ANNEXE: Note de travail concernant le chantier XMED 2011

Cas d’utilisation métier

On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011):

J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
ajouter de nouveaux champs issus de champs existants. J'aimerais
aussi pouvoir créer de nouveaux meds plus petits par extraction de
certaines composantes de champs, certains groupes ou certains pas de
temps.

On peut exprimer le besoin sous la forme des cas d’utilisation suivants (use cases):

• UC1: combiner dans un même fichier med des champs issus de plusieurs sources de données. On peut par exemple charger un premier fichier, puis ajouter à cette base des champs issus d’autre fichiers ou générés par manipulation de champs, ou encore générés par un module de calcul qui produirait directement du MEDCoupling.
• UC2: créer un champ contenant certaines composantes d’un autre champ. On pense ici aux fonctions de restriction, qui permettraient de récupérer certaines composantes uniquement.
• UC3: créer un champ contenant certains pas de temps d’un autre champ. C’est un cas particulier des fonctions de restriction évoquées ci-dessus.
• UC4: créer un champ comme la limitation d’un autre champ à un groupe de mailles. C’est un cas particulier des fonctions de restriction évoquées ci-dessus. Notion de domaine spatial. A priori la notion de groupe est définie dans MEDLoader.

On peut ajouter également les UC identifiés pour la maquette 2010:

• UC5: comparer des champs issus de source de données différentes, par exemple des champs chargés de deux fichiers med différents et qui s’appuient sur le même maillage (au moins conceptuellement). Le problème technique ici est de pouvoir changer le maillage d’un champ, pour ramener tous les champs sur le même maillage (au sens informatique). Ceci est une contrainte de MEDCoupling, les opérations sur des champs A et B imposent que A et B soient définis sur le même maillage, i.e. le même objet informatique.
• UC6: créer un champ de toute pièce sur un maillage, ou un groupe de mailles. Ce cas d’usage est typiquement prévu pour produire les conditions de chargement initial d’une structure. Il s’agit ici d’initialiser un champ à partir de zéro sur une surface prédéfinie de la géométrie (par exemple spécifiée par un nom de groupe de mailles).

Pour UC5: les sources de données sont référencées dans l’object browser. On importe explicitement les données dans l’espace de travail. On peut détecter que les maillages sont identiques et on propose à l’utilisateur de transférer le champ sur le maillage déjà présent. Sinon, les champs devront être référencés sur des maillages distincts dans l’arbre de l’espace de travail.

Analyses préliminaires pour le chantier 2011

On fait le choix pour le chantier 2011 de travailler à partir de la bibliothèque MEDCoupling (et non plus MEDMEM comme c’était le cas dans le démonstrateur 2011).

Analyse de MEDCoupling et MEDLoader

MEDCoupling est l’implémentation du modèle de données MED (avec recherche de minimisation des dépendances logicielles) et MEDLoader fournit une ensemble de fonctions pour le chargement des structures MEDCoupling depuis un fichier ou inversement leur sauvegarde sous forme de fichiers.

Dans l’implémentation MEDCoupling, un champ est l’ensemble des valeurs d’une grandeur physique sur un maillage pour un pas de temps donné. Un champ est caractérisé par:

• un support spatial, le maillage
• un type de discrétisation spatial, défini par l’emplacement des valeurs sur le maillage (sur les noeuds, sur les cellules, aux points de gauss, ...) et le mode d’interpolation spatial (P0, P1, etc)
• un pas de temps, défini par deux entiers (iteration, order) et un réel (timestamps)

Dans cette implémentation, il existe une association 1..n entre un maillage et un champ (alors que dans MEDMEM, la structure intermédiaire SUPPORT est implémentée).

MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer des structures MEDCoupling au travers du bus CORBA. L’interface à ce jour est délibérément réduite. Des classes dites “Cliente” sont fournies pour piloter les servants CORBA depuis un contexte client. Par exemple MEDCouplingFieldDoubleClient fournit une fonction de création d’une structure MEDCoupling à partir d’un pointeur vers un servant CORBA. La structure est créée localement (dans le contexte client) avec duplication des données issue de la structure encapsulée par le servant CORBA (récupération par la fonction de sérialisation).

Aucune interface CORBA n’est défini pour MEDLoader.

Questions:

• Voir comment sont créés les servants, et surtout comment ils sont récupérés (via le lcc?)
• Comment peut-on définir un champ sur un groupe de mailles (et non pas sur le maillage complet)? Comment peut-on extraire le champs circoncit à une groupe de mailles pour des opérations.
  • R: méthode changeUnderlyingMesh
• Comment manipuler deux champs chargées de fichiers différents mais construit sur le même maillage (conceptuellement). On peut forcer la réassociation d’un champ sur un autre maillage?
• Manipuler des champs de pas de temps différents? Différentes composantes d’un ou plusieurs champs?
• Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
• mapper sur une image

Improvments:

• MEDLoader::Write should raise an exception if the filepath is not writable
• MEDDataManager: développer une classe chapeau sur MEDCoupling et MEDLoader pour aider au chargement et la gestion de données MED (orienté manipulation de champs). Cette classe serait associée des structures légères FieldHandler et MeshHandler et des listes correspondantes pour la navigation dans les méta-données.
• Sur base du MEDDataManager, prévoir des ports med pour yacs par lesquels pourrait transiter des handler.

Nouveaux concepts à prendre en compte

Au démarrage du chantier 2011, on observe que les concepts suivants sont introduits dans le module MED:

• Le conteneur MED n’existe plus, utiliser MEDFILEBROWSER pour charger les fichiers med et obtenir les informations générales sur le contenu.
• MEDFILEBROWSER: remplace le concept de driver et fournit les fonctions précédemment fournies par la classe MED pour obtenir les informations de structure.
• Concept d’Extractor pour une lecture sélective des données de champs (suivant un critère d’extraction)
• Il n’est plus nécessaire d’appeler les méthodes read explicitement sur les objets (MESH et FIELD) pour charger les données. Par ailleurs, on peut définir deux fois le même champs (double chargement a priori) sans lever d’exception).

Analyse de conception pour le chantier 2011

Composants SALOME (interfaces IDL)

• MEDDataManager: défini une structure FIELD pour identifier un champ dans les requêtes. Il s’occupe également de la récupération physique des données, quelqu’en soit la source (fichier avec MEDLoader, autre module SALOME comme PARAVIS avec une méthode à définir)
• MEDCalculator: s’occupe des requêtes de calcul dont les arguments sont les structures FIELD du MEDDataManager. Reprendre l’interface de MEDOP.

Use case à réaliser depuis un client python:

• UC01: ajouter un fichier d’entrée et accéder aux informations concernant les champs. Ex: récupérer une structure champs par la donnée des paramètres primaires (nom identifiant, dt, it, nom du maillage).
• UC02: créer des champs et les ajouter au MEDDataManager
• UC03: mener des opérations basique sur les champs en console python

Interface Utilisateur

L’interface utilisateur est composée des parties suivantes:

• une partie GUI (appelée par la suite MEDGUI) qui s’occupe de piloter le chargement des données dans l’espace de travail, au moyen d’une interface graphique;
• une partie TUI (appelée par la suite MEDTUI) qui s’occupe de piloter la création de champs, au moyen de commandes exécutées dans la console python.

Le principe est que les champs sont préalablement chargés au niveau du composant SALOME au moyen de l’interface graphique (MEDGUI), puis manoeuvrés depuis l’application SALOME au moyen de variables proxy définies dans la console python (MEDTUI). Au chargement, les champs sont indéxés par le MEDDataManager, puis les index sont rendus accessibles au niveau du GUI au moyen d’une représentation arborescente de la structure MED. Les feuilles de l’arbre correspondent à des champs qui peuvent être sélectionnés et dont l’index peut être obtenu de la sélection.

L’espace de travail est organisé autour du concept de “workspace”. L’étude SALOME liste les datasource (les fichiers source des données med, mais peut-être aussi les référence vers des objets MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire permet de voir la structure fine d’une source de données.

Concernant MEDGUI:

• la représentation des données (les champs et les maillages associés) doit permettre de récupérer par l’interface graphique les identifiants des champs à manipuler (a priori les structures FIELD définies par le composant MEDDataManager). Cela conduit à la mise en place des composants suivants:
  • MedDataModel hérité de TreeData. Il est peuplé avec les méta-données décrivant la structure MED explorée.
  • MedGuiManager qui permet l’implantation du doc widget de présentation

TODO:

• specifier le concept de workspace (qui a une entrée dans l’étude?) en bijection avec un datamanager
• identifier des interlocuteur/utilisateur pour l’aspect ergonomie d’usage

Concernant MEDTUI:

• Il fournit les classes FieldProxy

Questions:

• Comment traiter le cas du travail sur des composantes ciblées, plus généralement, comment introduire le concept de domaine d’application?
• Prévoir des fonctions génériques (initialisation d’un champ sur un maillage avec une fonction analytique de la position, sauvegarder les champs créés dans un fichier med)

Tâches de développement

T20110622.1: Gestion des données internes

Status: terminé. Suite: fonction de sauvegarde au niveau graphique également

On vise les cas d’utiliation suivants:

• UC1: intégrer dans le datamodel du gui un champ créé dans la console python (et donc présent dans le datamanager du composant). Définir l’utilité?
• UC2: renommer un champ et plus généralement changer ses méta-données (avec assurance de synchronisation entre toutes les données).
• UC3: sauvegarder une sélection de champs. La sélection peut se faire dans l’arbre du datamodel gui.

WARN: robustesse de fieldproxy

T20110622.2: UC Initialisation/Création de champs

Status: à faire

Les cas implémentés à ce jour sont la création de champs à partir de champs existants et chargés d’un fichier med. On souhaite ici réaliser des cas ‘utilisation autour de la création de champs “from scratch”, s’appuyant tout de même sur un maillage chargé.

UC01: Sélection d’un groupe de maille dans SMESH pour initialiser un champ (par exemple les conditions limites d’un problème de calcul).

UC02: créer un champ avec des restrictions qui définissent le domaine d’application des opération de champs.

UC03: créer un champ à partir d’une image (codes rgb utilisé comme les composantes du champs vectoriel ou niveaux de gris pour un champ scalaire. Attention, pour ça, il faudra a priori fiare une projection du maillage cartesien de l’image sur le maillage (quelconque) sur lequel on souhaite définir le champ.

UC04: créer un champ à partir d’un tableau numpy

De manière générale, ce type de création sera assisté par le MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses pour l’utilisateur.

Par exemple, prévoir un menu contextuel qui propose les opérations possibles en fonction de la sélection (en plus de la fonction d’import dans la console python).

TODO:

• développer les fonctions d’initialisation, par exemple au moyen d’applyFunc et du mécanisme de callable?

T20110622.3: documentation contextuel

Status: à faire

• Remettre toutes les commandes dans le même fichier (fusionner cmdtools et fieldtools)
• Faire un modèle générique de command (classe de base
• Batir la doc des commandes sur cette base (lister toutes les instances de type Command par exemple)

T20110622.4: remontée des exception du composant MEDCalculator

Status: en cours, compléter la couverture

Pour des messages contextuel sur les erreurs de calcul (ex: division par 0)

• Poursuivre le travail fait sur getMedEventListener
• Protéger tous les appels au composants effectués depuis la console python (prendre example sur la commande save)

T20110624.1: gestion des données GUI

Status: à faire

Le workspace a une entrée dans l’obrowser. Sur cette entrée on peut:

• supprimer: supprime tout les champs associés
• sauvegarder. Dans ce cas, on rappelle l’ensemble des champs pour cocher ceux qu’on veut sauvegarder.

Le gui data model est réservé aux opérations sur les champs et à piloter leur import dans la console python.

TODO:

• Spécifier les concepts de workspace, database, et datasource, espace de gestion, ... et les associations. Simplifier avec l’appuie de use cases.
• Mécanisme de mise à jour du TreeView de XSALOME (aujourd’hui, seul l’ajout addChild est implémenté
• Clic droit sur objets de l’arbre: dans la notification TreeView -> WorkspaceController, faire remonter l’évènement clic droit ainsi que la liste des éléments sélectionné pour faire générer le menu contextuel au niveau du WorkspaceController qui peut déterminer le contexte métier (le TreeView ne le connaît pas).
• Définir des DataObject pour les maillages, les séries temporelles et les champs

Spécification des espaces de données:

• MEDDataManager dépend de l’étude (pour permettre la publication d’information dans une étude SALOME).
• créer “sourcid = MEDDataManager::addDataSource(filename)”, suivie de requetes getFields(sourceid), getMeshes(sourceid)
• les espaces de données: dataspace, workspace. Un seul workspace par étude, mais autand de datasources que l’on souhaite dans le dataspace. Les datasources sont rangés dans l’étude (le dataspace) et sont non modifiables après chargement (référence des sources de données).

T20110628.1: extention à d’autres objets SALOME

Status: suspendu

On doit reposer la question de l’existance de l’arbre indépendant (DockWidget), d’une part, et l’extention aux autres objets (GEOM et SMESH en particulier) du principe de sélection graphique pour utilisation dans la console python, d’autre part.

T20110628.2: visualisation d’un champ avec PARAVIS

Status: terminé (pour une première version) Suite: de nombreux défauts subsistent

Questions/remarques:

• Pb au démarrage du module: VisTrails fails to start
• Peux-t-on piloter la vue 3D sans charger le module? (voir myparavis.py)
• Comment donner un nom au MEDReader1 dans l’arbre Pipeline?
• Comment utiliser directement les objets MEDCouplingField?

T20110706.1: documentation du module

Status: en cours (10%)

Documenter les commandes TUI puis l’utilisation générale de l’interafce graphique. Mentionner l’existance de la commande medop.sh pour travailler exclusivement en mode texte (utile pour les tests rapides).

Documenter les modalités d’exécution des tests.

T20110708.1: helper python pour MEDCoupling

Status: en attente (pas urgent)

Faire un helper python dans le package xmed qui permet de faire du medcoupling facilement (essentiellement pour simplifier le chargement, puis la sélection des données). Cela demanderait de faire un MedDataManager comme une class C++ pure (non CORBA). Cette classe travaillerait par exemple uniquement avec des id et des liste d’id, et fournirait des fonctions d’affichage (comme le ls et le la) pour obtenir des meta-information.

Le servant MedDataManager pourrait être une surcouche de cette classe c++ pure.

T20110708.2: analyses et tests

TODO:

• créer un fichier de test avec plusieurs pas de temps
• créer un fichier de test avec des groupes de mailles

T20110728.1: refactoring MEDDataManager

Refactoring pour une meilleur association entre FieldHandler et MeshHandler:

• dans la mesure du possible utiliser les id plutôt que les handler en arguments des fonctions d’appel des objets
• A chaque champ (FieldHandler), on doit associer un meshid (et de manière optionnelle un fieldseriesId, si le champ peut être associé à une serie temporelle. A priori faisable uniquement au chargement du datasource).
• Pour cela, revoir les fonctions internes newFieldHandler et addField ou prévoir de les compléter à chaque fois qu’elles sont appelée avec les informations concernant le meshid.
• addField est utilisée par le MEDCalculator
• Attention au raffraichissement des données handler au niveau du Workspace. Peut-être le mieux est que les fieldproxy contiennent uniquement le fieldid, et qu’ils interroge le datamanager à chaque fois qu’ils ont besoin d’une donnée. Voir aussi les notifications via le MEDEventListener? Le plus simple est de faire la mise à jour lors de l’appel à la méthode __repr__ du fieldproxy, i.e. quand on essaye d’afficher les données. Parceque sinon il n’y a pas de problème puisque que le calculateur travaille à partir des id.

Petites améliorations du DataspaceController:

• Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de l’alias python dans un attribut du sobject.
• Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer est posé dans le WS. On peut donc proposer en option de lui associer un alias pour manipulation dans la console