Application du modèle de prévision météorologique WRF au Vietnam

Application du modèle de prévision météorologique WRF au Vietnam

Remerciements

Je tiens d’abord à remercier Monsieur le Professeur. Dr. NGUYEN Thanh Thuy qui
m’a dirigé pour mon mémoire de fin d’études universitaires. Sans son initiative, ce
projet n'aurait pas été achevé. Je tiens à lui exprimer toute ma reconnaissance pour
son dévouement, la confiance qu'il m'a accordée, sa rigueur et la qualité des
commentaires et suggestions sur mes travaux.
Je tiens également à remercier Dr. NGUYEN Huu Duc, Dr. TA Tuan Anh pour
m’avoir aidé et aussi m’avoir donné des conseils importants.
Je remercie infiniment Monsieur le Professeur. Dr. PHAM Ky Anh, Directeur du
Centre de la Calcul à Haute Performance, Université nationale de Hanoi pour sa
permission de rechercher et déployer le système sur deux superordinateurs les plus
puissants au Vietnam.
Je remercie également Monsieur PHAN Van Tan, enseignant-chercheur du Centre
de Météo, Université nationale de Hanoi pour ses conseils précieux, son soutien
ainsi que pour sa gentillesse tout au long de mon stage de fin d’études. Ce travail
n’aurait pu être accompli sans son aide.
Je remercie beaucoup Monsieur DOAN Trung Tung, Monsieur LE Duc Tung et
Monsieur Tran Tuan Tu au Centre de Calcul à Haute Performance pour leurs aides
techniques.
Ma gratitude s’adresse aussi aux professeurs à l’Institut Polytechnique de Hanoi
(IPH) pour m’avoir transmis de bonnes connaissances concernant le savoir et le
savoir-faire qui sont utiles pour mon mémoire.
Je voudrais remercier particulièrement mes professeurs de français pour leurs bons
conseils dans la rédaction du mémoire.
Finalement, j’exprime mon entière reconnaissance à ma famille et mes amis pour
leurs soutiens, leurs aides, leurs encouragements et leurs conseils sincères.

Hanoi, le 18 mai 2008

TRAN Viet Trung

TRAN Viet Trung ‐ Filière francophone de l’Informatique 1


Table des matières

Remerciements .......................................................................................................... 1
Liste des figures ......................................................................................................... 4
Liste des tableaux ...................................................................................................... 5
Liste des abréviations ................................................................................................ 6
Prologue 7
CHAPITRE I Modèle Weather Research and Forecasting (WRF) ................... 9
1. Introduction ....................................................................................................... 9
2. Architecture du modèle WRF ......................................................................... 10
2.1. Initialisation.............................................................................................. 10
2.2. WRF-VAR pour cœur ARW .................................................................... 11
2.3. Cœurs dynamiques (ARW & NMM) ....................................................... 11
2.4. Les paquets de physique........................................................................... 12
2.5. Outil de post-traitement du WRF ............................................................. 12
3. Sous modèle WRF ARW ................................................................................ 15
3.1. Le Système de prétraitement (WPS) ........................................................ 16
3.2. Initialisation du modèle ARW ................................................................. 21
3.3. Cœur WRF ARW ..................................................................................... 25
4. Conclusion ...................................................................................................... 27
CHAPITRE II Calcul à haute performance avec WRF ................................... 28
1. Matériel ........................................................................................................... 28
1.1. Bkluster .................................................................................................... 28
1.2. IBM eServer Cluster 1350 ....................................................................... 28
1.3. IBM eserver Cluster 1600 ........................................................................ 29
2. Environnement du logiciel .............................................................................. 30
2.1. Compilateurs et langage de programmation demandés ........................... 30
2.2. Les bibliothèques optionnelles ................................................................. 30
3. Domaines de calcul ......................................................................................... 31
3.1. Domaine de calcul au Bkluster. ............................................................... 31
3.2. Domaine de calcul au IBM eserver 1350. ................................................ 31
3.3. Domaine de calcul au IBM eserver 1600. ................................................ 33
4. Données du modèle ARW .............................................................................. 34
4.1. Données météorologiques ........................................................................ 34



4.2. Données géographiques ........................................................................... 34
5. Déploiement des modules du ARW ................................................................ 34
5.1. Module WPS ............................................................................................ 34
5.2. Module ARW ........................................................................................... 38
6. Conclusion ...................................................................................................... 40
CHAPITRE III Évaluation des expériences ...................................................... 41
1. Introduction ..................................................................................................... 41
2. Les expériences réalisées sur Bkluster ............................................................ 41
2.1. Mode séquentiel ....................................................................................... 41
2.2. Mode parallèle .......................................................................................... 42
3. Comparaison de la performance entre trois systèmes ..................................... 44
4. Conclusion ...................................................................................................... 46
CHAPITRE IV Application du modèle WRF au Centre HPC ........................ 47
1. Introduction ..................................................................................................... 47
2. Structure du Système ...................................................................................... 48
2.1. Module de contrôle automatique du modèle WRF .................................. 49
2.2. Extraction de champs météorologiques par le script NCL ...................... 51
2.3. Mise en carte de la structure de la base de données. ................................ 53
2.4. MeteoAPI ................................................................................................. 54
2.5. Gadget IPHmétéo pour Google Desktop ................................................. 58
3. Conclusion ...................................................................................................... 64
Conclusion 65
Référence 66
Annexe 67



Liste des figures
Figure I-1 Les composants du modèle WRF ............................................................. 10
Figure I-2 Graphique NCAR et RIP4 ....................................................................... 13
Figure I-3 Image de GrADS ...................................................................................... 14
Figure I-5 Le Composants du Système du modèle ARW ......................................... 16
Figure I-6 Système de prétraitement ......................................................................... 17
Figure I-7 Initialisation du modèle ARW ................................................................. 22
Figure I-8 Initialisation pour les cas de données idéaux ........................................... 23
Figure I-9 Initialisation pour les cas de données réels .............................................. 24
Figure I-10 Coordonnée de pression hydrostatique suivant le terrain ...................... 25
Figure I-11 Emboîtement du modèle ARW .............................................................. 26
Figure II-1 Comparaison de la performance de calcul entre trois systèmes. ............ 29
Figure II-2 Domaine Vietnam1 ................................................................................. 31
Figure II-3 Domaine DNA_nested ............................................................................ 32
Figure II-4 Domaine DNA-nested2 .......................................................................... 33
Figure II-5 Exécuter les programme du WPS ........................................................... 35
Figure II-6 Définir un domaine du modèle WRF ..................................................... 36
Figure III-1 Mode séquentiel .................................................................................... 42
Figure III-2 Temps d'exécution influencé par MPICH et la communication ........... 42
Figure III-3 L’influence de la quantité de processeurs ............................................. 43
Figure III-4 Temps moyen au cas optimal de trois systèmes................................... 45
Figure III-5 Comparaison entre Bkluster et IBM 1350............................................. 46
Figure IV-1 Produire des images météorologiques................................................... 47
Figure IV-2 Structure du système déployé au Centre HPC ...................................... 48
Figure IV-3 Automatisation du modèle WRF........................................................... 49
Figure IV-4 Les étapes principales du module d’extraire les champs
météorologiques ........................................................................................................ 52
Figure IV-5 Le structure de la base de données ........................................................ 53
Figure IV-6 le processus de traitement d’une demande par MeteoAPI .................... 56
Figure IV-7 IPHMétéo .............................................................................................. 60
Figure IV-8 Les trois états d’affichage de l’IPHmétéo ............................................. 61
Figure IV-9 IPHmétéo en version Français, Anglais et Vietnamien ........................ 62
Figure IV-10 IPHmétéo sur la galerie de Google ..................................................... 63
Figure IV-11 Prévision météorologique à 14 : 55’ le 16 mai 2008 .......................... 63



Liste des tableaux

Tableau I-1 Parallélisme dans le WPS ................................................................... 21
Tableau III-1 Temps moyen influencé par le nombre de processeurs sur Bkluster.. 44
Tableau III-2 Temps moyen influencé par le nombre de processeurs sur IBM 135044
Tableau III-3 Temps moyen influencé par 8 processeurs sur IBM 1600 ................. 44
Tableau IV-1 Structure de l’IPHmétéo ..................................................................... 61



Liste des abréviations

NWP : Numerical Weather Prediction
WRF : Weather Research and Forecasting
MM5 : The Fifth-Generation NCAR / Penn State Mesoscale Model
GRIB : GRIdded Binary
HPCC : High Performance Computing Centre
CM : Centre de Météo
NCAR : National Center for Atmospheric Research
NCEP : National Centers for Environmental Prediction
PNT : Prévision Numérique du Temps
MMM : Numerical Model Metadata
NAM : North Amercian Meso
GFS : Global Forecast System
AVN : Aviation Model
XML : Langage de balisage extensible
WSF : WRF Software Framework
ARW : Advanced Research WRF
GrADS : Grid Analysis and Display System



Introduction

Le problème de prévision numérique du temps (PNT) a attiré vivement l’intention
des chercheurs du Centre du Calcul à Haute Performance (HPCC), Institut
polytechnique de Hanoi. Depuis 2006, HPCC a mené une coopération avec le
Centre de météo (CM), de l’Université nationale des sciences de Hanoi afin de
pouvoir étudier et déployer les modèles de prévision météorologique sur les
ordinateurs à haute performance. Grâce à cette coopération, nous avons obtenu
plusieurs résultats importants, en particulier pour la recherche et le déploiement du
modèle MM5.
Cependant, pour l’opération de prévison, il n’est jamais suffisamment exact
d’utiliser seulement un modèle numérique quand il est appliqué dans les conditions
particulières du Vietnam. À partir de cette demande, la recherche d’autres modèles
de prévision météorologique est devenu un problème indispensable. Ce sont toutes
les raisons pour lesquelles le modèle de prévision numérique WRF a été choisi.
Parmi les autres, notamment le modèle MM5, il est une évolution et un successeur
du modèle MM5 qui n’est plus supporté par les développeurs. En effet, WRF s’est
développé rapidement les années dernières, il est presque neuf au Vietnam. Si mon
mémoire de fin d’études réussit bien, ce sera la première fois que le modèle WRF
est utilisé au HHPC et aussi au CM.
La perspective de ce mémoire se concentre non seulement sur le déploiement du
modèle WRF mais encore une importante partie se concentre sur recherche de la
façon pour exploiter les résultats de prévison chez les utilisateurs ordinaires.
Mon mémoire se compose donc des chapitres suivants :
Chapitre I : « Modèle Weather Research and Forecasting (WRF) »
On présentera dans ce chapitre des connaissances du modèle de prévision
météorologique WRF. On présentera en détail ensuite le sous-modèle WRF ARW
(Advanced Research WRF), ses composants et la relation entre eux.
Chapitre II : « Calcul à haute performance avec WRF »
On abordera en détail toutes les étapes et la façon de déployer le modèle sur les
superordinateurs à haute performance.
Chapitre III : « Évaluation des expériences »
On réalise et analyse des résultats obtenus en faisant des expériences. Les
évaluations concernent la recherche de la façon d’exécution optimale du modèle sur
tous les trois systèmes. On se concentre également sur la comparaison de la
performance entre eux.



Chapitre IV : « Application du modèle WRF au Centre HPC »
Ce chapitre illustrera un système professionnel déployé au centre HPC afin de
pouvoir exploiter les données de sortie du modèle WRF. Le système permet
d’approvisionner les bulletins de météo chez les utilisateurs ordinaires au Vietnam.



CHAPITRE I Modèle Weather Research and Forecasting (WRF)

1. Introduction
La prévision météorologique [1] est une application des connaissances en
météorologie et des techniques modernes de prises de données et d’informatique
pour prédire l’état de l’atmosphère à un temps ultérieur. L’histoire de la prévision
du temps remonte aux temps immémoriaux avec les oracles et devins, mais la
science moderne date vraiment de la fin du XIXe siècle et du début du XXe siècle.
Elle s’est cependant affirmée depuis la deuxième Guerre mondiale alors que les
moyens techniques comme le radar et les communications modernes ont rendu
l’accès aux données plus rapide et plus nombreuses.
Les lois régissant le comportement de l’atmosphère sont dérivées de la mécanique
des fluides. On peut les résoudre, grâce à des modèles mathématiques et des
superordinateurs. Ce sont les modèles numériques de prévision météorologique,
parmi lesquels le modèle WRF est un représentant typique de ces méthodes.
Théoriquement, le Modèle Weather Research and Forecasting (WRF) [2] est un
système numérique méso-échelle de nouvelle génération pour la recherche et les
prévisions météorologiques. C'est une évolution et un successeur du modèle MM5.
WRF est du domaine public et disponible gratuitement. Il présente des coeurs
dynamiques multiples, un système d'assimilation de données en 3 dimensions
variationnelles (3DVAR) et une architecture de logiciel tenant compte du calcul en
parallèle et de l'extensibilité du système.
WRF permet un large éventail d’applications à des échelles spatiales allantes de
quelques mètres à quelques centaines kilomètres, entre lesquelles :
• Prévision météo
• Simulation idéalisée (LES, convection, ondes baroclines)
• Paramétrisation atmosphérique
• Assimilation de données
• Processus de couplage
Les efforts pour développer le WRF ont principalement été une collaboration entre
National Center for Atmospheric Research (NCAR), National Oceanic and
Atmospheric Administration (le National Centers for Environmental Prediction
(NCEP) et Forecast Systems Laboratory (FSL), Air Force Weather Agency
(AFWA), Naval Research Laboratory, Oklahoma University, et Federal Aviation
Administration (FAA). WRF permet aux chercheurs la capacité d'accomplir des
simulations reflétant des données réelles ou des configurations idéalisées. WRF



fournit des prévisions opérationnelles d'un modèle qui est flexible et efficace, en
offrant les avances dans la physique, numeric et l'assimilation de données
contribuées par la communauté de recherche.

2. Architecture du modèle WRF
Les composants principaux du modèle WRF sont représentés dans la figure I-1 ci-
dessous. Ce sont :
• Le framework de logiciel WRF (WSF) fournit l'infrastructure qui loge les
cœurs multiples dynamiques.
• Les paquets de physique qui branchent le cœur par une interface standard de
physique.
• Les programmes de l'initialisation.
• Le système de l'assimilation de données d’observation du WRF (WRF-Var).
• Les cœurs multiples dynamiques.
Il y a deux cœurs dynamiques disponibles jusqu'à maintenant dans le WSF : Cœur
ARW (Advanced Research WRF) développé essentiellement à NCAR et cœur
NMM (Nonhydrostatic Mesoscale Model) développé à NCEP.

Framework de logiciel du WRF

Données observées, Système de post-
reanalyses, du traitement du WRF, outil
modèle global ... graphique

WRF-VAR

Figure I-1 Les composants du modèle WRF

La suite de ce chapitre se consacre à la description de ces différents modules.

2.1. Initialisation
WRF peut être exécuté avec les conditions initiales qui sont analytiquement définies
pour les simulations idéalisées, il peut être également exécuté en utilisant des
données interpolées d'une analyse du modèle global pour les cas de données réelles.



Les cas d'épreuves tant 2D que 3D pour les simulations idéalisées sont fournis. En
plus, plusieurs cas d’épreuves pour les simulations de données réelles sont
également fournis, qui comptent sur le système de prétraitement venu d'un paquet
externe qui convert les données GRIB dans un format convenable qui est ingéré par
le processus de traitement de données réelles du WRF.
Les programmes qui produisent les conditions initiales spécifiques pour la fonction
de cas de données idéals ou de cas de données réelles utilisent la même façon. Ils
fournissent les informations ci-après à cœur dynamique du WRF:
• Les données d'entrée qui est sur l'étalement horizontal et vertical correct
• La référence hydrostatiquement équilibrée
• Les métadonnées spécifiant de telles informations que la date, les
caractéristiques physiques et les détails de projection.

2.2. WRF-VAR pour cœur ARW
L'assimilation de données est la technique par laquelle les observations sont
combinées avec un produit de prédiction météorologique numérique pour améliorer
l’estimation de l'état atmosphérique. Les différences entre l'analyse et les
observations sont réduites selon leur erreur perçue. Traditionnellement, les
observations sont celles « directes » de température, d'humidité, et de vent des
rapports de surface et de radiosonde. Car les techniques de télédétection
rétrogradent peu à peu, les observations « indirectes » sont de plus en plus
disponibles pour des chercheurs et des modeleurs opérationnels. L'utilisation
efficace de ces observations indirectes pour l'analyse objective n'est pas commune,
les méthodes généralement utilisées comportent les techniques de variations
tridimensionnelles ou quadridimensionnelles (« 3DVAR » et « 4DVAR »,
respectivement), qui est probablement aussi bien employées pour des observations
directes.
WRF-VAR est utilisé seulement pour le modèle ARW.

2.3. Cœurs dynamiques (ARW & NMM)
Les cœurs dynamiques du modèle WRF sont les composants les plus importants. Le
rôle du cœur est de traiter les données d’entrée pour relever les résultats de
prévision météorologique. Évidemment, le temps d’exécution du modèle dépend
beaucoup de la performance du cœur. Advanced Research WRF (ARW) et Non-
Hydrostatic Mesoscale (NMM) sont deux cœurs dynamiques du modèle WRF. On
peut considérer que le modèle WRF se compose de différents sous-modèles avec
même architecture mais en différents codes de cœurs correspondant au modèle
ARW ou au modèle NMM.



Voici quelques caractéristiques essentielles du cœur ARW et du cœur NMM. Grâce
à ces informations, on peut trouver le meilleur cœur du modèle correspondant à des
tâches différentes.
• Les caractéristiques communes.
- Recherche de physique atmosphérique
- Cas d’étude de recherche
- Opération professionnelle de prédiction météorologique numérique du
temps réel et recherche de système de pronostics
- L'enseignement de la dynamique et de PNT
• Pour ARW seulement.
- Recherche du climat régional et de la période saisonnière
- Applications du Coupled-model* (par ex. l'océan, la chimie).
- Simulations idéalisées à beaucoup d’échelle (par ex. convection, les
signes de baroclinic, les grandes simulations de tourbillon)
- Recherche d'assimilation de données.

2.4. Les paquets de physique
Pour la simulation du climat réel et faire des simulations avec les résolutions
grossières, un ensemble minimal des composants de physique est exigé, par
exemple : la radiation, la couche limite, la surface de terrain, la convection, la
diffusion de tourbillon de sous-grille et la microphysique. Puisque le modèle est
développé pour la recherche et aussi pour les opérations, les plans de physique
sophistiqués et les plants de physique simples sont nécessaires dans le modèle. Les
objectifs du développement de physique WRF sont d'implémenter un ensemble
fondamental de la physique dans le modèle WRF et de concevoir une interface de
physique facile à utiliser.
Les options de physique du WRF tombent dans plusieurs catégories, chaque
catégorie entretient plusieurs options. Les catégories de physique sont :
la microphysique, le cumulus, la couche limite planétaire (PBL), le modèle de la
surface de terrain et la radiation.

2.5. Outil de post-traitement du WRF
Ce sont les logiciels qui permettent de visualiser les données sorties en graphique.
Les données de sortie sont dans le format de netCDF peuvent essentiellement être
visualisée en utilisant n'importe quel logiciel capable de traiter ce format de
données. Actuellement trois programmes utilités de post-traitement sont soutenus,
NCL, RIP4, ARWpost (le convertisseur à GrADS et à Vis5D). NCL et RIP4



peuvent seulement lire des données dans le format de netCDF, tandis qu'ARWpost
peut lire des données dans le format de GRIB1 et netCDF.
a. NCL, Graphique NCAR
Graphique NCAR [3] était un outil graphique très populaire qui est très bien
documenté et largement utilisé. Il fournit les ingrédients de base pour créer des
figures complexes grâce à des fonctions / routines qui peuvent être appelées par des
programmes en Fortran ou en C. Une interface de programmation pour l'outil de
graphiques NCAR a été développée : NCL (NCAR Command Language, langage de
commande NCAR). Les interfaces de programmation fournissent l'accès à des
utilitaires graphiques complexes comme la détection de contours, la projection sur
la carte de la terre et le tracé de vecteurs vitesse. L'interface C est majoritairement
construite au-dessus de l'interface Fortran. NCAR est distribué sous la licence
publique générale GNU.

Figure I-2 Graphique NCAR et RIP4

b. RIP4
RIP4 [4] est un programme Fortran qui invoque des routines Graphiques NCAR
pour but de visualiser des ensembles de données météorologiques, essentiellement
des données des modèles numériques meso-échelles. Il peut aussi être utilisé pour
visualiser les données d’entrée du modèle ou les analyses de sortie sur les grilles du
modèle. Il a été développé depuis 1991, essentiellement par Mark Stoelinga tant à
NCAR qu'à l'Université de Washington. RIP est un composant officiel du modèle



WRF, mais il pourrait potentiellement être utilisé avec la production de n'importe
quel modèle numérique meso-échelle.
Le programme est conçu pour être portatif à n'importe quel système UNIX qui a un
compilateur Fortran 77 ou Fortran 90 et la bibliothèque Graphique NCAR.
c. GrADS
Grid Analysis and Display System (GrADS) [5] est un outil d'analyse et de
visualisation interactif de données en sciences de la terre. Les données sont
généralement 4D (latitude, longitude, altitude et temps). Les opérations du GrADS
peuvent être exécutées directement sur les données en entrant les expressions
comme le langage FORTRAN à la ligne d'instruction et en mode interactif.
D’ailleurs, un ensemble riche des fonctions intégrées est fourni. En plus, les
utilisateurs peuvent ajouter leurs propres fonctions comme les routines externes
écrites dans n'importe quel langage de programmation. La syntaxe d'expression
permet des opérations complexes, par exemple : de grandes quantités de données
peuvent être exécutées avec les expressions simples.

Figure I-3 Image de GrADS



d. Vis5D
Pour avoir des images de visualisation en 3 dimensions de données de sortie du
modèle WRF, on peut utiliser le programme Vis5D, qui était le premier logiciel
libre de visualisation en 3 dimensions de données météorologiques.

Figure I-4 Logiciel Vis5D

Parmi lesquels, Graphiques NCAR était le programme le plus populaire pour
visualiser les données de sortie du modèle puisqu’il peut produire des images de
visualisation de qualité. Grâce à son interface de programmation, NCL, on peut
manipuler facilement les champs météorologiques de donnée en utilisant un grand
nombre de bibliothèques disponibles pour le modèle WRF.

3. Sous modèle WRF ARW
Comme je l’ai déjà mentionné dans le précédent secteur, on peut considérer que
WRF se compose de différents sous-modèles de même architecture mais en
différents codes de cœurs correspondant au modèle ARW ou au modèle NMM. Afin
de servir l’opération de prévision météorologique au Vietnam, après avoir consulté
les chercheurs expérimentés du Centre de Météo, nous avons le grand plaisir de
choisir le modèle ARW comme le but de recherche approfondie. Les connaissances
présentées ici constituent donc une base solide pour moi de bien déployer le
modèle.
Les composants de système du modèle ARW
La figure suivante montre l'ordinogramme pour le modèle ARW de la version 2 :



Ideal 2D Ideal 2D Ideal 3D
hill Squall line supercell

Ideal 2D Ideal 3D
grav baroclinic
Waves

Données
géographiques NCAR graphics
statiques NCL

WRF-Var

WPS OUTPUT RIP4

Données du
modèle global
(NAM,GPS,RUC, ARWpost
NNRP) (GRADS/Vis5D)

Figure I-5 Les Composants du Système du modèle ARW

3.1. Le Système de prétraitement (WPS)
Le système de prétraitement (WPS) est un ensemble de trois programmes dont le
rôle collectif est de préparer la donnée d’entrée au programme « real.exe » pour les
simulations de données réelles. Chaque programme exécute un stade de la
préparation : le « geogrid » définit des domaines et interpole des données
géographiques statiques aux grilles; « ungrib » extrait des champs météorologiques
des fichiers au format de GRIB; et le « metgrid » interpole horizontalement les
champs météorologiques extraits par « ungrib » aux grilles définies par « geogrid ».
Le travail qui est d’interpoler verticalement les champs météorologiques aux
niveaux eta de WRF (eta levels) est maintenant exécuté dans le programme
« real.exe ».



Figure I-6 Système de prétraitement

L'écoulement des données entre les programmes du WPS est montré dans la figure
ci-dessus. Chacun des programmes WPS lit des paramètres d'un fichier namelist
commun, comme montré dans la figure.
Ce namelist a des parties séparées pour chacun des programmes et d'une partie
partagée, qui définit des paramètres utilisés par plus qu'un programme WPS. Il y a
encore des fichiers de table supplémentaires qui sont utilisés par les programmes
individuels ne sont pas montrés dans la figure. Ces tables fournissent le contrôle
supplémentaire sur l'opération des programmes, bien que généralement ils n'aient
pas besoin d'être changés par l'utilisateur.
Fonction de chaque programme du WPS
Programme geogrid
Le but de « geogrid » est de définir les domaines de simulation et d’interpoler des
ensembles de données terrestres différentes aux grilles-modèles. Le domaine de
simulation est défini en utilisant des renseignements spécifiés par l'utilisateur dans
la partie « geogrid » du fichier namelist.wps. Par défaut, en calculant la latitude et la
longitude pour chaque point de grille, « geogrid » interpolera des catégories de sol,
la catégorie d'utilisation de terrain, l’altitude de terrain, la température moyen
annuel du sol profond, la fraction de végétation mensuel, l'albédo de neige
maximum aux grilles-modèles.
Ensembles de données globaux pour chaque champ sont fournis par le site Internet
MMM et doivent seulement être téléchargé une seule fois. Plusieurs des ensembles
de données sont disponibles pour une seule résolution, mais d'autres sont disponible
dans les résolutions de 30”, 2’, 5’ et 10’. L'utilisateur n'a pas besoin de télécharger
toutes les résolutions disponibles pour un ensemble de données, bien que les
champs interpolés soient généralement plus représentatifs si une résolution de
données du source était près de laquelle du domaine utilisé de simulation. Pourtant,



les utilisateurs qui s'attendent travailler avec les domaines ayant des écartements de
grille qui couvrent une grande gamme peuvent vouloir finalement télécharger toutes
les résolutions disponibles des données terrestres.
En plus du fait d'interpoler les champs terrestres implicites, le programme
« geogrid » est assez général pour être capable d'interpoler la plupart des champs
continus et catégoriques aux domaines de simulation. Les ensembles de données
nouvelles et supplémentaires peuvent être interpolés au domaine de simulation par
l'aide du fichier de table, GEOGRID.TBL. Le fichier GEOGRID.TBL définit
chacun des champs qui seront produits par « geogrid »; il décrit les méthodes
d'interpolation d’un champ, aussi bien que l'endroit d’hébergement où l'ensemble de
données de ce champ est trouvé.
La production de « geogrid » est écrite au format E/S de WRF API et ainsi, en
choisissant le format E/S NetCDF, « geogrid » peut écrire sa production au format
NetCDF pour la visualisation facile en utilisant des paquets de logiciel externes.
Programme ungrib
Le programme « ungrib » lit des fichiers GRIB, interprète les données et les écrit
dans un format simple, appelé le format intermédiaire. Les fichiers GRIB
contiennent des champs météorologiques variables aux temps et sont au format d'un
autre modèle global, comme le NAM de NCEP ou les modèles de GFS. Le
programme « ungrib » peut lire les fichiers GRIB en version 1 et 2. En effet, les
fichiers GRIB contiennent plus de champs météorologiques qui sont nécessaires
pour initialiser WRF. Tant les versions du format de GRIB utilisent des codes
différents pour identifier les variables dans le fichier, « Ungrib » utilise des tables
des codes - appelé Vtables, qui contient la liste des variables - pour définir quels
sont les champs pour extraire et pour écrire au format intermédiaire. Vtables sont
fournis avec le programme « ungrib ».
D’ailleurs, Vtables sont disponibles pour le format des grilles NAM 104 et 212, le
NAM AWIP, GFS, la Réanalyse NCEP/NCAR archivée à NCAR, RUC (les
données de niveau de pression et les données de coordonnée hybrides) et
l’AGRMET AFWA qui rapporte la production de surface du modèle. Les
utilisateurs peuvent créer leur propre Vtable pour d'autre production du modèle en
utilisant n'importe quel Vtables comme un gabarit,
« Ungrib » peut écrire des fichiers de données intermédiaires à un de trois formats
d'utilisateur-selectable suivants :
• WPS - un nouveau format contenant des renseignements supplémentaires
utiles pour optimiser l’exécution des programmes du modèle WRF.
• Le SI - le format intermédiaire précédent du modèle WRF.



• Le format de MM5, qui est inclus ici pour que « ungrib » puisse être
utilisé pour fournir les données d’entrée au format GRIB2 au système du
modèle MM5.
Certes, n'importe quel format peut être utilisé par WPS afin d’initialiser le modèle
WRF, mais le format de WPS soit recommandé.
Les données météorologiques du modèle global pour « ungrib » :
Les fichiers GRIB sont séparés en plusieurs sections, les sections, avant chaque
enregistrement, décrivent quelles données sont contenues dans l'enregistrement
(paramètres, temps de début, temps de prévision, résolution de la grille etc.) et la
dernière section contient les données binaires elles-mêmes. Les principales données
disponibles sont :
• Réanalyses NCEP/NCAR :
« NCEP/NCAR Reanalysis Project » est un projet commun entre les NCEP
(National Centers for Environmental Prediction) et le NCAR (National
Center for Atmospheric Research). Le but de ce projet était de fournir de
nouvelles analyses atmosphériques en utilisant les données historiques et
ainsi produire l'analyse de l'état de l'atmosphère actuelle. Ces données
globales ont une résolution de 2.5 x 2.5 degrés, elles sont disponibles toutes
les 6 heures depuis 1948.
• Réanalyses ECMWF (format GRIB):
La réanalyse appelée ERA-40 a été effectuée par le « European Centre » for
« Medium-Range Weather Forecasts » (ECMWF) pendant des années de
1957 à 2001. Le ECMWF avait déjà effectué une réanalyse pendant la
période de 1979 à 1993, le projet ERA-15, mais le projet ERA-40 est
beaucoup plus complexe, puisqu'il recouvre quarante années. De plus, ce
projet est d'autant plus complexe qu'il couvre des périodes où les avancées
technologiques en matière d'observations météorologiques ont été très
importantes, notamment avec l'apparition et la généralisation de l'utilisation
des satellites. Comme précédemment les données sont globales et
disponibles à une résolution de 2.5 x 2.5 degrés toutes les 6 heures.
• Prévisions NCEP GFS/AVN (format GRIB):
Un modèle numérique de prévision qui produit en temps réel des données de
prévision jusqu'à 360 heures (15 jours).
Les données de réanalyse sont des données obtenues à partir des modèles lancés sur
plusieurs années en mode d’assimilation de données. Des données d'observations
sont donc introduites au modèle. Selon le type de simulation que l'on souhaite
effectuer, l'utilisation de certains types de données est préférable. Dans le cadre de



simulations à long terme, les données de réanalyse sont très utiles. Par contre pour
effectuer des prévisions, les données GFS/AVN sont appropriées.
C’est pour ces raisons qu’il est préférable d'utiliser des données GFS/AVN, en effet
la compréhension des phénomènes passés permet notamment, en comparaison avec
les simulations numériques, d'améliorer les modèles de prévision utilisés en
intégrant le maximum d'observations. Cela revient à utiliser le maximum de
données disponibles pour mieux décrire les phénomènes atmosphériques.
Programme metgrid
Le programme « metgrid » interpole horizontalement les données météorologiques
au format intermédiaire qui sont extraits par le programme « ungrib » sur les
domaines de simulation que le programme « geogrid » a bien défini. La production
interpolée par « metgrid » peut alors être ingérée par le programme « real.exe ».
Les durées de temps interpolées par « metgrid » sont définies dans la partie "share"
de liste de nom du fichier namelist.wps de WPS, ils doivent être spécifiées
individuellement dans le namelist pour chaque domaine de simulation. Puisque le
travail du programme « metgrid », comme cela du programme « ungrib », est
dépendant de temps, le programme « metgrid » est initialisé chaque fois qu’on
dirige une nouvelle simulation.
Le contrôle de comment chaque champ météorologique est interpolé est fourni par
le fichier METGRID.TBL. Concrètement, le fichier METGRID.TBL fournit une
section à chaque champ et dans une section, il est possible de spécifier des options
comme les méthodes d'interpolation. La production de « metgrid » est écrite dans le
format d'E/S WRF API et ainsi, en choisissant le format d'E/S NetCDF, « metgrid »
peut écrire sa production au format NetCDF pour la visualisation facile en utilisant
des paquets de logiciel externes, en incluant la nouvelle version de RIP4.
Parallélisme dans le WPS
Si les dimensions des domaines traités par le WPS deviennent trop grandes pour se
situer dans la mémoire d'une seul unité centrale, il est possible d’exécuter le
programme « geogrid » et le programme « metgrid » dans une configuration de
mémoire distribuée.
Pour compiler « geogrid » et « metgrid » à l'exécution en mémoire distribué,
l'utilisateur doit avoir des bibliothèques MPI installées sur la machine prévue et doit
avoir compilé WPS en utilisant une "options de configuration" de "DM parallel".
Lorsque la compilation réussie, les programmes « geogrid » et « metgrid » peuvent
être exécutés avec l'instruction mpirun (du MPICH) ou poe (du MPI de l’IBM AIX
1600), selon la machine.



Comme on l'a mentionné plus tôt, le travail du programme « ungrib » n'est pas
disponible à la parallelization et, de plus, les exigences de mémoire pour le
traitement de « ungrib » sont indépendantes des exigences de mémoire de
« geogrid » et de « metgrid » ; ainsi, « ungrib » est toujours compilé pour une seul
unité centrale et dirigé sur une seule unité centrale, sans tenir compte sur "option de
configuration" de "DM parallel" a été choisie pendant la configuration.

Programme Parallelization
Geogrid.exe Oui
Ungrib.exe Non
Metgrid.exe Oui

Tableau I-1 Parallélisme dans le WPS

Chacun des formats d'E/S de WRF API standard (NetCDF, GRIB1, binaires) a un
format parallèle correspondant, dont le code est donné en ajoutant 100 à la valeur
d'io_form (par exemple, io_form_geogrid) pour le format standard. Il n'est pas
nécessaire d'utiliser un io_form parallèle, mais quand on l’a utilisé, chaque unité
centrale lira (écrira) sa donnée d’entrée (ou de sortie) sur un fichier séparé, dont le
nom est simplement le nom qui serait utilisé pendant l'exécution série, mais avec
une carte d'identité d'unité centrale de quatre chiffres ajoutée au nom.
Par exemple, exécuter « geogrid » sur quatre unités centrales avec
io_form_geogrid=102 créerait geo_em.d01.nc.0000, geo_em.d01.nc.0001,
geo_em.d01.nc.0002 et geo_em.d01.nc.0003 pour le domaine grossier.
Pendant l'exécution dans la mémoire distribuée, les domaines-modèles sont
décomposés dans les pièces rectangles. Par conséquent, si un parallèle io_form est
choisi pour la sortie de « geogrid », « metgrid » doit être dirigé en utilisant le même
nombre d'unités centrales qu'ont été utilisés pour diriger « geogrid ». De même si un
parallèle io_form est choisi pour les fichiers de sotie « metgrid », le programme
« real.exe » doit être dirigé en utilisant le même nombre d'unités centrales.
Évidemment, il est toujours possible d'utiliser une seule norme io_form en dirigeant
sur plusieurs des unités centrales, dans ce cas, toutes les données d’entrée et même
de sortie sont distribués. Comme une note finale, quand « geogrid » ou « metgrid »
sont dirigés par plusieurs des unités centrales, chaque unité centrale écrira son
propre fichier de journal (log file), avec les noms des fichiers étant ajoutés avec les
mêmes codes de carte d'identité d'unité centrale de quatre chiffres qui sont utilisés
pour les fichiers d'E/S de WRF API.

3.2. Initialisation du modèle ARW
Introduction



Le modèle ARW a deux grandes classes de simulations qu'il est capable de
produire: Ceux sont avec une initialisation idéale et ceux utilise les données réelles
pour l'initialisation.
Ci-dessous, nous allons présenter tous les deux types d’initialisation du modèle
WRF ARW.

Figure I-7 Initialisation du modèle ARW

La sélection du type de simulations de prévision est faite en exécutant l’instruction
«./compile ». Si l'utilisateur choisit « ./compile em_real », le programme
d'initialisation sera construit en utilisant un des modules prévus du cas de données
réelles (un des fichiers ./WRFV2/dyn_em/module_initialize_*.F). Pour chaque
programme d’initialisation, la même sorte d'activités continue à faire :
• Lire les données du fichier namelist
• Allouer l'espace de mémoire
• Calculer l'état de base (états de l’initialisation)
• Initialiser le reste de variables
• Produiser le fichier de condition initial (wrfinput_d*, wrfbdy_d*)
Le cas de données réelles fait un peu de travail supplémentaire :
• Lire les données d'entrée approvisionné par le WPS ou le SI) si ce sont les
données du WPS, calculer la pression sèche de surface, les niveaux (level) du
modèle et interpoler verticalement des données
• Calculer le profil de température de référence (différence avec les cas idéals,
tenir compte des normes saisonnières)
• Préparer des champs de sol pour l'utilisation dans le modèle (l'interpolation
verticale aux niveaux demandés)



• Faire les chèques pour vérifier les catégories de sol, terrain d'utilisation, le
masque de terrain, la température de sol, la température de surface de la
marine. Tous ce sont en accord l'un avec l'autre
• Les 3D données (u, v, t, q, ph) sont couplés avec les facteurs de carte (sur
l'étalement correct) et le total « mu »
Initialisation pour les cas de données idéales
Le programme "idéal" est une alternative dans le système ARW. Il permet de faire
initialisation pour les cas de données idéals. Typiquement, ce programme n'exige
aucun de donnée d’entrée. Le programme « ideal.exe » se concentre seulement aux
les travaux de recherche, donc on ne fait pas les recherches approfondies ici.

Ideal 2D Ideal 2D Ideal 3D
hill Squall line supercell

Ideal 2D Ideal 3D
grav baroclinic
Waves

Figure I-8 Initialisation pour les cas de données idéaux

Les cas de données idéales disponibles sont comme ci-dessous :
• Squall2d_x (test/em_squall2d_x)
- La ligne de rafale 2D (x, z) utilisant la microphysique de Kessler et
300 m^2/s fixés viscosité.
- La condition période utilisé dans l’axe y pour que le modèle 3D
produise la 2D simulation.
- La vitesse v devrait être le zéro et il ne devrait y avoir aucune
variation dans l’axe y aux résultats.
• Squall2d_y (test/em_squall2d_y)
- Même comme squall2d_x, sauf avec (x) tourné à (y).
- La vitesse u devrait être le zéro et il ne devrait y avoir aucune
variation dans l’axe x aux résultats.



• La simulation de supercellule en quart-cercle 3D (test/em_quarter_ss).
- Les supercellules mouvantes à gauches et à droites sont produites.
• L’écoulement sur une colline en forme de cloche 2D (x, z)
(test/em_hill2d_x)
- Avec la demi-largeur de 10 kms, la longueur de grille de 2 kms, la
colline de 100 m de haut, l’écoulement de 10 m/s,
- N=0.01/s, domaine de 30 kms de haut, 80 niveaux, les limites
ouvertes radiatives, absorption de la limite supérieure.
- Ce cas est dans le régime hydrostatique linéaire.
• Vagues baroclinic 3D (test/em_b_wave).
Initialisation pour les cas de données réelles
Le cas de données réelles était très important dans le modèle ARW avec lequel on
pourra exécuter le modèle jour après jour pour servir des opérations de prévision
météorologique. Ce sera donc également le type d’initialisation du ARW déployé au
centre HPC.

Donées
géographiques
statiques

WPS

Donées du
modèle global
(NAM,GPS,RUC,
NNRP)

Source externe de donnée
Système de
prétraitement du WRF

Figure I-9 Initialisation pour les cas de données réelles

Les données réelles sont fournies par le Système de Prétraitement (WPS).
Fonctionnellement, WPS produit les données de sortie qui sont introduites ensuite
au programme « real.exe » comme les données d’entrée. WPS envoie des données
ci-dessous qui sont prêts à être utilisées dans le programme « real.exe »:
• Les données d’entrées au format E/S de l’API de WRF.
• Les données ont déjà été interpolé horizontalement au point de grille correct
pour chaque variable.



• Les données météorologiques 3D du WPS : u, v, theta, mélange de ratio
• Les données 3D de surface du WPS : la température de sol, l'humidité de sol,
le liquide de sol
• Les données météorologiques 2D du WPS : La totale pression de surface
sèche
• Les données statiques 2D : Le terrain, les catégories de terrain, les
informations de sol, les facteurs de carte, Coriolis, la rotation de projection,
les données interpolées mensuelles.
• La matrice 1D de la coordonnée verticale
• Constants : la taille du domaine, la date, les listes de champs optionnels
disponibles, le coin latitude/longitude

3.3. Cœur ARW du WRF
Le coeur ARW a pour un modèle complètement compressible et nonhydrostatique
(avec une option hydrostatique). Sa coordonnée verticale est une coordonnée de
pression hydrostatique suivant le terrain. L'étalement de grille est la C-grille
Arakawa. De plus, le modèle utilise les projets 2D et 3D d'intégration de temps
d'ordre Runge-Kutta et projets à l’ordre 2D de 6D d'advection dans les directions
tant horizontales que verticales.

Figure I-10 Coordonnée de pression hydrostatique suivant le terrain

Le modèle ARW (avec cœur ARW) soutient une variété de capacités. Celle-ci
inclut :
• Les simulations avec les données réelles et les données idéalisées
• Les options de conditions limites latérales différentes pour les simulations
avec les données réelles et les données idéales



• Les options complètes de physique
• Bien-déterminé-positif d'advection
• Non-hydrostatique et hydrostatique (l'option à la durée d'exécution)
• Emboîtement « one-way », « two-way », emboîtement mouvant
• Analyse en trois dimensions.
• Assimilation des données d’observation.
Emboîtement du ARW
L'ARW soutient la technique d’emboîtement horizontal qui permet la résolution
d'être concentrée sur une région d'intérêt en présentant une grille supplémentaire (ou
les grilles) dans la grille de simulation. Certes, cette implémentation d’emboîtement
est en façons semblables aux implémentations dans d'autre modèle méso-échelle
(par exemple MM5). Mais, l'amélioration importante du technique d’emboîtement
de l'infrastructure du ARW par rapport aux techniques utilisées dans d'autres
modèles est la capacité de calculer efficacement en parallèle la simulation avec des
grilles d’emboîtement.
Actuellement, il est possible de choisir un emboîtement dit « two-way » ou « one-
way ». En « one-way » seul le domaine grossier peut affecter le domaine plus fin.
Les conditions limites du domaine fin sont dérivées de celles du domaine grossier
par interpolation. En « two-way » les résultats sur le domaine fin peuvent affecter la
solution sur le domaine grossier, par conséquent l'interaction est totale entre les
différents domaines.

Figure I-11 Emboîtement du modèle ARW



4. Conclusion
Dans ce chapitre on a eu une vue globale de différents modules composant du
modèle WRF et en particuler une vue globale du système du sous modèle WRF
ARW. Ceci a permis une première approche et était indispensable pour pouvoir
ensuite utiliser le modèle ARW à bon escient. Les chapitres qui suivent,
mentionnent son application à la réalité.
À partir de ce chapitre, le nom «Modèle WRF » est utilisé pour indiquer le modèle
WRF ARW puisque ce nom est utilisé plus populairement.



CHAPITRE II Calcul à haute performance avec WRF

Grâce aux connaissances théoriques du modèle de prévision météorologiqueWRF,
On sera le déployer sur les ordinateurs à haute performance. Ce travail permet de
renforcer les connaissances théoriques et également d’apporter le premier résultat le
plus important afin qu’un système professionnel de prévision météorologique soit
bien construit et appliqué au Vietnam.

1. Matériel
Le modèle WRF sera déployé sur tous les trois superordinateurs à haute
performance : Bkluster, IBM eserver 1350, IBM AIX eserver 1600. Le déploiement
du modèle sur BKluster a pour but d’exploiter les prévisions vers les utilisateurs
ordinaires. En revanche, Le modèle WRF sera déployé sur tous les deux
superordinateurs du centre HPC de l’université nationale de Hanoi pour être
exploité par les chercheurs du Centre de Météo (CM), Université Nationale de
Hanoi.

1.1. Bkluster
Centre HPC est équipé un cluster comportant :
• 2 Nœuds de calcul. Chaque nœud se compose d’un processeur avec coeur
double Intel Xenon 2.66 GHz, mémoire centrale : 2 GO, disque dur 80 GO.
• 1 Nœud de serveur se compose d’un processeur avec coeur double Intel
Xenon 3.0 MHz, mémoire centrale : 1 GO, disque dur 240 GO
• Interfaces réseau : GEthernet.
• Système d'exploitation : CenOS 5
• Compilateur : Fortran, C, C++ du Portland Group version 7.0
• Bibliothèque de programmation par passages de messages : MPICH 1.2.7
et MPICH 2 – version 1.0.3
• Performance totale du système : ≈ 10 GFlops.

1.2. IBM eServer Cluster 1350
• 8 Noeuds de calcul, Chaque noeud se compose de deux processeurs Intel
Xeon Dual Core 3.2 GHz, 2GB RAM, 1x36 GB HDD, DVD ROM.
Performance totale du système (8 noeuds) :≈ 51.2 GFlops
• 2 Noeuds de stockage, Chaque noeud se compose de deux processeurs Intel
Xeon Dual Core 3.2 GHz, 3 GB RAM, 4x72 GB HDD



• 1 Noeud de gestion, se compose un processeur Intel Xeon Dual Core 3.2, 3
GB RAM, 2x36 GB HDD
• Équipement de stockage : IBM EXP400 Ultra320 SCSI Storage Enclosure,
10x73 GB HDD SCSI 320 MBps 15KRpm, système de fichier disque-
partagé : GPFS pour Linux v2.3.0.5
• Système d’exploitation : HĐH Redhat Enterprise Linux 3.0
• Interfaces réseau : GEthernet

1.3. IBM eserver Cluster 1600
• 5 Nœuds de calcul pSeries 655, Chaque nœud se compose de 4 CPU Power
4+ 64 (2core) bit RISC 1.7 GHz du IBM; cache 5.6MB ECC L2, 128MB
ECC L3, largeur de bande du cache : 72.3 GBps; 32GB RAM, largeur de
bande du mémoire 51.2 GBps; 6x36 GB HDD. Performance totale du
système (5 nœuds) : 240 GFlops (limite d’enlargir : 768 GFlops/16 noeuds).
• 1 nœud de gestion CSM p630: Power4+ 64 bit (2 core) 1.2 GHz; cache 1.5
MB ECC L2, 8MB ECC L3, Largeur de bande du cache: 12.8 GBps; 1GB
RAM, Largeur de bande du mémoire : 6.4 GBps; 6x36 GB HDD, DVD
ROM.
• 1 Nœud de contrôle du matériel HCM: Intel Xeon 3.06 GHz, 1GB RAM, 40
GB HDD, DVD RAM.
• Tous les nœuds se connectent par HPS (Switch à haute performance),
Largeur de bande : 2GBps GEthernet.
• Équipement de stockage partagé : IBM DS4400 et EXP700 connectent au
Système IBM 1600 par Cable optique 2Gbps.

300
250
200
150 Performance de calcul
100
50
0
Bkluster IBM eserver 1350 IBM eserver 1600

Figure II-1 Comparaison de la performance de calcul entre trois systèmes.

La figure II-1 montre que la performance de calcul du système IBM AIX eserver
1600 était la plus haute de tous les trois. Pourtant, la performance réelle dans les
problèmes concrets ne reflète pas totalement comme ceci montré dans cette figure.



2. Environnement du logiciel

2.1. Compilateurs et langage de programmation demandés
Le modèle WRF est écrit en langage Fortran (comme Fortran 77, Fortran 90). Parmi
les composants du modèle WRF, RSL et maintenant RSL_LITE, qui s'assoit entre
WRF et l'interface MPI est écrit en langage C. Il y a aussi des programmes
auxiliaires qui sont écrits en C pour exécuter l'analyse syntaxique et la construction
de fichiers.
Donc, un compilateur C est aussi nécessaire pour compiler des programmes et des
bibliothèques externes.
Supplémentairement, le mécanisme de bâtiment du WRF utilise plusieurs langage
de script : perl (pour manipuler les tâches différentes comme le navigateur de code),
Cshell et Bourn Shell. Les outils traditionnels de traitement de texte sous UNIX
sont utilisés : make, M4, sed et awk.
Le WRFSI est surtout écrit dans le langage Fortran 77 et le langage Fortran 90 avec
quelques routines en langage C. Les scripts de Perl sont utilisés pour diriger les
programmes et Perl/Tk est utilisé pour GUI ( interface graphique pour l’utilisateur).
“Make” est utilisé dans la construction de tout executables.

2.2. Les bibliothèques optionnelles
La seule bibliothèque qui est presque toujours exigée est le paquet netCDF [6]
d'Unidata, puisque le modèle WRF utilise les bibliothèques netCDF pour lire et
écrire les données de sorties et les données temporaires en format netCDF.
Pour la mémoire distribuée, il faut installer une bibliothèque de programmation par
passages de messages (MPICH, PVM) [7]. Parmi toutes les versions du MPICH, la
version 2 du mpich est recommandée.
En ce qui concerne les programmes utiles pour visualiser les données temporaires
du modèle, on a besoin également des bibliothèques du Graphique NCAR installés
sur le système.
Par ailleurs, il y a trois bibliothèques qui seront exigées par le programme ungrib
pour soutenir l'Édition GRIB 2 [8] de compression.
• JasPer (une implémentation de la norme JPEG2000 pour la compression
"lossy")
• Zlib (une autre bibliothèque de compression, qui est utilisée par la
bibliothèque PNG)
• PNG (la bibliothèque de compression pour la compression "lossless")



3. Domaines de calcul
En considération de la performance totale de trois systèmes (BKluster,IBM eserver
1350, IBM eserver 1600), des expériences et des résultats, les différents domaines
de calcul seront utilisés pour chaque système.

3.1. Domaine de calcul au Bkluster.
La performance totale du système BKluster était plus faible, c’est la raison pour
laquelle le domaine à calcul est déterminé le plus petit. La résolution horizontale de
ce domaine (Figure II-2) composant 112x61 points est de 18km. En plus, ce
domaine recouvre seulement le Vietnam. Pour servir les opérations de prévision
fondamental comme la prévision de température, la prévision de condition du ciel,
ce domaine est acceptable.
Les paramètres du domaine Vietnam1 :

e_we = 61,
e_sn = 112,
geog_data_res = '30s',
dx = 18000,
dy = 18000,
map_proj = 'lambert',
ref_lat = 15.8,
ref_lon = 105.4,
truelat1 = 15,
truelat2 = 15,
stand_lon = 105,

Figure II-2 Domaine Vietnam1

3.2. Domaine de calcul au IBM eserver 1350.
Le premier domaine (Figure 2-1) recouvre l'Asie du Sud-est: 5-30o N, 90-125o E. Il
se compose de 50x70 points avec la résolution horizontale égale à 54km.
Verticalement, ce domaine se divise en 23 niveaux sigma à partir de la surface
jusqu'à 100mb.
Les paramètres du domaine DNA_nested :

e_we = 70,61,



e_sn = 50,100,
dx = 54000,
dy = 54000,
ref_lat = 17.5,
ref_lon = 107.5,
truelat1 = 17.5,
truelat2 = 17.5,
stand_lon = 107.5,

Figure II-3 Domaine DNA_nested

Le deuxième domaine était exactement le domaine utilisé au Bkluster. Ce domaine
recouvre tout le Vietnam et il est parfaitement emboîté au premier. Utilisant le
premier domaine qui a le rayon d’observation plus large, les chercheurs pourront
faire des prévisions de la tendance de la météo comme les saisons, les tempêtes, les
orages…



3.3. Domaine de calcul au IBM eserver 1600
Évidemment, IBM eserver 1600 était le système le plus puissant des trois systèmes.
C’est pourquoi ses domaines à calcul se composent de deux domaines ci-dessus et
encore des domaines plus petits pour chaque région du pays. Ces petits domaines
ont possibilité d'avoir une résolution égale de 6 km pour une prévision météo plus
précise.
Les paramètres du domaine DNA_nested2 :

e_we = 70,61,100,70,76,97, e_sn = 50,112,64,76,79,61,
dx = 54000,
dy = 54000,
ref_lat = 17.5,
ref_lon = 107.5,
truelat1 = 17.5,
truelat2 = 17.5,
stand_lon = 107.5,

Figure II-4 Domaine DNA-nested2



4. Données du modèle ARW

4.1. Données météorologiques
Les sources de données utilisées pour modèle ARW sont extraites à partir des autres
modèles régionaux ou des modèles globaux au format GRIB1 ou GRIB2 comme le
modèle GFS/AVN, modèle NAM… Pourtant, selon les chercheurs au Centre de
Méteo, Il vaut mieux utiliser les données météorologiques extraites du modèle
global GFS/AVN. Ces données peuvent être utilisées afin de prévoir le temps pour
16 jours, l'intervalle entre les prévisions est de 3 heurs, et le moment d'analyse est:
0h, 6h, 12h, et 18h (UTC/GMT). En réalité, les calculs effectués par un modèle
numérique voient leur fiabilité diminuer à mesure que leur échéance s'éloigne du
moment des relevés d'observation. Le système de prévision numérique du temps
ARW s'applique donc à des échéances allant au-delà de 3 jours à partir du moment
de l'observation.
On peut télécharger les données chaque jour sur le site :
ftp://ftpprd.ncep.noaa.gov/pub/data/nccf/com/gfs/prod/

4.2. Données géographiques
Modèle ARW nécessite des données de topographie, végétation, eau, type de sol.
Toutes ces données sont disponibles à différentes résolutions, c’est-à-dire 1degré,
30, 10, 5 ou 2 min, et 30seconds. Des données globales sont disponibles à l'USGS
(US Geological Survey), elles sont téléchargeables sur :
http://www.mmm.ucar.edu/wrf/src/wps_files/geog.tar.gz
Pour toutes les résolutions exceptées celle à 30 secondes, la base est constituée par
une carte topographique en 2 dimensions (courbes de niveau). Les courbes de
niveaux sont numérisées afin d'obtenir un fichier de points comprenant les
paramètres topographiques suivants : longitude (X), latitude (Y), altitude (Z).

5. Déploiement des modules du modèle ARW

5.1. Module WPS
Il y a essentiellement trois pas principaux à exécuter le Prétraitement WPS :
• Définir un domaine du modèle et des domaines emboîtés avec « geogrid ».
• Extraire des données météorologiques des ensembles de données GRIB pour
la simulation en période avec « ungrib ».
• Interpoler horizontalement des données météorologiques aux domaines du
modèle avec « metgrid ».



Quand les simulations multiples doivent être dirigées pour les mêmes domaines, il
est seulement nécessaire d'exécuter le premier pas une fois ; par la suite, les données
seulement variables de temps comme les données météorologiques doivent être
traitées pour chaque simulation en utilisant tous les deux : deuxième pas et
troisième pas. Les détails de ces trois pas sont présentés ci-dessous.

Figure II-5 Processus de l’execution des programmes du WPS

Pas 1 : Définir des domaines du modèle avec geogrid
Les domaines sont définis dans la partie "geogrid" du fichier namelist.wps et, en
plus, les paramètres dans la partie "share" doivent également être bien rédigés.
Les champs de base à configurer sont:
Dans la partie « share » du namelist.wps
max_dom = 2,
La valeur de ce champ spécifie le nombre total de domaines, en incluant le domaine
parental et les domaines emboîtés dans la simulation.
io_form_geogrid = 2,
Ce champ signifie le format d'E/S du WRF API dans lequel les fichiers de domaine
créés par le programme « geogrid » seront écrits. Les options possibles sont : 1 pour
le format binaire; 2 pour le format NetCDF; 3 pour le format GRIB1. Quand
l'option 1 est donnée, les fichiers de domaine auront un suffixe de .int; quand
l'option 2 est donnée, les fichiers de domaine auront un suffixe de .nc; quand
l'option 3 est donnée, les fichiers de domaine auront un suffixe de .gr1. La valeur
implicite est 2 (le format NetCDF).
opt_output_from_geogrid_path = './',



C’est une chaîne de caractères qui signifie le chemin, relatif ou absolu, à l'endroit
d'où les fichiers de sortie de « geogrid » devraient être écrits et lus. La valeur
implicite est ‘. / ’.
Pour définir la projection de domaines, les champs suivants doivent être bien
rédigé :
− MAP_PROJ: ‘lambert’, ‘mercator’, ‘polar’, or ‘rotated_ll’ ;signifie le
type de la projection
− TRUELAT1: Première vraie latitude
− TRUELAT2: Deuxième vraie latitude (seulement pour « Lambert
conformal”)
− STAND_LON: le méridien parallèle à l'axe y
Définir la région couverte (les dimensions et l'endroit) par le domaine grossier en
utilisant les champs suivants :
− REF_LAT, REF_LON : le (lat, lon) d'un endroit connu dans le
domaine (par défaut, le point au coeur du domaine)
− DX, DY: la distance de Grille aux deux directions x et y (unité de
mesure est dans mètres)
− E_WE : Le nombre de points dans la direction est-ouest.
− E_SN : Le nombre de points dans la direction nord-sud.

Figure II-6 Définir un domaine du modèle WRF



Après avoir bien configuré la partie « share » et la partie « geogrid », le programme
« geogrid.exe » pourra être exécuté en façon parallèle ou non :
. /geogrid.exe
./mpirun –n 4 ./geogrid.exe
Ce message suivant serait affirmé si le programme « geogrid.exe » est bien
exécuté :
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Successful completion of geogrid. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Pas 2 : Extraire des champs météorologiques des fichiers GRIB avec
« ungrib ».
Après avoir téléchargé des données météorologiques dans le format de GRIB, le
premier pas dans l’extraction des champs au format intermédiaire implique de
rédiger la partie « share » et « ungrib » du fichier namelist.wps - le même fichier qui
a été rédigé pour définir les domaines de simulation.
Les champs de base à configurer sont:
start_date = '2006-08-16_12:00:00','2006-08-16_12:00:00',
end_date = '2006-08-16_18:00:00','2006-08-16_12:00:00',
Ces champs représentent deux listes de nombres entiers de MAX_DOM éléments
qui spécifient la date de commencement et la date de fin au temps d'UTC de la
simulation pour chaque domaine.
interval_seconds = 21600
Ce champ représente l’intervalle de secondes entre les fichiers d'entrée
météorologiques variables du temps.
Dans la partie « ungrid » du namelist.wps
out_format = 'WPS',
On pourrait définir le format des données intermédiaires à être écrites par
« ungrib ». Le programme metgrid peut lire n'importe quels formats comme ‘WPS’,
‘SI’ et ‘MM5’.
Après avoir modifié convenablement le fichier namelist.wps, un Vtable doit être
fourni et les fichiers GRIB doivent être reliés (ou copiés) aux fichiers dont les noms
sont attendus par « ungrib ». Par exemple, si les données GRIB sont du modèle
GFS, cela peut être accompli par la commande suivante :



> ln -s ungrib/Variable_Tables/Vtable. GFS Vtable
Pour simplifier le travail de relier les fichiers GRIB aux fichiers que le programme
« ungrid.exe » attend, on pourra utiliser un script de commandes, link_grib.csh. Le
script link_grib.csh prend une liste des fichiers GRIB comme les arguments de ligne
d'instruction.
Sur bkluster, les données GRIB ont été téléchargées au répertoire
modelWRF/autoWRF/datas/gfs2008050412/, les fichiers sont reliés avec
link_grib.csh par les commandes suivantes :
>ls ~/modelWRF/autoWRF/datas/gfs2008050412/
-rw-r--r-- 1 trungtvk48 trungtvk48 14156270 May 4 23:42 gfs.t12z.pgrbf00.grib2
>link_grib.csh ~/modelWRF/autoWRF/datas/gfs2008050412/gfs.t12z.pgrbf *
Après avoir rédigé le fichier namelist.wps et relié le fichier Vtable approprié et les
fichiers GRIB, le programme « ungrib.exe » peut être exécuté pour produire des
fichiers de données météorologiques au format intermédiaire choisi.

5.2. Module ARW
Certes, Le modèle ARW supporte deux grandes classes de simulations
correspondants au cas de données idéales ou au cas de données réelles. Pourtant, le
système de prévision météorologique WRF au centre HPCC soit un système
opérationnel, c’est la raison pour laquelle le modèle ARW déployé au centre HPCC
utilise seulement les données réelles de sorties du système de prétraitement WPS.
Comme le déploiement du module WPS, tout d’abord on doit configurer le fichier
namelist.input pour bien exécuter le modèle ARW.
Les paramètres de base à configurer sont:
Dans la partie « time_control » du namelist.wps

&time_control
run_days = 0,
run_hours = 72,
run_minutes = 0,
run_seconds = 0,
start_year = 2008, 2000, 2000,
start_month = 05, 01, 01,
start_day = 04, 24, 24,



start_hour = 12, 12, 12,
start_minute = 00, 00, 00,
start_second = 00, 00, 00,
end_year = 2008, 2000, 2000,
end_month = 05, 01, 01,
end_day = 07, 25, 25,
end_hour = 12, 12, 12,
end_minute = 00, 00, 00,
end_second = 00, 00, 00,
interval_seconds = 10800

Les parameters START_YEAR, START_MONTH, START_DAY, START_HOUR,
END_YEAR, END_MONTH, END_DAY, END_HOUR, INTERVAL_SECONDS se
recopient de namelist.wps du module WPS.
run_hours = 72,
Pour la prévision en 3 jours, ce champ a toujours la valeur 72 (heures).
Dans la partie « domains » du namelist.wps

&domains
time_step = 108,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 1,
s_we = 1, 1, 1,
e_we = 61, 112, 94,
s_sn = 1, 1, 1,
e_sn = 112, 97, 91,
s_vert = 1, 1, 1,
e_vert = 28, 28, 28,
num_metgrid_levels = 27
dx = 18000, 10000, 3333,
dy = 18000, 10000, 3333,

Cette partie se compose également des mêmes paramètres du fichier namelist.wps
du WPS. Donc, il faut fixer les mêmes valeurs de chaque paramètre dans tous les
deux fichiers.
time_step = 108,



La valeur de ce paramètre était le pas de temps ‘en seconde’ pour l'intégration du
temps (recommandé 6*dx en km pour un cas typique). Avec l’intervalle de la grille
de calcul au Bkluster, dx=dy=18000, il faut mieux mettre « time_step=108 »
num_metgrid_levels: = 27,
Il signifie le nombre des niveaux verticaux de données d'arrivée. Comme le modèle
utilise les données météorologiques du modèle global GFS, cette valeur de ce
paramètre était toujours 27.
Ce module se compose de deux programmes « real.exe » et « wrf.exe ». Le
processus de déploiement du module ARW est comme ceci suivant :

Figure II-7 Processus de l’exécution des programmes du ARW

6. Conclusion
Dans ce chapitre, on aborde précisément tous les problèmes qui concernent le
déploiement du modèle WRF, y compris : la détermination du domaine à calcul sur
les trois superordinateurs. Les résultats obtenus sont très importants puisque le
modèle WRF déployé a bien produit les données de prévision météorologique.
Pourtant, l’exécution du modèle est encore manuelle, il manque un système
d’automatisation des tâches et puis, le résultat de sortie est plus spécialiste. Les
utilisateurs ordinaires ont donc des difficultés à le comprendre.
Les chapitres suivants se concentreront sur deux grands problèmes :
• Rechercher sur la configuration d’exécution du modèle WRF le plus optimal
sur chaque superordinateur.
• Déployer un système professionnel qui pourra fournir directement les
bulletins de météo chez les utilisateurs ordinaires.



CHAPITRE III Évaluation des expériences

1. Introduction
Comme le modèle WRF est installé sur trois systèmes de calcul à haute
performance : Bkluster, IBM eserver cluster 1350 et IBM eserver 1600, la question
apparue sera de comment trouver de meilleures conditions pour l’exécution du
système de prévision météorologique WRF. En plus, la performance de calcul de
trois systèmes en particulier sur l’exécution du modèle WRF sera également
évalués. Enfin, l'environnement le plus optimal est établi, les parties ci-dessous
précisent ces expériences ainsi que les réalisations acquises.

2. Les expériences réalisées sur Bkluster
Le programme « wrf.exe » est le plus important du système, le résultat et le temps
d’exécution de ce module en plusieurs modes reflètent la performance du système
ainsi que sa stabilité. Par conséquent, les critères d’évaluation ne concentrent que
sur cette partie particulière du modèle.
Méthode d’évaluation :
• Exécuter le programme « wrf.exe » avec les données d’entrées différentes, en
divers modes et le nombre de nœuds de calcul variant.
• Utiliser 2 façons pour :
- D’une part, on évalue le temps d’exécution du MM5 en chaque mode
d’opération avec le nombre de processeurs variés.
- D’autre part, on évalue le temps d’exécution en plusieurs modes avec
le nombre de processeurs fixés.
Cette évaluation s’est fait pendant 3 jours : 10, 11 et 12 mai 2008 et le temps moyen
de calcul est arrondi selon l'unité de minute. Le domaine à calcul Vietnam1 est
utilisé dans toutes les expériences.

2.1. Mode séquentiel
Le programme wrf.exe est compilé par 2 compilateurs différents: pgf90 (Portland
Group), ifort (Intel). On voit que le compilateur influence relativement le temps de
calcul, si ifort est utilisé pour la compilation et l'exécution du programme wrf.exe,
on économise environ 10% de temps par rapport à pgf90 pour une prévision météo.
En effet, l’exactitude d'un programme compilé par ifort n'est égale qu'à 1/10 de
celle du programme compilé par pgf90. Ce pourrait être la raison pour laquelle le
compilateur de l'Intel (ifort) cause moins de temps d'opération que celui du Portland
Group (pgf90).



Mode séquentiel
120 117
108
110

100

90

80 Mode séquentiel

70

60

50
pgi 7.0 Intel 10.1.015

Figure III-1 Mode séquentiel

2.2. Mode parallèle
En mode parallèle, non seulement des compilateurs mais en plus beaucoup d'autres
raisons influent sur le résultat du modèle. Précisément, ce sont la communication
entre les processus, le nombre de processeurs participés, la bibliothèque de
programmation par passages de messages (MPICH) et compilateurs.

90
78
80

70
60
60 57
49
50
mpich1.2.7p1
40
mpich2‐1.0.3
30

20

10

0
2processeurs/2noeuds 2processeurs/1noeuds

Figure III-2 Temps d'exécution influencé par MPICH et la communication

Premièrement, pour évaluer l’influence de la communication entre les processus, on
considère le cas où le programme wrf.exe est exécuté en utilisant 2 processeurs/ 2
nœuds et l’autre cas utilisant 2 processeurs/ 1 seul nœud. On voit que la



communication entre les processus /2 nœuds différents influence fortement sur le
temps de calcul du programme wrf.exe par rapport à la communication interne sur 1
seul nœud. D’ailleurs, en ce qui concerne la bibliothèque de programmation par
passages de messages (MPICH), l’influence de la communication dans MPICH 1
est plus forte de 25% que laquelle dans MPICH 2 de 16,6%.
Deuxièmement, dans la figure, on voit également que le fait d’utiliser MPICH 2
gagne le bénéfice du temps en comparaison d’autre cas avec MPICH 1. Ceci montre
que le programme wrf.exe supporte mieux la bibliothèque de programmation par
passages de messages MPICH 2. Si l’on peut faire un comparaison entre le modèle
WRF et le modèle MM5 que MPICH 1 convient, on sait bien que le modèle WRF
est une évolution et un successeur du modèle MM5, c’est la raison pour laquelle
WRF supporte mieux la nouvelle version de MPICH.
Ci_après, l'évaluation concentre sur la quantité de processeurs utilisés afin de
trouver le plus meilleur cas pour l’exécution du modèle WRF sur Bkluster. Dans
cette évaluation, la bibliothèque de programmation par passages de
messages MPICH 2 et le compilateur pgf90 sont choisis.

Figure III-3 L’influence de la quantité de processeurs

On peut voir que le temps moyen est linéaire et il atteint le minimum quand le
nombre de processeurs est égal à 4. Malheuresement, le nombre de processeurs ne
peut pas augmenter pour pourvoir trouver le plus meilleur résultat, faute de nœud à
calcul.
C’est pourquoi, j’utilise actuellement le domaine Vietnam1 comme le domaine dans
ces expériences pour l’exécution du modèle WRF sur Bkluster. Le programme



« wrf.exe » est toujours exécuté en mode parallel sur 4 processeurs avec le temps
moyen environ 40 minutes.

3. Comparaison de la performance entre trois systèmes
La dernière évaluation que je voudrais aborder dans mon mémoire de fin d’études
est la comparaison du temps de calcul du programme « wrf.exe » entre trois
systèmes qui ont bien déployé le modèle WRF.
Pour garder cette évaluation objectif, on utilise le même domaine à calcul
DNA_nested (figure II-3) pour exécuter le modèle WRF. La configuration tout
optimale de chaque système est déterminé en utilisant les mêmes expériences sur
Bkluster. Pourtant, l’expérience est fait une seule fois sur IBM AIX eserver cluster
1600, car le système était en panne depuis le mois de mars 2008.

2 processeurs 4 processeurs
Temps moyen (minutes) 108 56

Tableau III-1Temps moyen influencé par le nombre de processeurs sur Bkluster

4 processeurs 8 processeurs 16 processeurs
Temps moyen (minutes) 72 50 60

Tableau III-2Temps moyen influencé par le nombre de processeurs sur IBM 1350

8 processeurs
Temps moyen (minutes) 26

Tableau III-3 Temps moyen influencé par 8 processeurs sur IBM 1600

La configuration la plus optimale :
• BKluster
- 4 Processeurs/2 nœuds
- MPICH 2 – version 1.0.3
- Compilateur : pgf90 (Porlan Group) 7.0
• IBM eserver 1350
- 8 Processeurs/2 nœuds
- MPICH 2 – version 1.0.3
- Compilateur de fortran : pgf90 (Porlan Group) 7.0



• IBM AIX eserver 1600
- 8 Processeurs/ 1 nœuds
- la bibliothèque de programmation par passages de messages (MPI) du
vendeur IBM
- Compilateur de fortran du vendeur IBM

Figure III-4 Temps moyen au cas optimal de trois systèmes

Grâce aux informations de la figure III-4, on pourrait apercevoir que IBM AIX
eserver 1600 / 8 processeurs / 1 nœud ne perd qu’environs 26 minutes pour exécuter
le modèle WRF (domaine DNA_nested). Au contraire, avec le même nombre de
processeurs, IBM eserver 1350 / 8 processeurs / 2 nœuds a eu besoin du temps
double : 50 minutes à exécuter. C’était illogique puisqu’on ne bénéficie pas
beaucoup de performance des 8 processeurs par rapport à Bbluster avec 4
processeurs.
Pour comprendre mieux la situation, on fait la comparaison du temps moyen
nécessaire pour exécuter le modèle WRF (domaine DNA_nested) entre Bkluster et
IBM eserver 1350 ci-après. Le nombre de processeurs soit le même 4.



80 72
56
60

40

20 Temps moyen

0
Bkluster / 4 IBM AIX 1350 / 4
processeurs processeurs

Figure III-5 Comparaison entre Bkluster et IBM 1350

Sur la vue globale, la performance de 1 nœud (4 processeurs) de l’IBM eserver
1350 soit plus haute que laquelle de Bkluster. Mais à cause d’une panne du système,
le modèle WRF et aussi les données d’entrée (sortie) du modèle sont obligées à
installer sur l’équipement de stockage qui attache au système par une ligne Ethernet
(100 Mbps) par rapport à GEthernet. C’est la raison pour laquelle le système ne peut
pas exploiter sa performance totale.

4. Conclusion
Dans ce chapitre, on a fait des expériences afin de trouver la configuration optimale
de l’exécution du modèle WRF sur tous les trois systèmes. On a aussi quelques
comparaisons entre eux. Certes, les expériences exhaustives ne peuvent pas être
relevées, en raison des difficultés objectives. Mais, j’ai obtenu des connaissances
précieuses de la construction en système à haute performance. Tous les composants
du système influencent fortement la performance totale : Un système attendrait sa
performance la plus optimale si on garde l’unité de tous les composants.



CHAPITRE IV Application du modèle WRF au Centre HPC

1. Introduction
Comme déjà mentionné dans les chapitres précédents, les résultats de prévision
météorologique du modèle pourraient être visualisés en utilisant des outils
graphiques (NCAR, RIP4, …) . Parmi lesquelles, nous avons choisi d’installer
Graphiques NCAR comme le programme pricipal pour nous donner des images
météorologiques de qualité.
Image
NCL script
météorologique

Fichier au
format netCDF

Figure IV-1 Produire des images météorologiques

Certes, les images météorologiques sont bien utiles pour que des chercheurs
puissent les utiliser pour relever des prévisions météorologiques de l’état de météo
général comme les prévisions de tempêtes, de saisons, de phénormènes
spécialisés. Mais, chez les utilisateurs ordinaires, les images météoroligiques sont
toujours difficile à comprendre puisqu’elles représentent beaucoup d’informations
spécialisées.
D’ailleurs, en ce qui concerne la météo, la question posée est toujours plus simple
comme « est-ce qu’il fera beau demain ? Demain, il fera chaud ou non ? Quelle est
la température aujourd’hui ? ». Alors, mon mémoire de fin d’étude se compose
d’une partie importante qui a pour but de montrer une solution acceptable pour
exploiter les résultats de prévision du modèle WRF de façon facile chez les
utilisateurs ordinaires.



2. Structure du Système

Figure IV-2 Structure du système déployé au Centre HPC

Comme montré sur la figure, le système que j’ai déjà bâti se compose des
composants ci-dessous :
• Modèle WRF executé sur la grappe bkluster, qui joue le rôle de produire les
données météorologiques pour le système.
• Le programme qui contrôle le modèle WRF pour l’exécuter automatiquement
jour après jour. Dans la situation actuelle, le modèle WRF est exécuté une
fois par jour à 23 heures trente, comme la ligne de connection à l’Internet et
les ressources de calcul n’étaient pas suffisantes au centre HPC.
• Un module de traitement des données sorties du modèle pour relever les
champs météorologiques fondamentaux de toutes les villes vietnamiennes et
les insérer à la base de données. Ce module est programmé en utilisant le
langage NCL et le langage JAVA.
• Le module MeteoAPI a pour but de donner l’interface de
programmation(API) qui se situe entre la base de données et les applications
de représentation (le portail d’information de météo, le google
gadget IPHmétéo). Utiliser le module MeteoAPI est le mieux pour séparer le
structure de la base de données avec les applications de représentation.
D’ailleurs, les google gadgets n’étaient pas capables de se connecter
directement à la base de données.
• Les applications de représentation : Ceux-ci peuvent être de n’import quel
logiciel qui permet de publier les bulletins de météo en utilisant les données
fournies par MeteoAPI. J’ai choisi de créer le Google gadget IPHmétéo
puisqu’il pourrait avoir des avantages par rapport aux autres, selon moi.


Application du modèle de prévision météorologique WRF au Vietnam

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Application du modèle de prévision météorologique WRF au Vietnam

Ähnlich wie Application du modèle de prévision météorologique WRF au Vietnam (20)

Mehr von Viet-Trung TRAN

Mehr von Viet-Trung TRAN (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (19)

Application du modèle de prévision météorologique WRF au Vietnam