Aller au contenu. | Aller à la navigation

Outils personnels
Se connecter
Sections
Vous êtes ici : Accueil Utilisateurs FAQ Exécution

Exécution

Questions sur l'exécution de LMDZ
Show or Hide answer 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
Show or Hide answer 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
Show or Hide answer 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.

Show or Hide answer 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.

Show or Hide answer 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.

 

Show or Hide answer 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  -\-> -->

 

Mots-clés associés : , ,