doc/user/doxygen/doxfiles/start/library.dox

   1 /*!
   2 \page library The MED constellation: MEDCoupling, MEDLoader, MED file, etc ...
   3
   4 \section lib-termino Who's who?
   5 The library and the module have evolved over the years, raising
   6 some confusion between all the names used to label the various pieces. This page tries to clarify
   7 this situation.
   8
   9 "MED" can (unfortunately) refer to:
  10 - <b>\ref med-file "MED file format"</b>: the file format used to save a mesh (".med" extension)
  11 - <b>\ref med-file "MED-file library"</b>: the C++ library developed by EdF R&D (and provided
  12  with SALOME) to read/write MED file (warning: for advanced users only!)
  13 - <b> \ref medcoupling "MEDCoupling"</b>: the (relatively) high level API to deal with mesh and fields in memory
  14 - <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
  15 - <b>\ref remapper "Remapper"</b>: part of the library dedicated to
  16 \ref interpolation "interpolation/projection methods"
  17 - 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
  18 - and finally <b>\ref parallel "ParaMEDMEM"</b>, for the projection operations and field transfers in parallel
  19
  20 The most common confusion is between the MED library (what you are reading at present) and
  21 the MED-file library ("MED fichier").
  22 The MED-file library is part of the prerequisites of the MED library, and its only purpose is to read and write
  23 MED files. This is a low level API written in C, and giving a fine-grain access to the structure
  24 of the MED files (.med). The architecture diagramm below details those points further.
  25
  26 Another source of common confusion is that all the standard (sequential) MEDCoupling/MEDLoader API lies in
  27 the \b %ParaMEDMEM namespace.
  28 This is quite unfortunate but due to historical reasons. The true parallel functionalities
  29 of the MED library are detailed here: \ref parallel, but are still often called
  30 the %ParaMEDMEM part of the library.
  31
  32 \section lib-archi Architecture
  33 The figure below represents the layer structure of the packages of the
  34 library.
  35 - each element depends on the blocks it covers (fully or partially).
  36 - White blocks represent system or external dependencies.
  37 - the MEDCalc block, with gray background color, is the Graphical User Interface (please refer to the MED module documentation).
  38 - red-colored text identifies code with Swig interfaces (API available in \ref python-api "Python")
  39 - blue-colored text identifies code with both \ref python-api "Swig interfaces" and \ref corba-distrib "CORBA layer".
  40
  41 \image html MedCoupling_Architecture.png
  42
  43 The fundamental set (blue background) consists in three atomic libraries:
  44
  45 - \ref medcoupling "MEDCoupling" that describes data structures used for cross process exchange of \ref meshes "meshes" and \ref fields "fields".
  46 - \ref medloader "MEDLoader" and ParaMEDLoader that provides I/O functions to the MED file format with sequential and parallel processing, respectively. Those are built on top of the MED-file library.
  47 - \ref intro-interp "interpolation tools" that provides mathematical structures and algorithms for interpolation and
  48   localization. It is implemented in three blocks: \ref INTERP_KERNEL "InterpKernel", \ref MEDCoupling::MEDCouplingRemapper "Remapper" and \ref parallel "ParaMEDMEM" (Remapper with parallel processing).
  49
  50 */