From: vbd Date: Thu, 25 Sep 2008 09:52:09 +0000 (+0000) Subject: restructuring main.dox X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=c50c04e4f952610def16b56754e0c42d8ddff2d1;p=tools%2Fmedcoupling.git restructuring main.dox --- diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index 16f065a80..a155d6a4d 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -17,6 +17,7 @@ This user guide contains three different chapters that covers the core %MEDMEM l - Chapter \ref interpkernel describes the interpolation and localization library. - Chapter \ref paramedmem describes its MPI implementation, which is called %ParaMEDMEM. -- Chapter \ref medsplitter describes the implementation of the medsplitter tool that can be used to partition %MED files over a number of subdomains. +- Chapter \ref tools describes various tools based on MEDMEM that can +be helpful for handling MED files (conversion tools and splitting tools). */ diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox new file mode 100644 index 000000000..429234d1b --- /dev/null +++ b/doc/doxygen/medmem.dox @@ -0,0 +1,268 @@ +/*! +\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 general MED container : \ref MED_class, +- meshes : \ref mesh , +- structured meshes : \ref grid , +- supports and derived classes : \ref support , +- mesh generation tool : \ref meshing , +- fields : \ref field , +- drivers for reading and writing in MED, GIBI and VTK 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. + +\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 MED the global container; +- \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 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 \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 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(aka DEC, abstract class) : \ref dec, and its implementations : + - \ref intersectiondec for a \ref InterpKerRemapGlobal based on intersecting elems volume computation, + - NonCoincident DEC for a non-conservative interpolation based on element localization : \ref noncoincidentdec, + - Explicit Coincident DEC for remapping coincident meshes on a one-to-one basis. This class applies to unstructured topologies: \ref explicit_coincident_dec, + - Structured Coincident DEC for remapping coincident meshes on a one-to-one basis. This class applies to structured topologies : \ref structuredcoincidentdec. + +*/ + +/*! +\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-med2=${MED2DIR} 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. +*/ +>>>>>>> 1.1.4.1.2.1 diff --git a/doc/doxygen/tools.dox b/doc/doxygen/tools.dox index 552deb5e5..5da0c7060 100644 --- a/doc/doxygen/tools.dox +++ b/doc/doxygen/tools.dox @@ -1,267 +1,66 @@ /*! -\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 general MED container : \ref MED_class, -- meshes : \ref mesh , -- structured meshes : \ref grid , -- supports and derived classes : \ref support , -- mesh generation tool : \ref meshing , -- fields : \ref field , -- drivers for reading and writing in MED, GIBI and VTK 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. - -\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 MED the global container; -- \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 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 \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 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(aka DEC, abstract class) : \ref dec, and its implementations : - - \ref intersectiondec for a \ref InterpKerRemapGlobal based on intersecting elems volume computation, - - NonCoincident DEC for a non-conservative interpolation based on element localization : \ref noncoincidentdec, - - Explicit Coincident DEC for remapping coincident meshes on a one-to-one basis. This class applies to unstructured topologies: \ref explicit_coincident_dec, - - Structured Coincident DEC for remapping coincident meshes on a one-to-one basis. This class applies to structured topologies : \ref structuredcoincidentdec. - -*/ - -/*! -\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-med2=${MED2DIR} 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. -*/ +\page tools MEDMEM tools + +\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 +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 + +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 + +For Salome V4.1.0, one gets the following arguments : + +\code +Available options: + --help : produces this help message + --mesh-only : do not create the fields contained in the original file(s) + --distributed : specifies that the input file is distributed + --input-file= : name of the input MED file + --output-file= : name of the resulting file + --meshname= : name of the input mesh (not used with --distributed option) + --ndomains= : number of subdomains in the output file, default is 1 + --plain-master : creates a plain masterfile instead of an XML file + --creates-boundary-faces: creates the necessary faces so that faces joints are created in the output files + --family-splitting : preserves the family names instead of focusing on the groups +\endcode + +\section sauv2med sauv2med tool + +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. + +Calling +\code +sauv2med myfile.med +\endcode +generates a \a sauv file named \a myfile.med.sauv + + +\section med2sauv med2sauv tool + +med2sauv operator is the operator that is inverse of sauv2med. Its +behaviour is symmetrical. + +Calling +\code +med2sauv myfile.sauv +\endcode +generates a \a med file named \a myfile.sauv.med + +*/ \ No newline at end of file