Back to index

salome-med  6.5.0
MEDMEM library


Rationale for Med Memory

The Med data exchange model (DEM in English) is the format used in the Salome platform for communicating data between different components. It manipulates objects that describe the meshes underlying scientific computations and the value fields lying on these meshes. This data exchange can be achieved either through files using the Med-file formalism or directly through memory with the Med Memory (MEDMEM) library.

The Med libraries are oganized in multiple layers:

Thanks to Med Memory, any component can access a distant mesh or field object. Two codes running on different machines can thus exchange meshes and fields. These meshes and fields can easily be read/written in a Med file format, enabling access to the whole Salome suite of tools (CAD, meshing, Visualization, other components).


In this document, we describe the API of the Med Memory library (available in C++ and in Python). This document is intended for developers who are in charge of integrating existing applications in the Salome platform.

As will be seen in section Med Memory API, the API consists of very few classes:

All these are detailed in the following sections. The C++ formalism will be used for the description in these sections. Python syntax is very similar and is given in appendix medmem_sec_python.

Naming conventions

The naming conventions are rather straightforward, but the user familiar with the Med-File semantics may find that there are a few noticeable differences (see the following section).

Differences with Med-File concepts

Though the MEDMEM library can recompute a descending connectivity from a nodal connectivity, MEDMEM drivers can only read MED files containing the nodal connectivities of the entities. In MEDMEM, constituent entities are stored as MED_FACE or MED_EDGE, whereas in MED File, they should be stored as MED_MAILLE.

The field notion in MED File and MEDMEM is quite different. In MEDMEM a field is of course defined by its name, but also by its iteration number and its order number. In MED File a field is only flagged by its name. For instance, a temperature at times t=0.0 s, t=1.0 s, t=2.0 s will be considered as a single field in Med File terminology, while it will be considered as three distinct fields in the Med Memory sense.

Drivers for reading and writing

MEDMEM supports data exchange in following formats:

Limitation of length of names in GIBI format is overcome by storing names in the specific string pile of GIBI file. This pile is used to map actual long names of the data objects to their shortened representation.

Med Memory API



Med Memory uses two namespaces : MEDMEM which is the general namespace where the main classes are defined and MED_EN which defines enums that can be used by an English-speaking programer.


At a basic usage level, the API consists in few classes which are located in the MEDMEM C++ namespace (consult figure fig_UML_light which gives an UML diagram view of the main Med Memory classes):

UML diagram of basic Med Memory API classes
The API of those classes is quite sufficient for most of the component integrations in the Salome platform. The use of the Med Memory libraries may make easier the code coupling in the Salome framework. With these classes, it is possible to:

Note that on the figure fig_UML_light as well as on figure fig_UML the life cycle of mesh and field objects are independent. Destroying a field will have no effect on the mesh. But the user has to maintain the link: a mesh aggregates a support which aggregates a field. If the user has to delete Med Memory objects, the field has to be deleted first, then the support and finally the mesh.

A more advanced usage of the Med Memory is possible through other classes. Figure fig_UML gives a complete view of the Med Memory API. It includes :

UML diagram of Med Memory API classes


A few enums are defined in the MED_EN namespace :