hxx2salome : a SALOME component generator¶
This document is the following of the HELLO component documentation [R1], which presented the basis for the implementation of a SALOME Component, and the CALCULATOR component documentation [H1], which introduced the use of MED within the SALOME context. These two examples showed that implementing a SALOME component doesn’t require much imagination, it can be done by following some predefined rules. Thus, it is possible, provided a C++ standalone component, to wrap it into a SALOME Component automatically. This document presents hxx2salome, a prototype tool for automatic SALOME Component generation. This tool starts from the interface of a C++ component (an .hxx file), parse the public API , and use the type information to generate the SALOME component (the IDL interface, and its implementation).
Getting started¶
In this chapter, we will create from scratch a new SALOME component that add and multiply integers, and compute a factorial. We suppose that hxx2salome (and the related tools SA_new_component and SA_build ) have been installed in a directory called $HXX2SALOME_ROOT_DIR , which is present in your $PATH .
C++ component implementation¶
The first thing to do is to implement the C++ engine that will perform the services. To do it, we use the SA_new_cpp_component tool:
$ SA_new_cpp_component CALC
$ ls CALC_CPP_SRC/
adm archive AUTHORS build_configure ChangeLog configure.in.base
Makefile.am NEWS README rfind root_clean src
The SA_new_cpp_component CALC command has created a complete tree in directory CALC_CPP_SRC that allow you to build a C++ component with a SWIG python interface. Now we have to define the interface and implement it. For that, we edit and adapt the templates that have been generated in the source directory:
$ cd CALC_CPP_SRC/src/CALC/CALC_CXX # go in source dir
$ vi CALC.hxx # edit interface template and adapt it
#ifndef _CALC_HXX_
#define _CALC_HXX_
class CALC
{
public:
unsigned fact(unsigned n);
int add(int n1, int n2);
int mul(int n1, int n2);
};
#endif
$ vi CALC.cxx # edit and adapt class implementation template
#include "CALC.hxx"
int CALCUL::add(int i1, int i2)
{
return i1+i2;
}
int CALCUL::mul(int i1, int i2)
{
return i1*i2;
}
unsigned CALCUL::fact(unsigned n)
{
unsigned fact=1;
for (unsigned i=n; i!=1; --i)
fact*=i;
return fact;
}
A template python test file was also generated, that can be callable both from python and from SALOME. You can if you wish edit it and add the tests you want:
$ cd ../CALC_TEST
$ vi CALC_test.py
from os import getenv
if getenv("SALOMEPATH"):
import salome
import CALC_ORB
my_CALC = salome.lcc.FindOrLoadComponent("FactoryServer", "CALC")
IN_SALOME_GUI = 1
else:
import CALCSWIG
my_CALC=CALCSWIG.CALC()
pass
#
#
print "Test Program of CALC component"
print "5 + 3 = ", my_CALC.add(5,3)
print "5 * 3 = ", my_CALC.mul(5,3)
print "5! = ", my_CALC.fact(5)
Only the last three lines were added, the beginning is part of generated template.
Compilation – Testing with python¶
It’s time now to compile the component and test it. The component is built under Automake. The build procedure (build_configure, configure, make, make install) is explained in the README file. You can also use the SA_build tool:
$ cd ../../../.. # go in father directory of CALC_CPP_SRC
$ SA_build CALC_CPP_SRC
...
$ ls
CALC_CPP_BUILD CALC_CPP_INSTALL CALC_CPP_SRC
$ ls CALC_CPP_INSTALL # check installation was done
bin include lib
# update pathes for component's use within python
$ setenv PYTHONPATH \
instalDir/bin/salome:instalDir/lib/salome:$PYTHONPATH
$ setenv LD_LIBRARY_PATH \
instalDir/lib/salome:$LD_LIBRARY_PATH
$ python # test component with python
>>> import CALC_test
Test Program of CALC component
5 + 3 = 8
5 * 3 = 15
5! = 120
Before testing the component from python, it was necessary to update LD_LIBRARY_PATH and PYTHON_PATH environment variables.
SALOME component generation¶
The C++ engine is finished, and tested - the final step is the integration inside SALOME. This is done using hxx2salome tool (the options used here are explained in Chapter 8.2 – the tool also has a graphical interface):
hxx2salome -c -e ${INTEGRATION_ROOT}/my_env_products.sh instalDir/CALC_CPP_INSTALL \
CALC.hxx libCALCCXX.so ${INTEGRATION_ROOT}
...
$ source ${INTEGRATION_ROOT}/my_env_products.sh
$ runSalome –-modules=CALC # launch salome with CALC compo
>>> import CALC_test # import test case from python console
The component can now be used inside SALOME, from the python embedded console, or from Supervision.
What is a C++ component?¶
We explain in this paragraph what is meant by “C++ component” in this document. This definition is definitely not unique!
Let’s first try to define more generally what components are. They are used to deliver reusable, “off-the-shelf” software unit for incorporation into large applications (such as frameworks) : a component can be deployed independently and is subject to third-party composition. Its aim is to improve efficiency for end-users. It has specified interfaces and explicit context dependencies only. It encapsulates small-scale abstractions within a given domain.
A C++ component is a “high level” unit of reuse, based upon some source code libraries (developed in FORTRAN, C or C++). It takes the form of a C++ class. Its interface is the public API of this class, and is declared in an include file. It is designed to collaborate with other components . Therefore its API emphasizes the logical chains of computation a user can perform, and the data that may be exchanged with external world conform to standards (for example in the SALOME context: basic types, MED types and XDATA types).
For being more concrete, let’s take the (simple) example of a steady-state neutronic component developed by CEA to work in collaboration with thermal-hydraulic and fuel-pin mechanics components. The interface of this component is:
class CoreComponent
{
public:
void start();
void end();
void compute_power(int nitermax=200,
double epsflux=1e-4,
double espeigenvalue=1e-4);
const MEDMEM::MESH& DKCore_get_mesh();
const MEDMEM::FIELD<double>* get_power();
void feedback(const MEDMEM::FIELD<double>& Tcomb,
const MEDMEM::FIELD<double>& Dmod);
}
It emphasizes the following chain of computation:
It is designed to exchange MED objects: export of the mesh used for computation, and the neutronic power field, and import of fuel temperature and moderator density fields for thermal-hydraulic feedback.
This component was implemented with a preexisting function library, that was used in a neutronic software context. The internal format for meshes and fields was converted in MED format for exchange purpose.
SALOME component architecture (insights)¶
The SALOME component architecture is based on CORBA , and has been optimized for big data transfers. The key points of the architecture are:
- Distributed components with the appearance of proximity. There is no difference between local and distant objects, the network exchanges are done by the CORBA bus, or MPI or any other protocol, everything being totally transparent for the end user, who just has to call methods on his “apparently local” objects.
- Heterogeneities are hidden by CORBA , which is multi-language and multi-platform!
- An open architecture, object oriented, facilitating evolutions and integration of new components.
- On top of the CORBA layer has been developed a specialized layer ( KERNEL ), which offers services like management of the components and their life cycle, persistence of objects, resource management, logs and notification, supervision, and GUI .
- A common normalized data format for meshes an fields ( MED ), which facilitates exchanges between components and integration in the platform.
The components are usually developed with C++ or python – but this is not an obligation. For components based upon a C-compatible library of functions (Fortran, C, C++, ...), the proposed architecture is the following :
The low level libraries are wrapped in a high level C++ component, that is exported to Python using SWIG, and for distribution and coupling to SALOME using hxx2salome. Same scripts can be use in Python or within SALOME.
SALOME Component generation¶
In this chapter, we explain briefly the approach used to pass from a C++ component (as described in chapter 1) to a SALOME component.
A SALOME component is defined by its IDL interface (as explained in ...). It is then implemented using a target language, for example C++ (this step is called the IDL to C++ mapping).
Here we are doing the opposite! We have a C++ component with its interface (the definition of a class in a header), and we want to get a SALOME component (with its IDL interface, implemented using the C++ component). For doing this, we have to invert the IDL to C++ mapping. This is not feasible in a most general way (because of course user-defined C++ types don’t have their counterpart in IDL). But if we restrict the C++ type to the mapping of the IDL types supported by SALOME, then we have a way to go back from C++ to IDL .
The operations performed for the SALOME component generation are summed up in the following figure:
After these operations, the generated files are inserted in a template SALOME module (basically a clone of the CALCULATOR component described in ...). We obtain that way a full module ready for compiling.
IDL definition¶
The IDL code generation is based upon the type analysis of the C++ public API . Of course, generation can be done only if there is a CORBA equivalent type. This is the case for all basic types. It is also the case for the MED types, because a CORBA level was developed ( MESH , SUPPORT and FIELD interfaces), and a Client level that allow to create local C++ MED objects from CORBA objects. This last point is important for code generation, because it simplify it greatly! (The only thing to do is to create a client object and pass it to the C++ API ). The last supported types are vectors, they are treated using the Sender/Receiver mechanism of SALOME, thus optimizing the data transfer.
Correspondance for parameters¶
The following table resume all the supported C++ types for parameters, and the associated IDL type:
| C++ Argument type | IDL associated type |
|---|---|
| int | in long |
| double | in double |
| float | in float |
| long | in long |
| short | in short |
| unsigned | in unsigned long |
| const char* | in string |
| const std::string& | in string |
| int& | out long |
| double& | out double |
| long& | out long |
| short& | out short |
| float& | out float |
| unsigned& | out unsigned long |
| std::string& | out string |
| const MEDMEM::MESH& | in SALOME_MED::MESH |
| const MEDMEM::MESH* | in SALOME_MED::MESH |
| const MEDMEM::SUPPORT& | in SALOME_MED::SUPPORT |
| const MEDMEM::SUPPORT* | in SALOME_MED::SUPPORT |
| const MEDMEM::FIELD<double>* | in SALOME_MED::FIELDDOUBLE |
| const MEDMEM::FIELD<double>& | in SALOME_MED::FIELDDOUBLE |
| const std::vector<double>& | in SALOME::SenderDouble |
| std::vector<double>*& | out SALOME::SenderDouble |
| const std::vector< std::vector<double> >& | in SALOME::Matrix |
| MEDMEM::FIELD<double>*& | out SALOME_MED::FIELDDOUBLE |
| const MEDMEM::FIELD<int>* | in SALOME_MED::FIELDINT |
| const MEDMEM::FIELD<int>& | in SALOME_MED::FIELDINT |
| const std::vector<int>& | in SALOME::SenderInt |
| std::vector<int>*& | out SALOME::SenderInt |
| MEDMEM::FIELD<int>*& | out SALOME_MED::FIELDINT |
As we can see, it is very important to take great care of the qualifiers used in the C++ interface because they are interpreted. The determination of the in/out qualifier of IDL parameters is based upon the const and reference qualifier of C++ parameters. Basic types (passed by value in C++) are considered in parameters, references to basic types are considered out parameters. For user defined types, the const qualifier is interpreted as in parameter, and reference to pointer as out parameter.
For simplification purpose, SALOME doesn’t allow the use of IDL inout parameters. For this reason, non const pointers or references are not treated .
Correspondance for returned type¶
The mapping between C++ returned types and their IDL counterpart is similar, except that we don’t have to care about in/out qualifier! (The const and reference qualifier don’t discriminate IDL type, but this information will nevertheless be useful when generating IDL implementation for memory management).
| C++ returned type | IDL associated type |
|---|---|
| void | void |
| int | long |
| double | double |
| float | float |
| long | long |
| short | short |
| unsigned | unsigned long |
| const char* | string |
| char* | string |
| std::string | string |
| const MEDMEM::MESH& | SALOME_MED::MESH |
| MEDMEM::MESH& | SALOME_MED::MESH |
| const MEDMEM::MESH* | SALOME_MED::MESH |
| MEDMEM::MESH* | SALOME_MED::MESH |
| MEDMEM::SUPPORT* | SALOME_MED::SUPPORT |
| const MEDMEM::FIELD<double>* | SALOME_MED::FIELDDOUBLE |
| const MEDMEM::FIELD<double>& | SALOME_MED::FIELDDOUBLE |
| MEDMEM::FIELD<double>* | SALOME_MED::FIELDDOUBLE |
| MEDMEM::FIELD<double>& | SALOME_MED::FIELDDOUBLE |
| std::vector<double>* | SALOME::SenderDouble |
| const MEDMEM::FIELD<int>* | SALOME_MED::FIELDINT |
| const MEDMEM::FIELD<int>& | SALOME_MED::FIELDINT |
| MEDMEM::FIELD<int>* | SALOME_MED::FIELDINT |
| MEDMEM::FIELD<int>& | SALOME_MED::FIELDINT |
| std::vector<int>* | SALOME::SenderDouble |
| std::vector<std::vector<double> >* | SALOME::Matrix |
Example¶
To finish, let’s have a look on the IDL generated module corresponding to our neutronic component example:
module CoreComponent_ORB
{
interface CoreComponent_Gen : Engines::EngineComponent,
SALOME::MultiCommClass
{
void start();
void end();
void compute_power(in long nitermax,
in double epsflux,
in double espeigenvalue);
SALOME_MED::MESH get_mesh();
SALOME_MED::FIELDDOUBLE get_power();
void set_feedback(in SALOME_MED::FIELDDOUBLE Tcomb,
in SALOME_MED::FIELDDOUBLE Dmod);
};
};
IDL Implementation¶
As explained in [R2] and [H2], the IDL implementation consists in writing a servant (an object that will perform the IDL contract). The source of this servant is composed in two files, named in SALOME by convention <module_name>.hxx and <module_name>.cxx . The generated code for these two files is also based upon the type analysis of the C++ public API : for each C++ type, we know the IDL type that was associated (cf. Chapter 4), and consequently the code to generate. This code follows always the same scheme. We first generate the header <module_name>.hxx , which contains the class declaration of the servant, and is imposed by the rules of the C++ mapping of CORBA. We then generate <module_name>.cxx, which contains the class definition. For each method, we proceed in three steps :
- Arguments processing : conversion of the types imposed by C++ mapping rules to the type of the C++ component. Of course, this conversion is always possible, because we have restricted the C++ component type to the one for which this operation is possible!
- Call of the C++ component : the call is performed with the converted types of step 1.
- Post treatment of the returned argument : This operation is the opposite of first step : the type of the parameters returned by the C++ component are converted to match the C++ mapping rules.
This being abstract, let’s examine the generated code for two of the CoreComponent example :
const MEDMEM::FIELD<double>* get_power();
void feedback(const MEDMEM::FIELD<double>& Tcomb,
const MEDMEM::FIELD<double>& Dmod);
IDL:
SALOME_MED::FIELDDOUBLE get_power();
void set_feedback(in SALOME_MED::FIELDDOUBLE Tcomb,
in SALOME_MED::FIELDDOUBLE Dmod);
CoreComponent_i.hxx:
SALOME_MED::FIELDDOUBLE_ptr get_power();
void set_feedback(
SALOME_MED::FIELDDOUBLE_ptr Tcomb,
SALOME_MED::FIELDDOUBLE_ptr Dmod);
CoreComponent_i.cxx:
SALOME_MED::FIELDDOUBLE_ptr DKCORE_i::get_power()
{
beginService("DKCORE_i::get_power");
BEGIN_OF("DKCORE_i::get_power");
// Call cpp component
const MEDMEM::FIELD<double>* _rtn_cpp=cppCompo_->get_power();
// Post-processing & return
MEDMEM::FIELDDOUBLE_i* _rtn_field_i=new MEDMEM::FIELDDOUBLE_i(
const_cast<MEDMEM::FIELD<double>*>(_rtn_cpp),false);
SALOME_MED::FIELDDOUBLE_ptr _rtn_ior = _rtn_field_i->_this();
endService("DKCORE_i::get_power");
END_OF("DKCORE_i::get_power");
return _rtn_ior;
}
void DKCORE_i::set_feedback(
SALOME_MED::FIELDDOUBLE_ptr Tcomb,
SALOME_MED::FIELDDOUBLE_ptr Dmod)
{
beginService("DKCORE_i::set_feedback");
BEGIN_OF("DKCORE_i::set_feedback");
// Arguments processing
MEDMEM::FIELDClient<double> _Tcomb(Tcomb);
MEDMEM::FIELDClient<double> _Dmod(Dmod);
// Call cpp component
cppCompo_->set_feedback( _Tcomb, _Dmod);
// Post-processing & return
endService("DKCORE_i::set_feedback");
END_OF("DKCORE_i::set_feedback");
}
The IDL generated part is driven by the tables given in Chapter 5.1 and 5.2. You can check for example that in SALOME_MED::FIELDDOUBLE correspond in table 5.1 to C++ type const MEDMEM::FIELD<double>&.
The CoreComponent_i.hxx interface is imposed by the CORBA norm (C++ mapping).
Finaly, the implementation of methods in CoreComponent_i.cxx is done in three steps. First step is argument processing : we convert the Corba types in order to call the C++ component. In set_feedback method, this consists in creating FIELDClient from the received FIELDDOUBLE_ptr . Second step is the call of C++ component method with converted types of step 1. Last step is to create Corba returned types from the types returned bu C++. In get_power method, we wrap the returned const MEDMEM::FIELD<double>* in a Corba field FIELDDOUBLE_ptr .
A last word about memory management. The Corba field created in get_power method doesn’t take ownership of the C++ field it wrap (false parameter in the constructor). This is due to the fact that the C++ component method return a const field, thus indicating it owns the returned field. With a non const field, the Corba field would have get ownership (true parameter passed to the constructor), which means that deletion of Corba field causes deletion of C++ field).
Usage¶
Installation¶
The generator is a script file called hxx2salome , written in bash, which manages:
- the code generation,
- the compilation of generated module,
- the update of SALOME environment file.
This script can be used without any compilation. A Graphical User Interface, named ghx2salome was developed (with Qt) to wrap the script, which need to be installed and compiled:
cd <absolute path of HXX2SALOME>
./build_configure
./configure --prefix=<absolute path of HXX2SALOME>
make
make install
After installing, you have to set the environment variable HXXTOSALOME_ROOT_DIR to the bin directory that was installed and contains the hxx2salome, SA_new_cpp_component, SA_build scripts and the ghx2salome binary:
setenv HXX2SALOME_ROOT_DIR=<absolute path of HXX2SALOME>/bin
You may finally also configure the hxx2salome script (it is not mandatory, but may facilitate usage). For configuring the script, you can set the two following variables defined at the beginning :
- ENVIRON_FILE : SALOME environment file used for compilation. If present, hxx2salome will propose to compile new module (by sourcing ENVIRON_FILE file, and executing build_configure, configure, make & make install). It will also update this file with the new environment variable necessary to run generated module. This environment file can also be passed using -e option.
- CONFIGURE_OPTION : options passed to configure (for example –disable-debug or –enable-production ). This one cannot be passed by argument to the script. Default is no option.
Running the script¶
The command to run the script is (supposing HXX2SALOME_ROOT_DIR is in your PATH ) :
hxx2salome [OPTIONS] CPPdir CPP.hxx libCPP.so SALOMEdir
where the mandatory components are:
- CPPdir : the installation directory (absolute path) of the c++ standalone component,
- CPP.hxx : the header name of the component,
- libCPP.so : the name of the shared library.
- SALOMEdir : the directory where you want to install generated SALOME component.
(Of course, CPP.hxx and libCPP.so have to be found in CPPdir )
In addition, you can use following options to transmit information to generator:
-c : to compile the component after code generation,
-l : to launch SALOME with the component after compilation,
-e : environment_file : to specify an SALOME environment file to source (for compiling)
The script gives user information on what have been done (checking of arguments, extraction of public function, which public function is compatible or not, the generated IDL, ...) to allow to check validity.
Running the GUI¶
The GUI allow you to select the arguments with a file browser – thus avoiding spelling mistakes in file names that cause script abortion. The command to start the GUI is gxx2salome . It launch the following window :
Limitations – Advice¶
- The standalone C++ component should have a default constructor (a constructor without arguments). This is because there is no mechanism to transmit arguments from SALOME to a user-defined component. If your component needs information to be valid, you have to split construction and initialization, by adding a method that does initialization.
- Only methods with compatible types (types listed in Chapter 5, for which a conversion from CORBA to C++ is available) are treated. If a method contains non compatible types, it is just ignored (it is not blocking, you’ll just get a SALOME component without the non compatibles methods).
- Avoid inline functions inside the header. They are not treated! If you have inlined functions in your header, you can remove them – or create a clone of your header only for generation purpose, without inline functions.
- The name of the C++ component (the name of the class), which provide the name of the SALOME component, should be uppercase. This strange limitation is due to SALOME.
- Typedef in the header are prohibited!
- The const qualifiers should be carefully analyzed, it impact the way SALOME will manage memory. The critical case is if you have an internal field, and you (wrongly) return a non const pointer on it. Because the pointer is non const, it is considered that the SALOME component takes ownership of the field, and consequently will delete it after usage – thus invalidating an internal pointer of your C++ component. Crash is the most frequent issue of this case...
- Avoid including headers in your component interface. Use as much as possible forward declaration. This common C++ rule will reduce the dependencies and fasten compilation. The side effect for the generator is that if you include headers in your component interface you’ll have to indicate to the generator the paths where to find these included files.
- Avoid “using namespace” instruction in header (common C++ rule). MED and XDATA types should figure with the resolution operator. The generator doesn’t recognize types if the namespace is not specified.
| [H1] | The MED Calculator component (N. Crouzet) (see MEDCoupling Calculator Component). |
| [H2] | Integration of components into the SALOME environment (M. Tajchman) (see Integration of components into the SALOME environment) |