Intégration de OpenMP dans LMDZOR - Dev 2010/ 2011

LMDZ

Voir : ​http://lmdz.lmd.jussieu.fr/utilisateurs/distribution-du-modele/versions-intermediaires/lmdz5-trunk-revision-1575

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 LMDz sans physique sur vargas

Ces tests sont réalisés par Ehouarn Millour. Il compile sa version (trunk LMDZ5) en mode dev. Un résumé de ces tests est là : ​ticket LMDz 35.

Tests LMDZ4_AR5 sur Titane (juin 2011)

Ces tests utilisent LMDZ4_AR5 n°1546
En MPI pur (test sur 1 jour - compil avec le mode debug - adjust=n - ok_guide=false) :

• sur mercure 1P = 4P
• sur titane 24P = 32P

En MPI-Omp (test sur 1 mois - compil avec le mode debug - adjust=n - ok_guide=false):

• sur titane 32MPIx4OMP != 32MPIx1OMP
• sur titane 32MPIx1OMP = 32MPI pur
• ne compile pas sur mercure car physiq.F est trop gros et le compilateur annule l'openmp

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 LMDZ4_AR5 avec correction 1559 (juillet)

En MPI-Omp (test sur 1 mois - compil avec le mode debug - adjust=n - ok_guide=false):

• sur titane 32MPIx4OMP = 32MPIx1OMP

En mode nudgé moyennant quelques modifications dans le code on obtient bien l'égalité également

Tests avec LMDZ5 après correction 1559

On a donc deux équilibrages de trois mois, puis utiliser leur bandes respectives pour démarrer deux nouvelles simulations sur une année complète :

1. LMDZ5OMP6 : idem LMDZ5OMP4
2. LMDZ5OMP7 : idem LMDZ5OMP5

Le multi-monitoring de comparaison ​LMDZ5OMP6vsLMDZ5OMP7 montre que les résultats se rapprochent beaucoup en PROD avec cette dernière correction. Mais ils ne sont toujours pas identiques pour les pluies notamment. Rajouter ORCHIDEE ne pourra pas donner de résultat comparatifs.

Test en mode dev sur titane

Utilisation de

• la révision 1573 pour LMDz avec cette modif :

  ===================================================================
  --- arch/arch-X64_TITANE.fcm	(revision 1573)
  +++ arch/arch-X64_TITANE.fcm	(working copy)
  @@ -6,7 +6,7 @@
   %FPP_DEF             NC_DOUBLE BLAS SGEMV=DGEMV SGEMM=DGEMM FFT_MKL
   %BASE_FFLAGS         -i4 -r8 -automatic -align all -I${MKLROOT}/include
   %PROD_FFLAGS         -O3
  -%DEV_FFLAGS          -p -g -O3 -traceback -fp-stack-check -ftrapuv
  +%DEV_FFLAGS          -p -g -O3 -traceback -fpe0 -fp-stack-check -ftrapuv
   %DEBUG_FFLAGS        -p -g -traceback
   %MPI_FFLAGS
   %OMP_FFLAGS          -openmp
  

  (mais sans les modifs de code de Arnaud pas commitées,
  voir : /work/cont003/p86manci/LMDZ5DEB_OMP/modeles/LMDZ/libf/radiation_AR4_01.F),
• et 476 de branches/OpenMP pour ORCHIDEE.

La compilation est en mode dev pour LMDz et normale pour ORCHIDEE. Les deux configurations précédentes sont reprises ici : /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4.
Le multi-monitoring de comparaison est là : ​LMDZ5dOMP1-LMDZ5dOMP2. Toujours pas de correspondance.

Je lance deux tous derniers tests avec ce source LMDz, mais sans ORCHIDEE. Ces deux simulations en mode donnent le multi-monitoring ​suivant et ne correspondent toujours pas. Les simulations LMDz, même en mode dev, ne donnent pas le même résultat sur titane pour l'instant.

Suite à la présentation des tests de Joséfine sur vargas (et un peu titane) : cf ​rev-1575, il s'avère que le choix de test (4 MPI, 2 OMP) versus (8 MPI, 1 OMP) comporte probablement une erreur due au 1 OMP du deuxième test.

J'ai donc relancé des tests avec et sans ORCHIDEE en (2 MPI, 4 OMP) pour vérifier la reproductibilité. Le couple de tests à comparer sera alors

1. LMDZ5d2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)
2. LMDZ5d3 : ATM= (gcm.e, lmdz.x, 4MPI, 2OMP)

Le multi-monitoring ​LMDZ5d2-3 montre que même si on a bien un correspondance au début de l'année, on N'A PAS de correspondance en mode DEV sur un an. Et

1. LMDZ5dOMP2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP) + SRF
2. LMDZ5dOMP3 : ATM= (gcm.e, lmdz.x, 4MPI, 2OMP) + SRF

Le multi-monitoring ​LMDZ5dOMP2-3 montre que même si on a bien un correspondance au début de l'année, on N'A PAS de correspondance en mode DEV sur un an. On voit que la réponse de surface est tout de même très similaire. Mais on ne peut pas conclure sur la parallélisation OpenMP de ORCHIDEE.
De même en diminuant l'optimisation à la compilation de LMDz5 ( -O2 à la place de -O3 ), on n'obtient toujours pas une égalité : ​LMDZ5d2-O2_LMDZ5d3-O2.

Par contre avec l'optimisation minimale à la compilation de LMDZ5; -O1 on obtient bien une égalité parfaite des deux simulations. ​LMDZ5d2-O1_LMDZ5d3-O1. Il semble donc bien qu'une simulation avec ORCHIDEE puisse être validée avec LMDz compilé avec ce niveau d'optimisation.

On construit donc deux nouvelles simulations avec LMDz compilé avec -O1 et ORCHIDEE et IOIPSL compilés avec -O3 :

1. LMDZ5dOMP2-O1 : ATM= (gcm.e, lmdz.x, 8MPI, 4OMP) + SRF
2. LMDZ5dOMP3-O1 : ATM= (gcm.e, lmdz.x, 4MPI, 8OMP) + SRF

Nouveau Tests LMDZOR avec correction 1559 (12/11 - 02/12)

LMDz et ORCHIDEE compilés en -O1

Avec une compilation en optimisation -O1 (identique à la précédente LMDZ5dOMP2 et 3), le modèle LMDZ5dOMP plante en cours d'année (erreur assert)

• LMDZ5dOMP2-O1-O1 (10/12/11) - 8MPI, 4OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP2-O1-O1
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP2-O1-O1/
• LMDZ5dOMP3-O1-O1 (12/12/11) - 4MPI, 8OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP3-O1-O1
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP3-O1-O1/

Je ne comprends pas ce résultat car LMDz tourne sans problème sans ORCHIDEE ! cf courriel ESCI le 09/01/2012 intitulé "erreur LMDZOROMP sur titane : appel à idée ..."

LMDz compilé en -O0 et ORCHIDEE compilé en -O1

Avec LMDz compilé en DEBUG, on obtient une simulation de un mois (mais pas un an) :

• LMDZ5dOMP2-O0-O1(-1M) (09/01/11) - 8MPI, 4OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP2-O0-O1-1M
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP2-O0-O1
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP2-O0-O1/
• LMDZ5dOMP3-O0-O1(-1M) (09/01/11) - 4MPI, 8OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP3-O0-O1-1M
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP3-O0-O1
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP3-O0-O1/

Les différences de restart

cd /scratch/cont003/p86manci
cdo diffv LMDZ5dOMP2-O0-O1-1M_19800130_sechiba_rest.nc LMDZ5dOMP3-O0-O1-1M_19800130_sechiba_rest.nc
cdo diffv LMDZ5dOMP2-O0-O1-1M_19800130_restart.nc LMDZ5dOMP3-O0-O1-1M_19800130_restart.nc

pour ORCHIDEE et LMDz donnent des erreurs importantes.

LMDz et ORCHIDEE compilés en -O0

Le modèle a alors été compilé en mode DEBUG total (-O0 pour les deux modèles).

Les simulations sur un an dans ce mode de compilation sont :

• LMDZ5dOMP2-O0-O0 (09/01/12) - 8MPI, 4OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP2-O0-O0
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP2-O0-O0/
• LMDZ5dOMP3-O0-O0 (09/01/12) - 4MPI, 8OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP3-O0-O0
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP3-O0-O0/

La simulation LMDZ5dOMP2-O0-O0 a tourné sur un an, mais pas la simulation LMDZ5dOMP3-O0-O0.

J'ai donc refait des simulations sur des temps plus court (un seul jour), mais avec des sorties HF dans LMDz (en mettant :

     LMDZ_ecrit_mth=.02083333333333333333
[...]
     LMDZ_sed physiq.def phys_out_filekeys "y n n n n"
! #"${OK_mensuel} ${OK_journe} ${ok_hf} ${OK_instan} ${OK_les}"

dans lmdz.driver et sans ajustement (en rajoutant

 	    if ( [ X${LMDZ_Bands_file_name} != X ] && [ -f ${LMDZ_Bands_file_name} ] ) ; then
  		IGCM_sys_Get ${LMDZ_Bands_file_name} Bands_${RESOL_ATM_3D}_${ATM_PROC_MPI}prc.dat ; IGCM_sys_Chmod u+w Bands_${RESOL_ATM_3D}_${ATM_PROC_MPI}prc.dat

dans le même fichier.

Avec l'ajustement, sur un jour on obtient des différences dans la dynamique de l'atmosphères qui se répercutent dans ORCHIDEE au début du troisième pas de temps (du fait du pas de temps d'une heure pour le schéma radiatif).

Pour une simulation de un jour, sans routage et sans ajustement :

• LMDZ5dOMP2-O0-O0-1D-R1-2 (04/02/2012)
• LMDZ5dOMP3-O0-O0-1D-R1-2 (04/02/2012)

On a plus ces différences.

J'ai donc relancer les deux simulations annuelles, sans ajustement :

• LMDZ5dOMP2-O0-O0-1 (04/02/12) - 8MPI, 4OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP2-O0-O0-1
  • /scratch/cont003/p86manci/RUN_DIR/747611/LMDZOR/LMDZ5dOMP2-O0-O0-1.18624
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP2-O0-O0-1/
• LMDZ5dOMP3-O0-O0-1 (04/02/12) - 4MPI, 8OMP :
  
  • /work/cont003/p86manci/LMDZ5DEB_OMP/config/LMDZOR_v4/LMDZ5dOMP3-O0-O0-1
  • /scratch/cont003/p86manci/RUN_DIR/747610/LMDZOR/LMDZ5dOMP3-O0-O0-1.13026
  • /dmnfs/cont003/p86manci/IGCM_OUT/LMDZOR/TEST/CLIM/LMDZ5dOMP3-O0-O0-1/

Toujours sans succès (la simulation plante avant un an)...

Voir la fin de /scratch/cont003/p86manci/RUN_DIR/747611/LMDZOR/LMDZ5dOMP2-O0-O0-1.18624/out_lmdz.x.out.0001 ou /scratch/cont003/p86manci/RUN_DIR/747610/LMDZOR/LMDZ5dOMP3-O0-O0-1.13026/out_lmdz.x.out.0001 :

 nrerror: an assertion failed with this tag:regr_pr_av paprs
 program terminated by assert_v

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