wiki:IntegrationOpenMP

Version 41 (modified by acosce, 12 years ago) (diff)

--

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

Commandes et entêtes des différentes machines

Les entêtes des jobs et les commandes sont détaillés pour les différentes machines. Il y a le lancement d'un exécutable séquentiel ou parallèle et de plusieurs exécutables.

Evolution du travail

Exemple de config.card

ATM= (gcm.e, lmdz.x, 16MPI, 2OMP)

libIGCM

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/

12/8/2011

Martial a intégré dans libIGCM_sys/vargas ce qu'il faut pour lancer une execution.

  • Test fait sur vargas avec IPSLCM5A, MPI seulement. NEMO sur 5 MPI, oasis sur 1 et LMDZ sur 26. Fonctionne. Impeccable.
  • Modifications à intégrer dans :
    • PARAM/run.def (fft=n)
    • config.card (suppression de jobrunoptions, nb procs global et par executable)
    • COMP/lmdz.driver (gestion Bands : XXXX_Bands_96x95x39_26MPI_1OMP.dat_3)
    • COMP/oasis.driver (namcouple et plus de création de runfile là)
    • COMP/lmdz.card

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).

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

LMDZ5 sur Curie

test du 10 septembre 2012

  • Version LMDZ5/trunk rev 1651 (= head du 10 septembre 2012)
  • Compilation avec les options
    • -v false
    • -debug
    • -parallel mpi_omp
  • execution avec adjust=n
  • simulation test de 1 jour avec comparaison du fichier restart.nc
    LMDZ 4 MPI*8 OMP = LMDZ 16 MPI * 4 OMP
    
  • Version LMDZ5/trunk rev 1651 (= head du 10 septembre 2012)
  • Compilation avec les options
    • -v false
    • -debug
    • -parallel mpi
  • execution avec adjust=n
  • simulation test de 1 jour avec comparaison du fichier restart.nc
    LMDZ 32 MPI = les tests précédents avec OpenMP
    
  • Après un mois de simulation
    LMDZ 32 MPI = LMDZ 16 MPI * 8 OMP 
    

Attachments (5)

Download all attachments as: .zip