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é.
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 :
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 :
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 :
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.
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.
.
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.
Il y avait une erreur dans l'objet Title.cpp car le mapper n'était pas initialisé à NULL lors du constructeur.
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.
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 !).
[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]:
[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]: