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.

Correction LMDz 1557-1558

voir ​correction OpenMP LMDz exner_hyb_p.F.

Plusieurs simulations ont élé lancées après avoir patché et recompiler les versions avec cette correction.

Deux simulations sans ORCHIDEE, resp. clones de LMDZ5OMP1 et LMDZ5OMP et compilé avec le même code patché par 1558 :

1. LMDZ5OMP2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP) Voir ​LMDZ5OMP2vsLMDZ5OMP1vsLMDZ5OMP montre que le patch rapproche les simulations LMDZ5OMP et LMDZ5OMP2, mais sans obtenir le même résultat.
2. LMDZ5OMP3 : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP) Voir ​LMDZ5OMP3vsLMDZ5OMP. LMDZ5OMP3 n'est pas identique à la précédente. La correction 1558 modifie donc le résultat.

Voir aussi la différence entre ces deux simulations : ​LMDZ5OMP3_vs_LMDZ5OMP2 qui montre qu'elles se rapprochent bien avec la correction du bogue.

On se pose la question (il est temps !) de savoir si les redémarrages mettent en cause le défaut de reproduction de la parallélisation OpenMP. On a donc lancé deux nouvelles simulations sur une année complète sans redémarrage :

1. LMDZ5OMP4 : idem LMDZ5OMP2
2. LMDZ5OMP5 : idem LMDZ5OMP3 Voir ​LMDZ5OMP5vsLMDZ5OMP3 LMDZ5OMP5 n'est pas identique à la précédente. Les redémarrages influencent les résultats.

On a pas désactivé les ajustements de la parallélisation dans ces deux simulations.

On obtient malheureusement toujours pas de précips correspondantes; ​LMDZ5OMP5vsLMDZ5OMP4. Est-ce du à l'ajustement qui s'est prolongé toute l'année. Je passe à la correction de bogue suivante (E. Millour).

Avec la même version du source que LOOMPVEGET1, 2, 3 et 4, mais patché par 1558 :

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

Voir ​LOOMPVEGET6vsLOOMPVEGET5vsLOOMPVEGET4vsLOOMPVEGET3. Pas de modification ?? J'abandonne l'utilisation de l'OpenMP dans la version LMDZ4_AR5 pour ces tests. En effet, beaucoup d'autres corrections on été faites sur la nouvelle version LMDZ5.

Correction LMDz 1559

voir ​correction OpenMP LMDz exner_milieu_p.F.

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