Architecture de Polyphemus

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


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


Preprocessing: intérêt à générer des données



d’ensemble...).

Processing: programme qui traitera le modèle

considéré (gaussien, eulérien, ...) avec une

méthode donnée.


/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



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


/bc

/bio

/dep

/emissions

/ground

/meteo


/castor

/decay

/gaussian

/global

/local

/nesting

/plume-in-grid

/racm

/radm

/siream

/siream-aec


/optics

/waterplume


Dans le répertoire /include:

Ce qui est voué à être partagé (librairies,

fonctions, etc...)

Ce qui est externe (newran, wgrib, isorropia...)


/bc

/bio

/dep

/emissions

/ground

/meteo


/castor

/decay

/gaussian

/global

/local

/nesting

/plume-in-grid

/racm

/radm

/siream

/siream-aec


/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


/bc

/bio

/dep

/emissions

/ground

/meteo


/castor

/decay

/gaussian

/global

/local

/nesting

/plume-in-grid

/racm

/radm

/siream

/siream-aec


/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 "SplitAdvectionDST3.cxx"#include "DiffusionROS2.cxx"#include "ChemistryRACM.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 "SplitAdvectionDST3.cxx"#include "DiffusionROS2.cxx"#include "ChemistryRADM.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.

Architecture de Polyphemus

Documents

Transcript of Architecture de Polyphemus