include $(top_srcdir)/adm_local/unix/make_common_starter.am
-SUBDIRS = MEDMEM salome doxygen
+SUBDIRS = salome doxygen
dev_docs:
(cd salome && $(MAKE) $(AM_MAKEFLAGS) dev_docs)
GENERATE_TESTLIST = YES
GENERATE_BUGLIST = YES
ALIASES =
-ENABLED_SECTIONS = user MEDMEM_ug
+ENABLED_SECTIONS = user MEDCOUPLING_ug
MAX_INITIALIZER_LINES = 30
OPTIMIZE_OUTPUT_FOR_C = NO
SHOW_USED_FILES = NO
@srcdir@/../../src/INTERP_KERNEL/Bases \
@srcdir@/../../src/INTERP_KERNEL/Geometric2D \
@srcdir@/../../src/MEDCoupling \
- @srcdir@/../../src/MEDLoader \
- @srcdir@/../../src/MEDMEM
+ @srcdir@/../../src/MEDLoader
-FILE_PATTERNS = MEDMEM_GMesh.* \
- MEDMEM_Mesh.* \
- MEDMEM_Grid.* \
- MEDMEM_Meshing.* \
- MEDMEM_Support.* \
- MEDMEM_Field.* \
- MEDMEM_MedFileBrowser.* \
- MEDMEM_Remapper.* \
- InterpKernelDEC.* \
+FILE_PATTERNS = InterpKernelDEC.* \
OverlapDEC.* \
DEC.* \
DisjointDEC.* \
EXAMPLE_PATH = @srcdir@/../../src/ParaMEDMEM \
@srcdir@/../../src/MEDCoupling/Test \
@srcdir@/../../src/MEDCoupling_Swig \
- @srcdir@/../../src/MEDLoader/Swig \
- @srcdir@/../../doc/MEDMEM \
- @srcdir@/../../src/MEDMEMBinTest \
- @srcdir@/../../src/MEDMEM
+ @srcdir@/../../src/MEDLoader/Swig
EXAMPLE_PATTERNS = *.cxx *.py
EXAMPLE_RECURSIVE = NO
IMAGE_PATH = @srcdir@/figures
# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
#
-# MED MEDMEM : MED files in memory
-#
include $(top_srcdir)/adm_local/unix/make_common_starter.am
DOX_INPUT_FILE = Doxyfile_med_user
Geometric2D.dox \
biblio.dox \
barycoords.dox \
- dualmesh.dox \
- extractor.dox \
- field.dox \
- grid.dox \
interpkernel.dox \
interptheory.dox \
interptools.dox \
intersectors.dox \
medcoupling.dox \
- medfilebrowser.dox \
medloader.dox \
- medmem.dox \
- medsplitter.dox \
- mesh.dox \
- meshing.dox \
- polygon.dox \
+ medpartitioner.dox \
remapper.dox \
- support.dox \
tools.dox \
static/footer.html \
static/doxygen.css \
+++ /dev/null
-/*!
-\page dualmesh DualMESH
-
-The \ref INTERP_KERNEL::DualMESH "DualMESH" class is an auxiliary class used to perform P0->P1
-interpolation in \ref interpkernel. It takes place of target mesh in
-interpolation process and is initialized by the target mesh.
-
-DualMESH inherits from MEDMEM::MESH. It's API consists of only a
-constructor with one argument of the input target MEDMEM::MESH.
-
-The dual mesh is a polygonal mesh in 2D space or polyhedral mesh in 3D space
-consisting of dual cells built around each node of input target mesh.
-
-In 2D the dual cell is bound by edges connecting barycentres of cells
-sharing the input node with middles of cell edges ending at the input node.
-
-In 3D the dual polyhedron is bound by triangle faces. Each triangle is built
-on three following points:
-- barycentre of a cell sharing the input node;
-- barycentre of a face bounding the cell and sharing the input node;
-- middle of an edge bounding the face and ending at the input node.
-
-\section DualMESHUsage DualMESH usage
-
-An exemple of DualMESH usage to perform P0->P1 interpolation with INTERP_KERNEL::Remapper :
-
-\code
-...
-std::string sourceFileName("source.med");
-MEDMEM::MESH med_source_mesh(MED_DRIVER,sourceFileName,"Source_Mesh");
-std::string targetFileName("target.med");
-MEDMEM::MESH med_target_mesh(MED_DRIVER,targetFileName,"Target_Mesh");
-FIELD<double> sourceField(MED_DRIVER,sourceFileName,"Density",0,0);
-FIELD<double> targetField;
-Remapper mapper;
-mapper.prepare(med_source_mesh, DualMESH(med_target_mesh), "P0P1"); //<--- DualMESH
-mapper.transfer(sourceField,targetField);
-//use targetField
-...
-\endcode
-
-*/
+++ /dev/null
-/*!
-\page extractor Extractor
-
-MEDMEM::Extractor is a tool taking an input field and making a field
-of lower dimension by cutting the given field by a plane or a
-line. The following extractions are possible:
-- 3D -> 2D (3D mesh cut by plane)
-- 3D -> 1D (3D mesh cut by line)
-- 2D -> 1D (2D mesh cut by line in 2D space or by plane in 3D space)
-
-The input field is supposed to comply with following conditions
-- it is constant by element (i.e. has 1 gauss point),
-- it's support mesh does not contain poly elements,
-- volumic elements have planar faces,
-- surfasic elements have linear edges.
-
-The result field is a field constant by element on triangles,
-quadrangles, polygons or edges. It holds ownership of its
-support, which in its turn holds ownership of its mesh.
-
-\section ExtractorAlgo1 Algorithm to cut mesh in 3D space by plane and in 2D by line
-
--# Calculate a normal normalized vector to the plane in 3D space
-or the line in 2D space.
--# For each node of input mesh calculate its distance to the
-plane/line as scalar product of the normal vector and a vector
-node -> coords (coords is the arg of extractPlane() and
-extractLine()). The distance has a sign.
--# Store the distances of all nodes in a vector<double>.
--# Analyse edges of each cell. If extremities of an edge have
-different sign, we consider the edge to be cut by plane/line. If at
-least one cut edge of the cell has intersection point not closer than
-a certain precision from edge extremities, we consider the cell to be
-cut and we make a new cell in the new mesh. Also we consider a cell to
-be cut if 3D cell has three intersections at nodes and 2D cell has two
-intersections at nodes.
--# Calculate an intersection points using ratio of node
-distances. If the intersection point is too close to the edge
-extremity, we take coordinates of a corresponding node.
--# Make new nodes of intersection points and set them in proper
-order to make an element. For 2D elements we sort nodes by angle with the
-first edge of the new element.
-
-\section ExtractorAlgo2 Algorithm to cut 3D mesh by the line
--# Use descending connectivity to find outer faces. Outer face is
-bound to only one cell.
--# Find any outer face intersecting with the line.
--# Use the reverse descending connectivity or the reverse nodal
-connectivity to get cells to try next intersection.
--# Find another intersected face among faces of the got cells and so on.
--# Try to find the next outer face intersecting with the line. This is
-for the case if the input mesh has several domains. To avoid
-unnecessary outer face-line intersection searches, we classify outer
-faces along the line. So we won't try to intersect outer faces that
-are between the first and the last intersected outer faces we have
-already found.
-
-*/
+++ /dev/null
-
-/*!
-\page field FIELD
-
-\section FIELD_introduction Introduction
-
-MEDMEM fields are used to represent variables over a particular
-set of elements of the mesh. The region on which the variable is defined
-is determined through a support object (which can be
-retrieved by \a getSupport()
-method). Each field has a number of components, that could
- for instance be the different
-coordinates of a vector. All these components have a name, a
-description and a unit. Elements can also contain several
-Gauss points, in which case, values are defined on each
-Gauss point of the element.
-
-The fields can contain integer values or floating point values.
-In C++, this is reflected by the fact that FIELD is a class template
-that can be either a \c FIELD<int> or \c FIELD<double>. In Python,
-two classes \c FIELDINT and \c FIELDDOUBLE exist.
-In the present section, the methods of the FIELD template
-will be described as methods of a class \c FIELD_ (from
-which the template classes actually inherit). The template
-parameter is \c T.
-
-In MEDMEM, a field is characterized by its name (\c getName) and an optional description (\c getDescription).
-
-It is also characterized by its computation time :
-
-- an iteration number (time step number)
-- an order number (used if there are internal iterations inside a time step)
-- the time that corresponds to this iteration number.
-
-By default, there are no iteration and order number defined (value
-MED_NOPDT and MED_NONOR).
-
-\section field_interlacing Interlacing modes
-As for the coordinates in the mesh definition, there are two ways to store
-fields : one consists in interlacing the different components,
- grouping the data elementwise (MED_FULL_INTERLACE mode), the other one consists in grouping the data componentwise (MED_NO_INTERLACE).
-
-The situation is further complicated by the introduction of Gauss points.
-If the field is defined on several Gauss points, the MEDMEM convention
-is that the Gauss points are always grouped together. Let us denote
-\f$V_{ijk}\f$ the value of the field on the \f$i\f$-th element, for the \f$j\f$-th component
-on its \f$k\f$-th Gauss point. In {\c MED_FULL_INTERLACE,
-elements are nested in a \f$ijk\f$ order, while in \c MED_NO_INTERLACE
-elements are nested in \f$jik\f$ order. \\
-
-For instance, \c MED_FULL_INTERLACE will result in the following ordering (for four Gauss points and two components):
-\f$V_{111} V_{112} V_{113} V_{114} V_{121} V_{122} V_{123} V_{124} V_{211} V_{212} ... \f$
-
-\c MED_NO_INTERLACE will result in the following ordering :
-\f$ V_{111} V_{112} V_{113} V_{114} V_{211} V_{212} V_{213} V_{214} V_{311} V_{312} ... V_{121} V_{122} V_{123} \f$
-
-In this document, only the methods enabling the retrieval of
-values on fields defined on several Gauss points are presented.
-For further information on defining the location of the Gauss points
-in a reference element,
-the reader should consult MED file Web Page : https://hammi.extra.cea.fr/static/MED/web_med/
-
-\section field_outline Outline
-
-The following sections describe the FIELD methods :
-- This section describes how to create a FIELD lying on a support and
-fill it : \ref FIELD_getset
-- This section describes I/O methods :\ref FIELD_io
-- This section details methods for setting and accessing the values: \ref FIELD_value
-- This section details arithmetic operations performed on fields :
-\ref FIELD_algo,
-- This section treats the specific case of fields with several Gauss
-points : \ref FIELD_gauss.
-
-\subsection field_io_example Example for I/O routines
-This program gives an example of creation
-of a file containing a mesh and fields. This program
-is a tool that reads a mesh in an input file, creates a field
-with the inverse of the cell volume, and creates an output file
-with the mesh and the field.
-
- The reader should note that the mesh name
- passed as an argument to the
-\c addDriver() method has to be coherent with the
-mesh name (as obtained by \c getName() ).
-\verbinclude FIELDwrite.cxx
-
-
-\subsection FIELD_example Example
-The following example reviews most of the notions seen
-in this section.
-\verbinclude FIELDgeneral.cxx
-
-
-*/
-
+++ /dev/null
-/*!
-\page grid GRID
-\section GRIDgeneral General Information
-
-The GRID class represents structured meshes in the MEDMEM library.
-The GRID class inherits mesh common information from GMESH class,
-in particular, reading and writing from files (c.f. \ref MESH_io), general information
-access (c.f. \ref MESH_general),
-access to families and other supports (c.f. \ref MESH_families). However, because of the particular nature of structured meshes,
-there exist methods to access information related to the axes of the grid.
-
-The numbering of the cells and nodes in a grid starts at one and
-the inner loop is that of the first axis, the outer loop being the one
-of the last axis (c.f. figure \ref fig_grid_connectivity} ).
-
-\image html grid_example.png "Example for structured mesh connectivity. The numbering is automatically defined from the two input verctors X and Y."
-
-\section grid_outline Outline
-
-Constructors are defined in \ref GRID_constructors, methods related to
-axes are defined in \ref GRID_axes, while connectivity methods are
-given in \ref GRID_connectivity. A structured mesh can be obtained from
-a GRID using MEDMEM::GRID::convertInMESH() method.
-*/
-# \code void releaseTempArrays() \endcode
- Formats of arrays
- the array returned by \c getCoordinatesPtr must be a \b full \b interlace array.
- - the arrays returned by \c getConnectivityPtr and \c getConnectivityIndexPtr must be with the same principle as it is in \ref medmemConnArrays "medmem". Of course the numbering format may change according to \a My_numPol policy.
+ - the arrays returned by \c getConnectivityPtr and \c getConnectivityIndexPtr must be with the same principle as it is \ref MEDCouplingUMeshNodalConnectivity "MEDCouplingUMesh does". Of course the numbering format may change according to \a My_numPol policy.
Note that the array format for connectivity is kept close to MED. It is
close to VTK format too but slightly different. So it may require for the VTK side a copy
-/*!\mainpage MEDMEM user's guide
+/*!\mainpage SALOME MED user's guide
\section intro Introduction
This document is the user guide of the %MED SALOME module. The MED
- \ref medcoupling that describes DataStructures used for cross process exchange of meshes and fields.
- \ref medloader that provides I/O functions to the MED file format
-- \ref interptools (INTERP_KERNEL + REMAPPER) that provides
+- \ref interptools (INTERP_KERNEL + ParaMEDMEM::MEDCouplingRemapper) that provides
mathematical structures and algorithms for interpolation and
localization.
-You should be warned that the MEDMEM library still exists in the MED
-module but is considered as deprecated:
-
-- \ref medmem covers the %MEDMEM core library, i.e. the implementation
- of meshes, supports and fields and the associated drivers (for
- MED-file, VTK, GIBI).
-
\section S2 A graphical interface for standard use cases
The MED module in SALOME comes with a graphical interface that helps
\section S3 A set of tools for file manipulation
-- Chapter \ref tools describes various tools based on MEDMEM that can
+- Chapter \ref tools describes various tools based on MEDLoader that can
be helpful for handling MED files (conversion tools and splitting tools).
\section install Installation
The install procedure of the %MED SALOME module can handle a variety of configurations
to suit the needs of its user. Instructions for configuring and
-installing the module an be found in \ref medmem_install.
+installing the module an be found in \ref paramedmem_install.
+
+*/
+/*!
+\page paramedmem_install Configuring and Installing MED from sources
+
+The libraries in SALOME MED can be configured in several manners so that it can run inside or outside the Salome platform.
+Also, partitioning and parallel functionalities are optional.
+
+The sources of the library are located in the \a MED_SRC directory.
+The first step consists in preparing the configuration of the library :
+\verbatim
+cd ${MED_SRC}
+./build_configure
+\endverbatim
+
+This will create SALOME MED libraries with link to the SALOME Kernel.
+Sometimes, if it is desirable to have a standalone version of the library to be used independently from SALOME, use :
+\verbatim
+cd ${MED_SRC}
+./build_configure --without-kernel
+\endverbatim
+
+The library can then be configured :
+\verbatim
+mkdir ../MED_BUILD
+cd ../MED_BUILD
+../MED_SRC/configure --prefix=`pwd`/../MED_INSTALL
+\endverbatim
+
+This will configure the library without splitting functionalities. ParaMEDMEM will be compiled if an MPI version has been found.
+
+The following options can be useful to configure SALOME MED :
+- \a --enable-splitter=yes will trigger the compilation of the MEDSPLITTER tool,
+- \a --with-metis=${METISDIR} will specify a location for the METIS library,
+- \a --with-scotch=${SCOTCHDIR} will specify a location for the SCOTCH library,
+- \a --with-med3=${MED3DIR} specifies a location for MED-file library,
+- \a --with-hdf5=${HDF5DIR} specifies a location for the HDF5 library (must be the same as that used for the MED-file library)
+- \a --with-lam=${LAMDIR} specifies an install path for a LAM MPI library,
+- \a --with-mpich=${MPICHDIR} specifies an install path for a MPICH-1 library.
*/
- integrate HPC constraints (compact structures, limitation of copies and launching of CPU consuming algorithms only when absolutely needed ).
- compliant with ICOCO API
-The \ref medcoupling "MEDCoupling" data structure is \b fully \b independant from those implemented in MEDMEM.
-
\ref medcoupling "MEDCoupling" implements a set of algorithms linked to the data structure.
\section MEDCouplingMainConc Main Concepts
As a mesh has one dimension and only once, that is to say every cells in
mesh have the same dimension called MeshDimension.
-That is to say the
-MEDMEM vocabulary of faces and edges \b do \b not \b exist \b anymore here in
-MEDCoupling.
-
For exemple a mesh with a meshDimension equal to 1, have \b cells of type
NORM_SEG2. An another exemple, a mesh with a meshDimension equal
to 2, have \b cells of type
+++ /dev/null
-
-/*!
-\page MEDFILEBROWSER_class MEDFILEBROWSER
-
-\section MED_general General Information
-
-This object is used to get information about the different
-meshes/fields that are contained in a file.
-This enables the user to know about the file content without
-loading med objects in memory.
-
-\section MEDFILEBROWSER_object_outline Outline
-The methods are described in the following sections :
-- \ref MEDFILEBROWSER_constructors
-- \ref MEDFILEBROWSER_query
-
-For an example using these methods, one may see the Python scripts in the
-directory \c $MED_ROOT_DIR/bin/salome/,\c med_test1.py, or C++
-example program in the directory \c $MED_SRC_DIR/src/MEDMEMBinTest,
-\c duplicateMED.cxx.
-
-*/
\section MEDLoaderWriteMain Writing a MED file with MEDLoader
-As MEDMEM and MED file do, MEDLoader write process separates clearly
+As MED file does, MEDLoader write process separates clearly
meshes from fields. The reason is that a common use case in write mode
is to write in a first time a mesh and then writes several time steps
of a same field in appended mode.
The fact that the write process is rarely in a one shot put a
-constraint on API (as MEDMEM does) to precise to MEDLoader if you intend
+constraint on API to precise to MEDLoader if you intend
to append data to an existing file, or if you want to create a new
file from scratch. This explains the presence of boolean parameter \b
writeFromScratch in API of MEDLoader starting with \b
Two classes of MEDLoader write methods exists when \b writeFromScratch
is set to \b false :
-- Methods \b MEDLoader::Write*Dep : The behaviour is as MEDMEM, that
- is to say, the write is done without any question in file. The
+- Methods \b MEDLoader::Write*Dep : The write operation is performed without any question in file. The
responsability is let to the user because the MED file could be
corrupted. The advantage of this method is that it is faster
because no check is done.
+++ /dev/null
-/*!
-\page medmem MEDMEM library
-
-\section medmem_introduction Introduction
-\subsection medmem_rationale 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 (\c %MEDMEM) library.
-
-The Med libraries are oganized in multiple layers:
-- The MED file layer : C and Fortran API to implement mesh and field persistency.
-- The MED Memory level C++ API to create and manipulate mesh and field objects in memory.
-- Python API generated using SWIG which wraps the complete C++ API of the MED Memory
-- CORBA API to simplify distributed computation inside SALOME (Server Side).
-- MED Client classes to simplify and optimize interaction of distant objects within the local solver.
-
-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).
-
-\subsection medmem_outline 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 \ref medmem_api, the API consists of very few classes:
-
-- a MED-file browser : \ref MEDFILEBROWSER_class,
-- meshes : \ref mesh ,
-- structured meshes : \ref grid ,
-- supports and derived classes : \ref support ,
-- mesh generation tool : \ref meshing ,
-- fields : \ref field ,
-- \ref medmem_drivers "drivers for reading and writing" in MED, GIBI,
-VTK, EnSight and Porflow files.
-
-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 \ref medmem_sec_python.
-
-\subsection medmem_naming 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).
-
-- \b cell entity of dimension equal to the mesh dimension (1, 2 or 3).
-- \b component in a field, represents a value that is available for each element of the support (for instance : \f$ T \f$, \f$ v_x \f$, \f$ \sigma_{xy} \f$)).
-- \b connectivity \b (descending) connectivity table expressing connectivity of dimension \a d elements in terms of list of dimension \a d-1 elements.
-- \b connectivity \b (nodal) connectivity table expressing connectivity of dimension \a d elements in terms of list of nodes.
-- \b constituent \b entity entity having a dimension smaller than that of the mesh.
-- \b coordinates in a mesh, coordinates can be described by strings giving the names of the coordinates, the units of the coordinates, and the type of coordinates ('MED_CART', 'MED_SPHER' or 'MED_CYL').
-- \b description string of characters used to describ an object without giving any access to a query method.
-- \b dimension Med Memory discriminates the mesh dimension from the space dimension (a surface shape in 3D will have 2 as a mesh dimension).
-- \b driver object attached to a mesh or a field to read (resp. write) data from (resp. to) a Med-file.
-- \b edge entity of dimension 1 in a 2D mesh.
-- \b element elementary component of a mesh (0D, 1D, 2D or 3D).
-- \b entity category giving information on the dimension of elementary components of meshes : node, edge, face (only in 3D) or cell.
-- \b face for 3D meshes, faces are the 2D entities.
-- \b family support which is composed of a set of groups, which do not intersect each other, and which gives access to those groups.
-- \b field array of integer, integer array, real or real array lying on a support (the dimension of the array of values for each element of the support is called the number of components). A field is uniquely defined by its name, its support, its iteration number and its order number. -1 is the default value of those two numbers.
-- \b group support with additional access to parent families.
-- \b iteration number] information attached to a field that expresses the number of the time step in the computation (-1 is its default value).
-- \b name information attached to a mesh, support or field to name it and access to it.
-- \b node entity of dimension 0.
-- \b order \b number information attached to a field that expresses the number of an internal iteration inside a time step in the computation (-1 is its default value).
-- \b support list of elements of the same entity.
-- \b type category of an entity (triangle, segment, quadrangle, tetrahedron, hexahedron, etc...).
-
-
-\subsection medmem_diff 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 \c MED_FACE
-or \c MED_EDGE, whereas in %MED File, they should be stored as \c
- 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 \a t=0.0 s, \a t=1.0 s, \a 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.
-
-\subsection medmem_drivers Drivers for reading and writing
-
-MEDMEM supports data exchange in following formats:
-- \b GIBI - reading and writing the mesh and the fields in ASCII format.
-- \b VTK - writing the mesh and the fields in ASCII and binary formats.
-- \b EnSight - reading and writing the mesh and the fields in EnSigth6 and EnSigth GOLD formats (ASCII and binary).
-- \b PORFLOW - reading the mesh in ASCII format.
-
-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.
-
-\section medmem_api Med Memory API
-
-\subsection medmem_conventions Conventions
-
-- In this document, one refers to the main user documentation
-\ref RefManualMedMemory where the variable \c $MED_ROOT_DIR (resp.
-\c $MED_SRC_DIR) is the Med Memory directory installation (resp. sources
-directory).
-- All numberings start at one (take care of array index !).
-- When one gets a C (resp. C++) type array (resp. STL container) using a \c {get...} method, one should not modify the array. Access is in read only. To modify a such array (resp. STL container) use a \c {set...} method.
-- There are many couple of methods that have similar syntaxes (one singular and one
-plural). The plural method returns an array and the singular one returns one
-particular value in this array (see \c double \c getCoordinate(int i) and
-\c double* \c getCoordinates() for example). Generally, only the plural version
-of the methods are documented in this report.
-- Difference between local and global number in mesh element connectivity list : when one talks about an
-element number, one could see \f$ i^{th} \f$ quadrangle (\f$ i^{th} \f$ in quadrangles array : local numbering) or \f$ j^{th} \f$ element (\f$ j^{th} \f$ in all elements array :
-global numbering). These two numberings are equivalent only if one has only one
-geometric type.
-
-
-\subsection namespaces Namespaces
-
-Med Memory uses two namespaces : \c MEDMEM which is the general
-namespace where the main classes are defined and \c MED_EN
-which defines enums that can be used by an English-speaking
-programer.
-
-\subsection classes Classes
-At a basic usage level, the API consists in few classes which are located in
-the \c MEDMEM C++ namespace (consult figure \ref fig_UML_light which gives
-an UML diagram view of the main Med Memory classes):
-
-- \b MEDFILEBROWSER the class provinding information on meshes and fields conatained in a MED file;
-- \b MESH the class containing 2D or 3D mesh objects;
-- \b SUPPORT the class containing mainly a list of mesh elements;
-- \b FIELD the class template containing list of values lying on a particular support.
-
-\anchor fig_UML_light
-\image html UML_light.png " UML diagram of basic Med Memory API classes"
-\image latex UML_light.eps " 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:
-
-- read/write meshes and fields from MED-files;
-- create fields containing scalar or vectorial values on list of elements
-of the mesh;
-- communicate these fields between different components;
-- read/write such fields.
-
-Note that on the figure \ref fig_UML_light as well as on figure
-\ref 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 \ref fig_UML gives a complete view of the Med Memory API. It includes :
-
-- \b GROUP a class inherited from the SUPPORT class used to create supports linked to mesh groups. It stores restricted list of elements used to set boundary conditions, initial values.
-- \b FAMILY which is used to manipulate a certain kind of support which does not intersect each other.
-- \b MESHING which builds meshes from scratch, it can be used to transform meshes from a specific format to the MED format or to integrate a mesher within Salome platform (note that class does not add element or node to a mesh).
-- \b GRID which enables the user to manipulate specific functions for structured grid.
-
-\anchor fig_UML
-\image html UML_small.png "UML diagram of Med Memory API classes"
-\image latex UML_small.eps "UML diagram of Med Memory API classes"
-
-
-\subsection medmem_enums Enums
-A few enums are defined in the \c MED_EN namespace :
-
-- an enum which describes the way node coordinates or field values are stored,
- - \c MED_FULL_INTERLACE for arrays such that \f$ x_1,y_1,z_1,x_2,y_2,z_2,\ldots,x_n,y_n,z_n \f$;
- - \c MED_NO_INTERLACE for arrays such that \f$ x_1,x_2,\ldots,x_n,y_1,y_2,\ldots,y_n,z_1,z_2,\ldots,z_n \f$;
- - \c MED_UNDEFINED_INTERLACE, the undefined interlacing mode.
- .
-- an enum which describes the type of connectivity
- - \c MED_NODAL for nodal connectivity;
- - \c MED_DESCENDING for descending connectivity.
- .
-
-The user has to be aware of the fact that the Med Memory considers only meshes defined by their nodal connectivity. Nevertheless, the user may, after loading a file in memory, ask to the mesh object to calculate the descending connectivity.
-
-- an enum which contains the different mesh entities, \c medEntityMesh, the entries of which being :
- - \c MED_CELL
- - \c MED_FACE
- - \c MED_EDGE
- - \c MED_NODE
- - \c MED_ALL_ENTITIES
- .
-
-In 3D (resp. 2D), the user has to be aware of the fact that only mesh
-entities \c MED_CELL and \c MED_FACE (resp. \c MED_EDGE) are
-considered. In 1D, of course only mesh entities \c MED_CELL+ are considered. Using our naming convention (consult \ref medmem_naming), in $1$ D mesh
-only \b node and \b cell are considered. In 2D mesh, only \b node,
-\b cell and \b edge are considered. Finally in 3D mesh only
-\b node, \b cell and \b face are considered.
-
-- The \c medGeometryElement enum which defines geometric types. The
-available types are linear and quadratic elements (consult
-\ref RefManualMedMemory). The entries of this enum are quite
-self-explanatory :
- - \c MED_NONE
- - \c MED_POINT1
- - \c MED_SEG2
- - \c MED_SEG3
- - \c MED_TRIA3
- - \c MED_QUAD4
- - \c MED_TRIA6
- - \c MED_QUAD8
- - \c MED_TETRA4
- - \c MED_PYRA5
- - \c MED_PENTA6
- - \c MED_HEXA8
- - \c MED_TETRA10
- - \c MED_PYRA13
- - \c MED_PENTA15
- - \c MED_HEXA20
- - \c MED_POLYGON
- - \c MED_POLYHEDRA
- - \c MED_ALL_ELEMENTS
- .
-The connectivity of all these elements is defined in MED project Web page
-http://hammi.extra.cea.fr/static/MED/web_med/logiciels/med-2.3.1/doc/ .
-
-
-*/
-
-/*!
-\page paramedmem ParaMEDMEM library
-
-
-The ParaMEDMEM library is based on several classes that
-describe the coupling between two MPI-based parallel codes.
-
-The classes that make up the API of the library are :
-- communication interface : \ref comm_interface,
-- definition of processor groups : \ref processor_group,
-- Data Exchange Channel \ref dec, and its implementations :
- - \ref interpkerneldec for a \ref InterpKerRemapGlobal based on intersecting elements volume computation,
- - \ref overlapdec based on intersecting elems volume
- computation when source and target meshes are on same process id
-
-Given two groups of processors groupA (source) and groupB (target), the following code excerpt gives a typical use of the InterpKernelDEC class.
-
- \code
- ...
- InterpKernelDEC dec(groupA, groupB);//creates the data exchange channel
- dec.attachLocalField(field);//associate the local field
- dec.synchronize();//builds the interpolation matrix
- if (groupA.containsMyRank())
- dec.recvData();//receive the target field
- else if (groupB.containsMyRank())
- dec.sendData();//send the source field
- ...
- \endcode
-The generation of the \ref interpolationmatrix "interpolation matrix" and the corresponding matrix-vector products are performed either on the source, either on the target side.
-
-*/
-
-
-/*!
-\page medmem_install Configuring and Installing MEDMEM from sources
-
-The MEDMEM library can be configured in several manners so that it can run inside or outside the Salome platform. Also, partitioning and parallel functionalities are optional.
-
-The sources of the library are located in the \a MED_SRC directory.
-The first step consists in preparing the configuration of the library :
-\verbatim
-cd ${MED_SRC}
-./build_configure
-\endverbatim
-
-This will create a MEDMEM library with link to the SALOME Kernel. If it is desirable to have a standalone version of the library to be used independently from SALOME, use :
-\verbatim
-cd ${MED_SRC}
-./build_configure --without-kernel
-\endverbatim
-
-The library can then be configured :
-\verbatim
-mkdir ../MED_BUILD
-cd ../MED_BUILD
-../MED_SRC/configure --prefix=`pwd`/../MED_INSTALL
-\endverbatim
-
-This will configure the library without splitting functionalities. ParaMEDMEM will be compiled if an MPI version has been found.
-
-The following options can be useful to configure MEDMEM :
-- \a --enable-splitter=yes will trigger the compilation of the MEDSPLITTER tool,
-- \a --with-metis=${METISDIR} will specify a location for the METIS library,
-- \a --with-scotch=${SCOTCHDIR} will specify a location for the SCOTCH library,
-- \a --with-med3=${MED3DIR} specifies a location for MED-file library,
-- \a --with-hdf5=${HDF5DIR} specifies a location for the HDF5 library (must be the same as that used for the MED-file library)
-- \a --with-lam=${LAMDIR} specifies an install path for a LAM MPI library,
-- \a --with-mpich=${MPICHDIR} specifies an install path for a MPICH-1 library.
-*/
--- /dev/null
+/*!
+\page medpartitioner MEDPartitioner tool
+
+The purpose of MEDPartitioner is to split MED files into
+a series of other MED files forming a partition of the original MED
+files. It can either work with serial meshes (1 to n) or distributed
+meshes (p to n). For serial meshes, it accepts MED files from the 2.2
+version onwards. For distributed MED files, it accepts MED files from
+the 2.3 version onwards.
+
+It can be used either as an executable, \a medpartitioner or as a library. The partitioning is made thanks to one of the following library :
+- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html)
+- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_fr.html)
+
+The arguments to the medpartitioner tool can be retrieved by calling :
+\code
+medpartitioner --help
+\endcode
+
+There exists a parallel version of MEDPartitioner, which accepts
+distributed MED files only. In contrast to the ordinary MEDPartitioner
+the parallel one distributes several usual MED files composing the
+whole model among available processors. It uses parallel versions of
+the partitioning libraries: ParaMETIS and PT-SCOTCH. After the
+partitioning each processor writes only it's own part of the
+distributed MED file. The parallel MEDPartitioner processes meshes only,
+not fields.
+
+It can be used either as an executable, \a medpartitioner_para or as a library.
+
+The arguments to the medpartitioner_para tool can be retrieved by calling :
+\code
+medpartitioner_para --help
+\endcode
+
+
+*/
\ No newline at end of file
+++ /dev/null
-/*!
-\page medsplitter MEDSPLITTER tool
-
-The purpose of MEDSPLITTER is to split MED files into
-a series of other MED files forming a partition of the original MED
-files. It can either work with serial meshes (1 to n) or distributed
-meshes (p to n). For serial meshes, it accepts MED files from the 2.1
-version onwards. For distributed MED files, it accepts MED files from
-the 2.3 version onwards.
-
-It can be used either as an executable, \a medsplitter or as a library. The partitioning is made thanks to one of the following library :
-- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html)
-- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_fr.html)
-
-The arguments to the medsplitter tool can be retrieved by calling :
-\code
-medsplitter --help
-\endcode
-
-There exists a parallel version of MEDSPLITTER, which accepts
-distributed MED files only. In contrast to the ordinary MEDSPLITTER
-the parallel one distributes several usual MED files composing the
-whole model among available processors. It uses parallel versions of
-the partitioning libraries: ParaMETIS and PT-SCOTCH. After the
-partitioning each processor writes only it's own part of the
-distributed MED file. The parallel MEDSPLITTER processes meshes only,
-not fields.
-
-It can be used either as an executable, \a medsplitter_para or as a library.
-
-The arguments to the medsplitter_para tool can be retrieved by calling :
-\code
-medsplitter_para --help
-\endcode
-
-
-*/
\ No newline at end of file
+++ /dev/null
-/*!
-\page mesh MESH
-
-\section mesh_general General information
-
-The MESH class is dedicated to the handling of unstructured
-meshes. Class MESHING deriving from it supplies functions for creating meshes from scratch (c.f. \ref meshing).
-
-\section mesh_connectivity Content of the connectivity array
-Underlying the unstructured meshes is the notion of connectivity. This section only covers meshes made out of standard elements, the \c MED_POLYGON and \c MED_POLYHEDRA case being detailed in section \ref polygon .
-
-\anchor medmemConnArrays
-\image html connectivity_arrays_small.png "Nodal connectivity storage scheme"
-\image latex connectivity_arrays_small.eps "Nodal connectivity storage scheme"
-
-In MEDMEM, an unstructured mesh nodal connectivity is defined with these arrays:
-- the type array, which contains the number of cells for each present type;
-- the nodal connectivity array containing the connectivity of each cell, all cells being sorted by type;
-- the connectivity index array, which indicates the beginning of each cell in the connectivity array.
-
-The cell types are ordered by their number of nodes; MED_POLYGON and
-MED_POLYHEDRA is always the last type, if present.
-
-As an example, let us consider a mesh made out of a linear triangle, two linear quadrangles and a quadratic triangle (c.f. figure \ref fig_connectivity_example ).
-\image html connectivity_example_small.png "Example for mesh connectivity"
-\image latex connectivity_example_small.eps "Example for mesh connectivity"
-The number of types is : 3
-
-The type array writes :
-\{ \a MED_TRIA3, \a MED_QUAD4, \a MED_TRIA6 \}
-
-The global numbering index is : \{ 1,2,4,5 \} }. Its dimension is \f$ n_{types}+1 \f$
-so that elements of type \f$ type[i] \f$ are stored between element \f$ index[i] \f$ and
-\f$ index[i+1] \f$ ( \f$ index[i] \leq j < index[i+1] \f$).
-
-The connectivity array writes :
-\{ 1, 2, 3, 2, 4, 5, 3, 5, 6, 7, 8, 4, 6, 5, 10, 11, 9\}
-
-The connectivity index array writes :
-\{ 1, 4, 8, 12, 18\}
-
-Its dimension is \f$n_{cell}+1\f$, in order to be able to write
-that nodes of element \f$i\f$ are located in the connectivity array between
-\f$index[i]\f$ and \f$index[i+1]\f$ ( \f$index[i] \leq j < index[i+1]\f$).\\
-
-
-\warning
-As MEDMEM respects MED numbering which starts Fortran-style at 1, reading these information to set C structures requires careful handling of index offsets.
-
-
-\section mesh_outline Outline
-
-The description of MESH methods is given by the following sections :
-
-- Description of constructors is given in \ref MESH_constructors.
-- Methods retrieveing general information is given in \ref MESH_general.
-- Retrieval of information about mesh nodes can be found in \ref MESH_nodes.
-- Connectivity information methods are described in \ref MESH_connectivity.
-- The methods retrieving family information are given in \ref MESH_families.
-- The IO methods are given in \ref MESH_io.
-- The methods for an advanced usage (applying algorithms to meshes)
-are given in \ref MESH_advanced.
-
-*/
+++ /dev/null
-/*!
-
-\page meshing MESHING
-
-\section meshing_overview Overview
-
-This class is a class derived from MESH class that is used
-to build a MESH object from scratch.
-
-All verifications are under user responsability : if array values or array
-dimensions are wrong, results are impredictable.
-All the arrays passed as arguments in the set methods are duplicated in MESHING object.
-
-The creation of a mesh should respect the following sequence :
-- setting general information (name, description, coordinate system, ...),
-- setting the nodes (number and coordinates),
-- setting the connectivity (types, connectivity arrays,...),
-- group creations.
-
-The following paragraphs describe the methods that must be called
-when creating a mesh. An example illustrates the general procedure.
-The specific case of \c MED_POLYGON and \c MED_POLYHEDRA
-elements requires some methods that are described in \ref polygon.
-
-\section outline_meshing Outline
-
-The following sections point to various groups of MESHING methods :
-- Constructors : \ref MESHING_constructors,
-- General information : \ref MESHING_general,
-- Setting nodes : \ref MESHING_nodes,
-- Connectivity : \ref MESHING_connectivity,
-- Groups : \ref MESHING_group.
-
-An example of mesh creation via MESHING is given in :
-- C++ :
-\include MESHINGexample.cxx
-- Python:
-\include MESHINGexample.py
-
-*/
+++ /dev/null
-/*!\page polygon Polyhedra and polygons
-
-\section polygon_general General information
-
-The methods described in section \ref mesh do not take into account information about
- \c polygonal and \c polyhedral cells contained in a MESH object.
-Indeed, in the MEDMEM library, the connectivity data for these
-elements are stored the same way as connectivity of standard
-elements. Therefore, the methods that give access to this data are
-same as those of section \ref mesh.
-
-The polygon and the polyhedra case differ in nature,
-because in 3D, the list of nodes is not sufficient
-to described the shape of an element. A descending
-cell>face>nodes connectivity has to be established
-to fully describe the elements.
-
-\section polygon_connectivity Polygon connectivity
-
-Let us consider the case illustrated in figure \ref fig_polygon_connectivity .
-
-\anchor fig_polygon_connectivity
-\image html polygon_connectivity_small.png "Example for polygon connectivity"
-\image latex polygon_connectivity_small.eps "Example for polygon connectivity"
-
-
-- The connectivity table writes : {2, 6, 7, 3, 3, 7, 8, 4, 1, 2, 3, 4, 5 }
-- The connectivity index table writes : {1, 5, 9, 14 }
-
-\section polyhedron_conn Polyhedron connectivity
-
-For polyhedra, in the nodal connectivity case,
-list of nodes does not suffice to describe a general polyhedron;
-information of connectivity of each face is needed.
-A general polyhedron is therefore described by a list of nodes of
-all faces with -1 as separator between faces.
-
-Let us consider an example with the two tetrahedra represented on
-figure \ref fig_polyhedron_connectivity , the left one
-being stored as a \c MED_TETRA4 element, the right one being stored
-as a \c MED_POLYHEDRA element.
-
-\anchor fig_polyhedron_connectivity
-\image html polyhedron_connectivity_small.png "Example for polyhedron connectivity. Node numbers are written with a normal font, while face numbers are written in italic font."
-\image latex polyhedron_connectivity_small.eps "Example for polyhedron connectivity. Node numbers are written with a normal font, while face numbers are written in italic font."
-
-- The connectivity table writes : {1, 2, 3, 4, 2, 5, 3, -1, 2, 4, 5, -1, 4, 3, 5, -1, 2, 3, 4}
-- The index connectivity table writes : {1, 5, 20 }
-
-If there are two \c MED_POLYHEDRA elements that share a common face,
-the list of nodes is repeated twice in the polyhedron connectivity
-array but with reversed order.
-
-\section poly_example Example
-The following example illustrates the creation method for a mesh that
-contains polygons and/or polyhedra :
-\include test_MEDMEM_MeshingPoly.cxx
-*/
med_target_mesh->decrRef();
\endcode
-(Note that the same API can be used with \ref medmem field instead of \ref medcoupling fields using another remapper class \ref medmemremapper.)
-
\section InterpKerMidLevUsage Middle-level usage
+++ /dev/null
-/*!
-\page support SUPPORT
-
-\section support_general General information
-
-The SUPPORT class is the class representing subregions
- of the mesh in the MEDMEM library. A SUPPORT object groups together
-a set of elements that have similar entity types.
-
-\section support_outline Outline
-
-The reference for the SUPPORT methods are given by the following links :
-- constructors : \ref SUPPORT_constructors,
-- creation methods : \ref SUPPORT_creation,
-- query methods : \ref SUPPORT_query,
-- advanced methods : \ref SUPPORT_advanced.
-
-\section family FAMILY objects
-
-The FAMILY concept is directly linked to the representation of
-supports in the MED file. It is only useful for directly
-manipulating the arrays that are written/read by the MED drivers.
-More information can be found on this topic in
-\ref RefManualMedFile "MED reference guide".
-
-A FAMILY is a SUPPORT with some additional methods that concern some optional attributes (we could have none) and groups (we could also have none) :
-
-- \a getIdentifier returns the family identifier (an integer),
-- \a getNumberOfAttributes returns the number of attributes of this family,
-- \a getAttributesIdentifiers and \a getAttributeIdentifier returns an integer array or an integer that represents attribute identifier,
-- \a getAttributesValues and \a getAttributeValue returns an integer array or an integer that represents attribute value.
-- \a getAttributesDescriptions and \a getAttributeDescription returns a string array or a string that represents attribute description,
-- \a getNumberOfGroups returns the number of groups which it belongs to,
-- \a getGroupsNames and \a getGroupName return a string array or a string that represents the group name which it belongs to.
-
-
-\section group_section GROUP objects
-
-A GROUP is a SUPPORT with some additional methods to find FAMILY that makes it up :
-
-- \a getNumberOfFamilies returns the number of FAMILY that makes up the GROUP ;
-- \a getFamilies and \a getFamily return a FAMILY array or a FAMILY that makes up the GROUP.
-
-*/
/*!
-\page tools MEDMEM tools
+\page tools Tools on MED file
\section Introduction
-On top of the MEDMEM library, MEDMEM comes with a few executables that
-are based on the MEDMEM library and that help the user to perform
+
+There are few executables based on the MEDCoupling and MEDLoader libraries that
+ help the user to perform
common operations on MED files :
- conversion to other formats,
- splitting of a %MED file to a parallel %MED file distributed over a
number of subdomains.
-\section medsplitter MEDSPLITTERtool
+\section medpartitioner MEDPartitioner tool
-The purpose of MEDSPLITTER is to split MED files into
+The purpose of MEDPARTITIONER is to split MED files into
a series of other MED files forming a partition of the original MED
files. It can either work with serial meshes (1 to n) or distributed
meshes (p to n). For serial meshes, it accepts MED files from the 2.1
version onwards. For distributed MED files, it accepts MED files from
the 2.3 version onwards.
-There exists a parallel version of MEDSPLITTER, which accepts
-distributed MED files only. In contrast to the ordinary MEDSPLITTER
+There exists a parallel version of MEDPARTITIONER, which accepts
+distributed MED files only. In contrast to the ordinary MEDPARTITIONER
the parallel one distributes several usual MED files composing the
whole model among available processors. After the
partitioning, each processor writes only it's own part of the
-distributed MED file. The parallel MEDSPLITTER processes meshes only,
+distributed MED file. The parallel MEDPARTITIONER processes meshes only,
not fields.
-It can be used either as an executable, \a medsplitter (or \a
-medsplitter_para) or as a library. The partitioning is made thanks to
+It can be used either as an executable, \a medpartitioner (or \a
+medpartitioner_para) or as a library. The partitioning is made thanks to
one of the following library :
- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html)
- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_fr.html)
-The arguments to the medsplitter tool can be retrieved by calling :
+The arguments to the medpartitioner tool can be retrieved by calling :
\code
-medsplitter --help
+medpartitioner --help
\endcode
or
\code
-medsplitter_para --help
+medpartitioner_para --help
\endcode
-For Salome V4.1.0, one gets the following arguments (some of them are
+For Salome V7.2.0, one gets the following arguments (some of them are
unavailable in parallel version):
\code
The sauv2med tool enable conversion from a Cast3m \a sauv file into a
MED file. It is a python script that encapsulates the read/write
-drivers provided by the MEDMEM library.
+drivers provided by the MEDLoader library.
Calling
\code
