Version 43 (modified by acosce, 12 years ago) (diff) |
---|
Intégration de la parallélisation mixte MPI-OpenMP dans les configurations de l'IPSL
-
Intégration de la parallélisation mixte MPI-OpenMP dans les configurations …
- Objectif == Utiliser au maximum les machines de type SMP (vargas, titane, …
- Description du travail == Voir le document là : OpenMP.pdf
- Commandes et entêtes des différentes machines
-
Evolution du travail
- Exemple de config.card
- libIGCM
- Réunion "cahier des charges" le 7/10/2010 au LSCE
- intégration de OpenMP dans libIGCM
- 12/8/2011
- LMDZ
- Liste des tests recommandés pour valider le MPI/OpenMP
- Comment vérifier le bon fonctionnement de la parallélisation ?
- Tests LMDz sans physique sur vargas
- Tests LMDZ4_AR5 sur Titane (juin 2011)
- Tests LMDzOR sur titane
- Tests LMDZ4_AR5 avec correction 1559 (juillet)
- Tests avec LMDZ5 après correction 1559
- Nouveau Tests LMDZOR avec correction 1559 (12/11 - 02/12)
- Tests IPSLCM5A sur titane
- Point le 28/7/2011
- TESTS ANNE SEPTEMBRE 2012
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.
- Entêtes et commandes SX9 : IntegrationOpenMP/EnteteCommandesSX
- Entêtes et commandes vargas : IntegrationOpenMP/EnteteCommandesVargas
- Entêtes et commandes jade : IntegrationOpenMP/EnteteCommandesJade
- Entêtes et commandes titane : IntegrationOpenMP/EnteteCommandesTitane
- Entêtes et commandes curie : IntegrationOpenMP/EnteteCommandesCurie
Evolution du travail
Exemple de config.card
ATM= (gcm.e, lmdz.x, 16MPI, 2OMP)
libIGCM
- Voir branche dédiée : https://forge.ipsl.jussieu.fr/libigcm/browser/branches/libIGCM_MPI_OpenMP
- 29 mars 2012 : merge avec libIGCM trunk. https://forge.ipsl.jussieu.fr/libigcm/browser/trunk/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 :
- taskset -c 0 -p PID (voir ~/PROG/COURS/OpenMP/taskset)
- 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
Liste des tests recommandés pour valider le MPI/OpenMP
- compilation avec OpenMP (voir /work/cont003/p86manci/LMDZ4_OR_OMP/config/LMDZ4OR_v3/AA_Make)
- 8MPI + 1OMP = 1 noeud et 8 coeurs
- 2MPI + 4OMP = 1 noeud et 8 coeurs
- 8MPI + 4OMP = 4 noeuds et 32 coeurs
- compilation sans OpenMP (voir /work/cont003/p86manci/LMDZ4_OR/config/LMDZ4OR_v3/AA_Make)
- 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 :
- pidstat -p 12001 -t 1 4
- 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.
- 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 :
- compilation avec OpenMP
- 8MPI + 1OMP = 1 noeud et 8processeurs LOOMP_1_Bands_96x95x39_8MPI_1OMP.dat_3
- 2MPI + 4OMP = 1 noeud et 8prc LOOMP4_Bands_96x95x39_2MPI_4OMP.dat_3
- 8MPI + 4OMP = 4 noeuds et 32prc LOOMP32_Bands_96x95x39_8MPI_4OMP.dat_3
- compilation sans OpenMP
- 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 :
- LOOMPVEGET1 : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP)
- 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) :
- LOOMPVEGET3 (bande de LOOMPVEGET2) : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)
- 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) :
- LMDZ5OMP : ATM= (gcm.e, lmdz.x, 8MPI, 1OMP)
- 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 :
- compilation avec OpenMP
- 8MPI + 1OMP = 1 noeud et 8processeurs simulation LOOMP_1
- 2MPI + 4OMP = 1 noeud et 8prc : simulation LOOMP4
- 8MPI + 4OMP = 4 noeuds et 32prc simulation LOOMP32
- compilation sans OpenMP
- 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 :
- 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.
- 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 :
- LMDZ5OMP4 : idem LMDZ5OMP2
- 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 :
- LOOMPVEGET6, équivalent de LOOMPVEGET3 (bande de LOOMPVEGET2) : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)
- 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 :
- LMDZ5OMP6 : idem LMDZ5OMP4
- 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
- LMDZ5d2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP)
- 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
- LMDZ5dOMP2 : ATM= (gcm.e, lmdz.x, 2MPI, 4OMP) + SRF
- 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 :
- LMDZ5dOMP2-O1 : ATM= (gcm.e, lmdz.x, 8MPI, 4OMP) + SRF
- 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
TESTS ANNE SEPTEMBRE 2012
LMDZ5 sur Curie
- 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
LMDZOR sur Titane
branche orchidee openmp
configuration :
- LMDZ5 trunk 1651
- Orchidee branches/OpenMP rev 990
Compilation :
- mpif90 -openmp
- LMDZ avec -debug
- ORCHIDEE avec -p -g -O3 -traceback -fp-stack-check -ftrapuv
- SANS la clef ORCHIDEE_NOOPENMP --> donc utilisation de surf_land_orchidee_mod.f90 dans LMDZ
Simulation :
- adjust=n
- 1 jour
- comparaison des fichiers restart de LMDZ et ORCHIDEE
32 MPI * 1 OMP = 24 MPI * 1 OMP
Attachments (5)
- OpenMP.pdf (26.6 KB) - added by aclsce 14 years ago.
-
LOOMP4_Bands_96x95x39_2MPI_4OMP.dat_3
(200 bytes) -
added by mmaipsl 13 years ago.
Bandes pour compile OpenMP 2MPI 4OMP
-
LOOMP32_Bands_96x95x39_8MPI_4OMP.dat_3
(800 bytes) -
added by mmaipsl 13 years ago.
Bandes pour compile OpenMP 8MPI 4OMP
-
LOOMP_1_Bands_96x95x39_8MPI_1OMP.dat_3
(800 bytes) -
added by mmaipsl 13 years ago.
Bandes pour compile OpenMP 8MPI 1OMP
-
LMPIOMP3_Bands_96x95x39_8MPI_1OMP.dat_3
(800 bytes) -
added by mmaipsl 13 years ago.
Bandes pour compile MPI seul 8MPI '0'OMP
Download all attachments as: .zip