Aller au contenu. | Aller à la navigation

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

FAQ

La Foire aux Questions pour LMDZ

Généralités

J'ai un problème ...
J'ai un problème de compilation, d'éxecution, ...., j'ai trouvé un bug, j'aimerais bien que vous rajoutiez ... dans LMDZ

Pour savoir que faire quand vous avez un problème, une question, une amélioration à suggérer, voir

SOS-LMDZ

L'altitude des niveaux dans LMDz
Si je veux récupérer l'altitude de la surface, comment dois-je faire ? J'aimerais connaître l'altitude des différents niveaux ...?

 Tu as l'altitude des milieux des couches dans les fichiers de sortie:

(geop-phis)/9.8

Tu as aussi l'épaisseur des couches en masse : la variable mass qui vaut rho dz.  Donc

dz = mass/rho = mass * P / RT

Si tu as, par exemple, 39 niveaux, sous ferret:

fill/k=39 (geop-phis)/9.8 ; go land
donne l'altitude au milieu de la première couche (par rapport à la surface)

fill/k=39 mass*289*temp/pres ; go land
donne l'épaisseur de la première couche

Tout ca en m

Résultat des courses pour les configs standard :
z1 vers 35 m
dz1
vers 70m

Couche 6 (k=34) vers 850 m pour une épaisseur de 300 m

Installation

Où se trouve la doc d'installation de LMDZ ?

Vous trouverez plusieurs méthodes décrites pour installer LMDZ dans la rubrique Guides de ce site.

Vous pouvez choisir l'une ou l'autre selon la configuration choisie pour exécuter LMDZ.

Problèmes connus à l'installation

Cf. Problèmes connus à l'installation

Comment installer IOIPSL et l'outil rebuild?
La librairie IOIPSL n'est pas installée sur la machine que j'utilise et/ou je n'ai pas accès à l'outil 'rebuild' pour recombiner les fichiers de sorties obtenus lorsque je fais tourner le modèle en mode MPI. Quelle est la marche à suivre pour installer la librairie IOIPSL et ses outils connexes?
  1. Si vous utilisez une version à jour du script install.sh pour installer le modèle, alors vous disposez déjà d'une version à jour de la librairie IOIPSL (dans le répertoire modipsl/lib) et de l'utilitaire 'rebuild' (dans le répertoire modipsl/bin). SI ce n'est pas le cas, c'est que vous avez utilisé une vieille version du scirpt install.sh et il est préférable de récupérer la dernière version et réinstaller le modèle.
  2. Si vous n'utilisez pas le script install.sh pour installer le modèle, il vous faudra installer à la main la librairie IOIPSL en s'inspirant de la démarche suivante:
## Prérequis: la librairie NetCDF doit être installée
# 1. Télécharger modipsl, l'outil d'installation
svn co http://forge.ipsl.jussieu.fr/igcmg/svn/modipsl/trunk modipsl
# 2. Descendre dans le répertoire util
cd modipsl/util
# 3. Extraire IOIPSL (ici la version complète, entre autre pour aussi récupérer
# l'outil 'rebuild')
./model IOIPSL_PLUS
# 4. Adapter le fichier AA_make.gdef. C'est le point délicat: ce fichier contient
# les définitions (où trouver la librairie netcdf, quel compilateur utiliser, etc.)
# associées à un nom de "configuration cible".
# On peut soit créer sa propre "configuration cible" en suivant les modèles déjà
# présents, Soit en adapter une (dans ce qui suit, on présume qu'on va utiliser
# la "configuration cible" "gfortran"
# 5. Lancer l'installation des fichiers IOIPSL
./ins_make -t "gfortran" -p I4R8
# 6. Compiler la librairie IOIPSL
cd ../modeles/IOIPSL/src
make
# Si tout s'est bien passé, la librairie libioipsl.a et les modules associés
# sont dans le répertoire modipsl/lib
# 7. Compiler l'outil rebuild (pour pouvoir recombiner les sorties en mode MPI)
cd ../tools
make
# Si tout s'est bien passé, l'utilitaire 'rebuild' (et l'auxiliaire 'flio_rbld')
# se trouve dans le répertoire modipsl/bin

dernières modifications: 19 avril 2012

Sources

Rajouter des sorties
Je veux rajouter des sorties dans la physique. Comment faire suite à la réorganisation des routines histdef/histwrite/phys_output_*?

Les sorties n'ont pas fondamentalement changées, on a juste ajouté une surcouche pour pouvoir choisir les sorties à faire plus facilement. Cela se fait toujours en 2 étapes, une de définition (qui se fait maintenant dans phys_output_mod.F90) et une d'écriture (dans phys_output_write.h). L'ajout principal, c'est la définition d'une nouvelle structure associée à chaque variable à sortir. Cette structure est de type "5 entiers, 1 variable caractère" (voir la définition de ctrl_out au début de phys_output_mod.F90) qui correspondent aux différents niveaux de sorties que l'on souhaite pour la variable à sortir et au nom que l'on veut lui donner dans les fichier de sortie. Par exemple, pour la variable snow, on a défini un drapeau

o_snow = ctrl_out((/ 1, 1, 10, 1, 10 /),'snow')

qui veut dire que la variable s'appellera 'snow' dans les fichiers hist??? et qu'elle sera sortie à partir du niveau (celui qui est défini par lev_hist??? dans physiq.def)

1 dans le fichier histmth
1                        histday
10                      histhf
1                        histins
10                      histLES

Ceci permet, en fait, de contrôler le niveau de sortie des variables directement dans un fichier output.def. Par exemple, la variable topswai est normalement sortie à partir du niveau 4 dans histmth et 10 dans les autres. Si on sortir cette variable dans tous les fichiers histoire sans recompiler les sources, on rajoute la ligne

flag_topswai         =  1, 1, 1, 1, 1

dans le fichier output.def.

Donc pour rajouter des variables de sortie, on définit une politique de sortie de la variable et son petit nom dans une nouvelle structure (que je te suggère de nommer o_qque_chose et qu'on rajoute au début de phys_output_mod.F90 dans la partie déclaration) et ensuite on rajoute les lignes

CALL histdef2d(...)

qu'il faut dans phys_output_mod.F90

et les blocs

IF (o_???flag(iff)<=lev_files(iff)) THEN
CALL histwrite_phy(...)
ENDIF

qu'il faut dans phys_output_write.h

(en se basant sur la variable snow, par exemple)

Enfin, ne pas oublier de modifier les fichiers *xml pour les sorties XIOS (voir la Faq suivante)

J'ai rajouté une variable dans les sorties. Comment la rajouter dans les xml pour les sorties XIOS?

Vous venez de rajouter une variable de sortie en modifiant les fichiers:

  • libf/phylmd/phys_output_ctrlout_mod.F90
  • libf/phylmd/phys_output_write_mod.F90

 

N'oubliez surtout pas de modifier les fichiers *xml contrôlant les sorties sous XIOS car si vous ne le faites pas, dès que les sorties XIOS seront activées, le modèle plantera (vous demanderez en fait à XIOS de sortir une variable qu'il ne connaît pas).

Il faut définir votre variable dans le fichier DefLists/field_def_lmdz.xml puis l'inclure dans les fichiers DefLists/file_def_hist*xml si vous voulez effectivement la sortir dans les fichiers histoire.

Par exemple, vous avez défini la variable ocond dans phylmd/phys_output_ctrlout_mod.F90:

 TYPE(ctrl_out), SAVE :: o_ocond = ctrl_out((/ 2, 3, 4, 10, 10, 10, 11, 11, 11 /), & 'ocond', 'Condensed water', 'kg/kg', (/ ('', i=1, 9) /))

Il vous faut alors rajouter la ligne

<field id="ocond"    long_name="Condensed water"    unit="kg/kg" />

dans DefLists/field_def_lmdz.xml. Attention, les variables sont regroupés par ensemble de variables 2D et 3D

Puis, pour que la variable soit effectivement écrite dans le fichier histmth.nc, par exemple, vous rajoutez la ligne

<field field_ref="ocond" level="2" />

dans le fichier DefLists/file_def_histmth_lmdz.xml level correspond au niveau de sortie de la variable pour le fichier histmth. A priori, vous mettez les mêmes niveaux que ceux que vous avez défini dans phys_output_ctrlout_mod.F90

Exécution

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

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.

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.

 

Icon new 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  -\-> -->

 

Erreurs fréquentes

Error in get_aero_fromfile, netcdf error code = 2
Le modèle lmdz plante avec un message d'erreur concernant les aérosols alors que je n'ai pas touché aux fichiers de configuration ...

 Après une mise à jour des sources du modèle, celui-ci se plante avec le message d'erreur suivant alors que vous n'avez rien changé à la configuration du modèle et de son traitement des aérosols:

     reading variable SO4 in file aerosols1980.nc
     Error in get_aero_fromfile, netcdf error code =  2
     Error in get_aero_fromfile : pb open SO4
     in abort_gcm
     out of histclo
     Stopping in get_aero_fromfile.nc
     Reason = No such file or directory

En fait, à partir de la version r1668 des sources, le paramètre flag_aerosol change légèrement de comportement. Alors que, jusqu'à cette version du code, il était nécessaire que les paramètres ok_ade et ok_aie soient activés pour que flag_aerosol le soit aussi, son activation est maintenant indépendante de ces deux paramètres et il suffit qu'il ait une valeur différente de 0 pour qu'un fichier d'aérosols soit lu. 

Pour résoudre ce plantage, et si vous ne souhaitez pas tourner avec les aérosols, il faut vérifier dans vos fichiers de configuration (config.def, physiq.def, etc ...) que flag_aerosol n'est pas initialisé à une valeur différente de 0

Mots-clés associés : ,