+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(sphinx)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(sphinx)
--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+<XMI verified="false" xmi.version="1.2" timestamp="2012-11-06T17:59:15" xmlns:UML="http://schema.omg.org/spec/UML/1.3">
+ <XMI.header>
+ <XMI.documentation>
+ <XMI.exporter>umbrello uml modeller http://uml.sf.net</XMI.exporter>
+ <XMI.exporterVersion>1.5.8</XMI.exporterVersion>
+ <XMI.exporterEncoding>UnicodeUTF8</XMI.exporterEncoding>
+ </XMI.documentation>
+ <XMI.metamodel xmi.version="1.3" href="UML.xml" xmi.name="UML"/>
+ </XMI.header>
+ <XMI.content>
+ <UML:Model isSpecification="false" isAbstract="false" isLeaf="false" xmi.id="m1" isRoot="false" name="Modèle UML">
+ <UML:Namespace.ownedElement>
+ <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="folder" name="folder"/>
+ <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="datatype" name="datatype"/>
+ <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="interface" name="interface"/>
+ <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Logical View" name="Logical View">
+ <UML:Namespace.ownedElement>
+ <UML:Package stereotype="folder" visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Datatypes" name="Datatypes">
+ <UML:Namespace.ownedElement>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ZPqOwG3ZaJgC" name="int"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="WVv63G5f9uiL" name="char"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="dHU5JP7qmxEj" name="bool"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CIGkZvv5QqCT" name="float"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="7F8E7oZk44nN" name="double"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="RuDDqPu2fBmF" name="short"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="6hIUWSwdh4po" name="long"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rMXvQKIpDT33" name="unsigned int"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="qx3W6plAV1f1" name="unsigned short"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Ubc9dPySlTNA" name="unsigned long"/>
+ <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ndz0601vw4R2" name="string"/>
+ </UML:Namespace.ownedElement>
+ </UML:Package>
+ <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="NBqMfPwp0LlT" name="MEDCalc">
+ <UML:Namespace.ownedElement>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="KO9M6BTsmDX3" name="DatasourceHandler">
+ <UML:Classifier.feature>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="IDqrnmQNZzdi" type="ZPqOwG3ZaJgC" name="sourceid"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="eazbSktruFv5" type="ndz0601vw4R2" name="name"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="Js2a6sRrdpCC" type="ndz0601vw4R2" name="uri"/>
+ </UML:Classifier.feature>
+ </UML:Class>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="mpuQQtzqbsfV" name="MeshHandler">
+ <UML:Classifier.feature>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="6bYmLOgeEiEK" type="ZPqOwG3ZaJgC" name="meshid"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="MMCAGaa7ZOiQ" type="ndz0601vw4R2" name="name"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="4CWdiGy6waJd" type="ZPqOwG3ZaJgC" name="sourceid"/>
+ </UML:Classifier.feature>
+ </UML:Class>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Z3sQfH0YJ5g6" name="FieldHandler">
+ <UML:Classifier.feature>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="o3IdSrqOde12" type="ZPqOwG3ZaJgC" name="fieldid"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="HICpfJOiAmOR" type="ZPqOwG3ZaJgC" name="type"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="kwipcobg6E6w" type="ZPqOwG3ZaJgC" name="iteration"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="5UZhTZzlr9YW" type="ZPqOwG3ZaJgC" name="order"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="RuFbeb0OViC7" type="ZPqOwG3ZaJgC" name="meshid"/>
+ </UML:Classifier.feature>
+ </UML:Class>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="tFFeytJRMARL" name="FieldseriesHandler">
+ <UML:Classifier.feature>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="OKYFoL4febk2" type="ZPqOwG3ZaJgC" name="fieldseriesId"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="dZ9FP4RHHevG" type="ZPqOwG3ZaJgC" name="type"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="VEhrN6DlOlzB" type="ZPqOwG3ZaJgC" name="nbIterations"/>
+ <UML:Attribute visibility="public" isSpecification="false" xmi.id="41qibbiE8sRX" type="ZPqOwG3ZaJgC" name="meshId"/>
+ </UML:Classifier.feature>
+ </UML:Class>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="kG3S8XATRqib" name="Factory">
+ <UML:Classifier.feature>
+ <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CS8eIf5ejE39" name="getDataManager">
+ <UML:BehavioralFeature.parameter>
+ <UML:Parameter kind="return" xmi.id="HO3Z38DlLEsc" type="nSHVdoPkDYFK"/>
+ </UML:BehavioralFeature.parameter>
+ </UML:Operation>
+ <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="52BLkz1CzFrG" name="getCalculator">
+ <UML:BehavioralFeature.parameter>
+ <UML:Parameter kind="return" xmi.id="UD4jBGoER8yQ" type="UsXTM49RP2EE"/>
+ </UML:BehavioralFeature.parameter>
+ </UML:Operation>
+ </UML:Classifier.feature>
+ </UML:Class>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="nSHVdoPkDYFK" name="DataManager"/>
+ <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="UsXTM49RP2EE" name="Calculator"/>
+ </UML:Namespace.ownedElement>
+ </UML:Package>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="waq19EhXGt1t" name="">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="aIpeEQxrDZ1d" type="KO9M6BTsmDX3" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="n" xmi.id="KLQQ3Six0Wy7" type="mpuQQtzqbsfV" name="" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="SJsPpluxXW2y" name="">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="uGVzTJNdzM70" type="mpuQQtzqbsfV" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="L0i3AAwcTp0I" type="KO9M6BTsmDX3" name="sourceid" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ld0pX3I6kldh" name="">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="UVr0zGsErWnr" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="tIX5O3q7eqxB" type="mpuQQtzqbsfV" name="meshId" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="oCVhQ0u5qFB3" name="">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="yYmvjqxZZY8F" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="0" xmi.id="kG5Bo02aCVGa" type="tFFeytJRMARL" name="fieldseriesId" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ONJtNJsd01tV" name="">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="5vXlBV761AlS" type="tFFeytJRMARL" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="uYDM7AmTV5Lr" type="mpuQQtzqbsfV" name="" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rEjTH3dMz3kh" name="SALOME">
+ <UML:Namespace.ownedElement>
+ <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="BYw7PBW7PaZW" comment="SALOME CORBA Object that can be requested using the lyfe cycle corba registry" name="EngineComponent"/>
+ <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="tDJT9A2gh9I3" comment="Standard SALOME CORBA Object" name="GenericObject"/>
+ </UML:Namespace.ownedElement>
+ </UML:Package>
+ <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="BYw7PBW7PaZW" xmi.id="OOxclE0ol1ww" client="kG3S8XATRqib" name=""/>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="fUBIKo7DA4LI" name="instancie">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="FsZMpwZ9gj4C" type="kG3S8XATRqib" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="50TAtgDYAPqS" type="nSHVdoPkDYFK" name="" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="DweL0xdEpAae" name="instancie">
+ <UML:Association.connection>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="5AnlrsvxqO7j" type="kG3S8XATRqib" name="" aggregation="none"/>
+ <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="4JHDg6ft0HE0" type="UsXTM49RP2EE" name="" aggregation="none"/>
+ </UML:Association.connection>
+ </UML:Association>
+ <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="WqUPF7X6LpZS" client="nSHVdoPkDYFK" name=""/>
+ <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="AwSTl1vib2NJ" client="UsXTM49RP2EE" name=""/>
+ </UML:Namespace.ownedElement>
+ <XMI.extension xmi.extender="umbrello">
+ <diagrams>
+ <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDCALC_datamodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="644" canvaswidth="1201" localid="" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#000000" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffff00" zoom="100" xmi.id="yesp3EjZ9T3u" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
+ <widgets>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="261" showattsigs="601" showstereotype="1" y="101" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="193" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="KO9M6BTsmDX3" showscope="1" height="67" showopsigs="601"/>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="273" showattsigs="601" showstereotype="1" y="220" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="155" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="mpuQQtzqbsfV" showscope="1" height="67" showopsigs="601"/>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="268" showattsigs="601" showstereotype="1" y="371" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="150" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="Z3sQfH0YJ5g6" showscope="1" height="97" showopsigs="601"/>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="574" showattsigs="601" showstereotype="1" y="218" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="190" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tFFeytJRMARL" showscope="1" height="82" showopsigs="601"/>
+ <notewidget width="170" showstereotype="1" x="703" noteType="0" usesdiagramusefillcolor="1" y="278" usesdiagramfillcolor="1" isinstance="0" fillcolor="none" height="79" linecolor="none" xmi.id="IxOvY2fRkpkU" usefillcolor="1" linewidth="none" font="Ubuntu,10,-1,5,50,0,0,0,0,0" text="A Fieldseries is a data structure gathering a sequence of fields of same type."/>
+ </widgets>
+ <messages/>
+ <associations>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="mpuQQtzqbsfV" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="SJsPpluxXW2y" widgetbid="KO9M6BTsmDX3" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="323" starty="220"/>
+ <endpoint endx="323" endy="168"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="199" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="PUeF5c2aIZmS" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="170" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="UmnXhmcg0z5Y" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="260" showstereotype="1" y="170" text="sourceid" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="67" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zENRazZ7qpS9" height="19"/>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ld0pX3I6kldh" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="318" starty="371"/>
+ <endpoint endx="318" endy="287"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="350" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="84EPeyr6icdP" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="289" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="OF6MD9u7mXqC" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="264" showstereotype="1" y="289" text="meshId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="59" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdfkS5upaY4d" height="19"/>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="oCVhQ0u5qFB3" widgetbid="tFFeytJRMARL" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="418" starty="371"/>
+ <endpoint endx="574" endy="300"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="408" showstereotype="1" y="349" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdocFP2bd6xq" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="570" showstereotype="1" y="303" text="0" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Fpv0KlCvTC4k" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="487" showstereotype="1" y="282" text="fieldseriesId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="90" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="bkz9G4mP6yoi" height="19"/>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="tFFeytJRMARL" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ONJtNJsd01tV" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="574" starty="246"/>
+ <endpoint endx="428" endy="246"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="556" showstereotype="1" y="225" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Ep7Inv1iWpKl" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="430" showstereotype="1" y="225" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="FKMsQHge4ZeM" height="19"/>
+ </assocwidget>
+ </associations>
+ </diagram>
+ <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDCALC_componentmodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="436" canvaswidth="596" localid="-1" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#808080" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffffc0" zoom="100" xmi.id="e3MA5ySQiAqG" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
+ <widgets>
+ <classwidget linecolor="#ff0000" usesdiagramfillcolor="0" linewidth="none" showoperations="1" usesdiagramusefillcolor="0" showpubliconly="1" showpackage="1" x="330" showattsigs="601" showstereotype="1" y="184" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="227" isinstance="0" usefillcolor="1" fillcolor="#ffffc0" xmi.id="kG3S8XATRqib" showscope="1" height="52" showopsigs="601"/>
+ <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="342" showstereotype="1" y="87" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="184" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="BYw7PBW7PaZW" showscope="1" height="44" showopsigs="601"/>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="459" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="133" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="UsXTM49RP2EE" showscope="1" height="29" showopsigs="601"/>
+ <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="254" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="153" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="nSHVdoPkDYFK" showscope="1" height="29" showopsigs="601"/>
+ <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="367" showstereotype="1" y="388" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="160" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tDJT9A2gh9I3" showscope="1" height="44" showopsigs="601"/>
+ </widgets>
+ <messages/>
+ <associations>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="OOxclE0ol1ww" widgetbid="BYw7PBW7PaZW" totalcountb="2" type="511" usefillcolor="0" linewidth="none">
+ <linepath>
+ <startpoint startx="432" starty="184"/>
+ <endpoint endx="432" endy="131"/>
+ </linepath>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="3" xmi.id="fUBIKo7DA4LI" widgetbid="nSHVdoPkDYFK" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="362" starty="236"/>
+ <endpoint endx="362" endy="300"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="362" showstereotype="1" y="268" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="yMxCnWyqPM7m" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zDAFam9Z1k5N" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="HoH1ErvACtMz" height="19"/>
+ </assocwidget>
+ <assocwidget indexa="2" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="3" xmi.id="DweL0xdEpAae" widgetbid="UsXTM49RP2EE" totalcountb="2" type="512" usefillcolor="0" linewidth="none">
+ <linepath>
+ <startpoint startx="508" starty="236"/>
+ <endpoint endx="508" endy="300"/>
+ </linepath>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="508" showstereotype="1" y="269" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="NJokfvWe6hrg" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="RyGQiJny75zJ" height="19"/>
+ <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="usT4lq477qrk" height="19"/>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="nSHVdoPkDYFK" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="WqUPF7X6LpZS" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="0" linewidth="none">
+ <linepath>
+ <startpoint startx="398" starty="329"/>
+ <endpoint endx="398" endy="388"/>
+ </linepath>
+ </assocwidget>
+ <assocwidget indexa="1" indexb="2" usesdiagramusefillcolor="0" widgetaid="UsXTM49RP2EE" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="AwSTl1vib2NJ" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="1" linewidth="none">
+ <linepath>
+ <startpoint startx="510" starty="329"/>
+ <endpoint endx="510" endy="388"/>
+ </linepath>
+ </assocwidget>
+ </associations>
+ </diagram>
+ </diagrams>
+ </XMI.extension>
+ </UML:Model>
+ <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Use Case View" name="Use Case View">
+ <UML:Namespace.ownedElement/>
+ </UML:Model>
+ <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Component View" name="Component View">
+ <UML:Namespace.ownedElement/>
+ </UML:Model>
+ <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Deployment View" name="Deployment View">
+ <UML:Namespace.ownedElement/>
+ </UML:Model>
+ <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Entity Relationship Model" name="Entity Relationship Model">
+ <UML:Namespace.ownedElement/>
+ </UML:Model>
+ </UML:Namespace.ownedElement>
+ </UML:Model>
+ </XMI.content>
+ <XMI.extensions xmi.extender="umbrello">
+ <docsettings viewid="e3MA5ySQiAqG" uniqueid="1YG8dfUmZuFJ" documentation=""/>
+ <listview>
+ <listitem open="1" type="800" id="Views">
+ <listitem open="1" type="836" id="Entity Relationship Model"/>
+ <listitem open="1" type="802" id="Use Case View"/>
+ <listitem open="1" type="821" id="Component View"/>
+ <listitem open="1" type="827" id="Deployment View"/>
+ <listitem open="1" type="801" id="Logical View">
+ <listitem open="0" type="818" id="NBqMfPwp0LlT">
+ <listitem open="1" type="813" id="UsXTM49RP2EE"/>
+ <listitem open="1" type="813" id="nSHVdoPkDYFK"/>
+ <listitem open="0" type="813" id="KO9M6BTsmDX3">
+ <listitem open="0" type="814" id="eazbSktruFv5"/>
+ <listitem open="1" type="814" id="IDqrnmQNZzdi"/>
+ <listitem open="0" type="814" id="Js2a6sRrdpCC"/>
+ </listitem>
+ <listitem open="1" type="813" id="kG3S8XATRqib">
+ <listitem open="0" type="815" id="52BLkz1CzFrG"/>
+ <listitem open="0" type="815" id="CS8eIf5ejE39"/>
+ </listitem>
+ <listitem open="0" type="813" id="Z3sQfH0YJ5g6">
+ <listitem open="0" type="814" id="o3IdSrqOde12"/>
+ <listitem open="0" type="814" id="kwipcobg6E6w"/>
+ <listitem open="0" type="814" id="RuFbeb0OViC7"/>
+ <listitem open="0" type="814" id="5UZhTZzlr9YW"/>
+ <listitem open="0" type="814" id="HICpfJOiAmOR"/>
+ </listitem>
+ <listitem open="0" type="813" id="tFFeytJRMARL">
+ <listitem open="0" type="814" id="OKYFoL4febk2"/>
+ <listitem open="0" type="814" id="41qibbiE8sRX"/>
+ <listitem open="0" type="814" id="VEhrN6DlOlzB"/>
+ <listitem open="0" type="814" id="dZ9FP4RHHevG"/>
+ </listitem>
+ <listitem open="0" type="813" id="mpuQQtzqbsfV">
+ <listitem open="0" type="814" id="6bYmLOgeEiEK"/>
+ <listitem open="0" type="814" id="MMCAGaa7ZOiQ"/>
+ <listitem open="0" type="814" id="4CWdiGy6waJd"/>
+ </listitem>
+ </listitem>
+ <listitem open="0" type="807" id="e3MA5ySQiAqG" label="MEDCALC_componentmodel"/>
+ <listitem open="0" type="807" id="yesp3EjZ9T3u" label="MEDCALC_datamodel"/>
+ <listitem open="0" type="818" id="rEjTH3dMz3kh">
+ <listitem open="1" type="817" id="BYw7PBW7PaZW"/>
+ <listitem open="1" type="817" id="tDJT9A2gh9I3"/>
+ </listitem>
+ <listitem open="0" type="830" id="Datatypes">
+ <listitem open="1" type="829" id="dHU5JP7qmxEj"/>
+ <listitem open="1" type="829" id="WVv63G5f9uiL"/>
+ <listitem open="1" type="829" id="7F8E7oZk44nN"/>
+ <listitem open="1" type="829" id="CIGkZvv5QqCT"/>
+ <listitem open="1" type="829" id="ZPqOwG3ZaJgC"/>
+ <listitem open="1" type="829" id="6hIUWSwdh4po"/>
+ <listitem open="1" type="829" id="RuDDqPu2fBmF"/>
+ <listitem open="1" type="829" id="ndz0601vw4R2"/>
+ <listitem open="1" type="829" id="rMXvQKIpDT33"/>
+ <listitem open="1" type="829" id="Ubc9dPySlTNA"/>
+ <listitem open="1" type="829" id="qx3W6plAV1f1"/>
+ </listitem>
+ </listitem>
+ </listitem>
+ </listview>
+ <codegeneration>
+ <codegenerator language="C++"/>
+ </codegeneration>
+ </XMI.extensions>
+</XMI>
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-<XMI verified="false" xmi.version="1.2" timestamp="2012-11-06T17:59:15" xmlns:UML="http://schema.omg.org/spec/UML/1.3">
- <XMI.header>
- <XMI.documentation>
- <XMI.exporter>umbrello uml modeller http://uml.sf.net</XMI.exporter>
- <XMI.exporterVersion>1.5.8</XMI.exporterVersion>
- <XMI.exporterEncoding>UnicodeUTF8</XMI.exporterEncoding>
- </XMI.documentation>
- <XMI.metamodel xmi.version="1.3" href="UML.xml" xmi.name="UML"/>
- </XMI.header>
- <XMI.content>
- <UML:Model isSpecification="false" isAbstract="false" isLeaf="false" xmi.id="m1" isRoot="false" name="Modèle UML">
- <UML:Namespace.ownedElement>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="folder" name="folder"/>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="datatype" name="datatype"/>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="interface" name="interface"/>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Logical View" name="Logical View">
- <UML:Namespace.ownedElement>
- <UML:Package stereotype="folder" visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Datatypes" name="Datatypes">
- <UML:Namespace.ownedElement>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ZPqOwG3ZaJgC" name="int"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="WVv63G5f9uiL" name="char"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="dHU5JP7qmxEj" name="bool"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CIGkZvv5QqCT" name="float"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="7F8E7oZk44nN" name="double"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="RuDDqPu2fBmF" name="short"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="6hIUWSwdh4po" name="long"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rMXvQKIpDT33" name="unsigned int"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="qx3W6plAV1f1" name="unsigned short"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Ubc9dPySlTNA" name="unsigned long"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ndz0601vw4R2" name="string"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="NBqMfPwp0LlT" name="MEDOP">
- <UML:Namespace.ownedElement>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="KO9M6BTsmDX3" name="DatasourceHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="IDqrnmQNZzdi" type="ZPqOwG3ZaJgC" name="sourceid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="eazbSktruFv5" type="ndz0601vw4R2" name="name"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="Js2a6sRrdpCC" type="ndz0601vw4R2" name="uri"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="mpuQQtzqbsfV" name="MeshHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="6bYmLOgeEiEK" type="ZPqOwG3ZaJgC" name="meshid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="MMCAGaa7ZOiQ" type="ndz0601vw4R2" name="name"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="4CWdiGy6waJd" type="ZPqOwG3ZaJgC" name="sourceid"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Z3sQfH0YJ5g6" name="FieldHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="o3IdSrqOde12" type="ZPqOwG3ZaJgC" name="fieldid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="HICpfJOiAmOR" type="ZPqOwG3ZaJgC" name="type"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="kwipcobg6E6w" type="ZPqOwG3ZaJgC" name="iteration"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="5UZhTZzlr9YW" type="ZPqOwG3ZaJgC" name="order"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="RuFbeb0OViC7" type="ZPqOwG3ZaJgC" name="meshid"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="tFFeytJRMARL" name="FieldseriesHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="OKYFoL4febk2" type="ZPqOwG3ZaJgC" name="fieldseriesId"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="dZ9FP4RHHevG" type="ZPqOwG3ZaJgC" name="type"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="VEhrN6DlOlzB" type="ZPqOwG3ZaJgC" name="nbIterations"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="41qibbiE8sRX" type="ZPqOwG3ZaJgC" name="meshId"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="kG3S8XATRqib" name="Factory">
- <UML:Classifier.feature>
- <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CS8eIf5ejE39" name="getDataManager">
- <UML:BehavioralFeature.parameter>
- <UML:Parameter kind="return" xmi.id="HO3Z38DlLEsc" type="nSHVdoPkDYFK"/>
- </UML:BehavioralFeature.parameter>
- </UML:Operation>
- <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="52BLkz1CzFrG" name="getCalculator">
- <UML:BehavioralFeature.parameter>
- <UML:Parameter kind="return" xmi.id="UD4jBGoER8yQ" type="UsXTM49RP2EE"/>
- </UML:BehavioralFeature.parameter>
- </UML:Operation>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="nSHVdoPkDYFK" name="DataManager"/>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="UsXTM49RP2EE" name="Calculator"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="waq19EhXGt1t" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="aIpeEQxrDZ1d" type="KO9M6BTsmDX3" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="n" xmi.id="KLQQ3Six0Wy7" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="SJsPpluxXW2y" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="uGVzTJNdzM70" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="L0i3AAwcTp0I" type="KO9M6BTsmDX3" name="sourceid" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ld0pX3I6kldh" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="UVr0zGsErWnr" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="tIX5O3q7eqxB" type="mpuQQtzqbsfV" name="meshId" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="oCVhQ0u5qFB3" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="yYmvjqxZZY8F" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="0" xmi.id="kG5Bo02aCVGa" type="tFFeytJRMARL" name="fieldseriesId" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ONJtNJsd01tV" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="5vXlBV761AlS" type="tFFeytJRMARL" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="uYDM7AmTV5Lr" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rEjTH3dMz3kh" name="SALOME">
- <UML:Namespace.ownedElement>
- <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="BYw7PBW7PaZW" comment="SALOME CORBA Object that can be requested using the lyfe cycle corba registry" name="EngineComponent"/>
- <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="tDJT9A2gh9I3" comment="Standard SALOME CORBA Object" name="GenericObject"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="BYw7PBW7PaZW" xmi.id="OOxclE0ol1ww" client="kG3S8XATRqib" name=""/>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="fUBIKo7DA4LI" name="instancie">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="FsZMpwZ9gj4C" type="kG3S8XATRqib" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="50TAtgDYAPqS" type="nSHVdoPkDYFK" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="DweL0xdEpAae" name="instancie">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="5AnlrsvxqO7j" type="kG3S8XATRqib" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="4JHDg6ft0HE0" type="UsXTM49RP2EE" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="WqUPF7X6LpZS" client="nSHVdoPkDYFK" name=""/>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="AwSTl1vib2NJ" client="UsXTM49RP2EE" name=""/>
- </UML:Namespace.ownedElement>
- <XMI.extension xmi.extender="umbrello">
- <diagrams>
- <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDOP_datamodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="644" canvaswidth="1201" localid="" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#000000" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffff00" zoom="100" xmi.id="yesp3EjZ9T3u" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
- <widgets>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="261" showattsigs="601" showstereotype="1" y="101" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="193" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="KO9M6BTsmDX3" showscope="1" height="67" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="273" showattsigs="601" showstereotype="1" y="220" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="155" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="mpuQQtzqbsfV" showscope="1" height="67" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="268" showattsigs="601" showstereotype="1" y="371" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="150" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="Z3sQfH0YJ5g6" showscope="1" height="97" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="574" showattsigs="601" showstereotype="1" y="218" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="190" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tFFeytJRMARL" showscope="1" height="82" showopsigs="601"/>
- <notewidget width="170" showstereotype="1" x="703" noteType="0" usesdiagramusefillcolor="1" y="278" usesdiagramfillcolor="1" isinstance="0" fillcolor="none" height="79" linecolor="none" xmi.id="IxOvY2fRkpkU" usefillcolor="1" linewidth="none" font="Ubuntu,10,-1,5,50,0,0,0,0,0" text="A Fieldseries is a data structure gathering a sequence of fields of same type."/>
- </widgets>
- <messages/>
- <associations>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="mpuQQtzqbsfV" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="SJsPpluxXW2y" widgetbid="KO9M6BTsmDX3" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="323" starty="220"/>
- <endpoint endx="323" endy="168"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="199" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="PUeF5c2aIZmS" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="170" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="UmnXhmcg0z5Y" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="260" showstereotype="1" y="170" text="sourceid" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="67" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zENRazZ7qpS9" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ld0pX3I6kldh" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="318" starty="371"/>
- <endpoint endx="318" endy="287"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="350" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="84EPeyr6icdP" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="289" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="OF6MD9u7mXqC" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="264" showstereotype="1" y="289" text="meshId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="59" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdfkS5upaY4d" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="oCVhQ0u5qFB3" widgetbid="tFFeytJRMARL" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="418" starty="371"/>
- <endpoint endx="574" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="408" showstereotype="1" y="349" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdocFP2bd6xq" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="570" showstereotype="1" y="303" text="0" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Fpv0KlCvTC4k" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="487" showstereotype="1" y="282" text="fieldseriesId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="90" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="bkz9G4mP6yoi" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="tFFeytJRMARL" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ONJtNJsd01tV" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="574" starty="246"/>
- <endpoint endx="428" endy="246"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="556" showstereotype="1" y="225" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Ep7Inv1iWpKl" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="430" showstereotype="1" y="225" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="FKMsQHge4ZeM" height="19"/>
- </assocwidget>
- </associations>
- </diagram>
- <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDOP_componentmodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="436" canvaswidth="596" localid="-1" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#808080" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffffc0" zoom="100" xmi.id="e3MA5ySQiAqG" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
- <widgets>
- <classwidget linecolor="#ff0000" usesdiagramfillcolor="0" linewidth="none" showoperations="1" usesdiagramusefillcolor="0" showpubliconly="1" showpackage="1" x="330" showattsigs="601" showstereotype="1" y="184" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="227" isinstance="0" usefillcolor="1" fillcolor="#ffffc0" xmi.id="kG3S8XATRqib" showscope="1" height="52" showopsigs="601"/>
- <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="342" showstereotype="1" y="87" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="184" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="BYw7PBW7PaZW" showscope="1" height="44" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="459" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="133" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="UsXTM49RP2EE" showscope="1" height="29" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="254" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="153" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="nSHVdoPkDYFK" showscope="1" height="29" showopsigs="601"/>
- <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="367" showstereotype="1" y="388" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="160" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tDJT9A2gh9I3" showscope="1" height="44" showopsigs="601"/>
- </widgets>
- <messages/>
- <associations>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="OOxclE0ol1ww" widgetbid="BYw7PBW7PaZW" totalcountb="2" type="511" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="432" starty="184"/>
- <endpoint endx="432" endy="131"/>
- </linepath>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="3" xmi.id="fUBIKo7DA4LI" widgetbid="nSHVdoPkDYFK" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="362" starty="236"/>
- <endpoint endx="362" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="362" showstereotype="1" y="268" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="yMxCnWyqPM7m" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zDAFam9Z1k5N" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="HoH1ErvACtMz" height="19"/>
- </assocwidget>
- <assocwidget indexa="2" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="3" xmi.id="DweL0xdEpAae" widgetbid="UsXTM49RP2EE" totalcountb="2" type="512" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="508" starty="236"/>
- <endpoint endx="508" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="508" showstereotype="1" y="269" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="NJokfvWe6hrg" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="RyGQiJny75zJ" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="usT4lq477qrk" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="nSHVdoPkDYFK" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="WqUPF7X6LpZS" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="398" starty="329"/>
- <endpoint endx="398" endy="388"/>
- </linepath>
- </assocwidget>
- <assocwidget indexa="1" indexb="2" usesdiagramusefillcolor="0" widgetaid="UsXTM49RP2EE" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="AwSTl1vib2NJ" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="510" starty="329"/>
- <endpoint endx="510" endy="388"/>
- </linepath>
- </assocwidget>
- </associations>
- </diagram>
- </diagrams>
- </XMI.extension>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Use Case View" name="Use Case View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Component View" name="Component View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Deployment View" name="Deployment View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Entity Relationship Model" name="Entity Relationship Model">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- </UML:Namespace.ownedElement>
- </UML:Model>
- </XMI.content>
- <XMI.extensions xmi.extender="umbrello">
- <docsettings viewid="e3MA5ySQiAqG" uniqueid="1YG8dfUmZuFJ" documentation=""/>
- <listview>
- <listitem open="1" type="800" id="Views">
- <listitem open="1" type="836" id="Entity Relationship Model"/>
- <listitem open="1" type="802" id="Use Case View"/>
- <listitem open="1" type="821" id="Component View"/>
- <listitem open="1" type="827" id="Deployment View"/>
- <listitem open="1" type="801" id="Logical View">
- <listitem open="0" type="818" id="NBqMfPwp0LlT">
- <listitem open="1" type="813" id="UsXTM49RP2EE"/>
- <listitem open="1" type="813" id="nSHVdoPkDYFK"/>
- <listitem open="0" type="813" id="KO9M6BTsmDX3">
- <listitem open="0" type="814" id="eazbSktruFv5"/>
- <listitem open="1" type="814" id="IDqrnmQNZzdi"/>
- <listitem open="0" type="814" id="Js2a6sRrdpCC"/>
- </listitem>
- <listitem open="1" type="813" id="kG3S8XATRqib">
- <listitem open="0" type="815" id="52BLkz1CzFrG"/>
- <listitem open="0" type="815" id="CS8eIf5ejE39"/>
- </listitem>
- <listitem open="0" type="813" id="Z3sQfH0YJ5g6">
- <listitem open="0" type="814" id="o3IdSrqOde12"/>
- <listitem open="0" type="814" id="kwipcobg6E6w"/>
- <listitem open="0" type="814" id="RuFbeb0OViC7"/>
- <listitem open="0" type="814" id="5UZhTZzlr9YW"/>
- <listitem open="0" type="814" id="HICpfJOiAmOR"/>
- </listitem>
- <listitem open="0" type="813" id="tFFeytJRMARL">
- <listitem open="0" type="814" id="OKYFoL4febk2"/>
- <listitem open="0" type="814" id="41qibbiE8sRX"/>
- <listitem open="0" type="814" id="VEhrN6DlOlzB"/>
- <listitem open="0" type="814" id="dZ9FP4RHHevG"/>
- </listitem>
- <listitem open="0" type="813" id="mpuQQtzqbsfV">
- <listitem open="0" type="814" id="6bYmLOgeEiEK"/>
- <listitem open="0" type="814" id="MMCAGaa7ZOiQ"/>
- <listitem open="0" type="814" id="4CWdiGy6waJd"/>
- </listitem>
- </listitem>
- <listitem open="0" type="807" id="e3MA5ySQiAqG" label="MEDOP_componentmodel"/>
- <listitem open="0" type="807" id="yesp3EjZ9T3u" label="MEDOP_datamodel"/>
- <listitem open="0" type="818" id="rEjTH3dMz3kh">
- <listitem open="1" type="817" id="BYw7PBW7PaZW"/>
- <listitem open="1" type="817" id="tDJT9A2gh9I3"/>
- </listitem>
- <listitem open="0" type="830" id="Datatypes">
- <listitem open="1" type="829" id="dHU5JP7qmxEj"/>
- <listitem open="1" type="829" id="WVv63G5f9uiL"/>
- <listitem open="1" type="829" id="7F8E7oZk44nN"/>
- <listitem open="1" type="829" id="CIGkZvv5QqCT"/>
- <listitem open="1" type="829" id="ZPqOwG3ZaJgC"/>
- <listitem open="1" type="829" id="6hIUWSwdh4po"/>
- <listitem open="1" type="829" id="RuDDqPu2fBmF"/>
- <listitem open="1" type="829" id="ndz0601vw4R2"/>
- <listitem open="1" type="829" id="rMXvQKIpDT33"/>
- <listitem open="1" type="829" id="Ubc9dPySlTNA"/>
- <listitem open="1" type="829" id="qx3W6plAV1f1"/>
- </listitem>
- </listitem>
- </listitem>
- </listview>
- <codegeneration>
- <codegenerator language="C++"/>
- </codegeneration>
- </XMI.extensions>
-</XMI>
SALOME_CONFIGURE_FILE(conf.py.in conf.py)
SET(_cmd_options -c ${CMAKE_CURRENT_BINARY_DIR} -b html -d doctrees -D latex_paper_size=a4 ${CMAKE_CURRENT_SOURCE_DIR} html)
-SALOME_GENERATE_ENVIRONMENT_SCRIPT(_cmd env_script "${SPHINX_EXECUTABLE}" "${_cmd_options}")
+SALOME_GENERATE_ENVIRONMENT_SCRIPT(_cmd env_script "${SPHINX_EXECUTABLE}" "${_cmd_options}")
ADD_CUSTOM_TARGET(dev_docs ALL COMMAND ${_cmd})
--- /dev/null
+@import url("classic.css");
+
+body {
+ font-family: {{ 'Liberation', sans-serif }};
+ font-size: 82%;
+ color: #000;
+ background-color: #fff;
+ margin-left: 28px;
+}
+
+ul {
+ margin: 0 0 0 0;
+}
+
+div.related {
+ background-color: #444;
+}
+
+a,
+div.sphinxsidebar h3 a,
+div.sphinxsidebar a,
+div.footer a {
+ color: #444;
+}
+
+div.sphinxsidebar h3,
+div.sphinxsidebar h4 {
+ color: #000;
+}
+
+div.sphinxsidebar ul {
+ font-size: 94%;
+ color: #000;
+}
+
+div.sphinxsidebar input {
+ border-color: #444;
+}
+
+div.document {
+ background-color: #f5f8e4;
+}
+
+div.body h1,
+div.body h2,
+div.body h3,
+div.body h4,
+div.body h5,
+div.body h6 {
+ color: #000;
+ background-color: transparent;
+ border-bottom: 1px solid #444;
+}
+
+div.footer {
+ color: #000;
+}
+
+li.toctree-l2 {
+ font-size: 100%;
+}
+
+li.toctree-l3 {
+ font-size: 100%;
+}
+
+div.sphinxsidebarwrapper ul {
+ list-style-type: disc;
+ margin-top: 1px;
+ padding-left: 6px;
+}
+
+div.sphinxsidebarwrapper h3 {
+ font-size: 100%;
+ font-weight: bold;
+}
+
+div.body h1 {
+ font-size: 200%;
+}
+div.body h2 {
+ font-size: 160%;
+}
+div.body h3, div.body h4 {
+ font-size: 125%;
+}
+
+div.body p.topic-title {
+ margin-bottom: 2px;
+ font-size: 100%;
+}
+
+div.sphinxsidebar p {
+ color: #444;
+}
+
+#introduction p > em {
+ text-align: right;
+ float: right;
+}
+
+#introduction p {
+ font-size: 90%;
+ margin-bottom: 3px;
+}
+
+#introduction #id2.docutils.footnote {
+ font-size: 70%;
+ margin-top: 25px;
+}
+
+#introduction table.docutils.footnote {
+ font-size: 70%;
+ margin-top: 5px;
+}
+
+
+.tt {
+ font-family:"Courier New",Courier,monospace;
+}
+.strike {
+ text-decoration: line-through;
+}
+
+.bolditalic {
+ font-style:italic;
+ font-weight:bold
+}
+
+.underline {
+ text-decoration:underline;
+}
+
+.tag {
+ font-family:"Courier New",Courier,monospace;
+}
+
+.tagb {
+ font-family:"Courier New",Courier,monospace;
+ font-weight:bold
+}
+
+.todo {
+ background-color:yellow;
+}
+
+.warn {
+ background-color:#FFE4E4;
+}
+
+.info {
+ background-color:#EEEEEE;
+}
+
+.date {
+ font-family:"Courier New",Courier,monospace;
+ font-style:italic;
+}
+
+++ /dev/null
-@import url("classic.css");
-
-body {
- font-family: {{ 'Liberation', sans-serif }};
- font-size: 82%;
- color: #000;
- background-color: #fff;
- margin-left: 28px;
-}
-
-ul {
- margin: 0 0 0 0;
-}
-
-div.related {
- background-color: #444;
-}
-
-a,
-div.sphinxsidebar h3 a,
-div.sphinxsidebar a,
-div.footer a {
- color: #444;
-}
-
-div.sphinxsidebar h3,
-div.sphinxsidebar h4 {
- color: #000;
-}
-
-div.sphinxsidebar ul {
- font-size: 94%;
- color: #000;
-}
-
-div.sphinxsidebar input {
- border-color: #444;
-}
-
-div.document {
- background-color: #f5f8e4;
-}
-
-div.body h1,
-div.body h2,
-div.body h3,
-div.body h4,
-div.body h5,
-div.body h6 {
- color: #000;
- background-color: transparent;
- border-bottom: 1px solid #444;
-}
-
-div.footer {
- color: #000;
-}
-
-li.toctree-l2 {
- font-size: 100%;
-}
-
-li.toctree-l3 {
- font-size: 100%;
-}
-
-div.sphinxsidebarwrapper ul {
- list-style-type: disc;
- margin-top: 1px;
- padding-left: 6px;
-}
-
-div.sphinxsidebarwrapper h3 {
- font-size: 100%;
- font-weight: bold;
-}
-
-div.body h1 {
- font-size: 200%;
-}
-div.body h2 {
- font-size: 160%;
-}
-div.body h3, div.body h4 {
- font-size: 125%;
-}
-
-div.body p.topic-title {
- margin-bottom: 2px;
- font-size: 100%;
-}
-
-div.sphinxsidebar p {
- color: #444;
-}
-
-#introduction p > em {
- text-align: right;
- float: right;
-}
-
-#introduction p {
- font-size: 90%;
- margin-bottom: 3px;
-}
-
-#introduction #id2.docutils.footnote {
- font-size: 70%;
- margin-top: 25px;
-}
-
-#introduction table.docutils.footnote {
- font-size: 70%;
- margin-top: 5px;
-}
-
-
-.tt {
- font-family:"Courier New",Courier,monospace;
-}
-.strike {
- text-decoration: line-through;
-}
-
-.bolditalic {
- font-style:italic;
- font-weight:bold
-}
-
-.underline {
- text-decoration:underline;
-}
-
-.tag {
- font-family:"Courier New",Courier,monospace;
-}
-
-.tagb {
- font-family:"Courier New",Courier,monospace;
- font-weight:bold
-}
-
-.todo {
- background-color:yellow;
-}
-
-.warn {
- background-color:#FFE4E4;
-}
-
-.info {
- background-color:#EEEEEE;
-}
-
-.date {
- font-family:"Courier New",Courier,monospace;
- font-style:italic;
-}
-
# The stylecheet file will be searched within the static path, while
# the layout.html file will be searched within the template path
# (Note that this parameter can't be used together with html_theme. Exclusive)
-html_style = 'medop.css'
+html_style = 'medcalc.css'
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
#html_file_suffix = ''
# Output file base name for HTML help builder.
-htmlhelp_basename = 'medopdoc'
+htmlhelp_basename = 'medcalcdoc'
# Options for LaTeX output
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, document class [howto/manual]).
latex_documents = [
- ('index', 'medop-alldoc.tex', 'Documentation du module MED', 'G. Boulant', 'manual'),
- ('medop-specifications', 'medop-specifications.tex', 'Module MED - Specifications', 'G. Boulant', 'manual'),
- ('medop-develguide', 'medop-develguide.tex', 'Module MED - Guide de developpement', 'G. Boulant', 'manual'),
- ('medop-userguide-gui', 'medop-userguide-gui.tex', 'Module MED - Guide d\'utilisation de l\'interface graphique', 'G. Boulant', 'howto'),
- ('medop-userguide-api', 'medop-userguide-api.tex', 'MEDMEM library - Starter guide for users', 'G. Boulant', 'howto')
+ ('index', 'medcalc-alldoc.tex', 'Documentation du module MED', 'G. Boulant', 'manual'),
+ ('medcalc-specifications', 'medcalc-specifications.tex', 'Module MED - Specifications', 'G. Boulant', 'manual'),
+ ('medcalc-develguide', 'medcalc-develguide.tex', 'Module MED - Guide de developpement', 'G. Boulant', 'manual'),
+ ('medcalc-userguide-gui', 'medcalc-userguide-gui.tex', 'Module MED - Guide d\'utilisation de l\'interface graphique', 'G. Boulant', 'howto'),
+ ('medcalc-userguide-api', 'medcalc-userguide-api.tex', 'MEDMEM library - Starter guide for users', 'G. Boulant', 'howto')
]
# The name of an image file (relative to this directory) to place at the top of
.. toctree::
:maxdepth: 1
- medop-userguide-gui.rst
- medop-userguide-api.rst
+ medcalc-userguide-gui.rst
+ medcalc-userguide-api.rst
**Documentation technique**
.. toctree::
:maxdepth: 1
- medop-specifications.rst
- medop-develguide.rst
+ medcalc-specifications.rst
+ medcalc-develguide.rst
**Documentation annexe**
.. toctree::
:maxdepth: 1
- medop-references.rst
+ medcalc-references.rst
Archives documentaires
======================
--- /dev/null
+.. AVERTISSEMENT:
+.. Ce fichier contient les définitions globales à la documentation. Il
+.. peut être inclu au moyen de la directive rst "include" pour
+.. disposer des définitions dans le fichier qui fait l'inclusion.
+.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
+.. il est interdit de faire afficher du texte par ce document de
+.. définition.
+
+.. REFERENCES DOCUMENTAIRES:
+.. (les documents sont fournis dans le répertoire _static/documents)
+
+.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
+.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
+.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
+
+.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
+.. |REF_CEA_VBE_MEDMEM| replace:: Guide utilisateur de MED mémoire
+.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
+.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
+.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
+.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
+.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
+.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
+.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
+.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
+.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
+.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
+.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
+
+.. PRESENTATIONS:
+
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
+.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
+.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
+.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
+.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
+.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
+.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
+.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
+.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
+
+
+
+.. LIENS EXTERNES:
+.. (l'accès nécessite le réseau intranet EDF et internet)
+
+.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
+.. |LINK_EDF_MEDDOC| replace:: Modèle MED
+.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
+
+.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
+.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
+.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
+
+.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
+.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
+.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
+
+.. RENVOIES:
+
+.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
+.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
+
+
+.. SNAPSHOTS:
+
+.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
+.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
+
+.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
+.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
+
+.. |XMED_USERGUIDE_PDF| replace:: version pdf
+.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
+
+
+.. =========================================================
+.. Rendering roles
+.. =========================================================
+.. This role can be used to display monospace text (code)
+.. role:: tt
+ :class: tt
+
+.. role:: strike
+ :class: strike
+
+.. role:: bolditalic
+ :class: bolditalic
+
+.. role:: underline
+ :class: underline
+
+.. role:: tag
+ :class: tag
+
+.. role:: tagb
+ :class: tagb
+
+.. role:: todo
+ :class: todo
+
+.. role:: date
+ :class: date
+
+.. role:: warn
+ :class: warn
+
+.. role:: info
+ :class: info
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation, med, développement
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Module MED: Guide de développement du composant MEDCalc
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le composant logiciel MEDCalc est un élément du module MED. Il fournit
+une interface utilisateur pour la manipulation de maillages et de
+champs, composée d'une interface texte (TUI) et d'une interface
+graphique (GUI). L'interface graphique constitue l'interface graphique
+du module MED.
+
+Ce document est la documentation technique du composant MEDCalc. Il
+fournit les instructions à suivre pour installer le composant en vue
+d'un travail de développement, puis décrit les éléments de conception.
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Mise en place de l'espace de développement
+==========================================
+
+Gestion de configuration du composant MEDCalc
+-------------------------------------------
+
+Le composant logiciel MEDCalc est un package du module SALOME MED,
+hébergé dans l'espace source au niveau du sous-répertoire
+`src/MEDCalc`. La gestion des fichiers sources est donc intégrée dans le
+module SALOME MED.
+
+Organisation des sources du composant MEDCalc
+-------------------------------------------
+
+Le répertoire source `src/MEDCalc` distingue les sous-répertoires
+suivants:
+
+* cmp: package containing the SALOME components
+* tui: package containing the python user interface
+* gui: package containing the graphical user interface (the GUI part
+ of the MED module)
+* res: resources files associated to the MEDCalc package (icons, config
+ files, data files, ...)
+* exe: additional executable programs that can be launched from the
+ MEDCalc framework
+
+Construction du composant MEDCalc
+-------------------------------
+
+Intégré à la construction du module MED. Le composant MEDCalc dépend de
+MEDCoupling et MEDLoader uniquement.
+
+Exécution des tests unitaires du composant MEDCalc
+------------------------------------------------
+
+Les tests unitaires peuvent être exécutés au moyen de scripts python
+lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
+
+ $ ./appli/runSession
+ [NS=mars:2810]$ python appli/bin/salome/med/test_medcalc_components.py
+
+L'exécution imprime un rapport détaillant le résultat pour chaque
+fonction de test::
+
+ test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
+ test_Calculator_basics (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
+ test_loadDatasource (__main__.MyTestSuite) ... ok
+ test_getDataManager (__main__.MyTestSuite) ... ok
+ test_getFieldHandlerList (__main__.MyTestSuite) ... ok
+ test_getFieldRepresentation (__main__.MyTestSuite) ... ok
+ test_markAsPersistent (__main__.MyTestSuite) ... ok
+ test_saveFields (__main__.MyTestSuite) ... ok
+ test_updateFieldMetadata (__main__.MyTestSuite) ... ok
+
+Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
+
+* ``test_medcalc_components.py``: test les composants SALOME développés pour
+ la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
+* ``test_xmed_fieldOperations.py``: test des operations de champs telles
+ qu'elles sont mises en oeuvre depuis l'interface textuelle.
+* ``test_xmed_uiEventListener.py``: test du système de notification
+ d'évènements des composants vers la partie gui du module MED.
+* ``test_xmed_visualisation.py``: test du système de visualisation
+ des champs tel que piloté depuis le module MED.
+
+Architecture du module XMED
+===========================
+
+Le module MED pour la manipulation de champs est composé de:
+
+* une bibliothèque de fonctions pour le traitement de données sur des
+ maillages et des champs conformes au modèle MED (package
+ MEDCoupling, MEDLoader et REMAPPER);
+* une interface graphique pour la mise en oeuvre des cas standard de
+ manipulation de champs;
+* une ensemble d'outils pour intervenir sur des fichiers au format
+ MED.
+
+Une bibliothèque de fonctions pour le traitement de données
+-----------------------------------------------------------
+
+La figure ci-dessous montre la structure des paquets logiciels qui
+constituent la bibliothèque:
+
+.. image:: images/medlayers.png
+ :align: center
+
+Elle comprend en particulier les paquets suivants:
+
+* MEDCoupling: qui décrit les structures de données pour porter les
+ maillages et les champs
+* MEDLoader: qui fournit les fonctions de persistence sous forme de
+ fichiers au format MED (lecture et écriture).
+* REMAPPER:
+
+Il est important de noter que MEDCoupling n'a aucune dépendance
+logicielle autre que la bibliothèque C++ standard. Ceci permet
+d'envisager son implantation dans un code de calcul ou un outil de
+traitement sans tirer l'ensemble pré-requis de SALOME.
+
+Une interface graphique pour l'exécution des cas standard
+---------------------------------------------------------
+
+
+Un ensemble d'outils pour le traitement de fichiers
+---------------------------------------------------
+
+
+Description des composants
+==========================
+
+MEDDataManager - Le gestionnaire des données de session
+-------------------------------------------------------
+
+Le composant MEDDataManager s'occupe de fournir les données MED sur
+demande des interfaces clientes, en particulier pour module de
+pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
+en général elle proviennent d'un fichier au format med contenant des
+champs définis sur des maillages. Les données sont identifiées à la
+lecture des métadonnées de description dans le fichiers med, puis les
+valeurs des champs et les maillages support sont chargés au besoin.
+
+Le chargement des métadonnées de description se fait par la méthode::
+
+ loadDatasource(const char \*filepath)
+
+
+
+Eléments d'implémentation
+=========================
+
+Ecrire un service CORBA qui retourne une sequence de FieldHandler:
+
+.. code-block:: cpp
+
+ MEDCALC::FieldHandlerList * MyFunction(...) {
+ vector<MEDCALC::FieldHandler*> fieldHandlerList;
+ ...
+
+ fieldHandlerList.push_back(fieldHandler);
+
+ // Map the resulting list to a CORBA sequence for return:
+ MEDCALC::FieldHandlerList_var fieldHandlerSeq = new MEDCALC::FieldHandlerList();
+ int nbFieldHandler = fieldHandlerList.size();
+ fieldHandlerSeq->length(nbFieldHandler);
+ for (int i=0; i<nbFieldHandler; i++) {
+ fieldHandlerSeq[i] = *fieldHandlerList[i];
+ }
+ return fieldHandlerSeq._retn();
+ }
+
+Ecrire un service CORBA qui retourne une structure CORBA:
+
+.. code-block:: cpp
+
+ MEDCALC::FieldHandler * fieldHandler = new ...
+ _fieldHandlerMap[fieldHandler->id] = fieldHandler;
+
+ // >>> WARNING: CORBA struct specification indicates that the
+ // assignement acts as a desctructor for the structure that is
+ // pointed to. The values of the fields are copy first in the new
+ // structure that receives the assignement and finally the initial
+ // structure is destroyed. In the present case, WE WANT to keep
+ // the initial fieldHandler in the map. We must then make a deep
+ // copy of the structure found in the map and return the copy. The
+ // CORBA struct specification indicates that a deep copy can be
+ // done using the copy constructor. <<<
+ return new MEDCALC::FieldHandler(*fieldHandler);
+
+
+
+ANNEXE A: Bug en cours
+======================
+
+TO FIX:
+
+* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
+ 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
+ reference correcte vers le maillage).
+* le script de test test_medoperation.py plante si le module xmed n'a
+ pas été chargé avec des données chargées.
+
+ANNEXE B: Traçabilité avec le module XMED
+=========================================
+
+Le module SALOME de nom XMED est l'espace de développement initial du
+composant logiciel MEDCalc, intégré aujourd'hui au module MED. Cette
+annexe est la notice technique de ce module, qui reste disponible mais
+qui n'est plus maintenu.
+
+Gestion de configuration du module XMED
+---------------------------------------
+
+Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
+configuration dans une base git du projet NEPAL. Ils peuvent être
+récupérés au moyen de la commande::
+
+ $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
+
+Cette commande installe un répertoire ``xmed`` contenant l'ensemble
+des sources du module XMED.
+
+Le module XMED a pour pré-requis logiciel la plateforme SALOME:
+
+* SALOME version 6.1.3 (au moins) à télécharger à l'URL
+ http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
+* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
+* Installer la plate-forme choisie selon les instructions fournies.
+
+Le module XMED utilise également une bibliothèque interne au projet
+NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
+SALOME pour un usage de développement (XSALOME signifie eXtension
+SALOME). Les sources de cette bibliothèque doivent être récupérés au
+moyen de la commande::
+
+ $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
+
+Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
+des sources de la bibliothèque XSALOME.
+
+.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
+ simple bibliothèque de fonctions qui complète ou rend plus facile
+ d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
+ être intégrée à d'autres projets que les projets internes NEPAL ou
+ MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
+ héberge des développements destinés à être reversés dans la
+ plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
+ donc être garanti sur le long terme.
+
+Installation et lancement de l'application
+------------------------------------------
+
+L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
+disponible et que le shell de travail est étendu avec l'environnement
+de SALOME. En général, par des commandes de la forme::
+
+ $ . /where/is/salome/prerequis.sh
+ $ . /where/is/salome/envSalome.sh
+
+La compilation des modules xsalome et xmed suit le standard SALOME. La
+bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
+cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
+la configuration de la procédure de reconstruction de xmed::
+
+ $ export XSALOME_DIR=<xsalome_installdir>
+
+Aprés l'installation de xmed, il est possible de générer
+automatiquement une application SALOME prête à l'emploi pour la
+manipulation de champs::
+
+ $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
+
+Cette commande génére un répertoire ``appli`` à l'emplacement où elle
+est exécutée. Il reste à lancer l'application SALOME au moyen de la
+commande::
+
+ $ ./appli/runAppli -k
--- /dev/null
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Références documentaires
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. include:: medcalc-definitions.rst
+
+Documents de référence:
+
+* |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
+* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
+* |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
+
+Présentations:
+
+* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
+* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
+* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
+* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
+
+ - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
+ - |REF_EDF_JUS2011_OGV1|_
+ - |REF_EDF_JUS2011_OGV3|_
+ - |REF_EDF_JUS2011_OGV4|_
+
+Notes de travail:
+
+* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
+* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
--- /dev/null
+.. 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>`, 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:
+
+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.
+
+
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation, guide utilisateur
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Module MED: Guide d'utilisation de l'interface graphique
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Ce document est un guide rapide pour l'utilisation de l'interface
+graphique du module MED. Il montre comment utiliser le module sur la
+base de quelques exemples de référence, inspirés des cas d'utilisation
+identifiés lors de l'analyse des besoins en matière de manipulation de
+champs.
+
+.. warning:: Le document est autonome, mais il est vivement conseillé
+ de parcourir au préalable (ou en parallèle) :doc:`le document de
+ spécifications<medcalc-specifications>`, au moins pour fixer les
+ concepts et la terminologie.
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Présentation générale du module MED
+===================================
+
+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.
+
+Pour cela, le module propose deux espaces utilisateurs qui sont
+symbolisés par les rectangles rouges et vert sur la capture d'écran
+ci-dessous:
+
+* **l'espace des données** (*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 permet l'exploration des maillages et des champs fournis par
+ les différentes sources de données.
+* **l'espace de travail** (*workspace*), dans lequel l'utilisateur
+ peut déposer des champs sélectionnées dans l'espace source, pour
+ ensuite les travailler par exemple pour produire des nouveaux champs
+ au moyen des fonctions de manipulation fournies par l'interface
+ textuelle (console python TUI).
+
+.. image:: images/xmed-gui-withframe.png
+ :align: center
+
+L'utilisation type des fonctions de manipulation de champs suit un
+processus de la forme suivante:
+
+1. Chargement d'un fichier med dans l'espace de données (dataspace) et
+ exploration du contenu, composé de maillages et de champs définis
+ sur ces maillages et pouvant contenir un ou plusieurs pas de temps.
+2. Sélection (graphique) des champs à manipuler dans l'espace de
+ travail (workspace), 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" sur 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
+
+
+Tour rapide des fonctions du module MED
+=======================================
+
+Cette section présente des exemples d'utilisation du module XMED sous
+la forme de "storyboard", et illustre au passage les fonctions mises à
+disposition par le module.
+
+.. warning:: Cette section est en travaux. Tant que cet avis n'aura
+ pas disparu, veuillez en considérer le plan et le contenu encore
+ incomplets, temporaires et sujets à caution.
+
+Exemple 1: Explorer des sources de données
+------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * ajouter une source de données
+ * fonctions "Extends field series", "Visualize"
+
+.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
+ :height: 16px
+
+.. |ICO_XMED| image:: images/ico_xmed.png
+ :height: 16px
+
+.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
+ :height: 16px
+
+.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
+ :height: 16px
+
+Au démarrage, le module de manipulation de champs, identifié par
+l'icône |ICO_XMED|, présente une interface vierge:
+
+.. image:: images/xmed-gui-start.png
+ :align: center
+ :width: 800px
+
+La première étape consiste à ajouter une ou plusieurs source de
+données med dans le "dataspace". Pour cela, on clique sur l'icône "Add
+datasource" |ICO_DATASOURCE_ADD| qui propose de sélectionner un
+fichier med:
+
+.. image:: images/xmed-gui-datasource-selectfile.png
+ :align: center
+ :width: 800px
+
+L'opération ajoute une nouvelle entrée (datasource) dans l'espace de
+données (dataspace). Le contenu peut être exploré en parcourant
+l'arborescence. La figure ci-dessous (image de gauche) montre le
+résultat du chargement du fichier ``timeseries.med`` contenant un
+maillage de nom ``Grid_80x80`` sur lequel est défini un champ au noeud
+de nom ``Pulse``. Par défaut, la composition du champs (en terme de
+pas de temps et de composantes) n'est pas affichée pour éviter
+l'encombrement visuel de l'arbre. On doit faire la demande explicite
+au moyen de la commande "Expand field timeseries"
+|ICO_DATASOURCE_EXPAND| disponible dans le menu contextuel associé aux
+champs. Le résultat est affiché sur l'image centrale. La liste des
+itérations du champ ``Pulse`` peut être consultée.
+
+.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
+ :height: 340px
+.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
+ :height: 340px
+.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
+ :height: 340px
+
++--------------------------+--------------------------+--------------------------+
+| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
++--------------------------+--------------------------+--------------------------+
+
+.. note:: En toute rigueur, le concept de *champ* dans le modèle MED
+ désigne une itération donnée. Un ensemble d'itérations est désigné
+ par le terme *série temporelle de champs*. Par abus de langage, et
+ s'il n'y a pas ambiguité, on utilisera le nom du champ pour
+ désigner à la fois le champs proprement dit ou la série temporelle
+ à laquelle il appartient.
+
+Enfin, il est possible au niveau du dataspace de visualiser la forme
+générale du champ au moyen d'une carte scalaire affichée dans le
+viewer de SALOME. Pour cela, on sélectionne le pas de temps à
+visualiser et on utilise la commande "Visualize" |ICO_DATASOURCE_VIEW|
+disponible dans le menu contextuel associé:
+
+.. image:: images/xmed-gui-datasource-visualize-zoom.png
+ :align: center
+ :width: 800px
+
+.. note:: Cette représentation graphique a pour objectif le contrôle
+ visuel rapide. Aussi, les fonctions du module VISU sont employées
+ par défaut, mais il est possible de faire l'affichage des cartes
+ scalaires au moyen du module PARAVIS (choix de préférence non
+ implémenté pour le moment, mais techniquement réalisable).
+
+Exemple 2: Rassembler des champs issus de différentes sources
+-------------------------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * fonction "Use in workspace"
+ * fonction "Save"
+
+.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
+ :height: 16px
+.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
+ :height: 16px
+
+L'objectif est de récupérer des données issues de différents fichiers
+med, puis de les rassembler dans un même fichier en sortie.
+
+On commence par ajouter les sources de données med dans l'espace de
+données (dataspace). Dans l'exemple ci-dessous, l'espace de données
+contient deux sources de nom ``parametric_01.med`` et
+``smallmesh_varfiled.med``. La première source contient le maillage
+``Grid_80x80_01`` sur lequel est défini le champ ``StiffExp_01``. La
+deuxième source contient le maillage ``My2DMesh`` sur lequel sont
+définis deux champs de noms respectifs ``testfield1`` et
+``testfield2``:
+
+.. image:: images/xmed-userguide-example2-datasource.png
+ :align: center
+ :width: 800px
+
+Pour l'exemple, on souhaite rassembler les champs ``StiffExp_01`` et
+``testfield2`` dans un fichier de nom ``result.med``. La procédure
+consiste à importer les deux champs dans l'espace de travail
+(workspace), puis à sauvegarder l'espace de travail. Pour cela, on
+sélectionne les champs et on utilise la commande "Use in workspace"
+|ICO_DATASOURCE_USE| disponible dans le menu contextuel. Les deux
+champs sélectionnés apparaissent dans l'arborescence de l'espace de
+travail:
+
+.. image:: images/xmed-userguide-example2-workspace.png
+ :align: center
+ :width: 800px
+
+La sauvegarde de l'espace de travail est faite au moyen de la commande
+"Save workspace" |ICO_WORKSPACE_SAVE| disponible dans la barre
+d'outils du module. Une fenêtre de dialogue invite l'utilisateur à
+spécifier le nom du fichier de sauvegarde:
+
+.. image:: images/xmed-userguide-example2-workspace-save.png
+ :align: center
+ :width: 800px
+
+Ce fichier ``result.med`` peut ensuite être rechargé dans le module
+XMED (ou les modules VISU ou PARAVIS) pour vérifier la présence des
+champs sauvegardés.
+
+.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
+.. (invalid mesh on field)
+
+.. _xmed.userguide.exemple3:
+
+Exemple 3: Appliquer une opération mathématique sur des champs
+--------------------------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * exécution d'opérations mathématiques dans la console TUI
+ * fonction "put" pour référencer un champ de travail dans la liste
+ des champs persistant.
+ * fonction "Visualize" depuis le TUI.
+
+L'usage le plus courant du module de manipulation de champs est
+d'exécuter des opérations mathématiques dont les opérandes sont des
+champs ou des composantes de ces champs.
+
+On se place dans une situation où les sources de données sont définies
+dans le "dataspace" (dans l'exemple ci-après, une série temporelle de
+nom ``Pulse``, contenant 10 pas de temps, définis sur un maillage de
+nom ``Grid_80x80``, le tout issu du datasource ``timeseries.med``).
+
+Comme vu précedemment, pour manoeuvrer un champ dans l'espace de
+travail, on sélectionne ce champ, puis on exécute la commande "Use in
+workspace" |ICO_DATASOURCE_USE| du menu contextuel. Dans le cas
+présent, un seul champ est sélectionné (contre deux dans l'exemple
+précédent) et la commande ouvre alors une fenêtre de dialogue qui
+permet de préciser les données sur lesquelles on souhaite
+effectivement travailler et comment on veut les manoeuvrer:
+
+.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
+ :align: center
+ :width: 800px
+
+.. note:: En l'état actuel du développement, l'interface propose
+ uniquement de définir le nom de la variable sous laquelle doit être
+ manoeuvré le champ dans la console de travail (TUI). Dans une
+ version ultérieure, il est prévue de pouvoir préciser la ou les
+ composante du champs à utiliser et un groupe de maille pour définir
+ une restriction géométrique. Inversement, il sera également
+ possible de choisir une série temporelle complète pour faire des
+ opérations globales sur l'ensemble des pas de temps.
+
+Aprés validation, le champ est placé dans l'arborescence du
+"workspace" et une variable de nom ``<alias>`` est créée
+automatiquement dans la console de travail pour désigner le
+champ. Dans cet exemple, ``<alias>`` vaut ``f3``, positionné ainsi par
+l'utilisateur pour rappeler que la variable correspond au pas de temps
+n°3:
+
+.. image:: images/xmed-gui-workspace.png
+ :align: center
+ :width: 800px
+
+La manipulation peut commencer. Dans l'exemple ci-dessous, on crée le
+champ ``r`` comme le résultat d'une transformation afine du champ
+``f3`` (multiplication du champ par le facteur 2.7 auquel on ajoute
+l'offset 5.2)::
+
+ >>> r=2.7*f3+5.2
+
+On peut poursuivre la manipulation du champs avec une variété
+d'opérations qui sont détaillées dans les spécifications du module
+(cf. :ref:`Spécification des opérations<xmed-specifications>`):
+
+ >>> r=f3/1000 # les valeurs de r sont celles du champ f3 réduites d'un facteur 1000
+ >>> r=1/f3 # les valeurs de r sont les inverses des valeurs de f3
+ >>> r=f3*f3 # les valeurs de r sont celles du champ f3 élevées au carré
+ >>> r=pow(f3,2) # même résultat
+ >>> r=abs(f3) # valeur absolue du champ f3
+ >>> ...
+
+Les opérations peuvent utiliser plusieurs opérandes de type champs. Si
+``f4`` désigne le pas de temps n°4 du champ ``Pulse``, alors on peut
+calculer toute combinaison algébrique des deux champs::
+
+ >>> r=f3+f4
+ >>> r=f3-f4
+ >>> r=f3/f4
+ >>> r=f3*f4
+
+Avec au besoin l'utilisation de variables scalaires::
+
+ >>> r=4*f3-f4/1000
+ >>> ...
+
+Dans ces exemples, la variable ``r`` désigne un champ de travail qui
+contient le résultat de l'opération. Par défaut, ce champ de travail
+n'est pas référencé dans l'arborescence du workspace. Si on souhaite
+tout de même le référencer, par exemple pour qu'il soit pris en compte
+dans la sauvegarde, alors on tape la commande::
+
+ >>> put(r)
+
+La fonction ``put`` a pour but de marquer le champ en argument comme
+persistent, puis de le ranger dans l'arborescence du "workspace" afin
+qu'il soit visible et sélectionnable. En effet, parmi tous les champs
+qui pourront être créés dans la console pendant la session de travail,
+tous n'ont pas besoin d'être sauvegardés. Certains sont même des
+variables temporaires qui servent à la construction des champs
+résultats finaux. C'est pourquoi, seuls les champs rangés dans
+l'arborescence du workspace sont enregistrés lors de la demande de
+sauvegarde du workspace.
+
+Les variables définies dans la console ont d'autres utilités. Tout
+d'abord, elles permettent d'imprimer les informations concernant le
+champ manoeuvré. Pour cela, on tape simplement le nom de la variable
+puis retour::
+
+ >>> f3
+ field name (id) = Pulse (3)
+ mesh name (id) = Grid_80x80 (0)
+ discretization = ON_NODES
+ (iter, order) = (3,-1)
+ data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
+
+Elle peut également être utilisée comme argument des commandes de
+gestion disponibles dans l'interface textuelle (dont la liste
+détaillée est décrite à la section :ref:`Documentation de l'interface
+textuelle<xmed.userguide.tui>`). Par exemple, la fonction ``view``
+permet d'afficher la carte scalaire du champ dans le viewer::
+
+ >>> view(f3)
+
+Donne:
+
+.. image:: images/xmed-gui-workspace-view.png
+ :align: center
+ :width: 800px
+
+.. note:: On remarquera ici qu'il est facile de comparer deux pas de
+ temps d'un champ, par exemple en calculant la différence ``f3-f4``,
+ puis en affichant un aperçu de la carte scalaire résultat au moyen
+ de la fonction ``view``::
+
+ >>> view(f3-f4)
+
+On peut enfin tout simplement afficher les données du champs par la
+commande ``print``::
+
+ >>> print f3
+ Data content :
+ Tuple #0 : -0.6
+ Tuple #1 : -0.1
+ Tuple #2 : 0.4
+ Tuple #3 : -0.1
+ Tuple #4 : 0.4
+ ...
+ Tuple #6556 : 3.5
+ Tuple #6557 : 3.3
+ Tuple #6558 : 1.5
+ Tuple #6559 : 0.3
+ Tuple #6560 : 0.2
+
+Il est important de noter que les opérations entre champs ne peuvent
+être faites qu'entre champs définis sur le même maillage. Il s'agit là
+d'une spécification du modèle MED qui interdit d'envisager les
+opérations entre champs définis sur des maillages géométriquement
+différents. Techniquement, cela se traduit par l'obligation pour les
+objets informatique *champs* de partager le même objet informatique
+*maillage*.
+
+Dans l'hypothèse où on souhaite utiliser des champs définis sur des
+maillages différents, par exemple pour manoeuvrer les valeurs des
+champs à l'interface de deux maillages partageant une zone géométrique
+2D, il faut d'abord ramener tous les champs sur le même maillage de
+surface par une opération de projection.
+
+.. note:: Même si ceci est techniquement possible avec la bibliothèque
+ MEDCoupling, cet type d'opération de projection n'est pas encore
+ disponible dans le module de manipulation de champs (prévu en
+ 2012).
+
+Un autre besoin plus classique est l'utilisation de champs définis sur
+des maillages géométriquement identiques, mais techniquement
+différents, par exemple lorsqu'ils sont chargés de fichiers med
+différents. Pour traiter ce cas de figure, la bibliothèque MEDCoupling
+prévoit une fonction de "Changement du maillage support", dont
+l'utilisation au niveau du module de manipulation de champs est
+illustrée dans :ref:`l'exemple 4<xmed.userguide.exemple4>` ci-après.
+
+.. _xmed.userguide.exemple4:
+
+Exemple 4: Comparer des champs issues de différentes sources
+------------------------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * Changement du maillage support "change underlying mesh"
+
+On se place ici dans le cas de figure où des champs ont été produits
+sur le même maillage, au sens géométrique, mais enregistrés dans des
+fichiers med différents. C'est le cas par exemple d'une étude
+paramétrique où plusieurs calculs sont effectués avec des variantes
+sur certains paramètres du modèle simulé, chaque calcul produisant un
+fichier med.
+
+Soit ``parametric_01.med`` et ``parametric_02.med`` deux fichiers med
+contenant les champs que l'on souhaite comparer, par exemple en
+calculant la différence des valeurs et en visualisant le résultat.
+
+Aprés le chargement des sources de données dans le module XMED,
+l'utilisateur se trouve en présence de deux maillages, au sens
+technique du terme cette fois-ci, c'est-à-dire que les champs sont
+associées à des objets informatiques maillage différents, bien que
+géométriquement identiques.
+
+Or, les fonctions de manipulation de champs ne permettent pas les
+opérations sur des champs dont les maillages supports sont différents
+(voir la remarque à la fin de :ref:`l'exemple
+3<xmed.userguide.exemple3>`).
+
+Pour résoudre ce cas de figure, le module de manipulation de champs
+met à disposition la fonction "Change underlying mesh" qui permet de
+remplacer le maillage support d'un champ par un autre à partir du
+moment où les deux maillages sont géométriquement identiques,
+c'est-à-dire que les noeuds ont les mêmes coordonnées spatiales.
+
+.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
+ :height: 16px
+
+Dans l'exemple proposé, l'utilisateur sélectionne le premier pas de
+temps du champ ``StiffExp_01`` du "datasource" ``parametric_01.med``,
+puis l'importe dans l'espace de travail au moyen de la commande "Use
+in workspace" |ICO_DATASOURCE_USE|. Il sélectionne ensuite le premier
+pas de temps du champs ``StiffExp_02`` du "datasource"
+``parametric_02.med``, mais l'importe dans l'espace de travail au
+moyen de la commande "Change underlying mesh" |ICO_DATASOURCE_CHG|. La
+fenêtre de dialogue ci-dessous s'affiche et invite l'utilisateur à
+choisir le nouveau maillage support par sélection dans l'arborescence
+du "dataspace":
+
+.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
+ :align: center
+
+Dans cet exemple, on sélectionne le maillage ``Grid_80x80_01`` support
+du champ ``StiffExp_01``, avec lequel on souhaite faire la
+comparaison. Après validation, l'arborescence du workspace contient le
+champ ``StiffExp_02`` défini sur le maillage ``Grid_80x80_01``:
+
+.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
+ :align: center
+
+.. note:: La fonction "Change underlying mesh" ne modifie pas le champ
+ sélectionné dans le "dataspace" (principe de base de fonctionnement
+ du dataspace), mais crée une copie du champ dans l'espace de travail
+ pour ensuite remplacer le maillage support. D'où le nom par défaut
+ pour le champ ``dup(<nom du champ sélectionné>)`` (dup pour
+ "duplicate").
+
+Il reste à associer une variable à ce champ pour le manipuler dans la
+console. Ceci peut être fait au moyen de la commande "Use in console",
+disponible dans le menu contextuel du workspace.
+
+En définitif, si ``f1`` désigne le champ issu du datasource
+``parametric_01.med`` et ``f2`` le champ issu du datasource
+``parametric_02.med`` par la procédure décrite ci-dessus, alors la
+comparaison des deux grandeurs peut être faite comme pour le cas de
+:ref:`l'exemple 3<xmed.userguide.exemple3>`::
+
+ >>> r=f1-f2
+ >>> view(r)
+
+.. note:: En remarque générale sur cet exemple, il convient de noter
+ les points suivants:
+
+ * l'égalité géométrique de deux maillages est établie à une marge
+ d'erreur prés qu'il est possible de définir techniquement, mais
+ qui n'est pas ajustable au niveau de l'interface du module de
+ manipulation de champs. Elle est fixée à une valeur standard qui
+ permet de traiter la plupart des cas utilisateur. On verra à
+ l'usage s'il est nécessaire de remonter ce paramètre au niveau de
+ l'interface.
+ * L'utilisateur doit faire la démande explicite de changer le
+ maillage support d'un champ, en prévision de la comparaison de
+ champs issus de datasource différentes. Il s'agit là d'un choix
+ fonctionnel délibéré pour que l'utilisateur garde trace des
+ modifications faites sur les données (pas de modification
+ automatiques à l'insu de l'utilisateur, même sous prétexte
+ d'amélioration de l'ergonomie).
+
+
+Exemple 5: Créer un champ sur un domaine spatial
+------------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * initialisation par une fonction de la position spatiale
+ * initialisation sur un groupe de maille
+
+Le domaine géométrique de définition du champs à créer est spécifié
+ici par la donnée d'un groupe de mailles. Ce cas d'usage est
+typiquement prévu pour produire les conditions de chargement initial
+d'une structure, par exemple en définissant un champ sur une surface
+de la géométrie, identifiée par un nom de groupe de mailles.
+
+.. warning:: DEVELOPPEMENT EN COURS
+
+Exemple 6: Extraire une partie d'un champ
+-----------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * extraire une composante (ou un sous-ensemble des composantes)
+ * extraire un domaine géométrique (valeurs sur un groupe de maille)
+ * extraire un ou plusieurs pas de temps.
+
+.. warning:: DEVELOPPEMENT EN COURS
+
+ On doit illustrer ici les fonctions de restriction, qui
+ permettraient de récupérer certaines composantes uniquement. Le
+ principe est qu'on crée un nouveau champ qui est une restriction du
+ champ argument à une liste de composantes à spécifier (utiliser la
+ fonction __call__ des fieldproxy).
+
+Pour l'extraction des pas de temps, on peut se ramener au cas de
+l'exemple 2 avec une seule source de donnée.
+
+Exemple 7: Créer un champ à partir d'une image to[mp]ographique
+---------------------------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * Création d'un champ sans datasource (ni maillage, ni champs), à
+ partir d'un fichier image
+
+En tomographie ou en topographie, les appareils de mesure produisent
+des images qui représentent une grandeur physique en niveaux de gris
+sur un plan de coupe donné. L'image ci-dessous représente par exemple
+une vue interne du corps humain faite par IRM:
+
+.. image:: images/xmed-irm.png
+ :align: center
+ :width: 600px
+
+Cette image est un ensemble de pixels organisés sur une grille
+cartesienne. Elle peut donc être modélisée sous la forme d'un champ
+scalaire dont les valeurs sont définies aux cellules d'un maillage
+réglés de même taille que l'image (en nombre de pixels):
+
+.. image:: images/xmed-irm-field.png
+ :align: center
+ :width: 600px
+
+Le module de manipulation de champ fournit un utilitaire appelé
+``image2med.py`` qui permet d'appliquer ce principe à la conversion
+d'un fichier image en fichier med contenant la représentation de
+l'image sous forme d'un champ scalaire (seul le niveau de gris est
+conservé)::
+
+ $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
+
+.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
+ :height: 16px
+
+Cette opération de conversion peut être faite automatiquement dans
+l'interface graphique du module au moyen de la commande "Add Image
+Source" |ICO_IMAGESOURCE| disponible dans la barre d'outils. Cette
+commande ouvre la fenêtre suivante pour inviter l'utilisateur à
+choisir un fichier image:
+
+.. image:: images/medop_image2med_dialog.png
+ :align: center
+
+Le nom du fichier med résultat est proposé par défaut (changement de
+l'extention en ``*.med``) mais il peut être modifié. Enfin, on peut
+demander le chargement automatique du fichier med produit pour ajout
+dans l'espace de donnée. Les champs peuvent alors être manipulés comme
+dans les cas d'utilisation standard.
+
+Par exemple, l'image ci-dessous affiche le résultat de la différence
+entre deux images, ajoutée à l'image de référence: si i1 et i2
+désignent les champs créés à partir des deux images, on représente ``r
+= i1 + 5*(i2-i1)`` où le facteur 5 est arbitraire et sert à amplifier
+la zone d'intérêt (en haut de l'oeil gauche):
+
+.. image:: images/xmed-irm-diff.png
+ :align: center
+ :width: 600px
+
+L'exemple ci-dessous est le résultat du chargement d'une image
+tomographique issue du projet MAP (Charles Toulemonde,
+EDF/R&D/MMC). L'image tomographique:
+
+.. image:: images/champ_altitude_MAP.png
+ :align: center
+ :width: 600px
+
+Le résultat du chargement:
+
+.. image:: images/medop_image2med_tomographie.png
+ :align: center
+ :width: 800px
+
+Exemple 8: Continuer l'analyse dans PARAVIS
+-------------------------------------------
+
+.. note:: Cet exemple présente les fonctions:
+
+ * Export de champs vers le module PARAVIS.
+
+Les possibilités de représentation graphique des champs fournies par
+le module MED ont pour seul objectif le contrôle visuel rapide. Par
+défaut, le viewer de VISU est employé.
+
+Pour une analyse plus détaillées des champs, il est nécessaire de
+poursuivre le travail dans PARAVIS. Le module de manipulation de
+champs offre une fonction qui simplifie ce passage, en faisant le
+chargement automatique dans PARAVIS et en proposant une visualisation
+par défaut (carte de champs scalaire).
+
+Pour cela, il faut sélectionner dans l'espace de travail les champs à
+exporter, puis déclencher la fonction d'export depuis le menu
+contextuel associé:
+
+.. image:: images/medop_exportparavis.png
+ :align: center
+
+Les champs sélectionnés sont regroupés dans une entrée MED du
+navigateur PARAVIS, et le premier champ est affiché sous forme de
+carte de champ:
+
+.. image:: images/medop_exportparavis_result.png
+ :align: center
+ :width: 800px
+
+.. note:: La fonction d'export est une fonction de confort. La même
+ opération peut être faite manuellement en procédant d'abord à
+ l'enregistrement des champs sous forme de fichier MED, puis en
+ chargeant le fichier généré dans le module PARAVIS pour
+ visualisation.
+
+.. _xmed.userguide.tui:
+
+Utilisation de l'interface textuelle du module MED (TUI)
+========================================================
+
+Toutes les opérations menées au moyen de l'interface graphique peuvent
+être réalisées (avec plus ou moins de facilité) avec l'interface
+textuelle. Le module de manipulation de champs peut même être utilisé
+exclusivement en mode texte.
+..
+ Pour cela, on lance la commande::
+
+ $ <path/to/appli>/medop.sh
+..
+ Cette commande ouvre une console de commandes ``medop>``. Un fichier
+ med peut être chargé et travaillé, par exemple pour créer des champs à
+ partir des données du fichier.
+
+Que l'on soit en mode texte pur ou en mode graphique, un séquence de
+travail type dans la console peut ressembler au jeu d'instructions
+suivantes::
+
+ >>> medcalc.LoadDataSource("/path/to/mydata.med")
+ >>> la
+ id=0 name = testfield1
+ id=1 name = testfield2
+ >>> f1=accessField(0)
+ >>> f2=accessField(1)
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ >>> r=f1+f2
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ r (id=2, name=testfield1+testfield2)
+ >>> r.update(name="toto")
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ r (id=2, name=toto)
+ >>> putInWorkspace(r)
+ >>> saveWorkspace("result.med")
+
+Les commandes principales sont:
+
+* ``LoadDataSource``: charge un fichier med dans la base de données (utile
+ uniquement en mode texte pur)::
+
+ >>> LoadDataSource("/path/to/datafile.med")
+
+* ``LoadImageAsDataSource``: load an image as a med file
+
+* ``la``: affiche la liste de tous les champs chargés en base de données ("list all")
+* ``accessField``: définit un champ dans l'espace de travail à partir de son
+ identifiant (utile plutôt en mode texte pur car l'interface
+ graphique permet de faire cette opération par sélection d'un champ
+ dans le dataspace)::
+
+ >>> f=accessField(fieldId)
+
+* ``ls``: affiche la liste des champs présent dans l'espace de travail ("list")
+* ``putInWorkspace``: met un champ en référence dans l'*espace de gestion*::
+
+ >>> putInWorkspace(f)
+
+* ``saveWorkspace``: sauvegarde tous les champs référencés dans l'espace de
+ gestion dans un fichier med::
+
+ >>> saveWorkspace("/path/to/resultfile.med")
+
+.. note:: On peut faire à ce stade plusieurs remarques:
+
+ * la commande ``LoadDataSource`` charge uniquement les méta-informations
+ décrivant les maillage et les champs (noms, type de
+ discrétisation, liste des pas de temps). Les maillages et les
+ valeurs physiques des champs sont chargées ultérieurement (et
+ automatiquement) dés lors qu'elles sont requises par une
+ opération. Dans tous les cas, les données med (méta-informations
+ et valeurs) sont physiquement stockées au niveau de l'espace
+ *base de données*.
+ * la commande ``accessField`` définit en réalité un *manipulateur de champ*
+ dans l'espace de travail, c'est-à-dire une variable qui fait la
+ liaison avec le champ physique hébergé dans la base de
+ données. Les données physiques ne circulent jamais entre les
+ espaces, mais restent centralisées au niveau de la base de
+ données.
+
+Les commandes TUI suivantes nécessitent de travailler dans
+l'environnement graphique:
+
+* ``medcalc.MakeDeflectionShape``
+* ``medcalc.MakeIsoSurface``
+* ``medcalc.MakePointSprite``
+* ``medcalc.MakeScalarMap``
+* ``medcalc.MakeSlices``
+* ``medcalc.MakeVectorField``
+++ /dev/null
-.. AVERTISSEMENT:
-.. Ce fichier contient les définitions globales à la documentation. Il
-.. peut être inclu au moyen de la directive rst "include" pour
-.. disposer des définitions dans le fichier qui fait l'inclusion.
-.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
-.. il est interdit de faire afficher du texte par ce document de
-.. définition.
-
-.. REFERENCES DOCUMENTAIRES:
-.. (les documents sont fournis dans le répertoire _static/documents)
-
-.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
-.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
-.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
-
-.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
-.. |REF_CEA_VBE_MEDMEM| replace:: Guide utilisateur de MED mémoire
-.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
-.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
-.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
-.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
-.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
-.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
-.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
-.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
-.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
-.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
-.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
-
-.. PRESENTATIONS:
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
-.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
-.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
-.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
-.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
-.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
-.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
-.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
-.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
-
-
-
-.. LIENS EXTERNES:
-.. (l'accès nécessite le réseau intranet EDF et internet)
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
-.. |LINK_EDF_MEDDOC| replace:: Modèle MED
-.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
-.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
-.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
-
-.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
-.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
-.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
-
-.. RENVOIES:
-
-.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
-.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
-
-
-.. SNAPSHOTS:
-
-.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
-.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
-
-.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
-.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
-
-.. |XMED_USERGUIDE_PDF| replace:: version pdf
-.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
-
-
-.. =========================================================
-.. Rendering roles
-.. =========================================================
-.. This role can be used to display monospace text (code)
-.. role:: tt
- :class: tt
-
-.. role:: strike
- :class: strike
-
-.. role:: bolditalic
- :class: bolditalic
-
-.. role:: underline
- :class: underline
-
-.. role:: tag
- :class: tag
-
-.. role:: tagb
- :class: tagb
-
-.. role:: todo
- :class: todo
-
-.. role:: date
- :class: date
-
-.. role:: warn
- :class: warn
-
-.. role:: info
- :class: info
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med, développement
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide de développement du composant MEDOP
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le composant logiciel MEDOP est un élément du module MED. Il fournit
-une interface utilisateur pour la manipulation de maillages et de
-champs, composée d'une interface texte (TUI) et d'une interface
-graphique (GUI). L'interface graphique constitue l'interface graphique
-du module MED.
-
-Ce document est la documentation technique du composant MEDOP. Il
-fournit les instructions à suivre pour installer le composant en vue
-d'un travail de développement, puis décrit les éléments de conception.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Mise en place de l'espace de développement
-==========================================
-
-Gestion de configuration du composant MEDOP
--------------------------------------------
-
-Le composant logiciel MEDOP est un package du module SALOME MED,
-hébergé dans l'espace source au niveau du sous-répertoire
-`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le
-module SALOME MED.
-
-Organisation des sources du composant MEDOP
--------------------------------------------
-
-Le répertoire source `src/MEDOP` distingue les sous-répertoires
-suivants:
-
-* cmp: package containing the SALOME components
-* tui: package containing the python user interface
-* gui: package containing the graphical user interface (the GUI part
- of the MED module)
-* res: resources files associated to the MEDOP package (icons, config
- files, data files, ...)
-* exe: additional executable programs that can be launched from the
- MEDOP framework
-
-Construction du composant MEDOP
--------------------------------
-
-Intégré à la construction du module MED. Le composant MEDOP dépend de
-MEDCoupling et MEDLoader uniquement.
-
-Exécution des tests unitaires du composant MEDOP
-------------------------------------------------
-
-Les tests unitaires peuvent être exécutés au moyen de scripts python
-lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
-
- $ ./appli/runSession
- [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py
-
-L'exécution imprime un rapport détaillant le résultat pour chaque
-fonction de test::
-
- test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
- test_Calculator_basics (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
- test_addDatasource (__main__.MyTestSuite) ... ok
- test_getDataManager (__main__.MyTestSuite) ... ok
- test_getFieldHandlerList (__main__.MyTestSuite) ... ok
- test_getFieldRepresentation (__main__.MyTestSuite) ... ok
- test_markAsPersistent (__main__.MyTestSuite) ... ok
- test_saveFields (__main__.MyTestSuite) ... ok
- test_updateFieldMetadata (__main__.MyTestSuite) ... ok
-
-Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
-
-* ``test_medop_components.py``: test les composants SALOME développés pour
- la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
-* ``test_xmed_fieldOperations.py``: test des operations de champs telles
- qu'elles sont mises en oeuvre depuis l'interface textuelle.
-* ``test_xmed_uiEventListener.py``: test du système de notification
- d'évènements des composants vers la partie gui du module MED.
-* ``test_xmed_visualisation.py``: test du système de visualisation
- des champs tel que piloté depuis le module MED.
-
-Architecture du module XMED
-===========================
-
-Le module MED pour la manipulation de champs est composé de:
-
-* une bibliothèque de fonctions pour le traitement de données sur des
- maillages et des champs conformes au modèle MED (package
- MEDCoupling, MEDLoader et REMAPPER);
-* une interface graphique pour la mise en oeuvre des cas standard de
- manipulation de champs;
-* une ensemble d'outils pour intervenir sur des fichiers au format
- MED.
-
-Une bibliothèque de fonctions pour le traitement de données
------------------------------------------------------------
-
-La figure ci-dessous montre la structure des paquets logiciels qui
-constituent la bibliothèque:
-
-.. image:: images/medlayers.png
- :align: center
-
-Elle comprend en particulier les paquets suivants:
-
-* MEDCoupling: qui décrit les structures de données pour porter les
- maillages et les champs
-* MEDLoader: qui fournit les fonctions de persistence sous forme de
- fichiers au format MED (lecture et écriture).
-* REMAPPER:
-
-Il est important de noter que MEDCoupling n'a aucune dépendance
-logicielle autre que la bibliothèque C++ standard. Ceci permet
-d'envisager son implantation dans un code de calcul ou un outil de
-traitement sans tirer l'ensemble pré-requis de SALOME.
-
-Une interface graphique pour l'exécution des cas standard
----------------------------------------------------------
-
-
-Un ensemble d'outils pour le traitement de fichiers
----------------------------------------------------
-
-
-Description des composants
-==========================
-
-MEDDataManager - Le gestionnaire des données de session
--------------------------------------------------------
-
-Le composant MEDDataManager s'occupe de fournir les données MED sur
-demande des interfaces clientes, en particulier pour module de
-pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
-en général elle proviennent d'un fichier au format med contenant des
-champs définis sur des maillages. Les données sont identifiées à la
-lecture des métadonnées de description dans le fichiers med, puis les
-valeurs des champs et les maillages support sont chargés au besoin.
-
-Le chargement des métadonnées de description se fait par la méthode::
-
- addDatasource(const char \*filepath)
-
-
-
-Eléments d'implémentation
-=========================
-
-Ecrire un service CORBA qui retourne une sequence de FieldHandler:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandlerList * MyFunction(...) {
- vector<MEDOP::FieldHandler*> fieldHandlerList;
- ...
-
- fieldHandlerList.push_back(fieldHandler);
-
- // Map the resulting list to a CORBA sequence for return:
- MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList();
- int nbFieldHandler = fieldHandlerList.size();
- fieldHandlerSeq->length(nbFieldHandler);
- for (int i=0; i<nbFieldHandler; i++) {
- fieldHandlerSeq[i] = *fieldHandlerList[i];
- }
- return fieldHandlerSeq._retn();
- }
-
-Ecrire un service CORBA qui retourne une structure CORBA:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandler * fieldHandler = new ...
- _fieldHandlerMap[fieldHandler->id] = fieldHandler;
-
- // >>> WARNING: CORBA struct specification indicates that the
- // assignement acts as a desctructor for the structure that is
- // pointed to. The values of the fields are copy first in the new
- // structure that receives the assignement and finally the initial
- // structure is destroyed. In the present case, WE WANT to keep
- // the initial fieldHandler in the map. We must then make a deep
- // copy of the structure found in the map and return the copy. The
- // CORBA struct specification indicates that a deep copy can be
- // done using the copy constructor. <<<
- return new MEDOP::FieldHandler(*fieldHandler);
-
-
-
-ANNEXE A: Bug en cours
-======================
-
-TO FIX:
-
-* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
- 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
- reference correcte vers le maillage).
-* le script de test test_medoperation.py plante si le module xmed n'a
- pas été chargé avec des données chargées.
-
-ANNEXE B: Traçabilité avec le module XMED
-=========================================
-
-Le module SALOME de nom XMED est l'espace de développement initial du
-composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette
-annexe est la notice technique de ce module, qui reste disponible mais
-qui n'est plus maintenu.
-
-Gestion de configuration du module XMED
----------------------------------------
-
-Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
-configuration dans une base git du projet NEPAL. Ils peuvent être
-récupérés au moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
-
-Cette commande installe un répertoire ``xmed`` contenant l'ensemble
-des sources du module XMED.
-
-Le module XMED a pour pré-requis logiciel la plateforme SALOME:
-
-* SALOME version 6.1.3 (au moins) à télécharger à l'URL
- http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
-* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
-* Installer la plate-forme choisie selon les instructions fournies.
-
-Le module XMED utilise également une bibliothèque interne au projet
-NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
-SALOME pour un usage de développement (XSALOME signifie eXtension
-SALOME). Les sources de cette bibliothèque doivent être récupérés au
-moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
-
-Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
-des sources de la bibliothèque XSALOME.
-
-.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
- simple bibliothèque de fonctions qui complète ou rend plus facile
- d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
- être intégrée à d'autres projets que les projets internes NEPAL ou
- MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
- héberge des développements destinés à être reversés dans la
- plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
- donc être garanti sur le long terme.
-
-Installation et lancement de l'application
-------------------------------------------
-
-L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
-disponible et que le shell de travail est étendu avec l'environnement
-de SALOME. En général, par des commandes de la forme::
-
- $ . /where/is/salome/prerequis.sh
- $ . /where/is/salome/envSalome.sh
-
-La compilation des modules xsalome et xmed suit le standard SALOME. La
-bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
-cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
-la configuration de la procédure de reconstruction de xmed::
-
- $ export XSALOME_DIR=<xsalome_installdir>
-
-Aprés l'installation de xmed, il est possible de générer
-automatiquement une application SALOME prête à l'emploi pour la
-manipulation de champs::
-
- $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
-
-Cette commande génére un répertoire ``appli`` à l'emplacement où elle
-est exécutée. Il reste à lancer l'application SALOME au moyen de la
-commande::
-
- $ ./appli/runAppli -k
import salome
salome.salome_init()
import SALOME_MED
-
+
medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
medOp = medObj.createMedOperator()
-
+
f1 = medObj.getField("testfield1",-1,-1)
f2 = medObj.getField("testfield2",-1,-1)
-
+
somme = medOp.add(f1,f2)
Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à
salome.salome_init()
import SALOME_MED
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
+ medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
from xmed import fieldproxy
.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
++---------------+---------------+
L'image de gauche montre la sélection du pas de temps, l'image de
droite la boîte de dialogue qui permet la saisie de l'alias avec
// We suppose here that we have a CORBA object reference (object of
// type *_ptr or *_var), for example a SALOME_MED::MED object.
- SALOME_MED::MED_ptr medObj = ... // anything to get this object
+ SALOME_MED::MED_ptr medObj = ... // anything to get this object
// Get the IOR of this object
QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
QStringList commands;
commands+="import salome";
commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR);
-
+
QStringListIterator it(commands);
while (it.hasNext()) {
pyConsole->exec(it.next());
from xmed.fieldproxy import getFieldFromMed
from xmed.medproxy import getMedProxy
-
+
med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100")
-
+
f1=getFieldFromMed(med,"testfield1",-1,-1)
Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA
.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
++---------------+---------------+
Cette fonction répond au besoin de contrôle interactif des résultats
produits par les opérations de manipulation de champs.
(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
.. code-block:: python
-
+
import salome
import VISU
et fournit des fonctions de test unitaire (à exécuter ou pour s'en
inspirer). Après avoir lancé SALOME via une application virtuelle,
on peut taper::
-
+
$ <APPLI_ROOT>/runSession
[NS=venus:2810] $ python -i test_medoperation.py
- >>>
-
+ >>>
+
- Ceci permet de tester en particulier l'interface ``MedOp`` et son
utilisation dans le module python ``fieldproxy.py``.
:keywords: maillage, champ, MED, MEDMEM
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Note de travail concernant l'utilisation de MEDMEM
l'exemple):
.. code-block:: cpp
-
+
MED *myMed = new MED;
MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
driverIn->open();
permettre la mise à jour du support:
.. code-block:: cpp
-
+
MESH * mesh = myMed->getMesh(field);
mesh->read();
myMed->updateSupport();
Pour enfin charger les valeurs des composantes du champ:
.. code-block:: cpp
-
+
field->read();
La numérotation des éléments de maillage
``MedDataManager`` dans l'interface:
.. code-block:: cpp
-
+
#include "MEDMEM_MedDataManager.hxx"
class MedDataManager
public:
~MedDataManager();
void printFieldDouble(FIELD<double,FullInterlace> * field);
-
+
%extend {
MedDataManager(char * fileName)
{
- return new MedDataManager(string(fileName));
+ return new MedDataManager(string(fileName));
}
MedDataManager(MED * med)
{
return new MedDataManager(med);
}
-
+
%newobject getFieldDouble(const char * fieldName, const int dt, const int it);
FIELD<double, FullInterlace> * getFieldDouble(const char * fieldName, const int dt, const int it)
{
- return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
+ return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
}
}
-
+
};
d'amorce systématique:
.. code-block:: python
-
+
import salome
salome.salome_init()
-
+
import SALOME_MED
from libSALOME_Swig import *
On peut charger le composant SALOME MED:
.. code-block:: python
-
+
medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
grâce auquel les services de chargement de la structure MED peuvent
structure MED dans l'étude salome passée en argument:
.. code-block:: python
-
+
filePathName = "myfile.med"
medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude:
.. code-block:: python
-
+
filePathName = "myfile.med"
medObj = medComp.readStructFile(filePathName,salome.myStudyName)
fieldIdx = 1 # WRN maybe there is no field of idx=1
iterationIdx = 0
fieldName = medObj.getFieldNames()[fieldIdx]
- dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
+ dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
it = dtitfield[0]
dt = dtitfield[1]
fieldObj = medObj.getField(fieldName,it,dt)
nbOfFields = medObj.getNumberOfFields()
fieldNames = medObj.getFieldNames()
-
+
mesh = fieldObj.getSupport().getMesh()
.. note::
les exemples précédents):
.. code-block:: python
-
+
# Load the med structure using MED
medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
filePathName = "myfile.med"
medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
+
# Get the VISU component
import VISU
visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
visuComp.SetCurrentStudy(salome.myStudy)
-
+
# Get the sobject associated to the med object named "Med"
aSObject = salome.myStudy.FindObject("Med")
isPresent, medSObj = aSObject.FindSubObject(1)
-
- # Finally, import the med sobject in VISU
+
+ # Finally, import the med sobject in VISU
result = visuComp.ImportMed(medSObj)
Il est possible de d'aller plus loin et par exemple de déclencher
Questions:
-* Comment obtenir le nom du fichier med à partir d'une structure med?
+* Comment obtenir le nom du fichier med à partir d'une structure med?
* Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de
la donnée de l'objet CORBA SALOME_MED::MED?
.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
++---------------+---------------+
| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
++---------------+---------------+
La solution technique est construite sur les principes suivants:
+++ /dev/null
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Références documentaires
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. include:: medop-definitions.rst
-
-Documents de référence:
-
-* |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
-* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
-* |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
-
-Présentations:
-
-* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
-* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
-* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
-* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
-
- - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
- - |REF_EDF_JUS2011_OGV1|_
- - |REF_EDF_JUS2011_OGV3|_
- - |REF_EDF_JUS2011_OGV4|_
-
-Notes de travail:
-
-* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
-* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med
- :author: Guillaume Boulant
-
-.. include:: medop-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>`, 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:
-
-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.
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, guide utilisateur
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide d'utilisation de l'interface graphique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Ce document est un guide rapide pour l'utilisation de l'interface
-graphique du module MED. Il montre comment utiliser le module sur la
-base de quelques exemples de référence, inspirés des cas d'utilisation
-identifiés lors de l'analyse des besoins en matière de manipulation de
-champs.
-
-.. warning:: Le document est autonome, mais il est vivement conseillé
- de parcourir au préalable (ou en parallèle) :doc:`le document de
- spécifications<medop-specifications>`, au moins pour fixer les
- concepts et la terminologie.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation générale du module MED
-===================================
-
-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.
-
-Pour cela, le module propose deux espaces utilisateurs qui sont
-symbolisés par les rectangles rouges et vert sur la capture d'écran
-ci-dessous:
-
-* **l'espace des données** (*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 permet l'exploration des maillages et des champs fournis par
- les différentes sources de données.
-* **l'espace de travail** (*workspace*), dans lequel l'utilisateur
- peut déposer des champs sélectionnées dans l'espace source, pour
- ensuite les travailler par exemple pour produire des nouveaux champs
- au moyen des fonctions de manipulation fournies par l'interface
- textuelle (console python TUI).
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-L'utilisation type des fonctions de manipulation de champs suit un
-processus de la forme suivante:
-
-1. Chargement d'un fichier med dans l'espace de données (dataspace) et
- exploration du contenu, composé de maillages et de champs définis
- sur ces maillages et pouvant contenir un ou plusieurs pas de temps.
-2. Sélection (graphique) des champs à manipuler dans l'espace de
- travail (workspace), 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" sur 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
-
-
-Tour rapide des fonctions du module MED
-=======================================
-
-Cette section présente des exemples d'utilisation du module XMED sous
-la forme de "storyboard", et illustre au passage les fonctions mises à
-disposition par le module.
-
-.. warning:: Cette section est en travaux. Tant que cet avis n'aura
- pas disparu, veuillez en considérer le plan et le contenu encore
- incomplets, temporaires et sujets à caution.
-
-Exemple 1: Explorer des sources de données
-------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * ajouter une source de données
- * fonctions "Extends field series", "Visualize"
-
-.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
- :height: 16px
-
-.. |ICO_XMED| image:: images/ico_xmed.png
- :height: 16px
-
-.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
- :height: 16px
-
-.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
- :height: 16px
-
-Au démarrage, le module de manipulation de champs, identifié par
-l'icône |ICO_XMED|, présente une interface vierge:
-
-.. image:: images/xmed-gui-start.png
- :align: center
- :width: 800px
-
-La première étape consiste à ajouter une ou plusieurs source de
-données med dans le "dataspace". Pour cela, on clique sur l'icône "Add
-datasource" |ICO_DATASOURCE_ADD| qui propose de sélectionner un
-fichier med:
-
-.. image:: images/xmed-gui-datasource-selectfile.png
- :align: center
- :width: 800px
-
-L'opération ajoute une nouvelle entrée (datasource) dans l'espace de
-données (dataspace). Le contenu peut être exploré en parcourant
-l'arborescence. La figure ci-dessous (image de gauche) montre le
-résultat du chargement du fichier ``timeseries.med`` contenant un
-maillage de nom ``Grid_80x80`` sur lequel est défini un champ au noeud
-de nom ``Pulse``. Par défaut, la composition du champs (en terme de
-pas de temps et de composantes) n'est pas affichée pour éviter
-l'encombrement visuel de l'arbre. On doit faire la demande explicite
-au moyen de la commande "Expand field timeseries"
-|ICO_DATASOURCE_EXPAND| disponible dans le menu contextuel associé aux
-champs. Le résultat est affiché sur l'image centrale. La liste des
-itérations du champ ``Pulse`` peut être consultée.
-
-.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
- :height: 340px
-
-+--------------------------+--------------------------+--------------------------+
-| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
-+--------------------------+--------------------------+--------------------------+
-
-.. note:: En toute rigueur, le concept de *champ* dans le modèle MED
- désigne une itération donnée. Un ensemble d'itérations est désigné
- par le terme *série temporelle de champs*. Par abus de langage, et
- s'il n'y a pas ambiguité, on utilisera le nom du champ pour
- désigner à la fois le champs proprement dit ou la série temporelle
- à laquelle il appartient.
-
-Enfin, il est possible au niveau du dataspace de visualiser la forme
-générale du champ au moyen d'une carte scalaire affichée dans le
-viewer de SALOME. Pour cela, on sélectionne le pas de temps à
-visualiser et on utilise la commande "Visualize" |ICO_DATASOURCE_VIEW|
-disponible dans le menu contextuel associé:
-
-.. image:: images/xmed-gui-datasource-visualize-zoom.png
- :align: center
- :width: 800px
-
-.. note:: Cette représentation graphique a pour objectif le contrôle
- visuel rapide. Aussi, les fonctions du module VISU sont employées
- par défaut, mais il est possible de faire l'affichage des cartes
- scalaires au moyen du module PARAVIS (choix de préférence non
- implémenté pour le moment, mais techniquement réalisable).
-
-Exemple 2: Rassembler des champs issus de différentes sources
--------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * fonction "Use in workspace"
- * fonction "Save"
-
-.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
- :height: 16px
-.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
- :height: 16px
-
-L'objectif est de récupérer des données issues de différents fichiers
-med, puis de les rassembler dans un même fichier en sortie.
-
-On commence par ajouter les sources de données med dans l'espace de
-données (dataspace). Dans l'exemple ci-dessous, l'espace de données
-contient deux sources de nom ``parametric_01.med`` et
-``smallmesh_varfiled.med``. La première source contient le maillage
-``Grid_80x80_01`` sur lequel est défini le champ ``StiffExp_01``. La
-deuxième source contient le maillage ``My2DMesh`` sur lequel sont
-définis deux champs de noms respectifs ``testfield1`` et
-``testfield2``:
-
-.. image:: images/xmed-userguide-example2-datasource.png
- :align: center
- :width: 800px
-
-Pour l'exemple, on souhaite rassembler les champs ``StiffExp_01`` et
-``testfield2`` dans un fichier de nom ``result.med``. La procédure
-consiste à importer les deux champs dans l'espace de travail
-(workspace), puis à sauvegarder l'espace de travail. Pour cela, on
-sélectionne les champs et on utilise la commande "Use in workspace"
-|ICO_DATASOURCE_USE| disponible dans le menu contextuel. Les deux
-champs sélectionnés apparaissent dans l'arborescence de l'espace de
-travail:
-
-.. image:: images/xmed-userguide-example2-workspace.png
- :align: center
- :width: 800px
-
-La sauvegarde de l'espace de travail est faite au moyen de la commande
-"Save workspace" |ICO_WORKSPACE_SAVE| disponible dans la barre
-d'outils du module. Une fenêtre de dialogue invite l'utilisateur à
-spécifier le nom du fichier de sauvegarde:
-
-.. image:: images/xmed-userguide-example2-workspace-save.png
- :align: center
- :width: 800px
-
-Ce fichier ``result.med`` peut ensuite être rechargé dans le module
-XMED (ou les modules VISU ou PARAVIS) pour vérifier la présence des
-champs sauvegardés.
-
-.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
-.. (invalid mesh on field)
-
-.. _xmed.userguide.exemple3:
-
-Exemple 3: Appliquer une opération mathématique sur des champs
---------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * exécution d'opérations mathématiques dans la console TUI
- * fonction "put" pour référencer un champ de travail dans la liste
- des champs persistant.
- * fonction "Visualize" depuis le TUI.
-
-L'usage le plus courant du module de manipulation de champs est
-d'exécuter des opérations mathématiques dont les opérandes sont des
-champs ou des composantes de ces champs.
-
-On se place dans une situation où les sources de données sont définies
-dans le "dataspace" (dans l'exemple ci-après, une série temporelle de
-nom ``Pulse``, contenant 10 pas de temps, définis sur un maillage de
-nom ``Grid_80x80``, le tout issu du datasource ``timeseries.med``).
-
-Comme vu précedemment, pour manoeuvrer un champ dans l'espace de
-travail, on sélectionne ce champ, puis on exécute la commande "Use in
-workspace" |ICO_DATASOURCE_USE| du menu contextuel. Dans le cas
-présent, un seul champ est sélectionné (contre deux dans l'exemple
-précédent) et la commande ouvre alors une fenêtre de dialogue qui
-permet de préciser les données sur lesquelles on souhaite
-effectivement travailler et comment on veut les manoeuvrer:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
- :align: center
- :width: 800px
-
-.. note:: En l'état actuel du développement, l'interface propose
- uniquement de définir le nom de la variable sous laquelle doit être
- manoeuvré le champ dans la console de travail (TUI). Dans une
- version ultérieure, il est prévue de pouvoir préciser la ou les
- composante du champs à utiliser et un groupe de maille pour définir
- une restriction géométrique. Inversement, il sera également
- possible de choisir une série temporelle complète pour faire des
- opérations globales sur l'ensemble des pas de temps.
-
-Aprés validation, le champ est placé dans l'arborescence du
-"workspace" et une variable de nom ``<alias>`` est créée
-automatiquement dans la console de travail pour désigner le
-champ. Dans cet exemple, ``<alias>`` vaut ``f3``, positionné ainsi par
-l'utilisateur pour rappeler que la variable correspond au pas de temps
-n°3:
-
-.. image:: images/xmed-gui-workspace.png
- :align: center
- :width: 800px
-
-La manipulation peut commencer. Dans l'exemple ci-dessous, on crée le
-champ ``r`` comme le résultat d'une transformation afine du champ
-``f3`` (multiplication du champ par le facteur 2.7 auquel on ajoute
-l'offset 5.2)::
-
- >>> r=2.7*f3+5.2
-
-On peut poursuivre la manipulation du champs avec une variété
-d'opérations qui sont détaillées dans les spécifications du module
-(cf. :ref:`Spécification des opérations<xmed-specifications>`):
-
- >>> r=f3/1000 # les valeurs de r sont celles du champ f3 réduites d'un facteur 1000
- >>> r=1/f3 # les valeurs de r sont les inverses des valeurs de f3
- >>> r=f3*f3 # les valeurs de r sont celles du champ f3 élevées au carré
- >>> r=pow(f3,2) # même résultat
- >>> r=abs(f3) # valeur absolue du champ f3
- >>> ...
-
-Les opérations peuvent utiliser plusieurs opérandes de type champs. Si
-``f4`` désigne le pas de temps n°4 du champ ``Pulse``, alors on peut
-calculer toute combinaison algébrique des deux champs::
-
- >>> r=f3+f4
- >>> r=f3-f4
- >>> r=f3/f4
- >>> r=f3*f4
-
-Avec au besoin l'utilisation de variables scalaires::
-
- >>> r=4*f3-f4/1000
- >>> ...
-
-Dans ces exemples, la variable ``r`` désigne un champ de travail qui
-contient le résultat de l'opération. Par défaut, ce champ de travail
-n'est pas référencé dans l'arborescence du workspace. Si on souhaite
-tout de même le référencer, par exemple pour qu'il soit pris en compte
-dans la sauvegarde, alors on tape la commande::
-
- >>> put(r)
-
-La fonction ``put`` a pour but de marquer le champ en argument comme
-persistent, puis de le ranger dans l'arborescence du "workspace" afin
-qu'il soit visible et sélectionnable. En effet, parmi tous les champs
-qui pourront être créés dans la console pendant la session de travail,
-tous n'ont pas besoin d'être sauvegardés. Certains sont même des
-variables temporaires qui servent à la construction des champs
-résultats finaux. C'est pourquoi, seuls les champs rangés dans
-l'arborescence du workspace sont enregistrés lors de la demande de
-sauvegarde du workspace.
-
-Les variables définies dans la console ont d'autres utilités. Tout
-d'abord, elles permettent d'imprimer les informations concernant le
-champ manoeuvré. Pour cela, on tape simplement le nom de la variable
-puis retour::
-
- >>> f3
- field name (id) = Pulse (3)
- mesh name (id) = Grid_80x80 (0)
- discretization = ON_NODES
- (iter, order) = (3,-1)
- data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
-
-Elle peut également être utilisée comme argument des commandes de
-gestion disponibles dans l'interface textuelle (dont la liste
-détaillée est décrite à la section :ref:`Documentation de l'interface
-textuelle<xmed.userguide.tui>`). Par exemple, la fonction ``view``
-permet d'afficher la carte scalaire du champ dans le viewer::
-
- >>> view(f3)
-
-Donne:
-
-.. image:: images/xmed-gui-workspace-view.png
- :align: center
- :width: 800px
-
-.. note:: On remarquera ici qu'il est facile de comparer deux pas de
- temps d'un champ, par exemple en calculant la différence ``f3-f4``,
- puis en affichant un aperçu de la carte scalaire résultat au moyen
- de la fonction ``view``::
-
- >>> view(f3-f4)
-
-On peut enfin tout simplement afficher les données du champs par la
-commande ``print``::
-
- >>> print f3
- Data content :
- Tuple #0 : -0.6
- Tuple #1 : -0.1
- Tuple #2 : 0.4
- Tuple #3 : -0.1
- Tuple #4 : 0.4
- ...
- Tuple #6556 : 3.5
- Tuple #6557 : 3.3
- Tuple #6558 : 1.5
- Tuple #6559 : 0.3
- Tuple #6560 : 0.2
-
-Il est important de noter que les opérations entre champs ne peuvent
-être faites qu'entre champs définis sur le même maillage. Il s'agit là
-d'une spécification du modèle MED qui interdit d'envisager les
-opérations entre champs définis sur des maillages géométriquement
-différents. Techniquement, cela se traduit par l'obligation pour les
-objets informatique *champs* de partager le même objet informatique
-*maillage*.
-
-Dans l'hypothèse où on souhaite utiliser des champs définis sur des
-maillages différents, par exemple pour manoeuvrer les valeurs des
-champs à l'interface de deux maillages partageant une zone géométrique
-2D, il faut d'abord ramener tous les champs sur le même maillage de
-surface par une opération de projection.
-
-.. note:: Même si ceci est techniquement possible avec la bibliothèque
- MEDCoupling, cet type d'opération de projection n'est pas encore
- disponible dans le module de manipulation de champs (prévu en
- 2012).
-
-Un autre besoin plus classique est l'utilisation de champs définis sur
-des maillages géométriquement identiques, mais techniquement
-différents, par exemple lorsqu'ils sont chargés de fichiers med
-différents. Pour traiter ce cas de figure, la bibliothèque MEDCoupling
-prévoit une fonction de "Changement du maillage support", dont
-l'utilisation au niveau du module de manipulation de champs est
-illustrée dans :ref:`l'exemple 4<xmed.userguide.exemple4>` ci-après.
-
-.. _xmed.userguide.exemple4:
-
-Exemple 4: Comparer des champs issues de différentes sources
-------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Changement du maillage support "change underlying mesh"
-
-On se place ici dans le cas de figure où des champs ont été produits
-sur le même maillage, au sens géométrique, mais enregistrés dans des
-fichiers med différents. C'est le cas par exemple d'une étude
-paramétrique où plusieurs calculs sont effectués avec des variantes
-sur certains paramètres du modèle simulé, chaque calcul produisant un
-fichier med.
-
-Soit ``parametric_01.med`` et ``parametric_02.med`` deux fichiers med
-contenant les champs que l'on souhaite comparer, par exemple en
-calculant la différence des valeurs et en visualisant le résultat.
-
-Aprés le chargement des sources de données dans le module XMED,
-l'utilisateur se trouve en présence de deux maillages, au sens
-technique du terme cette fois-ci, c'est-à-dire que les champs sont
-associées à des objets informatiques maillage différents, bien que
-géométriquement identiques.
-
-Or, les fonctions de manipulation de champs ne permettent pas les
-opérations sur des champs dont les maillages supports sont différents
-(voir la remarque à la fin de :ref:`l'exemple
-3<xmed.userguide.exemple3>`).
-
-Pour résoudre ce cas de figure, le module de manipulation de champs
-met à disposition la fonction "Change underlying mesh" qui permet de
-remplacer le maillage support d'un champ par un autre à partir du
-moment où les deux maillages sont géométriquement identiques,
-c'est-à-dire que les noeuds ont les mêmes coordonnées spatiales.
-
-.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
- :height: 16px
-
-Dans l'exemple proposé, l'utilisateur sélectionne le premier pas de
-temps du champ ``StiffExp_01`` du "datasource" ``parametric_01.med``,
-puis l'importe dans l'espace de travail au moyen de la commande "Use
-in workspace" |ICO_DATASOURCE_USE|. Il sélectionne ensuite le premier
-pas de temps du champs ``StiffExp_02`` du "datasource"
-``parametric_02.med``, mais l'importe dans l'espace de travail au
-moyen de la commande "Change underlying mesh" |ICO_DATASOURCE_CHG|. La
-fenêtre de dialogue ci-dessous s'affiche et invite l'utilisateur à
-choisir le nouveau maillage support par sélection dans l'arborescence
-du "dataspace":
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
- :align: center
-
-Dans cet exemple, on sélectionne le maillage ``Grid_80x80_01`` support
-du champ ``StiffExp_01``, avec lequel on souhaite faire la
-comparaison. Après validation, l'arborescence du workspace contient le
-champ ``StiffExp_02`` défini sur le maillage ``Grid_80x80_01``:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
- :align: center
-
-.. note:: La fonction "Change underlying mesh" ne modifie pas le champ
- sélectionné dans le "dataspace" (principe de base de fonctionnement
- du dataspace), mais crée une copie du champ dans l'espace de travail
- pour ensuite remplacer le maillage support. D'où le nom par défaut
- pour le champ ``dup(<nom du champ sélectionné>)`` (dup pour
- "duplicate").
-
-Il reste à associer une variable à ce champ pour le manipuler dans la
-console. Ceci peut être fait au moyen de la commande "Use in console",
-disponible dans le menu contextuel du workspace.
-
-En définitif, si ``f1`` désigne le champ issu du datasource
-``parametric_01.med`` et ``f2`` le champ issu du datasource
-``parametric_02.med`` par la procédure décrite ci-dessus, alors la
-comparaison des deux grandeurs peut être faite comme pour le cas de
-:ref:`l'exemple 3<xmed.userguide.exemple3>`::
-
- >>> r=f1-f2
- >>> view(r)
-
-.. note:: En remarque générale sur cet exemple, il convient de noter
- les points suivants:
-
- * l'égalité géométrique de deux maillages est établie à une marge
- d'erreur prés qu'il est possible de définir techniquement, mais
- qui n'est pas ajustable au niveau de l'interface du module de
- manipulation de champs. Elle est fixée à une valeur standard qui
- permet de traiter la plupart des cas utilisateur. On verra à
- l'usage s'il est nécessaire de remonter ce paramètre au niveau de
- l'interface.
- * L'utilisateur doit faire la démande explicite de changer le
- maillage support d'un champ, en prévision de la comparaison de
- champs issus de datasource différentes. Il s'agit là d'un choix
- fonctionnel délibéré pour que l'utilisateur garde trace des
- modifications faites sur les données (pas de modification
- automatiques à l'insu de l'utilisateur, même sous prétexte
- d'amélioration de l'ergonomie).
-
-
-Exemple 5: Créer un champ sur un domaine spatial
-------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * initialisation par une fonction de la position spatiale
- * initialisation sur un groupe de maille
-
-Le domaine géométrique de définition du champs à créer est spécifié
-ici par la donnée d'un groupe de mailles. Ce cas d'usage est
-typiquement prévu pour produire les conditions de chargement initial
-d'une structure, par exemple en définissant un champ sur une surface
-de la géométrie, identifiée par un nom de groupe de mailles.
-
-.. warning:: DEVELOPPEMENT EN COURS
-
-Exemple 6: Extraire une partie d'un champ
------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * extraire une composante (ou un sous-ensemble des composantes)
- * extraire un domaine géométrique (valeurs sur un groupe de maille)
- * extraire un ou plusieurs pas de temps.
-
-.. warning:: DEVELOPPEMENT EN COURS
-
- On doit illustrer ici les fonctions de restriction, qui
- permettraient de récupérer certaines composantes uniquement. Le
- principe est qu'on crée un nouveau champ qui est une restriction du
- champ argument à une liste de composantes à spécifier (utiliser la
- fonction __call__ des fieldproxy).
-
-Pour l'extraction des pas de temps, on peut se ramener au cas de
-l'exemple 2 avec une seule source de donnée.
-
-Exemple 7: Créer un champ à partir d'une image to[mp]ographique
----------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Création d'un champ sans datasource (ni maillage, ni champs), à
- partir d'un fichier image
-
-En tomographie ou en topographie, les appareils de mesure produisent
-des images qui représentent une grandeur physique en niveaux de gris
-sur un plan de coupe donné. L'image ci-dessous représente par exemple
-une vue interne du corps humain faite par IRM:
-
-.. image:: images/xmed-irm.png
- :align: center
- :width: 600px
-
-Cette image est un ensemble de pixels organisés sur une grille
-cartesienne. Elle peut donc être modélisée sous la forme d'un champ
-scalaire dont les valeurs sont définies aux cellules d'un maillage
-réglés de même taille que l'image (en nombre de pixels):
-
-.. image:: images/xmed-irm-field.png
- :align: center
- :width: 600px
-
-Le module de manipulation de champ fournit un utilitaire appelé
-``image2med.py`` qui permet d'appliquer ce principe à la conversion
-d'un fichier image en fichier med contenant la représentation de
-l'image sous forme d'un champ scalaire (seul le niveau de gris est
-conservé)::
-
- $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
-
-.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
- :height: 16px
-
-Cette opération de conversion peut être faite automatiquement dans
-l'interface graphique du module au moyen de la commande "Add Image
-Source" |ICO_IMAGESOURCE| disponible dans la barre d'outils. Cette
-commande ouvre la fenêtre suivante pour inviter l'utilisateur à
-choisir un fichier image:
-
-.. image:: images/medop_image2med_dialog.png
- :align: center
-
-Le nom du fichier med résultat est proposé par défaut (changement de
-l'extention en ``*.med``) mais il peut être modifié. Enfin, on peut
-demander le chargement automatique du fichier med produit pour ajout
-dans l'espace de donnée. Les champs peuvent alors être manipulés comme
-dans les cas d'utilisation standard.
-
-Par exemple, l'image ci-dessous affiche le résultat de la différence
-entre deux images, ajoutée à l'image de référence: si i1 et i2
-désignent les champs créés à partir des deux images, on représente ``r
-= i1 + 5*(i2-i1)`` où le facteur 5 est arbitraire et sert à amplifier
-la zone d'intérêt (en haut de l'oeil gauche):
-
-.. image:: images/xmed-irm-diff.png
- :align: center
- :width: 600px
-
-L'exemple ci-dessous est le résultat du chargement d'une image
-tomographique issue du projet MAP (Charles Toulemonde,
-EDF/R&D/MMC). L'image tomographique:
-
-.. image:: images/champ_altitude_MAP.png
- :align: center
- :width: 600px
-
-Le résultat du chargement:
-
-.. image:: images/medop_image2med_tomographie.png
- :align: center
- :width: 800px
-
-Exemple 8: Continuer l'analyse dans PARAVIS
--------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Export de champs vers le module PARAVIS.
-
-Les possibilités de représentation graphique des champs fournies par
-le module MED ont pour seul objectif le contrôle visuel rapide. Par
-défaut, le viewer de VISU est employé.
-
-Pour une analyse plus détaillées des champs, il est nécessaire de
-poursuivre le travail dans PARAVIS. Le module de manipulation de
-champs offre une fonction qui simplifie ce passage, en faisant le
-chargement automatique dans PARAVIS et en proposant une visualisation
-par défaut (carte de champs scalaire).
-
-Pour cela, il faut sélectionner dans l'espace de travail les champs à
-exporter, puis déclencher la fonction d'export depuis le menu
-contextuel associé:
-
-.. image:: images/medop_exportparavis.png
- :align: center
-
-Les champs sélectionnés sont regroupés dans une entrée MED du
-navigateur PARAVIS, et le premier champ est affiché sous forme de
-carte de champ:
-
-.. image:: images/medop_exportparavis_result.png
- :align: center
- :width: 800px
-
-.. note:: La fonction d'export est une fonction de confort. La même
- opération peut être faite manuellement en procédant d'abord à
- l'enregistrement des champs sous forme de fichier MED, puis en
- chargeant le fichier généré dans le module PARAVIS pour
- visualisation.
-
-.. _xmed.userguide.tui:
-
-Utilisation de l'interface textuelle du module MED (TUI)
-========================================================
-
-Toutes les opérations menées au moyen de l'interface graphique peuvent
-être réalisées (avec plus ou moins de facilité) avec l'interface
-textuelle. Le module de manipulation de champs peut même être utilisé
-exclusivement en mode texte. Pour cela, on lance la commande::
-
- $ <path/to/appli>/medop.sh
-
-Cette commande ouvre une console de commandes ``medop>``. Un fichier
-med peut être chargé et travaillé, par exemple pour créer des champs à
-partir des données du fichier.
-
-Que l'on soit en mode texte pur ou en mode graphique, un séquence de
-travail type dans la console peut ressembler au jeu d'instructions
-suivantes::
-
- >>> load("/path/to/mydata.med")
- >>> la
- id=0 name = testfield1
- id=1 name = testfield2
- >>> f1=get(0)
- >>> f2=get(1)
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- >>> r=f1+f2
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=testfield1+testfield2)
- >>> r.update(name="toto")
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=toto)
- >>> put(r)
- >>> save("result.med")
-
-Les commandes principales sont:
-
-* ``load``: charge un fichier med dans la base de données (utile
- uniquement en mode texte pur)::
-
- >>> load("/path/to/datafile.med")
-
-* ``la``: affiche la liste de tous les champs chargés en base de données ("list all")
-* ``get``: définit un champ dans l'espace de travail à partir de son
- identifiant (utile plutôt en mode texte pur car l'interface
- graphique permet de faire cette opération par sélection d'un champ
- dans le dataspace)::
-
- >>> f=get(fieldId)
-
-* ``ls``: affiche la liste des champs présent dans l'espace de travail ("list")
-* ``put``: met un champ en référence dans l'*espace de gestion*::
-
- >>> put(f)
-
-* ``save``: sauvegarde tous les champs référencés dans l'espace de
- gestion dans un fichier med::
-
- >>> save("/path/to/resultfile.med")
-
-.. note:: On peut faire à ce stade plusieurs remarques:
-
- * la commande ``load`` charge uniquement les méta-informations
- décrivant les maillage et les champs (noms, type de
- discrétisation, liste des pas de temps). Les maillages et les
- valeurs physiques des champs sont chargées ultérieurement (et
- automatiquement) dés lors qu'elles sont requises par une
- opération. Dans tous les cas, les données med (méta-informations
- et valeurs) sont physiquement stockées au niveau de l'espace
- *base de données*.
- * la commande ``get`` définit en réalité un *manipulateur de champ*
- dans l'espace de travail, c'est-à-dire une variable qui fait la
- liaison avec le champ physique hébergé dans la base de
- données. Les données physiques ne circulent jamais entre les
- espaces, mais restent centralisées au niveau de la base de
- données.
-
-Les commandes TUI suivantes nécessitent de travailler dans
-l'environnement graphique:
-
-* ``visu``: afficher une carte de champ pour contrôle visuel rapide
- (pas de paramettrage possible)
-
- >>> view(f)
-
-
:keywords: maillage, champ, manipulation
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ANNEXE: Note de travail concernant le chantier XMED 2011
-------------------------------------
Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
+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
est posé dans le WS. On peut donc proposer en option de lui associer
un alias pour manipulation dans la console
-
-
+
+
:keywords: maillage, champ, manipulation
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ANNEXE: Note de travail concernant le chantier XMED 2012
* Eliminer la dépendance à XSALOME
* Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine
-.. warning:: TODO: refaire le point sur les tâches initiées en 2011
+.. warning:: TODO: refaire le point sur les tâches initiées en 2011
.. toctree::
:maxdepth: 1
- medop-userguide-gui.rst
- medop-userguide-api.rst
+ medcalc-userguide-gui.rst
+ medcalc-userguide-api.rst
**Technical documentation** (**in french**):
.. toctree::
:maxdepth: 1
- medop-specifications.rst
- medop-develguide.rst
+ medcalc-specifications.rst
+ medcalc-develguide.rst
**Additional documentation**
.. toctree::
:maxdepth: 1
- medop-references.rst
+ medcalc-references.rst
Document archive (in french)
============================
--- /dev/null
+.. AVERTISSEMENT:
+.. Ce fichier contient les définitions globales à la documentation. Il
+.. peut être inclu au moyen de la directive rst "include" pour
+.. disposer des définitions dans le fichier qui fait l'inclusion.
+.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
+.. il est interdit de faire afficher du texte par ce document de
+.. définition.
+
+.. REFERENCES DOCUMENTAIRES:
+.. (les documents sont fournis dans le répertoire _static/documents)
+
+.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
+.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
+.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
+
+.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
+.. |REF_CEA_VBE_MEDMEM| replace:: MEDMEM user's guide
+.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
+.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
+.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
+.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
+.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
+.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
+.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
+.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
+.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
+.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
+.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
+
+.. PRESENTATIONS:
+
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
+.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
+.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
+
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
+.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
+.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
+.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
+.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
+.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
+.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
+.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
+
+
+
+.. LIENS EXTERNES:
+.. (l'accès nécessite le réseau intranet EDF et internet)
+
+.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
+.. |LINK_EDF_MEDDOC| replace:: Modèle MED
+.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
+
+.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
+.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
+.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
+
+.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
+.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
+.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
+
+.. RENVOIES:
+
+.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
+.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
+
+
+.. SNAPSHOTS:
+
+.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
+.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
+
+.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
+.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
+
+.. |XMED_USERGUIDE_PDF| replace:: version pdf
+.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
+
+
+.. =========================================================
+.. Rendering roles
+.. =========================================================
+.. This role can be used to display monospace text (code)
+.. role:: tt
+ :class: tt
+
+.. role:: strike
+ :class: strike
+
+.. role:: bolditalic
+ :class: bolditalic
+
+.. role:: underline
+ :class: underline
+
+.. role:: tag
+ :class: tag
+
+.. role:: tagb
+ :class: tagb
+
+.. role:: todo
+ :class: todo
+
+.. role:: date
+ :class: date
+
+.. role:: warn
+ :class: warn
+
+.. role:: info
+ :class: info
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation, med, développement
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Module MED: Guide de développement du composant MEDCalc
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le composant logiciel MEDCalc est un élément du module MED. Il fournit
+une interface utilisateur pour la manipulation de maillages et de
+champs, composée d'une interface texte (TUI) et d'une interface
+graphique (GUI). L'interface graphique constitue l'interface graphique
+du module MED.
+
+Ce document est la documentation technique du composant MEDCalc. Il
+fournit les instructions à suivre pour installer le composant en vue
+d'un travail de développement, puis décrit les éléments de conception.
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Mise en place de l'espace de développement
+==========================================
+
+Gestion de configuration du composant MEDCalc
+-------------------------------------------
+
+Le composant logiciel MEDCalc est un package du module SALOME MED,
+hébergé dans l'espace source au niveau du sous-répertoire
+`src/MEDCalc`. La gestion des fichiers sources est donc intégrée dans le
+module SALOME MED.
+
+Organisation des sources du composant MEDCalc
+-------------------------------------------
+
+Le répertoire source `src/MEDCalc` distingue les sous-répertoires
+suivants:
+
+* cmp: package containing the SALOME components
+* tui: package containing the python user interface
+* gui: package containing the graphical user interface (the GUI part
+ of the MED module)
+* res: resources files associated to the MEDCalc package (icons, config
+ files, data files, ...)
+* exe: additional executable programs that can be launched from the
+ MEDCalc framework
+
+Construction du composant MEDCalc
+-------------------------------
+
+Intégré à la construction du module MED. Le composant MEDCalc dépend de
+MEDCoupling et MEDLoader uniquement.
+
+Exécution des tests unitaires du composant MEDCalc
+------------------------------------------------
+
+Les tests unitaires peuvent être exécutés au moyen de scripts python
+lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
+
+ $ ./appli/runSession
+ [NS=mars:2810]$ python appli/bin/salome/med/test_medcalc_components.py
+
+L'exécution imprime un rapport détaillant le résultat pour chaque
+fonction de test::
+
+ test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
+ test_Calculator_basics (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
+ test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
+ test_loadDatasource (__main__.MyTestSuite) ... ok
+ test_getDataManager (__main__.MyTestSuite) ... ok
+ test_getFieldHandlerList (__main__.MyTestSuite) ... ok
+ test_getFieldRepresentation (__main__.MyTestSuite) ... ok
+ test_markAsPersistent (__main__.MyTestSuite) ... ok
+ test_saveFields (__main__.MyTestSuite) ... ok
+ test_updateFieldMetadata (__main__.MyTestSuite) ... ok
+
+Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
+
+* ``test_medcalc_components.py``: test les composants SALOME développés pour
+ la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
+* ``test_xmed_fieldOperations.py``: test des operations de champs telles
+ qu'elles sont mises en oeuvre depuis l'interface textuelle.
+* ``test_xmed_uiEventListener.py``: test du système de notification
+ d'évènements des composants vers la partie gui du module MED.
+* ``test_xmed_visualisation.py``: test du système de visualisation
+ des champs tel que piloté depuis le module MED.
+
+Architecture du module XMED
+===========================
+
+Le module MED pour la manipulation de champs est composé de:
+
+* une bibliothèque de fonctions pour le traitement de données sur des
+ maillages et des champs conformes au modèle MED (package
+ MEDCoupling, MEDLoader et REMAPPER);
+* une interface graphique pour la mise en oeuvre des cas standard de
+ manipulation de champs;
+* une ensemble d'outils pour intervenir sur des fichiers au format
+ MED.
+
+Une bibliothèque de fonctions pour le traitement de données
+-----------------------------------------------------------
+
+La figure ci-dessous montre la structure des paquets logiciels qui
+constituent la bibliothèque:
+
+.. image:: images/medlayers.png
+ :align: center
+
+Elle comprend en particulier les paquets suivants:
+
+* MEDCoupling: qui décrit les structures de données pour porter les
+ maillages et les champs
+* MEDLoader: qui fournit les fonctions de persistence sous forme de
+ fichiers au format MED (lecture et écriture).
+* REMAPPER:
+
+Il est important de noter que MEDCoupling n'a aucune dépendance
+logicielle autre que la bibliothèque C++ standard. Ceci permet
+d'envisager son implantation dans un code de calcul ou un outil de
+traitement sans tirer l'ensemble pré-requis de SALOME.
+
+Une interface graphique pour l'exécution des cas standard
+---------------------------------------------------------
+
+
+Un ensemble d'outils pour le traitement de fichiers
+---------------------------------------------------
+
+
+Description des composants
+==========================
+
+MEDDataManager - Le gestionnaire des données de session
+-------------------------------------------------------
+
+Le composant MEDDataManager s'occupe de fournir les données MED sur
+demande des interfaces clientes, en particulier pour module de
+pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
+en général elle proviennent d'un fichier au format med contenant des
+champs définis sur des maillages. Les données sont identifiées à la
+lecture des métadonnées de description dans le fichiers med, puis les
+valeurs des champs et les maillages support sont chargés au besoin.
+
+Le chargement des métadonnées de description se fait par la méthode::
+
+ loadDatasource(const char \*filepath)
+
+
+
+Eléments d'implémentation
+=========================
+
+Ecrire un service CORBA qui retourne une sequence de FieldHandler:
+
+.. code-block:: cpp
+
+ MEDCALC::FieldHandlerList * MyFunction(...) {
+ vector<MEDCALC::FieldHandler*> fieldHandlerList;
+ ...
+
+ fieldHandlerList.push_back(fieldHandler);
+
+ // Map the resulting list to a CORBA sequence for return:
+ MEDCALC::FieldHandlerList_var fieldHandlerSeq = new MEDCALC::FieldHandlerList();
+ int nbFieldHandler = fieldHandlerList.size();
+ fieldHandlerSeq->length(nbFieldHandler);
+ for (int i=0; i<nbFieldHandler; i++) {
+ fieldHandlerSeq[i] = *fieldHandlerList[i];
+ }
+ return fieldHandlerSeq._retn();
+ }
+
+Ecrire un service CORBA qui retourne une structure CORBA:
+
+.. code-block:: cpp
+
+ MEDCALC::FieldHandler * fieldHandler = new ...
+ _fieldHandlerMap[fieldHandler->id] = fieldHandler;
+
+ // >>> WARNING: CORBA struct specification indicates that the
+ // assignement acts as a desctructor for the structure that is
+ // pointed to. The values of the fields are copy first in the new
+ // structure that receives the assignement and finally the initial
+ // structure is destroyed. In the present case, WE WANT to keep
+ // the initial fieldHandler in the map. We must then make a deep
+ // copy of the structure found in the map and return the copy. The
+ // CORBA struct specification indicates that a deep copy can be
+ // done using the copy constructor. <<<
+ return new MEDCALC::FieldHandler(*fieldHandler);
+
+
+
+ANNEXE A: Bug en cours
+======================
+
+TO FIX:
+
+* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
+ 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
+ reference correcte vers le maillage).
+* le script de test test_medoperation.py plante si le module xmed n'a
+ pas été chargé avec des données chargées.
+
+ANNEXE B: Traçabilité avec le module XMED
+=========================================
+
+Le module SALOME de nom XMED est l'espace de développement initial du
+composant logiciel MEDCalc, intégré aujourd'hui au module MED. Cette
+annexe est la notice technique de ce module, qui reste disponible mais
+qui n'est plus maintenu.
+
+Gestion de configuration du module XMED
+---------------------------------------
+
+Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
+configuration dans une base git du projet NEPAL. Ils peuvent être
+récupérés au moyen de la commande::
+
+ $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
+
+Cette commande installe un répertoire ``xmed`` contenant l'ensemble
+des sources du module XMED.
+
+Le module XMED a pour pré-requis logiciel la plateforme SALOME:
+
+* SALOME version 6.1.3 (au moins) à télécharger à l'URL
+ http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
+* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
+* Installer la plate-forme choisie selon les instructions fournies.
+
+Le module XMED utilise également une bibliothèque interne au projet
+NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
+SALOME pour un usage de développement (XSALOME signifie eXtension
+SALOME). Les sources de cette bibliothèque doivent être récupérés au
+moyen de la commande::
+
+ $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
+
+Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
+des sources de la bibliothèque XSALOME.
+
+.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
+ simple bibliothèque de fonctions qui complète ou rend plus facile
+ d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
+ être intégrée à d'autres projets que les projets internes NEPAL ou
+ MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
+ héberge des développements destinés à être reversés dans la
+ plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
+ donc être garanti sur le long terme.
+
+Installation et lancement de l'application
+------------------------------------------
+
+L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
+disponible et que le shell de travail est étendu avec l'environnement
+de SALOME. En général, par des commandes de la forme::
+
+ $ . /where/is/salome/prerequis.sh
+ $ . /where/is/salome/envSalome.sh
+
+La compilation des modules xsalome et xmed suit le standard SALOME. La
+bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
+cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
+la configuration de la procédure de reconstruction de xmed::
+
+ $ export XSALOME_DIR=<xsalome_installdir>
+
+Aprés l'installation de xmed, il est possible de générer
+automatiquement une application SALOME prête à l'emploi pour la
+manipulation de champs::
+
+ $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
+
+Cette commande génére un répertoire ``appli`` à l'emplacement où elle
+est exécutée. Il reste à lancer l'application SALOME au moyen de la
+commande::
+
+ $ ./appli/runAppli -k
--- /dev/null
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Appendix: Documentation references
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. include:: medcalc-definitions.rst
+
+References:
+
+* (**in french**) |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
+* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
+* (**in french**) |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
+
+Slides (**in french**):
+
+* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
+* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
+* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
+* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
+
+ - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
+ - |REF_EDF_JUS2011_OGV1|_ (**video**)
+ - |REF_EDF_JUS2011_OGV3|_ (**video**)
+ - |REF_EDF_JUS2011_OGV4|_ (**video**)
+
+Working notes (**in french**):
+
+* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
+* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
--- /dev/null
+.. 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>`, 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:
+
+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.
+
+
--- /dev/null
+.. meta::
+ :description: introduction guide for users of the MEDMEM library
+ :keywords: mesh, field, med, MEDCoupling, MEDLoader
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+MEDMEM library: Starter guide for users
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+This document illustrates how to start with the programming interface
+of the MEDMEM library. The users is someone who intends to create a
+data processing script involving meshes and fields.
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+ :depth: 2
+
+General overview
+================
+
+Definition of the MEDMEM library
+--------------------------------
+
+The MEDMEM library is designed to manipulate meshes and fields that
+conform to the MED data model. This library can be used in C++
+programs as in python scripts for data processing on meshes and
+fields. The library contains the data structure to describe meshes and
+fields as C++ objects (MEDCoupling package). It provides a set of
+functions to manage the persistency toward the med file format
+(MEDLoader package), and to process the data througt interpolation and
+localization algorithms (INTERP_KERNEL and REMAPPER packages), for
+example to perform field projections from a mesh to another.
+
+Installation of the MEDMEM library
+----------------------------------
+
+The MEDMEM library is part of the SALOME MED module and then is
+installed together with this module by the installation process of
+SALOME. Nevertheless, it is possible for low-weight deployment to
+install only the MEDMEM library from the source files embedded in the
+SALOME MED module. Keep in mind that the MEDMEM library is designed to
+be a self-consistent library with very few third party softwares (only
+med-file, glibc and mpi typically). In particular, it is strictly
+independant from the SALOME framework even if it distributed with
+SALOME for convenience reasons.
+
+Components of the MEDMEM library
+--------------------------------
+
+The MEDMEM library consists in a small set of atomic libraries files,
+in particular:
+
+* :tt:`medcoupling`: this library provides the data structures (C++
+ classes) to describe meshes and fields.
+* :tt:`medloader`: this library provides I/O functions to the MED file
+ format
+* :tt:`interpkernel`: this library provides the mathematical
+ structures and algorithms required med data processing, in
+ particular interpolation and localization.
+* :tt:`medcouplingremapper`: this library provides the functions for
+ fields projections and interpolation.
+
+The figure below represents the layer structure of the packages of the
+library:
+
+.. image:: images/medlayers_70pc.png
+ :align: center
+
+What we call MEDMEM library in this document is represented by the
+orange packages on this diagram. The white packages reprensent the old
+deprecated MEDMEM library. The blue packages represent the aditionnal
+components for field manipulation througth the user interface (TUI and
+GUI).
+
+The MEDMEM library comes also with this set of atomic libraries for
+advanced users/programmers:
+
+* :tt:`medcouplingcorba`: this library is designed for cross process
+ exchange of medcoupling objects.
+* :tt:`medpartitioner`: this library provides functions to split a MED
+ domain in several part in the perspective of parallel computing
+
+All these atomic C++ libraries are wrapped into a set of python
+modules (using the swig binding technology) so that all the data
+processing can be realized by scripting.
+
+.. warning:: It could happen that some parts of the C++ libraries are
+ not wrapped into python modules. This coverture will be
+ extend on demand and if the integrity of the concepts is
+ preserved.
+
+Main concepts of the MEDMEM library
+===================================
+
+.. warning:: TODO avec Antony. Présenter les structure de données de
+ MEDCoupling principalement. Describe the MEDMEM data
+ model, the typical content of a med file, the types of
+ cell that compose the meshes, the types of spatial
+ discretization of fields, ...
+
+Basic usages of the MEDMEM library
+==================================
+
+This section illustrates the usage of main features of the MEDMEM
+library using python examples. The usage of python is just to have a
+light syntax that makes more easy the first understanding.
+
+.. note:: All code examples here after are parts of the tutorial use
+ cases located in the folder :tt:`src/MEDCalc/tut` in the MED
+ source directory. These use cases are all working executable
+ programs and they can be used to initiate your own script.
+
+Preparing the shell environment
+-------------------------------
+
+We make the hypothesis here that the MEDMEM library is installed using
+the SALOME procedure and then is located in the MED module
+installation directory. In addition to the MED library, the third
+party softwares required for executing the examples are: python, hdf5
+and med-fichier. Then, you should prepare your shell environment
+with a set of instructions that looks like::
+
+ #------ python ------
+ export PYTHONHOME=</path/to/python>
+ export PYTHONSTARTUP=${PYTHONHOME}/pythonrc.py
+ export PYTHON_INCLUDE=${PYTHONHOME}/include/python2.6
+ export PATH=${PYTHONHOME}/bin:${PATH}
+ export LD_LIBRARY_PATH=${PYTHONHOME}/lib:${LD_LIBRARY_PATH}
+
+ #------ hdf5 ------
+ HDF5HOME=</path/to/hdf5>
+ export PATH=${HDF5HOME}/bin:$PATH
+ export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH}
+ export HDF5_DISABLE_VERSION_CHECK=1
+
+ #------ med ------
+ MED2HOME=</path/to/med>
+ export PATH=${MED2HOME}/bin:${PATH}
+ export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH}
+
+ #------ medmem ---
+ MED_ROOT_DIR=<path/to/salome_med_module>
+ export LD_LIBRARY_PATH=${MED_ROOT_DIR}/lib/salome:${LD_LIBRARY_PATH}
+ PYTHONPATH=${MED_ROOT_DIR}/lib/python2.6/site-packages/salome:${PYTHONPATH}
+ PYTHONPATH=${MED_ROOT_DIR}/bin/salome:${PYTHONPATH}
+ PYTHONPATH=${MED_ROOT_DIR}/lib/salome:${PYTHONPATH}
+ export PYTHONPATH
+
+Example 01: Explore a med file to get information concerning meshes and fields
+------------------------------------------------------------------------------
+
+:objectives: This example illustrates how to get information
+ concerning meshes and fields from a med file, using the
+ MEDLoader library.
+
+The loading of meshes and fields from a med file to a MEDCoupling data
+structure requires first the knowledge of metadata associated to these
+meshes and fields. You have to know the names of the meshes, so that
+you can specify the one you want to load, and then the names of the
+fields associated to one given mesh, the space discretizations used
+for each field, and the iterations available.
+
+The MEDLoader library can read these metadata without loading the
+physical data that compose the meshes and fields. This feature ensures
+the performance of the exploration process, in particular in the case
+of big meshes.
+
+This first instruction looks for meshes embedded in the med file
+(located by :tt:`filepath`) and returns the list of mesh names:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+.. WARNING: Note that the file path for the include directive must be
+ relative to this rst source file (i.e. as organized in the MED
+ source directory, and nevertheless the build procedure is realized
+ elsewhere.
+
+Then, you may select one of these names (or iterate on all names of
+the list) and read the list of fields defined on this mesh:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T2A
+ :end-before: # _T2B
+
+A field name could identify several MEDCoupling fields, that differ by
+their spatial discretization on the mesh (values on cells, values on
+nodes, ...). This spatial discretization is specified by the
+TypeOfField that is an integer value in this list:
+
+* :tt:`0 = ON_CELLS` (physical values defined by cell)
+* :tt:`1 = ON_NODES` (physical values defined on nodes)
+* :tt:`2 = ON_GAUSS_PT` (physical values defined on Gauss points)
+* :tt:`3 = ON_GAUSS_NE`
+
+.. note:: This constant variables are defined by the MEDLoader module
+ (:tt:`from MEDLoader import ON_NODES`).
+
+As a consequence, before loading the physical values of a field, we
+have to determine the types of spatial discretization that come with
+this field name and to choose one of this types. The instruction below
+read all the spatial discretization types available for the field of
+name :tt:`fieldName` defined on the mesh of name :tt:`meshName`:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T3A
+ :end-before: # _T3B
+
+Once you have selected the spatial discretization of interest (called
+:tt:`typeOfDiscretization` in the code below, that corresponds to an
+item of the list :tt:`listOfTypes`), you can extract the list of time
+iterations available for the identified field:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T4A
+ :end-before: # _T4B
+
+The iterations can be weither a list of time steps for which the field
+is defined (a timeseries) or a list of frequency steps (spectral
+analysis). In any case, an iteration item consists in a couple of
+integers, the first defining the main iteration step and the second an
+iteration order in this step, that can be consider as a sub-iteration
+of the step. In most of cases, the iteration order is set to :tt:`-1`
+(no sub-iterations).
+
+The field values can now be read for one particular time step (or
+spectrum tic), defined by the pair (iteration number, iteration
+order). This is illustrated by the example here after.
+
+Example 02: Load a mesh and a field from a med file
+---------------------------------------------------
+
+:objectives: This illustrates how to load the physical data of a
+ specified mesh and a specified field.
+
+The metadata read from a med file are required to identify the list of
+meshes and fields in the med file. We assume in this example that the
+mesh and field to load are identified, i.e. we know the name of the
+mesh to load (:tt:`meshName`) and the characteristic properties of the
+field to load (:tt:`fieldName`, :tt:`typeOfDiscretization` and
+:tt:`iteration`). For example, the instruction below load the mesh of
+name :tt:`meshName`:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T5A
+ :end-before: # _T5B
+
+and the instruction below load the field with name :tt:`fieldName`
+defined on this mesh at a particular iteration step characterized by
+the couple :tt:`(iterationNumber,iterationOrder)`:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T6A
+ :end-before: # _T6B
+
+The variables :tt:`mesh` and :tt:`field` in this code example are instances of
+the MEDCoupling classes describing the meshes and fields.
+
+Note that the read functions required the parameter
+:tt:`dimrestriction`. This parameter discreminates the mesh dimensions you
+are interested to relatively to the maximal dimension of cells
+contained in the mesh (then its value could be 0, -1, -2 or -3
+depending on the max dimension of the mesh). A value of
+:tt:`dimrestriction=0` means "no restriction".
+
+Example 03: Manage the MEDCoupling data load from a med file
+------------------------------------------------------------
+
+:objectives: Some suggestions for the MEDCoupling objects management,
+ in a programming context.
+
+In a real programming case, it could be relevant to explore first the
+med file to load all metadata concerning the whole set of meshes and
+associated fields, and then to load the physical data only once when
+required by the program.
+
+Such a programming scenario required that you keep all metadata in
+data structures created in memory, so that you can manage the
+collection of meshes and fields. Nevertheless, the MEDMEM library
+does not provide such data structures.
+
+We suggest to work with a simple list concept to store the metadata
+for each mesh entry and each field entry. Note that a mesh entry is
+characterized by the mesh name only, while a field entry is
+charaterized by the following attributes:
+
+* :tt:`fieldName`: the name of the field
+* :tt:`meshName`: the name of the mesh that supports the field
+* :tt:`typeOfDiscretization`: the type of spatial discretization
+* :tt:`iteration`: a couple of integers :tt:`(iter,order)` that
+ characterizes the step in a serie (timeseries or spectrum).
+
+By default, we suggest to work with a simple map concept (dictionnary in a
+python context, map in a C++ context) to register the meshes and
+fields loaded from the med file for each metadata entry.
+
+Then, depending on the processing algorithm you intend to implement,
+you may dispatch the data in a tree structure that fit your specific
+case, for performance reasons. For example, the following code
+illustrates how to dispatch the metadata in a tree data structure
+where leaves are the physical data (field objects). We first have to
+define a tree structure (basic definition in htis simple case, but it
+works fine):
+
+.. include:: ../../tut/medloader/manage.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+Then, we can scan the med structure and dispatch the metadata in the
+tree structure:
+
+.. include:: ../../tut/medloader/manage.py
+ :literal:
+ :start-after: # _T2A
+ :end-before: # _T2B
+
+Finally (and afterwards), we can display on standard output the
+metadata registered in the tree structure:
+
+.. include:: ../../tut/medloader/manage.py
+ :literal:
+ :start-after: # _T3A
+ :end-before: # _T3B
+
+Example 04: Simple arithmetic operations with fields
+----------------------------------------------------
+
+:objectives: This example illustrates how to load field iterations
+ from a med file containing a field timeseries and shows
+ how to use these iterations in simple arithmetic
+ operations.
+
+We consider a med file :tt:`timeseries.med`, containing one single
+mesh named :tt:`Grid_80x80` that supports a field with values defined
+on nodes (:tt:`typeOfDiscretization=ON_NODES`) given for ten
+iterations.
+
+This first code block identifies the mesh and the field to consider in
+this example:
+
+.. include:: ../../tut/addfields/operations.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+The following instructions load the field, make a scaling on the
+physical values (multiply by 3) and then save the result in an output
+med file named :tt:`scaling.med`:
+
+.. include:: ../../tut/addfields/operations.py
+ :literal:
+ :start-after: # _T2A
+ :end-before: # _T2B
+
+Note the usage of the method :tt:`applyFunc` that takes in argument a
+string expression that defined the mathematical function to apply on
+the values of the fields. In this expression, the field is symbolized
+by the letter :tt:`f`.
+
+The following set of instructions makes the addition of iteration
+number 3 with iteration number 4 of the field. Note that this
+operation required first to load the mesh:
+
+.. include:: ../../tut/addfields/operations.py
+ :literal:
+ :start-after: # _T3A
+ :end-before: # _T3B
+
+Exemple 05: Compare fields load from different files
+----------------------------------------------------
+
+:objectives: Illustrates the usage of the function
+ changeUnderlyingMesh
+
+Exemple 06: Create a field from scratch on a spatial domain
+-----------------------------------------------------------
+
+:objectives: Illustrates the applyFunc method of fields
+
+Exemple 07: Manipulate structured mesh
+--------------------------------------
+
+:objectives: Illustrates the basic usage of the advanced interface of
+ MEDLoader.
+
+The MEDLoader frontal interface let you load unstructured meshes:
+
+.. include:: ../../tut/medloader/tutorial.py
+ :literal:
+ :start-after: # _T5A
+ :end-before: # _T5B
+
+That is to say that even if the mesh is a structured mesh (a grid mesh
+for example), then you will get a MEDCoupling unstructured mesh
+object.
+
+To manipulate structured mesh objects, you have to use the MEDLoader
+backend interface named :tt:`MEDFileMesh`, or its derivative
+:tt:`MEDFileUMesh` for unstructured meshes, and :tt:`MEDFileCMesh` for
+structured meshes (CMesh for Cartesian Mesh). The code below
+illustrates how to load a mesh using the :tt:`MEDFileMesh` interface,
+and to know if it is a structured mesh:
+
+.. include:: ../../tut/medloader/cmesh.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+This second example can be used in the case where you know in advance
+that it is a structured mesh:
+
+.. include:: ../../tut/medloader/cmesh.py
+ :literal:
+ :start-after: # _T2A
+ :end-before: # _T2B
+
+In any cases, you can also save the mesh in another file with the
+methode :tt:`write` of the :tt:`MEDFileMesh` object:
+
+.. include:: ../../tut/medloader/cmesh.py
+ :literal:
+ :start-after: # _T3A
+ :end-before: # _T3B
+
+Exemple 08: Make a projection of a field
+----------------------------------------
+
+:objectives: Make the projection of a field from a source mesh to a
+ target meshe. The source mesh and the target mesh are
+ two different mesh of the same geometry.
+
+The input data of this use case are:
+
+* a source mesh, and a field defined on this source mesh (left side of
+ the figure below)
+* a target mesh, on which we want to project the field (right side of
+ the figure below)
+
+.. note:: The two meshes are displayed side by side on the figure for
+ convenience reason, but in the real use case they stand at
+ the same location in 3D space (they describe the same
+ geometry).
+
+.. image:: images/medop_projection_inputs.png
+ :align: center
+
+The expected result is a field defined on the target mesh and which
+corresponds to a physical data equivalent to the source field,
+i.e. with conservation of some physical properties. This operation
+requires the usage of interpolation algorithms provided by the
+:tt:`medcouplingremapper` library:
+
+.. include:: ../../tut/projection/demomed/demo_loadsource.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+Some comments on this code:
+
+* The physical property to be preserved by this interpolation is
+ specified using the keyword :tt:`ConservativeVolumic`
+* The parameter :tt:`P0P0` given at the preparation step of the
+ remapper specifies that the interpolation is done from CELLS (P0) to
+ CELLS (P0).
+* The interpolation, strictly speaking, is performed by the
+ instruction :tt:`ftarget =
+ remap.transferField(fsource,defaultValue)`
+* In this instruction, the :tt:`defaultValue` is used to set the target value
+ in the case where there is no cell in the source mesh that overlap
+ the target mesh (for example when the source mesh correspond to a
+ geometrical sub-part of the target mesh).
+
+When executing the :tt:`remapper`, the result is a new field defined on
+the target mesh, as illustrated on the figure below:
+
+.. image:: images/medop_projection_result.png
+ :align: center
+
+Exemple 09: Make a partition of a mesh using a field
+----------------------------------------------------
+
+:objective: This illustrates how to make a mesh partition using the
+ value of a field defined on this mesh.
+
+The input data is a MEDCoupling scalar field (:tt:`field`) defined on
+a 3D mesh, and we want to use this field as a criterium to make a
+partition of the mesh, for example by creating the mesh surface that
+delimits the volumes where the field value is greater that a limit L
+(and conversely the volumes where the field value is lower).
+
+.. image:: images/partition_mesh.png
+ :align: center
+
+The code below shows the simplest way to extract the cells where
+:tt:`field>L` and to create the skin mesh:
+
+.. include:: ../../tut/medcoupling/partition.py
+ :literal:
+ :start-after: # _T1A
+ :end-before: # _T1B
+
+At the end, the variable :tt:`skin` is a 2D mesh that can be saved in
+a med file using the MEDLoader:
+
+.. image:: images/partition_skin.png
+ :align: center
+
+Advanced usages of the MEDMEM library
+=====================================
+
+This section could explain how to process the physical data
+(dataArray) and to manipulate the advanced concepts of the MEDMEM
+library.
+
+.. Exemple 01: Create a field from an image
+.. ----------------------------------------
+
--- /dev/null
+.. meta::
+ :keywords: mesh, field, manipulation, user guide
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+MED module: User guide for graphical interface
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+This document is a quick guide for Graphical User Interface of MED module. It
+shows how to use this module on the basis of a few reference examples, built
+from use cases identified during requirement analysis stage.
+
+.. warning:: This document is self-contained, but it is strongly advised to
+ read :doc:`the specification document<medcalc-specifications>` (in
+ french), at least to clarify concepts and terminology.
+
+.. contents:: Contents
+ :local:
+ :backlinks: none
+
+.. warning:: Screenshots are not up-to-date. They were extracted from SALOME
+ 6 with data visualization achieved using VISU module. In SALOME
+ 7, VISU module has been replaced by PARAVIS module. The
+ look-and-feel may thus be slightly different.
+
+General presentation of MED module
+==================================
+
+The overall ergonomics of MED module for field manipulation is inspired by
+softwares such as octave or scilab. It combines a graphical interface (GUI) to
+select and prepare data, with a textual interface (the python console, TUI)
+for actual work on data.
+
+This module provides two user environments that are marked by the red and
+green rectangles on the screenshot below:
+
+* **The data space** (*dataspace*), in which user defines the MED data sources
+ (*datasource*), that is to say the med files from which meshes and fields
+ are read. This data space allows for the exploration of meshes and fields
+ provided by the different data sources.
+* **The workspace** (*workspace*), in which user may drop fields selected in
+ the source space, and then use them for example to produce new fields using
+ the operations on fields provided by the TUI.
+
+.. image:: images/xmed-gui-withframe.png
+ :align: center
+
+A typical use of field manipulation functions is:
+
+1. Load a med file in the data space and explore its contents: meshes and
+ fields defined on these meshes, defined for one or several time steps.
+2. Select (using GUI) fields to be manipulated in workspace ; it is possible
+ to introduce restrictions on time steps, components or groups of cells.
+3. Create new fields executing algebraic operations (+,-,*,/) on fields,
+ applying simple mathematical functions (pow, sqrt, abs), or initializing
+ them "from scratch" on a support mesh.
+4. Visually control produced fields, using PARAVIS module in SALOME,
+ automatically controlled from user interface.
+5. Save (parts of) produced fields to a med file.
+
+
+Quick tour on functions available in MED module
+===============================================
+
+This section presents some use examples of MED module like a "storyboard",
+illustrating the functions proposed by the module.
+
+.. warning:: This section is under construction. Please consider that its
+ contents and organization are still incomplete and may change
+ until this warning is removed.
+
+Example 1: Explore data sources
+-------------------------------
+
+.. note:: This example illustrates the following functions:
+
+ * add a data source
+ * "Extends field series" and "Visualize" functions
+
+.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
+ :height: 16px
+
+.. |ICO_XMED| image:: images/ico_xmed.png
+ :height: 16px
+
+.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
+ :height: 16px
+
+.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
+ :height: 16px
+
+At startup the field manipulation module, identified by icon |ICO_XMED|, shows
+an empty interface:
+
+.. image:: images/xmed-gui-start.png
+ :align: center
+ :width: 800px
+
+The first step consists in adding one or several med data sources in
+"dataspace". For this, user clicks on icon "Add datasource"
+|ICO_DATASOURCE_ADD| to select a med file:
+
+.. image:: images/xmed-gui-datasource-selectfile.png
+ :align: center
+ :width: 800px
+
+This operation adds a new entry (datasource) in data space. The contents can
+be explored using the data tree. The figure below (left image) shows the
+result of loading the file ``timeseries.med`` containing a mesh named
+``Grid_80x80`` on which a field on nodes named ``Pulse`` is defined. By
+default, the field composition (in terms of time steps and components) is not
+displayed to avoid visual congestion of data tree. User must explicitly ask
+for visualization using the command "Expand field timeseries"
+|ICO_DATASOURCE_EXPAND| available in the field contextual menu. The result is
+displayed on center image. The list of field ``Pulse`` iterations can be advised.
+
+.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
+ :height: 340px
+.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
+ :height: 340px
+.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
+ :height: 340px
+
++--------------------------+--------------------------+--------------------------+
+| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
++--------------------------+--------------------------+--------------------------+
+
+.. note:: Strictly speaking, the *field* concept in MED model corresponds to
+ a given iteration. A set of iterations is identified by the term
+ *field time series*. If there is no ambiguity, the field name will
+ refer to both the field itself or the time series it belongs to.
+
+Finally, it is possible from dataspace to visualize the field general shape
+using a scalar map displayed in SALOME viewer. For this, user selects the time step to
+display then uses the command "Visualize" |ICO_DATASOURCE_VIEW| available in
+the associated contextual menu:
+
+.. image:: images/xmed-gui-datasource-visualize-zoom.png
+ :align: center
+ :width: 800px
+
+.. note:: This graphical representation aims at providing a quick visual
+ control. Scalar maps are displayed using the PARAVIS module.
+
+Example 2: Combine fields from different sources
+------------------------------------------------
+
+.. note:: This example illustrates the following functions:
+
+ * function "Use in workspace"
+ * function "Save"
+
+.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
+ :height: 16px
+.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
+ :height: 16px
+
+The objective is to access data contained in several med files, then to
+combine them in the same output file.
+
+User starts by adding med data sources in dataspace. In the example below,
+dataspace contains two sources names ``parametric_01.med`` and
+``smallmesh_varfiled.med``. The first one contains the mesh ``Grid_80x80_01``
+on which the field ``StiffExp_01`` is defined. The second source contains the
+mesh ``My2DMesh`` on which the two fields ``testfield1`` are ``testfield2``
+are defined:
+
+.. image:: images/xmed-userguide-example2-datasource.png
+ :align: center
+ :width: 800px
+
+In this example, ``StiffExp_01`` and ``testfield2`` are combined then saved to
+``result.med`` file. The procedure consists in importing the two fields in
+workspace, then to save the workspace. For this user selects the fields and
+uses the command "Use in workspace" |ICO_DATASOURCE_USE| available in the
+contextual menu. Both selected fields appear in the workspace tree:
+
+.. image:: images/xmed-userguide-example2-workspace.png
+ :align: center
+ :width: 800px
+
+Workspace is saved using the command "Save workspace" |ICO_WORKSPACE_SAVE|
+available in the module toolbar. A dialog window lets user set the save
+file name:
+
+.. image:: images/xmed-userguide-example2-workspace-save.png
+ :align: center
+ :width: 800px
+
+The file ``result.med`` can then be reloaded in MED module (or PARAVIS module)
+to check the presence of saved fields.
+
+.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
+.. (invalid mesh on field)
+
+.. _xmed.userguide.exemple3:
+
+Example 3: Apply a formula on fields
+------------------------------------
+
+.. note:: This example illustrates the following functions:
+
+ * execute mathematical operations in TUI console
+ * function "put" to refer to a work field in the list of persisting fields.
+ * function "Visualize" from TUI.
+
+The most common usage of field manipulation module is to execute mathematical
+operations on fields or on their components.
+
+Assume data sources are already defined in dataspace (in the following example
+a temporal series named ``Pulse`` contains 10 time steps defined on a mesh
+named ``Grid_80x80``, all read from ``timeseries.med`` data source).
+
+As previously seen, a field can be manipulated in workspace after selecting
+the field and applying the command "Use in
+workspace" |ICO_DATASOURCE_USE| from contextual menu. Here only one file is
+selected (two in the previous example) and the command then opens a dialog
+window to select data to work on and the way they will be manipulated:
+
+.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
+ :align: center
+ :width: 800px
+
+.. note:: In the current state of development, the interface only propose to
+ define the name of a variable representing the field in TUI. In
+ a next version, user will have the possibility to specify the field
+ component(s) to be used and a group of cells to introduce
+ a geometrical restriction. Conversely it will be possible to select
+ a complete time series to apply global operations on all time steps.
+
+After validation, the field if put in workspace tree and a variable
+``<alias>`` is automatically created in the TUI to designate the field. In
+this example, ``<alias>`` is ``f3``, as set by user to recall that variable
+corresponds to the third time step:
+
+.. image:: images/xmed-gui-workspace.png
+ :align: center
+ :width: 800px
+
+Field manipulation can start. In the example below, use creates the field``r``
+as the result of an affine transformation of field ``f3`` (multiplication of
+field by a scale factor 2.7 then addition of offset 5.2)::
+
+ >>> r=2.7*f3+5.2
+
+Other operations can be applied, as detailed in module specifications
+(cf. :ref:`Spécification des opérations<xmed-specifications>`):
+
+ >>> r=f3/1000 # the values of r are the ones of f3 reduced by a factor 1000
+ >>> r=1/f3 # the values of r are the inverted values of f3
+ >>> r=f3*f3 # the values of r are the squared values of f3
+ >>> r=pow(f3,2) # same result
+ >>> r=abs(f3) # absolute value of field f3
+ >>> ...
+
+The two operands can be fields. If ``f4`` is the fourth time step of field
+``Pulse``, then algebraic combinations of fields can be computed::
+
+ >>> r=f3+f4
+ >>> r=f3-f4
+ >>> r=f3/f4
+ >>> r=f3*f4
+
+Scalar variables can be used if needed::
+
+ >>> r=4*f3-f4/1000
+ >>> ...
+
+In theses examples, the variable ``r`` corresponds to a work field containing
+the operation result. By default the field is nor referenced in workspace
+tree. If user wants to add it, for example to make it considered when saving,
+then the following command is used::
+
+ >>> put(r)
+
+The function ``put`` aims at tagging the field as persisting, the to store it
+in the workspace tree to make it visible and selectable. Among all fields that
+could be created in console during the work session, all do not need to be
+saved. Some may only be temporary variables used in the construction of final
+fields. That is why only fields in workspace tree are saved when saving the
+workspace.
+
+Variables defined in console have other uses. First they allow for printing
+information relative to the manipulated field. For this one enters the
+variable name then validates::
+
+ >>> f3
+ field name (id) = Pulse (3)
+ mesh name (id) = Grid_80x80 (0)
+ discretization = ON_NODES
+ (iter, order) = (3,-1)
+ data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
+
+Second, variables can be used as command arguments (the list of commands
+available in TUI is described in section :ref:`Documentation of textual
+interface<xmed.userguide.tui>`). For example the function ``view`` displays
+the field scalar map in the viewer::
+
+ >>> view(f3)
+
+Results in:
+
+.. image:: images/xmed-gui-workspace-view.png
+ :align: center
+ :width: 800px
+
+.. note:: It is easy to compare two time steps of a field, computing the
+ difference ``f3-f4``, then producing a scalar map preview using the
+ function ``view``::
+
+ >>> view(f3-f4)
+
+Finally the field data can be displayed using the command``print``::
+
+ >>> print f3
+ Data content :
+ Tuple #0 : -0.6
+ Tuple #1 : -0.1
+ Tuple #2 : 0.4
+ Tuple #3 : -0.1
+ Tuple #4 : 0.4
+ ...
+ Tuple #6556 : 3.5
+ Tuple #6557 : 3.3
+ Tuple #6558 : 1.5
+ Tuple #6559 : 0.3
+ Tuple #6560 : 0.2
+
+It is important to note that operations between fields can only be applied if
+fields are defined on the same mesh. It corresponds to a specification of MED
+model that forbids operations between fields defined on meshes geometrically
+different. Technically it means that the conceptual objects *fields* must share
+the same conceptual object *mesh*.
+
+If user do want to use fields defined on different meshes, for example to
+manipulate the field values at the interface of two meshes sharing a 2D
+geometrical area, it is necessary first to make all fields be defined on the
+same surface mesh using a projection operation.
+
+.. note:: Such projection operations are available in the MEDCoupling library.
+
+Another classical need is using fields defined on meshes geometrically
+identical, but technically different for example when they are loaded from
+different med files. For such a case, the MEDCoupling library proposes
+a function "Change support mesh" ; its use in field manipulation module is
+illustrated in :ref:`example 4<xmed.userguide.exemple4>` described hereafter.
+
+.. _xmed.userguide.exemple4:
+
+Example 4: Compare fields derived from different sources
+--------------------------------------------------------
+
+.. note:: This example illustrates the following function:
+
+ * Change the underlying (support) mesh
+
+Assume here that fields have been defined on same mesh, geometrically
+speaking, but saved in different med files. This occurs for example for
+a parametric study in which several computations are achieved with variants on
+some parameters of the simulated model, each computation producing a med file.
+
+Let ``parametric_01.med`` and ``parametric_02.med`` be two med files
+containing the fields to compare, for example computing the difference of
+their values and visualizing the result.
+
+After loading data sources user sees two meshes, this time from the technical
+point of view, that is to say fields are associated to different conceptual
+mesh objects, while geometrically identical.
+
+However field manipulation functions do not allow operations on fields lying
+on different support meshes (see remark at the end of :ref:`example
+3<xmed.userguide.exemple3>`).
+
+To circumvent this issue, the module offers the function "Change underlying
+mesh" to replace a field mesh support by another, provided that the two meshes
+are geometrically identical, that is to say nodes have the same spatial
+coordinates.
+
+.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
+ :height: 16px
+
+In the proposed example, user selects the first time step of field
+``StiffExp_01`` in data source ``parametric_01.med``, and imports it in
+workspace using the command "Use in workspace" |ICO_DATASOURCE_USE|. User then
+selects the first time step of field ``StiffExp_02`` in data source
+``parametric_02.med``, but imports it in workspace using the command "Change
+underlying mesh" |ICO_DATASOURCE_CHG|. The following dialog window appears to
+let user select the new support mesh in dataspace tree:
+
+.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
+ :align: center
+
+In this example, the support mesh ``Grid_80x80_01`` of field ``StiffExp_01``
+to compare with is selected. After validation the workspace tree contains the
+field ``StiffExp_02`` defined on mesh ``Grid_80x80_01``:
+
+.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
+ :align: center
+
+.. note:: The function "Change underlying mesh" does not modify the field
+ selected in dataspace (basic running principle of dataspace), but
+ creates a field copy in workspace to then change support mesh. This
+ explains the default name for field ``dup(<name of selected
+ field>)`` (dup stands for "duplicate").
+
+All we have to do now is to associate a variable to this field, in order to
+manipulate it in TUI. This can be done using the command "Use in console"
+available in workspace contextual menu.
+
+Finally, if ``f1`` is a field from datasource ``parametric_01.med`` and ``f2``
+is a field from datasource
+``parametric_02.med`` according to the above procedure, then comparison values
+can be achieved as explained in :ref:`example 3<xmed.userguide.exemple3>`::
+
+ >>> r=f1-f2
+ >>> view(r)
+
+.. note:: As a general remark concerning this example, one may note:
+
+ * the geometrical equality of two meshes is constrained to a numerical
+ error that can be technically set, but not through the module interface.
+ This tolerance is empirically set to a standard value regarding to
+ success of most of the use cases. The usefulness of setting this value in
+ the interface could be later investigated.
+
+ * User must explicitly ask for changing a field support mesh, in order to
+ compare fields coming from different data sources. This choice has been
+ made to keep trace of modifications made on data (no modification is made
+ without user knowing, even to improve ergonomics).
+
+
+Example 5: Create a field on a spatial domain
+---------------------------------------------
+
+.. note:: This example illustrates the following functions:
+
+ * initialize with function of spatial position
+ * initialize on a group of cells
+
+The geometrical domain on which the field to create is defined is here given
+by cell group data. This use case is provided for producing initial load
+conditions of a structure, for example defining a field on a geometry surface
+identified by a group of cells.
+
+.. warning:: DEVELOPMENT IN PROGRESS
+
+Example 6: Extract a field part
+-------------------------------
+
+.. note:: This example illustrates the following functions:
+
+ * extract a component (or a subset of components)
+ * extract a geometrical domain (values on a group of cells)
+ * extract one or several time steps
+
+.. warning:: DEVELOPMENT IN PROGRESS
+
+ Here the restriction functions that allow to get some components only, have
+ to be illustrated. The principle is creating a new field that is
+ a restriction of input field to a list of given components (use the
+ function __call__ of fieldproxy).
+
+For time step extraction, we can reduce to the case of example 2 with a single
+data source.
+
+Example 7: Create a field from a to[mp]ographic image
+-----------------------------------------------------
+
+.. note:: This example illustrates the following function:
+
+ * Create a field without data source (neither mesh nor field), from an
+ image file
+
+In tomography or topography studies, measurement devices produce images that
+represent a physical quantity using gray levels on a given cutting plane. The
+following image represents for example a internal view of human body obtained
+by MRI:
+
+.. image:: images/xmed-irm.png
+ :align: center
+ :width: 600px
+
+This image is a subset of pixels organized on a Cartesian grid. It can thus be
+represented as a scalar field whose values are defined on cells of a mesh
+having the same dimension as the image (number of pixels):
+
+.. image:: images/xmed-irm-field.png
+ :align: center
+ :width: 600px
+
+The field manipulation module provides a tool named ``image2med.py`` to
+convert a file image to a med file containing the image representation as
+a scalar field (only the gray level is kept)::
+
+ $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
+
+.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
+ :height: 16px
+
+This conversion operation can be automatically achieved using the command "Add
+Image Source" |ICO_IMAGESOURCE| available in GUI toolbar. This command opens
+the following window to let user select a file image:
+
+.. image:: images/medop_image2med_dialog.png
+ :align: center
+
+The name of result med file is set by default (changing file extension to
+``*.med``) but can be modified. Finally user can ask for automatic load of
+this med file in data space. Fields can then be manipulated like presented in
+the standard use cases.
+
+For example, the image below depicts the result of the difference between two
+images, added to the reference image: if i1 and i2 are the fields created from
+these two images, then ``r = i1 + 5*(i2-i1)`` with 5 an arbitrary factor to
+amplify the region of interest (above the left eye):
+
+.. image:: images/xmed-irm-diff.png
+ :align: center
+ :width: 600px
+
+The example below is the result of loading a tomographic image courtesy of MAP
+project (Charles Toulemonde, EDF/R&D/MMC). The tomographic image:
+
+.. image:: images/champ_altitude_MAP.png
+ :align: center
+ :width: 600px
+
+The result of loading:
+
+.. image:: images/medop_image2med_tomographie.png
+ :align: center
+ :width: 800px
+
+Example 8: Continue analysis in PARAVIS
+---------------------------------------
+
+.. note:: This example illustrates the following functio:
+
+ * Export fields to PARAVIS module
+
+The solutions for field representation in MED module aims at proposing a quick
+visual control.
+
+For a detailed analysis of fields, user shall switch to PARAVIS. The field
+manipulation module has a function to facilitate this transition, with
+automatic load in PARAVIS and proposing a default visualization (scalar map).
+
+For this user selects in workspace the fields to export, then call the export
+function from contextual menu:
+
+.. image:: images/medop_exportparavis.png
+ :align: center
+
+Selected fields are grouped in a single MED entry in PARAVIS, and the first
+field is depicted as a scalar map:
+
+.. image:: images/medop_exportparavis_result.png
+ :align: center
+ :width: 800px
+
+.. note:: The export function is a convenience function. The same operation
+ can be manually achieved, first saving fields to a med file then
+ loading the created file in PARAVIS module for visualization.
+
+.. _xmed.userguide.tui:
+
+Using the textual interface (TUI)
+=================================
+
+All operations driven through GUI can be done (more or less easily) using TUI.
+The field manipulation module can even be used exclusively in textual mode.
+..
+ For this run the command::
+
+ $ <path/to/appli>/medop.sh
+..
+ This command opens a command console ``medop>``. A med file can be loaded and
+ manipulated, for example to create fields from file data.
+
+Whatever textual or graphical mode is used, a typical workflow in console
+looks like the following instructions::
+
+ >>> medcalc.LoadDataSource("/path/to/mydata.med")
+ >>> la
+ id=0 name = testfield1
+ id=1 name = testfield2
+ >>> f1=accessField(0)
+ >>> f2=accessField(1)
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ >>> r=f1+f2
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ r (id=2, name=testfield1+testfield2)
+ >>> r.update(name="toto")
+ >>> ls
+ f1 (id=0, name=testfield1)
+ f2 (id=1, name=testfield2)
+ r (id=2, name=toto)
+ >>> putInWorkspace(r)
+ >>> saveWorkspace("result.med")
+
+The main commands are:
+
+* ``LoadDataSource``: load a med file in data base (useful in pure textual mode)::
+
+ >>> LoadDataSource("/path/to/datafile.med")
+
+* ``LoadImageAsDataSource``: load an image as a med file
+
+* ``la``: show the list of all fields loaded in data base ("list all")
+* ``accessField``: set a field in workspace from its identifier (useful in pure
+ textual mode ; this operation can be done in GUI selecting a field from data
+ space).::
+
+ >>> f=accessField(fieldId)
+
+* ``ls``: show the list of fields available in workspace ("list")
+* ``putInWorkspace``: put a reference to a field in *management space*::
+
+ >>> putInWorkspace(f)
+
+* ``saveWorkspace``: save to a med a file all fields referenced in management space::
+
+ >>> saveWorkspace("/path/to/resultfile.med")
+
+.. note::
+
+ * the ``LoadDataSource`` command only loads metadata describing meshes and fields
+ (names, discretization types, list of time steps). Meshes and physical
+ quantities on fields are loaded later (and automatically) as soon as an
+ operation needs them. In all cases med data (mete-information and values)
+ are physically stored in *data base* environment.
+ * the ``accessField`` command defines a *field handler* in workspace, i.e.
+ a variable that links to the physical field hosted in data base. Physical
+ data never transit between environments but remain centralized in data
+ base.
+
+The following TUI commands need to work in graphical environment:
+
+* ``medcalc.MakeDeflectionShape``
+* ``medcalc.MakeIsoSurface``
+* ``medcalc.MakePointSprite``
+* ``medcalc.MakeScalarMap``
+* ``medcalc.MakeSlices``
+* ``medcalc.MakeVectorField``
+
+
+.. LocalWords: softwares
+++ /dev/null
-.. AVERTISSEMENT:
-.. Ce fichier contient les définitions globales à la documentation. Il
-.. peut être inclu au moyen de la directive rst "include" pour
-.. disposer des définitions dans le fichier qui fait l'inclusion.
-.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
-.. il est interdit de faire afficher du texte par ce document de
-.. définition.
-
-.. REFERENCES DOCUMENTAIRES:
-.. (les documents sont fournis dans le répertoire _static/documents)
-
-.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
-.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
-.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
-
-.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
-.. |REF_CEA_VBE_MEDMEM| replace:: MEDMEM user's guide
-.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
-.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
-.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
-.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
-.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
-.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
-.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
-.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
-.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
-.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
-.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
-
-.. PRESENTATIONS:
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
-.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
-.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
-.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
-.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
-.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
-.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
-.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
-.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
-
-
-
-.. LIENS EXTERNES:
-.. (l'accès nécessite le réseau intranet EDF et internet)
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
-.. |LINK_EDF_MEDDOC| replace:: Modèle MED
-.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
-.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
-.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
-
-.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
-.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
-.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
-
-.. RENVOIES:
-
-.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
-.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
-
-
-.. SNAPSHOTS:
-
-.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
-.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
-
-.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
-.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
-
-.. |XMED_USERGUIDE_PDF| replace:: version pdf
-.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
-
-
-.. =========================================================
-.. Rendering roles
-.. =========================================================
-.. This role can be used to display monospace text (code)
-.. role:: tt
- :class: tt
-
-.. role:: strike
- :class: strike
-
-.. role:: bolditalic
- :class: bolditalic
-
-.. role:: underline
- :class: underline
-
-.. role:: tag
- :class: tag
-
-.. role:: tagb
- :class: tagb
-
-.. role:: todo
- :class: todo
-
-.. role:: date
- :class: date
-
-.. role:: warn
- :class: warn
-
-.. role:: info
- :class: info
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med, développement
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide de développement du composant MEDOP
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le composant logiciel MEDOP est un élément du module MED. Il fournit
-une interface utilisateur pour la manipulation de maillages et de
-champs, composée d'une interface texte (TUI) et d'une interface
-graphique (GUI). L'interface graphique constitue l'interface graphique
-du module MED.
-
-Ce document est la documentation technique du composant MEDOP. Il
-fournit les instructions à suivre pour installer le composant en vue
-d'un travail de développement, puis décrit les éléments de conception.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Mise en place de l'espace de développement
-==========================================
-
-Gestion de configuration du composant MEDOP
--------------------------------------------
-
-Le composant logiciel MEDOP est un package du module SALOME MED,
-hébergé dans l'espace source au niveau du sous-répertoire
-`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le
-module SALOME MED.
-
-Organisation des sources du composant MEDOP
--------------------------------------------
-
-Le répertoire source `src/MEDOP` distingue les sous-répertoires
-suivants:
-
-* cmp: package containing the SALOME components
-* tui: package containing the python user interface
-* gui: package containing the graphical user interface (the GUI part
- of the MED module)
-* res: resources files associated to the MEDOP package (icons, config
- files, data files, ...)
-* exe: additional executable programs that can be launched from the
- MEDOP framework
-
-Construction du composant MEDOP
--------------------------------
-
-Intégré à la construction du module MED. Le composant MEDOP dépend de
-MEDCoupling et MEDLoader uniquement.
-
-Exécution des tests unitaires du composant MEDOP
-------------------------------------------------
-
-Les tests unitaires peuvent être exécutés au moyen de scripts python
-lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
-
- $ ./appli/runSession
- [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py
-
-L'exécution imprime un rapport détaillant le résultat pour chaque
-fonction de test::
-
- test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
- test_Calculator_basics (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
- test_addDatasource (__main__.MyTestSuite) ... ok
- test_getDataManager (__main__.MyTestSuite) ... ok
- test_getFieldHandlerList (__main__.MyTestSuite) ... ok
- test_getFieldRepresentation (__main__.MyTestSuite) ... ok
- test_markAsPersistent (__main__.MyTestSuite) ... ok
- test_saveFields (__main__.MyTestSuite) ... ok
- test_updateFieldMetadata (__main__.MyTestSuite) ... ok
-
-Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
-
-* ``test_medop_components.py``: test les composants SALOME développés pour
- la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
-* ``test_xmed_fieldOperations.py``: test des operations de champs telles
- qu'elles sont mises en oeuvre depuis l'interface textuelle.
-* ``test_xmed_uiEventListener.py``: test du système de notification
- d'évènements des composants vers la partie gui du module MED.
-* ``test_xmed_visualisation.py``: test du système de visualisation
- des champs tel que piloté depuis le module MED.
-
-Architecture du module XMED
-===========================
-
-Le module MED pour la manipulation de champs est composé de:
-
-* une bibliothèque de fonctions pour le traitement de données sur des
- maillages et des champs conformes au modèle MED (package
- MEDCoupling, MEDLoader et REMAPPER);
-* une interface graphique pour la mise en oeuvre des cas standard de
- manipulation de champs;
-* une ensemble d'outils pour intervenir sur des fichiers au format
- MED.
-
-Une bibliothèque de fonctions pour le traitement de données
------------------------------------------------------------
-
-La figure ci-dessous montre la structure des paquets logiciels qui
-constituent la bibliothèque:
-
-.. image:: images/medlayers.png
- :align: center
-
-Elle comprend en particulier les paquets suivants:
-
-* MEDCoupling: qui décrit les structures de données pour porter les
- maillages et les champs
-* MEDLoader: qui fournit les fonctions de persistence sous forme de
- fichiers au format MED (lecture et écriture).
-* REMAPPER:
-
-Il est important de noter que MEDCoupling n'a aucune dépendance
-logicielle autre que la bibliothèque C++ standard. Ceci permet
-d'envisager son implantation dans un code de calcul ou un outil de
-traitement sans tirer l'ensemble pré-requis de SALOME.
-
-Une interface graphique pour l'exécution des cas standard
----------------------------------------------------------
-
-
-Un ensemble d'outils pour le traitement de fichiers
----------------------------------------------------
-
-
-Description des composants
-==========================
-
-MEDDataManager - Le gestionnaire des données de session
--------------------------------------------------------
-
-Le composant MEDDataManager s'occupe de fournir les données MED sur
-demande des interfaces clientes, en particulier pour module de
-pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
-en général elle proviennent d'un fichier au format med contenant des
-champs définis sur des maillages. Les données sont identifiées à la
-lecture des métadonnées de description dans le fichiers med, puis les
-valeurs des champs et les maillages support sont chargés au besoin.
-
-Le chargement des métadonnées de description se fait par la méthode::
-
- addDatasource(const char \*filepath)
-
-
-
-Eléments d'implémentation
-=========================
-
-Ecrire un service CORBA qui retourne une sequence de FieldHandler:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandlerList * MyFunction(...) {
- vector<MEDOP::FieldHandler*> fieldHandlerList;
- ...
-
- fieldHandlerList.push_back(fieldHandler);
-
- // Map the resulting list to a CORBA sequence for return:
- MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList();
- int nbFieldHandler = fieldHandlerList.size();
- fieldHandlerSeq->length(nbFieldHandler);
- for (int i=0; i<nbFieldHandler; i++) {
- fieldHandlerSeq[i] = *fieldHandlerList[i];
- }
- return fieldHandlerSeq._retn();
- }
-
-Ecrire un service CORBA qui retourne une structure CORBA:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandler * fieldHandler = new ...
- _fieldHandlerMap[fieldHandler->id] = fieldHandler;
-
- // >>> WARNING: CORBA struct specification indicates that the
- // assignement acts as a desctructor for the structure that is
- // pointed to. The values of the fields are copy first in the new
- // structure that receives the assignement and finally the initial
- // structure is destroyed. In the present case, WE WANT to keep
- // the initial fieldHandler in the map. We must then make a deep
- // copy of the structure found in the map and return the copy. The
- // CORBA struct specification indicates that a deep copy can be
- // done using the copy constructor. <<<
- return new MEDOP::FieldHandler(*fieldHandler);
-
-
-
-ANNEXE A: Bug en cours
-======================
-
-TO FIX:
-
-* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
- 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
- reference correcte vers le maillage).
-* le script de test test_medoperation.py plante si le module xmed n'a
- pas été chargé avec des données chargées.
-
-ANNEXE B: Traçabilité avec le module XMED
-=========================================
-
-Le module SALOME de nom XMED est l'espace de développement initial du
-composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette
-annexe est la notice technique de ce module, qui reste disponible mais
-qui n'est plus maintenu.
-
-Gestion de configuration du module XMED
----------------------------------------
-
-Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
-configuration dans une base git du projet NEPAL. Ils peuvent être
-récupérés au moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
-
-Cette commande installe un répertoire ``xmed`` contenant l'ensemble
-des sources du module XMED.
-
-Le module XMED a pour pré-requis logiciel la plateforme SALOME:
-
-* SALOME version 6.1.3 (au moins) à télécharger à l'URL
- http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
-* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
-* Installer la plate-forme choisie selon les instructions fournies.
-
-Le module XMED utilise également une bibliothèque interne au projet
-NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
-SALOME pour un usage de développement (XSALOME signifie eXtension
-SALOME). Les sources de cette bibliothèque doivent être récupérés au
-moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
-
-Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
-des sources de la bibliothèque XSALOME.
-
-.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
- simple bibliothèque de fonctions qui complète ou rend plus facile
- d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
- être intégrée à d'autres projets que les projets internes NEPAL ou
- MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
- héberge des développements destinés à être reversés dans la
- plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
- donc être garanti sur le long terme.
-
-Installation et lancement de l'application
-------------------------------------------
-
-L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
-disponible et que le shell de travail est étendu avec l'environnement
-de SALOME. En général, par des commandes de la forme::
-
- $ . /where/is/salome/prerequis.sh
- $ . /where/is/salome/envSalome.sh
-
-La compilation des modules xsalome et xmed suit le standard SALOME. La
-bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
-cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
-la configuration de la procédure de reconstruction de xmed::
-
- $ export XSALOME_DIR=<xsalome_installdir>
-
-Aprés l'installation de xmed, il est possible de générer
-automatiquement une application SALOME prête à l'emploi pour la
-manipulation de champs::
-
- $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
-
-Cette commande génére un répertoire ``appli`` à l'emplacement où elle
-est exécutée. Il reste à lancer l'application SALOME au moyen de la
-commande::
-
- $ ./appli/runAppli -k
import salome
salome.salome_init()
import SALOME_MED
-
+
medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
medOp = medObj.createMedOperator()
-
+
f1 = medObj.getField("testfield1",-1,-1)
f2 = medObj.getField("testfield2",-1,-1)
-
+
somme = medOp.add(f1,f2)
Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à
salome.salome_init()
import SALOME_MED
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
+ medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
from xmed import fieldproxy
.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
++---------------+---------------+
L'image de gauche montre la sélection du pas de temps, l'image de
droite la boîte de dialogue qui permet la saisie de l'alias avec
// We suppose here that we have a CORBA object reference (object of
// type *_ptr or *_var), for example a SALOME_MED::MED object.
- SALOME_MED::MED_ptr medObj = ... // anything to get this object
+ SALOME_MED::MED_ptr medObj = ... // anything to get this object
// Get the IOR of this object
QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
QStringList commands;
commands+="import salome";
commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR);
-
+
QStringListIterator it(commands);
while (it.hasNext()) {
pyConsole->exec(it.next());
from xmed.fieldproxy import getFieldFromMed
from xmed.medproxy import getMedProxy
-
+
med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100")
-
+
f1=getFieldFromMed(med,"testfield1",-1,-1)
Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA
.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
++---------------+---------------+
Cette fonction répond au besoin de contrôle interactif des résultats
produits par les opérations de manipulation de champs.
(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
.. code-block:: python
-
+
import salome
import VISU
et fournit des fonctions de test unitaire (à exécuter ou pour s'en
inspirer). Après avoir lancé SALOME via une application virtuelle,
on peut taper::
-
+
$ <APPLI_ROOT>/runSession
[NS=venus:2810] $ python -i test_medoperation.py
- >>>
-
+ >>>
+
- Ceci permet de tester en particulier l'interface ``MedOp`` et son
utilisation dans le module python ``fieldproxy.py``.
:keywords: maillage, champ, MED, MEDMEM
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Note de travail concernant l'utilisation de MEDMEM
l'exemple):
.. code-block:: cpp
-
+
MED *myMed = new MED;
MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
driverIn->open();
permettre la mise à jour du support:
.. code-block:: cpp
-
+
MESH * mesh = myMed->getMesh(field);
mesh->read();
myMed->updateSupport();
Pour enfin charger les valeurs des composantes du champ:
.. code-block:: cpp
-
+
field->read();
La numérotation des éléments de maillage
``MedDataManager`` dans l'interface:
.. code-block:: cpp
-
+
#include "MEDMEM_MedDataManager.hxx"
class MedDataManager
public:
~MedDataManager();
void printFieldDouble(FIELD<double,FullInterlace> * field);
-
+
%extend {
MedDataManager(char * fileName)
{
- return new MedDataManager(string(fileName));
+ return new MedDataManager(string(fileName));
}
MedDataManager(MED * med)
{
return new MedDataManager(med);
}
-
+
%newobject getFieldDouble(const char * fieldName, const int dt, const int it);
FIELD<double, FullInterlace> * getFieldDouble(const char * fieldName, const int dt, const int it)
{
- return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
+ return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
}
}
-
+
};
d'amorce systématique:
.. code-block:: python
-
+
import salome
salome.salome_init()
-
+
import SALOME_MED
from libSALOME_Swig import *
On peut charger le composant SALOME MED:
.. code-block:: python
-
+
medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
grâce auquel les services de chargement de la structure MED peuvent
structure MED dans l'étude salome passée en argument:
.. code-block:: python
-
+
filePathName = "myfile.med"
medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude:
.. code-block:: python
-
+
filePathName = "myfile.med"
medObj = medComp.readStructFile(filePathName,salome.myStudyName)
fieldIdx = 1 # WRN maybe there is no field of idx=1
iterationIdx = 0
fieldName = medObj.getFieldNames()[fieldIdx]
- dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
+ dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
it = dtitfield[0]
dt = dtitfield[1]
fieldObj = medObj.getField(fieldName,it,dt)
nbOfFields = medObj.getNumberOfFields()
fieldNames = medObj.getFieldNames()
-
+
mesh = fieldObj.getSupport().getMesh()
.. note::
les exemples précédents):
.. code-block:: python
-
+
# Load the med structure using MED
medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
filePathName = "myfile.med"
medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
+
# Get the VISU component
import VISU
visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
visuComp.SetCurrentStudy(salome.myStudy)
-
+
# Get the sobject associated to the med object named "Med"
aSObject = salome.myStudy.FindObject("Med")
isPresent, medSObj = aSObject.FindSubObject(1)
-
- # Finally, import the med sobject in VISU
+
+ # Finally, import the med sobject in VISU
result = visuComp.ImportMed(medSObj)
Il est possible de d'aller plus loin et par exemple de déclencher
Questions:
-* Comment obtenir le nom du fichier med à partir d'une structure med?
+* Comment obtenir le nom du fichier med à partir d'une structure med?
* Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de
la donnée de l'objet CORBA SALOME_MED::MED?
.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-+---------------+---------------+
++---------------+---------------+
| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
++---------------+---------------+
| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
++---------------+---------------+
La solution technique est construite sur les principes suivants:
+++ /dev/null
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Appendix: Documentation references
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. include:: medop-definitions.rst
-
-References:
-
-* (**in french**) |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
-* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
-* (**in french**) |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
-
-Slides (**in french**):
-
-* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
-* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
-* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
-* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
-
- - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
- - |REF_EDF_JUS2011_OGV1|_ (**video**)
- - |REF_EDF_JUS2011_OGV3|_ (**video**)
- - |REF_EDF_JUS2011_OGV4|_ (**video**)
-
-Working notes (**in french**):
-
-* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
-* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med
- :author: Guillaume Boulant
-
-.. include:: medop-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>`, 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:
-
-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.
-
-
+++ /dev/null
-.. meta::
- :description: introduction guide for users of the MEDMEM library
- :keywords: mesh, field, med, MEDCoupling, MEDLoader
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-MEDMEM library: Starter guide for users
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-This document illustrates how to start with the programming interface
-of the MEDMEM library. The users is someone who intends to create a
-data processing script involving meshes and fields.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
- :depth: 2
-
-General overview
-================
-
-Definition of the MEDMEM library
---------------------------------
-
-The MEDMEM library is designed to manipulate meshes and fields that
-conform to the MED data model. This library can be used in C++
-programs as in python scripts for data processing on meshes and
-fields. The library contains the data structure to describe meshes and
-fields as C++ objects (MEDCoupling package). It provides a set of
-functions to manage the persistency toward the med file format
-(MEDLoader package), and to process the data througt interpolation and
-localization algorithms (INTERP_KERNEL and REMAPPER packages), for
-example to perform field projections from a mesh to another.
-
-Installation of the MEDMEM library
-----------------------------------
-
-The MEDMEM library is part of the SALOME MED module and then is
-installed together with this module by the installation process of
-SALOME. Nevertheless, it is possible for low-weight deployment to
-install only the MEDMEM library from the source files embedded in the
-SALOME MED module. Keep in mind that the MEDMEM library is designed to
-be a self-consistent library with very few third party softwares (only
-med-file, glibc and mpi typically). In particular, it is strictly
-independant from the SALOME framework even if it distributed with
-SALOME for convenience reasons.
-
-Components of the MEDMEM library
---------------------------------
-
-The MEDMEM library consists in a small set of atomic libraries files,
-in particular:
-
-* :tt:`medcoupling`: this library provides the data structures (C++
- classes) to describe meshes and fields.
-* :tt:`medloader`: this library provides I/O functions to the MED file
- format
-* :tt:`interpkernel`: this library provides the mathematical
- structures and algorithms required med data processing, in
- particular interpolation and localization.
-* :tt:`medcouplingremapper`: this library provides the functions for
- fields projections and interpolation.
-
-The figure below represents the layer structure of the packages of the
-library:
-
-.. image:: images/medlayers_70pc.png
- :align: center
-
-What we call MEDMEM library in this document is represented by the
-orange packages on this diagram. The white packages reprensent the old
-deprecated MEDMEM library. The blue packages represent the aditionnal
-components for field manipulation througth the user interface (TUI and
-GUI).
-
-The MEDMEM library comes also with this set of atomic libraries for
-advanced users/programmers:
-
-* :tt:`medcouplingcorba`: this library is designed for cross process
- exchange of medcoupling objects.
-* :tt:`medpartitioner`: this library provides functions to split a MED
- domain in several part in the perspective of parallel computing
-
-All these atomic C++ libraries are wrapped into a set of python
-modules (using the swig binding technology) so that all the data
-processing can be realized by scripting.
-
-.. warning:: It could happen that some parts of the C++ libraries are
- not wrapped into python modules. This coverture will be
- extend on demand and if the integrity of the concepts is
- preserved.
-
-Main concepts of the MEDMEM library
-===================================
-
-.. warning:: TODO avec Antony. Présenter les structure de données de
- MEDCoupling principalement. Describe the MEDMEM data
- model, the typical content of a med file, the types of
- cell that compose the meshes, the types of spatial
- discretization of fields, ...
-
-Basic usages of the MEDMEM library
-==================================
-
-This section illustrates the usage of main features of the MEDMEM
-library using python examples. The usage of python is just to have a
-light syntax that makes more easy the first understanding.
-
-.. note:: All code examples here after are parts of the tutorial use
- cases located in the folder :tt:`src/MEDOP/tut` in the MED
- source directory. These use cases are all working executable
- programs and they can be used to initiate your own script.
-
-Preparing the shell environment
--------------------------------
-
-We make the hypothesis here that the MEDMEM library is installed using
-the SALOME procedure and then is located in the MED module
-installation directory. In addition to the MED library, the third
-party softwares required for executing the examples are: python, hdf5
-and med-fichier. Then, you should prepare your shell environment
-with a set of instructions that looks like::
-
- #------ python ------
- export PYTHONHOME=</path/to/python>
- export PYTHONSTARTUP=${PYTHONHOME}/pythonrc.py
- export PYTHON_INCLUDE=${PYTHONHOME}/include/python2.6
- export PATH=${PYTHONHOME}/bin:${PATH}
- export LD_LIBRARY_PATH=${PYTHONHOME}/lib:${LD_LIBRARY_PATH}
-
- #------ hdf5 ------
- HDF5HOME=</path/to/hdf5>
- export PATH=${HDF5HOME}/bin:$PATH
- export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH}
- export HDF5_DISABLE_VERSION_CHECK=1
-
- #------ med ------
- MED2HOME=</path/to/med>
- export PATH=${MED2HOME}/bin:${PATH}
- export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH}
-
- #------ medmem ---
- MED_ROOT_DIR=<path/to/salome_med_module>
- export LD_LIBRARY_PATH=${MED_ROOT_DIR}/lib/salome:${LD_LIBRARY_PATH}
- PYTHONPATH=${MED_ROOT_DIR}/lib/python2.6/site-packages/salome:${PYTHONPATH}
- PYTHONPATH=${MED_ROOT_DIR}/bin/salome:${PYTHONPATH}
- PYTHONPATH=${MED_ROOT_DIR}/lib/salome:${PYTHONPATH}
- export PYTHONPATH
-
-Example 01: Explore a med file to get information concerning meshes and fields
-------------------------------------------------------------------------------
-
-:objectives: This example illustrates how to get information
- concerning meshes and fields from a med file, using the
- MEDLoader library.
-
-The loading of meshes and fields from a med file to a MEDCoupling data
-structure requires first the knowledge of metadata associated to these
-meshes and fields. You have to know the names of the meshes, so that
-you can specify the one you want to load, and then the names of the
-fields associated to one given mesh, the space discretizations used
-for each field, and the iterations available.
-
-The MEDLoader library can read these metadata without loading the
-physical data that compose the meshes and fields. This feature ensures
-the performance of the exploration process, in particular in the case
-of big meshes.
-
-This first instruction looks for meshes embedded in the med file
-(located by :tt:`filepath`) and returns the list of mesh names:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-.. WARNING: Note that the file path for the include directive must be
- relative to this rst source file (i.e. as organized in the MED
- source directory, and nevertheless the build procedure is realized
- elsewhere.
-
-Then, you may select one of these names (or iterate on all names of
-the list) and read the list of fields defined on this mesh:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-A field name could identify several MEDCoupling fields, that differ by
-their spatial discretization on the mesh (values on cells, values on
-nodes, ...). This spatial discretization is specified by the
-TypeOfField that is an integer value in this list:
-
-* :tt:`0 = ON_CELLS` (physical values defined by cell)
-* :tt:`1 = ON_NODES` (physical values defined on nodes)
-* :tt:`2 = ON_GAUSS_PT` (physical values defined on Gauss points)
-* :tt:`3 = ON_GAUSS_NE`
-
-.. note:: This constant variables are defined by the MEDLoader module
- (:tt:`from MEDLoader import ON_NODES`).
-
-As a consequence, before loading the physical values of a field, we
-have to determine the types of spatial discretization that come with
-this field name and to choose one of this types. The instruction below
-read all the spatial discretization types available for the field of
-name :tt:`fieldName` defined on the mesh of name :tt:`meshName`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Once you have selected the spatial discretization of interest (called
-:tt:`typeOfDiscretization` in the code below, that corresponds to an
-item of the list :tt:`listOfTypes`), you can extract the list of time
-iterations available for the identified field:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T4A
- :end-before: # _T4B
-
-The iterations can be weither a list of time steps for which the field
-is defined (a timeseries) or a list of frequency steps (spectral
-analysis). In any case, an iteration item consists in a couple of
-integers, the first defining the main iteration step and the second an
-iteration order in this step, that can be consider as a sub-iteration
-of the step. In most of cases, the iteration order is set to :tt:`-1`
-(no sub-iterations).
-
-The field values can now be read for one particular time step (or
-spectrum tic), defined by the pair (iteration number, iteration
-order). This is illustrated by the example here after.
-
-Example 02: Load a mesh and a field from a med file
----------------------------------------------------
-
-:objectives: This illustrates how to load the physical data of a
- specified mesh and a specified field.
-
-The metadata read from a med file are required to identify the list of
-meshes and fields in the med file. We assume in this example that the
-mesh and field to load are identified, i.e. we know the name of the
-mesh to load (:tt:`meshName`) and the characteristic properties of the
-field to load (:tt:`fieldName`, :tt:`typeOfDiscretization` and
-:tt:`iteration`). For example, the instruction below load the mesh of
-name :tt:`meshName`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T5A
- :end-before: # _T5B
-
-and the instruction below load the field with name :tt:`fieldName`
-defined on this mesh at a particular iteration step characterized by
-the couple :tt:`(iterationNumber,iterationOrder)`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T6A
- :end-before: # _T6B
-
-The variables :tt:`mesh` and :tt:`field` in this code example are instances of
-the MEDCoupling classes describing the meshes and fields.
-
-Note that the read functions required the parameter
-:tt:`dimrestriction`. This parameter discreminates the mesh dimensions you
-are interested to relatively to the maximal dimension of cells
-contained in the mesh (then its value could be 0, -1, -2 or -3
-depending on the max dimension of the mesh). A value of
-:tt:`dimrestriction=0` means "no restriction".
-
-Example 03: Manage the MEDCoupling data load from a med file
-------------------------------------------------------------
-
-:objectives: Some suggestions for the MEDCoupling objects management,
- in a programming context.
-
-In a real programming case, it could be relevant to explore first the
-med file to load all metadata concerning the whole set of meshes and
-associated fields, and then to load the physical data only once when
-required by the program.
-
-Such a programming scenario required that you keep all metadata in
-data structures created in memory, so that you can manage the
-collection of meshes and fields. Nevertheless, the MEDMEM library
-does not provide such data structures.
-
-We suggest to work with a simple list concept to store the metadata
-for each mesh entry and each field entry. Note that a mesh entry is
-characterized by the mesh name only, while a field entry is
-charaterized by the following attributes:
-
-* :tt:`fieldName`: the name of the field
-* :tt:`meshName`: the name of the mesh that supports the field
-* :tt:`typeOfDiscretization`: the type of spatial discretization
-* :tt:`iteration`: a couple of integers :tt:`(iter,order)` that
- characterizes the step in a serie (timeseries or spectrum).
-
-By default, we suggest to work with a simple map concept (dictionnary in a
-python context, map in a C++ context) to register the meshes and
-fields loaded from the med file for each metadata entry.
-
-Then, depending on the processing algorithm you intend to implement,
-you may dispatch the data in a tree structure that fit your specific
-case, for performance reasons. For example, the following code
-illustrates how to dispatch the metadata in a tree data structure
-where leaves are the physical data (field objects). We first have to
-define a tree structure (basic definition in htis simple case, but it
-works fine):
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-Then, we can scan the med structure and dispatch the metadata in the
-tree structure:
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-Finally (and afterwards), we can display on standard output the
-metadata registered in the tree structure:
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Example 04: Simple arithmetic operations with fields
-----------------------------------------------------
-
-:objectives: This example illustrates how to load field iterations
- from a med file containing a field timeseries and shows
- how to use these iterations in simple arithmetic
- operations.
-
-We consider a med file :tt:`timeseries.med`, containing one single
-mesh named :tt:`Grid_80x80` that supports a field with values defined
-on nodes (:tt:`typeOfDiscretization=ON_NODES`) given for ten
-iterations.
-
-This first code block identifies the mesh and the field to consider in
-this example:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-The following instructions load the field, make a scaling on the
-physical values (multiply by 3) and then save the result in an output
-med file named :tt:`scaling.med`:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-Note the usage of the method :tt:`applyFunc` that takes in argument a
-string expression that defined the mathematical function to apply on
-the values of the fields. In this expression, the field is symbolized
-by the letter :tt:`f`.
-
-The following set of instructions makes the addition of iteration
-number 3 with iteration number 4 of the field. Note that this
-operation required first to load the mesh:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Exemple 05: Compare fields load from different files
-----------------------------------------------------
-
-:objectives: Illustrates the usage of the function
- changeUnderlyingMesh
-
-Exemple 06: Create a field from scratch on a spatial domain
------------------------------------------------------------
-
-:objectives: Illustrates the applyFunc method of fields
-
-Exemple 07: Manipulate structured mesh
---------------------------------------
-
-:objectives: Illustrates the basic usage of the advanced interface of
- MEDLoader.
-
-The MEDLoader frontal interface let you load unstructured meshes:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T5A
- :end-before: # _T5B
-
-That is to say that even if the mesh is a structured mesh (a grid mesh
-for example), then you will get a MEDCoupling unstructured mesh
-object.
-
-To manipulate structured mesh objects, you have to use the MEDLoader
-backend interface named :tt:`MEDFileMesh`, or its derivative
-:tt:`MEDFileUMesh` for unstructured meshes, and :tt:`MEDFileCMesh` for
-structured meshes (CMesh for Cartesian Mesh). The code below
-illustrates how to load a mesh using the :tt:`MEDFileMesh` interface,
-and to know if it is a structured mesh:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-This second example can be used in the case where you know in advance
-that it is a structured mesh:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-In any cases, you can also save the mesh in another file with the
-methode :tt:`write` of the :tt:`MEDFileMesh` object:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Exemple 08: Make a projection of a field
-----------------------------------------
-
-:objectives: Make the projection of a field from a source mesh to a
- target meshe. The source mesh and the target mesh are
- two different mesh of the same geometry.
-
-The input data of this use case are:
-
-* a source mesh, and a field defined on this source mesh (left side of
- the figure below)
-* a target mesh, on which we want to project the field (right side of
- the figure below)
-
-.. note:: The two meshes are displayed side by side on the figure for
- convenience reason, but in the real use case they stand at
- the same location in 3D space (they describe the same
- geometry).
-
-.. image:: images/medop_projection_inputs.png
- :align: center
-
-The expected result is a field defined on the target mesh and which
-corresponds to a physical data equivalent to the source field,
-i.e. with conservation of some physical properties. This operation
-requires the usage of interpolation algorithms provided by the
-:tt:`medcouplingremapper` library:
-
-.. include:: ../../tut/projection/demomed/demo_loadsource.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-Some comments on this code:
-
-* The physical property to be preserved by this interpolation is
- specified using the keyword :tt:`ConservativeVolumic`
-* The parameter :tt:`P0P0` given at the preparation step of the
- remapper specifies that the interpolation is done from CELLS (P0) to
- CELLS (P0).
-* The interpolation, strictly speaking, is performed by the
- instruction :tt:`ftarget =
- remap.transferField(fsource,defaultValue)`
-* In this instruction, the :tt:`defaultValue` is used to set the target value
- in the case where there is no cell in the source mesh that overlap
- the target mesh (for example when the source mesh correspond to a
- geometrical sub-part of the target mesh).
-
-When executing the :tt:`remapper`, the result is a new field defined on
-the target mesh, as illustrated on the figure below:
-
-.. image:: images/medop_projection_result.png
- :align: center
-
-Exemple 09: Make a partition of a mesh using a field
-----------------------------------------------------
-
-:objective: This illustrates how to make a mesh partition using the
- value of a field defined on this mesh.
-
-The input data is a MEDCoupling scalar field (:tt:`field`) defined on
-a 3D mesh, and we want to use this field as a criterium to make a
-partition of the mesh, for example by creating the mesh surface that
-delimits the volumes where the field value is greater that a limit L
-(and conversely the volumes where the field value is lower).
-
-.. image:: images/partition_mesh.png
- :align: center
-
-The code below shows the simplest way to extract the cells where
-:tt:`field>L` and to create the skin mesh:
-
-.. include:: ../../tut/medcoupling/partition.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-At the end, the variable :tt:`skin` is a 2D mesh that can be saved in
-a med file using the MEDLoader:
-
-.. image:: images/partition_skin.png
- :align: center
-
-Advanced usages of the MEDMEM library
-=====================================
-
-This section could explain how to process the physical data
-(dataArray) and to manipulate the advanced concepts of the MEDMEM
-library.
-
-.. Exemple 01: Create a field from an image
-.. ----------------------------------------
-
+++ /dev/null
-.. meta::
- :keywords: mesh, field, manipulation, user guide
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-MED module: User guide for graphical interface
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-This document is a quick guide for Graphical User Interface of MED module. It
-shows how to use this module on the basis of a few reference examples, built
-from use cases identified during requirement analysis stage.
-
-.. warning:: This document is self-contained, but it is strongly advised to
- read :doc:`the specification document<medop-specifications>` (in
- french), at least to clarify concepts and terminology.
-
-.. contents:: Contents
- :local:
- :backlinks: none
-
-.. warning:: Screenshots are not up-to-date. They were extracted from SALOME
- 6 with data visualization achieved using VISU module. In SALOME
- 7, VISU module has been replaced by PARAVIS module. The
- look-and-feel may thus be slightly different.
-
-General presentation of MED module
-==================================
-
-The overall ergonomics of MED module for field manipulation is inspired by
-softwares such as octave or scilab. It combines a graphical interface (GUI) to
-select and prepare data, with a textual interface (the python console, TUI)
-for actual work on data.
-
-This module provides two user environments that are marked by the red and
-green rectangles on the screenshot below:
-
-* **The data space** (*dataspace*), in which user defines the MED data sources
- (*datasource*), that is to say the med files from which meshes and fields
- are read. This data space allows for the exploration of meshes and fields
- provided by the different data sources.
-* **The workspace** (*workspace*), in which user may drop fields selected in
- the source space, and then use them for example to produce new fields using
- the operations on fields provided by the TUI.
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-A typical use of field manipulation functions is:
-
-1. Load a med file in the data space and explore its contents: meshes and
- fields defined on these meshes, defined for one or several time steps.
-2. Select (using GUI) fields to be manipulated in workspace ; it is possible
- to introduce restrictions on time steps, components or groups of cells.
-3. Create new fields executing algebraic operations (+,-,*,/) on fields,
- applying simple mathematical functions (pow, sqrt, abs), or initializing
- them "from scratch" on a support mesh.
-4. Visually control produced fields, using PARAVIS module in SALOME,
- automatically controlled from user interface.
-5. Save (parts of) produced fields to a med file.
-
-
-Quick tour on functions available in MED module
-===============================================
-
-This section presents some use examples of MED module like a "storyboard",
-illustrating the functions proposed by the module.
-
-.. warning:: This section is under construction. Please consider that its
- contents and organization are still incomplete and may change
- until this warning is removed.
-
-Example 1: Explore data sources
--------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * add a data source
- * "Extends field series" and "Visualize" functions
-
-.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
- :height: 16px
-
-.. |ICO_XMED| image:: images/ico_xmed.png
- :height: 16px
-
-.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
- :height: 16px
-
-.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
- :height: 16px
-
-At startup the field manipulation module, identified by icon |ICO_XMED|, shows
-an empty interface:
-
-.. image:: images/xmed-gui-start.png
- :align: center
- :width: 800px
-
-The first step consists in adding one or several med data sources in
-"dataspace". For this, user clicks on icon "Add datasource"
-|ICO_DATASOURCE_ADD| to select a med file:
-
-.. image:: images/xmed-gui-datasource-selectfile.png
- :align: center
- :width: 800px
-
-This operation adds a new entry (datasource) in data space. The contents can
-be explored using the data tree. The figure below (left image) shows the
-result of loading the file ``timeseries.med`` containing a mesh named
-``Grid_80x80`` on which a field on nodes named ``Pulse`` is defined. By
-default, the field composition (in terms of time steps and components) is not
-displayed to avoid visual congestion of data tree. User must explicitly ask
-for visualization using the command "Expand field timeseries"
-|ICO_DATASOURCE_EXPAND| available in the field contextual menu. The result is
-displayed on center image. The list of field ``Pulse`` iterations can be advised.
-
-.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
- :height: 340px
-
-+--------------------------+--------------------------+--------------------------+
-| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
-+--------------------------+--------------------------+--------------------------+
-
-.. note:: Strictly speaking, the *field* concept in MED model corresponds to
- a given iteration. A set of iterations is identified by the term
- *field time series*. If there is no ambiguity, the field name will
- refer to both the field itself or the time series it belongs to.
-
-Finally, it is possible from dataspace to visualize the field general shape
-using a scalar map displayed in SALOME viewer. For this, user selects the time step to
-display then uses the command "Visualize" |ICO_DATASOURCE_VIEW| available in
-the associated contextual menu:
-
-.. image:: images/xmed-gui-datasource-visualize-zoom.png
- :align: center
- :width: 800px
-
-.. note:: This graphical representation aims at providing a quick visual
- control. Scalar maps are displayed using the PARAVIS module.
-
-Example 2: Combine fields from different sources
-------------------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * function "Use in workspace"
- * function "Save"
-
-.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
- :height: 16px
-.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
- :height: 16px
-
-The objective is to access data contained in several med files, then to
-combine them in the same output file.
-
-User starts by adding med data sources in dataspace. In the example below,
-dataspace contains two sources names ``parametric_01.med`` and
-``smallmesh_varfiled.med``. The first one contains the mesh ``Grid_80x80_01``
-on which the field ``StiffExp_01`` is defined. The second source contains the
-mesh ``My2DMesh`` on which the two fields ``testfield1`` are ``testfield2``
-are defined:
-
-.. image:: images/xmed-userguide-example2-datasource.png
- :align: center
- :width: 800px
-
-In this example, ``StiffExp_01`` and ``testfield2`` are combined then saved to
-``result.med`` file. The procedure consists in importing the two fields in
-workspace, then to save the workspace. For this user selects the fields and
-uses the command "Use in workspace" |ICO_DATASOURCE_USE| available in the
-contextual menu. Both selected fields appear in the workspace tree:
-
-.. image:: images/xmed-userguide-example2-workspace.png
- :align: center
- :width: 800px
-
-Workspace is saved using the command "Save workspace" |ICO_WORKSPACE_SAVE|
-available in the module toolbar. A dialog window lets user set the save
-file name:
-
-.. image:: images/xmed-userguide-example2-workspace-save.png
- :align: center
- :width: 800px
-
-The file ``result.med`` can then be reloaded in MED module (or PARAVIS module)
-to check the presence of saved fields.
-
-.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
-.. (invalid mesh on field)
-
-.. _xmed.userguide.exemple3:
-
-Example 3: Apply a formula on fields
-------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * execute mathematical operations in TUI console
- * function "put" to refer to a work field in the list of persisting fields.
- * function "Visualize" from TUI.
-
-The most common usage of field manipulation module is to execute mathematical
-operations on fields or on their components.
-
-Assume data sources are already defined in dataspace (in the following example
-a temporal series named ``Pulse`` contains 10 time steps defined on a mesh
-named ``Grid_80x80``, all read from ``timeseries.med`` data source).
-
-As previously seen, a field can be manipulated in workspace after selecting
-the field and applying the command "Use in
-workspace" |ICO_DATASOURCE_USE| from contextual menu. Here only one file is
-selected (two in the previous example) and the command then opens a dialog
-window to select data to work on and the way they will be manipulated:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
- :align: center
- :width: 800px
-
-.. note:: In the current state of development, the interface only propose to
- define the name of a variable representing the field in TUI. In
- a next version, user will have the possibility to specify the field
- component(s) to be used and a group of cells to introduce
- a geometrical restriction. Conversely it will be possible to select
- a complete time series to apply global operations on all time steps.
-
-After validation, the field if put in workspace tree and a variable
-``<alias>`` is automatically created in the TUI to designate the field. In
-this example, ``<alias>`` is ``f3``, as set by user to recall that variable
-corresponds to the third time step:
-
-.. image:: images/xmed-gui-workspace.png
- :align: center
- :width: 800px
-
-Field manipulation can start. In the example below, use creates the field``r``
-as the result of an affine transformation of field ``f3`` (multiplication of
-field by a scale factor 2.7 then addition of offset 5.2)::
-
- >>> r=2.7*f3+5.2
-
-Other operations can be applied, as detailed in module specifications
-(cf. :ref:`Spécification des opérations<xmed-specifications>`):
-
- >>> r=f3/1000 # the values of r are the ones of f3 reduced by a factor 1000
- >>> r=1/f3 # the values of r are the inverted values of f3
- >>> r=f3*f3 # the values of r are the squared values of f3
- >>> r=pow(f3,2) # same result
- >>> r=abs(f3) # absolute value of field f3
- >>> ...
-
-The two operands can be fields. If ``f4`` is the fourth time step of field
-``Pulse``, then algebraic combinations of fields can be computed::
-
- >>> r=f3+f4
- >>> r=f3-f4
- >>> r=f3/f4
- >>> r=f3*f4
-
-Scalar variables can be used if needed::
-
- >>> r=4*f3-f4/1000
- >>> ...
-
-In theses examples, the variable ``r`` corresponds to a work field containing
-the operation result. By default the field is nor referenced in workspace
-tree. If user wants to add it, for example to make it considered when saving,
-then the following command is used::
-
- >>> put(r)
-
-The function ``put`` aims at tagging the field as persisting, the to store it
-in the workspace tree to make it visible and selectable. Among all fields that
-could be created in console during the work session, all do not need to be
-saved. Some may only be temporary variables used in the construction of final
-fields. That is why only fields in workspace tree are saved when saving the
-workspace.
-
-Variables defined in console have other uses. First they allow for printing
-information relative to the manipulated field. For this one enters the
-variable name then validates::
-
- >>> f3
- field name (id) = Pulse (3)
- mesh name (id) = Grid_80x80 (0)
- discretization = ON_NODES
- (iter, order) = (3,-1)
- data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
-
-Second, variables can be used as command arguments (the list of commands
-available in TUI is described in section :ref:`Documentation of textual
-interface<xmed.userguide.tui>`). For example the function ``view`` displays
-the field scalar map in the viewer::
-
- >>> view(f3)
-
-Results in:
-
-.. image:: images/xmed-gui-workspace-view.png
- :align: center
- :width: 800px
-
-.. note:: It is easy to compare two time steps of a field, computing the
- difference ``f3-f4``, then producing a scalar map preview using the
- function ``view``::
-
- >>> view(f3-f4)
-
-Finally the field data can be displayed using the command``print``::
-
- >>> print f3
- Data content :
- Tuple #0 : -0.6
- Tuple #1 : -0.1
- Tuple #2 : 0.4
- Tuple #3 : -0.1
- Tuple #4 : 0.4
- ...
- Tuple #6556 : 3.5
- Tuple #6557 : 3.3
- Tuple #6558 : 1.5
- Tuple #6559 : 0.3
- Tuple #6560 : 0.2
-
-It is important to note that operations between fields can only be applied if
-fields are defined on the same mesh. It corresponds to a specification of MED
-model that forbids operations between fields defined on meshes geometrically
-different. Technically it means that the conceptual objects *fields* must share
-the same conceptual object *mesh*.
-
-If user do want to use fields defined on different meshes, for example to
-manipulate the field values at the interface of two meshes sharing a 2D
-geometrical area, it is necessary first to make all fields be defined on the
-same surface mesh using a projection operation.
-
-.. note:: Such projection operations are available in the MEDCoupling library.
-
-Another classical need is using fields defined on meshes geometrically
-identical, but technically different for example when they are loaded from
-different med files. For such a case, the MEDCoupling library proposes
-a function "Change support mesh" ; its use in field manipulation module is
-illustrated in :ref:`example 4<xmed.userguide.exemple4>` described hereafter.
-
-.. _xmed.userguide.exemple4:
-
-Example 4: Compare fields derived from different sources
---------------------------------------------------------
-
-.. note:: This example illustrates the following function:
-
- * Change the underlying (support) mesh
-
-Assume here that fields have been defined on same mesh, geometrically
-speaking, but saved in different med files. This occurs for example for
-a parametric study in which several computations are achieved with variants on
-some parameters of the simulated model, each computation producing a med file.
-
-Let ``parametric_01.med`` and ``parametric_02.med`` be two med files
-containing the fields to compare, for example computing the difference of
-their values and visualizing the result.
-
-After loading data sources user sees two meshes, this time from the technical
-point of view, that is to say fields are associated to different conceptual
-mesh objects, while geometrically identical.
-
-However field manipulation functions do not allow operations on fields lying
-on different support meshes (see remark at the end of :ref:`example
-3<xmed.userguide.exemple3>`).
-
-To circumvent this issue, the module offers the function "Change underlying
-mesh" to replace a field mesh support by another, provided that the two meshes
-are geometrically identical, that is to say nodes have the same spatial
-coordinates.
-
-.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
- :height: 16px
-
-In the proposed example, user selects the first time step of field
-``StiffExp_01`` in data source ``parametric_01.med``, and imports it in
-workspace using the command "Use in workspace" |ICO_DATASOURCE_USE|. User then
-selects the first time step of field ``StiffExp_02`` in data source
-``parametric_02.med``, but imports it in workspace using the command "Change
-underlying mesh" |ICO_DATASOURCE_CHG|. The following dialog window appears to
-let user select the new support mesh in dataspace tree:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
- :align: center
-
-In this example, the support mesh ``Grid_80x80_01`` of field ``StiffExp_01``
-to compare with is selected. After validation the workspace tree contains the
-field ``StiffExp_02`` defined on mesh ``Grid_80x80_01``:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
- :align: center
-
-.. note:: The function "Change underlying mesh" does not modify the field
- selected in dataspace (basic running principle of dataspace), but
- creates a field copy in workspace to then change support mesh. This
- explains the default name for field ``dup(<name of selected
- field>)`` (dup stands for "duplicate").
-
-All we have to do now is to associate a variable to this field, in order to
-manipulate it in TUI. This can be done using the command "Use in console"
-available in workspace contextual menu.
-
-Finally, if ``f1`` is a field from datasource ``parametric_01.med`` and ``f2``
-is a field from datasource
-``parametric_02.med`` according to the above procedure, then comparison values
-can be achieved as explained in :ref:`example 3<xmed.userguide.exemple3>`::
-
- >>> r=f1-f2
- >>> view(r)
-
-.. note:: As a general remark concerning this example, one may note:
-
- * the geometrical equality of two meshes is constrained to a numerical
- error that can be technically set, but not through the module interface.
- This tolerance is empirically set to a standard value regarding to
- success of most of the use cases. The usefulness of setting this value in
- the interface could be later investigated.
-
- * User must explicitly ask for changing a field support mesh, in order to
- compare fields coming from different data sources. This choice has been
- made to keep trace of modifications made on data (no modification is made
- without user knowing, even to improve ergonomics).
-
-
-Example 5: Create a field on a spatial domain
----------------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * initialize with function of spatial position
- * initialize on a group of cells
-
-The geometrical domain on which the field to create is defined is here given
-by cell group data. This use case is provided for producing initial load
-conditions of a structure, for example defining a field on a geometry surface
-identified by a group of cells.
-
-.. warning:: DEVELOPMENT IN PROGRESS
-
-Example 6: Extract a field part
--------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * extract a component (or a subset of components)
- * extract a geometrical domain (values on a group of cells)
- * extract one or several time steps
-
-.. warning:: DEVELOPMENT IN PROGRESS
-
- Here the restriction functions that allow to get some components only, have
- to be illustrated. The principle is creating a new field that is
- a restriction of input field to a list of given components (use the
- function __call__ of fieldproxy).
-
-For time step extraction, we can reduce to the case of example 2 with a single
-data source.
-
-Example 7: Create a field from a to[mp]ographic image
------------------------------------------------------
-
-.. note:: This example illustrates the following function:
-
- * Create a field without data source (neither mesh nor field), from an
- image file
-
-In tomography or topography studies, measurement devices produce images that
-represent a physical quantity using gray levels on a given cutting plane. The
-following image represents for example a internal view of human body obtained
-by MRI:
-
-.. image:: images/xmed-irm.png
- :align: center
- :width: 600px
-
-This image is a subset of pixels organized on a Cartesian grid. It can thus be
-represented as a scalar field whose values are defined on cells of a mesh
-having the same dimension as the image (number of pixels):
-
-.. image:: images/xmed-irm-field.png
- :align: center
- :width: 600px
-
-The field manipulation module provides a tool named ``image2med.py`` to
-convert a file image to a med file containing the image representation as
-a scalar field (only the gray level is kept)::
-
- $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
-
-.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
- :height: 16px
-
-This conversion operation can be automatically achieved using the command "Add
-Image Source" |ICO_IMAGESOURCE| available in GUI toolbar. This command opens
-the following window to let user select a file image:
-
-.. image:: images/medop_image2med_dialog.png
- :align: center
-
-The name of result med file is set by default (changing file extension to
-``*.med``) but can be modified. Finally user can ask for automatic load of
-this med file in data space. Fields can then be manipulated like presented in
-the standard use cases.
-
-For example, the image below depicts the result of the difference between two
-images, added to the reference image: if i1 and i2 are the fields created from
-these two images, then ``r = i1 + 5*(i2-i1)`` with 5 an arbitrary factor to
-amplify the region of interest (above the left eye):
-
-.. image:: images/xmed-irm-diff.png
- :align: center
- :width: 600px
-
-The example below is the result of loading a tomographic image courtesy of MAP
-project (Charles Toulemonde, EDF/R&D/MMC). The tomographic image:
-
-.. image:: images/champ_altitude_MAP.png
- :align: center
- :width: 600px
-
-The result of loading:
-
-.. image:: images/medop_image2med_tomographie.png
- :align: center
- :width: 800px
-
-Example 8: Continue analysis in PARAVIS
----------------------------------------
-
-.. note:: This example illustrates the following functio:
-
- * Export fields to PARAVIS module
-
-The solutions for field representation in MED module aims at proposing a quick
-visual control.
-
-For a detailed analysis of fields, user shall switch to PARAVIS. The field
-manipulation module has a function to facilitate this transition, with
-automatic load in PARAVIS and proposing a default visualization (scalar map).
-
-For this user selects in workspace the fields to export, then call the export
-function from contextual menu:
-
-.. image:: images/medop_exportparavis.png
- :align: center
-
-Selected fields are grouped in a single MED entry in PARAVIS, and the first
-field is depicted as a scalar map:
-
-.. image:: images/medop_exportparavis_result.png
- :align: center
- :width: 800px
-
-.. note:: The export function is a convenience function. The same operation
- can be manually achieved, first saving fields to a med file then
- loading the created file in PARAVIS module for visualization.
-
-.. _xmed.userguide.tui:
-
-Using the textual interface (TUI)
-=================================
-
-All operations driven through GUI can be done (more or less easily) using TUI.
-The field manipulation module can even be used exclusively in textual mode.
-For this run the command::
-
- $ <path/to/appli>/medop.sh
-
-This command opens a command console ``medop>``. A med file can be loaded and
-manipulated, for example to create fields from file data.
-
-Whatever textual or graphical mode is used, a typical workflow in console
-looks like the following instructions::
-
- >>> load("/path/to/mydata.med")
- >>> la
- id=0 name = testfield1
- id=1 name = testfield2
- >>> f1=get(0)
- >>> f2=get(1)
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- >>> r=f1+f2
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=testfield1+testfield2)
- >>> r.update(name="toto")
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=toto)
- >>> put(r)
- >>> save("result.med")
-
-The main commands are:
-
-* ``load``: load a med file in data base (useful in pure textual mode)::
-
- >>> load("/path/to/datafile.med")
-
-* ``la``: show the list of all fields loaded in data base ("list all")
-* ``get``: set a field in workspace from its identifier (useful in pure
- textual mode ; this operation can be done in GUI selecting a field from data
- space).::
-
- >>> f=get(fieldId)
-
-* ``ls``: show the list of fields available in workspace ("list")
-* ``put``: put a reference to a field in *management space*::
-
- >>> put(f)
-
-* ``save``: save to a med a file all fields referenced in management space::
-
- >>> save("/path/to/resultfile.med")
-
-.. note::
-
- * the ``load`` command only loads metadata describing meshes and fields
- (names, discretization types, list of time steps). Meshes and physical
- quantities on fields are loaded later (and automatically) as soon as an
- operation needs them. In all cases med data (mete-information and values)
- are physically stored in *data base* environment.
- * the ``get`` command defines a *field handler* in workspace, i.e.
- a variable that links to the physical field hosted in data base. Physical
- data never transit between environments but remain centralized in data
- base.
-
-The following TUI commands need to work in graphical environment:
-
-* ``visu``: display a field map for quick visual control (no parametrization
- is possible)
-
- >>> view(f)
-
-
-
-.. LocalWords: softwares
:keywords: maillage, champ, manipulation
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ANNEXE: Note de travail concernant le chantier XMED 2011
-------------------------------------
Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
+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
est posé dans le WS. On peut donc proposer en option de lui associer
un alias pour manipulation dans la console
-
-
+
+
:keywords: maillage, champ, manipulation
:author: Guillaume Boulant
-.. include:: medop-definitions.rst
+.. include:: medcalc-definitions.rst
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
ANNEXE: Note de travail concernant le chantier XMED 2012
* Eliminer la dépendance à XSALOME
* Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine
-.. warning:: TODO: refaire le point sur les tâches initiées en 2011
+.. warning:: TODO: refaire le point sur les tâches initiées en 2011
