From: Cédric Aguerre Date: Fri, 24 Jul 2015 16:30:49 +0000 (+0200) Subject: [Huge] Introducing MEDCalc X-Git-Tag: simple_cmake~2^2~25 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=fcc88f008be873d54bd6d06fbb39def48d3ab414;p=tools%2Fmedcoupling.git [Huge] Introducing MEDCalc --- diff --git a/CMakeLists.txt b/CMakeLists.txt index 51a6514c3..a79ee2d72 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -50,7 +50,7 @@ IF(NOT SALOME_MED_STANDALONE) 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}) @@ -221,24 +221,24 @@ SET(SALOME_INSTALL_BINS bin/salome CACHE PATH "Install path: SALOME binaries") 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) @@ -267,7 +267,7 @@ SALOME_ACCUMULATE_ENVIRONMENT(PYTHONPATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${SALOM SALOME_ACCUMULATE_ENVIRONMENT(LD_LIBRARY_PATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_LIBS}) -# Sources +# Sources # ======== IF(WIN32) ADD_DEFINITIONS("-D_USE_MATH_DEFINES") @@ -323,21 +323,21 @@ IF(SALOME_USE_MPI) 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() @@ -346,8 +346,8 @@ 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() @@ -381,18 +381,18 @@ SET(SCOTCH_ROOT_DIR "${SCOTCH_ROOT_DIR}") 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 SalomeConfig.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 @@ -401,7 +401,7 @@ CONFIGURE_PACKAGE_CONFIG_FILE(${PROJECT_NAME}Config.cmake.in 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" @@ -409,5 +409,5 @@ INSTALL(FILES 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) diff --git a/doc/doxygen/doxfiles/gui.dox b/doc/doxygen/doxfiles/gui.dox index d8df24f06..6d765eb1a 100644 --- a/doc/doxygen/doxfiles/gui.dox +++ b/doc/doxygen/doxfiles/gui.dox @@ -6,11 +6,11 @@ you to deal with most standard use case of fields manipulation. The user guide can be found here: - User guide of the MED Graphical Interface + href="../../dev/MED/medcalc-userguide-gui.html">User guide of the MED Graphical Interface As a complement, a starter guide to MEDCouplig API is available: - Starter guide to MEDCoupling API for users + href="../../dev/MED/medcalc-userguide-api.html">Starter guide to MEDCoupling API for users You could also be interested to read the software specifications and @@ -18,9 +18,9 @@ requirements for this graphical module, and even the technical considerations for development: - Software + href="../../dev/MED/medcalc-specifications.html">Software specifications and requirements of the MED Graphical Interface (in french) - Developer guide of the MED Graphical Interface (in french) + href="../../dev/MED/medcalc-develguide.html">Developer guide of the MED Graphical Interface (in french) */ diff --git a/idl/CMakeLists.txt b/idl/CMakeLists.txt index 9f47f7c2b..69c3b4a6c 100644 --- a/idl/CMakeLists.txt +++ b/idl/CMakeLists.txt @@ -32,7 +32,7 @@ SET(SalomeIDLMED_IDLSOURCES MEDCalculator.idl MEDEventListener.idl MEDPresentationManager.idl - MEDOPFactory.idl + MEDFactory.idl ) IF(SALOME_USE_MPI) diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index d3d23be80..614d48eef 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -66,7 +66,7 @@ IF(NOT SALOME_MED_STANDALONE) 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) diff --git a/src/MEDCalc/CMakeLists.txt b/src/MEDCalc/CMakeLists.txt new file mode 100644 index 000000000..276489a86 --- /dev/null +++ b/src/MEDCalc/CMakeLists.txt @@ -0,0 +1,34 @@ +# 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) diff --git a/src/MEDCalc/cmp/CMakeLists.txt b/src/MEDCalc/cmp/CMakeLists.txt new file mode 100644 index 000000000..5e5c8393e --- /dev/null +++ b/src/MEDCalc/cmp/CMakeLists.txt @@ -0,0 +1,79 @@ +# 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() diff --git a/src/MEDCalc/doc/CMakeLists.txt b/src/MEDCalc/doc/CMakeLists.txt new file mode 100644 index 000000000..d91183151 --- /dev/null +++ b/src/MEDCalc/doc/CMakeLists.txt @@ -0,0 +1,20 @@ +# 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) diff --git a/src/MEDCalc/doc/models/medcalc.xmi b/src/MEDCalc/doc/models/medcalc.xmi new file mode 100644 index 000000000..00fbdb5a4 --- /dev/null +++ b/src/MEDCalc/doc/models/medcalc.xmi @@ -0,0 +1,318 @@ + + + + + umbrello uml modeller http://uml.sf.net + 1.5.8 + UnicodeUTF8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/src/MEDCalc/doc/sphinx/CMakeLists.txt b/src/MEDCalc/doc/sphinx/CMakeLists.txt new file mode 100644 index 000000000..af144c98b --- /dev/null +++ b/src/MEDCalc/doc/sphinx/CMakeLists.txt @@ -0,0 +1,31 @@ +# 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}") diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf new file mode 100755 index 000000000..405a2ccd0 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf new file mode 100755 index 000000000..2357da079 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf new file mode 100755 index 000000000..3dbad00ca Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf new file mode 100755 index 000000000..8048e0bad Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf new file mode 100755 index 000000000..f5f91231f Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf new file mode 100644 index 000000000..aee46bf25 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf new file mode 100644 index 000000000..dce10d93a Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf b/src/MEDCalc/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf new file mode 100755 index 000000000..2ea491817 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/xmed-develguide.pdf b/src/MEDCalc/doc/sphinx/_static/documents/xmed-develguide.pdf new file mode 100644 index 000000000..fad08c838 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/xmed-develguide.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/xmed-specifications.pdf b/src/MEDCalc/doc/sphinx/_static/documents/xmed-specifications.pdf new file mode 100644 index 000000000..76968732c Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/xmed-specifications.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/documents/xmed-userguide.pdf b/src/MEDCalc/doc/sphinx/_static/documents/xmed-userguide.pdf new file mode 100644 index 000000000..7fd7eabed Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/documents/xmed-userguide.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/medop.css b/src/MEDCalc/doc/sphinx/_static/medop.css new file mode 100644 index 000000000..468256166 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/_static/medop.css @@ -0,0 +1,159 @@ +@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; +} + diff --git a/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf new file mode 100644 index 000000000..9a129300b Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf differ diff --git a/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv new file mode 100644 index 000000000..8339d6333 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv differ diff --git a/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv new file mode 100644 index 000000000..ec7c90a92 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv differ diff --git a/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv new file mode 100644 index 000000000..7398d19a9 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv differ diff --git a/src/MEDCalc/doc/sphinx/conf.py.in b/src/MEDCalc/doc/sphinx/conf.py.in new file mode 100644 index 000000000..bad7ac849 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/conf.py.in @@ -0,0 +1,228 @@ +# -*- 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 +# " v 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/. +html_copy_source = True + +# If true, an OpenSearch description file will be output, and all pages will +# contain a 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 diff --git a/src/MEDCalc/doc/sphinx/fr/images/xmed-gui-withframe.png b/src/MEDCalc/doc/sphinx/fr/images/xmed-gui-withframe.png new file mode 100644 index 000000000..532c285e6 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/fr/images/xmed-gui-withframe.png differ diff --git a/src/MEDCalc/doc/sphinx/fr/images/xmed-gui.png b/src/MEDCalc/doc/sphinx/fr/images/xmed-gui.png new file mode 100644 index 000000000..0c9168374 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/fr/images/xmed-gui.png differ diff --git a/src/MEDCalc/doc/sphinx/fr/index.rst b/src/MEDCalc/doc/sphinx/fr/index.rst new file mode 100644 index 000000000..8d2939d2e --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/index.rst @@ -0,0 +1,60 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%%% + 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 diff --git a/src/MEDCalc/doc/sphinx/fr/medcalc-definitions.rst b/src/MEDCalc/doc/sphinx/fr/medcalc-definitions.rst new file mode 100644 index 000000000..0cb67b4e5 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medcalc-definitions.rst @@ -0,0 +1,123 @@ +.. 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` + + +.. 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 diff --git a/src/MEDCalc/doc/sphinx/fr/medcalc-develguide.rst b/src/MEDCalc/doc/sphinx/fr/medcalc-develguide.rst new file mode 100644 index 000000000..063a8e84f --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medcalc-develguide.rst @@ -0,0 +1,285 @@ +.. 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 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; iid] = 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= + +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:: + + $ /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 diff --git a/src/MEDCalc/doc/sphinx/fr/medcalc-references.rst b/src/MEDCalc/doc/sphinx/fr/medcalc-references.rst new file mode 100644 index 000000000..2153884c1 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medcalc-references.rst @@ -0,0 +1,28 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +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 diff --git a/src/MEDCalc/doc/sphinx/fr/medcalc-specifications.rst b/src/MEDCalc/doc/sphinx/fr/medcalc-specifications.rst new file mode 100644 index 000000000..ae152232e --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medcalc-specifications.rst @@ -0,0 +1,916 @@ +.. 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`, 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)>> r=fa+fb + +* Effectuer les contrôles visuel et les diagnostics en ligne de + commandes python (cf. :ref:`Spécification des fonctions de + 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. + + diff --git a/src/MEDCalc/doc/sphinx/fr/medcalc-userguide-gui.rst b/src/MEDCalc/doc/sphinx/fr/medcalc-userguide-gui.rst new file mode 100644 index 000000000..a90efde32 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medcalc-userguide-gui.rst @@ -0,0 +1,752 @@ +.. 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`, 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 ```` est créée +automatiquement dans la console de travail pour désigner le +champ. Dans cet exemple, ```` 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`): + + >>> 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`). 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` 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`). + +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()`` (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`:: + + >>> 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é):: + + $ /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:: + + $ /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`` diff --git a/src/MEDCalc/doc/sphinx/fr/medop-prototype-develguide.rst b/src/MEDCalc/doc/sphinx/fr/medop-prototype-develguide.rst new file mode 100644 index 000000000..0bc2eae90 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-prototype-develguide.rst @@ -0,0 +1,731 @@ +.. 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 `. + +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 ``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 + #include + #include + #include + + // 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:: + + $ /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 +``/resources/datafiles`` et dans l'installation au niveau du +répertoire ``/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). diff --git a/src/MEDCalc/doc/sphinx/fr/medop-prototype-medmem.rst b/src/MEDCalc/doc/sphinx/fr/medop-prototype-medmem.rst new file mode 100644 index 000000000..9c29fee19 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-prototype-medmem.rst @@ -0,0 +1,513 @@ +.. 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 *field = (FIELD *)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 * 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 * getFieldDouble(const char * fieldName, const int dt, const int it) + { + return (FIELD *) 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. diff --git a/src/MEDCalc/doc/sphinx/fr/medop-prototype-overview.rst b/src/MEDCalc/doc/sphinx/fr/medop-prototype-overview.rst new file mode 100644 index 000000000..5eaa00e08 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-prototype-overview.rst @@ -0,0 +1,95 @@ +.. 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. diff --git a/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2010.rst b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2010.rst new file mode 100644 index 000000000..724c9a832 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2010.rst @@ -0,0 +1,461 @@ +.. 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. diff --git a/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2011.rst b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2011.rst new file mode 100644 index 000000000..269b63b5a --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2011.rst @@ -0,0 +1,473 @@ +.. 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 + + + diff --git a/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2012.rst b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2012.rst new file mode 100644 index 000000000..4a3e10af4 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/fr/medop-workingnotes-2012.rst @@ -0,0 +1,84 @@ +.. 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 + diff --git a/src/MEDCalc/doc/sphinx/images/champ_altitude_MAP.png b/src/MEDCalc/doc/sphinx/images/champ_altitude_MAP.png new file mode 100644 index 000000000..0fbf2ba0d Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/champ_altitude_MAP.png differ diff --git a/src/MEDCalc/doc/sphinx/images/convert.sh b/src/MEDCalc/doc/sphinx/images/convert.sh new file mode 100755 index 000000000..52e3bfca8 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/images/convert.sh @@ -0,0 +1,35 @@ +#!/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 + + diff --git a/src/MEDCalc/doc/sphinx/images/ico_datasource_add.png b/src/MEDCalc/doc/sphinx/images/ico_datasource_add.png new file mode 100644 index 000000000..bcec3d6c7 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_datasource_add.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png b/src/MEDCalc/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png new file mode 100644 index 000000000..fe6c8b6d3 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_datasource_expandfield.png b/src/MEDCalc/doc/sphinx/images/ico_datasource_expandfield.png new file mode 100644 index 000000000..07c8b0b10 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_datasource_expandfield.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_datasource_use.png b/src/MEDCalc/doc/sphinx/images/ico_datasource_use.png new file mode 100644 index 000000000..0d1ab6326 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_datasource_use.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_datasource_view.png b/src/MEDCalc/doc/sphinx/images/ico_datasource_view.png new file mode 100644 index 000000000..418914405 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_datasource_view.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_imagesource.png b/src/MEDCalc/doc/sphinx/images/ico_imagesource.png new file mode 100644 index 000000000..465b156e4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_imagesource.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_workspace_save.png b/src/MEDCalc/doc/sphinx/images/ico_workspace_save.png new file mode 100644 index 000000000..268c8fb7b Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_workspace_save.png differ diff --git a/src/MEDCalc/doc/sphinx/images/ico_xmed.png b/src/MEDCalc/doc/sphinx/images/ico_xmed.png new file mode 100644 index 000000000..4f09fe03d Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/ico_xmed.png differ diff --git a/src/MEDCalc/doc/sphinx/images/med-uml-main.png b/src/MEDCalc/doc/sphinx/images/med-uml-main.png new file mode 100755 index 000000000..1e7d458cc Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/med-uml-main.png differ diff --git a/src/MEDCalc/doc/sphinx/images/med-uml-main_60pc.png b/src/MEDCalc/doc/sphinx/images/med-uml-main_60pc.png new file mode 100644 index 000000000..f8f06cb55 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/med-uml-main_60pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medlayers.png b/src/MEDCalc/doc/sphinx/images/medlayers.png new file mode 100644 index 000000000..179ae0bcf Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medlayers.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medlayers_70pc.png b/src/MEDCalc/doc/sphinx/images/medlayers_70pc.png new file mode 100644 index 000000000..f31997693 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medlayers_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medmem-corba-layers.png b/src/MEDCalc/doc/sphinx/images/medmem-corba-layers.png new file mode 100755 index 000000000..de355e983 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medmem-corba-layers.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medmem-layers.png b/src/MEDCalc/doc/sphinx/images/medmem-layers.png new file mode 100644 index 000000000..d781003a6 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medmem-layers.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield.png b/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield.png new file mode 100755 index 000000000..ad266f822 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield_scale.png b/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield_scale.png new file mode 100644 index 000000000..33a5caeb9 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-aliasfield_scale.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-result.png b/src/MEDCalc/doc/sphinx/images/medop-gui-result.png new file mode 100755 index 000000000..54a41bfed Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-result.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-result_scale.png b/src/MEDCalc/doc/sphinx/images/medop-gui-result_scale.png new file mode 100644 index 000000000..a53187bd4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-result_scale.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield.png b/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield.png new file mode 100755 index 000000000..47d5d61a4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield_scale.png b/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield_scale.png new file mode 100644 index 000000000..e311926f6 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-selectfield_scale.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-visufield.png b/src/MEDCalc/doc/sphinx/images/medop-gui-visufield.png new file mode 100755 index 000000000..fc4262722 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-visufield.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop-gui-visufield_scale.png b/src/MEDCalc/doc/sphinx/images/medop-gui-visufield_scale.png new file mode 100644 index 000000000..6cbe393c9 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop-gui-visufield_scale.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_exportparavis.png b/src/MEDCalc/doc/sphinx/images/medop_exportparavis.png new file mode 100644 index 000000000..4205c6ba6 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_exportparavis.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_exportparavis_result.png b/src/MEDCalc/doc/sphinx/images/medop_exportparavis_result.png new file mode 100644 index 000000000..56abc6ee3 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_exportparavis_result.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_image2med_dialog.png b/src/MEDCalc/doc/sphinx/images/medop_image2med_dialog.png new file mode 100644 index 000000000..35cf57b39 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_image2med_dialog.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_image2med_tomographie.png b/src/MEDCalc/doc/sphinx/images/medop_image2med_tomographie.png new file mode 100644 index 000000000..9f67fbc0c Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_image2med_tomographie.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_projection_inputs.png b/src/MEDCalc/doc/sphinx/images/medop_projection_inputs.png new file mode 100644 index 000000000..36c046397 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_projection_inputs.png differ diff --git a/src/MEDCalc/doc/sphinx/images/medop_projection_result.png b/src/MEDCalc/doc/sphinx/images/medop_projection_result.png new file mode 100644 index 000000000..69aa248de Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/medop_projection_result.png differ diff --git a/src/MEDCalc/doc/sphinx/images/partition_mesh.png b/src/MEDCalc/doc/sphinx/images/partition_mesh.png new file mode 100644 index 000000000..113395c05 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/partition_mesh.png differ diff --git a/src/MEDCalc/doc/sphinx/images/partition_skin.png b/src/MEDCalc/doc/sphinx/images/partition_skin.png new file mode 100644 index 000000000..bdabdb522 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/partition_skin.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-architecture.png b/src/MEDCalc/doc/sphinx/images/xmed-architecture.png new file mode 100755 index 000000000..143b674f7 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-architecture.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-exploremed.png b/src/MEDCalc/doc/sphinx/images/xmed-exploremed.png new file mode 100644 index 000000000..c9e0283aa Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-exploremed.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-functions.png b/src/MEDCalc/doc/sphinx/images/xmed-functions.png new file mode 100644 index 000000000..b0e67b8ef Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-functions.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png new file mode 100644 index 000000000..c62da6a19 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png new file mode 100644 index 000000000..bccd8c258 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu.png new file mode 100644 index 000000000..a8df311ca Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png new file mode 100644 index 000000000..5492fa1cc Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png new file mode 100644 index 000000000..5db5a11d8 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png new file mode 100644 index 000000000..48ed01162 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png new file mode 100644 index 000000000..b4891fd84 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png new file mode 100644 index 000000000..2de39c77f Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore.png new file mode 100644 index 000000000..8bb9bbd68 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-explore.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png new file mode 100644 index 000000000..85ea5d5cc Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-selectfile.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-selectfile.png new file mode 100644 index 000000000..39da53302 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-selectfile.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png new file mode 100644 index 000000000..f6eca45e0 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png new file mode 100644 index 000000000..505e3d6ad Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png new file mode 100644 index 000000000..f942cd84b Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png new file mode 100644 index 000000000..1f7109f63 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png new file mode 100644 index 000000000..98e1f324c Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result.png new file mode 100644 index 000000000..b0f4243d4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png new file mode 100644 index 000000000..f86b7b021 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png new file mode 100644 index 000000000..6bf6817a5 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png new file mode 100644 index 000000000..e556b1011 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize.png new file mode 100644 index 000000000..94fa549d6 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png new file mode 100644 index 000000000..a96aefc10 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png new file mode 100644 index 000000000..1f0599e77 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-start.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-start.png new file mode 100644 index 000000000..8a0a5931f Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-start.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-withframe.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-withframe.png new file mode 100644 index 000000000..4ec113636 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-withframe.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace-view.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace-view.png new file mode 100644 index 000000000..f501f6cf1 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace-view.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace.png b/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace.png new file mode 100644 index 000000000..081b8333f Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui-workspace.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui.png b/src/MEDCalc/doc/sphinx/images/xmed-gui.png new file mode 100644 index 000000000..0c9168374 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-gui_70pc.png b/src/MEDCalc/doc/sphinx/images/xmed-gui_70pc.png new file mode 100644 index 000000000..6d1845c61 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-gui_70pc.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-implantation.png b/src/MEDCalc/doc/sphinx/images/xmed-implantation.png new file mode 100644 index 000000000..0f17dcce4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-implantation.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-irm-diff.png b/src/MEDCalc/doc/sphinx/images/xmed-irm-diff.png new file mode 100644 index 000000000..44d557884 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-irm-diff.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-irm-field.png b/src/MEDCalc/doc/sphinx/images/xmed-irm-field.png new file mode 100644 index 000000000..1012ab1ea Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-irm-field.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-irm.png b/src/MEDCalc/doc/sphinx/images/xmed-irm.png new file mode 100644 index 000000000..5d20c7ed1 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-irm.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-datasource.png b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-datasource.png new file mode 100644 index 000000000..4e67ab118 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-datasource.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace-save.png b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace-save.png new file mode 100644 index 000000000..9d10513c9 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace-save.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace.png b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace.png new file mode 100644 index 000000000..3138f7a08 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-userguide-example2-workspace.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-visu-importtimestamps.png b/src/MEDCalc/doc/sphinx/images/xmed-visu-importtimestamps.png new file mode 100644 index 000000000..b685eccbd Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-visu-importtimestamps.png differ diff --git a/src/MEDCalc/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png b/src/MEDCalc/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png new file mode 100644 index 000000000..1cda69ba4 Binary files /dev/null and b/src/MEDCalc/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png differ diff --git a/src/MEDCalc/doc/sphinx/index.rst b/src/MEDCalc/doc/sphinx/index.rst new file mode 100644 index 000000000..6560ec984 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/index.rst @@ -0,0 +1,58 @@ + +%%%%%%%%%%%%%%%%%%%%%%%%%%% +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 diff --git a/src/MEDCalc/doc/sphinx/medcalc-definitions.rst b/src/MEDCalc/doc/sphinx/medcalc-definitions.rst new file mode 100644 index 000000000..3b4e37164 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-definitions.rst @@ -0,0 +1,123 @@ +.. 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` + + +.. 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 diff --git a/src/MEDCalc/doc/sphinx/medcalc-develguide.rst b/src/MEDCalc/doc/sphinx/medcalc-develguide.rst new file mode 100644 index 000000000..063a8e84f --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-develguide.rst @@ -0,0 +1,285 @@ +.. 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 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; iid] = 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= + +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:: + + $ /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 diff --git a/src/MEDCalc/doc/sphinx/medcalc-references.rst b/src/MEDCalc/doc/sphinx/medcalc-references.rst new file mode 100644 index 000000000..43cb54564 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-references.rst @@ -0,0 +1,28 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +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 diff --git a/src/MEDCalc/doc/sphinx/medcalc-specifications.rst b/src/MEDCalc/doc/sphinx/medcalc-specifications.rst new file mode 100644 index 000000000..ae152232e --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-specifications.rst @@ -0,0 +1,916 @@ +.. 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`, 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)>> r=fa+fb + +* Effectuer les contrôles visuel et les diagnostics en ligne de + commandes python (cf. :ref:`Spécification des fonctions de + 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. + + diff --git a/src/MEDCalc/doc/sphinx/medcalc-userguide-api.rst b/src/MEDCalc/doc/sphinx/medcalc-userguide-api.rst new file mode 100644 index 000000000..161e0551f --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-userguide-api.rst @@ -0,0 +1,528 @@ +.. 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= + 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= + export PATH=${HDF5HOME}/bin:$PATH + export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH} + export HDF5_DISABLE_VERSION_CHECK=1 + + #------ med ------ + MED2HOME= + export PATH=${MED2HOME}/bin:${PATH} + export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH} + + #------ medmem --- + MED_ROOT_DIR= + 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 +.. ---------------------------------------- + diff --git a/src/MEDCalc/doc/sphinx/medcalc-userguide-gui.rst b/src/MEDCalc/doc/sphinx/medcalc-userguide-gui.rst new file mode 100644 index 000000000..7a5de95c8 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medcalc-userguide-gui.rst @@ -0,0 +1,653 @@ +.. 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` (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 +```` is automatically created in the TUI to designate the field. In +this example, ```` 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`): + + >>> 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`). 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` 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`). + +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()`` (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`:: + + >>> 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):: + + $ /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:: + + $ /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 diff --git a/src/MEDCalc/doc/sphinx/medop-prototype-develguide.rst b/src/MEDCalc/doc/sphinx/medop-prototype-develguide.rst new file mode 100644 index 000000000..0bc2eae90 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-prototype-develguide.rst @@ -0,0 +1,731 @@ +.. 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 `. + +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 ``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 + #include + #include + #include + + // 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:: + + $ /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 +``/resources/datafiles`` et dans l'installation au niveau du +répertoire ``/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). diff --git a/src/MEDCalc/doc/sphinx/medop-prototype-medmem.rst b/src/MEDCalc/doc/sphinx/medop-prototype-medmem.rst new file mode 100644 index 000000000..9c29fee19 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-prototype-medmem.rst @@ -0,0 +1,513 @@ +.. 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 *field = (FIELD *)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 * 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 * getFieldDouble(const char * fieldName, const int dt, const int it) + { + return (FIELD *) 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. diff --git a/src/MEDCalc/doc/sphinx/medop-prototype-overview.rst b/src/MEDCalc/doc/sphinx/medop-prototype-overview.rst new file mode 100644 index 000000000..5eaa00e08 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-prototype-overview.rst @@ -0,0 +1,95 @@ +.. 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. diff --git a/src/MEDCalc/doc/sphinx/medop-workingnotes-2010.rst b/src/MEDCalc/doc/sphinx/medop-workingnotes-2010.rst new file mode 100644 index 000000000..724c9a832 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-workingnotes-2010.rst @@ -0,0 +1,461 @@ +.. 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. diff --git a/src/MEDCalc/doc/sphinx/medop-workingnotes-2011.rst b/src/MEDCalc/doc/sphinx/medop-workingnotes-2011.rst new file mode 100644 index 000000000..269b63b5a --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-workingnotes-2011.rst @@ -0,0 +1,473 @@ +.. 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 + + + diff --git a/src/MEDCalc/doc/sphinx/medop-workingnotes-2012.rst b/src/MEDCalc/doc/sphinx/medop-workingnotes-2012.rst new file mode 100644 index 000000000..4a3e10af4 --- /dev/null +++ b/src/MEDCalc/doc/sphinx/medop-workingnotes-2012.rst @@ -0,0 +1,84 @@ +.. 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 + diff --git a/src/MEDCalc/exe/CMakeLists.txt b/src/MEDCalc/exe/CMakeLists.txt new file mode 100644 index 000000000..d44f219c6 --- /dev/null +++ b/src/MEDCalc/exe/CMakeLists.txt @@ -0,0 +1,20 @@ +# 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) diff --git a/src/MEDCalc/exe/image2med/CMakeLists.txt b/src/MEDCalc/exe/image2med/CMakeLists.txt new file mode 100644 index 000000000..7629f5802 --- /dev/null +++ b/src/MEDCalc/exe/image2med/CMakeLists.txt @@ -0,0 +1,24 @@ +# 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) diff --git a/src/MEDCalc/gui/CMakeLists.txt b/src/MEDCalc/gui/CMakeLists.txt new file mode 100644 index 000000000..953911727 --- /dev/null +++ b/src/MEDCalc/gui/CMakeLists.txt @@ -0,0 +1,101 @@ +# 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}) diff --git a/src/MEDCalc/gui/dialogs/CMakeLists.txt b/src/MEDCalc/gui/dialogs/CMakeLists.txt new file mode 100644 index 000000000..f3aa8cbfc --- /dev/null +++ b/src/MEDCalc/gui/dialogs/CMakeLists.txt @@ -0,0 +1,81 @@ +# 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}) diff --git a/src/MEDCalc/res/CMakeLists.txt b/src/MEDCalc/res/CMakeLists.txt new file mode 100644 index 000000000..87f6ab69f --- /dev/null +++ b/src/MEDCalc/res/CMakeLists.txt @@ -0,0 +1,40 @@ +# 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}) diff --git a/src/MEDCalc/res/testfiles/CMakeLists.txt b/src/MEDCalc/res/testfiles/CMakeLists.txt new file mode 100644 index 000000000..4bdb0232b --- /dev/null +++ b/src/MEDCalc/res/testfiles/CMakeLists.txt @@ -0,0 +1,45 @@ +# 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) diff --git a/src/MEDCalc/tui/CMakeLists.txt b/src/MEDCalc/tui/CMakeLists.txt new file mode 100644 index 000000000..8e0d77052 --- /dev/null +++ b/src/MEDCalc/tui/CMakeLists.txt @@ -0,0 +1,31 @@ +# 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) diff --git a/src/MEDCalc/tut/medcoupling/README.txt b/src/MEDCalc/tut/medcoupling/README.txt new file mode 100644 index 000000000..9448c9ba4 --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/README.txt @@ -0,0 +1,2 @@ +Note that this test scripts required the PIL python library + diff --git a/src/MEDCalc/tut/medcoupling/env.sh b/src/MEDCalc/tut/medcoupling/env.sh new file mode 100644 index 000000000..b520cf294 --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/env.sh @@ -0,0 +1,55 @@ +# 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} diff --git a/src/MEDCalc/tut/medcoupling/images/avatar.png b/src/MEDCalc/tut/medcoupling/images/avatar.png new file mode 100644 index 000000000..ae252ccf9 Binary files /dev/null and b/src/MEDCalc/tut/medcoupling/images/avatar.png differ diff --git a/src/MEDCalc/tut/medcoupling/images/irm.png b/src/MEDCalc/tut/medcoupling/images/irm.png new file mode 100644 index 000000000..5d20c7ed1 Binary files /dev/null and b/src/MEDCalc/tut/medcoupling/images/irm.png differ diff --git a/src/MEDCalc/tut/medcoupling/images/lena.png b/src/MEDCalc/tut/medcoupling/images/lena.png new file mode 100644 index 000000000..16f9c840e Binary files /dev/null and b/src/MEDCalc/tut/medcoupling/images/lena.png differ diff --git a/src/MEDCalc/tut/medcoupling/images/tests.pgm b/src/MEDCalc/tut/medcoupling/images/tests.pgm new file mode 100644 index 000000000..63b8ce88a --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/images/tests.pgm @@ -0,0 +1,5 @@ +P5 +# CREATOR: GIMP PNM Filter Version 1.1 +6 6 +255 +¿¿ÿÿ¿¿¿¿ÿÿ¿¿ÿÿÿÿÿÿÿÿ¿¿ÿÿ¿¿¿¿ÿÿ¿¿ \ No newline at end of file diff --git a/src/MEDCalc/tut/medcoupling/partition.py b/src/MEDCalc/tut/medcoupling/partition.py new file mode 100644 index 000000000..5b6152e2f --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/partition.py @@ -0,0 +1,79 @@ +# -*- 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) diff --git a/src/MEDCalc/tut/medcoupling/pyfunctions/__init__.py b/src/MEDCalc/tut/medcoupling/pyfunctions/__init__.py new file mode 100644 index 000000000..e69de29bb diff --git a/src/MEDCalc/tut/medcoupling/pyfunctions/functions.py b/src/MEDCalc/tut/medcoupling/pyfunctions/functions.py new file mode 100755 index 000000000..0b0eb3080 --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/pyfunctions/functions.py @@ -0,0 +1,269 @@ +#!/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 xxsup: + 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() diff --git a/src/MEDCalc/tut/medcoupling/pyfunctions/lagrange.py b/src/MEDCalc/tut/medcoupling/pyfunctions/lagrange.py new file mode 100755 index 000000000..319902e12 --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/pyfunctions/lagrange.py @@ -0,0 +1,150 @@ +#!/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>> +# 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() diff --git a/src/MEDCalc/tut/medcoupling/testmed_lena.py b/src/MEDCalc/tut/medcoupling/testmed_lena.py new file mode 100755 index 000000000..114719ccc --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/testmed_lena.py @@ -0,0 +1,136 @@ +#!/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) diff --git a/src/MEDCalc/tut/medcoupling/testmed_simple.py b/src/MEDCalc/tut/medcoupling/testmed_simple.py new file mode 100755 index 000000000..36c2d813e --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/testmed_simple.py @@ -0,0 +1,164 @@ +#!/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) + + diff --git a/src/MEDCalc/tut/medcoupling/testpil.py b/src/MEDCalc/tut/medcoupling/testpil.py new file mode 100755 index 000000000..109f518ac --- /dev/null +++ b/src/MEDCalc/tut/medcoupling/testpil.py @@ -0,0 +1,149 @@ +#!/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() diff --git a/src/MEDCalc/tut/medloader/Makefile b/src/MEDCalc/tut/medloader/Makefile new file mode 100644 index 000000000..a03ea153c --- /dev/null +++ b/src/MEDCalc/tut/medloader/Makefile @@ -0,0 +1,9 @@ +all: + python tutorial.py + python explore.py + python manage.py + python testamel.py + python cmesh + +clean: + rm -f *~ *.pyc output.med diff --git a/src/MEDCalc/tut/medloader/cmesh.py b/src/MEDCalc/tut/medloader/cmesh.py new file mode 100644 index 000000000..6054c84ab --- /dev/null +++ b/src/MEDCalc/tut/medloader/cmesh.py @@ -0,0 +1,71 @@ +#!/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. diff --git a/src/MEDCalc/tut/medloader/explore.py b/src/MEDCalc/tut/medloader/explore.py new file mode 100644 index 000000000..5522d3737 --- /dev/null +++ b/src/MEDCalc/tut/medloader/explore.py @@ -0,0 +1,98 @@ +#!/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 diff --git a/src/MEDCalc/tut/medloader/madnex_field.med b/src/MEDCalc/tut/medloader/madnex_field.med new file mode 100644 index 000000000..05acf1a21 Binary files /dev/null and b/src/MEDCalc/tut/medloader/madnex_field.med differ diff --git a/src/MEDCalc/tut/medloader/madnex_grid.med b/src/MEDCalc/tut/medloader/madnex_grid.med new file mode 100644 index 000000000..b6b004dc6 Binary files /dev/null and b/src/MEDCalc/tut/medloader/madnex_grid.med differ diff --git a/src/MEDCalc/tut/medloader/manage.py b/src/MEDCalc/tut/medloader/manage.py new file mode 100644 index 000000000..4c6c44909 --- /dev/null +++ b/src/MEDCalc/tut/medloader/manage.py @@ -0,0 +1,94 @@ +#!/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 diff --git a/src/MEDCalc/tut/medloader/testamel.py b/src/MEDCalc/tut/medloader/testamel.py new file mode 100644 index 000000000..819aca01a --- /dev/null +++ b/src/MEDCalc/tut/medloader/testamel.py @@ -0,0 +1,68 @@ +# -*- 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 diff --git a/src/MEDCalc/tut/medloader/timeseries.med b/src/MEDCalc/tut/medloader/timeseries.med new file mode 100644 index 000000000..3226304db Binary files /dev/null and b/src/MEDCalc/tut/medloader/timeseries.med differ diff --git a/src/MEDCalc/tut/medloader/tutorial.py b/src/MEDCalc/tut/medloader/tutorial.py new file mode 100644 index 000000000..ab94b7915 --- /dev/null +++ b/src/MEDCalc/tut/medloader/tutorial.py @@ -0,0 +1,59 @@ +#!/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 diff --git a/src/MEDOP/CMakeLists.txt b/src/MEDOP/CMakeLists.txt deleted file mode 100644 index 276489a86..000000000 --- a/src/MEDOP/CMakeLists.txt +++ /dev/null @@ -1,34 +0,0 @@ -# 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) diff --git a/src/MEDOP/cmp/CMakeLists.txt b/src/MEDOP/cmp/CMakeLists.txt deleted file mode 100644 index 8c74dbc76..000000000 --- a/src/MEDOP/cmp/CMakeLists.txt +++ /dev/null @@ -1,79 +0,0 @@ -# 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() diff --git a/src/MEDOP/doc/CMakeLists.txt b/src/MEDOP/doc/CMakeLists.txt deleted file mode 100644 index d91183151..000000000 --- a/src/MEDOP/doc/CMakeLists.txt +++ /dev/null @@ -1,20 +0,0 @@ -# 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) diff --git a/src/MEDOP/doc/models/medop.xmi b/src/MEDOP/doc/models/medop.xmi deleted file mode 100644 index 9422c56f0..000000000 --- a/src/MEDOP/doc/models/medop.xmi +++ /dev/null @@ -1,318 +0,0 @@ - - - - - umbrello uml modeller http://uml.sf.net - 1.5.8 - UnicodeUTF8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/src/MEDOP/doc/sphinx/CMakeLists.txt b/src/MEDOP/doc/sphinx/CMakeLists.txt deleted file mode 100644 index 411eaefdf..000000000 --- a/src/MEDOP/doc/sphinx/CMakeLists.txt +++ /dev/null @@ -1,31 +0,0 @@ -# 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}") diff --git a/src/MEDOP/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf b/src/MEDOP/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf deleted file mode 100755 index 405a2ccd0..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf b/src/MEDOP/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf deleted file mode 100755 index 2357da079..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20091211_CEA_AGEAY_09-017-RT-A_Normalisation_des_champs_et_des_maillages_pour_le_couplage_de_codes.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf b/src/MEDOP/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf deleted file mode 100755 index 3dbad00ca..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf b/src/MEDOP/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf deleted file mode 100755 index 8048e0bad..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf b/src/MEDOP/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf deleted file mode 100755 index f5f91231f..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20101027_MAN_revueEDF-CEA.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf b/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf deleted file mode 100644 index aee46bf25..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_notes.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf b/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf deleted file mode 100644 index dce10d93a..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf b/src/MEDOP/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf deleted file mode 100755 index 2ea491817..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/xmed-develguide.pdf b/src/MEDOP/doc/sphinx/_static/documents/xmed-develguide.pdf deleted file mode 100644 index fad08c838..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/xmed-develguide.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/xmed-specifications.pdf b/src/MEDOP/doc/sphinx/_static/documents/xmed-specifications.pdf deleted file mode 100644 index 76968732c..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/xmed-specifications.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/documents/xmed-userguide.pdf b/src/MEDOP/doc/sphinx/_static/documents/xmed-userguide.pdf deleted file mode 100644 index 7fd7eabed..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/documents/xmed-userguide.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/medop.css b/src/MEDOP/doc/sphinx/_static/medop.css deleted file mode 100644 index 468256166..000000000 --- a/src/MEDOP/doc/sphinx/_static/medop.css +++ /dev/null @@ -1,159 +0,0 @@ -@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; -} - diff --git a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf b/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf deleted file mode 100644 index 9a129300b..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv b/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv deleted file mode 100644 index 8339d6333..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv b/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv deleted file mode 100644 index ec7c90a92..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv b/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv deleted file mode 100644 index 7398d19a9..000000000 Binary files a/src/MEDOP/doc/sphinx/_static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/conf.py.in b/src/MEDOP/doc/sphinx/conf.py.in deleted file mode 100644 index 9292409b4..000000000 --- a/src/MEDOP/doc/sphinx/conf.py.in +++ /dev/null @@ -1,228 +0,0 @@ -# -*- 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 -# " v 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/. -html_copy_source = True - -# If true, an OpenSearch description file will be output, and all pages will -# contain a 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 diff --git a/src/MEDOP/doc/sphinx/fr/images/xmed-gui-withframe.png b/src/MEDOP/doc/sphinx/fr/images/xmed-gui-withframe.png deleted file mode 100644 index 532c285e6..000000000 Binary files a/src/MEDOP/doc/sphinx/fr/images/xmed-gui-withframe.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/fr/images/xmed-gui.png b/src/MEDOP/doc/sphinx/fr/images/xmed-gui.png deleted file mode 100644 index 0c9168374..000000000 Binary files a/src/MEDOP/doc/sphinx/fr/images/xmed-gui.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/fr/index.rst b/src/MEDOP/doc/sphinx/fr/index.rst deleted file mode 100644 index cf3fa4b1e..000000000 --- a/src/MEDOP/doc/sphinx/fr/index.rst +++ /dev/null @@ -1,60 +0,0 @@ - -%%%%%%%%%%%%%%%%%%%%%%%%%%%% - 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 diff --git a/src/MEDOP/doc/sphinx/fr/medop-definitions.rst b/src/MEDOP/doc/sphinx/fr/medop-definitions.rst deleted file mode 100644 index 0cb67b4e5..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-definitions.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. 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` - - -.. 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 diff --git a/src/MEDOP/doc/sphinx/fr/medop-develguide.rst b/src/MEDOP/doc/sphinx/fr/medop-develguide.rst deleted file mode 100644 index 444a0a9a6..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-develguide.rst +++ /dev/null @@ -1,285 +0,0 @@ -.. 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 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; iid] = 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= - -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:: - - $ /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 diff --git a/src/MEDOP/doc/sphinx/fr/medop-prototype-develguide.rst b/src/MEDOP/doc/sphinx/fr/medop-prototype-develguide.rst deleted file mode 100644 index de2387b74..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-prototype-develguide.rst +++ /dev/null @@ -1,731 +0,0 @@ -.. 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 `. - -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 ``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 - #include - #include - #include - - // 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:: - - $ /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 -``/resources/datafiles`` et dans l'installation au niveau du -répertoire ``/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). diff --git a/src/MEDOP/doc/sphinx/fr/medop-prototype-medmem.rst b/src/MEDOP/doc/sphinx/fr/medop-prototype-medmem.rst deleted file mode 100644 index 2302f7b70..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-prototype-medmem.rst +++ /dev/null @@ -1,513 +0,0 @@ -.. 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 *field = (FIELD *)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 * 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 * getFieldDouble(const char * fieldName, const int dt, const int it) - { - return (FIELD *) 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. diff --git a/src/MEDOP/doc/sphinx/fr/medop-prototype-overview.rst b/src/MEDOP/doc/sphinx/fr/medop-prototype-overview.rst deleted file mode 100644 index c571c6e6f..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-prototype-overview.rst +++ /dev/null @@ -1,95 +0,0 @@ -.. 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. diff --git a/src/MEDOP/doc/sphinx/fr/medop-references.rst b/src/MEDOP/doc/sphinx/fr/medop-references.rst deleted file mode 100644 index 9be8cdc5f..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-references.rst +++ /dev/null @@ -1,28 +0,0 @@ -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -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 diff --git a/src/MEDOP/doc/sphinx/fr/medop-specifications.rst b/src/MEDOP/doc/sphinx/fr/medop-specifications.rst deleted file mode 100644 index 09ca88cd2..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-specifications.rst +++ /dev/null @@ -1,916 +0,0 @@ -.. 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`, 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)>> r=fa+fb - -* Effectuer les contrôles visuel et les diagnostics en ligne de - commandes python (cf. :ref:`Spécification des fonctions de - 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. - - diff --git a/src/MEDOP/doc/sphinx/fr/medop-userguide-gui.rst b/src/MEDOP/doc/sphinx/fr/medop-userguide-gui.rst deleted file mode 100644 index f09404a64..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-userguide-gui.rst +++ /dev/null @@ -1,748 +0,0 @@ -.. 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`, 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 ```` est créée -automatiquement dans la console de travail pour désigner le -champ. Dans cet exemple, ```` 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`): - - >>> 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`). 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` 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`). - -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()`` (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`:: - - >>> 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é):: - - $ /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:: - - $ /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) - - diff --git a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2010.rst b/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2010.rst deleted file mode 100644 index 724c9a832..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2010.rst +++ /dev/null @@ -1,461 +0,0 @@ -.. 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. diff --git a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2011.rst b/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2011.rst deleted file mode 100644 index 2c38e64bb..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2011.rst +++ /dev/null @@ -1,473 +0,0 @@ -.. 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 - - - diff --git a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2012.rst b/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2012.rst deleted file mode 100644 index b6ecb6d37..000000000 --- a/src/MEDOP/doc/sphinx/fr/medop-workingnotes-2012.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. 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 - diff --git a/src/MEDOP/doc/sphinx/images/champ_altitude_MAP.png b/src/MEDOP/doc/sphinx/images/champ_altitude_MAP.png deleted file mode 100644 index 0fbf2ba0d..000000000 Binary files a/src/MEDOP/doc/sphinx/images/champ_altitude_MAP.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/convert.sh b/src/MEDOP/doc/sphinx/images/convert.sh deleted file mode 100755 index 52e3bfca8..000000000 --- a/src/MEDOP/doc/sphinx/images/convert.sh +++ /dev/null @@ -1,35 +0,0 @@ -#!/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 - - diff --git a/src/MEDOP/doc/sphinx/images/ico_datasource_add.png b/src/MEDOP/doc/sphinx/images/ico_datasource_add.png deleted file mode 100644 index bcec3d6c7..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_datasource_add.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png b/src/MEDOP/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png deleted file mode 100644 index fe6c8b6d3..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_datasource_changeUnderlyingMesh.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_datasource_expandfield.png b/src/MEDOP/doc/sphinx/images/ico_datasource_expandfield.png deleted file mode 100644 index 07c8b0b10..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_datasource_expandfield.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_datasource_use.png b/src/MEDOP/doc/sphinx/images/ico_datasource_use.png deleted file mode 100644 index 0d1ab6326..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_datasource_use.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_datasource_view.png b/src/MEDOP/doc/sphinx/images/ico_datasource_view.png deleted file mode 100644 index 418914405..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_datasource_view.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_imagesource.png b/src/MEDOP/doc/sphinx/images/ico_imagesource.png deleted file mode 100644 index 465b156e4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_imagesource.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_workspace_save.png b/src/MEDOP/doc/sphinx/images/ico_workspace_save.png deleted file mode 100644 index 268c8fb7b..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_workspace_save.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/ico_xmed.png b/src/MEDOP/doc/sphinx/images/ico_xmed.png deleted file mode 100644 index 4f09fe03d..000000000 Binary files a/src/MEDOP/doc/sphinx/images/ico_xmed.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/med-uml-main.png b/src/MEDOP/doc/sphinx/images/med-uml-main.png deleted file mode 100755 index 1e7d458cc..000000000 Binary files a/src/MEDOP/doc/sphinx/images/med-uml-main.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/med-uml-main_60pc.png b/src/MEDOP/doc/sphinx/images/med-uml-main_60pc.png deleted file mode 100644 index f8f06cb55..000000000 Binary files a/src/MEDOP/doc/sphinx/images/med-uml-main_60pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medlayers.png b/src/MEDOP/doc/sphinx/images/medlayers.png deleted file mode 100644 index 179ae0bcf..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medlayers.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medlayers_70pc.png b/src/MEDOP/doc/sphinx/images/medlayers_70pc.png deleted file mode 100644 index f31997693..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medlayers_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medmem-corba-layers.png b/src/MEDOP/doc/sphinx/images/medmem-corba-layers.png deleted file mode 100755 index de355e983..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medmem-corba-layers.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medmem-layers.png b/src/MEDOP/doc/sphinx/images/medmem-layers.png deleted file mode 100644 index d781003a6..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medmem-layers.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield.png b/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield.png deleted file mode 100755 index ad266f822..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield_scale.png b/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield_scale.png deleted file mode 100644 index 33a5caeb9..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-aliasfield_scale.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-result.png b/src/MEDOP/doc/sphinx/images/medop-gui-result.png deleted file mode 100755 index 54a41bfed..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-result.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-result_scale.png b/src/MEDOP/doc/sphinx/images/medop-gui-result_scale.png deleted file mode 100644 index a53187bd4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-result_scale.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-selectfield.png b/src/MEDOP/doc/sphinx/images/medop-gui-selectfield.png deleted file mode 100755 index 47d5d61a4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-selectfield.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-selectfield_scale.png b/src/MEDOP/doc/sphinx/images/medop-gui-selectfield_scale.png deleted file mode 100644 index e311926f6..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-selectfield_scale.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-visufield.png b/src/MEDOP/doc/sphinx/images/medop-gui-visufield.png deleted file mode 100755 index fc4262722..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-visufield.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop-gui-visufield_scale.png b/src/MEDOP/doc/sphinx/images/medop-gui-visufield_scale.png deleted file mode 100644 index 6cbe393c9..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop-gui-visufield_scale.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_exportparavis.png b/src/MEDOP/doc/sphinx/images/medop_exportparavis.png deleted file mode 100644 index 4205c6ba6..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_exportparavis.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_exportparavis_result.png b/src/MEDOP/doc/sphinx/images/medop_exportparavis_result.png deleted file mode 100644 index 56abc6ee3..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_exportparavis_result.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_image2med_dialog.png b/src/MEDOP/doc/sphinx/images/medop_image2med_dialog.png deleted file mode 100644 index 35cf57b39..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_image2med_dialog.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_image2med_tomographie.png b/src/MEDOP/doc/sphinx/images/medop_image2med_tomographie.png deleted file mode 100644 index 9f67fbc0c..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_image2med_tomographie.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_projection_inputs.png b/src/MEDOP/doc/sphinx/images/medop_projection_inputs.png deleted file mode 100644 index 36c046397..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_projection_inputs.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/medop_projection_result.png b/src/MEDOP/doc/sphinx/images/medop_projection_result.png deleted file mode 100644 index 69aa248de..000000000 Binary files a/src/MEDOP/doc/sphinx/images/medop_projection_result.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/partition_mesh.png b/src/MEDOP/doc/sphinx/images/partition_mesh.png deleted file mode 100644 index 113395c05..000000000 Binary files a/src/MEDOP/doc/sphinx/images/partition_mesh.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/partition_skin.png b/src/MEDOP/doc/sphinx/images/partition_skin.png deleted file mode 100644 index bdabdb522..000000000 Binary files a/src/MEDOP/doc/sphinx/images/partition_skin.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-architecture.png b/src/MEDOP/doc/sphinx/images/xmed-architecture.png deleted file mode 100755 index 143b674f7..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-architecture.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-exploremed.png b/src/MEDOP/doc/sphinx/images/xmed-exploremed.png deleted file mode 100644 index c9e0283aa..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-exploremed.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-functions.png b/src/MEDOP/doc/sphinx/images/xmed-functions.png deleted file mode 100644 index b0e67b8ef..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-functions.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png deleted file mode 100644 index c62da6a19..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png deleted file mode 100644 index bccd8c258..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu.png deleted file mode 100644 index a8df311ca..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png deleted file mode 100644 index 5492fa1cc..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_60pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png deleted file mode 100644 index 5db5a11d8..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png deleted file mode 100644 index 48ed01162..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-contextmenu_80pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png deleted file mode 100644 index b4891fd84..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-expand-zoom.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png deleted file mode 100644 index 2de39c77f..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore-zoom.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore.png deleted file mode 100644 index 8bb9bbd68..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-explore.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png deleted file mode 100644 index 85ea5d5cc..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-menucontextuel-zoom.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-selectfile.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-selectfile.png deleted file mode 100644 index 39da53302..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-selectfile.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png deleted file mode 100644 index f6eca45e0..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-alias.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png deleted file mode 100644 index 505e3d6ad..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png deleted file mode 100644 index f942cd84b..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace-result_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png deleted file mode 100644 index 1f7109f63..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png deleted file mode 100644 index 98e1f324c..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-useinworkspace_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result.png deleted file mode 100644 index b0f4243d4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png deleted file mode 100644 index f86b7b021..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_50pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png deleted file mode 100644 index 6bf6817a5..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-result_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png deleted file mode 100644 index e556b1011..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize-zoom.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize.png deleted file mode 100644 index 94fa549d6..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png deleted file mode 100644 index a96aefc10..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_50pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png deleted file mode 100644 index 1f0599e77..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-datasource-visualize_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-start.png b/src/MEDOP/doc/sphinx/images/xmed-gui-start.png deleted file mode 100644 index 8a0a5931f..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-start.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-withframe.png b/src/MEDOP/doc/sphinx/images/xmed-gui-withframe.png deleted file mode 100644 index 4ec113636..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-withframe.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-workspace-view.png b/src/MEDOP/doc/sphinx/images/xmed-gui-workspace-view.png deleted file mode 100644 index f501f6cf1..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-workspace-view.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui-workspace.png b/src/MEDOP/doc/sphinx/images/xmed-gui-workspace.png deleted file mode 100644 index 081b8333f..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui-workspace.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui.png b/src/MEDOP/doc/sphinx/images/xmed-gui.png deleted file mode 100644 index 0c9168374..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-gui_70pc.png b/src/MEDOP/doc/sphinx/images/xmed-gui_70pc.png deleted file mode 100644 index 6d1845c61..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-gui_70pc.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-implantation.png b/src/MEDOP/doc/sphinx/images/xmed-implantation.png deleted file mode 100644 index 0f17dcce4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-implantation.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-irm-diff.png b/src/MEDOP/doc/sphinx/images/xmed-irm-diff.png deleted file mode 100644 index 44d557884..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-irm-diff.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-irm-field.png b/src/MEDOP/doc/sphinx/images/xmed-irm-field.png deleted file mode 100644 index 1012ab1ea..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-irm-field.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-irm.png b/src/MEDOP/doc/sphinx/images/xmed-irm.png deleted file mode 100644 index 5d20c7ed1..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-irm.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-datasource.png b/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-datasource.png deleted file mode 100644 index 4e67ab118..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-datasource.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace-save.png b/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace-save.png deleted file mode 100644 index 9d10513c9..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace-save.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace.png b/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace.png deleted file mode 100644 index 3138f7a08..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-userguide-example2-workspace.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-visu-importtimestamps.png b/src/MEDOP/doc/sphinx/images/xmed-visu-importtimestamps.png deleted file mode 100644 index b685eccbd..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-visu-importtimestamps.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png b/src/MEDOP/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png deleted file mode 100644 index 1cda69ba4..000000000 Binary files a/src/MEDOP/doc/sphinx/images/xmed-visu-scalarmaptimestamps.png and /dev/null differ diff --git a/src/MEDOP/doc/sphinx/index.rst b/src/MEDOP/doc/sphinx/index.rst deleted file mode 100644 index e291c971c..000000000 --- a/src/MEDOP/doc/sphinx/index.rst +++ /dev/null @@ -1,58 +0,0 @@ - -%%%%%%%%%%%%%%%%%%%%%%%%%%% -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 diff --git a/src/MEDOP/doc/sphinx/medop-definitions.rst b/src/MEDOP/doc/sphinx/medop-definitions.rst deleted file mode 100644 index 3b4e37164..000000000 --- a/src/MEDOP/doc/sphinx/medop-definitions.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. 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` - - -.. 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 diff --git a/src/MEDOP/doc/sphinx/medop-develguide.rst b/src/MEDOP/doc/sphinx/medop-develguide.rst deleted file mode 100644 index 444a0a9a6..000000000 --- a/src/MEDOP/doc/sphinx/medop-develguide.rst +++ /dev/null @@ -1,285 +0,0 @@ -.. 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 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; iid] = 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= - -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:: - - $ /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 diff --git a/src/MEDOP/doc/sphinx/medop-prototype-develguide.rst b/src/MEDOP/doc/sphinx/medop-prototype-develguide.rst deleted file mode 100644 index de2387b74..000000000 --- a/src/MEDOP/doc/sphinx/medop-prototype-develguide.rst +++ /dev/null @@ -1,731 +0,0 @@ -.. 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 `. - -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 ``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 - #include - #include - #include - - // 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:: - - $ /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 -``/resources/datafiles`` et dans l'installation au niveau du -répertoire ``/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). diff --git a/src/MEDOP/doc/sphinx/medop-prototype-medmem.rst b/src/MEDOP/doc/sphinx/medop-prototype-medmem.rst deleted file mode 100644 index 2302f7b70..000000000 --- a/src/MEDOP/doc/sphinx/medop-prototype-medmem.rst +++ /dev/null @@ -1,513 +0,0 @@ -.. 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 *field = (FIELD *)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 * 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 * getFieldDouble(const char * fieldName, const int dt, const int it) - { - return (FIELD *) 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. diff --git a/src/MEDOP/doc/sphinx/medop-prototype-overview.rst b/src/MEDOP/doc/sphinx/medop-prototype-overview.rst deleted file mode 100644 index c571c6e6f..000000000 --- a/src/MEDOP/doc/sphinx/medop-prototype-overview.rst +++ /dev/null @@ -1,95 +0,0 @@ -.. 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. diff --git a/src/MEDOP/doc/sphinx/medop-references.rst b/src/MEDOP/doc/sphinx/medop-references.rst deleted file mode 100644 index 0cc327834..000000000 --- a/src/MEDOP/doc/sphinx/medop-references.rst +++ /dev/null @@ -1,28 +0,0 @@ -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -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 diff --git a/src/MEDOP/doc/sphinx/medop-specifications.rst b/src/MEDOP/doc/sphinx/medop-specifications.rst deleted file mode 100644 index 09ca88cd2..000000000 --- a/src/MEDOP/doc/sphinx/medop-specifications.rst +++ /dev/null @@ -1,916 +0,0 @@ -.. 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`, 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)>> r=fa+fb - -* Effectuer les contrôles visuel et les diagnostics en ligne de - commandes python (cf. :ref:`Spécification des fonctions de - 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. - - diff --git a/src/MEDOP/doc/sphinx/medop-userguide-api.rst b/src/MEDOP/doc/sphinx/medop-userguide-api.rst deleted file mode 100644 index 6f230abc8..000000000 --- a/src/MEDOP/doc/sphinx/medop-userguide-api.rst +++ /dev/null @@ -1,528 +0,0 @@ -.. 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= - 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= - export PATH=${HDF5HOME}/bin:$PATH - export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH} - export HDF5_DISABLE_VERSION_CHECK=1 - - #------ med ------ - MED2HOME= - export PATH=${MED2HOME}/bin:${PATH} - export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH} - - #------ medmem --- - MED_ROOT_DIR= - 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 -.. ---------------------------------------- - diff --git a/src/MEDOP/doc/sphinx/medop-userguide-gui.rst b/src/MEDOP/doc/sphinx/medop-userguide-gui.rst deleted file mode 100644 index 3494402c5..000000000 --- a/src/MEDOP/doc/sphinx/medop-userguide-gui.rst +++ /dev/null @@ -1,649 +0,0 @@ -.. 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` (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 -```` is automatically created in the TUI to designate the field. In -this example, ```` 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`): - - >>> 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`). 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` 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`). - -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()`` (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`:: - - >>> 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):: - - $ /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:: - - $ /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 diff --git a/src/MEDOP/doc/sphinx/medop-workingnotes-2010.rst b/src/MEDOP/doc/sphinx/medop-workingnotes-2010.rst deleted file mode 100644 index 724c9a832..000000000 --- a/src/MEDOP/doc/sphinx/medop-workingnotes-2010.rst +++ /dev/null @@ -1,461 +0,0 @@ -.. 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. diff --git a/src/MEDOP/doc/sphinx/medop-workingnotes-2011.rst b/src/MEDOP/doc/sphinx/medop-workingnotes-2011.rst deleted file mode 100644 index 2c38e64bb..000000000 --- a/src/MEDOP/doc/sphinx/medop-workingnotes-2011.rst +++ /dev/null @@ -1,473 +0,0 @@ -.. 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 - - - diff --git a/src/MEDOP/doc/sphinx/medop-workingnotes-2012.rst b/src/MEDOP/doc/sphinx/medop-workingnotes-2012.rst deleted file mode 100644 index b6ecb6d37..000000000 --- a/src/MEDOP/doc/sphinx/medop-workingnotes-2012.rst +++ /dev/null @@ -1,84 +0,0 @@ -.. 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 - diff --git a/src/MEDOP/exe/CMakeLists.txt b/src/MEDOP/exe/CMakeLists.txt deleted file mode 100644 index d44f219c6..000000000 --- a/src/MEDOP/exe/CMakeLists.txt +++ /dev/null @@ -1,20 +0,0 @@ -# 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) diff --git a/src/MEDOP/exe/image2med/CMakeLists.txt b/src/MEDOP/exe/image2med/CMakeLists.txt deleted file mode 100644 index 7629f5802..000000000 --- a/src/MEDOP/exe/image2med/CMakeLists.txt +++ /dev/null @@ -1,24 +0,0 @@ -# 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) diff --git a/src/MEDOP/gui/CMakeLists.txt b/src/MEDOP/gui/CMakeLists.txt deleted file mode 100644 index 43faacf4d..000000000 --- a/src/MEDOP/gui/CMakeLists.txt +++ /dev/null @@ -1,101 +0,0 @@ -# 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}) diff --git a/src/MEDOP/gui/dialogs/CMakeLists.txt b/src/MEDOP/gui/dialogs/CMakeLists.txt deleted file mode 100644 index 574c12c27..000000000 --- a/src/MEDOP/gui/dialogs/CMakeLists.txt +++ /dev/null @@ -1,81 +0,0 @@ -# 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}) diff --git a/src/MEDOP/res/CMakeLists.txt b/src/MEDOP/res/CMakeLists.txt deleted file mode 100644 index f1f1f5236..000000000 --- a/src/MEDOP/res/CMakeLists.txt +++ /dev/null @@ -1,40 +0,0 @@ -# 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}) diff --git a/src/MEDOP/res/testfiles/CMakeLists.txt b/src/MEDOP/res/testfiles/CMakeLists.txt deleted file mode 100644 index c101b35fc..000000000 --- a/src/MEDOP/res/testfiles/CMakeLists.txt +++ /dev/null @@ -1,45 +0,0 @@ -# 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) diff --git a/src/MEDOP/tui/CMakeLists.txt b/src/MEDOP/tui/CMakeLists.txt deleted file mode 100644 index 734da38ad..000000000 --- a/src/MEDOP/tui/CMakeLists.txt +++ /dev/null @@ -1,21 +0,0 @@ -# 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) diff --git a/src/MEDOP/tui/presentation/CMakeLists.txt b/src/MEDOP/tui/presentation/CMakeLists.txt deleted file mode 100644 index 6aba267cf..000000000 --- a/src/MEDOP/tui/presentation/CMakeLists.txt +++ /dev/null @@ -1,26 +0,0 @@ -# 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) diff --git a/src/MEDOP/tui/xmedpy/CMakeLists.txt b/src/MEDOP/tui/xmedpy/CMakeLists.txt deleted file mode 100644 index bbc6e70c4..000000000 --- a/src/MEDOP/tui/xmedpy/CMakeLists.txt +++ /dev/null @@ -1,43 +0,0 @@ -# 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 diff --git a/src/MEDOP/tut/medcoupling/README.txt b/src/MEDOP/tut/medcoupling/README.txt deleted file mode 100644 index 9448c9ba4..000000000 --- a/src/MEDOP/tut/medcoupling/README.txt +++ /dev/null @@ -1,2 +0,0 @@ -Note that this test scripts required the PIL python library - diff --git a/src/MEDOP/tut/medcoupling/env.sh b/src/MEDOP/tut/medcoupling/env.sh deleted file mode 100644 index b520cf294..000000000 --- a/src/MEDOP/tut/medcoupling/env.sh +++ /dev/null @@ -1,55 +0,0 @@ -# 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} diff --git a/src/MEDOP/tut/medcoupling/images/avatar.png b/src/MEDOP/tut/medcoupling/images/avatar.png deleted file mode 100644 index ae252ccf9..000000000 Binary files a/src/MEDOP/tut/medcoupling/images/avatar.png and /dev/null differ diff --git a/src/MEDOP/tut/medcoupling/images/irm.png b/src/MEDOP/tut/medcoupling/images/irm.png deleted file mode 100644 index 5d20c7ed1..000000000 Binary files a/src/MEDOP/tut/medcoupling/images/irm.png and /dev/null differ diff --git a/src/MEDOP/tut/medcoupling/images/lena.png b/src/MEDOP/tut/medcoupling/images/lena.png deleted file mode 100644 index 16f9c840e..000000000 Binary files a/src/MEDOP/tut/medcoupling/images/lena.png and /dev/null differ diff --git a/src/MEDOP/tut/medcoupling/images/tests.pgm b/src/MEDOP/tut/medcoupling/images/tests.pgm deleted file mode 100644 index 63b8ce88a..000000000 --- a/src/MEDOP/tut/medcoupling/images/tests.pgm +++ /dev/null @@ -1,5 +0,0 @@ -P5 -# CREATOR: GIMP PNM Filter Version 1.1 -6 6 -255 -¿¿ÿÿ¿¿¿¿ÿÿ¿¿ÿÿÿÿÿÿÿÿ¿¿ÿÿ¿¿¿¿ÿÿ¿¿ \ No newline at end of file diff --git a/src/MEDOP/tut/medcoupling/partition.py b/src/MEDOP/tut/medcoupling/partition.py deleted file mode 100644 index 5b6152e2f..000000000 --- a/src/MEDOP/tut/medcoupling/partition.py +++ /dev/null @@ -1,79 +0,0 @@ -# -*- 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) diff --git a/src/MEDOP/tut/medcoupling/pyfunctions/__init__.py b/src/MEDOP/tut/medcoupling/pyfunctions/__init__.py deleted file mode 100644 index e69de29bb..000000000 diff --git a/src/MEDOP/tut/medcoupling/pyfunctions/functions.py b/src/MEDOP/tut/medcoupling/pyfunctions/functions.py deleted file mode 100755 index 0b0eb3080..000000000 --- a/src/MEDOP/tut/medcoupling/pyfunctions/functions.py +++ /dev/null @@ -1,269 +0,0 @@ -#!/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 xxsup: - 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() diff --git a/src/MEDOP/tut/medcoupling/pyfunctions/lagrange.py b/src/MEDOP/tut/medcoupling/pyfunctions/lagrange.py deleted file mode 100755 index 319902e12..000000000 --- a/src/MEDOP/tut/medcoupling/pyfunctions/lagrange.py +++ /dev/null @@ -1,150 +0,0 @@ -#!/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>> -# 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() diff --git a/src/MEDOP/tut/medcoupling/testmed_lena.py b/src/MEDOP/tut/medcoupling/testmed_lena.py deleted file mode 100755 index 114719ccc..000000000 --- a/src/MEDOP/tut/medcoupling/testmed_lena.py +++ /dev/null @@ -1,136 +0,0 @@ -#!/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) diff --git a/src/MEDOP/tut/medcoupling/testmed_simple.py b/src/MEDOP/tut/medcoupling/testmed_simple.py deleted file mode 100755 index 36c2d813e..000000000 --- a/src/MEDOP/tut/medcoupling/testmed_simple.py +++ /dev/null @@ -1,164 +0,0 @@ -#!/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) - - diff --git a/src/MEDOP/tut/medcoupling/testpil.py b/src/MEDOP/tut/medcoupling/testpil.py deleted file mode 100755 index 109f518ac..000000000 --- a/src/MEDOP/tut/medcoupling/testpil.py +++ /dev/null @@ -1,149 +0,0 @@ -#!/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() diff --git a/src/MEDOP/tut/medloader/Makefile b/src/MEDOP/tut/medloader/Makefile deleted file mode 100644 index a03ea153c..000000000 --- a/src/MEDOP/tut/medloader/Makefile +++ /dev/null @@ -1,9 +0,0 @@ -all: - python tutorial.py - python explore.py - python manage.py - python testamel.py - python cmesh - -clean: - rm -f *~ *.pyc output.med diff --git a/src/MEDOP/tut/medloader/cmesh.py b/src/MEDOP/tut/medloader/cmesh.py deleted file mode 100644 index 6054c84ab..000000000 --- a/src/MEDOP/tut/medloader/cmesh.py +++ /dev/null @@ -1,71 +0,0 @@ -#!/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. diff --git a/src/MEDOP/tut/medloader/explore.py b/src/MEDOP/tut/medloader/explore.py deleted file mode 100644 index 5522d3737..000000000 --- a/src/MEDOP/tut/medloader/explore.py +++ /dev/null @@ -1,98 +0,0 @@ -#!/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 diff --git a/src/MEDOP/tut/medloader/madnex_field.med b/src/MEDOP/tut/medloader/madnex_field.med deleted file mode 100644 index 05acf1a21..000000000 Binary files a/src/MEDOP/tut/medloader/madnex_field.med and /dev/null differ diff --git a/src/MEDOP/tut/medloader/madnex_grid.med b/src/MEDOP/tut/medloader/madnex_grid.med deleted file mode 100644 index b6b004dc6..000000000 Binary files a/src/MEDOP/tut/medloader/madnex_grid.med and /dev/null differ diff --git a/src/MEDOP/tut/medloader/manage.py b/src/MEDOP/tut/medloader/manage.py deleted file mode 100644 index 4c6c44909..000000000 --- a/src/MEDOP/tut/medloader/manage.py +++ /dev/null @@ -1,94 +0,0 @@ -#!/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 diff --git a/src/MEDOP/tut/medloader/testamel.py b/src/MEDOP/tut/medloader/testamel.py deleted file mode 100644 index 819aca01a..000000000 --- a/src/MEDOP/tut/medloader/testamel.py +++ /dev/null @@ -1,68 +0,0 @@ -# -*- 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 diff --git a/src/MEDOP/tut/medloader/timeseries.med b/src/MEDOP/tut/medloader/timeseries.med deleted file mode 100644 index 3226304db..000000000 Binary files a/src/MEDOP/tut/medloader/timeseries.med and /dev/null differ diff --git a/src/MEDOP/tut/medloader/tutorial.py b/src/MEDOP/tut/medloader/tutorial.py deleted file mode 100644 index ab94b7915..000000000 --- a/src/MEDOP/tut/medloader/tutorial.py +++ /dev/null @@ -1,59 +0,0 @@ -#!/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