ELAS_HYPER avec 3D_INCO_UP

Groguiguy · 2018-03-06 16:47:53

Bonjour à tous,

Après avoir arpenter le forum pour demander de l'aide, c'est à mon tour de proposer quelque chose à la communauté.
En effet je suis intéressé par l'utilisation d'éléments incompressible pour ELAS_HYPER.

Si j'en crois la documentation R5.03.19 :

ELAS_HYPER: Cette relation s’étend à des grandes transformations ; cette fonctionnalité est choisie par l’intermédiaire du mot-clé DEFORMATION = ‘GROT_GDEP’. Elle est disponible pour les éléments 3D, 3D_SI, C_PLAN et D_PLAN.

De plus, pour l'incompressibilité R3.06.08 :

Les 3 modélisations utilisant le formalisme de grandes déformations de GDEF_LOG et s'appuyant sur une formulation à 2 champs sont accessibles en utilisant les options suivantes pour AFFE_MODELE:
•'3D_INCO_UP' pour le 3D,
•'D_PLAN_INCO_UP' pour le 2D en déformations planes,
•'AXIS_INCO_UP' pour le 2D axisymétrique.

Et

Les modélisations INCO_UP, INCO_UPG et INCO_UPO peuvent être utilisées avec les opérateurs de mécaniques non-linéaires STAT_NON_LINE et DYNA_NON_LINE. Il est aussi possible d'utiliser l’opérateur de mécanique linéaire MECA_STATIQUE cependant ceci est fortement déconseillé car les résultats obtenus peuvent être de qualité médiocre. La version petites déformations est accessible en utilisant DEFORMATION=’PETIT’ sous COMPORTEMENT, la version grandes déformations en utilisant DEFORMATION=’SIMO_MIEHE’ ou DEFORMATION=’GDEF_LOG’. Les relations de comportement utilisables sont celles disponibles respectivement en petites déformations et en grandes déformations SIMO_MIEHE ou GDEF_LOG pour les modélisation INCO_UPG. Les modélisations INCO_UP et INCO_UPO sont actuellement limitées aux relations ELAS et VMIS_ISOT_XXX.

Donc ELAS_HYPER n'est pas compatible avec 3D_INCO_UP, donc pas avec les grandes déformations ce qui est en contradiction avec la doc u4.51.11 au point 5.2.2 qui précise que l'application de ELAS_HYPER permet les grandes déformations.

La formulation des éléments incompressibles utilise la déformation de SIMO_MIEHE, mais celle de ELAS_HYPER utilise les déformations de GREEN-LAGRANGE (avec passage en Cauchy-Green droit?, et inversement je suppose?).
Enfin, j'ai trouvé cette discussion sur le forum, qui date de quelques années maintenant :

AsterO'dactyle wrote:

Bonsoir,
Je pense qu'il faut ré-écrire ELAS_HYPER en formulation SIMO-MIEHE (via le tenseur F) plutôt que Green, car j'ai des doutes sur le fait qu'ELAS_HYPER respecte bien le schéma d'Aster (retour en Cauchy et non en PK2).
Ce qui me fait douter, c'est qu'on utilise les mêmes routines en COMP_INCR et COMP_ELAS.
COMP_ELAS fait bien la conversion Cauchy -> PK2 tout seul quand on est en Green, mais pas COMP_INCR.
Ca expliquerait pourquoi certains ont eux des problèmes avec des déformations importantes (pour une faible déformation, PK2 et Cauchy sont quasi identiques, par contre, pour de fortes déformations...)
Le problème est que l'hyperélasticité n'est quasiment pas utilisée en interne EDF.
C'est typiquement le genre de choses qu'une communauté Aster Libre devrait faire.
Ca m'intéresse à titre personnel, donc je veux bien faciliter les choses, écrire du code et de la doc et soutenir la démarche en interne.
(et pis c'est rigolo de refaire des équations, ça m'a bien amusé ce WE ).

Donc j'aimerai savoir où la modélisation hyperélastique incompressible en est?

S'il faut réécrire ELAS_HYPER en formulation SIMO_MIEHE je suis intéressé par l’aventure, et son écriture dans MFront pour l'implémenter à Code_Aster. Pour cela, je suis prêt à déterminer la forme du tenseur de contrainte et de la matrice tangente (dériver une fois, puis une deuxième fois l'énergie libre selon la déformation de Simo-Miehe (doc u4.51.11 point 4.5.4)), mais j'aimerai savoir si cela est utile et je ne suis pas dans le faux, notamment si depuis cela a déjà été fait.

Last edited by Groguiguy (2018-03-06 17:49:22)

AsterO'dactyle · 2018-03-07 05:55:53

Bonjour,

POur faire court: dans quelques semaines, nous aurons MFront 3.1.1 qui permet l'écriture de lois hyperélastiques de type "GROT_GDEP" (en grandes def) mais aussi SIMO_MIEHE.
Du coup, il sera possible de faire du "ELAS_HYPER" en INCO_UPG avec SIMO_MIEHE en branchant SIgnoriniSimoMiehe.mfront par exemple (qui existe déjà, voir sur le site de MFront). J'ai essayé, ça fonctionne. Seul problème: SIMO_MIEHE est une forme non-symétrique et ça coûte !
Quant au branchement des autres formulations INCO en GROT_GDEP, c'est un peu plus compliqué. Les formulations INCO_UP sur des éléments linéaires en particulier ont besoin d'une condensation statique qui oblige à utiliser un nombre restreint de lois: ELAS et VMIS_ISOT_*

Groguiguy · 2018-03-07 13:55:15

Quant au branchement des autres formulations INCO en GROT_GDEP, c'est un peu plus compliqué. Les formulations INCO_UP sur des éléments linéaires en particulier ont besoin d'une condensation statique qui oblige à utiliser un nombre restreint de lois: ELAS et VMIS_ISOT_*

Oui, je voulais dire 3D_INCO_UPG, vu que j'utilise des éléments tétraédrique à 10 noeuds.

Du coup, il sera possible de faire du "ELAS_HYPER" en INCO_UPG avec SIMO_MIEHE en branchant SIgnoriniSimoMiehe.mfront par exemple (qui existe déjà, voir sur le site de MFront). J'ai essayé, ça fonctionne. Seul problème: SIMO_MIEHE est une forme non-symétrique et ça coûte !

J'ai proposé d'aider à passer en grandes def incompressibles via SIMO_MIEHE car c'était votre idée originelle dans le post de 2008, mais étant une formulation développée pour l'écrouissage (il me semble) je ne sais pas si c'est plus pertinent que la forme logarithmique.
Si je comprends bien la doc R3.06.08 alors GDEF_LOG n'est utilisable qu'avec les éléments supportant 2 champs, pas 3 comme les éléments tétraédrique à 10 noeuds, c'est pour ça que vous proposiez une réécriture en SIMO_MIEHE et pas GDEF_LOG à l'époque?

Avec une formulation en SIMO_MIEHE la déformation est exprimé avec Cauchy-Green gauche si je me souviens bien (description eulérienne), hors le calcul de PK2 se fait avec Cauchy-Green droit, dans la version MFront que vous décrivez il y aura le retour entre gauche et droite pour passer de Green-Lagrange à Euler-Almansi? Car dans COMP_ELAS ou COMP_INCR les déformations sont calculés par rapport à la configuration de référence, donc en Green-Lagrange.

Pour faciliter le calcul, en forçant la symétrie la perte de précision serait trop importante? Problème de convergence avec l'algorithme de Newton? N'y a t'il pas moyen de développer GDEF_LOG sur des éléments à 3 champs, afin de faciliter le calcul car il me semble que GDEF_LOG est symétrique? Y a t'il quelque chose qui puisse être développé par la communauté pour le calcul hyperélastique en grande déformation incompressible du coup? Au laboratoire nous nous dirigeons de plus en plus sur l'utilisation de Code_Aster pour nos calculs biomécanique, j'espérais peut être pouvoir aider la communauté.

Last edited by Groguiguy (2018-03-07 14:01:23)

thomas.helfer · 2018-03-10 07:36:53

Bonjour,

Je me permets une petite précision.

Il y a en effet une difficulté liée à la présentation de GROT_GDEP et SIMO_MIEHE dans la documentation Aster qui sont en premier lieu associés pour le premier à une façon d'étendre une loi "petite transformations" en "grandes rotations petites déformations" et pour le second à une loi de comportement élasto-viscoplastique particulière.

Mais du point de vue "MFront", GROT_GDEP et SIMO_MIEHE ne sont que deux écritures différentes du principe des travaux virtuels et c'est précisément ce dont parle AsterO'dactile. Ils ne diffèrent que par:

- le tenseur des contraintes attendu en sortie (PK2 pour le premier, Cauchy pour le second)
- par la tangente cohérente attendues en sortie (DS_DEGL pour le premier, DTAU_DDF pour le second)

On peut utiliser ces deux options indifféremment pour toutes lois gérant les grandes transformations en interne c'est à dire prenant le gradient de la transformation en entrée et calculant Cauchy (MFront se chargera en interne des conversions ad hoc).

Autre précision, pour en avoir déjà discuter avec notre dinosaure favori, j'avoue ne toujours pas comprendre pourquoi SIMO_MIEHE conduit à une résolution non symétrique. Je pense que c'est lié à la loi initiale (je n'y mettrai pas ma main à couper, mais j'émets l'hypothèse qu'on pourrait symétrisé la matrice de raideur pour les lois hyperélastiques sans problème).

Cordialement,

Thomas Helfer

Groguiguy · 2018-03-13 14:46:46

Bonjour Thomas Helfer (au passage, je suis le collègue de Laure Astruc et Jean-François Witz),

Merci beaucoup pour ces précisions.

Donc avec la nouvelle version 3.1.1 le calcul incompressible hyperélastique est possible avec la formulation SIMO_MIEHE (mais lourd car non-symétrique même si le forçage semble possible). Mais en GROT_GDEP les éléments mixtes ne sont pas compatibles.
Pourquoi les éléments à 3 champs ne sont pas compatibles avec GROT_GDEP ?

Du coup, que faudrait il pour développer GROT_GDEP en incompressible? L'adapter à des éléments mixtes à 3 champs?

Au labo nous serions peut être (si c'est dans nos cordes) prêt à tenter l'aventure d'implémenter cela dans Code_Aster vu que nous transférons nos modèles Abaqus sur Code_Aster au fur et à mesure.

En vous remerciant,
Guillaume Dufaye

#1 2018-03-06 16:47:53

ELAS_HYPER avec 3D_INCO_UP

#2 2018-03-07 05:55:53

Re: ELAS_HYPER avec 3D_INCO_UP

#3 2018-03-07 13:55:15

Re: ELAS_HYPER avec 3D_INCO_UP

#4 2018-03-10 07:36:53

Re: ELAS_HYPER avec 3D_INCO_UP

#5 2018-03-13 14:46:46

Re: ELAS_HYPER avec 3D_INCO_UP

Board footer