.. _calculator:
-MED Calculator Component
-=========================
-This example is the following of the HELLO component. It's purpose is to show how to quickly create a new Salome module, to introduce the use of MED objects within Salome/Corba context, to demonstrate the mechanism of exceptions, and to introduce the use of Salome supervisor.
+MEDCoupling Calculator Component
+===================================
+This example is the following of the HELLO component. It's purpose is to show how to quickly create a new SALOME module, to introduce the use of MEDCoupling objects within SALOME/Corba context, to demonstrate the mechanism of exceptions, and to introduce the use of SALOME supervisor.
The MED libraries
------------------
+-------------------------
-Let's go back a little bit on the different MED libraries (a web site giving general information and documentation about MED project is accessible from the Salome2 web site, links section).
+Let's go back a little bit on the different MED libraries (a web site giving general information and documentation about MED / MEDCoupling project is accessible from the SALOME web site, links section).
-The first level (called “Med File”) is a C and Fortran API that implements mesh and field persistence. The definition of the mesh format (the definition of the implemented entities, the connectivity references ...) is done in [R3]_. The use of the API is documented by [R4]_ and [R5]_. The produced files are based on hdf format, and have the “.med” extension.
+The first level (called “MED File”) is a C and Fortran API that implements mesh and field persistence. The definition of the mesh format (the definition of the implemented entities, the connectivity references ...) is done in [R3]_. The use of the API is documented by [R4]_ and [R5]_. The produced files are based on hdf format, and have the “.med” extension.
-The second level library is called “Med Memory”, which is a C++ API that allows creating mesh and field objects in memory. Mesh creation can be done from scratch using set functions, or by loading a file with a driver (see html documentation and [R6]_). Fields are also created using drivers, or by initialization with a user-defined analytic function. Supported file format are .med, .sauv (persistent format of the CASTEM code), vtk (only in write mode), and porflow (fluid flow and heat transfer code). Med Memory was developed to allow the exchange of mesh and field objects in memory between solvers. It can also be used as an internal data structure for new solvers. A last purpose was to gather in the same place existing algorithms and services around meshes and fields :
+The second level library is called “MEDCoupling”, which is a C++ API that allows to create mesh and field objects in memory and manipulate them. Mesh creation can be done from scratch using set functions, or by loading a file with a driver (see html documentation and [R6]_). Fields are also created using drivers (MEDLoader), or by initialization with a user-defined analytic function. Supported file format are .med, .sauv (persistent format of the CASTEM code) and vtk (only in write mode). MEDCoupling was developed to allow the exchange of mesh and field objects in memory between solvers. It can also be used as an internal data structure for new solvers. A last purpose was to gather in the same place existing algorithms and services around meshes and fields :
* computation of sub-elements nodal connectivities (faces, edges),
-There are two libraries on the third level: a python API generated by SWIG, and a CORBA API :
+There are two libraries on the third level: a python API generated by SWIG, and a CORBA interface to exchange meshes, fields objects between different processes and SALOME containers without using files:
-* The python API wraps the complete Med Memory API, and allows a python user to manipulate Med Memory C++ objects within python.
+* The python API wraps the complete MEDCoupling API, and allows a python user to manipulate MEDCoupling C++ objects within python.
-* The CORBA API was written to facilitate distributed computation inside Salome. The API defines interfaces for the main MED objects (FIELD, SUPPORT, MESH). These interfaces are defined in the file MED.idl, they propose methods that allow distant users to access data. They are implemented by CORBA servants that encapsulate C++ Med Memory objects. This last library is the one we are using here to implement the CALCULATOR component on the server side.
+* The CORBA interface defined in MEDCouplingCorbaInterface.idl, propose methods that allow distant users to retrieve remote meshes, fields objects and to make available objects for others components. They are implemented by CORBA servants that encapsulate C++ MEDCoupling objects. This last library is the one we are using here to implement the CALCULATOR component on the server side.
-Finally, on the client side, we will demonstrate the use of the MEDClient classes. These classes are proxy classes designed to facilitate and optimize interaction of distant MED CORBA objects with local solvers. The Corba API is completely hidden to clients.
+Finally, on the client side, we will demonstrate the use of the MEDClient classes. These classes are proxy classes designed to facilitate and optimize interaction of distant MEDCoupling CORBA objects with local solvers. The Corba API is completely hidden to clients.
-Creation of a new Salome module - Compilation
+Creation of a new SALOME module - Compilation
---------------------------------------------
-The first step when developing a new Salome module is to create a directories tree with makefiles that allow you to compile a Salome component. This directories tree must follow Salome2 rules, which are described in [R1]_ and [R2]_. Create a complete tree from scratch is complicated, and error prone. The easiest way consist to find an existing module that “looks like the one you need”, and copy it. A shell script was written to facilitate this step : renameSalomeModule . This utility replace, after copying a module, any occurrence of the old name by the new one, thus avoiding to forget one of them. In the following example, we create a CALCULATOR_SRC module by copying HELLO_SRC module, then renameSalomeModule replace any occurrence of HELLO by CALCULATOR in CALCULATOR_SRC module:
+The first step when developing a new SALOME module is to create a directories tree with makefiles that allow you to compile a SALOME component. This directories tree must follow SALOME rules, which are described in [R1]_ and [R2]_. Create a complete tree from scratch is complicated, and error prone. The easiest way consist to find an existing module that “looks like the one you need”, and copy it. A shell script was written to facilitate this step : renameSalomeModule . This utility replace, after copying a module, any occurrence of the old name by the new one, thus avoiding to forget one of them. In the following example, we create a CALCULATOR_SRC module by copying HELLO_SRC module, then renameSalomeModule replace any occurrence of HELLO by CALCULATOR in CALCULATOR_SRC module:
-The remaining charge for the developer is to define the module interface (by writing a CORBA IDL file), and to implement it. But before, you may want to check that your duplicated module still compiles :
+The remaining charge for the developer is to define the module interface (by writing a CORBA IDL file), and to implement it. But before, you may want to check that your duplicated module still compiles ::
-
-
-::
-
- CALCULATOR_SRC/build_configure
mkdir CALCULATOR_BUILD
mkdir CALCULATOR_INSTALL
cd CALCULATOR_BUILD
- ../CALCULATOR_SRC/configure --prefix=installDir
+ cmake -DCMAKE_BUILD_TYPE=<Mode> -DCMAKE_INSTALL_PREFIX=CALCULATOR_INSTALL ../CALCULATOR_SRC
make && make install
-
+Where <Mode> is build mode (Release or Debug)
Modification of interface (IDL)
#include "SALOME_Component.idl"
#include "SALOME_Exception.idl"
- #include "MED.idl"
+ #include "MEDCouplingCorbaServant.idl"
module CALCULATOR_ORB
{
/*! \brief Interface of the %CALCULATOR component
*/
- interface CALCULATOR_Gen : Engines::Component
+ interface CALCULATOR_Gen : Engines::EngineComponent
{
/*!
Calculate the maximum relative difference of field with the previous one.
At first call, store passed field and return 1.
*/
double convergenceCriteria(
- in SALOME_MED::FIELDDOUBLE field);
+ in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
Apply to each (scalar) field component the linear function x -> ax+b.
Release field1 after use.
*/
- SALOME_MED::FIELDDOUBLE applyLin(
- in SALOME_MED::FIELDDOUBLE field1,
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface applyLin(
+ in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field1,
in double a1,
in double a2);
Return exception if fields are not compatible.
Release field1 and field2 after use.
*/
- SALOME_MED::FIELDDOUBLE add(
- in SALOME_MED::FIELDDOUBLE field1,
- in SALOME_MED::FIELDDOUBLE field2)
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface add(
+ in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field1,
+ in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field2)
raises (SALOME::SALOME_Exception);
/*!
return euclidian norm of field
Release field after use.
*/
- double norm2(in SALOME_MED::FIELDDOUBLE field);
+ double norm2(in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
return L2 norm of field
Release field after use.
*/
- double normL2(in SALOME_MED::FIELDDOUBLE field);
+ double normL2(in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
return L1 norm of field
Release field after use.
*/
- double normL1(in SALOME_MED::FIELDDOUBLE field);
+ double normL1(in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
return max norm of field
Release field after use.
*/
- double normMax(in SALOME_MED::FIELDDOUBLE field);
+ double normMax(in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
This utility method print in standard output the coordinates & field values
Release field after use.
*/
- void printField(in SALOME_MED::FIELDDOUBLE field);
+ void printField(in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field);
/*!
This method clones field in four examples.
Release field after use.
*/
void cloneField(
- in SALOME_MED::FIELDDOUBLE field,
- out SALOME_MED::FIELDDOUBLE clone1,
- out SALOME_MED::FIELDDOUBLE clone2,
- out SALOME_MED::FIELDDOUBLE clone3,
- out SALOME_MED::FIELDDOUBLE clone4 );
+ in SALOME_MED::MEDCouplingFieldDoubleCorbaInterface field,
+ out SALOME_MED::MEDCouplingFieldDoubleCorbaInterface clone1,
+ out SALOME_MED::MEDCouplingFieldDoubleCorbaInterface clone2,
+ out SALOME_MED::MEDCouplingFieldDoubleCorbaInterface clone3,
+ out SALOME_MED::MEDCouplingFieldDoubleCorbaInterface clone4 );
};
};
-* the inclusion of SALOME_Component.idl and SALOME_Exception.idl files, necessary for each Salome component (the CALCULATOR interface inherit from Engines::Component to benefit common services),
+* the inclusion of SALOME_Component.idl and SALOME_Exception.idl files, necessary for each SALOME component (the CALCULATOR interface inherit from Engines::EngineComponent to benefit common services),
-* the inclusion of MED.idl, because we are using the FIELDDOUBLE interface defined in SALOME_MED module.
+* the inclusion of MEDCouplingCorbaServant.idl, because we are using the MEDCouplingFieldDoubleCorbaInterface interface defined in SALOME_MED module.
The IDL attributes are mapped to C++ methods. This operation is normalized by CORBA. Here, we give the mapping for the types involved in our example:
-====================== =================
- **IDL Type** **C++ type**
-====================== =================
- **double** CORBA::DOUBLE
- **in FIELDDOUBLE** FIELDDOUBLE_ptr
- **out FIELDDOUBLE** FIELDDOUBLE_out
- **FIELDDOUBLE** FIELDDOUBLE_ptr
-====================== =================
+=============================================== =========================================
+ **IDL Type** **C++ type**
+=============================================== =========================================
+ **double** CORBA::DOUBLE
+ **in MEDCouplingFieldDoubleCorbaInterface** MEDCouplingFieldDoubleCorbaInterface_ptr
+ **out MEDCouplingFieldDoubleCorbaInterface** MEDCouplingFieldDoubleCorbaInterface_out
+ **MEDCouplingFieldDoubleCorbaInterface** MEDCouplingFieldDoubleCorbaInterface_ptr
+=============================================== =========================================
-FIELDDOUBLE_ptr and FIELDDOUBLE_out are C++ classes generated by the IDL compiler to map the MED CORBA interface FIELDDOUBLE . We will see below how to create such classes. But before, let's have a look on the new header of the user-defined derived class CALCULATOR.hxx :
+MEDCouplingFieldDoubleCorbaInterface_ptr and MEDCouplingFieldDoubleCorbaInterface_out are C++ classes generated by the IDL compiler to map the MEDCoupling CORBA interface MEDCouplingFieldDoubleCorbaInterface . We will see below how to create such classes. But before, let's have a look on the new header of the user-defined derived class CALCULATOR.hxx :
#include <SALOMEconfig.h>
#include CORBA_SERVER_HEADER(CALCULATOR_Gen)
- #include CORBA_CLIENT_HEADER(MED)
+ #include CORBA_CLIENT_HEADER(MEDCouplingCorbaServant)
#include "SALOME_Component_i.hxx"
class CALCULATOR:
virtual ~CALCULATOR();
CORBA::Double convergenceCriteria(
- SALOME_MED::FIELDDOUBLE_ptr field);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field);
CORBA::Double normMax(
- SALOME_MED::FIELDDOUBLE_ptr field1);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1);
CORBA::Double normL2(
- SALOME_MED::FIELDDOUBLE_ptr field1);
- CORBA::Double norm2(SALOME_MED::FIELDDOUBLE_ptr field1);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1);
+ CORBA::Double norm2(SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1);
CORBA::Double normL1(
- SALOME_MED::FIELDDOUBLE_ptr field1);
- SALOME_MED::FIELDDOUBLE_ptr applyLin(
- SALOME_MED::FIELDDOUBLE_ptr field1,
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr applyLin(
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1,
CORBA::Double a,CORBA::Double b);
- SALOME_MED::FIELDDOUBLE_ptr add(
- SALOME_MED::FIELDDOUBLE_ptr field1,
- SALOME_MED::FIELDDOUBLE_ptr field2)
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr add(
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1,
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field2)
throw ( SALOME::SALOME_Exception );
- void printField(SALOME_MED::FIELDDOUBLE_ptr field);
+ void printField(SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field);
void cloneField(
- SALOME_MED::FIELDDOUBLE_ptr field,
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field,
SALOME_MED::FIELDDOUBLE_out clone1,
SALOME_MED::FIELDDOUBLE_out clone2,
SALOME_MED::FIELDDOUBLE_out clone3,
-* the inclusion of CORBA_CLIENT_HEADER(MED) : this macro includes the header we needs to use CORBA MED interfaces (here, to use FIELDDOUBLE interface).
+* the inclusion of CORBA_CLIENT_HEADER(MEDCouplingCorbaServant) : this macro includes the header we needs to use CORBA MEDCoupling interfaces (here, to use MEDCouplingFieldDoubleCorbaInterface interface).
::
- CORBA::Double CALCULATOR::norm2(FIELDDOUBLE_ptr field1)
+ CORBA::Double CALCULATOR::norm2(SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1)
{
beginService( "CALCULATOR::norm2");
- BEGIN_OF("CALCULATOR::Norm2(FIELDDOUBLE_ptr field1)");
+ BEGIN_OF("CALCULATOR::Norm2(SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1)");
// Create a local field from corba field
// apply method normMax on it. When exiting the function
// f1 is deleted, and with it the remote corba field.
- FIELDClient<double> f1(field1);
- CORBA::Double norme = f1.norm2();
- END_OF("CALCULATOR::Norm2(FIELDDOUBLE_ptr field1)");
+ ParaMEDMEM::MEDCouplingAutoRefCountObjectPtr<ParaMEDMEM::MEDCouplingFieldDouble> f1=ParaMEDMEM::MEDCouplingFieldDoubleClient::New(field1);
+ CORBA::Double norme = f1->norm2();
+ END_OF("CALCULATOR::Norm2(SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1)");
endService( "CALCULATOR::norm2");
return norme;
}
-The norm2 method receives as an input parameter a reference to a distant MED CORBA field (named field1 ). It plays the role of the client toward the distant field field1 . As a client, we could directly call the methods of the FIELDDOUBLE CORBA API, for example call the getValue() method to retrieve the field values as an array. Doing this has some drawbacks. The transfer is not optimized because values are duplicated on server side. On the client side, we retrieve an array, but if we want to use existing solver or a function that takes an MedMemory C++ field, we need to rebuild a C++ field from the array, which is fastidious. That's why we are using here FIELDClient class : FIELDClient<double>. This is a proxy C++ template class (also available for int type), that inherit the interface of the MedMemory C++ FIELD<double> class. Therefore, it can be used anywhere in place where a FIELD<double> is expected. The characteristics of this class are :
+The norm2 method receives as an input parameter a reference to a distant MEDCoupling CORBA field (named field1 ). It plays the role of the client toward the distant field field1 . As a client, we could directly call the methods of the MEDCouplingFieldDouble CORBA interface, for example call the getValue() method to retrieve the field values as an array. Doing this has some drawbacks. The transfer is not optimized because values are duplicated on server side. On the client side, we retrieve an array, but if we want to use existing solver or a function that takes an MEDCoupling C++ field, we need to rebuild a C++ field from the array, which is fastidious. That's why we are using here MEDCouplingFieldDoubleClient class : MEDCouplingFieldDouble. This is a proxy C++ template class (also available for int type), that inherit the interface of the MEDCoupling C++ MEDCouplingFieldDouble class. Therefore, it can be used anywhere in place where a MEDCouplingFieldDouble is expected. The characteristics of this class are :
* it holds the CORBA reference of the distant field – and release it when object get out of scope (done in the class destructor),
-* the memory is automatically managed : when deleted, the FIELDClient release the CORBA reference it holds.
+* the memory is automatically managed : when deleted, the MEDCouplingFieldDoubleClient release the CORBA reference it holds.
-* and as already said, it can be used anywhere in state of a FIELD<double>, thus facilitating re-use of existing C++ API.
+* and as already said, it can be used anywhere in state of a MEDCouplingFieldDouble, thus facilitating re-use of existing C++ API.
-In our example, we simply create a FIELDClient , and then call on it the norm2 method of the MedMemory C++ API :
+In our example, we simply create a MEDCouplingFieldDoubleClient , and then call on it the norm2 method of the MEDCoupling C++ API :
::
- FIELDClient<double> f1(field1);
- CORBA::Double norme = f1.norm2();
+ ParaMEDMEM::MEDCouplingAutoRefCountObjectPtr<ParaMEDMEM::MEDCouplingFieldDouble> f1=ParaMEDMEM::MEDCouplingFieldDoubleClient::New(field1);
+ CORBA::Double norme = f1->norm2();
A client class was also created for MESH, called MESHClient , with the same characteristics. For meshes, all the arrays (connectivities, coordinates) are transferred on demand, which is generally more interesting than for fields (where we usually need to retrieve values soon or later).
::
- FIELDDOUBLE_ptr CALCULATOR::applyLin(
- FIELDDOUBLE_ptr field1,
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr CALCULATOR::applyLin(
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr field1,
CORBA::Double a,CORBA::Double b)
{
beginService( "CALCULATOR::applyLin");
BEGIN_OF("CALCULATOR::applyLin");
// create a local field on the heap,
// because it has to remain after exiting the function
- FIELD<double> * f1 = new FIELDClient<double>(field1);
+ ParaMEDMEM::MEDCouplingAutoRefCountObjectPtr<ParaMEDMEM::MEDCouplingFieldDouble> f1=ParaMEDMEM::MEDCouplingFieldDoubleClient::New(field1);
+ int nbOfCompo=f1->getArray()->getNumberOfComponents();
+ f1->getArray()->rearrange(1);
+ ParaMEDMEM::MEDCouplingFieldDoubleServant *NewField=NULL;
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr myFieldIOR = NULL;
f1->applyLin(a,b);
+ f1->getArray()->rearrange(nbOfCompo);
// create servant from f1, give it the property of c++
// field (parameter true). This imply that when the
// client will release it's field, it will delete
// NewField,and f1.
- FIELDDOUBLE_i * NewField = new FIELDDOUBLE_i(f1,true) ;
+ NewField = new ParaMEDMEM::MEDCouplingFieldDoubleServant(f1);
// activate object
- FIELDDOUBLE_ptr myFieldIOR = NewField->_this() ;
+ myFieldIOR = NewField->_this() ;
END_OF("CALCULATOR::applyLin");
endService( "CALCULATOR::applyLin");
-The method is client for the parameter field field1 , and server for the returned field NewField . The client part (treatment of field1 ) is similar to the first example : we create with field1 a FIELDClient f1 and apply on it C++ method applyLin. The difference is that creation is done on the heap, not on the stack (we will explain why later) :
+The method is client for the parameter field field1 , and server for the returned field NewField . The client part (treatment of field1 ) is similar to the first example : we create with field1 a MEDCouplingFieldDoubleClient f1 and apply on it C++ method applyLin. The difference is that creation is done on the heap, not on the stack (we will explain why later) :
::
- FIELDDOUBLE_i * NewField = new FIELDDOUBLE_i(f1,true) ;
+ ParaMEDMEM::MEDCouplingFieldDoubleServant * NewField = new ParaMEDMEM::MEDCouplingFieldDoubleServant(f1);
f1->applyLin(a,b);
-For the server part, we create a CORBA field (class FIELDDOUBLE_i ), activate it and return a reference on it :
+For the server part, we create a CORBA field (class ParaMEDMEM::MEDCouplingFieldDoubleCorbaInterface ), activate it and return a reference on it :
::
- FIELDDOUBLE_i * NewField = new FIELDDOUBLE_i(f1,true) ;
- FIELDDOUBLE_ptr myFieldIOR = NewField->_this() ;
+ ParaMEDMEM::MEDCouplingFieldDoubleServant * NewField = new ParaMEDMEM::MEDCouplingFieldDoubleServant(f1);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr myFieldIOR = NewField->_this() ;
return myFieldIOR;
-The parameters passed to the FIELDDOUBLE_i constructor are the C++ field f1 that is wrapped and used to give the services declared in IDL, and a boolean that indicates if ownership of wrapped field is transferred or not. If ownership is transferred, this means that when the CORBA field will be released by a client (for example by a FIELDClient created with a reference on it), it will delete the C++ field it holds. For example, the following code a hypothetic client could write would cause deletion of C++ field f1 :
+The parameters passed to the ParaMEDMEM::MEDCouplingFieldDoubleServant constructor are the C++ field f1 that is wrapped and used to give the services declared in IDL, and a boolean that indicates if ownership of wrapped field is transferred or not. If ownership is transferred, this means that when the CORBA field will be released by a client (for example by a MEDCouplingFieldDoubleClient created with a reference on it), it will delete the C++ field it holds. For example, the following code a hypothetic client could write would cause deletion of C++ field f1 :
::
- FIELDDOUBLE_ptr distant_f = CALCULATOR::applyLin(f,a,b);
- FIELD<double>* local_f = new FIELDClient<double>(distant_f);
+ SALOME_MED::MEDCouplingFieldDoubleCorbaInterface_ptr distant_f = CALCULATOR::applyLin(f,a,b);
+ ParaMEDMEM::MEDCouplingAutoRefCountObjectPtr<ParaMEDMEM::MEDCouplingFieldDouble> local_f=ParaMEDMEM::MEDCouplingFieldDoubleClient::New(distant_f);
// .. Use local_f
delete local_f; // causes release of distant_f and deletion
// of the C++ field it holds
-.. [R1] Guide pour le développement d'un module Salome 2 en Python (C. Caremoli) (voir :ref:`pysalome`).
+.. [R1] Guide for the development of a SALOME module in Python (C. Caremoli) (see :ref:`pysalome`).
-.. [R2] Guide pour le développement d'un module Salome 2 en C++ (N. Crouzet) (voir :ref:`cppsalome`).
+.. [R2] Guide for the development of a SALOME module in C++ (N. Crouzet) (see :ref:`cppsalome`).
-.. [R3] Définition du modèle d'échange de données MED V2.2 (V. Lefebvre, E. Fayolle).
+.. [R3] Définition du modèle d'échange de données MED V3 (V. Lefebvre, E. Fayolle).
-.. [R4] Guide de référence de la bibliothèque MED V2.2 (V. Lefebvre, E. Fayolle).
+.. [R4] Guide de référence de la bibliothèque MED V3 (V. Lefebvre, E. Fayolle).
-.. [R5] Guide d'utilisation de la bibliothèque MED V2.2 (V. Lefebvre, E. Fayolle).
+.. [R5] Guide d'utilisation de la bibliothèque MED V3 (V. Lefebvre, E. Fayolle).
-.. [R6] User's guide of Med Memory (P. Goldbronn, E. Fayolle, N. Bouhamou).
+.. [R6] User's guide of MEDCoupling (Doc HTML MED).
