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:

Those two steps are detailed in this document.

A word of caution

MFront is now part of the code_aster distribution. The use of another version of MFront for generating mechanical behaviours is strongly discouraged as there is no garantee that two versions of MFront are binary compatible: combining two versions of MFront can lead to an error in the best case, crashes of code_aster in the worst case and a wide variety of strange behaviours in between.

MFront behaviours officially integrated in code_aster

Some mechanical behaviours officially available in code_aster are natively generated with MFront. Those may be distinguished by their names which are lowercase (e.g. Iwan). This page only deals with user generated MFront mechanical behaviours.

Overview of the aster interface

The aster interface can be used to introduce:

Finite strain behaviours

Support for MFront finite strain behaviours is only available for code_aster version greater than 13.

code_aster provides two distincts finite strain formulation:

From the behaviour point of view, using SIMO_MIEHE or GROT_GDEP differs from:

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:

By default, finite strain behaviours must be used with the SIMO_MIEHE finite strain formulation.

Generating the shared library

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.

Generating the shared library as part of the code_aster simulation

The instructions for the generation of the shared library are given in the .comm file by an instruction similar to:

os.system("mfront --obuild plasticity.mfront --interface=aster")

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:

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:

os.system("cp src/")


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:

Second approach: generating the library before launching the simulation

Usage of MFront outside the code_aster environment

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.

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.

Generation of the shared library

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 :
- :  asterplasticity

This shows that the has been generated. It contains a function called asterplasticity. This library is located in the src subdirectory.


This second approach has the following advantages:


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:

Declaration of the call

Starting from an existing input file, two things must be declared:


Version 12.x

In the DEFI_MATERIAU block, one must add for code_aster version 12.x:

.......=DEFI_MATERIAU( UMAT=_F( LISTE_COEF = (C1,C2,....),),)

Version 13.x

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.

Definition of the material in the COMPORTEMENT field of mechanical operators

In 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:

Version 12.x

                  LIBRAIRIE   = '',
                  NOM_ROUTINE = 'asterplasticity',
                  NB_VARI     = 19,
                  DEFORMATION = 'GDEF_LOG', )

Version 13.x

                  LIBRAIRIE   = '',
                  NOM_ROUTINE = 'asterplasticity',
                  DEFORMATION = 'GDEF_LOG', )

A series of tutorials on video by N. Grilli

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.

Various examples


Code, Aster. U2.10.01: Notice d’utilisation du couplage entre Code_aster et les modules de lois de comportement Zmat et UMAT. Référence du Code Aster. EDF-R&D/AMA, 2014. Available from:
EDF. R5.03.24 révision : 10464: Modèles de grandes déformations GDEF_LOG et GDEF_HYPO_ELAS. Référence du Code Aster. EDF-R&D/AMA, 2013. Available from:
EDF. R5.03.22 révision : 11536: Loi de comportement en grandes rotations et petites déformations. Référence du Code Aster. EDF-R&D/AMA, 2013. Available from:
EDF. R5.03.22 révision : 11536: Loi de comportement en grandes rotations et petites déformations. Référence du Code Aster. EDF-R&D/AMA, 2013. Available from:
Belytschko, Ted. Nonlinear Finite Elements for Continua and Structures. Chichester ; New York : Wiley-Blackwell, 2000. ISBN 9780471987741.