From f5a499de8752cc56ae8814410b8b17735b94b4ee Mon Sep 17 00:00:00 2001 From: eap Date: Thu, 9 Sep 2010 14:05:20 +0000 Subject: [PATCH] Preparation of MEDMEM for SALOME 6x Update according to changes --- doc/doxygen/grid.dox | 13 +++++++----- doc/doxygen/main.dox | 4 +++- doc/doxygen/medmem.dox | 19 +++++++++--------- doc/doxygen/mesh.dox | 18 ++++++++++------- doc/doxygen/meshing.dox | 4 ++-- doc/doxygen/polygon.dox | 44 ++++++++++++++--------------------------- 6 files changed, 48 insertions(+), 54 deletions(-) diff --git a/doc/doxygen/grid.dox b/doc/doxygen/grid.dox index 36e09d3f8..07c6f5122 100644 --- a/doc/doxygen/grid.dox +++ b/doc/doxygen/grid.dox @@ -3,10 +3,10 @@ \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 @@ -17,5 +17,8 @@ of the last axis (c.f. figure \ref fig_grid_connectivity} ). \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. */ diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index 69d054975..7b35a7010 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -13,7 +13,9 @@ to suit the needs of its user. Instructions for configuring and installing the l \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 diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index 8cc256ec4..95b9d72e1 100644 --- a/doc/doxygen/medmem.dox +++ b/doc/doxygen/medmem.dox @@ -13,10 +13,9 @@ The Med libraries are oganized in multiple layers: - 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). @@ -26,13 +25,14 @@ In this document, we describe the API of the Med Memory library (available in C+ 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. @@ -85,7 +85,7 @@ a temperature at times \a t=0.0 s, \a t=1.0 s, \a t=2.0 s will be considered as 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. @@ -124,7 +124,7 @@ 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 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. @@ -146,8 +146,7 @@ of the mesh; - 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 : diff --git a/doc/doxygen/mesh.dox b/doc/doxygen/mesh.dox index 9a82793da..6e664c698 100644 --- a/doc/doxygen/mesh.dox +++ b/doc/doxygen/mesh.dox @@ -3,7 +3,8 @@ \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 . @@ -12,12 +13,13 @@ Underlying the unstructured meshes is the notion of connectivity. This section o \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" @@ -56,6 +58,8 @@ The description of MESH methods is given by the following sections : - 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. */ diff --git a/doc/doxygen/meshing.dox b/doc/doxygen/meshing.dox index de2565a2c..0b97eb4db 100644 --- a/doc/doxygen/meshing.dox +++ b/doc/doxygen/meshing.dox @@ -12,7 +12,7 @@ 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, dimensions, coordinate system, ...), +- setting general information (name, description, coordinate system, ...), - setting the nodes (number and coordinates), - setting the connectivity (types, connectivity arrays,...), - group creations. @@ -37,4 +37,4 @@ An example of mesh creation via MESHING is given in : - Python: \include MESHINGexample.py -*/ \ No newline at end of file +*/ diff --git a/doc/doxygen/polygon.dox b/doc/doxygen/polygon.dox index 75054cd7a..45d4cb5a7 100644 --- a/doc/doxygen/polygon.dox +++ b/doc/doxygen/polygon.dox @@ -4,12 +4,12 @@ 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 @@ -24,18 +24,16 @@ Let us consider the case illustrated in figure \ref fig_polygon_connectivity . \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 @@ -46,27 +44,15 @@ as a \c MED_POLYHEDRA element. \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 +*/ -- 2.39.2