\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.
*/
\section outline Outline
This user guide contains three different chapters that covers the core %MEDMEM library, the %ParaMEDMEM library and the %MEDSPLITTER tool:
-- Chapter \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).
+- Chapter \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, etc).
- Chapter \ref interpkernel describes the interpolation and
localization library.
- Chapter \ref medcoupling describes DataStructures used for cross
- 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 :
\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 .
\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; 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"
- 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. Some advanced methods are provided by
+the base GMESH in \ref GMESH_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.
- 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
\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}
-
-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.
+- 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.
-
-\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
+*/
