Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
5 Parallélismes numériques
Version default
Date :
16/02/2011
Page :
14/21
Clé :
U2.08.06
Révision :
5559
5.1
Solveur direct MULT_FRONT
Utilisation : grand public via Astk.
Périmètre d'utilisation : calculs comportant des résolutions de systèmes linéaires coûteuses (en général STAT/DYNA_NON_LINE, MECA_STATIQUE...).
Nombre de processeurs conseillés : 2 ou 4.
Gain : en temps CPU.
Speed-up : Gains variables suivant les cas (efficacité parallèle≈50%). Il faut une grosse granularité
degrés de liberté par processeur.
pour que ce parallélisme reste efficace : 10 5
Type de parallélisme : OpenMP.
Scénario: 2a du §3. Cumul contre-productif avec 1c. Chaînage 1b+2a possible et réalisable via Astk.
Chaînages 1a+2a/2a+3a potentiels (utilisateurs avancés).
Cette méthode multifrontale développée en interne (cf. [R6.02.02] ou [U4.50.01] §3.5) est utilisée via la mot-clé SOLVEUR/METHODE='MULT_FRONT'. C'est le solveur linéaire (historique et auto-portant)
préconisé par défaut en séquentiel.
La mise en oeuvre de ce parallélisme 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 threads.
Ainsi sur le serveur centralisé Aster, il faut paramétrer le champs suivants :
• ncpus=n, nombre de processeurs utilisés par les threads.
Une fois ce nombre de threads 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 du calcul.
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 :
15/21
Clé :
U2.08.06
Révision :
5559
5.2
Solveur direct MUMPS
Utilisation : grand public via Astk.
Périmètre d'utilisation : calculs comportant des résolutions de systèmes linéaires coûteuses (en général STAT/DYNA_NON_LINE, MECA_STATIQUE...).
Nombre de processeurs conseillés : 16 ou 32, voire plus (surtout si couplée avec 1c).
Gain : en temps CPU et en mémoire RAM (y compris la partie JEVEUX si MATR_DISTRIBUEE activée).
Speed-up : Gains variables suivant les cas (efficacité parallèle≈30%). Il faut une granularité moyenne pour que ce parallélisme reste efficace : environ 3.10
4 degrés de liberté par processeur.
Type de parallélisme : MPI.
Scénario : 2b du §3. Nativement conçu pour se coupler aux parallélismes informatiques 1c, et surtout,
1b (via Astk). Chaînage 1a+2a potentiel (utilisateurs avancés).
Cette méthode multifrontale s'appuie sur le produit externe MUMPS (cf. [R6.02.03] ou [U4.50.01]
§3.7) est utilisée via la mot-clé SOLVEUR/METHODE='MUMPS'. C'est le solveur linéaire conseillé
pour exploiter pleinement les gains CPU/RAM que peut procurer le parallélisme. Ce type de parallélisme est performant (surtout lorsqu'il est couplé avec 1b) tout en restant générique, robuste et grand public.
La mise en œuvre de ce parallélisme 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 processus MPI.
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.
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/RAM totale) du calcul.
Figure 6.1._ Flots de données/traitements parallèles du couplage Aster+MUMPS suivant le mode d'utilisation: centralisé ou distribué.
Idéalement, ce solveur linéaire parallèle doit être utilisé en mode distribué
(PARALLELISME=GROUP_ELEM/MAIL_DISPERSE/MAIL_CONTIGU/SOUS_DOMAINE). C'est-à-dire qu'il faut avoir initié en amont du solveur, au sein des calculs élémentaires/assemblages, un flot de données distribué (scénario parallèle 1b). MUMPS accepte en entrée ces données incomplètes et il les rassemble en interne. On ne perd pas ainsi de temps (comme c'est le cas pour les autres solveurs linéaires) à compléter les données issues de chaque processeur. Ce mode de fonctionnement est activé par défaut dans les commandes AFFE/MODI_MODELE (cf. §5.2).
En mode centralisé (CENTRALISE), la phase amont de construction de système linéaire n'est pas parallélisée (chaque processeur procède comme en séquentiel). MUMPS ne tient compte que des données issues du processeur maître.
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 :
16/21
Clé :
U2.08.06
Révision :
5559
Dans le premier cas, le code est parallèle de la construction du système linéaire jusqu'à sa résolution
(chaînage des parallélismes 1b+2b), dans le second cas, on n'exploite le parallélisme MPI que sur la partie résolution (parallélisme 2b).
Remarque :
Lorsque la part du calcul consacrée à la construction du système linéaire est faible (<5%), les deux modes d'utilisation (centralisé ou distribué) affichent des gains en temps similaires. Par
contre, seule l'approche distribuée procure, en plus, des gains sur les consommations 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
Code_Aster
Titre :
Notice d'utilisation du parallélisme
Responsable :
Olivier BOITEAU
Version default
Date :
16/02/2011
Page :
17/21
Clé :
U2.08.06
Révision :
5559
5.3
Solveur itératif PETSC
Utilisation: grand public via Astk.
Périmètre d'utilisation: calculs comportant des résolutions de systèmes linéaires coûteuses (en général STAT/DYNA_NON_LINE, MECA_STATIQUE...). Plutôt des problèmes bien conditionnés de grandes tailles.
Nombre de processeurs conseillés: quelques dizaines voire centaines.
Gain: en temps CPU et en mémoire RAM (suivant les préconditionneurs).
Speed-up: gains variables suivant les cas (efficacité parallèle>50%). Il faut une granularité moyenne pour que ce parallélisme reste efficace : 3.10
Type de parallélisme: MPI.
Scénario: 2c du §3. Chaînage 1b+2c possible et réalisable via Astk. Chaînages 1a+2c/1c+2c potentiels (utilisateurs avancés).
4 degrés de liberté par processeur.
Cette bibliothèque de solveurs itératifs (cf. [R6.01.02] ou [U4.50.01] §3.9) est utilisée via la mot-clé
SOLVEUR/METHODE='PETSC'. Ce type de solveur linéaire est conseillé pour traiter des
problèmes frontières de très grande taille (>5.10
6 degrés de liberté) et plutôt bien conditionnés.
La mise en œuvre de ce parallélisme 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 processus MPI.
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 nœuds sur lesquels vont être dispatchés ces processus MPI.
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 du calcul (voire en mémoire suivant les préconditionneurs).
Remarques :
•
Si le système matriciel que PETSC doit résoudre est issu de calculs
élémentaires/assemblages parallélisés (stratégie parallèle 2b), ces flots de données incomplets sont automatiquement rassemblés. Pour l'instant, seul un flot de donné centralisé
(le même pour tous les processeurs) a été mis en place. Le parallélisme reste interne à
PETSC. On perd donc, dans le couplage 1b+2c, du temps dans des communications MPI collectives.
•
Contrairement aux solveurs parallèles directs ( MUMPS , MULT_FRONT ), les itératifs ne sont
pas universels et robustes. Ils peuvent être très compétitifs (en temps et surtout en mémoire), mais il faut trouver le point de fonctionnement (algorithme, préconditionneur...)
adapté au problème.
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
