doc/developer/doxygen/doxfiles/reference/distrib/parallel.dox

   1 /*!
   2 \page parallel Parallelism
   3
   4 \section para-over Building blocks
   5
   6 Several classes and methods are available in the MED library to ease the exchange of information
   7 in a parallel context. The DECs (\ref para-dec "detailed further down") then use those classes to enable
   8 the parallel remapping (projection) of a field.
   9 For historical reasons, all those items are in the same namespace as the non-parallel MEDCoupling functionalities,
  10 <b>%ParaMEDMEM</b>.
  11
  12 The core elements of the API are:
  13 - \ref CommInterface-det "CommInterface", this is the wrapper around the MPI library, and an instance
  14 of this object is required in many constructors of the following objects.
  15 - \ref ParaMESH-det "ParaMESH", the parallel instantiation of a \ref meshes "MEDCoupling mesh"
  16 - \ref ParaFIELD-det "ParaFIELD", the parallel instantiation of a \ref fields "MEDCoupling field"
  17 - \ref MPIProcessorGroup-det "MPIProcessorGroup" (which inherits from the abstract
  18 \ref MEDCoupling::ProcessorGroup "ProcessorGroup"), a group of processors (typically MPI nodes)
  19
  20 In an advanced usage, the topology of the nodes in the computation is accessed through the following elements:
  21 - \ref BlockTopology-det "BlockTopology", specification of a topology based on the (structured) mesh.
  22 The mesh is divided in block (typically a split along the first axis) which are allocated on the various
  23 processors.
  24 - <b> %ExplicitTopology </b> (not fully supported yet and only used internally), specification of user-defined
  25 topology, still based on the mesh.
  26 - \ref ComponentTopology-det "ComponentTopology", specification of a topology allowing the split of
  27 several field *components* among different processors. The mesh is not the support of the topology anymore.
  28
  29 \section para-dec Data Exchange Channel - DEC
  30
  31 A Data Exchange Channel (%DEC) allows the transfer and/or the interpolation (remapping) of field data between several
  32 processors in a parallel (MPI) context.
  33 Some DECs perform a simple renumbering and copy of the data, and some are capable of functionalities similar to the
  34 \ref remapper "sequential remapper".
  35
  36 We list here the main characteristics of the DECs, the list being structured in the same
  37 way as the class hierarchy:
  38
  39 - \ref DisjointDEC-det "DisjointDEC", works with two disjoint groups of processors. This is an abstract class.
  40     - \ref InterpKernelDEC-det "InterpKernelDEC", inherits the properties of the \c %DisjointDEC. The projection
  41     methodology is based on the algorithms of %INTERP_KERNEL, that is to say, they work in a similar fashion than
  42     what the \ref remapper "sequential remapper" does. The following \ref discretization "projection methods"
  43     are supported: P0->P0 (the most common case), P1->P0, P0->P1.
  44     - \ref StructuredCoincidentDEC-det "StructuredCoincidentDEC", also inherits the properties
  45     of the \c %DisjointDEC, but this one is \b not based on the %INTERP_KERNEL algorithms.
  46     This DEC does a simple data transfer between two fields having a common (coincident) structured support,
  47     but different topologies (i.e. the structured domain is split differently among the processors for the
  48     two fields). Only the cell identifiers are handled, and no kind of interpolation (in the sense of the
  49     computation of a weight matrix) is performed. It is a "mere" reallocation of data from one domain
  50     partitioning to another.
  51     - \b ExplicitCoincidentDEC : as above, but based on an explicit topology. This DEC is used internally but
  52     rarely directly in the public API.
  53 - \ref OverlapDEC-det "OverlapDEC", works with a single processor group, but each processor detains
  54 both (part of) the source and target fields. This %DEC can really be seen as the true parallelisation of the
  55 \ref remapper "sequential remapper". Similarly to the \ref InterpKernelDEC-det "InterpKernelDEC"
  56 the projection methodology is based on the algorithms of %INTERP_KERNEL, that is to say,
  57 it works in a similar fashion than what the \ref remapper "sequential remapper" does.
  58 - \b NonCoincidentDEC (deprecated for now)
  59
  60 Besides, all the DECs inherit from the class \ref MEDCoupling::DECOptions "DECOptions" which provides
  61 the necessary methods to adjust the parameters used in the transfer/remapping.
  62
  63 The most commonly used %DEC is the \c %InterpKernelDEC, and here is a simple example to of its usage:
  64
  65  \code
  66 ...
  67 InterpKernelDEC dec(groupA, groupB);   // groupA and groupB are two MPIProcessorGroup
  68 dec.attachLocalField(field);           // field is a ParaFIELD, a MEDCouplingField or an ICoCo::MEDField
  69 dec.synchronize();                     // compute the distributed interpolation matrix
  70 if (groupA.containsMyRank())
  71 dec.recvData();                        // effectively transfer the field (receiving side)
  72 else if (groupB.containsMyRank())
  73 dec.sendData();                        // effectively transfer the field (sending side)
  74 ...
  75 \endcode
  76
  77 \n
  78 \n
  79 \n
  80
  81 */