This document shows how to use
MFront mechanical behaviour in EDF
Code_Aster finite element solver. It is extracted from the
MFront tutorial. A full description is available in the
Code_Aster reference documentation (see Code (2014)).
Code_Aster can be made very easy, once a few things have been clarified. This is precisely the purpose of this page.
Note that this page is focused on mechanical behaviours. One can also use material properties generated with the
python interface, the description of which is out of the scope of this page.
Usage of mechanical behaviours generated by
MFront is a two step process:
COMPORTEMENTfield of the
Those two steps are detailed in this document.
A word of caution
MFrontis now part of the
Code_Asterdistribution. The use of another version of
MFrontfor generating mechanical behaviours is strongly discouraged as there is no garantee that two versions of MFront are binary compatible: combining two versions of
MFrontcan lead to an error in the best case, crashes of
Code_Asterin the worst case and a wide variety of strange behaviours in between.
MFrontbehaviours officially integrated in
Some mechanical behaviours officially available in
Code_Asterare natively generated with
MFront. Those may be distinguished by their names which are lowercase (e.g.
Iwan). This page only deals with user generated
aster interface can be used to introduce:
GROT_GDEPfinite strain strategies (see EDF (2013a)).
MFront finite strain behaviours is only available for
Code_Aster version greater than
Code_Aster provides two distincts finite strain formulation:
SIMO_MIEHEwhich is a finite strain formulation where the principle of virtual power is expressed in the current configuration (see EDF (2013b)).
GROT_GDEPis the name in
Code_Asterof a finite strain formulation based on the principle of virtual work in the reference configuration expressed in term of the Green-Lagrange strain and the second Piola-Kirchhoff stress. Such a formulation is also called
Total Lagrangianin the litterature (see Belytschko (2000)) and in other finite element solvers.
From the behaviour point of view, using
GROT_GDEP differs from:
SIMO_MIEHE, the second Piola-Kirchhoff stress in
@AsterFiniteStrainFormulation keyword can be used to choose one of these finite strain formulation. This keyword must be followed by one of the following choice:
By default, finite strain behaviours must be used with the
SIMO_MIEHE finite strain formulation.
Support of the
GROT_GDEPfinite strain formulation
Official versions of
Code_Asterdoes not support yet calling
MFrontbehaviours for the
GROT_GDEPfinite strain formulation.
The first step can be done as part of a
Code_Aster simulation or before running
Code_Aster. These two approaches have their advantages and their drawbacks.
The first one is used in
Code_Aster verification tests associated with
MFront and for various examples delivered with the code.
In practice, we consider the second approach to be easier and more flexible.
In the following, we will consider the case of single mechanical behaviour implemented in a file called
The instructions for the generation of the shared library are given in the
.comm file by an instruction similar to:
Such an instruction requires the
python module to be loaded at the beginning of the
The previous instruction calls the
mfront executable which will:
C++sources for the
asterinterface from the
Those operations are performed in a temporary directory in which the
Code_Aster simulation is run. For the
plasticity.mfront to be present in this directory, it must be declared in
astk as an external data file (e.g. with type
The library is generated in the
src subdirectory. For convenience, this library is often copied in the current directory and often renamed with an instruction similar to:
The advantage of this first approach is that
as_run automatically set various environment variables for
mfront to work.
Moreover, the library is generated in the current directory (or in the
src subdirectory if the library is not copied and renamed), which means that it can directly be found when needed, typically when the
STAT_NON_LINE function is called.
This first approach however have however serious drawbacks:
C++sources or the compilation of the shared library fail.
libAsterBehaviour.sois the default and most common name, this name can be affected by the use of the
mfrontkeyword, but it can affected by use of the
MFrontfunctionalities, such as calling other
MFrontfiles (declaring for example material properties) from the
As previously described,
as_run sets up various environment variables to enable the use of
mfront and the use of the shared libraries generated by
mfront during the simulation.
MFront outside of a
Code_Aster simulation, we have to set an appropriate environment.
ASTER_ROOT be an environment variable containing the installation directory of
astk are then located in the
$ASTER_ROOT/bin directory). In the examples below, the
ASTER_ROOT variable is supposed to have been defined by the user. Using the
bash shell, this is done by:
Of course, the previous instruction must be adapted for your specific installation.
MFront is installed in
xxx stands for the version of
MFront delivered with
MFront, one must set the
LD_LIBRARY_PATH as follows:
To check that those environments have been properly set, just type:
This shows that
mfront has been found and is functional.
The following instruction will compile the
MFront behaviour using the
aster interface :
This shows that the
libAsterBehabviour.so has been generated. It contains a function called
asterplasticity. This library is located in the
This second approach has the following advantages:
MTestbefore their introduction in
Code_Aster, which is a good pratice.
The shared library is not in the temporary directory used by
as_run to run the simulation, so the user must specify where it is located. This can be done in various ways:
astk(external data file).
Starting from an existing input file, two things must be declared:
COMPORTEMENTfield of the mechanical operators (
DEFI_MATERIAU block, one must add for
For version greater than
13, the syntax has evolved:
In both cases,
CN are the material properties declared by the
MFront behaviour, in the same exact order.
COMPORTEMENTfield of mechanical operators
COMPORTEMENT part of the main computation instructions (
SIMU_POINT_MAT, …), the behaviour has the name
MFRONT. Here is an example of such declaration:
Code_Aster team uses the
This section reports all the issues are related to
MFront. The number of the ticket are the one used by the
For versions prior to 13.4, invalid deformation gradients were send to the behaviour during the prediction phase, causing floatting point exceptions.
For previous versions, one workaround is to use another prediction policy, for example:
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/92/simo_miehe-with-mfront.
If the behaviours declares an external state variable (corresponding to a “control variable” in
Code_Aster wording), its availability is not checked.
If not correctly declared, a nan value seems to be passed to the behaviour, which can be quite difficult to debug.
Note that the number of declared external state variables is not passed to the
MFront behaviour, so even this basic check is not possible.
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/93/better-support-of-external-state-variables.
MFrontsmall strain behaviours and
MFront small strain behaviours are not usable with
GROT_GDEP due to a meaningless restriction.
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/96/mfront-small-strain-behaviours-and.
MFrontfinite strain behaviours and
MFront finite strain behaviours are currently restricted to the
SIMO_MIEHE finite strain formulation. Support for the
GROT_GDEP finite strain formulation will be available in
MFront 3.1 (see the documentation of the
@AsterFiniteStrainFormulation keyword). Appropriate developments must be made on the
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/97/mfront-finite-strain-behaviours-and.
MFront: check if the behaviour is small strain or finite strain
Currently, one can use a
MFront finite strain behaviour with the
GDEF_LOG option, leading to a severe crash.
MFront behaviour is a finite or small strain behaviour shall be checked by
Code_Aster. This piece of information is given by the
A small strain behaviour shall be usable in the small strain assumption and with the
GDEF_LOG finite strain strategies.
A finite strain behaviour shall only be usable with
SIMO_MIEHE. (and with
GROT_GDEP in the future, see Ticket #97 below.
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/98/mfront-check-if-the-behaviour-is-small.
MFront: minimal length in LIST_COEF is not meaningfull
Currently, a least 2 entries must be given in the
LIST_COEF command. This is not meaningfull as some behaviours contains all the relevant physical information and does not require any material property.
To overcome this issue, two dummy material properties can be added to the
MFront behaviour from the command line:
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/99/mfront-minimal-length-in-list_coef-is-not.
MFront: restrict the finite strain strategies usable
For small strain behaviours,
MFront 3.1 provides a keyword (
@FiniteStrainStrategy) stating which finite strain strategy (
GDEF_LOG) has been used for the behaviour identification.
Code_Aster are required to read this information and check proper usage of the behaviour.
For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/100/mfront-restrict-the-finite-strain.
MFront: the library name containing officially supported behaviours is the same as the default library name generated by
By default (if neither the
@Library nor the
@Material keywords are used),
MFront generates a library called
This library may conflict with the library delivered with
Code_Aster which contains the officially supported behaviours.
Changing the library name in
Code_Aster seems easier for backward compatibility (for example, for
MFront: allow modification of parameters
Parameters are the MFront “flightweight” way of modifying the coefficients of a behaviour. Compared to material properties (given through the
LIST_COEF entry in
Code_Aster), parameters have default values. They are also global values, meaning that have the same value for every material.
It is possible to overload the default values by defining an appropriate text file (see the MFront documentation) in the current directory (meaning that this txt file must be declared as a data in the export file, otherwise not copied by
However, modifying parameters from the input file would be more convenient and would allow the supervisor to check that a parameter as been modified (hence, the study is no more under AQ if the behaviour was under AQ).
Currently a parameter can be modified through the
ExternalLibraryManager class of the
Code_Aster already modifies the
epsilon parameter if needed.
Belytschko, Ted. 2000. Nonlinear Finite Elements for Continua and Structures. Chichester ; New York: Wiley-Blackwell.
Code, Aster. 2014. “Notice d’utilisation Du Couplage Entre Code_Aster et Les Modules de Lois de Comportement Zmat et UMAT.” Référence du Code Aster U2.10.01. EDF-R&D/AMA. http://www.code-aster.org.
EDF. 2013a. “Modèles de Grandes Déformations GDEF_LOG et GDEF_HYPO_ELAS.” Référence du Code Aster R5.03.24 révision : 10464. EDF-R&D/AMA. http://www.code-aster.org.
EDF. 2013b. “Loi de Comportement Hyperélastique : Matériau Presque Incompressible.” Référence du Code Aster R5.03.19. EDF-R&D/MITI/MMN. http://www.code-aster.org.