Typo and whitespace fixes by Kunda

[modules/med.git] / doc / dev / sphinx / fr / medcalc-specifications.rst

.. meta::
   :keywords: maillage, champ, manipulation, med
   :author: Guillaume Boulant

.. include:: medcalc-definitions.rst

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Module MED: Spécifications fonctionnelles et techniques
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Ce texte présente les spécifications informatiques pour le
développement d'un module de manipulation de champs qui répond à
l'expression de besoins formulée dans le cahier des charges
|REF_EDF_VCA_H-I2C-2009-03595-FR|_.

.. contents:: Sommaire
   :local:
   :backlinks: none

Description des cas d'application de référence
==============================================

Plusieurs cas d'applications métier sont identifiés pour piloter le
développement du module de manipulation de champs:

* **Analyser et post-traiter le résultat d'un calcul**. C'est l'usage
  principal qui consiste typiquement à créer des champs comme le
  résultat d'*opérations mathématiques* dont les opérandes sont des
  champs et des scalaires. On compte également dans cette catégorie
  les *opérations de restriction* qui permettent d'extraire puis
  utiliser une partie d'un champs, c'est-à-dire de créer un champ
  comme la restriction d'un autre champ à une partie de son domaine de
  définition (certaines composantes, certains pas de temps, limitation
  à un groupe de mailles).
* **Comparer des champs issus d'un calcul paramétrique**. Il s'agit
  d'une variante du cas précédent qui consiste à mesurer et visualiser
  les variations entre des champs issues de sources de données
  différentes (différents fichiers med).
* **Préparer les conditions aux limites d'une calcul**. Il s'agit de
  pouvoir initialiser un champ sur un maillage ou un groupe de
  mailles, c'est-à-dire créer un champ de toute pièce sur un
  support spatial donné, par exemple par la donnée d'une fonction
  mathématique qui donne les valeurs des composantes en fonction des
  coordonnées spatiales.
* **Gérer des données de calcul**. Il s'agit typiquement de pouvoir
  rassembler au sein d'un même fichier med des champs et des maillages
  issues de différentes sources de données, et/ou créés au travers des
  cas d'application présentés ci-dessus.

Modèle conceptuel des données
=============================

On rappelle ici les concepts utilisés dans le module et les modalités
d'utilisation de ces concepts. Le point de vue est celui de
l'utilisateur du module de manipulation de champs. Il s'agit
essentiellement pour le moment d'éclaircir l'ergonomie d'usage sur le
plan conceptuel, avant d'aborder la déclinaison en spécifications
techniques pour lesquelles les particularités du modèle MED devront
être intégrées à la réflexion.

Concept de champ
----------------

Le concept central est celui de *champ*, c'est-à-dire une grandeur
physique exprimée sur un domaine spatial D. La grandeur peut être de
type scalaire (une température), de type vectorielle (une vitesse) ou
de type tensorielle (les contraintes). En un point de l'espace, elle
se définie donc par la donnée d'une ou plusieurs valeurs numériques
appelées les *composantes* (1 pour un champ scalaire, 3 pour un champ
vectoriel 3D, 6 pour un champ tensoriel symétrique 3D).

.. note:: Une pratique courante au niveau des codes est de stocker
   plusieurs grandeurs physiques différentes dans un même champs med
   (au sens informatique du terme). Par exemple, le champ
   électromagnétique à 6 composantes, plus le champ de température
   scalaire peuvent techniquement être stockés dans un même champs med
   à 7 composantes. C'est pourquoi, le module de manipulation de
   champs doit fournir des fonctions de restrictions qui permettent
   d'extraire certaines composantes pour former la grandeur physique à
   étudier. Dans la suite du document, on part du principe que l'on
   peut se ramener dans tous les cas au cas d'un champ homogène tel
   que défini plus haut.

Dans le cadre d'un modèle numérique discret, les valeurs du champ sont
exprimées pour un nombre fini de positions, qui correspondent à des
lieux particuliers du maillage. Suivant la nature des modèles de
calcul, les valeurs peuvent être données par cellule, par face, par
noeud, aux points de gauss, ...

Ainsi, un champ discret est un objet dont les valeurs peuvent être
lues selon les dimensions suivantes:

* *La position p dans l'espace*, caractérisée par le type de l'élément
  de maillage support et son numéro identifiant
* *La composante c*, caractérisée par son indice (jusqu'à 6
  composantes dans les modèles physiques envisagés)

L'évolution d'un champ dans le temps peut être exprimée sous la forme
d'une série temporelle, c'est-à-dire une séquence de champs donnés
pour des instants discrets. Aussi, si l'on manipule un champ qui varie
dans le temps, l'accès aux valeurs introduit une dimension
supplémentaire:

* *Le temps t*, caractérisé par un numéro de pas de temps
  (correspondant en général à une étape du calcul qui a produit le champ).

.. note:: Il s'agit là d'une représentation conceptuelle standard dont
   le |LINK_EDF_MEDDOC|_ fait une expression détaillée. En
   particulier, la position p est déterminée par la donnée du type
   d'élément support (valeurs aux noeuds, aux mailles, aux noeuds par
   éléments, aux points de gauss) et de l'indice de cet élément. En
   général, le type d'éléments support est résolu à l'initialisation
   et l'indice peut suffire au repérage dans les algorithmes. Le temps
   t est déterminé par un numéro d'itération, qui peut éventuellement
   être complété par un numéro d'ordre. Le cas des points de gauss
   ajoute un cran de complexité dans la mesure où il faut repérer
   l'entité géométrique (maille, face, arrête) puis le point de gauss
   de cette entité. A noter que dans le modèle MED, le concept de
   série temporelle de champ n'est pas explicitement définie et
   l'accès à des valeurs à différents instants t1 et t2 nécessite le
   chargement des champs ``F1=F(t1)`` et ``F2=F(t2)``.

Par convention, on utilisera par la suite les notations:

* **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U
  à la position p et prise à l'instant t;
* **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes
  les composantes;
* **U(t,:,c)** pour signifier que l'on manipule le domaine de
  définition spatial complet.

Dans une grande majorité des cas d'usage on travaille à temps t fixé
et sur un domaine spatiale prédéfini. Aussi on utilisera également la
notation à deux arguments ``U(:,:)`` ou tout simplement ``U`` (dès
lors qu'il n'y a pas ambiguïté) pour désigner un champ complet et Uc
pour désigner la composante c du champ avec c=1..6.

Concept d'opération
-------------------
Le deuxième concept à préciser est la notion d'*opération*. Une
opération dans le présent contexte est l'application d'un opérateur
sur un ou plusieurs champs pour produire une grandeur de type champ ou
de type valeur numérique.

Par exemple, la formule ``W=OP(U,V)`` indique que le champ W est formé
à partir des champs U et V en arguments d'une fonction OP. Dans le cas
d'une opération algébrique comme l'addition (cf. :ref:`Spécification
des opérations<xmed-specifications-fr>`, le résultat attendu par défaut
est que pour chaque instant t, chaque position p et chaque composante
c, on a ``W(t,p,c)=U(t,p,c)+V(t,p,c)`` (que l'on peut noter également
``W(:,:,:)=U(:,:,:)+V(:,:,:)`` compte-tenu de la convention présentée
plus haut). Ce n'est cependant pas une règle et l'utilisateur peut
très bien manoeuvrer les champs en détaillant et mixant les
composantes (par exemple ``W(:,:,3)=5+U(:,:,1)*V(:,:,2)``), ou encore
ne travailler que sur un domaine spatial et/ou temporel particulier
(cf. |REF_EDF_VCA_H-I2C-2009-03595-FR|_ §5.4.1).

On formalise donc le concept d'opération par les propriétés suivantes:

* L'opérateur peut produire un champ (par exemple la somme de deux
  champs W=sum(U,V)=U+V), une valeur numérique (par exemple la moyenne
  spatiale d'un champ m=smoy(U)) ou une valeur logique (par exemple le
  test d'égalité de deux champs b=isequal(U,V));
* L'opérateur peut être paramétré par la donnée de valeurs numériques
  (par exemple, le changement d'unité peut être défini comme une
  multiplication par un scalaire V=multiply(U,1000)=1000*U);
* L'opérateur est caractérisé par un domaine d'application qui
  spécifie la portée de l'opération. Ce domaine comporte plusieurs
  dimensions:

  - Un domaine temporel T qui spécifie les pas de temps sur lesquels
    l'opération est appliquée;
  - Un domaine spatial D qui spécifie la limite de portée de
    l'opérateur et donc le domaine de définition du champ produit (qui
    correspond dans ce cas à une restriction du domaine de définition
    des champs en argument);
  - Un domaine de composantes C qui spécifie les composantes sur
    lesquelles l'opération est appliquée;

.. note::
   Sur le plan informatique, l'opérateur aura également un paramètre
   appelé *option* qui pourra indiquer par exemple dans une
   opération unaire V=F(U) si le résultat V est une nouvelle instance
   de champ ou la valeur modifiée du champ de départ U. Il pourra
   également être amené à manoeuvrer des paramètres de type chaîne de
   caractères, par exemple pour les opérations de changement de nom
   des champs.

De manière générale, on utilisera la notation
**(W|y)=OP[D,C,T](P,U,V,...)** pour désigner une opération OP:

* **(V|y)**: V ou y désignent respectivement un résultat de type
  champ ou de type valeur numérique ou logique;
* **[T,D,C]**: le domaine d'application de l'opérateur avec T le
  domaine temporel, D le domaine spatial et C le domaine des
  composantes;
* **P,U,V,...**: les paramètres numériques P (liste de valeurs
  numériques) et les champs U,V,... en arguments de l'opérateur;

On note également les particularités suivantes pour certaines
opérations:

* Le domaine de définition du champ produit par une opération peut
  être différent du domaine de définition des champs en argument. Par
  exemple, dans le cas d'une opération de projection de champ, le
  domaine spatial résultat peut être modifié par rapport au domaine de
  définition initial, soit par la modification de la zone géométrique,
  soit par modification des entités de maillage support.
* En dehors des opérations de type dérivée et intégrale, les valeurs
  résultats sont déterminées de manière locale en chaque point du
  domaine d'application. Par exemple, l'addition W=U+V consiste à
  produire un champ W dont les valeurs en chaque point p sont la somme
  des valeurs des composantes de U et V en ce point p: ``W=U+V <=>
  W(:,p,:)=U(:,p,:)+V(:,p,:)`` pour tout point p du domaine
  d'application D.

Concept de domaine d'application
--------------------------------

Un domaine d'application est associé à une opération (et non pas à un
champ). Il a pour objectif de restreindre la portée de l'opération en
terme spatial, temporel, jeu des composantes.

Pour ce qui concerne le domaine spatial D, plusieurs modalités de
définition sont envisagées:

* la donnée d'un maillage ou d'un groupe d'éléments du maillage;
* un système de filtres qui peut combiner:

  - une zone géométrique définie indépendamment du maillage (boîte
    limite par exemple),
  - des critères conditionnant le calcul (par exemple U(t,p,c)=1 si
    V(t,p,c)<seuil).

.. warning:: Version 2010: D pourra correspondre au maillage complet
   et dans la mesure du possible à un groupe d'éléments du maillage

Ce domaine d'application peut être différent du domaine de définition
des champs mais il doit être compatible (recouvrement spatial partiel
au moins et même support d'entité de maillage). Ainsi, sans précision
particulière, une opération s'applique à l'ensemble du domaine de
définition des champs en argument (qui dans la pratique MED est
spécifié par le support et correspond en général au maillage
complet).

Limites d'utilisation
---------------------

Plusieurs situations doivent être examinées pour poser les limites
d'utilisation:

* Les champs en argument n'ont pas tous le même domaine de définition,
  par exemple parcequ'il ne sont pas définis sur les mêmes zones
  géométriques ou parcequ'ils ne sont pas donnés sur le même type
  d'entité de maillage. On peut imaginer dans ce cas produire le
  résultat sur les zones de recouvrement uniquement.
* Le domaine de définition des champs et le domaine d'application de
  l'opérateur ne sont pas compatibles, par exemple parcequ'on demande
  une restriction sur une zone géométrique qui ne fait pas partie de
  la zone de définition du champ d'entrée. A priori, ce type
  d'opération est déclaré en échec.
* Les champs en argument ne sont pas définis sur les mêmes pas de
  temps. Si l'opération est tolérée (techniquement MEDCoupling permet
  de le faire), le pas de temps résultat est indéfini.

.. warning:: **A faire**: spécifier les modalités de prise en compte de
   ces différentes situations (au moins sur le plan conceptuel).

Au delà de ces limites conceptuelles, il faut avoir en tête les
limites techniques liées à l'usage de MED mémoire (paquet
MEDCoupling). Par exemple, MEDCoupling impose que les champs opérandes
soient définis sur le même maillage support (on parle ici de l'objet
informatique correspondant au maillage). Deux champs construits sur le
même maillage (du point de vue conceptuel) mais issus de deux fichiers
med différents sont considérés comme des champs définis sur des
maillages support différents, c'est-à-dire que les objects
informatiques correspondant aux maillages sont différents (chargés de
deux fichiers différents). En l'état, il est donc impossible par
exemple de faire la comparaison de champs résultats d'une étude
paramétriques. MEDCoupling fournit une solution qu'il faudra mettre en
oeuvre de manière ergonomique au niveau du module MED. Il est possible
de changer le maillage support M1 d'un champs par un maillage M2 à
partir du moment où les maillages M1 et M2 sont identiques
géométriquement à une erreur près qu'il est possible de spécifier.

.. note::
   D'autres situations limites peuvent être évoquées sous l'angle
   informatique. Ce sont des situations qui a priori n'ont pas de
   raison d'exister sur le plan conceptuel mais qui peuvent très bien
   survenir au niveau du module informatique compte-tenu des
   particularités du modèle MED. Par exemple:

   * Le nombre et la nature des composantes ne sont pas identiques
     pour tous les champs d'entrée. Par exemple, U défini ses
     composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les
     défini comme U(:,:,1)=Uz, U(:,:,2)=Ux, U(:,:,3)=Uy. Cette
     situation peut être gérée techniquement par exemple au moyen
     d'une carte de correspondance qui accompagnerai chacun des champs
     pour exprimer le sens physique de chaque composants (histoire de
     ne pas ajouter des choux et des carottes).

Spécifications générales
========================

Le diagramme ci-dessous représente un découpage fonctionnel qui rend
compte de l'expression des besoins:

.. image:: ../images/xmed-functions.png
   :align: center

On peut identifier les fonctionnalités suivantes:

* **Opérations**: fonctions de manipulation de champs proprement
  dites;
* **Persistance**: fonctions d'enregistrement persistant et de
  chargement des données (au format med fichier)
* **Visualisation**: fonctions de contrôle visuel des champs
  manipulés
* **Export des données**: fonction de transposition des données de
  champs dans un format textuel directement exploitable et de manière
  autoportante dans une autre application, par exemple en python au
  moyen des structures de données Numpy.

Ces fonctions s'articulent autour d'un conteneur qui héberge les
champs manipulés et les supports de ces champs (représenté par le
cylindre central).

Un scénario d'utilisation type est:

* Préparation des champs à manipuler, par deux moyens complémentaires:

  - Utilisation des fonctions de persistance: chargement depuis un
    fichier med d'un ensemble de champs qui partagent le même espace
    de définition;
  - Utilisation des opérations de champs: chargement d'un maillage
    depuis un fichier med, puis création ab initio de champs au moyen
    des opérations de champs;

* Manipulation des champs par application des opérations à
  disposition, puis contrôle visuel des résultats produits au moyen
  des fonctions de visualisation mises à disposition par SALOME;
* Restitution des résultats produits, par deux moyens complémentaires:

  - Restitution des champs produits et/ou modifiés sous une forme
    persistante (fichier med);
  - Restitution d'une partie seulement des résultats sous forme de
    tableaux de valeurs sauvegardés dans un fichier texte ou exporté
    sous forme de tableau numpy

.. _xmed-specifications-fr:

Spécification des opérations
============================

Le cahier des charges définit trois catégories d'opérations
mathématiques:

* **Les opérations arithmétiques**, dans lesquelles le résultat à la
  position p et à l'instant t ne dépend que des données à la position
  p et à l'instant t;
* **Les opérations d'interpolations**, dans lesquelles le résultat
  est exprimé sur des entités de maillages différentes ou est projeté
  sur une zone géométrique différente du domaine de définition
  initial;
* **Les opérations globales**, dans lesquelles le résultat peut
  demander l'agrégation des valeurs sur plusieurs position p ou
  plusieurs pas de temps t (calcul d'extremum, d'intégrale);

Auxquelles, on peut ajouter à des fins de gestion des données:

* **Les opérations de génération**, qui permettent de créer un champ
  sur un maillage vierge ou d'étendre le domaine spatial de définition
  d'un champ;
* **Les opérations d'ordre sémantique**, qui permettent de modifier
  les méta-données associées aux champs (nom, unité, ...)
* **Les opérations de diagnostic**, qui permettent d'effectuer une
  analyse particulière d'un champ et/ou des éléments de maillage
  associés et de fournir un compte-rendu, sous la forme d'une
  structure de données ou d'un texte formaté affichable dans
  l'interface utilisateur.

La suite de la section décrit les spécifications prévues pour chaque
type d'opération unitaire. Un dernier paragraphe concerne les
modalités de combinaison des opérations et spécifie la définition d'un
domaine d'application sur une opération, qui permet de restreindre la
portée de l'opération en terme spatial, temporelle ou nature des
composantes impliquées.

Les opérations arithmétiques
----------------------------

Les opérations arithmétiques regroupent:

* les **opérations algébriques** (+, -, x, /);
* les **opérations vectorielles** (produit scalaire, produit
  vectoriel, produit tensoriel);
* l'**application d'une fonction mathématique** à variable scalaire
  (exponentielle, logarithme, fonctions trigonométriques, valeur
  absolue, partie entière) ou à variable de type champ (les fonctions
  de norme par exemple).

Pour les besoins des spécifications informatiques, il est plus commode
de classer ces opérations en deux catégories:

* les **opérations unaires**, qui prennent un opérande unique en
  argument. C'est le cas de la plupart des fonctions mathématiques
  envisagées;
* les **opérations binaires**, qui prennent deux opérandes en
  argument. C'est le cas des opérations algébriques et des opérations
  vectorielles.

A partir de cette classification, il convient de distinguer trois
formes d'usage selon la nature des opérandes:

* les opérandes sont exclusivement des scalaires (typiquement des
  valeurs de composantes des champs et des paramètres numériques). Par
  exemple::

    W(:,:4) = 1+2xU(:,:,2)+V(:,:,3)

* les opérandes sont exclusivement des champs. Par exemple::

    W = U + V       (addition)
    W = U ^ V       (produit vectoriel)

* les opérandes sont des champs et des paramètres numériques. Par exemple::

    W = 3xU - 2xV
    W = U + 2

Le premier cas de figure (opérandes scalaires) est trivial car les
règles mathématiques conventionnelles s'appliquent et sont
implémentées dans tous les langages (Python et C++ en
particulier). Les cas 2 et 3 par contre doivent être précisés car (i)
les règles de comportement ne peuvent pas être simplement déduites des
règles mathématiques (quel est le résultat de ``W = U + 2`` ?) et
(ii) certaines écritures ne peuvent avoir aucun sens (par exemple
``W = 2 / U``). Il convient donc de  préciser les conventions et
les limites sur ces deux cas de figure.

Dans le cas des opérations unaires où l'opérande est un champ, on doit
distinguer deux cas d'usage:

* l'application d'une fonction mathématique à valeur de type champ. Ce
  cas est trivial également et on applique la règle d'usage de la
  fonction. C'est typiquement le cas des fonctions de calcul de
  norme.
* l'application d'une fonction mathématique à valeur scalaire. Dans ce
  cas, on convient d'appliquer la fonction de manière unitaire sur
  chacune des composantes c du champ: ``W(:,:,c) = OP( U(:,:,c)
  )``

Dans le cas des opérations binaires, on recense les combinaisons
d'opérandes suivantes (les lettres capitales représentent des champs,
et les lettres minuscules une valeur scalaire qui peut être un
paramètre numérique ou la composante d'un champ):

* U+V ajoute les composantes en regard: W(:,:,c)=U(:,:,c)+V(:,:,c)
* U-V soustrait les composantes en regard: W(:,:,c)=U(:,:,c)-V(:,:,c)
* U*V multiplie les composantes en regard: W(:,:,c)=U(:,:,c)*V(:,:,c)
* U/V divise les composantes en regard: W(:,:,c)=U(:,:,c)/V(:,:,c)
* U+x ajoute x à toute les composantes: W(:,:,c)=U(:,:,c)+x
* U*x multiplie toutes les composantes par x: W(:,:,c)=U(:,:,c)*x
* U.V produit scalaire des champs U et V: W(:,:c)=U(:,:,c)*V(:,:,c)
* U^V produit vectoriel des champs U et V: W(:,:1)=U(:,:,2)*V(:,:,3)-U(:,:,3)*V(:,:,2), ...

.. note::
   Pour ce qui concerne les opérations vectorielles, un convention
   implicite est appliquée par laquelle on suppose que les composantes
   sont rangées dans l'ordre des dimensions spatiales U1=Ux, U2=Uy,
   U3=Uz. Sur le plan informatique au niveau du modèle MEDMEM, ceci
   n'est pas garanti et aucun élément du modèle ne permet de
   contraindre l'application de cette convention. Il convient donc de
   prévoir des fonctions techniques qui permettront de mettre en
   correspondance les indices de composantes et les dimensions
   spatiales (par exemple par la données d'une carte de correspondance
   applicable à un ensemble de champs).

.. warning::
   A développer:

   * Analyse dimensionnelle du champ résultats pour adapter
     l'unité. Par exemple, si on fait UxV où U et V sont exprimés en
     [m] alors le résultat est en [m2].

Les opérations d'interpolation
------------------------------
.. warning:: Non prévues au programme 2010.

Les opérations mathématiques globales
-------------------------------------
.. warning:: Non prévues au programme 2010.

Les opérations de génération
----------------------------
.. warning:: EN TRAVAUX

Les opérations de génération sont des fonctions qui permettent de
créer un champ sur un domaine du maillage où il n'est pas défini
initialement. Deux cas de figure peuvent se présenter:

* Le champ n'existe pas et il doit être créé sur un domaine à définir;
* Le champ existe mais les valeurs ne sont pas définies sur l'ensemble
  du maillage.

On peut envisager plusieurs modalités de mise en oeuvre:

* le prolongement par une valeur constante (ou plus généralement par
  une fonction de l'espace?);
* les valeurs du champs sont données par une fonction f(p,t) qui prend
  la position p et le pas de temps t en argument;
* on peut prédéfinir le champ position **r** qui porte les
  coordonnées spatiales de l'élément de maillage support, puis faire
  une opération arithmétique standard.

Les opérations d'ordre sémantique
---------------------------------
.. warning:: EN TRAVAUX

Concerne:

* le changement de nom du champ
* le changement d'unité du champ (il s'agit ici de conserver la
  cohérence entre la valeur numérique et l'attribut "unité" d'un
  champ.

Les opérations de diagnostic
----------------------------
.. warning:: EN TRAVAUX. A faire en fonction des besoins des cas d'application

On peut identifier plusieurs types d'opérations:

* les opérations à diagnostic booléen, par exemple
  b=isequal(U,V)=[U=V] (où [.] signifie évaluation de la condition
  entre crochers)
* les opérations à diagnostic textuel, par exemple afficher les
  méta-données associées à un champs (unité, nom, maillage support,
  type d'entité, pas de temps, ...)
* les opérations à diagnostic structuré, qui donneraient une structure
  de données exploitable au niveau d'un code logiciel.

Combinaison des opérations
--------------------------
.. warning:: EN TRAVAUX. Indiquer les règles de combinaison (associativité, commutativité, ...)

Définition d'un domaine d'application
-------------------------------------
Pour rappel, un domaine d'application peut être associé à une
opération pour restreindre la portée de l'opération en terme spatial,
temporelle ou nature des composantes impliquées.

.. warning:: Todo: spécifier comment on le définit et les modalités d'applications.

Spécification de l'ergonomie
============================

L'ergonomie générale d'utilisation du module de manipulation de champs
est inspirée des logiciels comme octave ou scilab. Elle associe une
interface graphique, pour sélectionner et préparer les données, avec
une interface texte (la console python) pour le travail effectif sur
les données:

* L'**interface graphique** a pour fonction essentielle de sélectionner et
  préparer les champs à manipuler dans l'interface texte, puis
  fournit des fonctions pour la gestion générale des données
  (chargement, sauvegarde, contrôle visuel, export).
* L'**interface texte** offre un jeu de commandes pour manipuler les
  champs (afficher les données, effectuer des opérations), piloter les
  fonctions d'affichage (contrôle visuel au moyen des modules VISU
  et/ou PARAVIS) et communiquer avec l'interface graphique (ajouter
  des nouveaux champs dans l'espace de gestion, mettre à jour les
  méta-données d'un champ).

Sur le plan de l'ergonomie, cela se traduit par un processus de
travail dans lequel on peut distinguer différentes phases:

* Une phase de préparation des champs à manoeuvrer sous la forme de
  variables nommées et simples à manipuler dans l'interface
  textuelle. Lors de cette phase, l'utilisateur spécifie de manière
  graphique tout ce qui peut être définis à l'avance et pour toute la
  durée du processus de travail. Par exemple, en spécifiant le nom des
  fichiers med source des données et les noms des champs à utiliser
  dans ces fichiers, le pas de temps de travail, le jeu des
  composantes à considérer, le domaine d'application des opérations;
* Une phase de manipulation des champs proprement dite, qui a lieu
  principalement dans l'interface textuelle, et qui peut s'accompagner
  de contrôle visuel des résultats et/ou d'export à destination
  d'outils complémentaires indépendants (gnuplot, python, ...);
* Une phase de restitution des champs produits pour assurer la
  persistance des données de travail. Tout les champs créés par les
  manipulations au niveau de l'interface textuelle ne sont pas à
  sauvegarder, et on on propose donc à l'utilisateur les moyens de
  choisir les champs à conserver. Cette phase peut amener
  l'utilisateur à préciser les informations manquantes, comme les noms
  de fichiers, les noms de champs produits, les unités, ...

Dans ce cadre, l'utilisation type des fonctions de manipulation de
champs est un processus de la forme suivante:

1. Chargement d'un fichier med dans SALOME et exploration du contenu,
   composé de maillages, sur lesquels sont définis des champs, pouvant
   contenir un ou plusieurs pas de temps.
2. Sélection (graphique) des champs à manipuler, avec la possibilité
   de préciser des restrictions d'utilisation (pas de temps,
   composantes, groupe de maille).
3. Création de nouveaux champs par l'exécution d'opérations
   algébriques (+,-,*,/) entre champs, l'application de fonctions
   mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
   "from scratch" à partir d'un maillage support.
4. Contrôle visuel rapide des champs produits (avec les modules VISU
   et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
   utilisateur)
5. Enregistrement d'une partie des champs produits dans un fichier med


Les espaces de données utilisateur
----------------------------------

Sur le plan conceptuel, on est amené à définir deux espaces de données
utilisateur:

* **l'espace des données source** (*dataspace*), dans lequel
  l'utilisateur définit les sources de données med (*datasource*),
  c'est-à-dire les fichiers med dans lesquels sont lus les champs
  et maillages. Cet espace est en lecture seule et permet
  l'exploration des sources de données (aperçu des maillages et des
  champs).
* **l'espace des données de travail** (*workspace*), dans lequel
  l'utilisateur dépose les champs et maillages à utiliser, puis range
  les champs produits au travers des fonctions de manipulation de
  champs.

La figure ci-dessous en donne une représentation imagée avec le
support de l'interface graphique du module (interface non définitive
affichée ici pour illustration des spécifications):

.. image:: ../images/xmed-gui-withframe.png
   :align: center

.. note:: Techniquement, les données sources sont rangées dans l'étude
   SALOME et peuvent être explorées au moyen de l'object browser. Les
   données de travail sont rangées dans un arbre complémentaire et
   manipulable dans la console python.

Le principe général est que **les données sources ne sont jamais
modifiées**. Le dataspace est un espace de chargement qui permet
d'explorer puis de sélectionner les données à manipuler. L'utilisateur
travaille à partir de maillages et de champs chargés préalablement
dans cet espace, mais ne peut en aucun cas les modifier
directement. Pour cela, il doit d'abord les sélectionner pour
utilisation dans l'espace de travail. Ce choix garantie l'intégrité
des sources de données et permet de rejouer la séquence de travail à
partir de zéro en cas de besoin (on efface le tableau noir et on
recommence). Par ailleurs, il permet d'assister graphiquement la
définition du champs à manipuler effectivement, en particulier pour
affecter un nom de variable de manipulation.

Les captures d'écrans suivantes montrent le principe d'utilisation sur
le cas de la sélection d'un pas de temps à utiliser dans l'espace de
travail. Les données à manoeuvrer (maillage et/ou champs) sont
sélectionnées pour utilisation dans l'espace de travail, où elles
peuvent être modifiées et/ou utilisées dans les opérations de
champs. Ici, le champ est désigné par la varibale ``f4`` dans
l'interface textuelle:

* Sur cette première capture, on sélectionne le pas de temps n°4 du
  champs ``Pulse`` définit sur le maillage ``Grid_80x80`` de la source
  de données ``timeseries.med`` (concrètement le fichier
  ``timeseries.med``) pour faire apparaître ensuite le menu contextuel
  et choisir l'option "Use in workspace":

.. image:: ../images/xmed-gui-datasource-contextmenu_70pc.png
   :align: center

* Cette capture montre une fenêtre de dialogue qui invite
  l'utilisateur à spécifier un alias pour la variable python qui
  va permettre la manipulation du champ dans l'interface textuelle de
  l'espace de travail (par défaut, le nom complet du champ est
  proposé). Ici, l'utilisateur spécifie ``f4``:

.. image:: ../images/xmed-gui-datasource-useinworkspace_70pc.png
   :align: center

* La validation de la fenêtre provoque l'ajout du champs dans l'espace
  de travail (le champ est désormais disponible à la manipulation) et
  définit une variable python de nom ``f4`` qui permet la manipulation
  du champ:

.. image:: ../images/xmed-gui-datasource-useinworkspace-result_70pc.png
   :align: center

Modalités d'utilisation
-----------------------

.. warning:: cette section est à nettoyer car elle contient des
   informations redondantes avec d'autres sections précédentes ou pire
   qui contredisent des sections précédentes.

Dans le cadre défini ci-dessus, une session d'utilisation type est:

* Sélectionner les sources de données puis définir le domaine
  d'application (espace, temps, composantes), avec éventuellement
  l'assistance d'une interface graphique;
* Charger les champs en conséquence dans l'espace de travail. Cette
  opération propose de définir une variable python pour manipulation
  dans l'interface textuelle.
* Effectuer les opérations dans l'espace de travail, c'est-à-dire en
  ligne de commandes python (ce qui demandera sans doute un travail
  conséquent de simplification et d'assistance en ligne). Par exemple,
  si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de
  travail, alors on peut en faire la somme par la commande::

  >>> r=fa+fb

* Effectuer les contrôles visuel et les diagnostics en ligne de
  commandes python (cf. :ref:`Spécification des fonctions de
  visualisation<specification_visualisation>`)::

  >>> view(r)

* Enregistrer les champs produits dans l'espace de travail sous forme
  de fichier med.

Sur cette base, on peut envisager une grande variété de cas d'utilisation:

* La structure MED (champs, maillage et groupes de mailles) est
  chargée dans le dataspace (l'étude SALOME techniquement) et peut
  être explorée au niveau de l'arbre d'étude. L'arbre peut faire
  apparaître:

  - les maillages et les groupes (qui peuvent être utilisés
    éventuellement pour restreindre le domaine d'application)
  - les champs dont on peut explorer les composantes et les itérations

* On sélectionne plusieurs champs, éventuellement en sélectionnant les
  pas de temps, les composantes et les domaines d'application spatiaux
* Menu contextuel --> Modifier un champ, Créer un champ, Prolonger un
  champ, ....
* On choisi pour la suite "Créer un champ", une fenêtre de dialogue
  s'affiche avec les saisies préremplies avec les données
  sélectionnées. Il est possible de rajouter des éléments ou préciser
  le domaine d'application
* Une partie de la boîte de dialogue est réservée à la saisie de la
  ligne de commande python qui permet la création du nouveau champ. Le
  nom dans l'étude pour le nouveau champ, ainsi que son nom python,
  sont spécifié par l'utilisateur ({{H|un peu à la mode du module
  system}}).
* L'opération est exécutée dans l'espace utilisateur (l'interface
  python), de sorte que les variables soient projetées dans cet espace
  et manipulables après l'opération au besoin. Par ailleurs,
  l'utilisateur peut visualiser les ligne de commandes nécessaires à
  taper pour exécuter sa requête.

.. _specification_visualisation:

Spécification des fonctions de visualisation
============================================

Dans le cadre du module MED, on appelle *fonction de visualisation*
une fonction qui permet d'avoir un aperçu graphique d'un champ, par
exemple au moyen d'une carte de champ construite sur une de ses
composante. Il s'agit là de vue de contrôle pour avoir une idée rapide
de la forme du champs. Pour créer des représentations spécifiques, on
préférera passer par les fonctions d'export vers le module PARAVIS.

Les modules VISU et PARAVIS offre des interface de programmation C++
et python qui permettent le pilotage depuis un module tiers comme le
module MED. On peut donc envisager une fonction de visualisation
intégrée au module de manipulation de champs, c'est-à-dire que l'on
déclenche sans sortir du module MED, et qui exploite les fonctions de
visualisation des modules VISU et/ou PARAVIS.

Les captures d'écran ci-dessous illustrent la mise en oeuvre de la
fonction de visualisation:

* Sélection d'un champ pour faire apparaitre le menu contextuel et
  choisir l'option "Visualize":

.. image:: ../images/xmed-gui-datasource-visualize_70pc.png
   :align: center

* Cette option déclenche l'affichage d'une carte de champ sur le cadre
  d'affichage des viewers SALOME:

.. image:: ../images/xmed-gui-datasource-visualize-result_70pc.png
   :align: center

Cette fonction est également disponible en ligne de commandes de
l'interface textuelle. Par exemple si ``f4`` désigne un champ de
l'espace de travail (importé des données source ou construit par les
opérations de champs), alors, on obtient une carte de champ par la
commande::

 >>> view(f4)

On peut remarquer d'ailleurs sur la capture d'écran de droite
ci-dessus que la demande de visualisation déclenche l'exécution de la
commande ``view`` dans la console de travail sur un champ identifié
par son numéro (3 dans l'exemple).

.. note:: Tous les champs, qu'ils soient des champs chargés d'une
   source de données ou construits par des opérations de champs sont
   identifiés par un numéro unique et invariant tout au long de la
   session de travail.

Spécification des fonctions de persistance
==========================================

On adopte le principe de fonctionnement suivant:

* Le module n’assure pas la persistence au sens SALOME du terme,
  c’est-à-dire qu’il ne permet pas la sauvegarde du travail dans une
  étude au format hdf, ni le dump sous la forme de script python
  SALOME. Le besoin n'est pas avéré et on peut même dire que ça n'a
  pas de sens compte-tenu de l'usage envisagé pour le module MED.
* Par contre, le module fournit des fonctions de sauvegarde du travail
  sous forme de fichiers med, l’export vers les modules VISU et
  PARAVIZ, ou même la sauvegarde de l’historique de l’interface de
  commandes.

Ainsi donc, l'utilisateur aura une fonction (probablement graphique)
pour définir la sélection des champs de l'espace de travail à
sauvegarder.

Spécification des fonctions d'export
====================================

.. warning:: EN TRAVAUX.

Plusieurs export peuvent être proposés:

* Export des champs vers le module PARAVIZ, dans l'objectif par
  exemple d'en faire une analyse visuelle plus poussée qu'avec les
  cartes de champs disponibles par défaut dans le module MED
* Export des données sous forme de tableau numpy, par exemple pour
  permettre un travail algorithmique sur les valeurs des champs.

Spécifications techniques
=========================

Il s'agit d'exprimer ici les contraintes techniques applicables à la
conception et au développement du nouveau module MED.

Implantation technique du module
--------------------------------

Il est convenu que le module MED existant dans la plate-forme SALOME
incarne le module de manipulation de champ. Dans la pratique, il
s'agit d'identifier clairement les parties à conserver, d'une part,
puis les parties à re-écrire, d'autre part. On peut partir sur les
hypothèses techniques suivantes:

* Le noyau du module en charge des opérations de manipulation de
  champs proprement dites est construit sur la base des paquets
  logiciels MEDCoupling (lui-même basé sur le INTERP_KERNEL) et
  MEDLoader.
* L'interface graphique du module MED est complétement re-écrite et
  remplacée par une interface adaptée spécialement à la manipulation
  des champs et la gestion des données associées
* Le contrôle visuel pourra être déclenché dans les visualisateurs
  SALOME (servis par les modules VISU et/ou PARAVIZ);
* Le module n'assure pas la persistence au sens SALOME du terme,
  c'est-à-dire qu'il ne permet pas la sauvegarde du travail dans une
  étude au format hdf, ni le dump sous la forme de script python
  SALOME.
* Par contre, il fournit des fonctions de sauvegarde du travail sous
  forme de fichiers med, l'export vers les modules VISU et PARAVIZ, ou
  même la sauvegarde de l'historique de l'interface de commandes.

L'implantation technique des développements est représentée sur la
figure ci-dessous:

.. image:: ../images/xmed-implantation.png
   :align: center

Le schéma représente les packages logiciels qui composent le module
MED (cf. |REF_CEA_VBE_MEDMEM|_):

* La partie MEDMEM, représentées en blanc. Cette partie est conservée
  pour compatibilité ascendante au niveau des applications métier qui
  ont fait le choix historique de s'appuyer sur MEDMEM. Cette partie
  du module MED aura tendance à disparaitre dans le futur au bénéfice
  de MEDCoupling et MEDLoader.
* La partie MEDCoupling, représentée en orange et qui founrnit le
  modèle MED mémoire de référence (composé de maillage et de champs)
  et l'interface de programmation pour manipuler le modèle. Le paquet
  MEDLoader est une extention dédiée à la persistence au format med
  fichier (lecture et écriture de champs et de maillage dans des
  fichiers med).
* La partie à développer pour la manipulation de champ, représentée en
  bleu.

.. note:: MEDCoupling peut être vu comme une structure de donnée
   particulièrement adaptée à la manipulation des gros volumes de
   données, en particulier par l'exploitation des possibilités de
   parallélisation et la réduction de la tailles des structures de
   données. En contrepartie, elle peut présenter un périmètre
   fonctionnel moins large que MEDMEM. Pour cette raison, MEDMEM avait
   été choisi comme socle de développement du prototype en 2010:

   * MEDCoupling ne permet pas de gérer des maillages composés de
     plusieurs type de mailles et il est exclus de le faire évoluer
     dans ce sens (c'est un choix fait pour les objectifs de
     performances évoqués plus haut);
   * MEDCoupling ne permet pas de gérer les supports qui expriment les
     champs aux noeuds par élément ni aux points de gauss. Cette
     seconde limitation a disparu en 2011.

   Aujourd'hui, on fait clairement le choix de MEDCoupling pour sa
   qualité et sa robustesse, dans l'objectif d'une meilleure
   maintenance à long terme. Par ailleurs, les différences
   fonctionnelles avec MEDMEM, si elles existaient encore en 2012 pour
   les besoins de la manipulation de champs, pourront être résorbées
   dans un futur proche.