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

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:

• Generating the shared library containing the mechanical behaviour using MFront.
• Declaring the mechanical behaviour in the 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 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:

• Small strain mechanical behaviours. Those behaviours can be used with the GDEF_LOG and GROT_GDEP finite strain strategies (see EDF (2013a)).
• Finite strain mechanical behaviours.
• Cohesive zone models.

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

• SIMO_MIEHE which is a finite strain formulation where the principle of virtual power is expressed in the current configuration (see EDF (2013b)).
• 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 Belytschko (2000)) and in other finite element solvers.

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

• The choice of the output stress (the Cauchy stress in SIMO_MIEHE, the second Piola-Kirchhoff stress in GROT_GDEP)
• The definition of the consistent tangent operator.

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.

Support of the GROT_GDEP finite strain formulation

Official versions of Code_Aster does not support yet calling MFront behaviours for the GROT_GDEP 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:

• generate C++ sources for the aster interface from the plasticity.mfront file
• build the shared library from the previous C++ 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:

os.system("cp src/libAsterBehaviour.so plasticity.so")

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.

### Drawbacks

This first approach however have however serious drawbacks:

• No error messages is thrown if the generation of the C++ sources or the compilation of the shared library fail.
• The user must know a priori the name of the generated library: Although 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.
• The user must know a priori the name of function that implements the behaviour. This name is most of the time deduced from the behaviour name, as given by @Behaviour mfront keyword, but it can affected by use of the @Material keyword.
• The shared library is compiled at each run of the simulation. This can be a waste of time (the compilation of an unique behaviour can take several seconds).
• It precludes, or at least makes more difficult, the use of advanced MFront functionalities, such as calling other MFront files (declaring for example material properties) from the plasticity.mfront file.

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

• Compilation errors are easier to detect, analyze and correct.
• The mechanical behaviours can be tested with MTest before their introduction in Code_Aster, which is a good pratice.
• All the functionnalities of MFront are available.
• The shared library is build only once (i.e. is not rebuilt for each simulation run)
• The shared library can be placed in a shared folder, allowing various members of a team to use the same mechanical behaviour.

### Drawbacks

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:

• The library can be marked as a dependency of the computation in astk (external data file).
• The absolute path of the library must be given.
• The directory where the shared library is located must be added to the LD_LIBRARY_PATH.

# Declaration of the call

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

• a material with appropriate coefficients using the DEFI_MATERIAU operator.
• a behaviour in the COMPORTEMENT field of the mechanical operators (STAT_NON_LINE, DYNA_NON_LINE, SIMU_POINT_MAT, ...).

## Call to the DEFI_MATERIAU

### 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

COMPORTEMENT=_F ( RELATION    = 'UMAT',
LIBRAIRIE   = 'libAsterBehaviour.so',
NOM_ROUTINE = 'asterplasticity',
NB_VARI     = 19,
DEFORMATION = 'GDEF_LOG', )

### Version 13.x

COMPORTEMENT=_F ( RELATION    = 'MFRONT',
LIBRAIRIE   = 'libAsterBehaviour.so',
NOM_ROUTINE = 'asterplasticity',
DEFORMATION = 'GDEF_LOG', )

# Know issues

The Code_Aster team uses the bitbucket forge:

https://bitbucket.org/code_aster/codeaster-src

This section reports all the issues are related to MFront. The number of the ticket are the one used by the bitbucket forge.

## Ticket #92: SIMO_MIEHE with MFront (Solved in Code_Aster 13.4)

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:

RESU1=STAT_NON_LINE(...
NEWTON=_F(PREDICTION = 'EXTRAPOLE',
...

For more details, see https://bitbucket.org/code_aster/codeaster-src/issues/92/simo_miehe-with-mfront.

## Ticket #93: Better support of external state variables for MFront behaviours

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.

## Ticket #96: MFront small strain behaviours and GROT_GDEP

MFront small strain behaviours are not usable with GROT_GDEP due to a meaningless restriction.

## Ticket #97: MFront finite strain behaviours and GROT_GDEP

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 Code_Aster side.

## Ticket #98: 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.

Whether a MFront behaviour is a finite or small strain behaviour shall be checked by Code_Aster. This piece of information is given by the _BehaviourType symbol exported in the library.

A small strain behaviour shall be usable in the small strain assumption and with the GROT_GDEP and 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.

## Ticket #99: 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:

mfront --@MaterialProperty="real fake1" --@MaterialProperty="real fake2" ...

## Ticket #100: MFront: restrict the finite strain strategies usable

For small strain behaviours, MFront 3.1 provides a keyword (@FiniteStrainStrategy) stating which finite strain strategy (GROT_GDEP or GDEF_LOG) has been used for the behaviour identification.

Developments in Code_Aster are required to read this information and check proper usage of the behaviour.

## Ticket #101: MFront: the library name containing officially supported behaviours is the same as the default library name generated by MFront (Solved in Code_Aster 13.4)

By default (if neither the @Library nor the @Material keywords are used), MFront generates a library called libAsterBehaviour.so.

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

## Ticket #103: 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 as_run).

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 TFEL/System library. Code_Aster already modifies the epsilon parameter if needed.

# References

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.