MEDCouplingRefCountObject.* \
MEDCouplingAutoRefCountObjectPtr.* \
MEDCouplingMemArray.* \
+ MEDCouplingGaussLocalization.* \
MEDCouplingRemapper.* \
MEDLoader.* \
MEDFileData.* \
The underlying mesh of \b f2 contains a newly created mesh with 3 cells (not as \b mesh1 in \b f1) and 9 nodes (as \b mesh1 in \b f1).
\n For fields on cells the number of tuples of the returned field is always equal to the number of ids given in input (here \b part1).
-\nOnly fields on cells have this particular behaviour.
+\n
+Only fields on cells have this particular behaviour.
<br><h3>Creation of a sub part of a field on nodes</h3>
\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_3
After the call of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" on node field \b f1, \b f1 will be reduced on a
submesh of \b mesh1 containing cells whose ids are in \b part2. So here the number of cells of \b f2 is 2 and the number of nodes is 4.
-\nSo contrary to fields on cells, it is normal for fields on nodes that number of tuples of the returned field of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart"
+\n
+So contrary to fields on cells, it is normal for fields on nodes that number of tuples of the returned field of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart"
method does not match the size of the input array (here \b part2).
We create a 2D vector field with 2 tuples and we want to transform this
field using an expression using
-\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(const char *func) "applyFunc()".
+\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int, const std::string&) "applyFunc()".
The expression \b func is applied to each atomic value of the \b field. We want to change
the \b field as follows. (In \b func, we use the variable "v" to refer to an atomic field value).
- Component #0 = component #0 (remains the same); hence "IVec * v" in \b func.
We create a 2D vector field with 2 values (vectors) and then we transform this
field into a 3D vector field by applying an expression to values of the 2D field
using
-\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const char *func) "applyFunc2()".
+\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const std::string&) "applyFunc2()".
Note that we set component info the \b array ("a" and "b" ) which will be used to refer to
corresponding components within a function.
The expression \b func is applied to components of each vector of the \b field. We want
We create a 2D vector field with 2 values (vectors) and then we transform this
field into a 3D vector field by applying an expression to values of the 2D field
using
-\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, const char *func) "applyFunc()".
+\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, const std::string& func) "applyFunc()".
The expression \b func is applied to components of each vector of the \b field. We want
the \b field to have 3 components computed as follows. (In \b func, we refer to the
first component of a field value using the variable "a", and to the second component, using
First, we create a 2D Cartesian mesh constituted by 2 cells.
\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_1
Now we create a field on cells and use
-\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const char *func) "fillFromAnalytic()"
+\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const std::string& func) "fillFromAnalytic()"
to fill it
with values computed using an expression \b func. This expression is applied to coordinates of
each point (barycenter) for which the field value is computed. We want the \b field to have
\subsubsection cpp_mcfield_remapper_middlelevel Using interpolation tools - Middle level usage
-- The simplest way to use the interpolator with \ref medcoupling data struture is illustrated in the following example.
+- The simplest way to use the interpolator with \ref medcoupling "MEDCoupling data struture" is illustrated in the following example.
\code
...
\section Questions
-General questions
+\ref faq-general
-# \ref f-newbie
-# \ref f-mehsf
-# \ref f-constel
-# \ref f-p0p1
-# \ref f-number
-MEDCoupling scripts in Python
+\ref faq-python
-# \ref f-hellow
-# \ref f-pyimport
-# \ref f-meshscratch
-# \ref f-groups
-# \ref f-unstruc
-Projection, interpolation, remapping
- -# How to project a field from one mesh to the other
- -# Which formula are used in the field projection algorithms
- -# How does this algorithm work
+\ref faq-interp
+ -# \ref f-proj
+ -# \ref f-proj-formula
-C++ specific questions
- -# Is there some coding guidelines that I should follow
- -# My C++ program produces a SIGSEGV, what should I do
+\ref faq-cpp
+ -# \ref f-cpp-guide
+ -# \ref f-cpp-segfault
-\section Answers
-\subsection f-newbie "I am a complete newbie, where should I start?"
+\section Answers
+\subsection faq-general General questions
+\subsubsection f-newbie "I am a complete newbie, where should I start?"
Take a look at the \ref start "getting started" section and the \ref tutorial.
-\subsection f-mehsf "What is a mesh, what is a field?"
+\subsubsection f-mehsf "What is a mesh, what is a field?"
Take a look at \ref terminology
-\subsection f-constel "What is a the difference between MED file, MEDCoupling and the SALOME MED module?"
+\subsubsection f-constel "What is a the difference between MED file, MEDCoupling and the SALOME MED module?"
Take a look at \ref library
-\subsection f-visu "How can I visualize a mesh and/or a field?"
+\subsubsection f-visu "How can I visualize a mesh and/or a field?"
Use the PARAVIS module of SALOME to visualize your MED file. The following dedicated fitlers have been
written specifically for MED files: Extract group, Extract cell types, ELNO Mesh, ELNO Points, ELNO Surface.
-\subsection f-p0p1 "What does a P0- (or P1-) field mean?"
+\subsubsection f-p0p1 "What does a P0- (or P1-) field mean?"
Take a look at \ref terminology
-\subsection f-number "What does surjective/old-2-new/new-2-old format mean?"
+\subsubsection f-number "What does surjective/old-2-new/new-2-old format mean?"
Take a look at \ref numbering
-
-
-
-\subsection f-hellow "Can you show me a simple example to get me started"
+\subsection faq-python MEDCoupling scripts in Python
+\subsubsection f-hellow "Can you show me a simple example to get me started"
TODO
-\subsection f-pyimport "When trying to execute my Python script I have 'ImportError: No module named MEDCoupling'"
+\subsubsection f-pyimport "When trying to execute my Python script I have 'ImportError: No module named MEDCoupling'"
Check that the environment variables PYTHONPATH and LD_LIBRARY_PATH (PATH under Windows) are correctly set.
If you have a full SALOME installation, use the 'shell' command that will automatically set up everything as it
should be:
export LD_LIBRARY_PATH=<install_root>/lib/salome
\endcode
-\subsection f-meshscratch "How to build a mesh from scratch"
+\subsubsection f-meshscratch "How to build a mesh from scratch"
Take a look at this example: \ref medcouplingpyexamplesUmeshStdBuild1
-\subsection f-fieldscratch "How to build a field from scratch"
+\subsubsection f-fieldscratch "How to build a field from scratch"
Take a look at this example: \ref medcouplingpyexamplesFieldDoubleBuild1
-\subsection f-io "How to write/read a mesh to/from a file"
+\subsubsection f-io "How to write/read a mesh to/from a file"
For starter, take a look at the \ref MEDLoaderBasicAPIPage "basic MEDLoader API".
-\subsection f-coher "How to control the validity of my mesh"
+\subsubsection f-coher "How to control the validity of my mesh"
Use the methods \ref ParaMEDMEM::MEDCouplingUMesh::checkCoherency() "MEDCouplingUMesh::checkCoherency()" or
\ref ParaMEDMEM::MEDCouplingUMesh::checkCoherency1() "MEDCouplingUMesh::checkCoherency1()"
-\subsection f-groups "How can I read/write groups on a mesh"
+\subsubsection f-groups "How can I read/write groups on a mesh"
Take a look at \ref AdvMEDLoaderAPIMeshReading and \ref AdvMEDLoaderAPIMeshWriting.
-\subsection f-unstruc "How can I transform a structured mesh into an unstructured one"
+\subsubsection f-unstruc "How can I transform a structured mesh into an unstructured one"
Use the method \ref ParaMEDMEM::MEDCouplingCMesh::buildUnstructured() "MEDCouplingCMesh::buildUnstructured()"
+\subsection faq-interp Projection, interpolation, remapping
+\subsubsection f-proj How to project a field from one mesh to the other
+This the job of the interpolation algorithms in the MED library. For starters, take a look at the
+\ref interpolation "general introduction on interpolation". Also
+\ref cpp_mcfield_remapper_highlevel "this simple example" gives a good first illustration.
+Finally, if you are intereseted in parallel projection (C++ only!), you should take a
+look at the \ref para-dec "DEC".
+
+\subsubsection f-proj-formula Which formula are used in the field projection algorithms
+The documentation for non \ref glossary "P0 field" (i.e. non \ref glossary "cell-based fields") is still an
+on-going work, but for the P0->P0 case, \ref InterpKerRemapGlobal "this page" gives a good overview.
+
+\subsection faq-cpp C++ specific questions
+\subsubsection f-cpp-guide Is there some coding guidelines that I should follow
+Yes. Please:
+- document your code (this is true for Python too!)
+- write some tests (this is true for Python too!)
+- and finally, take a look at the page \ref cpp
+
+\subsubsection f-cpp-segfault My C++ program produces a SIGSEGV, what should I do
+Re-compile in debug mode (with \c CMAKE_BUILD_TYPE=Debug), and use either valgrind or gdb
+to spot the place where the segfault happens.
+The most common source of mistake is some memory mis-allocation and/or deallocation.
+With this respect using the auto pointer class
+\ref ParaMEDMEM::MEDCouplingAutoRefCountObjectPtr "MEDCouplingAutoRefCountObjectPtr"
+can be of great help.
+
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
\n
\n
\n
\n
\n
\n
+\n
+\n
+
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+\n
+
*/
\ No newline at end of file
\subsection MEDCouplingArrayApplyFunc0 applyFunc method with only one parameter
This method produces a newly allocated DataArrayDouble instance having exactly the same number of components **and** number of tuples than the instance on which the
-\ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method is applied.
+\ref ParaMEDMEM::DataArrayDouble::applyFunc(const std::string &, bool) const applyFunc method is applied.
**This method is useful when the evaluation expression do not need to consider the components of each tuple separately**.
-That's why this method of \ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method with one parameter accepts at most only one variable.
+That's why this method of \ref ParaMEDMEM::DataArrayDouble::applyFunc(const std::string &, bool) const applyFunc method with one parameter accepts at most only one variable.
If it is not the case an exception is thrown as seen here :
As the example shows, the output \c d1 has 2 components as \c d.
-Whereas all the components of the input of \c d be not considered separately, it is also, possible with \ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method with one parameter
+Whereas all the components of the input of \c d be not considered separately, it is also, possible with \ref ParaMEDMEM::DataArrayDouble::applyFunc(const std::string &, bool) const applyFunc method with one parameter
to build an output having same number of components than input but where components in input are treated separately.
Let's build an example using DataArrayDouble instance \c d defined just above.
\subsection MEDCouplingArrayApplyFunc1 applyFunc method with only two parameters
-This method also returns a newly allocated DataArrayDouble instance having the same number of tuples than the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called, but the contrary to previous \ref MEDCouplingArrayApplyFunc0 "applyFunc with one parameter version" here the number of components is set by the user.
+This method also returns a newly allocated DataArrayDouble instance having the same number of tuples than the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const std::string &, bool) const applyFunc method is called, but the contrary to previous \ref MEDCouplingArrayApplyFunc0 "applyFunc with one parameter version" here the number of components is set by the user.
The big difference with \ref MEDCouplingArrayApplyFunc0 "applyFunc method with one parameter" seen above is that here components of tuples are treated separately.
-The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const here.
+The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const std::string &, bool) const here.
-Here the number of variables appearing in the expression should be equal at most to the number of component of the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called.
+Here the number of variables appearing in the expression should be equal at most to the number of component of the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const std::string &, bool) const applyFunc method is called.
Let's consider the following DataArrayDouble having 4 tuples with 3 components called dd.
Considering the previous warning, let's try to perform an application of function to compute in a DataArrayDouble instance called \c dd2 starting by adding component #0 and component #2
of \c dd.
-\nThe expression \c "a+c" will add component #0 to component #1 as seen in warning section !!!! It can appear silly, but this strategy has been chosen in order to support different set of variables.
+\n
+The expression \c "a+c" will add component #0 to component #1 as seen in warning section !!!! It can appear silly, but this strategy has been chosen in order to support different set of variables.
\n \ref ParaMEDMEM::DataArrayDouble::applyFunc2 "applyFunc2" and \ref ParaMEDMEM::DataArrayDouble::applyFunc3 "applyFunc3" methods have been developed to remedy to that feature that can be surprising.
\n These two methods are explained respectively \ref MEDCouplingArrayApplyFunc2 "here for applyFunc2" and \ref MEDCouplingArrayApplyFunc3 "here for applyFunc3".
-Whatever it is possible to find a workaround using \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc with 2 parameters.
+Whatever it is possible to find a workaround using \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const std::string &, bool) const applyFunc with 2 parameters.
\n Here is a solution to compute \c dd2 :
\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_6
- \ref ParaMEDMEM::MEDCouplingFieldDouble::getNumberOfComponents "getNumberOfComponents"
- \ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn"
- \ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc "applyFunc"
-- \ref ParaMEDMEM::MEDCouplingFieldDouble::addFields "cross instances operations"
+- \ref ParaMEDMEM::MEDCouplingFieldDouble::AddFields "cross instances operations"
\section MEDCouplingSpatialDisc Spatial discretization concept
This is the concept that makes the link, independently from temporal
\subsection interpkernelGeo2DNamingConv Naming conventions
- - An \ref INTERP_KERNEL::AbstractEdge "edge" is defined by a start
+ - An \ref INTERP_KERNEL::Edge "edge" is defined by a start
node, a end node and a curve equation (linear or arc of
circle). \b WARNING : start node and end node \b HAVE \b TO \b BE
different and distant at least equal to precision set.
closed. Closed means that the start node of first edge is equal to end
node of last edge.\n
A \ref INTERP_KERNEL::ComposedEdge "composed edge" is considered as a
-collection of \ref INTERP_KERNEL::AbstractEdge "abstract edges". An
-\ref INTERP_KERNEL::AbstractEdge "abstract edge" is either an \ref
+collection of \ref INTERP_KERNEL::Edge "abstract edges". An
+\ref INTERP_KERNEL::Edge "abstract edge" is either an \ref
INTERP_KERNEL::ElementaryEdge "elementary edge" or itself a \ref
INTERP_KERNEL::ComposedEdge "composed edge".\n A composite pattern has
been used here.
For fields with a P0 representation (cell based), conservativity formulas are different depending on whether the field is extensive or intensive (see \ref InterpKerP0P0Int and \ref InterpKerP0P0Ext).<br>
These two notions are themselves split into two sub-categories.
Indeed in some cases (e.g. non \ref MeshOverlap "overlapping meshes"), it is impossible to fulfill both the conservation principle and the maximum principle during the interpolation. The nature of the fields determines the formula to be used for non overlapping cells and thus the property that we will be satisfied.
-Finally we consider that fields with P1 or P2 representations are necessarily intensive.
+
+<b>Finally we consider that fields with P1 or P2 representations are necessarily intensive.</b>
\section Usage
In order to use the various \ref intro-interp "interpolations", you have to specify the nature of your field.
When the source and target meshes do not overlap, different treatments will be employed depending on the nature of the source and target fields.
-You can specify the nature of the field when you create a \ref medcoupling field with the following constructor:
+You can specify the nature of the field when you create a \ref fields "MEDCoupling field"
+with the following constructor:
\code
MEDCouplingFieldDouble(NatureOfField n, MEDCouplingTimeDiscretization *td, MEDCouplingFieldDiscretization *type);
\endcode
- \subpage remapper
- \subpage InterpKerIntersectors
+If you are looking for a parallel utilisation of the above, take a look at:
+
+- \ref parallel
+
Some implementation details of the C++ code can be found in appendix:
- \ref interpkernel
/*!
-\page InterpKerRemapGlobal Detailed explanations for P0 fields
+\page InterpKerRemapGlobal Detailed explanations for cell-based (P0) fields
For fields with polynomial representation on each cell, the components of the discretized field \f$ \phi_s \f$ on the source side can be expressed as linear combinations of the components of the discretized field \f$ \phi_t \f$ on the target side, in terms of a matrix-vector product:
The simplest way of using the \ref intro-interp "interpolations" in sequential mode is to use the class \c ParaMEDMEM::MEDCouplingRemapper . This class fulfills \c HXX2SALOME rules and may be used in YACS coupling graphs.
-If you intend to use \ref MEDCoupling data structure, ParaMEDMEM::MEDCouplingRemapper class should be used.
+If you intend to use \ref medcoupling "MEDCoupling data structures", the ParaMEDMEM::MEDCouplingRemapper class should be used.
\if ENABLE_EXAMPLES
Here is a \ref cpp_mcfield_remapper_highlevel "C++ example".
- compliant with \ref glossary "code coupling":
- fields data structure containing enough information to perform a well defined interpolation
- data structure exchangeable through processes, as well in \ref parallel "parallel" (SPMD paradigm -
- \ref library "sometimes called ParaMEDMEM"), as in a \ref distrib-corba "distributed paradigm" (using CORBA).
+ \ref library "sometimes called ParaMEDMEM"), as in a \ref corba-distrib "distributed paradigm" (using CORBA).
- minimize as much as possible the number of external software prerequisites needed to use it (the core of the
library, MEDCoupling, can be built as a standalone tool).
- light and agile enough to:
[TOC]
-This method is much closer to MED file organization than \ref
-MEDLoaderBasicAPI "basic MEDLoader API". All MED file
+This method is much closer to MED file organization than the \ref
+MEDLoaderBasicAPIPage "basic MEDLoader API". All MED file
concepts are exposed to the user. As a consequence, this advanced
API is meant to evolve with MED file data model enhancement.
\section MEDLoaderIntro Introduction
\ref medloader "MEDLoader" is a package in charge of loading from a file or write to a file
-in MED format a \ref medcoupling data structure. The fact that these
-functionalities are not merged in \ref medcoupling is explained by a
-willingness of reducing as much as possible the dependencies of \ref medcoupling libraries.
+in MED format a \ref medcoupling "MEDCoupling data structure". The fact that these
+functionalities are not merged in the \ref library "MEDCoupling library" is explained by a
+willingness of reducing as much as possible the dependencies of this library.
-As a MED file can combine several \ref medcoupling aspects in one (for example meshes in
-MED file on different mesh dimension with families and groups) the API
+As a MED file can combine several \ref medcoupling "MEDCoupling" aspects in one (for example meshes in
+MED file on more than one dimensions with families and groups) the API
of \ref medloader "MEDLoader" is much more rich than simply read and write.
\ref meshes "MEDCoupling mesh" is \b not as rich as a MED file mesh, and a \ref MEDCouplingFieldsPage "MEDCoupling field" is \b not as rich as a MED file field.
\ref MEDLoaderBasicAPIPage "A specific page dedicated to the basic API is available here".
-This approach is less close to MED file concepts, but closer to \ref MEDCouplingMainConc "MEDCoupling concepts".
+This approach is less close to MED file concepts, but closer to \ref medcoupling "MEDCoupling concepts".
So, basic API is simpler, as shown by method MEDLoader::WriteUMesh that needs no special knowledge about MED file concepts to interact with MED files.
- MED_POLYHED -> mesh dimension=3
- MED_TETRA4 -> mesh dimension=3
-The mesh dimension of \a myMesh is equal to 3 ( \f max(2,0,3,3) ). The **relative mesh dimension** is equal to the difference between mesh dimension of geometric type and the mesh dimension
+The mesh dimension of \a myMesh is equal to 3 ( \c max(2,0,3,3) ). The **relative mesh dimension** is equal to the difference between mesh dimension of geometric type and the mesh dimension
of the whole MED file dimension. It leads to the following **relative mesh dimension** :
- MED_TRI3 -> **relative mesh dimension** = -1
SET(_DOXY2SWIG ${PROJECT_SOURCE_DIR}/doc/user/doxygen/doxy2swig/doxy2swig.py)
SET(_SWIG_DOC_SUFFIX "doc_class_")
+
+
#
# MEDCoupling classes to include
#
MEDCouplingFieldDouble::accumulate(double *res) const;
MEDCouplingFieldDouble::accumulate(int compId) const;
MEDCouplingFieldDouble::advancedRepr() const;
-MEDCouplingFieldDouble::applyFunc(const char *func);
+MEDCouplingFieldDouble::applyFunc(const std::string &func);
MEDCouplingFieldDouble::applyFunc(int nbOfComp, FunctionToEvaluate func);
-MEDCouplingFieldDouble::applyFunc(int nbOfComp, const char *func);
+MEDCouplingFieldDouble::applyFunc(int nbOfComp, const std::string &func);
MEDCouplingFieldDouble::applyFunc(int nbOfComp, double val);
-MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const char *func);
-MEDCouplingFieldDouble::applyFunc3(int nbOfComp, const std::vector<std::string>& varsOrder, const char *func);
+MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const std::string &func);
+MEDCouplingFieldDouble::applyFunc3(int nbOfComp, const std::vector<std::string>& varsOrder, const std::string &func);
MEDCouplingFieldDouble::applyLin(double a, double b, int compoId);
MEDCouplingFieldDouble::buildNewTimeReprFromThis(TypeOfTimeDiscretization td, bool deepCopy) const;
MEDCouplingFieldDouble::buildSubPart(const DataArrayInt *part) const;
MEDCouplingFieldDouble::eigenValues() const;
MEDCouplingFieldDouble::eigenVectors() const;
MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, FunctionToEvaluate func);
-MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const char *func);
-MEDCouplingFieldDouble::fillFromAnalytic2(int nbOfComp, const char *func);
-MEDCouplingFieldDouble::fillFromAnalytic3(int nbOfComp, const std::vector<std::string>& varsOrder, const char *func);
+MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const std::string &func);
+MEDCouplingFieldDouble::fillFromAnalytic2(int nbOfComp, const std::string &func);
+MEDCouplingFieldDouble::fillFromAnalytic3(int nbOfComp, const std::vector<std::string>& varsOrder, const std::string &func);
MEDCouplingFieldDouble::getArray() const;
MEDCouplingFieldDouble::getArray();
MEDCouplingFieldDouble::getAverageValue() const;
MEDCouplingFieldDouble::MEDCouplingFieldDouble(TypeOfField type, TypeOfTimeDiscretization td);
MEDCouplingFieldDouble::MEDCouplingFieldDouble(const MEDCouplingFieldDouble& other, bool deepCopy);
MEDCouplingFieldDouble::MEDCouplingFieldDouble(const MEDCouplingFieldTemplate& ft, TypeOfTimeDiscretization td);
-MEDCouplingFieldDouble::applyFuncFast32(const char *func);
-MEDCouplingFieldDouble::applyFuncFast64(const char *func);
+MEDCouplingFieldDouble::applyFuncFast32(const std::string &func);
+MEDCouplingFieldDouble::applyFuncFast64(const std::string &func);
MEDCouplingFieldDouble::areCompatibleForDiv(const MEDCouplingField *other) const;
MEDCouplingFieldDouble::areCompatibleForMeld(const MEDCouplingFieldDouble *other) const;
MEDCouplingFieldDouble::areCompatibleForMerge(const MEDCouplingField *other) const;
/*! \name Others... */
///@{
-DataArray::getHeapMemorySize() const;
+DataArray::getHeapMemorySizeWithoutChildren() const;
DataArray::copyPartOfStringInfoFrom(const DataArray& other, const std::vector<int>& compoIds);
DataArray::copyPartOfStringInfoFrom2(const std::vector<int>& compoIds, const DataArray& other);
DataArray::areInfoEqualsIfNotWhy(const DataArray& other, std::string& reason) const;
* \warning This method performs no check of validity of new ids. **Use it with care !**
* \param [in] newNodeNumbersO2N - a permutation array, of length \a
* this->getNumberOfNodes(), in "Old to New" mode.
- * See \ref MEDCouplingArrayRenumbering for more info on renumbering modes.
+ * See \ref numbering for more info on renumbering modes.
* \throw If the nodal connectivity of cells is not defined.
*/
void MEDCoupling1SGTUMesh::renumberNodesInConn(const int *newNodeNumbersO2N)
* \warning This method performs no check of validity of new ids. **Use it with care !**
* \param [in] newNodeNumbersO2N - a permutation array, of length \a
* this->getNumberOfNodes(), in "Old to New" mode.
- * See \ref MEDCouplingArrayRenumbering for more info on renumbering modes.
+ * See \ref numbering for more info on renumbering modes.
* \throw If the nodal connectivity of cells is not defined.
*/
void MEDCoupling1DGTUMesh::renumberNodesInConn(const int *newNodeNumbersO2N)
* problem.
* \param [in] locId - the id of the Gauss localization object of interest.
* It must be in range <em> 0 <= locId < getNbOfGaussLocalization() </em>.
- * \return \ref MEDCouplingGaussLocalization & - the Gauss localization object.
+ * \return \ref ParaMEDMEM::MEDCouplingGaussLocalization "MEDCouplingGaussLocalization" & - the
+ * Gauss localization object.
* \throw If \a this field is not on Gauss points.
* \throw If \a locId is not within the valid range.
* \throw If the spatial discretization of \a this field is NULL.
* \warning This method is const, so the returned object is not apt for modification.
* \param [in] locId - the id of the Gauss localization object of interest.
* It must be in range <em> 0 <= locId < getNbOfGaussLocalization() </em>.
- * \return \ref const MEDCouplingGaussLocalization & - the Gauss localization object.
+ * \return const \ref MEDCouplingGaussLocalization & - the Gauss localization object.
* \throw If \a this field is not on Gauss points.
* \throw If \a locId is not within the valid range.
* \throw If the spatial discretization of \a this field is NULL.
/*!
* Returns number of components in the data array. For more info on the data arrays,
- * see \ref MEDCouplingArrayPage.
+ * see \ref arrays.
* \return int - the number of components in the data array.
* \throw If the data array is not set.
*/
* So \b this \b method \b behaves \b exactly \b as MEDCouplingField::getNumberOfTuplesExpected \b method.
*
* \warning No checkCoherency() is done here.
- * For more info on the data arrays, see \ref MEDCouplingArrayPage.
+ * For more info on the data arrays, see \ref arrays.
* \return int - the number of tuples.
* \throw If the mesh is not set.
* \throw If the spatial discretization of \a this field is NULL.
/*!
* Returns number of atomic double values in the data array of \a this field.
- * For more info on the data arrays, see \ref MEDCouplingArrayPage.
+ * For more info on the data arrays, see \ref arrays.
* \return int - (number of tuples) * (number of components) of the
* data array.
* \throw If the data array is not set.
* This method adds at the end of \a this a serie of values [\c valsBg,\c valsEnd). This method do \b not update its time label to avoid useless incrementation
* of counter. So the caller is expected to call TimeLabel::declareAsNew on \a this at the end of the push session.
*
- * \param [in] valsBg - an array of values to push at the end of \this.
+ * \param [in] valsBg - an array of values to push at the end of \c this.
* \param [in] valsEnd - specifies the end of the array \a valsBg, so that
* the last value of \a valsBg is \a valsEnd[ -1 ].
* \throw If \a this has already been allocated with number of components different from one.
/*!
* Permutes values of \a this array as required by \a old2New array. The values are
* permuted so that \c new[ \a old2New[ i ]] = \c old[ i ]. Number of tuples remains
- * the same as in \this one.
+ * the same as in \c this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
*/
/*!
* Permutes values of \a this array as required by \a new2Old array. The values are
* permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of tuples remains
- * the same as in \this one.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * the same as in \c this one.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
* \return DataArrayDouble * - the new instance of DataArrayDouble that the caller
/*!
* Returns a copy of \a this array with values permuted as required by \a old2New array.
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ].
- * Number of tuples in the result array remains the same as in \this one.
+ * Number of tuples in the result array remains the same as in \c this one.
* If a permutation reduction is needed, renumberAndReduce() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
* \return DataArrayDouble * - the new instance of DataArrayDouble that the caller
/*!
* Returns a copy of \a this array with values permuted as required by \a new2Old array.
* The values are permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of
- * tuples in the result array remains the same as in \this one.
+ * tuples in the result array remains the same as in \c this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
* \return DataArrayDouble * - the new instance of DataArrayDouble that the caller
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ] for all
* \a old2New[ i ] >= 0. In other words every i-th tuple in \a this array, for which
* \a old2New[ i ] is negative, is missing from the result array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old tuple and giving negative position for
* for i-th old tuple that should be omitted.
* The values are permuted so that \c new[ i ] = \c old[ \a new2OldBg[ i ]].
* This method is equivalent to renumberAndReduce() except that convention in input is
* \c new2old and \b not \c old2new.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* \c new2old and \b not \c old2new.
* This method is equivalent to selectByTupleId() except that it prevents coping data
* from behind the end of \a this array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* command \c range( \a bg, \a end2, \a step ).
* This method is equivalent to selectByTupleIdSafe() except that the input array is
* not constructed explicitly.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] bg - index of the first tuple to copy from \a this array.
* \param [in] end2 - index of the tuple before which the tuples to copy are located.
* \param [in] step - index increment to get index of the next tuple to copy.
/*!
* Returns a shorten copy of \a this array. The new DataArrayDouble contains ranges
* of tuples specified by \a ranges parameter.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] ranges - std::vector of std::pair's each of which defines a range
* of tuples in [\c begin,\c end) format.
* \return DataArrayDouble * - the new instance of DataArrayDouble that the caller
* \throw If \a this is not allocated.
* \throw If parameters specifying tuples and components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarraydouble_setpartofvaluessimple1 "Here is a Python example".
* defined by <em>(bgComp,endComp,stepComp)</em>.
* \throw If parameters specifying components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarraydouble_setpartofvalues3 "Here is a Python example".
* \a this array.
* \throw If parameters specifying components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarraydouble_setpartofvaluessimple3 "Here is a Python example".
* This method adds at the end of \a this a serie of values [\c valsBg,\c valsEnd). This method do \b not update its time label to avoid useless incrementation
* of counter. So the caller is expected to call TimeLabel::declareAsNew on \a this at the end of the push session.
*
- * \param [in] valsBg - an array of values to push at the end of \this.
+ * \param [in] valsBg - an array of values to push at the end of \c this.
* \param [in] valsEnd - specifies the end of the array \a valsBg, so that
* the last value of \a valsBg is \a valsEnd[ -1 ].
* \throw If \a this has already been allocated with number of components different from one.
* Creates a one-dimensional DataArrayInt of given length, whose contents are computed
* from values of \a this array, which is supposed to contain a renumbering map in
* "Old to New" mode. The result array contains a renumbering map in "New to Old" mode.
- * To know how to use the renumbering maps see \ref MEDCouplingArrayRenumbering.
+ * To know how to use the renumbering maps see \ref numbering.
* \param [in] newNbOfElem - the number of tuples in the result array.
* \return DataArrayInt * - the new instance of DataArrayInt.
* The caller is to delete this result array using decrRef() as it is no more
* Creates a one-dimensional DataArrayInt of given length, whose contents are computed
* from values of \a this array, which is supposed to contain a renumbering map in
* "New to Old" mode. The result array contains a renumbering map in "Old to New" mode.
- * To know how to use the renumbering maps see \ref MEDCouplingArrayRenumbering.
+ * To know how to use the renumbering maps see \ref numbering.
* \param [in] newNbOfElem - the number of tuples in the result array.
* \return DataArrayInt * - the new instance of DataArrayInt.
* The caller is to delete this result array using decrRef() as it is no more
/*!
* Permutes values of \a this array as required by \a old2New array. The values are
* permuted so that \c new[ \a old2New[ i ]] = \c old[ i ]. Number of tuples remains
- * the same as in \this one.
+ * the same as in \c this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
*/
/*!
* Permutes values of \a this array as required by \a new2Old array. The values are
* permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of tuples remains
- * the same as in \this one.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * the same as in \c this one.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
* \return DataArrayInt * - the new instance of DataArrayInt that the caller
/*!
* Returns a copy of \a this array with values permuted as required by \a old2New array.
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ].
- * Number of tuples in the result array remains the same as in \this one.
+ * Number of tuples in the result array remains the same as in \c this one.
* If a permutation reduction is needed, renumberAndReduce() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
* \return DataArrayInt * - the new instance of DataArrayInt that the caller
/*!
* Returns a copy of \a this array with values permuted as required by \a new2Old array.
* The values are permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of
- * tuples in the result array remains the same as in \this one.
+ * tuples in the result array remains the same as in \c this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
* \return DataArrayInt * - the new instance of DataArrayInt that the caller
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ] for all
* \a old2New[ i ] >= 0. In other words every i-th tuple in \a this array, for which
* \a old2New[ i ] is negative, is missing from the result array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old tuple and giving negative position for
* for i-th old tuple that should be omitted.
* The values are permuted so that \c new[ i ] = \c old[ \a new2OldBg[ i ]].
* This method is equivalent to renumberAndReduce() except that convention in input is
* \c new2old and \b not \c old2new.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* \c new2old and \b not \c old2new.
* This method is equivalent to selectByTupleId() except that it prevents coping data
* from behind the end of \a this array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* command \c range( \a bg, \a end2, \a step ).
* This method is equivalent to selectByTupleIdSafe() except that the input array is
* not constructed explicitly.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] bg - index of the first tuple to copy from \a this array.
* \param [in] end2 - index of the tuple before which the tuples to copy are located.
* \param [in] step - index increment to get index of the next tuple to copy.
/*!
* Returns a shorten copy of \a this array. The new DataArrayInt contains ranges
* of tuples specified by \a ranges parameter.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] ranges - std::vector of std::pair's each of which defines a range
* of tuples in [\c begin,\c end) format.
* \return DataArrayInt * - the new instance of DataArrayInt that the caller
* are [5,6,0,3,2,7,1,4]; if this result array (\a res) is used as an argument in call
* \a this->renumber(\a res) then the returned array contains [0,3,4,6,7,9,10,11].
* This method is useful for renumbering (in MED file for example). For more info
- * on renumbering see \ref MEDCouplingArrayRenumbering.
+ * on renumbering see \ref numbering.
* \return DataArrayInt * - a new instance of DataArrayInt. The caller is to delete this
* array using decrRef() as it is no more needed.
* \throw If \a this is not allocated.
* place in the set \a B. The second out array is the index of the first one; it shows how
* many elements of \a A are mapped into each element of \a B. <br>
* For more info on
- * mapping and its usage in renumbering see \ref MEDCouplingArrayRenumbering. <br>
+ * mapping and its usage in renumbering see \ref numbering. <br>
* \b Example:
* - \a this: [0,3,2,3,2,2,1,2]
* - \a targetNb: 4
* from a zip representation of a surjective format (returned e.g. by
* \ref ParaMEDMEM::DataArrayDouble::findCommonTuples() "DataArrayDouble::findCommonTuples()"
* for example). The result array minimizes the permutation. <br>
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering. <br>
+ * For more info on renumbering see \ref numbering. <br>
* \b Example: <br>
* - \a nbOfOldTuples: 10
* - \a arr : [0,3, 5,7,9]
/*!
* Returns a new DataArrayInt containing a renumbering map in "New to Old" mode,
* which if applied to \a this array would make it sorted ascendingly.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering. <br>
+ * For more info on renumbering see \ref numbering. <br>
* \b Example: <br>
* - \a this: [2,0,1,1,0,1,2,0,1,1,0,0]
* - result: [10,0,5,6,1,7,11,2,8,9,3,4]
* \throw If \a this is not allocated.
* \throw If parameters specifying tuples and components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarrayint_setpartofvaluessimple1 "Here is a Python example".
* defined by <em>(bgComp,endComp,stepComp)</em>.
* \throw If parameters specifying components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarrayint_setpartofvalues3 "Here is a Python example".
* \a this array.
* \throw If parameters specifying components to assign to, do not give a
* non-empty range of increasing indices or indices are out of a valid range
- * for \this array.
+ * for \c this array.
*
* \if ENABLE_EXAMPLES
* \ref py_mcdataarrayint_setpartofvaluessimple3 "Here is a Python example".
* permuted so that \c new[ \a old2New[ i ]] = \c old[ i ]. Number of tuples remains
* the same as in \this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
*/
* Permutes values of \a this array as required by \a new2Old array. The values are
* permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of tuples remains
* the same as in \this one.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
*/
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ].
* Number of tuples in the result array remains the same as in \this one.
* If a permutation reduction is needed, renumberAndReduce() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old value.
* \return DataArrayChar * - the new instance of DataArrayChar that the caller
* The values are permuted so that \c new[ i ] = \c old[ \a new2Old[ i ]]. Number of
* tuples in the result array remains the same as in \this one.
* If a permutation reduction is needed, substr() or selectByTupleId() should be used.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2Old - C array of length equal to \a this->getNumberOfTuples()
* giving a previous position of i-th new value.
* \return DataArrayChar * - the new instance of DataArrayChar that the caller
* The values are permuted so that \c new[ \a old2New[ i ]] = \c old[ i ] for all
* \a old2New[ i ] >= 0. In other words every i-th tuple in \a this array, for which
* \a old2New[ i ] is negative, is missing from the result array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] old2New - C array of length equal to \a this->getNumberOfTuples()
* giving a new position for i-th old tuple and giving negative position for
* for i-th old tuple that should be omitted.
* The values are permuted so that \c new[ i ] = \c old[ \a new2OldBg[ i ]].
* This method is equivalent to renumberAndReduce() except that convention in input is
* \c new2old and \b not \c old2new.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* \c new2old and \b not \c old2new.
* This method is equivalent to selectByTupleId() except that it prevents coping data
* from behind the end of \a this array.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] new2OldBg - pointer to the beginning of a permutation array that gives a
* tuple index in \a this array to fill the i-th tuple in the new array.
* \param [in] new2OldEnd - specifies the end of the permutation array that starts at
* command \c range( \a bg, \a end2, \a step ).
* This method is equivalent to selectByTupleIdSafe() except that the input array is
* not constructed explicitly.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] bg - index of the first tuple to copy from \a this array.
* \param [in] end2 - index of the tuple before which the tuples to copy are located.
* \param [in] step - index increment to get index of the next tuple to copy.
/*!
* Returns a shorten copy of \a this array. The new DataArrayChar contains ranges
* of tuples specified by \a ranges parameter.
- * For more info on renumbering see \ref MEDCouplingArrayRenumbering.
+ * For more info on renumbering see \ref numbering.
* \param [in] ranges - std::vector of std::pair's each of which defines a range
* of tuples in [\c begin,\c end) format.
* \return DataArrayChar * - the new instance of DataArrayChar that the caller
* \param [out] areNodesMerged - is set to \a true if any coincident nodes found.
* \param [out] newNbOfNodes - returns number of unique nodes.
* \return DataArrayInt * - the permutation array in "Old to New" mode. For more
- * info on "Old to New" mode see \ref MEDCouplingArrayRenumbering. The caller
+ * info on "Old to New" mode see \ref numbering. The caller
* is to delete this array using decrRef() as it is no more needed.
* \throw If the coordinates array is not set.
*/
* array is modified accordingly.
* \param [in] newNodeNumbers - a permutation array, of length \a
* this->getNumberOfNodes(), in "Old to New" mode.
- * See \ref MEDCouplingArrayRenumbering for more info on renumbering modes.
+ * See \ref numbering for more info on renumbering modes.
* \param [in] newNbOfNodes - number of nodes remaining after renumbering.
* \throw If the coordinates array is not set.
* \throw If the nodal connectivity of cells is not defined.
* of merged nodes (whose new ids coincide) is changed to be at their barycenter.
* \param [in] newNodeNumbers - a permutation array, of length \a
* this->getNumberOfNodes(), in "Old to New" mode.
- * See \ref MEDCouplingArrayRenumbering for more info on renumbering modes.
+ * See \ref numbering for more info on renumbering modes.
* \param [in] newNbOfNodes - number of nodes remaining after renumbering, which is
* actually one more than the maximal id in \a newNodeNumbers.
* \throw If the coordinates array is not set.
* \param [out] areNodesMerged - is set to \c true if any coincident nodes removed.
* \param [out] newNbOfNodes - number of nodes remaining after the removal.
* \return DataArrayInt * - the permutation array in "Old to New" mode. For more
- * info on "Old to New" mode see \ref MEDCouplingArrayRenumbering. The caller
+ * info on "Old to New" mode see \ref numbering. The caller
* is to delete this array using decrRef() as it is no more needed.
* \throw If the coordinates array is not set.
* \throw If the nodal connectivity of cells is not defined.
* \param [out] areNodesMerged - is set to \c true if any coincident nodes removed.
* \param [out] newNbOfNodes - number of nodes remaining after the removal.
* \return DataArrayInt * - the permutation array in "Old to New" mode. For more
- * info on "Old to New" mode see \ref MEDCouplingArrayRenumbering. The caller
+ * info on "Old to New" mode see \ref numbering. The caller
* is to delete this array using decrRef() as it is no more needed.
* \throw If the coordinates array is not set.
* \throw If the nodal connectivity of cells is not defined.
*
* \param [out] neighbors is an array storing all the neighbors of all nodes in \b this. This array is newly allocated and should be dealt by the caller. \b neighborsIndx 2nd output
* parameter allows to select the right part in this array. The number of tuples is equal to the last values in \b neighborsIndx.
- * \param [out] neighborsIndx is an array of size this->getNumberOfCells()+1 newly allocated and should be dealt by the caller. This arrays allow to use the first output parameter \b neighbors.
+ * \param [out] neighborsIdx is an array of size this->getNumberOfCells()+1 newly allocated and should be dealt by the caller. This arrays allow to use the first output parameter \b neighbors.
*/
void MEDCouplingUMesh::computeNeighborsOfNodes(DataArrayInt *&neighbors, DataArrayInt *&neighborsIdx) const
{
* - 2 : nodal. cell1 and cell2 are equal if and only if cell1 and cell2 have same type and have the same nodes constituting connectivity. This is the laziest policy. This policy
* can be used for users not sensitive to orientation of cell
* \param [in] startCellId specifies the cellId starting from which the equality computation will be carried out. By default it is 0, which it means that all cells in \a this will be scanned.
- * \param [out] commonCells
- * \param [out] commonCellsI
+ * \param [out] commonCellsArr
+ * \param [out] commonCellsIArr
* \return the correspondance array old to new in a newly allocated array.
*
*/
* The main difference is that this method is not expected to throw exception.
* This method has two outputs :
*
+ * \param other other mesh
* \param arr is an output parameter that returns a \b newly created instance. This array is of size 'other->getNumberOfCells()'.
* \return If \a other is fully included in 'this 'true is returned. If not false is returned.
*/
* By default coordinates are kept. This method is close to MEDCouplingUMesh::buildPartOfMySelf except that here input
* cellIds is not given explicitely but by a range python like.
*
+ * \param start
+ * \param end
+ * \param step
* \param keepCoords that specifies if you want or not to keep coords as this or zip it (see ParaMEDMEM::MEDCouplingUMesh::zipCoords). If true zipCoords is \b NOT called, if false, zipCoords is called.
* \return a newly allocated
*
* Size of [ \b cellIdsBg, \b cellIdsEnd ) ) must be equal to the number of cells of otherOnSameCoordsThanThis.
* The number of cells of \b this will remain the same with this method.
*
- * \param [in] begin begin of cell ids (included) of cells in this to assign
- * \param [in] end end of cell ids (excluded) of cells in this to assign
+ * \param [in] cellIdsBg begin of cell ids (included) of cells in this to assign
+ * \param [in] cellIdsEnd end of cell ids (excluded) of cells in this to assign
* \param [in] otherOnSameCoordsThanThis an another mesh with same meshdimension than \b this with exactly the same number of cells than cell ids list in [\b cellIdsBg, \b cellIdsEnd ).
* Coordinate pointer of \b this and those of \b otherOnSameCoordsThanThis must be the same
*/
* \throw if \b otherDimM1OnSameCoords is not part of constituent of \b this, or if coordinate pointer of \b this and \b otherDimM1OnSameCoords
* are not same, or if this->getMeshDimension()-1!=otherDimM1OnSameCoords.getMeshDimension()
*
+ * \param [in] otherDimM1OnSameCoords
* \param [out] cellIdsRk0 a newly allocated array containing the cell ids of s0 (which are cell ids of \b this) in the above algorithm.
* \param [out] cellIdsRk1 a newly allocated array containing the cell ids of s1 \b indexed into the \b cellIdsRk0 subset. To get the absolute ids of s1, simply invoke
* cellIdsRk1->transformWithIndArr(cellIdsRk0->begin(),cellIdsRk0->end());
* \warning This method performs no check of validity of new ids. **Use it with care !**
* \param [in] newNodeNumbersO2N - a permutation array, of length \a
* this->getNumberOfNodes(), in "Old to New" mode.
- * See \ref MEDCouplingArrayRenumbering for more info on renumbering modes.
+ * See \ref numbering for more info on renumbering modes.
* \throw If the nodal connectivity of cells is not defined.
*
* \if ENABLE_EXAMPLES
* should be contained in[0;this->getNumberOfCells()).
*
* \param [in] old2NewBg is expected to be a dynamically allocated pointer of size at least equal to this->getNumberOfCells()
+ * \param check
*/
void MEDCouplingUMesh::renumberCells(const int *old2NewBg, bool check)
{
/*!
* Returns a dimension of \a this mesh, i.e. a dimension of cells constituting \a this
- * mesh. For more info see \ref MEDCouplingMeshesPage.
+ * mesh. For more info see \ref meshes.
* \return int - the dimension of \a this mesh.
* \throw If the mesh dimension is not defined using setMeshDimension().
*/
/*!
* Second step of serialization process.
* \param tinyInfo must be equal to the result given by getTinySerializationInformation method.
+ * \param a1
+ * \param a2
+ * \param littleStrings
*/
void MEDCouplingUMesh::resizeForUnserialization(const std::vector<int>& tinyInfo, DataArrayInt *a1, DataArrayDouble *a2, std::vector<std::string>& littleStrings) const
{
* This method works only if \a this is a 3D mesh, that is to say a mesh with mesh dimension 3 and a space dimension 3.
* This method makes the hypothesis that \a this a coherent that is to say MEDCouplingUMesh::checkCoherency2 should throw no exception.
*
- * \ret a newly allocated int array with one components containing cell ids renumbered to fit the convention of MED (MED file and MEDCoupling)
+ * \return a newly allocated int array with one components containing cell ids renumbered to fit the convention of MED (MED file and MEDCoupling)
* \sa MEDCouplingUMesh::orientCorrectlyPolyhedrons,
*/
DataArrayInt *MEDCouplingUMesh::findAndCorrectBadOriented3DCells()
}
/*!
- * This method makes the hypothesis that \at this is sorted by type. If not an exception will be thrown.
+ * This method makes the hypothesis that \a this is sorted by type. If not an exception will be thrown.
* This method is the opposite of MEDCouplingUMesh::checkTypeConsistencyAndContig method. Given a list of cells in \a profile it returns a list of sub-profiles sorted by geo type.
* The result is put in the array \a idsPerType. In the returned parameter \a code, foreach i \a code[3*i+2] refers (if different from -1) to a location into the \a idsPerType.
* This method has 1 input \a profile and 3 outputs \a code \a idsInPflPerType and \a idsPerType.
*
+ * \param [in] profile
* \param [out] code is a vector of size 3*n where n is the number of different geometric type in \a this \b reduced to the profile \a profile. \a code has exactly the same semantic than in MEDCouplingUMesh::checkTypeConsistencyAndContig method.
* \param [out] idsInPflPerType is a vector of size of different geometric type in the subpart defined by \a profile of \a this ( equal to \a code.size()/3). For each i,
* \a idsInPflPerType[i] stores the tuple ids in \a profile that correspond to the geometric type code[3*i+0]
* dimension and sharing the node coordinates array.
* All cells of the *i*-th mesh precede all cells of the
* (*i*+1)-th mesh within the result mesh.
- * \param [in] a - a vector of meshes (MEDCouplingUMesh) to concatenate.
+ * \param [in] meshes - a vector of meshes (MEDCouplingUMesh) to concatenate.
* \return MEDCouplingUMesh * - the result mesh. It is a new instance of
* MEDCouplingUMesh. The caller is to delete this mesh using decrRef() as it
* is no more needed.
* The selection of extraction is done standardly in new2old format.
* This method returns indexed arrays using 2 arrays (arrOut,arrIndexOut).
*
- * \param [in] idsOfSelectBg begin of set of ids of the input extraction (included)
- * \param [in] idsOfSelectEnd end of set of ids of the input extraction (excluded)
+ * \param [in] idsOfSelectStart begin of set of ids of the input extraction (included)
+ * \param [in] idsOfSelectStop end of set of ids of the input extraction (excluded)
+ * \param [in] idsOfSelectStep
* \param [in] arrIn arr origin array from which the extraction will be done.
* \param [in] arrIndxIn is the input index array allowing to walk into \b arrIn
* \param [out] arrOut the resulting array
}
}
-/// @cond INTERNAL
+/// @endcond
/*!
* Returns true if a colinearization has been found in the given cell. If false is returned the content pushed in \a newConnOfCell is equal to [ \a connBg , \a connEnd ) .
}
}
-/// @cond INTERNAL
+/// @endcond
MEDFileFieldPerMesh::MEDFileFieldPerMesh(med_idt fid, MEDFileAnyTypeField1TSWithoutSDA *fath, int meshCsit, int meshIteration, int meshOrder, const MEDFileFieldNameScope& nasc, const MEDFileMesh *mm, const std::vector< std::pair<TypeOfField,INTERP_KERNEL::NormalizedCellType> > *entities):_mesh_iteration(meshIteration),_mesh_order(meshOrder),
_father(fath)
* On top of attaching a \c ParaMEDMEM::ParaFIELD, 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 \ref medoupling fields (ICoCo::MEDField).
+ * one for codes that express their fields as \ref fields "MEDCoupling fields" (ICoCo::MEDField).
*
* \section dec_options DEC Options
* Options supported by \c DEC objects are
\section dec-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" 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).
In the present version, only fields lying on elements are considered.
- \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."
+ \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."
- \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."
+ \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."
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 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.
The following code excerpt illutrates a typical use of the InterpKernelDEC class.
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|}
On top of \ref dec_options, options supported by %InterpKernelDEC objects are
related to the underlying 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
The computation is possible for 3D meshes and 2D meshes.
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.
+ faster than the \ref InterpKernelDEC-det "InterpKernelDEC" which gives a
+ \ref InterpKerRemapGlobal "conservative remapping".
It is particularly true for the initialisation phase (synchronize)
- which is very computationnaly intensive in \ref interpkerneldec.
+ which is very computationnaly intensive in \ref InterpKernelDEC-det.
In the present version, only fields lying on elements are considered.
The value is estimated by locating the barycenter of the target
{
}
- /*! Constructor of a non coincident \ref dec with
+ /*! Constructor of a non coincident \ref para-dec "DEC" with
* a source group on which lies a field lying on a mesh and a
* target group on which lies a mesh.
*
\anchor OverlapDEC-det
\class 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.
+ 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-det is that this \ref para-dec "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 InterpKernelDEC 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 of the computation. The 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 in order to explain the different steps."
- \subsection ParaMEDMEMOverlapDECAlgoStep1 Step 1 : Bounding box exchange and global interaction between procs computation.
+ \subsection ParaMEDMEMOverlapDECAlgoStep1 Step 1 : Bounding box exchange and global interaction
+ between procs computation.
- 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
+ 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 :
+ 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 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.
+ 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 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 local TODO list :
-
- - proc#0 : (0,0)
- - proc#1 : (0,1),(1,0)
- - proc#2 : (1,2),(2,0),(2,1),(2,2)
+ 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
+ local TODO list :
+
+ - proc\#0 : (0,0)
+ - proc\#1 : (0,1),(1,0)
+ - proc\#2 : (1,2),(2,0),(2,1),(2,2)
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 (with regard to interpolation). The \b local TODO list of other procs than local
+ 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
- Knowing the \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 :
+ In the \ref ParaMEDMEMOverlapDECImgTest1 "example above" the exchange TODO list gives the
+ following results :
Sending TODO list per proc :
- - proc #0 : Send fieldtemplate A to Proc#1, Send fieldtemplate B to Proc#1, Send fieldtemplate B to Proc#2
- - Proc #1 : Send fieldtemplate A to Proc#2, Send fieldtemplate B to Proc#2
- - Proc #2 : No send.
+ - proc \#0 : Send fieldtemplate A to Proc\#1, Send fieldtemplate B to Proc\#1, Send fieldtemplate
+ B to Proc\#2
+ - Proc \#1 : Send fieldtemplate A to Proc\#2, Send fieldtemplate B to Proc\#2
+ - Proc \#2 : No send.
Receiving TODO list per proc :
- - proc #0 : No receiving
- - 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 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 the TODO list. This couple is treated by either k or m as seen in \ref ParaMEDMEMOverlapDECAlgoStep2 "here in Step2".
-
- 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 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.
+ - proc \#0 : No receiving
+ - 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 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 the TODO list. This couple is treated by either k or m as
+ seen in \ref ParaMEDMEMOverlapDECAlgoStep2 "here in Step2".
+
+ 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 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) 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.
+ - 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 : Computation of the interpolation matrix
- 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
+ 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.
\subsection ParaMEDMEMOverlapDECAlgoStep5 Step 5 : Global matrix construction.
- After having performed the TODO list at the end of \ref ParaMEDMEMOverlapDECAlgoStep4 "Step4" we need 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 the 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<int,double> \c >.
- 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)
+ 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 a call to 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)
+ - 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 in proc 1 after execution of the function "prepare". This is an example of item 0 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 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
+ - Proc\#0 : 0,1
+ - Proc\#1 : 0,2
+ - Proc\#2 : 0,1,2
In the end ParaMEDMEM::OverlapMapping::_proc_ids_to_recv_vector_st will contain :
- - Proc#0 : 0,1,2
- - Proc#1 : 0,2
- - Proc#2 : 1,2
+ - Proc\#0 : 0,1,2
+ - Proc\#1 : 0,2
+ - Proc\#2 : 1,2
The method in charge to perform this is : ParaMEDMEM::OverlapMapping::prepare.
*/
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 dec can be used for fields that have component topologies,
+ Also, this \ref para-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 NonCoincidentDEC and \ref InterpKernelDEC. Therefore, this \ref dec must not be used
+ \ref NonCoincidentDEC-det "NonCoincidentDEC" and \ref InterpKernelDEC-det "InterpKernelDEC".
+ Therefore, this \ref para-dec "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 :
other DECs in the case when the remapping concerns similar meshes
that only have different partitionings. In the case when the
fields have also different component topologies, creating the ParaFIELD
- requires some more effort. See \ref parafield section for more details.
+ requires some more effort. See the \ref para-over section for more details.
*/
