]> SALOME platform Git repositories - modules/med.git/commitdiff
Salome HOME
Join modifications from branch BR_DEBUG_3_2_0b1 05Jun06
authorjfa <jfa@opencascade.com>
Mon, 5 Jun 2006 12:25:04 +0000 (12:25 +0000)
committerjfa <jfa@opencascade.com>
Mon, 5 Jun 2006 12:25:04 +0000 (12:25 +0000)
README [new file with mode: 0644]
src/MEDMEM/MEDMEM_Init.cxx

diff --git a/README b/README
new file mode 100644 (file)
index 0000000..975c663
--- /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
index 32a646747e6df34d840e8b184fe55862a6550cb8..95b3a38679b307c618fb0c670de327f925d8275a 100644 (file)
@@ -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);
 }