]> SALOME platform Git repositories - tools/medcoupling.git/commitdiff
Salome HOME
Documentation update
authoraguerre <aguerre>
Mon, 14 Oct 2013 08:49:09 +0000 (08:49 +0000)
committeraguerre <aguerre>
Mon, 14 Oct 2013 08:49:09 +0000 (08:49 +0000)
17 files changed:
doc/doxygen/BuildPyExamplesFromCPP.py
doc/doxygen/CMakeLists.txt
doc/doxygen/Doxyfile_med_user.in
doc/doxygen/doxfiles/biblio.dox [deleted file]
doc/doxygen/doxfiles/functionalities.dox [new file with mode: 0644]
doc/doxygen/doxfiles/glossary.dox [new file with mode: 0644]
doc/doxygen/doxfiles/gui.dox [new file with mode: 0644]
doc/doxygen/doxfiles/interptools.dox
doc/doxygen/doxfiles/intro.dox
doc/doxygen/doxfiles/library.dox [new file with mode: 0644]
doc/doxygen/doxfiles/medcoupling.dox
doc/doxygen/doxfiles/medloader.dox
doc/doxygen/figures/MedCoupling_Architecture.png [new file with mode: 0644]
doc/doxygen/figures/projectionHQ.png [new file with mode: 0755]
doc/doxygen/figures/projectionHQ_600.png [new file with mode: 0644]
src/MEDOP/doc/sphinx/CMakeLists.txt
src/MEDOP/doc/sphinx/conf.py.in

index d30bc00a1cf1ebd6d2fc9ab6ec2858f226414f71..33ed0d6bd66e23ab548f7b041c42949dce399cac 100644 (file)
@@ -64,6 +64,7 @@ def discardPythonFrom(contents):
     #
 #
 
+# Usage: BuildPyExamplesFromCPP.py <examples.in> <output directory>
 
 fCpp=file(sys.argv[1],"r")
 cppCont=fCpp.readlines() ; del fCpp
@@ -73,7 +74,11 @@ pyCont=Cpp2Python(pyCont)
 
 cppCont=discardPythonFrom(cppCont) # remove Python-only contents from Cpp
 
+# Save CPP and PY examples in two separate dox files
 outFileName=os.path.join(sys.argv[2],os.path.basename(sys.argv[1]))
 
-f=file(os.path.splitext(outFileName)[0]+".dox","w")
-f.writelines(cppCont+pyCont) ; del f
+f=file(os.path.splitext(outFileName)[0]+"CPP.dox","w")
+f.writelines(cppCont) ; del f
+
+f=file(os.path.splitext(outFileName)[0]+"PY.dox","w")
+f.writelines(pyCont) ; del f
index 928d2a6ce133f79a23deae4168a239f5c18a0c6d..5d82000c0d2e6ee328c425750687ee998111f886 100644 (file)
@@ -58,7 +58,7 @@ 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)
+#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.
 
index c6b21a8636aeeed4105ddd323f357ba5596dbe39..4c0349711ea5c89f512db52f3767f0ea0f68618b 100644 (file)
@@ -69,11 +69,22 @@ WARN_LOGFILE           = log_user
 #---------------------------------------------------------------------------
 # configuration options related to the input files
 #---------------------------------------------------------------------------
-INPUT                  = @builddir@ \
-                         @srcdir@/doxfiles \
+
+INPUT                  = @srcdir@/doxfiles/intro.dox \
+                         @srcdir@/doxfiles/glossary.dox \
+                         @srcdir@/doxfiles/library.dox \
+                         @srcdir@/doxfiles/medcoupling.dox \
+                         @srcdir@/doxfiles/medloader.dox \
+                         @srcdir@/doxfiles/interptools.dox \
+                         @srcdir@/doxfiles/functionalities.dox \
+                         @builddir@/medcouplingexamplesPY.dox \
+                         @srcdir@/doxfiles/gui.dox \
+                         @srcdir@/doxfiles/tools.dox \
+                         @builddir@/medcouplingexamplesCPP.dox \
                          @srcdir@/doxfiles/medcoupling \
                          @srcdir@/doxfiles/medloader \
                          @srcdir@/doxfiles/interpolation \
+                         @srcdir@/doxfiles/install.dox \
                          @srcdir@/fakesources \
                          @srcdir@/../../src/ParaMEDMEM \
                          @srcdir@/../../src/INTERP_KERNEL \
@@ -166,7 +177,6 @@ HTML_OUTPUT            = html
 HTML_HEADER            = @builddir@/static/header.html
 HTML_FOOTER            = @srcdir@/static/footer.html
 HTML_EXTRA_STYLESHEET  = @srcdir@/static/salome_extra.css
-HTML_ALIGN_MEMBERS     = YES
 GENERATE_HTMLHELP      = NO
 GENERATE_CHI           = YES
 BINARY_TOC             = NO
@@ -247,17 +257,9 @@ GRAPHICAL_HIERARCHY    = YES
 DOT_PATH               =
 DOT_FONTNAME           = Arial
 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
 #---------------------------------------------------------------------------
 SEARCHENGINE           = NO
-CGI_NAME               = search.cgi
-CGI_URL                =
-DOC_URL                =
-DOC_ABSPATH            =
-BIN_ABSPATH            = /usr/local/bin/
-EXT_DOC_PATHS          =
diff --git a/doc/doxygen/doxfiles/biblio.dox b/doc/doxygen/doxfiles/biblio.dox
deleted file mode 100644 (file)
index 77f7758..0000000
+++ /dev/null
@@ -1,12 +0,0 @@
-/*!
-\page references References
-
-Here follows a list of useful references :
-
--# \anchor RefManualMedFile Reference Manual for Med File, V. Lefebvre,  E. Fayolle, Projet PAL: D&eacute;finition du mod&egrave;le d'&eacute;change de donn&eacute;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&eacute;finition du mod&egrave;le d'&eacute;change de donn&eacute;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/doxfiles/functionalities.dox b/doc/doxygen/doxfiles/functionalities.dox
new file mode 100644 (file)
index 0000000..5ad7dc4
--- /dev/null
@@ -0,0 +1,107 @@
+/*!
+\page functionalities Available functionalities
+
+
+\section directOperations Direct operations on fields
+\subsection directOperations_creation Field creation
+- From scratch: \b New
+
+- Copy: \b clone*, \b deepCpy
+
+\subsection directOperations_modification Partial modifications
+- Creation: \b New, \b setMesh, \b setArray* \n
+  Example 1: \ref medcouplingpyexamplesFieldDoubleBuild1 \n
+  Example 2: \ref medcouplingpyexamplesFieldDoubleBuild2 \n
+  Example 3: \ref medcouplingpyexamplesFieldDoubleBuild3 \n
+  Example 4: \ref medcouplingpyexamplesFieldDoubleBuild4 \n
+
+- Copy
+  - \b buildNewTimeReprFromThis
+  .
+  Example: \ref py_mcfielddouble_buildNewTimeReprFromThis
+
+- Subparts
+  - \b buildSubPart*
+  .
+  Example: \ref py_mcfielddouble_subpart1
+  - \b keepSelectedComponents, \b setSelectedComponents
+
+
+And also:
+
+- Description: \b setName
+
+- I/O: cf. MEDLoader
+
+
+\section arithmeticOperations Local arithmetic
+\subsection arithmeticOperations_scalar Operations on scalars
+- Affectation
+  - From a constant: \b =
+  - From an expression: \b applyFunc* \b applyLin \b fillFromAnalytic* \n
+    Example 1: \ref py_mcfielddouble_applyFunc_same_nb_comp \n
+    Example 2: \ref py_mcfielddouble_applyFunc3 \n
+    Example 3: \ref py_mcfielddouble_applyFunc2 \n
+    Example 4: \ref py_mcfielddouble_applyFunc \n
+    Example 5: \ref py_mcmesh_fillFromAnalytic3 \n
+    Example 6: \ref py_mcmesh_fillFromAnalytic2 \n
+    Example 7: \ref py_mcmesh_fillFromAnalytic \n
+    Example 8: \ref cpp_mcfielddouble_fillFromAnalytic_c_func \n
+    Example 9: \ref cpp_mcfielddouble_applyFunc_c_func
+
+- Addition
+  - \b + \b += \b AddFields
+  .
+  Example: \ref medcouplingpyexamplesFieldDoubleBuild5
+
+- Subtraction
+  - \b \- \b \-= \b SubstractFields
+  - \b substractInPlaceDM
+  .
+  Example: \ref py_mcfielddouble_substractInPlaceDM
+
+- Multiplication
+  - \b * \b *= \b MultiplyFields
+  .
+  Example: \ref medcouplingpyexamplesFieldDoubleBuild5
+
+- Division:
+  - \b / \b /= \b DivideFields
+  .
+  Example: \ref medcouplingpyexamplesFieldDoubleBuild5
+
+- Power: \b ^ \b ^= \b PowFields
+
+\subsection arithmeticOperations_vector Operations on vectors or second order tensors
+- Contracted product: \b doublyContractedProduct
+- Determinant: \b determinant
+- Eigenvalues and eigenvectors: \b eigenValues, \b eigenVectors
+- Tensor inversion: \b inverse
+- Trace: \b trace
+- Deviator: \b deviator
+- Norms: \b norm*
+
+
+\section interpolationOperations Interpolation
+
+
+\section globalOperations Global operations
+- Spatial extrema: \b MaxFields, \b MinFields \n
+  Example: \ref py_mcfielddouble_MaxFields
+
+- Spatial mean: \b getAverageValue
+
+- Temporal extrema
+  - \b getMaxValue*
+  - \b getMinValue*
+
+
+\section otherOperations Others
+- Renumbering a mesh: \b renumber* \n
+  Example 1: \ref py_mcfielddouble_renumberNodes \n
+  Example 2: \ref py_mcfielddouble_renumberCells
+
+- Merge non overlapping fields: \b MergeFields \n
+  Example: \ref py_mcfielddouble_MergeFields
+
+*/
diff --git a/doc/doxygen/doxfiles/glossary.dox b/doc/doxygen/doxfiles/glossary.dox
new file mode 100644 (file)
index 0000000..4653742
--- /dev/null
@@ -0,0 +1,31 @@
+/*!
+\page glossary Concepts and definitions
+
+- \b Mesh: representation of a domain by a set of \b cells and \b nodes. Cells and nodes are named \b entities. There is no notion of edges or faces.
+- The \b dimension \b of \b a \b mesh is characterized by two parameters: the size of the space wherein the mesh is immersed, and the (maximum) size of the mesh cells.
+Examples: 3D surface mesh (3D space, 2D cells), 3D mesh (3D space, 3D cells), curved 2D mesh (2D space, 1D cells)...
+
+- \b Field: physical quantity whose value varies in space and time. Represented by a result vector V obtained from one or more tables of values ​​A, at any point of space covered by a mesh and in time defined by its temporal resolution. The size of V is called the number of \b components (equal to the number of components of A).
+- \b Intensive \b field: represents intensive physical data (i.e. which do not depend on the amount of material).
+Examples: density, power density, temperature, pressure.
+- \b Extensive \b field: represents extensive physical data (i.e. proportional to the size of the physical system represented).
+Examples: mass, volume, time, power.
+- The \b mesh \b support identifies both the mesh and the entity on which it is defined.
+
+- \b Family: partition of a mesh (nodes and cells with the same identifier). Every node or cell can only belong to one family, i.e. the intersection of two families is zero.
+- \b Group: a set of families; two groups may share elements.
+- \b Profile: subset of the entities of a mesh.
+- \b Field \b profile: indicates on which mesh entities field values are located (a field being defined on a part of a mesh).
+
+- The \b connectivity of a mesh represents the kind of connections between its vertices.
+- The \b nodal \b connectivity is the description of a mesh entity by the ordered list of its nodes.
+- The \b descending \b connectivity is the description of N-dimensional mesh entities by the ordered list of (N-1)-dimensional geometrical entities.
+
+- \b Intersector: algorithm that calculates the intersection of two cells from their position and geometry.
+- \b Maximum \b principle: a property of solutions to certain partial differential equations, of the elliptic and parabolic types; it says that the maximum of a function in a domain is to be found on the boundary of that domain.
+- \b Conservativity: preservation of conservation laws governing physical quantities during their discretization or their interpolation.
+- \b Projection: modification (by interpolation) of the entity on which a field is defined. The projection is called \b conservative if the interpolation uses intersection detection. The projection is said \b not \b conservative if the interpolation localizes a cloud of points in a mesh.
+- The \b Gauss \b integration \b points are the geometrical points where the numerical integration of a given quantity is performed. Precise location of these nodes and a sufficient number (related to the approximation order of the integration term) allow for an exact integration in the case of polynomial functions integration.
+- \b Kriging: a linear estimation method guaranteeing minimum variance. The estimate at a given point P is obtained locally from the point values ​​on a neighbourhood of P.
+
+*/
diff --git a/doc/doxygen/doxfiles/gui.dox b/doc/doxygen/doxfiles/gui.dox
new file mode 100644 (file)
index 0000000..170522d
--- /dev/null
@@ -0,0 +1,26 @@
+/*!
+\page gui 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:
+
+- <a class="el" target="_new"
+  href="../../dev/MED/medop-userguide-gui.html">User guide of the MED Graphical Interface (in french)</a>
+
+As a complement, a starter guide to MEDCouplig API is available:
+-  <a class="el" target="_new"
+  href="../../dev/MED/medop-userguide-api.html">Starter guide to MEDCoupling API for users</a>
+
+
+You could also be interested to read the software specifications and
+requirements for this graphical module, and even the technical
+considerations for development:
+
+- <a class="el" target="_new"
+  href="../../dev/MED/medop-specifications.html">Software
+  specifications and requirements of the MED Graphical Interface (in french)</a>
+- <a class="el" target="_new"
+  href="../../dev/MED/medop-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
+
+*/
index b0c1b879b2a4fdfdb1b18d0414ae8431b252b437..6dc4fb55db890e55923672226496aa355dbe9053 100644 (file)
@@ -1,5 +1,5 @@
 /*!
-\page interptools Interpolation tools
+\page interptools Interpolation algorithms
 
 \section Presentation
 The InterpKernel algorithms are part of the MED tool suite. They
index 1eac4dafa6562a9c8281b0666ac9ff73a5c85ac1..f26421311bb12e07230eb568cc64179293e1df38 100644 (file)
@@ -2,59 +2,76 @@
 
 \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
+Simulation studies require the manipulation of meshes and fields for data
+pre-processing, in calculation schemes (including chaining and coupling
+of codes), or even for results post-processing.
+
+Corresponding computer codes can be viewed as software components accessing
+input meshes and fields (with specific constraints) along with parameters
+(datasets), and producing result meshes and fields. Each code presents by
+construction the specificities of its discipline.
+
+The MED module aims at pooling operations on meshes and fields, facilitating
+their use by various codes involved in a simulation process. This includes
+making codes communicate while preserving as much as possible the integrity of
+their content.
+
+To fulfill its objective, the MED module includes:
+- Handling meshes and fields to satisfy code input requirements.
+- Extraction of field information to post-process computation results of
+a code.
+- Projections and serialization to exchange meshes and fields between codes.
+
+In addition, the MED module offers several interfacing levels; users can thus
+benefit from an interaction level adapted to their codes.
+
+Main services offered by MEDCoupling are:
+- Manipulation of fields and their support mesh, serialized with MED format.
+- Operations on scalars, vectors, and second order tensors.
+- 1D/2D/3D interpolation on nodes, cells, Gauss points and nodes by element.
+
+MEDCoupling thus considers:
+- Data dimension.
+- Nature of information on fields, as well as conservation laws.
+- Field profiles and mesh connectivity.
+
+
+\image html projectionHQ_600.png
+<br />
+
+\section contents Contents
+This document is organized as follows:
+- Recall of some basic \ref glossary about mesh and field manipulation.
+- \ref library 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:
+- Technical presentation of \ref medcoupling that describes DataStructures
+used for cross process exchange of meshes and fields.
+- Technical presentation of \ref medloader that provides I/O functions to the
+MED file format.
+- \ref interptools, from theory to practice using MEDCoupling.
+- Summary of  \ref functionalities "available functionalities".
+- \ref medcouplingpyexamples and tutorials.
+- \ref gui that exhibits some useful functions of the library for a graphical
+manipulation of data in standard use cases.
+- \ref tools based on MEDLoader that can be used to process MED data files
+(conversion tools and splitting tools).
+- \ref medcouplingcppexamples for advanced users.
 
-- <a class="el" target="_new"
-  href="../../dev/MED/medop-userguide.html">User guide of the MED Graphical Interface (in french)</a>
-
-You could also be interested to read the software specifications and
-requirements for this graphical module, and even the technical
-considerations for development:
-
-- <a class="el" target="_new"
-  href="../../dev/MED/medop-specifications.html">Software
-  specifications and requirements of the MED Graphical Interface (in french)</a>
-- <a class="el" target="_new"
-  href="../../dev/MED/medop-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
-
-\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.
+installing the module can be found in \ref paramedmem_install.
+
+
+\section references References
+Here follows a list of useful references :
+
+-# \anchor RefManualMedFile Reference Manual for Med File, V. Lefebvre,  E. Fayolle, Projet PAL: D&eacute;finition du mod&egrave;le d'&eacute;change de donn&eacute;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&eacute;finition du mod&egrave;le d'&eacute;change de donn&eacute;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/doxfiles/library.dox b/doc/doxygen/doxfiles/library.dox
new file mode 100644 (file)
index 0000000..867b7a3
--- /dev/null
@@ -0,0 +1,22 @@
+/*!
+\page library A library of functions for data processing
+
+The figure below represents the layer structure of the packages of the
+library.\n
+Each element depends on the blocks it covers (fully or partially).\n
+White blocks represent system or external dependencies.\n
+MEDCalc block, with gray background color, is the \ref gui "Graphical User Interface".
+\n
+Red-colored text identifies code with Swig interfaces.\n
+Blue-colored text identifies code with both Swig interfaces and CORBA layer.
+
+\image html MedCoupling_Architecture.png
+
+The fundamentals (blue background) consists in three atomic libraries:
+
+- \ref medcoupling that describes DataStructures used for cross process exchange of meshes and fields.
+- \ref medloader and ParaMEDLoader that provides I/O functions to the MED file format with sequential and parallel processing, respectively.
+- \ref interptools that provides mathematical structures and algorithms for interpolation and
+  localization. It concerns three blocks: \ref INTERP_KERNEL "InterpKernel", \ref ParaMEDMEM::MEDCouplingRemapper "Remapper" and ParaMEDMEM (Remapper with parallel processing).
+
+*/
index bc91f179ec2dfc9543f9bb5498e4a8418f27afe8..fdbbbe7b3a42f13004ef36a9383a8d776bf35fe4 100644 (file)
@@ -3,30 +3,30 @@
 
 \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.
+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 :
+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
+- minimize as much as possible the number of prerequisites needed to use it ; So 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".
+   - to ease implementation of clients of 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.
+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".
+Here are listed basic concepts present into MEDCoupling.
 
-For beginners in \ref medcoupling "MEDCoupling" world, it is advisable to read the following concepts in the same order than the underlying list.
+For beginners in MEDCoupling world, it is advisable to read the following concepts in the same order than the underlying list.
 
 - \subpage MEDCouplingArrayPage "DataArrays"
 - \subpage MEDCouplingMeshesPage "Meshes"
index 90da44d0125f3b15c3113e44e2648caf5cd449c7..92fe1099bc1834a5d5e800c3b571ec98dcd40a5c 100644 (file)
@@ -17,20 +17,38 @@ 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
+\section MEDLoader2Approaches Two approaches
 
 \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"
+- \ref MEDLoaderAdvApproach "advanced 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 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 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.
+This approach is the closest 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 :
 
@@ -50,24 +68,6 @@ 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
 
diff --git a/doc/doxygen/figures/MedCoupling_Architecture.png b/doc/doxygen/figures/MedCoupling_Architecture.png
new file mode 100644 (file)
index 0000000..23ee26b
Binary files /dev/null and b/doc/doxygen/figures/MedCoupling_Architecture.png differ
diff --git a/doc/doxygen/figures/projectionHQ.png b/doc/doxygen/figures/projectionHQ.png
new file mode 100755 (executable)
index 0000000..26cb913
Binary files /dev/null and b/doc/doxygen/figures/projectionHQ.png differ
diff --git a/doc/doxygen/figures/projectionHQ_600.png b/doc/doxygen/figures/projectionHQ_600.png
new file mode 100644 (file)
index 0000000..d28a93c
Binary files /dev/null and b/doc/doxygen/figures/projectionHQ_600.png differ
index 7bbc16616e648292f66f05c8d3867f5cc173b7cc..174796f708392c89e541c3b4cb3107996e355995 100644 (file)
 # See http://www.salome-platform.org/ or email : webmaster.salome@opencascade.com
 #
 
-IF(SPHINX_STATUS)
-  SET(srcdir ${CMAKE_CURRENT_SOURCE_DIR})
-  CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/conf.py.in ${CMAKE_CURRENT_BINARY_DIR}/conf.py @ONLY)
+# This file mainly prepares the environment in which sphinx should run:
+#  this sets the PYTHONPATH and LD_LIBRARY_PATH to include OMNIORB, DOCUTILS, SETUPTOOLS, etc ...
 
-  INSTALL(CODE "EXECUTE_PROCESS(COMMAND ${SPHINX_EXECUTABLE_TO_FIND} -c ${CMAKE_CURRENT_BINARY_DIR} -b html -d doctrees -D latex_paper_size=a4 ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR}/html)")
+# Prepare Sphinx options
+SET(SPHINXOPTS
+)
+SET(srcdir ${CMAKE_CURRENT_SOURCE_DIR})
+SET(PAPEROPT_a4
+  -D latex_paper_size=a4
+)
+SET(ALLSPHINXOPTS
+  -d doctrees
+  ${PAPEROPT_a4}
+  ${SPHINXOPTS}
+  ${srcdir}
+)
 
-  INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION share/doc/salome/dev/MED)
+SALOME_CONFIGURE_FILE(conf.py.in conf.py)
 
-ENDIF(SPHINX_STATUS)
+# Write the shell file preparing the env for the Sphinx run:
+#    This uses the paths to SPHINX, DOCUTILS and SETUPTOOLS:
+#    Their root dir were found when looking for Sphinx (FindSalomeSphinx.cmake):
+
+SET(_pydir python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
+IF(WINDOWS)
+  STRING(REPLACE "/" "\\" SCR "@SET PYTHONPATH=${CMAKE_INSTALL_PREFIX}\\lib\\${_pydir}\\site-packages\\salome\;%PYTHONPATH%
+  @SET PYTHONPATH=${CMAKE_INSTALL_PREFIX}\\bin\\salome\;%PYTHONPATH%
+  @SET PATH=${CMAKE_INSTALL_PREFIX}\\lib\\salome\;%PATH%
+  @SET PYTHONPATH=${CMAKE_INSTALL_PREFIX}\\${SALOME_INSTALL_PYTHON}\;%PYTHONPATH%
+  @SET PYTHONPATH=${CMAKE_INSTALL_PREFIX}\\${SALOME_INSTALL_PYTHON_SHARED}\;%PYTHONPATH%
+  @SET PYTHONPATH=${HDF5_ROOT_DIR}\\lib\;%PYTHONPATH%
+  @SET PYTHONPATH=${MPI_ROOT_DIR}\\lib\;%PYTHONPATH%
+
+  @SET PYTHONPATH=${KERNEL_ROOT_DIR}\\bin\\salome\;%PYTHONPATH%
+  @SET PATH=${KERNEL_ROOT_DIR}\\lib\\salome\;%PATH%
+  @SET PYTHONPATH=${KERNEL_ROOT_DIR}\\${SALOME_INSTALL_PYTHON}\;%PYTHONPATH%
+  @SET PYTHONPATH=${KERNEL_ROOT_DIR}\\${SALOME_INSTALL_PYTHON_SHARED}\;%PYTHONPATH%
+
+  @SET PYTHONPATH=${OMNIORB_ROOT_DIR}\\lib\\x86_win32\;%PYTHONPATH%
+  @SET PYTHONPATH=${OMNIORB_ROOT_DIR}\\lib\\python\;%PYTHONPATH%
+  @SET PATH=${OMNIORB_ROOT_DIR}\\lib\\x86_win32\;%PATH%
+  ")
+  SET(EXT "bat")
+  SET(CALL_STR "call")
+ELSE(WINDOWS)
+  SET(SCR  " export PYTHONPATH=${CMAKE_INSTALL_PREFIX}/lib/${_pydir}/site-packages/salome:\${PYTHONPATH}
+  export PYTHONPATH=${CMAKE_INSTALL_PREFIX}/bin/salome:\${PYTHONPATH}
+  export LD_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib/salome:\${LD_LIBRARY_PATH}
+  export PYTHONPATH=${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_PYTHON}:\${PYTHONPATH}
+  export PYTHONPATH=${CMAKE_INSTALL_PREFIX}/${SALOME_INSTALL_PYTHON_SHARED}:\${PYTHONPATH}
+  export PYTHONPATH=${HDF5_ROOT_DIR}/lib:\${PYTHONPATH}
+  export PYTHONPATH=${MPI_ROOT_DIR}/lib:\${PYTHONPATH}
+
+  export PYTHONPATH=${KERNEL_ROOT_DIR}/bin/salome:\${PYTHONPATH}
+  export LD_LIBRARY_PATH=${KERNEL_ROOT_DIR}/lib/salome:\${LD_LIBRARY_PATH}
+  export PYTHONPATH=${KERNEL_ROOT_DIR}/${SALOME_INSTALL_PYTHON}:\${PYTHONPATH}
+  export PYTHONPATH=${KERNEL_ROOT_DIR}/${SALOME_INSTALL_PYTHON_SHARED}:\${PYTHONPATH}
+
+  export PYTHONPATH=${OMNIORB_ROOT_DIR}/lib:\${PYTHONPATH}
+  export PYTHONPATH=${OMNIORB_ROOT_DIR}/lib/${_pydir}/site-packages:\${PYTHONPATH}
+  export PYTHONPATH=${OMNIORB_ROOT_DIR}/lib64/${_pydir}/site-packages:\${PYTHONPATH}
+  export PYTHONPATH=${OMNIORBPY_ROOT_DIR}/lib:\${PYTHONPATH}
+  export PYTHONPATH=${OMNIORBPY_ROOT_DIR}/lib/${_pydir}/site-packages:\${PYTHONPATH}
+  export PYTHONPATH=${OMNIORBPY_ROOT_DIR}/lib64/${_pydir}/site-packages:\${PYTHONPATH}
+  export LD_LIBRARY_PATH=${OMNIORB_ROOT_DIR}/lib:\${LD_LIBRARY_PATH}
+  export PYTHONPATH=${SETUPTOOLS_ROOT_DIR}/lib/${_pydir}/site-packages:\${PYTHONPATH}
+  export PYTHONPATH=${DOCUTILS_ROOT_DIR}/lib/${_pydir}/site-packages:\${PYTHONPATH}
+  export PYTHONPATH=${SPHINX_ROOT_DIR}/lib/${_pydir}/site-packages:\${PYTHONPATH}
+"
+  )
+  SET(EXT "sh")
+  SET(CALL_STR ".")
+ENDIF(WINDOWS)
+
+FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/env_s.${EXT} "${SCR}")
+
+ADD_CUSTOM_TARGET(html_docs ${CALL_STR} ${CMAKE_CURRENT_BINARY_DIR}/env_s.${EXT} && ${SPHINX_EXECUTABLE} -c ${CMAKE_CURRENT_BINARY_DIR} -b html ${ALLSPHINXOPTS} ${CMAKE_CURRENT_BINARY_DIR}/html)
+
+INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target html_docs)")
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${SALOME_INSTALL_DOC}/dev/MED)
index 9fb23d4326ea0ebb4e7c0dbba91a48d9eb5895f6..83474ef37a7fc61389ed213740fc589177c5451b 100644 (file)
@@ -47,7 +47,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = 'MED, Manipulation de champs dans SALOME'
-copyright = '2010 CEA/DEN, EDF R&D, G. Boulant, A. Geay'
+copyright = '2010 CEA/DEN, EDF R&D, OPEN CASCADE, G. Boulant, A. Geay'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -60,7 +60,7 @@ release = '@VERSION@'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
-language = 'en'
+language = 'fr'
 
 # There are two options for replacing |today|: either, you set today to some
 # non-false value, then it is used: