Amélioration du parallélisme dans Code_Aster grâce au solveur linéaire MUMPS

Dans le cadre des simulations thermo-mécaniques avec Code_Aster, l’essentiel des coûts calcul
provient de la construction et de la résolution des systèmes linéaires. Ces systèmes sont
souvent enfouis au plus profond d’autres algorithmes ou méthodes d’analyse : schéma non-linéaire,
intégration en temps, analyse modale… Pour améliorer les performances de ces étapes, Code_Aster
propose plusieurs stratégies :

• Un "parallélisme informatique" mis en œuvre pour distribuer des calculs Aster indépendants (plusieurs fichiers de commande) ou distribuer des calculs élémentaires et, éventuellement, les assemblages matriciels/vectoriels associés (au sein d’un même fichier de commande).

• Un "parallélisme numérique" mise en œuvre dans les algorithmes de résolution de système linéaire (multifrontale Aster en OpenMP[R6.02.02], le produit MUMPS[R6.02.03] et librairie PETSc[R6.01.02] en MPI).

• Un "parallélisme plus mécanique" avec la méthode de décomposition de domaine FETI[R6.01.03] ou, prochainement, un préconditionneur multigrille adapté aux modélisations du code. Ces fonctionnalités restent encore du domaine de la recherche.

Ces différents niveaux de parallélisme peuvent éventuellement se cumuler pour gagner en efficacité et/ou accroître le portion parallélisée d’un calcul. Cette distribution des données (et donc de leurs
traitements associés) entre les processeurs permet ainsi gagner en "temps elapsed" d’exécution et en quantité de mémoire RAM requise par processeur.

Actuellement un chantier logiciel important concerne l’intégration la plus optimale et la plus large possible du solveur direct MUMPS.

EDF R&D collabore d’ailleurs activement avec l’équipe de développement du produit (notamment via l’ANR SOLSTICE). En améliorant le couplage
Code_Aster/MUMPS et en upgradant la version de MUMPS (de la 4.7.3 à la 4.8.4), des gains appréciables ont pu être dégagés en consommation RAM par processeurs (en dizaines de pourcents).
Et ce, sans trop pénaliser les temps d’exécution. Ceux-ci sont dégradés de seulement quelques pourcents suivant la bande passante des disques et suivant l’importance de la phase de descente-remontée dans le calcul total (cf. figures).

D’autre part cette nouvelle version de MUMPS corrige quelques bugs liés à ses déchargements sur disque des blocs de la matrice factorisée (mot-clé Aster SOLVEUR/OUT_OF_CORE=’OUI’) et elle homogénéifie les pré-traitements qui sont opérés sur la matrice suivant les modes d’utilisation de MUMPS (notamment la phase de scaling ; mot-clé SOLVEUR/PRETRAITEMENTS).

Exemples, avec M pour millions de termes, N la taille du problème, nnz le nombre de termes non nuls de la matrice et Kfact celui de sa factorisée renumérotée (via METIS). Cas-tests canonique (cube) et plus industriel (cuve simplifiée de l’étude Epicure) exploités sur la machine Aster. A titre de comparaison : le solveur linéaire de référence (la multifrontale Aster) consomme en séquentiel, respectivement, pour le cube 900Mo/248s et, pour EPICURE, 4750Mo/3800s.

Désormais MUMPS est utilisé quotidiennement sur des études (rupture, THM…) non seulement pour exploiter ses fonctionnalités numériques avancées (pivotage, estimation d’erreurs, raffinement itératif) mais aussi (et surtout), pour gagner en temps d’exécution et en mémoire RAM grâce au parallélisme et à l’Out-Of-Core.