| [Top] | [Contents] | [Index] | [ ? ] |
Patrick Dular and Christophe Geuzaine
GetDP is a scientific computation software for the numerical solution of integro-differential equations, using finite element and integral type methods. This is edition 4.1 (March, 31 2005) of the GetDP Reference Manual, for GetDP 1.0.
Copying conditions Terms and conditions of use. Introduction What is GetDP? 1. Overview Quick overview of the general philosophy of GetDP. 2. Expressions Definition of basic expressions in GetDP. 3. Objects Definition of the 10 GetDP objects. 4. Types for objects Definition of all available types for the 10 objects. 5. Short examples Simple object examples. 6. Complete examples Some simple complete examples. 7. Running GetDP How to run GetDP on your operating system. 8. File formats Input and output file formats. 9. Bugs, versions and credits Contact information and ChangeLog A. Tips and tricks Some tips to make your life easier with GetDP. B. Frequently asked questions The GetDP FAQ C. Gmsh examples Sample Gmsh input files. D. License Complete copy of the license. Concept index Index of concepts. Metasyntactic variable index Index of metasyntactic variables used in this manual. Syntax index Index of reserved keywords in the GetDP language.
-- The Detailed Node Listing ---
Introduction
Research and collaboration activities Education and training activities Industrial studies How to read this manual
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?
Expressions
2.1 Definition 2.2 Constants 2.3 Operators 2.4 Functions 2.5 Current values 2.6 Arguments 2.7 Registers 2.8 Fields
Definition
2.3 Operators 2.2 Constants 2.4 Functions 2.5 Current values 2.8 Fields
Operators
2.3.1 Operator types 2.3.2 Evaluation order
Objects
Types for objects
Types forFunction
4.2.1 Math functions 4.2.2 Extended math functions 4.2.3 Green functions 4.2.4 Type manipulation functions 4.2.5 Coordinate functions 4.2.6 Miscellaneous functions
Short examples
FunctionSpaceexamples
Formulationexamples
Resolutionexamples
Complete examples
6.1 Electrostatic problem 6.2 Magnetostatic problem 6.3 Magnetodynamic problem
File formats
8.1 Input file format 8.2 Output file format
Output file format
8.2.1 File `.pre' 8.2.2 File `.res'
Bugs, versions and credits
9.1 Bugs 9.2 Versions 9.3 Credits
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GetDP is "free software"; this means that everyone is free to use it and to redistribute it on a free basis. GetDP is not in the public domain; it is copyrighted and there are restrictions on its distribution, but these restrictions are designed to permit everything that a good cooperating citizen would want to do. What is not allowed is to try to prevent others from further sharing any version of GetDP that they might get from you.
Specifically, we want to make sure that you have the right to give away copies of GetDP, that you receive source code or else can get it if you want it, that you can change GetDP or use pieces of GetDP in new free programs, and that you know you can do these things.
To make sure that everyone has such rights, we have to forbid you to deprive anyone else of these rights. For example, if you distribute copies of GetDP, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must tell them their rights.
Also, for our own protection, we must make certain that everyone finds out that there is no warranty for GetDP. If GetDP is modified by someone else and passed on, we want their recipients to know that what they have is not what we distributed, so that any problems introduced by others will not reflect on our reputation.
The precise conditions of the license for GetDP are found in the General Public License that accompanies the source code (see section D. License). Further information about this license is available from the GNU Project webpage http://www.gnu.org/copyleft/gpl-faq.html. Detailed copyright information can be found in 9.3 Credits.
The source code and various pre-compiled versions of GetDP (for Unix, Windows and Mac OS) can be downloaded from the web site http://www.geuz.org/getdp/.
If you use GetDP, we would appreciate that you mention it in your work. References and the latest news about GetDP are always available on http://www.geuz.org/getdp/. Please send all GetDP-related questions to the public GetDP mailing list at getdp@geuz.org.
If you want to integrate GetDP into a closed-source software, or want to sell a modified closed-source version of GetDP, please contact one of the authors. You can purchase a version of GetDP under a different license, with "no strings attached" (for example allowing you to take parts of GetDP and integrate them into your own proprietary code).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GetDP (a "General environment for the treatment of Discrete Problems") is a scientific software environment for the numerical solution of integro-differential equations, open to the coupling of physical problems (electromagnetic, thermal, etc.) as well as of numerical methods (finite element method, integral methods, etc.). It can deal with such problems of various dimensions (1D, 2D or 3D) and time states (static, transient or harmonic).
The main feature of GetDP is the closeness between its internal structure (written in C), the organization of data defining discrete problems (written by the user in ASCII data files) 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 working environment in which the definition of any problem makes use of a limited number of objects, which makes the environment structured and concise. It therefore gives researchers advanced developing tools and a large freedom in adding new functionalities.
The modeling tools provided by GetDP can be tackled at various levels of complexity: this opens the software to a wide range of activities, such as research, collaboration, education, training and industrial studies.
Research and collaboration activities Education and training activities Industrial studies How to read this manual
The internal structure of the software is very close to the structure used to define discrete problems in the input data files. As a result, a unicity and conciseness of both development and application levels is obtained without any interface between them, which facilitates work of any kind--particularly validations. GetDP permits to rapidly develop tools for the comparison of methods and the exchange of solutions between research teams, which is one of the main aims of collaboration. Moreover, after a short training, GetDP could be used by teams as a basis for their own developments, while allowing a large freedom in the latter.
The software environment consists of modeling tools applicable to various physical problems. Education and training can therefore be offered in various domains and at different levels. The closeness between the definition of discrete problems and their symbolic mathematical expressions entails that the theory and mathematical bases of numerical methods, which are essential to anyone who wants to tackle the solving of discrete problems, can be directly followed by their practical applications. These applications can be evolutionary, in the sense that the offered tools are of various levels of complexity. Everyone can tackle, step by step, according to his apprenticeship level, the tools adapted to the solving of more and more complex problems, as well as various methods for the solving of the same problem.
The treatment of industrial problems can also be facilitated because GetDP is adapted to the study of a wide range of physical problems using various numerical methods. In particular, adapted made to measure and ready-to-use software could be rapidly developed for given problems.
After reading 1. Overview, and 2. Expressions, which depict the general concepts and the way to construct simple expressions in GetDP, you can safely (during a first reading) skip 3. Objects and 4. Types for objects and directly go to 5. Short examples. This chapter gives simple examples of the problem definition syntax used to define the discrete problems. For each example, you should then go back to 3. Objects, and 4. Types for objects, and have a detailed view of the syntax of the objects appearing in it. Note that indexes for many concepts and for all the syntax elements are available at the end of this manual.
Once the examples presented in 5. Short examples, are understood, you may start to use GetDP on your computer (see section 7. Running GetDP), for example by solving the complete examples presented in 6. Complete examples.
| [ < ] | [ > ] | [ << ] | [ 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
2.1 Definition 2.2 Constants 2.3 Operators 2.4 Functions 2.5 Current values 2.6 Arguments 2.7 Registers 2.8 Fields
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Expressions are the basic tool of GetDP. They cover a wide range of functional expressions, from constants to formal expressions containing functions (built-in or user-defined, depending on space and time, etc.), arguments, discrete quantities and their associated differential operators, etc. Note that `white space' (spaces, tabs, new line characters) is ignored inside expressions (as well as inside all GetDP objects).
Expressions are denoted by the metasyntactic variable expression (remember the definition of the syntactic rules in 1.2 Syntactic rules used in this document):
expression:
integer |
real |
constant-id |
quantity |
argument |
current-value |
register-value-set |
register-value-get |
operator-unary expression |
expression operator-binary expression |
expression operator-ternary-left expression operator-ternary-right expression |
built-in-function-id [ < expression-list > ] < { expression-cst-list } > |
function-id [ < expression-list > ]
|
The following sections introduce the quantities that can appear in expressions, i.e. constant terminals (integer, real) and constant expression identifiers (constant-id, expression-cst-list), discretized fields (quantity), arguments (argument), current values (current-value), register values (register-value-set, register-value-get), operators (operator-unary, operator-binary, operator-ternary-left, operator-ternary-right) and built-in or user-defined functions (built-in-function-id, function-id). List of expressions are defined as:
expression-list: expression <,...> |
2.3 Operators 2.2 Constants 2.4 Functions 2.5 Current values 2.8 Fields
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The three constant types used in GetDP are integer, real and string. These types have the same meaning and syntax as in the C or C++ programming languages. Besides general expressions (expression), purely constant expressions, denoted by the metasyntactic variable expression-cst, are also used:
expression-cst:
integer |
real |
constant-id |
operator-unary expression-cst |
expression-cst operator-binary expression-cst |
expression-cst operator-ternary-left expression-cst operator-ternary-right
expression-cst |
math-function-id [ < expression-cst-list > ]
|
List of constant expressions are defined as:
expression-cst-list: expression-cst-list-item <,...> |
with
expression-cst-list-item:
expression-cst |
expression-cst : expression-cst |
expression-cst : expression-cst : expression-cst |
constant-id {} |
constant-id { expression-cst-list } |
List[ constant-id ] |
ListAlt[ constant-id, constant-id ]
|
The second case in this last definition permits to create a list containing
the range of numbers comprised between the two expression-cst, with a
unit incrementation step. The third case also permits to create a list
containing the range of numbers comprised between the two
expression-cst, but with a positive or negative incrementation step
equal to the third expression-cst. The fourth and fifth cases permit
to reference constant identifiers (constant-ids) of lists of constants
and constant identifiers of sublists of constants (see below for the
definition of constant identifiers) . The sixth case is a synonym for the
fourth. The last case permits to create alternate lists: the arguments of
ListAlt must be constant-ids of lists of constants of the same
dimension. The result is an alternate list of these constants: first
constant of argument 1, first constant of argument 2, second constant of
argument 1, etc. These kinds of lists of constants are for example often
used for function parameters (see section 2.4 Functions).
Contrary to a general expression which is evaluated at runtime (thanks to an internal stack mechanism), an expression-cst is completely evaluated during the syntactic analysis of the problem (when GetDP reads the `.pro' file). The definition of such constants or lists of constants with identifiers can be made outside or inside any GetDP object. The syntax for the definition of constants is:
affectation: DefineConstant [ constant-id < = expression-cst > <,...> ]; | constant-id = constant-def; |
with
constant-id:
string
constant-def:
expression-cst-list-item |
{ expression-cst-list }
|
Notes:
Pi (3.1415926535897932),
0D (0), 1D (1), 2D (2) and 3D (3).
DefineConstant (zero if no expression-cst is
given) is performed only if constant-id has not yet been defined. This
kind of explicit default definition mechanism is most useful in general
problem definition structures making use of a large number of generic
constants, functions or groups. When exploiting only a part of a complex
problem definition structure, the default definition mechanism allows to
define the quantities of interest only, the others being assigned a default
value (that will not be used during the processing but that avoids the error
messages produced when references to undefined quantities are made).
See 5.1 Constant expression examples, as well as 5.3 Function examples, for
some examples.
Constant character strings can also be defined. The syntax for their definition is the following:
string-id = "string"; |
with
string-id: string |
Character expressions can be defined, using these constant strings:
expression-char: "string" | string-id | StrCat[ expression-char , expression-char ] |
The third case in this definition permits to concatenate two character expressions.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
2.3.1 Operator types 2.3.2 Evaluation order
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The operators in GetDP are similar to the corresponding operators in the C or C++ programming languages.
operator-unary:
-
!
operator-binary:
^
*
/\
/
%
+
-
==
!=
>
>=
<
<=
&&
||
|| is
evaluated even if the first one is true.
operator-ternary-left:
?
:
?), which must result in a
scalar value. If it is true (non-zero) the second argument (located between
? and :) is evaluated and returned; otherwise the third
argument (located after :) is evaluated and returned.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The evaluation priorities are summarized below (from stronger to weaker,
i.e. ^ has the highest evaluation priority). Parentheses
() may be used anywhere to change the order of evaluation.
^
- (unary), !
/\
*, /, %
+, -
<, >, <=, >=
!=, ==
&&, ||
?:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Two types of functions coexist in GetDP: user-defined functions
(function-id, see 3.2 Function: defining global and piecewise expressions) and built-in functions
(built-in-function-id, defined in this section).
Both types of functions are always followed by a pair of brackets []
that can possibly contain arguments (see section 2.6 Arguments). This makes it
simple to distinguish a function-id or a built-in-function-id
from a constant-id. As shown below, built-in functions might also have
parameters, given between braces {}, and which are completely
evaluated during the analysis of the syntax (since they are of
expression-cst-list type):
built-in-function-id [ < expression-list > ] < { expression-cst-list } >
|
with
built-in-function-id: math-function-id | extended-math-function-id | green-function-id | type-function-id | coord-function-id | misc-function-id |
Notes:
Function.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Current values are a special kind of arguments (see section 2.6 Arguments) which return the current integer or floating point value of an internal GetDP variable:
$Time
$DTime
$Theta
$TimeStep
$Iteration
$X, $XS
$Y, $YS
$Z, $ZS
$A, $B, $C
OnGrid PostOperation (see section 4.10 Types for PostOperation).
Note:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Function arguments can be used in expressions and have the following syntax (integer indicates the position of the argument in the expression-list of the function, starting from 1):
argument: $integer |
See 3.2 Function: defining global and piecewise expressions, and 5.3 Function examples, for more details.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In many situations, identical parts of expressions are used more than once. If this is not a problem with constant expressions (since expression-csts are evaluated only once during the analysis of the problem definition structure, cf. 2.2 Constants), it may introduce some important overhead while evaluating complex expressions (which are evaluated at runtime, thanks to an internal stack mechanism). In order to circumvent this problem, the evaluation result of any part of an expression can be saved in a register: a memory location where this partial result will be accessible without any costly reevaluation of the partial expression.
Registers have the following syntax:
register-value-set: expression#integer register-value-get: #integer |
Thus, to store any part of an expression in the register 5, one
should add #5 directly after the expression. To reuse the value
stored in this register, one simply uses #5 instead of the expression
it should replace.
See 5.3 Function examples, for an example.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A discretized quantity (defined in a function space, cf.
3.4 FunctionSpace: building function spaces) is represented between braces {}, and can only
appear in well-defined expressions in Formulation
(see section 3.7 Formulation: building equations) and PostProcessing (see section 3.9 PostProcessing: exploiting computational results)
objects:
quantity:
< quantity-dof > { < quantity-operator > quantity-id }
|
with
quantity-id: string |
and
quantity-dof:
Dof
Degrees of
freedom), to be used only in Equation terms of formulations to
define (elementary) matrices. Roughly said, the Dof symbol in front
of a discrete quantity indicates that this quantity is an unknown quantity,
and should therefore not be considered as already computed.
BF
quantity-operator:
d
Grad
Curl
Rot
Div
dInv
GradInv
CurlInv
RotInv
DivInv
Note:
Grad, Curl and Div can be applied
to 0, 1 and 2-forms respectively, the exterior derivative operator d
is usually preferred with such fields.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter presents the formal definition of the ten GetDP objects mentioned in 1. Overview. To be concise, all the possible parameters for these objects are not given here (cf. the etc syntactic rule defined in 1.2 Syntactic rules used in this document). Please refer to 4. Types for objects, for this.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Group: defining topological entities Meshes (grids) constitute the input data of GetDP. All that is needed by GetDP as a mesh is a file containing a list of nodes (with their coordinates) and a list of geometrical elements with, for each one, a number characterizing its geometrical type (i.e. line, triangle, quadrangle, tetrahedron, hexahedron, prism, etc.), a number characterizing the physical region to which it belongs and the list of its nodes. This minimal input set should be easy to extract from most of the classical mesh file formats (see section 8.1 Input file format, for a complete description of the mesh file format read by GetDP).
Groups of geometrical entities of various types can be considered and are used in many objects. There are region groups, of which the entities are regions, and function groups, with nodes, edges, facets, volumes, groups of nodes, edges of tree, facets of tree, ... of regions.
Amongst region groups, elementary and global groups can be distinguished: elementary groups are relative to single regions (e.g. physical regions in which piecewise defined functions or constraints can be defined) while global groups are relative to sets of regions for which given treatments have to be performed (e.g. domain of integration, support of a function space, etc.).
Groups of function type contain lists of entities built on some region groups (e.g. nodes for nodal elements, edges for edge elements, edges of tree for gauge conditions, groups of nodes for floating potentials, elements on one side of a surface for cuts, etc.).
A definition of initially empty groups can be obtained thanks to a
DefineGroup command, so that their identifiers exist and can be
referred to in other objects, even if these groups are not explicitly
defined. This procedure is similar to the DefineConstant procedure
introduced for constants in 2.2 Constants.
The syntax for the definition of groups is:
Group {
< DefineGroup [ group-id <{integer}> <,...> ]; > ...
< group-id <{<#>integer}> = group-def; > ...
}
|
with
group-id:
string
group-def:
group-type [ group-list <, group-sub-type group-list > ] |
group-id <{<integer>}> |
#group-list
group-type:
Region | Global | NodesOf | EdgesOf | etc
group-list:
All | group-list-item | { group-list-item <,...> }
group-list-item:
integer |
integer : integer |
integer : integer : integer |
group-id <{<integer>}>
group-sub-type:
Not | StartingOn | OnOneSideOf | etc
|
Notes:
i:j replaces the list of consecutive integers i,
i+1, ..., j-1, j.
DefineGroup[group-id{n}] defines
the empty groups group-id{i}, i=1, ..., n.
Such a definition is optional, i.e. each
group-id{i} can be separately defined, in any order.
group-id{#n} = group-def
defines the groups group-id{i},
i=1, ..., n, by replacing for each i any
group-id{} in group-def with
group-id{i}.
#group-list is an abbreviation of Region[group-list].
See 4.1 Types for Group, for the complete list of options and 5.2 Group examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Function: defining global and piecewise expressions A user-defined function can be global in space or piecewise defined in region groups. A physical characteristic is an example of a piecewise defined function (e.g. magnetic permeability, electric conductivity, etc.) and can be simply a constant, for linear materials, or a function of one or several arguments for nonlinear materials. Such functions can of course depend on space coordinates or time, which can be needed to express complex constraints.
A definition of initially empty functions can be made thanks to the
DefineFunction command so that their identifiers exist and can be
referred to (but cannot be used) in other objects. The syntax for the
definition of functions is:
Function {
< DefineFunction [ function-id <,...> ]; > ...
< function-id [ < group-def > ] = expression; > ...
}
|
with
function-id: string |
Note:
Region type, and
indicates on which region the (piecewise) function is defined. Warning: it
is incorrect to write f[reg1]=1; g[reg2]=f[]+1; since the domains of
definition of f[] and g[] don't match.
See 4.2 Types for Function, for the complete list of built-in functions
and 5.3 Function examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Constraint: specifying constraints on function spaces and formulations
Constraints can be referred to in FunctionSpace objects to be
used for boundary conditions, to impose global quantities or to
initialize quantities. These constraints can be expressed with
functions or be imposed by the pre-resolution of another discrete
problem. Other constraints can also be defined, e.g. constraints of
network type for the definition of circuit connections, to be used in
Formulation objects.
The syntax for the definition of constraints is:
Constraint {
{ Name constraint-id <{#integer}>; Type constraint-type;
Case {
{ Region group-def; < Type constraint-type; >
< SubRegion group-def; > < TimeFunction expression; >
constraint-val; } ...
}
| Case constraint-case-id {
{ Region group-def; < Type constraint-type; >
constraint-case-val; } ...
} ...
} ...
}
|
with
constraint-id:
constraint-case-id:
string
constraint-type:
Assign | Init | Network | etc
constraint-val:
Value expression | NameOfResolution resolution-id | etc
constraint-case-val:
Branch { integer, integer } | etc
|
Notes:
Name constraint-id{#n} defines
the constraints constraint-id{i},
i=1, ..., n, replacing for each i any
group-id{} in group-defs of Case
fields with group-id{i}.
Case
fields is applied to all the cases of the constraint, unless other types are
explicitly given in these cases. The default type is Assign.
Region group-def will be the main
group-list argument of the group-def to be built for the
constraints of FunctionSpaces. The optional region type
SubRegion group-def will be the argument of the associated
group-sub-type.
Value of constraint-val cannot be time
dependent ($Time) because it is evaluated only once during the
pre-processing (for efficiency reasons). Time dependences must be defined
in TimeFunction expression.
See 4.3 Types for Constraint, for the complete list of options and
5.4 Constraint examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
FunctionSpace: building function spaces
A FunctionSpace is characterized by the type of its interpolated
fields, one or several basis functions and optional constraints (in
space and time). Subspaces of a function space can be defined (e.g.
for the use with hierarchical elements), as well as direct associations of
global quantities (e.g. floating potential, electric charge, current,
voltage, magnetomotive force, etc.).
A key point is that basis functions are defined by any number of subsets of
functions, being added. Each subset is characterized by associated built-in
functions for evaluation, a support of definition and a set of associated
supporting geometrical entities (e.g. nodes, edges, facets, volumes,
groups of nodes, edges incident to a node, etc.). The freedom in defining
various kinds of basis functions associated with different geometrical
entities to interpolate a field permits to build made-to-measure function
spaces adapted to a wide variety of field approximations
(see section 5.5 FunctionSpace examples).
The syntax for the definition of function spaces is:
FunctionSpace {
{ Name function-space-id <{#integer}>;
Type function-space-type;
BasisFunction {
{ Name basis-function-id; NameOfCoef coef-id;
Function basis-function-type
< { Quantity quantity-id;
Formulation formulation-id {#integer};
Group group-def; Resolution resolution-id {} } >;
Support group-def; Entity group-def; } ...
}
< SubSpace {
{ Name sub-space-id;
NameOfBasisFunction basis-function-list; } ...
} >
< GlobalQuantity {
{ Name global-quantity-id; Type global-quantity-type;
NameOfCoef coef-id; } ...
} >
< Constraint {
{ NameOfCoef coef-id;
EntityType group-type; < EntitySubType group-sub-type; >
NameOfConstraint constraint-id <{}>; } ...
} >
} ...
}
|
with
function-space-id:
basis-function-id:
coef-id:
sub-space-id:
global-quantity-id:
formulation-id:
resolution-id:
string
function-space-type:
Scalar | Vector | Form0 | Form1 | etc
basis-function-type:
BF_Node | BF_Edge | etc
basis-function-list:
basis-function-id | { basis-function-id <,...> }
global-quantity-type:
AliasOf | AssociatedWith
|
Notes:
Name function-space-id{#n} defines
the function spaces function-space-id{i},
i=1, ..., n, replacing for each i any {} in
group-defs of BasisFunction field and in
constraint-id{} of Constraint field with {i}.
Entity of
a BasisFunction is the same as that of the associated Support,
it is replaced by All for more efficient treatments during the
computation process (this prevents the construction and the analysis of a list
of geometrical entities).
Name for several
BasisFunction fields permits to define piecewise basis functions;
separate NameOfCoefs must be defined for those fields.
Group of type group-type,
using the Region defined in a Constraint object as its main
argument, and the optional SubRegion in the same object as a
group-sub-type argument.
BF_Global or
BF_dGlobal) needs parameters, i.e. it is given by the quantity
(quantity-id) pre-computed from multiresolutions performed on
multiformulations.
See 4.4 Types for FunctionSpace, for the complete list of options and
5.5 FunctionSpace examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jacobian: defining jacobian methods
Jacobian methods can be referred to in Formulation and
PostProcessing objects to be used in the computation of integral
terms and for changes of coordinates. They are based on Group
objects and define the geometrical transformations applied to the
reference elements (i.e. lines, triangles, quadrangles, tetrahedra,
prisms, hexahedra, etc.). Besides the classical lineic, surfacic and
volume Jacobians, the Jacobian object allows the construction of
various transformation methods (e.g. infinite transformations for
unbounded domains) thanks to dedicated jacobian methods.
The syntax for the definition of Jacobian methods is:
Jacobian {
{ Name jacobian-id;
Case {
{ Region group-def | All;
Jacobian jacobian-type < { expression-cst-list } >; } ...
}
} ...
}
|
with
jacobian-id: string jacobian-type: Vol | Sur | VolAxi | etc |
Note:
Jacobian object is defined by Region All
and must follow all the other cases.
See 4.5 Types for Jacobian, for the complete list of options and
5.6 Jacobian examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Integration: defining integration methods
Various numerical or analytical integration methods can be referred to in
Formulation and PostProcessing objects to be used in the
computation of integral terms, each with a set of particular options (number of
integration points for quadrature methods--which can be linked to an error
criterion for adaptative methods, definition of transformations for singular
integrations, etc.). Moreover, a choice can be made between several
integration methods according to a criterion (e.g. on the proximity between
the source and computation points in integral formulations).
The syntax for the definition of integration methods is:
Integration {
{ Name integration-id; < Criterion expression; >
Case {
< { Type integration-type;
Case {
{ GeoElement element-type; NumberOfPoints expression-cst } ...
}
} ... >
< { Type Analytic; } ... >
}
} ...
}
|
with
integration-id: string integration-type: Gauss | etc element-type: Line | Triangle | Tetrahedron etc |
See 4.6 Types for Integration, for the complete list of options and
5.7 Integration examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Formulation: building equations
The Formulation tool permits to deal with volume, surface and
line integrals with many kinds of densities to integrate, written in a
form that is similar to their symbolic expressions (it uses the same
expression syntax as elsewhere in GetDP), which therefore permits
to directly take into account various kinds of elementary matrices
(e.g. with scalar or cross products, anisotropies, nonlinearities, time
derivatives, various test functions, etc.). In case nonlinear physical
characteristics are considered, arguments are used for associated
functions. In that way, many formulations can be directly written in the
data file, as they are written symbolically. Fields involved in each
formulation are declared as belonging to beforehand defined function
spaces. The uncoupling between formulations and function spaces allows
to maintain a generality in both their definitions.
A Formulation is characterized by its type, the involved
quantities (of local, global or integral type) and a list of equation
terms. Global equations can also be considered, e.g. for the coupling
with network relations.
The syntax for the definition of formulations is:
Formulation {
{ Name formulation-id <{#integer}>; Type formulation-type;
Quantity {
{ Name quantity-id; Type quantity-type;
NameOfSpace function-space-id <{}>
< [ sub-space-id | global-quantity-id ] >;
< Symmetry expression-cst; >
< [ expression ]; In group-def;
Jacobian jacobian-id; Integration integration-id; >
< IndexOfSystem integer; > } ...
}
Equation {
< local-term-type
{ < term-op-type > [ expression, expression ];
In group-def; Jacobian jacobian-id;
Integration integration-id; } > ...
< GlobalTerm
{ < term-op-type > [ expression, expression ];
In group-def; } > ...
< GlobalEquation
{ Type Network; NameOfConstraint constraint-id;
{ Node expression; Loop expression; Equation expression;
In group-def; } ...
} > ...
}
} ...
}
|
with
formulation-id: string formulation-type: FemEquation | etc local-term-type: Galerkin | deRham quantity-type: Local | Global | Integral term-op-type: Dt | DtDt | JacNL | etc |
Note:
Name formulation-id{#n} defines
the formulations formulation-id{i},
i=1, ..., n, replacing for each i any {} in
function-space-id{} of Quantity field and in
group-defs of Equation field with {i}.
IndexOfSystem permits to resolve ambiguous cases when several
quantities belong to the same function space, but to different systems of
equations. The integer parameter then specifies the index in the list
of an OriginSystem command (see section 3.8 Resolution: solving systems of equations).
GlobalTerm defines a term to be assembled in an equation associated
with a global quantity. This equation is a finite element equation if that
global quantity is linked with local quantities.
GlobalEquation defines a global equation to be assembled in the
matrix of the system.
See 4.7 Types for Formulation, for the complete list of options and
5.8 Formulation examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Resolution: solving systems of equations
The operations available in a Resolution include: the generation of a
linear system, its solving with various kinds of linear solvers, the saving
of the solution or its transfer to another system, the definition of various
time stepping methods, the construction of iterative loops for nonlinear
problems (Newton-Raphson and fixed point methods), etc. Multi-harmonic
resolutions, coupled problems (e.g. magneto-thermal) or linked problems
(e.g. pre-computations of source fields) are thus easily defined in GetDP.
The Resolution object is characterized by a list of systems to
build and their associated formulations, using time or frequency domain,
and a list of elementary operations:
Resolution {
{ Name resolution-id <{#integer}>;
System {
{ Name system-id; NameOfFormulation formulation-list;
< Type system-type; >
< Frequency expression-cst-list-item |
Frequency { expression-cst-list }; >
< DestinationSystem system-id; >
< OriginSystem system-id; | OriginSystem { system-id <,...> }; >
< NameOfMesh expression-char > < Solver expression-char > } ...
}
Operation { < resolution-op; > ... }
} ...
}
|
with
resolution-id:
system-id:
string
formulation-list:
formulation-id <{}> | { formulation-id <{}> <,...> }
system-type:
Real | Complex
resolution-op:
Generate[system-id] | Solve[system-id] | etc
|
Notes:
Name resolution-id{#n} defines the
resolutions resolution-id{i}, i=1, ...,
n, replacing for each i any {} in
formulation-id{} of System field with {i}.
Real. A frequency
domain analysis is defined through the definition of one or several
frequencies (Frequency expression-cst-list-item | Frequency {
expression-cst-list }). Complex systems of equations with no
predefined list of frequencies (e.g. in modal analyses) can be explicitely
defined with Type Complex.
NameOfMesh permits to explicitely specify the mesh to be used for the
construction of the system of equations.
Solver permits to explicitely specify the name of the solver
parameter file to use for the solving of the system of equations. This is
ony valid if GetDP was compiled against the default solver library (it is
the case if you downloaded a pre-compiled copy of GetDP from the internet).
DestinationSystem permits to specify the destination system of a
TransferSolution operation (see section 4.8 Types for Resolution).
OriginSystem permits to specify the systems from which ambiguous
quantity definitions can be solved (see section 3.7 Formulation: building equations).
See 4.8 Types for Resolution, for the complete list of options and
5.9 Resolution examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostProcessing: exploiting computational results
The PostProcessing object is based on the quantities defined in a
Formulation and permits the construction (thanks to the
expression syntax) of any useful piecewise defined quantity of
interest:
PostProcessing {
{ Name post-processing-id <{#integer}>;
NameOfFormulation formulation-id <{}>; < NameOfSystem system-id; >
Quantity {
{ Name post-quantity-id; Value { post-value ... } } ...
}
} ...
}
|
with
post-processing-id:
post-quantity-id:
string
post-value:
Local { local-value } | Integral { integral-value }
local-value:
[ expression ]; In group-def; Jacobian jacobian-id;
integral-value:
[ expression ]; In group-def;
Integration integration-id; Jacobian jacobian-id;
|
Notes:
Name post-processing-id{#n}
defines the post-processings post-processing-id{i},
i=1, ..., n, replacing for each i any {} in
formulation-id{} with {i}.
PostOperation with the post-quantity-id[group-def]
command (see section 3.10 PostOperation: exporting results).
NameOfSystem system-id is not given, the system is
automatically selected as the one to which the first quantity listed in
the Quantity field of formulation-id is associated.
See 4.9 Types for PostProcessing, for the complete list of options and
5.10 PostProcessing examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostOperation: exporting results
The PostOperation is the bridge between results obtained with GetDP
and the external world. It defines several elementary operations on
PostProcessing quantities (e.g. plot on a region, section on a
user-defined plane, etc.), and outputs the results in several file formats.
PostOperation {
{ Name post-operation-id; NameOfPostProcessing post-processing-id;
< Format post-operation-fmt; >
Operation { < post-operation-op; > ... }
} ...
} |
PostOperation post-operation-id UsingPost post-processing-id {
< post-operation-op; > ...
} ...
|
with
post-operation-id: string post-operation-op: Print[ post-quantity-term, print-support <,print-option> ... ] | etc post-quantity-term: post-quantity-id <[group-def]> | post-quantity-id post-quantity-op post-quantity-id[group-def] | post-quantity-id[group-def] post-quantity-op post-quantity-id post-quantity-op: + | - | * | / print-support: OnElementsOf group-def | OnRegion group-def | OnGlobal | etc print-option: File expression-char | Format post-operation-fmt | etc post-operation-fmt: Table | TimeTable | etc |
Notes:
PostOperation syntaxes are equivalent. The first one conforms to
the overall interface, but the second one is more concise.
Operation
field is applied to all the post-processing operations, unless other formats
are explicitly given in these operations with the Format option
(see section 4.10 Types for PostOperation). The default format is Gmsh.
[group-def] of the post-quantity-id
can only be used when this quantity has been defined as an
integral-value (see section 3.9 PostProcessing: exploiting computational results). In this case, the sum of all
elementary integrals is performed over the region group-def.
post-quantity-id[group-def]).
See 4.10 Types for PostOperation, for the complete list of options and
5.11 PostOperation examples, for some examples.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter presents the complete list of choices associated with metasyntactic variables introduced for the ten GetDP objects.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Group Types in
group-type [ R1 <, group-sub-type R2 > ] |
group-type < group-sub-type >:
Region
Global
Region used with global BasisFunctions
BF_Global and BF_dGlobal).
NodesOf
< Not: but not those of R2 >.
EdgesOf
< Not: but not those of R2 >.
FacetsOf
< Not: but not those of R2 >.
VolumesOf
< Not: but not those of R2 >.
ElementsOf
< OnOneSideOf: only elements on one side of R2) >.
GroupsOfNodesOf
GroupsOfEdgesOf
< InSupport: in a support R2 being a group of type ElementOf,
i.e. containing elements >.
GroupsOfEdgesOnNodesOf
< Not: but not those of R2) >.
EdgesOfTreeIn
< StartingOn: a complete tree is first built on R2 >.
FacetsOfTreeIn
< StartingOn: a complete tree is first built on R2 >.
DualNodesOf
DualEdgesOf
DualFacetsOf
DualVolumesOf
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Function
4.2.1 Math functions 4.2.2 Extended math functions 4.2.3 Green functions 4.2.4 Type manipulation functions 4.2.5 Coordinate functions 4.2.6 Miscellaneous functions
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following functions are the equivalent of the functions of the C math library, and always return real-valued expressions. These are the only functions allowed in constant expressions (expression-cst, see 2.2 Constants).
math-function-id:
Exp
[expression]
Exponential function: e^expression.
Log
[expression]
Natural logarithm: ln(expression), expression>0.
Log10
[expression]
Base 10 logarithm: log10(expression), expression>0.
Sqrt
[expression]
Square root, expression>=0.
Sin
[expression]
Sine of expression.
Asin
[expression]
Arc sine (inverse sine) of expression in [-Pi/2,Pi/2], expression in [-1,1].
Cos
[expression]
Cosine of expression.
Acos
[expression]
Arc cosine (inverse cosine) of expression in [0,Pi], expression in [-1,1].
Tan
[expression]
Tangent of expression.
Atan
[expression]
Arc tangent (inverse tangent) of expression in [-Pi/2,Pi/2].
Atan2
[expression,expression]
Arc tangent (inverse tangent) of the first expression divided by the second, in [-Pi,Pi].
Sinh
[expression]
Hyperbolic sine of expression.
Cosh
[expression]
Hyperbolic cosine of expression.
Tanh
[expression]
Hyperbolic tangent of expression.
Fabs
[expression]
Absolute value of expression.
Fmod
[expression,expression]
Remainder of the division of the first expression by the second, with the sign of the first.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
extended-math-function-id:
Cross
[expression,expression]
Cross product of the two arguments; expression must be a vector.
Hypot
[expression,expression]
Square root of the sum of the squares of its arguments.
Norm
[expression]
Absolute value if expression is a scalar; euclidian norm if expression is a vector.
SquNorm
[expression]
Square norm: Norm[expression]^2.
Unit
[expression]
Normalization: expression/Norm[expression]. Returns 0 if the norm is
smaller than 1.e-30.
Transpose
[expression]
Transposition; expression must be a tensor.
TTrace
[expression]
Trace; expression must be a tensor.
F_Cos_wt_p
[]{expression-cst,expression-cst}
The first parameter represents the angular frequency and the second
represents the phase. If the type of the current system is Real,
F_Cos_wt_p[]{w,p} is identical to Cos[w*$Time+p]. If the
type of the current system is Complex, it is identical to
Complex[Cos[w],Sin[w]].
F_Sin_wt_p
[]{expression-cst,expression-cst}
The first parameter represents the angular frequency and the second
represents the phase. If the type of the current system is Real,
F_Sin_wt_p[]{w,p} is identical to Sin[w*$Time+p]. If the
type of the current system is Complex, it is identical to
Complex[Sin[w],-Cos[w]].
F_Period
[expression]{expression-cst}
Fmod[expression,expression-cst]
+
(expression<0 ? expression-cst : 0);
the result is always in [0,expression-cst[.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The Green functions are only used in integral quantities
(see section 3.7 Formulation: building equations). The first parameter represents the dimension of the
problem:
1D:
r = Fabs[$X-$XS]
2D:
r = Sqrt[($X-$XS)^2+($Y-$YS)^2]
3D:
r = Sqrt[($X-$XS)^2+($Y-$YS)^2+($Z-$ZS)^2]
1D, 2D and 3D cases.
green-function-id:
Laplace
[]{expression-cst}
r/2, 1/(2*Pi)*ln(1/r), 1/(4*Pi*r).
GradLaplace
[]{expression-cst}
Gradient of Laplace relative to the destination point ($X,
$Y, $Z).
Helmholtz
[]{expression-cst, expression-cst}
exp(j*k0*r)/(4*Pi*r), where k0 is given by the second parameter.
GradHelmholtz
[]{expression-cst, expression-cst}
Gradient of Helmholtz relative to the destination point ($X,
$Y, $Z).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
type-function-id:
Complex
[expression-list]
Creates a (multi-harmonic) complex expression from an number of real-valued expressions. The number of expressions in expression-list must be even.
Re
[expression]
Takes the real part of a complex-valued expression.
Im
[expression]
Takes the imaginary part of a complex-valued expression.
Vector
[expression,expression,expression]
Creates a vector from 3 scalars.
Tensor
[expression,expression,expression,expression,expression,expression,
expression,expression,expression]
Creates a second-rank tensor of order 3 from 9 scalars.
TensorV
[expression,expression,expression]
Creates a second-rank tensor of order 3 from 3 vectors.
TensorSym
[expression,expression,expression,expression,expression,expression]
Creates a symmetrical second-rank tensor of order 3 from 6 scalars.
TensorDiag
[expression,expression,expression]
Creates a diagonal second-rank tensor of order 3 from 3 scalars.
CompX
[expression]
Gets the X component of a vector.
CompY
[expression]
Gets the Y component of a vector.
CompZ
[expression]
Gets the Z component of a vector.
CompXX
[expression]
Gets the XX component of a tensor.
CompXY
[expression]
Gets the XY component of a tensor.
CompXZ
[expression]
Gets the XZ component of a tensor.
CompYX
[expression]
Gets the YX component of a tensor.
CompYY
[expression]
Gets the YY component of a tensor.
CompYZ
[expression]
Gets the YZ component of a tensor.
CompZX
[expression]
Gets the ZX component of a tensor.
CompZY
[expression]
Gets the ZY component of a tensor.
CompZZ
[expression]
Gets the ZZ component of a tensor.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
coord-function-id:
X
[]
Gets the X coordinate.
Y
[]
Gets the Y coordinate.
Z
[]
Gets the Z coordinate.
XYZ
[]
Gets X, Y and Z in a vector.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
misc-function-id:
Printf
[expression]
Prints the value of expression when evaluated.
Normal
[]
Computes the normal to the element.
NormalSource
[]
Computes the normal to the source element (only valid in a quantity of Integral type).
F_CompElementNum
[]
Returns 0 if the current element and the current source element are identical.
InterpolationLinear
[]{expression-cst-list}
Linear interpolation of points. The number of constant expressions in expression-cst-list must be even.
dInterpolationLinear
[]{expression-cst-list}
Derivative of linear interpolation of points. The number of constant expressions in expression-cst-list must be even.
InterpolationAkima
[]{expression-cst-list}
Akima interpolation of points. The number of constant expressions in expression-cst-list must be even.
dInterpolationAkima
[]{expression-cst-list}
Derivative of Akima interpolation of points. The number of constant expressions in expression-cst-list must be even.
Order
[quantity]
Returns the interpolation order of the quantity.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Constraint constraint-type:
Assign
Init
AssignFromResolution
InitFromResolution
Network
Link
LinkCplx
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
FunctionSpace function-space-type:
Form0
Form1
Form2
Form3
Form1P
Form2P
Scalar
Vector
basis-function-type:
BF_Node
NodesOf, value Form0).
BF_Edge
EdgesOf, value Form1).
BF_Facet
FacetsOf, value Form2).
BF_Volume
VolumesOf, value Form3).
BF_GradNode
NodesOf, value Form1).
BF_CurlEdge
EdgesOf, value Form2).
BF_DivFacet
FacetsOf, value Form3).
BF_GroupOfNodes
GroupsOfNodesOf, value Form0).
BF_GradGroupOfNodes
GroupsOfNodesOf, value Form1).
BF_GroupOfEdges
GroupsOfEdgesOf, value Form1).
BF_CurlGroupOfEdges
GroupsOfEdgesOf, value Form2).
BF_PerpendicularEdge
BF_Node) (on NodesOf, value Form1P).
BF_CurlPerpendicularEdge
BF_Node) (on NodesOf, value Form2P).
BF_GroupOfPerpendicularEdge
BF_Node) (on NodesOf, value Form1P).
BF_CurlGroupOfPerpendicularEdge
BF_Node) (on NodesOf,
value Form2P).
BF_PerpendicularFacet
BF_Edge)
(on EdgesOf, value Form2P).
BF_DivPerpendicularFacet
BF_Edge)
(on EdgesOf, value Form3).
BF_Region
Region, value Scalar).
BF_RegionX
Region, value Vector).
BF_RegionY
Region, value Vector).
BF_RegionZ
Region, value Vector).
BF_Global
Global, value depends on parameters).
BF_dGlobal
Global, value depends on parameters).
BF_NodeX
BF_Node, 0, 0)
(on NodesOf, value Vector).
BF_NodeY
BF_Node, 0)
(on NodesOf, value Vector).
BF_NodeZ
BF_Node)
(on NodesOf, value Vector).
BF_Zero
Scalar).
BF_One
Scalar).
global-quantity-type:
AliasOf
AssociatedWith
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jacobian jacobian-type:
Vol
Sur
Lin
VolAxi
SurAxi
VolAxiSqu
VolSphShell
Parameters: radius-internal, radius-external <, center-X, center-Y, center-Z, power, 1/infinity >.
VolAxiSphShell
VolAxi, but with spherical shell transformation.
Parameters: radius-internal, radius-external <, center-X, center-Y, center-Z, power, 1/infinity >.
VolAxiSquSphShell
VolAxiSqu, but with spherical shell transformation.
Parameters: radius-internal, radius-external <, center-X, center-Y, center-Z, power, 1/infinity >.
VolRectShell
Parameters: radius-internal, radius-external <, direction, center-X, center-Y, center-Z, power, 1/infinity >.
VolAxiRectShell
VolAxi, but with rectangular shell transformation.
Parameters: radius-internal, radius-external <, direction, center-X, center-Y, center-Z, power, 1/infinity >.
VolAxiSquRectShell
VolAxiSqu, but with rectangular shell transformation.
Parameters: radius-internal, radius-external <, direction, center-X, center-Y, center-Z, power, 1/infinity >.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Integration integration-type:
Gauss
GaussLegendre
element-type:
Line
Triangle
Quadrangle
Tetrahedron
Hexahedron
Prism
Pyramid
Point
Note:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Formulation formulation-type:
FemEquation
local-term-type:
quantity-type:
Local
NameOfSpace function-space-id.
Global
NameOfSpace function-space-id.
Integral
LocalQuantity before its use in an Equation term.
term-op-type:
Dt
DtDof
Dof{} term of the equation.
DtDt
DtDtDof
Dof{} term of the
equation.
JacNL
NeverDt
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Resolution resolution-op:
Generate
[system-id]
Generate the system of equations system-id.
Solve
[system-id]
Solve the system of equations system-id.
GenerateJac
[system-id]
Generate the system of equations system-id using a jacobian matrix (of which the unknowns are corrections dx of the current solution x).
SolveJac
[system-id]
Solve the system of equations system-id using a jacobian matrix (of which the unknowns are corrections dx of the current solution x). Then, Increment the solution (x=x+dx) and compute the relative error dx/x.
GenerateSeparate
[system-id]
Generate iteration matrices separately for system system-id. It is
destined to be used with Update in order to create more efficiently
the actual system to solve (this is only useful in linear transient problems
with one single excitation) or with Lanczos in order to generate the
matrices of a (generalized) eigen value problem.
Update
[system-id, expression]
Update the system of equations system-id (built from iteration
matrices generated separately with GenerateSeparate) with
expression
InitSolution
[system-id]
Initialize the solution of system-id to zero (default) or to the
values given in a Constraint of Init type.
SaveSolution
[system-id]
Save the solution of the system of equations system-id.
SaveSolutions
[system-id]
Save all the solutions available for the system of equations
system-id. This should be used with algorithms that generate more than
one solution at once, e.g. Lanczos or FourierTransform.
TransferSolution
[system-id]
Transfer the solution of system system-id, as an Assign
constraint, to the system of equations defined with a
DestinationSystem command. This is used with the
AssignFromResolution constraint type (see section 4.3 Types for Constraint).
TransferInitSolution
[system-id]
Transfer the solution of system system-id, as an Init
constraint, to the system of equations defined with a
DestinationSystem command. This is used with the
InitFromResolution constraint type (see section 4.3 Types for Constraint).
SetTime
[expression]
Change the current time.
SetFrequency
[system-id, expression]
Change the frequency of system system-id.
SystemCommand
[expression-char]
Execute the system command given by expression-char.
If
[expression] { resolution-op }
If expression is true (nonzero), perform the operations in resolution-op.
If
[expression] { resolution-op }
Else
{ resolution-op }
If expression is true (nonzero), perform the operations in the first resolution-op, else perform the operations in the second resolution-op.
Print
[ system-id <, File expression-char > <, { expression-cst-list } ><, TimeStep { expression-cst-list } >]
Print the system system-id. If the expression-cst-list is given,
print only the values of the degrees of freedom given in that list.
If the TimeStep option is present, limit the printing to the selected
time steps.
Print
[ { expression-list }, < File expression-char > ]
Print the current values of the expressions listed in expression-list.
Lanczos
[system-id, expression-cst, { expression-cst-list } , expression-cst]
Eigen value computation by the Lanczos algorithm. The parameters are: the
system (which has to be generated with GenerateSeparate[]), the size
of the Lanczos space, the indices of the eigen values/vectors to store, the
spectral shift.
FourierTransform
[system-id, system-id, { expression-cst-list }]
On-the-fly computation of a discrete Fourier transform. The parameters are:
the (time domain) system, the destination system in which the result of the
Fourier tranform is to be saved (it should be declared with Type
Complex), the list of frequencies to consider in the discrete Fourier
transform.
TimeLoopTheta
[expression-cst,expression-cst,expression,expression-cst]
{ resolution-op }
Time loop of a theta scheme. The parameters are: the initial time, the end time, the time step and the theta parameter (e.g. 1 for implicit Euler, 0.5 for Crank-Nicholson).
TimeLoopNewmark
[expression-cst,expression-cst,expression,expression-cst,expression-cst]Time loop of a Newmark scheme. The parameters are: the initial time, the end time, the time step, the beta and the gamma parameter.
IterativeLoop
[expression-cst,expression,expression-cst<,expression-cst>]
{ resolution-op }
Iterative loop for nonlinear analysis. The parameters are: the maximum number of iterations (if no convergence), the relaxation factor (multiplies the iterative correction dx) and the relative error to achieve. The optional parameter is a flag for testing purposes.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostProcessing post-value:
Local
To compute a local quantity.
Integral
To integrate the expression over each element.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostOperation print-support:
OnElementsOf
To compute a quantity on the elements belonging to the region group-def, where the solution was computed during the processing stage.
OnRegion
To compute a global quantity associated with the region group-def.
OnGlobal
OnSection
To compute a quantity on a section of the mesh defined by three points (i.e. on the intersection of the mesh with a cutting a plane, specified by three points). Each expression-cst-list must contain exactly three elements (the coordinates of the points).
OnGrid
To compute a quantity in elements of a mesh which differs from the real
support of the solution. OnGrid group-def differs from
OnElementsOf group-def by the reinterpolation that must be
performed.
OnGrid
{ expression, expression, expression }{ expression-cst-list-item | { expression-cst-list } , expression-cst-list-item | { expression-cst-list } , expression-cst-list-item | { expression-cst-list } }
To compute a quantity on a parametric grid. The three expressions
represent the three cartesian coordinates x, y and z, and
can be functions of the current values $A, $B and
$C. The values for $A, $B and $C are specified
by each expression-cst-list-item or expression-cst-list. For
example, OnGrid {Cos[$A], Sin[$A], 0} { 0:2*Pi:Pi/180, 0, 0 } will
compute the quantity on 360 points equally distributed on a circle in the
z=0 plane, and centered on the origin.
OnPoint
To compute a quantity at a point. The expression-cst-list must contain exactly three elements (the coordinates of the point).
OnLine
To compute a quantity along a line (given by its two end points), with an associated number of divisions equal to expression-cst. The interpolation points on the line are equidistant. Each expression-cst-list must contain exactly three elements (the coordinates of the points).
OnPlane
{ expression-cst, expression-cst }
To compute a quantity on a plane (specified by three points), with an associated number of divisions equal to each expression-cst along both generating directions. Each expression-cst-list must contain exactly three elements (the coordinates of the points).
OnBox
{ expression-cst-list } } { expression-cst, expression-cst, expression-cst }
To compute a quantity in a box (specified by four points), with an associated number of divisions equal to each expression-cst along the three generating directions. Each expression-cst-list must contain exactly three elements (the coordinates of the points).
print-option:
File
expression-char
Outputs the result in a file named expression-char.
File
> expression-char
Same as File expression-char, except that, if several File >
expression-char options appear in the same PostOperation, the results
are concatenated in the file expression-char.
File
>> expression-char
Appends the result to a file named expression-char.
Depth
Recursive division of the elements if expression-cst is greater than zero, derefinement if expression-cst is smaller than zero. If expression-cst is equal to zero, evaluation at the barycenter of the elements.
Skin
Smoothing
HarmonicToTime
Converts a harmonic solution into a time-dependent one (with expression-cst steps).
Dimension
Forces the dimension of the elements to consider in an element search. Specifies the problem dimension during an adaptation (h- or p-refinement).
TimeStep
expression-cst-list-item | { expression-cst-list }
Outputs results for the specified time steps only.
Frequency
expression-cst-list-item | { expression-cst-list }
Outputs results for the specified frequencies only.
Format
Outputs results in the specified format.
Adapt
P1 | H1 | H2
Performs p- or h-refinement on the post-processing result, considered as an error map.
Target
Specifies the target for the optimizer during adaptation (error for
P1|H1, number of elements for H2).
Value
expression-cst-list-item | { expression-cst-list }
Specifies acceptable output values for discrete optimization (e.g. the
available interpolation orders with Adapt P1).
Sort
Position | Connection
Sorts the output by position (x, y, z) or by connection (for LINE
elements only).
Iso
Outputs directly contour prints (with expression-cst values) instead of elementary values.
Iso
{ expression-cst-list }
Outputs directly contour prints for the values specified in the expression-cst-list instead of elementary values.
NoNewLine
Print OnRegion or Print OnGlobal).
ChangeOfCoordinates
{ expression, expression, expression }
Changes the coordinates of the results according to the three expressions
given in argument. The three expressions represent the three new
cartesian coordinates x, y and z, and can be functions of
the current values of the cartesian coordinates $X, $Y and
$Z.
ChangeOfValues
{ expression-list }
Changes the values of the results according to the expressions given in argument. The expressions represent the new values (x-compoment, y-component, etc.), and can be functions of the current values of the solution ($Val0, $Val1, etc.).
post-operation-fmt:
Gmsh
GmshParsed
Table
OnLine plots, normal to the plane for OnPlane
plots, parametric coordinates for parametric OnGrid plots, etc.
TimeTable
Gnuplot
Table format, except that
a new line is created for each node of each element, with a repetition of
the first node if the number of nodes in the element is greater than 2. This
permits to draw unstructured meshes and nice three-dimensional elevation
plots in Gnuplot. The columns are: element-type element-index
x-coord y-coord z-coord real real real
values. The three real numbers preceding the values
contain context-dependent information, depending on the type of plot:
curvilinear abscissa for OnLine plots, normal to the plane for
OnPlane plots, parametric coordinates for parametric OnGrid
plots, etc.
Adaptation
-adapt command line option.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The simplest constant expression consists of an integer or a real number as in
21 -3 |
or
-3.1415 27e3 -290.53e-12 |
Using operators and the classic math functions, constant-ids can be defined:
c1 = Sin[2/3*3.1415] * 5000^2; c2 = -1/c1; |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Group examples Let us assume that some elements in the input mesh have the region numbers 1000, 2000 and 3000. In the definitions
Group {
Air = Region[1000]; Core = Region[2000]; Inductor = Region[3000];
NonConductingDomain = Region[{Air, Core}];
ConductingDomain = Region[{Inductor}];
}
|
Air, Core, Inductor are identifiers of elementary
region groups while NonConductingDomain and
ConductingDomain are global region groups.
Groups of function type contain lists of entities built on the region groups appearing in their arguments. For example,
NodesOf[NonConductingDomain] |
represents the group of nodes of geometrical elements belonging to the regions
in NonConductingDomain and
EdgesOf[DomainC, Not SkinDomainC] |
represents the group of edges of geometrical elements belonging to the regions
in DomainC but not to those of SkinDomainC.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Function examples
A physical characteristic is a piecewise defined function. The magnetic
permeability mu[] can for example be defined in the considered
regions by
Function {
mu[Air] = 4.e-7*Pi;
mu[Core] = 1000.*4.e-7*Pi;
}
|
A nonlinear characteristic can be defined through an expression with arguments, e.g.
Function {
mu0 = 4.e-7*Pi;
a1 = 1000.; b1 = 100.; // Constants
mu[NonlinearCore] = mu0 + 1./(a1+b1*Norm[$1]^6);
}
|
where function mu[] in region NonLinearCore has one argument
$1 which has to be the magnetic flux density. This function is
actually called when writing the equations of a formulation, which permits
to directly extend it to a nonlinear form by adding only the necessary
arguments. For example, in a magnetic vector potential formulation, one may
write mu[{Curl a}] instead of mu[] in Equation terms
(see section 5.8 Formulation examples). Multiple arguments can be specified in a
similar way: writing mu[{Curl a},{T}] in an Equation term
will provide the function mu[] with two usable arguments, $1
(the magnetic flux density) and $2 (the temperature).
It is also possible to directly interpolate one-dimensional functions from tabulated data. In the following example, the function f(x) as well as its derivative f'(x) are interpolated from the (x,f(x)) couples (0,0.65), (1,0.72), (2,0.98) and (3,1.12):
Function {
couples = {0, 0.65 , 1, 0.72 , 2, 0.98 , 3, 1.12};
f[] = InterpolationLinear[$1]{List[couples]};
dfdx[] = dInterpolationLinear[$1]{List[couples]};
}
|
The function f[] may then be called in an Equation
term of a Formulation with one argument, x. Notice how the list
of constants List[couples] is supplied as a list of parameters to the
built-in function InterpolationLinear (see section 2.2 Constants, as well as
2.4 Functions). In order to facilitate the construction of such
interpolations, the couples can also be specified in two separate lists,
merged with the alternate list ListAlt command (see section 2.2 Constants):
Function {
data_x = {0, 1, 2, 3};
data_f = {0.65, 0.72, 0.98, 1.12};
f[] = InterpolationLinear[$1]{ListAlt[data_x, data_f]};
dfdx[] = dInterpolationLinear[$1]{ListAlt[data_x, data_f]};
}
|
In order to optimize the evaluation time of complex expressions,
registers may be used (see section 2.7 Registers). For example, the evaluation of
g[] = f[$1]*Sin[f[$1]^2] would require two (costly) linear
interpolations. But the result of the evaluation of f[] may be stored
in a register (for example the register 0) with
g[] = f[$1]#0 * Sin[#0^2]; |
thus reducing the number of evaluations of f[] (and of the
argument $1) to one.
A function can also be time dependent, e.g.
Function {
Freq = 50.; Phase = 30./180.*Pi; // Constants
TimeFct_Sin[] = Sin [ 2.*Pi*Freq * $Time + Phase ];
TimeFct_Exp[] = Exp [ - $Time / 0.0119 ];
TimeFct_ExtSin[] = F_Sin_wt_p [] {2.*Pi*Freq, Phase};
}
|
Note that TimeFct_ExtSin[] is identical to TimeFct_Sin[] in a
time domain analysis, but also permits to define phasors implicitely in the
case of harmonic analyses.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Constraint examples
Constraints are referred to in FunctionSpaces and are usually used
for boundary conditions (Assign type).
For example, essential conditions on two surface regions,
Surf0 and Surf1, will be first defined by
Constraint {
{ Name DirichletBoundaryCondition1; Type Assign;
Case {
{ Region Surf0; Value 0.; }
{ Region Surf1; Value 1.; }
}
}
}
|
The way the Values are associated with Regions (with their
nodes, their edges, their global regions, ...) is defined in the
FunctionSpaces which use the Constraint. In other words, a
Constraint defines data but does not define the method to process
them. A time dependent essential boundary condition on Surf1 would be
introduced as (cf. 5.3 Function examples for the definition of
TimeFct_Exp[]):
{ Region Surf1; Value 1.; TimeFunction 3*TimeFct_Exp[] }
|
It is important to notice that the time dependence cannot be
introduced in the Value field, since the Value is only
evaluated once during the pre-processing.
Other constraints can be referred to in Formulations. It is the case of
those defining electrical circuit connections (Network type), e.g.
Constraint {
{ Name ElectricalCircuit; Type Network;
Case Circuit1 {
{ Region VoltageSource; Branch {1,2}; }
{ Region PrimaryCoil; Branch {1,2}; }
}
Case Circuit2 {
{ Region SecondaryCoil; Branch {1,2}; }
{ Region Charge; Branch {1,2}; }
}
}
}
|
which defines two non-connected circuits (Circuit1 and Circuit2),
with an independent numbering of nodes: region VoltageSource is connected in
parallel with region PrimaryCoil, and region SecondaryCoil is
connected in parallel with region Charge.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
FunctionSpace examples Various discrete function spaces can be defined in the frame of the finite element method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The most elementary function space is the nodal finite element space, defined on a mesh of a domain W and denoted S0(W) (associated finite elements can be of various geometries), and associated with essential boundary conditions (Dirichlet conditions). It contains 0-forms, i.e. scalar fields of potential type:
v = Sum [ vn * sn, for all n in N ], v in S0(W)
where N is the set of nodes of W, sn is the nodal basis function associated with node n and vn is the value of v at node n. It is defined by
FunctionSpace {
{ Name Hgrad_v; Type Form0;
BasisFunction {
{ Name sn; NameOfCoef vn; Function BF_Node;
Support Domain; Entity NodesOf[All]; }
}
Constraint {
{ NameOfCoef vn; EntityType NodesOf;
NameOfConstraint DirichletBoundaryCondition1; }
}
}
}
|
Function sn is the built-in basis function BF_Node associated with
all nodes (NodesOf) in the mesh of W (Domain). Previously
defined Constraint DirichletBoundaryCondition1
(see section 5.4 Constraint examples) is used as boundary condition.
In the example above, Entity NodesOf[All] is preferred to
Entity NodesOf[Domain].
In this way, the list of all the nodes of Domain will not have to be
generated. All the nodes of each geometrical element in Support Domain
will be directly taken into account.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Higher order finite elements can be directly taken into account by BF_Node.
Hierarchical finite elements for 0-forms can be used by simply adding other basis
functions (associated with other geometrical entities, e.g. edges and facets) to
BasisFunction, e.g.
...
BasisFunction {
{ Name sn; NameOfCoef vn; Function BF_Node;
Support Domain; Entity NodesOf[All]; }
{ Name s2; NameOfCoef v2; Function BF_Node_2E;
Support Domain; Entity EdgesOf[All]; }
}
...
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A scalar potential with floating values vf on certain boundaries Gf, f in Cf, e.g. for electrostatic problems, can be expressed as
v = Sum [ vn * sn, for all n in Nv ] + Sum [ vf * sf, for all f in Cf ], v in S0(W)
where Nv is the set of inner nodes of W and each function sf
is associated with the group of nodes of boundary Gf, f in Cf
(SkinDomainC); sf is the sum of the nodal basis functions
of all the nodes of Cf. Its function space is defined by
FunctionSpace {
{ Name Hgrad_v_floating; Type Form0;
BasisFunction {
{ Name sn; NameOfCoef vn; Function BF_Node;
Support Domain; Entity NodesOf[All, Not SkinDomainC]; }
{ Name sf; NameOfCoef vf; Function BF_GroupOfNodes;
Support Domain; Entity GroupsOfNodesOf[SkinDomainC]; }
}
GlobalQuantity {
{ Name GlobalElectricPotential; Type AliasOf; NameOfCoef vf; }
{ Name GlobalElectricCharge; Type AssociatedWith;
NameOfCoef vf; }
}
Constraint { ... }
}
}
|
Two global quantities have been associated with this space: the electric
potential GlobalElectricPotential, being an alias of
coefficient vf, and the electric charge
GlobalElectricCharge, being associated with coefficient
vf.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Another space is the edge finite element space, denoted S1(W), containing 1-forms, i.e. curl-conform fields:
h = Sum [ he * se, for all e in E ], h in S1(W)
where E is the set of edges of W, se is the edge basis function for edge e and he is the circulation of h along edge e. It is defined by
FunctionSpace {
{ Name Hcurl_h; Type Form1;
BasisFunction {
{ Name se; NameOfCoef he; Function BF_Edge;
Support Domain; Entity EdgesOf[All]; }
}
Constraint { ... }
}
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A 1-form function space containing vector potentials can be associated
with a gauge condition, which can be defined as a constraint, e.g. a
zero value is fixed for all circulations along edges of a tree
(EdgesOfTreeIn) built in the mesh (Domain), having to be
complete on certain boundaries (StartingOn Surf):
Constraint {
{ Name GaugeCondition_a_Mag_3D; Type Assign;
Case {
{ Region Domain; SubRegion Surf; Value 0.; }
}
}
}
FunctionSpace {
{ Name Hcurl_a_Gauge; Type Form1;
BasisFunction {
{ Name se; NameOfCoef ae; Function BF_Edge;
Support Domain; Entity EdgesOf[All]; }
}
Constraint {
{ NameOfCoef ae;
EntityType EdgesOfTreeIn; EntitySubType StartingOn;
NameOfConstraint GaugeCondition_a_Mag_3D; }
...
}
}
}
|
The same gauge could also be defined in the BasisFunction field itself, by
limiting the set of entities supporting the unknowns:
Entity EdgesOf[All] would then be replaced by
Entity EdgesOfTreeIn[Domain, StartingOn Surf].
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A 1-form function space, containing curl free fields in certain regions WcC
(DomainCC) of W, which are the complementary part of Wc
(DomainC) in W, can be explicitly characterized by
h = Sum [ hk * sk, for all e in Ec ] + Sum [ phin * vn, for all n in NcC ], h in S1(W)
where Ec is the set of inner edges of W, NcC is the set of nodes inside WcC and on its boundary dWcC, sk is an edge basis function and vn is a vector nodal function. Such a space, coupling a vector field with a scalar potential, can be defined by
FunctionSpace {
{ Name Hcurl_hphi; Type Form1;
BasisFunction {
{ Name sk; NameOfCoef hk; Function BF_Edge;
Support DomainC; Entity EdgesOf[All, Not SkinDomainC]; }
{ Name vn; NameOfCoef phin; Function BF_GradNode;
Support DomainCC; Entity NodesOf[All]; }
{ Name vn; NameOfCoef phic; Function BF_GroupOfEdges;
Support DomainC; Entity GroupsOfEdgesOnNodesOf[SkinDomainC];}
}
Constraint {
{ NameOfCoef hk;
EntityType EdgesOf; NameOfConstraint MagneticField; }
{ NameOfCoef phin;
EntityType NodesOf; NameOfConstraint MagneticScalarPotential; }
{ NameOfCoef phic;
EntityType NodesOf; NameOfConstraint MagneticScalarPotential; }
}
}
}
|
This example points out the definition of a piecewise defined basis function, e.g.
function vn being defined with BF_GradNode in DomainCC and
BF_GroupOfEdges in DomainC. This leads to an easy coupling
between these regions.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In case a multiply connected domain WcC is considered, basis functions
associated with cuts (SurfaceCut) have to be added to the previous
basis functions, which gives the function space below:
Group {
_TransitionLayer_SkinDomainC_ =
ElementsOf[SkinDomainC, OnOneSideOf SurfaceCut];
}
FunctionSpace {
{ Name Hcurl_hphi; Type Form1;
BasisFunction {
... same as above ...
{ Name sc; NameOfCoef Ic; Function BF_GradGroupOfNodes;
Support ElementsOf[DomainCC, OnOneSideOf SurfaceCut];
Entity GroupsOfNodesOf[SurfaceCut]; }
{ Name sc; NameOfCoef Icc; Function BF_GroupOfEdges;
Support DomainC;
Entity GroupsOfEdgesOf
[SurfaceCut,
InSupport _TransitionLayer_SkinDomainC_]; }
}
GlobalQuantity {
{ Name I; Type AliasOf ; NameOfCoef Ic; }
{ Name U; Type AssociatedWith; NameOfCoef Ic; }
}
Constraint {
... same as above ...
{ NameOfCoef Ic;
EntityType GroupsOfNodesOf; NameOfConstraint Current; }
{ NameOfCoef Icc;
EntityType GroupsOfNodesOf; NameOfConstraint Current; }
{ NameOfCoef U;
EntityType GroupsOfNodesOf; NameOfConstraint Voltage; }
}
}
}
|
Global quantities associated with the cuts, i.e. currents and voltages if h is the magnetic field, have also been defined.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jacobian examples
A simple Jacobian method is for volume transformations (of n-D
regions in n-D geometries; n = 1, 2 or 3),
e.g. in region Domain,
Jacobian {
{ Name Vol;
Case {
{ Region Domain; Jacobian Vol; }
}
}
}
|
Jacobian VolAxi would define a volume Jacobian for axisymmetrical problems.
A Jacobian method can also be piecewise defined, in DomainInf, where
an infinite geometrical transformation has to be made using two constant
parameters (inner and outer radius of a spherical shell), and in all the
other regions (All, being the default); in each case, a volume
Jacobian is used. This method is defined by:
Jacobian {
{ Name Vol;
Case {
{ Region DomainInf; Jacobian VolSphShell {Val_Rint, Val_Rext}; }
{ Region All; Jacobian Vol; }
}
}
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Integration examples
A commonly used numerical integration method is the Gauss integration,
with a number of integration points (NumberOfPoints) depending on
geometrical element types (GeoElement), i.e.
Integration {
{ Name Int_1;
Case { {Type Gauss;
Case { { GeoElement Triangle ; NumberOfPoints 4; }
{ GeoElement Quadrangle ; NumberOfPoints 4; }
{ GeoElement Tetrahedron; NumberOfPoints 4; }
{ GeoElement Hexahedron ; NumberOfPoints 6; }
{ GeoElement Prism ; NumberOfPoints 9; } }
}
}
}
}
|
The method above is valid for both 2D and 3D problems, for different kinds of elements.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Formulation examples
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An electrostatic formulation using an electric scalar potential v, i.e.
( epsr grad v, grad vp ) W = 0, for all vp in S0(W),
is expressed by
Formulation {
{ Name Electrostatics_v; Type FemEquation;
Quantity {
{ Name v; Type Local; NameOfSpace Hgrad_v; }
}
Equation {
Galerkin { [ epsr[] * Dof{Grad v} , {Grad v} ];
In Domain; Jacobian Vol; Integration Int_1; }
}
}
}
|
The density of the Galerkin term is a copy of the symbolic form of
the formulation, i.e. the product of a relative permittivity function
epsr[] by a vector of degrees of freedom (Dof{.}); the
scalar product of this with the gradient of test function v results
in a symmetrical matrix.
Note that another Quantity could be defined for test functions,
e.g. vp defined by { Name vp; Type Local; NameOfSpace
Hgrad_v; }. However, its use would result in the computation of a full
matrix and consequently in a loss of efficiency.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An extension of the formulation above can be made to take floating
potentials and electrical charges into account (the latter being defined in
FunctionSpace Hgrad_v_floating), i.e.
Formulation {
{ Name Electrostatics_v_floating; Type FemEquation;
Quantity {
{ Name v; Type Local; NameOfSpace Hgrad_v_floating; }
{ Name V; Type Global;
NameOfSpace Hgrad_v_floating [GlobalElectricPotential]; }
{ Name Q; Type Global;
NameOfSpace Hgrad_v_floating [GlobalElectricCharge]; }
}
Equation {
Galerkin { [ epsr[] * Dof{Grad v} , {Grad v} ];
In Domain; Jacobian Vol; Integration Int_1; }
GlobalTerm { [ - Dof{Q}/eps0 , {V} ]; In SkinDomainC; }
}
}
}
|
with the predefinition Function { eps0 = 8.854187818e-12; }.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A magnetostatic 3D vector potential formulation
( nu curl a , curl ap ) W - ( js , ap ) Ws = 0, for all ap in S1(W) with gauge condition,
with a source current density js in inductors Ws, is expressed by
Formulation {
{ Name Magnetostatics_a_3D; Type FemEquation;
Quantity {
{ Name a; Type Local; NameOfSpace Hcurl_a_Gauge; }
}
Equation {
Galerkin { [ nu[] * Dof{Curl a} , {Curl a} ];
In Domain; Jacobian Vol; Integration Int_1; }
Galerkin { [ - SourceCurrentDensity[] , {a} ];
In DomainWithSourceCurrentDensity;
Jacobian Vol; Integration Int_1; }
}
}
}
|
Note that js is here given by a function SourceCurrentDensity[],
but could also be given by data computed from another problem,
e.g. from an electrokinetic problem (coupling of formulations) or
from a fully fixed function space (constraints fixing the density, which is
usually more efficient in time domain analyses).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A magnetodynamic 3D or 2D h-phi formulation, i.e. coupling the magnetic field h with a magnetic scalar potential phi,
Dt ( mu h , hp ) W + ( ro curl h , curl hp ) Wc = 0, for all hp in S1(W),
can be expressed by
Formulation {
{ Name Magnetodynamics_hphi; Type FemEquation;
Quantity {
{ Name h; Type Local; NameOfSpace Hcurl_hphi; }
}
Equation {
Galerkin { Dt [ mu[] * Dof{h} , {h} ];
In Domain; Jacobian Vol; Integration Int_1; }
Galerkin { [ rho[] * Dof{Curl h} , {Curl h} ];
In DomainC; Jacobian Vol; Integration Int_1; }
}
}
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In case nonlinear physical characteristics are considered, arguments are
used for associated functions, e.g. mu[{h}]. Several test
functions can be considered in an Equation field. Consequently,
mixed formulations can be defined.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Resolution examples
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A static resolution, e.g. for the electrostatic formulation
(see section 5.8 Formulation examples), can be defined by
Resolution {
{ Name Electrostatics_v;
System {
{ Name Sys_Ele; NameOfFormulation Electrostatics_v; }
}
Operation {
Generate[Sys_Ele]; Solve[Sys_Ele]; SaveSolution[Sys_Ele];
}
}
}
|
The generation (Generate) of the matrix of the system Sys_Ele
will be made with the formulation Electrostatics_v, followed by its
solving (Solve) and the saving of the solution (SaveSolution).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A frequency domain resolution, e.g. for the magnetodynamic h-phi
formulation (see section 5.8 Formulation examples), is given by
Resolution {
{ Name Magnetodynamics_hphi;
System {
{ Name Sys_Mag; NameOfFormulation Magnetodynamics_hphi;
Frequency Freq; }
}
Operation {
Generate[Sys_Mag]; Solve[Sys_Mag]; SaveSolution[Sys_Mag];
}
}
}
|
preceded by the definition of constant Freq, e.g.
Function {
Freq = 50.;
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A time domain resolution, e.g. for the same magnetodynamic h-phi
formulation (see section 5.8 Formulation examples), is given by
Resolution {
{ Name Magnetodynamics_hphi_Time;
System {
{ Name Sys_Mag; NameOfFormulation Magnetodynamics_hphi; }
}
Operation {
InitSolution[Sys_Mag]; SaveSolution[Sys_Mag];
TimeLoopTheta[Mag_Time0, Mag_TimeMax, Mag_DTime[], Mag_Theta[]] {
Generate[Sys_Mag]; Solve[Sys_Mag]; SaveSolution[Sys_Mag];
}
}
}
}
|
If, e.g. the Resolution above is preceded by the constant and function
definitions below
Function {
Tc = 10.e-3;
Mag_Time0 = 0.; Mag_TimeMax = 2.*Tc; Mag_DTime[] = Tc/20.;
Mag_Theta[] = 1./2.;
}
|
the performed time analysis will be a Crank-Nicolson scheme (theta-scheme
with Theta = 0.5) with initial time 0 ms, end time 20 ms and
time step 1 ms.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In case a nonlinear problem is solved, an iterative loop has to be defined in an appropriate level of the recursive resolution operations, e.g. for the magnetodynamic problem above,
...
Operation {
InitSolution[Sys_Mag]; SaveSolution[Sys_Mag];
TimeLoopTheta[Mag_Time0, Mag_TimeMax, Mag_DTime[], Mag_Theta[]] {
IterativeLoop[NL_NbrMax, NL_Eps, NL_Relax] {
GenerateJac[Sys_Mag]; SolveJac[Sys_Mag];
}
SaveSolution[Sys_Mag];
}
}
...
|
preceded by constant definitions, e.g.
Function {
NL_Eps = 1.e-4; NL_Relax = 1.; NL_NbrMax = 80;
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A coupled problem, e.g. magnetodynamic (in frequency domain;
Frequency Freq) - thermal (in time domain) coupling, with temperature
dependent characteristics (e.g. rho[{T}], ...), can be defined by:
Resolution {
{ Name MagnetoThermalCoupling_hphi_T;
System {
{ Name Sys_Mag; NameOfFormulation Magnetodynamics_hphi;
Frequency Freq; }
{ Name Sys_The; NameOfFormulation Thermal_T; }
}
Operation {
InitSolution[Sys_Mag]; InitSolution[Sys_The];
IterativeLoop[NL_NbrMax, NL_Eps, NL_Relax] {
GenerateJac[Sys_Mag]; SolveJac[Sys_Mag];
GenerateJac[Sys_The]; SolveJac[Sys_The];
}
SaveSolution[Sys_Mag]; SaveSolution[Sys_The];
}
}
}
|
Two systems of equations, Sys_Mag and Sys_The, will be solved
iteratively until convergence (Criterion), using a relaxation factor
(RelaxationFactor).
It can be seen through these examples that many resolutions can be linked or nested directly by the user, which gives a great freedom for coupled problems.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostProcessing examples
The quantities to be post-computed based on a solution of a resolution are
defined e.g. for the electrostatic problem (see section 5.8 Formulation examples;
see section 5.9 Resolution examples), for the solution associated with the
formulation Electrostatics_v, by
PostProcessing {
{ Name EleSta_v; NameOfFormulation Electrostatics_v;
Quantity {
{ Name v; Value { Local { [ {v} ]; In Domain; } } }
{ Name e; Value { Local { [ -{Grad v} ]; In Domain; } } }
{ Name d; Value { Local { [ -eps0*epsr[] *{Grad v} ];
In Domain; } } }
}
}
}
|
The electric scalar potential v (v), the electric field
e (e) and the electric flux density d (d) can
all be computed from the solution. They are all defined in the region
Domain.
The quantities for the solution associated with the formulation
Electrostatics_v_floating are defined by
PostProcessing {
{ Name EleSta_vf; NameOfFormulation Electrostatics_v_floating;
Quantity {
... same as above ...
{ Name Q; Value { Local { [ {Q} ]; In SkinDomainC; } } }
{ Name V; Value { Local { [ {V} ]; In SkinDomainC; } } }
}
}
}
|
which points out the way to define post-quantities based on global quantities.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
PostOperation examples
The simplest post-processing operation is the generation of maps of local
quantities, i.e. the display of the computed fields on the mesh. For
example, using the PostProcessing defined in 5.10 PostProcessing examples, the maps of the electric scalar potential and of the electric
field on the elements of the region Domain are defined as:
PostOperation {
{ Name Map_v_e; NameOfPostprocessing EleSta_v ;
Operation {
Print [ v, OnElementsOf Domain, File "map_v.pos" ];
Print [ e, OnElementsOf Domain, File "map_e.pos" ];
}
}
}
|
It is also possible to display local quantities on sections of the mesh, here for example on the plane containing the points (0,0,1), (1,0,1) and (0,1,1):
Print [ v, OnSection { {0,0,1} {1,0,1} {0,1,1} }, File "sec_v.pos" ];
|
Finally, local quantities can also be interpolated on another mesh than the one on which they have been computed. Six types of grids can be specified for this interpolation: a single point, a set of points evenly distributed on a line, a set of points evenly distributed on a plane, a set of points evenly distributed in a box, a set of points defined by a parametric equation, and a set of elements belonging to a different mesh than the original one:
Print [ e, OnPoint {0,0,1} ];
Print [ e, OnLine { {0,0,1} {1,0,1} } {125} ];
Print [ e, OnPlane { {0,0,1} {1,0,1} {0,1,1} } {125, 75} ];
Print [ e, OnBox { {0,0,1} {1,0,1} {0,1,1} {0,0,2} } {125, 75, 85} ];
Print [ e, OnGrid {$A, $B, 1} { 0:1:1/125, 0:1:1/75, 0 } ];
Print [ e, OnGrid Domain2 ];
|
Many options can be used to modify the aspect of all these maps, as well as
the default behaviour of the Print commands. See 4.10 Types for PostOperation, to get the list of all these options. For example, to obtain
a map of the scalar potential at the barycenters of the elements on the
boundary of the region Domain, in a table oriented format appended to
an already existing file out.txt, the operation would be:
Print [ v, OnElementsOf Domain, Depth 0, Skin, Format Table,
File >> "out.txt" ];
|
Global quantities, which are associated with regions (and not with the
elements of the mesh of these regions), are displayed thanks to the
OnRegion operation. For example, the global potential and charge on
the region SkinDomainC can be displayed with:
PostOperation {
{ Name Val_V_Q; NameOfPostprocessing EleSta_vf ;
Operation {
Print [ V, OnRegion SkinDomainC ];
Print [ Q, OnRegion SkinDomainC ];
}
}
}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
6.1 Electrostatic problem 6.2 Magnetostatic problem 6.3 Magnetodynamic problem
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An elementary electrostatic problem is first considered. The formulation used is an electric scalar potential formulation (file `EleSta_v.pro', including files `Jacobian_Lib.pro' and `Integration_Lib.pro'). It is applied to a microstrip line (file `mStrip.pro'), of which the geometry is defined in the file `mStrip.geo': see C. Gmsh examples. The geometry is two-dimensional; one half of the structure is considered by symmetry.
The structure of the following files points out the separation of the data describing the particular problem and the method used to solve it, and therefore how it is possible to build black boxes adapted to well defined categories of problems. The files are commented (see section 1.3 Comments) and can be run without any modification.
/* -------------------------------------------------------------------
File "mStrip.pro"
This file defines the problem dependent data structures for the
microstrip problem.
To compute the solution:
getdp mStrip -solve EleSta_v
To compute post-results:
getdp mStrip -pos Map
or getdp mStrip -pos Cut
------------------------------------------------------------------- */
Group {
/* Let's start by defining the interface (i.e. elementary groups)
between the mesh file and GetDP (no mesh object is defined, so
the default mesh will be assumed to be in GMSH format and located
in "mStrip.msh") */
Air = Region[101]; Diel1 = Region[111];
Ground = Region[120]; Line = Region[121];
SurfInf = Region[130];
/* We can then define a global group (used in "EleSta_v.pro",
the file containing the function spaces and formulations) */
DomainCC_Ele = Region[{Air, Diel1}];
}
Function {
/* The relative permittivity (needed in the formulation) is piecewise
defined in elementary groups */
epsr[Air] = 1.;
epsr[Diel1] = 9.8;
}
Constraint {
/* Now, some Dirichlet conditions are defined. The name
'ElectricScalarPotential' refers to the constraint name given in
the function space */
{ Name ElectricScalarPotential; Type Assign;
Case {
{ Region Region[{Ground, SurfInf}]; Value 0.; }
{ Region Line; Value 1.e-3; }
}
}
}
/* The formulation used and its tools, considered as being
in a black box, can now be included */
Include "Jacobian_Lib.pro"
Include "Integration_Lib.pro"
Include "EleSta_v.pro"
/* Finally, we can define some operations to output results */
e = 1.e-7;
PostOperation {
{ Name Map; NameOfPostProcessing EleSta_v;
Operation {
Print [ v, OnElementsOf DomainCC_Ele, File "mStrip_v.pos" ];
Print [ e, OnElementsOf DomainCC_Ele, File "mStrip_e.pos" ];
}
}
{ Name Cut; NameOfPostProcessing EleSta_v;
Operation {
Print [ e, OnLine {{e,e,0}{10.e-3,e,0}} {500}, File "Cut_e" ];
}
}
}
/* -------------------------------------------------------------------
File "EleSta_v.pro"
Electrostatics - Electric scalar potential v formulation
-------------------------------------------------------------------
I N P U T
---------
Global Groups : (Extension '_Ele' is for Electric problem)
-------------
Domain_Ele Whole electric domain (not used)
DomainCC_Ele Nonconducting regions
DomainC_Ele Conducting regions (not used)
Function :
--------
epsr[] Relative permittivity
Constraint :
----------
ElectricScalarPotential Fixed electric scalar potential
(classical boundary condition)
Physical constants :
------------------ */
eps0 = 8.854187818e-12;
Group {
DefineGroup[ Domain_Ele, DomainCC_Ele, DomainC_Ele ];
}
Function {
DefineFunction[ epsr ];
}
FunctionSpace {
{ Name Hgrad_v_Ele; Type Form0;
BasisFunction {
// v = v s , for all nodes
// n n
{ Name sn; NameOfCoef vn; Function BF_Node;
Support DomainCC_Ele; Entity NodesOf[ All ]; }
}
Constraint {
{ NameOfCoef vn; EntityType NodesOf;
NameOfConstraint ElectricScalarPotential; }
}
}
}
Formulation {
{ Name Electrostatics_v; Type FemEquation;
Quantity {
{ Name v; Type Local; NameOfSpace Hgrad_v_Ele; }
}
Equation {
Galerkin { [ epsr[] * Dof{d v} , {d v} ]; In DomainCC_Ele;
Jacobian Vol; Integration GradGrad; }
}
}
}
Resolution {
{ Name EleSta_v;
System {
{ Name Sys_Ele; NameOfFormulation Electrostatics_v; }
}
Operation {
Generate[Sys_Ele]; Solve[Sys_Ele]; SaveSolution[Sys_Ele];
}
}
}
PostProcessing {
{ Name EleSta_v; NameOfFormulation Electrostatics_v;
Quantity {
{ Name v;
Value {
Local { [ {v} ]; In DomainCC_Ele; Jacobian Vol; }
}
}
{ Name e;
Value {
Local { [ -{d v} ]; In DomainCC_Ele; Jacobian Vol; }
}
}
{ Name d;
Value {
Local { [ -eps0*epsr[] * {d v} ]; In DomainCC_Ele;
Jacobian Vol; }
}
}
}
}
}
/* -------------------------------------------------------------------
File "Jacobian_Lib.pro"
Definition of a jacobian method
-------------------------------------------------------------------
I N P U T
---------
GlobalGroup :
-----------
DomainInf Regions with Spherical Shell Transformation
Parameters :
----------
Val_Rint, Val_Rext Inner and outer radius of the Spherical Shell
of DomainInf
*/
Group {
DefineGroup[ DomainInf ] ;
DefineVariable[ Val_Rint, Val_Rext ] ;
}
Jacobian {
{ Name Vol ;
Case { { Region DomainInf ;
Jacobian VolSphShell {Val_Rint, Val_Rext} ; }
{ Region All ; Jacobian Vol ; }
}
}
}
/* -------------------------------------------------------------------
File "Integration_Lib.pro"
Definition of integration methods
------------------------------------------------------------------- */
Integration {
{ Name GradGrad ;
Case { {Type Gauss ;
Case { { GeoElement Triangle ; NumberOfPoints 4 ; }
{ GeoElement Quadrangle ; NumberOfPoints 4 ; }
{ GeoElement Tetrahedron ; NumberOfPoints 4 ; }
{ GeoElement Hexahedron ; NumberOfPoints 6 ; }
{ GeoElement Prism ; NumberOfPoints 9 ; } }
}
}
}
{ Name CurlCurl ;
Case { {Type Gauss ;
Case { { GeoElement Triangle ; NumberOfPoints 4 ; }
{ GeoElement Quadrangle ; NumberOfPoints 4 ; }
{ GeoElement Tetrahedron ; NumberOfPoints 4 ; }
{ GeoElement Hexahedron ; NumberOfPoints 6 ; }
{ GeoElement Prism ; NumberOfPoints 9 ; } }
}
}
}
}
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A magnetostatic problem is considered. The formulation used is a 2D magnetic vector potential formulation (see file `MagSta_a_2D.pro'). It is applied to a core-inductor system (file `CoreSta.pro'), of which the geometry is defined in file `Core.geo' (see section C. Gmsh examples). The geometry is two-dimensional; one fourth of the structure is considered by symmetry.
The jacobian and integration methods used are the same as for the electrostatic problem presented in 6.1 Electrostatic problem.
/* -------------------------------------------------------------------
File "CoreSta.pro"
This file defines the problem dependent data structures for the
static core-inductor problem.
To compute the solution:
getdp CoreSta -msh Core.msh -solve MagSta_a_2D
To compute post-results:
getdp CoreSta -msh Core.msh -pos Map_a
------------------------------------------------------------------- */
Group {
Air = Region[ 101 ]; Core = Region[ 102 ];
Ind = Region[ 103 ]; AirInf = Region[ 111 ];
SurfaceGh0 = Region[ 1100 ]; SurfaceGe0 = Region[ 1101 ];
SurfaceGInf = Region[ 1102 ];
Val_Rint = 200.e-3;
Val_Rext = 250.e-3;
DomainCC_Mag = Region[ {Air, AirInf, Core, Ind} ];
DomainC_Mag = Region[ {} ];
DomainS_Mag = Region[ {Ind} ]; // Stranded inductor
DomainInf = Region[ {AirInf} ];
Domain_Mag = Region[ {DomainCC_Mag, DomainC_Mag} ];
}
Function {
mu0 = 4.e-7 * Pi;
murCore = 100.;
nu [ Region[{Air, Ind, AirInf}] ] = 1. / mu0;
nu [ Core ] = 1. / (murCore * mu0);
Sc[ Ind ] = 2.5e-2 * 5.e-2;
}
Constraint {
{ Name MagneticVectorPotential_2D;
Case {
{ Region SurfaceGe0 ; Value 0.; }
{ Region SurfaceGInf; Value 0.; }
}
}
Val_I_1_ = 0.01 * 1000.;
{ Name SourceCurrentDensityZ;
Case {
{ Region Ind; Value Val_I_1_/Sc[]; }
}
}
}
Include "Jacobian_Lib.pro"
Include "Integration_Lib.pro"
Include "MagSta_a_2D.pro"
e = 1.e-5;
p1 = {e,e,0};
p2 = {0.12,e,0};
PostOperation {
{ Name Map_a; NameOfPostProcessing MagSta_a_2D;
Operation {
Print[ az, OnElementsOf Domain_Mag, File "CoreSta_a.pos" ];
Print[ b, OnLine{{List[p1]}{List[p2]}} {1000}, File "k_a" ];
}
}
}
/* -------------------------------------------------------------------
File "MagSta_a_2D.pro"
Magnetostatics - Magnetic vector potential a formulation (2D)
-------------------------------------------------------------------
I N P U T
---------
GlobalGroup : (Extension '_Mag' is for Magnetic problem)
-----------
Domain_Mag Whole magnetic domain
DomainS_Mag Inductor regions (Source)
Function :
--------
nu[] Magnetic reluctivity
Constraint :
----------
MagneticVectorPotential_2D
Fixed magnetic vector potential (2D)
(classical boundary condition)
SourceCurrentDensityZ Fixed source current density (in Z direction)
*/
Group {
DefineGroup[ Domain_Mag, DomainS_Mag ];
}
Function {
DefineFunction[ nu ];
}
FunctionSpace {
// Magnetic vector potential a (b = curl a)
{ Name Hcurl_a_Mag_2D; Type Form1P;
BasisFunction {
// a = a s
// e e
{ Name se; NameOfCoef ae; Function BF_PerpendicularEdge;
Support Domain_Mag; Entity NodesOf[ All ]; }
}
Constraint {
{ NameOfCoef ae; EntityType NodesOf;
NameOfConstraint MagneticVectorPotential_2D; }
}
}
// Source current density js (fully fixed space)
{ Name Hregion_j_Mag_2D; Type Vector;
BasisFunction {
{ Name sr; NameOfCoef jsr; Function BF_RegionZ;
Support DomainS_Mag; Entity DomainS_Mag; }
}
Constraint {
{ NameOfCoef jsr; EntityType Region;
NameOfConstraint SourceCurrentDensityZ; }
}
}
}
Formulation {
{ Name Magnetostatics_a_2D; Type FemEquation;
Quantity {
{ Name a ; Type Local; NameOfSpace Hcurl_a_Mag_2D; }
{ Name js; Type Local; NameOfSpace Hregion_j_Mag_2D; }
}
Equation {
Galerkin { [ nu[] * Dof{d a} , {d a} ]; In Domain_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { [ - Dof{js} , {a} ]; In DomainS_Mag;
Jacobian Vol; Integration CurlCurl; }
}
}
}
Resolution {
{ Name MagSta_a_2D;
System {
{ Name Sys_Mag; NameOfFormulation Magnetostatics_a_2D; }
}
Operation {
Generate[Sys_Mag]; Solve[Sys_Mag]; SaveSolution[Sys_Mag];
}
}
}
PostProcessing {
{ Name MagSta_a_2D; NameOfFormulation Magnetostatics_a_2D;
Quantity {
{ Name a;
Value {
Local { [ {a} ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name az;
Value {
Local { [ CompZ[{a}] ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name b;
Value {
Local { [ {d a} ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name h;
Value {
Local { [ nu[] * {d a} ]; In Domain_Mag; Jacobian Vol; }
}
}
}
}
}
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A magnetodynamic problem is considered. The formulation is a two-dimensional a-v formulation (see file `MagDyn_av_2D.pro', which includes the same jacobian and integration library files as in the previous section). It is applied to a core-inductor system (defined in file `CoreMassive.pro'), of which the geometry has already been defined in file `Core.geo' (giving file `Core.msh' with Gmsh; see section 8.1 Input file format).
The jacobian and integration methods used are defined in the same file as in the electrostatic problem in 6.1 Electrostatic problem.
/* -------------------------------------------------------------------
File "CoreMassive.pro"
This file defines the problem dependent data structures for the
dynamic core-inductor problem.
To compute the solution:
getdp CoreMassive -msh Core.msh -solve MagDyn_av_2D
To compute post-results:
getdp CoreMassive -msh Core.msh -pos Map_a
getdp CoreMassive -msh Core.msh -pos U_av
------------------------------------------------------------------- */
Group {
Air = Region[ 101 ]; Core = Region[ 102 ];
Ind = Region[ 103 ]; AirInf = Region[ 111 ];
SurfaceGh0 = Region[ 1100 ]; SurfaceGe0 = Region[ 1101 ];
SurfaceGInf = Region[ 1102 ];
Val_Rint = 200.e-3;
Val_Rext = 250.e-3;
DomainCC_Mag = Region[ {Air, AirInf} ];
DomainC_Mag = Region[ {Ind, Core} ]; // Massive inductor + conducting core
DomainB_Mag = Region[ {} ];
DomainS_Mag = Region[ {} ];
DomainInf = Region[ {AirInf} ];
Domain_Mag = Region[ {DomainCC_Mag, DomainC_Mag} ];
}
Function {
mu0 = 4.e-7 * Pi;
murCore = 100.;
nu [ #{Air, Ind, AirInf} ] = 1. / mu0;
nu [ Core ] = 1. / (murCore * mu0);
sigma [ Ind ] = 5.9e7;
sigma [ Core ] = 2.5e7;
Freq = 1.;
}
Constraint {
{ Name MagneticVectorPotential_2D;
Case {
{ Region SurfaceGe0 ; Value 0.; }
{ Region SurfaceGInf; Value 0.; }
}
}
{ Name SourceCurrentDensityZ;
Case {
}
}
Val_I_ = 0.01 * 1000.;
{ Name Current_2D;
Case {
{ Region Ind; Value Val_I_; }
}
}
{ Name Voltage_2D;
Case {
{ Region Core; Value 0.; }
}
}
}
Include "Jacobian_Lib.pro"
Include "Integration_Lib.pro"
Include "MagDyn_av_2D.pro"
PostOperation {
{ Name Map_a; NameOfPostProcessing MagDyn_av_2D;
Operation {
Print[ az, OnElementsOf Domain_Mag, File "Core_m_a.pos" ];
Print[ j, OnElementsOf Domain_Mag, File "Core_m_j.pos" ];
}
}
{ Name U_av; NameOfPostProcessing MagDyn_av_2D;
Operation {
Print[ U, OnRegion Ind ];
Print[ I, OnRegion Ind ];
}
}
}
/* -------------------------------------------------------------------
File "MagDyn_av_2D.pro"
Magnetodynamics - Magnetic vector potential and electric scalar
potential a-v formulation (2D)
-------------------------------------------------------------------
I N P U T
---------
GlobalGroup : (Extension '_Mag' is for Magnetic problem)
-----------
Domain_Mag Whole magnetic domain
DomainCC_Mag Nonconducting regions (not used)
DomainC_Mag Conducting regions
DomainS_Mag Inductor regions (Source)
DomainV_Mag All regions in movement (for speed term)
Function :
--------
nu[] Magnetic reluctivity
sigma[] Electric conductivity
Velocity[] Velocity of regions
Constraint :
----------
MagneticVectorPotential_2D
Fixed magnetic vector potential (2D)
(classical boundary condition)
SourceCurrentDensityZ Fixed source current density (in Z direction)
Voltage_2D Fixed voltage
Current_2D Fixed Current
Parameters :
----------
Freq Frequency (Hz)
Parameters for time loop with theta scheme :
Mag_Time0, Mag_TimeMax, Mag_DTime
Initial time, Maximum time, Time step (s)
Mag_Theta Theta (e.g. 1. : Implicit Euler,
0.5 : Cranck Nicholson)
*/
Group {
DefineGroup[ Domain_Mag, DomainCC_Mag, DomainC_Mag,
DomainS_Mag, DomainV_Mag ];
}
Function {
DefineFunction[ nu, sigma ];
DefineFunction[ Velocity ];
DefineVariable[ Freq ];
DefineVariable[ Mag_Time0, Mag_TimeMax, Mag_DTime, Mag_Theta ];
}
FunctionSpace {
// Magnetic vector potential a (b = curl a)
{ Name Hcurl_a_Mag_2D; Type Form1P;
BasisFunction {
// a = a s
// e e
{ Name se; NameOfCoef ae; Function BF_PerpendicularEdge;
Support Domain_Mag; Entity NodesOf[ All ]; }
}
Constraint {
{ NameOfCoef ae; EntityType NodesOf;
NameOfConstraint MagneticVectorPotential_2D; }
}
}
// Gradient of Electric scalar potential (2D)
{ Name Hregion_u_Mag_2D; Type Form1P;
BasisFunction {
{ Name sr; NameOfCoef ur; Function BF_RegionZ;
Support DomainC_Mag; Entity DomainC_Mag; }
}
GlobalQuantity {
{ Name U; Type AliasOf ; NameOfCoef ur; }
{ Name I; Type AssociatedWith; NameOfCoef ur; }
}
Constraint {
{ NameOfCoef U; EntityType Region;
NameOfConstraint Voltage_2D; }
{ NameOfCoef I; EntityType Region;
NameOfConstraint Current_2D; }
}
}
// Source current density js (fully fixed space)
{ Name Hregion_j_Mag_2D; Type Vector;
BasisFunction {
{ Name sr; NameOfCoef jsr; Function BF_RegionZ;
Support DomainS_Mag; Entity DomainS_Mag; }
}
Constraint {
{ NameOfCoef jsr; EntityType Region;
NameOfConstraint SourceCurrentDensityZ; }
}
}
}
Formulation {
{ Name Magnetodynamics_av_2D; Type FemEquation;
Quantity {
{ Name a ; Type Local ; NameOfSpace Hcurl_a_Mag_2D; }
{ Name ur; Type Local ; NameOfSpace Hregion_u_Mag_2D; }
{ Name I ; Type Global; NameOfSpace Hregion_u_Mag_2D [I]; }
{ Name U ; Type Global; NameOfSpace Hregion_u_Mag_2D [U]; }
{ Name js; Type Local ; NameOfSpace Hregion_j_Mag_2D; }
}
Equation {
Galerkin { [ nu[] * Dof{d a} , {d a} ]; In Domain_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { DtDof [ sigma[] * Dof{a} , {a} ]; In DomainC_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { [ sigma[] * Dof{ur} , {a} ]; In DomainC_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { [ - sigma[] * (Velocity[] *^ Dof{d a}) , {a} ];
In DomainV_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { [ - Dof{js} , {a} ]; In DomainS_Mag;
Jacobian Vol;
Integration CurlCurl; }
Galerkin { DtDof [ sigma[] * Dof{a} , {ur} ]; In DomainC_Mag;
Jacobian Vol; Integration CurlCurl; }
Galerkin { [ sigma[] * Dof{ur} , {ur} ]; In DomainC_Mag;
Jacobian Vol; Integration CurlCurl; }
GlobalTerm { [ Dof{I} , {U} ]; In DomainC_Mag; }
}
}
}
Resolution {
{ Name MagDyn_av_2D;
System {
{ Name Sys_Mag; NameOfFormulation Magnetodynamics_av_2D;
Type ComplexValue; Frequency Freq; }
}
Operation {
Generate[Sys_Mag]; Solve[Sys_Mag]; SaveSolution[Sys_Mag];
}
}
{ Name MagDyn_t_av_2D;
System {
{ Name Sys_Mag; NameOfFormulation Magnetodynamics_av_2D; }
}
Operation {
InitSolution[Sys_Mag]; SaveSolution[Sys_Mag];
TimeLoopTheta[Mag_Time0, Mag_TimeMax, Mag_DTime, Mag_Theta] {
Generate[Sys_Mag]; Solve[Sys_Mag]; SaveSolution[Sys_Mag];
}
}
}
}
PostProcessing {
{ Name MagDyn_av_2D; NameOfFormulation Magnetodynamics_av_2D;
Quantity {
{ Name a;
Value {
Local { [ {a} ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name az;
Value {
Local { [ CompZ[{a}] ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name b;
Value {
Local { [ {d a} ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name h;
Value {
Local { [ nu[] * {d a} ]; In Domain_Mag; Jacobian Vol; }
}
}
{ Name j;
Value {
Local { [ - sigma[]*(Dt[{a}]+{ur}) ]; In DomainC_Mag;
Jacobian Vol; }
}
}
{ Name jz;
Value {
Local { [ - sigma[]*CompZ[Dt[{a}]+{ur}] ]; In DomainC_Mag;
Jacobian Vol; }
}
}
{ Name roj2;
Value {
Local { [ sigma[]*SquNorm[Dt[{a}]+{ur}] ]; In DomainC_Mag;
Jacobian Vol; }
}
}
{ Name U; Value { Local { [ {U} ]; In DomainC_Mag; } } }
{ Name I; Value { Local { [ {I} ]; In DomainC_Mag; } } }
}
}
}
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GetDP has no graphical interface(1). It is a command-line driven program that reads a problem definition file once at the beginning of the processing. This problem definition file is a regular ASCII text file (see section 1.1 Numerical tools as objects), hence created with whatever editor you like.
If you just type the program name at your shell prompt (without any argument), you will get a short help on how to run GetDP. All GetDP calls look like
getdp filename options |
where filename is an ASCII file containing the problem definition, i.e. the structures this user's guide has taught you to create. This file can include other files (see section 1.4 Includes), so that only one problem definition file should always be given on the command line. The input files containing the problem definition structure are usually given the `.pro' extension (if so, there is no need to specify the extension on the command line). The name of this file (without the extension) is used as a basis for the creation of intermediate files during the pre-processing and the processing stages.
The options are a combination of the following commands (in any order):
-pre
Performs the pre-processing associated with the resolution resolution-id. In the pre-processing stage, GetDP creates the geometric database (from the mesh file), identifies the degrees of freedom (the unknowns) of the problem and sets up the constraints on these degrees of freedom. The pre-processing creates a file with a `.pre' extension. If resolution-id is omitted, the list of available choices is displayed.
-cal
Performs the processing. This requires that a pre-processing has been
performed previously, or that a -pre option is given on the same
command line. The performed resolution is the one given as an argument to
the -pre option. In the processing stage, GetDP executes all the
commands given in the Operation field of the selected
Resolution object (such as matrix assemblies, system resolutions,
...).
-pos
Performs the operations in the PostOperation(s) selected by the
post-operation-id(s). This requires that a processing has been
performed previously, or that a -cal option is given on the same
command line. If post-operation-id is omitted, the list of available
choices is displayed.
-ipos
Enters an interactive post-processing mode, permetting to manually type
PostOperation-like commands. These commands are based on the
PostProcessing object(s) selected by the post-processing-id(s).
If post-processing-id is omitted, the list of available choices is
displayed.
-msh
Reads the mesh database (in .msh format) from filename
(see section 8. File formats) rather than reading it from the default problem file
name (with the `.msh' extension appended).
-split
Saves processing results in separate files (one for each timestep).
-res
Loads processing results from file(s).
-name
Uses string as the default generic file name for input or output of mesh, pre-processing and processing files.
-restart
Restarts processing of a transient problem interrupted before being complete.
-solve
Same as -pre resolution-id -cal.
-adapt
Reads adaptation constraints from file.
-order
Specifies the maximum interpolation order.
-bin
Selects binary format for output files.
-log
Saves all processing history in a log file (the input file name with an
appended .log extension).
-socket
Communicates through socket string.
-check
Lets you check the problem structure interactively.
-v
-verbose
Sets the verbosity level. A value of 0 means that no information will be displayed during the processing.
-p
-progress
Sets the progress update rate. This controls the refreshment rate of the counter indicating the progress of the current computation (in %).
-info
Displays the version information.
-version
Displays the version number.
-help
Displays a message listing basic usage and available options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter describes the file formats that cannot be modified by the
user. The format of the problem definition structure is explained in
3. Objects, and 4. Types for objects. The format of the
post-processing files is explained in 4.10 Types for PostOperation.
8.1 Input file format 8.2 Output file format
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The native mesh format read by GetDP is the mesh file format produced by Gmsh (http://www.geuz.org/gmsh/). The file is divided into two sections, defining the nodes and the elements in the mesh.
$NOD number-of-nodes node-number x-coord y-coord z-coord ... $ENDNOD $ELM number-of-elements elm-number elm-type elm-region unused number-of-nodes node-numbers ... $ENDELM |
All the syntactic variables stand for integers except x-coord, y-coord and z-coord which stand for floating point values. The elm-type value defines the geometrical type for the element:
elm-type:
1
2
3
4
5
6
7
15
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
8.2.1 File `.pre' 8.2.2 File `.res'
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `.pre' file is generated by the pre-processing stage. It contains all the information about the degrees of freedom to be considered during the processing stage for a given resolution (i.e. unknowns, fixed values, initial values, etc.).
$Resolution /* 'resolution-id' */ main-resolution-number number-of-dofdata $EndResolution $DofData /* #dofdata-number */ resolution-number system-number number-of-function-spaces function-space-number ... number-of-time-functions time-function-number ... number-of-partitions partition-index ... number-of-any-dof number-of-dof dof-basis-function-number dof-entity dof-harmonic dof-type dof-data ... $EndDofData ... |
with
dof-data:
equation-number nnz
(dof-type: 1; unknown) |
dof-value dof-time-function-number
(dof-type: 2; fixed value) |
dof-associate-dof-number dof-value dof-time-function-number
(dof-type: 3; associated degree of freedom) |
equation-number dof-value
(dof-type: 5; initial value for an unknown)
|
Notes:
$DofData field for each system of equations considered in
the resolution (including those considered in pre-resolutions).
$DofData field is determined by the order
of this field in the `.pre' file.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `.res' file is generated by the processing stage. It contains the solution of the problem (or a part of it in case of program interruption).
$ResFormat /* GetDP vgetdp-version-number, string-for-format */ getdp-version-number file-res-format $EndResFormat $Solution /* DofData #dofdata-number */ dofdata-number time-value time-step-number solution-value ... $EndSolution ... |
Notes:
$Solution field contains the solution associated with a
$DofData field.
$Solution field for each time step, of which the time is
time-value (0 for non time dependent analyses).
$Solution field follows
the numbering of the equations given in the `.pre' file
(one floating point value for each degree of freedom).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
9.1 Bugs 9.2 Versions 9.3 Credits
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you think you have found a bug in GetDP, you can report it by electronic mail to the GetDP mailing list at getdp@geuz.org. Please send as precise a description of the problem as you can, including sample input files that produce the bug (problem definition and mesh files). Don't forget to mention both the version of GetDP and the version of your operation system (see section 7. Running GetDP to see how to get this information).
See the `TODO' file in the distribution to check the problems we already know about.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
$Id: VERSIONS,v 1.51 2005/02/05 20:38:19 geuzaine Exp $ New since 1.0: Lanczos with GSL+lapack; various small improvements and bug fixes; 1.0: New license (GNU GPL); added support for latest Gmsh mesh file format; more code cleanups; 0.91: Merged moving band and multi-harmonic code; new loops and conditionals in the parser; removed old readline code (just use GNU readline if available); upgraded to latest Gmsh post-processing format; various small enhancements and bug fixes; 0.89: Code cleanup; 0.88: Integrated FMM code; 0.87: Fixed major performance problem on Windows (matrix assembly and post-processing can be up to 3-4 times faster with 0.87 compared to 0.86, bringing performance much closer to Unix versions); fixed stack overflow on Mac OS X; Re-introduced face basis functions mistakenly removed in 0.86; Fixed post-processing bug with pyramidal basis functions; New build system based on autoconf; 0.86: Updated Gmsh output format; many small bug fixes; 0.85: Upgraded communication interface with Gmsh; New ChangeOfValues option in PostOperation; Many internal changes; 0.84: New ChangeOfCoordinate option in PostOperation; Fixed crash in InterpolationAkima; Improved interactive postprocessing (-ipos); Changed syntax of parametric OnGrid ($S, $T -> $A, $B, $C); Corrected Skin for non simplicial meshes; Fixed floating point exception in diagonal matrix scaling; Many other small fixes and cleanups; 0.83: Fixed bugs in SaveSolutions[] and InitSolution[]; Fixed corrupted binary post-processing files in the harmonic case for the Gmsh format; Output files are now created relatively to the input file directory; Made solver options available on the command line; Added optional matrix scaling and changed default parameter file name to 'solver.par' (Warning: please check the scaling definition in your old SOLVER.PAR files); Generalized syntax for lists (start:[incr]end -> start:end:incr); Updated reference guide; Added a new short presentation on the web site; OnCut -> OnSection; New functional syntax for resolution operations (e.g. Generate X -> Generate[X]); Many other small fixes and cleanups; 0.82: Added communication socket for interactive use with Gmsh; corrected (again) memory problem (leak + seg. fault) in time stepping schemes; corrected bug in Update[]; 0.81: Generalization of transformation jacobians (spherical and rectangular, with optional parameters); changed handling of missing command line arguments; enhanced Print OnCut; fixed memory leak for time domain analysis of coupled problems; -name option; Fixed seg. fault in ILUK; 0.80: Fixed computation of time derivatives on first time step (in post-processing); Added tolerance in transformation jacobians; Fixed parsing of DOS files (carriage return problems); Automatic memory reallocation in ILUD|K; 0.79: Various bug fixes (mainly for the post-processing of intergal quantities); Automatic treatment of degenerated cases in axisymmetrical problems; 0.78: Various bug fixes; 0.77: Changed syntax for PostOperations (Plot suppressed in favour of Print; Plot OnRegion becomes Print OnElementsOf); Changed table oriented post-processing formats; New binary formats; New error diagnostics; 0.76: Reorganized high order shape functions; Optimization of the post-processing (faster and less bloated); Lots of internal cleanups; 0.74: High order shape functions; lots of small bug fixes; 0.73: Eigen value problems (Lanczos); minor corrections; 0.7: constraint syntax; fourier transform; unary minus correction; complex integral quantity correction; separate iteration matrix generation; 0.6: Second order time derivatives; Newton nonlinear scheme; Newmark time stepping scheme; global quantity syntax; interactive post-processing; tensors; integral quantities; post-processing facilities; 0.3: First distributed version;
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
$Id: CREDITS,v 1.12 2004/09/30 04:58:18 geuzaine Exp $
GetDP is copyright (C) 1997-2004
Patrick Dular
<patrick.dular at ulg.ac.be>
and
Christophe Geuzaine
<geuzaine at acm.caltech.edu>
Major code contributions to GetDP have been provided by Johan
Gyselinck <johan.gyselinck at ulg.ac.be> and Ruth Sabariego
<ruth.sabariego at student.ulg.ac.be>.
Other code contributors include: David Colignon <david.colignon at
ulg.ac.be>, Tuan Ledinh <tuan.ledinh at student.ulg.ac.be>, Patrick
Lefevre <P.Lefevre at ulg.ac.be>, Andre Nicolet <andre.nicolet at
fresnel.fr>, <ohyeahq at yahoo.co.jp>, Jean-Francois Remacle <remacle
at scorec.rpi.edu>, Timo Tarhasaari <timo.tarhasaari at tut.fi>,
Christophe Trophime <trophime at labs.polycnrs-gre.fr> and Marc Ume
<Marc.Ume at digitalgraphics.be>. See the source code for more
details.
The AVL tree code (DataStr/avl.*) is copyright (C) 1988-1993, 1995 The
Regents of the University of California. Permission to use, copy,
modify, and distribute this software and its documentation for any
purpose and without fee is hereby granted, provided that the above
copyright notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting documentation,
and that the name of the University of California not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission. The University of
California makes no representations about the suitability of this
software for any purpose. It is provided "as is" without express or
implied warranty.
This version of GetDP may also contain code (in the Sparskit
subdirectory) copyright (C) 1990 Yousef Saad: check the configuration
options.
Thanks to the following folks who have contributed by providing fresh
ideas on theoretical or programming topics, who have sent patches,
requests for changes or improvements, or who gave us access to exotic
machines for testing GetDP: Olivier Adam <o.adam at ulg.ac.be>,
Alejandro Angulo <aacusm at yahoo.com>, Geoffrey Deliege <deliege at
mailserv.esat.kuleuven.ac.be>, Mark Evans <evans at gte.net>, Philippe
Geuzaine <geuzaine at gnat.colorado.edu>, Eric Godard <godard at
montefiore.ulg.ac.be>, Sebastien Guenneau <guenneau at
liverpool.ac.uk>, Francois Henrotte <fhenrott at esat.kuleuven.ac.be>,
Daniel Kedzierski <kedzierski at uol.com.br>, Samuel Kvasnica
<kvasnica at iaee.tuwien.ac.at>, Benoit Meys <bmeys at
techspace-aero.be>, Uwe Pahner <uwe.pahner at esat.kuleuven.ac.be>,
Georgia Psoni and Robert Struijs <gpsoni at free.fr>, Ahmed Rassili
<a.rassili at ulg.ac.be>, Thierry Scordilis <t.scordilis at atral.fr>
and Herve Tortel <tortel at loe.u-3mrs.fr>, Jose Geraldo A. Brito Neto
<jgabrito at terra.com.br>, Matthias Fenner <m.fenner at gmx.net>.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
.emacs file: (setq auto-mode-alist (append '(("\\.pro$"
. c++-mode)) auto-mode-alist)).
All as soon as possible in the definition of topological
entities used as Entity of BasisFunctions.
This will prevent GetDP from constructing unnecessary lists of entities.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
$Id: FAQ,v 1.9 2004/03/08 05:38:37 geuzaine Exp $ This is the GetDP FAQ ******************************************************************** Section 1: The basics * 1.1 What is GetDP? GetDP is a scientific software environment for the numerical solution of integro-differential equations, 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 various dimensions (1D, 2D, 2D axisymmetric or 3D) and time states (static, transient or harmonic). The main feature of GetDP is the closeness between the organization of data defining discrete problems (written by the user in ASCII data files) and the symbolic mathematical expressions of these problems. * 1.2 What are the terms and conditions of use? GetDP is distributed under the terms of the GNU General Public License. See the file doc/LICENSE for more information, or go to the GNU foundation's web site at http://www.gnu.org. * 1.3 What does 'GetDP' mean? General environment for the treatment of Discrete Problems * 1.4 Where can I find more information? <http://www.geuz.org/getdp/> is the primary site to obtain information about GetDP. You will find a short presentation, a complete reference guide as well as a searchable archive of the GetDP mailing list (<getdp@geuz.org>) on this site. ******************************************************************** Section 2: Installation * 2.1 Which OSes does GetDP run on? GetDP is known to run on Windows 95/98/NT/2000/XP, Linux, Mac OS X, Compaq Tru64 Unix (aka OSF1, aka Digital Unix), Sun OS, IBM AIX, SGI IRIX, FreeBSD and HP-UX. It should compile on any Unix-like operating system, provided that you have access to a recent C and Fortran 77 compiler. * 2.2 What do I need to compile GetDP from the sources? You need a C and a Fortran 77 compiler (e.g. the GNU compilers gcc and g77) as well as the GSL (version 1.2 or higher; freely available from http://sources.redhat.com/gsl/). Under Windows, you will need the Cygwin tools and compilers (freely available from http://www.cygwin.com). * 2.3 How to I compile GetDP? Just type ./configure; make; make install If you change some configuration options (type ./configure --help to get the list of all available choices), don't forget to do 'make clean' before rebuilding GetDP. * 2.4 GetDP [from a binary distribution] complains about missing libraries. Try 'ldd getdp' (or 'otool -L getdp' on Mac OS X) to check if all the required shared libraries are installed on your system. If not, install them. If it still doesn't work, recompile GetDP from the sources. ******************************************************************** Section 3: Usage * 3.1 How can I provide a mesh to GetDP? The only meshing format accepted by this version of GetDP is the 'msh' format created by Gmsh (<http://www.geuz.org/gmsh>). This format being very simple (see the reference GetDP manual for more details), it should be straightforward to write a converter from your mesh format to the 'msh' format. * 3.2 How can I visualize the results produced by GetDP? You can specify a format in all post-processing operations. Available formats include 'Table', 'TimeTable' and 'Gmsh'. 'Table' and 'TimeTable' output lists of numbers easily readable by Excel/gnuplot/Caleida Graph/etc. 'Gmsh' outputs post-processing views directly loadable by Gmsh. * 3.3 How do I change the linear solver used by GetDP? Edit the 'solver.par' file in the current working directory. You can also remove the file: GetDP will give you the opportunity to create it dynamically next time you perform a linear system solving. If you don't like the default linear solvers (based on Yousef Saad's Sparskit 2.0), you can configure and compile GetDP to use PETSc (http://www.mcs.anl.gov/petsc) instead: run ./configure --help for more info.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Gmsh is a three-dimensional finite element mesh generator with simple CAD and post-processing capabilities that can be used as a graphical front-end for GetDP. Gmsh can be downloaded from http://www.geuz.org/gmsh/.
This appendix reproduces verbatim the input files needed by Gmsh to produce the mesh files `mStrip.msh' and `Core.msh' used in the examples of 6. Complete examples.
/* -------------------------------------------------------------------
File "mStrip.geo"
This file is the geometrical description used by GMSH to produce
the file "mStrip.msh".
------------------------------------------------------------------- */
/* Definition of some parameters for geometrical dimensions, i.e.
h (height of 'Diel1'), w (width of 'Line'), t (thickness of 'Line')
xBox (width of the air box) and yBox (height of the air box) */
h = 1.e-3 ; w = 4.72e-3 ; t = 0.035e-3 ;
xBox = w/2. * 6. ; yBox = h * 12. ;
/* Definition of parameters for local mesh dimensions */
s = 1. ;
p0 = h / 10. * s ;
pLine0 = w/2. / 10. * s ; pLine1 = w/2. / 50. * s ;
pxBox = xBox / 10. * s ; pyBox = yBox / 8. * s ;
/* Definition of gemetrical points */
Point(1) = { 0 , 0, 0, p0} ;
Point(2) = { xBox, 0, 0, pxBox} ;
Point(3) = { xBox, h, 0, pxBox} ;
Point(4) = { 0 , h, 0, pLine0} ;
Point(5) = { w/2., h, 0, pLine1} ;
Point(6) = { 0 , h+t, 0, pLine0} ;
Point(7) = { w/2., h+t, 0, pLine1} ;
Point(8) = { 0 , yBox, 0, pyBox} ;
Point(9) = { xBox, yBox, 0, pyBox} ;
/* Definition of gemetrical lines */
Line(1) = {1,2}; Line(2) = {2,3}; Line(3) = {3,9};
Line(4) = {9,8}; Line(5) = {8,6}; Line(7) = {4,1};
Line(8) = {5,3}; Line(9) = {4,5}; Line(10) = {6,7};
Line(11) = {5,7};
/* Definition of geometrical surfaces */
Line Loop(12) = {8,-2,-1,-7,9}; Plane Surface(13) = {12};
Line Loop(14) = {10,-11,8,3,4,5}; Plane Surface(15) = {14};
/* Definition of Physical entities (surfaces, lines). The Physical
entities tell GMSH the elements and their associated region numbers
to save in the file 'mStrip.msh'. For example, the Region
111 is made of elements of surface 13, while the Region 121 is
made of elements of lines 9, 10 and 11 */
Physical Surface (101) = {15} ; /* Air */
Physical Surface (111) = {13} ; /* Diel1 */
Physical Line (120) = {1} ; /* Ground */
Physical Line (121) = {9,10,11} ; /* Line */
Physical Line (130) = {2,3,4} ; /* SurfInf */
/* -------------------------------------------------------------------
File "Core.geo"
This file is the geometrical description used by GMSH to produce
the file "Core.msh".
------------------------------------------------------------------- */
dxCore = 50.e-3; dyCore = 100.e-3;
xInd = 75.e-3; dxInd = 25.e-3; dyInd = 50.e-3;
rInt = 200.e-3; rExt = 250.e-3;
s = 1.;
p0 = 12.e-3 *s;
pCorex = 4.e-3 *s; pCorey0 = 8.e-3 *s; pCorey = 4.e-3 *s;
pIndx = 5.e-3 *s; pIndy = 5.e-3 *s;
pInt = 12.5e-3*s; pExt = 12.5e-3*s;
Point(1) = {0,0,0,p0};
Point(2) = {dxCore,0,0,pCorex};
Point(3) = {dxCore,dyCore,0,pCorey};
Point(4) = {0,dyCore,0,pCorey0};
Point(5) = {xInd,0,0,pIndx};
Point(6) = {xInd+dxInd,0,0,pIndx};
Point(7) = {xInd+dxInd,dyInd,0,pIndy};
Point(8) = {xInd,dyInd,0,pIndy};
Point(9) = {rInt,0,0,pInt};
Point(10) = {rExt,0,0,pExt};
Point(11) = {0,rInt,0,pInt};
Point(12) = {0,rExt,0,pExt};
Line(1) = {1,2}; Line(2) = {2,5}; Line(3) = {5,6};
Line(4) = {6,9}; Line(5) = {9,10}; Line(6) = {1,4};
Line(7) = {4,11}; Line(8) = {11,12}; Line(9) = {2,3};
Line(10) = {3,4}; Line(11) = {6,7}; Line(12) = {7,8};
Line(13) = {8,5};
Circle(14) = {9,1,11}; Circle(15) = {10,1,12};
Line Loop(16) = {-6,1,9,10}; Plane Surface(17) = {16};
Line Loop(18) = {11,12,13,3}; Plane Surface(19) = {18};
Line Loop(20) = {7,-14,-4,11,12,13,-2,9,10}; Plane Surface(21) = {20};
Line Loop(22) = {8,-15,-5,14}; Plane Surface(23) = {22};
Physical Surface(101) = {21}; /* Air */
Physical Surface(102) = {17}; /* Core */
Physical Surface(103) = {19}; /* Ind */
Physical Surface(111) = {23}; /* AirInf */
Physical Line(1000) = {1,2}; /* Cut */
Physical Line(1001) = {2}; /* CutAir */
Physical Line(202) = {9,10}; /* SkinCore */
Physical Line(203) = {11,12,13}; /* SkinInd */
Physical Line(1100) = {1,2,3,4,5}; /* SurfaceGh0 */
Physical Line(1101) = {6,7,8}; /* SurfaceGe0 */
Physical Line(1102) = {15}; /* SurfaceGInf */
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Copyright © 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. |
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
one line to give the program's name and a brief idea of what it does. Copyright (C) yyyy name of author This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. |
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice |
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | .
A B C D E F G H I J K L M N O P Q R S T U V W |
|---|
| Jump to: | .
A B C D E F G H I J K L M N O P Q R S T U V W |
|---|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | :
<
|
A B C D E F G I J L M O P Q R S T |
|---|
| Jump to: | :
<
|
A B C D E F G I J L M O P Q R S T |
|---|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| Jump to: | !
#
$
%
&
(
*
+
-
/
0
1
2
3
<
=
>
?
^
|
A B C D E F G H I J L N O P Q R S T U V X Y Z |
|---|
| Jump to: | !
#
$
%
&
(
*
+
-
/
0
1
2
3
<
=
>
?
^
|
A B C D E F G H I J L N O P Q R S T U V X Y Z |
|---|
| [Top] | [Contents] | [Index] | [ ? ] |
If you are looking for a graphical
front-end to GetDP, you may consider using Gmsh (available at
http://www.geuz.org/gmsh/). Gmsh permits to construct geometries, generate meshes,
launch computations and visualize results directly from within a
user-friendly graphical interface. The file formats used by Gmsh for mesh
generation and post-processing are the default file formats accepted by
GetDP (see 8.1 Input file format, and 4.10 Types for PostOperation).
| [Top] | [Contents] | [Index] | [ ? ] |
Group: defining topological entities
Function: defining global and piecewise expressions
Constraint: specifying constraints on function spaces and formulations
FunctionSpace: building function spaces
Jacobian: defining jacobian methods
Integration: defining integration methods
Formulation: building equations
Resolution: solving systems of equations
PostProcessing: exploiting computational results
PostOperation: exporting results
Group
Function
Constraint
FunctionSpace
Jacobian
Integration
Formulation
Resolution
PostProcessing
PostOperation
Group examples
Function examples
Constraint examples
FunctionSpace examples
Jacobian examples
Integration examples
Formulation examples
Resolution examples
PostProcessing examples
PostOperation examples
| [Top] | [Contents] | [Index] | [ ? ] |
Copying conditions
Introduction
1. Overview
2. Expressions
3. Objects
4. Types for objects
5. Short examples
6. Complete examples
7. Running GetDP
8. File formats
9. Bugs, versions and credits
A. Tips and tricks
B. Frequently asked questions
C. Gmsh examples
D. License
Concept index
Metasyntactic variable index
Syntax index
| [Top] | [Contents] | [Index] | [ ? ] |
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | previous or up-and-previous section | 1.1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next or up-and-next section | 1.3 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | concept index | |
| [ ? ] | About | this page |