@srcdir@/../../src/MEDLoader \
@srcdir@/../../src/MEDMEM
-FILE_PATTERNS = MEDMEM_Mesh.* \
+FILE_PATTERNS = MEDMEM_GMesh.* \
+ MEDMEM_Mesh.* \
MEDMEM_Grid.* \
MEDMEM_Meshing.* \
MEDMEM_Support.* \
MEDMEM_Field.* \
- MEDMEM_Med.* \
+ MEDMEM_MedFileBrowser.* \
InterpKernelDEC.* \
DEC.* \
MPIProcessorGroup.* \
InterpKernelGeo2DNode.* \
InterpKernelGeo2DQuadraticPolygon.* \
ParaFIELD.* \
- MEDCouplingMesh.* \
+ MEDCouplingMesh.* \
MEDCouplingUMesh.* \
- MEDCouplingUMeshDesc.* \
- MEDCouplingPointSet.* \
- MEDCouplingCMesh.* \
- MEDCouplingExtrudedMesh.* \
- MEDCouplingFieldDouble.* \
- MEDCouplingField.* \
- MEDCouplingFieldDiscretization.* \
- MEDCouplingTimeDiscretization.* \
- MEDCouplingTimeLabel.* \
- MEDCouplingRefCountObject.* \
- MEDCouplingMemArray.* \
- MEDCouplingRemapper.* \
- MEDLoader.* \
- MEDFileMesh.* \
+ MEDCouplingUMeshDesc.* \
+ MEDCouplingPointSet.* \
+ MEDCouplingCMesh.* \
+ MEDCouplingExtrudedMesh.* \
+ MEDCouplingFieldDouble.* \
+ MEDCouplingField.* \
+ MEDCouplingFieldDiscretization.* \
+ MEDCouplingTimeDiscretization.* \
+ MEDCouplingTimeLabel.* \
+ MEDCouplingRefCountObject.* \
+ MEDCouplingMemArray.* \
+ MEDCouplingRemapper.* \
+ MEDLoader.* \
+ MEDFileMesh.* \
*.dox
RECURSIVE = NO
EXCLUDE = CVS
EXCLUDE_PATTERNS = *~
EXAMPLE_PATH = @srcdir@/../../src/ParaMEDMEM/ \
@srcdir@/../../doc/MEDMEM \
+ @srcdir@/../../src/MEDMEMBinTest \
@srcdir@/../../src/MEDMEM
EXAMPLE_PATTERNS = *.cxx *.py
EXAMPLE_RECURSIVE = NO
+++ /dev/null
-
-/*!
-\page MED_class MED object
-
-\section MED_general General Information
-
-This object is used to give information about the different
-meshes/supports/fields that are contained in a file.
-This enables the user to know about the file content without
-loading the meshes in memory. Also, it can be useful for
-memory management since meshes, supports and fields accessed through a MED
-object are destroyed when the MED object is destroyed.
-
-\section MED_object_outline
-The methods are described in the following sections :
-- constructors : \ref MED_constructors
-- query methods : \ref MED_query
-
-For an example using these methods, one may see the Python scripts in the
-directory \c $MED_ROOT_DIR/bin/salome/,\c testMedObj.py, or C++
-example program in the directory \c $MED_SRC_DIR/src/MEDMEM,
-\c duplicateMED.cxx.
-
-*/
\ No newline at end of file
\section GRIDgeneral General Information
The GRID class represents structured meshes in the MEDMEM library.
-As the GRID class inherits from MESH, all of the functionalities that were
-described in the previous section apply for structured mesh GRID objects.
-In particular, reading and writing from files, general information access
-are similar. However, because of the particular nature of structured meshes,
+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
\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.
+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.
*/
--- /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.
+
+*/
- 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
+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).
As will be seen in section \ref medmem_api, the API consists of very few classes:
-- a general MED container : \ref MED_class,
+- 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 and VTK files.
+- \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.
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 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.
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 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.
- 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.
+\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 :
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
+ - \c MEDMEM_NONE
+ - \c MEDMEM_POINT1
+ - \c MEDMEM_SEG2
+ - \c MEDMEM_SEG3
+ - \c MEDMEM_TRIA3
+ - \c MEDMEM_QUAD4
+ - \c MEDMEM_TRIA6
+ - \c MEDMEM_QUAD8
+ - \c MEDMEM_TETRA4
+ - \c MEDMEM_PYRA5
+ - \c MEDMEM_PENTA6
+ - \c MEDMEM_HEXA8
+ - \c MEDMEM_TETRA10
+ - \c MEDMEM_PYRA13
+ - \c MEDMEM_PENTA15
+ - \c MEDMEM_HEXA20
+ - \c MEDMEM_POLYGON
+ - \c MEDMEM_POLYHEDRA
+ - \c MEDMEM_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/ .
- \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
\section mesh_general General information
-The MESH class is dedicated to the handling of unstructured meshes. Two classes derive from it : MESHING supplies functions for creating meshes from scratch (c.f. \ref meshing), while GRID gives specific constructors for creating structured meshes.
+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 .
+Underlying the unstructured meshes is the notion of connectivity. This section only covers meshes made out of standard elements, the \c MEDMEM_POLYGON and \c MEDMEM_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 (if the mesh has no MED_POLYGON and MED_POLYHEDRA element) :
-- 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,
+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.
+The cell types are ordered by their number of nodes; MEDMEM_POLYGON and
+MEDMEM_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"
The number of types is : 3
The type array writes :
-\{ \a MED_TRIA3, \a MED_QUAD4, \a MED_TRIA6 \}
+\{ \a MEDMEM_TRIA3, \a MEDMEM_QUAD4, \a MEDMEM_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
- 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.
+- The methods for an advanced usage (applying algorithms to meshes)
+are given in \ref MESH_advanced.
*/
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, dimensions, coordinate system, ...),
+- 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
+The specific case of \c MEDMEM_POLYGON and \c MEDMEM_POLYHEDRA
elements requires some methods that are described in \ref polygon.
\section outline_meshing Outline
- Python:
\include MESHINGexample.py
-*/
\ No newline at end of file
+*/
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 separately . Therefore,
-the methods that give access to this data are slightly different from
-those of section \ref mesh.
+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.
-Also, the polygon and the polyhedra case differ in nature,
+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
\image latex polygon_connectivity_small.eps "Example for polygon connectivity"
-- The standard element connectivity table writes : {2, 6, 7, 3, 3, 7, 8, 4 }
-- The standard element connectivity index table writes : {1, 5, 9 }
-- The polygon element connectivity table writes : {1, 2, 3, 4, 5 }
-- The polygon element connectivity index table writes : {1, 6 }
+- 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,
-one more array is required, because a
-list of nodes does not suffice to describe a general polyhedron.
-A general polyhedron is therefore described by a list of faces,
-each of those being described by a list of nodes.
+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.
+being stored as a \c MEDMEM_TETRA4 element, the right one being stored
+as a \c MEDMEM_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 standard element index connectivity table writes : {1, 5 }
-- The standard element connectivity table writes : {1, 2, 3, 4 }
-- The polyhedra connectivity index table writes :{1, 5}
-- The polyhedra connectivity face index table writes : {1, 4, 7, 10, 13}
-- The polyhedra connectivity (face/node connectivity) table writes : {2, 3, 5, 2, 4, 5, 4, 5, 3, 2, 3, 4}
+- 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 }
-Note that as they are not needed as such, the face numberings are not stored
-in any array. Only the number of nodes per face is implicitly stored
-in the polyhedra face connectivity index table.
-
-If there are two \c MED_POLYHEDRA elements that share a common face,
+If there are two \c MEDMEM_POLYHEDRA elements that share a common face,
the list of nodes is repeated twice in the polyhedron connectivity
-array.
-
-\section poly_outline Outline
-The methods associated to polygons/polyhedra are located in the following classes :
-- access methods are stored in MESH : \ref MESH_poly
-- creation methods are in MESHING : \ref MESHING_poly
+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
-*/
\ No newline at end of file
+*/
