Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
8/21
Clé :
U2.08.06
Révision :
5559
4 Parallélismes informatiques
4.1
Rampes de calculs indépendants
Utilisation : grand public via Astk.
Périmètre d'utilisation : calculs indépendants (paramétrique, étude de sensibilité...).
Nombre de processeurs conseillés : limite de la machine/gestionnaire batch.
Gain : en temps CPU.
Speed-up : proportionnel au nombre de cas indépendants.
Type de parallélisme : script shell.
Scénario : 1a du §3. Cumul avec toutes les autres stratégies de parallélisme licite mais s'adressant à des utilisateurs avancés (hors périmètre d'Astk).
L'outil Astk permet d'effectuer toute une série de calculs similaires mais indépendants (en séquentiel et surtout en parallèle MPI). On peut utiliser une version officielle du code ou une surcharge privée préalablement construite. Les fichiers de commande explicitant les calculs sont construits
dynamiquement à partir d'un fichier de commande «modèle» et d'un mécanisme de type
«dictionnaire» : jeux de paramètres différents pour chaque étude (mot-clé VALE du fichier .distr), blocs de commandes Aster/Python variables (PRE/POST_CALCUL)...
Le lancement de ces rampes parallèles s'effectue avec les paramètres de soumission usuels d'Astk.
On peut même re-paramétrer la configuration matérielle du calcul (liste des nœuds, nombre de cœurs, mémoire RAM totale par nœud...) via un classique fichier .hostfile.
Pour plus d'informations sur la mise en oeuvre de ce parallélisme, on pourra consulter la documentation d'Astk U1.04.00.
Remarques :
•
Avant de lancer une telle rampe de calculs, il est préférable d'optimiser au préalable sur une
étude type, les différents paramètres dimensionnants : gestion mémoire JEVEUX, aspects solveurs non linéaire/modaux/linéaire, mot-clé ARCHIVAGE, algorithme de contactfrottement... (cf. doc. U1.03.03 sur les performances, U4.50.01...).
•
On peut facilement écrouler une machine en lançant trop de calculs vis-à-vis des ressources disponibles. Il est conseillé de procéder par étapes et de se renseigner quant aux possibilités
d'utilisations de moyens de calculs partagés (classe batch, gros jobs prioritaires...).
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
Version default
Date :
16/02/2011
Page :
9/21
Clé :
U2.08.06
Révision :
5559
4.2
Calculs élémentaires et assemblages
Utilisation : grand public via Astk.
Périmètre d'utilisation : calculs comportant des calculs élémentaires/assemblages coûteux
(mécanique non linéaire).
Nombre de processeurs conseillés : 4 ou 8. Couplé avec le parallélisme distribué de MUMPS (valeur par défaut), typiquement 16 ou 32.
Gain : en temps voire en mémoire avec solveur linéaire MUMPS (si MATR_DISTRIBUEE) ou FETI.
Speed-up : Gains variables suivant les cas (efficacité parallèle 6
granularité pour que ce parallélisme reste efficace : 5.10
4
>50%). Il faut une assez grosse
degrés de liberté par processeur.
Type de parallélisme : MPI.
Scénario: 1b du §3. Nativement conçu pour se coupler aux parallélismes numériques 2b (via Astk).
Cumul avec toutes les autres stratégies de parallélisme licite. Cumul 1b+3a intrinsèque.
4.2.1 Mise en oeuvre
Désormais, la mise en œuvre du parallélisme dans les opérateurs effectuant des calculs élémentaires/ assemblages s'effectue de manière transparente à l'utilisateur. Elle s'initialise par défaut dès qu'on lance un calcul via Astk (menu Options) utilisant plusieurs processeurs.
Ainsi sur le serveur centralisé Aster, il faut paramétrer les champs suivants :
• mpi_nbcpu=m, nombre de processeurs alloués en MPI (nombre de processus MPI).
•
(facultatif) mpi_nbnoeud=p, nombre de noeuds sur lesquels vont être dispatchés ces processus MPI.
Par exemple, sur la machine Aster actuelle, les nœuds sont composés de 16 processeurs. Pour allouer 20 processus MPI à raison de 10 processus par nœud, il faut donc positionner mpi_nbcpu à
20 et mpi_nbnoeud à 2.
Une fois ce nombre de processus MPI fixé, on peut lancer son calcul (en batch sur la machine centralisé) avec le même paramétrage qu'en séquentiel. On peut bien sûr baisser les spécifications en temps et en consommations mémoire (JEVEUX) du calcul (si MUMPS+MATR_DISTRIBUEE ou FETI) par rapport aux consommations séquentielles.
Dès que plusieurs processus MPI sont activés, l'affectation du modèle dans le fichier de
commandes Aster (opérateur AFFE_MODELE) distribue les mailles
Code_Aster étant un code éléments finis, c'est la distribution naturelle des données (et des tâches associées). Par la suite, les étapes Aster de calculs élémentaires et d'assemblages (matriciels et vectoriels) vont se baser sur cette distribution pour «tarir» les flots de données/traitements locaux à chaque processeur. Chaque processeur ne va effectuer que les calculs associés au groupe de maille dont il a la charge.
Cette répartition maille/processeur se décline de différentes manières et elle est paramétrable dans l'opérateur AFFE_MODELE[U4.41.01] via les valeurs du mot-clé PARALLELISME:
1) CENTRALISE: Les mailles ne sont pas distribuées (comme en séquentiel). Chaque processeur connaît tout le maillage. Le parallélisme 1b n'est donc pas mis en œuvre. Ce mode d'utilisation est utile pour les tests de non-régression et pour certaines études où le parallélisme 1b rapporte peu voire est contre-productif (par ex. si on doit rassembler les données élémentaires pour nourrir un système linéaire non distribué et que les communications MPI requises sont trop lentes). Dans tous les cas de figure où les calculs
élémentaires représentent une faible part du temps total (par ex. en élasticité linéaire), cette option peut être suffisante.
2) GROUP_ELEM(défaut)/MAIL_DISPERSE/MAIL_CONTIGU/SOUS_DOMAINE : les mailles sont distribuées suivant le type de mailles, une distribution cyclique, par paquets de mailles
contiguës ou suivant des sous-domaines (préalablement construits via un des opérateurs
DEFI_PART_FETI/DEFI_PART_OPS).
6 On gagne au moins un facteur 2 (sur les temps consommés par les étapes parallélisées) en quadruplant le nombre de processeurs.
7 Du modèle.
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)
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
10/21
Clé :
U2.08.06
Révision :
5559
Remarques :
•
De manière générale, la distribution par sous-domaine (PARALLELISME=SOUS_DOMAINE +
PARTITION) est plus souple et elle peut s'avérer plus efficace en permettant d'adapter plus finement le flot de données à sa simulation.
•
Entre chaque commande, l'utilisateur peut même changer la répartition des mailles suivant les processeurs. Il lui suffit d'utiliser la commande MODI_MODELE . Ce mécanisme reste licite lorsqu'on enchaîne différents calculs (mode POURSUITE ). La règle étant bien sûr que cette nouvelle répartition reste valable, pour le modèle concerné, jusqu'à l'éventuel prochain
MODI_MODELE et que cette répartition doit rester compatible avec le paramétrage parallèle du calcul (nombre de nœuds/processeurs...).
•
Pour l'instant, la distribution par sous-domaines est basée sur un partitionnement au sens
FETI via les opérateurs DEFI_PART_*** . Ces derniers génèrent en fait une structure de
données trop riches pour les seuls besoins de la distribution maille/processeur (description interface, découpage des charges/conditions limites...). Pour éviter les surcoûts calculs qu'implique la constitution de ces objets redondants, on peut juste se contenter de préciser une seule charge, voire une charge «bidon». Pourvu qu'elle n'implique aucune manipulation de Lagrange (par exemple une charge de pression). Cette information ne servira pas dans le
calcul effectif des seuls objets décrivant la distribution maille/processeur.
4.2.2 Déséquilibrage de charge
Pour optimiser un calcul parallèle, il faut essayer d'équilibrer le flot de traitements qui va être confié à chaque processeur. Pour ce faire, ne disposant pas d'heuristique générale pour estimer la charge calcul en fonction des données, on ne peut que conseiller de distribuer de manière homogène les données entre les processeurs, tout en respectant deux règles spécifiques aux modélisations du code :
•
Rester attentif aux mailles de peau.
Les distributions par mailles sont les plus simples et les plus robustes à mettre en
œuvre mais elles peuvent conduire à des déséquilibres de charge car elles ne tiennent
pas compte des mailles particulières (mailles de peau, mailles spectatrices, zones non linéaires...). Par exemple, avec un fichier maillage débutant par 100 mailles 2D puis 900 mailles 3D, une répartition en 10 paquets via MAIL_CONTIGU va conduire à un déséquilibrage de charge : le premier processeur effectue des calculs élémentaires/assemblages sur des mailles 2D alors que les 9 autres ne travaillent qu'en 3D. Dans ce cas de figure, la distribution
cyclique 8 ou celle par sous-domaines 9 paraissent plus adaptées.
•
Rester attentif à la proportion de Lagranges.
Une autre cause de déséquilibrage de charge entre processeurs, peut provenir des
conditions de Dirichlet par dualisation (DDL_IMPO, LIAISON_***...). Chacun de ces blocages introduit une nouvelle variable (dite tardive), un Lagrange, et un nouvel élément fini
(dit tardif). Par soucis de robustesse/maintenabilité/lisibilité, le traitement de ces mailles tardives est affecté uniquement au processeur maître. Cette surcharge de travail est souvent négligeable (cf. §3 doc. U1.03.03 sur les performances), mais dans certain cas, elle peut introduire un déséquilibre plus marqué. L'utilisateur peut le compenser en renseignant un des mot-clés CHARGE_PROC0_MA/SD (MA pour maille et SD pour sous-domaine) de
AFFE_MODELE[U4.41.01].
Par exemple, en posant CHARGE_PROC0_MA=50 (%), le processeur maître pourra plus se consacrer aux mailles tardives car il n'aura que 50% des mailles standards (dites physiques) qu'il aurait dû avoir. Le reliquat est distribué entre les autres processeurs. De même avec une répartition par sous-domaines, si CHARGE_PROC0_SD=1 (sd), le processeur 0 ne traite qu'un sous-domaine, le reliquat est sous-traité.
Remarques :
•
Les paramètres CHARGE_PROC0_MA/SD peuvent être modifiés en cours de calcul via
l'opérateur MODI_MODELE . On peut aussi utiliser ce mécanisme pour artificiellement
8 Maille 1 pour le proc. 1, maille 2 pour le proc. 2... maille 10 pour le proc. 10 puis on revient au premier processeur, maille 11/proc. 1 etc.
9 Si on partitionne en 10 sous-domaines, chacun va comporter 100 mailles 3D auxquelles vont
être rattachées 10 mailles de peau 2D.
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)
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
11/21
Clé :
U2.08.06
Révision :
5559 surcharger le processeur maître (si par exemple, il est «mappé» sur un nœud de calcul
disposant de plus de mémoire ou plus rapide).
•
Le traitement différencié des mailles tardives concernent principalement les Lagranges, mais pas seulement. Ce cas de figure se retrouvent aussi avec les forces nodales, les échanges thermiques, la méthode de contact continue...
4.2.3 Structures de données distribuées
La distribution des données qu'implique ce type de parallélisme numérique ne diminue pas
forcément les consommations mémoire JEVEUX. Par soucis de lisibilité/maintenabilité, les objets
Aster usuels sont initialisés avec la même taille qu'en séquentiel. On se «contente» juste de les remplir partiellement suivant les mailles dont a la charge le processeur. On ne retaille donc généralement pas ces structures de données au plus juste, elles comportent beaucoup de valeurs nulles.
Cette stratégie n'est tenable que tant que les objets JEVEUX principaux impliqués dans les calculs
élémentaires/assemblages (CHAM_ELEM, RESU_ELEM, MATR_ASSE et CHAM_NO) ne dimensionnent pas les contraintes mémoire du calcul (cf. §5 de [U1.03.03]). Normalement leur occupation mémoire est négligeable comparée à celle du solveur linéaire. Mais lorsque ce dernier (par ex. MUMPS) est lui
implique), cette hiérarchie n'est plus forcément respectée. D'où l'introduction d'une option (mot-clé
MATR_DISTRIBUEE cf. U4.50.01) permettant de véritablement retailler, au plus juste, le bloc de
matrice Aster propre à chaque processeur.
Remarques :
•
Pour plus d'informations sur l'impact du parallélisme sur les structures de données et sur les structures de données distribuées, on pourra consulter le wiki du site.
•
En mode distribué, chaque processeur ne manipule que des matrices incomplètes (retaillées ou non). Par contre, afin d'éviter de nombreuses communications MPI (lors de l'évaluation des critères d'arrêt, calculs de résidus...), ce scénario n'a pas été retenu pour les vecteurs seconds membres. Leurs construction est bien parallélisée, mais à l'issu de l'assemblage, les contributions partielles de chaque processeur sont sommées. Ainsi, tout processeur
connaît entièrement les vecteurs impliqués dans le calcul.
10 L'Out-Of-Core (OOC) est un mode de gestion de la mémoire qui consiste à décharger sur disque certains objets alloués par le code pour libérer de la RAM. La stratégie OOC permet de traiter des problèmes plus gros mais ces accès disque ralentissent le calcul. A contrario, le mode In-Core (IC) consiste à garder les objets en RAM. Cela limite la taille des problèmes accessibles mais privilégie la vitesse.
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)
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
12/21
Clé :
U2.08.06
Révision :
5559
4.3
Calculs élémentaires d'algèbre linéaire
Utilisation : avancée (Astk + modification du fichier .btc)
Périmètre d'utilisation : calculs comportant des résolutions de systèmes linéaires (via
MUMPS/PETSC) et/ou des opérations de type BLAS
Nombre de processeurs conseillés : 2 ou 4.
Gain : en temps elapsed.
Speed-up : Gains variables suivant les cas (efficacité parallèle
pour que ce parallélisme reste efficace : 10 4
12 >50%). Une granularité faible suffit
degrés de liberté par processeur.
Type de parallélisme: threads.
Scénario: 1c du §3. Une utilisation classique consiste à tirer parti d'un parallélisme hybride
MPI+threads pour prolonger les performances du MPI (1c+2b...). Cumul contre-productif avec 2a.
Pour initier des traitements parallèles dans les calculs d'algèbre linéaire qui sont utilisés
(routines BLAS), il faut :
•
Préparer son étude (fichiers commande/maillage...) et son paramétrage de lancement
(temps, mémoire, nombre de processus Threads/MPI/Nœuds...). Par exemple, sur le serveur centralisé Aster, il faut paramétrer les champs suivants :
• ncpus=n, nombre de processeurs utilisés par les threads.
• mpi_nbcpu=m, nombre de processeurs utilisés par MPI (nombre de processus MPI).
• mpi_nbnoeud=p, nombre de nœuds sur lesquels vont être dispatchés ces processus.
Si (ncpus,mpi_nbcpu)=(n,1), les bibliothèques BLAS threadées utiliseront n processeurs.
Par contre, si (ncpus,mpi_nbcpu)=(n,m), chacun des m processus MPI utilisera pour ses besoins en BLAS, n processeurs.
Au final, Astk allouera nxm processeurs. Ceux-ci doivent donc être disponibles sur les p nœuds alloués.
•
Préparer la récupération du script de lancement généré par Astk (mettre en donnée un nouveau fichier mon_script.btc).
•
Pré-lancer l'étude (elle se termine en quelque secondes juste après l'écriture du .btc; le calcul n'est pas lancé).
•
Modifier «à la main» le contenu de ce fichier en remplaçant le nom de l'exécutable de lancement Aster (/chemin/exec_aster)
(/home/user/exec_aster_blasthreadees).
par un autre nom
•
Créer ce nouvel exécutable par recopie de l'exécutable officiel. Modifier le «à la main» afin de permettre l'usage des BLAS threadées. Par exemple, sur la machine centralisée, on positionnera la variable d'environnement MKL_SERIAL à NO plutôt que le YES par défaut: export MKL_SERIAL=NO.
•
Lancer (pour de bon cette fois) l'étude en prenant soin de ne pas modifier 14
d'Astk sauf à mettre le .btc en donnée.
•
Remarques :
•
La mise en oeuvre de ce parallélisme dépend du contexte informatique (matériel, logiciel) et des librairies d'algèbre linéaire threadées que l'on souhaite coupler au processus. On donne ici un canevas dans le cas très précis de l'utilisation des BLAS MKL sur la machine centralisée Aster.
11 Les BLAS sont des routines optimisées effectuant des opérations d'algèbre linéaire basique (d'où l'acronyme
'Basic Linear Algebra Subroutine') en stockage dense : produit matrice-vecteur, produit scalaire... Elles peuvent être parallélisées en mémoire partagée (OpenMP ou directement des threads Posix).
12 On gagne au moins un facteur 2 (sur les temps consommés par les étapes parallélisées) en quadruplant le nombre de processeurs.
13 Les BLAS sont massivement utilisées dans les solveurs linéaires MUMPS/PETSC.
14 Il deviendrait alors contradictoire à celui sauvegardé dans le .btc
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)
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
13/21
Clé :
U2.08.06
Révision :
5559
•
Ce type de parallélisme permet de prolonger le parallélisme MPI de MUMPS lorsqu'on a atteint
une trop faible granularité de travail par processus MPI. Le fait d'utiliser 2 ou 4 threads par processus MPI permet de prolonger notablement la scalabilité en temps du calcul. Par
contre, on ne gagnera pas plus en mémoire RAM.
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
Public link updated
The public link to your chat has been updated.
