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

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

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



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

WRF-VAR

Données observées, reanalyses, du

modèle global ...

Système de post-traitement du WRF, outil

graphique

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 :



Données géographiques

statiques

Données du modèle global

(NAM,GPS,RUC,NNRP)

WPS

WRF-Var

OUTPUT

NCAR graphics NCL

RIP4

ARWpost(GRADS/Vis5D)

Ideal 3D supercell

Ideal 2D hill

Ideal 2D Squall line

Ideal 3D baroclinic

Waves

Ideal 2D grav

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 3D supercell

Ideal 2D hill

Ideal 2D Squall line

Ideal 3D baroclinic

Waves

Ideal 2D grav

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

Donées du modèle global

(NAM,GPS,RUC,NNRP)

WPS

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.

0

50

100

150

200

250

300

Bkluster IBM eserver 1350 IBM eserver 1600

Performance de calcul

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, map_proj = 'lambert', 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, map_proj = 'lambert', 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).



117

108

50

60

70

80

90

100

110

120

pgi 7.0 Intel 10.1.015

Mode séquentiel

Mode séquentiel

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.

78

5760

49

0

10

20

30

40

50

60

70

80

90

2processeurs/2noeuds 2processeurs/1noeuds

mpich1.2.7p1

mpich2‐1.0.3

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.



56

72

0

20

40

60

80

Bkluster / 4 processeurs

IBM AIX 1350 / 4 processeurs

Temps moyen

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

NCL script

Fichier au format netCDF

Image météorologique

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.



Selon les recommandations de mes professeurs, cette structure était bien acceptable puisqu’il pourra montrer la solidarité durable et aussi l’indépendance entre les modules du système. Surtout chez le module MétéoAPI, son rôle était plus important pour donner la flexibilité.

2.1. Module de contrôle automatique du modèle WRF Le rôle de ce module était le plus important puisque le modèle WRF fournit les données de prévision afin que le système puisse marcher bien automatiquement jour après jour. De plus, les configurations du modèle WRF ne peuvent pas être fixées, elles changent chaque fois. Cela perd beaucoup de temps et provoque quelques fois des erreurs.

C'est pourquoi l'automatisation du système est un problème. La solution est donc l'utilisation des shell-scripts sous le système d'exploitation Linux.

Le module de contrôle automatique du modèle se compose essentielement de cinq shell-scripts. Chaque shell-script est le responsable d’une mission précise. Parmi lesquels « Maître_de_contrôle.sh » joue le rôle de contrôler et de gérer la gestion les autres. Il transforme tous les paramètres nécessaires pour le fonctionnement du système au reste.

Figure IV-3 Automatisation du modèle WRF

Les missions sont :

• Télécharger les analyses d’entrées du modèle global AVN

• Configurer les paramètres du module WPS dans le fichier namelist.wps

• Exécuter le programme ungrib.exe



• Exécuter le programme metgrid.exe

• Configurer les paramètres du module WRF dans le fichier namelist.wps

• Exécuter le programme real.exe

• Exécuter le programme wrf.exe

• Exécuter le script NCL pour traiter les donnée de sorties du modèle

J’utilise le programme crontab sous Linux pour pouvoir faire marcher automatiquement les shell-script à intervalle régulier.

Quotidiennement, crontab appelle « Maître_de_contrôle.sh », à son tour « Maître_de_contrôle.sh » exécute alternativement les shells:

Télécharger_les_données.sh

Ce shell est responsable du téléchargement des données d'entrée. Il utilise la commande « wget » pour fonctionner. Pour la prévision maximale de 72 heures, l'intervalle entre les prévisions est de 3 heures, les fichiers suivants doivent être bien téléchargé :

-rw-r--r-- 1 trungtvk48 trungtvk48 14252902 May 7 23:49 gfs.t12z.pgrbf00.grib2 -rw-r--r-- 1 trungtvk48 trungtvk48 16001004 May 7 23:49 gfs.t12z.pgrbf03.grib2 À … -rw-r--r-- 1 trungtvk48 trungtvk48 15912156 May 7 23:49 gfs.t12z.pgrbf69.grib2 -rw-r--r-- 1 trungtvk48 trungtvk48 15931227 May 7 23:50 gfs.t12z.pgrbf72.grib2

Les fichiers ont le format de nom de fichier comme :

gfs.t ??z.pgrbf ??.grib2

Par exemple « gfs.t12z.pgrbf69.grib2 » signifie des données de sorties du modèle global GFS/AVN avec le temps d’exécution de 12 heures (temp universel), prévision de 69 heures, au format grib2.

Exécuter_WPS.sh

Le shell-script a pour but d’exécuter les programmes du module WPS. Il fait tout d’abord configurer les paramètres qui varient chaque jour dans le fichier namelist.wps. Après les avoir bien configuré, le shell-script copie le fichier namelist.wps au répertoire $Domaine_à_calcul_ROOT et puis le programme ungrid.exe est exécuté.

On se souvient que la première étape d’exécution du programme geogrid.exe n’est pas nécessaire ici puisque le domaine de calcul était toujours le même. Si l’on définit un nouveau domaine, On aura besoin d’exécuter le programme geogrid.exe pour la première fois.



Comme le « ungrid.exe » n’est pas capable d’exécuter parallèlement, il ne faut pas utiliser les bibliothèques MPI. Mais pour le « metgrid.exe » C’est le contraire. L’exécution de « metgrid.exe » est commencée en appellant la commande suivante :

mpirun -np 2 -machinefile /home/trungtvk48/machines.LINUX ./metgrid.exe

Exécuter_WRF.sh

Les problèmes ci-dessous sont bien configurés pour exécuter deux programmes « real.exe » et « wrf.exe » :

• Déposer les fichiers temporaires de l’exécution précédente.

• Configurer le moment du commencement et celui de la fin des données d'entrées.

• Faire des liens des fichiers de sorties du WPS au répertoire où l’on fait exécuter le modèle au cas de données réelles.

• Commencer les démons sur les hôtes si l’on utilise la bibliothèque MPICH2 dans le fichier mpd.hosts

Exéculter_NCL.sh

Ce shell-script est le responsable de l’appel à des scripts NCL du répertoire « . /NCLscript » pour faire le post traitement des données de sortie du modèle.

Les deux scripts principaux qu’il faut appeler sont :

• Premièrement, le script pour extraire les données nécessaires afin que l’autre programme de JAVA puisse les insérer à la base de données.

• Deuxièmement, les scripts pour visualiser les résultats de prévision du modèle. Ils créent des images météorologiques afin que les chercheurs puisse observer les conditions météo actuelles.

2.2. Extraction de champs météorologiques par le script NCL

Pour extraire les champs météorologiques du source de fichier de sortie du modèle WRF, on a choisi de programmer un module en langage de script NCL. Je vais présenter le structure de ce programme.

Les étapes principales sont :

• Importer les bibliographies de programmation du WRF et ouvrir le fichier d’entrée au format NetCDF

• Déterminer le nombre de temps dans le fichier

• Retirer les champs météorologiques nécessaires

• Écrire les champs retirés au fichier de sortie



Figure IV-4 Les étapes principales du module d’extraction de champs météorologiques

On utilise l’instruction suivante pour importer les bibliothèques de programmation du NCL

load “le chemin à la bibliothèque”

Parmi les bibliothèques, « WRFUserARW.ncl » est toujours exigées pour traiter les fichiers de sortie du modèle WRF.

La variable « ntimes » représente le nombre de prévison du temps fournie par le modèle WRF. Dans le contexte de prévision de trois jours au Vietnam, l’intervalle : 3 heures, la variable « ntimes » a toujours la valeur de 25 (1 + 3*24/ 3)

Pour retirer les champs météorologiques, l’instruction « wrf_user_getvar » est nécessaire : il a pour but d’extraire des données du fichier au format netCDF.

Diagnostics disponibles par « wrf_user_getvar » :

• pressure : pression complète du modèle [hPa]

• rh : Humidité relative [%]



• slp : pression de niveau marine [hPa]

• td2 : température du point de rosée de 2 m [C]

• td : température du point de rosée [C]

• tc : Température [C]

• th : température potentielle [K]

• tk : Température [K]

• ua : La composante U de vent

• va : La composante V de vent

• wa : La composante W de vent

• uvmet : U et V de vent tournés à la coordonnée du terre

• z: Altitude complète [m]

On peut egalement extraire directement les champs en utilisant l’instruction suivante :

Valeur = fichier d’entrée ->le_nom_de_la-variable( coordonnée h,x,y)

Cette commande était très utile pour les variables qui ne sont pas disponibles pour « wrf_user_getvar ».

2.3. Mise en carte de la structure de la base de données.

Cette structure de la base de données est designée essentiellement afin de pouvoir relever les informations fondamentales de météo de chaque zone au Vietnam aux quelles peuvent correspondre les champs météorologiques de chaque position de la terre( latitude, longitude) extraits du temps des données de sortie du modèle WRF.

Figure IV-5 Le structure de la base de données



Dans le contexte de mon mémoire, je ne me concentre que sur la création des tables concernant le but de stocker des informations de prévisions météorologiques des villes au Vietnam. Les autres tables qui intéressent le portail d’information de météo ne sont pas présentées ici. Ce sont les travaux des autres membres de mon équipe.

Pour que l’on puisse présenter les résultats de prévision en trois langues internationales, Chaque ville ou chaque district est nomé en trois langues Vietnamien, anglais, français correspondant à trois attributs de la table tb_villes ou tb_districts de la base de données.

2.4. MétéoAPI Une part, le module MétéoAPI fournit les données de villes, de districts, d’informations météorologiques au format XML(langage de balisage extensible) en trois langues Vietnamien, anglais et français au google gadget IPHmétéo ou autre application de représentation.

D’autre part, ce module joue un rôle important pour determiner la condition générale de météo en coordonnant les composants météorologiques fondamentaux extraits. Pour bien réussir cette fonction, On a besoin tout d’abord de connaître les terminologies météorologiques, ci-après sont présentées les terminologies météorologiques documentaires du Centre de Météo (CM), Université nationale de Hanoi :

Terminologie météorologique.

CONDITION DE CIEL

Décrit la condition de ciel prédominante/moyenne basée sur dixièmes du ciel couvert par les nuages.

Condition de Ciel Couverture de Nuage

Nuageux 8/8 Nuages

Surtout Nuageux/ Nébulosité Considérable 6/8 à 7/8

Partiellement Nuageux/Partiellement Ensoleillé

3/8 à 5/8

Presque Clair/Presque Ensoleillé 1/8 à 2/8

Clair/Ensoleillé 0/8

Vent

Terminologie Vitesse du Vent

Direction La direction de vent est donnée comme celle dans laquelle le vent souffle.



Vent doux 0-20 mph

Venteux 20 -30 mph

Très Venteux 30-40 mph

Vent fort 40-73 Ph

Force d'Ouragan > 74 mph

Précipitations

Terminologie Précipitation Bruine 1-15 mm/jour La Pluie modérée 16-50 mm/jour La Forte Pluie > 50 mm/jour

Humidité

Terminologie Humidité Sec 0-30% Normal 30-70% Humide 70-100%

Température

Terminologie Température Très Chaud > 37° Chaud 30°-37° Tiède 24°-30° Léger 21°-24° Froid 18°-21° Très Froid 15°-18° Extrémement Froid < 15°



Comment le MétéoAPI fonctionne-t-il ?

7 - XMLHttpResponse

1 - XMLHttpRequest

4

Gadget IPHmétéo

Horloge

rafraîchir

Gadget IPHmétéo

8 – mettre à jour

2

Base de données

MétéoAPIRetenir les données

Déterminer la condition

météorologiqueProduire XML

réponse3

5

6

Http://www.hpcc.hut.edu.vn/meteo_api/

Figure IV-6 Processus de traitement d’une demande par MeteoAPI

Cette figure montre le processus de mise à jour du contenu de google gadget IPHmétéo. Tout d’abord, le gadget envoie une demande XMLHttpRequest après avoir reçu un signal d’horloge automatiquement ou si l’utilisateur le fait rafraîchir.

Le module MétéoAPI qui reçoit cette demande, il fait les trois tâches ci-dessous :

• Se connecter à la base de données pour retenir les données correspondantes. Il faut d’utiliser quatres paramètres (les clés primaires) pour déterminier un ensemble de données de la table tt_prévision. Ces clés primaires sont le jour, l’heure, la latitude et la longitude.

• Déterminer les conditions météorologiques en considération du tableau des terminologies météorologiques. Alors, la valeur du champ de température, de précipitation ou de couverage de nuage …qui est retenue de la base de données déterminera les conditions générales de la météo.

• Selon la langue demandée, le module MétéoAPI produit la réponse au format XML correspondant et puis le renvoie au client.

<?xml version="1.0" encoding="UTF-8" ?> - <weather>

- <forecast_information> <city data="Hanoi" /> <district data="Ba Dinh" /> <latitude data="21.034" />



<longitude data="105.837" /> <forecast_date data="2008-05-28" /> <forecast_time data="22" />

</forecast_information> - <current_conditions>

<condition data="Partiellement Nuageux" /> <temp_f data="" /> <temp_c data="29" /> <imgSun data="" /> <imgMoon data="28.png" /> <imgCloud data="Partly_Cloudy.png" /> <humidity data="82%" /> <wind_condition data="Ouest : 2 m/s" />

</current_conditions> - <forecast_conditions>

<day_of_week data="MER" /> <low data="28" /> <high data="36" /> <condition data="Partiellement Nuageux" /> <imgSun data="Sunny.png" /> <imgMoon data="" /> <imgCloud data="Partly_Cloudy.png" />

</forecast_conditions> - <forecast_conditions>

<day_of_week data="JEU" /> <low data="27" /> <high data="35" /> <condition data="Partiellement Nuageux" /> <imgSun data="Sunny.png" /> <imgMoon data="" /> <imgCloud data="Partly_Cloudy.png" />

</forecast_conditions> - <forecast_conditions>

<day_of_week data="VAN" /> <low data="26" /> <high data="33" /> <condition data="Pluie Modérée" /> <imgSun data="Sunny.png" /> <imgMoon data="" /> <imgCloud data="Moderate_Rain.png" />

</forecast_conditions> </weather>

Il y a trois parties principales d’une réponse au format XML. La première partie est de donner les informations sur le lieu où l’on fait la prévision : Ville, District, latitude, longitude, date et heure de prévision.



La deuxième partie concerne les conditions météorologiques au moment actuel. Les informations se composent de la description de la condition actuelle, la température, des images représentant la condition actuelle, l’humidité et les conditions du vent.

La dernière partie concerne les conditions météorologiques des jours après comme le lendemain, le surlendemain… évidemment, les informations sont très utiles pour les utilisateurs qui ont besoin de connaître les prévisions de la météo.

L’interface de programmation (API) du MétéoAPI.

Retenir la liste de villes pour les quelles on rédige le bulletin de météo

http://www.hpcc.hut.edu.vn/meteo_api/iph_cities.jsp?langue=VN

Paramètre Valeur Signification langue VN Vietnamien EN Anglais FR Français

Retenir la liste de districts d’une ville

http://www.hpcc.hut.edu.vn/meteo_api/iph_districts.jsp?langue=VN&iso_code=12

Paramètre Valeur Signification langue VN Vietnamien EN Anglais FR Français Iso_code Nombre entier Code de la ville

http://www.hpcc.hut.edu.vn/meteo_api/iph_weather.jsp?langue=VN&latitude=25.456&longitude=105.230

Paramètre Valeur Signification langue VN Vietnamien EN Anglais FR Français latitude Valeur réelle Latitude d’une position Longitude Valeur réelle Longitude d’une position

2.5. Gadget IPHmétéo sur Google Desktop Les gadgets de bureau sont des mini-applications interactives qui peuvent être placées n'importe où sur le bureau de l'utilisateur - ou mises à quai dans le Sidebar - pour montrer le nouveau courrier électronique, le temps, la météo, les photos et les nouvelles personnalisées.



Il leur faut utiliser seulement une petite ressource spatiale de bureau et une petite ressource informatique, comme le HDD et la RAM. Leur but est de fournir des informations pertinentes à l'utilisateur d‘une manière indiscrète. Fondamentalement, les gadgets de bureau permettent la vue d'utilisateur sur demande, et retienent les informations des sources de données prédéterminées. Idéalement, un gadget de bureau doit présenter le contenu personnalisé, basé sur les préférences de l'utilisateur. Il doit se concentrer sur les informations les plus importantes qu'un utilisateur exige sur une base journalière. D’ailleurs, la plupart des gadgets de bureau sont disponibles téléchargement gratuit.

À partir d’une demande d’amener les résultats des prévisions météorologiques du modèle WRF plus proches chez les utilisateurs, J’ai le grand plaisir de développer un gadget, précieusement, Ce sera un gadget de Google Desktop. Parmi les autres moteurs de gadget, Google Desktop procure des avantages suivants :

• Une grande communauté des développeurs grâce à laquelle je peux bénéficier des aides des personnes expérimentés.

• Le moteur Google Desktop Sidebar est accompagné par défault d’un produit Google Desktop Search qui était populaire dans le domaine de recherche sur le bureau de l’utilisateur. C’est la raison pour laquelle les gadgets de Google sont bien utilisés. D’ailleurs, Google offre une galerie de gadgets pour faire de la publicité des gadgets sur le site Internet officiel.

• Pour les développeurs, Google offre un kit de développement (SDK) et un blog officiel pour quiconque veut écrire des gadgets pour le Google Desktop. Ceci est bien utile et pratique.



Structure de l’IPHmétéo

Figure IV-7 IPHMétéo

Les gadgets de Google sont développés en utilisant XML (langage de balisage extensible) et Javascript. Les fichiers XML jouent le rôle de définir l'aspect du gadget et de spécifier quelle fonction mene les actions concrètes chez les utlisateurs comme : le fait de cliquer sur un bouton, le fait de taper sur le clavier… D’autre part, Les instructions et les classes, les fonctions qui font l’exécution d’un gadget sont rédigé en langage Javascript dans des fichiers *.js.

Ci-après le structure du gadget IPHmétéo :

Nom de fichier Sorte Description

en/strings.xml XML Définit des chaînes utilisées par le défaut, dans la version anglaise de ce gadget.

fr/strings.xml XML Pour la version française de ce gadget.

vn/strings.xml XML Pour la version vietnamienne de ce gadget.

gadget.gmanifest Le fichier de manifeste

Spécifie les métadonnées du gadget, comme la carte d'identité ID, version, version de Desktop de Google minimale, nom et description.

main.js Javascript Garde les codes du programme principal qui est responsable de la présentation des données.



main.xml XML Définit l’aspect du gadget

Options.xml XML Définit l’aspect de la boîte à option.

Options.js Javascript Manipule les fonctions de la boîte à option.

Weather.js Javascript Responsable de télécharger et traiter les données de météo.

City.js Javascript Responsable de télécharger la liste des villes pour lesquelles on a les données de prévision.

Images/ image Des images pour le gadget

Tableau IV-1 Structure de l’IPHmétéo

IPHmétéo utilise Google API pour bâtir sa fonction.

Caractéristiques de l’IPHmétéo

IPHmétéo supporte tous les trois états d’affichage d’un gadget de bureau. Il est capable de régler son UI (Interface de l’utilisateur) à son état d’affichage actuel. Son UI change au cas correspondant à l’extérieur du volet (non mis à quai), à l’intérieur du volet (mis à quai). Il peut également être minimisé pour conserver l'espace.

Figure IV-8 Les trois états d’affichage de l’IPHmétéo

En se coordonnant avec le module MétéoAPI, IPHmétéo peut supporter trois langues : Français, Vietnamien et Anglais. Les utilisateurs peuvent choisir une des trois langues que le gadget utilise pour afficher les informations. Au contraire, par défaut, la langue de système sera utilisé par IPHmétéo :



try {

Gadget_language = system.languageCode();

} catch (e) {

Gadget_language = strings.DEFAULT_LANGUAGE;

}

Figure IV-9 IPHmétéo en version Français, Anglais et Vietnamien

Avec les données fournies par MétéoAPI, le gadget peut afficher graphiquement les informations météorologiques ci-après :

• La prévision des conditions météorologiques actuelles : La condition de ciel en image, la conditon de ciel en texte, la température actuelle et la caractéristique du vent.

• La prévision des conditions météorologiques à trois jours : La condition de ciel en image, la température maximale et la température minimale du jour.

Comment bénéficier la fonction de l’IPHmétéo ?

Acctuellement, le gadget IPHmétéo est bien mis sur la galerie de Google après que les responsables ont fait les examens pour le vérifier pendant environ une semaine. À partir du 10 mai cette année, les utilisateurs peuvent le télécharger sur le site :

http://desktop.google.com/plugins/i/ihpmeteo_7250.html?hl=en

Google le présente également aux utilisateurs sur la galerie sur bureau. Je souhaite bien que l’IPHmétéo, avec la présentation de Google, sera utilisé par un grand nombre de personnes au Vietnam.



Figure IV-10 IPHmétéo sur la galerie de Google

Les évaluations au début

Dès la publication de l’IPHmétéo, le gadget a attiré l’intention des utilisateurs de Google Desktop. Il a bien joué le rôle de représenter les bulletins de météo des régions au Vietnam. Ci-après je voudrais bien montrer un exemple intéressant du bulletin de météo à 08 :00’ le 28 mai 2008.

Figure IV-11 Prévision météorologique à 08 : 00’ le 28 mai 2008



Il me semble bon puisque les informations météorologiques étaient prèsque similaires entre IPHmétéo, Yahoo weather et www.weather.com. En effet, Google weather n’était pas exact à la condition de ciel.

3. Conclusion Un système presque professionnel de prévision météorologique a été bien contruit au centre HPC afin de fournir quotidiennement les bulletins de météo chez les utilisateurs ordinaires au Vietnam. En effet, le système a bien fonctionné automatiquement depuis le début de mai 2008. Grâce à l’IPHmétéo, les utilisateurs accédéderont facilement aux prévisions de sortie du modèle WRF. Ce-ci est une partie importante de mon mémoire.



Conclusion Dans mon mémoire de fin d’études, je me suis efforcé de fournir un panorama du modèle de prévision météorologique WRF, et puis d’établir le modèle WRF sur l’environnement de calcul à haute performance : Bkluster, IBM eserver 1350 et IBM AIX eserver 1600. Mon étude se concentre également sur une partie importante du déployement d’un système professionnel qui fournit directement les bulletins de météo chez les utilisateurs ordinaires.

Avec le système professionnel déployé, les données de prévision pour environ 700 points au Vietnam sont insérés quotidienement à la base de données. Ceci signifie que la même quantité de régions a ses propres prévisions. C’est énorme en considération de la dizaine de points que les autres systèmes (weather.com, Yahoo weather, Google weather…) fournissent pour Vietnam.

Pourtant, le travail d’insérer les informations administratives de 700 points n’est pas fini, faute de temps. Ce problème sera surmonlé dans l’avenir proche.

Comme les données d’observation ne sont pas disponibles, le système n’a pas le module WRF-VAR qui joue le rôle d’assimiler les données, et qui peut améliorer le résultat de prévision du modèle. En suite, le système profite seulement de certains modes d’opération qui sont supportés par le modèle. Le fonctionnement du système dépend complètement des sources de données du site NCEP qui ne marche pas toujours bien.

La fonction de l’IPHmétéo reste encore simple, parfois il a des erreurs. Je vais donc en priorité le développer.

En conclusion, les expériences obtenues me permettent de renforcer mes connaissances du calcul à haute performance, en particulier de l’IBM AIX eserver 1600 : le système le plus fort au Vietnam. J’ai accquis des compétences de recherche, de synthèse des documents et d’établissement d’un système d’information avec quels j’ai une ferme confience pour mon chemin professionnel.



Références

[1]. http://fr.wikipedia.org/wiki/Prévision_numérique_du_temps [2]. Page d'accueil du WRF, http://www.wrf-model.org [3]. Page d'accueil du graphique NCAR: http://ngwww.ucar.edu/ [4]. Page http://www.mmm.ucar.edu/mm5/WRF_post/RIP4.htm [5]. Page http://www.iges.org/grads/ [6]. Page http://www.unidata.ucar.edu/software/netcdf/ [7]. Page http://en.wikipedia.org/wiki/MPICH [8]. Page http://en.wikipedia.org/wiki/GRIB [9]. Page http://fr.wikipedia.org/wiki/Widget_de_bureau « Quản trị hệ thống Linux » - NGUYEN Thanh Thuy « IBM eServer pSeries Cluster Systems Handbook » - Mukesh Kumar Gupta, Edward EuiJoo Lee, See Poo Soh. « IBM Cluster 1600 Managed by PSSP 3.5 » - Dino Quintero, Bernhard Buehler, Peter Custerson. « Cluster Systems Management Cookbook for pSeries » - Dino Quintero, Thomas Braunbeck, Ong Swee Thye. « XL Fortran for AIX® » « IBM System Cluster 1350 Facts and Features » « User’s Guide for Advanced Research WRF (ARW) » - Wei Wang, Dale Barker, John Bray « A Description of the Advanced Research WRF Version 2 » - William C. Skamarock, Joseph B. Klemp, Jimy Dudhia, David O. Gill « Recherche et déploiement du modèle de prévision météorologique MM5 » - PHUNG Thanh Dat Site http://code.google.com/support/bin/topic.py?topic=11366 Site http://code.google.com/apis/desktop/docs/gadget_apiref.html Site http://tornado.meso.com/wrf_forum/



Annexe

Félicitations de l'Équipe Google

From: Google Help [mailto:desktop‐[email protected]] Sent: Saturday, May 10, 2008 6:46 AM To: Tran Viet Trung Subject: Re: [#271117544] [PL] Plugin submission: IHP meteo

Congratulations! We're happy to let you know that we've approved your gadget for the Google Desktop Gadget program. In one to two weeks, your gadget should appear on the Download Gadgets page. Once your gadget is live, you can find it by selecting the appropriate category from the links on the left side of the page and scrolling down to your listing.

In celebration of your gadget, we'd like to send you a developer appreciation package. Your coupon code is 177015. To obtain your package, please contact the Google Store by phone at 1‐866‐746‐6453 or by email at [email protected] and provide your coupon code and shipping address.

To update your gadget, simply upload the new version to the URL listed on the gadget's Google Desktop Gadget page. Additionally, you can update the information displayed on the download page by modifying the metadata in your gadget's gmanifest file. We'll periodically download and scan your gmanifest files to update your gadget's information. If your updated information doesn't appear within two weeks, please let us know. For a refresher on the gmanifest file, visit http://desktop.google.com/dev/script.html#gmanifest

Lastly, if you change your download URL or your gadget's screenshots, please reply to this email to let us know.

Regards,

The Google Team

Original Message Follows:

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

From: Tran Viet Trung <[email protected]>

Subject: [PL] Plugin submission: IHP meteo

Date: Tue, 29 Apr 2008 00:59:18 ‐0700 (PDT)

x‐trak‐submit_language: en

x‐trak‐extra_issue:

Receive Email:true

Name:IHP meteo

Description:representation de l'information meteologique en utilisant le model WRF Type:SIDEBAR Platform:[WIN, MAC] Download Url:http://hpcc.hut.edu.vn/~trungtvk48/IHPmeteo.gg



Screenshot:http://hpcc.hut.edu.vn/~trungtvk48/big.gif

Thumbnail:http://hpcc.hut.edu.vn/~trungtvk48/small.gif

Education

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