From CAELinuxWiki
Revision as of 11:52, 18 November 2010 by Wikiadmin (Talk | contribs) (Reverted edit of Atywehacyg, changed back to last version by Keeswouters)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


   *  » Code_Aster usage
   *  » Non linear geometry on Code-Aster

Non linear geometry on Code-Aster

Hello, is possible activate non linear geometry on Code-Aster solver? There is a command (for example in ABAQUS there is NLGEOM=YES and the sw update stifness matrix step by step) to doing it? To activete it needed use some particular 3D element?

Regards Jacopo


Re: Non linear geometry on Code-Aster

NLGEOM in abaqus is unabled when dealing with high strains and high displacements / rotations.

You can do it as well in Aster using the GREEN or (depending on the behaviour law) SIMO_MIEHE for the strains tensors.

Thomas DE SOZA

  • In Code_Aster, geometrically (exact) non-linear analysis has to be enabled by hand depending on the type of finite element :
    • with isoparametric elements (D_PLAN,C_PLAN and 3D) you can use DEFORMATION='GREEN' to enable large displacements (including large rotations). Note that constitutive law is still written with a small strain hypothesis. Any constitutive law available under COMP_INCR can be used. Under COMP_ELAS, you can use ELAS_VMIS_* and ELAS_HYPER (non-linear elasticity and hyperelasticity).
    • with 3D shell elements (COQUE_3D), the same is enabled when selecting GREEN_GR (with constitutive law ELAS under COMP_ELAS, that is only linear elasticity can be used when dealing with large displacements/rotations).
    • with beam element POU_D_T_GD, you must use GREEN_GR (with constitutive law ELAS_POUTRE_GR under COMP_ELAS, that is only linear elasticity can be used).
    • with bar element CABLE, you must use GREEN (with constitutive law CABLE under COMP_ELAS, that is only linear elasticity can be used).
  • In addition to that, Code_Aster provides imprecise approaches to take into account large displacements/rotations :
    • for most of the finite elements one can use PETIT_REAC which updates the geometry at each iteration before computing the stiffness matrix, depending on the element it can be really hard to reach convergence (really slow).
    • for POU_D_TGM element (a multi-fiber beam element), one can use DEFORMATION='REAC_GEOM' to help converge when large displacements and large rotations occur.
  • Lastly, the most complete kinematic and constitutive behavior in Code_Aster is through the use of DEFORMATION='SIMO_MIEHE' (for isoparametric elements) which computes accurately the transformation gradient.



Note that constitutive law is still written with a small strain hypothesis. Any constitutive law available under COMP_INCR can be used.

Don't you can use comp_elas as well? In this case (for hyperelasticity for example) the stress tensor will be calculated regarding to the problem initial configuration and high strains can be considered through the Green Lagrange strain tensor. Well it remembers me one post: … 09&p=2 nlgeom2

Thomas DE SOZA Hi,

You're right, I modified my post to reflect your remarks.

TdS Jacopo

Thx Paul Thomas and Alex for help, now I asking you about a little summary about COMP_INCR and COMP_ELAS definition, I not sure to understand so well the differences. The COMP_ELAS to calculate the strain take as reference situation the indeformed shape (initial condition)? The COMP_INCR to calculate the starin take as reference the reactualizated geometry step by step? When is better use one instead other one? Other things, If I understand yuo said me that with 3D eleemnt you can use Green formulation to have a correct behaviuor for large rotation and large displacement.On the guideline I read that the green formulation give correct behaviour for big rotation but small displacement, it is true? To have correct behaviour for big roation and big displacement the best formulation appare Simo_miehe.

Thomas DE SOZA

  • 'GREEN' (meaning the strain tensor is Green-Lagrange) correctly models large displacements and large rotations but with the hypothesis of small strains (see in french R5.03.22).
  • Remember: small displacements implies small strains (which is often summed up as small perturbations) however small strains does not imply small displacements

Thomas, you have right as soon as possible I send you where I read what I said you on previous post (probabbly I made a mistake...), about what you said me I think that you wont said me something similar the simple example on file attched. On case 2 if I have a big perturbation I have big strain too, so I must use SIMO_MIEHI formulation.

Jacopo I make a mistake you have rigth I'm refferring to [U.4.51.11-B1 Comportements non linéaires] You can explane better the differencies between COMP_INCR and COMP_ELAS?

Regards and Thx again Jacopo


May be I'm mistaken but:

  • COMP_INCR => typically plastic calculation ... plastic calculation are calculated from plastic flow
  • COMP_ELAS => Contact calculation i.e. elastic material and geometrical non linearity


Thomas DE SOZA

  • COMP_ELAS : linear and non-linear elasticity. History of loading does not impact behavior, stress are related to (strains regarding a reference setup)

==> splitting the load into several parts is theorically not necessary. However the non-linearity is more easily solved when cutting it, that's why "temporal" discretization is also used as in COMP_INCR (where it is mandatory).

  • COMP_INCR : general constitutive equation (non-linear). History accounts for the constitutive equation. Incremental stresses are related to incremental strains (regarding last equilibrium setup). History is stored through internal variables (at each Gauss points).


  • Hyperélasticité - AsterO'dactyle


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

Gambatte !


Oui effectivement ça peut poser un problème ..... La question m'a interpelé donc je suis aller faire un petit tour dans les sources et effectivement les mêmes routines sont utilisées pour COMP_ELAS et COMP_INCR .... Par contre je n'ai pas trouvé de trace d'une conversion PK2 --> Cauchy, si quelqu'un sait où elle est réalisée, si elle est réalisée ...

En implémentant mes lois j'avais vérifié qu'en sortie de hypela, on avait PK2, je pensais que tout était calculé en PK2 puis converti en Cauchy au niveau des résultats. Dans l'absolu, il me semble que connaître Cauchy n'est pas nécessaire en hyperélasticité.

Au niveau de COMP_ELAS et COMP_INCR j'avais compris que COMP_ELAS se basait par rapport à la configuration initiale (formulation lagrangienne totale) et COMP_INCR en configuration incrémentale par rapport à la dernière configuration connue (formulation lagrangienne réactualisée).

Pourtant tout me semblait fonctionner correctement, même pour des déformations importantes lors de ma comparaison avec Abaq(....). De plus la nécessité de l'utilisation de la pression suiveuse pour avoir la bonne conception du tenseur de Cauchy appuie cette thèse. Bref je ne comprends plus trop .... il va falloir retrousser les manches big_smile .

Je suis moi-même particulièrement intéressé pour développé du code dans le but d'offrir une base hyperélastique plus complète et plus robuste sur Aster.


Revenons en à la discussion d'origine...

Où en êtes-vous de l'intégration de la loi à 9 paramètres ?

[english - well ...] I think that it is necessary to rewrite ELAS_HYPER in formulation SIMO-MIEHE rather (via the tensor F) than Green, because I have doubts about the fact that ELAS_HYPER respects the diagram strictly; Aster (return in Cauchy and not in PK2). What makes me doubt, is that one uses the same routines in COMP_INCR and COMP_ELAS. COMP_ELAS makes Cauchy conversion well --> PK2 all alone when one is in Green, but not COMP_INCR. That would explain why some have them problems with important deformations (for a weak deformation, PK2 and Cauchy are nearly identical, on the other hand, for strong deformations) The problem is that hyperelasticity is hardly used in-house by EDF. That is typically the qu' type of things; a Free Aster community should make. Ca m' interest in personal capacity, therefore I want well to facilitate the things, to write code and Doc. and to support in-house step. (and worse c' is funny to remake equations, that m' this WE amused well spalls). Gambatte!

AlexD Re:
Yes indeed, that can pose a problem. The question; thus I challenged am to go to make a small round in the sources and indeed the same routines are used for COMP_ELAS and COMP_INCR…. On the other hand I n' did not find of trace d' a conversion PK2 --> Cauchy, if quelqu' one knows where it is carried out, if it is carried out… By implementing my laws j' had checked qu' at exit of hypela, there were PK2, I thought that all was calculated in PK2 then converted into Cauchy on the level of the results. In l' absolute, it seems to me that to know Cauchy n' is not necessary in hyperelasticity. On the level of COMP_ELAS and COMP_INCR j' had understood that COMP_ELAS was based compared to the initial configuration (total Lagrangian formulation) and COMP_INCR in incremental configuration compared to the last known configuration (reactualized Lagrangian formulation). However all seemed me to function correctly, even for important deformations at the time of my comparison with Abaq (….). Moreover the need of l' use of the following pressure to have the good design of the tensor of Cauchy supports this thesis. In short I do not include/understand too much any more…. it the handles big_smile should be rolled up. I myself particularly interested for am developed code with an aim d' to offer a more complete and more robust hyperelastic base on Aster.