From: aguerre Date: Mon, 12 Aug 2013 12:39:17 +0000 (+0000) Subject: Fix some typos X-Git-Tag: DBugPolyhIntersector~19 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=f7095fccd427957d5bb264c9599b95770058328c;p=modules%2Fmed.git Fix some typos --- diff --git a/doc/doxygen/Geometric2D.dox b/doc/doxygen/Geometric2D.dox index 5f1f51dd7..e97cf0e83 100644 --- a/doc/doxygen/Geometric2D.dox +++ b/doc/doxygen/Geometric2D.dox @@ -6,7 +6,7 @@ polygons.\n 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. @@ -65,9 +65,9 @@ The process of boolean operations between two polygons P1 and P2 is done in thre 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. @@ -83,7 +83,7 @@ Perform localization of each splitted edge. As \ref interpkernelGeo2DBoolOpStep1 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 @@ -113,7 +113,7 @@ edges localized as \b in or \b on. 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. @@ -128,11 +128,11 @@ that we are sure that the edge is either \b fully \b in ,or \b fully \b on or \b 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. @@ -144,7 +144,7 @@ during intersecting process. \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 @@ -229,7 +229,7 @@ Too finish \ref interpkernelGeo2DBoolOpStep3 "closing" polygons. \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. diff --git a/doc/doxygen/barycoords.dox b/doc/doxygen/barycoords.dox index e55c64887..874fae61b 100644 --- a/doc/doxygen/barycoords.dox +++ b/doc/doxygen/barycoords.dox @@ -12,7 +12,7 @@ Input of the algorithm includes - coordinates of a barycentre of cells intersection (b),
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 @@ -30,10 +30,10 @@ in 3D case 
 | y1-y4 y2-y4 y3-y4 |
 | z1-z4 z2-z4 z3-z4 |
-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. */ diff --git a/doc/doxygen/interpkernel.dox b/doc/doxygen/interpkernel.dox index ccb1c3a78..28473e091 100644 --- a/doc/doxygen/interpkernel.dox +++ b/doc/doxygen/interpkernel.dox @@ -4,8 +4,8 @@ \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. @@ -20,7 +20,7 @@ filling the interpolation matrix W (which is generally sparse). For each pair (i 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 @@ -35,11 +35,11 @@ template (CRTP) class than enable an easy access to the main API without useless \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 : diff --git a/doc/doxygen/interptheory.dox b/doc/doxygen/interptheory.dox index 4fd32b8bb..937945bca 100644 --- a/doc/doxygen/interptheory.dox +++ b/doc/doxygen/interptheory.dox @@ -1,7 +1,7 @@ /*! \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. @@ -9,7 +9,7 @@ For fields with polynomial representation on each cell, the components of the di \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 @@ -25,7 +25,7 @@ formula \anchor InterpKerGenralEq has to 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 @@ -43,16 +43,16 @@ fully overlapped by cells of S that is \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 @@ -61,7 +61,7 @@ For intensive fields such as mass density or power density, the 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 @@ -71,7 +71,7 @@ In the \ref InterpKerGenralEq "general interpolation equation" 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 @@ -79,20 +79,20 @@ cell, the coefficients of the linear remapping matrix \f$ W \f$ are 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 : @@ -106,10 +106,10 @@ The coefficients of the linear remapping matrix \f$ W \f$ are then 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: * @@ -137,7 +137,7 @@ The first step of the interpolation leads to the following M1 matrix : 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 : @@ -162,8 +162,8 @@ If we apply the formula \ref TableNatureOfField "above" it leads to the followin \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 @@ -202,8 +202,8 @@ This type of interpolation is equivalent to the computation of \f$ FS_{vol} \f$ 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 @@ -261,11 +261,12 @@ If we apply the formula \ref TableNatureOfField "above" it leads to the followin 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. */ + diff --git a/doc/doxygen/intersectors.dox b/doc/doxygen/intersectors.dox index f08f36241..3f212f835 100755 --- a/doc/doxygen/intersectors.dox +++ b/doc/doxygen/intersectors.dox @@ -25,11 +25,11 @@ For the moment, it is only possible to remap two dimensional fields on 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. @@ -43,10 +43,10 @@ The following options are available for the 2D intersection computations: * *
PrintLevel Level of verboseness during the computations 0, 1, 2, 3 0
-\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: * @@ -61,8 +61,8 @@ Similar options as for the 2D remapping are available, plus some additional opti system such that the median plane is the Oxy plane * - * - * + * + * *
boolean true or false true
BoundingBoxAdjustmentWhen 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. positive real numbers 1.e-4
BoundingBoxAdjustmentAbsWhen 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. positive real numbers 0.
MaxDistance3DSurfIntersectBefore 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 real numbers -1.
BoundingBoxAdjustmentAbsWhen 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. positive real numbers 0.
MaxDistance3DSurfIntersectBefore 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 real numbers -1.
Note that choosing the Triangle Intersection_type necessarily set the DoRotate option to true. @@ -90,7 +90,7 @@ polyhedra into several tetrahedron-polyhedron intersection 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. @@ -106,9 +106,9 @@ principle than described in 2D. * 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 /| /| / | / | diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox index 3f36e5e04..cb275c482 100644 --- a/doc/doxygen/main.dox +++ b/doc/doxygen/main.dox @@ -18,7 +18,7 @@ library: \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 @@ -63,7 +63,7 @@ installing the module an be found in \ref paramedmem_install. 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} diff --git a/doc/doxygen/medcoupling.dox b/doc/doxygen/medcoupling.dox index 70b91bf49..14c3a61c2 100644 --- a/doc/doxygen/medcoupling.dox +++ b/doc/doxygen/medcoupling.dox @@ -10,7 +10,7 @@ - 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 @@ -55,15 +55,15 @@ In MEDCoupling library there is no presence of faces nor edges. 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" @@ -82,7 +82,7 @@ possibly temporal support. 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. @@ -114,7 +114,7 @@ Some of most important implemented methods are : - \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"). @@ -129,7 +129,7 @@ The most important pure virtual methods are : \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). @@ -207,7 +207,7 @@ There are for the moment two types of arrays : - 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". @@ -220,7 +220,7 @@ It will be presented in this section common concept shared by the two classes to 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. @@ -264,12 +264,12 @@ For example, let's consider a DataArray having 3 components (called *x* for the 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. @@ -282,7 +282,7 @@ If the user in C++ or Python wants to modify intensively its **big** \ref ParaME \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 @@ -348,13 +348,13 @@ but the use of \ref ParaMEDMEM::DataArrayInt "DataArrayInt" is strictly equivale 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 : @@ -365,7 +365,7 @@ or : \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 @@ -413,7 +413,7 @@ But the behaviour is the same than those seen for \ref MEDCouplingArrayBasicsCop \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 @@ -455,7 +455,7 @@ Formally a renumbering is a mathematical application that can be surjective, inj \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 @@ -478,11 +478,11 @@ Method in old to new mode that works on surjective applications : - \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. @@ -519,11 +519,11 @@ There are different API for applyFunc* methods of \ref ParaMEDMEM::DataArrayDoub \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 @@ -539,7 +539,7 @@ The dynamic expression evaluator works tuple by tuple through the *raw data* of 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. @@ -569,8 +569,8 @@ So \c smth represent a tuple of size 2. 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. @@ -580,7 +580,7 @@ In this example using IVec and JVec it is possible to differentiate output in co \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. @@ -592,8 +592,8 @@ Let's consider the following DataArrayDouble having 4 tuples with 3 components c \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 @@ -606,7 +606,7 @@ the component id. The strategy of expression evaluator is the following. Sort as 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. @@ -653,7 +653,7 @@ Let's consider DataArrayDouble instance \c ddd constituted with 4 tuples contain 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. @@ -673,7 +673,7 @@ Finally we consider that fields with P1 or P2 representations are necessarily in \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 @@ -704,7 +704,7 @@ sourceField->setNature(ConservativeVolumic); /*! \page MEDCouplingUMeshPage Unstructured meshes in MEDCoupling - + [TOC] An unstructured mesh in \ref medcoupling MEDCoupling is defined by : @@ -712,7 +712,7 @@ 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 @@ -733,7 +733,7 @@ The class that incarnates the described concept is : ParaMEDMEM::MEDCouplingUMes 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. @@ -772,11 +772,11 @@ The same mesh than \ref MEDCouplingUMeshStdBuild "in the standard section above" /*! \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 : @@ -795,17 +795,17 @@ Some of most important implemented methods by \ref ParaMEDMEM::MEDCouplingPointS 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." @@ -834,7 +834,7 @@ The class that incarnates this concept in MEDCoupling is : \ref ParaMEDMEM::MEDC \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 : @@ -868,3 +868,5 @@ The usage is simple : 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 diff --git a/doc/doxygen/medloader.dox b/doc/doxygen/medloader.dox index 5f1c2b10b..98eaa6c06 100644 --- a/doc/doxygen/medloader.dox +++ b/doc/doxygen/medloader.dox @@ -8,9 +8,9 @@ \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. @@ -22,7 +22,7 @@ But it is possible to emulate with a very good fidelity a MED file mesh and a ME \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." @@ -45,9 +45,9 @@ This is typically the case for a user that wants to precisely set/get mesh/group 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 @@ -73,8 +73,8 @@ As MED file concepts are more complex than MEDCoupling concepts, this approach i 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 @@ -85,7 +85,7 @@ use the best methods proposed by \ref medloader "MEDLoader API". 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" @@ -95,7 +95,7 @@ Inside the parenthesis, there is multiplicity : - * 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. @@ -117,7 +117,7 @@ This specificity leads to a constraint during writing phase because some mesh op \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. @@ -134,7 +134,7 @@ For each geometric type on which \a myMesh is defined the mesh dimension are : - 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 @@ -142,7 +142,7 @@ of the whole MED file dimension. It leads to the following **relative mesh dimen - 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 @@ -161,9 +161,7 @@ The mesh dimension of \a myMesh is 3. The relative mesh dimensions available are 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. @@ -197,8 +195,8 @@ internal state. That's why the basic API of MEDLoader offers \b only \b static m 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 @@ -209,8 +207,8 @@ MED file. A field f with \ref ParaMEDMEM::MEDCouplingTimeDiscretization \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 @@ -222,13 +220,13 @@ respectively on cells and on nodes lying on a specified mesh. 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. @@ -302,7 +300,7 @@ A mesh contains one or more families on nodes and/or on cells. A family is a par 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. @@ -319,11 +317,11 @@ same returned mesh. \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 @@ -331,7 +329,7 @@ step defined by iteration number 2 and iteration 3 the request will be : \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 @@ -340,7 +338,7 @@ To retrive the same field (same iteration) on 2D cells only the call will be : 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 : @@ -370,7 +368,7 @@ Two classes of MEDLoader write methods exists when \b writeFromScratch 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 @@ -425,9 +423,9 @@ possiblities are possible : 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. @@ -443,8 +441,8 @@ MEDLoader::WriteUMeshes. \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. @@ -526,7 +524,7 @@ nodes, (for example families, groups, numbering ) that's why for a simpler API t 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. @@ -543,13 +541,13 @@ exactly the behaviour of \ref MEDLoader::ReadUMeshFromFile "basic MEDLoader API" 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 @@ -632,7 +630,7 @@ family id of each cell or node. If it does not exist an exception will 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. @@ -665,7 +663,7 @@ medmesh->decrRef(); \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. @@ -743,11 +741,11 @@ Here the list of classes in %MEDLoader advanced API top down sorted : - 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. @@ -788,7 +786,7 @@ by \a iteration and \a order. 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 @@ -798,13 +796,13 @@ Fields defined partially on a meshes can been read using 2 main approaches : \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 diff --git a/doc/doxygen/remapper.dox b/doc/doxygen/remapper.dox index 5f2cfcac4..e37e89c30 100644 --- a/doc/doxygen/remapper.dox +++ b/doc/doxygen/remapper.dox @@ -32,14 +32,14 @@ med_target_mesh->decrRef(); \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 ... @@ -61,7 +61,7 @@ myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2 \endcode -- Same with VTK datastructure : +- Same with VTK data structure : \code ... @@ -79,7 +79,7 @@ VTKNormalizedUnstructuredMesh<2> wrap_source_mesh(vtk_source_mesh); 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 resultMatrix; myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); @@ -91,4 +91,4 @@ readerTarget->Delete(); ... \endcode -*/ \ No newline at end of file +*/