Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
2 Généralités
Version default
Date :
16/02/2011
Page :
4/21
Clé :
U2.08.06
Révision :
5559
Toute simulation Code_Aster peut bénéficier des gains 1 de performance que procure le
parallélisme. Du moment qu'il effectue des calculs élémentaires/assemblages, des résolutions
de systèmes linéaires ou des simulations indépendantes/similaires. Les gains peuvent être de deux ordres : sur le temps de calcul et sur l'espace RAM/disque requis.
Comme la plupart des codes généralistes en mécanique des structures, Code_Aster propose différentes stratégies pour s'adapter à l'étude et à la plate-forme de calcul :
2.1
Parallélismes informatiques
1a/ Lancement de rampes de calculs indépendants/similaires (calculs paramétriques, tests...);
Parallélisme via un script shell; Gain en CPU. Lancement standard via Astk.
1b/ Distribution des calculs élémentaires et des assemblages matriciels et vectoriels dans les pré/posttraitements et dans les constructions de système linéaire; Parallélisme MPI; Gain en CPU, et même gain en mémoire avec MUMPS+MATR_DISTRIBUEE et FETI. Lancement standard via Astk.
1c/ Distribution des calculs d'algèbre linéaire effectués par des Blas multithreadées; Gain en CPU;
Utilisation avancée.
2.2
Parallélismes numériques
2a/ Solveur direct MULT_FRONT; Parallélisme OpenMP; Gain en CPU. Lancement standard via Astk.
2b/ Solveur direct MUMPS; Parallélisme MPI; Gain en CPU et en mémoire. Lancement standard via
Astk.
2c/ Solveur itératif PETSC; Parallélisme MPI du solveur de Krylov (généralement pas du préconditionneur); Gain en CPU et en mémoire. Lancement standard via Astk.
2.3
Parallélisme mécanique ou multidomaine
3a/ Solveur hybride FETI; Parallélisme MPI; Gain en CPU et en mémoire. Lancement standard via
Astk.
Les parallélismes numériques 2a et surtout 2b sont les plus plébiscités. Ils supportent une utilisation
«industrielle» et «grand public». Ces parallélismes généralistes et fiables procurent des gains notables en CPU et en RAM. Leur paramétrisation est simple, leur mise en œuvre facilitée via les menus de l'outil Astk. Ils peuvent facilement se cumuler, en amont et/ou en aval des systèmes linéaires, avec le parallélisme des calculs élémentaires (1b).
Remarque:
D'autres cumuls de parallélisme peuvent s'opérer. Leur mise en oeuvre n'est pas automatisée et ils s'adressent à des utilisateurs plutôt avancés: 1c+2b ou 2c, 2a+3a, 1a+2a/2b/2c/3a,
1a+1c+2b... Certains cumuls sont cependant proscrits car contre-productifs (1c+2a) ou non prévus fonctionnellement (2b/2c+3a). D'autres sont intrinsèques à la méthode (par ex. 1b+3a).
D'un point de vue pratique, l'utilisateur n'a plus à se soucier, pour une utilisation standard, de
leur mise en œuvre en interaction fine avec les solveurs linéaires. En renseignant des menus
dédiés d'Astk 2 , on fixe le nombre de processeurs requis (en terme MPI et/ou OpenMP), avec
éventuellement leur répartition par nœud.
Dans le déroulement du fichier de commande Aster, si plusieurs processus MPI sont activés
(paramètre mpi_nbcpu pour 1b/2b/2c/3a), on distribue les mailles entre les processeurs (cf figure
1 Ceux ci sont variables suivant les fonctionnalités sollicitées et leur paramétrage, le jeu de données et la plate-forme logicielle utilisée. Il s'agit essentiellement de gain en temps de calcul. Sauf dans le cas de
MUMPS, de PETSC et de FETI, où l'on peut aussi gagner en mémoire.
2 Menus Options+ncpus/mpi_nbcpus/mpi_nbnoeud.
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 :
5/21
Clé :
U2.08.06
Révision :
5559
3.1). Cette distribution se décline de différentes manières et elle est paramétrable dans les opérateurs
AFFE/MODI_MODELE.
Dans le cas d'opérateurs de calcul (MECA_STATIQUE, STAT_NON_LINE...), cette distribution des mailles des calculs élémentaires va ensuite nourrir le parallélisme «numérique» des solveurs linéaires choisis par le mot-clé SOLVEUR.
Suivant le cas de figure, solveur linéaire distribué (MUMPS, FETI) ou non (MULT_FRONT, PETSC), on fournit les données, par morceaux, ou après les avoir rassemblées, au solveur linéaire. Ce dernier souvent les redistribue en interne au grès de ses contingences. Mais dans le cas d'un solveur linéaire acceptant un flot de données d'entrée déjà distribué, les gains en temps et en mémoire sont patents.
Par ailleurs, on ne rassemble les données (ou on effectue les communications MPI idoines) que si le déroulement algorithmique l'impose : par exemple pour un calcul de maximum sur toutes les mailles du modèle ou pour un produit matrice-vecteur.
Si le solveur linéaire parallèle utilise des threads (OpenMP des scénarios 1c et 2a) ceux-ci s'exécutent indépendamment des éventuels aspects MPI. Dans le cas le plus usuel (2a), les threads se substituent ensuite aux processus MPI. Dans un cas de parallélisme hybride (1c+2b/c), ils démultiplient leur efficacité.
Figure 3.1._ Lors d'un calcul paralléle, distribution des flots de données/traitements suivant les opérateurs (pré/post-traitement ou résolution) et le type de solveur utilisé.
Dans le cas d'un opérateur de pré/post-traitements (type CALC_ELEM), là encore, on ne rassemble les données (ou on effectue les communications MPI idoines) que si le déroulement algorithmique l'impose.
De toute façon, tout calcul parallèle Aster (sauf bien sûr le scénario 1a de calculs indépendants) doit
respecter le paradigme suivant : les bases globales de chaque processeur sont identiques à la fin de chaque opérateur. Car on ne sait pas si l'opérateur qui suit dans le fichier de commandes a prévu un flot de données incomplet. Il faut donc organiser les communications idoines pour compléter les champs éventuellement incomplets.
Remarque:
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 perdure, 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...).
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
