mardi 12 novembre 2013

Mise en oeuvre des modèles météo WRF-ARW et WRF-NMM - Partie 8 - Le post-processeur UPP

Dans l'article intitulé Partie 7 - Mise en oeuvre de WRF NMM, nous avons compilé le modèle WRF NMM et effectué un run sur la France. Mais le coeur NMM utilise une grille de type E, ce qui le rend très difficile à exploiter avec NCL pour produire des cartes, celui-ci étant prévu pour fonctionner avec une grille rectangulaire de type latitude/longitude. Nous allons devoir convertir les données produites dans un format plus classique, et pour cela nous allons utiliser un nouvel outl UPP.

Présentation de UPP


L'outil UPP (Unified Post Processor) a été conçu initialement pour retraiter les fichiers de sortie de WRF. Il a été depuis enrichi et permet de retraiter les données issues de nombreux autres modèles du NWS, comme GFS ou CFS. L'objectif est d'interpoler les données qui sont exprimées dans la grille native d'un modèle vers les niveaux et grilles standard utilisées au niveau international, et donc de produire des fichiers au format GRIB.

Le téléchargement du code source de UPP se fait depuis la page suivante :

http://www.dtcenter.org/wrf-nmm/users/downloads/index.php


Compilation


Décompressez votre archive dans votre dossier ~/Meteo, au même niveau que votre dossier  WRFV3. C'est important car par défaut il recherche votre librairie WRF dans ../WRFV3. Allez ensuite dans le dossier UPP et tapez :

# ./configure
Will use NETCDF in dir: /home/nicolas/Meteo
Will use WRF in dir: /home/nicolas/Meteo/UPPV2.1/../WRFV3
configure: making ./bin
bindir /home/nicolas/Meteo/UPPV2.1/bin
configure: making ./include
incmod /home/nicolas/Meteo/UPPV2.1/include
configure: making ./lib
libdir /home/nicolas/Meteo/UPPV2.1/lib
JASPER Environent found :: GRIB2 library ::
grib2lib = -L/home/nicolas/Meteo/lib -lpng -lz -ljasper
grib2inc = -I/home/nicolas/Meteo/include
-------------------------------------------------------------------------
Please select from among the following supported platforms.


1. Linux x86_64, PGI compiler (serial)
2. Linux x86_64, PGI compiler (dmpar)
3. Linux x86_64, Intel compiler (serial)
4. Linux x86_64, Intel compiler (dmpar)
5. Linux x86_64, Intel compiler, SGI MPT (serial)
6. Linux x86_64, Intel compiler, SGI MPT (dmpar)
7. Linux x86_64, gfortran compiler (serial)
8. Linux x86_64, gfortran compiler (dmpar)


Enter selection [1-8] :

Choisissez l'option 7, nous n'utiliserons pas la parallélisation.

# ./compile &> compile.log

Si cette commande réussit, alors les exécutables suivants sont produits dans le dossier bin :
  • copygb.exe
  • ndate.exe
  • unipost.exe
Vous ne devriez pas avoir de problème particulier à la compilation si vous avez réussi à compiler WRF, car vous aurez toutes les dépendances requises.

Préparation de l'environnement d'exécution


Nous allons maintenant préparer l'environnement d'exécution d'UPP. Je vous conseille de vous créer un répertoire de production à l'identique du test/nmm_real que nous avons utilisé jusqu'ici, en copiant les fichiers nécessaires. C'est ce que j'ai fait pour ma part dans le dossier /home/nicolas/Meteo/WRF/nmm_real. J'utiliserais donc ce chemin dans ce qui suivra.

Positionnez-vous dans le dossier nmm_real de production. On va créer une structure et copier les fichiers de config et les scripts de run fournis :

# cp -r ../../UPPV2.1/parm .
# cp ../../UPPV2.1/scripts/run_unipost* .
# mkdir postprd


Nous allons maintenant configurer le script  run_unipost. Assurez-vous au préalable que le shell KSH est bien installé sur votre système, car les scipts sont écrits dans ce langage. Editez-le avec votre éditeur préféré. Ce script étant assez long, je vais insister sur les parties à modifier. Ces parties sont généralement marquées par un "EDIT HERE" dans le fichier d'origine.

Premièrement quelques variables indiquant les chemins et le type de coeur utilisé. Le DOMAIN_PATH doit pointer sur votre dossier de production.

export TOP_DIR=/home/nicolas/Meteo
export WRF_DIR=${TOP_DIR}/WRFV3
export DOMAINPATH=${TOP_DIR}/WRF/nmm_real
export WRFPATH=${WRF_DIR}


export UNIPOST_HOME=${TOP_DIR}/UPPV2.1
export POSTEXEC=${UNIPOST_HOME}/bin



#Specify Dyn Core (ARW or NMM in upper case)
dyncore="NMM"


Ensuite il nous faudra indiquer la date de début de notre run, sa durée, ainsi que le pas de temps dans le fichier qui est de une heure :

export startdate=2013072800


export fhr=00
export lastfhr=23
export incrementhr=01


Nous allons préciser les options de nommage qui nous arrangent, à savoir l'extension de fichier souhaitée (.gr) ainsi que le préfixe du fichier (WRF) :

export COMSP=WRF
export tmmark=gr


La suite du script consiste à définir une boucle pour parcourir les différents domaines générés. Dans notre cas, un seul domaine est produit, on peut donc laisser la ligne suivante :


for domain in d01


Le script requiert ensuite que l'on définisse le format et le nom du fichier WRF d'entrée. J'ai dû modifier un peu la ligne définissant le fichier wrfout et enlever ${HH}. Je pense que le script est conçu de base pour utiliser un fichier par heure, ce qui n'est pas notre cas, tout est dans un seul fichier :

cat > itag <<EOF
../wrfout_${domain}_${YY}-${MM}-${DD}_00:00:00
netcdf
${YY}-${MM}-${DD}_${HH}:00:00
${tag}
EOF

Choisissez la méthode d'appel d'unipost. Cette commande est chargée  d'extraire et d'interpoler les données du fichier wrfout sur des niveaux verticaux standard, et de calculer certaines variables diagnostic comme la pression au niveau de la mer. A la compilation, nous avons choisi le mode Serial, décommentez la ligne correspondante et commentez les autres :

# Serial run command
${POSTEXEC}/unipost.exe > unipost_${domain}.${fhr}.out 2>&1

Notez que j'ai été obligé de modifier la ligne suivante (ajouter WRF juste après le mv), car les noms de fichiers n'étaient pas trouvés sinon :

# This prefix was given in the wrf_cntl.parm file
mv WRFWRFPRS${fhr}.${tmmark} WRFPRS_${domain}.${fhr}

Il nous faut maintenant configurer la commande copygb, dont le rôle est de produire les fichiers finaux sur la grille horizontale que nous souhaitons. Plusieurs méthodes d'appel existent dans le fichier, nous prendrons celle où l'on spécifie la grille sur la ligne de commande. Décommentez la ligne en conséquence, et modifiez-la comme ci-dessous, nous utilisons la même grille que pour le run WRF :

${POSTEXEC}/copygb.exe -xg"255 3 128 128 40400 8737 8 2337 10000 10000 0 64 45899 47696" WRFPRS_${domain}.${fhr} wrfprs_${domain}.${fhr}

Explication des chiffres barbares :
  • 255 3 : code qui indique qu'on utilise une grille Lambert Conforme définie par l'utilisateur.
  • 128 128 : nombre de points de grille en latitude / longitude
  • 40400 8737 : latitude et longitude du coin sud-ouest de notre domaine, multiplié par 1000
  • 8 : le chiffre 8... parce qu'il faut le chiffre 8.
  • 2337 : longitude du centre du domaine multiplié par 1000
  • 10000 10000 : c'est notre taille de grille X et Y en mètres
  • 0 64 : 0 et 64...
  • 45899 47696 : correspond aux variables truelat1 et truelat2 de la projection lambert, multiplié par 1000 (voir le fichier namelist.wps)

Exécution du post-processeur


Vous en avez maintenant terminé avec la configuration du script. Il est maintenant prêt à être lancé :

# ./run_unipost

La commande va itérer sur les différentes heures de sortie du modèle, et produire des fichiers dans le dossier postprd.

En cas d'erreur, vous pouvez regarder dans les fichiers postprd/unipost_d01.*.out, le dernier contiendra certainement un message d'erreur vous permettant de trouver la cause de l'échec. Les erreurs sont souvent dûes à un mauvais paramétrage du fichier ou alors des problèmes de chemins : exécutez-vous le script depuis le bon endroit ?

A l'arrivée, vous disposerez de fichiers directement exploitables correspondant à chaque heure de sortie du run. Ils sont au format GRIB1, vous devrez les renommer avec l'extension .gr si vous comptez utiliser NCL pour produire vos cartes. Le nom de base est postprd/wrfprs_d01.*, attention à la casse des caractères pour ne pas les confondre avec les fichiers intermédiaires.

Les fichiers produits sont directement exploitables en NCL, vous pouvez utiliser la commande ncl_filedump pour en lister le contenu, comme indiqué dans l'article Partie 6 - Visualisation des données. Vous pouvez également commencer à tracer vos cartes, mais vous devrez apprendre à vous servir des fonctions standard de NCL et non plus des fonctions WRF qui sont prévues pour WRF ARW uniquement.

Ma variable préférée n'est pas dans mon fichier !


La configuration par défaut d'Unipost produit toutes les variables possibles, tant que la source contient les données requises. En cela, vous n'aurez normalement pas besoin de toucher le fichier de configuration par défaut. Mais parfois, vous cherchez une banale variable et ne la trouvez pas dans votre fichier de sortie. C'est le cas par exemple de la température à 2 mètres, tout simplement parce qu'elle n'est pas dans le fichier produit par WRF !

Nous allons devoir demander à WRF de produire le champ de température à 2 mètres. Pour cela, il va falloir reconfigurer le code source en éditant le fichier WRFV3/Registry/Registry.NMM. Recherchez la ligne :

state    real   T2               ij     misc        1         -     ir        "T2"                  "TEMP at 2 M" ""

Ajoutez la lettre "h" à la section "ir" :

state    real   T2               ij     misc        1         -     irh        "T2"                  "TEMP at 2 M" ""

Ce fichier de configuration sert à générer des portions de programmes entières qui gèrent les différentes variables tout au long du run. En l'occurence, la section modifiée sert à indiquer comment gérer les entrées/sorties pour la variable d'état T2. La lettre h indique que cette variable fait partie de l'history, ce qui veut dire qu'elle doit être écrite dans le fichier de sortie. Le code correspondant doit maintenant être régénéré en procédant aux étapes suivantes :
  • recompiler WRF, pour tenir compte de cette modification. Voir l'article Partie 7 - Mise en oeuvre de WRF NMM.
  • recompiler UPP, car celui-ci référence la librairie d'I/O de WRF, qui est affectée par ces modifications également. Il n'est pas impossible également que UPP se serve du registry pour ses propres besoins.
Une fois ceci fait, relancez le script du postprocesseur UPP : le champ de température à 2 mètres doit maintenant être inclu dans votre fichier GRIB.

Conclusion


Nous voici arrivés au terme de la partie technique de ce tutorial. Quel chemin pour arriver jusqu'ici ! Car finalement nous n'avons fait finalement que peu de choses : installer le logiciel et le faire fonctionner sur un cas réel. Il resterais encore de nombreuses choses à dire, sur la production de cartes avec le langage NCL que nous n'avons fait que survoler ou encore sur les paramétrisations physiques du modèle. L'optimisation des performances et l'augmentation de la puissance de calcul par la mise en cluster  seraient également des sujets très intéressants à discuter. Dans l'ultime et dernier article, un peu moins technique, je discuterais un peu de tout cela afin de vous donner les pistes pour continuer vos expérimentations.