Post on 08-Jan-2016
description
Architecture de Polyphemus
Vue d’ensemble.
Comment trouver ses repères?
Comment envisager des adaptations mineures?
A propos des outils de développement.
A venir.
Vue d’ensemble
L’organisation de la future version 1.4:
reflète les 3 étapes suivantes:
preprocessing,
processing,
post-processing.
reflète la modularité.
/preprocessing/preprocessing/ic
/bc
/bio
/dep
emissions
/ground
/meteo
/processing/
assimilation
/castor
/decay
/gaussian
/global
/local
/nesting
/plume-in-grid
/racm
/radm
/siream
/siream-aec
/postprocessing/postprocessing/ensemble
/optics
/waterplume
/include/include
/Atm
oData
/Talos
/SeldonD
ata
/atmopy
/comm
on
/driver
/models
/modules
/wgrib
/eqsam
/isorropia
/isorropia_aec
/newran
/config (/config)
/raw data /data /results
Repère: structuration
Preprocessing: intérêt à générer des données
intermédiaires communes à plusieurs scenarii
ou traitements particuliers (calcul
d’ensemble...).
/preprocessing/preprocessing/ic
/bc
/bio
/dep
emissions
/ground
/meteo
Un sous-répertoire par type de
traitement.
A un fichier .cpp correspond un
programme exécutable (partout dans
Polyphemus).
Ex: Dans meteo, on compilera
meteo.cpp pour obtenir meteo qui
exploite des données ECMWF.
Si on a des données MM5, on
utilisera MM5-meteo obtenu à partir
de MM5-meteo.cpp.
Repère: structuration
Preprocessing: intérêt à générer des données
intermédiaires communes à plusieurs scenarii
ou traitements particuliers (calcul
d’ensemble...).
Processing: programme qui traitera le modèle
considéré (gaussien, eulérien, ...) avec une
méthode donnée.
/preprocessing/preprocessing/ic
/bc
/bio
/dep
/emissions
/ground
/meteo
/processing/assimilation
/castor
/decay
/gaussian
/global
/local
/nesting
/plume-in-grid
/racm
/radm
/siream
/siream-aec
Idem que
preprocessing
mais
uniquement
des .cpp avec
les fichiers de
configuration
exemples
Repère: structuration Preprocessing: intérêt à générer des données
intermédiaires communes à plusieurs scenarii
ou traitements particuliers (calcul
d’ensemble...).
Processing: programme qui traitera le modèle
considéré (gaussien, eulérien, ...) avec une
méthode donnée.
Post-processing: en python pour profiter, soit
de l’interactivité (ipython), soit de
l’automatisation (écriture de scripts).
/preprocessing/preprocessing/ic
/bc
/bio
/dep
/emissions
/ground
/meteo
/processing/assimilation
/castor
/decay
/gaussian
/global
/local
/nesting
/plume-in-grid
/racm
/radm
/siream
/siream-aec
/postprocessing/postprocessing/ensemble
/optics
/waterplume
Repère: structuration
Dans le répertoire /include:
Ce qui est voué à être partagé (librairies,
fonctions, etc...)
Ce qui est externe (newran, wgrib, isorropia...)
/preprocessing/preprocessing/ic
/bc
/bio
/dep
/emissions
/ground
/meteo
/processing/assimilation
/castor
/decay
/gaussian
/global
/local
/nesting
/plume-in-grid
/racm
/radm
/siream
/siream-aec
/postprocessing/postprocessing/ensemble
/optics
/waterplume
/include/include
/Atm
oData
/Talos
/SeldonD
ata
/atmopy
/comm
on
/driver
/models
/modules
/wgrib
/eqsam
/isorropia
/isorropia_aec
/newran
Repère: architecture du processing 3 niveaux:
Le « driverdriver » (ex: résolution simple ou calcul d’ensemble ou
assimilation de données etc...) est lancé par sa méthode
Run (« Driver.Run() »).
Opère sur
le(s) « modelmodel(s) » (ex: équation de chimie transport) est
intégré à chaque pas de temps par sa méthode Forward
(« Model.Forward() »).
Qui est composé si nécessaire
des « modulesmodules » (ex: les termes pris en compte dans
l’équation de chimie transport = advection, diffusion, chimie,
etc) également intégés par Forward (« Module.Forward() »)
Repère: Illustration par polair3d.cpp
#include "AtmoData.hxx"
#include "BaseDriver.cxx"
#include "Polair3DChemistry.cxx"
#include "SplitAdvectionDST3.cxx"#include "DiffusionROS2.cxx"#include "ChemistryRACM.cxx"
#include "BaseOutputSaver.cxx"...
int main(int argc, char** argv){... typedef double real; typedef Polair3DChemistry<real, SplitAdvectionDST3<real>, DiffusionROS2<real>, ChemistryRACM<real> > ClassModel; BaseDriver<real, ClassModel, BaseOutputSaver<real, ClassModel> > Driver(argv[1]);
Driver.Run();
Driver
Model
Modules
/preprocessing/preprocessing/ic
/bc
/bio
/dep
/emissions
/ground
/meteo
/processing/assimilation
/castor
/decay
/gaussian
/global
/local
/nesting
/plume-in-grid
/racm
/radm
/siream
/siream-aec
/postprocessing/postprocessing/ensemble
/optics
/waterplume
/include/include
/Atm
oData
/Talos
/SeldonD
ata
/atmopy
/comm
on
/driver/
assimilation
/
comm
on/local
/
uncertainty
/models*.cxx,
*.hxx
/modules/aerosol
/
chemistry/
comm
on/
transport
/wgrib
/eqsam
/isorropia
/isorropia_aec
/newran
Repère: schématiquement
Dans le .cpp
On inclut les fichiers sources contenant les modules,
le modèle, la méthode de sauvegarde et le pilote.
On déclare Modèle(module1, module2, ...).
On declare Pilote(modèle, méthode de sauvegarde).
Clés: changer la chimie de RACM
en RADM#include "AtmoData.hxx"
#include "BaseDriver.cxx"
#include "Polair3DChemistry.cxx"
#include "SplitAdvectionDST3.cxx"#include "DiffusionROS2.cxx"#include "ChemistryRACM.cxx"
#include "BaseOutputSaver.cxx"...
int main(int argc, char** argv){... typedef double real; typedef Polair3DChemistry<real, SplitAdvectionDST3<real>, DiffusionROS2<real>, ChemistryRACM<real> > ClassModel; BaseDriver<real, ClassModel, BaseOutputSaver<real, ClassModel> > Driver(argv[1]);
Driver.Run();
Clés: changer la chimie de RACM
en RADM?#include "AtmoData.hxx"
#include "BaseDriver.cxx"
#include "Polair3DChemistry.cxx"
#include "SplitAdvectionDST3.cxx"#include "DiffusionROS2.cxx"#include "ChemistryRADM.cxx"
#include "BaseOutputSaver.cxx"...
int main(int argc, char** argv){... typedef double real; typedef Polair3DChemistry<real, SplitAdvectionDST3<real>, DiffusionROS2<real>, ChemistryRADM<real> > ClassModel; BaseDriver<real, ClassModel, BaseOutputSaver<real, ClassModel> > Driver(argv[1]);
Driver.Run();
Clés: passer à un modèle gaussien?#include "AtmoData.hxx"
#include "PlumeDriver.cxx"
#include "GaussianPlume.cxx"
#include "BaseOutputSaver.cxx"
...
int main(int argc, char** argv)
{
typedef double real;
typedef GaussianPlume<real> ClassModel;
PlumeDriver<real, ClassModel, BaseOutputSaver<real, ClassModel> > Driver(argv[1]);
Driver.Run();
...
Cette fois, le driver est spécifique car des
instructions propres au gaussien y sont
(lecture de la météo dans un fichier .dat
spécial).
Pas de modules pour le gaussien,
tout est implémenté dans le modèle.
Clés: une sauvegarde spécifique?
Dans /include/driver/common se trouvent les outils disponibles
qui touchent au driver, notamment les procédures de
sauvegarde, dans le sous-répertoire output_saver.
Partir d’un .cxx qui est le plus proche de ce que l’on veut et en
faire une copie pour modification.
Déclarer la classe obtenue au niveau de
BaseOutputSaver::init() et dans le fichier de configuration.
Contribuer
Pour qu’un développement puisse devenir une
contribution Polyphemus, il faut assurer:
1/ la cohérence avec l’architecture existante,
2/ le respect des conventions de codage,
3/ un intérêt potentiel suffisant pour d’autres que soi,
4/ et si le développement est conséquent, un test
associé.
Outils de développement Pour compiler, utiliser de préférence SConsSCons qui est plus
portable et maintenable que make! (une version locale de scons
est incluse dans la distribution)
Valgrind peut être utile pour les fuites de mémoire et l’analyse
du temps de calcul.
Kdiff3 offre une interface conviviale pour analyser les
différences entre deux fichiers texte.
Utiliser les trackers de bugs et de requêtes sur le site du projet
Polyphemus dans Gforge (onglet « Suivi ») et les listes de
diffusion.
Pour des développeurs plus aguerris et réguliers, l’ensemble du
projet est accessible et modifiable sur le dépôt svn de la Gforge
Inria.
Dans les semaines et les mois à
venir...
Interface graphique pour lancer et exploiter des calculs en local
ou sur un serveur distant via un navigateur web. Dans un
premier temps, limité à des configurations très précises (TP
ParisTech).
Ajout d’un modèle lagrangien de diffusion de particules.
Passage au format netcdf.