From: jfa Date: Mon, 5 Jun 2006 12:25:04 +0000 (+0000) Subject: Join modifications from branch BR_DEBUG_3_2_0b1 05Jun06 X-Git-Tag: T3_2_0b2~1 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=0efb8a270626c5c39dfad01712e792e4dbe7c1b3;p=modules%2Fmed.git Join modifications from branch BR_DEBUG_3_2_0b1 05Jun06 --- diff --git a/README b/README new file mode 100644 index 000000000..975c66396 --- /dev/null +++ b/README @@ -0,0 +1,106 @@ +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 : +========================================= + +It's very simple : + +./configure --prefix=path_to_your_installation_directory +make +make install + +eventually if the user or the installer needs to build an installation of Med +Memory as a stand alone package, he may use the configure option +--without-kernel. By default the full debug options are set: + - compilation using -g option + - Med Memory debugging information history using -D_DEBUG_ option. + +The user may get all configure option with : + ./configure --help + +The user may set optimization option : + ./configure --enable-production --disable-debug (use compiler flags -O) + +In order to avoid most of the problem the user or the installer should first +check the HDF5HOME and the MED2HOME environment variables. This version of +Med Memory with Med File V2.2.2, V2.2.3, as well as V2.3.0 but with the +version of HDF5 V1.6.3. In the installation of Med File you should take care +of the $HDF5HOME environement variable. This warning is especially intended +to the user of The Med Memory in stand alone (without the SALOME KERNEL +component). + +III : MedMemory testing : +========================= + +After installation of the Med Memory; the user may find a large set of test +files in Med File V2.1, V2.2, GIBI format. + +To check the Med Memory installation, in the directory +path_to_your_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 diff --git a/src/MEDMEM/MEDMEM_Init.cxx b/src/MEDMEM/MEDMEM_Init.cxx index 32a646747..95b3a3867 100644 --- a/src/MEDMEM/MEDMEM_Init.cxx +++ b/src/MEDMEM/MEDMEM_Init.cxx @@ -42,15 +42,14 @@ MEDMEM::INIT::INIT() #ifdef MED_WITH_KERNEL // LocalTraceCollector::instance(); #endif /* ifdef MED_WITH_KERNEL*/ + char* traceKind = getenv("SALOME_trace"); -// char* traceKind = getenv("SALOME_trace"); + if (traceKind == NULL) + { + setenv("SALOME_trace","local",1); + traceKind = getenv("SALOME_trace"); + assert(traceKind); + } -// if (traceKind == NULL) -// { -// setenv("SALOME_trace","local",1); -// traceKind = getenv("SALOME_trace"); -// assert(traceKind); -// } - -// MESSAGE("Med Memory Initialization with $SALOME_trace = " << traceKind); + MESSAGE("Med Memory Initialization with $SALOME_trace = " << traceKind); }