ADD_DEPENDENCIES(usr_docs tutorial_doc)
#INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target tutorial_doc)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial)
-INSTALL(DIRECTORY images/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial/images)
-INSTALL(DIRECTORY data/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED/tutorial/data)
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/tutorial)
+INSTALL(DIRECTORY images/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/tutorial/images)
+INSTALL(DIRECTORY data/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/tutorial/data)
SET(make_clean_files html doctrees)
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${make_clean_files}")
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+#html_static_path = ['_static']
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
ENDIF()
#INSTALL(CODE "EXECUTE_PROCESS(COMMAND \"${CMAKE_COMMAND}\" --build ${PROJECT_BINARY_DIR} --target usr_docs)")
-INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doc_ref_user/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED)
-INSTALL(FILES images/head.png DESTINATION ${MEDCOUPLING_INSTALL_DOC}/gui/MED)
+INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doc_ref_user/html/ DESTINATION ${MEDCOUPLING_INSTALL_DOC})
+INSTALL(FILES images/head.png DESTINATION ${MEDCOUPLING_INSTALL_DOC})
SET(MAKE_CLEAN_FILES doc_ref_user tmp)
SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES "${MAKE_CLEAN_FILES}")
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/faq.dox \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/start \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/tutorial.dox \
- @CMAKE_CURRENT_SOURCE_DIR@/doxfiles/gui.dox \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference/arrays \
@CMAKE_CURRENT_SOURCE_DIR@/doxfiles/reference/meshes \
@PROJECT_SOURCE_DIR@/src/INTERP_KERNEL/Bases \
@PROJECT_SOURCE_DIR@/src/INTERP_KERNEL/Geometric2D \
@PROJECT_SOURCE_DIR@/src/MEDCoupling \
- @PROJECT_SOURCE_DIR@/src/MEDLoader \
- @PROJECT_SOURCE_DIR@/src/MEDCouplingCorba
+ @PROJECT_SOURCE_DIR@/src/MEDLoader
FILE_PATTERNS = InterpKernelDEC.* \
OverlapDEC.* \
#---------------------------------------------------------------------------
# Configuration::additions related to the search engine
#---------------------------------------------------------------------------
-SEARCHENGINE = NO
+SEARCHENGINE = YES
+++ /dev/null
-/*!
-\page gui Graphical user interface
-
-<h1>A graphical interface for standard use cases</h1>
-
-The MED module in SALOME comes with a graphical interface that helps
-you deal with the most standard use cases of field manipulation. The
-user guide can be found here:
-
-- <a class="el" target="_new"
- href="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-userguide-gui.html">User guide of the MED Graphical Interface</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="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-specifications.html">Software
- specifications and requirements of the MED Graphical Interface (in french)</a>
-- <a class="el" target="_new"
- href="${MED_ROOT_DIR}/share/doc/salome/dev/MED/medcalc-develguide.html">Developer guide of the MED Graphical Interface (in french)</a>
-
-*/
\mainpage Welcome to MEDCoupling!
-The MED module gathers several powerful functionalities around the input and output data of
+The MEDCoupling tool gathers several powerful functionalities around the input and output data of
simulation codes (meshes and fields mainly).
\image html projectionHQ_600.png "Example of a field interpolation between two 3D surfacic meshes"
-The most common usage is to write dedicated code (C++ or Python) linking to the library,
-however a \ref gui "graphical user interface" is also available.
+The most common usage is to write dedicated code (C++ or Python) linking to the library. However a graphical user interface is also available; for this please refer to the MED module documentation.
- If you don't know where to start, reading the \ref start "getting started" section and then
taking a look at the <a class="el" href="tutorial/index.html">tutorial</a> is probably a good way to go.
- \ref functionalities
- \ref python-api
- <a class="el" href="tutorial/index.html">Tutorial - MEDCoupling/MEDLoader in Python</a>
-- \ref gui
- \ref reference
- \ref medcoupling
- \ref medloader
/*!
\page corba-distrib Distribution in MEDCoupling using CORBA
-The following classes allow to publish \ref medcoupling "MEDCoupling objects" on the CORBA bus. They are
-directly related to the equivalent class in MEDCoupling, without the string \c Servant at the end of the
-name:
+The following classes allow to publish \ref medcoupling "MEDCoupling objects" on the CORBA bus.
+They are provided in the SALOME MED module that contains elements for the integration of MEDCoupling in SALOME.
+They are directly related to the equivalent class in MEDCoupling, without the string \c Servant at the end of the
+name:
- \ref ParaMEDMEM::DataArrayDoubleServant "DataArrayDoubleServant"
- \ref ParaMEDMEM::DataArrayIntServant "DataArrayIntServant"
TODO: complete the list.
-*/
\ No newline at end of file
+*/
\page library The MED constellation: MEDCoupling, MEDLoader, MED file, etc ...
\section lib-termino Who's who?
-The library and the module have evolved over the years, raising
+The library and the module have evolved over the years, raising
some confusion between all the names used to label the various pieces. This page tries to clarify
-this situation.
+this situation.
"MED" can (unfortunately) refer to:
- <b>\ref med-file "MED file format"</b>: the file format used to save a mesh (".med" extension)
with SALOME) to read/write MED file (warning: for advanced users only!)
- <b> \ref medcoupling "MEDCoupling"</b>: the (relatively) high level API to deal with mesh and fields in memory
- <b>\ref medloader MEDLoader</b>: part of the library dedicated to file I/O = a more user-friendly API than the MED-file library API
-- <b>\ref remapper "Remapper"</b>: part of the library dedicated to
+- <b>\ref remapper "Remapper"</b>: part of the library dedicated to
\ref interpolation "interpolation/projection methods"
-- <b>\ref gui "SALOME’s MED module"</b> (GUI point of view): a graphical client in the SALOME main application, providing a graphical interaction with part of the library
+- SALOME’s MED module (GUI point of view): a graphical client in the SALOME main application, providing a graphical interaction with part of the library ; for this please refer to the MED module documentation
- and finally <b>\ref parallel "ParaMEDMEM"</b>, for the projection operations and field transfers in parallel
-The most common confusion is between the MED library (what you are reading at present) and
-the MED-file library ("MED fichier").
+The most common confusion is between the MED library (what you are reading at present) and
+the MED-file library ("MED fichier").
The MED-file library is part of the prerequisites of the MED libary, and its only purpose is to read and write
MED files. This is a low level API written in C, and giving a fine-grain access to the structure
of the MED files (.med). The architecture diagramm below details those points further.
-Another source of common confusion is that all the standard (sequential) MEDCoupling/MEDLoader API lies in
+Another source of common confusion is that all the standard (sequential) MEDCoupling/MEDLoader API lies in
the \b %ParaMEDMEM namespace.
This is quite unfortunate but due to historical reasons. The true parallel functionalities
-of the MED library are detailed here: \ref parallel, but are still often called
+of the MED library are detailed here: \ref parallel, but are still often called
the %ParaMEDMEM part of the library.
\section lib-archi Architecture
The figure below represents the layer structure of the packages of the
-library.
+library.
- each element depends on the blocks it covers (fully or partially).
- White blocks represent system or external dependencies.
-- the MEDCalc block, with gray background color, is the \ref gui "Graphical User Interface".
+- the MEDCalc block, with gray background color, is the Graphical User Interface (please refer to the MED module documentation).
- red-colored text identifies code with Swig interfaces (API available in \ref python-api "Python")
- blue-colored text identifies code with both \ref python-api "Swig interfaces" and \ref corba-distrib "CORBA layer".
