2 :keywords: maillage, champ, manipulation, guide utilisateur
3 :author: Guillaume Boulant
5 .. include:: medop-definitions.rst
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
8 Module MED: Guide d'utilisation de l'interface graphique
9 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
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
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<medop-specifications>`, au moins pour fixer les
20 concepts et la terminologie.
22 .. contents:: Sommaire
26 Présentation générale du module MED
27 ===================================
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
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
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).
50 .. image:: images/xmed-gui-withframe.png
53 L'utilisation type des fonctions de manipulation de champs suit un
54 processus de la forme suivante:
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
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
70 5. Enregistrement d'une partie des champs produits dans un fichier med
73 Tour rapide des fonctions du module MED
74 =======================================
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.
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.
84 Exemple 1: Explorer des sources de données
85 ------------------------------------------
87 .. note:: Cet exemple présente les fonctions:
89 * ajouter une source de données
90 * fonctions "Extends field series", "Visualize"
92 .. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
95 .. |ICO_XMED| image:: images/ico_xmed.png
98 .. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
101 .. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
104 Au démarrage, le module de manipulation de champs, identifié par
105 l'icône |ICO_XMED|, présente une interface vierge:
107 .. image:: images/xmed-gui-start.png
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
116 .. image:: images/xmed-gui-datasource-selectfile.png
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.
133 .. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
135 .. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
137 .. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
140 +--------------------------+--------------------------+--------------------------+
141 | |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
142 +--------------------------+--------------------------+--------------------------+
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.
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é:
157 .. image:: images/xmed-gui-datasource-visualize-zoom.png
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).
167 Exemple 2: Rassembler des champs issus de différentes sources
168 -------------------------------------------------------------
170 .. note:: Cet exemple présente les fonctions:
172 * fonction "Use in workspace"
175 .. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
177 .. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
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.
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
192 .. image:: images/xmed-userguide-example2-datasource.png
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
205 .. image:: images/xmed-userguide-example2-workspace.png
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:
214 .. image:: images/xmed-userguide-example2-workspace-save.png
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
222 .. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
223 .. (invalid mesh on field)
225 .. _xmed.userguide.exemple3:
227 Exemple 3: Appliquer une opération mathématique sur des champs
228 --------------------------------------------------------------
230 .. note:: Cet exemple présente les fonctions:
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.
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.
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``).
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:
254 .. image:: images/xmed-gui-datasource-useinworkspace-alias.png
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.
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
274 .. image:: images/xmed-gui-workspace.png
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
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>`):
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
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::
305 Avec au besoin l'utilisation de variables scalaires::
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::
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.
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
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
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>`). Par exemple, la fonction ``view``
344 permet d'afficher la carte scalaire du champ dans le viewer::
350 .. image:: images/xmed-gui-workspace-view.png
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``::
361 On peut enfin tout simplement afficher les données du champs par la
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
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.
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
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>` ci-après.
405 .. _xmed.userguide.exemple4:
407 Exemple 4: Comparer des champs issues de différentes sources
408 ------------------------------------------------------------
410 .. note:: Cet exemple présente les fonctions:
412 * Changement du maillage support "change underlying mesh"
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
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.
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.
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>`).
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.
442 .. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
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
456 .. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
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``:
464 .. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
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
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.
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>`::
487 .. note:: En remarque générale sur cet exemple, il convient de noter
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
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).
506 Exemple 5: Créer un champ sur un domaine spatial
507 ------------------------------------------------
509 .. note:: Cet exemple présente les fonctions:
511 * initialisation par une fonction de la position spatiale
512 * initialisation sur un groupe de maille
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.
520 .. warning:: DEVELOPPEMENT EN COURS
522 Exemple 6: Extraire une partie d'un champ
523 -----------------------------------------
525 .. note:: Cet exemple présente les fonctions:
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.
531 .. warning:: DEVELOPPEMENT EN COURS
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).
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.
542 Exemple 7: Créer un champ à partir d'une image to[mp]ographique
543 ---------------------------------------------------------------
545 .. note:: Cet exemple présente les fonctions:
547 * Création d'un champ sans datasource (ni maillage, ni champs), à
548 partir d'un fichier image
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:
555 .. image:: images/xmed-irm.png
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):
564 .. image:: images/xmed-irm-field.png
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
574 $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
576 .. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
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:
585 .. image:: images/medop_image2med_dialog.png
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.
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):
600 .. image:: images/xmed-irm-diff.png
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:
608 .. image:: images/champ_altitude_MAP.png
612 Le résultat du chargement:
614 .. image:: images/medop_image2med_tomographie.png
618 Exemple 8: Continuer l'analyse dans PARAVIS
619 -------------------------------------------
621 .. note:: Cet exemple présente les fonctions:
623 * Export de champs vers le module PARAVIS.
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é.
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).
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
639 .. image:: images/medop_exportparavis.png
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
646 .. image:: images/medop_exportparavis_result.png
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
656 .. _xmed.userguide.tui:
658 Utilisation de l'interface textuelle du module MED (TUI)
659 ========================================================
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. Pour cela, on lance la commande::
666 $ <path/to/appli>/medop.sh
668 Cette commande ouvre une console de commandes ``medop>``. Un fichier
669 med peut être chargé et travaillé, par exemple pour créer des champs à
670 partir des données du fichier.
672 Que l'on soit en mode texte pur ou en mode graphique, un séquence de
673 travail type dans la console peut ressembler au jeu d'instructions
676 >>> load("/path/to/mydata.med")
678 id=0 name = testfield1
679 id=1 name = testfield2
683 f1 (id=0, name=testfield1)
684 f2 (id=1, name=testfield2)
687 f1 (id=0, name=testfield1)
688 f2 (id=1, name=testfield2)
689 r (id=2, name=testfield1+testfield2)
690 >>> r.update(name="toto")
692 f1 (id=0, name=testfield1)
693 f2 (id=1, name=testfield2)
696 >>> save("result.med")
698 Les commandes principales sont:
700 * ``load``: charge un fichier med dans la base de données (utile
701 uniquement en mode texte pur)::
703 >>> load("/path/to/datafile.med")
705 * ``la``: affiche la liste de tous les champs chargés en base de données ("list all")
706 * ``get``: définit un champ dans l'espace de travail à partir de son
707 identifiant (utile plutôt en mode texte pur car l'interface
708 graphique permet de faire cette opération par sélection d'un champ
713 * ``ls``: affiche la liste des champs présent dans l'espace de travail ("list")
714 * ``put``: met un champ en référence dans l'*espace de gestion*::
718 * ``save``: sauvegarde tous les champs référencés dans l'espace de
719 gestion dans un fichier med::
721 >>> save("/path/to/resultfile.med")
723 .. note:: On peut faire à ce stade plusieurs remarques:
725 * la commande ``load`` charge uniquement les méta-informations
726 décrivant les maillage et les champs (noms, type de
727 discrétisation, liste des pas de temps). Les maillages et les
728 valeurs physiques des champs sont chargées ultérieurement (et
729 automatiquement) dés lors qu'elles sont requises par une
730 opération. Dans tous les cas, les données med (méta-informations
731 et valeurs) sont physiquement stockées au niveau de l'espace
733 * la commande ``get`` définit en réalité un *manipulateur de champ*
734 dans l'espace de travail, c'est-à-dire une variable qui fait la
735 liaison avec le champ physique hébergé dans la base de
736 données. Les données physiques ne circulent jamais entre les
737 espaces, mais restent centralisées au niveau de la base de
740 Les commandes TUI suivantes nécessitent de travailler dans
741 l'environnement graphique:
743 * ``visu``: afficher une carte de champ pour contrôle visuel rapide
744 (pas de paramettrage possible)