2 :keywords: maillage, champ, manipulation, med
3 :author: Guillaume Boulant
5 .. include:: medop-definitions.rst
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
8 Module MED: Spécifications fonctionnelles et techniques
9 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
11 Ce texte présente les spécifications informatiques pour le
12 développement d'un module de manipulation de champs qui répond à
13 l'expression de besoins formulée dans le cahier des charges
14 |REF_EDF_VCA_H-I2C-2009-03595-FR|_.
16 .. contents:: Sommaire
20 Description des cas d'application de référence
21 ==============================================
23 Plusieurs cas d'applications métier sont identifiés pour piloter le
24 développement du module de manipulation de champs:
26 * **Analyser et post-traiter le résultat d'un calcul**. C'est l'usage
27 principal qui consiste typiquement à créer des champs comme le
28 résultat d'*opérations mathématiques* dont les opérandes sont des
29 champs et des scalaires. On compte également dans cette catégorie
30 les *opérations de restriction* qui permettent d'extraire puis
31 utiliser une partie d'un champs, c'est-à-dire de créer un champ
32 comme la restriction d'un autre champ à une partie de son domaine de
33 définition (certaines composantes, certains pas de temps, limitation
34 à un groupe de mailles).
35 * **Comparer des champs issus d'un calcul paramétrique**. Il s'agit
36 d'une variante du cas précédent qui consiste à mesurer et visualiser
37 les variations entre des champs issues de sources de données
38 différentes (différents fichiers med).
39 * **Préparer les conditions aux limites d'une calcul**. Il s'agit de
40 pouvoir initialiser un champ sur un maillage ou un groupe de
41 mailles, c'est-à-dire créer un champ de toute pièce sur un
42 support spatial donné, par exemple par la donnée d'une fonction
43 mathématique qui donne les valeurs des composantes en fonction des
44 coordonnées spatiales.
45 * **Gérer des données de calcul**. Il s'agit typiquement de pouvoir
46 rassembler au sein d'un même fichier med des champs et des maillages
47 issues de différentes sources de données, et/ou créés au travers des
48 cas d'application présentés ci-dessus.
50 Modèle conceptuel des données
51 =============================
53 On rappelle ici les concepts utilisés dans le module et les modalités
54 d'utilisation de ces concepts. Le point de vue est celui de
55 l'utilisateur du module de manipulation de champs. Il s'agit
56 essentiellement pour le moment d'éclaircir l'ergonomie d'usage sur le
57 plan conceptuel, avant d'aborder la déclinaison en spécifications
58 techniques pour lesquelles les particularités du modèle MED devront
59 être intégrées à la réflexion.
64 Le concept central est celui de *champ*, c'est-à-dire une grandeur
65 physique exprimée sur un domaine spatial D. La grandeur peut être de
66 type scalaire (une température), de type vectorielle (une vitesse) ou
67 de type tensorielle (les contraintes). En un point de l'espace, elle
68 se définie donc par la donnée d'une ou plusieurs valeurs numériques
69 appelées les *composantes* (1 pour un champ scalaire, 3 pour un champ
70 vectoriel 3D, 6 pour un champ tensoriel symétrique 3D).
72 .. note:: Une pratique courante au niveau des codes est de stocker
73 plusieurs grandeurs physiques différentes dans un même champs med
74 (au sens informatique du terme). Par exemple, le champ
75 électromagnétique à 6 composantes, plus le champ de température
76 scalaire peuvent techniquement être stockés dans un même champs med
77 à 7 composantes. C'est pourquoi, le module de manipulation de
78 champs doit fournir des fonctions de restrictions qui permettent
79 d'extraire certaines composantes pour former la grandeur physique à
80 étudier. Dans la suite du document, on part du principe que l'on
81 peut se ramener dans tous les cas au cas d'un champ homogène tel
84 Dans le cadre d'un modèle numérique discret, les valeurs du champ sont
85 exprimées pour un nombre fini de positions, qui correspondent à des
86 lieux particuliers du maillage. Suivant la nature des modèles de
87 calcul, les valeurs peuvent être données par cellule, par face, par
88 noeud, aux points de gauss, ...
90 Ainsi, un champ discret est un objet dont les valeurs peuvent être
91 lues selon les dimensions suivantes:
93 * *La position p dans l'espace*, caractérisée par le type de l'élément
94 de maillage support et son numéro identifiant
95 * *La composante c*, caractérisée par son indice (jusqu'à 6
96 composantes dans les modèles physiques envisagés)
98 L'évolution d'un champ dans le temps peut être exprimée sous la forme
99 d'une série temporelle, c'est-à-dire une séquence de champs donnés
100 pour des instants discrets. Aussi, si l'on manipule un champ qui varie
101 dans le temps, l'accès aux valeurs introduit une dimension
104 * *Le temps t*, caractérisé par un numéro de pas de temps
105 (correspondant en général à une étape du calcul qui a produit le champ).
107 .. note:: Il s'agit là d'une représentation conceptuelle standard dont
108 le |LINK_EDF_MEDDOC|_ fait une expression détaillée. En
109 particulier, la position p est déterminée par la donnée du type
110 d'élément support (valeurs aux noeuds, aux mailles, aux noeuds par
111 éléments, aux points de gauss) et de l'indice de cet élément. En
112 général, le type d'éléments support est résolu à l'initialisation
113 et l'indice peut suffire au repérage dans les algorithmes. Le temps
114 t est déterminé par un numéro d'itération, qui peut éventuellement
115 être complété par un numéro d'ordre. Le cas des points de gauss
116 ajoute un cran de complexité dans la mesure où il faut repérer
117 l'entité géométrique (maille, face, arrête) puis le point de gauss
118 de cette entité. A noter que dans le modèle MED, le concept de
119 série temporelle de champ n'est pas explicitement définie et
120 l'accès à des valeurs à différents instants t1 et t2 nécessite le
121 chargement des champs ``F1=F(t1)`` et ``F2=F(t2)``.
123 Par convention, on utilisera par la suite les notations:
125 * **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U
126 à la position p et prise à l'instant t;
127 * **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes
129 * **U(t,:,c)** pour signifier que l'on manipule le domaine de
130 définition spatial complet.
132 Dans une grande majorité des cas d'usage on travaille à temps t fixé
133 et sur un domaine spatiale prédéfini. Aussi on utilisera également la
134 notation à deux arguments ``U(:,:)`` ou tout simplement ``U`` (dès
135 lors qu'il n'y a pas ambiguïté) pour désigner un champ complet et Uc
136 pour désigner la composante c du champ avec c=1..6.
140 Le deuxième concept à préciser est la notion d'*opération*. Une
141 opération dans le présent contexte est l'application d'un opérateur
142 sur un ou plusieurs champs pour produire une grandeur de type champ ou
143 de type valeur numérique.
145 Par exemple, la formule ``W=OP(U,V)`` indique que le champ W est formé
146 à partir des champs U et V en arguments d'une fonction OP. Dans le cas
147 d'une opération algébrique comme l'addition (cf. :ref:`Spécification
148 des opérations<xmed-specifications>`, le résultat attendu par défaut
149 est que pour chaque instant t, chaque position p et chaque composante
150 c, on a ``W(t,p,c)=U(t,p,c)+V(t,p,c)`` (que l'on peut noter également
151 ``W(:,:,:)=U(:,:,:)+V(:,:,:)`` compte-tenu de la convention présentée
152 plus haut). Ce n'est cependant pas une règle et l'utilisateur peut
153 très bien manoeuvrer les champs en détaillant et mixant les
154 composantes (par exemple ``W(:,:,3)=5+U(:,:,1)*V(:,:,2)``), ou encore
155 ne travailler que sur un domaine spatial et/ou temporel particulier
156 (cf. |REF_EDF_VCA_H-I2C-2009-03595-FR|_ §5.4.1).
158 On formalise donc le concept d'opération par les propriétés suivantes:
160 * L'opérateur peut produire un champ (par exemple la somme de deux
161 champs W=sum(U,V)=U+V), une valeur numérique (par exemple la moyenne
162 spatiale d'un champ m=smoy(U)) ou une valeur logique (par exemple le
163 test d'égalité de deux champs b=isequal(U,V));
164 * L'opérateur peut être paramétré par la donnée de valeurs numériques
165 (par exemple, le changement d'unité peut être défini comme une
166 multiplication par un scalaire V=multiply(U,1000)=1000*U);
167 * L'opérateur est caractérisé par un domaine d'application qui
168 spécifie la portée de l'opération. Ce domaine comporte plusieurs
171 - Un domaine temporel T qui spécifie les pas de temps sur lesquels
172 l'opération est appliquée;
173 - Un domaine spatial D qui spécifie la limite de portée de
174 l'opérateur et donc le domaine de définition du champ produit (qui
175 correspond dans ce cas à une restriction du domaine de définition
176 des champs en argument);
177 - Un domaine de composantes C qui spécifie les composantes sur
178 lesquelles l'opération est appliquée;
181 Sur le plan informatique, l'opérateur aura également un paramètre
182 appelé *option* qui pourra indiquer par exemple dans une
183 opération unaire V=F(U) si le résultat V est une nouvelle instance
184 de champ ou la valeur modifiée du champ de départ U. Il pourra
185 également être amené à manoeuvrer des paramètres de type chaîne de
186 caractères, par exemple pour les opérations de changement de nom
189 De manière générale, on utilisera la notation
190 **(W|y)=OP[D,C,T](P,U,V,...)** pour désigner une opération OP:
192 * **(V|y)**: V ou y désignent respectivement un résultat de type
193 champ ou de type valeur numérique ou logique;
194 * **[T,D,C]**: le domaine d'application de l'opérateur avec T le
195 domaine temporel, D le domaine spatial et C le domaine des
197 * **P,U,V,...**: les paramètres numériques P (liste de valeurs
198 numériques) et les champs U,V,... en arguments de l'opérateur;
200 On note également les particularités suivantes pour certaines
203 * Le domaine de définition du champ produit par une opération peut
204 être différent du domaine de définition des champs en argument. Par
205 exemple, dans le cas d'une opération de projection de champ, le
206 domaine spatial résultat peut être modifié par rapport au domaine de
207 définition initial, soit par la modification de la zone géométrique,
208 soit par modification des entités de maillage support.
209 * En dehors des opérations de type dérivée et intégrale, les valeurs
210 résultats sont déterminées de manière locale en chaque point du
211 domaine d'application. Par exemple, l'addition W=U+V consiste à
212 produire un champ W dont les valeurs en chaque point p sont la somme
213 des valeurs des composantes de U et V en ce point p: ``W=U+V <=>
214 W(:,p,:)=U(:,p,:)+V(:,p,:)`` pour tout point p du domaine
217 Concept de domaine d'application
218 --------------------------------
220 Un domaine d'application est associé à une opération (et non pas à un
221 champ). Il a pour objectif de restreindre la portée de l'opération en
222 terme spatial, temporel, jeu des composantes.
224 Pour ce qui concerne le domaine spatial D, plusieurs modalités de
225 définition sont envisagées:
227 * la donnée d'un maillage ou d'un groupe d'éléments du maillage;
228 * un système de filtres qui peut combiner:
230 - une zone géométrique définie indépendamment du maillage (boîte
232 - des critères conditionnant le calcul (par exemple U(t,p,c)=1 si
235 .. warning:: Version 2010: D pourra correspondre au maillage complet
236 et dans la mesure du possible à un groupe d'éléments du maillage
238 Ce domaine d'application peut être différent du domaine de définition
239 des champs mais il doit être compatible (recouvrement spatial partiel
240 au moins et même support d'entité de maillage). Ainsi, sans précision
241 particulière, une opération s'applique à l'ensemble du domaine de
242 définition des champs en argument (qui dans la pratique MED est
243 spécifié par le support et correspond en général au maillage
246 Limites d'utilisation
247 ---------------------
249 Plusieurs situations doivent être examinées pour poser les limites
252 * Les champs en argument n'ont pas tous le même domaine de définition,
253 par exemple parcequ'il ne sont pas définis sur les mêmes zones
254 géométriques ou parcequ'ils ne sont pas donnés sur le même type
255 d'entité de maillage. On peut imaginer dans ce cas produire le
256 résultat sur les zones de recouvrement uniquement.
257 * Le domaine de définition des champs et le domaine d'application de
258 l'opérateur ne sont pas compatibles, par exemple parcequ'on demande
259 une restriction sur une zone géométrique qui ne fait pas partie de
260 la zone de définition du champ d'entrée. A priori, ce type
261 d'opération est déclaré en échec.
262 * Les champs en argument ne sont pas définis sur les mêmes pas de
263 temps. Si l'opération est tolérée (techniquement MEDCoupling permet
264 de le faire), le pas de temps résultat est indéfini.
266 .. warning:: **A faire**: spécifier les modalités de prise en compte de
267 ces différentes situations (au moins sur le plan conceptuel).
269 Au delà de ces limites conceptuelles, il faut avoir en tête les
270 limites techniques liées à l'usage de MED mémoire (paquet
271 MEDCoupling). Par exemple, MEDCoupling impose que les champs opérandes
272 soient définis sur le même maillage support (on parle ici de l'objet
273 informatique correspondant au maillage). Deux champs construits sur le
274 même maillage (du point de vue conceptuel) mais issus de deux fichiers
275 med différents sont considérés comme des champs définis sur des
276 maillages support différents, c'est-à-dire que les objects
277 informatiques correspondant aux maillages sont différents (chargés de
278 deux fichiers différents). En l'état, il est donc impossible par
279 exemple de faire la comparaison de champs résultats d'une étude
280 paramétriques. MEDCoupling fournit une solution qu'il faudra mettre en
281 oeuvre de manière ergonomique au niveau du module MED. Il est possible
282 de changer le maillage support M1 d'un champs par un maillage M2 à
283 partir du moment où les maillages M1 et M2 sont identiques
284 géométriquement à une erreur près qu'il est possible de spécifier.
287 D'autres situations limites peuvent être évoquées sous l'angle
288 informatique. Ce sont des situations qui a priori n'ont pas de
289 raison d'exister sur le plan conceptuel mais qui peuvent très bien
290 survenir au niveau du module informatique compte-tenu des
291 particularités du modèle MED. Par exemple:
293 * Le nombre et la nature des composantes ne sont pas identiques
294 pour tous les champs d'entrée. Par exemple, U défini ses
295 composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les
296 défini comme U(:,:,1)=Uz, U(:,:,2)=Ux, U(:,:,3)=Uy. Cette
297 situation peut être gérée techniquement par exemple au moyen
298 d'une carte de correspondance qui accompagnerai chacun des champs
299 pour exprimer le sens physique de chaque composants (histoire de
300 ne pas ajouter des choux et des carottes).
302 Spécifications générales
303 ========================
305 Le diagramme ci-dessous représente un découpage fonctionnel qui rend
306 compte de l'expression des besoins:
308 .. image:: images/xmed-functions.png
311 On peut identifier les fonctionnalités suivantes:
313 * **Opérations**: fonctions de manipulation de champs proprement
315 * **Persistance**: fonctions d'enregistrement persistant et de
316 chargement des données (au format med fichier)
317 * **Visualisation**: fonctions de contrôle visuel des champs
319 * **Export des données**: fonction de transposition des données de
320 champs dans un format textuel directement exploitable et de manière
321 autoportante dans une autre application, par exemple en python au
322 moyen des structures de données Numpy.
324 Ces fonctions s'articulent autour d'un conteneur qui héberge les
325 champs manipulés et les supports de ces champs (représenté par le
328 Un scénario d'utilisation type est:
330 * Préparation des champs à manipuler, par deux moyens complémentaires:
332 - Utilisation des fonctions de persistance: chargement depuis un
333 fichier med d'un ensemble de champs qui partagent le même espace
335 - Utilisation des opérations de champs: chargement d'un maillage
336 depuis un fichier med, puis création ab initio de champs au moyen
337 des opérations de champs;
339 * Manipulation des champs par application des opérations à
340 disposition, puis contrôle visuel des résultats produits au moyen
341 des fonctions de visualisation mises à disposition par SALOME;
342 * Restitution des résultats produits, par deux moyens complémentaires:
344 - Restitution des champs produits et/ou modifiés sous une forme
345 persistante (fichier med);
346 - Restitution d'une partie seulement des résultats sous forme de
347 tableaux de valeurs sauvegardés dans un fichier texte ou exporté
348 sous forme de tableau numpy
350 .. _xmed-specifications:
352 Spécification des opérations
353 ============================
355 Le cahier des charges définit trois catégories d'opérations
358 * **Les opérations arithmétiques**, dans lesquelles le résultat à la
359 position p et à l'instant t ne dépend que des données à la position
361 * **Les opérations d'interpolations**, dans lesquelles le résultat
362 est exprimé sur des entités de maillages différentes ou est projeté
363 sur une zone géométrique différente du domaine de définition
365 * **Les opérations globales**, dans lesquelles le résultat peut
366 demander l'agrégation des valeurs sur plusieurs position p ou
367 plusieurs pas de temps t (calcul d'extremum, d'intégrale);
369 Auxquelles, on peut ajouter à des fins de gestion des données:
371 * **Les opérations de génération**, qui permettent de créer un champ
372 sur un maillage vierge ou d'étendre le domaine spatial de définition
374 * **Les opérations d'ordre sémantique**, qui permettent de modifier
375 les méta-données associées aux champs (nom, unité, ...)
376 * **Les opérations de diagnostic**, qui permettent d'effectuer une
377 analyse particulière d'un champ et/ou des éléments de maillage
378 associés et de fournir un compte-rendu, sous la forme d'une
379 structure de données ou d'un texte formaté affichable dans
380 l'interface utilisateur.
382 La suite de la section décrit les spécifications prévues pour chaque
383 type d'opération unitaire. Un dernier paragraphe concerne les
384 modalités de combinaison des opérations et spécifie la définition d'un
385 domaine d'application sur une opération, qui permet de restreindre la
386 portée de l'opération en terme spatial, temporelle ou nature des
387 composantes impliquées.
389 Les opérations arithmétiques
390 ----------------------------
392 Les opérations arithmétiques regroupent:
394 * les **opérations algébriques** (+, -, x, /);
395 * les **opérations vectorielles** (produit scalaire, produit
396 vectoriel, produit tensoriel);
397 * l'**application d'une fonction mathématique** à variable scalaire
398 (exponentielle, logarithme, fonctions trigonométriques, valeur
399 absolue, partie entière) ou à variable de type champ (les fonctions
400 de norme par exemple).
402 Pour les besoins des spécifications informatiques, il est plus commode
403 de classer ces opérations en deux catégories:
405 * les **opérations unaires**, qui prennent un opérande unique en
406 argument. C'est le cas de la plupart des fonctions mathématiques
408 * les **opérations binaires**, qui prennent deux opérandes en
409 argument. C'est le cas des opérations algébriques et des opérations
412 A partir de cette classification, il convient de distinguer trois
413 formes d'usage selon la nature des opérandes:
415 * les opérandes sont exclusivement des scalaires (typiquement des
416 valeurs de composantes des champs et des paramètres numériques). Par
419 W(:,:4) = 1+2xU(:,:,2)+V(:,:,3)
421 * les opérandes sont exclusivement des champs. Par exemple::
424 W = U ^ V (produit vectoriel)
426 * les opérandes sont des champs et des paramètres numériques. Par exemple::
431 Le premier cas de figure (opérandes scalaires) est trivial car les
432 règles mathématiques conventionnelles s'appliquent et sont
433 implémentées dans tous les langages (Python et C++ en
434 particulier). Les cas 2 et 3 par contre doivent être précisés car (i)
435 les règles de comportement ne peuvent pas être simplement déduites des
436 règles mathématiques (quel est le résultat de ``W = U + 2`` ?) et
437 (ii) certaines écritures ne peuvent avoir aucun sens (par exemple
438 ``W = 2 / U``). Il convient donc de préciser les conventions et
439 les limites sur ces deux cas de figure.
441 Dans le cas des opérations unaires où l'opérande est un champ, on doit
442 distinguer deux cas d'usage:
444 * l'application d'une fonction mathématique à valeur de type champ. Ce
445 cas est trivial également et on applique la règle d'usage de la
446 fonction. C'est typiquement le cas des fonctions de calcul de
448 * l'application d'une fonction mathématique à valeur scalaire. Dans ce
449 cas, on convient d'appliquer la fonction de manière unitaire sur
450 chacune des composantes c du champ: ``W(:,:,c) = OP( U(:,:,c)
453 Dans le cas des opérations binaires, on recense les combinaisons
454 d'opérandes suivantes (les lettres capitales représentent des champs,
455 et les lettres minuscules une valeur scalaire qui peut être un
456 paramètre numérique ou la composante d'un champ):
458 * U+V ajoute les composantes en regard: W(:,:,c)=U(:,:,c)+V(:,:,c)
459 * U-V soustrait les composantes en regard: W(:,:,c)=U(:,:,c)-V(:,:,c)
460 * U*V multiplie les composantes en regard: W(:,:,c)=U(:,:,c)*V(:,:,c)
461 * U/V divise les composantes en regard: W(:,:,c)=U(:,:,c)/V(:,:,c)
462 * U+x ajoute x à toute les composantes: W(:,:,c)=U(:,:,c)+x
463 * U*x multiplie toutes les composantes par x: W(:,:,c)=U(:,:,c)*x
464 * U.V produit scalaire des champs U et V: W(:,:c)=U(:,:,c)*V(:,:,c)
465 * U^V produit vectoriel des champs U et V: W(:,:1)=U(:,:,2)*V(:,:,3)-U(:,:,3)*V(:,:,2), ...
468 Pour ce qui concerne les opérations vectorielles, un convention
469 implicite est appliquée par laquelle on suppose que les composantes
470 sont rangées dans l'ordre des dimensions spatiales U1=Ux, U2=Uy,
471 U3=Uz. Sur le plan informatique au niveau du modèle MEDMEM, ceci
472 n'est pas garanti et aucun élément du modèle ne permet de
473 contraindre l'application de cette convention. Il convient donc de
474 prévoir des fonctions techniques qui permettront de mettre en
475 correspondance les indices de composantes et les dimensions
476 spatiales (par exemple par la données d'une carte de correspondance
477 applicable à un ensemble de champs).
482 * Analyse dimensionnelle du champ résultats pour adapter
483 l'unité. Par exemple, si on fait UxV où U et V sont exprimés en
484 [m] alors le résultat est en [m2].
486 Les opérations d'interpolation
487 ------------------------------
488 .. warning:: Non prévues au programme 2010.
490 Les opérations mathématiques globales
491 -------------------------------------
492 .. warning:: Non prévues au programme 2010.
494 Les opérations de génération
495 ----------------------------
496 .. warning:: EN TRAVAUX
498 Les opérations de génération sont des fonctions qui permettent de
499 créer un champ sur un domaine du maillage où il n'est pas défini
500 initialement. Deux cas de figure peuvent se présenter:
502 * Le champ n'existe pas et il doit être créé sur un domaine à définir;
503 * Le champ existe mais les valeurs ne sont pas définies sur l'ensemble
506 On peut envisager plusieurs modalités de mise en oeuvre:
508 * le prolongement par une valeur constante (ou plus généralement par
509 une fonction de l'espace?);
510 * les valeurs du champs sont données par une fonction f(p,t) qui prend
511 la position p et le pas de temps t en argument;
512 * on peut prédéfinir le champ position **r** qui porte les
513 coordonnées spatiales de l'élément de maillage support, puis faire
514 une opération arithmétique standard.
516 Les opérations d'ordre sémantique
517 ---------------------------------
518 .. warning:: EN TRAVAUX
522 * le changement de nom du champ
523 * le changement d'unité du champ (il s'agit ici de conserver la
524 cohérence entre la valeur numérique et l'attribut "unité" d'un
527 Les opérations de diagnostic
528 ----------------------------
529 .. warning:: EN TRAVAUX. A faire en fonction des besoins des cas d'application
531 On peut identifier plusieurs types d'opérations:
533 * les opérations à diagnostic booléen, par exemple
534 b=isequal(U,V)=[U=V] (où [.] signifie évaluation de la condition
536 * les opérations à diagnostic textuel, par exemple afficher les
537 méta-données associées à un champs (unité, nom, maillage support,
538 type d'entité, pas de temps, ...)
539 * les opérations à diagnostic structuré, qui donneraient une structure
540 de données exploitable au niveau d'un code logiciel.
542 Combinaison des opérations
543 --------------------------
544 .. warning:: EN TRAVAUX. Indiquer les règles de combinaison (associativité, commutativité, ...)
546 Définition d'un domaine d'application
547 -------------------------------------
548 Pour rappel, un domaine d'application peut être associé à une
549 opération pour restreindre la portée de l'opération en terme spatial,
550 temporelle ou nature des composantes impliquées.
552 .. warning:: Todo: spécifier comment on le définit et les modalités d'applications.
554 Spécification de l'ergonomie
555 ============================
557 L'ergonomie générale d'utilisation du module de manipulation de champs
558 est inspirée des logiciels comme octave ou scilab. Elle associe une
559 interface graphique, pour sélectionner et préparer les données, avec
560 une interface texte (la console python) pour le travail effectif sur
563 * L'**interface graphique** a pour fonction essentielle de sélectionner et
564 préparer les champs à manipuler dans l'interface texte, puis
565 fournit des fonctions pour la gestion générale des données
566 (chargement, sauvegarde, contrôle visuel, export).
567 * L'**interface texte** offre un jeu de commandes pour manipuler les
568 champs (afficher les données, effectuer des opérations), piloter les
569 fonctions d'affichage (contrôle visuel au moyen des modules VISU
570 et/ou PARAVIS) et communiquer avec l'interface graphique (ajouter
571 des nouveaux champs dans l'espace de gestion, mettre à jour les
572 méta-données d'un champ).
574 Sur le plan de l'ergonomie, cela se traduit par un processus de
575 travail dans lequel on peut distinguer différentes phases:
577 * Une phase de préparation des champs à manoeuvrer sous la forme de
578 variables nommées et simples à manipuler dans l'interface
579 textuelle. Lors de cette phase, l'utilisateur spécifie de manière
580 graphique tout ce qui peut être définis à l'avance et pour toute la
581 durée du processus de travail. Par exemple, en spécifiant le nom des
582 fichiers med source des données et les noms des champs à utiliser
583 dans ces fichiers, le pas de temps de travail, le jeu des
584 composantes à considérer, le domaine d'application des opérations;
585 * Une phase de manipulation des champs proprement dite, qui a lieu
586 principalement dans l'interface textuelle, et qui peut s'accompagner
587 de contrôle visuel des résultats et/ou d'export à destination
588 d'outils complémentaires indépendants (gnuplot, python, ...);
589 * Une phase de restitution des champs produits pour assurer la
590 persistance des données de travail. Tout les champs créés par les
591 manipulations au niveau de l'interface textuelle ne sont pas à
592 sauvegarder, et on on propose donc à l'utilisateur les moyens de
593 choisir les champs à conserver. Cette phase peut amener
594 l'utilisateur à préciser les informations manquantes, comme les noms
595 de fichiers, les noms de champs produits, les unités, ...
597 Dans ce cadre, l'utilisation type des fonctions de manipulation de
598 champs est un processus de la forme suivante:
600 1. Chargement d'un fichier med dans SALOME et exploration du contenu,
601 composé de maillages, sur lesquels sont définis des champs, pouvant
602 contenir un ou plusieurs pas de temps.
603 2. Sélection (graphique) des champs à manipuler, avec la possibilité
604 de préciser des restrictions d'utilisation (pas de temps,
605 composantes, groupe de maille).
606 3. Création de nouveaux champs par l'exécution d'opérations
607 algébriques (+,-,*,/) entre champs, l'application de fonctions
608 mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
609 "from scratch" à partir d'un maillage support.
610 4. Contrôle visuel rapide des champs produits (avec les modules VISU
611 et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
613 5. Enregistrement d'une partie des champs produits dans un fichier med
616 Les espaces de données utilisateur
617 ----------------------------------
619 Sur le plan conceptuel, on est amené à définir deux espaces de données
622 * **l'espace des données source** (*dataspace*), dans lequel
623 l'utilisateur définit les sources de données med (*datasource*),
624 c'est-à-dire les fichiers med dans lesquels sont lus les champs
625 et maillages. Cet espace est en lecture seule et permet
626 l'exploration des sources de données (aperçu des maillages et des
628 * **l'espace des données de travail** (*workspace*), dans lequel
629 l'utilisateur dépose les champs et maillages à utiliser, puis range
630 les champs produits au travers des fonctions de manipulation de
633 La figure ci-dessous en donne une représentation imagée avec le
634 support de l'interface graphique du module (interface non définitive
635 affichée ici pour illustration des spécifications):
637 .. image:: images/xmed-gui-withframe.png
640 .. note:: Techniquement, les données sources sont rangées dans l'étude
641 SALOME et peuvent être explorées au moyen de l'object browser. Les
642 données de travail sont rangées dans un arbre complémentaire et
643 manipulable dans la console python.
645 Le principe général est que **les données sources ne sont jamais
646 modifiées**. Le dataspace est un espace de chargement qui permet
647 d'explorer puis de sélectionner les données à manipuler. L'utilisateur
648 travaille à partir de maillages et de champs chargés préalablement
649 dans cet espace, mais ne peut en aucun cas les modifier
650 directement. Pour cela, il doit d'abord les sélectionner pour
651 utilisation dans l'espace de travail. Ce choix garantie l'intégrité
652 des sources de données et permet de rejouer la séquence de travail à
653 partir de zéro en cas de besoin (on efface le tableau noir et on
654 recommence). Par ailleurs, il permet d'assister graphiquement la
655 définition du champs à manipuler effectivement, en particulier pour
656 affecter un nom de variable de manipulation.
658 Les captures d'écrans suivantes montrent le principe d'utilisation sur
659 le cas de la sélection d'un pas de temps à utiliser dans l'espace de
660 travail. Les données à manoeuvrer (maillage et/ou champs) sont
661 sélectionnées pour utilisation dans l'espace de travail, où elles
662 peuvent être modifiées et/ou utilisées dans les opérations de
663 champs. Ici, le champ est désigné par la varibale ``f4`` dans
664 l'interface textuelle:
666 * Sur cette première capture, on sélectionne le pas de temps n°4 du
667 champs ``Pulse`` définit sur le maillage ``Grid_80x80`` de la source
668 de données ``timeseries.med`` (concrètement le fichier
669 ``timeseries.med``) pour faire apparaître ensuite le menu contextuel
670 et choisir l'option "Use in workspace":
672 .. image:: images/xmed-gui-datasource-contextmenu_70pc.png
675 * Cette capture montre une fenêtre de dialogue qui invite
676 l'utilisateur à spécifier un alias pour la variable python qui
677 va permettre la manipulation du champ dans l'interface textuelle de
678 l'espace de travail (par défaut, le nom complet du champ est
679 proposé). Ici, l'utilisateur spécifie ``f4``:
681 .. image:: images/xmed-gui-datasource-useinworkspace_70pc.png
684 * La validation de la fenêtre provoque l'ajout du champs dans l'espace
685 de travail (le champ est désormais disponible à la manipulation) et
686 définit une variable python de nom ``f4`` qui permet la manipulation
689 .. image:: images/xmed-gui-datasource-useinworkspace-result_70pc.png
692 Modalités d'utilisation
693 -----------------------
695 .. warning:: cette section est à nettoyer car elle contient des
696 informations redondantes avec d'autres sections précédentes ou pire
697 qui contredisent des sections précédentes.
699 Dans le cadre défini ci-dessus, une session d'utilisation type est:
701 * Sélectionner les sources de données puis définir le domaine
702 d'application (espace, temps, composantes), avec éventuellement
703 l'assistance d'une interface graphique;
704 * Charger les champs en conséquence dans l'espace de travail. Cette
705 opération propose de définir une variable python pour manipulation
706 dans l'interface textuelle.
707 * Effectuer les opérations dans l'espace de travail, c'est-à-dire en
708 ligne de commandes python (ce qui demandera sans doute un travail
709 conséquent de simplification et d'assistance en ligne). Par exemple,
710 si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de
711 travail, alors on peut en faire la somme par la commande::
715 * Effectuer les contrôles visuel et les diagnostics en ligne de
716 commandes python (cf. :ref:`Spécification des fonctions de
717 visualisation<specification_visualisation>`)::
721 * Enregistrer les champs produits dans l'espace de travail sous forme
724 Sur cette base, on peut envisager une grande variété de cas d'utilisation:
726 * La structure MED (champs, maillage et groupes de mailles) est
727 chargée dans le dataspace (l'étude SALOME techniquement) et peut
728 être explorée au niveau de l'arbre d'étude. L'arbre peut faire
731 - les maillages et les groupes (qui peuvent être utilisés
732 éventuellement pour restreindre le domaine d'application)
733 - les champs dont on peut explorer les composantes et les itérations
735 * On sélectionne plusieurs champs, éventuellement en sélectionnant les
736 pas de temps, les composantes et les domaines d'application spatiaux
737 * Menu contextuel --> Modifier un champ, Créer un champ, Prolonger un
739 * On choisi pour la suite "Créer un champ", une fenêtre de dialogue
740 s'affiche avec les saisies préremplies avec les données
741 sélectionnées. Il est possible de rajouter des éléments ou préciser
742 le domaine d'application
743 * Une partie de la boîte de dialogue est réservée à la saisie de la
744 ligne de commande python qui permet la création du nouveau champ. Le
745 nom dans l'étude pour le nouveau champ, ainsi que son nom python,
746 sont spécifié par l'utilisateur ({{H|un peu à la mode du module
748 * L'opération est exécutée dans l'espace utilisateur (l'interface
749 python), de sorte que les variables soient projetées dans cet espace
750 et manipulables après l'opération au besoin. Par ailleurs,
751 l'utilisateur peut visualiser les ligne de commandes nécessaires à
752 taper pour exécuter sa requête.
754 .. _specification_visualisation:
756 Spécification des fonctions de visualisation
757 ============================================
759 Dans le cadre du module MED, on appelle *fonction de visualisation*
760 une fonction qui permet d'avoir un aperçu graphique d'un champ, par
761 exemple au moyen d'une carte de champ construite sur une de ses
762 composante. Il s'agit là de vue de contrôle pour avoir une idée rapide
763 de la forme du champs. Pour créer des représentations spécifiques, on
764 préférera passer par les fonctions d'export vers le module PARAVIS.
766 Les modules VISU et PARAVIS offre des interface de programmation C++
767 et python qui permettent le pilotage depuis un module tiers comme le
768 module MED. On peut donc envisager une fonction de visualisation
769 intégrée au module de manipulation de champs, c'est-à-dire que l'on
770 déclenche sans sortir du module MED, et qui exploite les fonctions de
771 visualisation des modules VISU et/ou PARAVIS.
773 Les captures d'écran ci-dessous illustrent la mise en oeuvre de la
774 fonction de visualisation:
776 * Sélection d'un champ pour faire apparaitre le menu contextuel et
777 choisir l'option "Visualize":
779 .. image:: images/xmed-gui-datasource-visualize_70pc.png
782 * Cette option déclenche l'affichage d'une carte de champ sur le cadre
783 d'affichage des viewers SALOME:
785 .. image:: images/xmed-gui-datasource-visualize-result_70pc.png
788 Cette fonction est également disponible en ligne de commandes de
789 l'interface textuelle. Par exemple si ``f4`` désigne un champ de
790 l'espace de travail (importé des données source ou construit par les
791 opérations de champs), alors, on obtient une carte de champ par la
796 On peut remarquer d'ailleurs sur la capture d'écran de droite
797 ci-dessus que la demande de visualisation déclenche l'exécution de la
798 commande ``view`` dans la console de travail sur un champ identifié
799 par son numéro (3 dans l'exemple).
801 .. note:: Tous les champs, qu'ils soient des champs chargés d'une
802 source de données ou construits par des opérations de champs sont
803 identifiés par un numéro unique et invariant tout au long de la
806 Spécification des fonctions de persistance
807 ==========================================
809 On adopte le principe de fonctionnement suivant:
811 * Le module n’assure pas la persistence au sens SALOME du terme,
812 c’est-à-dire qu’il ne permet pas la sauvegarde du travail dans une
813 étude au format hdf, ni le dump sous la forme de script python
814 SALOME. Le besoin n'est pas avéré et on peut même dire que ça n'a
815 pas de sens compte-tenu de l'usage envisagé pour le module MED.
816 * Par contre, le module fournit des fonctions de sauvegarde du travail
817 sous forme de fichiers med, l’export vers les modules VISU et
818 PARAVIZ, ou même la sauvegarde de l’historique de l’interface de
821 Ainsi donc, l'utilisateur aura une fonction (probablement graphique)
822 pour définir la sélection des champs de l'espace de travail à
825 Spécification des fonctions d'export
826 ====================================
828 .. warning:: EN TRAVAUX.
830 Plusieurs export peuvent être proposés:
832 * Export des champs vers le module PARAVIZ, dans l'objectif par
833 exemple d'en faire une analyse visuelle plus poussée qu'avec les
834 cartes de champs disponibles par défaut dans le module MED
835 * Export des données sous forme de tableau numpy, par exemple pour
836 permettre un travail algorithmique sur les valeurs des champs.
838 Spécifications techniques
839 =========================
841 Il s'agit d'exprimer ici les contraintes techniques applicables à la
842 conception et au développement du nouveau module MED.
844 Implantation technique du module
845 --------------------------------
847 Il est convenu que le module MED existant dans la plate-forme SALOME
848 incarne le module de manipulation de champ. Dans la pratique, il
849 s'agit d'identifier clairement les parties à conserver, d'une part,
850 puis les parties à re-écrire, d'autre part. On peut partir sur les
851 hypothèses techniques suivantes:
853 * Le noyau du module en charge des opérations de manipulation de
854 champs proprement dites est construit sur la base des paquets
855 logiciels MEDCoupling (lui-même basé sur le INTERP_KERNEL) et
857 * L'interface graphique du module MED est complétement re-écrite et
858 remplacée par une interface adaptée spécialement à la manipulation
859 des champs et la gestion des données associées
860 * Le contrôle visuel pourra être déclenché dans les visualisateurs
861 SALOME (servis par les modules VISU et/ou PARAVIZ);
862 * Le module n'assure pas la persistence au sens SALOME du terme,
863 c'est-à-dire qu'il ne permet pas la sauvegarde du travail dans une
864 étude au format hdf, ni le dump sous la forme de script python
866 * Par contre, il fournit des fonctions de sauvegarde du travail sous
867 forme de fichiers med, l'export vers les modules VISU et PARAVIZ, ou
868 même la sauvegarde de l'historique de l'interface de commandes.
870 L'implantation technique des développements est représentée sur la
873 .. image:: images/xmed-implantation.png
876 Le schéma représente les packages logiciels qui composent le module
877 MED (cf. |REF_CEA_VBE_MEDMEM|_):
879 * La partie MEDMEM, représentées en blanc. Cette partie est conservée
880 pour compatibilité ascendante au niveau des applications métier qui
881 ont fait le choix historique de s'appuyer sur MEDMEM. Cette partie
882 du module MED aura tendance à disparaitre dans le futur au bénéfice
883 de MEDCoupling et MEDLoader.
884 * La partie MEDCoupling, représentée en orange et qui founrnit le
885 modèle MED mémoire de référence (composé de maillage et de champs)
886 et l'interface de programmation pour manipuler le modèle. Le paquet
887 MEDLoader est une extention dédiée à la persistence au format med
888 fichier (lecture et écriture de champs et de maillage dans des
890 * La partie à développer pour la manipulation de champ, représentée en
893 .. note:: MEDCoupling peut être vu comme une structure de donnée
894 particulièrement adaptée à la manipulation des gros volumes de
895 données, en particulier par l'exploitation des possibilités de
896 parallélisation et la réduction de la tailles des structures de
897 données. En contrepartie, elle peut présenter un périmètre
898 fonctionnel moins large que MEDMEM. Pour cette raison, MEDMEM avait
899 été choisi comme socle de développement du prototype en 2010:
901 * MEDCoupling ne permet pas de gérer des maillages composés de
902 plusieurs type de mailles et il est exclus de le faire évoluer
903 dans ce sens (c'est un choix fait pour les objectifs de
904 performances évoqués plus haut);
905 * MEDCoupling ne permet pas de gérer les supports qui expriment les
906 champs aux noeuds par élément ni aux points de gauss. Cette
907 seconde limitation a disparu en 2011.
909 Aujourd'hui, on fait clairement le choix de MEDCoupling pour sa
910 qualité et sa robustesse, dans l'objectif d'une meilleure
911 maintenance à long terme. Par ailleurs, les différences
912 fonctionnelles avec MEDMEM, si elles existaient encore en 2012 pour
913 les besoins de la manipulation de champs, pourront être résorbées
914 dans un futur proche.