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