From: aguerre Date: Tue, 10 Sep 2013 16:00:51 +0000 (+0000) Subject: Changes in doc organization. X-Git-Tag: V7_3_1b1~155 X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=b13c86b02f5c5126fe62753266171b6f59ba5f0d;p=tools%2Fmedcoupling.git Changes in doc organization. --- diff --git a/doc/doxygen/BuildPyExamplesFromCPP.py b/doc/doxygen/BuildPyExamplesFromCPP.py index a31ee207d..d30bc00a1 100644 --- a/doc/doxygen/BuildPyExamplesFromCPP.py +++ b/doc/doxygen/BuildPyExamplesFromCPP.py @@ -22,19 +22,56 @@ import sys import re import os -def Cpp2Python(st): - st=st.replace("C++","Python") - st=st.replace("Cxx","Py") - st=st.replace("Cpp","Py") - st=st.replace("cxx","py") - st=st.replace("cpp","py") - return st +# :TRICKY: +# In input file, contents delimited by two lines containing BEGIN_CPP_ONLY and +# END_CPP_ONLY strings respectively, will only appear in C++ documentation. +# The same rule applies for Python-specific contents. + +def Cpp2Python(contents): + cpp_only = False + output = [] + for st in contents: + if "BEGIN_CPP_ONLY" in st: + cpp_only = True + elif "END_CPP_ONLY" in st: + cpp_only = False + elif not cpp_only: + st=st.replace("C++","Python") + st=st.replace("Cxx","Py") + st=st.replace("Cpp","Py") + st=st.replace("cxx","py") + st=st.replace("cpp","py") + output.append(st) + pass + pass + + return output +# +def discardPythonFrom(contents): + python_only = False + output = [] + for st in contents: + if "BEGIN_PYTHON_ONLY" in st: + python_only = True + elif "END_PYTHON_ONLY" in st: + python_only = False + elif not python_only: + output.append(st) + pass + pass + + return output + # +# + fCpp=file(sys.argv[1],"r") cppCont=fCpp.readlines() ; del fCpp pyCont=cppCont[:] pyCont=[elt.replace("medcouplingcppexamples","medcouplingpyexamples") for elt in pyCont] -pyCont=[Cpp2Python(elt) for elt in pyCont] +pyCont=Cpp2Python(pyCont) + +cppCont=discardPythonFrom(cppCont) # remove Python-only contents from Cpp outFileName=os.path.join(sys.argv[2],os.path.basename(sys.argv[1])) diff --git a/doc/doxygen/CMakeLists.txt b/doc/doxygen/CMakeLists.txt index 1dde0d94f..928d2a6ce 100644 --- a/doc/doxygen/CMakeLists.txt +++ b/doc/doxygen/CMakeLists.txt @@ -27,14 +27,47 @@ FOREACH(indoxfile ${indoxfiles}) CONFIGURE_FILE(${input} ${output}) MESSAGE(STATUS "Creation of ${output}") ENDFOREACH(indoxfile ${indoxfiles}) -FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/medcouplingexamples.doxy" input) +FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/medcouplingexamples.in" input) FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/BuildPyExamplesFromCPP.py" pythondocexamplesgenerator) FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}" output) + +# :TRICKY: For ease of maintenance, documentation for code examples is +# splitted in several files. We here splice to a single file before running +# Doxygen. + +SET(EXAMPLE_FILES # files to concatenate: order is important! + doxfiles/examples/medcouplingexamplesheader.doxy + doxfiles/examples/medcouplingexamplesfields.doxy + doxfiles/examples/medcouplingexamplesmeshes.doxy + doxfiles/examples/medcouplingexamplesarrays.doxy + doxfiles/examples/medcouplingexamplesother.doxy + doxfiles/examples/medcouplingexamplesfooter.doxy + ) + +# This function adds IN_FILE contents to the end of OUT_FILE +FUNCTION(concat IN_FILE OUT_FILE) + FILE(READ ${IN_FILE} CONTENTS) + FILE(APPEND ${OUT_FILE} ${CONTENTS}) +ENDFUNCTION() + +# Prepare a temporary file to "concat" to: +FILE(WRITE medcouplingexamples.in "") +# Call the "concat" function for each example file +FOREACH(EXAMPLE_FILE ${EXAMPLE_FILES}) + concat(${EXAMPLE_FILE} medcouplingexamples.in) +ENDFOREACH() +# Copy the temporary file to the final location +CONFIGURE_FILE(medcouplingexamples.in ${CMAKE_CURRENT_BINARY_DIR}/medcouplingexamples.dox) +# Note: The reason for writing to a temporary is so the real target file only +# gets updated if its content has changed. + + +# Here is the "standard" procedure, as if ${input} was hand-written. ADD_CUSTOM_TARGET(usr_docs ALL COMMAND ${PYTHON_EXECUTABLE} ${pythondocexamplesgenerator} ${input} ${output} COMMAND ${DOXYGEN_EXECUTABLE} Doxyfile_med_user COMMAND ${PYTHON_EXECUTABLE} -c "import shutil, sys; shutil.rmtree(r'''${CMAKE_INSTALL_PREFIX}/share/doc/salome/gui/MED''', True); shutil.copytree(r'''${CMAKE_CURRENT_BINARY_DIR}/doc_ref_user/html''', r'''${CMAKE_INSTALL_PREFIX}/share/doc/salome/gui/MED'''); shutil.copy(r'''${CMAKE_CURRENT_SOURCE_DIR}/images/head.png''', r'''${CMAKE_INSTALL_PREFIX}/share/doc/salome/gui/MED''')" - VERBATIM - WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} + VERBATIM + WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) diff --git a/doc/doxygen/Doxyfile_med_user.in b/doc/doxygen/Doxyfile_med_user.in index d96726d47..c6b21a863 100644 --- a/doc/doxygen/Doxyfile_med_user.in +++ b/doc/doxygen/Doxyfile_med_user.in @@ -35,7 +35,7 @@ BRIEF_MEMBER_DESC = NO REPEAT_BRIEF = YES ALWAYS_DETAILED_SEC = NO FULL_PATH_NAMES = NO -STRIP_FROM_PATH = +STRIP_FROM_PATH = INTERNAL_DOCS = NO STRIP_CODE_COMMENTS = YES CASE_SENSE_NAMES = YES @@ -53,7 +53,7 @@ TAB_SIZE = 8 GENERATE_TODOLIST = YES GENERATE_TESTLIST = YES GENERATE_BUGLIST = YES -ALIASES = +ALIASES = ENABLED_SECTIONS = user MEDCOUPLING_ug MAX_INITIALIZER_LINES = 30 OPTIMIZE_OUTPUT_FOR_C = NO @@ -70,17 +70,20 @@ WARN_LOGFILE = log_user # configuration options related to the input files #--------------------------------------------------------------------------- INPUT = @builddir@ \ - @srcdir@ \ - @srcdir@/fakesources \ + @srcdir@/doxfiles \ + @srcdir@/doxfiles/medcoupling \ + @srcdir@/doxfiles/medloader \ + @srcdir@/doxfiles/interpolation \ + @srcdir@/fakesources \ @srcdir@/../../src/ParaMEDMEM \ @srcdir@/../../src/INTERP_KERNEL \ - @srcdir@/../../src/INTERP_KERNEL/Bases \ + @srcdir@/../../src/INTERP_KERNEL/Bases \ @srcdir@/../../src/INTERP_KERNEL/Geometric2D \ @srcdir@/../../src/MEDCoupling \ - @srcdir@/../../src/MEDLoader + @srcdir@/../../src/MEDLoader FILE_PATTERNS = InterpKernelDEC.* \ - OverlapDEC.* \ + OverlapDEC.* \ DEC.* \ DisjointDEC.* \ MPIProcessorGroup.* \ @@ -88,8 +91,8 @@ FILE_PATTERNS = InterpKernelDEC.* \ ExplicitCoincidentDEC.* \ NonCoincidentDEC.* \ CommInterface.* \ - NormalizedGeometricTypes \ - NormalizedUnstructuredMesh.* \ + NormalizedGeometricTypes \ + NormalizedUnstructuredMesh.* \ Interpolation2D.* \ Interpolation3D.* \ Interpolation3DSurf.* \ @@ -97,7 +100,7 @@ FILE_PATTERNS = InterpKernelDEC.* \ PlanarIntersector.* \ TargetIntersector.* \ Interpolation.* \ - InterpolationOptions.* \ + InterpolationOptions.* \ InterpKernelGeo2DAbstractEdge.* \ InterpKernelGeo2DEdge.* \ InterpKernelGeo2DEdgeArcCircle.* \ @@ -109,17 +112,17 @@ FILE_PATTERNS = InterpKernelDEC.* \ ParaFIELD.* \ MEDCouplingMesh.* \ MEDCouplingUMesh.* \ - MEDCoupling1GTUMesh.* \ + MEDCoupling1GTUMesh.* \ MEDCouplingPointSet.* \ MEDCouplingCMesh.* \ - MEDCouplingStructuredMesh.* \ - MEDCouplingCurveLinearMesh.* \ + MEDCouplingStructuredMesh.* \ + MEDCouplingCurveLinearMesh.* \ MEDCouplingExtrudedMesh.* \ MEDCouplingFieldDouble.* \ MEDCouplingField.* \ - MEDCouplingNatureOfFieldEnum - MEDCouplingNatureOfField.hxx \ - MEDCouplingFieldTemplate.* \ + MEDCouplingNatureOfFieldEnum \ + MEDCouplingNatureOfField.hxx \ + MEDCouplingFieldTemplate.* \ MEDCouplingFieldDiscretization.* \ MEDCouplingTimeDiscretization.* \ MEDCouplingTimeLabel.* \ @@ -128,19 +131,19 @@ FILE_PATTERNS = InterpKernelDEC.* \ MEDCouplingRemapper.* \ MEDLoader.* \ MEDFileMesh.* \ - MEDFileField.* \ + MEDFileField.* \ *.dox -RECURSIVE = NO +RECURSIVE = YES EXCLUDE = CVS EXCLUDE_PATTERNS = *~ EXAMPLE_PATH = @srcdir@/../../src/ParaMEDMEM \ - @srcdir@/../../src/MEDCoupling/Test \ - @srcdir@/../../src/MEDCoupling_Swig \ - @srcdir@/../../src/MEDLoader/Swig + @srcdir@/../../src/MEDCoupling/Test \ + @srcdir@/../../src/MEDCoupling_Swig \ + @srcdir@/../../src/MEDLoader/Swig EXAMPLE_PATTERNS = *.cxx *.py EXAMPLE_RECURSIVE = NO IMAGE_PATH = @srcdir@/figures -INPUT_FILTER = +INPUT_FILTER = FILTER_SOURCE_FILES = NO #--------------------------------------------------------------------------- # configuration options related to source browsing @@ -154,7 +157,7 @@ REFERENCES_RELATION = YES #--------------------------------------------------------------------------- ALPHABETICAL_INDEX = YES COLS_IN_ALPHA_INDEX = 5 -IGNORE_PREFIX = +IGNORE_PREFIX = #--------------------------------------------------------------------------- # configuration options related to the HTML output #--------------------------------------------------------------------------- @@ -185,8 +188,8 @@ GENERATE_LATEX = YES LATEX_OUTPUT = latex COMPACT_LATEX = YES PAPER_TYPE = a4wide -EXTRA_PACKAGES = -LATEX_HEADER = +EXTRA_PACKAGES = +LATEX_HEADER = PDF_HYPERLINKS = NO USE_PDFLATEX = NO LATEX_BATCHMODE = NO @@ -197,8 +200,8 @@ GENERATE_RTF = NO RTF_OUTPUT = rtf COMPACT_RTF = NO RTF_HYPERLINKS = NO -RTF_STYLESHEET_FILE = -RTF_EXTENSIONS_FILE = +RTF_STYLESHEET_FILE = +RTF_EXTENSIONS_FILE = #--------------------------------------------------------------------------- # configuration options related to the man page output #--------------------------------------------------------------------------- @@ -211,26 +214,26 @@ MAN_LINKS = NO #--------------------------------------------------------------------------- GENERATE_XML = NO #--------------------------------------------------------------------------- -# Configuration options related to the preprocessor +# Configuration options related to the preprocessor #--------------------------------------------------------------------------- ENABLE_PREPROCESSING = YES MACRO_EXPANSION = YES EXPAND_ONLY_PREDEF = YES SEARCH_INCLUDES = YES -INCLUDE_PATH = -INCLUDE_FILE_PATTERNS = -PREDEFINED = +INCLUDE_PATH = +INCLUDE_FILE_PATTERNS = +PREDEFINED = EXPAND_AS_DEFINED = MEDCOUPLING_EXPORT MEDCOUPLINGREMAPPER_EXPORT MEDLOADER_EXPORT SKIP_FUNCTION_MACROS = YES #--------------------------------------------------------------------------- -# Configuration::addtions related to external references +# Configuration::addtions related to external references #--------------------------------------------------------------------------- -TAGFILES = -GENERATE_TAGFILE = +TAGFILES = +GENERATE_TAGFILE = ALLEXTERNALS = NO PERL_PATH = /usr/bin/perl #--------------------------------------------------------------------------- -# Configuration options related to the dot tool +# Configuration options related to the dot tool #--------------------------------------------------------------------------- CLASS_DIAGRAMS = YES HAVE_DOT = YES @@ -241,20 +244,20 @@ HIDE_UNDOC_RELATIONS = YES INCLUDE_GRAPH = YES INCLUDED_BY_GRAPH = YES GRAPHICAL_HIERARCHY = YES -DOT_PATH = +DOT_PATH = DOT_FONTNAME = Arial -DOTFILE_DIRS = +DOTFILE_DIRS = MAX_DOT_GRAPH_WIDTH = 1024 MAX_DOT_GRAPH_HEIGHT = 1024 GENERATE_LEGEND = YES DOT_CLEANUP = YES #--------------------------------------------------------------------------- -# Configuration::addtions related to the search engine +# Configuration::addtions related to the search engine #--------------------------------------------------------------------------- SEARCHENGINE = NO CGI_NAME = search.cgi -CGI_URL = -DOC_URL = -DOC_ABSPATH = +CGI_URL = +DOC_URL = +DOC_ABSPATH = BIN_ABSPATH = /usr/local/bin/ -EXT_DOC_PATHS = +EXT_DOC_PATHS = diff --git a/doc/doxygen/Geometric2D.dox b/doc/doxygen/Geometric2D.dox deleted file mode 100644 index e97cf0e83..000000000 --- a/doc/doxygen/Geometric2D.dox +++ /dev/null @@ -1,237 +0,0 @@ -/*! -\page interpkernelGeo2D Geometric2D Intersector - -Like other intersectors the aim of this intersector is to compute intersection between 2 -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 -potentially useful functions.\n -This page described Geometric2D intersector basic principles and -specific usage. - -\section interpkernelGeo2DIntro Introduction - -The principle used in this intersector to perform boolean operation on geometry is geometric-modeler like. -The data structure used to describe polygons is boundary description. That is to say the internal -representation of a polygon is its edges composing it. - -\subsection interpkernelGeo2DNamingConv Naming conventions - - - An \ref INTERP_KERNEL::AbstractEdge "edge" is defined by a start - node, a end node and a curve equation (linear or arc of - circle). \b WARNING : start node and end node \b HAVE \b TO \b BE - different and distant at least equal to precision set. - - An \ref INTERP_KERNEL::ElementaryEdge "elementary edge" is an edge \b NOT \b splittable \b without \b applying - \b mathematical \b intersection \b computation. - - A \ref INTERP_KERNEL::ComposedEdge "composed edge" is a collection of consecutive edges hierarchically \b splittable - \b without \b any \b mathematical \b intersection \b computation. - -Consecutive means that in a composed edge if edge \a e2 follows edge -\a e1, the end node of \a e1 is geometrically equal to start node of -\a e2. - -\subsection interpkernelGeo2DBasicConcepts Basic concepts - -A \ref INTERP_KERNEL::QuadraticPolygon "quadratic polygon" is a -specialization of a -\ref INTERP_KERNEL::ComposedEdge "composed edge" in that it is -closed. Closed means that the start node of first edge is equal to end -node of last edge.\n -A \ref INTERP_KERNEL::ComposedEdge "composed edge" is considered as a -collection of \ref INTERP_KERNEL::AbstractEdge "abstract edges". An -\ref INTERP_KERNEL::AbstractEdge "abstract edge" is either an \ref -INTERP_KERNEL::ElementaryEdge "elementary edge" or itself a \ref -INTERP_KERNEL::ComposedEdge "composed edge".\n A composite pattern has -been used here. - -Each \ref INTERP_KERNEL::ElementaryEdge " elementary edge" and each -\ref INTERP_KERNEL::Node "nodes" have a flag that states if during -the split process if it is \b out, \b on, \b in or \b unknown. - -\section interpkernelGeo2DBoolOp Boolean operation algorithm - -\subsection interpkernelGeo2DBoolOpPrinc Basics - -The boolean operation (intersection) between two polygons is used in P0 P0 interpolation. - -The process of boolean operations between two polygons P1 and P2 is done in three steps : - - -# \ref interpkernelGeo2DBoolOpStep1 "splitting". - -# \ref interpkernelGeo2DBoolOpStep2 "edges localization". - -# \ref interpkernelGeo2DBoolOpStep3 "result polygons building". - -\subsection interpkernelGeo2DBoolOpStep1 Step1 : splitting. - -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 -\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 -\ref INTERP_KERNEL::ElementaryEdge "elementary edge" constituting P2 -is either \b in, \b out or \b on polygon P1. - -During split process, when, without any CPU overhead, the location can be -deduced, the nodes and edges are localized. - -This step of splitting is common to all boolean operations.\n -The method in charge of that is INTERP_KERNEL::QuadraticPolygon::splitPolygonsEachOther. - -\subsection interpkernelGeo2DBoolOpStep2 Step2 : Edges localization. - -Perform localization of each splitted edge. As \ref interpkernelGeo2DBoolOpStep1 "split process" it - 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 -\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 -following these rules : - - * - * - * - * - * - * - * - * - * - * - *
Previous Edge LocCurrent start node Loc Current edge Loc
UNKNOWN ANY UNKNOWN -> \ref interpkernelGeo2DAlgLoc "Absolute search"
OUT ON IN
OUT ON_TANGENT OUT
IN ON OUT
IN ON_TANGENT IN
OUT OUT OUT
IN IN IN
ON ANY UNKNOWN -> \ref interpkernelGeo2DAlgLoc "Absolute search"
- -The method in charge of that is INTERP_KERNEL::QuadraticPolygon::performLocatingOperation. - -\subsection interpkernelGeo2DBoolOpStep3 Step3 : Result polygon building. - -This stage links each edge with wanted loc. \b Contrary to last 2 steps it is obviously boolean -operation dependant. Let's take the case of the intersection that is used in -P0->P0 interpolation. \n The principle of result polygon building is to build polygon by taking -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. - -The method in charge of that is INTERP_KERNEL::QuadraticPolygon::buildIntersectionPolygons. - -\section interpkernelGeo2DAlg underneath algorithms. - -\subsection interpkernelGeo2DAlgLoc Absolute localization algorithm. - -This algorithm is called when splitting process has been done, and -that we are sure that the edge is either \b fully \b in ,or \b fully \b on or \b fully -\b out. - -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$ -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-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. - -This computation is \b very \b expensive, that why some tricks as described in -\ref interpkernelGeo2DBoolOpStep2 "localization techniques" are used to call as few as possible -during intersecting process. - -\subsection interpkernelGeo2DAlgIntsect Intersection algorithms. - -The only mathematical intersections performed are edges intersections. -The algorithms used are : - - -# Lin-Lin intersection : http://mathworld.wolfram.com/Line-LineIntersection.html - -# Lin-Arc intersection : http://mathworld.wolfram.com/Circle-LineIntersection.html - -# Arc-Arc intersection : http://mathworld.wolfram.com/Circle-CircleIntersection.html - -\subsection interpkernelGeo2DAlgOthers Other algorithms. - -As internal architecture is quite general, it is possible to have more than classical intersection on any polygons : - - - \ref INTERP_KERNEL::ComposedEdge::getAreaOfZone "area" computation is available. - - \ref INTERP_KERNEL::QuadraticPolygon::getPerimeterFast "perimeter" computation. - - \ref INTERP_KERNEL::QuadraticPolygon::getHydraulicDiameter "Hydraulic diameter" computation. - -\section interpkernelGeo2DUsage Usage. - -This intersector is usable standalone. To use a set of user friendly methods have been implemented. - - - INTERP_KERNEL::QuadraticPolygon::buildArcCirclePolygon method builds from a \c std::vector of INTERP_KERNEL::Node* \a V, an instance of QuadraticPolygon \a P. - \a P will have \f$ N_{edges} = V.size()/2 \f$ edges. Quadratic edge \f$ Edge_i i \in [0,N_{edges}-1] \f$ starts with node V[i], ends with node V[i+1] and has a middle in - \f$ V[i+N_{edge}] \f$. \n If start, end and middle nodes of edge \f$ Edge_i \f$ are aligned by a precision specified by INTERP_KERNEL::QUADRATIC_PLANAR::setArcDetectionPrecision. - - INTERP_KERNEL::QuadraticPolygon::buildLinearPolygon method builds from a \c std::vector of INTERP_KERNEL::Node* \a V, an instance of QuadraticPolygon \a - P. \a P will have \f$ N_edges = V.size() \f$ edges. Linear edge \f$ Edge_i i \in [0,N_{edges}-1] \f$ starts with node V[i] and ends with node V[i+1]. - -The orientation of polygons (clockwise, inverse clockwise) impact computation only on the sign of areas. During intersection of 2 polygons their orientation can be different. - -The usage is simple : - -\code -... -// defining a precision -INTERP_KERNEL::QUADRATIC_PLANAR::setPrecision(1e-5); -INTERP_KERNEL::QUADRATIC_PLANAR::setArcDetectionPrecision(1e-5); -// -INTERP_KERNEL::QuadraticPolygon *polygon1=...; -bool isQuadratic=...//Depends on the nature of your cell. If your cell is MED_QUAD8 or MED_TRIA6 for example isQuadratic=true. -const double *externalTabXCoords=...; -const double *externalTabYCoords=...; -std::vector nodes; -INTERP_KERNEL::QuadraticPolygon *polygon2=0; -for(int i=0;iintersectWith(*polygon2); -double dhydPol1=polygon1->getHydraulicDiameter(); -double areaPol1=polygon1->getAreaOfZone(); -//clean-up -delete polygon1; -delete polygon2; -... -\endcode - -\section interpkernelGeo2DExample Example of result. - -Here an example of 2 polygons. The left one \a P1 has 4 edges and the -right one \a P2 has 4 edges too. - -\anchor interpkernelGeo2DEx1 -\image html SampGeo2D1.png "An example of intersection of 2 polygons." -\image latex SampGeo2D1.eps "An example of intersection of 2 polygons." - -After \ref interpkernelGeo2DBoolOpStep1 "spliting process" \a P1 has 6 edges and \a P2 has 6 edges too. - -\anchor interpkernelGeo2DEx2 -\image html SampGeo2D2.png "After spliting process two edges of P1 have been located has out." -\image latex SampGeo2D2.eps "After spliting process two edges of P1 have been located has out." - -\note BLUE is for OUT, GREEN for IN and RED for ON. - -For each 6 edges \ref interpkernelGeo2DBoolOpStep2 "locate" them. - -\anchor interpkernelGeo2DEx3 -\image html SampGeo2D3.png "Result after locating phase." -\image latex SampGeo2D3.eps "Result after locating phase." - -Too finish \ref interpkernelGeo2DBoolOpStep3 "closing" polygons. - -\anchor interpkernelGeo2DEx4 -\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 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 deleted file mode 100644 index 874fae61b..000000000 --- a/doc/doxygen/barycoords.dox +++ /dev/null @@ -1,39 +0,0 @@ -/*! -\page barycoords Barycentric coordinates algorithm - -Computation of barycentric coordinates is used to fill interpolation -matrix in case of P1 an P1d types of interpolation. Computation of -barycentric coordinates consists in finding weights of vertices -bearing values within the cell. The cell is triangle in 2D space and -tetrahedron in 3D space. - -Input of the algorithm includes -- coordinates of cell vertices (p1...pn), -- 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 -- (a1*p1+...+an*pn)=b and -- (a1+...+an)=1.0 - -Combining the last two expressions we get an equation in matrix form -a * T = ( b - pn ) -where -- a is a vector of coefficients a1...an -- b is a vector of cartesian coordinates of barycentre -- T is a matrix expressed via cartesian coordinates of vertices as -
in 2D case 
-| x1-x3 x2-x3 |
-| y1-y3 y2-y3 |
-in 3D case 
-| x1-x4 x2-x4 x3-x4 |
-| y1-y4 y2-y4 y3-y4 |
-| z1-z4 z2-z4 z3-z4 |
- -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 coefficients a. - -*/ diff --git a/doc/doxygen/biblio.dox b/doc/doxygen/biblio.dox deleted file mode 100644 index 1f258eadf..000000000 --- a/doc/doxygen/biblio.dox +++ /dev/null @@ -1,12 +0,0 @@ -/*! -\defgroup references References - -Here follows a list of useful references : - --# Reference Manual for Med File, V. Lefebvre, E. Fayolle, Projet PAL: Définition du modèle d'échange de données MED V2.2, Note technique EDF/SINETICS, HI-26-03-012/A, https://hammi.extra.cea.fr/static/MED/web_med/index.html \anchor RefManualMedFile --# VTK home page: \c http://public.kitware.com/VTK --# Med File Data Model : V. Lefebvre, E. Fayolle, Définition du modèle d'échange de données MED v2.2, https://hammi.extra.cea.fr/static/MED/web_med/pdf/NOTE_HI_26_03_012_A.pdf --# Jeffrey Grandy, Conservative remapping and region overlays by intersecting arbitrary polyhedra, Journal of Computational Physics, vol 148, 433-466 (1999) --# F. Preparata and M. Shamos Computational Geometry. Springer-Verlag, New York, 1985 -*/ - diff --git a/doc/doxygen/input/biblio.dox b/doc/doxygen/input/biblio.dox new file mode 100644 index 000000000..77f77585a --- /dev/null +++ b/doc/doxygen/input/biblio.dox @@ -0,0 +1,12 @@ +/*! +\page references References + +Here follows a list of useful references : + +-# \anchor RefManualMedFile Reference Manual for Med File, V. Lefebvre, E. Fayolle, Projet PAL: Définition du modèle d'échange de données MED V2.2, Note technique EDF/SINETICS, HI-26-03-012/A, https://hammi.extra.cea.fr/static/MED/web_med/index.html +-# VTK home page: \c http://public.kitware.com/VTK +-# Med File Data Model : V. Lefebvre, E. Fayolle, Définition du modèle d'échange de données MED v2.2, https://hammi.extra.cea.fr/static/MED/web_med/pdf/NOTE_HI_26_03_012_A.pdf +-# Jeffrey Grandy, Conservative remapping and region overlays by intersecting arbitrary polyhedra, Journal of Computational Physics, vol 148, 433-466 (1999) +-# F. Preparata and M. Shamos Computational Geometry. Springer-Verlag, New York, 1985 +*/ + diff --git a/doc/doxygen/input/examples/medcouplingexamplesarrays.doxy b/doc/doxygen/input/examples/medcouplingexamplesarrays.doxy new file mode 100644 index 000000000..bf96a4e50 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesarrays.doxy @@ -0,0 +1,820 @@ + +\section ExamplesArrays Arrays + +\subsection ExamplesArraysCreate Create + +\anchor BEGIN_PYTHON_ONLY +\subsubsection MEDCouplingArraySteps0 Building an array from scratch in Python +\anchor MEDCouplingArraySteps0Double +

Building a double array from scratch in Python

+ +Let's consider a list of floats \c dataDouble. + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_0 + +The easiest way to build the \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" called \c arrayDouble simply call : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_1bis + +An another way is to do that : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_1 + +\anchor MEDCouplingArraySteps0Int +

Building an int array from scratch in Python

+ +Let's consider a list of ints \c dataInt. + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_2 + +The easiest way to build the \ref ParaMEDMEM::DataArrayInt "DataArrayInt instance" called \c arrayInt simply call : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_3bis + +An another way is to do that : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_3 +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_CPP_ONLY +\subsubsection MEDCouplingArraySteps1 Building an array from scratch in C++ + +In this example we will create arrays with 12 tuples constituted each +of 3 components. These arrays will be created using different ways.\n + +The following code is only based using \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" +but the use of \ref ParaMEDMEM::DataArrayInt "DataArrayInt" is strictly equivalent. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_0 + +\anchor MEDCouplingArraySteps1NCNO +

Building an array from scratch in C++, no copy no ownership

+ +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_1 + +\anchor MEDCouplingArraySteps1NCWCPPO +

Building an array from scratch in C++, no copy with C++ ownership

+ +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_2 + +\anchor MEDCouplingArraySteps1NCWCO +

Building an array from scratch in C++, no copy with C ownership

+ +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_3 + +\anchor MEDCouplingArraySteps1WC +

Building an array from scratch in C++, with copy

+ +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_4 +\anchor END_CPP_ONLY + +\anchor BEGIN_CPP_ONLY +\subsubsection cpp_mcdataarray_copy Copy DataArrays + +\anchor cpp_mcdataarray_deepcopy +

Deep copy

+ +To perform a deep copy of a DataArray instance simply invoke : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_5 + +or : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_5bis + +\c coordsArrCpy is the deep copy of \c coordsArr 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_6 + +As \c coordsArrCpy is a copy object it needs to be deallocated in C++ like \c coordsArr. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_7 + +\anchor cpp_mcdataarray_shallowcopy +

Shallow copy

+ +To perform a shallow copy of a DataArray instance simply invoke : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_8 + +\c coordsArrCpy is the shallow copy of \c coordsArr so they share the same *raw data*. In reality they are the same object. +So it leads to the following behaviour to compare with the deep copy : + +\anchor MEDCouplingArrayBasicsCopyShallowTestEqual + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_9 + +So here the content of \c coordsArr and \c coordsArrCpy are linked, contrary to the deep copy case. + +As \c coordsArrCpy is a copy object, in C++, it needs to be deallocated. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_10 + +\anchor MEDCouplingArrayBasicsCopyDeepAssign +

Assignation by deep copy of DataArray

+ +We start by building a instance of ParaMEDMEM::DataArrayDouble allocated or not. Here, instance is not allocated, only built empty. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_11 + +Then, \c coordsArrCpy is assigned with the content of \c coordsArr. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_12 + +Then \c coordsArrCpy is a deep copy of \c coordsArr except that the instance of ParaMEDMEM::DataArrayDouble is those specified. +But the behaviour is the same than those seen for \ref MEDCouplingArrayBasicsCopyDeepTestEqual "deep copy". + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_13 + +As always, in C++, \c coordsArrCpy is an object whose life cycle is fully independent from \c coordsArr so decrement is needed. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_14 + +\anchor END_CPP_ONLY + + +\subsubsection cpp_mcdataarrayint_buildpermutationarr Building a permutation array + +Here we create two arrays containing same values but in different order and then we use +\ref ParaMEDMEM::DataArrayInt::buildPermutationArr "DataArrayInt::buildPermutationArr()" to get +an array showing in what places the values of \b b array are located in \b a array. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_buildPermutationArr_1 +The result array \b c contains [1,0,4,2,3]. + + +\subsection ExamplesArraysModify Modify + +\subsubsection cpp_mcdataarrayint_invertarray Inverting renumbering maps + +\anchor cpp_mcdataarrayint_invertarrayo2n2n2o +

invertArrayO2N2N2O()

+ +In this example we create a DataArrayInt containing a renumbering map in +"Old to New" mode, convert it into the renumbering map in "New to Old" mode and check the +result. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_invertArrayO2N2N2O_1 + +\anchor cpp_mcdataarrayint_invertarrayn2o2o2n +

invertArrayN2O2O2N()

+ +In this example we create a DataArrayInt containing a renumbering map in +"New to Old" mode, convert it into the renumbering map in "Old to New" mode and check the +result. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_invertArrayN2O2O2N_1 + + +\subsubsection py_mcdataarraydouble_setpartofvalues Set part of values of DataArrayDouble + +\anchor py_mcdataarraydouble_setselectedcomponents +

setSelectedComponents()

+First, we create a 'source' array. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents1 +Now we create a larger zero array and assign the array \b da into it. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents2 +As result contents of the array \b dv are as follows. +
+Info of components : "a2"   "a1"   "v3"   "v4"
+    Tuple #0 : 2 1 0 0
+    Tuple #1 : 4 3 0 0
+    Tuple #2 : 6 5 0 0
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way (except that component info +is not copied): +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents3 + +\anchor py_mcdataarraydouble_setpartofvalues1 +

setPartOfValues1()

+We create two arrays: +- a "large" (4x4) zero array \b da to assign to and +- a smaller (2x2) array \b dv filled with values [7.,8.,9.,10]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_1 +Now we copy \b dv to the middle of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_2 +As result contents of the array \b da are as follows. +
+    Info of components :"v1"   "v2"   "v3"   "v4"
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 8 0
+    Tuple #2 : 0 9 10 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and copy \b dv into a component of \b da. + +Note that the last parameter \b strictCompoCompare should be \c False +in this case, else \ref ParaMEDMEM::DataArrayDouble::setPartOfValues1() +throws an exception because \b da has 2 components but only one target +component is specified. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 8 0 0
+    Tuple #2 : 0 9 0 0
+    Tuple #3 : 0 10 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 8 9 10
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_5 +
+    Tuple #0 : 0 7 0 8
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 9 0 10
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way: +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_6 + + +\anchor py_mcdataarraydouble_setpartofvaluessimple1 +

setPartOfValuesSimple1()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_1 +Now we assign \b dv to the middle of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way: +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_6 + + +\anchor py_mcdataarraydouble_setpartofvaluessimple2 +

setPartOfValuesSimple2()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_1 +Now we assign \b dv to the middle of \b da. +We explicitly specify tuples and component to assign to by a list [1,2]. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValuesSimple2() can't +be explicitly called in Python. + + +\anchor py_mcdataarraydouble_setpartofvaluessimple3 +

setPartOfValuesSimple3()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_1 +Now we assign \b dv to the middle of \b da. +We explicitly specify tuples to assign to by a list [1,2]. And we specify +components to assign to using slicing: 1:3. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValuesSimple3() can't +be explicitly called in Python. + + +\anchor py_mcdataarraydouble_setpartofvalues2 +

setPartOfValues2()

+We create two arrays: +- a "large" (4x7) zero array \b da to assign to, +- a smaller (3x2) array \b dv filled with values [7.,8.,9.,10.,11.,12.]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_1 +Now we assign the two components of \b dv to the components of \b da +with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with + indices [0,1,2]. This is the first mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0  7  0  8  0  0  0
+    Tuple #1 : 0  9  0 10  0  0  0
+    Tuple #2 : 0 11  0 12  0  0  0
+    Tuple #3 : 0  0  0  0  0  0  0
+
+Every value of \b dv has been assigned to its own location within \b da. + +Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. +And we assign \b dv to the tuples of \b da with indices [0,2,3] . +This is the second mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_3 +The contents of \b dv have been assigned to each of specified tuples of \b da. +Every value of \b dv is repeated in the 3 specified tuples within \b da. +
+    Tuple #0 : 7  0  8  9 10 11 12
+    Tuple #1 : 0  0  0  0  0  0  0
+    Tuple #2 : 7  0  8  9 10 11 12
+    Tuple #3 : 7  0  8  9 10 11 12
+
+\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValues2() can't +be explicitly called in Python. + + +\anchor py_mcdataarraydouble_setpartofvalues3 +

setPartOfValues3()

+We create two arrays: +- a "large" (4x7) zero array \b da to assign to, +- a smaller (3x2) array \b dv filled with values [7.,8.,9.,10.,11.,12.]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_1 +Now we assign the two components of \b dv to the components of \b da +with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with +indices [0,1,2] which are specified using slicing: "0:3". +This is the first mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0  7  0  8  0  0  0
+    Tuple #1 : 0  9  0 10  0  0  0
+    Tuple #2 : 0 11  0 12  0  0  0
+    Tuple #3 : 0  0  0  0  0  0  0
+
+Every value of \b dv has been assigned to its own location within \b da. + +Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. +And we assign \b dv to the tuples of \b da with indices [0,2] using \a +slice notation "0:4:2". This is the second mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_3 +The contents of \b dv have been assigned to each of specified tuples of \b da. +Every value of \b dv is repeated in the 3 specified tuples within \b da. +
+    Tuple #0 : 7  0  8  9 10 11 12
+    Tuple #1 : 0  0  0  0  0  0  0
+    Tuple #2 : 7  0  8  9 10 11 12
+    Tuple #3 : 0  0  0  0  0  0  0
+
+\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValues3() can't +be explicitly called in Python. + + +\subsubsection py_mcdataarrayint_setpartofvalues Set part of values of DataArrayInt + +\anchor py_mcdataarrayint_setselectedcomponents +

setSelectedComponents()

+First, we create a 'source' array. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents1 +Now we create a larger zero array and assign the array \b da to it. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents2 +As result contents of the array \b dv are as follows. +
+Info of components : "a2"   "a1"   "v3"   "v4"
+    Tuple #0 : 2 1 0 0
+    Tuple #1 : 4 3 0 0
+    Tuple #2 : 6 5 0 0
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way (except that component info +is not copied): +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents3 + +\anchor py_mcdataarrayint_setpartofvalues1 +

setPartOfValues1()

+We create two arrays: +- a "large" (4x4) zero array \b da to assign to, and +- a smaller (2x2) array \b dv filled with values [7,8,9,10]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_1 +Now we copy \b dv to the middle of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_2 +As result contents of the array \b da are as follows. +
+    Info of components :"v1"   "v2"   "v3"   "v4"
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 8 0
+    Tuple #2 : 0 9 10 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and copy \b dv into a component of \b da. + +Note that the last parameter \b strictCompoCompare should be \c False +in this case, else \ref ParaMEDMEM::DataArrayInt::setPartOfValues1() +throws an exception because \b da has 2 components but only one target +component is specified. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 8 0 0
+    Tuple #2 : 0 9 0 0
+    Tuple #3 : 0 10 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 8 9 10
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_5 +
+    Tuple #0 : 0 7 0 8
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 9 0 10
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way: +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_6 + + + +\anchor py_mcdataarrayint_setpartofvaluessimple1 +

setPartOfValuesSimple1()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_1 +Now we assign \b dv to the middle of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+The same result can be achieved other way: +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_6 + + +\anchor py_mcdataarrayint_setpartofvaluessimple2 +

setPartOfValuesSimple2()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_1 +Now we assign \b dv to the middle of \b da. +We explicitly specify tuples and component to assign to by a list [1,2]. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+\note \ref ParaMEDMEM::DataArrayInt::setPartOfValuesSimple2() can't +be explicitly called in Python. + + +\anchor py_mcdataarrayint_setpartofvaluessimple3 +

setPartOfValuesSimple3()

+We create an array (4x4) \b da to assign to and define a value \b dv to assign. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_1 +Now we assign \b dv to the middle of \b da. +We explicitly specify tuples to assign to by a list [1,2]. And we specify +components to assign to using slicing: 1:3. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 0 7 7 0
+    Tuple #2 : 0 7 7 0
+    Tuple #3 : 0 0 0 0
+
+ +Here we re-fill \b da with zeros and assign \b dv to a component of \b da. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_3 +
+    Tuple #0 : 0 7 0 0
+    Tuple #1 : 0 7 0 0
+    Tuple #2 : 0 7 0 0
+    Tuple #3 : 0 7 0 0
+
+Below more two variants of location of target values are shown. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_4 +
+    Tuple #0 : 0 0 0 0
+    Tuple #1 : 7 7 7 7
+    Tuple #2 : 0 0 0 0
+    Tuple #3 : 0 0 0 0
+
+ +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_5 +
+    Tuple #0 : 0 7 0 7
+    Tuple #1 : 0 0 0 0
+    Tuple #2 : 0 7 0 7
+    Tuple #3 : 0 0 0 0
+
+\note \ref ParaMEDMEM::DataArrayInt::setPartOfValuesSimple3() can't +be explicitly called in Python. + + +\anchor py_mcdataarrayint_setpartofvalues2 +

setPartOfValues2()

+We create two arrays: +- a "large" (4x7) zero array \b da to assign to, +- a smaller (3x2) array \b dv filled with values [7,8,9,10,11,12]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_1 +Now we assign the two components of \b dv to the components of \b da +with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with + indices [0,1,2]. This is the first mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0  7  0  8  0  0  0
+    Tuple #1 : 0  9  0 10  0  0  0
+    Tuple #2 : 0 11  0 12  0  0  0
+    Tuple #3 : 0  0  0  0  0  0  0
+
+Every value of \b dv has been assigned to its own location within \b da. + +Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. +And we assign \b dv to the tuples of \b da with indices [0,2,3] . +This is the second mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_3 +The contents of \b dv have been assigned to each of specified tuples of \b da. +Every value of \b dv is repeated in the 3 specified tuples within \b da. +
+    Tuple #0 : 7  0  8  9 10 11 12
+    Tuple #1 : 0  0  0  0  0  0  0
+    Tuple #2 : 7  0  8  9 10 11 12
+    Tuple #3 : 7  0  8  9 10 11 12
+
+\note \ref ParaMEDMEM::DataArrayInt::setPartOfValues2() can't +be explicitly called in Python. + + +\anchor py_mcdataarrayint_setpartofvalues3 +

setPartOfValues3()

+We create two arrays: +- a "large" (4x7) zero array \b da to assign to, +- a smaller (3x2) array \b dv filled with values [7,8,9,10,11,12]. + +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_1 +Now we assign the two components of \b dv to the components of \b da +with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with +indices [0,1,2] which are specified using slicing: "0:3". +This is the first mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_2 +As result contents of the array \b da are as follows. +
+    Tuple #0 : 0  7  0  8  0  0  0
+    Tuple #1 : 0  9  0 10  0  0  0
+    Tuple #2 : 0 11  0 12  0  0  0
+    Tuple #3 : 0  0  0  0  0  0  0
+
+Every value of \b dv has been assigned to its own location within \b da. + +Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. +And we assign \b dv to the tuples of \b da with indices [0,2] using \a +slice notation "0:4:2". This is the second mode of usage. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_3 +The contents of \b dv have been assigned to each of specified tuples of \b da. +Every value of \b dv is repeated in the 3 specified tuples within \b da. +
+    Tuple #0 : 7  0  8  9 10 11 12
+    Tuple #1 : 0  0  0  0  0  0  0
+    Tuple #2 : 7  0  8  9 10 11 12
+    Tuple #3 : 0  0  0  0  0  0  0
+
+\note \ref ParaMEDMEM::DataArrayInt::setPartOfValues3() can't +be explicitly called in Python. + + +\subsubsection py_mcdataarraydouble_getdifferentvalues Excluding coincident tuples from DataArrayDouble + +The code below creates an array of real values and than an array of + unique values, not closer one to another than 0.2, is retrieved from it. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_getDifferentValues1 + + +\subsubsection cpp_mcdataarraydouble_meldwith Concatenating DataArrayDouble's by appending components + +In this example we create two data arrays including \b same number of +tuples and then we concatenate them using \ref +ParaMEDMEM::DataArrayDouble::meldWith "meldWith()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_Meld1_1 +Now the array \b da1 includes 7 tuples (as before) of 3 components +each. Its components are: "c0da1","c1da1","c0da2". + + +\subsubsection cpp_mcdataarrayint_meldwith Concatenating DataArrayInt's by appending components + +In this example we create two data arrays including \b same number of +tuples and then we concatenate them using \ref +ParaMEDMEM::DataArrayInt::meldWith "meldWith()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_Meld1_1 +Now the array \b da1 includes 7 tuples (as before) of 3 components +each. Its components are: "c0da1","c1da1","c0da2". + + +\subsection ExamplesArraysAccess Access + +\subsubsection cpp_mcdataarrayint_getTuple Getting a tuple of DataArrayInt + +In this simple example we create an array of integers arranged into 3 +tuples per 2 components, and finally print the second tuple. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_getTuple_1 +The output is +
 [9, 10]
+Note that we can traverse all tuples in the array by simply iterating +over it as the code below does. +\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_getTuple_2 +Its output follows. +
+(7, 8)
+(9, 10)
+(11, 12)
+
+ + +\subsubsection cpp_mcdataarraydouble_getidsinrange Finding values in range in DataArrayDouble + +In this example we create an array \b da containing same values as ones returned by +\c range( \c 10 ). Then we get an array of indices of values of \b da being in +range [ 2.5, 6 ]. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_getIdsInRange_1 +As result contents of the array \b da2 are as follows. +
+    Tuple #0 : 3
+    Tuple #1 : 4
+    Tuple #2 : 5
+    Tuple #3 : 6
+
+ + +\subsubsection cpp_mcdataarraydouble_findcommontuples Finding coincident tuples in DataArrayDouble + +Let's create an array of 6 tuples and 2 components that can be + considered as coordinates of 6 points in 2D space. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_findCommonTuples1 +Now we find points that are not far each from other than 1e-1. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_findCommonTuples2 +As we can realize from the above code, a hardcoded array \b expected3 is equal + to the raw data of a DataArrayInt \b c and a hardcoded array \b expected4 is equal + to the raw data of the DataArrayInt \b cI. + +The array \b c contains indices of 5 coincident points. The array \b + cI shows us boundaries of (cI->getNumberOfTuples()-1) = 2 groups of coincident points: +- The first group starts at index 0 and includes (3 - 0) = 3 points: 0,3,4. +- The second group starts at index 3 and includes (5 - 3) = 2 points: 1,2. + + +\subsubsection py_mcdataarraydouble_KeepSelectedComponents Creation of a sub-part of the DataArrayDouble by selecting components + +\snippet MEDCouplingExamplesTest.py SnippeDataArrayDoubleKeepSelectedComponents1_1 +We created an array \b a1 containing 5 tuples of 4 components each (20 +values). Now we are going to create an array \b a2 containing some +components of \b a1. +\snippet MEDCouplingExamplesTest.py SnippeDataArrayDoubleKeepSelectedComponents1_2 +Now each tuple of \b a2 includes components named "b","c","b","c","a","a". Thus +the result array \b a2 includes 30 elements (5 tuples per 6 components). + + +\subsubsection py_mcdataarrayint_keepselectedcomponents Creation of a sub-part of the DataArrayInt by selecting components + +\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_1 +We created an array \b a1 containing 5 tuples of 4 components each (20 +values). Now we are going to create an array \b a2 containing some +components of \b a1. +\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_2 +Now each tuple of \b a2 includes components named "b","c","b","c","a","a". Thus +the result array \b a2 includes 30 elements (5 tuples per 6 components). + +Note that +\ref ParaMEDMEM::DataArrayInt::keepSelectedComponents() "DataArrayInt::keepSelectedComponents()" +is called, providing the same result, by the following python code: +\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_3 diff --git a/doc/doxygen/input/examples/medcouplingexamplesfields.doxy b/doc/doxygen/input/examples/medcouplingexamplesfields.doxy new file mode 100644 index 000000000..f1deed1e7 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesfields.doxy @@ -0,0 +1,649 @@ + +\section ExamplesFields Fields + +\subsection ExamplesFieldsCreate Create + +\subsubsection medcouplingcppexamplesFieldDoubleBuild1 Standard build of a tensor field on cells with no time attached + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_1 + + +\subsubsection medcouplingcppexamplesFieldDoubleBuild2 Standard build of a scalar field on nodes with no time attached + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild2_1 + + +\subsubsection medcouplingcppexamplesFieldDoubleBuild3 Standard build of a vector field on cells with one time attached and no time interval + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild3_1 + + +\subsubsection medcouplingcppexamplesFieldDoubleBuild4 Standard build of a vector field on nodes defined on a time interval with a constant value during this interval + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild4_1 + + +\subsubsection cpp_mcfielddouble_MaxFields Getting maximal and minimal fields + +In this example we +- create two fields with two tuples per two components, +- use +\ref ParaMEDMEM::MEDCouplingFieldDouble::MaxFields "MaxFields()" +to get a field holding maximal values of the two fields. +- use +\ref ParaMEDMEM::MEDCouplingFieldDouble::MinFields "MinFields()" +to get a field holding minimal values of the two fields. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_MaxFields_1 + + +\subsubsection cpp_mcfielddouble_MergeFields Concatenating fields + +In this example we +- create an 1D mesh and a field on it, +- make a deep copy of the mesh and the field, +- translate the mesh and the field, +- use two variants of +\ref ParaMEDMEM::MEDCouplingFieldDouble::MergeFields "MergeFields()" +to create one field from the two by concatenating them and their meshes. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_MergeFields_1 +The result field is twice "longer" than \b field1. + + +\subsubsection cpp_mcfielddouble_buildNewTimeReprFromThis Getting a field copy with different time discretization + +First, we create a supporting 2D mesh and a field on it got using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". +\ref MEDCouplingTemporalDisc "Time discretization" of this field is +\ref ParaMEDMEM::ONE_TIME "ONE_TIME". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_buildNewTimeReprFromThis_1 +Now we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::buildNewTimeReprFromThis "buildNewTimeReprFromThis()" +to get a copy of \b field1 whose time discretization is +\ref ParaMEDMEM::NO_TIME "NO_TIME". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_buildNewTimeReprFromThis_2 + + +\subsubsection cpp_mcmesh_fillFromAnalytic3 Creating a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_1 +Now we use +\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic3 "fillFromAnalytic3()" +to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want to get the +field on cells, with 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 and checks that values of the second +tuple are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_3 + + +\subsubsection cpp_mcmesh_fillFromAnalytic2 Creating a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +Note that we set names to coordinates arrays ("a" and "b" ) which will be used to refer to +corresponding coordinates within a function. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_1 +Now we use +\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic2 "fillFromAnalytic2()" +to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want to get the +field on cells, with 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 and checks that values of the second +tuple are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_3 + + +\subsubsection cpp_mcmesh_fillFromAnalytic Creating a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_1 +Now we use +\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic "fillFromAnalytic()" +to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want to get the +field on cells, with 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 and checks that values of the second +tuple are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_3 + + +\subsubsection cpp_mcfielddouble_subpart1 Creation of a sub part of a field + +

Creation of a sub part of a field on cells

+\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_1 +The field on cells \b f1 lies on a mesh containing 5 cells and 9 nodes. +So this field \b f1 contains 5 tuples of 2 components each (10 values). +Now let's create a subfield on cells \b f2 from \b f1. +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_2 + +\b f1 is a field on cells, \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" method performs an extraction on cells too. + +So the array \b part1 lists ids on cells. + +- cell #0 of \b f2 is the same cell of cell #2 of \b f1 +- cell #1 of \b f2 is the same cell of cell #1 of \b f1 +- cell #2 of \b f2 is the same cell of cell #4 of \b f1 + +So \b f2 contains 3 tuples with 2 components. + +The underlying mesh of \b f2 contains a newly created mesh with 3 cells (not as \b mesh1 in \b f1) and 9 nodes (as \b mesh1 in \b f1). +\n For fields on cells the number of tuples of the returned field is always equal to the number of ids given in input (here \b part1). +\nOnly fields on cells have this particular behaviour. + +

Creation of a sub part of a field on nodes

+\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_3 +The field on nodes \b f1 lies on a mesh containing 5 cells and 9 nodes. +So this field \b f1 contains 9 tuples of 2 components each (18 values). +Now let's create a subfield on nodes \b f2 from \b f1. +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_4 + +\b f1 is a field on nodes, but \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" method performs an extraction on \b cells. + +After the call of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" on node field \b f1, \b f1 will be reduced on a +submesh of \b mesh1 containing cells whose ids are in \b part2. So here the number of cells of \b f2 is 2 and the number of nodes is 4. +\nSo contrary to fields on cells, it is normal for fields on nodes that number of tuples of the returned field of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" +method does not match the size of the input array (here \b part2). + + +\subsection ExamplesFieldsModify Modify + +\subsubsection cpp_mcfielddouble_substractInPlaceDM Subtracting field on different meshes + +We make two meshes in 1D space with no cells and 4 nodes. Nodes #0 and #2 are swapped +in the two meshes.
+And we make two fields on these meshes, so that fields values to equal to node +coordinates of the underlying meshes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_1 +We are going to subtract \b field2 from \b field1, though they are on +different meshes. +\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" +allows us doing this. We use a mesh comparison level \b levOfCheck = 10 that allows +subtracting fields on meshes with different node arrays.
+\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_2 +After applying +\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" +the both fields lie on \b mesh2. As +\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" +permutes values of \b field1 before value subtraction, and thus \b field1 becomes +equal to \b field2, hence their subtraction results in a zero field. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_3 + + +\subsubsection cpp_mcfielddouble_changeUnderlyingMesh Changing the underlying mesh + +We make two meshes in 1D space with no cells and 4 nodes. Nodes #0 and #2 are swapped +in the two meshes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_changeUnderlyingMesh_1 +We are going to use +\ref ParaMEDMEM::MEDCouplingFieldDouble::changeUnderlyingMesh "changeUnderlyingMesh()" +to set \b mesh2 instead of \b mesh1 as a support of a field.
+We use +\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic "fillFromAnalytic()" +to make a field on nodes of \b mesh1, so that its values to equal to node coordinates. +Then we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::changeUnderlyingMesh "changeUnderlyingMesh()" +to change the underlying mesh of the \b field. +(We use a mesh comparison level \b levOfCheck = 10 that allows substituting meshes with +different node arrays.) As a result, we expect that values of the \b field are also +permuted same as nodes of the two meshes, and thus its values become equal to the +array \b coords2. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_changeUnderlyingMesh_2 + + +\subsubsection cpp_mcfielddouble_applyFunc_same_nb_comp Changing a field using an expression + +We create a 2D vector field with 2 tuples and we want to transform this +field using an expression using +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(const char *func) "applyFunc()". +The expression \b func is applied to each atomic value of the \b field. We want to change +the \b field as follows. (In \b func, we use the variable "v" to refer to an atomic field value). +- Component #0 = component #0 (remains the same); hence "IVec * v" in \b func. +- Component #1 = component #1 ^ 2; hence "JVec * v*v". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_same_nb_comp_1 +Now we ascertain that the result field is as we expect. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_same_nb_comp_2 + + +\subsubsection cpp_mcfielddouble_applyFunc3 Changing a field using an expression + +We create a 2D vector field with 2 values (vectors) and then we transform this +field into a 3D vector field by applying an expression to values of the 2D field +using +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc3() "applyFunc3()". +The expression \b func is applied to components of each vector of the \b field. We want +the \b field to have 3 components computed as follows. (In \b func, we refer to the +first component of a field value using the variable "a", and to the second component, using +the variable "b", as we define it by \b varNamesVec). +- Component #0 = the second vector component; hence "IVec * b" in \b func. +- Component #1 = the first vector component; hence "JVec * a". +- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc3_1 +Now we ascertain that the result field is as we expect. We check the second vector of +the \b field. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc3_2 + + +\subsubsection cpp_mcfielddouble_applyFunc2 Changing a field using an expression + +We create a 2D vector field with 2 values (vectors) and then we transform this +field into a 3D vector field by applying an expression to values of the 2D field +using +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const char *func) "applyFunc2()". +Note that we set component info the \b array ("a" and "b" ) which will be used to refer to +corresponding components within a function. +The expression \b func is applied to components of each vector of the \b field. We want +the \b field to have 3 components computed as follows. (In \b func, we refer to the +first component of a field value using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second vector component; hence "IVec * b" in \b func. +- Component #1 = the first vector component; hence "JVec * a". +- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc2_1 +Now we ascertain that the result field is as we expect. We check the second vector of +the \b field. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc2_2 + + +\subsubsection cpp_mcfielddouble_applyFunc Changing a field using an expression + +We create a 2D vector field with 2 values (vectors) and then we transform this +field into a 3D vector field by applying an expression to values of the 2D field +using +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, const char *func) "applyFunc()". +The expression \b func is applied to components of each vector of the \b field. We want +the \b field to have 3 components computed as follows. (In \b func, we refer to the +first component of a field value using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second vector component; hence "IVec * b" in \b func. +- Component #1 = the first vector component; hence "JVec * a". +- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_1 +Now we ascertain that the result field is as we expect. We check the second vector of +the \b field. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_2 + + +\subsubsection cpp_mcfielddouble_applyFunc_val Filling a field with a value + +We want to transform a 2D vector field to a 3D vector field so that all values to be +equal to a certain value. First, we create the 2D mesh and the vector field on it. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_val_1 +Finally we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, double val) "applyFunc()" +to change the number of components and all field values. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_val_2 +As a result, number of tuples in the field equals to the number of cells in the mesh, +and number of components becomes equal to 3 as required. + + +\subsubsection cpp_mcfielddouble_fillFromAnalytic3 Filling a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_1 +Now we create a field on cells and use +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic2 "fillFromAnalytic2()" +to fill it +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want the \b field +to have 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 and checks that values of the second +tuple are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_3 + + +\subsubsection cpp_mcfielddouble_fillFromAnalytic2 Filling a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +Note that we set names to coordinates arrays ("a" and "b" ) which will be used to refer to +corresponding coordinates within a function. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_1 +Now we create a field on cells and use +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic2 "fillFromAnalytic2()" +to fill it +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want the \b field +to have 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 and checks that values of the second +tuple are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_3 + + +\subsubsection cpp_mcfielddouble_fillFromAnalytic Filling a field using an expression + +First, we create a 2D Cartesian mesh constituted by 2 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_1 +Now we create a field on cells and use +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const char *func) "fillFromAnalytic()" +to fill it +with values computed using an expression \b func. This expression is applied to coordinates of +each point (barycenter) for which the field value is computed. We want the \b field to have + 3 components computed as follows. (In \b func, we refer to the +first component of a point using the variable "a", and to the second component, using +the variable "b"). +- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. +- Component #1 = the first coordinate of the point; hence "JVec * a". +- Component #2 = distance between the point and SC origin (0.,0.); hence +"KVec * sqrt( a*a + b*b )". + +In addition we want to add 10.0 to each component computed as described above, hence +"10" in \b func. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_2 +Now we ascertain that the result field is as we expect. We check the second tuple of +the \b field. We get barycenter of the cell #1 to check that values of the second +tuple (#1) are computed as we want. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_3 + + +\subsubsection medcouplingcppexamplesFieldDoubleBuild5 Some operations that can be carried out on fields on cells + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_2 + +\anchor BEGIN_CPP_ONLY +The decrementation of ref counter should be carried out in CPlusPlus only ... + +\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_3 +\anchor END_CPP_ONLY + + +\subsubsection cpp_mcfielddouble_renumberNodes Permuting a field on nodes + +First, we create a supporting 2D mesh constituted by 4 cells. We create a 2x2 +Cartesian mesh and then convert it to an unstructured one, since the Cartesian mesh +is not suitable for +\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberNodes "renumberNodes()" as its + nature does not imply node renumbering. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_1 +Then we create a field on nodes using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()", +such that its values to coincide with coordinates of field location points that are + nodes in our case (as our field is \ref ParaMEDMEM::ON_NODES "ON_NODES"). +At last we ascertain that field values are equal to node coordinates. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_2 +Now, we are going to reverse order of nodes using +\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberNodes "renumberNodes()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_3 +As a result, the underlying mesh of \b field is changed and its nodes are also + renumbered. +And the field values are still equal to node coordinates of the renumbered \b mesh2. + + +\subsubsection cpp_mcfielddouble_renumberCells Permuting a field on cells + +First, we create a supporting 2D mesh constituted by 4 cells. We create a 2x2 +Cartesian mesh and then convert it to an unstructured one, since the Cartesian mesh +is not suitable for +\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberCells "renumberCells()" as its + nature does not imply cell renumbering. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_1 +Then we create a field on cells using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()", +such that its values to coincide with coordinates of field location points that are + cell barycenters in our case (as our field is \ref ParaMEDMEM::ON_CELLS "ON_CELLS"). +At last we ascertain that field values are equal to cell barycenters. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_2 +Now, we are going to reverse order of cells using +\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberCells "renumberCells()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_3 +As a result, the underlying mesh of \b field is changed and its cells are also + renumbered. +And the field values are still equal to cell barycenters of the renumbered \b mesh2. + + +\anchor BEGIN_CPP_ONLY +\subsubsection cpp_mcfielddouble_fillFromAnalytic_c_func Filling a field using a C function + +We want to create a 3D vector field lying on a 2D mesh using a C function as a value +generator. For that, first, we define the function that computes 3 values basing on 2 +coordinates of a 2D point. +\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_0 +Then we create the 2D mesh and the field on it, and finally we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, FunctionToEvaluate func) "fillFromAnalytic()" +to fill the field with values each composed of 3 components. +\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_1 +As a result, number of tuples in the field equals to the number of cells in the mesh, +and number of components equals to 3 as required. +\anchor END_CPP_ONLY + + +\anchor BEGIN_CPP_ONLY +\subsubsection cpp_mcfielddouble_applyFunc_c_func Changing a field by applying a C function + +We want to transform a 2D vector field to a 3D vector field by +applying a C function to each vector value. For that, first, we define the function +that computes 3 values basing on 2 components of a 2D vector. +\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_0 +Then we create the 2D mesh and the vector field on it. +\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_applyFunc_c_func_1 +Finally we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, FunctionToEvaluate func) "applyFunc()" +to change the field values. +\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_applyFunc_c_func_2 +As a result, number of tuples in the field equals to the number of cells in the mesh, +and number of components becomes equal to 3 as required. +\anchor END_CPP_ONLY + + +\anchor BEGIN_CPP_ONLY + +\subsubsection cpp_mcfield_remapper_highlevel Using interpolation tools - High level usage + +\code +... +const char sourceFileName[]="source.med"; +MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); +const char targetFileName[]="target.med"; +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); +// +sourceField->setNature(ConservativeVolumic);//Specify which formula to use in case of non overlapping meshes +MEDCouplingRemapper remapper; +remapper.setPrecision(1e-12); +remapper.setIntersectionType(INTERP_KERNEL::Triangulation); +remapper.prepare(sourceField->getMesh(),med_target_mesh,"P0P0"); +MEDCouplingFieldDouble *targetField=remapper.transferField(sourceField,/*default_value*/4.57);//Any target cell not intercepted by any source cell will have value set to 4.57. +... +// clean-up +targetField->decrRef(); +sourceField->decrRef(); +med_target_mesh->decrRef(); +\endcode + +\anchor END_CPP_ONLY + + +\anchor BEGIN_CPP_ONLY + +\subsubsection cpp_mcfield_remapper_middlelevel Using interpolation tools - Middle level usage + +- The simplest way to use the interpolator with \ref medcoupling data struture is illustrated in the following example. + +\code +... +MEDCouplingUMesh *med_source_mesh=MEDLoader::ReadUMeshFromFile("source.med","Source_mesh",0); +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile("target.med","Target_mesh",0); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_source_mesh(med_source_mesh); +MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_target_mesh(med_target_mesh); +// Go for interpolation... +INTERP_KERNEL::Interpolation2D myInterpolator; +myInterpolator.setPrecision(1e-7); +myInterpolator.setIntersectionType(INTERP_KERNEL::Geometric2D); +std::vector > resultMatrix; +INTERP_KERNEL::Matrix resultMatrix2; +// here the interpolation is performed twice for this code to illustrate the possibility of storing data the interpolation matrix in 2 different data structures. +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); +myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2,"P0P0"); +//Ok resultMatrix and resultMatrix2 contain matrix now +... +\endcode + + +- Same with VTK data structure : + +\code +... +vtkXMLUnstructuredGridReader *readerSource=vtkXMLUnstructuredGridReader::New(); +readerSource->SetFileName("source.vtu"); +vtkUnstructuredGrid *vtk_source_mesh=readerSource->GetOutput(); +readerSource->Update(); +vtkXMLUnstructuredGridReader *readerTarget=vtkXMLUnstructuredGridReader::New(); +readerTarget->SetFileName("target.vtu"); +vtkUnstructuredGrid *vtk_target_mesh=readerTarget->GetOutput(); +readerTarget->Update(); +// Ok at this point we have our mesh in VTK format. +// Go to wrap vtk_source_mesh and vtk_target_mesh. +VTKNormalizedUnstructuredMesh<2> wrap_source_mesh(vtk_source_mesh); +VTKNormalizedUnstructuredMesh<2> wrap_target_mesh(vtk_target_mesh); +// Go for interpolation... +INTERP_KERNEL::Interpolation2D myInterpolator; +//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"); +//Ok let's multiply resultMatrix by source field to interpolate to target field. +resultMatrix.multiply(...) +//clean-up +readerSource->Delete(); +readerTarget->Delete(); +... +\endcode + +\anchor END_CPP_ONLY + + +\subsection ExamplesFieldsAccess Access + +\subsubsection cpp_mcfielddouble_getValueOn_time Getting a field value at some point at certain time + +First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh +constituted by 4 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_1 +Then we create a scalar field on cells, whose values vary linearly in time. +We set all field values at a start time to be equal 10.0 using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". +And we set all field values at an end time to be equal 20.0 by doubling the start +time array. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_2 +Now, we want to get a field value at a point [0,0] at a middle time between the start +and end times. We expect the returned value to be equal to an average of 10. and 20. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_3 + + +\subsubsection cpp_mcfielddouble_getValueOnMulti Getting field values at some points + +First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh +constituted by 4 cells. Then we create a scalar field on cells using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnMulti_1 +Now, we want to retrieve all field values using +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()". +The field values relate to cells, hence we will use cell barycenters as a parameter of +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()". +We expect that the double array returned +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()" +is equal to that stored by \b field. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnMulti_2 + + +\subsubsection cpp_mcfielddouble_getValueOn Getting a field value at a point + +First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh +constituted by 4 cells. Then we create a scalar field on cells using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_1 +Now, we want to retrieve all field values using +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn()". +The field values relate to cells, hence we will use cell barycenters to get a field +value at each cell. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_2 +We collected all values returned by +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn()" in an array, so +that we can ascertain that the array of returned values is same as that stored by \b +field. + + +\subsubsection cpp_mcfielddouble_getValueOnPos Getting a value of field lying on a structured mesh + +First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh +constituted by 4 cells. Then we create a scalar field on cells using +\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnPos_1 +Now, we retrieve a field value relating to the cell #3 (this cell has a structured indexed +(1,1)). For that we use +\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnPos "getValueOnPos()" where we +pass the structured indexed of the cell: 1,1,-1 (the last index is meaningless as the +mesh is 2D). +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnPos_2 +After all we ascertain that the returned value corresponds to the expression used for +the field creation. Namely that the value equals to the sum of components of +barycenter of cell #3. diff --git a/doc/doxygen/input/examples/medcouplingexamplesfooter.doxy b/doc/doxygen/input/examples/medcouplingexamplesfooter.doxy new file mode 100644 index 000000000..d7365df16 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesfooter.doxy @@ -0,0 +1,2 @@ + +*/ diff --git a/doc/doxygen/input/examples/medcouplingexamplesheader.doxy b/doc/doxygen/input/examples/medcouplingexamplesheader.doxy new file mode 100644 index 000000000..cd385bcd1 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesheader.doxy @@ -0,0 +1,2 @@ +/*! +\page medcouplingcppexamples MEDCoupling C++ examples diff --git a/doc/doxygen/input/examples/medcouplingexamplesmeshes.doxy b/doc/doxygen/input/examples/medcouplingexamplesmeshes.doxy new file mode 100644 index 000000000..e09432473 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesmeshes.doxy @@ -0,0 +1,675 @@ + +\section ExamplesMeshes Meshes + +\subsection ExamplesMeshesCreate Create + +\subsubsection medcouplingcppexamplesUmeshStdBuild1 Standard build of an unstructured mesh from scratch + +Firstly retrieve basic data in full interlace mode for coordinates, and nodal connectivity cell per cell. +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_1 + +Then create ParaMEDMEM::MEDCouplingUMesh instance giving its mesh dimension (2 here) and a name. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_2 + +Gives an upper bound of the number of cells to be inserted into the unstructured mesh. +\n Then enter nodal connectivity of all cells, cell per cell using ParaMEDMEM::MEDCouplingUMesh::insertNextCell method. +\n When the nodal connectivity cell per cell has been finished, call ParaMEDMEM::MEDCouplingUMesh::finishInsertingCells method in order to restore \b mesh instance. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_3 + +At this level the connectivity part of the mesh \b mesh as been defined. Now let's set the coordinates using array \b coords defined above. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_4 + +At this level mesh is usable. When this mesh is no more needed simply call decrRef to decrement its reference counter. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_5 + + +\subsubsection medcouplingcppexamplesUmeshAdvBuild1 Advanced build of an unstructured mesh from scratch + +Firstly retrieve basic data in full interlace mode for coordinates, and nodal connectivity cell per cell, cell type \b included (3 for INTERP_KERNEL::NORM_TRI3 and 4 for INTERP_KERNEL::QUAD4). +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_1 + +Then create ParaMEDMEM::MEDCouplingUMesh instance giving its mesh dimension (2 here) and a name. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_2 + +Then enter nodal connectivity at once. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_3 + +At this level the connectivity part of the mesh \b mesh as been defined. Now let's set the coordinates using array \b coords defined above. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_4 + +At this level mesh is usable. When this mesh is no more needed simply call decrRef() to decrement its reference counter. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_5 + + +\subsubsection medcouplingcppexamplesCmeshStdBuild1 Standard build of an cartesian mesh from scratch + +We are going to build a 2D cartesian mesh, constituted from 9 nodes along X axis, and 7 nodes along Y axis. + +Firstly retrieve for each direction the discretization and build a \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" on the corresponding direction. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_1 + +Then create ParaMEDMEM::MEDCouplingCMesh instance giving the 2 instances of \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" obtained above. + +There are 2 techniques to get it. + +Either : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_2 + +Or : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_2bis + +\c mesh is now available for use : + +\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_3 + +When this mesh is no more needed simply call decrRef to decrement its reference counter. + +\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_4 + + +\subsubsection cpp_mcumesh_buildBoundaryMesh Getting a bounding mesh + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildBoundaryMesh_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::buildBoundaryMesh "buildBoundaryMesh()" to get a mesh +of lower dimension bounding \b mesh. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildBoundaryMesh_2 +Depending on the value of a parameter, +\ref ParaMEDMEM::MEDCouplingUMesh::buildBoundaryMesh "buildBoundaryMesh()" +creates the mesh sharing the node coordinates array with \b mesh or not. + + +\subsubsection cpp_mcumesh_buildFacePartOfMySelfNode Retrieving a lower dimension mesh based on given nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildFacePartOfMySelfNode_1 +In the following code we retrieve nodes of the cell #0 an then we call +\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" +twice with these nodes and with varying last parameter \b allNodes as input. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildFacePartOfMySelfNode_2 +
If the last parameter is \c true +\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" looks +for segements whose all nodes are given to it, hence it finds segments bounding the cell #0 only. +
If the last parameter is \c false +\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" looks +for any segment whose nodes are given to it, hence it adds more segments to \b mesh2. + + +\subsubsection cpp_mcumesh_buildPartOfMySelfNode Copying cells selected by nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelfNode_1 +In the following code we retrieve nodes of the cell #0 an then we call +\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" +twice with these nodes and with varying last parameter \b allNodes as input. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelfNode_2 +
If the last parameter is \c true +\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" looks +for cells whose all nodes are given to it, hence it finds the cell #0 only. +
If the last parameter is \c false +\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" looks +for any cell whose nodes are given to it, hence it finds all cells of \b mesh because all +cells share the node #4. + + +\subsubsection cpp_mcumesh_buildPartOfMySelf Getting a part of mesh + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelf_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelf "buildPartOfMySelf()" to get a mesh +containing only two cells of \b mesh. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelf_2 + + +\subsection ExamplesMeshesModify Modify + +\subsubsection cpp_mcumesh_findAndCorrectBadOriented3DExtrudedCells Fixing orientation of "extruded" volumes + +First, we create a mesh with 2 incorrectly oriented "extruded" volumes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findAndCorrectBadOriented3DExtrudedCells_1 +Now we check that +\ref ParaMEDMEM::MEDCouplingUMesh::findAndCorrectBadOriented3DExtrudedCells "findAndCorrectBadOriented3DExtrudedCells()" +finds and fixes the reversed cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findAndCorrectBadOriented3DExtrudedCells_2 + + +\subsubsection cpp_mcumesh_arePolyhedronsNotCorrectlyOriented Fixing orientation of polyhedra + +First, we create a mesh with 2 polyhedra, one of which is incorrectly oriented. We create +two "extruded" polyhedra and then convert them to correctly defined polyhedra. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_arePolyhedronsNotCorrectlyOriented_1 +Now we check that +\ref ParaMEDMEM::MEDCouplingUMesh::arePolyhedronsNotCorrectlyOriented "arePolyhedronsNotCorrectlyOriented()" +finds one reversed cell. After that we fix it using +\ref ParaMEDMEM::MEDCouplingUMesh::orientCorrectlyPolyhedrons "orientCorrectlyPolyhedrons()" and +re-check the orientation of polyhedra. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_arePolyhedronsNotCorrectlyOriented_2 + + +\subsubsection cpp_mcumesh_are2DCellsNotCorrectlyOriented Fixing orientation of faces + +First, we create a 2D mesh in 3D space with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is +reversed comparing with others. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_are2DCellsNotCorrectlyOriented_1 +Now we check that +\ref ParaMEDMEM::MEDCouplingUMesh::are2DCellsNotCorrectlyOriented "are2DCellsNotCorrectlyOriented()" +finds one reversed face. After that we fix the incorrectly oriented cell using +\ref ParaMEDMEM::MEDCouplingUMesh::orientCorrectly2DCells "orientCorrectly2DCells()" and +re-check the orientation of cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_are2DCellsNotCorrectlyOriented_2 + + +\subsubsection cpp_mcumesh_renumberNodesInConn Renumbering nodes in the connectivity array + +First, we create a 2D mesh with 1 QUAD4 cell and with undefined coordinates of nodes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodesInConn_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodesInConn "renumberNodesInConn()" +to get the following nodal connectivity of a sole cell: 0,1,2,3. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodesInConn_2 +\b old2newIds array defines how node ids are changed: +- new id of node #0 is -1, +- new id of node #1 is 3, +- new id of node #2 is 4, +- new id of node #3 is 1, +- new id of node #4 is 0. + + +\subsubsection cpp_mcumesh_renumberNodes Renumbering nodes + +First, we create a 2D mesh with 4 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_1 +Next, we use +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()" +to permute nodes so that +- old node #0 becomes #2, +- old node #1 remains #1, +- old node #2 becomes #0, +- old node #3 is removed. + +Number of nodes becomes 3. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_2 + +Next we compare behavior of +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()" and that of +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes2 "renumberNodes2()" which, in contrast to +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()", +moves merged nodes to their barycenter.
+We set #2 as new id of old node #3 and expect that +\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes2 "renumberNodes2()" moves old nodes #0 +and #3 to their barycenter (-0.3,0.0) which becomes position of node #2.
+\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_3 + + +\subsubsection cpp_mcumesh_mergeNodes Merging equal nodes + +First, we create a 2D mesh with 1 QUAD4 and 2 TRI3 cells. The cells are based on 6 nodes +of which 2 nodes fully coincide (#3 and #4) and 3 nodes are equal with precision 0.003. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_1 +Now we merge node duplicates using +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" and check values it returns. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_2 +Contents of \b arr shows ids of old nodes after the merging. The nodes considered equal +one to the other have the same id in \b arr. + +Next we compare behavior of +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" and that of +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes2 "mergeNodes2()" which, in contrast to +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()", +moves merged nodes to their barycenter.
We expect that +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes2 "mergeNodes2()" moves old nodes #0, #2 +and #5 to their barycenter equal to position of node #2.
+First we check that +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" does not move nodes +coincident with the node #2 to the position of node #2, and then we check that +\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes2()" does move. +(We check only the second (Y) component of node coordinates since the first component of +these nodes is exactly same.) +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_3 + + +\subsubsection cpp_mcumesh_zipConnectivityTraducer Removing cell duplicates + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells, so that +- the cell #2 has the same nodal connectivity as the cell #1 does, +- the cell #3 has the same nodal connectivity as the cell #0 does, +- the cell #4 is based on the same nodes as the cell #0 but nodes order is different. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipConnectivityTraducer_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::zipConnectivityTraducer "zipConnectivityTraducer()" +to remove duplicate cells. Then we check that two cells, having exactly same nodal +connectivity with other cells, have been removed. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipConnectivityTraducer_2 +Contents of \b arr shows ids of cells after duplicates removal. If a value (cell id) +equals to its index in \b arr, this means that the cell is not a duplicate of any cell +with lower id. Else, the value gives a cell id to which this cell is equal.
+Thus, the cells #0 and #1 have no preceding equal cell since \b arr[i] == i.
+The cell #2 equals to the cell #1 (== \b arr[2] ).
+The cell #3 equals to the cell #0 (== \b arr[3] ).
+The cell #4 has no equal cell. This is because the cell comparison technique specified +when we called +\ref ParaMEDMEM::MEDCouplingUMesh::zipConnectivityTraducer "zipConnectivityTraducer()" +was 0 ("exact"), if we had used the technique 2 ("nodal"), \b arr[4] would be 0. + + +\subsubsection cpp_mcumesh_zipCoordsTraducer Removing unused nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipCoordsTraducer_1 +Now we create \b mesh2 including all nodes but only two cells of \b mesh, and we use \ref +ParaMEDMEM::MEDCouplingUMesh::zipCoordsTraducer "zipCoordsTraducer()" to remove unused +nodes from \b mesh2. +\ref ParaMEDMEM::MEDCouplingUMesh::zipCoordsTraducer "zipCoordsTraducer()" returns an array +with -1 for unused nodes and new ids for used ones. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipCoordsTraducer_2 + + +\subsubsection cpp_mcumesh_getNodeIdsInUse Retrieving unused nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_1 +Now we create \b mesh2 including all nodes but only two cells of \b mesh, and we use \ref +ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" to get nodes of \b mesh2 +used in its two cells. +\ref ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" returns an array +with -1 for unused nodes and new ids for used ones. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_2 +Now we use \b newNbOfNodes returned by +\ref ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" to convert \b arr +to "New to Old" mode. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_3 + + +\subsubsection cpp_mcumesh_convertToPolyTypes Conversion of cells to "poly" types + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_convertToPolyTypes_1 +Now we convert cells #1 and #3 to type POLYGON and check the result +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_convertToPolyTypes_2 + + +\subsubsection cpp_mcpointset_scale Scaling the mesh + +First, we create a 2D mesh with 4 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_1 +Then we scale it by a factor of 2 with a center (0.,0.). +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_2 +Finally we check that all node coordinates have changed by more than 0.9. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_3 + + +\subsubsection cpp_mcpointset_translate Translating the mesh + +First, we create a 2D mesh with 4 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_1 +Then we translate it by a vector (1.,1.). +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_2 +Finally we check that all node coordinates have changed by more than 0.9. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_3 + + +\subsubsection cpp_mcpointset_rotate Rotating the mesh + +First, we create a 2D mesh with 4 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_1 +Then we rotate it around a point (0.,0.) by 90 degrees clockwise. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_2 +Next, we make a 3D mesh from the 2D one and rotate it around the Z axis by 90 degrees +counter-clockwise. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_3 +Finally we transform the mesh back to 2D space and check that all nodes get back to the +initial location. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_4 + + +\subsection ExamplesMeshesAccess Access + +\subsubsection cpp_mccmesh_getCoordsAt Getting node coordinates along an axis + +We create an 1D Cartesian mesh and retrieves node coordinates using +\ref ParaMEDMEM::MEDCouplingCMesh::getCoordsAt "getCoordsAt()". +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingCMesh_getCoordsAt_1 + + +\subsubsection cpp_mcpointset_getcoordinatesofnode Getting coordinates of a node + +The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh +"MEDCouplingUMesh" with 3 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getCoordinatesOfNode_1 +Here we get coordinates of the second node and check its two coordinates. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getCoordinatesOfNode_2 + + +\subsubsection cpp_mcumesh_areCellsIncludedIn Cells correspondence in two meshes + +First, we create a 2D \b mesh1 with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_1 +Then we create a \b mesh2 which includes cells #4, #2 and #0 of \b mesh1. The two meshes +share the same node coordinates array. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_2 +Now we ascertain that +- \ref ParaMEDMEM::MEDCouplingUMesh::areCellsIncludedIn "areCellsIncludedIn()" +detects that all cells of \b mesh2 are present in \b mesh1, +- the correspondence array \b corr2to1, which gives cell ids of \b mesh2 within +\b mesh1, is equal to the array \b cells2 which selected cells from \b mesh1 for creation +of \b mesh2. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_3 +Now we apply +\ref ParaMEDMEM::MEDCouplingUMesh::areCellsIncludedIn "areCellsIncludedIn()" +in a reverse direction and ascertain that it returns \c false. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_4 +The contents of the correspondence +array \b corr1to2 [2, 3, 1, 4, 0] means the following. +- The cell #0 of \b mesh1 is equal to the cell #2 (== \b corr1to2[ 0 ]) of \b mesh2. +- The cell #1 of \b mesh1 is missing from \b mesh2 (as \b corr1to2[ 1 ] >= \b mesh2->getNumberOfCells()). +- The cell #2 of \b mesh1 is equal to the cell #1 (== \b corr1to2[ 2 ]) of \b mesh2. +- The cell #3 of \b mesh1 is missing from \b mesh2 (as \b corr1to2[ 3 ] >= \b mesh2->getNumberOfCells()). +- The cell #4 of \b mesh1 is equal to the cell #0 (== \b corr1to2[ 4 ]) of \b mesh2. + + +\subsubsection cpp_mcumesh_checkDeepEquivalWith Deep comparison of meshes + +First, we create two 2D meshes with two triangles, so that +- their nodes are almost same but permuted, +- the first triangle is based exactly on the same nodes (taking the permutation into account), +- an order of nodes in the second triangle is changed. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_1 +Then we check that +- \ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalWith "checkDeepEquivalWith()" +considers the meshes equal (i.e. it does not throw any exception) if it is called with a cell +comparison policy \b cellCompPol == 1 +- mapping from \b mesh1 to \b mesh2 for both nodes and cells is as expected. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_2 +Next we ascertain that +\ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalOnSameNodesWith "checkDeepEquivalOnSameNodesWith()" +consider \b mesh1 and \b mesh2 different as they do not share the same nodal connectivity +array.
+After that we make the meshes share the node coordinates array and insert new +triangles based on the same nodes but in different order. This is to ascertain that +\ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalOnSameNodesWith "checkDeepEquivalOnSameNodesWith()" +called with the weakest cell comparison policy considers the meshes equal. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_3 + + +\subsubsection cpp_mcumesh_getPartBarycenterAndOwner Getting barycenters of cells + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::getPartBarycenterAndOwner "getPartBarycenterAndOwner()" to get +barycenters of all but the first cell. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_3 +The returned array contains 4 tuples per 2 components. + + +\subsubsection cpp_mcumesh_getCellsContainingPoints Finding cells containing a point (multi-point case) + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoints_1 +Then we use +\ref ParaMEDMEM::MEDCouplingUMesh::getCellsContainingPoints "getCellsContainingPoints()" to +get cells in contact with tree points. Two of them are in contact with some cells and one is not. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoints_2 +The contents of the result arrays \b cells ([4, 0, 1]) and \b cellsIndex ([0, 0, 1, 3]) +mean the following. +- Point #0 is in contact with none (== \b cellsIndx[1] - \b cellsIndx[0]) cell. +- Point #1 is in contact with 1 (== \b cellsIndx[2] - \b cellsIndx[1]) cell whose id is #4 + (== \b cells[ \b cellsIndx[ 1 ]]). +- Point #2 is in contact with 2 (== \b cellsIndx[3] - \b cellsIndx[2]) cells whose ids are #0 + (== \b cells[ \b cellsIndx[ 2 ]]) and #1 (== \b cells[ \b cellsIndx[ 2 ] + 1 ]). + + +\subsubsection cpp_mcumesh_getCellsContainingPoint Finding cells containing a point + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoint_1 +Then we use +\ref ParaMEDMEM::MEDCouplingUMesh::getCellsContainingPoint "getCellsContainingPoint()" to +get cells in contact with a small ball (point with precision) located near the node #4 and +shifted from this node by its radius \b eps. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoint_2 +Since the node #4 is shared by all cells, size of the vector \b cellIds must be equal to +the number of cells in \b mesh. + + +\subsubsection cpp_mcumesh_buildPartOrthogonalField Getting normals of cells + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is +reversed. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOrthogonalField_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOrthogonalField "buildPartOrthogonalField()" to get +normal vectors to the cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOrthogonalField_2 + + +\subsubsection cpp_mcumesh_getPartMeasureField Getting volumes of cells + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is +reversed. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::getPartMeasureField "getPartMeasureField()" to get +volumes of all but the first cell. If we call +\ref ParaMEDMEM::MEDCouplingUMesh::getPartMeasureField "getPartMeasureField()" with \b +isAbs == \c true, the area of the cell #1 is returned positive, else, negative that +reflects its inverse orientation. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_2 + + +\subsubsection cpp_mcumesh_getCellsInBoundingBox Getting cells using the bounding box + +First, we create a 2D mesh with 1 TRI3 cell. Bounding box of this cell is [0.,0., 1.,1]. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsInBoundingBox_1 +Now we check how +\ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" +searches for cells using the bounding box. We use a bounding box touching the bounding box +of the sole cell at one point (1.,1.). +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsInBoundingBox_2 +If \ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" is +called with parameter \b eps == 0.0, the cell is not found because the two bounding boxes +(one of the cell and the one passed as parameter) do not overlap.
+If \ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" is +called with parameter \b eps == 0.1, the cell is found because \b eps is used to increase +the bounding box of the cell and thus the two bounding boxes intersect each other.
+ + +\subsubsection cpp_mcumesh_findBoundaryNodes Getting boundary nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findBoundaryNodes_1 +Now we use +\ref ParaMEDMEM::MEDCouplingUMesh::findBoundaryNodes "findBoundaryNodes()" to get ids +of boundary nodes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findBoundaryNodes_2 +\ref ParaMEDMEM::MEDCouplingUMesh::findBoundaryNodes "findBoundaryNodes()" returns all +node ids except the node #4 which is in the middle of \b mesh. + + +\subsubsection cpp_mcumesh_getCellIdsLyingOnNodes Getting cells by nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsLyingOnNodes_1 +In the following code we retrieve nodes of the cell #0 an then we call +\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" +twice with these nodes and with varying last parameter \b allNodes as input. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsLyingOnNodes_2 +
If the last parameter is \c true +\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" looks +for cells whose all nodes are given to it, hence it finds the cell #0 only. +
If the last parameter is \c false +\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" looks +for any cell whose nodes are given to it, hence it finds all cells of \b mesh because all +cells share the node #4. + + +\subsubsection cpp_mcumesh_getCellIdsFullyIncludedInNodeIds Getting cells by nodes + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsFullyIncludedInNodeIds_1 +In the following code we retrieve nodes of two cells an then we use +\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsFullyIncludedInNodeIds +"getCellIdsFullyIncludedInNodeIds()" to find these cells by their nodes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsFullyIncludedInNodeIds_2 + + +\subsubsection cpp_mcumesh_buildDescendingConnectivity2 Retrieving the descending connectivity with orientation + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_1 +Now we get and check the descending connectivity. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_2 +Here we get connectivity of the cell #2 (#3 in FORTRAN mode) of \b mesh2 to see how +mutual orientation of cells in \b mesh and \b mesh2 is defined. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_3 +The contents of the result arrays \b desc and \b descIndx mean the following. +- The cell #0 of \b mesh (QUAD4) is bound by 4 (== \b descIndx[1] - \b descIndx[0]) + segments (SEG2) of \b mesh2 whose ids in FORTRAN mode are + - #1 (== \b desc[ \b descIndx[ 0 ]]), + - #2 (== \b desc[ \b descIndx[ 0 ] + 1 ]), + - #3 (== \b desc[ \b descIndx[ 0 ] + 2 ]) and + - #4 (== \b desc[ \b descIndx[ 0 ] + 3 ]). +
Ids are positive since order of nodes in the corresponding cells of \b mesh and \b mesh2 + are same. For example nodes of SEG2 #3 are [4,1] and nodes of QUAD4 #0 are [0,3,\b 4,\b 1]. +- The cell #1 of \b mesh (TRI3) is bound by 3 (== \b descIndx[2] - \b descIndx[1]) segements of + \b mesh2 whose ids in FORTRAN mode are: + - #-3 (== \b desc[ \b descIndx[ 1 ]]), + - #5 (== \b desc[ \b descIndx[ 1 ] + 1 ]) and + - #6 (== \b desc[ \b descIndx[ 1 ] + 2 ]). +
The id -3 means that order of nodes in SEG2 #3 ([4,1]) is different from the order of + these nodes in TRI3 #1: [\b 1,\b 4,2]. +- etc. + +The contents of the result arrays \b revDesc and \b revDescIndx mean the following. +- The cell #0 of \b mesh2 (SEG2) bounds 1 (== \b revDescIndx[1] - \b revDescIndx[0]) cell of \b + mesh whose id is: + - # 0 (== \b revDesc[ \b revDescIndx[ 0 ]]). +- The cell #1 of \b mesh2 bounds 2 (== \b revDescIndx[2] - \b revDescIndx[1]) cells of \b + mesh whose ids are: + - # 0 (== \b revDesc[ \b revDescIndx[ 1 ]]) and + - # 1 (== \b revDesc[ \b revDescIndx[ 1 ] + 1 ]). +- etc. + + +\subsubsection cpp_mcumesh_buildDescendingConnectivity Retrieving the descending connectivity + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity_1 +Now we get and check the descending connectivity. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity_2 +The contents of the result arrays \b desc and \b descIndx mean the following. +- The cell #0 of \b mesh (QUAD4) is bound by 4 (== \b descIndx[1] - \b descIndx[0]) + segments (SEG2) of \b mesh2 whose ids are + - #0 (== \b desc[ \b descIndx[ 0 ]]), + - #1 (== \b desc[ \b descIndx[ 0 ] + 1 ]), + - #2 (== \b desc[ \b descIndx[ 0 ] + 2 ]) and + - #3 (== \b desc[ \b descIndx[ 0 ] + 3 ]). +- The cell #1 of \b mesh (TRI3) is bound by 3 (== \b descIndx[2] - \b descIndx[1]) segements of + \b mesh2 whose ids are: + - #2 (== \b desc[ \b descIndx[ 1 ]]), + - #4 (== \b desc[ \b descIndx[ 1 ] + 1 ]) and + - #5 (== \b desc[ \b descIndx[ 1 ] + 2 ]). +- etc. + +The contents of the result arrays \b revDesc and \b revDescIndx mean the following. +- The cell #0 of \b mesh2 (SEG2) bounds 1 (== \b revDescIndx[1] - \b revDescIndx[0]) cell of \b + mesh whose id is: + - # 0 (== \b revDesc[ \b revDescIndx[ 0 ]]). +- The cell #1 of \b mesh2 bounds 2 (== \b revDescIndx[2] - \b revDescIndx[1]) cells of \b + mesh whose ids are: + - # 0 (== \b revDesc[ \b revDescIndx[ 1 ]]) and + - # 1 (== \b revDesc[ \b revDescIndx[ 1 ] + 1 ]). +- etc. + + +\subsubsection cpp_mcumesh_getReverseNodalConnectivity Getting the reverse nodal connectivity + +First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getReverseNodalConnectivity_1 +Now we get and check its reverse nodal connectivity. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getReverseNodalConnectivity_2 +The contents of the result arrays mean the following. +- Node #0 is shared by 1 (== \b revNodalIndx[1] - \b revNodalIndx[0]) cell whose id is #0 + (== \b revNodal[ \b revNodalIndx[ 0 ]]). +- Node #1 is shared by 2 (== \b revNodalIndx[2] - \b revNodalIndx[1]) cells whose ids are #0 + (== \b revNodal[ \b revNodalIndx[ 1 ]]) and #1 (== \b revNodal[ \b revNodalIndx[ 1 ] + 1 ]). +- etc. + + +\subsubsection cpp_mcpointset_getBoundingBox Getting a minimum box bounding nodes + +First, we create a 3D mesh with 2 nodes, so that the first one has minimal coordinates and +the second one has maximal coordinates. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getBoundingBox_1 +Now we get a bounding box enclosing these nodes. This bounding box should contain +coordinates of our two nodes (but in "no interlace" mode), as the nodes coincide with +points returned by the bounding box. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getBoundingBox_2 + + +\subsubsection cpp_mcpointset_getnodeidsnearpoint Getting nodes close to a point + +The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh +"MEDCouplingUMesh" with 5 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoint_1 +Now we define an array of coordinates of a point close to nodes #0, #2 and #4. + +Thus we expect that +\ref ParaMEDMEM::MEDCouplingPointSet::getNodeIdsNearPoint "getNodeIdsNearPoint()" that +we are going to use, +if called with \b eps = 0.003, would return ids of nodes #0, #2 and #4. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoint_2 + + +\subsubsection cpp_mcpointset_getnodeidsnearpoints Getting nodes close to some points + +The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh +"MEDCouplingUMesh" with 7 nodes and no cells. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoints_1 +Now we define an array of coordinates of 3 points near which we want to find nodes of the mesh. +- Point #0 is at distance 0.001 from the node #1. +- Point #1 is rather far from all nodes. +- Point #2 is close to nodes #3, #4 and #5. + +Thus we expect that +\ref ParaMEDMEM::MEDCouplingPointSet::getNodeIdsNearPoints "getNodeIdsNearPoints()" that +we are going to use, +if called with \b eps = 0.003, would return ids of close nodes #1, #3, #4 and #5. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoints_2 +\b idsIndex returns [0, 1, 1, 4] which means that: +- Point #0 is close to 1 (== \b idsIndex[1] - \b idsIndex[0]) node whose id is +\b ids[ \b idsIndex[ 0 ]]. +- Point #1 is close to 0 (== \b idsIndex[2] - \b idsIndex[1]) nodes. +- Point #2 is close to 3 (== \b idsIndex[3] - \b idsIndex[2]) nodes whose ids are +\b ids[ \b idsIndex[ 2 ]], \b ids[ \b idsIndex[ 2 ] + 1 ] and \b ids[ \b idsIndex[ 2 ] + 2 ]. + + +\subsubsection cpp_mcpointset_findcommonnodes Finding coincident nodes + +First, we create a mesh with 6 nodes, of which two nodes (#3 and #4) are fully coincident +and 3 nodes (#0, #2 and #5) have distance less than 0.004 between them. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_findCommonNodes_1 +Then, we use \ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes()" to find +coincident nodes, and check that (1) calling +\ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes()" with \b prec +== 1e-13 finds the two fully coincident nodes only and (2) +\ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes"(0.004) finds 5 +equal nodes. +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_findCommonNodes_2 diff --git a/doc/doxygen/input/examples/medcouplingexamplesother.doxy b/doc/doxygen/input/examples/medcouplingexamplesother.doxy new file mode 100644 index 000000000..551ca72e5 --- /dev/null +++ b/doc/doxygen/input/examples/medcouplingexamplesother.doxy @@ -0,0 +1,260 @@ + +\section ExamplesOther Other + +\subsection ExamplesOtherInputOutput Input/Output + +\subsubsection cpp_mcfielddouble_WriteVTK Writing fields in a VTK file + +In this example we +- create an 2D mesh and 3 fields on it, +- use +\ref ParaMEDMEM::MEDCouplingFieldDouble::WriteVTK "WriteVTK()" +to write all the fields and the mesh to a VTK file. + +\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_WriteVTK_1 + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection MEDLoaderExample2 Loading a mesh using basic API + +Consider a mesh called "Example2" in file "file2.med" +containing MED_POLYHEDRA, MED_TETRA4, MED_QUAD8, MED_TRI6, MED_SEG2 +and MED_POINT1. In this case you will have : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_8 + +To get 3D cells (MED_POLYHEDRA and MED_TETRA4) you should type : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_7 + +To get 2D cells (MED_TRI6 and MED_QUAD8) you should type : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_4 + +To get 1D cells (MED_SEG2) you should type : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_5 + +And finally for 0D cells (MED_POINT1) you will write : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_6 + +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcumesh_writefile_onemesh_basic Writing one mesh using basic API + +To write one mesh \b myMesh with name \b "myMeshName" in a MED file \b "wfile1.med" the following code should be typed : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_1 + +With the previous code, if "wFile1.med" file exists the file is +crashed and will contain after the call only the contents of myMesh +instance. + +If you want to append a mesh in "wFile1.med" you should type : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_2 + +With the previous code, if the "wFile1.med" has already a mesh called "myMeshName" an +INTERP_KERNEL::Exception will be thrown. +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_CPP_ONLY +\subsubsection cpp_mcumesh_loadfile Loading a mesh using advanced API + +\code + +const char fileName[]=...; +const char meshName[]=...; +MEDFileUMesh *medmesh=MEDFileUMesh::New(fileName,meshName); +std::vector nel=medmesh->getNonEmptyLevels(); +if(nel.size()<1) + throw INTERP_KERNEL::Exception("The test is not good for my file ! Expecting a multi level mesh to play with !"); +MEDCouplingUMesh *m0=medmesh->getMeshAtLevel(nel[1],false); +MEDCouplingUMesh *g1=medmesh->getGroup(nel[1],"mesh2",false); +DataArrayInt *dag1=medmesh->getGroupArr(nel[1],"mesh2",false); +MEDCouplingUMesh *g1bis=m0->buildPartOfMySelf(dag1->getConstPointer(),dag1->getConstPointer()+dag1->getNbOfElems()); +g1bis->setName(dag1->getName()); +if(!g1->isEqual(g1bis,1e-12)) + throw INTERP_KERNEL::Exception("hmmmm :g1 and g1bis should be equal..."); +// +dag1->decrRef(); +g1->decrRef(); +m0->decrRef(); +medmesh->decrRef(); + +\endcode +\anchor END_CPP_ONLY + +\anchor BEGIN_CPP_ONLY +\subsubsection cpp_mcumesh_writefile Writing a mesh using advanced API + +\code + +MEDCouplingUMesh *m=...; //m is a mesh with meshDim=2 spaceDim=2 +MEDCouplingUMesh *m1=...; //m1 is a mesh with meshDim=1 spaceDim=2 same coords than m +MEDCouplingUMesh *m2=...; //m2 is a mesh with meshDim=0 spaceDim=2 same coords than m +MEDFileUMesh *mm=MEDFileUMesh::New(); +mm->setName("mm");//name needed to be non empty +mm->setDescription("Description mm"); +mm->setCoords(m1->getCoords()); +mm->setMeshAtLevel(-1,m1,false); +mm->setMeshAtLevel(0,m,false); +mm->setMeshAtLevel(-2,m2,false); +DataArrayInt *g1=DataArrayInt::New(); +g1->alloc(2,1); +g1->setName("G1"); +const int val1[2]={1,3}; +std::copy(val1,val1+2,g1->getPointer()); +DataArrayInt *g2=DataArrayInt::New(); +g2->alloc(3,1); +g2->setName("G2"); +const int val2[3]={1,2,3}; +std::copy(val2,val2+3,g2->getPointer()); +// +std::vector grps(2); +grps[0]=g1; grps[1]=g2; +mm->setGroupsAtLevel(0,grps,false); +// +g2->decrRef(); +g1->decrRef(); +// +mm->write(2); + +\endcode +\anchor END_CPP_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_loadfile_onetimestep_basic Reading a field at one time step using basic API +So to retrieve a field on 3D cell called "F1Cell" in example file +"file2.med" on a mesh "Example2" (\ref MEDLoaderExample2 "as defined here") on time +step defined by iteration number 2 and iteration 3 the request will be : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_12 + +To retrieve the same field (same iteration) on 2D cells only the call will be : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_13 +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_loadfile_alltimesteps_basic Reading a field at all time steps using basic API + +It is typically recommended to use the following +code when you want to load all time steps of a field on cell "myField" lying on +same mesh "mesh1" in one shot : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_11 + +\anchor END_PYTHON_ONLY + + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_loadfile_allentities Reading a field on all entities using advanced API + +Let's read a field on all entity called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined +by \a iteration and \a order. + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_1 + +To read it there are 3 main approaches : + +- Use ParaMEDMEM::MEDFileField1TS class : + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_3 + +- Use ParaMEDMEM::MEDFileFieldMultiTS class : + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_4 + +- Use iteration ParaMEDMEM::MEDFileFieldMultiTS class : + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_5 + +\anchor END_PYTHON_ONLY + + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_loadfile_partial Reading a partial field using advanced API + +Let's read a partial field called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined +by \a iteration and \a order. + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_1 + +Fields defined partially on a meshes can been read using 2 main approaches : + +- 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 + +- Or the user wants to retrieve the binding (cell ids or node ids) with the whole mesh on which the partial field lies partially on. + +\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 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 approach starting from second approach : + +\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_6 + +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_writefile_severaltimesteps_basic Writing several time steps of a field using basic API + +To write a serie of time steps in a "file3.med" file lying on the same +unstructured mesh the typical code +to write is the following : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_3 + +In the above code, it is important to note that the values of pairs +(iteration,order) should be different between two calls to avoid that +a call to MEDLoader::WriteFieldUsingAlreadyWrittenMesh overwrites a +previous call. +Another important thing is the fact that \c f.getMesh() is not modified. +This write method presents the big advantage to be fast, because +neither check nor read is performed. That's why the parameter of \b writeFromScratch +is not needed here, contrary +to other MEDLoader::Write* methods. + +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_writefile_allentities Writing a field defined on all entities using advanced API + +Let's write a cell field on all entities called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined +by \a iteration and \a order. + +\snippet MEDLoaderExamplesTest.py PySnippetWriteFieldOnAllEntity1_2 + +We can see here that the necessity to deal with both mesh and field to write a field is exposed by the API. The mesh write mode is 2 to tell to MED file that is file already exists to scratch it. +The mode of write is 0 to simply add to the file the field specific part. + +\anchor END_PYTHON_ONLY + + +\anchor BEGIN_PYTHON_ONLY +\subsubsection py_mcfield_writefile_partial Writing a partial field using advanced API + +\snippet MEDLoaderExamplesTest.py PySnippetWriteFieldPartial1_2 + +To write a partial field \a f can have a **null mesh**, because the link with mesh is made given the entry of \a mm MEDFileField1TS::setFieldProfile method. + +\anchor END_PYTHON_ONLY diff --git a/doc/doxygen/input/install.dox b/doc/doxygen/input/install.dox new file mode 100644 index 000000000..bf5daa730 --- /dev/null +++ b/doc/doxygen/input/install.dox @@ -0,0 +1,39 @@ + +/*! +\page paramedmem_install Configuring and Installing MED from sources + +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 first step consists in preparing the configuration of the library : +\verbatim +cd ${MED_SRC} +./build_configure +\endverbatim + +This will create SALOME MED libraries with link to the SALOME Kernel. +Sometimes, if it is desirable to have a standalone version of the library to be used independently from SALOME, use : +\verbatim +cd ${MED_SRC} +./build_configure --without-kernel +\endverbatim + +The library can then be configured : +\verbatim +mkdir ../MED_BUILD +cd ../MED_BUILD +../MED_SRC/configure --prefix=`pwd`/../MED_INSTALL +\endverbatim + +This will configure the library without splitting functionalities. ParaMEDMEM will be compiled if an MPI version has been found. + +The following options can be useful to configure SALOME MED : +- \a --enable-splitter=yes will trigger the compilation of the MEDSPLITTER tool, +- \a --with-metis=${METISDIR} will specify a location for the METIS library, +- \a --with-scotch=${SCOTCHDIR} will specify a location for the SCOTCH library, +- \a --with-med3=${MED3DIR} specifies a location for MED-file library, +- \a --with-hdf5=${HDF5DIR} specifies a location for the HDF5 library (must be the same as that used for the MED-file library) +- \a --with-lam=${LAMDIR} specifies an install path for a LAM MPI library, +- \a --with-mpich=${MPICHDIR} specifies an install path for a MPICH-1 library. +*/ diff --git a/doc/doxygen/input/interpolation/Geometric2D.dox b/doc/doxygen/input/interpolation/Geometric2D.dox new file mode 100644 index 000000000..e97cf0e83 --- /dev/null +++ b/doc/doxygen/input/interpolation/Geometric2D.dox @@ -0,0 +1,237 @@ +/*! +\page interpkernelGeo2D Geometric2D Intersector + +Like other intersectors the aim of this intersector is to compute intersection between 2 +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 +potentially useful functions.\n +This page described Geometric2D intersector basic principles and +specific usage. + +\section interpkernelGeo2DIntro Introduction + +The principle used in this intersector to perform boolean operation on geometry is geometric-modeler like. +The data structure used to describe polygons is boundary description. That is to say the internal +representation of a polygon is its edges composing it. + +\subsection interpkernelGeo2DNamingConv Naming conventions + + - An \ref INTERP_KERNEL::AbstractEdge "edge" is defined by a start + node, a end node and a curve equation (linear or arc of + circle). \b WARNING : start node and end node \b HAVE \b TO \b BE + different and distant at least equal to precision set. + - An \ref INTERP_KERNEL::ElementaryEdge "elementary edge" is an edge \b NOT \b splittable \b without \b applying + \b mathematical \b intersection \b computation. + - A \ref INTERP_KERNEL::ComposedEdge "composed edge" is a collection of consecutive edges hierarchically \b splittable + \b without \b any \b mathematical \b intersection \b computation. + +Consecutive means that in a composed edge if edge \a e2 follows edge +\a e1, the end node of \a e1 is geometrically equal to start node of +\a e2. + +\subsection interpkernelGeo2DBasicConcepts Basic concepts + +A \ref INTERP_KERNEL::QuadraticPolygon "quadratic polygon" is a +specialization of a +\ref INTERP_KERNEL::ComposedEdge "composed edge" in that it is +closed. Closed means that the start node of first edge is equal to end +node of last edge.\n +A \ref INTERP_KERNEL::ComposedEdge "composed edge" is considered as a +collection of \ref INTERP_KERNEL::AbstractEdge "abstract edges". An +\ref INTERP_KERNEL::AbstractEdge "abstract edge" is either an \ref +INTERP_KERNEL::ElementaryEdge "elementary edge" or itself a \ref +INTERP_KERNEL::ComposedEdge "composed edge".\n A composite pattern has +been used here. + +Each \ref INTERP_KERNEL::ElementaryEdge " elementary edge" and each +\ref INTERP_KERNEL::Node "nodes" have a flag that states if during +the split process if it is \b out, \b on, \b in or \b unknown. + +\section interpkernelGeo2DBoolOp Boolean operation algorithm + +\subsection interpkernelGeo2DBoolOpPrinc Basics + +The boolean operation (intersection) between two polygons is used in P0 P0 interpolation. + +The process of boolean operations between two polygons P1 and P2 is done in three steps : + + -# \ref interpkernelGeo2DBoolOpStep1 "splitting". + -# \ref interpkernelGeo2DBoolOpStep2 "edges localization". + -# \ref interpkernelGeo2DBoolOpStep3 "result polygons building". + +\subsection interpkernelGeo2DBoolOpStep1 Step1 : splitting. + +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 +\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 +\ref INTERP_KERNEL::ElementaryEdge "elementary edge" constituting P2 +is either \b in, \b out or \b on polygon P1. + +During split process, when, without any CPU overhead, the location can be +deduced, the nodes and edges are localized. + +This step of splitting is common to all boolean operations.\n +The method in charge of that is INTERP_KERNEL::QuadraticPolygon::splitPolygonsEachOther. + +\subsection interpkernelGeo2DBoolOpStep2 Step2 : Edges localization. + +Perform localization of each splitted edge. As \ref interpkernelGeo2DBoolOpStep1 "split process" it + 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 +\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 +following these rules : + + * + * + * + * + * + * + * + * + * + * + *
Previous Edge LocCurrent start node Loc Current edge Loc
UNKNOWN ANY UNKNOWN -> \ref interpkernelGeo2DAlgLoc "Absolute search"
OUT ON IN
OUT ON_TANGENT OUT
IN ON OUT
IN ON_TANGENT IN
OUT OUT OUT
IN IN IN
ON ANY UNKNOWN -> \ref interpkernelGeo2DAlgLoc "Absolute search"
+ +The method in charge of that is INTERP_KERNEL::QuadraticPolygon::performLocatingOperation. + +\subsection interpkernelGeo2DBoolOpStep3 Step3 : Result polygon building. + +This stage links each edge with wanted loc. \b Contrary to last 2 steps it is obviously boolean +operation dependant. Let's take the case of the intersection that is used in +P0->P0 interpolation. \n The principle of result polygon building is to build polygon by taking +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. + +The method in charge of that is INTERP_KERNEL::QuadraticPolygon::buildIntersectionPolygons. + +\section interpkernelGeo2DAlg underneath algorithms. + +\subsection interpkernelGeo2DAlgLoc Absolute localization algorithm. + +This algorithm is called when splitting process has been done, and +that we are sure that the edge is either \b fully \b in ,or \b fully \b on or \b fully +\b out. + +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$ +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-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. + +This computation is \b very \b expensive, that why some tricks as described in +\ref interpkernelGeo2DBoolOpStep2 "localization techniques" are used to call as few as possible +during intersecting process. + +\subsection interpkernelGeo2DAlgIntsect Intersection algorithms. + +The only mathematical intersections performed are edges intersections. +The algorithms used are : + + -# Lin-Lin intersection : http://mathworld.wolfram.com/Line-LineIntersection.html + -# Lin-Arc intersection : http://mathworld.wolfram.com/Circle-LineIntersection.html + -# Arc-Arc intersection : http://mathworld.wolfram.com/Circle-CircleIntersection.html + +\subsection interpkernelGeo2DAlgOthers Other algorithms. + +As internal architecture is quite general, it is possible to have more than classical intersection on any polygons : + + - \ref INTERP_KERNEL::ComposedEdge::getAreaOfZone "area" computation is available. + - \ref INTERP_KERNEL::QuadraticPolygon::getPerimeterFast "perimeter" computation. + - \ref INTERP_KERNEL::QuadraticPolygon::getHydraulicDiameter "Hydraulic diameter" computation. + +\section interpkernelGeo2DUsage Usage. + +This intersector is usable standalone. To use a set of user friendly methods have been implemented. + + - INTERP_KERNEL::QuadraticPolygon::buildArcCirclePolygon method builds from a \c std::vector of INTERP_KERNEL::Node* \a V, an instance of QuadraticPolygon \a P. + \a P will have \f$ N_{edges} = V.size()/2 \f$ edges. Quadratic edge \f$ Edge_i i \in [0,N_{edges}-1] \f$ starts with node V[i], ends with node V[i+1] and has a middle in + \f$ V[i+N_{edge}] \f$. \n If start, end and middle nodes of edge \f$ Edge_i \f$ are aligned by a precision specified by INTERP_KERNEL::QUADRATIC_PLANAR::setArcDetectionPrecision. + - INTERP_KERNEL::QuadraticPolygon::buildLinearPolygon method builds from a \c std::vector of INTERP_KERNEL::Node* \a V, an instance of QuadraticPolygon \a + P. \a P will have \f$ N_edges = V.size() \f$ edges. Linear edge \f$ Edge_i i \in [0,N_{edges}-1] \f$ starts with node V[i] and ends with node V[i+1]. + +The orientation of polygons (clockwise, inverse clockwise) impact computation only on the sign of areas. During intersection of 2 polygons their orientation can be different. + +The usage is simple : + +\code +... +// defining a precision +INTERP_KERNEL::QUADRATIC_PLANAR::setPrecision(1e-5); +INTERP_KERNEL::QUADRATIC_PLANAR::setArcDetectionPrecision(1e-5); +// +INTERP_KERNEL::QuadraticPolygon *polygon1=...; +bool isQuadratic=...//Depends on the nature of your cell. If your cell is MED_QUAD8 or MED_TRIA6 for example isQuadratic=true. +const double *externalTabXCoords=...; +const double *externalTabYCoords=...; +std::vector nodes; +INTERP_KERNEL::QuadraticPolygon *polygon2=0; +for(int i=0;iintersectWith(*polygon2); +double dhydPol1=polygon1->getHydraulicDiameter(); +double areaPol1=polygon1->getAreaOfZone(); +//clean-up +delete polygon1; +delete polygon2; +... +\endcode + +\section interpkernelGeo2DExample Example of result. + +Here an example of 2 polygons. The left one \a P1 has 4 edges and the +right one \a P2 has 4 edges too. + +\anchor interpkernelGeo2DEx1 +\image html SampGeo2D1.png "An example of intersection of 2 polygons." +\image latex SampGeo2D1.eps "An example of intersection of 2 polygons." + +After \ref interpkernelGeo2DBoolOpStep1 "spliting process" \a P1 has 6 edges and \a P2 has 6 edges too. + +\anchor interpkernelGeo2DEx2 +\image html SampGeo2D2.png "After spliting process two edges of P1 have been located has out." +\image latex SampGeo2D2.eps "After spliting process two edges of P1 have been located has out." + +\note BLUE is for OUT, GREEN for IN and RED for ON. + +For each 6 edges \ref interpkernelGeo2DBoolOpStep2 "locate" them. + +\anchor interpkernelGeo2DEx3 +\image html SampGeo2D3.png "Result after locating phase." +\image latex SampGeo2D3.eps "Result after locating phase." + +Too finish \ref interpkernelGeo2DBoolOpStep3 "closing" polygons. + +\anchor interpkernelGeo2DEx4 +\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 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/input/interpolation/barycoords.dox b/doc/doxygen/input/interpolation/barycoords.dox new file mode 100644 index 000000000..b45c2a60d --- /dev/null +++ b/doc/doxygen/input/interpolation/barycoords.dox @@ -0,0 +1,39 @@ +/*! +\page barycoords Barycentric coordinates algorithm + +Computation of barycentric coordinates is used to fill interpolation +matrix in case of P1 and P1d types of interpolation. Computation of +barycentric coordinates consists in finding weights of vertices +bearing values within the cell. The cell is triangular in 2D space and +tetrahedral in 3D space. + +Input of the algorithm include: +- coordinates of cell vertices (p1...pn), +- 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 +- (a1*p1+...+an*pn)=b and +- (a1+...+an)=1.0 + +Combining the last two expressions we get an equation in matrix form +a * T = ( b - pn ) +where +- a is a vector of coefficients a1...an +- b is a vector of cartesian coordinates of barycentre +- T is a matrix expressed via cartesian coordinates of vertices as +
in 2D case 
+| x1-x3 x2-x3 |
+| y1-y3 y2-y3 |
+in 3D case 
+| x1-x4 x2-x4 x3-x4 |
+| y1-y4 y2-y4 y3-y4 |
+| z1-z4 z2-z4 z3-z4 |
+ +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 coefficients a. + +*/ diff --git a/doc/doxygen/input/interpolation/interpkernel.dox b/doc/doxygen/input/interpolation/interpkernel.dox new file mode 100644 index 000000000..ce61e679d --- /dev/null +++ b/doc/doxygen/input/interpolation/interpkernel.dox @@ -0,0 +1,85 @@ +/*! +\page interpkernel Interpolation kernel + +\section InterpKerIntro Introduction + +The main purpose of this module is to propose a set of algorithms for +mesh interpolation \b fully \b independent \b of \b the \b mesh \b data structure 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. + +\section InterpKerMainArchitecture Main architecture of interpolation kernel. + +In the %interpolation kernel, algorithms that computes the intersection \f$ T_i\cap S_j\f$ given the locations and geometries of source cell \f$ S_j \f$ +and target cell \f$ T_i \f$ are called \subpage InterpKerIntersectors. + +As can be seen in \subpage InterpKerRemapGlobal "the theory of interpolation", all the proposed interpolators aim at +filling the interpolation matrix W (which is generally sparse). For each pair (i,j), \f$ W_{ij} \f$ is obtained +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 +is too far from an another cell in the target mesh each. + +So for a given type of interpolation, the computation of W is +performed in two steps : + +-# A filtering process reduces the number of pairs of elements for which the calculation must be carried out by + eliminating the pairs whose bounding boxes do not intersect. +-# For all remaining pairs calling for each intersector (click here for the available \ref InterpKerIntersectors). + +Whatever its dimension and type, each interpolator inherits from INTERP_KERNEL::Interpolation which is a +template (CRTP) class than enable an easy access to the main API without useless CPU cost. + +\subsection InterpKerMeshType class MeshType + +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 \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 : + +- Const values / Types + - MyConnType : represents type of connectivity index. This is typically \c int or \c long \c int . + - MY_SPACEDIM : space dimension. Dimension relative to coordinates. + - MY_MESHDIM : the dimension of all cells in meshes. + - My_numPol : policy of numbering. C Format ( \f$ [0,n-1] \f$ ) or FORTRAN ( \f$ [1,n] \f$ ). +- Methods + -# \code void getBoundingBox(double *boundingBox) const \endcode + -# \code INTERP_KERNEL::NormalizedCellType getTypeOfElement(MyConnType eltId) const \endcode + -# \code unsigned char getNumberOfNodesOfElement(MyConnType eltId) const \endcode + -# \code unsigned long getNumberOfNodes() const \endcode + -# \code unsigned long getNumberOfElements() const \endcode + -# \code const MyConnType *getConnectivityPtr() const \endcode + -# \code const double *getCoordinatesPtr() const \endcode + -# \code const MyConnType *getConnectivityIndexPtr() const \endcode + -# \code void releaseTempArrays() \endcode +- Formats of arrays + - the array returned by \c getCoordinatesPtr must be a \b full \b interlace array. + - the arrays returned by \c getConnectivityPtr and \c getConnectivityIndexPtr must be with the same principle as it is \ref MEDCouplingUMeshNodalConnectivity "implemented in MEDCouplingUMesh". Of course the numbering format may change according to \a My_numPol policy. + +Note that the array format for connectivity is kept close to MED. It is +close to VTK format too but slightly different. So it may require for the VTK side a copy +on wrap. To avoid this copy of a part of the connectivity structure, an iterator should be used. + +\subsection InterpKerMatrixType class MatrixType + +As already said, the matrix returned by interpolator is typically a sparse matrix. Instances of +\c class \c MatrixType are used to store the resulting interpolation matrix. To be able to be filled by the interpolator the \c MatrixType class has to match the following concept : + +- Methods + -# \code void resize(uint nbrows) \endcode + -# \code Row &operator [] (uint irow) \endcode + +\c class \c Row has to match at least the following concept : + +- Methods + - \code void insert(const std::pair& myPair) \endcode + +Note that \c std::vector\c < \c std::map > is a candidate for \c MatrixType. + +*/ diff --git a/doc/doxygen/input/interpolation/interptheory.dox b/doc/doxygen/input/interpolation/interptheory.dox new file mode 100644 index 000000000..bc0ea8838 --- /dev/null +++ b/doc/doxygen/input/interpolation/interptheory.dox @@ -0,0 +1,271 @@ +/*! +\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: + +\f[ + \phi_t=W.\phi_s. +\f] + +\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 discretization (on cells P0, on nodes P1,...). + +\section ConsInterp Conservative interpolation + +At the basis of many CFD numerical schemes is the fact that physical +quantities such as density, momentum per unit volume or energy per +unit volume obey some balance laws that should be preserved at the +discrete level on every cell. + +It is therefore often desired that the process interpolation preserve the +integral of \f$ \phi \f$ on any domain. At the discrete level, for any +target cell \f$ T_i \f$, the following \b general \b interpolation \b +formula has to be satisfied : +\anchor InterpKerGenralEq +\f[ +\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 +geometry of source and target mesh cells. + +\section MeshOverlap Mesh overlapping + +Another important property of the interpolation process is the maximum principle: the field values resulting from the interpolation should remain between the upper and lower bounds of the original field. +When interpolation is performed between a source mesh S and a target +mesh T the aspect of overlapping is important. In fact if any cell of +of S is fully overlapped by cells of T and inversely any cell of T is +fully overlapped by cells of S that is +\f[ +\sum_{S_j} Vol(T_i\cap S_j) = Vol(T_i),\hspace{1cm} and \hspace{1cm} \sum_{T_i} Vol(S_j\cap T_i) = Vol(S_j) +\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. + +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, +- 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 + +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}. +\f] + +Here Vol represents the volume when the mesh dimension is equal to 3, the +area when mesh dimension is equal to 2, and length when mesh dimension is equal to 1. + +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}. +\f] + +As the field values are constant on each +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) }. +\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. +Hence in the \ref InterpKerGenralEq "general interpolation equation" the +left hand side becomes : + +\f[ +\int_{T_i} \phi = P_{T_i}, +\f] + +while the right hand side is now : + +\f[ +\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = +\sum_{S_j\cap T_i \neq \emptyset} \frac{Vol(T_i\cap S_j)}{ Vol(S_j)}.P_{S_j}. +\f] + +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) }. +\f] + +\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: + + * + * + * + * + *
Intensive extensive
Conservation \f[\frac{Vol(T_i\cap S_j)}{ Vol(T_i)}\f]
\ref TableNatureOfFieldExampleRevIntegral "RevIntegral" 		\f[ \frac{Vol(T_i\cap S_j)}{ \sum_{T_i} Vol(S_j\cap T_i) }\f]
\ref TableNatureOfFieldExampleIntegralGlobConstraint "IntegralGlobConstraint"
Maximum principle \f[\frac{Vol(T_i\cap S_j)}{ \sum_{S_j} Vol(T_i\cap S_j)}\f]
\ref TableNatureOfFieldExampleConservVol "ConservativeVolumic" 		\f[\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }\f]
\ref TableNatureOfFieldExampleIntegral "Integral"
+ +\section TableNatureOfFieldExample Illustration of a non overlapping P0P0 interpolation + +Let's consider the following case with a source mesh containing two cells and a target mesh containing one cell. +Let's consider a field FS on cells on the source mesh that we want to interpolate on the target mesh. + +The value of FS on the cell#0 is 4 and the value on the cell#1 is 100. + +The aim here is to compute the interpolated field FT on the target mesh of field FS depending on the \ref NatureOfField "nature of the field". + +\anchor TableNatureOfFieldEx1 +\image html NonOverlapping.png "An example of non overlapping intersection of two meshes." + +The first step of the interpolation leads to the following M1 matrix : + +\f[ + M1=\left[\begin{tabular}{cc} + 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 : + +\f[ + M_{Conservative Volumic}=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{0.125+0.75}}$ & + $\displaystyle{\frac{0.75}{0.125+0.75}}$ \\ + \end{tabular}\right]=\left[\begin{tabular}{cc} + 0.14286 & 0.85714 \\ + \end{tabular}\right] +\f] +\f[ + FT=\left[\begin{tabular}{cc} + $\displaystyle\frac{0.125}{0.875}$ & $\displaystyle\frac{0.75}{0.875}$ \\ + \end{tabular}\right].\left[\begin{tabular}{c} + 4 \\ + 100 \\ + \end{tabular}\right] + =\left[\begin{tabular}{c} + 86.28571\\ + \end{tabular}\right] +\f] + +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 + +If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{Integral} \f$ matrix : + +\f[ + M_{Integral}=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{9}}$ & $\displaystyle{\frac{0.75}{3}}$ \\ + \end{tabular}\right]=\left[\begin{tabular}{cc} + 0.013888 & 0.25 \\ + \end{tabular}\right] +\f] +\f[ + FT=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{9}}$ & $\displaystyle{\frac{0.75}{3}}$ \\ + \end{tabular}\right].\left[\begin{tabular}{c} + 4 \\ + 100 \\ + \end{tabular}\right] + =\left[\begin{tabular}{c} + 25.055\\ + \end{tabular}\right] +\f] + +This type of interpolation is typically recommended for the interpolation of \b power (\b NOT \b power \b density !) for +a user who wants to conserve the quantity \b only on the intersecting part of the source mesh (the green part on the \ref TableNatureOfFieldEx1 "example") + +This type of interpolation is equivalent to the computation of \f$ FS_{vol} \f$ followed by a multiplication by \f$ M1 \f$ where \f$ FS_{vol} \f$ is given by : + +\f[ + FS_{vol}=\left[\begin{tabular}{c} + $\displaystyle{\frac{4}{9}}$ \\ + $\displaystyle{\frac{100}{3}}$ \\ + \end{tabular}\right] +\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 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 + +If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{IntegralGlobConstraint} \f$ matrix : + +\f[ + M_{IntegralGlobConstraint}=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{0.125}}$ & ${\displaystyle\frac{0.75}{0.75}}$ \\ + \end{tabular}\right]=\left[\begin{tabular}{cc} + 1 & 1 \\ + \end{tabular}\right] +\f] +\f[ + FT=\left[\begin{tabular}{cc} + 1 & 1 \\ + \end{tabular}\right].\left[\begin{tabular}{c} + 4 \\ + 100 \\ + \end{tabular}\right] + =\left[\begin{tabular}{c} + 104\\ + \end{tabular}\right] +\f] + +This type of interpolation is typically recommended for the interpolation of \b power (\b NOT \b power \b density !) for +a user who wants to \b conserve \b all \b the \b power in its source field. Here we have 104 W in source field, we have 104 W too, +in the output target interpolated field. + +\b BUT, As we can see here, the maximum principle is \b not respected here, because the target cell #0 has a value higher than the two +intercepted source cells. + +\subsection TableNatureOfFieldExampleRevIntegral Reverse integral case + +If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{RevIntegral} \f$ matrix : + +\f[ + M_{RevIntegral}=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{1.5}}$ & $\displaystyle{\frac{0.75}{1.5}}$ \\ + \end{tabular}\right]=\left[\begin{tabular}{cc} + 0.083333 & 0.5 \\ + \end{tabular}\right] +\f] +\f[ + FT=\left[\begin{tabular}{cc} + $\displaystyle{\frac{0.125}{1.5}}$ & $\displaystyle{\frac{0.75}{1.5}}$ \\ + \end{tabular}\right].\left[\begin{tabular}{c} + 4 \\ + 100 \\ + \end{tabular}\right] + =\left[\begin{tabular}{c} + 50.333\\ + \end{tabular}\right] +\f] + +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 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 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/input/interpolation/intersectors.dox b/doc/doxygen/input/interpolation/intersectors.dox new file mode 100644 index 000000000..5c8f3d6e2 --- /dev/null +++ b/doc/doxygen/input/interpolation/intersectors.dox @@ -0,0 +1,138 @@ +/*! +\defgroup InterpKerGrpIntPlan Planar Intersector + +Here are listed all the methods to be called or to overload to all +concrete intersector. + +\page InterpKerIntersectors Intersectors + +\section interpolation2D Special features of 2D intersectors + +\subsection InterpKerPlanarIntGenP0P0 P0->P0 : PlanarIntersector. + +All the 2D intersectors inherits from INTERP_KERNEL::PlanarIntersector class. + +All the important methods are \ref InterpKerGrpIntPlan "described here".\n To sum up the main task offered by this class is to give the +evaluation of interpolation of one cell in source mesh with an another +cell in target mesh. + +\subsection InterpKerPlanarIntFeatureP0P0 P0->P0 intersectors features. + +When remapping two dimensional fields, areas of intersection between polygonal cells are to be computed. Three algorithms are available: +- Triangle: decompose each cells into triangles and computes triangle-triangle intersection by determining segment crossings and node inclusions. This algorithm is the fastest if both meshes are made of triangular cells. +- Convex: presume that both meshes are made of convex cells, and performs a direct computation of the intersection nodes between two cells through a sweep line algorithm (see F. Preparata and M. Shamos, 1985 in \ref references). +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 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 \subpage barycoords "barycentric coordinates" +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. + +The following options are available for the 2D intersection computations: + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be + * used in the computation of the cell-cell intersections + * Triangle, Convex, \ref interpkernelGeo2D "Geometric2D", PointLocator Triangle
Precision Accuracy of the computations is precision times the characteristic size of the meshes positive real numbers 1.0E-12
PrintLevel Level of verboseness during the computations 0, 1, 2, 3 0
+ +\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 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: + + * + * + * + * + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
MedianPlane Position of the median plane where both cells will be projected real numbers between 0 and 1 0.5
Precision Accuracy of the computations is + * precision times the characteristic size of the meshes + * positive real numbers 1.E-12
Orientation Specifies orientation to take into account. If -1 only negative intersection area are taken into account. If 1 only positive intersection + * area are taken into account. If 0 intersection area are always taken into account. If 2 intersection area are always taken into account (as 0) difference is that absolute value -1,0,1,2 0
DoRotate Performs a rotation of the coordinate + 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 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. + +\section interpolation3D Special features of 3D volumes intersectors + +\subsection InterpKer3DIntGenP0P0 P0->P0 : TargetIntersector + +Unlike \ref InterpKerPlanarIntGenP0P0 "PlanarIntersector phylosophy" +this intersector is slightly different. Here for the moment +there is one instance per pair of meshes \b and target element. See INTERP_KERNEL::TargetIntersector for more details. + +\subsection InterpKer3DIntFeatureP0P0 P0->P0 intersectors features. + +When remapping three dimensional fields, volumes of intersection +between polyhedral cells are to be computed. +Two methods are available : +- Triangle : the method of Jeffrey Grandy, 1999 (see \ref references) +to intersect arbitrary polyhedra. The basic algorithm computes the +intersection of a tetrahedron with an arbitrary (possibly non convex) +polyhedron. Using splitting techniques, it is possible to transform +the problem of computing the intersection between two general +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 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. + + * + * + * + * + * + *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be + * used in the computation of the cell-cell intersections + * Triangle, PointLocator Triangle
SplittingPolicy Way in which the hexahedra are + * split into tetrahedra (only if Intersection_type==Triangle) PLANAR_FACE_5, PLANAR_FACE_6, GENERAL_24, GENERAL_48 GENERAL_48
PrintLevel Level of verboseness during the computations 1, 2, 3, 4, 5 0
+ +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 planar faces and nodes numbered according to the following picture: +\verbatim + + 7 ------ 6 + /| /| + / | / | + 3 ------ 2 | + | | | | + | | | | + | 4-----|- 5 + | / | / + 0 ------ 1 +\endverbatim +The use of the SPLIT_NODES_5 splitting policy would lead to a 5 tetrahedra decomposition as follows : +\verbatim + 0, 1, 5, 2 + 0, 4, 5, 7 + 0, 3, 7, 2 + 5, 6, 7, 2 + 0, 2, 5, 7 +\endverbatim +The use of the SPLIT_NODES_6 splitting policy would lead to a 6 tetrahedra decomposition as follows : +\verbatim + 0, 1, 5, 6 + 0, 2, 1, 6 + 0, 5, 4, 6 + 0, 4, 7, 6 + 0, 3, 2, 6 + 0, 7, 3, 6 +\endverbatim + +*/ diff --git a/doc/doxygen/input/interpolation/remapper.dox b/doc/doxygen/input/interpolation/remapper.dox new file mode 100644 index 000000000..7df282a4c --- /dev/null +++ b/doc/doxygen/input/interpolation/remapper.dox @@ -0,0 +1,25 @@ + +/*! +\page RemapperClasses The remapper class. + +\section InterpKerHighLevUsage High-level usage + +The simplest way of using the \ref interptools in sequential mode is to use the class \c ParaMEDMEM::MEDCouplingRemapper . This class fulfills \c HXX2SALOME rules and may be used in YACS coupling graphs. + +If you intend to use \ref MEDCoupling data structure, ParaMEDMEM::MEDCouplingRemapper class should be used. + +Here is a \ref cpp_mcfield_remapper_highlevel "C++ example". + + +\section InterpKerMidLevUsage Middle-level usage + +This mode is the mode that needs the minimum of prerequisites +(algorithms and the data structure you intend to use). On the other +hand it is needed to specify precisely nature of interpolator. + +As a consequence of the genericity of the interpolators, they are usable only by +instantiating an underlying \ref InterpKerMeshType "mesh" and \ref InterpKerMatrixType "matrix" data structure fulfilling some requirements. + +Here is a \ref cpp_mcfield_remapper_middlelevel "C++ example". + +*/ diff --git a/doc/doxygen/input/interptools.dox b/doc/doxygen/input/interptools.dox new file mode 100644 index 000000000..b0c1b879b --- /dev/null +++ b/doc/doxygen/input/interptools.dox @@ -0,0 +1,28 @@ +/*! +\page interptools Interpolation tools + +\section Presentation +The InterpKernel algorithms are part of the MED tool suite. They +answer to the following basic problem : given a source mesh \f$M_s\f$, a +source field \f$F_s\f$ and a target mesh \f$M_t\f$, reconstruct a field \f$F_t\f$ +that uses \f$M_t\f$ as a support. The InterpKernel suite gives a number of +possibilities to compute the target field, depending on a variety of +user constraints. + +\image html interpolationimage.png "General interpolation scheme" width=10cm + +The starting point for using the tools is the description of the two main different APIs. +- \subpage RemapperClasses "remapper class" and the underlying \subpage interpkernel library for sequential codes using \ref medcoupling fields or other data structures. +- \ref paramedmem for parallel MPI based codes using \c ParaMEDMEM distributed fields, and the algorithms of the \ref interpkernel library. + +The possibilities encompass: +- 1D, 2D lines, 2D (\ref interpolation2D), 3D surfaces(\ref interpolation3Dsurf) and 3D(\ref interpolation3D) handling, +- computation via node localization (\ref pointlocator) or via cell intersection (\ref ConsInterp), +- treatment of extended polygons (where edges can be arcs or segments) +for 2D intersection computations via \subpage interpkernelGeo2D, +- management of fields with P0,P1 or P2 representations. P0<->P0, P1<->P0, P1<->P1 and P2->P0 (non conservative) interpolators are available. + +In case of non \ref MeshOverlap "overlapping meshes", it is important to specify whether the field represents an extensive or intensive physical quantity through +the \ref NatureOfField attribute of the \ref medcoupling field. + +*/ diff --git a/doc/doxygen/input/intro.dox b/doc/doxygen/input/intro.dox new file mode 100644 index 000000000..1eac4dafa --- /dev/null +++ b/doc/doxygen/input/intro.dox @@ -0,0 +1,60 @@ +/*! + +\mainpage Introduction + +\section intro Contents +This document is the user guide of the %MED SALOME module. The MED +module consists in: + +- \ref S1 to manipulate meshes and fields that conform + to the MED data model. This library can be used in C++ programs as + in python script for data processing on meshes and fields. +- \ref S2 that exhibits some useful functions of the + library for a graphical manipulation of data in standard use cases. +- \ref S3 that can be used to process MED data files + +\section S1 A library of functions for data processing + +The figure below represents the layer structure of the packages of the +library: + +\image html medlayers_70pc.png + +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 +- \ref interptools (INTERP_KERNEL + ParaMEDMEM::MEDCouplingRemapper) that provides + mathematical structures and algorithms for interpolation and + localization. + +\section S2 A graphical interface for standard use cases + +The MED module in SALOME comes with a graphical interface that helps +you to deal with most standard use case of fields manipulation. The +user guide can be found here: + +- User guide of the MED Graphical Interface (in french) + +You could also be interested to read the software specifications and +requirements for this graphical module, and even the technical +considerations for development: + +- Software + specifications and requirements of the MED Graphical Interface (in french) +- Developer guide of the MED Graphical Interface (in french) + +\section S3 A set of tools for file manipulation + +- Chapter \ref tools describes various tools based on MEDLoader that can +be helpful for handling MED files (conversion tools and splitting tools). + +\section install Installation +The install procedure of the %MED SALOME module can handle a variety of configurations +to suit the needs of its user. Instructions for configuring and +installing the module an be found in \ref paramedmem_install. + +*/ diff --git a/doc/doxygen/input/medcoupling.dox b/doc/doxygen/input/medcoupling.dox new file mode 100644 index 000000000..bc91f179e --- /dev/null +++ b/doc/doxygen/input/medcoupling.dox @@ -0,0 +1,37 @@ +/*! +\page medcoupling MEDCoupling + +\section MEDCouplingIntro Introduction + +\ref medcoupling "MEDCoupling" is a library (\b libmedcoupling.so or \b medcoupling.dll) fully written in C++ and wrapped to be called in Python too. + +\ref medcoupling "MEDCoupling" C++ library implements a data structure which is the result of the following tradeoff : + +- 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 on +\ref interpkernel "INTERP_KERNEL library" +- light enough to be agile in order to : + - maximize the amount of algorithms being applied on it + - to ease implementation of clients of \ref medcoupling "MEDCoupling". +- large enough to be used for MED file I/O. +- compliant with VTK visualization DataStructure +- integrate HPC constraints (compact structures, limitation of copies and launching of CPU consuming algorithms only when absolutely needed ). +- compliant with ICOCO API + +\ref medcoupling "MEDCoupling" implements a set of algorithms linked to the data structure. + +\section MEDCouplingMainConc Main Concepts + +Here are listed basic concepts present into \ref medcoupling "MEDCoupling". + +For beginners in \ref medcoupling "MEDCoupling" world, it is advisable to read the following concepts in the same order than the underlying list. + +- \subpage MEDCouplingArrayPage "DataArrays" +- \subpage MEDCouplingMeshesPage "Meshes" +- \subpage MEDCouplingFieldsPage "Fields" +- \subpage MEDCouplingFieldTemplatesPage "Field templates" +- \subpage MEDCouplingTimeLabelPage "Time labels" + +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingArray.dox b/doc/doxygen/input/medcoupling/MEDCouplingArray.dox new file mode 100644 index 000000000..edd2f615d --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingArray.dox @@ -0,0 +1,357 @@ + +/*! + +\page MEDCouplingArrayPage MEDCoupling Arrays + +[TOC] + +\section MEDCouplingArrayIntro Introduction + +One of the most basic concept mainly used all over MEDCoupling is +MEDCoupling array. + +This concept is used all over +\ref medcoupling "MEDCoupling", \ref paramedmem "ParaMEDMEM", \ref medloader "MEDLoader" modules so it should be correctly +handled to play well with \ref MEDCouplingMeshesPage "Meshes" and \ref MEDCouplingFieldsPage "Fields". + +\ref ParaMEDMEM::DataArray "DataArrays" are the atomic element of potentially heavy in memory objects in \ref medcoupling "MEDCoupling", \ref paramedmem "ParaMEDMEM" and \ref medloader "MEDLoader". + +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::DataArray "DataArray" \b non \b instantiable \b class that factorizes some common methods of inherited instantiable classes. + +In the rest of the documentation \b DataArray will be used for both \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt". + +\section MEDCouplingArrayBasics Basics concepts of the DataArrays. + +It will be presented in this section common concept shared by the two classes to \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt". + +\subsection MEDCouplingArrayBasicsName Name + +A \ref ParaMEDMEM::DataArray "DataArray" instance has an attribute **name**. + +**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. + +\subsection MEDCouplingArrayBasicsTuplesAndCompo Raw data, tuples and components of DataArrays. + +The main goal of \ref ParaMEDMEM::DataArray "DataArray" is to store contiguous vector of atomical elements with same basic datatype (signed integers, double precision...). This vector of atomical elements is called **raw data** of \ref ParaMEDMEM::DataArray "DataArray". + +The size of this vector of data is called "number of elements". So the number of bytes stored by a \ref ParaMEDMEM::DataArray "DataArray" instance, is equal to +the product of the __number of elements__ * __constant size of DataType__ . + +As \ref ParaMEDMEM::DataArray "DataArray" instances are designed to store vector fields, tensor fields, coordinate of nodes, the notion of _components_ has been added. + +So, \ref ParaMEDMEM::DataArray "DataArrays" have an additional attribute that is number of components that represent the size of a contiguous set of atomical elements. +The vector of atomical elements stored into \ref ParaMEDMEM::DataArray "DataArrays" are grouped in contiguous memory set of atomical elements having each same size. + +The contiguous set of atomical elements is called **tuple**. And each **tuple** stored in raw data, has a length exactly equal to the number of components of +\ref ParaMEDMEM::DataArray "DataArray" storing it. + +Thus : + +\f[ + N_{elements}=N_{tuples}*N_{components}. +\f] + +\f[ + N_{bytes}=N_{elements}*sizeof(DataType)=N_{tuples}*N_{components}*sizeof(DataType). +\f] + +In other words, **raw data** of \ref ParaMEDMEM::DataArray "DataArrays" can be seen as a dense matrix, whose number of components would be the row size and number of tuples +would be the column size. In this point of view of \ref ParaMEDMEM::DataArray "DataArrays" a **tuple** is represented by the corresponding row in the dense matrix. + +Typically in the **raw data** of \ref ParaMEDMEM::DataArray "DataArrays" **number of tuples** is highly bigger than **number of components** ! + +To finish, raw data is stored tuples by tuples, in another words, in **full interlace mode**, which is the natural storage strategy in C/C++ world. + +For example, let's consider a DataArray having 3 components (called *x* for the first component, *y* for the second, and *z* for the third) and composed by 5 tuples. +\n The *raw data* of the DataAarray instance will be organized in memory like that : \f$ x_0,y_0,z_0,x_1,y_1,z_1,x_2,y_2,z_2,x_3,y_3,z_3,x_4,y_4,z_4 \f$. + + +\subsection MEDCouplingArrayBasicsCompoName Information on components name. + +As seen in the sub section above, a \ref ParaMEDMEM::DataArray "DataArray" instance has a defined number of components. + +There is an information attached to each of these components constituting the \ref ParaMEDMEM::DataArray "DataArray". + +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 character. + +\subsection MEDCouplingArrayBasicsTimeLabel DataArrays and TimeLabel. + +\ref ParaMEDMEM::DataArray "DataArrays instances" can consume big amount of data in memory so they inherit from \ref MEDCouplingTimeLabelPage "TimeLabel". +So in C++ it is a good practice to use : +- \c getConstPointer method in readonly access. +- \c getPointer method only if write is needed. + +If the user in C++ or Python wants to modify intensively its **big** \ref ParaMEDMEM::DataArray "DataArray" instance **not** using raw data pointer it is better to invoke +\c setIJSilent just after invocation 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. + +\section MEDCouplingArrayBuildFromScratch Building an array from scratch + +Here is a description of typical usages of \ref ParaMEDMEM::DataArrayDouble "MEDCoupling arrays". + +\ref MEDCouplingArraySteps1 "Here is a C++ example."
+\ref MEDCouplingArraySteps0 "Here is a Python example."
+ + +\section MEDCouplingArrayBasicsCopy Copy DataArrays. + +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) +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* independent from the instance on which the method +\c deepCpy has been invoked. + +\ref cpp_mcdataarray_deepcopy "Here is a C++ example."
+ +\subsection MEDCouplingArrayBasicsCopyShallow Shallow copy of DataArray + +As \ref ParaMEDMEM::DataArray "DataArrays" are the atomic entity of potentially big memory objects into \ref medcoupling "MEDCoupling", the shallow copy +simply returns the same object with the reference counter incremented. + +\ref cpp_mcdataarray_shallowcopy "Here is a C++ example."
+ + +\section MEDCouplingArrayBasicsCompare Compare DataArrays. + +Comparison is \ref medcoupling "MEDCoupling" is a concept highly sensitive because big amount of tests uses this to state about the success or the fail of these tests. +There are two types of comparison : + +- strict, that compares strictly all the non mutable attributes (state sensitive). Methods to perform this strict comparison are : + - ParaMEDMEM::DataArrayInt::isEqual + - ParaMEDMEM::DataArrayDouble::isEqual. + +- less strict, that focus only on non string attributes. Methods to perform less strict comparison are : + - ParaMEDMEM::DataArrayInt::isEqualWithoutConsideringStr + - ParaMEDMEM::DataArrayDouble::isEqualWithoutConsideringStr + +\section MEDCouplingArrayFill Filling DataArray with values + +Both DataArrayDouble and DataArrayInt provide comfort methods that +fill the array with some values. These methods are: +- ParaMEDMEM::DataArrayInt::fillWithZero and + ParaMEDMEM::DataArrayDouble::fillWithZero which assigns zero to all + values in array. +- ParaMEDMEM::DataArrayInt::fillWithValue and + ParaMEDMEM::DataArrayDouble::fillWithValue which assigns a certain value to all + values in array. +- ParaMEDMEM::DataArrayInt::iota() and + ParaMEDMEM::DataArrayDouble::iota() which assigns incrementing values to all + values in array. + +\section MEDCouplingArrayRenumbering Array renumbering + +Here is presented all it is necessary to know concerning renumbering. +Renumbering is intensely required in %MEDLoader in %ParaMEDMEM. One of the user of renumbering is MED file for I/O where cells are sorted by type. +But it is also used on operations of node cell merging. It is also used in parallel mode when splitting of mesh is needed... + +Formally a renumbering is a mathematical application that can be surjective, injective or bijective. This application is defined using an instance of +\ref ParaMEDMEM::DataArrayInt "DataArrayInt". There are different ways to define this application. + +\subsection MEDCouplingArrayRenumberingO2N Old to new mode + +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 + +If \b MySujection equals [2,1,0,1,2], it means that : + +- old id #0 will have new id equal to 2 +- old id #1 will have new id equal to 1 +- old id #2 will have new id equal to 0 +- old id #3 will have new id equal to 1 like old id #1 +- old id #4 will have new id equal to 2 like old id #0 + +This is the most common mode of renumbering in MEDCoupling because there is more methods implying renumbering that reduce the number of entities than method that increase number of entities. + +Method in old to new mode that works on bijective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumber "DataArrayDouble::renumber" +- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlace" + +Method in old to new mode that works on surjective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumberAndReduce "DataArrayDouble::renumberAndReduce" + +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 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. +Let's consider a call to \ref ParaMEDMEM::MEDCouplingUMesh::simplexize "simplexize" that increases the number of cell from 4 cells to 6 cells.\n +In new to old mode the array \b MyInjection that specifies this injection will have 6 tuples and 1 component. The content of the 5*1 values will be in {0,1,2,3}.\n +If \b MyInjection equals [2,0,1,1,3,0] it means that : + +- new id #0 comes from old id 2 +- new id #1 comes from old id 0 +- new id #2 comes from old id 1 +- new id #3 comes from old id 1 +- new id #4 comes from old id 3 +- new id #5 comes from old id 0 + +Method in new to old mode that works on bijective applications : + +- \ref ParaMEDMEM::DataArrayDouble::renumberR "DataArrayDouble::renumberR" +- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlaceR" + +Method in new to old mode that works on surjective applications : + +- \ref ParaMEDMEM::DataArrayDouble::selectByTupleId "DataArrayDouble::selectByTupleId" +- \ref ParaMEDMEM::DataArrayDouble::selectByTupleIdSafe "DataArrayDouble::selectByTupleIdSafe" +- \ref ParaMEDMEM::DataArrayDouble::selectByTupleId2 "DataArrayDouble::selectByTupleId2" +- \ref ParaMEDMEM::DataArrayDouble::selectByTupleRanges "DataArrayDouble::selectByTupleRanges" + +\section MEDCouplingArrayApplyFunc Application of a function on DataArrayDouble instances. + +This section is only dedicated for \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instances". + +It is possible to apply to \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" a function given by a string. + +There are different API for applyFunc* methods of \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble class". + +\subsection MEDCouplingArrayApplyFuncExpr Expressions supported + +In order to reduce as much as possible dependencies, a little dynamic formula interpreter 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), +- >,< +- if + +The expression evaluator is also sensitive to the following var pattern : IVec, JVec, KVec, LVec,... ,ZVec + +- IVec stands for unitary vector [1,0,0,0,...] +- JVec stands for unitary vector [0,1,0,0,...] +- KVec stands for unitary vector [0,0,1,0,...] +- ... + +The dynamic expression evaluator works tuple by tuple through the *raw data* of DataArrayDouble instance. + +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. +\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. + +- The given the preprocessed tree given an input tuple a preallocated tuple is fed with the result of the evaluation. + At this last phase only mathematical errors are thrown (division by 0, log(0), sqrt of a negative number ...) + +\subsection MEDCouplingArrayApplyFunc0 applyFunc method with only one parameter + +This method produces a newly allocated DataArrayDouble instance having exactly the same number of components **and** number of tuples than the instance on which the +\ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method is applied. + +**This method is useful when the evaluation expression do not need to consider the components of each tuple separately**. + +That's why this method of \ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method with one parameter accepts at most only one variable. + +If it is not the case an exception is thrown as seen here : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_1 + +Let's take a very simple example on a DataArrayDouble instance \c d having 4 tuples and 2 components. + +In the next example the expression contains only one variable : \c smth. +So \c smth represent a tuple of size 2. + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_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 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. + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_3 + +In this example using IVec and JVec it is possible to differentiate output in component #0 and output in component #1 for DataArrayDouble instance \c d2. + +\subsection MEDCouplingArrayApplyFunc1 applyFunc method with only two parameters + +This method also returns a newly allocated DataArrayDouble instance having the same number of tuples than the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called, but the contrary to previous \ref MEDCouplingArrayApplyFunc0 "applyFunc with one parameter version" here the number of components is set by the user. + +The big difference with \ref MEDCouplingArrayApplyFunc0 "applyFunc method with one parameter" seen above is that here components of tuples are treated separately. + +The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const here. + +Here the number of variables appearing in the expression should be equal at most to the number of component of the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called. + +Let's consider the following DataArrayDouble having 4 tuples with 3 components called dd. + +\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 and the square root of the second component and the third component +the invocation should be something like this : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_5 + +\warning In the expression \c "f+sqrt(g)+h", there are 3 variables \c {"g","h","f"}. As seen \ref MEDCouplingArrayApplyFuncExprA1 "in link phase in expression evaluator" it is needed to match a variable to +the component id. The strategy of expression evaluator is the following. Sort ascendingly variables using their names and affect component id following this sorted list. It leads to : +- \c f will be attached to component #0 of \c dd +- \c g will be attached to component #1 of \c dd +- \c h will be attached to component #2 of \c dd + +Considering the previous warning, let's try to perform an application of function to compute in a DataArrayDouble instance called \c dd2 starting by adding component #0 and component #2 +of \c dd. +\nThe expression \c "a+c" will add component #0 to component #1 as seen in warning section !!!! It can appear silly, but this strategy has been chosen in order to support different set of variables. +\n \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. +\n Here is a solution to compute \c dd2 : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_6 + +\subsection MEDCouplingArrayApplyFunc2 applyFunc2 method + +The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc2 here. + +This method is very close to \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters". + +The only difference is the mapping between variables found in expression and tuple id. Rather than using rank in string sorting as \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters uses" here the component information are considered. + +Let's consider DataArrayDouble instance \c ddd constituted with 4 tuples containing each 3 components. The components are named respectively \c {"Y","AA","GG"} with following different units attached on them. + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_7 + +To compute the sum of the first component (component #0) and the third component (component #2) simply do that : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_8 + +\subsection MEDCouplingArrayApplyFunc3 applyFunc3 method + +The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc3 here. + +This method is very close to \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters" and \ref MEDCouplingArrayApplyFunc2 "applyFunc2". + +The only difference is the mapping between variables found in expression and tuple id. Rather than using rank in string sorting as in \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters uses" or the component information as in \ref MEDCouplingArrayApplyFunc2 "applyFunc2", here an explicit vector is given in input. + +Let's consider DataArrayDouble instance \c ddd constituted with 4 tuples containing each 3 components. To add first component (component #0) and the third component (component #2) simply do that : + +\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_9 + +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingCMesh.dox b/doc/doxygen/input/medcoupling/MEDCouplingCMesh.dox new file mode 100644 index 000000000..8d3263401 --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingCMesh.dox @@ -0,0 +1,23 @@ + +/*! + \page MEDCouplingCMeshPage Cartesian meshes in MEDCoupling + +A cartesian mesh is a mesh that represents structured mesh whose nodes are arranged along axes of trihedron. + +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 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 example of a 2D cartesian mesh. + +\subpage medcouplingcppexamplesCmeshStdBuild1 "Here the C++ implementation." + +\subpage medcouplingpyexamplesCmeshStdBuild1 "Here the Python implementation." + +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingExtruded.dox b/doc/doxygen/input/medcoupling/MEDCouplingExtruded.dox new file mode 100644 index 000000000..95a4783ed --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingExtruded.dox @@ -0,0 +1,17 @@ + +/*! + \page MEDCouplingExtrudedPage 3D Extruded meshes in MEDCoupling + +An extruded mesh is a mesh also called 2.5 D. + +It is a convolution of a 2D unstructured mesh with a 1D unstructured mesh. + +The problem is that this type of mesh is not managed by any file format that's why to build an instance of this mesh you need a 3D unstructured mesh and a 2D +unstructured mesh lying on the same coordinates. + +The advantage of this structure is that the interpolation time is highly improved. + +This class is also useful for users that want to map the 3D unstructured mesh cell ids level by level along an axis. + +The class that incarnates this concept in MEDCoupling is : \ref ParaMEDMEM::MEDCouplingExtrudedMesh. +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingFieldTemplates.dox b/doc/doxygen/input/medcoupling/MEDCouplingFieldTemplates.dox new file mode 100644 index 000000000..5be4dec00 --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingFieldTemplates.dox @@ -0,0 +1,16 @@ + +/*! + \page MEDCouplingFieldTemplatesPage Field templates in MEDCoupling + +This concept appears in ICOCO API. +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 : + +- a \ref MEDCouplingMeshesPage "mesh" +- a spatial discretization (on cells, on nodes, on Gauss points (including localizations, reference elements), ) + +*/ + + LocalWords: discretization diff --git a/doc/doxygen/input/medcoupling/MEDCouplingFields.dox b/doc/doxygen/input/medcoupling/MEDCouplingFields.dox new file mode 100644 index 000000000..44c966cd2 --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingFields.dox @@ -0,0 +1,119 @@ + +/*! +\page MEDCouplingFieldsPage Fields in MEDCoupling + +[TOC] + +\section MEDCouplingFields Field concept + +A field in MEDCoupling point of view, is a structure that allows to +store a discretization of a physical value on a defined discretized spatial and +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 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. + +Fields in MEDCoupling follow the two following rules : + +- A field will lie on \b ALL entities of its spatial support (\ref MEDCouplingMeshesPage "mesh"). +- A field has \b only \b one spatial support (\ref MEDCouplingMeshesPage "mesh") on its temporal support. + +The main properties of a field are : + +- name +- spatial support which is a \ref MEDCouplingMeshesPage "mesh" +- a \ref MEDCouplingSpatialDisc "spatial discretization" +- a description of intrinsic nature of the values of field (see \ref NatureOfField). This is important for conservative interpolation (see \ref TableNatureOfField). +- a temporal discretization that specifies, if it exists, the time interval on which the field is covering, and how. +- number of components + +This definition of field in MEDCoupling allows an instance of field to +know at any point inside its spatial-temporal support the value. + +The class that incarnates the concept described above is : \ref ParaMEDMEM::MEDCouplingFieldDouble. + +Some of most important implemented methods are : + +- \ref ParaMEDMEM::MEDCouplingFieldDouble::getNumberOfComponents "getNumberOfComponents" +- \ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn" +- \ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc "applyFunc" +- \ref ParaMEDMEM::MEDCouplingFieldDouble::addFields "cross instances operations" +\section MEDCouplingSpatialDisc Spatial discretization concept + +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"). + +The abstract class that incarnates the concept is : \ref ParaMEDMEM::MEDCouplingFieldDiscretization. + +The most important pure virtual methods are : + +- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getNumberOfTuples "getnumberOfTuples" +- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getValueOn "getValueOn" +- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getMeasureField "getMeasureField" + +\section MEDCouplingTemporalDisc Temporal discretization concept + +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). + +The abstract class \ref ParaMEDMEM::MEDCouplingTimeDiscretization +incarnates this described concept. + +This classes and its subclasses are responsible in storing the arrays +of the aggregating field. + +The most important methods are : + +- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::setTime "setTime" and \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getTime "getTime" +- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getArray "getArray" and \ref ParaMEDMEM::MEDCouplingTimeDiscretization::setArray "setArray" +- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getArraysForTime "getArraysForTime" +- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getValueForTime "getValueForTime" + +\section MEDCouplingFirstSteps3 Building a field from scratch + +Here we will make the assumption that an instance of \c MEDCouplingMesh called \c mesh has been created ( to know more about mesh creation \ref MEDCouplingUMeshStdBuild "click here" ). + +\subsection MEDCouplingFirstSteps3OnCellsNoTS Create a tensor field with 9 components on cells with no time step + +\subpage medcouplingcppexamplesFieldDoubleBuild1 "Here the C++ implementation." + +\subpage medcouplingpyexamplesFieldDoubleBuild1 "Here the Python implementation." + +\subsection MEDCouplingFirstSteps3OnNodesNoTS Create a scalar field on nodes with no time step + +\subpage medcouplingcppexamplesFieldDoubleBuild2 "Here the C++ implementation." + +\subpage medcouplingpyexamplesFieldDoubleBuild2 "Here the Python implementation." + +\subsection MEDCouplingFirstSteps3OnCellsWTS Create a 2 components-vector field on cells with one time step and no interval + +\subpage medcouplingcppexamplesFieldDoubleBuild3 "Here the C++ implementation." + +\subpage medcouplingpyexamplesFieldDoubleBuild3 "Here the Python implementation." + +\subsection MEDCouplingFirstSteps3OnCellsCTI Create a 3 components-vector field on nodes with a time interval where field remains constant on this time interval + +\subpage medcouplingcppexamplesFieldDoubleBuild4 "Here the C++ implementation." + +\subpage medcouplingpyexamplesFieldDoubleBuild4 "Here the Python implementation." + +\section MEDCouplingSecondStep0 Operations on Fields + +Here we will make the assumption that an instance of \ref ParaMEDMEM::MEDCouplingMesh "MEDCouplingMesh" +called \c mesh has been created with spaceDim==2. + +\subpage medcouplingcppexamplesFieldDoubleBuild5 "Here a C++ example of more advanced use of MEDCouplingFieldDouble instances". + +\subpage medcouplingpyexamplesFieldDoubleBuild5 "Here a Python example of more advanced use of MEDCouplingFieldDouble instances". + +*/ + + LocalWords: discretization diff --git a/doc/doxygen/input/medcoupling/MEDCouplingMeshes.dox b/doc/doxygen/input/medcoupling/MEDCouplingMeshes.dox new file mode 100644 index 000000000..246af144d --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingMeshes.dox @@ -0,0 +1,35 @@ + +/*! + \page MEDCouplingMeshesPage Meshes in MEDCoupling + +\section MEDCouplingMeshes Common concept shared by all type of Meshes in MEDCoupling + +A mesh has the following properties : + +- name +- **a dimension (called mesh dimension) and only one** (it implies that \b all cells constituting +mesh have the same dimension) +- a space dimension (relative to coordinates) +- a number of nodes +- a number of cells + +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 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 instantiable mesh types in MEDCoupling + +- \subpage MEDCouplingUMeshPage "Unstructured meshes" +- \subpage MEDCouplingCMeshPage "Cartesian meshes" +- \subpage MEDCouplingExtrudedPage "3D Extruded meshes" + +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingPointSet.dox b/doc/doxygen/input/medcoupling/MEDCouplingPointSet.dox new file mode 100644 index 000000000..be05453dd --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingPointSet.dox @@ -0,0 +1,21 @@ + +/*! + \page MEDCouplingPointSetPage Point set meshes in MEDCoupling + +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. +Instantiable class ParaMEDMEM::MEDCouplingUMesh inherits from ParaMEDMEM::MEDCouplingPointSet. + +Some of most important implemented methods by \ref ParaMEDMEM::MEDCouplingPointSet "MEDCouplingPointSet" class are : + +- \ref ParaMEDMEM::MEDCouplingPointSet::getSpaceDimension "getSpaceDimension" +- \ref ParaMEDMEM::MEDCouplingPointSet::getNumberOfNodes "getNumberOfNodes" +- \ref ParaMEDMEM::MEDCouplingPointSet::rotate "rotate" +- \ref ParaMEDMEM::MEDCouplingPointSet::translate "translate" +- \ref ParaMEDMEM::MEDCouplingPointSet::scale "scale" +- \ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes "findCommonNodes" +- \ref ParaMEDMEM::MEDCouplingPointSet::renumberNodes "renumberNodes" +- \ref ParaMEDMEM::MEDCouplingPointSet::getBoundingBox "getBoundingBox" +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingTimeLabel.dox b/doc/doxygen/input/medcoupling/MEDCouplingTimeLabel.dox new file mode 100644 index 000000000..7d5b925c4 --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingTimeLabel.dox @@ -0,0 +1,25 @@ + +/*! + \page MEDCouplingTimeLabelPage Time label in MEDCoupling + +Time label is a **non instantiable** class whose each object consuming potentially big amount of memory inherit from. +The class that incarnates this concept is ParaMEDMEM::TimeLabel. + +Here are some of examples of classes that inherit from \ref ParaMEDMEM::TimeLabel "TimeLabel" class : + +- ParaMEDMEM::DataArrayInt, ParaMEDMEM::DataArrayDouble +- ParaMEDMEM::MEDCouplingMesh +- ParaMEDMEM::MEDCouplingFieldDouble +- ... + +This class is in charge of storing a 32 bits unsigned integer called time label, that allows the user to know easily, if an heavy object in memory has been modified or not. + +The usage is simple : + +- Call ParaMEDMEM::TimeLabel::getTimeOfThis a first time to retrieve a reference. Store the returned unsigned integer. +- When you need to know if the instance inheriting from ParaMEDMEM::TimeLabel has changed or not simply invoke ParaMEDMEM::TimeLabel::getTimeOfThis again and compare with the stored value. + If the value is different, the instance has changed, if not the instance has **not** changed. + +The virtual call to ParaMEDMEM::TimeLabel::updateTime changes the behaviour of ParaMEDMEM::TimeLabel::getTimeOfThis ; it is a bug, so please notify the bug into the salome forum. + +*/ diff --git a/doc/doxygen/input/medcoupling/MEDCouplingUMesh.dox b/doc/doxygen/input/medcoupling/MEDCouplingUMesh.dox new file mode 100644 index 000000000..11596a348 --- /dev/null +++ b/doc/doxygen/input/medcoupling/MEDCouplingUMesh.dox @@ -0,0 +1,67 @@ + +/*! + \page MEDCouplingUMeshPage Unstructured meshes in MEDCoupling + +[TOC] + +An unstructured mesh in \ref medcoupling MEDCoupling is defined by : + + - a point cloud 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 cloud that constitutes the cell. + +As unstructured mesh is dynamically defined enough, this class is also used by MEDCoupling to instantiate degenerated meshes as : + +- point cloud only meshes. This type of mesh will have mesh dimension 0. +- abstract meshes containing only one cell that covers a potentially + infinite space. This abstract mesh is used as support of fields + containing only one integrated value. This is typically used to + represent fields used by system code. This type of mesh will have + mesh dimension equal to -1. + +The norm used for cells connectivity of different types, is the same as specified in MED file except +that connectivities are represented in \b C \b format and \b not \b in \b FORTRAN \b format ! + +The class that incarnates the described concept is : ParaMEDMEM::MEDCouplingUMesh. +\n This class inherits from ParaMEDMEM::MEDCouplingPointSet abstract class. +\n So \ref MEDCouplingUMeshPage "MEDCouplingUMesh" inherits from all \ref MEDCouplingPointSetPage "point set features". + +\section MEDCouplingUMeshStdBuild Standard building of an unstructured mesh from scratch + +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 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. + +You can notice that it is possible to mix cell types as long as the dimension of cell is exactly equal to meshDim to respect \ref MEDCouplingMeshes "this rule". + +\subpage medcouplingcppexamplesUmeshStdBuild1 "Here is the C++ implementation." + +\subpage medcouplingpyexamplesUmeshStdBuild1 "Here is the Python implementation." + +\section MEDCouplingUMeshNodalConnectivity How MEDCouplingUMesh stores its nodal connectivity + +\ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh class" stores its nodal connectivity into 2 arrays. + +- The first one, the biggest is ParaMEDMEM::MEDCouplingUMesh::_nodal_connectivity. +- The second one, the less big is ParaMEDMEM::MEDCouplingUMesh::_nodal_connectivity_index. + +\image html MEDCouplingUMeshConn.png "Nodal connectivity storage into MEDCouplingUMesh class" +\image latex MEDCouplingUMeshConn.eps "Nodal connectivity storage into MEDCouplingUMesh class" + +\note The last value of the nodal connectivity index points to an invalid memory place. It is not an error, simply as for standard C++, all ranges +are given in format [\b begin,\b end) where \b begin is included and \b end excluded. + +\section MEDCouplingUMeshAdvBuild Advanced building of an unstructured mesh from scratch + +Here we are going to build the mesh in a more advanced manner. This method expects that the user knows the storage format underlying ParaMEDMEM::MEDCouplingUMesh. + +The same mesh than \ref MEDCouplingUMeshStdBuild "in the standard section above" is going to be implemented using advanced method. + +\subpage medcouplingcppexamplesUmeshAdvBuild1 "Here the C++ implementation." + +\subpage medcouplingpyexamplesUmeshAdvBuild1 "Here the Python implementation." + +*/ diff --git a/doc/doxygen/input/medcoupling/NatureOfField.dox b/doc/doxygen/input/medcoupling/NatureOfField.dox new file mode 100644 index 000000000..6dc178cd6 --- /dev/null +++ b/doc/doxygen/input/medcoupling/NatureOfField.dox @@ -0,0 +1,60 @@ + +/*! + \defgroup NatureOfField Nature of a field + + \section IntExtFields Overview: intensive and extensive field + +\c NatureOfField is an enum which helps in determining some physical significance of the field and affects the choice of the interpolation formula (see \ref TableNatureOfField). +It has five possible values: +- "NoNature", the default value, does not allow the use of any interpolation tools + +For intensive 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. + +For extensive fields: +- \ref TableNatureOfFieldExampleIntegral "Integral", for extensive field with the maximum principle favored over conservativity. Relevant for power fields. + +- \ref TableNatureOfFieldExampleIntegralGlobConstraint "IntegralGlobConstraint", for extensive fields with conservativity favored over the maximum principle. Relevant for power fields. + +\n + +By intensive field we mean a field that represents an intensive physical variable such as density (\f$kg.m^{-3}\f$), power density (\f$W.m^{-3}\f$), temperature (\f$K\f$) or pressure (\f$Pa\f$). Typically the physical value doesn't scale with the size of the underlying geometry.
+By extensive (or integral) field we mean a field that represents an extensive physical quantity such as mass (\f$kg\f$), volume (\f$m^3\f$), a momentum (\f$kg.m.s^{-1}\f$) or power \f$(W\f$). +Typically the field value scales linearly with respect to the underlying geometry size. +For fields with a P0 representation (cell based), conservativity formulas are different depending on whether the field is extensive or intensive (see \ref InterpKerP0P0Int and \ref InterpKerP0P0Ext).
+These two notions are themselves split into two sub-categories. +Indeed in some cases (e.g. non \ref MeshOverlap "overlapping meshes"), it is impossible to fulfill both the conservation principle and the maximum principle during the interpolation. The nature of the fields determines the formula to be used for non overlapping cells and thus the property that we will be satisfied. +Finally we consider that fields with P1 or P2 representations are necessarily intensive. + +\section Usage + +In order to use 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 +MEDCouplingFieldDouble(NatureOfField n, MEDCouplingTimeDiscretization *td, MEDCouplingFieldDiscretization *type); +\endcode + +If you read or copy an already existing field, or later after its creation, you may want to change/set its nature. +In order to do so, you can use the function + +\code +void setNature(NatureOfField nat); +\endcode + +Here is an example + +\code +... +const char sourceFileName[]="source.med"; +MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); +const char targetFileName[]="target.med"; +MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); +// +sourceField->setNature(ConservativeVolumic); +... +\endcode + +*/ diff --git a/doc/doxygen/input/medloader.dox b/doc/doxygen/input/medloader.dox new file mode 100644 index 000000000..90da44d01 --- /dev/null +++ b/doc/doxygen/input/medloader.dox @@ -0,0 +1,184 @@ +/*! +\page medloader MEDLoader + +[TOC] + +\section MEDLoaderIntro Introduction + +\ref medloader "MEDLoader" is a package in charge of loading from a file or write to a file +in MED format a \ref medcoupling data structure. The fact that these +functionalities are not merged in \ref medcoupling is explained by a +willingness of reducing as much as possible the dependencies of \ref medcoupling libraries. + +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 MEDCouplingMeshesPage "MEDCoupling mesh" is \b not as rich as a MED file mesh, and a \ref MEDCouplingFieldsPage "MEDCoupling field" is \b not as rich as a MED file field. +But it is possible to emulate with a very good fidelity a MED file mesh and a MED file field with a collection of MEDCoupling instances for each. + +\section MEDLoader2Approaches Two approaches are available in MEDLoader : Advanced API, Basic API + +\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 approach" + +Whatever the approach(es) you choose, it is advisable to know main concepts of MED files \ref MEDLoaderMainC "that are quickly reminded here." + +\subsection MEDLoaderAdvApproach Advanced API approach + +\subpage MEDLoaderAdvancedAPIPage "A specific page dedicated to the advanced API is available here". + +This approach is the most close to MED file. By using this advanced API approach the user will manipulate classes that represent MED file concepts. + +It implies that the user should be informed about the \ref MEDLoaderMainC "MED file concepts", that do not exist in \ref medcoupling "MEDCoupling". For example : + +- group/family in meshes +- profiles in fields + +This is typically the case for a user that wants to precisely set/get mesh/group/family groups set on different level. + +*This is why a set of classes corresponding to memory representation of MED file concepts is proposed by advanced API approach.* + +*So All information contained in file is represented by advanced API class instances.* + +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 particularly recommended : + +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 + +\subpage MEDLoaderBasicAPIPage "A specific page dedicated to the basic API is available here". + +This approach is less close to MED file concepts, but closer to \ref MEDCouplingMainConc "MEDCoupling concepts". + +So, basic API is simpler, as shown by method MEDLoader::WriteUMesh that needs no special knowledge about MED file concepts to interact with MED files. + +This API is in the form of a list of public static methods in a class ParaMEDMEM::MEDLoader. + +This simplicity has a cost, the I/O are not (cannot be) optimized. + +As MED file concepts are more complex than MEDCoupling concepts, this approach is not the most relevant for specific MED file objects read/write. + +- Manipulation of multi level MED file mesh is not easy with basic approach + +- Manipulation of partial fields is not easy with basic approach + + +\subsection MEDLoaderCohabitationApproach Cohabitation of the two approaches + +The two approaches are \b NOT opposed, they are compatible each other so it is possible to mix them. + +Typically it is possible to read rich information of a complex MED file using advanced API in read mode, postprocess this input then get a simpler MED file model, and write it to a simple output MED file using basic API. + +\section MEDLoaderMainC Main concepts of MED files + +Here we will describe some of the basic concepts of MED files in order to +use the best methods proposed by \ref medloader "MEDLoader API". + +\subsection BasicMEDLoaderAPIGen Basics in 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 : + +\image html MEDFileConcepts.png "Resumed MED file concepts" + +Inside the parenthesis, there is multiplicity : + +- + stands for [1,inf) +- * stands for [0,inf) +- ? stands for 0 or 1 + +Each box is **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. + +There can be as many instance of boxes as wanted in a MED file. + +**As it can be seen in MED file world, fields and meshes are sorted by geometric type**. + +This specificity leads to a constraint during writing phase because some mesh operations may significantly modify the organization of geometric types during mesh/field operations. +\n Here are some of operations that can alter the geometric type order of cells: + +- aggregation of meshes +- aggregation of fields +- extraction of a part of meshes +- extraction of a part of fields +- partial polyhedrization of meshes +- unpolyhedronization of meshes + +\section MEDLoaderCommonVoc Vocabulary used in MEDLoader + +\subsection MEDLoaderCommonVocRelMeshDimMesh Relative mesh dimension in meshes + +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. + +To connect the MED file world to the MEDLoader/MEDCoupling world the notion of **relative mesh dimension** has been introduced in \ref medloader "MEDLoader". + +This concept of **relative mesh dimension** is used frequently in the \ref medloader "MEDLoader APIs" (\ref MEDLoaderBasicAPIPage "basic" and \ref MEDLoaderAdvancedAPIPage "advanced"). + +To explain the semantic of **relative mesh dimension** let's take the example of a mesh called \a myMesh in a MED file, containing MED_TRI3, MED_POINT1, MED_POLYHED, MED_TETRA4. + +For each geometric type on which \a myMesh is defined the mesh dimensions are : + +- MED_TRI3 -> mesh dimension=2 +- MED_POINT1 -> mesh dimension=0 +- MED_POLYHED -> mesh dimension=3 +- MED_TETRA4 -> mesh dimension=3 + +The mesh dimension of \a myMesh is equal to 3 ( \f max(2,0,3,3) ). The **relative mesh dimension** is equal to the difference between mesh dimension of geometric type and the mesh dimension +of the whole MED file dimension. It leads to the following **relative mesh dimension** : + +- MED_TRI3 -> **relative mesh dimension** = -1 +- MED_POINT1 -> **relative mesh dimension** = -3 +- 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 +MED file data structure of \a myMesh : + +- Level 0 + - MED_TETRA4 + - MED_POLYHED +- Level -1 + - MED_TRI3 +- Level -2 + - nothing -> level **not** available for \a myMesh +- Level -3 + - MED_POINT1 + +The mesh dimension of \a myMesh is 3. The relative mesh dimensions available are 0, -1 and -3. + +\subsection MEDLoaderCommonVocRelMeshDimField Relative mesh dimension in fields + +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. + +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. + +\subsection MEDLoaderCommonVocIterationOrder Iteration and order in MED file + +As seen \ref BasicMEDLoaderAPIGen "above", fields in MED file can be defined on different time steps. + +But there is a **major difference** with \ref medcoupling "MEDCoupling" concept in time steps. \ref medcoupling "MEDCoupling" focuses on the float value of time for interpolation reason. + +\ref medloader MEDLoader and MED file focus on pair of integers to precise a specific time steps. + +This difference of point of view can be seen in the API where the order of returned parameters in python differs from MEDCouplingFieldDouble::getTime to MEDFileField1TS::getTime. + +In MED file and so in \ref medloader "MEDLoader" the time steps are identified by a pair of integers called : + +- iteration +- order + +Order refers to sub iteration id, that is by default set to -1 in case of non use. A physical time with float type is attached to this pair of integer. + +*/ diff --git a/doc/doxygen/input/medloader/MEDLoaderAdvancedAPI.dox b/doc/doxygen/input/medloader/MEDLoaderAdvancedAPI.dox new file mode 100644 index 000000000..d47408e44 --- /dev/null +++ b/doc/doxygen/input/medloader/MEDLoaderAdvancedAPI.dox @@ -0,0 +1,248 @@ + +/*! +\page MEDLoaderAdvancedAPIPage Advanced MEDLoader API. + +[TOC] + +This method is much closer to MED file organization than \ref +MEDLoaderBasicAPI "basic MEDLoader API". All MED file +concepts are exposed to the user. As a consequence, this advanced +API is lead to change with MED file data model enhancement. + +In reading mode, the user can scan entirely and directly the contents of its MED file as it is organized in its MED file. +Inversely, in writing mode, the user can describe its data in the same +way that MED file does. + +\section AdvMEDLoaderBasics Some of basics of advanced API + +- Like basic %MEDLoader API there is a notion of \c meshDimRelToMax. +Each time this parameter appears in API, it will have the semantic +explained here. +The value of the parameter \c meshDimRelToMax is at most in {0,-1,-2,-3}. This relative value specifies a level +relative to the value returned by ParaMEDMEM::MEDFileMesh::getMeshDimension(). + +A mesh containing MED_TETRA4, MED_TRI3, MED_QUAD4 and MED_POINT1 has a meshDimension +equal to 3. For \c meshDimRelToMax equal to 0 the user will +deal with cells whose type has a dimension equal to 3+0, that is to +say here MED_TETRA4. For \c meshDimRelToMax equal to -1 the user will +deal with cells which dimension equals 3-1 that is to say MED_TRI3 +and MED_QUAD4. + +An important method is ParaMEDMEM::MEDFileUMesh::getNonEmptyLevels(). It returns all +non empty levels available. In the previous example, this method will +return {0,-1,-3}. -2 does not appear because no cells with dimension +equal to 1 (3-2) appear in MED file mesh (no MED_SEG2, no MED_SEG3). + +- Besides notion of \c meshDimRelToMax there is notion of \c meshDimRelToMaxExt. +\c meshDimRelToMaxExt is simply an extension of \c meshDimRelToMax for +nodes. + +The parameter of \c meshDimRelToMaxExt appears in +\ref ParaMEDMEM::MEDFileUMesh "umesh advanced API" of %MEDLoader with the following semantics. + +Some of MED file concepts are available both for cells and +nodes (for example families, groups, numbering) ; that's why for a simpler API this +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 +before. + +- A parameter that also often appears in advanced %MEDLoader API is \c renum. +This parameter is set to \c +true by default. +This parameter indicates if the user intends to take into account +the renumbering array of cells of the current MED file mesh. +If no renumbering array is defined, this parameter is ignored by +%MEDLoader. + +If such renumbering exists and the \c renum parameter is +set to \c true, then the renumbering is taken into account. This is +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 caution \b for \b users \b concerned \b by \b cells \b orders. + +- 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 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 + current instance already exists, the content is not written and an + exception is thrown. + - 0 : If the file does not exists equivalent to 2. If file already + exists write without any question. If an element with same ids + existed previously the content is overwritten by the content of the + current instance, that can lead to a file corruption. + +\section AdvMEDLoaderAPIMeshesRW Dealing with Meshes with advanced API. + +Contrary to the basic %MEDLoader API, here after reading process, the user +has to deal with a new instance of class that fits the MED file model. +To access a MEDCoupling mesh user should request this class +instance. + +\subsection AdvMEDLoaderAPIMeshReading Reading a mesh. + +The class that incarnates Read/Write mesh in MED file is ParaMEDMEM::MEDFileUMesh. + +First of all, like basic %MEDLoader API, only MEDfile files whose version >= 2.2 are able +to be read with advanced API. + +To read a mesh having the name \c meshName in file \c fileName the +following simple code has to be written : + +\code + +MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName,meshName); + +\endcode + +If the user do not know the name of the mesh inside MED file +'fileName' the following code should be written : + +\code + +MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName); + +\endcode + +In this case the first mesh (in MED file sense) found in \c fileName +file will be loaded. + +Now the user can ask for mesh dimension of of \c myMedMesh instance by +calling \c myMedMesh->getMeshDimension(). This method returns the +highest level of present cell in MED file mesh \c myMedMesh. +This returned integer is computed and \b not those contained in MED file +that can be invalid. + +\n + +- Retrieving a mesh at a specified relative level \c meshDimRelToMax=mdrm : simply call + - \c myMedMesh->getMeshAtLevel(mdrm) + - or \c myMedMesh->getLevel0Mesh() or \c + myMedMesh->getLevelM1Mesh(), or \c myMedMesh->getLevelM2Mesh() + depending on the value of mdrm + + +- Retrieving a family at a specified level : + - Either an array of node/cell id + - \c getFamilyArr method or \c getFamiliesArr + - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling + - \c getFamily method or \c getFamilies + +- Retrieving a group at a specified level : + - Either an array of node/cell id + - \c getGroupArr method or \c getGroupsArr + - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling + - \c getGroup method or \c getGroups + +- Retrieving family field array : +Method \c getFamilyFieldAtLevel retrieves for a specified extended level the +family id of each cell or node. + +- Retrieving renumbering array : +Method \c getNumberFieldAtLevel returns, if it exists for a specified extended level, the +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 explicitly for Groups and +Families. Advanced %MEDLoader API, uses the same order than underlying +mesh at specified level. + +\anchor AdvMEDLoaderAPIMeshReadingSampl + +Here is a \ref cpp_mcumesh_loadfile "C++ example" illustrating a typical use of \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" instance. + +\subsection AdvMEDLoaderAPIMeshWriting Writing a mesh. + +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. + +One important point is that coordinates of a mesh are shared by all +cells whatever their level. That's why the +\ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" instance +should be shared by all \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" used in input parameter of +set* methods. If the user intends to build a \ref ParaMEDMEM::MEDFileUMesh "MEDFileUMesh" instance from +scratch, a call to \c setCoords should be done first. + + +Generally speaking traduce get* methods with set* methods have corresponding write semantic. + +Some differences still exist : + +- \c setMeshAtLevel, \c setMeshAtLevelOld simply call \c setMeshAtLevelGen with repectively \c newOrOld parameter +set to true and false. These methods specify if a renumbering computation is needed or not. \c setMeshAtLevelOld is faster +than \c setMeshAtLevel because no renumbering computation is done. If the user is not warranty about the order of its meshes to enter +it is better to use \c setMeshAtLevel method. + +- Groups definition : Groups constitution is time consuming because of the store mode chosen by MED file. Groups definition +leads to a partition computation which is time/memory consuming ; that is why groups should be defined at once and not with addGroup one by one that will lead to +compute a partition for each appended group. One important point to note is that DataArrayInt instance given in input to define groups should have its name +set to the desired group name. If not an exception will be thrown, because MED file does not support groups with no name. + +\anchor AdvMEDLoaderAPIMeshWritingSampl + +Here is a \ref cpp_mcumesh_writefile "C++ example". + + +\section AdvMEDLoaderAPIFieldRW Dealing with Fields with advanced API. + +In advanced API fields have been developed using divide and conquer pattern to reproduce with the maximal fidelity the MED file field concept \ref BasicMEDLoaderAPIGen "seen here". + +Here the list of classes in %MEDLoader advanced API top down sorted : + +- Level 0 : ParaMEDMEM::MEDFileFields +- Level -1 : ParaMEDMEM::MEDFileFieldMultiTSWithoutSDA +- Level -2 : ParaMEDMEM::MEDFileField1TSWithoutSDA +- Level -3 : ParaMEDMEM::MEDFileFieldPerMesh (present only for backward compatibility MED file 2.2) +- Level -4 : ParaMEDMEM::MEDFileFieldPerMeshPerType +- Level -5 : ParaMEDMEM::MEDFileFieldPerMeshPerTypePerDisc + + +Each level in the tree representing a field (cyan box) 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 leaf (level -5) of MED file field +points to range [\a start, \a end). + +As different time steps of a same field and different fields inside a MED file can share or not profiles (yellow box) and localization (red box) a manipulable field classes instance +(ParaMEDMEM::MEDFileField1TS and ParaMEDMEM::MEDFileFieldMultiTS) in advanced API is the result of a subclass of a data class +(respectively ParaMEDMEM::MEDFileField1TSWithoutSDA, ParaMEDMEM::MEDFileFieldMultiTSWithoutSDA) and an instance of ParaMEDMEM::MEDFileFieldGlobsReal representing the shared data arrays (SDA) +at a specified scope inside the MED file. + +\subsection AdvMEDLoaderAPIFieldR Reading a field + +\subsubsection AdvMEDLoaderAPIFieldRC Reading a field defined on all entities + +Fields defined on all entities are the most used and common fields in MED file world. + +In this mode the user does **not** want to retrieve the entity ids of the constituting subsupport of the whole mesh because it has no sense. + +Here is a \ref py_mcfield_loadfile_allentities "Python example". + +\subsubsection AdvMEDLoaderAPIFieldRP Reading a partial field + +Here is a \ref py_mcfield_loadfile_partial "Python example". + + +\subsection AdvMEDLoaderAPIFieldW Writing a field + +\subsubsection AdvMEDLoaderAPIFieldWC Writing a field defined on all entities + +Fields defined on all entities are the most used and common fields in MED file world. + +In this mode the user do **not** want to retrieve the entity ids of the constituting subsupport of the whole mesh because it has no sense. + +Here is a \ref py_mcfield_writefile_allentities "Python example". + +\subsubsection AdvMEDLoaderAPIFieldWP Writing a partial field + +Here is a \ref py_mcfield_writefile_partial "Python example". + +*/ diff --git a/doc/doxygen/input/medloader/MEDLoaderBasicAPI.dox b/doc/doxygen/input/medloader/MEDLoaderBasicAPI.dox new file mode 100644 index 000000000..2d6f319b4 --- /dev/null +++ b/doc/doxygen/input/medloader/MEDLoaderBasicAPI.dox @@ -0,0 +1,231 @@ + +/*! +\page MEDLoaderBasicAPIPage Basic MEDLoader API. + +[TOC] + +The aim of this page is to present MEDLoader basic API. The goal of +this basic API is to perform a read or a write in one shot without any +internal state. That's why the basic API of MEDLoader offers \b only \b static methods whose names have the first +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 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 instances are stored into components and units into MED files. The +name of meshes and fields are used by MEDLoader as is into +MED file. From a field f with \ref ParaMEDMEM::MEDCouplingTimeDiscretization +"time discretization" set to ONE_TIME, calls to +\c f->getTime(time,iteration,order) are used by MEDLoader to store the field into MED file. All strings used by MEDLoader should fulfill the rules of MED file where string length +is 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 + +The MEDLoader::CheckFileForRead method will perform such a check before any attempt of read. +A field is also discriminated by its name. The methods MEDLoader::GetCellFieldNamesOnMesh and MEDLoader::GetNodeFieldNamesOnMesh are available to know all fields +respectively on cells and on nodes lying on a specified mesh. + + A field is defined by several time steps discriminated by a pair of ints +(iteration,order). It is \b not possible to store 2 time steps of a same +field having the same iteration and order +numbers. The floating point value attached to this couple of ids (iteration,order) is only present for information. +Static methods MEDLoader::GetCellFieldIterations and +MEDLoader::GetNodeFieldIterations return a vector of pairs (iteration, order). + +A field time step lies on one \b or \b more mesh(es) specified by its \b or \b their name(s). A field time step 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 explain 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. + +Let's recall basic principles that explains some of the aspect of MEDLoade API. +\anchor MEDLoaderMeshNameConstraint MED file can contain several meshes. These meshes are +discriminated by their names (two meshes could not have the same +name). In the same way a MED file can contain several fields. +So MEDLoader offers the MEDLoader::GetMeshNames method to +discover all the mesh names contained in your file. + +\section BasicMEDLoaderBasicAPIMesh Reading and writing meshes in MED files using basic API + +In MED file meshes could combine in one unstructured mesh cells that +have different dimension. For example it is possible to mix +MED_TETRA4, MED_TRIA6, MED_SEG2, MED_POINT1, MED_POLYGON, +MED_POLYHEDRA in a same mesh. In MEDCouplingUMesh such a mix is not +allowed as described \ref MEDCouplingMeshes "here". So to \b read such mesh it +is important to know which mesh dimension you are interested in. The parameter \b meshDimRelToMax of method MEDLoader::ReadUMeshFromFile corresponds to the mesh dimension you are +interested in, expressed relatively to the maximal dimension of cells contained +in the mesh in file. + +Let's take 2 examples : + +- If you have a mesh called "MyMesh" in file "file1.med" with +MED_POLYGON, MED_TRI3, MED_SEG2 and MED_SEG3 : The max dimension of +cells is 2 (for MED_POLYGON and MED_TRI3). So if you want exclusively +cells with type MED_POLYGON and MED_TRI3 you should use : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_9 + +If you are interested in MED_SEG2 and MED_SEG3 you should use : + +\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_10 + +The method MEDLoader::ReadUMeshDimFromFile could +help you to have this mesh dimension. + +Here is a \ref MEDLoaderExample2 "Python example".
+ +To finish this subsection, it is important to know that MEDLoader +takes into account the cell numbers stored in a mesh of a med +file. This renumbering allows MEDLoader to conserve the order of +MEDCoupling cells into the file. So if the renumbering of cells in MED +file is not correct an exception will be thrown. + +\subsection BasicMEDLoaderAPIPoMesh Part of meshes in MED files + +A mesh contains one or more families on nodes and/or on cells. A family is a partition +(mathematical sense) of the mesh it lies on. A family can be described +by an integer value on \b all nodes and on \b all cells of a same mesh. +All cells and nodes having the same id define this family. This id +is called the familyId. A family is discriminated by its id. MED file +attaches 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. + +A group is a set of families. So groups can overlap each other, +contrary to families. Groups are also discriminated by a name. As for +families the static method to retrieve the groups of a specified mesh is MEDLoader::GetMeshGroupsNames. + +MEDLoader allows you to retrieve the +corresponding "part of meshes" thanks to static methods +MEDLoader::ReadUMeshFromFamilies and MEDLoader::ReadUMeshFromGroups. +These methods allow you to combine several families and groups in the +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 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, that is why this +aspect does not appear in the MEDLoader API. + +Here is a \ref py_mcfield_loadfile_onetimestep_basic "Python example". + + +\subsection MEDLoaderMEDFieldsRead Reading several field time steps at a time in MED files + +It is possible with MEDLoader to read several time steps of a field at once. +The advantage with this approach is to avoid reading and loading the same mesh several +times. + +Here is a \ref py_mcfield_loadfile_alltimesteps_basic "Python example". + + +\section MEDLoaderWriteMain Writing a MED file with MEDLoader + +As MED file does, MEDLoader write process clearly separates +meshes from fields. The reason is that a common use case in write mode +is to write in a first time a mesh and then to write several time steps +of a same field in appended mode. + +The fact that the write process is rarely in a one shot puts a +constraint on API to precise to MEDLoader if you intend +to append data to an existing file, or if you want to create a new +file from scratch. This explains the presence of boolean parameter \b +writeFromScratch in API of MEDLoader starting with \b +MEDLoader::Write* . + +If \b writeFromScratch parameter is set to \b true and if the file +already exists the file will be crashed and replaced by the new +corresponding data. If \b writeFromScratch parameter is set to \b false and if the +file does \b not \b exist the new file is created, but if the file +exists MEDLoader will enter in appended mode. + +Two classes of MEDLoader write methods exist when \b writeFromScratch +is set to \b false : + +- Methods \b MEDLoader::Write*Dep : The write operation is performed without any question in file. The + 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 + by always trying to append data. The consequence is that a + read of part (and data processing) of MED file could be needed before any attempt of + writing. So these methods could be in some cases much time and memory consuming. + +The behaviour of MEDLoader when \b writeFromScratch is set to false will be precised +for each \b MEDLoader::Write* methods is the next subsections. + +\subsection MEDLoaderWriteMesh Writing one mesh in a MED file with MEDLoader + +The first think to know is that MEDLoader is using the \b meshName in +ParaMEDMEM::MEDCouplingMesh instance to put it in MED file. + +As explained in previous section \ref MEDLoaderMeshNameConstraint "here", +a mesh in MED file is discriminated by a name, so the \b meshName +\b should \b be \b non \b empty. If it is the case an +INTERP_KERNEL::Exception will be thrown. + +Here is a \ref py_mcumesh_writefile_onemesh_basic "Python example". + + +\subsection MEDLoaderWriteMeshes Writing several meshes in a MED file with MEDLoader + +It could be interesting to write several meshes in one shot. Two +possibilities: + +- Write several instances of ParaMEDMEM::MEDCouplingUMesh + lying \b on \b same \b coords \b with \b different \b mesh \b dimensions. In this case MEDLoader::WriteUMeshes is the method you should + use. Typically this method should be used to write files such as + defined \ref MEDLoaderExample2 "here". + This method first checks that all instances share the same + ParaMEDMEM::DataArrayDouble instance as coords. If not an + INTERP_KERNEL::Exception will be thrown and an invocation on + ParaMEDMEM::MEDCouplingPointSet::tryToShareSameCoords will be necessary. + +- Write a partition of meshes having \b same \b mesh \b dimension, that is to say a set of + 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 input (preserving order) and will simplify the + merged mesh. After this operation, the groups will be constituted by + assigning the group names with the corresponding names of + instance. That's why all meshes must have a not empty name which is different from one mesh to the other. The method to use in this case is + MEDLoader::WriteUMeshesPartition. + +For these 2 described methods the semantic of \b writeFromScratch when +\b false is the same, that is to say : no writing +(INTERP_KERNEL::Exception thrown) will be done if the +file already exists and contains a mesh with name 'meshName' +for MEDLoader::WriteUMeshesPartition method and the name of first element +of unstructured mesh vector passed as first parameter of +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 +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 writes the specified time step on it. + +- When \b writeFromScatch equals to \b false, this method checks that + the underlying mesh exists (by looking to the contents of \c field->getMesh()->getName()) in file. If not, the behaviour is the + same that previous case with \b writeFromScratch parameter set to + \b true. If the mesh already exists, MEDLoader reads the field and + tries to apply field on it. This operation could be rather time + consuming because a read operation is performed and a reorder + operation too. If the file already contains the same field at the + same time step (iteration and order ids) the corresponding time step + will be replaced by the field passed in parameter. + +\subsection MEDLoaderWriteFields Writing several time steps of a field in a MED file with MEDLoader + +Here is a \ref py_mcfield_writefile_severaltimesteps_basic "Python example". + +*/ diff --git a/doc/doxygen/input/tools.dox b/doc/doxygen/input/tools.dox new file mode 100644 index 000000000..8bcba7cd2 --- /dev/null +++ b/doc/doxygen/input/tools.dox @@ -0,0 +1,100 @@ +/*! +\page tools Tools on MED file + +\section Introduction + +There are few executables based on the MEDCoupling and MEDLoader libraries that + help the user to perform +common operations on MED files : +- conversion to other formats, +- splitting of a %MED file to a parallel %MED file distributed over a +number of subdomains. + +\section medpartitioner MEDPartitioner tool + +The purpose of MEDPARTITIONER is to split MED files into +a series of other MED files forming a partition of the original MED +files. It can either work with serial meshes (1 to n) or distributed +meshes (p to n). For serial meshes, it accepts MED files from the 2.1 +version onwards. For distributed MED files, it accepts MED files from +the 2.3 version onwards. + +There exists a parallel version of MEDPARTITIONER, which accepts +distributed MED files only. In contrast to the ordinary MEDPARTITIONER +the parallel one distributes several usual MED files composing the +whole model among available processors. After the +partitioning, each processor writes only it's own part of the +distributed MED file. The parallel MEDPARTITIONER processes meshes only, +not fields. + +It can be used either as an executable, \a medpartitioner (or \a +medpartitioner_para) or as a library. The partitioning is made thanks to +one of the following library : +- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html) +- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_en.html) + +The arguments to the medpartitioner tool can be retrieved by calling : +\code +medpartitioner --help +\endcode +or +\code +medpartitioner_para --help +\endcode + +For Salome V7.2.0, one gets the following arguments (some of them are +unavailable in parallel version): + +\code +Available options: + --help : produces this help message + --mesh-only : do not create the fields contained in the original file(s) + --distributed : specifies that the input file is distributed + --input-file= : name of the input MED file + --output-file= : name of the resulting file + --meshname= : name of the input mesh (not used with --distributed option) + --ndomains= : number of subdomains in the output file, default is 1 + --plain-master : creates a plain masterfile instead of an XML file + --creates-boundary-faces: creates the necessary faces so that faces joints are created in the output files + --family-splitting : preserves the family names instead of focusing on the groups +\endcode + +\section renumber RENUMBER tool + +The purpose of RENUMBER is to renumber the cell of a mesh in order to +make numerical computation easier. This tool works with meshes +which contain only one cell type and can renumber it according to two +different methods: +- Reverse Cuthill McKee (with the Boost Graph Library http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/table_of_contents.html) +- Nested Dissection (with the METIS library +http://glaros.dtc.umn.edu/gkhome/views/metis/index.html) + +It can be used in this way : +\code +renumber MEDFile_in MeshName Method[BOOST/METIS] MEDFile_out +\endcode + +\section sauv2med sauv2med tool + +The sauv2med tool enable conversion from a Cast3m \a sauv file into a +MED file. It is a python script that encapsulates the read/write +drivers provided by the MEDLoader library. + +Calling +\code +sauv2med myfile.sauv +\endcode +generates a \a med file named \a myfile.sauv.med + +\section med2sauv med2sauv tool + +med2sauv operator is the operator that is inverse of sauv2med. Its +behaviour is symmetrical. + +Calling +\code +med2sauv myfile.med +\endcode +generates a \a sauv file named \a myfile.med.sauv + +*/ diff --git a/doc/doxygen/interpkernel.dox b/doc/doxygen/interpkernel.dox deleted file mode 100644 index 28473e091..000000000 --- a/doc/doxygen/interpkernel.dox +++ /dev/null @@ -1,85 +0,0 @@ -/*! -\page interpkernel Interpolation kernel - -\section InterpKerIntro Introduction - -The main purpose of this module is to propose a set of algorithms for -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. - -\section InterpKerMainArchitecture Main architecture of interpolation kernel. - -In the %interpolation kernel, algorithms that computes the intersection \f$ T_i\cap S_j\f$ given the locations and geometries of source cell \f$ S_j \f$ -and target cell \f$ T_i \f$ are called \ref InterpKerIntersectors. - -As can be seen in \ref ConsInterp "the theory of interpolation", all the proposed interpolators aim at -filling the interpolation matrix W (which is generally sparse). For each pair (i,j), \f$ W_{ij} \f$ is obtained -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 -is too far from an another cell in the target mesh each. - -So for a given type of interpolation, the computation of W is -performed in two steps : - --# A filtering process reduces the number of pairs of elements for which the calculation must be carried out by - eliminating the pairs whose bounding boxes do not intersect. --# For all remaining pairs calling for each intersector (click here for the available \ref InterpKerIntersectors). - -Whatever its dimension and type, each interpolator inherits from INTERP_KERNEL::Interpolation which is a -template (CRTP) class than enable an easy access to the main API without useless CPU cost. - -\subsection InterpKerMeshType class MeshType - -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 \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 : - -- Const values / Types - - MyConnType : represents type of connectivity index. This is typically \c int or \c long \c int . - - MY_SPACEDIM : space dimension. Dimension relative to coordinates. - - MY_MESHDIM : the dimension of all cells in meshes. - - My_numPol : policy of numbering. C Format ( \f$ [0,n-1] \f$ ) or FORTRAN ( \f$ [1,n] \f$ ). -- Methods - -# \code void getBoundingBox(double *boundingBox) const \endcode - -# \code INTERP_KERNEL::NormalizedCellType getTypeOfElement(MyConnType eltId) const \endcode - -# \code unsigned char getNumberOfNodesOfElement(MyConnType eltId) const \endcode - -# \code unsigned long getNumberOfNodes() const \endcode - -# \code unsigned long getNumberOfElements() const \endcode - -# \code const MyConnType *getConnectivityPtr() const \endcode - -# \code const double *getCoordinatesPtr() const \endcode - -# \code const MyConnType *getConnectivityIndexPtr() const \endcode - -# \code void releaseTempArrays() \endcode -- Formats of arrays - - the array returned by \c getCoordinatesPtr must be a \b full \b interlace array. - - the arrays returned by \c getConnectivityPtr and \c getConnectivityIndexPtr must be with the same principle as it is \ref MEDCouplingUMeshNodalConnectivity "implemented in MEDCouplingUMesh". Of course the numbering format may change according to \a My_numPol policy. - -Note that the array format for connectivity is kept close to MED. It is -close to VTK format too but slightly different. So it may require for the VTK side a copy -on wrap. To avoid this copy of a part of the connectivity structure, an iterator should be used. - -\subsection InterpKerMatrixType class MatrixType - -As already said, the matrix returned by interpolator is typically a sparse matrix. Instances of -\c class \c MatrixType are used to store the resulting interpolation matrix. To be able to be filled by the interpolator the \c MatrixType class has to match the following concept : - -- Methods - -# \code void resize(uint nbrows) \endcode - -# \code Row &operator [] (uint irow) \endcode - -\c class \c Row has to match at least the following concept : - -- Methods - - \code void insert(const std::pair& myPair) \endcode - -Note that \c std::vector\c < \c std::map > is a candidate for \c MatrixType. - -*/ diff --git a/doc/doxygen/interptheory.dox b/doc/doxygen/interptheory.dox deleted file mode 100644 index 937945bca..000000000 --- a/doc/doxygen/interptheory.dox +++ /dev/null @@ -1,272 +0,0 @@ -/*! -\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: - -\f[ - \phi_t=W.\phi_s. -\f] - -\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 discretization (on cells P0, on nodes P1,...). - -\section ConsInterp Conservative interpolation - -At the basis of many CFD numerical schemes is the fact that physical -quantities such as density, momentum per unit volume or energy per -unit volume obey some balance laws that should be preserved at the -discrete level on every cell. - -It is therefore often desired that the process interpolation preserve the -integral of \f$ \phi \f$ on any domain. At the discrete level, for any -target cell \f$ T_i \f$, the following \b general \b interpolation \b -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. -\f] - -This equation is used to compute \f$ W_{ij} \f$, based on the fields representation ( P0, P1, P1d etc..) and the -geometry of source and target mesh cells. - -\section MeshOverlap Mesh overlapping - -Another important property of the interpolation process is the maximum principle: the field values resulting from the interpolation should remain between the upper and lower bounds of the original field. -When interpolation is performed between a source mesh S and a target -mesh T the aspect of overlapping is important. In fact if any cell of -of S is fully overlapped by cells of T and inversely any cell of T is -fully overlapped by cells of S that is -\f[ -\sum_{S_j} Vol(T_i\cap S_j) = Vol(T_i),\hspace{1cm} and \hspace{1cm} \sum_{T_i} Vol(S_j\cap T_i) = Vol(S_j) -\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. - -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, -- 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 - -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}. -\f] - -Here Vol represents the volume when the mesh dimension is equal to 3, the -area when mesh dimension is equal to 2, and length when mesh dimension is equal to 1. - -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}. -\f] - -As the field values are constant on each -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) }. -\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. -Hence in the \ref InterpKerGenralEq "general interpolation equation" the -left hand side becomes : - -\f[ -\int_{T_i} \phi = P_{T_i}, -\f] - -while the right hand side is now : - -\f[ -\sum_{S_j\cap T_i \neq \emptyset} \int_{T_i\cap S_j} \phi = -\sum_{S_j\cap T_i \neq \emptyset} \frac{Vol(T_i\cap S_j)}{ Vol(S_j)}.P_{S_j}. -\f] - -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) }. -\f] - -\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: - - * - * - * - * - *
Intensive extensive
Conservation \f[\frac{Vol(T_i\cap S_j)}{ Vol(T_i)}\f]
\ref TableNatureOfFieldExampleRevIntegral "RevIntegral" 		\f[ \frac{Vol(T_i\cap S_j)}{ \sum_{T_i} Vol(S_j\cap T_i) }\f]
\ref TableNatureOfFieldExampleIntegralGlobConstraint "IntegralGlobConstraint"
Maximum principle \f[\frac{Vol(T_i\cap S_j)}{ \sum_{S_j} Vol(T_i\cap S_j)}\f]
\ref TableNatureOfFieldExampleConservVol "ConservativeVolumic" 		\f[\frac{Vol(T_i\cap S_j)}{ Vol(S_j) }\f]
\ref TableNatureOfFieldExampleIntegral "Integral"
- -\section TableNatureOfFieldExample Illustration of a non overlapping P0P0 interpolation - -Let's consider the following case with a source mesh containing two cells and a target mesh containing one cell. -Let's consider a field FS on cells on the source mesh that we want to interpolate on the target mesh. - -The value of FS on the cell#0 is 4 and the value on the cell#1 is 100. - -The aim here is to compute the interpolated field FT on the target mesh of field FS depending on the \ref NatureOfField "nature of the field". - -\anchor TableNatureOfFieldEx1 -\image html NonOverlapping.png "An example of non overlapping intersection of two meshes." - -The first step of the interpolation leads to the following M1 matrix : - -\f[ - M1=\left[\begin{tabular}{cc} - 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 : - -\f[ - M_{Conservative Volumic}=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{0.125+0.75}}$ & - $\displaystyle{\frac{0.75}{0.125+0.75}}$ \\ - \end{tabular}\right]=\left[\begin{tabular}{cc} - 0.14286 & 0.85714 \\ - \end{tabular}\right] -\f] -\f[ - FT=\left[\begin{tabular}{cc} - $\displaystyle\frac{0.125}{0.875}$ & $\displaystyle\frac{0.75}{0.875}$ \\ - \end{tabular}\right].\left[\begin{tabular}{c} - 4 \\ - 100 \\ - \end{tabular}\right] - =\left[\begin{tabular}{c} - 86.28571\\ - \end{tabular}\right] -\f] - -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 - -If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{Integral} \f$ matrix : - -\f[ - M_{Integral}=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{9}}$ & $\displaystyle{\frac{0.75}{3}}$ \\ - \end{tabular}\right]=\left[\begin{tabular}{cc} - 0.013888 & 0.25 \\ - \end{tabular}\right] -\f] -\f[ - FT=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{9}}$ & $\displaystyle{\frac{0.75}{3}}$ \\ - \end{tabular}\right].\left[\begin{tabular}{c} - 4 \\ - 100 \\ - \end{tabular}\right] - =\left[\begin{tabular}{c} - 25.055\\ - \end{tabular}\right] -\f] - -This type of interpolation is typically recommended for the interpolation of \b power (\b NOT \b power \b density !) for -a user who wants to conserve the quantity \b only on the intersecting part of the source mesh (the green part on the \ref TableNatureOfFieldEx1 "example") - -This type of interpolation is equivalent to the computation of \f$ FS_{vol} \f$ followed by a multiplication by \f$ M1 \f$ where \f$ FS_{vol} \f$ is given by : - -\f[ - FS_{vol}=\left[\begin{tabular}{c} - $\displaystyle{\frac{4}{9}}$ \\ - $\displaystyle{\frac{100}{3}}$ \\ - \end{tabular}\right] -\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 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 - -If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{IntegralGlobConstraint} \f$ matrix : - -\f[ - M_{IntegralGlobConstraint}=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{0.125}}$ & ${\displaystyle\frac{0.75}{0.75}}$ \\ - \end{tabular}\right]=\left[\begin{tabular}{cc} - 1 & 1 \\ - \end{tabular}\right] -\f] -\f[ - FT=\left[\begin{tabular}{cc} - 1 & 1 \\ - \end{tabular}\right].\left[\begin{tabular}{c} - 4 \\ - 100 \\ - \end{tabular}\right] - =\left[\begin{tabular}{c} - 104\\ - \end{tabular}\right] -\f] - -This type of interpolation is typically recommended for the interpolation of \b power (\b NOT \b power \b density !) for -a user who wants to \b conserve \b all \b the \b power in its source field. Here we have 104 W in source field, we have 104 W too, -in the output target interpolated field. - -\b BUT, As we can see here, the maximum principle is \b not respected here, because the target cell #0 has a value higher than the two -intercepted source cells. - -\subsection TableNatureOfFieldExampleRevIntegral Reverse integral case - -If we apply the formula \ref TableNatureOfField "above" it leads to the following \f$ M_{RevIntegral} \f$ matrix : - -\f[ - M_{RevIntegral}=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{1.5}}$ & $\displaystyle{\frac{0.75}{1.5}}$ \\ - \end{tabular}\right]=\left[\begin{tabular}{cc} - 0.083333 & 0.5 \\ - \end{tabular}\right] -\f] -\f[ - FT=\left[\begin{tabular}{cc} - $\displaystyle{\frac{0.125}{1.5}}$ & $\displaystyle{\frac{0.75}{1.5}}$ \\ - \end{tabular}\right].\left[\begin{tabular}{c} - 4 \\ - 100 \\ - \end{tabular}\right] - =\left[\begin{tabular}{c} - 50.333\\ - \end{tabular}\right] -\f] - -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 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 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/interptools.dox b/doc/doxygen/interptools.dox deleted file mode 100644 index b52d689c4..000000000 --- a/doc/doxygen/interptools.dox +++ /dev/null @@ -1,28 +0,0 @@ -/*! -\page interptools Interpolation tools - -\section Presentation -The InterpKernel algorithms are part of the MED tool suite. They -answer to the following basic problem : given a source mesh \f$M_s\f$, a -source field \f$F_s\f$ and a target mesh \f$M_t\f$, reconstruct a field \f$F_t\f$ -that uses \f$M_t\f$ as a support. The InterpKernel suite gives a number of -possibilities to compute the target field, depending on a variety of -user constraints. - -\image html interpolationimage.png "General interpolation scheme" width=10cm - -The starting point for using the tools is the description of the two main different APIs. -- \ref RemapperClasses "Remapper class" and the underlying \ref interpkernel library for sequential codes using \ref medcoupling fields or other data structures. -- \ref paramedmem for parallel MPI based codes using \c ParaMEDMEM distributed fields, and the algorithms of the \ref interpkernel library. - -The possibilities encompass: -- 1D, 2D lines, 2D (\ref interpolation2D), 3D surfaces(\ref interpolation3Dsurf) and 3D(\ref interpolation3D) handling, -- computation via node localization (\ref pointlocator) or via cell intersection (\ref ConsInterp), -- treatment of extended polygons (where edges can be arcs or segments) -for 2D intersection computations via \ref interpkernelGeo2D, -- management of fields with P0,P1 or P2 representations. P0<->P0, P1<->P0, P1<->P1 and P2->P0 (non conservative) interpolators are available. - -In case of non \ref MeshOverlap "overlapping meshes", it is important to specify whether the field represents an extensive or intensive physical quantity through -the \ref NatureOfField attribute of the \ref medcoupling field. - -*/ \ No newline at end of file diff --git a/doc/doxygen/intersectors.dox b/doc/doxygen/intersectors.dox deleted file mode 100755 index 3f212f835..000000000 --- a/doc/doxygen/intersectors.dox +++ /dev/null @@ -1,140 +0,0 @@ -/*! -\defgroup InterpKerGrpIntPlan Plannar Intersector - -Here are listed all the methods to be called or to overload to all -concrete intersector. - -\page InterpKerIntersectors Intersectors - -\section interpolation2D Special features of 2D intersectors - -\subsection InterpKerPlanarIntGenP0P0 P0->P0 : PlanarIntersector. - -All the 2D intersectors inherits from INTERP_KERNEL::PlanarIntersector class. - -All the important methods are \ref InterpKerGrpIntPlan "described here".\n To sum up the main task offered by this class is to give the -evaluation of interpolation of one cell in source mesh with an another -cell in target mesh. - -\subsection InterpKerPlanarIntFeatureP0P0 P0->P0 intersectors features. - -When remapping two dimensional fields, areas of intersection between polygonal cells are to be computed. Three algorithms are available: -- Triangle: decompose each cells into triangles and computes triangle-triangle intersection by determining segment crossings and node inclusions. This algorithm is the fastest if both meshes are made of triangular cells. -- Convex: presume that both meshes are made of convex cells, and performs a direct computation of the intersection nodes between two cells through a sweep line algorithm (see F. Preparata and M. Shamos, 1985 in \ref references). -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 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 Triangle). For P0P1 locate target nodes -in source cells. For P1P1 compute for each target node its barycentric -coordinates in source cell. - -The following options are available for the 2D intersection computations: - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be - * used in the computation of the cell-cell intersections - * Triangle, Convex, \ref interpkernelGeo2D "Geometric2D", PointLocator Triangle
Precision Accuracy of the computations is precision times the characteristic size of the meshes positive real numbers 1.0E-12
PrintLevel Level of verboseness during the computations 0, 1, 2, 3 0
- -\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 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: - - * - * - * - * - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
MedianPlane Position of the median plane where both cells will be projected real numbers between 0 and 1 0.5
Precision Accuracy of the computations is - * precision times the characteristic size of the meshes - * positive real numbers 1.E-12
Orientation Specifies orientation to take into account. If -1 only negative intersection area are taken into account. If 1 only positive intersection - * area are taken into account. If 0 intersection area are always taken into account. If 2 intersection area are always taken into account (as 0) difference is that absolute value -1,0,1,2 0
DoRotate Performs a rotation of the coordinate - 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 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. - -\section interpolation3D Special features of 3D volumes intersectors - -\subsection InterpKer3DIntGenP0P0 P0->P0 : TargetIntersector - -Unlike \ref InterpKerPlanarIntGenP0P0 "PlanarIntersector phylosophy" -this intersector is slightly different. Here for the moment -there is one instance per pair of meshes \b and target element. See INTERP_KERNEL::TargetIntersector for -more details. - -\subsection InterpKer3DIntFeatureP0P0 P0->P0 intersectors features. - -When remapping three dimensional fields, volumes of intersection -between polyhedral cells are to be computed. -Two methods are available : -- Triangle : the method of Jeffrey Grandy, 1999 (see \ref references) -to intersect arbitrary polyhedra. The basic algorithm computes the -intersection of a tetrahedron with an arbitrary (possibly non convex) -polyhedron. Using splitting techniques, it is possible to transform -the problem of computing the intersection between two general -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 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. - - * - * - * - * - * - *
OptionDescription Admitted valuesDefault
Intersection_typeSpecifies the algorithm to be - * used in the computation of the cell-cell intersections - * Triangle, PointLocator Triangle
SplittingPolicy Way in which the hexahedra are - * split into tetrahedra (only if Intersection_type==Triangle) PLANAR_FACE_5, PLANAR_FACE_6, GENERAL_24, GENERAL_48 GENERAL_48
PrintLevel Level of verboseness during the computations 1, 2, 3, 4, 5 0
- -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 planar faces and nodes numbered according to the following picture: -\verbatim - - 7 ------ 6 - /| /| - / | / | - 3 ------ 2 | - | | | | - | | | | - | 4-----|- 5 - | / | / - 0 ------ 1 -\endverbatim -The use of the SPLIT_NODES_5 splitting policy would lead to a 5 tetrahedra decomposition as follows : -\verbatim - 0, 1, 5, 2 - 0, 4, 5, 7 - 0, 3, 7, 2 - 5, 6, 7, 2 - 0, 2, 5, 7 -\endverbatim -The use of the SPLIT_NODES_6 splitting policy would lead to a 6 tetrahedra decomposition as follows : -\verbatim - 0, 1, 5, 6 - 0, 2, 1, 6 - 0, 5, 4, 6 - 0, 4, 7, 6 - 0, 3, 2, 6 - 0, 7, 3, 6 -\endverbatim - -*/ diff --git a/doc/doxygen/main.dox b/doc/doxygen/main.dox deleted file mode 100644 index cb275c482..000000000 --- a/doc/doxygen/main.dox +++ /dev/null @@ -1,97 +0,0 @@ -/*!\mainpage SALOME MED user's guide - -\section intro Introduction -This document is the user guide of the %MED SALOME module. The MED -module consists in: - -- \ref S1 to manipulate meshes and fields that conform - to the MED data model. This library can be used in C++ programs as - in python script for data processing on meshes and fields. -- \ref S2 that exhibits some useful functions of the - library for a graphical manipulation of data in standard use cases. -- \ref S3 that can be used to process MED data files - -\section S1 A library of functions for data processing - -The figure below represents the layer structure of the packages of the -library: - -\image html medlayers_70pc.png - -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 -- \ref interptools (INTERP_KERNEL + ParaMEDMEM::MEDCouplingRemapper) that provides - mathematical structures and algorithms for interpolation and - localization. - -\section S2 A graphical interface for standard use cases - -The MED module in SALOME comes with a graphical interface that helps -you to deal with most standard use case of fields manipulation. The -user guide can be found here: - -- User guide of the MED Graphical Interface (in french) - -You could also be interested to read the software specifications and -requirements for this graphical module, and even the technical -considerations for development: - -- Software - specifications and requirements of the MED Graphical Interface (in french) -- Developer guide of the MED Graphical Interface (in french) - -\section S3 A set of tools for file manipulation - -- Chapter \ref tools describes various tools based on MEDLoader that can -be helpful for handling MED files (conversion tools and splitting tools). - -\section install Installation -The install procedure of the %MED SALOME module can handle a variety of configurations -to suit the needs of its user. Instructions for configuring and -installing the module an be found in \ref paramedmem_install. - -*/ - -/*! -\page paramedmem_install Configuring and Installing MED from sources - -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 first step consists in preparing the configuration of the library : -\verbatim -cd ${MED_SRC} -./build_configure -\endverbatim - -This will create SALOME MED libraries with link to the SALOME Kernel. -Sometimes, if it is desirable to have a standalone version of the library to be used independently from SALOME, use : -\verbatim -cd ${MED_SRC} -./build_configure --without-kernel -\endverbatim - -The library can then be configured : -\verbatim -mkdir ../MED_BUILD -cd ../MED_BUILD -../MED_SRC/configure --prefix=`pwd`/../MED_INSTALL -\endverbatim - -This will configure the library without splitting functionalities. ParaMEDMEM will be compiled if an MPI version has been found. - -The following options can be useful to configure SALOME MED : -- \a --enable-splitter=yes will trigger the compilation of the MEDSPLITTER tool, -- \a --with-metis=${METISDIR} will specify a location for the METIS library, -- \a --with-scotch=${SCOTCHDIR} will specify a location for the SCOTCH library, -- \a --with-med3=${MED3DIR} specifies a location for MED-file library, -- \a --with-hdf5=${HDF5DIR} specifies a location for the HDF5 library (must be the same as that used for the MED-file library) -- \a --with-lam=${LAMDIR} specifies an install path for a LAM MPI library, -- \a --with-mpich=${MPICHDIR} specifies an install path for a MPICH-1 library. -*/ diff --git a/doc/doxygen/medcoupling.dox b/doc/doxygen/medcoupling.dox deleted file mode 100644 index 14c3a61c2..000000000 --- a/doc/doxygen/medcoupling.dox +++ /dev/null @@ -1,872 +0,0 @@ -/*! -\page medcoupling MEDCoupling - -\section MEDCouplingIntro Introduction - -\ref medcoupling "MEDCoupling" is a library (\b libmedcoupling.so or \b medcoupling.dll) fully written in C++ and wrapped to be called in Python too. - -\ref medcoupling "MEDCoupling" C++ library implements a data structure which is the result of the following tradeoff : - -- 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 on -\ref interpkernel "INTERP_KERNEL library" -- light enough to be agile in order to : - - maximize the amount of algorithms being applied on it - - to ease implementation of clients of \ref medcoupling "MEDCoupling". -- large enough to be used for MED file I/O. -- compliant with VTK visualization DataStructure -- integrate HPC constraints (compact structures, limitation of copies and launching of CPU consuming algorithms only when absolutely needed ). -- compliant with ICOCO API - -\ref medcoupling "MEDCoupling" implements a set of algorithms linked to the data structure. - -\section MEDCouplingMainConc Main Concepts - -Here are listed basic concepts present into \ref medcoupling "MEDCoupling". - -For beginners in \ref medcoupling "MEDCoupling" world, it is advisable to read the following concepts in the same order than the underlying list. - -- \subpage MEDCouplingArrayPage "DataArrays" -- \subpage MEDCouplingMeshesPage "Meshes" -- \subpage MEDCouplingFieldsPage "Fields" -- \subpage MEDCouplingFieldTemplatesPage "Field templates" -- \subpage MEDCouplingTimeLabelPage "Time labels" - -*/ - -/*! - \page MEDCouplingMeshesPage Meshes in MEDCoupling - -\section MEDCouplingMeshes Common concept shared by all type of Meshes in MEDCoupling - -A mesh has the following properties : - -- name -- **a dimension (called mesh dimension) and only one** (it implies that \b all cells constituting -mesh have the same dimension) -- a space dimension (relative to coordinates) -- a number of nodes -- a number of cells - -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 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 instantiable mesh types in MEDCoupling - -- \subpage MEDCouplingUMeshPage "Unstructured meshes" -- \subpage MEDCouplingCMeshPage "Cartesian meshes" -- \subpage MEDCouplingExtrudedPage "3D Extruded meshes" - -/*! -\page MEDCouplingFieldsPage Fields in MEDCoupling - -[TOC] - -\section MEDCouplingFields Field concept - -A field in MEDCoupling point of view, is a structure that allows to -store a discretization of a physical value on a defined discretized spatial and -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 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. - -Fields in MEDCoupling follow the two following rules : - -- A field will lie on \b ALL entities of its spatial support (\ref MEDCouplingMeshesPage "mesh"). -- A field has \b only \b one spatial support (\ref MEDCouplingMeshesPage "mesh") on its temporal support. - -The main properties of a field are : - -- name -- spatial support which is a \ref MEDCouplingMeshesPage "mesh" -- a \ref MEDCouplingSpatialDisc "spatial discretization" -- a description of intrinsic nature of the values of field (see \ref NatureOfField). This is important for conservative interpolation (see \ref TableNatureOfField). -- a temporal discretization that specifies, if it exists, the time interval on which the field is covering, and how. -- number of components - -This definition of field in MEDCoupling allows an instance of field to -know at any point inside its spatial-temporal support the value. - -The class that incarnates the concept described above is : \ref ParaMEDMEM::MEDCouplingFieldDouble. - -Some of most important implemented methods are : - -- \ref ParaMEDMEM::MEDCouplingFieldDouble::getNumberOfComponents "getNumberOfComponents" -- \ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn" -- \ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc "applyFunc" -- \ref ParaMEDMEM::MEDCouplingFieldDouble::addFields "cross instances operations" -\section MEDCouplingSpatialDisc Spatial discretization concept - -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"). - -The abstract class that incarnates the concept is : \ref ParaMEDMEM::MEDCouplingFieldDiscretization. - -The most important pure virtual methods are : - -- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getNumberOfTuples "getnumberOfTuples" -- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getValueOn "getValueOn" -- \ref ParaMEDMEM::MEDCouplingFieldDiscretization::getMeasureField "getMeasureField" - -\section MEDCouplingTemporalDisc Temporal discretization concept - -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). - -The abstract class \ref ParaMEDMEM::MEDCouplingTimeDiscretization -incarnates this described concept. - -This classes and its subclasses are responsible in storing the arrays -of the aggregating field. - -The most important methods are : - -- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::setTime "setTime" and \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getTime "getTime" -- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getArray "getArray" and \ref ParaMEDMEM::MEDCouplingTimeDiscretization::setArray "setArray" -- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getArraysForTime "getArraysForTime" -- \ref ParaMEDMEM::MEDCouplingTimeDiscretization::getValueForTime "getValueForTime" - -\section MEDCouplingFirstSteps3 Building a field from scratch - -Here we will make the assumption that an instance of \c MEDCouplingMesh called \c mesh has been created ( to know more about mesh creation \ref MEDCouplingUMeshStdBuild "click here" ). - -\subsection MEDCouplingFirstSteps3OnCellsNoTS Create a tensor field with 9 components on cells with no time step - -\subpage medcouplingcppexamplesFieldDoubleBuild1 "Here the C++ implementation." - -\subpage medcouplingpyexamplesFieldDoubleBuild1 "Here the Python implementation." - -\subsection MEDCouplingFirstSteps3OnNodesNoTS Create a scalar field on nodes with no time step - -\subpage medcouplingcppexamplesFieldDoubleBuild2 "Here the C++ implementation." - -\subpage medcouplingpyexamplesFieldDoubleBuild2 "Here the Python implementation." - -\subsection MEDCouplingFirstSteps3OnCellsWTS Create a 2 components-vector field on cells with one time step and no interval - -\subpage medcouplingcppexamplesFieldDoubleBuild3 "Here the C++ implementation." - -\subpage medcouplingpyexamplesFieldDoubleBuild3 "Here the Python implementation." - -\subsection MEDCouplingFirstSteps3OnCellsCTI Create a 3 components-vector field on nodes with a time interval where field remains constant on this time interval - -\subpage medcouplingcppexamplesFieldDoubleBuild4 "Here the C++ implementation." - -\subpage medcouplingpyexamplesFieldDoubleBuild4 "Here the Python implementation." - -\section MEDCouplingSecondStep0 Operations on Fields - -Here we will make the assumption that an instance of \ref ParaMEDMEM::MEDCouplingMesh "MEDCouplingMesh" -called \c mesh has been created with spaceDim==2. - -\subpage medcouplingcppexamplesFieldDoubleBuild5 "Here a C++ example of more advanced use of MEDCouplingFieldDouble instances". - -\subpage medcouplingpyexamplesFieldDoubleBuild5 "Here a Python example of more advanced use of MEDCouplingFieldDouble instances". - -*/ - -/*! - -\page MEDCouplingArrayPage MEDCoupling Arrays - -[TOC] - -\section MEDCouplingArrayIntro Introduction - -One of the most basic concept mainly used all over MEDCoupling is -MEDCoupling array. - -This concept is used all over -\ref medcoupling "MEDCoupling", \ref paramedmem "ParaMEDMEM", \ref medloader "MEDLoader" modules so it should be correctly -handled to play well with \ref MEDCouplingMeshesPage "Meshes" and \ref MEDCouplingFieldsPage "Fields". - -\ref ParaMEDMEM::DataArray "DataArrays" are the atomic element of potentially heavy in memory objects in \ref medcoupling "MEDCoupling", \ref paramedmem "ParaMEDMEM" and \ref medloader "MEDLoader". - -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::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". - -\section MEDCouplingArrayBasics Basics concepts of the DataArrays. - -It will be presented in this section common concept shared by the two classes to \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" and \ref ParaMEDMEM::DataArrayInt "DataArrayInt". - -\subsection MEDCouplingArrayBasicsName Name - -A \ref ParaMEDMEM::DataArray "DataArray" instance has an attribute **name**. - -**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. - -\subsection MEDCouplingArrayBasicsTuplesAndCompo Raw data, tuples and components of DataArrays. - -The main goal of \ref ParaMEDMEM::DataArray "DataArray" is to store contiguous vector of atomical elements with same basic datatype (signed integers, double precision...). This vector of atomical elements is called **raw data** of \ref ParaMEDMEM::DataArray "DataArray". - -The size of this vector of data is called "number of elements". So the number of bytes stored by a \ref ParaMEDMEM::DataArray "DataArray" instance, is equal to -the product of the __number of elements__ * __constant size of DataType__ . - -As \ref ParaMEDMEM::DataArray "DataArray" instances are designed to store vector fields, tensor fields, coordinate of nodes, the notion of _components_ has been added. - -So, \ref ParaMEDMEM::DataArray "DataArrays" have an additional attribute that is number of components that represent the size of a contiguous set of atomical elements. -The vector of atomical elements stored into \ref ParaMEDMEM::DataArray "DataArrays" are grouped in contiguous memory set of atomical elements having each same size. - -The contiguous set of atomical elements is called **tuple**. And each **tuple** stored in raw data, have each a length exactly equal to the number of components of -\ref ParaMEDMEM::DataArray "DataArray" storing it. - -Thus : - -\f[ - N_{elements}=N_{tuples}*N_{components}. -\f] - -\f[ - N_{bytes}=N_{elements}*sizeof(DataType)=N_{tuples}*N_{components}*sizeof(DataType). -\f] - -In other words, **raw data** of \ref ParaMEDMEM::DataArray "DataArrays" can be seen as a dense matrix, whose number of components would be the row size and number of tuples -would be the column size. In this point of view of \ref ParaMEDMEM::DataArray "DataArrays" a **tuple** is represented by the corresponding row in the dense matrix. - -Typically in the **raw data** of \ref ParaMEDMEM::DataArray "DataArrays" **number of tuples** is highly bigger than **number of components** ! - -To finish, raw data is stored tuples by tuples, in another words, in **full interlace mode**, which is the natural storage strategy in C/C++ world. - -For example, let's consider a DataArray having 3 components (called *x* for the first component, *y* for the second, and *z* for the third) and composed by 5 tuples. -\n The *raw data* of the DataAarray instance will be organized in momory like that : \f$ x_0,y_0,z_0,x_1,y_1,z_1,x_2,y_2,z_2,x_3,y_3,z_3,x_4,y_4,z_4 \f$. - - -\subsection MEDCouplingArrayBasicsCompoName Information on components name. - -As seen in the sub section above, a \ref ParaMEDMEM::DataArray "DataArray" instance has a defined number of components. - -There is an information attached to each of these components constituting the \ref ParaMEDMEM::DataArray "DataArray". - -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 character. - -\subsection MEDCouplingArrayBasicsTimeLabel DataArrays and TimeLabel. - -\ref ParaMEDMEM::DataArray "DataArrays instances" can consume big amount of data in memory so they inherit from \subpage MEDCouplingTimeLabelPage "TimeLabel". -So in C++ it is a good practice to use : -- \c getConstPointer method in readonly access. -- \c getPointer method only if write is needed. - -If the user in C++ or Python wants to modify intensively its **big** \ref ParaMEDMEM::DataArray "DataArray" instance **not** using raw data pointer it is better to invoke -\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. - -\section MEDCouplingArraySteps0 Building an array from scratch in Python - -\subsection MEDCouplingArraySteps0Double Building an double array from scratch in Python - -Let's consider a list of floats \c dataDouble. - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_0 - -The easiest way to build the \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" called \c arrayDouble simply call : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_1bis - -An another way is to do that : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_1 - -\subsection MEDCouplingArraySteps0Int Building an int array from scratch in Python - -Let's consider a list of ints \c dataInt. - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_2 - -The easiest way to build the \ref ParaMEDMEM::DataArrayInt "DataArrayInt instance" called \c arrayInt simply call : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_3bis - -An another way is to do that : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayBuild1_3 - - -\section MEDCouplingArraySteps1 Building an array from scratch in C++ - -Here is a description of typical usages of \ref ParaMEDMEM::DataArrayDouble "MEDCoupling arrays". - -In this example we will create arrays with 12 tuples constituted each -of 3 components. These arrays will be created using different ways.\n - -The following code is only based using \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" -but the use of \ref ParaMEDMEM::DataArrayInt "DataArrayInt" is strictly equivalent. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_0 - -\subsection MEDCouplingArraySteps1NCNO Building an array from scratch in C++, no copy no ownership - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_1 - -\subsection MEDCouplingArraySteps1NCWCPPO Building an array from scratch in C++, no copy with C++ ownership - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_2 - -\subsection MEDCouplingArraySteps1NCWCO Building an array from scratch in C++, no copy with C ownership - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_3 - -\subsection MEDCouplingArraySteps1WC Building an array from scratch in C++, with copy - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_4 - -\section MEDCouplingArrayBasicsCopy Copy DataArrays. - -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) -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* 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_5 - -or : - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_5bis - -\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_6 - -As \c myCoordsCpy is a copy object it needs to be deallocated in C++ like \c myCoords. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_7 - -\subsection MEDCouplingArrayBasicsCopyShallow Shallow copy of DataArray - -As \ref ParaMEDMEM::DataArray "DataArrays" are the atomic entity of potentially big memory objects into \ref medcoupling "MEDCoupling", the shallow copy -simply returns the same object with the reference counter incremented. - -To perform a shallow copy of a DataArray instance simply invoke : - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_8 - -\c myCoordsCpy is the shallow copy of \c myCoords so they share the same *raw data*. In reality they are the same object. -So it leads to the following behaviour to compare with the deep copy : - -\anchor MEDCouplingArrayBasicsCopyShallowTestEqual - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_9 - -So here the content of \c myCoords and \c myCoordsCpy are linked, contrary to the deep copy case. - -As \c myCoordsCpy is a copy object, in C++, it needs to be deallocated. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_10 - -\subsection MEDCouplingArrayBasicsCopyDeepAssign Assignation by deep copy of DataArray - -We start by building a instance of ParaMEDMEM::DataArrayDouble allocated or not. Here, instance is not allocated, only built empty. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_11 - -Then, \c myCoordsCpy is assigned with the content of \c myCoords. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_12 - -Then \c myCoordsCpy is a deep copy of \c myCoords except that the instance of ParaMEDMEM::DataArrayDouble is those specified. -But the behaviour is the same than those seen for \ref MEDCouplingArrayBasicsCopyDeepTestEqual "deep copy". - -\snippet MEDCouplingExamplesTest.cxx CppSnippetDataArrayBuild1_13 - -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 - -\section MEDCouplingArrayBasicsCompare Compare DataArrays. - -Comparison is \ref medcoupling "MEDCoupling" is a concept highly sensitive because big amount of tests uses this to state about the sucess or the fail of these tests. -There are two types of comparison : - -- strict, that compares strictly all the non mutable attributes (state sensitive). Methods to perform this strict comparison are : - - ParaMEDMEM::DataArrayInt::isEqual - - ParaMEDMEM::DataArrayDouble::isEqual. - -- less strict, that focus only on non string attributes. Methods to perform less strict comparison are : - - ParaMEDMEM::DataArrayInt::isEqualWithoutConsideringStr - - ParaMEDMEM::DataArrayDouble::isEqualWithoutConsideringStr - -\section MEDCouplingArrayFill Filling DataArray with values - -Both DataArrayDouble and DataArrayInt provide comfort methods that -fill the array with some values. These methods are: -- ParaMEDMEM::DataArrayInt::fillWithZero and - ParaMEDMEM::DataArrayDouble::fillWithZero which assigns zero to all - values in array. -- ParaMEDMEM::DataArrayInt::fillWithValue and - ParaMEDMEM::DataArrayDouble::fillWithValue which assigns a certain value to all - values in array. -- ParaMEDMEM::DataArrayInt::iota() and - ParaMEDMEM::DataArrayDouble::iota() which assigns incrementing values to all - values in array. - -\section MEDCouplingArrayRenumbering Array renumbering - -Here is presented all it is necessary to know concerning renumbering. -Renumbering is intensely required in %MEDLoader in %ParaMEDMEM. One of the user of renumbering is MED file for I/O where cells are sorted by type. -But it is also used on operations of node cell merging. It is also used in parallel mode when splitting of mesh is needed... - -Formally a renumbering is a mathematical application that can be surjective, injective or bijective. This application is defined using an instance of -\ref ParaMEDMEM::DataArrayInt "DataArrayInt". There are different ways to define this application. - -\subsection MEDCouplingArrayRenumberingO2N Old to new mode - -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 - -If \b MySujection equals [2,1,0,1,2], it means that : - -- old id #0 will have new id equal to 2 -- old id #1 will have new id equal to 1 -- old id #2 will have new id equal to 0 -- old id #3 will have new id equal to 1 like old id #1 -- old id #4 will have new id equal to 2 like old id #0 - -This is the most common mode of renumbering in MEDCoupling because there is more methods implying renumbering that reduce the number of entities than method that increase number of entities. - -Method in old to new mode that works on bijective applications : - -- \ref ParaMEDMEM::DataArrayDouble::renumber "DataArrayDouble::renumber" -- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlace" - -Method in old to new mode that works on surjective applications : - -- \ref ParaMEDMEM::DataArrayDouble::renumberAndReduce "DataArrayDouble::renumberAndReduce" - -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 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. -Let's consider a call to \ref ParaMEDMEM::MEDCouplingUMesh::simplexize "simplexize" that increases the number of cell from 4 cells to 6 cells.\n -In new to old mode the array \b MyInjection that specifies this injection will have 6 tuples and 1 component. The content of the 5*1 values will be in {0,1,2,3}.\n -If \b MyInjection equals [2,0,1,1,3,0] it means that : - -- new id #0 comes from old id 2 -- new id #1 comes from old id 0 -- new id #2 comes from old id 1 -- new id #3 comes from old id 1 -- new id #4 comes from old id 3 -- new id #5 comes from old id 0 - -Method in new to old mode that works on bijective applications : - -- \ref ParaMEDMEM::DataArrayDouble::renumberR "DataArrayDouble::renumberR" -- \ref ParaMEDMEM::DataArrayDouble::renumberInPlace "DataArrayDouble::renumberInPlaceR" - -Method in new to old mode that works on surjective applications : - -- \ref ParaMEDMEM::DataArrayDouble::selectByTupleId "DataArrayDouble::selectByTupleId" -- \ref ParaMEDMEM::DataArrayDouble::selectByTupleIdSafe "DataArrayDouble::selectByTupleIdSafe" -- \ref ParaMEDMEM::DataArrayDouble::selectByTupleId2 "DataArrayDouble::selectByTupleId2" -- \ref ParaMEDMEM::DataArrayDouble::selectByTupleRanges "DataArrayDouble::selectByTupleRanges" - -\section MEDCouplingArrayApplyFunc Application of a function on DataArrayDouble instances. - -This section is only dedicated for \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instances". - -It is possible to apply to \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" a function given by a string. - -There are different API for applyFunc* methods of \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble class". - -\subsection MEDCouplingArrayApplyFuncExpr Expressions supported - -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), -- >,< -- if - -The expression evaluator is also sensitive to the following var pattern : IVec, JVec, KVec, LVec,... ,ZVec - -- IVec stands for unitary vector [1,0,0,0,...] -- JVec stands for unitary vector [0,1,0,0,...] -- KVec stands for unitary vector [0,0,1,0,...] -- ... - -The dynamic expression evaluator works tuple by tuple through the *raw data* of DataArrayDouble instance. - -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. -\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. - -- The given the preprocessed tree given an input tuple a preallocated tuple is fed with the result of the evaluation. - At this last phase only mathematical errors are thrown (division by 0, log(0), sqrt of a negative number ...) - -\subsection MEDCouplingArrayApplyFunc0 applyFunc method with only one parameter - -This method produces a newly allocated DataArrayDouble instance having exactly the same number of components **and** number of tuples than the instance on which the -\ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method is applied. - -**This method is useful when the evaluation expression do not need to consider the components of each tuple separately**. - -That's why this method of \ref ParaMEDMEM::DataArrayDouble::applyFunc(const char *) const applyFunc method with one parameter accepts at most only one variable. - -If it is not the case an exception is thrown as seen here : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_1 - -Let's take a very simple example on a DataArrayDouble instance \c d having 4 tuples and 2 components. - -In the next example the expression contains only one variable : \c smth. -So \c smth represent a tuple of size 2. - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_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 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. - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_3 - -In this example using IVec and JVec it is possible to differentiate output in component #0 and output in component #1 for DataArrayDouble instance \c d2. - -\subsection MEDCouplingArrayApplyFunc1 applyFunc method with only two parameters - -This method also returns a newly allocated DataArrayDouble instance having the same number of tuples than the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called, but the contrary to previous \ref MEDCouplingArrayApplyFunc0 "applyFunc with one parameter version" here the number of components is set by the user. - -The big difference with \ref MEDCouplingArrayApplyFunc0 "applyFunc method with one parameter" seen above is that here components of tuples are treated separately. - -The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const here. - -Here the number of variables appearing in the expression should be equal at most to the number of component of the DataArrayDouble instance on which \ref ParaMEDMEM::DataArrayDouble::applyFunc(int,const char *) const applyFunc method is called. - -Let's consider the following DataArrayDouble having 4 tuples with 3 components called dd. - -\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 and the square root of the second component and the third component -the invocation should be something like this : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_5 - -\warning In the expression \c "f+sqrt(g)+h", there are 3 variables \c {"g","h","f"}. As seen \ref MEDCouplingArrayApplyFuncExprA1 "in link phase in expression evaluator" it is needed to match a variable to -the component id. The strategy of expression evaluator is the following. Sort ascendingly variables using their names and affect component id following this sorted list. It leads to : -- \c f will be attached to component #0 of \c dd -- \c g will be attached to component #1 of \c dd -- \c h will be attached to component #2 of \c dd - -Considering the previous warning, let's try to perform an application of function to compute in a DataArrayDouble instance called \c dd2 starting by adding component #0 and component #2 -of \c dd. -\nThe expression \c "a+c" will add component #0 to component #1 as seen in warning section !!!! It can appear silly, but this strategy has been chosen in order to support different set of variables. -\n \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. -\n Here is a solution to compute \c dd2 : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_6 - -\subsection MEDCouplingArrayApplyFunc2 applyFunc2 method - -The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc2 here. - -This method is very close to \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters". - -The only different is the mapping between variables found in expression and tuple id. Rather than using rank in string sorting as \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters uses" here the component information are considered. - -Let's consider DataArrayDouble instance \c ddd constituted with 4 tuples containing each 3 components. The components are named respectively \c {"Y","AA","GG"} with following different units attached on them. - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_7 - -To compute the sum of the first component (component #0) and the third component (component #2) simply do that : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_8 - -\subsection MEDCouplingArrayApplyFunc3 applyFunc3 method - -The method that implements it is \ref ParaMEDMEM::DataArrayDouble::applyFunc3 here. - -This method is very close to \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters" and \ref MEDCouplingArrayApplyFunc2 "applyFunc2". - -The only different is the mapping between variables found in expression and tuple id. Rather than using rank in string sorting as in \ref MEDCouplingArrayApplyFunc1 "applyFunc method with only two parameters uses" or the component information as in \ref MEDCouplingArrayApplyFunc2 "applyFunc2", here an explicit vector is given in input. - -Let's consider DataArrayDouble instance \c ddd constituted with 4 tuples containing each 3 components. To add first component (component #0) and the third component (component #2) simply do that : - -\snippet MEDCouplingExamplesTest.py PySnippetDataArrayApplyFunc1_9 - -*/ - -/*! - \defgroup NatureOfField Nature of a field - - \section IntExtFields Overview: intensive and extensive field - -\c NatureOfField is an enum which helps determining some physical significance of the field and affects the choice of the interpolation formula (see \ref TableNatureOfField). -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, pressure fields. - -- \ref TableNatureOfFieldExampleRevIntegral "RevIntegral", for intensive field with the conservativity favored over maximum principle. Relevant for power density fields. - -- \ref TableNatureOfFieldExampleIntegral "Integral", for extensive field with the maximum principle favored over conservativity. Relevant for power fields. - -- \ref TableNatureOfFieldExampleIntegralGlobConstraint "IntegralGlobConstraint", for extensive fields with conservativity favored over the maximum principle. Relevant for power fields. - -The first two correspond to intensive fields, the last two correspond to extensive fields. - -By an intensive field we mean a field that represent an intensive physical variable such as density (\f$kg.m^{-3}\f$), power density (\f$W.m^{-3}\f$), temperature (\f$K\f$) or pressure (\f$Pa\f$). Typically the physical value doesn't scale with the size of the underlying geometry. -By extensive (or integral) field we mean a field that represents an extensive physical quantity such as mass (\f$kg\f$), volume (\f$m^3\f$), a momentum (\f$kg.m.s^{-1}\f$) or power \f$(W\f$). -Typically the field value scales linearly with respect to the underlying geometry size. -For fields with a P0 representation (cell based), conservativity formulas are different depending on whether the field is extensive or intensive (see \ref InterpKerP0P0Int and \ref InterpKerP0P0Ext). -Those two notions are themselves split into two sub-categories. -Indeed in some cases (e.g. non \ref MeshOverlap "overlapping meshes"), it is impossible to fulfill both the conservation principle and the maximum principle during the interpolation. The nature of the fields determine the formula to be used for non overlapping cells and thus the property that we will be satisfied. -Finally we consider that fields with P1 or P2 representations are necessarily intensive. - -\section Usage - -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 -MEDCouplingFieldDouble(NatureOfField n, MEDCouplingTimeDiscretization *td, MEDCouplingFieldDiscretization *type); -\endcode - -If you read or copy an already existing field, or later after its creation, you may want to change/set its nature. -In order to do so, you can use the function - -\code -void setNature(NatureOfField nat); -\endcode - -Here is an example - -\code -... -const char sourceFileName[]="source.med"; -MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); -const char targetFileName[]="target.med"; -MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); -// -sourceField->setNature(ConservativeVolumic); -... -\endcode - -*/ - -/*! - \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 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 - infinite space. This abstract mesh is used as support of fields - containing only one integrated value. This is typically used to - represent fields used by system code. This type of mesh will have - mesh dimension equal to -1. - -The norm used for cells connectivity of different types, is the same as specified in MED file except -that connectivities are in represented in \b C \b format and \b not \b in \b FORTRAN \b format ! - -The class that incarnates the described concept is : ParaMEDMEM::MEDCouplingUMesh. -\n This class inherits from ParaMEDMEM::MEDCouplingPointSet abstract class. -\n So \ref MEDCouplingUMeshPage "MEDCouplingUMesh" inherits from all \ref MEDCouplingPointSetPage "point set features". - -\section MEDCouplingUMeshStdBuild Standard building of an unstructured mesh from scratch - -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 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. - -You can notice that it is possible to mix cell types as long as the dimension of cell is exactly equal to meshDim to respect \ref MEDCouplingMeshes "this rule". - -\subpage medcouplingcppexamplesUmeshStdBuild1 "Here is the C++ implementation." - -\subpage medcouplingpyexamplesUmeshStdBuild1 "Here is the Python implementation." - -\section MEDCouplingUMeshNodalConnectivity How MEDCouplingUMesh stores its nodal connectivity - -\ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh class" stores its nodal connectivity into 2 arrays. - -- The first one, the biggest is ParaMEDMEM::MEDCouplingUMesh::_nodal_connectivity. -- The second one, the less big is ParaMEDMEM::MEDCouplingUMesh::_nodal_connectivity_index. - -\image html MEDCouplingUMeshConn.png "Nodal connectivity storage into MEDCouplingUMesh class" -\image latex MEDCouplingUMeshConn.eps "Nodal connectivity storage into MEDCouplingUMesh class" - -\note The last value of the nodal connectivity index points to an invalid memory place. It is not an error, simply as for standard C++, all ranges -are given in format [\b begin,\b end) where \b begin is included and \b end excluded. - -\section MEDCouplingUMeshAdvBuild Advanced building of an unstructured mesh from scratch - -Here we are going to build the mesh in a more advanced manner. This method expects that the user knows the storage format underlying ParaMEDMEM::MEDCouplingUMesh. - -The same mesh than \ref MEDCouplingUMeshStdBuild "in the standard section above" is going to be implemented using advanced method. - -\subpage medcouplingcppexamplesUmeshAdvBuild1 "Here the C++ implementation." - -\subpage medcouplingpyexamplesUmeshAdvBuild1 "Here the Python implementation." - -*/ - -/*! - \page MEDCouplingPointSetPage Point set meshes in MEDCoupling - -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. -Instantiable class ParaMEDMEM::MEDCouplingUMesh inherits from ParaMEDMEM::MEDCouplingPointSet. - -Some of most important implemented methods by \ref ParaMEDMEM::MEDCouplingPointSet "MEDCouplingPointSet" class are : - -- \ref ParaMEDMEM::MEDCouplingPointSet::getSpaceDimension "getSpaceDimension" -- \ref ParaMEDMEM::MEDCouplingPointSet::getNumberOfNodes "getNumberOfNodes" -- \ref ParaMEDMEM::MEDCouplingPointSet::rotate "rotate" -- \ref ParaMEDMEM::MEDCouplingPointSet::translate "translate" -- \ref ParaMEDMEM::MEDCouplingPointSet::scale "scale" -- \ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes "findCommonNodes" -- \ref ParaMEDMEM::MEDCouplingPointSet::renumberNodes "renumberNodes" -- \ref ParaMEDMEM::MEDCouplingPointSet::getBoundingBox "getBoundingBox" -*/ - -/*! - \page MEDCouplingCMeshPage Cartesian meshes in MEDCoupling - -A cartesian mesh is a mesh that represents structured mesh whose nodes are arranged along axes of trihedron. - -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 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 example of a 2D cartesian mesh. - -\subpage medcouplingcppexamplesCmeshStdBuild1 "Here the C++ implementation." - -\subpage medcouplingpyexamplesCmeshStdBuild1 "Here the Python implementation." - -*/ - -/*! - \page MEDCouplingExtrudedPage 3D Extruded meshes in MEDCoupling - -An extruded mesh is a mesh also called 2.5 D. - -It a convolution of 2D unstructured mesh with 1D unstructured mesh. - -The problem is that this type of mesh is not managed by any file format that's why to build an instance of this mesh you need 3D unstructured mesh and a 2D -unstructured mesh lying on the same coordinates. - -The advantage of this structure is that the interpolation time is highly improved. - -This class is also useful for users that want to map the 3D unstructured mesh cell ids level by level along an axe. - -The class that incarnates this concept in MEDCoupling is : \ref ParaMEDMEM::MEDCouplingExtrudedMesh. -*/ - -/*! - \page MEDCouplingFieldTemplatesPage Field templates in MEDCoupling - -This concept appears in ICOCO API. -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 : - -- a \ref MEDCouplingMeshesPage "mesh" -- a spatial discretization (on cells, on nodes, on gauss points (including localizations, reference elements), ) - -*/ - -/*! - \page MEDCouplingTimeLabelPage Time label in MEDCoupling - -Time label is a **non instanciable** class whose each objects consuming potentially big amount of memory inherit from. -The class that incarnates this concept is ParaMEDMEM::TimeLabel. - -Here some of examples of classes that inherit from \ref ParaMEDMEM::TimeLabel "TimeLabel" class : - -- ParaMEDMEM::DataArrayInt, ParaMEDMEM::DataArrayDouble -- ParaMEDMEM::MEDCouplingMesh -- ParaMEDMEM::MEDCouplingFieldDouble -- ... - -This class is in charge to store a 32 bits unsigned integer called time label, that allows the user to know easily, if an heavy object in memory has been modified or not. - -The usage is simple : - -- call ParaMEDMEM::TimeLabel::getTimeOfThis a first time to retrieve a reference. Store the returned unsigned integer. -- when you need to know if the instance inheriting from ParaMEDMEM::TimeLabel has changed or not simply invoke ParaMEDMEM::TimeLabel::getTimeOfThis again and compare with the stored value. - If the value is different, the instance has changed, if not the instance has **not** changed. - -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/medcouplingexamples.doxy b/doc/doxygen/medcouplingexamples.doxy deleted file mode 100644 index 794b307cd..000000000 --- a/doc/doxygen/medcouplingexamples.doxy +++ /dev/null @@ -1,1985 +0,0 @@ -/*! -\page medcouplingcppexamples MEDCoupling C++ examples - - -\anchor cpp_mcfielddouble_WriteVTK -

Writting fields in a VTK file

- -In this example we -- create an 2D mesh and 3 fields on it, -- use -\ref ParaMEDMEM::MEDCouplingFieldDouble::WriteVTK "WriteVTK()" -to write all the fields and the mesh to a VTK file. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_WriteVTK_1 - - - -\anchor cpp_mcfielddouble_MaxFields -

Getting maximal and minimal fields

- -In this example we -- create two fields with two tuples per two components, -- use -\ref ParaMEDMEM::MEDCouplingFieldDouble::MaxFields "MaxFields()" -to get a field holding maximal values of the two fields. -- use -\ref ParaMEDMEM::MEDCouplingFieldDouble::MinFields "MinFields()" -to get a field holding minimal values of the two fields. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_MaxFields_1 - - -\anchor cpp_mcfielddouble_MergeFields -

Concatenating fields

- -In this example we -- create an 1D mesh and a field on it, -- make a deep copy of the mesh and the field, -- translate the mesh and the field, -- use two variants of -\ref ParaMEDMEM::MEDCouplingFieldDouble::MergeFields "MergeFields()" -to create one field from the two by concatenating them and their meshes. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_MergeFields_1 -The result field is twice "longer" than \b field1. - - - -\anchor cpp_mcfielddouble_substractInPlaceDM -

Subtracting field on different meshs

- -We make two meshes in 1D space with no cells and 4 nodes. Nodes #0 and #2 are swapped -in the two meshes.
-And we make two fields on these meshes, so that fields values to equal to node -coordinates of the underlying meshes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_1 -We are going to subtract \b field2 from \b field1, though they are on -different meshes. -\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" -allows us doing this. We use a mesh comparison level \b levOfCheck = 10 that allows -subtracting fields on meshes with different node arrays.
-\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_2 -After applying -\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" -the both fields lie on \b mesh2. As -\ref ParaMEDMEM::MEDCouplingFieldDouble::substractInPlaceDM "substractInPlaceDM()" -permutes values of \b field1 before value subtraction, and thus \b field1 becomes -equal to \b feild2, hence their subtraction results in a zero field. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_substractInPlaceDM_3 - - - -\anchor cpp_mcfielddouble_changeUnderlyingMesh -

Changing the underlying mesh

- -We make two meshes in 1D space with no cells and 4 nodes. Nodes #0 and #2 are swapped -in the two meshes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_changeUnderlyingMesh_1 -We are going to use -\ref ParaMEDMEM::MEDCouplingFieldDouble::changeUnderlyingMesh "changeUnderlyingMesh()" -to set \b mesh2 instead of \b mesh1 as a support of a field.
-We use -\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic "fillFromAnalytic()" -to make a field on nodes of \b mesh1, so that its values to equal to node coordinates. -Then we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::changeUnderlyingMesh "changeUnderlyingMesh()" -to change the underlying mesh of the \b field. -(We use a mesh comparison level \b levOfCheck = 10 that allows substituting meshes with -different node arrays.) As a result, we expect that values of the \b field are also -permuted same as nodes of the two meshes, and thus its values become equal to the -array \b coords2. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_changeUnderlyingMesh_2 - - -\anchor cpp_mcfielddouble_applyFunc_same_nb_comp -

Changing a field using a formular

- -We create a 2D vector field with 2 tuples and we want to transform this -field using a formular using -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(const char *func) "applyFunc()". -The formular \b func is applied each atomic value of the \b field. We want to change -the \b field as follows. (In \b func, we use the variable "v" to refer to an atomic field value). -- Component #0 = component #0 (remains the same); hence "IVec * v" in \b func. -- Component #1 = component #1 ^ 2; hence "JVec * v*v". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_same_nb_comp_1 -Now we ascertain that the result field is as we expect. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_same_nb_comp_2 - - - -\anchor cpp_mcfielddouble_applyFunc3 -

Changing a field using a formular

- -We create a 2D vector field with 2 values (vectors) and then we transform this -field into a 3D vector field by applying a formular to values of the 2D field -using -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc3() "applyFunc3()". -The formular \b func is applied to components of each vector of the \b field. We want -the \b field to have 3 components computed as follows. (In \b func, we refer to the -first component of a field value using the variable "a", and to the second component, using -the variable "b", as we define it by \b varNamesVec). -- Component #0 = the second vector component; hence "IVec * b" in \b func. -- Component #1 = the first vector component; hence "JVec * a". -- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc3_1 -Now we ascertain that the result field is as we expect. We check the second vector of -the \b field. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc3_2 - - - -\anchor cpp_mcfielddouble_applyFunc2 -

Changing a field using a formular

- -We create a 2D vector field with 2 values (vectors) and then we transform this -field into a 3D vector field by applying a formular to values of the 2D field -using -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc2(int nbOfComp, const char *func) "applyFunc2()". -Note that we set component info the \b array ("a" and "b" ) which will be used to refer to -corresponding components within a function. -The formular \b func is applied to components of each vector of the \b field. We want -the \b field to have 3 components computed as follows. (In \b func, we refer to the -first component of a field value using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second vector component; hence "IVec * b" in \b func. -- Component #1 = the first vector component; hence "JVec * a". -- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc2_1 -Now we ascertain that the result field is as we expect. We check the second vector of -the \b field. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc2_2 - - - -\anchor cpp_mcfielddouble_applyFunc -

Changing a field using a formular

- -We create a 2D vector field with 2 values (vectors) and then we transform this -field into a 3D vector field by applying a formular to values of the 2D field -using -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, const char *func) "applyFunc()". -The formular \b func is applied to components of each vector of the \b field. We want -the \b field to have 3 components computed as follows. (In \b func, we refer to the -first component of a field value using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second vector component; hence "IVec * b" in \b func. -- Component #1 = the first vector component; hence "JVec * a". -- Component #2 = a vector magnitude; hence "KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_1 -Now we ascertain that the result field is as we expect. We check the second vector of -the \b field. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_2 - - - -\anchor cpp_mcfielddouble_applyFunc_val -

Filling a field with a value

- -We want to transform a 2D vector field to a 3D vector field so that all values to be -equal to a certain value. First, we create the 2D mesh and the vector field on it. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_val_1 -Finally we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, double val) "applyFunc()" -to change the number of components and all field values. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_applyFunc_val_2 -As a result, number of tuples in the field equals to the number of cells in the mesh, -and number of components becomes equal to 3 as required. - - -\anchor cpp_mcfielddouble_fillFromAnalytic3 -

Filling a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_1 -Now we create a field on cells and use -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic2 "fillFromAnalytic2()" -to fill it -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want the \b field -to have 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 and checks that values of the second -tuple are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic3_3 - - - -\anchor cpp_mcfielddouble_fillFromAnalytic2 -

Filling a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -Note that we set names to coordinates arrays ("a" and "b" ) which will be used to refer to -corresponding coordinates within a function. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_1 -Now we create a field on cells and use -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic2 "fillFromAnalytic2()" -to fill it -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want the \b field -to have 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 and checks that values of the second -tuple are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic2_3 - - -\anchor cpp_mcfielddouble_fillFromAnalytic -

Filling a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_1 -Now we create a field on cells and use -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, const char *func) "fillFromAnalytic()" -to fill it -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want the \b field to have - 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 to check that values of the second -tuple (#1) are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_fillFromAnalytic_3 - - -\anchor cpp_mcfielddouble_getValueOn_time -

Getting a field value at some point at certain time

- -First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh -constituted by 4 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_1 -Then we create a scalar field on cells, whose values vary linearly in time. -We set all field values at a start time to be equal 10.0 using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". -And we set all field values at an end time to be equal 20.0 by doubling the start -time array. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_2 -Now, we want to get a field value at a point [0,0] at a middle time between the start -and end times. We expect the returned value to be equal to an average of 10. and 20. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_time_3 - - -\anchor cpp_mcfielddouble_getValueOnMulti -

Getting field values at some points

- -First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh -constituted by 4 cells. Then we create a scalar field on cells using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnMulti_1 -Now, we want to retrieve all field values using -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()". -The field values relate to cells, hence we will use cell barycenters as a parameter of -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()". -We expect that the double array returned -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnMulti "getValueOnMulti()" -is equal to that stored by \b field. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnMulti_2 - - - -\anchor cpp_mcfielddouble_getValueOn -

Getting a field value at a point

- -First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh -constituted by 4 cells. Then we create a scalar field on cells using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_1 -Now, we want to retrieve all field values using -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn()". -The field values relate to cells, hence we will use cell barycenters to get a field -value at each cell. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOn_2 -We collected all values returned by -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOn "getValueOn()" in an array, so -that we can ascertain that the array of returned values is same as that stored by \b -field. - - - -\anchor cpp_mcfielddouble_getValueOnPos -

Getting a value of field lying on a structured mesh

- -First, we create a supporting structured mesh. We create a 2x2 Cartesian mesh -constituted by 4 cells. Then we create a scalar field on cells using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnPos_1 -Now, we retrieve a field value relating to the cell #3 (this cell has a structured indexed -(1,1)). For that we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::getValueOnPos "getValueOnPos()" where we -pass the structured indexed of the cell: 1,1,-1 (the last index is meaningless as the -mesh is 2D). -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_getValueOnPos_2 -After all we ascertain that the returned value corresponds to the formular used for -the field creation. Namely that the value equals to the sum of components of -barycenter of cell #3. - - - -\anchor cpp_mcfielddouble_renumberNodes -

Permuting a field on nodes

- -First, we create a supporting 2D mesh constituted by 4 cells. We create a 2x2 -Cartesian mesh and then convert it to an unstructured one, since the Cartesian mesh -is not suitable for -\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberNodes "renumberNodes()" as its - nature does not imply node renumbering. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_1 -Then we create a field on nodes using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()", -such that its values to coincide with coordinates of field location points that are - nodes in our case (as our field is \ref ParaMEDMEM::ON_NODES "ON_NODES"). -At last we ascertain that field values are equal to node coordinates. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_2 -Now, we are going to reverse order of nodes using -\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberNodes "renumberNodes()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberNodes_3 -As a result, the underlying mesh of \b field is changed and its nodes are also - renumbered. -And the field values are still equal to node coordinates of the renumbered \b mesh2. - - - -\anchor cpp_mcfielddouble_renumberCells -

Permuting a field on cells

- -First, we create a supporting 2D mesh constituted by 4 cells. We create a 2x2 -Cartesian mesh and then convert it to an unstructured one, since the Cartesian mesh -is not suitable for -\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberCells "renumberCells()" as its - nature does not imply cell renumbering. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_1 -Then we create a field on cells using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()", -such that its values to coincide with coordinates of field location points that are - cell barycenters in our case (as our field is \ref ParaMEDMEM::ON_CELLS "ON_CELLS"). -At last we ascertain that field values are equal to cell barycenters. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_2 -Now, we are going to reverse order of cells using -\ref ParaMEDMEM::MEDCouplingFieldDouble::renumberCells "renumberCells()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_renumberCells_3 -As a result, the underlying mesh of \b field is changed and its cells are also - renumbered. -And the field values are still equal to cell barycenters of the renumbered \b mesh2. - - - -\anchor cpp_mcfielddouble_buildNewTimeReprFromThis -

Getting a field copy with different time discretization

- -First, we create a supporting 2D mesh and a field on it got using -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic "fillFromAnalytic()". -\ref MEDCouplingTemporalDisc "Time discretization" of this field is -\ref ParaMEDMEM::ONE_TIME "ONE_TIME". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_buildNewTimeReprFromThis_1 -Now we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::buildNewTimeReprFromThis "buildNewTimeReprFromThis()" -to get a copy of \b field1 whose time discretization is -\ref ParaMEDMEM::NO_TIME "NO_TIME". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingFieldDouble_buildNewTimeReprFromThis_2 - - -\anchor cpp_mcmesh_fillFromAnalytic3 -

Creating a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_1 -Now we use -\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic3 "fillFromAnalytic3()" -to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want to get the -field on cells, with 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 and checks that values of the second -tuple are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic3_3 - - - -\anchor cpp_mcmesh_fillFromAnalytic2 -

Creating a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -Note that we set names to coordinates arrays ("a" and "b" ) which will be used to refer to -corresponding coordinates within a function. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_1 -Now we use -\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic2 "fillFromAnalytic2()" -to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want to get the -field on cells, with 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 and checks that values of the second -tuple are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic2_3 - - -\anchor cpp_mcmesh_fillFromAnalytic -

Creating a field using a formular

- -First, we create a 2D Cartesian mesh constituted by 2 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_1 -Now we use -\ref ParaMEDMEM::MEDCouplingMesh::fillFromAnalytic "fillFromAnalytic()" -to get a \ref ParaMEDMEM::MEDCouplingFieldDouble "MEDCouplingFieldDouble" on cells filled -with values computed using a formular \b func. This formular is applied to coordinates of -each point (barycenter) for which the field value is computed. We want to get the -field on cells, with 3 components computed as follows. (In \b func, we refer to the -first component of a point using the variable "a", and to the second component, using -the variable "b"). -- Component #0 = the second coordinate of the point; hence "IVec * b" in \b func. -- Component #1 = the first coordinate of the point; hence "JVec * a". -- Component #2 = distance between the point and SC origin (0.,0.); hence -"KVec * sqrt( a*a + b*b )". - -In addition we want to add 10.0 to each component computed as described above, hence -"10" in \b func. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_2 -Now we ascertain that the result field is as we expect. We check the second tuple of -the \b field. We get barycenter of the cell #1 and checks that values of the second -tuple are computed as we want. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingMesh_fillFromAnalytic_3 - - -\anchor cpp_mccmesh_getCoordsAt -

Getting node coordinates

- -We create an 1D Cartesian mesh and retrieves node coordinates using -\ref ParaMEDMEM::MEDCouplingCMesh::getCoordsAt "getCoordsAt()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingCMesh_getCoordsAt_1 - - - -\anchor cpp_mcumesh_areCellsIncludedIn -

Cells correspondence in two meshes

- -First, we create a 2D \b mesh1 with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_1 -Then we create a \b mesh2 which includes cells #4, #2 and #0 of \b mesh1. The two meshes -share the same node coordinates array. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_2 -Now we ascertain that -- \ref ParaMEDMEM::MEDCouplingUMesh::areCellsIncludedIn "areCellsIncludedIn()" -detects that all cells of \b mesh2 are present in \b mesh1, -- the correspondence array \b corr2to1, which gives cell ids of \b mesh2 within -\b mesh1, is equal to the array \b cells2 which selected cells from \b mesh1 for creation -of \b mesh2. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_3 -Now we apply -\ref ParaMEDMEM::MEDCouplingUMesh::areCellsIncludedIn "areCellsIncludedIn()" -in a reverse direction and ascertain that it returns \c false. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_areCellsIncludedIn_4 -The contents of the correspondence -array \b corr1to2 [2, 3, 1, 4, 0] means the following. -- The cell #0 of \b mesh1 is equal to the cell #2 (== \b corr1to2[ 0 ]) of \b mesh2. -- The cell #1 of \b mesh1 is missing from \b mesh2 (as \b corr1to2[ 1 ] >= \b mesh2->getNumberOfCells()). -- The cell #2 of \b mesh1 is equal to the cell #1 (== \b corr1to2[ 2 ]) of \b mesh2. -- The cell #3 of \b mesh1 is missing from \b mesh2 (as \b corr1to2[ 3 ] >= \b mesh2->getNumberOfCells()). -- The cell #4 of \b mesh1 is equal to the cell #0 (== \b corr1to2[ 4 ]) of \b mesh2. - - -\anchor cpp_mcumesh_checkDeepEquivalWith -

Deep comparison of meshes

- -First, we create two 2D meshes with two triangles, so that -- their nodes are almost same but permuted, -- the first triangle is based exactly on the same nodes (taking the permutation into account), -- an order of nodes in the second triangle is changed. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_1 -Then we check that -- \ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalWith "checkDeepEquivalWith()" -considers the meshes equal (i.e. it does not throw any exception) if it is called with a cell -comparison policy \b cellCompPol == 1 -- mapping from \b mesh1 to \b mesh2 for both nodes and cells is as expected. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_2 -Next we ascertain that -\ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalOnSameNodesWith "checkDeepEquivalOnSameNodesWith()" -consider \b mesh1 and \b mesh2 different as they do not share the same nodal connectivity -array.
-After that we make the meshes share the node coordinates array and insert new -triangles based on the same nodes but in different order. This is to ascertain that -\ref ParaMEDMEM::MEDCouplingUMesh::checkDeepEquivalOnSameNodesWith "checkDeepEquivalOnSameNodesWith()" -called with the weakest cell comparison policy considers the meshes equal. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_checkDeepEquivalWith_3 - - - -\anchor cpp_mcumesh_getPartBarycenterAndOwner -

Getting barycenters of cells

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::getPartBarycenterAndOwner "getPartBarycenterAndOwner()" to get -barycenters of all but the first cell. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_3 -The returned array contains 4 tuples per 2 components. - - -\anchor cpp_mcumesh_findAndCorrectBadOriented3DExtrudedCells -

Fixing orientation of "extruded" volumes

- -First, we create a mesh with 2 incorrectly oriented "extruded" volumes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findAndCorrectBadOriented3DExtrudedCells_1 -Now we check that -\ref ParaMEDMEM::MEDCouplingUMesh::findAndCorrectBadOriented3DExtrudedCells "findAndCorrectBadOriented3DExtrudedCells()" -finds and fixes the reversed cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findAndCorrectBadOriented3DExtrudedCells_2 - - -\anchor cpp_mcumesh_arePolyhedronsNotCorrectlyOriented -

Fixing orientation of polyhedra

- -First, we create a mesh with 2 polyhedra, one of which is incorrectly oriented. We create -two "extruded" polyhedra and then convert them to correctly defined polyhedra. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_arePolyhedronsNotCorrectlyOriented_1 -Now we check that -\ref ParaMEDMEM::MEDCouplingUMesh::arePolyhedronsNotCorrectlyOriented "arePolyhedronsNotCorrectlyOriented()" -finds one reversed cell. After that we fix it using -\ref ParaMEDMEM::MEDCouplingUMesh::orientCorrectlyPolyhedrons "orientCorrectlyPolyhedrons()" and -re-check the orientation of polyhedra. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_arePolyhedronsNotCorrectlyOriented_2 - - -\anchor cpp_mcumesh_are2DCellsNotCorrectlyOriented -

Fixing orientation of faces

- -First, we create a 2D mesh in 3D space with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is -reversed comparing with others. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_are2DCellsNotCorrectlyOriented_1 -Now we check that -\ref ParaMEDMEM::MEDCouplingUMesh::are2DCellsNotCorrectlyOriented "are2DCellsNotCorrectlyOriented()" -finds one reversed face. After that we fix the incorrectly oriented cell using -\ref ParaMEDMEM::MEDCouplingUMesh::orientCorrectly2DCells "orientCorrectly2DCells()" and -re-check the orientation of cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_are2DCellsNotCorrectlyOriented_2 - - -\anchor cpp_mcumesh_getCellsContainingPoints -

Finding cells containing a point (multi-point case)

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoints_1 -Then we use -\ref ParaMEDMEM::MEDCouplingUMesh::getCellsContainingPoints "getCellsContainingPoints()" to -get cells in contact with tree points. Two of them are in contact with some cells and one is not. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoints_2 -The contents of the result arrays \b cells ([4, 0, 1]) and \b cellsIndex ([0, 0, 1, 3]) -mean the following. -- Point #0 is in contact with none (== \b cellsIndx[1] - \b cellsIndx[0]) cell. -- Point #1 is in contact with 1 (== \b cellsIndx[2] - \b cellsIndx[1]) cell whose id is #4 - (== \b cells[ \b cellsIndx[ 1 ]]). -- Point #2 is in contact with 2 (== \b cellsIndx[3] - \b cellsIndx[2]) cells whose ids are #0 - (== \b cells[ \b cellsIndx[ 2 ]]) and #1 (== \b cells[ \b cellsIndx[ 2 ] + 1 ]). - - -\anchor cpp_mcumesh_getCellsContainingPoint -

Finding cells containing a point

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoint_1 -Then we use -\ref ParaMEDMEM::MEDCouplingUMesh::getCellsContainingPoint "getCellsContainingPoint()" to -get cells in contact with a small ball (point with precision) located near the node #4 and -shifted from this node by its radius \b eps. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsContainingPoint_2 -Since the node #4 is shared by all cells, size of the vector \b cellIds must be equal to -the number of cells in \b mesh. - -\anchor cpp_mcumesh_buildPartOrthogonalField -

Getting normals of cells

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is -reversed. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOrthogonalField_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOrthogonalField "buildPartOrthogonalField()" to get -normal vectors to the cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOrthogonalField_2 - - - -\anchor cpp_mcumesh_getPartMeasureField -

Getting volumes of cells

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. Orientation of the cell #1 is -reversed. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::getPartMeasureField "getPartMeasureField()" to get -volumes of all but the first cell. If we call -\ref ParaMEDMEM::MEDCouplingUMesh::getPartMeasureField "getPartMeasureField()" with \b -isAbs == \c true, the area of the cell #1 is returned positive, else, negative that -reflects its inverse orientation. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getPartMeasureField_2 - - - -\anchor cpp_mcumesh_getCellsInBoundingBox -

Getting cells using the bounding box

- -First, we create a 2D mesh with 1 TRI3 cell. Bounding box of this cell is [0.,0., 1.,1]. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsInBoundingBox_1 -Now we check how -\ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" -searches for cells using the bounding box. We use a bounding box touching the bounding box -of the sole cell at one point (1.,1.). -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellsInBoundingBox_2 -If \ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" is -called with parameter \b eps == 0.0, the cell is not found because the two bounding boxes -(one of the cell and the one passed as parameter) do not overlap.
-If \ref ParaMEDMEM::MEDCouplingUMesh::getCellsInBoundingBox "getCellsInBoundingBox()" is -called with parameter \b eps == 0.1, the cell is found because \b eps is used to increase -the bounding box of the cell and thus the two bounding boxes intersect each other.
- -\anchor cpp_mcumesh_renumberNodesInConn -

Renumbering nodes in the connectivity array

- -First, we create a 2D mesh with 1 QUAD4 cell and with undefined coordinates of nodes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodesInConn_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodesInConn "renumberNodesInConn()" -to get the following nodal connectivity of a sole cell: 0,1,2,3. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodesInConn_2 -\b old2newIds array defines how node ids are changed: -- new id of node #0 is -1, -- new id of node #1 is 3, -- new id of node #2 is 4, -- new id of node #3 is 1, -- new id of node #4 is 0. - -\anchor cpp_mcumesh_renumberNodes -

Renumbering nodes

- -First, we create a 2D mesh with 4 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_1 -Next, we use -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()" -to permute nodes so that -- old node #0 becomes #2, -- old node #1 remains #1, -- old node #2 becomes #0, -- old node #3 is removed. - -Number of nodes becomes 3. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_2 - -Next we compare behavior of -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()" and that of -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes2 "renumberNodes2()" which, in contrast to -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes "renumberNodes()", -moves merged nodes to their barycenter.
-We set #2 as new id of old node #3 and expect that -\ref ParaMEDMEM::MEDCouplingUMesh::renumberNodes2 "renumberNodes2()" moves old nodes #0 -and #3 to their barycenter (-0.3,0.0) which becomes position of node #2.
-\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_renumberNodes_3 - - -\anchor cpp_mcumesh_findBoundaryNodes -

Getting boundary nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findBoundaryNodes_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::findBoundaryNodes "findBoundaryNodes()" to get ids -of boundary nodes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_findBoundaryNodes_2 -\ref ParaMEDMEM::MEDCouplingUMesh::findBoundaryNodes "findBoundaryNodes()" returns all -node ids except the node #4 which is in the middle of \b mesh. - - -\anchor cpp_mcumesh_buildBoundaryMesh -

Getting a bounding mesh

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildBoundaryMesh_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::buildBoundaryMesh "buildBoundaryMesh()" to get a mesh -of lower dimension bounding \b mesh. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildBoundaryMesh_2 -Depending on the value of a parameter, -\ref ParaMEDMEM::MEDCouplingUMesh::buildBoundaryMesh "buildBoundaryMesh()" -creates the mesh sharing the node coordinates array with \b mesh or not. - - -\anchor cpp_mcumesh_buildFacePartOfMySelfNode -

Retrieving a lower dimension mesh based on given nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildFacePartOfMySelfNode_1 -In the following code we retrieve nodes of the cell #0 an then we call -\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" -twice with these nodes and with varying last parameter \b allNodes as input. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildFacePartOfMySelfNode_2 -
If the last parameter is \c true -\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" looks -for segements whose all nodes are given to it, hence it finds segments bounding the cell #0 only. -
If the last parameter is \c false -\ref ParaMEDMEM::MEDCouplingUMesh::buildFacePartOfMySelfNode "buildFacePartOfMySelfNode()" looks -for any segment whose nodes are given to it, hence it adds more segments to \b mesh2. - - -\anchor cpp_mcumesh_buildPartOfMySelfNode -

Copying cells selected by nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelfNode_1 -In the following code we retrieve nodes of the cell #0 an then we call -\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" -twice with these nodes and with varying last parameter \b allNodes as input. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelfNode_2 -
If the last parameter is \c true -\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" looks -for cells whose all nodes are given to it, hence it finds the cell #0 only. -
If the last parameter is \c false -\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelfNode "buildPartOfMySelfNode()" looks -for any cell whose nodes are given to it, hence it finds all cells of \b mesh because all -cells share the node #4. - - -\anchor cpp_mcumesh_getCellIdsLyingOnNodes -

Getting cells by nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsLyingOnNodes_1 -In the following code we retrieve nodes of the cell #0 an then we call -\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" -twice with these nodes and with varying last parameter \b allNodes as input. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsLyingOnNodes_2 -
If the last parameter is \c true -\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" looks -for cells whose all nodes are given to it, hence it finds the cell #0 only. -
If the last parameter is \c false -\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsLyingOnNodes "getCellIdsLyingOnNodes()" looks -for any cell whose nodes are given to it, hence it finds all cells of \b mesh because all -cells share the node #4. - - - -\anchor cpp_mcumesh_getCellIdsFullyIncludedInNodeIds -

Getting cells by nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsFullyIncludedInNodeIds_1 -In the following code we retrieve nodes of two cells an then we use -\ref ParaMEDMEM::MEDCouplingUMesh::getCellIdsFullyIncludedInNodeIds -"getCellIdsFullyIncludedInNodeIds()" to find these cells by their nodes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getCellIdsFullyIncludedInNodeIds_2 - - -\anchor cpp_mcumesh_buildPartOfMySelf -

Getting a part of mesh

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelf_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::buildPartOfMySelf "buildPartOfMySelf()" to get a mesh -containing only two cells of \b mesh. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildPartOfMySelf_2 - - -\anchor cpp_mcumesh_mergeNodes -

Merging equal nodes

- -First, we create a 2D mesh with 1 QUAD4 and 2 TRI3 cells. The cells are based on 6 nodes -of which 2 nodes fully coincide (#3 and #4) and 3 nodes are equal with precision 0.003. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_1 -Now we merge node duplicates using -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" and check values it returns. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_2 -Contents of \b arr shows ids of old nodes after the merging. The nodes considered equal -one to the other have the same id in \b arr. - -Next we compare behavior of -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" and that of -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes2 "mergeNodes2()" which, in contrast to -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()", -moves merged nodes to their barycenter.
We expect that -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes2 "mergeNodes2()" moves old nodes #0, #2 -and #5 to their barycenter equal to position of node #2.
-First we check that -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes()" does not move nodes -coincident with the node #2 to the position of node #2, and then we check that -\ref ParaMEDMEM::MEDCouplingUMesh::mergeNodes "mergeNodes2()" does move. -(We check only the second (Y) component of node coordinates since the first component of -these nodes is exactly same.) -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_mergeNodes_3 - - - -\anchor cpp_mcumesh_zipConnectivityTraducer -

Removing cell duplicates

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells, so that -- the cell #2 has the same nodal connectivity as the cell #1 does, -- the cell #3 has the same nodal connectivity as the cell #0 does, -- the cell #4 is based on the same nodes as the cell #0 but nodes order is different. - -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipConnectivityTraducer_1 -Now we use -\ref ParaMEDMEM::MEDCouplingUMesh::zipConnectivityTraducer "zipConnectivityTraducer()" -to remove duplicate cells. Then we check that two cells, having exactly same nodal -connectivity with other cells, have been removed. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipConnectivityTraducer_2 -Contents of \b arr shows ids of cells after duplicates removal. If a value (cell id) -equals to its index in \b arr, this means that the cell is not a duplicate of any cell -with lower id. Else, the value gives a cell id to which this cell is equal.
-Thus, the cells #0 and #1 have no preceding equal cell since \b arr[i] == i.
-The cell #2 equals to the cell #1 (== \b arr[2] ).
-The cell #3 equals to the cell #0 (== \b arr[3] ).
-The cell #4 has no equal cell. This is because the cell comparison technique specified -when we called -\ref ParaMEDMEM::MEDCouplingUMesh::zipConnectivityTraducer "zipConnectivityTraducer()" -was 0 ("exact"), if we had used the technique 2 ("nodal"), \b arr[4] would be 0. - - - -\anchor cpp_mcumesh_zipCoordsTraducer -

Removing unused nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipCoordsTraducer_1 -Now we create \b mesh2 including all nodes but only two cells of \b mesh, and we use \ref -ParaMEDMEM::MEDCouplingUMesh::zipCoordsTraducer "zipCoordsTraducer()" to remove unused -nodes from \b mesh2. -\ref ParaMEDMEM::MEDCouplingUMesh::zipCoordsTraducer "zipCoordsTraducer()" returns an array -with -1 for unused nodes and new ids for used ones. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_zipCoordsTraducer_2 - - - -\anchor cpp_mcumesh_getNodeIdsInUse -

Retrieving unused nodes

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_1 -Now we create \b mesh2 including all nodes but only two cells of \b mesh, and we use \ref -ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" to get nodes of \b mesh2 -used in its two cells. -\ref ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" returns an array -with -1 for unused nodes and new ids for used ones. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_2 -Now we use \b newNbOfNodes returned by -\ref ParaMEDMEM::MEDCouplingUMesh::getNodeIdsInUse "getNodeIdsInUse()" to convert \b arr -to "New to Old" mode. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getNodeIdsInUse_3 - - -\anchor cpp_mcumesh_convertToPolyTypes -

Conversion of cells to "poly" types

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_convertToPolyTypes_1 -Now we convert cells #1 and #3 to type POLYGON and check the result -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_convertToPolyTypes_2 - - -\anchor cpp_mcumesh_buildDescendingConnectivity2 -

Retrieving the descending connectivity with orientation

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_1 -Now we get and check the descending connectivity. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_2 -Here we get connectivity of the cell #2 (#3 in FORTRAN mode) of \b mesh2 to see how -mutual orientation of cells in \b mesh and \b mesh2 is defined. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity2_3 -The contents of the result arrays \b desc and \b descIndx mean the following. -- The cell #0 of \b mesh (QUAD4) is bound by 4 (== \b descIndx[1] - \b descIndx[0]) - segments (SEG2) of \b mesh2 whose ids in FORTRAN mode are - - #1 (== \b desc[ \b descIndx[ 0 ]]), - - #2 (== \b desc[ \b descIndx[ 0 ] + 1 ]), - - #3 (== \b desc[ \b descIndx[ 0 ] + 2 ]) and - - #4 (== \b desc[ \b descIndx[ 0 ] + 3 ]). -
Ids are positive since order of nodes in the corresponding cells of \b mesh and \b mesh2 - are same. For example nodes of SEG2 #3 are [4,1] and nodes of QUAD4 #0 are [0,3,\b 4,\b 1]. -- The cell #1 of \b mesh (TRI3) is bound by 3 (== \b descIndx[2] - \b descIndx[1]) segements of - \b mesh2 whose ids in FORTRAN mode are: - - #-3 (== \b desc[ \b descIndx[ 1 ]]), - - #5 (== \b desc[ \b descIndx[ 1 ] + 1 ]) and - - #6 (== \b desc[ \b descIndx[ 1 ] + 2 ]). -
The id -3 means that order of nodes in SEG2 #3 ([4,1]) is different from the order of - these nodes in TRI3 #1: [\b 1,\b 4,2]. -- etc. - -The contents of the result arrays \b revDesc and \b revDescIndx mean the following. -- The cell #0 of \b mesh2 (SEG2) bounds 1 (== \b revDescIndx[1] - \b revDescIndx[0]) cell of \b - mesh whose id is: - - # 0 (== \b revDesc[ \b revDescIndx[ 0 ]]). -- The cell #1 of \b mesh2 bounds 2 (== \b revDescIndx[2] - \b revDescIndx[1]) cells of \b - mesh whose ids are: - - # 0 (== \b revDesc[ \b revDescIndx[ 1 ]]) and - - # 1 (== \b revDesc[ \b revDescIndx[ 1 ] + 1 ]). -- etc. - - - -\anchor cpp_mcumesh_buildDescendingConnectivity -

Retrieving the descending connectivity

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity_1 -Now we get and check the descending connectivity. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_buildDescendingConnectivity_2 -The contents of the result arrays \b desc and \b descIndx mean the following. -- The cell #0 of \b mesh (QUAD4) is bound by 4 (== \b descIndx[1] - \b descIndx[0]) - segments (SEG2) of \b mesh2 whose ids are - - #0 (== \b desc[ \b descIndx[ 0 ]]), - - #1 (== \b desc[ \b descIndx[ 0 ] + 1 ]), - - #2 (== \b desc[ \b descIndx[ 0 ] + 2 ]) and - - #3 (== \b desc[ \b descIndx[ 0 ] + 3 ]). -- The cell #1 of \b mesh (TRI3) is bound by 3 (== \b descIndx[2] - \b descIndx[1]) segements of - \b mesh2 whose ids are: - - #2 (== \b desc[ \b descIndx[ 1 ]]), - - #4 (== \b desc[ \b descIndx[ 1 ] + 1 ]) and - - #5 (== \b desc[ \b descIndx[ 1 ] + 2 ]). -- etc. - -The contents of the result arrays \b revDesc and \b revDescIndx mean the following. -- The cell #0 of \b mesh2 (SEG2) bounds 1 (== \b revDescIndx[1] - \b revDescIndx[0]) cell of \b - mesh whose id is: - - # 0 (== \b revDesc[ \b revDescIndx[ 0 ]]). -- The cell #1 of \b mesh2 bounds 2 (== \b revDescIndx[2] - \b revDescIndx[1]) cells of \b - mesh whose ids are: - - # 0 (== \b revDesc[ \b revDescIndx[ 1 ]]) and - - # 1 (== \b revDesc[ \b revDescIndx[ 1 ] + 1 ]). -- etc. - - -\anchor cpp_mcumesh_getReverseNodalConnectivity -

Getting the reverse nodal connectivity

- -First, we create a 2D mesh with 3 QUAD4 and 2 TRI3 cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getReverseNodalConnectivity_1 -Now we get and check its reverse nodal connectivity. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingUMesh_getReverseNodalConnectivity_2 -The contents of the result arrays mean the following. -- Node #0 is shared by 1 (== \b revNodalIndx[1] - \b revNodalIndx[0]) cell whose id is #0 - (== \b revNodal[ \b revNodalIndx[ 0 ]]). -- Node #1 is shared by 2 (== \b revNodalIndx[2] - \b revNodalIndx[1]) cells whose ids are #0 - (== \b revNodal[ \b revNodalIndx[ 1 ]]) and #1 (== \b revNodal[ \b revNodalIndx[ 1 ] + 1 ]). -- etc. - -\anchor cpp_mcpointset_scale -

Scaling the mesh

- -First, we create a 2D mesh with 4 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_1 -Then we scale it by a factor of 2 with a center (0.,0.). -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_2 -Finally we check that all node coordinates have changed by more than 0.9. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_scale_3 - - - - -\anchor cpp_mcpointset_translate -

Translating the mesh

- -First, we create a 2D mesh with 4 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_1 -Then we translate it by a vector (1.,1.). -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_2 -Finally we check that all node coordinates have changed by more than 0.9. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_translate_3 - - - -\anchor cpp_mcpointset_rotate -

Rotating the mesh

- -First, we create a 2D mesh with 4 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_1 -Then we rotate it around a point (0.,0.) by 90 degrees clockwise. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_2 -Next, we make a 3D mesh from the 2D one and rotate it around the Z axis by 90 degrees -counter-clockwise. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_3 -Finally we transform the mesh back to 2D space and check that all nodes get back to the -initial location. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_rotate_4 - -\anchor cpp_mcpointset_getBoundingBox -

Getting a minimum box bounding nodes

- -First, we create a 3D mesh with 2 nodes, so that the first one has minimal coordinates and -the second one has maximal coordinates. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getBoundingBox_1 -Now we get a bounding box enclosing these nodes. This bounding box should contain -coordinates of our two nodes (but in "no interlace" mode), as the nodes coincide with -points returned by the bounding box. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getBoundingBox_2 - - -\anchor cpp_mcpointset_getnodeidsnearpoint -

Getting nodes close to a point

- -The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh -"MEDCouplingUMesh" with 5 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoint_1 -Now we define an array of coordinates of a point close to nodes #0, #2 and #4. - -Thus we expect that -\ref ParaMEDMEM::MEDCouplingPointSet::getNodeIdsNearPoint "getNodeIdsNearPoint()" that -we are going to use, -if called with \b eps = 0.003, would return ids of nodes #0, #2 and #4. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoint_2 - - -\anchor cpp_mcpointset_getnodeidsnearpoints -

Getting nodes close to some points

- -The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh -"MEDCouplingUMesh" with 7 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoints_1 -Now we define an array of coordinates of 3 points near which we want to find nodes of the mesh. -- Point #0 is at distance 0.001 from the node #1. -- Point #1 is rather far from all nodes. -- Point #2 is close to nodes #3, #4 and #5. - -Thus we expect that -\ref ParaMEDMEM::MEDCouplingPointSet::getNodeIdsNearPoints "getNodeIdsNearPoints()" that -we are going to use, -if called with \b eps = 0.003, would return ids of close nodes #1, #3, #4 and #5. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getNodeIdsNearPoints_2 -\b idsIndex returns [0, 1, 1, 4] which means that: -- Point #0 is close to 1 (== \b idsIndex[1] - \b idsIndex[0]) node whose id is -\b ids[ \b idsIndex[ 0 ]]. -- Point #1 is close to 0 (== \b idsIndex[2] - \b idsIndex[1]) nodes. -- Point #2 is close to 3 (== \b idsIndex[3] - \b idsIndex[2]) nodes whose ids are -\b ids[ \b idsIndex[ 2 ]], \b ids[ \b idsIndex[ 2 ] + 1 ] and \b ids[ \b idsIndex[ 2 ] + 2 ]. - - -\anchor cpp_mcpointset_findcommonnodes -

Finding coincident nodes

- -First, we create a mesh with 6 nodes, of which two nodes (#3 and #4) are fully coincident -and 3 nodes (#0, #2 and #5) have distance less than 0.004 between them. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_findCommonNodes_1 -Then, we use \ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes()" to find -coincident nodes, and check that (1) calling -\ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes()" with \b prec -== 1e-13 finds the two fully coincident nodes only and (2) -\ref ParaMEDMEM::MEDCouplingPointSet::findCommonNodes() "findCommonNodes"(0.004) finds 5 -equal nodes. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_findCommonNodes_2 - -\anchor cpp_mcpointset_getcoordinatesofnode -

Getting coordinates of a node

- -The following code creates a 2D \ref ParaMEDMEM::MEDCouplingUMesh -"MEDCouplingUMesh" with 3 nodes and no cells. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getCoordinatesOfNode_1 -Here we get coordinates of the second node and check its two coordinates. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_MEDCouplingPointSet_getCoordinatesOfNode_2 - -\anchor cpp_mcdataarrayint_getTuple -

Getting a tuple of DataArrayInt

- -In this simple example we create an array of integers arranged into 3 -tuples per 2 components, and finally print the second tuple. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_getTuple_1 -The output is -
 [9, 10]
-Note that we can traverse all tuples in the array by simply iterating -over it as the code below does. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_getTuple_2 -Its output follows. -
-(7, 8)
-(9, 10)
-(11, 12)
-
- -\anchor cpp_mcdataarrayint_buildpermutationarr -

Building a permutation array

- -Here we create two arrays containing same values but in different order and then we use -\ref ParaMEDMEM::DataArrayInt::buildPermutationArr "DataArrayInt::buildPermutationArr()" to get -an array showing in what places the values of \b b array are located in \b a array. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_buildPermutationArr_1 -The result array \b c contains [1,0,4,2,3]. - -

Inverting renumbering maps

-\anchor cpp_mcdataarrayint_invertarrayo2n2n2o -

invertArrayO2N2N2O()

- -In this example we create a DataArrayInt containing a renumbering map in -"Old to New" mode, convert it into the renumbering map in "New to Old" mode and check the -result. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_invertArrayO2N2N2O_1 - -\anchor cpp_mcdataarrayint_invertarrayn2o2o2n -

invertArrayN2O2O2N()

- -In this example we create a DataArrayInt containing a renumbering map in -"New to Old" mode, convert it into the renumbering map in "Old to New" mode and check the -result. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_invertArrayN2O2O2N_1 - - - -\anchor cpp_mcdataarraydouble_getidsinrange -

Finding values in range in DataArrayDouble

- -In this example we create an array \b da containing same values as ones returned by -\c range( \c 10 ). Then we get an array of indices of values of \b da being in -range [ 2.5, 6 ]. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_getIdsInRange_1 -As result contents of the array \b da2 are as follows. -
-    Tuple #0 : 3
-    Tuple #1 : 4
-    Tuple #2 : 5
-    Tuple #3 : 6
-
- - -\anchor py_mcdataarraydouble_setselectedcomponents -

Set part of values of DataArrayDouble

-

setSelectedComponents()

-First, we create a 'source' array. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents1 -Now we create a larger zero array and assign the array \b da into it. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents2 -As result contents of the array \b dv are as follows. -
-Info of components : "a2"   "a1"   "v3"   "v4"   
-    Tuple #0 : 2 1 0 0 
-    Tuple #1 : 4 3 0 0 
-    Tuple #2 : 6 5 0 0 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way (except that component info -is not copied): -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setSelectedComponents3 - -\anchor py_mcdataarraydouble_setpartofvalues1 -

setPartOfValues1()

-We create two arrays: -- a "large" (4x4) zero array \b da to assign to and -- a smaller (2x2) array \b dv filled with values [7.,8.,9.,10]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_1 -Now we copy \b dv to the middle of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_2 -As result contents of the array \b da are as follows. -
-    Info of components :"v1"   "v2"   "v3"   "v4"
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 8 0 
-    Tuple #2 : 0 9 10 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and copy \b dv into a component of \b da. - -Note that the last parameter \b strictCompoCompare should be \c False -in this case, else \ref ParaMEDMEM::DataArrayDouble::setPartOfValues1() -throws an exception because \b da has 2 components but only one target -component is specified. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 8 0 0 
-    Tuple #2 : 0 9 0 0 
-    Tuple #3 : 0 10 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 8 9 10 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_5 -
-    Tuple #0 : 0 7 0 8 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 9 0 10 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way: -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues1_6 - - - -\anchor py_mcdataarraydouble_setpartofvaluessimple1 -

setPartOfValuesSimple1()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_1 -Now we assign \b dv to the middle of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way: -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple1_6 - - -\anchor py_mcdataarraydouble_setpartofvaluessimple2 -

setPartOfValuesSimple2()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_1 -Now we assign \b dv to the middle of \b da. -We explicitly specify tuples and component to assign to by a list [1,2]. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple2_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValuesSimple2() can't -be explicitly called in Python. - - -\anchor py_mcdataarraydouble_setpartofvaluessimple3 -

setPartOfValuesSimple3()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_1 -Now we assign \b dv to the middle of \b da. -We explicitly specify tuples to assign to by a list [1,2]. And we specify -components to assign to using slicing: 1:3. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValuesSimple3_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValuesSimple3() can't -be explicitly called in Python. - - -\anchor py_mcdataarraydouble_setpartofvalues2 -

setPartOfValues2()

-We create two arrays: -- a "large" (4x7) zero array \b da to assign to, -- a smaller (3x2) array \b dv filled with values [7.,8.,9.,10.,11.,12.]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_1 -Now we assign the two components of \b dv to the components of \b da -with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with - indices [0,1,2]. This is the first mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0  7  0  8  0  0  0  
-    Tuple #1 : 0  9  0 10  0  0  0 
-    Tuple #2 : 0 11  0 12  0  0  0 
-    Tuple #3 : 0  0  0  0  0  0  0
-
-Every value of \b dv has been assigned to its own location within \b da. - -Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. -And we assign \b dv to the tuples of \b da with indices [0,2,3] . -This is the second mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues2_3 -The contents of \b dv have been assigned to each of specified tuples of \b da. -Every value of \b dv is repeated in the 3 specified tuples within \b da. -
-    Tuple #0 : 7  0  8  9 10 11 12
-    Tuple #1 : 0  0  0  0  0  0  0   
-    Tuple #2 : 7  0  8  9 10 11 12
-    Tuple #3 : 7  0  8  9 10 11 12
-
-\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValues2() can't -be explicitly called in Python. - - -\anchor py_mcdataarraydouble_setpartofvalues3 -

setPartOfValues3()

-We create two arrays: -- a "large" (4x7) zero array \b da to assign to, -- a smaller (3x2) array \b dv filled with values [7.,8.,9.,10.,11.,12.]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_1 -Now we assign the two components of \b dv to the components of \b da -with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with -indices [0,1,2] which are specified using slicing: "0:3". -This is the first mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0  7  0  8  0  0  0  
-    Tuple #1 : 0  9  0 10  0  0  0 
-    Tuple #2 : 0 11  0 12  0  0  0 
-    Tuple #3 : 0  0  0  0  0  0  0
-
-Every value of \b dv has been assigned to its own location within \b da. - -Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. -And we assign \b dv to the tuples of \b da with indices [0,2] using \a -slice notation "0:4:2". This is the second mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_setPartOfValues3_3 -The contents of \b dv have been assigned to each of specified tuples of \b da. -Every value of \b dv is repeated in the 3 specified tuples within \b da. -
-    Tuple #0 : 7  0  8  9 10 11 12
-    Tuple #1 : 0  0  0  0  0  0  0   
-    Tuple #2 : 7  0  8  9 10 11 12
-    Tuple #3 : 0  0  0  0  0  0  0   
-
-\note \ref ParaMEDMEM::DataArrayDouble::setPartOfValues3() can't -be explicitly called in Python. - - -\anchor py_mcdataarrayint_setselectedcomponents -

Set part of values of DataArrayInt

-

setSelectedComponents()

-First, we create a 'source' array. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents1 -Now we create a larger zero array and assign the array \b da to it. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents2 -As result contents of the array \b dv are as follows. -
-Info of components : "a2"   "a1"   "v3"   "v4"   
-    Tuple #0 : 2 1 0 0 
-    Tuple #1 : 4 3 0 0 
-    Tuple #2 : 6 5 0 0 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way (except that component info -is not copied): -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setSelectedComponents3 - -\anchor py_mcdataarrayint_setpartofvalues1 -

setPartOfValues1()

-We create two arrays: -- a "large" (4x4) zero array \b da to assign to, and -- a smaller (2x2) array \b dv filled with values [7,8,9,10]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_1 -Now we copy \b dv to the middle of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_2 -As result contents of the array \b da are as follows. -
-    Info of components :"v1"   "v2"   "v3"   "v4"
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 8 0 
-    Tuple #2 : 0 9 10 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and copy \b dv into a component of \b da. - -Note that the last parameter \b strictCompoCompare should be \c False -in this case, else \ref ParaMEDMEM::DataArrayInt::setPartOfValues1() -throws an exception because \b da has 2 components but only one target -component is specified. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 8 0 0 
-    Tuple #2 : 0 9 0 0 
-    Tuple #3 : 0 10 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 8 9 10 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_5 -
-    Tuple #0 : 0 7 0 8 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 9 0 10 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way: -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues1_6 - - - -\anchor py_mcdataarrayint_setpartofvaluessimple1 -

setPartOfValuesSimple1()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_1 -Now we assign \b dv to the middle of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-The same result can be achieved other way: -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple1_6 - - -\anchor py_mcdataarrayint_setpartofvaluessimple2 -

setPartOfValuesSimple2()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_1 -Now we assign \b dv to the middle of \b da. -We explicitly specify tuples and component to assign to by a list [1,2]. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple2_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-\note \ref ParaMEDMEM::DataArrayInt::setPartOfValuesSimple2() can't -be explicitly called in Python. - - -\anchor py_mcdataarrayint_setpartofvaluessimple3 -

setPartOfValuesSimple3()

-We create an array (4x4) \b da to assign to and define a value \b dv to assign. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_1 -Now we assign \b dv to the middle of \b da. -We explicitly specify tuples to assign to by a list [1,2]. And we specify -components to assign to using slicing: 1:3. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 0 7 7 0 
-    Tuple #2 : 0 7 7 0 
-    Tuple #3 : 0 0 0 0 
-
- -Here we re-fill \b da with zeros and assign \b dv to a component of \b da. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_3 -
-    Tuple #0 : 0 7 0 0 
-    Tuple #1 : 0 7 0 0 
-    Tuple #2 : 0 7 0 0 
-    Tuple #3 : 0 7 0 0 
-
-Below more two variants of location of target values are shown. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_4 -
-    Tuple #0 : 0 0 0 0 
-    Tuple #1 : 7 7 7 7 
-    Tuple #2 : 0 0 0 0 
-    Tuple #3 : 0 0 0 0 
-
- -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValuesSimple3_5 -
-    Tuple #0 : 0 7 0 7 
-    Tuple #1 : 0 0 0 0 
-    Tuple #2 : 0 7 0 7 
-    Tuple #3 : 0 0 0 0 
-
-\note \ref ParaMEDMEM::DataArrayInt::setPartOfValuesSimple3() can't -be explicitly called in Python. - - -\anchor py_mcdataarrayint_setpartofvalues2 -

setPartOfValues2()

-We create two arrays: -- a "large" (4x7) zero array \b da to assign to, -- a smaller (3x2) array \b dv filled with values [7,8,9,10,11,12]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_1 -Now we assign the two components of \b dv to the components of \b da -with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with - indices [0,1,2]. This is the first mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0  7  0  8  0  0  0  
-    Tuple #1 : 0  9  0 10  0  0  0 
-    Tuple #2 : 0 11  0 12  0  0  0 
-    Tuple #3 : 0  0  0  0  0  0  0
-
-Every value of \b dv has been assigned to its own location within \b da. - -Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. -And we assign \b dv to the tuples of \b da with indices [0,2,3] . -This is the second mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues2_3 -The contents of \b dv have been assigned to each of specified tuples of \b da. -Every value of \b dv is repeated in the 3 specified tuples within \b da. -
-    Tuple #0 : 7  0  8  9 10 11 12
-    Tuple #1 : 0  0  0  0  0  0  0   
-    Tuple #2 : 7  0  8  9 10 11 12
-    Tuple #3 : 7  0  8  9 10 11 12
-
-\note \ref ParaMEDMEM::DataArrayInt::setPartOfValues2() can't -be explicitly called in Python. - - -\anchor py_mcdataarrayint_setpartofvalues3 -

setPartOfValues3()

-We create two arrays: -- a "large" (4x7) zero array \b da to assign to, -- a smaller (3x2) array \b dv filled with values [7,8,9,10,11,12]. - -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_1 -Now we assign the two components of \b dv to the components of \b da -with indices [1,3], and the 3 tuples of \b dv to the 3 tuples of \b da with -indices [0,1,2] which are specified using slicing: "0:3". -This is the first mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_2 -As result contents of the array \b da are as follows. -
-    Tuple #0 : 0  7  0  8  0  0  0  
-    Tuple #1 : 0  9  0 10  0  0  0 
-    Tuple #2 : 0 11  0 12  0  0  0 
-    Tuple #3 : 0  0  0  0  0  0  0
-
-Every value of \b dv has been assigned to its own location within \b da. - -Now we re-fill \b da with zeros and rearrange \b dv to have 6 components. -And we assign \b dv to the tuples of \b da with indices [0,2] using \a -slice notation "0:4:2". This is the second mode of usage. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayInt_setPartOfValues3_3 -The contents of \b dv have been assigned to each of specified tuples of \b da. -Every value of \b dv is repeated in the 3 specified tuples within \b da. -
-    Tuple #0 : 7  0  8  9 10 11 12
-    Tuple #1 : 0  0  0  0  0  0  0   
-    Tuple #2 : 7  0  8  9 10 11 12
-    Tuple #3 : 0  0  0  0  0  0  0   
-
-\note \ref ParaMEDMEM::DataArrayInt::setPartOfValues3() can't -be explicitly called in Python. - - -\anchor py_mcdataarraydouble_getdifferentvalues -

Excluding coincident tuples from DataArrayDouble

- -The code below creates an array of real values and than an array of - unique values, not closer one to another than 0.2, is retrieved from it. -\snippet MEDCouplingExamplesTest.py Snippet_DataArrayDouble_getDifferentValues1 - - -\anchor cpp_mcdataarraydouble_findcommontuples -

Finding coincident tuples in DataArrayDouble

- -Let's create an array of 6 tuples and 2 components that can be - considered as coordinates of 6 points in 2D space. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_findCommonTuples1 -Now we find points that are not far each from other than 1e-1. -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_findCommonTuples2 -As we can realize from the above code, a hardcoded array \b expected3 is equal - to the raw data of a DataArrayInt \b c and a hardcoded array \b expected4 is equal - to the raw data of the DataArrayInt \b cI. - -The array \b c contains indices of 5 coincident points. The array \b - cI shows us boundaries of (cI->getNumberOfTuples()-1) = 2 groups of coincident points: -- The first group starts at index 0 and includes (3 - 0) = 3 points: 0,3,4. -- The second group starts at index 3 and includes (5 - 3) = 2 points: 1,2. - -\anchor cpp_mcdataarraydouble_meldwith -

Concatenating DataArrayDouble's by appending components

- -In this example we create two data arrays including \b same number of -tuples and then we concatenate them using \ref -ParaMEDMEM::DataArrayDouble::meldWith "meldWith()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayDouble_Meld1_1 -Now the array \b da1 includes 7 tuples (as before) of 3 components -each. Its components are: "c0da1","c1da1","c0da2". - - -\anchor cpp_mcdataarrayint_meldwith -

Concatenating DataArrayInt's by appending components

- -In this example we create two data arrays including \b same number of -tuples and then we concatenate them using \ref -ParaMEDMEM::DataArrayInt::meldWith "meldWith()". -\snippet MEDCouplingExamplesTest.cxx CppSnippet_DataArrayInt_Meld1_1 -Now the array \b da1 includes 7 tuples (as before) of 3 components -each. Its components are: "c0da1","c1da1","c0da2". - - -\anchor py_mcdataarraydouble_KeepSelectedComponents - -

Creation of a sub-part of the DataArrayDouble by selecting components

- -\snippet MEDCouplingExamplesTest.py SnippeDataArrayDoubleKeepSelectedComponents1_1 -We created an array \b a1 containing 5 tuples of 4 components each (20 -values). Now we are going to create an array \b a2 containing some -components of \b a1. -\snippet MEDCouplingExamplesTest.py SnippeDataArrayDoubleKeepSelectedComponents1_2 -Now each tuple of \b a2 includes components named "b","c","b","c","a","a". Thus -the result array \b a2 includes 30 elements (5 tuples per 6 components). - - -\anchor py_mcdataarrayint_keepselectedcomponents - -

Creation of a sub-part of the DataArrayInt by selecting components

- -\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_1 -We created an array \b a1 containing 5 tuples of 4 components each (20 -values). Now we are going to create an array \b a2 containing some -components of \b a1. -\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_2 -Now each tuple of \b a2 includes components named "b","c","b","c","a","a". Thus -the result array \b a2 includes 30 elements (5 tuples per 6 components). - -Note that -\ref ParaMEDMEM::DataArrayInt::keepSelectedComponents() "DataArrayInt::keepSelectedComponents()" -is called, providing the same result, by the following python code: -\snippet MEDCouplingExamplesTest.py SnippeDataArrayIntKeepSelectedComponents1_3 - -\anchor cpp_mcfielddouble_subpart1 - - -

Creation of a sub part of a field

-

Creation of a sub part of a field on cells

-\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_1 -The field on cells \b f1 lies on a mesh containing 5 cells and 9 nodes. -So this field \b f1 contains 5 tuples of 2 components each (10 values). -Now let's create a subfield on cells \b f2 from \b f1. -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_2 - -\b f1 is a field on cells, \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" method performs an extraction on cells too. - -So the array \b part1 lists ids on cells. - -- cell #0 of \b f2 is the same cell of cell #2 of \b f1 -- cell #1 of \b f2 is the same cell of cell #1 of \b f1 -- cell #2 of \b f2 is the same cell of cell #4 of \b f1 - -So \b f2 contains 3 tuples with 2 components. - -The underlying mesh of \b f2 contains a newly created mesh with 3 cells (not as \b mesh1 in \b f1) and 9 nodes (as \b mesh1 in \b f1). -\n For fields on cells the number of tuples of the returned field is always equal to the number of ids given in input (here \b part1). -\nOnly fields on cells have this particular behaviour. - -

Creation of a sub part of a field on nodes

-\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_3 -The field on nodes \b f1 lies on a mesh containing 5 cells and 9 nodes. -So this field \b f1 contains 9 tuples of 2 components each (18 values). -Now let's create a subfield on nodes \b f2 from \b f1. -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuildSubPart1_4 - -\b f1 is a field on nodes, but \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" method performs an extraction on \b cells. - -After the call of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" on node field \b f1, \b f1 will be reduced on a -submesh of \b mesh1 containing cells whoses ids are in \b part2. So here the number of cells of \b f2 is 2 and the number of nodes is 4. -\nSo contrary to fields on cells, it is normal for fields on nodes that number of tuples of the returned field of \ref ParaMEDMEM::MEDCouplingFieldDouble::buildSubPart "buildSubPart" -method does not match the size of the input array (here \b part2). - -*/ - -/*! -\page medcouplingcppexamplesUmeshStdBuild1

Example of standard build of an unstructured mesh from scratch in C++

- -Firstly retrieve basic data in full interlace mode for coordinates, and nodal connectivity cell per cell. -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_1 - -Then create ParaMEDMEM::MEDCouplingUMesh instance giving its meshdimension (2 here) and a name. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_2 - -Gives an upper bound of the number of cells to be inserted into the unstructured mesh. -\n Then enter nodal connectivity of all cells, cell per cell using ParaMEDMEM::MEDCouplingUMesh::insertNextCell method. -\n When the nodal connectivity cell per cell has been finished, call ParaMEDMEM::MEDCouplingUMesh::finishInsertingCells method in order to restore \b mesh instance. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_3 - -At this level the connectivity part of the mesh \b mesh as been defined. Now let's set the coordinates using array \b coords defined above. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_4 - -At this level mesh is usable. When this mesh is no more needed simply call decrRef to decrement its reference counter. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshStdBuild1_5 - -*/ - -/*! -\page medcouplingcppexamplesUmeshAdvBuild1

Example of advanced build of an unstructured mesh from scratch in C++

- -Firstly retrieve basic data in full interlace mode for coordinates, and nodal connectivity cell per cell, cell type \b included (3 for INTERP_KERNEL::NORM_TRI3 and 4 for INTERP_KERNEL::QUAD4). -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_1 - -Then create ParaMEDMEM::MEDCouplingUMesh instance giving its meshdimension (2 here) and a name. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_2 - -Then enter nodal connectivity at once. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_3 - -At this level the connectivity part of the mesh \b mesh as been defined. Now let's set the coordinates using array \b coords defined above. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_4 - -At this level mesh is usable. When this mesh is no more needed simply call decrRef() to decrement its reference counter. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetUMeshAdvBuild1_5 - -*/ - -/*! -\page medcouplingcppexamplesCmeshStdBuild1

Example of standard build of an cartesian mesh from scratch in C++

- -We are going to build a 2D cartesian mesh, constituted from 9 nodes along X axis, and 7 nodes along Y axis. - -Firstly retrieve for each direction the discretization and build a \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble instance" on the corresponding direction. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_1 - -Then create ParaMEDMEM::MEDCouplingCMesh instance giving the 2 instances of \ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" obtained above. - -There are 2 techniques to get it. - -Either : - -\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_2 - -Or : - -\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_2bis - -\c mesh is now available for use : - -\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_3 - -When this mesh is no more needed simply call decrRef to decrement its reference counter. - -\snippet MEDCouplingExamplesTest.cxx CppSnippetCMeshStdBuild1_4 - -*/ - -/*! -\page medcouplingcppexamplesFieldDoubleBuild1

Examples in C++ of standard build of a tensor field on cells with no time attached

- -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_1 - -*/ - -/*! -\page medcouplingcppexamplesFieldDoubleBuild2

Examples in C++ of standard build of a scalar field on nodes with no time attached

- -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild2_1 - -*/ - -/*! -\page medcouplingcppexamplesFieldDoubleBuild3

Examples in C++ of standard build of a vector field on cells with with one time attached and no time interval

- -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild3_1 - -*/ - -/*! -\page medcouplingcppexamplesFieldDoubleBuild4

Examples in C++ of standard build of a vector field on nodes defined on a time interval with a constant value during this interval

- -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild4_1 - -*/ - -/*! -\page medcouplingcppexamplesFieldDoubleBuild5

Examples in C++ of operation that can be carried out on fields on cells

- -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_2 - -The decrementation of ref counter should be carried out in CPlusPlus only ... - -\snippet MEDCouplingExamplesTest.cxx CppSnippetFieldDoubleBuild1_3 - -*/ diff --git a/doc/doxygen/medcouplingexamplescpponly.dox b/doc/doxygen/medcouplingexamplescpponly.dox deleted file mode 100644 index 2049312b9..000000000 --- a/doc/doxygen/medcouplingexamplescpponly.dox +++ /dev/null @@ -1,36 +0,0 @@ -/*! -\page medcouplingexamplescpponly MEDCoupling C++ examples - -\anchor cpp_mcfielddouble_fillFromAnalytic_c_func -

Filling a field using a C function

- -We want to create a 3D vector field lying on a 2D mesh using a C function as a value -generator. For that, first, we define the function that computes 3 values basing on 2 -coordinates of a 2D point. -\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_0 -Then we create the 2D mesh and the field on it, and finally we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::fillFromAnalytic(int nbOfComp, FunctionToEvaluate func) "fillFromAnalytic()" -to fill the field with values each composed of 3 components. -\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_1 -As a result, number of tuples in the field equals to the number of cells in the mesh, -and number of components equals to 3 as required. - - -\anchor cpp_mcfielddouble_applyFunc_c_func -

Changing a field by applying a C function

- -We want to transform a 2D vector field to a 3D vector field by -applying a C function to each vector value. For that, first, we define the function -that computes 3 values basing on 2 components of a 2D vector. -\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_fillFromAnalytic_c_func_0 -Then we create the 2D mesh and the vector field on it. -\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_applyFunc_c_func_1 -Finally we use -\ref ParaMEDMEM::MEDCouplingFieldDouble::applyFunc(int nbOfComp, FunctionToEvaluate func) "applyFunc()" -to change the field values. -\snippet MEDCouplingExamplesTest.cxx Snippet_MEDCouplingFieldDouble_applyFunc_c_func_2 -As a result, number of tuples in the field equals to the number of cells in the mesh, -and number of components becomes equal to 3 as required. - - -*/ diff --git a/doc/doxygen/medloader.dox b/doc/doxygen/medloader.dox deleted file mode 100644 index 98eaa6c06..000000000 --- a/doc/doxygen/medloader.dox +++ /dev/null @@ -1,833 +0,0 @@ -/*! -\page medloader MEDLoader - -[TOC] - -\section MEDLoaderIntro Introduction - -\ref medloader "MEDLoader" is a package in charge of loading from a file or write to a file -in MED format a \ref medcoupling data structure. The fact that these -functionalities are not merged in \ref medcoupling is explained by a -willingness of reducing as much as possible the dependencies of \ref medcoupling libraries. - -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 MEDCouplingMeshesPage "MEDCoupling mesh" is \b not as rich as a MED file mesh, and a \ref MEDCouplingFieldsPage "MEDCoupling field" is \b not as rich as a MED file field. -But it is possible to emulate with a very good fidelity a MED file mesh and a MED file field with a collection of MEDCoupling instances for each. - -\section MEDLoader2Approaches Two approaches are available in MEDLoader : Advanced API, Basic API - -\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 approach" - -Whatever the approach(es) you choose, it is advisable to know main concepts of MED files \ref MEDLoaderMainC "that are quickly reminded here." - -\subsection MEDLoaderAdvApproach Advanced API approach - -\subpage MEDLoaderAdvancedAPIPage "A specific page dedicated to the advanced API is available here". - -This approach is the most close to MED file. By using this advanced API approach the user will manipulates classes that represents MED file concepts. - -It implies that the user should be informed about the \ref MEDLoaderMainC "MED file concepts", that do not exist in \ref medcoupling "MEDCoupling". For example : - -- group/family in meshes -- profiles in fields - -This is typically the case for a user that wants to precisely set/get mesh/group/family groups set on different level. - -*That's why a set of classes representing a memory representation of MED file concepts are proposed by advanced API approach.* - -*So All information contained in file is represented in advanced API class instances.* - -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 particularly recommended : - -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 - -\subpage MEDLoaderBasicAPIPage "A specific page dedicated to the basic API is available here". - -This approach is less close to MED file concepts, but closer to \ref MEDCouplingMainConc "MEDCoupling concepts". - -So, basic API, is simpler as show method MEDLoader::WriteUMesh that needs no special knowledge needed of MED file concepts to interact with MED files. - -This API is in the form of a list of public static methods a class ParaMEDMEM::MEDLoader. - -This simplicity has a cost, the I/O are not (cannot be) optimized. - -As MED file concepts are more complex than MEDCoupling concepts, this approach is not the most relevant for specific MED file objects read/write. - -- Manipulation of multi level MED file mesh is not easy to manipulate with basic approach - -- Manipulation of partial fields in not easy to manipulate too with basic approach - - -\subsection MEDLoaderCohabitationApproach Cohabitation of the two approaches - -The two approaches are \b NOT opposed, they are compatible each other so it is possible to mix them. - -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 - -Here we will describes some of basic concepts of MED files in order to -use the best methods proposed by \ref medloader "MEDLoader API". - -\subsection BasicMEDLoaderAPIGen Basics in 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 : - -\image html MEDFileConcepts.png "Resumed MED file concepts" - -Inside the parenthesis, there is multiplicity : - -- + stands for [1,inf) -- * stands for [0,inf) -- ? stands for 0 or 1 - -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. - -There can be as many instance of boxes as wanted in a MED file. - -**As it can be seen in MED file world, fields and meshes are sorted by geometric type**. - -This specificity leads to a constraint during writing phase because some mesh operations may modify significantly the organization of geometric types during mesh/field operations. -\n Here some of operation that can alter the geometric type order of cells : - -- aggregation of meshes -- aggregation of fields -- extraction of a part of meshes -- extraction of a part of fields -- partial polyhedrization of meshes -- unpolyhedronization of meshes - -\section MEDLoaderCommonVoc Vocabulary used in MEDLoader - -\subsection MEDLoaderCommonVocRelMeshDimMesh Relative mesh dimension in meshes - -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. - -To connect the MED file world to the MEDLoader/MEDCoupling world the notion of **relative mesh dimension** has been introduced in \ref medloader "MEDLoader". - -This concept of **relative mesh dimension** is used frequently in the \ref medloader "MEDLoader both APIs" ( \ref MEDLoaderBasicAPIPage "basic" and \ref MEDLoaderAdvancedAPIPage "advanced"). - -To explain the semantic of **relative mesh dimension** let's take the example of a mesh called \a myMesh in a MED file, containing MED_TRI3, MED_POINT1, MED_POLYHED, MED_TETRA4. - -For each geometric type on which \a myMesh is defined the mesh dimension are : - -- MED_TRI3 -> mesh dimension=2 -- MED_POINT1 -> mesh dimension=0 -- MED_POLYHED -> mesh dimension=3 -- MED_TETRA4 -> mesh dimension=3 - -The mesh dimension of \a myMesh is equal to 3 ( \f max(2,0,3,3) ). The **relative mesh dimension** is equal to the difference between mesh dimension of geometric type and the mesh dimension -of the whole MED file dimension. It leads to the following **relative mesh dimension** : - -- MED_TRI3 -> **relative mesh dimension** = -1 -- MED_POINT1 -> **relative mesh dimension** = -3 -- 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 -MED file data structure of \a myMesh : - -- Level 0 - - MED_TETRA4 - - MED_POLYHED -- Level -1 - - MED_TRI3 -- Level -2 - - nothing -> level **not** available for \a myMesh -- Level -3 - - MED_POINT1 - -The mesh dimension of \a myMesh is 3. The relative mesh dimensions available are 0, -1 and -3. - -\subsection MEDLoaderCommonVocRelMeshDimField Relative mesh dimension in fields - -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. - -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. - -\subsection MEDLoaderCommonVocIterationOrder Iteration and order in MED file - -As seen \ref BasicMEDLoaderAPIGen "above", fields in MED file can be defined on different time steps. - -But there is a **major difference** with \ref medcoupling MEDCoupling concept in time steps. \ref medcoupling MEDCoupling is focused to the float value of time for interpolation reason. - -\ref medloader MEDLoader and MED file are focused on pair of integer to precise a specific time steps. - -This difference of point of view can be seen in the API where the order of returned parameters in python differs from MEDCouplingFieldDouble::getTime to MEDFileField1TS::getTime. - -In MED file and so in \ref medloader MEDLoader the time steps are identified by a pair of integers called : - -- iteration -- order - -Order refers to sub iteration id, that is by default set to -1 in case of non use. A physical time with float type is attached to this pair of integer. - -*/ - -/*! -\page MEDLoaderBasicAPIPage Basic MEDLoader API. - -[TOC] - -The aim of this page is to present basic API of MEDLoader. The goal of -this basic API is to perform a read or a write in one shot without any -internal state. That's why the basic API of MEDLoader offers \b only \b static methods whose method names have the first -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 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 - -instances are stores into components and units into MED files. The -name of meshes and fields are used by MEDLoader to use it as this into -MED file. A field f with \ref ParaMEDMEM::MEDCouplingTimeDiscretization -"time discretization" set to ONE_TIME, the value of -\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 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 - -The MEDLoader::CheckFileForRead method will perform the check of that before any attempt of read. -A field is also discriminated by its name. The method MEDLoader::GetCellFieldNamesOnMesh and MEDLoader::GetNodeFieldNamesOnMesh are available to know all fields -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 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 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. - -Let's recall basic principles that explains some of the aspect of MEDLoade API. -\anchor MEDLoaderMeshNameConstraint MED file can contain several meshes. These meshes are -discriminated by their names (two meshes could not have the same -names). By the same way a MED file can contain several fields in MED. -So MEDLoader propose to you the MEDLoader::GetMeshNames method to -discover all the mesh names contained in your file. - -\section BasicMEDLoaderBasicAPIMesh Reading and writing meshes in MED files using basic API - -In MED file meshes could combine in one unstructured mesh cells that -have different dimension. For example it is possible to mix -MED_TETRA4, MED_TRIA6, MED_SEG2, MED_POINT1, MED_POLYGON, -MED_POLYHEDRA in a same mesh. In MEDCouplingUMesh such a mix is not -allowed as described \ref MEDCouplingUMeshes "here". So to \b read such mesh it -is important to know which meshdimension you are interested to. In API -the parameter \b meshDimRelToMax discreminates the meshdim you are -interested to relatively to the maximal dimension of cells contained -in the mesh in file. - -Let's take 2 examples : - -- If you have a mesh called "MyMesh" in file "file1.med" with -MED_POLYGON, MED_TRI3, MED_SEG2 and MED_SEG3 : The max dimension of -cells is 2 (for MED_POLYGON and MED_TRI3). So if you want exclusively -cells with type MED_POLYGON and MED_TRI3 you should use : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_9 - -If you are interested in MED_SEG2 and MED_SEG3 you should use : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_10 - -The method MEDLoader::ReadUMeshDimFromFile could -help you to have this mesh dimension. -\anchor MEDLoaderExample2 -- Consider an another mesh called "Example2" in file "file2.med" -containing MED_POLYHEDRA, MED_TETRA4, MED_QUAD8, MED_TRI6, MED_SEG2 -and MED_POINT1. In this case you will have : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_8 - -To get 3D cells (MED_POLYHEDRA and MED_TETRA4) you should type : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_7 - -To get 2D cells (MED_TRI6 and MED_QUAD8) you should type : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_4 - -To get 1D cells (MED_SEG2) you should type : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_5 - -And finally for 0D cells (MED_POINT1) you will write : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_6 - -To finish this subsection, it is important to know that MEDLoader -takes into account of the cell numbers stored in a mesh of a med -file. This renumbering allows MEDLoader to conserve the order of -MEDCoupling cells into the file. So if the renumbering of cells in MED -file is not correct an exception will be thrown. - -\subsection BasicMEDLoaderAPIPoMesh Part of meshes in MED files - -A mesh contains one or more families on nodes and/or on cells. A family is a partition -(mathematical sense) of the mesh it lies to. A family can be described -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 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. - -A group is a set of families. So groups can overlap each other, -contrary to families. Groups are also discriminated by a name. As for -families the static method to retrieves the groups of a specified mesh is MEDLoader::GetMeshGroupsNames. - -MEDLoader allows you to retrieve the -corresponding "part of meshes" thanks to static methods -MEDLoader::ReadUMeshFromFamilies and MEDLoader::ReadUMeshFromGroups. -This method allows you to combine several families and groups in the -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 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, 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 -step defined by iteration number 2 and iteration 3 the request will be : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_12 - -To retrieve the same field (same iteration) on 2D cells only the call will be : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_13 - -\subsection MEDLoaderMEDFieldsRead Reading several field time steps at a time in MED files - -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 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 : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_11 - -\section MEDLoaderWriteMain Writing a MED file with MEDLoader - -As MED file does, MEDLoader write process separates clearly -meshes from fields. The reason is that a common use case in write mode -is to write in a first time a mesh and then writes several time steps -of a same field in appended mode. - -The fact that the write process is rarely in a one shot put a -constraint on API to precise to MEDLoader if you intend -to append data to an existing file, or if you want to create a new -file from scratch. This explains the presence of boolean parameter \b -writeFromScratch in API of MEDLoader starting with \b -MEDLoader::Write* . - -If \b writeFromScratch parameter is set to \b true and if the file -already exists the file will be crashed and replaced by the new -corresponding data. If \b writeFromScratch parameter is set to \b false and if the -file does \b not \b exist the new file is created, but if the file -exists MEDLoader will enter in appended mode. - -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 - 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 - by always trying to append data. The consequence of that is that a - read of part (and data processing) of MED file could be needed before any attempt of - writing. So these methods could be in some cases much time and memory consuming. - -The behaviour of MEDLoader when \b writeFromScratch is set to false will be precised -for each \b MEDLoader::Write* methods is the next subsections. - -\subsection MEDLoaderWriteMesh Writing one mesh in a MED file with MEDLoader - -The first think to know is that MEDLoader is using the \b meshName in -ParaMEDMEM::MEDCouplingMesh instance to put it in MED file. - -As explained in previous section \ref MEDLoaderMeshNameConstraint "here", -a mesh in MED file is discriminated by a name, so the \b meshName -\b should \b be \b non \b empty. If it is the case an -INTERP_KERNEL::Exception will be thrown. - -To write one mesh \b myMesh with name \b "myMeshName" in a MED file \b "wfile1.med" the following code should be typed : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_1 - -With the previous code, if "wFile1.med" file existed the file is -crashed and will contain after the call only the content of myMesh -instance. - -If you desire to append a mesh in "wFile1.med" you should type : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_2 - -With the previous code, if the "wFile1.med" had already a mesh called "myMeshName" an -INTERP_KERNEL::Exception will be thrown. - -\subsection MEDLoaderWriteMeshes Writing several meshes in a MED file with MEDLoader - -It could be interesting to write several meshes in one shot. Two -possiblities are possible : - -- Write several instances of ParaMEDMEM::MEDCouplingUMesh - lying \b on \b same \b coords \b with \b different \b mesh \b dimension. In this case the - use of MEDLoader::WriteUMeshes is the method you should - use. Typically this method should be used to write such of file - defined \ref MEDLoaderExample2 "here". - This method first checks that all instances share the same - ParaMEDMEM::DataArrayDouble instance as coords. If not an - INTERP_KERNEL::Exception will be thrown and an invocation on - ParaMEDMEM::MEDCouplingPointSet::tryToShareSameCoords will be necessary. - -- Write a partition of meshes having \b same \b mesh \b dimension, that is to say a set of - 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 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 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. - -For these 2 described methods the semantic of \b writeFromScratch when -\b false is the same, that is to say : no writing -(INTERP_KERNEL::Exception thrown) will be done if the -file already exists and contains already a mesh with name 'meshName' -for MEDLoader::WriteUMeshesPartition method and the name of the first -of the vector of unstructured meshes passed as first parameter of -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 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. - -- When \b writeFromScatch equals to \b false, this method looks that - the underlying mesh exists (by looking the content of \c field->getMesh()->getName() ) in file. If not, the behaviour is the - same that previous case with \b writeFromScratch parameter set to - \b true. If the mesh already exists, MEDLoader reads the field and - tries to apply field on it. This operation could be rather time - consuming because a read operation is performed and a reorder - operation too. If the file already contains the same field at the - same time step (iteration and order ids) the corresponding time step - will be replaced by the field passed in parameter. - -\subsection MEDLoaderWriteFields Writing several time steps of a field in a MED file with MEDLoader - -To write a serie of time steps in a "file3.med" file lying on the same -unstructured mesh the typical code -to write is the following : - -\snippet MEDLoaderExamplesTest.py PySnippetMeshAdvAPI1_3 - -In the previous code, it is important to note that the values of pair -(iteration,order) should be different between two calls to avoid that -a call to MEDLoader::WriteFieldUsingAlreadyWrittenMesh overwrites a -previous call. -An another important thing is the fact that \c f->getMesh() does not be -modified. -This method of writing presents the big advantage to be fast, because -no check neither read is performed by this method. That's why contrary -to other MEDLoader::Write* method the parameter of \b writeFromScratch -is not needed here. - -*/ - -/*! -\page MEDLoaderAdvancedAPIPage Advanced MEDLoader API. - -[TOC] - -This method is much closer to MED file organization than \ref -MEDLoaderBasicAPI "basic MEDLoader API". All MED file -concepts are exposed to the user. As a consequence, this advanced -API is lead to change with MED file data model enhancement. - -In reading mode, the user can scan entirely and directly the content of its MED file as it is organized in its MED file. -Inversely, in writing mode, the user can describe its data in the same -way that MED file does. - -\section AdvMEDLoaderBasics Some of basics of advanced API - -- Like basic %MEDLoader API there is a notion of \c meshDimRelToMax. -Each time This parameter appears in API, it will have the semantic -explain here. -The value of the parameter \c meshDimRelToMax is at most in {0,-1,-2,-3}. This relative value specifies a level -relative to value returned by ParaMEDMEM::MEDFileMesh::getMeshDimension(). - -A mesh containing MED_TETRA4, MED_TRI3, MED_QUAD4 and MED_POINT1 has a meshDimension -equal to 3. For \c meshDimRelToMax equal to 0 the user will -deal with cells whose type has a dimension equal to 3+0, that is to -say here MED_TETRA4. For \c meshDimRelToMax equal to -1 the user will -deal with cells witch dimension equal to 3-1 that is to say MED_TRI3 -and MED_QUAD4. - -An important method is ParaMEDMEM::MEDFileUMesh::getNonEmptyLevels() method. It returns all -non empty levels available. In the previous example, this method will -return {0,-1,-3}. -2 does not appear because no cells with dimension -equal to 1 (3-2) appear in MED file mesh (no MED_SEG2 not MED_SEG3). - -- Besides notion of \c meshDimRelToMax there is notion of \c meshDimRelToMaxExt. -\c meshDimRelToMaxExt is simply an extension of \c meshDimRelToMax for -nodes. - -The parameter of \c meshDimRelToMaxExt appears in -\ref ParaMEDMEM::MEDFileUMesh "umesh advanced API" of %MEDLoader with the following semantics. - -Some of MED file concepts are available both for cells and -nodes, (for example families, groups, numbering ) that's why for a simpler API this -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 described -before. - -- A parameter that also often appears in advanced %MEDLoader API is \c renum. -This parameter by default in advanced %MEDLoader API is set to \c -true. -This parameter indicates if the user intend to take into account -of the renumbering array of cells of the current MED file mesh. -If no renumbering array is defined, this parameter is ignored by -%MEDLoader. - -If such renumbering exists and the \c renum parameter is -set to \c true, then the renumbering is taken into account. This is -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 caution \b for \b users \b concerned \b by \b cells \b orders. - -- 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 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 - current instance already exists, the content is not written and an - exception is thrown. - - 0 : If the file does not exists equivalent to 2. If file already - exists write without any question. If an element with same ids - existed previously the content is overwritten by the content of the - current instance, that can lead to a file corruption. - -\section AdvMEDLoaderAPIMeshesRW Dealing with Meshes with advanced API. - -Contrary to the basic %MEDLoader API, here after reading process, the user -has to deal with a new instance of class that fits the MED file model. -To access to a MEDCoupling mesh the user should request this class -instance. - -\subsection AdvMEDLoaderAPIMeshReading Reading a mesh. - -The class that incarnates Read/Write mesh in MED file is ParaMEDMEM::MEDFileUMesh. - -First of all, like basic %MEDLoader API, only MEDfile files whose version >= 2.2 are able -to be read with advanced API. - -To read a mesh having the name \c meshName in file \c fileName the -following simple code has to be written : - -\code - -MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName,meshName); - -\endcode - -If the user do not know the name of the mesh inside MED file -'fileName' the following code should be written : - -\code - -MEDFileUMesh *myMedMesh=MEDFileUMesh::New(fileName); - -\endcode - -In this case the first mesh (in MED file sense) found in \c fileName -file will be loaded. - -Now the user can ask for mesh dimension of of \c myMedMesh instance by -calling \c myMedMesh->getMeshDimension(). This method returns the -highest level of present cell in MED file mesh \c myMedMesh. -This returned integer is computed and \b not those contained in MED file -that can be invalid. - -\n - -- Retrieving a mesh at a specified relative level \c meshDimRelToMax=mdrm : simply call - - \c myMedMesh->getMeshAtLevel(mdrm) - - or \c myMedMesh->getLevel0Mesh() or \c - myMedMesh->getLevelM1Mesh(), or \c myMedMesh->getLevelM2Mesh() - depending on the value of mdrm - - -- Retrieving a family at a specified level : - - Either an array of node/cell id - - \c getFamilyArr method or \c getFamiliesArr - - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling - - \c getFamily method or \c getFamilies - -- Retrieving a group at a specified level : - - Either an array of node/cell id - - \c getGroupArr method or \c getGroupsArr - - Or on \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" form by calling - - \c getGroup method or \c getGroups - -- Retrieving family field array : -Method \c getFamilyFieldAtLevel retrieves for a specified extended level the -family id of each cell or node. - -- Retrieving renumbering array : -Method \c getNumberFieldAtLevel returns, if it exists for a specified extended level, the -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 explicitly for Groups and -Families. Advanced %MEDLoader API, uses the same order than underlying -mesh at specified level. - -\subsection AdvMEDLoaderAPIMeshReadingSampl Sample of reading a mesh. - -Here a typical use of \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" instance. - -\code - -const char fileName[]=...; -const char meshName[]=...; -MEDFileUMesh *medmesh=MEDFileUMesh::New(fileName,meshName); -std::vector nel=medmesh->getNonEmptyLevels(); -if(nel.size()<1) - throw INTERP_KERNEL::Exception("The test is not good for my file ! Expecting a multi level mesh to play with !"); -MEDCouplingUMesh *m0=medmesh->getMeshAtLevel(nel[1],false); -MEDCouplingUMesh *g1=medmesh->getGroup(nel[1],"mesh2",false); -DataArrayInt *dag1=medmesh->getGroupArr(nel[1],"mesh2",false); -MEDCouplingUMesh *g1bis=m0->buildPartOfMySelf(dag1->getConstPointer(),dag1->getConstPointer()+dag1->getNbOfElems()); -g1bis->setName(dag1->getName()); -if(!g1->isEqual(g1bis,1e-12)) - throw INTERP_KERNEL::Exception("hmmmm :g1 and g1bis should be equal..."); -// -dag1->decrRef(); -g1->decrRef(); -m0->decrRef(); -medmesh->decrRef(); - -\endcode - -\subsection AdvMEDLoaderAPIMeshWriting Writing a mesh. - -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. - -One important point is that coordinates of a mesh are shared by all -cells whatever their level. That's why the -\ref ParaMEDMEM::DataArrayDouble "DataArrayDouble" instance -should be shared by all \ref ParaMEDMEM::MEDCouplingUMesh "MEDCouplingUMesh" used in input parameter of -set* methods. If the user intend to build a \ref ParaMEDMEM::MEDFileUMesh "MEDFileUMesh" instance from -scratch, a call to \c setCoords should be done first. - - -Generally speaking traduce get* methods with set* methods have corresponding write semantic. - -Some differences still exist : - -- \c setMeshAtLevel, \c setMeshAtLevelOld simply call \c setMeshAtLevelGen with repectively \c newOrOld parameter -set to true and false. These method specifies if a renumbering computation is needed or not. \c setMeshAtLevelOld is faster -than \c setMeshAtLevel because no renumbering computation is done. If the user is not warranty about the order of its meshes to enter -it is better to use \c setMeshAtLevel method. - -- Groups definition : Groups constitution is time consuming because of the stored mode chosen by MED file to store them. Groups definition -lead to a partition computation which is time/mem consuming that's why groups should be defined at once and not with addGroup one by one that will lead to -compute a partition for each appended group. One important point to note is that DataArrayInt instance given in input to define groups should have its name -set to the desired group name. If not an exception will be thrown, because MED file does not support groups with no name. - -\subsection AdvMEDLoaderAPIMeshWritingSampl Sample of writing a mesh. - -\code - -MEDCouplingUMesh *m=...; //m is a mesh with meshDim=2 spaceDim=2 -MEDCouplingUMesh *m1=...; //m1 is a mesh with meshDim=1 spaceDim=2 same coords than m -MEDCouplingUMesh *m2=...; //m2 is a mesh with meshDim=0 spaceDim=2 same coords than m -MEDFileUMesh *mm=MEDFileUMesh::New(); -mm->setName("mm");//name needed to be non empty -mm->setDescription("Description mm"); -mm->setCoords(m1->getCoords()); -mm->setMeshAtLevel(-1,m1,false); -mm->setMeshAtLevel(0,m,false); -mm->setMeshAtLevel(-2,m2,false); -DataArrayInt *g1=DataArrayInt::New(); -g1->alloc(2,1); -g1->setName("G1"); -const int val1[2]={1,3}; -std::copy(val1,val1+2,g1->getPointer()); -DataArrayInt *g2=DataArrayInt::New(); -g2->alloc(3,1); -g2->setName("G2"); -const int val2[3]={1,2,3}; -std::copy(val2,val2+3,g2->getPointer()); -// -std::vector grps(2); -grps[0]=g1; grps[1]=g2; -mm->setGroupsAtLevel(0,grps,false); -// -g2->decrRef(); -g1->decrRef(); -// -mm->write(2); - - -\endcode - -\section AdvMEDLoaderAPIFieldRW Dealing with Fields with advanced API. - -In advanced API fields have been developed using divide and conquer pattern to reproduce with the maximal fidelity the MED file field concept \ref BasicMEDLoaderAPIGen "seen here". - -Here the list of classes in %MEDLoader advanced API top down sorted : - -- Level 0 : ParaMEDMEM::MEDFileFields -- Level -1 : ParaMEDMEM::MEDFileFieldMultiTSWithoutSDA -- Level -2 : ParaMEDMEM::MEDFileField1TSWithoutSDA -- Level -3 : ParaMEDMEM::MEDFileFieldPerMesh (present only for backward compatibility MED file 2.2) -- Level -4 : ParaMEDMEM::MEDFileFieldPerMeshPerType -- Level -5 : ParaMEDMEM::MEDFileFieldPerMeshPerTypePerDisc - - -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 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. - -\subsection AdvMEDLoaderAPIFieldR Reading a field - -\subsubsection AdvMEDLoaderAPIFieldRC Reading a field defined on all entity - -Fields defined on all entity are the most used and common fields in MED file world. - -In this mode the user do **not** want to retrieve the entity ids of the constituting subsupport of the whole mesh because it has no sense. - -Let's read a field on all entity called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined -by \a iteration and \a order. - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_1 - -To read it there are 3 main approaches : - -- Use ParaMEDMEM::MEDFileField1TS class : - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_3 - -- Use ParaMEDMEM::MEDFileFieldMultiTS class : - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_4 - -- Use iteration ParaMEDMEM::MEDFileFieldMultiTS class : - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldOnAllEntity1_5 - -\subsubsection AdvMEDLoaderAPIFieldRP Reading a partial field - -Let's read a partial field called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined -by \a iteration and \a order. - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_1 - -Fields defined partially on a meshes can been read using 2 main approaches : - -- 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 - -- Or the user wants to retrieve the binding (cell ids or node ids) with the whole mesh on which the partial field lies partially on. - -\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 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 approach starting from second approach : - -\snippet MEDLoaderExamplesTest.py PySnippetReadFieldPartial1_6 - -\subsection AdvMEDLoaderAPIFieldW Writing a field - -\subsubsection AdvMEDLoaderAPIFieldWC Writing a field defined on all entity - -Fields defined on all entity are the most used and common fields in MED file world. - -In this mode the user do **not** want to retrieve the entity ids of the constituting subsupport of the whole mesh because it has no sense. - -Let's write a cell field on all entity called \a fieldName lying on a mesh called \a meshName in a MED file called \a fname at a iteration defined on time step defined -by \a iteration and \a order. - -\snippet MEDLoaderExamplesTest.py PySnippetWriteFieldOnAllEntity1_2 - -We can see here that the necessity to deal with both mesh and field to write a field is exposed by the API. The mesh write mode is 2 to tell to MED file that is file already exists to scratch it. -The mode of write is 0 to simply add to the file the field specific part. - -\subsubsection AdvMEDLoaderAPIFieldWP Writing a partial field - -\snippet MEDLoaderExamplesTest.py PySnippetWriteFieldPartial1_2 - -To write a partial field \a f can have a **null mesh**, because the link with mesh is made given the entry of \a mm MEDFileField1TS::setFieldProfile method. - - -*/ - diff --git a/doc/doxygen/medpartitioner.dox b/doc/doxygen/medpartitioner.dox deleted file mode 100644 index 434e4687d..000000000 --- a/doc/doxygen/medpartitioner.dox +++ /dev/null @@ -1,37 +0,0 @@ -/*! -\page medpartitioner MEDPartitioner tool - -The purpose of MEDPartitioner is to split MED files into -a series of other MED files forming a partition of the original MED -files. It can either work with serial meshes (1 to n) or distributed -meshes (p to n). For serial meshes, it accepts MED files from the 2.2 -version onwards. For distributed MED files, it accepts MED files from -the 2.3 version onwards. - -It can be used either as an executable, \a medpartitioner or as a library. The partitioning is made thanks to one of the following library : -- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html) -- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_fr.html) - -The arguments to the medpartitioner tool can be retrieved by calling : -\code -medpartitioner --help -\endcode - -There exists a parallel version of MEDPartitioner, which accepts -distributed MED files only. In contrast to the ordinary MEDPartitioner -the parallel one distributes several usual MED files composing the -whole model among available processors. It uses parallel versions of -the partitioning libraries: ParaMETIS and PT-SCOTCH. After the -partitioning each processor writes only it's own part of the -distributed MED file. The parallel MEDPartitioner processes meshes only, -not fields. - -It can be used either as an executable, \a medpartitioner_para or as a library. - -The arguments to the medpartitioner_para tool can be retrieved by calling : -\code -medpartitioner_para --help -\endcode - - -*/ \ No newline at end of file diff --git a/doc/doxygen/remapper.dox b/doc/doxygen/remapper.dox deleted file mode 100644 index e37e89c30..000000000 --- a/doc/doxygen/remapper.dox +++ /dev/null @@ -1,94 +0,0 @@ - -/*! -\page RemapperClasses The REMAPPER class. - -\section InterpKerHighLevUsage High-level usage - -The simplest way of using the \ref interptools in sequential mode is to use the class \c ParaMEDMEM::MEDCouplingRemapper . This class fulfills \c HXX2SALOME rules and may be used in YACS coupling graphs. - -- If you intend to use \ref MEDCoupling data structure, ParaMEDMEM::MEDCouplingRemapper class should be used : - -\code -... -const char sourceFileName[]="source.med"; -MEDCouplingFieldDouble *sourceField=MEDLoader::ReadFieldCell(sourceFileName,"Source_Mesh",0,"Density",/*iteration*/0,/*order*/0); -const char targetFileName[]="target.med"; -MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile(targetFileName,"Target_Mesh",0); -// -sourceField->setNature(ConservativeVolumic);//Specify which formula to use in case of non overlapping meshes -MEDCouplingRemapper remapper; -remapper.setPrecision(1e-12); -remapper.setIntersectionType(INTERP_KERNEL::Triangulation); -remapper.prepare(sourceField->getMesh(),med_target_mesh,"P0P0"); -MEDCouplingFieldDouble *targetField=remapper.transferField(sourceField,/*default_value*/4.57);//Any target cell not intercepted by any source cell will have value set to 4.57. -... -// clean-up -targetField->decrRef(); -sourceField->decrRef(); -med_target_mesh->decrRef(); -\endcode - - -\section InterpKerMidLevUsage Middle-level usage - -This mode is the mode that needs the minimum of prerequisites -(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 -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 data struture is illustrated in the following example. - -\code -... -MEDCouplingUMesh *med_source_mesh=MEDLoader::ReadUMeshFromFile("source.med","Source_mesh",0); -MEDCouplingUMesh *med_target_mesh=MEDLoader::ReadUMeshFromFile("target.med","Target_mesh",0); -MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_source_mesh(med_source_mesh); -MEDCouplingNormalizedUnstructuredMesh<2,2> wrap_target_mesh(med_target_mesh); -// Go for interpolation... -INTERP_KERNEL::Interpolation2D myInterpolator; -myInterpolator.setPrecision(1e-7); -myInterpolator.setIntersectionType(INTERP_KERNEL::Geometric2D); -std::vector > resultMatrix; -INTERP_KERNEL::Matrix resultMatrix2; -// here the interpolation is performed twice for this code to illustrate the possibility of storing data the interpolation matrix in 2 different data structures. -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix,"P0P0"); -myInterpolator.interpolateMeshes(wrap_source_mesh,wrap_target_mesh,resultMatrix2,"P0P0"); -//Ok resultMatrix and resultMatrix2 contain matrix now -... -\endcode - - -- Same with VTK data structure : - -\code -... -vtkXMLUnstructuredGridReader *readerSource=vtkXMLUnstructuredGridReader::New(); -readerSource->SetFileName("source.vtu"); -vtkUnstructuredGrid *vtk_source_mesh=readerSource->GetOutput(); -readerSource->Update(); -vtkXMLUnstructuredGridReader *readerTarget=vtkXMLUnstructuredGridReader::New(); -readerTarget->SetFileName("target.vtu"); -vtkUnstructuredGrid *vtk_target_mesh=readerTarget->GetOutput(); -readerTarget->Update(); -// Ok at this point we have our mesh in VTK format. -// Go to wrap vtk_source_mesh and vtk_target_mesh. -VTKNormalizedUnstructuredMesh<2> wrap_source_mesh(vtk_source_mesh); -VTKNormalizedUnstructuredMesh<2> wrap_target_mesh(vtk_target_mesh); -// Go for interpolation... -INTERP_KERNEL::Interpolation2D myInterpolator; -//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"); -//Ok let's multiply resultMatrix by source field to interpolate to target field. -resultMatrix.multiply(...) -//clean-up -readerSource->Delete(); -readerTarget->Delete(); -... -\endcode - -*/ diff --git a/doc/doxygen/tools.dox b/doc/doxygen/tools.dox deleted file mode 100644 index afa437188..000000000 --- a/doc/doxygen/tools.dox +++ /dev/null @@ -1,100 +0,0 @@ -/*! -\page tools Tools on MED file - -\section Introduction - -There are few executables based on the MEDCoupling and MEDLoader libraries that - help the user to perform -common operations on MED files : -- conversion to other formats, -- splitting of a %MED file to a parallel %MED file distributed over a -number of subdomains. - -\section medpartitioner MEDPartitioner tool - -The purpose of MEDPARTITIONER is to split MED files into -a series of other MED files forming a partition of the original MED -files. It can either work with serial meshes (1 to n) or distributed -meshes (p to n). For serial meshes, it accepts MED files from the 2.1 -version onwards. For distributed MED files, it accepts MED files from -the 2.3 version onwards. - -There exists a parallel version of MEDPARTITIONER, which accepts -distributed MED files only. In contrast to the ordinary MEDPARTITIONER -the parallel one distributes several usual MED files composing the -whole model among available processors. After the -partitioning, each processor writes only it's own part of the -distributed MED file. The parallel MEDPARTITIONER processes meshes only, -not fields. - -It can be used either as an executable, \a medpartitioner (or \a -medpartitioner_para) or as a library. The partitioning is made thanks to -one of the following library : -- METIS (http://glaros.dtc.umn.edu/gkhome/views/metis/index.html) -- SCOTCH (http://www.labri.fr/perso/pelegrin/scotch/scotch_fr.html) - -The arguments to the medpartitioner tool can be retrieved by calling : -\code -medpartitioner --help -\endcode -or -\code -medpartitioner_para --help -\endcode - -For Salome V7.2.0, one gets the following arguments (some of them are -unavailable in parallel version): - -\code -Available options: - --help : produces this help message - --mesh-only : do not create the fields contained in the original file(s) - --distributed : specifies that the input file is distributed - --input-file= : name of the input MED file - --output-file= : name of the resulting file - --meshname= : name of the input mesh (not used with --distributed option) - --ndomains= : number of subdomains in the output file, default is 1 - --plain-master : creates a plain masterfile instead of an XML file - --creates-boundary-faces: creates the necessary faces so that faces joints are created in the output files - --family-splitting : preserves the family names instead of focusing on the groups -\endcode - -\section renumber RENUMBER tool - -The purpose of RENUMBER is to renumber the cell of a mesh in order to -make numerical computation easier. This tool works with meshes -which contain only one cell type and can renumber it according to two -different methods: -- Reverse Cuthill McKee (with the Boost Graph Library http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/table_of_contents.html) -- Nested Dissection (with the METIS library -http://glaros.dtc.umn.edu/gkhome/views/metis/index.html) - -It can be used in this way : -\code -renumber MEDFile_in MeshName Method[BOOST/METIS] MEDFile_out -\endcode - -\section sauv2med sauv2med tool - -The sauv2med tool enable conversion from a Cast3m \a sauv file into a -MED file. It is a python script that encapsulates the read/write -drivers provided by the MEDLoader library. - -Calling -\code -sauv2med myfile.sauv -\endcode -generates a \a med file named \a myfile.sauv.med - -\section med2sauv med2sauv tool - -med2sauv operator is the operator that is inverse of sauv2med. Its -behaviour is symmetrical. - -Calling -\code -med2sauv myfile.med -\endcode -generates a \a sauv file named \a myfile.med.sauv - -*/