Various fixes for test runs - introducing MEDCOUPLING_RESOURCE_DIR env variable

[tools/medcoupling.git] / src / ParaMEDMEM / StructuredCoincidentDEC.cxx

diff --git a/src/ParaMEDMEM/StructuredCoincidentDEC.cxx b/src/ParaMEDMEM/StructuredCoincidentDEC.cxx
index 36454c959ff4b84b676dbca7c5ef1788da0500a3..9408c267eae27b432e6bcafbc05debb1dbc64e78 100644 (file)
--- a/src/ParaMEDMEM/StructuredCoincidentDEC.cxx
+++ b/src/ParaMEDMEM/StructuredCoincidentDEC.cxx
@@ -1,4 +1,4 @@
-// Copyright (C) 2007-2019  CEA/DEN, EDF R&D
+// Copyright (C) 2007-2020  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
@@ -34,60 +34,6 @@ using namespace std;
 namespace MEDCoupling
 {
 
-  /*!
-    \anchor StructuredCoincidentDEC-det
-    \class StructuredCoincidentDEC
-
-    This class aims at \ref interpolation "remapping fields" that have identical
-    structured supports (=the same underlying mesh) but different parallel topologies
-    (=different sub-domains in the structured mesh). It can be used to couple
-    together multi-physics codes that operate on the same domain
-    with different partitioning. This can be useful for example if one of
-    the computation is much faster than the other. It can also be used
-    to couple together codes that share an interface that was generated
-    in the same manner (with identical global ids).
-    Also, this \ref para-dec "DEC" can be used for fields that have component topologies,
-    i.e., components that are scattered over several processors.
-
-    The remapping between the two supports is based on identity of global
-    ids, instead of geometrical considerations (as it is the case for
-    \ref InterpKernelDEC-det "InterpKernelDEC").
-    Therefore, beware that this \ref para-dec "DEC" can not be used
-    for coincident meshes if they do *not* have the exact same numbering.
-
-    With this %DEC no projection, and no interpolation of the field data is done, contrary
-    to what happens in \ref InterpKernelDEC-det "InterpKernelDEC". It is just
-    a matter of allocating the values from one side to the other, using directly the cell
-    identifiers.
-
-    As all the other DECs, its usage requires two phases :
-    - a setup phase during which the topologies are exchanged so that
-    the target side knows from which processors it should expect
-    the data.
-    - a send/recv phase during which the field data is actually transferred.
-
-    This example illustrates the sending of a field with
-    the \c StructuredCoincidentDEC :
-    \code
-    ...
-    StructuredCoincidentDEC dec(groupA, groupB);
-    dec.attachLocalField(field);
-    dec.synchronize();
-    if (groupA.containsMyRank())
-    dec.recvData();
-    else if (groupB.containsMyRank())
-    dec.sendData();
-    ...
-    \endcode
-
-    Creating a ParaFIELD to be attached to the %DEC is done in exactly the same way as for
-    the other DECs, if only the partitioning of the support mesh differs.
-    In the case where the
-    fields have also different *component* topologies, creating the ParaFIELD
-    requires some more effort. See the \ref para-over "parallelism" section for more details.
-  */
-
-
   StructuredCoincidentDEC::StructuredCoincidentDEC():_topo_source(0),_topo_target(0),
                                                      _send_counts(0),_recv_counts(0),
                                                      _send_displs(0),_recv_displs(0),