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 [1]).
Usage of MFront
in 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:
MFront
.COMPORTEMENT
field of the STAT_NON_LINE
function.Those two steps are detailed in this document.
A word of caution
MFront
is now part of thecode_aster
distribution. The use of another version ofMFront
for generating mechanical behaviours is strongly discouraged as there is no garantee that two versions of MFront are binary compatible: combining two versions ofMFront
can lead to an error in the best case, crashes ofcode_aster
in the worst case and a wide variety of strange behaviours in between.
MFront
behaviours officially integrated incode_aster
Some mechanical behaviours officially available in
code_aster
are natively generated withMFront
. Those may be distinguished by their names which are lowercase (e.g.Iwan
). This page only deals with user generatedMFront
mechanical behaviours.
aster
interfaceThe aster
interface can be used to introduce:
GDEF_LOG
and GROT_GDEP
finite strain strategies (see [2]).Support for MFront
finite strain behaviours is only available for code_aster
version greater than 13
.
code_aster
provides two distincts finite strain formulation:
SIMO_MIEHE
which is a finite strain formulation where the principle of virtual power is expressed in the current configuration (see [4]).GROT_GDEP
is the name in code_aster
of 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 Lagrangian
in the litterature (see [5]) and in other finite element solvers.From the behaviour point of view, using SIMO_MIEHE
or GROT_GDEP
differs from:
SIMO_MIEHE
, the second Piola-Kirchhoff stress in GROT_GDEP
)The @AsterFiniteStrainFormulation
keyword can be used to choose one of these finite strain formulation. This keyword must be followed by one of the following choice:
SIMO_MIEHE
GROT_GDEP
or TotalLagrangian
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 plasticity.mfront
.
code_aster
simulationThe 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 os
python
module to be loaded at the beginning of the .comm
file.
The previous instruction calls the mfront
executable which will:
C++
sources for the aster
interface from the plasticity.mfront
fileC++
sources.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 nom
).
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.so
is the default and most common name, this name can be affected by the use of the @Material
or the @Library
mfront
keywords.@Behaviour
mfront
keyword, but it can affected by use of the @Material
keyword.MFront
functionalities, such as calling other MFront
files (declaring for example material properties) from the plasticity.mfront
file.MFront
outside the code_aster
environmentAs 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.
To use MFront
outside of a code_aster
simulation, we have to set an appropriate environment.
Let ASTER_ROOT
be an environment variable containing the installation directory of code_aster
(as_run
and 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 $ASTER_ROOT/public/mfront-xxx
where xxx
stands for the version of MFront
delivered with code_aster
.
To use MFront
, one must set the PATH
and 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 src
subdirectory.
This second approach has the following advantages:
MTest
before their introduction in code_aster
, which is a good pratice.MFront
are available.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).LD_LIBRARY_PATH
.Starting from an existing input file, two things must be declared:
DEFI_MATERIAU
operator.COMPORTEMENT
field of the mechanical operators (STAT_NON_LINE
, DYNA_NON_LINE
, SIMU_POINT_MAT
, …).DEFI_MATERIAU
In the DEFI_MATERIAU
block, one must add for code_aster
version 12.x
:
=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, C1
, …, CN
are the material properties declared by the MFront
behaviour, in the same exact order.
COMPORTEMENT
field of mechanical operatorsIn the COMPORTEMENT
part of the main computation instructions (STAT_NON_LINE
, DYNA_NON_LINE
, 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 MFront
and code_aster
:
The series adresses several advanced topics regarding the interface between code_ater and MFront:
which can be very handy for a lot of users.
#References