Welcome to the forums. Please post in English or French.

You are not logged in.

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

Groguiguy
Member
Registered: 2017-11-07
Posts: 67

ELAS_HYPER avec 3D_INCO_UP

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 smile ).

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. smile

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

Offline

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

AsterO'dactyle
Administrator
Registered: 2007-11-29
Posts: 173

Re: ELAS_HYPER avec 3D_INCO_UP

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_*


Code_Asterの開発者

Offline

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

Groguiguy
Member
Registered: 2017-11-07
Posts: 67

Re: ELAS_HYPER avec 3D_INCO_UP

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)

Offline

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

thomas.helfer
Member
Registered: 2013-09-26
Posts: 80

Re: ELAS_HYPER avec 3D_INCO_UP

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

Offline

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

Groguiguy
Member
Registered: 2017-11-07
Posts: 67

Re: ELAS_HYPER avec 3D_INCO_UP

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

Offline

Board footer