From: vbd Date: Wed, 13 Jul 2011 08:22:38 +0000 (+0000) Subject: merge from 631 BR X-Git-Tag: MEDPartitioner_first_compilable_version~10 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=684fbc340f8746a5f9d8f3c04c8fb6bb69185cb6;p=tools%2Fmedcoupling.git merge from 631 BR --- diff --git a/doc/doxygen/Doxyfile_med_user.in b/doc/doxygen/Doxyfile_med_user.in index 01b76df5c..db4a10990 100644 --- a/doc/doxygen/Doxyfile_med_user.in +++ b/doc/doxygen/Doxyfile_med_user.in @@ -1,20 +1,20 @@ -# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +# Copyright (C) 2007-2011 CEA/DEN, EDF R&D, OPEN CASCADE # -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 2.1 of the License. +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License. # -# This library is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# Lesser General Public License for more details. +# This library is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# Lesser General Public License for more details. # -# You should have received a copy of the GNU Lesser General Public -# License along with this library; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# You should have received a copy of the GNU Lesser General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com # # Doxyfile 0.1 @@ -77,15 +77,19 @@ 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.* \ + MEDMEM_Remapper.* \ InterpKernelDEC.* \ + OverlapDEC.* \ DEC.* \ - MPIProcessorGroup.* \ + DisjointDEC.* \ + MPIProcessorGroup.* \ StructuredCoincidentDEC.* \ ExplicitCoincidentDEC.* \ NonCoincidentDEC.* \ @@ -108,27 +112,30 @@ FILE_PATTERNS = MEDMEM_Mesh.* \ InterpKernelGeo2DNode.* \ InterpKernelGeo2DQuadraticPolygon.* \ ParaFIELD.* \ - MEDCouplingMesh.* \ + MEDCouplingMesh.* \ MEDCouplingUMesh.* \ - MEDCouplingUMeshDesc.* \ - MEDCouplingPointSet.* \ - MEDCouplingCMesh.* \ - MEDCouplingExtrudedMesh.* \ - MEDCouplingFieldDouble.* \ - MEDCouplingField.* \ - MEDCouplingFieldDiscretization.* \ - MEDCouplingTimeDiscretization.* \ - MEDCouplingTimeLabel.* \ - MEDCouplingRefCountObject.* \ - MEDCouplingMemArray.* \ - MEDCouplingRemapper.* \ - MEDLoader.* \ + MEDCouplingUMeshDesc.* \ + MEDCouplingPointSet.* \ + MEDCouplingCMesh.* \ + MEDCouplingExtrudedMesh.* \ + MEDCouplingFieldDouble.* \ + MEDCouplingField.* \ + MEDCouplingFieldTemplate.* \ + 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 @@ -165,6 +172,12 @@ DISABLE_INDEX = NO ENUM_VALUES_PER_LINE = 4 GENERATE_TREEVIEW = YES TREEVIEW_WIDTH = 250 + +#--------------------------------------------------------------------------- +#SORT related options +#--------------------------------------------------------------------------- +SORT_GROUP_NAMES = NO + #--------------------------------------------------------------------------- # configuration options related to the LaTeX output #--------------------------------------------------------------------------- @@ -201,13 +214,13 @@ GENERATE_XML = NO # Configuration options related to the preprocessor #--------------------------------------------------------------------------- ENABLE_PREPROCESSING = YES -MACRO_EXPANSION = NO -EXPAND_ONLY_PREDEF = NO +MACRO_EXPANSION = YES +EXPAND_ONLY_PREDEF = YES SEARCH_INCLUDES = YES INCLUDE_PATH = INCLUDE_FILE_PATTERNS = PREDEFINED = -EXPAND_AS_DEFINED = +EXPAND_AS_DEFINED = MEDCOUPLING_EXPORT MEDCOUPLINGREMAPPER_EXPORT SKIP_FUNCTION_MACROS = YES #--------------------------------------------------------------------------- # Configuration::addtions related to external references diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index b49523f5f..714e33185 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -1,20 +1,20 @@ -# Copyright (C) 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE +# Copyright (C) 2007-2011 CEA/DEN, EDF R&D, OPEN CASCADE # -# This library is free software; you can redistribute it and/or -# modify it under the terms of the GNU Lesser General Public -# License as published by the Free Software Foundation; either -# version 2.1 of the License. +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License. # -# This library is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -# Lesser General Public License for more details. +# This library is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# Lesser General Public License for more details. # -# You should have received a copy of the GNU Lesser General Public -# License along with this library; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# You should have received a copy of the GNU Lesser General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com +# See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com # # MED MEDMEM : MED files in memory @@ -27,7 +27,9 @@ guidocdir = $(docdir)/gui/MED guidoc_DATA = images/head.png install-data-local : html-local - $(INSTALL) -d $(DESTDIR)$(docdir)/gui/MED + @if test -d doc_ref_user; then \ + $(INSTALL) -d $(DESTDIR)$(docdir)/gui/MED; \ + fi @if test -d doc_ref_user/html ; then \ for filen in `find doc_ref_user/html -maxdepth 1 -type f` ; do\ echo "Installing $${filen}" ; \ @@ -44,7 +46,6 @@ clean-local: EXTRA_DIST += figures \ main.dox \ Geometric2D.dox \ - MED_class.dox \ biblio.dox \ barycoords.dox \ dualmesh.dox \ @@ -53,6 +54,7 @@ EXTRA_DIST += figures \ grid.dox \ interpkernel.dox \ medcoupling.dox \ + medfilebrowser.dox \ medloader.dox \ medmem.dox \ medsplitter.dox \ @@ -64,4 +66,4 @@ EXTRA_DIST += figures \ tools.dox \ static/footer.html \ static/doxygen.css \ - images \ No newline at end of file + images diff --git a/doc/doxygen/figures/OverlapDEC1.fig b/doc/doxygen/figures/OverlapDEC1.fig new file mode 100644 index 000000000..31166cd1e --- /dev/null +++ b/doc/doxygen/figures/OverlapDEC1.fig @@ -0,0 +1,95 @@ +#FIG 3.2 Produced by xfig version 3.2.5b +Landscape +Center +Inches +Letter +100.00 +Single +-2 +1200 2 +6 5775 5775 6750 6600 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6450 5850 6750 5850 +2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6450 6450 6750 6450 +2 1 0 1 1 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6450 6150 6750 6150 +4 0 0 50 -1 0 12 0.0000 4 180 525 5775 5925 proc 0\001 +4 0 2 50 -1 0 12 0.0000 4 180 525 5775 6525 proc 2\001 +4 0 1 50 -1 0 12 0.0000 4 180 525 5775 6225 proc 1\001 +-6 +6 2700 4050 3150 4500 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2925 4275 212 212 2925 4275 3075 4425 +4 0 0 50 -1 0 14 0.0000 4 165 120 2925 4350 0\001 +-6 +6 9300 3825 9750 4275 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 9525 4050 212 212 9525 4050 9675 4200 +4 0 0 50 -1 0 14 0.0000 4 165 120 9525 4125 0\001 +-6 +6 4275 3525 4725 3975 +1 3 0 1 1 7 50 -1 -1 0.000 1 0.0000 4500 3750 212 212 4500 3750 4712 3750 +4 0 1 50 -1 0 12 0.0000 4 135 105 4425 3825 0\001 +-6 +6 7950 3225 8400 3675 +1 3 0 1 1 7 50 -1 -1 0.000 1 0.0000 8175 3450 212 212 8175 3450 8387 3450 +4 0 1 50 -1 0 12 0.0000 4 135 105 8100 3525 0\001 +-6 +6 2775 2550 3225 3000 +1 3 0 1 2 7 50 -1 -1 0.000 1 0.0000 3000 2775 212 212 3000 2775 3212 2775 +4 0 2 50 -1 0 12 0.0000 4 135 105 3000 2850 0\001 +-6 +6 8775 2475 9225 2925 +1 3 0 1 2 7 50 -1 -1 0.000 1 0.0000 9000 2700 212 212 9000 2700 9212 2700 +4 0 2 50 -1 0 12 0.0000 4 135 105 9000 2775 0\001 +-6 +1 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 3975 4425 212 212 3975 4425 4125 4575 +1 3 0 1 1 7 50 -1 -1 0.000 1 0.0000 4248 2814 212 212 4248 2814 4460 2814 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 3 + 3600 3600 4800 4800 3600 4800 +2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 4800 2400 4800 2400 3600 3600 3600 3600 4800 +2 2 0 1 1 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 4875 3375 3675 3375 3675 2175 4875 2175 4875 3375 +2 1 0 1 1 7 50 -1 -1 0.000 0 0 -1 0 0 3 + 4875 3375 4875 4650 3675 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6225 5250 6225 975 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3075 1425 3975 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 8700 1425 9525 1425 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 4 + 7800 4800 10200 4800 10200 2400 7800 4800 +2 1 0 1 1 7 50 -1 -1 0.000 0 0 -1 0 0 4 + 7800 4650 8925 3525 7800 2475 7800 4650 +2 1 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 4 + 9000 3450 10125 2325 7875 2325 9000 3450 +2 2 0 1 2 7 50 -1 -1 0.000 0 0 -1 0 0 5 + 3600 3375 2400 3375 2400 2175 3600 2175 3600 3375 +4 0 0 50 -1 0 12 0.0000 4 135 105 2325 5100 0\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 4725 5100 2\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 3600 5100 1\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 2175 3750 3\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 3450 3825 4\001 +4 0 0 50 -1 0 20 0.0000 4 225 930 3075 1275 Source\001 +4 0 0 50 -1 0 14 0.0000 4 165 120 3900 4500 1\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 2175 3450 0\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 3450 3300 1\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 3825 3300 1\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 5025 3375 2\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 3750 2025 3\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 4950 2025 4\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 4950 4875 0\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 4200 2850 1\001 +4 0 0 50 -1 0 20 0.0000 4 300 885 8625 1275 Target\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 7575 4725 0\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 7500 2475 2\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 7725 5100 0\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 10125 5100 1\001 +4 0 0 50 -1 0 12 0.0000 4 135 105 10425 2400 2\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 9000 3300 0\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 7800 2175 1\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 10050 2175 2\001 +4 0 1 50 -1 0 12 0.0000 4 135 105 8700 3600 1\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 3525 2025 3\001 +4 0 2 50 -1 0 12 0.0000 4 135 105 2325 2025 2\001 diff --git a/doc/doxygen/figures/OverlapDEC1.png b/doc/doxygen/figures/OverlapDEC1.png new file mode 100644 index 000000000..d6fbd3f0b Binary files /dev/null and b/doc/doxygen/figures/OverlapDEC1.png differ diff --git a/doc/doxygen/figures/UML_light.png b/doc/doxygen/figures/UML_light.png index 8eff5fa9c..08ecacdbb 100644 Binary files a/doc/doxygen/figures/UML_light.png and b/doc/doxygen/figures/UML_light.png differ diff --git a/doc/doxygen/figures/UML_small.png b/doc/doxygen/figures/UML_small.png index 77109ab34..791728fa4 100644 Binary files a/doc/doxygen/figures/UML_small.png and b/doc/doxygen/figures/UML_small.png differ 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/interpkernel.dox b/doc/doxygen/interpkernel.dox index bfed9661f..71db3faad 100644 --- a/doc/doxygen/interpkernel.dox +++ b/doc/doxygen/interpkernel.dox @@ -1,170 +1,46 @@ /*! -\page interpkernel Interpolation kernel toolkit +\page interpkernel Interpolation tools \section InterpKerIntro Introduction The main purpose of this module is to propose a set of algorithms for -mesh interpolation \b fully \b independant \b of \b mesh \b datastructure to +mesh interpolation \b fully \b independant \b of \b the \b mesh \b datastructure to support several type of format. This component is parameterized as much as possible using C++ templates. For the moment only interpolators for unstructured meshes are present in -%interpolation kernel. - -\section InterpKerTheory Theory of interpolation - -\subsection InterpKerPerfOverl Mesh overlapping - -When interpolation is performed between a source mesh S and a target -mesh T the aspect of overlapping is important. In fact if any cell of -of S is fully overlapped by cells of T and inversely any cell of T is -fully overlapped by cells of S the meshes S and T are said \b -coincidant and some general formulae in next sub section are simpler. -As far as possible in the next sub sections the formulae for -coincidant and non-coincidant meshes will be given. - -\subsection InterpKerRemapGlobal Global conservative remapping - -For fields with polynomial representation on each cell, the components of the discretized field \f$ \phi_s \f$ on the source side can be expressed as linear combinations of the components of the discretized field \f$ \phi_t \f$ on the target side, in terms of a matrix-vector product : - -\f[ - \phi_t=W.\phi_s. -\f] - -All the aim of interpolators is to compute W depending on a physical -quantities and the type of interpolation wanted (P0, P1, P1d etc...). - -For the \b intensive \b field \f$ \phi \f$ from the -source mesh \f$ S \f$ to the target mesh \f$ T \f$ the interpolation should preserve the -integral of \f$ \phi \f$ on any domain. At the discrete level, for any -target cell \f$ T_i \f$, the following \b general \b interpolation \b -equation \anchor InterpKerGenralEq has to -be always verified : - -\f[ -\int_{T_i} \phi = \sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi. -\f] - -To compute \f$ W_{ij} \f$ -this equation is used. The evaluation of integrals depends on the source and target meshes and on the nature of interpolation chosen : P0, P1, P1d etc... For the moment it is only possible to -remap fields with P0 representations. - -\subsection InterpKerRemapInt Conservative remapping of intensive physical quantities - -At the basis of many CFD numerical schemes is the fact that physical -quantities such as density, momentum per unit volume or energy per -unit volume obey some balance laws that should be preserved at the -discrete level on every cell. This property is critical for example to -accurately capture shockwaves. - -\subsection InterpKerP0P0Int cell-cell (P0->P0) conservative remapping of intensive physical quantities - -In the \ref InterpKerGenralEq "general interpolation equation" the -left hand side becomes : - -\f[ -\int_{T_i} \phi = (\sum_{S_j} Vol(T_i\cap S_j)).\phi_{T_i}. -\f] - -\note \f$ \sum_{S_j} Vol(T_i\cap S_j) = Vol(T_i) \f$ \ref InterpKerPerfOverl "in case of perfect overlapping". - -In the \ref InterpKerGenralEq "general interpolation equation" the -right hand side becomes : - -\f[ -\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = \sum_{S_j\cap T_i \neq \emptyset} {Vol(T_i\cap S_j)}.\phi_{S_j}. -\f] - -In the case where the \b intensive field values are constant on each -cell, the coefficients of the linear remapping matrix \f$ W \f$ are -given by the formula : - -\f[ - W_{ij}=\frac{Vol(T_i\cap S_j)}{ \sum_{S_j} Vol(T_i\cap S_j) }. -\f] - -and \ref InterpKerPerfOverl "in case of perfect overlapping" : - -\f[ - W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(T_i) }. -\f] - -Where Vol represents the volume with mesh dimension of interpolation equals to 3, the -area when mesh dimension equals to 2, and length when mesh dimension equals to 1. - -\subsection InterpKerRemapExt Conservative remapping of extensive physical quantities - -In code coupling from neutronics to hydraulic code \b extensive field -of power is exchanged and the all power as to be kept the same. The -principle is to 'intensify' the field to move on from extensive field -\e P to an intensive one \f$ \phi \f$. - -\subsection InterpKerP0P0Ext cell-cell (P0->P0) conservative remapping of extensive physical quantities - -In the \ref InterpKerGenralEq "general interpolation equation" the -left hand side becomes : - -\f[ -\int_{T_i} \phi = P_{T_i}. -\f] - -In the \ref InterpKerGenralEq "general interpolation equation" the -right hand side becomes : - -\f[ -\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = -\sum_{S_j\cap T_i \neq \emptyset} \frac{Vol(T_i\cap S_j)}{\sum_{T_i} Vol(T_i \cap S_j)}.P_{S_j}. -\f] - -\note \f$ \sum_{T_i} Vol(T_i \cap S_j) = Vol(S_j) \f$ \ref InterpKerPerfOverl "in case of perfect overlapping". - -In the case where the \b extensive field values are constant on each -cell, the coefficients of the linear remapping matrix \f$ W \f$ are -given by the formula : - -\f[ - W_{ij}=\frac{Vol(T_i\cap S_j)}{ \sum_{T_i} Vol(T_i \cap S_j) }. -\f] - -and \ref InterpKerPerfOverl "in case of perfect overlapping" : - -\f[ - W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }. -\f] +the %interpolation kernel. \section InterpKerMainArchitecture Main architecture of interpolation kernel. -In %interpolation kernel, the algorithm that computes \f$ W_{ij} \f$ given cell i -in source mesh and cell j in target mesh is called intersector. +In the %interpolation kernel, algorithms that computes the intersection \f$ T_i\cap S_j\f$ given the locations and geometries of source cell \f$ S_j \f$ +and target cell \f$ T_i \f$ are called \ref InterpKerIntersectors. -As seen in \ref InterpKerTheory "the theory of interpolation", for all interpolation the aim is to -fill the W matrix (which is generally a sparse matrix). Fundamatally for each pair (i,j) \f$ W_{ij} \f$ is obtained -by calling each time the wanted intersector. The problem is that each call to algorithm +As can be seen in \ref InterpKerTheory "the theory of interpolation", all the proposed interpolators aim at +filling the interpolation matrix W (which is generally sparse). For each pair (i,j), \f$ W_{ij} \f$ is obtained +by calling the desired intersector. The problem is that each call to this algorithm is CPU-expensive. -To reduce the computation time a first filtering is done to found a -maximim of (i,j) pairs where \f$ W_{ij} \f$ is obviously equal to 0. Typically it -is the case when a cell in source mesh is too far from an another cell -in target mesh each other. +To reduce the computational time, a first filtering is done to detect +pairs (i,j) \f$ W_{ij} \f$ is obviously equal to 0. It is typically the case when a cell in the source mesh +is too far from an another cell in the target mesh each. So for a given type of interpolation, the computation of W is performed in two steps : -# A filtering process reduces the number of pairs of elements for which the calculation must be carried out by - eliminating pairs that do not intersect through a comparison of - their bounding boxes. It reduces as much as possible call to intersector. + eliminating the pairs whose bounding boxes do not intersect. -# For all remaining pairs calling for each intersector (see \ref interpolation2D, \ref interpolation3Dsurf or \ref interpolation3D). -Each interpolator inherits from INTERP_KERNEL::Interpolation ( whatever -its dimension and its type ) that is a -CRTP class in order to clearly see the main API without useless CPU cost. +Whatever its dimension and type, each interpolator inherits from INTERP_KERNEL::Interpolation which is a +template (CRTP) class than enable an easy access to the main API without useless CPU cost. \subsection InterpKerMeshType class MeshType Each Interpolators and Intersectors are parameterized (templated in C++ langage) with \c class \c MeshType . This type of generalization has been chosen to reduce at maximum overhead. \n -Thanks to this principle \b intersectors \b and \b interpolators \b are \b usable -\b with \b several \b formats \b without \b preformance \b loss. For example MED, VTK...\n +Thanks to this principle intersectors and interpolators are usable +with \bseveral \b mesh \b formats such as \c MED or \c VTK, \b without \b preformance \b loss. \c MeshType is a concept that should strictly fulfilled the following rules : @@ -185,40 +61,37 @@ rules : -# \code void releaseTempArrays() \endcode - Formats of arrays - the array returned by \c getCoordinatesPtr must be a \b full \b interlace array. - - the arrays returned by \c getConnectivityPtr and \c - - getConnectivityIndexPtr must be with the same principle as it is in \ref medmemConnArrays "medmem". Of course the numbering format may change according to \a My_numPol policy. + - the arrays returned by \c getConnectivityPtr and \c getConnectivityIndexPtr must be with the same principle as it is in \ref medmemConnArrays "medmem". Of course the numbering format may change according to \a My_numPol policy. -\note The arrays formats of connectivity is kept close to MED. It is -close to VTK too but slightly different. So it needs VTK side a copy -on wrap. To avoid this copy of a part of connectivity structure, iterator should be used. +Note that the array format for connectivity is kept close to MED. It is +close to VTK format too but slightly different. So it may require for the VTK side a copy +on wrap. To avoid this copy of a part of the connectivity structure, an iterator should be used. \subsection InterpKerMatrixType class MatrixType As already said, the matrix returned by interpolator is typically a sparse matrix. Instances of -\c class \c MatrixType are used to stores these results of -interpolation. To be able to be filled by the interpolator the \c MatrixType class has to match the following concept : +\c class \c MatrixType are used to store the resulting interpolation matrix. To be able to be filled by the interpolator the \c MatrixType class has to match the following concept : - Methods -# \code void resize(uint nbrows) \endcode -# \code Row &operator [] (uint irow) \endcode -\c class \c Row has to match at least following concept : +\c class \c Row has to match at least the following concept : - Methods - \code void insert(const std::pair& myPair) \endcode -\note \c std::vector\c < \c std::map > is a candidate for +Note that \c std::vector\c < \c std::map > is a candidate for \c MatrixType. -\section InterpKerGenUsage Usage of interpolation kernel. +\section InterpKerGenUsage Usage of interpolation tools: the REMAPPER classes. \subsection InterpKerHighLevUsage high-level usage -The simplest mode of usage of interpolator in sequential mode is to use REMAPPER classes. These classes fulfill HXX2SALOME rules to allow the user to use it -in coupling graphs. 2 REMAPPERS exist, ParaMEDMEM::MEDCouplingRemapper and Remapper. These classes are strongly linked to their corresponding data structure, respectively -MEDCoupling and MEDMEM. In return, all interpolation request and spare interpolation matrix are hidden from you. Here two examples of REMAPPER classes : +The simplest way of using the interpolation tools is in sequential mode to use the REMAPPER classes. These classes fulfill \c HXX2SALOME rules and may be used +in coupling graphs. Two sequential REMAPPERS exist, \c ParaMEDMEM::MEDCouplingRemapper and \ref medmemremapper . These classes are strongly linked to their corresponding data structure, respectively \ref medcoupling and \ref MEDMEM. -- If you intend to use MEDCoupling data struture, ParaMEDMEM::MEDCouplingRemapper class should be used : +- If you intend to use \ref MEDCoupling data struture, ParaMEDMEM::MEDCouplingRemapper class should be used : \code ... @@ -240,7 +113,7 @@ sourceField->decrRef(); med_target_mesh->decrRef(); \endcode -- If you intend to use MEDMEM data structure, Remapper class should be used : +- If you intend to use \ref MEDMEM data structure, \c medmemremapper class should be used : \code ... @@ -251,7 +124,7 @@ MEDMEM::MESH med_target_mesh(MED_DRIVER,targetFileName,"Target_Mesh"); FIELD sourceField(MED_DRIVER,sourceFileName,"Density",0,0); FIELD targetField; Remapper mapper; -mapper.prepare(med_source_mesh,med_target_mesh); +mapper.prepare(med_source_mesh,med_target_mesh,"P0P1"); mapper.transfer(sourceField,targetField); //use targetField ... @@ -342,4 +215,122 @@ readerTarget->Delete(); ... \endcode +\section InterpKerTheory Theory of conservative interpolation + +At the basis of many CFD numerical schemes is the fact that physical +quantities such as density, momentum per unit volume or energy per +unit volume obey some balance laws that should be preserved at the +discrete level on every cell. This property is critical for example to +accurately capture shockwaves. + +\subsection InterpKerPerfOverl Mesh overlapping + +When interpolation is performed between a source mesh S and a target +mesh T the aspect of overlapping is important. In fact if any cell of +of S is fully overlapped by cells of T and inversely any cell of T is +fully overlapped by cells of S the meshes S and T are said to be \b +coincident and some general formulae in next sub section are simpler. +As far as possible in the next sub sections the formulae for +coincident and non-coincident meshes will be given. + +\subsection InterpKerRemapGlobal Linear conservative remapping + +For fields with polynomial representation on each cell, the components of the discretized field \f$ \phi_s \f$ on the source side can be expressed as linear combinations of the components of the discretized field \f$ \phi_t \f$ on the target side, in terms of a matrix-vector product : + +\f[ + \phi_t=W.\phi_s. +\f] + +The objectives of interpolators is to compute the matrix W depending on their physical +properties (intensive or extensive field) and their mesh discretisation (P0, P1,...). + +It is often desired that the process interpolation preserve the +integral of \f$ \phi \f$ on any domain. At the discrete level, for any +target cell \f$ T_i \f$, the following \b general \b interpolation \b +equation \anchor InterpKerGenralEq has to +be always verified : + +\f[ +\int_{T_i} \phi = \sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi. +\f] + +This equation is used to compute \f$ W_{ij} \f$, based on the fields representation ( P0, P1, P1d etc..) and the +geometry of source and target mesh cells. : + +\subsection InterpKerRemapInt Conservative remapping of P0 (cell based) fields + +We assume that the field is represented by a vector with a discrete value on each cell. +This value can represent either +- an average value of the field in the cell (average density, velocity or temperature in the cell) in which case the representation is said to be \b intensive, +- an integrated value over the cell (total mass, power of the cell) in which case the representation is said to be \b extensive + +\subsection InterpKerP0P0Int cell-cell (P0->P0) conservative remapping of intensive fields + +In the \ref InterpKerGenralEq "general interpolation equation" the +left hand side becomes : + +\f[ +\int_{T_i} \phi = (\sum_{S_j} Vol(T_i\cap S_j)).\phi_{T_i}. +\f] + +Here Vol represents the volume when the mesh dimension is equal to 3, the +area when mesh dimension is equal to 2, and length when mesh dimension is equal to 1. + +Note that \f$ \sum_{S_j} Vol(T_i\cap S_j) = Vol(T_i) \f$ \ref InterpKerPerfOverl "in case of perfect overlapping". + +In the \ref InterpKerGenralEq "general interpolation equation" the +right hand side becomes : + +\f[ +\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = \sum_{S_j\cap T_i \neq \emptyset} {Vol(T_i\cap S_j)}.\phi_{S_j}. +\f] + +As the field values are constant on each +cell, the coefficients of the linear remapping matrix \f$ W \f$ are +given by the formula : + +\f[ + W_{ij}=\frac{Vol(T_i\cap S_j)}{ \sum_{S_j} Vol(T_i\cap S_j) }. +\f] + +and \ref InterpKerPerfOverl "in case of perfect overlapping" : + +\f[ + W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(T_i) }. +\f] + +\subsection InterpKerP0P0Ext cell-cell (P0->P0) conservative remapping of extensive physical quantities + +In code coupling from neutronics to hydraulics, \b extensive field +of power is exchanged and the total power should remain the same. +The discrete values of the field represent the total power contained in the cell. +Hence in the \ref InterpKerGenralEq "general interpolation equation" the +left hand side becomes : + +\f[ +\int_{T_i} \phi = P_{T_i}, +\f] + +while the right hand side is now : + +\f[ +\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = +\sum_{S_j\cap T_i \neq \emptyset} \frac{Vol(T_i\cap S_j)}{\sum_{T_i} Vol(T_i \cap S_j)}.P_{S_j}. +\f] + +Note \f$ \sum_{T_i} Vol(T_i \cap S_j) = Vol(S_j) \f$ \ref InterpKerPerfOverl "in case of perfect overlapping". + +The coefficients of the linear remapping matrix \f$ W \f$ are then +given by the formula : + +\f[ + W_{ij}=\frac{Vol(T_i\cap S_j)}{ \sum_{T_i} Vol(T_i \cap S_j) }. +\f] + +and \ref InterpKerPerfOverl "in case of perfect overlapping" : + +\f[ + W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }. +\f] + */ diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index d7e4c3893..cbc0828d7 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -13,14 +13,13 @@ 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 interpkernel describes the interpolation and -localization library. - Chapter \ref medcoupling describes DataStructures used for cross process exchange of meshes and fields. - Chapter \ref paramedmem describes its MPI implementation, which is called %ParaMEDMEM. - Chapter \ref medloader describes API for I/O from or to a MED file coming from a \ref medcoupling data structure. +- Chapter \ref interpkernel describes the interpolation and localization library. +- 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 tools describes various tools based on MEDMEM that can be helpful for handling MED files (conversion tools and splitting tools). diff --git a/doc/doxygen/medcoupling.dox b/doc/doxygen/medcoupling.dox index cd5fdb3d1..82c97d29d 100644 --- a/doc/doxygen/medcoupling.dox +++ b/doc/doxygen/medcoupling.dox @@ -20,77 +20,23 @@ developped to be compatible with HPC constraints (compact structures, limitation of copies and launching of CPU consuming algorithms only when absolutely needed ). -\section MEDCouplingMainConc Main Concepts - -- \ref MEDCouplingMeshesP "Meshes" -- \ref MEDCouplingFieldsP "Fields" - -\section MEDCouplingFirstSteps1 Building an array from scratch - -All of exemples given here make the assumption that the \c ParaMEDMEM -namespace is visible ( by calling for example \c using \c -namespace \c ParaMEDMEM; ). - -Here a description of typical usages to use MEDCoupling arrays. -In this example we will create arrays with 12 tuples constituted each -of 3 components. These arrays will be created using different ways. +\section MEDCouplingMainBasics Basics -\code +One of the most basic concept mainly used all over MEDCoupling is +MEDCoupling array. This concept is used all over +MEDCoupling/ParaMEDMEM/MEDLoader modules so it should be correctly +handled to play well with \ref MEDCouplingMeshesP "Meshes" and \ref MEDCouplingFieldsP "Fields". -const int nbOfNodes=12; -double coords[3*nbOfNodes]={ ... }; +It exists two type of arrays : + - double precision float array incarnated by ParaMEDMEM::DataArrayDouble class. + - integer array incarnated by ParaMEDMEM::DataArrayInt class. -DataArrayDouble *myCoords=0; -double *tmp=0; -\endcode +To know more about arrays \ref MEDCouplingArrayPage "click here for arrays documentation". -- no copy no ownership -\code -myCoords=DataArrayDouble::New(); -myCoords->useArray(coords,false,CPP_DEALLOC,nbOfNodes,3); -//now use myCoords as you need -... -//myCoords is no more usefully here : release it -myCoords->decrRef(); -\endcode - - -- no copy and ownership C++ -\code -myCoords=DataArrayDouble::New(); -tmp=new double[3*nbOfNodes]; -std::copy(coords,coords+3*nbOfNodes,tmp); -myCoords->useArray(tmp,true,CPP_DEALLOC,nbOfNodes,3); -//now use myCoords as you need -... -//myCoords is no more usefully, release it -myCoords->decrRef(); -\endcode - -- no copy and ownership C -\code -myCoords=DataArrayDouble::New(); -tmp=(double *)malloc(3*nbOfNodes*sizeof(double)); -std::copy(coords,coords+3*nbOfNodes,tmp); -myCoords->useArray(tmp,true,C_DEALLOC,nbOfNodes,3); -//now use myCoords as you need -... -//myCoords is no more usefully here : release it -myCoords->decrRef(); -\endcode +\section MEDCouplingMainConc Main Concepts -- copy -\code -myCoords=DataArrayDouble::New(); -myCoords->alloc(nbOfNodes,3); -tmp=myCoords->getPointer(); -std::copy(coords,coords+3*nbOfNodes,tmp); -myCoords->declareAsNew();//you have modified data pointed by internal pointer notify object -//now use myCoords as you need -... -//myCoords is no more usefully here : release it -myCoords->decrRef(); -\endcode +- \ref MEDCouplingMeshesP "Meshes" +- \ref MEDCouplingFieldsP "Fields" \section MEDCouplingFirstSteps2 Building unstructured mesh from scratch @@ -251,7 +197,21 @@ A mesh has a the following properties : mesh have the same dimension) - a space dimension (relative to coordinates) - a number of nodes -- a number of cells +- a number of cells + +In MEDCoupling library there is no presence of faces nor edges. + +As a mesh has one dimension and only once, that is to say every cells in +mesh have the same dimension called MeshDimension. + +That is to say the +MEDMEM vocabulary of faces and edges \b do \b not \b exist \b anymore here in +MEDCoupling. + +For exemple a mesh with a meshDimension equal to 1, have \b cells of type +NORM_SEG2. An another exemple, a mesh with a meshDimension equal +to 2, have \b cells of type +NORM_TRI3 and NORM_POLYGON for example. The class that incarnates the concept described above is : \ref ParaMEDMEM::MEDCouplingMesh. @@ -276,7 +236,7 @@ used by MEDCoupling to instanciate degenerated meshes as : represent fields used by system code. This type of mesh will have mesh dimension equal to -1. -The norm used for cells connectivity of different types, is the same as specified in MED file execpt +The norm used for cells connectivity of different types, is the same as specified in MED file except that connectivities are in represented in \b C \b format and \b not \b in \b FORTRAN \b format ! @@ -409,3 +369,190 @@ The most important methods are : - \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getValueForTime "getValueForTime" */ + +/*! +\page MEDCouplingArrayPage MEDCoupling Arrays + +\section MEDCouplingArrayIntro Introduction + +This page will try to describe data arrays in MEDCoupling. Presently, +in MEDCoupling it exists two types of arrays : + +- double precision array incarnated by ParaMEDMEM::DataArrayDouble class. +- signed integer (32 bits) array incarnated by ParaMEDMEM::DataArrayInt class. + +\section MEDCouplingArrayBasics Basics concepts + +It will be presented in this section common concept shared by the two classes to \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt". + +- The first thing is that an array has a name (stored as a C++ string). This name is often ignored in MEDCoupling algorithm when arrays are aggregated (field array, connectivity, coordinates). + The reason is that name is stored by the aggregating object. + But it can be very usefull for arrays not aggregated in bigger MEDCoupling object for groups ids and families ids for example. + +- The second thing is the data storage. For obvious reason, MEDCoupling DataArray stores data in a contiguous way in memory like \c std::vector does.\n + +- The third thing is linked to previous point. Data arrays are able to store vectorized data. It is usefull to store the data of a vectorial field. That's why MEDCoupling arrays uses the concepts + of components. To store an array for a vector field on cell with 3 components lying on a mesh having 5 cells. The array will contain 5*3=15 values grouped by 3. + The 5 groups containing each 3 elements are called \b tuples.\n \b Number \b of \b values \b stored \b in \b an \b array \b is \b equal \b to \b number \b of \b tuples + \b multiplied \b by \b number \b of \b components. \n + Generally speaking, except for vector field arrays, and array for nodes coordinates, the number of components is equal to one. + +- The fourth thing is linked to point 2 and 3 as MEDCoupling is developped in C++ the values of arrays are stored tuples by tuples, that is to say in full interlace mode.\n + That is to say, the 15 values in the example in point 3 will be stored like this :\n + \f$ x_0,y_0,z_0,x_1,y_1,z_1,x_2,y_2,z_2,x_3,y_3,z_3,x_4,y_4,z_4 \f$ where x stands for component #0, y for component #1 and z for component #2 + As consequence \b all \b algorithms \b in \b ParaMEDMEM \b are \b working \b in \b full \b interlace \b mode. + +- The fifth thing is that each components of an array has info stored in a string. If a unit is desired to be added on components the following convention should be used "MY_COMPO_INFO [MYUNIT]".\n + Unit should be put between "[" and "]" after info and one space character. + +- The sixth thing is that MEDCoupling arrays inherits from \ref ParaMEDMEM::TimeLabel "TimeLabel" class. It means that the time stamp attached to array indicates if yes or no the array has been modified. + In C++ if the access of data is direct using non const \c getPointer method it is the reponsability to the use to notify the possible modification. + Inversely if setIJ method is used to modify an array, take care of the fact that the time stamp of the array is modified on each call to setIJ. If huge amount of call to setIJ is required it + is better to use setIJSilent instead and call notifyNew right after instead. + + +\section MEDCouplingArraySteps0 Building an array from scratch in Python + +\verbatim +arrayDouble=DataArrayDouble.New(); +dataDouble=[0.,10.,20.,1.,11.,21.,2.,12.,22.,3.,13.,23.,4.,14.,24.] +arrayDouble.setValues(dataDouble,5,3);# 5 tuples containing each 3 components +##### +arrayInt=DataArrayInt.New(); +dataInt=[0, 10, 20, 1, 11, 21, 2, 12, 22, 3, 13, 23, 4, 14, 24] +arrayInt.setValues(dataInt,5,3);# 5 tuples containing each 3 components +\endverbatim + +\section MEDCouplingArraySteps1 Building an array from scratch in C++ + +All of exemples given here make the assumption that the \c ParaMEDMEM +namespace is visible ( by calling for example \c using \c +namespace \c ParaMEDMEM; ). + +Here a description of typical usages to use \ref ParaMEDMEM::DataArrayDouble "MEDCoupling arrays".\n +In this example we will create arrays with 12 tuples constituted each +of 3 components. These arrays will be created using different ways.\n + +The following code is only based using \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" +but the use of \ref ParaMEDMEM::DataArrayInt "DataArrayInt" is strictly equivalent. + +\code + +const int nbOfNodes=12; +double coords[3*nbOfNodes]={ ... }; + +DataArrayDouble *myCoords=0; +double *tmp=0; +\endcode + +- no copy no ownership +\code +myCoords=DataArrayDouble::New(); +myCoords->useArray(coords,false,CPP_DEALLOC,nbOfNodes,3); +//now use myCoords as you need +... +//myCoords is no more usefully here : release it +myCoords->decrRef(); +\endcode + + +- no copy and ownership C++ +\code +myCoords=DataArrayDouble::New(); +tmp=new double[3*nbOfNodes]; +std::copy(coords,coords+3*nbOfNodes,tmp); +myCoords->useArray(tmp,true,CPP_DEALLOC,nbOfNodes,3); +//now use myCoords as you need +... +//myCoords is no more usefully, release it +myCoords->decrRef(); +\endcode + +- no copy and ownership C +\code +myCoords=DataArrayDouble::New(); +tmp=(double *)malloc(3*nbOfNodes*sizeof(double)); +std::copy(coords,coords+3*nbOfNodes,tmp); +myCoords->useArray(tmp,true,C_DEALLOC,nbOfNodes,3); +//now use myCoords as you need +... +//myCoords is no more usefully here : release it +myCoords->decrRef(); +\endcode + +- copy +\code +myCoords=DataArrayDouble::New(); +myCoords->alloc(nbOfNodes,3); +tmp=myCoords->getPointer(); +std::copy(coords,coords+3*nbOfNodes,tmp); +myCoords->declareAsNew();//you have modified data pointed by internal pointer notify object +//now use myCoords as you need +... +//myCoords is no more usefully here : release it +myCoords->decrRef(); +\endcode + +\section MEDCouplingArrayRenumbering Array renumbering + +Here is presented all it is necessary to know concerning renumbering. +Renumbering is intensely required in %MEDLoader in %ParaMEDMEM. One of the user of renumbering is MED file for I/O where cells are sorted by type. +But it is also used on operations of node cell merging. It is also used in parallel mode when splitting of mesh is needed... + +Formally a renumbering is a mathematical application that can be surjective, injective or bijective. This application is defined using an instance of +\ref ParaMEDMEM::DataArrayInt "DataArrayInt". There are different ways to define this application. + +\subsection MEDCouplingArrayRenumberingO2N Old to new mode + +The old to new mode is particulary recommanded for surjective and bijective application. This is typically the case of \ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "MEDCouplingUMesh::mergeNodes" method. +Let's consider a call to \ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes" that reduces the number of nodes from 5 nodes to 3 nodes.\n +In old to new mode the array \b MySurjection that specifies this surjection will have 5 tuples and 1 component. The content of the 5*1 values will be in {0,1,2}.\n + +If \b MySujection equals [2,1,0,1,2], it means that : + +- old id #0 will have new id equal to 2 +- old id #1 will have new id equal to 1 +- old id #2 will have new id equal to 0 +- old id #3 will have new id equal to 1 like old id #1 +- old id #4 will have new id equal to 2 like old id #0 + +This is the most common mode of renumbering in MEDCoupling because there is more methods implying renumbering that reduce the number of entities than method that increase number of entities. + +Method in old to new mode that works on bijective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumber "DataArrayDouble::renumber" +- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlace" + +Method in old to new mode that works on surjective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumberAndReduce "DataArrayDouble::renumberAndReduce" + +Sometimes the format old to new for sujections can be replaced by another format with 2 arrays. Less compact in memory. The \ref ParaMEDMEM::DataArrayInt::changeSurjectiveFormat "DataArrayInt::changeSurjectiveFormat" method performs that. + +\subsection MEDCouplingArrayRenumberingN2O New to old mode + +The new to old mode is particulary recommanded for strictly injective and bijective permutations. This is particulary usefull for methods that increase the number of entities like for example +\ref ParaMEDMEM::MEDCouplingUMesh::simplexize "MEDCouplingUMesh::simplexize".\n +All non static methods in \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" or \ref ParaMEDMEM::DataArrayInt "DataArrayInt" having as last letter \b R (meaning Reversed) in capital works with +the mode new to old. +Let's consider a call to \ref ParaMEDMEM::MEDCouplingUMesh::simplexize "simplexize" that increases the number of cell from 4 cells to 6 cells.\n +In new to old mode the array \b MyInjection that specifies this injection will have 6 tuples and 1 component. The content of the 5*1 values will be in {0,1,2,3}.\n +If \b MyInjection equals [2,0,1,1,3,0] it means that : + +- new id #0 comes from old id 2 +- new id #1 comes from old id 0 +- new id #2 comes from old id 1 +- new id #3 comes from old id 1 +- new id #4 comes from old id 3 +- new id #5 comes from old id 0 + +Method in new to old mode that works on bijective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumberR "DataArrayDouble::renumberR" +- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlaceR" + +Method in new to old mode that works on surjective applications : + +- \ref ParaMEDMEM::DataArrayDouble::selectByTupleId "DataArrayDouble::selectByTupleId" + +*/ 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/medloader.dox b/doc/doxygen/medloader.dox index 9cb490e52..344a8422d 100644 --- a/doc/doxygen/medloader.dox +++ b/doc/doxygen/medloader.dox @@ -1,17 +1,49 @@ /*! -\page medloader MEDLoader +\page medloader %MEDLoader \section MEDLoaderIntro Introduction -MEDLoader is a package in charge of loading from a file or write to a file +%MEDLoader is a package in charge of loading from a file or write to a file in MED format a \ref medcoupling data structure. The fact that these functionalities are not merged in \ref medcoupling is explained by a willingness of reducing as much as possible the dependancies of \ref medcoupling libraries. As a MED file can combine several \ref medcoupling aspects in one (for exemple meshes in -MED file on different mesh dimension with families and groups) the API of MEDLoader is much more rich than simply read and write. +MED file on different mesh dimension with families and groups) the API +of %MEDLoader is much more rich than simply read and write. -MEDLoader offers \b static methods whose method names have the first +MEDCoupling mesh does \b not fit a MED file mesh, and a MEDCoupling +field does \b not fit a MED file field. But it is possible to emulate +with a very good fidelity a MED file mesh and a MED file field with +a collection of MEDCoupling instances for each. + +That's why %MEDLoader module offers two different approaches to perform Read/Write from/to MED +file. + +- Either the user is close too MEDCoupling concepts. This is the case +if pieces of information to access or to write are \b directly +mapped to a MEDCouplingMesh/MEDCouplingFieldDouble in MEDCoupling package. \nIn this case, the \ref MEDLoaderBasicAPI "basic API" is recommended in this case because simpler and faster. + +- Or the user knows the MED file concept well and if nature of +information to deal with do not fit exactly the class offered by +MEDCoupling, the \ref MEDLoaderAdvancedAPI "advanced API" is +recommended. This is typically the case for a user that wants to precisely set/get +mesh/group/family groups set on different level lying on a same field defined +partially... This API is faster, all information contained in file is represented, but +less check is performed.\n This API is recommended for users that want to operate directly on MED files (split of MED files for example) + +The two methods are \b not opposed, they are compatible each other so +it is possible to mix them. But the user should keep in mind that +behaviour of these two methods can vary. + +*/ + +/*! +\page MEDLoaderBasicAPI Basic %MEDLoader API. + +The aim of this page is to present basic API of MEDLoader. The goal of +this basic API is to perform a read or a write in one shot without any +internal state. That's why the basic API of MEDLoader offers \b only \b static methods whose method names have the first character in capital. You are intended to use these methods. The following chapters will try to describe in details some of important ones. @@ -24,7 +56,7 @@ name of meshes and fields are used by MEDLoader to use it as this into MED file. A field f with \ref ParaMEDMEM::MEDCouplingTimeDiscretization "time discretization" set to ONE_TIME, the value of \c f->getTime(time,iteration,order) are used by MEDLoader to store -identifies the field into MED file. All strings used by MEDLoader to +to identify the field into MED file. All strings used by MEDLoader to use it into MED file should fulfill the rules of MED file where length are limited. That's why the user should be aware of these constaints when trying to read/write a MED file using MEDLoader. @@ -35,7 +67,7 @@ MEDLoader tries to manage that by protecting the user by throwing exceptions whe Here we will describes some of basic concepts of MED files in order to use the best methods proposed by MEDLoader API. -\subsection MEDLoaderMEDFileGen Basics in MED files +\subsection BasicMEDLoaderAPIGen Basics in MED files First of all MEDLoader \b will \b not read MED files whose version is \b lower \b than \b 2.2. The MEDLoader::CheckFileForRead will perform @@ -68,11 +100,11 @@ This recalled specificities of MED file explains that it is necessary to specify each time, at field-read time, the type of field, the iteration and order number the mesh you are interested in. -\subsection MEDLoaderMEDFileMesh Meshes in MED files +\subsection BasicMEDLoaderAPIMesh Meshes in MED files In MED file meshes could combine in one unstructured mesh cells that have different dimension. For example it is possible to mix -MED_TETRA4, MED_TRIA6, MED_SEG2, MED_POINT0, MED_POLYGON, +MED_TETRA4, MED_TRIA6, MED_SEG2, MED_POINT1, MED_POLYGON, MED_POLYHEDRA in a same mesh. In MEDCouplingUMesh such a mix is not allowed as described \ref MEDCouplingUMeshes "here". So to \b read such mesh it is important to know which meshdimension you are interested to. In API @@ -102,7 +134,7 @@ help you to have this mesh dimension. \anchor MEDLoaderExample2 - Consider an another mesh called "Example2" in file "file2.med" containing MED_POLYHEDRA, MED_TETRA4, MED_QUAD8, MED_TRI6, MED_SEG2 -and MED_POINT0. In this case you will have : +and MED_POINT1. In this case you will have : \code assert(3==MEDLoader::ReadUMeshDimFromFile("file2.med","Example2")); @@ -125,7 +157,7 @@ To get 1D cells (MED_SEG2) you should type : MEDCouplingUMesh *m1D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",-2); \endcode -And finally for 0D cells (MED_POINT0) you will write : +And finally for 0D cells (MED_POINT1) you will write : \code MEDCouplingUMesh *m0D=MEDLoader::ReadUMeshFromFile("file2.med","Example2",-3); @@ -137,7 +169,7 @@ file. This renumbering allows MEDLoader to conserve the order of MEDCoupling cells into the file. So if the renumbering of cells in MED file is not correct an exception will be thrown. -\subsection MEDLoaderMEDFilePoMesh Part of meshes in MED files +\subsection BasicMEDLoaderAPIPoMesh Part of meshes in MED files A mesh contains one or more families on nodes and/or on cells. A family is a partition (mathematical sense) of the mesh it lies to. A family can be described @@ -158,7 +190,7 @@ MEDLoader::ReadUMeshFromFamilies and MEDLoader::ReadUMeshFromGroups. This method allows you to combine several families and groups in the same returned mesh. -\subsection MEDLoaderMEDFileField Reading a field at one time step in MED files +\subsection BasicMEDLoaderAPIField Reading a field at one time step in MED files A field at one time step on one mesh, with one entity (cell, node) lies on all mesh on on a part of it. In this last case a definition of @@ -355,3 +387,253 @@ to other MEDLoader::Write* method the parameter of \b writeFromScratch is not needed here. */ + +/*! +\page MEDLoaderAdvancedAPI Advanced %MEDLoader API. + +This method is much closer to MED file organization than \ref +MEDLoaderBasicAPI "basic MEDLoader API". All MED file +concepts are exposed to the user. As a consequence, this advanced +API is lead to change with MED file data model enhancement. + +In reading mode, the user can scan entirely and directly the content of its MED file as it is organized in its MED file. +Inversely, in writing mode, the user can describe its data in the same +way that MED file does. + +\section AdvMEDLoaderBasics Some of basic parameters appearing in advanced API + +- Like basic %MEDLoader API there is a notion of \c meshDimRelToMax. +Each time This parameter appears in API, it will have the semantic +explain here. +The value of the parameter \c meshDimRelToMax is at most in {0,-1,-2,-3}. This relative value specifies a level +relative to value returned by \c myMedMesh->getMeshDimension(). + +A mesh containing MED_TETRA4, MED_TRI3, MED_QUAD4 and MED_POINT1 has a meshDimension +equal to 3. For \c meshDimRelToMax equal to 0 the user will +deal with cells whose type has a dimension equal to 3+0, that is to +say here MED_TETRA4. For \c meshDimRelToMax equal to -1 the user will +deal with cells witch dimension equal to 3-1 that is to say MED_TRI3 +and MED_QUAD4. + +An important method is \c getNonEmptyLevels() method. It returns all +non empty levels available. In the previous example, this method will +return {0,-1,-3}. -2 does not appear because no cells with dimension +equal to 1 (3-2) appear in MED file mesh (no MED_SEG2 not MED_SEG3). + +- Besides notion of \c meshDimRelToMax there is notion of \c meshDimRelToMaxExt. +\c meshDimRelToMaxExt is simply an extension of \c meshDimRelToMax for +nodes. + +The parameter of \c meshDimRelToMaxExt appears in +\ref ParaMEDMEM::MEDFileUMesh "umesh advanced API" of %MEDLoader with the following semantics. + +Some of MED file concepts are available both for cells and +nodes, (for example families, groups, numbering ) that's why for a simpler API this +concept has been introduced. \c meshDimRelToMaxExt parameter can take a value in at +most {1,0,-1,-2,-3}. +1 stands for node and 0,-1,-2,-3 has exactly the +same semantic than those described in \c meshDimRelToMax decribed +before. + +- A parameter that also often appears in advanced %MEDLoader API is \c renum. +This parameter by default in advanced %MEDLoader API is set to \c +true. +This parameter indicates if the user intend to take into account +of the renumbering array of cells of the current MED file mesh. +If no renumbering array is defined, this parameter is ignored by +%MEDLoader. + +If such renumbering exists and the \c renum parameter is +set to \c true, then the renumbering is taken into account. This is +exactly the behaviour of \ref MEDLoader::ReadUMeshFromFile "basic MEDLoader API". +If the user expects to ignore this renumbering even in case of +presence of renumbering array, false should be passed to \c renum +parameter. \b The \b parameter \b renum \b should \b be \b set \b with +\b cauton \b for \b users \b concerned \b by \b cells \b orders. + +- A laster important parameter is the \c mode during writing. The + available values for the parameter \c mode are : + - 2 : for a write from scratch. If file already exists, file will be + erased and replace by the content of the instance on which \c write + method has been calles. + - 1 : If the file does not exists equivalent to 2. If file already + exists, the write is done on APPEND mode. That is to say that no + data loss will occur. But in case that an element with same ids than + current instance already exists, the content is not written and an + exception is thrown. + - 0 : If the file does not exists equivalent to 2. If file already + exists write without any question. If an element with same ids + existed previously the content is overwritten by the content of the + current instance, that can lead to a file corruption. + +\section AdvMEDLoaderAPIReading Reading from a file with advanced API. + +Contrary to the basic %MEDLoader API, here after reading process, the user +has to deal with a new instance of class that fits the MED file model. +To access to a MEDCoupling mesh the user should request this class +instance. + +\subsection AdvMEDLoaderAPIMeshReading Reading a mesh. + +The class that incarnates Read/Write mesh in MED file is ParaMEDMEM::MEDFileUMesh. + +First of all, like basic %MEDLoader API, only MEDfile files whose version >= 2.2 are able +to be read with advanced API. + +To read a mesh having the name \c meshName in file \c fileName the +following simple code has to be written : + +\code + +MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName,meshName); + +\endcode + +If the user do not know the name of the mesh inside MED file +'fileName' the following code should be written : + +\code + +MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName); + +\endcode + +In this case the first mesh (in MED file sense) found in \c fileName +file will be loaded. + +Now the user can ask for mesh dimension of of \c myMedMesh instance by +calling \c myMedMesh->getMeshDimension(). This method returns the +highest level of present cell in MED file mesh \c myMedMesh. +This returned integer is computed and \b not those contained in MED file +that can be invalid. + +\n + +- Retrieving a mesh at a specified relative level \c meshDimRelToMax=mdrm : simply call + - \c myMedMesh->getMeshAtLevel(mdrm) + - or \c myMedMesh->getLevel0Mesh() or \c + myMedMesh->getLevelM1Mesh(), or \c myMedMesh->getLevelM2Mesh() + depending on the value of mdrm + + +- Retrieving a family at a specified level : + - Either an array of node/cell id + - \c getFamilyArr method or \c getFamiliesArr + - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling + - \c getFamily method or \c getFamilies + +- Retrieving a group at a specified level : + - Either an array of node/cell id + - \c getGroupArr method or \c getGroupsArr + - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling + - \c getGroup method or \c getGroups + +- Retrieving family field array : +Method \c getFamilyFieldAtLevel retrieves for a specified extended level the +family id of each cell or node. + +- Retrieving renumbering array : +Method \c getNumberFieldAtLevel returns, if it exists for a specified extended level, the +family id of each cell or node. If it does not exist an exception will +be thrown. + +An important point is that families and groups are \b not sorted in +MED file. No sort is stored in MED file explicitely for Groups and +Families. Advanced %MEDLoader API, uses the same order than underlying +mesh at specified level. + +\subsection AdvMEDLoaderAPIMeshReadingSampl Sample of reading a mesh. + +Here a typical use of \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" instance. + +\code + +const char fileName[]=...; +const char meshName[]=...; +MEDFileUMesh *medmesh=MEDFileUMesh::New(fileName,meshName); +std::vector nel=medmesh->getNonEmptyLevels(); +if(nel.size()<1) + throw INTERP_KERNEL::Exception("The test is not good for my file ! Expecting a multi level mesh to play with !"); +MEDCouplingUMesh *m0=medmesh->getMeshAtLevel(nel[1],false); +MEDCouplingUMesh *g1=medmesh->getGroup(nel[1],"mesh2",false); +DataArrayInt *dag1=medmesh->getGroupArr(nel[1],"mesh2",false); +MEDCouplingUMesh *g1bis=m0->buildPartOfMySelf(dag1->getConstPointer(),dag1->getConstPointer()+dag1->getNbOfElems()); +g1bis->setName(dag1->getName()); +if(!g1->isEqual(g1bis,1e-12)) + throw INTERP_KERNEL::Exception("hmmmm :g1 and g1bis should be equal..."); +// +dag1->decrRef(); +g1->decrRef(); +m0->decrRef(); +medmesh->decrRef(); + +\endcode + +\subsection AdvMEDLoaderAPIMeshWriting Writing a mesh. + +The use is very symetric to reading part. It is possible to either +build a \ref ParaMEDMEM::MEDFileUMesh "MEDFileUMesh" instance from +scratch, or to work with an existing instance coming from a loading +from a file. + +One important point is that coordinates of a mesh are shared by all +cells whatever their level. That's why the +\ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" instance +should be shared by all \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" used in input parameter of +set* methods. If the user intend to build a \ref ParaMEDMEM::MEDFileUMesh "MEDFileUMesh" instance from +scratch, a call to \c setCoords should be done first. + + +Generally speaking traduce get* methods with set* methods have corresponding write semantic. + +Some differences still exist : + +- \c setMeshAtLevel, \c setMeshAtLevelOld simply call \c setMeshAtLevelGen with repectively \c newOrOld parameter +set to true and false. These method specifies if a renumbering computation is needed or not. \c setMeshAtLevelOld is faster +than \c setMeshAtLevel because no renumbering computation is done. If the user is not warranty about the order of its meshes to enter +it is better to use \c setMeshAtLevel method. + +- Groups definition : Groups constitution is time consuming because of the stored mode chosen by MED file to store them. Groups definition +lead to a partition computation which is time/mem consuming that's why groups should be defined at once and not with addGroup one by one that will lead to +compute a partition for each appended group. One important point to note is that DataArrayInt instance given in input to define groups should have its name +set to the desired group name. If not an exception will be thrown, because MED file does not support groups with no name. + +\subsection AdvMEDLoaderAPIMeshWritingSampl Sample of writing a mesh. + +\code + +MEDCouplingUMesh *m=...; //m is a mesh with meshDim=2 spaceDim=2 +MEDCouplingUMesh *m1=...; //m1 is a mesh with meshDim=1 spaceDim=2 same coords than m +MEDCouplingUMesh *m2=...; //m2 is a mesh with meshDim=0 spaceDim=2 same coords than m +MEDFileUMesh *mm=MEDFileUMesh::New(); +mm->setName("mm");//name needed to be non empty +mm->setDescription("Description mm"); +mm->setCoords(m1->getCoords()); +mm->setMeshAtLevel(-1,m1,false); +mm->setMeshAtLevel(0,m,false); +mm->setMeshAtLevel(-2,m2,false); +DataArrayInt *g1=DataArrayInt::New(); +g1->alloc(2,1); +g1->setName("G1"); +const int val1[2]={1,3}; +std::copy(val1,val1+2,g1->getPointer()); +DataArrayInt *g2=DataArrayInt::New(); +g2->alloc(3,1); +g2->setName("G2"); +const int val2[3]={1,2,3}; +std::copy(val2,val2+3,g2->getPointer()); +// +std::vector grps(2); +grps[0]=g1; grps[1]=g2; +mm->setGroupsAtLevel(0,grps,false); +// +g2->decrRef(); +g1->decrRef(); +// +mm->write(2); + + +\endcode + +*/ + diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index 8cc256ec4..41332123e 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 : @@ -190,7 +189,7 @@ entities \c MED_CELL and \c MED_FACE (resp. \c MED_EDGE) are considered. In 1D, of course only mesh entities \c MED_CELL+ are considered. Using our naming convention (consult \ref medmem_naming), in $1$ D mesh only \b node and \b cell are considered. In 2D mesh, only \b node, \b cell and \b edge are considered. Finally in 3D mesh only -\b node}, \b cell and \b face are considered. +\b node, \b cell and \b face are considered. - The \c medGeometryElement enum which defines geometric types. The available types are linear and quadratic elements (consult @@ -232,11 +231,13 @@ 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 interpkerneldec for a \ref InterpKerRemapGlobal based on intersecting elems volume computation, +- Data Exchange Channel \ref dec, and its implementations : + - \ref interpkerneldec for a \ref InterpKerRemapGlobal based on intersecting elements 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, + - \ref overlapdec based on intersecting elems volume + computation when source and target meshes are on same process id */ @@ -276,4 +277,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..93a51d30f 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,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..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 +*/ diff --git a/doc/doxygen/static/doxygen.css b/doc/doxygen/static/doxygen.css index d8991647e..9d051a4be 100644 --- a/doc/doxygen/static/doxygen.css +++ b/doc/doxygen/static/doxygen.css @@ -1,381 +1,381 @@ -body { - font-family: Arial, Helvetica, sans-serif; - background-color: #ffffff; +/* The standard CSS for doxygen */ + +body, table, div, p, dl { + font-family: Lucida Grande, Verdana, Geneva, Arial, sans-serif; + font-size: 12px; } -h1 { - text-align: center; - text-decoration: none; - border: none; - line-height: 25px; - text-align: center; -// text-transform:uppercase; - background: #D9f4fd; - font-size: 12pt; - font-weight: bold; - border: 1px solid #CCCCCC; - -moz-border-radius: 8px; - -moz-box-shadow:5px 5px 5px rgba(0, 0, 0, 0.15); +/* @group Heading Levels */ + +h1 { + font-size: 150%; } h2 { - font-size: 12pt; - font-weight: bold; + font-size: 120%; } -table { - font-size: 10pt; +h3 { + font-size: 100%; } -CAPTION { - font-weight: bold +dt { + font-weight: bold; } -/* Link in the top navbar */ -A.qindex {} +div.multicol { + -moz-column-gap: 1em; + -webkit-column-gap: 1em; + -moz-column-count: 3; + -webkit-column-count: 3; +} -A.qindexRef {} +p.startli, p.startdd, p.starttd { + margin-top: 2px; +} -/* Link to any cross-referenced Doxygen element inside a code section - (ex: header) -*/ -A.code { - text-decoration: none; - font-weight: normal; - color: #4444ee +p.endli { + margin-bottom: 0px; } -A.codeRef { - font-weight: normal; - color: #4444ee +p.enddd { + margin-bottom: 4px; } -A:hover { - text-decoration: none; - background-color: lightblue; +p.endtd { + margin-bottom: 2px; } -div.contents { - font-family: Arial, Helvetica, sans-serif; - font-size: 10pt; +/* @end */ + +caption { + font-weight: bold; } -div.navpath { - font-size: 11pt; - border: 0 none; - text-align: left; +span.legend { + font-size: 70%; + text-align: center; } -div.version { - background-color:#ffffde; - border:1px solid #cccccc; - font-family: Arial, Helvetica, sans-serif; - font-size: 9pt; - text-align: center; - width:100px; - -moz-border-radius: 8px; -// -moz-box-shadow:5px 5px 5px rgba(0, 0, 0, 0.15); +h3.version { + font-size: 90%; + text-align: center; } -div.header { - background: url("head.png"); - background-color: #175783; - border: 1px solid; - height: 80px; - background-repeat: no-repeat; - margin-bottom: 10px; +div.qindex, div.navtab{ + background-color: #EBEFF6; + border: 1px solid #A3B4D7; + text-align: center; + margin: 2px; + padding: 2px; } -div.tabs { - text-align: justify; - margin-left : 2px; - margin-right : 2px; - margin-top : 2px; - margin-bottom : 2px - font-weight: bold; - color: #FFFFFF; -} - -div.footer { - background-color: #D9f4fd; - border: 1px solid #AAAAAA; - font-family: Arial, Helvetica, sans-serif; - font-size: 11px; - padding: 10px; - margin-top: 15px; -} - -DL.el { - margin-left: -1cm -} - -/* A code fragment (ex: header) */ -div.fragment { - border: none; -} - -/* In the alpha list (coumpound index), style of an alphabetical index letter */ -DIV.ah { - background-color: #CCCCCC; - font-weight: bold; - color: #ffffff; - margin-bottom: 3px; - margin-top: 3px -} - -/* Method name (+ type) */ -TD.md { - background-color: lightblue; - font-weight: bold; -} - -/* Method parameter (some of them) */ -TD.mdname1 { - background-color: lightblue; - font-weight: bold; color: #602020; -} - -/* Method parameter (some of them) */ -TD.mdname { - background-color: lightblue; - font-weight: bold; - color: #602020; - width: 600px; -} - -/* Separator between methods group (usually empty, seems not supported by IE) */ -DIV.groupHeader { - margin-left: 16px; - margin-top: 12px; - margin-bottom: 6px; - font-weight: bold -} - -DIV.groupText { - margin-left: 16px; - font-style: italic; - font-size: smaller -} - -/*div.div-page { - background-color: #FFFFFF; - margin-left: 1em; - margin-right: 1em; - margin-top: 1em; - margin-bottom: 0.1em; - - padding-left: 1em; - padding-right: 1em; - padding-top: 0.5em; - padding-bottom: 0.5em; - - border: 2px solid #0D299A; - border-width: 2px; - border-color: #0D299A; -}*/ - -div.tabs { - text-align: justify; - margin-left : 2px; - margin-right : 2px; - margin-top : 2px; - margin-bottom : 2px - font-weight: bold; - color: #FFFFFF; -} - -DIV.div-footer { - margin-left: 1em; - margin-right: 1em; - margin-bottom: 0.2em; - text-align: right; - font-size: 9pt; -} - -/* In File List, Coumpound List, etc, 1st column of the index */ -TD.indexkey { - background-color: #CCCCCC; - font-weight: bold; - padding-right : 10px; - padding-top : 2px; - padding-left : 10px; - padding-bottom : 2px; - margin-left : 0px; - margin-right : 0px; - margin-top : 2px; - margin-bottom : 2px -} - -/* In File List, Coumpound List, etc, 2nd column of the index */ -TD.indexvalue { - background-color: #CCCCCC; - font-style: italic; - padding-right : 10px; - padding-top : 2px; - padding-left : 10px; - padding-bottom : 2px; - margin-left : 0px; - margin-right : 0px; - margin-top : 2px; - margin-bottom : 2px -} - -span.keyword { color: #008000 } -span.keywordtype { color: #604020 } -span.keywordflow { color: #e08000 } -span.comment { color: #800000 } -span.preprocessor { color: #806020 } -span.stringliteral { color: #002080 } -span.charliteral { color: #008080 } +div.qindex, div.navpath { + width: 100%; + line-height: 140%; +} -/* @group Code Colorization */ +div.navtab { + margin-right: 15px; +} + +/* @group Link Styling */ + +a { + color: #3D578C; + font-weight: normal; + text-decoration: none; +} + +.contents a:visited { + color: #4665A2; +} + +a:hover { + text-decoration: underline; +} + +a.qindex { + font-weight: bold; +} + +a.qindexHL { + font-weight: bold; + background-color: #9CAFD4; + color: #ffffff; + border: 1px double #869DCA; +} + +.contents a.qindexHL:visited { + color: #ffffff; +} + +a.el { + font-weight: bold; +} + +a.elRef { +} + +a.code { + color: #4665A2; +} + +a.codeRef { + color: #4665A2; +} + +/* @end */ + +dl.el { + margin-left: -1cm; +} .fragment { font-family: monospace, fixed; - font-size: 10pt; + font-size: 105%; } pre.fragment { - width: 95%; - border: 1px solid #CCCCCC; - -moz-border-radius: 8px; - -moz-box-shadow:5px 5px 5px rgba(0, 0, 0, 0.15); - background-color:#EEF3F5; + border: 1px solid #C4CFE5; + background-color: #FBFCFD; padding: 4px 6px; - margin: 4px 1px 4px 1px; + margin: 4px 8px 4px 2px; + overflow: auto; + word-wrap: break-word; + font-size: 9pt; + line-height: 125%; +} + +div.ah { + background-color: black; + font-weight: bold; + color: #ffffff; + margin-bottom: 3px; + margin-top: 3px; + padding: 0.2em; + border: solid thin #333; + border-radius: 0.5em; + -webkit-border-radius: .5em; + -moz-border-radius: .5em; + box-shadow: 2px 2px 3px #999; + -webkit-box-shadow: 2px 2px 3px #999; + -moz-box-shadow: rgba(0, 0, 0, 0.15) 2px 2px 2px; + background-image: -webkit-gradient(linear, left top, left bottom, from(#eee), to(#000),color-stop(0.3, #444)); + background-image: -moz-linear-gradient(center top, #eee 0%, #444 40%, #000); +} + +div.groupHeader { + margin-left: 16px; + margin-top: 12px; + font-weight: bold; } -/* Top Navigation style */ +div.version { + border:1px solid #0000FF; + color: #CCCCCC; + font-family: Arial, Helvetica, sans-serif; + font-size: 9pt; + text-align: center; + width:100px; + -moz-border-radius: 8px; + margin: 5px; +} + +div.footer1 { + background-color: #DFE5F1; + border: 1px solid #AAAAAA; + font-family: Arial, Helvetica, sans-serif; + font-size: 11px; + padding: 10px; + margin-top: 15px; +} + + +div.groupText { + margin-left: 16px; + font-style: italic; +} -div.navigation { - margin-bottom: 70px; +body { + background: white; + color: black; + margin: 0; } -/* Left navigation panel style */ +div.contents { + margin-top: 10px; + margin-left: 10px; + margin-right: 10px; +} -body.ftvtree { - background-color: #D9f4fd; - margin: 10px; +td.indexkey { + background-color: #EBEFF6; + font-weight: bold; + border: 1px solid #C4CFE5; + margin: 2px 0px 2px 0; + padding: 2px 10px; } -div.directory { - margin: 0; +td.indexvalue { + background-color: #EBEFF6; + border: 1px solid #C4CFE5; + padding: 2px 10px; + margin: 2px 0px; } -div.directory.p { - margin: 0; +tr.memlist { + background-color: #EEF1F7; } -h3.swap { - font-size: 10pt; - margin-bottom: 0; +p.formulaDsp { + text-align: center; } -/* Link to any cross-referenced Doxygen element */ -a.el { - text-decoration: none; - font-family: Arial, Helvetica, sans-serif; - font-weight: bold; - font-size: 9pt; - color: #551a8b; +img.formulaDsp { + } -a.el:hover { - background-color: transparent; +img.formulaInl { + vertical-align: middle; } -a.elRef { - font-weight: normal; +div.center { + text-align: center; + margin-top: 0px; + margin-bottom: 0px; + padding: 0px; } +div.center img { + border: 0px; +} -#MSearchBox { - -moz-border-radius:8px 8px 8px 8px; - background-color:white; - border:1px solid #84B0C7; - margin:0; - padding:0; - white-space:nowrap; +address.footer { + text-align: right; + padding-right: 12px; } -div.directory img { - vertical-align:-30%; +img.footer { + border: 0px; + vertical-align: middle; } -div.directory p { - white-space:nowrap; - margin: 0; +/* @group Code Colorization */ + +span.keyword { + color: #008000 } -div.directory-alt div { - display: none; - margin: 0px; +span.keywordtype { + color: #604020 +} + +span.keywordflow { + color: #e08000 } +span.comment { + color: #800000 +} -div.directory div { - display: none; - margin: 0px; +span.preprocessor { + color: #806020 } -div.version { - background-color:#ffffde; - border:1px solid #cccccc; - font-family: Arial, Helvetica, sans-serif; - font-size: 9pt; - text-align: center; - width:100px; - -moz-border-radius: 8px; -// -moz-box-shadow:5px 5px 5px rgba(0, 0, 0, 0.15); -} - -/* In File List, Coumpound List, etc, 1st column of the index */ -TD.indexkey { - background-color: #DDDDEE; - font-weight: bold; - padding-right : 10px; - padding-top : 2px; - padding-left : 10px; - padding-bottom : 2px; - margin-left : 0px; - margin-right : 0px; - margin-top : 2px; - margin-bottom : 2px -} - -/* In File List, Coumpound List, etc, 2nd column of the index */ -TD.indexvalue { - background-color: #EEEEFF; - font-style: italic; - padding-right : 10px; - padding-top : 2px; - padding-left : 10px; - padding-bottom : 2px; - margin-left : 0px; - margin-right : 0px; - margin-top : 2px; - margin-bottom : 2px +span.stringliteral { + color: #002080 +} + +span.charliteral { + color: #008080 } +span.vhdldigit { + color: #ff00ff +} + +span.vhdlchar { + color: #000000 +} + +span.vhdlkeyword { + color: #700070 +} + +span.vhdllogic { + color: #ff0000 +} + +/* @end */ + +/* +.search { + color: #003399; + font-weight: bold; +} + +form.search { + margin-bottom: 0px; + margin-top: 0px; +} + +input.search { + font-size: 75%; + color: #000080; + font-weight: normal; + background-color: #e8eef2; +} +*/ + +td.tiny { + font-size: 75%; +} + +.dirtab { + padding: 4px; + border-collapse: collapse; + border: 1px solid #A3B4D7; +} + +th.dirtab { + background: #EBEFF6; + font-weight: bold; +} + +hr { + height: 0px; + border: none; + border-top: 1px solid #4A6AAA; +} + +hr.footer { + height: 1px; +} /* @group Member Descriptions */ +table.memberdecls { + border-spacing: 0px; + padding: 0px; +} + .mdescLeft, .mdescRight, .memItemLeft, .memItemRight, .memTemplItemLeft, .memTemplItemRight, .memTemplParams { - background-color: #FAFAFA; - border: none; - margin: 4px; - padding: 1px 0 0 8px; + background-color: #F9FAFC; + border: none; + margin: 4px; + padding: 1px 0 0 8px; } .mdescLeft, .mdescRight { - padding: 0px 8px 4px 8px; - color: #555; + padding: 0px 8px 4px 8px; + color: #555; } .memItemLeft, .memItemRight, .memTemplParams { - border-top: 1px solid #ccc; + border-top: 1px solid #C4CFE5; } .memItemLeft, .memTemplItemLeft { @@ -383,86 +383,448 @@ TD.indexvalue { } .memTemplParams { - color: #606060; + color: #4665A2; white-space: nowrap; } /* @end */ +/* @group Member Details */ + /* Styles for detailed member documentation */ .memtemplate { - font-size: 80%; - color: #606060; - font-weight: normal; - margin-left: 3px; + font-size: 80%; + color: #4665A2; + font-weight: normal; + margin-left: 9px; } .memnav { - background-color: #e8eef2; - border: 1px solid #84b0c7; - text-align: center; - margin: 2px; - margin-right: 15px; - padding: 2px; + background-color: #EBEFF6; + border: 1px solid #A3B4D7; + text-align: center; + margin: 2px; + margin-right: 15px; + padding: 2px; } .memitem { - padding: 0; - margin-bottom: 10px; + padding: 0; + margin-bottom: 10px; } .memname { white-space: nowrap; font-weight: bold; -} - -.memproto, .memdoc { - border: 1px solid #84b0c7; + margin-left: 6px; } .memproto { - padding: 0; - background-color: #d5e1e8; + border-top: 1px solid #A8B8D9; + border-left: 1px solid #A8B8D9; + border-right: 1px solid #A8B8D9; + padding: 6px 0px 6px 0px; + color: #253555; font-weight: bold; - -webkit-border-top-left-radius: 8px; - -webkit-border-top-right-radius: 8px; - -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); - -moz-border-radius-topleft: 8px; - -moz-border-radius-topright: 8px; + text-shadow: 0px 1px 1px rgba(255, 255, 255, 0.9); + /* opera specific markup */ + box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); + border-top-right-radius: 8px; + border-top-left-radius: 8px; + /* firefox specific markup */ -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px; + -moz-border-radius-topright: 8px; + -moz-border-radius-topleft: 8px; + /* webkit specific markup */ + -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); + -webkit-border-top-right-radius: 8px; + -webkit-border-top-left-radius: 8px; + background-image:url('nav_f.png'); + background-repeat:repeat-x; + background-color: #E2E8F2; } - - .memdoc { + border-bottom: 1px solid #A8B8D9; + border-left: 1px solid #A8B8D9; + border-right: 1px solid #A8B8D9; padding: 2px 5px; - background-color: #eef3f5; + background-color: #FBFCFD; border-top-width: 0; - -webkit-border-bottom-left-radius: 8px; - -webkit-border-bottom-right-radius: 8px; - -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); + /* opera specific markup */ + border-bottom-left-radius: 8px; + border-bottom-right-radius: 8px; + box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); + /* firefox specific markup */ -moz-border-radius-bottomleft: 8px; -moz-border-radius-bottomright: 8px; -moz-box-shadow: rgba(0, 0, 0, 0.15) 5px 5px 5px; + background-image: -moz-linear-gradient(center top, #FFFFFF 0%, #FFFFFF 60%, #F7F8FB 95%, #EEF1F7); + /* webkit specific markup */ + -webkit-border-bottom-left-radius: 8px; + -webkit-border-bottom-right-radius: 8px; + -webkit-box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.15); + background-image: -webkit-gradient(linear,center top,center bottom,from(#FFFFFF), color-stop(0.6,#FFFFFF), color-stop(0.60,#FFFFFF), color-stop(0.95,#F7F8FB), to(#EEF1F7)); } .paramkey { - text-align: right; + text-align: right; } .paramtype { - white-space: nowrap; + white-space: nowrap; } .paramname { - color: #602020; - white-space: nowrap; + color: #602020; + white-space: nowrap; } .paramname em { - font-style: normal; + font-style: normal; +} + +.params, .retval, .exception, .tparams { + border-spacing: 6px 2px; +} + +.params .paramname, .retval .paramname { + font-weight: bold; + vertical-align: top; +} + +.params .paramtype { + font-style: italic; + vertical-align: top; +} + +.params .paramdir { + font-family: "courier new",courier,monospace; + vertical-align: top; +} + + + + +/* @end */ + +/* @group Directory (tree) */ + +/* for the tree view */ + +.ftvtree { + font-family: sans-serif; + margin: 0px; +} + +/* these are for tree view when used as main index */ + +.directory { + font-size: 9pt; + font-weight: bold; + margin: 5px; +} + +.directory h3 { + margin: 0px; + margin-top: 1em; + font-size: 11pt; +} + +/* +The following two styles can be used to replace the root node title +with an image of your choice. Simply uncomment the next two styles, +specify the name of your image and be sure to set 'height' to the +proper pixel height of your image. +*/ + +/* +.directory h3.swap { + height: 61px; + background-repeat: no-repeat; + background-image: url("yourimage.gif"); +} +.directory h3.swap span { + display: none; +} +*/ + +.directory > h3 { + margin-top: 0; +} + +.directory p { + margin: 0px; + white-space: nowrap; +} + +.directory div { + display: none; + margin: 0px; +} + +.directory img { + vertical-align: -30%; +} + +/* these are for tree view when not used as main index */ + +.directory-alt { + font-size: 100%; + font-weight: bold; +} + +.directory-alt h3 { + margin: 0px; + margin-top: 1em; + font-size: 11pt; +} + +.directory-alt > h3 { + margin-top: 0; +} + +.directory-alt p { + margin: 0px; + white-space: nowrap; +} + +.directory-alt div { + display: none; + margin: 0px; +} + +.directory-alt img { + vertical-align: -30%; } /* @end */ +div.dynheader { + margin-top: 8px; +} + +address { + font-style: normal; + color: #2A3D61; +} + +table.doxtable { + border-collapse:collapse; +} + +table.doxtable td, table.doxtable th { + border: 1px solid #2D4068; + padding: 3px 7px 2px; +} + +table.doxtable th { + background-color: #374F7F; + color: #FFFFFF; + font-size: 110%; + padding-bottom: 4px; + padding-top: 5px; + text-align:left; +} + +.tabsearch { + top: 0px; + left: 10px; + height: 36px; + background-image: url('tab_b.png'); + z-index: 101; + overflow: hidden; + font-size: 13px; +} + +.navpath ul +{ + font-size: 11px; + background-image:url('tab_b.png'); + background-repeat:repeat-x; + height:30px; + line-height:30px; + color:#8AA0CC; + border:solid 1px #C2CDE4; + overflow:hidden; + margin:0px; + padding:0px; +} + +.navpath li +{ + list-style-type:none; + float:left; + padding-left:10px; + padding-right:15px; + background-image:url('bc_s.png'); + background-repeat:no-repeat; + background-position:right; + color:#364D7C; +} + +.navpath li.navelem a +{ + height:32px; + display:block; + text-decoration: none; + outline: none; +} + +.navpath li.navelem a:hover +{ + color:#6884BD; +} + +.navpath li.footer +{ + list-style-type:none; + float:right; + padding-left:10px; + padding-right:15px; + background-image:none; + background-repeat:no-repeat; + background-position:right; + color:#364D7C; + font-size: 8pt; +} + + +div.summary +{ + float: right; + font-size: 8pt; + padding-right: 5px; + width: 50%; + text-align: right; +} + +div.summary a +{ + white-space: nowrap; +} + +div.ingroups +{ + font-size: 8pt; + padding-left: 5px; + width: 50%; + text-align: left; +} + +div.ingroups a +{ + white-space: nowrap; +} + +div.header +{ + background-image:url('nav_h.png'); + background-repeat:repeat-x; + background-color: #F9FAFC; + margin: 0px; + border-bottom: 1px solid #C4CFE5; +} + +div.headertitle +{ + padding: 5px 5px 5px 10px; +} + +dl +{ + padding: 0 0 0 10px; +} + +dl.note, dl.warning, dl.attention, dl.pre, dl.post, dl.invariant, dl.deprecated, dl.todo, dl.test, dl.bug +{ + border-left:4px solid; + padding: 0 0 0 6px; +} + +dl.note +{ + border-color: #D0D000; +} + +dl.warning, dl.attention +{ + border-color: #FF0000; +} + +dl.pre, dl.post, dl.invariant +{ + border-color: #00D000; +} + +dl.deprecated +{ + border-color: #505050; +} + +dl.todo +{ + border-color: #00C0E0; +} + +dl.test +{ + border-color: #3030E0; +} + +dl.bug +{ + border-color: #C08050; +} + +#projectlogo +{ + text-align: center; + vertical-align: bottom; + border-collapse: separate; +} + +#projectlogo img +{ + border: 0px none; +} + +#projectname +{ + background-color: #175783; + border: 1px solid; + height: 80px; + background-repeat: no-repeat; +/* font: 300% arial,sans-serif;*/ + margin: 0px; + padding: 0px; +} + +#projectbrief +{ + font: 120% arial,sans-serif; + margin: 0px; + padding: 0px; +} + +#projectnumber +{ + font: 50% arial,sans-serif; + margin: 0px; + padding: 0px; +} + +#titlearea +{ + background: url("head.png"); + background-color: #175783; + border: 1px solid; + height: 80px; + background-repeat: no-repeat; + padding: 0px; + margin: 0px; + width: 100%; + border-bottom: 1px solid #5373B4; +} + diff --git a/doc/doxygen/static/footer.html b/doc/doxygen/static/footer.html index fdfb138ca..b344790a6 100755 --- a/doc/doxygen/static/footer.html +++ b/doc/doxygen/static/footer.html @@ -1,13 +1,12 @@ - - - - - -
-
-Copyright © 2007-2010 CEA/DEN, EDF R&D, OPEN CASCADE
-Copyright © 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
-
-
+
  • + + +
    +
    + Copyright © 2007-2011 CEA/DEN, EDF R&D, OPEN CASCADE
    + Copyright © 2003-2007 OPEN CASCADE, EADS/CCR, LIP6, CEA/DEN, CEDRAT, EDF R&D, LEG, PRINCIPIA R&D, BUREAU VERITAS
    +
    +
    + \ No newline at end of file diff --git a/doc/doxygen/static/header.html.in b/doc/doxygen/static/header.html.in index bcf8c48ea..9792445cb 100755 --- a/doc/doxygen/static/header.html.in +++ b/doc/doxygen/static/header.html.in @@ -1,10 +1,22 @@ - - + + - - $title - - + +$title + + + + + + + + + -
    -
    Version: @VERSION@
    \ No newline at end of file + +
    +
    Version: @VERSION@
    + +