From 69453d30768e495c7eba2badc9189a3433ee5ac6 Mon Sep 17 00:00:00 2001 From: ageay Date: Wed, 9 Mar 2011 06:49:56 +0000 Subject: [PATCH] *** empty log message *** --- doc/doxygen/Doxyfile_med_user.in | 36 ++++++++++---------- doc/doxygen/MED_class.dox | 24 ------------- doc/doxygen/grid.dox | 13 ++++--- doc/doxygen/medfilebrowser.dox | 22 ++++++++++++ doc/doxygen/medmem.dox | 58 +++++++++++++++----------------- doc/doxygen/mesh.dox | 21 +++++++----- doc/doxygen/meshing.dox | 6 ++-- doc/doxygen/polygon.dox | 50 ++++++++++----------------- 8 files changed, 110 insertions(+), 120 deletions(-) delete mode 100644 doc/doxygen/MED_class.dox create mode 100644 doc/doxygen/medfilebrowser.dox diff --git a/doc/doxygen/Doxyfile_med_user.in b/doc/doxygen/Doxyfile_med_user.in index f8e39d1f8..cafc4de5d 100644 --- a/doc/doxygen/Doxyfile_med_user.in +++ b/doc/doxygen/Doxyfile_med_user.in @@ -77,12 +77,13 @@ INPUT = @srcdir@ \ @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.* \ @@ -108,28 +109,29 @@ FILE_PATTERNS = MEDMEM_Mesh.* \ 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 diff --git a/doc/doxygen/MED_class.dox b/doc/doxygen/MED_class.dox deleted file mode 100644 index fa348a573..000000000 --- a/doc/doxygen/MED_class.dox +++ /dev/null @@ -1,24 +0,0 @@ - -/*! -\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 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/medfilebrowser.dox b/doc/doxygen/medfilebrowser.dox new file mode 100644 index 000000000..622f00666 --- /dev/null +++ b/doc/doxygen/medfilebrowser.dox @@ -0,0 +1,22 @@ + +/*! +\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. + +*/ diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index 8cc256ec4..70c55153c 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 : @@ -196,25 +195,25 @@ only \b node and \b cell are considered. In 2D mesh, only \b node, 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/ . @@ -276,4 +275,3 @@ The following options can be useful to configure MEDMEM : - \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/mesh.dox b/doc/doxygen/mesh.dox index 9a82793da..52ff8f25c 100644 --- a/doc/doxygen/mesh.dox +++ b/doc/doxygen/mesh.dox @@ -3,21 +3,23 @@ \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" @@ -25,7 +27,7 @@ As an example, let us consider a mesh made out of a linear triangle, two linear 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 @@ -56,6 +58,7 @@ 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. */ diff --git a/doc/doxygen/meshing.dox b/doc/doxygen/meshing.dox index de2565a2c..20d87bfdd 100644 --- a/doc/doxygen/meshing.dox +++ b/doc/doxygen/meshing.dox @@ -12,14 +12,14 @@ 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. 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 @@ -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..ea5121a1c 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,49 +24,35 @@ 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 -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 +*/ -- 2.39.2