This page introduces the MFrontGallery project whose latest version is available at: https://github.com/thelfer/MFrontGallery
This project has two main almost orthogonal goals:
MFront, able to meet the requirements of safety-critical studies as discussed in Section 1.2.The distinction between those two approaches is profound and discussed in depth in Sections 1 and 2.
While the first goal is common to all (mechanical) solvers, one originality of the MFrontGallery project is to address the second goal.
The MFrontGallery project also contains various high-quality MFront implementations. Those implementations may originate from the MFront tutorials, i.e. the MFront gallery page (hence the name of the project). This project is also meant to store various contributions of academic or industrial users of MFront willing to share their material knowledge and also benefit from the continuous integration process to guarantee that no regression would happen as MFront evolves.
The
MFrontGalleryandMFrontMaterialsprojectsThe
MFrontGalleryproject is the open-source counterpart of theMFrontMaterialsproject (called internallymfm).MFrontMaterialsis used for material knowledge management by the fuel performance codes developped on top of thePLEAIDESplatform [1, 2] and results from a common effort of CEA and its industrial partners EDF and Framatome. See the faq for details about the relation between those two projects.As both projects shares the same
cmakeinfrastructure, the namemfmor references to theMFrontMaterialsproject may appear in function names, documentation, examples, etc.
In particular, the project provides:
cmake infrastructure that can be duplicated in (academic or industrial) derived projects. This infrastructure allows:
MFront sources using all interfaces supported by MFront. For example, concerning behaviours, the behaviours can be compiled for the following solvers: Cast3M, code_aster, Europlexus, Abaqus/Standard, Abaqus/Explicit, Ansys, AMITEX_FFTP, CalculiX, ZSet, DIANA FEA. Thanks to the generic interface, those behaviours are also available in all solvers using the MFrontGenericInterfaceSupport projet (MGIS), including: OpenGeoSys, MFEM-MGIS, MANTA, mgis.fenics, MoFEM, XPER, etc.MTest. Those unit tests generate XML result files conforming to the JUnit standard that can readily be used by continuous integration platforms such as jenkins.MFrontGallery.MFront implementationsMFront implementations.Section 1 discusses why a new approach to material knowledge management is needed in the context of safety criticial studies.
Section 2 describes some typical use case of projects derived from MFrontGallery.
Section 3 discusses how MFront implementations are stored in the project.
Section 4 provides a short overview of the usage of the project.
Numerical simulations of solids are based on the description of the evolution of the thermodynamical state of the materials of interest. In the context of the MFrontGallery project, this thermodynamical state is described at each point of space by a set of internal state variables which can evolve with time due to various physical phenomena (plasticity, viscoplaticity, damage, phase change, swelling due to dessication, etc.).
The knowledge that one may have about a given material can be represented in different forms. Here, the following categorization is employed:
The MFrontGallery project has been developed to address various issues related to material knowledge management for safety-critical studies:
MFront source file, the MFrontGallery can generate shared libraries for all the solvers of interest.MFront.MFront implementations can be classified in two main categories:
An alternative way of expressing the disctinction between self-contained and generic implementations is to consider that generic implementations only describe a set of constitutive equations while self-contained implementations describes a set of constitutive equations and the material coefficients identified on a well-defined set of experiments for a particular material.
In practice, the physical information contained in self-contained implementations may be more complex than a set of material coefficients. For example, the Young modulus of a material may be defined by an analytical formula and can’t thus be reduced to a set of constants. This analytical formula shall be part of a self-contained mechanical behaviour implementation. Of course, this analytical formula could be included in the set of constitutive equations and parametrized to retrieve a bit of genericity. In our experience, such a hybrid approach is fragile, less readable and and cumbersome. Moreover it does not address the main issue of generic behaviours which is the management of the physical information in a reliable and robust way.
Introducing generic implementations in solvers can be very useful for rapid prototyping by the end-users. They can also be useful for behaviours with little specificity (e.g. linear elasticity, von Mises plasticity) often used in general analyses relying on a more frequent and ad-hoc re-parameterization. However, such generic implementations raise the issue of how to manage the physical information used in engineering studies, particularly safety-critical ones.
For the sake of simplicity, we will first consider the case where the solver provide all the generic implementations required by the users and discuss in a second case the situation of external implementations (such as UMAT behaviours in Abaqus).
Most commonly, the physical information will be in the input file of the considered solver, generally in a section dedicated to the definition of the materials.
But the input files not only contain that physical information but also the boundary conditions, load step information, numerical parameters, discretization information, etc. for the simulation it is meant to describe.
When a new simulation is considered, physical information, i.e. the material definition section, is often copy-pasted to a new input file.
Such input files are also generally shared by engineers which will modify them to their own needs.
Things get even worse if this physical information must be shared with another team which uses a different solver. In general, the physical information is manually adapted to input file format of the new solver, an operation which is error-prone for a large number of reasons, including non-consistent parameter definitions, unit conversions, or plain-and-simple copy errors.
In the end, our experience shows that it is practically impossible to track physical information reliably in this way, particularly if the knowledge of the materials evolves over time.
A more elaborate solution consists in splitting the input file in multiple ones and separating the material declarations from the rest. One can thus maintain a database of ready-to-use material definitions.
A variant of this approach is to have specific keywords allowing to request specific material definitions.
In each case, the physical information is associated to a label. If this information evolves, one may just have to create a new label.
The solution is elegant and the physical information is no longer duplicated with every change of geometry or boundary conditions.
However, this approach still has severe drawbacks:
According to the experience of the authors, a rigorous material knowledge management suitable for safety-critical studies is only possible if self-contained implementations are considered.
MFrontGallery projectThe MFrontGallery is based on the assumption that the solvers of interest (note the plural) can use shared libraries generated by the MFront code generator [3, 4].
This assumption allows to decouple the material knowledge management from the development (source code) of the solvers of interest.
However, an important argument in favor of generic implementation is code-reuse. MFront provides several techniques to facilitate code factorisation between implementations as described in the “Best practices” page
MFrontGalleryThe cmake infrastructure derived from MFrontGallery is meant to be reused in derived projects. The creation of a derived projet is described in depth on this page.
The cmake infrastructure is documented on this page.
This sections highlight two typical usage of projects derived from MFrontGallery:
In both cases, we highly recommend reading the best practices page.
Self-contained implementations are stored in the materials directory. Under this directory, implementations are stored by material and by kind (material property, behaviour or model), as follows:
materials/
├── Bentonite
│ └── behaviours
│ └── include
├── Concrete
│ └── behaviours
├── CrushedSalt
│ └── behaviours
├── VanadiumAlloy
│ ├── behaviours
│ └── properties
└── Wood
└── behavioursGeneric implementations are stored in the generic-behaviours directory. Under this directory, the implementations are more or less arbitraly classified by the main phenomenon described, as follows:
generic-behaviours/
├── damage
├── damage_viscoplasticity
├── finitestrainsinglecrystal
├── heattransfer
├── hyperelasticity
├── hyperviscoelasticity
├── nonlinearelasticity
├── plasticity
├── viscoelasticity
└── viscoplasticityThese generic implementations have been introduced in the MFrontGallery project to:
̀MFront evolves.After downloading or cloning the sources of the MFrontGallery project, a typical usage of the project is divided in four steps (common to most cmake projects):
** Cloning the
masterbranch of theMFrontGalleryproject**The
masterbranch of theMFrontGalleryproject can be cloned as follows:$ git clone https://github.com/thelfer/MFrontGallery
The sources are assumed to be in the MFrontGallery directory. While not strictly required, it is convienient to create a build directory (here, at the same level as the MFrontGallery directory):
$ mkdir build
$ cd buildThe configuration step is triggered by calling cmake, e.g.:
$ cmake ../MFrontGallery/ -DCMAKE_BUILD_TYPE=Release \
-Denable-generic-behaviours=ON -Denable-ansys=ONThe interfaces are selected by a set of cmake flags prefixed by enable. In the previous command, we only selected the generic and ansys interfaces.
TFELexecutablesBy default, the configuration step assumes that the various binaries provided by the
TFELproject (includingmfront) can be found in the current environment. See the installation guide for details.
The complete set of available flags are described in the installation guide.
The outputs of the previous command shows the generated libraries and their contents:
-- Adding library : HeatTransferBehaviours-generic (/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/StationaryLinearHeatTransfer-generic.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/StationaryLinearHeatTransfer.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/StationaryNonLinearHeatTransfer-generic.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/StationaryNonLinearHeatTransfer.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/TransientLinearHeatTransfer-generic.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/TransientLinearHeatTransfer.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/TransientNonLinearHeatTransfer-generic.cxx;/home/th202608/codes/MFrontGallery/master/src/build3/generic-behaviours/heattransfer/generic/src/TransientNonLinearHeatTransfer.cxx)Some MFront files are not compatible with the selected interface. For example, the ansys interface only supports small and finite strain behaviours. Generalized behaviours are then discarded as shown by the following ouptut:
-- StationaryLinearHeatTransfer has been discarded for interface ansys (unsupported behaviour type)
-- StationaryNonLinearHeatTransfer has been discarded for interface ansys (unsupported behaviour type)
-- TransientLinearHeatTransfer has been discarded for interface ansys (unsupported behaviour type)
-- TransientNonLinearHeatTransfer has been discarded for interface ansys (unsupported behaviour type)The selected libraries can be built as follows:
$ cmake --build . --target allVarious targets are avaiable.
Unit tests can be executed as follows:
$ cmake --build . --target checkA summary of the executed tests and their status is displayed, as follows:
Test project /home/th202608/codes/MFrontGallery/master/src/build3
Start 1: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_UpWard_mtest
1/8 Test #1: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_UpWard_mtest ......... Passed 0.02 sec
Start 2: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_DownWard_mtest
2/8 Test #2: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_DownWard_mtest ....... Passed 0.02 sec
Start 3: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_ToNearest_mtest
3/8 Test #3: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_ToNearest_mtest ...... Passed 0.02 sec
Start 4: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_TowardZero_mtest
4/8 Test #4: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_ansys_TowardZero_mtest ..... Passed 0.02 sec
Start 5: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_UpWard_mtest
5/8 Test #5: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_UpWard_mtest ....... Passed 0.02 sec
Start 6: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_DownWard_mtest
6/8 Test #6: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_DownWard_mtest ..... Passed 0.02 sec
Start 7: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_ToNearest_mtest
7/8 Test #7: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_ToNearest_mtest .... Passed 0.02 sec
Start 8: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_TowardZero_mtest
8/8 Test #8: SemiImplicitModifiedCamClay_OpenGeoSys2020_Triax_generic_TowardZero_mtest ... Passed 0.02 sec
100% tests passed, 0 tests failed out of 8
Total Test time (real) = 0.13 sec
Built target checkThe built shared libraries can be installed as follows:
$ cmake --build . --target installThe MFrontGallery project has been developed by CEA, EDF and Framatome as part of a common effort to build a common and robust material knowledge management strategy to back safety-critical studies which meet the quality requirements imposed by the French Safety Authority (ANS).