description getdp

[Christophe Geuzaine]

-- 
Christophe Geuzaine

Tel: +32-(0)4-366.37.10    mailto:Christophe.Geuzaine at ulg.ac.be
Fax: +32-(0)4-366.29.10    http://www.montefiore.ulg.ac.be/~geuzaine/
-------------- next part --------------

@article{dular:getdp:98,
  author    = "P. Dular and C. Geuzaine and F. Henrotte and W. Legros",
  title     = "A general environment for the treatment of discrete problems and its 
               application to the finite element method",
  journal   = IEEETRMAG, 
  volume    = 34,
  number    = 5,
  pages     = "3395--3398",
  month     = sep,
  year      = "1998",
  annote    = "Conference: Compumag'97, Rio de Janeiro, Br{\'e}sil, 3-6/11/1997
               Presentation: P. Dular",
}


@Unpublished{soft:getdp:doc,
   Author = "P. Dular and C. Geuzaine",
   Title  = "{GetDP} Manual: the documentation for {GetDP}, a General environment 
             for the treatment of Discrete Problems",
   Note   = "\url{http://www.montefiore.ulg.ac.be/~geuzaine/getdp.html}"}
}


\section{Introduction}

 The software environment, called GetDP (\emph{General environment for the
treatment of Discrete Problems}~\cite{dular:getdp:98,soft:getdp}), is open to
the coupling of physical problems (electromagnetic, thermal, mechanical, etc)
as well as of numerical methods (finite element method, integral methods,
etc). It can deal with such problems of any dimension (1D, 2D and 3D) and any
time states (static, transient or harmonic). The main feature of GetDP is the
closeness between its internal structure, the organization of data defining
discrete problems and the symbolic mathematical expressions of these
problems. Its aim is to be welcoming and of easy use for both development and
application levels: it consists of a general working environment in which the
definition of any problem makes use of a limited number of elements, which
makes the environment structured and concise. It therefore gives researchers
advanced developing tools and a large freedom in adding new functionalities.

An assembly of computational tools of GetDP leads to a problem definition
structure, which is a transcription of the mathematical expression of the
problem, and forms a text data file: the equations describing a phenomenon,
written in a mathematical form adapted to a chosen numerical method, directly
constitute data for GetDP. This is the key feature of GetDP, which implies that
the wished generality of the working environment is obtained in the easiest and
most direct way.

\section{Numerical Tools as Objects}


Table I

Mesh            -
Group           Mesh
Function        Group
Constraint      Group, Function, (Resolution)
FunctionSpace   Group, Constraint, (Formulation), (Resolution)
Jacobian        Group
Integration     -
Formulation     Group, Function, (Constraint), FunctionSpace,
                Jacobian, Integration
Resolution      Mesh, Function, Formulation
PostProcessing  Mesh, Group, Function, (Jacobian), (Integration), 
                Formulation, (Resolution)
PostOperation   PostProcessing


The resolution of a discrete problem with GetDP requires the definition, in a
text data file, of the GetDP objects listed in Table I.  The gathering of all
these objects constitutes the problem definition structure, which is a copy of
the formal mathematical formulation of the problem. Table I shows all the
interdependencies between the different objects; reading this table from top to
bottom pictures the working philosophy and the chaining of operations peculiar
to GetDP, from mesh generation to results visualization.  The computational
tools which are at the center of a problem definition structure for coupled
finite element and boundary integral methods are \key{Formulation}s and
\key{FunctionSpace}s. \key{Formulation}s define systems of equations that have
to be built and solved, while \key{FunctionSpace}s contain all the quantities,
i.e.\ scalar or vector fields, known or not, involved in
\key{Formulation}s. Then, other tools constitute data for the latter
(\key{Function}s, \key{Constraint}s, \key{Group}s of geometrical entities
associated with a \key{Mesh} of a geometry, as well as \key{Integration}
methods and \key{Jacobian} methods when integrations are involved in
\key{Formulation}s).

\section{Working Philosophy}

Let us examine the working philosophy in detail. The \key{Resolution} of
a problem requires the building of one or several systems of equations defined
by a set of \key{Formulation}s. A \key{Formulation} uses a set of known or
unknown quantities and fields belonging to \key{FunctionSpace}s, defined on
\key{Group}s of regions and subjected to \key{Constraint}s (such as boundary
conditions, themselves defined on \key{Group}s of regions), as well as
\key{Functions} (such as physical characteristics piecewise defined on
\key{Group}s of regions). The equations can for example be of integral type and
are therefore defined on \key{Group}s  of regions. For integrations,
\key{Integration} and \key{Jacobian} methods are needed (the latter being also
defined on \key{Group}s of regions). A \key{PostProcessing} is performed on the
results of a \key{Resolution} to define the quantities of
interest. \key{PostOperation}s can then finally be applied to these quantities
to output graphical data in several formats. 

Each object of a problem definition structure must be defined before
being referred to by others. A chaining which always respects this property is
the following: it first contains the objects defining particular data of
a problem, such as geometry, physical characteristics and boundary conditions
(i.e.\ \key{Mesh}, \key{Group}, \key{Function}, \key{Cons\-traint}) followed by
those defining a resolution method, such as unknowns, equations and related 
fields (i.e.\ \key{Jacobian}, \key{Integration}, \key{FunctionSpace},
\key{Formulation}, \key{Resolution} and \key{PostProcessing}). This
decomposition points out the possibility of building black boxes, containing
objects of the second group, adapted to treatments of defined problems.

The generality of GetDP is based on the tight closeness ensured between the
mathematical formulation of the problem, its description by means of the syntax
and the corresponding internal data structure. As each tool appears only once
in the code as an object, validations are facilitated. Indeed, a tool validated
in the frame of a simple method is automatically valid when used within other,
possibly more complex, methods. For example, a method first tested in 2D can
be extended to 3D quite directly and confidently, within the same software.  

The analysis of the GetDP syntax is performed by Lex and Yacc, the software
being written in C. C permits the manipulation of data structures and function
pointers, mandatory for the object oriented approach, in ways that Fortran
simply does not allow. ANSI C is a complete standard that all modern C
compilers support, and the language is identical on all machines. It would be
natural and reasonable to have coded GetDP in C++; we have opted to use C
instead, since C++ is still evolving and compilers on different machines are
not identical. Using C function pointers to provide data encapsulation and
polymorphism has allowed us to get many of the advantages of C++ without using
such a large and more complicated language.