Salome HOME
MED33 porting
[tools/medcoupling.git] / src / ParaMEDMEM / InterpKernelDEC.cxx
index 0027a853c385a04d5453ac3725759c965b278eb2..ccf6571c0b485c036abf3cbdf716845fee46b2a3 100644 (file)
@@ -1,4 +1,4 @@
-// Copyright (C) 2007-2014  CEA/DEN, EDF R&D
+// Copyright (C) 2007-2016  CEA/DEN, EDF R&D
 //
 // This library is free software; you can redistribute it and/or
 // modify it under the terms of the GNU Lesser General Public
 #include "InterpKernelDEC.hxx"
 #include "ElementLocator.hxx"
 
-namespace ParaMEDMEM
+namespace MEDCoupling
 {  
 
   /*!
-    \defgroup interpkerneldec InterpKernelDEC
+    \anchor InterpKernelDEC-det
+    \class InterpKernelDEC
 
-    \section overview Overview
+    \section InterpKernelDEC-over Overview
 
-    The InterpKernelDEC enables the \ref conservativeremapping of fields between two parallel codes. This remapping is based on the computation of intersection volumes between elements from code A and elements from code B. The computation is possible for 3D meshes, 2D meshes, and 3D-surface meshes. Dimensions must be similar for code A and code B (for instance, though it could be desirable, it is not yet possible to couple 3D surfaces with 2D surfaces).
+    The InterpKernelDEC enables the \ref InterpKerRemapGlobal "remapping" (or interpolation) of fields between
+    two parallel codes.
 
-    In the present version, only fields lying on elements are considered.
+    The projection
+    methodology is based on the algorithms of %INTERP_KERNEL, that is to say, they work in a similar fashion than
+    what the \ref remapper "sequential remapper" does. The following \ref discretization "projection methods"
+    are supported: P0->P0 (the most common case), P1->P0, P0->P1.
 
-    \image html NonCoincident_small.png "Example showing the transfer from a field based on a quadrangular mesh to a triangular mesh. In a P0-P0 interpolation, to obtain the value on a triangle, the values on quadrangles are weighted by their intersection area and summed."
+    The computation is possible for 3D meshes, 2D meshes, and 3D-surface
+    meshes. Dimensions must be identical for code A and code B (for instance, though it could be
+    desirable, it is not yet possible to couple 3D surfaces with 2D surfaces).
 
-    \image latex NonCoincident_small.eps "Example showing the transfer from a field based on a quadrangular mesh to a triangular mesh. In a P0-P0 interpolation, to obtain the value on a triangle, the values on quadrangles are weighted by their intersection area and summed."
+    The name "InterpKernelDEC" comes from the fact that this class uses exactly the same algorithms
+    as the sequential remapper. Both this class and the sequential
+    \ref MEDCoupling::MEDCouplingRemapper "MEDCouplingRemapper" are built on top of the %INTERP_KERNEL
+    algorithms (notably the computation of the intersection volumes).
+
+    Among the important properties inherited from the parent abstract class \ref DisjointDEC-det "DisjointDEC",
+    the two \ref MPIProcessorGroup-det "processor groups" (source and target) must have a void intersection.
+
+    \image html NonCoincident_small.png "Transfer of a field supported by a quadrangular mesh to a triangular mesh".
+
+    \image latex NonCoincident_small.eps "Transfer of a field supported by a quadrangular mesh to a triangular mesh"
+
+    In the figure above we see the transfer of a field based on a quadrangular mesh to a new field supported by
+    a triangular mesh. In a P0-P0 interpolation, to obtain the value on a triangle, the values on the
+    quadrangles are weighted by their intersection area and summed.
 
     A typical use of InterpKernelDEC encompasses two distinct phases :
-    - A setup phase during which the intersection volumes are computed and the communication structures are setup. This corresponds to calling the InterpKernelDEC::synchronize() method.
-    - A use phase during which the remappings are actually performed. This corresponds to the calls to sendData() and recvData() which actually trigger the data exchange. The data exchange are synchronous in the current version of the library so that recvData() and sendData() calls must be synchronized on code A and code B processor groups. 
+    - A setup phase during which the intersection volumes are computed and the communication structures are
+    setup. This corresponds to calling the InterpKernelDEC::synchronize() method.
+    - A running phase during which the projections are actually performed. This corresponds to the calls to
+    sendData() and recvData() which actually trigger the data exchange. The data exchange are synchronous
+    in the current version of the library so that recvData() and sendData() calls must be synchronized
+    on code A and code B processor groups.
 
-    The following code excerpt illutrates a typical use of the InterpKernelDEC class.
+    The following code excerpt illustrates a typical use of the InterpKernelDEC class.
 
     \code
     ...
@@ -63,12 +88,19 @@ namespace ParaMEDMEM
     dec.sendData();
     ...
     \endcode
-    A \ref conservativeremapping of the field from the source mesh to the target mesh is performed by the function synchronise(), which computes the \ref remappingmatrix.
+    A \ref InterpKerRemapGlobal "remapping" of the field from the source mesh to the target mesh is performed by
+    the function synchronise(), which computes the interpolation matrix.
 
-    Computing the field on the receiving side can be expressed in terms of a matrix-vector product : \f$ \phi_t=W.\phi_s\f$, with \f$ \phi_t \f$ the field on the target side and \f$ \phi_s \f$ the field on the source side.
-    When remapping a 3D surface to another 3D surface, a projection phase is necessary to match elements from both sides. Care must be taken when defining this projection to obtain a \ref conservative remapping.
+    Computing the field on the receiving side can be expressed in terms of a matrix-vector product :
+    \f$ \phi_t=W.\phi_s\f$, with \f$ \phi_t \f$ the field on the target side and \f$ \phi_s \f$ the field
+    on the source side.
+    When remapping a 3D surface to another 3D surface, a projection phase is necessary to match elements
+    from both sides. Care must be taken when defining this projection to obtain a
+    \ref InterpKerRemapGlobal "conservative remapping".
 
-    In the P0-P0 case, this matrix is a plain rectangular matrix with coefficients equal to the intersection areas between triangle and quadrangles. For instance, in the above figure, the matrix is :
+    In the P0-P0 case, this matrix is a plain rectangular matrix with coefficients equal to the
+    intersection areas between triangle and quadrangles. For instance, in the above figure, the matrix
+    is :
 
     \f[
     \begin{tabular}{|cccc|}
@@ -79,32 +111,29 @@ namespace ParaMEDMEM
     \end{tabular}
     \f]
 
-
-
-    \section interpkerneldec_options Options
-    On top of \ref dec_options, options supported by %InterpKernelDEC objects are
-    related to the underlying Intersector class. 
+    \section InterpKernelDEC-options Options
+    On top of the usual \ref MEDCoupling::DECOptions "DEC options", the options supported by %InterpKernelDEC objects are
+    related to the underlying \ref InterpKerIntersectors "intersector class".
     All the options available in the intersector objects are
-    available for the %InterpKernelDEC object. The various options available for  * intersectors can be reviewed in \ref InterpKerIntersectors.
+    available for the %InterpKernelDEC object. The various options available for  intersectors can
+    be reviewed in \ref InterpKerIntersectors.
  
     For instance :
     \verbatim
     InterpKernelDEC dec(source_group, target_group);
     dec.attachLocalField(field);
-    dec.setOptions("DoRotate",false);
-    dec.setOptions("Precision",1e-12);
+    dec.setDoRotate(false);
+    dec.setPrecision(1e-12);
     dec.synchronize();
     \endverbatim
 
     \warning{  Options must be set before calling the synchronize method. }
   */
-
-  /*!
-    \addtogroup interpkerneldec
-    @{
-  */
   
-  InterpKernelDEC::InterpKernelDEC():_interpolation_matrix(0)
+  InterpKernelDEC::InterpKernelDEC():
+    DisjointDEC(),
+    _nb_distant_points(0), _distant_coords(0),
+    _distant_locations(0), _interpolation_matrix(0)
   {  
   }
 
@@ -112,20 +141,32 @@ namespace ParaMEDMEM
     This constructor creates an InterpKernelDEC which has \a source_group as a working side 
     and  \a target_group as an idle side. All the processors will actually participate, but intersection computations will be performed on the working side during the \a synchronize() phase.
     The constructor must be called synchronously on all processors of both processor groups.
+    The source group and target group MUST form a partition of all the procs within the communicator passed as 'world_comm'
+    when building the group.
 
     \param source_group working side ProcessorGroup
     \param target_group lazy side ProcessorGroup
 
   */
   InterpKernelDEC::InterpKernelDEC(ProcessorGroup& source_group, ProcessorGroup& target_group):
-    DisjointDEC(source_group, target_group),_interpolation_matrix(0)
+    DisjointDEC(source_group, target_group),
+    _nb_distant_points(0), _distant_coords(0),
+    _distant_locations(0), _interpolation_matrix(0)
   {
 
   }
 
+
+  /*!
+   * Creates an InterpKernelDEC from a set of source procs IDs and target group IDs.
+   * The difference with the ctor using groups is that the set of procs might not cover entirely MPI_COMM_WORLD
+   * (a sub-communicator holding the union of source and target procs is recreated internally).
+   */
   InterpKernelDEC::InterpKernelDEC(const std::set<int>& src_ids, const std::set<int>& trg_ids,
-                                   const MPI_Comm& world_comm):DisjointDEC(src_ids,trg_ids,world_comm),
-                                                               _interpolation_matrix(0)
+                                   const MPI_Comm& world_comm):
+    DisjointDEC(src_ids,trg_ids,world_comm),
+    _nb_distant_points(0), _distant_coords(0),
+    _distant_locations(0), _interpolation_matrix(0)
   {
   }
 
@@ -138,9 +179,10 @@ namespace ParaMEDMEM
   /*! 
     \brief Synchronization process for exchanging topologies.
 
-    This method prepares all the structures necessary for sending data from a processor group to the other. It uses the mesh underlying the fields that have been set with attachLocalField method.
+    This method prepares all the structures necessary for sending data from a processor group to the other. It uses the mesh
+    underlying the fields that have been set with attachLocalField method.
     It works in four steps :
-    -# Bounding boxes are computed for each subdomain,
+    -# Bounding boxes are computed for each sub-domain,
     -# The lazy side mesh parts that are likely to intersect the working side local processor are sent to the working side,
     -# The working side calls the interpolation kernel to compute the intersection between local and imported mesh.
     -# The lazy side is updated so that it knows the structure of the data that will be sent by
@@ -272,9 +314,5 @@ namespace ParaMEDMEM
     _interpolation_matrix->getAccessDEC()->setTime(time,deltatime);
     sendData() ;
   }
-
-  /*!
-    @}
-  */
   
 }