2 :keywords: maillage, champ, manipulation
3 :author: Guillaume Boulant
5 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
6 ANNEXE: Note de travail concernant le chantier XMED 2010
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
13 Principes directeurs du développement
14 =====================================
16 En matière de développement:
18 * On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
19 module SALOME diffusable dans la version d'exploitation 2010 (SALOME
20 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
21 devoir tenir compte des contraintes de temps SALOME et (ii) le
22 produit envisagé fin 2010 est une maquette qui cherche à éprouver
23 l'ergonomie générale d'utilisation et en aucun cas on ne peut
24 garantir la réalisation d'un module SALOME compatible avec les
25 exigences de mise en exploitation.
26 * On ne cherche pas d'emblée à capturer tous les cas d'application,
27 mais à concevoir un développement qui acceptera les extensions de
28 périmètres dans des conditions raisonnables. Aussi, les
29 fonctionnalités développées seront celles qui sont nécessaires à la
30 réalisation des cas d'application de référence;
32 En matière d'ergonomie:
34 * L'interface utilisateur de référence (appelé espace de travail dans
35 le volet de spécifications fonctionnelles) est l'interpréteur
36 python. Les fonctionnalités doivent être pensées pour un usage
37 adapté à une interface textuelle (TUI) de ce type.
38 * La création d'une interface graphique (GUI) peut être envisagée en
39 complément et comme un moyen de manipuler graphiquement les
40 fonctionnalités développées pour l'interface textuelle et pour aider
41 la préparation des variables dans l'interface python.
42 * Le modèle d'un processus de manipulation de champs est:
44 - Préparation du jeu de variables U, V, ... représentant les champs
45 à manipuler. C'est à ce stade que l'on résoud la question de
46 sélection des données (dans un champ publié dans l'arbre d'étude,
47 par un module de calcul ou par chargement d'un fichier med)
48 - Utilisation des variables avec une sémantique la plus proche
49 possible du modèle conceptuel et des spécifications
51 - Création des variables qui représentent les résultats des
52 fonctions de manipulation;
53 - Persistence (fichier med), visualisation (SALOME) ou export (vers
54 une structure qui peut être directement utilisable en numpy)
56 Sur le plan technique:
58 * On souhaite spécifier clairement le conteneur SALOME des fonctions
59 de manipulation de champs. Pour discussion:
61 - Il apparaît que les modules SALOME MED et VISU contiennent déjà
62 des fonctions qui peuvent faire partie des fonctions de
63 manipulations de champs (en particulier pour l'exploration des
64 structures MED, leur visualisation et la sélection des données à
66 - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
67 tout cas pas sous sa forme de module SALOME) et compte-tenu du
68 caractère obsolescent du module VISU (amené à être remplacé sur le
69 plan fonctionnel par le module PARAVIS), on pourrait examiner la
70 création d'un module dédié à la manipulation des maillages et des
71 champs par l'agrégation technique au sein d'un même module des
72 fonctions des modules MED et VISU.
74 Au moins dans un premier temps, on se donne les limites suivantes:
76 * Une opération ne peut pas combiner des pas de temps différents. Dans
77 l'hypothèse où cette limite venait à être levée, on doit spécifier
78 le pas de temps de la donnée résultat;
79 * Le domaine d'application d'une opération pourra être défini
80 exclusivement par la donnée d'un maillage ou un groupe d'éléments du
82 * On ne traite pas le cas des champs qui prennent leurs valeurs aux
83 points de gauss ou aux noeuds par élément. Une particularité de ces
84 types de support est que le repérage de la position implique deux
85 indices (par exemple l'indice de la maille, puis l'indice du point
88 Eléments de conception
89 ======================
94 On peut par exemple imaginer une maquette du genre:
96 * En C++ dans MEDGUI, charger un fichier med et donner une vue de la
97 structure des maillages et des champs dans l'arbre d'étude.
98 * Sélectionner un élément (par exemple un pas de temps d'un champ) et
99 le menu contextuel permet d'exporter ce champ dans la console python
100 pour manipulation. Pour cela, s'inspirer de la fonction
101 ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
103 * L'élément est marqué comme ayant été exporté, on peut imaginer une
104 récupération ultérieure.
105 * Exporter un deuxième champ cohérent avec le premier (même pas de
106 temps et défini sur le même maillage avec le même support, on
108 * Dans la console python, faire les opérations sur les champs
109 * Publication du champ résultat dans l'arbre d'étude pour sauvegarde
110 ultérieure. C'est a priori le gros morceau qui consiste à faire un
111 objet CORBA MED à partir d'un objet MED standard, en plus défini
112 dans la console python (sous forme d'objet python).
114 Quand ce premier cas d'utilisation est au point, on peut envisager de
115 le compléter par les opérations suivantes
117 * exporter le résultat med dans un fichier
118 * visualiser les champs produits
120 Plan de développement:
122 * Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
123 d'architecture, l'opération physique se déroulera en définitif au
124 niveau de MEDMEM pur.
125 * Prévoir une implémentation des opérations sous forme de fonctions
126 informatiques, même les opérations algébriques (+,-,*,/). Pour ces
127 dernières et dans certaines conditions (quand on manipule
128 directement les strutures MEDMEM et non pas les objets CORBA),
129 l'utilisation des formes A+B, A-B, ... peuvent être rendues
130 possibles. Dans ce cas, voir la possibilité de combiner plusieurs
131 opérations algébriques sur une seule ligne: A+B-C*0.3.
132 * On peut charger la structure MED sous forme d'objet CORBA publiable
133 dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
134 exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
135 récupère que les informations nécessaires au chargement d'un champs:
136 le nom du champs, le nom de son maillage associé, les identifiants
137 du pas de temps, au besoin une structure Field non chargée (par
138 exemple pour récupérer plus facilement le maillage).
139 * Un mécanisme (à développer à partir du PyConsole par exemple)
140 pourrait alors permettre le chargement des champs sélectionnés dans
141 la console python et sous un nom facile à manoeuvrer. Prendre
142 inspiration sur XCADGUI::LoadIntoPythonConsole().
143 * A priori, les données sont physiquement chargée dans le GUI. Au
144 besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
145 CORBA field à partir d'un field standard (à tester).
147 Une autre idée est de récupérer le pointeur CORBA MED dans la console
148 python et de tirer les données à partir de là. Ajouter une couche de
149 wrapping python pur pour gérer les cas de simplification (surcharge
150 des opérations arithmétiques par exemple).
152 Besoins complémentaires:
154 * L'interpréteur doit contenir des éléments d'aide (par exemple un
155 help qui liste les opérations possibles sur les champs chargés)
156 * prévoir quelques fonctions de visu et de persistence. Cela commence
157 probablement par des fonctions de publication dans l'étude des
158 champs créés par les opérations de manipulation. Les champs sont
159 physiquement ajouté automatiquement à la structure med par le MedOp
160 mais il n'est pas obligatoirement publié => fournir un moyen de
163 Limitations actuelles (liées à la conception de MEDMEM):
165 * les champs doivent être gérés par la même structure MED car ils
166 doivent partager le même support.
167 * les opérations possibles dans MEDMEM sont entre champs pris sur un
168 pas de temps (Q: les pas de temps peuvent-ils être différents).
174 Développement de classes proxy:
176 * FieldProxy, FieldTimeSeriesProxy
177 * Attention pour les éries temporelles, le SUPPORT med peut être
178 différent en chaque pas de temps (par exemple en cas d'extension
179 spatiale du champ au cours du temps).
181 MEDMEM_MedDataManager:
183 * FIX: test de l'implémentation C++ au travers de la fonction test() du
184 MedOperator ==> OK. Quand on fait la même opération depuis python
185 via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
186 destructeur du champ semble être appelé. Pb de gestion des pointeurs?
194 * FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
195 plusieurs fois de suite puisqu'on recycle la référence si elle est
197 * IMP: MEDMEM::MED faire une gestion des chargements des champs (par
198 exemple avec un getField qui renvoie le champ s'il est déjà chargé
199 ou le charge et le renvoie sinon).
200 * IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
201 passant a priori par le driver associé. Plusieurs driver peuvent
202 être associés à une structure MED car les données peuvent être
203 chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
204 étendre la structure MED pour avoir accés à la liste des driver puis
205 de cette liste déduire les noms des fichiers.
206 * IMP: Opérations combinant des champs sur des support différents ne
207 peuvent pas être faites par l'API (une exception est levée en cas de
208 supports incompatibles), mais on peut imaginer le faire en
209 manoeuvrant les tableaux de données directement.
210 * INF: faire le point sur les fonctions utilitaires autour de MEDMEM
211 et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
212 * IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
213 préalablement ajouté: une fonction removeField en complément de
216 Concernant l'interface SALOME_MED:
218 * IMP: Fonctions algébriques, qui seront implémentées au niveau de la
219 structure MED et requêtées au niveau des classes proxy en spécifiant
220 les identifiants des champs impliqués et les paramétres requis (pas
221 de temps en particulier).
223 Concernant le module MED:
225 * IMP: pourvoir exporter la structure med dans un fichier med (la
226 structure ayant pu être enrichie par la publication de champs créés
227 par les operations de champs.
230 Historique des travaux
231 ======================
233 20100726 : mise au point du schéma de conception
234 ------------------------------------------------
236 Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
239 * MED Coupling ne peut pas gérer des mailles de dimensions différentes
240 dans un même modèle (choix faits dans un soucis de performance dans
241 l'accès à une structure de donnée compact). On peut contourner le
242 problème en définissant deux champs pour traiter chacun des type de
244 * Un champ repose sur un maillage complet (pas de notion de profil,
245 mais cela peut être émulé en créant deux maillages)
246 * Le concept de point de gauss n'existe pas (pas implémenté)
250 * Idéalement, il conviendrait de faire un état des lieux du module
251 MED, en particulier des éléments MEDMEM (le coeur), les interfaces
252 CORBA associées (MED.idl implémenté dans le package source
253 MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
254 implémenté dans le package source MED) et le GUI (MedGUI.cxx
255 implémenté dans le package source MEDGUI).
257 * Ergonomie TUI et modèle CORBA associé:
259 1. Charger un objet medmem (puis les objets métier mesh et field)
260 sur un domaine d'application donné.
261 2. En faire des variables disponibles dans l'interface TUI et que
262 l'on peut manipuler dans des opérations algébriques.
263 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
264 les autres modules SALOME.
266 * Compléter le diagramme de la structure informatique de MED (en
267 particulier l'implémentation des interface IDL).
268 * Préparer un module de travail XMED (organisation d'une bibliothèque)
272 * Est-il possible de faire des opérations algébriques à partir des
273 objets SALOMEMED (objects CORBA MED)?
274 * Création d'un objet MED_i à partir d'une objet MED pur préalablement
279 * Des opérations de champs sont possibles sur des champs à des pas de
280 temps fixés. Si l'opération doit être menée sur plusieurs pas de
281 temps, alors itérer sur chaque pas de temps. L'idée ici est
282 d'introduire le concept de série temporelle de champs en temps
283 qu'objet manipulable.
284 * Pour deux champs différents de la même structure MED, la données des
285 identifiants dt et it ne correspond pas forcément au même instant
286 absolu (en tout cas rien ne le garanti, même si c'est tout de même
287 une pratique courante).
289 20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
290 --------------------------------------------------------------------------
292 XMED: svn révision 16
293 Travailler avec le fichier de donnée testfield.med joint.
296 20101007 : Vers une maquette CORBA
297 ----------------------------------
299 Le contexte d'utilisation des opérations de champs est l'environnement
300 SALOME. Le support de gestion des données est donc l'étude SALOME. Au
301 plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
302 session SALOME (soit par un code de calcul intégré, soit par
303 chargement des données à partir d'un fichier med). Ces objets sont en
304 général référencés dans l'étude SALOME sous la forme d'objets CORBA de
305 classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
306 SObject (Study Object) dont un attribut est une référence vers un
307 objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
310 On peut donc envisager une solution dans laquelle on donne à
311 l'utilisateur des poignées de manipulation des objets
312 SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
313 type proxy. Cela signifie que l'utilisateur ne manipule pas
314 directement des objets MEDMEM mais des objets python qui font
315 l'interface (à concevoir et implémenter, a priori avec un design
316 pattern de type proxy).
318 L'utilisation directe des objets MEDMEM aurait pu être une solution
319 extremement pratique dans la mesure où ces objets en l'état peuvent
320 être combinés dans des opérations de champs (c'est déjà
321 implémenté). Par contre, ce procédé souffre de limitations importantes
322 dans la gestion et la circulation des données pour les différents cas
323 d'utilisation envisagés (visualisation, export, transfert à un autre
326 L'avantage de la solution proposée est multiple:
328 * Elle permet de travailler sur une structure MED cohérente pour
329 intégrer les résultats des opérations de calculs et combiner des
330 champs cohérents entre eux. Tout passe par des classes proxy qui
331 pourront s'assurer de la cohérence des opérations demandées et
332 exécuter automatiquement les fonctions de pré-traitement ou
333 post-traitement requises pour ces opérations. On peut imaginer par
334 exemple que les requêtes d'opération soient envoyées par les classes
335 proxy à la structure MED à laquelle les champs sont associés pour
336 piloter l'opération en MEDMEM pur.
337 * Elle permet d'automatiser un certain nombre d'opérations
338 implicites. Par exemple si deux champs ne sont pas définis dans la
339 même unité, un changement d'unité peut être effectué automatiquement
340 par la classe proxy avant de commander l'opération au niveau
342 * Elle permet de laisser les données sur le container SALOME et de
343 réaliser des opérations sans rappatrier les données en local (qui
344 peuvent être en trés grand nombre).
345 * Elle permet d'étendre facilement l'ergonomie de manipulation des
346 champs, par exemple en définissant la notion de *série temporelle de
347 champs*, ou encore les concepts de *domaine de définition* évoqués
348 dans les spécifications fonctionnelles.
349 * Elle rend immédiat la circulation des données entre modules SALOME,
350 puisque les champs restent accessble par des objets CORBA, en
351 particulier pour la visualisation ou l'export des champs produits
354 Elle a cependant des inconvénients et/ou limitations:
356 * Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
357 les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
358 se limite a priori aux opérations de champs (les opérations
359 algébriques dans un premier temps).
360 * Les champs à manipuler dans une opération donnée doivent être gérés
361 par la même structure MED.
363 Il est à noter également que les interfaces de programmation de
364 SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
365 permettre des requêtes de manipulations de champs (fonctions addition,
366 soustraction, multiplication, ...). Pas de contrainte ici sur
367 l'ergonomie puisque la manipulation par l'utilisateur se fera au
368 niveau des classes proxy uniquement.
373 * On tente ici une maquette qui exploite dans la mesure du possible le
374 fonctionnement actuel du module MED, en particulier la gestion des
375 données dans l'étude.
376 * Dans une deuxième version, on pourra examiner sérieusement la
377 révision de la gestion des données dans le module, quitte à la
378 spécifier et maquetter dans XMED pour intégration ultérieure dans
381 - Pouvoir gérer plusieurs structures med dans l'étude.
383 * Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
384 des données (gestion des chargements des champs en particulier,
385 références croisées pour retrouver le med à partir du champ par
386 exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
387 faut pouvoir par ailleurs gérer indifféremment une structure med (et
388 les champs qui y sont associés) qu'elle soit créée en mémoire from
389 scratch ou chargée d'un fichier (donc attention avec les opérations
390 de lecture read(), sur les maillages comme sur les champs). La
391 structure med permet d'obtenir les méta données (meta-field par
392 exemple) mais ne permet pas de savoir si les données sont
393 physiquement chargées ou pas.
398 * XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
399 Première version qui permet d'importer un champ dans la console
400 python sous la forme d'un FieldProxy. Ne permet pas encore de faire
401 des opérations. Introduction dans le module MED de l'interface MEDOP
402 pour prendre en charge les opérations sur les champs.
405 20101019 : Maquette de démonstration pour l'addition
406 ----------------------------------------------------
408 Cette maquette implémente une solution technique de bout en bout (de
409 l'interface python aux objets MEDMEM, en passant par le fieldproxy
410 puis les servants CORBA pour les operations, ...) mais sur le
411 périmètre de l'addition de champs sur tout leur domaine de définition
412 et pour un pas de temps donné.
416 * gére l'addition de champs de type double uniquement (parceque le
417 reste n'est pas implémenté)
421 * XMED: svn révision 25
422 * MED: cvs tag BR_medop_20101019
425 20101020: Fonctions complémentaires
426 -----------------------------------
428 Cette version test la faisabilité des fonctions complémentaires pour
429 accompagner la manipulation de champs. Cela comprend en particulier:
431 * **la sauvegarde des champs produits** dans un fichier med (un champ ou
432 toute la structure med). Pour cela, on définit un med proxy comme
433 l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
434 de fonction au niveau C++ pour permettre un usage au niveau du GUI
436 * **la visualisation d'un champ** au moyen du module VISU.
437 * **des fonctions d'aide interactives** pour assister l'utilisateur
438 dans la console de manipulation des champs.
443 * peut-on sauvegarder un champ unique?
444 * peut-on faire en sorte que ce soit l'affectation à une variable qui
445 provoque l'ajout du champ à la structure med (ou plus exactement qui
446 supprime tous les champs intermédiaires).
451 * XMED: svn revision 31
452 * MED: cvs tag BR_medop_20101025
455 20110606: commit avant transfert dans git
456 -----------------------------------------
458 * XMED: svn revision 53
460 Les parties de MED utiles à MEDOP seront reversées dans XMED
461 dans une première étape, puis le tout dans MED 6 au final.
