.. meta::
:keywords: maillage, champ, manipulation
:author: Guillaume Boulant
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ANNEXE: Note de travail concernant le chantier XMED 2010
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
.. contents:: Sommaire
:local:
:backlinks: none
Principes directeurs du dĂŠveloppement
=====================================
En matière de dÊveloppement:
* On ne cherche pas d'emblĂŠe Ă s'inscrire dans la fabrication d'un
module SALOME diffusable dans la version d'exploitation 2010 (SALOME
6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
devoir tenir compte des contraintes de temps SALOME et (ii) le
produit envisagĂŠ fin 2010 est une maquette qui cherche Ă ĂŠprouver
l'ergonomie gĂŠnĂŠrale d'utilisation et en aucun cas on ne peut
garantir la rĂŠalisation d'un module SALOME compatible avec les
exigences de mise en exploitation.
* On ne cherche pas d'emblĂŠe Ă capturer tous les cas d'application,
mais Ă concevoir un dĂŠveloppement qui acceptera les extensions de
pÊrimètres dans des conditions raisonnables. Aussi, les
fonctionnalitĂŠs dĂŠveloppĂŠes seront celles qui sont nĂŠcessaires Ă la
rĂŠalisation des cas d'application de rĂŠfĂŠrence;
En matière d'ergonomie:
* L'interface utilisateur de rĂŠfĂŠrence (appelĂŠ espace de travail dans
le volet de spĂŠcifications fonctionnelles) est l'interprĂŠteur
python. Les fonctionnalitĂŠs doivent ĂŞtre pensĂŠes pour un usage
adaptĂŠ Ă une interface textuelle (TUI) de ce type.
* La crĂŠation d'une interface graphique (GUI) peut ĂŞtre envisagĂŠe en
complĂŠment et comme un moyen de manipuler graphiquement les
fonctionnalitĂŠs dĂŠveloppĂŠes pour l'interface textuelle et pour aider
la prĂŠparation des variables dans l'interface python.
* Le modèle d'un processus de manipulation de champs est:
- PrĂŠparation du jeu de variables U, V, ... reprĂŠsentant les champs
Ă manipuler. C'est Ă ce stade que l'on rĂŠsoud la question de
sĂŠlection des donnĂŠes (dans un champ publiĂŠ dans l'arbre d'ĂŠtude,
par un module de calcul ou par chargement d'un fichier med)
- Utilisation des variables avec une sĂŠmantique la plus proche
possible du modèle conceptuel et des spÊcifications
fonctionnelles;
- CrĂŠation des variables qui reprĂŠsentent les rĂŠsultats des
fonctions de manipulation;
- Persistence (fichier med), visualisation (SALOME) ou export (vers
une structure qui peut ĂŞtre directement utilisable en numpy)
Sur le plan technique:
* On souhaite spĂŠcifier clairement le conteneur SALOME des fonctions
de manipulation de champs. Pour discussion:
- Il apparaĂŽt que les modules SALOME MED et VISU contiennent dĂŠjĂ
des fonctions qui peuvent faire partie des fonctions de
manipulations de champs (en particulier pour l'exploration des
structures MED, leur visualisation et la sĂŠlection des donnĂŠes Ă
manipuler).
- Dans la mesure oĂš le module MED n'est pas utilisĂŠ Ă ce jour (en
tout cas pas sous sa forme de module SALOME) et compte-tenu du
caractère obsolescent du module VISU (amenÊ à être remplacÊ sur le
plan fonctionnel par le module PARAVIS), on pourrait examiner la
crĂŠation d'un module dĂŠdiĂŠ Ă la manipulation des maillages et des
champs par l'agrĂŠgation technique au sein d'un mĂŞme module des
fonctions des modules MED et VISU.
Au moins dans un premier temps, on se donne les limites suivantes:
* Une opĂŠration ne peut pas combiner des pas de temps diffĂŠrents. Dans
l'hypothèse oÚ cette limite venait à être levÊe, on doit spÊcifier
le pas de temps de la donnĂŠe rĂŠsultat;
* Le domaine d'application d'une opĂŠration pourra ĂŞtre dĂŠfini
exclusivement par la donnĂŠe d'un maillage ou un groupe d'ĂŠlĂŠments du
maillage;
* On ne traite pas le cas des champs qui prennent leurs valeurs aux
points de gauss ou aux noeuds par ĂŠlĂŠment. Une particularitĂŠ de ces
types de support est que le repĂŠrage de la position implique deux
indices (par exemple l'indice de la maille, puis l'indice du point
de gauss).
ElĂŠments de conception
======================
Plan gĂŠnĂŠral
------------
On peut par exemple imaginer une maquette du genre:
* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
structure des maillages et des champs dans l'arbre d'ĂŠtude.
* SĂŠlectionner un ĂŠlĂŠment (par exemple un pas de temps d'un champ) et
le menu contextuel permet d'exporter ce champ dans la console python
pour manipulation. Pour cela, s'inspirer de la fonction
``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
PythonConsole.
* L'ĂŠlĂŠment est marquĂŠ comme ayant ĂŠtĂŠ exportĂŠ, on peut imaginer une
rĂŠcupĂŠration ultĂŠrieure.
* Exporter un deuxième champ cohÊrent avec le premier (même pas de
temps et dĂŠfini sur le mĂŞme maillage avec le mĂŞme support, on
s'arrange pour).
* Dans la console python, faire les opĂŠrations sur les champs
* Publication du champ rĂŠsultat dans l'arbre d'ĂŠtude pour sauvegarde
ultĂŠrieure. C'est a priori le gros morceau qui consiste Ă faire un
objet CORBA MED Ă partir d'un objet MED standard, en plus dĂŠfini
dans la console python (sous forme d'objet python).
Quand ce premier cas d'utilisation est au point, on peut envisager de
le complĂŠter par les opĂŠrations suivantes
* exporter le rĂŠsultat med dans un fichier
* visualiser les champs produits
Plan de dĂŠveloppement:
* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
d'architecture, l'opĂŠration physique se dĂŠroulera en dĂŠfinitif au
niveau de MEDMEM pur.
* PrĂŠvoir une implĂŠmentation des opĂŠrations sous forme de fonctions
informatiques, mĂŞme les opĂŠrations algĂŠbriques (+,-,*,/). Pour ces
dernières et dans certaines conditions (quand on manipule
directement les strutures MEDMEM et non pas les objets CORBA),
l'utilisation des formes A+B, A-B, ... peuvent ĂŞtre rendues
possibles. Dans ce cas, voir la possibilitĂŠ de combiner plusieurs
opĂŠrations algĂŠbriques sur une seule ligne: A+B-C*0.3.
* On peut charger la structure MED sous forme d'objet CORBA publiable
dans l'ĂŠtude, de sorte d'avoir accĂŠs aux mĂŠta-donnĂŠes et pouvoir par
exemple sĂŠlectionner les champs d'intĂŠrĂŞt. De cet objet CORBA, on ne
rÊcupère que les informations nÊcessaires au chargement d'un champs:
le nom du champs, le nom de son maillage associĂŠ, les identifiants
du pas de temps, au besoin une structure Field non chargĂŠe (par
exemple pour rĂŠcupĂŠrer plus facilement le maillage).
* Un mĂŠcanisme (Ă dĂŠvelopper Ă partir du PyConsole par exemple)
pourrait alors permettre le chargement des champs sĂŠlectionnĂŠs dans
la console python et sous un nom facile Ă manoeuvrer. Prendre
inspiration sur XCADGUI::LoadIntoPythonConsole().
* A priori, les donnĂŠes sont physiquement chargĂŠe dans le GUI. Au
besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
CORBA field Ă partir d'un field standard (Ă tester).
Une autre idĂŠe est de rĂŠcupĂŠrer le pointeur CORBA MED dans la console
python et de tirer les donnĂŠes Ă partir de lĂ . Ajouter une couche de
wrapping python pur pour gĂŠrer les cas de simplification (surcharge
des opĂŠrations arithmĂŠtiques par exemple).
Besoins complĂŠmentaires:
* L'interprĂŠteur doit contenir des ĂŠlĂŠments d'aide (par exemple un
help qui liste les opĂŠrations possibles sur les champs chargĂŠs)
* prĂŠvoir quelques fonctions de visu et de persistence. Cela commence
probablement par des fonctions de publication dans l'ĂŠtude des
champs crĂŠĂŠs par les opĂŠrations de manipulation. Les champs sont
physiquement ajoutĂŠ automatiquement Ă la structure med par le MedOp
mais il n'est pas obligatoirement publiĂŠ => fournir un moyen de
publication.
Limitations actuelles (liĂŠes Ă la conception de MEDMEM):
* les champs doivent ĂŞtre gĂŠrĂŠs par la mĂŞme structure MED car ils
doivent partager le mĂŞme support.
* les opĂŠrations possibles dans MEDMEM sont entre champs pris sur un
pas de temps (Q: les pas de temps peuvent-ils ĂŞtre diffĂŠrents).
DĂŠveloppements
--------------
DĂŠveloppement de classes proxy:
* FieldProxy, FieldTimeSeriesProxy
* Attention pour les ĂŠries temporelles, le SUPPORT med peut ĂŞtre
diffĂŠrent en chaque pas de temps (par exemple en cas d'extension
spatiale du champ au cours du temps).
MEDMEM_MedDataManager:
* FIX: test de l'implĂŠmentation C++ au travers de la fonction test() du
MedOperator ==> OK. Quand on fait la mĂŞme opĂŠration depuis python
via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
destructeur du champ semble ĂŞtre appelĂŠ. Pb de gestion des pointeurs?
Evolutions Ă prĂŠvoir
====================
Concernant MEDMEM:
* FIX: SALOME_MED::MED::getField devrait pouvoir ĂŞtre appelĂŠe
plusieurs fois de suite puisqu'on recycle la rĂŠfĂŠrence si elle est
dĂŠjĂ chargĂŠe.
* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
exemple avec un getField qui renvoie le champ s'il est dĂŠjĂ chargĂŠ
ou le charge et le renvoie sinon).
* IMP: RĂŠcupĂŠrer le nom du fichier med Ă partir de l'objet MED, en
passant a priori par le driver associĂŠ. Plusieurs driver peuvent
ĂŞtre associĂŠs Ă une structure MED car les donnĂŠes peuvent ĂŞtre
chargĂŠes en plusieurs fois et de plusieurs fichiers. Il faut donc
ĂŠtendre la structure MED pour avoir accĂŠs Ă la liste des driver puis
de cette liste dĂŠduire les noms des fichiers.
* IMP: OpĂŠrations combinant des champs sur des support diffĂŠrents ne
peuvent pas ĂŞtre faites par l'API (une exception est levĂŠe en cas de
supports incompatibles), mais on peut imaginer le faire en
manoeuvrant les tableaux de donnĂŠes directement.
* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
prĂŠalablement ajoutĂŠ: une fonction removeField en complĂŠment de
addField.
Concernant l'interface SALOME_MED:
* IMP: Fonctions algĂŠbriques, qui seront implĂŠmentĂŠes au niveau de la
structure MED et requĂŞtĂŠes au niveau des classes proxy en spĂŠcifiant
les identifiants des champs impliquĂŠs et les paramĂŠtres requis (pas
de temps en particulier).
Concernant le module MED:
* IMP: pourvoir exporter la structure med dans un fichier med (la
structure ayant pu ĂŞtre enrichie par la publication de champs crĂŠĂŠs
par les operations de champs.
Historique des travaux
======================
20100726 : mise au point du schĂŠma de conception
------------------------------------------------
Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
raisons:
* MED Coupling ne peut pas gĂŠrer des mailles de dimensions diffĂŠrentes
dans un même modèle (choix faits dans un soucis de performance dans
l'accès à une structure de donnÊe compact). On peut contourner le
problème en dÊfinissant deux champs pour traiter chacun des type de
mailles.
* Un champ repose sur un maillage complet (pas de notion de profil,
mais cela peut ĂŞtre ĂŠmulĂŠ en crĂŠant deux maillages)
* Le concept de point de gauss n'existe pas (pas implĂŠmentĂŠ)
TODO:
* IdĂŠalement, il conviendrait de faire un ĂŠtat des lieux du module
MED, en particulier des ĂŠlĂŠments MEDMEM (le coeur), les interfaces
CORBA associĂŠes (MED.idl implĂŠmentĂŠ dans le package source
MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
implĂŠmentĂŠ dans le package source MED) et le GUI (MedGUI.cxx
implĂŠmentĂŠ dans le package source MEDGUI).
* Ergonomie TUI et modèle CORBA associÊ:
1. Charger un objet medmem (puis les objets mĂŠtier mesh et field)
sur un domaine d'application donnĂŠ.
2. En faire des variables disponibles dans l'interface TUI et que
l'on peut manipuler dans des opĂŠrations algĂŠbriques.
3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
les autres modules SALOME.
* ComplĂŠter le diagramme de la structure informatique de MED (en
particulier l'implĂŠmentation des interface IDL).
* PrÊparer un module de travail XMED (organisation d'une bibliothèque)
Tests Ă rĂŠaliser:
* Est-il possible de faire des opĂŠrations algĂŠbriques Ă partir des
objets SALOMEMED (objects CORBA MED)?
* CrĂŠation d'un objet MED_i Ă partir d'une objet MED pur prĂŠalablement
chargĂŠ en mĂŠmoire.
A retenir:
* Des opĂŠrations de champs sont possibles sur des champs Ă des pas de
temps fixĂŠs. Si l'opĂŠration doit ĂŞtre menĂŠe sur plusieurs pas de
temps, alors itĂŠrer sur chaque pas de temps. L'idĂŠe ici est
d'introduire le concept de sĂŠrie temporelle de champs en temps
qu'objet manipulable.
* Pour deux champs diffĂŠrents de la mĂŞme structure MED, la donnĂŠes des
identifiants dt et it ne correspond pas forcĂŠment au mĂŞme instant
absolu (en tout cas rien ne le garanti, mĂŞme si c'est tout de mĂŞme
une pratique courante).
20101005 : première maquette de dÊmonstration de l'ergonomie en MEDMEM pur
--------------------------------------------------------------------------
XMED: svn rĂŠvision 16
Travailler avec le fichier de donnĂŠe testfield.med joint.
20101007 : Vers une maquette CORBA
----------------------------------
Le contexte d'utilisation des opĂŠrations de champs est l'environnement
SALOME. Le support de gestion des donnĂŠes est donc l'ĂŠtude SALOME. Au
plus bas niveau, les champs sont des objets MEDMEM instanciĂŠs dans une
session SALOME (soit par un code de calcul intĂŠgrĂŠ, soit par
chargement des donnĂŠes Ă partir d'un fichier med). Ces objets sont en
gĂŠnĂŠral rĂŠfĂŠrencĂŠs dans l'ĂŠtude SALOME sous la forme d'objets CORBA de
classe SALOMEMED::FIELD. Plus exactement, l'Êtude SALOME gère des
SObject (Study Object) dont un attribut est une rĂŠfĂŠrence vers un
objet CORBA de classe SALOMEMED::FIELD qui lui-mĂŞme encapsule un objet
MEDMEM::Field.
On peut donc envisager une solution dans laquelle on donne Ă
l'utilisateur des poignĂŠes de manipulation des objets
SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
type proxy. Cela signifie que l'utilisateur ne manipule pas
directement des objets MEDMEM mais des objets python qui font
l'interface (Ă concevoir et implĂŠmenter, a priori avec un design
pattern de type proxy).
L'utilisation directe des objets MEDMEM aurait pu ĂŞtre une solution
extremement pratique dans la mesure oĂš ces objets en l'ĂŠtat peuvent
ĂŞtre combinĂŠs dans des opĂŠrations de champs (c'est dĂŠjĂ
implĂŠmentĂŠ). Par contre, ce procĂŠdĂŠ souffre de limitations importantes
dans la gestion et la circulation des donnĂŠes pour les diffĂŠrents cas
d'utilisation envisagĂŠs (visualisation, export, transfert Ă un autre
module SALOME).
L'avantage de la solution proposĂŠe est multiple:
* Elle permet de travailler sur une structure MED cohĂŠrente pour
intĂŠgrer les rĂŠsultats des opĂŠrations de calculs et combiner des
champs cohĂŠrents entre eux. Tout passe par des classes proxy qui
pourront s'assurer de la cohĂŠrence des opĂŠrations demandĂŠes et
exĂŠcuter automatiquement les fonctions de prĂŠ-traitement ou
post-traitement requises pour ces opĂŠrations. On peut imaginer par
exemple que les requĂŞtes d'opĂŠration soient envoyĂŠes par les classes
proxy Ă la structure MED Ă laquelle les champs sont associĂŠs pour
piloter l'opĂŠration en MEDMEM pur.
* Elle permet d'automatiser un certain nombre d'opĂŠrations
implicites. Par exemple si deux champs ne sont pas dĂŠfinis dans la
mĂŞme unitĂŠ, un changement d'unitĂŠ peut ĂŞtre effectuĂŠ automatiquement
par la classe proxy avant de commander l'opĂŠration au niveau
MEDMEM.
* Elle permet de laisser les donnĂŠes sur le container SALOME et de
rĂŠaliser des opĂŠrations sans rappatrier les donnĂŠes en local (qui
peuvent ĂŞtre en trĂŠs grand nombre).
* Elle permet d'ĂŠtendre facilement l'ergonomie de manipulation des
champs, par exemple en dĂŠfinissant la notion de *sĂŠrie temporelle de
champs*, ou encore les concepts de *domaine de dĂŠfinition* ĂŠvoquĂŠs
dans les spĂŠcifications fonctionnelles.
* Elle rend immĂŠdiat la circulation des donnĂŠes entre modules SALOME,
puisque les champs restent accessble par des objets CORBA, en
particulier pour la visualisation ou l'export des champs produits
par les opĂŠrations.
Elle a cependant des inconvĂŠnients et/ou limitations:
* Elle nĂŠcessite l'implĂŠmentation d'une classe proxy pour encapsuler tous
les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
se limite a priori aux opĂŠrations de champs (les opĂŠrations
algĂŠbriques dans un premier temps).
* Les champs Ă manipuler dans une opĂŠration donnĂŠe doivent ĂŞtre gĂŠrĂŠs
par la mĂŞme structure MED.
Il est Ă noter ĂŠgalement que les interfaces de programmation de
SALOMEMED (interface CORBA pour MEDMEM) devront ĂŞtre ĂŠtendues pour
permettre des requĂŞtes de manipulations de champs (fonctions addition,
soustraction, multiplication, ...). Pas de contrainte ici sur
l'ergonomie puisque la manipulation par l'utilisateur se fera au
niveau des classes proxy uniquement.
Hypothèses:
* On tente ici une maquette qui exploite dans la mesure du possible le
fonctionnement actuel du module MED, en particulier la gestion des
donnĂŠes dans l'ĂŠtude.
* Dans une deuxième version, on pourra examiner sÊrieusement la
rĂŠvision de la gestion des donnĂŠes dans le module, quitte Ă la
spĂŠcifier et maquetter dans XMED pour intĂŠgration ultĂŠrieure dans
MED. Exemple:
- Pouvoir gĂŠrer plusieurs structures med dans l'ĂŠtude.
* Enfin, on exploite MEDMEM en l'ĂŠtat. Pour les besoins de la gestion
des donnĂŠes (gestion des chargements des champs en particulier,
rĂŠfĂŠrences croisĂŠes pour retrouver le med Ă partir du champ par
exemple, ...), il pourra ĂŞtre nĂŠcessaire de faire ĂŠvoluer MEDMEM. Il
faut pouvoir par ailleurs gĂŠrer indiffĂŠremment une structure med (et
les champs qui y sont associĂŠs) qu'elle soit crĂŠĂŠe en mĂŠmoire from
scratch ou chargĂŠe d'un fichier (donc attention avec les opĂŠrations
de lecture read(), sur les maillages comme sur les champs). La
structure med permet d'obtenir les mĂŠta donnĂŠes (meta-field par
exemple) mais ne permet pas de savoir si les donnĂŠes sont
physiquement chargĂŠes ou pas.
RĂŠvisions:
* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
Première version qui permet d'importer un champ dans la console
python sous la forme d'un FieldProxy. Ne permet pas encore de faire
des opĂŠrations. Introduction dans le module MED de l'interface MEDOP
pour prendre en charge les opĂŠrations sur les champs.
20101019 : Maquette de dĂŠmonstration pour l'addition
----------------------------------------------------
Cette maquette implĂŠmente une solution technique de bout en bout (de
l'interface python aux objets MEDMEM, en passant par le fieldproxy
puis les servants CORBA pour les operations, ...) mais sur le
pÊrimètre de l'addition de champs sur tout leur domaine de dÊfinition
et pour un pas de temps donnĂŠ.
Limitations:
* gĂŠre l'addition de champs de type double uniquement (parceque le
reste n'est pas implĂŠmentĂŠ)
RĂŠvisions:
* XMED: svn rĂŠvision 25
* MED: cvs tag BR_medop_20101019
20101020: Fonctions complĂŠmentaires
-----------------------------------
Cette version test la faisabilitĂŠ des fonctions complĂŠmentaires pour
accompagner la manipulation de champs. Cela comprend en particulier:
* **la sauvegarde des champs produits** dans un fichier med (un champ ou
toute la structure med). Pour cela, on dĂŠfinit un med proxy comme
l'extention du SALOME_MED::MED (prĂŠvir plutĂ´t d'implĂŠmenter ce type
de fonction au niveau C++ pour permettre un usage au niveau du GUI
C++?).
* **la visualisation d'un champ** au moyen du module VISU.
* **des fonctions d'aide interactives** pour assister l'utilisateur
dans la console de manipulation des champs.
Questions:
* peut-on sauvegarder un champ unique?
* peut-on faire en sorte que ce soit l'affectation Ă une variable qui
provoque l'ajout du champ Ă la structure med (ou plus exactement qui
supprime tous les champs intermĂŠdiaires).
RĂŠvision:
* XMED: svn revision 31
* MED: cvs tag BR_medop_20101025
20110606: commit avant transfert dans git
-----------------------------------------
* XMED: svn revision 53
Les parties de MED utiles Ă MEDOP seront reversĂŠes dans XMED
dans une première Êtape, puis le tout dans MED 6 au final.