[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

# 1. Overview

> 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] | [ ? ]

## 1.1 Numerical tools as objects

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 treatment of general classes of problems that share the same resolution methods.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 1.2 Syntactic rules used in this document

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.

1. Keywords and literal symbols are printed like `this`.
2. Metasyntactic variables (i.e., text bits that are not part of the syntax, but stand for other text bits) are printed like this.
3. A colon (`:`) after a metasyntactic variable separates the variable from its definition.
4. Optional rules are enclosed in `<` `>` pairs.
5. Multiple choices are separated by `|`.
6. Three dots (...) indicate a possible repetition of the preceding rule.
7. For conciseness, the notation `rule <, rule > ...` is replaced by `rule <,...>`.
8. The etc symbol replaces nonlisted rules.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 1.3 Comments

Both C and C++ style comments are supported and can be used in the input data files to comment selected text regions:

1. the text region comprised between `/*` and `*/` pairs is ignored;
2. the rest of a line after a double slash `//` is ignored.

Comments cannot be used inside double quotes or inside GetDP keywords.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 1.4 Includes

An input data file can be included in another input data file by placing one of the following commands (expression-char represents a file name) on a separate line, outside the GetDP objects. Any text placed after an include command on the same line is ignored.

    Include expression-char
    #include expression-char

See 2.2 Constants, for the definition of the character expression expression-char.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

## 1.5 Which problems can GetDP actually solve?

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:

Numerical methods
  finite element method
  boundary element method (experimental, undocumented)
  volume integral methods (experimental, undocumented)
Geometrical models
  one-dimensional models (1D)
  two-dimensional models (2D), plane and axisymmetric
  three-dimensional models (3D)
Time states
  static states
  sinusoidal and harmonic states
  transient states
  eigenvalue problems

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.

Nevertheless, specific numerical tools will always need to be implemented to solve specific problems in areas other than those mentionned above. If you think the general phisosophy of GetDP is right for you and your problem, but you discover that GetDP lacks the tools necessary to handle it, let us know: we would love to discuss it with you. For example, at the time of this writing, many areas of GetDP would need to be improved to make GetDP as useful for computational mechanics or computational fluid dynamics as it is for computational electromagnetics... So if you have the skills and some free time, feel free to join the project: we gladly accept all code contributions!

[ << ] | [ >> ] |  |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

Back to geuz.org/getdp