Metafor

ULiege - Aerospace & Mechanical Engineering

User Tools

Site Tools


commit:2016:04_11

Commit 2016-04-11

Ce commit permet d'activer la matrice de raideur analytique pour le contact défo-défo et dès lors, il est possible de lancer une simulation en parallèle !

Elle est programmée pour tous les matériaux de contact du type pénalité. Il reste à la programmer pour les matériaux du type lagrangien augmenté.

Il y a un gardien en interne qui indique qu'il n'y a pas de matrice de raideur analytique pour les méthodes de contact du type énergétiquement consistente.

Applications

Voici un exemple d'utilisation : l'écrasement d'une cellule hexagonale (TFE Hervé Delhalle).

Le cas test est extrêmement couteux en temps CPU : auto-contact, contact defo-defo, EAS, 3D.

Grâce à mes développements, on peut paralléliser l’entièreté du code (Assemblage des forces, de la matrice de raideur, résolution du système linéaire).

Les deux vidéos correspondent au même ensemble de paramètres numériques et matériaux. Il y a juste le nombre d'archivage qui varie (100 à 500). La simulation Metafor s'arrête suite aux éléments extrêmement déformés autour des zones d'auto-contact. Étant donné que l'archivage force la simulation à passer par certains points de l'intégration temporelle, il se peut que certaines configurations de contact soient problématique à un moment donné, d'où les différences sur l'aboutissement de la simulation.

En lançant la simulation en parallèle sur le cluster (avec 12 CPUs), on obtient :

  • un temps Real CPU de 8m22.94s (User CPU de 1h29m19.76s) pour 643 STEP (68.7838% done) pour un archivage de 100,
  • un temps Real CPU de 15m11.35s (User CPU de 2h26m21.33s) pour 1196 STEP (97.5692% done) pour un archivage de 500.

Les mêmes simulations lancées en série sur le cluster en matrice de raideur numérique (uniquement pour le contact défo-défo), on obtient :

  • un temps Real CPU de 14m41.16s (User CPU de 14m38.95s) pour 248 STEP (81.9944% done) pour un archivage de 100,
  • un temps Real CPU de 1h5m38.35s (User CPU de 1h5m34.43s) pour 1469 STEP (88.361% done) pour un archivage de 500.

Les mêmes simulations lancées en série sur le cluster en matrice de raideur analytique (uniquement pour le contact défo-défo), on obtient :

  • un temps Real CPU de 14m32.94s (User CPU de 14m30.73s) pour 248 STEP (81.9944% done) pour un archivage de 100,
  • un temps Real CPU de 42m38.64s (User CPU de 42m35.89s) pour 1041 STEP (97.5692% done) pour un archivage de 500.

Paradoxalement, on observe une différence dans le nombre de STEP effectué entre la version en parallèle et en série du même cas test (Assemblage de la matrice de raideur ne se fait pas dans le même ordre entre la version parallèle et la version série). On dénote une diminution du temps de calcul (léger tout de même, mais bon il n'y a pas énormément de nœud en contact !) entre la version analytique et la version numérique de la matrice de raideur de contact.

Programmation - Aspect

Contrairement aux éléments volumiques, les éléments de contact sont particulièrement difficile à linéariser suite à la présence de nombreuses configurations de contact différente d'une part et d'autre part le traitement différent en fonction d'un nœud esclave ou d'un nœud maître.

Après une première tentative peu efficace mais qui marchait pour le calcul de la matrice de contact défo-défo (C'était le matériau qui calculait les matrices de raideur “nœud-noeud” en fonction du type de projection et en fonction des nœuds considérés (esclave ou maitre), ce qui entrainait beaucoup de copier/coller !), j'ai proposé une hiérarchie de classe “ContactGKState” qui est uniquement instanciée lors du calcul de la matrice de raideur de contact, puisque que nous en avons uniquement besoin à ce moment là. La fonction première de cette classe est de calculer les incréments de gap normal et tangentiel (ce sont des vecteurs), les incréments de normal, de tangentes (ce sont des matrices), et les incréments des coordonnées intrinsèques de projection (ce sont des vecteurs) pour chaque nœud. Une fois que c'est fait, il suffit de demander au matériau de calculer la matrice de raideur noeud-noeud et ensuite de l'assembler dans la matrice de raideur de l'élément de contact. Cela permet de découpler le matériau de la cinématique de contact (gaps et repère local), ce qui aurait dû être fait pour les matrices de raideur rigide déformable.

Le prix à payer est la présence de nouvelles variables dans le projection state, qui sont uniquement utiliser pour le contact défo-défo et pour certaines configurations de contact défo-défo. On se stocke le strict minimum en mémoire, ce qui implique un re-calcul de variables déjà calculées auparavant lors de la détection du contact. Ce n'est pas top mais ça reste un compromis à l'heure actuelle étant donné la structure du code source pour les opérateurs de projection et l'organisation des librairies.

Finalement, je tiens à signaler que rien n'avait été pensé, voir conçu, d'où la difficulté, pour déterminer la matrice de raideur tangente analytique en contact défo-défo.

Pour chaque configuration de contact, je suis resté le plus général possible dans la détermination des différents termes de contact (On peut avoir du contact double projection avec une face quadrangulaire et une face triangulaire !). Dès lors, si on insère de nouvelles entités maîtres avec lesquelles on effectue du contact, il suffira de modifier un nombre très limité de fonctions (calcul de tangente, de dérivée de tangente, de normal, bref purement de la géométrie)

.

Modifications - Corner-Line & Corner-Node Projection

J'ai modifié la manière avec laquelle on récupère les nœuds de l'outil. En effet, on partait du principe qu'une configuration de contact du type Corner Node (Un nœud esclave et un nœud maitre) possède au moins trois faces (Un point est l'intersection de trois surfaces en 3D !). Cependant, avec les tolérances in et out utilisées pour les sommets et les bords de chaque face, il y avait des configurations de contact du type Corner Node avec deux faces au total et l'algorithme renvoyait deux nœuds maitres au lieu d'un nœud maitre !!!

Ce bug a été corrigé pour les faces triangulaires et quadrangulaires.

Bug Fix

Visualisation

Il y avait une erreur dans l'objet Title.cpp car le mapper n'était pas initialisé à NULL lors du constructeur.

Area In Contact

En dérivant la version défo-défo de la matrice de raideur de contact avec l'option AIC, j'ai constaté que les gradients d'aire de contact nodale étaient mal calculés puisqu'on ne calculait pas l'épaisseur hors plan.

Perspectives

Il est nécessaire de créer une batterie de test pour le contact défo-défo. Pour l'instant, je me suis contenté de reprendre les cas tests bacon existant. J'ai ajouté la version analytique du cas test du point de vue de la matrice de raideur de contact. A terme, il faudrait faire des cas-tests du type défo-défo en enrichissant la boite à outils createContactTests car ce serait beaucoup plus systématique (voir le répertoire contactMech et contactTmMech).

Du point de vue théorique, j'ai constaté une erreur pour le contact tangentiel. En effet, dans le cas où le point de projection et le point de collement appartiennent à deux faces/courbes différentes, on doit inclure tous les nœuds des deux faces/courbes pour l'élément de contact et pas uniquement les nœuds de la face sur laquelle on projette le nœud esclave. En fait, il n'y a pas de forces appliquées sur les nœuds de la courbe/face où se trouve le point de collement (Sauf les nœuds commun avec la face/courbe de projection du nœud esclave), mais nous devons inclure ces nœuds pour calculer correctement l'incrément du gap tangentiel !

Finalement, je ferai un petit refactoring (Simplification de l'interface du contactTool et des objects géométriques) de ce qui est déjà programmé pour essayer d'avoir un interface commun (pour les ContactGKState) et également il faudra vérifier si on ne peut pas encore gagner du temps CPU dans ce qui est déjà programmé (Ajouter des gardiens pour éviter de calculer des termes qui seront d'office nuls ou l'inverse éliminer ces gardiens et laisser le code calculer : difficile de juger sans avoir fait des tests !).

L'ensemble de configuration de contact proposé par la routine decideContact a été traité a priori ! Cependant, il est fort probable qu'il faut ajouter de nouvelles configurations pour traiter plus facilement les cas pathologiques (par exemple, lorsque deux faces adjacentes possèdent un angle de faible ouverture). En gros, je n'ai rien modifié dans le choix de la configuration finale de contact.

Fichiers ajoutés/supprimés

[a]:mtContact/src/ClassicalDoubleProjectionContact2DGKState.cpp
[a]:mtContact/src/ClassicalDoubleProjectionContact2DGKState.h
[a]:mtContact/src/ClassicalDoubleProjectionContact3DGKState.cpp
[a]:mtContact/src/ClassicalDoubleProjectionContact3DGKState.h
[a]:mtContact/src/Contact2DGKState.cpp
[a]:mtContact/src/Contact2DGKState.h
[a]:mtContact/src/Contact3DGKState.cpp
[a]:mtContact/src/Contact3DGKState.h
[a]:mtContact/src/ContactGKState.cpp
[a]:mtContact/src/ContactGKState.h
[a]:mtContact/src/CornerProjectionContact2DGKState.cpp
[a]:mtContact/src/CornerProjectionContact2DGKState.h
[a]:mtContact/src/CornerProjectionContact3DGKState.cpp
[a]:mtContact/src/CornerProjectionContact3DGKState.h
[a]:mtContact/src/DoubleProjectionContact2DGKState.cpp
[a]:mtContact/src/DoubleProjectionContact2DGKState.h
[a]:mtContact/src/DoubleProjectionContact3DGKState.cpp
[a]:mtContact/src/DoubleProjectionContact3DGKState.h
[a]:mtContact/src/EdgeProjectionContactGKState.cpp
[a]:mtContact/src/EdgeProjectionContactGKState.h
[a]:mtContact/src/SingleProjectionContact2DGKState.cpp
[a]:mtContact/src/SingleProjectionContact2DGKState.h
[a]:mtContact/src/SingleProjectionContact3DGKState.cpp
[a]:mtContact/src/SingleProjectionContact3DGKState.h
[a]:mtContact/src/SpecialDoubleProjectionContact2DGKState.cpp
[a]:mtContact/src/SpecialDoubleProjectionContact2DGKState.h
[a]:mtContact/src/SpecialDoubleProjectionContact3DGKState.cpp
[a]:mtContact/src/SpecialDoubleProjectionContact3DGKState.h
[r]:

Cas tests ajoutés/supprimés

[a]:apps/bImp/cyl3DDyn.py
[a]:apps/bImp/cyl3DDynAna.py
[a]:apps/bImp/cylElastDynAna.py
[a]:apps/bImp/cylElastDynNum.py
[a]:apps/bImp/cylElastFrotDynAna.py
[a]:apps/bImp/cylElastFrotDynNum.py
[a]:apps/bImp/cylPlastDynAna.py
[a]:apps/bImp/cylPlastDynNum.py
[a]:apps/bImp/laursenContact2DAna.py
[a]:apps/bImp/laursenContact3DAna.py
[a]:apps/bQs/carresSPointeDd1Ana.py
[a]:apps/bQs/carresSPointeDd2Ana.py
[a]:apps/bQs/carresSPointeDd3Ana.py
[a]:apps/bQs/corner1Ana.py
[a]:apps/bQs/corner2Ana.py
[a]:apps/bQs/cubeContactType1Ana.py
[a]:apps/bQs/cubeCorDd1Ana.py
[a]:apps/bQs/cubeCorDd2Ana.py
[a]:apps/bQs/cubeCorDd3Ana.py
[a]:apps/bQs/cubeLinAna.py
[a]:apps/bQs/cubes1Ana.py
[a]:apps/bQs/cubes1NC2Ana.py
[a]:apps/bQs/cubes1NCAna.py
[a]:apps/bQs/cubes2Ana.py
[a]:apps/bQs/frot2d1Ana.py
[a]:apps/bQs/frot2d2Ana.py
[a]:apps/bQs/frot3dAna.py
[a]:apps/bQs/frot3dVariableFrotCoefAna.py
[a]:apps/contactMec/contact3dTriangleDDAna.py
[a]:apps/contactMec/initialBalancingAube2to3Moyeu2DAna.py
[a]:apps/contactMec/initialBalancingAube2to3Moyeu3DAna.py
[a]:apps/contactMec/initialBalancingAube2to5Moyeu2DAna.py
[a]:apps/contactMec/initialBalancingAube2to5Moyeu3DAna.py
[r]:
commit/2016/04_11.txt · Last modified: 2024/03/01 16:10 by boman

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki