V - 2.1. Principe de fonctionnement du scénario de prévision
Comme cela a été décrit dans le chapitres 2 et 4, l’intérêt d’utiliser la grille dans cette étude réside initialement dans sa capacité à déporter des calculs susceptibles de surcharger les capacités informatiques du système d’information du SPC-GD (cf. §.III – 1.2.41). La méthodologie qui a émergé de l’analyse du chapitre 4 consiste donc à l’exécution d’un ensemble8 de scénarios de prévisions de
manière simultanée sur les nœuds de calcul de la grille. Par conséquence, un scénario de prévision correspondra à un job de grille.
D’un point de vue fonctionnel, l’analyse d’ALHTAÏR a permis d’identifier une indépendance entre les cellules du bassin versant mais une dépendance temporelle entre les instances de simulation successives (cf. §.III – 1.2.4.2). Si, en début d’évènement, les conditions hydrologiques du bassin versant sont considérées comme nulles (modèle hydrologique évènementiel), ses conditions assurent ensuite le « lien hydrologique » entre deux pas de temps successifs. Ainsi, pour permettre ce lien, entre la fonction « temps-réel » assurée par l’application ALHTAÏR existante et la version « prévision » portée sur la grille, il a été nécessaire d’enregistrer les conditions hydrologiques et l’hydrogramme à chaque pas de temps, de manière à permettre leur transfert et leur prise en charge ultérieure et à distance par le scénario de prévision. Ainsi, à chaque fois que le prévisionniste désire exécuter un scénario de prévision, le système d’aide à la décision doit récupérer les dernières conditions hydrologiques et l’hydrogramme du bassin versant, modélisées grâce à la version « temps réel » pour l’utiliser lors de l’exécution du scénario de prévision sur la grille (Figure 65).
Afin de pouvoir modéliser un scénario de prévision sur la grille EGGE, les fichiers transférés au nœud de calcul (InputSandbox) correspondent aux :
- bassin versant à modéliser
- conditions hydrologiques « temps réel » - l’hydrogramme « temps réel »
- la prévision de pluie CALAMAR
- le proxy créé grâce au certificat personnel
- les algorithmes d’ALHTAÏR et les librairies spécifiques
8 Le terme de « simulation » est réservé dans la suite de ce mémoire pour évoquer cet ensemble de scénarios
Figure 65 : Synopsis du traitement d'un scénario de prévision
Une fois que le prévisionniste soumet ce scénario les services de gestion de tâches de gLite se charge de soumettre le job correspondant à un élément de calcul disponible, qui, une fois l’exécution terminée retourne les nouvelles conditions hydrologiques et l’hydrogramme de prévision sur l’interface utilisateur et/ou les dépose sur un élément de stockage.
Il convient de détailler la méthodologie qui a permis d’une part l’exécution des algorithmes des modules de production et de transfert du modèle ALHTAÏR et d’autre part la gestion des données entre ces modules, et leur échange entre le système local et les ressources de la grille. Ces développements ont été menés depuis une interface utilisateur9 installée dans les locaux de l’IPGP10 à Paris, appartenant à
l’organisation virtuelle ESR11, constituant une des VO de la grille EGEE.
9 Moyen par défaut d’accès aux ressources de grille (détaillée dans ce chapitre) 10 Institut de physique du globe de Paris
11 Earth Science Research.
V - 2.2. Stratégie de portage
V
V- 2.2.1. Recodage des algorithmes- 2.2.1. Recodage des algorithmes
La première étape de développement concerne la grillification des modules hydrologiques de l’application ALHTAÏR. Initialement développée sous WINDEV©, langage exclusivement réservé au
système d’exploitation WINDOWS©, ces modules ont du être recodés avec un langage exécutable sur
un environnement Linux.
Sur les nœuds de calcul de la grille EGEE, il existe majoritairement 4 langages de programmation12 :
- JAVA13
- C14
- C++ - Python15
Il ne s’agit pas dans ce développement de discuter l’intérêt de chacun de ces langages. Dans le cadre de cette méthodologie, le langage de script Python a été choisi pour sa facilité d’utilisation, sa légèreté et sa modularité. En tant que langage interprété, il ne nécessite pas de compilation préalable du programme. D’autre part, il s’agit d’un langage de haut niveau, ne nécessitant pas la déclaration des variables. Malgré une certaine lenteur d’exécution, en comparaison avec les langages C et C++, sa rapidité de développement et la possibilité de développer une approche objet en fait un langage adapté à la problématique de cette recherche (PRECHELT, 2000).
Après l’analyse du code de l’application WINDEV©, un diagramme de classes UML a été créé pour
faciliter le recodage de l’application (Figure 66). Les éléments essentiels de la modélisation sont les caractéristiques du bassin versant et de l’image radar qui permettent de calculer le ruissellement de surface pour chaque cellule du bassin versant (production) et de construire l’hydrogramme à l’exutoire de ce dernier (transfert). Au préalable, les correspondances géographiques sont établies entre les cellules (au sens de pixel) du bassin versant et celles de l’image radar, c'est-à-dire qu’à une cellule de bassin versant correspond une cellule radar.
12 Ces langages font partie des paquets officiels de la distribution Scientific Linux 13 http://www.java.com/fr/
14 http://gcc.gnu.org/ 15 http://www.python.org/
Figure 66 : Diagramme de classes des modules hydrologiques d'ALHTAÏR
La gestion de ces matrices est permise par le module externe NumPy16 capable d’interagir avec les
fonctions standards de Python. Finalement, la séquence de traitement du cœur de l’application ALHTAÏR décrit dans le chapitre 2 (cf. §.III – 1.2.4.2 : Fig. 43), correspondant aux modules de production et de transfert, n’a pas été modifiée, seule la structure, le format et l’accès aux données ont été adaptés notamment dans l’optique de l’utilisation des services web de l’OGC.
V
V- 2.2.2. Formatage des données- 2.2.2. Formatage des données
La seconde étape de la reconstruction des algorithmes fonctionnels d’ALHTAÏR concerne le formatage des données. Le format sélectionné est le NetCDF17 (Network Common Data Form). Ce format de
données permet la gestion efficace de données spatiotemporelles et multidimensionnelles. Il est basé sur des :
- dimensions,
- variables basées sur une ou plusieurs dimensions, - attributs.
Un tel format permet de prendre en charge un grand nombre de données, dont celles issues du monitoring de l’environnement. L’intérêt principal est de pouvoir stocker un nombre important de matrices dans un seul fichier afin de réduire la multiplication des fichiers de stockage. Un ensemble de métadonnées, décrites grâce au langage CDL (Common Data Language) et basées sur la convention CF (Climate Forecast) (EATON et al., 2009) (Figure 67), est établi pour décrire et documenter les
données stockées et recoder les données utilisées dans ALTHAÏR de manière standard. Le recodage des données relatives à ALHTAÏR concerne :
- le bassin versant composé de 8 variables principales : o les limites du bassin versant
16 http://numpy.scipy.org/
17 http://www.unidata.ucar.edu/software/netcdf/
o les temps de transfert de chaque cellule du bassin versant o les 6 paramètres spatialisés d’ALHTAÏR (AYRAL, 2005)
o et les variables relatives au positionnement géographique des cellules - la pluie issue des images radar composée d’une variable principale
o la pluie brute spatialisée
o et les variables relatives au positionnement géographique des cellules - les conditions hydrologiques du bassin versant composées des situations :
o d’infiltration o d’imbibition o de ruissellement
o d’écoulement hypodermique
- le ou les hydrogrammes de chaque bassin versant
{
dimensions:
time = UNLIMITED ; // (496 currently) x = 50 ; y = 50 ; variables: int Lambert_Conformal ; :grid_mapping_name = "lambert_conformal_conic" ; :…
double rainfall(time=496, y=50, x=50) ; :units = "mm/h" ;
:long_name = "Rainfall intensity" ; :coordinates = "lat lon" ;
:grid_mapping = "Lambert_Conformal" ;
:_CoordinateSystems = "ProjectionCoordinateSystem LatLonCoordinateSystem" ; …
double time(time=496) ; :long_name = "rainfall time" ; :standard_name = "time" ;
:units = "seconds since 1970-01-01 02:00:00" ; :axis = "T" ;
:_CoordinateAxisType = "Time" ; :bounds = "time_bnds" ; …
float lat(x=50, y=50) ; :units = "degrees_north" ;
:long_name = "latitude coordinate" ; :standard_name = "latitude" ; :_CoordinateAxisType = "Lat" ; float lon(x=50, y=50) ;
:… }
Figure 67 : Extrait de la description CDL d'une donnée de pluie CALAMAR, basée sur la convention CF
Grâce au format NetCDF, il est possible de mieux prendre en charge la dimension temporelle des données, essentielle dans le cas de la modélisation hydrologique. Il est donc possible de représenter l’ensemble d’un évènement hydrométéorologique au travers d’un seul fichier NetCDF. A noter que ce format est accessible par le module externe Scientific Python18 permettant de construire, lire et modifier
18 http://dirac.cnrs-orleans.fr/plone/software/scientificpython
ce type de données. L’intérêt du NetCDF réside dans sa capacité à intégrer des données multidimensionnelles de sources différentes permettant ainsi un accès facilité à des sous-ensembles par l’interrogation du fichier. Dans ce contexte, la motivation principale dans l’utilisation du NetCDF concerne sa prise en compte par l’OGC, et son rapprochement avec le service dédié à la gestion des couvertures géographiques (WCS) (DOMENICO et NATIVI, 2009). En effet, par sa capacité à s’auto-
décrire, un service web peut l’interroger et accéder au sous-ensemble requis par un utilisateur ou un autre service. De plus, les efforts de développement sur le NetCDF et les différentes librairies qui le supportent, s’orientent vers une meilleure capacité à paralléliser leurs traitements (HARTNETT, 2009).
Finalement, le format NcML, qui est une représentation XML du NetCDF, a été utilisé pour coder les hydrogrammes des scénarios de prévision. Par sa capacité à décrire formellement les données et les métadonnées contenues dans un fichier NetCDF, il tend à améliorer l’interopérabilité dans les échanges de données. Son extension NcML-GML permet par exemple son intégration dans des logiciels SIG et sa meilleure prise en compte pour l’approche SOA (NATIVI et al., 2005).
L’implémentation de cette nouvelle version des modules de production et de transfert de l’application ALHTAÏR, grâce au langage python et au format de données NetCDF, peut être caractérisée par les indicateurs du Tableau 5.
Données / algorithmes Caractéristiques informatiques
Bassin versant de 2 MB à 20 MB (19 MB pour 545 km2)
Radar 454,3 KB (1h) et 3 MB (8h)
Conditions hydrologiques 14,6 MB (5 mn) et 13,2 GB (100h)
Hydrogramme 4,7 KB (NcML) et 3,8 KB (NetCDF)
Algorithmes et librairies 3,7 MB
Tableau 5 : Caractéristiques techniques des données et algorithmes après grillification
À la vue de ces caractéristiques, et étant donné les capacités technologiques de la grille EGEE l’ensemble de ces contraintes de traitement apparait relativement faible. Cependant, chaque instance de modélisation impose la prise en charge de l’ensemble de ces données et l’actualisation des conditions hydrologiques, de l’image radar et de l’hydrogramme à chaque opération de prévision. Cette mise à jour, peut représenter une limite à la rapidité de traitement, en particulier dans le cas où le réseau informatique externe utilisé pour accéder aux ressources de grille a une bande passante de faible capacité.
V
V- 2.2.3. Simulation hydrologique sur la grille EGEE- 2.2.3. Simulation hydrologique sur la grille EGEE
L’utilisation la plus classique de la grille EGEE se fait au travers du protocole SSH (cf. §.V - 1.1). Un utilisateur reconnu par une organisation virtuelle d’EGEE, dans le cas de cette étude Earth Science
Research, c’est-à-dire disposant d’un certificat électronique se connecte à une des interfaces utilisateur
fournie par certains sites de la VO. L’interface utilisateur peut permettre de stocker des algorithmes, des données et des librairies, après accord avec l’administrateur de cette UI. A partir de cette UI, l’utilisateur peut avoir accès aux services de haut niveau de gLite pour effectuer des traitements sur les ressources de la grille.
Dans le cadre de cette étude, une instance de prévision est basée sur le job de grille décrit dans la Figure 68. Elle implique la présence, sur l’interface utilisateur, des fichiers contenus dans
InputSandbox, qui, avec ce script et le proxy de sécurité, composera le paquet du job.
Type = "Job" ;
JobType = "Normal" ;
Executable = "env python" ;
Arguments = "Alhtair.py" ;
InputSandbox = {"Alhtair.py","alhtair.tar.gz”,"bassin-versant.nc","conditions- initiales.nc","prévision-pluie.nc","hydrogramme-tps-reel.nc"} ;
StdOutput = "std.out" ;
StdError = "std.err" ;
OutputSandbox = {"std.out","std.err","hydrogramme.xml","post-conditions.nc", "logfile.log"} ;
Requirements = “other.GlueHostArchitecturePlatformType == "i686"” ;
Figure 68 : Job de grille (JDL) pour exécuter les modules hydrologiques d'ALHTAÏR
La chaîne de traitements classique lors de l’exécution d’un job est la suivante :
- l’utilisateur créé un proxy de sécurité grâce à ses certificats (voms-proxy-init) et son mot de passe,
- il soumet ce job à l’intergiciel (glite-wms-job-submit) qui sélectionne un WMS disponible pour traiter la requête,
- un WMS accepte le job et prépare le paquet pour sa soumission au CE sélectionné grâce à la contrainte exprimée par l’attribut Requirement (en l’occurrence une machine 32 bits),
- le CE réceptionne le job, le transmet à un des ses WN, et transfère les données d’entrée (InputSandbox),
- l’exécution débute sur le WN par la préparation des données19 et de l’environnement
d’exécution (librairies Scientific Python, Numpy et netcdf) puis lance les modules hydrologiques (Alhtair.py),
- l’exécution se termine en préservant uniquement les données de sortie qui sont soit récupérées par l’utilisateur à la fin du job (OutputSandbox) soit/et enregistrées sur un élément de stockage avec un enregistrement dans le LFC,
- l’utilisateur tenu informé tout au long du traitement du job (glite-wms-job-status), récupère les données de sortie sur son UI (glite-wms-job-output).
L’envoi de manière asynchrone de ce job au courtier de ressource provoque une série d’opérations au niveau de l’intergiciel transparents à l’utilisateur qui peut à tout moment se renseigner sur son état d’avancement. Une fois terminée, il est en charge de la récupération des résultats de la simulation.
19 À noter que des données déjà stockées sur des SEs peuvent être transférées sur le WN grâce aux fonctionnalités LCG
De prime abord, une telle architecture asynchrone permet de soumettre un nombre important de jobs en simultanée afin de répondre à un besoin ponctuel ou constant de ressources de calcul et/ou de stockage dans le cas d’une gestion intensive de données (réplication, échange, etc.), comme cette recherche le nécessite à travers la gestion d’ensembles de scénarios de prévision hydrologique. Dans une optique scientifique, visant à simuler différents scénarios, à traiter un jeu de données important, ou paralléliser des traitements intensifs20, l’intergiciel gLite et ses services offrent un ensemble de
commandes bash permettant de préparer les jobs, gérer des données sur SE, soumettre des jobs, suivre l’évolution de leur exécution, etc. Cependant, dans une optique opérationnelle, cette méthode de communication ne semble pas réellement approprier à :
- la compétence des prévisionnistes du SPC-GD
- la contrainte temporelle caractéristique d’une situation de crise
Ainsi, l’encapsulation de ces opérations de bas niveau par un composant logiciel capable d’interagir avec les services de gLite et le système d’information du SPC-GD se révèle nécessaire. Dans ce sens, la méthodologie de recours à une application web, tel qu’une interface de cartographie en ligne, connectée à des services web médiateurs doit être présentée.
20 Il s’agit d’embarrassingly parallel (aucun équivalent français trouvé) où l’effort de parallélisation (au sens de parallélisation
de contrôle) est limité voire inexistant
175
S
SYYNNTTHHEESSEE
Le premier niveau de cette phase d’implémentation, détaillé dans ce chapitre, consiste donc à adapter le code existant à un fonctionnement de grille. Il est question de la grillification ou du portage de l’application. Une fois autorisé par l’organisation virtuelle à laquelle il appartient, l’utilisateur (ou son système d’information) se connecte à cette interface utilisateur et envoi des requêtes asynchrones pour exécuter l’application grillifiée aux services de l’intergiciel de grille. La relative autonomie de ces services, détaillée dans la première partie de ce chapitre, facilite la prise en charge des opérations soumises par l’utilisateur.
L’application ALHTAÏR, et en particulier ses modules de modélisation hydrologique, a donc été grillifiée sur les ressources de l’organisation virtuelle ESR. Un recodage de ces algorithmes a été nécessaire et une adaptation de la gestion des données d’entrée et de sortie a été menée pour faciliter la reproductibilité des traitements. Finalement, les capacités informatiques offertes par les nombreuses ressources de calcul de la VO ESR ont permis d’envisager la prise en charge de nombreux scénarios de prévision de manière simultanée.
Cependant, l’inconvénient principal de cette approche se situe dans l’excédent de charge de travail et les compétences spécifiques qu’elle implique. Dans une dimension opérationnelle temps réel, les aspects technologiques doivent être idéalement minimisés afin de libérer l’utilisateur de toutes contraintes fonctionnelles et lui permettre une réalisation optimale de la mission pour laquelle il est astreint. De plus, les premiers tests de modélisation hydrologique grâce à ce portage ont permis d’identifier une forte variabilité des performances de calcul et un taux d’échec incompatible avec les besoins de l’expertise hydrologique en situation de crise.
Dans ce sens, le recours à des services web de l’OGC interfacés avec les services de l’intergiciel gLite et une interface graphique par laquelle le prévisionniste établit ces scénarios de prévision apparait indispensable à la mission d’expertise hydrologique allouée au SPC-GD. D’autre part, une meilleure prise en charge des jobs de grille doit être envisagée pour améliorer les performances de modélisation.
177