Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
3 Quelques conseils préalables
Version default
Date :
16/02/2011
Page :
6/21
Clé :
U2.08.06
Révision :
5559
On formule ici quelques conseils pour aider l'utilisateur à tirer parti des stratégies de calcul
parallèle du code. Mais il faut bien être conscient, qu'avant tout chose, il faut d'abord optimiser et valider son calcul séquentiel en tenant compte des conseils qui fourmillent dans les documentations des commandes. Pour ce faire, on utilise, si possible, un maillage plus grossier et/ou on n'active que quelques pas de temps.
Le paramétrage par défaut et les affichages/alarmes du code proposent un fonctionnement
équilibré et instrumenté. On liste ci-dessous et, de manière non exhaustive, plusieurs questions qu'il est intéressant de se poser lorsqu'on cherche à paralléliser son calcul. Bien sûr, certaines questions
(et réponses) sont cumulatives et peuvent donc s'appliquer simultanément.
3.1
Préambule
Il est intéressant de valider, au préalable, son calcul parallèle en comparant quelques itérations en mode séquentiel et en mode parallèle. Cette démarche permet aussi de calibrer les gains
maximums atteignables (speed-up théoriques) et donc d'éviter de trop «gaspiller de processeurs».
Ainsi, si on note
f
la portion parallèle du code (déterminée par exemple via un run séquentiel préalable), alors le speed-up théorique formule d'Amdhal (cf. [R6.01.03] §2.4) :
S
p
maximal accessible sur
S p
=
1
1− f
f p
p
processeurs se calcule suivant la
Par exemple, si on utilise le parallélisme MUMPS distribué par défaut (scénarios 1b+2b) et que les
étapes de construction/résolution de système linéaire représentent 90% du temps séquentiel ( f
=0.90), le speed-up théorique est borné à la valeur
S
∞
=
1
1−0.90.9/ ∞
=
10
! Et ce, quelque soit le nombre de processus MPI alloués.
Il est intéressant d'évaluer les principaux postes de consommation (temps/RAM) : en mécanique quasi-statique, ce sont généralement les étapes de calculs élémentaires/assemblages, de
résolution de système linéaire et les algorithmes de contact-frottement. Mais leurs proportions dépendent beaucoup du cas de figure (caractéristiques du contact, taille du problème, complexité des lois matériaux...). Si les calculs élémentaires sont importants, il faut les paralléliser via la scénario 1b
(scénario par défaut). Si, au contraire, les systèmes linéaires focalisent l'essentiel des coûts, les scénarios 2a ou 2b peuvent suffire. Par contre, si c'est le contact-frottement qui dimensionne le calcul, il faut chercher à optimiser son paramétrage et/ou paralléliser son solveur linéaire interne (cf. méthode
GCP+MUMPS).
Pour optimiser son calcul parallèle, il faut surveiller les éventuels déséquilibres de charge du flot de données (CPU et mémoire) et limiter les surcoûts dus aux déchargements mémoire (JEVEUX et
MUMPS OOC) et aux archivages de champs. Sur le sujet, on pourra consulter la documentation
[U1.03.03] «Indicateur de performance d'un calcul (temps/mémoire)». Elle indique la marche à suivre pour établir les bons diagnostics et elle propose des solutions.
Quelques chiffres empiriques: on conseille d'allouer au moins 20 000 degrés de liberté par processus MPI; Un calcul thermo-mécanique standard bénéficie généralement, sur 32 processeurs, d'un gain de l'ordre de la dizaine en temps elapsed et d'un facteur 4 en mémoire RAM.
3.2
Calculs indépendants
Lorsque la simulation que l'on souhaite effectuer se décompose naturellement (étude paramétrique, calcul de sensibilité...) ou, artificiellement (chaînage thermo-mécanique particulier...), en calculs similaires mais indépendants, on peut gagner beaucoup en temps calcul grâce au parallélisme numérique 1a.
Manuel d'utilisation
Document diffusé sous licence GNU FDL (http://www.gnu.org/copyleft/fdl.html)
Fascicule u2.08 : Fonctions avancées et contrôle des calculs
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
3.3
Gain en mémoire RAM
Version default
Date :
16/02/2011
Page :
7/21
Clé :
U2.08.06
Révision :
5559
Lorsque le facteur mémoire dimensionnant concerne la résolution de systèmes linéaires (ce qui est souvent le cas), le cumul des parallélismes informatiques 1b (calculs élémentaires/assemblages) et
numériques 2b (solveur linéaire distribué MUMPS) est tout indiqué 3 .
Une fois que l'on a distribué son calcul Code_Aster+MUMPS sur suffisamment de processeurs, les consommations RAM de JEVEUX peuvent devenir prédominantes (par rapport à celles de MUMPS que l'on a étalées sur les processeurs). Pour rétablir la bonne hiérarchie (le solveur externe doit supporter le pic de consommation RAM !) il faut activer, en plus, l'option SOLVEUR/MATR_DISTRIBUEE
[U4.50.01].
Pour résoudre des problèmes frontières de très grandes tailles (
5.10
6
degrés de liberté), on peut aussi essayer les solveurs itératifs/hybride parallèles (stratégies parallèles 2c/3a ).
3.4
Gain en temps
Si l'essentiel des coûts concerne uniquement les résolutions de systèmes linéaires on peut se contenter d'utiliser les solveurs linéaires MUMPS en mode centralisé (stratégie 2b) ou MULT_FRONT
(2a). Dès que la construction des systèmes devient non négligeable (>5%), il est primordial d'étendre le périmètre parallèle en activant la distribution des calculs élémentaires/assemblages (1b) et en passant à MUMPS distribué (valeur par défaut).
Sur des problèmes frontières de grandes tailles (
10
6
degrés de liberté), une fois les bons
paramètres numériques sélectionnés 4 (préconditionneur, relaxation... cf. [U4.50.01]), les solveurs
itératifs/hybride parallèles (2c/3a) peuvent procurer des gains en temps très appréciables par rapport
aux solveurs directs génériques (2a/2b). Surtout si les résolutions sont relaxées 5 car, par la suite, elles
sont corrigées par un processus englobant (algorithme de Newton de THER/STAT_NON_LINE...).
3 Pour baisser les consommations mémoire de MUMPS on peut aussi jouer sur d'autres paramètres : OOC et relaxation des résolutions [U4.50.01].
4 Il n'y a par contre pas de règle universelle, tous les paramètres doivent être ajustés au cas par cas.
5 C'est-à-dire que l'on va être moins exigeant quant à la qualité de la solution. Cela peut passer par un critère d'arrêt médiocre, le calcul d'un préconditionneur frustre et sa mutualisation durant plusieurs résolutions de système linéaire... Les fonctionnalités des solveurs non linéaires et linéaires de Code_Aster permettent de mettre en œuvre facilement ce type de scénarios.
Manuel d'utilisation Fascicule u2.08 : Fonctions avancées et contrôle des calculs
Document diffusé sous licence GNU FDL (http://www.gnu.org/copyleft/fdl.html)
