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