From: ndjinga Date: Fri, 22 Apr 2011 11:04:55 +0000 (+0000) Subject: Updated the doxygen documentation X-Git-Tag: EndWorkDidier~36 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=9db3ff5d69b255c7418d4401eb3730d36c8ef309;p=tools%2Fmedcoupling.git Updated the doxygen documentation --- diff --git a/src/ParaMEDMEM/DisjointDEC.cxx b/src/ParaMEDMEM/DisjointDEC.cxx index c3a92b451..67d0cf004 100644 --- a/src/ParaMEDMEM/DisjointDEC.cxx +++ b/src/ParaMEDMEM/DisjointDEC.cxx @@ -37,16 +37,16 @@ * * Interface class for creation of a link between two * processor groups for exhanging mesh or field data. - * The DEC is defined by attaching a field on the receiving or on the + * The \c DEC is defined by attaching a field on the receiving or on the * sending side. - * On top of attaching a ParaMEDMEM::FIELD, it is possible to + * On top of attaching a \c ParaMEDMEM::FIELD, it is possible to * attach a ICoCo::Field. This class is an abstract class that enables * coupling of codes that respect the ICoCo interface \ref icoco. It has two implementations: - * one for codes that express their fields as MEDCoupling fields (ICoCo::MEDField) and one + * one for codes that express their fields as \ref medoupling fields (ICoCo::MEDField) and one * for codes that express their fields as Trio/U fields. * * \section dec_options DEC Options - * Options supported by DEC objects are + * Options supported by \c DEC objects are * * * @@ -54,7 +54,7 @@ *
OptionDescriptionDefault value
- The following code excerpt shows how to set options for an object that inherits from DEC : + The following code excerpt shows how to set options for an object that inherits from \c DEC : \code InterpKernelDEC dec(source_group,target_group); diff --git a/src/ParaMEDMEM/NonCoincidentDEC.cxx b/src/ParaMEDMEM/NonCoincidentDEC.cxx index 2ff66ca3c..38d318531 100644 --- a/src/ParaMEDMEM/NonCoincidentDEC.cxx +++ b/src/ParaMEDMEM/NonCoincidentDEC.cxx @@ -45,8 +45,7 @@ namespace ParaMEDMEM \c NonCoincidentDEC enables nonconservative remapping of fields between two parallel codes. The computation is possible for 3D meshes and 2D meshes. - It is not available for 3D surfaces. The computation enables fast parallel localization, based on the - FVM library. The computation is based on a point in element search, followed + It is not available for 3D surfaces. The computation enables fast parallel localization, and is based on a point in element search, followed by a field evaluation at the point location. Thus, it is typically faster than the \ref interpkerneldec which gives a \ref conservativeremapping. It is particularly true for the initialisation phase (synchronize) @@ -246,7 +245,7 @@ namespace ParaMEDMEM @{ */ - /*! Constructor of a non coincident DEC with + /*! Constructor of a non coincident \ref dec with * a source group on which lies a field lying on a mesh and a * target group on which lies a mesh. * diff --git a/src/ParaMEDMEM/OverlapDEC.cxx b/src/ParaMEDMEM/OverlapDEC.cxx index 4ac0dfdf0..576de5b05 100644 --- a/src/ParaMEDMEM/OverlapDEC.cxx +++ b/src/ParaMEDMEM/OverlapDEC.cxx @@ -25,54 +25,52 @@ #include "OverlapInterpolationMatrix.hxx" /*! \defgroup overlapdec OverlapDEC - The OverlapDEC enables the \ref InterpKerRemapGlobal "conservative remapping" of fields between two parallel codes. This remapping is based on the computation of intersection volumes on a \b same \b processor \b group. On this processor group is defined a field template defined on A and an another on B. The computation is possible for 3D meshes, 2D meshes, 3D-surface meshes, 1D meshes and 2D-curve meshes. Dimensions must be similar for code A and code B. - The main difference with \ref interpkerneldec is that this DEC manage 2 field-templates on each process in processor group A and B called in code source and target. - Furthermore all process in process group cooperates in global interpolation matrix computation. In this sense InterpKernelDEC is a specialization of OverlapDEC. + The \c OverlapDEC enables the \ref InterpKerRemapGlobal "conservative remapping" of fields between two parallel codes. This remapping is based on the computation of intersection volumes on a \b same \b processor \b group. On this processor group are defined two field-templates called A and B. The computation is possible for 3D meshes, 2D meshes, 3D-surface meshes, 1D meshes and 2D-curve meshes. Dimensions must be similar for the distribution templates A and B. + The main difference with \ref interpkerneldec is that this \ref dec manages 2 field templates on each processor of the processor group (A and B) called source and target. + Furthermore all processors in processor group cooperates in global interpolation matrix computation. In this respect \ref InterpKernelIDEC is a specialization of \c OverlapDEC. \section ParaMEDMEMOverlapDECAlgorithmDescription Algorithm Description - Let's consider the following use case that is ran in ParaMEDMEMTest_OverlapDEC.cxx to describes the different steps in computation. Processor group contains 3 processors. + Let's consider the following use case that is ran in ParaMEDMEMTest_OverlapDEC.cxx to describes the different steps of the computation. The processor group contains 3 processors. \anchor ParaMEDMEMOverlapDECImgTest1 - \image html OverlapDEC1.png "Example showing the use case to explain the different steps." + \image html OverlapDEC1.png "Example showing the use case in order to explain the different steps." \subsection ParaMEDMEMOverlapDECAlgoStep1 Step 1 : Bounding box exchange and global interaction between procs computation. - In order to reduce as fas as possible number of exchange among processors every procs computes a bounding box for A and B. Then a AllToAll is performed so that - every procs can compute the \b global interactions between procs. - This computation leads every procs to compute the same global TODO list expressed as a list of pair. A pair (x,y) means that proc \b x fieldtemplate A can interacts (because bounding boxes interacts) with fieltemplate B of proc \b y. + In order to reduce as much as possible the amount of communications between distant processors, every processor computes a bounding box for A and B. Then a AllToAll communication is performed so that + every processor can compute the \b global interactions between processor. + This computation leads every processor to compute the same global TODO list expressed as a list of pair. A pair (x,y) means that proc \b x fieldtemplate A can interact with fieltemplate B of proc \b y because the two bounding boxes interact. In the \ref ParaMEDMEMOverlapDECImgTest1 "example above" this computation leads to the following a \b global TODO list : \b (0,0),(0,1),(1,0),(1,2),(2,0),(2,1),(2,2) - Here pair (0,2) does not appear because bounding box of fieldtemplateA of proc#2 does not interact with proc#0 of fieldtemplate B. + Here the pair (0,2) does not appear because the bounding box of fieldtemplateA of proc#2 does not intersect that of fieldtemplate B on proc#0. Stage performed by ParaMEDMEM::OverlapElementLocator::computeBoundingBoxes. \subsection ParaMEDMEMOverlapDECAlgoStep2 Step 2 : Computation of local TODO list - Starting from global interaction previously computed in \ref ParaMEDMEMOverlapDECAlgoStep1 "Step 1", each proc computes the TODO list per proc. - The following rules is chosen : a pair (x,y) can be treated by either proc #x or proc #y, in order to reduce the amount of data transfert accross - procs. The algorithm chosen for loadbalancing is the following : Each proc as an empty \b local TODO list at the beginning. The for each pair (k,m) in - \b global TODO list if proc#k has less temporary local list than proc#m pair (k,m) is added to temparary local TODO list of proc#k. - If proc#m has less temporary local TODO list than proc#k pair (k,m) is added to temparary local TODO list of proc#m. - If proc#k and proc#m have the same amount of temporary local TODO list pair (k,m) is added to temparary local TODO list of proc#k. + Starting from the global interaction previously computed in \ref ParaMEDMEMOverlapDECAlgoStep1 "Step 1", each proc computes the TODO list per proc. + The following rules is chosen : a pair (x,y) can be treated by either proc #x or proc #y, in order to reduce the amount of data transfert among + processors. The algorithm chosen for load balancing is the following : Each processor has an empty \b local TODO list at the beginning. Then for each pair (k,m) in + \b global TODO list, if proc#k has less temporary local list than proc#m pair, (k,m) is added to temparary local TODO list of proc#k. + If proc#m has less temporary local TODO list than proc#k pair, (k,m) is added to temporary local TODO list of proc#m. + If proc#k and proc#m have the same amount of temporary local TODO list pair, (k,m) is added to temporary local TODO list of proc#k. - In the \ref ParaMEDMEMOverlapDECImgTest1 "example above" this computation leads to the following a local TODO list : + In the \ref ParaMEDMEMOverlapDECImgTest1 "example above" this computation leads to the following local TODO list : - proc#0 : (0,0) - proc#1 : (0,1),(1,0) - proc#2 : (1,2),(2,0),(2,1),(2,2) - - Stage performed by ParaMEDMEM::OverlapElementLocator::computeBoundingBoxes too. - The algorithm described here is not perfect for this use case. It will be enhanced soon, I hope. + The algorithm described here is not perfect for this use case, we hope to enhance it soon. - At this stage each proc knows precisely its \b local TODO list (at interpolation sense). The \b local TODO list of other procs than local - is kept for future computation. + At this stage each proc knows precisely its \b local TODO list (with regard to interpolation). The \b local TODO list of other procs than local + is kept for future computations. \subsection ParaMEDMEMOverlapDECAlgoStep3 Step 3 : Matrix echange between procs - At this step knows its \b local TODO list, the aim now is to exchange field-templates between procs. Each proc computes knowing TODO list per + Knowing the \b local TODO list, the aim now is to exchange field-templates between procs. Each proc computes knowing TODO list per proc computed in \ref ParaMEDMEMOverlapDECAlgoStep2 "Step 2" the exchange TODO list : In the \ref ParaMEDMEMOverlapDECImgTest1 "example above" the exchange TODO list gives the following results : @@ -89,33 +87,31 @@ - proc #1 : receiving fieldtemplate A from Proc#0, receiving fieldtemplate B from Proc#0 - proc #2 : receiving fieldtemplate B from Proc#0, receiving fieldtemplate A from Proc#1, receiving fieldtemplate B from Proc#1 - To avoid as far as possible big amount of exchange between procs only relevant part of mesh. For a proc#k sending fieldtemplate A to fieldtemplate B - of proc #m. In this case proc#k computes part of mesh A in boundingbox B of proc#m. It implies that the corresponding cellIds or nodeIds of + To avoid as much as possible large volumes of transfers between procs, only relevant parts of meshes are sent. In order for proc#k to send fieldtemplate A to fieldtemplate B + of proc #m., proc#k computes the part of mesh A contained in the boundingbox B of proc#m. It implies that the corresponding cellIds or nodeIds of the corresponding part are sent to proc #m too. - Let's consider the couple (k,m) in TODO list. This couple is treated by either k or m as seen \ref ParaMEDMEMOverlapDECAlgoStep2 "here in Step2". + Let's consider the couple (k,m) in the TODO list. This couple is treated by either k or m as seen in \ref ParaMEDMEMOverlapDECAlgoStep2 "here in Step2". - As it will be dealt in Step 6, at the end for final matrix-vector computation the result matrix of the couple (k,m) anywhere it is computed (proc #k or proc #m) - it will be stored in \b proc#m. + As will be dealt in Step 6, for final matrix-vector computations, the resulting matrix of the couple (k,m) whereever it is computed (proc #k or proc #m) + will be stored in \b proc#m. - - If proc #k is in charge (performs matrix computation) of this couple (k,m) target ids (cells or nodes) of mesh in proc #m are renumbered, because proc #m has stripped - its target mesh to avoid big amount of data to transfer. In this case as it is finally proc #m in charge finally of the matrix, proc #k must keep preciously the - source ids needed to be sent to proc#m. No problem will appear for matrix assembling in proc m, for source ids because no restriction done. - Concerning source ids to be sent for matrix-vector computation, proc k will known precisely which source ids field values to send to proc #m. - This is incarnated by OverlapMapping::keepTracksOfTargetIds in proc m. + - If proc #k is in charge (performs the matrix computation) for this couple (k,m), target ids (cells or nodes) of the mesh in proc #m are renumbered, because proc #m has seelected a sub mesh of the target mesh to avoid large amounts of data to transfer. In this case as proc #m is ultimately in charge of the matrix, proc #k must keep preciously the + source ids needed to be sent to proc#m. No problem will appear for matrix assembling in proc m for source ids because no restriction was done. + Concerning source ids to be sent for the matrix-vector computation, proc k will know precisely which source ids field values to send to proc #m. + This is embodied by OverlapMapping::keepTracksOfTargetIds in proc m. - - If proc #m is in charge (performs matrix computation) of this couple (k,m) source ids (cells or nodes) of mesh in proc #k are renumbered, because proc #k has stripped - its source mesh to avoid big amount of data to transfer. In this case as it is finally proc #m in charge finally of the matrix, proc #m receive the source ids - from remote proc #k so the matrix is directly OK, no need of renumbering will be needed in \ref ParaMEDMEMOverlapDECAlgoStep5 "Step 5". But proc k must - keep tracks of sent ids to proc m for matrix-vector computation. + - If proc #m is in charge (performs matrix computation) for this couple (k,m), source ids (cells or nodes) of the mesh in proc #k are renumbered, because proc #k has selected a sub mesh of the source mesh to avoid large amounts of data to transfer. In this case as proc #k is ultimately in charge of the matrix, proc #m receives the source ids + from remote proc #k, and thus the matrix is directly correct, no need for renumbering as in \ref ParaMEDMEMOverlapDECAlgoStep5 "Step 5". However proc #k must + keep track of the ids sent to proc #m for te matrix-vector computation. This is incarnated by OverlapMapping::keepTracksOfSourceIds in proc k. This step is performed in ParaMEDMEM::OverlapElementLocator::exchangeMeshes method. - \subsection ParaMEDMEMOverlapDECAlgoStep4 Step 4 : The interpolation matrix computation + \subsection ParaMEDMEMOverlapDECAlgoStep4 Step 4 : Computation of the interpolation matrix - After mesh exchange in \ref ParaMEDMEMOverlapDECAlgoStep3 "Step3" each proc has all information to perform its \b local TODO list computed in - \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". This step is so potentially CPU costly. That's why the \b local TODO list per proc is expected to + After mesh exchange in \ref ParaMEDMEMOverlapDECAlgoStep3 "Step3" each processor has all the required information to treat its \b local TODO list computed in + \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". This step is potentially CPU costly, which is why the \b local TODO list per proc is expected to be as well balanced as possible. The interpolation is performed as \ref ParaMEDMEM::MEDCouplingRemapper "Remapper" does. @@ -124,30 +120,30 @@ \subsection ParaMEDMEMOverlapDECAlgoStep5 Step 5 : Global matrix construction. - After having performed the TODO list at the end of \ref ParaMEDMEMOverlapDECAlgoStep4 "Step4" it is needed to assemble the final matrix. + After having performed the TODO list at the end of \ref ParaMEDMEMOverlapDECAlgoStep4 "Step4" we need to assemble the final matrix. - The final aim is to have a distributed matrix \f$ M_k \f$ on each proc#k. In order to reduce data exchange during matrix product process. + The final aim is to have a distributed matrix \f$ M_k \f$ on each proc#k. In order to reduce data exchange during the matrix product process, \f$ M_k \f$ is built using sizeof(Proc group) \c std::vector< \c std::map \c >. - For a proc#k, it is necessary to fetch info of all matrix built in \ref ParaMEDMEMOverlapDECAlgoStep4 "Step4" where the first element in pair + For a proc#k, it is necessary to fetch info of all matrices built in \ref ParaMEDMEMOverlapDECAlgoStep4 "Step4" where the first element in pair (i,j) is equal to k. - After this step, the matrix repartition is the following after call ParaMEDMEM::OverlapMapping::prepare : + After this step, the matrix repartition is the following after a call to ParaMEDMEM::OverlapMapping::prepare : - proc#0 : (0,0),(1,0),(2,0) - proc#1 : (0,1),(2,1) - proc#2 : (1,2),(2,2) - Tuple (2,1) computed on proc 2 is stored at the end of "prepare" in proc 1. So it is an example of item 0 in \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". - Tuple (0,1) computed on proc 1 and stored in proc 1 too. So it is an example of item 1 in \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". + Tuple (2,1) computed on proc 2 is stored in proc 1 after execution of the function "prepare". This is an example of item 0 in \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". + Tuple (0,1) computed on proc 1 is stored in proc 1 too. This is an example of item 1 in \ref ParaMEDMEMOverlapDECAlgoStep2 "Step2". - In ParaMEDMEM::OverlapMapping::_proc_ids_to_send_vector_st will contain : + In the end ParaMEDMEM::OverlapMapping::_proc_ids_to_send_vector_st will contain : - Proc#0 : 0,1 - Proc#1 : 0,2 - Proc#2 : 0,1,2 - In ParaMEDMEM::OverlapMapping::_proc_ids_to_recv_vector_st will contain : + In the end ParaMEDMEM::OverlapMapping::_proc_ids_to_recv_vector_st will contain : - Proc#0 : 0,1,2 - Proc#1 : 0,2 diff --git a/src/ParaMEDMEM/StructuredCoincidentDEC.cxx b/src/ParaMEDMEM/StructuredCoincidentDEC.cxx index bd9368225..71845ba3b 100644 --- a/src/ParaMEDMEM/StructuredCoincidentDEC.cxx +++ b/src/ParaMEDMEM/StructuredCoincidentDEC.cxx @@ -43,12 +43,12 @@ namespace ParaMEDMEM 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 DEC can be used for fields that have component topologies, + Also, this \ref 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 - NonCoincidentDEC and InterpKernelDEC. Therefore, this DEC must not be used + \ref NonCoincidentDEC and \ref InterpKernelDEC. Therefore, this \ref dec must not be used for coincident meshes that do not have the same numbering. As all the other DECs, its use is made of two phases : @@ -58,7 +58,7 @@ namespace ParaMEDMEM - a send/recv phase during which the field data is actually transferred. This example illustrates the sending of a field with - the DEC : + the \c StructuredCoincidentDEC : \code ... StructuredCoincidentDEC dec(groupA, groupB);