Parallélismes numériques ======================== Solveur direct MULT_FRONT ------------------------- Descriptif ~~~~~~~~~~ **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 cœurs conseillés:** 2 ou 4. **Gain :** en temps elapsed. **Speedup:** Gains variables suivant les cas (efficacité parallèle≈50%). Il faut une bonne granularité pour que ce parallélisme reste efficace : au moins 50.103 ddls par cœur. **Type de parallélisme:** numérique *via* le langage OpenMP (ncpus). **Scénario:** 2a du §2. Chaînage possible mais peu utile avec 1b, 2b ou 2c. Cumul contre-productif avec 1c, possible mais peu utile avec 1d. Mise en œuvre ~~~~~~~~~~~~~ Cette méthode multifrontale développée en interne (cf. [:ref:`R6.02.02 `] ou [:external:ref:`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 sur les modèles de taille petite ou moyenne (<0.5M ddls). La mise en œuvre de ce parallélisme s'effectue de manière transparente pour l'utilisateur. Elle s'initialise par défaut dès qu'on lance un calcul *via Astk* (menu Options) utilisant plusieurs threads OpenMP. Ainsi sur le serveur centralisé *Aster* , il faut paramétrer le champs suivants: * ncpus=n, nombre de threads OpenMP alloués. 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. Package MUMPS ------------- Descriptif ~~~~~~~~~~ **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 cœurs conseillés:** chaîné avec le parallélisme distribué des calculs élémentaires/assemblages typiquement 16, 32 voire 64. **Gain:** en temps CPU et en mémoire RAM. **Speedup:** Gains variables suivant les cas (efficacité parallèle≈30%). Il faut une granularité moyenne pour que ce parallélisme reste efficace : entre 30 et 50.103 ddls par processus MPI. **Type de parallélisme:** numérique *via* le langage MPI. **Scénario:** 2b du §3. Nativement conçu pour se chaîner aux parallélismes 1b ou 2c. Chaînage possible mais peu utile avec 2a. Couplage très utile avec 1c ou 1d (voire les 2). Mise en œuvre ~~~~~~~~~~~~~ **Cette méthode multifrontale s'appuie sur le produit externe MUMPS** (cf. [:ref:`R6.02.03 `] ou [:external:ref:`U4.50.01 `] §3.7) est utilisée soit en tant que solveur direct (mot-clé SOLVEUR/METHODE='MUMPS'), soit en tant que préconditionneur des solveurs itératifs PETSC ou GCPC (mot-clé SOLVEUR/PRE_COND='LDLT_SP'). **C'est le package HPC 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 chaîné avec 1b et couplé avec 1c) tout en restant générique, robuste et grand public. 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). Idéalement, ce solveur linéaire HPC doit être utilisé en mode parallèle distribué (DISTRIBUTION/METHODE='GROUP_ELEM'/'MAIL_DISPERSE'/'MAIL_CONTIGU'/'SOUS_DOMAINE'/'SOUS_DOM.OLD'). C'est-à-dire qu'il faut avoir initié en amont de ce solveur linéaire, au sein des procédures de calculs élémentaires/assemblages, des flots de données/traitements distribués (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. §4.2). En mode centralisé (CENTRALISE), la phase amont de construction des systèmes linéaires n'est pas parallélisée (chaque processeur procède comme en séquentiel). MUMPS ne tient alors compte que des données issues du processeur maître. 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). .. image:: images/100000000000038F00000234AA66913D8CA69A19.jpg :width: 4.3346in :height: 2.6728in .. _RefImage_100000000000038F00000234AA66913D8CA69A19.jpg: *Figure 5.2.1._ Flots de données/traitements parallèles du couplage Code_Aster+* MUMPS *suivant le mode d'utilisation:* *centralisé ou distribué.* **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.* Solveur itératif PETSC ---------------------- Descriptif ~~~~~~~~~~ **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 non linéaires de grandes tailles. **Nombre de cœurs conseillés:** chaîné avec le parallélisme distribué des calculs élémentaires/assemblages (1b), voire celui du préconditionneur MUMPS (2b), typiquement 16, 32 voire 64. **Gain:** en temps CPU et en mémoire RAM (suivant les préconditionneurs). **Speedup:** gains variables suivant les cas (efficacité parallèle>50%). Il faut une granularité moyenne pour que ce parallélisme reste efficace : 50.103 ddls par processus MPI. **Type de parallélisme:** numérique *via* le langage MPI. **Scénario:** 2c du §3. Nativement conçu pour se chaîner aux parallélismes 1b ou 2b; chaînage possible mais peu utile avec 2a. Cumul possible mais peu utile avec 1c, hors-périmètre avec 1d. Mise en œuvre ~~~~~~~~~~~~~ Cette bibliothèque de solveurs itératifs (cf. [:ref:`R6.01.02 `] ou [:external:ref:`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, soit des problèmes frontières de très grande taille (>5M ddls), soit en non linéaire, pour tirer pleinement partie de la mutualisation du préconditionneur entre différents pas de Newton **.** La mise en œuvre de ce parallélisme s'effectue comme pour le package MUMPS (cf. §5.2). **Remarque:** * *Contrairement aux solveurs parallèles directs (MUMPS,* *MULT_FRONT), les itératifs ne sont pas universels (ils ne peuvent pas être utiliser en modal) et toujours 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.Toutefois, sur ce dernier point, l'usage généralisé (et paramétré par défaut) de* *MUMPSsimple précision comme préconditionneur (PRE_COND='LDLT_SP') a considérablement amélioré les choses.*