Aller au contenu. | Aller à la navigation

Outils personnels

Navigation
Vous êtes ici : Accueil / Pour utiliser LMDZ / FAQ / Exécution

Exécution

Questions sur l'exécution de LMDZ
Montre ou Cacher la réponse Comment retrouver la physique utilisée pour le rapport 4 du GIEC ?
Vous avez téléchargé la dernière version (head) de LMDZ4. Vous utilisez le répertoire "phylmd" contenant la dernière version de la physique. Vous désirez néanmoins retrouver la physique utilisée pour le rapport 4 du GIEC (AR4). Remarque : si vous utilisez d'anciens sources, le iflag_con doit valoir 3. Avec le nouvelle version, et pour retrouver les anciens résultats, il faut utiliser iflag_con=30 qu'il faut comprendre comme 3v0.

Vous pouvez retrouver l'ancienne physique simplement en choisissant certaines valeurs dans les fichiers "*.def", à l'exécution :

Fichier
Variable signification
AR4 Tiedtke
défaut
Nouvelle physique
physiq
iflag_wake
Activation des wake
0 0 0 1
physiq iflag_coupl
Couplage entre CL et convection
0 0 0 1
physiq iflag_ratqs
Choix pour le "ratqs" stable
0 0 1 1
physiq iflag_thermals
Version des thermiques
0 : ajustement sec
13 : thermiques
14 : thermiques + "bidouilles" pour les stratocumulus de bord Est
0 0 0 14
physiq iflag_pbl
Version de la couche limite diffuse
1: LMD, 8 : Mellor et Yamada
1 1 1
8
physiq
iflag_con
Choix du schéma de convection
30
2 2 3
physiq
iflag_cldcon
Choix du schéma pour caculer les nuages
convectifs.
3
-2 1
4
physiq iflag_clos
Fermeture (pour iflag_con=3)
0 0 1 2
Montre ou Cacher la réponse Comment choisir la résolution ?
Quelles sont les résolutions standard de LMDZ et quelles sont les degrés de liberté sur le choix de la grille ?

La réponse est de deux ordres :
D'abord, il y a certaines contraintes qu'il est préférable de respecter pour des raisons d'efficacité numérique et qui sont décrites ci-dessous.
Ensuite, il est sans doute souhaitable de se placer au maximum sur des grilles communes, quand c'est possible.

Pour le développement du modèle intégré de l'IPSL par exemple, deux
résolutions sont pour l'instant retenues.
Une résolution très grossière de 72x45.
Une résolution plus fine de 96x71.
Les deux résolutions diffèrent par la parité des latitudes et donc par la répartition des points à l'équateur ce qui peut avoir un impact sur le couplage avec l'océan mais on ne sait pas dans quel mesure.

Pour ceux qui veulent jouer avec d'autres grilles, régulières ou zoomées,

Les contraintes techniques sont les suivantes :

1. Rapport entre le nombre de points en longitude et en latitude.

Pour les grilles régulières au moins, nous privilégions des grilles avec une résolution en degrés plus fine en latitude qu'en longitude afin d'obtenir une résolution relativement isotrope dans les moyennes latitudes.
Une grille régulière 2ox2o, par exemple, correspond à des mailles isotropes à l'équateur mais extrêmement étirées en latitude dans les hautes latitudes.
On peut même envisager d'utiliser des grilles avec le m^eme nombre de points en longitude et en latitude pour resoudre finement les structures latitudinales, essentielles dans les tropiques.

2. Prendre un multiple de 8.

Pour des raisons d'efficacité numérique du schéma de transport, il est préférable de choisir un nombre de point en longitude (iim) multiple de 8 (ou, à défaut 4).
En effet, pour éviter de réduire indéfiniment le pas de temps d'advection pour palier au problème posé par le resserement des mailles en logitude près des pôles, on groupe à partir d'une certaine latitude les mailles 2 par 2 en longitude, puis 4 par 4, puis 8 par 8 en arrivant au pôle.
Ce nombre peut éventuellement être changer en modifiant le paramètre parameter (ngroup=3) dans le sous-programme dyn3d/groupe.F (ngroup=3 pour im multiple de 2**3=8).
Mais, prendre une valeur plus petite de ngroup risque de conduire à devoir diminuer de façon notable le pas de temps d'advection.

3. Choisir une grille physique avec des diviseurs.

Le code radiatif est extrêmement coûteux en taille mémoire notamment parce qu'il contient un grand nombre de tableaux locaux en im*jm*lm*lm.
Pour éviter d'avoir des éxecutables excessivement gros, il est possible de demander au code de calculer le transfert radiatif sur des sous domaines (merci Laurent Li).
Ces sous domaines doivent avoir une dimension diviseur de la dimension totale de la grille horizontale physique, klon.

La grille horizontale de la physique est représentée par une dimension horizontale unique correspondant à tous les points de la grille dynamique sans la duplication des points en -pi et +pi et avec un seul point par pôle soit:
klon=2+iim*(jjm-1)
2 est toujours diviseurs si iim l'est (ce qui est nécessaire pour le point 2).
Mais, à part ça, c'est pas toujours évident...
Une fois qu'un diviseur kdlon de klon est trouvé, il suffit de placer dans le répertoire phylmd un fichier raddim.im.jm.h contenant la valeur de kdlon.
Ce fichier sera automatiquement copié sur raddim.h quand vous effectuerez la compilation avec makegcm.
Par exemple
==> raddim.96.72.h <==
INTEGER kdlon, kflev
PARAMETER (kdlon=487,kflev=klev)
sera copié sur raddim.h si on effectue la comande
makegcm -d 96x72x19 gcm

Si le fichier raddim.im.jm.h n'existe pas pour la résolution demandée, makegcm vous prévient (mais vous ne le verrez pas parce que c'est noyé dans plein d'autres bla bla) et écrase le fichier raddim.h avec le fichier
==> raddim.defaut.h <==

       INTEGER kdlon, kflev
PARAMETER (kdlon=klon,kflev=klev)

Pour les résolutions supérieures à 72x45, je propose de privilégier les grilles suivantes: 96x72, 192x145, 290x180
avec les fichiers suivants
==> raddim.96.72.h <==

       INTEGER kdlon, kflev
PARAMETER (kdlon=487,kflev=klev)

==> raddim.192.145.h <==
INTEGER kdlon, kflev
c      klon=27650=50*553=10*2765
PARAMETER (kdlon=2765,kflev=klev)

==> raddim.290.180.h <==

c      klon=51912=17304*3=12978*4=8652*6=7416*7=6489*8
c     = 5768*9 = 4326*12 = 3708*14 = 2884*18 = 2472*21 = 2163*24
c     = 1854*28 = 1442*36 = 1236*42 = 927*56 = 824*63 = 721*72
c     = 618*84 = 504*103 = 412*126 = 309*168 = 252*206
       INTEGER kdlon, kflev
       PARAMETER (kdlon=1442,kflev=klev)

Mais, n'hésitez pas, en phase de développement, à utiliser des versions beaucoup plus légères, à l'huile végétale, comme 32x24 ou 48x32.

Enfin, pour ceux qui voudraient chosir leur nouvelle grille et trouver des resolutions avec des diviseurs pour raddim, ils peuvent
compiler et executer le petit programme FORTRAN choixdim.F :

      program choixdim
implicit none
integer im, jm, ngrid, div,i

print*,'im=?'
read(*,*) im
print*,'jm=?'
read(*,*) jm
ngrid=im*(jm-1)+2
print*,'ngrid=',ngrid
do i=1,int(sqrt(float(ngrid)))+1
if (mod(ngrid,i).eq.0) then
print*,ngrid/i,i,(ngrid/i)*i
endif
enddo
end
Montre ou Cacher la réponse Quelles variables/paramètres met-on dans les fichiers *.def?
Quels sont les paramètres à renseigner dans les fichier *.def pour que LMDZ s'exécute correctement? Et d'ailleurs que sont et que signifient toutes ces variables que l'on trouve dans ces fichiers *.def?

Vous trouverez ici une page à jour qui précise ce que sont les fichiers *.def, quelles variables ils peuvent contenir, ainsi que quelques explications sur leurs rôles et valeurs associées.

Montre ou Cacher la réponse Comment faire tourner LMDZ en parallèle sur mon PC Linux?
Vous voulez faire tourner LMDZ en local sur votre PC Linux; et comme c'est un multicoeur, autant compiler et faire tourner le code en parallèle. Mais que faut-il faire pour y parvenir?

LMDZ peut être compilé et exécuté en parallèle en mode MPI ou OpenMP, voire en mode hybride MPI+OpenMP. Cela demande néanmoins quelques apports extérieurs, typiquement, qu'une librairie MPI soit également installée sur la machine, et que le compilateur employé reconnaisse les directives OpenMP (c'est le cas d'une majorité: ifort, gfortran, xlf, pgfortran, ...).

Quelques notes et conseils pour compiler et exécuter LMDZ en parallèle sont regroupées dans cette page.

Montre ou Cacher la réponse Comment réduire les sorties à une partie du domaine horizontal ?
Dans une exécution parallèle.

En parallèle, ce n'est possible qu'avec les sorties contrôlées par XIOS. Compiler avec XIOS (option -io xios de makelmdz_fcm). Choisir :

ok_all_xml = TRUE
dans run.def. Copier les fichiers Deflists/*.xml dans le répertoire d'exécution. Dans context_lmdz.xml, dans la partie <domain_definition>, dans :
<domain id="dom_glo" data_dim="2" />
ajouter la description du domaine souhaité. Par exemple :
<domain id="dom_glo" data_dim="2" zoom_ni="14" zoom_ibegin="105"
zoom_nj="11" zoom_jbegin="3" />
pour un domaine de 14 × 11 points à partir du point i = 105, j = 3.

 

Montre ou Cacher la réponse Comment extraire les données sur un point de plantage?
Pour étudier un plantage dans le modèle, on voudrait extraire un historique des champs produits par le modèle pour le point qui "plante". Comment faire?

IOS permet de sortir des champs à haute fréquence sur une région réduite ou un point en modifiant simplement les fichiers de contrôle xml. Lors d'un plantage, on peut donc suivre l'évolution des champs sur un point de grille jusqu'au moment du plantage.

ATTENTION: contrairement à ce que l'on pourrait penser, lorsque XIOS, en mode serveur, reçoit un ABORT, il aborte tout de suite sans écrire ce qu'il peut rester dans ses tampons. On n'est donc pas certain d'avoir les données jusqu'au moment du plantage. Il est donc nécessaire de relancer le job en mode attaché pour être sûr d'avoir tout l'historique jusqu'au plantage. Voir cette note dans le cas d'un plantage d'un couplé "récent" (c'est-à-dire dans le cas où les points terre sont ignorés par Nemo)

Mode d'emploi (pour une configuration modipsl):

  1. repérer le point qui plante dans la sortie LMDZ. On cherche des lignes de ce type:
  2. déterminer les i et j globaux du point à partir de la longitude et de la latitude données ci-dessus, le plus simple (mais le plus long) étant de déterminer ces indices à partir des variables lon et lat contenues dans un fichier histmth.nc en comptant les indices à partir d'une sortie ncdump du fichier (si on pense devoir faire souvent ce travail, il sera utile de dresser un tableau de correspondance indices/lon/lat, exemple ici pour la résolution horizontale standard 144x142),
    ici le point a pour longitude 165° E et latitude 67.18° N. Cela correspond 
    pour XIOS1 
        à i = 139 et j = 19 sur la grille globale
    pour XIOS2 
        à i = 138 et j = 18 sur la grille globale 
        (XIOS2 indice les tableaux à la mode C soit à partir de 0)
  3.  préparer deux nouveaux fichiers xml dans modeles/LMDZ/DefLists, copies des fichiers context_lmdz.xml et file_def_histins_lmdz.xml (on peut appeler ces copies context_lmdz_debug.xml  et file_def_histins_lmdz_debug.xml, respectivement).
    ⇒ dans context_lmdz_debug.xml, on redéfinit le domaine de sortie qui ne contiendra que notre point de plantage:
         pour XIOS1 on remplace la ligne
    <domain id="dom_glo" data_dim="2" />
    
    par la ligne suivante :
    <domain id="dom_glo" data_dim="2" zoom_ni="1" zoom_ibegin="139" zoom_nj="1" zoom_jbegin="19" />
    et pour XIOS2 on définit le bloc <domain-definition> de la manière suivante :
       <domain_definition>
         <domain id="dom_glo" data_dim="2" />
         <domain id="dom_glo_zoom" domain_ref="dom_glo">
            <zoom_domain ibegin="138" ni="1" jbegin="18" nj="1"/>
         </domain>
       </domain_definition>
    
    on peut aussi supprimer les lignes définissant les fichiers de sorties autres que histins , ils ne serviront pas

    ⇒ dans file_def_histins_lmdz_debug.xml, on indique à XIOS que l'on veut faire des sorties instantanées à tous les pas de temps et en écrivant à tous les pas de temps
          on remplace la ligne
    <file id="histins" name="Xhistins" output_freq="1ts" output_level="4" enabled=".FALSE.">
    par la ligne
    <file id="histins" name="Xhistins" output_freq="1ts" output_level="10" enabled=".TRUE." sync_freq="1ts" >
    

    Pour XIOS2, on indique aussi le numéro du pas de temps à partir duquel on souhaite sortir chaque pas de temps (si on veut sortir les instantanés à partir du 5ème jour d'une simulation où le pas de temps de la physique est de 10 minutes, le numéro du pas de temps sera = day_step / iphysiq * (5-1) = 576 ) et la ligne sera donc la suivante:

        <file id="histins" name="Xhistins" output_freq="1ts" record_offset="-576" output_level="10"  enabled=".TRUE." sync_freq="1ts" >  
    et on indique que le domaine de sortie des variables sera le domaine zoomé (un point donc) défini ci-dessus dans le fichier context_lmdz_debug.xml en rajoutant l'attribut domain_ref="dom_glo_zoom" à toutes les balises <field_group>. Par exemple, la ligne
        <field_group operation="instant" freq_op="1ts>  
    devient
        <field_group operation="instant" freq_op="1ts" domain_ref="dom_glo_zoom">
  4. se déplacer dans le répertoire de soumission habituel et préparer la soumission de débogage:
    ⇒ dans COMP/lmdz.card, indiquer qu'on utilise les fichiers *debug.xml,
         on remplace les lignes
            (${MODIPSL}/modeles/LMDZ/DefLists/context_lmdz.xml, . )            ,\
            (${MODIPSL}/modeles/LMDZ/DefLists/file_def_histins_lmdz.xml, . )   ,\    
    par
            (${MODIPSL}/modeles/LMDZ/DefLists/context_lmdz_debug.xml, context_lmdz.xml )            ,\
            (${MODIPSL}/modeles/LMDZ/DefLists/file_def_histins_lmdz_debug.xml, file_def_histins_lmdz.xml )   ,    \    
    ⇒ dans config.card et Job, indiquer qu'on passe en mode attaché pour XIOS,
    pour config.card,
              ♦ commenter la section [IOS] et les lignes IOS= dans les sections [ListOfComponents] et [Executable]
    pour Job,
              ♦ refaire un ins_job et vérifier que le #MSUB -n indique bien 1 processeur de moins qu'en mode serveur
  5. faire le clean_PeriodLenght et re-soumettre le job
  6. à la fin du job, l'historique de sorties instantanées sur le point qui nous intéresse se trouve dans un fichier appellé  Xhistins_0.nc qu'on aura soit sauvegardé à un endroit particulier par le biais du lmdz.card ou qu'on trouvera dans le répertoire d'exécution du job.

    ATTENTION! : pour des raisons de synchronisation entre modèles (probablement), le job ne s'arrête pas "proprement" et va s'arrêter en "time limit exceedeed". Vous pouvez ajuster le temps requis dans l'entête du job pour tenir compte de cet état de fait. La cause de ce problème est à l'étude.
     

Cas du couplé "récent"

ATTENTION! :
en configuration couplée ocean-atmosphère (IPSLCM), l'utilisation du mode attaché XIOS pour NEMO ne fonctionne pas. Afin d'extraire les données sur un point de plantage (cf ci-dessus), il faut donc prélablement désactiver les sorties NEMO. Pour cela, il suffit de commenter la définition des fichiers outputs de NEMO dans le fichier "context_nemo.xml":

  1. Chercher où se trouve le fichier "context_nemo.xml"
    > grep context_nemo.xml COMP/opa9.card
    (${MODIPSL}/modeles/NEMOGCM/CONFIG/ORCA1_LIM3_PISCES/EXP00/context_nemo.xml , context_nemo.xml    ), \
  2.  Commenter les lignes relatives aux définitions des fichiers de sorties en éditant le fichier context_nemo.xml trouvé ci-dessus (e.g ${MODIPSL}/modeles/NEMOGCM/CONFIG/ORCA1_LIM3_PISCES/EXP00/context_nemo.xml )

     <!-- <file_definition src="./file_def_nemo-opa.xml"/>     <\!--  NEMO ocean dynamics                     -\-> -->
     <!-- <file_definition src="./file_def_nemo-lim.xml"/>     <\!--  NEMO ocean sea ice                      -\-> -->
     <!-- <file_definition src="./file_def_nemo-pisces.xml"/>     <\!--  NEMO ocean biogeochemistry with PISCES  -\-> -->

 

Montre ou Cacher la réponse Comment boucher des trous dans le workflow CMIP6?
Dans l'état actuel du modèle couplé IPSLCM6.1.[1234], il peut arriver que certaines séries temporelles de variables soient incomplètes (a priori les variables cl?calipso issues du simulateur COSP dans LMDZ). En attendant de résoudre le problème dans le code, il est nécessaire de reboucher les trous constatés dans ces séries temporelles en rejouant les années manquantes.



Nous vous recommandons la procédure suivante:
On prend pour exemple la simulation CM61-LR-2xCO2-01

  1. Repérer les trous dans les séries.
     

Il est nécessaire de bien repérer et noter les variables et les années concernées par ces trous. On utilise pour cela les outils de vérification mis à disposition par G. Levavasseur qu'on trouvera dans la checklist ici:

https://forge.ipsl.jussieu.fr/igcmg/wiki/IPSLCM6/IPSL-CM6A-LR#V%C3%A9rificationsencoursdesimulation

en particulier l'outil nctime -overlap.

Le résultat de nctime -overlap sur la simulation prise en exemple donne pour les séries temporelles de la variable clhcalipso:

Shortest path found WITH overlaps:
  clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_185001-199912.nc
[ clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_195901-199912.nc <-- to remove ]
[ clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_191301-199912.nc <-- to remove ]
[ clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_193801-199912.nc <-- to remove ]

Le problème étant que XIOS recrée un fichier avec une nouvelle date de départ quand il lui manque un pas de temps, on en déduit de la liste ci-dessus que les années 1912, 1937 et 1958 manquent dans la série temporelle. On peut s'en assurer en utilisant l'outil cdo tinfo sur ces 4 fichiers pour vérifier les dates effectivement contenues dans ces fichiers.

  1. Relancer la simulation pour reboucher les trous:
     

Il s'agit maintenant de relancer une simulation parallèle à la simulation originale sur les années manquantes pour boucher les trous des séries temporelles. On prend comme exemple ici l'année à refaire 1958 et on appellera ici CM61-LR-2xCO2-01-REDO-1958, la nouvelle simulation

  • on copie le répertoire original
cp -R CM61-LR-2xCO2-01 CM61-LR-2xCO2-01-REDO-1958
  • on fait du ménage dans le répertoire CM61-LR-2xCO2-01-REDO-1958
(rm -rf Debug Script* run.card Job*)
  • on édite le config.card de la simulation CM61-LR-2xCO2-01-REDO-1958 pour
    • renommer la simulation
      JobName=CM61-LR-2xCO2-01-REDO-1958
    • positionner DateBegin et DateEnd aux bonnes valeurs
      DateBegin=1958-01-01        
      DateEnd=1958-12-31   
      pour rejouer l'année 1958
    • positionner les bonnes valeurs pour les restarts:
      #D- Last day of the experience used as restart for this component if Restart=y         
      RestartDate=1957-12-31         
      #D- Define restart simulation name for all components         
      RestartJobName=CM61-LR-2xCO2-01         
      #D- Path Server Group Login         
      RestartPath=/ccc/store/cont003/gencmip6/p86fair/IGCM_OUT/IPSLCM6/PROD/abrupt-2xCO2 

Attention, si vous n'avez gardé que certaines années de vos restarts, il faudra rejouer plus d'années (vous rapprocher de L. Fairhead ou M.-A. Foujols)

  • on s'assure qu'on a bien
    Reproducibility_after_restart= y   
    dans COMP/opa9.card
  • enfin pour que les nouveaux fichiers aient la bonne année de référence et s'accordent avec le calendrier de la simulation originale , il faut mettre le paramètre LMDZ raz_date à 0 dans le fichier run.def. Pour cela, on commente les lignes suivantes dans DRIVER/lmdz.driver
        #    if [ ${CumulPeriod} -eq 1 ] ; then     
        #        IGCM_comp_modifyDefFile blocker run.def raz_date  1     
        #    else     
              IGCM_comp_modifyDefFile blocker run.def raz_date  0     
        #    fi
  • on lance un ../../../libIGCM/ins_job
  • on soumet le Job
  • une fois l'exécution finie proprement, il faut
    • vérifier que la simulation rejouée n'a pas dévié par rapport à la simulation originale: on comparera les solver.stat de l'océan des deux simulations pour l'année en question (ou les fichiers restart pour le modèle forcé)
    • renommer les fichiers nouvellement créés et qu'on veut garder pour le bouchage de trou. On se déplace donc dans le répertoire où le workflow CMIP stocke ses fichiers (a priori $GENCMIP6_CCCWORKDIR/IGCM_OUT/.../PROD/..../CM61-LR-2xCO2-01-REDO/CMIP6/ATM), et on constate l'existence d'un fichier
      clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_195801-199912.nc 
      Si on lance cdo tinfo sur ce fichier, on vérifiera que le fichier couvre les dates
      Start date          :  1958-01-16 12:00:00  
      End date            :  1958-12-16 12:00:00  
      et on le renomme donc en
      clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_195801-195812.nc
  • une fois le renommage des différents fichiers concernés (un fichier par variable à boucher), on peut relancer une nouvelle année en repartant de l'étape "faire le ménage dans le répertoire" (Marie-Alice et Laurent ont chacun développé des scripts qui permettent d'automatiser cete procédure si un grand nombre d'années sont à refaire, leur demander si besoin)

 

  1. Rebouchage effectif des trous des séries temporelles originelles

    Une fois toutes les années manquantes rejouées et les fichiers renommées, il faut maintenant déplacer ces nouveaux fichiers dans l'arborescence CMIP6 de la simulation originale, en renommant d'abord les fichiers déjà existants. Pour la variable clhcalipso, la commande cdo tinfo utilisée au 1) nous indique par exemple que le fichier
    clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_193801-199912.nc
    se trouvant ici
    $GENCMIP6_CCCWORKDIR/IGCM_OUT/.../PROD/..../CM61-LR-2xCO2-01/CMIP6/ATM  
    ne couvre que les dates 1938-01-16 à 1957-12-16. On le renommera donc en
    clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_193801-195712.nc. 
    Une fois le renommage de tous les fichiers concernés effectués, on peut recopier les fichiers 'annuels' créés au 2) dans le répertoire original, par exemple
    cd $GENCMIP6_CCCWORKDIR/IGCM_OUT/.../PROD/..../CM61-LR-2xCO2-01-REDO/CMIP6/ATM/ 
    cp clhcalipso_CFmon_IPSL-CM6A-LR_abrupt-2xCO2_r1i1p1f1_gr_195801-195812.nc ../../../CM61-LR-2xCO2-01/CMIP6/ATM/
Mots-clés associés : FAQ, exécution, aide