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

   1 /*!
   2 \page terminology Terminology - Meshes, fields, interpolation
   3
   4 \section start-meshfield Meshes and fields
   5
   6 This section covers at a very high level the concepts used overall in the MED world.
   7 More precise definitions can be found in the \ref glossary, or in the dedicated pages for the
   8 \ref meshes "meshes" and the \ref fields "fields".
   9
  10 Many physical simulation codes (try to) solve a given set of equations on a given geometrical domain.
  11 This domain can be anything from the representation of a building to the description of the
  12 molecular network found in a small piece of concrete.
  13
  14 The geometrical domain is provided to the machine as a CAO modelisation (what you can build with the
  15 GEOM module of SALOME for example).
  16
  17 \image html geom.png "Example geometry (CAO) of a cylinder"
  18
  19 The numerical codes (e.g. FEM-based codes)
  20 are usually unable to work directly with such a format, and a spatial discretization of the domain has
  21 to be performed: the **meshing**. A **mesh** can hence roughly be seen as a discrete version of a continuous input geometry.
  22 The module SMESH in SALOME is typically dedicated to performing this task.
  23
  24 \image html fine_mesh.png "Example meshing of the above geometry"
  25
  26 A mesh is made of **cells** (the elementary spatial unit), which are typically simple polygons or polyhedrons.
  27
  28 On this support, the code can read/store values in form of a **field**. A **field** is hence an
  29 array of data, where each cell (or node, or ... etc) has
  30 one (or more) values associated to it. A code simulating the heat equation will for example produce a temperature
  31 field assigning a single temperature value to each cell of the mesh.
  32
  33 Taking the vocabulary of the finite-element world, a field with values stored at the cell level is often
  34 called a **P0 field**, and a field where values are stored at node level a **P1 field**.
  35
  36 More on this subject:
  37 - \ref meshes
  38 - \ref fields
  39
  40 \section start-interp Interpolation
  41
  42 When working with different codes, or when coupling codes, it is often the case that the initial problem
  43 has been modelised in two different ways. For example a thermic code might use a mesh made of tetrahedron
  44 and a CFD code might use a mesh made of hexaedrons. The <b>interpolation mechanisms</b> provided in the MED library
  45 allow the user to easily \b transfer field data from one representation to the other.
  46
  47 In all its generality it is a complex task, covering many different use cases (do the two meshes overlap? do
  48 we want to conserve the total amount represented by the field?, etc...), justifying a dedicated section in
  49 the documentation: \ref interpolation
  50
  51 In this documentation you will sometime read the words "projection", or "transfer" or "interpolation" for this
  52 process.
  53
  54 More on this subject:
  55 - \ref interpolation
  56
  57 */