Salome HOME
Typo and whitespace fixes by Kunda
[modules/med.git] / doc / dev / sphinx / fr / medcalc-userguide-gui.rst
1 .. meta::
2    :keywords: maillage, champ, manipulation, guide utilisateur
3    :author: Guillaume Boulant
4
5 .. include:: medcalc-definitions.rst
6
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
8 Module MED: Guide d'utilisation de l'interface graphique
9 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
10
11 Ce document est un guide rapide pour l'utilisation de l'interface
12 graphique du module MED. Il montre comment utiliser le module sur la
13 base de quelques exemples de référence, inspirés des cas d'utilisation
14 identifiés lors de l'analyse des besoins en matière de manipulation de
15 champs.
16
17 .. warning:: Le document est autonome, mais il est vivement conseillé
18    de parcourir au préalable (ou en parallèle) :doc:`le document de
19    spécifications<medcalc-specifications>`, au moins pour fixer les
20    concepts et la terminologie.
21
22 .. contents:: Sommaire
23    :local:
24    :backlinks: none
25
26 Présentation générale du module MED
27 ===================================
28
29 L'ergonomie générale d'utilisation du module de manipulation de champs
30 est inspirée des logiciels comme octave ou scilab. Elle associe une
31 interface graphique, pour sélectionner et préparer les données, avec
32 une interface texte (la console python) pour le travail effectif sur
33 les données.
34
35 Pour cela, le module propose deux espaces utilisateurs qui sont
36 symbolisés par les rectangles rouges et vert sur la capture d'écran
37 ci-dessous:
38
39 * **l'espace des données** (*dataspace*), dans lequel l'utilisateur
40   définit les sources de données med (*datasource*), c'est-à-dire les
41   fichiers med dans lesquels sont lus les champs et maillages. Cet
42   espace permet l'exploration des maillages et des champs fournis par
43   les différentes sources de données.
44 * **l'espace de travail** (*workspace*), dans lequel l'utilisateur
45   peut déposer des champs sélectionnées dans l'espace source, pour
46   ensuite les travailler par exemple pour produire des nouveaux champs
47   au moyen des fonctions de manipulation fournies par l'interface
48   textuelle (console python TUI).
49
50 .. image:: ../images/xmed-gui-withframe.png
51    :align: center
52
53 L'utilisation type des fonctions de manipulation de champs suit un
54 processus de la forme suivante:
55
56 1. Chargement d'un fichier med dans l'espace de données (dataspace) et
57    exploration du contenu, composé de maillages et de champs définis
58    sur ces maillages et pouvant contenir un ou plusieurs pas de temps.
59 2. Sélection (graphique) des champs à manipuler dans l'espace de
60    travail (workspace), avec la possibilité de préciser des
61    restrictions d'utilisation (pas de temps, composantes, groupe de
62    maille).
63 3. Création de nouveaux champs par l'exécution d'opérations
64    algébriques (+,-,*,/) entre champs, l'application de fonctions
65    mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
66    "from scratch" sur un maillage support.
67 4. Contrôle visuel rapide des champs produits (avec les modules VISU
68    et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
69    utilisateur)
70 5. Enregistrement d'une partie des champs produits dans un fichier med
71
72
73 Tour rapide des fonctions du module MED
74 =======================================
75
76 Cette section présente des exemples d'utilisation du module XMED sous
77 la forme de "storyboard", et illustre au passage les fonctions mises à
78 disposition par le module.
79
80 .. warning:: Cette section est en travaux. Tant que cet avis n'aura
81    pas disparu, veuillez en considérer le plan et le contenu encore
82    incomplets, temporaires et sujets à caution.
83
84 Exemple 1: Explorer des sources de données
85 ------------------------------------------
86
87 .. note:: Cet exemple présente les fonctions:
88
89    * ajouter une source de données
90    * fonctions "Extends field series", "Visualize"
91
92 .. |ICO_DATASOURCE_ADD| image:: ../images/ico_datasource_add.png
93                         :height: 16px
94
95 .. |ICO_XMED| image:: ../images/ico_xmed.png
96               :height: 16px
97
98 .. |ICO_DATASOURCE_EXPAND| image:: ../images/ico_datasource_expandfield.png
99                            :height: 16px
100
101 .. |ICO_DATASOURCE_VIEW| image:: ../images/ico_datasource_view.png
102                          :height: 16px
103
104 Au démarrage, le module de manipulation de champs, identifié par
105 l'icône |ICO_XMED|, présente une interface vierge:
106
107 .. image:: ../images/xmed-gui-start.png
108    :align: center
109    :width: 800px
110
111 La première étape consiste à ajouter une ou plusieurs source de
112 données med dans le "dataspace". Pour cela, on clique sur l'icône "Add
113 datasource" |ICO_DATASOURCE_ADD| qui propose de sélectionner un
114 fichier med:
115
116 .. image:: ../images/xmed-gui-datasource-selectfile.png
117    :align: center
118    :width: 800px
119
120 L'opération ajoute une nouvelle entrée (datasource) dans l'espace de
121 données (dataspace). Le contenu peut être exploré en parcourant
122 l'arborescence. La figure ci-dessous (image de gauche) montre le
123 résultat du chargement du fichier ``timeseries.med`` contenant un
124 maillage de nom ``Grid_80x80`` sur lequel est défini un champ au noeud
125 de nom ``Pulse``. Par défaut, la composition du champs (en terme de
126 pas de temps et de composantes) n'est pas affichée pour éviter
127 l'encombrement visuel de l'arbre. On doit faire la demande explicite
128 au moyen de la commande "Expand field timeseries"
129 |ICO_DATASOURCE_EXPAND| disponible dans le menu contextuel associé aux
130 champs. Le résultat est affiché sur l'image centrale. La liste des
131 itérations du champ ``Pulse`` peut être consultée.
132
133 .. |IMG_DATASOURCE_EXPLORE| image:: ../images/xmed-gui-datasource-explore-zoom.png
134                             :height: 340px
135 .. |IMG_DATASOURCE_MENUCON| image:: ../images/xmed-gui-datasource-menucontextuel-zoom.png
136                             :height: 340px
137 .. |IMG_DATASOURCE_EXPANDF| image:: ../images/xmed-gui-datasource-expand-zoom.png
138                             :height: 340px
139
140 +--------------------------+--------------------------+--------------------------+
141 | |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
142 +--------------------------+--------------------------+--------------------------+
143
144 .. note:: En toute rigueur, le concept de *champ* dans le modèle MED
145    désigne une itération donnée. Un ensemble d'itérations est désigné
146    par le terme *série temporelle de champs*. Par abus de langage, et
147    s'il n'y a pas ambiguité, on utilisera le nom du champ pour
148    désigner à la fois le champs proprement dit ou la série temporelle
149    à laquelle il appartient.
150
151 Enfin, il est possible au niveau du dataspace de visualiser la forme
152 générale du champ au moyen d'une carte scalaire affichée dans le
153 viewer de SALOME. Pour cela, on sélectionne le pas de temps à
154 visualiser et on utilise la commande "Visualize" |ICO_DATASOURCE_VIEW|
155 disponible dans le menu contextuel associé:
156
157 .. image:: ../images/xmed-gui-datasource-visualize-zoom.png
158    :align: center
159    :width: 800px
160
161 .. note:: Cette représentation graphique a pour objectif le contrôle
162    visuel rapide. Aussi, les fonctions du module VISU sont employées
163    par défaut, mais il est possible de faire l'affichage des cartes
164    scalaires au moyen du module PARAVIS (choix de préférence non
165    implémenté pour le moment, mais techniquement réalisable).
166
167 Exemple 2: Rassembler des champs issus de différentes sources
168 -------------------------------------------------------------
169
170 .. note:: Cet exemple présente les fonctions:
171
172    * fonction "Use in workspace"
173    * fonction "Save"
174
175 .. |ICO_DATASOURCE_USE| image:: ../images/ico_datasource_use.png
176                         :height: 16px
177 .. |ICO_WORKSPACE_SAVE| image:: ../images/ico_workspace_save.png
178                         :height: 16px
179
180 L'objectif est de récupérer des données issues de différents fichiers
181 med, puis de les rassembler dans un même fichier en sortie.
182
183 On commence par ajouter les sources de données med dans l'espace de
184 données (dataspace). Dans l'exemple ci-dessous, l'espace de données
185 contient deux sources de nom ``parametric_01.med`` et
186 ``smallmesh_varfiled.med``. La première source contient le maillage
187 ``Grid_80x80_01`` sur lequel est défini le champ ``StiffExp_01``. La
188 deuxième source contient le maillage ``My2DMesh`` sur lequel sont
189 définis deux champs de noms respectifs ``testfield1`` et
190 ``testfield2``:
191
192 .. image:: ../images/xmed-userguide-example2-datasource.png
193    :align: center
194    :width: 800px
195
196 Pour l'exemple, on souhaite rassembler les champs ``StiffExp_01`` et
197 ``testfield2`` dans un fichier de nom ``result.med``. La procédure
198 consiste à importer les deux champs dans l'espace de travail
199 (workspace), puis à sauvegarder l'espace de travail. Pour cela, on
200 sélectionne les champs et on utilise la commande "Use in workspace"
201 |ICO_DATASOURCE_USE| disponible dans le menu contextuel. Les deux
202 champs sélectionnés apparaissent dans l'arborescence de l'espace de
203 travail:
204
205 .. image:: ../images/xmed-userguide-example2-workspace.png
206    :align: center
207    :width: 800px
208
209 La sauvegarde de l'espace de travail est faite au moyen de la commande
210 "Save workspace" |ICO_WORKSPACE_SAVE| disponible dans la barre
211 d'outils du module. Une fenêtre de dialogue invite l'utilisateur à
212 spécifier le nom du fichier de sauvegarde:
213
214 .. image:: ../images/xmed-userguide-example2-workspace-save.png
215    :align: center
216    :width: 800px
217
218 Ce fichier ``result.med`` peut ensuite être rechargé dans le module
219 XMED (ou les modules VISU ou PARAVIS) pour vérifier la présence des
220 champs sauvegardés.
221
222 .. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
223 .. (invalid mesh on field)
224
225 .. _xmed.userguide.exemple3-fr:
226
227 Exemple 3: Appliquer une opération mathématique sur des champs
228 --------------------------------------------------------------
229
230 .. note:: Cet exemple présente les fonctions:
231
232    * exécution d'opérations mathématiques dans la console TUI
233    * fonction "put" pour référencer un champ de travail dans la liste
234      des champs persistant.
235    * fonction "Visualize" depuis le TUI.
236
237 L'usage le plus courant du module de manipulation de champs est
238 d'exécuter des opérations mathématiques dont les opérandes sont des
239 champs ou des composantes de ces champs.
240
241 On se place dans une situation où les sources de données sont définies
242 dans le "dataspace" (dans l'exemple ci-après, une série temporelle de
243 nom ``Pulse``, contenant 10 pas de temps, définis sur un maillage de
244 nom ``Grid_80x80``, le tout issu du datasource ``timeseries.med``).
245
246 Comme vu précedemment, pour manoeuvrer un champ dans l'espace de
247 travail, on sélectionne ce champ, puis on exécute la commande "Use in
248 workspace" |ICO_DATASOURCE_USE| du menu contextuel. Dans le cas
249 présent, un seul champ est sélectionné (contre deux dans l'exemple
250 précédent) et la commande ouvre alors une fenêtre de dialogue qui
251 permet de préciser les données sur lesquelles on souhaite
252 effectivement travailler et comment on veut les manoeuvrer:
253
254 .. image:: ../images/xmed-gui-datasource-useinworkspace-alias.png
255    :align: center
256    :width: 800px
257
258 .. note:: En l'état actuel du développement, l'interface propose
259    uniquement de définir le nom de la variable sous laquelle doit être
260    manoeuvré le champ dans la console de travail (TUI). Dans une
261    version ultérieure, il est prévue de pouvoir préciser la ou les
262    composante du champs à utiliser et un groupe de maille pour définir
263    une restriction géométrique. Inversement, il sera également
264    possible de choisir une série temporelle complète pour faire des
265    opérations globales sur l'ensemble des pas de temps.
266
267 Aprés validation, le champ est placé dans l'arborescence du
268 "workspace" et une variable de nom ``<alias>`` est créée
269 automatiquement dans la console de travail pour désigner le
270 champ. Dans cet exemple, ``<alias>`` vaut ``f3``, positionné ainsi par
271 l'utilisateur pour rappeler que la variable correspond au pas de temps
272 n°3:
273
274 .. image:: ../images/xmed-gui-workspace.png
275    :align: center
276    :width: 800px
277
278 La manipulation peut commencer. Dans l'exemple ci-dessous, on crée le
279 champ ``r`` comme le résultat d'une transformation afine du champ
280 ``f3`` (multiplication du champ par le facteur 2.7 auquel on ajoute
281 l'offset 5.2)::
282
283  >>> r=2.7*f3+5.2
284
285 On peut poursuivre la manipulation du champs avec une variété
286 d'opérations qui sont détaillées dans les spécifications du module
287 (cf. :ref:`Spécification des opérations<xmed-specifications>`):
288
289  >>> r=f3/1000     # les valeurs de r sont celles du champ f3 réduites d'un facteur 1000
290  >>> r=1/f3        # les valeurs de r sont les inverses des valeurs de f3
291  >>> r=f3*f3       # les valeurs de r sont celles du champ f3 élevées au carré
292  >>> r=pow(f3,2)   # même résultat
293  >>> r=abs(f3)     # valeur absolue du champ f3
294  >>> ...
295
296 Les opérations peuvent utiliser plusieurs opérandes de type champs. Si
297 ``f4`` désigne le pas de temps n°4 du champ ``Pulse``, alors on peut
298 calculer toute combinaison algébrique des deux champs::
299
300  >>> r=f3+f4
301  >>> r=f3-f4
302  >>> r=f3/f4
303  >>> r=f3*f4
304
305 Avec au besoin l'utilisation de variables scalaires::
306
307  >>> r=4*f3-f4/1000
308  >>> ...
309
310 Dans ces exemples, la variable ``r`` désigne un champ de travail qui
311 contient le résultat de l'opération. Par défaut, ce champ de travail
312 n'est pas référencé dans l'arborescence du workspace. Si on souhaite
313 tout de même le référencer, par exemple pour qu'il soit pris en compte
314 dans la sauvegarde, alors on tape la commande::
315
316  >>> put(r)
317
318 La fonction ``put`` a pour but de marquer le champ en argument comme
319 persistent, puis de le ranger dans l'arborescence du "workspace" afin
320 qu'il soit visible et sélectionnable. En effet, parmi tous les champs
321 qui pourront être créés dans la console pendant la session de travail,
322 tous n'ont pas besoin d'être sauvegardés. Certains sont même des
323 variables temporaires qui servent à la construction des champs
324 résultats finaux. C'est pourquoi, seuls les champs rangés dans
325 l'arborescence du workspace sont enregistrés lors de la demande de
326 sauvegarde du workspace.
327
328 Les variables définies dans la console ont d'autres utilités. Tout
329 d'abord, elles permettent d'imprimer les informations concernant le
330 champ manoeuvré. Pour cela, on tape simplement le nom de la variable
331 puis retour::
332
333  >>> f3
334  field name (id)         = Pulse (3)
335  mesh name (id)          = Grid_80x80 (0)
336  discretization          = ON_NODES
337  (iter, order)           = (3,-1)
338  data source             = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
339
340 Elle peut également être utilisée comme argument des commandes de
341 gestion disponibles dans l'interface textuelle (dont la liste
342 détaillée est décrite à la section :ref:`Documentation de l'interface
343 textuelle<xmed.userguide.tui-fr>`). Par exemple, la fonction ``view``
344 permet d'afficher la carte scalaire du champ dans le viewer::
345
346  >>> view(f3)
347
348 Donne:
349
350 .. image:: ../images/xmed-gui-workspace-view.png
351    :align: center
352    :width: 800px
353
354 .. note:: On remarquera ici qu'il est facile de comparer deux pas de
355    temps d'un champ, par exemple en calculant la différence ``f3-f4``,
356    puis en affichant un aperçu de la carte scalaire résultat au moyen
357    de la fonction ``view``::
358
359     >>> view(f3-f4)
360
361 On peut enfin tout simplement afficher les données du champs par la
362 commande ``print``::
363
364  >>> print f3
365  Data content :
366  Tuple #0 : -0.6
367  Tuple #1 : -0.1
368  Tuple #2 : 0.4
369  Tuple #3 : -0.1
370  Tuple #4 : 0.4
371  ...
372  Tuple #6556 : 3.5
373  Tuple #6557 : 3.3
374  Tuple #6558 : 1.5
375  Tuple #6559 : 0.3
376  Tuple #6560 : 0.2
377
378 Il est important de noter que les opérations entre champs ne peuvent
379 être faites qu'entre champs définis sur le même maillage. Il s'agit là
380 d'une spécification du modèle MED qui interdit d'envisager les
381 opérations entre champs définis sur des maillages géométriquement
382 différents. Techniquement, cela se traduit par l'obligation pour les
383 objets informatique *champs* de partager le même objet informatique
384 *maillage*.
385
386 Dans l'hypothèse où on souhaite utiliser des champs définis sur des
387 maillages différents, par exemple pour manoeuvrer les valeurs des
388 champs à l'interface de deux maillages partageant une zone géométrique
389 2D, il faut d'abord ramener tous les champs sur le même maillage de
390 surface par une opération de projection.
391
392 .. note:: Même si ceci est techniquement possible avec la bibliothèque
393    MEDCoupling, cet type d'opération de projection n'est pas encore
394    disponible dans le module de manipulation de champs (prévu en
395    2012).
396
397 Un autre besoin plus classique est l'utilisation de champs définis sur
398 des maillages géométriquement identiques, mais techniquement
399 différents, par exemple lorsqu'ils sont chargés de fichiers med
400 différents. Pour traiter ce cas de figure, la bibliothèque MEDCoupling
401 prévoit une fonction de "Changement du maillage support", dont
402 l'utilisation au niveau du module de manipulation de champs est
403 illustrée dans :ref:`l'exemple 4<xmed.userguide.exemple4-fr>` ci-après.
404
405 .. _xmed.userguide.exemple4-fr:
406
407 Exemple 4: Comparer des champs issues de différentes sources
408 ------------------------------------------------------------
409
410 .. note:: Cet exemple présente les fonctions:
411
412    * Changement du maillage support "change underlying mesh"
413
414 On se place ici dans le cas de figure où des champs ont été produits
415 sur le même maillage, au sens géométrique, mais enregistrés dans des
416 fichiers med différents. C'est le cas par exemple d'une étude
417 paramétrique où plusieurs calculs sont effectués avec des variantes
418 sur certains paramètres du modèle simulé, chaque calcul produisant un
419 fichier med.
420
421 Soit ``parametric_01.med`` et ``parametric_02.med`` deux fichiers med
422 contenant les champs que l'on souhaite comparer, par exemple en
423 calculant la différence des valeurs et en visualisant le résultat.
424
425 Aprés le chargement des sources de données dans le module XMED,
426 l'utilisateur se trouve en présence de deux maillages, au sens
427 technique du terme cette fois-ci, c'est-à-dire que les champs sont
428 associées à des objets informatiques maillage différents, bien que
429 géométriquement identiques.
430
431 Or, les fonctions de manipulation de champs ne permettent pas les
432 opérations sur des champs dont les maillages supports sont différents
433 (voir la remarque à la fin de :ref:`l'exemple
434 3<xmed.userguide.exemple3-fr>`).
435
436 Pour résoudre ce cas de figure, le module de manipulation de champs
437 met à disposition la fonction "Change underlying mesh" qui permet de
438 remplacer le maillage support d'un champ par un autre à partir du
439 moment où les deux maillages sont géométriquement identiques,
440 c'est-à-dire que les noeuds ont les mêmes coordonnées spatiales.
441
442 .. |ICO_DATASOURCE_CHG| image:: ../images/ico_datasource_changeUnderlyingMesh.png
443                         :height: 16px
444
445 Dans l'exemple proposé, l'utilisateur sélectionne le premier pas de
446 temps du champ ``StiffExp_01`` du "datasource" ``parametric_01.med``,
447 puis l'importe dans l'espace de travail au moyen de la commande "Use
448 in workspace" |ICO_DATASOURCE_USE|. Il sélectionne ensuite le premier
449 pas de temps du champs ``StiffExp_02`` du "datasource"
450 ``parametric_02.med``, mais l'importe dans l'espace de travail au
451 moyen de la commande "Change underlying mesh" |ICO_DATASOURCE_CHG|. La
452 fenêtre de dialogue ci-dessous s'affiche et invite l'utilisateur à
453 choisir le nouveau maillage support par sélection dans l'arborescence
454 du "dataspace":
455
456 .. image:: ../images/xmed-gui-datasource-changeUnderlyingMesh.png
457    :align: center
458
459 Dans cet exemple, on sélectionne le maillage ``Grid_80x80_01`` support
460 du champ ``StiffExp_01``, avec lequel on souhaite faire la
461 comparaison. Après validation, l'arborescence du workspace contient le
462 champ ``StiffExp_02`` défini sur le maillage ``Grid_80x80_01``:
463
464 .. image:: ../images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
465    :align: center
466
467 .. note:: La fonction "Change underlying mesh" ne modifie pas le champ
468   sélectionné dans le "dataspace" (principe de base de fonctionnement
469   du dataspace), mais crée une copie du champ dans l'espace de travail
470   pour ensuite remplacer le maillage support. D'où le nom par défaut
471   pour le champ ``dup(<nom du champ sélectionné>)`` (dup pour
472   "duplicate").
473
474 Il reste à associer une variable à ce champ pour le manipuler dans la
475 console. Ceci peut être fait au moyen de la commande "Use in console",
476 disponible dans le menu contextuel du workspace.
477
478 En définitif, si ``f1`` désigne le champ issu du datasource
479 ``parametric_01.med`` et ``f2`` le champ issu du datasource
480 ``parametric_02.med`` par la procédure décrite ci-dessus, alors la
481 comparaison des deux grandeurs peut être faite comme pour le cas de
482 :ref:`l'exemple 3<xmed.userguide.exemple3-fr>`::
483
484  >>> r=f1-f2
485  >>> view(r)
486
487 .. note:: En remarque générale sur cet exemple, il convient de noter
488    les points suivants:
489
490    * l'égalité géométrique de deux maillages est établie à une marge
491      d'erreur prés qu'il est possible de définir techniquement, mais
492      qui n'est pas ajustable au niveau de l'interface du module de
493      manipulation de champs. Elle est fixée à une valeur standard qui
494      permet de traiter la plupart des cas utilisateur. On verra à
495      l'usage s'il est nécessaire de remonter ce paramètre au niveau de
496      l'interface.
497    * L'utilisateur doit faire la démande explicite de changer le
498      maillage support d'un champ, en prévision de la comparaison de
499      champs issus de datasource différentes. Il s'agit là d'un choix
500      fonctionnel délibéré pour que l'utilisateur garde trace des
501      modifications faites sur les données (pas de modification
502      automatiques à l'insu de l'utilisateur, même sous prétexte
503      d'amélioration de l'ergonomie).
504
505
506 Exemple 5: Créer un champ sur un domaine spatial
507 ------------------------------------------------
508
509 .. note:: Cet exemple présente les fonctions:
510
511    * initialisation par une fonction de la position spatiale
512    * initialisation sur un groupe de maille
513
514 Le domaine géométrique de définition du champs à créer est spécifié
515 ici par la donnée d'un groupe de mailles. Ce cas d'usage est
516 typiquement prévu pour produire les conditions de chargement initial
517 d'une structure, par exemple en définissant un champ sur une surface
518 de la géométrie, identifiée par un nom de groupe de mailles.
519
520 .. warning:: DEVELOPPEMENT EN COURS
521
522 Exemple 6: Extraire une partie d'un champ
523 -----------------------------------------
524
525 .. note:: Cet exemple présente les fonctions:
526
527    * extraire une composante (ou un sous-ensemble des composantes)
528    * extraire un domaine géométrique (valeurs sur un groupe de maille)
529    * extraire un ou plusieurs pas de temps.
530
531 .. warning:: DEVELOPPEMENT EN COURS
532
533    On doit illustrer ici les fonctions de restriction, qui
534    permettraient de récupérer certaines composantes uniquement. Le
535    principe est qu'on crée un nouveau champ qui est une restriction du
536    champ argument à une liste de composantes à spécifier (utiliser la
537    fonction __call__ des fieldproxy).
538
539 Pour l'extraction des pas de temps, on peut se ramener au cas de
540 l'exemple 2 avec une seule source de donnée.
541
542 Exemple 7: Créer un champ à partir d'une image to[mp]ographique
543 ---------------------------------------------------------------
544
545 .. note:: Cet exemple présente les fonctions:
546
547    * Création d'un champ sans datasource (ni maillage, ni champs), à
548      partir d'un fichier image
549
550 En tomographie ou en topographie, les appareils de mesure produisent
551 des images qui représentent une grandeur physique en niveaux de gris
552 sur un plan de coupe donné. L'image ci-dessous représente par exemple
553 une vue interne du corps humain faite par IRM:
554
555 .. image:: ../images/xmed-irm.png
556    :align: center
557    :width: 600px
558
559 Cette image est un ensemble de pixels organisés sur une grille
560 cartesienne. Elle peut donc être modélisée sous la forme d'un champ
561 scalaire dont les valeurs sont définies aux cellules d'un maillage
562 réglés de même taille que l'image (en nombre de pixels):
563
564 .. image:: ../images/xmed-irm-field.png
565    :align: center
566    :width: 600px
567
568 Le module de manipulation de champ fournit un utilitaire appelé
569 ``image2med.py`` qui permet d'appliquer ce principe à la conversion
570 d'un fichier image en fichier med contenant la représentation de
571 l'image sous forme d'un champ scalaire (seul le niveau de gris est
572 conservé)::
573
574   $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
575
576 .. |ICO_IMAGESOURCE| image:: ../images/ico_imagesource.png
577                         :height: 16px
578
579 Cette opération de conversion peut être faite automatiquement dans
580 l'interface graphique du module au moyen de la commande "Add Image
581 Source" |ICO_IMAGESOURCE| disponible dans la barre d'outils. Cette
582 commande ouvre la fenêtre suivante pour inviter l'utilisateur à
583 choisir un fichier image:
584
585 .. image:: ../images/medop_image2med_dialog.png
586    :align: center
587
588 Le nom du fichier med résultat est proposé par défaut (changement de
589 l'extention en ``*.med``) mais il peut être modifié. Enfin, on peut
590 demander le chargement automatique du fichier med produit pour ajout
591 dans l'espace de donnée. Les champs peuvent alors être manipulés comme
592 dans les cas d'utilisation standard.
593
594 Par exemple, l'image ci-dessous affiche le résultat de la différence
595 entre deux images, ajoutée à l'image de référence: si i1 et i2
596 désignent les champs créés à partir des deux images, on représente ``r
597 = i1 + 5*(i2-i1)`` où le facteur 5 est arbitraire et sert à amplifier
598 la zone d'intérêt (en haut de l'oeil gauche):
599
600 .. image:: ../images/xmed-irm-diff.png
601    :align: center
602    :width: 600px
603
604 L'exemple ci-dessous est le résultat du chargement d'une image
605 tomographique issue du projet MAP (Charles Toulemonde,
606 EDF/R&D/MMC). L'image tomographique:
607
608 .. image:: ../images/champ_altitude_MAP.png
609    :align: center
610    :width: 600px
611
612 Le résultat du chargement:
613
614 .. image:: ../images/medop_image2med_tomographie.png
615    :align: center
616    :width: 800px
617
618 Exemple 8: Continuer l'analyse dans PARAVIS
619 -------------------------------------------
620
621 .. note:: Cet exemple présente les fonctions:
622
623    * Export de champs vers le module PARAVIS.
624
625 Les possibilités de représentation graphique des champs fournies par
626 le module MED ont pour seul objectif le contrôle visuel rapide. Par
627 défaut, le viewer de VISU est employé.
628
629 Pour une analyse plus détaillées des champs, il est nécessaire de
630 poursuivre le travail dans PARAVIS. Le module de manipulation de
631 champs offre une fonction qui simplifie ce passage, en faisant le
632 chargement automatique dans PARAVIS et en proposant une visualisation
633 par défaut (carte de champs scalaire).
634
635 Pour cela, il faut sélectionner dans l'espace de travail les champs à
636 exporter, puis déclencher la fonction d'export depuis le menu
637 contextuel associé:
638
639 .. image:: ../images/medop_exportparavis.png
640    :align: center
641
642 Les champs sélectionnés sont regroupés dans une entrée MED du
643 navigateur PARAVIS, et le premier champ est affiché sous forme de
644 carte de champ:
645
646 .. image:: ../images/medop_exportparavis_result.png
647    :align: center
648    :width: 800px
649
650 .. note:: La fonction d'export est une fonction de confort. La même
651    opération peut être faite manuellement en procédant d'abord à
652    l'enregistrement des champs sous forme de fichier MED, puis en
653    chargeant le fichier généré dans le module PARAVIS pour
654    visualisation.
655
656 .. _xmed.userguide.tui-fr:
657
658 Utilisation de l'interface textuelle du module MED (TUI)
659 ========================================================
660
661 Toutes les opérations menées au moyen de l'interface graphique peuvent
662 être réalisées (avec plus ou moins de facilité) avec l'interface
663 textuelle. Le module de manipulation de champs peut même être utilisé
664 exclusivement en mode texte.
665
666 Pour cela, on lance la commande::
667
668  $ <path/to/appli>/medop.sh
669
670 Cette commande ouvre une console de commandes ``medop>``. Un fichier
671 med peut être chargé et travaillé, par exemple pour créer des champs à
672 partir des données du fichier.
673
674 Que l'on soit en mode texte pur ou en mode graphique, un séquence de
675 travail type dans la console peut ressembler au jeu d'instructions
676 suivantes::
677
678  >>> medcalc.LoadDataSource("/path/to/mydata.med")
679  >>> la
680  id=0    name    = testfield1
681  id=1    name    = testfield2
682  >>> f1=accessField(0)
683  >>> f2=accessField(1)
684  >>>    ls
685  f1      (id=0, name=testfield1)
686  f2      (id=1, name=testfield2)
687  >>> r=f1+f2
688  >>> ls
689  f1      (id=0, name=testfield1)
690  f2      (id=1, name=testfield2)
691  r       (id=2, name=testfield1+testfield2)
692  >>> r.update(name="toto")
693  >>> ls
694  f1      (id=0, name=testfield1)
695  f2      (id=1, name=testfield2)
696  r       (id=2, name=toto)
697  >>> putInWorkspace(r)
698  >>> saveWorkspace("result.med")
699
700 Les commandes principales sont:
701
702 * ``LoadDataSource``: charge un fichier med dans la base de données (utile
703   uniquement en mode texte pur)::
704
705   >>> LoadDataSource("/path/to/datafile.med")
706
707 * ``LoadImageAsDataSource``: load an image as a med file
708
709 * ``la``: affiche la liste de tous les champs chargés en base de données ("list all")
710 * ``accessField``: définit un champ dans l'espace de travail à partir de son
711   identifiant (utile plutôt en mode texte pur car l'interface
712   graphique permet de faire cette opération par sélection d'un champ
713   dans le dataspace)::
714
715   >>> f=accessField(fieldId)
716
717 * ``ls``: affiche la liste des champs présent dans l'espace de travail ("list")
718 * ``putInWorkspace``: met un champ en référence dans l'*espace de gestion*::
719
720   >>> putInWorkspace(f)
721
722 * ``saveWorkspace``: sauvegarde tous les champs référencés dans l'espace de
723   gestion dans un fichier med::
724
725   >>> saveWorkspace("/path/to/resultfile.med")
726
727 .. note:: On peut faire à ce stade plusieurs remarques:
728
729    * la commande ``LoadDataSource`` charge uniquement les méta-informations
730      décrivant les maillage et les champs (noms, type de
731      discrétisation, liste des pas de temps). Les maillages et les
732      valeurs physiques des champs sont chargées ultérieurement (et
733      automatiquement) dés lors qu'elles sont requises par une
734      opération. Dans tous les cas, les données med (méta-informations
735      et valeurs) sont physiquement stockées au niveau de l'espace
736      *base de données*.
737    * la commande ``accessField`` définit en réalité un *manipulateur de champ*
738      dans l'espace de travail, c'est-à-dire une variable qui fait la
739      liaison avec le champ physique hébergé dans la base de
740      données. Les données physiques ne circulent jamais entre les
741      espaces, mais restent centralisées au niveau de la base de
742      données.
743
744 Les commandes TUI suivantes nécessitent de travailler dans
745 l'environnement graphique:
746
747 * ``medcalc.MakeDeflectionShape``
748 * ``medcalc.MakeIsoSurface``
749 * ``medcalc.MakePointSprite``
750 * ``medcalc.MakeScalarMap``
751 * ``medcalc.MakeSlices``
752 * ``medcalc.MakeVectorField``