This is the Med Memory package V3.2.0 I : Major evolution of the Med Memory package between V2.2.x and V3.2.x : ========================================================================= The Med Memory may be used as a stand alone package with only the C++ and the python layers (adding --without-kernel at the configure step). In this case there are no links with the SALOME KERNEL. In this version, - mesh defined with polygones/polyhedra mixed with usual types of cells; - the Med File drivers of the Med Memory support the V2.1 as well as the V2.2 versions of the Med File layer. The requirement of the Salome platform is only Med File V2.2, the V2.1 version is emberked in the Med Memory. - Using the Med file (V2.1 and V2.2) and GIBI drivers; fields laying on a partial support; - Fields defined on cells mesh with multiple gauss points, may be mounted in memory and treated. With all those new functionalities, most of the Med Memory client codes based on previous releases of the Med Memory should work; but minor changes should be done for the get/set field classes methods: - the getValue() and the setValue(T *) methods take no MED_EN::medModeSwitch parameter; - the getValueI (resp. setValueI) should be replaced by getRow(int ) (resp. setRow(int ,T*) if the field is in full interlacing mode (using the method getInterlacingType() of the classe FIELD_). If the field is stored in no interlacing mode getValueIJ (resp. setValueIJ) should be replaced by getColumn(int ) (resp. setColumn(int ,T*)). Intensive debugging was carried throughout the entire Med Memory C++ Layer: - especially on the major user's C++ classes (such as MED, MESH, SUPPORT and FIELD); - the C++ drivers classes on those major classes. Especially the Med File and the GIBI drivers are read/write ones. The VTK drivers are only for the writing; and finally the PORFLOW drivers may only be used for the MESH class in the reading mode. The Med Client layer of the Med Memory has been tested in a full Server/Client configuration. II : MedMemory building and installation : ========================================= Assuming that the rather straightforward path_to_your_MedMemory_installation_directory, path_to_your_MedMemory_building_directory, path_to_your_MedMemory_sources_directory, path_to_your_MedFile_installation_directory, path_to_your_HDF5_installation_directory, directories are setted; the user/installer may use the following commands to build the Med Memory installation as a Salome component : In the directory path_to_your_MedMemory_building_directory; path_to_your_MedMemory_sources_directory/build_configure path_to_your_MedMemory_sources_directory/configure --prefix=path_to_your_MedMemory_installation_directory make make install Eventually if the user/installer needs to build an installation of Med Memory as a stand alone package, he/she may use always in the path_to_your_MedMemory_building_directory, the following commands : path_to_your_MedMemory_sources_directory/build_configure --without-kernel path_to_your_MedMemory_sources_directory/configure --prefix=path_to_your_MedMemory_installation_directory make make install Remark : If the installer gets the sources archives from the NEPAL web site -------- (CEA, EDF, OCC, ie hammi web site) the user may only use the following commands : path_to_your_MedMemory_sources_directory/configure --prefix=path_to_your_MedMemory_installation_directory make make install By default the full debug options are set: - compilation using -g option - Med Memory debugging information history using -D_DEBUG_ option. The user/installer may get all configure option with : path_to_your_MedMemory_sources_directory/configure --help set optimization option : path_to_your_MedMemory_sources_directory/configure --enable-production --disable-debug (use compiler flags -O) In order to avoid most of the problem the user/installer should first check the $HDF5HOME and the $MED2HOME environment variables. In csh: setenv HDF5HOME path_to_your_HDF5_installation_directory setenv MED2HOME path_to_your_MedFile_installation_directory This version of Med Memory has been tested with Med File V2.2.2, V2.2.3, as well as V2.3.0 but with the version of HDF5 V1.6.3. Thus, in the installation process of Med File the user/installer should take care of the $HDF5HOME environement variable. This warning is especially intended to the user of the Med Memory in its stand alone vesion (ie without the SALOME KERNEL component). III : MedMemory testing : ========================= After installation of the Med Memory; the user/installer may find a large set of Med File V2.1, V2.2, GIBI test files in the directory : path_to_your_MedMemory_installation_directory/share/salome/resources/ For user/installer of the Med Meory as a Salome component, sourcing the usual Salome environement and using the usual runSalome command, all needed environement variables (such as $MED_ROOT_DIR, $LD_LIBRARY_PATH and $PYTHONPATH) are well setted. But for the user/installer of the Med Memory as a stand alone version should set his/her environement. Assuming that $HDF5HOME $MED2HOME are setted properly, in csh : setenv MED_ROOT_DIR path_to_your_MedMemory_installation_directory setenv PATH ${MED2HOME}/bin:${HDF5HOME}/bin:$PATH setenv LD_LIBRARY_PATH ${MED_ROOT_DIR}/lib/salome:${MED2HOME}/lib:${HDF5HOME}/lib:$LD_LIBRARY_PATH setenv PYTHONPATH ${MED_ROOT_DIR}/bin/salome:${MED_ROOT_DIR}/lib/salome:${MED_ROOT_DIR}/lib/python${PYTHON_VERSION}/site-packages/salome: To check the Med Memory installation, in the directory path_to_your_MedMemory_installation_directory/bin/salome you may find a set of python scripts and test executable. To ckeck the deep layers (C++, Python) of the Med Memory, the installer may run: - testMedMemGeneral.py, - medMeshing_test.py - test_profil_MedFieldDriver.py - testGaussLocalization.py - med_field_anal.py - test_MEDMEM_MeshingFlica - test_MEDMEM_Meshing_poly - test_MEDMEM_MeshingPoly To check the upper layer (CORBA, Client), the installer may run in the SALOME Python consol: - Med_Gen_test.py - medClient_test.py - testMedAlliances1.py - testMedAlliances.py - testMeshAlliances.py