Code_Aster et le parallélisme

8 juillet 2010

par O. Boiteau, T. de Soza, N. Sellenet et N. Tardieu, EDF R&D / AMA

Dans Code_Aster, le parallélisme continue à progresser. Aujourd’hui, pour l’utilisateur il est possible de le mettre en oeuvre simplement via Astk. Pour cela, il est nécessaire de choisir la version MPI de Code_Aster, d’utiliser le solveur MUMPS (SOLVEUR=’MUMPS’ dans le fichier de commande) et d’indiquer à Astk le nombre de processus MPI désirés (mpi_nbcpu). A partir de là, Code_Aster génère automatiquement une distribution cyclique des mailles.

Ces options basiques rendent parallèles les deux étapes les plus gourmandes en temps de calcul et en mémoire que sont d’une part les calculs élémentaires et l’assemblage et d’autre part les résolutions de système linéaire.

Un usage plus avancé est possible, néanmoins il nécessite davantage de paramétrisation.

En effet il est possible de modifier le partitionnement par défaut pour obtenir de meilleurs performances. Pour ce faire, on utilise la commande MODI_MODELE qui permet de choisir entre diverses répartitions mailles/processeurs : MAIL_CONTIGU (distribution par paquet de mailles contigües), MAIL_DISPERSE (distribution cyclique par mailles), ou SOUS_DOMAINE (distribution des mailles via un partitionnement préalablement calculé par l’opérateur DEFI_PART_FETI).

D’autres options permettent de faire diminuer la consommation mémoire globale du calcul. Par exemple, on peut diminuer celle intrinsèque de Code_Aster via le mot-clé SOLVEUR, il est possible d’utiliser MATR_DISTRIBUEE=’OUI’. Ainsi chaque processus MPI ne va construire que les morceaux de matrice correspondant aux paquets de mailles dont il est responsable. D’autre part, on peut diminuer significativement le pic mémoire de la résolution du système linéaire (gain allant jusqu’à un facteur 6) en activant la gestion de mémoire out-of-core du solveur MUMPS (mot-clé SOLVEUR, OUT_OF_CORE=’OUI’)

Gains en mémoire apportés par MATR_DISTRIBUEE sur les études de la Pompe RIS (800 000 ddl) et Epicure (860 000 ddl) suivant le nombre de processus. Sur le graphique, on retrouve la consommation du gestionnaire de mémoire : JEVEUX_std (MATR_DISTRIBUEE=’NON’), JEVEUX_dist (MATR_DISTRIBUEE=’OUI’) et la consommation de mémoire du solveur MUMPS en out-of-core.

De même, le parallélisme et ses performances sont suivis semaine après semaine grâce à l’ajout de nouveaux cas tests dans la base de cas test (exemple : perf009, perf010 et perf011).

Cas test perf010 (499 203 ddl)	Etude Epicure : perf011 (860 000 ddl)

Sur ces graphiques, on peut constater l’apport du parallélisme utilisé avec ses options de base. Dans le cas de l’étude Epicure, on constate qu’on peut gagner jusqu’à un facteur 10 sur 32 processeurs.

Pour plus d’informations, on pourra consulter les documentations U2.08.06 ’Notice d’utilisation du parallélisme’, U1.03.03 ’Indicateur de performance d’un calcul (temps/mémoire)’ et U4.50.01 ’Mot-clé SOLVEUR’.