From: ndjinga Date: Tue, 9 Mar 2010 11:26:22 +0000 (+0000) Subject: Corrected minor error in medmem doxygen comments X-Git-Tag: V5_1_main_FINAL~162 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=865b9612cef7bc5f4526c6038c6e614a54edb24f;p=tools%2Fmedcoupling.git Corrected minor error in medmem doxygen comments --- diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index e2e10c2ad..8cc256ec4 100644 --- a/doc/doxygen/medmem.dox +++ b/doc/doxygen/medmem.dox @@ -122,7 +122,7 @@ 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)~: +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; @@ -137,7 +137,7 @@ an UML diagram view of the main Med Memory 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~: +is possible to: - read/write meshes and fields from MED-files; - create fields containing scalar or vectorial values on list of elements @@ -147,14 +147,14 @@ of the mesh; 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. +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 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 @@ -232,11 +232,11 @@ 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. +- Data Exchange Channel (aka DEC, abstract class) : \ref dec, and its implementations : + - \ref interpkerneldec for a \ref InterpKerRemapGlobal based on intersecting elems volume computation, + - \ref noncoincidentdec for a non-conservative interpolation based on element localization, + - \ref structuredcoincidentdec for remapping coincident meshes on a one-to-one basis. This class applies to structured topologies. + - \ref explicitcoincidentdec for remapping coincident meshes on a one-to-one basis. This class applies to unstructured topologies, */