1
Stage “MesoNH sous Olive”
SWAPP/OLIVEToulouse
27 Novembre 2008
la swapp-bug-team en exercice :
Véronique Mathiot , Guillaume Beffrey, Eric Sevault
mail: [email protected]
liste de diffusion: [email protected]
2
1.1 Objectifs
Utiliser les fonctionnalités de base de SWAPP Créer une expérience MesoNH Modifier l'expérience Monitorer l'expérience
3
1.2 Plan
2. Historique et philosophie du système
3. Architecture générale et nomenclature
4. L'interface SWAPP (TP)
5. L'application Gco et la gestion des configurations
6. Création, modification et suivi d'une expérience MesoNH (TP)
4
2. Historique et philosophie
5
2. Historique et philosophie du projet
ou...comment on en est arrivé làà l'insu de notre plein gré.
6
2.1 Cadrage officiel Quand la direction technique de l'époque (Philippe Courtier)
décide de lancer un projet spécifique baptisé « Outil de Lancement Interactif et de Visualisation d'Expérience », les motivations sont les suivantes :
disposer d'un système « convivial » permettant à la communauté de prévision numérique orientée recherche opérationnelle de concentrer ses maigres ressources sur la dimension scientifique de son travail ;
favoriser le rapprochement opérationnel / recherche ;
s'inspirer de méthodes de travail en vigueur au CEPMMT ;
Le projet est monté en prélevant des ressources sur la bête, sur la base de la « valorisation de l'existant » (très hypothétique) et surtout sur la base de la bonne volonté des personnes volontaires (GMAP, COMPAS, DSI/OP).
7
2.2 État des lieux Le GMAP est assez naturellement au centre de ces
préoccupations. Le projet est d'ailleurs confié à Florence Rabier (GMAP/OBS) et le comité de pilotage à Bruno Lacroix (COMPAS/D). Deux éléments donnent une illustration de la situation périlleuse où nous en étions alors :
il n'était plus possible aux équipes de recherche, malgré de nombreux efforts en ce sens, de reproduire à l'identique (toutes conditions de calcul égales par ailleurs) la chaîne opérationnelle... ce qui induisait une validation de plus en plus aléatoire des développements et un risque de divergence sérieux ;
un mini-projet interne au GMAP visant à développer et maintenir un script multi-configurations du 4DVar, absorbait de plus en plus de ressources sans arriver à converger de façon totalement satisfaisante ;
8
2.3 Limitations Résoudre les difficultés exposées plus haut, était
donc la priorité du projet. Il faut garder à l'esprit cet aspect contingent pour comprendre un certain nombre de limitations (d'autres surviendront par après) du projet OLIVE :
il s'oriente naturellement au début vers des types d'expériences à finalité opérationnelle ;
un poids très important est mis sur la reproductibilité et la traçabilité des configurations d'expérience, y compris au détriment d'autres aspects (usage, ergonomie, etc.) ;
la capacité à opérer un rapprochement avec l'environnement opérationnel ne pouvait être un obstacle définitif à une réalisation effective pour le GMAP ;
le type d'utilisateur visé est essentiellement représenté par un développeur en prévision numérique plutôt expérimenté.
9
2.4 Chronologie fin 2000 : lettre de mission, le projet formel est en place entre
janvier 2001 et janvier 2004 ; 2001 : le prototypage d'une solution ad hoc s'avère de plus en
plus complexe, décision d'évaluer le framework de webmars développé par Baudouin Raoult au CEPMMT ;
2002/09 : pré-version 0, version remaniée webmars ; 2003/02 : version 0 pour gmapistes aventureux ! 2003/12 : version 1 (réécriture intégrale du noyau), bascule
transparente des bêtas testeurs, arrivée de nombreux autres utilisateurs ;
2004/09 : version 2 (mise à jour logicielle Apache / mod_perl 2), multi-serveurs ;
2005 : mises à jour (sécurités, liens, cibles) + CEPMMT ; 2006 : inflation configurations (GCO pilier OLIVE) ;
10
2.5 Quelques spécifications générales
enregistrer tous les changements des configurations opérationnelles et de leurs composants ;
construire, dupliquer, mettre au point et suivre le déroulement d'expériences a priori basées sur une configuration opérationnelle ;
permettre quelques diagnostiques graphiques utilisant des outils existants (metview, scores, etc.) ;
visualiser et pourvoir gérer (même sommairement) l'archivage des données issues de ces opérations ;
accéder de la façon la plus uniforme possible à toutes ces applications... une interface « web » serait donc la bienvenue ;
11
2.6 ... et quelques idées basiques L'application qui visualise l'information est la même que celle
qui produit ou modifie cette information ; L'application doit être explicite en elle-même (auto-
documentation ?) ; Pour tout ce qui relève de la prévision numérique elle-même,
rien ne doit être caché à l'utilisateur final : la plupart sont des utilisateurs avancés et ils doivent pouvoir effectuer toute investigation nécessaire en cas de difficulté scientifique ou technique ;
Utiliser des développements logiciels ayant fait leurs preuves dans la communauté météo :
SMS pour la soumission de jobs et la gestion du séquencement ;
XCDP comme interface graphique privilégiée sur SMS ;
12
2.7 Un cadre commun A la fois un cadre commun logiciel ( framework ) et
de convivialité ( communauté olive ) ; Le cadre commun logiciel est SWAPP :
SShared ( bah oui, puisque commun )
WWeb / WWeird ( faut se rendre à la raison )
APPAPPlications ( faut bien que ça fasse quelque chose )
L'implémentation dans le monde réel prend la forme d'un système de fichiers virtuel ( virtual file system ) constitué d'objets permanents (DB) doués d'attributs et capables de méthodes dans des contextes variés ;
Au moment de l'activité du projet, peu de choses disponibles ; depuis... c'est devenu un classique de développement ( RoR, +/- CMS php / mysql ) ;
13
3. Architecture générale et nomenclature
14
3. Nomenclature et Architecture générale
ou...c'est quand que qui fait quoi et où ?
15
3.1 SWAPP SWAPP en lui-même est un ensemble logiciel PERL
accessible depuis trois modes, trois « CONTEXTES » : mode shell émulé ( administration du système ) ;
API pour développements spécifiques ( advanced users );
APACHE / mod_perl ( navigation usuelle ) ;
SWAPP #!/usr/bin/perl -w
use Swapp;
...
16
3.2 Où est stockée l'information ? Les objets persistants sont stockés localement au
SERVER SWAPP, dans des unités « invisibles » à l'utilisateur, mais qui peuvent être aisément sauvegardées, dupliquées, etc.
L'accès se fait selon l'un des trois modes décrits plus haut ...
rootrootSWAPPSWAPP
userusersharedshared
17
3.3 L'alter ego de SWAPP : SMS Scheduling and Monitoring System En charge du séquencement des jobs, de la gestion des
dépendances, de la soumission effective des tâches... Notre version embarque l'API SWAPP et est capable de
reconstituer à la volée l'information nécessaire à la constitution du shell et son exécution ;
XCDP est son interface naturelle ;
SMSSMS
18
3.4 Le « Server » OLIVE
Ce que l'on nomme couramment le « serveur OLIVE » est donc en fait la réunion des serveurs APACHE+SWAPP et SMS+SWAPP :
Apache+ SWAPP
Apache+ SWAPP
SMS+ SWAPP
SMS+ SWAPP
OLIVEcible(s)d'exécution
science del'utilisateur
19
3.5 Les cibles d'exécutions et d'archivage
Une cible d'exécution est un système informatique quelconque capable de tourner une tâche olive, ie :
répertorié dans l'espace virtuel swapp comme étant un « target experiment » ;
disposant de l'outillage minimal : la « toolbox » OLIVE ; L'archivage regroupe les espaces de stockage
(permanents ou non) qui permettront aux tâches des expériences de partager des données puis de les stocker ;
OLIVE(virtual)
OLIVE(virtual)
TARGET(real)
TARGET(real)
WORKDIRWORKDIR
COUGARCOUGAR
20
4. L'interface SWAPP
21
4.1 Les serveurs SWAPP Liens vers les serveur olive:
depuis le site http://gco.meteo.fr , rubrique OLIVE, « Direct link to SWAPP OLIVE »
Accès directs:
http:/ /sxobs1.cnrm.meteo.fr:8181/swapp_entry/margaret/ Swapp/Browse/etc/apps/Swapp/
http:/ /sxalgo1.cnrm.meteo.fr:8181/swapp_entry/groucho/ Swapp/Browse/etc/apps/Swapp/
http:/ /sxrecyf2.cnrm.meteo.fr:8181/swapp_entry/cocoanuts/ Swapp/Browse/etc/apps/Swapp/
http:/ /sxcoope1.cnrm.meteo.fr:8181/swapp_entry/chico/ Swapp/Browse/etc/apps/Swapp/
http:/ /sxproc1.cnrm.meteo.fr:8181/swapp_entry/harpo/ Swapp/Browse/etc/apps/Swapp/
http:/ /cannelle.meteo.fr:8181/swapp_entry/monkeybizz/ Swapp/Browse/etc/apps/Swapp/
22
4.2 Applications et bases utilisateur
Chaque utilisateur dispose de 2 bases :
- une base de données archive (/archive/group/user),
- une base de données personnelle (/home/group/user) contenant :
un presse-papier (clipboard)
une poubelle (trash)
un répertoire de favoris (favorites)
un répertoire contenant ses expériences (experiments)
Accès aux applications de SWAPP : Olive, Gco, Archive
23
4.3 Les méthodes sur les objets
- visualiser (browse) - éditer (edit) - renommer (configure) - créer un répertoire (configure) - copier - coller - couper - supprimer - ordonner (configure)
24
4. L'interface SWAPP
TP
25
5. Application Gco et gestion des configurations
26
5. Application GCO et gestion des configurations
Gestion des cycles opérationnels (GCO) historique des cycles des chaînes opérationnelles,
doubles ou en test
cycle: liste d'éléments (namelists, binaires, fichiers de constantes, etc) correspondant à une version donnée d'une configuration.
Gestion des configurations historique des changements de structure des
scripts
27
5.1 Nomenclature des cycles opérationnels
Les cycles: nomenclature
ARPEGE ETIRE: cy32t0_op2.25
ARPEGE TROPIQUE: cy32t0_tropique-op1.09
ALADIN FRANCE: al31t1_op1NEC.13
ALADIN REUNION: al32t0_reunion-op1.02
AROME: al32t2_arome-bf.04
MESONH: mn32t0_masdev47.02
CY32T0_(name-)OP1.11
nom du
cycle
nom de
la branche
numéro de
version
nom de la config.
(facultatif)
28
5.2 Gestion des cycles opérationnelsApplication GCO sous SWAPP: l'historique
accès: >> GCO >> Search in history of cycles
Chaque modification d'élément est historisée avec un classement:
par type de chaîne (oper/dble/test) par date (et réseau si oper/dble)
Outils genv/gget
(accessible en ligne de commande: ~marp001/public/bin/)
genv: obtenir la liste des éléments d'un cycle gget: récupérer en local un élément (depuis cougar ou
depuis un tampon GCO sur tori/sumo)
historique également disponible sur l'intra-GCO: http://gco.meteo.fr/
29
5.3 Gestion des configurations
Historique des changements de structure des scripts
accès:
>> Olive >> Browse OLIVE configurations
les configurations sont classées par type puis par version
Les versions de configurations sont liées aux versions de cycle
30
5.4 Lien avec une expérience Olive...
Une expérience Olive s'appuie sur: une structure définie par la version de configuration
des éléments définis par la version de cycle
=> à la création d'une expérience, le choix d'un cycle suffit à déterminer la configuration utilisée...
L'expérience Olive utilise des éléments issus: de l'archivage GCO (genv, gget)
éléments localisés sur le tampon GCO de tori/sumo ou depuis cougar
de l'archivage oper ou double (DSI/OP)
sur cougar : ~mxpt001/.....
de l'expérience elle-même
directement du workdir ou sur cougar: $HOME/xp/$XPID/...
31
5.5 L'équipe GCO
gestion des codes sources des modèles météorologiques (arpege, aladin, arome), compilation
historisation des nouveaux éléments (cycles) et des nouvelles configurations
fourniture des éléments à DSI/OP pour les modifications sur les chaînes oper et double.
Tests de reproductibilité entre les chaînes oper/dble et Olive
Véronique Mathiot, Stéphane Martinez, Guillaume Beffrey
intra-gco: http://gco.meteo.frmail: [email protected]
32
6. Création, modification et suivi d'une expérience MesoNH
33
6. Application Olive
Création d'une expérience :
- le contexte (oper/double)
- le cycle ou la date à laquelle ce cyle était oper ou double
- le type de configuration
On peut ensuite choisir :
- le cutoff
- la période de l'expérience
- la machine d'exécution
- toutes les variables ou ressources utilisées
34
6.1 Définition d'une expérience
Une expérience est une arborescence de :
- répertoires, familles et tâches,
- paramétrée par des variables et des fonctions.
Elle possède un identifiant unique. Sa structure est toujours la même :
date/réseau/cutoff/familles/tâches
35
6.2 Composants d'une expérience
Famille : ensemble de tâches.
Tâche : séquence de ressources d'entrée, d'exécution et de sortie.
Ressource : objet permettant de décrire un élément de configuration d'un modèle. La classe et les attributs d'un objet définissent son comportement.
36
6.2 Composants d'une expérience
Variable : les variables SWAPP sont des variables d'environnement. Elles peuvent être définies à tous les niveaux de l'expérience.
Trigger : fonction SMS utilisée pour introduire des dépendances entre tâches ou familles.
Setup : objet situé sur la première page d'une expérience permettant de configurer certains paramètres de l'expérience (profils des jobs, échéance de prévision)
37
6.3 Suivi de l'expérience:Configuration d'XCDP
POUR CONFIGURER XCDP:- Lancer XCDP
- Dans l'onglet « edit », sélectionner « preferences »
- Dans l'onglet « user level », définir « administrator »
- Dans l'onglet « server », définir votre serveur. Par exemple:
name: sxcoope1
host: sxcoope1.cnrm.meteo.fr
number: 314159
et cliquer sur « add »
- Dans l'onglet SMS, indiquer 120 pour le « Call SMS every » (seconde ligne)
- Fermer la fenetre
- Utiliser l'onglet Servers pour vous connecter
POUR SELECTIONNER LA SUITE A VISUALISER:
- Faites un clic droit sur le nom du serveur et sélectionner « suite »
38
6.3 Suivi d'une expérience
Sur tori : les jobs découpage des jobs en « steps » : $FTDIR/mtool/submit
répertoire de travail des jobs : $FTDIR/mtool/spool
outputs des jobs : $HOME/xpout/$xpid/$yyyymmdd/$hh/$cutoff/
Sur tori : en cas de plantage sauvegarde du répertoire de travail :
$WORKDIR/xp/$user/$xpid/$yyyymmdd/$hh/$cutoff
Sur tori : les résultats $WORKDIR/xp/$xpid/$yyyymmddH$hhA|P
Sur cougar : les résultats
$HOME/xp/$xpid/$yyyymmddH$hhA|P
39
7. Archivage et ménage
40
7.1 Archivage
Cougar : $HOME/xp/n°expérience
Tori : $WORKDIR/xp/n°expérience
SWAPP_OUTPUT_STRATEGY (default = archive,workdir)
SWAPP_ARCHIVE_NAME (default = cougar)
Miroir de l'archive et gestion de l'archive : application Archive de SWAPP
41
7.2 Ménage
Nettoyage automatique de l'archive en fonction de règles d'archivage :
- suppression des objets correspondants sous SWAPP
- déplacement des fichiers concernés sur cougar sous $HOME/trash/xp
Des règles sont définies par défaut sous SWAPP : /shared/archive/default
- Une règle est définie par une priorité, un nom de répertoire, un nom de fichier et une durée de rétention.
- Les règles peuvent être redéfinies par l'utilisateur à n'importe quel niveau de l'arborescence.
42
THE END
Top Related