Intégration de la parallélisation mixte MPI-OpenMP dans les configurations de l'IPSL

Objectif == Utiliser au maximum les machines de type SMP (vargas, titane, platine, jade) en s’affranchissant de la limitation du nombre de processus MPI (3 bandes de latitudes par process MPI)

et des problèmes éventuels de mémoire intra-nœud en particulier lorsqu’on monte en résolution grâce à l'utilisation de la parallélisation mixte MPI-OpenMP (MPI inter-noeud, OpenMP intra-noeud).

Description du travail == Voir le document là : OpenMP.pdf​

Evolution du travail

Réunion "cahier des charges" le 7/10/2010 au LSCE

Présents : Anne, Olivier, Yann, Martial, Arnaud

Une discussion autour des premiers développements de Martial a abouti aux conclusions suivantes :

• On part sur l'idée d'avoir des informations dans le config.card relatives au nombre de process MPI et tâches openMP pour chaque exécutable.

Ce config.card est donc propre à une configuration et à une machine par défaut, ce qui signifie qu'une configuration particulière tournera "sans rien changer" sur une seule machine. Pour adapter ce config.card en vue de tourner sur une machine différente de la machine par défaut, il faudra modifier à la main le config.card grâce à de l'information disponible soit sur une page wiki soit dans chacune des configurations (mais un peu lourd à entretenir !).

• L'utilisation de ces informations se fera ensuite en deux étapes grâce à des fonctions/scripts (définies dans libIGCM_sys/libIGCM_sys_mercurex9.ksh par exemple) :
  • lecture dans le Job de soumission(au niveau du IGCM_config_Initialize) des informations contenues dans le config.card.
  • le lancement du modèle lui-même : on remplace la ligne de commande actuelle ${MPIRUN_COMMAND} ${MPIRUN_OPTIONS} ./${config_Executable_Name} >> ${Exe_Output} 2>&1 par le lancement d'un script, dans lequel
    • seront utilisées les infos recoltées dans le config.card
    • sera lancé le modèle de la facon appropriée (./gcm.e, ./orchidee_ol, mpirun -f config_file, mpiexec...)

Le script sera construit dans la couche système de la machine et testera le type de configuration à lancer. En particulier, il détectera une configuration couplée à partir de l'existence de la composante CPL.

ins_job de modipsl sera modifié à terme pour supprimer l'utilisation de JobNumProcTot et utiliser à la place les paramètres MPI/OMP/NOD de lancement par éxécutable dans le config.card. Cela signifie que ins_job utilisera la procédure de lecture de ces paramètres dans libIGCM.

Cette première approche va etre développée/completée/affinée/testée sur un cas concret par Martial, Arnaud et Anne. Ce cas concret est le suivant :

• une machine : mercure SX9
• seulement MPI
• trois configurations tests : IPSLCM5A, LMDZINCA, ORCHIDEE_OL

Un nouveau point sera fait à la suite de cela.

intégration de OpenMP dans libIGCM

Pour l'instant (30/05/2011), l'intégration de MPI/OpenMP n'a été réalisé que sur titane, et est en attente d'un tag libIGCM pour être placée sur une branche libIGCM_AllPara. Les tests sont fait à partir de la config LMDZ4OR_v3 et continuerons avec IPSLCM5A.
Cette première version est accessible sur le chemin :
titane.ccc.cea.fr: /work/cont003/p86manci/LMDZ4_OR/libIGCM/

modification simple du config.card

[Executable]
Name=run_file
#D- For each component, Real name of executable, Name of executable for oasis
ATM= (gcm.e, lmdz.x, 8MPI, 4OMP)
SRF= ("", "")
SBG= ("", "")

permet dans cet exemple d'utiliser 8 processus MPI, chacun divisés en 4 tâches OpenMP.

Comment binder (fixer) les processus ?

Sur titane, on utilise automatiquement les modules "openmp" :

module load openmp/${max_omp}thds

en fonction du nombre maximum de tâches OpenMP demandées.

Sur un PC linux, il est possible de "binder" un processus à un coeur physique avec :

1. taskset -c 0 -p PID (voir ~/PROG/COURS/OpenMP/taskset)
2. On peut aussi utiliser la bibliothèque numactl qui permet un déploiment très précis des tâches en fonction des architectures (pour les experts).

Liste des tests recommandés pour valider le MPI/OpenMP

1. compilation avec OpenMP (voir /work/cont003/p86manci/LMDZ4_OR_OMP/config/LMDZ4OR_v3/AA_Make)
   1. 8MPI + 1OMP = 1 noeud et 8 coeurs
   2. 2MPI + 4OMP = 1 noeud et 8 coeurs
   3. 8MPI + 4OMP = 4 noeuds et 32 coeurs

1. compilation sans OpenMP (voir /work/cont003/p86manci/LMDZ4_OR/config/LMDZ4OR_v3/AA_Make)
   1. 8MPI + "0OMP" = 1 noeuds et 8 coeurs

Comment vérifier le bon fonctionnement de la parallélisation ?

sous linux

Sur des PC sous linux, on peut aussi utiliser les utilitaires suivants :

1. pidstat -p 12001 -t 1 4
2. top : Deux raccourcis sont à retenir pour visualiser les tâches sur l'ensembles des processus :

• "1" donne la visualisation de la charge de tous les coeurs
• "H" donne la visualisation des tâches dans la liste.

1. htop permet aussi de bien visualiser les tâches OpenMP avec l'arbre d'héritage.

sur titane

Vous allez dans le répertoire SCRATCH de vos simulation (si il est accessible). Par exemple :
/scratch/cont003/p86manci/LMDZOR/LOOMP32.5093
Le fichier "hosts" contenu dans ce répertoire contien la liste des noeuds et le nombre des tâches par noeuds de calcul.
On peut alors se connecter en intéractif sur l'un des noeuds :

ssh titane107

et éxécuter la commande top.

Tests LMDzOR sur titane

Les fichiers de Bands établi avec le mécanisme de 3 mois standard dans la configuration LMDZ4OR_v3 varient (faiblement) en fonction du nombre de processus MPI ET OpenMP. En attachement, on trouvera des exemples de fichier de bands pour les tests décris dans le paragraphe précédent :

1. compilation avec OpenMP
   1. 8MPI + 1OMP = 1 noeud et 8processeurs LOOMP_1_Bands_96x95x39_8MPI_1OMP.dat_3​
   2. 2MPI + 4OMP = 1 noeud et 8prc LOOMP4_Bands_96x95x39_2MPI_4OMP.dat_3​
   3. 8MPI + 4OMP = 4 noeuds et 32prc LOOMP32_Bands_96x95x39_8MPI_4OMP.dat_3​
2. compilation sans OpenMP
   1. 8MPI + "0OMP" = 1 noeuds et 8prc LMPIOMP3_Bands_96x95x39_8MPI_1OMP.dat_3​

Les tests effectuées avec le modèles LMDZ4/branches/LMDZ4_AR5 (rev 1483) et le modèle LMDZ5/trunk (rev 1535), il s'avère que ce modèle, lorsque ORCHIDEE est désactivé à l'éxécution (paramètre VEGET=n dans le run.def) ne conservent pas la parallélisation MPI/OpenMP.

Les simulations sans ORCHIDEE activé à l'éxécution avec le code LMDz version LMDZ4_AR5 :

1. LOOMPVEGET1 : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP)
2. LOOMPVEGET2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)

Voir ​LOOMPVEGET2vsLOOMPVEGET1

Même version mais pas d'ajustement sur trois mois (on reprend la bande au bout des trois mois des deux versions précédentes correspondantes pour les paramètres MPI/OpenMP) :

1. LOOMPVEGET3 (bande de LOOMPVEGET2) : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)
2. LOOMPVEGET4 (bande de LOOMPVEGET1) : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP)

Voir ​LOOMPVEGET4vsLOOMPVEGET3.

Voir enfin ​LOOMPVEGET4vsLOOMPVEGET3vsLOOMPVEGET2vsLOOMPVEGET1 qui montre bien que toutes ces simulations ne donnent pas les mêmes monitorings sur un an.

Les simulations sans ORCHIDEE compilé à l'éxécution avec le code LMDz version LMDZ5

(avec ajustement sur trois mois) :

1. LMDZ5OMP : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP)
2. LMDZ5OMP1 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)

Voir

​LMDZ5OMP1vsLMDZ5OMP qui montre que la nouvelle version de LMDz ne donne toujours pas les mêmes monitorings sur un an.

Enfin les simulations sur 10 ans avec la dernière version de la végétation activée :

1. compilation avec OpenMP
   1. 8MPI + 1OMP = 1 noeud et 8processeurs simulation LOOMP_1
   2. 2MPI + 4OMP = 1 noeud et 8prc : simulation LOOMP4
   3. 8MPI + 4OMP = 4 noeuds et 32prc simulation LOOMP32
2. compilation sans OpenMP
   1. 8MPI + "0OMP" = 1 noeuds et 8prc simulation LMPIOMP3

Les différences de monitorings suivant : ​LOOMP4vsLOOMP_1 ​LOOMP4vsLOOMP32 ​LOOMP4vsLMPIOMP3 et ​LOOMP32vsLMPIOMP3 montrent que les modèles sont prochent avec les changement de compilation et de parallélisation, mais que les précipitations notamment changent parfois beaucoup sur la décénnie.

On ne peut donc pas conclure sur la robustesse de la parallélisation OpenMP du modèle ORCHIDEE, tant que l'on a pas une version robuste du modèle LMDz.

Tests IPSLCM5A sur titane

La configuration couplée IPSLCM5A utilisée est la configuration standard avec les modifications suivantes :

ORCHIDEE : ​http://forge.ipsl.jussieu.fr/orchidee/svn/branches/OpenMP/ORCHIDEE

LMDZ : modification dans oasis.F90

-    LOGICAL                            :: cpl_current_omp
+    LOGICAL, SAVE                            :: cpl_current_omp

libIGCM : libIGCM prise chez Martial (en attente de commit sur une branche après le prochain tag)

IPSLCM5A : modifications à la main dans config.card, oasis.card

Tests en cours (a comparer avec piControl2) :

• 10 ans : 5 OCE MPI, 26 ATM MPI (x 1 OMP)
• 10 ans : 5 OCE MPI, 12 ATM MPI x 4 OMP

Point le 28/7/2011

Voir commit de Yann sur LMDZ là : ​http://lmdz.lmd.jussieu.fr/trac/changeset/1558

Tests avec la modif ci-dessus :

• Titane : Résultats identiques (comparaisons restarts) sur une simu de 25 jours de LMDZ seul (sans aer, sans ORCHIDEE) avec LMDR4_AR5 compilé en mode debug entre :
  • 32 process MPI, 1 thread OpenMP
  • 32 process MPI, 4 threads OpenMP

Prochaines étapes :

• tests avec activation aerosols, activation Orchidee, activation couplage ocean
• adaptation libIGCM pour vargas