-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
+# Copyright (C) 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 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
-#
-CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8 FATAL_ERROR)
-INCLUDE(CMakeDependentOption)
-PROJECT(SalomeMED C CXX)
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2 FATAL_ERROR)
+#INCLUDE(CMakeDependentOption)
+PROJECT(MEDCoupling C CXX)
# Ensure a proper linker behavior:
CMAKE_POLICY(SET CMP0003 NEW)
# Project name, upper case
STRING(TOUPPER ${PROJECT_NAME} PROJECT_NAME_UC)
-SET(${PROJECT_NAME_UC}_MAJOR_VERSION 7)
-SET(${PROJECT_NAME_UC}_MINOR_VERSION 7)
+SET(${PROJECT_NAME_UC}_MAJOR_VERSION 1)
+SET(${PROJECT_NAME_UC}_MINOR_VERSION 0)
SET(${PROJECT_NAME_UC}_PATCH_VERSION 0)
SET(${PROJECT_NAME_UC}_VERSION
${${PROJECT_NAME_UC}_MAJOR_VERSION}.${${PROJECT_NAME_UC}_MINOR_VERSION}.${${PROJECT_NAME_UC}_PATCH_VERSION})
SET(${PROJECT_NAME_UC}_VERSION_DEV 1)
-#
-# Kernel detection comes before user options to be
-# able to take previous values of global options ...
-#
-SET(_default_MPI OFF)
-IF(NOT SALOME_MED_STANDALONE)
- SET(KERNEL_ROOT_DIR $ENV{KERNEL_ROOT_DIR} CACHE PATH "Path to the Salome KERNEL")
- IF(EXISTS ${KERNEL_ROOT_DIR})
- LIST(APPEND CMAKE_MODULE_PATH "${KERNEL_ROOT_DIR}/salome_adm/cmake_files")
- INCLUDE(SalomeMacros)
- FIND_PACKAGE(SalomeKERNEL REQUIRED)
- KERNEL_WITH_CORBA() #check whether KERNEL builded with CORBA
- ADD_DEFINITIONS(${KERNEL_DEFINITIONS})
- INCLUDE_DIRECTORIES(${KERNEL_INCLUDE_DIRS})
- 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})
- LIST(APPEND CMAKE_MODULE_PATH "${KERNEL_ROOT_DIR}/salome_adm/cmake_files")
-ELSE(NOT SALOME_MED_STANDALONE)
- LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/adm_local_without_kernel/cmake_files")
- INCLUDE(SalomeMacros)
-ENDIF(NOT SALOME_MED_STANDALONE)
-
-# Platform setup
-# ==============
-INCLUDE(SalomeSetupPlatform)
-
-IF(NOT SALOME_MED_STANDALONE)
- FIND_PACKAGE(SalomePThread REQUIRED) # for MEDCouplingCorba/Test for EDF
- FIND_PACKAGE(SalomeOmniORB REQUIRED)
-ENDIF(NOT SALOME_MED_STANDALONE)
+# Our own set of macros:
+LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake_files")
+INCLUDE(MEDCouplingMacros)
+
#
# User options
# ============
INCLUDE(CMakeDependentOption)
-OPTION(SALOME_MED_STANDALONE "Build MED without CORBA bindings. When OFF, exchange to PARAVIS is disabled." OFF)
-OPTION(SALOME_MED_MICROMED "Build MED without MED file dependancy." OFF)
-OPTION(SALOME_MED_ENABLE_PYTHON "Build PYTHON bindings." ON)
-OPTION(SALOME_MED_ENABLE_PARTITIONER "Build MEDPartitioner." ON)
-OPTION(SALOME_MED_ENABLE_RENUMBER "Build Renumber." ON)
-OPTION(SALOME_MED_WITH_FILE_EXAMPLES "Install examples of files containing meshes and fields of different formats." ON)
-OPTION(SALOME_USE_MPI "(Use MPI containers) - For MED this triggers the build of ParaMEDMEM." ${_default_MPI})
-CMAKE_DEPENDENT_OPTION(SALOME_BUILD_GUI "Build GUI of MED." ON
- "NOT SALOME_MED_STANDALONE" OFF)
-OPTION(SALOME_BUILD_TESTS "Build MED tests." ON)
-OPTION(SALOME_BUILD_DOC "Build MED doc." ON)
-CMAKE_DEPENDENT_OPTION(SALOME_MED_PARTITIONER_METIS "Enable metis graph library in MEDPartitioner." ON "SALOME_MED_ENABLE_PARTITIONER" OFF)
-CMAKE_DEPENDENT_OPTION(SALOME_MED_PARTITIONER_SCOTCH "Enable scotch graph library in MEDPartitioner." ON "SALOME_MED_ENABLE_PARTITIONER;NOT SALOME_USE_MPI" OFF)
-CMAKE_DEPENDENT_OPTION(SALOME_MED_PARTITIONER_PARMETIS "Enable parmetis graph library in MEDPartitioner." ON "SALOME_MED_ENABLE_PARTITIONER;SALOME_USE_MPI" OFF)
+OPTION(MEDCOUPLING_MED_MICROMED "Build MED without MED file dependancy." OFF)
+OPTION(MEDCOUPLING_MED_ENABLE_PYTHON "Build PYTHON bindings." ON)
+OPTION(MEDCOUPLING_MED_ENABLE_PARTITIONER "Build MEDPartitioner." ON)
+OPTION(MEDCOUPLING_MED_ENABLE_RENUMBER "Build Renumber." ON)
+OPTION(MEDCOUPLING_MED_WITH_FILE_EXAMPLES "Install examples of files containing meshes and fields of different formats." ON)
+OPTION(MEDCOUPLING_USE_MPI "(Use MPI containers) - For MED this triggers the build of ParaMEDMEM." OFF)
+OPTION(MEDCOUPLING_BUILD_TESTS "Build MED tests." ON)
+OPTION(MEDCOUPLING_BUILD_DOC "Build MED doc." ON)
+CMAKE_DEPENDENT_OPTION(MEDCOUPLING_MED_PARTITIONER_METIS "Enable metis graph library in MEDPartitioner." ON "MEDCOUPLING_MED_ENABLE_PARTITIONER" OFF)
+CMAKE_DEPENDENT_OPTION(MEDCOUPLING_MED_PARTITIONER_SCOTCH "Enable scotch graph library in MEDPartitioner." ON "MEDCOUPLING_MED_ENABLE_PARTITIONER;NOT MEDCOUPLING_USE_MPI" OFF)
+CMAKE_DEPENDENT_OPTION(MEDCOUPLING_MED_PARTITIONER_PARMETIS "Enable parmetis graph library in MEDPartitioner." ON "MEDCOUPLING_MED_ENABLE_PARTITIONER;MEDCOUPLING_USE_MPI" OFF)
IF(WIN32)
- CMAKE_DEPENDENT_OPTION(SALOME_MED_MEDLOADER_USE_XDR "Enable use of XDR for SauvReader." ON "NOT SALOME_MED_MICROMED" OFF)
+ CMAKE_DEPENDENT_OPTION(MEDCOUPLING_MED_MEDLOADER_USE_XDR "Enable use of XDR for SauvReader." ON "NOT MEDCOUPLING_MED_MICROMED" OFF)
ENDIF(WIN32)
#
# Set list of prerequisites
# =========================
-IF(NOT SALOME_MED_STANDALONE)
- SET(KERNEL_ROOT_DIR $ENV{KERNEL_ROOT_DIR} CACHE PATH "Path to the Salome KERNEL")
- IF(EXISTS ${KERNEL_ROOT_DIR})
- LIST(APPEND CMAKE_MODULE_PATH "${KERNEL_ROOT_DIR}/salome_adm/cmake_files")
- INCLUDE(SalomeMacros)
- FIND_PACKAGE(SalomeKERNEL REQUIRED)
- KERNEL_WITH_CORBA() #check whether KERNEL builded with CORBA
- 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})
- LIST(APPEND CMAKE_MODULE_PATH "${KERNEL_ROOT_DIR}/salome_adm/cmake_files")
- LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/adm_local/cmake_files")
-ELSE(NOT SALOME_MED_STANDALONE)
- LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/adm_local/cmake_files")
- LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/adm_local_without_kernel/cmake_files")
- INCLUDE(SalomeMacros)
-ENDIF(NOT SALOME_MED_STANDALONE)
-
-IF(NOT SALOME_MED_MICROMED)
- FIND_PACKAGE(SalomeHDF5 REQUIRED)
- FIND_PACKAGE(SalomeMEDFile REQUIRED)
+IF(NOT MEDCOUPLING_MED_MICROMED)
+ FIND_PACKAGE(HDF5 REQUIRED)
+ FIND_PACKAGE(MEDFile REQUIRED)
# XDR stuff
IF(NOT WIN32)
- FIND_PACKAGE(SalomeXDR REQUIRED)
+ FIND_PACKAGE(XDR REQUIRED)
ELSE(NOT WIN32)
- IF(SALOME_MED_MEDLOADER_USE_XDR)
- FIND_PACKAGE(SalomeXDR REQUIRED)
- ENDIF(SALOME_MED_MEDLOADER_USE_XDR)
+ IF(MEDCOUPLING_MED_MEDLOADER_USE_XDR)
+ FIND_PACKAGE(XDR REQUIRED)
+ ENDIF(MEDCOUPLING_MED_MEDLOADER_USE_XDR)
ENDIF(NOT WIN32)
# End of XDR Stuff
- IF(SALOME_MED_ENABLE_PARTITIONER)
- FIND_PACKAGE(SalomeLibXml2)
- SALOME_LOG_OPTIONAL_PACKAGE(LibXml2 SALOME_MED_ENABLE_PARTITIONER)
- IF(SALOME_MED_PARTITIONER_METIS)
- FIND_PACKAGE(SalomeMetis)
- SALOME_LOG_OPTIONAL_PACKAGE(Metis SALOME_MED_PARTITIONER_METIS)
+ IF(MEDCOUPLING_MED_ENABLE_PARTITIONER)
+ IF(DEFINED ENV{LIBXML2_ROOT_DIR})
+ SET(LIBXML2_ROOT_DIR $ENV{LIBXML2_ROOT_DIR} CACHE PATH "Path to the LibXml2.")
+ LIST(APPEND CMAKE_PREFIX_PATH "${LIBXML2_ROOT_DIR}")
+ ENDIF()
+ FIND_PACKAGE(LibXml2)
+ IF(MEDCOUPLING_MED_PARTITIONER_METIS)
+ FIND_PACKAGE(Metis)
ADD_DEFINITIONS("-DMED_ENABLE_METIS")
- ENDIF(SALOME_MED_PARTITIONER_METIS)
- IF(SALOME_MED_PARTITIONER_SCOTCH)
- FIND_PACKAGE(SalomeScotch)
- SALOME_LOG_OPTIONAL_PACKAGE(Scotch SALOME_MED_PARTITIONER_SCOTCH)
+ ENDIF(MEDCOUPLING_MED_PARTITIONER_METIS)
+ IF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
+ FIND_PACKAGE(Scotch)
ADD_DEFINITIONS("-DMED_ENABLE_SCOTCH")
- ENDIF(SALOME_MED_PARTITIONER_SCOTCH)
- ENDIF(SALOME_MED_ENABLE_PARTITIONER)
-ENDIF(NOT SALOME_MED_MICROMED)
+ ENDIF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
+ ENDIF(MEDCOUPLING_MED_ENABLE_PARTITIONER)
+ENDIF(NOT MEDCOUPLING_MED_MICROMED)
-# Find GUI (optional)
-# ===========
-IF(SALOME_BUILD_GUI)
- SET(GUI_ROOT_DIR $ENV{GUI_ROOT_DIR} CACHE PATH "Path to the Salome GUI")
- IF(EXISTS ${GUI_ROOT_DIR})
- LIST(APPEND CMAKE_MODULE_PATH "${GUI_ROOT_DIR}/adm_local/cmake_files")
- FIND_PACKAGE(SalomeGUI REQUIRED)
- SALOME_GUI_WITH_CORBA() #check whether GUI builded with CORBA
- SALOME_GUI_MODE(SALOME_USE_SALOMEOBJECT SALOME_USE_PYCONSOLE OPTIONAL SALOME_USE_PVVIEWER)
- ADD_DEFINITIONS(${GUI_DEFINITIONS})
- INCLUDE_DIRECTORIES(${GUI_INCLUDE_DIRS})
- ELSE(EXISTS ${GUI_ROOT_DIR})
- MESSAGE(FATAL_ERROR "We absolutely need a Salome GUI, please define GUI_ROOT_DIR or turn option SALOME_BUILD_GUI to OFF !")
- ENDIF(EXISTS ${GUI_ROOT_DIR})
- FIND_PACKAGE(SalomeQt4 REQUIRED COMPONENTS QtCore QtGui)
- FIND_PACKAGE(SalomeCAS REQUIRED) # maybe one day it will disappear ...
-ENDIF(SALOME_BUILD_GUI)
-
-LIST(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/adm_local/cmake_files")
-
-ENABLE_TESTING() # let it outsite because even if SALOME_BUILD_TESTS is OFF, python tests that not need additional compilation can be run.
-
-IF(SALOME_BUILD_TESTS)
- FIND_PACKAGE(SalomeCppUnit)
- SALOME_LOG_OPTIONAL_PACKAGE(CppUnit SALOME_BUILD_TESTS)
-ENDIF(SALOME_BUILD_TESTS)
-
-IF(SALOME_USE_MPI)
- FIND_PACKAGE(SalomeMPI REQUIRED)
+ENABLE_TESTING() # let it outsite because even if MEDCOUPLING_BUILD_TESTS is OFF, python tests that not need additional compilation can be run.
+
+IF(MEDCOUPLING_BUILD_TESTS)
+ FIND_PACKAGE(CppUnit)
+ENDIF(MEDCOUPLING_BUILD_TESTS)
+
+IF(MEDCOUPLING_USE_MPI)
+ FIND_PACKAGE(MPI REQUIRED)
ADD_DEFINITIONS("-DHAVE_MPI")
- IF(SALOME_MED_PARTITIONER_PARMETIS)
- FIND_PACKAGE(SalomeParMetis)
- SALOME_LOG_OPTIONAL_PACKAGE(ParMetis SALOME_MED_PARTITIONER_PARMETIS)
+ SET(MPI_INCLUDE_DIRS ${MPI_C_INCLUDE_PATH} ${MPI_CXX_INCLUDE_PATH})
+ SET(MPI_LIBRARIES ${MPI_C_LIBRARIES} ${MPI_CXX_LIBRARIES})
+ SET(MPI_DEFINITIONS "${MPI_CXX_COMPILE_FLAGS}")
+
+ IF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
+ FIND_PACKAGE(ParMetis)
ADD_DEFINITIONS("-DMED_ENABLE_PARMETIS")
- ENDIF(SALOME_MED_PARTITIONER_PARMETIS)
-ENDIF(SALOME_USE_MPI)
-
-IF(SALOME_MED_ENABLE_RENUMBER)
- FIND_PACKAGE(SalomeBoost)
- SALOME_LOG_OPTIONAL_PACKAGE(Boost SALOME_MED_ENABLE_RENUMBER)
-ENDIF(SALOME_MED_ENABLE_RENUMBER)
-
-IF(SALOME_MED_ENABLE_PYTHON)
- FIND_PACKAGE(SalomePython)
- FIND_PACKAGE(SalomeSWIG)
- SALOME_LOG_OPTIONAL_PACKAGE(Python SALOME_MED_ENABLE_PYTHON)
- SALOME_LOG_OPTIONAL_PACKAGE(SWIG SALOME_MED_ENABLE_PYTHON)
- IF(NOT SALOME_MED_STANDALONE)
- FIND_PACKAGE(SalomeOmniORBPy REQUIRED)
- ENDIF(NOT SALOME_MED_STANDALONE)
+ ENDIF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
+ENDIF(MEDCOUPLING_USE_MPI)
+
+IF(MEDCOUPLING_MED_ENABLE_RENUMBER)
+ IF(DEFINED ENV{BOOST_ROOT_DIR})
+ SET(BOOST_ROOT_DIR $ENV{BOOST_ROOT_DIR} CACHE PATH "Path to the Boost.")
+ LIST(APPEND CMAKE_PREFIX_PATH "${BOOST_ROOT_DIR}")
+ ENDIF()
+ SET(Boost_USE_STATIC_LIBS OFF)
+ SET(Boost_USE_MULTITHREADED ON)
+ SET(Boost_USE_STATIC_RUNTIME OFF)
+ SET(Boost_NO_BOOST_CMAKE ON)
+ FIND_PACKAGE(Boost)
+ENDIF(MEDCOUPLING_MED_ENABLE_RENUMBER)
+
+IF(MEDCOUPLING_BUILD_DOC)
+ FIND_PACKAGE(Doxygen)
+ FIND_PACKAGE(Graphviz)
+ FIND_PACKAGE(Sphinx)
+ENDIF(MEDCOUPLING_BUILD_DOC)
+
+IF(MEDCOUPLING_MED_ENABLE_PYTHON)
+ FIND_PACKAGE(PythonInterp)
+ GET_FILENAME_COMPONENT(_python_dir "${PYTHON_EXECUTABLE}" PATH)
+ GET_FILENAME_COMPONENT(CMAKE_INCLUDE_PATH "${_python_dir}/../include/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}" ABSOLUTE)
+ GET_FILENAME_COMPONENT(CMAKE_LIBRARY_PATH "${_python_dir}/../lib" ABSOLUTE)
+ SET(PythonLibs_FIND_VERSION "${PYTHON_VERSION}")
+ FIND_PACKAGE(PythonLibs)
+
+ FIND_PACKAGE(SWIG)
# Set the extra flags for SWIG for numpy and scipy
SET(SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY)
IF(NUMPY_FOUND)
IF(SCIPY_FOUND)
SET(SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY "${SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY};-DWITH_SCIPY")
ENDIF(SCIPY_FOUND)
-ENDIF(SALOME_MED_ENABLE_PYTHON)
-
-IF(SALOME_BUILD_DOC)
- FIND_PACKAGE(SalomeDoxygen)
- FIND_PACKAGE(SalomeGraphviz)
- FIND_PACKAGE(SalomeSphinx)
- SALOME_LOG_OPTIONAL_PACKAGE(Doxygen SALOME_BUILD_DOC)
- SALOME_LOG_OPTIONAL_PACKAGE(Graphviz SALOME_BUILD_DOC)
- SALOME_LOG_OPTIONAL_PACKAGE(Sphinx SALOME_BUILD_DOC)
-ENDIF(SALOME_BUILD_DOC)
-
-# Detection report
-SALOME_PACKAGE_REPORT_AND_CHECK()
+ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
# Directories
#
# Directories have to be given after prerequisites (to be able to use
# Python version string for example).
# ===========
-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
- "Install path: SALOME scripts")
-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
- "Install path: SALOME Python scripts")
-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
- "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
- "Install path: local SALOME CMake files")
-
-IF(SALOME_MED_ENABLE_PYTHON)
+SET(MEDCOUPLING_INSTALL_BINS bin CACHE PATH "Install path: MEDCoupling binaries")
+SET(MEDCOUPLING_INSTALL_LIBS lib CACHE PATH "Install path: MEDCoupling libs")
+SET(MEDCOUPLING_INSTALL_HEADERS include CACHE PATH "Install path: MEDCoupling headers")
+SET(MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS ${MEDCOUPLING_INSTALL_BINS} CACHE PATH "Install path: MEDCoupling scripts")
+SET(MEDCOUPLING_INSTALL_TESTS tests CACHE PATH "Install path: MEDCoupling tests")
+# SET(MEDCOUPLING_INSTALL_SCRIPT_DATA ${MEDCOUPLING_INSTALL_BINS} CACHE PATH "Install path: MEDCoupling script data")
+SET(MEDCOUPLING_INSTALL_SCRIPT_PYTHON ${MEDCOUPLING_INSTALL_BINS} CACHE PATH "Install path: MEDCoupling Python scripts")
+SET(MEDCOUPLING_INSTALL_CMAKE_LOCAL cmake_files CACHE PATH "Install path: local MEDCoupling CMake files")
+
+IF(MEDCOUPLING_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
- "Install path: SALOME Python shared modules")
-ENDIF(SALOME_MED_ENABLE_PYTHON)
+ SET(MEDCOUPLING_INSTALL_PYTHON ${_pydir} CACHE PATH "Install path: MEDCoupling Python stuff")
+ SET(MEDCOUPLING_INSTALL_PYTHON_SHARED ${MEDCOUPLING_INSTALL_PYTHON}/shared_modules CACHE PATH
+ "Install path: MEDCoupling Python shared modules")
+ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
-SET(SALOME_INSTALL_RES share/salome/resources CACHE PATH "Install path: SALOME resources")
-SET(SALOME_INSTALL_DOC share/doc/salome CACHE PATH "Install path: SALOME documentation")
+SET(MEDCOUPLING_INSTALL_RES share/resources CACHE PATH "Install path: MEDCoupling resources")
+SET(MEDCOUPLING_INSTALL_DOC share/doc CACHE PATH "Install path: MEDCoupling documentation")
# Med specific:
-SET(SALOME_MED_INSTALL_RES_DATA "${SALOME_INSTALL_RES}/med" CACHE PATH "Install path: SALOME MED specific data")
-SET(SALOME_MED_INSTALL_RES_SCRIPTS "${SALOME_INSTALL_RES}/med" CACHE PATH "Install path: SALOME MED specific scripts")
+SET(MEDCOUPLING_INSTALL_RES_DATA "${MEDCOUPLING_INSTALL_RES}/med" CACHE PATH "Install path: MEDCoupling specific data")
+#SET(MEDCOUPLING_MED_INSTALL_RES_SCRIPTS "${MEDCOUPLING_INSTALL_RES}/med" CACHE PATH "Install path: MEDCouplng specific scripts")
-MARK_AS_ADVANCED(SALOME_INSTALL_BINS SALOME_INSTALL_LIBS SALOME_INSTALL_IDLS SALOME_INSTALL_HEADERS)
-MARK_AS_ADVANCED(SALOME_INSTALL_SCRIPT_SCRIPTS SALOME_INSTALL_SCRIPT_DATA SALOME_INSTALL_SCRIPT_PYTHON)
-MARK_AS_ADVANCED(SALOME_INSTALL_APPLISKEL_SCRIPTS SALOME_INSTALL_APPLISKEL_PYTHON SALOME_INSTALL_CMAKE SALOME_INSTALL_CMAKE_LOCAL SALOME_INSTALL_RES)
-MARK_AS_ADVANCED(SALOME_INSTALL_PYTHON SALOME_INSTALL_PYTHON_SHARED SALOME_MED_INSTALL_RES_DATA SALOME_MED_INSTALL_RES_SCRIPTS SALOME_INSTALL_DOC)
+MARK_AS_ADVANCED(MEDCOUPLING_INSTALL_BINS MEDCOUPLING_INSTALL_LIBS MEDCOUPLING_INSTALL_IDLS MEDCOUPLING_INSTALL_HEADERS)
+MARK_AS_ADVANCED(MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS MEDCOUPLING_INSTALL_SCRIPT_DATA MEDCOUPLING_INSTALL_SCRIPT_PYTHON)
+MARK_AS_ADVANCED(MEDCOUPLING_INSTALL_APPLISKEL_SCRIPTS MEDCOUPLING_INSTALL_APPLISKEL_PYTHON MEDCOUPLING_INSTALL_CMAKE MEDCOUPLING_INSTALL_CMAKE_LOCAL MEDCOUPLING_INSTALL_RES)
+MARK_AS_ADVANCED(MEDCOUPLING_INSTALL_PYTHON MEDCOUPLING_INSTALL_PYTHON_SHARED MEDCOUPLING_MED_INSTALL_RES_DATA MEDCOUPLING_MED_INSTALL_RES_SCRIPTS MEDCOUPLING_INSTALL_DOC)
# Header configuration
# ====================
-SALOME_XVERSION(${PROJECT_NAME})
-SALOME_CONFIGURE_FILE(MED_version.h.in MED_version.h INSTALL ${SALOME_INSTALL_HEADERS})
-SALOME_CONFIGURE_FILE(VERSION.in VERSION INSTALL ${SALOME_INSTALL_BINS})
+MEDCOUPLING_XVERSION(${PROJECT_NAME})
+CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/MEDCoupling_version.h.in ${CMAKE_CURRENT_BINARY_DIR}/MEDCoupling_version.h)
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDCoupling_version.h DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# Accumulate environment variables for MED module
-SALOME_ACCUMULATE_ENVIRONMENT(PYTHONPATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_BINS}
- ${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_PYTHON})
-SALOME_ACCUMULATE_ENVIRONMENT(LD_LIBRARY_PATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_LIBS})
+#SALOME_ACCUMULATE_ENVIRONMENT(PYTHONPATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${MEDCOUPLING_INSTALL_BINS}
+# ${CMAKE_INSTALL_PREFIX}/${MEDCOUPLING_INSTALL_PYTHON})
+#SALOME_ACCUMULATE_ENVIRONMENT(LD_LIBRARY_PATH NOCHECK ${CMAKE_INSTALL_PREFIX}/${MEDCOUPLING_INSTALL_LIBS})
-# Sources
+# Sources
# ========
IF(WIN32)
ADD_DEFINITIONS("-D_USE_MATH_DEFINES")
ENDIF(WIN32)
ADD_SUBDIRECTORY(src)
-ADD_SUBDIRECTORY(adm_local)
+ADD_SUBDIRECTORY(cmake_files)
-IF(SALOME_BUILD_DOC)
+IF(MEDCOUPLING_BUILD_DOC)
ADD_SUBDIRECTORY(doc)
-ENDIF(SALOME_BUILD_DOC)
-
-IF(NOT SALOME_MED_STANDALONE)
- ADD_SUBDIRECTORY(idl)
-ELSE(NOT SALOME_MED_STANDALONE)
- ADD_SUBDIRECTORY(adm_local_without_kernel)
-ENDIF(NOT SALOME_MED_STANDALONE)
+ENDIF(MEDCOUPLING_BUILD_DOC)
-IF(NOT SALOME_MED_MICROMED)
- IF(SALOME_MED_WITH_FILE_EXAMPLES)
+IF(NOT MEDCOUPLING_MED_MICROMED)
+ IF(MEDCOUPLING_MED_WITH_FILE_EXAMPLES)
ADD_SUBDIRECTORY(resources)
- ENDIF(SALOME_MED_WITH_FILE_EXAMPLES)
-ENDIF(NOT SALOME_MED_MICROMED)
+ ENDIF(MEDCOUPLING_MED_WITH_FILE_EXAMPLES)
+ENDIF(NOT MEDCOUPLING_MED_MICROMED)
# Configuration export
# ====================
-INCLUDE(CMakePackageConfigHelpers)
# List of targets in this project we want to make visible to the rest of the world.
# They all have to be INSTALL'd with the option "EXPORT ${PROJECT_NAME}TargetGroup"
SET(_${PROJECT_NAME}_exposed_targets
interpkernel medcoupling medcouplingremapper)
-IF(NOT SALOME_MED_MICROMED)
+IF(NOT MEDCOUPLING_MED_MICROMED)
LIST(APPEND _${PROJECT_NAME}_exposed_targets medloader)
- IF(SALOME_MED_ENABLE_RENUMBER)
+ IF(MEDCOUPLING_MED_ENABLE_RENUMBER)
LIST(APPEND _${PROJECT_NAME}_exposed_targets renumbercpp)
ENDIF()
- IF(SALOME_MED_ENABLE_PARTITIONER)
+ IF(MEDCOUPLING_MED_ENABLE_PARTITIONER)
LIST(APPEND _${PROJECT_NAME}_exposed_targets medpartitionercpp)
- IF(SALOME_BUILD_TESTS)
+ IF(MEDCOUPLING_BUILD_TESTS)
LIST(APPEND _${PROJECT_NAME}_exposed_targets MEDPARTITIONERTest)
ENDIF()
ENDIF()
- IF(SALOME_BUILD_TESTS)
+ IF(MEDCOUPLING_BUILD_TESTS)
LIST(APPEND _${PROJECT_NAME}_exposed_targets InterpKernelTest)
ENDIF()
ENDIF()
-IF(SALOME_USE_MPI)
+IF(MEDCOUPLING_USE_MPI)
LIST(APPEND _${PROJECT_NAME}_exposed_targets paramedmem)
- IF(NOT SALOME_MED_MICROMED)
+ IF(NOT MEDCOUPLING_MED_MICROMED)
LIST(APPEND _${PROJECT_NAME}_exposed_targets paramedloader)
ENDIF()
- IF(NOT SALOME_MED_STANDALONE)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
- paramedcouplingcorba paramedmemcompo)
- ENDIF()
- IF(SALOME_BUILD_TESTS)
- IF(NOT SALOME_MED_MICROMED)
+ IF(MEDCOUPLING_BUILD_TESTS)
+ IF(NOT MEDCOUPLING_MED_MICROMED)
LIST(APPEND _${PROJECT_NAME}_exposed_targets ParaMEDMEMTest)
ENDIF()
- ENDIF()
-ENDIF()
-
-IF(NOT SALOME_MED_STANDALONE)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
- SalomeIDLMED SalomeIDLMEDTests medcouplingcorba medcouplingclient)
- IF(NOT SALOME_MED_MICROMED)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets medcalculator MEDOPFactoryEngine)
- IF(SALOME_MED_ENABLE_PYTHON)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets medcalculatorspython)
- ENDIF()
- ENDIF()
-ENDIF()
-
-IF(SALOME_BUILD_GUI)
- IF(NOT SALOME_MED_MICROMED)
- LIST(APPEND _${PROJECT_NAME}_exposed_targets
- MEDOPGUI_dialogs MEDOPGUI)
ENDIF()
ENDIF()
# - in the build tree:
# Ensure the variables are always defined for the configure (even if empty):
-SET(KERNEL_ROOT_DIR "${KERNEL_ROOT_DIR}")
-SET(GUI_ROOT_DIR "${GUI_ROOT_DIR}")
-SET(MEDFILE_ROOT_DIR "${MEDFILE_ROOT_DIR}")
-SET(MPI_ROOT_DIR "${MPI_ROOT_DIR}")
-SET(HDF5_ROOT_DIR "${HDF5_ROOT_DIR}")
-SET(OMNIORB_ROOT_DIR "${OMNIORB_ROOT_DIR}")
-SET(PTHREAD_ROOT_DIR "${PTHREAD_ROOT_DIR}")
-SET(BOOST_ROOT_DIR "${BOOST_ROOT_DIR}")
-SET(SWIG_ROOT_DIR "${SWIG_ROOT_DIR}")
-SET(PYTHON_ROOT_DIR "${PYTHON_ROOT_DIR}")
-SET(CPPUNIT_ROOT_DIR "${CPPUNIT_ROOT_DIR}")
-SET(GRAPHVIZ_ROOT_DIR "${GRAPHVIZ_ROOT_DIR}")
-SET(DOXYGEN_ROOT_DIR "${DOXYGEN_ROOT_DIR}")
-SET(SPHINX_ROOT_DIR "${SPHINX_ROOT_DIR}")
-
-SET(METIS_ROOT_DIR "${METIS_ROOT_DIR}")
-SET(PARMETIS_ROOT_DIR "${PARMETIS_ROOT_DIR}")
-SET(SCOTCH_ROOT_DIR "${SCOTCH_ROOT_DIR}")
-SET(XDR_ROOT_DIR "${XDR_ROOT_DIR}")
+# SET(KERNEL_ROOT_DIR "${KERNEL_ROOT_DIR}")
+# SET(GUI_ROOT_DIR "${GUI_ROOT_DIR}")
+# SET(MEDFILE_ROOT_DIR "${MEDFILE_ROOT_DIR}")
+# SET(MPI_ROOT_DIR "${MPI_ROOT_DIR}")
+# SET(HDF5_ROOT_DIR "${HDF5_ROOT_DIR}")
+# SET(OMNIORB_ROOT_DIR "${OMNIORB_ROOT_DIR}")
+# SET(PTHREAD_ROOT_DIR "${PTHREAD_ROOT_DIR}")
+# SET(BOOST_ROOT_DIR "${BOOST_ROOT_DIR}")
+# SET(SWIG_ROOT_DIR "${SWIG_ROOT_DIR}")
+# SET(PYTHON_ROOT_DIR "${PYTHON_ROOT_DIR}")
+# SET(CPPUNIT_ROOT_DIR "${CPPUNIT_ROOT_DIR}")
+# SET(GRAPHVIZ_ROOT_DIR "${GRAPHVIZ_ROOT_DIR}")
+# SET(DOXYGEN_ROOT_DIR "${DOXYGEN_ROOT_DIR}")
+# SET(SPHINX_ROOT_DIR "${SPHINX_ROOT_DIR}")
+
+# SET(METIS_ROOT_DIR "${METIS_ROOT_DIR}")
+# SET(PARMETIS_ROOT_DIR "${PARMETIS_ROOT_DIR}")
+# 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 Salome<MODULE>Config.cmake:
-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
- ${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
- 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
- SPHINX_ROOT_DIR METIS_ROOT_DIR PARMETIS_ROOT_DIR SCOTCH_ROOT_DIR XDR_ROOT_DIR)
-
-WRITE_BASIC_PACKAGE_VERSION_FILE(${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
- VERSION ${${PROJECT_NAME_UC}_VERSION}
- COMPATIBILITY AnyNewerVersion)
-
+# SALOME_CONFIGURE_PREPARE(Metis ParMetis Scotch XDR CAS Qt4 CppUnit Graphviz Doxygen Sphinx MPI omniORB
+# PThread Boost libXml2 Python HDF5 MEDFile)
+
+# INCLUDE(CMakePackageConfigHelpers)
+# CONFIGURE_PACKAGE_CONFIG_FILE(${PROJECT_NAME}Config.cmake.in
+# ${PROJECT_BINARY_DIR}/to_install/${PROJECT_NAME}Config.cmake
+# INSTALL_DESTINATION "${MEDCOUPLING_INSTALL_CMAKE}_LOCAL"
+# PATH_VARS CONF_INCLUDE_DIRS MEDCOUPLING_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
+# SPHINX_ROOT_DIR METIS_ROOT_DIR PARMETIS_ROOT_DIR SCOTCH_ROOT_DIR XDR_ROOT_DIR)
+
+#WRITE_BASIC_PACKAGE_VERSION_FILE(${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
+# VERSION ${${PROJECT_NAME_UC}_VERSION}
+# COMPATIBILITY AnyNewerVersion)
+
# Install the CMake configuration files:
-INSTALL(FILES
- "${PROJECT_BINARY_DIR}/to_install/${PROJECT_NAME}Config.cmake"
- "${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake"
- DESTINATION "${SALOME_INSTALL_CMAKE_LOCAL}")
+# INSTALL(FILES
+# "${PROJECT_BINARY_DIR}/to_install/${PROJECT_NAME}Config.cmake"
+# "${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake"
+# DESTINATION "${MEDCOUPLING_INSTALL_CMAKE_LOCAL}")
# Install the export set for use with the install-tree
-INSTALL(EXPORT ${PROJECT_NAME}TargetGroup DESTINATION "${SALOME_INSTALL_CMAKE_LOCAL}"
- FILE ${PROJECT_NAME}Targets.cmake)
+#INSTALL(EXPORT ${PROJECT_NAME}TargetGroup DESTINATION "${MEDCOUPLING_INSTALL_CMAKE_LOCAL}"
+# FILE ${PROJECT_NAME}Targets.cmake)
--- /dev/null
+// Copyright (C) 2015 CEA/DEN, EDF R&D, OPEN CASCADE
+//
+// Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+// CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+//
+// 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
+//
+
+#if !defined(__MEDCOUPLING_VERSION_H__)
+#define __MEDCOUPLING_VERSION_H__
+
+/*!
+ Specify version of MEDCoupling, as follows
+
+ MEDCOUPLING_VERSION_MAJOR : (integer) number identifying major version
+ MEDCOUPLING_VERSION_MINOR : (integer) number identifying minor version
+ MEDCOUPLING_VERSION_MAINTENANCE : (integer) number identifying maintenance version
+ MEDCOUPLING_VERSION_STR : (string) complete version number "major.minor.maintenance"
+ MEDCOUPLING_VERSION : (hex) complete version number (major << 16) + (minor << 8) + maintenance
+ MEDCOUPLING_DEVELOPMENT : (integer) indicates development version when set to 1
+*/
+
+#define MEDCOUPLING_VERSION_MAJOR @MEDCOUPLING_MAJOR_VERSION@
+#define MEDCOUPLING_VERSION_MINOR @MEDCOUPLING_MINOR_VERSION@
+#define MEDCOUPLING_VERSION_MAINTENANCE @MEDCOUPLING_PATCH_VERSION@
+#define MEDCOUPLING_VERSION_STR "@MEDCOUPLING_VERSION@"
+#define MEDCOUPLING_VERSION @MEDCOUPLING_XVERSION@
+#define MEDCOUPLING_DEVELOPMENT @MEDCOUPLING_VERSION_DEV@
+
+#endif // __MEDCOUPLING_VERSION_H__
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(unix)
-ADD_SUBDIRECTORY(cmake_files)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(admlocal_cmake_DATA
- FindXDR.cmake
- FindSalomeXDR.cmake
- FindMetis.cmake
- FindSalomeMetis.cmake
- FindParMetis.cmake
- FindSalomeParMetis.cmake
- FindScotch.cmake
- FindSalomeScotch.cmake
- FindSalomeMED.cmake
- )
-
-INSTALL(FILES ${admlocal_cmake_DATA} DESTINATION ${SALOME_INSTALL_CMAKE_LOCAL})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(config_files)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(dist_admlocalm4_DATA
- ac_check_sizeof_fortran.m4
- check_GUI.m4
- check_Med.m4
- check_Med2.m4
- check_bft.m4
- check_fvm.m4
- check_metis.m4
- check_parmetis.m4
- check_scotch.m4
- med_check_sizeof_medint.m4
- renumber.m4
- splitter.m4
- with_Kernel.m4
-)
-
-FOREACH(f ${dist_admlocalm4_DATA})
- SET(DEST adm_local/unix/config_files)
- INSTALL(FILES ${f} DESTINATION ${DEST})
-ENDFOREACH(f ${dist_admlocalm4_DATA})
+++ /dev/null
-dnl Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
-dnl
-dnl This library is free software; you can redistribute it and/or
-dnl modify it under the terms of the GNU Lesser General Public
-dnl License as published by the Free Software Foundation; either
-dnl version 2.1 of the License, or (at your option) any later version.
-dnl
-dnl This library is distributed in the hope that it will be useful,
-dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
-dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-dnl Lesser General Public License for more details.
-dnl
-dnl You should have received a copy of the GNU Lesser General Public
-dnl License along with this library; if not, write to the Free Software
-dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-dnl
-dnl See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-dnl
-
-dnl define macros :
-dnl AC_ENABLE_RENUMBER AC_DISABLE_RENUMBER
-dnl author Vincent BERGEAUD
-dnl
-# AC_ENABLE_RENUMBER
-AC_DEFUN([AC_ENABLE_RENUMBER], [dnl
-define([AC_ENABLE_RENUMBER_DEFAULT], ifelse($1, yes, yes, no))dnl
-AC_ARG_ENABLE(renumber,
-changequote(<<, >>)dnl
-<< --enable-renumber[=PKGS] build with renumber tool [default=>>AC_ENABLE_RENUMBER_DEFAULT],
-changequote([, ])dnl
-[p=${PACKAGE-default}
-case "$enableval" in
-yes) enable_renumber=yes ;;
-no) enable_renumber=no ;;
-*)
- enable_renumber=no
- # Look at the argument we got. We use all the common list separators.
- IFS="${IFS= }"; ac_save_ifs="$IFS"; IFS="${IFS}:,"
- for pkg in $enableval; do
- if test "X$pkg" = "X$p"; then
- enable_renumber=yes
- fi
- done
- IFS="$ac_save_ifs"
- ;;
-esac],
-enable_renumber=AC_ENABLE_RENUMBER_DEFAULT)dnl
-
-if test "X$enable_renumber" = "Xyes"; then
- ENABLE_RENUMBER="yes"
- AC_SUBST(ENABLE_RENUMBER)
-fi
-])
-
-# AC_DISABLE_RENUMBER - set the default flag to --disable-renumber
-AC_DEFUN([AC_DISABLE_RENUMBER], [AC_ENABLE_RENUMBER(no)])
-
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(input ${CMAKE_CURRENT_SOURCE_DIR}/SALOMEconfig.h.in)
-SET(output ${CMAKE_CURRENT_BINARY_DIR}/SALOMEconfig.h)
-MESSAGE(STATUS "Creation of ${output}")
-CONFIGURE_FILE(${input} ${output})
-INSTALL(FILES ${output} DESTINATION ${SALOME_INSTALL_HEADERS})
-
-FILE(GLOB CMAKE_CONFIG_FILES "${CMAKE_CURRENT_SOURCE_DIR}/cmake_files/*.cmake")
-INSTALL(FILES ${CMAKE_CONFIG_FILES} DESTINATION ${SALOME_INSTALL_CMAKE_LOCAL})
--- /dev/null
+# Copyright (C) 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(admlocal_cmake_DATA
+ FindCppUnit.cmake
+ FindMEDFile.cmake
+ FindParMetis.cmake
+ FindSphinx.cmake
+ MEDCouplingMacros.cmake
+ FindGraphviz.cmake
+ FindMetis.cmake
+ FindScotch.cmake
+ FindXDR.cmake
+)
+
+INSTALL(FILES ${admlocal_cmake_DATA} DESTINATION ${MEDCOUPLING_INSTALL_CMAKE_LOCAL})
--- /dev/null
+# - Find CppUnit
+# Sets the following variables:
+# CPPUNIT_INCLUDE_DIRS - path to the CppUnit include directory
+# CPPUNIT_LIBRARIES - path to the CppUnit libraries to be linked against
+# CPPUNIT_DEFINITIONS - specific CppUnit definitions to be added
+#
+# The header cppunit/extensions/HelperMacros.h is looked for.
+# The following libraries are searched
+# cppunit_dll, or cppunitd_dll (Windows)
+# cppunit (Linux)
+#
+
+#########################################################################
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# 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
+#
+
+IF(NOT CppUnit_FIND_QUIETLY)
+ MESSAGE(STATUS "Looking for CppUnit ...")
+ENDIF()
+
+# Headers
+SET(CPPUNIT_ROOT_DIR $ENV{CPPUNIT_ROOT_DIR} CACHE PATH "Path to the CPPUNIT.")
+IF(CPPUNIT_ROOT_DIR)
+ LIST(APPEND CMAKE_INCLUDE_PATH "${CPPUNIT_ROOT_DIR}/include")
+ LIST(APPEND CMAKE_PROGRAM_PATH "${CPPUNIT_ROOT_DIR}/bin")
+ENDIF(CPPUNIT_ROOT_DIR)
+
+SET(CPPUNIT_INCLUDE_TO_FIND cppunit/extensions/HelperMacros.h)
+FIND_PATH(CPPUNIT_INCLUDE_DIRS ${CPPUNIT_INCLUDE_TO_FIND})
+
+# Libraries
+IF(WIN32)
+ IF(CMAKE_BUILD_TYPE STREQUAL Debug)
+ FIND_LIBRARY(CPPUNIT_LIBRARIES cppunitd_dll)
+ ELSE(CMAKE_BUILD_TYPE STREQUAL Debug)
+ FIND_LIBRARY(CPPUNIT_LIBRARIES cppunit_dll)
+ ENDIF(CMAKE_BUILD_TYPE STREQUAL Debug)
+ELSE(WIN32)
+ FIND_PROGRAM(CPPUNIT_CONFIG_BIN cppunit-config)
+ IF(NOT CPPUNIT_CONFIG_BIN)
+ MESSAGE(FATAL_ERROR "Error in CPPUNIT detection ! cppunit-config executable not found !")
+ ENDIF(NOT CPPUNIT_CONFIG_BIN)
+ EXECUTE_PROCESS(COMMAND ${CPPUNIT_CONFIG_BIN} --libs OUTPUT_VARIABLE CPPUNIT_LDFLAGS)
+ STRING(STRIP ${CPPUNIT_LDFLAGS} CPPUNIT_LDFLAGS)
+ STRING(REPLACE " " ";" LDFLAGS_LIST ${CPPUNIT_LDFLAGS})
+ FOREACH(LDFLAG ${LDFLAGS_LIST})
+ STRING(REGEX MATCH "^-L.*" LIBDIR "${LDFLAG}")
+ STRING(REGEX MATCH "^-l.*" LIB "${LDFLAG}")
+ IF(LIBDIR)
+ STRING(REGEX REPLACE "^-L" "" LIBDIR ${LIBDIR})
+ LIST(APPEND CMAKE_LIBRARY_PATH ${LIBDIR})
+ ELSEIF(LIB)
+ STRING(REGEX REPLACE "^-l" "" LIB ${LIB})
+ LIST(APPEND LIBS ${LIB})
+ ELSE()
+ MESSAGE(FATAL_ERROR "Unrecognized token \"${LDFLAG}\" in the output of cppunit-config --libs")
+ ENDIF()
+ ENDFOREACH(LDFLAG ${LDFLAGS_LIST})
+ FOREACH(LIB ${LIBS})
+ FIND_LIBRARY(CPPUNIT_SUBLIB_${LIB} ${LIB})
+ IF(NOT CPPUNIT_SUBLIB_${LIB})
+ MESSAGE(FATAL_ERROR "Error in CPPUNIT detection! Fail to locate the needed library ${LIB}!")
+ ENDIF(NOT CPPUNIT_SUBLIB_${LIB})
+ LIST(APPEND CPPUNIT_LIBRARIES ${CPPUNIT_SUBLIB_${LIB}})
+ ENDFOREACH(LIB ${LIBS})
+# MESSAGE("**** ${CPPUNIT_LIBRARIES}")
+ENDIF(WIN32)
+
+# Global variables
+SET(CPPUNIT_DEFINITIONS)
+IF(WIN32)
+ SET(CPPUNIT_DEFINITIONS -DCPPUNIT_DLL)
+ENDIF(WIN32)
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(CppUnit REQUIRED_VARS CPPUNIT_INCLUDE_DIRS CPPUNIT_LIBRARIES)
--- /dev/null
+# - Graphviz detection
+#
+# Output variables: GRAPHVIZ_EXECUTABLE - where is executable 'dot' takes place.
+# GRAPHVIZ_INCLUDE_DIRS - where to find headers.
+# GRAPHVIZ_LIBRARIES - where to get libraries.
+# GRAPHVIZ_VERSION - Graphviz version
+# GRAPHVIZ_DEFINITIONS - Graphviz definitions
+# GRAPHVIZ_FOUND - True if Graphviz was found.
+#
+###########################################################################
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# 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(GRAPHVIZ_ROOT_DIR $ENV{GRAPHVIZ_ROOT_DIR} CACHE PATH "Path to the Graphviz.")
+IF(GRAPHVIZ_ROOT_DIR)
+ LIST(APPEND CMAKE_PREFIX_PATH "${GRAPHVIZ_ROOT_DIR}")
+ENDIF(GRAPHVIZ_ROOT_DIR)
+
+FIND_PROGRAM(GRAPHVIZ_EXECUTABLE dot)
+
+FIND_PATH(GRAPHVIZ_INCLUDE_DIR NAMES graphviz/cgraph.h)
+SET(GRAPHVIZ_INCLUDE_DIRS ${GRAPHVIZ_INCLUDE_DIR} ${GRAPHVIZ_INCLUDE_DIR}/graphviz)
+
+FIND_LIBRARY(GRAPHVIZ_cdt_LIBRARY NAMES cdt PATH_SUFFIXES bin)
+FIND_LIBRARY(GRAPHVIZ_graph_LIBRARY NAMES cgraph PATH_SUFFIXES bin)
+FIND_LIBRARY(GRAPHVIZ_gvc_LIBRARY NAMES gvc PATH_SUFFIXES bin)
+FIND_LIBRARY(GRAPHVIZ_pathplan_LIBRARY NAMES pathplan PATH_SUFFIXES bin)
+
+SET(GRAPHVIZ_LIBRARIES
+ ${GRAPHVIZ_cdt_LIBRARY}
+ ${GRAPHVIZ_graph_LIBRARY}
+ ${GRAPHVIZ_gvc_LIBRARY}
+ ${GRAPHVIZ_pathplan_LIBRARY}
+ )
+
+IF(GRAPHVIZ_EXECUTABLE)
+ EXECUTE_PROCESS(COMMAND ${GRAPHVIZ_EXECUTABLE} "-V" ERROR_VARIABLE GRAPHVIZ_VERSION ERROR_STRIP_TRAILING_WHITESPACE)
+ STRING(REGEX REPLACE ".* ([0-9.]+) .*" "\\1" GRAPHVIZ_VERSION "${GRAPHVIZ_VERSION}")
+ENDIF()
+
+SET(GRAPHVIZ_DEFINITIONS)
+IF("${GRAPHVIZ_VERSION}" VERSION_LESS "2.36.0")
+ SET(GRAPHVIZ_DEFINITIONS -DWITH_CGRAPH)
+ENDIF()
+
+## Don't detect cgraph on Windows
+#IF(NOT WIN32)
+# FIND_LIBRARY(GRAPHVIZ_cgraph_LIBRARY NAMES cgraph PATH_SUFFIXES bin)
+# SET(GRAPHVIZ_LIBRARIES ${GRAPHVIZ_cgraph_LIBRARY})
+#ENDIF()
+
+# Handle the standard arguments of the find_package() command:
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Graphviz REQUIRED_VARS
+ GRAPHVIZ_EXECUTABLE
+ GRAPHVIZ_LIBRARIES
+ GRAPHVIZ_INCLUDE_DIRS)
--- /dev/null
+# - Find MED file installation
+#
+# The following variable are set:
+# MEDFILE_INCLUDE_DIRS
+# MEDFILE_LIBRARIES
+# MEDFILE_C_LIBRARIES
+# MEDFILE_F_LIBRARIES
+#
+# The CMake (or environment) variable MEDFILE_ROOT_DIR can be set to
+# guide the detection and indicate a root directory to look into.
+#
+############################################################################
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# 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
+#
+
+# ------
+
+MESSAGE(STATUS "Check for medfile ...")
+
+# ------
+
+SET(MEDFILE_ROOT_DIR $ENV{MEDFILE_ROOT_DIR} CACHE PATH "Path to the MEDFile.")
+IF(MEDFILE_ROOT_DIR)
+ LIST(APPEND CMAKE_PREFIX_PATH "${MEDFILE_ROOT_DIR}")
+ENDIF(MEDFILE_ROOT_DIR)
+
+FIND_PATH(MEDFILE_INCLUDE_DIRS med.h)
+#FIND_PROGRAM(MDUMP mdump)
+FIND_LIBRARY(MEDFILE_C_LIBRARIES NAMES medC)
+FIND_LIBRARY(MEDFILE_F_LIBRARIES NAMES med)
+IF(MEDFILE_F_LIBRARIES)
+ SET(MEDFILE_LIBRARIES ${MEDFILE_C_LIBRARIES} ${MEDFILE_F_LIBRARIES})
+ELSE(MEDFILE_F_LIBRARIES)
+ SET(MEDFILE_LIBRARIES ${MEDFILE_C_LIBRARIES})
+ENDIF(MEDFILE_F_LIBRARIES)
+
+IF(NOT MEDFILE_INCLUDE_DIRS
+ OR (NOT MEDFILE_C_LIBRARIES AND NOT MEDFILE_F_LIBRARIES))
+ MESSAGE(FATAL_ERROR "MEDFile not found; please set MEDFILE_ROOT_DIR and check target directory.")
+ENDIF()
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(MEDFile REQUIRED_VARS MEDFILE_INCLUDE_DIRS MEDFILE_LIBRARIES)
--- /dev/null
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# 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
+#
+
+# ------
+
+MESSAGE(STATUS "Check for metis ...")
+
+SET(METIS_ROOT_DIR $ENV{METIS_ROOT_DIR} CACHE PATH "Path to the METIS.")
+IF(METIS_ROOT_DIR)
+ LIST(APPEND CMAKE_LIBRARY_PATH "${METIS_ROOT_DIR}")
+ LIST(APPEND CMAKE_LIBRARY_PATH "${METIS_ROOT_DIR}/lib")
+ LIST(APPEND CMAKE_INCLUDE_PATH "${METIS_ROOT_DIR}/Lib")
+ LIST(APPEND CMAKE_INCLUDE_PATH "${METIS_ROOT_DIR}/include")
+ENDIF(METIS_ROOT_DIR)
+
+FIND_LIBRARY(METIS_LIBRARIES metis)
+FIND_PATH(METIS_INCLUDE_DIRS metis.h)
+
+IF(NOT METIS_LIBRARIES OR NOT METIS_INCLUDE_DIRS)
+ MESSAGE(FATAL_ERROR "Metis not found; please set METIS_ROOT_DIR and check target directory.")
+ENDIF()
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Metis REQUIRED_VARS METIS_INCLUDE_DIRS METIS_LIBRARIES)
+FILE(READ ${METIS_INCLUDE_DIRS}/metis.h metis_h_content)
+STRING(REPLACE "\n" ";" list_metis_h_content ${metis_h_content})
+FOREACH(ln ${list_metis_h_content})
+ IF("${ln}" MATCHES "^#define METIS_VER_MAJOR")
+ STRING(REPLACE "#define METIS_VER_MAJOR" "" metis_major_version "${ln}")
+ STRING(STRIP "${metis_major_version}" metis_major_version)
+ ENDIF("${ln}" MATCHES "^#define METIS_VER_MAJOR")
+ENDFOREACH(ln ${list_metis_h_content})
+IF(metis_major_version STREQUAL 5)
+ SET(MEDCOUPLING_METIS_V5 1)
+ MESSAGE(STATUS "Metis maj version 5 detected.")
+ELSE(metis_major_version STREQUAL 5)
+ MESSAGE(STATUS "Metis maj version 4 detected.")
+ENDIF(metis_major_version STREQUAL 5)
--- /dev/null
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# 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
+#
+
+# ------
+
+MESSAGE(STATUS "Check for parmetis ...")
+
+SET(PARMETIS_ROOT_DIR $ENV{PARMETIS_ROOT_DIR} CACHE PATH "Path to the PARMETIS.")
+IF(PARMETIS_ROOT_DIR)
+ LIST(APPEND CMAKE_PREFIX_PATH "${PARMETIS_ROOT_DIR}")
+ENDIF(PARMETIS_ROOT_DIR)
+
+FIND_LIBRARY(PARMETIS_LIBRARIES parmetis)
+FIND_LIBRARY(PARMETIS_SEQ_LIBRARIES metis)
+SET(PARMETIS_LIBRARIES ${PARMETIS_LIBRARIES} ${PARMETIS_SEQ_LIBRARIES})
+FIND_PATH(PARMETIS_INCLUDE_DIRS parmetis.h)
+
+IF(NOT PARMETIS_LIBRARIES OR NOT PARMETIS_INCLUDE_DIRS)
+ MESSAGE(FATAL_ERROR "Parallel Metis not found; please set PARMETIS_ROOT_DIR and check target directory.")
+ENDIF()
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(ParMetis REQUIRED_VARS PARMETIS_INCLUDE_DIRS PARMETIS_LIBRARIES)
--- /dev/null
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# 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
+#
+
+# ------
+
+MESSAGE(STATUS "Check for scotch ...")
+
+SET(SCOTCH_ROOT_DIR $ENV{SCOTCH_ROOT_DIR} CACHE PATH "Path to the SCOTCH.")
+IF(SCOTCH_ROOT_DIR)
+ LIST(APPEND CMAKE_PREFIX_PATH "${SCOTCH_ROOT_DIR}")
+ENDIF(SCOTCH_ROOT_DIR)
+
+FIND_LIBRARY(SCOTCH_LIBRARIES scotch)
+FIND_LIBRARY(SCOTCH_ERR_LIBRARIES scotcherr)
+SET(SCOTCH_LIBRARIES ${SCOTCH_LIBRARIES} ${SCOTCH_ERR_LIBRARIES})
+FIND_PATH(SCOTCH_INCLUDE_DIRS scotch.h PATH_SUFFIXES "/scotch")
+
+IF(NOT SCOTCH_LIBRARIES OR NOT SCOTCH_ERR_LIBRARIES OR NOT SCOTCH_INCLUDE_DIRS)
+ MESSAGE(FATAL_ERROR "Scotch not found; please set SCOTCH_ROOT_DIR and check target directory.")
+ENDIF()
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Scotch REQUIRED_VARS SCOTCH_INCLUDE_DIRS SCOTCH_LIBRARIES)
--- /dev/null
+# - Sphinx detection
+#
+# Output variables:
+# SPHINX_EXECUTABLE - path to the Sphinx executable
+# SPHINX_PYTHONPATH - path to the Sphinx Python modules
+#
+###########################################################################
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# Copyright (C) 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN,
+# CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
+#
+# 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
+#
+
+FIND_PROGRAM(SPHINX_EXECUTABLE sphinx-build PATH_SUFFIXES Scripts)
+FIND_PROGRAM(SPHINX_APIDOC_EXECUTABLE sphinx-apidoc PATH_SUFFIXES Scripts)
+
+# Get root dir locally, going up two levels from the exec:
+GET_FILENAME_COMPONENT(_tmp_ROOT_DIR "${SPHINX_EXECUTABLE}" PATH)
+GET_FILENAME_COMPONENT(_tmp_ROOT_DIR "${_tmp_ROOT_DIR}" PATH)
+IF(WIN32)
+ SET(SPHINX_PYTHONPATH "${_tmp_ROOT_DIR}/lib/site-packages")
+ELSE()
+ SET(SPHINX_PYTHONPATH "${_tmp_ROOT_DIR}/lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages")
+ENDIF()
+# Handle the standard arguments of the find_package() command:
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(Sphinx REQUIRED_VARS SPHINX_EXECUTABLE SPHINX_APIDOC_EXECUTABLE)
--- /dev/null
+# Copyright (C) 2007-2015 CEA/DEN, EDF R&D, OPEN CASCADE
+#
+# 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
+#
+
+MESSAGE(STATUS "Check for XDR ...")
+
+FIND_PATH(XDR_INCLUDE_DIRS rpc/xdr.h)
+SET(XDR_DEFINITIONS "-DHAS_XDR")
+
+IF(WIN32)
+ FIND_LIBRARY(XDR_LIBRARIES xdr) # To get the .lib file from XDR
+ FIND_PATH(XDR_INCLUDE_DIRS2 stdint.h PATH_SUFFIXES src/msvc) # To get the stdint.h from XDR (needed by types.h)
+ IF(XDR_INCLUDE_DIRS)
+ IF(XDR_INCLUDE_DIRS2)
+ LIST(APPEND XDR_INCLUDE_DIRS "${XDR_INCLUDE_DIRS2}")
+ ELSE()
+ SET(XDR_INCLUDE_DIRS "${XDR_INCLUDE_DIRS2}") # Make the detection fail
+ ENDIF()
+ ENDIF()
+ENDIF(WIN32)
+
+INCLUDE(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(XDR REQUIRED_VARS XDR_INCLUDE_DIRS)
--- /dev/null
+# Copyright (C) 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
+#
+
+####################################################################
+# _TOHEXA()
+# Convert a number (smaller than 16) into hexadecimal representation
+# with a leading 0.
+MACRO(_TOHEXA num result)
+ SET(_hexa_map a b c d e f)
+ IF(${num} LESS 10)
+ SET(${result} "0${num}")
+ ELSE()
+ MATH(EXPR _res "${num}-10" )
+ LIST(GET _hexa_map ${_res} _out)
+ SET(${result} "0${_out}")
+ ENDIF()
+ENDMACRO(_TOHEXA)
+
+####################################################################
+# MEDCOUPLING_XVERSION()
+#
+# Computes hexadecimal version of MEDCOUPLING package
+#
+# USAGE: MEDCOUPLING_XVERSION(package)
+#
+# ARGUMENTS:
+#
+# package: IN: MEDCOUPLING package name
+#
+# The macro reads MEDCOUPLING package version from PACKAGE_VERSION variable
+# (note package name are uppercase);
+# hexadecimal version value in form 0xAABBCC (where AA, BB and CC are
+# major, minor and maintenance components of package version in
+# hexadecimal form) is put to the PACKAGE_XVERSION variable
+MACRO(MEDCOUPLING_XVERSION pkg)
+ STRING(TOUPPER ${pkg} _pkg_UC)
+ IF(${_pkg_UC}_VERSION)
+ SET(_major)
+ SET(_minor)
+ SET(_patch)
+ _TOHEXA(${${_pkg_UC}_MAJOR_VERSION} _major)
+ _TOHEXA(${${_pkg_UC}_MINOR_VERSION} _minor)
+ _TOHEXA(${${_pkg_UC}_PATCH_VERSION} _patch)
+ SET(${_pkg_UC}_XVERSION "0x${_major}${_minor}${_patch}")
+ ENDIF()
+ENDMACRO(MEDCOUPLING_XVERSION)
ADD_SUBDIRECTORY(user)
ADD_SUBDIRECTORY(tutorial)
-ADD_SUBDIRECTORY(dev)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(sphinx)
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-<XMI verified="false" xmi.version="1.2" timestamp="2012-11-06T17:59:15" xmlns:UML="http://schema.omg.org/spec/UML/1.3">
- <XMI.header>
- <XMI.documentation>
- <XMI.exporter>umbrello uml modeller http://uml.sf.net</XMI.exporter>
- <XMI.exporterVersion>1.5.8</XMI.exporterVersion>
- <XMI.exporterEncoding>UnicodeUTF8</XMI.exporterEncoding>
- </XMI.documentation>
- <XMI.metamodel xmi.version="1.3" href="UML.xml" xmi.name="UML"/>
- </XMI.header>
- <XMI.content>
- <UML:Model isSpecification="false" isAbstract="false" isLeaf="false" xmi.id="m1" isRoot="false" name="Modèle UML">
- <UML:Namespace.ownedElement>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="folder" name="folder"/>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="datatype" name="datatype"/>
- <UML:Stereotype visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="interface" name="interface"/>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Logical View" name="Logical View">
- <UML:Namespace.ownedElement>
- <UML:Package stereotype="folder" visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Datatypes" name="Datatypes">
- <UML:Namespace.ownedElement>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ZPqOwG3ZaJgC" name="int"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="WVv63G5f9uiL" name="char"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="dHU5JP7qmxEj" name="bool"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CIGkZvv5QqCT" name="float"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="7F8E7oZk44nN" name="double"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="RuDDqPu2fBmF" name="short"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="6hIUWSwdh4po" name="long"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rMXvQKIpDT33" name="unsigned int"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="qx3W6plAV1f1" name="unsigned short"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Ubc9dPySlTNA" name="unsigned long"/>
- <UML:DataType stereotype="datatype" visibility="public" isSpecification="false" namespace="Datatypes" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="ndz0601vw4R2" name="string"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="NBqMfPwp0LlT" name="MEDOP">
- <UML:Namespace.ownedElement>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="KO9M6BTsmDX3" name="DatasourceHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="IDqrnmQNZzdi" type="ZPqOwG3ZaJgC" name="sourceid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="eazbSktruFv5" type="ndz0601vw4R2" name="name"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="Js2a6sRrdpCC" type="ndz0601vw4R2" name="uri"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="mpuQQtzqbsfV" name="MeshHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="6bYmLOgeEiEK" type="ZPqOwG3ZaJgC" name="meshid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="MMCAGaa7ZOiQ" type="ndz0601vw4R2" name="name"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="4CWdiGy6waJd" type="ZPqOwG3ZaJgC" name="sourceid"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Z3sQfH0YJ5g6" name="FieldHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="o3IdSrqOde12" type="ZPqOwG3ZaJgC" name="fieldid"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="HICpfJOiAmOR" type="ZPqOwG3ZaJgC" name="type"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="kwipcobg6E6w" type="ZPqOwG3ZaJgC" name="iteration"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="5UZhTZzlr9YW" type="ZPqOwG3ZaJgC" name="order"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="RuFbeb0OViC7" type="ZPqOwG3ZaJgC" name="meshid"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="tFFeytJRMARL" name="FieldseriesHandler">
- <UML:Classifier.feature>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="OKYFoL4febk2" type="ZPqOwG3ZaJgC" name="fieldseriesId"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="dZ9FP4RHHevG" type="ZPqOwG3ZaJgC" name="type"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="VEhrN6DlOlzB" type="ZPqOwG3ZaJgC" name="nbIterations"/>
- <UML:Attribute visibility="public" isSpecification="false" xmi.id="41qibbiE8sRX" type="ZPqOwG3ZaJgC" name="meshId"/>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="kG3S8XATRqib" name="Factory">
- <UML:Classifier.feature>
- <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="CS8eIf5ejE39" name="getDataManager">
- <UML:BehavioralFeature.parameter>
- <UML:Parameter kind="return" xmi.id="HO3Z38DlLEsc" type="nSHVdoPkDYFK"/>
- </UML:BehavioralFeature.parameter>
- </UML:Operation>
- <UML:Operation visibility="public" isSpecification="false" isQuery="false" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="52BLkz1CzFrG" name="getCalculator">
- <UML:BehavioralFeature.parameter>
- <UML:Parameter kind="return" xmi.id="UD4jBGoER8yQ" type="UsXTM49RP2EE"/>
- </UML:BehavioralFeature.parameter>
- </UML:Operation>
- </UML:Classifier.feature>
- </UML:Class>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="nSHVdoPkDYFK" name="DataManager"/>
- <UML:Class visibility="public" isSpecification="false" namespace="NBqMfPwp0LlT" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="UsXTM49RP2EE" name="Calculator"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="waq19EhXGt1t" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="aIpeEQxrDZ1d" type="KO9M6BTsmDX3" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="n" xmi.id="KLQQ3Six0Wy7" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="SJsPpluxXW2y" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="uGVzTJNdzM70" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="L0i3AAwcTp0I" type="KO9M6BTsmDX3" name="sourceid" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ld0pX3I6kldh" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="UVr0zGsErWnr" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="tIX5O3q7eqxB" type="mpuQQtzqbsfV" name="meshId" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="oCVhQ0u5qFB3" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="yYmvjqxZZY8F" type="Z3sQfH0YJ5g6" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="0" xmi.id="kG5Bo02aCVGa" type="tFFeytJRMARL" name="fieldseriesId" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="ONJtNJsd01tV" name="">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="n" xmi.id="5vXlBV761AlS" type="tFFeytJRMARL" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="uYDM7AmTV5Lr" type="mpuQQtzqbsfV" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Package visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="rEjTH3dMz3kh" name="SALOME">
- <UML:Namespace.ownedElement>
- <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="BYw7PBW7PaZW" comment="SALOME CORBA Object that can be requested using the lyfe cycle corba registry" name="EngineComponent"/>
- <UML:Interface stereotype="interface" visibility="public" isSpecification="false" namespace="rEjTH3dMz3kh" isAbstract="true" isLeaf="false" isRoot="false" xmi.id="tDJT9A2gh9I3" comment="Standard SALOME CORBA Object" name="GenericObject"/>
- </UML:Namespace.ownedElement>
- </UML:Package>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="BYw7PBW7PaZW" xmi.id="OOxclE0ol1ww" client="kG3S8XATRqib" name=""/>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="fUBIKo7DA4LI" name="instancie">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="FsZMpwZ9gj4C" type="kG3S8XATRqib" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="50TAtgDYAPqS" type="nSHVdoPkDYFK" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="DweL0xdEpAae" name="instancie">
- <UML:Association.connection>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="false" isSpecification="false" multiplicity="1" xmi.id="5AnlrsvxqO7j" type="kG3S8XATRqib" name="" aggregation="none"/>
- <UML:AssociationEnd changeability="changeable" visibility="public" isNavigable="true" isSpecification="false" multiplicity="1" xmi.id="4JHDg6ft0HE0" type="UsXTM49RP2EE" name="" aggregation="none"/>
- </UML:Association.connection>
- </UML:Association>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="WqUPF7X6LpZS" client="nSHVdoPkDYFK" name=""/>
- <UML:Abstraction visibility="public" isSpecification="false" namespace="Logical View" supplier="tDJT9A2gh9I3" xmi.id="AwSTl1vib2NJ" client="UsXTM49RP2EE" name=""/>
- </UML:Namespace.ownedElement>
- <XMI.extension xmi.extender="umbrello">
- <diagrams>
- <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDOP_datamodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="644" canvaswidth="1201" localid="" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#000000" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffff00" zoom="100" xmi.id="yesp3EjZ9T3u" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
- <widgets>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="261" showattsigs="601" showstereotype="1" y="101" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="193" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="KO9M6BTsmDX3" showscope="1" height="67" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="273" showattsigs="601" showstereotype="1" y="220" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="155" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="mpuQQtzqbsfV" showscope="1" height="67" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="268" showattsigs="601" showstereotype="1" y="371" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="150" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="Z3sQfH0YJ5g6" showscope="1" height="97" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="574" showattsigs="601" showstereotype="1" y="218" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="190" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tFFeytJRMARL" showscope="1" height="82" showopsigs="601"/>
- <notewidget width="170" showstereotype="1" x="703" noteType="0" usesdiagramusefillcolor="1" y="278" usesdiagramfillcolor="1" isinstance="0" fillcolor="none" height="79" linecolor="none" xmi.id="IxOvY2fRkpkU" usefillcolor="1" linewidth="none" font="Ubuntu,10,-1,5,50,0,0,0,0,0" text="A Fieldseries is a data structure gathering a sequence of fields of same type."/>
- </widgets>
- <messages/>
- <associations>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="mpuQQtzqbsfV" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="SJsPpluxXW2y" widgetbid="KO9M6BTsmDX3" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="323" starty="220"/>
- <endpoint endx="323" endy="168"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="199" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="PUeF5c2aIZmS" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="325" showstereotype="1" y="170" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="UmnXhmcg0z5Y" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="260" showstereotype="1" y="170" text="sourceid" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="67" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zENRazZ7qpS9" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ld0pX3I6kldh" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="318" starty="371"/>
- <endpoint endx="318" endy="287"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="350" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="84EPeyr6icdP" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="320" showstereotype="1" y="289" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="OF6MD9u7mXqC" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="264" showstereotype="1" y="289" text="meshId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="59" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdfkS5upaY4d" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="Z3sQfH0YJ5g6" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="oCVhQ0u5qFB3" widgetbid="tFFeytJRMARL" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="418" starty="371"/>
- <endpoint endx="574" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="408" showstereotype="1" y="349" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="wdocFP2bd6xq" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="570" showstereotype="1" y="303" text="0" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Fpv0KlCvTC4k" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="487" showstereotype="1" y="282" text="fieldseriesId" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="+" role="710" width="90" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="bkz9G4mP6yoi" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="tFFeytJRMARL" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="2" xmi.id="ONJtNJsd01tV" widgetbid="mpuQQtzqbsfV" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="574" starty="246"/>
- <endpoint endx="428" endy="246"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="556" showstereotype="1" y="225" text="n" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="Ep7Inv1iWpKl" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="430" showstereotype="1" y="225" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="FKMsQHge4ZeM" height="19"/>
- </assocwidget>
- </associations>
- </diagram>
- <diagram showopsig="1" linecolor="#ff0000" snapx="10" showattribassocs="1" snapy="10" linewidth="0" showattsig="1" isopen="1" showpackage="1" showpubliconly="1" showstereotype="1" name="MEDOP_componentmodel" font="Ubuntu,10,-1,5,50,0,0,0,0,0" canvasheight="436" canvaswidth="596" localid="-1" snapcsgrid="0" showgrid="0" showops="1" griddotcolor="#808080" backgroundcolor="#ffffff" usefillcolor="1" fillcolor="#ffffc0" zoom="100" xmi.id="e3MA5ySQiAqG" documentation="" showscope="1" snapgrid="0" showatts="1" type="1">
- <widgets>
- <classwidget linecolor="#ff0000" usesdiagramfillcolor="0" linewidth="none" showoperations="1" usesdiagramusefillcolor="0" showpubliconly="1" showpackage="1" x="330" showattsigs="601" showstereotype="1" y="184" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="227" isinstance="0" usefillcolor="1" fillcolor="#ffffc0" xmi.id="kG3S8XATRqib" showscope="1" height="52" showopsigs="601"/>
- <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="342" showstereotype="1" y="87" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="184" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="BYw7PBW7PaZW" showscope="1" height="44" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="459" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="133" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="UsXTM49RP2EE" showscope="1" height="29" showopsigs="601"/>
- <classwidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="254" showattsigs="601" showstereotype="1" y="300" showattributes="1" font="Ubuntu,10,-1,5,75,0,0,0,0,0" width="153" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="nSHVdoPkDYFK" showscope="1" height="29" showopsigs="601"/>
- <interfacewidget linecolor="none" usesdiagramfillcolor="1" linewidth="none" showoperations="1" usesdiagramusefillcolor="1" showpubliconly="1" showpackage="1" x="367" showstereotype="1" y="388" font="Ubuntu,10,-1,5,75,1,0,0,0,0" drawascircle="0" width="160" isinstance="0" usefillcolor="1" fillcolor="none" xmi.id="tDJT9A2gh9I3" showscope="1" height="44" showopsigs="601"/>
- </widgets>
- <messages/>
- <associations>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="OOxclE0ol1ww" widgetbid="BYw7PBW7PaZW" totalcountb="2" type="511" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="432" starty="184"/>
- <endpoint endx="432" endy="131"/>
- </linepath>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="1" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="1" fillcolor="none" linecolor="none" totalcounta="3" xmi.id="fUBIKo7DA4LI" widgetbid="nSHVdoPkDYFK" totalcountb="2" type="512" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="362" starty="236"/>
- <endpoint endx="362" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="362" showstereotype="1" y="268" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="yMxCnWyqPM7m" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="zDAFam9Z1k5N" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="364" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="HoH1ErvACtMz" height="19"/>
- </assocwidget>
- <assocwidget indexa="2" indexb="1" usesdiagramusefillcolor="0" widgetaid="kG3S8XATRqib" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="3" xmi.id="DweL0xdEpAae" widgetbid="UsXTM49RP2EE" totalcountb="2" type="512" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="508" starty="236"/>
- <endpoint endx="508" endy="300"/>
- </linepath>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="508" showstereotype="1" y="269" text="instancie" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="703" width="62" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="NJokfvWe6hrg" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="238" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="701" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="RyGQiJny75zJ" height="19"/>
- <floatingtext linecolor="none" usesdiagramfillcolor="1" linewidth="none" usesdiagramusefillcolor="1" x="510" showstereotype="1" y="279" text="1" font="Ubuntu,10,-1,5,50,0,0,0,0,0" pretext="" role="702" width="16" isinstance="0" posttext="" usefillcolor="1" fillcolor="none" xmi.id="usT4lq477qrk" height="19"/>
- </assocwidget>
- <assocwidget indexa="1" indexb="1" usesdiagramusefillcolor="0" widgetaid="nSHVdoPkDYFK" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="WqUPF7X6LpZS" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="0" linewidth="none">
- <linepath>
- <startpoint startx="398" starty="329"/>
- <endpoint endx="398" endy="388"/>
- </linepath>
- </assocwidget>
- <assocwidget indexa="1" indexb="2" usesdiagramusefillcolor="0" widgetaid="UsXTM49RP2EE" usesdiagramfillcolor="0" fillcolor="#000000" linecolor="none" totalcounta="2" xmi.id="AwSTl1vib2NJ" widgetbid="tDJT9A2gh9I3" totalcountb="3" type="511" usefillcolor="1" linewidth="none">
- <linepath>
- <startpoint startx="510" starty="329"/>
- <endpoint endx="510" endy="388"/>
- </linepath>
- </assocwidget>
- </associations>
- </diagram>
- </diagrams>
- </XMI.extension>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Use Case View" name="Use Case View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Component View" name="Component View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Deployment View" name="Deployment View">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- <UML:Model stereotype="folder" visibility="public" isSpecification="false" namespace="m1" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="Entity Relationship Model" name="Entity Relationship Model">
- <UML:Namespace.ownedElement/>
- </UML:Model>
- </UML:Namespace.ownedElement>
- </UML:Model>
- </XMI.content>
- <XMI.extensions xmi.extender="umbrello">
- <docsettings viewid="e3MA5ySQiAqG" uniqueid="1YG8dfUmZuFJ" documentation=""/>
- <listview>
- <listitem open="1" type="800" id="Views">
- <listitem open="1" type="836" id="Entity Relationship Model"/>
- <listitem open="1" type="802" id="Use Case View"/>
- <listitem open="1" type="821" id="Component View"/>
- <listitem open="1" type="827" id="Deployment View"/>
- <listitem open="1" type="801" id="Logical View">
- <listitem open="0" type="818" id="NBqMfPwp0LlT">
- <listitem open="1" type="813" id="UsXTM49RP2EE"/>
- <listitem open="1" type="813" id="nSHVdoPkDYFK"/>
- <listitem open="0" type="813" id="KO9M6BTsmDX3">
- <listitem open="0" type="814" id="eazbSktruFv5"/>
- <listitem open="1" type="814" id="IDqrnmQNZzdi"/>
- <listitem open="0" type="814" id="Js2a6sRrdpCC"/>
- </listitem>
- <listitem open="1" type="813" id="kG3S8XATRqib">
- <listitem open="0" type="815" id="52BLkz1CzFrG"/>
- <listitem open="0" type="815" id="CS8eIf5ejE39"/>
- </listitem>
- <listitem open="0" type="813" id="Z3sQfH0YJ5g6">
- <listitem open="0" type="814" id="o3IdSrqOde12"/>
- <listitem open="0" type="814" id="kwipcobg6E6w"/>
- <listitem open="0" type="814" id="RuFbeb0OViC7"/>
- <listitem open="0" type="814" id="5UZhTZzlr9YW"/>
- <listitem open="0" type="814" id="HICpfJOiAmOR"/>
- </listitem>
- <listitem open="0" type="813" id="tFFeytJRMARL">
- <listitem open="0" type="814" id="OKYFoL4febk2"/>
- <listitem open="0" type="814" id="41qibbiE8sRX"/>
- <listitem open="0" type="814" id="VEhrN6DlOlzB"/>
- <listitem open="0" type="814" id="dZ9FP4RHHevG"/>
- </listitem>
- <listitem open="0" type="813" id="mpuQQtzqbsfV">
- <listitem open="0" type="814" id="6bYmLOgeEiEK"/>
- <listitem open="0" type="814" id="MMCAGaa7ZOiQ"/>
- <listitem open="0" type="814" id="4CWdiGy6waJd"/>
- </listitem>
- </listitem>
- <listitem open="0" type="807" id="e3MA5ySQiAqG" label="MEDOP_componentmodel"/>
- <listitem open="0" type="807" id="yesp3EjZ9T3u" label="MEDOP_datamodel"/>
- <listitem open="0" type="818" id="rEjTH3dMz3kh">
- <listitem open="1" type="817" id="BYw7PBW7PaZW"/>
- <listitem open="1" type="817" id="tDJT9A2gh9I3"/>
- </listitem>
- <listitem open="0" type="830" id="Datatypes">
- <listitem open="1" type="829" id="dHU5JP7qmxEj"/>
- <listitem open="1" type="829" id="WVv63G5f9uiL"/>
- <listitem open="1" type="829" id="7F8E7oZk44nN"/>
- <listitem open="1" type="829" id="CIGkZvv5QqCT"/>
- <listitem open="1" type="829" id="ZPqOwG3ZaJgC"/>
- <listitem open="1" type="829" id="6hIUWSwdh4po"/>
- <listitem open="1" type="829" id="RuDDqPu2fBmF"/>
- <listitem open="1" type="829" id="ndz0601vw4R2"/>
- <listitem open="1" type="829" id="rMXvQKIpDT33"/>
- <listitem open="1" type="829" id="Ubc9dPySlTNA"/>
- <listitem open="1" type="829" id="qx3W6plAV1f1"/>
- </listitem>
- </listitem>
- </listitem>
- </listview>
- <codegeneration>
- <codegenerator language="C++"/>
- </codegeneration>
- </XMI.extensions>
-</XMI>
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SALOME_CONFIGURE_FILE(conf.py.in conf.py)
-
-SET(_cmd_options -c ${CMAKE_CURRENT_BINARY_DIR} -b html -d doctrees -D latex_paper_size=a4 ${CMAKE_CURRENT_SOURCE_DIR} html)
-SALOME_GENERATE_ENVIRONMENT_SCRIPT(_cmd env_script "${SPHINX_EXECUTABLE}" "${_cmd_options}")
-
-ADD_CUSTOM_TARGET(dev_docs ALL COMMAND ${_cmd})
-
-#INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target dev_docs)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${SALOME_INSTALL_DOC}/dev/MED)
-
-SET(make_clean_files html doctrees)
-SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${make_clean_files}")
+++ /dev/null
-@import url("classic.css");
-
-body {
- font-family: {{ 'Liberation', sans-serif }};
- font-size: 82%;
- color: #000;
- background-color: #fff;
- margin-left: 28px;
-}
-
-ul {
- margin: 0 0 0 0;
-}
-
-div.related {
- background-color: #444;
-}
-
-a,
-div.sphinxsidebar h3 a,
-div.sphinxsidebar a,
-div.footer a {
- color: #444;
-}
-
-div.sphinxsidebar h3,
-div.sphinxsidebar h4 {
- color: #000;
-}
-
-div.sphinxsidebar ul {
- font-size: 94%;
- color: #000;
-}
-
-div.sphinxsidebar input {
- border-color: #444;
-}
-
-div.document {
- background-color: #f5f8e4;
-}
-
-div.body h1,
-div.body h2,
-div.body h3,
-div.body h4,
-div.body h5,
-div.body h6 {
- color: #000;
- background-color: transparent;
- border-bottom: 1px solid #444;
-}
-
-div.footer {
- color: #000;
-}
-
-li.toctree-l2 {
- font-size: 100%;
-}
-
-li.toctree-l3 {
- font-size: 100%;
-}
-
-div.sphinxsidebarwrapper ul {
- list-style-type: disc;
- margin-top: 1px;
- padding-left: 6px;
-}
-
-div.sphinxsidebarwrapper h3 {
- font-size: 100%;
- font-weight: bold;
-}
-
-div.body h1 {
- font-size: 200%;
-}
-div.body h2 {
- font-size: 160%;
-}
-div.body h3, div.body h4 {
- font-size: 125%;
-}
-
-div.body p.topic-title {
- margin-bottom: 2px;
- font-size: 100%;
-}
-
-div.sphinxsidebar p {
- color: #444;
-}
-
-#introduction p > em {
- text-align: right;
- float: right;
-}
-
-#introduction p {
- font-size: 90%;
- margin-bottom: 3px;
-}
-
-#introduction #id2.docutils.footnote {
- font-size: 70%;
- margin-top: 25px;
-}
-
-#introduction table.docutils.footnote {
- font-size: 70%;
- margin-top: 5px;
-}
-
-
-.tt {
- font-family:"Courier New",Courier,monospace;
-}
-.strike {
- text-decoration: line-through;
-}
-
-.bolditalic {
- font-style:italic;
- font-weight:bold
-}
-
-.underline {
- text-decoration:underline;
-}
-
-.tag {
- font-family:"Courier New",Courier,monospace;
-}
-
-.tagb {
- font-family:"Courier New",Courier,monospace;
- font-weight:bold
-}
-
-.todo {
- background-color:yellow;
-}
-
-.warn {
- background-color:#FFE4E4;
-}
-
-.info {
- background-color:#EEEEEE;
-}
-
-.date {
- font-family:"Courier New",Courier,monospace;
- font-style:italic;
-}
-
+++ /dev/null
-# -*- 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 = 'classic'
-html_theme_options = {
- "stickysidebar": "false",
- "rightsidebar": "false",
-}
-
-# Add any paths that contain custom themes here, relative to this directory.
-#html_theme_path = ['themes']
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# "<project> v<release> documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# The name of an image file (within the static path) to use as favicon of the
-# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
-# pixels large.
-#html_favicon = None
-
-
-# The stylecheet file will be searched within the static path, while
-# the layout.html file will be searched within the template path
-# (Note that this parameter can't be used together with html_theme. Exclusive)
-html_style = 'medop.css'
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = [os.path.join('@CMAKE_CURRENT_SOURCE_DIR@','_static')]
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-#html_last_updated_fmt = '%b %d, %Y'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-#html_sidebars = {}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-#html_additional_pages = {}
-
-# If false, no module index is generated.
-html_use_modindex = False
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, the reST sources are included in the HTML build as _sources/<name>.
-html_copy_source = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a <link> tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = ''
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'medopdoc'
-
-
-# Options for LaTeX output
-# ------------------------
-
-latex_elements = {
- # The paper size ('letterpaper' or 'a4paper').
- 'papersize': 'a4paper',
- # Select another font family
- #'fontpkg':'\\usepackage{eucal}',
- # get rid off blank pages
- 'classoptions': ',openany,oneside',
- 'babel' : '\\usepackage[english]{babel}',
- # The font size ('10pt', '11pt' or '12pt').
- #'pointsize': '10pt',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title, author, document class [howto/manual]).
-latex_documents = [
- ('index', 'medop-alldoc.tex', 'Documentation du module MED', 'G. Boulant', 'manual'),
- ('medop-specifications', 'medop-specifications.tex', 'Module MED - Specifications', 'G. Boulant', 'manual'),
- ('medop-develguide', 'medop-develguide.tex', 'Module MED - Guide de developpement', 'G. Boulant', 'manual'),
- ('medop-userguide-gui', 'medop-userguide-gui.tex', 'Module MED - Guide d\'utilisation de l\'interface graphique', 'G. Boulant', 'howto'),
- ('medop-userguide-api', 'medop-userguide-api.tex', 'MEDMEM library - Starter guide for users', 'G. Boulant', 'howto')
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-latex_logo = os.path.join("@CMAKE_CURRENT_SOURCE_DIR@","_static","head.png")
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-latex_use_parts = True
-
-# Additional stuff for the LaTeX preamble.
-#latex_preamble = ''
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-latex_use_modindex = False
-
-# Definition of substitute variables for rst texts
-# ------------------------------------------------
-# The rst_epilog can be used to define variable in conf.py and use the
-# values of these variables in the rst text files.
-srcdir = '@CMAKE_CURRENT_SOURCE_DIR@'
-rst_epilog = '.. |SPHINXDOC_SRCDIR| replace:: %s' % srcdir
+++ /dev/null
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%
- Documentation du module MED
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module SALOME MED (pour Modèle d'Echange de Données) fournit la
-bibliothèque MEDCoupling (bibliothèque C++ dédiée à la manipulation de
-maillages et de champs conformes au modèle MED), ainsi qu'une
-interface graphique pour la réalisation des opérations de manipulation
-les plus usuelles.
-
-Documentation de référence
-==========================
-
-**Documentation d'utilisation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-userguide-gui.rst
- medop-userguide-api.rst
-
-**Documentation technique**
-
-.. toctree::
- :maxdepth: 1
-
- medop-specifications.rst
- medop-develguide.rst
-
-**Documentation annexe**
-
-.. toctree::
- :maxdepth: 1
-
- medop-references.rst
-
-Archives documentaires
-======================
-
-**Documentation du prototype 2010**
-
-Cette section décrit le prototype mis au point en 2010 pour les
-analyses de conception (maquette 2010 sur base MEDMEM)
-
-.. toctree::
- :maxdepth: 1
-
- medop-prototype-overview.rst
- medop-prototype-develguide.rst
- medop-prototype-medmem.rst
-
-**Journal de travail**
-
-.. toctree::
- :maxdepth: 1
-
- medop-workingnotes-2010.rst
- medop-workingnotes-2011.rst
- medop-workingnotes-2012.rst
+++ /dev/null
-.. AVERTISSEMENT:
-.. Ce fichier contient les définitions globales à la documentation. Il
-.. peut être inclu au moyen de la directive rst "include" pour
-.. disposer des définitions dans le fichier qui fait l'inclusion.
-.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
-.. il est interdit de faire afficher du texte par ce document de
-.. définition.
-
-.. REFERENCES DOCUMENTAIRES:
-.. (les documents sont fournis dans le répertoire _static/documents)
-
-.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
-.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
-.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
-
-.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
-.. |REF_CEA_VBE_MEDMEM| replace:: Guide utilisateur de MED mémoire
-.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
-.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
-.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
-.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
-.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
-.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
-.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
-.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
-.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
-.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
-.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
-
-.. PRESENTATIONS:
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
-.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
-.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
-.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
-.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
-.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
-.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
-.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
-.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
-
-
-
-.. LIENS EXTERNES:
-.. (l'accès nécessite le réseau intranet EDF et internet)
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
-.. |LINK_EDF_MEDDOC| replace:: Modèle MED
-.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
-.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
-.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
-
-.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
-.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
-.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
-
-.. RENVOIES:
-
-.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
-.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
-
-
-.. SNAPSHOTS:
-
-.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
-.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
-
-.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
-.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
-
-.. |XMED_USERGUIDE_PDF| replace:: version pdf
-.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
-
-
-.. =========================================================
-.. Rendering roles
-.. =========================================================
-.. This role can be used to display monospace text (code)
-.. role:: tt
- :class: tt
-
-.. role:: strike
- :class: strike
-
-.. role:: bolditalic
- :class: bolditalic
-
-.. role:: underline
- :class: underline
-
-.. role:: tag
- :class: tag
-
-.. role:: tagb
- :class: tagb
-
-.. role:: todo
- :class: todo
-
-.. role:: date
- :class: date
-
-.. role:: warn
- :class: warn
-
-.. role:: info
- :class: info
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med, développement
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide de développement du composant MEDOP
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le composant logiciel MEDOP est un élément du module MED. Il fournit
-une interface utilisateur pour la manipulation de maillages et de
-champs, composée d'une interface texte (TUI) et d'une interface
-graphique (GUI). L'interface graphique constitue l'interface graphique
-du module MED.
-
-Ce document est la documentation technique du composant MEDOP. Il
-fournit les instructions à suivre pour installer le composant en vue
-d'un travail de développement, puis décrit les éléments de conception.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Mise en place de l'espace de développement
-==========================================
-
-Gestion de configuration du composant MEDOP
--------------------------------------------
-
-Le composant logiciel MEDOP est un package du module SALOME MED,
-hébergé dans l'espace source au niveau du sous-répertoire
-`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le
-module SALOME MED.
-
-Organisation des sources du composant MEDOP
--------------------------------------------
-
-Le répertoire source `src/MEDOP` distingue les sous-répertoires
-suivants:
-
-* cmp: package containing the SALOME components
-* tui: package containing the python user interface
-* gui: package containing the graphical user interface (the GUI part
- of the MED module)
-* res: resources files associated to the MEDOP package (icons, config
- files, data files, ...)
-* exe: additional executable programs that can be launched from the
- MEDOP framework
-
-Construction du composant MEDOP
--------------------------------
-
-Intégré à la construction du module MED. Le composant MEDOP dépend de
-MEDCoupling et MEDLoader uniquement.
-
-Exécution des tests unitaires du composant MEDOP
-------------------------------------------------
-
-Les tests unitaires peuvent être exécutés au moyen de scripts python
-lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
-
- $ ./appli/runSession
- [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py
-
-L'exécution imprime un rapport détaillant le résultat pour chaque
-fonction de test::
-
- test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
- test_Calculator_basics (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
- test_addDatasource (__main__.MyTestSuite) ... ok
- test_getDataManager (__main__.MyTestSuite) ... ok
- test_getFieldHandlerList (__main__.MyTestSuite) ... ok
- test_getFieldRepresentation (__main__.MyTestSuite) ... ok
- test_markAsPersistent (__main__.MyTestSuite) ... ok
- test_saveFields (__main__.MyTestSuite) ... ok
- test_updateFieldMetadata (__main__.MyTestSuite) ... ok
-
-Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
-
-* ``test_medop_components.py``: test les composants SALOME développés pour
- la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
-* ``test_xmed_fieldOperations.py``: test des operations de champs telles
- qu'elles sont mises en oeuvre depuis l'interface textuelle.
-* ``test_xmed_uiEventListener.py``: test du système de notification
- d'évènements des composants vers la partie gui du module MED.
-* ``test_xmed_visualisation.py``: test du système de visualisation
- des champs tel que piloté depuis le module MED.
-
-Architecture du module XMED
-===========================
-
-Le module MED pour la manipulation de champs est composé de:
-
-* une bibliothèque de fonctions pour le traitement de données sur des
- maillages et des champs conformes au modèle MED (package
- MEDCoupling, MEDLoader et REMAPPER);
-* une interface graphique pour la mise en oeuvre des cas standard de
- manipulation de champs;
-* une ensemble d'outils pour intervenir sur des fichiers au format
- MED.
-
-Une bibliothèque de fonctions pour le traitement de données
------------------------------------------------------------
-
-La figure ci-dessous montre la structure des paquets logiciels qui
-constituent la bibliothèque:
-
-.. image:: images/medlayers.png
- :align: center
-
-Elle comprend en particulier les paquets suivants:
-
-* MEDCoupling: qui décrit les structures de données pour porter les
- maillages et les champs
-* MEDLoader: qui fournit les fonctions de persistence sous forme de
- fichiers au format MED (lecture et écriture).
-* REMAPPER:
-
-Il est important de noter que MEDCoupling n'a aucune dépendance
-logicielle autre que la bibliothèque C++ standard. Ceci permet
-d'envisager son implantation dans un code de calcul ou un outil de
-traitement sans tirer l'ensemble pré-requis de SALOME.
-
-Une interface graphique pour l'exécution des cas standard
----------------------------------------------------------
-
-
-Un ensemble d'outils pour le traitement de fichiers
----------------------------------------------------
-
-
-Description des composants
-==========================
-
-MEDDataManager - Le gestionnaire des données de session
--------------------------------------------------------
-
-Le composant MEDDataManager s'occupe de fournir les données MED sur
-demande des interfaces clientes, en particulier pour module de
-pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
-en général elle proviennent d'un fichier au format med contenant des
-champs définis sur des maillages. Les données sont identifiées à la
-lecture des métadonnées de description dans le fichiers med, puis les
-valeurs des champs et les maillages support sont chargés au besoin.
-
-Le chargement des métadonnées de description se fait par la méthode::
-
- addDatasource(const char \*filepath)
-
-
-
-Eléments d'implémentation
-=========================
-
-Ecrire un service CORBA qui retourne une sequence de FieldHandler:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandlerList * MyFunction(...) {
- vector<MEDOP::FieldHandler*> fieldHandlerList;
- ...
-
- fieldHandlerList.push_back(fieldHandler);
-
- // Map the resulting list to a CORBA sequence for return:
- MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList();
- int nbFieldHandler = fieldHandlerList.size();
- fieldHandlerSeq->length(nbFieldHandler);
- for (int i=0; i<nbFieldHandler; i++) {
- fieldHandlerSeq[i] = *fieldHandlerList[i];
- }
- return fieldHandlerSeq._retn();
- }
-
-Ecrire un service CORBA qui retourne une structure CORBA:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandler * fieldHandler = new ...
- _fieldHandlerMap[fieldHandler->id] = fieldHandler;
-
- // >>> WARNING: CORBA struct specification indicates that the
- // assignement acts as a desctructor for the structure that is
- // pointed to. The values of the fields are copy first in the new
- // structure that receives the assignement and finally the initial
- // structure is destroyed. In the present case, WE WANT to keep
- // the initial fieldHandler in the map. We must then make a deep
- // copy of the structure found in the map and return the copy. The
- // CORBA struct specification indicates that a deep copy can be
- // done using the copy constructor. <<<
- return new MEDOP::FieldHandler(*fieldHandler);
-
-
-
-ANNEXE A: Bug en cours
-======================
-
-TO FIX:
-
-* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
- 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
- reference correcte vers le maillage).
-* le script de test test_medoperation.py plante si le module xmed n'a
- pas été chargé avec des données chargées.
-
-ANNEXE B: Traçabilité avec le module XMED
-=========================================
-
-Le module SALOME de nom XMED est l'espace de développement initial du
-composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette
-annexe est la notice technique de ce module, qui reste disponible mais
-qui n'est plus maintenu.
-
-Gestion de configuration du module XMED
----------------------------------------
-
-Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
-configuration dans une base git du projet NEPAL. Ils peuvent être
-récupérés au moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
-
-Cette commande installe un répertoire ``xmed`` contenant l'ensemble
-des sources du module XMED.
-
-Le module XMED a pour pré-requis logiciel la plateforme SALOME:
-
-* SALOME version 6.1.3 (au moins) à télécharger à l'URL
- http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
-* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
-* Installer la plate-forme choisie selon les instructions fournies.
-
-Le module XMED utilise également une bibliothèque interne au projet
-NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
-SALOME pour un usage de développement (XSALOME signifie eXtension
-SALOME). Les sources de cette bibliothèque doivent être récupérés au
-moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
-
-Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
-des sources de la bibliothèque XSALOME.
-
-.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
- simple bibliothèque de fonctions qui complète ou rend plus facile
- d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
- être intégrée à d'autres projets que les projets internes NEPAL ou
- MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
- héberge des développements destinés à être reversés dans la
- plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
- donc être garanti sur le long terme.
-
-Installation et lancement de l'application
-------------------------------------------
-
-L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
-disponible et que le shell de travail est étendu avec l'environnement
-de SALOME. En général, par des commandes de la forme::
-
- $ . /where/is/salome/prerequis.sh
- $ . /where/is/salome/envSalome.sh
-
-La compilation des modules xsalome et xmed suit le standard SALOME. La
-bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
-cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
-la configuration de la procédure de reconstruction de xmed::
-
- $ export XSALOME_DIR=<xsalome_installdir>
-
-Aprés l'installation de xmed, il est possible de générer
-automatiquement une application SALOME prête à l'emploi pour la
-manipulation de champs::
-
- $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
-
-Cette commande génére un répertoire ``appli`` à l'emplacement où elle
-est exécutée. Il reste à lancer l'application SALOME au moyen de la
-commande::
-
- $ ./appli/runAppli -k
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, documentation technique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Cette note fait la synthèse des développements effectués pour le
-maquettage des fonctions de manipulation de champs dans SALOME. Elle
-présente les principes retenus en matière de conception, c'est-à-dire
-concernant les mécanismes techniques sous-jacents, et en matière
-d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
-l'environnement SALOME.
-
-Ces principes sont illustrés par des développements implantés dans le
-module XMED, développé pour les besoins de l'analyse, et dans le
-module MED distribué avec la plateforme SALOME.
-
-.. note:: la lecture de ce chapitre demande une connaissance de la
- structure de classes du module MED, en particulier la distinction
- entre les classes ``MEDMEM::*`` et les servants CORBA associés
- (classe ``SALOME_MED::*``).
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs
-====================
-
-Objectif et motivation
-----------------------
-
-L'objectif de maquettage est de trouver une architecture technique qui
-permet d'exécuter le cas d'utilisation suivant:
-
-* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Opérations pow, sqrt.
-* Possibilité de visualiser les champs produits avec VISU pour
- contrôle des résultats.
-* Possibilité d'exporter des champs produits dans un fichier med.
-
-Eléments de contexte
---------------------
-
-Les opérations de manipulation de champs sont en grande partie
-implémentées dans la bibliothèque MEDMEM. Pour illustration, le
-fragment de code ci-dessous montre comment une addition de champ peut
-être opérée en python:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-Ceci montre que les champs peuvent être manipulés avec une interface
-relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
-f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
-package MEDMEM et wrapping python du package MEDMEM_SWIG).
-
-Par ailleurs, le fonctionnement actuel des modules SALOME qui
-manoeuvrent des données MED est d'instancier les structures de données
-MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
-servants CORBA hébergés dans le processus ``SALOME_Container``, et de
-donner accés à ces données depuis l'étude SALOME au travers de
-pointeurs CORBA. Ce choix d'architecture présente l'avantage de
-centraliser au niveau serveur la gestion du cycle de vie des données
-informatiques et de pouvoir distribuer des "poignées" pour manipuler
-ces données depuis chaque point de l'application qui sait accéder au
-bus CORBA, l'interface graphique en particulier.
-
-
-Hypothèse de travail
---------------------
-
-Compte-tenu de l'objectif de maquettage et des éléments de contexte
-existant, on cherche une solution dans le cadre des hypothèses
-de travail suivantes:
-
-* La manipulation des champs se fait dans l'environement graphique de
- SALOME.
-* Dans cet environnement, on souhaite pouvoir sélectionner
- graphiquement les champs à considérer, puis manipuler ces champs
- dans l'interface texte au moyen de variables python avec une syntaxe
- aussi simple que celle définie dans le wrapping python de MEDMEM,
- c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
- pouvoir écrire f1+f2.
-* Les données MED sont physiquement dans la partie serveur de SALOME
- et accessibles via des pointeurs CORBA (interface spécifiée dans
- MED.idl). On exclu la recopie de données au niveau du client
- graphique.
-
-Dans le cadre de ces hypothèses, la difficulté technique réside dans
-la mise au point d'une interface de communication entre des variables
-manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
-dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
-instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
-processus ``SALOME_Container``).
-
-
-Eléments de conception
-======================
-
-
-Implantation technique
-----------------------
-
-Le diagramme ci-dessous représente l'organisation des principaux
-paquets logiciels du module MED:
-
-.. image:: images/medmem-layers.png
- :align: center
-
-Les cadres bleus représentent le lieu d'implantation des
-développements effectués dans le module MED pour les besoins du
-maquettage. On notera en particulier les interventions aux niveaux
-suivants:
-
-* interfaces idl: ajout de l'interface MEDOP.idl
-* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
- l'interface MEDOP.idl
-
-Architecture technique
-----------------------
-
-Les schéma ci-dessous représente les objets informatiques qui sont à
-l'oeuvre pour la réalisation des opérations sur les champs:
-
-.. image:: /images/xmed-architecture.png
- :align: center
- :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
-
-On distingue les objets suivants:
-
-* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
- MED chargée en mémoire.
-* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
- chargés en mémoire.
-* Une instances de ``SALOME_MED::MED`` et des instances de
- ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
- structure med et des champs qui lui sont associés et chargés en
- mémoire.
-* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
- centralise la mise en oeuvre des opérations de champs sur le serveur
- ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
- sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
- directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
- de temps.
-* Des instances de ``FieldProxy`` qui correspondent aux variables
- manipulées au niveau de l'interface graphique et qui représentent
- les champs. Une instance de FieldProxy possède détient les
- références des servants ``SALOME_MED::MEDOP`` et
- ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
- ``medop_ptr`` et ``field_ptr`` respectivement.
-* Il existe également une instance de ``MedProxy`` non représentée
- dans ce diagramme. Cette instance correspond à une variable qui
- permet de manipuler la structure med.
-
-.. note:: Les éléments apportés par la maquette sont les classes
- ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
- éléments ont pu être modifiés légèrement pour les besoins de
- l'intégration ou pour la correction de quelques bugs.
-
-Le cycle de vie de ces objets est le suivant.
-
-Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
-des champs ``MEDMEM::FIELD``, la création est faite au moment du
-chargement du fichier med dans SALOME au moyen du module MED. A cette
-occasion, les servants CORBA associés ``SALOME_MED::MED`` et
-``SALOME_MED::FIELD`` sont créés et des références vers ces servants
-sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
-l'utilisateur dans l'interface graphique. L'ensemble de ces données
-préexiste à la manipulation de champs.
-
-Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
-``SALOME_MED::MED`` auquel ils sont associées. Le servant
-``SALOME_MED::MED`` possède une référence sur la structure
-``MEDMEM::MED`` et il la transmet à l'instance du servant
-``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
-autonome par la suite pour manipuler les données MED, et les champs en
-particulier. Le code python ci-dessous montre comment un opérateur med
-``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
-l'addition de deux champs:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
- medOp = medObj.createMedOperator()
-
- f1 = medObj.getField("testfield1",-1,-1)
- f2 = medObj.getField("testfield2",-1,-1)
-
- somme = medOp.add(f1,f2)
-
-Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à
-une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
-``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
-un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
-``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
-une référence directe sur la structure ``MEDMEM::MED`` et peut la
-manoeuvrer pour demander des champs, faire des opérations avec ces
-champs, ajouter le champs résultat à la structure et enfin retourner
-un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
-
-Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
-instance de ``FieldProxy`` est un objet python qui peut être
-manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
-localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
-ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
-d'usage (cf. paragraphe ci-après). La création d'un objet
-``FieldProxy`` déclenche la création d'un opérateur med (instance de
-``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
-référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
-opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
-opérations possibles sur ce champ, comme illustrer sur l'exemple
-ci-dessus.
-
-
-Rôle des objets proxy
----------------------
-
-Dans le modèle d'architecture présenté ci-dessus, on introduit deux
-types d'objets proxy:
-
-* Les objets de classe ``FieldProxy`` qui représentent des poignées de
- manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
- dans le container SALOME.
-* Les objets de classe ``MedProxy`` qui représentent des poignées de
- manipulation des structures ``MEDMEM::MED`` physiquement instanciées
- dans le container SALOME.
-
-Elles sont instanciées dans l'interpréteur python SALOME pour
-manipulation dans l'interface textuelle à partir de la donnée du
-pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
-champ (le nom du champ et le pas de temps défini par le numéro d'ordre
-et le numéro d'iteration:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
-
- from xmed import fieldproxy
- from xmed import medproxy
-
- f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
- f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
-
- field_somme = f1 + f2
- field_offset = f1 + 5.3
-
-Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
-``field_offset`` sont des objets de classe ``FieldProxy``. Ils
-correspondent aux variables physiquement manipulées par
-l'utilisateur pour désigner les champs dans les opérations.
-
-Ces classes proxy sont conçues pour être le lieu d'implémentation de
-l'interprétation des commandes utilisateur et donc de l'ergonomie
-de manipulation des champs au niveau l'interface textuelle. Ce point
-est développé :ref:`plus bas <develguide_execFieldOperation>`.
-
-Programmation de l'interface textuelle
---------------------------------------
-
-Dans le cadre de la maquette, l'interface de manipulation des champs
-est l'interface textuelle python intégrée à SALOME. Dans la pratique,
-l'utilisateur manipule des variables python qui correspondent à des
-objets de classe ``FieldProxy`` équipées des fonctions requises et de
-l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
-ci-dessus).
-
-Or, l'hypothèse de travail est que les données MED sont chargées dans
-SALOME et publiées dans l'étude pour point d'accés depuis l'interface
-graphique. L'utilisateur choisi un champs directement dans l'arbre
-d'étude (ou dans une interface graphique dédiée) puis demande qu'il
-soit mis à disposition dans l'interface python sous un nom de variable
-à choisir. Les captures d'écran ci-dessous montre la séquence
-graphique en images:
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-
-+---------------+---------------+
-| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
-
-L'image de gauche montre la sélection du pas de temps, l'image de
-droite la boîte de dialogue qui permet la saisie de l'alias avec
-lequel le champs sera manipulé dans l'interface textuelle. La
-validation de cette fenêtre doit mettre automatiquement le champ à
-disposition dans l'interface python SALOME et sous le nom de variable
-spécifié par l'alias saisi.
-
-Pour cela, il y a un couplage technique à programmer entre l'interface
-graphique et l'interface textuelle python, avec en particulier la
-transmission des pointeurs vers les servants CORBA mis en jeu dans la
-sélection.
-
-Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
-MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
-implémente l'interface graphique du module. Pour rappel, l'interface
-graphique d'un module SALOME se présente sous la forme d'une classe
-centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
-``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
-par laquelle on peut récupérer une instance de la console python
-embarquée (this->getApp()->pythonConsole()).
-
-Le code suivant illustre l'envoie d'une commande python par ce
-mécanisme. Dans cet example, on cherche à reconstituer dans le
-contexte de la console python un pointer vers un objet med instancié
-dans le contexte C++ de l'application graphique. Pour cela, on
-communique la référence de l'objet sous la forme sérialisé (IOR pour
-un objet CORBA):
-
-.. code-block:: cpp
-
- #include <PyConsole_Console.h>
- #include <QString>
- #include <QStringList>
- #include <SalomeApp_Application.h>
-
- // We suppose here that we have a CORBA object reference (object of
- // type *_ptr or *_var), for example a SALOME_MED::MED object.
- SALOME_MED::MED_ptr medObj = ... // anything to get this object
-
- // Get the IOR of this object
- QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
-
- PyConsole_Console * pyConsole = getApp()->pythonConsole();
-
- QStringList commands;
- commands+="import salome";
- commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR);
-
- QStringListIterator it(commands);
- while (it.hasNext()) {
- pyConsole->exec(it.next());
- }
-
-Le code réel de la maquette est basé sur ce principe et transmet à la
-console python des lignes de commandes qui permettent de reconstruire:
-
-* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
- champ sélectionné;
-* une instance de ``FieldProxy`` qui correspond au champ sélectionné
- et avec pour nom de variable la valeur de l'alias saisi dans
- l'interface graphique.
-
-Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
-par la fabrication de la liste de commandes suivante pour envoie à la
-console python par le mécanisme illustré plus haut:
-
-.. code-block:: cpp
-
- QStringList commands;
- commands+="from xmed.fieldproxy import getFieldFromMed";
- commands+="from xmed.medproxy import getMedProxy";
- commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
- commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
-
-Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
-``iterationIndex`` sont construites à partir du champ sélectionné par
-des techniques de programmation standard dans SALOME qu'on peut
-examiner en détail dans la classe ``XMEDGUI`` (voir méthode
-``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
-chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
-
-Le point important à noter ici est que les données à transmettre
-doivent être fournies sous forme de chaînes de caractères ou de types
-simples. C'est pourquoi la référence au servant CORBA
-``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
-c'est-à-dire une chaîne de caractères qui permet l'identification de
-l'objet au niveau du bus CORBA.
-
-Au niveau de la console python cela correspond à l'exécution des
-commandes suivantes:
-
-.. code-block:: python
-
- from xmed.fieldproxy import getFieldFromMed
- from xmed.medproxy import getMedProxy
-
- med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100")
-
- f1=getFieldFromMed(med,"testfield1",-1,-1)
-
-Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA
-``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
-``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
-associée à ce servant (en fait associée au servant
-``SALOME_MED::MEDOP`` créé sur demande par le servant
-``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
-
-.. _develguide_execFieldOperation:
-
-Exécution des opérations sur le champs
---------------------------------------
-
-Les variables définies dans l'interface textuelle pour désigner les
-champs à manipuler sont des objets de classe ``FieldProxy``.
-
-Cette classe a une propriété remarquable, elle est construite sur un
-design pattern de type "Proxy" qui pointe vers un servant
-``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
-directement au servant vers lequel il pointe, mais que l'on passe
-systématiquement par une procédure de l'objet proxy qui fait "boîte
-aux lettres":
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __getattr__( self, name ):
- """
- This method realizes the proxy pattern toward the servant
- SALOME_MED::FIELD.
- """
- return getattr( self.__field_ptr, name )
-
-Ce pattern permet l'implémentation de pré-traitement et/ou de
-post-traitement suivant le type d'accés que l'on cherche à faire.
-
-Il permet aussi et surtout de fournir un objet python qui présente
-l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
-operations de champs. Ici, python est ton ami, car il s'agit pour cela
-d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
-par python pour les operations entre objets. En particulier, la
-re-définition des fonctions internes ``__add__`` (opérateur addition),
-``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
-multiplication) et ``__div__`` (opérateur division) au sein de la
-classe ``FieldProxy``, permet de prendre la main sur le comportement
-des opérations algébriques et de définir une ergonomie sur mesure. Par
-exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
-(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
-réel à une variable de type FieldProxy):
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __add__(self, operande):
- """
- This can process the addition of two fields or the addition of
- a scalar to a field. It depends weither the operande is a
- FieldProxy or a simple scalar numerical value.
- """
- if isinstance(operande, FieldProxy):
- # The operande is an other field
- otherField_ptr = operande.__field_ptr
- rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
- else:
- # The operande is a scalar numerical value that must be
- # considered as an offset in a linear transformation
- factor = 1
- offset = operande
- rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
- return FieldProxy(self.__med_ptr, rfield_ptr)
-
-Il est à noter que dans les deux cas de figure (opérande=champ ou
-opérande=scalaire), la fonction délègue la réalisation concrète de
-l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
-l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
-MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
-service de calcul (l'addition entre champs dans le premier cas,
-l'application d'une transformation linéaire de type y=factor*x+offset
-dans le deuxième cas).
-
-Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
-présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
-l'interface du servant ``SALOME_MED_MEDOP``):
-
-.. code-block:: cpp
-
- /*! Addition of the fields f1 and f2 ( f1+f2) */
- FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Substraction of the fields f1 and f2 (f1-f2) */
- FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Multiplication of the fields f1 by f2 (f1*f2) */
- FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Division of the fields f1 by f2 (f1/f2) */
- FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Power of the field f (f^power) */
- FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
- /*! Linear transformation of the field f (factor*f+offset) */
- FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
- /*! Dublication of the field f */
- FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
-
-Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
-module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
-``MEDMEM_I``). C'est au sein des instances de cette classe que sont
-réalisées les opérations et que sont produites physiquement les
-données. Typiquement, les opérations présentées ici produisent un
-champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
-``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
-ce servant.
-
-Ce mécanisme global peut être étendu sans limitation à tout les types
-d'opération qui sont envisagés dans les spécifications de manipulation
-des champs dans SALOME.
-
-
-Contrôle visuel des champs
---------------------------
-
-Les illustrations ci-dessous montrent qu'une fonction de visalisation
-est implémentée dans la maquette pour permettre le contrôle visuel
-d'un champ au moyen d'une représentation 3D (une carte spatiale du
-module du champ dans l'exemple implémenté par défaut):
-
-.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
-.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-
-+---------------+---------------+
-| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
-
-Cette fonction répond au besoin de contrôle interactif des résultats
-produits par les opérations de manipulation de champs.
-
-Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
-module VISU de faire une représentation 3D d'un champ spécifié par la
-donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
-(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
-
-.. code-block:: python
-
- import salome
- import VISU
-
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Then we can import the specified field in the VISU module. This
- # creates an study entry in the VISU folder.
- result = visuComp.ImportMedField(field_ptr)
-
- meshName = field_ptr.getSupport().getMesh().getName()
- fieldName = field_ptr.getName()
- iterNumber = field_ptr.getIterationNumber()
- scalarmap = visuComp.ScalarMapOnField(result,
- meshName,
- visuEntityType,
- fieldName,
- iterNumber)
-
-Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
-particulier à cause de la non définition de la variable
-``visuEntityType``, voir remarque plus bas), le composant VISU
-désigné ici par la variable ``visuComp`` va chercher les données du
-champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
-argument de la fonction ``ImportMedField``, puis produit une
-représentation de type "scalarmap".
-
-.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
- plus haut conférées par le pattern "Proxy", on peut transmettre ici
- aussi bien le servant CORBA que l'instance du proxy (la fonction
- ``ImportMedField`` n'y verra que du feu).
-
-Le code complet et fonctionnel de la fonction d'affichage est dans le
-corps du module python ``fieldproxy.py`` sous la forme d'une fonction
-de nom ``visuField``. Il convient de noter que cette fonction doit
-établir une correspondance entre le type des entités tel que défini
-dans MED et dans VISU:
-
-.. code-block:: python
-
- medEntityType = field_ptr.getSupport().getEntity()
- if (medEntityType == SALOME_MED.MED_CELL):
- visuEntityType = VISU.CELL
- elif (medEntityType == SALOME_MED.MED_NODE):
- visuEntityType = VISU.NODE
-
-
-Export des résultats de calcul
-------------------------------
-
-Tous les champs produits à l'occasion des opérations entre objets
-``FieldProxy`` sont automatiquement ajoutés à la structure med à
-laquelle is sont associés. Une convention d'attribution des noms est
-implémentée de sorte que par défaut aucune précision n'est demandée à
-l'utilisateur.
-
-La structure med peut être manipulée au moyen de la variable ``med``
-créée dans l'interface textuelle comme une instance de la classe
-``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
-l'interface du servant ``SALOME_MED::MED`` étendue de quelques
-fonctions utilitaires pour la gestion et le contrôle des données.
-
-En particulier, la sauvegarde de la structure dans un fichier est
-automatisée par la méthode ``save(medfilename)``:
-
-.. code-block:: python
-
- med = medproxy.MedProxy(medObj)
- med.save("/tmp/output.med")
-
-Cette méthode s'occupe de définir un driver d'écriture et de procéder
-à l'enregistrement des données de la structure med (les maillages, les
-champs présents au départ et tous les champs produits depuis la
-lecture initiale).
-
-Limitations
-===========
-
-L'implémentation de la maquette limite l'usage des opérations aux cas
-de figure suivants:
-
-* Seules les operations entre champs qui partagent le même support med
- sont possibles. Ceci est une contrainte imposé par la conception
- actuelle de MEDMEM.
-* Le résultat d'une opérations est calculé sur toutes les composantes
- et tout le domaine de définition des champs en opérande. Cette
- deuxième contrainte est juste parce que les usages plus fin,
- notemment avec la notion de domaine de définition, n'a pas encore
- été exéminée à ce jour.
-* Le nom d'un champ produit par une opération ne correspond pas au nom
- de la variable python par laquelle on le réceptionne et on le
- manipule. Le nom est attribué par une convention (ceci n'est pas
- vraiment une limitation mais une caractéristique à connaître).
-
-On note également les restriction techniques suivantes:
-
-* Les données MEDMEM sont supposées être chargées par le composant MED
- puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
- par le module MED).
-* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
- de la classe ``FieldProxy`` soient pris en considération dans les
- opérations sur les champs, il est indispensable que le premier
- opérande d'une opération unitaire soit un champ (objet de classe
- ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
- fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
- car python tente de traiter la situation au moyen de la fonction
- ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
-
-
-Notice informatique
-===================
-
-Gestion de configuration
-------------------------
-
-Les développements décrits dans ce chapitre sont répartis entre les
-modules MED et XMED (développé pour l'occasion). Cette séparation est
-faite par soucis de clarté et d'efficacité de développement, mais les
-éléménts du module XMED ont vocation à intégrer le module MED dans la
-mesure où les propositions techniques sont retenues pour le
-développement à venir.
-
-Le code source du module XMED peut être récupérés par la commande
-suivante::
-
- $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
-
-Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
-équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
-VISU. Pour récupérer la branche BR_medop du module MED, taper la
-commande::
-
- $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
-
-La configuration de référence est:
-
-* XMED: révision svn 41
-* MED: tag cvs BR_medop_20101025
-
-Moyens de tests
----------------
-
-Plusieurs types de tests unitaires sont définis (reste à les
-automatiser proprement):
-
-* Test des servants et utilitaires de manipulation python:
-
- - Dans XMED, package xmed/tests, utiliser le script
- ``test_medoperation.py`` dans un interpréteur python lancé dans
- une session shell SALOME. Ce script prépare des variables de test
- et fournit des fonctions de test unitaire (à exécuter ou pour s'en
- inspirer). Après avoir lancé SALOME via une application virtuelle,
- on peut taper::
-
- $ <APPLI_ROOT>/runSession
- [NS=venus:2810] $ python -i test_medoperation.py
- >>>
-
- - Ceci permet de tester en particulier l'interface ``MedOp`` et son
- utilisation dans le module python ``fieldproxy.py``.
-
-* Test des classes MEDMEM:
-
- - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
-
-Un fichier de test basique (mais néanmoins suffisant) de nom
-``tesfield.med`` est fourni avec les sources dans le répertoire
-``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
-répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
-contient deux champs ``testfield1`` et ``testfield2`` définis sur un
-pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
-par éléments (MED_CELL).
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, MED, MEDMEM
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Note de travail concernant l'utilisation de MEDMEM
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module MED de SALOME comporte plusieurs composants d'intérêt pour
-la manipulation de champs:
-
-* la bibliothèque MEDMEM qui fournit une interface de programmation
- pour manoeuvrer une structure MED
-* le module CORBA SALOME_MED qui matérialise le composant SALOME
- (serveur corba) du module MED
-* l'interopérabilité avec le module VISU qui permet la visualisation
- des champs manipulés dans MED
-
-Les sections ci-après donnent quelques éclairages techniques sur ces
-différents aspects. Les sources de démonstration peuvent être
-récupérés depuis le dépôt svn::
-
- $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
- $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation synthétique de MED
-===============================
-
-MED désigne un modèle conceptuel pour décrire des données de type
-éléments finis (éléments finis, volumes finis et éléments
-discrets). Dans l'usage courant, il permet la description et l'échange
-des données de calcul de type maillages et champs. La documentation
-complète peut être trouvée à l'URL suivantes:
-
-* |LINK_EDF_MEDDOC|_ (version 2.3).
-
-On distingue deux implémentations informatiques de ce modèle:
-
-* MED fichier: qui permet la lecture et l'écriture de données depuis
- un fichier au format med. Les opérations de lecture/écriture sont
- atomiques (pas de chargement de la structure de données globale).
-* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
- image de la structure de données MED contenue dans un fichier au
- format med. Les opérations peuvent être atomiques ou
- globales.
-
-On notera simplement ici que MEDMEM utilise MED fichier pour les
-opérations de lecture/écriture et que MED fichier est indépendant de
-MED mémoire. La documentation complète de MED fichier peut être
-trouvée à l'URL suivante:
-
-* |LINK_EDF_MEDFICHIERDOC|_
-
-La bibliothèque MEDMEM
-======================
-
-Le modèle de classes MEDMEM est structuré autour des notions de MESH
-(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
-champs). Ces notions reprennent en partie des concepts du modèle
-MED. Le diagramme ci-dessous présente les classes principales:
-
-.. image:: images/med-uml-main_60pc.png
- :align: center
-
-Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
-figure ci-dessous indique qu'une instance MED peut être associée à
-plusieurs maillage et plusieurs champs. Par contre un champ donné ne
-peut être associé qu'à un seul maillage (par l'intermédiaire du
-support). Plusieurs champs peuvent être associés au même maillage. La
-forme la plus courante est d'ailleurs une instance composé d'un
-maillage unique sur lequel sont définis plusieurs champs.
-
-On peut avoir également des configurations plus complexes, comme par
-exemple un maillage unique, plusieurs champs définis sur ce maillage
-mais avec des supports différents, par exemple parce que les valeurs
-sont définies sur des entités de maillage différentes (les éléments
-pour un champ, les noeuds pour un autre, ...)::
-
- field1->support1->mesh
- field2->support2->mesh
- field3->support3->mesh
-
-On observe:
-
-* 2 champs U et V doivent avoir le même support (au sens informatique
- du terme) pour pouvoir être en argument d'une opération (sinon
- exception). Il faudrait accepter qu'il soit informatiquement
- différent et vérifier la conformité conceptuelle.
-* Cette contrainte peut se comprendre car physiquement les données
- sont stockées dans un vecteur qui couvre toutes les mailles. Le
- support est le seul masque de lecture pour établir la correspondance
- avec les positions dans le maillage et il est donc important qu'une
- cohérence soit assurée.
-
-Les objets champs (FIELD) et maillage (MESH)
---------------------------------------------
-
-Un objet MED permet d'accéder aux différentes informations concernant
-les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
-données physiques associées à ces objets (les valeurs des composantes
-pour les champs, les mailles et leur connectivité pour les
-maillages). L'accès aux données physiques est du ressort des objets
-spécifiques MESH, SUPPORT et FIELD.
-
-Un objet MED peut être créé intégralement en mémoire. L'usage plus
-fréquent est de l'initialiser à partir de la donnée d'un fichier
-med. Pour cela, l'objet MED doit être associé à un driver
-d'entrée/sortie branché sur le fichier (``testfilename`` dans
-l'exemple):
-
-.. code-block:: cpp
-
- MED *myMed = new MED;
- MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
- driverIn->open();
- driverIn->readFileStruct();
- driverIn->close();
-
-A l'occasion de la fonction readFileStruct, la structure interne de
-l'objet MED est enrichie des informations concernant les objets MESH,
-SUPPORT et FIELD contenu dans le fichier. En particulier un
-dictionnaire des champs (variable map interne) est initialisé est
-contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
-méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
-autonome pour être chargé sur demande. On peut alors requêter l'objet
-MED pour obtenir un champ particulier (spécifié par son nom
-``fieldname`` dans l'exemple):
-
-.. code-block:: cpp
-
- FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
-
-Puis le champ qui lui est associé doit être physiquement chargé pour
-permettre la mise à jour du support:
-
-.. code-block:: cpp
-
- MESH * mesh = myMed->getMesh(field);
- mesh->read();
- myMed->updateSupport();
-
-Pour enfin charger les valeurs des composantes du champ:
-
-.. code-block:: cpp
-
- field->read();
-
-La numérotation des éléments de maillage
-----------------------------------------
-
-Les éléments qui composent un maillage sont caractérisés par:
-
-* Le type d'entité de l'élément, à choisir dans la liste
- ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
- ``MED_FACE``, ``MED_CELL``.
-* Le type de géométrie de l'élément, à choisir dans la liste
- ``MED_EN::medGeometryElement``, qui contient en particulier
- ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
-
-Les éléments sont numérotés par un indice relatif à la catégorie
-géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
-composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
-ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
-persistente dans le fichier med). De même, les arrêtes sont numérotées
-de 1 à Na. Une numérotion globale implicite existe sur les éléments,
-elle consiste à parcourir l'ensemble des types géométriques dans
-l'ordre de définition du modèle de données. Ainsi, si le modèle
-contient uniquement les Na arrêtes et les Nf faces, alors l'indice
-global de la première face est Na+1.
-
-.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
-
-
-Binding python de MEDMEM
-------------------------
-
-Les classes du package ``MEDMEM`` (package du module ``MED`` qui
-implémentent les structures de données C++ de MED mémoire) produisent
-la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
-partie mis à disposition de l'interface python grace à une couche de
-liaison (binding Python-C++) générée par le logiciel SWIG à partir
-d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
-package source ``MEDMEM_SWIG``).
-
-Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
-des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
-nouvelle classe est créée (du moins si l'on souhaite profiter de ces
-évolutions dans l'interface python).
-
-Cette mise à jour nécessite de prendre soin au transfert des
-structures de données entre les espaces python et C++. En particulier,
-l'utilisation des template de classe pour décrire les champs typés en
-C++ appelle une précaution de codage particulière de l'interface
-SWIG.
-
-Pour exemple, le fragment de code ci-dessous, extrait du fichier
-``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
-``MedDataManager`` dans l'interface:
-
-.. code-block:: cpp
-
- #include "MEDMEM_MedDataManager.hxx"
-
- class MedDataManager
- {
- public:
- ~MedDataManager();
- void printFieldDouble(FIELD<double,FullInterlace> * field);
-
- %extend {
- MedDataManager(char * fileName)
- {
- return new MedDataManager(string(fileName));
- }
- MedDataManager(MED * med)
- {
- return new MedDataManager(med);
- }
-
- %newobject getFieldDouble(const char * fieldName, const int dt, const int it);
- FIELD<double, FullInterlace> * getFieldDouble(const char * fieldName, const int dt, const int it)
- {
- return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
- }
- }
-
- };
-
-
-Utilisation de MEDMEM pour la manipulation de champs
-----------------------------------------------------
-
-Des opérations de manipulation de champs sont disponibles dans la
-bibliothèque MEDMEM standard est peuvent être utilisées dans
-l'interface python. Les quelques lignes suivantes illustrent l'usage
-qu'on peut en faire pour exécuter l'addition de deux champs sur tout
-leur espace de définition et pour un pas de temps donné:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-.. note:: Cet exemple de code requiert les évolutions de MEDMEM
- opérées dans la branche BR_medop (pour disposer de la classe
- MedDataManager en particulier) et le package python ``xmed`` qui
- fournit quelques fonctions utilitaires pour manoeuvrer les données
- med (ce package est dans le module XMED et sera probablement à
- terme intégré au module MED).
-
-Des limitations existent aujourd'hui pour ce type de manipulations:
-
-* les champs doivent partager le même support MED, c'est-à-dire être
- décrit sur le même maillage et sur les mêmes entités de ce
- maillage.
-* ...
-
-
-Remarque sur l'implémentation C++
----------------------------------
-
-A noter l'usage de plusieurs formes d'arguments pour les fonctions:
-
-* passage des arguments par valeur ``myfunction(A a);``
-* passage des arguments par référence ``myfunction(A& a);``
-* passage des arguments par pointeur ``myfunction(A* a);``
-
-Le passage des arguments par référence est une facilité d'écriture
-pour éviter de passer un pointeur tout en évitant la récopie des
-données de la variable.
-
-.. _xmed-medmem_corbainterface:
-
-L'interface CORBA SALOME_MED
-============================
-
-Implémentation du composant MED et des servants SALOME_MED::\*
---------------------------------------------------------------
-
-Le composant MED est un servant CORBA qui permet la manipulation de
-données MEDMEM dans l'environnement SALOME. Le composant peut fournir
-des pointeurs vers des instances de l'interface SALOME_MED (objets
-SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
-servants CORBA qui résident dans le container et qui encapsulent les
-données MEDMEM.
-
-Le schéma ci-dessous représente les éléments informatiques qui
-composent l'architecture CORBA du module MED:
-
-.. image:: images/medmem-corba-layers.png
- :align: center
-
-Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
-CORBA) fonctionnent différement en ce qui concerne le chargement des
-données:
-
-* Dans MEDMEM, les données sont chargées à la demande (fonctions read
- des objets) et aucune gestion n'est assurée. En particulier l'appel
- à read alors que la donnée est déjà chargée conduit à une levée
- d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
- type de gestion.
-* Dans SALOME_MED, les données sont chargées à la création de
- l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
- leurs données sont chargés à ce moment là et gérés dans une table de
- type HashMap au niveau de la structure SALOME_MED::MED. Cette
- structure remplie dés lors des fonction de gestion. L'appel à
- SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
- un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
- l'initialisation (ATTENTION, cette fonction est bugguée dans la
- branche principale -> Fix dans la branche BR_medop).
-
-Une gestion intermédiaire peut être envisagée: le chargement à la
-demande géré dans une ou plusieurs tables de champs (une pour chaque
-type de valeur numérique). Une implémentation de ce type de gestion
-est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
-en charge ce comportement pour les structures de données MED (en
-particulier les champs).
-
-Utilisation du composant MED
-----------------------------
-Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
-interfaces de ce module CORBA sont spécifiées par les fichiers idl
-suivants:
-
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
- ``MED.idl``] qui décrit les interfaces des objets manipulés par le
- module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
- et FIELD.
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
- ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
- (c'est-à-dire le composant chargé par la commande
- ``FindOrLoadComponent("FactoryServer", "MED")`` du
- lyfeCycleCorba). On trouve:
-
- - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
- pour l'implémentation des services généraux des composants SALOME
- (persistance hdf, dump)
- - l'interface ``MED_Gen`` qui hérite des interfaces
- ``Engines::Component`` et ``MED_Gen_Driver`` pour
- l'implémentation des services spécifiques du composant MED.
-
-L'implémentation de ces interfaces est faites au niveau de différents
-packages des sources du module MED:
-
-* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
- interfaces décrites par le fichier ``MED.idl``;
-* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
- décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
- partie composant classique d'un module SALOME.
-* Le package ``MedCorba_Swig`` qui fournit une interface swig
- générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
- ``MED``
-
-L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
-utilise l'interface swig fournie par MedCorba_Swig). Après l'import
-d'amorce systématique:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
-
- import SALOME_MED
- from libSALOME_Swig import *
-
-On peut charger le composant SALOME MED:
-
-.. code-block:: python
-
- medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
-
-grâce auquel les services de chargement de la structure MED peuvent
-être invoqués. Par exemple, les commandes suivantes chargent toute la
-structure MED dans l'étude salome passée en argument:
-
-.. code-block:: python
-
- filePathName = "myfile.med"
- medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
-Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude:
-
-.. code-block:: python
-
- filePathName = "myfile.med"
- medObj = medComp.readStructFile(filePathName,salome.myStudyName)
-
-On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
-qui permet une utilisation assez semblable (mais différente on le
-verra plus bas) à MEDMEM:
-
-.. code-block:: python
-
- fieldIdx = 1 # WRN maybe there is no field of idx=1
- iterationIdx = 0
- fieldName = medObj.getFieldNames()[fieldIdx]
- dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
- it = dtitfield[0]
- dt = dtitfield[1]
- fieldObj = medObj.getField(fieldName,it,dt)
- nbOfFields = medObj.getNumberOfFields()
- fieldNames = medObj.getFieldNames()
-
- mesh = fieldObj.getSupport().getMesh()
-
-.. note::
- Observations en vrac:
-
- * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
- le champ informatique réel (objet MEDMEM).
- * FIELD_i::fieldMap variable static de type map qui semble gérer
- les différentes instances de FIELD_i (~pattern factory). Cette
- map peut être requétée au moyen d'un indice de type long appelé
- corbaIndex.
- * Quand on crée un FIELD_i par le constructeur d'argument
- ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
- incrément du corbaIndex
- * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
- ``MEDMEM::FIELD_`` associé
- * A CONFIRMER: Il semble que les fonctions de chargement
- ``readStructFile*()`` charge toutes les données du fichier med,
- alors qu'en MEDMEM seules les meta-données sont chargées.
- * A CONFIRMER: il semble que le chargement d'une structure MED
- CORBA peut se faire sans passer par le composant (cf. l'interface
- de MED)
-
-Interface avec le module VISU
-=============================
-
-Des interactions sont possibles entre MED et VISU à partir du moment
-où les données med sont gérées dans l'étude, c'est-à-dire sous la
-forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
-deux conditions sont aujourd'hui nécessaires (objet corba + publié
-dans l'étude) mais il semble que ce ne soit lié qu'à un choix
-d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
-a priori être modifié. A CONFIRMER.
-
-L'exemple de code ci-dessous (en python, mais il peut être transposé à
-une implémentation C++) montre par exemple comment envoyer au module
-VISU une requête de visualisation d'un champs hébergé par le module
-MED (en fait, les données sont gérées au travers d'un objet corba
-SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
-catégorie du composant MED). Les importations standard (salome,
-SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
-les exemples précédents):
-
-.. code-block:: python
-
- # Load the med structure using MED
- medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- filePathName = "myfile.med"
- medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
- # Get the VISU component
- import VISU
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Get the sobject associated to the med object named "Med"
- aSObject = salome.myStudy.FindObject("Med")
- isPresent, medSObj = aSObject.FindSubObject(1)
-
- # Finally, import the med sobject in VISU
- result = visuComp.ImportMed(medSObj)
-
-Il est possible de d'aller plus loin et par exemple de déclencher
-l'affichage d'une scalarmap d'un champ spécifique pour une itération
-particulière (voir la fonction
-``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
-``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
-
-Liens complémentaires:
-
-* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
-
-
-Notes en vrac
-=============
-
-Questions:
-
-* Comment obtenir le nom du fichier med à partir d'une structure med?
-* Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de
- la donnée de l'objet CORBA SALOME_MED::MED?
-
-Remarques:
-
-* A part, les opérations arithmétiques (+,-,*,/), aucune opération
- n'est définie.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, vue d'ensemble
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module XMED est un espace d'expérimentation pour le développement
-des opérations de manipulation de champs. Il complète des
-développements intégrés directement dans le module MED et gérés dans
-la branche CVS BR_medop.
-
-Une maquette est au point pour illustrer les propositions en matière
-d'ergonomie d'utilisation et en matière d'architecture technique. La
-maquette permet de réaliser des cas d'utilisation de la forme:
-
-* Chargement d'un fichier med dans le module MED (ou publication par
- un code de calcul).
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Egalement quelques fonctions
- mathématiques standard applicables sur des champs (pow, sqrt).
-* Possibilité de visualiser les champs produits avec VISU
-* Possibilité d'exporter des champs produits dans un fichier med
-
-La figure ci-dessous montre le résultat d'une séquence d'utilisation
-dans laquelle les champs "testfield1" et "testfield2" ont été
-sélectionnés dans l'arbre d'étude pour être utilisés dans la console
-textuelle sous les noms de variables f1 et f2. L'image montre le
-contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
-ligne de commande:
-
-.. image:: images/medop-gui-result.png
- :align: center
-
-La séquence ci-après montre le cas d'utilisation complet en
-images:
-
-1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
-2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
- défaut, le nom du champ est proposé (``testfield1`` ici). Dans
- l'exemple, l'utilisateur remplace par l'alias ``f1``.
-3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
- ``f1`` au moyen de la commande ``f1.visu()``
-4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
- l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
- récupéré ici dans une variable de nom ``result``.
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
-.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-
-+---------------+---------------+
-| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
-| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
-
-La solution technique est construite sur les principes suivants:
-
-* Les données MEDMEM sont physiquement chargées par le composant MED,
- c'est-à-dire dans le processus ``Container`` de SALOME, et sont
- référencées dans l'étude SALOME.
-* Les opérations sont physiquement des opérations entre objets MEDMEM
- purs qui ont lieu dans le composant MED.
-* Les opérations sont pilotées par des objets proxy python instanciés
- dans la console TUI puis manipulés par l'utilisateur. Ces objets
- proxy savent accéder aux objets MEDMEM au travers de leur interface
- CORBA.
-
-Ainsi, l'architecture technique est construite pour pouvoir travailler
-sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
-depuis des objets python dans l'interface textuelle de
-SALOME. L'effort principal a donc porté sur la mise au point de
-l'interface technique qui permet de lier des variables représentant
-les champs au niveau du GUI (techniquement, la calculette est
-l'interpréteur python embarqué dans le GUI, étendu de quelques
-fonctions pour la manipulation de champs), alors que les données
-MEDMEM sont physiquement disponibles uniquement au niveau des
-composants CORBA (et les opérations implémentées dans MEDMEM
-uniquement).
-
-Pour le moment, la maquette est limitée à des operations entre champs
-qui partagent le même support med (contrainte de MEDMEM) et le
-résultat est calculé sur toutes les composantes et tout le domaine de
-définition du champs (cette deuxième contrainte est juste parce que
-les extentions n'ont pas encore été examinées). Enfin, le support de
-gestion des données est supposé être l'étude SALOME et la structure
-MED qui y est publiée.
+++ /dev/null
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Références documentaires
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. include:: medop-definitions.rst
-
-Documents de référence:
-
-* |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
-* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
-* |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
-
-Présentations:
-
-* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
-* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
-* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
-* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
-
- - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
- - |REF_EDF_JUS2011_OGV1|_
- - |REF_EDF_JUS2011_OGV3|_
- - |REF_EDF_JUS2011_OGV4|_
-
-Notes de travail:
-
-* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
-* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Spécifications fonctionnelles et techniques
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Ce texte présente les spécifications informatiques pour le
-développement d'un module de manipulation de champs qui répond à
-l'expression de besoins formulée dans le cahier des charges
-|REF_EDF_VCA_H-I2C-2009-03595-FR|_.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Description des cas d'application de référence
-==============================================
-
-Plusieurs cas d'applications métier sont identifiés pour piloter le
-développement du module de manipulation de champs:
-
-* **Analyser et post-traiter le résultat d'un calcul**. C'est l'usage
- principal qui consiste typiquement à créer des champs comme le
- résultat d'*opérations mathématiques* dont les opérandes sont des
- champs et des scalaires. On compte également dans cette catégorie
- les *opérations de restriction* qui permettent d'extraire puis
- utiliser une partie d'un champs, c'est-à-dire de créer un champ
- comme la restriction d'un autre champ à une partie de son domaine de
- définition (certaines composantes, certains pas de temps, limitation
- à un groupe de mailles).
-* **Comparer des champs issus d'un calcul paramétrique**. Il s'agit
- d'une variante du cas précédent qui consiste à mesurer et visualiser
- les variations entre des champs issues de sources de données
- différentes (différents fichiers med).
-* **Préparer les conditions aux limites d'une calcul**. Il s'agit de
- pouvoir initialiser un champ sur un maillage ou un groupe de
- mailles, c'est-à-dire créer un champ de toute pièce sur un
- support spatial donné, par exemple par la donnée d'une fonction
- mathématique qui donne les valeurs des composantes en fonction des
- coordonnées spatiales.
-* **Gérer des données de calcul**. Il s'agit typiquement de pouvoir
- rassembler au sein d'un même fichier med des champs et des maillages
- issues de différentes sources de données, et/ou créés au travers des
- cas d'application présentés ci-dessus.
-
-Modèle conceptuel des données
-=============================
-
-On rappelle ici les concepts utilisés dans le module et les modalités
-d'utilisation de ces concepts. Le point de vue est celui de
-l'utilisateur du module de manipulation de champs. Il s'agit
-essentiellement pour le moment d'éclaircir l'ergonomie d'usage sur le
-plan conceptuel, avant d'aborder la déclinaison en spécifications
-techniques pour lesquelles les particularités du modèle MED devront
-être intégrées à la réflexion.
-
-Concept de champ
-----------------
-
-Le concept central est celui de *champ*, c'est-à-dire une grandeur
-physique exprimée sur un domaine spatial D. La grandeur peut être de
-type scalaire (une température), de type vectorielle (une vitesse) ou
-de type tensorielle (les contraintes). En un point de l'espace, elle
-se définie donc par la donnée d'une ou plusieurs valeurs numériques
-appelées les *composantes* (1 pour un champ scalaire, 3 pour un champ
-vectoriel 3D, 6 pour un champ tensoriel symétrique 3D).
-
-.. note:: Une pratique courante au niveau des codes est de stocker
- plusieurs grandeurs physiques différentes dans un même champs med
- (au sens informatique du terme). Par exemple, le champ
- électromagnétique à 6 composantes, plus le champ de température
- scalaire peuvent techniquement être stockés dans un même champs med
- à 7 composantes. C'est pourquoi, le module de manipulation de
- champs doit fournir des fonctions de restrictions qui permettent
- d'extraire certaines composantes pour former la grandeur physique à
- étudier. Dans la suite du document, on part du principe que l'on
- peut se ramener dans tous les cas au cas d'un champ homogène tel
- que défini plus haut.
-
-Dans le cadre d'un modèle numérique discret, les valeurs du champ sont
-exprimées pour un nombre fini de positions, qui correspondent à des
-lieux particuliers du maillage. Suivant la nature des modèles de
-calcul, les valeurs peuvent être données par cellule, par face, par
-noeud, aux points de gauss, ...
-
-Ainsi, un champ discret est un objet dont les valeurs peuvent être
-lues selon les dimensions suivantes:
-
-* *La position p dans l'espace*, caractérisée par le type de l'élément
- de maillage support et son numéro identifiant
-* *La composante c*, caractérisée par son indice (jusqu'à 6
- composantes dans les modèles physiques envisagés)
-
-L'évolution d'un champ dans le temps peut être exprimée sous la forme
-d'une série temporelle, c'est-à-dire une séquence de champs donnés
-pour des instants discrets. Aussi, si l'on manipule un champ qui varie
-dans le temps, l'accès aux valeurs introduit une dimension
-supplémentaire:
-
-* *Le temps t*, caractérisé par un numéro de pas de temps
- (correspondant en général à une étape du calcul qui a produit le champ).
-
-.. note:: Il s'agit là d'une représentation conceptuelle standard dont
- le |LINK_EDF_MEDDOC|_ fait une expression détaillée. En
- particulier, la position p est déterminée par la donnée du type
- d'élément support (valeurs aux noeuds, aux mailles, aux noeuds par
- éléments, aux points de gauss) et de l'indice de cet élément. En
- général, le type d'éléments support est résolu à l'initialisation
- et l'indice peut suffire au repérage dans les algorithmes. Le temps
- t est déterminé par un numéro d'itération, qui peut éventuellement
- être complété par un numéro d'ordre. Le cas des points de gauss
- ajoute un cran de complexité dans la mesure où il faut repérer
- l'entité géométrique (maille, face, arrête) puis le point de gauss
- de cette entité. A noter que dans le modèle MED, le concept de
- série temporelle de champ n'est pas explicitement définie et
- l'accès à des valeurs à différents instants t1 et t2 nécessite le
- chargement des champs ``F1=F(t1)`` et ``F2=F(t2)``.
-
-Par convention, on utilisera par la suite les notations:
-
-* **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U
- à la position p et prise à l'instant t;
-* **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes
- les composantes;
-* **U(t,:,c)** pour signifier que l'on manipule le domaine de
- définition spatial complet.
-
-Dans une grande majorité des cas d'usage on travaille à temps t fixé
-et sur un domaine spatiale prédéfini. Aussi on utilisera également la
-notation à deux arguments ``U(:,:)`` ou tout simplement ``U`` (dès
-lors qu'il n'y a pas ambiguïté) pour désigner un champ complet et Uc
-pour désigner la composante c du champ avec c=1..6.
-
-Concept d'opération
--------------------
-Le deuxième concept à préciser est la notion d'*opération*. Une
-opération dans le présent contexte est l'application d'un opérateur
-sur un ou plusieurs champs pour produire une grandeur de type champ ou
-de type valeur numérique.
-
-Par exemple, la formule ``W=OP(U,V)`` indique que le champ W est formé
-à partir des champs U et V en arguments d'une fonction OP. Dans le cas
-d'une opération algébrique comme l'addition (cf. :ref:`Spécification
-des opérations<xmed-specifications>`, le résultat attendu par défaut
-est que pour chaque instant t, chaque position p et chaque composante
-c, on a ``W(t,p,c)=U(t,p,c)+V(t,p,c)`` (que l'on peut noter également
-``W(:,:,:)=U(:,:,:)+V(:,:,:)`` compte-tenu de la convention présentée
-plus haut). Ce n'est cependant pas une règle et l'utilisateur peut
-très bien manoeuvrer les champs en détaillant et mixant les
-composantes (par exemple ``W(:,:,3)=5+U(:,:,1)*V(:,:,2)``), ou encore
-ne travailler que sur un domaine spatial et/ou temporel particulier
-(cf. |REF_EDF_VCA_H-I2C-2009-03595-FR|_ §5.4.1).
-
-On formalise donc le concept d'opération par les propriétés suivantes:
-
-* L'opérateur peut produire un champ (par exemple la somme de deux
- champs W=sum(U,V)=U+V), une valeur numérique (par exemple la moyenne
- spatiale d'un champ m=smoy(U)) ou une valeur logique (par exemple le
- test d'égalité de deux champs b=isequal(U,V));
-* L'opérateur peut être paramétré par la donnée de valeurs numériques
- (par exemple, le changement d'unité peut être défini comme une
- multiplication par un scalaire V=multiply(U,1000)=1000*U);
-* L'opérateur est caractérisé par un domaine d'application qui
- spécifie la portée de l'opération. Ce domaine comporte plusieurs
- dimensions:
-
- - Un domaine temporel T qui spécifie les pas de temps sur lesquels
- l'opération est appliquée;
- - Un domaine spatial D qui spécifie la limite de portée de
- l'opérateur et donc le domaine de définition du champ produit (qui
- correspond dans ce cas à une restriction du domaine de définition
- des champs en argument);
- - Un domaine de composantes C qui spécifie les composantes sur
- lesquelles l'opération est appliquée;
-
-.. note::
- Sur le plan informatique, l'opérateur aura également un paramètre
- appelé *option* qui pourra indiquer par exemple dans une
- opération unaire V=F(U) si le résultat V est une nouvelle instance
- de champ ou la valeur modifiée du champ de départ U. Il pourra
- également être amené à manoeuvrer des paramètres de type chaîne de
- caractères, par exemple pour les opérations de changement de nom
- des champs.
-
-De manière générale, on utilisera la notation
-**(W|y)=OP[D,C,T](P,U,V,...)** pour désigner une opération OP:
-
-* **(V|y)**: V ou y désignent respectivement un résultat de type
- champ ou de type valeur numérique ou logique;
-* **[T,D,C]**: le domaine d'application de l'opérateur avec T le
- domaine temporel, D le domaine spatial et C le domaine des
- composantes;
-* **P,U,V,...**: les paramètres numériques P (liste de valeurs
- numériques) et les champs U,V,... en arguments de l'opérateur;
-
-On note également les particularités suivantes pour certaines
-opérations:
-
-* Le domaine de définition du champ produit par une opération peut
- être différent du domaine de définition des champs en argument. Par
- exemple, dans le cas d'une opération de projection de champ, le
- domaine spatial résultat peut être modifié par rapport au domaine de
- définition initial, soit par la modification de la zone géométrique,
- soit par modification des entités de maillage support.
-* En dehors des opérations de type dérivée et intégrale, les valeurs
- résultats sont déterminées de manière locale en chaque point du
- domaine d'application. Par exemple, l'addition W=U+V consiste à
- produire un champ W dont les valeurs en chaque point p sont la somme
- des valeurs des composantes de U et V en ce point p: ``W=U+V <=>
- W(:,p,:)=U(:,p,:)+V(:,p,:)`` pour tout point p du domaine
- d'application D.
-
-Concept de domaine d'application
---------------------------------
-
-Un domaine d'application est associé à une opération (et non pas à un
-champ). Il a pour objectif de restreindre la portée de l'opération en
-terme spatial, temporel, jeu des composantes.
-
-Pour ce qui concerne le domaine spatial D, plusieurs modalités de
-définition sont envisagées:
-
-* la donnée d'un maillage ou d'un groupe d'éléments du maillage;
-* un système de filtres qui peut combiner:
-
- - une zone géométrique définie indépendamment du maillage (boîte
- limite par exemple),
- - des critères conditionnant le calcul (par exemple U(t,p,c)=1 si
- V(t,p,c)<seuil).
-
-.. warning:: Version 2010: D pourra correspondre au maillage complet
- et dans la mesure du possible à un groupe d'éléments du maillage
-
-Ce domaine d'application peut être différent du domaine de définition
-des champs mais il doit être compatible (recouvrement spatial partiel
-au moins et même support d'entité de maillage). Ainsi, sans précision
-particulière, une opération s'applique à l'ensemble du domaine de
-définition des champs en argument (qui dans la pratique MED est
-spécifié par le support et correspond en général au maillage
-complet).
-
-Limites d'utilisation
----------------------
-
-Plusieurs situations doivent être examinées pour poser les limites
-d'utilisation:
-
-* Les champs en argument n'ont pas tous le même domaine de définition,
- par exemple parcequ'il ne sont pas définis sur les mêmes zones
- géométriques ou parcequ'ils ne sont pas donnés sur le même type
- d'entité de maillage. On peut imaginer dans ce cas produire le
- résultat sur les zones de recouvrement uniquement.
-* Le domaine de définition des champs et le domaine d'application de
- l'opérateur ne sont pas compatibles, par exemple parcequ'on demande
- une restriction sur une zone géométrique qui ne fait pas partie de
- la zone de définition du champ d'entrée. A priori, ce type
- d'opération est déclaré en échec.
-* Les champs en argument ne sont pas définis sur les mêmes pas de
- temps. Si l'opération est tolérée (techniquement MEDCoupling permet
- de le faire), le pas de temps résultat est indéfini.
-
-.. warning:: **A faire**: spécifier les modalités de prise en compte de
- ces différentes situations (au moins sur le plan conceptuel).
-
-Au delà de ces limites conceptuelles, il faut avoir en tête les
-limites techniques liées à l'usage de MED mémoire (paquet
-MEDCoupling). Par exemple, MEDCoupling impose que les champs opérandes
-soient définis sur le même maillage support (on parle ici de l'objet
-informatique correspondant au maillage). Deux champs construits sur le
-même maillage (du point de vue conceptuel) mais issus de deux fichiers
-med différents sont considérés comme des champs définis sur des
-maillages support différents, c'est-à-dire que les objects
-informatiques correspondant aux maillages sont différents (chargés de
-deux fichiers différents). En l'état, il est donc impossible par
-exemple de faire la comparaison de champs résultats d'une étude
-paramétriques. MEDCoupling fournit une solution qu'il faudra mettre en
-oeuvre de manière ergonomique au niveau du module MED. Il est possible
-de changer le maillage support M1 d'un champs par un maillage M2 à
-partir du moment où les maillages M1 et M2 sont identiques
-géométriquement à une erreur près qu'il est possible de spécifier.
-
-.. note::
- D'autres situations limites peuvent être évoquées sous l'angle
- informatique. Ce sont des situations qui a priori n'ont pas de
- raison d'exister sur le plan conceptuel mais qui peuvent très bien
- survenir au niveau du module informatique compte-tenu des
- particularités du modèle MED. Par exemple:
-
- * Le nombre et la nature des composantes ne sont pas identiques
- pour tous les champs d'entrée. Par exemple, U défini ses
- composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les
- défini comme U(:,:,1)=Uz, U(:,:,2)=Ux, U(:,:,3)=Uy. Cette
- situation peut être gérée techniquement par exemple au moyen
- d'une carte de correspondance qui accompagnerai chacun des champs
- pour exprimer le sens physique de chaque composants (histoire de
- ne pas ajouter des choux et des carottes).
-
-Spécifications générales
-========================
-
-Le diagramme ci-dessous représente un découpage fonctionnel qui rend
-compte de l'expression des besoins:
-
-.. image:: images/xmed-functions.png
- :align: center
-
-On peut identifier les fonctionnalités suivantes:
-
-* **Opérations**: fonctions de manipulation de champs proprement
- dites;
-* **Persistance**: fonctions d'enregistrement persistant et de
- chargement des données (au format med fichier)
-* **Visualisation**: fonctions de contrôle visuel des champs
- manipulés
-* **Export des données**: fonction de transposition des données de
- champs dans un format textuel directement exploitable et de manière
- autoportante dans une autre application, par exemple en python au
- moyen des structures de données Numpy.
-
-Ces fonctions s'articulent autour d'un conteneur qui héberge les
-champs manipulés et les supports de ces champs (représenté par le
-cylindre central).
-
-Un scénario d'utilisation type est:
-
-* Préparation des champs à manipuler, par deux moyens complémentaires:
-
- - Utilisation des fonctions de persistance: chargement depuis un
- fichier med d'un ensemble de champs qui partagent le même espace
- de définition;
- - Utilisation des opérations de champs: chargement d'un maillage
- depuis un fichier med, puis création ab initio de champs au moyen
- des opérations de champs;
-
-* Manipulation des champs par application des opérations à
- disposition, puis contrôle visuel des résultats produits au moyen
- des fonctions de visualisation mises à disposition par SALOME;
-* Restitution des résultats produits, par deux moyens complémentaires:
-
- - Restitution des champs produits et/ou modifiés sous une forme
- persistante (fichier med);
- - Restitution d'une partie seulement des résultats sous forme de
- tableaux de valeurs sauvegardés dans un fichier texte ou exporté
- sous forme de tableau numpy
-
-.. _xmed-specifications:
-
-Spécification des opérations
-============================
-
-Le cahier des charges définit trois catégories d'opérations
-mathématiques:
-
-* **Les opérations arithmétiques**, dans lesquelles le résultat à la
- position p et à l'instant t ne dépend que des données à la position
- p et à l'instant t;
-* **Les opérations d'interpolations**, dans lesquelles le résultat
- est exprimé sur des entités de maillages différentes ou est projeté
- sur une zone géométrique différente du domaine de définition
- initial;
-* **Les opérations globales**, dans lesquelles le résultat peut
- demander l'agrégation des valeurs sur plusieurs position p ou
- plusieurs pas de temps t (calcul d'extremum, d'intégrale);
-
-Auxquelles, on peut ajouter à des fins de gestion des données:
-
-* **Les opérations de génération**, qui permettent de créer un champ
- sur un maillage vierge ou d'étendre le domaine spatial de définition
- d'un champ;
-* **Les opérations d'ordre sémantique**, qui permettent de modifier
- les méta-données associées aux champs (nom, unité, ...)
-* **Les opérations de diagnostic**, qui permettent d'effectuer une
- analyse particulière d'un champ et/ou des éléments de maillage
- associés et de fournir un compte-rendu, sous la forme d'une
- structure de données ou d'un texte formaté affichable dans
- l'interface utilisateur.
-
-La suite de la section décrit les spécifications prévues pour chaque
-type d'opération unitaire. Un dernier paragraphe concerne les
-modalités de combinaison des opérations et spécifie la définition d'un
-domaine d'application sur une opération, qui permet de restreindre la
-portée de l'opération en terme spatial, temporelle ou nature des
-composantes impliquées.
-
-Les opérations arithmétiques
-----------------------------
-
-Les opérations arithmétiques regroupent:
-
-* les **opérations algébriques** (+, -, x, /);
-* les **opérations vectorielles** (produit scalaire, produit
- vectoriel, produit tensoriel);
-* l'**application d'une fonction mathématique** à variable scalaire
- (exponentielle, logarithme, fonctions trigonométriques, valeur
- absolue, partie entière) ou à variable de type champ (les fonctions
- de norme par exemple).
-
-Pour les besoins des spécifications informatiques, il est plus commode
-de classer ces opérations en deux catégories:
-
-* les **opérations unaires**, qui prennent un opérande unique en
- argument. C'est le cas de la plupart des fonctions mathématiques
- envisagées;
-* les **opérations binaires**, qui prennent deux opérandes en
- argument. C'est le cas des opérations algébriques et des opérations
- vectorielles.
-
-A partir de cette classification, il convient de distinguer trois
-formes d'usage selon la nature des opérandes:
-
-* les opérandes sont exclusivement des scalaires (typiquement des
- valeurs de composantes des champs et des paramètres numériques). Par
- exemple::
-
- W(:,:4) = 1+2xU(:,:,2)+V(:,:,3)
-
-* les opérandes sont exclusivement des champs. Par exemple::
-
- W = U + V (addition)
- W = U ^ V (produit vectoriel)
-
-* les opérandes sont des champs et des paramètres numériques. Par exemple::
-
- W = 3xU - 2xV
- W = U + 2
-
-Le premier cas de figure (opérandes scalaires) est trivial car les
-règles mathématiques conventionnelles s'appliquent et sont
-implémentées dans tous les langages (Python et C++ en
-particulier). Les cas 2 et 3 par contre doivent être précisés car (i)
-les règles de comportement ne peuvent pas être simplement déduites des
-règles mathématiques (quel est le résultat de ``W = U + 2`` ?) et
-(ii) certaines écritures ne peuvent avoir aucun sens (par exemple
-``W = 2 / U``). Il convient donc de préciser les conventions et
-les limites sur ces deux cas de figure.
-
-Dans le cas des opérations unaires où l'opérande est un champ, on doit
-distinguer deux cas d'usage:
-
-* l'application d'une fonction mathématique à valeur de type champ. Ce
- cas est trivial également et on applique la règle d'usage de la
- fonction. C'est typiquement le cas des fonctions de calcul de
- norme.
-* l'application d'une fonction mathématique à valeur scalaire. Dans ce
- cas, on convient d'appliquer la fonction de manière unitaire sur
- chacune des composantes c du champ: ``W(:,:,c) = OP( U(:,:,c)
- )``
-
-Dans le cas des opérations binaires, on recense les combinaisons
-d'opérandes suivantes (les lettres capitales représentent des champs,
-et les lettres minuscules une valeur scalaire qui peut être un
-paramètre numérique ou la composante d'un champ):
-
-* U+V ajoute les composantes en regard: W(:,:,c)=U(:,:,c)+V(:,:,c)
-* U-V soustrait les composantes en regard: W(:,:,c)=U(:,:,c)-V(:,:,c)
-* U*V multiplie les composantes en regard: W(:,:,c)=U(:,:,c)*V(:,:,c)
-* U/V divise les composantes en regard: W(:,:,c)=U(:,:,c)/V(:,:,c)
-* U+x ajoute x à toute les composantes: W(:,:,c)=U(:,:,c)+x
-* U*x multiplie toutes les composantes par x: W(:,:,c)=U(:,:,c)*x
-* U.V produit scalaire des champs U et V: W(:,:c)=U(:,:,c)*V(:,:,c)
-* U^V produit vectoriel des champs U et V: W(:,:1)=U(:,:,2)*V(:,:,3)-U(:,:,3)*V(:,:,2), ...
-
-.. note::
- Pour ce qui concerne les opérations vectorielles, un convention
- implicite est appliquée par laquelle on suppose que les composantes
- sont rangées dans l'ordre des dimensions spatiales U1=Ux, U2=Uy,
- U3=Uz. Sur le plan informatique au niveau du modèle MEDMEM, ceci
- n'est pas garanti et aucun élément du modèle ne permet de
- contraindre l'application de cette convention. Il convient donc de
- prévoir des fonctions techniques qui permettront de mettre en
- correspondance les indices de composantes et les dimensions
- spatiales (par exemple par la données d'une carte de correspondance
- applicable à un ensemble de champs).
-
-.. warning::
- A développer:
-
- * Analyse dimensionnelle du champ résultats pour adapter
- l'unité. Par exemple, si on fait UxV où U et V sont exprimés en
- [m] alors le résultat est en [m2].
-
-Les opérations d'interpolation
-------------------------------
-.. warning:: Non prévues au programme 2010.
-
-Les opérations mathématiques globales
--------------------------------------
-.. warning:: Non prévues au programme 2010.
-
-Les opérations de génération
-----------------------------
-.. warning:: EN TRAVAUX
-
-Les opérations de génération sont des fonctions qui permettent de
-créer un champ sur un domaine du maillage où il n'est pas défini
-initialement. Deux cas de figure peuvent se présenter:
-
-* Le champ n'existe pas et il doit être créé sur un domaine à définir;
-* Le champ existe mais les valeurs ne sont pas définies sur l'ensemble
- du maillage.
-
-On peut envisager plusieurs modalités de mise en oeuvre:
-
-* le prolongement par une valeur constante (ou plus généralement par
- une fonction de l'espace?);
-* les valeurs du champs sont données par une fonction f(p,t) qui prend
- la position p et le pas de temps t en argument;
-* on peut prédéfinir le champ position **r** qui porte les
- coordonnées spatiales de l'élément de maillage support, puis faire
- une opération arithmétique standard.
-
-Les opérations d'ordre sémantique
----------------------------------
-.. warning:: EN TRAVAUX
-
-Concerne:
-
-* le changement de nom du champ
-* le changement d'unité du champ (il s'agit ici de conserver la
- cohérence entre la valeur numérique et l'attribut "unité" d'un
- champ.
-
-Les opérations de diagnostic
-----------------------------
-.. warning:: EN TRAVAUX. A faire en fonction des besoins des cas d'application
-
-On peut identifier plusieurs types d'opérations:
-
-* les opérations à diagnostic booléen, par exemple
- b=isequal(U,V)=[U=V] (où [.] signifie évaluation de la condition
- entre crochers)
-* les opérations à diagnostic textuel, par exemple afficher les
- méta-données associées à un champs (unité, nom, maillage support,
- type d'entité, pas de temps, ...)
-* les opérations à diagnostic structuré, qui donneraient une structure
- de données exploitable au niveau d'un code logiciel.
-
-Combinaison des opérations
---------------------------
-.. warning:: EN TRAVAUX. Indiquer les règles de combinaison (associativité, commutativité, ...)
-
-Définition d'un domaine d'application
--------------------------------------
-Pour rappel, un domaine d'application peut être associé à une
-opération pour restreindre la portée de l'opération en terme spatial,
-temporelle ou nature des composantes impliquées.
-
-.. warning:: Todo: spécifier comment on le définit et les modalités d'applications.
-
-Spécification de l'ergonomie
-============================
-
-L'ergonomie générale d'utilisation du module de manipulation de champs
-est inspirée des logiciels comme octave ou scilab. Elle associe une
-interface graphique, pour sélectionner et préparer les données, avec
-une interface texte (la console python) pour le travail effectif sur
-les données:
-
-* L'**interface graphique** a pour fonction essentielle de sélectionner et
- préparer les champs à manipuler dans l'interface texte, puis
- fournit des fonctions pour la gestion générale des données
- (chargement, sauvegarde, contrôle visuel, export).
-* L'**interface texte** offre un jeu de commandes pour manipuler les
- champs (afficher les données, effectuer des opérations), piloter les
- fonctions d'affichage (contrôle visuel au moyen des modules VISU
- et/ou PARAVIS) et communiquer avec l'interface graphique (ajouter
- des nouveaux champs dans l'espace de gestion, mettre à jour les
- méta-données d'un champ).
-
-Sur le plan de l'ergonomie, cela se traduit par un processus de
-travail dans lequel on peut distinguer différentes phases:
-
-* Une phase de préparation des champs à manoeuvrer sous la forme de
- variables nommées et simples à manipuler dans l'interface
- textuelle. Lors de cette phase, l'utilisateur spécifie de manière
- graphique tout ce qui peut être définis à l'avance et pour toute la
- durée du processus de travail. Par exemple, en spécifiant le nom des
- fichiers med source des données et les noms des champs à utiliser
- dans ces fichiers, le pas de temps de travail, le jeu des
- composantes à considérer, le domaine d'application des opérations;
-* Une phase de manipulation des champs proprement dite, qui a lieu
- principalement dans l'interface textuelle, et qui peut s'accompagner
- de contrôle visuel des résultats et/ou d'export à destination
- d'outils complémentaires indépendants (gnuplot, python, ...);
-* Une phase de restitution des champs produits pour assurer la
- persistance des données de travail. Tout les champs créés par les
- manipulations au niveau de l'interface textuelle ne sont pas à
- sauvegarder, et on on propose donc à l'utilisateur les moyens de
- choisir les champs à conserver. Cette phase peut amener
- l'utilisateur à préciser les informations manquantes, comme les noms
- de fichiers, les noms de champs produits, les unités, ...
-
-Dans ce cadre, l'utilisation type des fonctions de manipulation de
-champs est un processus de la forme suivante:
-
-1. Chargement d'un fichier med dans SALOME et exploration du contenu,
- composé de maillages, sur lesquels sont définis des champs, pouvant
- contenir un ou plusieurs pas de temps.
-2. Sélection (graphique) des champs à manipuler, avec la possibilité
- de préciser des restrictions d'utilisation (pas de temps,
- composantes, groupe de maille).
-3. Création de nouveaux champs par l'exécution d'opérations
- algébriques (+,-,*,/) entre champs, l'application de fonctions
- mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
- "from scratch" à partir d'un maillage support.
-4. Contrôle visuel rapide des champs produits (avec les modules VISU
- et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
- utilisateur)
-5. Enregistrement d'une partie des champs produits dans un fichier med
-
-
-Les espaces de données utilisateur
-----------------------------------
-
-Sur le plan conceptuel, on est amené à définir deux espaces de données
-utilisateur:
-
-* **l'espace des données source** (*dataspace*), dans lequel
- l'utilisateur définit les sources de données med (*datasource*),
- c'est-à-dire les fichiers med dans lesquels sont lus les champs
- et maillages. Cet espace est en lecture seule et permet
- l'exploration des sources de données (aperçu des maillages et des
- champs).
-* **l'espace des données de travail** (*workspace*), dans lequel
- l'utilisateur dépose les champs et maillages à utiliser, puis range
- les champs produits au travers des fonctions de manipulation de
- champs.
-
-La figure ci-dessous en donne une représentation imagée avec le
-support de l'interface graphique du module (interface non définitive
-affichée ici pour illustration des spécifications):
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-.. note:: Techniquement, les données sources sont rangées dans l'étude
- SALOME et peuvent être explorées au moyen de l'object browser. Les
- données de travail sont rangées dans un arbre complémentaire et
- manipulable dans la console python.
-
-Le principe général est que **les données sources ne sont jamais
-modifiées**. Le dataspace est un espace de chargement qui permet
-d'explorer puis de sélectionner les données à manipuler. L'utilisateur
-travaille à partir de maillages et de champs chargés préalablement
-dans cet espace, mais ne peut en aucun cas les modifier
-directement. Pour cela, il doit d'abord les sélectionner pour
-utilisation dans l'espace de travail. Ce choix garantie l'intégrité
-des sources de données et permet de rejouer la séquence de travail à
-partir de zéro en cas de besoin (on efface le tableau noir et on
-recommence). Par ailleurs, il permet d'assister graphiquement la
-définition du champs à manipuler effectivement, en particulier pour
-affecter un nom de variable de manipulation.
-
-Les captures d'écrans suivantes montrent le principe d'utilisation sur
-le cas de la sélection d'un pas de temps à utiliser dans l'espace de
-travail. Les données à manoeuvrer (maillage et/ou champs) sont
-sélectionnées pour utilisation dans l'espace de travail, où elles
-peuvent être modifiées et/ou utilisées dans les opérations de
-champs. Ici, le champ est désigné par la varibale ``f4`` dans
-l'interface textuelle:
-
-* Sur cette première capture, on sélectionne le pas de temps n°4 du
- champs ``Pulse`` définit sur le maillage ``Grid_80x80`` de la source
- de données ``timeseries.med`` (concrètement le fichier
- ``timeseries.med``) pour faire apparaître ensuite le menu contextuel
- et choisir l'option "Use in workspace":
-
-.. image:: images/xmed-gui-datasource-contextmenu_70pc.png
- :align: center
-
-* Cette capture montre une fenêtre de dialogue qui invite
- l'utilisateur à spécifier un alias pour la variable python qui
- va permettre la manipulation du champ dans l'interface textuelle de
- l'espace de travail (par défaut, le nom complet du champ est
- proposé). Ici, l'utilisateur spécifie ``f4``:
-
-.. image:: images/xmed-gui-datasource-useinworkspace_70pc.png
- :align: center
-
-* La validation de la fenêtre provoque l'ajout du champs dans l'espace
- de travail (le champ est désormais disponible à la manipulation) et
- définit une variable python de nom ``f4`` qui permet la manipulation
- du champ:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-result_70pc.png
- :align: center
-
-Modalités d'utilisation
------------------------
-
-.. warning:: cette section est à nettoyer car elle contient des
- informations redondantes avec d'autres sections précédentes ou pire
- qui contredisent des sections précédentes.
-
-Dans le cadre défini ci-dessus, une session d'utilisation type est:
-
-* Sélectionner les sources de données puis définir le domaine
- d'application (espace, temps, composantes), avec éventuellement
- l'assistance d'une interface graphique;
-* Charger les champs en conséquence dans l'espace de travail. Cette
- opération propose de définir une variable python pour manipulation
- dans l'interface textuelle.
-* Effectuer les opérations dans l'espace de travail, c'est-à-dire en
- ligne de commandes python (ce qui demandera sans doute un travail
- conséquent de simplification et d'assistance en ligne). Par exemple,
- si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de
- travail, alors on peut en faire la somme par la commande::
-
- >>> r=fa+fb
-
-* Effectuer les contrôles visuel et les diagnostics en ligne de
- commandes python (cf. :ref:`Spécification des fonctions de
- visualisation<specification_visualisation>`)::
-
- >>> view(r)
-
-* Enregistrer les champs produits dans l'espace de travail sous forme
- de fichier med.
-
-Sur cette base, on peut envisager une grande variété de cas d'utilisation:
-
-* La structure MED (champs, maillage et groupes de mailles) est
- chargée dans le dataspace (l'étude SALOME techniquement) et peut
- être explorée au niveau de l'arbre d'étude. L'arbre peut faire
- apparaître:
-
- - les maillages et les groupes (qui peuvent être utilisés
- éventuellement pour restreindre le domaine d'application)
- - les champs dont on peut explorer les composantes et les itérations
-
-* On sélectionne plusieurs champs, éventuellement en sélectionnant les
- pas de temps, les composantes et les domaines d'application spatiaux
-* Menu contextuel --> Modifier un champ, Créer un champ, Prolonger un
- champ, ....
-* On choisi pour la suite "Créer un champ", une fenêtre de dialogue
- s'affiche avec les saisies préremplies avec les données
- sélectionnées. Il est possible de rajouter des éléments ou préciser
- le domaine d'application
-* Une partie de la boîte de dialogue est réservée à la saisie de la
- ligne de commande python qui permet la création du nouveau champ. Le
- nom dans l'étude pour le nouveau champ, ainsi que son nom python,
- sont spécifié par l'utilisateur ({{H|un peu à la mode du module
- system}}).
-* L'opération est exécutée dans l'espace utilisateur (l'interface
- python), de sorte que les variables soient projetées dans cet espace
- et manipulables après l'opération au besoin. Par ailleurs,
- l'utilisateur peut visualiser les ligne de commandes nécessaires à
- taper pour exécuter sa requête.
-
-.. _specification_visualisation:
-
-Spécification des fonctions de visualisation
-============================================
-
-Dans le cadre du module MED, on appelle *fonction de visualisation*
-une fonction qui permet d'avoir un aperçu graphique d'un champ, par
-exemple au moyen d'une carte de champ construite sur une de ses
-composante. Il s'agit là de vue de contrôle pour avoir une idée rapide
-de la forme du champs. Pour créer des représentations spécifiques, on
-préférera passer par les fonctions d'export vers le module PARAVIS.
-
-Les modules VISU et PARAVIS offre des interface de programmation C++
-et python qui permettent le pilotage depuis un module tiers comme le
-module MED. On peut donc envisager une fonction de visualisation
-intégrée au module de manipulation de champs, c'est-à-dire que l'on
-déclenche sans sortir du module MED, et qui exploite les fonctions de
-visualisation des modules VISU et/ou PARAVIS.
-
-Les captures d'écran ci-dessous illustrent la mise en oeuvre de la
-fonction de visualisation:
-
-* Sélection d'un champ pour faire apparaitre le menu contextuel et
- choisir l'option "Visualize":
-
-.. image:: images/xmed-gui-datasource-visualize_70pc.png
- :align: center
-
-* Cette option déclenche l'affichage d'une carte de champ sur le cadre
- d'affichage des viewers SALOME:
-
-.. image:: images/xmed-gui-datasource-visualize-result_70pc.png
- :align: center
-
-Cette fonction est également disponible en ligne de commandes de
-l'interface textuelle. Par exemple si ``f4`` désigne un champ de
-l'espace de travail (importé des données source ou construit par les
-opérations de champs), alors, on obtient une carte de champ par la
-commande::
-
- >>> view(f4)
-
-On peut remarquer d'ailleurs sur la capture d'écran de droite
-ci-dessus que la demande de visualisation déclenche l'exécution de la
-commande ``view`` dans la console de travail sur un champ identifié
-par son numéro (3 dans l'exemple).
-
-.. note:: Tous les champs, qu'ils soient des champs chargés d'une
- source de données ou construits par des opérations de champs sont
- identifiés par un numéro unique et invariant tout au long de la
- session de travail.
-
-Spécification des fonctions de persistance
-==========================================
-
-On adopte le principe de fonctionnement suivant:
-
-* Le module n’assure pas la persistence au sens SALOME du terme,
- c’est-à-dire qu’il ne permet pas la sauvegarde du travail dans une
- étude au format hdf, ni le dump sous la forme de script python
- SALOME. Le besoin n'est pas avéré et on peut même dire que ça n'a
- pas de sens compte-tenu de l'usage envisagé pour le module MED.
-* Par contre, le module fournit des fonctions de sauvegarde du travail
- sous forme de fichiers med, l’export vers les modules VISU et
- PARAVIZ, ou même la sauvegarde de l’historique de l’interface de
- commandes.
-
-Ainsi donc, l'utilisateur aura une fonction (probablement graphique)
-pour définir la sélection des champs de l'espace de travail à
-sauvegarder.
-
-Spécification des fonctions d'export
-====================================
-
-.. warning:: EN TRAVAUX.
-
-Plusieurs export peuvent être proposés:
-
-* Export des champs vers le module PARAVIZ, dans l'objectif par
- exemple d'en faire une analyse visuelle plus poussée qu'avec les
- cartes de champs disponibles par défaut dans le module MED
-* Export des données sous forme de tableau numpy, par exemple pour
- permettre un travail algorithmique sur les valeurs des champs.
-
-Spécifications techniques
-=========================
-
-Il s'agit d'exprimer ici les contraintes techniques applicables à la
-conception et au développement du nouveau module MED.
-
-Implantation technique du module
---------------------------------
-
-Il est convenu que le module MED existant dans la plate-forme SALOME
-incarne le module de manipulation de champ. Dans la pratique, il
-s'agit d'identifier clairement les parties à conserver, d'une part,
-puis les parties à re-écrire, d'autre part. On peut partir sur les
-hypothèses techniques suivantes:
-
-* Le noyau du module en charge des opérations de manipulation de
- champs proprement dites est construit sur la base des paquets
- logiciels MEDCoupling (lui-même basé sur le INTERP_KERNEL) et
- MEDLoader.
-* L'interface graphique du module MED est complétement re-écrite et
- remplacée par une interface adaptée spécialement à la manipulation
- des champs et la gestion des données associées
-* Le contrôle visuel pourra être déclenché dans les visualisateurs
- SALOME (servis par les modules VISU et/ou PARAVIZ);
-* Le module n'assure pas la persistence au sens SALOME du terme,
- c'est-à-dire qu'il ne permet pas la sauvegarde du travail dans une
- étude au format hdf, ni le dump sous la forme de script python
- SALOME.
-* Par contre, il fournit des fonctions de sauvegarde du travail sous
- forme de fichiers med, l'export vers les modules VISU et PARAVIZ, ou
- même la sauvegarde de l'historique de l'interface de commandes.
-
-L'implantation technique des développements est représentée sur la
-figure ci-dessous:
-
-.. image:: images/xmed-implantation.png
- :align: center
-
-Le schéma représente les packages logiciels qui composent le module
-MED (cf. |REF_CEA_VBE_MEDMEM|_):
-
-* La partie MEDMEM, représentées en blanc. Cette partie est conservée
- pour compatibilité ascendante au niveau des applications métier qui
- ont fait le choix historique de s'appuyer sur MEDMEM. Cette partie
- du module MED aura tendance à disparaitre dans le futur au bénéfice
- de MEDCoupling et MEDLoader.
-* La partie MEDCoupling, représentée en orange et qui founrnit le
- modèle MED mémoire de référence (composé de maillage et de champs)
- et l'interface de programmation pour manipuler le modèle. Le paquet
- MEDLoader est une extention dédiée à la persistence au format med
- fichier (lecture et écriture de champs et de maillage dans des
- fichiers med).
-* La partie à développer pour la manipulation de champ, représentée en
- bleu.
-
-.. note:: MEDCoupling peut être vu comme une structure de donnée
- particulièrement adaptée à la manipulation des gros volumes de
- données, en particulier par l'exploitation des possibilités de
- parallélisation et la réduction de la tailles des structures de
- données. En contrepartie, elle peut présenter un périmètre
- fonctionnel moins large que MEDMEM. Pour cette raison, MEDMEM avait
- été choisi comme socle de développement du prototype en 2010:
-
- * MEDCoupling ne permet pas de gérer des maillages composés de
- plusieurs type de mailles et il est exclus de le faire évoluer
- dans ce sens (c'est un choix fait pour les objectifs de
- performances évoqués plus haut);
- * MEDCoupling ne permet pas de gérer les supports qui expriment les
- champs aux noeuds par élément ni aux points de gauss. Cette
- seconde limitation a disparu en 2011.
-
- Aujourd'hui, on fait clairement le choix de MEDCoupling pour sa
- qualité et sa robustesse, dans l'objectif d'une meilleure
- maintenance à long terme. Par ailleurs, les différences
- fonctionnelles avec MEDMEM, si elles existaient encore en 2012 pour
- les besoins de la manipulation de champs, pourront être résorbées
- dans un futur proche.
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, guide utilisateur
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide d'utilisation de l'interface graphique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Ce document est un guide rapide pour l'utilisation de l'interface
-graphique du module MED. Il montre comment utiliser le module sur la
-base de quelques exemples de référence, inspirés des cas d'utilisation
-identifiés lors de l'analyse des besoins en matière de manipulation de
-champs.
-
-.. warning:: Le document est autonome, mais il est vivement conseillé
- de parcourir au préalable (ou en parallèle) :doc:`le document de
- spécifications<medop-specifications>`, au moins pour fixer les
- concepts et la terminologie.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation générale du module MED
-===================================
-
-L'ergonomie générale d'utilisation du module de manipulation de champs
-est inspirée des logiciels comme octave ou scilab. Elle associe une
-interface graphique, pour sélectionner et préparer les données, avec
-une interface texte (la console python) pour le travail effectif sur
-les données.
-
-Pour cela, le module propose deux espaces utilisateurs qui sont
-symbolisés par les rectangles rouges et vert sur la capture d'écran
-ci-dessous:
-
-* **l'espace des données** (*dataspace*), dans lequel l'utilisateur
- définit les sources de données med (*datasource*), c'est-à-dire les
- fichiers med dans lesquels sont lus les champs et maillages. Cet
- espace permet l'exploration des maillages et des champs fournis par
- les différentes sources de données.
-* **l'espace de travail** (*workspace*), dans lequel l'utilisateur
- peut déposer des champs sélectionnées dans l'espace source, pour
- ensuite les travailler par exemple pour produire des nouveaux champs
- au moyen des fonctions de manipulation fournies par l'interface
- textuelle (console python TUI).
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-L'utilisation type des fonctions de manipulation de champs suit un
-processus de la forme suivante:
-
-1. Chargement d'un fichier med dans l'espace de données (dataspace) et
- exploration du contenu, composé de maillages et de champs définis
- sur ces maillages et pouvant contenir un ou plusieurs pas de temps.
-2. Sélection (graphique) des champs à manipuler dans l'espace de
- travail (workspace), avec la possibilité de préciser des
- restrictions d'utilisation (pas de temps, composantes, groupe de
- maille).
-3. Création de nouveaux champs par l'exécution d'opérations
- algébriques (+,-,*,/) entre champs, l'application de fonctions
- mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
- "from scratch" sur un maillage support.
-4. Contrôle visuel rapide des champs produits (avec les modules VISU
- et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
- utilisateur)
-5. Enregistrement d'une partie des champs produits dans un fichier med
-
-
-Tour rapide des fonctions du module MED
-=======================================
-
-Cette section présente des exemples d'utilisation du module XMED sous
-la forme de "storyboard", et illustre au passage les fonctions mises à
-disposition par le module.
-
-.. warning:: Cette section est en travaux. Tant que cet avis n'aura
- pas disparu, veuillez en considérer le plan et le contenu encore
- incomplets, temporaires et sujets à caution.
-
-Exemple 1: Explorer des sources de données
-------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * ajouter une source de données
- * fonctions "Extends field series", "Visualize"
-
-.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
- :height: 16px
-
-.. |ICO_XMED| image:: images/ico_xmed.png
- :height: 16px
-
-.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
- :height: 16px
-
-.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
- :height: 16px
-
-Au démarrage, le module de manipulation de champs, identifié par
-l'icône |ICO_XMED|, présente une interface vierge:
-
-.. image:: images/xmed-gui-start.png
- :align: center
- :width: 800px
-
-La première étape consiste à ajouter une ou plusieurs source de
-données med dans le "dataspace". Pour cela, on clique sur l'icône "Add
-datasource" |ICO_DATASOURCE_ADD| qui propose de sélectionner un
-fichier med:
-
-.. image:: images/xmed-gui-datasource-selectfile.png
- :align: center
- :width: 800px
-
-L'opération ajoute une nouvelle entrée (datasource) dans l'espace de
-données (dataspace). Le contenu peut être exploré en parcourant
-l'arborescence. La figure ci-dessous (image de gauche) montre le
-résultat du chargement du fichier ``timeseries.med`` contenant un
-maillage de nom ``Grid_80x80`` sur lequel est défini un champ au noeud
-de nom ``Pulse``. Par défaut, la composition du champs (en terme de
-pas de temps et de composantes) n'est pas affichée pour éviter
-l'encombrement visuel de l'arbre. On doit faire la demande explicite
-au moyen de la commande "Expand field timeseries"
-|ICO_DATASOURCE_EXPAND| disponible dans le menu contextuel associé aux
-champs. Le résultat est affiché sur l'image centrale. La liste des
-itérations du champ ``Pulse`` peut être consultée.
-
-.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
- :height: 340px
-
-+--------------------------+--------------------------+--------------------------+
-| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
-+--------------------------+--------------------------+--------------------------+
-
-.. note:: En toute rigueur, le concept de *champ* dans le modèle MED
- désigne une itération donnée. Un ensemble d'itérations est désigné
- par le terme *série temporelle de champs*. Par abus de langage, et
- s'il n'y a pas ambiguité, on utilisera le nom du champ pour
- désigner à la fois le champs proprement dit ou la série temporelle
- à laquelle il appartient.
-
-Enfin, il est possible au niveau du dataspace de visualiser la forme
-générale du champ au moyen d'une carte scalaire affichée dans le
-viewer de SALOME. Pour cela, on sélectionne le pas de temps à
-visualiser et on utilise la commande "Visualize" |ICO_DATASOURCE_VIEW|
-disponible dans le menu contextuel associé:
-
-.. image:: images/xmed-gui-datasource-visualize-zoom.png
- :align: center
- :width: 800px
-
-.. note:: Cette représentation graphique a pour objectif le contrôle
- visuel rapide. Aussi, les fonctions du module VISU sont employées
- par défaut, mais il est possible de faire l'affichage des cartes
- scalaires au moyen du module PARAVIS (choix de préférence non
- implémenté pour le moment, mais techniquement réalisable).
-
-Exemple 2: Rassembler des champs issus de différentes sources
--------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * fonction "Use in workspace"
- * fonction "Save"
-
-.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
- :height: 16px
-.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
- :height: 16px
-
-L'objectif est de récupérer des données issues de différents fichiers
-med, puis de les rassembler dans un même fichier en sortie.
-
-On commence par ajouter les sources de données med dans l'espace de
-données (dataspace). Dans l'exemple ci-dessous, l'espace de données
-contient deux sources de nom ``parametric_01.med`` et
-``smallmesh_varfiled.med``. La première source contient le maillage
-``Grid_80x80_01`` sur lequel est défini le champ ``StiffExp_01``. La
-deuxième source contient le maillage ``My2DMesh`` sur lequel sont
-définis deux champs de noms respectifs ``testfield1`` et
-``testfield2``:
-
-.. image:: images/xmed-userguide-example2-datasource.png
- :align: center
- :width: 800px
-
-Pour l'exemple, on souhaite rassembler les champs ``StiffExp_01`` et
-``testfield2`` dans un fichier de nom ``result.med``. La procédure
-consiste à importer les deux champs dans l'espace de travail
-(workspace), puis à sauvegarder l'espace de travail. Pour cela, on
-sélectionne les champs et on utilise la commande "Use in workspace"
-|ICO_DATASOURCE_USE| disponible dans le menu contextuel. Les deux
-champs sélectionnés apparaissent dans l'arborescence de l'espace de
-travail:
-
-.. image:: images/xmed-userguide-example2-workspace.png
- :align: center
- :width: 800px
-
-La sauvegarde de l'espace de travail est faite au moyen de la commande
-"Save workspace" |ICO_WORKSPACE_SAVE| disponible dans la barre
-d'outils du module. Une fenêtre de dialogue invite l'utilisateur à
-spécifier le nom du fichier de sauvegarde:
-
-.. image:: images/xmed-userguide-example2-workspace-save.png
- :align: center
- :width: 800px
-
-Ce fichier ``result.med`` peut ensuite être rechargé dans le module
-XMED (ou les modules VISU ou PARAVIS) pour vérifier la présence des
-champs sauvegardés.
-
-.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
-.. (invalid mesh on field)
-
-.. _xmed.userguide.exemple3:
-
-Exemple 3: Appliquer une opération mathématique sur des champs
---------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * exécution d'opérations mathématiques dans la console TUI
- * fonction "put" pour référencer un champ de travail dans la liste
- des champs persistant.
- * fonction "Visualize" depuis le TUI.
-
-L'usage le plus courant du module de manipulation de champs est
-d'exécuter des opérations mathématiques dont les opérandes sont des
-champs ou des composantes de ces champs.
-
-On se place dans une situation où les sources de données sont définies
-dans le "dataspace" (dans l'exemple ci-après, une série temporelle de
-nom ``Pulse``, contenant 10 pas de temps, définis sur un maillage de
-nom ``Grid_80x80``, le tout issu du datasource ``timeseries.med``).
-
-Comme vu précedemment, pour manoeuvrer un champ dans l'espace de
-travail, on sélectionne ce champ, puis on exécute la commande "Use in
-workspace" |ICO_DATASOURCE_USE| du menu contextuel. Dans le cas
-présent, un seul champ est sélectionné (contre deux dans l'exemple
-précédent) et la commande ouvre alors une fenêtre de dialogue qui
-permet de préciser les données sur lesquelles on souhaite
-effectivement travailler et comment on veut les manoeuvrer:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
- :align: center
- :width: 800px
-
-.. note:: En l'état actuel du développement, l'interface propose
- uniquement de définir le nom de la variable sous laquelle doit être
- manoeuvré le champ dans la console de travail (TUI). Dans une
- version ultérieure, il est prévue de pouvoir préciser la ou les
- composante du champs à utiliser et un groupe de maille pour définir
- une restriction géométrique. Inversement, il sera également
- possible de choisir une série temporelle complète pour faire des
- opérations globales sur l'ensemble des pas de temps.
-
-Aprés validation, le champ est placé dans l'arborescence du
-"workspace" et une variable de nom ``<alias>`` est créée
-automatiquement dans la console de travail pour désigner le
-champ. Dans cet exemple, ``<alias>`` vaut ``f3``, positionné ainsi par
-l'utilisateur pour rappeler que la variable correspond au pas de temps
-n°3:
-
-.. image:: images/xmed-gui-workspace.png
- :align: center
- :width: 800px
-
-La manipulation peut commencer. Dans l'exemple ci-dessous, on crée le
-champ ``r`` comme le résultat d'une transformation afine du champ
-``f3`` (multiplication du champ par le facteur 2.7 auquel on ajoute
-l'offset 5.2)::
-
- >>> r=2.7*f3+5.2
-
-On peut poursuivre la manipulation du champs avec une variété
-d'opérations qui sont détaillées dans les spécifications du module
-(cf. :ref:`Spécification des opérations<xmed-specifications>`):
-
- >>> r=f3/1000 # les valeurs de r sont celles du champ f3 réduites d'un facteur 1000
- >>> r=1/f3 # les valeurs de r sont les inverses des valeurs de f3
- >>> r=f3*f3 # les valeurs de r sont celles du champ f3 élevées au carré
- >>> r=pow(f3,2) # même résultat
- >>> r=abs(f3) # valeur absolue du champ f3
- >>> ...
-
-Les opérations peuvent utiliser plusieurs opérandes de type champs. Si
-``f4`` désigne le pas de temps n°4 du champ ``Pulse``, alors on peut
-calculer toute combinaison algébrique des deux champs::
-
- >>> r=f3+f4
- >>> r=f3-f4
- >>> r=f3/f4
- >>> r=f3*f4
-
-Avec au besoin l'utilisation de variables scalaires::
-
- >>> r=4*f3-f4/1000
- >>> ...
-
-Dans ces exemples, la variable ``r`` désigne un champ de travail qui
-contient le résultat de l'opération. Par défaut, ce champ de travail
-n'est pas référencé dans l'arborescence du workspace. Si on souhaite
-tout de même le référencer, par exemple pour qu'il soit pris en compte
-dans la sauvegarde, alors on tape la commande::
-
- >>> put(r)
-
-La fonction ``put`` a pour but de marquer le champ en argument comme
-persistent, puis de le ranger dans l'arborescence du "workspace" afin
-qu'il soit visible et sélectionnable. En effet, parmi tous les champs
-qui pourront être créés dans la console pendant la session de travail,
-tous n'ont pas besoin d'être sauvegardés. Certains sont même des
-variables temporaires qui servent à la construction des champs
-résultats finaux. C'est pourquoi, seuls les champs rangés dans
-l'arborescence du workspace sont enregistrés lors de la demande de
-sauvegarde du workspace.
-
-Les variables définies dans la console ont d'autres utilités. Tout
-d'abord, elles permettent d'imprimer les informations concernant le
-champ manoeuvré. Pour cela, on tape simplement le nom de la variable
-puis retour::
-
- >>> f3
- field name (id) = Pulse (3)
- mesh name (id) = Grid_80x80 (0)
- discretization = ON_NODES
- (iter, order) = (3,-1)
- data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
-
-Elle peut également être utilisée comme argument des commandes de
-gestion disponibles dans l'interface textuelle (dont la liste
-détaillée est décrite à la section :ref:`Documentation de l'interface
-textuelle<xmed.userguide.tui>`). Par exemple, la fonction ``view``
-permet d'afficher la carte scalaire du champ dans le viewer::
-
- >>> view(f3)
-
-Donne:
-
-.. image:: images/xmed-gui-workspace-view.png
- :align: center
- :width: 800px
-
-.. note:: On remarquera ici qu'il est facile de comparer deux pas de
- temps d'un champ, par exemple en calculant la différence ``f3-f4``,
- puis en affichant un aperçu de la carte scalaire résultat au moyen
- de la fonction ``view``::
-
- >>> view(f3-f4)
-
-On peut enfin tout simplement afficher les données du champs par la
-commande ``print``::
-
- >>> print f3
- Data content :
- Tuple #0 : -0.6
- Tuple #1 : -0.1
- Tuple #2 : 0.4
- Tuple #3 : -0.1
- Tuple #4 : 0.4
- ...
- Tuple #6556 : 3.5
- Tuple #6557 : 3.3
- Tuple #6558 : 1.5
- Tuple #6559 : 0.3
- Tuple #6560 : 0.2
-
-Il est important de noter que les opérations entre champs ne peuvent
-être faites qu'entre champs définis sur le même maillage. Il s'agit là
-d'une spécification du modèle MED qui interdit d'envisager les
-opérations entre champs définis sur des maillages géométriquement
-différents. Techniquement, cela se traduit par l'obligation pour les
-objets informatique *champs* de partager le même objet informatique
-*maillage*.
-
-Dans l'hypothèse où on souhaite utiliser des champs définis sur des
-maillages différents, par exemple pour manoeuvrer les valeurs des
-champs à l'interface de deux maillages partageant une zone géométrique
-2D, il faut d'abord ramener tous les champs sur le même maillage de
-surface par une opération de projection.
-
-.. note:: Même si ceci est techniquement possible avec la bibliothèque
- MEDCoupling, cet type d'opération de projection n'est pas encore
- disponible dans le module de manipulation de champs (prévu en
- 2012).
-
-Un autre besoin plus classique est l'utilisation de champs définis sur
-des maillages géométriquement identiques, mais techniquement
-différents, par exemple lorsqu'ils sont chargés de fichiers med
-différents. Pour traiter ce cas de figure, la bibliothèque MEDCoupling
-prévoit une fonction de "Changement du maillage support", dont
-l'utilisation au niveau du module de manipulation de champs est
-illustrée dans :ref:`l'exemple 4<xmed.userguide.exemple4>` ci-après.
-
-.. _xmed.userguide.exemple4:
-
-Exemple 4: Comparer des champs issues de différentes sources
-------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Changement du maillage support "change underlying mesh"
-
-On se place ici dans le cas de figure où des champs ont été produits
-sur le même maillage, au sens géométrique, mais enregistrés dans des
-fichiers med différents. C'est le cas par exemple d'une étude
-paramétrique où plusieurs calculs sont effectués avec des variantes
-sur certains paramètres du modèle simulé, chaque calcul produisant un
-fichier med.
-
-Soit ``parametric_01.med`` et ``parametric_02.med`` deux fichiers med
-contenant les champs que l'on souhaite comparer, par exemple en
-calculant la différence des valeurs et en visualisant le résultat.
-
-Aprés le chargement des sources de données dans le module XMED,
-l'utilisateur se trouve en présence de deux maillages, au sens
-technique du terme cette fois-ci, c'est-à-dire que les champs sont
-associées à des objets informatiques maillage différents, bien que
-géométriquement identiques.
-
-Or, les fonctions de manipulation de champs ne permettent pas les
-opérations sur des champs dont les maillages supports sont différents
-(voir la remarque à la fin de :ref:`l'exemple
-3<xmed.userguide.exemple3>`).
-
-Pour résoudre ce cas de figure, le module de manipulation de champs
-met à disposition la fonction "Change underlying mesh" qui permet de
-remplacer le maillage support d'un champ par un autre à partir du
-moment où les deux maillages sont géométriquement identiques,
-c'est-à-dire que les noeuds ont les mêmes coordonnées spatiales.
-
-.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
- :height: 16px
-
-Dans l'exemple proposé, l'utilisateur sélectionne le premier pas de
-temps du champ ``StiffExp_01`` du "datasource" ``parametric_01.med``,
-puis l'importe dans l'espace de travail au moyen de la commande "Use
-in workspace" |ICO_DATASOURCE_USE|. Il sélectionne ensuite le premier
-pas de temps du champs ``StiffExp_02`` du "datasource"
-``parametric_02.med``, mais l'importe dans l'espace de travail au
-moyen de la commande "Change underlying mesh" |ICO_DATASOURCE_CHG|. La
-fenêtre de dialogue ci-dessous s'affiche et invite l'utilisateur à
-choisir le nouveau maillage support par sélection dans l'arborescence
-du "dataspace":
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
- :align: center
-
-Dans cet exemple, on sélectionne le maillage ``Grid_80x80_01`` support
-du champ ``StiffExp_01``, avec lequel on souhaite faire la
-comparaison. Après validation, l'arborescence du workspace contient le
-champ ``StiffExp_02`` défini sur le maillage ``Grid_80x80_01``:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
- :align: center
-
-.. note:: La fonction "Change underlying mesh" ne modifie pas le champ
- sélectionné dans le "dataspace" (principe de base de fonctionnement
- du dataspace), mais crée une copie du champ dans l'espace de travail
- pour ensuite remplacer le maillage support. D'où le nom par défaut
- pour le champ ``dup(<nom du champ sélectionné>)`` (dup pour
- "duplicate").
-
-Il reste à associer une variable à ce champ pour le manipuler dans la
-console. Ceci peut être fait au moyen de la commande "Use in console",
-disponible dans le menu contextuel du workspace.
-
-En définitif, si ``f1`` désigne le champ issu du datasource
-``parametric_01.med`` et ``f2`` le champ issu du datasource
-``parametric_02.med`` par la procédure décrite ci-dessus, alors la
-comparaison des deux grandeurs peut être faite comme pour le cas de
-:ref:`l'exemple 3<xmed.userguide.exemple3>`::
-
- >>> r=f1-f2
- >>> view(r)
-
-.. note:: En remarque générale sur cet exemple, il convient de noter
- les points suivants:
-
- * l'égalité géométrique de deux maillages est établie à une marge
- d'erreur prés qu'il est possible de définir techniquement, mais
- qui n'est pas ajustable au niveau de l'interface du module de
- manipulation de champs. Elle est fixée à une valeur standard qui
- permet de traiter la plupart des cas utilisateur. On verra à
- l'usage s'il est nécessaire de remonter ce paramètre au niveau de
- l'interface.
- * L'utilisateur doit faire la démande explicite de changer le
- maillage support d'un champ, en prévision de la comparaison de
- champs issus de datasource différentes. Il s'agit là d'un choix
- fonctionnel délibéré pour que l'utilisateur garde trace des
- modifications faites sur les données (pas de modification
- automatiques à l'insu de l'utilisateur, même sous prétexte
- d'amélioration de l'ergonomie).
-
-
-Exemple 5: Créer un champ sur un domaine spatial
-------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * initialisation par une fonction de la position spatiale
- * initialisation sur un groupe de maille
-
-Le domaine géométrique de définition du champs à créer est spécifié
-ici par la donnée d'un groupe de mailles. Ce cas d'usage est
-typiquement prévu pour produire les conditions de chargement initial
-d'une structure, par exemple en définissant un champ sur une surface
-de la géométrie, identifiée par un nom de groupe de mailles.
-
-.. warning:: DEVELOPPEMENT EN COURS
-
-Exemple 6: Extraire une partie d'un champ
------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * extraire une composante (ou un sous-ensemble des composantes)
- * extraire un domaine géométrique (valeurs sur un groupe de maille)
- * extraire un ou plusieurs pas de temps.
-
-.. warning:: DEVELOPPEMENT EN COURS
-
- On doit illustrer ici les fonctions de restriction, qui
- permettraient de récupérer certaines composantes uniquement. Le
- principe est qu'on crée un nouveau champ qui est une restriction du
- champ argument à une liste de composantes à spécifier (utiliser la
- fonction __call__ des fieldproxy).
-
-Pour l'extraction des pas de temps, on peut se ramener au cas de
-l'exemple 2 avec une seule source de donnée.
-
-Exemple 7: Créer un champ à partir d'une image to[mp]ographique
----------------------------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Création d'un champ sans datasource (ni maillage, ni champs), à
- partir d'un fichier image
-
-En tomographie ou en topographie, les appareils de mesure produisent
-des images qui représentent une grandeur physique en niveaux de gris
-sur un plan de coupe donné. L'image ci-dessous représente par exemple
-une vue interne du corps humain faite par IRM:
-
-.. image:: images/xmed-irm.png
- :align: center
- :width: 600px
-
-Cette image est un ensemble de pixels organisés sur une grille
-cartesienne. Elle peut donc être modélisée sous la forme d'un champ
-scalaire dont les valeurs sont définies aux cellules d'un maillage
-réglés de même taille que l'image (en nombre de pixels):
-
-.. image:: images/xmed-irm-field.png
- :align: center
- :width: 600px
-
-Le module de manipulation de champ fournit un utilitaire appelé
-``image2med.py`` qui permet d'appliquer ce principe à la conversion
-d'un fichier image en fichier med contenant la représentation de
-l'image sous forme d'un champ scalaire (seul le niveau de gris est
-conservé)::
-
- $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
-
-.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
- :height: 16px
-
-Cette opération de conversion peut être faite automatiquement dans
-l'interface graphique du module au moyen de la commande "Add Image
-Source" |ICO_IMAGESOURCE| disponible dans la barre d'outils. Cette
-commande ouvre la fenêtre suivante pour inviter l'utilisateur à
-choisir un fichier image:
-
-.. image:: images/medop_image2med_dialog.png
- :align: center
-
-Le nom du fichier med résultat est proposé par défaut (changement de
-l'extention en ``*.med``) mais il peut être modifié. Enfin, on peut
-demander le chargement automatique du fichier med produit pour ajout
-dans l'espace de donnée. Les champs peuvent alors être manipulés comme
-dans les cas d'utilisation standard.
-
-Par exemple, l'image ci-dessous affiche le résultat de la différence
-entre deux images, ajoutée à l'image de référence: si i1 et i2
-désignent les champs créés à partir des deux images, on représente ``r
-= i1 + 5*(i2-i1)`` où le facteur 5 est arbitraire et sert à amplifier
-la zone d'intérêt (en haut de l'oeil gauche):
-
-.. image:: images/xmed-irm-diff.png
- :align: center
- :width: 600px
-
-L'exemple ci-dessous est le résultat du chargement d'une image
-tomographique issue du projet MAP (Charles Toulemonde,
-EDF/R&D/MMC). L'image tomographique:
-
-.. image:: images/champ_altitude_MAP.png
- :align: center
- :width: 600px
-
-Le résultat du chargement:
-
-.. image:: images/medop_image2med_tomographie.png
- :align: center
- :width: 800px
-
-Exemple 8: Continuer l'analyse dans PARAVIS
--------------------------------------------
-
-.. note:: Cet exemple présente les fonctions:
-
- * Export de champs vers le module PARAVIS.
-
-Les possibilités de représentation graphique des champs fournies par
-le module MED ont pour seul objectif le contrôle visuel rapide. Par
-défaut, le viewer de VISU est employé.
-
-Pour une analyse plus détaillées des champs, il est nécessaire de
-poursuivre le travail dans PARAVIS. Le module de manipulation de
-champs offre une fonction qui simplifie ce passage, en faisant le
-chargement automatique dans PARAVIS et en proposant une visualisation
-par défaut (carte de champs scalaire).
-
-Pour cela, il faut sélectionner dans l'espace de travail les champs à
-exporter, puis déclencher la fonction d'export depuis le menu
-contextuel associé:
-
-.. image:: images/medop_exportparavis.png
- :align: center
-
-Les champs sélectionnés sont regroupés dans une entrée MED du
-navigateur PARAVIS, et le premier champ est affiché sous forme de
-carte de champ:
-
-.. image:: images/medop_exportparavis_result.png
- :align: center
- :width: 800px
-
-.. note:: La fonction d'export est une fonction de confort. La même
- opération peut être faite manuellement en procédant d'abord à
- l'enregistrement des champs sous forme de fichier MED, puis en
- chargeant le fichier généré dans le module PARAVIS pour
- visualisation.
-
-.. _xmed.userguide.tui:
-
-Utilisation de l'interface textuelle du module MED (TUI)
-========================================================
-
-Toutes les opérations menées au moyen de l'interface graphique peuvent
-être réalisées (avec plus ou moins de facilité) avec l'interface
-textuelle. Le module de manipulation de champs peut même être utilisé
-exclusivement en mode texte. Pour cela, on lance la commande::
-
- $ <path/to/appli>/medop.sh
-
-Cette commande ouvre une console de commandes ``medop>``. Un fichier
-med peut être chargé et travaillé, par exemple pour créer des champs à
-partir des données du fichier.
-
-Que l'on soit en mode texte pur ou en mode graphique, un séquence de
-travail type dans la console peut ressembler au jeu d'instructions
-suivantes::
-
- >>> load("/path/to/mydata.med")
- >>> la
- id=0 name = testfield1
- id=1 name = testfield2
- >>> f1=get(0)
- >>> f2=get(1)
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- >>> r=f1+f2
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=testfield1+testfield2)
- >>> r.update(name="toto")
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=toto)
- >>> put(r)
- >>> save("result.med")
-
-Les commandes principales sont:
-
-* ``load``: charge un fichier med dans la base de données (utile
- uniquement en mode texte pur)::
-
- >>> load("/path/to/datafile.med")
-
-* ``la``: affiche la liste de tous les champs chargés en base de données ("list all")
-* ``get``: définit un champ dans l'espace de travail à partir de son
- identifiant (utile plutôt en mode texte pur car l'interface
- graphique permet de faire cette opération par sélection d'un champ
- dans le dataspace)::
-
- >>> f=get(fieldId)
-
-* ``ls``: affiche la liste des champs présent dans l'espace de travail ("list")
-* ``put``: met un champ en référence dans l'*espace de gestion*::
-
- >>> put(f)
-
-* ``save``: sauvegarde tous les champs référencés dans l'espace de
- gestion dans un fichier med::
-
- >>> save("/path/to/resultfile.med")
-
-.. note:: On peut faire à ce stade plusieurs remarques:
-
- * la commande ``load`` charge uniquement les méta-informations
- décrivant les maillage et les champs (noms, type de
- discrétisation, liste des pas de temps). Les maillages et les
- valeurs physiques des champs sont chargées ultérieurement (et
- automatiquement) dés lors qu'elles sont requises par une
- opération. Dans tous les cas, les données med (méta-informations
- et valeurs) sont physiquement stockées au niveau de l'espace
- *base de données*.
- * la commande ``get`` définit en réalité un *manipulateur de champ*
- dans l'espace de travail, c'est-à-dire une variable qui fait la
- liaison avec le champ physique hébergé dans la base de
- données. Les données physiques ne circulent jamais entre les
- espaces, mais restent centralisées au niveau de la base de
- données.
-
-Les commandes TUI suivantes nécessitent de travailler dans
-l'environnement graphique:
-
-* ``visu``: afficher une carte de champ pour contrôle visuel rapide
- (pas de paramettrage possible)
-
- >>> view(f)
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2010
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs du développement
-=====================================
-
-En matière de développement:
-
-* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
- module SALOME diffusable dans la version d'exploitation 2010 (SALOME
- 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
- devoir tenir compte des contraintes de temps SALOME et (ii) le
- produit envisagé fin 2010 est une maquette qui cherche à éprouver
- l'ergonomie générale d'utilisation et en aucun cas on ne peut
- garantir la réalisation d'un module SALOME compatible avec les
- exigences de mise en exploitation.
-* On ne cherche pas d'emblée à capturer tous les cas d'application,
- mais à concevoir un développement qui acceptera les extensions de
- périmètres dans des conditions raisonnables. Aussi, les
- fonctionnalités développées seront celles qui sont nécessaires à la
- réalisation des cas d'application de référence;
-
-En matière d'ergonomie:
-
-* L'interface utilisateur de référence (appelé espace de travail dans
- le volet de spécifications fonctionnelles) est l'interpréteur
- python. Les fonctionnalités doivent être pensées pour un usage
- adapté à une interface textuelle (TUI) de ce type.
-* La création d'une interface graphique (GUI) peut être envisagée en
- complément et comme un moyen de manipuler graphiquement les
- fonctionnalités développées pour l'interface textuelle et pour aider
- la préparation des variables dans l'interface python.
-* Le modèle d'un processus de manipulation de champs est:
-
- - Préparation du jeu de variables U, V, ... représentant les champs
- à manipuler. C'est à ce stade que l'on résoud la question de
- sélection des données (dans un champ publié dans l'arbre d'étude,
- par un module de calcul ou par chargement d'un fichier med)
- - Utilisation des variables avec une sémantique la plus proche
- possible du modèle conceptuel et des spécifications
- fonctionnelles;
- - Création des variables qui représentent les résultats des
- fonctions de manipulation;
- - Persistence (fichier med), visualisation (SALOME) ou export (vers
- une structure qui peut être directement utilisable en numpy)
-
-Sur le plan technique:
-
-* On souhaite spécifier clairement le conteneur SALOME des fonctions
- de manipulation de champs. Pour discussion:
-
- - Il apparaît que les modules SALOME MED et VISU contiennent déjà
- des fonctions qui peuvent faire partie des fonctions de
- manipulations de champs (en particulier pour l'exploration des
- structures MED, leur visualisation et la sélection des données à
- manipuler).
- - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
- tout cas pas sous sa forme de module SALOME) et compte-tenu du
- caractère obsolescent du module VISU (amené à être remplacé sur le
- plan fonctionnel par le module PARAVIS), on pourrait examiner la
- création d'un module dédié à la manipulation des maillages et des
- champs par l'agrégation technique au sein d'un même module des
- fonctions des modules MED et VISU.
-
-Au moins dans un premier temps, on se donne les limites suivantes:
-
-* Une opération ne peut pas combiner des pas de temps différents. Dans
- l'hypothèse où cette limite venait à être levée, on doit spécifier
- le pas de temps de la donnée résultat;
-* Le domaine d'application d'une opération pourra être défini
- exclusivement par la donnée d'un maillage ou un groupe d'éléments du
- maillage;
-* On ne traite pas le cas des champs qui prennent leurs valeurs aux
- points de gauss ou aux noeuds par élément. Une particularité de ces
- types de support est que le repérage de la position implique deux
- indices (par exemple l'indice de la maille, puis l'indice du point
- de gauss).
-
-Eléments de conception
-======================
-
-Plan général
-------------
-
-On peut par exemple imaginer une maquette du genre:
-
-* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
- structure des maillages et des champs dans l'arbre d'étude.
-* Sélectionner un élément (par exemple un pas de temps d'un champ) et
- le menu contextuel permet d'exporter ce champ dans la console python
- pour manipulation. Pour cela, s'inspirer de la fonction
- ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
- PythonConsole.
-* L'élément est marqué comme ayant été exporté, on peut imaginer une
- récupération ultérieure.
-* Exporter un deuxième champ cohérent avec le premier (même pas de
- temps et défini sur le même maillage avec le même support, on
- s'arrange pour).
-* Dans la console python, faire les opérations sur les champs
-* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
- ultérieure. C'est a priori le gros morceau qui consiste à faire un
- objet CORBA MED à partir d'un objet MED standard, en plus défini
- dans la console python (sous forme d'objet python).
-
-Quand ce premier cas d'utilisation est au point, on peut envisager de
-le compléter par les opérations suivantes
-
-* exporter le résultat med dans un fichier
-* visualiser les champs produits
-
-Plan de développement:
-
-* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
- d'architecture, l'opération physique se déroulera en définitif au
- niveau de MEDMEM pur.
-* Prévoir une implémentation des opérations sous forme de fonctions
- informatiques, même les opérations algébriques (+,-,*,/). Pour ces
- dernières et dans certaines conditions (quand on manipule
- directement les strutures MEDMEM et non pas les objets CORBA),
- l'utilisation des formes A+B, A-B, ... peuvent être rendues
- possibles. Dans ce cas, voir la possibilité de combiner plusieurs
- opérations algébriques sur une seule ligne: A+B-C*0.3.
-* On peut charger la structure MED sous forme d'objet CORBA publiable
- dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
- exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
- récupère que les informations nécessaires au chargement d'un champs:
- le nom du champs, le nom de son maillage associé, les identifiants
- du pas de temps, au besoin une structure Field non chargée (par
- exemple pour récupérer plus facilement le maillage).
-* Un mécanisme (à développer à partir du PyConsole par exemple)
- pourrait alors permettre le chargement des champs sélectionnés dans
- la console python et sous un nom facile à manoeuvrer. Prendre
- inspiration sur XCADGUI::LoadIntoPythonConsole().
-* A priori, les données sont physiquement chargée dans le GUI. Au
- besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
- CORBA field à partir d'un field standard (à tester).
-
-Une autre idée est de récupérer le pointeur CORBA MED dans la console
-python et de tirer les données à partir de là. Ajouter une couche de
-wrapping python pur pour gérer les cas de simplification (surcharge
-des opérations arithmétiques par exemple).
-
-Besoins complémentaires:
-
-* L'interpréteur doit contenir des éléments d'aide (par exemple un
- help qui liste les opérations possibles sur les champs chargés)
-* prévoir quelques fonctions de visu et de persistence. Cela commence
- probablement par des fonctions de publication dans l'étude des
- champs créés par les opérations de manipulation. Les champs sont
- physiquement ajouté automatiquement à la structure med par le MedOp
- mais il n'est pas obligatoirement publié => fournir un moyen de
- publication.
-
-Limitations actuelles (liées à la conception de MEDMEM):
-
-* les champs doivent être gérés par la même structure MED car ils
- doivent partager le même support.
-* les opérations possibles dans MEDMEM sont entre champs pris sur un
- pas de temps (Q: les pas de temps peuvent-ils être différents).
-
-
-Développements
---------------
-
-Développement de classes proxy:
-
-* FieldProxy, FieldTimeSeriesProxy
-* Attention pour les éries temporelles, le SUPPORT med peut être
- différent en chaque pas de temps (par exemple en cas d'extension
- spatiale du champ au cours du temps).
-
-MEDMEM_MedDataManager:
-
-* FIX: test de l'implémentation C++ au travers de la fonction test() du
- MedOperator ==> OK. Quand on fait la même opération depuis python
- via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
- destructeur du champ semble être appelé. Pb de gestion des pointeurs?
-
-
-Evolutions à prévoir
-====================
-
-Concernant MEDMEM:
-
-* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
- plusieurs fois de suite puisqu'on recycle la référence si elle est
- déjà chargée.
-* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
- exemple avec un getField qui renvoie le champ s'il est déjà chargé
- ou le charge et le renvoie sinon).
-* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
- passant a priori par le driver associé. Plusieurs driver peuvent
- être associés à une structure MED car les données peuvent être
- chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
- étendre la structure MED pour avoir accés à la liste des driver puis
- de cette liste déduire les noms des fichiers.
-* IMP: Opérations combinant des champs sur des support différents ne
- peuvent pas être faites par l'API (une exception est levée en cas de
- supports incompatibles), mais on peut imaginer le faire en
- manoeuvrant les tableaux de données directement.
-* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
- et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
-* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
- préalablement ajouté: une fonction removeField en complément de
- addField.
-
-Concernant l'interface SALOME_MED:
-
-* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
- structure MED et requêtées au niveau des classes proxy en spécifiant
- les identifiants des champs impliqués et les paramétres requis (pas
- de temps en particulier).
-
-Concernant le module MED:
-
-* IMP: pourvoir exporter la structure med dans un fichier med (la
- structure ayant pu être enrichie par la publication de champs créés
- par les operations de champs.
-
-
-Historique des travaux
-======================
-
-20100726 : mise au point du schéma de conception
-------------------------------------------------
-
-Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
-raisons:
-
-* MED Coupling ne peut pas gérer des mailles de dimensions différentes
- dans un même modèle (choix faits dans un soucis de performance dans
- l'accès à une structure de donnée compact). On peut contourner le
- problème en définissant deux champs pour traiter chacun des type de
- mailles.
-* Un champ repose sur un maillage complet (pas de notion de profil,
- mais cela peut être émulé en créant deux maillages)
-* Le concept de point de gauss n'existe pas (pas implémenté)
-
-TODO:
-
-* Idéalement, il conviendrait de faire un état des lieux du module
- MED, en particulier des éléments MEDMEM (le coeur), les interfaces
- CORBA associées (MED.idl implémenté dans le package source
- MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
- implémenté dans le package source MED) et le GUI (MedGUI.cxx
- implémenté dans le package source MEDGUI).
-
-* Ergonomie TUI et modèle CORBA associé:
-
- 1. Charger un objet medmem (puis les objets métier mesh et field)
- sur un domaine d'application donné.
- 2. En faire des variables disponibles dans l'interface TUI et que
- l'on peut manipuler dans des opérations algébriques.
- 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
- les autres modules SALOME.
-
-* Compléter le diagramme de la structure informatique de MED (en
- particulier l'implémentation des interface IDL).
-* Préparer un module de travail XMED (organisation d'une bibliothèque)
-
-Tests à réaliser:
-
-* Est-il possible de faire des opérations algébriques à partir des
- objets SALOMEMED (objects CORBA MED)?
-* Création d'un objet MED_i à partir d'une objet MED pur préalablement
- chargé en mémoire.
-
-A retenir:
-
-* Des opérations de champs sont possibles sur des champs à des pas de
- temps fixés. Si l'opération doit être menée sur plusieurs pas de
- temps, alors itérer sur chaque pas de temps. L'idée ici est
- d'introduire le concept de série temporelle de champs en temps
- qu'objet manipulable.
-* Pour deux champs différents de la même structure MED, la données des
- identifiants dt et it ne correspond pas forcément au même instant
- absolu (en tout cas rien ne le garanti, même si c'est tout de même
- une pratique courante).
-
-20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
---------------------------------------------------------------------------
-
-XMED: svn révision 16
-Travailler avec le fichier de donnée testfield.med joint.
-
-
-20101007 : Vers une maquette CORBA
-----------------------------------
-
-Le contexte d'utilisation des opérations de champs est l'environnement
-SALOME. Le support de gestion des données est donc l'étude SALOME. Au
-plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
-session SALOME (soit par un code de calcul intégré, soit par
-chargement des données à partir d'un fichier med). Ces objets sont en
-général référencés dans l'étude SALOME sous la forme d'objets CORBA de
-classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
-SObject (Study Object) dont un attribut est une référence vers un
-objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
-MEDMEM::Field.
-
-On peut donc envisager une solution dans laquelle on donne à
-l'utilisateur des poignées de manipulation des objets
-SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
-type proxy. Cela signifie que l'utilisateur ne manipule pas
-directement des objets MEDMEM mais des objets python qui font
-l'interface (à concevoir et implémenter, a priori avec un design
-pattern de type proxy).
-
-L'utilisation directe des objets MEDMEM aurait pu être une solution
-extremement pratique dans la mesure où ces objets en l'état peuvent
-être combinés dans des opérations de champs (c'est déjà
-implémenté). Par contre, ce procédé souffre de limitations importantes
-dans la gestion et la circulation des données pour les différents cas
-d'utilisation envisagés (visualisation, export, transfert à un autre
-module SALOME).
-
-L'avantage de la solution proposée est multiple:
-
-* Elle permet de travailler sur une structure MED cohérente pour
- intégrer les résultats des opérations de calculs et combiner des
- champs cohérents entre eux. Tout passe par des classes proxy qui
- pourront s'assurer de la cohérence des opérations demandées et
- exécuter automatiquement les fonctions de pré-traitement ou
- post-traitement requises pour ces opérations. On peut imaginer par
- exemple que les requêtes d'opération soient envoyées par les classes
- proxy à la structure MED à laquelle les champs sont associés pour
- piloter l'opération en MEDMEM pur.
-* Elle permet d'automatiser un certain nombre d'opérations
- implicites. Par exemple si deux champs ne sont pas définis dans la
- même unité, un changement d'unité peut être effectué automatiquement
- par la classe proxy avant de commander l'opération au niveau
- MEDMEM.
-* Elle permet de laisser les données sur le container SALOME et de
- réaliser des opérations sans rappatrier les données en local (qui
- peuvent être en trés grand nombre).
-* Elle permet d'étendre facilement l'ergonomie de manipulation des
- champs, par exemple en définissant la notion de *série temporelle de
- champs*, ou encore les concepts de *domaine de définition* évoqués
- dans les spécifications fonctionnelles.
-* Elle rend immédiat la circulation des données entre modules SALOME,
- puisque les champs restent accessble par des objets CORBA, en
- particulier pour la visualisation ou l'export des champs produits
- par les opérations.
-
-Elle a cependant des inconvénients et/ou limitations:
-
-* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
- les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
- se limite a priori aux opérations de champs (les opérations
- algébriques dans un premier temps).
-* Les champs à manipuler dans une opération donnée doivent être gérés
- par la même structure MED.
-
-Il est à noter également que les interfaces de programmation de
-SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
-permettre des requêtes de manipulations de champs (fonctions addition,
-soustraction, multiplication, ...). Pas de contrainte ici sur
-l'ergonomie puisque la manipulation par l'utilisateur se fera au
-niveau des classes proxy uniquement.
-
-
-Hypothèses:
-
-* On tente ici une maquette qui exploite dans la mesure du possible le
- fonctionnement actuel du module MED, en particulier la gestion des
- données dans l'étude.
-* Dans une deuxième version, on pourra examiner sérieusement la
- révision de la gestion des données dans le module, quitte à la
- spécifier et maquetter dans XMED pour intégration ultérieure dans
- MED. Exemple:
-
- - Pouvoir gérer plusieurs structures med dans l'étude.
-
-* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
- des données (gestion des chargements des champs en particulier,
- références croisées pour retrouver le med à partir du champ par
- exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
- faut pouvoir par ailleurs gérer indifféremment une structure med (et
- les champs qui y sont associés) qu'elle soit créée en mémoire from
- scratch ou chargée d'un fichier (donc attention avec les opérations
- de lecture read(), sur les maillages comme sur les champs). La
- structure med permet d'obtenir les méta données (meta-field par
- exemple) mais ne permet pas de savoir si les données sont
- physiquement chargées ou pas.
-
-
-Révisions:
-
-* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
- Première version qui permet d'importer un champ dans la console
- python sous la forme d'un FieldProxy. Ne permet pas encore de faire
- des opérations. Introduction dans le module MED de l'interface MEDOP
- pour prendre en charge les opérations sur les champs.
-
-
-20101019 : Maquette de démonstration pour l'addition
-----------------------------------------------------
-
-Cette maquette implémente une solution technique de bout en bout (de
-l'interface python aux objets MEDMEM, en passant par le fieldproxy
-puis les servants CORBA pour les operations, ...) mais sur le
-périmètre de l'addition de champs sur tout leur domaine de définition
-et pour un pas de temps donné.
-
-Limitations:
-
-* gére l'addition de champs de type double uniquement (parceque le
- reste n'est pas implémenté)
-
-Révisions:
-
-* XMED: svn révision 25
-* MED: cvs tag BR_medop_20101019
-
-
-20101020: Fonctions complémentaires
------------------------------------
-
-Cette version test la faisabilité des fonctions complémentaires pour
-accompagner la manipulation de champs. Cela comprend en particulier:
-
-* **la sauvegarde des champs produits** dans un fichier med (un champ ou
- toute la structure med). Pour cela, on définit un med proxy comme
- l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
- de fonction au niveau C++ pour permettre un usage au niveau du GUI
- C++?).
-* **la visualisation d'un champ** au moyen du module VISU.
-* **des fonctions d'aide interactives** pour assister l'utilisateur
- dans la console de manipulation des champs.
-
-
-Questions:
-
-* peut-on sauvegarder un champ unique?
-* peut-on faire en sorte que ce soit l'affectation à une variable qui
- provoque l'ajout du champ à la structure med (ou plus exactement qui
- supprime tous les champs intermédiaires).
-
-
-Révision:
-
-* XMED: svn revision 31
-* MED: cvs tag BR_medop_20101025
-
-
-20110606: commit avant transfert dans git
------------------------------------------
-
-* XMED: svn revision 53
-
-Les parties de MED utiles à MEDOP seront reversées dans XMED
-dans une première étape, puis le tout dans MED 6 au final.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2011
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Cas d'utilisation métier
-========================
-
-On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
-
- J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
- ajouter de nouveaux champs issus de champs existants. J'aimerais
- aussi pouvoir créer de nouveaux meds plus petits par extraction de
- certaines composantes de champs, certains groupes ou certains pas de
- temps.
-
-On peut exprimer le besoin sous la forme des cas d'utilisation
-suivants (use cases):
-
-* **UC1: combiner dans un même fichier med des champs issus de
- plusieurs sources de données**. On peut par exemple charger un
- premier fichier, puis ajouter à cette base des champs issus d'autre
- fichiers ou générés par manipulation de champs, ou encore générés
- par un module de calcul qui produirait directement du MEDCoupling.
-* **UC2: créer un champ contenant certaines composantes d'un autre
- champ**. On pense ici aux fonctions de restriction, qui permettraient
- de récupérer certaines composantes uniquement.
-* **UC3: créer un champ contenant certains pas de temps d'un autre
- champ**. C'est un cas particulier des fonctions de restriction
- évoquées ci-dessus.
-* **UC4: créer un champ comme la limitation d'un autre champ à un
- groupe de mailles**. C'est un cas particulier des fonctions de
- restriction évoquées ci-dessus. Notion de domaine spatial. A
- priori la notion de groupe est définie dans MEDLoader.
-
-On peut ajouter également les UC identifiés pour la maquette 2010:
-
-* **UC5: comparer des champs issus de source de données différentes**,
- par exemple des champs chargés de deux fichiers med différents et
- qui s'appuient sur le même maillage (au moins conceptuellement). Le
- problème technique ici est de pouvoir changer le maillage d'un
- champ, pour ramener tous les champs sur le même maillage (au sens
- informatique). Ceci est une contrainte de MEDCoupling, les
- opérations sur des champs A et B imposent que A et B soient définis
- sur le même maillage, i.e. le même objet informatique.
-* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
- de mailles. Ce cas d'usage est typiquement prévu pour produire les
- conditions de chargement initial d'une structure. Il s'agit ici
- d'initialiser un champ à partir de zéro sur une surface prédéfinie
- de la géométrie (par exemple spécifiée par un nom de groupe de
- mailles).
-
-Pour UC5: les sources de données sont référencées dans l'object
-browser. On importe explicitement les données dans l'espace de
-travail. On peut détecter que les maillages sont identiques et on
-propose à l'utilisateur de transférer le champ sur le maillage déjà
-présent. Sinon, les champs devront être référencés sur des maillages
-distincts dans l'arbre de l'espace de travail.
-
-Analyses préliminaires pour le chantier 2011
-============================================
-
-On fait le choix pour le chantier 2011 de travailler à partir de la
-bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
-le démonstrateur 2011).
-
-Analyse de MEDCoupling et MEDLoader
------------------------------------
-
-MEDCoupling est l'implémentation du modèle de données MED (avec
-recherche de minimisation des dépendances logicielles) et MEDLoader
-fournit une ensemble de fonctions pour le chargement des structures
-MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
-forme de fichiers.
-
-Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
-d'une grandeur physique sur un maillage pour un pas de temps donné. Un
-champ est caractérisé par:
-
-* un support spatial, le maillage
-* un type de discrétisation spatial, défini par l'emplacement des
- valeurs sur le maillage (sur les noeuds, sur les cellules, aux
- points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
- etc)
-* un pas de temps, défini par deux entiers (iteration, order) et un
- réel (timestamps)
-
-Dans cette implémentation, il existe une association 1..n entre un
-maillage et un champ (alors que dans MEDMEM, la structure
-intermédiaire SUPPORT est implémentée).
-
-MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
-des structures MEDCoupling au travers du bus CORBA. L'interface à ce
-jour est délibérément réduite. Des classes dites "Cliente" sont
-fournies pour piloter les servants CORBA depuis un contexte
-client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
-fonction de création d'une structure MEDCoupling à partir d'un
-pointeur vers un servant CORBA. La structure est créée localement
-(dans le contexte client) avec duplication des données issue de la
-structure encapsulée par le servant CORBA (récupération par la
-fonction de sérialisation).
-
-Aucune interface CORBA n'est défini pour MEDLoader.
-
-Questions:
-
-* Voir comment sont créés les servants, et surtout comment ils sont
- récupérés (via le lcc?)
-* Comment peut-on définir un champ sur un groupe de mailles (et non
- pas sur le maillage complet)? Comment peut-on extraire le champs
- circoncit à une groupe de mailles pour des opérations.
-
- - R: méthode changeUnderlyingMesh
-
-* Comment manipuler deux champs chargées de fichiers différents mais
- construit sur le même maillage (conceptuellement). On peut forcer la
- réassociation d'un champ sur un autre maillage?
-* Manipuler des champs de pas de temps différents? Différentes
- composantes d'un ou plusieurs champs?
-* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
-
-* mapper sur une image
-
-Improvments:
-
-* MEDLoader::Write should raise an exception if the filepath is not writable
-* MEDDataManager: développer une classe chapeau sur MEDCoupling et
- MEDLoader pour aider au chargement et la gestion de données MED
- (orienté manipulation de champs). Cette classe serait associée des
- structures légères FieldHandler et MeshHandler et des listes
- correspondantes pour la navigation dans les méta-données.
-* Sur base du MEDDataManager, prévoir des ports med pour yacs par
- lesquels pourrait transiter des handler.
-
-Nouveaux concepts à prendre en compte
--------------------------------------
-
-Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
-
-* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
- les fichiers med et obtenir les informations générales sur le
- contenu.
-* MEDFILEBROWSER: remplace le concept de driver et fournit les
- fonctions précédemment fournies par la classe MED pour obtenir les
- informations de structure.
-* Concept d'Extractor pour une lecture sélective des données de champs
- (suivant un critère d'extraction)
-* Il n'est plus nécessaire d'appeler les méthodes read explicitement
- sur les objets (MESH et FIELD) pour charger les données. Par
- ailleurs, on peut définir deux fois le même champs (double
- chargement a priori) sans lever d'exception).
-
-
-Analyse de conception pour le chantier 2011
-===========================================
-
-Composants SALOME (interfaces IDL)
-----------------------------------
-
-* MEDDataManager: défini une structure FIELD pour identifier un champ
- dans les requêtes. Il s'occupe également de la récupération physique
- des données, quelqu'en soit la source (fichier avec MEDLoader, autre
- module SALOME comme PARAVIS avec une méthode à définir)
-* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
- les structures FIELD du MEDDataManager. Reprendre l'interface de
- MEDOP.
-
-Use case à réaliser depuis un client python:
-
-* UC01: ajouter un fichier d'entrée et accéder aux informations
- concernant les champs. Ex: récupérer une structure champs par la
- donnée des paramètres primaires (nom identifiant, dt, it, nom du
- maillage).
-* UC02: créer des champs et les ajouter au MEDDataManager
-* UC03: mener des opérations basique sur les champs en console python
-
-Interface Utilisateur
----------------------
-
-L'interface utilisateur est composée des parties suivantes:
-
-* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
- le chargement des données dans l'espace de travail, au moyen d'une
- interface graphique;
-* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
- la création de champs, au moyen de commandes exécutées dans la
- console python.
-
-Le principe est que les champs sont préalablement chargés au niveau du
-composant SALOME au moyen de l'interface graphique (MEDGUI), puis
-manoeuvrés depuis l'application SALOME au moyen de variables proxy
-définies dans la console python (MEDTUI). Au chargement, les champs
-sont indéxés par le MEDDataManager, puis les index sont rendus
-accessibles au niveau du GUI au moyen d'une représentation
-arborescente de la structure MED. Les feuilles de l'arbre
-correspondent à des champs qui peuvent être sélectionnés et dont
-l'index peut être obtenu de la sélection.
-
-L'espace de travail est organisé autour du concept de
-"workspace". L'étude SALOME liste les datasource (les fichiers source
-des données med, mais peut-être aussi les référence vers des objets
-MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
-permet de voir la structure fine d'une source de données.
-
-Concernant MEDGUI:
-
-* la représentation des données (les champs et les maillages associés)
- doit permettre de récupérer par l'interface graphique les
- identifiants des champs à manipuler (a priori les structures FIELD
- définies par le composant MEDDataManager). Cela conduit à la mise en
- place des composants suivants:
-
- - MedDataModel hérité de TreeData. Il est peuplé avec les
- méta-données décrivant la structure MED explorée.
- - MedGuiManager qui permet l'implantation du doc widget de
- présentation
-
-TODO:
-
-* specifier le concept de workspace (qui a une entrée dans l'étude?)
- en bijection avec un datamanager
-* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
-
-Concernant MEDTUI:
-
-* Il fournit les classes FieldProxy
-
-Questions:
-
-* Comment traiter le cas du travail sur des composantes ciblées, plus
- généralement, comment introduire le concept de domaine
- d'application?
-* Prévoir des fonctions génériques (initialisation d'un champ sur un
- maillage avec une fonction analytique de la position, sauvegarder
- les champs créés dans un fichier med)
-
-
-Tâches de développement
-=======================
-
-T20110622.1: Gestion des données internes
------------------------------------------
-
-**Status: terminé.**
-Suite: fonction de sauvegarde au niveau graphique également
-
-On vise les cas d'utiliation suivants:
-
-* UC1: intégrer dans le datamodel du gui un champ créé dans la console
- python (et donc présent dans le datamanager du composant). Définir
- l'utilité?
-* UC2: renommer un champ et plus généralement changer ses méta-données
- (avec assurance de synchronisation entre toutes les données).
-* UC3: sauvegarder une sélection de champs. La sélection peut se faire
- dans l'arbre du datamodel gui.
-
-WARN: robustesse de fieldproxy
-
-
-
-T20110622.2: UC Initialisation/Création de champs
--------------------------------------------------
-
-**Status: à faire**
-
-Les cas implémentés à ce jour sont la création de champs à partir de
-champs existants et chargés d'un fichier med. On souhaite ici réaliser
-des cas 'utilisation autour de la création de champs "from scratch",
-s'appuyant tout de même sur un maillage chargé.
-
-UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
-champ (par exemple les conditions limites d'un problème de calcul).
-
-UC02: créer un champ avec des restrictions qui définissent le domaine
-d'application des opération de champs.
-
-UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
-composantes du champs vectoriel ou niveaux de gris pour un champ
-scalaire. Attention, pour ça, il faudra a priori fiare une projection
-du maillage cartesien de l'image sur le maillage (quelconque) sur
-lequel on souhaite définir le champ.
-
-UC04: créer un champ à partir d'un tableau numpy
-
-De manière générale, ce type de création sera assisté par le
-MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
-pour l'utilisateur.
-
-Par exemple, prévoir un menu contextuel qui propose les opérations
-possibles en fonction de la sélection (en plus de la fonction d'import
-dans la console python).
-
-TODO:
-
-* développer les fonctions d'initialisation, par exemple au moyen
- d'applyFunc et du mécanisme de callable?
-
-T20110622.3: documentation contextuel
--------------------------------------
-
-**Status: à faire**
-
-* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
- et fieldtools)
-* Faire un modèle générique de command (classe de base
-* Batir la doc des commandes sur cette base (lister toutes les
- instances de type Command par exemple)
-
-T20110622.4: remontée des exception du composant MEDCalculator
---------------------------------------------------------------
-
-**Status: en cours, compléter la couverture**
-
-Pour des messages contextuel sur les erreurs de calcul (ex: division
-par 0)
-
-* Poursuivre le travail fait sur getMedEventListener
-* Protéger tous les appels au composants effectués depuis la console
- python (prendre example sur la commande save)
-
-T20110624.1: gestion des données GUI
-------------------------------------
-
-**Status: à faire**
-
-
-
-Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
-
-* supprimer: supprime tout les champs associés
-* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
- cocher ceux qu'on veut sauvegarder.
-
-Le gui data model est réservé aux opérations sur les champs et à
-piloter leur import dans la console python.
-
-TODO:
-
-* Spécifier les concepts de workspace, database, et datasource, espace
- de gestion, ... et les associations. Simplifier avec l'appuie de use
- cases.
-* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
- l'ajout addChild est implémenté
-* Clic droit sur objets de l'arbre: dans la notification TreeView ->
- WorkspaceController, faire remonter l'évènement clic droit ainsi que la
- liste des éléments sélectionné pour faire générer le menu contextuel
- au niveau du WorkspaceController qui peut déterminer le contexte métier
- (le TreeView ne le connaît pas).
-* Définir des DataObject pour les maillages, les séries temporelles et
- les champs
-
-
-Spécification des espaces de données:
-
-* MEDDataManager dépend de l'étude (pour permettre la publication
- d'information dans une étude SALOME).
-* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
- requetes getFields(sourceid), getMeshes(sourceid)
-* les espaces de données: dataspace, workspace. Un seul workspace par
- étude, mais autand de datasources que l'on souhaite dans le
- dataspace. Les datasources sont rangés dans l'étude (le dataspace)
- et sont non modifiables après chargement (référence des sources de
- données).
-
-
-T20110628.1: extention à d'autres objets SALOME
------------------------------------------------
-
-**Status: suspendu**
-
-On doit reposer la question de l'existance de l'arbre indépendant
-(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
-SMESH en particulier) du principe de sélection graphique pour
-utilisation dans la console python, d'autre part.
-
-
-T20110628.2: visualisation d'un champ avec PARAVIS
---------------------------------------------------
-
-**Status: terminé (pour une première version)**
-Suite: de nombreux défauts subsistent
-
-Questions/remarques:
-
-* Pb au démarrage du module: VisTrails fails to start
-* Peux-t-on piloter la vue 3D sans charger le module? (voir
- myparavis.py)
-* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
-* Comment utiliser directement les objets MEDCouplingField?
-
-
-T20110706.1: documentation du module
-------------------------------------
-
-**Status: en cours (10%)**
-
-Documenter les commandes TUI puis l'utilisation générale de
-l'interafce graphique. Mentionner l'existance de la commande medop.sh
-pour travailler exclusivement en mode texte (utile pour les tests
-rapides).
-
-Documenter les modalités d'exécution des tests.
-
-T20110708.1: helper python pour MEDCoupling
--------------------------------------------
-
-**Status: en attente (pas urgent)**
-
-Faire un helper python dans le package xmed qui permet de faire du
-medcoupling facilement (essentiellement pour simplifier le chargement,
-puis la sélection des données). Cela demanderait de faire un
-MedDataManager comme une class C++ pure (non CORBA). Cette classe
-travaillerait par exemple uniquement avec des id et des liste d'id, et
-fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
-pour obtenir des meta-information.
-
-Le servant MedDataManager pourrait être une surcouche de cette classe
-c++ pure.
-
-T20110708.2: analyses et tests
-------------------------------
-
-TODO:
-
-* créer un fichier de test avec plusieurs pas de temps
-* créer un fichier de test avec des groupes de mailles
-
-
-T20110728.1: refactoring MEDDataManager
----------------------------------------
-
-Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
-
-* dans la mesure du possible utiliser les id plutôt que les handler en
- arguments des fonctions d'appel des objets
-* A chaque champ (FieldHandler), on doit associer un meshid (et de
- manière optionnelle un fieldseriesId, si le champ peut être associé
- à une serie temporelle. A priori faisable uniquement au chargement
- du datasource).
-* Pour cela, revoir les fonctions internes newFieldHandler et addField
- ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
- les informations concernant le meshid.
-* addField est utilisée par le MEDCalculator
-* Attention au raffraichissement des données handler au niveau du
- Workspace. Peut-être le mieux est que les fieldproxy contiennent
- uniquement le fieldid, et qu'ils interroge le datamanager à chaque
- fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
- via le MEDEventListener? **Le plus simple est de faire la mise à
- jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
- on essaye d'afficher les données**. Parceque sinon il n'y a pas de
- problème puisque que le calculateur travaille à partir des id.
-
-
-Petites améliorations du DataspaceController:
-
-* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
- l'alias python dans un attribut du sobject.
-* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
- est posé dans le WS. On peut donc proposer en option de lui associer
- un alias pour manipulation dans la console
-
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2012
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-
-Analyse preliminaire pour le chantier 2012
-==========================================
-
-La figure imposée pour le chantier 2012 est l'intégration du nouveau
-module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
-préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
-
-L'état actuel est:
-
-* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
- MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
- aujourd'hui obsolètes ou amener à disparaître pour l'échéance
- SALOME7
-* Un module SALOME de nom XMED qui fournit les fonctions graphiques
- pour la manipulation de champs.
-* Ce module XMED utilise le module VISU pour les vue de contrôle.
-
-La cible est:
-
-* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
- packages logiciels obsolètes et intégrant les fonctions graphiques
- (GUI et TUI).
-* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
- contrôle.
-* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
- exemple).
-
-A examiner:
-
-* voir les attendus concernant les ports MED dans YACS
-* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
-
-Tâches de développement
-=======================
-
-20120904: Migrer XMED dans MED
-------------------------------
-
-Plan de travail:
-
-* Migration des composants + test
-
-
-
-20120904: Nettoyage de XSALOME
-------------------------------
-
-:status: en cours
-
-* Supprimer les vieilleries de XSALOME:
-
- - StdHelper -> Basic_Utils (KERNEL)
-
-20120829: mise en place du chantier 2012
-----------------------------------------
-
-:status: terminé
-
-L'objectif de cette première étape est de reverser le prototype 2011
-(module XMED indépendant) dans la branche V6_main du module MED. On
-peut procéder de la manière suivante:
-
-* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
- V6_main
-* Eliminer la dépendance à XSALOME
-* Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine
-
-.. warning:: TODO: refaire le point sur les tâches initiées en 2011
-
+++ /dev/null
-#!/bin/sh
-# Copyright (C) 2007-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-factor="50%"
-listfiles="\
- medop-gui-aliasfield.png \
- medop-gui-result.png \
- medop-gui-selectfield.png \
- medop-gui-visufield.png"
-
-for file in $listfiles; do
- echo "Processing file $file ..."
- bn=$(basename $file .png)
- outfile=$bn"_scale.png"
- convert -scale $factor $file $outfile
-done
-
-
+++ /dev/null
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Documentation of MED module
-%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-The SALOME MED module provides MEDCoupling library (a C++ library dedicated of
-mesh and field manipulation consistent with MED model), as well as a Graphical
-User Interface to access some usual operations.
-
-References
-==========
-
-**User documentation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-userguide-gui.rst
- medop-userguide-api.rst
-
-**Technical documentation** (**in french**):
-
-.. toctree::
- :maxdepth: 1
-
- medop-specifications.rst
- medop-develguide.rst
-
-**Additional documentation**
-
-.. toctree::
- :maxdepth: 1
-
- medop-references.rst
-
-Document archive (in french)
-============================
-
-**Documentation du prototype 2010**
-
-Cette section décrit le prototype mis au point en 2010 pour les
-analyses de conception (maquette 2010 sur base MEDMEM)
-
-.. toctree::
- :maxdepth: 1
-
- medop-prototype-overview.rst
- medop-prototype-develguide.rst
- medop-prototype-medmem.rst
-
-**Journal de travail**
-
-.. toctree::
- :maxdepth: 1
-
- medop-workingnotes-2010.rst
- medop-workingnotes-2011.rst
- medop-workingnotes-2012.rst
+++ /dev/null
-.. AVERTISSEMENT:
-.. Ce fichier contient les définitions globales à la documentation. Il
-.. peut être inclu au moyen de la directive rst "include" pour
-.. disposer des définitions dans le fichier qui fait l'inclusion.
-.. Pour éviter de polluer les textes dans lequel ce fichier est inclu,
-.. il est interdit de faire afficher du texte par ce document de
-.. définition.
-
-.. REFERENCES DOCUMENTAIRES:
-.. (les documents sont fournis dans le répertoire _static/documents)
-
-.. You can refer to this reference using the keyword: |REF_EDF_VCA_H-I2C-2009-03595-FR|_
-.. |REF_EDF_VCA_H-I2C-2009-03595-FR| replace:: H-I2C-2009-03595-FR: Manipulation de champs dans SALOME - Orientations générales
-.. _REF_EDF_VCA_H-I2C-2009-03595-FR: _static/documents/20091218_EDF_VCANO_H-I2C-2009-03595-FR.pdf
-
-.. You can refer to this reference using the keyword: |REF_CEA_VBE_MEDMEM|_
-.. |REF_CEA_VBE_MEDMEM| replace:: MEDMEM user's guide
-.. _REF_CEA_VBE_MEDMEM: _static/documents/20070105_CEA_VBERGEAUD_GuideutilisateurMEDMEMOIRE.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_GBO_WORKNOTE|_
-.. |REF_EDF_GBO_WORKNOTE| replace:: XMED: Notes de travail
-.. _REF_EDF_GBO_WORKNOTE: _static/documents/20110309_XMED_scan_notes.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_ELO_REM|_
-.. |REF_EDF_ELO_REM| replace:: XMED: Remarques E. Lorentz
-.. _REF_EDF_ELO_REM: _static/documents/20110309_XMED_scan_remarques_ELORENTZ.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP01|_
-.. |REF_EDF_PRESMANIPCHP01| replace:: Séminaire EDF-CEA de janvier 2010: manipulation de champs
-.. _REF_EDF_PRESMANIPCHP01: _static/documents/20100129_MAN_seminaireEDF-CEA_all.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP02|_
-.. |REF_EDF_PRESMANIPCHP02| replace:: Révue EDF-CEA: maquette de manipulation de champs
-.. _REF_EDF_PRESMANIPCHP02: _static/documents/20101027_MAN_revueEDF-CEA.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_PRESMANIPCHP03|_
-.. |REF_EDF_PRESMANIPCHP03| replace:: Séminaire EDF-CEA de mars 2011: manipulation de champs, maquette 2010
-.. _REF_EDF_PRESMANIPCHP03: _static/documents/20110310_seminaireEDF-CEA_maquetteXMED.pdf
-
-.. PRESENTATIONS:
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_PDF|_
-.. |REF_EDF_JUS2011_PDF| replace:: JUS2011: outils de manipulation de champs
-.. _REF_EDF_JUS2011_PDF: _static/presentations/20111115_JUS-2011/20111115_JUS2011_manipulation_de_champs.pdf
-
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV1|_
-.. |REF_EDF_JUS2011_OGV1| replace:: JUS2011: outils de manipulation de champs - Exemple 1
-.. _REF_EDF_JUS2011_OGV1: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_1.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV3|_
-.. |REF_EDF_JUS2011_OGV3| replace:: JUS2011: outils de manipulation de champs - Exemple 3
-.. _REF_EDF_JUS2011_OGV3: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_3.ogv
-.. You can refer to this reference using the keyword: |REF_EDF_JUS2011_OGV4|_
-.. |REF_EDF_JUS2011_OGV4| replace:: JUS2011: outils de manipulation de champs - Exemple 4
-.. _REF_EDF_JUS2011_OGV4: _static/presentations/20111115_JUS-2011/20111115_JUS2011_medop_exemple_4.ogv
-
-
-
-.. LIENS EXTERNES:
-.. (l'accès nécessite le réseau intranet EDF et internet)
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDDOC|_
-.. |LINK_EDF_MEDDOC| replace:: Modèle MED
-.. _LINK_EDF_MEDDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc/html/modele_de_donnees.html
-
-.. You can refer to this reference using the keyword: |LINK_EDF_MEDFICHIERDOC|_
-.. |LINK_EDF_MEDFICHIERDOC| replace:: Documentation de MED fichier
-.. _LINK_EDF_MEDFICHIERDOC: http://med.der.edf.fr/logiciels/med-2.3.6/doc
-
-.. You can refer to this reference using the keyword: |LINK_EDF_SALOME_MED__MED|_
-.. |LINK_EDF_SALOME_MED__MED| replace:: SALOME_MED::MED
-.. _LINK_EDF_SALOME_MED__MED: http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/interfaceSALOME__MED_1_1MED.html
-
-.. RENVOIES:
-
-.. You can refer to this reference using the keyword: |SEE_MEDMEM_CORBA|
-.. |SEE_MEDMEM_CORBA| replace:: :ref:`L'interface CORBA SALOME_MED<xmed-medmem_corbainterface>`
-
-
-.. SNAPSHOTS:
-
-.. |XMED_SPECIFICATIONS_PDF| replace:: version pdf
-.. _XMED_SPECIFICATIONS_PDF: _static/documents/xmed-specifications.pdf
-
-.. |XMED_DEVELGUIDE_PDF| replace:: version pdf
-.. _XMED_DEVELGUIDE_PDF: _static/documents/xmed-develguide.pdf
-
-.. |XMED_USERGUIDE_PDF| replace:: version pdf
-.. _XMED_USERGUIDE_PDF: _static/documents/xmed-userguide.pdf
-
-
-.. =========================================================
-.. Rendering roles
-.. =========================================================
-.. This role can be used to display monospace text (code)
-.. role:: tt
- :class: tt
-
-.. role:: strike
- :class: strike
-
-.. role:: bolditalic
- :class: bolditalic
-
-.. role:: underline
- :class: underline
-
-.. role:: tag
- :class: tag
-
-.. role:: tagb
- :class: tagb
-
-.. role:: todo
- :class: todo
-
-.. role:: date
- :class: date
-
-.. role:: warn
- :class: warn
-
-.. role:: info
- :class: info
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med, développement
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Guide de développement du composant MEDOP
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le composant logiciel MEDOP est un élément du module MED. Il fournit
-une interface utilisateur pour la manipulation de maillages et de
-champs, composée d'une interface texte (TUI) et d'une interface
-graphique (GUI). L'interface graphique constitue l'interface graphique
-du module MED.
-
-Ce document est la documentation technique du composant MEDOP. Il
-fournit les instructions à suivre pour installer le composant en vue
-d'un travail de développement, puis décrit les éléments de conception.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Mise en place de l'espace de développement
-==========================================
-
-Gestion de configuration du composant MEDOP
--------------------------------------------
-
-Le composant logiciel MEDOP est un package du module SALOME MED,
-hébergé dans l'espace source au niveau du sous-répertoire
-`src/MEDOP`. La gestion des fichiers sources est donc intégrée dans le
-module SALOME MED.
-
-Organisation des sources du composant MEDOP
--------------------------------------------
-
-Le répertoire source `src/MEDOP` distingue les sous-répertoires
-suivants:
-
-* cmp: package containing the SALOME components
-* tui: package containing the python user interface
-* gui: package containing the graphical user interface (the GUI part
- of the MED module)
-* res: resources files associated to the MEDOP package (icons, config
- files, data files, ...)
-* exe: additional executable programs that can be launched from the
- MEDOP framework
-
-Construction du composant MEDOP
--------------------------------
-
-Intégré à la construction du module MED. Le composant MEDOP dépend de
-MEDCoupling et MEDLoader uniquement.
-
-Exécution des tests unitaires du composant MEDOP
-------------------------------------------------
-
-Les tests unitaires peuvent être exécutés au moyen de scripts python
-lancés depuis une session shell SALOME. Dans un nouveau shell, taper::
-
- $ ./appli/runSession
- [NS=mars:2810]$ python appli/bin/salome/med/test_medop_components.py
-
-L'exécution imprime un rapport détaillant le résultat pour chaque
-fonction de test::
-
- test_Calculator_applyFunc (__main__.MyTestSuite) ... ok
- test_Calculator_basics (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldListInFieldseries (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getFieldseriesListOnMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMesh (__main__.MyTestSuite) ... ok
- test_MEDDataManager_getMeshList (__main__.MyTestSuite) ... ok
- test_addDatasource (__main__.MyTestSuite) ... ok
- test_getDataManager (__main__.MyTestSuite) ... ok
- test_getFieldHandlerList (__main__.MyTestSuite) ... ok
- test_getFieldRepresentation (__main__.MyTestSuite) ... ok
- test_markAsPersistent (__main__.MyTestSuite) ... ok
- test_saveFields (__main__.MyTestSuite) ... ok
- test_updateFieldMetadata (__main__.MyTestSuite) ... ok
-
-Les scripts de test sont installés dans le répertoire ``bin/med``. On trouve:
-
-* ``test_medop_components.py``: test les composants SALOME développés pour
- la manipulation de champs (``MEDDataManager`` et ``MEDCalculator``).
-* ``test_xmed_fieldOperations.py``: test des operations de champs telles
- qu'elles sont mises en oeuvre depuis l'interface textuelle.
-* ``test_xmed_uiEventListener.py``: test du système de notification
- d'évènements des composants vers la partie gui du module MED.
-* ``test_xmed_visualisation.py``: test du système de visualisation
- des champs tel que piloté depuis le module MED.
-
-Architecture du module XMED
-===========================
-
-Le module MED pour la manipulation de champs est composé de:
-
-* une bibliothèque de fonctions pour le traitement de données sur des
- maillages et des champs conformes au modèle MED (package
- MEDCoupling, MEDLoader et REMAPPER);
-* une interface graphique pour la mise en oeuvre des cas standard de
- manipulation de champs;
-* une ensemble d'outils pour intervenir sur des fichiers au format
- MED.
-
-Une bibliothèque de fonctions pour le traitement de données
------------------------------------------------------------
-
-La figure ci-dessous montre la structure des paquets logiciels qui
-constituent la bibliothèque:
-
-.. image:: images/medlayers.png
- :align: center
-
-Elle comprend en particulier les paquets suivants:
-
-* MEDCoupling: qui décrit les structures de données pour porter les
- maillages et les champs
-* MEDLoader: qui fournit les fonctions de persistence sous forme de
- fichiers au format MED (lecture et écriture).
-* REMAPPER:
-
-Il est important de noter que MEDCoupling n'a aucune dépendance
-logicielle autre que la bibliothèque C++ standard. Ceci permet
-d'envisager son implantation dans un code de calcul ou un outil de
-traitement sans tirer l'ensemble pré-requis de SALOME.
-
-Une interface graphique pour l'exécution des cas standard
----------------------------------------------------------
-
-
-Un ensemble d'outils pour le traitement de fichiers
----------------------------------------------------
-
-
-Description des composants
-==========================
-
-MEDDataManager - Le gestionnaire des données de session
--------------------------------------------------------
-
-Le composant MEDDataManager s'occupe de fournir les données MED sur
-demande des interfaces clientes, en particulier pour module de
-pilotage fieldproxy.py. Ces données peuvent avoir plusieurs sources,
-en général elle proviennent d'un fichier au format med contenant des
-champs définis sur des maillages. Les données sont identifiées à la
-lecture des métadonnées de description dans le fichiers med, puis les
-valeurs des champs et les maillages support sont chargés au besoin.
-
-Le chargement des métadonnées de description se fait par la méthode::
-
- addDatasource(const char \*filepath)
-
-
-
-Eléments d'implémentation
-=========================
-
-Ecrire un service CORBA qui retourne une sequence de FieldHandler:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandlerList * MyFunction(...) {
- vector<MEDOP::FieldHandler*> fieldHandlerList;
- ...
-
- fieldHandlerList.push_back(fieldHandler);
-
- // Map the resulting list to a CORBA sequence for return:
- MEDOP::FieldHandlerList_var fieldHandlerSeq = new MEDOP::FieldHandlerList();
- int nbFieldHandler = fieldHandlerList.size();
- fieldHandlerSeq->length(nbFieldHandler);
- for (int i=0; i<nbFieldHandler; i++) {
- fieldHandlerSeq[i] = *fieldHandlerList[i];
- }
- return fieldHandlerSeq._retn();
- }
-
-Ecrire un service CORBA qui retourne une structure CORBA:
-
-.. code-block:: cpp
-
- MEDOP::FieldHandler * fieldHandler = new ...
- _fieldHandlerMap[fieldHandler->id] = fieldHandler;
-
- // >>> WARNING: CORBA struct specification indicates that the
- // assignement acts as a desctructor for the structure that is
- // pointed to. The values of the fields are copy first in the new
- // structure that receives the assignement and finally the initial
- // structure is destroyed. In the present case, WE WANT to keep
- // the initial fieldHandler in the map. We must then make a deep
- // copy of the structure found in the map and return the copy. The
- // CORBA struct specification indicates that a deep copy can be
- // done using the copy constructor. <<<
- return new MEDOP::FieldHandler(*fieldHandler);
-
-
-
-ANNEXE A: Bug en cours
-======================
-
-TO FIX:
-
-* la composition d'opérations n'est pas possible (ex: 2*f1+f2) car
- 2*f1 est indiqué comme non compatible (il semble qu'il n'ai pas la
- reference correcte vers le maillage).
-* le script de test test_medoperation.py plante si le module xmed n'a
- pas été chargé avec des données chargées.
-
-ANNEXE B: Traçabilité avec le module XMED
-=========================================
-
-Le module SALOME de nom XMED est l'espace de développement initial du
-composant logiciel MEDOP, intégré aujourd'hui au module MED. Cette
-annexe est la notice technique de ce module, qui reste disponible mais
-qui n'est plus maintenu.
-
-Gestion de configuration du module XMED
----------------------------------------
-
-Les sources du module (répertoire ``xmed``) sont archivés en dépôt de
-configuration dans une base git du projet NEPAL. Ils peuvent être
-récupérés au moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xmed.git
-
-Cette commande installe un répertoire ``xmed`` contenant l'ensemble
-des sources du module XMED.
-
-Le module XMED a pour pré-requis logiciel la plateforme SALOME:
-
-* SALOME version 6.1.3 (au moins) à télécharger à l'URL
- http://pal.der.edf.fr/pal/projets/pal/releases/V6_1_3
-* On peut également utiliser une version dérivée comme SALOME-MECA 2010.1
-* Installer la plate-forme choisie selon les instructions fournies.
-
-Le module XMED utilise également une bibliothèque interne au projet
-NEPAL, appelée XSALOME, et qui fournit une extension aux fonctions de
-SALOME pour un usage de développement (XSALOME signifie eXtension
-SALOME). Les sources de cette bibliothèque doivent être récupérés au
-moyen de la commande::
-
- $ git clone git@cli70rw.der.edf.fr:xom/xsalome.git
-
-Cette commande installe un répertoire ``xsalome`` contenant l'ensemble
-des sources de la bibliothèque XSALOME.
-
-.. note:: La bibliothèque XSALOME n'est pas un module SALOME mais une
- simple bibliothèque de fonctions qui complète ou rend plus facile
- d'utilisation les fonctions de SALOME. Elle NE DOIT EN AUCUN CAS
- être intégrée à d'autres projets que les projets internes NEPAL ou
- MAILLAGE. Il s'agit en effet d'une bibliothèque de transition qui
- héberge des développements destinés à être reversés dans la
- plate-forme SALOME. Le contenu et les interfaces de XSALOME ne peut
- donc être garanti sur le long terme.
-
-Installation et lancement de l'application
-------------------------------------------
-
-L'installation suppose qu'une version 6.1.3 de SALOME (ou plus) est
-disponible et que le shell de travail est étendu avec l'environnement
-de SALOME. En général, par des commandes de la forme::
-
- $ . /where/is/salome/prerequis.sh
- $ . /where/is/salome/envSalome.sh
-
-La compilation des modules xsalome et xmed suit le standard SALOME. La
-bibliothèque xsalome est un prérequis à la compilation de xmed. Pour
-cela, la variable d'environnement XSALOME_DIR doit être spécifiée pour
-la configuration de la procédure de reconstruction de xmed::
-
- $ export XSALOME_DIR=<xsalome_installdir>
-
-Aprés l'installation de xmed, il est possible de générer
-automatiquement une application SALOME prête à l'emploi pour la
-manipulation de champs::
-
- $ <xmed_installdir>/bin/salome/xmed/appligen/appligen.sh
-
-Cette commande génére un répertoire ``appli`` à l'emplacement où elle
-est exécutée. Il reste à lancer l'application SALOME au moyen de la
-commande::
-
- $ ./appli/runAppli -k
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, documentation technique
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Cette note fait la synthèse des développements effectués pour le
-maquettage des fonctions de manipulation de champs dans SALOME. Elle
-présente les principes retenus en matière de conception, c'est-à-dire
-concernant les mécanismes techniques sous-jacents, et en matière
-d'ergonomie, c'est-à-dire concernant les modalités d'utilisation dans
-l'environnement SALOME.
-
-Ces principes sont illustrés par des développements implantés dans le
-module XMED, développé pour les besoins de l'analyse, et dans le
-module MED distribué avec la plateforme SALOME.
-
-.. note:: la lecture de ce chapitre demande une connaissance de la
- structure de classes du module MED, en particulier la distinction
- entre les classes ``MEDMEM::*`` et les servants CORBA associés
- (classe ``SALOME_MED::*``).
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs
-====================
-
-Objectif et motivation
-----------------------
-
-L'objectif de maquettage est de trouver une architecture technique qui
-permet d'exécuter le cas d'utilisation suivant:
-
-* Chargement d'un fichier med dans SALOME (a priori dans le module MED)
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Opérations pow, sqrt.
-* Possibilité de visualiser les champs produits avec VISU pour
- contrôle des résultats.
-* Possibilité d'exporter des champs produits dans un fichier med.
-
-Eléments de contexte
---------------------
-
-Les opérations de manipulation de champs sont en grande partie
-implémentées dans la bibliothèque MEDMEM. Pour illustration, le
-fragment de code ci-dessous montre comment une addition de champ peut
-être opérée en python:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-Ceci montre que les champs peuvent être manipulés avec une interface
-relativement ergonomique (une addition de deux champs f1 et f2 s'écrit
-f1+f2) tant que l'on manoeuvre des objets MEDMEM purs (classes C++ du
-package MEDMEM et wrapping python du package MEDMEM_SWIG).
-
-Par ailleurs, le fonctionnement actuel des modules SALOME qui
-manoeuvrent des données MED est d'instancier les structures de données
-MEDMEM au niveau de la partie serveur, c'est-à-dire au niveau des
-servants CORBA hébergés dans le processus ``SALOME_Container``, et de
-donner accés à ces données depuis l'étude SALOME au travers de
-pointeurs CORBA. Ce choix d'architecture présente l'avantage de
-centraliser au niveau serveur la gestion du cycle de vie des données
-informatiques et de pouvoir distribuer des "poignées" pour manipuler
-ces données depuis chaque point de l'application qui sait accéder au
-bus CORBA, l'interface graphique en particulier.
-
-
-Hypothèse de travail
---------------------
-
-Compte-tenu de l'objectif de maquettage et des éléments de contexte
-existant, on cherche une solution dans le cadre des hypothèses
-de travail suivantes:
-
-* La manipulation des champs se fait dans l'environement graphique de
- SALOME.
-* Dans cet environnement, on souhaite pouvoir sélectionner
- graphiquement les champs à considérer, puis manipuler ces champs
- dans l'interface texte au moyen de variables python avec une syntaxe
- aussi simple que celle définie dans le wrapping python de MEDMEM,
- c'est-à-dire que pour faire l'addition de 2 champs f1 et f2, on veut
- pouvoir écrire f1+f2.
-* Les données MED sont physiquement dans la partie serveur de SALOME
- et accessibles via des pointeurs CORBA (interface spécifiée dans
- MED.idl). On exclu la recopie de données au niveau du client
- graphique.
-
-Dans le cadre de ces hypothèses, la difficulté technique réside dans
-la mise au point d'une interface de communication entre des variables
-manipulées par l'utilisateur dans l'interface graphique (c'est-à-dire
-dans le processus ``SALOME_SessionServer``) et des objets MEDMEM
-instanciés dans le containeur des servants CORBA (c'est-à-dire dans le
-processus ``SALOME_Container``).
-
-
-Eléments de conception
-======================
-
-
-Implantation technique
-----------------------
-
-Le diagramme ci-dessous représente l'organisation des principaux
-paquets logiciels du module MED:
-
-.. image:: images/medmem-layers.png
- :align: center
-
-Les cadres bleus représentent le lieu d'implantation des
-développements effectués dans le module MED pour les besoins du
-maquettage. On notera en particulier les interventions aux niveaux
-suivants:
-
-* interfaces idl: ajout de l'interface MEDOP.idl
-* package MEDMEM_I: ajout du servant SALOME_MED::MEDOP qui implémente
- l'interface MEDOP.idl
-
-Architecture technique
-----------------------
-
-Les schéma ci-dessous représente les objets informatiques qui sont à
-l'oeuvre pour la réalisation des opérations sur les champs:
-
-.. image:: /images/xmed-architecture.png
- :align: center
- :alt: Objets mis en oeuvre dans l'interface de manipulation de champs
-
-On distingue les objets suivants:
-
-* Une instance de ``MEDMEM::MED``, correspondant à la structure de donnée
- MED chargée en mémoire.
-* Des instances de ``MEDMEM::FIELD`` qui représentent les champs med
- chargés en mémoire.
-* Une instances de ``SALOME_MED::MED`` et des instances de
- ``SALOME_MED::FIELD`` qui sont les servants CORBA respectivement de la
- structure med et des champs qui lui sont associés et chargés en
- mémoire.
-* Une instance de ``SALOME_MED::MEDOP`` qui est le servant CORBA qui
- centralise la mise en oeuvre des opérations de champs sur le serveur
- ``SALOME_Container``. Le servant MEDOP détient en attribut une référence
- sur la structure ``MEDMEM::MED``, ce qui lui permet d'accéder
- directement aux champs ``MEDMEM::FIELD`` à partir de leur nom et du pas
- de temps.
-* Des instances de ``FieldProxy`` qui correspondent aux variables
- manipulées au niveau de l'interface graphique et qui représentent
- les champs. Une instance de FieldProxy possède détient les
- références des servants ``SALOME_MED::MEDOP`` et
- ``SALOME_MED::FIELD`` sous la forme de pointeurs CORBA de noms
- ``medop_ptr`` et ``field_ptr`` respectivement.
-* Il existe également une instance de ``MedProxy`` non représentée
- dans ce diagramme. Cette instance correspond à une variable qui
- permet de manipuler la structure med.
-
-.. note:: Les éléments apportés par la maquette sont les classes
- ``SALOME_MED::MEDOP``, ``MedProxy`` et ``FieldProxy``. Les autres
- éléments ont pu être modifiés légèrement pour les besoins de
- l'intégration ou pour la correction de quelques bugs.
-
-Le cycle de vie de ces objets est le suivant.
-
-Pour ce qui concerne les instances de la structure ``MEDMEM::MED`` et
-des champs ``MEDMEM::FIELD``, la création est faite au moment du
-chargement du fichier med dans SALOME au moyen du module MED. A cette
-occasion, les servants CORBA associés ``SALOME_MED::MED`` et
-``SALOME_MED::FIELD`` sont créés et des références vers ces servants
-sont publiés dans l'étude. Ils peuvent donc être sélectionnés par
-l'utilisateur dans l'interface graphique. L'ensemble de ces données
-préexiste à la manipulation de champs.
-
-Les objets ``SALOME_MED::MEDOP`` sont instanciés au sein du servant
-``SALOME_MED::MED`` auquel ils sont associées. Le servant
-``SALOME_MED::MED`` possède une référence sur la structure
-``MEDMEM::MED`` et il la transmet à l'instance du servant
-``SALOME_MED::MEDOP`` qu'il construit. L'opérateur MEDOP est donc
-autonome par la suite pour manipuler les données MED, et les champs en
-particulier. Le code python ci-dessous montre comment un opérateur med
-``SALOME_MED::MEDOP`` peut être créé puis utilisé pour réaliser
-l'addition de deux champs:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
- medOp = medObj.createMedOperator()
-
- f1 = medObj.getField("testfield1",-1,-1)
- f2 = medObj.getField("testfield2",-1,-1)
-
- somme = medOp.add(f1,f2)
-
-Il est à noter qu'une instance de ``SALOME_MED::MEDOP`` est associé à
-une instance unique de ``SALOME_MED::MED`` (et donc indirectement de
-``MEDMED::MED``) pour toute la durée de son cycle de vie. Par contre,
-un servant ``SALOME_MED::MED`` peut être associé à plusieurs servants
-``SALOME_MED::MEDOP`` différents. Un servant ``SALOME_MED::MEDOP`` a
-une référence directe sur la structure ``MEDMEM::MED`` et peut la
-manoeuvrer pour demander des champs, faire des opérations avec ces
-champs, ajouter le champs résultat à la structure et enfin retourner
-un servant ``SALOME_MED::FIELD`` qui encapsule le champ résultat.
-
-Enfin, quelques éléments concernant la classe ``FieldProxy``. Une
-instance de ``FieldProxy`` est un objet python qui peut être
-manoeuvrée dans l'interpréteur SALOME et qui référence un champ MED
-localisé sur le serveur ``SALOME_Container`` (par le mécanisme décrit
-ci-dessus). C'est à ce niveau qu'on règle les détails d'ergonomie
-d'usage (cf. paragraphe ci-après). La création d'un objet
-``FieldProxy`` déclenche la création d'un opérateur med (instance de
-``SALOME_MED::MEDOP``) qui lui est associé et dont il conserve la
-référence CORBA en attribut (noté ``medop_ptr`` sur le diagramme). Cet
-opérateur ``medop_ptr`` peut être requêter pour exécuter toutes les
-opérations possibles sur ce champ, comme illustrer sur l'exemple
-ci-dessus.
-
-
-Rôle des objets proxy
----------------------
-
-Dans le modèle d'architecture présenté ci-dessus, on introduit deux
-types d'objets proxy:
-
-* Les objets de classe ``FieldProxy`` qui représentent des poignées de
- manipulation des champs ``MEDMEM::FIELD`` physiquement instanciés
- dans le container SALOME.
-* Les objets de classe ``MedProxy`` qui représentent des poignées de
- manipulation des structures ``MEDMEM::MED`` physiquement instanciées
- dans le container SALOME.
-
-Elles sont instanciées dans l'interpréteur python SALOME pour
-manipulation dans l'interface textuelle à partir de la donnée du
-pointeur vers le servant ``SALOME_MED::MED`` et de l'identifiant du
-champ (le nom du champ et le pas de temps défini par le numéro d'ordre
-et le numéro d'iteration:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
- import SALOME_MED
-
- medComp = salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- medObj = medComp.readStructFile("myfile.med",salome.myStudyName)
-
- from xmed import fieldproxy
- from xmed import medproxy
-
- f1 = fieldproxy.getFieldFromMed(medObj, "testfield1", -1, -1)
- f2 = fieldproxy.getFieldFromMed(medObj, "testfield2", -1, -1)
-
- field_somme = f1 + f2
- field_offset = f1 + 5.3
-
-Dans cet exemple, les variables ``f1``, ``f2``, ``field_somme`` et
-``field_offset`` sont des objets de classe ``FieldProxy``. Ils
-correspondent aux variables physiquement manipulées par
-l'utilisateur pour désigner les champs dans les opérations.
-
-Ces classes proxy sont conçues pour être le lieu d'implémentation de
-l'interprétation des commandes utilisateur et donc de l'ergonomie
-de manipulation des champs au niveau l'interface textuelle. Ce point
-est développé :ref:`plus bas <develguide_execFieldOperation>`.
-
-Programmation de l'interface textuelle
---------------------------------------
-
-Dans le cadre de la maquette, l'interface de manipulation des champs
-est l'interface textuelle python intégrée à SALOME. Dans la pratique,
-l'utilisateur manipule des variables python qui correspondent à des
-objets de classe ``FieldProxy`` équipées des fonctions requises et de
-l'ergonomie nécessaire à la mise en oeuvre des opérations (voir
-ci-dessus).
-
-Or, l'hypothèse de travail est que les données MED sont chargées dans
-SALOME et publiées dans l'étude pour point d'accés depuis l'interface
-graphique. L'utilisateur choisi un champs directement dans l'arbre
-d'étude (ou dans une interface graphique dédiée) puis demande qu'il
-soit mis à disposition dans l'interface python sous un nom de variable
-à choisir. Les captures d'écran ci-dessous montre la séquence
-graphique en images:
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-
-+---------------+---------------+
-| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
-
-L'image de gauche montre la sélection du pas de temps, l'image de
-droite la boîte de dialogue qui permet la saisie de l'alias avec
-lequel le champs sera manipulé dans l'interface textuelle. La
-validation de cette fenêtre doit mettre automatiquement le champ à
-disposition dans l'interface python SALOME et sous le nom de variable
-spécifié par l'alias saisi.
-
-Pour cela, il y a un couplage technique à programmer entre l'interface
-graphique et l'interface textuelle python, avec en particulier la
-transmission des pointeurs vers les servants CORBA mis en jeu dans la
-sélection.
-
-Ce couplage est implanté au niveau de la classe MEDGUI.cxx du module
-MED (où de la classe XMEDGUI.cxx du module XMED pour la maquette) qui
-implémente l'interface graphique du module. Pour rappel, l'interface
-graphique d'un module SALOME se présente sous la forme d'une classe
-centrale de nom ``<MODULE_NAME>GUI`` et qui spécialise la classe
-``SalomeApp_Module``. Cette classe possède une méthode ``getApp()``
-par laquelle on peut récupérer une instance de la console python
-embarquée (this->getApp()->pythonConsole()).
-
-Le code suivant illustre l'envoie d'une commande python par ce
-mécanisme. Dans cet example, on cherche à reconstituer dans le
-contexte de la console python un pointer vers un objet med instancié
-dans le contexte C++ de l'application graphique. Pour cela, on
-communique la référence de l'objet sous la forme sérialisé (IOR pour
-un objet CORBA):
-
-.. code-block:: cpp
-
- #include <PyConsole_Console.h>
- #include <QString>
- #include <QStringList>
- #include <SalomeApp_Application.h>
-
- // We suppose here that we have a CORBA object reference (object of
- // type *_ptr or *_var), for example a SALOME_MED::MED object.
- SALOME_MED::MED_ptr medObj = ... // anything to get this object
-
- // Get the IOR of this object
- QString medIOR = SalomeApp_Application::orb()->object_to_string(medObj);
-
- PyConsole_Console * pyConsole = getApp()->pythonConsole();
-
- QStringList commands;
- commands+="import salome";
- commands+=QString("med=salome.orb.string_to_object(\"%1\")").arg(medIOR);
-
- QStringListIterator it(commands);
- while (it.hasNext()) {
- pyConsole->exec(it.next());
- }
-
-Le code réel de la maquette est basé sur ce principe et transmet à la
-console python des lignes de commandes qui permettent de reconstruire:
-
-* un pointeur CORBA vers le servant ``SALOME_MED::MED`` associé au
- champ sélectionné;
-* une instance de ``FieldProxy`` qui correspond au champ sélectionné
- et avec pour nom de variable la valeur de l'alias saisi dans
- l'interface graphique.
-
-Au niveau du code C++ de la classe ``XMEDGUI.cxx``, cela se traduit
-par la fabrication de la liste de commandes suivante pour envoie à la
-console python par le mécanisme illustré plus haut:
-
-.. code-block:: cpp
-
- QStringList commands;
- commands+="from xmed.fieldproxy import getFieldFromMed";
- commands+="from xmed.medproxy import getMedProxy";
- commands+=QString("if not dir().__contains__('med'): med = getMedProxy(\"%1\")").arg(medIOR);
- commands+=QString("%1=getFieldFromMed(med,\"%3\",%4,%5)").arg(*alias).arg(fieldName).arg(orderIndex).arg(iterationIndex);
-
-Les variables ``medIOR``, ``fieldName``, ``orderIndex`` et
-``iterationIndex`` sont construites à partir du champ sélectionné par
-des techniques de programmation standard dans SALOME qu'on peut
-examiner en détail dans la classe ``XMEDGUI`` (voir méthode
-``XMEDGUI::LoadIntoPythonConsole()``). La variable ``alias`` est la
-chaîne saisie par l'utilisateur dans la fenêtre de dialogue.
-
-Le point important à noter ici est que les données à transmettre
-doivent être fournies sous forme de chaînes de caractères ou de types
-simples. C'est pourquoi la référence au servant CORBA
-``SALOME_MED::MED`` est transmise ici sous la forme de son IOR,
-c'est-à-dire une chaîne de caractères qui permet l'identification de
-l'objet au niveau du bus CORBA.
-
-Au niveau de la console python cela correspond à l'exécution des
-commandes suivantes:
-
-.. code-block:: python
-
- from xmed.fieldproxy import getFieldFromMed
- from xmed.medproxy import getMedProxy
-
- med = getMedProxy("IOR:010000001700000049444c3a53414c4f4d455f4d45442f4d45443a312e300000010000000000000064000000010102000e0000003133302e39382e37372e313733009e0a0e000000feadc4ca4c00003169000000001100000200000000000000080000000100000000545441010000001c00000001000000010001000100000001000105090101000100000009010100")
-
- f1=getFieldFromMed(med,"testfield1",-1,-1)
-
-Ce jeu d'instructions reconstitue un pointeur vers le servant CORBA
-``SALOME_MED::MED`` à partir de son identifiant IOR (voir la fonction
-``getMedProxy(...)``, puis crée une instance de ``FieldProxy``
-associée à ce servant (en fait associée au servant
-``SALOME_MED::MEDOP`` créé sur demande par le servant
-``SALOME_MED::MED``, voir la fonction ``getFieldFromMed(...)``).
-
-.. _develguide_execFieldOperation:
-
-Exécution des opérations sur le champs
---------------------------------------
-
-Les variables définies dans l'interface textuelle pour désigner les
-champs à manipuler sont des objets de classe ``FieldProxy``.
-
-Cette classe a une propriété remarquable, elle est construite sur un
-design pattern de type "Proxy" qui pointe vers un servant
-``SALOME_MED::FIELD``. Cela signifie que l'on ne peut pas accéder
-directement au servant vers lequel il pointe, mais que l'on passe
-systématiquement par une procédure de l'objet proxy qui fait "boîte
-aux lettres":
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __getattr__( self, name ):
- """
- This method realizes the proxy pattern toward the servant
- SALOME_MED::FIELD.
- """
- return getattr( self.__field_ptr, name )
-
-Ce pattern permet l'implémentation de pré-traitement et/ou de
-post-traitement suivant le type d'accés que l'on cherche à faire.
-
-Il permet aussi et surtout de fournir un objet python qui présente
-l'interface de ``SALOME_MED::FIELD`` dotée d'extentions adhoc pour les
-operations de champs. Ici, python est ton ami, car il s'agit pour cela
-d'équiper la classe ``FieldProxy`` des automatismes prévus nativement
-par python pour les operations entre objets. En particulier, la
-re-définition des fonctions internes ``__add__`` (opérateur addition),
-``__sub__`` (opérateur soustraction), ``__mul__`` (opérateur
-multiplication) et ``__div__`` (opérateur division) au sein de la
-classe ``FieldProxy``, permet de prendre la main sur le comportement
-des opérations algébriques et de définir une ergonomie sur mesure. Par
-exemple, la méthode ``__add__`` peut gérer les variantes "f1+f2"
-(ajout de deux variables de type FieldProxy) et "f1+5.3" (ajout d'un
-réel à une variable de type FieldProxy):
-
-.. code-block:: python
-
- class FieldProxy:
-
- def __add__(self, operande):
- """
- This can process the addition of two fields or the addition of
- a scalar to a field. It depends weither the operande is a
- FieldProxy or a simple scalar numerical value.
- """
- if isinstance(operande, FieldProxy):
- # The operande is an other field
- otherField_ptr = operande.__field_ptr
- rfield_ptr = self.__medOp_ptr.add(self.__field_ptr, otherField_ptr)
- else:
- # The operande is a scalar numerical value that must be
- # considered as an offset in a linear transformation
- factor = 1
- offset = operande
- rfield_ptr = self.__medOp_ptr.lin(self.__field_ptr, factor, offset)
- return FieldProxy(self.__med_ptr, rfield_ptr)
-
-Il est à noter que dans les deux cas de figure (opérande=champ ou
-opérande=scalaire), la fonction délègue la réalisation concrète de
-l'opération au servant ``SALOME_MED::MEDOP`` (identifié ici par
-l'attribut ``self.__medOp_ptr`` et que l'on appelera l'*opérateur
-MEDOP* dans la suite pour simplifier), mais n'appelle pas le même
-service de calcul (l'addition entre champs dans le premier cas,
-l'application d'une transformation linéaire de type y=factor*x+offset
-dans le deuxième cas).
-
-Pour couvrir le cas des opérations algébriques, l'opérateur MEDOP
-présentre l'interface suivante (cf. fichier ``MEDOP.idl`` qui définie
-l'interface du servant ``SALOME_MED_MEDOP``):
-
-.. code-block:: cpp
-
- /*! Addition of the fields f1 and f2 ( f1+f2) */
- FIELD add(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Substraction of the fields f1 and f2 (f1-f2) */
- FIELD sub(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Multiplication of the fields f1 by f2 (f1*f2) */
- FIELD mul(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Division of the fields f1 by f2 (f1/f2) */
- FIELD div(in FIELD f1, in FIELD f2) raises (SALOME::SALOME_Exception);
- /*! Power of the field f (f^power) */
- FIELD pow(in FIELD f, in long power) raises (SALOME::SALOME_Exception);
- /*! Linear transformation of the field f (factor*f+offset) */
- FIELD lin(in FIELD f, in double factor, in double offset) raises (SALOME::SALOME_Exception);
- /*! Dublication of the field f */
- FIELD dup(in FIELD f) raises (SALOME::SALOME_Exception);
-
-Cette interface est implémentée dans la classe C++ ``MEDOP_i`` du
-module MED (voir fichier ``MEDMEM_MedOp_i.hxx`` du package
-``MEDMEM_I``). C'est au sein des instances de cette classe que sont
-réalisées les opérations et que sont produites physiquement les
-données. Typiquement, les opérations présentées ici produisent un
-champ ``MEDMEM::FIELD`` sur la base duquel elle fabrique un servant
-``SALOME_MED::FIELD`` pour finalement retourner un pointeur CORBA sur
-ce servant.
-
-Ce mécanisme global peut être étendu sans limitation à tout les types
-d'opération qui sont envisagés dans les spécifications de manipulation
-des champs dans SALOME.
-
-
-Contrôle visuel des champs
---------------------------
-
-Les illustrations ci-dessous montrent qu'une fonction de visalisation
-est implémentée dans la maquette pour permettre le contrôle visuel
-d'un champ au moyen d'une représentation 3D (une carte spatiale du
-module du champ dans l'exemple implémenté par défaut):
-
-.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
-.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-
-+---------------+---------------+
-| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
-
-Cette fonction répond au besoin de contrôle interactif des résultats
-produits par les opérations de manipulation de champs.
-
-Il s'agit là d'un usage classique de SALOME, dans lequel on demande au
-module VISU de faire une représentation 3D d'un champ spécifié par la
-donnée du servant ``SALOME_MED::FIELD`` qui lui est associé
-(représenté par la variable ``field_ptr`` dans l'exemple ci-dessous):
-
-.. code-block:: python
-
- import salome
- import VISU
-
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Then we can import the specified field in the VISU module. This
- # creates an study entry in the VISU folder.
- result = visuComp.ImportMedField(field_ptr)
-
- meshName = field_ptr.getSupport().getMesh().getName()
- fieldName = field_ptr.getName()
- iterNumber = field_ptr.getIterationNumber()
- scalarmap = visuComp.ScalarMapOnField(result,
- meshName,
- visuEntityType,
- fieldName,
- iterNumber)
-
-Dans ce jeu d'instructions donné pour exemple (non fonctionnel, en
-particulier à cause de la non définition de la variable
-``visuEntityType``, voir remarque plus bas), le composant VISU
-désigné ici par la variable ``visuComp`` va chercher les données du
-champ en interrogeant le servant ``SALOME_MED::FIELD`` transmis en
-argument de la fonction ``ImportMedField``, puis produit une
-représentation de type "scalarmap".
-
-.. note:: Compte-tenu des propriétés de la classe FieldProxy décrites
- plus haut conférées par le pattern "Proxy", on peut transmettre ici
- aussi bien le servant CORBA que l'instance du proxy (la fonction
- ``ImportMedField`` n'y verra que du feu).
-
-Le code complet et fonctionnel de la fonction d'affichage est dans le
-corps du module python ``fieldproxy.py`` sous la forme d'une fonction
-de nom ``visuField``. Il convient de noter que cette fonction doit
-établir une correspondance entre le type des entités tel que défini
-dans MED et dans VISU:
-
-.. code-block:: python
-
- medEntityType = field_ptr.getSupport().getEntity()
- if (medEntityType == SALOME_MED.MED_CELL):
- visuEntityType = VISU.CELL
- elif (medEntityType == SALOME_MED.MED_NODE):
- visuEntityType = VISU.NODE
-
-
-Export des résultats de calcul
-------------------------------
-
-Tous les champs produits à l'occasion des opérations entre objets
-``FieldProxy`` sont automatiquement ajoutés à la structure med à
-laquelle is sont associés. Une convention d'attribution des noms est
-implémentée de sorte que par défaut aucune précision n'est demandée à
-l'utilisateur.
-
-La structure med peut être manipulée au moyen de la variable ``med``
-créée dans l'interface textuelle comme une instance de la classe
-``MedProxy``. La classe ``MedProxy`` fournit un objet qui présente
-l'interface du servant ``SALOME_MED::MED`` étendue de quelques
-fonctions utilitaires pour la gestion et le contrôle des données.
-
-En particulier, la sauvegarde de la structure dans un fichier est
-automatisée par la méthode ``save(medfilename)``:
-
-.. code-block:: python
-
- med = medproxy.MedProxy(medObj)
- med.save("/tmp/output.med")
-
-Cette méthode s'occupe de définir un driver d'écriture et de procéder
-à l'enregistrement des données de la structure med (les maillages, les
-champs présents au départ et tous les champs produits depuis la
-lecture initiale).
-
-Limitations
-===========
-
-L'implémentation de la maquette limite l'usage des opérations aux cas
-de figure suivants:
-
-* Seules les operations entre champs qui partagent le même support med
- sont possibles. Ceci est une contrainte imposé par la conception
- actuelle de MEDMEM.
-* Le résultat d'une opérations est calculé sur toutes les composantes
- et tout le domaine de définition des champs en opérande. Cette
- deuxième contrainte est juste parce que les usages plus fin,
- notemment avec la notion de domaine de définition, n'a pas encore
- été exéminée à ce jour.
-* Le nom d'un champ produit par une opération ne correspond pas au nom
- de la variable python par laquelle on le réceptionne et on le
- manipule. Le nom est attribué par une convention (ceci n'est pas
- vraiment une limitation mais une caractéristique à connaître).
-
-On note également les restriction techniques suivantes:
-
-* Les données MEDMEM sont supposées être chargées par le composant MED
- puis référencées dans l'étude SALOME (comme c'est fait aujourd'hui
- par le module MED).
-* Dans certain cas, python n'est pas ton ami. Pour que les opérateur
- de la classe ``FieldProxy`` soient pris en considération dans les
- opérations sur les champs, il est indispensable que le premier
- opérande d'une opération unitaire soit un champ (objet de classe
- ``FieldProxy``). Par exemple: "field_offset = field + 5.3"
- fonctionne alors que "field_offset = 5.3 + field" ne fonctionne pas
- car python tente de traiter la situation au moyen de la fonction
- ``__add__`` de la classe ``float`` (qui n'est pas modifiable).
-
-
-Notice informatique
-===================
-
-Gestion de configuration
-------------------------
-
-Les développements décrits dans ce chapitre sont répartis entre les
-modules MED et XMED (développé pour l'occasion). Cette séparation est
-faite par soucis de clarté et d'efficacité de développement, mais les
-éléménts du module XMED ont vocation à intégrer le module MED dans la
-mesure où les propositions techniques sont retenues pour le
-développement à venir.
-
-Le code source du module XMED peut être récupérés par la commande
-suivante::
-
- $ svn co svn://nepal.der.edf.fr/FIELD/XMED_SRC/trunk XMED_SRC
-
-Le pré-requis est la plate-forme SALOME version 5.1.4 (ou plus)
-équipée au minimum des modules KERNEL, GUI, MED (branche BR_medop) et
-VISU. Pour récupérer la branche BR_medop du module MED, taper la
-commande::
-
- $ cvs -d :pserver:anonymous@cvs.opencascade.com:2401/home/server/cvs/MED co -r BR_medop MED_SRC
-
-La configuration de référence est:
-
-* XMED: révision svn 41
-* MED: tag cvs BR_medop_20101025
-
-Moyens de tests
----------------
-
-Plusieurs types de tests unitaires sont définis (reste à les
-automatiser proprement):
-
-* Test des servants et utilitaires de manipulation python:
-
- - Dans XMED, package xmed/tests, utiliser le script
- ``test_medoperation.py`` dans un interpréteur python lancé dans
- une session shell SALOME. Ce script prépare des variables de test
- et fournit des fonctions de test unitaire (à exécuter ou pour s'en
- inspirer). Après avoir lancé SALOME via une application virtuelle,
- on peut taper::
-
- $ <APPLI_ROOT>/runSession
- [NS=venus:2810] $ python -i test_medoperation.py
- >>>
-
- - Ceci permet de tester en particulier l'interface ``MedOp`` et son
- utilisation dans le module python ``fieldproxy.py``.
-
-* Test des classes MEDMEM:
-
- - Test de MEDMEM::MedDataManager dans ``MEDMEM_MedDataManager_test.cxx``
-
-Un fichier de test basique (mais néanmoins suffisant) de nom
-``tesfield.med`` est fourni avec les sources dans le répertoire
-``<XMED_SRC>/resources/datafiles`` et dans l'installation au niveau du
-répertoire ``<INSTALLDIR>/share/salome/resources/xmed/datadir``. Il
-contient deux champs ``testfield1`` et ``testfield2`` définis sur un
-pas de temps unique (dt,it=-1,-1). Ces champs définissent des valeurs
-par éléments (MED_CELL).
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, MED, MEDMEM
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Note de travail concernant l'utilisation de MEDMEM
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module MED de SALOME comporte plusieurs composants d'intérêt pour
-la manipulation de champs:
-
-* la bibliothèque MEDMEM qui fournit une interface de programmation
- pour manoeuvrer une structure MED
-* le module CORBA SALOME_MED qui matérialise le composant SALOME
- (serveur corba) du module MED
-* l'interopérabilité avec le module VISU qui permet la visualisation
- des champs manipulés dans MED
-
-Les sections ci-après donnent quelques éclairages techniques sur ces
-différents aspects. Les sources de démonstration peuvent être
-récupérés depuis le dépôt svn::
-
- $ svn export svn://nepal.der.edf.fr/OM/manifield/trunk manifield
- $ svn export svn://nepal.der.edf.fr/FIELD/demofield/trunk demofield
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Présentation synthétique de MED
-===============================
-
-MED désigne un modèle conceptuel pour décrire des données de type
-éléments finis (éléments finis, volumes finis et éléments
-discrets). Dans l'usage courant, il permet la description et l'échange
-des données de calcul de type maillages et champs. La documentation
-complète peut être trouvée à l'URL suivantes:
-
-* |LINK_EDF_MEDDOC|_ (version 2.3).
-
-On distingue deux implémentations informatiques de ce modèle:
-
-* MED fichier: qui permet la lecture et l'écriture de données depuis
- un fichier au format med. Les opérations de lecture/écriture sont
- atomiques (pas de chargement de la structure de données globale).
-* MED mémoire (noté MEDMEM): qui permet le chargement en mémoire d'une
- image de la structure de données MED contenue dans un fichier au
- format med. Les opérations peuvent être atomiques ou
- globales.
-
-On notera simplement ici que MEDMEM utilise MED fichier pour les
-opérations de lecture/écriture et que MED fichier est indépendant de
-MED mémoire. La documentation complète de MED fichier peut être
-trouvée à l'URL suivante:
-
-* |LINK_EDF_MEDFICHIERDOC|_
-
-La bibliothèque MEDMEM
-======================
-
-Le modèle de classes MEDMEM est structuré autour des notions de MESH
-(les maillages), de SUPPORT (le profil des entités) et de FIELD (les
-champs). Ces notions reprennent en partie des concepts du modèle
-MED. Le diagramme ci-dessous présente les classes principales:
-
-.. image:: images/med-uml-main_60pc.png
- :align: center
-
-Le conteneur de plus haut niveau dans MEDMEM est la classe MED. La
-figure ci-dessous indique qu'une instance MED peut être associée à
-plusieurs maillage et plusieurs champs. Par contre un champ donné ne
-peut être associé qu'à un seul maillage (par l'intermédiaire du
-support). Plusieurs champs peuvent être associés au même maillage. La
-forme la plus courante est d'ailleurs une instance composé d'un
-maillage unique sur lequel sont définis plusieurs champs.
-
-On peut avoir également des configurations plus complexes, comme par
-exemple un maillage unique, plusieurs champs définis sur ce maillage
-mais avec des supports différents, par exemple parce que les valeurs
-sont définies sur des entités de maillage différentes (les éléments
-pour un champ, les noeuds pour un autre, ...)::
-
- field1->support1->mesh
- field2->support2->mesh
- field3->support3->mesh
-
-On observe:
-
-* 2 champs U et V doivent avoir le même support (au sens informatique
- du terme) pour pouvoir être en argument d'une opération (sinon
- exception). Il faudrait accepter qu'il soit informatiquement
- différent et vérifier la conformité conceptuelle.
-* Cette contrainte peut se comprendre car physiquement les données
- sont stockées dans un vecteur qui couvre toutes les mailles. Le
- support est le seul masque de lecture pour établir la correspondance
- avec les positions dans le maillage et il est donc important qu'une
- cohérence soit assurée.
-
-Les objets champs (FIELD) et maillage (MESH)
---------------------------------------------
-
-Un objet MED permet d'accéder aux différentes informations concernant
-les objets MESH, SUPPORT et FIELD, mais il ne permet pas d'accéder aux
-données physiques associées à ces objets (les valeurs des composantes
-pour les champs, les mailles et leur connectivité pour les
-maillages). L'accès aux données physiques est du ressort des objets
-spécifiques MESH, SUPPORT et FIELD.
-
-Un objet MED peut être créé intégralement en mémoire. L'usage plus
-fréquent est de l'initialiser à partir de la donnée d'un fichier
-med. Pour cela, l'objet MED doit être associé à un driver
-d'entrée/sortie branché sur le fichier (``testfilename`` dans
-l'exemple):
-
-.. code-block:: cpp
-
- MED *myMed = new MED;
- MED_MED_RDONLY_DRIVER *driverIn = new MED_MED_RDONLY_DRIVER(testfilename, myMed);
- driverIn->open();
- driverIn->readFileStruct();
- driverIn->close();
-
-A l'occasion de la fonction readFileStruct, la structure interne de
-l'objet MED est enrichie des informations concernant les objets MESH,
-SUPPORT et FIELD contenu dans le fichier. En particulier un
-dictionnaire des champs (variable map interne) est initialisé est
-contient l'ensemble des objets ``FIELD_`` préchargés (i.e. avec les
-méta-données uniquement). Chaque objet ``FIELD_`` ainsi préchargé est
-autonome pour être chargé sur demande. On peut alors requêter l'objet
-MED pour obtenir un champ particulier (spécifié par son nom
-``fieldname`` dans l'exemple):
-
-.. code-block:: cpp
-
- FIELD<double> *field = (FIELD<double> *)myMed->getField(fieldname, dt, it);
-
-Puis le champ qui lui est associé doit être physiquement chargé pour
-permettre la mise à jour du support:
-
-.. code-block:: cpp
-
- MESH * mesh = myMed->getMesh(field);
- mesh->read();
- myMed->updateSupport();
-
-Pour enfin charger les valeurs des composantes du champ:
-
-.. code-block:: cpp
-
- field->read();
-
-La numérotation des éléments de maillage
-----------------------------------------
-
-Les éléments qui composent un maillage sont caractérisés par:
-
-* Le type d'entité de l'élément, à choisir dans la liste
- ``MED_EN::medEntityMesh``, qui contient en particulier ``MED_NODE``,
- ``MED_FACE``, ``MED_CELL``.
-* Le type de géométrie de l'élément, à choisir dans la liste
- ``MED_EN::medGeometryElement``, qui contient en particulier
- ``MED_NONE``, ``MED_TRIA3``, ..., ``MED_ALL_ELEMENTS``.
-
-Les éléments sont numérotés par un indice relatif à la catégorie
-géométrique à laquelle ils appartiennent. Ainsi, si le modèle est
-composé de Na arrêtes et Nf faces de type géométrique MED_QUAD4, alors
-ces faces sont numérotées de 1 à Nf dans le modèle MED (et de manière
-persistente dans le fichier med). De même, les arrêtes sont numérotées
-de 1 à Na. Une numérotion globale implicite existe sur les éléments,
-elle consiste à parcourir l'ensemble des types géométriques dans
-l'ordre de définition du modèle de données. Ainsi, si le modèle
-contient uniquement les Na arrêtes et les Nf faces, alors l'indice
-global de la première face est Na+1.
-
-.. note:: Des exemples de code sont disponibles dans le package ``demofield``, fichier ``python/pybasicfields/MEDMEM_tester.py``.
-
-
-Binding python de MEDMEM
-------------------------
-
-Les classes du package ``MEDMEM`` (package du module ``MED`` qui
-implémentent les structures de données C++ de MED mémoire) produisent
-la bibliothèque ``libmedmem.so``. Cette ensemble de classes est en
-partie mis à disposition de l'interface python grace à une couche de
-liaison (binding Python-C++) générée par le logiciel SWIG à partir
-d'un fichier de description d'interface ``libMEDMEM_Swig.i`` (dans le
-package source ``MEDMEM_SWIG``).
-
-Ce fichier d'interface doit être mis à jour dés lors qu'une évolution
-des interfaces publiques des classes C++ MEDMEM est faite ou qu'une
-nouvelle classe est créée (du moins si l'on souhaite profiter de ces
-évolutions dans l'interface python).
-
-Cette mise à jour nécessite de prendre soin au transfert des
-structures de données entre les espaces python et C++. En particulier,
-l'utilisation des template de classe pour décrire les champs typés en
-C++ appelle une précaution de codage particulière de l'interface
-SWIG.
-
-Pour exemple, le fragment de code ci-dessous, extrait du fichier
-``libMEDMEM_Swig.i``, montre comment déclarer la nouvelle classe
-``MedDataManager`` dans l'interface:
-
-.. code-block:: cpp
-
- #include "MEDMEM_MedDataManager.hxx"
-
- class MedDataManager
- {
- public:
- ~MedDataManager();
- void printFieldDouble(FIELD<double,FullInterlace> * field);
-
- %extend {
- MedDataManager(char * fileName)
- {
- return new MedDataManager(string(fileName));
- }
- MedDataManager(MED * med)
- {
- return new MedDataManager(med);
- }
-
- %newobject getFieldDouble(const char * fieldName, const int dt, const int it);
- FIELD<double, FullInterlace> * getFieldDouble(const char * fieldName, const int dt, const int it)
- {
- return (FIELD<double, FullInterlace> *) self->getFieldDouble(string(fieldName), dt, it);
- }
- }
-
- };
-
-
-Utilisation de MEDMEM pour la manipulation de champs
-----------------------------------------------------
-
-Des opérations de manipulation de champs sont disponibles dans la
-bibliothèque MEDMEM standard est peuvent être utilisées dans
-l'interface python. Les quelques lignes suivantes illustrent l'usage
-qu'on peut en faire pour exécuter l'addition de deux champs sur tout
-leur espace de définition et pour un pas de temps donné:
-
-.. code-block:: python
-
- from libMEDMEM_Swig import MedDataManager
- from xmed.helper import readMed, writeMed
-
- # Load the medmem data structure from a med file
- med = readMed("/tmp/input.med")
- # Then create a med data manager to deal with the fields data
- dm = MedDataManager(med)
- # Get the timestamps (dt,it)=(-1,-1) of the fields "testfield1" and "testfield2"
- f1 = dm.getFieldDouble("testfield1",-1,-1)
- f2 = dm.getFieldDouble("testfield2",-1,-1)
-
- # Create a new field as the sum of f1 and f2
- r = f1 + f2
- # And add this new field to the med data structure
- med.addField(r)
-
- # Finally, write the whole data in an output med file
- writeMed(med,"/tmp/output.med")
-
-.. note:: Cet exemple de code requiert les évolutions de MEDMEM
- opérées dans la branche BR_medop (pour disposer de la classe
- MedDataManager en particulier) et le package python ``xmed`` qui
- fournit quelques fonctions utilitaires pour manoeuvrer les données
- med (ce package est dans le module XMED et sera probablement à
- terme intégré au module MED).
-
-Des limitations existent aujourd'hui pour ce type de manipulations:
-
-* les champs doivent partager le même support MED, c'est-à-dire être
- décrit sur le même maillage et sur les mêmes entités de ce
- maillage.
-* ...
-
-
-Remarque sur l'implémentation C++
----------------------------------
-
-A noter l'usage de plusieurs formes d'arguments pour les fonctions:
-
-* passage des arguments par valeur ``myfunction(A a);``
-* passage des arguments par référence ``myfunction(A& a);``
-* passage des arguments par pointeur ``myfunction(A* a);``
-
-Le passage des arguments par référence est une facilité d'écriture
-pour éviter de passer un pointeur tout en évitant la récopie des
-données de la variable.
-
-.. _xmed-medmem_corbainterface:
-
-L'interface CORBA SALOME_MED
-============================
-
-Implémentation du composant MED et des servants SALOME_MED::\*
---------------------------------------------------------------
-
-Le composant MED est un servant CORBA qui permet la manipulation de
-données MEDMEM dans l'environnement SALOME. Le composant peut fournir
-des pointeurs vers des instances de l'interface SALOME_MED (objets
-SALOMEMED::MED, SALOME_MED_FIELD, ...). Ces instances sont des
-servants CORBA qui résident dans le container et qui encapsulent les
-données MEDMEM.
-
-Le schéma ci-dessous représente les éléments informatiques qui
-composent l'architecture CORBA du module MED:
-
-.. image:: images/medmem-corba-layers.png
- :align: center
-
-Les structures MEDMEM (données physiques) et SALOME_MED (wrapping
-CORBA) fonctionnent différement en ce qui concerne le chargement des
-données:
-
-* Dans MEDMEM, les données sont chargées à la demande (fonctions read
- des objets) et aucune gestion n'est assurée. En particulier l'appel
- à read alors que la donnée est déjà chargée conduit à une levée
- d'exception. C'est à l'utilisateur de MEDMEM de prendre en charge ce
- type de gestion.
-* Dans SALOME_MED, les données sont chargées à la création de
- l'instance SALOME_MED::MED. Les maillages ainsi que les champs et
- leurs données sont chargés à ce moment là et gérés dans une table de
- type HashMap au niveau de la structure SALOME_MED::MED. Cette
- structure remplie dés lors des fonction de gestion. L'appel à
- SALOME_MED::MED.getField(...) ne charge pas les données mais renvoie
- un pointeur SALOME_MED::FIELD_ptr sur les données chargées à
- l'initialisation (ATTENTION, cette fonction est bugguée dans la
- branche principale -> Fix dans la branche BR_medop).
-
-Une gestion intermédiaire peut être envisagée: le chargement à la
-demande géré dans une ou plusieurs tables de champs (une pour chaque
-type de valeur numérique). Une implémentation de ce type de gestion
-est illustré dans la classe ``MedDataManager`` du package MEDMEM qui prend
-en charge ce comportement pour les structures de données MED (en
-particulier les champs).
-
-Utilisation du composant MED
-----------------------------
-Le module SALOME MED fournit un module CORBA appelé SALOME_MED. Les
-interfaces de ce module CORBA sont spécifiées par les fichiers idl
-suivants:
-
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED_8idl.html
- ``MED.idl``] qui décrit les interfaces des objets manipulés par le
- module SALOME_MED. On trouve en particulier les objets MESH, SUPPORT
- et FIELD.
-* le fichier
- [http://nepal.der.edf.fr/pub/SALOME_userguide/MED5/doc/salome/tui/MED/MED__Gen_8idl.html
- ``MED_Gen.idl``] qui décrit les interfaces du composant SALOME
- (c'est-à-dire le composant chargé par la commande
- ``FindOrLoadComponent("FactoryServer", "MED")`` du
- lyfeCycleCorba). On trouve:
-
- - l'interface ``MED_Gen_Driver`` qui hérite de SALOMEDS::Driver
- pour l'implémentation des services généraux des composants SALOME
- (persistance hdf, dump)
- - l'interface ``MED_Gen`` qui hérite des interfaces
- ``Engines::Component`` et ``MED_Gen_Driver`` pour
- l'implémentation des services spécifiques du composant MED.
-
-L'implémentation de ces interfaces est faites au niveau de différents
-packages des sources du module MED:
-
-* Le package ``MEDMEM_I`` qui fournit l'implémentation C++ des
- interfaces décrites par le fichier ``MED.idl``;
-* Le package ``MED`` qui fournit l'implémentation C++ des interfaces
- décrites par le fichier ``MED_Gen.idl``, et qui correspond à la
- partie composant classique d'un module SALOME.
-* Le package ``MedCorba_Swig`` qui fournit une interface swig
- générée à partir de l'implémentation C++ de ``MEDMEM_I`` et
- ``MED``
-
-L'utilisation peut être illustrée au moyen d'exemples python (i.e. qui
-utilise l'interface swig fournie par MedCorba_Swig). Après l'import
-d'amorce systématique:
-
-.. code-block:: python
-
- import salome
- salome.salome_init()
-
- import SALOME_MED
- from libSALOME_Swig import *
-
-On peut charger le composant SALOME MED:
-
-.. code-block:: python
-
- medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
-
-grâce auquel les services de chargement de la structure MED peuvent
-être invoqués. Par exemple, les commandes suivantes chargent toute la
-structure MED dans l'étude salome passée en argument:
-
-.. code-block:: python
-
- filePathName = "myfile.med"
- medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
-Ce deuxième exemple charge la structure MED mais ne place pas le résultat dans l'étude:
-
-.. code-block:: python
-
- filePathName = "myfile.med"
- medObj = medComp.readStructFile(filePathName,salome.myStudyName)
-
-On récupère à la place un objet de classe |LINK_EDF_SALOME_MED__MED|_
-qui permet une utilisation assez semblable (mais différente on le
-verra plus bas) à MEDMEM:
-
-.. code-block:: python
-
- fieldIdx = 1 # WRN maybe there is no field of idx=1
- iterationIdx = 0
- fieldName = medObj.getFieldNames()[fieldIdx]
- dtitfield = medObj.getFieldIteration(fieldName,iterationIdx)
- it = dtitfield[0]
- dt = dtitfield[1]
- fieldObj = medObj.getField(fieldName,it,dt)
- nbOfFields = medObj.getNumberOfFields()
- fieldNames = medObj.getFieldNames()
-
- mesh = fieldObj.getSupport().getMesh()
-
-.. note::
- Observations en vrac:
-
- * Un FIELD_i possède un champ de type ``MEDMEM::FIELD_`` qui représente
- le champ informatique réel (objet MEDMEM).
- * FIELD_i::fieldMap variable static de type map qui semble gérer
- les différentes instances de FIELD_i (~pattern factory). Cette
- map peut être requétée au moyen d'un indice de type long appelé
- corbaIndex.
- * Quand on crée un FIELD_i par le constructeur d'argument
- ``MEDMEM::FIELD_``, le ``MEDMEM::FIELD_`` est ajouté dans la map avec
- incrément du corbaIndex
- * La fonction FIELD_i::read(i) redirige vers la fonction read(i) du
- ``MEDMEM::FIELD_`` associé
- * A CONFIRMER: Il semble que les fonctions de chargement
- ``readStructFile*()`` charge toutes les données du fichier med,
- alors qu'en MEDMEM seules les meta-données sont chargées.
- * A CONFIRMER: il semble que le chargement d'une structure MED
- CORBA peut se faire sans passer par le composant (cf. l'interface
- de MED)
-
-Interface avec le module VISU
-=============================
-
-Des interactions sont possibles entre MED et VISU à partir du moment
-où les données med sont gérées dans l'étude, c'est-à-dire sous la
-forme d'objets SALOME_MED (voir ci-dessus) publiés dans l'étude. Les
-deux conditions sont aujourd'hui nécessaires (objet corba + publié
-dans l'étude) mais il semble que ce ne soit lié qu'à un choix
-d'interface VISU (la fonction ``ImportMed`` en particulier) qui peut
-a priori être modifié. A CONFIRMER.
-
-L'exemple de code ci-dessous (en python, mais il peut être transposé à
-une implémentation C++) montre par exemple comment envoyer au module
-VISU une requête de visualisation d'un champs hébergé par le module
-MED (en fait, les données sont gérées au travers d'un objet corba
-SALOME_MED "délocalisé" et qui a été référencé dans l'étude dans la
-catégorie du composant MED). Les importations standard (salome,
-SALOME_MED, ...) sont supposées avoir été faites au préalable (voir
-les exemples précédents):
-
-.. code-block:: python
-
- # Load the med structure using MED
- medComp=salome.lcc.FindOrLoadComponent("FactoryServer", "MED")
- filePathName = "myfile.med"
- medComp.readStructFileWithFieldType(filePathName,salome.myStudyName)
-
- # Get the VISU component
- import VISU
- visuComp = salome.lcc.FindOrLoadComponent("FactoryServer", "VISU")
- visuComp.SetCurrentStudy(salome.myStudy)
-
- # Get the sobject associated to the med object named "Med"
- aSObject = salome.myStudy.FindObject("Med")
- isPresent, medSObj = aSObject.FindSubObject(1)
-
- # Finally, import the med sobject in VISU
- result = visuComp.ImportMed(medSObj)
-
-Il est possible de d'aller plus loin et par exemple de déclencher
-l'affichage d'une scalarmap d'un champ spécifique pour une itération
-particulière (voir la fonction
-``TEST_SALOMEMED_requestToVisu_scalarmap`` du fichier
-``SALOMEMED_tester.py`` fourni dans les sources d'exemple).
-
-Liens complémentaires:
-
-* http://nepal.der.edf.fr/pub/SALOME_userguide/VISU_V5_1_3/doc/salome/gui/VISU La documentation utilisateur en ligne du module VISU
-
-
-Notes en vrac
-=============
-
-Questions:
-
-* Comment obtenir le nom du fichier med à partir d'une structure med?
-* Peut-on imaginer un moyen de fournir l'objet MEDMEM::MED à partir de
- la donnée de l'objet CORBA SALOME_MED::MED?
-
-Remarques:
-
-* A part, les opérations arithmétiques (+,-,*,/), aucune opération
- n'est définie.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, XMED
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Démonstrateur XMED, vue d'ensemble
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Le module XMED est un espace d'expérimentation pour le développement
-des opérations de manipulation de champs. Il complète des
-développements intégrés directement dans le module MED et gérés dans
-la branche CVS BR_medop.
-
-Une maquette est au point pour illustrer les propositions en matière
-d'ergonomie d'utilisation et en matière d'architecture technique. La
-maquette permet de réaliser des cas d'utilisation de la forme:
-
-* Chargement d'un fichier med dans le module MED (ou publication par
- un code de calcul).
-* Sélection graphique des champs de l'étude à mettre à disposition
- dans la console utilisateur ("calculette" en mode texte qui
- concraitement correspond à l'interface python de SALOME).
-* Dans la calculette, exécution d'opérations algébriques (+,-,*,/)
- entre champs avec possibilité d'utiliser des scalaires dans des
- opérations de type transformation linéaire (y=ax+b ou y et x sont
- des champs et a et b des scalaires). Egalement quelques fonctions
- mathématiques standard applicables sur des champs (pow, sqrt).
-* Possibilité de visualiser les champs produits avec VISU
-* Possibilité d'exporter des champs produits dans un fichier med
-
-La figure ci-dessous montre le résultat d'une séquence d'utilisation
-dans laquelle les champs "testfield1" et "testfield2" ont été
-sélectionnés dans l'arbre d'étude pour être utilisés dans la console
-textuelle sous les noms de variables f1 et f2. L'image montre le
-contrôle visuel du résultat de l'opération f1+f2-(f1-f2)^2 tapée en
-ligne de commande:
-
-.. image:: images/medop-gui-result.png
- :align: center
-
-La séquence ci-après montre le cas d'utilisation complet en
-images:
-
-1. Sélection d'un champs sur un pas de temps dans l'arbre d'étude
-2. Saisie d'un nom de variable (alias) pour manipuler ce champ. Par
- défaut, le nom du champ est proposé (``testfield1`` ici). Dans
- l'exemple, l'utilisateur remplace par l'alias ``f1``.
-3. Contrôle visuel du champ ``testfield1`` manipulé par sa variable
- ``f1`` au moyen de la commande ``f1.visu()``
-4. Chargement du champ ``testfield2`` sous le nom ``f2``, exécution de
- l'opération ``f1+f2-(f1-f2)^2`` et contrôle visuel du résultat,
- récupéré ici dans une variable de nom ``result``.
-
-.. |IMG_SELECT| image:: images/medop-gui-selectfield_scale.png
-.. |IMG_ALIAS| image:: images/medop-gui-aliasfield_scale.png
-.. |IMG_VISU| image:: images/medop-gui-visufield_scale.png
-.. |IMG_RESULT| image:: images/medop-gui-result_scale.png
-
-+---------------+---------------+
-| |IMG_SELECT| | |IMG_ALIAS| |
-+---------------+---------------+
-| |IMG_VISU| | |IMG_RESULT| |
-+---------------+---------------+
-
-La solution technique est construite sur les principes suivants:
-
-* Les données MEDMEM sont physiquement chargées par le composant MED,
- c'est-à-dire dans le processus ``Container`` de SALOME, et sont
- référencées dans l'étude SALOME.
-* Les opérations sont physiquement des opérations entre objets MEDMEM
- purs qui ont lieu dans le composant MED.
-* Les opérations sont pilotées par des objets proxy python instanciés
- dans la console TUI puis manipulés par l'utilisateur. Ces objets
- proxy savent accéder aux objets MEDMEM au travers de leur interface
- CORBA.
-
-Ainsi, l'architecture technique est construite pour pouvoir travailler
-sur des données MEDMEM pur en partant de pointeurs CORBA manoeuvrés
-depuis des objets python dans l'interface textuelle de
-SALOME. L'effort principal a donc porté sur la mise au point de
-l'interface technique qui permet de lier des variables représentant
-les champs au niveau du GUI (techniquement, la calculette est
-l'interpréteur python embarqué dans le GUI, étendu de quelques
-fonctions pour la manipulation de champs), alors que les données
-MEDMEM sont physiquement disponibles uniquement au niveau des
-composants CORBA (et les opérations implémentées dans MEDMEM
-uniquement).
-
-Pour le moment, la maquette est limitée à des operations entre champs
-qui partagent le même support med (contrainte de MEDMEM) et le
-résultat est calculé sur toutes les composantes et tout le domaine de
-définition du champs (cette deuxième contrainte est juste parce que
-les extentions n'ont pas encore été examinées). Enfin, le support de
-gestion des données est supposé être l'étude SALOME et la structure
-MED qui y est publiée.
+++ /dev/null
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Appendix: Documentation references
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. include:: medop-definitions.rst
-
-References:
-
-* (**in french**) |REF_EDF_VCA_H-I2C-2009-03595-FR|_ - Valérie Cano - décembre 2009
-* |REF_CEA_VBE_MEDMEM|_ - Vincent Bergeaud - janvier 2007
-* (**in french**) |LINK_EDF_MEDDOC|_ - documentation en ligne (EDF)
-
-Slides (**in french**):
-
-* |REF_EDF_PRESMANIPCHP01|_ - Valérie Cano, Guillaume Boulant - janvier 2010
-* |REF_EDF_PRESMANIPCHP02|_ - Guillaume Boulant - octobre 2010
-* |REF_EDF_PRESMANIPCHP03|_ - Guillaume Boulant - mars 2011
-* Présentation à la Journée des Utilisateurs de SALOME de 2011 (JUS2011):
-
- - |REF_EDF_JUS2011_PDF|_ - Anthony Geay (CEA), Guillaume Boulant - novembre 2011
- - |REF_EDF_JUS2011_OGV1|_ (**video**)
- - |REF_EDF_JUS2011_OGV3|_ (**video**)
- - |REF_EDF_JUS2011_OGV4|_ (**video**)
-
-Working notes (**in french**):
-
-* |REF_EDF_GBO_WORKNOTE|_ - Guillaume Boulant - novembre 2010
-* |REF_EDF_ELO_REM|_ - Eric Lorentz - novembre 2010
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation, med
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-Module MED: Spécifications fonctionnelles et techniques
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-Ce texte présente les spécifications informatiques pour le
-développement d'un module de manipulation de champs qui répond à
-l'expression de besoins formulée dans le cahier des charges
-|REF_EDF_VCA_H-I2C-2009-03595-FR|_.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Description des cas d'application de référence
-==============================================
-
-Plusieurs cas d'applications métier sont identifiés pour piloter le
-développement du module de manipulation de champs:
-
-* **Analyser et post-traiter le résultat d'un calcul**. C'est l'usage
- principal qui consiste typiquement à créer des champs comme le
- résultat d'*opérations mathématiques* dont les opérandes sont des
- champs et des scalaires. On compte également dans cette catégorie
- les *opérations de restriction* qui permettent d'extraire puis
- utiliser une partie d'un champs, c'est-à-dire de créer un champ
- comme la restriction d'un autre champ à une partie de son domaine de
- définition (certaines composantes, certains pas de temps, limitation
- à un groupe de mailles).
-* **Comparer des champs issus d'un calcul paramétrique**. Il s'agit
- d'une variante du cas précédent qui consiste à mesurer et visualiser
- les variations entre des champs issues de sources de données
- différentes (différents fichiers med).
-* **Préparer les conditions aux limites d'une calcul**. Il s'agit de
- pouvoir initialiser un champ sur un maillage ou un groupe de
- mailles, c'est-à-dire créer un champ de toute pièce sur un
- support spatial donné, par exemple par la donnée d'une fonction
- mathématique qui donne les valeurs des composantes en fonction des
- coordonnées spatiales.
-* **Gérer des données de calcul**. Il s'agit typiquement de pouvoir
- rassembler au sein d'un même fichier med des champs et des maillages
- issues de différentes sources de données, et/ou créés au travers des
- cas d'application présentés ci-dessus.
-
-Modèle conceptuel des données
-=============================
-
-On rappelle ici les concepts utilisés dans le module et les modalités
-d'utilisation de ces concepts. Le point de vue est celui de
-l'utilisateur du module de manipulation de champs. Il s'agit
-essentiellement pour le moment d'éclaircir l'ergonomie d'usage sur le
-plan conceptuel, avant d'aborder la déclinaison en spécifications
-techniques pour lesquelles les particularités du modèle MED devront
-être intégrées à la réflexion.
-
-Concept de champ
-----------------
-
-Le concept central est celui de *champ*, c'est-à-dire une grandeur
-physique exprimée sur un domaine spatial D. La grandeur peut être de
-type scalaire (une température), de type vectorielle (une vitesse) ou
-de type tensorielle (les contraintes). En un point de l'espace, elle
-se définie donc par la donnée d'une ou plusieurs valeurs numériques
-appelées les *composantes* (1 pour un champ scalaire, 3 pour un champ
-vectoriel 3D, 6 pour un champ tensoriel symétrique 3D).
-
-.. note:: Une pratique courante au niveau des codes est de stocker
- plusieurs grandeurs physiques différentes dans un même champs med
- (au sens informatique du terme). Par exemple, le champ
- électromagnétique à 6 composantes, plus le champ de température
- scalaire peuvent techniquement être stockés dans un même champs med
- à 7 composantes. C'est pourquoi, le module de manipulation de
- champs doit fournir des fonctions de restrictions qui permettent
- d'extraire certaines composantes pour former la grandeur physique à
- étudier. Dans la suite du document, on part du principe que l'on
- peut se ramener dans tous les cas au cas d'un champ homogène tel
- que défini plus haut.
-
-Dans le cadre d'un modèle numérique discret, les valeurs du champ sont
-exprimées pour un nombre fini de positions, qui correspondent à des
-lieux particuliers du maillage. Suivant la nature des modèles de
-calcul, les valeurs peuvent être données par cellule, par face, par
-noeud, aux points de gauss, ...
-
-Ainsi, un champ discret est un objet dont les valeurs peuvent être
-lues selon les dimensions suivantes:
-
-* *La position p dans l'espace*, caractérisée par le type de l'élément
- de maillage support et son numéro identifiant
-* *La composante c*, caractérisée par son indice (jusqu'à 6
- composantes dans les modèles physiques envisagés)
-
-L'évolution d'un champ dans le temps peut être exprimée sous la forme
-d'une série temporelle, c'est-à-dire une séquence de champs donnés
-pour des instants discrets. Aussi, si l'on manipule un champ qui varie
-dans le temps, l'accès aux valeurs introduit une dimension
-supplémentaire:
-
-* *Le temps t*, caractérisé par un numéro de pas de temps
- (correspondant en général à une étape du calcul qui a produit le champ).
-
-.. note:: Il s'agit là d'une représentation conceptuelle standard dont
- le |LINK_EDF_MEDDOC|_ fait une expression détaillée. En
- particulier, la position p est déterminée par la donnée du type
- d'élément support (valeurs aux noeuds, aux mailles, aux noeuds par
- éléments, aux points de gauss) et de l'indice de cet élément. En
- général, le type d'éléments support est résolu à l'initialisation
- et l'indice peut suffire au repérage dans les algorithmes. Le temps
- t est déterminé par un numéro d'itération, qui peut éventuellement
- être complété par un numéro d'ordre. Le cas des points de gauss
- ajoute un cran de complexité dans la mesure où il faut repérer
- l'entité géométrique (maille, face, arrête) puis le point de gauss
- de cette entité. A noter que dans le modèle MED, le concept de
- série temporelle de champ n'est pas explicitement définie et
- l'accès à des valeurs à différents instants t1 et t2 nécessite le
- chargement des champs ``F1=F(t1)`` et ``F2=F(t2)``.
-
-Par convention, on utilisera par la suite les notations:
-
-* **U(t,p,c)** pour désigner la valeur de la composante c d'un champ U
- à la position p et prise à l'instant t;
-* **U(t,p,:)** pour signifier que l'on manipule l'ensemble de toutes
- les composantes;
-* **U(t,:,c)** pour signifier que l'on manipule le domaine de
- définition spatial complet.
-
-Dans une grande majorité des cas d'usage on travaille à temps t fixé
-et sur un domaine spatiale prédéfini. Aussi on utilisera également la
-notation à deux arguments ``U(:,:)`` ou tout simplement ``U`` (dès
-lors qu'il n'y a pas ambiguïté) pour désigner un champ complet et Uc
-pour désigner la composante c du champ avec c=1..6.
-
-Concept d'opération
--------------------
-Le deuxième concept à préciser est la notion d'*opération*. Une
-opération dans le présent contexte est l'application d'un opérateur
-sur un ou plusieurs champs pour produire une grandeur de type champ ou
-de type valeur numérique.
-
-Par exemple, la formule ``W=OP(U,V)`` indique que le champ W est formé
-à partir des champs U et V en arguments d'une fonction OP. Dans le cas
-d'une opération algébrique comme l'addition (cf. :ref:`Spécification
-des opérations<xmed-specifications>`, le résultat attendu par défaut
-est que pour chaque instant t, chaque position p et chaque composante
-c, on a ``W(t,p,c)=U(t,p,c)+V(t,p,c)`` (que l'on peut noter également
-``W(:,:,:)=U(:,:,:)+V(:,:,:)`` compte-tenu de la convention présentée
-plus haut). Ce n'est cependant pas une règle et l'utilisateur peut
-très bien manoeuvrer les champs en détaillant et mixant les
-composantes (par exemple ``W(:,:,3)=5+U(:,:,1)*V(:,:,2)``), ou encore
-ne travailler que sur un domaine spatial et/ou temporel particulier
-(cf. |REF_EDF_VCA_H-I2C-2009-03595-FR|_ §5.4.1).
-
-On formalise donc le concept d'opération par les propriétés suivantes:
-
-* L'opérateur peut produire un champ (par exemple la somme de deux
- champs W=sum(U,V)=U+V), une valeur numérique (par exemple la moyenne
- spatiale d'un champ m=smoy(U)) ou une valeur logique (par exemple le
- test d'égalité de deux champs b=isequal(U,V));
-* L'opérateur peut être paramétré par la donnée de valeurs numériques
- (par exemple, le changement d'unité peut être défini comme une
- multiplication par un scalaire V=multiply(U,1000)=1000*U);
-* L'opérateur est caractérisé par un domaine d'application qui
- spécifie la portée de l'opération. Ce domaine comporte plusieurs
- dimensions:
-
- - Un domaine temporel T qui spécifie les pas de temps sur lesquels
- l'opération est appliquée;
- - Un domaine spatial D qui spécifie la limite de portée de
- l'opérateur et donc le domaine de définition du champ produit (qui
- correspond dans ce cas à une restriction du domaine de définition
- des champs en argument);
- - Un domaine de composantes C qui spécifie les composantes sur
- lesquelles l'opération est appliquée;
-
-.. note::
- Sur le plan informatique, l'opérateur aura également un paramètre
- appelé *option* qui pourra indiquer par exemple dans une
- opération unaire V=F(U) si le résultat V est une nouvelle instance
- de champ ou la valeur modifiée du champ de départ U. Il pourra
- également être amené à manoeuvrer des paramètres de type chaîne de
- caractères, par exemple pour les opérations de changement de nom
- des champs.
-
-De manière générale, on utilisera la notation
-**(W|y)=OP[D,C,T](P,U,V,...)** pour désigner une opération OP:
-
-* **(V|y)**: V ou y désignent respectivement un résultat de type
- champ ou de type valeur numérique ou logique;
-* **[T,D,C]**: le domaine d'application de l'opérateur avec T le
- domaine temporel, D le domaine spatial et C le domaine des
- composantes;
-* **P,U,V,...**: les paramètres numériques P (liste de valeurs
- numériques) et les champs U,V,... en arguments de l'opérateur;
-
-On note également les particularités suivantes pour certaines
-opérations:
-
-* Le domaine de définition du champ produit par une opération peut
- être différent du domaine de définition des champs en argument. Par
- exemple, dans le cas d'une opération de projection de champ, le
- domaine spatial résultat peut être modifié par rapport au domaine de
- définition initial, soit par la modification de la zone géométrique,
- soit par modification des entités de maillage support.
-* En dehors des opérations de type dérivée et intégrale, les valeurs
- résultats sont déterminées de manière locale en chaque point du
- domaine d'application. Par exemple, l'addition W=U+V consiste à
- produire un champ W dont les valeurs en chaque point p sont la somme
- des valeurs des composantes de U et V en ce point p: ``W=U+V <=>
- W(:,p,:)=U(:,p,:)+V(:,p,:)`` pour tout point p du domaine
- d'application D.
-
-Concept de domaine d'application
---------------------------------
-
-Un domaine d'application est associé à une opération (et non pas à un
-champ). Il a pour objectif de restreindre la portée de l'opération en
-terme spatial, temporel, jeu des composantes.
-
-Pour ce qui concerne le domaine spatial D, plusieurs modalités de
-définition sont envisagées:
-
-* la donnée d'un maillage ou d'un groupe d'éléments du maillage;
-* un système de filtres qui peut combiner:
-
- - une zone géométrique définie indépendamment du maillage (boîte
- limite par exemple),
- - des critères conditionnant le calcul (par exemple U(t,p,c)=1 si
- V(t,p,c)<seuil).
-
-.. warning:: Version 2010: D pourra correspondre au maillage complet
- et dans la mesure du possible à un groupe d'éléments du maillage
-
-Ce domaine d'application peut être différent du domaine de définition
-des champs mais il doit être compatible (recouvrement spatial partiel
-au moins et même support d'entité de maillage). Ainsi, sans précision
-particulière, une opération s'applique à l'ensemble du domaine de
-définition des champs en argument (qui dans la pratique MED est
-spécifié par le support et correspond en général au maillage
-complet).
-
-Limites d'utilisation
----------------------
-
-Plusieurs situations doivent être examinées pour poser les limites
-d'utilisation:
-
-* Les champs en argument n'ont pas tous le même domaine de définition,
- par exemple parcequ'il ne sont pas définis sur les mêmes zones
- géométriques ou parcequ'ils ne sont pas donnés sur le même type
- d'entité de maillage. On peut imaginer dans ce cas produire le
- résultat sur les zones de recouvrement uniquement.
-* Le domaine de définition des champs et le domaine d'application de
- l'opérateur ne sont pas compatibles, par exemple parcequ'on demande
- une restriction sur une zone géométrique qui ne fait pas partie de
- la zone de définition du champ d'entrée. A priori, ce type
- d'opération est déclaré en échec.
-* Les champs en argument ne sont pas définis sur les mêmes pas de
- temps. Si l'opération est tolérée (techniquement MEDCoupling permet
- de le faire), le pas de temps résultat est indéfini.
-
-.. warning:: **A faire**: spécifier les modalités de prise en compte de
- ces différentes situations (au moins sur le plan conceptuel).
-
-Au delà de ces limites conceptuelles, il faut avoir en tête les
-limites techniques liées à l'usage de MED mémoire (paquet
-MEDCoupling). Par exemple, MEDCoupling impose que les champs opérandes
-soient définis sur le même maillage support (on parle ici de l'objet
-informatique correspondant au maillage). Deux champs construits sur le
-même maillage (du point de vue conceptuel) mais issus de deux fichiers
-med différents sont considérés comme des champs définis sur des
-maillages support différents, c'est-à-dire que les objects
-informatiques correspondant aux maillages sont différents (chargés de
-deux fichiers différents). En l'état, il est donc impossible par
-exemple de faire la comparaison de champs résultats d'une étude
-paramétriques. MEDCoupling fournit une solution qu'il faudra mettre en
-oeuvre de manière ergonomique au niveau du module MED. Il est possible
-de changer le maillage support M1 d'un champs par un maillage M2 à
-partir du moment où les maillages M1 et M2 sont identiques
-géométriquement à une erreur près qu'il est possible de spécifier.
-
-.. note::
- D'autres situations limites peuvent être évoquées sous l'angle
- informatique. Ce sont des situations qui a priori n'ont pas de
- raison d'exister sur le plan conceptuel mais qui peuvent très bien
- survenir au niveau du module informatique compte-tenu des
- particularités du modèle MED. Par exemple:
-
- * Le nombre et la nature des composantes ne sont pas identiques
- pour tous les champs d'entrée. Par exemple, U défini ses
- composantes comme U(:,:,1)=Ux, U(:,:,2)=Uy, U(:,:,3)=Uz et V les
- défini comme U(:,:,1)=Uz, U(:,:,2)=Ux, U(:,:,3)=Uy. Cette
- situation peut être gérée techniquement par exemple au moyen
- d'une carte de correspondance qui accompagnerai chacun des champs
- pour exprimer le sens physique de chaque composants (histoire de
- ne pas ajouter des choux et des carottes).
-
-Spécifications générales
-========================
-
-Le diagramme ci-dessous représente un découpage fonctionnel qui rend
-compte de l'expression des besoins:
-
-.. image:: images/xmed-functions.png
- :align: center
-
-On peut identifier les fonctionnalités suivantes:
-
-* **Opérations**: fonctions de manipulation de champs proprement
- dites;
-* **Persistance**: fonctions d'enregistrement persistant et de
- chargement des données (au format med fichier)
-* **Visualisation**: fonctions de contrôle visuel des champs
- manipulés
-* **Export des données**: fonction de transposition des données de
- champs dans un format textuel directement exploitable et de manière
- autoportante dans une autre application, par exemple en python au
- moyen des structures de données Numpy.
-
-Ces fonctions s'articulent autour d'un conteneur qui héberge les
-champs manipulés et les supports de ces champs (représenté par le
-cylindre central).
-
-Un scénario d'utilisation type est:
-
-* Préparation des champs à manipuler, par deux moyens complémentaires:
-
- - Utilisation des fonctions de persistance: chargement depuis un
- fichier med d'un ensemble de champs qui partagent le même espace
- de définition;
- - Utilisation des opérations de champs: chargement d'un maillage
- depuis un fichier med, puis création ab initio de champs au moyen
- des opérations de champs;
-
-* Manipulation des champs par application des opérations à
- disposition, puis contrôle visuel des résultats produits au moyen
- des fonctions de visualisation mises à disposition par SALOME;
-* Restitution des résultats produits, par deux moyens complémentaires:
-
- - Restitution des champs produits et/ou modifiés sous une forme
- persistante (fichier med);
- - Restitution d'une partie seulement des résultats sous forme de
- tableaux de valeurs sauvegardés dans un fichier texte ou exporté
- sous forme de tableau numpy
-
-.. _xmed-specifications:
-
-Spécification des opérations
-============================
-
-Le cahier des charges définit trois catégories d'opérations
-mathématiques:
-
-* **Les opérations arithmétiques**, dans lesquelles le résultat à la
- position p et à l'instant t ne dépend que des données à la position
- p et à l'instant t;
-* **Les opérations d'interpolations**, dans lesquelles le résultat
- est exprimé sur des entités de maillages différentes ou est projeté
- sur une zone géométrique différente du domaine de définition
- initial;
-* **Les opérations globales**, dans lesquelles le résultat peut
- demander l'agrégation des valeurs sur plusieurs position p ou
- plusieurs pas de temps t (calcul d'extremum, d'intégrale);
-
-Auxquelles, on peut ajouter à des fins de gestion des données:
-
-* **Les opérations de génération**, qui permettent de créer un champ
- sur un maillage vierge ou d'étendre le domaine spatial de définition
- d'un champ;
-* **Les opérations d'ordre sémantique**, qui permettent de modifier
- les méta-données associées aux champs (nom, unité, ...)
-* **Les opérations de diagnostic**, qui permettent d'effectuer une
- analyse particulière d'un champ et/ou des éléments de maillage
- associés et de fournir un compte-rendu, sous la forme d'une
- structure de données ou d'un texte formaté affichable dans
- l'interface utilisateur.
-
-La suite de la section décrit les spécifications prévues pour chaque
-type d'opération unitaire. Un dernier paragraphe concerne les
-modalités de combinaison des opérations et spécifie la définition d'un
-domaine d'application sur une opération, qui permet de restreindre la
-portée de l'opération en terme spatial, temporelle ou nature des
-composantes impliquées.
-
-Les opérations arithmétiques
-----------------------------
-
-Les opérations arithmétiques regroupent:
-
-* les **opérations algébriques** (+, -, x, /);
-* les **opérations vectorielles** (produit scalaire, produit
- vectoriel, produit tensoriel);
-* l'**application d'une fonction mathématique** à variable scalaire
- (exponentielle, logarithme, fonctions trigonométriques, valeur
- absolue, partie entière) ou à variable de type champ (les fonctions
- de norme par exemple).
-
-Pour les besoins des spécifications informatiques, il est plus commode
-de classer ces opérations en deux catégories:
-
-* les **opérations unaires**, qui prennent un opérande unique en
- argument. C'est le cas de la plupart des fonctions mathématiques
- envisagées;
-* les **opérations binaires**, qui prennent deux opérandes en
- argument. C'est le cas des opérations algébriques et des opérations
- vectorielles.
-
-A partir de cette classification, il convient de distinguer trois
-formes d'usage selon la nature des opérandes:
-
-* les opérandes sont exclusivement des scalaires (typiquement des
- valeurs de composantes des champs et des paramètres numériques). Par
- exemple::
-
- W(:,:4) = 1+2xU(:,:,2)+V(:,:,3)
-
-* les opérandes sont exclusivement des champs. Par exemple::
-
- W = U + V (addition)
- W = U ^ V (produit vectoriel)
-
-* les opérandes sont des champs et des paramètres numériques. Par exemple::
-
- W = 3xU - 2xV
- W = U + 2
-
-Le premier cas de figure (opérandes scalaires) est trivial car les
-règles mathématiques conventionnelles s'appliquent et sont
-implémentées dans tous les langages (Python et C++ en
-particulier). Les cas 2 et 3 par contre doivent être précisés car (i)
-les règles de comportement ne peuvent pas être simplement déduites des
-règles mathématiques (quel est le résultat de ``W = U + 2`` ?) et
-(ii) certaines écritures ne peuvent avoir aucun sens (par exemple
-``W = 2 / U``). Il convient donc de préciser les conventions et
-les limites sur ces deux cas de figure.
-
-Dans le cas des opérations unaires où l'opérande est un champ, on doit
-distinguer deux cas d'usage:
-
-* l'application d'une fonction mathématique à valeur de type champ. Ce
- cas est trivial également et on applique la règle d'usage de la
- fonction. C'est typiquement le cas des fonctions de calcul de
- norme.
-* l'application d'une fonction mathématique à valeur scalaire. Dans ce
- cas, on convient d'appliquer la fonction de manière unitaire sur
- chacune des composantes c du champ: ``W(:,:,c) = OP( U(:,:,c)
- )``
-
-Dans le cas des opérations binaires, on recense les combinaisons
-d'opérandes suivantes (les lettres capitales représentent des champs,
-et les lettres minuscules une valeur scalaire qui peut être un
-paramètre numérique ou la composante d'un champ):
-
-* U+V ajoute les composantes en regard: W(:,:,c)=U(:,:,c)+V(:,:,c)
-* U-V soustrait les composantes en regard: W(:,:,c)=U(:,:,c)-V(:,:,c)
-* U*V multiplie les composantes en regard: W(:,:,c)=U(:,:,c)*V(:,:,c)
-* U/V divise les composantes en regard: W(:,:,c)=U(:,:,c)/V(:,:,c)
-* U+x ajoute x à toute les composantes: W(:,:,c)=U(:,:,c)+x
-* U*x multiplie toutes les composantes par x: W(:,:,c)=U(:,:,c)*x
-* U.V produit scalaire des champs U et V: W(:,:c)=U(:,:,c)*V(:,:,c)
-* U^V produit vectoriel des champs U et V: W(:,:1)=U(:,:,2)*V(:,:,3)-U(:,:,3)*V(:,:,2), ...
-
-.. note::
- Pour ce qui concerne les opérations vectorielles, un convention
- implicite est appliquée par laquelle on suppose que les composantes
- sont rangées dans l'ordre des dimensions spatiales U1=Ux, U2=Uy,
- U3=Uz. Sur le plan informatique au niveau du modèle MEDMEM, ceci
- n'est pas garanti et aucun élément du modèle ne permet de
- contraindre l'application de cette convention. Il convient donc de
- prévoir des fonctions techniques qui permettront de mettre en
- correspondance les indices de composantes et les dimensions
- spatiales (par exemple par la données d'une carte de correspondance
- applicable à un ensemble de champs).
-
-.. warning::
- A développer:
-
- * Analyse dimensionnelle du champ résultats pour adapter
- l'unité. Par exemple, si on fait UxV où U et V sont exprimés en
- [m] alors le résultat est en [m2].
-
-Les opérations d'interpolation
-------------------------------
-.. warning:: Non prévues au programme 2010.
-
-Les opérations mathématiques globales
--------------------------------------
-.. warning:: Non prévues au programme 2010.
-
-Les opérations de génération
-----------------------------
-.. warning:: EN TRAVAUX
-
-Les opérations de génération sont des fonctions qui permettent de
-créer un champ sur un domaine du maillage où il n'est pas défini
-initialement. Deux cas de figure peuvent se présenter:
-
-* Le champ n'existe pas et il doit être créé sur un domaine à définir;
-* Le champ existe mais les valeurs ne sont pas définies sur l'ensemble
- du maillage.
-
-On peut envisager plusieurs modalités de mise en oeuvre:
-
-* le prolongement par une valeur constante (ou plus généralement par
- une fonction de l'espace?);
-* les valeurs du champs sont données par une fonction f(p,t) qui prend
- la position p et le pas de temps t en argument;
-* on peut prédéfinir le champ position **r** qui porte les
- coordonnées spatiales de l'élément de maillage support, puis faire
- une opération arithmétique standard.
-
-Les opérations d'ordre sémantique
----------------------------------
-.. warning:: EN TRAVAUX
-
-Concerne:
-
-* le changement de nom du champ
-* le changement d'unité du champ (il s'agit ici de conserver la
- cohérence entre la valeur numérique et l'attribut "unité" d'un
- champ.
-
-Les opérations de diagnostic
-----------------------------
-.. warning:: EN TRAVAUX. A faire en fonction des besoins des cas d'application
-
-On peut identifier plusieurs types d'opérations:
-
-* les opérations à diagnostic booléen, par exemple
- b=isequal(U,V)=[U=V] (où [.] signifie évaluation de la condition
- entre crochers)
-* les opérations à diagnostic textuel, par exemple afficher les
- méta-données associées à un champs (unité, nom, maillage support,
- type d'entité, pas de temps, ...)
-* les opérations à diagnostic structuré, qui donneraient une structure
- de données exploitable au niveau d'un code logiciel.
-
-Combinaison des opérations
---------------------------
-.. warning:: EN TRAVAUX. Indiquer les règles de combinaison (associativité, commutativité, ...)
-
-Définition d'un domaine d'application
--------------------------------------
-Pour rappel, un domaine d'application peut être associé à une
-opération pour restreindre la portée de l'opération en terme spatial,
-temporelle ou nature des composantes impliquées.
-
-.. warning:: Todo: spécifier comment on le définit et les modalités d'applications.
-
-Spécification de l'ergonomie
-============================
-
-L'ergonomie générale d'utilisation du module de manipulation de champs
-est inspirée des logiciels comme octave ou scilab. Elle associe une
-interface graphique, pour sélectionner et préparer les données, avec
-une interface texte (la console python) pour le travail effectif sur
-les données:
-
-* L'**interface graphique** a pour fonction essentielle de sélectionner et
- préparer les champs à manipuler dans l'interface texte, puis
- fournit des fonctions pour la gestion générale des données
- (chargement, sauvegarde, contrôle visuel, export).
-* L'**interface texte** offre un jeu de commandes pour manipuler les
- champs (afficher les données, effectuer des opérations), piloter les
- fonctions d'affichage (contrôle visuel au moyen des modules VISU
- et/ou PARAVIS) et communiquer avec l'interface graphique (ajouter
- des nouveaux champs dans l'espace de gestion, mettre à jour les
- méta-données d'un champ).
-
-Sur le plan de l'ergonomie, cela se traduit par un processus de
-travail dans lequel on peut distinguer différentes phases:
-
-* Une phase de préparation des champs à manoeuvrer sous la forme de
- variables nommées et simples à manipuler dans l'interface
- textuelle. Lors de cette phase, l'utilisateur spécifie de manière
- graphique tout ce qui peut être définis à l'avance et pour toute la
- durée du processus de travail. Par exemple, en spécifiant le nom des
- fichiers med source des données et les noms des champs à utiliser
- dans ces fichiers, le pas de temps de travail, le jeu des
- composantes à considérer, le domaine d'application des opérations;
-* Une phase de manipulation des champs proprement dite, qui a lieu
- principalement dans l'interface textuelle, et qui peut s'accompagner
- de contrôle visuel des résultats et/ou d'export à destination
- d'outils complémentaires indépendants (gnuplot, python, ...);
-* Une phase de restitution des champs produits pour assurer la
- persistance des données de travail. Tout les champs créés par les
- manipulations au niveau de l'interface textuelle ne sont pas à
- sauvegarder, et on on propose donc à l'utilisateur les moyens de
- choisir les champs à conserver. Cette phase peut amener
- l'utilisateur à préciser les informations manquantes, comme les noms
- de fichiers, les noms de champs produits, les unités, ...
-
-Dans ce cadre, l'utilisation type des fonctions de manipulation de
-champs est un processus de la forme suivante:
-
-1. Chargement d'un fichier med dans SALOME et exploration du contenu,
- composé de maillages, sur lesquels sont définis des champs, pouvant
- contenir un ou plusieurs pas de temps.
-2. Sélection (graphique) des champs à manipuler, avec la possibilité
- de préciser des restrictions d'utilisation (pas de temps,
- composantes, groupe de maille).
-3. Création de nouveaux champs par l'exécution d'opérations
- algébriques (+,-,*,/) entre champs, l'application de fonctions
- mathématiques standard (pow, sqrt, abs), ou encore l'initialisation
- "from scratch" à partir d'un maillage support.
-4. Contrôle visuel rapide des champs produits (avec les modules VISU
- et/ou PARAVIS de SALOME, pilotés automatiquement depuis l'interface
- utilisateur)
-5. Enregistrement d'une partie des champs produits dans un fichier med
-
-
-Les espaces de données utilisateur
-----------------------------------
-
-Sur le plan conceptuel, on est amené à définir deux espaces de données
-utilisateur:
-
-* **l'espace des données source** (*dataspace*), dans lequel
- l'utilisateur définit les sources de données med (*datasource*),
- c'est-à-dire les fichiers med dans lesquels sont lus les champs
- et maillages. Cet espace est en lecture seule et permet
- l'exploration des sources de données (aperçu des maillages et des
- champs).
-* **l'espace des données de travail** (*workspace*), dans lequel
- l'utilisateur dépose les champs et maillages à utiliser, puis range
- les champs produits au travers des fonctions de manipulation de
- champs.
-
-La figure ci-dessous en donne une représentation imagée avec le
-support de l'interface graphique du module (interface non définitive
-affichée ici pour illustration des spécifications):
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-.. note:: Techniquement, les données sources sont rangées dans l'étude
- SALOME et peuvent être explorées au moyen de l'object browser. Les
- données de travail sont rangées dans un arbre complémentaire et
- manipulable dans la console python.
-
-Le principe général est que **les données sources ne sont jamais
-modifiées**. Le dataspace est un espace de chargement qui permet
-d'explorer puis de sélectionner les données à manipuler. L'utilisateur
-travaille à partir de maillages et de champs chargés préalablement
-dans cet espace, mais ne peut en aucun cas les modifier
-directement. Pour cela, il doit d'abord les sélectionner pour
-utilisation dans l'espace de travail. Ce choix garantie l'intégrité
-des sources de données et permet de rejouer la séquence de travail à
-partir de zéro en cas de besoin (on efface le tableau noir et on
-recommence). Par ailleurs, il permet d'assister graphiquement la
-définition du champs à manipuler effectivement, en particulier pour
-affecter un nom de variable de manipulation.
-
-Les captures d'écrans suivantes montrent le principe d'utilisation sur
-le cas de la sélection d'un pas de temps à utiliser dans l'espace de
-travail. Les données à manoeuvrer (maillage et/ou champs) sont
-sélectionnées pour utilisation dans l'espace de travail, où elles
-peuvent être modifiées et/ou utilisées dans les opérations de
-champs. Ici, le champ est désigné par la varibale ``f4`` dans
-l'interface textuelle:
-
-* Sur cette première capture, on sélectionne le pas de temps n°4 du
- champs ``Pulse`` définit sur le maillage ``Grid_80x80`` de la source
- de données ``timeseries.med`` (concrètement le fichier
- ``timeseries.med``) pour faire apparaître ensuite le menu contextuel
- et choisir l'option "Use in workspace":
-
-.. image:: images/xmed-gui-datasource-contextmenu_70pc.png
- :align: center
-
-* Cette capture montre une fenêtre de dialogue qui invite
- l'utilisateur à spécifier un alias pour la variable python qui
- va permettre la manipulation du champ dans l'interface textuelle de
- l'espace de travail (par défaut, le nom complet du champ est
- proposé). Ici, l'utilisateur spécifie ``f4``:
-
-.. image:: images/xmed-gui-datasource-useinworkspace_70pc.png
- :align: center
-
-* La validation de la fenêtre provoque l'ajout du champs dans l'espace
- de travail (le champ est désormais disponible à la manipulation) et
- définit une variable python de nom ``f4`` qui permet la manipulation
- du champ:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-result_70pc.png
- :align: center
-
-Modalités d'utilisation
------------------------
-
-.. warning:: cette section est à nettoyer car elle contient des
- informations redondantes avec d'autres sections précédentes ou pire
- qui contredisent des sections précédentes.
-
-Dans le cadre défini ci-dessus, une session d'utilisation type est:
-
-* Sélectionner les sources de données puis définir le domaine
- d'application (espace, temps, composantes), avec éventuellement
- l'assistance d'une interface graphique;
-* Charger les champs en conséquence dans l'espace de travail. Cette
- opération propose de définir une variable python pour manipulation
- dans l'interface textuelle.
-* Effectuer les opérations dans l'espace de travail, c'est-à-dire en
- ligne de commandes python (ce qui demandera sans doute un travail
- conséquent de simplification et d'assistance en ligne). Par exemple,
- si ``fa`` et ``fb`` désignent deux champs définis dans l'espace de
- travail, alors on peut en faire la somme par la commande::
-
- >>> r=fa+fb
-
-* Effectuer les contrôles visuel et les diagnostics en ligne de
- commandes python (cf. :ref:`Spécification des fonctions de
- visualisation<specification_visualisation>`)::
-
- >>> view(r)
-
-* Enregistrer les champs produits dans l'espace de travail sous forme
- de fichier med.
-
-Sur cette base, on peut envisager une grande variété de cas d'utilisation:
-
-* La structure MED (champs, maillage et groupes de mailles) est
- chargée dans le dataspace (l'étude SALOME techniquement) et peut
- être explorée au niveau de l'arbre d'étude. L'arbre peut faire
- apparaître:
-
- - les maillages et les groupes (qui peuvent être utilisés
- éventuellement pour restreindre le domaine d'application)
- - les champs dont on peut explorer les composantes et les itérations
-
-* On sélectionne plusieurs champs, éventuellement en sélectionnant les
- pas de temps, les composantes et les domaines d'application spatiaux
-* Menu contextuel --> Modifier un champ, Créer un champ, Prolonger un
- champ, ....
-* On choisi pour la suite "Créer un champ", une fenêtre de dialogue
- s'affiche avec les saisies préremplies avec les données
- sélectionnées. Il est possible de rajouter des éléments ou préciser
- le domaine d'application
-* Une partie de la boîte de dialogue est réservée à la saisie de la
- ligne de commande python qui permet la création du nouveau champ. Le
- nom dans l'étude pour le nouveau champ, ainsi que son nom python,
- sont spécifié par l'utilisateur ({{H|un peu à la mode du module
- system}}).
-* L'opération est exécutée dans l'espace utilisateur (l'interface
- python), de sorte que les variables soient projetées dans cet espace
- et manipulables après l'opération au besoin. Par ailleurs,
- l'utilisateur peut visualiser les ligne de commandes nécessaires à
- taper pour exécuter sa requête.
-
-.. _specification_visualisation:
-
-Spécification des fonctions de visualisation
-============================================
-
-Dans le cadre du module MED, on appelle *fonction de visualisation*
-une fonction qui permet d'avoir un aperçu graphique d'un champ, par
-exemple au moyen d'une carte de champ construite sur une de ses
-composante. Il s'agit là de vue de contrôle pour avoir une idée rapide
-de la forme du champs. Pour créer des représentations spécifiques, on
-préférera passer par les fonctions d'export vers le module PARAVIS.
-
-Les modules VISU et PARAVIS offre des interface de programmation C++
-et python qui permettent le pilotage depuis un module tiers comme le
-module MED. On peut donc envisager une fonction de visualisation
-intégrée au module de manipulation de champs, c'est-à-dire que l'on
-déclenche sans sortir du module MED, et qui exploite les fonctions de
-visualisation des modules VISU et/ou PARAVIS.
-
-Les captures d'écran ci-dessous illustrent la mise en oeuvre de la
-fonction de visualisation:
-
-* Sélection d'un champ pour faire apparaitre le menu contextuel et
- choisir l'option "Visualize":
-
-.. image:: images/xmed-gui-datasource-visualize_70pc.png
- :align: center
-
-* Cette option déclenche l'affichage d'une carte de champ sur le cadre
- d'affichage des viewers SALOME:
-
-.. image:: images/xmed-gui-datasource-visualize-result_70pc.png
- :align: center
-
-Cette fonction est également disponible en ligne de commandes de
-l'interface textuelle. Par exemple si ``f4`` désigne un champ de
-l'espace de travail (importé des données source ou construit par les
-opérations de champs), alors, on obtient une carte de champ par la
-commande::
-
- >>> view(f4)
-
-On peut remarquer d'ailleurs sur la capture d'écran de droite
-ci-dessus que la demande de visualisation déclenche l'exécution de la
-commande ``view`` dans la console de travail sur un champ identifié
-par son numéro (3 dans l'exemple).
-
-.. note:: Tous les champs, qu'ils soient des champs chargés d'une
- source de données ou construits par des opérations de champs sont
- identifiés par un numéro unique et invariant tout au long de la
- session de travail.
-
-Spécification des fonctions de persistance
-==========================================
-
-On adopte le principe de fonctionnement suivant:
-
-* Le module n’assure pas la persistence au sens SALOME du terme,
- c’est-à-dire qu’il ne permet pas la sauvegarde du travail dans une
- étude au format hdf, ni le dump sous la forme de script python
- SALOME. Le besoin n'est pas avéré et on peut même dire que ça n'a
- pas de sens compte-tenu de l'usage envisagé pour le module MED.
-* Par contre, le module fournit des fonctions de sauvegarde du travail
- sous forme de fichiers med, l’export vers les modules VISU et
- PARAVIZ, ou même la sauvegarde de l’historique de l’interface de
- commandes.
-
-Ainsi donc, l'utilisateur aura une fonction (probablement graphique)
-pour définir la sélection des champs de l'espace de travail à
-sauvegarder.
-
-Spécification des fonctions d'export
-====================================
-
-.. warning:: EN TRAVAUX.
-
-Plusieurs export peuvent être proposés:
-
-* Export des champs vers le module PARAVIZ, dans l'objectif par
- exemple d'en faire une analyse visuelle plus poussée qu'avec les
- cartes de champs disponibles par défaut dans le module MED
-* Export des données sous forme de tableau numpy, par exemple pour
- permettre un travail algorithmique sur les valeurs des champs.
-
-Spécifications techniques
-=========================
-
-Il s'agit d'exprimer ici les contraintes techniques applicables à la
-conception et au développement du nouveau module MED.
-
-Implantation technique du module
---------------------------------
-
-Il est convenu que le module MED existant dans la plate-forme SALOME
-incarne le module de manipulation de champ. Dans la pratique, il
-s'agit d'identifier clairement les parties à conserver, d'une part,
-puis les parties à re-écrire, d'autre part. On peut partir sur les
-hypothèses techniques suivantes:
-
-* Le noyau du module en charge des opérations de manipulation de
- champs proprement dites est construit sur la base des paquets
- logiciels MEDCoupling (lui-même basé sur le INTERP_KERNEL) et
- MEDLoader.
-* L'interface graphique du module MED est complétement re-écrite et
- remplacée par une interface adaptée spécialement à la manipulation
- des champs et la gestion des données associées
-* Le contrôle visuel pourra être déclenché dans les visualisateurs
- SALOME (servis par les modules VISU et/ou PARAVIZ);
-* Le module n'assure pas la persistence au sens SALOME du terme,
- c'est-à-dire qu'il ne permet pas la sauvegarde du travail dans une
- étude au format hdf, ni le dump sous la forme de script python
- SALOME.
-* Par contre, il fournit des fonctions de sauvegarde du travail sous
- forme de fichiers med, l'export vers les modules VISU et PARAVIZ, ou
- même la sauvegarde de l'historique de l'interface de commandes.
-
-L'implantation technique des développements est représentée sur la
-figure ci-dessous:
-
-.. image:: images/xmed-implantation.png
- :align: center
-
-Le schéma représente les packages logiciels qui composent le module
-MED (cf. |REF_CEA_VBE_MEDMEM|_):
-
-* La partie MEDMEM, représentées en blanc. Cette partie est conservée
- pour compatibilité ascendante au niveau des applications métier qui
- ont fait le choix historique de s'appuyer sur MEDMEM. Cette partie
- du module MED aura tendance à disparaitre dans le futur au bénéfice
- de MEDCoupling et MEDLoader.
-* La partie MEDCoupling, représentée en orange et qui founrnit le
- modèle MED mémoire de référence (composé de maillage et de champs)
- et l'interface de programmation pour manipuler le modèle. Le paquet
- MEDLoader est une extention dédiée à la persistence au format med
- fichier (lecture et écriture de champs et de maillage dans des
- fichiers med).
-* La partie à développer pour la manipulation de champ, représentée en
- bleu.
-
-.. note:: MEDCoupling peut être vu comme une structure de donnée
- particulièrement adaptée à la manipulation des gros volumes de
- données, en particulier par l'exploitation des possibilités de
- parallélisation et la réduction de la tailles des structures de
- données. En contrepartie, elle peut présenter un périmètre
- fonctionnel moins large que MEDMEM. Pour cette raison, MEDMEM avait
- été choisi comme socle de développement du prototype en 2010:
-
- * MEDCoupling ne permet pas de gérer des maillages composés de
- plusieurs type de mailles et il est exclus de le faire évoluer
- dans ce sens (c'est un choix fait pour les objectifs de
- performances évoqués plus haut);
- * MEDCoupling ne permet pas de gérer les supports qui expriment les
- champs aux noeuds par élément ni aux points de gauss. Cette
- seconde limitation a disparu en 2011.
-
- Aujourd'hui, on fait clairement le choix de MEDCoupling pour sa
- qualité et sa robustesse, dans l'objectif d'une meilleure
- maintenance à long terme. Par ailleurs, les différences
- fonctionnelles avec MEDMEM, si elles existaient encore en 2012 pour
- les besoins de la manipulation de champs, pourront être résorbées
- dans un futur proche.
-
-
+++ /dev/null
-.. meta::
- :description: introduction guide for users of the MEDMEM library
- :keywords: mesh, field, med, MEDCoupling, MEDLoader
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-MEDMEM library: Starter guide for users
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-This document illustrates how to start with the programming interface
-of the MEDMEM library. The users is someone who intends to create a
-data processing script involving meshes and fields.
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
- :depth: 2
-
-General overview
-================
-
-Definition of the MEDMEM library
---------------------------------
-
-The MEDMEM library is designed to manipulate meshes and fields that
-conform to the MED data model. This library can be used in C++
-programs as in python scripts for data processing on meshes and
-fields. The library contains the data structure to describe meshes and
-fields as C++ objects (MEDCoupling package). It provides a set of
-functions to manage the persistency toward the med file format
-(MEDLoader package), and to process the data througt interpolation and
-localization algorithms (INTERP_KERNEL and REMAPPER packages), for
-example to perform field projections from a mesh to another.
-
-Installation of the MEDMEM library
-----------------------------------
-
-The MEDMEM library is part of the SALOME MED module and then is
-installed together with this module by the installation process of
-SALOME. Nevertheless, it is possible for low-weight deployment to
-install only the MEDMEM library from the source files embedded in the
-SALOME MED module. Keep in mind that the MEDMEM library is designed to
-be a self-consistent library with very few third party softwares (only
-med-file, glibc and mpi typically). In particular, it is strictly
-independant from the SALOME framework even if it distributed with
-SALOME for convenience reasons.
-
-Components of the MEDMEM library
---------------------------------
-
-The MEDMEM library consists in a small set of atomic libraries files,
-in particular:
-
-* :tt:`medcoupling`: this library provides the data structures (C++
- classes) to describe meshes and fields.
-* :tt:`medloader`: this library provides I/O functions to the MED file
- format
-* :tt:`interpkernel`: this library provides the mathematical
- structures and algorithms required med data processing, in
- particular interpolation and localization.
-* :tt:`medcouplingremapper`: this library provides the functions for
- fields projections and interpolation.
-
-The figure below represents the layer structure of the packages of the
-library:
-
-.. image:: images/medlayers_70pc.png
- :align: center
-
-What we call MEDMEM library in this document is represented by the
-orange packages on this diagram. The white packages reprensent the old
-deprecated MEDMEM library. The blue packages represent the aditionnal
-components for field manipulation througth the user interface (TUI and
-GUI).
-
-The MEDMEM library comes also with this set of atomic libraries for
-advanced users/programmers:
-
-* :tt:`medcouplingcorba`: this library is designed for cross process
- exchange of medcoupling objects.
-* :tt:`medpartitioner`: this library provides functions to split a MED
- domain in several part in the perspective of parallel computing
-
-All these atomic C++ libraries are wrapped into a set of python
-modules (using the swig binding technology) so that all the data
-processing can be realized by scripting.
-
-.. warning:: It could happen that some parts of the C++ libraries are
- not wrapped into python modules. This coverture will be
- extend on demand and if the integrity of the concepts is
- preserved.
-
-Main concepts of the MEDMEM library
-===================================
-
-.. warning:: TODO avec Antony. Présenter les structure de données de
- MEDCoupling principalement. Describe the MEDMEM data
- model, the typical content of a med file, the types of
- cell that compose the meshes, the types of spatial
- discretization of fields, ...
-
-Basic usages of the MEDMEM library
-==================================
-
-This section illustrates the usage of main features of the MEDMEM
-library using python examples. The usage of python is just to have a
-light syntax that makes more easy the first understanding.
-
-.. note:: All code examples here after are parts of the tutorial use
- cases located in the folder :tt:`src/MEDOP/tut` in the MED
- source directory. These use cases are all working executable
- programs and they can be used to initiate your own script.
-
-Preparing the shell environment
--------------------------------
-
-We make the hypothesis here that the MEDMEM library is installed using
-the SALOME procedure and then is located in the MED module
-installation directory. In addition to the MED library, the third
-party softwares required for executing the examples are: python, hdf5
-and med-fichier. Then, you should prepare your shell environment
-with a set of instructions that looks like::
-
- #------ python ------
- export PYTHONHOME=</path/to/python>
- export PYTHONSTARTUP=${PYTHONHOME}/pythonrc.py
- export PYTHON_INCLUDE=${PYTHONHOME}/include/python2.6
- export PATH=${PYTHONHOME}/bin:${PATH}
- export LD_LIBRARY_PATH=${PYTHONHOME}/lib:${LD_LIBRARY_PATH}
-
- #------ hdf5 ------
- HDF5HOME=</path/to/hdf5>
- export PATH=${HDF5HOME}/bin:$PATH
- export LD_LIBRARY_PATH=${HDF5HOME}/lib:${LD_LIBRARY_PATH}
- export HDF5_DISABLE_VERSION_CHECK=1
-
- #------ med ------
- MED2HOME=</path/to/med>
- export PATH=${MED2HOME}/bin:${PATH}
- export LD_LIBRARY_PATH=${MED2HOME}/lib:${LD_LIBRARY_PATH}
-
- #------ medmem ---
- MED_ROOT_DIR=<path/to/salome_med_module>
- export LD_LIBRARY_PATH=${MED_ROOT_DIR}/lib/salome:${LD_LIBRARY_PATH}
- PYTHONPATH=${MED_ROOT_DIR}/lib/python2.6/site-packages/salome:${PYTHONPATH}
- PYTHONPATH=${MED_ROOT_DIR}/bin/salome:${PYTHONPATH}
- PYTHONPATH=${MED_ROOT_DIR}/lib/salome:${PYTHONPATH}
- export PYTHONPATH
-
-Example 01: Explore a med file to get information concerning meshes and fields
-------------------------------------------------------------------------------
-
-:objectives: This example illustrates how to get information
- concerning meshes and fields from a med file, using the
- MEDLoader library.
-
-The loading of meshes and fields from a med file to a MEDCoupling data
-structure requires first the knowledge of metadata associated to these
-meshes and fields. You have to know the names of the meshes, so that
-you can specify the one you want to load, and then the names of the
-fields associated to one given mesh, the space discretizations used
-for each field, and the iterations available.
-
-The MEDLoader library can read these metadata without loading the
-physical data that compose the meshes and fields. This feature ensures
-the performance of the exploration process, in particular in the case
-of big meshes.
-
-This first instruction looks for meshes embedded in the med file
-(located by :tt:`filepath`) and returns the list of mesh names:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-.. WARNING: Note that the file path for the include directive must be
- relative to this rst source file (i.e. as organized in the MED
- source directory, and nevertheless the build procedure is realized
- elsewhere.
-
-Then, you may select one of these names (or iterate on all names of
-the list) and read the list of fields defined on this mesh:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-A field name could identify several MEDCoupling fields, that differ by
-their spatial discretization on the mesh (values on cells, values on
-nodes, ...). This spatial discretization is specified by the
-TypeOfField that is an integer value in this list:
-
-* :tt:`0 = ON_CELLS` (physical values defined by cell)
-* :tt:`1 = ON_NODES` (physical values defined on nodes)
-* :tt:`2 = ON_GAUSS_PT` (physical values defined on Gauss points)
-* :tt:`3 = ON_GAUSS_NE`
-
-.. note:: This constant variables are defined by the MEDLoader module
- (:tt:`from MEDLoader import ON_NODES`).
-
-As a consequence, before loading the physical values of a field, we
-have to determine the types of spatial discretization that come with
-this field name and to choose one of this types. The instruction below
-read all the spatial discretization types available for the field of
-name :tt:`fieldName` defined on the mesh of name :tt:`meshName`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Once you have selected the spatial discretization of interest (called
-:tt:`typeOfDiscretization` in the code below, that corresponds to an
-item of the list :tt:`listOfTypes`), you can extract the list of time
-iterations available for the identified field:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T4A
- :end-before: # _T4B
-
-The iterations can be weither a list of time steps for which the field
-is defined (a timeseries) or a list of frequency steps (spectral
-analysis). In any case, an iteration item consists in a couple of
-integers, the first defining the main iteration step and the second an
-iteration order in this step, that can be consider as a sub-iteration
-of the step. In most of cases, the iteration order is set to :tt:`-1`
-(no sub-iterations).
-
-The field values can now be read for one particular time step (or
-spectrum tic), defined by the pair (iteration number, iteration
-order). This is illustrated by the example here after.
-
-Example 02: Load a mesh and a field from a med file
----------------------------------------------------
-
-:objectives: This illustrates how to load the physical data of a
- specified mesh and a specified field.
-
-The metadata read from a med file are required to identify the list of
-meshes and fields in the med file. We assume in this example that the
-mesh and field to load are identified, i.e. we know the name of the
-mesh to load (:tt:`meshName`) and the characteristic properties of the
-field to load (:tt:`fieldName`, :tt:`typeOfDiscretization` and
-:tt:`iteration`). For example, the instruction below load the mesh of
-name :tt:`meshName`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T5A
- :end-before: # _T5B
-
-and the instruction below load the field with name :tt:`fieldName`
-defined on this mesh at a particular iteration step characterized by
-the couple :tt:`(iterationNumber,iterationOrder)`:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T6A
- :end-before: # _T6B
-
-The variables :tt:`mesh` and :tt:`field` in this code example are instances of
-the MEDCoupling classes describing the meshes and fields.
-
-Note that the read functions required the parameter
-:tt:`dimrestriction`. This parameter discreminates the mesh dimensions you
-are interested to relatively to the maximal dimension of cells
-contained in the mesh (then its value could be 0, -1, -2 or -3
-depending on the max dimension of the mesh). A value of
-:tt:`dimrestriction=0` means "no restriction".
-
-Example 03: Manage the MEDCoupling data load from a med file
-------------------------------------------------------------
-
-:objectives: Some suggestions for the MEDCoupling objects management,
- in a programming context.
-
-In a real programming case, it could be relevant to explore first the
-med file to load all metadata concerning the whole set of meshes and
-associated fields, and then to load the physical data only once when
-required by the program.
-
-Such a programming scenario required that you keep all metadata in
-data structures created in memory, so that you can manage the
-collection of meshes and fields. Nevertheless, the MEDMEM library
-does not provide such data structures.
-
-We suggest to work with a simple list concept to store the metadata
-for each mesh entry and each field entry. Note that a mesh entry is
-characterized by the mesh name only, while a field entry is
-charaterized by the following attributes:
-
-* :tt:`fieldName`: the name of the field
-* :tt:`meshName`: the name of the mesh that supports the field
-* :tt:`typeOfDiscretization`: the type of spatial discretization
-* :tt:`iteration`: a couple of integers :tt:`(iter,order)` that
- characterizes the step in a serie (timeseries or spectrum).
-
-By default, we suggest to work with a simple map concept (dictionnary in a
-python context, map in a C++ context) to register the meshes and
-fields loaded from the med file for each metadata entry.
-
-Then, depending on the processing algorithm you intend to implement,
-you may dispatch the data in a tree structure that fit your specific
-case, for performance reasons. For example, the following code
-illustrates how to dispatch the metadata in a tree data structure
-where leaves are the physical data (field objects). We first have to
-define a tree structure (basic definition in htis simple case, but it
-works fine):
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-Then, we can scan the med structure and dispatch the metadata in the
-tree structure:
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-Finally (and afterwards), we can display on standard output the
-metadata registered in the tree structure:
-
-.. include:: ../../tut/medloader/manage.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Example 04: Simple arithmetic operations with fields
-----------------------------------------------------
-
-:objectives: This example illustrates how to load field iterations
- from a med file containing a field timeseries and shows
- how to use these iterations in simple arithmetic
- operations.
-
-We consider a med file :tt:`timeseries.med`, containing one single
-mesh named :tt:`Grid_80x80` that supports a field with values defined
-on nodes (:tt:`typeOfDiscretization=ON_NODES`) given for ten
-iterations.
-
-This first code block identifies the mesh and the field to consider in
-this example:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-The following instructions load the field, make a scaling on the
-physical values (multiply by 3) and then save the result in an output
-med file named :tt:`scaling.med`:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-Note the usage of the method :tt:`applyFunc` that takes in argument a
-string expression that defined the mathematical function to apply on
-the values of the fields. In this expression, the field is symbolized
-by the letter :tt:`f`.
-
-The following set of instructions makes the addition of iteration
-number 3 with iteration number 4 of the field. Note that this
-operation required first to load the mesh:
-
-.. include:: ../../tut/addfields/operations.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Exemple 05: Compare fields load from different files
-----------------------------------------------------
-
-:objectives: Illustrates the usage of the function
- changeUnderlyingMesh
-
-Exemple 06: Create a field from scratch on a spatial domain
------------------------------------------------------------
-
-:objectives: Illustrates the applyFunc method of fields
-
-Exemple 07: Manipulate structured mesh
---------------------------------------
-
-:objectives: Illustrates the basic usage of the advanced interface of
- MEDLoader.
-
-The MEDLoader frontal interface let you load unstructured meshes:
-
-.. include:: ../../tut/medloader/tutorial.py
- :literal:
- :start-after: # _T5A
- :end-before: # _T5B
-
-That is to say that even if the mesh is a structured mesh (a grid mesh
-for example), then you will get a MEDCoupling unstructured mesh
-object.
-
-To manipulate structured mesh objects, you have to use the MEDLoader
-backend interface named :tt:`MEDFileMesh`, or its derivative
-:tt:`MEDFileUMesh` for unstructured meshes, and :tt:`MEDFileCMesh` for
-structured meshes (CMesh for Cartesian Mesh). The code below
-illustrates how to load a mesh using the :tt:`MEDFileMesh` interface,
-and to know if it is a structured mesh:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-This second example can be used in the case where you know in advance
-that it is a structured mesh:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T2A
- :end-before: # _T2B
-
-In any cases, you can also save the mesh in another file with the
-methode :tt:`write` of the :tt:`MEDFileMesh` object:
-
-.. include:: ../../tut/medloader/cmesh.py
- :literal:
- :start-after: # _T3A
- :end-before: # _T3B
-
-Exemple 08: Make a projection of a field
-----------------------------------------
-
-:objectives: Make the projection of a field from a source mesh to a
- target meshe. The source mesh and the target mesh are
- two different mesh of the same geometry.
-
-The input data of this use case are:
-
-* a source mesh, and a field defined on this source mesh (left side of
- the figure below)
-* a target mesh, on which we want to project the field (right side of
- the figure below)
-
-.. note:: The two meshes are displayed side by side on the figure for
- convenience reason, but in the real use case they stand at
- the same location in 3D space (they describe the same
- geometry).
-
-.. image:: images/medop_projection_inputs.png
- :align: center
-
-The expected result is a field defined on the target mesh and which
-corresponds to a physical data equivalent to the source field,
-i.e. with conservation of some physical properties. This operation
-requires the usage of interpolation algorithms provided by the
-:tt:`medcouplingremapper` library:
-
-.. include:: ../../tut/projection/demomed/demo_loadsource.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-Some comments on this code:
-
-* The physical property to be preserved by this interpolation is
- specified using the keyword :tt:`ConservativeVolumic`
-* The parameter :tt:`P0P0` given at the preparation step of the
- remapper specifies that the interpolation is done from CELLS (P0) to
- CELLS (P0).
-* The interpolation, strictly speaking, is performed by the
- instruction :tt:`ftarget =
- remap.transferField(fsource,defaultValue)`
-* In this instruction, the :tt:`defaultValue` is used to set the target value
- in the case where there is no cell in the source mesh that overlap
- the target mesh (for example when the source mesh correspond to a
- geometrical sub-part of the target mesh).
-
-When executing the :tt:`remapper`, the result is a new field defined on
-the target mesh, as illustrated on the figure below:
-
-.. image:: images/medop_projection_result.png
- :align: center
-
-Exemple 09: Make a partition of a mesh using a field
-----------------------------------------------------
-
-:objective: This illustrates how to make a mesh partition using the
- value of a field defined on this mesh.
-
-The input data is a MEDCoupling scalar field (:tt:`field`) defined on
-a 3D mesh, and we want to use this field as a criterium to make a
-partition of the mesh, for example by creating the mesh surface that
-delimits the volumes where the field value is greater that a limit L
-(and conversely the volumes where the field value is lower).
-
-.. image:: images/partition_mesh.png
- :align: center
-
-The code below shows the simplest way to extract the cells where
-:tt:`field>L` and to create the skin mesh:
-
-.. include:: ../../tut/medcoupling/partition.py
- :literal:
- :start-after: # _T1A
- :end-before: # _T1B
-
-At the end, the variable :tt:`skin` is a 2D mesh that can be saved in
-a med file using the MEDLoader:
-
-.. image:: images/partition_skin.png
- :align: center
-
-Advanced usages of the MEDMEM library
-=====================================
-
-This section could explain how to process the physical data
-(dataArray) and to manipulate the advanced concepts of the MEDMEM
-library.
-
-.. Exemple 01: Create a field from an image
-.. ----------------------------------------
-
+++ /dev/null
-.. meta::
- :keywords: mesh, field, manipulation, user guide
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-MED module: User guide for graphical interface
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-This document is a quick guide for Graphical User Interface of MED module. It
-shows how to use this module on the basis of a few reference examples, built
-from use cases identified during requirement analysis stage.
-
-.. warning:: This document is self-contained, but it is strongly advised to
- read :doc:`the specification document<medop-specifications>` (in
- french), at least to clarify concepts and terminology.
-
-.. contents:: Contents
- :local:
- :backlinks: none
-
-.. warning:: Screenshots are not up-to-date. They were extracted from SALOME
- 6 with data visualization achieved using VISU module. In SALOME
- 7, VISU module has been replaced by PARAVIS module. The
- look-and-feel may thus be slightly different.
-
-General presentation of MED module
-==================================
-
-The overall ergonomics of MED module for field manipulation is inspired by
-softwares such as octave or scilab. It combines a graphical interface (GUI) to
-select and prepare data, with a textual interface (the python console, TUI)
-for actual work on data.
-
-This module provides two user environments that are marked by the red and
-green rectangles on the screenshot below:
-
-* **The data space** (*dataspace*), in which user defines the MED data sources
- (*datasource*), that is to say the med files from which meshes and fields
- are read. This data space allows for the exploration of meshes and fields
- provided by the different data sources.
-* **The workspace** (*workspace*), in which user may drop fields selected in
- the source space, and then use them for example to produce new fields using
- the operations on fields provided by the TUI.
-
-.. image:: images/xmed-gui-withframe.png
- :align: center
-
-A typical use of field manipulation functions is:
-
-1. Load a med file in the data space and explore its contents: meshes and
- fields defined on these meshes, defined for one or several time steps.
-2. Select (using GUI) fields to be manipulated in workspace ; it is possible
- to introduce restrictions on time steps, components or groups of cells.
-3. Create new fields executing algebraic operations (+,-,*,/) on fields,
- applying simple mathematical functions (pow, sqrt, abs), or initializing
- them "from scratch" on a support mesh.
-4. Visually control produced fields, using PARAVIS module in SALOME,
- automatically controlled from user interface.
-5. Save (parts of) produced fields to a med file.
-
-
-Quick tour on functions available in MED module
-===============================================
-
-This section presents some use examples of MED module like a "storyboard",
-illustrating the functions proposed by the module.
-
-.. warning:: This section is under construction. Please consider that its
- contents and organization are still incomplete and may change
- until this warning is removed.
-
-Example 1: Explore data sources
--------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * add a data source
- * "Extends field series" and "Visualize" functions
-
-.. |ICO_DATASOURCE_ADD| image:: images/ico_datasource_add.png
- :height: 16px
-
-.. |ICO_XMED| image:: images/ico_xmed.png
- :height: 16px
-
-.. |ICO_DATASOURCE_EXPAND| image:: images/ico_datasource_expandfield.png
- :height: 16px
-
-.. |ICO_DATASOURCE_VIEW| image:: images/ico_datasource_view.png
- :height: 16px
-
-At startup the field manipulation module, identified by icon |ICO_XMED|, shows
-an empty interface:
-
-.. image:: images/xmed-gui-start.png
- :align: center
- :width: 800px
-
-The first step consists in adding one or several med data sources in
-"dataspace". For this, user clicks on icon "Add datasource"
-|ICO_DATASOURCE_ADD| to select a med file:
-
-.. image:: images/xmed-gui-datasource-selectfile.png
- :align: center
- :width: 800px
-
-This operation adds a new entry (datasource) in data space. The contents can
-be explored using the data tree. The figure below (left image) shows the
-result of loading the file ``timeseries.med`` containing a mesh named
-``Grid_80x80`` on which a field on nodes named ``Pulse`` is defined. By
-default, the field composition (in terms of time steps and components) is not
-displayed to avoid visual congestion of data tree. User must explicitly ask
-for visualization using the command "Expand field timeseries"
-|ICO_DATASOURCE_EXPAND| available in the field contextual menu. The result is
-displayed on center image. The list of field ``Pulse`` iterations can be advised.
-
-.. |IMG_DATASOURCE_EXPLORE| image:: images/xmed-gui-datasource-explore-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_MENUCON| image:: images/xmed-gui-datasource-menucontextuel-zoom.png
- :height: 340px
-.. |IMG_DATASOURCE_EXPANDF| image:: images/xmed-gui-datasource-expand-zoom.png
- :height: 340px
-
-+--------------------------+--------------------------+--------------------------+
-| |IMG_DATASOURCE_EXPLORE| | |IMG_DATASOURCE_MENUCON| | |IMG_DATASOURCE_EXPANDF| |
-+--------------------------+--------------------------+--------------------------+
-
-.. note:: Strictly speaking, the *field* concept in MED model corresponds to
- a given iteration. A set of iterations is identified by the term
- *field time series*. If there is no ambiguity, the field name will
- refer to both the field itself or the time series it belongs to.
-
-Finally, it is possible from dataspace to visualize the field general shape
-using a scalar map displayed in SALOME viewer. For this, user selects the time step to
-display then uses the command "Visualize" |ICO_DATASOURCE_VIEW| available in
-the associated contextual menu:
-
-.. image:: images/xmed-gui-datasource-visualize-zoom.png
- :align: center
- :width: 800px
-
-.. note:: This graphical representation aims at providing a quick visual
- control. Scalar maps are displayed using the PARAVIS module.
-
-Example 2: Combine fields from different sources
-------------------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * function "Use in workspace"
- * function "Save"
-
-.. |ICO_DATASOURCE_USE| image:: images/ico_datasource_use.png
- :height: 16px
-.. |ICO_WORKSPACE_SAVE| image:: images/ico_workspace_save.png
- :height: 16px
-
-The objective is to access data contained in several med files, then to
-combine them in the same output file.
-
-User starts by adding med data sources in dataspace. In the example below,
-dataspace contains two sources names ``parametric_01.med`` and
-``smallmesh_varfiled.med``. The first one contains the mesh ``Grid_80x80_01``
-on which the field ``StiffExp_01`` is defined. The second source contains the
-mesh ``My2DMesh`` on which the two fields ``testfield1`` are ``testfield2``
-are defined:
-
-.. image:: images/xmed-userguide-example2-datasource.png
- :align: center
- :width: 800px
-
-In this example, ``StiffExp_01`` and ``testfield2`` are combined then saved to
-``result.med`` file. The procedure consists in importing the two fields in
-workspace, then to save the workspace. For this user selects the fields and
-uses the command "Use in workspace" |ICO_DATASOURCE_USE| available in the
-contextual menu. Both selected fields appear in the workspace tree:
-
-.. image:: images/xmed-userguide-example2-workspace.png
- :align: center
- :width: 800px
-
-Workspace is saved using the command "Save workspace" |ICO_WORKSPACE_SAVE|
-available in the module toolbar. A dialog window lets user set the save
-file name:
-
-.. image:: images/xmed-userguide-example2-workspace-save.png
- :align: center
- :width: 800px
-
-The file ``result.med`` can then be reloaded in MED module (or PARAVIS module)
-to check the presence of saved fields.
-
-.. BUG: plantage à l'utilsation dans XMED d'un fichier rechargé
-.. (invalid mesh on field)
-
-.. _xmed.userguide.exemple3:
-
-Example 3: Apply a formula on fields
-------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * execute mathematical operations in TUI console
- * function "put" to refer to a work field in the list of persisting fields.
- * function "Visualize" from TUI.
-
-The most common usage of field manipulation module is to execute mathematical
-operations on fields or on their components.
-
-Assume data sources are already defined in dataspace (in the following example
-a temporal series named ``Pulse`` contains 10 time steps defined on a mesh
-named ``Grid_80x80``, all read from ``timeseries.med`` data source).
-
-As previously seen, a field can be manipulated in workspace after selecting
-the field and applying the command "Use in
-workspace" |ICO_DATASOURCE_USE| from contextual menu. Here only one file is
-selected (two in the previous example) and the command then opens a dialog
-window to select data to work on and the way they will be manipulated:
-
-.. image:: images/xmed-gui-datasource-useinworkspace-alias.png
- :align: center
- :width: 800px
-
-.. note:: In the current state of development, the interface only propose to
- define the name of a variable representing the field in TUI. In
- a next version, user will have the possibility to specify the field
- component(s) to be used and a group of cells to introduce
- a geometrical restriction. Conversely it will be possible to select
- a complete time series to apply global operations on all time steps.
-
-After validation, the field if put in workspace tree and a variable
-``<alias>`` is automatically created in the TUI to designate the field. In
-this example, ``<alias>`` is ``f3``, as set by user to recall that variable
-corresponds to the third time step:
-
-.. image:: images/xmed-gui-workspace.png
- :align: center
- :width: 800px
-
-Field manipulation can start. In the example below, use creates the field``r``
-as the result of an affine transformation of field ``f3`` (multiplication of
-field by a scale factor 2.7 then addition of offset 5.2)::
-
- >>> r=2.7*f3+5.2
-
-Other operations can be applied, as detailed in module specifications
-(cf. :ref:`Spécification des opérations<xmed-specifications>`):
-
- >>> r=f3/1000 # the values of r are the ones of f3 reduced by a factor 1000
- >>> r=1/f3 # the values of r are the inverted values of f3
- >>> r=f3*f3 # the values of r are the squared values of f3
- >>> r=pow(f3,2) # same result
- >>> r=abs(f3) # absolute value of field f3
- >>> ...
-
-The two operands can be fields. If ``f4`` is the fourth time step of field
-``Pulse``, then algebraic combinations of fields can be computed::
-
- >>> r=f3+f4
- >>> r=f3-f4
- >>> r=f3/f4
- >>> r=f3*f4
-
-Scalar variables can be used if needed::
-
- >>> r=4*f3-f4/1000
- >>> ...
-
-In theses examples, the variable ``r`` corresponds to a work field containing
-the operation result. By default the field is nor referenced in workspace
-tree. If user wants to add it, for example to make it considered when saving,
-then the following command is used::
-
- >>> put(r)
-
-The function ``put`` aims at tagging the field as persisting, the to store it
-in the workspace tree to make it visible and selectable. Among all fields that
-could be created in console during the work session, all do not need to be
-saved. Some may only be temporary variables used in the construction of final
-fields. That is why only fields in workspace tree are saved when saving the
-workspace.
-
-Variables defined in console have other uses. First they allow for printing
-information relative to the manipulated field. For this one enters the
-variable name then validates::
-
- >>> f3
- field name (id) = Pulse (3)
- mesh name (id) = Grid_80x80 (0)
- discretization = ON_NODES
- (iter, order) = (3,-1)
- data source = file:///home/gboulant/development/projets/salome/MEDOP/XMED/xmed/resources/datafiles/timeseries.med
-
-Second, variables can be used as command arguments (the list of commands
-available in TUI is described in section :ref:`Documentation of textual
-interface<xmed.userguide.tui>`). For example the function ``view`` displays
-the field scalar map in the viewer::
-
- >>> view(f3)
-
-Results in:
-
-.. image:: images/xmed-gui-workspace-view.png
- :align: center
- :width: 800px
-
-.. note:: It is easy to compare two time steps of a field, computing the
- difference ``f3-f4``, then producing a scalar map preview using the
- function ``view``::
-
- >>> view(f3-f4)
-
-Finally the field data can be displayed using the command``print``::
-
- >>> print f3
- Data content :
- Tuple #0 : -0.6
- Tuple #1 : -0.1
- Tuple #2 : 0.4
- Tuple #3 : -0.1
- Tuple #4 : 0.4
- ...
- Tuple #6556 : 3.5
- Tuple #6557 : 3.3
- Tuple #6558 : 1.5
- Tuple #6559 : 0.3
- Tuple #6560 : 0.2
-
-It is important to note that operations between fields can only be applied if
-fields are defined on the same mesh. It corresponds to a specification of MED
-model that forbids operations between fields defined on meshes geometrically
-different. Technically it means that the conceptual objects *fields* must share
-the same conceptual object *mesh*.
-
-If user do want to use fields defined on different meshes, for example to
-manipulate the field values at the interface of two meshes sharing a 2D
-geometrical area, it is necessary first to make all fields be defined on the
-same surface mesh using a projection operation.
-
-.. note:: Such projection operations are available in the MEDCoupling library.
-
-Another classical need is using fields defined on meshes geometrically
-identical, but technically different for example when they are loaded from
-different med files. For such a case, the MEDCoupling library proposes
-a function "Change support mesh" ; its use in field manipulation module is
-illustrated in :ref:`example 4<xmed.userguide.exemple4>` described hereafter.
-
-.. _xmed.userguide.exemple4:
-
-Example 4: Compare fields derived from different sources
---------------------------------------------------------
-
-.. note:: This example illustrates the following function:
-
- * Change the underlying (support) mesh
-
-Assume here that fields have been defined on same mesh, geometrically
-speaking, but saved in different med files. This occurs for example for
-a parametric study in which several computations are achieved with variants on
-some parameters of the simulated model, each computation producing a med file.
-
-Let ``parametric_01.med`` and ``parametric_02.med`` be two med files
-containing the fields to compare, for example computing the difference of
-their values and visualizing the result.
-
-After loading data sources user sees two meshes, this time from the technical
-point of view, that is to say fields are associated to different conceptual
-mesh objects, while geometrically identical.
-
-However field manipulation functions do not allow operations on fields lying
-on different support meshes (see remark at the end of :ref:`example
-3<xmed.userguide.exemple3>`).
-
-To circumvent this issue, the module offers the function "Change underlying
-mesh" to replace a field mesh support by another, provided that the two meshes
-are geometrically identical, that is to say nodes have the same spatial
-coordinates.
-
-.. |ICO_DATASOURCE_CHG| image:: images/ico_datasource_changeUnderlyingMesh.png
- :height: 16px
-
-In the proposed example, user selects the first time step of field
-``StiffExp_01`` in data source ``parametric_01.med``, and imports it in
-workspace using the command "Use in workspace" |ICO_DATASOURCE_USE|. User then
-selects the first time step of field ``StiffExp_02`` in data source
-``parametric_02.med``, but imports it in workspace using the command "Change
-underlying mesh" |ICO_DATASOURCE_CHG|. The following dialog window appears to
-let user select the new support mesh in dataspace tree:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh.png
- :align: center
-
-In this example, the support mesh ``Grid_80x80_01`` of field ``StiffExp_01``
-to compare with is selected. After validation the workspace tree contains the
-field ``StiffExp_02`` defined on mesh ``Grid_80x80_01``:
-
-.. image:: images/xmed-gui-datasource-changeUnderlyingMesh_wsview.png
- :align: center
-
-.. note:: The function "Change underlying mesh" does not modify the field
- selected in dataspace (basic running principle of dataspace), but
- creates a field copy in workspace to then change support mesh. This
- explains the default name for field ``dup(<name of selected
- field>)`` (dup stands for "duplicate").
-
-All we have to do now is to associate a variable to this field, in order to
-manipulate it in TUI. This can be done using the command "Use in console"
-available in workspace contextual menu.
-
-Finally, if ``f1`` is a field from datasource ``parametric_01.med`` and ``f2``
-is a field from datasource
-``parametric_02.med`` according to the above procedure, then comparison values
-can be achieved as explained in :ref:`example 3<xmed.userguide.exemple3>`::
-
- >>> r=f1-f2
- >>> view(r)
-
-.. note:: As a general remark concerning this example, one may note:
-
- * the geometrical equality of two meshes is constrained to a numerical
- error that can be technically set, but not through the module interface.
- This tolerance is empirically set to a standard value regarding to
- success of most of the use cases. The usefulness of setting this value in
- the interface could be later investigated.
-
- * User must explicitly ask for changing a field support mesh, in order to
- compare fields coming from different data sources. This choice has been
- made to keep trace of modifications made on data (no modification is made
- without user knowing, even to improve ergonomics).
-
-
-Example 5: Create a field on a spatial domain
----------------------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * initialize with function of spatial position
- * initialize on a group of cells
-
-The geometrical domain on which the field to create is defined is here given
-by cell group data. This use case is provided for producing initial load
-conditions of a structure, for example defining a field on a geometry surface
-identified by a group of cells.
-
-.. warning:: DEVELOPMENT IN PROGRESS
-
-Example 6: Extract a field part
--------------------------------
-
-.. note:: This example illustrates the following functions:
-
- * extract a component (or a subset of components)
- * extract a geometrical domain (values on a group of cells)
- * extract one or several time steps
-
-.. warning:: DEVELOPMENT IN PROGRESS
-
- Here the restriction functions that allow to get some components only, have
- to be illustrated. The principle is creating a new field that is
- a restriction of input field to a list of given components (use the
- function __call__ of fieldproxy).
-
-For time step extraction, we can reduce to the case of example 2 with a single
-data source.
-
-Example 7: Create a field from a to[mp]ographic image
------------------------------------------------------
-
-.. note:: This example illustrates the following function:
-
- * Create a field without data source (neither mesh nor field), from an
- image file
-
-In tomography or topography studies, measurement devices produce images that
-represent a physical quantity using gray levels on a given cutting plane. The
-following image represents for example a internal view of human body obtained
-by MRI:
-
-.. image:: images/xmed-irm.png
- :align: center
- :width: 600px
-
-This image is a subset of pixels organized on a Cartesian grid. It can thus be
-represented as a scalar field whose values are defined on cells of a mesh
-having the same dimension as the image (number of pixels):
-
-.. image:: images/xmed-irm-field.png
- :align: center
- :width: 600px
-
-The field manipulation module provides a tool named ``image2med.py`` to
-convert a file image to a med file containing the image representation as
-a scalar field (only the gray level is kept)::
-
- $ <xmed_root_dir>/bin/salome/xmed/image2med.py -i myimage.png -m myfield.med
-
-.. |ICO_IMAGESOURCE| image:: images/ico_imagesource.png
- :height: 16px
-
-This conversion operation can be automatically achieved using the command "Add
-Image Source" |ICO_IMAGESOURCE| available in GUI toolbar. This command opens
-the following window to let user select a file image:
-
-.. image:: images/medop_image2med_dialog.png
- :align: center
-
-The name of result med file is set by default (changing file extension to
-``*.med``) but can be modified. Finally user can ask for automatic load of
-this med file in data space. Fields can then be manipulated like presented in
-the standard use cases.
-
-For example, the image below depicts the result of the difference between two
-images, added to the reference image: if i1 and i2 are the fields created from
-these two images, then ``r = i1 + 5*(i2-i1)`` with 5 an arbitrary factor to
-amplify the region of interest (above the left eye):
-
-.. image:: images/xmed-irm-diff.png
- :align: center
- :width: 600px
-
-The example below is the result of loading a tomographic image courtesy of MAP
-project (Charles Toulemonde, EDF/R&D/MMC). The tomographic image:
-
-.. image:: images/champ_altitude_MAP.png
- :align: center
- :width: 600px
-
-The result of loading:
-
-.. image:: images/medop_image2med_tomographie.png
- :align: center
- :width: 800px
-
-Example 8: Continue analysis in PARAVIS
----------------------------------------
-
-.. note:: This example illustrates the following functio:
-
- * Export fields to PARAVIS module
-
-The solutions for field representation in MED module aims at proposing a quick
-visual control.
-
-For a detailed analysis of fields, user shall switch to PARAVIS. The field
-manipulation module has a function to facilitate this transition, with
-automatic load in PARAVIS and proposing a default visualization (scalar map).
-
-For this user selects in workspace the fields to export, then call the export
-function from contextual menu:
-
-.. image:: images/medop_exportparavis.png
- :align: center
-
-Selected fields are grouped in a single MED entry in PARAVIS, and the first
-field is depicted as a scalar map:
-
-.. image:: images/medop_exportparavis_result.png
- :align: center
- :width: 800px
-
-.. note:: The export function is a convenience function. The same operation
- can be manually achieved, first saving fields to a med file then
- loading the created file in PARAVIS module for visualization.
-
-.. _xmed.userguide.tui:
-
-Using the textual interface (TUI)
-=================================
-
-All operations driven through GUI can be done (more or less easily) using TUI.
-The field manipulation module can even be used exclusively in textual mode.
-For this run the command::
-
- $ <path/to/appli>/medop.sh
-
-This command opens a command console ``medop>``. A med file can be loaded and
-manipulated, for example to create fields from file data.
-
-Whatever textual or graphical mode is used, a typical workflow in console
-looks like the following instructions::
-
- >>> load("/path/to/mydata.med")
- >>> la
- id=0 name = testfield1
- id=1 name = testfield2
- >>> f1=get(0)
- >>> f2=get(1)
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- >>> r=f1+f2
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=testfield1+testfield2)
- >>> r.update(name="toto")
- >>> ls
- f1 (id=0, name=testfield1)
- f2 (id=1, name=testfield2)
- r (id=2, name=toto)
- >>> put(r)
- >>> save("result.med")
-
-The main commands are:
-
-* ``load``: load a med file in data base (useful in pure textual mode)::
-
- >>> load("/path/to/datafile.med")
-
-* ``la``: show the list of all fields loaded in data base ("list all")
-* ``get``: set a field in workspace from its identifier (useful in pure
- textual mode ; this operation can be done in GUI selecting a field from data
- space).::
-
- >>> f=get(fieldId)
-
-* ``ls``: show the list of fields available in workspace ("list")
-* ``put``: put a reference to a field in *management space*::
-
- >>> put(f)
-
-* ``save``: save to a med a file all fields referenced in management space::
-
- >>> save("/path/to/resultfile.med")
-
-.. note::
-
- * the ``load`` command only loads metadata describing meshes and fields
- (names, discretization types, list of time steps). Meshes and physical
- quantities on fields are loaded later (and automatically) as soon as an
- operation needs them. In all cases med data (mete-information and values)
- are physically stored in *data base* environment.
- * the ``get`` command defines a *field handler* in workspace, i.e.
- a variable that links to the physical field hosted in data base. Physical
- data never transit between environments but remain centralized in data
- base.
-
-The following TUI commands need to work in graphical environment:
-
-* ``visu``: display a field map for quick visual control (no parametrization
- is possible)
-
- >>> view(f)
-
-
-
-.. LocalWords: softwares
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2010
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Principes directeurs du développement
-=====================================
-
-En matière de développement:
-
-* On ne cherche pas d'emblée à s'inscrire dans la fabrication d'un
- module SALOME diffusable dans la version d'exploitation 2010 (SALOME
- 6). La raison est double: (i) on souhaite au moins pour 2010 ne pas
- devoir tenir compte des contraintes de temps SALOME et (ii) le
- produit envisagé fin 2010 est une maquette qui cherche à éprouver
- l'ergonomie générale d'utilisation et en aucun cas on ne peut
- garantir la réalisation d'un module SALOME compatible avec les
- exigences de mise en exploitation.
-* On ne cherche pas d'emblée à capturer tous les cas d'application,
- mais à concevoir un développement qui acceptera les extensions de
- périmètres dans des conditions raisonnables. Aussi, les
- fonctionnalités développées seront celles qui sont nécessaires à la
- réalisation des cas d'application de référence;
-
-En matière d'ergonomie:
-
-* L'interface utilisateur de référence (appelé espace de travail dans
- le volet de spécifications fonctionnelles) est l'interpréteur
- python. Les fonctionnalités doivent être pensées pour un usage
- adapté à une interface textuelle (TUI) de ce type.
-* La création d'une interface graphique (GUI) peut être envisagée en
- complément et comme un moyen de manipuler graphiquement les
- fonctionnalités développées pour l'interface textuelle et pour aider
- la préparation des variables dans l'interface python.
-* Le modèle d'un processus de manipulation de champs est:
-
- - Préparation du jeu de variables U, V, ... représentant les champs
- à manipuler. C'est à ce stade que l'on résoud la question de
- sélection des données (dans un champ publié dans l'arbre d'étude,
- par un module de calcul ou par chargement d'un fichier med)
- - Utilisation des variables avec une sémantique la plus proche
- possible du modèle conceptuel et des spécifications
- fonctionnelles;
- - Création des variables qui représentent les résultats des
- fonctions de manipulation;
- - Persistence (fichier med), visualisation (SALOME) ou export (vers
- une structure qui peut être directement utilisable en numpy)
-
-Sur le plan technique:
-
-* On souhaite spécifier clairement le conteneur SALOME des fonctions
- de manipulation de champs. Pour discussion:
-
- - Il apparaît que les modules SALOME MED et VISU contiennent déjà
- des fonctions qui peuvent faire partie des fonctions de
- manipulations de champs (en particulier pour l'exploration des
- structures MED, leur visualisation et la sélection des données à
- manipuler).
- - Dans la mesure où le module MED n'est pas utilisé à ce jour (en
- tout cas pas sous sa forme de module SALOME) et compte-tenu du
- caractère obsolescent du module VISU (amené à être remplacé sur le
- plan fonctionnel par le module PARAVIS), on pourrait examiner la
- création d'un module dédié à la manipulation des maillages et des
- champs par l'agrégation technique au sein d'un même module des
- fonctions des modules MED et VISU.
-
-Au moins dans un premier temps, on se donne les limites suivantes:
-
-* Une opération ne peut pas combiner des pas de temps différents. Dans
- l'hypothèse où cette limite venait à être levée, on doit spécifier
- le pas de temps de la donnée résultat;
-* Le domaine d'application d'une opération pourra être défini
- exclusivement par la donnée d'un maillage ou un groupe d'éléments du
- maillage;
-* On ne traite pas le cas des champs qui prennent leurs valeurs aux
- points de gauss ou aux noeuds par élément. Une particularité de ces
- types de support est que le repérage de la position implique deux
- indices (par exemple l'indice de la maille, puis l'indice du point
- de gauss).
-
-Eléments de conception
-======================
-
-Plan général
-------------
-
-On peut par exemple imaginer une maquette du genre:
-
-* En C++ dans MEDGUI, charger un fichier med et donner une vue de la
- structure des maillages et des champs dans l'arbre d'étude.
-* Sélectionner un élément (par exemple un pas de temps d'un champ) et
- le menu contextuel permet d'exporter ce champ dans la console python
- pour manipulation. Pour cela, s'inspirer de la fonction
- ``XCADGUI::OnLoadScript()`` du XCADGUI pour manoeuvrer un objet
- PythonConsole.
-* L'élément est marqué comme ayant été exporté, on peut imaginer une
- récupération ultérieure.
-* Exporter un deuxième champ cohérent avec le premier (même pas de
- temps et défini sur le même maillage avec le même support, on
- s'arrange pour).
-* Dans la console python, faire les opérations sur les champs
-* Publication du champ résultat dans l'arbre d'étude pour sauvegarde
- ultérieure. C'est a priori le gros morceau qui consiste à faire un
- objet CORBA MED à partir d'un objet MED standard, en plus défini
- dans la console python (sous forme d'objet python).
-
-Quand ce premier cas d'utilisation est au point, on peut envisager de
-le compléter par les opérations suivantes
-
-* exporter le résultat med dans un fichier
-* visualiser les champs produits
-
-Plan de développement:
-
-* Faire une maquette en MEDMEM pur d'abord, car quelque soit le choix
- d'architecture, l'opération physique se déroulera en définitif au
- niveau de MEDMEM pur.
-* Prévoir une implémentation des opérations sous forme de fonctions
- informatiques, même les opérations algébriques (+,-,*,/). Pour ces
- dernières et dans certaines conditions (quand on manipule
- directement les strutures MEDMEM et non pas les objets CORBA),
- l'utilisation des formes A+B, A-B, ... peuvent être rendues
- possibles. Dans ce cas, voir la possibilité de combiner plusieurs
- opérations algébriques sur une seule ligne: A+B-C*0.3.
-* On peut charger la structure MED sous forme d'objet CORBA publiable
- dans l'étude, de sorte d'avoir accés aux méta-données et pouvoir par
- exemple sélectionner les champs d'intérêt. De cet objet CORBA, on ne
- récupère que les informations nécessaires au chargement d'un champs:
- le nom du champs, le nom de son maillage associé, les identifiants
- du pas de temps, au besoin une structure Field non chargée (par
- exemple pour récupérer plus facilement le maillage).
-* Un mécanisme (à développer à partir du PyConsole par exemple)
- pourrait alors permettre le chargement des champs sélectionnés dans
- la console python et sous un nom facile à manoeuvrer. Prendre
- inspiration sur XCADGUI::LoadIntoPythonConsole().
-* A priori, les données sont physiquement chargée dans le GUI. Au
- besoin, il semble possible (cf. MED_i::init) de fabriquer une objet
- CORBA field à partir d'un field standard (à tester).
-
-Une autre idée est de récupérer le pointeur CORBA MED dans la console
-python et de tirer les données à partir de là. Ajouter une couche de
-wrapping python pur pour gérer les cas de simplification (surcharge
-des opérations arithmétiques par exemple).
-
-Besoins complémentaires:
-
-* L'interpréteur doit contenir des éléments d'aide (par exemple un
- help qui liste les opérations possibles sur les champs chargés)
-* prévoir quelques fonctions de visu et de persistence. Cela commence
- probablement par des fonctions de publication dans l'étude des
- champs créés par les opérations de manipulation. Les champs sont
- physiquement ajouté automatiquement à la structure med par le MedOp
- mais il n'est pas obligatoirement publié => fournir un moyen de
- publication.
-
-Limitations actuelles (liées à la conception de MEDMEM):
-
-* les champs doivent être gérés par la même structure MED car ils
- doivent partager le même support.
-* les opérations possibles dans MEDMEM sont entre champs pris sur un
- pas de temps (Q: les pas de temps peuvent-ils être différents).
-
-
-Développements
---------------
-
-Développement de classes proxy:
-
-* FieldProxy, FieldTimeSeriesProxy
-* Attention pour les éries temporelles, le SUPPORT med peut être
- différent en chaque pas de temps (par exemple en cas d'extension
- spatiale du champ au cours du temps).
-
-MEDMEM_MedDataManager:
-
-* FIX: test de l'implémentation C++ au travers de la fonction test() du
- MedOperator ==> OK. Quand on fait la même opération depuis python
- via l'interface SWIG ==> au deuxième appel de getFieldDouble, le
- destructeur du champ semble être appelé. Pb de gestion des pointeurs?
-
-
-Evolutions à prévoir
-====================
-
-Concernant MEDMEM:
-
-* FIX: SALOME_MED::MED::getField devrait pouvoir être appelée
- plusieurs fois de suite puisqu'on recycle la référence si elle est
- déjà chargée.
-* IMP: MEDMEM::MED faire une gestion des chargements des champs (par
- exemple avec un getField qui renvoie le champ s'il est déjà chargé
- ou le charge et le renvoie sinon).
-* IMP: Récupérer le nom du fichier med à partir de l'objet MED, en
- passant a priori par le driver associé. Plusieurs driver peuvent
- être associés à une structure MED car les données peuvent être
- chargées en plusieurs fois et de plusieurs fichiers. Il faut donc
- étendre la structure MED pour avoir accés à la liste des driver puis
- de cette liste déduire les noms des fichiers.
-* IMP: Opérations combinant des champs sur des support différents ne
- peuvent pas être faites par l'API (une exception est levée en cas de
- supports incompatibles), mais on peut imaginer le faire en
- manoeuvrant les tableaux de données directement.
-* INF: faire le point sur les fonctions utilitaires autour de MEDMEM
- et de son interface SWIG (ex: dumpMEDMEM.py, med_opfield_test.py).
-* IMP: dans MEDMEM::MED et SALOME_MED::MED, pouvoir enlever un champ
- préalablement ajouté: une fonction removeField en complément de
- addField.
-
-Concernant l'interface SALOME_MED:
-
-* IMP: Fonctions algébriques, qui seront implémentées au niveau de la
- structure MED et requêtées au niveau des classes proxy en spécifiant
- les identifiants des champs impliqués et les paramétres requis (pas
- de temps en particulier).
-
-Concernant le module MED:
-
-* IMP: pourvoir exporter la structure med dans un fichier med (la
- structure ayant pu être enrichie par la publication de champs créés
- par les operations de champs.
-
-
-Historique des travaux
-======================
-
-20100726 : mise au point du schéma de conception
-------------------------------------------------
-
-Choix entre MEDMEM et MEDCoupling: on reste sur MEDMEM pour plusieurs
-raisons:
-
-* MED Coupling ne peut pas gérer des mailles de dimensions différentes
- dans un même modèle (choix faits dans un soucis de performance dans
- l'accès à une structure de donnée compact). On peut contourner le
- problème en définissant deux champs pour traiter chacun des type de
- mailles.
-* Un champ repose sur un maillage complet (pas de notion de profil,
- mais cela peut être émulé en créant deux maillages)
-* Le concept de point de gauss n'existe pas (pas implémenté)
-
-TODO:
-
-* Idéalement, il conviendrait de faire un état des lieux du module
- MED, en particulier des éléments MEDMEM (le coeur), les interfaces
- CORBA associées (MED.idl implémenté dans le package source
- MEDMEM_I), l'engine (composant SALOME d'interface MED_Gen.idl et
- implémenté dans le package source MED) et le GUI (MedGUI.cxx
- implémenté dans le package source MEDGUI).
-
-* Ergonomie TUI et modèle CORBA associé:
-
- 1. Charger un objet medmem (puis les objets métier mesh et field)
- sur un domaine d'application donné.
- 2. En faire des variables disponibles dans l'interface TUI et que
- l'on peut manipuler dans des opérations algébriques.
- 3. Pouvoir au besoin en faire des objets CORBA pour l'interface avec
- les autres modules SALOME.
-
-* Compléter le diagramme de la structure informatique de MED (en
- particulier l'implémentation des interface IDL).
-* Préparer un module de travail XMED (organisation d'une bibliothèque)
-
-Tests à réaliser:
-
-* Est-il possible de faire des opérations algébriques à partir des
- objets SALOMEMED (objects CORBA MED)?
-* Création d'un objet MED_i à partir d'une objet MED pur préalablement
- chargé en mémoire.
-
-A retenir:
-
-* Des opérations de champs sont possibles sur des champs à des pas de
- temps fixés. Si l'opération doit être menée sur plusieurs pas de
- temps, alors itérer sur chaque pas de temps. L'idée ici est
- d'introduire le concept de série temporelle de champs en temps
- qu'objet manipulable.
-* Pour deux champs différents de la même structure MED, la données des
- identifiants dt et it ne correspond pas forcément au même instant
- absolu (en tout cas rien ne le garanti, même si c'est tout de même
- une pratique courante).
-
-20101005 : première maquette de démonstration de l'ergonomie en MEDMEM pur
---------------------------------------------------------------------------
-
-XMED: svn révision 16
-Travailler avec le fichier de donnée testfield.med joint.
-
-
-20101007 : Vers une maquette CORBA
-----------------------------------
-
-Le contexte d'utilisation des opérations de champs est l'environnement
-SALOME. Le support de gestion des données est donc l'étude SALOME. Au
-plus bas niveau, les champs sont des objets MEDMEM instanciés dans une
-session SALOME (soit par un code de calcul intégré, soit par
-chargement des données à partir d'un fichier med). Ces objets sont en
-général référencés dans l'étude SALOME sous la forme d'objets CORBA de
-classe SALOMEMED::FIELD. Plus exactement, l'étude SALOME gère des
-SObject (Study Object) dont un attribut est une référence vers un
-objet CORBA de classe SALOMEMED::FIELD qui lui-même encapsule un objet
-MEDMEM::Field.
-
-On peut donc envisager une solution dans laquelle on donne à
-l'utilisateur des poignées de manipulation des objets
-SALOMEMED::FIELD, par exemple au moyen d'un modèle informatique de
-type proxy. Cela signifie que l'utilisateur ne manipule pas
-directement des objets MEDMEM mais des objets python qui font
-l'interface (à concevoir et implémenter, a priori avec un design
-pattern de type proxy).
-
-L'utilisation directe des objets MEDMEM aurait pu être une solution
-extremement pratique dans la mesure où ces objets en l'état peuvent
-être combinés dans des opérations de champs (c'est déjà
-implémenté). Par contre, ce procédé souffre de limitations importantes
-dans la gestion et la circulation des données pour les différents cas
-d'utilisation envisagés (visualisation, export, transfert à un autre
-module SALOME).
-
-L'avantage de la solution proposée est multiple:
-
-* Elle permet de travailler sur une structure MED cohérente pour
- intégrer les résultats des opérations de calculs et combiner des
- champs cohérents entre eux. Tout passe par des classes proxy qui
- pourront s'assurer de la cohérence des opérations demandées et
- exécuter automatiquement les fonctions de pré-traitement ou
- post-traitement requises pour ces opérations. On peut imaginer par
- exemple que les requêtes d'opération soient envoyées par les classes
- proxy à la structure MED à laquelle les champs sont associés pour
- piloter l'opération en MEDMEM pur.
-* Elle permet d'automatiser un certain nombre d'opérations
- implicites. Par exemple si deux champs ne sont pas définis dans la
- même unité, un changement d'unité peut être effectué automatiquement
- par la classe proxy avant de commander l'opération au niveau
- MEDMEM.
-* Elle permet de laisser les données sur le container SALOME et de
- réaliser des opérations sans rappatrier les données en local (qui
- peuvent être en trés grand nombre).
-* Elle permet d'étendre facilement l'ergonomie de manipulation des
- champs, par exemple en définissant la notion de *série temporelle de
- champs*, ou encore les concepts de *domaine de définition* évoqués
- dans les spécifications fonctionnelles.
-* Elle rend immédiat la circulation des données entre modules SALOME,
- puisque les champs restent accessble par des objets CORBA, en
- particulier pour la visualisation ou l'export des champs produits
- par les opérations.
-
-Elle a cependant des inconvénients et/ou limitations:
-
-* Elle nécessite l'implémentation d'une classe proxy pour encapsuler tous
- les appels aux objets SALOME_MED (et donc MEDMEM). Cette interface
- se limite a priori aux opérations de champs (les opérations
- algébriques dans un premier temps).
-* Les champs à manipuler dans une opération donnée doivent être gérés
- par la même structure MED.
-
-Il est à noter également que les interfaces de programmation de
-SALOMEMED (interface CORBA pour MEDMEM) devront être étendues pour
-permettre des requêtes de manipulations de champs (fonctions addition,
-soustraction, multiplication, ...). Pas de contrainte ici sur
-l'ergonomie puisque la manipulation par l'utilisateur se fera au
-niveau des classes proxy uniquement.
-
-
-Hypothèses:
-
-* On tente ici une maquette qui exploite dans la mesure du possible le
- fonctionnement actuel du module MED, en particulier la gestion des
- données dans l'étude.
-* Dans une deuxième version, on pourra examiner sérieusement la
- révision de la gestion des données dans le module, quitte à la
- spécifier et maquetter dans XMED pour intégration ultérieure dans
- MED. Exemple:
-
- - Pouvoir gérer plusieurs structures med dans l'étude.
-
-* Enfin, on exploite MEDMEM en l'état. Pour les besoins de la gestion
- des données (gestion des chargements des champs en particulier,
- références croisées pour retrouver le med à partir du champ par
- exemple, ...), il pourra être nécessaire de faire évoluer MEDMEM. Il
- faut pouvoir par ailleurs gérer indifféremment une structure med (et
- les champs qui y sont associés) qu'elle soit créée en mémoire from
- scratch ou chargée d'un fichier (donc attention avec les opérations
- de lecture read(), sur les maillages comme sur les champs). La
- structure med permet d'obtenir les méta données (meta-field par
- exemple) mais ne permet pas de savoir si les données sont
- physiquement chargées ou pas.
-
-
-Révisions:
-
-* XMED svn revision 21 + tarball MED_SRC-20101014-15h26m.tgz.
- Première version qui permet d'importer un champ dans la console
- python sous la forme d'un FieldProxy. Ne permet pas encore de faire
- des opérations. Introduction dans le module MED de l'interface MEDOP
- pour prendre en charge les opérations sur les champs.
-
-
-20101019 : Maquette de démonstration pour l'addition
-----------------------------------------------------
-
-Cette maquette implémente une solution technique de bout en bout (de
-l'interface python aux objets MEDMEM, en passant par le fieldproxy
-puis les servants CORBA pour les operations, ...) mais sur le
-périmètre de l'addition de champs sur tout leur domaine de définition
-et pour un pas de temps donné.
-
-Limitations:
-
-* gére l'addition de champs de type double uniquement (parceque le
- reste n'est pas implémenté)
-
-Révisions:
-
-* XMED: svn révision 25
-* MED: cvs tag BR_medop_20101019
-
-
-20101020: Fonctions complémentaires
------------------------------------
-
-Cette version test la faisabilité des fonctions complémentaires pour
-accompagner la manipulation de champs. Cela comprend en particulier:
-
-* **la sauvegarde des champs produits** dans un fichier med (un champ ou
- toute la structure med). Pour cela, on définit un med proxy comme
- l'extention du SALOME_MED::MED (prévir plutôt d'implémenter ce type
- de fonction au niveau C++ pour permettre un usage au niveau du GUI
- C++?).
-* **la visualisation d'un champ** au moyen du module VISU.
-* **des fonctions d'aide interactives** pour assister l'utilisateur
- dans la console de manipulation des champs.
-
-
-Questions:
-
-* peut-on sauvegarder un champ unique?
-* peut-on faire en sorte que ce soit l'affectation à une variable qui
- provoque l'ajout du champ à la structure med (ou plus exactement qui
- supprime tous les champs intermédiaires).
-
-
-Révision:
-
-* XMED: svn revision 31
-* MED: cvs tag BR_medop_20101025
-
-
-20110606: commit avant transfert dans git
------------------------------------------
-
-* XMED: svn revision 53
-
-Les parties de MED utiles à MEDOP seront reversées dans XMED
-dans une première étape, puis le tout dans MED 6 au final.
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2011
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-Cas d'utilisation métier
-========================
-
-On illustre par un exemple (Christophe Vallet, R&D/MMC, 1/7/2011)::
-
- J'ai souvent des fichiers med de résultats de calcul, et j'aimerais y
- ajouter de nouveaux champs issus de champs existants. J'aimerais
- aussi pouvoir créer de nouveaux meds plus petits par extraction de
- certaines composantes de champs, certains groupes ou certains pas de
- temps.
-
-On peut exprimer le besoin sous la forme des cas d'utilisation
-suivants (use cases):
-
-* **UC1: combiner dans un même fichier med des champs issus de
- plusieurs sources de données**. On peut par exemple charger un
- premier fichier, puis ajouter à cette base des champs issus d'autre
- fichiers ou générés par manipulation de champs, ou encore générés
- par un module de calcul qui produirait directement du MEDCoupling.
-* **UC2: créer un champ contenant certaines composantes d'un autre
- champ**. On pense ici aux fonctions de restriction, qui permettraient
- de récupérer certaines composantes uniquement.
-* **UC3: créer un champ contenant certains pas de temps d'un autre
- champ**. C'est un cas particulier des fonctions de restriction
- évoquées ci-dessus.
-* **UC4: créer un champ comme la limitation d'un autre champ à un
- groupe de mailles**. C'est un cas particulier des fonctions de
- restriction évoquées ci-dessus. Notion de domaine spatial. A
- priori la notion de groupe est définie dans MEDLoader.
-
-On peut ajouter également les UC identifiés pour la maquette 2010:
-
-* **UC5: comparer des champs issus de source de données différentes**,
- par exemple des champs chargés de deux fichiers med différents et
- qui s'appuient sur le même maillage (au moins conceptuellement). Le
- problème technique ici est de pouvoir changer le maillage d'un
- champ, pour ramener tous les champs sur le même maillage (au sens
- informatique). Ceci est une contrainte de MEDCoupling, les
- opérations sur des champs A et B imposent que A et B soient définis
- sur le même maillage, i.e. le même objet informatique.
-* **UC6: créer un champ de toute pièce sur un maillage**, ou un groupe
- de mailles. Ce cas d'usage est typiquement prévu pour produire les
- conditions de chargement initial d'une structure. Il s'agit ici
- d'initialiser un champ à partir de zéro sur une surface prédéfinie
- de la géométrie (par exemple spécifiée par un nom de groupe de
- mailles).
-
-Pour UC5: les sources de données sont référencées dans l'object
-browser. On importe explicitement les données dans l'espace de
-travail. On peut détecter que les maillages sont identiques et on
-propose à l'utilisateur de transférer le champ sur le maillage déjà
-présent. Sinon, les champs devront être référencés sur des maillages
-distincts dans l'arbre de l'espace de travail.
-
-Analyses préliminaires pour le chantier 2011
-============================================
-
-On fait le choix pour le chantier 2011 de travailler à partir de la
-bibliothèque MEDCoupling (et non plus MEDMEM comme c'était le cas dans
-le démonstrateur 2011).
-
-Analyse de MEDCoupling et MEDLoader
------------------------------------
-
-MEDCoupling est l'implémentation du modèle de données MED (avec
-recherche de minimisation des dépendances logicielles) et MEDLoader
-fournit une ensemble de fonctions pour le chargement des structures
-MEDCoupling depuis un fichier ou inversement leur sauvegarde sous
-forme de fichiers.
-
-Dans l'implémentation MEDCoupling, un champ est l'ensemble des valeurs
-d'une grandeur physique sur un maillage pour un pas de temps donné. Un
-champ est caractérisé par:
-
-* un support spatial, le maillage
-* un type de discrétisation spatial, défini par l'emplacement des
- valeurs sur le maillage (sur les noeuds, sur les cellules, aux
- points de gauss, ...) et le mode d'interpolation spatial (P0, P1,
- etc)
-* un pas de temps, défini par deux entiers (iteration, order) et un
- réel (timestamps)
-
-Dans cette implémentation, il existe une association 1..n entre un
-maillage et un champ (alors que dans MEDMEM, la structure
-intermédiaire SUPPORT est implémentée).
-
-MEDCouplingCorba fournit un ensemble de servants CORBA pour manoeuvrer
-des structures MEDCoupling au travers du bus CORBA. L'interface à ce
-jour est délibérément réduite. Des classes dites "Cliente" sont
-fournies pour piloter les servants CORBA depuis un contexte
-client. Par exemple ``MEDCouplingFieldDoubleClient`` fournit une
-fonction de création d'une structure MEDCoupling à partir d'un
-pointeur vers un servant CORBA. La structure est créée localement
-(dans le contexte client) avec duplication des données issue de la
-structure encapsulée par le servant CORBA (récupération par la
-fonction de sérialisation).
-
-Aucune interface CORBA n'est défini pour MEDLoader.
-
-Questions:
-
-* Voir comment sont créés les servants, et surtout comment ils sont
- récupérés (via le lcc?)
-* Comment peut-on définir un champ sur un groupe de mailles (et non
- pas sur le maillage complet)? Comment peut-on extraire le champs
- circoncit à une groupe de mailles pour des opérations.
-
- - R: méthode changeUnderlyingMesh
-
-* Comment manipuler deux champs chargées de fichiers différents mais
- construit sur le même maillage (conceptuellement). On peut forcer la
- réassociation d'un champ sur un autre maillage?
-* Manipuler des champs de pas de temps différents? Différentes
- composantes d'un ou plusieurs champs?
-* Comment importer un MedCoupling dans PARAVIS? (dans VISU?)?
-
-* mapper sur une image
-
-Improvments:
-
-* MEDLoader::Write should raise an exception if the filepath is not writable
-* MEDDataManager: développer une classe chapeau sur MEDCoupling et
- MEDLoader pour aider au chargement et la gestion de données MED
- (orienté manipulation de champs). Cette classe serait associée des
- structures légères FieldHandler et MeshHandler et des listes
- correspondantes pour la navigation dans les méta-données.
-* Sur base du MEDDataManager, prévoir des ports med pour yacs par
- lesquels pourrait transiter des handler.
-
-Nouveaux concepts à prendre en compte
--------------------------------------
-
-Au démarrage du chantier 2011, on observe que les concepts suivants
-sont introduits dans le module MED:
-
-* Le conteneur MED n'existe plus, utiliser MEDFILEBROWSER pour charger
- les fichiers med et obtenir les informations générales sur le
- contenu.
-* MEDFILEBROWSER: remplace le concept de driver et fournit les
- fonctions précédemment fournies par la classe MED pour obtenir les
- informations de structure.
-* Concept d'Extractor pour une lecture sélective des données de champs
- (suivant un critère d'extraction)
-* Il n'est plus nécessaire d'appeler les méthodes read explicitement
- sur les objets (MESH et FIELD) pour charger les données. Par
- ailleurs, on peut définir deux fois le même champs (double
- chargement a priori) sans lever d'exception).
-
-
-Analyse de conception pour le chantier 2011
-===========================================
-
-Composants SALOME (interfaces IDL)
-----------------------------------
-
-* MEDDataManager: défini une structure FIELD pour identifier un champ
- dans les requêtes. Il s'occupe également de la récupération physique
- des données, quelqu'en soit la source (fichier avec MEDLoader, autre
- module SALOME comme PARAVIS avec une méthode à définir)
-* MEDCalculator: s'occupe des requêtes de calcul dont les arguments sont
- les structures FIELD du MEDDataManager. Reprendre l'interface de
- MEDOP.
-
-Use case à réaliser depuis un client python:
-
-* UC01: ajouter un fichier d'entrée et accéder aux informations
- concernant les champs. Ex: récupérer une structure champs par la
- donnée des paramètres primaires (nom identifiant, dt, it, nom du
- maillage).
-* UC02: créer des champs et les ajouter au MEDDataManager
-* UC03: mener des opérations basique sur les champs en console python
-
-Interface Utilisateur
----------------------
-
-L'interface utilisateur est composée des parties suivantes:
-
-* une partie GUI (appelée par la suite MEDGUI) qui s'occupe de piloter
- le chargement des données dans l'espace de travail, au moyen d'une
- interface graphique;
-* une partie TUI (appelée par la suite MEDTUI) qui s'occupe de piloter
- la création de champs, au moyen de commandes exécutées dans la
- console python.
-
-Le principe est que les champs sont préalablement chargés au niveau du
-composant SALOME au moyen de l'interface graphique (MEDGUI), puis
-manoeuvrés depuis l'application SALOME au moyen de variables proxy
-définies dans la console python (MEDTUI). Au chargement, les champs
-sont indéxés par le MEDDataManager, puis les index sont rendus
-accessibles au niveau du GUI au moyen d'une représentation
-arborescente de la structure MED. Les feuilles de l'arbre
-correspondent à des champs qui peuvent être sélectionnés et dont
-l'index peut être obtenu de la sélection.
-
-L'espace de travail est organisé autour du concept de
-"workspace". L'étude SALOME liste les datasource (les fichiers source
-des données med, mais peut-être aussi les référence vers des objets
-MED déjà existants ou chargé dans PARAVIZ). Une vue complémentaire
-permet de voir la structure fine d'une source de données.
-
-Concernant MEDGUI:
-
-* la représentation des données (les champs et les maillages associés)
- doit permettre de récupérer par l'interface graphique les
- identifiants des champs à manipuler (a priori les structures FIELD
- définies par le composant MEDDataManager). Cela conduit à la mise en
- place des composants suivants:
-
- - MedDataModel hérité de TreeData. Il est peuplé avec les
- méta-données décrivant la structure MED explorée.
- - MedGuiManager qui permet l'implantation du doc widget de
- présentation
-
-TODO:
-
-* specifier le concept de workspace (qui a une entrée dans l'étude?)
- en bijection avec un datamanager
-* identifier des interlocuteur/utilisateur pour l'aspect ergonomie d'usage
-
-Concernant MEDTUI:
-
-* Il fournit les classes FieldProxy
-
-Questions:
-
-* Comment traiter le cas du travail sur des composantes ciblées, plus
- généralement, comment introduire le concept de domaine
- d'application?
-* Prévoir des fonctions génériques (initialisation d'un champ sur un
- maillage avec une fonction analytique de la position, sauvegarder
- les champs créés dans un fichier med)
-
-
-Tâches de développement
-=======================
-
-T20110622.1: Gestion des données internes
------------------------------------------
-
-**Status: terminé.**
-Suite: fonction de sauvegarde au niveau graphique également
-
-On vise les cas d'utiliation suivants:
-
-* UC1: intégrer dans le datamodel du gui un champ créé dans la console
- python (et donc présent dans le datamanager du composant). Définir
- l'utilité?
-* UC2: renommer un champ et plus généralement changer ses méta-données
- (avec assurance de synchronisation entre toutes les données).
-* UC3: sauvegarder une sélection de champs. La sélection peut se faire
- dans l'arbre du datamodel gui.
-
-WARN: robustesse de fieldproxy
-
-
-
-T20110622.2: UC Initialisation/Création de champs
--------------------------------------------------
-
-**Status: à faire**
-
-Les cas implémentés à ce jour sont la création de champs à partir de
-champs existants et chargés d'un fichier med. On souhaite ici réaliser
-des cas 'utilisation autour de la création de champs "from scratch",
-s'appuyant tout de même sur un maillage chargé.
-
-UC01: Sélection d'un groupe de maille dans SMESH pour initialiser un
-champ (par exemple les conditions limites d'un problème de calcul).
-
-UC02: créer un champ avec des restrictions qui définissent le domaine
-d'application des opération de champs.
-
-UC03: créer un champ à partir d'une image (codes rgb utilisé comme les
-composantes du champs vectoriel ou niveaux de gris pour un champ
-scalaire. Attention, pour ça, il faudra a priori fiare une projection
-du maillage cartesien de l'image sur le maillage (quelconque) sur
-lequel on souhaite définir le champ.
-
-UC04: créer un champ à partir d'un tableau numpy
-
-De manière générale, ce type de création sera assisté par le
-MEDGUI. Au niveau MEDTUI, les fonctions pourraient être fastidieuses
-pour l'utilisateur.
-
-Par exemple, prévoir un menu contextuel qui propose les opérations
-possibles en fonction de la sélection (en plus de la fonction d'import
-dans la console python).
-
-TODO:
-
-* développer les fonctions d'initialisation, par exemple au moyen
- d'applyFunc et du mécanisme de callable?
-
-T20110622.3: documentation contextuel
--------------------------------------
-
-**Status: à faire**
-
-* Remettre toutes les commandes dans le même fichier (fusionner cmdtools
- et fieldtools)
-* Faire un modèle générique de command (classe de base
-* Batir la doc des commandes sur cette base (lister toutes les
- instances de type Command par exemple)
-
-T20110622.4: remontée des exception du composant MEDCalculator
---------------------------------------------------------------
-
-**Status: en cours, compléter la couverture**
-
-Pour des messages contextuel sur les erreurs de calcul (ex: division
-par 0)
-
-* Poursuivre le travail fait sur getMedEventListener
-* Protéger tous les appels au composants effectués depuis la console
- python (prendre example sur la commande save)
-
-T20110624.1: gestion des données GUI
-------------------------------------
-
-**Status: à faire**
-
-
-
-Le workspace a une entrée dans l'obrowser. Sur cette entrée on peut:
-
-* supprimer: supprime tout les champs associés
-* sauvegarder. Dans ce cas, on rappelle l'ensemble des champs pour
- cocher ceux qu'on veut sauvegarder.
-
-Le gui data model est réservé aux opérations sur les champs et à
-piloter leur import dans la console python.
-
-TODO:
-
-* Spécifier les concepts de workspace, database, et datasource, espace
- de gestion, ... et les associations. Simplifier avec l'appuie de use
- cases.
-* Mécanisme de mise à jour du TreeView de XSALOME (aujourd'hui, seul
- l'ajout addChild est implémenté
-* Clic droit sur objets de l'arbre: dans la notification TreeView ->
- WorkspaceController, faire remonter l'évènement clic droit ainsi que la
- liste des éléments sélectionné pour faire générer le menu contextuel
- au niveau du WorkspaceController qui peut déterminer le contexte métier
- (le TreeView ne le connaît pas).
-* Définir des DataObject pour les maillages, les séries temporelles et
- les champs
-
-
-Spécification des espaces de données:
-
-* MEDDataManager dépend de l'étude (pour permettre la publication
- d'information dans une étude SALOME).
-* créer "sourcid = MEDDataManager::addDataSource(filename)", suivie de
- requetes getFields(sourceid), getMeshes(sourceid)
-* les espaces de données: dataspace, workspace. Un seul workspace par
- étude, mais autand de datasources que l'on souhaite dans le
- dataspace. Les datasources sont rangés dans l'étude (le dataspace)
- et sont non modifiables après chargement (référence des sources de
- données).
-
-
-T20110628.1: extention à d'autres objets SALOME
------------------------------------------------
-
-**Status: suspendu**
-
-On doit reposer la question de l'existance de l'arbre indépendant
-(DockWidget), d'une part, et l'extention aux autres objets (GEOM et
-SMESH en particulier) du principe de sélection graphique pour
-utilisation dans la console python, d'autre part.
-
-
-T20110628.2: visualisation d'un champ avec PARAVIS
---------------------------------------------------
-
-**Status: terminé (pour une première version)**
-Suite: de nombreux défauts subsistent
-
-Questions/remarques:
-
-* Pb au démarrage du module: VisTrails fails to start
-* Peux-t-on piloter la vue 3D sans charger le module? (voir
- myparavis.py)
-* Comment donner un nom au MEDReader1 dans l'arbre Pipeline?
-* Comment utiliser directement les objets MEDCouplingField?
-
-
-T20110706.1: documentation du module
-------------------------------------
-
-**Status: en cours (10%)**
-
-Documenter les commandes TUI puis l'utilisation générale de
-l'interafce graphique. Mentionner l'existance de la commande medop.sh
-pour travailler exclusivement en mode texte (utile pour les tests
-rapides).
-
-Documenter les modalités d'exécution des tests.
-
-T20110708.1: helper python pour MEDCoupling
--------------------------------------------
-
-**Status: en attente (pas urgent)**
-
-Faire un helper python dans le package xmed qui permet de faire du
-medcoupling facilement (essentiellement pour simplifier le chargement,
-puis la sélection des données). Cela demanderait de faire un
-MedDataManager comme une class C++ pure (non CORBA). Cette classe
-travaillerait par exemple uniquement avec des id et des liste d'id, et
-fournirait des fonctions d'affichage (comme le ``ls`` et le ``la``)
-pour obtenir des meta-information.
-
-Le servant MedDataManager pourrait être une surcouche de cette classe
-c++ pure.
-
-T20110708.2: analyses et tests
-------------------------------
-
-TODO:
-
-* créer un fichier de test avec plusieurs pas de temps
-* créer un fichier de test avec des groupes de mailles
-
-
-T20110728.1: refactoring MEDDataManager
----------------------------------------
-
-Refactoring pour une meilleur association entre FieldHandler et MeshHandler:
-
-* dans la mesure du possible utiliser les id plutôt que les handler en
- arguments des fonctions d'appel des objets
-* A chaque champ (FieldHandler), on doit associer un meshid (et de
- manière optionnelle un fieldseriesId, si le champ peut être associé
- à une serie temporelle. A priori faisable uniquement au chargement
- du datasource).
-* Pour cela, revoir les fonctions internes newFieldHandler et addField
- ou prévoir de les compléter à chaque fois qu'elles sont appelée avec
- les informations concernant le meshid.
-* addField est utilisée par le MEDCalculator
-* Attention au raffraichissement des données handler au niveau du
- Workspace. Peut-être le mieux est que les fieldproxy contiennent
- uniquement le fieldid, et qu'ils interroge le datamanager à chaque
- fois qu'ils ont besoin d'une donnée. Voir aussi les notifications
- via le MEDEventListener? **Le plus simple est de faire la mise à
- jour lors de l'appel à la méthode __repr__ du fieldproxy, i.e. quand
- on essaye d'afficher les données**. Parceque sinon il n'y a pas de
- problème puisque que le calculateur travaille à partir des id.
-
-
-Petites améliorations du DataspaceController:
-
-* Au OnUseInWorkspace, stocker (dans la mesure du possible) le nom de
- l'alias python dans un attribut du sobject.
-* Dans DlgChangeUnderLyingMesh, expliquer que le champs sera dupliquer
- est posé dans le WS. On peut donc proposer en option de lui associer
- un alias pour manipulation dans la console
-
-
-
+++ /dev/null
-.. meta::
- :keywords: maillage, champ, manipulation
- :author: Guillaume Boulant
-
-.. include:: medop-definitions.rst
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-ANNEXE: Note de travail concernant le chantier XMED 2012
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-.. contents:: Sommaire
- :local:
- :backlinks: none
-
-
-Analyse preliminaire pour le chantier 2012
-==========================================
-
-La figure imposée pour le chantier 2012 est l'intégration du nouveau
-module de manipulation de champs dans SALOME 6.6 (objectif CEA), en
-préparation de la mise en exploitation dans SALOME 7 (objectif EDF).
-
-L'état actuel est:
-
-* Un module SALOME de nom MED intégrant les bibliothèques MEDCoupling,
- MEDLoader, REMAPPER, mais aussi plusieurs packages logiciels
- aujourd'hui obsolètes ou amener à disparaître pour l'échéance
- SALOME7
-* Un module SALOME de nom XMED qui fournit les fonctions graphiques
- pour la manipulation de champs.
-* Ce module XMED utilise le module VISU pour les vue de contrôle.
-
-La cible est:
-
-* Un module unique (nom à définir, par exemple MEDOP) débarrassé des
- packages logiciels obsolètes et intégrant les fonctions graphiques
- (GUI et TUI).
-* L'utilisation du module PARAVIS (au lieu de VISU) pour les vues de
- contrôle.
-* L'intégration de MEDCoupling avec YACS (port MED dans YACS par
- exemple).
-
-A examiner:
-
-* voir les attendus concernant les ports MED dans YACS
-* interface PARAVIS: utilisation du viewer (et de l'API python) sans chargement du GUI
-
-Tâches de développement
-=======================
-
-20120904: Migrer XMED dans MED
-------------------------------
-
-Plan de travail:
-
-* Migration des composants + test
-
-
-
-20120904: Nettoyage de XSALOME
-------------------------------
-
-:status: en cours
-
-* Supprimer les vieilleries de XSALOME:
-
- - StdHelper -> Basic_Utils (KERNEL)
-
-20120829: mise en place du chantier 2012
-----------------------------------------
-
-:status: terminé
-
-L'objectif de cette première étape est de reverser le prototype 2011
-(module XMED indépendant) dans la branche V6_main du module MED. On
-peut procéder de la manière suivante:
-
-* update de XMED (et XSALOME utilisé par XMED) pour fonctionnement sur
- V6_main
-* Eliminer la dépendance à XSALOME
-* Supprimer la gestion des multiversion SALOME5/6 au niveau de l'engine
-
-.. warning:: TODO: refaire le point sur les tâches initiées en 2011
-
# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
#
-SALOME_CONFIGURE_FILE(conf.py.in conf.py)
+CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/conf.py.in ${CMAKE_CURRENT_BINARY_DIR}/conf.py)
+
+MACRO(MEDCOUPLING_EXTEND_ENVIRONMENT_VARIABLE output envvar values)
+ SET(_env)
+ FOREACH(_val ${values})
+ IF(${envvar} STREQUAL "PATH" OR ${envvar} STREQUAL "LD_LIBRARY_PATH")
+ IF(NOT IS_DIRECTORY ${_val})
+ GET_FILENAME_COMPONENT(_val "${_val}" PATH)
+ ENDIF()
+ ENDIF()
+ IF(WIN32)
+ IF(${envvar} STREQUAL "LD_LIBRARY_PATH")
+ SET(envvar PATH)
+ ENDIF()
+ STRING(REPLACE "/" "\\" _env "${_env} @SET ${envvar}=${_val};%${envvar}%\n")
+ ELSE(WIN32)
+ SET(_env "${_env} export ${envvar}=${_val}:\${${envvar}}\n")
+ ENDIF(WIN32)
+ ENDFOREACH(_val)
+ SET(${output} "${${output}} ${_env}")
+ENDMACRO(MEDCOUPLING_EXTEND_ENVIRONMENT_VARIABLE envvar values)
+
+
+SET(SETUPTOOLS_PATH $ENV{SETUPTOOLS_ROOT_DIR}/bin)
+SET(SETUPTOOLS_PYTHONPATH $ENV{SETUPTOOLS_ROOT_DIR}/lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages)
+
+SET(DOCUTILS_PATH $ENV{DOCUTILS_ROOT_DIR}/bin)
+SET(DOCUTILS_PYTHONPATH $ENV{DOCUTILS_ROOT_DIR}/lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages)
+
+SET(PKGCONFIG_PYTHONPATH $ENV{PKGCONFIG_ROOT_DIR}/lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages)
+
+
+SET(build_env)
+
+#SET(_variables ${SPHINX_EXECUTABLE} ${SPHINX_APIDOC_EXECUTABLE} ${PYTHON_EXECUTABLE} ${GRAPHVIZ_EXECUTABLE} ${SETUPTOOLS_PATH} ${DOCUTILS_PATH})
+#MEDCOUPLING_EXTEND_ENVIRONMENT_VARIABLE(build_env "PATH" "${_variables}")
+
+#SET(_variables ${SPHINX_PYTHONPATH} ${PYTHON_PYTHONPATH} ${SETUPTOOLS_PYTHONPATH} ${DOCUTILS_PYTHONPATH} ${PKGCONFIG_PYTHONPATH})
+SET(_variables ${SPHINX_PYTHONPATH} ${SETUPTOOLS_PYTHONPATH} ${PKGCONFIG_PYTHONPATH} ${DOCUTILS_PYTHONPATH})
+MEDCOUPLING_EXTEND_ENVIRONMENT_VARIABLE(build_env "PYTHONPATH" "${_variables}")
+
+#SET(_variables ${PYTHON_LIBRARIES} ${GRAPHVIZ_LIBRARIES})
+SET(_variables ${PYTHON_LIBRARIES})
+MEDCOUPLING_EXTEND_ENVIRONMENT_VARIABLE(build_env "LD_LIBRARY_PATH" "${_variables}")
+
+IF(WIN32)
+ SET(_ext "bat")
+ SET(_call_cmd "call")
+ELSE()
+ SET(_ext "sh")
+ SET(_call_cmd ".")
+ENDIF()
+
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}")
+SET(_cmd ${SPHINX_EXECUTABLE} ${_cmd_options})
+
+SET(_script ${CMAKE_CURRENT_BINARY_DIR}/env_script.${_ext})
+
+FILE(WRITE ${_script} "${build_env}")
+SET(make_doc ${_call_cmd} ${_script} && ${_cmd})
+
-ADD_CUSTOM_TARGET(tutorial_doc COMMAND ${_cmd})
+ADD_CUSTOM_TARGET(tutorial_doc COMMAND ${make_doc})
ADD_DEPENDENCIES(usr_docs tutorial_doc)
#INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target tutorial_doc)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${SALOME_INSTALL_DOC}/gui/MED/tutorial)
-INSTALL(DIRECTORY images/ DESTINATION ${SALOME_INSTALL_DOC}/gui/MED/tutorial/images)
-INSTALL(DIRECTORY data/ DESTINATION ${SALOME_INSTALL_DOC}/gui/MED/tutorial/data)
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial)
+INSTALL(DIRECTORY images/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial/images)
+INSTALL(DIRECTORY data/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial/data)
SET(make_clean_files html doctrees)
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${make_clean_files}")
# built documents.
#
# The short X.Y version.
-version = '@SALOMEMED_VERSION@'
+version = '@MEDCOUPLING_VERSION@'
# The full version, including alpha/beta/rc tags.
-release = '@SALOMEMED_VERSION@'
+release = '@MEDCOUPLING_VERSION@'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
Playing with unstructured mesh
------------------------------
-Unstructured meshes are the most used mesh type. MEDCouplingUMesh is the name of the class representing unstuctured meshes in MEDCoupling. MEDCouplingUMesh inherits from the MEDCouplingPointSet class that deals with all methods handling coordinates only.
+Unstructured meshes are the most used mesh type. MEDCouplingUMesh is the name of the class representing unstuctured meshes in MEDCoupling. MEDCouplingUMesh inherits from the MEDCouplingPointSet class that deals with all methods handling coordinates only.
MEDCouplingUMesh adds two more attributes :
* nodal connectivity
* nodal connectivity index
Import the MEDCoupling Python module. ::
- from MEDCoupling import *
+ from MEDCoupling import *
We now build a mesh containing artificially two types of cell (NORM_HEXA8 and NORM_POLYHED) to highlight the possibility to work with non-homogeneous cell types.
mesh3D is an extruded mesh containing 18 cells composed into 3 levels along Z of 6 cells.
Copy paste the following lines. ::
- coords=[0.,0.,0., 1.,1.,0., 1.,1.25,0., 1.,0.,0., 1.,1.5,0., 2.,0.,0., 2.,1.,0., 1.,2.,0., 0.,2.,0., 3.,1.,0.,
+ coords=[0.,0.,0., 1.,1.,0., 1.,1.25,0., 1.,0.,0., 1.,1.5,0., 2.,0.,0., 2.,1.,0., 1.,2.,0., 0.,2.,0., 3.,1.,0.,
3.,2.,0., 0.,1.,0., 1.,3.,0., 2.,2.,0., 2.,3.,0.,
0.,0.,1., 1.,1.,1., 1.,1.25,1., 1.,0.,1., 1.,1.5,1., 2.,0.,1., 2.,1.,1., 1.,2.,1., 0.,2.,1., 3.,1.,1.,
3.,2.,1., 0.,1.,1., 1.,3.,1., 2.,2.,1., 2.,3.,1.,
3.,2.,2., 0.,1.,2., 1.,3.,2., 2.,2.,2., 2.,3.,2.,
0.,0.,3., 1.,1.,3., 1.,1.25,3., 1.,0.,3., 1.,1.5,3., 2.,0.,3., 2.,1.,3., 1.,2.,3., 0.,2.,3., 3.,1.,3.,
3.,2.,3., 0.,1.,3., 1.,3.,3., 2.,2.,3., 2.,3.,3.]
- conn=[0,11,1,3,15,26,16,18, 1,2,4,7,13,6,-1,1,16,21,6,-1,6,21,28,13,-1,13,7,22,28,-1,7,4,19,22,-1,4,2,17,19,-1,2,1,16,17,-1,16,21,28,22,19,17,
+ conn=[0,11,1,3,15,26,16,18, 1,2,4,7,13,6,-1,1,16,21,6,-1,6,21,28,13,-1,13,7,22,28,-1,7,4,19,22,-1,4,2,17,19,-1,2,1,16,17,-1,16,21,28,22,19,17,
1,6,5,3,16,21,20,18, 13,10,9,6,28,25,24,21, 11,8,7,4,2,1,-1,11,26,16,1,-1,1,16,17,2,-1,2,17,19,4,-1,4,19,22,7,-1,7,8,23,22,-1,8,11,26,23,-1,26,16,17,19,22,23,
7,12,14,13,22,27,29,28, 15,26,16,18,30,41,31,33, 16,17,19,22,28,21,-1,16,31,36,21,-1,21,36,43,28,-1,28,22,37,43,-1,22,19,34,37,-1,19,17,32,34,-1,17,16,31,32,-1,31,36,43,37,34,32,
16,21,20,18,31,36,35,33, 28,25,24,21,43,40,39,36, 26,23,22,19,17,16,-1,26,41,31,16,-1,16,31,32,17,-1,17,32,34,19,-1,19,34,37,22,-1,22,23,38,37,-1,23,26,41,38,-1,41,31,32,34,37,38,
22,27,29,28,37,42,44,43, 30,41,31,33,45,56,46,48, 31,32,34,37,43,36,-1,31,46,51,36,-1,36,51,58,43,-1,43,37,52,58,-1,37,34,49,52,-1,34,32,47,49,-1,32,31,46,47,-1,46,51,58,52,49,47,
31,36,35,33,46,51,50,48, 43,40,39,36,58,55,54,51, 41,38,37,34,32,31,-1,41,56,46,31,-1,31,46,47,32,-1,32,47,49,34,-1,34,49,52,37,-1,37,38,53,52,-1,38,41,56,53,-1,56,46,47,49,52,53,
37,42,44,43,52,57,59,58]
- mesh3D=MEDCouplingUMesh.New("mesh3D",3)
- mesh3D.allocateCells(18)
- mesh3D.insertNextCell(NORM_HEXA8,conn[0:8]); mesh3D.insertNextCell(NORM_POLYHED,conn[8:51]); mesh3D.insertNextCell(NORM_HEXA8,conn[51:59]); mesh3D.insertNextCell(NORM_HEXA8,conn[59:67]); mesh3D.insertNextCell(NORM_POLYHED,conn[67:110]); mesh3D.insertNextCell(NORM_HEXA8,conn[110:118]);
- mesh3D.insertNextCell(NORM_HEXA8,conn[118:126]); mesh3D.insertNextCell(NORM_POLYHED,conn[126:169]); mesh3D.insertNextCell(NORM_HEXA8,conn[169:177]); mesh3D.insertNextCell(NORM_HEXA8,conn[177:185]); mesh3D.insertNextCell(NORM_POLYHED,conn[185:228]); mesh3D.insertNextCell(NORM_HEXA8,conn[228:236]);
- mesh3D.insertNextCell(NORM_HEXA8,conn[236:244]); mesh3D.insertNextCell(NORM_POLYHED,conn[244:287]); mesh3D.insertNextCell(NORM_HEXA8,conn[287:295]); mesh3D.insertNextCell(NORM_HEXA8,conn[295:303]); mesh3D.insertNextCell(NORM_POLYHED,conn[303:346]); mesh3D.insertNextCell(NORM_HEXA8,conn[346:354]);
- myCoords=DataArrayDouble.New(coords,60,3)
- myCoords.setInfoOnComponents(["X [m]","Y [m]","Z [m]"])
- mesh3D.setCoords(myCoords)
- mesh3D.orientCorrectlyPolyhedrons()
- mesh3D.sortCellsInMEDFileFrmt()
- mesh3D.checkCoherency()
- renum=DataArrayInt.New(60) ; renum[:15]=range(15,30) ; renum[15:30]=range(15) ; renum[30:45]=range(45,60) ; renum[45:]=range(30,45)
- mesh3D.renumberNodes(renum,60)
-
+ mesh3D=MEDCouplingUMesh.New("mesh3D",3)
+ mesh3D.allocateCells(18)
+ mesh3D.insertNextCell(NORM_HEXA8,conn[0:8]); mesh3D.insertNextCell(NORM_POLYHED,conn[8:51]); mesh3D.insertNextCell(NORM_HEXA8,conn[51:59]); mesh3D.insertNextCell(NORM_HEXA8,conn[59:67]); mesh3D.insertNextCell(NORM_POLYHED,conn[67:110]); mesh3D.insertNextCell(NORM_HEXA8,conn[110:118]);
+ mesh3D.insertNextCell(NORM_HEXA8,conn[118:126]); mesh3D.insertNextCell(NORM_POLYHED,conn[126:169]); mesh3D.insertNextCell(NORM_HEXA8,conn[169:177]); mesh3D.insertNextCell(NORM_HEXA8,conn[177:185]); mesh3D.insertNextCell(NORM_POLYHED,conn[185:228]); mesh3D.insertNextCell(NORM_HEXA8,conn[228:236]);
+ mesh3D.insertNextCell(NORM_HEXA8,conn[236:244]); mesh3D.insertNextCell(NORM_POLYHED,conn[244:287]); mesh3D.insertNextCell(NORM_HEXA8,conn[287:295]); mesh3D.insertNextCell(NORM_HEXA8,conn[295:303]); mesh3D.insertNextCell(NORM_POLYHED,conn[303:346]); mesh3D.insertNextCell(NORM_HEXA8,conn[346:354]);
+ myCoords=DataArrayDouble.New(coords,60,3)
+ myCoords.setInfoOnComponents(["X [m]","Y [m]","Z [m]"])
+ mesh3D.setCoords(myCoords)
+ mesh3D.orientCorrectlyPolyhedrons()
+ mesh3D.sortCellsInMEDFileFrmt()
+ mesh3D.checkCoherency()
+ renum=DataArrayInt.New(60) ; renum[:15]=range(15,30) ; renum[15:30]=range(15) ; renum[30:45]=range(45,60) ; renum[45:]=range(30,45)
+ mesh3D.renumberNodes(renum,60)
+
Convert coordinate unit from meters to centimeters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It might seem stupid, but this comes up regularly when coupling... ::
- mesh3D.getCoords()[:]*=100.
- mesh3D.getCoords().setInfoOnComponents(["X [cm]","Y [cm]","Z [cm]"])
+ mesh3D.getCoords()[:]*=100.
+ mesh3D.getCoords().setInfoOnComponents(["X [cm]","Y [cm]","Z [cm]"])
.. note:: It is important to keep the DataArrayDouble instance up-to-date about the physical units to avoid ambiguity. The INTERP_KERNEL library includes a physical unit processor.
DataArrayDouble.getDifferentValues and DataArrayDouble.sort can help you! ::
- zLev=mesh3D.getCoords()[:,2]
- zLev=zLev.getDifferentValues(1e-12)
- zLev.sort()
+ zLev=mesh3D.getCoords()[:,2]
+ zLev=zLev.getDifferentValues(1e-12)
+ zLev.sort()
Extract the 6 cells of the second row along Oz
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
going through point [0.,0.,(zLev[1]+zLev[2])/2]. This method retrieves 2 things : the slicemesh containing the result slicing mesh3D
and foreach 2D cell in slicemesh, the corresponding cell id into mesh3D. ::
- tmp,cellIdsSol1=mesh3D.buildSlice3D([0.,0.,(zLev[1]+zLev[2])/2],[0.,0.,1.],1e-12)
+ tmp,cellIdsSol1=mesh3D.buildSlice3D([0.,0.,(zLev[1]+zLev[2])/2],[0.,0.,1.],1e-12)
-* Using Barycenter of cells of mesh3D :
+* Using Barycenter of cells of mesh3D :
Firstly, compute the barycenters of the 3D cells. Then select the 2nd component of the barycenter of the cells.
Finally select the tuple ids (corresponding to cell ids) falling in the range [zLev[1],zLev[2]]. ::
- bary=mesh3D.getBarycenterAndOwner()
- baryZ=bary[:,2]
- cellIdsSol2=baryZ.getIdsInRange(zLev[1],zLev[2])
+ bary=mesh3D.getBarycenterAndOwner()
+ baryZ=bary[:,2]
+ cellIdsSol2=baryZ.getIdsInRange(zLev[1],zLev[2])
* Using MEDCouplingExtrudedMesh :
Let's begin with the build of the 2D mesh. We build it from all the nodes on a plane going through point [0.,0.,zLev[0]] and with normal vector [0.,0.,1.] (MEDCouplingUMesh.findNodesOnPlane()).
Then invoke MEDCouplingUMesh.buildFacePartOfMySelfNode to build mesh2D (read the documentation of buildFacePartOfMySelfNode()). ::
- nodeIds=mesh3D.findNodesOnPlane([0.,0.,zLev[0]],[0.,0.,1.],1e-10)
- mesh2D=mesh3D.buildFacePartOfMySelfNode(nodeIds,True)
+ nodeIds=mesh3D.findNodesOnPlane([0.,0.,zLev[0]],[0.,0.,1.],1e-10)
+ mesh2D=mesh3D.buildFacePartOfMySelfNode(nodeIds,True)
Then it is possible to compute an extrusion from mesh3D and mesh2D. ::
- extMesh=MEDCouplingExtrudedMesh.New(mesh3D,mesh2D,0)
+ extMesh=MEDCouplingExtrudedMesh.New(mesh3D,mesh2D,0)
Then simply request the 2nd row. ::
- cellIdsSol3=extMesh.getMesh3DIds()[mesh2D.getNumberOfCells():2*mesh2D.getNumberOfCells()]
+ cellIdsSol3=extMesh.getMesh3DIds()[mesh2D.getNumberOfCells():2*mesh2D.getNumberOfCells()]
It is now possible to check that the 3 solutions are the same : ::
- for i in xrange(3):
- exec("print cellIdsSol%s.getValues()"%(i+1))
+ for i in xrange(3):
+ exec("print cellIdsSol%s.getValues()"%(i+1))
Extract a sub-part of mesh3D
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the previously retrieved cell ids in cellIdsSol2 to compute a sub-part of mesh3D. ::
- mesh3DPart=mesh3D[cellIdsSol2] # equivalent to mesh3DPart=mesh3D.buildPartOfMySelf(cellIdsSol2,True)
+ mesh3DPart=mesh3D[cellIdsSol2] # equivalent to mesh3DPart=mesh3D.buildPartOfMySelf(cellIdsSol2,True)
.. note:: The geometrical type doesn't play any role here. "mesh3DPart" now contains len(cellIdsSol2) cells. The cell #0 in "mesh3DPart" corresponds to the cell #cellIdsSol2[0] in "mesh3D" and so on ... "cellIdsSol2" can thus be seen as an array "new-to-old".
At this point, "mesh3DPart" lies on the same coordinates, so mesh3DPart has 60 nodes whereas only 30 are necessary. To zip the orphan nodes in "mesh3DPart", simply invoke zipCoords(): ::
- mesh3DPart.zipCoords()
+ mesh3DPart.zipCoords()
At this point mesh3DPart only contains 30 nodes and 6 cells. To prepare to MED file I/O we have to check if mesh3DPart is ready to be written safely into a MED file (i.e. if the cells are indeed ordered by type). ::
- print mesh3DPart.checkConsecutiveCellTypesAndOrder([NORM_HEXA8,NORM_POLYHED])
+ print mesh3DPart.checkConsecutiveCellTypesAndOrder([NORM_HEXA8,NORM_POLYHED])
Or: ::
- print mesh3DPart.checkConsecutiveCellTypes()
+ print mesh3DPart.checkConsecutiveCellTypes()
You can also print the content of the mesh "mesh3Dpart": ::
- print mesh3DPart.advancedRepr()
+ print mesh3DPart.advancedRepr()
We see that mesh3DPart contains 6 cells, 4 HEXA8 then 2 POLYHED. Everything's OK: the cells are grouped by geometrical type.
There are 2 solutions to do that.
-* using the barycenters of mesh3D again: same principle than above. ::
+* using the barycenters of mesh3D again: same principle than above. ::
- baryXY=bary[:,[0,1]]
- baryXY-=[250.,150.]
- magn=baryXY.magnitude()
- cellIds2Sol1=magn.getIdsInRange(0.,1e-12)
+ baryXY=bary[:,[0,1]]
+ baryXY-=[250.,150.]
+ magn=baryXY.magnitude()
+ cellIds2Sol1=magn.getIdsInRange(0.,1e-12)
* using extrusion extMesh: starting from the unique cell in mesh2D whose center is at [250.,150.,0.] MEDCouplingExtrudedMesh.getMesh3DIds retrieves the cell IDs sorted by slice. ::
- bary2=mesh2D.getBarycenterAndOwner()[:,[0,1]]
- bary2-=[250.,150.]
- magn=bary2.magnitude()
- ids=magn.getIdsInRange(0.,1e-12)
- idStart=int(ids) # ids is assumed to contain only one value, if not an exception is thrown
- cellIds2Sol2=extMesh.getMesh3DIds()[range(idStart,mesh3D.getNumberOfCells(),mesh2D.getNumberOfCells())]
+ bary2=mesh2D.getBarycenterAndOwner()[:,[0,1]]
+ bary2-=[250.,150.]
+ magn=bary2.magnitude()
+ ids=magn.getIdsInRange(0.,1e-12)
+ idStart=int(ids) # ids is assumed to contain only one value, if not an exception is thrown
+ cellIds2Sol2=extMesh.getMesh3DIds()[range(idStart,mesh3D.getNumberOfCells(),mesh2D.getNumberOfCells())]
Now, build the sub-part of mesh3D using cell IDs in cellIds2Sol1. ::
- mesh3DSlice2=mesh3D[cellIds2Sol1]
- mesh3DSlice2.zipCoords()
+ mesh3DSlice2=mesh3D[cellIds2Sol1]
+ mesh3DSlice2.zipCoords()
Duplicate "mesh3DSlice2" and translate it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Perform a deep copy of mesh3DSlice2. On this copy perform a translation v=[0.,1000.,0.].
Then aggregate mesh3DSlice2 with its translated copy, using MEDCouplingUMesh.MergeUMeshes. ::
- mesh3DSlice2bis=mesh3DSlice2.deepCpy()
- mesh3DSlice2bis.translate([0.,1000.,0.])
- mesh3DSlice2All=MEDCouplingUMesh.MergeUMeshes([mesh3DSlice2,mesh3DSlice2bis])
+ mesh3DSlice2bis=mesh3DSlice2.deepCpy()
+ mesh3DSlice2bis.translate([0.,1000.,0.])
+ mesh3DSlice2All=MEDCouplingUMesh.MergeUMeshes([mesh3DSlice2,mesh3DSlice2bis])
-.. note:: My apologies for the name of the method MEDCouplingUMesh.MergeUMeshes. In Salome 7 it will be called AggregateUMeshes. For information, to merge two (or more) unstructured meshes, one has to invoke MergeUMeshes(), then mergeNodes() on the result, and finally zipConnectivity().
+.. note:: My apologies for the name of the method MEDCouplingUMesh.MergeUMeshes. In future version it will be called AggregateUMeshes. For information, to merge two (or more) unstructured meshes, one has to invoke MergeUMeshes(), then mergeNodes() on the result, and finally zipConnectivity().
Descending connectivity
A face from "mesh3DSurf" is said to be internal if and only if it is shared by more than one 3D cell in "mesh3D" (see reverse descending connectivity (out parameter 3 et 4)). ::
- mesh3DSurf,desc,descIndx,revDesc,revDescIndx=mesh3D.buildDescendingConnectivity()
- numberOf3DCellSharing=revDescIndx.deltaShiftIndex()
- cellIds=numberOf3DCellSharing.getIdsNotEqual(1)
- mesh3DSurfInside=mesh3DSurf[cellIds]
- mesh3DSurfInside.writeVTK("mesh3DSurfInside.vtu")
-
+ mesh3DSurf,desc,descIndx,revDesc,revDescIndx=mesh3D.buildDescendingConnectivity()
+ numberOf3DCellSharing=revDescIndx.deltaShiftIndex()
+ cellIds=numberOf3DCellSharing.getIdsNotEqual(1)
+ mesh3DSurfInside=mesh3DSurf[cellIds]
+ mesh3DSurfInside.writeVTK("mesh3DSurfInside.vtu")
+
.. image:: images/mesh3DSurfInside.jpg
Solution
# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
#
-SALOME_CONFIGURE_FILE(Doxyfile_med_user.in Doxyfile_med_user)
-SALOME_CONFIGURE_FILE(static/header.html.in static/header.html)
+CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile_med_user.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile_med_user)
+CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/static/header.html.in ${CMAKE_CURRENT_BINARY_DIR}/static/header.html)
-
-IF(SALOME_MED_ENABLE_PYTHON)
- INCLUDE(doxy2swig/doxy2swig.cmake)
+IF(MEDCOUPLING_MED_ENABLE_PYTHON)
+ INCLUDE(doxy2swig/doxy2swig.cmake)
FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}/tmp/medcouplingexamples.in" input)
FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/BuildPyExamplesFromCPP.py" pythondocexamplesgenerator)
FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}" output)
-
+
# :TRICKY: For ease of maintenance, documentation for code examples is
# splitted in several files. We here splice to a single file before running
# Doxygen.
VERBATIM
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
-
+
# Create dummy target gathering the generation of all .i files:
ADD_CUSTOM_TARGET(swig_ready)
ADD_DEPENDENCIES(swig_ready usr_docs)
-
- SALOME_MED_SWIG_DOCSTRING_CONFIGURE(usr_docs swig_ready MEDCoupling)
- SALOME_MED_SWIG_DOCSTRING_CONFIGURE(usr_docs swig_ready MEDLoader)
-
+
+ MEDCOUPLING_MED_SWIG_DOCSTRING_CONFIGURE(usr_docs swig_ready MEDCoupling)
+ MEDCOUPLING_MED_SWIG_DOCSTRING_CONFIGURE(usr_docs swig_ready MEDLoader)
+
SET(doxyfile_med_user ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile_med_user)
FILE(STRINGS ${doxyfile_med_user} enabled_sections REGEX "ENABLED_SECTIONS")
IF(enabled_sections)
STRING(REPLACE ${enabled_sections} "${enabled_sections} ENABLE_EXAMPLES" new_doxy_file ${doxy_file})
FILE(WRITE ${doxyfile_med_user} ${new_doxy_file})
ELSE()
- FILE(APPEND ${doxyfile_med_user}
+ FILE(APPEND ${doxyfile_med_user}
"#Temporary variable to enable python documentation sections\nENABLED_SECTIONS = ENABLE_EXAMPLES")
ENDIF()
-
+
# Swig generation to have docstrings correctly populated:
INCLUDE(doxy2swig/doxy2swig.cmake)
-
+
ELSE()
ADD_CUSTOM_TARGET(usr_docs ALL
COMMAND ${DOXYGEN_EXECUTABLE} Doxyfile_med_user
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
ENDIF()
-
+
#INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target usr_docs)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doc_ref_user/html/ DESTINATION ${SALOME_INSTALL_DOC}/gui/MED)
-INSTALL(FILES images/head.png DESTINATION ${SALOME_INSTALL_DOC}/gui/MED)
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doc_ref_user/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED)
+INSTALL(FILES images/head.png DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED)
SET(MAKE_CLEAN_FILES doc_ref_user tmp)
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${MAKE_CLEAN_FILES}")
# General configuration options
#---------------------------------------------------------------------------
#
-PROJECT_NAME = "SALOME MED Users' Guide"
+PROJECT_NAME = "MEDCoupling Users' Guide"
PROJECT_NUMBER =
OUTPUT_DIRECTORY = doc_ref_user
OUTPUT_LANGUAGE = English
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference/cpp \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference/distrib \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference/misc \
- @CMAKE_CURRENT_SOURCE_DIR@/doxfiles/examples/examples.dox \
+ @CMAKE_CURRENT_SOURCE_DIR@/doxfiles/examples/examples.dox \
@CMAKE_CURRENT_BINARY_DIR@/medcouplingexamplesPY.dox \
@CMAKE_CURRENT_BINARY_DIR@/medcouplingexamplesCPP.dox \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/appendix \
@PROJECT_SOURCE_DIR@/src/INTERP_KERNEL/Geometric2D \
@PROJECT_SOURCE_DIR@/src/MEDCoupling \
@PROJECT_SOURCE_DIR@/src/MEDLoader \
- @PROJECT_SOURCE_DIR@/src/MEDCouplingCorba
+ @PROJECT_SOURCE_DIR@/src/MEDCouplingCorba
FILE_PATTERNS = InterpKernelDEC.* \
OverlapDEC.* \
HTML_OUTPUT = html
HTML_HEADER = @CMAKE_CURRENT_BINARY_DIR@/static/header.html
HTML_FOOTER = @CMAKE_CURRENT_SOURCE_DIR@/static/footer.html
-HTML_EXTRA_STYLESHEET = @CMAKE_CURRENT_SOURCE_DIR@/static/salome_extra.css
+HTML_EXTRA_STYLESHEET = @CMAKE_CURRENT_SOURCE_DIR@/static/medcoupling_extra.css
GENERATE_HTMLHELP = NO
GENERATE_CHI = YES
BINARY_TOC = NO
-
/*!
\page install Configuring and Installing MED from sources
-The install procedure of the %MED SALOME module can handle a variety of configurations
+The install procedure of %MEDCoupling can handle a variety of configurations
to suit the needs of its user. Instructions for configuring and
installing the module can be found here.
+Partitioning and parallel functionalities are optional.
-The libraries in SALOME MED can be configured in several manners so that it can run inside or outside the Salome platform.
-Also, partitioning and parallel functionalities are optional.
-
-The sources of the library are located in the \a MED_SRC directory.
+Assume that the library sources are located in \a MEDCOUPLING_SRC directory. Build and install directories are MEDCOUPLING_BUILD and MEDCOUPLING_INSTALL, respectively.
The first step consists in preparing the CMake build precedure :
\verbatim
-mkdir MED_BUILD
-cd ${MED_BUILD}
-cmake -DCMAKE_BUILD_TYPE=<Mode> -DCMAKE_INSTALL_PREFIX=`pwd`/../MED_INSTALL ../<MED_SRC>
+mkdir <MEDCOUPLING_BUILD>
+cd <MEDCOUPLING_BUILD>
+cmake -DCMAKE_BUILD_TYPE=<Mode> -DCMAKE_INSTALL_PREFIX=<MEDCOUPLING_INSTALL> <MEDCOUPLING_SRC>
\endverbatim
, where <Mode> is build mode (Release or Debug).
-This will create SALOME MED libraries with link to the SALOME Kernel.
-Sometimes, if it is desirable to have a standalone version of the library to be used independently from SALOME, use :
+This will configure the library without splitting functionalities. The \ref parallel "parallel functionalities" will be compiled if an MPI version has been found.
+
+The following options can be useful to configure MEDCoupling :
+- \a -DMEDCOUPLING_MED_PARTITIONER_METIS=ON enables metis graph library in MEDPartitioner,
+- \a -DMEDCOUPLING_MED_PARTITIONER_PARMETIS=ON enables parmetis graph library in MEDPartitioner,
+- \a -DMEDCOUPLING_MED_PARTITIONER_SCOTCH=ON enables scotch graph library in MEDPartitioner,
+- \a -DMEDCOUPLING_MED_MICROMED=ON build MED with MED file dependancy,
+- \a -DMEDCOUPLING_MED_ENABLE_PYTHON=ON builds PYTHON bindings,
+- \a -DMEDCOUPLING_MED_ENABLE_PARTITIONER builds MEDPartitioner,
+- \a -DMEDCOUPLING_MED_ENABLE_RENUMBER builds Renumber,
+- \a -DMEDCOUPLING_USE_MPI=ON uses MPI containers.
+
+According to set options and compilation environment, user may need to define some <prerequisite>_ROOT_DIR variables. For example if in SALOME environment:
\verbatim
-mkdir MED_BUILD
-cd ${MED_BUILD}
-cmake -DCMAKE_BUILD_TYPE=<Mode> -DCMAKE_INSTALL_PREFIX=`pwd`/../MED_INSTALL _DSALOME_MED_STANDALONE=ON ../<MED_SRC>
+export MEDFILE_ROOT_DIR=${MED3HOME}
+export METIS_ROOT_DIR=$METISDIR
+export SCOTCH_ROOT_DIR=$SCOTCHDIR
+export BOOST_ROOT_DIR=$BOOST_ROOT
+export GRAPHVIZ_ROOT_DIR=$GRAPHVIZHOME
+export CPPUNIT_ROOT_DIR=$CPPUNIT_ROOT
\endverbatim
-This will configure the library without splitting functionalities. The
-\ref parallel "parallel functionalities" will be compiled if an MPI version has been found.
-
-The following options can be useful to configure SALOME MED :
-- \a -DSALOME_MED_PARTITIONER_METIS=ON enables metis graph library in MEDPartitioner,
-- \a -DSALOME_MED_PARTITIONER_PARMETIS=ON enables parmetis graph library in MEDPartitioner,
-- \a -DSALOME_MED_PARTITIONER_SCOTCH=ON enables scotch graph library in MEDPartitioner,
-- \a -DSALOME_MED_MICROMED=ON build MED with MED file dependancy,
-- \a -DSALOME_MED_ENABLE_PYTHON=ON builds PYTHON bindings,
-- \a -DSALOME_MED_ENABLE_PARTITIONER builds MEDPartitioner,
-- \a -DSALOME_MED_ENABLE_RENUMBER builds Renumber,
-- \a -DSALOME_USE_MPI=ON uses MPI containers.
+If using MPI, the PARMETIS_ROOT_DIR variable should be set.
*/
/*!
-\page gui Graphical user interface
+\page gui Graphical user interface
<h1>A graphical interface for standard use cases</h1>
user guide can be found here:
- <a class="el" target="_new"
- href="../../dev/MED/medop-userguide-gui.html">User guide of the MED Graphical Interface</a>
+ href="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-userguide-gui.html">User guide of the MED Graphical Interface</a>
You could also be interested to read the software specifications and
requirements for this graphical module, and even the technical
considerations for development:
- <a class="el" target="_new"
- href="../../dev/MED/medop-specifications.html">Software
+ href="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-specifications.html">Software
specifications and requirements of the MED Graphical Interface (in french)</a>
- <a class="el" target="_new"
- href="../../dev/MED/medop-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
+ href="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
*/
/*!
-\mainpage Welcome to the SALOME MED module!
+\mainpage Welcome to MEDCoupling!
-The MED module gathers several powerful functionalities around the input and output data of
-simulation codes (meshes and fields mainly).
+The MED module gathers several powerful functionalities around the input and output data of
+simulation codes (meshes and fields mainly).
\image html projectionHQ_600.png "Example of a field interpolation between two 3D surfacic meshes"
The most common usage is to write dedicated code (C++ or Python) linking to the library,
however a \ref gui "graphical user interface" is also available.
-- If you don't know where to start, reading the \ref start "getting started" section and then
+- If you don't know where to start, reading the \ref start "getting started" section and then
taking a look at the <a class="el" href="tutorial/index.html">tutorial</a> is probably a good way to go.
- If you are looking for a very specific point (how can I build a mesh from scratch,
how do I write my data to a file, etc ...), taking a look at the \ref faq "FAQ" or at the numerous
- \ref examples "code examples" might help.
+ \ref examples "code examples" might help.
- Finally people looking for the reference documentation of a given function (in C++ or Python) should
take a look at the \ref ParaMEDMEM "API documentation". Only the C++ functions are documented, but
the Python API has been designed to be used in a very similar fashion, provided you are aware of the
- \ref medcouplingcppexamples
\endif
-- \ref appendix
+- \ref appendix
- \ref glossary
- \ref med-file
- \ref install
-
+
- \ref ParaMEDMEM "MEDCoupling (and other parallel classes) API documentation"
- \ref MEDLoader "MEDLoader API documentation"
## \param[in] target_swig dummy target encompassing the final build of all SWIG files
## \param[in] cls_list list of classes for which to generate SWIG files
## \param[in] swig_main_file main SWIG file including the other generated SWIG files
-## \param[out] swig_files list of generated SWIG files
+## \param[out] swig_files list of generated SWIG files
##
-MACRO(SALOME_MED_SWIG_DOCSTRING_GENERATE target_doc target_swig cls_list swig_main_file swig_files)
+MACRO(MEDCOUPLING_MED_SWIG_DOCSTRING_GENERATE target_doc target_swig cls_list swig_main_file swig_files)
# List of generated SWIG files (.i) for doc purposes only:
SET(${swig_files})
FOREACH(_cls IN LISTS ${cls_list})
SET(_xml_file "${CMAKE_CURRENT_BINARY_DIR}/../doxygen/doc_ref_user/xml/class${_cls}.xml")
SET(_swig_file_base "${_SWIG_DOC_SUFFIX}${_cls}.i")
SET(_swig_file "${PROJECT_BINARY_DIR}/doc/${_swig_file_base}" )
-
+
# SWIG doc files will always be generated *after* Doxygen is run:
### WARNING: ADD_CUSTOM_COMMAND(TARGET xxx POST_BUILD ...) command
### must be in exactly the same subdir as the initial target construction command.
### That's why this file is included with an INCLUDE() rather than using ADD_SUBDIRECTORY
- # Note: we touch the main .i file to be sure to retrigger swig when the doc in a included
- # class changes.
+ # Note: we touch the main .i file to be sure to retrigger swig when the doc in a included
+ # class changes.
ADD_CUSTOM_COMMAND(OUTPUT ${_swig_file}
COMMAND ${PYTHON_EXECUTABLE} ${_DOXY2SWIG} "-n" ${_xml_file} ${_swig_file}
COMMAND ${CMAKE_COMMAND} -E touch_nocreate ${swig_main_file}
ADD_CUSTOM_TARGET(${_swig_file_base} DEPENDS ${_swig_file})
# The doxy2swig script is executed once the doxygen documentation has been generated ...
ADD_DEPENDENCIES(${_swig_file_base} ${target_doc})
- # ... and the meta target 'swig_ready' (here ${target_swig}) is ready when all .i files
+ # ... and the meta target 'swig_ready' (here ${target_swig}) is ready when all .i files
# have been generated:
ADD_DEPENDENCIES(${target_swig} ${_swig_file_base})
-
+
LIST(APPEND ${swig_files} ${_swig_file_base})
ENDFOREACH()
-ENDMACRO(SALOME_MED_SWIG_DOCSTRING_GENERATE)
+ENDMACRO(MEDCOUPLING_MED_SWIG_DOCSTRING_GENERATE)
##
## \param[in] target_doc main target for the stantard doxygen generation
## \param[in] target_swig dummy target encompassing the final build of all SWIG files
## \param[in] root_name either 'MEDCoupling' or 'MEDLoader'
-##
-MACRO(SALOME_MED_SWIG_DOCSTRING_CONFIGURE target_doc target_swig root_name)
+##
+MACRO(MEDCOUPLING_MED_SWIG_DOCSTRING_CONFIGURE target_doc target_swig root_name)
SET(_all_swig_docs)
SET(_swig_include_set)
SET(_in_file doxy2swig/${root_name}_doc.i.in)
SET(_out_file ${PROJECT_BINARY_DIR}/doc/${root_name}_doc.i)
- SALOME_MED_SWIG_DOCSTRING_GENERATE(${target_doc} ${target_swig} _classes_${root_name} ${_out_file} _all_swig_docs)
+ MEDCOUPLING_MED_SWIG_DOCSTRING_GENERATE(${target_doc} ${target_swig} _classes_${root_name} ${_out_file} _all_swig_docs)
FOREACH(f IN LISTS _all_swig_docs)
SET(_swig_include_set "${_swig_include_set}\n%include \"${f}\"")
ENDFOREACH()
CONFIGURE_FILE(${_in_file} ${_out_file} @ONLY)
-ENDMACRO(SALOME_MED_SWIG_DOCSTRING_CONFIGURE)
-
+ENDMACRO(MEDCOUPLING_MED_SWIG_DOCSTRING_CONFIGURE)
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
-<div id="titlearea"><div align="right"><div class="version">Version: @SALOMEMED_VERSION@</div></div></div>
+<div id="titlearea"><div align="right"><div class="version">Version: @MEDCOUPLING_VERSION@</div></div></div>
<!-- end header part -->
--- /dev/null
+/* The extra CSS for doxygen 1.8.3.1 */
+
+#titlearea {
+ background-image:url('head.png');
+ background-color: #175783;
+ border: 1px solid;
+ height: 80px;
+ background-repeat: no-repeat;
+ padding: 0px;
+ margin: 0px;
+ width: 99.9%;
+ border-bottom: 1px solid #5373B4;
+}
+
+div.version {
+ border:1px solid #0000FF;
+ color: #CCCCCC;
+ font-family: Arial, Helvetica, sans-serif;
+ font-size: 9pt;
+ text-align: center;
+ width:100px;
+ -moz-border-radius: 8px;
+ margin: 5px;
+}
+
+.navpath li.footer {
+ line-height:15px;
+ text-align: right;
+}
\ No newline at end of file
+++ /dev/null
-/* The extra CSS for doxygen 1.8.3.1 */
-
-#titlearea {
- background-image:url('head.png');
- background-color: #175783;
- border: 1px solid;
- height: 80px;
- background-repeat: no-repeat;
- padding: 0px;
- margin: 0px;
- width: 99.9%;
- border-bottom: 1px solid #5373B4;
-}
-
-div.version {
- border:1px solid #0000FF;
- color: #CCCCCC;
- font-family: Arial, Helvetica, sans-serif;
- font-size: 9pt;
- text-align: center;
- width:100px;
- -moz-border-radius: 8px;
- margin: 5px;
-}
-
-.navpath li.footer {
- line-height:15px;
- text-align: right;
-}
\ No newline at end of file
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-INCLUDE(UseOmniORB)
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}
-)
-
-SET(SalomeIDLMED_IDLSOURCES
- MEDCouplingCorbaServant.idl
- ParaMEDCouplingCorbaServant.idl
- MEDDataManager.idl
- MEDCalculator.idl
- MEDEventListener.idl
- MEDOPFactory.idl
-)
-
-IF(SALOME_USE_MPI)
- SET(SalomeIDLMED_IDLSOURCES ${SalomeIDLMED_IDLSOURCES} ParaMEDMEMComponent.idl)
-ENDIF(SALOME_USE_MPI)
-
-SET(SalomeIDLMEDTests_IDLSOURCES
- MEDCouplingCorbaServantTest.idl
-)
-
-SET(_idl_include_dirs
- ${CMAKE_CURRENT_SOURCE_DIR}
- ${KERNEL_ROOT_DIR}/idl/salome
-)
-
-SET(_idl_link_flags
- ${KERNEL_SalomeIDLKernel}
-)
-
-OMNIORB_ADD_MODULE(SalomeIDLMED "${SalomeIDLMED_IDLSOURCES}" "${_idl_include_dirs}" "${_idl_link_flags}")
-OMNIORB_ADD_MODULE(SalomeIDLMEDTests "${SalomeIDLMEDTests_IDLSOURCES}" "${_idl_include_dirs}" "SalomeIDLMED")
-
-INSTALL(TARGETS SalomeIDLMED EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
-INSTALL(TARGETS SalomeIDLMEDTests DESTINATION ${SALOME_INSTALL_LIBS})
#
SET(MED_RESOURCES_FILES
- boitenew.cnc
- boitenew.inp
- boitenew.xyz
- Case1.cnc
- Case1.inp
- Case1.xyz
- cube.cnc
- cube.inp
- cube.xyz
- test3.cnc
- test3.inp
- test3.xyz
- titi.cnc
- titi.inp
- titi.xyz
- carre_en_quad4.med
- carre_en_quad4_seg2.med
- cas_defaut_domaine_fluide.med
- ChampsDarcy.med
- cube_hexa8.med
- cube_hexa8_quad4.med
- darcy_1.1_res.med
- darcy_1.3_resCASTEM.med
- darcy_1.3_resPORFLOW.med
- darcy_1.3_resTRACES.med
- darcy2_Castem_EFMH.med
- darcy2_Castem_qua_EFMH.med
- darcy2_Castem_qua_VF.med
- Darcy3_3D_H_10x10x10_2.med
- Darcy3_3D_H_10x10x10.sauve
- dx200_dy1_avec_2couches.sauve
- elle_2D_QT_10x10.sauve
- elle_2D_QT_2x2.sauve
- elle_2D_QT_40x40.sauve
- elle_2D_QT_4x4.sauve
- elle_3D_HPr_10x10x10_2.med
- elle_3D_HPr_10x10x10.sauve
- elle_3D_HPr_2x2x2_2.med
- elle_3D_HPr_2x2x2.sauve
- elle_3D_HPr_4x4x4_2.med
- elle_3D_HPr_4x4x4.sauve
- extendedtransport53_triangles.med
- geomMesh_nomorereadable21.med
- geomMesh22.med
- H_CastCast_EFMH_I129_COUPLEX1.med
- H_CastCast_VF_I129_COUPLEX1.med
- H_CastCast_VF_Se79_COUPLEX1.med
- H_CastPorf_I129_COUPLEX1.med
- H_CastPorf_Se79_COUPLEX1.med
- H_PorfCast_EFMH_I129_COUPLEX1.med
- H_PorfCast_EFMH_Se79_COUPLEX1.med
- H_PorfPorf_I129_COUPLEX1.med
- H_Traces_I129_COUPLEX1.med
- H_Traces_Se79_COUPLEX1.med
- inclusion_2d_raf.sauve
- inclusion_2d.sauve
- mail_ktest1-3-hexa.sauve
- mail_ktest1-3-tetra.sauve
- mail_ktest3-1.sauve
- mail_ktest3-2.sauve
- maill.00.med
- maill.00_nofield.med
- maill.00_nomesh.med
- maill.00_without_seg2.med
- maill.0.med
- maillage_5_5_5.med
- maillage_andra2_100elts.sauve
- maillage_cas2_2d.sauve
- maillage_cas4_234elts.sauve
- maillage_CHEMVAL_100elts.sauve
- maillage_CHEMVAL_40elts.sauve
- maillage_chemvalIV_cas1_100elts.sauve
- maillage_chemvalIV_cas1_40elts.med
- maillage_chemvalIV_cas1_40elts.sauve
- maillage_UniSegFam.med
- mail_test1-1-qua.sauve
- mail_test1-1-tri.sauve
- mail_test1-2-qua.sauve
- mail_test1-2-tri.sauve
- mail-test1-4-1.sauve
- mail-test1-4-2.sauve
- mesh_nomorereadable21.med
- mesh.med
- Mistrat.med
- Old_ChampsDarcy.med
- Old_darcy_1.1_res.med
- Old_darcy_1.3_resCASTEM.med
- Old_darcy_1.3_resPORFLOW.med
- Old_darcy_1.3_resTRACES.med
- Old_darcy2_Castem_EFMH.med
- Old_darcy2_Castem_qua_EFMH.med
- Old_darcy2_Castem_qua_VF.med
- Old_H_CastCast_EFMH_I129_COUPLEX1.med
- Old_H_CastCast_VF_I129_COUPLEX1.med
- Old_H_CastCast_VF_Se79_COUPLEX1.med
- Old_H_CastPorf_I129_COUPLEX1.med
- Old_H_CastPorf_Se79_COUPLEX1.med
- Old_H_PorfCast_EFMH_I129_COUPLEX1.med
- Old_H_PorfCast_EFMH_Se79_COUPLEX1.med
- Old_H_PorfPorf_I129_COUPLEX1.med
- Old_H_PorfPorf_Se79_COUPLEX1.med
- Old_H_Traces_I129_COUPLEX1.med
- Old_H_Traces_Se79_COUPLEX1.med
- Old_maillage_chemvalIV_cas1_40elts.med
- pointe_nomorereadable21.med
+ #boitenew.cnc
+ #boitenew.inp
+ #boitenew.xyz
+ #Case1.cnc
+ #Case1.inp
+ #Case1.xyz
+ #cube.cnc
+ #cube.inp
+ #cube.xyz
+ #test3.cnc
+ #test3.inp
+ #test3.xyz
+ #titi.cnc
+ #titi.inp
+ #titi.xyz
+ #carre_en_quad4.med
+ #carre_en_quad4_seg2.med
+ #cas_defaut_domaine_fluide.med
+ #ChampsDarcy.med
+ #cube_hexa8.med
+ #cube_hexa8_quad4.med
+ #darcy_1.1_res.med
+ #darcy_1.3_resCASTEM.med
+ #darcy_1.3_resPORFLOW.med
+ #darcy_1.3_resTRACES.med
+ #darcy2_Castem_EFMH.med
+ #darcy2_Castem_qua_EFMH.med
+ #darcy2_Castem_qua_VF.med
+ #Darcy3_3D_H_10x10x10_2.med
+ #Darcy3_3D_H_10x10x10.sauve
+ #dx200_dy1_avec_2couches.sauve
+ #elle_2D_QT_10x10.sauve
+ #elle_2D_QT_2x2.sauve
+ #elle_2D_QT_40x40.sauve
+ #elle_2D_QT_4x4.sauve
+ #elle_3D_HPr_10x10x10_2.med
+ #elle_3D_HPr_10x10x10.sauve
+ #elle_3D_HPr_2x2x2_2.med
+ #elle_3D_HPr_2x2x2.sauve
+ #elle_3D_HPr_4x4x4_2.med
+ #elle_3D_HPr_4x4x4.sauve
+ #extendedtransport53_triangles.med
+ #geomMesh_nomorereadable21.med
+ #geomMesh22.med
+ #H_CastCast_EFMH_I129_COUPLEX1.med
+ #H_CastCast_VF_I129_COUPLEX1.med
+ #H_CastCast_VF_Se79_COUPLEX1.med
+ #H_CastPorf_I129_COUPLEX1.med
+ #H_CastPorf_Se79_COUPLEX1.med
+ #H_PorfCast_EFMH_I129_COUPLEX1.med
+ #H_PorfCast_EFMH_Se79_COUPLEX1.med
+ #H_PorfPorf_I129_COUPLEX1.med
+ #H_Traces_I129_COUPLEX1.med
+ #H_Traces_Se79_COUPLEX1.med
+ # inclusion_2d_raf.sauve
+ # inclusion_2d.sauve
+ # mail_ktest1-3-hexa.sauve
+ # mail_ktest1-3-tetra.sauve
+ # mail_ktest3-1.sauve
+ # mail_ktest3-2.sauve
+ # maill.00.med
+ # maill.00_nofield.med
+ # maill.00_nomesh.med
+ # maill.00_without_seg2.med
+ # maill.0.med
+ # maillage_5_5_5.med
+ # maillage_andra2_100elts.sauve
+ # maillage_cas2_2d.sauve
+ # maillage_cas4_234elts.sauve
+ # maillage_CHEMVAL_100elts.sauve
+ # maillage_CHEMVAL_40elts.sauve
+ # maillage_chemvalIV_cas1_100elts.sauve
+ # maillage_chemvalIV_cas1_40elts.med
+ # maillage_chemvalIV_cas1_40elts.sauve
+ # maillage_UniSegFam.med
+ # mail_test1-1-qua.sauve
+ # mail_test1-1-tri.sauve
+ # mail_test1-2-qua.sauve
+ # mail_test1-2-tri.sauve
+ # mail-test1-4-1.sauve
+ # mail-test1-4-2.sauve
+ # mesh_nomorereadable21.med
+ # mesh.med
+ # Mistrat.med
+ #Old_ChampsDarcy.med
+ #Old_darcy_1.1_res.med
+ #Old_darcy_1.3_resCASTEM.med
+ #Old_darcy_1.3_resPORFLOW.med
+ #Old_darcy_1.3_resTRACES.med
+ #Old_darcy2_Castem_EFMH.med
+ #Old_darcy2_Castem_qua_EFMH.med
+ #Old_darcy2_Castem_qua_VF.med
+ #Old_H_CastCast_EFMH_I129_COUPLEX1.med
+ #Old_H_CastCast_VF_I129_COUPLEX1.med
+ #Old_H_CastCast_VF_Se79_COUPLEX1.med
+ #Old_H_CastPorf_I129_COUPLEX1.med
+ #Old_H_CastPorf_Se79_COUPLEX1.med
+ #Old_H_PorfCast_EFMH_I129_COUPLEX1.med
+ #Old_H_PorfCast_EFMH_Se79_COUPLEX1.med
+ #Old_H_PorfPorf_I129_COUPLEX1.med
+ #Old_H_PorfPorf_Se79_COUPLEX1.med
+ #Old_H_Traces_I129_COUPLEX1.med
+ #Old_H_Traces_Se79_COUPLEX1.med
+ #Old_maillage_chemvalIV_cas1_40elts.med
+ #pointe_nomorereadable21.med
pointe.med
poly3D.med
- polyedres.med
+ #polyedres.med
polygones.med
- recoll_bord.med
- test19.med
- test_2D.med
- trio_2D.med
- TimeStamps.med
- zzzz121b.med
- zzzz121b_without_tr6.med
+ #recoll_bord.med
+ #test19.med
+ # test_2D.med
+ # trio_2D.med
+ # TimeStamps.med
+ # zzzz121b.med
+ # zzzz121b_without_tr6.med
UnitTetra.med
GeneralTetra.med
NudgedSimpler.med
GenTetra2.med
TrickyTetra1.med
LargeUnitTetra.med
- LargeInconsistentTetra.med
+ # LargeInconsistentTetra.med
DividedUnitTetraSimpler.med
DividedUnitTetra.med
NudgedDividedUnitTetra.med
square2_split
square2_split1.med
square2_split2.med
- testStructCart3D.med
+ # testStructCart3D.med
Mesh3D_10_2d1.med
Mesh3D_10_2d2.med
Mesh3D_11.med
Pol2.fig
Pol3.fig
Pol4.fig
- blow5_ascii.case
- blow5_ascii.geo
- blow5_ascii_cd_displacement
- blow5_ascii_cd_thickness
- blow5_ascii_pd_displacement
- blow5_ascii_pd_thickness
- test_2D.sauve
+ # blow5_ascii.case
+ # blow5_ascii.geo
+ # blow5_ascii_cd_displacement
+ # blow5_ascii_cd_thickness
+ # blow5_ascii_pd_displacement
+ # blow5_ascii_pd_thickness
+ #test_2D.sauve
allPillesTest.sauv
BDC-714.sauv
portico_3subs.sauv
agitateur.med
)
-IF(MED_ENABLE_GUI)
- FILE(GLOB MED_RESOURCES_PNG "${CMAKE_CURRENT_SOURCE_DIR}/*.png")
- SET(MED_RESOURCES_FILES
- ${MED_RESOURCES_FILES}
- ModuleMed.png
- Data.png
- Infos.png
- Structure.png
- explore_med_file.png
- field_selection.png
- med_mesh.png
- med_field.png
- mesh_selection.png
- )
-ENDIF(MED_ENABLE_GUI)
+# IF(MED_ENABLE_GUI)
+# FILE(GLOB MED_RESOURCES_PNG "${CMAKE_CURRENT_SOURCE_DIR}/*.png")
+# SET(MED_RESOURCES_FILES
+# ${MED_RESOURCES_FILES}
+# ModuleMed.png
+# Data.png
+# Infos.png
+# Structure.png
+# explore_med_file.png
+# field_selection.png
+# med_mesh.png
+# med_field.png
+# mesh_selection.png
+# )
+# ENDIF(MED_ENABLE_GUI)
-INSTALL(FILES ${MED_RESOURCES_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
+FOREACH(resfile ${MED_RESOURCES_FILES})
+ CONFIGURE_FILE("${CMAKE_CURRENT_SOURCE_DIR}/${resfile}" "${CMAKE_CURRENT_BINARY_DIR}/${resfile}" COPYONLY)
+ENDFOREACH(resfile)
-MESSAGE(STATUS "Creation of ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml")
-CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/MEDCatalog.xml.in ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml @ONLY)
-MESSAGE(STATUS "Creation of ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml")
-CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/SalomeApp.xml.in ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml @ONLY)
+INSTALL(FILES ${MED_RESOURCES_FILES} DESTINATION ${MEDCOUPLING_INSTALL_RES_DATA})
-INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
+#MESSAGE(STATUS "Creation of ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml")
+#CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/MEDCatalog.xml.in ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml @ONLY)
+#MESSAGE(STATUS "Creation of ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml")
+#CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/SalomeApp.xml.in ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml @ONLY)
+
+#INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDCatalog.xml ${CMAKE_CURRENT_BINARY_DIR}/SalomeApp.xml DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
+# Copyright (C) 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 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_ENABLE_MICROMED ${MEDCOUPLING_MED_MICROMED})
ADD_SUBDIRECTORY(INTERP_KERNEL)
+IF(MEDCOUPLING_BUILD_TESTS)
+ ADD_SUBDIRECTORY(INTERP_KERNELTest)
+ENDIF(MEDCOUPLING_BUILD_TESTS)
ADD_SUBDIRECTORY(MEDCoupling)
-IF(SALOME_MED_ENABLE_PYTHON)
+IF(MEDCOUPLING_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(MEDCoupling_Swig)
-ENDIF(SALOME_MED_ENABLE_PYTHON)
+ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
-IF(NOT SALOME_MED_MICROMED)
+IF(NOT MEDCOUPLING_MED_MICROMED)
ADD_SUBDIRECTORY(MEDLoader)
- IF(SALOME_MED_ENABLE_RENUMBER)
+ IF(MEDCOUPLING_MED_ENABLE_RENUMBER)
ADD_SUBDIRECTORY(RENUMBER)
- IF(SALOME_MED_ENABLE_PYTHON)
+ IF(MEDCOUPLING_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(RENUMBER_Swig)
- ENDIF(SALOME_MED_ENABLE_PYTHON)
- ENDIF(SALOME_MED_ENABLE_RENUMBER)
- IF(SALOME_MED_ENABLE_PARTITIONER)
+ ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
+ ENDIF(MEDCOUPLING_MED_ENABLE_RENUMBER)
+ IF(MEDCOUPLING_MED_ENABLE_PARTITIONER)
ADD_SUBDIRECTORY(MEDPartitioner)
- IF(SALOME_MED_ENABLE_PYTHON)
+ IF(MEDCOUPLING_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(MEDPartitioner_Swig)
- ENDIF(SALOME_MED_ENABLE_PYTHON)
- ENDIF(SALOME_MED_ENABLE_PARTITIONER)
- IF(SALOME_BUILD_TESTS)
- ADD_SUBDIRECTORY(INTERP_KERNELTest)
- ENDIF(SALOME_BUILD_TESTS)
-ENDIF(NOT SALOME_MED_MICROMED)
+ ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
+ ENDIF(MEDCOUPLING_MED_ENABLE_PARTITIONER)
+ENDIF(NOT MEDCOUPLING_MED_MICROMED)
-IF(SALOME_USE_MPI)
+IF(MEDCOUPLING_USE_MPI)
ADD_SUBDIRECTORY(ParaMEDMEM)
- IF(NOT SALOME_MED_MICROMED)
+ IF(NOT MEDCOUPLING_MED_MICROMED)
ADD_SUBDIRECTORY(ParaMEDLoader)
- ENDIF(NOT SALOME_MED_MICROMED)
- IF(NOT SALOME_MED_STANDALONE)
- ADD_SUBDIRECTORY(ParaMEDCouplingCorba)
- ADD_SUBDIRECTORY(ParaMEDMEMComponent)
- ENDIF(NOT SALOME_MED_STANDALONE)
- IF(SALOME_MED_ENABLE_PYTHON)
+ ENDIF(NOT MEDCOUPLING_MED_MICROMED)
+ IF(MEDCOUPLING_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(ParaMEDMEM_Swig)
- ENDIF(SALOME_MED_ENABLE_PYTHON)
- IF(SALOME_BUILD_TESTS)
- IF(NOT SALOME_MED_MICROMED)
+ ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
+ IF(MEDCOUPLING_BUILD_TESTS)
+ IF(NOT MEDCOUPLING_MED_MICROMED)
ADD_SUBDIRECTORY(ParaMEDMEMTest)
- ENDIF(NOT SALOME_MED_MICROMED)
- ENDIF(SALOME_BUILD_TESTS)
-ENDIF(SALOME_USE_MPI)
-
-IF(NOT SALOME_MED_STANDALONE)
- ADD_SUBDIRECTORY(MEDCouplingCorba)
- IF(NOT SALOME_MED_MICROMED)
- ADD_SUBDIRECTORY(MEDCalculator)
- ADD_SUBDIRECTORY(MEDOP)
- ENDIF(NOT SALOME_MED_MICROMED)
- IF(SALOME_MED_ENABLE_PYTHON)
- ADD_SUBDIRECTORY(MEDCouplingCorba_Swig)
- ENDIF(SALOME_MED_ENABLE_PYTHON)
-ENDIF(NOT SALOME_MED_STANDALONE)
-
-IF(SALOME_BUILD_GUI)
- IF(NOT SALOME_MED_MICROMED)
- IF(SALOME_MED_ENABLE_PYTHON)
- #ADD_SUBDIRECTORY(MEDGUI)
- ENDIF(SALOME_MED_ENABLE_PYTHON)
- ENDIF(NOT SALOME_MED_MICROMED)
-ENDIF(SALOME_BUILD_GUI)
+ ENDIF(NOT MEDCOUPLING_MED_MICROMED)
+ ENDIF(MEDCOUPLING_BUILD_TESTS)
+ENDIF(MEDCOUPLING_USE_MPI)
# Application tests
INSTALL(FILES CTestTestfileInstall.cmake
- DESTINATION ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test
+ DESTINATION ${MEDCOUPLING_INSTALL_TESTS}
RENAME CTestTestfile.cmake)
INSTALL(FILES CTestTestfileInstallMEDCoupling.cmake
- DESTINATION ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling
+ DESTINATION ${MEDCOUPLING_INSTALL_TESTS}/MEDCoupling
RENAME CTestTestfile.cmake)
--- /dev/null
+# Copyright (C) 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
+#
+
+SUBDIRS(MEDCoupling)
--- /dev/null
+# Copyright (C) 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(COMPONENT_NAME MEDCOUPLING)
+
+#SUBDIRS(INTERP_KERNELTest)
+SUBDIRS(MEDCoupling)
+#SUBDIRS(MEDCoupling_Swig)
+#SUBDIRS(MEDLoader)
+#SUBDIRS(MEDLoader/Swig)
+#SUBDIRS(MEDPartitioner)
+#SUBDIRS(ParaMEDMEM_Swig)
+#SUBDIRS(ParaMEDMEMTest)
+#SUBDIRS(MEDPartitioner_Swig)
+#SUBDIRS(RENUMBER_Swig)
ADD_LIBRARY(interpkernel SHARED ${interpkernel_SOURCES})
SET_TARGET_PROPERTIES(interpkernel PROPERTIES COMPILE_FLAGS "${PLATFORM_MMAP}")
TARGET_LINK_LIBRARIES(interpkernel ${PLATFORM_LIBS})
-INSTALL(TARGETS interpkernel EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS interpkernel EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
FILE(GLOB_RECURSE interpkernel_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
FILE(GLOB_RECURSE interpkernel_HEADERS_TXX "${CMAKE_CURRENT_SOURCE_DIR}/*.txx")
-INSTALL(FILES ${interpkernel_HEADERS_HXX} ${interpkernel_HEADERS_TXX} Bases/NormalizedGeometricTypes DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${interpkernel_HEADERS_HXX} ${interpkernel_HEADERS_TXX} Bases/NormalizedGeometricTypes DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# Will be used for SWIG dependencies:
SET (interpkernel_HEADERS_HXX PARENT_SCOPE)
int pos=(int)_value;
int lgth=(int)valuesInExpr.size();
if(pos>=lgth || pos<0)
- throw INTERP_KERNEL::Exception("LeafExprVal::replaceValues : Big Problem detected ! Send expression to Salome support with expression !");
+ throw INTERP_KERNEL::Exception("LeafExprVal::replaceValues : Big Problem detected !");
_value=valuesInExpr[pos];
}
{
if(_expr[_expr.length()-1]!=')')
return ;
- //at this level of code _expr
+ //at this level of code _expr
std::size_t pos1=_expr.find_first_of('(');
std::size_t pos4=FindCorrespondingOpenBracket(_expr,_expr.length()-1);
if(pos4!=pos1)
/*!
* This method has the responsability to see if this->_expr is interpretable without any recursion.
* \return true if no recursion needed, false if this->_expr is too complex to be interpreted at this level.
- * \throw exception if this->_expr is simple enough to try to interprate this and this expression contains an error.
+ * \throw exception if this->_expr is simple enough to try to interprate this and this expression contains an error.
*/
bool ExprParser::tryToInterpALeaf()
{
)
ADD_EXECUTABLE(PerfTest ${PerfTest_SOURCES})
TARGET_LINK_LIBRARIES(PerfTest InterpKernelTest ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
- INSTALL(TARGETS PerfTest DESTINATION ${SALOME_INSTALL_BINS})
+ INSTALL(TARGETS PerfTest DESTINATION ${MEDCOUPLING_INSTALL_BINS})
ENDIF(NOT MED_ENABLE_MICROMED)
ADD_LIBRARY(InterpKernelTest SHARED ${InterpKernelTest_SOURCES})
-TARGET_LINK_LIBRARIES(InterpKernelTest medloader medcoupling interpkernel ${CPPUNIT_LIBRARIES})
+
+SET(InterpKernelTest_LIBS medcoupling interpkernel ${CPPUNIT_LIBRARIES})
+IF(NOT MED_ENABLE_MICROMED)
+ SET(InterpKernelTest_LIBS medloader ${InterpKernelTest_LIBS})
+ENDIF(NOT MED_ENABLE_MICROMED)
+TARGET_LINK_LIBRARIES(InterpKernelTest ${InterpKernelTest_LIBS})
ADD_EXECUTABLE(TestINTERP_KERNEL ${TestINTERP_KERNEL_SOURCES})
TARGET_LINK_LIBRARIES(TestINTERP_KERNEL InterpKernelTest ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestINTERP_KERNEL TestINTERP_KERNEL)
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
-SET_TESTS_PROPERTIES(TestINTERP_KERNEL PROPERTIES ENVIRONMENT "${tests_env}")
-INSTALL(TARGETS TestINTERP_KERNEL DESTINATION ${SALOME_INSTALL_BINS})
-INSTALL(TARGETS InterpKernelTest DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS TestINTERP_KERNEL DESTINATION ${MEDCOUPLING_INSTALL_BINS})
+INSTALL(TARGETS InterpKernelTest DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
+INSTALL(FILES CppUnitTest.hxx InterpKernelTestExport.hxx DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/INTERP_KERNELTest)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_TESTS}/MEDCoupling/INTERP_KERNELTest)
INSTALL(TARGETS TestINTERP_KERNEL InterpKernelTest DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
#include "VectorUtils.hxx"
-// levels :
+// levels :
// 1 - titles and volume results
// 2 - symmetry / diagonal results and intersection matrix output
// 3 - empty
double Interpolation3DTest::sumVolume(const IntersectionMatrix& m) const
{
-
+
std::vector<double> volumes;
for(IntersectionMatrix::const_iterator iter = m.begin() ; iter != m.end() ; ++iter)
{
// vol += std::abs(iter2->second);
}
}
-
+
// sum in ascending order to avoid rounding errors
sort(volumes.begin(), volumes.end());
}
return compatitable;
}
-
+
bool Interpolation3DTest::testSymmetric(const IntersectionMatrix& m1, const IntersectionMatrix& m2) const
{
{
for(std::map<int, double>::const_iterator iter2 = iter->begin() ; iter2 != iter->end() ; ++iter2)
{
-
+
std::cout << "V(" << i << ", " << iter2->first << ") = " << iter2->second << std::endl;
-
+
}
++i;
}
void Interpolation3DTest::tearDown()
{
delete interpolator;
-}
+}
void Interpolation3DTest::calcIntersectionMatrix(const char* mesh1path, const char* mesh1, const char* mesh2path, const char* mesh2, IntersectionMatrix& m) const
{
- const string dataBaseDir = getenv("MED_ROOT_DIR");
- const string dataDir = dataBaseDir + "/share/salome/resources/med/";
+ string dataDir = "";
+ if ( getenv("MEDCOUPLING_ROOT_DIR") ) {
+ dataDir = getenv("MEDCOUPLING_ROOT_DIR");
+ dataDir += "/share/resources/med/";
+ }
+ else {
+ dataDir = get_current_dir_name();
+ dataDir += "/../../resources/";
+ }
LOG(1, std::endl << "=== -> intersecting src = " << mesh1 << ", target = " << mesh2 );
LOG(5, "Loading " << mesh1 << " from " << mesh1path);
MESH sMesh(MED_DRIVER, dataDir+mesh1path, mesh1);
-
+
LOG(5, "Loading " << mesh2 << " from " << mesh2path);
MESH tMesh(MED_DRIVER, dataDir+mesh2path, mesh2);
}
LOG(1, "Intersection calculation done. " << std::endl );
-
+
}
void Interpolation3DTest::intersectMeshes(const char* mesh1path, const char* mesh1, const char* mesh2path, const char* mesh2, const double correctVol, const double prec, bool doubleTest) const
IntersectionMatrix matrix1;
calcIntersectionMatrix(mesh1path, mesh1, mesh2path, mesh2, matrix1);
-#if LOG_LEVEL >= 2
+#if LOG_LEVEL >= 2
dumpIntersectionMatrix(matrix1);
#endif
}
else
{
-
+
IntersectionMatrix matrix2;
- calcIntersectionMatrix(mesh2path, mesh2, mesh1path, mesh1, matrix2);
+ calcIntersectionMatrix(mesh2path, mesh2, mesh1path, mesh1, matrix2);
#if LOG_LEVEL >= 2
dumpIntersectionMatrix(matrix2);
#endif
-
+
const double vol2 = sumVolume(matrix2);
LOG(1, "vol1 = " << vol1 << ", vol2 = " << vol2 << ", correctVol = " << correctVol );
#include <algorithm>
-// levels :
+// levels :
// 1 - titles and volume results
// 2 - symmetry / diagonal results and intersection matrix output
// 3 - empty
}
/**
- * Verifies if for a given intersection matrix the sum of each row is equal to the volumes
+ * Verifies if for a given intersection matrix the sum of each row is equal to the volumes
* of the corresponding source elements and the sum of each column is equal to the volumes
* of the corresponding target elements. This will be true as long as the meshes correspond
* to the same geometry. The equalities are in the "epsilon-sense", making sure the relative
//if(m2[j - 1].count(i+1) > 0)
// {
std::map<int, double> theMap = m2.at(j);
- const double v2 = fabs(theMap[i]);
+ const double v2 = fabs(theMap[i]);
if(v1 != v2)
{
LOG(2, "V1( " << i << ", " << j << ") = " << v1 << " which is different from V2( " << j << ", " << i << ") = " << v2 << " | diff = " << v1 - v2 );
}
if(!isSymmetric)
{
- LOG(1, "*** matrices are not symmetric");
+ LOG(1, "*** matrices are not symmetric");
}
return isSymmetric;
}
* Calculates the intersection matrix for two meshes.
* If the source and target meshes are the same, a CppUnit assertion raised if testVolumes() returns false.
*
- * @param mesh1path the path to the file containing the source mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh1path the path to the file containing the source mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh1 the name of the source mesh
- * @param mesh2path the path to the file containing the target mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh2path the path to the file containing the target mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh2 the name of the target mesh
* @param m intersection matrix in which to store the result of the intersection
*/
* it will be confirmed that the intersection matrix is diagonal, otherwise the intersection matrices will be
* calculated once which each mesh as source mesh, and it will be verified that the they are each others' transpose.
*
- * @param mesh1path the path to the file containing the source mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh1path the path to the file containing the source mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh1 the name of the source mesh
- * @param mesh2path the path to the file containing the target mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh2path the path to the file containing the target mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh2 the name of the target mesh
* @param correctVol the total volume of the intersection of the two meshes
* @param prec maximum relative error to be tolerated in volume comparisions
IntersectionMatrix matrix1;
calcIntersectionMatrix(mesh1path, mesh1, mesh2path, mesh2, matrix1);
-#if LOG_LEVEL >= 2
+#if LOG_LEVEL >= 2
dumpIntersectionMatrix(matrix1);
#endif
else
{
IntersectionMatrix matrix2;
- calcIntersectionMatrix(mesh2path, mesh2, mesh1path, mesh1, matrix2);
+ calcIntersectionMatrix(mesh2path, mesh2, mesh1path, mesh1, matrix2);
#if LOG_LEVEL >= 2
dumpIntersectionMatrix(matrix2);
/**
* Utility method used to facilitate the call to intersect meshes.
- * It calls intersectMeshes, using "mesh1.med" as file name for the mesh with name "mesh1" and
+ * It calls intersectMeshes, using "mesh1.med" as file name for the mesh with name "mesh1" and
* "mesh2.med" as file name for the mesh with name "mesh2". The rest of the arguments are passed
* along as they are.
*
/**
* \file PerfTest.cxx
- * Test program which takes two meshes and calculates their intersection matrix.
- *
- * USAGE : PerfTest mesh1 mesh2
+ * Test program which takes two meshes and calculates their intersection matrix.
+ *
+ * USAGE : PerfTest mesh1 mesh2
* where mesh1 and mesh2 are the names of two meshes located in
- * the files mesh1.med, mesh2.med in {$MED_ROOT_DIR}/share/salome/resources/med/
+ * the files mesh1.med, mesh2.med in {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
*
*/
*/
class PerfTestToolkit : public MeshTestToolkit<3,3>
{
-
+
public:
/**
* Calculates the intersection matrix for two meshes.
- * Outputs the names of the meshes intersected, the number of elements in each mesh,
+ * Outputs the names of the meshes intersected, the number of elements in each mesh,
* the number of matrix elements and the number of non-zero matrix elements, etc.
* These values help to determine how well the filtering algorithm is working.
*
- * @param mesh1path the path to the file containing the source mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh1path the path to the file containing the source mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh1 the name of the source mesh
- * @param mesh2path the path to the file containing the target mesh, relative to {$MED_ROOT_DIR}/share/salome/resources/med/
+ * @param mesh2path the path to the file containing the target mesh, relative to {$MEDCOUPLING_ROOT_DIR}/share/resources/med/
* @param mesh2 the name of the target mesh
* @param m intersection matrix in which to store the result of the intersection
*/
- void calcIntersectionMatrix(const char* mesh1path, const char* mesh1, const char* mesh2path, const char* mesh2, IntersectionMatrix& m)
+ void calcIntersectionMatrix(const char* mesh1path, const char* mesh1, const char* mesh2path, const char* mesh2, IntersectionMatrix& m)
{
LOG(1, std::endl << "=== -> intersecting src = " << mesh1 << ", target = " << mesh2 );
-
+
LOG(5, "Loading " << mesh1 << " from " << mesh1path);
MEDCouplingAutoRefCountObjectPtr<MEDFileUMesh> sMeshML=MEDFileUMesh::New(INTERP_TEST::getResourceFile(mesh1path).c_str(),mesh1);
MEDCouplingAutoRefCountObjectPtr<MEDCouplingUMesh> sMesh=sMeshML->getMeshAtLevel(0);
-
-
+
+
LOG(5, "Loading " << mesh2 << " from " << mesh2path);
MEDCouplingAutoRefCountObjectPtr<MEDFileUMesh> tMeshML=MEDFileUMesh::New(INTERP_TEST::getResourceFile(mesh2path).c_str(),mesh2);
MEDCouplingAutoRefCountObjectPtr<MEDCouplingUMesh> tMesh=tMeshML->getMeshAtLevel(0);
-
+
MEDCouplingNormalizedUnstructuredMesh<3,3> sMesh_wrapper(sMesh);
MEDCouplingNormalizedUnstructuredMesh<3,3> tMesh_wrapper(tMesh);
-
+
Interpolation3D interpolator;
interpolator.interpolateMeshes(sMesh_wrapper, tMesh_wrapper,m,"P0P0");
-
+
std::pair<int, int> eff = countNumberOfMatrixEntries(m);
- LOG(1, eff.first << " of " << numTargetElems * numSrcElems << " intersections calculated : ratio = "
+ LOG(1, eff.first << " of " << numTargetElems * numSrcElems << " intersections calculated : ratio = "
<< double(eff.first) / double(numTargetElems * numSrcElems));
- LOG(1, eff.second << " non-zero elements of " << eff.first << " total : filter efficiency = "
+ LOG(1, eff.second << " non-zero elements of " << eff.first << " total : filter efficiency = "
<< double(eff.second) / double(eff.first));
-
+
LOG(1, "Intersection calculation done. " << std::endl );
-
+
}
/**
*/
std::pair<int,int> countNumberOfMatrixEntries(const IntersectionMatrix& m)
{
-
+
int numElems = 0;
int numNonZero = 0;
for(IntersectionMatrix::const_iterator iter = m.begin() ; iter != m.end() ; ++iter)
}
return std::make_pair(numElems, numNonZero);
}
-
+
};
}
/**
- * Main method of the program.
+ * Main method of the program.
* Intersects the meshes and outputs some information about the calculation as well as the
* intersection matrix on std::cout.
*
using INTERP_TEST::PerfTestToolkit;
assert(argc == 3);
-
+
// load meshes
const std::string mesh1 = argv[1];
const std::string mesh2 = argv[2];
testTools.calcIntersectionMatrix(mesh1path.c_str(), mesh1.c_str(), mesh2path.c_str(), mesh2.c_str(), m);
testTools.dumpIntersectionMatrix(m);
-
+
return 0;
}
#include "TestInterpKernelUtils.hxx"
#include <cstdlib>
+#include <unistd.h>
namespace INTERP_TEST
{
std::string getResourceFile( const std::string& filename )
{
std::string resourceFile = "";
-
- if ( getenv("top_srcdir") ) {
- // we are in 'make test' step
- resourceFile = getenv("top_srcdir");
- resourceFile += "/resources/";
+
+ if ( getenv("MEDCOUPLING_ROOT_DIR") ) {
+ // use MEDCOUPLING_ROOT_DIR env.var
+ resourceFile = getenv("MEDCOUPLING_ROOT_DIR");
+ resourceFile += "/share/resources/med/";
}
- else if ( getenv("MED_ROOT_DIR") ) {
- // use MED_ROOT_DIR env.var
- resourceFile = getenv("MED_ROOT_DIR");
- resourceFile += "/share/salome/resources/med/";
+ else {
+ resourceFile = get_current_dir_name();
+ resourceFile += "/../../resources/";
}
+
resourceFile += filename;
return resourceFile;
}
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-IF(SALOME_MED_ENABLE_PYTHON)
- ADD_SUBDIRECTORY(Swig)
- IF(SALOME_BUILD_TESTS)
- ADD_SUBDIRECTORY(Test)
- ENDIF(SALOME_BUILD_TESTS)
-ENDIF(SALOME_MED_ENABLE_PYTHON)
-
-INCLUDE_DIRECTORIES(
- ${MEDFILE_INCLUDE_DIRS}
- ${HDF5_INCLUDE_DIRS}
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCouplingCorba
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDLoader
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Geometric2D
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/ExprEval
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/GaussPoints
- )
-
-SET(medcalculator_SOURCES
- MEDCalculatorBrowserMesh.cxx
- MEDCalculatorBrowserField.cxx
- MEDCalculatorBrowserStep.cxx
- MEDCalculatorBrowserLiteStruct.cxx
- MEDCalculatorDBRangeSelection.cxx
- MEDCalculatorDBSliceField.cxx
- MEDCalculatorDBField.cxx
-)
-
-ADD_LIBRARY(medcalculator SHARED ${medcalculator_SOURCES})
-TARGET_LINK_LIBRARIES(medcalculator medloader medcouplingcorba ${KERNEL_LDFLAGS}
- ${KERNEL_SALOMELocalTrace} ${KERNEL_SalomeNS} ${KERNEL_OpUtil}
- ${OMNIORB_LIBRARIES} ${PLATFORM_LIBRARIES})
-INSTALL(TARGETS medcalculator DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB medcalculator_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${medcalculator_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_DEFINITIONS(${PYTHON_DEFINITIONS})
-
-FIND_PACKAGE(SWIG REQUIRED)
-INCLUDE(${SWIG_USE_FILE})
-
-INCLUDE_DIRECTORIES(
- ${PYTHON_INCLUDE_DIRS}
- ${MEDFILE_INCLUDE_DIRS}
- ${HDF5_INCLUDE_DIRS}
- ${CMAKE_CURRENT_SOURCE_DIR}
- ${CMAKE_CURRENT_SOURCE_DIR}/..
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDLoader
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDLoader/Swig
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling_Swig
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL/Bases
- )
-
-SET(medcalculatorspython_SOURCES
- SPythonInterpreter.cxx
- SPythonParser.cxx
- )
-
-ADD_LIBRARY(medcalculatorspython SHARED ${medcalculatorspython_SOURCES})
-TARGET_LINK_LIBRARIES(medcalculatorspython interpkernel ${PYTHON_LIBRARIES})
-INSTALL(TARGETS medcalculatorspython DESTINATION ${SALOME_INSTALL_LIBS})
-
-SET_SOURCE_FILES_PROPERTIES(MEDCalculator.i PROPERTIES CPLUSPLUS ON)
-SET_SOURCE_FILES_PROPERTIES(MEDCalculator.i PROPERTIES SWIG_DEFINITIONS "-shadow")
-SET(SWIG_MODULE_MEDCalculator_EXTRA_FLAGS ${SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY})
-SWIG_ADD_MODULE(MEDCalculator python MEDCalculator.i)
-SWIG_LINK_LIBRARIES(MEDCalculator ${PYTHON_LIBRARIES} medcalculator)
-
-IF(WIN32)
- SET_TARGET_PROPERTIES(_MEDCalculator PROPERTIES DEBUG_OUTPUT_NAME _MEDCalculator_d)
-ENDIF(WIN32)
-
-FILE(GLOB medcalculatorspython_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${medcalculatorspython_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
-INSTALL(TARGETS _MEDCalculator DESTINATION ${SALOME_INSTALL_PYTHON})
-INSTALL(FILES MEDCalculator.i MEDCalculatorTypemaps.i DESTINATION ${SALOME_INSTALL_HEADERS})
-SALOME_INSTALL_SCRIPTS(${CMAKE_CURRENT_BINARY_DIR}/MEDCalculator.py ${SALOME_INSTALL_PYTHON})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_DEFINITIONS(${CPPUNIT_DEFINITIONS})
-
-INCLUDE_DIRECTORIES(
- ${PYTHON_INCLUDE_DIRS}
- ${CPPUNIT_INCLUDE_DIRS}
- ${HDF5_INCLUDE_DIRS}
- ${MEDFILE_INCLUDE_DIRS}
- ${CMAKE_CURRENT_SOURCE_DIR}/..
- ${CMAKE_CURRENT_SOURCE_DIR}/../Swig
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDLoader
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL/Bases
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNELTest # For common CppUnitTest.hxx file
- )
-
-SET(TestMEDCalculator_SOURCES
- TestMEDCalculator.cxx
- MEDCalculatorBasicsTest.cxx
- )
-
-ADD_EXECUTABLE(TestMEDCalculator ${TestMEDCalculator_SOURCES})
-TARGET_LINK_LIBRARIES(TestMEDCalculator medcalculatorspython medcalculator ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBRARIES})
-ADD_TEST(TestMEDCalculator TestMEDCalculator)
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
-SET_TESTS_PROPERTIES(TestMEDCalculator PROPERTIES ENVIRONMENT "${tests_env}")
-
-INSTALL(TARGETS TestMEDCalculator DESTINATION ${SALOME_INSTALL_BINS})
-
-# Application tests
-
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDCalculator)
-INSTALL(TARGETS TestMEDCalculator DESTINATION ${TEST_INSTALL_DIRECTORY})
-
-INSTALL(FILES CTestTestfileInstall.cmake
- DESTINATION ${TEST_INSTALL_DIRECTORY}
- RENAME CTestTestfile.cmake)
#
# Author : Anthony Geay (CEA/DEN)
-IF(SALOME_BUILD_TESTS)
+IF(MEDCOUPLING_BUILD_TESTS)
ADD_SUBDIRECTORY(Test)
-ENDIF(SALOME_BUILD_TESTS)
+ENDIF(MEDCOUPLING_BUILD_TESTS)
INCLUDE_DIRECTORIES(
${CMAKE_CURRENT_BINARY_DIR}/../..
ADD_LIBRARY(medcoupling SHARED ${medcoupling_SOURCES})
TARGET_LINK_LIBRARIES(medcoupling interpkernel)
-INSTALL(TARGETS medcoupling EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS medcoupling EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
ADD_LIBRARY(medcouplingremapper SHARED ${medcouplingremapper_SOURCES})
TARGET_LINK_LIBRARIES(medcouplingremapper medcoupling)
-INSTALL(TARGETS medcouplingremapper EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS medcouplingremapper EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
FILE(GLOB medcoupling_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
FILE(GLOB medcoupling_HEADERS_TXX "${CMAKE_CURRENT_SOURCE_DIR}/*.txx")
-INSTALL(FILES ${medcoupling_HEADERS_HXX} ${medcoupling_HEADERS_TXX} MEDCouplingNatureOfFieldEnum DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${medcoupling_HEADERS_HXX} ${medcoupling_HEADERS_TXX} MEDCouplingNatureOfFieldEnum DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# To allow usage as SWIG dependencies:
SET(medcoupling_HEADERS_HXX PARENT_SCOPE)
// Author : Anthony Geay (CEA/DEN)
#include "MEDCouplingRefCountObject.hxx"
-#include "MED_version.h"
+#include "MEDCoupling_version.h"
#include <sstream>
#include <algorithm>
const char *ParaMEDMEM::MEDCouplingVersionStr()
{
- return SALOMEMED_VERSION_STR;
+ return MEDCOUPLING_VERSION_STR;
}
int ParaMEDMEM::MEDCouplingVersion()
{
- return SALOMEMED_VERSION;
+ return MEDCOUPLING_VERSION;
}
void ParaMEDMEM::MEDCouplingVersionMajMinRel(int& maj, int& minor, int& releas)
{
- int ver=SALOMEMED_VERSION;
+ int ver=MEDCOUPLING_VERSION;
maj=(ver & 0xFF0000) >> 16;
minor=(ver & 0xFF00) >> 8;
releas=(ver & 0xFF);
MEDCouplingBasicsTest0.cxx
)
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
-
ADD_EXECUTABLE(TestMEDCoupling ${TestMEDCoupling_SOURCES})
TARGET_LINK_LIBRARIES(TestMEDCoupling medcoupling ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestMEDCoupling TestMEDCoupling)
-SET_TESTS_PROPERTIES(TestMEDCoupling PROPERTIES ENVIRONMENT "${tests_env}")
ADD_EXECUTABLE(TestMEDCouplingRemapper ${TestMEDCouplingRemapper_SOURCES})
TARGET_LINK_LIBRARIES(TestMEDCouplingRemapper medcouplingremapper ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestMEDCouplingRemapper TestMEDCouplingRemapper)
-SET_TESTS_PROPERTIES(TestMEDCouplingRemapper PROPERTIES ENVIRONMENT "${tests_env}")
ADD_EXECUTABLE(TestMEDCouplingExamples ${TestMEDCouplingExamples_SOURCES})
TARGET_LINK_LIBRARIES(TestMEDCouplingExamples medcoupling ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestMEDCouplingExamples TestMEDCouplingExamples)
-SET_TESTS_PROPERTIES(TestMEDCouplingExamples PROPERTIES ENVIRONMENT "${tests_env}")
-INSTALL(TARGETS TestMEDCoupling TestMEDCouplingRemapper TestMEDCouplingExamples DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS TestMEDCoupling TestMEDCouplingRemapper TestMEDCouplingExamples DESTINATION ${MEDCOUPLING_INSTALL_BINS})
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES UnitTestsResult)
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDCoupling)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDCoupling)
INSTALL(TARGETS TestMEDCoupling TestMEDCouplingRemapper TestMEDCouplingExamples DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_DEFINITIONS(${OMNIORB_DEFINITIONS})
-
-ADD_SUBDIRECTORY(Client)
-
-IF(SALOME_BUILD_TESTS)
- ADD_SUBDIRECTORY(Test)
-ENDIF(SALOME_BUILD_TESTS)
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- )
-
-SET(medcouplingcorba_SOURCES
- MEDCouplingRefCountServant.cxx
- MEDCouplingMeshServant.cxx
- MEDCouplingPointSetServant.cxx
- MEDCouplingExtrudedMeshServant.cxx
- MEDCouplingStructuredMeshServant.cxx
- MEDCouplingCurveLinearMeshServant.cxx
- MEDCoupling1DGTUMeshServant.cxx
- MEDCoupling1SGTUMeshServant.cxx
- MEDCoupling1GTUMeshServant.cxx
- MEDCouplingCMeshServant.cxx
- MEDCouplingIMeshServant.cxx
- MEDCouplingUMeshServant.cxx
- MEDCouplingFieldServant.cxx
- MEDCouplingFieldDoubleServant.cxx
- MEDCouplingFieldTemplateServant.cxx
- MEDCouplingMultiFieldsServant.cxx
- MEDCouplingFieldOverTimeServant.cxx
- DataArrayDoubleServant.cxx
- DataArrayIntServant.cxx
- DataArrayServant.cxx
- )
-
-ADD_LIBRARY(medcouplingcorba SHARED ${medcouplingcorba_SOURCES})
-TARGET_LINK_LIBRARIES(medcouplingcorba medcoupling SalomeIDLMED ${PLATFORM_LIBS})
-INSTALL(TARGETS medcouplingcorba EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB medcouplingcorba_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${medcouplingcorba_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
-
-# To allow usage as SWIG dependencies:
-SET(medcouplingcorba_HEADERS_HXX PARENT_SCOPE)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL/Bases
- )
-
-SET(medcouplingclient_SOURCES
- DataArrayDoubleClient.cxx
- DataArrayIntClient.cxx
- MEDCouplingCMeshClient.cxx
- MEDCouplingIMeshClient.cxx
- MEDCoupling1SGTUMeshClient.cxx
- MEDCoupling1DGTUMeshClient.cxx
- MEDCouplingCurveLinearMeshClient.cxx
- MEDCouplingExtrudedMeshClient.cxx
- MEDCouplingFieldDoubleClient.cxx
- MEDCouplingFieldOverTimeClient.cxx
- MEDCouplingFieldTemplateClient.cxx
- MEDCouplingMeshClient.cxx
- MEDCouplingMultiFieldsClient.cxx
- MEDCouplingUMeshClient.cxx
- )
-
-ADD_LIBRARY(medcouplingclient SHARED ${medcouplingclient_SOURCES})
-TARGET_LINK_LIBRARIES(medcouplingclient medcoupling SalomeIDLMED ${OMNIORB_LIBRARIES} ${PLATFORM_LIBS})
-INSTALL(TARGETS medcouplingclient EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB medcouplingclient_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${medcouplingclient_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CPPUNIT_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/..
- ${CMAKE_CURRENT_SOURCE_DIR}/../Client
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL/Bases
- )
-
-SET(TestMEDCouplingCorbaServ_SOURCES
- TestMEDCouplingCorbaServ.cxx
- MEDCouplingMeshFieldFactoryComponent.cxx
- MEDCouplingMeshFieldFactoryComponentServ.cxx
- )
-
-ADD_EXECUTABLE(TestMEDCouplingCorbaServ ${TestMEDCouplingCorbaServ_SOURCES})
-TARGET_LINK_LIBRARIES(TestMEDCouplingCorbaServ medcouplingcorba SalomeIDLMEDTests ${OMNIORB_LIBRARIES} ${PLATFORM_LIBRARIES})
-
-SET(TestMEDCouplingCorbaClt_SOURCES
- TestMEDCouplingCorbaClt.cxx
- MEDCouplingMeshFieldFactoryComponent.cxx
- MEDCouplingMeshFieldFactoryComponentClt.cxx
- )
-
-ADD_EXECUTABLE(TestMEDCouplingCorbaClt ${TestMEDCouplingCorbaClt_SOURCES})
-SET_TARGET_PROPERTIES(TestMEDCouplingCorbaClt PROPERTIES COMPILE_FLAGS "${CPPUNIT_DEFINITIONS}")
-TARGET_LINK_LIBRARIES(TestMEDCouplingCorbaClt medcouplingclient SalomeIDLMEDTests ${OMNIORB_LIBRARIES} ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBRARIES} ${PTHREAD_LIBRARIES})
-
-INSTALL(TARGETS TestMEDCouplingCorbaServ TestMEDCouplingCorbaClt DESTINATION ${SALOME_INSTALL_BINS})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_SUBDIRECTORY(Client)
-
-ADD_DEFINITIONS(${PYTHON_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-FIND_PACKAGE(SWIG REQUIRED)
-INCLUDE(${SWIG_USE_FILE})
-
-SET_SOURCE_FILES_PROPERTIES(MEDCouplingCorba.i PROPERTIES CPLUSPLUS ON)
-SET_SOURCE_FILES_PROPERTIES(MEDCouplingCorba.i PROPERTIES SWIG_DEFINITIONS "-shadow")
-SET(SWIG_MODULE_MEDCouplingCorba_EXTRA_FLAGS ${SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY})
-
-SET(MEDCouplingCorba_SWIG_DPYS_FILES
- MEDCouplingCorbaTypemaps.i)
-
-INCLUDE_DIRECTORIES(
- ${PYTHON_INCLUDE_DIRS}
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCouplingCorba
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling_Swig
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- )
-
-# _ABR_ Ensure dependency mechanism on all SWIG files and headers
-SET (SWIG_MODULE_MEDCouplingCorba_EXTRA_DEPS ${MEDCouplingCorba_SWIG_DPYS_FILES}
- ${medcouplingcorba_HEADERS_HXX}
- ${medcoupling_HEADERS_HXX} ${medcoupling_HEADERS_TXX}
- ${interpkernel_HEADERS_HXX} ${interpkernel_HEADERS_TXX})
-
-SWIG_ADD_MODULE(MEDCouplingCorba python MEDCouplingCorba.i)
-SWIG_LINK_LIBRARIES(MEDCouplingCorba ${PYTHON_LIBRARIES} medcouplingcorba ${PLATFORM_LIBS})
-IF(WIN32)
- SET_TARGET_PROPERTIES(_MEDCouplingCorba PROPERTIES DEBUG_OUTPUT_NAME _MEDCouplingCorba_d)
-ENDIF(WIN32)
-
-INSTALL(TARGETS _MEDCouplingCorba DESTINATION ${SALOME_INSTALL_PYTHON})
-INSTALL(FILES MEDCouplingCorba.i MEDCouplingCorbaTypemaps.i DESTINATION ${SALOME_INSTALL_HEADERS})
-SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDCouplingCorba.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-# Author : Anthony Geay (CEA/DEN)
-
-ADD_DEFINITIONS(${PYTHON_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-FIND_PACKAGE(SWIG REQUIRED)
-INCLUDE(${SWIG_USE_FILE})
-
-SET_SOURCE_FILES_PROPERTIES(MEDCouplingClient.i PROPERTIES CPLUSPLUS ON)
-SET_SOURCE_FILES_PROPERTIES(MEDCouplingClient.i PROPERTIES SWIG_DEFINITIONS "-shadow")
-SET(SWIG_MODULE_MEDCouplingClient_EXTRA_FLAGS ${SWIG_EXTRA_FLAGS_FOR_NUMPYANDSCIPY})
-
-INCLUDE_DIRECTORIES(
- ${PYTHON_INCLUDE_DIRS}
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCouplingCorba/Client
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling_Swig
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../../INTERP_KERNEL/Bases
- )
-
-SWIG_ADD_MODULE(MEDCouplingClient python MEDCouplingClient.i)
-SWIG_LINK_LIBRARIES(MEDCouplingClient ${PYTHON_LIBRARIES} medcouplingclient)
-IF(WIN32)
- SET_TARGET_PROPERTIES(_MEDCouplingClient PROPERTIES DEBUG_OUTPUT_NAME _MEDCouplingClient_d)
-ENDIF(WIN32)
-
-INSTALL(TARGETS _MEDCouplingClient DESTINATION ${SALOME_INSTALL_PYTHON})
-INSTALL(FILES MEDCouplingClient.i DESTINATION ${SALOME_INSTALL_HEADERS})
-SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDCouplingClient.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON})
# SWIG must run after the doc if we want to have the docstrings extracted from Doxygen
# into the Python module:
-IF(SALOME_BUILD_DOC)
+IF(MEDCOUPLING_BUILD_DOC)
LIST(APPEND SWIG_MODULE_MEDCoupling_EXTRA_FLAGS -DWITH_DOCSTRINGS)
- LIST(APPEND SWIG_MODULE_MEDCoupling_EXTRA_DEPS
+ LIST(APPEND SWIG_MODULE_MEDCoupling_EXTRA_DEPS
${PROJECT_BINARY_DIR}/doc/MEDCoupling_doc.i
swig_ready)
ENDIF()
SET_TARGET_PROPERTIES(_MEDCouplingRemapper PROPERTIES DEBUG_OUTPUT_NAME _MEDCouplingRemapper_d)
SET_TARGET_PROPERTIES(_MEDCoupling PROPERTIES DEBUG_OUTPUT_NAME _MEDCoupling_d)
ENDIF(WIN32)
-INSTALL(TARGETS ${SWIG_MODULE_MEDCoupling_REAL_NAME} ${SWIG_MODULE_MEDCouplingRemapper_REAL_NAME} DESTINATION ${SALOME_INSTALL_PYTHON})
+INSTALL(TARGETS ${SWIG_MODULE_MEDCoupling_REAL_NAME} ${SWIG_MODULE_MEDCouplingRemapper_REAL_NAME} DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
-SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDCoupling.py ${CMAKE_CURRENT_BINARY_DIR}/MEDCouplingRemapper.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON})
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDCoupling.py ${CMAKE_CURRENT_BINARY_DIR}/MEDCouplingRemapper.py DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
-INSTALL(FILES MEDCoupling.i MEDCouplingCommon.i MEDCouplingRefCountObject.i MEDCouplingMemArray.i MEDCouplingFieldDiscretization.i MEDCouplingTimeDiscretization.i MEDCouplingFinalize.i MEDCouplingRemapper.i MEDCouplingTypemaps.i MEDCouplingDataArrayTypemaps.i DESTINATION ${SALOME_INSTALL_HEADERS})
-INSTALL(FILES MEDCouplingBasicsTest.py MEDCouplingRemapperTest.py MEDCouplingDataForTest.py MEDCouplingNumPyTest.py MEDCouplingPickleTest.py DESTINATION ${SALOME_INSTALL_SCRIPT_PYTHON})
-INSTALL(FILES MEDCouplingExamplesTest.py DESTINATION ${SALOME_INSTALL_SCRIPT_PYTHON})
-
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
+INSTALL(FILES MEDCoupling.i MEDCouplingCommon.i MEDCouplingRefCountObject.i MEDCouplingMemArray.i MEDCouplingFieldDiscretization.i MEDCouplingTimeDiscretization.i MEDCouplingFinalize.i MEDCouplingRemapper.i MEDCouplingTypemaps.i MEDCouplingDataArrayTypemaps.i DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
+INSTALL(FILES MEDCouplingBasicsTest.py MEDCouplingRemapperTest.py MEDCouplingDataForTest.py MEDCouplingNumPyTest.py MEDCouplingPickleTest.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
+INSTALL(FILES MEDCouplingExamplesTest.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
ADD_TEST(MEDCouplingBasicsTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDCouplingBasicsTest.py)
-SET_TESTS_PROPERTIES(MEDCouplingBasicsTest PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDCouplingExamplesTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDCouplingExamplesTest.py)
-SET_TESTS_PROPERTIES(MEDCouplingExamplesTest PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDCouplingRemapperTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDCouplingRemapperTest.py)
-SET_TESTS_PROPERTIES(MEDCouplingRemapperTest PROPERTIES ENVIRONMENT "${tests_env}")
IF(NUMPY_FOUND)
ADD_TEST(MEDCouplingNumPyTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDCouplingNumPyTest.py)
- SET_TESTS_PROPERTIES(MEDCouplingNumPyTest PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDCouplingPickleTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDCouplingPickleTest.py)
- SET_TESTS_PROPERTIES(MEDCouplingPickleTest PROPERTIES ENVIRONMENT "${tests_env}")
ENDIF(NUMPY_FOUND)
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDCoupling_Swig)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDCoupling_Swig)
INSTALL(FILES MEDCouplingBasicsTest.py MEDCouplingRemapperTest.py MEDCouplingDataForTest.py MEDCouplingNumPyTest.py MEDCouplingPickleTest.py MEDCouplingExamplesTest.py DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${XDR_DEFINITIONS} ${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE(${QT_USE_FILE})
-INCLUDE(UseQt4Ext)
-
-SET(MEDGUI_SOURCES
- MEDGUIFileContentDial.cxx
- MEDGUISelection.cxx
- MEDGUISelectComponents.cxx
- MEDGUIDataBaseDockWidget.cxx
-)
-
-SET(MEDGUI_HEADERS MEDGUIFileContentDial.h MEDGUISelectComponents.h)
-SET(MEDGUI_FORMS MEDGUIFileContentDial.ui MEDGUISelectComponents.ui)
-#SET(MEDGUI_RESOURCES images.qrc)
-
-QT4_WRAP_CPP(MEDGUI_HEADERS_MOC ${MEDGUI_HEADERS})
-QT4_WRAP_UI(MEDGUI_FORMS_HEADERS ${MEDGUI_FORMS})
-#QT4_ADD_RESOURCES(MEDGUI_RESOURCES_RCC ${MEDGUI_RESOURCES})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CAS_INCLUDE_DIRS}
- ${Boost_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIRS}
- ${GUI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_BINARY_DIR}/../..
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCalculator
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/GaussPoints
- )
-
-SET(MEDGUITS_SOURCES
- MED_images.ts
- MED_msg_fr.ts
- MED_msg_en.ts
- MED_msg_ja.ts
-)
-
-ADD_LIBRARY(MEDGUI SHARED ${MEDGUI_SOURCES} ${MEDGUI_HEADERS_MOC} ${MEDGUI_FORMS_HEADERS})
-TARGET_LINK_LIBRARIES(MEDGUI medcalculator ${QT_MT_LIBS} ${CAS_KERNEL} ${BOOST_LIBRARIES} ${GUI_LDFLAGS} ${SalomeApp} ${CAM} ${LightApp} ${qtx} ${suit} ${SalomeObject} ${PLATFORM_LIBS} ${SalomeLifeCycleCORBA})
-INSTALL(TARGETS MEDGUI DESTINATION ${SALOME_INSTALL_LIBS})
-QT4_INSTALL_TS_RESOURCES("${MEDGUITS_SOURCES}" "${SALOME_MED_INSTALL_RES_DATA}")
ADD_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${XDR_DEFINITIONS})
-IF(SALOME_MED_ENABLE_PYTHON)
+IF(MEDCOUPLING_MED_ENABLE_PYTHON)
ADD_SUBDIRECTORY(Swig)
-ENDIF(SALOME_MED_ENABLE_PYTHON)
+ENDIF(MEDCOUPLING_MED_ENABLE_PYTHON)
-IF(SALOME_BUILD_TESTS)
+IF(MEDCOUPLING_BUILD_TESTS)
ADD_SUBDIRECTORY(Test)
-ENDIF(SALOME_BUILD_TESTS)
+ENDIF(MEDCOUPLING_BUILD_TESTS)
SET(MEDLOADER_XDR_INCLUDE_DIRS)
SET(MEDLOADER_XDR_LIBRARIES)
IF(WIN32)
- IF(SALOME_MED_MEDLOADER_USE_XDR)
+ IF(MEDCOUPLING_MED_MEDLOADER_USE_XDR)
ADD_DEFINITIONS(-DNOMINMAX)
SET(MEDLOADER_XDR_INCLUDE_DIRS ${XDR_INCLUDE_DIRS})
SET(MEDLOADER_XDR_LIBRARIES ${XDR_LIBRARIES})
- ENDIF(SALOME_MED_MEDLOADER_USE_XDR)
+ ENDIF(MEDCOUPLING_MED_MEDLOADER_USE_XDR)
ELSE(WIN32)
SET(MEDLOADER_XDR_INCLUDE_DIRS ${XDR_INCLUDE_DIRS})
ENDIF(WIN32)
ADD_LIBRARY(medloader SHARED ${medloader_SOURCES})
SET_TARGET_PROPERTIES(medloader PROPERTIES COMPILE_FLAGS "")
TARGET_LINK_LIBRARIES(medloader medcoupling ${MEDFILE_C_LIBRARIES} ${HDF5_LIBRARIES} ${MEDLOADER_XDR_LIBRARIES})
-INSTALL(TARGETS medloader EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS medloader EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
FILE(GLOB medloader_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${medloader_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${medloader_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# To allow usage as SWIG dependencies:
SET(medloader_HEADERS_HXX PARENT_SCOPE)
# SWIG must run after the doc if we want to have the docstrings extracted from Doxygen
# into the Python module:
-IF(SALOME_BUILD_DOC)
+IF(MEDCOUPLING_BUILD_DOC)
LIST(APPEND SWIG_MODULE_MEDLoader_EXTRA_FLAGS -DWITH_DOCSTRINGS)
- LIST(APPEND SWIG_MODULE_MEDLoader_EXTRA_DEPS
+ LIST(APPEND SWIG_MODULE_MEDLoader_EXTRA_DEPS
${PROJECT_BINARY_DIR}/doc/MEDLoader_doc.i
swig_ready)
ENDIF()
SET_TARGET_PROPERTIES(_MEDLoader PROPERTIES DEBUG_OUTPUT_NAME _MEDLoader_d)
ENDIF(WIN32)
-INSTALL(TARGETS _MEDLoader DESTINATION ${SALOME_INSTALL_PYTHON})
-INSTALL(FILES MEDLoader.i MEDLoaderTypemaps.i MEDLoaderCommon.i DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(TARGETS _MEDLoader DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
+INSTALL(FILES MEDLoader.i MEDLoaderTypemaps.i MEDLoaderCommon.i DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
-SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDLoader.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON})
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDLoader.py DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
-INSTALL(FILES MEDLoaderDataForTest.py MEDLoaderTest.py MEDLoaderTest2.py MEDLoaderTest3.py MEDLoaderTest4.py SauvLoaderTest.py MEDLoaderExamplesTest.py MEDLoaderCouplingTrainingSession.py CaseIO.py CaseReader.py CaseWriter.py VTKReader.py MEDLoaderSplitter.py medutilities.py DESTINATION ${SALOME_INSTALL_SCRIPT_SCRIPTS})
-INSTALL(FILES med2sauv PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS} )
-INSTALL(FILES sauv2med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS} )
-INSTALL(FILES case2med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS} )
-INSTALL(FILES med2case PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS} )
-
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
+INSTALL(FILES MEDLoaderDataForTest.py MEDLoaderTest.py MEDLoaderTest2.py MEDLoaderTest3.py MEDLoaderTest4.py SauvLoaderTest.py MEDLoaderExamplesTest.py MEDLoaderCouplingTrainingSession.py CaseIO.py CaseReader.py CaseWriter.py VTKReader.py MEDLoaderSplitter.py medutilities.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS})
+INSTALL(FILES med2sauv PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${MEDCOUPLING_INSTALL_BINS} )
+INSTALL(FILES sauv2med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${MEDCOUPLING_INSTALL_BINS} )
+INSTALL(FILES case2med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${MEDCOUPLING_INSTALL_BINS} )
+INSTALL(FILES med2case PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${MEDCOUPLING_INSTALL_BINS} )
ADD_TEST(MEDLoaderTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderTest.py)
-SET_TESTS_PROPERTIES(MEDLoaderTest PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDLoaderTest2 ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderTest2.py)
-SET_TESTS_PROPERTIES(MEDLoaderTest2 PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDLoaderTest3 ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderTest3.py)
-SET_TESTS_PROPERTIES(MEDLoaderTest3 PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDLoaderTest4 ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderTest4.py)
-SET_TESTS_PROPERTIES(MEDLoaderTest4 PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(MEDLoaderExamplesTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderExamplesTest.py)
-SET_TESTS_PROPERTIES(MEDLoaderExamplesTest PROPERTIES ENVIRONMENT "${tests_env}")
ADD_TEST(SauvLoaderTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/SauvLoaderTest.py)
-SET_TESTS_PROPERTIES(SauvLoaderTest PROPERTIES ENVIRONMENT "${tests_env}")
IF(NUMPY_FOUND)
ADD_TEST(MEDLoaderCouplingTrainingSession ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDLoaderCouplingTrainingSession.py)
- SET_TESTS_PROPERTIES(MEDLoaderCouplingTrainingSession PROPERTIES ENVIRONMENT "${tests_env}")
ENDIF(NUMPY_FOUND)
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDLoader/Swig)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDLoader/Swig)
+
+SET(MEDLOADER_TEST_FILES MEDLoaderDataForTest.py MEDLoaderTest.py MEDLoaderTest2.py MEDLoaderTest3.py MEDLoaderTest4.py SauvLoaderTest.py MEDLoaderExamplesTest.py MEDLoaderCouplingTrainingSession.py CaseIO.py CaseReader.py CaseWriter.py VTKReader.py MEDLoaderSplitter.py medutilities.py)
-INSTALL(FILES MEDLoaderDataForTest.py MEDLoaderTest.py MEDLoaderTest2.py MEDLoaderTest3.py MEDLoaderTest4.py SauvLoaderTest.py MEDLoaderExamplesTest.py MEDLoaderCouplingTrainingSession.py CaseIO.py CaseReader.py CaseWriter.py VTKReader.py MEDLoaderSplitter.py medutilities.py DESTINATION ${TEST_INSTALL_DIRECTORY})
+FOREACH(testfile ${MEDLOADER_TEST_FILES})
+ CONFIGURE_FILE("${CMAKE_CURRENT_SOURCE_DIR}/${testfile}" "${CMAKE_CURRENT_BINARY_DIR}/${testfile}" COPYONLY)
+ENDFOREACH(testfile)
+INSTALL(FILES ${MEDLOADER_TEST_FILES} DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
DESTINATION ${TEST_INSTALL_DIRECTORY}
""" Converting MED file format in memory to a the Case file format (Ensight).
A new file with the same base name and the .case extension is created with its depencies (.geo ...).
"""
-
+
header="""FORMAT
type: ensight gold
GEOMETRY
time values:
%(TimeValues)s
"""
-
+
@classmethod
def New(cls):
""" Static constructor. """
assert(isinstance(status,bool))
self.__export_groups=status
pass
-
+
def write(self,fileName):
""" Write into the specified fileName series the result """
self._real_written_file_name.append(realWrittenCaseFileNameForCurMesh)
pass
return self._real_written_file_name
-
+
def __writeMeshesPart(self,mdm,meshfn):
try:
os.remove(meshfn)
assert(isinstance(mdm,MEDFileUMesh))
ms2=[[mdm.getMeshAtLevel(lev) for lev in mdm.getNonEmptyLevels()[:1]]]
if self.__export_groups:
- for grpnm in mdm.getGroupsNames():
+ for grpnm in mdm.getGroupsNames():
ms3=[]
for lev in mdm.getGrpNonEmptyLevels(grpnm)[:1]:
m=mdm.getGroup(lev,grpnm) ; m.zipCoords()
a=np.memmap(f,dtype='byte',mode='w+',offset=0,shape=(sz,)) ; a.flush() # truncate to set the size of the file
mm=mmap.mmap(f.fileno(),offset=0,length=0)
mm.write(self.__str80("C Binary"))
- mm.write(self.__str80("Exported from MEDCoupling/MEDLoader SALOME version %s"%(MEDCouplingVersionStr())))
+ mm.write(self.__str80("Exported from MEDCoupling/MEDLoader version %s"%(MEDCouplingVersionStr())))
mm.write(self.__str80("Conversion using CaseWriter class"))
mm.write(self.__str80("node id off"))
mm.write(self.__str80("element id off"))
pass
pass
pass
-
+
def __writeFieldsPart(self,mdfs):
if not mdfs:
return ""
headerPart+=htp
pass
return headerPart
-
+
@classmethod
def __str80(cls,st):
if len(st)>79:
raise Exception("String \"%s\" is too long (>79) !"%(st))
return st.ljust(79)+"\n"
-
+
def __computeSizeOfGeoFile(self,listOfMeshes,nn):
sz=0
for m in listOfMeshes:
from numpy import *
from math import acos
-med_root_dir=os.getenv("MED_ROOT_DIR")
-agitateur_file=os.path.join(os.getenv("MED_ROOT_DIR"),"share","salome","resources","med","agitateur.med")
+med_root_dir=os.getenv("MEDCOUPLING_ROOT_DIR")
+if med_root_dir:
+ agitateur_file=os.path.join(os.getenv("MEDCOUPLING_ROOT_DIR"),"share","resources","med","agitateur.med")
+else:
+ current_dir = os.path.dirname(os.path.realpath(__file__))
+ agitateur_file=os.path.join(current_dir, "..", "..", "..", "resources","agitateur.med")
+ pass
data=MEDFileData(agitateur_file)
ts=data.getFields()[0].getTimeSteps()
print ts
class SauvLoaderTest(unittest.TestCase):
+ def __getResourcesDirectory(self):
+ med_root_dir=os.getenv("MEDCOUPLING_ROOT_DIR")
+ if med_root_dir:
+ return os.path.join( os.getenv("MEDCOUPLING_ROOT_DIR"), "share","resources","med")
+ else:
+ current_dir = os.path.dirname(os.path.realpath(__file__))
+ return os.path.join(current_dir, "..", "..", "..", "resources")
+ pass
+
def testSauv2Med(self):
# get a file containing all types of readable piles
- self.assertTrue( os.getenv("MED_ROOT_DIR") )
- sauvFile = os.path.join( os.getenv("MED_ROOT_DIR"), "share","salome",
- "resources","med","allPillesTest.sauv")
+ sauvFile = os.path.join( self.__getResourcesDirectory(),"allPillesTest.sauv")
self.assertTrue( os.access( sauvFile, os.F_OK))
# read SAUV and write MED
d2=sr.loadInMEDFileDS();
d2.write(medFile,0);
- # check
+ # check
self.assertEqual(1,d2.getNumberOfMeshes())
self.assertEqual(8+97,d2.getNumberOfFields())
mm = d2.getMeshes()
def testMed2Sauv(self):
# read pointe.med
- self.assertTrue( os.getenv("MED_ROOT_DIR") )
- medFile = os.path.join( os.getenv("MED_ROOT_DIR"), "share","salome",
- "resources","med","pointe.med")
+ medFile = os.path.join(self.__getResourcesDirectory(),"pointe.med")
self.assertTrue( os.access( medFile, os.F_OK))
pointeMed = MEDFileData.New( medFile )
@unittest.skipUnless(MEDLoader.HasXDR(),"requires XDR")
def testMissingGroups(self):
"""test for issue 0021749: [CEA 601] Some missing groups in mesh after reading a SAUV file with SauvReader."""
- self.assertTrue( os.getenv("MED_ROOT_DIR") )
- sauvFile = os.path.join( os.getenv("MED_ROOT_DIR"), "share","salome",
- "resources","med","BDC-714.sauv")
+ sauvFile = os.path.join(self.__getResourcesDirectory(),"BDC-714.sauv")
self.assertTrue( os.access( sauvFile, os.F_OK))
name_of_group_on_cells='Slice10:ABSORBER'
name_of_group_on_cells2='Slice10:00LR'
sw.setCpyGrpIfOnASingleFamilyStatus(True)
self.assertTrue(sw.getCpyGrpIfOnASingleFamilyStatus())
sw.write(sauvFile)
-
+
f = open(sauvFile)
# String pattern for the header of the sub meshes record ("PILE" number, number of named objects, number of objects)
pattern_pile= re.compile(r'\sPILE\sNUMERO\s+(?P<number>[0-9]+)NBRE\sOBJETS\sNOMMES\s+(?P<nbnamed>[0-9]+)NBRE\sOBJETS\s+(?P<nbobjects>[0-9]+)')
# String pattern for a sub mesh header (cell type, number of components and three numbers)
pattern_header=re.compile(r'\s+(?P<type>[0-9]+)\s+(?P<nbsubs>[0-9]+)\s+[0-9]+\s+[0-9]+\s+[0-9]+')
-
+
nbobjects=0
line = f.readline()
while(line):
pass
line=f.readline()
pass
-
+
# Skipping the objects names
f.readline()
# Skipping the objects ids
f.readline()
- # Looking for each sub-mesh header
+ # Looking for each sub-mesh header
line = f.readline()
cur_object=0
while(line and cur_object < nbobjects):
SauvLoaderTest.cxx
)
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
-
ADD_EXECUTABLE(TestMEDLoader ${TestMEDLoader_SOURCES})
TARGET_LINK_LIBRARIES(TestMEDLoader medloader ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestMEDLoader TestMEDLoader)
-SET_TESTS_PROPERTIES(TestMEDLoader PROPERTIES ENVIRONMENT "${tests_env}")
ADD_EXECUTABLE(TestSauvLoader ${TestSauvLoader_SOURCES})
TARGET_LINK_LIBRARIES(TestSauvLoader medloader ${CPPUNIT_LIBRARIES} ${PLATFORM_LIBS})
ADD_TEST(TestSauvLoader TestSauvLoader)
-SET_TESTS_PROPERTIES(TestSauvLoader PROPERTIES ENVIRONMENT "${tests_env}")
-INSTALL(TARGETS TestMEDLoader TestSauvLoader DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS TestMEDLoader TestSauvLoader DESTINATION ${MEDCOUPLING_INSTALL_BINS})
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDLoader)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDLoader)
INSTALL(TARGETS TestMEDLoader TestSauvLoader DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
{
std::string resourceFile = "";
- if ( getenv("top_srcdir") ) {
- // we are in 'make test' step
- resourceFile = getenv("top_srcdir");
- resourceFile += "/resources/";
+ if ( getenv("MEDCOUPLING_ROOT_DIR") ) {
+ // use MEDCOUPLING_ROOT_DIR env.var
+ resourceFile = getenv("MEDCOUPLING_ROOT_DIR");
+ resourceFile += "/share/resources/med/";
}
- else if ( getenv("MED_ROOT_DIR") ) {
- // use MED_ROOT_DIR env.var
- resourceFile = getenv("MED_ROOT_DIR");
- resourceFile += "/share/salome/resources/med/";
+ else {
+ resourceFile = get_current_dir_name();
+ resourceFile += "/../../../resources/";
}
+
resourceFile += filename;
return resourceFile;
}
MEDCouplingAutoRefCountObjectPtr<MEDFileData> d2=sr->loadInMEDFileDS();
// write MED
d2->write("allPillesTest.med",0);
- // check
+ // check
CPPUNIT_ASSERT_EQUAL(1,d2->getNumberOfMeshes());
CPPUNIT_ASSERT_EQUAL(8+97,d2->getNumberOfFields());
MEDFileMesh * m = d2->getMeshes()->getMeshAtPos(0);
{
std::string resourceFile = "";
- if ( getenv("top_srcdir") ) {
- // we are in 'make test' step
- resourceFile = getenv("top_srcdir");
- resourceFile += "/resources/";
+ if ( getenv("MEDCOUPLING_ROOT_DIR") ) {
+ // use MEDCOUPLING_ROOT_DIR env.var
+ resourceFile = getenv("MEDCOUPLING_ROOT_DIR");
+ resourceFile += "/share/resources/med/";
}
- else if ( getenv("MED_ROOT_DIR") ) {
- // use MED_ROOT_DIR env.var
- resourceFile = getenv("MED_ROOT_DIR");
- resourceFile += "/share/salome/resources/med/";
+ else {
+ resourceFile = get_current_dir_name();
+ resourceFile += "/../../../resources/";
}
+
resourceFile += filename;
#ifdef WIN32
std::string fixedpath = resourceFile;
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(cmp)
-ADD_SUBDIRECTORY(res)
-
-IF(SALOME_BUILD_GUI)
- ADD_SUBDIRECTORY(gui)
-ENDIF()
-
-IF(SALOME_MED_ENABLE_PYTHON)
- ADD_SUBDIRECTORY(tui)
- ADD_SUBDIRECTORY(exe)
-ENDIF()
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_DEFINITIONS(${HDF5_DEFINITIONS} ${MEDFILE_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${MEDFILE_INCLUDE_DIRS}
- ${HDF5_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${PROJECT_BINARY_DIR}/idl
- ${PROJECT_SOURCE_DIR}/src/MEDCoupling
- ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL/Bases
- ${PROJECT_SOURCE_DIR}/src/INTERP_KERNEL
- ${PROJECT_SOURCE_DIR}/src/MEDLoader
-)
-
-SET(MEDOPFactoryEngine_SOURCES
- MEDDataManager_i.cxx
- MEDCalculator_i.cxx
- MEDOPFactory_i.cxx
-)
-SET(COMMON_LIBS
- medloader
- SalomeIDLMED
- ${KERNEL_TOOLSDS}
- ${KERNEL_SalomeHDFPersist}
- ${KERNEL_SalomeContainer}
- ${KERNEL_SalomeCommunication}
- ${KERNEL_SalomeKernelHelpers}
- ${KERNEL_SalomeLifeCycleCORBA}
- ${KERNEL_SALOMELocalTrace}
- ${KERNEL_SALOMEBasics}
- ${KERNEL_SalomeGenericObj}
- medcoupling
- medcouplingremapper
- interpkernel
- ${MEDFILE_C_LIBRARIES}
- ${HDF5_LIBRARIES}
- ${OMNIORB_LIBRARIES}
- ${PLATFORM_LIBRARIES}
-)
-
-# This undefines the macros MIN and MAX which are specified in the windows headers
-IF(WIN32)
- SET(COMMON_FLAGS "${COMMON_FLAGS} -DNOMINMAX")
-ENDIF(WIN32)
-
-ADD_LIBRARY(MEDOPFactoryEngine SHARED ${MEDOPFactoryEngine_SOURCES})
-SET_TARGET_PROPERTIES(MEDOPFactoryEngine PROPERTIES COMPILE_FLAGS "${COMMON_FLAGS}")
-TARGET_LINK_LIBRARIES(MEDOPFactoryEngine SalomeIDLMED ${COMMON_LIBS})
-
-INSTALL(TARGETS MEDOPFactoryEngine DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB MEDOPFactoryEngine_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${MEDOPFactoryEngine_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
-
-IF(SALOME_ENABLE_PYTHON)
- INSTALL(FILES test_medop_components.py PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS}/xmed)
-ENDIF()
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(image2med)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(MED_PYTHON_SCRIPTS
- image2med.py
- xmedimages.py
- )
-
-INSTALL(FILES ${MED_PYTHON_SCRIPTS} DESTINATION ${SALOME_INSTALL_BINS}/med PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_DEFINITIONS(${MEDFILE_DEFINITIONS} ${XDR_DEFINITIONS} ${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-INCLUDE(${QT_USE_FILE})
-SET(QT_LIBS "${QT_LIBRARIES}")
-INCLUDE(UseQt4Ext)
-
-ADD_SUBDIRECTORY(dialogs)
-
-
-SET(MEDOPGUI_SOURCES
- MEDOPFactoryClient.cxx
- XmedConsoleDriver.cxx
- WorkspaceController.cxx
- XmedDataModel.cxx
- MEDEventListener_i.cxx
- MEDOPModule.cxx
- DatasourceController.cxx
- factory.cxx
-)
-
-SET(MEDOPGUI_HEADERS MEDOPModule.hxx MEDEventListener_i.hxx WorkspaceController.hxx DatasourceController.hxx)
-
-QT4_WRAP_CPP(MEDOPGUI_HEADERS_MOC ${MEDOPGUI_HEADERS})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CAS_INCLUDE_DIRS}
- ${Boost_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${GUI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${CMAKE_CURRENT_SOURCE_DIR}/dialogs
- ${CMAKE_CURRENT_BINARY_DIR}/dialogs
- ${CMAKE_CURRENT_SOURCE_DIR}/../cmp
- ${CMAKE_CURRENT_SOURCE_DIR}/../../MEDGUI
- ${PROJECT_BINARY_DIR}/idl
- ${PROJECT_BINARY_DIR}
-)
-
-SET(MEDOPGUITS_SOURCES
- MED_images.ts
- MED_msg_en.ts
- MED_msg_fr.ts
- MED_msg_ja.ts
- MEDOP_msg_en.ts
- MEDOP_msg_fr.ts
- MEDOP_msg_ja.ts
-)
-
-SET(COMMON_FLAGS
- ${CAS_KERNEL}
- ${QT_MT_LIBRARIES}
- ${OMNIORB_LIBRARIES}
- ${PLATFORM_LIBRARIES}
- ${BOOST_LIBRARIES}
- SalomeIDLMED
- MEDOPGUI_dialogs
- MEDOPFactoryEngine
- ${GUI_qtx}
- ${GUI_suit}
- ${GUI_SalomeObject}
- ${KERNEL_SalomeLifeCycleCORBA}
- ${KERNEL_SalomeKernelHelpers}
- ${GUI_SalomeApp}
- ${GUI_SalomeGuiHelpers}
- ${GUI_SalomeTreeData}
- ${KERNEL_OpUtil}
- ${GUI_CAM}
- ${GUI_LightApp}
- ${GUI_PyConsole}
-)
-
-ADD_LIBRARY(MEDOPGUI SHARED ${MEDOPGUI_SOURCES} ${MEDOPGUI_HEADERS_MOC})
-IF(WITH_MEDMEMGUI)
- SET_TARGET_PROPERTIES(MEDOPGUI PROPERTIES COMPILE_FLAGS "-D__WITH_MEDMEMGUI__")
-ENDIF(WITH_MEDMEMGUI)
-TARGET_LINK_LIBRARIES(MEDOPGUI ${COMMON_FLAGS})
-
-INSTALL(TARGETS MEDOPGUI DESTINATION ${SALOME_INSTALL_LIBS})
-QT4_INSTALL_TS_RESOURCES("${MEDOPGUITS_SOURCES}" "${SALOME_MED_INSTALL_RES_DATA}")
-
-FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_DEFINITIONS(${CAS_DEFINITIONS} ${BOOST_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE(UseQt4Ext)
-
-SET(MEDOPGUI_dialogs_FORMS
- GenericDialog.ui
- DlgAlias.ui
- DlgUseInWorkspace.ui
- DlgChangeUnderlyingMesh.ui
- DlgInterpolateField.ui
- DlgImageToMed.ui
-)
-QT4_WRAP_UI(MEDOPGUI_dialogs_FORMS_HEADERS ${MEDOPGUI_dialogs_FORMS})
-
-SET(MEDOPGUI_dialogs_FILES
- GenericDialog.hxx
- DlgAlias.hxx
- DlgUseInWorkspace.hxx
- DlgChangeUnderlyingMesh.hxx
- DlgInterpolateField.hxx
- DlgImageToMed.hxx
-)
-QT4_WRAP_CPP(MEDOPGUI_dialogs_HEADERS_MOC ${MEDOPGUI_dialogs_FILES})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${CAS_INCLUDE_DIRS}
- ${Boost_INCLUDE_DIRS}
- ${PTHREAD_INCLUDE_DIR}
- ${CMAKE_CURRENT_BINARY_DIR}
- ${GUI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_SOURCE_DIR}/..
- ${QT4_INCLUDE_DIRECTORY}
-)
-
-SET(MEDOPGUI_dialogs_SOURCES
- GenericDialog.cxx
- DlgAlias.cxx
- DlgUseInWorkspace.cxx
- DlgChangeUnderlyingMesh.cxx
- DlgInterpolateField.cxx
- DlgImageToMed.cxx
-)
-
-ADD_LIBRARY(MEDOPGUI_dialogs SHARED ${MEDOPGUI_dialogs_SOURCES} ${MEDOPGUI_dialogs_HEADERS_MOC} ${MEDOPGUI_dialogs_FORMS_HEADERS})
-TARGET_LINK_LIBRARIES(MEDOPGUI_dialogs ${CAS_KERNEL} ${QT_LIBRARIES} ${KERNEL_SalomeIDLKernel}
- ${GUI_SalomeGuiHelpers} ${OMNIORB_LIBRARIES} ${GUI_qtx} ${GUI_suit} ${PLATFORM_LIBRARIES}
- ${KERNEL_SalomeLifeCycleCORBA} ${KERNEL_SalomeKernelHelpers} ${GUI_SalomeGuiHelpers})
-INSTALL(TARGETS MEDOPGUI_dialogs DESTINATION ${SALOME_INSTALL_LIBS})
-
-#
-# ---------------------------------------------------------
-# Unit test programs
-# ---------------------------------------------------------
-#
-ADD_EXECUTABLE(dlgTester dlgTester.cxx)
-TARGET_LINK_LIBRARIES(dlgTester MEDOPGUI_dialogs ${QT_LIBS} ${PLATFORM_LIBS})
-INSTALL(TARGETS dlgTester DESTINATION ${SALOME_INSTALL_BINS})
-#ADD_TEST(dlgTester dlgTester)
-
-FILE(GLOB COMMON_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+++ /dev/null
-# Copyright (C) 2007-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(testfiles)
-
-SET(MED_RESOURCES_FILES
- datasource_add.png
- datasource_changeUnderlyingMesh.png
- datasource_interpolateField.png
- datasource_expandfield.png
- datasource_field.png
- datasource_mesh.png
- datasource.png
- datasource_use.png
- datasource_view.png
- fileimport-32.png
- folder.png
- image_add.png
- MEDOP.png
- MEDOP_small.png
- workspace_clean.png
- workspace_save.png
- )
-INSTALL(FILES ${MED_RESOURCES_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA})
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(MED_FILES
- testfield.med
- smallmesh_varfield.med
- smallmesh_constfield.med
- bigmesh.med
- fieldlena.med
- timeseries.med
- parametric_01.med
- parametric_02.med
- enceinte-axis-E500000.med
- enceinte-axis-E600000.med
- entaille.med
- padderoutput.med
- )
-
-INSTALL(FILES ${MED_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medop_testfiles)
-
-SET(MED_IMG_FILES
- irm_test1.png
- irm_test2.png
- # extra
- README.txt
- champ_altitude_MAP.pgm
- )
-
-INSTALL(FILES ${MED_IMG_FILES} DESTINATION ${SALOME_MED_INSTALL_RES_DATA}/medop_testfiles)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_SUBDIRECTORY(xmedpy)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-SET(PYFILES_TO_INSTALL
- __init__.py
- fieldproxy.py
- fieldtools.py
- fieldguide.py
- cmdtools.py
-# For the control of PARAVIS and VISU
- driver_pvis.py
- driver_visu.py
-# For the medop.sh executable program
- medop.py
-# Modules that are required for test or tutorial purposes only:
- properties.py
- )
-
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_PYTHON}/xmed)
-
-SET(TEST_SCRIPTS_XMED
- tests/test_xmed_fieldOperations.py
- tests/test_xmed_uiEventListener.py
- tests/test_xmed_visualisation.py
- )
-
-INSTALL(FILES ${TEST_SCRIPTS_XMED} PERMISSIONS OWNER_EXECUTE OWNER_WRITE OWNER_READ GROUP_EXECUTE GROUP_READ WORLD_EXECUTE WORLD_READ DESTINATION ${SALOME_INSTALL_BINS}/xmed)
\ No newline at end of file
+++ /dev/null
-Note that this test scripts required the PIL python library
-
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This configuration comes in extension with the standard configuration
-# defined by the file envlight.sh for image processing and math
-# processing.
-
-#------ Python Imaging Library ------
-PILDIR=/opt/programs/salome/workspace/prerequisites/install/Pil-117-py266-tcl859-tk859
-export PATH=${PILDIR}/bin:$PATH
-export PYTHONPATH=${PILDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-#------ Numpy ------
-NUMPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Numpy-151-py266-la331
-export PATH=${NUMPY_DIR}/bin:${PATH}
-export PYTHONPATH=${NUMPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-# ------ Scipy ------
-SCIPY_DIR=/opt/programs/salome/workspace/prerequisites/install/Scipy-090-py266-la331-sw204-nu151
-export PYTHONPATH=${SCIPY_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-# WARN: Matplot, sip and pyqt are requires for the plotter used in
-# lagrange.py (could be optional)
-
-# ------ Matplot ----
-MATPLOT_DIR=/opt/programs/salome/workspace/prerequisites/install/Matplotlib-110-py266-set06c11-num151
-export PYTHONPATH=${MATPLOT_DIR}/lib/python2.6/site-packages:${PYTHONPATH}
-
-#------ sip ------
-SIPDIR=/opt/programs/salome/workspace/prerequisites/install/Sip-4132-py266
-export PATH=${SIPDIR}/bin:${PATH}
-export PYTHONPATH=${SIPDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-export LD_LIBRARY_PATH=${SIPDIR}/lib/python2.6/site-packages:${LD_LIBRARY_PATH}
-
-PYQTDIR=/opt/programs/salome/workspace/prerequisites/install/Pyqt-491p1-py266-qt463p2-sip4132
-#export PYQT_SIPS=${PYQTDIR}/share/sip
-#export PYUIC=${PYQTDIR}/bin/pyuic4
-export PYTHONPATH=${PYQTDIR}/lib/python2.6/site-packages:${PYTHONPATH}
-export PATH=${PYQTDIR}/bin:${PATH}
+++ /dev/null
-P5
-# CREATOR: GIMP PNM Filter Version 1.1
-6 6
-255
-¿¿ÿÿ¿¿¿¿ÿÿ¿¿ÿÿ\ 4\aÿÿÿÿ\ 3\ 4ÿÿ¿¿ÿÿ¿¿¿¿ÿÿ¿¿
\ No newline at end of file
+++ /dev/null
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This illustrates how to make a mesh partition using the value of a
-# field defined on this mesh (for example to extract the cells where
-# the field takes a value greater than a threshold L.
-# (Anthony Geay, nov. 2012)
-
-# WRN: this use case does not require a med input file because the
-# data (mesh and field) to work with are created from scratch.
-
-from MEDCoupling import *
-
-# =======================================================
-# Creation of the input data (mesh and field)
-# =======================================================
-#
-# We prepare the input field from scratch instead of load it from a
-# file, but there is no difference
-from MEDCouplingDataForTest import MEDCouplingDataForTest
-m3D=MEDCouplingDataForTest.build3DTargetMesh_1()
-m3D.setName("m3D")
-a=DataArrayDouble.New([1.,1.,1.,-1.,-1.,-1.,-1.,-1.])
-field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
-field.setMesh(m3D)
-field.setArray(a)
-field.checkCoherency()
-field.setName("f")
-
-# Save the field (and associated mesh)
-from MEDLoader import MEDLoader
-MEDLoader.WriteField("partition_input.med",field,True)
-
-# =======================================================
-# Determine the border skin mesh
-# =======================================================
-#
-# We have to determine the 2D mesh that delimits the volume where the
-# field is greater than a threshold L from the volume where the field
-# is lower than this threshold (in this example L=0).
-#
-# WRN: This works in SALOME V660 only
-#
-# _T1A
-L=0.
-arr = field.getArray()
-ids = arr.getIdsInRange(L,1e300)
-m3DSub = field.getMesh()[ids]
-skin = m3DSub.computeSkin()
-MEDLoader.WriteUMesh("partition_skin.med",skin,True);
-# _T1B
-
-# =======================================================
-# Compare to the result in SALOME V650
-# =======================================================
-# SALOME V650 requires a more complicated syntax.
-m2D,desc,descI,revDesc,revDescI=m3DSub.buildDescendingConnectivity()
-numberOf3DVolSharing=revDescI.deltaShiftIndex()
-ids2D=numberOf3DVolSharing.getIdsEqual(1)
-skin_V650=m2D[ids2D]
-# We can check if the two skins are identical
-print "Are two meshes equal between V660 and V650 ?",skin.isEqual(skin_V650,1e-12)
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-
-class Function:
- def __init__(self, **kwargs):
- self.kwargs = kwargs
-
- def function(self, x, **kwargs):
- # This should be implemented in a derived class
- raise Runtime("function is not implemented yet")
-
- def __call__(self, x):
- # The argument can be a scalar or a list, we have to check
- # that first.
- if isIterable(x):
- y = map(self,x)
- else:
- y = self.function(x, **self.kwargs)
- return y
-
-def isIterable(x):
- """
- This returns True if the parameter is an iterable, a list or an
- array, or any collection object.
- """
- try:
- len(x)
- return True
- except TypeError, e:
- return False
-
-#
-# =====================================================
-# Implementation of standard functions. All function are normalized
-# function: the xrange is [0,1], the yrange is [0,1]
-import numpy
-from scipy.constants import pi
-
-# Note that in this situation, the create another constructor because
-# the parameters can be deduced from one single parameter xlimit. The
-# constructor must create a kwargs dictionary that map the arguments
-# of the method "function"
-class FuncConique(Function):
- def __init__(self,xlimit):
- a = 1./(xlimit*xlimit-2*xlimit+1)
- b = -2.*a
- c = a
- d = 1/(xlimit*xlimit)
- # We call the super constructor to redefine the kwarg
- # attribute, so that it fits with the arguments of the method
- # "function":
- Function.__init__(self,xlimit=xlimit,a=a,b=b,c=c,d=d)
- # NOTE: Instead of calling the super constructor, we could
- # redefine directly the kwargs attribute:
- #self.kwargs = {"xlimit":xlimit,
- # "a":a, "b":b,
- # "c":c, "d":d}
-
- def function(self,x,xlimit,a,b,c,d):
- if x<xlimit:
- y=d*x*x
- else:
- y=a*x*x+b*x+c
- return y
-
-
-class FuncChapeau(Function):
- def function(self,x,xlimit):
- if x<xlimit:
- y=x/xlimit
- else:
- y=(x-1)/(xlimit-1)
- return y
-
-class FuncStiffExp(Function):
- """
- xlimit : the x position of the top of the function
- stiffness : the higher it is, the stiffer the function is
- """
- def function(self,x,xlimit,stiffness):
- if x<xlimit:
- y=numpy.exp(stiffness*(x-xlimit))
- else:
- y=numpy.exp(-stiffness*(x-xlimit))
- return y
-
-class FuncCosinus(Function):
- def __init__(self,nbPeriods):
- # The pulsation w must be choosen so that w*xmax=n*2pi where
- # xmax=1 and n is an integer that corresponds to the number of
- # oscilations on the xrange [0,xmax].
- w=nbPeriods*2*pi
- Function.__init__(self,w=w)
-
- def function(self,x,w):
- y=numpy.cos(w*x)
- return y
-
-class FuncStiffPulse(Function):
- def __init__(self,xlimit, stiffness, nbPeriods):
- self.stiffexp=FuncStiffExp(xlimit=xlimit,stiffness=stiffness)
- self.cosinus=FuncCosinus(nbPeriods=nbPeriods)
- Function.__init__(self)
-
- def function(self,x):
- y=self.stiffexp(x)*numpy.abs(self.cosinus(x))
- return y
-
-class FuncHeaviside(Function):
- def function(self,x,xlimit):
- if x<xlimit:
- y=0
- else:
- y=1
- return y
-
-class FuncPorte(Function):
- def function(self,x,xinf,xsup):
- if x<xinf or x>xsup:
- y=0
- else:
- y=1
- return y
-
-import lagrange
-class FuncLagrange(Function):
- def __init__(self,points):
- """
- @points : a dictionary whose keys are x values and values are
- y values to be considered as fixed points for interpolation.
- """
- Function.__init__(self)
- self.polynom = lagrange.lagrange(points)
-
- def function(self,x):
- return self.polynom(x)
-
-#
-# =====================================================
-# Unit tests functions
-# =====================================================
-#
-class MyFunction(Function):
- def function(self,x,a,b):
- y=a*x+b
- return y
-
-def TEST_Function():
- # The parameters of the constructor of MyFunction must be
- # consistent with the kwargs parameters of the method function of
- # the class MyFunction (it must map exactly).
- f=MyFunction(a=3.,b=7.)
-
- x=2
- y_ref = 3.*x+7.
- y_res = f(x)
- print y_ref
- print y_res
- if y_ref != y_res:
- print "ERR"
- else:
- print "OK"
-
-def TEST_Function_withIterable():
- f=MyFunction(a=3.,b=1.)
-
- arrX = [0., 1., 2., 3.]
- arrY = f(arrX)
-
- arrY_ref = [1., 4., 7., 10.]
- print "arrY res =%s"%arrY
- print "arrY ref =%s"%arrY_ref
-
-def TEST_FuncConique():
- f=FuncConique(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncChapeau():
- f=FuncChapeau(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncStiffExp():
- f=FuncStiffExp(xlimit=0.3,stiffness=20.)
- from plotter import plot
- plot(f)
-
-def TEST_FuncCosinus():
- f=FuncCosinus(nbPeriods=20)
- from plotter import plot
- plot(f, step=0.001)
-
-def TEST_FuncStiffPulse():
- f=FuncStiffPulse(xlimit=0.3,stiffness=50,nbPeriods=15)
- from plotter import plot
- plot(f, step=0.001)
-
-def TEST_FuncHeaviside():
- f=FuncHeaviside(xlimit=0.3)
- from plotter import plot
- plot(f)
-
-def TEST_FuncPorte():
- f=FuncPorte(xinf=0.3,xsup=0.4)
- from plotter import plot
- plot(f)
-
-def TEST_customize_01():
- f=FuncStiffPulse(xlimit=0.3,stiffness=40,nbPeriods=20)
-
- # One can customize the final function as follow (in this example,
- # a linear transform)
- def myfunc(x):
- y=5*f(x)+2
- return y
-
- from plotter import plot
- plot(myfunc, step=0.001)
-
-def TEST_customize_02():
- f=FuncHeaviside(xlimit=0.3)
-
- # One can customize the final function as follow (in this example,
- # reverse of heaviside)
- def myfunc(x):
- y=1-f(x)
- return y
-
- from plotter import plot
- plot(myfunc)
-
-def TEST_FuncLagrange():
- points = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
- f=FuncLagrange(points)
- from plotter import plot
- plot(f)
-
-if __name__ == "__main__":
- TEST_Function()
- TEST_Function_withIterable()
- #TEST_FuncConique()
- #TEST_FuncChapeau()
- #TEST_FuncStiffExp()
- #TEST_FuncCosinus()
- #TEST_FuncStiffPulse()
- #TEST_FuncHeaviside()
- #TEST_FuncPorte()
- #TEST_customize_01()
- #TEST_customize_02()
- #TEST_FuncLagrange()
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-import scipy
-def lagrange(points):
- '''
- This returns a polynom that fits the points specified in the input
- dictionary (lagrange interpolation). In this dictionary, the keys
- are x value and the values are y corresponding values
- (i.e. y=polynom(x)). The polynom is a scipy polynom and then is a
- callable (can be used as a function).
- '''
- tmp = scipy.poly1d([0])
- result=scipy.poly1d([0])
-
- for i in points.keys():
- numerator=scipy.poly1d([1])
- denom = 1.0
- for j in points.keys():
- if (i != j):
- tmp = scipy.poly1d([1,-j])
- numerator = numerator * tmp
- denom = denom * (i - j)
- tmp = (numerator/denom) * points.get(i)
- result = result + tmp
-
- return result
-
-def points_usingfunction(arrX,function):
- points={}
- for x in arrX:
- points[x] = function(x)
- return points
-
-def points_usingarray(arrX,arrY):
- points={}
- for i in range(len(arrX)):
- x=arrX[i]
- y=arrY[i]
- points[x] = y
- return points
-
-def sortdict(points):
- # Sort this dictionary by keys and returns 2 lists, the list of X
- # and the list of Y, the whole ordered by X
- keys = points.keys()
- keys.sort()
- return keys, [points[key] for key in keys]
-
-import pylab
-import numpy
-def plot(function, start=0., stop=1., step=0.01):
- """
- The parameter function must be a callable.
- """
- arrX=numpy.arange(start, stop, step, dtype='float64')
- # function is a callable
- arrY=map(function,arrX)
- pylab.plot(arrX, arrY)
- pylab.show()
-
-
-# ---
-# The points does not need to be ordered by x values
-def TEST_lagrange_01():
- input = {0.:5, 0.2:10, 0.9:10, 0.6:21, 1:8}
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-def TEST_lagrange_02():
- input = {0.:0., 0.5:1., 1.:0.}
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# ---
-# One can create the input dictionary from arrays
-def TEST_lagrange_usingarrays_01():
- arrX = [0., 0.2, 0.9, 0.6, 1]
- arrY = [5, 10, 10, 21, 8]
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# Another example using numpy
-def TEST_lagrange_usingarrays_02():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- arrY=numpy.zeros(len(arrX), dtype='float64')
- arrY[3]=2
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# ---
-# One can create the input dictionary from a function applied to an
-# array of X values
-
-# simple method for mathematical functions
-def TEST_lagrange_usingfunction_01():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- arrY=numpy.cos(10*arrX)
- input = points_usingarray(arrX,arrY)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-# General method
-xlimit=0.8
-def chapeau(x):
- if x<xlimit:
- y=x
- else:
- y=2*xlimit-x
- return y
-
-def TEST_lagrange_usingfunction_01():
- arrX=numpy.arange(start=0., stop=1., step=0.1, dtype='float64')
- input = points_usingfunction(arrX,chapeau)
- polynom = lagrange(input)
- print polynom
- plot(function=polynom, start=0., stop=1., step=0.001)
-
-
-if __name__ == "__main__":
- #TEST_lagrange_01()
- TEST_lagrange_02()
- #TEST_lagrange_usingarrays_01()
- #TEST_lagrange_usingarrays_02()
- #TEST_lagrange_usingfunction_01()
- #TEST_lagrange_usingfunction_01()
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-import pylab
-import numpy
-def plot(function, start=0., stop=1., step=0.01):
- """
- The parameter function must be a callable.
- """
- arrX=numpy.arange(start, stop, step, dtype='float64')
- # function is a callable
- arrY=map(function,arrX)
- pylab.plot(arrX, arrY)
- pylab.show()
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-import CORBA
-import PARAVIS_Gen_idl
-import SALOME_ContainerManager_idl
-
-from SALOME_NamingServicePy import SALOME_NamingServicePy_i
-
-from MEDCouplingCorba import *
-
-def createALocalMesh():
- targetCoords=[ 0., 0., 0., 50., 0., 0. , 200., 0., 0. , 0., 50., 0., 50., 50., 0. , 200., 50., 0., 0., 200., 0., 50., 200., 0. , 200., 200., 0. ,
- 0., 0., 50., 50., 0., 50. , 200., 0., 50. , 0., 50., 50., 50., 50., 50. , 200., 50., 50., 0., 200., 50., 50., 200., 50. , 200., 200., 50. ,
- 0., 0., 200., 50., 0., 200. , 200., 0., 200. , 0., 50., 200., 50., 50., 200. , 200., 50., 200., 0., 200., 200., 50., 200., 200. , 200., 200., 200. ];
- targetConn=[0,1,4,3,9,10,13,12, 1,2,5,4,10,11,14,13, 3,4,7,6,12,13,16,15, 4,5,8,7,13,14,17,16,
- 9,10,13,12,18,19,22,21, 10,11,14,13,19,20,23,22, 12,13,16,15,21,22,25,24, 13,14,17,16,22,23,26,25];
- targetMesh=MEDCouplingUMesh.New();
- targetMesh.setMeshDimension(3);
- targetMesh.setName("MyMesh3D");
- targetMesh.setDescription("build3DMesh");
- targetMesh.allocateCells(12);
- for i in xrange(8):
- targetMesh.insertNextCell(NORM_HEXA8,8,targetConn[8*i:8*(i+1)]);
- pass
- targetMesh.finishInsertingCells();
- myCoords=DataArrayDouble.New();
- myCoords.setValues(targetCoords,27,3);
- targetMesh.setCoords(myCoords)
- myCoords.setName("check in case")
- return targetMesh;
-
-def createALocalField1():
- m=createALocalMesh()
- field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([1.,11.,101.,1001., 2.,12.,102.,1002., 3.,13.,103.,1003., 4.,14.,104.,1004., 5.,15.,105.,1005., 6.,16.,106.,1006., 7.,17.,107.,1007., 8.,18.,108.,1008.,],8,4)
- field.setArray(da)
- field.setName("vitoo")
- field.setTime(4.5,3,4)
- return field
-
-def createALocalField2():
- m=createALocalMesh()
- field=MEDCouplingFieldDouble.New(ON_NODES,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([float(3*i) for i in xrange(27)],27,1)
- field.setArray(da)
- field.setName("vitooNode")
- field.setTime(4.7,9,14)
- return field
-
-def createALocalMultiField3():
- fName="FieldOverTimeCorba"
- m=createALocalMesh()
- nbOfFields=100
- fs=nbOfFields*[None]
- for i in xrange(nbOfFields):
- fs[i]=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- fs[i].setMesh(m)
- da=DataArrayDouble.New()
- da.setValues([0.,1.,2.+i,3.,4.,5.,7.],8,1)
- fs[i].setArray(da)
- fs[i].setName(fName)
- fs[i].setTime(1.2+i,9,14)
- pass
- ret=MEDCouplingFieldOverTime.New(fs);
- return ret
-
-def createALocalCMesh4():
- mesh=MEDCouplingCMesh.New();
- coordsX=DataArrayDouble.New();
- arrX=[ -1., 1., 2., 4. ]
- coordsX.setValues(arrX,4,1);
- coordsY=DataArrayDouble.New();
- arrY=[ -2., 4., 8. ]
- coordsY.setValues(arrY,3,1);
- coordsZ=DataArrayDouble.New();
- arrZ=[ -3., 3., 6., 12., 17. ]
- coordsZ.setValues(arrZ,5,1);
- mesh.setCoords(coordsX,coordsY,coordsZ);
- mesh.setName("CMeshSample")
- return mesh
-
-def createALocalField5():
- m=createALocalCMesh4()
- field=MEDCouplingFieldDouble.New(ON_CELLS,ONE_TIME)
- field.setMesh(m)
- da=DataArrayDouble.New()
- field.setTime(14.5,0,0)
- da.setValues([float(7*i) for i in xrange(24)],24,1)
- field.setName("MeshOnCMesh");
- field.setArray(da)
- return field;
-
-
-######
-
-orb = CORBA.ORB_init([], CORBA.ORB_ID)
-poa=orb.resolve_initial_references("RootPOA");
-mgr=poa._get_the_POAManager();
-mgr.activate();
-
-###### Searching for
-
-naming_service = SALOME_NamingServicePy_i(orb)
-rp=SALOME_ContainerManager_idl._0_Engines.ResourceParameters("","","",["PARAVIS"],1,10,10,1,1,"first",[])
-cp=SALOME_ContainerManager_idl._0_Engines.ContainerParameters("","get","",1,False,"",rp)
-sm=naming_service.Resolve("/ContainerManager")
-cont=sm.GiveContainer(cp)
-paraviz=naming_service.Resolve("/Containers/%s/FactoryServer/PARAVIS_inst_1"%(cont.getHostName()))
-
-######
-
-meshCorba=MEDCouplingUMeshServant._this(createALocalMesh())
-ior=orb.object_to_string(meshCorba)
-print "mesh : ",ior
-
-f1=MEDCouplingFieldDoubleServant._this(createALocalField1())
-ior2=orb.object_to_string(f1)
-print "Field on cell ",ior2
-
-f2=MEDCouplingFieldDoubleServant._this(createALocalField2())
-ior3=orb.object_to_string(f2)
-print "Field on node ",ior3
-
-fs3=MEDCouplingFieldOverTimeServant._this(createALocalMultiField3())
-fs3.Register()
-ior4=orb.object_to_string(fs3)
-print "Fields over time ",ior4
-
-m2=MEDCouplingCMeshServant._this(createALocalCMesh4())
-ior5=orb.object_to_string(m2)
-print "CMesh 2 : ",ior5
-
-f5=MEDCouplingFieldDoubleServant._this(createALocalField5())
-ior6=orb.object_to_string(f5)
-print "Field on cell CMesh ",ior6
-
-script="""
-src1 = ParaMEDCorbaPluginSource()
-src1.IORCorba = '%s'
-asc=GetAnimationScene()
-rw=GetRenderView()
-dr=Show()\ndr.Visibility = 1
-"""
-
-content=script%(ior4)
-paraviz.ExecuteScript(content)
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This script illustrates the basic usage of MEDCoupling and MEDLoader
-# to generate test data files for various cases of med operation. It
-# illustrates also the usage of numpy to specify the values of the
-# fields when defined on a cartesian mesh (grid).
-# (gboulant - 11/07/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-import numpy
-
-#
-# ===============================================================
-# Helper functions to create meshes
-# ===============================================================
-#
-
-def createGridMesh(meshName, nbCellsX, nbCellsY):
- """
- The mesh is created using MEDCoupling. The code below creates a
- cartesian mesh as a grid with nbCellsX segments in the X direction
- and nbCellsY in the Y direction (nb. cells = nbCellsX * nbCellsY)
- """
- print "Creating grid mesh of size %sx%s"%(nbCellsX, nbCellsY)
- cmesh=MC.MEDCouplingCMesh.New();
-
- # Create X coordinates
- nbNodesX = nbCellsX+1
- stepX = 0.1
- arrX = [float(i * stepX) for i in range(nbNodesX)]
- coordsX=MC.DataArrayDouble.New()
- coordsX.setValues(arrX,nbNodesX,1)
-
- # Create Y coordinates
- nbNodesY = nbCellsY+1
- stepY = 0.1
- arrY=[float(i * stepY) for i in range(nbNodesY)]
- coordsY=MC.DataArrayDouble.New()
- coordsY.setValues(arrY,nbNodesY,1)
-
- # Create the grid
- cmesh.setCoords(coordsX,coordsY)
- cmesh.setName(meshName)
-
- return cmesh
-
-def unstructuredMesh(cartesianMesh):
- """
- Convert the cartesian mesh in unstructured mesh for the need of
- write function of MEDLoader
- """
- print "Creating unstructured mesh from %s"%(cartesianMesh.getName())
- umesh=cartesianMesh.buildUnstructured();
- umesh.setName(cartesianMesh.getName())
- return umesh
-
-#
-# ===============================================================
-# Creating a cartesian mesh
-# ===============================================================
-#
-# The size is the number of discrete values in a direction, and then
-# corresponds to the number of cells in that direction.
-size=80
-#size=512
-
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The parameter
-# "size" is considered to be a number of cells (intervals). The number
-# of nodes in that direction is size+1.
-# <<<
-
-nbCellsX = size
-nbNodesX = nbCellsX+1
-
-nbCellsY = size # The size could be different than the X size
-nbNodesY = nbCellsY+1
-
-meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
-cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
-umesh = unstructuredMesh(cmesh)
-medFileName="gendata.med"
-ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
-
-#
-# ===============================================================
-# Creating a scalar field, working with numpy
-# ===============================================================
-#
-
-def createField(fieldName,gridMesh,
- numpy2Darray,typeOfField=MC.ON_CELLS,
- iteration=0):
- """
- The number of values for the fields is deduced from the sizes of
- the numpy array. If typeOfField is ON_CELLS, the size is considered
- as the number of cells, otherwise it's considered as the number of
- nodes. In any case, it must be consistent with the dimensions of
- the numpy 2D array.
- """
- print "Creating field %s with iteration=%s"%(fieldName,iteration)
-
- # The sizes are deduced from the numpy array. Note that if
- # typeOfField is ON_CELLS, then the size should correspond to the
- # number of cells, while if typeOfField is ON_NODES, then the size
- # should correspond to the number of nodes
- [sizeX,sizeY] = numpy2Darray.shape
-
- # We first have to reshape the 2D numpy array in a 1D vector that
- # concatenate all the rows
- data=numpy2Darray.reshape(1,sizeX*sizeY)[0]
- # Then, we can create a simple list as required by the MEDCoupling
- # DataArrayDouble. Note also the usage of float type because
- # MEDCoupling works only with real numbers
- listdata=list(data)
-
- # Create the field using the list obtained from the numpy array
- field = MC.MEDCouplingFieldDouble.New(typeOfField,MC.ONE_TIME);
- field.setName(fieldName);
- field.setMesh(gridMesh);
- field.setIteration(iteration)
- field.setTimeValue(float(iteration))
-
- nbComponents=1 # Only one single component for a scalar field
- nbCells=sizeX*sizeY
- dataArray=MC.DataArrayDouble.New();
- dataArray.setValues(listdata,nbCells,nbComponents)
- field.setArray(dataArray);
-
- return field
-
-def writeField(fieldName, numpy2Darray,
- typeOfField=MC.ON_CELLS,
- iteration=0):
-
- field = createField(fieldName, umesh, numpy2Darray,
- typeOfField, iteration)
- createFromScratch=False
- ML.MEDLoader.WriteField(medFileName,field,createFromScratch)
-
-
-def createTestNumpy2DArray(sizeX, sizeY):
- """
- This illustrates how to create a numpy 2D array for input of the
- createField function.
- """
- rows=[]
- for irow in range(sizeY):
- row = numpy.arange(start = irow*sizeY,
- stop = irow*sizeY+sizeX,
- step = 1,
- dtype='float64')
- rows.append(row)
-
- numpy2Darray = numpy.vstack(rows)
- return numpy2Darray
-
-def createTestFieldOnCells():
- # Test field on cells
- numpy2Darray = createTestNumpy2DArray(sizeX=nbCellsX, sizeY=nbCellsY)
- writeField("FieldOnCells", numpy2Darray,
- typeOfField=MC.ON_CELLS)
-
-def createTestFieldOnNodes():
- # Test field on nodes
- numpy2Darray = createTestNumpy2DArray(sizeX=nbNodesX, sizeY=nbNodesY)
- writeField("FieldOnNodes", numpy2Darray,
- typeOfField=MC.ON_NODES)
-
-
-#
-# =================================================
-# Creating a time series
-# =================================================
-#
-
-# -------------------------------------------------
-# Simple demo of the principles
-# -------------------------------------------------
-
-# In these functions, (x,y) are the indexes of the element in the
-# numpy array. Note that theses indexes maps the indexes of the
-# cartesian mesh.
-
-# A function can be a simple python function ...
-def f1(x,y):
- z = 10*x
- print "x=%s\ny=%s\nz=%s"%(x,y,z)
- return z
-
-# ... but also a more sophisticated callable object, for example to
-# defines some parameters
-class Function(object):
- def __init__(self, sizeX, sizeY, param):
- self.sizeX = sizeX
- self.sizeY = sizeY
- self.param = param
-
- def function(self, x,y):
- z = self.param*x
- print "x=%s\ny=%s\nz=%s"%(x,y,z)
- return z
-
- def __call__(self, x,y):
- return self.function(x,y)
-
-fOnNodes=Function(sizeX=nbNodesX, sizeY=nbNodesY, param=10)
-fOnCells=Function(sizeX=nbCellsX, sizeY=nbCellsY, param=3)
-
-def createFunctionField_01():
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
- f=fOnNodes
- numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
- writeField("FieldOnNodesUsingFunc", numpy2Darray,typeOfField)
-
- f=fOnCells
- sizeX=nbCellsX
- sizeY=nbCellsY
- typeOfField=MC.ON_CELLS
- numpy2Darray = numpy.fromfunction(f,(sizeX,sizeY),dtype='float64')
- writeField("FieldOnCellsUsingFunc", numpy2Darray,typeOfField)
-
-
-# -------------------------------------------------
-# Using the pyfunctions package to generate data
-# -------------------------------------------------
-
-def createNumpy2DArrayWithFunc(sizeX, sizeY, function):
- """
- @function : a callable than can be used as a function of X.
- Typically function should be an instance of Function object
- defined in pyfunctions.functions.
- """
-
- # X coordinates should range between 0 and 1 to use the normalized
- # functions. We have to generate sizeX points:
- step=1./sizeX
- arrX=[float(i * step) for i in range(sizeX)]
-
- values = function(arrX)
-
- # Then on can create the base row for the numpy 2D array
- rowX = numpy.array(values)
- # and replicate this row along the Y axis
- rows=[]
- for irow in range(sizeY):
- rows.append(rowX)
-
- numpy2Darray = numpy.vstack(rows)
- return numpy2Darray
-
-from pyfunctions.functions import FuncStiffPulse
-def createNumpy2DArrayWithFuncStiff(sizeX, sizeY):
- f=FuncStiffPulse(xlimit=0.3,stiffness=30,nbPeriods=10)
- return createNumpy2DArrayWithFunc(sizeX, sizeY, f)
-
-def createFunctionField_02():
- sizeX=nbCellsX
- sizeY=nbCellsY
- typeOfField=MC.ON_CELLS
- numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
- writeField("FieldOnCellsUsingFunc02", numpy2Darray,typeOfField)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
- numpy2Darray = createNumpy2DArrayWithFuncStiff(sizeX,sizeY)
- writeField("FieldOnNodesUsingFunc02", numpy2Darray,typeOfField)
-
-#
-# =================================================
-# Functions to create custom fields for MEDOP tests
-# =================================================
-#
-def createTimeSeries():
- """
- Create a single med file with a single mesh and a field defined on
- several time steps (time series).
- """
- meshName = "Grid_%sx%s"%(nbCellsX, nbCellsY)
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
- medFileName="timeseries.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- nbIterations=10
- pulseStiffNess = 20
- pulseNbPeriods = 10
- for iteration in range(nbIterations):
- xlimit = float(iteration)/float(nbIterations)
- f=FuncStiffPulse(xlimit,stiffness=pulseStiffNess,nbPeriods=pulseNbPeriods)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField("Pulse",umesh,numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-from pyfunctions.functions import FuncStiffExp
-def createParametrics():
- """
- Create 2 med files containing each a mesh (identical) and a field
- defined on this mesh in each file.
- """
- meshName = "Grid_%sx%s_01"%(nbCellsX, nbCellsY)
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- medFileName="parametric_01.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- f=FuncStiffExp(xlimit=0.3,stiffness=30)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- fieldName = "StiffExp_01"
- field = createField(fieldName,umesh, numpy2Darray,typeOfField)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
- medFileName="parametric_02.med"
- umesh.setName("Grid_%sx%s_02"%(nbCellsX, nbCellsY))
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- f=FuncStiffExp(xlimit=0.4,stiffness=30)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- fieldName = "StiffExp_02"
- field = createField(fieldName,umesh, numpy2Darray,typeOfField)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-def createParametrics_demo():
- """
- Create 2 med files containing each a mesh (identical) and a field
- defined on this mesh in each file.
- """
- meshName = "mesh1"
- cmesh = createGridMesh(meshName, nbCellsX, nbCellsY)
- umesh = unstructuredMesh(cmesh)
-
- sizeX=nbNodesX
- sizeY=nbNodesY
- typeOfField=MC.ON_NODES
-
- listIteration = [0,1,2,3,4]
-
- medFileName="parametric_01.med"
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- fieldName = "field1"
- for iteration in listIteration:
- #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=5)
- f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=10)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
- medFileName="parametric_02.med"
- umesh.setName("mesh2")
- ML.MEDLoader.WriteUMesh(medFileName,umesh,True);
- fieldName = "field2"
- for iteration in listIteration:
- #f=FuncStiffPulse(xlimit=0.3+0.1*iteration,stiffness=10,nbPeriods=6)
- f=FuncStiffExp(xlimit=0.3+0.1*iteration,stiffness=15)
- numpy2Darray = createNumpy2DArrayWithFunc(sizeX,sizeY,f)
- field = createField(fieldName,umesh, numpy2Darray,typeOfField,iteration)
- ML.MEDLoader.WriteField(medFileName,field,False)
-
-
-
-#
-# =================================================
-# Main runner
-# =================================================
-#
-if __name__ == "__main__":
- #createTestFieldOnCells()
- #createTestFieldOnNodes()
- #createFunctionField_01()
- #createFunctionField_02()
- #createTimeSeries()
- createParametrics_demo()
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This use case illustrates the usage of PIL (Python Imaging Library)
-# combined with the MEDCoupling and MEDLoader modules to save an image
-# as a field in a med file.
-# (gboulant - 27/06/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-#
-# ===============================================================
-# We first get data from the test image to render as a field
-# ===============================================================
-#
-import scipy, numpy
-# The data field array may be created from the lena image
-#image = scipy.lena()
-# We could either read a real image using the PIL python package.
-from scipy.misc import pilutil
-image = pilutil.imread("images/avatar.png",True)
-
-
-#from PIL import Image
-#im=Image.open("images/irm.png")
-#im=Image.open("images/lena.png")
-#image=pilutil.fromimage(im,True)
-#image=numpy.asarray(im)
-#print image
-
-dim = len(image.shape)
-print "Image space dimension = %d"%dim
-sizeX = image.shape[1]
-sizeY = image.shape[0]
-
-# The sizes defined the number of pixel in a direction, then the
-# number of cells to create in the mesh in that direction.
-
-# We must reshape the matrix of pixel in a 1D vector that concatenates
-# all the rows, and then convert this vector in a simple list of
-# double as required by the MEDCoupling field specification.
-import numpy
-imageDataNArray = image.reshape(1,sizeX*sizeY)[0]
-print imageDataNArray
-
-imageDataNArrayDouble = numpy.array(imageDataNArray, dtype='float64')
-imageDataArrayDouble = list(imageDataNArrayDouble)
-
-#
-# ===============================================================
-# Creating a cartesian mesh with a grid of the size of the image
-# ===============================================================
-#
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The data values
-# are considered as values defined on cells. With size values in a
-# direction, we have to create size+1 mesh nodes in that direction.
-# <<<
-
-# The mesh is created using MEDCoupling
-cmesh=MC.MEDCouplingCMesh.New();
-cmesh.setName("imagemesh")
-
-# We use an arbitrary step between cells (the value does not matter)
-stepX = 0.1
-nbNodesX = sizeX+1
-arrX = [float(i * stepX) for i in range(nbNodesX)]
-coordsX=MC.DataArrayDouble.New()
-coordsX.setValues(arrX,nbNodesX,1)
-
-stepY = 0.1
-nbNodesY = sizeY+1
-arrY=[float(i * stepY) for i in range(nbNodesY)]
-coordsY=MC.DataArrayDouble.New()
-coordsY.setValues(arrY,nbNodesY,1)
-
-cmesh.setCoords(coordsX,coordsY)
-print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
-
-# WARN: In the current state of development of MEDLoader, only
-# unstructured meshes are supported for writting function in med
-# files. We just have to convert the cartesian mesh in an unstructured
-# mesh before creating the field.
-umesh=cmesh.buildUnstructured();
-umesh.setName("imagemesh")
-
-#
-# ===============================================================
-# Creating a scalar field on the mesh using image data
-# ===============================================================
-#
-
-# Create the field using MEDCoupling
-field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
-field.setName("imagefield");
-field.setMesh(umesh);
-# OPTIONAL: We set an arbitrary time step for test purpose
-field.setIteration(3);
-field.setOrder(0)
-
-dataArray=MC.DataArrayDouble.New();
-nbCells = sizeX*sizeY
-nbComponents=1 # For a scalar field
-
-# This example shows haw to initialize all cell with the same
-# value. Just create an array of size nbCells
-# dataArray.setValues(nbCells*[3.4],nbCells,nbComponents)
-
-dataArray.setValues(imageDataArrayDouble,nbCells,nbComponents)
-field.setArray(dataArray);
-
-# The MEDLoader can be used to save all the stuff in a med file. You
-# just have to specify the field and the MEDLoader will save the
-# underlying mesh.
-createFromScratch=True
-ML.MEDLoader.WriteField("fieldimage.med",field,createFromScratch)
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This simple use case illustrates the basic usage of MEDCoupling and
-# MEDLoader to create a cartesian mesh, define a field on this mesh,
-# and save all the stuff in a med file.
-# (gboulant - 27/06/2011)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-
-#
-# ===============================================================
-# Creating a 512x512 cartesian mesh
-# ===============================================================
-#
-# The size is the number of discrete values in a direction, and then
-# corresponds to the number of cells in that direction.
-size=8
-#size=512
-
-# The mesh is created using MEDCoupling. The code below creates a
-# cartesian mesh as a sizexsize grid
-
-# >>>
-# WARNING: remember the problem of tics and spaces. The data values
-# are considered as values defined on cells. With size values in a
-# direction, we have to create size+1 mesh nodes in that direction.
-# <<<
-
-cmesh=MC.MEDCouplingCMesh.New();
-cmesh.setName("512x512 cartesian mesh")
-
-sizeX = size
-nbNodesX = sizeX+1
-stepX = 0.1
-arrX = [float(i * stepX) for i in range(nbNodesX)]
-print "Size of arrX = %d"%len(arrX)
-
-coordsX=MC.DataArrayDouble.New()
-coordsX.setValues(arrX,nbNodesX,1)
-
-sizeY = size
-nbNodesY = sizeY+1
-stepY = 0.1
-arrY=[float(i * stepY) for i in range(nbNodesY)]
-coordsY=MC.DataArrayDouble.New()
-coordsY.setValues(arrY,sizeY,1)
-
-cmesh.setCoords(coordsX,coordsY)
-print cmesh.getSpaceDimension()
-#print cmesh
-
-# WARN: In the current state of development of MEDLoader, only
-# unstructured meshes are supported for writting function in med
-# files. We just have to convert the cartesian mesh in an unstructured
-# mesh before creating the field.
-umesh=cmesh.buildUnstructured();
-umesh.setName("512x512 unstructured mesh")
-
-# This can be used to save the mesh only (can be visualize using
-# SMESH).
-meshFileName = "umesh.med"
-ML.MEDLoader.WriteUMesh(meshFileName,umesh,True);
-
-# Alternatively, you can use a MEDFileMesh to write the mesh in a
-# file.
-medFileCMesh = ML.MEDFileCMesh.New()
-medFileCMesh.setMesh(cmesh)
-medFileCMesh.setName(cmesh.getName())
-meshFileName = "cmesh.med"
-mode = 2
-medFileCMesh.write(meshFileName,mode)
-
-#
-# ===============================================================
-# Creating a scalar field on the 512x512 mesh
-# ===============================================================
-#
-# For the simple test, we create a field that varies in space as
-# field(x,y)=x+y where x and y are coordinates on the mesh
-
-# --- Field on cells
-
-# Create the field
-field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
-field.setName("AnalyticField_onCells");
-field.setMesh(umesh);
-
-nbComponents=1 # Only one single component for a scalar field
-fillFunction="x+y"
-field.fillFromAnalytic(nbComponents,fillFunction);
-
-# The MEDLoader can be used to save all the stuff in a med file. You
-# just have to specify the field and the MEDLoader will save the
-# underlying mesh.
-createFromScratch=True
-ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
-
-# --- Field on nodes
-
-field = MC.MEDCouplingFieldDouble.New(MC.ON_NODES);
-field.setName("AnalyticField_onNodes");
-field.setMesh(umesh);
-field.fillFromAnalytic(nbComponents,fillFunction);
-createFromScratch=False
-ML.MEDLoader.WriteField("fieldtest.med",field,createFromScratch)
-
-
-#
-# ===============================================================
-# Creating a scalar field, working with numpy
-# ===============================================================
-#
-
-# We start by creating a numpy matrix
-import numpy
-rows=[]
-for irow in range(sizeY):
- row = numpy.arange(irow*sizeY,irow*sizeY+sizeX,dtype='float64')
- rows.append(row)
-
-marray = numpy.vstack(rows)
-
-# Then, we can reshape the matrix in a 1D vector that concatenate all
-# the rows
-data=marray.reshape(1,sizeX*sizeY)[0]
-# Finally, we can create a simple list as required by the MEDCoupling
-# DataArrayDouble. Note also the usage of float type because
-# MEDCoupling works only with real numbers
-listdata=list(data)
-
-# Create the field using the list obtained from the numpy array
-fieldWithNumpy = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS);
-fieldWithNumpy.setName("Numpy Field");
-fieldWithNumpy.setMesh(umesh);
-
-nbCells=sizeX*sizeY
-dataArray=MC.DataArrayDouble.New();
-dataArray.setValues(listdata,nbCells,nbComponents)
-fieldWithNumpy.setArray(dataArray);
-
-createFromScratch=False
-ML.MEDLoader.WriteField("fieldtest.med",fieldWithNumpy,createFromScratch)
-
-
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2011-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This script illustrates how to create a matrix of pixels from data
-# read in an image file. At the end, the cells of the matrix
-# corresponds to the cells of a cartesian mesh that could hold a field
-# whose value is the value of the pixel.
-# (gboulant - 13/11/2011)
-
-from PIL import Image
-from PIL import ImageOps
-import numpy
-
-def image2matrix():
- # Load the image
- #img=Image.open("images/avatar.png")
- img=Image.open("images/tests.pgm")
-
- # Get a grayscale version
- imgbw=ImageOps.grayscale(img)
-
- # Save the image (optionnal)
- imgbw.save(fp="testsbw.pgm")
-
- # Get the data
- imgdata=imgbw.getdata()
- width,height=imgbw.size
- print list(imgdata)
- print width,height
-
- # Convert the data in a matrix using numpy
- tab=numpy.array(imgdata,dtype='float64')
- print list(tab)
- print tab
- nbRows=height
- nbCols=width
- matrix=numpy.reshape(tab,(nbRows,nbCols))
- # Note that in the reshape function, the height (sizeY) of the image
- # is specified first, because it corresponds to the number of rows.
- print matrix
- print list(matrix)
-
-import MEDCoupling as MC
-import MEDLoader as ML
-def createMesh(meshname, sizeX, sizeY):
- """
- Creating a cartesian mesh with a grid of the size of the image.
- sizeX and sizeY should be respectively the width and heigth of the
- image.
- """
- # >>>
- # WARNING: remember the problem of tics and spaces. The data values
- # are considered as values defined on cells. With size values in a
- # direction, we have to create size+1 mesh nodes in that direction.
- # <<<
-
- # The mesh is created using MEDCoupling
- cmesh=MC.MEDCouplingCMesh.New();
- cmesh.setName(meshname)
-
- # We use an arbitrary step between cells (the value does not matter)
- stepX = 0.1
- nbNodesX = sizeX+1
- arrX = [float(i * stepX) for i in range(nbNodesX)]
- coordsX=MC.DataArrayDouble.New()
- coordsX.setValues(arrX,nbNodesX,1)
-
- # For the Y dimension, we have to reverse the coordinates (the
- # first pixel is at y=height and not at y=0).
- stepY = 0.1
- nbNodesY = sizeY+1
- lengthY = sizeY*stepY
- arrY=[float(lengthY - i * stepY) for i in range(nbNodesY)]
- coordsY=MC.DataArrayDouble.New()
- coordsY.setValues(arrY,nbNodesY,1)
-
- cmesh.setCoords(coordsX,coordsY)
- print "Imagem mesh dimension: %d"%cmesh.getSpaceDimension()
-
- # WARN: In the current state of development of MEDLoader, only
- # unstructured meshes are supported for writting function in med
- # files. We just have to convert the cartesian mesh in an unstructured
- # mesh before creating the field.
- umesh=cmesh.buildUnstructured();
- umesh.setName("imagemesh")
-
- return umesh
-
-def createField(fieldname, mesh, image):
- """
- Creating a scalar field on the mesh using image data
- """
- # Create the field using MEDCoupling
- field = MC.MEDCouplingFieldDouble.New(MC.ON_CELLS,MC.ONE_TIME);
- field.setName(fieldname);
- field.setMesh(mesh);
- # OPTIONAL: We set an arbitrary time step for test purpose
- field.setIteration(0);
- field.setOrder(0)
-
- imagedata=list(image.getdata())
- width,height=image.size
- nbCells = width*height
- dataArray=MC.DataArrayDouble.New();
- nbComponents=1 # For a scalar field
-
- dataArray.setValues(imagedata,nbCells,nbComponents)
- field.setArray(dataArray);
-
- return field
-
-def image2med():
- img=Image.open("images/avatar.png")
- #img=Image.open("images/irm.png")
- imgbw=ImageOps.grayscale(img)
- # We keep only the grayscale. Maybe, it could be usefull to get
- # the RGB scales each on one component of the field.
-
- width,height=imgbw.size
- mesh=createMesh("mesh",width,height)
- field=createField("field",mesh,imgbw)
-
- createFromScratch=True
- ML.MEDLoader.WriteField("image.med",field,createFromScratch)
-
-
-# ===================================================================
-
-if __name__ == "__main__":
- #image2matrix()
- image2med()
+++ /dev/null
-all:
- python tutorial.py
- python explore.py
- python manage.py
- python testamel.py
- python cmesh
-
-clean:
- rm -f *~ *.pyc output.med
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-from MEDLoader import MEDLoader
-
-import os
-filename = "madnex_field.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-meshName="my_field_RG"
-fieldName="my_field"
-itNumber=0
-itOrder=0
-
-# Load as an unstructured mesh
-meshDimRelToMax = 0 # 0 = no restriction
-umesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
-print "umesh is structured: %s"%umesh.isStructured()
-
-# Load as a structured mesh explicitly
-# _T2A
-from MEDLoader import MEDFileCMesh
-medfile = MEDFileCMesh.New(filepath,meshName)
-cmesh = medfile.getMesh()
-# Note that the getMesh method is a short way to the method:
-#cmesh = medfile.getGenMeshAtLevel(0,False)
-print "cmesh is structured: %s"%cmesh.isStructured()
-# _T2B
-
-# Load and let MEDLoader decide what is nature of the mesh
-# _T1A
-from MEDLoader import MEDFileMesh
-medfile = MEDFileMesh.New(filepath,meshName)
-print medfile.advancedRepr()
-meshDimRelToMax = 0 # 0 = no restriction
-mesh = medfile.getGenMeshAtLevel(meshDimRelToMax)
-print "mesh is structured: %s"%mesh.isStructured()
-# _T1B
-
-
-# Write the mesh to another file
-# _T3A
-outputfilepath="output.med"
-mode=0
-medfile.write(outputfilepath,mode)
-# _T3B
-
-# test to reload the mesh
-medfile = MEDFileCMesh.New(outputfilepath,meshName)
-cmesh = medfile.getMesh()
-print "cmesh is structured: %s"%cmesh.isStructured()
-
-# Q: Is it possible to know if a mesh is structured or unstructured
-# without loading the mesh.
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-from MEDLoader import MEDLoader
-
-import os
-#filename = "madnex_field.med"
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# Read the source meshes
-meshNames = MEDLoader.GetMeshNames(filepath)
-
-# Set to True if the meshes and fields data must be loaded. Otherwise,
-# only theire descriptions will be loaded.
-READ_PHYSICAL_DATA=False
-
-for meshName in meshNames:
-
- print "%s"%meshName
-
- # At this step, one can load the mesh of name meshName (but it is
- # not an obligation to continue to explore the metadata)
- meshDimRelToMax = 0 # 0 = no restriction
- if READ_PHYSICAL_DATA:
- mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
- # Note that the read function required the parameter
- # meshDimRelToMax. This parameter discreminates the meshdim you
- # are interested to relatively to the maximal dimension of cells
- # contained in the mesh in file (then its value could be 0, -1, -2
- # or -3 depending on the max dimension of the mesh. 0 means "no
- # restriction".
-
- # Read the names of the fields that rely on this mesh
- fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
-
- for fieldName in fieldNames:
-
- print " %s"%fieldName
-
- # A field name could identify several MEDCoupling fields, that
- # differ by their spatial discretization on the mesh (values on
- # cells, values on nodes, ...). This spatial discretization is
- # specified by the TypeOfField that is an integer value in this
- # list:
- # 0 = ON_CELLS
- # 1 = ON_NODES
- # 2 = ON_GAUSS_PT
- # 3 = ON_GAUSS_NE
- #
- # As a consequence, before loading values of a field, we have
- # to determine the types of spatial discretization defined for
- # this field and to chooose one.
-
- listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
- for typeOfDiscretization in listOfTypes:
- print " %s"%typeOfDiscretization
-
- # Then, we can get the iterations associated to this field on
- # this type of spatial discretization:
- fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
-
- # Then, we can access to the physical data for each
- # iteration of this field
- for fieldIteration in fieldIterations:
- itNumber = fieldIteration[0]
- itOrder = fieldIteration[1]
- print " (%s,%s)"%(itNumber,itOrder)
-
- if READ_PHYSICAL_DATA:
- medCouplingField = MEDLoader.ReadField(typeOfDiscretization,
- filepath,
- meshName,
- meshDimRelToMax,
- fieldName,
- itNumber,
- itOrder)
- print medCouplingField
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# _T1A
-import collections
-def tree():
- return collections.defaultdict(tree)
-
-fieldTree = tree()
-meshDict = {}
-# _T1B
-
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# _T2A
-from MEDLoader import MEDLoader
-meshNames = MEDLoader.GetMeshNames(filepath)
-
-meshDimRelToMax = 0 # 0 = no restriction
-
-for meshName in meshNames:
- mesh = MEDLoader.ReadUMeshFromFile(filepath,meshName,meshDimRelToMax)
- meshDict[meshName] = mesh
-
- fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
- for fieldName in fieldNames:
- listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
- for typeOfDiscretization in listOfTypes:
- fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
- for fieldIteration in fieldIterations:
- itNumber = fieldIteration[0]
- itOrder = fieldIteration[1]
-
- field = MEDLoader.ReadField(typeOfDiscretization,
- filepath,
- meshName,
- meshDimRelToMax,
- fieldName,
- itNumber,
- itOrder)
-
- fieldTree\
- [meshName]\
- [fieldName]\
- [typeOfDiscretization]\
- [itNumber][itOrder] = field
-# _T2B
-
-# Q: use a list of structures whose an attribute could be a
-# MEDCoupling field? Or a tree that you cross using attribute and
-# whose leaves are the MEDCoupling fields?
-# R: I think that the default structure should be a simple list that
-# store objects whith properties that corresponds to the metadata (and
-# if loaded the MEDCouplingField or Mesh). Then for specific request,
-# a BTree could be create to organize the search (for example if we
-# request all the fields for a given iteration step, then we should
-# use the iteration step as a first classifaction switch of the tree
-
-print fieldTree.keys()
-
-# _T3A
-for meshName in fieldTree.keys():
- print "%s"%meshName
- for fieldName in fieldTree[meshName].keys():
- print " %s"%fieldName
- for fieldType in fieldTree[meshName][fieldName].keys():
- print " %s"%fieldType
- for itNumber in fieldTree[meshName][fieldName][fieldType].keys():
- for itOrder in fieldTree[meshName][fieldName][fieldType][itNumber].keys():
- print " (%s,%s)"%(itNumber,itOrder)
- print fieldTree[meshName][fieldName][fieldType][itNumber][itOrder]
-# _T3B
+++ /dev/null
-# -*- coding: iso-8859-1 -*-
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This illustrates the use of getValueOn in the case of hexahedron
-# meshes (for which a temporary limitation implies the usage of the
-# method simplexize that split the hexahedron into simplex,
-# i.e. triangles and tetrahedrons).
-#
-# (gboulant, nov. 2012)
-from MEDLoader import *
-from MEDCoupling import *
-
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-rmedfilename = filepath
-
-# Load the meshe data
-meshname = "Grid_80x80"
-fieldname = "Pulse"
-dimrestriction = 0 # no restriction
-msource = MEDLoader.ReadUMeshFromFile(rmedfilename,meshname,dimrestriction)
-
-# WARN: In the current version of MEDCoupling, the getValueOn works
-# only with simplex cells (triangles, tetrahedron). This is not a
-# technical problem, but a question of specification of the
-# interpolation to be performed in the case of other cells, in
-# particular in the case of hexahedron meshes.
-#
-# A temporary solution (with good numerical results) is to split
-# hexahedrons into simplex (before the association of the mesh to the
-# field) using the method simplexize.
-policy = 0
-msource.simplexize(policy)
-
-# Load the field data at iteration 0
-iteration = 0
-order = -1
-fieldOnNodes = MEDLoader.ReadField(ON_NODES,rmedfilename,
- meshname,dimrestriction,
- fieldname,iteration,order)
-
-
-fieldOnNodes.setMesh(msource)
-
-# Get the value of field at coordinates x,y
-x=0.5
-y=0.5
-fieldValue = fieldOnNodes.getValueOn([x,y])
-print fieldValue
+++ /dev/null
-#!/usr/bin/env python
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-# This script illustrates the basic features of MEDLoader
-# (gboulant, 17 nov 2012)
-import os
-filename = "timeseries.med"
-filepath = os.path.join(os.path.abspath(os.path.dirname(__file__)),filename)
-
-# _T1A
-from MEDLoader import MEDLoader
-meshNames = MEDLoader.GetMeshNames(filepath)
-# _T1B
-meshName=meshNames[0]
-# _T2A
-fieldNames = MEDLoader.GetAllFieldNamesOnMesh(filepath,meshName)
-# _T2B
-fieldName=fieldNames[0]
-# _T3A
-listOfTypes = MEDLoader.GetTypesOfField(filepath,meshName,fieldName)
-# _T3B
-typeOfDiscretization=listOfTypes[0]
-# _T4A
-fieldIterations = MEDLoader.GetFieldIterations(typeOfDiscretization,
- filepath,
- meshName,
- fieldName)
-# _T4B
-
-iteration = fieldIterations[0]
-iterationNumber = iteration[0]
-iterationOrder = iteration[1]
-
-dimrestriction = 0
-# _T5A
-mesh = MEDLoader.ReadUMeshFromFile(filepath, meshName, dimrestriction)
-# _T5B
-# _T6A
-field = MEDLoader.ReadField(typeOfDiscretization,
- filepath, meshName, dimrestriction,
- fieldName, iterationNumber, iterationOrder)
-# _T6B
${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/GaussPoints
)
-IF(SALOME_MED_PARTITIONER_METIS)
+IF(MEDCOUPLING_MED_PARTITIONER_METIS)
ADD_DEFINITIONS(${METIS_DEFINITIONS})
- IF(SALOME_MED_METIS_V5)
+ IF(MEDCOUPLING_METIS_V5)
ADD_DEFINITIONS("-DMED_ENABLE_METIS_V5")
- ENDIF(SALOME_MED_METIS_V5)
+ ENDIF(MEDCOUPLING_METIS_V5)
INCLUDE_DIRECTORIES(${METIS_INCLUDE_DIRS})
-ENDIF(SALOME_MED_PARTITIONER_METIS)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_METIS)
########
-# VERY IMPORTANT PUT METIS BEFORE SCOTCH because
+# VERY IMPORTANT PUT METIS BEFORE SCOTCH because
# metis.h is also in SCOTCH install dir !!!
########
-IF(SALOME_MED_PARTITIONER_SCOTCH)
+IF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
ADD_DEFINITIONS(${SCOTCH_DEFINITIONS})
INCLUDE_DIRECTORIES(${SCOTCH_INCLUDE_DIRS})
-ENDIF(SALOME_MED_PARTITIONER_SCOTCH)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
-IF(SALOME_MED_PARTITIONER_PARMETIS)
+IF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
ADD_DEFINITIONS(${PARMETIS_DEFINITIONS})
INCLUDE_DIRECTORIES(${PARMETIS_INCLUDE_DIRS})
-ENDIF(SALOME_MED_PARTITIONER_PARMETIS)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
-IF(SALOME_USE_MPI)
+IF(MEDCOUPLING_USE_MPI)
ADD_DEFINITIONS(${MPI_DEFINITIONS})
INCLUDE_DIRECTORIES(${MPI_INCLUDE_DIRS})
-ENDIF(SALOME_USE_MPI)
+ENDIF(MEDCOUPLING_USE_MPI)
-IF(SALOME_BUILD_TESTS)
+IF(MEDCOUPLING_BUILD_TESTS)
ADD_SUBDIRECTORY(Test)
-ENDIF(SALOME_BUILD_TESTS)
+ENDIF(MEDCOUPLING_BUILD_TESTS)
SET(medpartitionercpp_HEADERS_HXX
MEDPARTITIONER_MeshCollection.hxx
medcoupling
medloader
)
-IF(SALOME_MED_PARTITIONER_PARMETIS)
+IF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
SET(medpartitionercpp_HEADERS_HXX ${medpartitionercpp_HEADERS_HXX} MEDPARTITIONER_ParMetisGraph.hxx)
SET(medpartitionercpp_SOURCES ${medpartitionercpp_SOURCES} MEDPARTITIONER_ParMetisGraph.cxx MEDPARTITIONER_MetisGraph.cxx)
SET(medpartitionercpp_DEFINITIONS "${medpartitionercpp_DEFINITIONS} ${PARMETIS_DEFINITIONS}")
SET(medpartitionercpp_LDFLAGS ${medpartitionercpp_LDFLAGS} ${PARMETIS_LIBRARIES})
-ENDIF(SALOME_MED_PARTITIONER_PARMETIS)
-IF(SALOME_MED_PARTITIONER_METIS)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
+IF(MEDCOUPLING_MED_PARTITIONER_METIS)
SET(medpartitionercpp_HEADERS_HXX ${medpartitionercpp_HEADERS_HXX} MEDPARTITIONER_MetisGraph.hxx)
SET(medpartitionercpp_SOURCES ${medpartitionercpp_SOURCES} MEDPARTITIONER_MetisGraph.cxx)
SET(medpartitionercpp_DEFINITIONS "${medpartitionercpp_DEFINITIONS} ${METIS_DEFINITIONS}")
SET(medpartitionercpp_LDFLAGS ${medpartitionercpp_LDFLAGS} ${METIS_LIBRARIES})
-ENDIF(SALOME_MED_PARTITIONER_METIS)
-IF(SALOME_MED_PARTITIONER_SCOTCH)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_METIS)
+IF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
SET(medpartitionercpp_HEADERS_HXX ${medpartitionercpp_HEADERS_HXX} MEDPARTITIONER_ScotchGraph.hxx)
SET(medpartitionercpp_SOURCES ${medpartitionercpp_SOURCES} MEDPARTITIONER_ScotchGraph.cxx)
SET(medpartitionercpp_DEFINITIONS "${medpartitionercpp_DEFINITIONS} ${SCOTCH_DEFINITIONS}")
SET(medpartitionercpp_LDFLAGS ${medpartitionercpp_LDFLAGS} ${SCOTCH_LIBRARIES})
-ENDIF(SALOME_MED_PARTITIONER_SCOTCH)
+ENDIF(MEDCOUPLING_MED_PARTITIONER_SCOTCH)
-IF(${SALOME_USE_MPI})
+IF(${MEDCOUPLING_USE_MPI})
SET(medpartitionercpp_SOURCES ${medpartitionercpp_SOURCES} MEDPARTITIONER_UtilsPara.cxx MEDPARTITIONER_JointFinder.cxx)
ADD_EXECUTABLE(medpartitioner_para medpartitioner_para.cxx)
SET(medpartitionercpp_LDFLAGS ${medpartitionercpp_LDFLAGS} ${MPI_LIBRARIES})
SET_TARGET_PROPERTIES(medpartitioner_para PROPERTIES COMPILE_FLAGS "${medpartitionercpp_DEFINITIONS}")
TARGET_LINK_LIBRARIES(medpartitioner_para medpartitionercpp ${medpartitionercpp_LDFLAGS})
- INSTALL(TARGETS medpartitioner_para DESTINATION ${SALOME_INSTALL_BINS})
-ENDIF(${SALOME_USE_MPI})
+ INSTALL(TARGETS medpartitioner_para DESTINATION ${MEDCOUPLING_INSTALL_BINS})
+ENDIF(${MEDCOUPLING_USE_MPI})
ADD_DEFINITIONS(${medpartitionercpp_DEFINITIONS})
-
+
ADD_LIBRARY(medpartitionercpp SHARED ${medpartitionercpp_SOURCES})
TARGET_LINK_LIBRARIES(medpartitionercpp ${medpartitionercpp_LDFLAGS} ${PLATFORM_LIBS} ${PTHREAD_LIBS})
-INSTALL(TARGETS medpartitionercpp DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS medpartitionercpp DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
ADD_EXECUTABLE(medpartitioner medpartitioner.cxx)
TARGET_LINK_LIBRARIES(medpartitioner medpartitionercpp ${medpartitionercpp_LDFLAGS})
-INSTALL(TARGETS medpartitioner DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS medpartitioner DESTINATION ${MEDCOUPLING_INSTALL_BINS})
-INSTALL(FILES ${medpartitionercpp_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${medpartitionercpp_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
typedef int idxtype;
#endif // defined(MED_ENABLE_METIS) & !defined(MED_ENABLE_PARMETIS)
-void MEDPARTITIONER_METIS_PartGraphRecursive(int *nvtxs, idxtype *xadj, idxtype *adjncy, idxtype *vwgt,
- idxtype *adjwgt, int *wgtflag, int *numflag, int *nparts,
+void MEDPARTITIONER_METIS_PartGraphRecursive(int *nvtxs, idxtype *xadj, idxtype *adjncy, idxtype *vwgt,
+ idxtype *adjwgt, int *wgtflag, int *numflag, int *nparts,
int *options, int *edgecut, idxtype *part)
{
#if defined(MED_ENABLE_METIS)
#ifndef MED_ENABLE_METIS_V5
- METIS_PartGraphRecursive(nvtxs, xadj, adjncy, vwgt,
- adjwgt, wgtflag, numflag, nparts,
+ METIS_PartGraphRecursive(nvtxs, xadj, adjncy, vwgt,
+ adjwgt, wgtflag, numflag, nparts,
options, edgecut, part);
#else
int ncon=1;
options[METIS_OPTION_NCUTS]=1;
options[METIS_OPTION_NITER]=1;
options[METIS_OPTION_UFACTOR]=1;
- METIS_PartGraphRecursive(nvtxs, &ncon, xadj, adjncy, vwgt, 0 /* vsize*/,
+ METIS_PartGraphRecursive(nvtxs, &ncon, xadj, adjncy, vwgt, 0 /* vsize*/,
adjwgt, nparts,/* tpwgts*/ 0,/* ubvec */ 0,
options, edgecut, part);
#endif
#endif
}
-void MEDPARTITIONER_METIS_PartGraphKway(int *nvtxs, idxtype *xadj, idxtype *adjncy, idxtype *vwgt,
- idxtype *adjwgt, int *wgtflag, int *numflag, int *nparts,
+void MEDPARTITIONER_METIS_PartGraphKway(int *nvtxs, idxtype *xadj, idxtype *adjncy, idxtype *vwgt,
+ idxtype *adjwgt, int *wgtflag, int *numflag, int *nparts,
int *options, int *edgecut, idxtype *part)
{
#if defined(MED_ENABLE_METIS)
#ifndef MED_ENABLE_METIS_V5
- METIS_PartGraphKway(nvtxs, xadj, adjncy, vwgt,
- adjwgt, wgtflag, numflag, nparts,
+ METIS_PartGraphKway(nvtxs, xadj, adjncy, vwgt,
+ adjwgt, wgtflag, numflag, nparts,
options, edgecut, part);
#else
int ncon=1;
options[METIS_OPTION_NCUTS]=1;
options[METIS_OPTION_NITER]=1;
options[METIS_OPTION_UFACTOR]=1;
- METIS_PartGraphKway(nvtxs, &ncon, xadj, adjncy, vwgt, 0 /* vsize*/,
+ METIS_PartGraphKway(nvtxs, &ncon, xadj, adjncy, vwgt, 0 /* vsize*/,
adjwgt, nparts, 0 , 0 /* ubvec */,
options, edgecut, part);
#endif
SET(MEDPARTITIONERTest_LDFLAGS medpartitionercpp ${CPPUNIT_LIBRARIES})
-IF(SALOME_USE_MPI)
- IF(SALOME_MED_PARTITIONER_PARMETIS)
+IF(MEDCOUPLING_USE_MPI)
+ IF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
SET(MEDPARTITIONERTest_SOURCES ${MEDPARTITIONERTest_SOURCES} MEDPARTITIONERTestPara.cxx)
- ENDIF(SALOME_MED_PARTITIONER_PARMETIS)
-ENDIF(SALOME_USE_MPI)
+ ENDIF(MEDCOUPLING_MED_PARTITIONER_PARMETIS)
+ENDIF(MEDCOUPLING_USE_MPI)
ADD_LIBRARY(MEDPARTITIONERTest SHARED ${MEDPARTITIONERTest_SOURCES})
TARGET_LINK_LIBRARIES(MEDPARTITIONERTest ${MEDPARTITIONERTest_LDFLAGS})
-INSTALL(TARGETS MEDPARTITIONERTest DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS MEDPARTITIONERTest DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
ADD_EXECUTABLE(TestMEDPARTITIONER TestMEDPARTITIONER.cxx)
TARGET_LINK_LIBRARIES(TestMEDPARTITIONER MEDPARTITIONERTest)
-INSTALL(TARGETS TestMEDPARTITIONER DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS TestMEDPARTITIONER DESTINATION ${MEDCOUPLING_INSTALL_BINS})
-INSTALL(FILES ${MEDPARTITIONERTest_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${MEDPARTITIONERTest_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
ADD_TEST(TestMEDPARTITIONER TestMEDPARTITIONER)
-SET_TESTS_PROPERTIES(TestMEDPARTITIONER PROPERTIES ENVIRONMENT "${tests_env}")
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDPartitioner)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDPartitioner)
INSTALL(TARGETS MEDPARTITIONERTest TestMEDPARTITIONER DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
#include <cppunit/TestAssert.h>
#include <sstream>
+#include <fstream>
#include <cmath>
#include <list>
#include <stdexcept>
#include <cstdlib>
#include <vector>
+#include <unistd.h>
#ifdef HAVE_MPI
#include <mpi.h>
std::string MEDPARTITIONERTest::getPartitionerExe() const
{
std::string execName;
- if ( getenv("top_builddir")) // make distcheck
+ if ( getenv("MEDCOUPLING_ROOT_DIR") )
{
- execName = getenv("top_builddir");
- execName += "/src/MEDPartitioner/medpartitioner";
- }
- else if ( getenv("MED_ROOT_DIR") )
- {
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner";
+ execName=getenv("MEDCOUPLING_ROOT_DIR"); //.../INSTALL/MED
+ execName+="/bin/medpartitioner";
}
else
{
- CPPUNIT_FAIL("Can't find medpartitioner, neither MED_ROOT_DIR nor top_builddir is set");
+ execName = get_current_dir_name();
+ execName += "/../../MEDPartitioner/medpartitioner";
+ if (! std::ifstream(execName.c_str()))
+ CPPUNIT_FAIL("Can't find medpartitioner, please set MEDCOUPLING_ROOT_DIR");
}
return execName;
}
ii=ii + _ni + 2 ;
conn.push_back(ii);
conn.push_back(ii-1);
-
+
ii=i + j*(_ni+1) + (k+1)*(_ni+1)*(_nj+1);
conn.push_back(ii);
conn.push_back(ii+1);
cout << endl;
cout << "\nnb conn " << (_ni)*(_nj)*(_nk)*8 << " " << conn.size() << endl;
for (int i=0; i<(int)conn.size(); i=i+8)
- {
+ {
for (int j=0; j<8; j++)
cout << conn[i+j] << " ";
cout << endl;
cout << endl;
}
*/
-
+
MEDCouplingUMesh *mesh=MEDCouplingUMesh::New();
mesh->setMeshDimension(3);
int nbc=conn.size()/8; //nb of cells
cout<<endl;
cout<<"\nnb conn "<<(_ni)*(_nj)*4<<" "<<conn.size()<<endl;
for (int i=0; i<(int)conn.size(); i=i+4)
- {
+ {
for (int j=0; j<4; j++) cout<<conn[i+j]<<" ";
cout<<endl;
}
cout<<endl;
}
-
+
MEDCouplingUMesh *mesh=MEDCouplingUMesh::New();
mesh->setMeshDimension(2);
int nbc=conn.size()/4; //nb of cells
cout<<endl;
cout<<"\nnb conn "<<(_ni)*(_nj)*4<<" "<<conn.size()<<endl;
for (int i=0; i<(int)conn.size(); i=i+4)
- {
+ {
for (int j=0; j<4; j++)
cout << conn[i+j] << " ";
cout << endl;
}
cout << endl;
}
-
+
MEDCouplingUMesh *mesh=MEDCouplingUMesh::New();
mesh->setMeshDimension(2);
int nbc=conn.size()/4; //nb of cells
field.push_back(j+.2);
field.push_back(k+.3);
}
-
+
MEDCouplingUMesh *mesh=MEDLoader::ReadUMeshFromFile(_file_name.c_str(),_mesh_name.c_str(),0);
int nbOfNodes=mesh->getNumberOfNodes();
MEDCouplingFieldDouble *f1=MEDCouplingFieldDouble::New(ON_NODES,ONE_TIME);
}
mesh->decrRef();
}
-
+
{
vector<const ParaMEDMEM::MEDCouplingUMesh*> meshes;
MEDCouplingUMesh * mesh1 = buildCUBE3DMesh();
meshes.push_back(mesh1);
meshes.push_back(mesh2);
MEDLoader::WriteUMeshes(_file_name_with_faces.c_str(), meshes, true);
-
+
ParaMEDMEM::MEDFileUMesh* mfm=ParaMEDMEM::MEDFileUMesh::New(_file_name_with_faces.c_str(), mesh1->getName().c_str());
DataArrayInt* FacesFam=DataArrayInt::New();
FacesFam->alloc(mfm->getSizeAtLevel(-1),1);
mfm->write(_file_name_with_faces.c_str(),0);
FacesFam->decrRef();
CellsFam->decrRef();
-
+
/*ce truc marche pas!
ParaMEDMEM::MEDFileUMesh* mfm=ParaMEDMEM::MEDFileUMesh::New(_file_name_with_faces.c_str(), mesh1->getName());
vector<const ParaMEDMEM::MEDCouplingUMesh*> ms;
mfm->setGroupsFromScratch(-1, ms);
mfm->write(_file_name_with_faces.c_str(),0);
*/
-
+
if (_verbose) cout<<endl<<_file_name_with_faces<<" created"<<endl;
if (_ntot<1000000) //too long
{
mesh2->decrRef();
mfm->decrRef();
}
-
+
{
MEDCouplingUMesh * mesh = buildCARRE3DMesh();
MEDLoader::WriteUMesh(_file_name2.c_str(),mesh,true);
<mapping>\n$tagMesh \
</mapping>\n \
</root>\n";
-
+
string tagSubfiles, tagSubfile="\
<subfile id=\"$xyz\">\n \
<name>$fileName</name>\n \
<name>testMesh</name>\n \
</chunk>\n \
</mesh>\n";
-
+
int xyz=1;
string sxyz;
DataArrayDouble* coordsInit=mesh->getCoords()->deepCpy();
double deltax=cooFin[0]-cooDep[0];
double deltay=cooFin[1]-cooDep[1];
double deltaz=cooFin[2]-cooDep[2];
-
+
double dz=0.;
for (int z=0; z<nbz; z++)
{
string fileName;
sxyz=IntToStr(xyz);
fileName="tmp_testMeshHuge_"+IntToStr(_ni)+"x"+IntToStr(_nj)+"x"+IntToStr(_nk)+"_"+sxyz+".med";
-
+
DataArrayDouble* coords=mesh->getCoords();
//int nbOfComp=coords->getNumberOfComponents(); //be 3D
int nbOfTuple=coords->getNumberOfTuples();
}
MEDLoader::WriteUMesh(fileName.c_str(),mesh,true);
-
+
tagSubfiles+=tagSubfile;
tagSubfiles.replace(tagSubfiles.find("$xyz"),4,sxyz);
tagSubfiles.replace(tagSubfiles.find("$fileName"),9,fileName);
-
+
tagMeshes+=tagMesh;
tagMeshes.replace(tagMeshes.find("$xyz"),4,sxyz);
xyz++;
dz+=deltaz;
}
coordsInit->decrRef();
-
+
tagXml.replace(tagXml.find("$subdomainNumber"),16,sxyz);
tagXml.replace(tagXml.find("$tagSubfile"),11,tagSubfiles);
tagXml.replace(tagXml.find("$tagMesh"),8,tagMeshes);
f<<tagXml;
f.close();
//cout<<"\n"<<tagXml<<endl;
- if (_verbose)
+ if (_verbose)
cout<<endl<<nameFileXml<<" created"<<endl;
mesh->decrRef();
}
f3->setDescription("MyDescriptionNE");
DataArrayDouble *array=DataArrayDouble::New();
//int nb=f1->getMesh()->getNumberOfNodes();
-
+
/*8 pt de gauss by cell
int nb=f3->getMesh()->getNumberOfCells()*8;
array->alloc(nb,2);
double *ptr=array->getPointer();
for (int i=0; i<nb*2; i=i+2) {ptr[i]=(double)(i/8) ; ptr[i]=2.*(double)(i/8);}
*/
-
+
//more nbptgauss=8 by default needs set MEDCouplingFieldDiscretizationPerCell
//theory: (may be) http://www.code-aster.org/V2/doc/v9/fr/man_r/r3/r3.06.03.pdf
- int nbptgauss=8; //nb pt de gauss by cell
+ int nbptgauss=8; //nb pt de gauss by cell
int nbcell=f3->getMesh()->getNumberOfCells();
int nb=nbcell*nbptgauss;
int nbcomp=2;
{
cout<<"\n types in "<<name<<" : ";
//for (std::set<INTERP_KERNEL::NormalizedCellType>::iterator t=types.begin(); t!=types.end(); ++t) cout<<" "<<*t;
- for (std::set<INTERP_KERNEL::NormalizedCellType>::const_iterator t=types.begin(); t!=types.end(); ++t)
+ for (std::set<INTERP_KERNEL::NormalizedCellType>::const_iterator t=types.begin(); t!=types.end(); ++t)
{
//INTERP_KERNEL::CellModel essai=INTERP_KERNEL::CellModel::GetCellModel(*t);
cout<<" "<<(INTERP_KERNEL::CellModel::GetCellModel(*t)).getRepr();
cout<<endl;
}
m->decrRef();
-
+
MEDFileUMesh * mf = MEDFileUMesh::New(_file_name.c_str(),_mesh_name.c_str(),-1,-1);
vector<int> lev;
lev=mf->getNonEmptyLevels();
bool empty_groups=false;
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(fileName,parallelizer);
-
+
MEDPARTITIONER::ParallelTopology* aPT = (MEDPARTITIONER::ParallelTopology*) collection.getTopology();
aPT->setGlobalNumerotationDefault(collection.getParaDomainSelector());
//Creating the graph and partitioning it
new_topo.reset( collection.createPartition(ndomains,MEDPARTITIONER::Graph::METIS) );
//Creating a new mesh collection from the partitioning
MEDPARTITIONER::MeshCollection new_collection(collection,new_topo.get(),split_family,empty_groups);
-
+
//example to create files
//MyGlobals::_General_Informations.clear();
//MyGlobals::_General_Informations.push_back(SerializeFromString("finalMeshName=Merge"));
//if (MyGlobals::_Verbose>100) cout << "generalInformations : \n"<<ReprVectorOfString(MyGlobals::_General_Informations);
//new_collection.write("ttmp")
-
+
CPPUNIT_ASSERT(new_collection.isParallelMode());
CPPUNIT_ASSERT_EQUAL(3, new_collection.getMeshDimension());
CPPUNIT_ASSERT(new_collection.getName()==collection.getName());
bool empty_groups=false;
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(fileName,parallelizer);
-
+
MEDPARTITIONER::ParallelTopology* aPT = (MEDPARTITIONER::ParallelTopology*) collection.getTopology();
aPT->setGlobalNumerotationDefault(collection.getParaDomainSelector());
-
+
for (int ndomains=2 ; ndomains<=16 ; ndomains++)
{
//Creating the graph and partitioning it
new_topo.reset( collection.createPartition(ndomains,MEDPARTITIONER::Graph::METIS) );
//Creating a new mesh collection from the partitioning
MEDPARTITIONER::MeshCollection new_collection(collection,new_topo.get(),split_family,empty_groups);
-
+
CPPUNIT_ASSERT_EQUAL(ndomains,new_collection.getNbOfLocalMeshes());
CPPUNIT_ASSERT_EQUAL(ndomains,new_collection.getNbOfGlobalMeshes());
CPPUNIT_ASSERT_EQUAL(collection.getNbOfLocalCells(),new_collection.getNbOfLocalCells());
bool empty_groups=false;
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(fileName,parallelizer);
-
+
MEDPARTITIONER::ParallelTopology* aPT = (MEDPARTITIONER::ParallelTopology*) collection.getTopology();
aPT->setGlobalNumerotationDefault(collection.getParaDomainSelector());
//Creating the graph and partitioning it
new_topo.reset( collection.createPartition(ndomains,MEDPARTITIONER::Graph::SCOTCH) );
//Creating a new mesh collection from the partitioning
MEDPARTITIONER::MeshCollection new_collection(collection,new_topo.get(),split_family,empty_groups);
-
+
//example to create files
//MyGlobals::_General_Informations.clear();
//MyGlobals::_General_Informations.push_back(SerializeFromString("finalMeshName=Merge"));
//if (MyGlobals::_Verbose>100) cout << "generalInformations : \n"<<ReprVectorOfString(MyGlobals::_General_Informations);
//new_collection.write("ttmp")
-
+
CPPUNIT_ASSERT(new_collection.isParallelMode());
CPPUNIT_ASSERT_EQUAL(3, new_collection.getMeshDimension());
CPPUNIT_ASSERT(new_collection.getName()==collection.getName());
bool empty_groups=false;
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(fileName,parallelizer);
-
+
MEDPARTITIONER::ParallelTopology* aPT = (MEDPARTITIONER::ParallelTopology*) collection.getTopology();
aPT->setGlobalNumerotationDefault(collection.getParaDomainSelector());
-
+
for (int ndomains=2 ; ndomains<=16 ; ndomains++)
{
//Creating the graph and partitioning it
new_topo.reset( collection.createPartition(ndomains,MEDPARTITIONER::Graph::SCOTCH) );
//Creating a new mesh collection from the partitioning
MEDPARTITIONER::MeshCollection new_collection(collection,new_topo.get(),split_family,empty_groups);
-
+
CPPUNIT_ASSERT_EQUAL(ndomains,new_collection.getNbOfLocalMeshes());
CPPUNIT_ASSERT_EQUAL(ndomains,new_collection.getNbOfGlobalMeshes());
CPPUNIT_ASSERT_EQUAL(collection.getNbOfLocalCells(),new_collection.getNbOfLocalCells());
{
int res;
string cmd,execName,sourceName,targetName;
-
+
execName=getPartitionerExe();
-
+
cmd="which "+execName+" 2>/dev/null 1>/dev/null"; //no trace
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL_MESSAGE(execName + " - INVALID PATH TO medpartitioner", 0, res);
-
+
cmd=execName+" --ndomains=2 --split-method="+MetisOrScotch; //on same proc
sourceName=_file_name;
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
cmd=execName+" --ndomains=5 --split-method="+MetisOrScotch; //on less proc
sourceName=_file_name;
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
cmd=execName+" --ndomains=1 --split-method="+MetisOrScotch; //on 1 proc
sourceName=targetName+".xml";
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-}
+}
void MEDPARTITIONERTest::verifyMetisOrScotchMedpartitionerOnSmallSizeForMesh(std::string MetisOrScotch)
{
string fileName,cmd,execName,sourceName,targetName,input;
execName=getPartitionerExe();
fileName=_file_name_with_faces;
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
ParaMEDMEM::MEDCouplingUMesh* faceMesh=initialMesh->getLevelM1Mesh(false);
-
+
cmd=execName+" --ndomains=5 --split-method="+MetisOrScotch; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(input,parallelizer);
CPPUNIT_ASSERT_EQUAL(3, collection.getMeshDimension());
for (std::size_t i = 0; i < cellMeshes.size(); i++)
nbcells+=cellMeshes[i]->getNumberOfCells();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
-
+
std::vector<ParaMEDMEM::MEDCouplingUMesh*>faceMeshes=collection.getFaceMesh();
CPPUNIT_ASSERT_EQUAL(5, (int) faceMeshes.size());
int nbfaces=0;
for (std::size_t i=0; i < faceMeshes.size(); i++)
nbfaces+=faceMeshes[i]->getNumberOfCells();
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), nbfaces);
-
+
//merge split meshes and test equality
cmd=execName+" --ndomains=1 --split-method="+MetisOrScotch; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
ParaMEDMEM::MEDCouplingUMesh* refusedFaceMesh=refusedMesh->getLevelM1Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), refusedFaceMesh->getNumberOfCells());
-
+
/*not the good job
ParaMEDMEM::MEDCouplingMesh* mergeCell=cellMesh->mergeMyselfWith(refusedCellMesh);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), mergeCell->getNumberOfCells());
-
+
ParaMEDMEM::MEDCouplingMesh* mergeFace=faceMesh->mergeMyselfWith(refusedFaceMesh);
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), mergeFace->getNumberOfCells());
-
+
CPPUNIT_ASSERT(faceMesh->isEqual(refusedFaceMesh,1e-12));
*/
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
meshes.resize(0);
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
meshes.push_back(refusedFaceMesh);
MEDCouplingUMesh* fusedFace=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), fusedFace->getNumberOfCells());
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
fusedFace->decrRef();
execName=getPartitionerExe();
fileName=_file_name;
fileName.replace(fileName.find(".med"),4,"_WithVecFieldOnCells.med");
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
-
+
cmd=execName+" --ndomains=5 --split-method="+MetisOrScotch; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
//merge split meshes and test equality
cmd=execName+" --ndomains=1 --split-method="+MetisOrScotch; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
MEDCouplingFieldDouble* field1=MEDLoader::ReadFieldCell(fileName.c_str(),initialMesh->getName().c_str(),0,"VectorFieldOnCells",0,1);
MEDCouplingFieldDouble* field2=MEDLoader::ReadFieldCell(refusedName.c_str(),refusedCellMesh->getName().c_str(),0,"VectorFieldOnCells",0,1);
-
+
int nbcells=corr[1]->getNumberOfTuples();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
//use corr to test equality of field
DataArrayDouble* f1=field1->getArray();
DataArrayDouble* f2=field2->getArray();
- if (_verbose>300)
+ if (_verbose>300)
{
cout<<"\nf1 : "<<f1->reprZip();
cout<<"\nf2 : "<<f2->reprZip(); //field2->advancedRepradvancedRepr();
for (std::size_t i = 0; i < corr.size(); i++)
cout << "\ncorr " << i << " : " << corr[i]->reprZip();
-
+
}
int nbequal=0;
int nbcomp=field1->getNumberOfComponents();
}
}
CPPUNIT_ASSERT_EQUAL(nbcells*nbcomp, nbequal);
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
field1->decrRef();
execName=getPartitionerExe();
fileName=_file_name;
fileName.replace(fileName.find(".med"),4,"_WithVecFieldOnGaussNe.med");
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
-
+
cmd=execName+" --ndomains=5 --split-method="+MetisOrScotch; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
//merge split meshes and test equality
cmd=execName+" --ndomains=1 --split-method="+MetisOrScotch; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
MEDCouplingFieldDouble* field1=MEDLoader::ReadField(ON_GAUSS_NE,fileName.c_str(),initialMesh->getName().c_str(),0,"MyFieldOnGaussNE",5,6);
MEDCouplingFieldDouble* field2=MEDLoader::ReadField(ON_GAUSS_NE,refusedName.c_str(),refusedCellMesh->getName().c_str(),0,"MyFieldOnGaussNE",5,6);
-
+
int nbcells=corr[1]->getNumberOfTuples();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
//use corr to test equality of field
DataArrayDouble* f1=field1->getArray();
DataArrayDouble* f2=field2->getArray();
- if (_verbose>300)
+ if (_verbose>300)
{
cout << "\nf1 : " << f1->reprZip(); //123.4 for 12th cell,3rd component, 4th gausspoint
cout << "\nf2 : " << f2->reprZip(); //field2->advancedRepradvancedRepr();
for (std::size_t i = 0; i < corr.size(); i++)
cout << "\ncorr " << i << " : " << corr[i]->reprZip();
-
+
}
int nbequal=0;
int nbptgauss=8;
}
}
CPPUNIT_ASSERT_EQUAL(nbcells*nbcomp*nbptgauss, nbequal);
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
field1->decrRef();
CPPUNIT_TEST( testMeshCollectionComplexPartitionScotch );
CPPUNIT_TEST( testScotchSmallSize );
#endif
-
+
#if defined(HAVE_MPI)
#if defined(MED_ENABLE_PARMETIS)
//test with mpi on system
int _nb_target_huge;
std::string _mesh_name; //initial test mesh file med
int _verbose;
-
+
//for utils
void setSize(int ni, int nj, int nk);
void setSmallSize();
void setMedianSize();
void setbigSize();
std::string getPartitionerExe() const;
+ std::string getPartitionerParaExe() const;
ParaMEDMEM::MEDCouplingUMesh * buildCUBE3DMesh();
ParaMEDMEM::MEDCouplingUMesh * buildFACE3DMesh();
ParaMEDMEM::MEDCouplingUMesh * buildCARRE3DMesh();
void launchMedpartitionerOnTestMeshes();
void launchMedpartitionerOnHugeTestMeshes();
void deleteTestMeshes();
-
+
//for CPPUNIT_TEST
void setUp();
void tearDown();
void testMeshCollectionComplexPartitionScotch();
void testScotchSmallSize();
#endif
-
+
#if defined(HAVE_MPI)
void testMpirunSmallSize();
void testMpirunMedianSize();
using namespace MEDPARTITIONER;
#if defined(HAVE_MPI)
+std::string MEDPARTITIONERTest::getPartitionerParaExe() const
+{
+ std::string execName;
+ if ( getenv("MEDCOUPLING_ROOT_DIR") )
+ {
+ execName=getenv("MEDCOUPLING_ROOT_DIR"); //.../INSTALL/MED
+ execName+="/bin/medpartitioner_para";
+ }
+ else
+ {
+ execName = get_current_dir_name();
+ execName += "/../../MEDPartitioner/medpartitioner_para";
+ if (! std::ifstream(execName.c_str()))
+ CPPUNIT_FAIL("Can't find medpartitioner_para, please set MEDCOUPLING_ROOT_DIR");
+ }
+ return execName;
+}
+
void MEDPARTITIONERTest::verifyMedpartitionerOnSmallSizeForMesh()
{
int res;
string fileName,cmd,execName,sourceName,targetName,input;
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner_para";
+ execName=getPartitionerParaExe();
fileName=_file_name_with_faces;
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
ParaMEDMEM::MEDCouplingUMesh* faceMesh=initialMesh->getLevelM1Mesh(false);
-
+
cmd="mpirun -np 5 "+execName+" --ndomains=5 --split-method=metis"; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
MEDPARTITIONER::ParaDomainSelector parallelizer(false);
MEDPARTITIONER::MeshCollection collection(input,parallelizer);
CPPUNIT_ASSERT_EQUAL(3, collection.getMeshDimension());
for (std::size_t i = 0; i < cellMeshes.size(); i++)
nbcells+=cellMeshes[i]->getNumberOfCells();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
-
+
std::vector<ParaMEDMEM::MEDCouplingUMesh*>faceMeshes=collection.getFaceMesh();
CPPUNIT_ASSERT_EQUAL(5, (int) faceMeshes.size());
int nbfaces=0;
for (std::size_t i=0; i < faceMeshes.size(); i++)
nbfaces+=faceMeshes[i]->getNumberOfCells();
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), nbfaces);
-
+
//merge split meshes and test equality
cmd="mpirun -np 1 "+execName+" --ndomains=1 --split-method=metis"; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
ParaMEDMEM::MEDCouplingUMesh* refusedFaceMesh=refusedMesh->getLevelM1Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), refusedFaceMesh->getNumberOfCells());
-
+
/*not the good job
ParaMEDMEM::MEDCouplingMesh* mergeCell=cellMesh->mergeMyselfWith(refusedCellMesh);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), mergeCell->getNumberOfCells());
-
+
ParaMEDMEM::MEDCouplingMesh* mergeFace=faceMesh->mergeMyselfWith(refusedFaceMesh);
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), mergeFace->getNumberOfCells());
-
+
CPPUNIT_ASSERT(faceMesh->isEqual(refusedFaceMesh,1e-12));
*/
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
meshes.resize(0);
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
meshes.push_back(refusedFaceMesh);
MEDCouplingUMesh* fusedFace=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(faceMesh->getNumberOfCells(), fusedFace->getNumberOfCells());
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
fusedFace->decrRef();
{
int res;
string fileName,cmd,execName,sourceName,targetName,input;
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner_para";
+ execName=getPartitionerParaExe();
fileName=_file_name;
fileName.replace(fileName.find(".med"),4,"_WithVecFieldOnCells.med");
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
-
+
cmd="mpirun -np 5 "+execName+" --ndomains=5 --split-method=metis"; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
//merge split meshes and test equality
cmd="mpirun -np 1 "+execName+" --ndomains=1 --split-method=metis"; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
MEDCouplingFieldDouble* field1=MEDLoader::ReadFieldCell(fileName.c_str(),initialMesh->getName().c_str(),0,"VectorFieldOnCells",0,1);
MEDCouplingFieldDouble* field2=MEDLoader::ReadFieldCell(refusedName.c_str(),refusedCellMesh->getName().c_str(),0,"VectorFieldOnCells",0,1);
-
+
int nbcells=corr[1]->getNumberOfTuples();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
//use corr to test equality of field
DataArrayDouble* f1=field1->getArray();
DataArrayDouble* f2=field2->getArray();
- if (_verbose>300)
+ if (_verbose>300)
{
cout<<"\nf1 : "<<f1->reprZip();
cout<<"\nf2 : "<<f2->reprZip(); //field2->advancedRepradvancedRepr();
for (std::size_t i = 0; i < corr.size(); i++)
cout << "\ncorr " << i << " : " << corr[i]->reprZip();
-
+
}
int nbequal=0;
int nbcomp=field1->getNumberOfComponents();
}
}
CPPUNIT_ASSERT_EQUAL(nbcells*nbcomp, nbequal);
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
field1->decrRef();
{
int res;
string fileName,cmd,execName,sourceName,targetName,input;
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner_para";
+ execName=getPartitionerParaExe();
fileName=_file_name;
fileName.replace(fileName.find(".med"),4,"_WithVecFieldOnGaussNe.med");
-
+
ParaMEDMEM::MEDFileUMesh* initialMesh=ParaMEDMEM::MEDFileUMesh::New(fileName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* cellMesh=initialMesh->getLevel0Mesh(false);
-
+
cmd="mpirun -np 5 "+execName+" --ndomains=5 --split-method=metis"; //on same proc
sourceName=fileName;
targetName=fileName;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
input=targetName+".xml";
-
+
//merge split meshes and test equality
cmd="mpirun -np 1 "+execName+" --ndomains=1 --split-method=metis"; //on same proc
sourceName=targetName+".xml";
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
string refusedName=targetName+"1.med";
ParaMEDMEM::MEDFileUMesh* refusedMesh=ParaMEDMEM::MEDFileUMesh::New(refusedName.c_str(),_mesh_name.c_str());
ParaMEDMEM::MEDCouplingUMesh* refusedCellMesh=refusedMesh->getLevel0Mesh(false);
-
+
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), refusedCellMesh->getNumberOfCells());
-
+
std::vector<const MEDCouplingUMesh *> meshes;
std::vector<DataArrayInt *> corr;
meshes.push_back(cellMesh);
meshes.push_back(refusedCellMesh);
MEDCouplingUMesh* fusedCell=MEDCouplingUMesh::FuseUMeshesOnSameCoords(meshes,0,corr);
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), fusedCell->getNumberOfCells());
-
+
MEDCouplingFieldDouble* field1=MEDLoader::ReadField(ON_GAUSS_NE,fileName.c_str(),initialMesh->getName().c_str(),0,"MyFieldOnGaussNE",5,6);
MEDCouplingFieldDouble* field2=MEDLoader::ReadField(ON_GAUSS_NE,refusedName.c_str(),refusedCellMesh->getName().c_str(),0,"MyFieldOnGaussNE",5,6);
-
+
int nbcells=corr[1]->getNumberOfTuples();
CPPUNIT_ASSERT_EQUAL(cellMesh->getNumberOfCells(), nbcells);
//use corr to test equality of field
DataArrayDouble* f1=field1->getArray();
DataArrayDouble* f2=field2->getArray();
- if (_verbose>300)
+ if (_verbose>300)
{
cout << "\nf1 : " << f1->reprZip(); //123.4 for 12th cell,3rd component, 4th gausspoint
cout << "\nf2 : " << f2->reprZip(); //field2->advancedRepradvancedRepr();
for (std::size_t i = 0; i < corr.size(); i++)
cout << "\ncorr " << i << " : " << corr[i]->reprZip();
-
+
}
int nbequal=0;
int nbptgauss=8;
}
}
CPPUNIT_ASSERT_EQUAL(nbcells*nbcomp*nbptgauss, nbequal);
-
+
for (std::size_t i = 0; i < corr.size(); i++)
corr[i]->decrRef();
field1->decrRef();
void MEDPARTITIONERTest::launchMedpartitionerOnTestMeshes()
{
-
- /* examples
+
+ /* examples
export INFI=/home/vb144235/resources/blade.med
//no need export MESH=Fuse_1
export INFI=tmp_testMeshxxx.med
*/
int res;
string cmd,execName,sourceName,targetName;
-
+
res=system("which mpirun 2>/dev/null 1>/dev/null"); //no trace
CPPUNIT_ASSERT_EQUAL(0, res);
-
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner_para";
-
+
+ execName=getPartitionerParaExe();
+
cmd="which "+execName+" 2>/dev/null 1>/dev/null"; //no trace
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
cmd="mpirun -np 2 "+execName+" --ndomains=2 --split-method=metis"; //on same proc
sourceName=_file_name;
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
cmd="mpirun -np 3 "+execName+" --ndomains=5 --split-method=metis"; //on less proc
sourceName=_file_name;
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-
+
cmd="mpirun -np 1 "+execName+" --ndomains=1 --split-method=metis"; //on 1 proc
sourceName=targetName+".xml";
targetName=_file_name;
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-}
+}
void MEDPARTITIONERTest::launchMedpartitionerOnHugeTestMeshes()
{
int res=0;
string cmd,execName,sourceName,targetName;
- execName=getenv("MED_ROOT_DIR"); //.../INSTALL/MED
- execName+="/bin/salome/medpartitioner_para";
+ execName=getPartitionerParaExe();
string snbTarget=IntToStr(_nb_target_huge);
cmd="mpirun -np "+snbTarget+" "+execName+" --ndomains="+snbTarget+" --split-method=metis"; //on same proc
if (_verbose) cout<<endl<<cmd<<endl;
res=system(cmd.c_str());
CPPUNIT_ASSERT_EQUAL(0, res);
-}
+}
void MEDPARTITIONERTest::testMpirunSmallSize()
{
IF(WIN32)
SET_TARGET_PROPERTIES(_MEDPartitioner PROPERTIES DEBUG_OUTPUT_NAME _MEDPartitioner_d)
ENDIF(WIN32)
-INSTALL(TARGETS ${SWIG_MODULE_MEDPartitioner_REAL_NAME} DESTINATION ${SALOME_INSTALL_PYTHON})
+INSTALL(TARGETS ${SWIG_MODULE_MEDPartitioner_REAL_NAME} DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDPartitioner.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_SCRIPT_PYTHON})
+INSTALL(FILES "${PYFILES_TO_INSTALL}" DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
-INSTALL(FILES MEDPartitioner.i MEDPartitionerCommon.i DESTINATION ${SALOME_INSTALL_HEADERS})
-INSTALL(FILES MEDPartitionerTest.py DESTINATION ${SALOME_INSTALL_SCRIPT_PYTHON})
+INSTALL(FILES MEDPartitioner.i MEDPartitionerCommon.i DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
+INSTALL(FILES MEDPartitionerTest.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
ADD_TEST(MEDPartitionerTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDPartitionerTest.py)
-SET_TESTS_PROPERTIES(MEDPartitionerTest PROPERTIES ENVIRONMENT "${tests_env}")
+SET(MEDPartitionerTest_PYTHONPATH "PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}:${CMAKE_CURRENT_BINARY_DIR}/../MEDLoader/Swig")
+SET_TESTS_PROPERTIES(MEDPartitionerTest PROPERTIES ENVIRONMENT "${MEDPartitionerTest_PYTHONPATH}")
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDPartitioner_Swig)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/MEDPartitioner_Swig)
INSTALL(FILES MEDPartitionerTest.py DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
DESTINATION ${TEST_INSTALL_DIRECTORY}
RENAME CTestTestfile.cmake)
-
-
c=MEDCouplingCMesh() ; c.setCoords(arr,arr)
m=c.buildUnstructured()
m.setName("mesh")
- mm=MEDFileUMesh()
+ mm=MEDFileUMesh()
mm.setMeshAtLevel(0,m)
ms=MEDFileMeshes() ; ms.pushMesh(mm)
data=MEDFileData()
self.assertEqual( 3, meshes.getMeshAtPos(0).getJoints().getNumberOfJoints())
self.assertEqual( 3, meshes.getMeshAtPos(1).getJoints().getNumberOfJoints())
self.assertEqual( 3, meshes.getMeshAtPos(2).getJoints().getNumberOfJoints())
- self.assertEqual( 3, meshes.getMeshAtPos(3).getJoints().getNumberOfJoints())
+ self.assertEqual( 3, meshes.getMeshAtPos(3).getJoints().getNumberOfJoints())
joints=meshes.getMeshAtPos(0).getJoints()
self.assertEqual( 1, joints.getJointAtPos(0).getDomainNumber(), 1)
self.assertEqual( 2, joints.getJointAtPos(1).getDomainNumber(), 2)
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${MPI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCouplingCorba
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- )
-
-SET(paramedcouplingcorba_SOURCES
- ParaMEDCouplingFieldDoubleServant.cxx
- ParaMEDCouplingUMeshServant.cxx
- )
-
-ADD_LIBRARY(paramedcouplingcorba SHARED ${paramedcouplingcorba_SOURCES})
-SET_TARGET_PROPERTIES(paramedcouplingcorba PROPERTIES COMPILE_FLAGS "${MPI_DEFINITIONS} ${OMNIORB_DEFINITIONS}")
-TARGET_LINK_LIBRARIES(paramedcouplingcorba medcouplingcorba ${MPI_LIBS})
-INSTALL(TARGETS paramedcouplingcorba DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB paramedcouplingcorba_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${paramedcouplingcorba_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
ADD_LIBRARY(paramedloader SHARED ${paramedloader_SOURCES})
TARGET_LINK_LIBRARIES(paramedloader paramedmem medloader ${PLATFORM_LIBS})
-INSTALL(TARGETS paramedloader EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS paramedloader EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
FILE(GLOB paramedloader_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${paramedloader_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${paramedloader_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
ADD_LIBRARY(paramedmem SHARED ${paramedmem_SOURCES})
TARGET_LINK_LIBRARIES(paramedmem medcoupling ${MPI_LIBRARIES})
-INSTALL(TARGETS paramedmem EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS paramedmem EXPORT ${PROJECT_NAME}TargetGroup DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
FILE(GLOB paramedmem_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${paramedmem_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${paramedmem_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
# To allow usage as SWIG dependencies:
SET(paramedmem_HEADERS_HXX PARENT_SCOPE)
-
+++ /dev/null
-# Copyright (C) 2012-2015 CEA/DEN, EDF R&D
-#
-# This library is free software; you can redistribute it and/or
-# modify it under the terms of the GNU Lesser General Public
-# License as published by the Free Software Foundation; either
-# version 2.1 of the License, or (at your option) any later version.
-#
-# This library is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-#
-# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
-#
-
-ADD_DEFINITIONS(${MPI_DEFINITIONS} ${OMNIORB_DEFINITIONS})
-
-INCLUDE_DIRECTORIES(
- ${OMNIORB_INCLUDE_DIR} ${OMNIORB_INCLUDE_DIRS}
- ${MPI_INCLUDE_DIRS}
- ${CMAKE_CURRENT_BINARY_DIR}/../../idl
- ${CMAKE_CURRENT_SOURCE_DIR}/../ParaMEDMEM
- ${CMAKE_CURRENT_SOURCE_DIR}/../ParaMEDCouplingCorba
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCouplingCorba
- ${CMAKE_CURRENT_SOURCE_DIR}/../MEDCoupling
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL
- ${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/Bases
- )
-
-SET(paramedmemcompo_SOURCES
- MPIMEDCouplingFieldDoubleServant.cxx
- ParaMEDMEMComponent_i.cxx
- )
-
-ADD_LIBRARY(paramedmemcompo SHARED ${paramedmemcompo_SOURCES})
-TARGET_LINK_LIBRARIES(paramedmemcompo medcouplingcorba paramedmem)
-INSTALL(TARGETS paramedmemcompo DESTINATION ${SALOME_INSTALL_LIBS})
-
-FILE(GLOB paramedmemcompo_HEADERS_HXX "${CMAKE_CURRENT_SOURCE_DIR}/*.hxx")
-INSTALL(FILES ${paramedmemcompo_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
ADD_LIBRARY(ParaMEDMEMTest SHARED ${ParaMEDMEMTest_SOURCES})
SET_TARGET_PROPERTIES(ParaMEDMEMTest PROPERTIES COMPILE_FLAGS "")
TARGET_LINK_LIBRARIES(ParaMEDMEMTest paramedmem paramedloader medcouplingremapper ${CPPUNIT_LIBRARIES})
-INSTALL(TARGETS ParaMEDMEMTest DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS ParaMEDMEMTest DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
SET(TESTSParaMEDMEM)
SET(TestParaMEDMEM_SOURCES
ParaMEDMEMTestMPI2_1.cxx
)
SET(TESTSParaMEDMEM ${TESTSParaMEDMEM} ParaMEDMEMTestMPI2_1)
-
+
SET(ParaMEDMEMTestMPI2_2_SOURCES
MPI2Connector.cxx
ParaMEDMEMTestMPI2_2.cxx
# Now add CMake tests - test_perf, ParaMEDMEMTestMPI2_1 and ParaMEDMEMTestMPI2_2
# are left aside, as they are too specific
-#
+#
# -- some tests require 2, 3, 4 or 5 procs --
ADD_TEST(NAME TestParaMEDMEM_Proc2 COMMAND ${MPIEXEC} -np 2 $<TARGET_FILE:TestParaMEDMEM>)
ADD_TEST(NAME TestParaMEDMEM_Proc3 COMMAND ${MPIEXEC} -np 3 $<TARGET_FILE:TestParaMEDMEM>)
ADD_TEST(NAME TestMPIAccessDEC_Proc4 COMMAND ${MPIEXEC} -np 4 $<TARGET_FILE:TestMPIAccessDEC>)
# Installation rules
-INSTALL(TARGETS ${TESTSParaMEDMEM} DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS ${TESTSParaMEDMEM} DESTINATION ${MEDCOUPLING_INSTALL_BINS})
SET(COMMON_HEADERS_HXX
MPIMainTest.hxx
MPIAccessDECTest.hxx
ParaMEDMEMTest.hxx
MPI2Connector.hxx
)
-INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${COMMON_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
#include <unistd.h>
#endif
-//================================================================================
-/*!
- * \brief Get path to the resources file.
- *
- * When running 'make test' source file is taken from MED_SRC/resources folder.
- * Otherwise, file is searched in ${MED_ROOT_DIR}/share/salome/resources/med folder.
- *
- * \param filename name of the resource file (should not include a path)
- * \return full path to the resource file
- */
-//================================================================================
-
std::string ParaMEDMEMTest::getResourceFile( const std::string& filename )
{
std::string resourceFile = "";
- if ( getenv("top_srcdir") ) {
- // we are in 'make test' step
- resourceFile = getenv("top_srcdir");
- resourceFile += "/resources/";
+ if ( getenv("MEDCOUPLING_ROOT_DIR") ) {
+ // use MEDCOUPLING_ROOT_DIR env.var
+ resourceFile = getenv("MEDCOUPLING_ROOT_DIR");
+ resourceFile += "/share/resources/med/";
}
- else if ( getenv("MED_ROOT_DIR") ) {
- // use MED_ROOT_DIR env.var
- resourceFile = getenv("MED_ROOT_DIR");
- resourceFile += "/share/salome/resources/med/";
+ else {
+ resourceFile = get_current_dir_name();
+ resourceFile += "/../../resources/";
}
+
resourceFile += filename;
return resourceFile;
}
//================================================================================
/*!
- * \brief Creates a copy of source file (if source file is specified)
+ * \brief Creates a copy of source file (if source file is specified)
* in the temporary directory and returns a path to the tmp file
*
* \param tmpfile name of the temporary file (without path)
#include "ParaFIELD.hxx"
#include "UnstructuredParaSUPPORT.hxx"
#include "ICoCoMEDField.hxx"
-
+
#include <string>
// use this define to enable lines, execution of which leads to Segmentation Fault
using namespace std;
using namespace ParaMEDMEM;
using namespace MEDMEM;
-
+
/*
* Check methods defined in InterpKernelDEC.hxx
*
//the test is meant to run on five processors
if (size !=5) return ;
-
- testNonCoincidentDEC( "/share/salome/resources/med/square1_split",
+
+ testNonCoincidentDEC( "square1_split",
"Mesh_2",
- "/share/salome/resources/med/square2_split",
+ "square2_split",
"Mesh_3",
3,
1e-6);
-}
+}
void ParaMEDMEMTest::testNonCoincidentDEC_3D()
{
int size;
MPI_Comm_size(MPI_COMM_WORLD,&size);
-
+
//the test is meant to run on five processors
if (size !=4) return ;
-
- testNonCoincidentDEC( "/share/salome/resources/med/blade_12000_split2",
+
+ testNonCoincidentDEC( "blade_12000_split2",
"Mesh_1",
- "/share/salome/resources/med/blade_3000_split2",
+ "blade_3000_split2",
"Mesh_1",
2,
1e4);
-}
+}
void ParaMEDMEMTest::testNonCoincidentDEC(const string& filename1,
const string& meshname1,
int rank;
MPI_Comm_size(MPI_COMM_WORLD,&size);
MPI_Comm_rank(MPI_COMM_WORLD,&rank);
-
+
set<int> self_procs;
set<int> procs_source;
set<int> procs_target;
-
+
for (int i=0; i<nproc_source; i++)
procs_source.insert(i);
for (int i=nproc_source; i<size; i++)
procs_target.insert(i);
self_procs.insert(rank);
-
+
ParaMEDMEM::CommInterface interface;
-
+
ParaMEDMEM::ProcessorGroup* self_group = new ParaMEDMEM::MPIProcessorGroup(interface,self_procs);
ParaMEDMEM::ProcessorGroup* target_group = new ParaMEDMEM::MPIProcessorGroup(interface,procs_target);
ParaMEDMEM::ProcessorGroup* source_group = new ParaMEDMEM::MPIProcessorGroup(interface,procs_source);
-
+
ParaMEDMEM::ParaMESH* source_mesh=0;
ParaMEDMEM::ParaMESH* target_mesh=0;
ParaMEDMEM::ParaSUPPORT* parasupport=0;
MEDMEM::FIELD<double>* field;
ParaMEDMEM::ParaMESH* paramesh;
ParaMEDMEM::ParaFIELD* parafield;
-
+
string filename_xml1 = getResourceFile(filename1);
- string filename_xml2 = getResourceFile(filename2);
+ string filename_xml2 = getResourceFile(filename2);
//string filename_seq_wr = makeTmpFile("");
//string filename_seq_med = makeTmpFile("myWrField_seq_pointe221.med");
-
+
// To remove tmp files from disk
ParaMEDMEMTest_TmpFilesRemover aRemover;
//aRemover.Register(filename_seq_wr);
if (source_group->containsMyRank())
{
string master = filename_xml1;
-
+
ostringstream strstream;
strstream <<master<<rank+1<<".med";
ostringstream meshname ;
meshname<< meshname1<<"_"<< rank+1;
-
+
CPPUNIT_ASSERT_NO_THROW(mesh = new MESH(MED_DRIVER,strstream.str(),meshname.str()));
support=new MEDMEM::SUPPORT(mesh,"all elements",MED_EN::MED_CELL);
-
+
paramesh=new ParaMESH (*mesh,*source_group,"source mesh");
-
+
parasupport=new UnstructuredParaSUPPORT( support,*source_group);
ParaMEDMEM::ComponentTopology comptopo;
parafield = new ParaFIELD(parasupport, comptopo);
-
+
int nb_local=support->getNumberOfElements(MED_EN::MED_ALL_ELEMENTS);
double * value= new double[nb_local];
for(int ielem=0; ielem<nb_local;ielem++)
parafield->getField()->setValue(value);
icocofield=new ICoCo::MEDField(paramesh,parafield);
-
+
dec.attachLocalField(icocofield);
delete [] value;
}
-
+
//loading the geometry for the target group
if (target_group->containsMyRank())
{
strstream << master<<(rank-nproc_source+1)<<".med";
ostringstream meshname ;
meshname<< meshname2<<"_"<<rank-nproc_source+1;
-
+
CPPUNIT_ASSERT_NO_THROW(mesh = new MESH(MED_DRIVER,strstream.str(),meshname.str()));
support=new MEDMEM::SUPPORT(mesh,"all elements",MED_EN::MED_CELL);
-
+
paramesh=new ParaMESH (*mesh,*target_group,"target mesh");
parasupport=new UnstructuredParaSUPPORT(support,*target_group);
ParaMEDMEM::ComponentTopology comptopo;
parafield = new ParaFIELD(parasupport, comptopo);
-
+
int nb_local=support->getNumberOfElements(MED_EN::MED_ALL_ELEMENTS);
double * value= new double[nb_local];
for(int ielem=0; ielem<nb_local;ielem++)
value[ielem]=0.0;
parafield->getField()->setValue(value);
icocofield=new ICoCo::MEDField(paramesh,parafield);
-
+
dec.attachLocalField(icocofield);
delete [] value;
}
-
-
- //attaching a DEC to the source group
+
+
+ //attaching a DEC to the source group
double field_before_int;
double field_after_int;
-
+
if (source_group->containsMyRank())
- {
+ {
field_before_int = parafield->getVolumeIntegral(1);
MPI_Bcast(&field_before_int, 1,MPI_DOUBLE, 0,MPI_COMM_WORLD);
dec.synchronize();
dec.sendData();
// paramesh->write(MED_DRIVER,"./sourcesquarenc");
- //parafield->write(MED_DRIVER,"./sourcesquarenc","boundary");
-
-
+ //parafield->write(MED_DRIVER,"./sourcesquarenc","boundary");
+
+
}
-
+
//attaching a DEC to the target group
if (target_group->containsMyRank())
{
MPI_Bcast(&field_before_int, 1,MPI_DOUBLE, 0,MPI_COMM_WORLD);
-
+
dec.synchronize();
dec.setOption("ForcedRenormalization",false);
dec.recvData();
//paramesh->write(MED_DRIVER, "./targetsquarenc");
//parafield->write(MED_DRIVER, "./targetsquarenc", "boundary");
field_after_int = parafield->getVolumeIntegral(1);
-
+
}
MPI_Bcast(&field_before_int,1,MPI_DOUBLE,0,MPI_COMM_WORLD);
MPI_Bcast(&field_after_int, 1,MPI_DOUBLE, size-1,MPI_COMM_WORLD);
-
+
CPPUNIT_ASSERT_DOUBLES_EQUAL(field_before_int, field_after_int, epsilon);
-
+
delete source_group;
delete target_group;
delete self_group;
delete parasupport;
delete mesh;
MPI_Barrier(MPI_COMM_WORLD);
-
+
}
#endif
${medloader_HEADERS_HXX}
${medcoupling_HEADERS_HXX} ${medcoupling_HEADERS_TXX}
${interpkernel_HEADERS_HXX} ${interpkernel_HEADERS_TXX})
-
+
SWIG_ADD_MODULE(ParaMEDMEM python ParaMEDMEM.i)
SWIG_LINK_LIBRARIES(ParaMEDMEM ${PYTHON_LIBRARIES} paramedmem medloader)
SET_SOURCE_FILES_PROPERTIES(ParaMEDMEM.i PROPERTIES CPLUSPLUS ON)
SET_SOURCE_FILES_PROPERTIES(ParaMEDMEM.i PROPERTIES SWIG_DEFINITIONS "-shadow")
-INSTALL(TARGETS _ParaMEDMEM DESTINATION ${SALOME_INSTALL_PYTHON})
-INSTALL(FILES ParaMEDMEM.i DESTINATION ${SALOME_INSTALL_HEADERS})
-SALOME_INSTALL_SCRIPTS(${CMAKE_CURRENT_BINARY_DIR}/ParaMEDMEM.py ${SALOME_INSTALL_SCRIPT_PYTHON})
-INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/ParaMEDMEM.py test_InterpKernelDEC.py test_NonCoincidentDEC.py test_StructuredCoincidentDEC.py DESTINATION ${SALOME_INSTALL_SCRIPT_PYTHON})
\ No newline at end of file
+INSTALL(TARGETS _ParaMEDMEM DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
+INSTALL(FILES ParaMEDMEM.i DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/ParaMEDMEM.py test_InterpKernelDEC.py test_NonCoincidentDEC.py test_StructuredCoincidentDEC.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
nproc_source = 3
procs_source = range( nproc_source )
procs_target = range( size - nproc_source + 1, size)
-
+
interface = CommInterface()
target_group = MPIProcessorGroup(interface, procs_target)
source_group = MPIProcessorGroup(interface, procs_source)
dec = InterpKernelDEC(source_group, target_group)
-
+
mesh =0
support =0
paramesh =0
parafield =0
icocofield =0
- data_dir = os.environ['MED_ROOT_DIR']
+ data_dir = os.environ['MEDCOUPLING_ROOT_DIR']
tmp_dir = os.environ['TMP']
-
+
if not tmp_dir or len(tmp_dir)==0:
tmp_dir = "/tmp"
pass
-
- filename_xml1 = os.path.join(data_dir, "share/salome/resources/med/square1_split")
- filename_xml2 = os.path.join(data_dir, "share/salome/resources/med/square2_split")
-
+
+ filename_xml1 = os.path.join(data_dir, "share/resources/med/square1_split")
+ filename_xml2 = os.path.join(data_dir, "share/resources/med/square2_split")
+
MPI_Barrier(MPI_COMM_WORLD)
if source_group.containsMyRank():
filename = filename_xml1 + str(rank+1) + ".med"
dec.setMethod("P0")
dec.attachLocalField(icocofield)
pass
-
+
if source_group.containsMyRank():
field_before_int = parafield.getVolumeIntegral(0,True)
dec.synchronize()
dec = NonCoincidentDEC(source_group, target_group)
-data_dir = os.environ['MED_ROOT_DIR']
+data_dir = os.environ['MEDCOUPLING_ROOT_DIR']
tmp_dir = os.environ['TMP']
if tmp_dir == '':
tmp_dir = "/tmp"
pass
-filename_xml1 = data_dir + "/share/salome/resources/med/square1_split"
-filename_xml2 = data_dir + "/share/salome/resources/med/square2_split"
+filename_xml1 = data_dir + "/share/resources/med/square1_split"
+filename_xml2 = data_dir + "/share/resources/med/square2_split"
MPI_Barrier(MPI_COMM_WORLD)
-
+
if source_group.containsMyRank():
filename = filename_xml1 + str(rank+1) + ".med"
dec.sendData()
pass
-
+
if target_group.containsMyRank():
MPI_Bcast(field_before_int, 1, MPI_DOUBLE, 0, MPI_COMM_WORLD)
comptopo = 0
icocofield= 0
#
- data_dir = os.environ['MED_ROOT_DIR']
+ data_dir = os.environ['MEDCOUPLING_ROOT_DIR']
tmp_dir = os.environ['TMP']
if tmp_dir == '':
tmp_dir = "/tmp"
pass
-
- filename_xml1 = data_dir + "/share/salome/resources/med/square1_split"
- filename_2 = data_dir + "/share/salome/resources/med/square1.med"
+
+ filename_xml1 = data_dir + "/share/resources/med/square1_split"
+ filename_2 = data_dir + "/share/resources/med/square1.med"
filename_seq_wr = tmp_dir + "/"
filename_seq_med = tmp_dir + "/myWrField_seq_pointe221.med"
-
+
dec = StructuredCoincidentDEC(source_group, target_group)
MPI_Barrier(MPI_COMM_WORLD)
if source_group.containsMyRank():
pass
parafield.getField().setValues(value)
icocofield = ICoCoMEDField(mesh,parafield.getField())
- dec.setMethod("P0")
- dec.attachLocalField(parafield)
+ dec.setMethod("P0")
+ dec.attachLocalField(parafield)
dec.synchronize()
dec.sendData()
pass
print "End of test StructuredCoincidentDEC"
pass
-
+
unittest.main()
${CMAKE_CURRENT_SOURCE_DIR}/../INTERP_KERNEL/GaussPoints
)
-IF(SALOME_USE_MPI)
+IF(MEDCOUPLING_USE_MPI)
ADD_DEFINITIONS(${MPI_DEFINITIONS})
INCLUDE_DIRECTORIES(${MPI_INCLUDE_DIRS})
-ENDIF(SALOME_USE_MPI)
+ENDIF(MEDCOUPLING_USE_MPI)
SET(renumbercpp_HEADERS_HXX
RENUMBER_Renumbering.hxx
IF(METIS_FOUND)
INCLUDE_DIRECTORIES(${METIS_INCLUDE_DIRS})
-
+
SET(renumbercpp_SOURCES ${renumbercpp_SOURCES} RENUMBER_METISRenumbering.cxx)
SET(renumbercpp_HEADERS_HXX ${renumbercpp_HEADERS_HXX} RENUMBER_METISRenumbering.hxx)
SET(renumbercpp_LDFLAGS ${renumbercpp_LDFLAGS} ${METIS_LIBRARIES})
IF(Boost_FOUND)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
-
+
SET(renumbercpp_SOURCES ${renumbercpp_SOURCES} RENUMBER_BOOSTRenumbering.cxx)
SET(renumbercpp_HEADERS_HXX ${renumbercpp_HEADERS_HXX} RENUMBER_BOOSTRenumbering.hxx)
SET(renumbercpp_LDFLAGS ${renumbercpp_LDFLAGS} ${BOOST_LIBRARIES})
ENDIF(Boost_FOUND)
-IF(SALOME_USE_MPI)
+IF(MEDCOUPLING_USE_MPI)
SET(renumbercpp_LDFLAGS ${renumbercpp_LDFLAGS} ${MPI_LIBRARIES})
-ENDIF(SALOME_USE_MPI)
+ENDIF(MEDCOUPLING_USE_MPI)
ADD_EXECUTABLE(renumber ${renumber_SOURCES})
SET_TARGET_PROPERTIES(renumber PROPERTIES COMPILE_FLAGS "${renumber_DEFINITIONS}")
TARGET_LINK_LIBRARIES(renumber renumbercpp)
-INSTALL(TARGETS renumber DESTINATION ${SALOME_INSTALL_BINS})
+INSTALL(TARGETS renumber DESTINATION ${MEDCOUPLING_INSTALL_BINS})
ADD_LIBRARY(renumbercpp SHARED ${renumbercpp_SOURCES})
SET_TARGET_PROPERTIES(renumbercpp PROPERTIES COMPILE_FLAGS "${renumber_DEFINITIONS}")
TARGET_LINK_LIBRARIES(renumbercpp ${renumbercpp_LDFLAGS})
-INSTALL(TARGETS renumbercpp DESTINATION ${SALOME_INSTALL_LIBS})
+INSTALL(TARGETS renumbercpp DESTINATION ${MEDCOUPLING_INSTALL_LIBS})
-INSTALL(FILES ${renumbercpp_HEADERS_HXX} DESTINATION ${SALOME_INSTALL_HEADERS})
+INSTALL(FILES ${renumbercpp_HEADERS_HXX} DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
pass
def setUp(self):
- srcdir = os.getenv("srcdir")
- med_root = os.getenv("MED_ROOT_DIR")
- if srcdir:
- # make test is being performed
- self.dir_renumber="./renumber"
- self.dir_mesh = os.path.join( srcdir, "../../resources")
- elif med_root:
- # hope renumber has been already installed
- self.dir_renumber=os.path.join( med_root, "bin/salome/renumber")
- self.dir_mesh = os.path.join( med_root, "share/salome/resources/med")
- else:
- # initial version
- self.dir_renumber="../../../MED_INSTALL/bin/salome/renumber"
- self.dir_mesh="../../resources"
- pass
+ med_root_dir=os.getenv("MEDCOUPLING_ROOT_DIR")
+ self.dir_renumber=os.path.join(med_root_dir, "bin/renumber")
+ self.dir_mesh=os.path.join(med_root_dir, "share","resources","med")
pass
pass
IF(WIN32)
SET_TARGET_PROPERTIES(_MEDRenumber PROPERTIES DEBUG_OUTPUT_NAME _MEDRenumber_d)
ENDIF(WIN32)
-INSTALL(TARGETS ${SWIG_MODULE_MEDRenumber_REAL_NAME} DESTINATION ${SALOME_INSTALL_PYTHON})
+INSTALL(TARGETS ${SWIG_MODULE_MEDRenumber_REAL_NAME} DESTINATION ${MEDCOUPLING_INSTALL_PYTHON})
-SET(PYFILES_TO_INSTALL ${CMAKE_CURRENT_BINARY_DIR}/MEDRenumber.py)
-SALOME_INSTALL_SCRIPTS("${PYFILES_TO_INSTALL}" ${SALOME_INSTALL_SCRIPT_PYTHON})
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/MEDRenumber.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
-INSTALL(FILES MEDRenumber.i MEDRenumberCommon.i DESTINATION ${SALOME_INSTALL_HEADERS})
-INSTALL(FILES MEDRenumberTest.py DESTINATION ${SALOME_INSTALL_SCRIPT_PYTHON})
+INSTALL(FILES MEDRenumber.i MEDRenumberCommon.i DESTINATION ${MEDCOUPLING_INSTALL_HEADERS})
+INSTALL(FILES MEDRenumberTest.py DESTINATION ${MEDCOUPLING_INSTALL_SCRIPT_PYTHON})
-SALOME_GENERATE_TESTS_ENVIRONMENT(tests_env)
ADD_TEST(MEDRenumberTest ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/MEDRenumberTest.py)
-SET_TESTS_PROPERTIES(MEDRenumberTest PROPERTIES ENVIRONMENT "${tests_env}")
+SET(MEDRenumberTest_PYTHONPATH "PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}:${CMAKE_CURRENT_BINARY_DIR}/../MEDCoupling_Swig")
+SET_TESTS_PROPERTIES(MEDRenumberTest PROPERTIES ENVIRONMENT "${MEDRenumberTest_PYTHONPATH}")
# Application tests
-SET(TEST_INSTALL_DIRECTORY ${SALOME_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/RENUMBER_Swig)
+SET(TEST_INSTALL_DIRECTORY ${MEDCOUPLING_INSTALL_SCRIPT_SCRIPTS}/test/MEDCoupling/RENUMBER_Swig)
INSTALL(FILES MEDRenumberTest.py DESTINATION ${TEST_INSTALL_DIRECTORY})
INSTALL(FILES CTestTestfileInstall.cmake
