KERNEL_WITH_CORBA() #check whether KERNEL builded with CORBA
ADD_DEFINITIONS(${KERNEL_DEFINITIONS})
INCLUDE_DIRECTORIES(${KERNEL_INCLUDE_DIRS})
- SET(_default_MPI ${SALOME_USE_MPI})
+ SET(_default_MPI ${SALOME_USE_MPI})
ELSE(EXISTS ${KERNEL_ROOT_DIR})
MESSAGE(FATAL_ERROR "We absolutely need a Salome KERNEL, please define KERNEL_ROOT_DIR or turn option SALOME_MED_STANDALONE to ON !")
ENDIF(EXISTS ${KERNEL_ROOT_DIR})
SET(SALOME_INSTALL_LIBS lib/salome CACHE PATH "Install path: SALOME libs")
SET(SALOME_INSTALL_IDLS idl/salome CACHE PATH "Install path: SALOME IDL files")
SET(SALOME_INSTALL_HEADERS include/salome CACHE PATH "Install path: SALOME headers")
-SET(SALOME_INSTALL_SCRIPT_SCRIPTS ${SALOME_INSTALL_BINS} CACHE PATH
+SET(SALOME_INSTALL_SCRIPT_SCRIPTS ${SALOME_INSTALL_BINS} CACHE PATH
"Install path: SALOME scripts")
-SET(SALOME_INSTALL_SCRIPT_DATA ${SALOME_INSTALL_BINS} CACHE PATH
+SET(SALOME_INSTALL_SCRIPT_DATA ${SALOME_INSTALL_BINS} CACHE PATH
"Install path: SALOME script data")
-SET(SALOME_INSTALL_SCRIPT_PYTHON ${SALOME_INSTALL_BINS} CACHE PATH
+SET(SALOME_INSTALL_SCRIPT_PYTHON ${SALOME_INSTALL_BINS} CACHE PATH
"Install path: SALOME Python scripts")
-SET(SALOME_INSTALL_APPLISKEL_SCRIPTS ${SALOME_INSTALL_BINS}/appliskel CACHE PATH
+SET(SALOME_INSTALL_APPLISKEL_SCRIPTS ${SALOME_INSTALL_BINS}/appliskel CACHE PATH
"Install path: SALOME application skeleton - scripts")
-SET(SALOME_INSTALL_APPLISKEL_PYTHON ${SALOME_INSTALL_BINS}/appliskel CACHE PATH
+SET(SALOME_INSTALL_APPLISKEL_PYTHON ${SALOME_INSTALL_BINS}/appliskel CACHE PATH
"Install path: SALOME application skeleton - Python")
SET(SALOME_INSTALL_CMAKE salome_adm/cmake_files CACHE PATH "Install path: SALOME CMake files")
-SET(SALOME_INSTALL_CMAKE_LOCAL adm_local/cmake_files CACHE PATH
+SET(SALOME_INSTALL_CMAKE_LOCAL adm_local/cmake_files CACHE PATH
"Install path: local SALOME CMake files")
IF(SALOME_MED_ENABLE_PYTHON)
SET(_pydir lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages)
SET(SALOME_INSTALL_PYTHON ${_pydir}/salome CACHE PATH "Install path: SALOME Python stuff")
- SET(SALOME_INSTALL_PYTHON_SHARED ${SALOME_INSTALL_PYTHON}/shared_modules CACHE PATH
+ SET(SALOME_INSTALL_PYTHON_SHARED ${SALOME_INSTALL_PYTHON}/shared_modules CACHE PATH
"Install path: SALOME Python shared modules")
ENDIF(SALOME_MED_ENABLE_PYTHON)
SALOME_ACCUMULATE_ENVIRONMENT(LD_LIBRARY_PATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_LIBS})
-# Sources
+# Sources
# ========
IF(WIN32)
ADD_DEFINITIONS("-D_USE_MATH_DEFINES")
LIST(APPEND _${PROJECT_NAME}_exposed_targets paramedloader)
ENDIF()
IF(NOT SALOME_MED_STANDALONE)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
+ LIST(APPEND _${PROJECT_NAME}_exposed_targets
paramedcouplingcorba paramedmemcompo)
ENDIF()
IF(SALOME_BUILD_TESTS)
IF(NOT SALOME_MED_MICROMED)
LIST(APPEND _${PROJECT_NAME}_exposed_targets ParaMEDMEMTest)
ENDIF()
- ENDIF()
+ ENDIF()
ENDIF()
IF(NOT SALOME_MED_STANDALONE)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
+ LIST(APPEND _${PROJECT_NAME}_exposed_targets
SalomeIDLMED SalomeIDLMEDTests medcouplingcorba medcouplingclient)
IF(NOT SALOME_MED_MICROMED)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets medcalculator MEDOPFactoryEngine)
+ LIST(APPEND _${PROJECT_NAME}_exposed_targets medcalculator MEDFactoryEngine)
IF(SALOME_MED_ENABLE_PYTHON)
LIST(APPEND _${PROJECT_NAME}_exposed_targets medcalculatorspython)
ENDIF()
IF(SALOME_BUILD_GUI)
IF(NOT SALOME_MED_MICROMED)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
- MEDOPGUI_dialogs MEDOPGUI)
+ LIST(APPEND _${PROJECT_NAME}_exposed_targets
+ MEDCALCGUI_dialogs MEDCALCGUI)
ENDIF()
ENDIF()
SET(XDR_ROOT_DIR "${XDR_ROOT_DIR}")
# - in the install tree:
-# Get the relative path of the include directory so
+# Get the relative path of the include directory so
# we can register it in the generated configuration files:
SET(CONF_INCLUDE_DIRS "${CMAKE_INSTALL_PREFIX}/${INSTALL_INCLUDE_DIR}")
# Build variables that will be expanded when configuring Salome<MODULE>Config.cmake:
-SALOME_CONFIGURE_PREPARE(Metis ParMetis Scotch XDR CAS Qt4 CppUnit Graphviz Doxygen Sphinx MPI omniORB
+SALOME_CONFIGURE_PREPARE(Metis ParMetis Scotch XDR CAS Qt4 CppUnit Graphviz Doxygen Sphinx MPI omniORB
PThread Boost libXml2 Python HDF5 MEDFile)
-CONFIGURE_PACKAGE_CONFIG_FILE(${PROJECT_NAME}Config.cmake.in
+CONFIGURE_PACKAGE_CONFIG_FILE(${PROJECT_NAME}Config.cmake.in
${PROJECT_BINARY_DIR}/to_install/${PROJECT_NAME}Config.cmake
INSTALL_DESTINATION "${SALOME_INSTALL_CMAKE}_LOCAL"
- PATH_VARS CONF_INCLUDE_DIRS SALOME_INSTALL_CMAKE_LOCAL CMAKE_INSTALL_PREFIX
+ PATH_VARS CONF_INCLUDE_DIRS SALOME_INSTALL_CMAKE_LOCAL CMAKE_INSTALL_PREFIX
KERNEL_ROOT_DIR GUI_ROOT_DIR MEDFILE_ROOT_DIR MPI_ROOT_DIR
HDF5_ROOT_DIR OMNIORB_ROOT_DIR PTHREAD_ROOT_DIR BOOST_ROOT_DIR
SWIG_ROOT_DIR PYTHON_ROOT_DIR CPPUNIT_ROOT_DIR GRAPHVIZ_ROOT_DIR DOXYGEN_ROOT_DIR
WRITE_BASIC_PACKAGE_VERSION_FILE(${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
VERSION ${${PROJECT_NAME_UC}_VERSION}
COMPATIBILITY AnyNewerVersion)
-
+
# Install the CMake configuration files:
INSTALL(FILES
"${PROJECT_BINARY_DIR}/to_install/${PROJECT_NAME}Config.cmake"
DESTINATION "${SALOME_INSTALL_CMAKE_LOCAL}")
# Install the export set for use with the install-tree
-INSTALL(EXPORT ${PROJECT_NAME}TargetGroup DESTINATION "${SALOME_INSTALL_CMAKE_LOCAL}"
+INSTALL(EXPORT ${PROJECT_NAME}TargetGroup DESTINATION "${SALOME_INSTALL_CMAKE_LOCAL}"
FILE ${PROJECT_NAME}Targets.cmake)
user guide can be found here:
- <a class="el" target="_new"
- href="../../dev/MED/medop-userguide-gui.html">User guide of the MED Graphical Interface</a>
+ href="../../dev/MED/medcalc-userguide-gui.html">User guide of the MED Graphical Interface</a>
As a complement, a starter guide to MEDCouplig API is available:
- <a class="el" target="_new"
- href="../../dev/MED/medop-userguide-api.html">Starter guide to MEDCoupling API for users</a>
+ href="../../dev/MED/medcalc-userguide-api.html">Starter guide to MEDCoupling API for users</a>
You could also be interested to read the software specifications and
considerations for development:
- <a class="el" target="_new"
- href="../../dev/MED/medop-specifications.html">Software
+ href="../../dev/MED/medcalc-specifications.html">Software
specifications and requirements of the MED Graphical Interface (in french)</a>
- <a class="el" target="_new"
- href="../../dev/MED/medop-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
+ href="../../dev/MED/medcalc-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
*/
MEDCalculator.idl
MEDEventListener.idl
MEDPresentationManager.idl
- MEDOPFactory.idl
+ MEDFactory.idl
)
IF(SALOME_USE_MPI)
ADD_SUBDIRECTORY(MEDCouplingCorba)
IF(NOT SALOME_MED_MICROMED)
ADD_SUBDIRECTORY(MEDCalculator)
- ADD_SUBDIRECTORY(MEDOP)
+ ADD_SUBDIRECTORY(MEDCalc)
ENDIF(NOT SALOME_MED_MICROMED)
IF(SALOME_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(MEDCouplingCorba_Swig)
--- /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(cmp)
+ADD_SUBDIRECTORY(res)
+
+IF(SALOME_BUILD_GUI)
+ ADD_SUBDIRECTORY(gui)
+ENDIF()
+
+IF(SALOME_MED_ENABLE_PYTHON)
+ ADD_SUBDIRECTORY(tui)
+ ADD_SUBDIRECTORY(exe)
+ENDIF()
+
+IF(SALOME_BUILD_DOC)
+ ADD_SUBDIRECTORY(doc)
+ENDIF(SALOME_BUILD_DOC)
--- /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_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${OMNIORB_DEFINITIONS})
+
+INCLUDE_DIRECTORIES(
+ ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
+ ${MEDFILE_INCLUDE_DIRS}
+ ${HDF5_INCLUDE_DIRS}
+ ${PTHREAD_INCLUDE_DIR}
+ ${CMAKE_CURRENT_BINARY_DIR}
+ ${PROJECT_BINARY_DIR}/idl
+ ${PROJECT_SOURCE_DIR}/src/MEDCoupling
+ ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL/Bases
+ ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL
+ ${PROJECT_SOURCE_DIR}/src/MEDLoader
+)
+
+SET(MEDFactoryEngine_SOURCES
+ MEDDataManager_i.cxx
+ MEDCalculator_i.cxx
+ MEDPresentationManager_i.cxx
+ MEDFactory_i.cxx
+)
+
+SET(COMMON_LIBS
+ medloader
+ SalomeIDLMED
+ ${KERNEL_TOOLSDS}
+ ${KERNEL_SalomeHDFPersist}
+ ${KERNEL_SalomeContainer}
+ ${KERNEL_SalomeCommunication}
+ ${KERNEL_SalomeKernelHelpers}
+ ${KERNEL_SalomeLifeCycleCORBA}
+ ${KERNEL_SALOMELocalTrace}
+ ${KERNEL_SALOMEBasics}
+ ${KERNEL_SalomeGenericObj}
+ medcoupling
+ medcouplingremapper
+ interpkernel
+ ${MEDFILE_C_LIBRARIES}
+ ${HDF5_LIBRARIES}
+ ${OMNIORB_LIBRARIES}
+ ${PLATFORM_LIBRARIES}
+)
+
+# This undefines the macros MIN and MAX which are specified in the windows headers
+IF(WIN32)
+ SET(COMMON_FLAGS "${COMMON_FLAGS} -DNOMINMAX")
+ENDIF(WIN32)
+
+ADD_LIBRARY(MEDFactoryEngine SHARED ${MEDFactoryEngine_SOURCES})
+SET_TARGET_PROPERTIES(MEDFactoryEngine PROPERTIES COMPILE_FLAGS "${COMMON_FLAGS}")
+TARGET_LINK_LIBRARIES(MEDFactoryEngine SalomeIDLMED ${COMMON_LIBS})
+
+INSTALL(TARGETS MEDFactoryEngine DESTINATION ${SALOME_INSTALL_LIBS})
+
+FILE(GLOB MEDFactoryEngine_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
+INSTALL(FILES ${MEDFactoryEngine_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+
+IF(SALOME_ENABLE_PYTHON)
+ INSTALL(FILES test_medcalc_components.py PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS}/xmed)
+ENDIF()
--- /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
+# 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
+#
+
+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}")
+
+ADD_CUSTOM_TARGET(html_docs COMMAND ${_cmd})
+
+INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target html_docs)")
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${SALOME_INSTALL_DOC}/dev/MED)
+
+SET(make_clean_files html doctrees)
+SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${make_clean_files}")
--- /dev/null
+@import url("default.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
+# -*- coding: iso-8859-1 -*-
+#
+# yacs documentation build configuration file, created by
+# sphinx-quickstart on Fri Aug 29 09:57:25 2008.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# The contents of this file are pickled, so don't put values in the namespace
+# that aren't pickleable (module imports are okay, they're removed automatically).
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys, os
+
+# If your extensions are in another directory, add it here. If the directory
+# is relative to the documentation root, use os.path.abspath to make it
+# absolute, like shown here.
+#sys.path.append(os.path.abspath('.'))
+
+# General configuration
+# ---------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = ['sphinx.ext.autodoc']
+
+# Uncomment the following line to build the links with Python documentation
+# (you might need to set http_proxy environment variable for this to work)
+#extensions += ['sphinx.ext.intersphinx']
+
+# Intersphinx mapping to add links to modules and objects in the Python
+# standard library documentation
+intersphinx_mapping = {'http://docs.python.org': None}
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = [os.path.join('@CMAKE_CURRENT_SOURCE_DIR@','_templates')]
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'MED, Manipulation de champs dans SALOME'
+copyright = '2010-2015 CEA/DEN, EDF R&D, OPEN CASCADE, G. Boulant, A. Geay'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '@SALOMEMED_VERSION@'
+# The full version, including alpha/beta/rc tags.
+release = '@SALOMEMED_VERSION@'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = 'fr'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = ['.build','ref','images','CVS','.svn']
+
+# A list of glob-style patterns that should be excluded when looking for source
+# files. They are matched against the source file names relative to the
+# source directory, using slashes as directory separators on all platforms.
+exclude_patterns = ['**/CVS']
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# Options for HTML output
+# -----------------------
+
+# The theme to use for HTML and HTML Help pages. Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+#html_theme = 'omadoc'
+html_theme_options = {
+ "stickysidebar": "false",
+ "rightsidebar": "false",
+}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = ['themes']
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+
+# 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 = '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,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = [os.path.join('@CMAKE_CURRENT_SOURCE_DIR@','_static')]
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+html_use_modindex = False
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, the reST sources are included in the HTML build as _sources/<name>.
+html_copy_source = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'medcalcdoc'
+
+
+# Options for LaTeX output
+# ------------------------
+
+latex_elements = {
+ # The paper size ('letterpaper' or 'a4paper').
+ 'papersize': 'a4paper',
+ # Select another font family
+ #'fontpkg':'\\usepackage{eucal}',
+ # get rid off blank pages
+ 'classoptions': ',openany,oneside',
+ 'babel' : '\\usepackage[english]{babel}',
+ # The font size ('10pt', '11pt' or '12pt').
+ #'pointsize': '10pt',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, document class [howto/manual]).
+latex_documents = [
+ ('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
+# the title page.
+latex_logo = os.path.join("@CMAKE_CURRENT_SOURCE_DIR@","_static","head.png")
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+latex_use_parts = True
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+latex_use_modindex = False
+
+# Definition of substitute variables for rst texts
+# ------------------------------------------------
+# The rst_epilog can be used to define variable in conf.py and use the
+# values of these variables in the rst text files.
+srcdir = '@CMAKE_CURRENT_SOURCE_DIR@'
+rst_epilog = '.. |SPHINXDOC_SRCDIR| replace:: %s' % srcdir
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ Documentation du module MED
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le module SALOME MED (pour Modèle d'Echange de Données) fournit la
+bibliothèque MEDCoupling (bibliothèque C++ dédiée à la manipulation de
+maillages et de champs conformes au modèle MED), ainsi qu'une
+interface graphique pour la réalisation des opérations de manipulation
+les plus usuelles.
+
+Documentation de référence
+==========================
+
+**Documentation d'utilisation**
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-userguide-gui.rst
+ medcalc-userguide-api.rst
+
+**Documentation technique**
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-specifications.rst
+ medcalc-develguide.rst
+
+**Documentation annexe**
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-references.rst
+
+Archives documentaires
+======================
+
+**Documentation du prototype 2010**
+
+Cette section décrit le prototype mis au point en 2010 pour les
+analyses de conception (maquette 2010 sur base MEDMEM)
+
+.. toctree::
+ :maxdepth: 1
+
+ medop-prototype-overview.rst
+ medop-prototype-develguide.rst
+ medop-prototype-medmem.rst
+
+**Journal de travail**
+
+.. toctree::
+ :maxdepth: 1
+
+ medop-workingnotes-2010.rst
+ medop-workingnotes-2011.rst
+ medop-workingnotes-2012.rst
--- /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
+.. meta::
+ :keywords: maillage, champ, manipulation, XMED
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Démonstrateur XMED, documentation technique
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Cette note fait la synthèse des développements effectués pour le
+maquettage des fonctions de manipulation de champs dans SALOME. Elle
+présente les principes retenus en matière de conception, c'est-à-dire
+concernant les mécanismes techniques sous-jacents, et en matière
+d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
+l'environnement SALOME.
+
+Ces principes sont illustrés par des développements implantés dans le
+module XMED, développé pour les besoins de l'analyse, et dans le
+module MED distribué avec la plateforme SALOME.
+
+.. note:: la lecture de ce chapitre demande une connaissance de la
+ structure de classes du module MED, en particulier la distinction
+ entre les classes ``MEDMEM::*`` et les servants CORBA associés
+ (classe ``SALOME_MED::*``).
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Principes directeurs
+====================
+
+Objectif et motivation
+----------------------
+
+L'objectif de maquettage est de trouver une architecture technique qui
+permet d'exécuter le cas d'utilisation suivant:
+
+* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
+* Sélection graphique des champs de l'étude à mettre à disposition
+ dans la console utilisateur ("calculette" en mode texte qui
+ concraitement correspond à l'interface python de SALOME).
+* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
+ entre champs avec possibilité d'utiliser des scalaires dans des
+ opérations de type transformation linéaire (y=ax+b ou y et x sont
+ des champs et a et b des scalaires). Opérations pow, sqrt.
+* Possibilité de visualiser les champs produits avec VISU pour
+ contrôle des résultats.
+* Possibilité d'exporter des champs produits dans un fichier med.
+
+Eléments de contexte
+--------------------
+
+Les opérations de manipulation de champs sont en grande partie
+implémentées dans la bibliothèque MEDMEM. Pour illustration, le
+fragment de code ci-dessous montre comment une addition de champ peut
+être opérée en python:
+
+.. code-block:: python
+
+ from libMEDMEM_Swig import MedDataManager
+ from xmed.helper import readMed, writeMed
+
+ # Load the medmem data structure from a med file
+ med = readMed("/tmp/input.med")
+ # Then create a med data manager to deal with the fields data
+ dm = MedDataManager(med)
+ # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
+ f1 = dm.getFieldDouble("testfield1",-1,-1)
+ f2 = dm.getFieldDouble("testfield2",-1,-1)
+
+ # Create a new field as the sum of f1 and f2
+ r = f1 + f2
+ # And add this new field to the med data structure
+ med.addField(r)
+
+ # Finally, write the whole data in an output med file
+ writeMed(med,"/tmp/output.med")
+
+Ceci montre que les champs peuvent être manipulés avec une interface
+relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
+f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
+package MEDMEM et wrapping python du package MEDMEM_SWIG).
+
+Par ailleurs, le fonctionnement actuel des modules SALOME qui
+manoeuvrent des données MED est d'instancier les structures de données
+MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
+servants CORBA hébergés dans le processus ``SALOME_Container``, et de
+donner accés à ces données depuis l'étude SALOME au travers de
+pointeurs CORBA. Ce choix d'architecture présente l'avantage de
+centraliser au niveau serveur la gestion du cycle de vie des données
+informatiques et de pouvoir distribuer des "poignées" pour manipuler
+ces données depuis chaque point de l'application qui sait accéder au
+bus CORBA, l'interface graphique en particulier.
+
+
+Hypothèse de travail
+--------------------
+
+Compte-tenu de l'objectif de maquettage et des éléments de contexte
+existant, on cherche une solution dans le cadre des hypothèses
+de travail suivantes:
+
+* La manipulation des champs se fait dans l'environement graphique de
+ SALOME.
+* Dans cet environnement, on souhaite pouvoir sélectionner
+ graphiquement les champs à considérer, puis manipuler ces champs
+ dans l'interface texte au moyen de variables python avec une syntaxe
+ aussi simple que celle définie dans le wrapping python de MEDMEM,
+ c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
+ pouvoir écrire f1+f2.
+* Les données MED sont physiquement dans la partie serveur de SALOME
+ et accessibles via des pointeurs CORBA (interface spécifiée dans
+ MED.idl). On exclu la recopie de données au niveau du client
+ graphique.
+
+Dans le cadre de ces hypothèses, la difficulté technique réside dans
+la mise au point d'une interface de communication entre des variables
+manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
+dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
+instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
+processus ``SALOME_Container``).
+
+
+Eléments de conception
+======================
+
+
+Implantation technique
+----------------------
+
+Le diagramme ci-dessous représente l'organisation des principaux
+paquets logiciels du module MED:
+
+.. image:: images/medmem-layers.png
+ :align: center
+
+Les cadres bleus représentent le lieu d'implantation des
+développements effectués dans le module MED pour les besoins du
+maquettage. On notera en particulier les interventions aux niveaux
+suivants:
+
+* interfaces idl: ajout de l'interface MEDOP.idl
+* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
+ l'interface MEDOP.idl
+
+Architecture technique
+----------------------
+
+Les schéma ci-dessous représente les objets informatiques qui sont à
+l'oeuvre pour la réalisation des opérations sur les champs:
+
+.. image:: /images/xmed-architecture.png
+ :align: center
+ :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
+
+On distingue les objets suivants:
+
+* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
+ MED chargée en mémoire.
+* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
+ chargés en mémoire.
+* Une instances de ``SALOME_MED::MED`` et des instances de
+ ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
+ structure med et des champs qui lui sont associés et chargés en
+ mémoire.
+* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
+ centralise la mise en oeuvre des opérations de champs sur le serveur
+ ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
+ sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
+ directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
+ de temps.
+* Des instances de ``FieldProxy`` qui correspondent aux variables
+ manipulées au niveau de l'interface graphique et qui représentent
+ les champs. Une instance de FieldProxy possède détient les
+ références des servants ``SALOME_MED::MEDOP`` et
+ ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
+ ``medop_ptr`` et ``field_ptr`` respectivement.
+* Il existe également une instance de ``MedProxy`` non représentée
+ dans ce diagramme. Cette instance correspond à une variable qui
+ permet de manipuler la structure med.
+
+.. note:: Les éléments apportés par la maquette sont les classes
+ ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
+ éléments ont pu être modifiés légèrement pour les besoins de
+ l'intégration ou pour la correction de quelques bugs.
+
+Le cycle de vie de ces objets est le suivant.
+
+Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
+des champs ``MEDMEM::FIELD``, la création est faite au moment du
+chargement du fichier med dans SALOME au moyen du module MED. A cette
+occasion, les servants CORBA associés ``SALOME_MED::MED`` et
+``SALOME_MED::FIELD`` sont créés et des références vers ces servants
+sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
+l'utilisateur dans l'interface graphique. L'ensemble de ces données
+préexiste à la manipulation de champs.
+
+Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
+``SALOME_MED::MED`` auquel ils sont associées. Le servant
+``SALOME_MED::MED`` possède une référence sur la structure
+``MEDMEM::MED`` et il la transmet à l'instance du servant
+``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
+autonome par la suite pour manipuler les données MED, et les champs en
+particulier. Le code python ci-dessous montre comment un opérateur med
+``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
+l'addition de deux champs:
+
+.. code-block:: python
+
+ 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é à
+une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
+``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
+un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
+``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
+une référence directe sur la structure ``MEDMEM::MED`` et peut la
+manoeuvrer pour demander des champs, faire des opérations avec ces
+champs, ajouter le champs résultat à la structure et enfin retourner
+un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
+
+Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
+instance de ``FieldProxy`` est un objet python qui peut être
+manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
+localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
+ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
+d'usage (cf. paragraphe ci-après). La création d'un objet
+``FieldProxy`` déclenche la création d'un opérateur med (instance de
+``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
+référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
+opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
+opérations possibles sur ce champ, comme illustrer sur l'exemple
+ci-dessus.
+
+
+Rôle des objets proxy
+---------------------
+
+Dans le modèle d'architecture présenté ci-dessus, on introduit deux
+types d'objets proxy:
+
+* Les objets de classe ``FieldProxy`` qui représentent des poignées de
+ manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
+ dans le container SALOME.
+* Les objets de classe ``MedProxy`` qui représentent des poignées de
+ manipulation des structures ``MEDMEM::MED`` physiquement instanciées
+ dans le container SALOME.
+
+Elles sont instanciées dans l'interpréteur python SALOME pour
+manipulation dans l'interface textuelle à partir de la donnée du
+pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
+champ (le nom du champ et le pas de temps défini par le numéro d'ordre
+et le numéro d'iteration:
+
+.. code-block:: python
+
+ import salome
+ salome.salome_init()
+ import SALOME_MED
+
+ medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
+ medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
+
+ from xmed import fieldproxy
+ from xmed import medproxy
+
+ f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
+ f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
+
+ field_somme = f1 + f2
+ field_offset = f1 + 5.3
+
+Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
+``field_offset`` sont des objets de classe ``FieldProxy``. Ils
+correspondent aux variables physiquement manipulées par
+l'utilisateur pour désigner les champs dans les opérations.
+
+Ces classes proxy sont conçues pour être le lieu d'implémentation de
+l'interprétation des commandes utilisateur et donc de l'ergonomie
+de manipulation des champs au niveau l'interface textuelle. Ce point
+est développé :ref:`plus bas <develguide_execFieldOperation>`.
+
+Programmation de l'interface textuelle
+--------------------------------------
+
+Dans le cadre de la maquette, l'interface de manipulation des champs
+est l'interface textuelle python intégrée à SALOME. Dans la pratique,
+l'utilisateur manipule des variables python qui correspondent à des
+objets de classe ``FieldProxy`` équipées des fonctions requises et de
+l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
+ci-dessus).
+
+Or, l'hypothèse de travail est que les données MED sont chargées dans
+SALOME et publiées dans l'étude pour point d'accés depuis l'interface
+graphique. L'utilisateur choisi un champs directement dans l'arbre
+d'étude (ou dans une interface graphique dédiée) puis demande qu'il
+soit mis à disposition dans l'interface python sous un nom de variable
+à choisir. Les captures d'écran ci-dessous montre la séquence
+graphique en images:
+
+.. |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
+lequel le champs sera manipulé dans l'interface textuelle. La
+validation de cette fenêtre doit mettre automatiquement le champ à
+disposition dans l'interface python SALOME et sous le nom de variable
+spécifié par l'alias saisi.
+
+Pour cela, il y a un couplage technique à programmer entre l'interface
+graphique et l'interface textuelle python, avec en particulier la
+transmission des pointeurs vers les servants CORBA mis en jeu dans la
+sélection.
+
+Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
+MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
+implémente l'interface graphique du module. Pour rappel, l'interface
+graphique d'un module SALOME se présente sous la forme d'une classe
+centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
+``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
+par laquelle on peut récupérer une instance de la console python
+embarquée (this->getApp()->pythonConsole()).
+
+Le code suivant illustre l'envoie d'une commande python par ce
+mécanisme. Dans cet example, on cherche à reconstituer dans le
+contexte de la console python un pointer vers un objet med instancié
+dans le contexte C++ de l'application graphique. Pour cela, on
+communique la référence de l'objet sous la forme sérialisé (IOR pour
+un objet CORBA):
+
+.. code-block:: cpp
+
+ #include <PyConsole_Console.h>
+ #include <QString>
+ #include <QStringList>
+ #include <SalomeApp_Application.h>
+
+ // 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
+
+ // Get the IOR of this object
+ QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
+
+ PyConsole_Console * pyConsole = getApp()->pythonConsole();
+
+ 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());
+ }
+
+Le code réel de la maquette est basé sur ce principe et transmet à la
+console python des lignes de commandes qui permettent de reconstruire:
+
+* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
+ champ sélectionné;
+* une instance de ``FieldProxy`` qui correspond au champ sélectionné
+ et avec pour nom de variable la valeur de l'alias saisi dans
+ l'interface graphique.
+
+Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
+par la fabrication de la liste de commandes suivante pour envoie à la
+console python par le mécanisme illustré plus haut:
+
+.. code-block:: cpp
+
+ QStringList commands;
+ commands+="from xmed.fieldproxy import getFieldFromMed";
+ commands+="from xmed.medproxy import getMedProxy";
+ commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
+ commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
+
+Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
+``iterationIndex`` sont construites à partir du champ sélectionné par
+des techniques de programmation standard dans SALOME qu'on peut
+examiner en détail dans la classe ``XMEDGUI`` (voir méthode
+``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
+chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
+
+Le point important à noter ici est que les données à transmettre
+doivent être fournies sous forme de chaînes de caractères ou de types
+simples. C'est pourquoi la référence au servant CORBA
+``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
+c'est-à-dire une chaîne de caractères qui permet l'identification de
+l'objet au niveau du bus CORBA.
+
+Au niveau de la console python cela correspond à l'exécution des
+commandes suivantes:
+
+.. code-block:: python
+
+ 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
+``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
+``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
+associée à ce servant (en fait associée au servant
+``SALOME_MED::MEDOP`` créé sur demande par le servant
+``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
+
+.. _develguide_execFieldOperation:
+
+Exécution des opérations sur le champs
+--------------------------------------
+
+Les variables définies dans l'interface textuelle pour désigner les
+champs à manipuler sont des objets de classe ``FieldProxy``.
+
+Cette classe a une propriété remarquable, elle est construite sur un
+design pattern de type "Proxy" qui pointe vers un servant
+``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
+directement au servant vers lequel il pointe, mais que l'on passe
+systématiquement par une procédure de l'objet proxy qui fait "boîte
+aux lettres":
+
+.. code-block:: python
+
+ class FieldProxy:
+
+ def __getattr__( self, name ):
+ """
+ This method realizes the proxy pattern toward the servant
+ SALOME_MED::FIELD.
+ """
+ return getattr( self.__field_ptr, name )
+
+Ce pattern permet l'implémentation de pré-traitement et/ou de
+post-traitement suivant le type d'accés que l'on cherche à faire.
+
+Il permet aussi et surtout de fournir un objet python qui présente
+l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
+operations de champs. Ici, python est ton ami, car il s'agit pour cela
+d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
+par python pour les operations entre objets. En particulier, la
+re-définition des fonctions internes ``__add__`` (opérateur addition),
+``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
+multiplication) et ``__div__`` (opérateur division) au sein de la
+classe ``FieldProxy``, permet de prendre la main sur le comportement
+des opérations algébriques et de définir une ergonomie sur mesure. Par
+exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
+(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
+réel à une variable de type FieldProxy):
+
+.. code-block:: python
+
+ class FieldProxy:
+
+ def __add__(self, operande):
+ """
+ This can process the addition of two fields or the addition of
+ a scalar to a field. It depends weither the operande is a
+ FieldProxy or a simple scalar numerical value.
+ """
+ if isinstance(operande, FieldProxy):
+ # The operande is an other field
+ otherField_ptr = operande.__field_ptr
+ rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
+ else:
+ # The operande is a scalar numerical value that must be
+ # considered as an offset in a linear transformation
+ factor = 1
+ offset = operande
+ rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
+ return FieldProxy(self.__med_ptr, rfield_ptr)
+
+Il est à noter que dans les deux cas de figure (opérande=champ ou
+opérande=scalaire), la fonction délègue la réalisation concrète de
+l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
+l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
+MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
+service de calcul (l'addition entre champs dans le premier cas,
+l'application d'une transformation linéaire de type y=factor*x+offset
+dans le deuxième cas).
+
+Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
+présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
+l'interface du servant ``SALOME_MED_MEDOP``):
+
+.. code-block:: cpp
+
+ /*! Addition of the fields f1 and f2 ( f1+f2) */
+ FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Substraction of the fields f1 and f2 (f1-f2) */
+ FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Multiplication of the fields f1 by f2 (f1*f2) */
+ FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Division of the fields f1 by f2 (f1/f2) */
+ FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Power of the field f (f^power) */
+ FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
+ /*! Linear transformation of the field f (factor*f+offset) */
+ FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
+ /*! Dublication of the field f */
+ FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
+
+Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
+module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
+``MEDMEM_I``). C'est au sein des instances de cette classe que sont
+réalisées les opérations et que sont produites physiquement les
+données. Typiquement, les opérations présentées ici produisent un
+champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
+``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
+ce servant.
+
+Ce mécanisme global peut être étendu sans limitation à tout les types
+d'opération qui sont envisagés dans les spécifications de manipulation
+des champs dans SALOME.
+
+
+Contrôle visuel des champs
+--------------------------
+
+Les illustrations ci-dessous montrent qu'une fonction de visalisation
+est implémentée dans la maquette pour permettre le contrôle visuel
+d'un champ au moyen d'une représentation 3D (une carte spatiale du
+module du champ dans l'exemple implémenté par défaut):
+
+.. |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.
+
+Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
+module VISU de faire une représentation 3D d'un champ spécifié par la
+donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
+(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
+
+.. code-block:: python
+
+ import salome
+ import VISU
+
+ visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
+ visuComp.SetCurrentStudy(salome.myStudy)
+
+ # Then we can import the specified field in the VISU module. This
+ # creates an study entry in the VISU folder.
+ result = visuComp.ImportMedField(field_ptr)
+
+ meshName = field_ptr.getSupport().getMesh().getName()
+ fieldName = field_ptr.getName()
+ iterNumber = field_ptr.getIterationNumber()
+ scalarmap = visuComp.ScalarMapOnField(result,
+ meshName,
+ visuEntityType,
+ fieldName,
+ iterNumber)
+
+Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
+particulier à cause de la non définition de la variable
+``visuEntityType``, voir remarque plus bas), le composant VISU
+désigné ici par la variable ``visuComp`` va chercher les données du
+champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
+argument de la fonction ``ImportMedField``, puis produit une
+représentation de type "scalarmap".
+
+.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
+ plus haut conférées par le pattern "Proxy", on peut transmettre ici
+ aussi bien le servant CORBA que l'instance du proxy (la fonction
+ ``ImportMedField`` n'y verra que du feu).
+
+Le code complet et fonctionnel de la fonction d'affichage est dans le
+corps du module python ``fieldproxy.py`` sous la forme d'une fonction
+de nom ``visuField``. Il convient de noter que cette fonction doit
+établir une correspondance entre le type des entités tel que défini
+dans MED et dans VISU:
+
+.. code-block:: python
+
+ medEntityType = field_ptr.getSupport().getEntity()
+ if (medEntityType == SALOME_MED.MED_CELL):
+ visuEntityType = VISU.CELL
+ elif (medEntityType == SALOME_MED.MED_NODE):
+ visuEntityType = VISU.NODE
+
+
+Export des résultats de calcul
+------------------------------
+
+Tous les champs produits à l'occasion des opérations entre objets
+``FieldProxy`` sont automatiquement ajoutés à la structure med à
+laquelle is sont associés. Une convention d'attribution des noms est
+implémentée de sorte que par défaut aucune précision n'est demandée à
+l'utilisateur.
+
+La structure med peut être manipulée au moyen de la variable ``med``
+créée dans l'interface textuelle comme une instance de la classe
+``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
+l'interface du servant ``SALOME_MED::MED`` étendue de quelques
+fonctions utilitaires pour la gestion et le contrôle des données.
+
+En particulier, la sauvegarde de la structure dans un fichier est
+automatisée par la méthode ``save(medfilename)``:
+
+.. code-block:: python
+
+ med = medproxy.MedProxy(medObj)
+ med.save("/tmp/output.med")
+
+Cette méthode s'occupe de définir un driver d'écriture et de procéder
+à l'enregistrement des données de la structure med (les maillages, les
+champs présents au départ et tous les champs produits depuis la
+lecture initiale).
+
+Limitations
+===========
+
+L'implémentation de la maquette limite l'usage des opérations aux cas
+de figure suivants:
+
+* Seules les operations entre champs qui partagent le même support med
+ sont possibles. Ceci est une contrainte imposé par la conception
+ actuelle de MEDMEM.
+* Le résultat d'une opérations est calculé sur toutes les composantes
+ et tout le domaine de définition des champs en opérande. Cette
+ deuxième contrainte est juste parce que les usages plus fin,
+ notemment avec la notion de domaine de définition, n'a pas encore
+ été exéminée à ce jour.
+* Le nom d'un champ produit par une opération ne correspond pas au nom
+ de la variable python par laquelle on le réceptionne et on le
+ manipule. Le nom est attribué par une convention (ceci n'est pas
+ vraiment une limitation mais une caractéristique à connaître).
+
+On note également les restriction techniques suivantes:
+
+* Les données MEDMEM sont supposées être chargées par le composant MED
+ puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
+ par le module MED).
+* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
+ de la classe ``FieldProxy`` soient pris en considération dans les
+ opérations sur les champs, il est indispensable que le premier
+ opérande d'une opération unitaire soit un champ (objet de classe
+ ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
+ fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
+ car python tente de traiter la situation au moyen de la fonction
+ ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
+
+
+Notice informatique
+===================
+
+Gestion de configuration
+------------------------
+
+Les développements décrits dans ce chapitre sont répartis entre les
+modules MED et XMED (développé pour l'occasion). Cette séparation est
+faite par soucis de clarté et d'efficacité de développement, mais les
+éléménts du module XMED ont vocation à intégrer le module MED dans la
+mesure où les propositions techniques sont retenues pour le
+développement à venir.
+
+Le code source du module XMED peut être récupérés par la commande
+suivante::
+
+ $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
+
+Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
+équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
+VISU. Pour récupérer la branche BR_medop du module MED, taper la
+commande::
+
+ $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
+
+La configuration de référence est:
+
+* XMED: révision svn 41
+* MED: tag cvs BR_medop_20101025
+
+Moyens de tests
+---------------
+
+Plusieurs types de tests unitaires sont définis (reste à les
+automatiser proprement):
+
+* Test des servants et utilitaires de manipulation python:
+
+ - Dans XMED, package xmed/tests, utiliser le script
+ ``test_medoperation.py`` dans un interpréteur python lancé dans
+ une session shell SALOME. Ce script prépare des variables de test
+ 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``.
+
+* Test des classes MEDMEM:
+
+ - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
+
+Un fichier de test basique (mais néanmoins suffisant) de nom
+``tesfield.med`` est fourni avec les sources dans le répertoire
+``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
+répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
+contient deux champs ``testfield1`` et ``testfield2`` définis sur un
+pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
+par éléments (MED_CELL).
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, MED, MEDMEM
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Note de travail concernant l'utilisation de MEDMEM
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le module MED de SALOME comporte plusieurs composants d'intérêt pour
+la manipulation de champs:
+
+* la bibliothèque MEDMEM qui fournit une interface de programmation
+ pour manoeuvrer une structure MED
+* le module CORBA SALOME_MED qui matérialise le composant SALOME
+ (serveur corba) du module MED
+* l'interopérabilité avec le module VISU qui permet la visualisation
+ des champs manipulés dans MED
+
+Les sections ci-après donnent quelques éclairages techniques sur ces
+différents aspects. Les sources de démonstration peuvent être
+récupérés depuis le dépôt svn::
+
+ $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
+ $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Présentation synthétique de MED
+===============================
+
+MED désigne un modèle conceptuel pour décrire des données de type
+éléments finis (éléments finis, volumes finis et éléments
+discrets). Dans l'usage courant, il permet la description et l'échange
+des données de calcul de type maillages et champs. La documentation
+complète peut être trouvée à l'URL suivantes:
+
+* |LINK_EDF_MEDDOC|_ (version 2.3).
+
+On distingue deux implémentations informatiques de ce modèle:
+
+* MED fichier: qui permet la lecture et l'écriture de données depuis
+ un fichier au format med. Les opérations de lecture/écriture sont
+ atomiques (pas de chargement de la structure de données globale).
+* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
+ image de la structure de données MED contenue dans un fichier au
+ format med. Les opérations peuvent être atomiques ou
+ globales.
+
+On notera simplement ici que MEDMEM utilise MED fichier pour les
+opérations de lecture/écriture et que MED fichier est indépendant de
+MED mémoire. La documentation complète de MED fichier peut être
+trouvée à l'URL suivante:
+
+* |LINK_EDF_MEDFICHIERDOC|_
+
+La bibliothèque MEDMEM
+======================
+
+Le modèle de classes MEDMEM est structuré autour des notions de MESH
+(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
+champs). Ces notions reprennent en partie des concepts du modèle
+MED. Le diagramme ci-dessous présente les classes principales:
+
+.. image:: images/med-uml-main_60pc.png
+ :align: center
+
+Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
+figure ci-dessous indique qu'une instance MED peut être associée à
+plusieurs maillage et plusieurs champs. Par contre un champ donné ne
+peut être associé qu'à un seul maillage (par l'intermédiaire du
+support). Plusieurs champs peuvent être associés au même maillage. La
+forme la plus courante est d'ailleurs une instance composé d'un
+maillage unique sur lequel sont définis plusieurs champs.
+
+On peut avoir également des configurations plus complexes, comme par
+exemple un maillage unique, plusieurs champs définis sur ce maillage
+mais avec des supports différents, par exemple parce que les valeurs
+sont définies sur des entités de maillage différentes (les éléments
+pour un champ, les noeuds pour un autre, ...)::
+
+ field1->support1->mesh
+ field2->support2->mesh
+ field3->support3->mesh
+
+On observe:
+
+* 2 champs U et V doivent avoir le même support (au sens informatique
+ du terme) pour pouvoir être en argument d'une opération (sinon
+ exception). Il faudrait accepter qu'il soit informatiquement
+ différent et vérifier la conformité conceptuelle.
+* Cette contrainte peut se comprendre car physiquement les données
+ sont stockées dans un vecteur qui couvre toutes les mailles. Le
+ support est le seul masque de lecture pour établir la correspondance
+ avec les positions dans le maillage et il est donc important qu'une
+ cohérence soit assurée.
+
+Les objets champs (FIELD) et maillage (MESH)
+--------------------------------------------
+
+Un objet MED permet d'accéder aux différentes informations concernant
+les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
+données physiques associées à ces objets (les valeurs des composantes
+pour les champs, les mailles et leur connectivité pour les
+maillages). L'accès aux données physiques est du ressort des objets
+spécifiques MESH, SUPPORT et FIELD.
+
+Un objet MED peut être créé intégralement en mémoire. L'usage plus
+fréquent est de l'initialiser à partir de la donnée d'un fichier
+med. Pour cela, l'objet MED doit être associé à un driver
+d'entrée/sortie branché sur le fichier (``testfilename`` dans
+l'exemple):
+
+.. code-block:: cpp
+
+ MED *myMed = new MED;
+ MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
+ driverIn->open();
+ driverIn->readFileStruct();
+ driverIn->close();
+
+A l'occasion de la fonction readFileStruct, la structure interne de
+l'objet MED est enrichie des informations concernant les objets MESH,
+SUPPORT et FIELD contenu dans le fichier. En particulier un
+dictionnaire des champs (variable map interne) est initialisé est
+contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
+méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
+autonome pour être chargé sur demande. On peut alors requêter l'objet
+MED pour obtenir un champ particulier (spécifié par son nom
+``fieldname`` dans l'exemple):
+
+.. code-block:: cpp
+
+ FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
+
+Puis le champ qui lui est associé doit être physiquement chargé pour
+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
+----------------------------------------
+
+Les éléments qui composent un maillage sont caractérisés par:
+
+* Le type d'entité de l'élément, à choisir dans la liste
+ ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
+ ``MED_FACE``, ``MED_CELL``.
+* Le type de géométrie de l'élément, à choisir dans la liste
+ ``MED_EN::medGeometryElement``, qui contient en particulier
+ ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
+
+Les éléments sont numérotés par un indice relatif à la catégorie
+géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
+composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
+ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
+persistente dans le fichier med). De même, les arrêtes sont numérotées
+de 1 à Na. Une numérotion globale implicite existe sur les éléments,
+elle consiste à parcourir l'ensemble des types géométriques dans
+l'ordre de définition du modèle de données. Ainsi, si le modèle
+contient uniquement les Na arrêtes et les Nf faces, alors l'indice
+global de la première face est Na+1.
+
+.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
+
+
+Binding python de MEDMEM
+------------------------
+
+Les classes du package ``MEDMEM`` (package du module ``MED`` qui
+implémentent les structures de données C++ de MED mémoire) produisent
+la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
+partie mis à disposition de l'interface python grace à une couche de
+liaison (binding Python-C++) générée par le logiciel SWIG à partir
+d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
+package source ``MEDMEM_SWIG``).
+
+Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
+des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
+nouvelle classe est créée (du moins si l'on souhaite profiter de ces
+évolutions dans l'interface python).
+
+Cette mise à jour nécessite de prendre soin au transfert des
+structures de données entre les espaces python et C++. En particulier,
+l'utilisation des template de classe pour décrire les champs typés en
+C++ appelle une précaution de codage particulière de l'interface
+SWIG.
+
+Pour exemple, le fragment de code ci-dessous, extrait du fichier
+``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
+``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));
+ }
+ 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);
+ }
+ }
+
+ };
+
+
+Utilisation de MEDMEM pour la manipulation de champs
+----------------------------------------------------
+
+Des opérations de manipulation de champs sont disponibles dans la
+bibliothèque MEDMEM standard est peuvent être utilisées dans
+l'interface python. Les quelques lignes suivantes illustrent l'usage
+qu'on peut en faire pour exécuter l'addition de deux champs sur tout
+leur espace de définition et pour un pas de temps donné:
+
+.. code-block:: python
+
+ from libMEDMEM_Swig import MedDataManager
+ from xmed.helper import readMed, writeMed
+
+ # Load the medmem data structure from a med file
+ med = readMed("/tmp/input.med")
+ # Then create a med data manager to deal with the fields data
+ dm = MedDataManager(med)
+ # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
+ f1 = dm.getFieldDouble("testfield1",-1,-1)
+ f2 = dm.getFieldDouble("testfield2",-1,-1)
+
+ # Create a new field as the sum of f1 and f2
+ r = f1 + f2
+ # And add this new field to the med data structure
+ med.addField(r)
+
+ # Finally, write the whole data in an output med file
+ writeMed(med,"/tmp/output.med")
+
+.. note:: Cet exemple de code requiert les évolutions de MEDMEM
+ opérées dans la branche BR_medop (pour disposer de la classe
+ MedDataManager en particulier) et le package python ``xmed`` qui
+ fournit quelques fonctions utilitaires pour manoeuvrer les données
+ med (ce package est dans le module XMED et sera probablement à
+ terme intégré au module MED).
+
+Des limitations existent aujourd'hui pour ce type de manipulations:
+
+* les champs doivent partager le même support MED, c'est-à-dire être
+ décrit sur le même maillage et sur les mêmes entités de ce
+ maillage.
+* ...
+
+
+Remarque sur l'implémentation C++
+---------------------------------
+
+A noter l'usage de plusieurs formes d'arguments pour les fonctions:
+
+* passage des arguments par valeur ``myfunction(A a);``
+* passage des arguments par référence ``myfunction(A& a);``
+* passage des arguments par pointeur ``myfunction(A* a);``
+
+Le passage des arguments par référence est une facilité d'écriture
+pour éviter de passer un pointeur tout en évitant la récopie des
+données de la variable.
+
+.. _xmed-medmem_corbainterface:
+
+L'interface CORBA SALOME_MED
+============================
+
+Implémentation du composant MED et des servants SALOME_MED::\*
+--------------------------------------------------------------
+
+Le composant MED est un servant CORBA qui permet la manipulation de
+données MEDMEM dans l'environnement SALOME. Le composant peut fournir
+des pointeurs vers des instances de l'interface SALOME_MED (objets
+SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
+servants CORBA qui résident dans le container et qui encapsulent les
+données MEDMEM.
+
+Le schéma ci-dessous représente les éléments informatiques qui
+composent l'architecture CORBA du module MED:
+
+.. image:: images/medmem-corba-layers.png
+ :align: center
+
+Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
+CORBA) fonctionnent différement en ce qui concerne le chargement des
+données:
+
+* Dans MEDMEM, les données sont chargées à la demande (fonctions read
+ des objets) et aucune gestion n'est assurée. En particulier l'appel
+ à read alors que la donnée est déjà chargée conduit à une levée
+ d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
+ type de gestion.
+* Dans SALOME_MED, les données sont chargées à la création de
+ l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
+ leurs données sont chargés à ce moment là et gérés dans une table de
+ type HashMap au niveau de la structure SALOME_MED::MED. Cette
+ structure remplie dés lors des fonction de gestion. L'appel à
+ SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
+ un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
+ l'initialisation (ATTENTION, cette fonction est bugguée dans la
+ branche principale -> Fix dans la branche BR_medop).
+
+Une gestion intermédiaire peut être envisagée: le chargement à la
+demande géré dans une ou plusieurs tables de champs (une pour chaque
+type de valeur numérique). Une implémentation de ce type de gestion
+est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
+en charge ce comportement pour les structures de données MED (en
+particulier les champs).
+
+Utilisation du composant MED
+----------------------------
+Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
+interfaces de ce module CORBA sont spécifiées par les fichiers idl
+suivants:
+
+* le fichier
+ [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
+ ``MED.idl``] qui décrit les interfaces des objets manipulés par le
+ module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
+ et FIELD.
+* le fichier
+ [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
+ ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
+ (c'est-à-dire le composant chargé par la commande
+ ``FindOrLoadComponent("FactoryServer", "MED")`` du
+ lyfeCycleCorba). On trouve:
+
+ - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
+ pour l'implémentation des services généraux des composants SALOME
+ (persistance hdf, dump)
+ - l'interface ``MED_Gen`` qui hérite des interfaces
+ ``Engines::Component`` et ``MED_Gen_Driver`` pour
+ l'implémentation des services spécifiques du composant MED.
+
+L'implémentation de ces interfaces est faites au niveau de différents
+packages des sources du module MED:
+
+* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
+ interfaces décrites par le fichier ``MED.idl``;
+* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
+ décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
+ partie composant classique d'un module SALOME.
+* Le package ``MedCorba_Swig`` qui fournit une interface swig
+ générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
+ ``MED``
+
+L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
+utilise l'interface swig fournie par MedCorba_Swig). Après l'import
+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
+être invoqués. Par exemple, les commandes suivantes chargent toute la
+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)
+
+On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
+qui permet une utilisation assez semblable (mais différente on le
+verra plus bas) à MEDMEM:
+
+.. code-block:: python
+
+ fieldIdx = 1 # WRN maybe there is no field of idx=1
+ iterationIdx = 0
+ fieldName = medObj.getFieldNames()[fieldIdx]
+ 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::
+ Observations en vrac:
+
+ * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
+ le champ informatique réel (objet MEDMEM).
+ * FIELD_i::fieldMap variable static de type map qui semble gérer
+ les différentes instances de FIELD_i (~pattern factory). Cette
+ map peut être requétée au moyen d'un indice de type long appelé
+ corbaIndex.
+ * Quand on crée un FIELD_i par le constructeur d'argument
+ ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
+ incrément du corbaIndex
+ * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
+ ``MEDMEM::FIELD_`` associé
+ * A CONFIRMER: Il semble que les fonctions de chargement
+ ``readStructFile*()`` charge toutes les données du fichier med,
+ alors qu'en MEDMEM seules les meta-données sont chargées.
+ * A CONFIRMER: il semble que le chargement d'une structure MED
+ CORBA peut se faire sans passer par le composant (cf. l'interface
+ de MED)
+
+Interface avec le module VISU
+=============================
+
+Des interactions sont possibles entre MED et VISU à partir du moment
+où les données med sont gérées dans l'étude, c'est-à-dire sous la
+forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
+deux conditions sont aujourd'hui nécessaires (objet corba + publié
+dans l'étude) mais il semble que ce ne soit lié qu'à un choix
+d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
+a priori être modifié. A CONFIRMER.
+
+L'exemple de code ci-dessous (en python, mais il peut être transposé à
+une implémentation C++) montre par exemple comment envoyer au module
+VISU une requête de visualisation d'un champs hébergé par le module
+MED (en fait, les données sont gérées au travers d'un objet corba
+SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
+catégorie du composant MED). Les importations standard (salome,
+SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
+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
+ result = visuComp.ImportMed(medSObj)
+
+Il est possible de d'aller plus loin et par exemple de déclencher
+l'affichage d'une scalarmap d'un champ spécifique pour une itération
+particulière (voir la fonction
+``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
+``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
+
+Liens complémentaires:
+
+* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
+
+
+Notes en vrac
+=============
+
+Questions:
+
+* 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?
+
+Remarques:
+
+* A part, les opérations arithmétiques (+,-,*,/), aucune opération
+ n'est définie.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation, XMED
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Démonstrateur XMED, vue d'ensemble
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le module XMED est un espace d'expérimentation pour le développement
+des opérations de manipulation de champs. Il complète des
+développements intégrés directement dans le module MED et gérés dans
+la branche CVS BR_medop.
+
+Une maquette est au point pour illustrer les propositions en matière
+d'ergonomie d'utilisation et en matière d'architecture technique. La
+maquette permet de réaliser des cas d'utilisation de la forme:
+
+* Chargement d'un fichier med dans le module MED (ou publication par
+ un code de calcul).
+* Sélection graphique des champs de l'étude à mettre à disposition
+ dans la console utilisateur ("calculette" en mode texte qui
+ concraitement correspond à l'interface python de SALOME).
+* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
+ entre champs avec possibilité d'utiliser des scalaires dans des
+ opérations de type transformation linéaire (y=ax+b ou y et x sont
+ des champs et a et b des scalaires). Egalement quelques fonctions
+ mathématiques standard applicables sur des champs (pow, sqrt).
+* Possibilité de visualiser les champs produits avec VISU
+* Possibilité d'exporter des champs produits dans un fichier med
+
+La figure ci-dessous montre le résultat d'une séquence d'utilisation
+dans laquelle les champs "testfield1" et "testfield2" ont été
+sélectionnés dans l'arbre d'étude pour être utilisés dans la console
+textuelle sous les noms de variables f1 et f2. L'image montre le
+contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
+ligne de commande:
+
+.. image:: images/medop-gui-result.png
+ :align: center
+
+La séquence ci-après montre le cas d'utilisation complet en
+images:
+
+1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
+2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
+ défaut, le nom du champ est proposé (``testfield1`` ici). Dans
+ l'exemple, l'utilisateur remplace par l'alias ``f1``.
+3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
+ ``f1`` au moyen de la commande ``f1.visu()``
+4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
+ l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
+ récupéré ici dans une variable de nom ``result``.
+
+.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
+.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
+.. |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:
+
+* Les données MEDMEM sont physiquement chargées par le composant MED,
+ c'est-à-dire dans le processus ``Container`` de SALOME, et sont
+ référencées dans l'étude SALOME.
+* Les opérations sont physiquement des opérations entre objets MEDMEM
+ purs qui ont lieu dans le composant MED.
+* Les opérations sont pilotées par des objets proxy python instanciés
+ dans la console TUI puis manipulés par l'utilisateur. Ces objets
+ proxy savent accéder aux objets MEDMEM au travers de leur interface
+ CORBA.
+
+Ainsi, l'architecture technique est construite pour pouvoir travailler
+sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
+depuis des objets python dans l'interface textuelle de
+SALOME. L'effort principal a donc porté sur la mise au point de
+l'interface technique qui permet de lier des variables représentant
+les champs au niveau du GUI (techniquement, la calculette est
+l'interpréteur python embarqué dans le GUI, étendu de quelques
+fonctions pour la manipulation de champs), alors que les données
+MEDMEM sont physiquement disponibles uniquement au niveau des
+composants CORBA (et les opérations implémentées dans MEDMEM
+uniquement).
+
+Pour le moment, la maquette est limitée à des operations entre champs
+qui partagent le même support med (contrainte de MEDMEM) et le
+résultat est calculé sur toutes les composantes et tout le domaine de
+définition du champs (cette deuxième contrainte est juste parce que
+les extentions n'ont pas encore été examinées). Enfin, le support de
+gestion des données est supposé être l'étude SALOME et la structure
+MED qui y est publiée.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2010
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Principes directeurs du développement
+=====================================
+
+En matière de développement:
+
+* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
+ module SALOME diffusable dans la version d'exploitation 2010 (SALOME
+ 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
+ devoir tenir compte des contraintes de temps SALOME et (ii) le
+ produit envisagé fin 2010 est une maquette qui cherche à éprouver
+ l'ergonomie générale d'utilisation et en aucun cas on ne peut
+ garantir la réalisation d'un module SALOME compatible avec les
+ exigences de mise en exploitation.
+* On ne cherche pas d'emblée à capturer tous les cas d'application,
+ mais à concevoir un développement qui acceptera les extensions de
+ périmètres dans des conditions raisonnables. Aussi, les
+ fonctionnalités développées seront celles qui sont nécessaires à la
+ réalisation des cas d'application de référence;
+
+En matière d'ergonomie:
+
+* L'interface utilisateur de référence (appelé espace de travail dans
+ le volet de spécifications fonctionnelles) est l'interpréteur
+ python. Les fonctionnalités doivent être pensées pour un usage
+ adapté à une interface textuelle (TUI) de ce type.
+* La création d'une interface graphique (GUI) peut être envisagée en
+ complément et comme un moyen de manipuler graphiquement les
+ fonctionnalités développées pour l'interface textuelle et pour aider
+ la préparation des variables dans l'interface python.
+* Le modèle d'un processus de manipulation de champs est:
+
+ - Préparation du jeu de variables U, V, ... représentant les champs
+ à manipuler. C'est à ce stade que l'on résoud la question de
+ sélection des données (dans un champ publié dans l'arbre d'étude,
+ par un module de calcul ou par chargement d'un fichier med)
+ - Utilisation des variables avec une sémantique la plus proche
+ possible du modèle conceptuel et des spécifications
+ fonctionnelles;
+ - Création des variables qui représentent les résultats des
+ fonctions de manipulation;
+ - Persistence (fichier med), visualisation (SALOME) ou export (vers
+ une structure qui peut être directement utilisable en numpy)
+
+Sur le plan technique:
+
+* On souhaite spécifier clairement le conteneur SALOME des fonctions
+ de manipulation de champs. Pour discussion:
+
+ - Il apparaît que les modules SALOME MED et VISU contiennent déjà
+ des fonctions qui peuvent faire partie des fonctions de
+ manipulations de champs (en particulier pour l'exploration des
+ structures MED, leur visualisation et la sélection des données à
+ manipuler).
+ - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
+ tout cas pas sous sa forme de module SALOME) et compte-tenu du
+ caractère obsolescent du module VISU (amené à être remplacé sur le
+ plan fonctionnel par le module PARAVIS), on pourrait examiner la
+ création d'un module dédié à la manipulation des maillages et des
+ champs par l'agrégation technique au sein d'un même module des
+ fonctions des modules MED et VISU.
+
+Au moins dans un premier temps, on se donne les limites suivantes:
+
+* Une opération ne peut pas combiner des pas de temps différents. Dans
+ l'hypothèse où cette limite venait à être levée, on doit spécifier
+ le pas de temps de la donnée résultat;
+* Le domaine d'application d'une opération pourra être défini
+ exclusivement par la donnée d'un maillage ou un groupe d'éléments du
+ maillage;
+* On ne traite pas le cas des champs qui prennent leurs valeurs aux
+ points de gauss ou aux noeuds par élément. Une particularité de ces
+ types de support est que le repérage de la position implique deux
+ indices (par exemple l'indice de la maille, puis l'indice du point
+ de gauss).
+
+Eléments de conception
+======================
+
+Plan général
+------------
+
+On peut par exemple imaginer une maquette du genre:
+
+* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
+ structure des maillages et des champs dans l'arbre d'étude.
+* Sélectionner un élément (par exemple un pas de temps d'un champ) et
+ le menu contextuel permet d'exporter ce champ dans la console python
+ pour manipulation. Pour cela, s'inspirer de la fonction
+ ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
+ PythonConsole.
+* L'élément est marqué comme ayant été exporté, on peut imaginer une
+ récupération ultérieure.
+* Exporter un deuxième champ cohérent avec le premier (même pas de
+ temps et défini sur le même maillage avec le même support, on
+ s'arrange pour).
+* Dans la console python, faire les opérations sur les champs
+* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
+ ultérieure. C'est a priori le gros morceau qui consiste à faire un
+ objet CORBA MED à partir d'un objet MED standard, en plus défini
+ dans la console python (sous forme d'objet python).
+
+Quand ce premier cas d'utilisation est au point, on peut envisager de
+le compléter par les opérations suivantes
+
+* exporter le résultat med dans un fichier
+* visualiser les champs produits
+
+Plan de développement:
+
+* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
+ d'architecture, l'opération physique se déroulera en définitif au
+ niveau de MEDMEM pur.
+* Prévoir une implémentation des opérations sous forme de fonctions
+ informatiques, même les opérations algébriques (+,-,*,/). Pour ces
+ dernières et dans certaines conditions (quand on manipule
+ directement les strutures MEDMEM et non pas les objets CORBA),
+ l'utilisation des formes A+B, A-B, ... peuvent être rendues
+ possibles. Dans ce cas, voir la possibilité de combiner plusieurs
+ opérations algébriques sur une seule ligne: A+B-C*0.3.
+* On peut charger la structure MED sous forme d'objet CORBA publiable
+ dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
+ exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
+ récupère que les informations nécessaires au chargement d'un champs:
+ le nom du champs, le nom de son maillage associé, les identifiants
+ du pas de temps, au besoin une structure Field non chargée (par
+ exemple pour récupérer plus facilement le maillage).
+* Un mécanisme (à développer à partir du PyConsole par exemple)
+ pourrait alors permettre le chargement des champs sélectionnés dans
+ la console python et sous un nom facile à manoeuvrer. Prendre
+ inspiration sur XCADGUI::LoadIntoPythonConsole().
+* A priori, les données sont physiquement chargée dans le GUI. Au
+ besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
+ CORBA field à partir d'un field standard (à tester).
+
+Une autre idée est de récupérer le pointeur CORBA MED dans la console
+python et de tirer les données à partir de là. Ajouter une couche de
+wrapping python pur pour gérer les cas de simplification (surcharge
+des opérations arithmétiques par exemple).
+
+Besoins complémentaires:
+
+* L'interpréteur doit contenir des éléments d'aide (par exemple un
+ help qui liste les opérations possibles sur les champs chargés)
+* prévoir quelques fonctions de visu et de persistence. Cela commence
+ probablement par des fonctions de publication dans l'étude des
+ champs créés par les opérations de manipulation. Les champs sont
+ physiquement ajouté automatiquement à la structure med par le MedOp
+ mais il n'est pas obligatoirement publié => fournir un moyen de
+ publication.
+
+Limitations actuelles (liées à la conception de MEDMEM):
+
+* les champs doivent être gérés par la même structure MED car ils
+ doivent partager le même support.
+* les opérations possibles dans MEDMEM sont entre champs pris sur un
+ pas de temps (Q: les pas de temps peuvent-ils être différents).
+
+
+Développements
+--------------
+
+Développement de classes proxy:
+
+* FieldProxy, FieldTimeSeriesProxy
+* Attention pour les éries temporelles, le SUPPORT med peut être
+ différent en chaque pas de temps (par exemple en cas d'extension
+ spatiale du champ au cours du temps).
+
+MEDMEM_MedDataManager:
+
+* FIX: test de l'implémentation C++ au travers de la fonction test() du
+ MedOperator ==> OK. Quand on fait la même opération depuis python
+ via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
+ destructeur du champ semble être appelé. Pb de gestion des pointeurs?
+
+
+Evolutions à prévoir
+====================
+
+Concernant MEDMEM:
+
+* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
+ plusieurs fois de suite puisqu'on recycle la référence si elle est
+ déjà chargée.
+* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
+ exemple avec un getField qui renvoie le champ s'il est déjà chargé
+ ou le charge et le renvoie sinon).
+* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
+ passant a priori par le driver associé. Plusieurs driver peuvent
+ être associés à une structure MED car les données peuvent être
+ chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
+ étendre la structure MED pour avoir accés à la liste des driver puis
+ de cette liste déduire les noms des fichiers.
+* IMP: Opérations combinant des champs sur des support différents ne
+ peuvent pas être faites par l'API (une exception est levée en cas de
+ supports incompatibles), mais on peut imaginer le faire en
+ manoeuvrant les tableaux de données directement.
+* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
+ et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
+* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
+ préalablement ajouté: une fonction removeField en complément de
+ addField.
+
+Concernant l'interface SALOME_MED:
+
+* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
+ structure MED et requêtées au niveau des classes proxy en spécifiant
+ les identifiants des champs impliqués et les paramétres requis (pas
+ de temps en particulier).
+
+Concernant le module MED:
+
+* IMP: pourvoir exporter la structure med dans un fichier med (la
+ structure ayant pu être enrichie par la publication de champs créés
+ par les operations de champs.
+
+
+Historique des travaux
+======================
+
+20100726 : mise au point du schéma de conception
+------------------------------------------------
+
+Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
+raisons:
+
+* MED Coupling ne peut pas gérer des mailles de dimensions différentes
+ dans un même modèle (choix faits dans un soucis de performance dans
+ l'accès à une structure de donnée compact). On peut contourner le
+ problème en définissant deux champs pour traiter chacun des type de
+ mailles.
+* Un champ repose sur un maillage complet (pas de notion de profil,
+ mais cela peut être émulé en créant deux maillages)
+* Le concept de point de gauss n'existe pas (pas implémenté)
+
+TODO:
+
+* Idéalement, il conviendrait de faire un état des lieux du module
+ MED, en particulier des éléments MEDMEM (le coeur), les interfaces
+ CORBA associées (MED.idl implémenté dans le package source
+ MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
+ implémenté dans le package source MED) et le GUI (MedGUI.cxx
+ implémenté dans le package source MEDGUI).
+
+* Ergonomie TUI et modèle CORBA associé:
+
+ 1. Charger un objet medmem (puis les objets métier mesh et field)
+ sur un domaine d'application donné.
+ 2. En faire des variables disponibles dans l'interface TUI et que
+ l'on peut manipuler dans des opérations algébriques.
+ 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
+ les autres modules SALOME.
+
+* Compléter le diagramme de la structure informatique de MED (en
+ particulier l'implémentation des interface IDL).
+* Préparer un module de travail XMED (organisation d'une bibliothèque)
+
+Tests à réaliser:
+
+* Est-il possible de faire des opérations algébriques à partir des
+ objets SALOMEMED (objects CORBA MED)?
+* Création d'un objet MED_i à partir d'une objet MED pur préalablement
+ chargé en mémoire.
+
+A retenir:
+
+* Des opérations de champs sont possibles sur des champs à des pas de
+ temps fixés. Si l'opération doit être menée sur plusieurs pas de
+ temps, alors itérer sur chaque pas de temps. L'idée ici est
+ d'introduire le concept de série temporelle de champs en temps
+ qu'objet manipulable.
+* Pour deux champs différents de la même structure MED, la données des
+ identifiants dt et it ne correspond pas forcément au même instant
+ absolu (en tout cas rien ne le garanti, même si c'est tout de même
+ une pratique courante).
+
+20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
+--------------------------------------------------------------------------
+
+XMED: svn révision 16
+Travailler avec le fichier de donnée testfield.med joint.
+
+
+20101007 : Vers une maquette CORBA
+----------------------------------
+
+Le contexte d'utilisation des opérations de champs est l'environnement
+SALOME. Le support de gestion des données est donc l'étude SALOME. Au
+plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
+session SALOME (soit par un code de calcul intégré, soit par
+chargement des données à partir d'un fichier med). Ces objets sont en
+général référencés dans l'étude SALOME sous la forme d'objets CORBA de
+classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
+SObject (Study Object) dont un attribut est une référence vers un
+objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
+MEDMEM::Field.
+
+On peut donc envisager une solution dans laquelle on donne à
+l'utilisateur des poignées de manipulation des objets
+SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
+type proxy. Cela signifie que l'utilisateur ne manipule pas
+directement des objets MEDMEM mais des objets python qui font
+l'interface (à concevoir et implémenter, a priori avec un design
+pattern de type proxy).
+
+L'utilisation directe des objets MEDMEM aurait pu être une solution
+extremement pratique dans la mesure où ces objets en l'état peuvent
+être combinés dans des opérations de champs (c'est déjà
+implémenté). Par contre, ce procédé souffre de limitations importantes
+dans la gestion et la circulation des données pour les différents cas
+d'utilisation envisagés (visualisation, export, transfert à un autre
+module SALOME).
+
+L'avantage de la solution proposée est multiple:
+
+* Elle permet de travailler sur une structure MED cohérente pour
+ intégrer les résultats des opérations de calculs et combiner des
+ champs cohérents entre eux. Tout passe par des classes proxy qui
+ pourront s'assurer de la cohérence des opérations demandées et
+ exécuter automatiquement les fonctions de pré-traitement ou
+ post-traitement requises pour ces opérations. On peut imaginer par
+ exemple que les requêtes d'opération soient envoyées par les classes
+ proxy à la structure MED à laquelle les champs sont associés pour
+ piloter l'opération en MEDMEM pur.
+* Elle permet d'automatiser un certain nombre d'opérations
+ implicites. Par exemple si deux champs ne sont pas définis dans la
+ même unité, un changement d'unité peut être effectué automatiquement
+ par la classe proxy avant de commander l'opération au niveau
+ MEDMEM.
+* Elle permet de laisser les données sur le container SALOME et de
+ réaliser des opérations sans rappatrier les données en local (qui
+ peuvent être en trés grand nombre).
+* Elle permet d'étendre facilement l'ergonomie de manipulation des
+ champs, par exemple en définissant la notion de *série temporelle de
+ champs*, ou encore les concepts de *domaine de définition* évoqués
+ dans les spécifications fonctionnelles.
+* Elle rend immédiat la circulation des données entre modules SALOME,
+ puisque les champs restent accessble par des objets CORBA, en
+ particulier pour la visualisation ou l'export des champs produits
+ par les opérations.
+
+Elle a cependant des inconvénients et/ou limitations:
+
+* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
+ les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
+ se limite a priori aux opérations de champs (les opérations
+ algébriques dans un premier temps).
+* Les champs à manipuler dans une opération donnée doivent être gérés
+ par la même structure MED.
+
+Il est à noter également que les interfaces de programmation de
+SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
+permettre des requêtes de manipulations de champs (fonctions addition,
+soustraction, multiplication, ...). Pas de contrainte ici sur
+l'ergonomie puisque la manipulation par l'utilisateur se fera au
+niveau des classes proxy uniquement.
+
+
+Hypothèses:
+
+* On tente ici une maquette qui exploite dans la mesure du possible le
+ fonctionnement actuel du module MED, en particulier la gestion des
+ données dans l'étude.
+* Dans une deuxième version, on pourra examiner sérieusement la
+ révision de la gestion des données dans le module, quitte à la
+ spécifier et maquetter dans XMED pour intégration ultérieure dans
+ MED. Exemple:
+
+ - Pouvoir gérer plusieurs structures med dans l'étude.
+
+* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
+ des données (gestion des chargements des champs en particulier,
+ références croisées pour retrouver le med à partir du champ par
+ exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
+ faut pouvoir par ailleurs gérer indifféremment une structure med (et
+ les champs qui y sont associés) qu'elle soit créée en mémoire from
+ scratch ou chargée d'un fichier (donc attention avec les opérations
+ de lecture read(), sur les maillages comme sur les champs). La
+ structure med permet d'obtenir les méta données (meta-field par
+ exemple) mais ne permet pas de savoir si les données sont
+ physiquement chargées ou pas.
+
+
+Révisions:
+
+* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
+ Première version qui permet d'importer un champ dans la console
+ python sous la forme d'un FieldProxy. Ne permet pas encore de faire
+ des opérations. Introduction dans le module MED de l'interface MEDOP
+ pour prendre en charge les opérations sur les champs.
+
+
+20101019 : Maquette de démonstration pour l'addition
+----------------------------------------------------
+
+Cette maquette implémente une solution technique de bout en bout (de
+l'interface python aux objets MEDMEM, en passant par le fieldproxy
+puis les servants CORBA pour les operations, ...) mais sur le
+périmètre de l'addition de champs sur tout leur domaine de définition
+et pour un pas de temps donné.
+
+Limitations:
+
+* gére l'addition de champs de type double uniquement (parceque le
+ reste n'est pas implémenté)
+
+Révisions:
+
+* XMED: svn révision 25
+* MED: cvs tag BR_medop_20101019
+
+
+20101020: Fonctions complémentaires
+-----------------------------------
+
+Cette version test la faisabilité des fonctions complémentaires pour
+accompagner la manipulation de champs. Cela comprend en particulier:
+
+* **la sauvegarde des champs produits** dans un fichier med (un champ ou
+ toute la structure med). Pour cela, on définit un med proxy comme
+ l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
+ de fonction au niveau C++ pour permettre un usage au niveau du GUI
+ C++?).
+* **la visualisation d'un champ** au moyen du module VISU.
+* **des fonctions d'aide interactives** pour assister l'utilisateur
+ dans la console de manipulation des champs.
+
+
+Questions:
+
+* peut-on sauvegarder un champ unique?
+* peut-on faire en sorte que ce soit l'affectation à une variable qui
+ provoque l'ajout du champ à la structure med (ou plus exactement qui
+ supprime tous les champs intermédiaires).
+
+
+Révision:
+
+* XMED: svn revision 31
+* MED: cvs tag BR_medop_20101025
+
+
+20110606: commit avant transfert dans git
+-----------------------------------------
+
+* XMED: svn revision 53
+
+Les parties de MED utiles à MEDOP seront reversées dans XMED
+dans une première étape, puis le tout dans MED 6 au final.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2011
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Cas d'utilisation métier
+========================
+
+On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
+
+ J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
+ ajouter de nouveaux champs issus de champs existants. J'aimerais
+ aussi pouvoir créer de nouveaux meds plus petits par extraction de
+ certaines composantes de champs, certains groupes ou certains pas de
+ temps.
+
+On peut exprimer le besoin sous la forme des cas d'utilisation
+suivants (use cases):
+
+* **UC1: combiner dans un même fichier med des champs issus de
+ plusieurs sources de données**. On peut par exemple charger un
+ premier fichier, puis ajouter à cette base des champs issus d'autre
+ fichiers ou générés par manipulation de champs, ou encore générés
+ par un module de calcul qui produirait directement du MEDCoupling.
+* **UC2: créer un champ contenant certaines composantes d'un autre
+ champ**. On pense ici aux fonctions de restriction, qui permettraient
+ de récupérer certaines composantes uniquement.
+* **UC3: créer un champ contenant certains pas de temps d'un autre
+ champ**. C'est un cas particulier des fonctions de restriction
+ évoquées ci-dessus.
+* **UC4: créer un champ comme la limitation d'un autre champ à un
+ groupe de mailles**. C'est un cas particulier des fonctions de
+ restriction évoquées ci-dessus. Notion de domaine spatial. A
+ priori la notion de groupe est définie dans MEDLoader.
+
+On peut ajouter également les UC identifiés pour la maquette 2010:
+
+* **UC5: comparer des champs issus de source de données différentes**,
+ par exemple des champs chargés de deux fichiers med différents et
+ qui s'appuient sur le même maillage (au moins conceptuellement). Le
+ problème technique ici est de pouvoir changer le maillage d'un
+ champ, pour ramener tous les champs sur le même maillage (au sens
+ informatique). Ceci est une contrainte de MEDCoupling, les
+ opérations sur des champs A et B imposent que A et B soient définis
+ sur le même maillage, i.e. le même objet informatique.
+* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
+ de mailles. Ce cas d'usage est typiquement prévu pour produire les
+ conditions de chargement initial d'une structure. Il s'agit ici
+ d'initialiser un champ à partir de zéro sur une surface prédéfinie
+ de la géométrie (par exemple spécifiée par un nom de groupe de
+ mailles).
+
+Pour UC5: les sources de données sont référencées dans l'object
+browser. On importe explicitement les données dans l'espace de
+travail. On peut détecter que les maillages sont identiques et on
+propose à l'utilisateur de transférer le champ sur le maillage déjà
+présent. Sinon, les champs devront être référencés sur des maillages
+distincts dans l'arbre de l'espace de travail.
+
+Analyses préliminaires pour le chantier 2011
+============================================
+
+On fait le choix pour le chantier 2011 de travailler à partir de la
+bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
+le démonstrateur 2011).
+
+Analyse de MEDCoupling et MEDLoader
+-----------------------------------
+
+MEDCoupling est l'implémentation du modèle de données MED (avec
+recherche de minimisation des dépendances logicielles) et MEDLoader
+fournit une ensemble de fonctions pour le chargement des structures
+MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
+forme de fichiers.
+
+Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
+d'une grandeur physique sur un maillage pour un pas de temps donné. Un
+champ est caractérisé par:
+
+* un support spatial, le maillage
+* un type de discrétisation spatial, défini par l'emplacement des
+ valeurs sur le maillage (sur les noeuds, sur les cellules, aux
+ points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
+ etc)
+* un pas de temps, défini par deux entiers (iteration, order) et un
+ réel (timestamps)
+
+Dans cette implémentation, il existe une association 1..n entre un
+maillage et un champ (alors que dans MEDMEM, la structure
+intermédiaire SUPPORT est implémentée).
+
+MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
+des structures MEDCoupling au travers du bus CORBA. L'interface à ce
+jour est délibérément réduite. Des classes dites "Cliente" sont
+fournies pour piloter les servants CORBA depuis un contexte
+client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
+fonction de création d'une structure MEDCoupling à partir d'un
+pointeur vers un servant CORBA. La structure est créée localement
+(dans le contexte client) avec duplication des données issue de la
+structure encapsulée par le servant CORBA (récupération par la
+fonction de sérialisation).
+
+Aucune interface CORBA n'est défini pour MEDLoader.
+
+Questions:
+
+* Voir comment sont créés les servants, et surtout comment ils sont
+ récupérés (via le lcc?)
+* Comment peut-on définir un champ sur un groupe de mailles (et non
+ pas sur le maillage complet)? Comment peut-on extraire le champs
+ circoncit à une groupe de mailles pour des opérations.
+
+ - R: méthode changeUnderlyingMesh
+
+* Comment manipuler deux champs chargées de fichiers différents mais
+ construit sur le même maillage (conceptuellement). On peut forcer la
+ réassociation d'un champ sur un autre maillage?
+* Manipuler des champs de pas de temps différents? Différentes
+ composantes d'un ou plusieurs champs?
+* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
+
+* mapper sur une image
+
+Improvments:
+
+* MEDLoader::Write should raise an exception if the filepath is not writable
+* MEDDataManager: développer une classe chapeau sur MEDCoupling et
+ MEDLoader pour aider au chargement et la gestion de données MED
+ (orienté manipulation de champs). Cette classe serait associée des
+ structures légères FieldHandler et MeshHandler et des listes
+ correspondantes pour la navigation dans les méta-données.
+* Sur base du MEDDataManager, prévoir des ports med pour yacs par
+ lesquels pourrait transiter des handler.
+
+Nouveaux concepts à prendre en compte
+-------------------------------------
+
+Au démarrage du chantier 2011, on observe que les concepts suivants
+sont introduits dans le module MED:
+
+* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
+ les fichiers med et obtenir les informations générales sur le
+ contenu.
+* MEDFILEBROWSER: remplace le concept de driver et fournit les
+ fonctions précédemment fournies par la classe MED pour obtenir les
+ informations de structure.
+* Concept d'Extractor pour une lecture sélective des données de champs
+ (suivant un critère d'extraction)
+* Il n'est plus nécessaire d'appeler les méthodes read explicitement
+ sur les objets (MESH et FIELD) pour charger les données. Par
+ ailleurs, on peut définir deux fois le même champs (double
+ chargement a priori) sans lever d'exception).
+
+
+Analyse de conception pour le chantier 2011
+===========================================
+
+Composants SALOME (interfaces IDL)
+----------------------------------
+
+* MEDDataManager: défini une structure FIELD pour identifier un champ
+ dans les requêtes. Il s'occupe également de la récupération physique
+ des données, quelqu'en soit la source (fichier avec MEDLoader, autre
+ module SALOME comme PARAVIS avec une méthode à définir)
+* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
+ les structures FIELD du MEDDataManager. Reprendre l'interface de
+ MEDOP.
+
+Use case à réaliser depuis un client python:
+
+* UC01: ajouter un fichier d'entrée et accéder aux informations
+ concernant les champs. Ex: récupérer une structure champs par la
+ donnée des paramètres primaires (nom identifiant, dt, it, nom du
+ maillage).
+* UC02: créer des champs et les ajouter au MEDDataManager
+* UC03: mener des opérations basique sur les champs en console python
+
+Interface Utilisateur
+---------------------
+
+L'interface utilisateur est composée des parties suivantes:
+
+* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
+ le chargement des données dans l'espace de travail, au moyen d'une
+ interface graphique;
+* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
+ la création de champs, au moyen de commandes exécutées dans la
+ console python.
+
+Le principe est que les champs sont préalablement chargés au niveau du
+composant SALOME au moyen de l'interface graphique (MEDGUI), puis
+manoeuvrés depuis l'application SALOME au moyen de variables proxy
+définies dans la console python (MEDTUI). Au chargement, les champs
+sont indéxés par le MEDDataManager, puis les index sont rendus
+accessibles au niveau du GUI au moyen d'une représentation
+arborescente de la structure MED. Les feuilles de l'arbre
+correspondent à des champs qui peuvent être sélectionnés et dont
+l'index peut être obtenu de la sélection.
+
+L'espace de travail est organisé autour du concept de
+"workspace". L'étude SALOME liste les datasource (les fichiers source
+des données med, mais peut-être aussi les référence vers des objets
+MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
+permet de voir la structure fine d'une source de données.
+
+Concernant MEDGUI:
+
+* la représentation des données (les champs et les maillages associés)
+ doit permettre de récupérer par l'interface graphique les
+ identifiants des champs à manipuler (a priori les structures FIELD
+ définies par le composant MEDDataManager). Cela conduit à la mise en
+ place des composants suivants:
+
+ - MedDataModel hérité de TreeData. Il est peuplé avec les
+ méta-données décrivant la structure MED explorée.
+ - MedGuiManager qui permet l'implantation du doc widget de
+ présentation
+
+TODO:
+
+* specifier le concept de workspace (qui a une entrée dans l'étude?)
+ en bijection avec un datamanager
+* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
+
+Concernant MEDTUI:
+
+* Il fournit les classes FieldProxy
+
+Questions:
+
+* Comment traiter le cas du travail sur des composantes ciblées, plus
+ généralement, comment introduire le concept de domaine
+ d'application?
+* Prévoir des fonctions génériques (initialisation d'un champ sur un
+ maillage avec une fonction analytique de la position, sauvegarder
+ les champs créés dans un fichier med)
+
+
+Tâches de développement
+=======================
+
+T20110622.1: Gestion des données internes
+-----------------------------------------
+
+**Status: terminé.**
+Suite: fonction de sauvegarde au niveau graphique également
+
+On vise les cas d'utiliation suivants:
+
+* UC1: intégrer dans le datamodel du gui un champ créé dans la console
+ python (et donc présent dans le datamanager du composant). Définir
+ l'utilité?
+* UC2: renommer un champ et plus généralement changer ses méta-données
+ (avec assurance de synchronisation entre toutes les données).
+* UC3: sauvegarder une sélection de champs. La sélection peut se faire
+ dans l'arbre du datamodel gui.
+
+WARN: robustesse de fieldproxy
+
+
+
+T20110622.2: UC Initialisation/Création de champs
+-------------------------------------------------
+
+**Status: à faire**
+
+Les cas implémentés à ce jour sont la création de champs à partir de
+champs existants et chargés d'un fichier med. On souhaite ici réaliser
+des cas 'utilisation autour de la création de champs "from scratch",
+s'appuyant tout de même sur un maillage chargé.
+
+UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
+champ (par exemple les conditions limites d'un problème de calcul).
+
+UC02: créer un champ avec des restrictions qui définissent le domaine
+d'application des opération de champs.
+
+UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
+composantes du champs vectoriel ou niveaux de gris pour un champ
+scalaire. Attention, pour ça, il faudra a priori fiare une projection
+du maillage cartesien de l'image sur le maillage (quelconque) sur
+lequel on souhaite définir le champ.
+
+UC04: créer un champ à partir d'un tableau numpy
+
+De manière générale, ce type de création sera assisté par le
+MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
+pour l'utilisateur.
+
+Par exemple, prévoir un menu contextuel qui propose les opérations
+possibles en fonction de la sélection (en plus de la fonction d'import
+dans la console python).
+
+TODO:
+
+* développer les fonctions d'initialisation, par exemple au moyen
+ d'applyFunc et du mécanisme de callable?
+
+T20110622.3: documentation contextuel
+-------------------------------------
+
+**Status: à faire**
+
+* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
+ et fieldtools)
+* Faire un modèle générique de command (classe de base
+* Batir la doc des commandes sur cette base (lister toutes les
+ instances de type Command par exemple)
+
+T20110622.4: remontée des exception du composant MEDCalculator
+--------------------------------------------------------------
+
+**Status: en cours, compléter la couverture**
+
+Pour des messages contextuel sur les erreurs de calcul (ex: division
+par 0)
+
+* Poursuivre le travail fait sur getMedEventListener
+* Protéger tous les appels au composants effectués depuis la console
+ python (prendre example sur la commande save)
+
+T20110624.1: gestion des données GUI
+------------------------------------
+
+**Status: à faire**
+
+
+
+Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
+
+* supprimer: supprime tout les champs associés
+* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
+ cocher ceux qu'on veut sauvegarder.
+
+Le gui data model est réservé aux opérations sur les champs et à
+piloter leur import dans la console python.
+
+TODO:
+
+* Spécifier les concepts de workspace, database, et datasource, espace
+ de gestion, ... et les associations. Simplifier avec l'appuie de use
+ cases.
+* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
+ l'ajout addChild est implémenté
+* Clic droit sur objets de l'arbre: dans la notification TreeView ->
+ WorkspaceController, faire remonter l'évènement clic droit ainsi que la
+ liste des éléments sélectionné pour faire générer le menu contextuel
+ au niveau du WorkspaceController qui peut déterminer le contexte métier
+ (le TreeView ne le connaît pas).
+* Définir des DataObject pour les maillages, les séries temporelles et
+ les champs
+
+
+Spécification des espaces de données:
+
+* MEDDataManager dépend de l'étude (pour permettre la publication
+ d'information dans une étude SALOME).
+* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
+ requetes getFields(sourceid), getMeshes(sourceid)
+* les espaces de données: dataspace, workspace. Un seul workspace par
+ étude, mais autand de datasources que l'on souhaite dans le
+ dataspace. Les datasources sont rangés dans l'étude (le dataspace)
+ et sont non modifiables après chargement (référence des sources de
+ données).
+
+
+T20110628.1: extention à d'autres objets SALOME
+-----------------------------------------------
+
+**Status: suspendu**
+
+On doit reposer la question de l'existance de l'arbre indépendant
+(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
+SMESH en particulier) du principe de sélection graphique pour
+utilisation dans la console python, d'autre part.
+
+
+T20110628.2: visualisation d'un champ avec PARAVIS
+--------------------------------------------------
+
+**Status: terminé (pour une première version)**
+Suite: de nombreux défauts subsistent
+
+Questions/remarques:
+
+* Pb au démarrage du module: VisTrails fails to start
+* Peux-t-on piloter la vue 3D sans charger le module? (voir
+ myparavis.py)
+* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
+* Comment utiliser directement les objets MEDCouplingField?
+
+
+T20110706.1: documentation du module
+------------------------------------
+
+**Status: en cours (10%)**
+
+Documenter les commandes TUI puis l'utilisation générale de
+l'interafce graphique. Mentionner l'existance de la commande medop.sh
+pour travailler exclusivement en mode texte (utile pour les tests
+rapides).
+
+Documenter les modalités d'exécution des tests.
+
+T20110708.1: helper python pour MEDCoupling
+-------------------------------------------
+
+**Status: en attente (pas urgent)**
+
+Faire un helper python dans le package xmed qui permet de faire du
+medcoupling facilement (essentiellement pour simplifier le chargement,
+puis la sélection des données). Cela demanderait de faire un
+MedDataManager comme une class C++ pure (non CORBA). Cette classe
+travaillerait par exemple uniquement avec des id et des liste d'id, et
+fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
+pour obtenir des meta-information.
+
+Le servant MedDataManager pourrait être une surcouche de cette classe
+c++ pure.
+
+T20110708.2: analyses et tests
+------------------------------
+
+TODO:
+
+* créer un fichier de test avec plusieurs pas de temps
+* créer un fichier de test avec des groupes de mailles
+
+
+T20110728.1: refactoring MEDDataManager
+---------------------------------------
+
+Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
+
+* dans la mesure du possible utiliser les id plutôt que les handler en
+ arguments des fonctions d'appel des objets
+* A chaque champ (FieldHandler), on doit associer un meshid (et de
+ manière optionnelle un fieldseriesId, si le champ peut être associé
+ à une serie temporelle. A priori faisable uniquement au chargement
+ du datasource).
+* Pour cela, revoir les fonctions internes newFieldHandler et addField
+ ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
+ les informations concernant le meshid.
+* addField est utilisée par le MEDCalculator
+* Attention au raffraichissement des données handler au niveau du
+ Workspace. Peut-être le mieux est que les fieldproxy contiennent
+ uniquement le fieldid, et qu'ils interroge le datamanager à chaque
+ fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
+ via le MEDEventListener? **Le plus simple est de faire la mise à
+ jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
+ on essaye d'afficher les données**. Parceque sinon il n'y a pas de
+ problème puisque que le calculateur travaille à partir des id.
+
+
+Petites améliorations du DataspaceController:
+
+* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
+ l'alias python dans un attribut du sobject.
+* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
+ est posé dans le WS. On peut donc proposer en option de lui associer
+ un alias pour manipulation dans la console
+
+
+
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2012
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+
+Analyse preliminaire pour le chantier 2012
+==========================================
+
+La figure imposée pour le chantier 2012 est l'intégration du nouveau
+module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
+préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
+
+L'état actuel est:
+
+* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
+ MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
+ aujourd'hui obsolètes ou amener à disparaître pour l'échéance
+ SALOME7
+* Un module SALOME de nom XMED qui fournit les fonctions graphiques
+ pour la manipulation de champs.
+* Ce module XMED utilise le module VISU pour les vue de contrôle.
+
+La cible est:
+
+* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
+ packages logiciels obsolètes et intégrant les fonctions graphiques
+ (GUI et TUI).
+* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
+ contrôle.
+* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
+ exemple).
+
+A examiner:
+
+* voir les attendus concernant les ports MED dans YACS
+* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
+
+Tâches de développement
+=======================
+
+20120904: Migrer XMED dans MED
+------------------------------
+
+Plan de travail:
+
+* Migration des composants + test
+
+
+
+20120904: Nettoyage de XSALOME
+------------------------------
+
+:status: en cours
+
+* Supprimer les vieilleries de XSALOME:
+
+ - StdHelper -> Basic_Utils (KERNEL)
+
+20120829: mise en place du chantier 2012
+----------------------------------------
+
+:status: terminé
+
+L'objectif de cette première étape est de reverser le prototype 2011
+(module XMED indépendant) dans la branche V6_main du module MED. On
+peut procéder de la manière suivante:
+
+* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
+ V6_main
+* 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
+
--- /dev/null
+#!/bin/sh
+# Copyright (C) 2007-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
+#
+
+factor="50%"
+listfiles="\
+ medop-gui-aliasfield.png \
+ medop-gui-result.png \
+ medop-gui-selectfield.png \
+ medop-gui-visufield.png"
+
+for file in $listfiles; do
+ echo "Processing file $file ..."
+ bn=$(basename $file .png)
+ outfile=$bn"_scale.png"
+ convert -scale $factor $file $outfile
+done
+
+
--- /dev/null
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Documentation of MED module
+%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+The SALOME MED module provides MEDCoupling library (a C++ library dedicated of
+mesh and field manipulation consistent with MED model), as well as a Graphical
+User Interface to access some usual operations.
+
+References
+==========
+
+**User documentation**
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-userguide-gui.rst
+ medcalc-userguide-api.rst
+
+**Technical documentation** (**in french**):
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-specifications.rst
+ medcalc-develguide.rst
+
+**Additional documentation**
+
+.. toctree::
+ :maxdepth: 1
+
+ medcalc-references.rst
+
+Document archive (in french)
+============================
+
+**Documentation du prototype 2010**
+
+Cette section décrit le prototype mis au point en 2010 pour les
+analyses de conception (maquette 2010 sur base MEDMEM)
+
+.. toctree::
+ :maxdepth: 1
+
+ medop-prototype-overview.rst
+ medop-prototype-develguide.rst
+ medop-prototype-medmem.rst
+
+**Journal de travail**
+
+.. toctree::
+ :maxdepth: 1
+
+ medop-workingnotes-2010.rst
+ medop-workingnotes-2011.rst
+ medop-workingnotes-2012.rst
--- /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
+.. meta::
+ :keywords: maillage, champ, manipulation, XMED
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Démonstrateur XMED, documentation technique
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Cette note fait la synthèse des développements effectués pour le
+maquettage des fonctions de manipulation de champs dans SALOME. Elle
+présente les principes retenus en matière de conception, c'est-à-dire
+concernant les mécanismes techniques sous-jacents, et en matière
+d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
+l'environnement SALOME.
+
+Ces principes sont illustrés par des développements implantés dans le
+module XMED, développé pour les besoins de l'analyse, et dans le
+module MED distribué avec la plateforme SALOME.
+
+.. note:: la lecture de ce chapitre demande une connaissance de la
+ structure de classes du module MED, en particulier la distinction
+ entre les classes ``MEDMEM::*`` et les servants CORBA associés
+ (classe ``SALOME_MED::*``).
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Principes directeurs
+====================
+
+Objectif et motivation
+----------------------
+
+L'objectif de maquettage est de trouver une architecture technique qui
+permet d'exécuter le cas d'utilisation suivant:
+
+* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
+* Sélection graphique des champs de l'étude à mettre à disposition
+ dans la console utilisateur ("calculette" en mode texte qui
+ concraitement correspond à l'interface python de SALOME).
+* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
+ entre champs avec possibilité d'utiliser des scalaires dans des
+ opérations de type transformation linéaire (y=ax+b ou y et x sont
+ des champs et a et b des scalaires). Opérations pow, sqrt.
+* Possibilité de visualiser les champs produits avec VISU pour
+ contrôle des résultats.
+* Possibilité d'exporter des champs produits dans un fichier med.
+
+Eléments de contexte
+--------------------
+
+Les opérations de manipulation de champs sont en grande partie
+implémentées dans la bibliothèque MEDMEM. Pour illustration, le
+fragment de code ci-dessous montre comment une addition de champ peut
+être opérée en python:
+
+.. code-block:: python
+
+ from libMEDMEM_Swig import MedDataManager
+ from xmed.helper import readMed, writeMed
+
+ # Load the medmem data structure from a med file
+ med = readMed("/tmp/input.med")
+ # Then create a med data manager to deal with the fields data
+ dm = MedDataManager(med)
+ # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
+ f1 = dm.getFieldDouble("testfield1",-1,-1)
+ f2 = dm.getFieldDouble("testfield2",-1,-1)
+
+ # Create a new field as the sum of f1 and f2
+ r = f1 + f2
+ # And add this new field to the med data structure
+ med.addField(r)
+
+ # Finally, write the whole data in an output med file
+ writeMed(med,"/tmp/output.med")
+
+Ceci montre que les champs peuvent être manipulés avec une interface
+relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
+f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
+package MEDMEM et wrapping python du package MEDMEM_SWIG).
+
+Par ailleurs, le fonctionnement actuel des modules SALOME qui
+manoeuvrent des données MED est d'instancier les structures de données
+MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
+servants CORBA hébergés dans le processus ``SALOME_Container``, et de
+donner accés à ces données depuis l'étude SALOME au travers de
+pointeurs CORBA. Ce choix d'architecture présente l'avantage de
+centraliser au niveau serveur la gestion du cycle de vie des données
+informatiques et de pouvoir distribuer des "poignées" pour manipuler
+ces données depuis chaque point de l'application qui sait accéder au
+bus CORBA, l'interface graphique en particulier.
+
+
+Hypothèse de travail
+--------------------
+
+Compte-tenu de l'objectif de maquettage et des éléments de contexte
+existant, on cherche une solution dans le cadre des hypothèses
+de travail suivantes:
+
+* La manipulation des champs se fait dans l'environement graphique de
+ SALOME.
+* Dans cet environnement, on souhaite pouvoir sélectionner
+ graphiquement les champs à considérer, puis manipuler ces champs
+ dans l'interface texte au moyen de variables python avec une syntaxe
+ aussi simple que celle définie dans le wrapping python de MEDMEM,
+ c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
+ pouvoir écrire f1+f2.
+* Les données MED sont physiquement dans la partie serveur de SALOME
+ et accessibles via des pointeurs CORBA (interface spécifiée dans
+ MED.idl). On exclu la recopie de données au niveau du client
+ graphique.
+
+Dans le cadre de ces hypothèses, la difficulté technique réside dans
+la mise au point d'une interface de communication entre des variables
+manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
+dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
+instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
+processus ``SALOME_Container``).
+
+
+Eléments de conception
+======================
+
+
+Implantation technique
+----------------------
+
+Le diagramme ci-dessous représente l'organisation des principaux
+paquets logiciels du module MED:
+
+.. image:: images/medmem-layers.png
+ :align: center
+
+Les cadres bleus représentent le lieu d'implantation des
+développements effectués dans le module MED pour les besoins du
+maquettage. On notera en particulier les interventions aux niveaux
+suivants:
+
+* interfaces idl: ajout de l'interface MEDOP.idl
+* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
+ l'interface MEDOP.idl
+
+Architecture technique
+----------------------
+
+Les schéma ci-dessous représente les objets informatiques qui sont à
+l'oeuvre pour la réalisation des opérations sur les champs:
+
+.. image:: /images/xmed-architecture.png
+ :align: center
+ :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
+
+On distingue les objets suivants:
+
+* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
+ MED chargée en mémoire.
+* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
+ chargés en mémoire.
+* Une instances de ``SALOME_MED::MED`` et des instances de
+ ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
+ structure med et des champs qui lui sont associés et chargés en
+ mémoire.
+* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
+ centralise la mise en oeuvre des opérations de champs sur le serveur
+ ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
+ sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
+ directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
+ de temps.
+* Des instances de ``FieldProxy`` qui correspondent aux variables
+ manipulées au niveau de l'interface graphique et qui représentent
+ les champs. Une instance de FieldProxy possède détient les
+ références des servants ``SALOME_MED::MEDOP`` et
+ ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
+ ``medop_ptr`` et ``field_ptr`` respectivement.
+* Il existe également une instance de ``MedProxy`` non représentée
+ dans ce diagramme. Cette instance correspond à une variable qui
+ permet de manipuler la structure med.
+
+.. note:: Les éléments apportés par la maquette sont les classes
+ ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
+ éléments ont pu être modifiés légèrement pour les besoins de
+ l'intégration ou pour la correction de quelques bugs.
+
+Le cycle de vie de ces objets est le suivant.
+
+Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
+des champs ``MEDMEM::FIELD``, la création est faite au moment du
+chargement du fichier med dans SALOME au moyen du module MED. A cette
+occasion, les servants CORBA associés ``SALOME_MED::MED`` et
+``SALOME_MED::FIELD`` sont créés et des références vers ces servants
+sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
+l'utilisateur dans l'interface graphique. L'ensemble de ces données
+préexiste à la manipulation de champs.
+
+Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
+``SALOME_MED::MED`` auquel ils sont associées. Le servant
+``SALOME_MED::MED`` possède une référence sur la structure
+``MEDMEM::MED`` et il la transmet à l'instance du servant
+``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
+autonome par la suite pour manipuler les données MED, et les champs en
+particulier. Le code python ci-dessous montre comment un opérateur med
+``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
+l'addition de deux champs:
+
+.. code-block:: python
+
+ 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é à
+une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
+``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
+un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
+``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
+une référence directe sur la structure ``MEDMEM::MED`` et peut la
+manoeuvrer pour demander des champs, faire des opérations avec ces
+champs, ajouter le champs résultat à la structure et enfin retourner
+un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
+
+Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
+instance de ``FieldProxy`` est un objet python qui peut être
+manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
+localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
+ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
+d'usage (cf. paragraphe ci-après). La création d'un objet
+``FieldProxy`` déclenche la création d'un opérateur med (instance de
+``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
+référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
+opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
+opérations possibles sur ce champ, comme illustrer sur l'exemple
+ci-dessus.
+
+
+Rôle des objets proxy
+---------------------
+
+Dans le modèle d'architecture présenté ci-dessus, on introduit deux
+types d'objets proxy:
+
+* Les objets de classe ``FieldProxy`` qui représentent des poignées de
+ manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
+ dans le container SALOME.
+* Les objets de classe ``MedProxy`` qui représentent des poignées de
+ manipulation des structures ``MEDMEM::MED`` physiquement instanciées
+ dans le container SALOME.
+
+Elles sont instanciées dans l'interpréteur python SALOME pour
+manipulation dans l'interface textuelle à partir de la donnée du
+pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
+champ (le nom du champ et le pas de temps défini par le numéro d'ordre
+et le numéro d'iteration:
+
+.. code-block:: python
+
+ import salome
+ salome.salome_init()
+ import SALOME_MED
+
+ medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
+ medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
+
+ from xmed import fieldproxy
+ from xmed import medproxy
+
+ f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
+ f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
+
+ field_somme = f1 + f2
+ field_offset = f1 + 5.3
+
+Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
+``field_offset`` sont des objets de classe ``FieldProxy``. Ils
+correspondent aux variables physiquement manipulées par
+l'utilisateur pour désigner les champs dans les opérations.
+
+Ces classes proxy sont conçues pour être le lieu d'implémentation de
+l'interprétation des commandes utilisateur et donc de l'ergonomie
+de manipulation des champs au niveau l'interface textuelle. Ce point
+est développé :ref:`plus bas <develguide_execFieldOperation>`.
+
+Programmation de l'interface textuelle
+--------------------------------------
+
+Dans le cadre de la maquette, l'interface de manipulation des champs
+est l'interface textuelle python intégrée à SALOME. Dans la pratique,
+l'utilisateur manipule des variables python qui correspondent à des
+objets de classe ``FieldProxy`` équipées des fonctions requises et de
+l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
+ci-dessus).
+
+Or, l'hypothèse de travail est que les données MED sont chargées dans
+SALOME et publiées dans l'étude pour point d'accés depuis l'interface
+graphique. L'utilisateur choisi un champs directement dans l'arbre
+d'étude (ou dans une interface graphique dédiée) puis demande qu'il
+soit mis à disposition dans l'interface python sous un nom de variable
+à choisir. Les captures d'écran ci-dessous montre la séquence
+graphique en images:
+
+.. |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
+lequel le champs sera manipulé dans l'interface textuelle. La
+validation de cette fenêtre doit mettre automatiquement le champ à
+disposition dans l'interface python SALOME et sous le nom de variable
+spécifié par l'alias saisi.
+
+Pour cela, il y a un couplage technique à programmer entre l'interface
+graphique et l'interface textuelle python, avec en particulier la
+transmission des pointeurs vers les servants CORBA mis en jeu dans la
+sélection.
+
+Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
+MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
+implémente l'interface graphique du module. Pour rappel, l'interface
+graphique d'un module SALOME se présente sous la forme d'une classe
+centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
+``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
+par laquelle on peut récupérer une instance de la console python
+embarquée (this->getApp()->pythonConsole()).
+
+Le code suivant illustre l'envoie d'une commande python par ce
+mécanisme. Dans cet example, on cherche à reconstituer dans le
+contexte de la console python un pointer vers un objet med instancié
+dans le contexte C++ de l'application graphique. Pour cela, on
+communique la référence de l'objet sous la forme sérialisé (IOR pour
+un objet CORBA):
+
+.. code-block:: cpp
+
+ #include <PyConsole_Console.h>
+ #include <QString>
+ #include <QStringList>
+ #include <SalomeApp_Application.h>
+
+ // 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
+
+ // Get the IOR of this object
+ QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
+
+ PyConsole_Console * pyConsole = getApp()->pythonConsole();
+
+ 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());
+ }
+
+Le code réel de la maquette est basé sur ce principe et transmet à la
+console python des lignes de commandes qui permettent de reconstruire:
+
+* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
+ champ sélectionné;
+* une instance de ``FieldProxy`` qui correspond au champ sélectionné
+ et avec pour nom de variable la valeur de l'alias saisi dans
+ l'interface graphique.
+
+Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
+par la fabrication de la liste de commandes suivante pour envoie à la
+console python par le mécanisme illustré plus haut:
+
+.. code-block:: cpp
+
+ QStringList commands;
+ commands+="from xmed.fieldproxy import getFieldFromMed";
+ commands+="from xmed.medproxy import getMedProxy";
+ commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
+ commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
+
+Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
+``iterationIndex`` sont construites à partir du champ sélectionné par
+des techniques de programmation standard dans SALOME qu'on peut
+examiner en détail dans la classe ``XMEDGUI`` (voir méthode
+``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
+chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
+
+Le point important à noter ici est que les données à transmettre
+doivent être fournies sous forme de chaînes de caractères ou de types
+simples. C'est pourquoi la référence au servant CORBA
+``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
+c'est-à-dire une chaîne de caractères qui permet l'identification de
+l'objet au niveau du bus CORBA.
+
+Au niveau de la console python cela correspond à l'exécution des
+commandes suivantes:
+
+.. code-block:: python
+
+ 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
+``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
+``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
+associée à ce servant (en fait associée au servant
+``SALOME_MED::MEDOP`` créé sur demande par le servant
+``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
+
+.. _develguide_execFieldOperation:
+
+Exécution des opérations sur le champs
+--------------------------------------
+
+Les variables définies dans l'interface textuelle pour désigner les
+champs à manipuler sont des objets de classe ``FieldProxy``.
+
+Cette classe a une propriété remarquable, elle est construite sur un
+design pattern de type "Proxy" qui pointe vers un servant
+``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
+directement au servant vers lequel il pointe, mais que l'on passe
+systématiquement par une procédure de l'objet proxy qui fait "boîte
+aux lettres":
+
+.. code-block:: python
+
+ class FieldProxy:
+
+ def __getattr__( self, name ):
+ """
+ This method realizes the proxy pattern toward the servant
+ SALOME_MED::FIELD.
+ """
+ return getattr( self.__field_ptr, name )
+
+Ce pattern permet l'implémentation de pré-traitement et/ou de
+post-traitement suivant le type d'accés que l'on cherche à faire.
+
+Il permet aussi et surtout de fournir un objet python qui présente
+l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
+operations de champs. Ici, python est ton ami, car il s'agit pour cela
+d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
+par python pour les operations entre objets. En particulier, la
+re-définition des fonctions internes ``__add__`` (opérateur addition),
+``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
+multiplication) et ``__div__`` (opérateur division) au sein de la
+classe ``FieldProxy``, permet de prendre la main sur le comportement
+des opérations algébriques et de définir une ergonomie sur mesure. Par
+exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
+(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
+réel à une variable de type FieldProxy):
+
+.. code-block:: python
+
+ class FieldProxy:
+
+ def __add__(self, operande):
+ """
+ This can process the addition of two fields or the addition of
+ a scalar to a field. It depends weither the operande is a
+ FieldProxy or a simple scalar numerical value.
+ """
+ if isinstance(operande, FieldProxy):
+ # The operande is an other field
+ otherField_ptr = operande.__field_ptr
+ rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
+ else:
+ # The operande is a scalar numerical value that must be
+ # considered as an offset in a linear transformation
+ factor = 1
+ offset = operande
+ rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
+ return FieldProxy(self.__med_ptr, rfield_ptr)
+
+Il est à noter que dans les deux cas de figure (opérande=champ ou
+opérande=scalaire), la fonction délègue la réalisation concrète de
+l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
+l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
+MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
+service de calcul (l'addition entre champs dans le premier cas,
+l'application d'une transformation linéaire de type y=factor*x+offset
+dans le deuxième cas).
+
+Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
+présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
+l'interface du servant ``SALOME_MED_MEDOP``):
+
+.. code-block:: cpp
+
+ /*! Addition of the fields f1 and f2 ( f1+f2) */
+ FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Substraction of the fields f1 and f2 (f1-f2) */
+ FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Multiplication of the fields f1 by f2 (f1*f2) */
+ FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Division of the fields f1 by f2 (f1/f2) */
+ FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
+ /*! Power of the field f (f^power) */
+ FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
+ /*! Linear transformation of the field f (factor*f+offset) */
+ FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
+ /*! Dublication of the field f */
+ FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
+
+Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
+module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
+``MEDMEM_I``). C'est au sein des instances de cette classe que sont
+réalisées les opérations et que sont produites physiquement les
+données. Typiquement, les opérations présentées ici produisent un
+champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
+``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
+ce servant.
+
+Ce mécanisme global peut être étendu sans limitation à tout les types
+d'opération qui sont envisagés dans les spécifications de manipulation
+des champs dans SALOME.
+
+
+Contrôle visuel des champs
+--------------------------
+
+Les illustrations ci-dessous montrent qu'une fonction de visalisation
+est implémentée dans la maquette pour permettre le contrôle visuel
+d'un champ au moyen d'une représentation 3D (une carte spatiale du
+module du champ dans l'exemple implémenté par défaut):
+
+.. |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.
+
+Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
+module VISU de faire une représentation 3D d'un champ spécifié par la
+donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
+(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
+
+.. code-block:: python
+
+ import salome
+ import VISU
+
+ visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
+ visuComp.SetCurrentStudy(salome.myStudy)
+
+ # Then we can import the specified field in the VISU module. This
+ # creates an study entry in the VISU folder.
+ result = visuComp.ImportMedField(field_ptr)
+
+ meshName = field_ptr.getSupport().getMesh().getName()
+ fieldName = field_ptr.getName()
+ iterNumber = field_ptr.getIterationNumber()
+ scalarmap = visuComp.ScalarMapOnField(result,
+ meshName,
+ visuEntityType,
+ fieldName,
+ iterNumber)
+
+Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
+particulier à cause de la non définition de la variable
+``visuEntityType``, voir remarque plus bas), le composant VISU
+désigné ici par la variable ``visuComp`` va chercher les données du
+champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
+argument de la fonction ``ImportMedField``, puis produit une
+représentation de type "scalarmap".
+
+.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
+ plus haut conférées par le pattern "Proxy", on peut transmettre ici
+ aussi bien le servant CORBA que l'instance du proxy (la fonction
+ ``ImportMedField`` n'y verra que du feu).
+
+Le code complet et fonctionnel de la fonction d'affichage est dans le
+corps du module python ``fieldproxy.py`` sous la forme d'une fonction
+de nom ``visuField``. Il convient de noter que cette fonction doit
+établir une correspondance entre le type des entités tel que défini
+dans MED et dans VISU:
+
+.. code-block:: python
+
+ medEntityType = field_ptr.getSupport().getEntity()
+ if (medEntityType == SALOME_MED.MED_CELL):
+ visuEntityType = VISU.CELL
+ elif (medEntityType == SALOME_MED.MED_NODE):
+ visuEntityType = VISU.NODE
+
+
+Export des résultats de calcul
+------------------------------
+
+Tous les champs produits à l'occasion des opérations entre objets
+``FieldProxy`` sont automatiquement ajoutés à la structure med à
+laquelle is sont associés. Une convention d'attribution des noms est
+implémentée de sorte que par défaut aucune précision n'est demandée à
+l'utilisateur.
+
+La structure med peut être manipulée au moyen de la variable ``med``
+créée dans l'interface textuelle comme une instance de la classe
+``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
+l'interface du servant ``SALOME_MED::MED`` étendue de quelques
+fonctions utilitaires pour la gestion et le contrôle des données.
+
+En particulier, la sauvegarde de la structure dans un fichier est
+automatisée par la méthode ``save(medfilename)``:
+
+.. code-block:: python
+
+ med = medproxy.MedProxy(medObj)
+ med.save("/tmp/output.med")
+
+Cette méthode s'occupe de définir un driver d'écriture et de procéder
+à l'enregistrement des données de la structure med (les maillages, les
+champs présents au départ et tous les champs produits depuis la
+lecture initiale).
+
+Limitations
+===========
+
+L'implémentation de la maquette limite l'usage des opérations aux cas
+de figure suivants:
+
+* Seules les operations entre champs qui partagent le même support med
+ sont possibles. Ceci est une contrainte imposé par la conception
+ actuelle de MEDMEM.
+* Le résultat d'une opérations est calculé sur toutes les composantes
+ et tout le domaine de définition des champs en opérande. Cette
+ deuxième contrainte est juste parce que les usages plus fin,
+ notemment avec la notion de domaine de définition, n'a pas encore
+ été exéminée à ce jour.
+* Le nom d'un champ produit par une opération ne correspond pas au nom
+ de la variable python par laquelle on le réceptionne et on le
+ manipule. Le nom est attribué par une convention (ceci n'est pas
+ vraiment une limitation mais une caractéristique à connaître).
+
+On note également les restriction techniques suivantes:
+
+* Les données MEDMEM sont supposées être chargées par le composant MED
+ puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
+ par le module MED).
+* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
+ de la classe ``FieldProxy`` soient pris en considération dans les
+ opérations sur les champs, il est indispensable que le premier
+ opérande d'une opération unitaire soit un champ (objet de classe
+ ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
+ fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
+ car python tente de traiter la situation au moyen de la fonction
+ ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
+
+
+Notice informatique
+===================
+
+Gestion de configuration
+------------------------
+
+Les développements décrits dans ce chapitre sont répartis entre les
+modules MED et XMED (développé pour l'occasion). Cette séparation est
+faite par soucis de clarté et d'efficacité de développement, mais les
+éléménts du module XMED ont vocation à intégrer le module MED dans la
+mesure où les propositions techniques sont retenues pour le
+développement à venir.
+
+Le code source du module XMED peut être récupérés par la commande
+suivante::
+
+ $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
+
+Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
+équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
+VISU. Pour récupérer la branche BR_medop du module MED, taper la
+commande::
+
+ $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
+
+La configuration de référence est:
+
+* XMED: révision svn 41
+* MED: tag cvs BR_medop_20101025
+
+Moyens de tests
+---------------
+
+Plusieurs types de tests unitaires sont définis (reste à les
+automatiser proprement):
+
+* Test des servants et utilitaires de manipulation python:
+
+ - Dans XMED, package xmed/tests, utiliser le script
+ ``test_medoperation.py`` dans un interpréteur python lancé dans
+ une session shell SALOME. Ce script prépare des variables de test
+ 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``.
+
+* Test des classes MEDMEM:
+
+ - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
+
+Un fichier de test basique (mais néanmoins suffisant) de nom
+``tesfield.med`` est fourni avec les sources dans le répertoire
+``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
+répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
+contient deux champs ``testfield1`` et ``testfield2`` définis sur un
+pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
+par éléments (MED_CELL).
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, MED, MEDMEM
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Note de travail concernant l'utilisation de MEDMEM
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le module MED de SALOME comporte plusieurs composants d'intérêt pour
+la manipulation de champs:
+
+* la bibliothèque MEDMEM qui fournit une interface de programmation
+ pour manoeuvrer une structure MED
+* le module CORBA SALOME_MED qui matérialise le composant SALOME
+ (serveur corba) du module MED
+* l'interopérabilité avec le module VISU qui permet la visualisation
+ des champs manipulés dans MED
+
+Les sections ci-après donnent quelques éclairages techniques sur ces
+différents aspects. Les sources de démonstration peuvent être
+récupérés depuis le dépôt svn::
+
+ $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
+ $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Présentation synthétique de MED
+===============================
+
+MED désigne un modèle conceptuel pour décrire des données de type
+éléments finis (éléments finis, volumes finis et éléments
+discrets). Dans l'usage courant, il permet la description et l'échange
+des données de calcul de type maillages et champs. La documentation
+complète peut être trouvée à l'URL suivantes:
+
+* |LINK_EDF_MEDDOC|_ (version 2.3).
+
+On distingue deux implémentations informatiques de ce modèle:
+
+* MED fichier: qui permet la lecture et l'écriture de données depuis
+ un fichier au format med. Les opérations de lecture/écriture sont
+ atomiques (pas de chargement de la structure de données globale).
+* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
+ image de la structure de données MED contenue dans un fichier au
+ format med. Les opérations peuvent être atomiques ou
+ globales.
+
+On notera simplement ici que MEDMEM utilise MED fichier pour les
+opérations de lecture/écriture et que MED fichier est indépendant de
+MED mémoire. La documentation complète de MED fichier peut être
+trouvée à l'URL suivante:
+
+* |LINK_EDF_MEDFICHIERDOC|_
+
+La bibliothèque MEDMEM
+======================
+
+Le modèle de classes MEDMEM est structuré autour des notions de MESH
+(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
+champs). Ces notions reprennent en partie des concepts du modèle
+MED. Le diagramme ci-dessous présente les classes principales:
+
+.. image:: images/med-uml-main_60pc.png
+ :align: center
+
+Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
+figure ci-dessous indique qu'une instance MED peut être associée à
+plusieurs maillage et plusieurs champs. Par contre un champ donné ne
+peut être associé qu'à un seul maillage (par l'intermédiaire du
+support). Plusieurs champs peuvent être associés au même maillage. La
+forme la plus courante est d'ailleurs une instance composé d'un
+maillage unique sur lequel sont définis plusieurs champs.
+
+On peut avoir également des configurations plus complexes, comme par
+exemple un maillage unique, plusieurs champs définis sur ce maillage
+mais avec des supports différents, par exemple parce que les valeurs
+sont définies sur des entités de maillage différentes (les éléments
+pour un champ, les noeuds pour un autre, ...)::
+
+ field1->support1->mesh
+ field2->support2->mesh
+ field3->support3->mesh
+
+On observe:
+
+* 2 champs U et V doivent avoir le même support (au sens informatique
+ du terme) pour pouvoir être en argument d'une opération (sinon
+ exception). Il faudrait accepter qu'il soit informatiquement
+ différent et vérifier la conformité conceptuelle.
+* Cette contrainte peut se comprendre car physiquement les données
+ sont stockées dans un vecteur qui couvre toutes les mailles. Le
+ support est le seul masque de lecture pour établir la correspondance
+ avec les positions dans le maillage et il est donc important qu'une
+ cohérence soit assurée.
+
+Les objets champs (FIELD) et maillage (MESH)
+--------------------------------------------
+
+Un objet MED permet d'accéder aux différentes informations concernant
+les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
+données physiques associées à ces objets (les valeurs des composantes
+pour les champs, les mailles et leur connectivité pour les
+maillages). L'accès aux données physiques est du ressort des objets
+spécifiques MESH, SUPPORT et FIELD.
+
+Un objet MED peut être créé intégralement en mémoire. L'usage plus
+fréquent est de l'initialiser à partir de la donnée d'un fichier
+med. Pour cela, l'objet MED doit être associé à un driver
+d'entrée/sortie branché sur le fichier (``testfilename`` dans
+l'exemple):
+
+.. code-block:: cpp
+
+ MED *myMed = new MED;
+ MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
+ driverIn->open();
+ driverIn->readFileStruct();
+ driverIn->close();
+
+A l'occasion de la fonction readFileStruct, la structure interne de
+l'objet MED est enrichie des informations concernant les objets MESH,
+SUPPORT et FIELD contenu dans le fichier. En particulier un
+dictionnaire des champs (variable map interne) est initialisé est
+contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
+méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
+autonome pour être chargé sur demande. On peut alors requêter l'objet
+MED pour obtenir un champ particulier (spécifié par son nom
+``fieldname`` dans l'exemple):
+
+.. code-block:: cpp
+
+ FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
+
+Puis le champ qui lui est associé doit être physiquement chargé pour
+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
+----------------------------------------
+
+Les éléments qui composent un maillage sont caractérisés par:
+
+* Le type d'entité de l'élément, à choisir dans la liste
+ ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
+ ``MED_FACE``, ``MED_CELL``.
+* Le type de géométrie de l'élément, à choisir dans la liste
+ ``MED_EN::medGeometryElement``, qui contient en particulier
+ ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
+
+Les éléments sont numérotés par un indice relatif à la catégorie
+géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
+composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
+ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
+persistente dans le fichier med). De même, les arrêtes sont numérotées
+de 1 à Na. Une numérotion globale implicite existe sur les éléments,
+elle consiste à parcourir l'ensemble des types géométriques dans
+l'ordre de définition du modèle de données. Ainsi, si le modèle
+contient uniquement les Na arrêtes et les Nf faces, alors l'indice
+global de la première face est Na+1.
+
+.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
+
+
+Binding python de MEDMEM
+------------------------
+
+Les classes du package ``MEDMEM`` (package du module ``MED`` qui
+implémentent les structures de données C++ de MED mémoire) produisent
+la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
+partie mis à disposition de l'interface python grace à une couche de
+liaison (binding Python-C++) générée par le logiciel SWIG à partir
+d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
+package source ``MEDMEM_SWIG``).
+
+Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
+des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
+nouvelle classe est créée (du moins si l'on souhaite profiter de ces
+évolutions dans l'interface python).
+
+Cette mise à jour nécessite de prendre soin au transfert des
+structures de données entre les espaces python et C++. En particulier,
+l'utilisation des template de classe pour décrire les champs typés en
+C++ appelle une précaution de codage particulière de l'interface
+SWIG.
+
+Pour exemple, le fragment de code ci-dessous, extrait du fichier
+``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
+``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));
+ }
+ 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);
+ }
+ }
+
+ };
+
+
+Utilisation de MEDMEM pour la manipulation de champs
+----------------------------------------------------
+
+Des opérations de manipulation de champs sont disponibles dans la
+bibliothèque MEDMEM standard est peuvent être utilisées dans
+l'interface python. Les quelques lignes suivantes illustrent l'usage
+qu'on peut en faire pour exécuter l'addition de deux champs sur tout
+leur espace de définition et pour un pas de temps donné:
+
+.. code-block:: python
+
+ from libMEDMEM_Swig import MedDataManager
+ from xmed.helper import readMed, writeMed
+
+ # Load the medmem data structure from a med file
+ med = readMed("/tmp/input.med")
+ # Then create a med data manager to deal with the fields data
+ dm = MedDataManager(med)
+ # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
+ f1 = dm.getFieldDouble("testfield1",-1,-1)
+ f2 = dm.getFieldDouble("testfield2",-1,-1)
+
+ # Create a new field as the sum of f1 and f2
+ r = f1 + f2
+ # And add this new field to the med data structure
+ med.addField(r)
+
+ # Finally, write the whole data in an output med file
+ writeMed(med,"/tmp/output.med")
+
+.. note:: Cet exemple de code requiert les évolutions de MEDMEM
+ opérées dans la branche BR_medop (pour disposer de la classe
+ MedDataManager en particulier) et le package python ``xmed`` qui
+ fournit quelques fonctions utilitaires pour manoeuvrer les données
+ med (ce package est dans le module XMED et sera probablement à
+ terme intégré au module MED).
+
+Des limitations existent aujourd'hui pour ce type de manipulations:
+
+* les champs doivent partager le même support MED, c'est-à-dire être
+ décrit sur le même maillage et sur les mêmes entités de ce
+ maillage.
+* ...
+
+
+Remarque sur l'implémentation C++
+---------------------------------
+
+A noter l'usage de plusieurs formes d'arguments pour les fonctions:
+
+* passage des arguments par valeur ``myfunction(A a);``
+* passage des arguments par référence ``myfunction(A& a);``
+* passage des arguments par pointeur ``myfunction(A* a);``
+
+Le passage des arguments par référence est une facilité d'écriture
+pour éviter de passer un pointeur tout en évitant la récopie des
+données de la variable.
+
+.. _xmed-medmem_corbainterface:
+
+L'interface CORBA SALOME_MED
+============================
+
+Implémentation du composant MED et des servants SALOME_MED::\*
+--------------------------------------------------------------
+
+Le composant MED est un servant CORBA qui permet la manipulation de
+données MEDMEM dans l'environnement SALOME. Le composant peut fournir
+des pointeurs vers des instances de l'interface SALOME_MED (objets
+SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
+servants CORBA qui résident dans le container et qui encapsulent les
+données MEDMEM.
+
+Le schéma ci-dessous représente les éléments informatiques qui
+composent l'architecture CORBA du module MED:
+
+.. image:: images/medmem-corba-layers.png
+ :align: center
+
+Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
+CORBA) fonctionnent différement en ce qui concerne le chargement des
+données:
+
+* Dans MEDMEM, les données sont chargées à la demande (fonctions read
+ des objets) et aucune gestion n'est assurée. En particulier l'appel
+ à read alors que la donnée est déjà chargée conduit à une levée
+ d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
+ type de gestion.
+* Dans SALOME_MED, les données sont chargées à la création de
+ l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
+ leurs données sont chargés à ce moment là et gérés dans une table de
+ type HashMap au niveau de la structure SALOME_MED::MED. Cette
+ structure remplie dés lors des fonction de gestion. L'appel à
+ SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
+ un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
+ l'initialisation (ATTENTION, cette fonction est bugguée dans la
+ branche principale -> Fix dans la branche BR_medop).
+
+Une gestion intermédiaire peut être envisagée: le chargement à la
+demande géré dans une ou plusieurs tables de champs (une pour chaque
+type de valeur numérique). Une implémentation de ce type de gestion
+est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
+en charge ce comportement pour les structures de données MED (en
+particulier les champs).
+
+Utilisation du composant MED
+----------------------------
+Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
+interfaces de ce module CORBA sont spécifiées par les fichiers idl
+suivants:
+
+* le fichier
+ [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
+ ``MED.idl``] qui décrit les interfaces des objets manipulés par le
+ module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
+ et FIELD.
+* le fichier
+ [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
+ ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
+ (c'est-à-dire le composant chargé par la commande
+ ``FindOrLoadComponent("FactoryServer", "MED")`` du
+ lyfeCycleCorba). On trouve:
+
+ - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
+ pour l'implémentation des services généraux des composants SALOME
+ (persistance hdf, dump)
+ - l'interface ``MED_Gen`` qui hérite des interfaces
+ ``Engines::Component`` et ``MED_Gen_Driver`` pour
+ l'implémentation des services spécifiques du composant MED.
+
+L'implémentation de ces interfaces est faites au niveau de différents
+packages des sources du module MED:
+
+* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
+ interfaces décrites par le fichier ``MED.idl``;
+* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
+ décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
+ partie composant classique d'un module SALOME.
+* Le package ``MedCorba_Swig`` qui fournit une interface swig
+ générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
+ ``MED``
+
+L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
+utilise l'interface swig fournie par MedCorba_Swig). Après l'import
+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
+être invoqués. Par exemple, les commandes suivantes chargent toute la
+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)
+
+On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
+qui permet une utilisation assez semblable (mais différente on le
+verra plus bas) à MEDMEM:
+
+.. code-block:: python
+
+ fieldIdx = 1 # WRN maybe there is no field of idx=1
+ iterationIdx = 0
+ fieldName = medObj.getFieldNames()[fieldIdx]
+ 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::
+ Observations en vrac:
+
+ * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
+ le champ informatique réel (objet MEDMEM).
+ * FIELD_i::fieldMap variable static de type map qui semble gérer
+ les différentes instances de FIELD_i (~pattern factory). Cette
+ map peut être requétée au moyen d'un indice de type long appelé
+ corbaIndex.
+ * Quand on crée un FIELD_i par le constructeur d'argument
+ ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
+ incrément du corbaIndex
+ * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
+ ``MEDMEM::FIELD_`` associé
+ * A CONFIRMER: Il semble que les fonctions de chargement
+ ``readStructFile*()`` charge toutes les données du fichier med,
+ alors qu'en MEDMEM seules les meta-données sont chargées.
+ * A CONFIRMER: il semble que le chargement d'une structure MED
+ CORBA peut se faire sans passer par le composant (cf. l'interface
+ de MED)
+
+Interface avec le module VISU
+=============================
+
+Des interactions sont possibles entre MED et VISU à partir du moment
+où les données med sont gérées dans l'étude, c'est-à-dire sous la
+forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
+deux conditions sont aujourd'hui nécessaires (objet corba + publié
+dans l'étude) mais il semble que ce ne soit lié qu'à un choix
+d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
+a priori être modifié. A CONFIRMER.
+
+L'exemple de code ci-dessous (en python, mais il peut être transposé à
+une implémentation C++) montre par exemple comment envoyer au module
+VISU une requête de visualisation d'un champs hébergé par le module
+MED (en fait, les données sont gérées au travers d'un objet corba
+SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
+catégorie du composant MED). Les importations standard (salome,
+SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
+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
+ result = visuComp.ImportMed(medSObj)
+
+Il est possible de d'aller plus loin et par exemple de déclencher
+l'affichage d'une scalarmap d'un champ spécifique pour une itération
+particulière (voir la fonction
+``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
+``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
+
+Liens complémentaires:
+
+* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
+
+
+Notes en vrac
+=============
+
+Questions:
+
+* 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?
+
+Remarques:
+
+* A part, les opérations arithmétiques (+,-,*,/), aucune opération
+ n'est définie.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation, XMED
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+Démonstrateur XMED, vue d'ensemble
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Le module XMED est un espace d'expérimentation pour le développement
+des opérations de manipulation de champs. Il complète des
+développements intégrés directement dans le module MED et gérés dans
+la branche CVS BR_medop.
+
+Une maquette est au point pour illustrer les propositions en matière
+d'ergonomie d'utilisation et en matière d'architecture technique. La
+maquette permet de réaliser des cas d'utilisation de la forme:
+
+* Chargement d'un fichier med dans le module MED (ou publication par
+ un code de calcul).
+* Sélection graphique des champs de l'étude à mettre à disposition
+ dans la console utilisateur ("calculette" en mode texte qui
+ concraitement correspond à l'interface python de SALOME).
+* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
+ entre champs avec possibilité d'utiliser des scalaires dans des
+ opérations de type transformation linéaire (y=ax+b ou y et x sont
+ des champs et a et b des scalaires). Egalement quelques fonctions
+ mathématiques standard applicables sur des champs (pow, sqrt).
+* Possibilité de visualiser les champs produits avec VISU
+* Possibilité d'exporter des champs produits dans un fichier med
+
+La figure ci-dessous montre le résultat d'une séquence d'utilisation
+dans laquelle les champs "testfield1" et "testfield2" ont été
+sélectionnés dans l'arbre d'étude pour être utilisés dans la console
+textuelle sous les noms de variables f1 et f2. L'image montre le
+contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
+ligne de commande:
+
+.. image:: images/medop-gui-result.png
+ :align: center
+
+La séquence ci-après montre le cas d'utilisation complet en
+images:
+
+1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
+2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
+ défaut, le nom du champ est proposé (``testfield1`` ici). Dans
+ l'exemple, l'utilisateur remplace par l'alias ``f1``.
+3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
+ ``f1`` au moyen de la commande ``f1.visu()``
+4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
+ l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
+ récupéré ici dans une variable de nom ``result``.
+
+.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
+.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
+.. |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:
+
+* Les données MEDMEM sont physiquement chargées par le composant MED,
+ c'est-à-dire dans le processus ``Container`` de SALOME, et sont
+ référencées dans l'étude SALOME.
+* Les opérations sont physiquement des opérations entre objets MEDMEM
+ purs qui ont lieu dans le composant MED.
+* Les opérations sont pilotées par des objets proxy python instanciés
+ dans la console TUI puis manipulés par l'utilisateur. Ces objets
+ proxy savent accéder aux objets MEDMEM au travers de leur interface
+ CORBA.
+
+Ainsi, l'architecture technique est construite pour pouvoir travailler
+sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
+depuis des objets python dans l'interface textuelle de
+SALOME. L'effort principal a donc porté sur la mise au point de
+l'interface technique qui permet de lier des variables représentant
+les champs au niveau du GUI (techniquement, la calculette est
+l'interpréteur python embarqué dans le GUI, étendu de quelques
+fonctions pour la manipulation de champs), alors que les données
+MEDMEM sont physiquement disponibles uniquement au niveau des
+composants CORBA (et les opérations implémentées dans MEDMEM
+uniquement).
+
+Pour le moment, la maquette est limitée à des operations entre champs
+qui partagent le même support med (contrainte de MEDMEM) et le
+résultat est calculé sur toutes les composantes et tout le domaine de
+définition du champs (cette deuxième contrainte est juste parce que
+les extentions n'ont pas encore été examinées). Enfin, le support de
+gestion des données est supposé être l'étude SALOME et la structure
+MED qui y est publiée.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2010
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Principes directeurs du développement
+=====================================
+
+En matière de développement:
+
+* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
+ module SALOME diffusable dans la version d'exploitation 2010 (SALOME
+ 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
+ devoir tenir compte des contraintes de temps SALOME et (ii) le
+ produit envisagé fin 2010 est une maquette qui cherche à éprouver
+ l'ergonomie générale d'utilisation et en aucun cas on ne peut
+ garantir la réalisation d'un module SALOME compatible avec les
+ exigences de mise en exploitation.
+* On ne cherche pas d'emblée à capturer tous les cas d'application,
+ mais à concevoir un développement qui acceptera les extensions de
+ périmètres dans des conditions raisonnables. Aussi, les
+ fonctionnalités développées seront celles qui sont nécessaires à la
+ réalisation des cas d'application de référence;
+
+En matière d'ergonomie:
+
+* L'interface utilisateur de référence (appelé espace de travail dans
+ le volet de spécifications fonctionnelles) est l'interpréteur
+ python. Les fonctionnalités doivent être pensées pour un usage
+ adapté à une interface textuelle (TUI) de ce type.
+* La création d'une interface graphique (GUI) peut être envisagée en
+ complément et comme un moyen de manipuler graphiquement les
+ fonctionnalités développées pour l'interface textuelle et pour aider
+ la préparation des variables dans l'interface python.
+* Le modèle d'un processus de manipulation de champs est:
+
+ - Préparation du jeu de variables U, V, ... représentant les champs
+ à manipuler. C'est à ce stade que l'on résoud la question de
+ sélection des données (dans un champ publié dans l'arbre d'étude,
+ par un module de calcul ou par chargement d'un fichier med)
+ - Utilisation des variables avec une sémantique la plus proche
+ possible du modèle conceptuel et des spécifications
+ fonctionnelles;
+ - Création des variables qui représentent les résultats des
+ fonctions de manipulation;
+ - Persistence (fichier med), visualisation (SALOME) ou export (vers
+ une structure qui peut être directement utilisable en numpy)
+
+Sur le plan technique:
+
+* On souhaite spécifier clairement le conteneur SALOME des fonctions
+ de manipulation de champs. Pour discussion:
+
+ - Il apparaît que les modules SALOME MED et VISU contiennent déjà
+ des fonctions qui peuvent faire partie des fonctions de
+ manipulations de champs (en particulier pour l'exploration des
+ structures MED, leur visualisation et la sélection des données à
+ manipuler).
+ - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
+ tout cas pas sous sa forme de module SALOME) et compte-tenu du
+ caractère obsolescent du module VISU (amené à être remplacé sur le
+ plan fonctionnel par le module PARAVIS), on pourrait examiner la
+ création d'un module dédié à la manipulation des maillages et des
+ champs par l'agrégation technique au sein d'un même module des
+ fonctions des modules MED et VISU.
+
+Au moins dans un premier temps, on se donne les limites suivantes:
+
+* Une opération ne peut pas combiner des pas de temps différents. Dans
+ l'hypothèse où cette limite venait à être levée, on doit spécifier
+ le pas de temps de la donnée résultat;
+* Le domaine d'application d'une opération pourra être défini
+ exclusivement par la donnée d'un maillage ou un groupe d'éléments du
+ maillage;
+* On ne traite pas le cas des champs qui prennent leurs valeurs aux
+ points de gauss ou aux noeuds par élément. Une particularité de ces
+ types de support est que le repérage de la position implique deux
+ indices (par exemple l'indice de la maille, puis l'indice du point
+ de gauss).
+
+Eléments de conception
+======================
+
+Plan général
+------------
+
+On peut par exemple imaginer une maquette du genre:
+
+* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
+ structure des maillages et des champs dans l'arbre d'étude.
+* Sélectionner un élément (par exemple un pas de temps d'un champ) et
+ le menu contextuel permet d'exporter ce champ dans la console python
+ pour manipulation. Pour cela, s'inspirer de la fonction
+ ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
+ PythonConsole.
+* L'élément est marqué comme ayant été exporté, on peut imaginer une
+ récupération ultérieure.
+* Exporter un deuxième champ cohérent avec le premier (même pas de
+ temps et défini sur le même maillage avec le même support, on
+ s'arrange pour).
+* Dans la console python, faire les opérations sur les champs
+* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
+ ultérieure. C'est a priori le gros morceau qui consiste à faire un
+ objet CORBA MED à partir d'un objet MED standard, en plus défini
+ dans la console python (sous forme d'objet python).
+
+Quand ce premier cas d'utilisation est au point, on peut envisager de
+le compléter par les opérations suivantes
+
+* exporter le résultat med dans un fichier
+* visualiser les champs produits
+
+Plan de développement:
+
+* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
+ d'architecture, l'opération physique se déroulera en définitif au
+ niveau de MEDMEM pur.
+* Prévoir une implémentation des opérations sous forme de fonctions
+ informatiques, même les opérations algébriques (+,-,*,/). Pour ces
+ dernières et dans certaines conditions (quand on manipule
+ directement les strutures MEDMEM et non pas les objets CORBA),
+ l'utilisation des formes A+B, A-B, ... peuvent être rendues
+ possibles. Dans ce cas, voir la possibilité de combiner plusieurs
+ opérations algébriques sur une seule ligne: A+B-C*0.3.
+* On peut charger la structure MED sous forme d'objet CORBA publiable
+ dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
+ exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
+ récupère que les informations nécessaires au chargement d'un champs:
+ le nom du champs, le nom de son maillage associé, les identifiants
+ du pas de temps, au besoin une structure Field non chargée (par
+ exemple pour récupérer plus facilement le maillage).
+* Un mécanisme (à développer à partir du PyConsole par exemple)
+ pourrait alors permettre le chargement des champs sélectionnés dans
+ la console python et sous un nom facile à manoeuvrer. Prendre
+ inspiration sur XCADGUI::LoadIntoPythonConsole().
+* A priori, les données sont physiquement chargée dans le GUI. Au
+ besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
+ CORBA field à partir d'un field standard (à tester).
+
+Une autre idée est de récupérer le pointeur CORBA MED dans la console
+python et de tirer les données à partir de là. Ajouter une couche de
+wrapping python pur pour gérer les cas de simplification (surcharge
+des opérations arithmétiques par exemple).
+
+Besoins complémentaires:
+
+* L'interpréteur doit contenir des éléments d'aide (par exemple un
+ help qui liste les opérations possibles sur les champs chargés)
+* prévoir quelques fonctions de visu et de persistence. Cela commence
+ probablement par des fonctions de publication dans l'étude des
+ champs créés par les opérations de manipulation. Les champs sont
+ physiquement ajouté automatiquement à la structure med par le MedOp
+ mais il n'est pas obligatoirement publié => fournir un moyen de
+ publication.
+
+Limitations actuelles (liées à la conception de MEDMEM):
+
+* les champs doivent être gérés par la même structure MED car ils
+ doivent partager le même support.
+* les opérations possibles dans MEDMEM sont entre champs pris sur un
+ pas de temps (Q: les pas de temps peuvent-ils être différents).
+
+
+Développements
+--------------
+
+Développement de classes proxy:
+
+* FieldProxy, FieldTimeSeriesProxy
+* Attention pour les éries temporelles, le SUPPORT med peut être
+ différent en chaque pas de temps (par exemple en cas d'extension
+ spatiale du champ au cours du temps).
+
+MEDMEM_MedDataManager:
+
+* FIX: test de l'implémentation C++ au travers de la fonction test() du
+ MedOperator ==> OK. Quand on fait la même opération depuis python
+ via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
+ destructeur du champ semble être appelé. Pb de gestion des pointeurs?
+
+
+Evolutions à prévoir
+====================
+
+Concernant MEDMEM:
+
+* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
+ plusieurs fois de suite puisqu'on recycle la référence si elle est
+ déjà chargée.
+* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
+ exemple avec un getField qui renvoie le champ s'il est déjà chargé
+ ou le charge et le renvoie sinon).
+* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
+ passant a priori par le driver associé. Plusieurs driver peuvent
+ être associés à une structure MED car les données peuvent être
+ chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
+ étendre la structure MED pour avoir accés à la liste des driver puis
+ de cette liste déduire les noms des fichiers.
+* IMP: Opérations combinant des champs sur des support différents ne
+ peuvent pas être faites par l'API (une exception est levée en cas de
+ supports incompatibles), mais on peut imaginer le faire en
+ manoeuvrant les tableaux de données directement.
+* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
+ et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
+* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
+ préalablement ajouté: une fonction removeField en complément de
+ addField.
+
+Concernant l'interface SALOME_MED:
+
+* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
+ structure MED et requêtées au niveau des classes proxy en spécifiant
+ les identifiants des champs impliqués et les paramétres requis (pas
+ de temps en particulier).
+
+Concernant le module MED:
+
+* IMP: pourvoir exporter la structure med dans un fichier med (la
+ structure ayant pu être enrichie par la publication de champs créés
+ par les operations de champs.
+
+
+Historique des travaux
+======================
+
+20100726 : mise au point du schéma de conception
+------------------------------------------------
+
+Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
+raisons:
+
+* MED Coupling ne peut pas gérer des mailles de dimensions différentes
+ dans un même modèle (choix faits dans un soucis de performance dans
+ l'accès à une structure de donnée compact). On peut contourner le
+ problème en définissant deux champs pour traiter chacun des type de
+ mailles.
+* Un champ repose sur un maillage complet (pas de notion de profil,
+ mais cela peut être émulé en créant deux maillages)
+* Le concept de point de gauss n'existe pas (pas implémenté)
+
+TODO:
+
+* Idéalement, il conviendrait de faire un état des lieux du module
+ MED, en particulier des éléments MEDMEM (le coeur), les interfaces
+ CORBA associées (MED.idl implémenté dans le package source
+ MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
+ implémenté dans le package source MED) et le GUI (MedGUI.cxx
+ implémenté dans le package source MEDGUI).
+
+* Ergonomie TUI et modèle CORBA associé:
+
+ 1. Charger un objet medmem (puis les objets métier mesh et field)
+ sur un domaine d'application donné.
+ 2. En faire des variables disponibles dans l'interface TUI et que
+ l'on peut manipuler dans des opérations algébriques.
+ 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
+ les autres modules SALOME.
+
+* Compléter le diagramme de la structure informatique de MED (en
+ particulier l'implémentation des interface IDL).
+* Préparer un module de travail XMED (organisation d'une bibliothèque)
+
+Tests à réaliser:
+
+* Est-il possible de faire des opérations algébriques à partir des
+ objets SALOMEMED (objects CORBA MED)?
+* Création d'un objet MED_i à partir d'une objet MED pur préalablement
+ chargé en mémoire.
+
+A retenir:
+
+* Des opérations de champs sont possibles sur des champs à des pas de
+ temps fixés. Si l'opération doit être menée sur plusieurs pas de
+ temps, alors itérer sur chaque pas de temps. L'idée ici est
+ d'introduire le concept de série temporelle de champs en temps
+ qu'objet manipulable.
+* Pour deux champs différents de la même structure MED, la données des
+ identifiants dt et it ne correspond pas forcément au même instant
+ absolu (en tout cas rien ne le garanti, même si c'est tout de même
+ une pratique courante).
+
+20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
+--------------------------------------------------------------------------
+
+XMED: svn révision 16
+Travailler avec le fichier de donnée testfield.med joint.
+
+
+20101007 : Vers une maquette CORBA
+----------------------------------
+
+Le contexte d'utilisation des opérations de champs est l'environnement
+SALOME. Le support de gestion des données est donc l'étude SALOME. Au
+plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
+session SALOME (soit par un code de calcul intégré, soit par
+chargement des données à partir d'un fichier med). Ces objets sont en
+général référencés dans l'étude SALOME sous la forme d'objets CORBA de
+classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
+SObject (Study Object) dont un attribut est une référence vers un
+objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
+MEDMEM::Field.
+
+On peut donc envisager une solution dans laquelle on donne à
+l'utilisateur des poignées de manipulation des objets
+SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
+type proxy. Cela signifie que l'utilisateur ne manipule pas
+directement des objets MEDMEM mais des objets python qui font
+l'interface (à concevoir et implémenter, a priori avec un design
+pattern de type proxy).
+
+L'utilisation directe des objets MEDMEM aurait pu être une solution
+extremement pratique dans la mesure où ces objets en l'état peuvent
+être combinés dans des opérations de champs (c'est déjà
+implémenté). Par contre, ce procédé souffre de limitations importantes
+dans la gestion et la circulation des données pour les différents cas
+d'utilisation envisagés (visualisation, export, transfert à un autre
+module SALOME).
+
+L'avantage de la solution proposée est multiple:
+
+* Elle permet de travailler sur une structure MED cohérente pour
+ intégrer les résultats des opérations de calculs et combiner des
+ champs cohérents entre eux. Tout passe par des classes proxy qui
+ pourront s'assurer de la cohérence des opérations demandées et
+ exécuter automatiquement les fonctions de pré-traitement ou
+ post-traitement requises pour ces opérations. On peut imaginer par
+ exemple que les requêtes d'opération soient envoyées par les classes
+ proxy à la structure MED à laquelle les champs sont associés pour
+ piloter l'opération en MEDMEM pur.
+* Elle permet d'automatiser un certain nombre d'opérations
+ implicites. Par exemple si deux champs ne sont pas définis dans la
+ même unité, un changement d'unité peut être effectué automatiquement
+ par la classe proxy avant de commander l'opération au niveau
+ MEDMEM.
+* Elle permet de laisser les données sur le container SALOME et de
+ réaliser des opérations sans rappatrier les données en local (qui
+ peuvent être en trés grand nombre).
+* Elle permet d'étendre facilement l'ergonomie de manipulation des
+ champs, par exemple en définissant la notion de *série temporelle de
+ champs*, ou encore les concepts de *domaine de définition* évoqués
+ dans les spécifications fonctionnelles.
+* Elle rend immédiat la circulation des données entre modules SALOME,
+ puisque les champs restent accessble par des objets CORBA, en
+ particulier pour la visualisation ou l'export des champs produits
+ par les opérations.
+
+Elle a cependant des inconvénients et/ou limitations:
+
+* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
+ les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
+ se limite a priori aux opérations de champs (les opérations
+ algébriques dans un premier temps).
+* Les champs à manipuler dans une opération donnée doivent être gérés
+ par la même structure MED.
+
+Il est à noter également que les interfaces de programmation de
+SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
+permettre des requêtes de manipulations de champs (fonctions addition,
+soustraction, multiplication, ...). Pas de contrainte ici sur
+l'ergonomie puisque la manipulation par l'utilisateur se fera au
+niveau des classes proxy uniquement.
+
+
+Hypothèses:
+
+* On tente ici une maquette qui exploite dans la mesure du possible le
+ fonctionnement actuel du module MED, en particulier la gestion des
+ données dans l'étude.
+* Dans une deuxième version, on pourra examiner sérieusement la
+ révision de la gestion des données dans le module, quitte à la
+ spécifier et maquetter dans XMED pour intégration ultérieure dans
+ MED. Exemple:
+
+ - Pouvoir gérer plusieurs structures med dans l'étude.
+
+* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
+ des données (gestion des chargements des champs en particulier,
+ références croisées pour retrouver le med à partir du champ par
+ exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
+ faut pouvoir par ailleurs gérer indifféremment une structure med (et
+ les champs qui y sont associés) qu'elle soit créée en mémoire from
+ scratch ou chargée d'un fichier (donc attention avec les opérations
+ de lecture read(), sur les maillages comme sur les champs). La
+ structure med permet d'obtenir les méta données (meta-field par
+ exemple) mais ne permet pas de savoir si les données sont
+ physiquement chargées ou pas.
+
+
+Révisions:
+
+* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
+ Première version qui permet d'importer un champ dans la console
+ python sous la forme d'un FieldProxy. Ne permet pas encore de faire
+ des opérations. Introduction dans le module MED de l'interface MEDOP
+ pour prendre en charge les opérations sur les champs.
+
+
+20101019 : Maquette de démonstration pour l'addition
+----------------------------------------------------
+
+Cette maquette implémente une solution technique de bout en bout (de
+l'interface python aux objets MEDMEM, en passant par le fieldproxy
+puis les servants CORBA pour les operations, ...) mais sur le
+périmètre de l'addition de champs sur tout leur domaine de définition
+et pour un pas de temps donné.
+
+Limitations:
+
+* gére l'addition de champs de type double uniquement (parceque le
+ reste n'est pas implémenté)
+
+Révisions:
+
+* XMED: svn révision 25
+* MED: cvs tag BR_medop_20101019
+
+
+20101020: Fonctions complémentaires
+-----------------------------------
+
+Cette version test la faisabilité des fonctions complémentaires pour
+accompagner la manipulation de champs. Cela comprend en particulier:
+
+* **la sauvegarde des champs produits** dans un fichier med (un champ ou
+ toute la structure med). Pour cela, on définit un med proxy comme
+ l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
+ de fonction au niveau C++ pour permettre un usage au niveau du GUI
+ C++?).
+* **la visualisation d'un champ** au moyen du module VISU.
+* **des fonctions d'aide interactives** pour assister l'utilisateur
+ dans la console de manipulation des champs.
+
+
+Questions:
+
+* peut-on sauvegarder un champ unique?
+* peut-on faire en sorte que ce soit l'affectation à une variable qui
+ provoque l'ajout du champ à la structure med (ou plus exactement qui
+ supprime tous les champs intermédiaires).
+
+
+Révision:
+
+* XMED: svn revision 31
+* MED: cvs tag BR_medop_20101025
+
+
+20110606: commit avant transfert dans git
+-----------------------------------------
+
+* XMED: svn revision 53
+
+Les parties de MED utiles à MEDOP seront reversées dans XMED
+dans une première étape, puis le tout dans MED 6 au final.
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2011
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+Cas d'utilisation métier
+========================
+
+On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
+
+ J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
+ ajouter de nouveaux champs issus de champs existants. J'aimerais
+ aussi pouvoir créer de nouveaux meds plus petits par extraction de
+ certaines composantes de champs, certains groupes ou certains pas de
+ temps.
+
+On peut exprimer le besoin sous la forme des cas d'utilisation
+suivants (use cases):
+
+* **UC1: combiner dans un même fichier med des champs issus de
+ plusieurs sources de données**. On peut par exemple charger un
+ premier fichier, puis ajouter à cette base des champs issus d'autre
+ fichiers ou générés par manipulation de champs, ou encore générés
+ par un module de calcul qui produirait directement du MEDCoupling.
+* **UC2: créer un champ contenant certaines composantes d'un autre
+ champ**. On pense ici aux fonctions de restriction, qui permettraient
+ de récupérer certaines composantes uniquement.
+* **UC3: créer un champ contenant certains pas de temps d'un autre
+ champ**. C'est un cas particulier des fonctions de restriction
+ évoquées ci-dessus.
+* **UC4: créer un champ comme la limitation d'un autre champ à un
+ groupe de mailles**. C'est un cas particulier des fonctions de
+ restriction évoquées ci-dessus. Notion de domaine spatial. A
+ priori la notion de groupe est définie dans MEDLoader.
+
+On peut ajouter également les UC identifiés pour la maquette 2010:
+
+* **UC5: comparer des champs issus de source de données différentes**,
+ par exemple des champs chargés de deux fichiers med différents et
+ qui s'appuient sur le même maillage (au moins conceptuellement). Le
+ problème technique ici est de pouvoir changer le maillage d'un
+ champ, pour ramener tous les champs sur le même maillage (au sens
+ informatique). Ceci est une contrainte de MEDCoupling, les
+ opérations sur des champs A et B imposent que A et B soient définis
+ sur le même maillage, i.e. le même objet informatique.
+* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
+ de mailles. Ce cas d'usage est typiquement prévu pour produire les
+ conditions de chargement initial d'une structure. Il s'agit ici
+ d'initialiser un champ à partir de zéro sur une surface prédéfinie
+ de la géométrie (par exemple spécifiée par un nom de groupe de
+ mailles).
+
+Pour UC5: les sources de données sont référencées dans l'object
+browser. On importe explicitement les données dans l'espace de
+travail. On peut détecter que les maillages sont identiques et on
+propose à l'utilisateur de transférer le champ sur le maillage déjà
+présent. Sinon, les champs devront être référencés sur des maillages
+distincts dans l'arbre de l'espace de travail.
+
+Analyses préliminaires pour le chantier 2011
+============================================
+
+On fait le choix pour le chantier 2011 de travailler à partir de la
+bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
+le démonstrateur 2011).
+
+Analyse de MEDCoupling et MEDLoader
+-----------------------------------
+
+MEDCoupling est l'implémentation du modèle de données MED (avec
+recherche de minimisation des dépendances logicielles) et MEDLoader
+fournit une ensemble de fonctions pour le chargement des structures
+MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
+forme de fichiers.
+
+Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
+d'une grandeur physique sur un maillage pour un pas de temps donné. Un
+champ est caractérisé par:
+
+* un support spatial, le maillage
+* un type de discrétisation spatial, défini par l'emplacement des
+ valeurs sur le maillage (sur les noeuds, sur les cellules, aux
+ points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
+ etc)
+* un pas de temps, défini par deux entiers (iteration, order) et un
+ réel (timestamps)
+
+Dans cette implémentation, il existe une association 1..n entre un
+maillage et un champ (alors que dans MEDMEM, la structure
+intermédiaire SUPPORT est implémentée).
+
+MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
+des structures MEDCoupling au travers du bus CORBA. L'interface à ce
+jour est délibérément réduite. Des classes dites "Cliente" sont
+fournies pour piloter les servants CORBA depuis un contexte
+client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
+fonction de création d'une structure MEDCoupling à partir d'un
+pointeur vers un servant CORBA. La structure est créée localement
+(dans le contexte client) avec duplication des données issue de la
+structure encapsulée par le servant CORBA (récupération par la
+fonction de sérialisation).
+
+Aucune interface CORBA n'est défini pour MEDLoader.
+
+Questions:
+
+* Voir comment sont créés les servants, et surtout comment ils sont
+ récupérés (via le lcc?)
+* Comment peut-on définir un champ sur un groupe de mailles (et non
+ pas sur le maillage complet)? Comment peut-on extraire le champs
+ circoncit à une groupe de mailles pour des opérations.
+
+ - R: méthode changeUnderlyingMesh
+
+* Comment manipuler deux champs chargées de fichiers différents mais
+ construit sur le même maillage (conceptuellement). On peut forcer la
+ réassociation d'un champ sur un autre maillage?
+* Manipuler des champs de pas de temps différents? Différentes
+ composantes d'un ou plusieurs champs?
+* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
+
+* mapper sur une image
+
+Improvments:
+
+* MEDLoader::Write should raise an exception if the filepath is not writable
+* MEDDataManager: développer une classe chapeau sur MEDCoupling et
+ MEDLoader pour aider au chargement et la gestion de données MED
+ (orienté manipulation de champs). Cette classe serait associée des
+ structures légères FieldHandler et MeshHandler et des listes
+ correspondantes pour la navigation dans les méta-données.
+* Sur base du MEDDataManager, prévoir des ports med pour yacs par
+ lesquels pourrait transiter des handler.
+
+Nouveaux concepts à prendre en compte
+-------------------------------------
+
+Au démarrage du chantier 2011, on observe que les concepts suivants
+sont introduits dans le module MED:
+
+* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
+ les fichiers med et obtenir les informations générales sur le
+ contenu.
+* MEDFILEBROWSER: remplace le concept de driver et fournit les
+ fonctions précédemment fournies par la classe MED pour obtenir les
+ informations de structure.
+* Concept d'Extractor pour une lecture sélective des données de champs
+ (suivant un critère d'extraction)
+* Il n'est plus nécessaire d'appeler les méthodes read explicitement
+ sur les objets (MESH et FIELD) pour charger les données. Par
+ ailleurs, on peut définir deux fois le même champs (double
+ chargement a priori) sans lever d'exception).
+
+
+Analyse de conception pour le chantier 2011
+===========================================
+
+Composants SALOME (interfaces IDL)
+----------------------------------
+
+* MEDDataManager: défini une structure FIELD pour identifier un champ
+ dans les requêtes. Il s'occupe également de la récupération physique
+ des données, quelqu'en soit la source (fichier avec MEDLoader, autre
+ module SALOME comme PARAVIS avec une méthode à définir)
+* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
+ les structures FIELD du MEDDataManager. Reprendre l'interface de
+ MEDOP.
+
+Use case à réaliser depuis un client python:
+
+* UC01: ajouter un fichier d'entrée et accéder aux informations
+ concernant les champs. Ex: récupérer une structure champs par la
+ donnée des paramètres primaires (nom identifiant, dt, it, nom du
+ maillage).
+* UC02: créer des champs et les ajouter au MEDDataManager
+* UC03: mener des opérations basique sur les champs en console python
+
+Interface Utilisateur
+---------------------
+
+L'interface utilisateur est composée des parties suivantes:
+
+* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
+ le chargement des données dans l'espace de travail, au moyen d'une
+ interface graphique;
+* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
+ la création de champs, au moyen de commandes exécutées dans la
+ console python.
+
+Le principe est que les champs sont préalablement chargés au niveau du
+composant SALOME au moyen de l'interface graphique (MEDGUI), puis
+manoeuvrés depuis l'application SALOME au moyen de variables proxy
+définies dans la console python (MEDTUI). Au chargement, les champs
+sont indéxés par le MEDDataManager, puis les index sont rendus
+accessibles au niveau du GUI au moyen d'une représentation
+arborescente de la structure MED. Les feuilles de l'arbre
+correspondent à des champs qui peuvent être sélectionnés et dont
+l'index peut être obtenu de la sélection.
+
+L'espace de travail est organisé autour du concept de
+"workspace". L'étude SALOME liste les datasource (les fichiers source
+des données med, mais peut-être aussi les référence vers des objets
+MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
+permet de voir la structure fine d'une source de données.
+
+Concernant MEDGUI:
+
+* la représentation des données (les champs et les maillages associés)
+ doit permettre de récupérer par l'interface graphique les
+ identifiants des champs à manipuler (a priori les structures FIELD
+ définies par le composant MEDDataManager). Cela conduit à la mise en
+ place des composants suivants:
+
+ - MedDataModel hérité de TreeData. Il est peuplé avec les
+ méta-données décrivant la structure MED explorée.
+ - MedGuiManager qui permet l'implantation du doc widget de
+ présentation
+
+TODO:
+
+* specifier le concept de workspace (qui a une entrée dans l'étude?)
+ en bijection avec un datamanager
+* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
+
+Concernant MEDTUI:
+
+* Il fournit les classes FieldProxy
+
+Questions:
+
+* Comment traiter le cas du travail sur des composantes ciblées, plus
+ généralement, comment introduire le concept de domaine
+ d'application?
+* Prévoir des fonctions génériques (initialisation d'un champ sur un
+ maillage avec une fonction analytique de la position, sauvegarder
+ les champs créés dans un fichier med)
+
+
+Tâches de développement
+=======================
+
+T20110622.1: Gestion des données internes
+-----------------------------------------
+
+**Status: terminé.**
+Suite: fonction de sauvegarde au niveau graphique également
+
+On vise les cas d'utiliation suivants:
+
+* UC1: intégrer dans le datamodel du gui un champ créé dans la console
+ python (et donc présent dans le datamanager du composant). Définir
+ l'utilité?
+* UC2: renommer un champ et plus généralement changer ses méta-données
+ (avec assurance de synchronisation entre toutes les données).
+* UC3: sauvegarder une sélection de champs. La sélection peut se faire
+ dans l'arbre du datamodel gui.
+
+WARN: robustesse de fieldproxy
+
+
+
+T20110622.2: UC Initialisation/Création de champs
+-------------------------------------------------
+
+**Status: à faire**
+
+Les cas implémentés à ce jour sont la création de champs à partir de
+champs existants et chargés d'un fichier med. On souhaite ici réaliser
+des cas 'utilisation autour de la création de champs "from scratch",
+s'appuyant tout de même sur un maillage chargé.
+
+UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
+champ (par exemple les conditions limites d'un problème de calcul).
+
+UC02: créer un champ avec des restrictions qui définissent le domaine
+d'application des opération de champs.
+
+UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
+composantes du champs vectoriel ou niveaux de gris pour un champ
+scalaire. Attention, pour ça, il faudra a priori fiare une projection
+du maillage cartesien de l'image sur le maillage (quelconque) sur
+lequel on souhaite définir le champ.
+
+UC04: créer un champ à partir d'un tableau numpy
+
+De manière générale, ce type de création sera assisté par le
+MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
+pour l'utilisateur.
+
+Par exemple, prévoir un menu contextuel qui propose les opérations
+possibles en fonction de la sélection (en plus de la fonction d'import
+dans la console python).
+
+TODO:
+
+* développer les fonctions d'initialisation, par exemple au moyen
+ d'applyFunc et du mécanisme de callable?
+
+T20110622.3: documentation contextuel
+-------------------------------------
+
+**Status: à faire**
+
+* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
+ et fieldtools)
+* Faire un modèle générique de command (classe de base
+* Batir la doc des commandes sur cette base (lister toutes les
+ instances de type Command par exemple)
+
+T20110622.4: remontée des exception du composant MEDCalculator
+--------------------------------------------------------------
+
+**Status: en cours, compléter la couverture**
+
+Pour des messages contextuel sur les erreurs de calcul (ex: division
+par 0)
+
+* Poursuivre le travail fait sur getMedEventListener
+* Protéger tous les appels au composants effectués depuis la console
+ python (prendre example sur la commande save)
+
+T20110624.1: gestion des données GUI
+------------------------------------
+
+**Status: à faire**
+
+
+
+Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
+
+* supprimer: supprime tout les champs associés
+* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
+ cocher ceux qu'on veut sauvegarder.
+
+Le gui data model est réservé aux opérations sur les champs et à
+piloter leur import dans la console python.
+
+TODO:
+
+* Spécifier les concepts de workspace, database, et datasource, espace
+ de gestion, ... et les associations. Simplifier avec l'appuie de use
+ cases.
+* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
+ l'ajout addChild est implémenté
+* Clic droit sur objets de l'arbre: dans la notification TreeView ->
+ WorkspaceController, faire remonter l'évènement clic droit ainsi que la
+ liste des éléments sélectionné pour faire générer le menu contextuel
+ au niveau du WorkspaceController qui peut déterminer le contexte métier
+ (le TreeView ne le connaît pas).
+* Définir des DataObject pour les maillages, les séries temporelles et
+ les champs
+
+
+Spécification des espaces de données:
+
+* MEDDataManager dépend de l'étude (pour permettre la publication
+ d'information dans une étude SALOME).
+* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
+ requetes getFields(sourceid), getMeshes(sourceid)
+* les espaces de données: dataspace, workspace. Un seul workspace par
+ étude, mais autand de datasources que l'on souhaite dans le
+ dataspace. Les datasources sont rangés dans l'étude (le dataspace)
+ et sont non modifiables après chargement (référence des sources de
+ données).
+
+
+T20110628.1: extention à d'autres objets SALOME
+-----------------------------------------------
+
+**Status: suspendu**
+
+On doit reposer la question de l'existance de l'arbre indépendant
+(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
+SMESH en particulier) du principe de sélection graphique pour
+utilisation dans la console python, d'autre part.
+
+
+T20110628.2: visualisation d'un champ avec PARAVIS
+--------------------------------------------------
+
+**Status: terminé (pour une première version)**
+Suite: de nombreux défauts subsistent
+
+Questions/remarques:
+
+* Pb au démarrage du module: VisTrails fails to start
+* Peux-t-on piloter la vue 3D sans charger le module? (voir
+ myparavis.py)
+* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
+* Comment utiliser directement les objets MEDCouplingField?
+
+
+T20110706.1: documentation du module
+------------------------------------
+
+**Status: en cours (10%)**
+
+Documenter les commandes TUI puis l'utilisation générale de
+l'interafce graphique. Mentionner l'existance de la commande medop.sh
+pour travailler exclusivement en mode texte (utile pour les tests
+rapides).
+
+Documenter les modalités d'exécution des tests.
+
+T20110708.1: helper python pour MEDCoupling
+-------------------------------------------
+
+**Status: en attente (pas urgent)**
+
+Faire un helper python dans le package xmed qui permet de faire du
+medcoupling facilement (essentiellement pour simplifier le chargement,
+puis la sélection des données). Cela demanderait de faire un
+MedDataManager comme une class C++ pure (non CORBA). Cette classe
+travaillerait par exemple uniquement avec des id et des liste d'id, et
+fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
+pour obtenir des meta-information.
+
+Le servant MedDataManager pourrait être une surcouche de cette classe
+c++ pure.
+
+T20110708.2: analyses et tests
+------------------------------
+
+TODO:
+
+* créer un fichier de test avec plusieurs pas de temps
+* créer un fichier de test avec des groupes de mailles
+
+
+T20110728.1: refactoring MEDDataManager
+---------------------------------------
+
+Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
+
+* dans la mesure du possible utiliser les id plutôt que les handler en
+ arguments des fonctions d'appel des objets
+* A chaque champ (FieldHandler), on doit associer un meshid (et de
+ manière optionnelle un fieldseriesId, si le champ peut être associé
+ à une serie temporelle. A priori faisable uniquement au chargement
+ du datasource).
+* Pour cela, revoir les fonctions internes newFieldHandler et addField
+ ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
+ les informations concernant le meshid.
+* addField est utilisée par le MEDCalculator
+* Attention au raffraichissement des données handler au niveau du
+ Workspace. Peut-être le mieux est que les fieldproxy contiennent
+ uniquement le fieldid, et qu'ils interroge le datamanager à chaque
+ fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
+ via le MEDEventListener? **Le plus simple est de faire la mise à
+ jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
+ on essaye d'afficher les données**. Parceque sinon il n'y a pas de
+ problème puisque que le calculateur travaille à partir des id.
+
+
+Petites améliorations du DataspaceController:
+
+* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
+ l'alias python dans un attribut du sobject.
+* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
+ est posé dans le WS. On peut donc proposer en option de lui associer
+ un alias pour manipulation dans la console
+
+
+
--- /dev/null
+.. meta::
+ :keywords: maillage, champ, manipulation
+ :author: Guillaume Boulant
+
+.. include:: medcalc-definitions.rst
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+ANNEXE: Note de travail concernant le chantier XMED 2012
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+.. contents:: Sommaire
+ :local:
+ :backlinks: none
+
+
+Analyse preliminaire pour le chantier 2012
+==========================================
+
+La figure imposée pour le chantier 2012 est l'intégration du nouveau
+module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
+préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
+
+L'état actuel est:
+
+* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
+ MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
+ aujourd'hui obsolètes ou amener à disparaître pour l'échéance
+ SALOME7
+* Un module SALOME de nom XMED qui fournit les fonctions graphiques
+ pour la manipulation de champs.
+* Ce module XMED utilise le module VISU pour les vue de contrôle.
+
+La cible est:
+
+* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
+ packages logiciels obsolètes et intégrant les fonctions graphiques
+ (GUI et TUI).
+* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
+ contrôle.
+* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
+ exemple).
+
+A examiner:
+
+* voir les attendus concernant les ports MED dans YACS
+* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
+
+Tâches de développement
+=======================
+
+20120904: Migrer XMED dans MED
+------------------------------
+
+Plan de travail:
+
+* Migration des composants + test
+
+
+
+20120904: Nettoyage de XSALOME
+------------------------------
+
+:status: en cours
+
+* Supprimer les vieilleries de XSALOME:
+
+ - StdHelper -> Basic_Utils (KERNEL)
+
+20120829: mise en place du chantier 2012
+----------------------------------------
+
+:status: terminé
+
+L'objectif de cette première étape est de reverser le prototype 2011
+(module XMED indépendant) dans la branche V6_main du module MED. On
+peut procéder de la manière suivante:
+
+* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
+ V6_main
+* 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
+
--- /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(image2med)
--- /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
+#
+
+SET(MED_PYTHON_SCRIPTS
+ image2med.py
+ )
+
+INSTALL(FILES ${MED_PYTHON_SCRIPTS} DESTINATION ${SALOME_INSTALL_BINS}/med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ)
--- /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_DEFINITIONS(${MEDFILE_DEFINITIONS} ${XDR_DEFINITIONS} ${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
+INCLUDE(${QT_USE_FILE})
+SET(QT_LIBS "${QT_LIBRARIES}")
+INCLUDE(UseQt4Ext)
+
+ADD_SUBDIRECTORY(dialogs)
+
+
+SET(MEDCALCGUI_SOURCES
+ MEDFactoryClient.cxx
+ XmedConsoleDriver.cxx
+ WorkspaceController.cxx
+ XmedDataModel.cxx
+ MEDEventListener_i.cxx
+ MEDModule.cxx
+ DatasourceController.cxx
+ factory.cxx
+)
+
+SET(MEDCALCGUI_HEADERS MEDModule.hxx MEDEventListener_i.hxx WorkspaceController.hxx DatasourceController.hxx)
+
+QT4_WRAP_CPP(MEDCALCGUI_HEADERS_MOC ${MEDCALCGUI_HEADERS})
+
+INCLUDE_DIRECTORIES(
+ ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
+ ${CAS_INCLUDE_DIRS}
+ ${Boost_INCLUDE_DIRS}
+ ${PTHREAD_INCLUDE_DIR}
+ ${GUI_INCLUDE_DIRS}
+ ${CMAKE_CURRENT_BINARY_DIR}
+ ${CMAKE_CURRENT_SOURCE_DIR}/dialogs
+ ${CMAKE_CURRENT_BINARY_DIR}/dialogs
+ ${CMAKE_CURRENT_SOURCE_DIR}/../cmp
+ ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDGUI
+ ${PROJECT_BINARY_DIR}/idl
+ ${PROJECT_BINARY_DIR}
+)
+
+SET(MEDCALCGUITS_SOURCES
+ MED_images.ts
+ MED_msg_en.ts
+ MED_msg_fr.ts
+ MED_msg_ja.ts
+ MEDCALC_msg_en.ts
+ MEDCALC_msg_fr.ts
+ MEDCALC_msg_ja.ts
+)
+
+SET(COMMON_FLAGS
+ ${CAS_KERNEL}
+ ${QT_MT_LIBRARIES}
+ ${OMNIORB_LIBRARIES}
+ ${PLATFORM_LIBRARIES}
+ ${BOOST_LIBRARIES}
+ SalomeIDLMED
+ MEDCALCGUI_dialogs
+ MEDFactoryEngine
+ ${GUI_qtx}
+ ${GUI_suit}
+ ${GUI_SalomeObject}
+ ${KERNEL_SalomeLifeCycleCORBA}
+ ${KERNEL_SalomeKernelHelpers}
+ ${GUI_SalomeApp}
+ ${GUI_SalomeGuiHelpers}
+ ${GUI_SalomeTreeData}
+ ${KERNEL_OpUtil}
+ ${GUI_CAM}
+ ${GUI_LightApp}
+ ${GUI_PyConsole}
+)
+
+ADD_LIBRARY(MEDCALCGUI SHARED ${MEDCALCGUI_SOURCES} ${MEDCALCGUI_HEADERS_MOC})
+IF(WITH_MEDMEMGUI)
+ SET_TARGET_PROPERTIES(MEDCALCGUI PROPERTIES COMPILE_FLAGS "-D__WITH_MEDMEMGUI__")
+ENDIF(WITH_MEDMEMGUI)
+TARGET_LINK_LIBRARIES(MEDCALCGUI ${COMMON_FLAGS})
+
+INSTALL(TARGETS MEDCALCGUI DESTINATION ${SALOME_INSTALL_LIBS})
+QT4_INSTALL_TS_RESOURCES("${MEDCALCGUITS_SOURCES}" "${SALOME_MED_INSTALL_RES_DATA}")
+
+FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
+INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
--- /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_DEFINITIONS(${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
+
+INCLUDE(UseQt4Ext)
+
+SET(MEDCALCGUI_dialogs_FORMS
+ GenericDialog.ui
+ DlgAlias.ui
+ DlgUseInWorkspace.ui
+ DlgChangeUnderlyingMesh.ui
+ DlgInterpolateField.ui
+ DlgImageToMed.ui
+)
+QT4_WRAP_UI(MEDCALCGUI_dialogs_FORMS_HEADERS ${MEDCALCGUI_dialogs_FORMS})
+
+SET(MEDCALCGUI_dialogs_FILES
+ GenericDialog.hxx
+ DlgAlias.hxx
+ DlgUseInWorkspace.hxx
+ DlgChangeUnderlyingMesh.hxx
+ DlgInterpolateField.hxx
+ DlgImageToMed.hxx
+)
+QT4_WRAP_CPP(MEDCALCGUI_dialogs_HEADERS_MOC ${MEDCALCGUI_dialogs_FILES})
+
+INCLUDE_DIRECTORIES(
+ ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
+ ${CAS_INCLUDE_DIRS}
+ ${Boost_INCLUDE_DIRS}
+ ${PTHREAD_INCLUDE_DIR}
+ ${CMAKE_CURRENT_BINARY_DIR}
+ ${GUI_INCLUDE_DIRS}
+ ${CMAKE_CURRENT_SOURCE_DIR}/..
+ ${QT4_INCLUDE_DIRECTORY}
+)
+
+SET(MEDCALCGUI_dialogs_SOURCES
+ GenericDialog.cxx
+ DlgAlias.cxx
+ DlgUseInWorkspace.cxx
+ DlgChangeUnderlyingMesh.cxx
+ DlgInterpolateField.cxx
+ DlgImageToMed.cxx
+)
+
+ADD_LIBRARY(MEDCALCGUI_dialogs SHARED ${MEDCALCGUI_dialogs_SOURCES} ${MEDCALCGUI_dialogs_HEADERS_MOC} ${MEDCALCGUI_dialogs_FORMS_HEADERS})
+TARGET_LINK_LIBRARIES(MEDCALCGUI_dialogs ${CAS_KERNEL} ${QT_LIBRARIES} ${KERNEL_SalomeIDLKernel}
+ ${GUI_SalomeGuiHelpers} ${OMNIORB_LIBRARIES} ${GUI_qtx} ${GUI_suit} ${PLATFORM_LIBRARIES}
+ ${KERNEL_SalomeLifeCycleCORBA} ${KERNEL_SalomeKernelHelpers} ${GUI_SalomeGuiHelpers})
+INSTALL(TARGETS MEDCALCGUI_dialogs DESTINATION ${SALOME_INSTALL_LIBS})
+
+#
+# ---------------------------------------------------------
+# Unit test programs
+# ---------------------------------------------------------
+#
+ADD_EXECUTABLE(dlgTester dlgTester.cxx)
+TARGET_LINK_LIBRARIES(dlgTester MEDCALCGUI_dialogs ${QT_LIBS} ${PLATFORM_LIBS})
+INSTALL(TARGETS dlgTester DESTINATION ${SALOME_INSTALL_BINS})
+#ADD_TEST(dlgTester dlgTester)
+
+FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
+INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
--- /dev/null
+# Copyright (C) 2007-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(testfiles)
+
+SET(MED_RESOURCES_FILES
+ datasource_add.png
+ datasource_changeUnderlyingMesh.png
+ datasource_interpolateField.png
+ datasource_expandfield.png
+ datasource_field.png
+ datasource_mesh.png
+ datasource.png
+ datasource_use.png
+ datasource_view.png
+ fileimport-32.png
+ folder.png
+ image_add.png
+ MEDCalc.png
+ MEDCalc_small.png
+ workspace_clean.png
+ workspace_save.png
+ )
+INSTALL(FILES ${MED_RESOURCES_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
--- /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
+#
+
+SET(MED_FILES
+ testfield.med
+ smallmesh_varfield.med
+ smallmesh_constfield.med
+ bigmesh.med
+ fieldlena.med
+ timeseries.med
+ parametric_01.med
+ parametric_02.med
+ enceinte-axis-E500000.med
+ enceinte-axis-E600000.med
+ entaille.med
+ padderoutput.med
+ )
+
+INSTALL(FILES ${MED_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medcalc_testfiles)
+
+SET(MED_IMG_FILES
+ irm_test1.png
+ irm_test2.png
+ # extra
+ README.txt
+ champ_altitude_MAP.pgm
+ )
+
+INSTALL(FILES ${MED_IMG_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medcalc_testfiles)
--- /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
+#
+
+SET(PYFILES_TO_INSTALL
+ __init__.py
+ fieldproxy.py
+ medconsole.py
+ medcorba.py
+ medevents.py
+ medimages.py
+ medio.py
+ medpresentation.py
+ )
+
+SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON}/medcalc)
--- /dev/null
+Note that this test scripts required the PIL python library
+
--- /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
+#
+
+# This configuration comes in extension with the standard configuration
+# defined by the file envlight.sh for image processing and math
+# processing.
+
+#------ Python Imaging Library ------
+PILDIR=/opt/programs/salome/workspace/prerequisites/install/Pil-117-py266-tcl859-tk859
+export PATH=${PILDIR}/bin:$PATH
+export PYTHONPATH=${PILDIR}/lib/python2.6/site-packages:${PYTHONPATH}
+
+#------ Numpy ------
+NUMPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Numpy-151-py266-la331
+export PATH=${NUMPY_DIR}/bin:${PATH}
+export PYTHONPATH=${NUMPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
+
+# ------ Scipy ------
+SCIPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Scipy-090-py266-la331-sw204-nu151
+export PYTHONPATH=${SCIPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
+
+# WARN: Matplot, sip and pyqt are requires for the plotter used in
+# lagrange.py (could be optional)
+
+# ------ Matplot ----
+MATPLOT_DIR=/opt/programs/salome/workspace/prerequisites/install/Matplotlib-110-py266-set06c11-num151
+export PYTHONPATH=${MATPLOT_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
+
+#------ sip ------
+SIPDIR=/opt/programs/salome/workspace/prerequisites/install/Sip-4132-py266
+export PATH=${SIPDIR}/bin:${PATH}
+export PYTHONPATH=${SIPDIR}/lib/python2.6/site-packages:${PYTHONPATH}
+export LD_LIBRARY_PATH=${SIPDIR}/lib/python2.6/site-packages:${LD_LIBRARY_PATH}
+
+PYQTDIR=/opt/programs/salome/workspace/prerequisites/install/Pyqt-491p1-py266-qt463p2-sip4132
+#export PYQT_SIPS=${PYQTDIR}/share/sip
+#export PYUIC=${PYQTDIR}/bin/pyuic4
+export PYTHONPATH=${PYQTDIR}/lib/python2.6/site-packages:${PYTHONPATH}
+export PATH=${PYQTDIR}/bin:${PATH}
--- /dev/null
+P5
+# CREATOR: GIMP PNM Filter Version 1.1
+6 6
+255
+¿¿ÿÿ¿¿¿¿ÿÿ¿¿ÿÿ\ 4\aÿÿÿÿ\ 3\ 4ÿÿ¿¿ÿÿ¿¿¿¿ÿÿ¿¿
\ No newline at end of file
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+# 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
+#
+
+# This illustrates how to make a mesh partition using the value of a
+# field defined on this mesh (for example to extract the cells where
+# the field takes a value greater than a threshold L.
+# (Anthony Geay, nov. 2012)
+
+# WRN: this use case does not require a med input file because the
+# data (mesh and field) to work with are created from scratch.
+
+from MEDCoupling import *
+
+# =======================================================
+# Creation of the input data (mesh and field)
+# =======================================================
+#
+# We prepare the input field from scratch instead of load it from a
+# file, but there is no difference
+from MEDCouplingDataForTest import MEDCouplingDataForTest
+m3D=MEDCouplingDataForTest.build3DTargetMesh_1()
+m3D.setName("m3D")
+a=DataArrayDouble.New([1.,1.,1.,-1.,-1.,-1.,-1.,-1.])
+field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
+field.setMesh(m3D)
+field.setArray(a)
+field.checkCoherency()
+field.setName("f")
+
+# Save the field (and associated mesh)
+from MEDLoader import MEDLoader
+MEDLoader.WriteField("partition_input.med",field,True)
+
+# =======================================================
+# Determine the border skin mesh
+# =======================================================
+#
+# We have to determine the 2D mesh that delimits the volume where the
+# field is greater than a threshold L from the volume where the field
+# is lower than this threshold (in this example L=0).
+#
+# WRN: This works in SALOME V660 only
+#
+# _T1A
+L=0.
+arr = field.getArray()
+ids = arr.getIdsInRange(L,1e300)
+m3DSub = field.getMesh()[ids]
+skin = m3DSub.computeSkin()
+MEDLoader.WriteUMesh("partition_skin.med",skin,True);
+# _T1B
+
+# =======================================================
+# Compare to the result in SALOME V650
+# =======================================================
+# SALOME V650 requires a more complicated syntax.
+m2D,desc,descI,revDesc,revDescI=m3DSub.buildDescendingConnectivity()
+numberOf3DVolSharing=revDescI.deltaShiftIndex()
+ids2D=numberOf3DVolSharing.getIdsEqual(1)
+skin_V650=m2D[ids2D]
+# We can check if the two skins are identical
+print "Are two meshes equal between V660 and V650 ?",skin.isEqual(skin_V650,1e-12)
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+
+class Function:
+ def __init__(self, **kwargs):
+ self.kwargs = kwargs
+
+ def function(self, x, **kwargs):
+ # This should be implemented in a derived class
+ raise Runtime("function is not implemented yet")
+
+ def __call__(self, x):
+ # The argument can be a scalar or a list, we have to check
+ # that first.
+ if isIterable(x):
+ y = map(self,x)
+ else:
+ y = self.function(x, **self.kwargs)
+ return y
+
+def isIterable(x):
+ """
+ This returns True if the parameter is an iterable, a list or an
+ array, or any collection object.
+ """
+ try:
+ len(x)
+ return True
+ except TypeError, e:
+ return False
+
+#
+# =====================================================
+# Implementation of standard functions. All function are normalized
+# function: the xrange is [0,1], the yrange is [0,1]
+import numpy
+from scipy.constants import pi
+
+# Note that in this situation, the create another constructor because
+# the parameters can be deduced from one single parameter xlimit. The
+# constructor must create a kwargs dictionary that map the arguments
+# of the method "function"
+class FuncConique(Function):
+ def __init__(self,xlimit):
+ a = 1./(xlimit*xlimit-2*xlimit+1)
+ b = -2.*a
+ c = a
+ d = 1/(xlimit*xlimit)
+ # We call the super constructor to redefine the kwarg
+ # attribute, so that it fits with the arguments of the method
+ # "function":
+ Function.__init__(self,xlimit=xlimit,a=a,b=b,c=c,d=d)
+ # NOTE: Instead of calling the super constructor, we could
+ # redefine directly the kwargs attribute:
+ #self.kwargs = {"xlimit":xlimit,
+ # "a":a, "b":b,
+ # "c":c, "d":d}
+
+ def function(self,x,xlimit,a,b,c,d):
+ if x<xlimit:
+ y=d*x*x
+ else:
+ y=a*x*x+b*x+c
+ return y
+
+
+class FuncChapeau(Function):
+ def function(self,x,xlimit):
+ if x<xlimit:
+ y=x/xlimit
+ else:
+ y=(x-1)/(xlimit-1)
+ return y
+
+class FuncStiffExp(Function):
+ """
+ xlimit : the x position of the top of the function
+ stiffness : the higher it is, the stiffer the function is
+ """
+ def function(self,x,xlimit,stiffness):
+ if x<xlimit:
+ y=numpy.exp(stiffness*(x-xlimit))
+ else:
+ y=numpy.exp(-stiffness*(x-xlimit))
+ return y
+
+class FuncCosinus(Function):
+ def __init__(self,nbPeriods):
+ # The pulsation w must be choosen so that w*xmax=n*2pi where
+ # xmax=1 and n is an integer that corresponds to the number of
+ # oscilations on the xrange [0,xmax].
+ w=nbPeriods*2*pi
+ Function.__init__(self,w=w)
+
+ def function(self,x,w):
+ y=numpy.cos(w*x)
+ return y
+
+class FuncStiffPulse(Function):
+ def __init__(self,xlimit, stiffness, nbPeriods):
+ self.stiffexp=FuncStiffExp(xlimit=xlimit,stiffness=stiffness)
+ self.cosinus=FuncCosinus(nbPeriods=nbPeriods)
+ Function.__init__(self)
+
+ def function(self,x):
+ y=self.stiffexp(x)*numpy.abs(self.cosinus(x))
+ return y
+
+class FuncHeaviside(Function):
+ def function(self,x,xlimit):
+ if x<xlimit:
+ y=0
+ else:
+ y=1
+ return y
+
+class FuncPorte(Function):
+ def function(self,x,xinf,xsup):
+ if x<xinf or x>xsup:
+ y=0
+ else:
+ y=1
+ return y
+
+import lagrange
+class FuncLagrange(Function):
+ def __init__(self,points):
+ """
+ @points : a dictionary whose keys are x values and values are
+ y values to be considered as fixed points for interpolation.
+ """
+ Function.__init__(self)
+ self.polynom = lagrange.lagrange(points)
+
+ def function(self,x):
+ return self.polynom(x)
+
+#
+# =====================================================
+# Unit tests functions
+# =====================================================
+#
+class MyFunction(Function):
+ def function(self,x,a,b):
+ y=a*x+b
+ return y
+
+def TEST_Function():
+ # The parameters of the constructor of MyFunction must be
+ # consistent with the kwargs parameters of the method function of
+ # the class MyFunction (it must map exactly).
+ f=MyFunction(a=3.,b=7.)
+
+ x=2
+ y_ref = 3.*x+7.
+ y_res = f(x)
+ print y_ref
+ print y_res
+ if y_ref != y_res:
+ print "ERR"
+ else:
+ print "OK"
+
+def TEST_Function_withIterable():
+ f=MyFunction(a=3.,b=1.)
+
+ arrX = [0., 1., 2., 3.]
+ arrY = f(arrX)
+
+ arrY_ref = [1., 4., 7., 10.]
+ print "arrY res =%s"%arrY
+ print "arrY ref =%s"%arrY_ref
+
+def TEST_FuncConique():
+ f=FuncConique(xlimit=0.3)
+ from plotter import plot
+ plot(f)
+
+def TEST_FuncChapeau():
+ f=FuncChapeau(xlimit=0.3)
+ from plotter import plot
+ plot(f)
+
+def TEST_FuncStiffExp():
+ f=FuncStiffExp(xlimit=0.3,stiffness=20.)
+ from plotter import plot
+ plot(f)
+
+def TEST_FuncCosinus():
+ f=FuncCosinus(nbPeriods=20)
+ from plotter import plot
+ plot(f, step=0.001)
+
+def TEST_FuncStiffPulse():
+ f=FuncStiffPulse(xlimit=0.3,stiffness=50,nbPeriods=15)
+ from plotter import plot
+ plot(f, step=0.001)
+
+def TEST_FuncHeaviside():
+ f=FuncHeaviside(xlimit=0.3)
+ from plotter import plot
+ plot(f)
+
+def TEST_FuncPorte():
+ f=FuncPorte(xinf=0.3,xsup=0.4)
+ from plotter import plot
+ plot(f)
+
+def TEST_customize_01():
+ f=FuncStiffPulse(xlimit=0.3,stiffness=40,nbPeriods=20)
+
+ # One can customize the final function as follow (in this example,
+ # a linear transform)
+ def myfunc(x):
+ y=5*f(x)+2
+ return y
+
+ from plotter import plot
+ plot(myfunc, step=0.001)
+
+def TEST_customize_02():
+ f=FuncHeaviside(xlimit=0.3)
+
+ # One can customize the final function as follow (in this example,
+ # reverse of heaviside)
+ def myfunc(x):
+ y=1-f(x)
+ return y
+
+ from plotter import plot
+ plot(myfunc)
+
+def TEST_FuncLagrange():
+ points = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
+ f=FuncLagrange(points)
+ from plotter import plot
+ plot(f)
+
+if __name__ == "__main__":
+ TEST_Function()
+ TEST_Function_withIterable()
+ #TEST_FuncConique()
+ #TEST_FuncChapeau()
+ #TEST_FuncStiffExp()
+ #TEST_FuncCosinus()
+ #TEST_FuncStiffPulse()
+ #TEST_FuncHeaviside()
+ #TEST_FuncPorte()
+ #TEST_customize_01()
+ #TEST_customize_02()
+ #TEST_FuncLagrange()
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+import scipy
+def lagrange(points):
+ '''
+ This returns a polynom that fits the points specified in the input
+ dictionary (lagrange interpolation). In this dictionary, the keys
+ are x value and the values are y corresponding values
+ (i.e. y=polynom(x)). The polynom is a scipy polynom and then is a
+ callable (can be used as a function).
+ '''
+ tmp = scipy.poly1d([0])
+ result=scipy.poly1d([0])
+
+ for i in points.keys():
+ numerator=scipy.poly1d([1])
+ denom = 1.0
+ for j in points.keys():
+ if (i != j):
+ tmp = scipy.poly1d([1,-j])
+ numerator = numerator * tmp
+ denom = denom * (i - j)
+ tmp = (numerator/denom) * points.get(i)
+ result = result + tmp
+
+ return result
+
+def points_usingfunction(arrX,function):
+ points={}
+ for x in arrX:
+ points[x] = function(x)
+ return points
+
+def points_usingarray(arrX,arrY):
+ points={}
+ for i in range(len(arrX)):
+ x=arrX[i]
+ y=arrY[i]
+ points[x] = y
+ return points
+
+def sortdict(points):
+ # Sort this dictionary by keys and returns 2 lists, the list of X
+ # and the list of Y, the whole ordered by X
+ keys = points.keys()
+ keys.sort()
+ return keys, [points[key] for key in keys]
+
+import pylab
+import numpy
+def plot(function, start=0., stop=1., step=0.01):
+ """
+ The parameter function must be a callable.
+ """
+ arrX=numpy.arange(start, stop, step, dtype='float64')
+ # function is a callable
+ arrY=map(function,arrX)
+ pylab.plot(arrX, arrY)
+ pylab.show()
+
+
+# ---
+# The points does not need to be ordered by x values
+def TEST_lagrange_01():
+ input = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+def TEST_lagrange_02():
+ input = {0.:0., 0.5:1., 1.:0.}
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+# ---
+# One can create the input dictionary from arrays
+def TEST_lagrange_usingarrays_01():
+ arrX = [0., 0.2, 0.9, 0.6, 1]
+ arrY = [5, 10, 10, 21, 8]
+ input = points_usingarray(arrX,arrY)
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+# Another example using numpy
+def TEST_lagrange_usingarrays_02():
+ arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
+ arrY=numpy.zeros(len(arrX), dtype='float64')
+ arrY[3]=2
+ input = points_usingarray(arrX,arrY)
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+# ---
+# One can create the input dictionary from a function applied to an
+# array of X values
+
+# simple method for mathematical functions
+def TEST_lagrange_usingfunction_01():
+ arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
+ arrY=numpy.cos(10*arrX)
+ input = points_usingarray(arrX,arrY)
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+# General method
+xlimit=0.8
+def chapeau(x):
+ if x<xlimit:
+ y=x
+ else:
+ y=2*xlimit-x
+ return y
+
+def TEST_lagrange_usingfunction_01():
+ arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
+ input = points_usingfunction(arrX,chapeau)
+ polynom = lagrange(input)
+ print polynom
+ plot(function=polynom, start=0., stop=1., step=0.001)
+
+
+if __name__ == "__main__":
+ #TEST_lagrange_01()
+ TEST_lagrange_02()
+ #TEST_lagrange_usingarrays_01()
+ #TEST_lagrange_usingarrays_02()
+ #TEST_lagrange_usingfunction_01()
+ #TEST_lagrange_usingfunction_01()
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+import pylab
+import numpy
+def plot(function, start=0., stop=1., step=0.01):
+ """
+ The parameter function must be a callable.
+ """
+ arrX=numpy.arange(start, stop, step, dtype='float64')
+ # function is a callable
+ arrY=map(function,arrX)
+ pylab.plot(arrX, arrY)
+ pylab.show()
--- /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
+#
+
+import CORBA
+import PARAVIS_Gen_idl
+import SALOME_ContainerManager_idl
+
+from SALOME_NamingServicePy import SALOME_NamingServicePy_i
+
+from MEDCouplingCorba import *
+
+def createALocalMesh():
+ targetCoords=[ 0., 0., 0., 50., 0., 0. , 200., 0., 0. , 0., 50., 0., 50., 50., 0. , 200., 50., 0., 0., 200., 0., 50., 200., 0. , 200., 200., 0. ,
+ 0., 0., 50., 50., 0., 50. , 200., 0., 50. , 0., 50., 50., 50., 50., 50. , 200., 50., 50., 0., 200., 50., 50., 200., 50. , 200., 200., 50. ,
+ 0., 0., 200., 50., 0., 200. , 200., 0., 200. , 0., 50., 200., 50., 50., 200. , 200., 50., 200., 0., 200., 200., 50., 200., 200. , 200., 200., 200. ];
+ targetConn=[0,1,4,3,9,10,13,12, 1,2,5,4,10,11,14,13, 3,4,7,6,12,13,16,15, 4,5,8,7,13,14,17,16,
+ 9,10,13,12,18,19,22,21, 10,11,14,13,19,20,23,22, 12,13,16,15,21,22,25,24, 13,14,17,16,22,23,26,25];
+ targetMesh=MEDCouplingUMesh.New();
+ targetMesh.setMeshDimension(3);
+ targetMesh.setName("MyMesh3D");
+ targetMesh.setDescription("build3DMesh");
+ targetMesh.allocateCells(12);
+ for i in xrange(8):
+ targetMesh.insertNextCell(NORM_HEXA8,8,targetConn[8*i:8*(i+1)]);
+ pass
+ targetMesh.finishInsertingCells();
+ myCoords=DataArrayDouble.New();
+ myCoords.setValues(targetCoords,27,3);
+ targetMesh.setCoords(myCoords)
+ myCoords.setName("check in case")
+ return targetMesh;
+
+def createALocalField1():
+ m=createALocalMesh()
+ field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
+ field.setMesh(m)
+ da=DataArrayDouble.New()
+ da.setValues([1.,11.,101.,1001., 2.,12.,102.,1002., 3.,13.,103.,1003., 4.,14.,104.,1004., 5.,15.,105.,1005., 6.,16.,106.,1006., 7.,17.,107.,1007., 8.,18.,108.,1008.,],8,4)
+ field.setArray(da)
+ field.setName("vitoo")
+ field.setTime(4.5,3,4)
+ return field
+
+def createALocalField2():
+ m=createALocalMesh()
+ field=MEDCouplingFieldDouble.New(ON_NODES,ONE_TIME)
+ field.setMesh(m)
+ da=DataArrayDouble.New()
+ da.setValues([float(3*i) for i in xrange(27)],27,1)
+ field.setArray(da)
+ field.setName("vitooNode")
+ field.setTime(4.7,9,14)
+ return field
+
+def createALocalMultiField3():
+ fName="FieldOverTimeCorba"
+ m=createALocalMesh()
+ nbOfFields=100
+ fs=nbOfFields*[None]
+ for i in xrange(nbOfFields):
+ fs[i]=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
+ fs[i].setMesh(m)
+ da=DataArrayDouble.New()
+ da.setValues([0.,1.,2.+i,3.,4.,5.,7.],8,1)
+ fs[i].setArray(da)
+ fs[i].setName(fName)
+ fs[i].setTime(1.2+i,9,14)
+ pass
+ ret=MEDCouplingFieldOverTime.New(fs);
+ return ret
+
+def createALocalCMesh4():
+ mesh=MEDCouplingCMesh.New();
+ coordsX=DataArrayDouble.New();
+ arrX=[ -1., 1., 2., 4. ]
+ coordsX.setValues(arrX,4,1);
+ coordsY=DataArrayDouble.New();
+ arrY=[ -2., 4., 8. ]
+ coordsY.setValues(arrY,3,1);
+ coordsZ=DataArrayDouble.New();
+ arrZ=[ -3., 3., 6., 12., 17. ]
+ coordsZ.setValues(arrZ,5,1);
+ mesh.setCoords(coordsX,coordsY,coordsZ);
+ mesh.setName("CMeshSample")
+ return mesh
+
+def createALocalField5():
+ m=createALocalCMesh4()
+ field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
+ field.setMesh(m)
+ da=DataArrayDouble.New()
+ field.setTime(14.5,0,0)
+ da.setValues([float(7*i) for i in xrange(24)],24,1)
+ field.setName("MeshOnCMesh");
+ field.setArray(da)
+ return field;
+
+
+######
+
+orb = CORBA.ORB_init([], CORBA.ORB_ID)
+poa=orb.resolve_initial_references("RootPOA");
+mgr=poa._get_the_POAManager();
+mgr.activate();
+
+###### Searching for
+
+naming_service = SALOME_NamingServicePy_i(orb)
+rp=SALOME_ContainerManager_idl._0_Engines.ResourceParameters("","","",["PARAVIS"],1,10,10,1,1,"first",[])
+cp=SALOME_ContainerManager_idl._0_Engines.ContainerParameters("","get","",1,False,"",rp)
+sm=naming_service.Resolve("/ContainerManager")
+cont=sm.GiveContainer(cp)
+paraviz=naming_service.Resolve("/Containers/%s/FactoryServer/PARAVIS_inst_1"%(cont.getHostName()))
+
+######
+
+meshCorba=MEDCouplingUMeshServant._this(createALocalMesh())
+ior=orb.object_to_string(meshCorba)
+print "mesh : ",ior
+
+f1=MEDCouplingFieldDoubleServant._this(createALocalField1())
+ior2=orb.object_to_string(f1)
+print "Field on cell ",ior2
+
+f2=MEDCouplingFieldDoubleServant._this(createALocalField2())
+ior3=orb.object_to_string(f2)
+print "Field on node ",ior3
+
+fs3=MEDCouplingFieldOverTimeServant._this(createALocalMultiField3())
+fs3.Register()
+ior4=orb.object_to_string(fs3)
+print "Fields over time ",ior4
+
+m2=MEDCouplingCMeshServant._this(createALocalCMesh4())
+ior5=orb.object_to_string(m2)
+print "CMesh 2 : ",ior5
+
+f5=MEDCouplingFieldDoubleServant._this(createALocalField5())
+ior6=orb.object_to_string(f5)
+print "Field on cell CMesh ",ior6
+
+script="""
+src1 = ParaMEDCorbaPluginSource()
+src1.IORCorba = '%s'
+asc=GetAnimationScene()
+rw=GetRenderView()
+dr=Show()\ndr.Visibility = 1
+"""
+
+content=script%(ior4)
+paraviz.ExecuteScript(content)
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2011-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
+#
+
+# This script illustrates the basic usage of MEDCoupling and MEDLoader
+# to generate test data files for various cases of med operation. It
+# illustrates also the usage of numpy to specify the values of the
+# fields when defined on a cartesian mesh (grid).
+# (gboulant - 11/07/2011)
+
+import MEDCoupling as MC
+import MEDLoader as ML
+
+import numpy
+
+#
+# ===============================================================
+# Helper functions to create meshes
+# ===============================================================
+#
+
+def createGridMesh(meshName, nbCellsX, nbCellsY):
+ """
+ The mesh is created using MEDCoupling. The code below creates a
+ cartesian mesh as a grid with nbCellsX segments in the X direction
+ and nbCellsY in the Y direction (nb. cells = nbCellsX * nbCellsY)
+ """
+ print "Creating grid mesh of size %sx%s"%(nbCellsX, nbCellsY)
+ cmesh=MC.MEDCouplingCMesh.New();
+
+ # Create X coordinates
+ nbNodesX = nbCellsX+1
+ stepX = 0.1
+ arrX = [float(i * stepX) for i in range(nbNodesX)]
+ coordsX=MC.DataArrayDouble.New()
+ coordsX.setValues(arrX,nbNodesX,1)
+
+ # Create Y coordinates
+ nbNodesY = nbCellsY+1
+ stepY = 0.1
+ arrY=[float(i * stepY) for i in range(nbNodesY)]
+ coordsY=MC.DataArrayDouble.New()
+ coordsY.setValues(arrY,nbNodesY,1)
+
+ # Create the grid
+ cmesh.setCoords(coordsX,coordsY)
+ cmesh.setName(meshName)
+
+ return cmesh
+
+def unstructuredMesh(cartesianMesh):
+ """
+ Convert the cartesian mesh in unstructured mesh for the need of
+ write function of MEDLoader
+ """
+ print "Creating unstructured mesh from %s"%(cartesianMesh.getName())
+ umesh=cartesianMesh.buildUnstructured();
+ umesh.setName(cartesianMesh.getName())
+ return umesh
+
+#
+# ===============================================================
+# Creating a cartesian mesh
+# ===============================================================
+#
+# The size is the number of discrete values in a direction, and then
+# corresponds to the number of cells in that direction.
+size=80
+#size=512
+
+
+# >>>
+# WARNING: remember the problem of tics and spaces. The parameter
+# "size" is considered to be a number of cells (intervals). The number
+# of nodes in that direction is size+1.
+# <<<
+
+nbCellsX = size
+nbNodesX = nbCellsX+1
+
+nbCellsY = size # The size could be different than the X size
+nbNodesY = nbCellsY+1
+
+meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
+cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
+umesh = unstructuredMesh(cmesh)
+medFileName="gendata.med"
+ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+
+#
+# ===============================================================
+# Creating a scalar field, working with numpy
+# ===============================================================
+#
+
+def createField(fieldName,gridMesh,
+ numpy2Darray,typeOfField=MC.ON_CELLS,
+ iteration=0):
+ """
+ The number of values for the fields is deduced from the sizes of
+ the numpy array. If typeOfField is ON_CELLS, the size is considered
+ as the number of cells, otherwise it's considered as the number of
+ nodes. In any case, it must be consistent with the dimensions of
+ the numpy 2D array.
+ """
+ print "Creating field %s with iteration=%s"%(fieldName,iteration)
+
+ # The sizes are deduced from the numpy array. Note that if
+ # typeOfField is ON_CELLS, then the size should correspond to the
+ # number of cells, while if typeOfField is ON_NODES, then the size
+ # should correspond to the number of nodes
+ [sizeX,sizeY] = numpy2Darray.shape
+
+ # We first have to reshape the 2D numpy array in a 1D vector that
+ # concatenate all the rows
+ data=numpy2Darray.reshape(1,sizeX*sizeY)[0]
+ # Then, we can create a simple list as required by the MEDCoupling
+ # DataArrayDouble. Note also the usage of float type because
+ # MEDCoupling works only with real numbers
+ listdata=list(data)
+
+ # Create the field using the list obtained from the numpy array
+ field = MC.MEDCouplingFieldDouble.New(typeOfField,MC.ONE_TIME);
+ field.setName(fieldName);
+ field.setMesh(gridMesh);
+ field.setIteration(iteration)
+ field.setTimeValue(float(iteration))
+
+ nbComponents=1 # Only one single component for a scalar field
+ nbCells=sizeX*sizeY
+ dataArray=MC.DataArrayDouble.New();
+ dataArray.setValues(listdata,nbCells,nbComponents)
+ field.setArray(dataArray);
+
+ return field
+
+def writeField(fieldName, numpy2Darray,
+ typeOfField=MC.ON_CELLS,
+ iteration=0):
+
+ field = createField(fieldName, umesh, numpy2Darray,
+ typeOfField, iteration)
+ createFromScratch=False
+ ML.MEDLoader.WriteField(medFileName,field,createFromScratch)
+
+
+def createTestNumpy2DArray(sizeX, sizeY):
+ """
+ This illustrates how to create a numpy 2D array for input of the
+ createField function.
+ """
+ rows=[]
+ for irow in range(sizeY):
+ row = numpy.arange(start = irow*sizeY,
+ stop = irow*sizeY+sizeX,
+ step = 1,
+ dtype='float64')
+ rows.append(row)
+
+ numpy2Darray = numpy.vstack(rows)
+ return numpy2Darray
+
+def createTestFieldOnCells():
+ # Test field on cells
+ numpy2Darray = createTestNumpy2DArray(sizeX=nbCellsX, sizeY=nbCellsY)
+ writeField("FieldOnCells", numpy2Darray,
+ typeOfField=MC.ON_CELLS)
+
+def createTestFieldOnNodes():
+ # Test field on nodes
+ numpy2Darray = createTestNumpy2DArray(sizeX=nbNodesX, sizeY=nbNodesY)
+ writeField("FieldOnNodes", numpy2Darray,
+ typeOfField=MC.ON_NODES)
+
+
+#
+# =================================================
+# Creating a time series
+# =================================================
+#
+
+# -------------------------------------------------
+# Simple demo of the principles
+# -------------------------------------------------
+
+# In these functions, (x,y) are the indexes of the element in the
+# numpy array. Note that theses indexes maps the indexes of the
+# cartesian mesh.
+
+# A function can be a simple python function ...
+def f1(x,y):
+ z = 10*x
+ print "x=%s\ny=%s\nz=%s"%(x,y,z)
+ return z
+
+# ... but also a more sophisticated callable object, for example to
+# defines some parameters
+class Function(object):
+ def __init__(self, sizeX, sizeY, param):
+ self.sizeX = sizeX
+ self.sizeY = sizeY
+ self.param = param
+
+ def function(self, x,y):
+ z = self.param*x
+ print "x=%s\ny=%s\nz=%s"%(x,y,z)
+ return z
+
+ def __call__(self, x,y):
+ return self.function(x,y)
+
+fOnNodes=Function(sizeX=nbNodesX, sizeY=nbNodesY, param=10)
+fOnCells=Function(sizeX=nbCellsX, sizeY=nbCellsY, param=3)
+
+def createFunctionField_01():
+ sizeX=nbNodesX
+ sizeY=nbNodesY
+ typeOfField=MC.ON_NODES
+ f=fOnNodes
+ numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
+ writeField("FieldOnNodesUsingFunc", numpy2Darray,typeOfField)
+
+ f=fOnCells
+ sizeX=nbCellsX
+ sizeY=nbCellsY
+ typeOfField=MC.ON_CELLS
+ numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
+ writeField("FieldOnCellsUsingFunc", numpy2Darray,typeOfField)
+
+
+# -------------------------------------------------
+# Using the pyfunctions package to generate data
+# -------------------------------------------------
+
+def createNumpy2DArrayWithFunc(sizeX, sizeY, function):
+ """
+ @function : a callable than can be used as a function of X.
+ Typically function should be an instance of Function object
+ defined in pyfunctions.functions.
+ """
+
+ # X coordinates should range between 0 and 1 to use the normalized
+ # functions. We have to generate sizeX points:
+ step=1./sizeX
+ arrX=[float(i * step) for i in range(sizeX)]
+
+ values = function(arrX)
+
+ # Then on can create the base row for the numpy 2D array
+ rowX = numpy.array(values)
+ # and replicate this row along the Y axis
+ rows=[]
+ for irow in range(sizeY):
+ rows.append(rowX)
+
+ numpy2Darray = numpy.vstack(rows)
+ return numpy2Darray
+
+from pyfunctions.functions import FuncStiffPulse
+def createNumpy2DArrayWithFuncStiff(sizeX, sizeY):
+ f=FuncStiffPulse(xlimit=0.3,stiffness=30,nbPeriods=10)
+ return createNumpy2DArrayWithFunc(sizeX, sizeY, f)
+
+def createFunctionField_02():
+ sizeX=nbCellsX
+ sizeY=nbCellsY
+ typeOfField=MC.ON_CELLS
+ numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
+ writeField("FieldOnCellsUsingFunc02", numpy2Darray,typeOfField)
+
+ sizeX=nbNodesX
+ sizeY=nbNodesY
+ typeOfField=MC.ON_NODES
+ numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
+ writeField("FieldOnNodesUsingFunc02", numpy2Darray,typeOfField)
+
+#
+# =================================================
+# Functions to create custom fields for MEDCalc tests
+# =================================================
+#
+def createTimeSeries():
+ """
+ Create a single med file with a single mesh and a field defined on
+ several time steps (time series).
+ """
+ meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
+ cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
+ umesh = unstructuredMesh(cmesh)
+ medFileName="timeseries.med"
+ ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+
+ sizeX=nbNodesX
+ sizeY=nbNodesY
+ typeOfField=MC.ON_NODES
+
+ nbIterations=10
+ pulseStiffNess = 20
+ pulseNbPeriods = 10
+ for iteration in range(nbIterations):
+ xlimit = float(iteration)/float(nbIterations)
+ f=FuncStiffPulse(xlimit,stiffness=pulseStiffNess,nbPeriods=pulseNbPeriods)
+ numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
+ field = createField("Pulse",umesh,numpy2Darray,typeOfField,iteration)
+ ML.MEDLoader.WriteField(medFileName,field,False)
+
+from pyfunctions.functions import FuncStiffExp
+def createParametrics():
+ """
+ Create 2 med files containing each a mesh (identical) and a field
+ defined on this mesh in each file.
+ """
+ meshName = "Grid_%sx%s_01"%(nbCellsX, nbCellsY)
+ cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
+ umesh = unstructuredMesh(cmesh)
+
+ sizeX=nbNodesX
+ sizeY=nbNodesY
+ typeOfField=MC.ON_NODES
+
+ medFileName="parametric_01.med"
+ ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+ f=FuncStiffExp(xlimit=0.3,stiffness=30)
+ numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
+ fieldName = "StiffExp_01"
+ field = createField(fieldName,umesh, numpy2Darray,typeOfField)
+ ML.MEDLoader.WriteField(medFileName,field,False)
+
+ medFileName="parametric_02.med"
+ umesh.setName("Grid_%sx%s_02"%(nbCellsX, nbCellsY))
+ ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+ f=FuncStiffExp(xlimit=0.4,stiffness=30)
+ numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
+ fieldName = "StiffExp_02"
+ field = createField(fieldName,umesh, numpy2Darray,typeOfField)
+ ML.MEDLoader.WriteField(medFileName,field,False)
+
+def createParametrics_demo():
+ """
+ Create 2 med files containing each a mesh (identical) and a field
+ defined on this mesh in each file.
+ """
+ meshName = "mesh1"
+ cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
+ umesh = unstructuredMesh(cmesh)
+
+ sizeX=nbNodesX
+ sizeY=nbNodesY
+ typeOfField=MC.ON_NODES
+
+ listIteration = [0,1,2,3,4]
+
+ medFileName="parametric_01.med"
+ ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+ fieldName = "field1"
+ for iteration in listIteration:
+ #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=5)
+ f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=10)
+ numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
+ field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
+ ML.MEDLoader.WriteField(medFileName,field,False)
+
+ medFileName="parametric_02.med"
+ umesh.setName("mesh2")
+ ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
+ fieldName = "field2"
+ for iteration in listIteration:
+ #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=6)
+ f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=15)
+ numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
+ field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
+ ML.MEDLoader.WriteField(medFileName,field,False)
+
+
+
+#
+# =================================================
+# Main runner
+# =================================================
+#
+if __name__ == "__main__":
+ #createTestFieldOnCells()
+ #createTestFieldOnNodes()
+ #createFunctionField_01()
+ #createFunctionField_02()
+ #createTimeSeries()
+ createParametrics_demo()
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2011-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
+#
+
+# This use case illustrates the usage of PIL (Python Imaging Library)
+# combined with the MEDCoupling and MEDLoader modules to save an image
+# as a field in a med file.
+# (gboulant - 27/06/2011)
+
+import MEDCoupling as MC
+import MEDLoader as ML
+
+#
+# ===============================================================
+# We first get data from the test image to render as a field
+# ===============================================================
+#
+import scipy, numpy
+# The data field array may be created from the lena image
+#image = scipy.lena()
+# We could either read a real image using the PIL python package.
+from scipy.misc import pilutil
+image = pilutil.imread("images/avatar.png",True)
+
+
+#from PIL import Image
+#im=Image.open("images/irm.png")
+#im=Image.open("images/lena.png")
+#image=pilutil.fromimage(im,True)
+#image=numpy.asarray(im)
+#print image
+
+dim = len(image.shape)
+print "Image space dimension = %d"%dim
+sizeX = image.shape[1]
+sizeY = image.shape[0]
+
+# The sizes defined the number of pixel in a direction, then the
+# number of cells to create in the mesh in that direction.
+
+# We must reshape the matrix of pixel in a 1D vector that concatenates
+# all the rows, and then convert this vector in a simple list of
+# double as required by the MEDCoupling field specification.
+import numpy
+imageDataNArray = image.reshape(1,sizeX*sizeY)[0]
+print imageDataNArray
+
+imageDataNArrayDouble = numpy.array(imageDataNArray, dtype='float64')
+imageDataArrayDouble = list(imageDataNArrayDouble)
+
+#
+# ===============================================================
+# Creating a cartesian mesh with a grid of the size of the image
+# ===============================================================
+#
+
+# >>>
+# WARNING: remember the problem of tics and spaces. The data values
+# are considered as values defined on cells. With size values in a
+# direction, we have to create size+1 mesh nodes in that direction.
+# <<<
+
+# The mesh is created using MEDCoupling
+cmesh=MC.MEDCouplingCMesh.New();
+cmesh.setName("imagemesh")
+
+# We use an arbitrary step between cells (the value does not matter)
+stepX = 0.1
+nbNodesX = sizeX+1
+arrX = [float(i * stepX) for i in range(nbNodesX)]
+coordsX=MC.DataArrayDouble.New()
+coordsX.setValues(arrX,nbNodesX,1)
+
+stepY = 0.1
+nbNodesY = sizeY+1
+arrY=[float(i * stepY) for i in range(nbNodesY)]
+coordsY=MC.DataArrayDouble.New()
+coordsY.setValues(arrY,nbNodesY,1)
+
+cmesh.setCoords(coordsX,coordsY)
+print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
+
+# WARN: In the current state of development of MEDLoader, only
+# unstructured meshes are supported for writting function in med
+# files. We just have to convert the cartesian mesh in an unstructured
+# mesh before creating the field.
+umesh=cmesh.buildUnstructured();
+umesh.setName("imagemesh")
+
+#
+# ===============================================================
+# Creating a scalar field on the mesh using image data
+# ===============================================================
+#
+
+# Create the field using MEDCoupling
+field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
+field.setName("imagefield");
+field.setMesh(umesh);
+# OPTIONAL: We set an arbitrary time step for test purpose
+field.setIteration(3);
+field.setOrder(0)
+
+dataArray=MC.DataArrayDouble.New();
+nbCells = sizeX*sizeY
+nbComponents=1 # For a scalar field
+
+# This example shows haw to initialize all cell with the same
+# value. Just create an array of size nbCells
+# dataArray.setValues(nbCells*[3.4],nbCells,nbComponents)
+
+dataArray.setValues(imageDataArrayDouble,nbCells,nbComponents)
+field.setArray(dataArray);
+
+# The MEDLoader can be used to save all the stuff in a med file. You
+# just have to specify the field and the MEDLoader will save the
+# underlying mesh.
+createFromScratch=True
+ML.MEDLoader.WriteField("fieldimage.med",field,createFromScratch)
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2011-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
+#
+
+# This simple use case illustrates the basic usage of MEDCoupling and
+# MEDLoader to create a cartesian mesh, define a field on this mesh,
+# and save all the stuff in a med file.
+# (gboulant - 27/06/2011)
+
+import MEDCoupling as MC
+import MEDLoader as ML
+
+#
+# ===============================================================
+# Creating a 512x512 cartesian mesh
+# ===============================================================
+#
+# The size is the number of discrete values in a direction, and then
+# corresponds to the number of cells in that direction.
+size=8
+#size=512
+
+# The mesh is created using MEDCoupling. The code below creates a
+# cartesian mesh as a sizexsize grid
+
+# >>>
+# WARNING: remember the problem of tics and spaces. The data values
+# are considered as values defined on cells. With size values in a
+# direction, we have to create size+1 mesh nodes in that direction.
+# <<<
+
+cmesh=MC.MEDCouplingCMesh.New();
+cmesh.setName("512x512 cartesian mesh")
+
+sizeX = size
+nbNodesX = sizeX+1
+stepX = 0.1
+arrX = [float(i * stepX) for i in range(nbNodesX)]
+print "Size of arrX = %d"%len(arrX)
+
+coordsX=MC.DataArrayDouble.New()
+coordsX.setValues(arrX,nbNodesX,1)
+
+sizeY = size
+nbNodesY = sizeY+1
+stepY = 0.1
+arrY=[float(i * stepY) for i in range(nbNodesY)]
+coordsY=MC.DataArrayDouble.New()
+coordsY.setValues(arrY,sizeY,1)
+
+cmesh.setCoords(coordsX,coordsY)
+print cmesh.getSpaceDimension()
+#print cmesh
+
+# WARN: In the current state of development of MEDLoader, only
+# unstructured meshes are supported for writting function in med
+# files. We just have to convert the cartesian mesh in an unstructured
+# mesh before creating the field.
+umesh=cmesh.buildUnstructured();
+umesh.setName("512x512 unstructured mesh")
+
+# This can be used to save the mesh only (can be visualize using
+# SMESH).
+meshFileName = "umesh.med"
+ML.MEDLoader.WriteUMesh(meshFileName,umesh,True);
+
+# Alternatively, you can use a MEDFileMesh to write the mesh in a
+# file.
+medFileCMesh = ML.MEDFileCMesh.New()
+medFileCMesh.setMesh(cmesh)
+medFileCMesh.setName(cmesh.getName())
+meshFileName = "cmesh.med"
+mode = 2
+medFileCMesh.write(meshFileName,mode)
+
+#
+# ===============================================================
+# Creating a scalar field on the 512x512 mesh
+# ===============================================================
+#
+# For the simple test, we create a field that varies in space as
+# field(x,y)=x+y where x and y are coordinates on the mesh
+
+# --- Field on cells
+
+# Create the field
+field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
+field.setName("AnalyticField_onCells");
+field.setMesh(umesh);
+
+nbComponents=1 # Only one single component for a scalar field
+fillFunction="x+y"
+field.fillFromAnalytic(nbComponents,fillFunction);
+
+# The MEDLoader can be used to save all the stuff in a med file. You
+# just have to specify the field and the MEDLoader will save the
+# underlying mesh.
+createFromScratch=True
+ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
+
+# --- Field on nodes
+
+field = MC.MEDCouplingFieldDouble.New(MC.ON_NODES);
+field.setName("AnalyticField_onNodes");
+field.setMesh(umesh);
+field.fillFromAnalytic(nbComponents,fillFunction);
+createFromScratch=False
+ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
+
+
+#
+# ===============================================================
+# Creating a scalar field, working with numpy
+# ===============================================================
+#
+
+# We start by creating a numpy matrix
+import numpy
+rows=[]
+for irow in range(sizeY):
+ row = numpy.arange(irow*sizeY,irow*sizeY+sizeX,dtype='float64')
+ rows.append(row)
+
+marray = numpy.vstack(rows)
+
+# Then, we can reshape the matrix in a 1D vector that concatenate all
+# the rows
+data=marray.reshape(1,sizeX*sizeY)[0]
+# Finally, we can create a simple list as required by the MEDCoupling
+# DataArrayDouble. Note also the usage of float type because
+# MEDCoupling works only with real numbers
+listdata=list(data)
+
+# Create the field using the list obtained from the numpy array
+fieldWithNumpy = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
+fieldWithNumpy.setName("Numpy Field");
+fieldWithNumpy.setMesh(umesh);
+
+nbCells=sizeX*sizeY
+dataArray=MC.DataArrayDouble.New();
+dataArray.setValues(listdata,nbCells,nbComponents)
+fieldWithNumpy.setArray(dataArray);
+
+createFromScratch=False
+ML.MEDLoader.WriteField("fieldtest.med",fieldWithNumpy,createFromScratch)
+
+
--- /dev/null
+#!/usr/bin/env python
+# -*- coding: iso-8859-1 -*-
+# Copyright (C) 2011-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
+#
+
+# This script illustrates how to create a matrix of pixels from data
+# read in an image file. At the end, the cells of the matrix
+# corresponds to the cells of a cartesian mesh that could hold a field
+# whose value is the value of the pixel.
+# (gboulant - 13/11/2011)
+
+from PIL import Image
+from PIL import ImageOps
+import numpy
+
+def image2matrix():
+ # Load the image
+ #img=Image.open("images/avatar.png")
+ img=Image.open("images/tests.pgm")
+
+ # Get a grayscale version
+ imgbw=ImageOps.grayscale(img)
+
+ # Save the image (optionnal)
+ imgbw.save(fp="testsbw.pgm")
+
+ # Get the data
+ imgdata=imgbw.getdata()
+ width,height=imgbw.size
+ print list(imgdata)
+ print width,height
+
+ # Convert the data in a matrix using numpy
+ tab=numpy.array(imgdata,dtype='float64')
+ print list(tab)
+ print tab
+ nbRows=height
+ nbCols=width
+ matrix=numpy.reshape(tab,(nbRows,nbCols))
+ # Note that in the reshape function, the height (sizeY) of the image
+ # is specified first, because it corresponds to the number of rows.
+ print matrix
+ print list(matrix)
+
+import MEDCoupling as MC
+import MEDLoader as ML
+def createMesh(meshname, sizeX, sizeY):
+ """
+ Creating a cartesian mesh with a grid of the size of the image.
+ sizeX and sizeY should be respectively the width and heigth of the
+ image.
+ """
+ # >>>
+ # WARNING: remember the problem of tics and spaces. The data values
+ # are considered as values defined on cells. With size values in a
+ # direction, we have to create size+1 mesh nodes in that direction.
+ # <<<
+
+ # The mesh is created using MEDCoupling
+ cmesh=MC.MEDCouplingCMesh.New();
+ cmesh.setName(meshname)
+
+ # We use an arbitrary step between cells (the value does not matter)
+ stepX = 0.1
+ nbNodesX = sizeX+1
+ arrX = [float(i * stepX) for i in range(nbNodesX)]
+ coordsX=MC.DataArrayDouble.New()
+ coordsX.setValues(arrX,nbNodesX,1)
+
+ # For the Y dimension, we have to reverse the coordinates (the
+ # first pixel is at y=height and not at y=0).
+ stepY = 0.1
+ nbNodesY = sizeY+1
+ lengthY = sizeY*stepY
+ arrY=[float(lengthY - i * stepY) for i in range(nbNodesY)]
+ coordsY=MC.DataArrayDouble.New()
+ coordsY.setValues(arrY,nbNodesY,1)
+
+ cmesh.setCoords(coordsX,coordsY)
+ print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
+
+ # WARN: In the current state of development of MEDLoader, only
+ # unstructured meshes are supported for writting function in med
+ # files. We just have to convert the cartesian mesh in an unstructured
+ # mesh before creating the field.
+ umesh=cmesh.buildUnstructured();
+ umesh.setName("imagemesh")
+
+ return umesh
+
+def createField(fieldname, mesh, image):
+ """
+ Creating a scalar field on the mesh using image data
+ """
+ # Create the field using MEDCoupling
+ field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
+ field.setName(fieldname);
+ field.setMesh(mesh);
+ # OPTIONAL: We set an arbitrary time step for test purpose
+ field.setIteration(0);
+ field.setOrder(0)
+
+ imagedata=list(image.getdata())
+ width,height=image.size
+ nbCells = width*height
+ dataArray=MC.DataArrayDouble.New();
+ nbComponents=1 # For a scalar field
+
+ dataArray.setValues(imagedata,nbCells,nbComponents)
+ field.setArray(dataArray);
+
+ return field
+
+def image2med():
+ img=Image.open("images/avatar.png")
+ #img=Image.open("images/irm.png")
+ imgbw=ImageOps.grayscale(img)
+ # We keep only the grayscale. Maybe, it could be usefull to get
+ # the RGB scales each on one component of the field.
+
+ width,height=imgbw.size
+ mesh=createMesh("mesh",width,height)
+ field=createField("field",mesh,imgbw)
+
+ createFromScratch=True
+ ML.MEDLoader.WriteField("image.med",field,createFromScratch)
+
+
+# ===================================================================
+
+if __name__ == "__main__":
+ #image2matrix()
+ image2med()
--- /dev/null
+all:
+ python tutorial.py
+ python explore.py
+ python manage.py
+ python testamel.py
+ python cmesh
+
+clean:
+ rm -f *~ *.pyc output.med
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+from MEDLoader import MEDLoader
+
+import os
+filename = "madnex_field.med"
+filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
+
+meshName="my_field_RG"
+fieldName="my_field"
+itNumber=0
+itOrder=0
+
+# Load as an unstructured mesh
+meshDimRelToMax = 0 # 0 = no restriction
+umesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
+print "umesh is structured: %s"%umesh.isStructured()
+
+# Load as a structured mesh explicitly
+# _T2A
+from MEDLoader import MEDFileCMesh
+medfile = MEDFileCMesh.New(filepath,meshName)
+cmesh = medfile.getMesh()
+# Note that the getMesh method is a short way to the method:
+#cmesh = medfile.getGenMeshAtLevel(0,False)
+print "cmesh is structured: %s"%cmesh.isStructured()
+# _T2B
+
+# Load and let MEDLoader decide what is nature of the mesh
+# _T1A
+from MEDLoader import MEDFileMesh
+medfile = MEDFileMesh.New(filepath,meshName)
+print medfile.advancedRepr()
+meshDimRelToMax = 0 # 0 = no restriction
+mesh = medfile.getGenMeshAtLevel(meshDimRelToMax)
+print "mesh is structured: %s"%mesh.isStructured()
+# _T1B
+
+
+# Write the mesh to another file
+# _T3A
+outputfilepath="output.med"
+mode=0
+medfile.write(outputfilepath,mode)
+# _T3B
+
+# test to reload the mesh
+medfile = MEDFileCMesh.New(outputfilepath,meshName)
+cmesh = medfile.getMesh()
+print "cmesh is structured: %s"%cmesh.isStructured()
+
+# Q: Is it possible to know if a mesh is structured or unstructured
+# without loading the mesh.
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+from MEDLoader import MEDLoader
+
+import os
+#filename = "madnex_field.med"
+filename = "timeseries.med"
+filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
+
+# Read the source meshes
+meshNames = MEDLoader.GetMeshNames(filepath)
+
+# Set to True if the meshes and fields data must be loaded. Otherwise,
+# only theire descriptions will be loaded.
+READ_PHYSICAL_DATA=False
+
+for meshName in meshNames:
+
+ print "%s"%meshName
+
+ # At this step, one can load the mesh of name meshName (but it is
+ # not an obligation to continue to explore the metadata)
+ meshDimRelToMax = 0 # 0 = no restriction
+ if READ_PHYSICAL_DATA:
+ mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
+ # Note that the read function required the parameter
+ # meshDimRelToMax. This parameter discreminates the meshdim you
+ # are interested to relatively to the maximal dimension of cells
+ # contained in the mesh in file (then its value could be 0, -1, -2
+ # or -3 depending on the max dimension of the mesh. 0 means "no
+ # restriction".
+
+ # Read the names of the fields that rely on this mesh
+ fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
+
+ for fieldName in fieldNames:
+
+ print " %s"%fieldName
+
+ # 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:
+ # 0 = ON_CELLS
+ # 1 = ON_NODES
+ # 2 = ON_GAUSS_PT
+ # 3 = ON_GAUSS_NE
+ #
+ # As a consequence, before loading values of a field, we have
+ # to determine the types of spatial discretization defined for
+ # this field and to chooose one.
+
+ listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
+ for typeOfDiscretization in listOfTypes:
+ print " %s"%typeOfDiscretization
+
+ # Then, we can get the iterations associated to this field on
+ # this type of spatial discretization:
+ fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
+ filepath,
+ meshName,
+ fieldName)
+
+ # Then, we can access to the physical data for each
+ # iteration of this field
+ for fieldIteration in fieldIterations:
+ itNumber = fieldIteration[0]
+ itOrder = fieldIteration[1]
+ print " (%s,%s)"%(itNumber,itOrder)
+
+ if READ_PHYSICAL_DATA:
+ medCouplingField = MEDLoader.ReadField(typeOfDiscretization,
+ filepath,
+ meshName,
+ meshDimRelToMax,
+ fieldName,
+ itNumber,
+ itOrder)
+ print medCouplingField
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+# _T1A
+import collections
+def tree():
+ return collections.defaultdict(tree)
+
+fieldTree = tree()
+meshDict = {}
+# _T1B
+
+import os
+filename = "timeseries.med"
+filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
+
+# _T2A
+from MEDLoader import MEDLoader
+meshNames = MEDLoader.GetMeshNames(filepath)
+
+meshDimRelToMax = 0 # 0 = no restriction
+
+for meshName in meshNames:
+ mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
+ meshDict[meshName] = mesh
+
+ fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
+ for fieldName in fieldNames:
+ listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
+ for typeOfDiscretization in listOfTypes:
+ fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
+ filepath,
+ meshName,
+ fieldName)
+ for fieldIteration in fieldIterations:
+ itNumber = fieldIteration[0]
+ itOrder = fieldIteration[1]
+
+ field = MEDLoader.ReadField(typeOfDiscretization,
+ filepath,
+ meshName,
+ meshDimRelToMax,
+ fieldName,
+ itNumber,
+ itOrder)
+
+ fieldTree\
+ [meshName]\
+ [fieldName]\
+ [typeOfDiscretization]\
+ [itNumber][itOrder] = field
+# _T2B
+
+# Q: use a list of structures whose an attribute could be a
+# MEDCoupling field? Or a tree that you cross using attribute and
+# whose leaves are the MEDCoupling fields?
+# R: I think that the default structure should be a simple list that
+# store objects whith properties that corresponds to the metadata (and
+# if loaded the MEDCouplingField or Mesh). Then for specific request,
+# a BTree could be create to organize the search (for example if we
+# request all the fields for a given iteration step, then we should
+# use the iteration step as a first classifaction switch of the tree
+
+print fieldTree.keys()
+
+# _T3A
+for meshName in fieldTree.keys():
+ print "%s"%meshName
+ for fieldName in fieldTree[meshName].keys():
+ print " %s"%fieldName
+ for fieldType in fieldTree[meshName][fieldName].keys():
+ print " %s"%fieldType
+ for itNumber in fieldTree[meshName][fieldName][fieldType].keys():
+ for itOrder in fieldTree[meshName][fieldName][fieldType][itNumber].keys():
+ print " (%s,%s)"%(itNumber,itOrder)
+ print fieldTree[meshName][fieldName][fieldType][itNumber][itOrder]
+# _T3B
--- /dev/null
+# -*- coding: iso-8859-1 -*-
+# 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
+#
+
+# This illustrates the use of getValueOn in the case of hexahedron
+# meshes (for which a temporary limitation implies the usage of the
+# method simplexize that split the hexahedron into simplex,
+# i.e. triangles and tetrahedrons).
+#
+# (gboulant, nov. 2012)
+from MEDLoader import *
+from MEDCoupling import *
+
+import os
+filename = "timeseries.med"
+filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
+
+rmedfilename = filepath
+
+# Load the meshe data
+meshname = "Grid_80x80"
+fieldname = "Pulse"
+dimrestriction = 0 # no restriction
+msource = MEDLoader.ReadUMeshFromFile(rmedfilename,meshname,dimrestriction)
+
+# WARN: In the current version of MEDCoupling, the getValueOn works
+# only with simplex cells (triangles, tetrahedron). This is not a
+# technical problem, but a question of specification of the
+# interpolation to be performed in the case of other cells, in
+# particular in the case of hexahedron meshes.
+#
+# A temporary solution (with good numerical results) is to split
+# hexahedrons into simplex (before the association of the mesh to the
+# field) using the method simplexize.
+policy = 0
+msource.simplexize(policy)
+
+# Load the field data at iteration 0
+iteration = 0
+order = -1
+fieldOnNodes = MEDLoader.ReadField(ON_NODES,rmedfilename,
+ meshname,dimrestriction,
+ fieldname,iteration,order)
+
+
+fieldOnNodes.setMesh(msource)
+
+# Get the value of field at coordinates x,y
+x=0.5
+y=0.5
+fieldValue = fieldOnNodes.getValueOn([x,y])
+print fieldValue
--- /dev/null
+#!/usr/bin/env python
+# 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
+#
+
+# This script illustrates the basic features of MEDLoader
+# (gboulant, 17 nov 2012)
+import os
+filename = "timeseries.med"
+filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
+
+# _T1A
+from MEDLoader import MEDLoader
+meshNames = MEDLoader.GetMeshNames(filepath)
+# _T1B
+meshName=meshNames[0]
+# _T2A
+fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
+# _T2B
+fieldName=fieldNames[0]
+# _T3A
+listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
+# _T3B
+typeOfDiscretization=listOfTypes[0]
+# _T4A
+fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
+ filepath,
+ meshName,
+ fieldName)
+# _T4B
+
+iteration = fieldIterations[0]
+iterationNumber = iteration[0]
+iterationOrder = iteration[1]
+
+dimrestriction = 0
+# _T5A
+mesh = MEDLoader.ReadUMeshFromFile(filepath, meshName, dimrestriction)
+# _T5B
+# _T6A
+field = MEDLoader.ReadField(typeOfDiscretization,
+ filepath, meshName, dimrestriction,
+ fieldName, iterationNumber, iterationOrder)
+# _T6B
+++ /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(cmp)
-ADD_SUBDIRECTORY(res)
-
-IF(SALOME_BUILD_GUI)
- ADD_SUBDIRECTORY(gui)
-ENDIF()
-
-IF(SALOME_MED_ENABLE_PYTHON)
- ADD_SUBDIRECTORY(tui)
- ADD_SUBDIRECTORY(exe)
-ENDIF()
-
-IF(SALOME_BUILD_DOC)
- ADD_SUBDIRECTORY(doc)
-ENDIF(SALOME_BUILD_DOC)
+++ /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_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${MEDFILE_INCLUDE_DIRS}
- ${HDF5_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${PROJECT_BINARY_DIR}/idl
- ${PROJECT_SOURCE_DIR}/src/MEDCoupling
- ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL/Bases
- ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL
- ${PROJECT_SOURCE_DIR}/src/MEDLoader
-)
-
-SET(MEDOPFactoryEngine_SOURCES
- MEDDataManager_i.cxx
- MEDCalculator_i.cxx
- MEDPresentationManager_i.cxx
- MEDOPFactory_i.cxx
-)
-
-SET(COMMON_LIBS
- medloader
- SalomeIDLMED
- ${KERNEL_TOOLSDS}
- ${KERNEL_SalomeHDFPersist}
- ${KERNEL_SalomeContainer}
- ${KERNEL_SalomeCommunication}
- ${KERNEL_SalomeKernelHelpers}
- ${KERNEL_SalomeLifeCycleCORBA}
- ${KERNEL_SALOMELocalTrace}
- ${KERNEL_SALOMEBasics}
- ${KERNEL_SalomeGenericObj}
- medcoupling
- medcouplingremapper
- interpkernel
- ${MEDFILE_C_LIBRARIES}
- ${HDF5_LIBRARIES}
- ${OMNIORB_LIBRARIES}
- ${PLATFORM_LIBRARIES}
-)
-
-# This undefines the macros MIN and MAX which are specified in the windows headers
-IF(WIN32)
- SET(COMMON_FLAGS "${COMMON_FLAGS} -DNOMINMAX")
-ENDIF(WIN32)
-
-ADD_LIBRARY(MEDOPFactoryEngine SHARED ${MEDOPFactoryEngine_SOURCES})
-SET_TARGET_PROPERTIES(MEDOPFactoryEngine PROPERTIES COMPILE_FLAGS "${COMMON_FLAGS}")
-TARGET_LINK_LIBRARIES(MEDOPFactoryEngine SalomeIDLMED ${COMMON_LIBS})
-
-INSTALL(TARGETS MEDOPFactoryEngine DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB MEDOPFactoryEngine_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${MEDOPFactoryEngine_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
-
-IF(SALOME_ENABLE_PYTHON)
- INSTALL(FILES test_medop_components.py PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS}/xmed)
-ENDIF()
+++ /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="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>
+++ /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
-#
-
-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}")
-
-ADD_CUSTOM_TARGET(html_docs COMMAND ${_cmd})
-
-INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target html_docs)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${SALOME_INSTALL_DOC}/dev/MED)
-
-SET(make_clean_files html doctrees)
-SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${make_clean_files}")
+++ /dev/null
-@import url("default.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
-# -*- coding: iso-8859-1 -*-
-#
-# yacs documentation build configuration file, created by
-# sphinx-quickstart on Fri Aug 29 09:57:25 2008.
-#
-# This file is execfile()d with the current directory set to its containing dir.
-#
-# The contents of this file are pickled, so don't put values in the namespace
-# that aren't pickleable (module imports are okay, they're removed automatically).
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys, os
-
-# If your extensions are in another directory, add it here. If the directory
-# is relative to the documentation root, use os.path.abspath to make it
-# absolute, like shown here.
-#sys.path.append(os.path.abspath('.'))
-
-# General configuration
-# ---------------------
-
-# Add any Sphinx extension module names here, as strings. They can be extensions
-# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ['sphinx.ext.autodoc']
-
-# Uncomment the following line to build the links with Python documentation
-# (you might need to set http_proxy environment variable for this to work)
-#extensions += ['sphinx.ext.intersphinx']
-
-# Intersphinx mapping to add links to modules and objects in the Python
-# standard library documentation
-intersphinx_mapping = {'http://docs.python.org': None}
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = [os.path.join('@CMAKE_CURRENT_SOURCE_DIR@','_templates')]
-
-# The suffix of source filenames.
-source_suffix = '.rst'
-
-# The encoding of source files.
-source_encoding = 'utf-8'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = 'MED, Manipulation de champs dans SALOME'
-copyright = '2010-2015 CEA/DEN, EDF R&D, OPEN CASCADE, G. Boulant, A. Geay'
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short X.Y version.
-version = '@SALOMEMED_VERSION@'
-# The full version, including alpha/beta/rc tags.
-release = '@SALOMEMED_VERSION@'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-language = 'fr'
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-#today_fmt = '%B %d, %Y'
-
-# List of documents that shouldn't be included in the build.
-#unused_docs = []
-
-# List of directories, relative to source directory, that shouldn't be searched
-# for source files.
-exclude_trees = ['.build','ref','images','CVS','.svn']
-
-# A list of glob-style patterns that should be excluded when looking for source
-# files. They are matched against the source file names relative to the
-# source directory, using slashes as directory separators on all platforms.
-exclude_patterns = ['**/CVS']
-
-# The reST default role (used for this markup: `text`) to use for all documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-#show_authors = False
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'sphinx'
-
-
-# Options for HTML output
-# -----------------------
-
-# The theme to use for HTML and HTML Help pages. Major themes that come with
-# Sphinx are currently 'default' and 'sphinxdoc'.
-#html_theme = 'omadoc'
-html_theme_options = {
- "stickysidebar": "false",
- "rightsidebar": "false",
-}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = ['themes']
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# "<project> v<release> documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-
-# 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'
-
-# 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,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = [os.path.join('@CMAKE_CURRENT_SOURCE_DIR@','_static')]
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-html_use_modindex = False
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, the reST sources are included in the HTML build as _sources/<name>.
-html_copy_source = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = ''
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'medopdoc'
-
-
-# Options for LaTeX output
-# ------------------------
-
-latex_elements = {
- # The paper size ('letterpaper' or 'a4paper').
- 'papersize': 'a4paper',
- # Select another font family
- #'fontpkg':'\\usepackage{eucal}',
- # get rid off blank pages
- 'classoptions': ',openany,oneside',
- 'babel' : '\\usepackage[english]{babel}',
- # The font size ('10pt', '11pt' or '12pt').
- #'pointsize': '10pt',
-}
-
-# 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')
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-latex_logo = os.path.join("@CMAKE_CURRENT_SOURCE_DIR@","_static","head.png")
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-latex_use_parts = True
-
-# Additional stuff for the LaTeX preamble.
-#latex_preamble = ''
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-latex_use_modindex = False
-
-# Definition of substitute variables for rst texts
-# ------------------------------------------------
-# The rst_epilog can be used to define variable in conf.py and use the
-# values of these variables in the rst text files.
-srcdir = '@CMAKE_CURRENT_SOURCE_DIR@'
-rst_epilog = '.. |SPHINXDOC_SRCDIR| replace:: %s' % srcdir
+++ /dev/null
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%
- Documentation du module MED
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module SALOME MED (pour Modèle d'Echange de Données) fournit la
-bibliothèque MEDCoupling (bibliothèque C++ dédiée à la manipulation de
-maillages et de champs conformes au modèle MED), ainsi qu'une
-interface graphique pour la réalisation des opérations de manipulation
-les plus usuelles.
-
-Documentation de référence
-==========================
-
-**Documentation d'utilisation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-userguide-gui.rst
- medop-userguide-api.rst
-
-**Documentation technique**
-
-.. toctree::
- :maxdepth: 1
-
- medop-specifications.rst
- medop-develguide.rst
-
-**Documentation annexe**
-
-.. toctree::
- :maxdepth: 1
-
- medop-references.rst
-
-Archives documentaires
-======================
-
-**Documentation du prototype 2010**
-
-Cette section décrit le prototype mis au point en 2010 pour les
-analyses de conception (maquette 2010 sur base MEDMEM)
-
-.. toctree::
- :maxdepth: 1
-
- medop-prototype-overview.rst
- medop-prototype-develguide.rst
- medop-prototype-medmem.rst
-
-**Journal de travail**
-
-.. toctree::
- :maxdepth: 1
-
- medop-workingnotes-2010.rst
- medop-workingnotes-2011.rst
- medop-workingnotes-2012.rst
+++ /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_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_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::
-
- loadDatasource(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
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, documentation technique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Cette note fait la synthèse des développements effectués pour le
-maquettage des fonctions de manipulation de champs dans SALOME. Elle
-présente les principes retenus en matière de conception, c'est-à-dire
-concernant les mécanismes techniques sous-jacents, et en matière
-d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
-l'environnement SALOME.
-
-Ces principes sont illustrés par des développements implantés dans le
-module XMED, développé pour les besoins de l'analyse, et dans le
-module MED distribué avec la plateforme SALOME.
-
-.. note:: la lecture de ce chapitre demande une connaissance de la
- structure de classes du module MED, en particulier la distinction
- entre les classes ``MEDMEM::*`` et les servants CORBA associés
- (classe ``SALOME_MED::*``).
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs
-====================
-
-Objectif et motivation
-----------------------
-
-L'objectif de maquettage est de trouver une architecture technique qui
-permet d'exécuter le cas d'utilisation suivant:
-
-* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Opérations pow, sqrt.
-* Possibilité de visualiser les champs produits avec VISU pour
- contrôle des résultats.
-* Possibilité d'exporter des champs produits dans un fichier med.
-
-Eléments de contexte
---------------------
-
-Les opérations de manipulation de champs sont en grande partie
-implémentées dans la bibliothèque MEDMEM. Pour illustration, le
-fragment de code ci-dessous montre comment une addition de champ peut
-être opérée en python:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-Ceci montre que les champs peuvent être manipulés avec une interface
-relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
-f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
-package MEDMEM et wrapping python du package MEDMEM_SWIG).
-
-Par ailleurs, le fonctionnement actuel des modules SALOME qui
-manoeuvrent des données MED est d'instancier les structures de données
-MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
-servants CORBA hébergés dans le processus ``SALOME_Container``, et de
-donner accés à ces données depuis l'étude SALOME au travers de
-pointeurs CORBA. Ce choix d'architecture présente l'avantage de
-centraliser au niveau serveur la gestion du cycle de vie des données
-informatiques et de pouvoir distribuer des "poignées" pour manipuler
-ces données depuis chaque point de l'application qui sait accéder au
-bus CORBA, l'interface graphique en particulier.
-
-
-Hypothèse de travail
---------------------
-
-Compte-tenu de l'objectif de maquettage et des éléments de contexte
-existant, on cherche une solution dans le cadre des hypothèses
-de travail suivantes:
-
-* La manipulation des champs se fait dans l'environement graphique de
- SALOME.
-* Dans cet environnement, on souhaite pouvoir sélectionner
- graphiquement les champs à considérer, puis manipuler ces champs
- dans l'interface texte au moyen de variables python avec une syntaxe
- aussi simple que celle définie dans le wrapping python de MEDMEM,
- c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
- pouvoir écrire f1+f2.
-* Les données MED sont physiquement dans la partie serveur de SALOME
- et accessibles via des pointeurs CORBA (interface spécifiée dans
- MED.idl). On exclu la recopie de données au niveau du client
- graphique.
-
-Dans le cadre de ces hypothèses, la difficulté technique réside dans
-la mise au point d'une interface de communication entre des variables
-manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
-dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
-instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
-processus ``SALOME_Container``).
-
-
-Eléments de conception
-======================
-
-
-Implantation technique
-----------------------
-
-Le diagramme ci-dessous représente l'organisation des principaux
-paquets logiciels du module MED:
-
-.. image:: images/medmem-layers.png
- :align: center
-
-Les cadres bleus représentent le lieu d'implantation des
-développements effectués dans le module MED pour les besoins du
-maquettage. On notera en particulier les interventions aux niveaux
-suivants:
-
-* interfaces idl: ajout de l'interface MEDOP.idl
-* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
- l'interface MEDOP.idl
-
-Architecture technique
-----------------------
-
-Les schéma ci-dessous représente les objets informatiques qui sont à
-l'oeuvre pour la réalisation des opérations sur les champs:
-
-.. image:: /images/xmed-architecture.png
- :align: center
- :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
-
-On distingue les objets suivants:
-
-* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
- MED chargée en mémoire.
-* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
- chargés en mémoire.
-* Une instances de ``SALOME_MED::MED`` et des instances de
- ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
- structure med et des champs qui lui sont associés et chargés en
- mémoire.
-* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
- centralise la mise en oeuvre des opérations de champs sur le serveur
- ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
- sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
- directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
- de temps.
-* Des instances de ``FieldProxy`` qui correspondent aux variables
- manipulées au niveau de l'interface graphique et qui représentent
- les champs. Une instance de FieldProxy possède détient les
- références des servants ``SALOME_MED::MEDOP`` et
- ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
- ``medop_ptr`` et ``field_ptr`` respectivement.
-* Il existe également une instance de ``MedProxy`` non représentée
- dans ce diagramme. Cette instance correspond à une variable qui
- permet de manipuler la structure med.
-
-.. note:: Les éléments apportés par la maquette sont les classes
- ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
- éléments ont pu être modifiés légèrement pour les besoins de
- l'intégration ou pour la correction de quelques bugs.
-
-Le cycle de vie de ces objets est le suivant.
-
-Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
-des champs ``MEDMEM::FIELD``, la création est faite au moment du
-chargement du fichier med dans SALOME au moyen du module MED. A cette
-occasion, les servants CORBA associés ``SALOME_MED::MED`` et
-``SALOME_MED::FIELD`` sont créés et des références vers ces servants
-sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
-l'utilisateur dans l'interface graphique. L'ensemble de ces données
-préexiste à la manipulation de champs.
-
-Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
-``SALOME_MED::MED`` auquel ils sont associées. Le servant
-``SALOME_MED::MED`` possède une référence sur la structure
-``MEDMEM::MED`` et il la transmet à l'instance du servant
-``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
-autonome par la suite pour manipuler les données MED, et les champs en
-particulier. Le code python ci-dessous montre comment un opérateur med
-``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
-l'addition de deux champs:
-
-.. code-block:: python
-
- 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é à
-une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
-``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
-un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
-``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
-une référence directe sur la structure ``MEDMEM::MED`` et peut la
-manoeuvrer pour demander des champs, faire des opérations avec ces
-champs, ajouter le champs résultat à la structure et enfin retourner
-un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
-
-Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
-instance de ``FieldProxy`` est un objet python qui peut être
-manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
-localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
-ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
-d'usage (cf. paragraphe ci-après). La création d'un objet
-``FieldProxy`` déclenche la création d'un opérateur med (instance de
-``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
-référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
-opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
-opérations possibles sur ce champ, comme illustrer sur l'exemple
-ci-dessus.
-
-
-Rôle des objets proxy
----------------------
-
-Dans le modèle d'architecture présenté ci-dessus, on introduit deux
-types d'objets proxy:
-
-* Les objets de classe ``FieldProxy`` qui représentent des poignées de
- manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
- dans le container SALOME.
-* Les objets de classe ``MedProxy`` qui représentent des poignées de
- manipulation des structures ``MEDMEM::MED`` physiquement instanciées
- dans le container SALOME.
-
-Elles sont instanciées dans l'interpréteur python SALOME pour
-manipulation dans l'interface textuelle à partir de la donnée du
-pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
-champ (le nom du champ et le pas de temps défini par le numéro d'ordre
-et le numéro d'iteration:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
-
- from xmed import fieldproxy
- from xmed import medproxy
-
- f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
- f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
-
- field_somme = f1 + f2
- field_offset = f1 + 5.3
-
-Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
-``field_offset`` sont des objets de classe ``FieldProxy``. Ils
-correspondent aux variables physiquement manipulées par
-l'utilisateur pour désigner les champs dans les opérations.
-
-Ces classes proxy sont conçues pour être le lieu d'implémentation de
-l'interprétation des commandes utilisateur et donc de l'ergonomie
-de manipulation des champs au niveau l'interface textuelle. Ce point
-est développé :ref:`plus bas <develguide_execFieldOperation>`.
-
-Programmation de l'interface textuelle
---------------------------------------
-
-Dans le cadre de la maquette, l'interface de manipulation des champs
-est l'interface textuelle python intégrée à SALOME. Dans la pratique,
-l'utilisateur manipule des variables python qui correspondent à des
-objets de classe ``FieldProxy`` équipées des fonctions requises et de
-l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
-ci-dessus).
-
-Or, l'hypothèse de travail est que les données MED sont chargées dans
-SALOME et publiées dans l'étude pour point d'accés depuis l'interface
-graphique. L'utilisateur choisi un champs directement dans l'arbre
-d'étude (ou dans une interface graphique dédiée) puis demande qu'il
-soit mis à disposition dans l'interface python sous un nom de variable
-à choisir. Les captures d'écran ci-dessous montre la séquence
-graphique en images:
-
-.. |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
-lequel le champs sera manipulé dans l'interface textuelle. La
-validation de cette fenêtre doit mettre automatiquement le champ à
-disposition dans l'interface python SALOME et sous le nom de variable
-spécifié par l'alias saisi.
-
-Pour cela, il y a un couplage technique à programmer entre l'interface
-graphique et l'interface textuelle python, avec en particulier la
-transmission des pointeurs vers les servants CORBA mis en jeu dans la
-sélection.
-
-Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
-MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
-implémente l'interface graphique du module. Pour rappel, l'interface
-graphique d'un module SALOME se présente sous la forme d'une classe
-centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
-``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
-par laquelle on peut récupérer une instance de la console python
-embarquée (this->getApp()->pythonConsole()).
-
-Le code suivant illustre l'envoie d'une commande python par ce
-mécanisme. Dans cet example, on cherche à reconstituer dans le
-contexte de la console python un pointer vers un objet med instancié
-dans le contexte C++ de l'application graphique. Pour cela, on
-communique la référence de l'objet sous la forme sérialisé (IOR pour
-un objet CORBA):
-
-.. code-block:: cpp
-
- #include <PyConsole_Console.h>
- #include <QString>
- #include <QStringList>
- #include <SalomeApp_Application.h>
-
- // 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
-
- // Get the IOR of this object
- QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
-
- PyConsole_Console * pyConsole = getApp()->pythonConsole();
-
- 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());
- }
-
-Le code réel de la maquette est basé sur ce principe et transmet à la
-console python des lignes de commandes qui permettent de reconstruire:
-
-* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
- champ sélectionné;
-* une instance de ``FieldProxy`` qui correspond au champ sélectionné
- et avec pour nom de variable la valeur de l'alias saisi dans
- l'interface graphique.
-
-Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
-par la fabrication de la liste de commandes suivante pour envoie à la
-console python par le mécanisme illustré plus haut:
-
-.. code-block:: cpp
-
- QStringList commands;
- commands+="from xmed.fieldproxy import getFieldFromMed";
- commands+="from xmed.medproxy import getMedProxy";
- commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
- commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
-
-Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
-``iterationIndex`` sont construites à partir du champ sélectionné par
-des techniques de programmation standard dans SALOME qu'on peut
-examiner en détail dans la classe ``XMEDGUI`` (voir méthode
-``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
-chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
-
-Le point important à noter ici est que les données à transmettre
-doivent être fournies sous forme de chaînes de caractères ou de types
-simples. C'est pourquoi la référence au servant CORBA
-``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
-c'est-à-dire une chaîne de caractères qui permet l'identification de
-l'objet au niveau du bus CORBA.
-
-Au niveau de la console python cela correspond à l'exécution des
-commandes suivantes:
-
-.. code-block:: python
-
- 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
-``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
-``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
-associée à ce servant (en fait associée au servant
-``SALOME_MED::MEDOP`` créé sur demande par le servant
-``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
-
-.. _develguide_execFieldOperation:
-
-Exécution des opérations sur le champs
---------------------------------------
-
-Les variables définies dans l'interface textuelle pour désigner les
-champs à manipuler sont des objets de classe ``FieldProxy``.
-
-Cette classe a une propriété remarquable, elle est construite sur un
-design pattern de type "Proxy" qui pointe vers un servant
-``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
-directement au servant vers lequel il pointe, mais que l'on passe
-systématiquement par une procédure de l'objet proxy qui fait "boîte
-aux lettres":
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __getattr__( self, name ):
- """
- This method realizes the proxy pattern toward the servant
- SALOME_MED::FIELD.
- """
- return getattr( self.__field_ptr, name )
-
-Ce pattern permet l'implémentation de pré-traitement et/ou de
-post-traitement suivant le type d'accés que l'on cherche à faire.
-
-Il permet aussi et surtout de fournir un objet python qui présente
-l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
-operations de champs. Ici, python est ton ami, car il s'agit pour cela
-d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
-par python pour les operations entre objets. En particulier, la
-re-définition des fonctions internes ``__add__`` (opérateur addition),
-``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
-multiplication) et ``__div__`` (opérateur division) au sein de la
-classe ``FieldProxy``, permet de prendre la main sur le comportement
-des opérations algébriques et de définir une ergonomie sur mesure. Par
-exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
-(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
-réel à une variable de type FieldProxy):
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __add__(self, operande):
- """
- This can process the addition of two fields or the addition of
- a scalar to a field. It depends weither the operande is a
- FieldProxy or a simple scalar numerical value.
- """
- if isinstance(operande, FieldProxy):
- # The operande is an other field
- otherField_ptr = operande.__field_ptr
- rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
- else:
- # The operande is a scalar numerical value that must be
- # considered as an offset in a linear transformation
- factor = 1
- offset = operande
- rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
- return FieldProxy(self.__med_ptr, rfield_ptr)
-
-Il est à noter que dans les deux cas de figure (opérande=champ ou
-opérande=scalaire), la fonction délègue la réalisation concrète de
-l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
-l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
-MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
-service de calcul (l'addition entre champs dans le premier cas,
-l'application d'une transformation linéaire de type y=factor*x+offset
-dans le deuxième cas).
-
-Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
-présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
-l'interface du servant ``SALOME_MED_MEDOP``):
-
-.. code-block:: cpp
-
- /*! Addition of the fields f1 and f2 ( f1+f2) */
- FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Substraction of the fields f1 and f2 (f1-f2) */
- FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Multiplication of the fields f1 by f2 (f1*f2) */
- FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Division of the fields f1 by f2 (f1/f2) */
- FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Power of the field f (f^power) */
- FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
- /*! Linear transformation of the field f (factor*f+offset) */
- FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
- /*! Dublication of the field f */
- FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
-
-Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
-module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
-``MEDMEM_I``). C'est au sein des instances de cette classe que sont
-réalisées les opérations et que sont produites physiquement les
-données. Typiquement, les opérations présentées ici produisent un
-champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
-``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
-ce servant.
-
-Ce mécanisme global peut être étendu sans limitation à tout les types
-d'opération qui sont envisagés dans les spécifications de manipulation
-des champs dans SALOME.
-
-
-Contrôle visuel des champs
---------------------------
-
-Les illustrations ci-dessous montrent qu'une fonction de visalisation
-est implémentée dans la maquette pour permettre le contrôle visuel
-d'un champ au moyen d'une représentation 3D (une carte spatiale du
-module du champ dans l'exemple implémenté par défaut):
-
-.. |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.
-
-Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
-module VISU de faire une représentation 3D d'un champ spécifié par la
-donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
-(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
-
-.. code-block:: python
-
- import salome
- import VISU
-
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Then we can import the specified field in the VISU module. This
- # creates an study entry in the VISU folder.
- result = visuComp.ImportMedField(field_ptr)
-
- meshName = field_ptr.getSupport().getMesh().getName()
- fieldName = field_ptr.getName()
- iterNumber = field_ptr.getIterationNumber()
- scalarmap = visuComp.ScalarMapOnField(result,
- meshName,
- visuEntityType,
- fieldName,
- iterNumber)
-
-Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
-particulier à cause de la non définition de la variable
-``visuEntityType``, voir remarque plus bas), le composant VISU
-désigné ici par la variable ``visuComp`` va chercher les données du
-champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
-argument de la fonction ``ImportMedField``, puis produit une
-représentation de type "scalarmap".
-
-.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
- plus haut conférées par le pattern "Proxy", on peut transmettre ici
- aussi bien le servant CORBA que l'instance du proxy (la fonction
- ``ImportMedField`` n'y verra que du feu).
-
-Le code complet et fonctionnel de la fonction d'affichage est dans le
-corps du module python ``fieldproxy.py`` sous la forme d'une fonction
-de nom ``visuField``. Il convient de noter que cette fonction doit
-établir une correspondance entre le type des entités tel que défini
-dans MED et dans VISU:
-
-.. code-block:: python
-
- medEntityType = field_ptr.getSupport().getEntity()
- if (medEntityType == SALOME_MED.MED_CELL):
- visuEntityType = VISU.CELL
- elif (medEntityType == SALOME_MED.MED_NODE):
- visuEntityType = VISU.NODE
-
-
-Export des résultats de calcul
-------------------------------
-
-Tous les champs produits à l'occasion des opérations entre objets
-``FieldProxy`` sont automatiquement ajoutés à la structure med à
-laquelle is sont associés. Une convention d'attribution des noms est
-implémentée de sorte que par défaut aucune précision n'est demandée à
-l'utilisateur.
-
-La structure med peut être manipulée au moyen de la variable ``med``
-créée dans l'interface textuelle comme une instance de la classe
-``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
-l'interface du servant ``SALOME_MED::MED`` étendue de quelques
-fonctions utilitaires pour la gestion et le contrôle des données.
-
-En particulier, la sauvegarde de la structure dans un fichier est
-automatisée par la méthode ``save(medfilename)``:
-
-.. code-block:: python
-
- med = medproxy.MedProxy(medObj)
- med.save("/tmp/output.med")
-
-Cette méthode s'occupe de définir un driver d'écriture et de procéder
-à l'enregistrement des données de la structure med (les maillages, les
-champs présents au départ et tous les champs produits depuis la
-lecture initiale).
-
-Limitations
-===========
-
-L'implémentation de la maquette limite l'usage des opérations aux cas
-de figure suivants:
-
-* Seules les operations entre champs qui partagent le même support med
- sont possibles. Ceci est une contrainte imposé par la conception
- actuelle de MEDMEM.
-* Le résultat d'une opérations est calculé sur toutes les composantes
- et tout le domaine de définition des champs en opérande. Cette
- deuxième contrainte est juste parce que les usages plus fin,
- notemment avec la notion de domaine de définition, n'a pas encore
- été exéminée à ce jour.
-* Le nom d'un champ produit par une opération ne correspond pas au nom
- de la variable python par laquelle on le réceptionne et on le
- manipule. Le nom est attribué par une convention (ceci n'est pas
- vraiment une limitation mais une caractéristique à connaître).
-
-On note également les restriction techniques suivantes:
-
-* Les données MEDMEM sont supposées être chargées par le composant MED
- puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
- par le module MED).
-* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
- de la classe ``FieldProxy`` soient pris en considération dans les
- opérations sur les champs, il est indispensable que le premier
- opérande d'une opération unitaire soit un champ (objet de classe
- ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
- fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
- car python tente de traiter la situation au moyen de la fonction
- ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
-
-
-Notice informatique
-===================
-
-Gestion de configuration
-------------------------
-
-Les développements décrits dans ce chapitre sont répartis entre les
-modules MED et XMED (développé pour l'occasion). Cette séparation est
-faite par soucis de clarté et d'efficacité de développement, mais les
-éléménts du module XMED ont vocation à intégrer le module MED dans la
-mesure où les propositions techniques sont retenues pour le
-développement à venir.
-
-Le code source du module XMED peut être récupérés par la commande
-suivante::
-
- $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
-
-Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
-équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
-VISU. Pour récupérer la branche BR_medop du module MED, taper la
-commande::
-
- $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
-
-La configuration de référence est:
-
-* XMED: révision svn 41
-* MED: tag cvs BR_medop_20101025
-
-Moyens de tests
----------------
-
-Plusieurs types de tests unitaires sont définis (reste à les
-automatiser proprement):
-
-* Test des servants et utilitaires de manipulation python:
-
- - Dans XMED, package xmed/tests, utiliser le script
- ``test_medoperation.py`` dans un interpréteur python lancé dans
- une session shell SALOME. Ce script prépare des variables de test
- 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``.
-
-* Test des classes MEDMEM:
-
- - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
-
-Un fichier de test basique (mais néanmoins suffisant) de nom
-``tesfield.med`` est fourni avec les sources dans le répertoire
-``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
-répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
-contient deux champs ``testfield1`` et ``testfield2`` définis sur un
-pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
-par éléments (MED_CELL).
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, MED, MEDMEM
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Note de travail concernant l'utilisation de MEDMEM
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module MED de SALOME comporte plusieurs composants d'intérêt pour
-la manipulation de champs:
-
-* la bibliothèque MEDMEM qui fournit une interface de programmation
- pour manoeuvrer une structure MED
-* le module CORBA SALOME_MED qui matérialise le composant SALOME
- (serveur corba) du module MED
-* l'interopérabilité avec le module VISU qui permet la visualisation
- des champs manipulés dans MED
-
-Les sections ci-après donnent quelques éclairages techniques sur ces
-différents aspects. Les sources de démonstration peuvent être
-récupérés depuis le dépôt svn::
-
- $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
- $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation synthétique de MED
-===============================
-
-MED désigne un modèle conceptuel pour décrire des données de type
-éléments finis (éléments finis, volumes finis et éléments
-discrets). Dans l'usage courant, il permet la description et l'échange
-des données de calcul de type maillages et champs. La documentation
-complète peut être trouvée à l'URL suivantes:
-
-* |LINK_EDF_MEDDOC|_ (version 2.3).
-
-On distingue deux implémentations informatiques de ce modèle:
-
-* MED fichier: qui permet la lecture et l'écriture de données depuis
- un fichier au format med. Les opérations de lecture/écriture sont
- atomiques (pas de chargement de la structure de données globale).
-* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
- image de la structure de données MED contenue dans un fichier au
- format med. Les opérations peuvent être atomiques ou
- globales.
-
-On notera simplement ici que MEDMEM utilise MED fichier pour les
-opérations de lecture/écriture et que MED fichier est indépendant de
-MED mémoire. La documentation complète de MED fichier peut être
-trouvée à l'URL suivante:
-
-* |LINK_EDF_MEDFICHIERDOC|_
-
-La bibliothèque MEDMEM
-======================
-
-Le modèle de classes MEDMEM est structuré autour des notions de MESH
-(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
-champs). Ces notions reprennent en partie des concepts du modèle
-MED. Le diagramme ci-dessous présente les classes principales:
-
-.. image:: images/med-uml-main_60pc.png
- :align: center
-
-Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
-figure ci-dessous indique qu'une instance MED peut être associée à
-plusieurs maillage et plusieurs champs. Par contre un champ donné ne
-peut être associé qu'à un seul maillage (par l'intermédiaire du
-support). Plusieurs champs peuvent être associés au même maillage. La
-forme la plus courante est d'ailleurs une instance composé d'un
-maillage unique sur lequel sont définis plusieurs champs.
-
-On peut avoir également des configurations plus complexes, comme par
-exemple un maillage unique, plusieurs champs définis sur ce maillage
-mais avec des supports différents, par exemple parce que les valeurs
-sont définies sur des entités de maillage différentes (les éléments
-pour un champ, les noeuds pour un autre, ...)::
-
- field1->support1->mesh
- field2->support2->mesh
- field3->support3->mesh
-
-On observe:
-
-* 2 champs U et V doivent avoir le même support (au sens informatique
- du terme) pour pouvoir être en argument d'une opération (sinon
- exception). Il faudrait accepter qu'il soit informatiquement
- différent et vérifier la conformité conceptuelle.
-* Cette contrainte peut se comprendre car physiquement les données
- sont stockées dans un vecteur qui couvre toutes les mailles. Le
- support est le seul masque de lecture pour établir la correspondance
- avec les positions dans le maillage et il est donc important qu'une
- cohérence soit assurée.
-
-Les objets champs (FIELD) et maillage (MESH)
---------------------------------------------
-
-Un objet MED permet d'accéder aux différentes informations concernant
-les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
-données physiques associées à ces objets (les valeurs des composantes
-pour les champs, les mailles et leur connectivité pour les
-maillages). L'accès aux données physiques est du ressort des objets
-spécifiques MESH, SUPPORT et FIELD.
-
-Un objet MED peut être créé intégralement en mémoire. L'usage plus
-fréquent est de l'initialiser à partir de la donnée d'un fichier
-med. Pour cela, l'objet MED doit être associé à un driver
-d'entrée/sortie branché sur le fichier (``testfilename`` dans
-l'exemple):
-
-.. code-block:: cpp
-
- MED *myMed = new MED;
- MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
- driverIn->open();
- driverIn->readFileStruct();
- driverIn->close();
-
-A l'occasion de la fonction readFileStruct, la structure interne de
-l'objet MED est enrichie des informations concernant les objets MESH,
-SUPPORT et FIELD contenu dans le fichier. En particulier un
-dictionnaire des champs (variable map interne) est initialisé est
-contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
-méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
-autonome pour être chargé sur demande. On peut alors requêter l'objet
-MED pour obtenir un champ particulier (spécifié par son nom
-``fieldname`` dans l'exemple):
-
-.. code-block:: cpp
-
- FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
-
-Puis le champ qui lui est associé doit être physiquement chargé pour
-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
-----------------------------------------
-
-Les éléments qui composent un maillage sont caractérisés par:
-
-* Le type d'entité de l'élément, à choisir dans la liste
- ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
- ``MED_FACE``, ``MED_CELL``.
-* Le type de géométrie de l'élément, à choisir dans la liste
- ``MED_EN::medGeometryElement``, qui contient en particulier
- ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
-
-Les éléments sont numérotés par un indice relatif à la catégorie
-géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
-composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
-ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
-persistente dans le fichier med). De même, les arrêtes sont numérotées
-de 1 à Na. Une numérotion globale implicite existe sur les éléments,
-elle consiste à parcourir l'ensemble des types géométriques dans
-l'ordre de définition du modèle de données. Ainsi, si le modèle
-contient uniquement les Na arrêtes et les Nf faces, alors l'indice
-global de la première face est Na+1.
-
-.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
-
-
-Binding python de MEDMEM
-------------------------
-
-Les classes du package ``MEDMEM`` (package du module ``MED`` qui
-implémentent les structures de données C++ de MED mémoire) produisent
-la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
-partie mis à disposition de l'interface python grace à une couche de
-liaison (binding Python-C++) générée par le logiciel SWIG à partir
-d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
-package source ``MEDMEM_SWIG``).
-
-Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
-des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
-nouvelle classe est créée (du moins si l'on souhaite profiter de ces
-évolutions dans l'interface python).
-
-Cette mise à jour nécessite de prendre soin au transfert des
-structures de données entre les espaces python et C++. En particulier,
-l'utilisation des template de classe pour décrire les champs typés en
-C++ appelle une précaution de codage particulière de l'interface
-SWIG.
-
-Pour exemple, le fragment de code ci-dessous, extrait du fichier
-``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
-``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));
- }
- 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);
- }
- }
-
- };
-
-
-Utilisation de MEDMEM pour la manipulation de champs
-----------------------------------------------------
-
-Des opérations de manipulation de champs sont disponibles dans la
-bibliothèque MEDMEM standard est peuvent être utilisées dans
-l'interface python. Les quelques lignes suivantes illustrent l'usage
-qu'on peut en faire pour exécuter l'addition de deux champs sur tout
-leur espace de définition et pour un pas de temps donné:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-.. note:: Cet exemple de code requiert les évolutions de MEDMEM
- opérées dans la branche BR_medop (pour disposer de la classe
- MedDataManager en particulier) et le package python ``xmed`` qui
- fournit quelques fonctions utilitaires pour manoeuvrer les données
- med (ce package est dans le module XMED et sera probablement à
- terme intégré au module MED).
-
-Des limitations existent aujourd'hui pour ce type de manipulations:
-
-* les champs doivent partager le même support MED, c'est-à-dire être
- décrit sur le même maillage et sur les mêmes entités de ce
- maillage.
-* ...
-
-
-Remarque sur l'implémentation C++
----------------------------------
-
-A noter l'usage de plusieurs formes d'arguments pour les fonctions:
-
-* passage des arguments par valeur ``myfunction(A a);``
-* passage des arguments par référence ``myfunction(A& a);``
-* passage des arguments par pointeur ``myfunction(A* a);``
-
-Le passage des arguments par référence est une facilité d'écriture
-pour éviter de passer un pointeur tout en évitant la récopie des
-données de la variable.
-
-.. _xmed-medmem_corbainterface:
-
-L'interface CORBA SALOME_MED
-============================
-
-Implémentation du composant MED et des servants SALOME_MED::\*
---------------------------------------------------------------
-
-Le composant MED est un servant CORBA qui permet la manipulation de
-données MEDMEM dans l'environnement SALOME. Le composant peut fournir
-des pointeurs vers des instances de l'interface SALOME_MED (objets
-SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
-servants CORBA qui résident dans le container et qui encapsulent les
-données MEDMEM.
-
-Le schéma ci-dessous représente les éléments informatiques qui
-composent l'architecture CORBA du module MED:
-
-.. image:: images/medmem-corba-layers.png
- :align: center
-
-Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
-CORBA) fonctionnent différement en ce qui concerne le chargement des
-données:
-
-* Dans MEDMEM, les données sont chargées à la demande (fonctions read
- des objets) et aucune gestion n'est assurée. En particulier l'appel
- à read alors que la donnée est déjà chargée conduit à une levée
- d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
- type de gestion.
-* Dans SALOME_MED, les données sont chargées à la création de
- l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
- leurs données sont chargés à ce moment là et gérés dans une table de
- type HashMap au niveau de la structure SALOME_MED::MED. Cette
- structure remplie dés lors des fonction de gestion. L'appel à
- SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
- un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
- l'initialisation (ATTENTION, cette fonction est bugguée dans la
- branche principale -> Fix dans la branche BR_medop).
-
-Une gestion intermédiaire peut être envisagée: le chargement à la
-demande géré dans une ou plusieurs tables de champs (une pour chaque
-type de valeur numérique). Une implémentation de ce type de gestion
-est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
-en charge ce comportement pour les structures de données MED (en
-particulier les champs).
-
-Utilisation du composant MED
-----------------------------
-Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
-interfaces de ce module CORBA sont spécifiées par les fichiers idl
-suivants:
-
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
- ``MED.idl``] qui décrit les interfaces des objets manipulés par le
- module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
- et FIELD.
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
- ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
- (c'est-à-dire le composant chargé par la commande
- ``FindOrLoadComponent("FactoryServer", "MED")`` du
- lyfeCycleCorba). On trouve:
-
- - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
- pour l'implémentation des services généraux des composants SALOME
- (persistance hdf, dump)
- - l'interface ``MED_Gen`` qui hérite des interfaces
- ``Engines::Component`` et ``MED_Gen_Driver`` pour
- l'implémentation des services spécifiques du composant MED.
-
-L'implémentation de ces interfaces est faites au niveau de différents
-packages des sources du module MED:
-
-* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
- interfaces décrites par le fichier ``MED.idl``;
-* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
- décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
- partie composant classique d'un module SALOME.
-* Le package ``MedCorba_Swig`` qui fournit une interface swig
- générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
- ``MED``
-
-L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
-utilise l'interface swig fournie par MedCorba_Swig). Après l'import
-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
-être invoqués. Par exemple, les commandes suivantes chargent toute la
-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)
-
-On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
-qui permet une utilisation assez semblable (mais différente on le
-verra plus bas) à MEDMEM:
-
-.. code-block:: python
-
- fieldIdx = 1 # WRN maybe there is no field of idx=1
- iterationIdx = 0
- fieldName = medObj.getFieldNames()[fieldIdx]
- 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::
- Observations en vrac:
-
- * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
- le champ informatique réel (objet MEDMEM).
- * FIELD_i::fieldMap variable static de type map qui semble gérer
- les différentes instances de FIELD_i (~pattern factory). Cette
- map peut être requétée au moyen d'un indice de type long appelé
- corbaIndex.
- * Quand on crée un FIELD_i par le constructeur d'argument
- ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
- incrément du corbaIndex
- * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
- ``MEDMEM::FIELD_`` associé
- * A CONFIRMER: Il semble que les fonctions de chargement
- ``readStructFile*()`` charge toutes les données du fichier med,
- alors qu'en MEDMEM seules les meta-données sont chargées.
- * A CONFIRMER: il semble que le chargement d'une structure MED
- CORBA peut se faire sans passer par le composant (cf. l'interface
- de MED)
-
-Interface avec le module VISU
-=============================
-
-Des interactions sont possibles entre MED et VISU à partir du moment
-où les données med sont gérées dans l'étude, c'est-à-dire sous la
-forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
-deux conditions sont aujourd'hui nécessaires (objet corba + publié
-dans l'étude) mais il semble que ce ne soit lié qu'à un choix
-d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
-a priori être modifié. A CONFIRMER.
-
-L'exemple de code ci-dessous (en python, mais il peut être transposé à
-une implémentation C++) montre par exemple comment envoyer au module
-VISU une requête de visualisation d'un champs hébergé par le module
-MED (en fait, les données sont gérées au travers d'un objet corba
-SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
-catégorie du composant MED). Les importations standard (salome,
-SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
-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
- result = visuComp.ImportMed(medSObj)
-
-Il est possible de d'aller plus loin et par exemple de déclencher
-l'affichage d'une scalarmap d'un champ spécifique pour une itération
-particulière (voir la fonction
-``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
-``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
-
-Liens complémentaires:
-
-* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
-
-
-Notes en vrac
-=============
-
-Questions:
-
-* 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?
-
-Remarques:
-
-* A part, les opérations arithmétiques (+,-,*,/), aucune opération
- n'est définie.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, vue d'ensemble
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module XMED est un espace d'expérimentation pour le développement
-des opérations de manipulation de champs. Il complète des
-développements intégrés directement dans le module MED et gérés dans
-la branche CVS BR_medop.
-
-Une maquette est au point pour illustrer les propositions en matière
-d'ergonomie d'utilisation et en matière d'architecture technique. La
-maquette permet de réaliser des cas d'utilisation de la forme:
-
-* Chargement d'un fichier med dans le module MED (ou publication par
- un code de calcul).
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Egalement quelques fonctions
- mathématiques standard applicables sur des champs (pow, sqrt).
-* Possibilité de visualiser les champs produits avec VISU
-* Possibilité d'exporter des champs produits dans un fichier med
-
-La figure ci-dessous montre le résultat d'une séquence d'utilisation
-dans laquelle les champs "testfield1" et "testfield2" ont été
-sélectionnés dans l'arbre d'étude pour être utilisés dans la console
-textuelle sous les noms de variables f1 et f2. L'image montre le
-contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
-ligne de commande:
-
-.. image:: images/medop-gui-result.png
- :align: center
-
-La séquence ci-après montre le cas d'utilisation complet en
-images:
-
-1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
-2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
- défaut, le nom du champ est proposé (``testfield1`` ici). Dans
- l'exemple, l'utilisateur remplace par l'alias ``f1``.
-3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
- ``f1`` au moyen de la commande ``f1.visu()``
-4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
- l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
- récupéré ici dans une variable de nom ``result``.
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-.. |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:
-
-* Les données MEDMEM sont physiquement chargées par le composant MED,
- c'est-à-dire dans le processus ``Container`` de SALOME, et sont
- référencées dans l'étude SALOME.
-* Les opérations sont physiquement des opérations entre objets MEDMEM
- purs qui ont lieu dans le composant MED.
-* Les opérations sont pilotées par des objets proxy python instanciés
- dans la console TUI puis manipulés par l'utilisateur. Ces objets
- proxy savent accéder aux objets MEDMEM au travers de leur interface
- CORBA.
-
-Ainsi, l'architecture technique est construite pour pouvoir travailler
-sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
-depuis des objets python dans l'interface textuelle de
-SALOME. L'effort principal a donc porté sur la mise au point de
-l'interface technique qui permet de lier des variables représentant
-les champs au niveau du GUI (techniquement, la calculette est
-l'interpréteur python embarqué dans le GUI, étendu de quelques
-fonctions pour la manipulation de champs), alors que les données
-MEDMEM sont physiquement disponibles uniquement au niveau des
-composants CORBA (et les opérations implémentées dans MEDMEM
-uniquement).
-
-Pour le moment, la maquette est limitée à des operations entre champs
-qui partagent le même support med (contrainte de MEDMEM) et le
-résultat est calculé sur toutes les composantes et tout le domaine de
-définition du champs (cette deuxième contrainte est juste parce que
-les extentions n'ont pas encore été examinées). Enfin, le support de
-gestion des données est supposé être l'étude SALOME et la structure
-MED qui y est publiée.
+++ /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)
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2010
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs du développement
-=====================================
-
-En matière de développement:
-
-* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
- module SALOME diffusable dans la version d'exploitation 2010 (SALOME
- 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
- devoir tenir compte des contraintes de temps SALOME et (ii) le
- produit envisagé fin 2010 est une maquette qui cherche à éprouver
- l'ergonomie générale d'utilisation et en aucun cas on ne peut
- garantir la réalisation d'un module SALOME compatible avec les
- exigences de mise en exploitation.
-* On ne cherche pas d'emblée à capturer tous les cas d'application,
- mais à concevoir un développement qui acceptera les extensions de
- périmètres dans des conditions raisonnables. Aussi, les
- fonctionnalités développées seront celles qui sont nécessaires à la
- réalisation des cas d'application de référence;
-
-En matière d'ergonomie:
-
-* L'interface utilisateur de référence (appelé espace de travail dans
- le volet de spécifications fonctionnelles) est l'interpréteur
- python. Les fonctionnalités doivent être pensées pour un usage
- adapté à une interface textuelle (TUI) de ce type.
-* La création d'une interface graphique (GUI) peut être envisagée en
- complément et comme un moyen de manipuler graphiquement les
- fonctionnalités développées pour l'interface textuelle et pour aider
- la préparation des variables dans l'interface python.
-* Le modèle d'un processus de manipulation de champs est:
-
- - Préparation du jeu de variables U, V, ... représentant les champs
- à manipuler. C'est à ce stade que l'on résoud la question de
- sélection des données (dans un champ publié dans l'arbre d'étude,
- par un module de calcul ou par chargement d'un fichier med)
- - Utilisation des variables avec une sémantique la plus proche
- possible du modèle conceptuel et des spécifications
- fonctionnelles;
- - Création des variables qui représentent les résultats des
- fonctions de manipulation;
- - Persistence (fichier med), visualisation (SALOME) ou export (vers
- une structure qui peut être directement utilisable en numpy)
-
-Sur le plan technique:
-
-* On souhaite spécifier clairement le conteneur SALOME des fonctions
- de manipulation de champs. Pour discussion:
-
- - Il apparaît que les modules SALOME MED et VISU contiennent déjà
- des fonctions qui peuvent faire partie des fonctions de
- manipulations de champs (en particulier pour l'exploration des
- structures MED, leur visualisation et la sélection des données à
- manipuler).
- - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
- tout cas pas sous sa forme de module SALOME) et compte-tenu du
- caractère obsolescent du module VISU (amené à être remplacé sur le
- plan fonctionnel par le module PARAVIS), on pourrait examiner la
- création d'un module dédié à la manipulation des maillages et des
- champs par l'agrégation technique au sein d'un même module des
- fonctions des modules MED et VISU.
-
-Au moins dans un premier temps, on se donne les limites suivantes:
-
-* Une opération ne peut pas combiner des pas de temps différents. Dans
- l'hypothèse où cette limite venait à être levée, on doit spécifier
- le pas de temps de la donnée résultat;
-* Le domaine d'application d'une opération pourra être défini
- exclusivement par la donnée d'un maillage ou un groupe d'éléments du
- maillage;
-* On ne traite pas le cas des champs qui prennent leurs valeurs aux
- points de gauss ou aux noeuds par élément. Une particularité de ces
- types de support est que le repérage de la position implique deux
- indices (par exemple l'indice de la maille, puis l'indice du point
- de gauss).
-
-Eléments de conception
-======================
-
-Plan général
-------------
-
-On peut par exemple imaginer une maquette du genre:
-
-* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
- structure des maillages et des champs dans l'arbre d'étude.
-* Sélectionner un élément (par exemple un pas de temps d'un champ) et
- le menu contextuel permet d'exporter ce champ dans la console python
- pour manipulation. Pour cela, s'inspirer de la fonction
- ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
- PythonConsole.
-* L'élément est marqué comme ayant été exporté, on peut imaginer une
- récupération ultérieure.
-* Exporter un deuxième champ cohérent avec le premier (même pas de
- temps et défini sur le même maillage avec le même support, on
- s'arrange pour).
-* Dans la console python, faire les opérations sur les champs
-* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
- ultérieure. C'est a priori le gros morceau qui consiste à faire un
- objet CORBA MED à partir d'un objet MED standard, en plus défini
- dans la console python (sous forme d'objet python).
-
-Quand ce premier cas d'utilisation est au point, on peut envisager de
-le compléter par les opérations suivantes
-
-* exporter le résultat med dans un fichier
-* visualiser les champs produits
-
-Plan de développement:
-
-* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
- d'architecture, l'opération physique se déroulera en définitif au
- niveau de MEDMEM pur.
-* Prévoir une implémentation des opérations sous forme de fonctions
- informatiques, même les opérations algébriques (+,-,*,/). Pour ces
- dernières et dans certaines conditions (quand on manipule
- directement les strutures MEDMEM et non pas les objets CORBA),
- l'utilisation des formes A+B, A-B, ... peuvent être rendues
- possibles. Dans ce cas, voir la possibilité de combiner plusieurs
- opérations algébriques sur une seule ligne: A+B-C*0.3.
-* On peut charger la structure MED sous forme d'objet CORBA publiable
- dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
- exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
- récupère que les informations nécessaires au chargement d'un champs:
- le nom du champs, le nom de son maillage associé, les identifiants
- du pas de temps, au besoin une structure Field non chargée (par
- exemple pour récupérer plus facilement le maillage).
-* Un mécanisme (à développer à partir du PyConsole par exemple)
- pourrait alors permettre le chargement des champs sélectionnés dans
- la console python et sous un nom facile à manoeuvrer. Prendre
- inspiration sur XCADGUI::LoadIntoPythonConsole().
-* A priori, les données sont physiquement chargée dans le GUI. Au
- besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
- CORBA field à partir d'un field standard (à tester).
-
-Une autre idée est de récupérer le pointeur CORBA MED dans la console
-python et de tirer les données à partir de là. Ajouter une couche de
-wrapping python pur pour gérer les cas de simplification (surcharge
-des opérations arithmétiques par exemple).
-
-Besoins complémentaires:
-
-* L'interpréteur doit contenir des éléments d'aide (par exemple un
- help qui liste les opérations possibles sur les champs chargés)
-* prévoir quelques fonctions de visu et de persistence. Cela commence
- probablement par des fonctions de publication dans l'étude des
- champs créés par les opérations de manipulation. Les champs sont
- physiquement ajouté automatiquement à la structure med par le MedOp
- mais il n'est pas obligatoirement publié => fournir un moyen de
- publication.
-
-Limitations actuelles (liées à la conception de MEDMEM):
-
-* les champs doivent être gérés par la même structure MED car ils
- doivent partager le même support.
-* les opérations possibles dans MEDMEM sont entre champs pris sur un
- pas de temps (Q: les pas de temps peuvent-ils être différents).
-
-
-Développements
---------------
-
-Développement de classes proxy:
-
-* FieldProxy, FieldTimeSeriesProxy
-* Attention pour les éries temporelles, le SUPPORT med peut être
- différent en chaque pas de temps (par exemple en cas d'extension
- spatiale du champ au cours du temps).
-
-MEDMEM_MedDataManager:
-
-* FIX: test de l'implémentation C++ au travers de la fonction test() du
- MedOperator ==> OK. Quand on fait la même opération depuis python
- via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
- destructeur du champ semble être appelé. Pb de gestion des pointeurs?
-
-
-Evolutions à prévoir
-====================
-
-Concernant MEDMEM:
-
-* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
- plusieurs fois de suite puisqu'on recycle la référence si elle est
- déjà chargée.
-* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
- exemple avec un getField qui renvoie le champ s'il est déjà chargé
- ou le charge et le renvoie sinon).
-* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
- passant a priori par le driver associé. Plusieurs driver peuvent
- être associés à une structure MED car les données peuvent être
- chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
- étendre la structure MED pour avoir accés à la liste des driver puis
- de cette liste déduire les noms des fichiers.
-* IMP: Opérations combinant des champs sur des support différents ne
- peuvent pas être faites par l'API (une exception est levée en cas de
- supports incompatibles), mais on peut imaginer le faire en
- manoeuvrant les tableaux de données directement.
-* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
- et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
-* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
- préalablement ajouté: une fonction removeField en complément de
- addField.
-
-Concernant l'interface SALOME_MED:
-
-* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
- structure MED et requêtées au niveau des classes proxy en spécifiant
- les identifiants des champs impliqués et les paramétres requis (pas
- de temps en particulier).
-
-Concernant le module MED:
-
-* IMP: pourvoir exporter la structure med dans un fichier med (la
- structure ayant pu être enrichie par la publication de champs créés
- par les operations de champs.
-
-
-Historique des travaux
-======================
-
-20100726 : mise au point du schéma de conception
-------------------------------------------------
-
-Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
-raisons:
-
-* MED Coupling ne peut pas gérer des mailles de dimensions différentes
- dans un même modèle (choix faits dans un soucis de performance dans
- l'accès à une structure de donnée compact). On peut contourner le
- problème en définissant deux champs pour traiter chacun des type de
- mailles.
-* Un champ repose sur un maillage complet (pas de notion de profil,
- mais cela peut être émulé en créant deux maillages)
-* Le concept de point de gauss n'existe pas (pas implémenté)
-
-TODO:
-
-* Idéalement, il conviendrait de faire un état des lieux du module
- MED, en particulier des éléments MEDMEM (le coeur), les interfaces
- CORBA associées (MED.idl implémenté dans le package source
- MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
- implémenté dans le package source MED) et le GUI (MedGUI.cxx
- implémenté dans le package source MEDGUI).
-
-* Ergonomie TUI et modèle CORBA associé:
-
- 1. Charger un objet medmem (puis les objets métier mesh et field)
- sur un domaine d'application donné.
- 2. En faire des variables disponibles dans l'interface TUI et que
- l'on peut manipuler dans des opérations algébriques.
- 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
- les autres modules SALOME.
-
-* Compléter le diagramme de la structure informatique de MED (en
- particulier l'implémentation des interface IDL).
-* Préparer un module de travail XMED (organisation d'une bibliothèque)
-
-Tests à réaliser:
-
-* Est-il possible de faire des opérations algébriques à partir des
- objets SALOMEMED (objects CORBA MED)?
-* Création d'un objet MED_i à partir d'une objet MED pur préalablement
- chargé en mémoire.
-
-A retenir:
-
-* Des opérations de champs sont possibles sur des champs à des pas de
- temps fixés. Si l'opération doit être menée sur plusieurs pas de
- temps, alors itérer sur chaque pas de temps. L'idée ici est
- d'introduire le concept de série temporelle de champs en temps
- qu'objet manipulable.
-* Pour deux champs différents de la même structure MED, la données des
- identifiants dt et it ne correspond pas forcément au même instant
- absolu (en tout cas rien ne le garanti, même si c'est tout de même
- une pratique courante).
-
-20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
---------------------------------------------------------------------------
-
-XMED: svn révision 16
-Travailler avec le fichier de donnée testfield.med joint.
-
-
-20101007 : Vers une maquette CORBA
-----------------------------------
-
-Le contexte d'utilisation des opérations de champs est l'environnement
-SALOME. Le support de gestion des données est donc l'étude SALOME. Au
-plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
-session SALOME (soit par un code de calcul intégré, soit par
-chargement des données à partir d'un fichier med). Ces objets sont en
-général référencés dans l'étude SALOME sous la forme d'objets CORBA de
-classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
-SObject (Study Object) dont un attribut est une référence vers un
-objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
-MEDMEM::Field.
-
-On peut donc envisager une solution dans laquelle on donne à
-l'utilisateur des poignées de manipulation des objets
-SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
-type proxy. Cela signifie que l'utilisateur ne manipule pas
-directement des objets MEDMEM mais des objets python qui font
-l'interface (à concevoir et implémenter, a priori avec un design
-pattern de type proxy).
-
-L'utilisation directe des objets MEDMEM aurait pu être une solution
-extremement pratique dans la mesure où ces objets en l'état peuvent
-être combinés dans des opérations de champs (c'est déjà
-implémenté). Par contre, ce procédé souffre de limitations importantes
-dans la gestion et la circulation des données pour les différents cas
-d'utilisation envisagés (visualisation, export, transfert à un autre
-module SALOME).
-
-L'avantage de la solution proposée est multiple:
-
-* Elle permet de travailler sur une structure MED cohérente pour
- intégrer les résultats des opérations de calculs et combiner des
- champs cohérents entre eux. Tout passe par des classes proxy qui
- pourront s'assurer de la cohérence des opérations demandées et
- exécuter automatiquement les fonctions de pré-traitement ou
- post-traitement requises pour ces opérations. On peut imaginer par
- exemple que les requêtes d'opération soient envoyées par les classes
- proxy à la structure MED à laquelle les champs sont associés pour
- piloter l'opération en MEDMEM pur.
-* Elle permet d'automatiser un certain nombre d'opérations
- implicites. Par exemple si deux champs ne sont pas définis dans la
- même unité, un changement d'unité peut être effectué automatiquement
- par la classe proxy avant de commander l'opération au niveau
- MEDMEM.
-* Elle permet de laisser les données sur le container SALOME et de
- réaliser des opérations sans rappatrier les données en local (qui
- peuvent être en trés grand nombre).
-* Elle permet d'étendre facilement l'ergonomie de manipulation des
- champs, par exemple en définissant la notion de *série temporelle de
- champs*, ou encore les concepts de *domaine de définition* évoqués
- dans les spécifications fonctionnelles.
-* Elle rend immédiat la circulation des données entre modules SALOME,
- puisque les champs restent accessble par des objets CORBA, en
- particulier pour la visualisation ou l'export des champs produits
- par les opérations.
-
-Elle a cependant des inconvénients et/ou limitations:
-
-* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
- les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
- se limite a priori aux opérations de champs (les opérations
- algébriques dans un premier temps).
-* Les champs à manipuler dans une opération donnée doivent être gérés
- par la même structure MED.
-
-Il est à noter également que les interfaces de programmation de
-SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
-permettre des requêtes de manipulations de champs (fonctions addition,
-soustraction, multiplication, ...). Pas de contrainte ici sur
-l'ergonomie puisque la manipulation par l'utilisateur se fera au
-niveau des classes proxy uniquement.
-
-
-Hypothèses:
-
-* On tente ici une maquette qui exploite dans la mesure du possible le
- fonctionnement actuel du module MED, en particulier la gestion des
- données dans l'étude.
-* Dans une deuxième version, on pourra examiner sérieusement la
- révision de la gestion des données dans le module, quitte à la
- spécifier et maquetter dans XMED pour intégration ultérieure dans
- MED. Exemple:
-
- - Pouvoir gérer plusieurs structures med dans l'étude.
-
-* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
- des données (gestion des chargements des champs en particulier,
- références croisées pour retrouver le med à partir du champ par
- exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
- faut pouvoir par ailleurs gérer indifféremment une structure med (et
- les champs qui y sont associés) qu'elle soit créée en mémoire from
- scratch ou chargée d'un fichier (donc attention avec les opérations
- de lecture read(), sur les maillages comme sur les champs). La
- structure med permet d'obtenir les méta données (meta-field par
- exemple) mais ne permet pas de savoir si les données sont
- physiquement chargées ou pas.
-
-
-Révisions:
-
-* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
- Première version qui permet d'importer un champ dans la console
- python sous la forme d'un FieldProxy. Ne permet pas encore de faire
- des opérations. Introduction dans le module MED de l'interface MEDOP
- pour prendre en charge les opérations sur les champs.
-
-
-20101019 : Maquette de démonstration pour l'addition
-----------------------------------------------------
-
-Cette maquette implémente une solution technique de bout en bout (de
-l'interface python aux objets MEDMEM, en passant par le fieldproxy
-puis les servants CORBA pour les operations, ...) mais sur le
-périmètre de l'addition de champs sur tout leur domaine de définition
-et pour un pas de temps donné.
-
-Limitations:
-
-* gére l'addition de champs de type double uniquement (parceque le
- reste n'est pas implémenté)
-
-Révisions:
-
-* XMED: svn révision 25
-* MED: cvs tag BR_medop_20101019
-
-
-20101020: Fonctions complémentaires
------------------------------------
-
-Cette version test la faisabilité des fonctions complémentaires pour
-accompagner la manipulation de champs. Cela comprend en particulier:
-
-* **la sauvegarde des champs produits** dans un fichier med (un champ ou
- toute la structure med). Pour cela, on définit un med proxy comme
- l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
- de fonction au niveau C++ pour permettre un usage au niveau du GUI
- C++?).
-* **la visualisation d'un champ** au moyen du module VISU.
-* **des fonctions d'aide interactives** pour assister l'utilisateur
- dans la console de manipulation des champs.
-
-
-Questions:
-
-* peut-on sauvegarder un champ unique?
-* peut-on faire en sorte que ce soit l'affectation à une variable qui
- provoque l'ajout du champ à la structure med (ou plus exactement qui
- supprime tous les champs intermédiaires).
-
-
-Révision:
-
-* XMED: svn revision 31
-* MED: cvs tag BR_medop_20101025
-
-
-20110606: commit avant transfert dans git
------------------------------------------
-
-* XMED: svn revision 53
-
-Les parties de MED utiles à MEDOP seront reversées dans XMED
-dans une première étape, puis le tout dans MED 6 au final.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2011
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Cas d'utilisation métier
-========================
-
-On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
-
- J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
- ajouter de nouveaux champs issus de champs existants. J'aimerais
- aussi pouvoir créer de nouveaux meds plus petits par extraction de
- certaines composantes de champs, certains groupes ou certains pas de
- temps.
-
-On peut exprimer le besoin sous la forme des cas d'utilisation
-suivants (use cases):
-
-* **UC1: combiner dans un même fichier med des champs issus de
- plusieurs sources de données**. On peut par exemple charger un
- premier fichier, puis ajouter à cette base des champs issus d'autre
- fichiers ou générés par manipulation de champs, ou encore générés
- par un module de calcul qui produirait directement du MEDCoupling.
-* **UC2: créer un champ contenant certaines composantes d'un autre
- champ**. On pense ici aux fonctions de restriction, qui permettraient
- de récupérer certaines composantes uniquement.
-* **UC3: créer un champ contenant certains pas de temps d'un autre
- champ**. C'est un cas particulier des fonctions de restriction
- évoquées ci-dessus.
-* **UC4: créer un champ comme la limitation d'un autre champ à un
- groupe de mailles**. C'est un cas particulier des fonctions de
- restriction évoquées ci-dessus. Notion de domaine spatial. A
- priori la notion de groupe est définie dans MEDLoader.
-
-On peut ajouter également les UC identifiés pour la maquette 2010:
-
-* **UC5: comparer des champs issus de source de données différentes**,
- par exemple des champs chargés de deux fichiers med différents et
- qui s'appuient sur le même maillage (au moins conceptuellement). Le
- problème technique ici est de pouvoir changer le maillage d'un
- champ, pour ramener tous les champs sur le même maillage (au sens
- informatique). Ceci est une contrainte de MEDCoupling, les
- opérations sur des champs A et B imposent que A et B soient définis
- sur le même maillage, i.e. le même objet informatique.
-* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
- de mailles. Ce cas d'usage est typiquement prévu pour produire les
- conditions de chargement initial d'une structure. Il s'agit ici
- d'initialiser un champ à partir de zéro sur une surface prédéfinie
- de la géométrie (par exemple spécifiée par un nom de groupe de
- mailles).
-
-Pour UC5: les sources de données sont référencées dans l'object
-browser. On importe explicitement les données dans l'espace de
-travail. On peut détecter que les maillages sont identiques et on
-propose à l'utilisateur de transférer le champ sur le maillage déjà
-présent. Sinon, les champs devront être référencés sur des maillages
-distincts dans l'arbre de l'espace de travail.
-
-Analyses préliminaires pour le chantier 2011
-============================================
-
-On fait le choix pour le chantier 2011 de travailler à partir de la
-bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
-le démonstrateur 2011).
-
-Analyse de MEDCoupling et MEDLoader
------------------------------------
-
-MEDCoupling est l'implémentation du modèle de données MED (avec
-recherche de minimisation des dépendances logicielles) et MEDLoader
-fournit une ensemble de fonctions pour le chargement des structures
-MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
-forme de fichiers.
-
-Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
-d'une grandeur physique sur un maillage pour un pas de temps donné. Un
-champ est caractérisé par:
-
-* un support spatial, le maillage
-* un type de discrétisation spatial, défini par l'emplacement des
- valeurs sur le maillage (sur les noeuds, sur les cellules, aux
- points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
- etc)
-* un pas de temps, défini par deux entiers (iteration, order) et un
- réel (timestamps)
-
-Dans cette implémentation, il existe une association 1..n entre un
-maillage et un champ (alors que dans MEDMEM, la structure
-intermédiaire SUPPORT est implémentée).
-
-MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
-des structures MEDCoupling au travers du bus CORBA. L'interface à ce
-jour est délibérément réduite. Des classes dites "Cliente" sont
-fournies pour piloter les servants CORBA depuis un contexte
-client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
-fonction de création d'une structure MEDCoupling à partir d'un
-pointeur vers un servant CORBA. La structure est créée localement
-(dans le contexte client) avec duplication des données issue de la
-structure encapsulée par le servant CORBA (récupération par la
-fonction de sérialisation).
-
-Aucune interface CORBA n'est défini pour MEDLoader.
-
-Questions:
-
-* Voir comment sont créés les servants, et surtout comment ils sont
- récupérés (via le lcc?)
-* Comment peut-on définir un champ sur un groupe de mailles (et non
- pas sur le maillage complet)? Comment peut-on extraire le champs
- circoncit à une groupe de mailles pour des opérations.
-
- - R: méthode changeUnderlyingMesh
-
-* Comment manipuler deux champs chargées de fichiers différents mais
- construit sur le même maillage (conceptuellement). On peut forcer la
- réassociation d'un champ sur un autre maillage?
-* Manipuler des champs de pas de temps différents? Différentes
- composantes d'un ou plusieurs champs?
-* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
-
-* mapper sur une image
-
-Improvments:
-
-* MEDLoader::Write should raise an exception if the filepath is not writable
-* MEDDataManager: développer une classe chapeau sur MEDCoupling et
- MEDLoader pour aider au chargement et la gestion de données MED
- (orienté manipulation de champs). Cette classe serait associée des
- structures légères FieldHandler et MeshHandler et des listes
- correspondantes pour la navigation dans les méta-données.
-* Sur base du MEDDataManager, prévoir des ports med pour yacs par
- lesquels pourrait transiter des handler.
-
-Nouveaux concepts à prendre en compte
--------------------------------------
-
-Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
-
-* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
- les fichiers med et obtenir les informations générales sur le
- contenu.
-* MEDFILEBROWSER: remplace le concept de driver et fournit les
- fonctions précédemment fournies par la classe MED pour obtenir les
- informations de structure.
-* Concept d'Extractor pour une lecture sélective des données de champs
- (suivant un critère d'extraction)
-* Il n'est plus nécessaire d'appeler les méthodes read explicitement
- sur les objets (MESH et FIELD) pour charger les données. Par
- ailleurs, on peut définir deux fois le même champs (double
- chargement a priori) sans lever d'exception).
-
-
-Analyse de conception pour le chantier 2011
-===========================================
-
-Composants SALOME (interfaces IDL)
-----------------------------------
-
-* MEDDataManager: défini une structure FIELD pour identifier un champ
- dans les requêtes. Il s'occupe également de la récupération physique
- des données, quelqu'en soit la source (fichier avec MEDLoader, autre
- module SALOME comme PARAVIS avec une méthode à définir)
-* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
- les structures FIELD du MEDDataManager. Reprendre l'interface de
- MEDOP.
-
-Use case à réaliser depuis un client python:
-
-* UC01: ajouter un fichier d'entrée et accéder aux informations
- concernant les champs. Ex: récupérer une structure champs par la
- donnée des paramètres primaires (nom identifiant, dt, it, nom du
- maillage).
-* UC02: créer des champs et les ajouter au MEDDataManager
-* UC03: mener des opérations basique sur les champs en console python
-
-Interface Utilisateur
----------------------
-
-L'interface utilisateur est composée des parties suivantes:
-
-* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
- le chargement des données dans l'espace de travail, au moyen d'une
- interface graphique;
-* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
- la création de champs, au moyen de commandes exécutées dans la
- console python.
-
-Le principe est que les champs sont préalablement chargés au niveau du
-composant SALOME au moyen de l'interface graphique (MEDGUI), puis
-manoeuvrés depuis l'application SALOME au moyen de variables proxy
-définies dans la console python (MEDTUI). Au chargement, les champs
-sont indéxés par le MEDDataManager, puis les index sont rendus
-accessibles au niveau du GUI au moyen d'une représentation
-arborescente de la structure MED. Les feuilles de l'arbre
-correspondent à des champs qui peuvent être sélectionnés et dont
-l'index peut être obtenu de la sélection.
-
-L'espace de travail est organisé autour du concept de
-"workspace". L'étude SALOME liste les datasource (les fichiers source
-des données med, mais peut-être aussi les référence vers des objets
-MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
-permet de voir la structure fine d'une source de données.
-
-Concernant MEDGUI:
-
-* la représentation des données (les champs et les maillages associés)
- doit permettre de récupérer par l'interface graphique les
- identifiants des champs à manipuler (a priori les structures FIELD
- définies par le composant MEDDataManager). Cela conduit à la mise en
- place des composants suivants:
-
- - MedDataModel hérité de TreeData. Il est peuplé avec les
- méta-données décrivant la structure MED explorée.
- - MedGuiManager qui permet l'implantation du doc widget de
- présentation
-
-TODO:
-
-* specifier le concept de workspace (qui a une entrée dans l'étude?)
- en bijection avec un datamanager
-* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
-
-Concernant MEDTUI:
-
-* Il fournit les classes FieldProxy
-
-Questions:
-
-* Comment traiter le cas du travail sur des composantes ciblées, plus
- généralement, comment introduire le concept de domaine
- d'application?
-* Prévoir des fonctions génériques (initialisation d'un champ sur un
- maillage avec une fonction analytique de la position, sauvegarder
- les champs créés dans un fichier med)
-
-
-Tâches de développement
-=======================
-
-T20110622.1: Gestion des données internes
------------------------------------------
-
-**Status: terminé.**
-Suite: fonction de sauvegarde au niveau graphique également
-
-On vise les cas d'utiliation suivants:
-
-* UC1: intégrer dans le datamodel du gui un champ créé dans la console
- python (et donc présent dans le datamanager du composant). Définir
- l'utilité?
-* UC2: renommer un champ et plus généralement changer ses méta-données
- (avec assurance de synchronisation entre toutes les données).
-* UC3: sauvegarder une sélection de champs. La sélection peut se faire
- dans l'arbre du datamodel gui.
-
-WARN: robustesse de fieldproxy
-
-
-
-T20110622.2: UC Initialisation/Création de champs
--------------------------------------------------
-
-**Status: à faire**
-
-Les cas implémentés à ce jour sont la création de champs à partir de
-champs existants et chargés d'un fichier med. On souhaite ici réaliser
-des cas 'utilisation autour de la création de champs "from scratch",
-s'appuyant tout de même sur un maillage chargé.
-
-UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
-champ (par exemple les conditions limites d'un problème de calcul).
-
-UC02: créer un champ avec des restrictions qui définissent le domaine
-d'application des opération de champs.
-
-UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
-composantes du champs vectoriel ou niveaux de gris pour un champ
-scalaire. Attention, pour ça, il faudra a priori fiare une projection
-du maillage cartesien de l'image sur le maillage (quelconque) sur
-lequel on souhaite définir le champ.
-
-UC04: créer un champ à partir d'un tableau numpy
-
-De manière générale, ce type de création sera assisté par le
-MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
-pour l'utilisateur.
-
-Par exemple, prévoir un menu contextuel qui propose les opérations
-possibles en fonction de la sélection (en plus de la fonction d'import
-dans la console python).
-
-TODO:
-
-* développer les fonctions d'initialisation, par exemple au moyen
- d'applyFunc et du mécanisme de callable?
-
-T20110622.3: documentation contextuel
--------------------------------------
-
-**Status: à faire**
-
-* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
- et fieldtools)
-* Faire un modèle générique de command (classe de base
-* Batir la doc des commandes sur cette base (lister toutes les
- instances de type Command par exemple)
-
-T20110622.4: remontée des exception du composant MEDCalculator
---------------------------------------------------------------
-
-**Status: en cours, compléter la couverture**
-
-Pour des messages contextuel sur les erreurs de calcul (ex: division
-par 0)
-
-* Poursuivre le travail fait sur getMedEventListener
-* Protéger tous les appels au composants effectués depuis la console
- python (prendre example sur la commande save)
-
-T20110624.1: gestion des données GUI
-------------------------------------
-
-**Status: à faire**
-
-
-
-Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
-
-* supprimer: supprime tout les champs associés
-* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
- cocher ceux qu'on veut sauvegarder.
-
-Le gui data model est réservé aux opérations sur les champs et à
-piloter leur import dans la console python.
-
-TODO:
-
-* Spécifier les concepts de workspace, database, et datasource, espace
- de gestion, ... et les associations. Simplifier avec l'appuie de use
- cases.
-* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
- l'ajout addChild est implémenté
-* Clic droit sur objets de l'arbre: dans la notification TreeView ->
- WorkspaceController, faire remonter l'évènement clic droit ainsi que la
- liste des éléments sélectionné pour faire générer le menu contextuel
- au niveau du WorkspaceController qui peut déterminer le contexte métier
- (le TreeView ne le connaît pas).
-* Définir des DataObject pour les maillages, les séries temporelles et
- les champs
-
-
-Spécification des espaces de données:
-
-* MEDDataManager dépend de l'étude (pour permettre la publication
- d'information dans une étude SALOME).
-* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
- requetes getFields(sourceid), getMeshes(sourceid)
-* les espaces de données: dataspace, workspace. Un seul workspace par
- étude, mais autand de datasources que l'on souhaite dans le
- dataspace. Les datasources sont rangés dans l'étude (le dataspace)
- et sont non modifiables après chargement (référence des sources de
- données).
-
-
-T20110628.1: extention à d'autres objets SALOME
------------------------------------------------
-
-**Status: suspendu**
-
-On doit reposer la question de l'existance de l'arbre indépendant
-(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
-SMESH en particulier) du principe de sélection graphique pour
-utilisation dans la console python, d'autre part.
-
-
-T20110628.2: visualisation d'un champ avec PARAVIS
---------------------------------------------------
-
-**Status: terminé (pour une première version)**
-Suite: de nombreux défauts subsistent
-
-Questions/remarques:
-
-* Pb au démarrage du module: VisTrails fails to start
-* Peux-t-on piloter la vue 3D sans charger le module? (voir
- myparavis.py)
-* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
-* Comment utiliser directement les objets MEDCouplingField?
-
-
-T20110706.1: documentation du module
-------------------------------------
-
-**Status: en cours (10%)**
-
-Documenter les commandes TUI puis l'utilisation générale de
-l'interafce graphique. Mentionner l'existance de la commande medop.sh
-pour travailler exclusivement en mode texte (utile pour les tests
-rapides).
-
-Documenter les modalités d'exécution des tests.
-
-T20110708.1: helper python pour MEDCoupling
--------------------------------------------
-
-**Status: en attente (pas urgent)**
-
-Faire un helper python dans le package xmed qui permet de faire du
-medcoupling facilement (essentiellement pour simplifier le chargement,
-puis la sélection des données). Cela demanderait de faire un
-MedDataManager comme une class C++ pure (non CORBA). Cette classe
-travaillerait par exemple uniquement avec des id et des liste d'id, et
-fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
-pour obtenir des meta-information.
-
-Le servant MedDataManager pourrait être une surcouche de cette classe
-c++ pure.
-
-T20110708.2: analyses et tests
-------------------------------
-
-TODO:
-
-* créer un fichier de test avec plusieurs pas de temps
-* créer un fichier de test avec des groupes de mailles
-
-
-T20110728.1: refactoring MEDDataManager
----------------------------------------
-
-Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
-
-* dans la mesure du possible utiliser les id plutôt que les handler en
- arguments des fonctions d'appel des objets
-* A chaque champ (FieldHandler), on doit associer un meshid (et de
- manière optionnelle un fieldseriesId, si le champ peut être associé
- à une serie temporelle. A priori faisable uniquement au chargement
- du datasource).
-* Pour cela, revoir les fonctions internes newFieldHandler et addField
- ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
- les informations concernant le meshid.
-* addField est utilisée par le MEDCalculator
-* Attention au raffraichissement des données handler au niveau du
- Workspace. Peut-être le mieux est que les fieldproxy contiennent
- uniquement le fieldid, et qu'ils interroge le datamanager à chaque
- fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
- via le MEDEventListener? **Le plus simple est de faire la mise à
- jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
- on essaye d'afficher les données**. Parceque sinon il n'y a pas de
- problème puisque que le calculateur travaille à partir des id.
-
-
-Petites améliorations du DataspaceController:
-
-* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
- l'alias python dans un attribut du sobject.
-* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
- est posé dans le WS. On peut donc proposer en option de lui associer
- un alias pour manipulation dans la console
-
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2012
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-
-Analyse preliminaire pour le chantier 2012
-==========================================
-
-La figure imposée pour le chantier 2012 est l'intégration du nouveau
-module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
-préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
-
-L'état actuel est:
-
-* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
- MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
- aujourd'hui obsolètes ou amener à disparaître pour l'échéance
- SALOME7
-* Un module SALOME de nom XMED qui fournit les fonctions graphiques
- pour la manipulation de champs.
-* Ce module XMED utilise le module VISU pour les vue de contrôle.
-
-La cible est:
-
-* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
- packages logiciels obsolètes et intégrant les fonctions graphiques
- (GUI et TUI).
-* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
- contrôle.
-* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
- exemple).
-
-A examiner:
-
-* voir les attendus concernant les ports MED dans YACS
-* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
-
-Tâches de développement
-=======================
-
-20120904: Migrer XMED dans MED
-------------------------------
-
-Plan de travail:
-
-* Migration des composants + test
-
-
-
-20120904: Nettoyage de XSALOME
-------------------------------
-
-:status: en cours
-
-* Supprimer les vieilleries de XSALOME:
-
- - StdHelper -> Basic_Utils (KERNEL)
-
-20120829: mise en place du chantier 2012
-----------------------------------------
-
-:status: terminé
-
-L'objectif de cette première étape est de reverser le prototype 2011
-(module XMED indépendant) dans la branche V6_main du module MED. On
-peut procéder de la manière suivante:
-
-* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
- V6_main
-* 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
-
+++ /dev/null
-#!/bin/sh
-# Copyright (C) 2007-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
-#
-
-factor="50%"
-listfiles="\
- medop-gui-aliasfield.png \
- medop-gui-result.png \
- medop-gui-selectfield.png \
- medop-gui-visufield.png"
-
-for file in $listfiles; do
- echo "Processing file $file ..."
- bn=$(basename $file .png)
- outfile=$bn"_scale.png"
- convert -scale $factor $file $outfile
-done
-
-
+++ /dev/null
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Documentation of MED module
-%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-The SALOME MED module provides MEDCoupling library (a C++ library dedicated of
-mesh and field manipulation consistent with MED model), as well as a Graphical
-User Interface to access some usual operations.
-
-References
-==========
-
-**User documentation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-userguide-gui.rst
- medop-userguide-api.rst
-
-**Technical documentation** (**in french**):
-
-.. toctree::
- :maxdepth: 1
-
- medop-specifications.rst
- medop-develguide.rst
-
-**Additional documentation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-references.rst
-
-Document archive (in french)
-============================
-
-**Documentation du prototype 2010**
-
-Cette section décrit le prototype mis au point en 2010 pour les
-analyses de conception (maquette 2010 sur base MEDMEM)
-
-.. toctree::
- :maxdepth: 1
-
- medop-prototype-overview.rst
- medop-prototype-develguide.rst
- medop-prototype-medmem.rst
-
-**Journal de travail**
-
-.. toctree::
- :maxdepth: 1
-
- medop-workingnotes-2010.rst
- medop-workingnotes-2011.rst
- medop-workingnotes-2012.rst
+++ /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_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_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::
-
- loadDatasource(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
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, documentation technique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Cette note fait la synthèse des développements effectués pour le
-maquettage des fonctions de manipulation de champs dans SALOME. Elle
-présente les principes retenus en matière de conception, c'est-à-dire
-concernant les mécanismes techniques sous-jacents, et en matière
-d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
-l'environnement SALOME.
-
-Ces principes sont illustrés par des développements implantés dans le
-module XMED, développé pour les besoins de l'analyse, et dans le
-module MED distribué avec la plateforme SALOME.
-
-.. note:: la lecture de ce chapitre demande une connaissance de la
- structure de classes du module MED, en particulier la distinction
- entre les classes ``MEDMEM::*`` et les servants CORBA associés
- (classe ``SALOME_MED::*``).
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs
-====================
-
-Objectif et motivation
-----------------------
-
-L'objectif de maquettage est de trouver une architecture technique qui
-permet d'exécuter le cas d'utilisation suivant:
-
-* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Opérations pow, sqrt.
-* Possibilité de visualiser les champs produits avec VISU pour
- contrôle des résultats.
-* Possibilité d'exporter des champs produits dans un fichier med.
-
-Eléments de contexte
---------------------
-
-Les opérations de manipulation de champs sont en grande partie
-implémentées dans la bibliothèque MEDMEM. Pour illustration, le
-fragment de code ci-dessous montre comment une addition de champ peut
-être opérée en python:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-Ceci montre que les champs peuvent être manipulés avec une interface
-relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
-f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
-package MEDMEM et wrapping python du package MEDMEM_SWIG).
-
-Par ailleurs, le fonctionnement actuel des modules SALOME qui
-manoeuvrent des données MED est d'instancier les structures de données
-MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
-servants CORBA hébergés dans le processus ``SALOME_Container``, et de
-donner accés à ces données depuis l'étude SALOME au travers de
-pointeurs CORBA. Ce choix d'architecture présente l'avantage de
-centraliser au niveau serveur la gestion du cycle de vie des données
-informatiques et de pouvoir distribuer des "poignées" pour manipuler
-ces données depuis chaque point de l'application qui sait accéder au
-bus CORBA, l'interface graphique en particulier.
-
-
-Hypothèse de travail
---------------------
-
-Compte-tenu de l'objectif de maquettage et des éléments de contexte
-existant, on cherche une solution dans le cadre des hypothèses
-de travail suivantes:
-
-* La manipulation des champs se fait dans l'environement graphique de
- SALOME.
-* Dans cet environnement, on souhaite pouvoir sélectionner
- graphiquement les champs à considérer, puis manipuler ces champs
- dans l'interface texte au moyen de variables python avec une syntaxe
- aussi simple que celle définie dans le wrapping python de MEDMEM,
- c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
- pouvoir écrire f1+f2.
-* Les données MED sont physiquement dans la partie serveur de SALOME
- et accessibles via des pointeurs CORBA (interface spécifiée dans
- MED.idl). On exclu la recopie de données au niveau du client
- graphique.
-
-Dans le cadre de ces hypothèses, la difficulté technique réside dans
-la mise au point d'une interface de communication entre des variables
-manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
-dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
-instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
-processus ``SALOME_Container``).
-
-
-Eléments de conception
-======================
-
-
-Implantation technique
-----------------------
-
-Le diagramme ci-dessous représente l'organisation des principaux
-paquets logiciels du module MED:
-
-.. image:: images/medmem-layers.png
- :align: center
-
-Les cadres bleus représentent le lieu d'implantation des
-développements effectués dans le module MED pour les besoins du
-maquettage. On notera en particulier les interventions aux niveaux
-suivants:
-
-* interfaces idl: ajout de l'interface MEDOP.idl
-* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
- l'interface MEDOP.idl
-
-Architecture technique
-----------------------
-
-Les schéma ci-dessous représente les objets informatiques qui sont à
-l'oeuvre pour la réalisation des opérations sur les champs:
-
-.. image:: /images/xmed-architecture.png
- :align: center
- :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
-
-On distingue les objets suivants:
-
-* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
- MED chargée en mémoire.
-* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
- chargés en mémoire.
-* Une instances de ``SALOME_MED::MED`` et des instances de
- ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
- structure med et des champs qui lui sont associés et chargés en
- mémoire.
-* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
- centralise la mise en oeuvre des opérations de champs sur le serveur
- ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
- sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
- directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
- de temps.
-* Des instances de ``FieldProxy`` qui correspondent aux variables
- manipulées au niveau de l'interface graphique et qui représentent
- les champs. Une instance de FieldProxy possède détient les
- références des servants ``SALOME_MED::MEDOP`` et
- ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
- ``medop_ptr`` et ``field_ptr`` respectivement.
-* Il existe également une instance de ``MedProxy`` non représentée
- dans ce diagramme. Cette instance correspond à une variable qui
- permet de manipuler la structure med.
-
-.. note:: Les éléments apportés par la maquette sont les classes
- ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
- éléments ont pu être modifiés légèrement pour les besoins de
- l'intégration ou pour la correction de quelques bugs.
-
-Le cycle de vie de ces objets est le suivant.
-
-Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
-des champs ``MEDMEM::FIELD``, la création est faite au moment du
-chargement du fichier med dans SALOME au moyen du module MED. A cette
-occasion, les servants CORBA associés ``SALOME_MED::MED`` et
-``SALOME_MED::FIELD`` sont créés et des références vers ces servants
-sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
-l'utilisateur dans l'interface graphique. L'ensemble de ces données
-préexiste à la manipulation de champs.
-
-Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
-``SALOME_MED::MED`` auquel ils sont associées. Le servant
-``SALOME_MED::MED`` possède une référence sur la structure
-``MEDMEM::MED`` et il la transmet à l'instance du servant
-``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
-autonome par la suite pour manipuler les données MED, et les champs en
-particulier. Le code python ci-dessous montre comment un opérateur med
-``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
-l'addition de deux champs:
-
-.. code-block:: python
-
- 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é à
-une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
-``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
-un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
-``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
-une référence directe sur la structure ``MEDMEM::MED`` et peut la
-manoeuvrer pour demander des champs, faire des opérations avec ces
-champs, ajouter le champs résultat à la structure et enfin retourner
-un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
-
-Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
-instance de ``FieldProxy`` est un objet python qui peut être
-manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
-localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
-ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
-d'usage (cf. paragraphe ci-après). La création d'un objet
-``FieldProxy`` déclenche la création d'un opérateur med (instance de
-``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
-référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
-opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
-opérations possibles sur ce champ, comme illustrer sur l'exemple
-ci-dessus.
-
-
-Rôle des objets proxy
----------------------
-
-Dans le modèle d'architecture présenté ci-dessus, on introduit deux
-types d'objets proxy:
-
-* Les objets de classe ``FieldProxy`` qui représentent des poignées de
- manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
- dans le container SALOME.
-* Les objets de classe ``MedProxy`` qui représentent des poignées de
- manipulation des structures ``MEDMEM::MED`` physiquement instanciées
- dans le container SALOME.
-
-Elles sont instanciées dans l'interpréteur python SALOME pour
-manipulation dans l'interface textuelle à partir de la donnée du
-pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
-champ (le nom du champ et le pas de temps défini par le numéro d'ordre
-et le numéro d'iteration:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
-
- from xmed import fieldproxy
- from xmed import medproxy
-
- f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
- f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
-
- field_somme = f1 + f2
- field_offset = f1 + 5.3
-
-Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
-``field_offset`` sont des objets de classe ``FieldProxy``. Ils
-correspondent aux variables physiquement manipulées par
-l'utilisateur pour désigner les champs dans les opérations.
-
-Ces classes proxy sont conçues pour être le lieu d'implémentation de
-l'interprétation des commandes utilisateur et donc de l'ergonomie
-de manipulation des champs au niveau l'interface textuelle. Ce point
-est développé :ref:`plus bas <develguide_execFieldOperation>`.
-
-Programmation de l'interface textuelle
---------------------------------------
-
-Dans le cadre de la maquette, l'interface de manipulation des champs
-est l'interface textuelle python intégrée à SALOME. Dans la pratique,
-l'utilisateur manipule des variables python qui correspondent à des
-objets de classe ``FieldProxy`` équipées des fonctions requises et de
-l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
-ci-dessus).
-
-Or, l'hypothèse de travail est que les données MED sont chargées dans
-SALOME et publiées dans l'étude pour point d'accés depuis l'interface
-graphique. L'utilisateur choisi un champs directement dans l'arbre
-d'étude (ou dans une interface graphique dédiée) puis demande qu'il
-soit mis à disposition dans l'interface python sous un nom de variable
-à choisir. Les captures d'écran ci-dessous montre la séquence
-graphique en images:
-
-.. |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
-lequel le champs sera manipulé dans l'interface textuelle. La
-validation de cette fenêtre doit mettre automatiquement le champ à
-disposition dans l'interface python SALOME et sous le nom de variable
-spécifié par l'alias saisi.
-
-Pour cela, il y a un couplage technique à programmer entre l'interface
-graphique et l'interface textuelle python, avec en particulier la
-transmission des pointeurs vers les servants CORBA mis en jeu dans la
-sélection.
-
-Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
-MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
-implémente l'interface graphique du module. Pour rappel, l'interface
-graphique d'un module SALOME se présente sous la forme d'une classe
-centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
-``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
-par laquelle on peut récupérer une instance de la console python
-embarquée (this->getApp()->pythonConsole()).
-
-Le code suivant illustre l'envoie d'une commande python par ce
-mécanisme. Dans cet example, on cherche à reconstituer dans le
-contexte de la console python un pointer vers un objet med instancié
-dans le contexte C++ de l'application graphique. Pour cela, on
-communique la référence de l'objet sous la forme sérialisé (IOR pour
-un objet CORBA):
-
-.. code-block:: cpp
-
- #include <PyConsole_Console.h>
- #include <QString>
- #include <QStringList>
- #include <SalomeApp_Application.h>
-
- // 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
-
- // Get the IOR of this object
- QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
-
- PyConsole_Console * pyConsole = getApp()->pythonConsole();
-
- 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());
- }
-
-Le code réel de la maquette est basé sur ce principe et transmet à la
-console python des lignes de commandes qui permettent de reconstruire:
-
-* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
- champ sélectionné;
-* une instance de ``FieldProxy`` qui correspond au champ sélectionné
- et avec pour nom de variable la valeur de l'alias saisi dans
- l'interface graphique.
-
-Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
-par la fabrication de la liste de commandes suivante pour envoie à la
-console python par le mécanisme illustré plus haut:
-
-.. code-block:: cpp
-
- QStringList commands;
- commands+="from xmed.fieldproxy import getFieldFromMed";
- commands+="from xmed.medproxy import getMedProxy";
- commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
- commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
-
-Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
-``iterationIndex`` sont construites à partir du champ sélectionné par
-des techniques de programmation standard dans SALOME qu'on peut
-examiner en détail dans la classe ``XMEDGUI`` (voir méthode
-``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
-chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
-
-Le point important à noter ici est que les données à transmettre
-doivent être fournies sous forme de chaînes de caractères ou de types
-simples. C'est pourquoi la référence au servant CORBA
-``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
-c'est-à-dire une chaîne de caractères qui permet l'identification de
-l'objet au niveau du bus CORBA.
-
-Au niveau de la console python cela correspond à l'exécution des
-commandes suivantes:
-
-.. code-block:: python
-
- 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
-``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
-``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
-associée à ce servant (en fait associée au servant
-``SALOME_MED::MEDOP`` créé sur demande par le servant
-``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
-
-.. _develguide_execFieldOperation:
-
-Exécution des opérations sur le champs
---------------------------------------
-
-Les variables définies dans l'interface textuelle pour désigner les
-champs à manipuler sont des objets de classe ``FieldProxy``.
-
-Cette classe a une propriété remarquable, elle est construite sur un
-design pattern de type "Proxy" qui pointe vers un servant
-``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
-directement au servant vers lequel il pointe, mais que l'on passe
-systématiquement par une procédure de l'objet proxy qui fait "boîte
-aux lettres":
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __getattr__( self, name ):
- """
- This method realizes the proxy pattern toward the servant
- SALOME_MED::FIELD.
- """
- return getattr( self.__field_ptr, name )
-
-Ce pattern permet l'implémentation de pré-traitement et/ou de
-post-traitement suivant le type d'accés que l'on cherche à faire.
-
-Il permet aussi et surtout de fournir un objet python qui présente
-l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
-operations de champs. Ici, python est ton ami, car il s'agit pour cela
-d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
-par python pour les operations entre objets. En particulier, la
-re-définition des fonctions internes ``__add__`` (opérateur addition),
-``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
-multiplication) et ``__div__`` (opérateur division) au sein de la
-classe ``FieldProxy``, permet de prendre la main sur le comportement
-des opérations algébriques et de définir une ergonomie sur mesure. Par
-exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
-(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
-réel à une variable de type FieldProxy):
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __add__(self, operande):
- """
- This can process the addition of two fields or the addition of
- a scalar to a field. It depends weither the operande is a
- FieldProxy or a simple scalar numerical value.
- """
- if isinstance(operande, FieldProxy):
- # The operande is an other field
- otherField_ptr = operande.__field_ptr
- rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
- else:
- # The operande is a scalar numerical value that must be
- # considered as an offset in a linear transformation
- factor = 1
- offset = operande
- rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
- return FieldProxy(self.__med_ptr, rfield_ptr)
-
-Il est à noter que dans les deux cas de figure (opérande=champ ou
-opérande=scalaire), la fonction délègue la réalisation concrète de
-l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
-l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
-MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
-service de calcul (l'addition entre champs dans le premier cas,
-l'application d'une transformation linéaire de type y=factor*x+offset
-dans le deuxième cas).
-
-Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
-présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
-l'interface du servant ``SALOME_MED_MEDOP``):
-
-.. code-block:: cpp
-
- /*! Addition of the fields f1 and f2 ( f1+f2) */
- FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Substraction of the fields f1 and f2 (f1-f2) */
- FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Multiplication of the fields f1 by f2 (f1*f2) */
- FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Division of the fields f1 by f2 (f1/f2) */
- FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Power of the field f (f^power) */
- FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
- /*! Linear transformation of the field f (factor*f+offset) */
- FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
- /*! Dublication of the field f */
- FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
-
-Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
-module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
-``MEDMEM_I``). C'est au sein des instances de cette classe que sont
-réalisées les opérations et que sont produites physiquement les
-données. Typiquement, les opérations présentées ici produisent un
-champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
-``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
-ce servant.
-
-Ce mécanisme global peut être étendu sans limitation à tout les types
-d'opération qui sont envisagés dans les spécifications de manipulation
-des champs dans SALOME.
-
-
-Contrôle visuel des champs
---------------------------
-
-Les illustrations ci-dessous montrent qu'une fonction de visalisation
-est implémentée dans la maquette pour permettre le contrôle visuel
-d'un champ au moyen d'une représentation 3D (une carte spatiale du
-module du champ dans l'exemple implémenté par défaut):
-
-.. |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.
-
-Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
-module VISU de faire une représentation 3D d'un champ spécifié par la
-donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
-(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
-
-.. code-block:: python
-
- import salome
- import VISU
-
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Then we can import the specified field in the VISU module. This
- # creates an study entry in the VISU folder.
- result = visuComp.ImportMedField(field_ptr)
-
- meshName = field_ptr.getSupport().getMesh().getName()
- fieldName = field_ptr.getName()
- iterNumber = field_ptr.getIterationNumber()
- scalarmap = visuComp.ScalarMapOnField(result,
- meshName,
- visuEntityType,
- fieldName,
- iterNumber)
-
-Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
-particulier à cause de la non définition de la variable
-``visuEntityType``, voir remarque plus bas), le composant VISU
-désigné ici par la variable ``visuComp`` va chercher les données du
-champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
-argument de la fonction ``ImportMedField``, puis produit une
-représentation de type "scalarmap".
-
-.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
- plus haut conférées par le pattern "Proxy", on peut transmettre ici
- aussi bien le servant CORBA que l'instance du proxy (la fonction
- ``ImportMedField`` n'y verra que du feu).
-
-Le code complet et fonctionnel de la fonction d'affichage est dans le
-corps du module python ``fieldproxy.py`` sous la forme d'une fonction
-de nom ``visuField``. Il convient de noter que cette fonction doit
-établir une correspondance entre le type des entités tel que défini
-dans MED et dans VISU:
-
-.. code-block:: python
-
- medEntityType = field_ptr.getSupport().getEntity()
- if (medEntityType == SALOME_MED.MED_CELL):
- visuEntityType = VISU.CELL
- elif (medEntityType == SALOME_MED.MED_NODE):
- visuEntityType = VISU.NODE
-
-
-Export des résultats de calcul
-------------------------------
-
-Tous les champs produits à l'occasion des opérations entre objets
-``FieldProxy`` sont automatiquement ajoutés à la structure med à
-laquelle is sont associés. Une convention d'attribution des noms est
-implémentée de sorte que par défaut aucune précision n'est demandée à
-l'utilisateur.
-
-La structure med peut être manipulée au moyen de la variable ``med``
-créée dans l'interface textuelle comme une instance de la classe
-``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
-l'interface du servant ``SALOME_MED::MED`` étendue de quelques
-fonctions utilitaires pour la gestion et le contrôle des données.
-
-En particulier, la sauvegarde de la structure dans un fichier est
-automatisée par la méthode ``save(medfilename)``:
-
-.. code-block:: python
-
- med = medproxy.MedProxy(medObj)
- med.save("/tmp/output.med")
-
-Cette méthode s'occupe de définir un driver d'écriture et de procéder
-à l'enregistrement des données de la structure med (les maillages, les
-champs présents au départ et tous les champs produits depuis la
-lecture initiale).
-
-Limitations
-===========
-
-L'implémentation de la maquette limite l'usage des opérations aux cas
-de figure suivants:
-
-* Seules les operations entre champs qui partagent le même support med
- sont possibles. Ceci est une contrainte imposé par la conception
- actuelle de MEDMEM.
-* Le résultat d'une opérations est calculé sur toutes les composantes
- et tout le domaine de définition des champs en opérande. Cette
- deuxième contrainte est juste parce que les usages plus fin,
- notemment avec la notion de domaine de définition, n'a pas encore
- été exéminée à ce jour.
-* Le nom d'un champ produit par une opération ne correspond pas au nom
- de la variable python par laquelle on le réceptionne et on le
- manipule. Le nom est attribué par une convention (ceci n'est pas
- vraiment une limitation mais une caractéristique à connaître).
-
-On note également les restriction techniques suivantes:
-
-* Les données MEDMEM sont supposées être chargées par le composant MED
- puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
- par le module MED).
-* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
- de la classe ``FieldProxy`` soient pris en considération dans les
- opérations sur les champs, il est indispensable que le premier
- opérande d'une opération unitaire soit un champ (objet de classe
- ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
- fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
- car python tente de traiter la situation au moyen de la fonction
- ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
-
-
-Notice informatique
-===================
-
-Gestion de configuration
-------------------------
-
-Les développements décrits dans ce chapitre sont répartis entre les
-modules MED et XMED (développé pour l'occasion). Cette séparation est
-faite par soucis de clarté et d'efficacité de développement, mais les
-éléménts du module XMED ont vocation à intégrer le module MED dans la
-mesure où les propositions techniques sont retenues pour le
-développement à venir.
-
-Le code source du module XMED peut être récupérés par la commande
-suivante::
-
- $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
-
-Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
-équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
-VISU. Pour récupérer la branche BR_medop du module MED, taper la
-commande::
-
- $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
-
-La configuration de référence est:
-
-* XMED: révision svn 41
-* MED: tag cvs BR_medop_20101025
-
-Moyens de tests
----------------
-
-Plusieurs types de tests unitaires sont définis (reste à les
-automatiser proprement):
-
-* Test des servants et utilitaires de manipulation python:
-
- - Dans XMED, package xmed/tests, utiliser le script
- ``test_medoperation.py`` dans un interpréteur python lancé dans
- une session shell SALOME. Ce script prépare des variables de test
- 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``.
-
-* Test des classes MEDMEM:
-
- - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
-
-Un fichier de test basique (mais néanmoins suffisant) de nom
-``tesfield.med`` est fourni avec les sources dans le répertoire
-``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
-répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
-contient deux champs ``testfield1`` et ``testfield2`` définis sur un
-pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
-par éléments (MED_CELL).
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, MED, MEDMEM
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Note de travail concernant l'utilisation de MEDMEM
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module MED de SALOME comporte plusieurs composants d'intérêt pour
-la manipulation de champs:
-
-* la bibliothèque MEDMEM qui fournit une interface de programmation
- pour manoeuvrer une structure MED
-* le module CORBA SALOME_MED qui matérialise le composant SALOME
- (serveur corba) du module MED
-* l'interopérabilité avec le module VISU qui permet la visualisation
- des champs manipulés dans MED
-
-Les sections ci-après donnent quelques éclairages techniques sur ces
-différents aspects. Les sources de démonstration peuvent être
-récupérés depuis le dépôt svn::
-
- $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
- $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation synthétique de MED
-===============================
-
-MED désigne un modèle conceptuel pour décrire des données de type
-éléments finis (éléments finis, volumes finis et éléments
-discrets). Dans l'usage courant, il permet la description et l'échange
-des données de calcul de type maillages et champs. La documentation
-complète peut être trouvée à l'URL suivantes:
-
-* |LINK_EDF_MEDDOC|_ (version 2.3).
-
-On distingue deux implémentations informatiques de ce modèle:
-
-* MED fichier: qui permet la lecture et l'écriture de données depuis
- un fichier au format med. Les opérations de lecture/écriture sont
- atomiques (pas de chargement de la structure de données globale).
-* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
- image de la structure de données MED contenue dans un fichier au
- format med. Les opérations peuvent être atomiques ou
- globales.
-
-On notera simplement ici que MEDMEM utilise MED fichier pour les
-opérations de lecture/écriture et que MED fichier est indépendant de
-MED mémoire. La documentation complète de MED fichier peut être
-trouvée à l'URL suivante:
-
-* |LINK_EDF_MEDFICHIERDOC|_
-
-La bibliothèque MEDMEM
-======================
-
-Le modèle de classes MEDMEM est structuré autour des notions de MESH
-(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
-champs). Ces notions reprennent en partie des concepts du modèle
-MED. Le diagramme ci-dessous présente les classes principales:
-
-.. image:: images/med-uml-main_60pc.png
- :align: center
-
-Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
-figure ci-dessous indique qu'une instance MED peut être associée à
-plusieurs maillage et plusieurs champs. Par contre un champ donné ne
-peut être associé qu'à un seul maillage (par l'intermédiaire du
-support). Plusieurs champs peuvent être associés au même maillage. La
-forme la plus courante est d'ailleurs une instance composé d'un
-maillage unique sur lequel sont définis plusieurs champs.
-
-On peut avoir également des configurations plus complexes, comme par
-exemple un maillage unique, plusieurs champs définis sur ce maillage
-mais avec des supports différents, par exemple parce que les valeurs
-sont définies sur des entités de maillage différentes (les éléments
-pour un champ, les noeuds pour un autre, ...)::
-
- field1->support1->mesh
- field2->support2->mesh
- field3->support3->mesh
-
-On observe:
-
-* 2 champs U et V doivent avoir le même support (au sens informatique
- du terme) pour pouvoir être en argument d'une opération (sinon
- exception). Il faudrait accepter qu'il soit informatiquement
- différent et vérifier la conformité conceptuelle.
-* Cette contrainte peut se comprendre car physiquement les données
- sont stockées dans un vecteur qui couvre toutes les mailles. Le
- support est le seul masque de lecture pour établir la correspondance
- avec les positions dans le maillage et il est donc important qu'une
- cohérence soit assurée.
-
-Les objets champs (FIELD) et maillage (MESH)
---------------------------------------------
-
-Un objet MED permet d'accéder aux différentes informations concernant
-les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
-données physiques associées à ces objets (les valeurs des composantes
-pour les champs, les mailles et leur connectivité pour les
-maillages). L'accès aux données physiques est du ressort des objets
-spécifiques MESH, SUPPORT et FIELD.
-
-Un objet MED peut être créé intégralement en mémoire. L'usage plus
-fréquent est de l'initialiser à partir de la donnée d'un fichier
-med. Pour cela, l'objet MED doit être associé à un driver
-d'entrée/sortie branché sur le fichier (``testfilename`` dans
-l'exemple):
-
-.. code-block:: cpp
-
- MED *myMed = new MED;
- MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
- driverIn->open();
- driverIn->readFileStruct();
- driverIn->close();
-
-A l'occasion de la fonction readFileStruct, la structure interne de
-l'objet MED est enrichie des informations concernant les objets MESH,
-SUPPORT et FIELD contenu dans le fichier. En particulier un
-dictionnaire des champs (variable map interne) est initialisé est
-contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
-méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
-autonome pour être chargé sur demande. On peut alors requêter l'objet
-MED pour obtenir un champ particulier (spécifié par son nom
-``fieldname`` dans l'exemple):
-
-.. code-block:: cpp
-
- FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
-
-Puis le champ qui lui est associé doit être physiquement chargé pour
-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
-----------------------------------------
-
-Les éléments qui composent un maillage sont caractérisés par:
-
-* Le type d'entité de l'élément, à choisir dans la liste
- ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
- ``MED_FACE``, ``MED_CELL``.
-* Le type de géométrie de l'élément, à choisir dans la liste
- ``MED_EN::medGeometryElement``, qui contient en particulier
- ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
-
-Les éléments sont numérotés par un indice relatif à la catégorie
-géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
-composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
-ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
-persistente dans le fichier med). De même, les arrêtes sont numérotées
-de 1 à Na. Une numérotion globale implicite existe sur les éléments,
-elle consiste à parcourir l'ensemble des types géométriques dans
-l'ordre de définition du modèle de données. Ainsi, si le modèle
-contient uniquement les Na arrêtes et les Nf faces, alors l'indice
-global de la première face est Na+1.
-
-.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
-
-
-Binding python de MEDMEM
-------------------------
-
-Les classes du package ``MEDMEM`` (package du module ``MED`` qui
-implémentent les structures de données C++ de MED mémoire) produisent
-la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
-partie mis à disposition de l'interface python grace à une couche de
-liaison (binding Python-C++) générée par le logiciel SWIG à partir
-d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
-package source ``MEDMEM_SWIG``).
-
-Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
-des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
-nouvelle classe est créée (du moins si l'on souhaite profiter de ces
-évolutions dans l'interface python).
-
-Cette mise à jour nécessite de prendre soin au transfert des
-structures de données entre les espaces python et C++. En particulier,
-l'utilisation des template de classe pour décrire les champs typés en
-C++ appelle une précaution de codage particulière de l'interface
-SWIG.
-
-Pour exemple, le fragment de code ci-dessous, extrait du fichier
-``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
-``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));
- }
- 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);
- }
- }
-
- };
-
-
-Utilisation de MEDMEM pour la manipulation de champs
-----------------------------------------------------
-
-Des opérations de manipulation de champs sont disponibles dans la
-bibliothèque MEDMEM standard est peuvent être utilisées dans
-l'interface python. Les quelques lignes suivantes illustrent l'usage
-qu'on peut en faire pour exécuter l'addition de deux champs sur tout
-leur espace de définition et pour un pas de temps donné:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-.. note:: Cet exemple de code requiert les évolutions de MEDMEM
- opérées dans la branche BR_medop (pour disposer de la classe
- MedDataManager en particulier) et le package python ``xmed`` qui
- fournit quelques fonctions utilitaires pour manoeuvrer les données
- med (ce package est dans le module XMED et sera probablement à
- terme intégré au module MED).
-
-Des limitations existent aujourd'hui pour ce type de manipulations:
-
-* les champs doivent partager le même support MED, c'est-à-dire être
- décrit sur le même maillage et sur les mêmes entités de ce
- maillage.
-* ...
-
-
-Remarque sur l'implémentation C++
----------------------------------
-
-A noter l'usage de plusieurs formes d'arguments pour les fonctions:
-
-* passage des arguments par valeur ``myfunction(A a);``
-* passage des arguments par référence ``myfunction(A& a);``
-* passage des arguments par pointeur ``myfunction(A* a);``
-
-Le passage des arguments par référence est une facilité d'écriture
-pour éviter de passer un pointeur tout en évitant la récopie des
-données de la variable.
-
-.. _xmed-medmem_corbainterface:
-
-L'interface CORBA SALOME_MED
-============================
-
-Implémentation du composant MED et des servants SALOME_MED::\*
---------------------------------------------------------------
-
-Le composant MED est un servant CORBA qui permet la manipulation de
-données MEDMEM dans l'environnement SALOME. Le composant peut fournir
-des pointeurs vers des instances de l'interface SALOME_MED (objets
-SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
-servants CORBA qui résident dans le container et qui encapsulent les
-données MEDMEM.
-
-Le schéma ci-dessous représente les éléments informatiques qui
-composent l'architecture CORBA du module MED:
-
-.. image:: images/medmem-corba-layers.png
- :align: center
-
-Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
-CORBA) fonctionnent différement en ce qui concerne le chargement des
-données:
-
-* Dans MEDMEM, les données sont chargées à la demande (fonctions read
- des objets) et aucune gestion n'est assurée. En particulier l'appel
- à read alors que la donnée est déjà chargée conduit à une levée
- d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
- type de gestion.
-* Dans SALOME_MED, les données sont chargées à la création de
- l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
- leurs données sont chargés à ce moment là et gérés dans une table de
- type HashMap au niveau de la structure SALOME_MED::MED. Cette
- structure remplie dés lors des fonction de gestion. L'appel à
- SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
- un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
- l'initialisation (ATTENTION, cette fonction est bugguée dans la
- branche principale -> Fix dans la branche BR_medop).
-
-Une gestion intermédiaire peut être envisagée: le chargement à la
-demande géré dans une ou plusieurs tables de champs (une pour chaque
-type de valeur numérique). Une implémentation de ce type de gestion
-est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
-en charge ce comportement pour les structures de données MED (en
-particulier les champs).
-
-Utilisation du composant MED
-----------------------------
-Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
-interfaces de ce module CORBA sont spécifiées par les fichiers idl
-suivants:
-
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
- ``MED.idl``] qui décrit les interfaces des objets manipulés par le
- module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
- et FIELD.
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
- ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
- (c'est-à-dire le composant chargé par la commande
- ``FindOrLoadComponent("FactoryServer", "MED")`` du
- lyfeCycleCorba). On trouve:
-
- - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
- pour l'implémentation des services généraux des composants SALOME
- (persistance hdf, dump)
- - l'interface ``MED_Gen`` qui hérite des interfaces
- ``Engines::Component`` et ``MED_Gen_Driver`` pour
- l'implémentation des services spécifiques du composant MED.
-
-L'implémentation de ces interfaces est faites au niveau de différents
-packages des sources du module MED:
-
-* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
- interfaces décrites par le fichier ``MED.idl``;
-* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
- décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
- partie composant classique d'un module SALOME.
-* Le package ``MedCorba_Swig`` qui fournit une interface swig
- générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
- ``MED``
-
-L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
-utilise l'interface swig fournie par MedCorba_Swig). Après l'import
-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
-être invoqués. Par exemple, les commandes suivantes chargent toute la
-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)
-
-On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
-qui permet une utilisation assez semblable (mais différente on le
-verra plus bas) à MEDMEM:
-
-.. code-block:: python
-
- fieldIdx = 1 # WRN maybe there is no field of idx=1
- iterationIdx = 0
- fieldName = medObj.getFieldNames()[fieldIdx]
- 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::
- Observations en vrac:
-
- * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
- le champ informatique réel (objet MEDMEM).
- * FIELD_i::fieldMap variable static de type map qui semble gérer
- les différentes instances de FIELD_i (~pattern factory). Cette
- map peut être requétée au moyen d'un indice de type long appelé
- corbaIndex.
- * Quand on crée un FIELD_i par le constructeur d'argument
- ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
- incrément du corbaIndex
- * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
- ``MEDMEM::FIELD_`` associé
- * A CONFIRMER: Il semble que les fonctions de chargement
- ``readStructFile*()`` charge toutes les données du fichier med,
- alors qu'en MEDMEM seules les meta-données sont chargées.
- * A CONFIRMER: il semble que le chargement d'une structure MED
- CORBA peut se faire sans passer par le composant (cf. l'interface
- de MED)
-
-Interface avec le module VISU
-=============================
-
-Des interactions sont possibles entre MED et VISU à partir du moment
-où les données med sont gérées dans l'étude, c'est-à-dire sous la
-forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
-deux conditions sont aujourd'hui nécessaires (objet corba + publié
-dans l'étude) mais il semble que ce ne soit lié qu'à un choix
-d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
-a priori être modifié. A CONFIRMER.
-
-L'exemple de code ci-dessous (en python, mais il peut être transposé à
-une implémentation C++) montre par exemple comment envoyer au module
-VISU une requête de visualisation d'un champs hébergé par le module
-MED (en fait, les données sont gérées au travers d'un objet corba
-SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
-catégorie du composant MED). Les importations standard (salome,
-SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
-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
- result = visuComp.ImportMed(medSObj)
-
-Il est possible de d'aller plus loin et par exemple de déclencher
-l'affichage d'une scalarmap d'un champ spécifique pour une itération
-particulière (voir la fonction
-``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
-``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
-
-Liens complémentaires:
-
-* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
-
-
-Notes en vrac
-=============
-
-Questions:
-
-* 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?
-
-Remarques:
-
-* A part, les opérations arithmétiques (+,-,*,/), aucune opération
- n'est définie.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, vue d'ensemble
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module XMED est un espace d'expérimentation pour le développement
-des opérations de manipulation de champs. Il complète des
-développements intégrés directement dans le module MED et gérés dans
-la branche CVS BR_medop.
-
-Une maquette est au point pour illustrer les propositions en matière
-d'ergonomie d'utilisation et en matière d'architecture technique. La
-maquette permet de réaliser des cas d'utilisation de la forme:
-
-* Chargement d'un fichier med dans le module MED (ou publication par
- un code de calcul).
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Egalement quelques fonctions
- mathématiques standard applicables sur des champs (pow, sqrt).
-* Possibilité de visualiser les champs produits avec VISU
-* Possibilité d'exporter des champs produits dans un fichier med
-
-La figure ci-dessous montre le résultat d'une séquence d'utilisation
-dans laquelle les champs "testfield1" et "testfield2" ont été
-sélectionnés dans l'arbre d'étude pour être utilisés dans la console
-textuelle sous les noms de variables f1 et f2. L'image montre le
-contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
-ligne de commande:
-
-.. image:: images/medop-gui-result.png
- :align: center
-
-La séquence ci-après montre le cas d'utilisation complet en
-images:
-
-1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
-2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
- défaut, le nom du champ est proposé (``testfield1`` ici). Dans
- l'exemple, l'utilisateur remplace par l'alias ``f1``.
-3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
- ``f1`` au moyen de la commande ``f1.visu()``
-4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
- l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
- récupéré ici dans une variable de nom ``result``.
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-.. |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:
-
-* Les données MEDMEM sont physiquement chargées par le composant MED,
- c'est-à-dire dans le processus ``Container`` de SALOME, et sont
- référencées dans l'étude SALOME.
-* Les opérations sont physiquement des opérations entre objets MEDMEM
- purs qui ont lieu dans le composant MED.
-* Les opérations sont pilotées par des objets proxy python instanciés
- dans la console TUI puis manipulés par l'utilisateur. Ces objets
- proxy savent accéder aux objets MEDMEM au travers de leur interface
- CORBA.
-
-Ainsi, l'architecture technique est construite pour pouvoir travailler
-sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
-depuis des objets python dans l'interface textuelle de
-SALOME. L'effort principal a donc porté sur la mise au point de
-l'interface technique qui permet de lier des variables représentant
-les champs au niveau du GUI (techniquement, la calculette est
-l'interpréteur python embarqué dans le GUI, étendu de quelques
-fonctions pour la manipulation de champs), alors que les données
-MEDMEM sont physiquement disponibles uniquement au niveau des
-composants CORBA (et les opérations implémentées dans MEDMEM
-uniquement).
-
-Pour le moment, la maquette est limitée à des operations entre champs
-qui partagent le même support med (contrainte de MEDMEM) et le
-résultat est calculé sur toutes les composantes et tout le domaine de
-définition du champs (cette deuxième contrainte est juste parce que
-les extentions n'ont pas encore été examinées). Enfin, le support de
-gestion des données est supposé être l'étude SALOME et la structure
-MED qui y est publiée.
+++ /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
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2010
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs du développement
-=====================================
-
-En matière de développement:
-
-* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
- module SALOME diffusable dans la version d'exploitation 2010 (SALOME
- 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
- devoir tenir compte des contraintes de temps SALOME et (ii) le
- produit envisagé fin 2010 est une maquette qui cherche à éprouver
- l'ergonomie générale d'utilisation et en aucun cas on ne peut
- garantir la réalisation d'un module SALOME compatible avec les
- exigences de mise en exploitation.
-* On ne cherche pas d'emblée à capturer tous les cas d'application,
- mais à concevoir un développement qui acceptera les extensions de
- périmètres dans des conditions raisonnables. Aussi, les
- fonctionnalités développées seront celles qui sont nécessaires à la
- réalisation des cas d'application de référence;
-
-En matière d'ergonomie:
-
-* L'interface utilisateur de référence (appelé espace de travail dans
- le volet de spécifications fonctionnelles) est l'interpréteur
- python. Les fonctionnalités doivent être pensées pour un usage
- adapté à une interface textuelle (TUI) de ce type.
-* La création d'une interface graphique (GUI) peut être envisagée en
- complément et comme un moyen de manipuler graphiquement les
- fonctionnalités développées pour l'interface textuelle et pour aider
- la préparation des variables dans l'interface python.
-* Le modèle d'un processus de manipulation de champs est:
-
- - Préparation du jeu de variables U, V, ... représentant les champs
- à manipuler. C'est à ce stade que l'on résoud la question de
- sélection des données (dans un champ publié dans l'arbre d'étude,
- par un module de calcul ou par chargement d'un fichier med)
- - Utilisation des variables avec une sémantique la plus proche
- possible du modèle conceptuel et des spécifications
- fonctionnelles;
- - Création des variables qui représentent les résultats des
- fonctions de manipulation;
- - Persistence (fichier med), visualisation (SALOME) ou export (vers
- une structure qui peut être directement utilisable en numpy)
-
-Sur le plan technique:
-
-* On souhaite spécifier clairement le conteneur SALOME des fonctions
- de manipulation de champs. Pour discussion:
-
- - Il apparaît que les modules SALOME MED et VISU contiennent déjà
- des fonctions qui peuvent faire partie des fonctions de
- manipulations de champs (en particulier pour l'exploration des
- structures MED, leur visualisation et la sélection des données à
- manipuler).
- - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
- tout cas pas sous sa forme de module SALOME) et compte-tenu du
- caractère obsolescent du module VISU (amené à être remplacé sur le
- plan fonctionnel par le module PARAVIS), on pourrait examiner la
- création d'un module dédié à la manipulation des maillages et des
- champs par l'agrégation technique au sein d'un même module des
- fonctions des modules MED et VISU.
-
-Au moins dans un premier temps, on se donne les limites suivantes:
-
-* Une opération ne peut pas combiner des pas de temps différents. Dans
- l'hypothèse où cette limite venait à être levée, on doit spécifier
- le pas de temps de la donnée résultat;
-* Le domaine d'application d'une opération pourra être défini
- exclusivement par la donnée d'un maillage ou un groupe d'éléments du
- maillage;
-* On ne traite pas le cas des champs qui prennent leurs valeurs aux
- points de gauss ou aux noeuds par élément. Une particularité de ces
- types de support est que le repérage de la position implique deux
- indices (par exemple l'indice de la maille, puis l'indice du point
- de gauss).
-
-Eléments de conception
-======================
-
-Plan général
-------------
-
-On peut par exemple imaginer une maquette du genre:
-
-* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
- structure des maillages et des champs dans l'arbre d'étude.
-* Sélectionner un élément (par exemple un pas de temps d'un champ) et
- le menu contextuel permet d'exporter ce champ dans la console python
- pour manipulation. Pour cela, s'inspirer de la fonction
- ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
- PythonConsole.
-* L'élément est marqué comme ayant été exporté, on peut imaginer une
- récupération ultérieure.
-* Exporter un deuxième champ cohérent avec le premier (même pas de
- temps et défini sur le même maillage avec le même support, on
- s'arrange pour).
-* Dans la console python, faire les opérations sur les champs
-* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
- ultérieure. C'est a priori le gros morceau qui consiste à faire un
- objet CORBA MED à partir d'un objet MED standard, en plus défini
- dans la console python (sous forme d'objet python).
-
-Quand ce premier cas d'utilisation est au point, on peut envisager de
-le compléter par les opérations suivantes
-
-* exporter le résultat med dans un fichier
-* visualiser les champs produits
-
-Plan de développement:
-
-* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
- d'architecture, l'opération physique se déroulera en définitif au
- niveau de MEDMEM pur.
-* Prévoir une implémentation des opérations sous forme de fonctions
- informatiques, même les opérations algébriques (+,-,*,/). Pour ces
- dernières et dans certaines conditions (quand on manipule
- directement les strutures MEDMEM et non pas les objets CORBA),
- l'utilisation des formes A+B, A-B, ... peuvent être rendues
- possibles. Dans ce cas, voir la possibilité de combiner plusieurs
- opérations algébriques sur une seule ligne: A+B-C*0.3.
-* On peut charger la structure MED sous forme d'objet CORBA publiable
- dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
- exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
- récupère que les informations nécessaires au chargement d'un champs:
- le nom du champs, le nom de son maillage associé, les identifiants
- du pas de temps, au besoin une structure Field non chargée (par
- exemple pour récupérer plus facilement le maillage).
-* Un mécanisme (à développer à partir du PyConsole par exemple)
- pourrait alors permettre le chargement des champs sélectionnés dans
- la console python et sous un nom facile à manoeuvrer. Prendre
- inspiration sur XCADGUI::LoadIntoPythonConsole().
-* A priori, les données sont physiquement chargée dans le GUI. Au
- besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
- CORBA field à partir d'un field standard (à tester).
-
-Une autre idée est de récupérer le pointeur CORBA MED dans la console
-python et de tirer les données à partir de là. Ajouter une couche de
-wrapping python pur pour gérer les cas de simplification (surcharge
-des opérations arithmétiques par exemple).
-
-Besoins complémentaires:
-
-* L'interpréteur doit contenir des éléments d'aide (par exemple un
- help qui liste les opérations possibles sur les champs chargés)
-* prévoir quelques fonctions de visu et de persistence. Cela commence
- probablement par des fonctions de publication dans l'étude des
- champs créés par les opérations de manipulation. Les champs sont
- physiquement ajouté automatiquement à la structure med par le MedOp
- mais il n'est pas obligatoirement publié => fournir un moyen de
- publication.
-
-Limitations actuelles (liées à la conception de MEDMEM):
-
-* les champs doivent être gérés par la même structure MED car ils
- doivent partager le même support.
-* les opérations possibles dans MEDMEM sont entre champs pris sur un
- pas de temps (Q: les pas de temps peuvent-ils être différents).
-
-
-Développements
---------------
-
-Développement de classes proxy:
-
-* FieldProxy, FieldTimeSeriesProxy
-* Attention pour les éries temporelles, le SUPPORT med peut être
- différent en chaque pas de temps (par exemple en cas d'extension
- spatiale du champ au cours du temps).
-
-MEDMEM_MedDataManager:
-
-* FIX: test de l'implémentation C++ au travers de la fonction test() du
- MedOperator ==> OK. Quand on fait la même opération depuis python
- via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
- destructeur du champ semble être appelé. Pb de gestion des pointeurs?
-
-
-Evolutions à prévoir
-====================
-
-Concernant MEDMEM:
-
-* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
- plusieurs fois de suite puisqu'on recycle la référence si elle est
- déjà chargée.
-* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
- exemple avec un getField qui renvoie le champ s'il est déjà chargé
- ou le charge et le renvoie sinon).
-* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
- passant a priori par le driver associé. Plusieurs driver peuvent
- être associés à une structure MED car les données peuvent être
- chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
- étendre la structure MED pour avoir accés à la liste des driver puis
- de cette liste déduire les noms des fichiers.
-* IMP: Opérations combinant des champs sur des support différents ne
- peuvent pas être faites par l'API (une exception est levée en cas de
- supports incompatibles), mais on peut imaginer le faire en
- manoeuvrant les tableaux de données directement.
-* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
- et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
-* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
- préalablement ajouté: une fonction removeField en complément de
- addField.
-
-Concernant l'interface SALOME_MED:
-
-* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
- structure MED et requêtées au niveau des classes proxy en spécifiant
- les identifiants des champs impliqués et les paramétres requis (pas
- de temps en particulier).
-
-Concernant le module MED:
-
-* IMP: pourvoir exporter la structure med dans un fichier med (la
- structure ayant pu être enrichie par la publication de champs créés
- par les operations de champs.
-
-
-Historique des travaux
-======================
-
-20100726 : mise au point du schéma de conception
-------------------------------------------------
-
-Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
-raisons:
-
-* MED Coupling ne peut pas gérer des mailles de dimensions différentes
- dans un même modèle (choix faits dans un soucis de performance dans
- l'accès à une structure de donnée compact). On peut contourner le
- problème en définissant deux champs pour traiter chacun des type de
- mailles.
-* Un champ repose sur un maillage complet (pas de notion de profil,
- mais cela peut être émulé en créant deux maillages)
-* Le concept de point de gauss n'existe pas (pas implémenté)
-
-TODO:
-
-* Idéalement, il conviendrait de faire un état des lieux du module
- MED, en particulier des éléments MEDMEM (le coeur), les interfaces
- CORBA associées (MED.idl implémenté dans le package source
- MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
- implémenté dans le package source MED) et le GUI (MedGUI.cxx
- implémenté dans le package source MEDGUI).
-
-* Ergonomie TUI et modèle CORBA associé:
-
- 1. Charger un objet medmem (puis les objets métier mesh et field)
- sur un domaine d'application donné.
- 2. En faire des variables disponibles dans l'interface TUI et que
- l'on peut manipuler dans des opérations algébriques.
- 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
- les autres modules SALOME.
-
-* Compléter le diagramme de la structure informatique de MED (en
- particulier l'implémentation des interface IDL).
-* Préparer un module de travail XMED (organisation d'une bibliothèque)
-
-Tests à réaliser:
-
-* Est-il possible de faire des opérations algébriques à partir des
- objets SALOMEMED (objects CORBA MED)?
-* Création d'un objet MED_i à partir d'une objet MED pur préalablement
- chargé en mémoire.
-
-A retenir:
-
-* Des opérations de champs sont possibles sur des champs à des pas de
- temps fixés. Si l'opération doit être menée sur plusieurs pas de
- temps, alors itérer sur chaque pas de temps. L'idée ici est
- d'introduire le concept de série temporelle de champs en temps
- qu'objet manipulable.
-* Pour deux champs différents de la même structure MED, la données des
- identifiants dt et it ne correspond pas forcément au même instant
- absolu (en tout cas rien ne le garanti, même si c'est tout de même
- une pratique courante).
-
-20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
---------------------------------------------------------------------------
-
-XMED: svn révision 16
-Travailler avec le fichier de donnée testfield.med joint.
-
-
-20101007 : Vers une maquette CORBA
-----------------------------------
-
-Le contexte d'utilisation des opérations de champs est l'environnement
-SALOME. Le support de gestion des données est donc l'étude SALOME. Au
-plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
-session SALOME (soit par un code de calcul intégré, soit par
-chargement des données à partir d'un fichier med). Ces objets sont en
-général référencés dans l'étude SALOME sous la forme d'objets CORBA de
-classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
-SObject (Study Object) dont un attribut est une référence vers un
-objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
-MEDMEM::Field.
-
-On peut donc envisager une solution dans laquelle on donne à
-l'utilisateur des poignées de manipulation des objets
-SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
-type proxy. Cela signifie que l'utilisateur ne manipule pas
-directement des objets MEDMEM mais des objets python qui font
-l'interface (à concevoir et implémenter, a priori avec un design
-pattern de type proxy).
-
-L'utilisation directe des objets MEDMEM aurait pu être une solution
-extremement pratique dans la mesure où ces objets en l'état peuvent
-être combinés dans des opérations de champs (c'est déjà
-implémenté). Par contre, ce procédé souffre de limitations importantes
-dans la gestion et la circulation des données pour les différents cas
-d'utilisation envisagés (visualisation, export, transfert à un autre
-module SALOME).
-
-L'avantage de la solution proposée est multiple:
-
-* Elle permet de travailler sur une structure MED cohérente pour
- intégrer les résultats des opérations de calculs et combiner des
- champs cohérents entre eux. Tout passe par des classes proxy qui
- pourront s'assurer de la cohérence des opérations demandées et
- exécuter automatiquement les fonctions de pré-traitement ou
- post-traitement requises pour ces opérations. On peut imaginer par
- exemple que les requêtes d'opération soient envoyées par les classes
- proxy à la structure MED à laquelle les champs sont associés pour
- piloter l'opération en MEDMEM pur.
-* Elle permet d'automatiser un certain nombre d'opérations
- implicites. Par exemple si deux champs ne sont pas définis dans la
- même unité, un changement d'unité peut être effectué automatiquement
- par la classe proxy avant de commander l'opération au niveau
- MEDMEM.
-* Elle permet de laisser les données sur le container SALOME et de
- réaliser des opérations sans rappatrier les données en local (qui
- peuvent être en trés grand nombre).
-* Elle permet d'étendre facilement l'ergonomie de manipulation des
- champs, par exemple en définissant la notion de *série temporelle de
- champs*, ou encore les concepts de *domaine de définition* évoqués
- dans les spécifications fonctionnelles.
-* Elle rend immédiat la circulation des données entre modules SALOME,
- puisque les champs restent accessble par des objets CORBA, en
- particulier pour la visualisation ou l'export des champs produits
- par les opérations.
-
-Elle a cependant des inconvénients et/ou limitations:
-
-* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
- les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
- se limite a priori aux opérations de champs (les opérations
- algébriques dans un premier temps).
-* Les champs à manipuler dans une opération donnée doivent être gérés
- par la même structure MED.
-
-Il est à noter également que les interfaces de programmation de
-SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
-permettre des requêtes de manipulations de champs (fonctions addition,
-soustraction, multiplication, ...). Pas de contrainte ici sur
-l'ergonomie puisque la manipulation par l'utilisateur se fera au
-niveau des classes proxy uniquement.
-
-
-Hypothèses:
-
-* On tente ici une maquette qui exploite dans la mesure du possible le
- fonctionnement actuel du module MED, en particulier la gestion des
- données dans l'étude.
-* Dans une deuxième version, on pourra examiner sérieusement la
- révision de la gestion des données dans le module, quitte à la
- spécifier et maquetter dans XMED pour intégration ultérieure dans
- MED. Exemple:
-
- - Pouvoir gérer plusieurs structures med dans l'étude.
-
-* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
- des données (gestion des chargements des champs en particulier,
- références croisées pour retrouver le med à partir du champ par
- exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
- faut pouvoir par ailleurs gérer indifféremment une structure med (et
- les champs qui y sont associés) qu'elle soit créée en mémoire from
- scratch ou chargée d'un fichier (donc attention avec les opérations
- de lecture read(), sur les maillages comme sur les champs). La
- structure med permet d'obtenir les méta données (meta-field par
- exemple) mais ne permet pas de savoir si les données sont
- physiquement chargées ou pas.
-
-
-Révisions:
-
-* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
- Première version qui permet d'importer un champ dans la console
- python sous la forme d'un FieldProxy. Ne permet pas encore de faire
- des opérations. Introduction dans le module MED de l'interface MEDOP
- pour prendre en charge les opérations sur les champs.
-
-
-20101019 : Maquette de démonstration pour l'addition
-----------------------------------------------------
-
-Cette maquette implémente une solution technique de bout en bout (de
-l'interface python aux objets MEDMEM, en passant par le fieldproxy
-puis les servants CORBA pour les operations, ...) mais sur le
-périmètre de l'addition de champs sur tout leur domaine de définition
-et pour un pas de temps donné.
-
-Limitations:
-
-* gére l'addition de champs de type double uniquement (parceque le
- reste n'est pas implémenté)
-
-Révisions:
-
-* XMED: svn révision 25
-* MED: cvs tag BR_medop_20101019
-
-
-20101020: Fonctions complémentaires
------------------------------------
-
-Cette version test la faisabilité des fonctions complémentaires pour
-accompagner la manipulation de champs. Cela comprend en particulier:
-
-* **la sauvegarde des champs produits** dans un fichier med (un champ ou
- toute la structure med). Pour cela, on définit un med proxy comme
- l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
- de fonction au niveau C++ pour permettre un usage au niveau du GUI
- C++?).
-* **la visualisation d'un champ** au moyen du module VISU.
-* **des fonctions d'aide interactives** pour assister l'utilisateur
- dans la console de manipulation des champs.
-
-
-Questions:
-
-* peut-on sauvegarder un champ unique?
-* peut-on faire en sorte que ce soit l'affectation à une variable qui
- provoque l'ajout du champ à la structure med (ou plus exactement qui
- supprime tous les champs intermédiaires).
-
-
-Révision:
-
-* XMED: svn revision 31
-* MED: cvs tag BR_medop_20101025
-
-
-20110606: commit avant transfert dans git
------------------------------------------
-
-* XMED: svn revision 53
-
-Les parties de MED utiles à MEDOP seront reversées dans XMED
-dans une première étape, puis le tout dans MED 6 au final.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2011
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Cas d'utilisation métier
-========================
-
-On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
-
- J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
- ajouter de nouveaux champs issus de champs existants. J'aimerais
- aussi pouvoir créer de nouveaux meds plus petits par extraction de
- certaines composantes de champs, certains groupes ou certains pas de
- temps.
-
-On peut exprimer le besoin sous la forme des cas d'utilisation
-suivants (use cases):
-
-* **UC1: combiner dans un même fichier med des champs issus de
- plusieurs sources de données**. On peut par exemple charger un
- premier fichier, puis ajouter à cette base des champs issus d'autre
- fichiers ou générés par manipulation de champs, ou encore générés
- par un module de calcul qui produirait directement du MEDCoupling.
-* **UC2: créer un champ contenant certaines composantes d'un autre
- champ**. On pense ici aux fonctions de restriction, qui permettraient
- de récupérer certaines composantes uniquement.
-* **UC3: créer un champ contenant certains pas de temps d'un autre
- champ**. C'est un cas particulier des fonctions de restriction
- évoquées ci-dessus.
-* **UC4: créer un champ comme la limitation d'un autre champ à un
- groupe de mailles**. C'est un cas particulier des fonctions de
- restriction évoquées ci-dessus. Notion de domaine spatial. A
- priori la notion de groupe est définie dans MEDLoader.
-
-On peut ajouter également les UC identifiés pour la maquette 2010:
-
-* **UC5: comparer des champs issus de source de données différentes**,
- par exemple des champs chargés de deux fichiers med différents et
- qui s'appuient sur le même maillage (au moins conceptuellement). Le
- problème technique ici est de pouvoir changer le maillage d'un
- champ, pour ramener tous les champs sur le même maillage (au sens
- informatique). Ceci est une contrainte de MEDCoupling, les
- opérations sur des champs A et B imposent que A et B soient définis
- sur le même maillage, i.e. le même objet informatique.
-* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
- de mailles. Ce cas d'usage est typiquement prévu pour produire les
- conditions de chargement initial d'une structure. Il s'agit ici
- d'initialiser un champ à partir de zéro sur une surface prédéfinie
- de la géométrie (par exemple spécifiée par un nom de groupe de
- mailles).
-
-Pour UC5: les sources de données sont référencées dans l'object
-browser. On importe explicitement les données dans l'espace de
-travail. On peut détecter que les maillages sont identiques et on
-propose à l'utilisateur de transférer le champ sur le maillage déjà
-présent. Sinon, les champs devront être référencés sur des maillages
-distincts dans l'arbre de l'espace de travail.
-
-Analyses préliminaires pour le chantier 2011
-============================================
-
-On fait le choix pour le chantier 2011 de travailler à partir de la
-bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
-le démonstrateur 2011).
-
-Analyse de MEDCoupling et MEDLoader
------------------------------------
-
-MEDCoupling est l'implémentation du modèle de données MED (avec
-recherche de minimisation des dépendances logicielles) et MEDLoader
-fournit une ensemble de fonctions pour le chargement des structures
-MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
-forme de fichiers.
-
-Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
-d'une grandeur physique sur un maillage pour un pas de temps donné. Un
-champ est caractérisé par:
-
-* un support spatial, le maillage
-* un type de discrétisation spatial, défini par l'emplacement des
- valeurs sur le maillage (sur les noeuds, sur les cellules, aux
- points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
- etc)
-* un pas de temps, défini par deux entiers (iteration, order) et un
- réel (timestamps)
-
-Dans cette implémentation, il existe une association 1..n entre un
-maillage et un champ (alors que dans MEDMEM, la structure
-intermédiaire SUPPORT est implémentée).
-
-MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
-des structures MEDCoupling au travers du bus CORBA. L'interface à ce
-jour est délibérément réduite. Des classes dites "Cliente" sont
-fournies pour piloter les servants CORBA depuis un contexte
-client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
-fonction de création d'une structure MEDCoupling à partir d'un
-pointeur vers un servant CORBA. La structure est créée localement
-(dans le contexte client) avec duplication des données issue de la
-structure encapsulée par le servant CORBA (récupération par la
-fonction de sérialisation).
-
-Aucune interface CORBA n'est défini pour MEDLoader.
-
-Questions:
-
-* Voir comment sont créés les servants, et surtout comment ils sont
- récupérés (via le lcc?)
-* Comment peut-on définir un champ sur un groupe de mailles (et non
- pas sur le maillage complet)? Comment peut-on extraire le champs
- circoncit à une groupe de mailles pour des opérations.
-
- - R: méthode changeUnderlyingMesh
-
-* Comment manipuler deux champs chargées de fichiers différents mais
- construit sur le même maillage (conceptuellement). On peut forcer la
- réassociation d'un champ sur un autre maillage?
-* Manipuler des champs de pas de temps différents? Différentes
- composantes d'un ou plusieurs champs?
-* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
-
-* mapper sur une image
-
-Improvments:
-
-* MEDLoader::Write should raise an exception if the filepath is not writable
-* MEDDataManager: développer une classe chapeau sur MEDCoupling et
- MEDLoader pour aider au chargement et la gestion de données MED
- (orienté manipulation de champs). Cette classe serait associée des
- structures légères FieldHandler et MeshHandler et des listes
- correspondantes pour la navigation dans les méta-données.
-* Sur base du MEDDataManager, prévoir des ports med pour yacs par
- lesquels pourrait transiter des handler.
-
-Nouveaux concepts à prendre en compte
--------------------------------------
-
-Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
-
-* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
- les fichiers med et obtenir les informations générales sur le
- contenu.
-* MEDFILEBROWSER: remplace le concept de driver et fournit les
- fonctions précédemment fournies par la classe MED pour obtenir les
- informations de structure.
-* Concept d'Extractor pour une lecture sélective des données de champs
- (suivant un critère d'extraction)
-* Il n'est plus nécessaire d'appeler les méthodes read explicitement
- sur les objets (MESH et FIELD) pour charger les données. Par
- ailleurs, on peut définir deux fois le même champs (double
- chargement a priori) sans lever d'exception).
-
-
-Analyse de conception pour le chantier 2011
-===========================================
-
-Composants SALOME (interfaces IDL)
-----------------------------------
-
-* MEDDataManager: défini une structure FIELD pour identifier un champ
- dans les requêtes. Il s'occupe également de la récupération physique
- des données, quelqu'en soit la source (fichier avec MEDLoader, autre
- module SALOME comme PARAVIS avec une méthode à définir)
-* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
- les structures FIELD du MEDDataManager. Reprendre l'interface de
- MEDOP.
-
-Use case à réaliser depuis un client python:
-
-* UC01: ajouter un fichier d'entrée et accéder aux informations
- concernant les champs. Ex: récupérer une structure champs par la
- donnée des paramètres primaires (nom identifiant, dt, it, nom du
- maillage).
-* UC02: créer des champs et les ajouter au MEDDataManager
-* UC03: mener des opérations basique sur les champs en console python
-
-Interface Utilisateur
----------------------
-
-L'interface utilisateur est composée des parties suivantes:
-
-* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
- le chargement des données dans l'espace de travail, au moyen d'une
- interface graphique;
-* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
- la création de champs, au moyen de commandes exécutées dans la
- console python.
-
-Le principe est que les champs sont préalablement chargés au niveau du
-composant SALOME au moyen de l'interface graphique (MEDGUI), puis
-manoeuvrés depuis l'application SALOME au moyen de variables proxy
-définies dans la console python (MEDTUI). Au chargement, les champs
-sont indéxés par le MEDDataManager, puis les index sont rendus
-accessibles au niveau du GUI au moyen d'une représentation
-arborescente de la structure MED. Les feuilles de l'arbre
-correspondent à des champs qui peuvent être sélectionnés et dont
-l'index peut être obtenu de la sélection.
-
-L'espace de travail est organisé autour du concept de
-"workspace". L'étude SALOME liste les datasource (les fichiers source
-des données med, mais peut-être aussi les référence vers des objets
-MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
-permet de voir la structure fine d'une source de données.
-
-Concernant MEDGUI:
-
-* la représentation des données (les champs et les maillages associés)
- doit permettre de récupérer par l'interface graphique les
- identifiants des champs à manipuler (a priori les structures FIELD
- définies par le composant MEDDataManager). Cela conduit à la mise en
- place des composants suivants:
-
- - MedDataModel hérité de TreeData. Il est peuplé avec les
- méta-données décrivant la structure MED explorée.
- - MedGuiManager qui permet l'implantation du doc widget de
- présentation
-
-TODO:
-
-* specifier le concept de workspace (qui a une entrée dans l'étude?)
- en bijection avec un datamanager
-* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
-
-Concernant MEDTUI:
-
-* Il fournit les classes FieldProxy
-
-Questions:
-
-* Comment traiter le cas du travail sur des composantes ciblées, plus
- généralement, comment introduire le concept de domaine
- d'application?
-* Prévoir des fonctions génériques (initialisation d'un champ sur un
- maillage avec une fonction analytique de la position, sauvegarder
- les champs créés dans un fichier med)
-
-
-Tâches de développement
-=======================
-
-T20110622.1: Gestion des données internes
------------------------------------------
-
-**Status: terminé.**
-Suite: fonction de sauvegarde au niveau graphique également
-
-On vise les cas d'utiliation suivants:
-
-* UC1: intégrer dans le datamodel du gui un champ créé dans la console
- python (et donc présent dans le datamanager du composant). Définir
- l'utilité?
-* UC2: renommer un champ et plus généralement changer ses méta-données
- (avec assurance de synchronisation entre toutes les données).
-* UC3: sauvegarder une sélection de champs. La sélection peut se faire
- dans l'arbre du datamodel gui.
-
-WARN: robustesse de fieldproxy
-
-
-
-T20110622.2: UC Initialisation/Création de champs
--------------------------------------------------
-
-**Status: à faire**
-
-Les cas implémentés à ce jour sont la création de champs à partir de
-champs existants et chargés d'un fichier med. On souhaite ici réaliser
-des cas 'utilisation autour de la création de champs "from scratch",
-s'appuyant tout de même sur un maillage chargé.
-
-UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
-champ (par exemple les conditions limites d'un problème de calcul).
-
-UC02: créer un champ avec des restrictions qui définissent le domaine
-d'application des opération de champs.
-
-UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
-composantes du champs vectoriel ou niveaux de gris pour un champ
-scalaire. Attention, pour ça, il faudra a priori fiare une projection
-du maillage cartesien de l'image sur le maillage (quelconque) sur
-lequel on souhaite définir le champ.
-
-UC04: créer un champ à partir d'un tableau numpy
-
-De manière générale, ce type de création sera assisté par le
-MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
-pour l'utilisateur.
-
-Par exemple, prévoir un menu contextuel qui propose les opérations
-possibles en fonction de la sélection (en plus de la fonction d'import
-dans la console python).
-
-TODO:
-
-* développer les fonctions d'initialisation, par exemple au moyen
- d'applyFunc et du mécanisme de callable?
-
-T20110622.3: documentation contextuel
--------------------------------------
-
-**Status: à faire**
-
-* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
- et fieldtools)
-* Faire un modèle générique de command (classe de base
-* Batir la doc des commandes sur cette base (lister toutes les
- instances de type Command par exemple)
-
-T20110622.4: remontée des exception du composant MEDCalculator
---------------------------------------------------------------
-
-**Status: en cours, compléter la couverture**
-
-Pour des messages contextuel sur les erreurs de calcul (ex: division
-par 0)
-
-* Poursuivre le travail fait sur getMedEventListener
-* Protéger tous les appels au composants effectués depuis la console
- python (prendre example sur la commande save)
-
-T20110624.1: gestion des données GUI
-------------------------------------
-
-**Status: à faire**
-
-
-
-Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
-
-* supprimer: supprime tout les champs associés
-* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
- cocher ceux qu'on veut sauvegarder.
-
-Le gui data model est réservé aux opérations sur les champs et à
-piloter leur import dans la console python.
-
-TODO:
-
-* Spécifier les concepts de workspace, database, et datasource, espace
- de gestion, ... et les associations. Simplifier avec l'appuie de use
- cases.
-* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
- l'ajout addChild est implémenté
-* Clic droit sur objets de l'arbre: dans la notification TreeView ->
- WorkspaceController, faire remonter l'évènement clic droit ainsi que la
- liste des éléments sélectionné pour faire générer le menu contextuel
- au niveau du WorkspaceController qui peut déterminer le contexte métier
- (le TreeView ne le connaît pas).
-* Définir des DataObject pour les maillages, les séries temporelles et
- les champs
-
-
-Spécification des espaces de données:
-
-* MEDDataManager dépend de l'étude (pour permettre la publication
- d'information dans une étude SALOME).
-* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
- requetes getFields(sourceid), getMeshes(sourceid)
-* les espaces de données: dataspace, workspace. Un seul workspace par
- étude, mais autand de datasources que l'on souhaite dans le
- dataspace. Les datasources sont rangés dans l'étude (le dataspace)
- et sont non modifiables après chargement (référence des sources de
- données).
-
-
-T20110628.1: extention à d'autres objets SALOME
------------------------------------------------
-
-**Status: suspendu**
-
-On doit reposer la question de l'existance de l'arbre indépendant
-(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
-SMESH en particulier) du principe de sélection graphique pour
-utilisation dans la console python, d'autre part.
-
-
-T20110628.2: visualisation d'un champ avec PARAVIS
---------------------------------------------------
-
-**Status: terminé (pour une première version)**
-Suite: de nombreux défauts subsistent
-
-Questions/remarques:
-
-* Pb au démarrage du module: VisTrails fails to start
-* Peux-t-on piloter la vue 3D sans charger le module? (voir
- myparavis.py)
-* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
-* Comment utiliser directement les objets MEDCouplingField?
-
-
-T20110706.1: documentation du module
-------------------------------------
-
-**Status: en cours (10%)**
-
-Documenter les commandes TUI puis l'utilisation générale de
-l'interafce graphique. Mentionner l'existance de la commande medop.sh
-pour travailler exclusivement en mode texte (utile pour les tests
-rapides).
-
-Documenter les modalités d'exécution des tests.
-
-T20110708.1: helper python pour MEDCoupling
--------------------------------------------
-
-**Status: en attente (pas urgent)**
-
-Faire un helper python dans le package xmed qui permet de faire du
-medcoupling facilement (essentiellement pour simplifier le chargement,
-puis la sélection des données). Cela demanderait de faire un
-MedDataManager comme une class C++ pure (non CORBA). Cette classe
-travaillerait par exemple uniquement avec des id et des liste d'id, et
-fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
-pour obtenir des meta-information.
-
-Le servant MedDataManager pourrait être une surcouche de cette classe
-c++ pure.
-
-T20110708.2: analyses et tests
-------------------------------
-
-TODO:
-
-* créer un fichier de test avec plusieurs pas de temps
-* créer un fichier de test avec des groupes de mailles
-
-
-T20110728.1: refactoring MEDDataManager
----------------------------------------
-
-Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
-
-* dans la mesure du possible utiliser les id plutôt que les handler en
- arguments des fonctions d'appel des objets
-* A chaque champ (FieldHandler), on doit associer un meshid (et de
- manière optionnelle un fieldseriesId, si le champ peut être associé
- à une serie temporelle. A priori faisable uniquement au chargement
- du datasource).
-* Pour cela, revoir les fonctions internes newFieldHandler et addField
- ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
- les informations concernant le meshid.
-* addField est utilisée par le MEDCalculator
-* Attention au raffraichissement des données handler au niveau du
- Workspace. Peut-être le mieux est que les fieldproxy contiennent
- uniquement le fieldid, et qu'ils interroge le datamanager à chaque
- fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
- via le MEDEventListener? **Le plus simple est de faire la mise à
- jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
- on essaye d'afficher les données**. Parceque sinon il n'y a pas de
- problème puisque que le calculateur travaille à partir des id.
-
-
-Petites améliorations du DataspaceController:
-
-* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
- l'alias python dans un attribut du sobject.
-* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
- est posé dans le WS. On peut donc proposer en option de lui associer
- un alias pour manipulation dans la console
-
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2012
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-
-Analyse preliminaire pour le chantier 2012
-==========================================
-
-La figure imposée pour le chantier 2012 est l'intégration du nouveau
-module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
-préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
-
-L'état actuel est:
-
-* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
- MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
- aujourd'hui obsolètes ou amener à disparaître pour l'échéance
- SALOME7
-* Un module SALOME de nom XMED qui fournit les fonctions graphiques
- pour la manipulation de champs.
-* Ce module XMED utilise le module VISU pour les vue de contrôle.
-
-La cible est:
-
-* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
- packages logiciels obsolètes et intégrant les fonctions graphiques
- (GUI et TUI).
-* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
- contrôle.
-* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
- exemple).
-
-A examiner:
-
-* voir les attendus concernant les ports MED dans YACS
-* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
-
-Tâches de développement
-=======================
-
-20120904: Migrer XMED dans MED
-------------------------------
-
-Plan de travail:
-
-* Migration des composants + test
-
-
-
-20120904: Nettoyage de XSALOME
-------------------------------
-
-:status: en cours
-
-* Supprimer les vieilleries de XSALOME:
-
- - StdHelper -> Basic_Utils (KERNEL)
-
-20120829: mise en place du chantier 2012
-----------------------------------------
-
-:status: terminé
-
-L'objectif de cette première étape est de reverser le prototype 2011
-(module XMED indépendant) dans la branche V6_main du module MED. On
-peut procéder de la manière suivante:
-
-* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
- V6_main
-* 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
-
+++ /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(image2med)
+++ /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
-#
-
-SET(MED_PYTHON_SCRIPTS
- image2med.py
- )
-
-INSTALL(FILES ${MED_PYTHON_SCRIPTS} DESTINATION ${SALOME_INSTALL_BINS}/med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ)
+++ /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_DEFINITIONS(${MEDFILE_DEFINITIONS} ${XDR_DEFINITIONS} ${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-INCLUDE(${QT_USE_FILE})
-SET(QT_LIBS "${QT_LIBRARIES}")
-INCLUDE(UseQt4Ext)
-
-ADD_SUBDIRECTORY(dialogs)
-
-
-SET(MEDOPGUI_SOURCES
- MEDOPFactoryClient.cxx
- XmedConsoleDriver.cxx
- WorkspaceController.cxx
- XmedDataModel.cxx
- MEDEventListener_i.cxx
- MEDOPModule.cxx
- DatasourceController.cxx
- factory.cxx
-)
-
-SET(MEDOPGUI_HEADERS MEDOPModule.hxx MEDEventListener_i.hxx WorkspaceController.hxx DatasourceController.hxx)
-
-QT4_WRAP_CPP(MEDOPGUI_HEADERS_MOC ${MEDOPGUI_HEADERS})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CAS_INCLUDE_DIRS}
- ${Boost_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${GUI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${CMAKE_CURRENT_SOURCE_DIR}/dialogs
- ${CMAKE_CURRENT_BINARY_DIR}/dialogs
- ${CMAKE_CURRENT_SOURCE_DIR}/../cmp
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDGUI
- ${PROJECT_BINARY_DIR}/idl
- ${PROJECT_BINARY_DIR}
-)
-
-SET(MEDOPGUITS_SOURCES
- MED_images.ts
- MED_msg_en.ts
- MED_msg_fr.ts
- MED_msg_ja.ts
- MEDOP_msg_en.ts
- MEDOP_msg_fr.ts
- MEDOP_msg_ja.ts
-)
-
-SET(COMMON_FLAGS
- ${CAS_KERNEL}
- ${QT_MT_LIBRARIES}
- ${OMNIORB_LIBRARIES}
- ${PLATFORM_LIBRARIES}
- ${BOOST_LIBRARIES}
- SalomeIDLMED
- MEDOPGUI_dialogs
- MEDOPFactoryEngine
- ${GUI_qtx}
- ${GUI_suit}
- ${GUI_SalomeObject}
- ${KERNEL_SalomeLifeCycleCORBA}
- ${KERNEL_SalomeKernelHelpers}
- ${GUI_SalomeApp}
- ${GUI_SalomeGuiHelpers}
- ${GUI_SalomeTreeData}
- ${KERNEL_OpUtil}
- ${GUI_CAM}
- ${GUI_LightApp}
- ${GUI_PyConsole}
-)
-
-ADD_LIBRARY(MEDOPGUI SHARED ${MEDOPGUI_SOURCES} ${MEDOPGUI_HEADERS_MOC})
-IF(WITH_MEDMEMGUI)
- SET_TARGET_PROPERTIES(MEDOPGUI PROPERTIES COMPILE_FLAGS "-D__WITH_MEDMEMGUI__")
-ENDIF(WITH_MEDMEMGUI)
-TARGET_LINK_LIBRARIES(MEDOPGUI ${COMMON_FLAGS})
-
-INSTALL(TARGETS MEDOPGUI DESTINATION ${SALOME_INSTALL_LIBS})
-QT4_INSTALL_TS_RESOURCES("${MEDOPGUITS_SOURCES}" "${SALOME_MED_INSTALL_RES_DATA}")
-
-FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /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_DEFINITIONS(${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE(UseQt4Ext)
-
-SET(MEDOPGUI_dialogs_FORMS
- GenericDialog.ui
- DlgAlias.ui
- DlgUseInWorkspace.ui
- DlgChangeUnderlyingMesh.ui
- DlgInterpolateField.ui
- DlgImageToMed.ui
-)
-QT4_WRAP_UI(MEDOPGUI_dialogs_FORMS_HEADERS ${MEDOPGUI_dialogs_FORMS})
-
-SET(MEDOPGUI_dialogs_FILES
- GenericDialog.hxx
- DlgAlias.hxx
- DlgUseInWorkspace.hxx
- DlgChangeUnderlyingMesh.hxx
- DlgInterpolateField.hxx
- DlgImageToMed.hxx
-)
-QT4_WRAP_CPP(MEDOPGUI_dialogs_HEADERS_MOC ${MEDOPGUI_dialogs_FILES})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CAS_INCLUDE_DIRS}
- ${Boost_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${GUI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_SOURCE_DIR}/..
- ${QT4_INCLUDE_DIRECTORY}
-)
-
-SET(MEDOPGUI_dialogs_SOURCES
- GenericDialog.cxx
- DlgAlias.cxx
- DlgUseInWorkspace.cxx
- DlgChangeUnderlyingMesh.cxx
- DlgInterpolateField.cxx
- DlgImageToMed.cxx
-)
-
-ADD_LIBRARY(MEDOPGUI_dialogs SHARED ${MEDOPGUI_dialogs_SOURCES} ${MEDOPGUI_dialogs_HEADERS_MOC} ${MEDOPGUI_dialogs_FORMS_HEADERS})
-TARGET_LINK_LIBRARIES(MEDOPGUI_dialogs ${CAS_KERNEL} ${QT_LIBRARIES} ${KERNEL_SalomeIDLKernel}
- ${GUI_SalomeGuiHelpers} ${OMNIORB_LIBRARIES} ${GUI_qtx} ${GUI_suit} ${PLATFORM_LIBRARIES}
- ${KERNEL_SalomeLifeCycleCORBA} ${KERNEL_SalomeKernelHelpers} ${GUI_SalomeGuiHelpers})
-INSTALL(TARGETS MEDOPGUI_dialogs DESTINATION ${SALOME_INSTALL_LIBS})
-
-#
-# ---------------------------------------------------------
-# Unit test programs
-# ---------------------------------------------------------
-#
-ADD_EXECUTABLE(dlgTester dlgTester.cxx)
-TARGET_LINK_LIBRARIES(dlgTester MEDOPGUI_dialogs ${QT_LIBS} ${PLATFORM_LIBS})
-INSTALL(TARGETS dlgTester DESTINATION ${SALOME_INSTALL_BINS})
-#ADD_TEST(dlgTester dlgTester)
-
-FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /dev/null
-# Copyright (C) 2007-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(testfiles)
-
-SET(MED_RESOURCES_FILES
- datasource_add.png
- datasource_changeUnderlyingMesh.png
- datasource_interpolateField.png
- datasource_expandfield.png
- datasource_field.png
- datasource_mesh.png
- datasource.png
- datasource_use.png
- datasource_view.png
- fileimport-32.png
- folder.png
- image_add.png
- MEDOP.png
- MEDOP_small.png
- workspace_clean.png
- workspace_save.png
- )
-INSTALL(FILES ${MED_RESOURCES_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
+++ /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
-#
-
-SET(MED_FILES
- testfield.med
- smallmesh_varfield.med
- smallmesh_constfield.med
- bigmesh.med
- fieldlena.med
- timeseries.med
- parametric_01.med
- parametric_02.med
- enceinte-axis-E500000.med
- enceinte-axis-E600000.med
- entaille.med
- padderoutput.med
- )
-
-INSTALL(FILES ${MED_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medop_testfiles)
-
-SET(MED_IMG_FILES
- irm_test1.png
- irm_test2.png
- # extra
- README.txt
- champ_altitude_MAP.pgm
- )
-
-INSTALL(FILES ${MED_IMG_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medop_testfiles)
+++ /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(xmedpy)
-ADD_SUBDIRECTORY(presentation)
+++ /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
-#
-
-SET(PYFILES_TO_INSTALL
- __init__.py
- medpresentation.py
- medimages.py
- )
-
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON}/medcalc)
+++ /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
-#
-
-SET(PYFILES_TO_INSTALL
- __init__.py
- fieldproxy.py
- fieldtools.py
- fieldguide.py
- cmdtools.py
-# For the control of PARAVIS and VISU
- driver_pvis.py
- driver_visu.py
-# For the medop.sh executable program
- medop.py
-# Modules that are required for test or tutorial purposes only:
- properties.py
- )
-
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON}/xmed)
-
-SET(TEST_SCRIPTS_XMED
- tests/test_xmed_fieldOperations.py
- tests/test_xmed_uiEventListener.py
- tests/test_xmed_visualisation.py
- )
-
-INSTALL(FILES ${TEST_SCRIPTS_XMED} PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS}/xmed)
\ No newline at end of file
+++ /dev/null
-Note that this test scripts required the PIL python library
-
+++ /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
-#
-
-# This configuration comes in extension with the standard configuration
-# defined by the file envlight.sh for image processing and math
-# processing.
-
-#------ Python Imaging Library ------
-PILDIR=/opt/programs/salome/workspace/prerequisites/install/Pil-117-py266-tcl859-tk859
-export PATH=${PILDIR}/bin:$PATH
-export PYTHONPATH=${PILDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-#------ Numpy ------
-NUMPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Numpy-151-py266-la331
-export PATH=${NUMPY_DIR}/bin:${PATH}
-export PYTHONPATH=${NUMPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-# ------ Scipy ------
-SCIPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Scipy-090-py266-la331-sw204-nu151
-export PYTHONPATH=${SCIPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-# WARN: Matplot, sip and pyqt are requires for the plotter used in
-# lagrange.py (could be optional)
-
-# ------ Matplot ----
-MATPLOT_DIR=/opt/programs/salome/workspace/prerequisites/install/Matplotlib-110-py266-set06c11-num151
-export PYTHONPATH=${MATPLOT_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-#------ sip ------
-SIPDIR=/opt/programs/salome/workspace/prerequisites/install/Sip-4132-py266
-export PATH=${SIPDIR}/bin:${PATH}
-export PYTHONPATH=${SIPDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-export LD_LIBRARY_PATH=${SIPDIR}/lib/python2.6/site-packages:${LD_LIBRARY_PATH}
-
-PYQTDIR=/opt/programs/salome/workspace/prerequisites/install/Pyqt-491p1-py266-qt463p2-sip4132
-#export PYQT_SIPS=${PYQTDIR}/share/sip
-#export PYUIC=${PYQTDIR}/bin/pyuic4
-export PYTHONPATH=${PYQTDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-export PATH=${PYQTDIR}/bin:${PATH}
+++ /dev/null
-P5
-# CREATOR: GIMP PNM Filter Version 1.1
-6 6
-255
-¿¿ÿÿ¿¿¿¿ÿÿ¿¿ÿÿ\ 4\aÿÿÿÿ\ 3\ 4ÿÿ¿¿ÿÿ¿¿¿¿ÿÿ¿¿
\ No newline at end of file
+++ /dev/null
-# -*- coding: iso-8859-1 -*-
-# 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
-#
-
-# This illustrates how to make a mesh partition using the value of a
-# field defined on this mesh (for example to extract the cells where
-# the field takes a value greater than a threshold L.
-# (Anthony Geay, nov. 2012)
-
-# WRN: this use case does not require a med input file because the
-# data (mesh and field) to work with are created from scratch.
-
-from MEDCoupling import *
-
-# =======================================================
-# Creation of the input data (mesh and field)
-# =======================================================
-#
-# We prepare the input field from scratch instead of load it from a
-# file, but there is no difference
-from MEDCouplingDataForTest import MEDCouplingDataForTest
-m3D=MEDCouplingDataForTest.build3DTargetMesh_1()
-m3D.setName("m3D")
-a=DataArrayDouble.New([1.,1.,1.,-1.,-1.,-1.,-1.,-1.])
-field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
-field.setMesh(m3D)
-field.setArray(a)
-field.checkCoherency()
-field.setName("f")
-
-# Save the field (and associated mesh)
-from MEDLoader import MEDLoader
-MEDLoader.WriteField("partition_input.med",field,True)
-
-# =======================================================
-# Determine the border skin mesh
-# =======================================================
-#
-# We have to determine the 2D mesh that delimits the volume where the
-# field is greater than a threshold L from the volume where the field
-# is lower than this threshold (in this example L=0).
-#
-# WRN: This works in SALOME V660 only
-#
-# _T1A
-L=0.
-arr = field.getArray()
-ids = arr.getIdsInRange(L,1e300)
-m3DSub = field.getMesh()[ids]
-skin = m3DSub.computeSkin()
-MEDLoader.WriteUMesh("partition_skin.med",skin,True);
-# _T1B
-
-# =======================================================
-# Compare to the result in SALOME V650
-# =======================================================
-# SALOME V650 requires a more complicated syntax.
-m2D,desc,descI,revDesc,revDescI=m3DSub.buildDescendingConnectivity()
-numberOf3DVolSharing=revDescI.deltaShiftIndex()
-ids2D=numberOf3DVolSharing.getIdsEqual(1)
-skin_V650=m2D[ids2D]
-# We can check if the two skins are identical
-print "Are two meshes equal between V660 and V650 ?",skin.isEqual(skin_V650,1e-12)
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-
-class Function:
- def __init__(self, **kwargs):
- self.kwargs = kwargs
-
- def function(self, x, **kwargs):
- # This should be implemented in a derived class
- raise Runtime("function is not implemented yet")
-
- def __call__(self, x):
- # The argument can be a scalar or a list, we have to check
- # that first.
- if isIterable(x):
- y = map(self,x)
- else:
- y = self.function(x, **self.kwargs)
- return y
-
-def isIterable(x):
- """
- This returns True if the parameter is an iterable, a list or an
- array, or any collection object.
- """
- try:
- len(x)
- return True
- except TypeError, e:
- return False
-
-#
-# =====================================================
-# Implementation of standard functions. All function are normalized
-# function: the xrange is [0,1], the yrange is [0,1]
-import numpy
-from scipy.constants import pi
-
-# Note that in this situation, the create another constructor because
-# the parameters can be deduced from one single parameter xlimit. The
-# constructor must create a kwargs dictionary that map the arguments
-# of the method "function"
-class FuncConique(Function):
- def __init__(self,xlimit):
- a = 1./(xlimit*xlimit-2*xlimit+1)
- b = -2.*a
- c = a
- d = 1/(xlimit*xlimit)
- # We call the super constructor to redefine the kwarg
- # attribute, so that it fits with the arguments of the method
- # "function":
- Function.__init__(self,xlimit=xlimit,a=a,b=b,c=c,d=d)
- # NOTE: Instead of calling the super constructor, we could
- # redefine directly the kwargs attribute:
- #self.kwargs = {"xlimit":xlimit,
- # "a":a, "b":b,
- # "c":c, "d":d}
-
- def function(self,x,xlimit,a,b,c,d):
- if x<xlimit:
- y=d*x*x
- else:
- y=a*x*x+b*x+c
- return y
-
-
-class FuncChapeau(Function):
- def function(self,x,xlimit):
- if x<xlimit:
- y=x/xlimit
- else:
- y=(x-1)/(xlimit-1)
- return y
-
-class FuncStiffExp(Function):
- """
- xlimit : the x position of the top of the function
- stiffness : the higher it is, the stiffer the function is
- """
- def function(self,x,xlimit,stiffness):
- if x<xlimit:
- y=numpy.exp(stiffness*(x-xlimit))
- else:
- y=numpy.exp(-stiffness*(x-xlimit))
- return y
-
-class FuncCosinus(Function):
- def __init__(self,nbPeriods):
- # The pulsation w must be choosen so that w*xmax=n*2pi where
- # xmax=1 and n is an integer that corresponds to the number of
- # oscilations on the xrange [0,xmax].
- w=nbPeriods*2*pi
- Function.__init__(self,w=w)
-
- def function(self,x,w):
- y=numpy.cos(w*x)
- return y
-
-class FuncStiffPulse(Function):
- def __init__(self,xlimit, stiffness, nbPeriods):
- self.stiffexp=FuncStiffExp(xlimit=xlimit,stiffness=stiffness)
- self.cosinus=FuncCosinus(nbPeriods=nbPeriods)
- Function.__init__(self)
-
- def function(self,x):
- y=self.stiffexp(x)*numpy.abs(self.cosinus(x))
- return y
-
-class FuncHeaviside(Function):
- def function(self,x,xlimit):
- if x<xlimit:
- y=0
- else:
- y=1
- return y
-
-class FuncPorte(Function):
- def function(self,x,xinf,xsup):
- if x<xinf or x>xsup:
- y=0
- else:
- y=1
- return y
-
-import lagrange
-class FuncLagrange(Function):
- def __init__(self,points):
- """
- @points : a dictionary whose keys are x values and values are
- y values to be considered as fixed points for interpolation.
- """
- Function.__init__(self)
- self.polynom = lagrange.lagrange(points)
-
- def function(self,x):
- return self.polynom(x)
-
-#
-# =====================================================
-# Unit tests functions
-# =====================================================
-#
-class MyFunction(Function):
- def function(self,x,a,b):
- y=a*x+b
- return y
-
-def TEST_Function():
- # The parameters of the constructor of MyFunction must be
- # consistent with the kwargs parameters of the method function of
- # the class MyFunction (it must map exactly).
- f=MyFunction(a=3.,b=7.)
-
- x=2
- y_ref = 3.*x+7.
- y_res = f(x)
- print y_ref
- print y_res
- if y_ref != y_res:
- print "ERR"
- else:
- print "OK"
-
-def TEST_Function_withIterable():
- f=MyFunction(a=3.,b=1.)
-
- arrX = [0., 1., 2., 3.]
- arrY = f(arrX)
-
- arrY_ref = [1., 4., 7., 10.]
- print "arrY res =%s"%arrY
- print "arrY ref =%s"%arrY_ref
-
-def TEST_FuncConique():
- f=FuncConique(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncChapeau():
- f=FuncChapeau(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncStiffExp():
- f=FuncStiffExp(xlimit=0.3,stiffness=20.)
- from plotter import plot
- plot(f)
-
-def TEST_FuncCosinus():
- f=FuncCosinus(nbPeriods=20)
- from plotter import plot
- plot(f, step=0.001)
-
-def TEST_FuncStiffPulse():
- f=FuncStiffPulse(xlimit=0.3,stiffness=50,nbPeriods=15)
- from plotter import plot
- plot(f, step=0.001)
-
-def TEST_FuncHeaviside():
- f=FuncHeaviside(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncPorte():
- f=FuncPorte(xinf=0.3,xsup=0.4)
- from plotter import plot
- plot(f)
-
-def TEST_customize_01():
- f=FuncStiffPulse(xlimit=0.3,stiffness=40,nbPeriods=20)
-
- # One can customize the final function as follow (in this example,
- # a linear transform)
- def myfunc(x):
- y=5*f(x)+2
- return y
-
- from plotter import plot
- plot(myfunc, step=0.001)
-
-def TEST_customize_02():
- f=FuncHeaviside(xlimit=0.3)
-
- # One can customize the final function as follow (in this example,
- # reverse of heaviside)
- def myfunc(x):
- y=1-f(x)
- return y
-
- from plotter import plot
- plot(myfunc)
-
-def TEST_FuncLagrange():
- points = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
- f=FuncLagrange(points)
- from plotter import plot
- plot(f)
-
-if __name__ == "__main__":
- TEST_Function()
- TEST_Function_withIterable()
- #TEST_FuncConique()
- #TEST_FuncChapeau()
- #TEST_FuncStiffExp()
- #TEST_FuncCosinus()
- #TEST_FuncStiffPulse()
- #TEST_FuncHeaviside()
- #TEST_FuncPorte()
- #TEST_customize_01()
- #TEST_customize_02()
- #TEST_FuncLagrange()
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-import scipy
-def lagrange(points):
- '''
- This returns a polynom that fits the points specified in the input
- dictionary (lagrange interpolation). In this dictionary, the keys
- are x value and the values are y corresponding values
- (i.e. y=polynom(x)). The polynom is a scipy polynom and then is a
- callable (can be used as a function).
- '''
- tmp = scipy.poly1d([0])
- result=scipy.poly1d([0])
-
- for i in points.keys():
- numerator=scipy.poly1d([1])
- denom = 1.0
- for j in points.keys():
- if (i != j):
- tmp = scipy.poly1d([1,-j])
- numerator = numerator * tmp
- denom = denom * (i - j)
- tmp = (numerator/denom) * points.get(i)
- result = result + tmp
-
- return result
-
-def points_usingfunction(arrX,function):
- points={}
- for x in arrX:
- points[x] = function(x)
- return points
-
-def points_usingarray(arrX,arrY):
- points={}
- for i in range(len(arrX)):
- x=arrX[i]
- y=arrY[i]
- points[x] = y
- return points
-
-def sortdict(points):
- # Sort this dictionary by keys and returns 2 lists, the list of X
- # and the list of Y, the whole ordered by X
- keys = points.keys()
- keys.sort()
- return keys, [points[key] for key in keys]
-
-import pylab
-import numpy
-def plot(function, start=0., stop=1., step=0.01):
- """
- The parameter function must be a callable.
- """
- arrX=numpy.arange(start, stop, step, dtype='float64')
- # function is a callable
- arrY=map(function,arrX)
- pylab.plot(arrX, arrY)
- pylab.show()
-
-
-# ---
-# The points does not need to be ordered by x values
-def TEST_lagrange_01():
- input = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-def TEST_lagrange_02():
- input = {0.:0., 0.5:1., 1.:0.}
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# ---
-# One can create the input dictionary from arrays
-def TEST_lagrange_usingarrays_01():
- arrX = [0., 0.2, 0.9, 0.6, 1]
- arrY = [5, 10, 10, 21, 8]
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# Another example using numpy
-def TEST_lagrange_usingarrays_02():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- arrY=numpy.zeros(len(arrX), dtype='float64')
- arrY[3]=2
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# ---
-# One can create the input dictionary from a function applied to an
-# array of X values
-
-# simple method for mathematical functions
-def TEST_lagrange_usingfunction_01():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- arrY=numpy.cos(10*arrX)
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# General method
-xlimit=0.8
-def chapeau(x):
- if x<xlimit:
- y=x
- else:
- y=2*xlimit-x
- return y
-
-def TEST_lagrange_usingfunction_01():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- input = points_usingfunction(arrX,chapeau)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-
-if __name__ == "__main__":
- #TEST_lagrange_01()
- TEST_lagrange_02()
- #TEST_lagrange_usingarrays_01()
- #TEST_lagrange_usingarrays_02()
- #TEST_lagrange_usingfunction_01()
- #TEST_lagrange_usingfunction_01()
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-import pylab
-import numpy
-def plot(function, start=0., stop=1., step=0.01):
- """
- The parameter function must be a callable.
- """
- arrX=numpy.arange(start, stop, step, dtype='float64')
- # function is a callable
- arrY=map(function,arrX)
- pylab.plot(arrX, arrY)
- pylab.show()
+++ /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
-#
-
-import CORBA
-import PARAVIS_Gen_idl
-import SALOME_ContainerManager_idl
-
-from SALOME_NamingServicePy import SALOME_NamingServicePy_i
-
-from MEDCouplingCorba import *
-
-def createALocalMesh():
- targetCoords=[ 0., 0., 0., 50., 0., 0. , 200., 0., 0. , 0., 50., 0., 50., 50., 0. , 200., 50., 0., 0., 200., 0., 50., 200., 0. , 200., 200., 0. ,
- 0., 0., 50., 50., 0., 50. , 200., 0., 50. , 0., 50., 50., 50., 50., 50. , 200., 50., 50., 0., 200., 50., 50., 200., 50. , 200., 200., 50. ,
- 0., 0., 200., 50., 0., 200. , 200., 0., 200. , 0., 50., 200., 50., 50., 200. , 200., 50., 200., 0., 200., 200., 50., 200., 200. , 200., 200., 200. ];
- targetConn=[0,1,4,3,9,10,13,12, 1,2,5,4,10,11,14,13, 3,4,7,6,12,13,16,15, 4,5,8,7,13,14,17,16,
- 9,10,13,12,18,19,22,21, 10,11,14,13,19,20,23,22, 12,13,16,15,21,22,25,24, 13,14,17,16,22,23,26,25];
- targetMesh=MEDCouplingUMesh.New();
- targetMesh.setMeshDimension(3);
- targetMesh.setName("MyMesh3D");
- targetMesh.setDescription("build3DMesh");
- targetMesh.allocateCells(12);
- for i in xrange(8):
- targetMesh.insertNextCell(NORM_HEXA8,8,targetConn[8*i:8*(i+1)]);
- pass
- targetMesh.finishInsertingCells();
- myCoords=DataArrayDouble.New();
- myCoords.setValues(targetCoords,27,3);
- targetMesh.setCoords(myCoords)
- myCoords.setName("check in case")
- return targetMesh;
-
-def createALocalField1():
- m=createALocalMesh()
- field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([1.,11.,101.,1001., 2.,12.,102.,1002., 3.,13.,103.,1003., 4.,14.,104.,1004., 5.,15.,105.,1005., 6.,16.,106.,1006., 7.,17.,107.,1007., 8.,18.,108.,1008.,],8,4)
- field.setArray(da)
- field.setName("vitoo")
- field.setTime(4.5,3,4)
- return field
-
-def createALocalField2():
- m=createALocalMesh()
- field=MEDCouplingFieldDouble.New(ON_NODES,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([float(3*i) for i in xrange(27)],27,1)
- field.setArray(da)
- field.setName("vitooNode")
- field.setTime(4.7,9,14)
- return field
-
-def createALocalMultiField3():
- fName="FieldOverTimeCorba"
- m=createALocalMesh()
- nbOfFields=100
- fs=nbOfFields*[None]
- for i in xrange(nbOfFields):
- fs[i]=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- fs[i].setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([0.,1.,2.+i,3.,4.,5.,7.],8,1)
- fs[i].setArray(da)
- fs[i].setName(fName)
- fs[i].setTime(1.2+i,9,14)
- pass
- ret=MEDCouplingFieldOverTime.New(fs);
- return ret
-
-def createALocalCMesh4():
- mesh=MEDCouplingCMesh.New();
- coordsX=DataArrayDouble.New();
- arrX=[ -1., 1., 2., 4. ]
- coordsX.setValues(arrX,4,1);
- coordsY=DataArrayDouble.New();
- arrY=[ -2., 4., 8. ]
- coordsY.setValues(arrY,3,1);
- coordsZ=DataArrayDouble.New();
- arrZ=[ -3., 3., 6., 12., 17. ]
- coordsZ.setValues(arrZ,5,1);
- mesh.setCoords(coordsX,coordsY,coordsZ);
- mesh.setName("CMeshSample")
- return mesh
-
-def createALocalField5():
- m=createALocalCMesh4()
- field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- field.setTime(14.5,0,0)
- da.setValues([float(7*i) for i in xrange(24)],24,1)
- field.setName("MeshOnCMesh");
- field.setArray(da)
- return field;
-
-
-######
-
-orb = CORBA.ORB_init([], CORBA.ORB_ID)
-poa=orb.resolve_initial_references("RootPOA");
-mgr=poa._get_the_POAManager();
-mgr.activate();
-
-###### Searching for
-
-naming_service = SALOME_NamingServicePy_i(orb)
-rp=SALOME_ContainerManager_idl._0_Engines.ResourceParameters("","","",["PARAVIS"],1,10,10,1,1,"first",[])
-cp=SALOME_ContainerManager_idl._0_Engines.ContainerParameters("","get","",1,False,"",rp)
-sm=naming_service.Resolve("/ContainerManager")
-cont=sm.GiveContainer(cp)
-paraviz=naming_service.Resolve("/Containers/%s/FactoryServer/PARAVIS_inst_1"%(cont.getHostName()))
-
-######
-
-meshCorba=MEDCouplingUMeshServant._this(createALocalMesh())
-ior=orb.object_to_string(meshCorba)
-print "mesh : ",ior
-
-f1=MEDCouplingFieldDoubleServant._this(createALocalField1())
-ior2=orb.object_to_string(f1)
-print "Field on cell ",ior2
-
-f2=MEDCouplingFieldDoubleServant._this(createALocalField2())
-ior3=orb.object_to_string(f2)
-print "Field on node ",ior3
-
-fs3=MEDCouplingFieldOverTimeServant._this(createALocalMultiField3())
-fs3.Register()
-ior4=orb.object_to_string(fs3)
-print "Fields over time ",ior4
-
-m2=MEDCouplingCMeshServant._this(createALocalCMesh4())
-ior5=orb.object_to_string(m2)
-print "CMesh 2 : ",ior5
-
-f5=MEDCouplingFieldDoubleServant._this(createALocalField5())
-ior6=orb.object_to_string(f5)
-print "Field on cell CMesh ",ior6
-
-script="""
-src1 = ParaMEDCorbaPluginSource()
-src1.IORCorba = '%s'
-asc=GetAnimationScene()
-rw=GetRenderView()
-dr=Show()\ndr.Visibility = 1
-"""
-
-content=script%(ior4)
-paraviz.ExecuteScript(content)
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-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
-#
-
-# This script illustrates the basic usage of MEDCoupling and MEDLoader
-# to generate test data files for various cases of med operation. It
-# illustrates also the usage of numpy to specify the values of the
-# fields when defined on a cartesian mesh (grid).
-# (gboulant - 11/07/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-import numpy
-
-#
-# ===============================================================
-# Helper functions to create meshes
-# ===============================================================
-#
-
-def createGridMesh(meshName, nbCellsX, nbCellsY):
- """
- The mesh is created using MEDCoupling. The code below creates a
- cartesian mesh as a grid with nbCellsX segments in the X direction
- and nbCellsY in the Y direction (nb. cells = nbCellsX * nbCellsY)
- """
- print "Creating grid mesh of size %sx%s"%(nbCellsX, nbCellsY)
- cmesh=MC.MEDCouplingCMesh.New();
-
- # Create X coordinates
- nbNodesX = nbCellsX+1
- stepX = 0.1
- arrX = [float(i * stepX) for i in range(nbNodesX)]
- coordsX=MC.DataArrayDouble.New()
- coordsX.setValues(arrX,nbNodesX,1)
-
- # Create Y coordinates
- nbNodesY = nbCellsY+1
- stepY = 0.1
- arrY=[float(i * stepY) for i in range(nbNodesY)]
- coordsY=MC.DataArrayDouble.New()
- coordsY.setValues(arrY,nbNodesY,1)
-
- # Create the grid
- cmesh.setCoords(coordsX,coordsY)
- cmesh.setName(meshName)
-
- return cmesh
-
-def unstructuredMesh(cartesianMesh):
- """
- Convert the cartesian mesh in unstructured mesh for the need of
- write function of MEDLoader
- """
- print "Creating unstructured mesh from %s"%(cartesianMesh.getName())
- umesh=cartesianMesh.buildUnstructured();
- umesh.setName(cartesianMesh.getName())
- return umesh
-
-#
-# ===============================================================
-# Creating a cartesian mesh
-# ===============================================================
-#
-# The size is the number of discrete values in a direction, and then
-# corresponds to the number of cells in that direction.
-size=80
-#size=512
-
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The parameter
-# "size" is considered to be a number of cells (intervals). The number
-# of nodes in that direction is size+1.
-# <<<
-
-nbCellsX = size
-nbNodesX = nbCellsX+1
-
-nbCellsY = size # The size could be different than the X size
-nbNodesY = nbCellsY+1
-
-meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
-cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
-umesh = unstructuredMesh(cmesh)
-medFileName="gendata.med"
-ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
-
-#
-# ===============================================================
-# Creating a scalar field, working with numpy
-# ===============================================================
-#
-
-def createField(fieldName,gridMesh,
- numpy2Darray,typeOfField=MC.ON_CELLS,
- iteration=0):
- """
- The number of values for the fields is deduced from the sizes of
- the numpy array. If typeOfField is ON_CELLS, the size is considered
- as the number of cells, otherwise it's considered as the number of
- nodes. In any case, it must be consistent with the dimensions of
- the numpy 2D array.
- """
- print "Creating field %s with iteration=%s"%(fieldName,iteration)
-
- # The sizes are deduced from the numpy array. Note that if
- # typeOfField is ON_CELLS, then the size should correspond to the
- # number of cells, while if typeOfField is ON_NODES, then the size
- # should correspond to the number of nodes
- [sizeX,sizeY] = numpy2Darray.shape
-
- # We first have to reshape the 2D numpy array in a 1D vector that
- # concatenate all the rows
- data=numpy2Darray.reshape(1,sizeX*sizeY)[0]
- # Then, we can create a simple list as required by the MEDCoupling
- # DataArrayDouble. Note also the usage of float type because
- # MEDCoupling works only with real numbers
- listdata=list(data)
-
- # Create the field using the list obtained from the numpy array
- field = MC.MEDCouplingFieldDouble.New(typeOfField,MC.ONE_TIME);
- field.setName(fieldName);
- field.setMesh(gridMesh);
- field.setIteration(iteration)
- field.setTimeValue(float(iteration))
-
- nbComponents=1 # Only one single component for a scalar field
- nbCells=sizeX*sizeY
- dataArray=MC.DataArrayDouble.New();
- dataArray.setValues(listdata,nbCells,nbComponents)
- field.setArray(dataArray);
-
- return field
-
-def writeField(fieldName, numpy2Darray,
- typeOfField=MC.ON_CELLS,
- iteration=0):
-
- field = createField(fieldName, umesh, numpy2Darray,
- typeOfField, iteration)
- createFromScratch=False
- ML.MEDLoader.WriteField(medFileName,field,createFromScratch)
-
-
-def createTestNumpy2DArray(sizeX, sizeY):
- """
- This illustrates how to create a numpy 2D array for input of the
- createField function.
- """
- rows=[]
- for irow in range(sizeY):
- row = numpy.arange(start = irow*sizeY,
- stop = irow*sizeY+sizeX,
- step = 1,
- dtype='float64')
- rows.append(row)
-
- numpy2Darray = numpy.vstack(rows)
- return numpy2Darray
-
-def createTestFieldOnCells():
- # Test field on cells
- numpy2Darray = createTestNumpy2DArray(sizeX=nbCellsX, sizeY=nbCellsY)
- writeField("FieldOnCells", numpy2Darray,
- typeOfField=MC.ON_CELLS)
-
-def createTestFieldOnNodes():
- # Test field on nodes
- numpy2Darray = createTestNumpy2DArray(sizeX=nbNodesX, sizeY=nbNodesY)
- writeField("FieldOnNodes", numpy2Darray,
- typeOfField=MC.ON_NODES)
-
-
-#
-# =================================================
-# Creating a time series
-# =================================================
-#
-
-# -------------------------------------------------
-# Simple demo of the principles
-# -------------------------------------------------
-
-# In these functions, (x,y) are the indexes of the element in the
-# numpy array. Note that theses indexes maps the indexes of the
-# cartesian mesh.
-
-# A function can be a simple python function ...
-def f1(x,y):
- z = 10*x
- print "x=%s\ny=%s\nz=%s"%(x,y,z)
- return z
-
-# ... but also a more sophisticated callable object, for example to
-# defines some parameters
-class Function(object):
- def __init__(self, sizeX, sizeY, param):
- self.sizeX = sizeX
- self.sizeY = sizeY
- self.param = param
-
- def function(self, x,y):
- z = self.param*x
- print "x=%s\ny=%s\nz=%s"%(x,y,z)
- return z
-
- def __call__(self, x,y):
- return self.function(x,y)
-
-fOnNodes=Function(sizeX=nbNodesX, sizeY=nbNodesY, param=10)
-fOnCells=Function(sizeX=nbCellsX, sizeY=nbCellsY, param=3)
-
-def createFunctionField_01():
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
- f=fOnNodes
- numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
- writeField("FieldOnNodesUsingFunc", numpy2Darray,typeOfField)
-
- f=fOnCells
- sizeX=nbCellsX
- sizeY=nbCellsY
- typeOfField=MC.ON_CELLS
- numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
- writeField("FieldOnCellsUsingFunc", numpy2Darray,typeOfField)
-
-
-# -------------------------------------------------
-# Using the pyfunctions package to generate data
-# -------------------------------------------------
-
-def createNumpy2DArrayWithFunc(sizeX, sizeY, function):
- """
- @function : a callable than can be used as a function of X.
- Typically function should be an instance of Function object
- defined in pyfunctions.functions.
- """
-
- # X coordinates should range between 0 and 1 to use the normalized
- # functions. We have to generate sizeX points:
- step=1./sizeX
- arrX=[float(i * step) for i in range(sizeX)]
-
- values = function(arrX)
-
- # Then on can create the base row for the numpy 2D array
- rowX = numpy.array(values)
- # and replicate this row along the Y axis
- rows=[]
- for irow in range(sizeY):
- rows.append(rowX)
-
- numpy2Darray = numpy.vstack(rows)
- return numpy2Darray
-
-from pyfunctions.functions import FuncStiffPulse
-def createNumpy2DArrayWithFuncStiff(sizeX, sizeY):
- f=FuncStiffPulse(xlimit=0.3,stiffness=30,nbPeriods=10)
- return createNumpy2DArrayWithFunc(sizeX, sizeY, f)
-
-def createFunctionField_02():
- sizeX=nbCellsX
- sizeY=nbCellsY
- typeOfField=MC.ON_CELLS
- numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
- writeField("FieldOnCellsUsingFunc02", numpy2Darray,typeOfField)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
- numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
- writeField("FieldOnNodesUsingFunc02", numpy2Darray,typeOfField)
-
-#
-# =================================================
-# Functions to create custom fields for MEDOP tests
-# =================================================
-#
-def createTimeSeries():
- """
- Create a single med file with a single mesh and a field defined on
- several time steps (time series).
- """
- meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
- medFileName="timeseries.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- nbIterations=10
- pulseStiffNess = 20
- pulseNbPeriods = 10
- for iteration in range(nbIterations):
- xlimit = float(iteration)/float(nbIterations)
- f=FuncStiffPulse(xlimit,stiffness=pulseStiffNess,nbPeriods=pulseNbPeriods)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField("Pulse",umesh,numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-from pyfunctions.functions import FuncStiffExp
-def createParametrics():
- """
- Create 2 med files containing each a mesh (identical) and a field
- defined on this mesh in each file.
- """
- meshName = "Grid_%sx%s_01"%(nbCellsX, nbCellsY)
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- medFileName="parametric_01.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- f=FuncStiffExp(xlimit=0.3,stiffness=30)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- fieldName = "StiffExp_01"
- field = createField(fieldName,umesh, numpy2Darray,typeOfField)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
- medFileName="parametric_02.med"
- umesh.setName("Grid_%sx%s_02"%(nbCellsX, nbCellsY))
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- f=FuncStiffExp(xlimit=0.4,stiffness=30)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- fieldName = "StiffExp_02"
- field = createField(fieldName,umesh, numpy2Darray,typeOfField)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-def createParametrics_demo():
- """
- Create 2 med files containing each a mesh (identical) and a field
- defined on this mesh in each file.
- """
- meshName = "mesh1"
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- listIteration = [0,1,2,3,4]
-
- medFileName="parametric_01.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- fieldName = "field1"
- for iteration in listIteration:
- #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=5)
- f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=10)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
- medFileName="parametric_02.med"
- umesh.setName("mesh2")
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- fieldName = "field2"
- for iteration in listIteration:
- #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=6)
- f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=15)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-
-
-#
-# =================================================
-# Main runner
-# =================================================
-#
-if __name__ == "__main__":
- #createTestFieldOnCells()
- #createTestFieldOnNodes()
- #createFunctionField_01()
- #createFunctionField_02()
- #createTimeSeries()
- createParametrics_demo()
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-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
-#
-
-# This use case illustrates the usage of PIL (Python Imaging Library)
-# combined with the MEDCoupling and MEDLoader modules to save an image
-# as a field in a med file.
-# (gboulant - 27/06/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-#
-# ===============================================================
-# We first get data from the test image to render as a field
-# ===============================================================
-#
-import scipy, numpy
-# The data field array may be created from the lena image
-#image = scipy.lena()
-# We could either read a real image using the PIL python package.
-from scipy.misc import pilutil
-image = pilutil.imread("images/avatar.png",True)
-
-
-#from PIL import Image
-#im=Image.open("images/irm.png")
-#im=Image.open("images/lena.png")
-#image=pilutil.fromimage(im,True)
-#image=numpy.asarray(im)
-#print image
-
-dim = len(image.shape)
-print "Image space dimension = %d"%dim
-sizeX = image.shape[1]
-sizeY = image.shape[0]
-
-# The sizes defined the number of pixel in a direction, then the
-# number of cells to create in the mesh in that direction.
-
-# We must reshape the matrix of pixel in a 1D vector that concatenates
-# all the rows, and then convert this vector in a simple list of
-# double as required by the MEDCoupling field specification.
-import numpy
-imageDataNArray = image.reshape(1,sizeX*sizeY)[0]
-print imageDataNArray
-
-imageDataNArrayDouble = numpy.array(imageDataNArray, dtype='float64')
-imageDataArrayDouble = list(imageDataNArrayDouble)
-
-#
-# ===============================================================
-# Creating a cartesian mesh with a grid of the size of the image
-# ===============================================================
-#
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The data values
-# are considered as values defined on cells. With size values in a
-# direction, we have to create size+1 mesh nodes in that direction.
-# <<<
-
-# The mesh is created using MEDCoupling
-cmesh=MC.MEDCouplingCMesh.New();
-cmesh.setName("imagemesh")
-
-# We use an arbitrary step between cells (the value does not matter)
-stepX = 0.1
-nbNodesX = sizeX+1
-arrX = [float(i * stepX) for i in range(nbNodesX)]
-coordsX=MC.DataArrayDouble.New()
-coordsX.setValues(arrX,nbNodesX,1)
-
-stepY = 0.1
-nbNodesY = sizeY+1
-arrY=[float(i * stepY) for i in range(nbNodesY)]
-coordsY=MC.DataArrayDouble.New()
-coordsY.setValues(arrY,nbNodesY,1)
-
-cmesh.setCoords(coordsX,coordsY)
-print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
-
-# WARN: In the current state of development of MEDLoader, only
-# unstructured meshes are supported for writting function in med
-# files. We just have to convert the cartesian mesh in an unstructured
-# mesh before creating the field.
-umesh=cmesh.buildUnstructured();
-umesh.setName("imagemesh")
-
-#
-# ===============================================================
-# Creating a scalar field on the mesh using image data
-# ===============================================================
-#
-
-# Create the field using MEDCoupling
-field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
-field.setName("imagefield");
-field.setMesh(umesh);
-# OPTIONAL: We set an arbitrary time step for test purpose
-field.setIteration(3);
-field.setOrder(0)
-
-dataArray=MC.DataArrayDouble.New();
-nbCells = sizeX*sizeY
-nbComponents=1 # For a scalar field
-
-# This example shows haw to initialize all cell with the same
-# value. Just create an array of size nbCells
-# dataArray.setValues(nbCells*[3.4],nbCells,nbComponents)
-
-dataArray.setValues(imageDataArrayDouble,nbCells,nbComponents)
-field.setArray(dataArray);
-
-# The MEDLoader can be used to save all the stuff in a med file. You
-# just have to specify the field and the MEDLoader will save the
-# underlying mesh.
-createFromScratch=True
-ML.MEDLoader.WriteField("fieldimage.med",field,createFromScratch)
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-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
-#
-
-# This simple use case illustrates the basic usage of MEDCoupling and
-# MEDLoader to create a cartesian mesh, define a field on this mesh,
-# and save all the stuff in a med file.
-# (gboulant - 27/06/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-#
-# ===============================================================
-# Creating a 512x512 cartesian mesh
-# ===============================================================
-#
-# The size is the number of discrete values in a direction, and then
-# corresponds to the number of cells in that direction.
-size=8
-#size=512
-
-# The mesh is created using MEDCoupling. The code below creates a
-# cartesian mesh as a sizexsize grid
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The data values
-# are considered as values defined on cells. With size values in a
-# direction, we have to create size+1 mesh nodes in that direction.
-# <<<
-
-cmesh=MC.MEDCouplingCMesh.New();
-cmesh.setName("512x512 cartesian mesh")
-
-sizeX = size
-nbNodesX = sizeX+1
-stepX = 0.1
-arrX = [float(i * stepX) for i in range(nbNodesX)]
-print "Size of arrX = %d"%len(arrX)
-
-coordsX=MC.DataArrayDouble.New()
-coordsX.setValues(arrX,nbNodesX,1)
-
-sizeY = size
-nbNodesY = sizeY+1
-stepY = 0.1
-arrY=[float(i * stepY) for i in range(nbNodesY)]
-coordsY=MC.DataArrayDouble.New()
-coordsY.setValues(arrY,sizeY,1)
-
-cmesh.setCoords(coordsX,coordsY)
-print cmesh.getSpaceDimension()
-#print cmesh
-
-# WARN: In the current state of development of MEDLoader, only
-# unstructured meshes are supported for writting function in med
-# files. We just have to convert the cartesian mesh in an unstructured
-# mesh before creating the field.
-umesh=cmesh.buildUnstructured();
-umesh.setName("512x512 unstructured mesh")
-
-# This can be used to save the mesh only (can be visualize using
-# SMESH).
-meshFileName = "umesh.med"
-ML.MEDLoader.WriteUMesh(meshFileName,umesh,True);
-
-# Alternatively, you can use a MEDFileMesh to write the mesh in a
-# file.
-medFileCMesh = ML.MEDFileCMesh.New()
-medFileCMesh.setMesh(cmesh)
-medFileCMesh.setName(cmesh.getName())
-meshFileName = "cmesh.med"
-mode = 2
-medFileCMesh.write(meshFileName,mode)
-
-#
-# ===============================================================
-# Creating a scalar field on the 512x512 mesh
-# ===============================================================
-#
-# For the simple test, we create a field that varies in space as
-# field(x,y)=x+y where x and y are coordinates on the mesh
-
-# --- Field on cells
-
-# Create the field
-field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
-field.setName("AnalyticField_onCells");
-field.setMesh(umesh);
-
-nbComponents=1 # Only one single component for a scalar field
-fillFunction="x+y"
-field.fillFromAnalytic(nbComponents,fillFunction);
-
-# The MEDLoader can be used to save all the stuff in a med file. You
-# just have to specify the field and the MEDLoader will save the
-# underlying mesh.
-createFromScratch=True
-ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
-
-# --- Field on nodes
-
-field = MC.MEDCouplingFieldDouble.New(MC.ON_NODES);
-field.setName("AnalyticField_onNodes");
-field.setMesh(umesh);
-field.fillFromAnalytic(nbComponents,fillFunction);
-createFromScratch=False
-ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
-
-
-#
-# ===============================================================
-# Creating a scalar field, working with numpy
-# ===============================================================
-#
-
-# We start by creating a numpy matrix
-import numpy
-rows=[]
-for irow in range(sizeY):
- row = numpy.arange(irow*sizeY,irow*sizeY+sizeX,dtype='float64')
- rows.append(row)
-
-marray = numpy.vstack(rows)
-
-# Then, we can reshape the matrix in a 1D vector that concatenate all
-# the rows
-data=marray.reshape(1,sizeX*sizeY)[0]
-# Finally, we can create a simple list as required by the MEDCoupling
-# DataArrayDouble. Note also the usage of float type because
-# MEDCoupling works only with real numbers
-listdata=list(data)
-
-# Create the field using the list obtained from the numpy array
-fieldWithNumpy = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
-fieldWithNumpy.setName("Numpy Field");
-fieldWithNumpy.setMesh(umesh);
-
-nbCells=sizeX*sizeY
-dataArray=MC.DataArrayDouble.New();
-dataArray.setValues(listdata,nbCells,nbComponents)
-fieldWithNumpy.setArray(dataArray);
-
-createFromScratch=False
-ML.MEDLoader.WriteField("fieldtest.med",fieldWithNumpy,createFromScratch)
-
-
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-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
-#
-
-# This script illustrates how to create a matrix of pixels from data
-# read in an image file. At the end, the cells of the matrix
-# corresponds to the cells of a cartesian mesh that could hold a field
-# whose value is the value of the pixel.
-# (gboulant - 13/11/2011)
-
-from PIL import Image
-from PIL import ImageOps
-import numpy
-
-def image2matrix():
- # Load the image
- #img=Image.open("images/avatar.png")
- img=Image.open("images/tests.pgm")
-
- # Get a grayscale version
- imgbw=ImageOps.grayscale(img)
-
- # Save the image (optionnal)
- imgbw.save(fp="testsbw.pgm")
-
- # Get the data
- imgdata=imgbw.getdata()
- width,height=imgbw.size
- print list(imgdata)
- print width,height
-
- # Convert the data in a matrix using numpy
- tab=numpy.array(imgdata,dtype='float64')
- print list(tab)
- print tab
- nbRows=height
- nbCols=width
- matrix=numpy.reshape(tab,(nbRows,nbCols))
- # Note that in the reshape function, the height (sizeY) of the image
- # is specified first, because it corresponds to the number of rows.
- print matrix
- print list(matrix)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-def createMesh(meshname, sizeX, sizeY):
- """
- Creating a cartesian mesh with a grid of the size of the image.
- sizeX and sizeY should be respectively the width and heigth of the
- image.
- """
- # >>>
- # WARNING: remember the problem of tics and spaces. The data values
- # are considered as values defined on cells. With size values in a
- # direction, we have to create size+1 mesh nodes in that direction.
- # <<<
-
- # The mesh is created using MEDCoupling
- cmesh=MC.MEDCouplingCMesh.New();
- cmesh.setName(meshname)
-
- # We use an arbitrary step between cells (the value does not matter)
- stepX = 0.1
- nbNodesX = sizeX+1
- arrX = [float(i * stepX) for i in range(nbNodesX)]
- coordsX=MC.DataArrayDouble.New()
- coordsX.setValues(arrX,nbNodesX,1)
-
- # For the Y dimension, we have to reverse the coordinates (the
- # first pixel is at y=height and not at y=0).
- stepY = 0.1
- nbNodesY = sizeY+1
- lengthY = sizeY*stepY
- arrY=[float(lengthY - i * stepY) for i in range(nbNodesY)]
- coordsY=MC.DataArrayDouble.New()
- coordsY.setValues(arrY,nbNodesY,1)
-
- cmesh.setCoords(coordsX,coordsY)
- print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
-
- # WARN: In the current state of development of MEDLoader, only
- # unstructured meshes are supported for writting function in med
- # files. We just have to convert the cartesian mesh in an unstructured
- # mesh before creating the field.
- umesh=cmesh.buildUnstructured();
- umesh.setName("imagemesh")
-
- return umesh
-
-def createField(fieldname, mesh, image):
- """
- Creating a scalar field on the mesh using image data
- """
- # Create the field using MEDCoupling
- field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
- field.setName(fieldname);
- field.setMesh(mesh);
- # OPTIONAL: We set an arbitrary time step for test purpose
- field.setIteration(0);
- field.setOrder(0)
-
- imagedata=list(image.getdata())
- width,height=image.size
- nbCells = width*height
- dataArray=MC.DataArrayDouble.New();
- nbComponents=1 # For a scalar field
-
- dataArray.setValues(imagedata,nbCells,nbComponents)
- field.setArray(dataArray);
-
- return field
-
-def image2med():
- img=Image.open("images/avatar.png")
- #img=Image.open("images/irm.png")
- imgbw=ImageOps.grayscale(img)
- # We keep only the grayscale. Maybe, it could be usefull to get
- # the RGB scales each on one component of the field.
-
- width,height=imgbw.size
- mesh=createMesh("mesh",width,height)
- field=createField("field",mesh,imgbw)
-
- createFromScratch=True
- ML.MEDLoader.WriteField("image.med",field,createFromScratch)
-
-
-# ===================================================================
-
-if __name__ == "__main__":
- #image2matrix()
- image2med()
+++ /dev/null
-all:
- python tutorial.py
- python explore.py
- python manage.py
- python testamel.py
- python cmesh
-
-clean:
- rm -f *~ *.pyc output.med
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-from MEDLoader import MEDLoader
-
-import os
-filename = "madnex_field.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-meshName="my_field_RG"
-fieldName="my_field"
-itNumber=0
-itOrder=0
-
-# Load as an unstructured mesh
-meshDimRelToMax = 0 # 0 = no restriction
-umesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
-print "umesh is structured: %s"%umesh.isStructured()
-
-# Load as a structured mesh explicitly
-# _T2A
-from MEDLoader import MEDFileCMesh
-medfile = MEDFileCMesh.New(filepath,meshName)
-cmesh = medfile.getMesh()
-# Note that the getMesh method is a short way to the method:
-#cmesh = medfile.getGenMeshAtLevel(0,False)
-print "cmesh is structured: %s"%cmesh.isStructured()
-# _T2B
-
-# Load and let MEDLoader decide what is nature of the mesh
-# _T1A
-from MEDLoader import MEDFileMesh
-medfile = MEDFileMesh.New(filepath,meshName)
-print medfile.advancedRepr()
-meshDimRelToMax = 0 # 0 = no restriction
-mesh = medfile.getGenMeshAtLevel(meshDimRelToMax)
-print "mesh is structured: %s"%mesh.isStructured()
-# _T1B
-
-
-# Write the mesh to another file
-# _T3A
-outputfilepath="output.med"
-mode=0
-medfile.write(outputfilepath,mode)
-# _T3B
-
-# test to reload the mesh
-medfile = MEDFileCMesh.New(outputfilepath,meshName)
-cmesh = medfile.getMesh()
-print "cmesh is structured: %s"%cmesh.isStructured()
-
-# Q: Is it possible to know if a mesh is structured or unstructured
-# without loading the mesh.
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-from MEDLoader import MEDLoader
-
-import os
-#filename = "madnex_field.med"
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# Read the source meshes
-meshNames = MEDLoader.GetMeshNames(filepath)
-
-# Set to True if the meshes and fields data must be loaded. Otherwise,
-# only theire descriptions will be loaded.
-READ_PHYSICAL_DATA=False
-
-for meshName in meshNames:
-
- print "%s"%meshName
-
- # At this step, one can load the mesh of name meshName (but it is
- # not an obligation to continue to explore the metadata)
- meshDimRelToMax = 0 # 0 = no restriction
- if READ_PHYSICAL_DATA:
- mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
- # Note that the read function required the parameter
- # meshDimRelToMax. This parameter discreminates the meshdim you
- # are interested to relatively to the maximal dimension of cells
- # contained in the mesh in file (then its value could be 0, -1, -2
- # or -3 depending on the max dimension of the mesh. 0 means "no
- # restriction".
-
- # Read the names of the fields that rely on this mesh
- fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
-
- for fieldName in fieldNames:
-
- print " %s"%fieldName
-
- # 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:
- # 0 = ON_CELLS
- # 1 = ON_NODES
- # 2 = ON_GAUSS_PT
- # 3 = ON_GAUSS_NE
- #
- # As a consequence, before loading values of a field, we have
- # to determine the types of spatial discretization defined for
- # this field and to chooose one.
-
- listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
- for typeOfDiscretization in listOfTypes:
- print " %s"%typeOfDiscretization
-
- # Then, we can get the iterations associated to this field on
- # this type of spatial discretization:
- fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
-
- # Then, we can access to the physical data for each
- # iteration of this field
- for fieldIteration in fieldIterations:
- itNumber = fieldIteration[0]
- itOrder = fieldIteration[1]
- print " (%s,%s)"%(itNumber,itOrder)
-
- if READ_PHYSICAL_DATA:
- medCouplingField = MEDLoader.ReadField(typeOfDiscretization,
- filepath,
- meshName,
- meshDimRelToMax,
- fieldName,
- itNumber,
- itOrder)
- print medCouplingField
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-# _T1A
-import collections
-def tree():
- return collections.defaultdict(tree)
-
-fieldTree = tree()
-meshDict = {}
-# _T1B
-
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# _T2A
-from MEDLoader import MEDLoader
-meshNames = MEDLoader.GetMeshNames(filepath)
-
-meshDimRelToMax = 0 # 0 = no restriction
-
-for meshName in meshNames:
- mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
- meshDict[meshName] = mesh
-
- fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
- for fieldName in fieldNames:
- listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
- for typeOfDiscretization in listOfTypes:
- fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
- for fieldIteration in fieldIterations:
- itNumber = fieldIteration[0]
- itOrder = fieldIteration[1]
-
- field = MEDLoader.ReadField(typeOfDiscretization,
- filepath,
- meshName,
- meshDimRelToMax,
- fieldName,
- itNumber,
- itOrder)
-
- fieldTree\
- [meshName]\
- [fieldName]\
- [typeOfDiscretization]\
- [itNumber][itOrder] = field
-# _T2B
-
-# Q: use a list of structures whose an attribute could be a
-# MEDCoupling field? Or a tree that you cross using attribute and
-# whose leaves are the MEDCoupling fields?
-# R: I think that the default structure should be a simple list that
-# store objects whith properties that corresponds to the metadata (and
-# if loaded the MEDCouplingField or Mesh). Then for specific request,
-# a BTree could be create to organize the search (for example if we
-# request all the fields for a given iteration step, then we should
-# use the iteration step as a first classifaction switch of the tree
-
-print fieldTree.keys()
-
-# _T3A
-for meshName in fieldTree.keys():
- print "%s"%meshName
- for fieldName in fieldTree[meshName].keys():
- print " %s"%fieldName
- for fieldType in fieldTree[meshName][fieldName].keys():
- print " %s"%fieldType
- for itNumber in fieldTree[meshName][fieldName][fieldType].keys():
- for itOrder in fieldTree[meshName][fieldName][fieldType][itNumber].keys():
- print " (%s,%s)"%(itNumber,itOrder)
- print fieldTree[meshName][fieldName][fieldType][itNumber][itOrder]
-# _T3B
+++ /dev/null
-# -*- coding: iso-8859-1 -*-
-# 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
-#
-
-# This illustrates the use of getValueOn in the case of hexahedron
-# meshes (for which a temporary limitation implies the usage of the
-# method simplexize that split the hexahedron into simplex,
-# i.e. triangles and tetrahedrons).
-#
-# (gboulant, nov. 2012)
-from MEDLoader import *
-from MEDCoupling import *
-
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-rmedfilename = filepath
-
-# Load the meshe data
-meshname = "Grid_80x80"
-fieldname = "Pulse"
-dimrestriction = 0 # no restriction
-msource = MEDLoader.ReadUMeshFromFile(rmedfilename,meshname,dimrestriction)
-
-# WARN: In the current version of MEDCoupling, the getValueOn works
-# only with simplex cells (triangles, tetrahedron). This is not a
-# technical problem, but a question of specification of the
-# interpolation to be performed in the case of other cells, in
-# particular in the case of hexahedron meshes.
-#
-# A temporary solution (with good numerical results) is to split
-# hexahedrons into simplex (before the association of the mesh to the
-# field) using the method simplexize.
-policy = 0
-msource.simplexize(policy)
-
-# Load the field data at iteration 0
-iteration = 0
-order = -1
-fieldOnNodes = MEDLoader.ReadField(ON_NODES,rmedfilename,
- meshname,dimrestriction,
- fieldname,iteration,order)
-
-
-fieldOnNodes.setMesh(msource)
-
-# Get the value of field at coordinates x,y
-x=0.5
-y=0.5
-fieldValue = fieldOnNodes.getValueOn([x,y])
-print fieldValue
+++ /dev/null
-#!/usr/bin/env python
-# 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
-#
-
-# This script illustrates the basic features of MEDLoader
-# (gboulant, 17 nov 2012)
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# _T1A
-from MEDLoader import MEDLoader
-meshNames = MEDLoader.GetMeshNames(filepath)
-# _T1B
-meshName=meshNames[0]
-# _T2A
-fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
-# _T2B
-fieldName=fieldNames[0]
-# _T3A
-listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
-# _T3B
-typeOfDiscretization=listOfTypes[0]
-# _T4A
-fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
-# _T4B
-
-iteration = fieldIterations[0]
-iterationNumber = iteration[0]
-iterationOrder = iteration[1]
-
-dimrestriction = 0
-# _T5A
-mesh = MEDLoader.ReadUMeshFromFile(filepath, meshName, dimrestriction)
-# _T5B
-# _T6A
-field = MEDLoader.ReadField(typeOfDiscretization,
- filepath, meshName, dimrestriction,
- fieldName, iterationNumber, iterationOrder)
-# _T6B
