2 :keywords: maillage, champ, manipulation
3 :author: Guillaume Boulant
5 .. include:: medop-definitions.rst
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
8 ANNEXE: Note de travail concernant le chantier XMED 2011
9 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
11 .. contents:: Sommaire
15 Cas d'utilisation métier
16 ========================
18 On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
20 J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
21 ajouter de nouveaux champs issus de champs existants. J'aimerais
22 aussi pouvoir créer de nouveaux meds plus petits par extraction de
23 certaines composantes de champs, certains groupes ou certains pas de
26 On peut exprimer le besoin sous la forme des cas d'utilisation
29 * **UC1: combiner dans un même fichier med des champs issus de
30 plusieurs sources de données**. On peut par exemple charger un
31 premier fichier, puis ajouter à cette base des champs issus d'autre
32 fichiers ou générés par manipulation de champs, ou encore générés
33 par un module de calcul qui produirait directement du MEDCoupling.
34 * **UC2: créer un champ contenant certaines composantes d'un autre
35 champ**. On pense ici aux fonctions de restriction, qui permettraient
36 de récupérer certaines composantes uniquement.
37 * **UC3: créer un champ contenant certains pas de temps d'un autre
38 champ**. C'est un cas particulier des fonctions de restriction
40 * **UC4: créer un champ comme la limitation d'un autre champ à un
41 groupe de mailles**. C'est un cas particulier des fonctions de
42 restriction évoquées ci-dessus. Notion de domaine spatial. A
43 priori la notion de groupe est définie dans MEDLoader.
45 On peut ajouter également les UC identifiés pour la maquette 2010:
47 * **UC5: comparer des champs issus de source de données différentes**,
48 par exemple des champs chargés de deux fichiers med différents et
49 qui s'appuient sur le même maillage (au moins conceptuellement). Le
50 problème technique ici est de pouvoir changer le maillage d'un
51 champ, pour ramener tous les champs sur le même maillage (au sens
52 informatique). Ceci est une contrainte de MEDCoupling, les
53 opérations sur des champs A et B imposent que A et B soient définis
54 sur le même maillage, i.e. le même objet informatique.
55 * **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
56 de mailles. Ce cas d'usage est typiquement prévu pour produire les
57 conditions de chargement initial d'une structure. Il s'agit ici
58 d'initialiser un champ à partir de zéro sur une surface prédéfinie
59 de la géométrie (par exemple spécifiée par un nom de groupe de
62 Pour UC5: les sources de données sont référencées dans l'object
63 browser. On importe explicitement les données dans l'espace de
64 travail. On peut détecter que les maillages sont identiques et on
65 propose à l'utilisateur de transférer le champ sur le maillage déjà
66 présent. Sinon, les champs devront être référencés sur des maillages
67 distincts dans l'arbre de l'espace de travail.
69 Analyses préliminaires pour le chantier 2011
70 ============================================
72 On fait le choix pour le chantier 2011 de travailler à partir de la
73 bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
74 le démonstrateur 2011).
76 Analyse de MEDCoupling et MEDLoader
77 -----------------------------------
79 MEDCoupling est l'implémentation du modèle de données MED (avec
80 recherche de minimisation des dépendances logicielles) et MEDLoader
81 fournit une ensemble de fonctions pour le chargement des structures
82 MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
85 Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
86 d'une grandeur physique sur un maillage pour un pas de temps donné. Un
87 champ est caractérisé par:
89 * un support spatial, le maillage
90 * un type de discrétisation spatial, défini par l'emplacement des
91 valeurs sur le maillage (sur les noeuds, sur les cellules, aux
92 points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
94 * un pas de temps, défini par deux entiers (iteration, order) et un
97 Dans cette implémentation, il existe une association 1..n entre un
98 maillage et un champ (alors que dans MEDMEM, la structure
99 intermédiaire SUPPORT est implémentée).
101 MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
102 des structures MEDCoupling au travers du bus CORBA. L'interface à ce
103 jour est délibérément réduite. Des classes dites "Cliente" sont
104 fournies pour piloter les servants CORBA depuis un contexte
105 client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
106 fonction de création d'une structure MEDCoupling à partir d'un
107 pointeur vers un servant CORBA. La structure est créée localement
108 (dans le contexte client) avec duplication des données issue de la
109 structure encapsulée par le servant CORBA (récupération par la
110 fonction de sérialisation).
112 Aucune interface CORBA n'est défini pour MEDLoader.
116 * Voir comment sont créés les servants, et surtout comment ils sont
117 récupérés (via le lcc?)
118 * Comment peut-on définir un champ sur un groupe de mailles (et non
119 pas sur le maillage complet)? Comment peut-on extraire le champs
120 circoncit à une groupe de mailles pour des opérations.
122 - R: méthode changeUnderlyingMesh
124 * Comment manipuler deux champs chargées de fichiers différents mais
125 construit sur le même maillage (conceptuellement). On peut forcer la
126 réassociation d'un champ sur un autre maillage?
127 * Manipuler des champs de pas de temps différents? Différentes
128 composantes d'un ou plusieurs champs?
129 * Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
131 * mapper sur une image
135 * MEDLoader::Write should raise an exception if the filepath is not writable
136 * MEDDataManager: développer une classe chapeau sur MEDCoupling et
137 MEDLoader pour aider au chargement et la gestion de données MED
138 (orienté manipulation de champs). Cette classe serait associée des
139 structures légères FieldHandler et MeshHandler et des listes
140 correspondantes pour la navigation dans les méta-données.
141 * Sur base du MEDDataManager, prévoir des ports med pour yacs par
142 lesquels pourrait transiter des handler.
144 Nouveaux concepts à prendre en compte
145 -------------------------------------
147 Au démarrage du chantier 2011, on observe que les concepts suivants
148 sont introduits dans le module MED:
150 * Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
151 les fichiers med et obtenir les informations générales sur le
153 * MEDFILEBROWSER: remplace le concept de driver et fournit les
154 fonctions précédemment fournies par la classe MED pour obtenir les
155 informations de structure.
156 * Concept d'Extractor pour une lecture sélective des données de champs
157 (suivant un critère d'extraction)
158 * Il n'est plus nécessaire d'appeler les méthodes read explicitement
159 sur les objets (MESH et FIELD) pour charger les données. Par
160 ailleurs, on peut définir deux fois le même champs (double
161 chargement a priori) sans lever d'exception).
164 Analyse de conception pour le chantier 2011
165 ===========================================
167 Composants SALOME (interfaces IDL)
168 ----------------------------------
170 * MEDDataManager: défini une structure FIELD pour identifier un champ
171 dans les requêtes. Il s'occupe également de la récupération physique
172 des données, quelqu'en soit la source (fichier avec MEDLoader, autre
173 module SALOME comme PARAVIS avec une méthode à définir)
174 * MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
175 les structures FIELD du MEDDataManager. Reprendre l'interface de
178 Use case à réaliser depuis un client python:
180 * UC01: ajouter un fichier d'entrée et accéder aux informations
181 concernant les champs. Ex: récupérer une structure champs par la
182 donnée des paramètres primaires (nom identifiant, dt, it, nom du
184 * UC02: créer des champs et les ajouter au MEDDataManager
185 * UC03: mener des opérations basique sur les champs en console python
187 Interface Utilisateur
188 ---------------------
190 L'interface utilisateur est composée des parties suivantes:
192 * une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
193 le chargement des données dans l'espace de travail, au moyen d'une
195 * une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
196 la création de champs, au moyen de commandes exécutées dans la
199 Le principe est que les champs sont préalablement chargés au niveau du
200 composant SALOME au moyen de l'interface graphique (MEDGUI), puis
201 manoeuvrés depuis l'application SALOME au moyen de variables proxy
202 définies dans la console python (MEDTUI). Au chargement, les champs
203 sont indéxés par le MEDDataManager, puis les index sont rendus
204 accessibles au niveau du GUI au moyen d'une représentation
205 arborescente de la structure MED. Les feuilles de l'arbre
206 correspondent à des champs qui peuvent être sélectionnés et dont
207 l'index peut être obtenu de la sélection.
209 L'espace de travail est organisé autour du concept de
210 "workspace". L'étude SALOME liste les datasource (les fichiers source
211 des données med, mais peut-être aussi les référence vers des objets
212 MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
213 permet de voir la structure fine d'une source de données.
217 * la représentation des données (les champs et les maillages associés)
218 doit permettre de récupérer par l'interface graphique les
219 identifiants des champs à manipuler (a priori les structures FIELD
220 définies par le composant MEDDataManager). Cela conduit à la mise en
221 place des composants suivants:
223 - MedDataModel hérité de TreeData. Il est peuplé avec les
224 méta-données décrivant la structure MED explorée.
225 - MedGuiManager qui permet l'implantation du doc widget de
230 * specifier le concept de workspace (qui a une entrée dans l'étude?)
231 en bijection avec un datamanager
232 * identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
236 * Il fournit les classes FieldProxy
240 * Comment traiter le cas du travail sur des composantes ciblées, plus
241 généralement, comment introduire le concept de domaine
243 * Prévoir des fonctions génériques (initialisation d'un champ sur un
244 maillage avec une fonction analytique de la position, sauvegarder
245 les champs créés dans un fichier med)
248 Tâches de développement
249 =======================
251 T20110622.1: Gestion des données internes
252 -----------------------------------------
255 Suite: fonction de sauvegarde au niveau graphique également
257 On vise les cas d'utiliation suivants:
259 * UC1: intégrer dans le datamodel du gui un champ créé dans la console
260 python (et donc présent dans le datamanager du composant). Définir
262 * UC2: renommer un champ et plus généralement changer ses méta-données
263 (avec assurance de synchronisation entre toutes les données).
264 * UC3: sauvegarder une sélection de champs. La sélection peut se faire
265 dans l'arbre du datamodel gui.
267 WARN: robustesse de fieldproxy
271 T20110622.2: UC Initialisation/Création de champs
272 -------------------------------------------------
276 Les cas implémentés à ce jour sont la création de champs à partir de
277 champs existants et chargés d'un fichier med. On souhaite ici réaliser
278 des cas 'utilisation autour de la création de champs "from scratch",
279 s'appuyant tout de même sur un maillage chargé.
281 UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
282 champ (par exemple les conditions limites d'un problème de calcul).
284 UC02: créer un champ avec des restrictions qui définissent le domaine
285 d'application des opération de champs.
287 UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
288 composantes du champs vectoriel ou niveaux de gris pour un champ
289 scalaire. Attention, pour ça, il faudra a priori fiare une projection
290 du maillage cartesien de l'image sur le maillage (quelconque) sur
291 lequel on souhaite définir le champ.
293 UC04: créer un champ à partir d'un tableau numpy
295 De manière générale, ce type de création sera assisté par le
296 MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
299 Par exemple, prévoir un menu contextuel qui propose les opérations
300 possibles en fonction de la sélection (en plus de la fonction d'import
301 dans la console python).
305 * développer les fonctions d'initialisation, par exemple au moyen
306 d'applyFunc et du mécanisme de callable?
308 T20110622.3: documentation contextuel
309 -------------------------------------
313 * Remettre toutes les commandes dans le même fichier (fusionner cmdtools
315 * Faire un modèle générique de command (classe de base
316 * Batir la doc des commandes sur cette base (lister toutes les
317 instances de type Command par exemple)
319 T20110622.4: remontée des exception du composant MEDCalculator
320 --------------------------------------------------------------
322 **Status: en cours, compléter la couverture**
324 Pour des messages contextuel sur les erreurs de calcul (ex: division
327 * Poursuivre le travail fait sur getMedEventListener
328 * Protéger tous les appels au composants effectués depuis la console
329 python (prendre example sur la commande save)
331 T20110624.1: gestion des données GUI
332 ------------------------------------
338 Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
340 * supprimer: supprime tout les champs associés
341 * sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
342 cocher ceux qu'on veut sauvegarder.
344 Le gui data model est réservé aux opérations sur les champs et à
345 piloter leur import dans la console python.
349 * Spécifier les concepts de workspace, database, et datasource, espace
350 de gestion, ... et les associations. Simplifier avec l'appuie de use
352 * Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
353 l'ajout addChild est implémenté
354 * Clic droit sur objets de l'arbre: dans la notification TreeView ->
355 WorkspaceController, faire remonter l'évènement clic droit ainsi que la
356 liste des éléments sélectionné pour faire générer le menu contextuel
357 au niveau du WorkspaceController qui peut déterminer le contexte métier
358 (le TreeView ne le connaît pas).
359 * Définir des DataObject pour les maillages, les séries temporelles et
363 Spécification des espaces de données:
365 * MEDDataManager dépend de l'étude (pour permettre la publication
366 d'information dans une étude SALOME).
367 * créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
368 requetes getFields(sourceid), getMeshes(sourceid)
369 * les espaces de données: dataspace, workspace. Un seul workspace par
370 étude, mais autand de datasources que l'on souhaite dans le
371 dataspace. Les datasources sont rangés dans l'étude (le dataspace)
372 et sont non modifiables après chargement (référence des sources de
376 T20110628.1: extention à d'autres objets SALOME
377 -----------------------------------------------
381 On doit reposer la question de l'existance de l'arbre indépendant
382 (DockWidget), d'une part, et l'extention aux autres objets (GEOM et
383 SMESH en particulier) du principe de sélection graphique pour
384 utilisation dans la console python, d'autre part.
387 T20110628.2: visualisation d'un champ avec PARAVIS
388 --------------------------------------------------
390 **Status: terminé (pour une première version)**
391 Suite: de nombreux défauts subsistent
395 * Pb au démarrage du module: VisTrails fails to start
396 * Peux-t-on piloter la vue 3D sans charger le module? (voir
398 * Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
399 * Comment utiliser directement les objets MEDCouplingField?
402 T20110706.1: documentation du module
403 ------------------------------------
405 **Status: en cours (10%)**
407 Documenter les commandes TUI puis l'utilisation générale de
408 l'interafce graphique. Mentionner l'existance de la commande medop.sh
409 pour travailler exclusivement en mode texte (utile pour les tests
412 Documenter les modalités d'exécution des tests.
414 T20110708.1: helper python pour MEDCoupling
415 -------------------------------------------
417 **Status: en attente (pas urgent)**
419 Faire un helper python dans le package xmed qui permet de faire du
420 medcoupling facilement (essentiellement pour simplifier le chargement,
421 puis la sélection des données). Cela demanderait de faire un
422 MedDataManager comme une class C++ pure (non CORBA). Cette classe
423 travaillerait par exemple uniquement avec des id et des liste d'id, et
424 fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
425 pour obtenir des meta-information.
427 Le servant MedDataManager pourrait être une surcouche de cette classe
430 T20110708.2: analyses et tests
431 ------------------------------
435 * créer un fichier de test avec plusieurs pas de temps
436 * créer un fichier de test avec des groupes de mailles
439 T20110728.1: refactoring MEDDataManager
440 ---------------------------------------
442 Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
444 * dans la mesure du possible utiliser les id plutôt que les handler en
445 arguments des fonctions d'appel des objets
446 * A chaque champ (FieldHandler), on doit associer un meshid (et de
447 manière optionnelle un fieldseriesId, si le champ peut être associé
448 à une serie temporelle. A priori faisable uniquement au chargement
450 * Pour cela, revoir les fonctions internes newFieldHandler et addField
451 ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
452 les informations concernant le meshid.
453 * addField est utilisée par le MEDCalculator
454 * Attention au raffraichissement des données handler au niveau du
455 Workspace. Peut-être le mieux est que les fieldproxy contiennent
456 uniquement le fieldid, et qu'ils interroge le datamanager à chaque
457 fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
458 via le MEDEventListener? **Le plus simple est de faire la mise à
459 jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
460 on essaye d'afficher les données**. Parceque sinon il n'y a pas de
461 problème puisque que le calculateur travaille à partir des id.
464 Petites améliorations du DataspaceController:
466 * Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
467 l'alias python dans un attribut du sobject.
468 * Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
469 est posé dans le WS. On peut donc proposer en option de lui associer
470 un alias pour manipulation dans la console
