MEDMEM library

Introduction

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).

Outline

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.

Med Memory API

Conventions

Namespaces

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.

Classes

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_light.png

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 that the MED container controls the life cycle of all the objects it contains~: its destructor will destroy all the objects it aggregates. On the other hand, the life cycle of mesh, support and field objects are independent. Destroying a support (resp. a field) will have no effect on the mesh (resp. support) which refers to it. 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_small.png

UML diagram of Med Memory API classes

Enums

A few enums are defined in the MED_EN namespace :

Generated on Sat May 1 03:22:36 2010 for Med Memory Users' Guide by  doxygen 1.6.3