# Implantation de lois de comportement mécanique à l'aide de MFront: simplicité, efficacité, robustesse et portabilité

Thomas Helfer, Jean-Michel Proix, Olivier Fandeur

► To cite this version:

Thomas Helfer, Jean-Michel Proix, Olivier Fandeur. Implantation de lois de comportement mécanique à l'aide de MFront: simplicité, efficacité, robustesse et portabilité. 12e Colloque national en calcul des structures, CSMA, May 2015, Giens, France. hal-01706198

HAL Id: hal-01706198

https://hal.science/hal-01706198v1

Submitted on 10 Feb 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Implantation de lois de comportement mécanique à l'aide de MFront :
simplicité, efficacité, robustesse et portabilité

T. Helfer<fnref n="1" />, J.M. Proix<fnref n="2" />, O. Fandeur<fnref n="3" />,<fnref n="4" />

**Résumé** — Ce papier est dédié au générateur de code open-source nommé MFront [6]. Plusieurs langages dédiés (domain specific languages), basés sur le C++ [23], permettent d'écrire de manière simple, compacte, efficace et robuste, l'implantation de lois de comportement mécanique. Après une vue d'ensemble, nous décrivons certaines des techniques de programmation utilisées. Nous présentons ensuite divers algorithmes permettant d'accroître la robustesse des schémas d'intégration implicites. Enfin, nous discutons certaines questions liées à la portabilité des implantations entre différents codes.

## 1 Introduction

Le projet PLEIADES vise à fournir une plate-forme unifiée de développement des applications de simulation des éléments combustible nucléaires du CEA et d'EDF [19]. Au sein de ce projet, le générateur de code MFront permet de traiter les aspects liés à l'écriture et la capitalisation des connaissances matériau dans un cadre d'assurance qualité strict. MFront s'est ensuite révélé utile hors du domaine combustible, notamment pour les utilisateurs des codes Cast3M [5], Code Aster [8] et AMITEX FTT [4]. Une interface pour le code ZeBuLoN [2] est également disponible. MFront a été mis en open-source en octobre 2014 dans l'espoir d'être utile aux ingénieurs et chercheurs de la communauté des matériaux et/ou du calcul de structure.

L'écriture de lois de comportement mécanique, par nature complexe, a un impact fort sur les temps de calcul et fait donc l'objet d'une attention particulière. MFront propose plusieurs langages dédiés aux lois de comportement mécanique (appelés domain specific languages) sur la base du C++ : certains sont dédiés à des formalismes spécifiques (lois de viscoplasticité ou plasticité isotropes), d'autres aux schémas d'intégration en vitesse et les derniers aux schémas d'intégration implicites.

La première section de ce document propose une vue d'ensemble de MFront.

La seconde met en avant une partie des techniques utilisées pour atteindre des performances numériques élevées. Nous concluons cette section par donner quelques éléments issus d'un benchmark comparant les lois générées via MFront aux lois natives du Code Aster.

La troisième section de ce document est dédiée à l'augmentation de la robustesse des algorithmes implicites. Nous y décrivons différents algorithmes introduits dans MFront.

La quatrième section de ce document décrit certaines questions liées à la portabilité de l'implantation d'une loi de comportement. Nous considérerons les codes Cast3M, Code Aster et ZeBuLoN [18]. Nous traiterons différents points liés aux stratégies de convergence utilisées par ces codes (choix de l'opérateur tangent) ou la gestion des contraintes planes.

## 2 Vue d'ensemble de MFront

Cette section donne une vue d'ensemble de MFront. Nous y décrivons un exemple très simple, puis nous présentons les différents algorithmes numériques disponibles avant d'aborder la notion d'interface.

<footnote n="1">¹ CEA, DEN/DEC, Département d'Études des Combustibles, thomas.helfer@cea.fr</footnote>

<footnote n="2">² EDF R&D, Département Analyses Mécaniques et Acoustique, jean michel.proix@edf.fr</footnote>

<footnote n="3">³ CEA, DEN/DM2S, Département de Modélisation des Systèmes et des Structures, olivier.fandeur@cea.fr</footnote>

<footnote n="4">⁴ IMSIA, UMR 8193, CNRS EDF CEA ENSTA</footnote>
```c
@Parser IsotropicPlasticMisesFlow: //< domain specific language
@Behaviour Plasticity: //< name of the behaviour
@Parameter H 22e9: //< hardening slope
@Parameter s0 200e6: //< elasticity limit
@FlowRule{
    f      seq-H*p-s0;
    df_dseq 1;
    df DP -H;
}
```

<caption>FIGURE 1 – Implantation d'une loi de comportement plastique avec un écrouissage isotrope.</caption>

## 2.1 Un premier exemple

La figure 1 décrit un fichier d'entrée utilisé par `MFront` pour implanter une loi de comportement plastique avec un écrouissage isotrope. Il s'agit d'un exemple d'un langage dédié à un type de loi particulier qui souligne qu'un des buts de `MFront` est de permettre une implantation de loi de comportement sous la forme la plus simple et la plus compacte possible.

Ce fichier est converti en sources C++ formant un total de plus de 1500 lignes qui gèrent :

- l'algorithme d'intégration, tel que décrit par SIMO et HUGUES (réduction à une équation scalaire) [22];

- le calcul de l'opérateur tangent cohérent [21];

- dans le cadre d'une adhérence au code `Cast3M` (voir la notion d'interface ci-dessous), le traitement des contraintes planes et/ou le passage en grandes transformations suivant différents formalismes dont les déformations logarithmiques [15]. En effet, ces points doivent actuellement être gérés au niveau de la loi de comportement dans `Cast3M` alors que les codes `Code Aster` et `ZeBuLoN` proposent des solutions génériques en amont et/ou en aval de la loi de comportement. Ce point est discuté en section 5.

Les sources générées sont essentiellement des classes `template` paramétrées par l'hypothèse de modélisation et le type numérique utilisé (simple, double ou quadruple précision). Les techniques d'optimisation présentées plus loin (section 3) permettent d'obtenir, pour chaque hypothèse de modélisation, un code optimisable par le compilateur : il n'y a, par exemple, aucune allocation dynamique ni aucune boucle dans les opérations tensorielles.

## 2.2 Algorithmes numériques disponibles

`MFront` dispose de nombreux algorithmes d'intégration. On distingue deux classes d'algorithmes [3] :

- ceux basés sur un schéma d'intégration explicite de type `Runge Kutta`;

- ceux basés sur un schéma d'intégration implicite.

La question de la robustesse des algorithmes implicites est traitée en section 4.

## 2.3 Interfaces

La notion d'interface dans `MFront` permet de générer un code spécifique au code cible. Il existe aujourd'hui des interfaces pour les codes aux éléments finis `Cast3M` [5], `Code Aster` [8] et `ZeBuLoN` [18] et l'application combustible `Cyrano3` [24]. L'interface au code aux éléments finis `Cast3M` a été reprise par le solveur FFT massivement parallèle `AMITEX FTT` [4].

# 3 Efficacité du code généré grâce aux techniques de programmation utilisées

Cette section s'intéresse à la question de l'efficacité du code généré. Un benchmark permet de montrer que malgré le caractère générique et multi-code, les performances obtenues sont satisfaisantes. La seconde partie décrit une partie des techniques utilisées pour obtenir ce résultat.
<table><caption>TABLE 1: Quelques exemples issus du benchmark comparant, dans Code Aster, les performances du code généré par MFront aux lois natives de ce code.</caption><thead><tr><th>Description</th><th>Algorithme</th><th>Temps CPU total (Aster vs MFront)</th><th>Illustration</th></tr></thead><tbody><tr><td>Visco-plastic and damaging for steel [10, 17]</td><td>Implicit</td><td>17mn43s vs 7mn58s</td><td></td></tr><tr><td>Damaging for concrete ([12, 13])</td><td>Default</td><td>45mn vs 63mn</td><td></td></tr><tr><td>Generic Single crystal viscoplasticity ([9, 14])</td><td>Implicit</td><td>28mn vs 24mn</td><td></td></tr><tr><td>FCC single crystal viscoplasticity ([9, 16])</td><td>Implicit</td><td>33m54s vs 29m30s</td><td></td></tr><tr><td>FCC homogenized polycrystals 30 grains ([1, 9])</td><td>Runge Kutta 4/5</td><td>9s67 vs 8s22</td><td></td></tr><tr><td>Anisotropic creep with phase transformation ([11])</td><td>Implicit</td><td>180s vs 171s</td><td></td></tr></tbody></table>

<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /></figure>

<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /></figure>

<figure><img src="image_7.png" /></figure>

## 3.1 Benchmark

Le tableau 1 présente un extrait d'un benchmark réalisé par l'équipe de Code Aster comparant les performances du code généré par MFront aux lois natives de ce code.

On remarque que les lois générées par MFront sont en général compétitives avec les implantations natives<fnref n="1" />. L'un des intérêts forts de MFront est le temps de développement de ces lois de l'ordre de la journée.

<footnote n="1">1. Parmi les cas présentés, nous voyons que l'utilisation de la loi native de Mazars est nettement plus efficace. Ceci est en partie dû au fait qu'il s'agit d'une loi explicite : le temps passé dans la loi est inférieur au temps nécessaire au branchement de la loi (l'appel à la loi native est plus « direct »). Un travail est en cours pour réduire ce temps de branchement.</footnote>
## 3.2 Template metaprogramming, expression templates et concepts

L'utilisation d'un générateur de code permet de masquer l'emploi de techniques de programmation avancées proposées par le langage C++, qui sont d'un accès difficile même pour des développeurs aguerris. Elles sont cependant une des clés pour obtenir des implantations numériquement efficaces.

<figure><img src="image_8.png" /><figcaption>FIGURE 2 – Évolution du résidu en fonction du nombre d'itérations : échec de l'algorithme de NEWTON et emploi de stratégies alternatives.</figcaption></figure>

# 4 Robustesse de l'intégration implicite

Le schéma d'intégration implicite est privilégié. Cependant, l'algorithme de NEWTON généralement utilisé pour résoudre le système non-linéaire qui en résulte peut manquer de robustesse, ce que nous avons illustré sur la figure 2 dans le cas d'une loi de comportement cristalline en grandes déformations.

L'utilisation de diverses modifications et stratégies alternatives à l'algorithme de NEWTON, notamment en réduisant la taille des corrections faites à chaque itération de l'algorithme, ou en considérant les algorithmes « en patte de chien » de POWELL ou l'algorithme de LEVENBERG-MARQUARDT [7, 20], est illustrée.

# 5 Sur l'écriture portable et efficace d'une loi comportement mécanique

Bien que la notion d'interface évoquée plus haut permette de se brancher à différents codes, ceux-ci présentent des particularités notamment liées aux algorithmes d'équilibre disponibles.

Dans le cadre de ce papier, nous proposons un survol à (très) grosses mailles de certaines de ces particularités dans le cas des codes Cast3M, Code Aster et ZeBuLoN : nous décrivons le traitement des contraintes planes et le calcul de l'opérateur tangent, si le code le nécessite.

# Remerciements

Le développement de MFront a été soutenu par le projet PLEIADES, co-développé par le CEA, EDF et AREVA, et le projet Simu Meca2015 d'EDF R&D. Les auteurs remercient Jacques BESSON et Stéphane QUILICI pour le temps qu'ils nous ont consacré lors de l'écriture de l'interface zmat dédiée au code aux éléments finis ZeBuLoN.