This document specifies how an MFront behaviour is stored in a MADNEX file and discusses how information about such an MFront behaviour can be queried using mfront-query and compiled using mfront.

Figure 1: Hierarchy of a MADNEX file
Figure 1: Hierarchy of a MADNEX file

Figure 1 shows how material knowledge implementation are stored in a madnex file. Three kinds of material knowledge implementations are supported:

For the sake of simplicity, only behaviours are considered in the rest of this document.

This hierarchy is the same of the one adopted in the MFrontMaterials project.

About material identifiers

As depicted on Figure 1, MFront implementations are stored under the MFront group. Then the implementations are sorted using a material identifier. This material identifier is optional and behaviours may be directly stored in a Behaviours group directly under the MFront group1.

Material identifiers must conform the restrictions imposed by MFront 2.

About behaviour identifiers

Behaviour identifiers must be unique and follow the restrictions of the behaviour names imposed by MFront3.

Global identifier

The combination of material identifier and behaviour identifier shall result in a unique identifier. A madnex file containing two material knowledge with the same identifiers is ill-formed.

Group associated with a behaviour

The identification a behaviour starts from an existing implementation file whose parameters or material properties are fitted to adjust experimental data. The structure of the group associated with a behaviour reflects this.

The source data set (required)

The group associated with a behaviour shall contains a data set called source storing an MFront implementation. This implementation serves as the basis for building the final behaviour, which means that the information it contains may be overridden by information retrieved in the other data set of the group.

The metadata data set (optional)

The metadata data set is a compound which may alter the meta data of the MFront implementation. The following entries are allowed, but not required:

The parameters data set (optional)

The parameters data set allows:

The parameters names must be a subset of the parameters or material properties defined in the source data set.

The bounds data (optional)

The bounds data shall reflect the domain over which the identification is assumed to be valid.

  1. This implies that Behaviours, Material Properties and MOdels can’t be used as material identifiers.↩

  2. See the documentation of the @Material keyword. Those restrictions mostly states that the material’ name must be a valid C++ identifier.↩

  3. See the documentation of the @Behaviour keyword. Those restrictions mostly states that the behaviour’ name must be a valid C++ identifier.↩