From: ndjinga Date: Tue, 4 Oct 2011 07:45:41 +0000 (+0000) Subject: Evolution of the MEDMEM library documentation, more specifically about the interpolat... X-Git-Tag: V6_main_FINAL~937 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=cf32f5ac648b838f2a4c9dae2eeafc9543ec4c8a;p=tools%2Fmedcoupling.git Evolution of the MEDMEM library documentation, more specifically about the interpolation tools --- diff --git a/doc/doxygen/Makefile.am b/doc/doxygen/Makefile.am index 7ac768450..0dbfef279 100644 --- a/doc/doxygen/Makefile.am +++ b/doc/doxygen/Makefile.am @@ -53,7 +53,9 @@ EXTRA_DIST += figures \ field.dox \ grid.dox \ interpkernel.dox \ - interpkernel_features.dox \ + interptheory.dox \ + interptools.dox \ + intersectors.dox \ medcoupling.dox \ medfilebrowser.dox \ medloader.dox \ @@ -62,9 +64,9 @@ EXTRA_DIST += figures \ mesh.dox \ meshing.dox \ polygon.dox \ - remapping.dox \ + remapper.dox \ support.dox \ tools.dox \ static/footer.html \ static/doxygen.css \ - images \ No newline at end of file + images diff --git a/doc/doxygen/figures/interpolationimage.png b/doc/doxygen/figures/interpolationimage.png new file mode 100644 index 000000000..a823f7f37 Binary files /dev/null and b/doc/doxygen/figures/interpolationimage.png differ diff --git a/doc/doxygen/figures/source_field.png b/doc/doxygen/figures/source_field.png new file mode 100755 index 000000000..d3e90df26 Binary files /dev/null and b/doc/doxygen/figures/source_field.png differ diff --git a/doc/doxygen/figures/source_mesh.png b/doc/doxygen/figures/source_mesh.png new file mode 100755 index 000000000..e10ba3d90 Binary files /dev/null and b/doc/doxygen/figures/source_mesh.png differ diff --git a/doc/doxygen/figures/target_field.png b/doc/doxygen/figures/target_field.png new file mode 100755 index 000000000..5fc892926 Binary files /dev/null and b/doc/doxygen/figures/target_field.png differ diff --git a/doc/doxygen/figures/target_mesh.png b/doc/doxygen/figures/target_mesh.png new file mode 100755 index 000000000..67b2d343c Binary files /dev/null and b/doc/doxygen/figures/target_mesh.png differ diff --git a/doc/doxygen/interpkernel.dox b/doc/doxygen/interpkernel.dox index 71db3faad..83f124b7a 100644 --- a/doc/doxygen/interpkernel.dox +++ b/doc/doxygen/interpkernel.dox @@ -1,5 +1,5 @@ /*! -\page interpkernel Interpolation tools +\page interpkernel Interpolation kernel \section InterpKerIntro Introduction @@ -15,7 +15,7 @@ the %interpolation kernel. 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 can be seen in \ref InterpKerTheory "the theory of interpolation", all the proposed interpolators aim at +As can be seen in \ref ConsInterp "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. @@ -29,7 +29,7 @@ performed in two steps : -# A filtering process reduces the number of pairs of elements for which the calculation must be carried out by 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). + -# For all remaining pairs calling for each intersector (click here for the available \ref InterpKerIntersectors). 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. @@ -84,253 +84,5 @@ As already said, the matrix returned by interpolator is typically a sparse matri Note that \c std::vector\c < \c std::map > is a candidate for \c MatrixType. -\section InterpKerGenUsage Usage of interpolation tools: the REMAPPER classes. -\subsection InterpKerHighLevUsage high-level usage - -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 \ref MEDCoupling data struture, ParaMEDMEM::MEDCouplingRemapper class should be used : - -\code -... -const char sourceFileName[]="source.med"; -MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); -const char targetFileName[]="target.med"; -MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); -// -sourceField->setNature(ConservativeVolumic);//Specify nature is needed to allow remapper object to apply correct policy for denominator computation ! -MEDCouplingRemapper remapper; -remapper.setPrecision(1e-12); -remapper.setIntersectionType(INTERP_KERNEL::Triangulation); -remapper.prepare(sourceField->getMesh(),med_target_mesh,"P0P0"); -MEDCouplingFieldDouble *targetField=remapper.transferField(sourceField,/*default_value*/4.57);//Any target cell not intercepted by any source cell will have value set to 4.57. -... -// clean-up -targetField->decrRef(); -sourceField->decrRef(); -med_target_mesh->decrRef(); -\endcode - -- If you intend to use \ref MEDMEM data structure, \c medmemremapper class should be used : - -\code -... -std::string sourceFileName("source.med"); -MEDMEM::MESH med_source_mesh(MED_DRIVER,sourceFileName,"Source_Mesh"); -std::string targetFileName("target.med"); -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,"P0P1"); -mapper.transfer(sourceField,targetField); -//use targetField -... -\endcode - -\subsection InterpKerMidLevUsage middle-level usage - -This mode is the mode that needs the minimum of prerequisites -(algorithms and the datastructure you intend to use). On the other -hand it is needed to specify precisely nature of interpolator. - -As consequence of genericity of interpolators, they are usable only by -instanciating an underneath mesh data structure. The two following -examples show how to use interpolator at this level. - -- The simplest way to use interpolator with MEDCoupling datastruture is put in the following example. Note that this code is close to those used by ParaMEDMEM -to perform synchronization of meshes between processes of a MPI communicator : - -\code -... -MEDCouplingUMesh *med_source_mesh=MEDLoader::ReadUMeshFromFile("source.med","Source_mesh",0); -MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile("target.med","Target_mesh",0); -MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_source_mesh(med_source_mesh); -MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_target_mesh(med_target_mesh); -// Go for interpolation... -INTERP_KERNEL::Interpolation2D myInterpolator; -myInterpolator.setPrecision(1e-7); -myInterpolator.setIntersectionType(INTERP_KERNEL::Geometric2D); -std::vector > resultMatrix; -INTERP_KERNEL::Matrix resultMatrix2; -// here the interpolation is performed twice for this code to show the capability of storing data of out matrix in 2 different data structures. -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2,"P0P0"); -//Ok resultMatrix and resultMatrix2 contain matrix now -... -\endcode - -- An another way to use the interpolator with MEDMEM datastructure is : - -\code -... -std::string sourceFileName("source.med"); -MEDMEM::MESH med_source_mesh(MED_DRIVER,sourceFileName,"Source_Mesh"); -std::string targetFileName("target.med"); -MEDMEM::MESH med_target_mesh(MED_DRIVER,targetFileName,"Target_Mesh"); -// Ok at this point we have our mesh in MED-Memory format. -// Go to wrap med_source_mesh and med_target_mesh. -MEDNormalizedUnstructuredMesh<2,2> wrap_source_mesh(&med_source_mesh); -MEDNormalizedUnstructuredMesh<2,2> wrap_target_mesh(&med_target_mesh); -// Go for interpolation... -INTERP_KERNEL::Interpolation2D myInterpolator; -//optionnal call to parametrize your interpolation. First precision, tracelevel, intersector wanted. -myInterpolator.setOptions(1e-7,0,Geometric2D); -INTERP_KERNEL::Matrix resultMatrix; -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); -//Ok let's multiply resultMatrix by source field to interpolate to target field. -resultMatrix.multiply(...) -... -\endcode - -- Same with VTK datastructure : - -\code -... -vtkXMLUnstructuredGridReader *readerSource=vtkXMLUnstructuredGridReader::New(); -readerSource->SetFileName("source.vtu"); -vtkUnstructuredGrid *vtk_source_mesh=readerSource->GetOutput(); -readerSource->Update(); -vtkXMLUnstructuredGridReader *readerTarget=vtkXMLUnstructuredGridReader::New(); -readerTarget->SetFileName("target.vtu"); -vtkUnstructuredGrid *vtk_target_mesh=readerTarget->GetOutput(); -readerTarget->Update(); -// Ok at this point we have our mesh in VTK format. -// Go to wrap vtk_source_mesh and vtk_target_mesh. -VTKNormalizedUnstructuredMesh<2> wrap_source_mesh(vtk_source_mesh); -VTKNormalizedUnstructuredMesh<2> wrap_target_mesh(vtk_target_mesh); -// Go for interpolation... -INTERP_KERNEL::Interpolation2D myInterpolator; -//optionnal call to parametrize your interpolation. First precision, tracelevel, intersector wanted. -myInterpolator.setOptions(1e-7,0,Geometric2D); -INTERP_KERNEL::Matrix resultMatrix; -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); -//Ok let's multiply resultMatrix by source field to interpolate to target field. -resultMatrix.multiply(...) -//clean-up -readerSource->Delete(); -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] - -*/ +*/ \ No newline at end of file diff --git a/doc/doxygen/interpkernel_features.dox b/doc/doxygen/interpkernel_features.dox deleted file mode 100644 index 10534ee69..000000000 --- a/doc/doxygen/interpkernel_features.dox +++ /dev/null @@ -1,30 +0,0 @@ -/*! -\page interpkernel_features InterpKernel features - -\section Presentation -The InterpKernel algorithms are part of the MED tool suite. They -answer to the following basic problem : given a source mesh $M_s$, a -source field $F_s$ and a target mesh $M_t$, reconstruct a field $F_t$ -that uses $M_t$ as a support. The InterpKernel suite gives a number of -possibilities to compute the target field, depending on a variety of -user constraints. - -\image html interpolation_image.png - -InterpKernel possibilities emcompass: -- 1D, 2D lines, 2D, 3D surfaces and 3D handling, -- computation via node localization or via cell intersection (for -conservative remapping), -- treatment of MPI-distributed fields and meshes, -- different APIs for different levels of integration (as SALOME -components, for MPI distributed codes, as low-level library), -- treatment of extended polygons (where edges can be arcs or segments) -for 2D intersection computations, -- management of P0, P1 and P2 fields. - -The starting point for using the tools is the description of the -diferent APIs. You can obtain this information by following this -link : \ref interpkernel. If you would like more information about the -features, you can follow the following links : \ref interpolation2D, -\ref interpolation3Dsurf, \ref interpolation3D which provide details -about the options available when using intersection algorithms. diff --git a/doc/doxygen/interptheory.dox b/doc/doxygen/interptheory.dox new file mode 100644 index 000000000..1d16d001a --- /dev/null +++ b/doc/doxygen/interptheory.dox @@ -0,0 +1,122 @@ +/*! +\page InterpKerRemapGlobal Linear 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] + +\f$W\f$ is called the \anchor interpolationmatrix interpolation matrix. +The objectives of interpolators is to compute the matrix W depending on their physical +properties (\ref IntExtFields) and their mesh discretisation (P0, P1,...). + +\section ConsInterp 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. + +It is therefore 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 +formula \anchor InterpKerGenralEq has to +be satisfied : + +\f[ +\int_{T_i} \phi_t = \sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi_s. +\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. + +\section MeshOverlap Mesh overlapping + +Another important property of the interpolation process is the maximum principle: the field values resulting from the interpolation should remain between the upper and lower bounds of the original field. +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 that is +\f[ +\sum_{S_j} Vol(T_i\cap S_j) = Vol(T_i) and \sum_{T_i} Vol(S_j\cap T_i) = Vol(S_j) +\f] +then the meshes S and T are said to be \b +overlapping and all the algorithms will return the same results. + +The ideal interpolation algorithm should be conservative and respect the maximum principle. However such an algorithm can be impossible to design if the two meshes do not overlap. When the meshes do not overlap, using either \f$Vol(T_i)\f$ or \f$\sum_{S_j} Vol(T_i\cap S_j)\f$ in the formula one obtains an algorithm that respects either conservativity either the maximum principle. + + +\section InterpKerRemapInt Linear 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 + +\section 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 = Vol(T_i).\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. + +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)}{ Vol(T_i) }. +\f] + + +\section InterpKerP0P0Ext cell-cell (P0->P0) conservative remapping of extensive fields + +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)}{ Vol(S_j)}.P_{S_j}. +\f] + +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)}{ Vol(S_j) }. +\f] + +\section TableNatureOfField Summary +In the case of fields with P0 representation, if the meshes do not overlap the scheme is either conservative or maximum preserving (not both) and depending on the prioritised property and the \ref NatureOfField the interpolation coefficients take the following value + + * + * + * + * + *
Intensive extensive
Conservation \f[\frac{Vol(T_i\cap S_j)}{ Vol(T_i)}\f]
ConservativeVolumic 		\f[ \frac{Vol(T_i\cap S_j)}{ \sum_{T_i} Vol(S_j\cap T_i) }\f]
IntegralGlobConstraint
Maximum principle \f[\frac{Vol(T_i\cap S_j)}{ \sum_{S_j} Vol(T_i\cap S_j)}\f]
RevIntegral		 \f[\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }\f]
Integral
+ + +*/ + diff --git a/doc/doxygen/interptools.dox b/doc/doxygen/interptools.dox new file mode 100644 index 000000000..b52d689c4 --- /dev/null +++ b/doc/doxygen/interptools.dox @@ -0,0 +1,28 @@ +/*! +\page interptools Interpolation tools + +\section Presentation +The InterpKernel algorithms are part of the MED tool suite. They +answer to the following basic problem : given a source mesh \f$M_s\f$, a +source field \f$F_s\f$ and a target mesh \f$M_t\f$, reconstruct a field \f$F_t\f$ +that uses \f$M_t\f$ as a support. The InterpKernel suite gives a number of +possibilities to compute the target field, depending on a variety of +user constraints. + +\image html interpolationimage.png "General interpolation scheme" width=10cm + +The starting point for using the tools is the description of the two main different APIs. +- \ref RemapperClasses "Remapper class" and the underlying \ref interpkernel library for sequential codes using \ref medcoupling fields or other data structures. +- \ref paramedmem for parallel MPI based codes using \c ParaMEDMEM distributed fields, and the algorithms of the \ref interpkernel library. + +The possibilities encompass: +- 1D, 2D lines, 2D (\ref interpolation2D), 3D surfaces(\ref interpolation3Dsurf) and 3D(\ref interpolation3D) handling, +- computation via node localization (\ref pointlocator) or via cell intersection (\ref ConsInterp), +- treatment of extended polygons (where edges can be arcs or segments) +for 2D intersection computations via \ref interpkernelGeo2D, +- management of fields with P0,P1 or P2 representations. P0<->P0, P1<->P0, P1<->P1 and P2->P0 (non conservative) interpolators are available. + +In case of non \ref MeshOverlap "overlapping meshes", it is important to specify whether the field represents an extensive or intensive physical quantity through +the \ref NatureOfField attribute of the \ref medcoupling field. + +*/ \ No newline at end of file diff --git a/doc/doxygen/intersectors.dox b/doc/doxygen/intersectors.dox new file mode 100755 index 000000000..f08f36241 --- /dev/null +++ b/doc/doxygen/intersectors.dox @@ -0,0 +1,140 @@ +/*! +\defgroup InterpKerGrpIntPlan Plannar Intersector + +Here are listed all the methods to be called or to overload to all +concrete intersector. + +\page InterpKerIntersectors Intersectors + +\section interpolation2D Special features of 2D intersectors + +\subsection InterpKerPlanarIntGenP0P0 P0->P0 : PlanarIntersector. + +All the 2D intersectors inherits from INTERP_KERNEL::PlanarIntersector class. + +All the important methods are \ref InterpKerGrpIntPlan "described here".\n To sum up the main task offered by this class is to give the +evaluation of interpolation of one cell in source mesh with an another +cell in target mesh. + +\subsection InterpKerPlanarIntFeatureP0P0 P0->P0 intersectors features. + +When remapping two dimensional fields, areas of intersection between polygonal cells are to be computed. Three algorithms are available: +- Triangle: decompose each cells into triangles and computes triangle-triangle intersection by determining segment crossings and node inclusions. This algorithm is the fastest if both meshes are made of triangular cells. +- Convex: presume that both meshes are made of convex cells, and performs a direct computation of the intersection nodes between two cells through a sweep line algorithm (see F. Preparata and M. Shamos, 1985 in \ref references). +For the moment, it is only possible to remap two dimensional fields on +meshes with mixed triangular and quadrangular elements. +- Geometric2D: Any type of 2D cells (linear, quadratic, convex-polygons, +non-convex polygons) is supported by this algorithm. Due to its +flexibility this algo is slower than the other. +- \anchor pointlocator PointLocator: This is a \b non \b conservative interpolator. For P0P0, it +locates the barycenter of target cell in the source cells. For P1P0, it +locates barycenter of target cell and compute barycentric coordinates +in source cell (Works only with trangle). For P0P1 locate target nodes +in source cells. For P1P1 compute for each target node its barycentric +coordinates in source cell. + +The following options are available for the 2D intersection computations: + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be + * used in the computation of the cell-cell intersections + * Triangle, Convex, \ref interpkernelGeo2D "Geometric2D", PointLocator Triangle
Precision Accuracy of the computations is precision times the characteristic size of the meshes positive real numbers 1.0E-12
PrintLevel Level of verboseness during the computations 0, 1, 2, 3 0
+ +\section interpolation3Dsurf Special features of 3D surface intersectors + +When remapping a three dimensional surfaces, one should give a meaning to the area of intersection between two three-dimensional non coplanar polygons. A projection phase is thus necessary to have both polygons on the same plane. Care must be taken when defining this projection to avoid non conservative remappings. After the projection step, the source and target cells lie in the same plane and the same algorithms as for 2D remapping can be employed. +For the moment, it is only possible to remap fields on three dimension surfacic meshes with mixed triangular and quadrangular elements. +Similar options as for the 2D remapping are available, plus some additional options specific to 3D surface remapping: + + * + * + * + * + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
MedianPlane Position of the median plane where both cells will be projected real numbers between 0 and 1 0.5
Precision Accuracy of the computations is + * precision times the characteristic size of the meshes + * positive real numbers 1.E-12
Orientation Specifies orientation to take into account. If -1 only negative intersection area are taken into account. If 1 only positive intersection + * area are taken into account. If 0 intersection area are always taken into account. If 2 intersection area are always taken into account (as 0) difference is that absolute value -1,0,1,2 0
DoRotate Performs a rotation of the coordinate + system such that the median plane is the Oxy plane + boolean true or false true
BoundingBoxAdjustmentWhen detecting an intersection between bounding boxes, the bounding are expanded by a factor (1+BoundingBoxAdjustment). It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. positive real numbers 1.e-4
BoundingBoxAdjustmentAbsWhen detecting an intersection between bounding boxes, the bounding are expanded uniformaly in the 3 dimension of space with the absolute value BoundingBoxAdjustmentAbs. It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. positive real numbers 0.
MaxDistance3DSurfIntersectBefore atempting an intersection in 3D surf test the distance D between fast barycenter of target cell and medium source plane P. If option < 0. no interpretation of D is done. If option > 0. then if D real numbers -1.
+ +Note that choosing the Triangle Intersection_type necessarily set the DoRotate option to true. + +\section interpolation3D Special features of 3D volumes intersectors + +\subsection InterpKer3DIntGenP0P0 P0->P0 : TargetIntersector + +Unlike \ref InterpKerPlanarIntGenP0P0 "PlanarIntersector phylosophy" +this intersector is slightly different. Here for the moment +there is one instance per pair of meshes \b and target element. See INTERP_KERNEL::TargetIntersector for +more details. + +\subsection InterpKer3DIntFeatureP0P0 P0->P0 intersectors features. + +When remapping three dimensional fields, volumes of intersection +between polyhedral cells are to be computed. +Two methods are available : +- Triangle : the method of Jeffrey Grandy, 1999 (see \ref references) +to intersect arbitrary polyhedra. The basic algorithm computes the +intersection of a tetrahedron with an arbitrary (possibly non convex) +polyhedron. Using splitting techniques, it is possible to transform +the problem of computing the intersection between two general +polyhedra into several tetrahedron-polyhedron intersection +calculations. For the moment it is only possible to remap fields on +meshes having mixed tetrahedral and hexahedral cells. When using a +mesh with hexahedral cells, several splitting techniques may be +employed depending mainly on wether the faces are planar or not. The +following options are available for the splitting: +- PointLocator : \b non \b conservative intersector based on the same +principle than described in 2D. + + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be + * used in the computation of the cell-cell intersections + * Triangle, PointLocator Triangle
SplittingPolicy Way in which the hexahedra are + * split into tetrahedra (only if Intersection_type==Triangle) PLANAR_FACE_5, PLANAR_FACE_6, GENERAL_24, GENERAL_48 GENERAL_48
PrintLevel Level of verboseness during the computations 1, 2, 3, 4, 5 0
+ +Note that a SplittingPolicy values starting with the word "PLANAR" presume that each face is to be considered planar, while the SplittingPolicy values starting with the word GENERAL does not. The integer at the end gives the number of tetrahedra that result from the split. + Consider an hexahedron with with planar faces and nodes numbered according to the following picture: +\verbatim + + 7 ------ 6 + /| /| + / | / | + 3 ------ 2 | + | | | | + | | | | + | 4-----|- 5 + | / | / + 0 ------ 1 +\endverbatim +The use of the SPLIT_NODES_5 splitting policy would lead to a 5 tetrahedra decomposition as follows : +\verbatim + 0, 1, 5, 2 + 0, 4, 5, 7 + 0, 3, 7, 2 + 5, 6, 7, 2 + 0, 2, 5, 7 +\endverbatim +The use of the SPLIT_NODES_6 splitting policy would lead to a 6 tetrahedra decomposition as follows : +\verbatim + 0, 1, 5, 6 + 0, 2, 1, 6 + 0, 5, 4, 6 + 0, 4, 7, 6 + 0, 3, 2, 6 + 0, 7, 3, 6 +\endverbatim + +*/ diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index cbc0828d7..a3d73913c 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -12,13 +12,12 @@ The install procedure of the %MEDMEM library can handle a variety of configurati to suit the needs of its user. Instructions for configuring and installing the library can be found in \ref medmem_install. \section outline Outline -This user guide contains three different chapters that covers the core %MEDMEM library, the %ParaMEDMEM library and the %MEDSPLITTER tool: +This user guide contains five different chapters that cover the core %MEDMEM and MEDCoupling libraries, the interpolation library and the associated tools: - 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 interptools 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 f5a34e77d..3a86a1bde 100644 --- a/doc/doxygen/medcoupling.dox +++ b/doc/doxygen/medcoupling.dox @@ -27,11 +27,11 @@ 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". -It exists two type of arrays : +There are two types of arrays : - double precision float array incarnated by ParaMEDMEM::DataArrayDouble class. - integer array incarnated by ParaMEDMEM::DataArrayInt class. -To know more about arrays \ref MEDCouplingArrayPage "click here for arrays documentation". +To learn more about arrays \ref MEDCouplingArrayPage "click here for arrays documentation". \section MEDCouplingMainConc Main Concepts @@ -48,7 +48,7 @@ Here we will create a mesh with spacedim==2 and meshdim==2 too with 5 cells and 9 nodes. You can notice that it is possible to mix cell -types as you want as long as the dimension of cell is exactly equal to +types as long as the dimension of cell is exactly equal to meshDim to respect \ref MEDCouplingMeshes "this rule". \code @@ -317,7 +317,7 @@ The main properties of a field are : - name - spatial support which is a \ref MEDCouplingMeshesP "mesh" - a \ref MEDCouplingSpatialDisc "spatial discretization" -- a description of intrinsic nature of the values of field. This is important for conservative interpolation. +- a description of intrinsic nature of the values of field (see \ref NatureOfField). This is important for conservative interpolation (see \ref TableNatureOfField). - a temporal discretization that specifies, if it exists, the time interval on which the field is covering, and how. - number of components @@ -556,3 +556,53 @@ Method in new to old mode that works on surjective applications : - \ref ParaMEDMEM::DataArrayDouble::selectByTupleId "DataArrayDouble::selectByTupleId" */ + +/*! + \defgroup NatureOfField Nature of a field + + \section IntExtFields Overview: intensive and extensive field + +\c NatureOfField is an enum which helps determining some physical significance of the field and affects the choice of interpolation formula ( see \ref TableNatureOfField). +It has five possible values: +- "NoNature", the default value, does not allow the use of interpolation tools +- "ConservativeVolumic", for intensive field with conservativity favored over the maximum principle +- "Integral", for extensive field with the maximum principle favored over conservativity +- "IntegralGlobConstraint", for extensive fields with conservativity favored over the maximum principle +- "RevIntegral", for intensive field with the maximum principle favored over conservativity + +By an intensive field we mean a field that represent volumetric or intensive physical variable such as density (\f$kg.m^{-3}\f$), temperature (\f$\circ K\f$) or pressure (\f$Pa\f$). +By extensive (or integral) field we mean a field that represents an extensive physical quantity sych as mass (\f$kg\f$), volume (\f$m^3\f$), a momentum (\f$kg.m.s^{-1}\f$) or power \f$(W\f$). +For fields with a P0 representation, conservativity formulas are different depending on whether the field is extensive or intensive (see \ref InterpKerP0P0Int and \ref InterpKerP0P0Ext). +In some cases such a non \ref MeshOverlap "overlapping meshes", it is impossible to fulfill both conservation and maximum principle during the interpolation. The nature of the fields determines the formula to be used for non overlapped cells and thus the property that we will be satisfied. +We consider that fields with P1 or P2 representations are necessarily intensive. + +\section Usage + +In order to employ the various \ref interptools, it is important to specify the nature of your field. +In case the sources and target meshes do not overlap different treatments will be employed, depending on the nature of the source and target fields. +You can specify the nature of the field when you create a \ref medcoupling field with the following constructor: +\code +MEDCouplingFieldDouble(NatureOfField n, MEDCouplingTimeDiscretization *td, MEDCouplingFieldDiscretization *type); +\endcode + +If you read or copy an already existing field, or later after its creation, you may want to change/set its nature. +In order to do so, you can use the function + +\code +void setNature(NatureOfField nat); +\endcode + +Here is an example + +\code +... +const char sourceFileName[]="source.med"; +MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); +const char targetFileName[]="target.med"; +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); +// +sourceField->setNature(ConservativeVolumic); +... +\endcode + +*/ \ No newline at end of file diff --git a/doc/doxygen/medloader.dox b/doc/doxygen/medloader.dox index 344a8422d..d1bb0fe29 100644 --- a/doc/doxygen/medloader.dox +++ b/doc/doxygen/medloader.dox @@ -1,5 +1,5 @@ /*! -\page medloader %MEDLoader +\page medloader MEDLoader \section MEDLoaderIntro Introduction @@ -39,7 +39,7 @@ behaviour of these two methods can vary. */ /*! -\page MEDLoaderBasicAPI Basic %MEDLoader API. +\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 diff --git a/doc/doxygen/medmem.dox b/doc/doxygen/medmem.dox index 41332123e..f0918773d 100644 --- a/doc/doxygen/medmem.dox +++ b/doc/doxygen/medmem.dox @@ -226,21 +226,37 @@ http://hammi.extra.cea.fr/static/MED/web_med/logiciels/med-2.3.1/doc/ . The ParaMEDMEM library is based on several classes that -describe the coupling between two parallel codes. +describe the coupling between two MPI-based 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 \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, + - (obsolete ?) \ref noncoincidentdec for a non-conservative interpolation based on element localization, + - (obsolete ?) \ref structuredcoincidentdec for remapping coincident meshes on a one-to-one basis. This class applies to structured topologies. + - (obsolete ?) \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 +Given two groups of processors groupA (source) and groupB (target), the following code excerpt gives a typical use of the InterpKernelDEC class. + + \code + ... + InterpKernelDEC dec(groupA, groupB);//creates the data exchange channel + dec.attachLocalField(field);//associate the local field + dec.synchronize();//builds the interpolation matrix + if (groupA.containsMyRank()) + dec.recvData();//receive the target field + else if (groupB.containsMyRank()) + dec.sendData();//send the source field + ... + \endcode +The generation of the \ref interpolationmatrix "interpolation matrix" and the corresponding matrix-vector products are performed either on the source, either on the target side. + */ + /*! \page medmem_install Configuring and Installing MEDMEM from sources diff --git a/doc/doxygen/remapper.dox b/doc/doxygen/remapper.dox new file mode 100644 index 000000000..fd20f98a4 --- /dev/null +++ b/doc/doxygen/remapper.dox @@ -0,0 +1,96 @@ + +/*! +\page RemapperClasses The REMAPPER class. + +\section InterpKerHighLevUsage High-level usage + +The simplest way of using the \ref interptools in sequential mode is to use the class \c ParaMEDMEM::MEDCouplingRemapper . This class fulfills \c HXX2SALOME rules and may be used in YACS coupling graphs. + +- If you intend to use \ref MEDCoupling data structure, ParaMEDMEM::MEDCouplingRemapper class should be used : + +\code +... +const char sourceFileName[]="source.med"; +MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); +const char targetFileName[]="target.med"; +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); +// +sourceField->setNature(ConservativeVolumic);//Specify which formula to use in case of non overlapping meshes +MEDCouplingRemapper remapper; +remapper.setPrecision(1e-12); +remapper.setIntersectionType(INTERP_KERNEL::Triangulation); +remapper.prepare(sourceField->getMesh(),med_target_mesh,"P0P0"); +MEDCouplingFieldDouble *targetField=remapper.transferField(sourceField,/*default_value*/4.57);//Any target cell not intercepted by any source cell will have value set to 4.57. +... +// clean-up +targetField->decrRef(); +sourceField->decrRef(); +med_target_mesh->decrRef(); +\endcode + +(Note that the same API can be used with \ref medmem field instead of \ref medcoupling fields using another remapper class \ref medmemremapper.) + + +\section InterpKerMidLevUsage Middle-level usage + +This mode is the mode that needs the minimum of prerequisites +(algorithms and the datastructure you intend to use). On the other +hand it is needed to specify precisely nature of interpolator. + +As consequence of the genericity of the interpolators, they are usable only by +instanciating an underlying \ref InterpKerMeshType "mesh" and \ref InterpKerMatrixType "matrix" data structure fulfilling some requirements. The two following +examples show how to use interpolator at this level. + +- The simplest way to use the interpolator with \ref medcoupling datastruture is illustrated in the following example. + +\code +... +MEDCouplingUMesh *med_source_mesh=MEDLoader::ReadUMeshFromFile("source.med","Source_mesh",0); +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile("target.med","Target_mesh",0); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_source_mesh(med_source_mesh); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_target_mesh(med_target_mesh); +// Go for interpolation... +INTERP_KERNEL::Interpolation2D myInterpolator; +myInterpolator.setPrecision(1e-7); +myInterpolator.setIntersectionType(INTERP_KERNEL::Geometric2D); +std::vector > resultMatrix; +INTERP_KERNEL::Matrix resultMatrix2; +// here the interpolation is performed twice for this code to illustrate the possibility of storing data the interpolation matrix in 2 different data structures. +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2,"P0P0"); +//Ok resultMatrix and resultMatrix2 contain matrix now +... +\endcode + + +- Same with VTK datastructure : + +\code +... +vtkXMLUnstructuredGridReader *readerSource=vtkXMLUnstructuredGridReader::New(); +readerSource->SetFileName("source.vtu"); +vtkUnstructuredGrid *vtk_source_mesh=readerSource->GetOutput(); +readerSource->Update(); +vtkXMLUnstructuredGridReader *readerTarget=vtkXMLUnstructuredGridReader::New(); +readerTarget->SetFileName("target.vtu"); +vtkUnstructuredGrid *vtk_target_mesh=readerTarget->GetOutput(); +readerTarget->Update(); +// Ok at this point we have our mesh in VTK format. +// Go to wrap vtk_source_mesh and vtk_target_mesh. +VTKNormalizedUnstructuredMesh<2> wrap_source_mesh(vtk_source_mesh); +VTKNormalizedUnstructuredMesh<2> wrap_target_mesh(vtk_target_mesh); +// Go for interpolation... +INTERP_KERNEL::Interpolation2D myInterpolator; +//optionnal call to parametrize your interpolation. First precision, tracelevel, intersector wanted. +myInterpolator.setOptions(1e-7,0,Geometric2D); +INTERP_KERNEL::Matrix resultMatrix; +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); +//Ok let's multiply resultMatrix by source field to interpolate to target field. +resultMatrix.multiply(...) +//clean-up +readerSource->Delete(); +readerTarget->Delete(); +... +\endcode + +*/ \ No newline at end of file diff --git a/doc/doxygen/remapping.dox b/doc/doxygen/remapping.dox deleted file mode 100755 index 9c0d229f1..000000000 --- a/doc/doxygen/remapping.dox +++ /dev/null @@ -1,140 +0,0 @@ -/*! -\defgroup InterpKerGrpIntPlan Plannar Intersector - -Here are listed all the methods to be called or to overload to all -concrete intersector. - -\page InterpKerIntersectors Intersectors - -\section interpolation2D Special features of 2D intersectors - -\subsection InterpKerPlanarIntGenP0P0 P0->P0 : PlanarIntersector. - -All the 2D intersectors inherits from INTERP_KERNEL::PlanarIntersector class. - -All the important methods are \ref InterpKerGrpIntPlan "described here".\n To sum up the main task offered by this class is to give the -evaluation of interpolation of one cell in source mesh with an another -cell in target mesh. - -\subsection InterpKerPlanarIntFeatureP0P0 P0->P0 intersectors features. - -When remapping two dimensional fields, areas of intersection between polygonal cells are to be computed. Three algorithms are available: -- Triangle: decompose each cells into triangles and computes triangle-triangle intersection by determining segment crossings and node inclusions. This algorithm is the fastest if both meshes are made of triangular cells. -- Convex: presume that both meshes are made of convex cells, and performs a direct computation of the intersection nodes between two cells through a sweep line algorithm (see F. Preparata and M. Shamos, 1985 in \ref references). -For the moment, it is only possible to remap two dimensional fields on -meshes with mixed triangular and quadrangular elements. -- Geometric2D: Any type of 2D cells (linear, quadratic, convex-polygons, -non-convex polygons) is supported by this algorithm. Due to its -flexibility this algo is slower than the other. -- PointLocator: This is \b non \b conservative interpolator. For P0P0, it -locate the barycenter of target cell in the source cells. For P1P0, it -locates barycenter of target cell and compute barycentric coordinates -in source cell (Works only with trangle). For P0P1 locate target nodes -in source cells. For P1P1 compute for each target node its barycentric -coordinates in source cell. - -The following options are available for the 2D intersection computations: - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be - * used in the computation of the cell-cell intersections - * Triangle, Convex, \ref interpkernelGeo2D "Geometric2D", PointLocator Triangle
Precision Accuracy of the computations is precision times the characteristic size of the meshes positive real numbers 1.0E-12
PrintLevel Level of verboseness during the computations 0, 1, 2, 3 0
- -\section interpolation3Dsurf Special features of 3D surface intersectors - -When remapping a three dimensional surfaces, one should give a meaning to the area of intersection between two three-dimensional non coplanar polygons. A projection phase is thus necessary to have both polygons on the same plane. Care must be taken when defining this projection to avoid non conservative remappings. After the projection step, the source and target cells lie in the same plane and the same algorithms as for 2D remapping can be employed. -For the moment, it is only possible to remap fields on three dimension surfacic meshes with mixed triangular and quadrangular elements. -Similar options as for the 2D remapping are available, plus some additional options specific to 3D surface remapping: - - * - * - * - * - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
MedianPlane Position of the median plane where both cells will be projected real numbers between 0 and 1 0.5
Precision Accuracy of the computations is - * precision times the characteristic size of the meshes - * positive real numbers 1.E-12
Orientation Specifies orientation to take into account. If -1 only negative intersection area are taken into account. If 1 only positive intersection - * area are taken into account. If 0 intersection area are always taken into account. If 2 intersection area are always taken into account (as 0) difference is that absolute value -1,0,1,2 0
DoRotate Performs a rotation of the coordinate - system such that the median plane is the Oxy plane - boolean true or false true
BoundingBoxAdjustmentWhen detecting an intersection between bounding boxes, the bounding are expanded by a factor (1+BoundingBoxAdjustment). It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. positive real numbers 1.e-4
BoundingBoxAdjustmentAbsWhen detecting an intersection between bounding boxes, the bounding are expanded uniformaly in the 3 dimension of space with the absolute value BoundingBoxAdjustmentAbs. It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. positive real numbers 0.
MaxDistance3DSurfIntersectBefore atempting an intersection in 3D surf test the distance D between fast barycenter of target cell and medium source plane P. If option < 0. no interpretation of D is done. If option > 0. then if D real numbers -1.
- -Note that choosing the Triangle Intersection_type necessarily set the DoRotate option to true. - -\section interpolation3D Special features of 3D volumes intersectors - -\subsection InterpKer3DIntGenP0P0 P0->P0 : TargetIntersector - -Unlike \ref InterpKerPlanarIntGenP0P0 "PlanarIntersector phylosophy" -this intersector is slightly different. Here for the moment -there is one instance per pair of meshes \b and target element. See INTERP_KERNEL::TargetIntersector for -more details. - -\subsection InterpKer3DIntFeatureP0P0 P0->P0 intersectors features. - -When remapping three dimensional fields, volumes of intersection -between polyhedral cells are to be computed. -Two methods are available : -- Triangle : the method of Jeffrey Grandy, 1999 (see \ref references) -to intersect arbitrary polyhedra. The basic algorithm computes the -intersection of a tetrahedron with an arbitrary (possibly non convex) -polyhedron. Using splitting techniques, it is possible to transform -the problem of computing the intersection between two general -polyhedra into several tetrahedron-polyhedron intersection -calculations. For the moment it is only possible to remap fields on -meshes having mixed tetrahedral and hexahedral cells. When using a -mesh with hexahedral cells, several splitting techniques may be -employed depending mainly on wether the faces are planar or not. The -following options are available for the splitting: -- PointLocator : \b non \b conservative intersector based on the same -principle than described in 2D. - - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be - * used in the computation of the cell-cell intersections - * Triangle, PointLocator Triangle
SplittingPolicy Way in which the hexahedra are - * split into tetrahedra (only if Intersection_type==Triangle) PLANAR_FACE_5, PLANAR_FACE_6, GENERAL_24, GENERAL_48 GENERAL_48
PrintLevel Level of verboseness during the computations 1, 2, 3, 4, 5 0
- -Note that a SplittingPolicy values starting with the word "PLANAR" presume that each face is to be considered planar, while the SplittingPolicy values starting with the word GENERAL does not. The integer at the end gives the number of tetrahedra that result from the split. - Consider an hexahedron with with planar faces and nodes numbered according to the following picture: -\verbatim - - 7 ------ 6 - /| /| - / | / | - 3 ------ 2 | - | | | | - | | | | - | 4-----|- 5 - | / | / - 0 ------ 1 -\endverbatim -The use of the SPLIT_NODES_5 splitting policy would lead to a 5 tetrahedra decomposition as follows : -\verbatim - 0, 1, 5, 2 - 0, 4, 5, 7 - 0, 3, 7, 2 - 5, 6, 7, 2 - 0, 2, 5, 7 -\endverbatim -The use of the SPLIT_NODES_6 splitting policy would lead to a 6 tetrahedra decomposition as follows : -\verbatim - 0, 1, 5, 6 - 0, 2, 1, 6 - 0, 5, 4, 6 - 0, 4, 7, 6 - 0, 3, 2, 6 - 0, 7, 3, 6 -\endverbatim - -*/