4. Parallélismes informatiques#

4.1. Rampes de calculs indépendants#

4.1.1. Descriptif#

Utilisation: grand public via Astk .

Périmètre d’utilisation: calculs indépendants (paramétrique, étude de sensibilité…).

Nombre de cœurs 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: informatique via des scripts 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 ).

4.1.2. Mise en œuvre#

L’outil Astkpermet 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 reparamé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 œuvre de ce parallélisme, on pourra consulter les documentations [U1.04.00]/[U2.08.07].

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 contact-frottement… (cf. documentations [U1.03.03], [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’utilisation de moyens de calculs partagés (classe batch, gros jobs prioritaires…).

4.2. Calculs élémentaires et assemblages#

4.2.1. Descriptif#

Utilisation: grand public via Astk .

Périmètre d’utilisation: calculs comportant des calculs élémentaires/assemblages coûteux (mécanique non linéaire). Activé par défaut dès que le nombre de processus MPI>1.

Nombre de cœurs conseillés: seul, entre 4 et 8. Chaîné avec le parallélisme distribué de MUMPS ou de PETSC (valeur par défaut), typiquement 16, 32 voire 64.

Gain: en temps voire en mémoire avec solveur linéaire MUMPS/PETSC (si MATR_DISTRIBUEE).

Speed-up: Gains variables suivant les cas (efficacité parallèle [13]_ >50%). Il faut une assez grosse granularité pour que ce parallélisme reste efficace : 30 ou 50.103 ddls par processus MPI.

Type de parallélisme: informatique via la langage MPI (mpi_nbcpu/mpi_nbnœud).

Scénario: 1b du §2. Nativement conçu pour se chaîner aux parallélismes numériques 2b ou 2c. Chaînage possible avec 1c, possible mais peu utile avec 1d ou 2a. Pas de cumul possible.

4.2.2. Mise en œuvre#

La mise en œuvre de ce schéma parallèle s’effectue de manière transparente pour l’utilisateur. Via Astk, elle s’initialise par défaut dès qu’on a sélectionné une version parallèle de Code_Aster (notée ***_mpi) ainsi qu’un nombre de processus MPI au moins égale à 2.

Ainsi sur le serveur centralisé Aster , il faut paramétrer les champs suivants dans le menu Options :

mpi_nbcpu=m , nombre de processus MPI alloués.
mpi_nbnœud=p , nombre de nœuds sur lesquels vont être distribués ces processus MPI.

Par exemple, sur la machine centralisée Aster5, les nœuds sont composés de 24 cœurs. Pour allouer 32 processus MPI à raison de 8 processus par nœud, il faut donc positionner mpi_nbcpu à 32 et mpi_nbnœud à 4.

On conseille, en général, de ne pas allouer tous les cœurs d’un nœud en MPI seul . Cela peut avoir pour effet de ralentir la simulation car, même si une partie des calculs s’en trouve accélérée du fait de sa distribution sur plus de cœurs, comme ceux-ci partagent certaines ressources mémoire, lesaccès aux donnéessont, eux, ralentis.

Pour utiliser plus efficacement et à 100% toutes les ressources allouées on conseille plutôt de panacherparallélisme MPI et OpenMP (cf. scénarios 1b+2b/1c ou 1b+2b/1c+2c).

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. Si ce schéma parallèle est chaîné avec le parallélisme numérique de MUMPS ou celui de de PETSC (ou les 2, cf. scénarios 2b et 2c), on peut réduire son pic mémoire RAM en activant l’option MATR_DISTRIBUEE.

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 ses mailles entre les processeurs . Code_Aster étant un code éléments finis, c’est une 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 les opérateurs AFFE_MODELE[U4.41.01]/MODI_MODELE[U4.41.02] via les valeurs du mot-clé DISTRIBUTION/METHODE=:

“CENTRALISE”: Les mailles ne sont pas distribuées (comme en séquentiel). Chaque processeur connaît l’intégralité des mailles du modèle. 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.
“GROUP_ELEM” /” MAIL_DISPERSE” /”MAIL_CONTIGU” /”SOUS_DOMAINE” (défaut) /”SOUS_DOM.OLD”: les mailles sont distribuées en se basant sur différents critères: par type, par distribution cyclique, par paquets de même taille ou suivant des stratégies sous-domaines.

Dans les deux derniers scénarios, la distribution s’effectue via les partitionneurs METIS (défaut) ou SCOTCH (cf. mot-clé PARTITIONNEUR). Ceux-ci doivent donc être installés et linkés à la versions Code_Aster utilisée. C’est évidemment fait par défaut sur la machine centralisée.

Remarques:

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 doit rester compatible avec le paramétrage parallèle du calcul (nombre de nœuds/processeurs…).
Seul le parallélisme MPI permet d’accélérer cette étape du calcul. Or si on alloue trop de MPI, l’étape de résolution de système linéaire risque d’être ralentie ou d’être bloquée par manque de mémoire. Pour pallier à ce problème, on peut, avec le solveur linéaire MUMPS (cf. mot-clé SOLVEUR/REDUCTION_MPI), réduire le nombre de processus MPI utilisés uniquement dans MUMPS.

Les cœurs inoccupés se voient alors confier à l’autre niveau de parallélisme, l’OpenMP. La consommation mémoire globale du calcul s’en trouve ainsi réduite et ce, sans ralentir les résolutions de système linéaire. On accélère ainsi grandement l’étape de calcul élémentaire/assemblage sans impacter, ni le coût mémoire, ni celui en temps, de l’étape de résolution de système.

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 Code_Aster usuels sont initialisés avec la même taille qu’en séquentiel. Chaque processus MPI se «contente» juste de les remplir partiellement avec les données produites par les mailles dont a la charge le processeur. A charge pour le solveur linéaire parallèle utilisé dans la suite de l’opérateur (MUMPS, PETSC ou les 2) d’assembler ces données incomplètes et distribuées. On ne retaille donc généralement pas ces structures de données, 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 aussi Out-Of-Core [14]_ et parallélisé en MPI (avec la répartition des données entre processeurs que cela 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 Asterpropre à chaque processus MPI.

Remarque:

En mode distribué, chaque processus MPI 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 constructions sont bien parallélisées, mais, à l’issue de l’assemblage, les contributions partielles de chaque processus sont rassemblées. Ainsi, tout processus MPI connaît entièrement les vecteurs (CHAM_NO) impliqués dans le calcul.

4.3. Distribution des calculs d’algèbre linéaire basiques#

4.3.1. Descriptif#

Utilisation: grand public viaAstk.

Périmètre d’utilisation: calculs comportant des résolutions de systèmes linéaires via MUMPS (usage solveur direct ou préconditionneur de PETSC/GCPC).

Nombre de cœurs conseillés: sur Aster5, entre 2 et 12. Pas plus que de cœurs physiques partageant la même mémoire physique.

Gain: en temps elapsed (mais augmentation du temps CPU).

Speed-up: Gains variables suivant les cas (efficacité parallèle [15]_ >50%). Une granularité faible suffit pour que ce parallélisme reste efficace : 10.103 ddls par threads OpenMP.

Type de parallélisme: informatique via le langage OpenMP (ncpus).

Scénario: 1c du §2. Une utilisation classique consiste à tirer parti d’un parallélisme hybride MPI+OpenMP pour accentuer les performances de MUMPS et de tirer partie à 100% des ressources machine (2b/1c ou (2b/1c)+2c).

Cumul contre-productif avec 2a, utile avec 2b, possible mais peu utile avec 2c (seul) ou 1d.

4.3.2. Mise en œuvre#

Ainsi sur le serveur centralisé Aster , il faut paramétrer les champs suivants dans le menu Options :

ncpus=k , nombre de threads OpenMP alloués (par processus MPI si mpi_nbcpu>1).

Ce schéma parallèle est généralement utilisé en conjonction du parallélisme MPI de MUMPS. Car on conseille, en général, de ne pas allouer tous les cœurs d’un nœud en MPI seul . Cela peut avoir pour effet de ralentir la simulation car, même si une partie des calculs s’en trouve accélérée du fait de sa distribution sur plus de cœurs, comme ceux-ci partagent certaines ressources mémoire, les accès aux données sont, eux, ralentis. Pour utiliser plus efficacement et à 100% toutes les ressources allouées on conseille plutôt de panacher parallélisme MPI et OpenMP (cf. scénarios 2b/1c ou (2b/1c)+2c).

Dans ce type de parallélisme hybride (MPI/OpenMP), l’outil Astk[U1.04.00] complète automatiquement le nombre de threads en fonction des ressources machines, dès que le champ ncpus est laissé vide.

Par exemple, sur la machine centralisée Aster5 , les nœuds sont composés de 24 cœurs. Si on souhaite organiser un parallélisme hybride 12 MPI x 4 OpenMP, il suffit de positionner mpi_nbcpu à 12, mpi_nbnœud à 2 et ncpus=<vide> (ou 4 explicitement).

Remarque:

La mise en œuvre de ce parallélisme dépend du contexte informatique (matériel, logiciel) et des librairies d’algèbre linéaire utilisées. Sur la machine centralisée Aster, on utilise les BLAS threadées MKL.

4.4. Calculs modaux d’INFO_MODE/CALC_MODES#

4.4.1. Descriptif#

Utilisation: grand public viaAstk.

Périmètre d’utilisation: calculs comportant de coûteuses recherches de modes propres.

Nombre de cœurs conseillés: plusieurs dizaines (par exemple, nombre de sous-bandes fréquentielles x 2, 4 ou 8).

Gain : en temps elapsed v oire en mémoire RAM (grâce au deuxième niveau de parallélisme).

Speedup: Gains variables suivant les cas: efficacité de l’ordre de 70% sur le premier niveau de parallélisme (sur les sous-bandes fréquentielles) complété par le parallélisme éventuel du second niveau (si SOLVEUR=MUMPS, efficacité complémentaire de l’ordre de 20%).

Type de parallélisme: informatique via le langage MPI (mpi_nbcpu/mpi_nbnœud).

Scénario: 1d du §2. Nativement conçu pour se coupler au parallélisme 2b (voire 2b/1c).

Chaînage possible mais peu utile avec 1b. Cumul possible mais peu utile avec 2a et impossible avec 2c (hors périmètre).

4.4.2. Mise en œuvre#

L’usage de CALC_MODES avec l’option “BANDE” découpée en plusieurs sous-bandes est à privilégier lorsqu’on traite des problèmes modaux de tailles moyennes ou grandes (>0.5M ddls) et/ou que l’on cherche une bonne partie de leurs spectres (> 50 modes).

On découpe alors le calcul en plusieurs sous-bandes fréquentielles. Sur chacune de ces sous-bandes, un solveur modal effectue la recherche de modes associée. Pour ce faire, ce solveur modal utilise intensivement un solveur linéaire.

Ces deux briques de calcul (solveur modal et solveur linéaire) sont les étapes dimensionnantes du calcul en terme de consommation mémoire et temps. C’est sur elles qu’il faut mettre l’accent si on veut réduire significativement les coûts calcul de cet opérateur (cf. figures 1.3a/b).

Or, l’organisation du calcul modal sur des sous-bandes distinctes offre ici un cadre idéal de parallélisme: distribution de gros calculs presque indépendants . Son parallélisme permet de gagner beaucoup en temps mais au prix d’un surcoût en mémoire [16]_ .

Si on dispose d’un nombre de processeurs suffisant (> au nombre de sous-bandes non vides), on peut alors enclencher un deuxième niveau de parallélisme viale solveur linéaire (si on a choisit METHODE=”MUMPS”). Celui-ci permettra de continuer à gagner en temps mais surtout, il permettra de compenser le surcoût mémoire du premier niveau voire de diminuer notablement le pic mémoire séquentiel.

Pour un usage optimal de CALC_MODES avec l’option “BANDE” découpée en plusieurs sous-bandes parallélisées, il est donc conseillé de:

Construire des sous-bandes de calcul relativement équilibrées . Pour ce faire, on peut donc, au préalable, calibrer le spectre étudié via un appel à INFO_MODE [U4.52.01] (si possible en parallèle). Puis lancer le calcul CALC_MODES avec l’option “BANDE” découpée en plusieurs sous-bandes parallélisées en fonction du nombre de sous-bandes choisies et du nombre de processeurs disponibles.
De prendre des sous-bandesentre 50 et 100modes .
Sélectionnerun nombre de processeurs qui est un multiple du nombre de sous-bandes (non vides). Ainsi, on réduit les déséquilibrages de charges qui nuisent aux performances.

Pour plus de détails on pourra consulter la documentation utilisateur de l’opérateur[U4.52.02].

4.5. Calculs MISS3D via CALC_MISS#

4.5.1. Descriptif#

Utilisation: grand public viaAstk.

Périmètre d’utilisation: calculs comportant des calculs MISS3D.

Nombre de cœurs conseillés: avec option FICHIER_TEMPS, plusieurs dizaines (par exemple, nombre de fréquences x4 ou X8); autre option, jusqu’à 24 cœurs.

Gain : en temps elapsed .

Speed-up: Gains variables suivant les cas: efficacité de l’ordre de 100% sur le premier niveau de parallélisme (en MPI sur les fréquences si FICHIER_TEMPS) complété par le parallélisme éventuel du second niveau (en OpenMP).

Type de parallélisme: informatique via le langage MPI (mpi_nbcpu/mpi_nbnœud) si FICHIER_TEMPS, complété éventuellement par un parallélisme OpenMP (toutes les autres options de CALC_MISS, ncpus) .

Scénario: 1e du §2.

4.5.2. Mise en œuvre#

Si les calculs CALC_MISS sont indépendants (option FICHIER_TEMPS), on peut déjà les distribuer sur plusieurs nœuds, en réservant plusieurs processus MPI par nœud. Chacun va traiter une série de fréquences. On ne prendra pas tous les c œ urs d’un nœud afin de laisser assez de mémoire RAM au calcul MISS3D.

Ensuite, afin d’utiliser au mieux ces cœurs inoccupés, il est alors conseillé de rajouter un deuxième niveau de parallélisme en activant des threads OpenMP au sein de chaque processus MPI MISS3D (cf. figures 1.4a/b).

Si les calculs ces calculs CALC_MISS ne sont, par contre, pas indépendants (autre option que FICHIER_TEMPS), on n’utilisera qu’un nœud du cluster et on n’activera que le second niveau de parallélisme via OpenMP.

Pour plus de détails on pourra consulter la documentation utilisateur de l’opérateur[U2.06.07].

4.6. Autres distributions de calculs#

4.6.1. Descriptif#

Utilisation: grand public viaAstk.

Périmètre d’utilisation: calculs comportant du contact-frottement, des appels à REST_SPEC_TEMP[U4.63.34], CALC_CHAMP[U4.81.04] (options REAC/FORC_NODA et ***_NOEU)…

Nombre de cœurs conseillés: pas de paramétrage spécifique (mode parallèle par défaut), garder le même paramétrage parallèle MPI que pour le parallélisme de MUMPS: au moins 50000 ou 100000 ddls par processus MPI.

Sauf pour le «parallélisme en temps» de CALC_CHAMP, qui lui est efficace dès qu’on réserve au moins une douzaine pas de temps par processus MPI. Du moment que le calcul unitaire d’un seul pas de temps s’avère assez coûteux.

Gain : en temps elapsed .

Speed-up: Gain assez important si taille ci-dessus respectée: efficacité >50%.

Type de parallélisme: informatique via le langage MPI (mpi_nbcpu/mpi_nbnœud).

Scénario: 1f du §2.

4.6.2. Mise en œuvre#

Mise en œuvre identique à celle de MUMPS (cf. §5.5.2), sauf pour CALC_CHAMP[U4.81.04], pour lequel il faut activer un mot-clé spécifique (PARALLELISME_TEMPS=’OUI’).