[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
1.1 Numerical tools as objects 1.2 Syntactic rules used in this document 1.3 Comments 1.4 Includes 1.5 Which problems can GetDP actually solve?
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An assembly of computational tools (or objects) in 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.
The resolution of a discrete problem with GetDP requires the definition, in a text data file, of the GetDP objects listed (together with their dependencies) in the following figure and table.
Group --- Function Group Constraint Group, Function, (Resolution) FunctionSpace Group, Constraint, (Formulation), (Resolution) Jacobian Group Integration --- Formulation Group, Function, (Constraint), FunctionSpace, Jacobian, Integration Resolution Function, Formulation PostProcessing Group, Function, Jacobian, Integration, Formulation, Resolution PostOperation Group, PostProcessing |
The gathering of all these objects constitutes the problem definition structure, which is a copy of the formal mathematical formulation of the problem. Reading the first column of the table from top to bottom pictures the working philosophy and the linking of operations peculiar to GetDP, from group definition to results visualization. The decomposition highlighted in the figure points out the separation between the objects defining the method of resolution, which may be isolated in a "black box" (bottom) and those defining the data peculiar to a given problem (top).
The computational tools which are in the center of a problem definition
structure are formulations (Formulation
) and function spaces
(FunctionSpace
). Formulations define systems of equations that have
to be built and solved, while function spaces contain all the quantities,
i.e. functions, fields of vectors or covectors, known or not, involved in
formulations.
Each object of a problem definition structure must be defined before being
referred to by others. A linking 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. Group
, Function
and Constraint
) followed by
those defining a resolution method, such as unknowns, equations and related
objects (i.e. Jacobian
, Integration
, FunctionSpace
,
Formulation
, Resolution
and PostProcessing
). The
processing cycle ends with the presentation of the results (i.e. lists of
numbers in various formats), defined in PostOperation
fields. This
decomposition points out the possibility of building black boxes, containing
objects of the second group, adapted to treatments of defined problems.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here are the rules we tried to follow when writing this user's guide. Note that metasyntactic variable definitions stay valid throughout all the manual (and not only in the sections where the definitions appear). See Metasyntactic variable index, for an index of all metasyntactic variables.
this
.
:
) after a metasyntactic variable separates the variable
from its definition.
<
>
pairs.
|
.
rule <, rule > ...
is replaced by rule <,...>
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Both C and C++ style comments are supported and can be used in the input data file to comment selected text regions:
/*
and */
pairs is ignored;
//
is ignored.
These commands won't have the described effects inside double quotes or inside GetDP keywords.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Files can be included by placing one of the following commands (expression-char represents a file name) on a separate line, and outside any GetDP object. Any text placed after an include command on the same line is ignored.
|
See 2.2 Constants, for the definition of the character expression expression-char.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The preceding explanations may seem very (too) general. Which are the problems that GetDP can actually solve? To answer this question, here is a list of methods that we have considered and coupled until now:
These methods have been successfully applied to build coupled physical models involving electromagnetic phenomena (magnetostatics, magnetodynamics, electrostatics, electrokinetics, electrodynamics, wave propagation, lumped electric circuits), acoustic phenomena, thermal phenomena and mechanical phenomena (elasticity, rigid body movement).
As can be guessed from the preceding list, GetDP has been initially developed in the field of computational electromagnetics, which fully uses all the offered coupling features. We believe that this does not interfere with the expected generality of the software because a particular modeling forms a problem definition structure which is totally external to the software: GetDP offers computational tools; the user freely applies them to define and solve his problem.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |