From 85c9d800341cb72d756b59b50879d9ae95524084 Mon Sep 17 00:00:00 2001
From: Christophe Geuzaine <cgeuzaine@ulg.ac.be>
Date: Mon, 14 Apr 2003 21:41:25 +0000
Subject: [PATCH] merge intro and overview

---
 doc/texinfo/gmsh.texi | 274 ++++++++++++++++++++----------------------
 1 file changed, 129 insertions(+), 145 deletions(-)

diff --git a/doc/texinfo/gmsh.texi b/doc/texinfo/gmsh.texi
index 0cf90269e0..323e9407d9 100644
--- a/doc/texinfo/gmsh.texi
+++ b/doc/texinfo/gmsh.texi
@@ -1,5 +1,5 @@
 \input texinfo.tex @c -*-texinfo-*-
-@c $Id: gmsh.texi,v 1.11 2003-04-14 21:34:53 geuzaine Exp $
+@c $Id: gmsh.texi,v 1.12 2003-04-14 21:41:25 geuzaine Exp $
 @c
 @c Copyright (C) 1997-2003 C. Geuzaine, J.-F. Remacle
 @c
@@ -143,8 +143,7 @@ the @cite{Gmsh Reference Manual}, for Gmsh @value{GMSH-VERSION}.
 
 @menu
 * Copying conditions::          Terms and conditions of use.
-* Introduction::                What is Gmsh?
-* Overview::                    Quick overview of the general philosophy of Gmsh.
+* Overview::                    What is Gmsh?
 * General tools::               Description of general commands and options.
 * Geometry module::             Description of all Geometry commands.
 * Mesh module::                 Description of all Mesh commands.
@@ -163,18 +162,15 @@ the @cite{Gmsh Reference Manual}, for Gmsh @value{GMSH-VERSION}.
 @detailmenu
  --- The Detailed Node Listing ---
 
-Introduction
-
-* What Gmsh is pretty good at...::  
-* ... and what it is not so good at::  
-* Syntactic rules::             
-
 Overview
 
 * Geometry::                    
 * Mesh::                        
 * Solver::                      
 * Post-processing::             
+* What Gmsh is pretty good at...::  
+* ... and what it is not so good at::  
+* Syntactic rules::             
 
 General tools
 
@@ -238,7 +234,7 @@ Bugs, versions and contributors
 
 @ifclear COMMERCIAL
 
-@node Copying conditions, Introduction, Top, Top
+@node Copying conditions, Overview, Top, Top
 @unnumbered Copying conditions
 
 @cindex Copyright
@@ -287,11 +283,11 @@ developments and download information, are always available on
 @end ifclear
 
 @c =========================================================================
-@c Introduction
+@c Overview
 @c =========================================================================
 
-@node Introduction, Overview, Copying conditions, Top
-@unnumbered Introduction
+@node Overview, General tools, Copying conditions, Top
+@chapter Overview
 
 @cindex Introduction
 @cindex Overview
@@ -308,17 +304,134 @@ All geometrical, mesh, solver and post-processing instructions are
 prescribed either interactively using the graphical user interface or in
 ASCII data files using Gmsh's own scripting language.
 
+Gmsh is structured around four modules: geometry, mesh, solver and
+post-processing. The specification of any input to these modules is done
+either interactively, or in text data files (interactive specifications
+generate language bits in the input file, and vice versa). The accessibility
+of most features in the ASCII text file makes it possible to automate all
+treatments (loops, tests and external access methods permit advanced
+scripting capabilities). The internal kernel of Gmsh reflects this
+structure: it is built around a geometry, mesh, solver and post-processing
+module. A brief description of these four modules is given hereafter.
+
 @menu
+* Geometry::                    
+* Mesh::                        
+* Solver::                      
+* Post-processing::             
 * What Gmsh is pretty good at...::  
 * ... and what it is not so good at::  
 * Syntactic rules::             
 @end menu
 
+@c -------------------------------------------------------------------------
+@c Geometry: geometrical entity definition
+@c -------------------------------------------------------------------------
+
+@node Geometry, Mesh, Overview, Overview
+@section Geometry: geometrical entity definition
+
+Geometries are created in a bottom-up flow by successively defining
+points, oriented curves (segments, circles, ellipses, splines, etc.),
+oriented surfaces (plane surfaces, ruled surfaces, etc.) and
+volumes. Compound groups of geometrical entities can be defined, based
+on these elementary parametrized geometric entities. Data can be
+defined either interactively thanks to the menu system, or directly in
+the ASCII input files.  The scripting possibilities (with loops,
+tests, arrays of variables, etc.) allow fully parametrized definitions
+of all geometrical entities.
+
+@c -------------------------------------------------------------------------
+@c Mesh: finite element mesh generation
+@c -------------------------------------------------------------------------
+
+@node Mesh, Solver, Geometry, Overview
+@section Mesh: finite element mesh generation
+
+A finite element mesh is a tessellation of a given subset of R3 by
+elementary geometrical elements of various shapes (in this case lines,
+triangles, quadrangles, tetrahedra, prisms, hexahedra and pyramids),
+arranged in such a way that if two of them intersect, they do so along a
+face, an edge or a node, and never otherwise. All the finite element meshes
+produced by Gmsh as unstructured, even if they were generated in a
+structured way. This implies that the elementary geometrical elements are
+defined only by an ordered list of their vertices (which allows the
+orientation of all their lower order geometrical entities) but no predefined
+relation is assumed between any two elementary elements.
+
+The mesh generation is performed in the same order as the geometry
+creation: curves are discretized first; the mesh of the curves is then
+used to mesh the surfaces; then the mesh of the surfaces is used to
+mesh the volumes. This automatically assures the continuity of the
+mesh when, for example, two surfaces share a common curve. Every
+meshing step is constrained by the characteristic length field, which
+can be uniform, specified by characteristic length associated to
+elementary geometrical entities, or associated to another mesh (the
+background mesh).
+
+For each meshing step (i.e. the discretization of lines, surfaces and
+volumes), all structured mesh directives are executed first, and serve
+as additional constraints for the unstructured parts. The implemented
+Delaunay algorithm is subdivided in the following five steps for
+surface/volume discretization:
+
+@enumerate
+@item
+trivial meshing of a box including the convex polygon/polyhedron defined by
+the boundary nodes resulting from the discretization of the curves/surfaces;
+@item
+creation of the initial mesh by insertion of all the nodes on the
+curves/surfaces thanks to the Bowyer algorithm;
+@item
+boundary restoration to force all the edges/faces of the curves/surfaces to
+be present in the initial mesh;
+@item
+suppression of all the unwanted triangles/tetrahedra (in particular those
+containing the nodes of the initial box);
+@item
+insertion of new nodes by the Bowyer algorithm until the characteristic size
+of each simplex is lower or equal to the characteristic length field
+evaluated at the center of its circumscribed circle/sphere.
+@end enumerate
+
+@c -------------------------------------------------------------------------
+@c Solver: external solver interface
+@c -------------------------------------------------------------------------
+
+@node Solver, Post-processing, Mesh, Overview
+@section Solver: external solver interface
+
+External solvers can be interfaced with Gmsh through Unix sockets, which
+permits to easily launch computations either locally or on remote computers,
+and to collect and exploit the simulation results within Gmsh. The default
+solver interfaced with Gmsh is GetDP
+(@uref{http://www.geuz.org/getdp/}). @xref{Solver}, to see how to define
+your own solver.
+
+@c -------------------------------------------------------------------------
+@c Post-processing: scalar and vector field visualization
+@c -------------------------------------------------------------------------
+
+@node Post-processing, What Gmsh is pretty good at..., Solver, Overview
+@section Post-processing: scalar and vector field visualization
+
+Multiple post-processing scalar or vector maps can be loaded and manipulated
+(globally or individually) along with the geometry and the mesh. Scalar
+fields are represented by iso-value curves/surfaces or color maps and vector
+fields by three-dimensional arrows or displacement maps. Post-processing
+functions include arbitrary section computation, offset, elevation, boundary
+extraction, color map and range modification, animation, vector graphic
+output, etc. All post-processing options can be accessed either
+interactively or through the input ASCII text files. Scripting permits to
+automate all the post-processing operations (e.g. for the creation of
+complex animations). User-defined operations can also be performed on
+post-proessing views through to dynamically loadable modules (plug-ins).
+
 @c -------------------------------------------------------------------------
 @c What Gmsh is pretty good at
 @c -------------------------------------------------------------------------
 
-@node What Gmsh is pretty good at..., ... and what it is not so good at, Introduction, Introduction
+@node What Gmsh is pretty good at..., ... and what it is not so good at, Post-processing, Overview
 @section What Gmsh is pretty good at...
 
 @itemize @bullet
@@ -374,7 +487,7 @@ per-user configuration files, or specified on the command-line
 @c ... and what it is not so good at
 @c -------------------------------------------------------------------------
 
-@node ... and what it is not so good at, Syntactic rules, What Gmsh is pretty good at..., Introduction
+@node ... and what it is not so good at, Syntactic rules, What Gmsh is pretty good at..., Overview
 @section ... and what it is not so good at
 
 @itemize @bullet
@@ -407,7 +520,7 @@ elements).
 @c Syntactic Rules Used in this Document
 @c -------------------------------------------------------------------------
 
-@node Syntactic rules,  , ... and what it is not so good at, Introduction
+@node Syntactic rules,  , ... and what it is not so good at, Overview
 @section Syntactic rules used in this document
 
 @cindex Syntax, rules
@@ -443,135 +556,6 @@ Three dots (@dots{}) indicate a possible repetition of the preceding rule.
 The @var{etc} symbol replaces nonlisted rules.
 @end enumerate
 
-@c =========================================================================
-@c Overview
-@c =========================================================================
-
-@node Overview, General tools, Introduction, Top
-@chapter Overview
-
-@cindex Overview
-
-Gmsh is structured around four modules: geometry, mesh, solver and
-post-processing. The specification of any input to these modules is done
-either interactively, or in text data files (interactive specifications
-generate language bits in the input file, and vice versa). The accessibility
-of most features in the ASCII text file makes it possible to automate all
-treatments (loops, tests and external access methods permit advanced
-scripting capabilities). The internal kernel of Gmsh reflects this
-structure: it is built around a geometry, mesh, solver and post-processing
-module. A brief description of these four modules is given hereafter.
-
-@menu
-* Geometry::                    
-* Mesh::                        
-* Solver::                      
-* Post-processing::             
-@end menu
-
-@c -------------------------------------------------------------------------
-@c Geometry: geometrical entity definition
-@c -------------------------------------------------------------------------
-
-@node Geometry, Mesh, Overview, Overview
-@section Geometry: geometrical entity definition
-
-Geometries are created in a bottom-up flow by successively defining
-points, oriented curves (segments, circles, ellipses, splines, etc.),
-oriented surfaces (plane surfaces, ruled surfaces, etc.) and
-volumes. Compound groups of geometrical entities can be defined, based
-on these elementary parametrized geometric entities. Data can be
-defined either interactively thanks to the menu system, or directly in
-the ASCII input files.  The scripting possibilities (with loops,
-tests, arrays of variables, etc.) allow fully parametrized definitions
-of all geometrical entities.
-
-@c -------------------------------------------------------------------------
-@c Mesh: finite element mesh generation
-@c -------------------------------------------------------------------------
-
-@node Mesh, Solver, Geometry, Overview
-@section Mesh: finite element mesh generation
-
-A finite element mesh is a tessellation of a given subset of R3 by
-elementary geometrical elements of various shapes (in this case lines,
-triangles, quadrangles, tetrahedra, prisms, hexahedra and pyramids),
-arranged in such a way that if two of them intersect, they do so along a
-face, an edge or a node, and never otherwise. All the finite element meshes
-produced by Gmsh as unstructured, even if they were generated in a
-structured way. This implies that the elementary geometrical elements are
-defined only by an ordered list of their vertices (which allows the
-orientation of all their lower order geometrical entities) but no predefined
-relation is assumed between any two elementary elements.
-
-The mesh generation is performed in the same order as the geometry
-creation: curves are discretized first; the mesh of the curves is then
-used to mesh the surfaces; then the mesh of the surfaces is used to
-mesh the volumes. This automatically assures the continuity of the
-mesh when, for example, two surfaces share a common curve. Every
-meshing step is constrained by the characteristic length field, which
-can be uniform, specified by characteristic length associated to
-elementary geometrical entities, or associated to another mesh (the
-background mesh).
-
-For each meshing step (i.e. the discretization of lines, surfaces and
-volumes), all structured mesh directives are executed first, and serve
-as additional constraints for the unstructured parts. The implemented
-Delaunay algorithm is subdivided in the following five steps for
-surface/volume discretization:
-
-@enumerate
-@item
-trivial meshing of a box including the convex polygon/polyhedron defined by
-the boundary nodes resulting from the discretization of the curves/surfaces;
-@item
-creation of the initial mesh by insertion of all the nodes on the
-curves/surfaces thanks to the Bowyer algorithm;
-@item
-boundary restoration to force all the edges/faces of the curves/surfaces to
-be present in the initial mesh;
-@item
-suppression of all the unwanted triangles/tetrahedra (in particular those
-containing the nodes of the initial box);
-@item
-insertion of new nodes by the Bowyer algorithm until the characteristic size
-of each simplex is lower or equal to the characteristic length field
-evaluated at the center of its circumscribed circle/sphere.
-@end enumerate
-
-@c -------------------------------------------------------------------------
-@c Solver: external solver interface
-@c -------------------------------------------------------------------------
-
-@node Solver, Post-processing, Mesh, Overview
-@section Solver: external solver interface
-
-External solvers can be interfaced with Gmsh through Unix sockets, which
-permits to easily launch computations either locally or on remote computers,
-and to collect and exploit the simulation results within Gmsh. The default
-solver interfaced with Gmsh is GetDP
-(@uref{http://www.geuz.org/getdp/}). @xref{Solver}, to see how to define
-your own solver.
-
-@c -------------------------------------------------------------------------
-@c Post-processing: scalar and vector field visualization
-@c -------------------------------------------------------------------------
-
-@node Post-processing,  , Solver, Overview
-@section Post-processing: scalar and vector field visualization
-
-Multiple post-processing scalar or vector maps can be loaded and manipulated
-(globally or individually) along with the geometry and the mesh. Scalar
-fields are represented by iso-value curves/surfaces or color maps and vector
-fields by three-dimensional arrows or displacement maps. Post-processing
-functions include arbitrary section computation, offset, elevation, boundary
-extraction, color map and range modification, animation, vector graphic
-output, etc. All post-processing options can be accessed either
-interactively or through the input ASCII text files. Scripting permits to
-automate all the post-processing operations (e.g. for the creation of
-complex animations). User-defined operations can also be performed on
-post-proessing views through to dynamically loadable modules (plug-ins).
-
 @c =========================================================================
 @c General tools
 @c =========================================================================
-- 
GitLab