The specificity of this intersector is to deal with \b any \b type of
polygons even those with \b quadratic \b edges.
Its quite generic architecture allows him to deal with some other
-patentially usefull functions.\n
+potentially useful functions.\n
This page described Geometric2D intersector basic principles and
specific usage.
The principle used to do boolean operations between 2 polygons P1 and
P2 is to intersect each edge of P1 with each edge of P2. \n After this
-edge-splitting, polygon P1 is splitted, so that each
+edge-splitting, polygon P1 is splitted, so that each
\ref INTERP_KERNEL::ElementaryEdge "elementary edge" constituting P1
-is either \b in, \b out or \b on polygon P2. And inversely, polygon P2 is splitted so that each
+is either \b in, \b out or \b on polygon P2. And inversely, polygon P2 is splitted so that each
\ref INTERP_KERNEL::ElementaryEdge "elementary edge" constituting P2
is either \b in, \b out or \b on polygon P1.
is common to all boolean operations.
When the location of edges has \b not been
-already deduced in previous computation and there is no predecessor, the
+already deduced in previous computation and there is no predecessor, the
\ref interpkernelGeo2DAlgLoc "localization is done in absolute".
After it deduces the localization relatively to the previous edge
thanks to node localization.\n The relative localization is done
Generally, the principle is to take an edge in \a P1 with wanted loc and linking
direct neighbour-edges (with correct loc) until closing a polygon. If
not, using \a P2 edges to try to close polygon. The process is
-repeated until all edges with correct loc have been consumed.
+repeated until all edges with correct loc have been consumed.
The method in charge of that is INTERP_KERNEL::QuadraticPolygon::buildIntersectionPolygons.
The principle chosen to know if an edge \a E is completely included in an
any polygon \a P is to see if its barycenter \a B is inside this any
polygon \a P.
-After, for each nodes \f$ P_i \f$ of polygon \a P we store angle in \f$ [-\pi/2,\pi/2 ] \f$
+After, for each nodes \f$ P_i \f$ of polygon \a P we store angle in \f$ [-\pi/2,\pi/2 ] \f$
that represents the slope of line \f$ (BP_i) \f$.\n
Then a line \a L going through \a B with a slope being as far as
-possible from all slopes found above. Then the algorithm goes along \a L
-and number of times \a N it intersects \b non-tangentally the any polygon \a P.
+possible from all slopes found above. Then the algorithm goes along \a L
+and number of times \a N it intersects \b non-tangentially the any polygon \a P.
If \a N is odd \a B (and then \a E) is IN.
If \a N is even \a B (and then \a E) is OUT.
\subsection interpkernelGeo2DAlgIntsect Intersection algorithms.
The only mathematical intersections performed are edges intersections.
-The algorithms used are :
+The algorithms used are :
-# Lin-Lin intersection : http://mathworld.wolfram.com/Line-LineIntersection.html
-# Lin-Arc intersection : http://mathworld.wolfram.com/Circle-LineIntersection.html
\image html SampGeo2D4.png "Close-up of final result after close polygons phase."
\image latex SampGeo2D4.eps "Close-up of final result after close polygons phase."
-\note The result polygon is constitued from 2 sub-edges coming from \a P1
+\note The result polygon is constituted of 2 sub-edges coming from \a P1
and 1 sub-edge from \a P2 closing the polygon. For the 2 edges of \a P1
they are green because they are fully included in \a P2. Inversely,
the only sub-edge coming from \a P2 is fully included in \a P1.
- coordinates of a barycentre of cells intersection (b),
<br>where n is number of vertices which is either 3 or 4.
-Purpose is to find coefficients a1...an so that
+Purpose is to find coefficients a1...an so that
- (a1*p1+...+an*pn)=b and
- (a1+...+an)=1.0
| y1-y4 y2-y4 y3-y4 |
| z1-z4 z2-z4 z3-z4 |</pre>
-In 2D case solution is found by inversing T which is trivial: a = T^(-1) * ( b - pn )
+In 2D case solution is found by inverting T which is trivial: a = T^(-1) * ( b - pn )
In 3D case we use Gaussian elimination algorithm. First we use elementary
row operations to transform T into upper triangular form and
-then perform back substitution to find coeficients a.
+then perform back substitution to find coefficients a.
*/
\section InterpKerIntro Introduction
The main purpose of this module is to propose a set of algorithms for
-mesh interpolation \b fully \b independant \b of \b the \b mesh \b datastructure to
-support several type of format. This component is parameterized as
+mesh interpolation \b fully \b independent \b of \b the \b mesh \b datas tructure to
+support several type of format. This component is parametrized as
much as possible using C++ templates.
For the moment only interpolators for unstructured meshes are present in
the %interpolation kernel.
by calling the desired intersector. The problem is that each call to this algorithm
is CPU-expensive.
To reduce the computational time, a first filtering is done to detect
-pairs (i,j) \f$ W_{ij} \f$ is obviously equal to 0. It is typically the case when a cell in the source mesh
+pairs (i,j) \f$ W_{ij} \f$ is obviously equal to 0. It is typically the case when a cell in the source mesh
is too far from an another cell in the target mesh each.
So for a given type of interpolation, the computation of W is
\subsection InterpKerMeshType class MeshType
-Each Interpolators and Intersectors are parameterized (templated in
-C++ langage) with \c class \c MeshType . This type of generalization
+Each Interpolators and Intersectors are parametrized (templated in
+C++ language) with \c class \c MeshType . This type of generalization
has been chosen to reduce at maximum overhead. \n
Thanks to this principle intersectors and interpolators are usable
-with \bseveral \b mesh \b formats such as \c MED or \c VTK, \b without \b preformance \b loss.
+with \b several \b mesh \b formats such as \c MED or \c VTK, \b without \b performance \b loss.
\c MeshType is a concept that should strictly fulfilled the following
rules :
/*!
\page InterpKerRemapGlobal Linear remapping
-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:
+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:
\f[
\phi_t=W.\phi_s.
\f$W\f$ is called the \anchor interpolationmatrix interpolation matrix.
The objective of interpolators is to compute the matrix W depending on their physical
-properties (\ref IntExtFields) and their mesh discretisation (on cells P0, on nodes P1,...).
+properties (\ref IntExtFields) and their mesh discretization (on cells P0, on nodes P1,...).
\section ConsInterp Conservative interpolation
be satisfied :
\f[
-\int_{T_i} \phi_t = \sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi_s.
+\int_{T_i} \phi_t = \sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi_s.
\f]
This equation is used to compute \f$ W_{ij} \f$, based on the fields representation ( P0, P1, P1d etc..) and the
\f]
then the meshes S and T are said to be \b
overlapping. In this case the two formulas in a given column in the table below give the same
-result. All intensive formulas result in the same output, and all the extensive formulas give also the same output.
+result. All intensive formulas result in the same output, and all the extensive formulas give also the same output.
The ideal interpolation algorithm should be conservative and respect the maximum principle. However such an algorithm can be impossible to design if the two meshes do not overlap. When the meshes do not overlap, using either \f$Vol(T_i)\f$ or \f$\sum_{S_j} Vol(T_i\cap S_j)\f$ one obtains an algorithm that respects either the conservativity or the maximum principle (see the nature of field \ref TableNatureOfField "summary table").
\section InterpKerRemapInt Linear conservative remapping of P0 (cell based) fields
-We assume that the field is represented by a vector with a discrete value on each cell.
-This value can represent either
-- an average value of the field in the cell (average density, velocity or temperature in the cell) in which case the representation is said to be \b intensive,
+We assume that the field is represented by a vector with a discrete value on each cell.
+This value can represent either
+- an average value of the field in the cell (average density, velocity or temperature in the cell) in which case the representation is said to be \b intensive,
- an integrated value over the cell (total mass, power of the cell) in which case the representation is said to be \b extensive
\section InterpKerP0P0Int cell-cell (P0->P0) conservative remapping of intensive fields
left hand side in the \ref InterpKerGenralEq "general interpolation equation" becomes :
\f[
-\int_{T_i} \phi = Vol(T_i).\phi_{T_i}.
+\int_{T_i} \phi = Vol(T_i).\phi_{T_i}.
\f]
Here Vol represents the volume when the mesh dimension is equal to 3, the
right hand side becomes :
\f[
-\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = \sum_{S_j\cap T_i \neq \emptyset} {Vol(T_i\cap S_j)}.\phi_{S_j}.
+\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = \sum_{S_j\cap T_i \neq \emptyset} {Vol(T_i\cap S_j)}.\phi_{S_j}.
\f]
As the field values are constant on each
given by the formula :
\f[
- W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(T_i) }.
+ W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(T_i) }.
\f]
\section InterpKerP0P0Ext cell-cell (P0->P0) conservative remapping of extensive fields
In code coupling from neutronics to hydraulics, \b extensive field
-of power is exchanged and the total power should remain the same.
-The discrete values of the field represent the total power contained in the cell.
+of power is exchanged and the total power should remain the same.
+The discrete values of the field represent the total power contained in the cell.
Hence in the \ref InterpKerGenralEq "general interpolation equation" the
left hand side becomes :
\f[
-\int_{T_i} \phi = P_{T_i},
+\int_{T_i} \phi = P_{T_i},
\f]
while the right hand side is now :
given by the formula :
\f[
- W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }.
+ W_{ij}=\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }.
\f]
-\section TableNatureOfField Summary
+\section TableNatureOfField Summary
In the case of fields with a P0 representation (cell based) and when the meshes do not overlap, the scheme is either conservative or maximum preserving (not both). Depending on the \ref NatureOfField the interpolation coefficients take the following value:
* <TABLE BORDER=1 >
0.125 & 0.75 \\
\end{tabular}\right]
\f]
-
+
\subsection TableNatureOfFieldExampleConservVol Conservative volumic case
If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{Conservative Volumic} \f$ matrix :
\end{tabular}\right]
\f]
-As we can see here the maximum principle is respected.This nature of field is particulary recommended to interpolate an intensive
-field such as \b temperature or \b pression.
+As we can see here the maximum principle is respected.This nature of field is particularly recommended to interpolate an intensive
+field such as \b temperature or \b pressure.
\subsection TableNatureOfFieldExampleIntegral Integral case
In the particular case treated \ref TableNatureOfFieldEx1 "here", it means that only a power of 25.055 W is intercepted by the target cell !
-So from the 104 W of the source field \f$ FS \f$, only 25.055 W are transmited in the target field using this nature of field.
-In order to treat differently a power field, another policy, \ref TableNatureOfFieldExampleIntegralGlobConstraint "integral global constraint nature" is available.
+So from the 104 W of the source field \f$ FS \f$, only 25.055 W are transmitted in the target field using this nature of field.
+In order to treat differently a power field, another policy, \ref TableNatureOfFieldExampleIntegralGlobConstraint "integral global constraint nature" is available.
\subsection TableNatureOfFieldExampleIntegralGlobConstraint Integral with global constraints case
This type of nature is particulary recommended to interpolate an intensive \b density
field (moderator density, power density).
The difference with \ref TableNatureOfFieldExampleConservVol "conservative volumic" seen above is that here the
-target field is homogeneized to the \b whole target cell. It explains why this nature of field does not follow the maximum principle.
+target field is homogenized to the \b whole target cell. It explains why this nature of field does not follow the maximum principle.
To illustrate the case, let's consider that \f$ FS \f$ is a power density field in \f$ W/m^2 \f$.
-With this nature of field the target cell #0 cumulates 0.125*4=0.5 W of power from the source cell #0 and 0.75*100=75 W of power from the source cell #1.
+With this nature of field the target cell #0 accumulates 0.125*4=0.5 W of power from the source cell #0 and 0.75*100=75 W of power from the source cell #1.
It leads to 75.5 W of power on the \b whole target cell #0. So, the final power density is equal to 75.5/1.5=50.333 W/m^2.
*/
+
meshes with mixed triangular and quadrangular elements.
- Geometric2D: Any type of 2D cells (linear, quadratic, convex-polygons,
non-convex polygons) is supported by this algorithm. Due to its
-flexibility this algo is slower than the other.
+flexibility this algorithm is slower than the other.
- \anchor pointlocator PointLocator: This is a \b non \b conservative interpolator. For P0P0, it
locates the barycenter of target cell in the source cells. For P1P0, it
locates barycenter of target cell and compute barycentric coordinates
-in source cell (Works only with trangle). For P0P1 locate target nodes
+in source cell (Works only with Triangle). For P0P1 locate target nodes
in source cells. For P1P1 compute for each target node its barycentric
coordinates in source cell.
* <TR><TD>PrintLevel </TD><TD>Level of verboseness during the computations </TD><TD> 0, 1, 2, 3 </TD><TD>0 </TD></TR>
*</TABLE>
-\section interpolation3Dsurf Special features of 3D surface intersectors
+\section interpolation3Dsurf Special features of 3D surface intersectors
When remapping a three dimensional surfaces, one should give a meaning to the area of intersection between two three-dimensional non coplanar polygons. A projection phase is thus necessary to have both polygons on the same plane. Care must be taken when defining this projection to avoid non conservative remappings. After the projection step, the source and target cells lie in the same plane and the same algorithms as for 2D remapping can be employed.
-For the moment, it is only possible to remap fields on three dimension surfacic meshes with mixed triangular and quadrangular elements.
+For the moment, it is only possible to remap fields on three dimension surface meshes with mixed triangular and quadrangular elements.
Similar options as for the 2D remapping are available, plus some additional options specific to 3D surface remapping:
* <TABLE BORDER=1 >
system such that the median plane is the Oxy plane </TD><TD>
boolean true or false </TD><TD> true </TD></TR>
* <TR><TD>BoundingBoxAdjustment</TD><TD>When detecting an intersection between bounding boxes, the bounding are expanded by a factor (1+BoundingBoxAdjustment). It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. </TD><TD> positive real numbers </TD><TD> 1.e-4 </TD></TR>
- * <TR><TD>BoundingBoxAdjustmentAbs</TD><TD>When detecting an intersection between bounding boxes, the bounding are expanded uniformaly in the 3 dimension of space with the absolute value BoundingBoxAdjustmentAbs. It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. </TD><TD> positive real numbers </TD><TD> 0. </TD></TR>
- * <TR><TD>MaxDistance3DSurfIntersect</TD><TD>Before atempting an intersection in 3D surf test the distance D between fast barycenter of target cell and medium source plane P. If option < 0. no interpretation of D is done. If option > 0. then if D<option intersection is taken into account and if D>option intersection is equal to 0. . This option exists in order to have an iso behaviour whatever the angle of plane P and OXY OYZ OXZ contrary to BBoxAdjestments options. </TD><TD> real numbers </TD><TD> -1. </TD></TR>
+ * <TR><TD>BoundingBoxAdjustmentAbs</TD><TD>When detecting an intersection between bounding boxes, the bounding are expanded uniformly in the 3 dimension of space with the absolute value BoundingBoxAdjustmentAbs. It is particularly useful when detecting intersections for 3D surfaces for which the bounding boxes might not actually intersect. </TD><TD> positive real numbers </TD><TD> 0. </TD></TR>
+ * <TR><TD>MaxDistance3DSurfIntersect</TD><TD>Before attempting an intersection in 3D surf test the distance D between fast barycenter of target cell and medium source plane P. If option < 0. no interpretation of D is done. If option > 0. then if D<option intersection is taken into account and if D>option intersection is equal to 0. . This option exists in order to have an iso behaviour whatever the angle of plane P and OXY OYZ OXZ contrary to BBoxAdjestments options. </TD><TD> real numbers </TD><TD> -1. </TD></TR>
*</TABLE>
Note that choosing the Triangle Intersection_type necessarily set the DoRotate option to true.
calculations. For the moment it is only possible to remap fields on
meshes having mixed tetrahedral and hexahedral cells. When using a
mesh with hexahedral cells, several splitting techniques may be
-employed depending mainly on wether the faces are planar or not. The
+employed depending mainly on whether the faces are planar or not. The
following options are available for the splitting:
- PointLocator : \b non \b conservative intersector based on the same
principle than described in 2D.
* </TABLE>
Note that a SplittingPolicy values starting with the word "PLANAR" presume that each face is to be considered planar, while the SplittingPolicy values starting with the word GENERAL does not. The integer at the end gives the number of tetrahedra that result from the split.
- Consider an hexahedron with with planar faces and nodes numbered according to the following picture:
+ Consider an hexahedron with planar faces and nodes numbered according to the following picture:
\verbatim
-
+
7 ------ 6
/| /|
/ | / |
\image html medlayers_70pc.png
-The fondamentals consists in three atomic libraries:
+The fundamentals consists in three atomic libraries:
- \ref medcoupling that describes DataStructures used for cross process exchange of meshes and fields.
- \ref medloader that provides I/O functions to the MED file format
The libraries in SALOME MED can be configured in several manners so that it can run inside or outside the Salome platform.
Also, partitioning and parallel functionalities are optional.
-The sources of the library are located in the \a MED_SRC directory.
+The sources of the library are located in the \a MED_SRC directory.
The first step consists in preparing the configuration of the library :
\verbatim
cd ${MED_SRC}
- Compliant with coupling :
- Fields definition defined enough to perform well defined interpolation
- exchangeable through process as well in parallel case in SPMD paradigm ( \ref paramedmem "ParaMEDMEM" ), as in distributed paradigm using CORBA.
-- minimize as much as possible the number of prerequisites needed to use it ; So \ref medcoupling "MEDCoupling" only depends from
+- minimize as much as possible the number of prerequisites needed to use it ; So \ref medcoupling "MEDCoupling" only depends on
\ref interpkernel "INTERP_KERNEL library"
- light enough to be agile in order to :
- maximize the amount of algorithms being applied on it
As a mesh has one dimension and only once, that is to say every cells in
mesh have the same dimension called MeshDimension.
-For exemple a mesh with a meshDimension equal to 1, have \b cells of type
-NORM_SEG2. An another exemple, a mesh with a meshDimension equal
+For example a mesh with a meshDimension equal to 1, have \b cells of type
+NORM_SEG2. Another example, a mesh with a meshDimension equal
to 2, have \b cells of type
NORM_TRI3 and NORM_POLYGON for example.
The class that incarnates the concept described above is :
\ref ParaMEDMEM::MEDCouplingMesh.
-\section MEDCouplingMeshesAvailInstan Available instaciable mesh types in MEDCoupling
+\section MEDCouplingMeshesAvailInstan Available instantiable mesh types in MEDCoupling
- \subpage MEDCouplingUMeshPage "Unstructured meshes"
- \subpage MEDCouplingCMeshPage "Cartesian meshes"
The spatial support is a \ref MEDCouplingMeshesPage "mesh".
A field is lying on an entity that will be specified by the spatial
-discretization of the field. For exemple a field on node will lie on
+discretization of the field. For example a field on node will lie on
all nodes of its mesh.
A field on cell will lie on all cells of its mesh.
- \ref ParaMEDMEM::MEDCouplingFieldDouble::addFields "cross instances operations"
\section MEDCouplingSpatialDisc Spatial discretization concept
-This is the concept that makes the link, independantly from temporal
+This is the concept that makes the link, independently from temporal
discretization, between the field and its spatial support(\ref MEDCouplingMeshesPage "mesh"). This
concept allows the field to make a check and interpretation of an
array of values given a spatial support (\ref MEDCouplingMeshesPage "mesh").
\section MEDCouplingTemporalDisc Temporal discretization concept
-This information allows, independantly from spatial discretization, to
+This information allows, independently from spatial discretization, to
associate a time interval, if it exists, on which the field will be
defined. This concept is able to give the value at any time of
the definition interval (if any).
- double precision float (64 bits) array incarnated by \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble class".
- signed integer (32 bits) array incarnated by \ref ParaMEDMEM::DataArrayInt "DataArrayInt class".
-\ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt" classes inherits from
+\ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt" classes inherits from
\ref ParaMEDMEM::DataArray "DataArray" \b non \b instanciable \b class that factorizes some common methods of inherited instanciable classes.
In the rest of the documentation \b DataArray will be used for both \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt".
A \ref ParaMEDMEM::DataArray "DataArray" instance has an attribute **name**.
-**name** is particulary useful for \ref ParaMEDMEM::DataArray "DataArray" representing profiles, families, groups, fields in MEDLoader.
+**name** is particularly useful for \ref ParaMEDMEM::DataArray "DataArray" representing profiles, families, groups, fields in MEDLoader.
But excepted these useful usecases, **name** attribute is often ignored when \ref ParaMEDMEM::DataArray "DataArrays" are aggregated (field array, connectivity, coordinates) in a bigger object.
Whatever the usage of the **name** attribute of \ref ParaMEDMEM::DataArray "DataArrays", all methods in ParaMEDMEM::DataArrayDouble and ParaMEDMEM::DataArrayInt class deal with **name** as they do for components names.
As seen in the sub section above, a \ref ParaMEDMEM::DataArray "DataArray" instance has a defined number of components.
-Their is an information attached to each of these components constiting the \ref ParaMEDMEM::DataArray "DataArray".
+There is an information attached to each of these components constituting the \ref ParaMEDMEM::DataArray "DataArray".
-This information is concretely a string of caracters that allows, if needed, to give information about the conresponding component.
+This information is concretely a string of characters that allows, if needed, to give information about the corresponding component.
The format chosen in **MEDCoupling** for information on is "MY_COMPO_INFO [MYUNIT]". If needed, the unit attached to the component
-should be put between "[" and "]" after the information of the components after one space caracter.
+should be put between "[" and "]" after the information of the components after one space character.
\subsection MEDCouplingArrayBasicsTimeLabel DataArrays and TimeLabel.
\c setIJSilent just after invokation of \c declareAsNew instead of calling \c setIJ method that will increment time label of \ref ParaMEDMEM::DataArray "DataArray" instance
on each call.
-\c setIJ method usage should be reduced to little modification sessions.
+\c setIJ method usage should be reduced to little modification sessions.
\section MEDCouplingArraySteps0 Building an array from scratch in Python
As \ref ParaMEDMEM::DataArray "DataArrays" are the atomic entity of potentially big memory objects into \ref medcoupling "MEDCoupling"
, \ref ParaMEDMEM::DataArray "DataArrays" introduces concepts of copy and comparison that will be used by aggregating classes.
-For more complex objects (that aggregate themselves big objects)
+For more complex objects (that aggregate themselves big objects)
like ParaMEDMEM::MEDCouplingFieldDouble the concept of copy (shallow or deep) is less straight forward because which aggregated subobjects are copied or not.
\subsection MEDCouplingArrayBasicsCopyDeep Deep copy of DataArray
As for all potentially heavy memory consumer objects in \ref medcoupling "MEDCoupling", \ref ParaMEDMEM::DataArray "DataArrays" implement
- method \c deepCpy. This method deeply copies an instance. The life cycle of the returned object is *fully* independant from the instance on which the method
+ method \c deepCpy. This method deeply copies an instance. The life cycle of the returned object is *fully* independent from the instance on which the method
\c deepCpy has been invoked.
To perform a deep copy of a DataArray instance simply invoke :
\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_5bis
-\c myCoordsCpy is the deep copy of \c myCoords so they are independant and their *raw data* has been deeply copied.
+\c myCoordsCpy is the deep copy of \c myCoords so they are independent and their *raw data* has been deeply copied.
So it leads to the following behaviour :
\anchor MEDCouplingArrayBasicsCopyDeepTestEqual
\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_13
-As always, in C++, \c myCoordsCpy is an object whose life cycle is fully independant from \c myCoords so decrement is needed.
+As always, in C++, \c myCoordsCpy is an object whose life cycle is fully independent from \c myCoords so decrement is needed.
\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_14
\subsection MEDCouplingArrayRenumberingO2N Old to new mode
-The old to new mode is particulary recommanded for surjective and bijective application. This is typically the case of \ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "MEDCouplingUMesh::mergeNodes" method.
+The old to new mode is particularly recommended for surjective and bijective application. This is typically the case of \ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "MEDCouplingUMesh::mergeNodes" method.
Let's consider a call to \ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes" that reduces the number of nodes from 5 nodes to 3 nodes.\n
In old to new mode the array \b MySurjection that specifies this surjection will have 5 tuples and 1 component. The content of the 5*1 values will be in {0,1,2}.\n
- \ref ParaMEDMEM::DataArrayDouble::renumberAndReduce "DataArrayDouble::renumberAndReduce"
-Sometimes the format old to new for sujections can be replaced by another format with 2 arrays. Less compact in memory. The \ref ParaMEDMEM::DataArrayInt::changeSurjectiveFormat "DataArrayInt::changeSurjectiveFormat" method performs that.
+Sometimes the format old to new for surjections can be replaced by another format with 2 arrays. Less compact in memory. The \ref ParaMEDMEM::DataArrayInt::changeSurjectiveFormat "DataArrayInt::changeSurjectiveFormat" method performs that.
\subsection MEDCouplingArrayRenumberingN2O New to old mode
-The new to old mode is particulary recommanded for strictly injective and bijective permutations. This is particulary usefull for methods that increase the number of entities like for example
+The new to old mode is particularly recommended for strictly injective and bijective permutations. This is particularly useful for methods that increase the number of entities like for example
\ref ParaMEDMEM::MEDCouplingUMesh::simplexize "MEDCouplingUMesh::simplexize".\n
All non static methods in \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" or \ref ParaMEDMEM::DataArrayInt "DataArrayInt" having as last letter \b R (meaning Reversed) in capital works with
the mode new to old.
\subsection MEDCouplingArrayApplyFuncExpr Expressions supported
-In order to reduce as much as possible dependancies, a little dynamic formula interpretor has been developped into INTERP_KERNEL.
+In order to reduce as much as possible dependencies, a little dynamic formula interpretor has been developed into INTERP_KERNEL.
This dynamic expression evaluator can deal the following exhaustive list :
- +,-,*,^ (^ for exponent 3^2==9)
-- sin,cos,tan,sqrt,abs,exp,max,min,ln (neper logarithm), log (neper logarithm), log10 (decimal logarithm),
+- sin,cos,tan,sqrt,abs,exp,max,min,ln (neper logarithm), log (neper logarithm), log10 (decimal logarithm),
- >,<
- if
The principle of the dynamic expression evaluator is the following :
- Given the input string a compilation tree is built whose leaves are either constants or variables.
- At this phase only syntax errors are thrown.
+ At this phase only syntax errors are thrown.
\anchor MEDCouplingArrayApplyFuncExprA1
- Then given the computed tree, a link phase is performed to accelerate evaluation. At this phase the incoherence between the number of
components and the number of variables are detected.
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 separetely, it is also, possible with \ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method with one parameter
-to build an output having same number of components than input but where components in input are treated separetely.
+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
+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 alse 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 pervious \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 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.
The big difference with \ref MEDCouplingArrayApplyFunc0 "applyFunc method with one parameter" seen above is that here components of tuples are treated separately.
\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_4
-If you intend to create a new DataArrayDouble instance called \c dd1 having only one component that is the result of the sum of first component le square root of the second component and the thrid component
-the invokation should be something like this :
+If you intend to create a new DataArrayDouble instance called \c dd1 having only one component that is the result of the sum of first component and the square root of the second component and the third component
+the invocation should be something like this :
\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_5
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 \ref ParaMEDMEM::DataArrayDouble::applyFunc2 "applyFunc2" and \ref ParaMEDMEM::DataArrayDouble::applyFunc3 "applyFunc3" methods have been developped to remedy to that feature that can be surprising.
+\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.
It has five possible values:
- "NoNature", the default value, does not allow the use of any interpolation tools
-- \ref TableNatureOfFieldExampleConservVol "ConservativeVolumic", for intensive field with the maximum principle favored over conservativity. Relevant for temperature, pression fields.
+- \ref TableNatureOfFieldExampleConservVol "ConservativeVolumic", for intensive field with the maximum principle favored over conservativity. Relevant for temperature, pressure fields.
- \ref TableNatureOfFieldExampleRevIntegral "RevIntegral", for intensive field with the conservativity favored over maximum principle. Relevant for power density fields.
\section Usage
-In order to employ the various \ref interptools, you have to specify the nature of your field.
+In order to employ the various \ref interptools, 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:
\code
/*!
\page MEDCouplingUMeshPage Unstructured meshes in MEDCoupling
-
+
[TOC]
An unstructured mesh in \ref medcoupling MEDCoupling is defined by :
- a point clouds where the explicit coordinates of each point must be specified (inherited from \subpage MEDCouplingPointSetPage "MEDCouplingPointSet class").
- nodal connectivity that specifies for each cell, the points in the previous point clouds that constitutes the cell.
-As unstructured mesh is dynamically defined enough, this class is also used by MEDCoupling to instanciate degenerated meshes as :
+As unstructured mesh is dynamically defined enough, this class is also used by MEDCoupling to instantiate degenerated meshes as :
- points cloud only meshes. This type of mesh will have mesh dimension 0.
- abstract meshes containing only one cell that covers a potentially
The described method here is called standard, because no special knowledge of underneath nodal connectivity is needed here.
This method of building unstructured mesh is easiest but not the most CPU/memory efficient one.
-All of exemples given here make the assumption that the \c ParaMEDMEM namespace is visible ( by calling for example \c using \c namespace \c ParaMEDMEM; ).
+All of examples given here make the assumption that the \c ParaMEDMEM namespace is visible ( by calling for example \c using \c namespace \c ParaMEDMEM; ).
Here we will create a mesh with spacedim==3 and meshdim==2. \b mesh contains 5 cells (with geometric type INTERP_KERNEL::NORM_TRI3, INTERP_KERNEL::NORM_QUAD4)
and 9 nodes.
/*!
\page MEDCouplingPointSetPage Point set meshes in MEDCoupling
-This is a \b non \b instanciable class that implements many algorithm working only on a set of points without any connectivity aspect.
+This is a \b non \b instantiable class that implements many algorithm working only on a set of points without any connectivity aspect.
The presence of this class is only for factorization reasons.
The class that incarnates this concept in \ref medcoupling "MEDCoupling" is : \ref ParaMEDMEM::MEDCouplingPointSet.
-Instanciable class ParaMEDMEM::MEDCouplingUMesh inherits from ParaMEDMEM::MEDCouplingPointSet.
+Instantiable class ParaMEDMEM::MEDCouplingUMesh inherits from ParaMEDMEM::MEDCouplingPointSet.
Some of most important implemented methods by \ref ParaMEDMEM::MEDCouplingPointSet "MEDCouplingPointSet" class are :
A cartesian mesh is a mesh that represents structured mesh whose nodes are arranged along axes of trihedron.
-To instanciate an object of this type, only n arrays are needed.
+To instantiate an object of this type, only n arrays are needed.
In this type of mesh space dimension \b and mesh dimension are equals and the value is n ( with n in [1,2,3] ).
-The n arrays will have only one component and the values contained in these arrays will be ascendantly sorted.
+The n arrays will have only one component and the values contained in these arrays will be ascendently sorted.
The class that incarnates the described concept is : ParaMEDMEM::MEDCouplingCMesh.
\section MEDCouplingCMeshStdBuild Standard building of a cartesian mesh from scratch
-Let's present an exemple of a 2D cartesian mesh.
+Let's present an example of a 2D cartesian mesh.
\subpage medcouplingcppexamplesCmeshStdBuild1 "Here the C++ implementation."
\page MEDCouplingFieldTemplatesPage Field templates in MEDCoupling
This concept appears in ICOCO API.
-field template is the adequate datastructure to perform costly interpolation matrix computation as \ref RemapperClasses "Remapper class" does.
+field template is the adequate data structure to perform costly interpolation matrix computation as \ref RemapperClasses "Remapper class" does.
So, a field template can be seen as field without double values. The double values are only used for light matrix vector multiplication.
Concretely a field template is a pair containing :
The virtual call to ParaMEDMEM::TimeLabel::updateTime change the behaviour of ParaMEDMEM::TimeLabel::getTimeOfThis it is a bug, so please notify the bug into the salome forum.
*/
+
+ LocalWords: discretization
\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 dependancies of \ref medcoupling libraries.
+willingness of reducing as much as possible the dependencies of \ref medcoupling libraries.
-As a MED file can combine several \ref medcoupling aspects in one (for exemple meshes in
+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
of \ref medloader "MEDLoader" is much more rich than simply read and write.
\ref medloader "MEDLoader" module offers two different approaches to perform Read/Write from/to MED file.
- \ref MEDLoaderAdvApproach "advanced API approach"
-- \ref MEDLoaderBasicApproach "basic API apprach"
+- \ref MEDLoaderBasicApproach "basic API approach"
Whatever the approach(es) you choose, it is advisable to know main concepts of MED files \ref MEDLoaderMainC "that are quickly reminded here."
The level of coherency check is variable across methods, to let to the user the maximal capacity of modification of its MED file data in memory.
-This API is particulary recommended :
+This API is particularly recommended :
-1. For users that want to repare a MED file (invalid family ids, invalid mesh dimension, mismatch of family ids, numbering cells/nodes array modification)
+1. For users that want to repair a MED file (invalid family ids, invalid mesh dimension, mismatch of family ids, numbering cells/nodes array modification)
2. For users that want to operate directly on complex MED file objects (split of MED files for example, duplication of nodes).
\subsection MEDLoaderBasicApproach Basic API approach
The two approaches are \b NOT opposed, they are compatible each other so it is possible to mix them.
-Typically it it is possible to read rich information of a complex MED file using advanced API in read mode, and write a simpler MED file model
-coming from a post treatement of the complex input MED file data to a simple output MED file using basic API for writing.
+Typically it is possible to read rich information of a complex MED file using advanced API in read mode, and write a simpler MED file model
+coming from a postprocessing of the complex input MED file data to a simple output MED file using basic API for writing.
\section MEDLoaderMainC Main concepts of MED files
First of all **MEDLoader will not read MED files whose version is strictly lower than 2.2.**
-For new comers in MED file world some of basics principles are recalled in the following graphic :
+For new comers in MED file world some of basics principles are recalled in the following graphic :
\image html MEDFileConcepts.png "Resumed MED file concepts"
- * stands for [0,inf)
- ? stands for 0 or 1
-Each box are **independant in MED file format during read write session.**
+Each box are **independent in MED file format during read write session.**
**Boxes instances are linked each other only by red arrows using string as discriminating key.** It implies that empty names in basic concepts objects of MED file are forbidden.
\subsection MEDLoaderCommonVocRelMeshDimMesh Relative mesh dimension in meshes
-As it has been seen \ref BasicMEDLoaderAPIGen "above", all big arrays in fields and meshes (execpted coordinates) are sorted by geometric type, without any awareness of the dimension.
+As it has been seen \ref BasicMEDLoaderAPIGen "above", all big arrays in fields and meshes (except coordinates) are sorted by geometric type, without any awareness of the dimension.
For example an unstructured mesh in MED file world can lie simultaneously on MED_TRI3, MED_POINT1, MED_POLYHED, MED_TETRA4..., \ref MEDCouplingMeshes "which is impossible in MEDCoupling" for manipulation reasons.
- 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 geometic type and the mesh dimension
+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
of the whole MED file dimension. It leads to the following **relative mesh dimension** :
- MED_TRI3 -> **relative mesh dimension** = -1
- MED_POLYHED -> **relative mesh dimension** = 0
- MED_TETRA4 -> **relative mesh dimension** = 0
-In \ref medloader "MEDLoader" all geometric information are then grouped relative dimension per relative dimension. It leads to the following geometric sorting of
+In \ref medloader "MEDLoader" all geometric information are then grouped relative dimension per relative dimension. It leads to the following geometric sorting of
MED file data structure of \a myMesh :
- Level 0
As it has been seen previously in \ref MEDLoaderCommonVocRelMeshDimMesh "for meshes", the values of fields are sorted by levels too.
-The principle is the same than those explained for meshes. The only difference is in the fact that it is possible for fields on cell and fields on
-
-gauss points that mesh dimension of underlying mesh of a field is not always (but very often) equal to the dimension of geometric types on which this field is defined.
+The principle is the same than those explained for meshes. The only difference is in the fact that it is possible for fields on cell and fields on Gauss points that mesh dimension of underlying mesh of a field is not always (but very often) equal to the dimension of geometric types on which this field is defined.
So it is advised, to compare the non empty level of a field **and** of its underlying mesh before trying to request heavy data from a MED file.
character in capital. You are intended to use these methods. The following
chapters will try to describe in details some of important ones.
-The basic idea of MEDLoader is to exploite as much as possible MED
- file capabilities to store MEDCoupling data file in a MED file and
+The basic idea of MEDLoader is to exploit as much as possible MED
+ file capabilities to store MEDCoupling data file in a MED file and
reversely to load from a MED file into a MEDCoupling data structure.
Basically, the info on components of ParaMEDMEM::DataArrayDouble
\c f->getTime(time,iteration,order) are used by MEDLoader to store
to identify the field into MED file. All strings used by MEDLoader to
use it into MED file should fulfill the rules of MED file where length
-are limited.
-That's why the user should be aware of these constaints when trying to read/write a MED file using MEDLoader.
+are limited.
+That's why the user should be aware of these constraints when trying to read/write a MED file using MEDLoader.
MEDLoader tries to manage that by protecting the user by throwing exceptions when the rules are not followed.
\section BasicMEDLoaderBasicAPIGlobalInfo Retrieving tiny global information from MED files using basic API
A field is defined by several time steps discriminated by a pair of int
(iteration,order). It is \b not possible to store 2 time steps of a same
field having the same iteration and order
-number. The floatting point value attached on this couple of ids (iteration,order) is only present for information.
+number. The floating point value attached on this couple of ids (iteration,order) is only present for information.
Static methods MEDLoader::GetCellFieldIterations and
MEDLoader::GetNodeFieldIterations return a vector of pair containing
each respectively iteration and order.
-A time step of a field lyies on one \b or \b more mesh(es) specified by its \b or \b their name. A time step of a field in
-MED file could be defined on point \b and on cell \b and, \b or on gauss points \b and, \b or on point per element.
+A time step of a field lies on one \b or \b more mesh(es) specified by its \b or \b their name. A time step of a field in
+MED file could be defined on point \b and on cell \b and, \b or on Gauss points \b and, \b or on point per element.
This recalled specificities of MED file explains that it is necessary to specify each time, at field-read time, the type of field, the iteration and order number the mesh you are interested in.
by an integer field on \b all nodes and on \b all cells of a same mesh.
All cells and nodes having the same ids defines this family. This id
is called the familyId. A family is discriminated by its id. MED file
-attach a name to its id to be more userfriendly. So by construction, 2 different
+attach a name to its id to be more user friendly. So by construction, 2 different
families could not share anything. The user can retrieve all the
families names available on a mesh with the static method MEDLoader::GetMeshFamiliesNames.
\subsection BasicMEDLoaderAPIField Reading a field at one time step in MED files
A field at one time step on one mesh, with one entity (cell, node)
-lies on all mesh on on a part of it. In this last case a definition of
+lies on all mesh on a part of it. In this last case a definition of
a profile is needed. Even if the notions of profile on mesh and group
on mesh could appear close, these two concepts are totally
disconnected in MED file.
-The aspect of profile is managed by MEDLoader, thats why this
+The aspect of profile is managed by MEDLoader, that is why this
aspect does not appear in the MEDLoader API.
So to retrieve a field on 3D cell called "F1Cell" in example file
\ref MEDLoaderExample2 "file2.med (seen in meshes section)" on a mesh "Example2" on time
\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_12
-To retrive the same field (same iteration) on 2D cells only the call will be :
+To retrieve the same field (same iteration) on 2D cells only the call will be :
\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_13
It is possible with MEDLoader to read several time steps of a field at
a time.
The advantage with this approach is to avoid to read and load several
-time a same mesh. This is typically recommanded to use the following
+time a same mesh. This is typically recommended to use the following
code when you desire to load all time steps of a field on cell "myField" lying on
same mesh "mesh1" in one shot :
is set to \b false :
- Methods \b MEDLoader::Write*Dep : The write operation is performed without any question in file. The
- responsability is let to the user because the MED file could be
+ responsibility is let to the user because the MED file could be
corrupted. The advantage of this method is that it is faster
because no check is done.
- Methods \b MEDLoader::Write* : MEDLoader will not corrupt your file
groups and families from given meshes. As in the previous case the
check of same coords will be done (if not an INTERP_KERNEL::Exception is
thrown). After this step this method will
- merge (by concerving the order in input) and will simplify the
+ merge (by preserving order in input) and will simplify the
merged mesh. After this operation, the groups will be constituted by
- assigning the groups names with the conresponding names of
+ assigning the groups names with the corresponding names of
instance. That's why all meshes have to have a not empty name and
different each other. The method to use in this case is
MEDLoader::WriteUMeshesPartition.
\subsection MEDLoaderWriteField Writing one time step of a field in a MED file with MEDLoader
To write \b one \b time \b step of a field from scratch with MEDLoader is to
-use MEDLoader::WriteField method. The behviour of this method depends
-on the value of the \b writeFromScratch paramter :
+use MEDLoader::WriteField method. The behaviour of this method depends
+on the value of the \b writeFromScratch parameter :
- When \b writeFromScratch equals to \b true, this method performs two things, it
writes the underlying mesh and write the specified time step on it.
concept has been introduced. \c meshDimRelToMaxExt parameter can take a value in at
most {1,0,-1,-2,-3}.
1 stands for node and 0,-1,-2,-3 has exactly the
-same semantic than those described in \c meshDimRelToMax decribed
+same semantic than those described in \c meshDimRelToMax described
before.
- A parameter that also often appears in advanced %MEDLoader API is \c renum.
If the user expects to ignore this renumbering even in case of
presence of renumbering array, false should be passed to \c renum
parameter. \b The \b parameter \b renum \b should \b be \b set \b with
-\b cauton \b for \b users \b concerned \b by \b cells \b orders.
+\b caution \b for \b users \b concerned \b by \b cells \b orders.
-- A laster important parameter is the \c mode during writing. The
+- A last important parameter is the \c mode during writing. The
available values for the parameter \c mode are :
- 2 : for a write from scratch. If file already exists, file will be
erased and replace by the content of the instance on which \c write
- method has been calles.
+ method has been called.
- 1 : If the file does not exists equivalent to 2. If file already
exists, the write is done on APPEND mode. That is to say that no
data loss will occur. But in case that an element with same ids than
be thrown.
An important point is that families and groups are \b not sorted in
-MED file. No sort is stored in MED file explicitely for Groups and
+MED file. No sort is stored in MED file explicitly for Groups and
Families. Advanced %MEDLoader API, uses the same order than underlying
mesh at specified level.
\subsection AdvMEDLoaderAPIMeshWriting Writing a mesh.
-The use is very symetric to reading part. It is possible to either
+The use is very symmetric to reading part. It is possible to either
build a \ref ParaMEDMEM::MEDFileUMesh "MEDFileUMesh" instance from
scratch, or to work with an existing instance coming from a loading
from a file.
- Level -5 : ParaMEDMEM::MEDFileFieldPerMeshPerTypePerDisc
-In each level in tree of the the cyan box of field is represented by a class. The only difference is that values are grouped in a single big array located
+In each level in tree of the cyan box of field is represented by a class. The only difference is that values are grouped in a single big array located
in level -2 (ParaMEDMEM::MEDFileField1TSWithoutSDA) in which each leaves (level -5) of MED file field
point to using a range [\a start, \a end).
-As different time steps of a same field and different field inside a MED file can shared or not profiles (yellow box) and Locatization (red box) a manipulable field classes instance
+As different time steps of a same field and different field inside a MED file can shared or not profiles (yellow box) and localization (red box) a manipulable field classes instance
(ParaMEDMEM::MEDFileField1TS and ParaMEDMEM::MEDFileFieldMultiTS) in advanced API are the result of a subclass of a data class
(respectively ParaMEDMEM::MEDFileField1TSWithoutSDA, ParaMEDMEM::MEDFileFieldMultiTSWithoutSDA) and a instance of ParaMEDMEM::MEDFileFieldGlobsReal representing the shared data arrays (SDA)
at a specified scope inside the MED file.
Fields defined partially on a meshes can been read using 2 main approaches :
-- Either the user wants to retreave it's field in %MEDCoupling sense, that is to say for interpolation, to evaluate such field on different points...
+- Either the user wants to retrieve it's field in %MEDCoupling sense, that is to say for interpolation, to evaluate such field on different points...
\n In this mode the link with the whole mesh is not useful for the user
\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_3
\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_4
\ref medcoupling "MEDCoupling" allows to make bridges between the approaches. For example \a pfl \ref ParaMEDMEM::DataArrayInt "DataArrayInt instance" retrieved directly
-from the file in the second approach can be retrived starting from first approach.
+from the file in the second approach can be retrieved starting from first approach.
Starting from mesh \a firstApproachMesh of read field in first approach \a fread, whith the whole mesh \a wholeMesh the profile \a pflComputed can be computed :
\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_5
-Inversely, it is possible to rebuild field obtained in first apprach starting from second approach :
+Inversely, it is possible to rebuild field obtained in first approach starting from second approach :
\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_6
\section InterpKerMidLevUsage Middle-level usage
This mode is the mode that needs the minimum of prerequisites
-(algorithms and the datastructure you intend to use). On the other
+(algorithms and the data structure you intend to use). On the other
hand it is needed to specify precisely nature of interpolator.
As consequence of the genericity of the interpolators, they are usable only by
-instanciating an underlying \ref InterpKerMeshType "mesh" and \ref InterpKerMatrixType "matrix" data structure fulfilling some requirements. The two following
+instantiating an underlying \ref InterpKerMeshType "mesh" and \ref InterpKerMatrixType "matrix" data structure fulfilling some requirements. The two following
examples show how to use interpolator at this level.
-- The simplest way to use the interpolator with \ref medcoupling datastruture is illustrated in the following example.
+- The simplest way to use the interpolator with \ref medcoupling data struture is illustrated in the following example.
\code
...
\endcode
-- Same with VTK datastructure :
+- Same with VTK data structure :
\code
...
VTKNormalizedUnstructuredMesh<2> wrap_target_mesh(vtk_target_mesh);
// Go for interpolation...
INTERP_KERNEL::Interpolation2D myInterpolator;
-//optionnal call to parametrize your interpolation. First precision, tracelevel, intersector wanted.
+//optional call to parametrize your interpolation. First precision, tracelevel, intersector wanted.
myInterpolator.setOptions(1e-7,0,Geometric2D);
INTERP_KERNEL::Matrix<double,ALL_C_MODE> resultMatrix;
myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0");
...
\endcode
-*/
\ No newline at end of file
+*/
