+++ /dev/null
-/*!
-\page parallel Parallelism
-
-\section para-over Building blocks
-
-Several classes and methods are available in the MED library to ease the exchange of information
-in a parallel context. The DECs (\ref para-dec "detailed further down") then use those classes to enable
-the parallel remapping (projection) of a field.
-For historical reasons, all those items are in the same namespace as the non-parallel MEDCoupling functionalities,
-<b>%ParaMEDMEM</b>.
-
-The core elements of the API are:
-- \ref CommInterface-det "CommInterface", this is the wrapper around the MPI library, and an instance
-of this object is required in many constructors of the following objects.
-- \ref ParaMESH-det "ParaMESH", the parallel instantiation of a \ref meshes "MEDCoupling mesh"
-- \ref ParaFIELD-det "ParaFIELD", the parallel instantiation of a \ref fields "MEDCoupling field"
-- \ref MPIProcessorGroup-det "MPIProcessorGroup" (which inherits from the abstract
-\ref MEDCoupling::ProcessorGroup "ProcessorGroup"), a group of processors (typically MPI nodes)
-
-In an advanced usage, the topology of the nodes in the computation is accessed through the following elements:
-- \ref BlockTopology-det "BlockTopology", specification of a topology based on the (structured) mesh.
-The mesh is divided in block (typically a split along the first axis) which are allocated on the various
-processors.
-- <b> %ExplicitTopology </b> (not fully supported yet and only used internally), specification of user-defined
-topology, still based on the mesh.
-- \ref ComponentTopology-det "ComponentTopology", specification of a topology allowing the split of
-several field *components* among different processors. The mesh is not the support of the topology anymore.
-
-\section para-dec Data Exchange Channel - DEC
-
-A Data Exchange Channel (%DEC) allows the transfer and/or the interpolation (remapping) of field data between several
-processors in a parallel (MPI) context.
-Some DECs perform a simple renumbering and copy of the data, and some are capable of functionalities similar to the
-\ref remapper "sequential remapper".
-
-We list here the main characteristics of the DECs, the list being structured in the same
-way as the class hierarchy:
-
-- \ref DisjointDEC-det "DisjointDEC", works with two disjoint groups of processors. This is an abstract class.
- - \ref InterpKernelDEC-det "InterpKernelDEC", inherits the properties of the \c %DisjointDEC. 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.
- - \ref StructuredCoincidentDEC-det "StructuredCoincidentDEC", also inherits the properties
- of the \c %DisjointDEC, but this one is \b not based on the %INTERP_KERNEL algorithms.
- This DEC does a simple data transfer between two fields having a common (coincident) structured support,
- but different topologies (i.e. the structured domain is split differently among the processors for the
- two fields). Only the cell identifiers are handled, and no kind of interpolation (in the sense of the
- computation of a weight matrix) is performed. It is a "mere" reallocation of data from one domain
- partitioning to another.
- - \b ExplicitCoincidentDEC : as above, but based on an explicit topology. This DEC is used internally but
- rarely directly in the public API.
-- \ref OverlapDEC-det "OverlapDEC", works with a single processor group, but each processor detains
-both (part of) the source and target fields. This %DEC can really be seen as the true parallelisation of the
-\ref remapper "sequential remapper". Similarly to the \ref InterpKernelDEC-det "InterpKernelDEC"
-the projection methodology is based on the algorithms of %INTERP_KERNEL, that is to say,
-it works in a similar fashion than what the \ref remapper "sequential remapper" does.
-- \b NonCoincidentDEC (deprecated for now)
-
-Besides, all the DECs inherit from the class \ref MEDCoupling::DECOptions "DECOptions" which provides
-the necessary methods to adjust the parameters used in the transfer/remapping.
-
-The most commonly used %DEC is the \c %InterpKernelDEC, and here is a simple example to of its usage:
-
- \code
-...
-InterpKernelDEC dec(groupA, groupB); // groupA and groupB are two MPIProcessorGroup
-dec.attachLocalField(field); // field is a ParaFIELD, a MEDCouplingField or an ICoCo::MEDField
-dec.synchronize(); // compute the distributed interpolation matrix
-if (groupA.containsMyRank())
-dec.recvData(); // effectively transfer the field (receiving side)
-else if (groupB.containsMyRank())
-dec.sendData(); // effectively transfer the field (sending side)
-...
-\endcode
-
-\n
-\n
-\n
-
-*/
