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_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 ).
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 ).
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 ) 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.
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:
"mfront --obuild plasticity.mfront --interface=aster")os.system(
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:
"cp src/libAsterBehaviour.so plasticity.so")os.system(
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:
$ export ASTER_ROOT=/home/th202608/codes/aster/13.3.0/install/
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:
$ export PATH=$ASTER_ROOT/public/mfront-xxx/bin:$PATH $ export LD_LIBRARY_PATH=$ASTER_ROOT/public/mfront-xxx/lib:$LD_LIBRARY_PATH
To check that those environments have been properly set, just type:
$ mfront MFront::exe: no file name specified and nothing to be done Usage: mfront [options] [files]
This shows that
mfront has been found and is functional.
The following instruction will compile the
MFront behaviour using the
aster interface :
$ mfront --obuild --interface=aster plasticity.mfront Treating target : all The following library has been built : - libAsterBehaviour.so : asterplasticity
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
=DEFI_MATERIAU( UMAT=_F( LISTE_COEF = (C1,C2,....),),).......
For version greater than
13, the syntax has evolved:
=DEFI_MATERIAU( MFRONT=_F( LISTE_COEF = (C1,C2,....)),).......
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:
=_F ( RELATION = 'UMAT', COMPORTEMENT= 'libAsterBehaviour.so', LIBRAIRIE = 'asterplasticity', NOM_ROUTINE = 19, NB_VARI = 'GDEF_LOG', ) DEFORMATION
=_F ( RELATION = 'MFRONT', COMPORTEMENT= 'libAsterBehaviour.so', LIBRAIRIE = 'asterplasticity', NOM_ROUTINE = 'GDEF_LOG', ) DEFORMATION
Nicolò Grilli (University of Bristol) published a series of three videos showing in details how to make single and polycrystal simulations with
The series adresses several advanced topics regarding the interface between code_ater and MFront:
which can be very handy for a lot of users.