This is the 'GetDP Reference Manual' for GetDP 3.5.0 (development
version) (November 24, 2023). Copyright (C) 19972022 P. Dular and C.
Geuzaine, University of Liege.
GetDP
Obtaining GetDP
Copying conditions
1 Overview
2 How to read this manual
3 Running GetDP
4 Expressions
5 Objects
6 Types for objects
7 Short examples
8 Complete examples
Appendix A File formats
Appendix B Gmsh examples
Appendix C Compiling the source code
Appendix D Frequently asked questions
Appendix E Tips and tricks
Appendix F Version history
Appendix G Copyright and credits
Appendix H License
Concept index
Metasyntactic variable index
Syntax index
GetDP
Obtaining GetDP
Copying conditions
1 Overview
1.1 Numerical tools as objects
1.2 Which problems can GetDP actually solve?
1.3 Bug reports
2 How to read this manual
2.1 Syntactic rules used in this document
3 Running GetDP
4 Expressions
4.1 Comments
4.2 Includes
4.3 Expressions definition
4.4 Constants
4.5 Operators
4.5.1 Operator types
4.5.2 Evaluation order
4.6 Functions
4.7 Current values
4.8 Arguments
4.9 Runtime variables and registers
4.10 Fields
4.11 Macros, loops and conditionals
5 Objects
5.1 'Group': defining topological entities
5.2 'Function': defining global and piecewise expressions
5.3 'Constraint': specifying constraints on function spaces and formulations
5.4 'FunctionSpace': building function spaces
5.5 'Jacobian': defining jacobian methods
5.6 'Integration': defining integration methods
5.7 'Formulation': building equations
5.8 'Resolution': solving systems of equations
5.9 'PostProcessing': exploiting computational results
5.10 'PostOperation': exporting results
6 Types for objects
6.1 Types for 'Group'
6.2 Types for 'Function'
6.2.1 Math functions
6.2.2 Extended math functions
6.2.3 Green functions
6.2.4 Type manipulation functions
6.2.5 Coordinate functions
6.2.6 Miscellaneous functions
6.3 Types for 'Constraint'
6.4 Types for 'FunctionSpace'
6.5 Types for 'Jacobian'
6.6 Types for 'Integration'
6.7 Types for 'Formulation'
6.8 Types for 'Resolution'
6.9 Types for 'PostProcessing'
6.10 Types for 'PostOperation'
7 Short examples
7.1 Constant expression examples
7.2 'Group' examples
7.3 'Function' examples
7.4 'Constraint' examples
7.5 'FunctionSpace' examples
7.5.1 Nodal finite element spaces
7.5.2 High order nodal finite element space
7.5.3 Nodal finite element space with floating potentials
7.5.4 Edge finite element space
7.5.5 Edge finite element space with gauge condition
7.5.6 Coupled edge and nodal finite element spaces
7.5.7 Coupled edge and nodal finite element spaces for multiply connected domains
7.6 'Jacobian' examples
7.7 'Integration' examples
7.8 'Formulation' examples
7.8.1 Electrostatic scalar potential formulation
7.8.2 Electrostatic scalar potential formulation with floating potentials and electric charges
7.8.3 Magnetostatic 3D vector potential formulation
7.8.4 Magnetodynamic 3D or 2D magnetic field and magnetic scalar potential formulation
7.8.5 Nonlinearities, Mixed formulations, ...
7.9 'Resolution' examples
7.9.1 Static resolution (electrostatic problem)
7.9.2 Frequency domain resolution (magnetodynamic problem)
7.9.3 Time domain resolution (magnetodynamic problem)
7.9.4 Nonlinear time domain resolution (magnetodynamic problem)
7.9.5 Coupled formulations
7.10 'PostProcessing' examples
7.11 'PostOperation' examples
8 Complete examples
8.1 Electrostatic problem
8.2 Magnetostatic problem
8.3 Magnetodynamic problem
Appendix A File formats
A.1 Input file format
A.2 Output file format
A.2.1 File '.pre'
A.2.2 File '.res'
Appendix B Gmsh examples
Appendix C Compiling the source code
Appendix D Frequently asked questions
D.1 The basics
D.2 Installation
D.3 Usage
Appendix E Tips and tricks
Appendix F Version history
Appendix G Copyright and credits
Appendix H License
Concept index
Metasyntactic variable index
Syntax index
GetDP
*****
Patrick Dular and Christophe Geuzaine
GetDP is a general finite element solver that uses mixed finite elements
to discretize de Rhamtype complexes in one, two and three dimensions.
This is the 'GetDP Reference Manual' for GetDP 3.5.0 (development
version) (November 24, 2023).
Obtaining GetDP
***************
The source code and various precompiled versions of GetDP (for Windows,
Linux and MacOS) can be downloaded from .
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
.
Copying conditions
******************
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 (*note License::).
Further information about this license is available from the GNU Project
webpage . Detailed copyright
information can be found in *note Copyright and credits::.
If you want to integrate parts of GetDP into a closedsource software,
or want to sell a modified closedsource version of GetDP, you will need
to obtain a different license. Please contact us directly
(http://geuz.org) for more information.
1 Overview
**********
GetDP (a "General environment for the treatment of Discrete Problems")
is a scientific software environment for the numerical solution of
integrodifferential 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.
1.1 Numerical tools as objects
==============================
An assembly of computational tools (or objects) in GetDP leads to a
problem definition structure, which is a transcription of the
mathematical expression of the problem, and forms a text data file: the
equations describing a phenomenon, written in a mathematical form
adapted to a chosen numerical method, directly constitute data for
GetDP.
The resolution of a discrete problem with GetDP requires the definition,
in a text data file, of the GetDP objects listed (together with their
dependencies) in the following figure and table.

 
  
 > Function  
   \ \ 
     \ 
   \  \ 
  \/   \ \/
    \ 
 Group > Constraint    \ PostOperation 
     \ 
        \ /\
***********************************************************************************************
*     \/ \/\/ \/ _\  *
*         *
*    =====>FunctionSpace ==> Formulation ==> Resolution ==>PostProcessing *
*        *
*    /\/\/\  /\/\/\/\ *
*           *
*         *
*        *
*     Integration    *
*       *
*      *
*      *
*  > Jacobian   *
*    *
*   *
*  *
* *
***********************************************************************************************
Group 
Function Group
Constraint Group, Function, (Resolution)
FunctionSpace Group, Constraint, (Formulation), (Resolution)
Jacobian Group
Integration 
Formulation Group, Function, (Constraint), FunctionSpace,
Jacobian, Integration
Resolution Function, Formulation
PostProcessing Group, Function, Jacobian, Integration,
Formulation, Resolution
PostOperation Group, PostProcessing
The gathering of all these objects constitutes the problem definition
structure, which is a copy of the formal mathematical formulation of the
problem. Reading the first column of the table from top to bottom
pictures the working philosophy and the linking of operations peculiar
to GetDP, from group definition to results visualization. The
decomposition highlighted in the figure points out the separation
between the objects defining the method of resolution, which may be
isolated in a "black box" (bottom) and those defining the data peculiar
to a given problem (top).
The computational tools which are in the center of a problem definition
structure are formulations ('Formulation') and function spaces
('FunctionSpace'). Formulations define systems of equations that have
to be built and solved, while function spaces contain all the
quantities, i.e., functions, fields of vectors or covectors, known or
not, involved in formulations.
Each object of a problem definition structure must be defined before
being referred to by others. A linking which always respects this
property is the following: it first contains the objects defining
particular data of a problem, such as geometry, physical characteristics
and boundary conditions (i.e., 'Group', 'Function' and 'Constraint')
followed by those defining a resolution method, such as unknowns,
equations and related objects (i.e., 'Jacobian', 'Integration',
'FunctionSpace', 'Formulation', 'Resolution' and 'PostProcessing'). The
processing cycle ends with the presentation of the results (i.e., lists
of numbers in various formats), defined in 'PostOperation' fields. This
decomposition points out the possibility of building black boxes,
containing objects of the second group, adapted to treatment of general
classes of problems that share the same resolution methods.
1.2 Which problems can GetDP actually solve?
============================================
The preceding explanations may seem very (too) general. Which are the
problems that GetDP can actually solve? To answer this question, here
is a list of methods that we have considered and coupled until now:
Numerical methods
finite element method
boundary element method (experimental, undocumented)
volume integral methods (experimental, undocumented)
Geometrical models
onedimensional models (1D)
twodimensional models (2D), plane and axisymmetric
threedimensional models (3D)
Time states
static states
sinusoidal and harmonic states
transient states
eigenvalue problems
These methods have been successfully applied to build coupled physical
models involving electromagnetic phenomena (magnetostatics,
magnetodynamics, electrostatics, electrokinetics, electrodynamics, wave
propagation, lumped electric circuits), acoustic phenomena, thermal
phenomena and mechanical phenomena (elasticity, rigid body movement).
As can be guessed from the preceding list, GetDP has been initially
developed in the field of computational electromagnetics, which fully
uses all the offered coupling features. We believe that this does not
interfere with the expected generality of the software because a
particular modeling forms a problem definition structure which is
totally external to the software: GetDP offers computational tools; the
user freely applies them to define and solve his problem.
Nevertheless, specific numerical tools will _always_ need to be
implemented to solve specific problems in areas other than those
mentionned above. If you think the general phisosophy of GetDP is right
for you and your problem, but you discover that GetDP lacks the tools
necessary to handle it, let us know: we would love to discuss it with
you. For example, at the time of this writing, many areas of GetDP
would need to be improved to make GetDP as useful for computational
mechanics or computational fluid dynamics as it is for computational
electromagnetics... So if you have the skills and some free time, feel
free to join the project: we gladly accept all code contributions!
1.3 Bug reports
===============
Please file issues on .
Provide as precise a description of the problem as you can, including
sample input files that produce the bug. Don't forget to mention both
the version of GetDP and the version of your operation system (*note
Running GetDP:: to see how to get this information).
See *note Frequently asked questions::, and the bug tracking system
(https://gitlab.onelab.info/getdp/getdp/issues) to see which problems we
already know about.
2 How to read this manual
*************************
After reading *note Overview::, which depicts the general philosophy of
GetDP, you might want to skip *note Expressions::, *note Objects:: and
*note Types for objects:: and directly run the demo files bundled in the
distribution on your computer (*note Running GetDP::). You should then
open these examples with a text editor and compare their structure with
the examples given in *note Short examples:: and *note Complete
examples::. For each new syntax element that you fall onto, you can
then go back to *note Expressions::, *note Objects::, and *note Types
for objects::, and find in these chapters the detailed description of
the syntactic rules as well as all the available options.
Indexes for many concepts (*note Concept index::) and for all the syntax
elements (*note Syntax index::) are available at the end of this manual.
2.1 Syntactic rules used in this document
=========================================
Here are the rules we tried to follow when writing this user's guide.
Note that metasyntactic variable definitions stay valid throughout all
the manual (and not only in the sections where the definitions appear).
See *note Metasyntactic variable index::, for an index of all
metasyntactic variables.
1. Keywords and literal symbols are printed like 'this'.
2. Metasyntactic variables (i.e., text bits that are not part of the
syntax, but stand for other text bits) are printed like THIS.
3. A colon (':') after a metasyntactic variable separates the variable
from its definition.
4. Optional rules are enclosed in '<' '>' pairs.
5. Multiple choices are separated by ''.
6. Three dots (...) indicate a possible repetition of the preceding
rule.
7. For conciseness, the notation 'RULE <, RULE > ...' is replaced by
'RULE <,...>'.
8. The ETC symbol replaces nonlisted rules.
3 Running GetDP
***************
GetDP has no graphical interface(1) (*note Running GetDPFootnote1::).
It is a commandline 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 (*note Numerical tools as objects::), hence
created with whatever text 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 the 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 (*note 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 preprocessing and the processing stages.
The OPTIONS are a combination of the following commands (in any order):
'pre'
RESOLUTIONID
Performs the preprocessing associated with the resolution
RESOLUTIONID. In the preprocessing 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 preprocessing creates a file
with a '.pre' extension. If RESOLUTIONID is omitted, the list of
available choices is displayed.
'cal'
Performs the processing. This requires that a preprocessing 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'
POSTOPERATIONID ...
Performs the operations in the 'PostOperation'(s) selected by the
POSTOPERATIONID(s). This requires that a processing has been
performed previously, or that a 'cal' option is given on the same
command line. If POSTOPERATIONID is omitted, the list of
available choices is displayed.
'msh'
FILENAME
Reads the mesh (in '.msh' format) from FILENAME (*note File
formats::) rather than from the default problem file name (with the
'.msh' extension appended).
'msh_scaling'
VALUE
Multiplies the coordinates of all the nodes in the mesh by VALUE.
'gmshread'
FILENAME ...
Read gmsh data files (same as GmshRead in 'Resolution' operations).
Allows to use such datasets outside resolutions (e.g. in
preprocessing).
'split'
Saves processing results in separate files (one for each timestep).
'res'
FILENAME ...
Loads processing results from file(s).
'name'
STRING
Uses STRING as the default generic file name for input or output of
mesh, preprocessing and processing files.
'restart'
Restarts processing of a time stepping resolution interrupted
before being complete.
'solve'
RESOLUTIONID
Same as 'pre RESOLUTIONID cal'.
'solver'
FILENAME
Specifies a solver option file (whose format varies depending on
the linear algebra toolkit used).
'slepc'
Uses SLEPc instead of Arpack as eigensolver.
'adapt'
FILE
Reads adaptation constraints from file.
'order'
REAL
Specifies the maximum interpolation order.
'cache'
Caches network computations to disk.
'bin'
Selects binary format for output files.
'v2'
Creates meshbased Gmsh output files when possible.
'check'
Lets you check the problem structure interactively.
'v'
'verbose'
INTEGER
Sets the verbosity level. A value of 0 means that no information
will be displayed during the processing.
'cpu'
Reports CPU times for all operations.
'p'
'progress'
INTEGER
Sets the progress update rate. This controls the refreshment rate
of the counter indicating the progress of the current computation
(in %).
'onelab'
NAME
Communicates with OneLab (file or server address)
'setnumber'
NAME VALUE
Sets constant number NAME to VALUE
'setstring'
NAME VALUE
Sets constant string NAME to VALUE
'info'
Displays the version information.
'version'
Displays the version number.
'help'
Displays a message listing basic usage and available options.
(1) If you are looking for a graphical frontend to GetDP, you may
consider using Gmsh (available at ). Gmsh permits to
construct geometries, generate meshes, launch computations and visualize
results directly from within a userfriendly graphical interface. The
file formats used by Gmsh for mesh generation and postprocessing are
the default file formats accepted by GetDP (see *note Input file
format::, and *note Types for PostOperation::).
4 Expressions
*************
This chapter and the next two describe in a rather formal way all the
commands that can be used in the ASCII text input files. If you are
just beginning to use GetDP, or just want to see what GetDP is all
about, you should skip this chapter and the next two for now, have a
quick look at *note Running GetDP::, and run the demo problems bundled
in the distribution on your computer. You should then open the '.pro'
files in a text editor and compare their structure with the examples
given in *note Short examples:: and *note Complete examples::. Once you
have a general idea of how the files are organized, you might want to
come back here to learn more about the specific syntax of all the
objects, and all the available options.
4.1 Comments
============
Both C and C++ style comments are supported and can be used in the input
data files to comment selected text regions:
1. the text region comprised between '/*' and '*/' pairs is ignored;
2. the rest of a line after a double slash '//' is ignored.
Comments cannot be used inside double quotes or inside GetDP keywords.
4.2 Includes
============
An input data file can be included in another input data file by placing
one of the following commands (EXPRESSIONCHAR represents a file name)
on a separate line, outside the GetDP objects. Any text placed after an
include command on the same line is ignored.
Include EXPRESSIONCHAR
#include EXPRESSIONCHAR
See *note Constants::, for the definition of the character expression
EXPRESSIONCHAR.
4.3 Expressions definition
==========================
Expressions are the basic tool of GetDP. They cover a wide range of
functional expressions, from constants to formal expressions containing
functions (builtin or userdefined, 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 *note Syntactic
rules::):
EXPRESSION:
( EXPRESSION ) 
INTEGER 
REAL 
CONSTANTID 
QUANTITY 
ARGUMENT 
CURRENTVALUE 
VARIABLESET 
VARIABLEGET 
REGISTERSET 
REGISTERGET 
OPERATORUNARY EXPRESSION 
EXPRESSION OPERATORBINARY EXPRESSION 
EXPRESSION OPERATORTERNARYLEFT EXPRESSION OPERATORTERNARYRIGHT EXPRESSION 
BUILTINFUNCTIONID [ < EXPRESSIONLIST > ] < { EXPRESSIONCSTLIST } > 
FUNCTIONID [ < EXPRESSIONLIST > ] 
< Real  Complex > [ EXPRESSION ] 
Dt [ EXPRESSION ] 
AtAnteriorTimeStep [ EXPRESSION, INTEGER ] 
Order [ QUANTITY ] 
Trace [ EXPRESSION, GROUPID ] 
EXPRESSION ##INTEGER
The following sections introduce the quantities that can appear in
expressions, i.e., constant terminals (INTEGER, REAL) and constant
expression identifiers (CONSTANTID, EXPRESSIONCSTLIST), discretized
fields (QUANTITY), arguments (ARGUMENT), current values (CURRENTVALUE),
register values (REGISTERSET, REGISTERGET), operators (OPERATORUNARY,
OPERATORBINARY, OPERATORTERNARYLEFT, OPERATORTERNARYRIGHT) and
builtin or userdefined functions (BUILTINFUNCTIONID, FUNCTIONID).
The last seven cases in this definition permit to cast an expression as
real or complex, get the time derivative or evaluate an expression at an
anterior time step, retrieve the interpolation order of a discretized
quantity, evaluate the trace of an expression, and print the value of an
expression for debugging purposes.
List of expressions are defined as:
EXPRESSIONLIST:
EXPRESSION <,...>
4.4 Constants
=============
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
EXPRESSIONCST, are also used:
EXPRESSIONCST:
( EXPRESSIONCST ) 
INTEGER 
REAL 
CONSTANTID 
OPERATORUNARY EXPRESSIONCST 
EXPRESSIONCST OPERATORBINARY EXPRESSIONCST 
EXPRESSIONCST OPERATORTERNARYLEFT EXPRESSIONCST OPERATORTERNARYRIGHT
EXPRESSIONCST 
MATHFUNCTIONID [ < EXPRESSIONCSTLIST > ] 
#CONSTANTID() 
CONSTANTID(EXPRESSIONCST) 
StrFind[ EXPRESSIONCHAR, EXPRESSIONCHAR ] 
StrCmp[ EXPRESSIONCHAR, EXPRESSIONCHAR ] 
StrLen[ EXPRESSIONCHAR ] 
StringToName[ EXPRESSIONCHAR ]  S2N[ EXPRESSIONCHAR ] 
Exists[ STRING ]  FileExists[ STRING ]  GroupExists[ STRING ] 
GetForced[ STRING ]  NbrRegions [ STRING ] 
GetNumber[ EXPRESSIONCHAR <, EXPRESSIONCST> ]
'StrFind' searches the first EXPRESSIONCHAR for any occurrence of the
second EXPRESSIONCHAR. 'StrCmp' compares the two strings (returns an
integer greater than, equal to, or less than 0, according as the first
string is greater than, equal to, or less than the second string).
'StrLen' returns the length of the string. 'StringToName' creates a
name from the provided string. 'Exists' checks for the existence of a
constant or a function. 'FileExists' checks for the existence of a
file. 'GroupExists' checks for the existence of a group. 'GetForced'
gets the value of a constant (zero if does not exist). 'NbrRegions'
counts the numbers of elementary regions in a group. 'GetNumber' allows
to get the value of a ONELAB number variable (the optional second
argument specifies the default value returned if the variable does not
exist).
List of constant expressions are defined as:
EXPRESSIONCSTLIST:
EXPRESSIONCSTLISTITEM <,...>
with
EXPRESSIONCSTLISTITEM:
EXPRESSIONCST 
EXPRESSIONCST : EXPRESSIONCST 
EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST 
CONSTANTID () 
CONSTANTID ( { EXPRESSIONCSTLIST } ) 
List[ CONSTANTID ] 
List[ EXPRESSIONCSTLISTITEM ] 
List[ { EXPRESSIONCSTLIST } ] 
ListAlt[ CONSTANTID, CONSTANTID ] 
ListAlt[ EXPRESSIONCSTLISTITEM, EXPRESSIONCSTLISTITEM ] 
LinSpace[ EXPRESSIONCST, EXPRESSIONCST, EXPRESSIONCST ] 
LogSpace[ EXPRESSIONCST, EXPRESSIONCST, EXPRESSIONCST ] 
 EXPRESSIONCSTLISTITEM 
EXPRESSIONCST * EXPRESSIONCSTLISTITEM 
EXPRESSIONCSTLISTITEM * EXPRESSIONCST 
EXPRESSIONCST / EXPRESSIONCSTLISTITEM 
EXPRESSIONCSTLISTITEM / EXPRESSIONCST 
EXPRESSIONCSTLISTITEM ^ EXPRESSIONCST 
EXPRESSIONCSTLISTITEM + EXPRESSIONCSTLISTITEM 
EXPRESSIONCSTLISTITEM  EXPRESSIONCSTLISTITEM 
EXPRESSIONCSTLISTITEM * EXPRESSIONCSTLISTITEM 
EXPRESSIONCSTLISTITEM / EXPRESSIONCSTLISTITEM 
ListFromFile [ EXPRESSIONCHAR ] 
ListFromServer [ EXPRESSIONCHAR ] 
ReadTable [ EXPRESSIONCHAR, EXPRESSIONCHAR ]
The second case in this last definition permits to create a list
containing the range of numbers comprised between the two
EXPRESSIONCST, with a unit incrementation step. The third case also
permits to create a list containing the range of numbers comprised
between the two EXPRESSIONCST, but with a positive or negative
incrementation step equal to the third EXPRESSIONCST. The fourth and
fifth cases permit to reference constant identifiers (CONSTANTIDs) 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 seventh case permits to create
alternate lists: the arguments of 'ListAlt' must be CONSTANTIDs 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 (*note
Functions::). The next two cases permit to create linear and
logarithmic lists of numbers, respectively. The remaining cases permit
to apply arithmetic operators itemwise in lists. 'ListFromFile' reads
a list of numbers from a file. 'ListFromServer' attemps to get a list
of numbers from the ONELAB variable EXPRESSIONCHAR. 'ReadTable' reads
tabular data in the same format as 'ListFromFile', and in addition
stores in the runtime table named after the second EXPRESSIONCHAR.
Contrary to a general EXPRESSION which is evaluated at runtime (thanks
to an internal stack mechanism), an EXPRESSIONCST 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 [ CONSTANTID < = EXPRESSIONCST > <,...> ]; 
DefineConstant [ CONSTANTID = { EXPRESSIONCST , ONELABOPTIONS } <,...> ]; 
DefineConstant [ STRINGID < = STRINGDEF > <,...> ]; 
DefineConstant [ STRINGID = { STRINGDEF , ONELABOPTIONS } <,...> ]; 
CONSTANTID <()> = CONSTANTDEF; 
CONSTANTID = DefineNumber[ CONSTANTDEF, ONELABOPTIONS ];
STRINGID <()> = STRINGDEF; 
STRINGID = DefineString[ STRINGDEF, ONELABOPTIONS ]; 
Printf [ "STRING" ] < >  >> STRINGDEF >; 
Printf [ "STRING", EXPRESSIONCSTLIST ] < >  >> STRINGDEF >; 
Read [ CONSTANTID ] ; 
Read [ CONSTANTID , EXPRESSIONCST ]; 
UndefineConstant  Delete [ CONSTANTID ] ;
UndefineFunction [ CONSTANTID ] ;
SetNumber[ STRING , EXPRESSIONCST ];
SetString[ STRING , STRINGDEF ];
with
CONSTANTID:
STRING 
STRING ( EXPRESSIONCSTLIST ) 
STRING ~ { EXPRESSIONCST } <,...>
CONSTANTDEF:
EXPRESSIONCSTLISTITEM 
{ EXPRESSIONCSTLIST }
STRINGID:
STRING 
STRING ~ { EXPRESSIONCST } <,...>
STRINGDEF:
"STRING" 
StrCat[ EXPRESSIONCHAR <,...> ] 
Str[ EXPRESSIONCHAR <,...> ]
Notes:
1. Five constants are predefined in GetDP: 'Pi' (3.1415926535897932),
'0D' (0), '1D' (1), '2D' (2) and '3D' (3).
2. When '~{EXPRESSIONCST}' is appended to a string STRING, the result
is a new string formed by the concatenation of STRING, '_' (an
underscore) and the value of the EXPRESSIONCST. This is most
useful in loops (*note Macros loops and conditionals::), where it
permits to define unique strings automatically. For example,
For i In {1:3}
x~{i} = i;
EndFor
is the same as
x_1 = 1;
x_2 = 2;
x_3 = 3;
3. The assignment in 'DefineConstant' (zero if no EXPRESSIONCST is
given) is performed only if CONSTANTID 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).
When ONELABOPTIONS are provided, the parameter is exchanged with
the ONELAB server. See
for more information.
4. 'DefineNumber' and 'DefineString' allow to define a ONELAB
parameter. In this case the affectation always takes place.
'SetNumber' and 'SetString' allow the direct setting of ONELAB
parameters without defining local variables.
See *note Constant expression examples::, as well as *note Function
examples::, for some examples.
Character expressions are defined as follows:
EXPRESSIONCHAR:
"STRING" 
STRINGID 
StrCat[ EXPRESSIONCHAR <,...> ] 
Str[ EXPRESSIONCHAR <,...> ]
StrChoice[ EXPRESSION, EXPRESSIONCHAR, EXPRESSIONCHAR ] 
StrSub[ EXPRESSIONCHAR, EXPRESSION, EXPRESSION ] 
StrSub[ EXPRESSIONCHAR, EXPRESSION ] 
UpperCase [ EXPRESSIONCHAR ] 
Sprintf [ EXPRESSIONCHAR ] 
Sprintf[ EXPRESSIONCHAR, EXPRESSIONCSTLIST ] 
NameToString ( STRING )  N2S ( STRING ) 
GetString[ EXPRESSIONCHAR <, EXPRESSIONCHAR,> ] 
Date  CurrentDirectory  CurrentDir 
AbsolutePath [ EXPRESSIONCHAR ] 
DirName [ EXPRESSIONCHAR ] 
OnelabAction
'StrCat' and 'Str' permit to concatenate character expressions ('Str'
adds a newline character after each string except the last) when
creating a string. 'Str' is also used to create string lists (when
STRINGID is followed by '()'). 'StrChoice' returns the first or second
EXPRESSIONCHAR depending on the value of EXPRESSION. 'StrSub' returns
the portion of the string that starts at the character position given by
the first EXPRESSION and spans the number of characters given by the
second EXPRESSION or until the end of the string (whichever comes first;
or always if the second EXPRESSION is not provided). 'UpperCase'
converts the EXPRESSIONCHAR to upper case. 'Sprintf' is equivalent to
the 'sprintf' C function (where EXPRESSIONCHAR is a format string that
can contain floating point formatting characters: '%e', '%g', etc.).
'NameToString' converts a variable name into a string. 'GetString'
allows to get the value of a ONELAB string variable (the optional second
argument specifies the default value returned if the variable does not
exist.) 'Date' permits to access the current date. 'CurrentDirectory'
and 'CurrentDir' return the directory of the '.pro' file.
'AbsolutePath' returns the absolute path of a file. 'DirName' returns
the directory of a file. 'OnelabAction' returns the current ONELAB
action (e.g. 'check' or 'compute').
List of character expressions are defined as:
EXPRESSIONCHARLIST:
EXPRESSIONCHAR <,...>
4.5 Operators
=============
4.5.1 Operator types

The operators in GetDP are similar to the corresponding operators in the
C or C++ programming languages.
OPERATORUNARY:
''
Unary minus.
'!'
Logical not.
OPERATORBINARY:
'^'
Exponentiation. The evaluation of the both arguments must result
in a scalar value.
'*'
Multiplication or scalar product, depending on the type of the
arguments.
'/\'
Cross product. The evaluation of both arguments must result in
vectors.
'/'
Division.
'%'
Modulo. The evaluation of the second argument must result in a
scalar value.
'+'
Addition.
''
Subtraction.
'=='
Equality.
'!='
Inequality.
'>'
Greater. The evaluation of both arguments must result in scalar
values.
'>='
Greater or equality. The evaluation of both arguments must result
in scalar values.
'<'
Less. The evaluation of both arguments must result in scalar
values.
'<='
Less or equality. The evaluation of both arguments must result in
scalar values.
'&&'
Logical 'and'. The evaluation of both arguments must result in
scalar values.
''
Logical 'or'. The evaluation of both arguments must result in
floating point values. Warning: the logical 'or' always (unlike in
C or C++) implies the evaluation of both arguments. That is, the
second operand of '' is evaluated even if the first one is true.
'&'
Binary 'and'.
''
Binary 'or'.
'>>'
Bitwise rightshift operator. Shifts the bits of the first
argument to the right by the number of bits specified by the second
argument.
'<<'
Bitwise leftshift operator. Shifts the bits of the first argument
to the left by the number of bits specified by the second argument.
OPERATORTERNARYLEFT:
'?'
OPERATORTERNARYRIGHT:
':'
The only ternary operator, formed by OPERATORTERNARYLEFT and
OPERATORTERNARYRIGHT is defined as in the C or C++ programming
languages. The ternary operator first evaluates its first argument
(the EXPRESSIONCST located before the '?'), which must result in a
scalar value. If it is true (nonzero) the second argument
(located between '?' and ':') is evaluated and returned; otherwise
the third argument (located after ':') is evaluated and returned.
4.5.2 Evaluation order

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), !'
' &'
'/\'
'*, /, %'
'+, '
'<, >, <=, >=, <<, >>'
'!=, =='
'&&, '
'?:'
4.6 Functions
=============
Two types of functions coexist in GetDP: userdefined functions
(FUNCTIONID, see *note Function::) and builtin functions
(BUILTINFUNCTIONID, defined in this section).
Both types of functions are always followed by a pair of brackets '[]'
that can possibly contain arguments (*note Arguments::). This makes it
simple to distinguish a FUNCTIONID or a BUILTINFUNCTIONID from a
CONSTANTID. As shown below, builtin functions might also have
parameters, given between braces '{}', and which are completely
evaluated during the analysis of the syntax (since they are of
EXPRESSIONCSTLIST type):
BUILTINFUNCTIONID [ < EXPRESSIONLIST > ] < { EXPRESSIONCSTLIST } >
with
BUILTINFUNCTIONID:
MATHFUNCTIONID 
EXTENDEDMATHFUNCTIONID 
GREENFUNCTIONID 
TYPEFUNCTIONID 
COORDFUNCTIONID 
MISCFUNCTIONID
Notes:
1. All possible values for BUILTINFUNCTIONID are listed in *note
Types for Function::.
2. Classical mathematical functions (*note Math functions::) are the
only functions allowed in a constant definition (see the definition
of EXPRESSIONCST in *note Constants::).
4.7 Current values
==================
Current values return the current floating point value of an internal
GetDP variable:
'$Time'
Value of the current time. This value is set to zero for non time
dependent analyses.
'$DTime'
Value of the current time increment used in a time stepping
algorithm.
'$Theta'
Current theta value in a theta time stepping algorithm.
'$TimeStep'
Number of the current time step in a time stepping algorithm.
'$Breakpoint'
In case of a breakpoint hit in TimeLoopAdaptive it is the number of
the current breakpoint. In the other case when $Time corresponds
not to a breakpoint the value is 1.
'$Iteration, $NLIteration'
Current iteration in a nonlinear loop.
'$Residual, $NLResidual'
Current residual in a nonlinear loop.
'$EigenvalueReal'
Real part of the current eigenvalue.
'$EigenvalueImag'
Imaginary part of the current eigenvalue.
'$X, $XS'
Value of the current (destination or source) Xcoordinate.
'$Y, $YS'
Value of the current (destination or source) Ycoordinate.
'$Z, $ZS'
Value of the current (destination or source) Zcoordinate.
'$A, $B, $C'
Value of the current parametric coordinates used in the parametric
'OnGrid' 'PostOperation' (*note Types for PostOperation::).
'$QuadraturePointIndex'
Index of the current quadrature point.
'$KSPIteration'
Current iteration in a Krylov subspace solver.
'$KSPResidual'
Current residual in a Krylov subspace solver.
'$KSPIterations'
Total number of iterations of Krylov subspace solver.
'$KSPSystemSize'
System size of Krylov subspace solver.
Note:
1. The current X, Y and Z coordinates refer to the 'physical world'
coordinates, i.e., coordinates in which the mesh is expressed.
Current values are "readonly". Userdefined runtime variables, which
share the same syntax but whose value can be changed in an EXPRESSION,
are defined in *note Runtime variables and registers::.
4.8 Arguments
=============
Function arguments can be used in expressions and have the following
syntax (INTEGER indicates the position of the argument in the
EXPRESSIONLIST of the function, starting from 1):
ARGUMENT:
$INTEGER
See *note Function::, and *note Function examples::, for more details.
4.9 Runtime variables and registers
====================================
Constant expressions (EXPRESSIONCSTs) are evaluated only once during
the analysis of the problem definition structure, cf. *note Constants::.
While this is perfectly fine in most situations, sometimes it is
necessary to store and modify variables at runtime. For example, an
iteration in a 'Resolution' could depend on values computed at runtime.
Also, to speedup the evaluation of EXPRESSIONs (which are evaluated at
runtime through GetDP's internal stack mechanism), it can be useful to
save some results in a temporary variable, at runtime, in order to
reuse them later on.
Two mechanisms exit to handle such cases: runtime variables (which
follow the same syntax as *note Current values::), and registers.
Runtime variables have the following syntax:
VARIABLESET:
$VARIABLEID = EXPRESSION
VARIABLEGET:
$VARIABLEID
VARIABLEID:
STRING 
STRING ~ { EXPRESSIONCST } <,...>
Thus, runtime variables can simply be defined anywhere in an EXPRESSION
and be reused later on. Current values can be seen as special cases of
runtime variables, which are readonly.
Registers have the following syntax:
REGISTERSET:
EXPRESSION#EXPRESSIONCST
REGISTERGET:
#EXPRESSIONCST
Thus, to store any 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 *note Function examples::, for an example.
4.10 Fields
===========
A discretized quantity (defined in a function space, cf. *note
FunctionSpace::) is represented between braces '{}', and can only appear
in welldefined expressions in 'Formulation' (*note Formulation::) and
'PostProcessing' (*note PostProcessing::) objects:
QUANTITY:
< QUANTITYDOF > { < QUANTITYOPERATOR > QUANTITYID } 
{ < QUANTITYOPERATOR > QUANTITYID } [ EXPRESSIONCSTLIST ]
with
QUANTITYID:
STRING 
STRING ~ { EXPRESSIONCST }
and
QUANTITYDOF:
'Dof'
Defines a vector of discrete quantities (vector of 'D'egrees 'o'f
'f'reedom), 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.
An 'Equation' term must be linear with respect to the 'Dof'. Thus,
for example, a nonlinear term like
Integral { [ f[] * Dof{T}^4 , {T} ]; ... }
must first be linearized; and while
Integral { [ f[] * Dof{T} , {T} ]; ... }
Integral { [ f[] * 12 , {T} ]; ... }
is valid, the following, which is affine but not linear, is not:
Integral { [ f[] * (Dof{T}  12) , {T} ]; ... }
GetDP supports two linearization techniques. The first is
functional iteration (or Picard method), where one simply plugs the
value obtained at the previous iteration into the nonlinear
equation (the previous value is known, and is accessed e.g. with
'{T}' instead 'Dof{T}'). The second is the NewtonRaphson
iteration, where the Jacobian is specified with a 'JacNL' equation
term.
'BF'
Indicates that only a basis function will be used (only valid with
basis functions associated with regions).
QUANTITYOPERATOR:
'd'
Exterior derivative (d): applied to a Pform, gives a (P+1)form.
'Grad'
Gradient: applied to a scalar field, gives a vector.
'Curl'
'Rot'
Curl: applied to a vector field, gives a vector.
'Div'
Divergence (div): applied to a vector field, gives a scalar.
'D1'
Applies the operator specified in the first argument of 'dFunction
{ BASISFUNCTIONTYPE, BASISFUNCTIONTYPE }' (*note
FunctionSpace::). This is currently only used for
nodalinterpolated vector fields (interpolated with 'BF_Node_X',
'BF_Node_Y', 'BF_Node_Z')
When the first BASISFUNCTIONTYPE in 'dFunction' is set to
'BF_NodeX_D1' for component X, 'BF_NodeY_D1' for component Y and
'BF_NodeZ_D1' for component Z, then 'D1' applied to a vector [u_x,
u_y, u_z] gives: [du_x/dx, du_y/dy, du_z/dz] Note that in this case
specifying explicitely 'dFunction' is not necessary, as
'BF_NodeX_D1', 'BF_NodeY_D1' and 'BF_NodeZ_D1' are assigned by
default as the "'D1' derivatives" of 'BF_NodeX', 'BF_NodeY' and
'BF_NodeZ'. This also holds for 'BF_GroupOfNodes_X',
'BF_GroupOfNodes_Y' and 'BF_GroupOfNodes_Z'.
When the first BASISFUNCTIONTYPE in 'dFunction' is set to
'BF_NodeX_D12' for component X and 'BF_NodeY_D12' for component Y,
then 'D1' applied to a vector [u_x, u_y] gives: [du_x/dx, du_y/dy,
du_y/dx + du_x/dy]
'D2'
Applies the operator specified in the second argument of 'dFunction
{ BASISFUNCTIONTYPE, BASISFUNCTIONTYPE }' (*note
FunctionSpace::). This is currently only used for
nodalinterpolated vector fields (interpolated with 'BF_Node_X',
'BF_Node_Y', 'BF_Node_Z')
More specifically, when the second BASISFUNCTIONTYPE is to
'BF_NodeX_D2' for component X, 'BF_NodeY_D2' for component Y and
'BF_NodeZ_D2' for component Z, then 'D2' applied to a vector [u_x,
u_y, u_z] gives: [du_y/dx + du_x/dy, du_z/dy + du_y/dz, du_x/dz +
du_z/dx] Note that in this case specifying explicitely 'dFunction'
is not necessary, as 'BF_NodeX_D2', 'BF_NodeY_D2' and 'BF_NodeZ_D2'
are assigned by default as the "'D2' derivatives" of 'BF_NodeX',
'BF_NodeY' and 'BF_NodeZ'. This also holds for
'BF_GroupOfNodes_X', 'BF_GroupOfNodes_Y' and 'BF_GroupOfNodes_Z'.
Notes:
1. While the operators 'Grad', 'Curl' and 'Div' can be applied to 0, 1
and 2forms respectively, the exterior derivative operator 'd' is
usually preferred with such fields.
2. The second case permits to evaluate a discretized quantity at a
certain position X, Y, Z (when EXPRESSIONCSTLIST contains three
items) or at a specific time, N time steps ago (when
EXPRESSIONCSTLIST contains a single item).
4.11 Macros, loops and conditionals
===================================
Macros are defined as follows:
'Macro STRING  EXPRESSIONCHAR'
Begins the declaration of a userdefined file macro named STRING.
The body of the macro starts on the line after ''Macro STRING'',
and can contain any GetDP command.
'Return'
Ends the body of the current userdefined file macro. Macro
declarations cannot be imbricated, and must be made outside any
GetDP object.
'Macro ( EXPRESSIONCHAR , EXPRESSIONCHAR ) ;'
Begins the declaration of a userdefined string macro. The body of
the macro is given explicitly as the second argument.
Macros, loops and conditionals can be used in any of the following
objects: Group, Function, Constraint (as well as in a contraintcase),
FunctionSpace, Formulation (as well as in the quantity and equation
defintions), Resolution (as well as resolutionterm, system defintion
and operations), PostProcessing (in the definition of the
PostQuantities) and PostOperation (as well as in the operation list).
LOOP:
'Call STRING  EXPRESSIONCHAR;'
Executes the body of a (previously defined) macro named STRING.
'For ( EXPRESSIONCST : EXPRESSIONCST )'
Iterates from the value of the first EXPRESSIONCST to the value of
the second EXPRESSIONCST, with a unit incrementation step. At
each iteration, the commands comprised between ''For (
EXPRESSIONCST : EXPRESSIONCST )'' and the matching 'EndFor' are
executed.
'For ( EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST )'
Iterates from the value of the first EXPRESSIONCST to the value of
the second EXPRESSIONCST, with a positive or negative
incrementation step equal to the third EXPRESSIONCST. At each
iteration, the commands comprised between ''For ( EXPRESSIONCST :
EXPRESSIONCST : EXPRESSIONCST )'' and the matching 'EndFor' are
executed.
'For STRING In { EXPRESSIONCST : EXPRESSIONCST }'
Iterates from the value of the first EXPRESSIONCST to the value of
the second EXPRESSIONCST, with a unit incrementation step. At
each iteration, the value of the iterate is affected to an
expression named STRING, and the commands comprised between ''For
STRING In { EXPRESSIONCST : EXPRESSIONCST }'' and the matching
'EndFor' are executed.
'For STRING In { EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST }'
Iterates from the value of the first EXPRESSIONCST to the value of
the second EXPRESSIONCST, with a positive or negative
incrementation step equal to the third EXPRESSIONCST. At each
iteration, the value of the iterate is affected to an expression
named STRING, and the commands comprised between ''For STRING In {
EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST }'' and the
matching 'EndFor' are executed.
'EndFor'
Ends a matching 'For' command.
'If ( EXPRESSIONCST )'
The body enclosed between ''If ( EXPRESSIONCST )'' and the
matching 'ElseIf', 'Else' or 'EndIf', is evaluated if
EXPRESSIONCST is nonzero.
'ElseIf ( EXPRESSIONCST )'
The body enclosed between ''ElseIf ( EXPRESSIONCST )'' and the
next matching 'ElseIf', 'Else' or 'EndIf', is evaluated if
EXPRESSIONCST is nonzero and none of the EXPRESSIONCST of the
previous matching codes 'If' and 'ElseIf' were nonzero.
'Else'
The body enclosed between 'Else' and the matching 'EndIf' is
evaluated if none of the EXPRESSIONCST of the previous matching
codes 'If' and 'ElseIf' were nonzero.
'EndIf'
Ends a matching 'If' command.
'LevelTest'
Variable equal to the level of imbrication of a body in an
'If''EndIf' test.
'Parse [ EXPRESSIONCHAR ];'
Parse the given string.
5 Objects
*********
This chapter presents the formal definition of the ten GetDP objects
mentioned in *note Overview::. To be concise, all the possible
parameters for these objects are not given here (cf. the ETC syntactic
rule defined in *note Syntactic rules::). Please refer to *note Types
for objects::, for the list of all available options.
5.1 '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 (*note 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 *note Constants::.
The syntax for the definition of groups is:
Group {
< DefineGroup [ GROUPID <{INTEGER}> <,...> ]; > ...
< GROUPID = GROUPDEF; > ...
< GROUPID += GROUPDEF; > ...
< GROUPID = GROUPDEF; > ...
< AFFECTATION > ...
< LOOP > ...
}
with
GROUPID:
STRING 
STRING ~ { EXPRESSIONCST }
GROUPDEF:
GROUPTYPE [ GROUPLIST <, GROUPSUBTYPE GROUPLIST > ] 
GROUPID <{}> 
#GROUPLIST
GROUPTYPE:
Region  Global  NodesOf  EdgesOf  ETC
GROUPLIST:
All  GROUPLISTITEM  { GROUPLISTITEM <,...> }
GROUPLISTITEM:
INTEGER 
INTEGER : INTEGER 
INTEGER : INTEGER : INTEGER 
GROUPID <{}>
GROUPSUBTYPE:
Not  StartingOn  OnPositiveSideOf  ETC
Notes:
1. INTEGER as a GROUPLISTITEM is the only interface with the mesh;
with each element is associated a region number, being this
INTEGER, and a geometrical type (*note Input file format::).
Ranges of integers can be specified in the same way as ranges of
constant expressions in an EXPRESSIONCSTLISTITEM (*note
Constants::). For example, 'I:J' replaces the list of consecutive
integers I, I+1, ..., J1, J.
2. Array of groups: 'DefineGroup[GROUPID{N}]' defines the empty
groups 'GROUPID{I}', I=1, ..., n. Such a definition is optional,
i.e., each 'GROUPID{I}' can be separately defined, in any order.
3. '#GROUPLIST' is an abbreviation of 'Region[GROUPLIST]'.
See *note Types for Group::, for the complete list of options and *note
Group examples::, for some examples.
5.2 'Function': defining global and piecewise expressions
=========================================================
A userdefined 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 [ FUNCTIONID <,...> ]; > ...
< FUNCTIONID [ < GROUPDEF <, GROUPDEF > > ] = EXPRESSION; > ...
< AFFECTATION > ...
< LOOP > ...
}
with
FUNCTIONID:
STRING
Note:
1. The first optional GROUPDEF in brackets must be of 'Region' type,
and indicates on which region the (piecewise) function is defined.
The second optional GROUPDEF in brackets, also of 'Region' type,
defines an association with a second region for mutual
contributions. A default piecewise function can be defined with
'All' for GROUPDEF, for all the other nondefined regions.
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.
2. One can also define initially empty functions inline by replacing
the expression with '***'.
See *note Types for Function::, for the complete list of builtin
functions and *note Function examples::, for some examples.
5.3 '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 preresolution 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 {
{ < Append < EXPRESSIONCST >; >
Name CONSTRAINTID; Type CONSTRAINTTYPE;
Case {
{ Region GROUPDEF; < Type CONSTRAINTTYPE; >
< SubRegion GROUPDEF; > < TimeFunction EXPRESSION; >
< RegionRef GROUPDEF; > < SubRegionRef GROUPDEF; >
< Coefficient EXPRESSION; > < Function EXPRESSION; >
< Filter EXPRESSION; >
CONSTRAINTVAL; } ...
< LOOP > ...
}
 Case CONSTRAINTCASEID {
{ Region GROUPDEF; < Type CONSTRAINTTYPE; >
CONSTRAINTCASEVAL; } ...
< LOOP > ...
} ...
} ...
< AFFECTATION > ...
< LOOP > ...
}
with
CONSTRAINTID:
CONSTRAINTCASEID:
STRING 
STRING ~ { EXPRESSIONCST }
CONSTRAINTTYPE:
Assign  Init  Network  Link  ETC
CONSTRAINTVAL:
Value EXPRESSION  NameOfResolution RESOLUTIONID  ETC
CONSTRAINTCASEVAL:
Branch { INTEGER, INTEGER }  ETC
Notes:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'Constraint' of the same 'Name' with additional 'Case's.
2. The constraint type CONSTRAINTTYPE defined outside the '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'.
3. The region type 'Region GROUPDEF' will be the main GROUPLIST
argument of the GROUPDEF to be built for the constraints of
'FunctionSpace's. The optional region type 'SubRegion GROUPDEF'
will be the argument of the associated GROUPSUBTYPE.
4. EXPRESSION in 'Value' of CONSTRAINTVAL cannot be time dependent
('$Time') because it is evaluated only once during the
preprocessing (for efficiency reasons). Time dependences must be
defined in 'TimeFunction EXPRESSION'.
See *note Types for Constraint::, for the complete list of options and
*note Constraint examples::, for some examples.
5.4 '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
builtin 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
madetomeasure function spaces adapted to a wide variety of field
approximations (*note FunctionSpace examples::).
The syntax for the definition of function spaces is:
FunctionSpace {
{ < Append < EXPRESSIONCST >; >
Name FUNCTIONSPACEID;
Type FUNCTIONSPACETYPE;
BasisFunction {
{ Name BASISFUNCTIONID; NameOfCoef COEFID;
Function BASISFUNCTIONTYPE
< { Quantity QUANTITYID;
Formulation FORMULATIONID { EXPRESSIONCST };
Group GROUPDEF;
Resolution RESOLUTIONID { EXPRESSIONCST } } >;
< dFunction { BASISFUNCTIONTYPE, BASISFUNCTIONTYPE } ; >
Support GROUPDEF; Entity GROUPDEF; } ...
}
< SubSpace {
{ < Append < EXPRESSIONCST >; >
Name SUBSPACEID;
NameOfBasisFunction BASISFUNCTIONLIST; } ...
} >
< GlobalQuantity {
{ Name GLOBALQUANTITYID; Type GLOBALQUANTITYTYPE;
NameOfCoef COEFID; } ...
} >
< Constraint {
{ NameOfCoef COEFID;
EntityType Auto  GROUPTYPE; < EntitySubType GROUPSUBTYPE; >
NameOfConstraint CONSTRAINTID <{}>; } ...
} >
} ...
< AFFECTATION > ...
< LOOP > ...
}
with
FUNCTIONSPACEID:
FORMULATIONID:
RESOLUTIONID:
STRING 
STRING ~ { EXPRESSIONCST }
BASISFUNCTIONID:
COEFID:
SUBSPACEID:
GLOBALQUANTITYID:
STRING
FUNCTIONSPACETYPE:
Scalar  Vector  Form0  Form1  ETC
BASISFUNCTIONTYPE:
BF_Node  BF_Edge  ETC
BASISFUNCTIONLIST:
BASISFUNCTIONID  { BASISFUNCTIONID <,...> }
GLOBALQUANTITYTYPE:
AliasOf  AssociatedWith
Notes:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive; its omission fixes it to a top
value) permits to append an existing 'FunctionSpace' of the same
'Name' with additional 'BasisFunction's, 'SubSpace's,
'GlobalQuantity''s and 'Constraint's, or an existing 'SubSpace' of
the same 'Name' with additional 'NameOfBasisFunction''s. If the
'Append' 'FunctionSpace' level is 2, the 'Append' 'SubSpace' level
is automatically 1 if omitted.
2. When the definition region of a function type group used as an
'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).
3. The same 'Name' for several 'BasisFunction' fields permits to
define piecewise basis functions; separate 'NameOfCoef's must be
defined for those fields.
4. A constraint is associated with geometrical entities defined by an
automatically created 'Group' of type GROUPTYPE ('Auto'
automatically fixes it as the 'Entity' GROUPDEF type of the
related 'BasisFunction'), using the 'Region' defined in a
'Constraint' object as its main argument, and the optional
'SubRegion' in the same object as a GROUPSUBTYPE argument.
5. A global basis function ('BF_Global' or 'BF_dGlobal') needs
parameters, i.e., it is given by the quantity (QUANTITYID)
precomputed from multiresolutions performed on multiformulations.
6. Explicit derivatives of the basis functions can be specified using
'dFunction { BASISFUNCTIONTYPE , BASISFUNCTIONTYPE }'. These
derivates can be accessed using the special 'D1' and 'D2' operators
(*note Fields::).
See *note Types for FunctionSpace::, for the complete list of options
and *note FunctionSpace examples::, for some examples.
5.5 '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 {
{ < Append < EXPRESSIONCST >; >
Name JACOBIANID;
Case {
{ Region GROUPDEF  All;
Jacobian JACOBIANTYPE < { EXPRESSIONCSTLIST } >; } ...
}
} ...
}
with
JACOBIANID:
STRING
JACOBIANTYPE:
Vol  Sur  VolAxi  ETC
Note:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'Jacobian' of the same 'Name' with additional 'Case's.
2. The default case of a 'Jacobian' object is defined by 'Region All'
and must follow all the other cases.
See *note Types for Jacobian::, for the complete list of options and
*note Jacobian examples::, for some examples.
5.6 '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 methodswhich 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 {
{ < Append < EXPRESSIONCST >; >
Name INTEGRATIONID; < Criterion EXPRESSION; >
Case {
< { Type INTEGRATIONTYPE;
Case {
{ GeoElement ELEMENTTYPE; NumberOfPoints EXPRESSIONCST } ...
}
} ... >
< { Type Analytic; } ... >
}
} ...
}
with
INTEGRATIONID:
STRING
INTEGRATIONTYPE:
Gauss  ETC
ELEMENTTYPE:
Line  Triangle  Tetrahedron ETC
Note:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'Integration' of the same 'Name' with additional 'Case's.
See *note Types for Integration::, for the complete list of options and
*note Integration examples::, for some examples.
5.7 '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 {
{ < Append < EXPRESSIONCST >; >
Name FORMULATIONID; Type FORMULATIONTYPE;
Quantity {
{ Name QUANTITYID; Type QUANTITYTYPE;
NameOfSpace FUNCTIONSPACEID <{}>
< [ SUBSPACEID  GLOBALQUANTITYID ] >;
< Symmetry EXPRESSIONCST; >
< [ EXPRESSION ]; In GROUPDEF;
Jacobian JACOBIANID; Integration INTEGRATIONID; >
< IndexOfSystem INTEGER; > } ...
}
Equation {
< LOCALTERMTYPE
{ < TERMOPTYPE > [ EXPRESSION, EXPRESSION ];
In GROUPDEF; Jacobian JACOBIANID;
Integration INTEGRATIONID; } > ...
< GlobalTerm
{ < TERMOPTYPE > [ EXPRESSION, EXPRESSION ];
In GROUPDEF; < SubType EQUATIONTERMSUBTYPE; > } > ...
< GlobalEquation
{ Type Network; NameOfConstraint CONSTRAINTID;
{ Node EXPRESSION; Loop EXPRESSION; Equation EXPRESSION;
In GROUPDEF; } ...
} > ...
< AFFECTATION > ...
< LOOP > ...
}
} ...
< AFFECTATION > ...
< LOOP > ...
}
with
FORMULATIONID:
STRING 
STRING ~ { EXPRESSIONCST }
FORMULATIONTYPE:
FemEquation  ETC
LOCALTERMTYPE:
Integral  deRham
EQUATIONTERMSUBTYPE:
Self (default)  Mutual  SelfAndMutual
QUANTITYTYPE:
Local  Global  Integral
TERMOPTYPE:
DtDof  DtDtDof  Eig  JacNL  ETC
Note:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'Formulation' of the same 'Name' with additional 'Quantity''s and
'Equation's.
2. '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 (*note
Resolution::).
3. A '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. The optional associated 'SubType' defines either self
(default) or mutual contributions, or both. Mutual contributions
need piecewise functions defined on pairs or regions.
4. A 'GlobalEquation' defines a global equation to be assembled in the
matrix of the system.
See *note Types for Formulation::, for the complete list of options and
*note Formulation examples::, for some examples.
5.8 '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 (NewtonRaphson and fixed point methods), etc.
Multiharmonic resolutions, coupled problems (e.g., magnetothermal) or
linked problems (e.g., precomputations 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 {
{ < Append < EXPRESSIONCST >; >
Name RESOLUTIONID; < Hidden EXPRESSIONCST; >
System {
{ Name SYSTEMID; NameOfFormulation FORMULATIONLIST;
< Type SYSTEMTYPE; >
< Frequency EXPRESSIONCSTLISTITEM 
Frequency { EXPRESSIONCSTLIST }; >
< DestinationSystem SYSTEMID; >
< OriginSystem SYSTEMID;  OriginSystem { SYSTEMID <,...> }; >
< NameOfMesh EXPRESSIONCHAR > < Solver EXPRESSIONCHAR >
< LOOP > } ...
< LOOP > ...
}
Operation {
< RESOLUTIONOP; > ...
< LOOP > ...
}
} ...
< AFFECTATION > ...
< LOOP > ...
}
with
RESOLUTIONID:
SYSTEMID:
STRING 
STRING ~ { EXPRESSIONCST }
FORMULATIONLIST:
FORMULATIONID <{}>  { FORMULATIONID <{}> <,...> }
SYSTEMTYPE:
Real  Complex
RESOLUTIONOP:
Generate[SYSTEMID]  Solve[SYSTEMID]  ETC
Notes:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'Resolution' of the same 'Name' with additional 'System's and
'Operation's.
2. The default type for a system of equations is 'Real'. A frequency
domain analysis is defined through the definition of one or several
frequencies ('Frequency EXPRESSIONCSTLISTITEM  Frequency {
EXPRESSIONCSTLIST }'). Complex systems of equations with no
predefined list of frequencies (e.g., in modal analyses) can be
explicitely defined with 'Type Complex'.
3. 'NameOfMesh' permits to explicitely specify the mesh to be used for
the construction of the system of equations.
4. '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 precompiled copy of
GetDP from the internet).
5. 'DestinationSystem' permits to specify the destination system of a
'TransferSolution' operation (*note Types for Resolution::).
6. 'OriginSystem' permits to specify the systems from which ambiguous
quantity definitions can be solved (*note Formulation::).
See *note Types for Resolution::, for the complete list of options and
*note Resolution examples::, for some examples.
5.9 '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 {
{ < Append < EXPRESSIONCST >; >
Name POSTPROCESSINGID;
NameOfFormulation FORMULATIONID <{}>; < NameOfSystem SYSTEMID; >
Quantity {
{ < Append < EXPRESSIONCST >; >
Name POSTQUANTITYID; Value { POSTVALUE ... } } ...
< LOOP > ...
}
} ...
< AFFECTATION > ...
< LOOP > ...
}
with
POSTPROCESSINGID:
POSTQUANTITYID:
STRING 
STRING ~ { EXPRESSIONCST }
POSTVALUE:
Local { LOCALVALUE }  Integral { INTEGRALVALUE }
LOCALVALUE:
[ EXPRESSION ]; In GROUPDEF; Jacobian JACOBIANID;
INTEGRALVALUE:
[ EXPRESSION ]; In GROUPDEF;
Integration INTEGRATIONID; Jacobian JACOBIANID;
Notes:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive; its omission fixes it to a top
value) permits to append an existing 'PostProcessing' of the same
'Name' with additional 'Value's, or an existing 'Quantity' of the
same 'Name' with additional 'Quantity''s. If the 'Append'
'PostProcessing' level is 2, the 'Append' 'Quantity' level is
automatically 1 if omitted. Fixing the 'Append' 'Quantity' level
to N suppresses the N lastly defined 'Quantity''s before
appending.
2. The quantity defined with INTEGRALVALUE is piecewise defined over
the elements of the mesh of GROUPDEF, and takes, in each element,
the value of the integration of EXPRESSION over this element. The
global integral of EXPRESSION over a whole region (being either
GROUPDEF or a subset of GROUPDEF) has to be defined in the
'PostOperation' with the 'POSTQUANTITYID[GROUPDEF]' command
(*note PostOperation::).
3. If 'NameOfSystem SYSTEMID' is not given, the system is
automatically selected as the one to which the first quantity
listed in the 'Quantity' field of FORMULATIONID is associated.
See *note Types for PostProcessing::, for the complete list of options
and *note PostProcessing examples::, for some examples.
5.10 '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
userdefined plane, etc.), and outputs the results in several file
formats.
PostOperation {
{ < Append < EXPRESSIONCST >; >
Name POSTOPERATIONID; NameOfPostProcessing POSTPROCESSINGID;
< Hidden EXPRESSIONCST; >
< Format POSTOPERATIONFMT; >
< TimeValue EXPRESSIONCSTLIST; > < TimeImagValue EXPRESSIONCSTLIST; >
< LastTimeStepOnly < EXPRESSIONCST >; >
< OverrideTimeStepValue EXPRESSIONCST; >
< NoMesh EXPRESSIONCST; > < AppendToExistingFile EXPRESSIONCST; >
< ResampleTime[EXPRESSIONCST, EXPRESSIONCST, EXPRESSIONCST]; >
< AppendTimeStepToFileName < EXPRESSIONCST >; >
Operation {
< POSTOPERATIONOP; > ...
}
} ...
< AFFECTATION > ...
< LOOP > ...
} 
PostOperation < (Append < EXPRESSIONCST >) > POSTOPERATIONID UsingPost POSTPROCESSINGID {
< POSTOPERATIONOP; > ...
} ...
with
POSTOPERATIONID:
STRING 
STRING ~ { EXPRESSIONCST }
POSTOPERATIONOP:
Print[ POSTQUANTITYID <[GROUPDEF]>, PRINTSUPPORT <,PRINTOPTION> ... ] 
Print[ EXPRESSIONLIST, Format "STRING" <,PRINTOPTION> ... ] 
PrintGroup[ GROUPID, PRINTSUPPORT <,PRINTOPTION> ... ] 
Echo[ "STRING" <,PRINTOPTION> ... ] 
CreateDir [ "STRING" ] 
DeleteFile [ "STRING" ] 
SendMergeFileRequest[ EXPRESSIONCHAR ] 
< LOOP > ...
ETC
PRINTSUPPORT:
OnElementsOf GROUPDEF  OnRegion GROUPDEF  OnGlobal  ETC
PRINTOPTION:
File EXPRESSIONCHAR  Format POSTOPERATIONFMT  ETC
POSTOPERATIONFMT:
Table  TimeTable  ETC
Notes:
1. The optional 'Append < EXPRESSIONCST >' (when the optional level
EXPRESSIONCST is strictly positive) permits to append an existing
'PostOperation' of the same 'Name' with additional 'Operation's.
2. Both 'PostOperation' syntaxes are equivalent. The first one
conforms to the overall interface, but the second one is more
concise.
3. The format POSTOPERATIONFMT defined outside the 'Operation' field
is applied to all the postprocessing operations, unless other
formats are explicitly given in these operations with the 'Format'
option (*note Types for PostOperation::). The default format is
'Gmsh'.
4. The 'ResampleTime' option allows equidistant resampling of the time
steps by a spline interpolation. The parameters are: start time,
stop time, time step.
5. The optional argument '[GROUPDEF]' of the POSTQUANTITYID can
only be used when this quantity has been defined as an
INTEGRALVALUE (*note PostProcessing::). In this case, the sum of
all elementary integrals is performed over the region GROUPDEF.
See *note Types for PostOperation::, for the complete list of options
and *note PostOperation examples::, for some examples.
6 Types for objects
*******************
This chapter presents the complete list of choices associated with
metasyntactic variables introduced for the ten GetDP objects.
6.1 Types for 'Group'
=====================
Types in
GROUPTYPE [ R1 <, GROUPSUBTYPE R2 <, GROUPSUBTYPE2 R3 > > ]
'GROUPTYPE < GROUPSUBTYPE < GROUPSUBTYPE2 > >':
'Region'
Regions in R1.
'Global'
Regions in R1 (variant of 'Region' used with global
'BasisFunction's 'BF_Global' and 'BF_dGlobal').
'NodesOf'
Nodes of elements of R1
< 'Not': but not those of R2 >.
'EdgesOf'
Edges of elements of R1
< 'Not': but not those of R2 >.
'FacetsOf'
Facets of elements of R1
< 'Not': but not those of R2 >.
'VolumesOf'
Volumes of elements of R1
< 'Not': but not those of R2 >.
'ElementsOf'
Elements of regions in R1
< 'OnOneSideOf': only elements on one side of R2 (nonautomatic,
i.e., both sides if both in R1) >  < 'OnPositiveSideOf': only
elements on positive (normal) side of R2 < , 'Not': but not those
touching only its skin R3 (mandatory for free skins for correct
separation of side layers) > >.
'GroupsOfNodesOf'
Groups of nodes of elements of R1 (a group is associated with each
region).
'GroupsOfEdgesOf'
Groups of edges of elements of R1 (a group is associated with each
region).
< 'InSupport': in a support R2 being a group of type 'ElementOf',
i.e., containing elements >.
'GroupsOfEdgesOnNodesOf'
Groups of edges incident to nodes of elements of R1 (a group is
associated with each node).
< 'Not': but not those of R2) >.
'GroupOfRegionsOf'
Single group of elements of regions in R1 (with basis function
BF_Region just one DOF is created for all elements of R1).
'EdgesOfTreeIn'
Edges of a tree of edges of R1
< 'StartingOn': a complete tree is first built on R2 >.
'FacetsOfTreeIn'
Facets of a tree of facets of R1
< 'StartingOn': a complete tree is first built on R2 >.
'DualNodesOf'
Dual nodes of elements of R1.
'DualEdgesOf'
Dual edges of elements of R1.
'DualFacetsOf'
Dual facets of elements of R1.
'DualVolumesOf'
Dual volumes of elements of R1.
6.2 Types for 'Function'
========================
6.2.1 Math functions

The following functions are the equivalent of the functions of the C or
C++ math library. Unless indicated otherwise, arguments to these
functions can be real or complex valued when used in EXPRESSIONs. When
used in constant expressions (EXPRESSIONCST, see *note Constants::),
only realvalued arguments are accepted.
MATHFUNCTIONID:
'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] (real valued only).
'Cos'
'[EXPRESSION]'
Cosine of EXPRESSION.
'Acos'
'[EXPRESSION]'
Arc cosine (inverse cosine) of EXPRESSION in [0,Pi], EXPRESSION in
[1,1] (real valued only).
'Tan'
'[EXPRESSION]'
Tangent of EXPRESSION.
'Atan'
'[EXPRESSION]'
Arc tangent (inverse tangent) of EXPRESSION in [Pi/2,Pi/2] (real
valued only).
'Atan2'
'[EXPRESSION,EXPRESSION]'
Arc tangent (inverse tangent) of the first EXPRESSION divided by
the second, in [Pi,Pi] (real valued only).
'Sinh'
'[EXPRESSION]'
Hyperbolic sine of EXPRESSION.
'Cosh'
'[EXPRESSION]'
Hyperbolic cosine of EXPRESSION.
'Tanh'
'[EXPRESSION]'
Hyperbolic tangent of the real valued EXPRESSION.
'TanhC2'
'[EXPRESSION]'
Hyperbolic tangent of a complex valued EXPRESSION.
'Fabs'
'[EXPRESSION]'
Absolute value of EXPRESSION (real valued only).
'Abs'
'[EXPRESSION]'
Absolute value of EXPRESSION.
'Floor'
'[EXPRESSION]'
Rounds downwards to the nearest integer that is not greater than
EXPRESSION (real valued only).
'Ceil'
'[EXPRESSION]'
Rounds upwards to the nearest integer that is not less than
EXPRESSION (real valued only).
'Fmod'
'[EXPRESSION,EXPRESSION]'
Remainder of the division of the first EXPRESSION by the second,
with the sign of the first (real valued only).
'Min'
'[EXPRESSION,EXPRESSION]'
Minimum of the two (scalar) expressions (real valued only).
'Max'
'[EXPRESSION,EXPRESSION]'
Maximum of the two (scalar) expressions (real valued only).
'Sign'
'[EXPRESSION]'
1 for EXPRESSION less than zero and 1 otherwise (real valued
only).
'Jn'
'[EXPRESSION]'
Returns the Bessel function of the first kind of order given by the
first EXPRESSION for the value of the second EXPRESSION (real
valued only).
'dJn'
'[EXPRESSION]'
Returns the derivative of the Bessel function of the first kind of
order given by the first EXPRESSION for the value of the second
EXPRESSION (real valued only).
'Yn'
'[EXPRESSION]'
Returns the Bessel function of the second kind of order given by
the first EXPRESSION for the value of the second EXPRESSION (real
valued only).
'dYn'
'[EXPRESSION]'
Returns the derivative of the Bessel function of the second kind of
order given by the first EXPRESSION for the value of the second
EXPRESSION (real valued only).
6.2.2 Extended math functions

EXTENDEDMATHFUNCTIONID:
'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.e30.
'Transpose'
'[EXPRESSION]'
Transposition; EXPRESSION must be a tensor.
'Inv'
'[EXPRESSION]'
Inverse of the tensor EXPRESSION.
'Det'
'[EXPRESSION]'
Determinant of the tensor EXPRESSION.
'Rotate'
'[EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION]'
Rotation of a vector or tensor given by the first EXPRESSION by the
angles in radians given by the last three EXPRESSION values around
the x, y and zaxis.
'TTrace'
'[EXPRESSION]'
Trace; EXPRESSION must be a tensor.
'Cos_wt_p'
'[]{EXPRESSIONCST,EXPRESSIONCST}'
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[p],Sin[p]]'.
'Sin_wt_p'
'[]{EXPRESSIONCST,EXPRESSIONCST}'
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[p],Cos[p]]'.
'Period'
'[EXPRESSION]{EXPRESSIONCST}'
'Fmod[EXPRESSION,EXPRESSIONCST]' '+' '(EXPRESSION<0 ?
EXPRESSIONCST : 0)'; the result is always in [0,EXPRESSIONCST[.
'Interval'
'[EXPRESSION,EXPRESSION,EXPRESSION]{EXPRESSIONCST,
EXPRESSIONCST,EXPRESSIONCST}'
Not documented yet.
6.2.3 Green functions

The Green functions are only used in integral quantities (*note
Formulation::). 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]'
The triplets of values given in the definitions below correspond to the
'1D', '2D' and '3D' cases.
GREENFUNCTIONID:
'Laplace'
'[]{EXPRESSIONCST}'
'r/2', '1/(2*Pi)*ln(1/r)', '1/(4*Pi*r)'.
'GradLaplace'
'[]{EXPRESSIONCST}'
Gradient of 'Laplace' relative to the destination point ('$X',
'$Y', '$Z').
'Helmholtz'
'[]{EXPRESSIONCST, EXPRESSIONCST}'
'exp(j*k0*r)/(4*Pi*r)', where 'k0' is given by the second
parameter.
'GradHelmholtz'
'[]{EXPRESSIONCST, EXPRESSIONCST}'
Gradient of 'Helmholtz' relative to the destination point ('$X',
'$Y', '$Z').
6.2.4 Type manipulation functions

TYPEFUNCTIONID:
'Complex'
'[EXPRESSIONLIST]'
Creates a (multiharmonic) complex expression from an number of
realvalued expressions. The number of expressions in
EXPRESSIONLIST must be even.
'Complex_MH'
'[EXPRESSIONLIST]{EXPRESSIONCSTLIST}'
Not documented yet.
'Re'
'[EXPRESSION]'
Takes the real part of a complexvalued expression.
'Im'
'[EXPRESSION]'
Takes the imaginary part of a complexvalued expression.
'Conj'
'[EXPRESSION]'
Computes the conjugate of a complexvalued expression.
'Cart2Pol'
'[EXPRESSION]'
Converts the cartesian form (reale, imaginary) of a complexvalued
expression into polar form (amplitude, phase [radians]).
'Vector'
'[EXPRESSION,EXPRESSION,EXPRESSION]'
Creates a vector from 3 scalars.
'Tensor'
'[EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION,'
'EXPRESSION,EXPRESSION,EXPRESSION]'
Creates a secondrank tensor of order 3 from 9 scalars, by row:
[ scalar0 scalar1 scalar2 ] [ CompXX CompXY CompXZ ]
T = [ scalar3 scalar4 scalar5 ] = [ CompYX CompYY CompYZ ]
[ scalar6 scalar7 scalar8 ] [ CompZX CompZY CompZZ ]
'TensorV'
'[EXPRESSION,EXPRESSION,EXPRESSION]'
Creates a secondrank tensor of order 3 from 3 row vectors:
[ vector0 ]
T = [ vector1 ]
[ vector2 ]
'TensorSym'
'[EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION,EXPRESSION]'
Creates a symmetrical secondrank tensor of order 3 from 6 scalars.
'TensorDiag'
'[EXPRESSION,EXPRESSION,EXPRESSION]'
Creates a diagonal secondrank tensor of order 3 from 3 scalars.
'SquDyadicProduct'
'[EXPRESSION]'
Dyadic product of the vector given by EXPRESSION with itself.
'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.
'Cart2Sph'
'[EXPRESSION]'
Gets the tensor for transformation of vector from cartesian to
spherical coordinates.
'Cart2Cyl'
'[EXPRESSION]'
Gets the tensor for transformation of vector from cartesian to
cylindric coordinates. E.g. to convert a vector with
(x,y,z)components to one with (radial, tangential,
axial)components: Cart2Cyl[XYZ[]] * vector
'UnitVectorX'
'[]'
Creates a unit vector in xdirection.
'UnitVectorY'
'[]'
Creates a unit vector in ydirection.
'UnitVectorZ'
'[]'
Creates a unit vector in zdirection.
6.2.5 Coordinate functions

COORDFUNCTIONID:
'X'
'[]'
Gets the X coordinate.
'Y'
'[]'
Gets the Y coordinate.
'Z'
'[]'
Gets the Z coordinate.
'XYZ'
'[]'
Gets X, Y and Z in a vector.
6.2.6 Miscellaneous functions

MISCFUNCTIONID:
'Printf'
'[EXPRESSION]'
Prints the value of EXPRESSION when evaluated. ('MPI_Printf' can
be use instead, to print the message for all MPI ranks.)
'Rand'
'[EXPRESSION]'
Returns a pseudorandom number in [0, EXPRESSION].
'Normal'
'[]'
Computes the normal to the element.
'NormalSource'
'[]'
Computes the normal to the source element (only valid in a quantity
of Integral type).
'Tangent'
'[]'
Computes the tangent to the element (only valid for line elements).
'TangentSource'
'[]'
Computes the tangent to the source element (only valid in a
quantity of Integral type and only for line elements).
'ElementVol'
'[]'
Computes the element's volume.
'SurfaceArea'
'[]{EXPRESSIONCSTLIST}'
Computes the area of the physical surfaces in EXPRESSIONCSTLIST
or of the actual surface if EXPRESSIONCSTLIST is empty.
'GetVolume'
'[]'
Computes the volume of the actual physical group.
'CompElementNum'
'[]'
Returns 0 if the current element and the current source element are
identical.
'GetNumElements'
'[]{EXPRESSIONCSTLIST}'
Counts the elements of physical numbers in EXPRESSIONCSTLIST or
of the actual region if EXPRESSIONCSTLIST is empty.
'ElementNum'
'[]'
Returns the tag (number) of the current element.
'QuadraturePointIndex'
'[]'
Returns the index of the current quadrature point.
'AtIndex'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Returns the ith entry of EXPRESSIONCSTLIST. This can be used to
get an element in a list, using an index that is computed at
runtime.
'InterpolationLinear'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Linear interpolation of points. The number of constant expressions
in EXPRESSIONCSTLIST must be even.
'dInterpolationLinear'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Derivative of linear interpolation of points. The number of
constant expressions in EXPRESSIONCSTLIST must be even.
'InterpolationBilinear'
'[EXPRESSION,EXPRESSION]{EXPRESSIONCSTLIST}'
Bilinear interpolation of a table based on two variables.
'dInterpolationBilinear'
'[EXPRESSION,EXPRESSION]{EXPRESSIONCSTLIST}'
Derivative of bilinear interpolation of a table based on two
variables. The result is a vector.
'InterpolationAkima'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Akima interpolation of points. The number of constant expressions
in EXPRESSIONCSTLIST must be even.
'dInterpolationAkima'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Derivative of Akima interpolation of points. The number of
constant expressions in EXPRESSIONCSTLIST must be even.
'Order'
'[QUANTITY]'
Returns the interpolation order of the QUANTITY.
'Field'
'[EXPRESSION]'
Evaluate the last one of the fields ("views") loaded with
'GmshRead' (*note Types for Resolution::), at the point EXPRESSION.
Common usage is thus 'Field[XYZ[]]'.
'Field'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but evaluate all the fields corresponding to the tags in the
list, and sum all the values. A field having no value at the given
position does not produce an error: its contribution to the sum is
simply zero.
'ScalarField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only realvalued scalar fields. A second
optional argument is the value of the time step. A third optional
argument is a boolean flag to indicate that the interpolation
should be performed (if possible) in the same element as the
current element.
'VectorField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only realvalued vector fields. Optional
arguments are treated in the same way as for 'ScalarField'.
'TensorField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only realvalued tensor fields. Optional
arguments are treated in the same way as for 'ScalarField'.
'ComplexScalarField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only complexvalued scalar fields. Optional
arguments are treated in the same way as for 'ScalarField'.
'ComplexVectorField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only complexvalued vector fields. Optional
arguments are treated in the same way as for 'ScalarField'.
'ComplexTensorField'
'[EXPRESSION]{EXPRESSIONCSTLIST}'
Idem, but consider only complexvalued tensor fields. Optional
arguments are treated in the same way as for 'ScalarField'.
'Distance'
'[EXPRESSION]{EXPRESSIONCST}'
Evaluate the distance between the point (whose x, y, z coordinates
are given as a vector argument) and a vector valued view,
interpreted as a displacement field (i.e. compute the minimal
distance between the point and the deformed mesh in the view).
'GetCpuTime'
'[]'
Returns current CPU time, in seconds (total amount of time spent
executing in user mode since GetDP was started).
'GetWallClockTime'
'[]'
Returns the current wall clock time, in seconds (total wall clock
time since GetDP was started).
'GetMemory'
'[]'
Returns the current memory usage, in megabytes (maximum resident
set size).
'SetNumberRunTime'
'[EXPRESSION]{CHAREXPRESSION}'
Sets the CHAREXPRESSION ONELAB variable at runtime to EXPRESSION.
'SetNumberRunTimeWithChoices'
'[EXPRESSION]{CHAREXPRESSION}'
Same as 'SetNumberRunTime', but adds the value to the choices of
the ONELAB variable (i.e. in the same way as 'SendToServer' in
'PostOperation', which are used for plotting the history of the
variable).
'GetNumberRunTime'
'[ ]{CHAREXPRESSION}'
Gets the value of the CHAREXPRESSION ONELAB variable at runtime.
If the optional EXPRESSION is provided, it is used as a default
value if ONELAB is not available.
'SetVariable'
'[ EXPRESSION <,...> ]{ $VARIABLEID }'
Sets the value of the runtime variable '$VARIABLEID' to the value
of the first EXPRESSION, and returns this value. If optional
EXPRESSIONs are provided, they are appended to the variable name,
separated by '_'.
'GetVariable'
'[ <,...> ]{ $VARIABLEID }'
Gets the value of the runtime variable '$VARIABLEID'. If the
optional EXPRESSIONs are provided, they are appended to the
variable name, separated by '_'.
'ValueFromIndex'
'[ ]{ EXPRESSIONCSTLIST }'
Treats EXPRESSIONCSTLIST as a map of (ENTITY, VALUE) pairs.
Useful to specify nodal or elementwise constraints, where ENTITY
is the node (mesh vertex) or element number (tag).
'VectorFromIndex'
'[ ]{ EXPRESSIONCSTLIST }'
Same 'ValueFromIndex', but with 3 scalar values per ENTITY.
'ValueFromTable'
'[ EXPRESSION ]{ CHAREXPRESSION }'
Accesses the map CHAREXPRESSION created by a 'NodeTable' or
'ElementTable' 'PostOperation'. If the map is not available (e.g.
in preprocessing), or if the entity is not found in the map, use
EXPRESSION as default value. Useful to specify nodal or
elementwise constraints, where ENTITY is the node (mesh vertex) or
element number (tag).
6.3 Types for 'Constraint'
==========================
CONSTRAINTTYPE:
'Assign'
To assign a value (e.g., for boundary condition).
'Init'
To give an initial value (e.g., initial value in a time domain
analysis). If two values are provided (with 'Value [ EXPRESSION,
EXPRESSION ]'), the first value can be used using the
'InitSolution1' operation. This is mainly useful for the Newmark
timestepping scheme.
'AssignFromResolution'
To assign a value to be computed by a preresolution.
'InitFromResolution'
To give an initial value to be computed by a preresolution.
'Network'
To describe the node connections of branches in a network.
'Link'
To define links between degrees of freedom in the constrained
region with degrees of freedom in a "reference" region, with some
coefficient. For example, to link the degrees of freedom in the
contrained region 'Left' with the degrees of freedom in the
reference region 'Right', located Pi units to the right of the
region 'Left' along the Xaxis, with the coeficient '1', one could
write:
{ Name periodic;
Case {
{ Region Left; Type Link ; RegionRef Right;
Coefficient 1; Function Vector[X[]+Pi, Y[], Z[]] ;
< FunctionRef XYZ[]; >
}
}
}
In this example, 'Function' defines the mapping that translates the
geometrical elements in the region 'Left' by Pi units along the
Xaxis, so that they correspond with the elements in the reference
region 'Right'. For this mapping to work, the meshes of 'Left' and
'Right' must be identical. (The optional 'FunctionRef' function
allows to transform the reference region, useful e.g. to avoid
generating overlapping meshes for rotational links.)
'LinkCplx'
To define complexvalued links between degrees of freedom. The
syntax is the same as for constraints of type 'Link', but
'Coeficient' can be complex.
6.4 Types for 'FunctionSpace'
=============================
FUNCTIONSPACETYPE:
'Form0'
0form, i.e., scalar field of potential type.
'Form1'
1form, i.e., curlconform field (associated with a curl).
'Form2'
2form, i.e., divconform field (associated with a divergence).
'Form3'
3form, i.e., scalar field of density type.
'Form1P'
1form perpendicular to the Z=0 plane, i.e., perpendicular
curlconform field (associated with a curl).
'Form2P'
2form in the Z=0 plane, i.e., parallel divconform field
(associated with a divergence).
'Scalar'
Scalar field.
'Vector'
Vector field.
BASISFUNCTIONTYPE:
'BF_Node'
Nodal function (on 'NodesOf', value 'Form0').
'BF_Edge'
Edge function (on 'EdgesOf', value 'Form1').
'BF_Facet'
Facet function (on 'FacetsOf', value 'Form2').
'BF_Volume'
Volume function (on 'VolumesOf', value 'Form3').
'BF_GradNode'
Gradient of nodal function (on 'NodesOf', value 'Form1').
'BF_CurlEdge'
Curl of edge function (on 'EdgesOf', value 'Form2').
'BF_DivFacet'
Divergence of facet function (on 'FacetsOf', value 'Form3').
'BF_GroupOfNodes'
Sum of nodal functions (on 'GroupsOfNodesOf', value 'Form0').
'BF_GradGroupOfNodes'
Gradient of sum of nodal functions (on 'GroupsOfNodesOf', value
'Form1').
'BF_GroupOfEdges'
Sum of edge functions (on 'GroupsOfEdgesOf', value 'Form1').
'BF_CurlGroupOfEdges'
Curl of sum of edge functions (on 'GroupsOfEdgesOf', value
'Form2').
'BF_PerpendicularEdge'
1form (0, 0, 'BF_Node') (on 'NodesOf', value 'Form1P').
'BF_CurlPerpendicularEdge'
Curl of 1form (0, 0, 'BF_Node') (on 'NodesOf', value 'Form2P').
'BF_GroupOfPerpendicularEdge'
Sum of 1forms (0, 0, 'BF_Node') (on 'NodesOf', value 'Form1P').
'BF_CurlGroupOfPerpendicularEdge'
Curl of sum of 1forms (0, 0, 'BF_Node') (on 'NodesOf', value
'Form2P').
'BF_PerpendicularFacet'
2form (90 degree rotation of 'BF_Edge') (on 'EdgesOf', value
'Form2P').
'BF_DivPerpendicularFacet'
Div of 2form (90 degree rotation of 'BF_Edge') (on 'EdgesOf',
value 'Form3').
'BF_Region'
Unit value 1 (on 'Region' or 'GroupOfRegionsOf', value 'Scalar').
'BF_RegionX'
Unit vector (1, 0, 0) (on 'Region', value 'Vector').
'BF_RegionY'
Unit vector (0, 1, 0) (on 'Region', value 'Vector').
'BF_RegionZ'
Unit vector (0, 0, 1) (on 'Region', value 'Vector').
'BF_Global'
Global precomputed quantity (on 'Global', value depends on
parameters).
'BF_dGlobal'
Exterior derivative of global precomputed quantity (on 'Global',
value depends on parameters).
'BF_NodeX'
Vector ('BF_Node', 0, 0) (on 'NodesOf', value 'Vector').
'BF_NodeY'
Vector (0, 'BF_Node', 0) (on 'NodesOf', value 'Vector').
'BF_NodeZ'
Vector (0, 0, 'BF_Node') (on 'NodesOf', value 'Vector').
'BF_Zero'
Zero value 0 (on all regions, value 'Scalar').
'BF_One'
Unit value 1 (on all regions, value 'Scalar').
GLOBALQUANTITYTYPE:
'AliasOf'
Another name for a name of coefficient of basis function.
'AssociatedWith'
A global quantity associated with a name of coefficient of basis
function, and therefore with this basis function.
6.5 Types for 'Jacobian'
========================
JACOBIANTYPE:
'Vol'
Volume Jacobian, for ND regions in ND geometries, N = 1, 2 or 3.
'Sur'
Surface Jacobian, for (N1)D regions in ND geometries, N = 1, 2
or 3.
'Lin'
Line Jacobian, for (N2)D regions in ND geometries, N = 2 or 3.
'VolAxi'
Axisymmetrical volume Jacobian (1st type: r), for 2D regions in
axisymmetrical geometries.
'SurAxi'
Axisymmetrical surface Jacobian (1st type: r), for 1D regions in
axisymmetrical geometries.
'VolAxiSqu'
Axisymmetrical volume Jacobian (2nd type: r^2), for 2D regions in
axisymmetrical geometries.
'VolSphShell'
Volume Jacobian with spherical shell transformation, for ND
regions in ND geometries, N = 2 or 3.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, CENTERX, CENTERY,
CENTERZ, POWER, 1/INFINITY >.
'VolCylShell'
Volume Jacobian with cylindrical shell transformation, for ND
regions in ND geometries, N = 2 or 3. For N=2, 'VolCylShell' is
identical to 'VolSphShell'. For N=3, the axis of the cylinder is
supposed to be along the Z axis.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, CENTERX, CENTERY,
CENTERZ, POWER, 1/INFINITY >.
'VolAxiSphShell'
Same as 'VolAxi', but with spherical shell transformation.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, CENTERX, CENTERY,
CENTERZ, POWER, 1/INFINITY >.
'VolAxiSquSphShell'
Same as 'VolAxiSqu', but with spherical shell transformation.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, CENTERX, CENTERY,
CENTERZ, POWER, 1/INFINITY >.
'VolRectShell'
Volume Jacobian with rectangular shell transformation, for ND
regions in ND geometries, N = 2 or 3.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, DIRECTION,
CENTERX, CENTERY, CENTERZ, POWER, 1/INFINITY >.
'VolAxiRectShell'
Same as 'VolAxi', but with rectangular shell transformation.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, DIRECTION,
CENTERX, CENTERY, CENTERZ, POWER, 1/INFINITY >.
'VolAxiSquRectShell'
Same as 'VolAxiSqu', but with rectangular shell transformation.
Parameters: RADIUSINTERNAL, RADIUSEXTERNAL <, DIRECTION,
CENTERX, CENTERY, CENTERZ, POWER, 1/INFINITY >.
6.6 Types for 'Integration'
===========================
INTEGRATIONTYPE:
'Gauss'
Numerical Gauss integration.
'GaussLegendre'
Numerical Gauss integration obtained by application of a
multiplicative rule on the onedimensional Gauss integration.
ELEMENTTYPE:
'Line'
Line (2 nodes, 1 edge, 1 volume) (#1).
'Triangle'
Triangle (3 nodes, 3 edges, 1 facet, 1 volume) (#2).
'Quadrangle'
Quadrangle (4 nodes, 4 edges, 1 facet, 1 volume) (#3).
'Tetrahedron'
Tetrahedron (4 nodes, 6 edges, 4 facets, 1 volume) (#4).
'Hexahedron'
Hexahedron (8 nodes, 12 edges, 6 facets, 1 volume) (#5).
'Prism'
Prism (6 nodes, 9 edges, 5 facets, 1 volume) (#6).
'Pyramid'
Pyramid (5 nodes, 8 edges, 5 facets, 1 volume) (#7).
'Point'
Point (1 node) (#15).
Note:
1. N in (#N) is the type number of the element (*note Input file
format::).
6.7 Types for 'Formulation'
===========================
FORMULATIONTYPE:
'FemEquation'
Finite element method formulation (all methods of moments, integral
methods).
LOCALTERMTYPE:
'Integral'
Integral of Galerkin or PetrovGalerkin type.
'deRham'
deRham projection (collocation).
QUANTITYTYPE:
'Local'
Local quantity defining a field in a function space. In case a
subspace is considered, its identifier has to be given between the
brackets following the 'NameOfSpace FUNCTIONSPACEID'.
'Global'
Global quantity defining a global quantity from a function space.
The identifier of this quantity has to be given between the
brackets following the 'NameOfSpace FUNCTIONSPACEID'.
'Integral'
Integral quantity obtained by the integration of a 'LocalQuantity'
before its use in an 'Equation' term.
TERMOPTYPE:
'Dt'
Time derivative applied to the whole term of the equation. (Not
implemented yet.)
'DtDof'
Time derivative applied only to the 'Dof{}' term of the equation.
'DtDt'
Time derivative of 2nd order applied to the whole term of the
equation. (Not implemented yet.)
'DtDtDof'
Time derivative of 2nd order applied only to the 'Dof{}' term of
the equation.
'Eig'
The term is multiplied by (a certain function of) the eigenvalue.
This is to be used with the 'GenerateSeparate' and 'EigenSolve'
'Resolution' operations. An optional 'Order EXPRESSION;' or
'Rational EXPRESSION;' statement can be added in the term to
specify the eigenvalue function. Full documentation of this
feature is not available yet.
'JacNL'
Nonlinear part of the Jacobian matrix (tangent stiffness matrix) to
be assembled for nonlinear analysis.
'DtDofJacNL'
Nonlinear part of the Jacobian matrix for the first order time
derivative (tangent mass matrix) to be assembled for nonlinear
analysis.
'NeverDt'
No time scheme applied to the term (e.g., Theta is always 1 even if
a theta scheme is applied).
6.8 Types for 'Resolution'
==========================
RESOLUTIONOP:
'Generate'
'[SYSTEMID]'
Generate the system of equations SYSTEMID.
'Solve'
'[SYSTEMID]'
Solve the system of equations SYSTEMID.
'SolveAgain'
'[SYSTEMID]'
Save as 'Solve', but reuses the preconditionner when called
multiple times.
'SetGlobalSolverOptions'
'[CHAREXPRESSION]'
Set global PETSc solver options (with the same syntax as PETSc
options specified on the command line, e.g. '"ksp_type gmres
pc_type ilu"').
'GenerateJac'
'[SYSTEMID]'
Generate the system of equations SYSTEMID using a jacobian matrix
(of which the unknowns are corrections DX of the current solution
X).
'SolveJac'
'[SYSTEMID]'
Solve the system of equations SYSTEMID 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'
'[SYSTEMID]'
Generate matrices separately for 'DtDtDof', 'DtDof' and 'NoDt'
terms in SYSTEMID. The separate matrices can be used with the
'Update' operation (for efficient time domain analysis of linear
PDEs with constant coefficients), or with the 'EigenSolve'
operation (for solving generalized eigenvalue problems).
'GenerateOnly'
'[SYSTEMID, EXPRESSIONCSTLIST]'
Not documented yet.
'GenerateOnlyJac'
'[SYSTEMID, EXPRESSIONCSTLIST]'
Not documented yet.
'GenerateGroup'
Not documented yet.
'GenerateRightHandSideGroup'
Not documented yet.
'Update'
'[SYSTEMID]'
Update the system of equations SYSTEMID (built from submatrices
generated separately with 'GenerateSeparate') with the
'TimeFunction'(s) provided in 'Assign' constraints. This assumes
that the problem is linear, that the matrix coefficients are
independent of time, and that all sources are imposed using
'Assign' constraints.
'Update'
'[SYSTEMID, EXPRESSION]'
Update the system of equations SYSTEMID (built from submatrices
generated separately with 'GenerateSeparate') with EXPRESSION.
This assumes that the problem is linear, that the matrix
coefficients are independent of time, and that the righthandside
of the linear system can simply be multiplied by EXPRESSION at each
step.
'UpdateConstraint'
'[SYSTEMID, GROUPID, CONSTRAINTTYPE]'
Recompute the constraint of type CONSTRAINTTYPE acting on GROUPID
during processing.
'GetResidual'
'[SYSTEMID, $VARIABLEID]'
Compute the residual 'r = b  A x' and store its L2 norm in the
runtime variable $VARIABLEID.
'GetNormSolution  GetNormRightHandSide  GetNormResidual  GetNormIncrement'
'[SYSTEMID, $VARIABLEID]'
Compute the norm of the solution (resp. righthandside, residual
or increment) and store its L2 norm in the runtime variable
$VARIABLEID.
'SwapSolutionAndResidual'
'[SYSTEMID]'
Swap the solution 'x' and residual 'r' vectors.
'SwapSolutionAndRightHandSide'
'[SYSTEMID]'
Swap the solution 'x' and righthandside 'b' vectors.
'InitSolution'
'[SYSTEMID]'
Creates a new solution vector, adds it to the solution vector list
for SYSTEMID, and initializes the solution. The values in the
vector are initialized to the values given in a 'Constraint' of
'Init' type (if two values are given in 'Init', the second value is
used). If no constraint is provided, the values are initialized to
zero if the solution vector is the first in the solution list;
otherwise the values are initialized using the previous solution in
the list.
'InitSolution1'
'[SYSTEMID]'
Same as 'InitSolution', but uses the first value given in the
'Init' constraints.
'CreateSolution'
'[SYSTEMID]'
Creates a new solution vector, adds it to the solution vector list
for SYSTEMID, and initializes the solution to zero.
'CreateSolution'
'[SYSTEMID, EXPRESSIONCST]'
Same as 'CreateSolution', but initialize the solution by copying
the EXPRESSIONCSTth solution in the solution list.
'Apply'
'[SYSTEMID]'
'x < Ax'
'SetSolutionAsRightHandSide'
'[SYSTEMID]'
'b < x'
'SetRightHandSideAsSolution'
'[SYSTEMID]'
'x < b'
'Residual'
'[SYSTEMID]'
'res < b  Ax'
'CopySolution'
'[SYSTEMID, CHAREXPRESSION  CONSTANTID() <, SendToServer
CHAREXPRESSION > ]'
Copy the current solution 'x' into a vector named CHAREXPRESSION
or into a list named CONSTANTID. In the latter case, if
'SendToServer' is provided, copy the list to the ONELAB server as
well.
'CopySolution'
'[CHAREXPRESSION  CONSTANTID(), SYSTEMID]'
Copy the vector named CHAREXPRESSION or the list named CONSTANTID
into the current solution 'x'.
'CopyRightHandSide'
'[SYSTEMID, CHAREXPRESSION  CONSTANTID() <, SendToServer
CHAREXPRESSION > ]'
Copy the current righthand side 'b' into a vector named
CHAREXPRESSION or into a list named CONSTANTID. In the latter
case, if 'SendToServer' is provided, copy the list to the ONELAB
server as well.
'CopyRightHandSide'
'[CHAREXPRESSION  CONSTANTID(), SYSTEMID]'
Copy the vector named CHAREXPRESSION or the list named CONSTANTID
into the current righthandside 'b'.
'CopyResidual'
'[SYSTEMID, CHAREXPRESSION  CONSTANTID() <, SendToServer
CHAREXPRESSION > ]'
Copy the current residual into a vector named CHAREXPRESSION or
into a list named CONSTANTID. In the latter case, if
'SendToServer' is provided, copy the list to the ONELAB server as
well.
'CopyResidual'
'[CHAREXPRESSION  CONSTANTID(), SYSTEMID]'
Copy the vector named CHAREXPRESSION or the list named CONSTANTID
into the current residual.
'SaveSolution'
'[SYSTEMID]'
Save the solution of the system of equations SYSTEMID.
'SaveSolutions'
'[SYSTEMID]'
Save all the solutions available for the system of equations
SYSTEMID. This should be used with algorithms that generate more
than one solution at once, e.g., 'EigenSolve' or
'FourierTransform'.
'RemoveLastSolution'
'[SYSTEMID]'
Removes the last solution (i.e. associated with the last time
step) associated with system SYSTEMID.
'TransferSolution'
'[SYSTEMID]'
Transfer the solution of system SYSTEMID, as an 'Assign'
constraint, to the system of equations defined with a
'DestinationSystem' command. This is used with the
'AssignFromResolution' constraint type (*note Types for
Constraint::).
'Evaluate'
'[EXPRESSION <, EXPRESSION>]'
Evaluate the EXPRESSION(s).
'SetTime'
'[EXPRESSION]'
Change the current time.
'SetTimeStep'
'[EXPRESSION]'
Change the current time step number (1, 2, 3, ...)
'SetDTime'
'[EXPRESSION]'
Change the current time step value (dt).
'SetFrequency'
'[SYSTEMID, EXPRESSION]'
Change the frequency of system SYSTEMID.
'SystemCommand'
'[EXPRESSIONCHAR]'
Execute the system command given by EXPRESSIONCHAR.
'Error'
'[EXPRESSIONCHAR]'
Output error message EXPRESSIONCHAR.
'Test'
'[EXPRESSION] { RESOLUTIONOP }'
If EXPRESSION is true (nonzero), perform the operations in
RESOLUTIONOP.
'Test'
'[EXPRESSION] { RESOLUTIONOP } { RESOLUTIONOP }'
If EXPRESSION is true (nonzero), perform the operations in the
first RESOLUTIONOP, else perform the operations in the second
RESOLUTIONOP.
'While'
'[EXPRESSION] { RESOLUTIONOP }'
While EXPRESSION is true (nonzero), perform the operations in
RESOLUTIONOP.
'Break'
'[]'
Aborts an iterative loop, a time loop or a While loop.
'Exit'
'[]'
Exit, brutally.
'Sleep'
'[EXPRESSION]'
Sleeps for EXPRESSION seconds;
'SetExtrapolationOrder'
'[EXPRESSIONCST]'
Chooses the extrapolation order to compute the initialization of
the solution vector in time loops. Default is 0.
'Print'
'[ { EXPRESSIONLIST } <, File EXPRESSIONCHAR > <, Format
EXPRESSIONCHAR > ]'
Print the expressions listed in EXPRESSIONLIST. If 'Format' is
given, use it to format the (scalar) expressions like 'Printf'.
'Print'
'[ SYSTEMID <, File EXPRESSIONCHAR > <, { EXPRESSIONCSTLIST }
>'
'<, TimeStep { EXPRESSIONCSTLIST } >]'
Print the system SYSTEMID. If the EXPRESSIONCSTLIST 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.
'EigenSolve'
'[SYSTEMID, EXPRESSIONCST, EXPRESSIONCST, EXPRESSIONCST < ,
EXPRESSION > ]'
Eigenvalue/eigenvector computation using Arpack or SLEPc. The
parameters are: the system (which has to be generated with
'GenerateSeparate[]'), the number of eigenvalues/eigenvectors to
compute and the real and imaginary spectral shift (around which to
look for eigenvalues). The last optional argument allows to filter
which eigenvalue/eigenvector pairs will be saved. For example,
'($EigenvalueReal > 0)' would only keep pairs corresponding to
eigenvalues with a striclty positive real part.
'Lanczos'
'[SYSTEMID, EXPRESSIONCST, { EXPRESSIONCSTLIST } ,
EXPRESSIONCST]'
Eigenvalue/eigenvector computation using 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 eigenvalues/eigenvectors to store, the spectral shift. This
routine is deprecated: use 'EigenSolve' instead.
'FourierTransform'
'[SYSTEMID, SYSTEMID, { EXPRESSIONCSTLIST }]'
Onthefly (incremental) computation of a 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') and the list of frequencies to
consider. The computation is an approximation that assumes that
the time step is constant; it is not an actual Discrete Fourier
Transform (the number of samples is unknown a priori).
'TimeLoopTheta'
'[EXPRESSIONCST,EXPRESSIONCST,EXPRESSION,EXPRESSIONCST]' '{
RESOLUTIONOP }'
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 CrankNicholson).
Warning: GetDP automatically handles timedependent constraints
when they are provided using the 'TimeFunction' mechanism in an
'Assign'type 'Constraint' (*note Constraint::). However, GetDP
cannot automatically transform general timedependent source terms
in weak formulations (timedependent functions written in a
'Integral' term). Such source terms will be correctly treated only
for implicit Euler, as the expression in the 'Integral' term is
evaluated at the current time step. For other schemes, the source
term should be written explicitly, by splitting it in two ('theta
f_n+1 + (1theta) f_n'), making use of the 'AtAnteriorTimeStep[]'
for the second part, and specifying 'NeverDt' in the 'Integral'
term.
'TimeLoopNewmark'
'[EXPRESSIONCST,EXPRESSIONCST,EXPRESSION,EXPRESSIONCST,EXPRESSIONCST]'
{ RESOLUTIONOP }
Time loop of a Newmark scheme. The parameters are: the initial
time, the end time, the time step, the beta and the gamma
parameter.
Warning: same restrictions apply for timedependent functions in
the weak formulations as for 'TimeLoopTheta'.
'TimeLoopAdaptive'
'[EXPRESSIONCST,EXPRESSIONCST,EXPRESSIONCST,EXPRESSIONCST,
EXPRESSIONCST,INTEGRATIONMETHOD,,
System { {SYSTEMID,EXPRESSIONCST,EXPRESSIONCST,NORMTYPE} ... }

PostOperation {
{POSTOPERATIONID,EXPRESSIONCST,EXPRESSIONCST,NORMTYPE} ... }
]'
'{ RESOLUTIONOP }'
'{ RESOLUTIONOP }'
Time loop with variable time steps. The step size is adjusted
according the local truncation error (LTE) of the specified
Systems/PostOperations via a predictorcorrector method.
The parameters are: start time, end time, initial time step, min.
time step, max. time step, integration method, list of breakpoints
(time points to be hit). The LTE calculation can be based on all
DOFs of a system and/or on a PostOperation result. The parameters
here are: System/PostOperation for LTE assessment, relative LTE
tolerance, absolute LTE tolerance, normtype for LTE calculation.
Possible choices for INTEGRATIONMETHOD are: 'Euler, Trapezoidal,
Gear_2, Gear_3, Gear_4, Gear_5, Gear_6'. The Gear methods
correspond to backward differentiation formulas of order 2..6.
Possible choices for NORMTYPE: 'L1Norm, MeanL1Norm, L2Norm,
MeanL2Norm, LinfNorm'.
'MeanL1Norm' and 'MeanL2Norm' correspond to 'L1Norm' and 'L2Norm'
divided by the number of degrees of freedom, respectively.
The first RESOLUTIONOP is executed every time step. The second
one is only executed if the actual time step is accepted (LTE is in
the specified range). E.g. 'SaveSolution[]' is usually placed in
the 2nd RESOLUTIONOP.
'IterativeLoop'
'[EXPRESSIONCST,EXPRESSION,EXPRESSIONCST<,EXPRESSIONCST>]' {
RESOLUTIONOP }
Iterative loop for nonlinear analysis. The parameters are: the
maximum number of iterations (if no convergence), the relative
error to achieve and the relaxation factor (multiplies the
iterative correction DX). The optional parameter is a flag for
testing purposes.
'IterativeLoopN'
'[EXPRESSIONCST,EXPRESSION,
System { {SYSTEMID,EXPRESSIONCST,EXPRESSIONCST, ASSESSEDOBJECT
NORMTYPE} ... } 
PostOperation { {POSTOPERATIONID,EXPRESSIONCST,EXPRESSIONCST,
NORMTYPE} ... } ]'
{ RESOLUTIONOP }
Similar to 'IterativeLoop[]' but allows to specify in detail the
tolerances and the type of norm to be calculated for convergence
assessment.
The parameters are: the maximum number of iterations (if no
convergence), the relaxation factor (multiplies the iterative
correction DX). The convergence assessment can be based on all
DOFs of a system and/or on a PostOperation result. The parameters
here are: System/PostOperation for convergence assessment, relative
tolerance, absolute tolerance, assessed object (only applicable for
a specified system), normtype for error calculation.
Possible choices for ASSESSEDOBJECT: 'Solution, Residual,
RecalcResidual'. 'Residual' assesses the residual from the last
iteration whereas 'RecalcResidual' calculates the residual once
again after each iteration. This means that with 'Residual'
usually one extra iteration is performed, but 'RecalcResidual'
causes higher computational effort per iteration. Assessing the
residual can only be used for Newton's method.
Possible choices for NORMTYPE: 'L1Norm, MeanL1Norm, L2Norm,
MeanL2Norm, LinfNorm'.
'MeanL1Norm' and 'MeanL2Norm' correspond to 'L1Norm' and 'L2Norm'
divided by the number of degrees of freedom, respectively.
'IterativeLinearSolver'
Generic iterative linear solver. To be documented.
'PostOperation'
'[POSTOPERATIONID]'
Perform the specified 'PostOperation'.
'GmshRead'
'[EXPRESSIONCHAR]'
When GetDP is linked with the Gmsh library, read a file using Gmsh.
This file can be in any format recognized by Gmsh. If the file
contains one or multiple postprocessing fields, these fields will
be evaluated using the builtin 'Field[]', 'ScalarField[]',
'VectorField[]', etc., functions (*note Miscellaneous functions::).
(Note that 'GmshOpen' and 'GmshMerge' can be used instead of
'GmshRead' to force Gmsh to do classical "open" and "merge"
operations, instead of trying to "be intelligent" when reading
postprocessing datasets, i.e., creating new models on the fly if
necessary.)
'GmshRead'
'[EXPRESSIONCHAR, EXPRESSIONCST]'
Same thing as the 'GmshRead' command above, except that the field
is forced to be stored with the given tag. The tag can be used to
retrieve the given field with the builtin 'Field[]',
'ScalarField[]', 'VectorField[]', etc., functions (*note
Miscellaneous functions::).
'GmshRead'
'[EXPRESSIONCHAR, $STRING]'
Same as the 'GmshRead', but evaluates EXPRESSIONCHAR by replacing
a double precision format specifier with the value of the runtime
variable '$'STRING.
'GmshWrite'
'[EXPRESSIONCHAR, EXPRESSIONCST]'
Writes the a Gmsh field to disk. (The format is guessed from the
file extension.)
'GmshClearAll'
'[]'
Clears all Gmsh data (loaded with 'GmshRead' and friends).
'ReadTable'
'[EXPRESSIONCHAR, EXPRESSIONCHAR]'
Reads tabular data in the same format as 'ListFromFile', and stores
in the runtime table named after the second EXPRESSIONCHAR.
'DeleteFile'
'[EXPRESSIONCHAR]'
Delete a file.
'RenameFile'
'[EXPRESSIONCHAR, EXPRESSIONCHAR]'
Rename a file.
'CreateDir  CreateDirectory'
'[EXPRESSIONCHAR]'
Create a directory.
'MPI_SetCommSelf'
'[]'
Changes MPI communicator to self.
'MPI_SetCommWorld'
'[]'
Changes MPI communicator to world.
'MPI_Barrier'
'[]'
MPI barrier (blocks until all processes have reached this call).
'MPI_BroadcastFields'
'[ < EXPRESSIONLIST > ]'
Broadcast all fields over MPI (except those listed in the list).
'MPI_BroadcastVariables'
'[]'
Broadcast all runtime variables over MPI.
6.9 Types for 'PostProcessing'
==============================
POSTVALUE:
'Local'
{ LOCALVALUE }
To compute a local quantity.
'Integral'
{ INTEGRALVALUE }
To integrate the expression over each element.
6.10 Types for 'PostOperation'
==============================
PRINTSUPPORT:
'OnElementsOf'
GROUPDEF
To compute a quantity on the elements belonging to the region
GROUPDEF, where the solution was computed during the processing
stage.
'OnRegion'
GROUPDEF
To compute a global quantity associated with the region GROUPDEF.
'OnGlobal'
To compute a global integral quantity, with no associated region.
'OnSection'
{ { EXPRESSIONCSTLIST } { EXPRESSIONCSTLIST } {
EXPRESSIONCSTLIST } }
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 EXPRESSIONCSTLIST must
contain exactly three elements (the coordinates of the points).
'OnGrid'
GROUPDEF
To compute a quantity in elements of a mesh which differs from the
real support of the solution. 'OnGrid GROUPDEF' differs from
'OnElementsOf GROUPDEF' by the reinterpolation that must be
performed.
'OnGrid'
'{ EXPRESSION, EXPRESSION, EXPRESSION }'
'{ EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST } ,'
' EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST } ,'
' EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST } }'
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
EXPRESSIONCSTLISTITEM or EXPRESSIONCSTLIST. 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'
{ EXPRESSIONCSTLIST }
To compute a quantity at a point. The EXPRESSIONCSTLIST must
contain exactly three elements (the coordinates of the point).
'OnLine'
{ { EXPRESSIONCSTLIST } { EXPRESSIONCSTLIST } } {
EXPRESSIONCST }
To compute a quantity along a line (given by its two end points),
with an associated number of divisions equal to EXPRESSIONCST.
The interpolation points on the line are equidistant. Each
EXPRESSIONCSTLIST must contain exactly three elements (the
coordinates of the points).
'OnPlane'
{ { EXPRESSIONCSTLIST } { EXPRESSIONCSTLIST } {
EXPRESSIONCSTLIST } }
'{ EXPRESSIONCST, EXPRESSIONCST }'
To compute a quantity on a plane (specified by three points: the
origin and the end of the unit vectors), with an associated number
of divisions equal to each EXPRESSIONCST along both generating
directions. Each EXPRESSIONCSTLIST must contain exactly three
elements (the coordinates of the points).
'OnBox'
{ { EXPRESSIONCSTLIST } { EXPRESSIONCSTLIST } {
EXPRESSIONCSTLIST }
' { EXPRESSIONCSTLIST } } { EXPRESSIONCST, EXPRESSIONCST,
EXPRESSIONCST }'
To compute a quantity in a box (specified by four points), with an
associated number of divisions equal to each EXPRESSIONCST along
the three generating directions. Each EXPRESSIONCSTLIST must
contain exactly three elements (the coordinates of the points).
PRINTOPTION:
'File'
'EXPRESSIONCHAR'
Outputs the result in a file named EXPRESSIONCHAR.
'File'
'> EXPRESSIONCHAR'
Same as 'File EXPRESSIONCHAR', except that, if several 'File >
EXPRESSIONCHAR' options appear in the same 'PostOperation', the
results are concatenated in the file EXPRESSIONCHAR.
'File'
'>> EXPRESSIONCHAR'
Appends the result to a file named EXPRESSIONCHAR.
'AppendToExistingFile'
EXPRESSIONCST
Appends the result to the file specified with 'File'. (Same
behavior as '>' if EXPRESSIONCST = 1; same behavior as '>>' if
EXPRESSIONCST = 2.)
'Name  Label'
'EXPRESSIONCHAR'
For formats that support it, sets the label of the output field to
EXPRESSIONCHAR (also used with with 'SendToServer' to force the
label).
'Depth'
EXPRESSIONCST
Recursive division of the elements if EXPRESSIONCST is greater
than zero, derefinement if EXPRESSIONCST is smaller than zero. If
EXPRESSIONCST is equal to zero, evaluation at the barycenter of
the elements.
'AtGaussPoints'
EXPRESSIONCST
Print result at the specified number of Gauss points.
'Skin'
Computes the result on the boundary of the region.
'Smoothing'
< EXPRESSIONCST >
Smoothes the solution at the nodes.
'HarmonicToTime'
EXPRESSIONCST
Converts a harmonic solution into a timedependent one (with
EXPRESSIONCST steps).
'Dimension'
EXPRESSIONCST
Forces the dimension of the elements to consider in an element
search. Specifies the problem dimension during an adaptation (h
or prefinement).
'TimeStep'
'EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST }'
Outputs results for the specified time steps only.
'TimeValue'
'EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST }'
Outputs results for the specified time value(s) only.
'TimeImagValue'
'EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST }'
Outputs results for the specified imaginary time value(s) only.
'LastTimeStepOnly'
Outputs results for the last time step only (useful when calling a
'PostOperation' directly in a 'Resolution', for example).
'AppendExpressionToFileName'
EXPRESSION
Evaluate the given EXPRESSION at runtime and append it to the
filename.
'AppendExpressionFormat'
EXPRESSIONCHAR
Cstyle format string for printing the EXPRESSION provided in
'AppendExpressionToFileName'. Default is '"%.16g"'.
'AppendTimeStepToFileName'
< EXPRESSIONCST >
Appends the time step to the output file; only makes sense with
'LastTimeStepOnly'.
'AppendStringToFileName'
EXPRESSIONCHAR
Append the given EXPRESSIONCHAR to the filename.
'OverrideTimeStepValue'
EXPRESSIONCST
Overrides the value of the current time step with the given value.
'NoMesh'
< EXPRESSIONCST >
Prevents the mesh from being written in the output file (useful
with new meshbased solution formats).
'SendToServer'
EXPRESSIONCHAR
Send the value to the Onelab server, using EXPRESSIONCHAR as the
parameter name.
'SendToServer'
EXPRESSIONCHAR { EXPRESSIONCSTLIST }
Send the requested harmonics of the value to the Onelab server,
using EXPRESSIONCHAR as the parameter name.
'Color'
EXPRESSIONCHAR
Used with 'SendToServer', sets the color of the parameter in the
Onelab server.
'Hidden'
< EXPRESSIONCST >
Used with 'SendToServer', selects the visibility of the exchanged
value.
'Closed'
EXPRESSIONCHAR
Used with 'SendToServer', closes (or opens) the subtree containing
the parameter.
'Units'
EXPRESSIONCHAR
Used with 'SendToServer', sets the units of the parameter in the
Onelab server.
'Frequency'
'EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST }'
Outputs results for the specified frequencies only.
'Format'
POSTOPERATIONFMT
Outputs results in the specified format.
'Adapt'
'P1  H1  H2'
Performs p or hrefinement on the postprocessing result,
considered as an error map.
'Target'
EXPRESSIONCST
Specifies the target for the optimizer during adaptation (error for
'P1H1', number of elements for 'H2').
'Value'
'EXPRESSIONCSTLISTITEM  { EXPRESSIONCSTLIST }'
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'
EXPRESSIONCST
Outputs directly contour prints (with EXPRESSIONCST values)
instead of elementary values.
'Iso'
'{ EXPRESSIONCSTLIST }'
Outputs directly contour prints for the values specified in the
EXPRESSIONCSTLIST instead of elementary values.
'NoNewLine'
Suppresses the new lines in the output when printing global
quantities (i.e., with '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'
'{ EXPRESSIONLIST }'
Changes the values of the results according to the expressions
given in argument. The EXPRESSIONs represent the new values
(Xcompoment, Ycomponent, etc.), and can be functions of the
current values of the solution ($VAL0, $VAL1, etc.).
'DecomposeInSimplex'
Decomposes all output elements in simplices (points, lines,
triangles or tetrahedra).
'StoreInVariable'
'$EXPRESSIONCHAR'
Stores the result of a pointwise evaluation or an 'OnRegion'
postprocessing operation in the runtime variable
$code[$]EXPRESSIONCHAR.
'StoreInRegister'
'EXPRESSIONCST'
Stores the result of pointwise evaluation or an 'OnRegion'
postprocessing operation in the register EXPRESSIONCST.
'StoreMinInRegister'
'StoreMaxInRegister'
'EXPRESSIONCST'
Stores the minimum or maximum value of an 'OnElementsOf'
postprocessing operation in the register EXPRESSIONCST.
'StoreMinXinRegister'
'StoreMinYinRegister'
'StoreMinZinRegister'
'StoreMaxXinRegister'
'StoreMaxYinRegister'
'StoreMaxZinRegister'
'EXPRESSIONCST'
Stores the X, Y or Z coordinate of the location, where the minimum
or maximum of an 'OnElementsOf' postprocessing operation occurs,
in the register EXPRESSIONCST.
'StoreInField'
'EXPRESSIONCST'
Stores the result of a postprocessing operation in the field (Gmsh
listbased postprocessing view) with tag EXPRESSIONCST.
'StoreInMeshBasedField'
'EXPRESSIONCST'
Stores the result of a postprocessing operation in the meshbased
field (Gmsh meshbased postprocessing view) with tag
EXPRESSIONCST.
'TimeLegend'
'< { EXPRESSION, EXPRESSION, EXPRESSION } >'
Includes a time legend in Gmsh plots. If the three optional
expressions giving the position of the legend are not specified,
the legend is centered on top of the plot.
'FrequencyLegend'
'< { EXPRESSION, EXPRESSION, EXPRESSION } >'
Includes a frequency legend in Gmsh plots. If the three optional
expressions giving the position of the legend are not specified,
the legend is centered on top of the plot.
'EigenvalueLegend'
'< { EXPRESSION, EXPRESSION, EXPRESSION } >'
Includes an eigenvalue legend in Gmsh plots. If the three optional
expressions giving the position of the legend are not specified,
the legend is centered on top of the plot.
POSTOPERATIONFMT:
'Gmsh'
'GmshParsed'
Gmsh output. See *note Input file format:: and the documentation
of Gmsh () for a description of the file formats.
'Table'
Space oriented column output, e.g., suitable for Gnuplot, Excel,
Caleida Graph, etc. The columns are: ELEMENTTYPE ELEMENTINDEX
XCOORD YCOORD ZCOORD ... REAL REAL
REAL VALUES. The three REAL numbers preceding the VALUES contain
contextdependent 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.
'SimpleTable'
Like 'Table', but with only the XCOORD YCOORD ZCOORD and VALUES
columns.
'TimeTable'
Time oriented column output, e.g., suitable for Gnuplot, Excel,
Caleida Graph, etc. The columns are: TIMESTEP TIME XCOORD
YCOORD ZCOORD ... VALUE.
'NodeTable'
Table of nodal values, in the form NODENUMBER NODEVALUE(s). When
exported to a file, the total number of nodal values is printed
first. The data is automatically exported as a runtime accessible
list as well as a ONELAB variable, with the name of the
'PostOperation' quantity. The values are also directly usable by
the 'ValueFromTable' function, which allows to use them as values
in a nodal 'Constraint'.
'ElementTable'
Table of element values, in the form ELEMENTNUMBER
ELEMENTNODEVALUE(s). When exported to a file, the total number
of element values is printed first. The data is automatically
exported as a runtime accessible list as well as a ONELAB
variable, with the name of the 'PostOperation' quantity. The
values are also directly usable by the 'ValueFromTable' function,
which allows to use them as values in an elementwise 'Constraint'.
'Gnuplot'
Space oriented column output similar to the '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 threedimensional elevation plots in Gnuplot. The columns
are: ELEMENTTYPE ELEMENTINDEX XCOORD YCOORD ZCOORD REAL REAL
REAL VALUES. The three REAL numbers preceding the VALUES contain
contextdependent 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'
Adaptation map, suitable for the GetDP 'adapt' command line
option.
7 Short examples
****************
7.1 Constant expression examples
================================
The simplest constant expression consists of an INTEGER or a REAL number
as in
21
3
or
3.1415
27e3
290.53e12
Using operators and the classic math functions, CONSTANTIDs can be
defined:
c1 = Sin[2/3*3.1415] * 5000^2;
c2 = 1/c1;
7.2 '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'.
7.3 '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.e7*Pi;
mu[Core] = 1000.*4.e7*Pi;
}
A nonlinear characteristic can be defined through an EXPRESSION with
arguments, e.g.,
Function {
mu0 = 4.e7*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 (*note
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 onedimensional 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 builtin
function 'InterpolationLinear' (*note Constants::, as well as *note
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 (*note 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 (*note Runtime variables and 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.
The same results can be obtained using a runtime variable '$v':
g[] = ($v = f[$1]) * Sin[$v^2];
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[] = 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.
7.4 'Constraint' examples
=========================
Constraints are referred to in 'FunctionSpace's 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 'Value's are associated with 'Region's (with their nodes,
their edges, their global regions, ...) is defined in the
'FunctionSpace's 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. *note 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 preprocessing.
Other constraints can be referred to in 'Formulation's. 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 nonconnected 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'.
7.5 'FunctionSpace' examples
============================
Various discrete function spaces can be defined in the frame of the
finite element method.
7.5.1 Nodal finite element spaces

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 0forms, 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 builtin basis function BF_Node associated with all
nodes ('NodesOf') in the mesh of W ('Domain'). Previously defined
'Constraint DirichletBoundaryCondition1' (*note 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.
7.5.2 High order nodal finite element space

Higher order finite elements can be directly taken into account by
'BF_Node'. Hierarchical finite elements for 0forms 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]; }
}
...
7.5.3 Nodal finite element space with floating potentials

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'.
7.5.4 Edge finite element space

Another space is the edge finite element space, denoted S1(W),
containing 1forms, i.e., curlconform 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 { ... }
}
}
7.5.5 Edge finite element space with gauge condition

A 1form 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; }
...
}
}
}
7.5.6 Coupled edge and nodal finite element spaces

A 1form 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.
7.5.7 Coupled edge and nodal finite element spaces for multiply connected domains

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.
7.6 'Jacobian' examples
=======================
A simple Jacobian method is for volume transformations (of ND regions
in ND 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; }
}
}
}
7.7 '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.
7.8 'Formulation' examples
==========================
7.8.1 Electrostatic scalar potential formulation

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 {
Integral { [ epsr[] * Dof{Grad v} , {Grad v} ];
In Domain; Jacobian Vol; Integration Int_1; }
}
}
}
The density of the 'Integral' 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.
7.8.2 Electrostatic scalar potential formulation with floating potentials and electric charges

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 {
Integral { [ 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.854187818e12; }'.
7.8.3 Magnetostatic 3D vector potential formulation

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 {
Integral { [ nu[] * Dof{Curl a} , {Curl a} ];
In Domain; Jacobian Vol; Integration Int_1; }
Integral { [  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).
7.8.4 Magnetodynamic 3D or 2D magnetic field and magnetic scalar potential formulation

A magnetodynamic 3D or 2D HPHI 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 {
Integral { Dt [ mu[] * Dof{h} , {h} ];
In Domain; Jacobian Vol; Integration Int_1; }
Integral { [ rho[] * Dof{Curl h} , {Curl h} ];
In DomainC; Jacobian Vol; Integration Int_1; }
}
}
}
7.8.5 Nonlinearities, Mixed formulations, ...

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.
7.9 'Resolution' examples
=========================
7.9.1 Static resolution (electrostatic problem)

A static resolution, e.g., for the electrostatic formulation (*note
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').
7.9.2 Frequency domain resolution (magnetodynamic problem)

A frequency domain resolution, e.g., for the magnetodynamic HPHI
formulation (*note 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.;
}
7.9.3 Time domain resolution (magnetodynamic problem)

A time domain resolution, e.g., for the same magnetodynamic HPHI
formulation (*note 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.e3;
Mag_Time0 = 0.; Mag_TimeMax = 2.*Tc; Mag_DTime[] = Tc/20.;
Mag_Theta[] = 1./2.;
}
the performed time domain analysis will be a CrankNicolson scheme
(thetascheme with 'Theta = 0.5') with initial time 0 ms, end time 20 ms
and time step 1 ms.
7.9.4 Nonlinear time domain resolution (magnetodynamic problem)

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.e4; NL_Relax = 1.; NL_NbrMax = 80;
}
7.9.5 Coupled formulations

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.
7.10 'PostProcessing' examples
==============================
The quantities to be postcomputed based on a solution of a resolution
are defined, e.g., for the electrostatic problem (*note Formulation
examples::; *note 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 postquantities based on global
quantities.
7.11 'PostOperation' examples
=============================
The simplest postprocessing 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 *note 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 *note 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 ];
}
}
}
8 Complete examples
*******************
This chapter presents complete examples that can be run "as is" with
GetDP (*note Running GetDP::).
Many other readytouse examples are available on the website of the
ONELAB project: .
8.1 Electrostatic problem
=========================
Let us first consider a simple electrostatic problem. 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'), whose geometry is
defined in the file 'mStrip.geo' (*note Gmsh examples::). The geometry
is twodimensional and by symmetry only one half of the structure is
modeled.
SurfInf
/ /
++ /
  /
 Air /
 
 Line 
 / / /  2D elements in:
+/+ /  Air, Diel1
/  
+++ 1D elements in:
 Diel1  Line, Ground, SurfInf
 
++
\
Ground
Note that the structure of the following files points out the separation
of the data describing the particular problem and the method used to
solve it (*note Numerical tools as objects::), and therefore how it is
possible to build black boxes adapted to well defined categories of
problems. The files are commented (*note 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 postresults:
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.e3; }
}
}
}
/* 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.e7;
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.e3,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.854187818e12;
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 ; } }
}
}
}
}
8.2 Magnetostatic problem
=========================
We now consider a magnetostatic problem. The formulation used is a 2D
magnetic vector potential formulation (see file 'MagSta_a_2D.pro'). It
is applied to a coreinductor system (file 'CoreSta.pro'), whose
geometry is defined in theh file 'Core.geo' (*note Gmsh examples::).
The geometry is twodimensional and, by symmetry, one fourth of the
structure is modeled.
SurfaceGInf
______ /
 ____/
 \___
____ AirInf \__
S  _ \
u  \ \
r  Air \ \
f  \ \
a  \ 
c   
e ++  
G    
e  Core  ++  
0   Ind  
     
++++++
\
SurfaceGh0
2D elements in: Air, AirInf, Core, Ind
1D elements in: SurfaceGh0, SurfaceGe0, SurfaceGInf
(AirInf is a spherical shell corresponding to an infinite region)
The jacobian and integration methods used are the same as for the
electrostatic problem presented in *note Electrostatic problem::.
/* 
File "CoreSta.pro"
This file defines the problem dependent data structures for the
static coreinductor problem.
To compute the solution:
getdp CoreSta msh Core.msh solve MagSta_a_2D
To compute postresults:
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.e3;
Val_Rext = 250.e3;
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.e7 * Pi;
murCore = 100.;
nu [ Region[{Air, Ind, AirInf}] ] = 1. / mu0;
nu [ Core ] = 1. / (murCore * mu0);
Sc[ Ind ] = 2.5e2 * 5.e2;
}
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.e5;
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; }
}
}
}
}
}
8.3 Magnetodynamic problem
==========================
As a third example we consider a magnetodynamic problem. The
formulation is a twodimensional av formulation (see file
'MagDyn_av_2D.pro', which includes the same jacobian and integration
library files as in *note Electrostatic problem::). It is applied to a
coreinductor system (defined in file 'CoreMassive.pro'), whose geometry
has already been defined in file 'Core.geo'.
/* 
File "CoreMassive.pro"
This file defines the problem dependent data structures for the
dynamic coreinductor problem.
To compute the solution:
getdp CoreMassive msh Core.msh solve MagDyn_av_2D
To compute postresults:
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.e3;
Val_Rext = 250.e3;
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.e7 * 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 av 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; } } }
}
}
}
Appendix A File formats
***********************
This chapter describes the file formats that cannot be modified by the
user. The format of the problem definition structure is explained in
*note Objects::, and *note Types for objects::. The format of the
postprocessing files is explained in *note Types for PostOperation::.
A.1 Input file format
=====================
The native mesh format read by GetDP is the mesh file format produced by
Gmsh (). In its "version 1" incarnation, an 'msh'
file is divided into two sections, defining the nodes and the elements
in the mesh.
$NOD
NUMBEROFNODES
NODENUMBER XCOORD YCOORD ZCOORD
...
$ENDNOD
$ELM
NUMBEROFELEMENTS
ELMNUMBER ELMTYPE ELMREGION UNUSED NUMBEROFNODES NODENUMBERS
...
$ENDELM
All the syntactic variables stand for integers except XCOORD, YCOORD
and ZCOORD which stand for floating point values. The ELMTYPE value
defines the geometrical type for the element:
ELMTYPE:
'1'
Line (2 nodes, 1 edge).
'2'
Triangle (3 nodes, 3 edges).
'3'
Quadrangle (4 nodes, 4 edges).
'4'
Tetrahedron (4 nodes, 6 edges, 4 facets).
'5'
Hexahedron (8 nodes, 12 edges, 6 facets).
'6'
Prism (6 nodes, 9 edges, 5 facets).
'7'
Pyramid (5 nodes, 8 edges, 5 facets).
'15'
Point (1 node).
GetDP can also read more recent versions of the 'msh' format (2.0 and
above), as well as binary meshes. See the Gmsh documentation for more
information about these formats.
A.2 Output file format
======================
A.2.1 File '.pre'

The '.pre' file is generated by the preprocessing 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 /* 'RESOLUTIONID' */
MAINRESOLUTIONNUMBER NUMBEROFDOFDATA
$EndResolution
$DofData /* #DOFDATANUMBER */
RESOLUTIONNUMBER SYSTEMNUMBER
NUMBEROFFUNCTIONSPACES FUNCTIONSPACENUMBER ...
NUMBEROFTIMEFUNCTIONS TIMEFUNCTIONNUMBER ...
NUMBEROFPARTITIONS PARTITIONINDEX ...
NUMBEROFANYDOF NUMBEROFDOF
DOFBASISFUNCTIONNUMBER DOFENTITY DOFHARMONIC DOFTYPE DOFDATA
...
$EndDofData
...
with
DOFDATA:
EQUATIONNUMBER NNZ
(DOFTYPE: 1; UNKNOWN) 
DOFVALUE DOFTIMEFUNCTIONNUMBER
(DOFTYPE: 2; FIXED VALUE) 
DOFASSOCIATEDOFNUMBER DOFVALUE DOFTIMEFUNCTIONNUMBER
(DOFTYPE: 3; ASSOCIATED DEGREE OF FREEDOM) 
EQUATIONNUMBER DOFVALUE
(DOFTYPE: 5; INITIAL VALUE FOR AN UNKNOWN)
Notes:
1. There is one '$DofData' field for each system of equations
considered in the resolution (including those considered in
preresolutions).
2. The DOFDATANUMBER of a '$DofData' field is determined by the order
of this field in the '.pre' file.
3. NUMBEROFDOF is the dimension of the considered system of
equations, while NUMBEROFANYDOF is the total number of degrees
of freedom before the application of constraints.
4. Each degree of freedom is coded with three integer values, which
are the associated basis function, entity and harmonic numbers,
i.e., DOFBASISFUNCTIONNUMBER, DOFENTITY and DOFHARMONIC.
5. NNZ is not used at the moment.
A.2.2 File '.res'

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 vGETDPVERSIONNUMBER, STRINGFORFORMAT */
1.1 FILERESFORMAT
$EndResFormat
$Solution /* DofData #DOFDATANUMBER */
DOFDATANUMBER TIMEVALUE TIMEIMAGVALUE TIMESTEPNUMBER
SOLUTIONVALUE
...
$EndSolution
...
Notes:
1. A '$Solution' field contains the solution associated with a
'$DofData' field.
2. There is one '$Solution' field for each time step, of which the
time is TIMEVALUE (0 for non time dependent or non modal analyses)
and the imaginary time is TIMEIMAGVALUE (0 for non time dependent
or non modal analyses).
3. The order of the SOLUTIONVALUEs in a '$Solution' field follows the
numbering of the equations given in the '.pre' file (one floating
point value for each degree of freedom).
Appendix B Gmsh examples
************************
Gmsh is a threedimensional finite element mesh generator with simple
CAD and postprocessing capabilities that can be used as a graphical
frontend for GetDP. Gmsh can be downloaded from .
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 *note 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.e3 ; w = 4.72e3 ; t = 0.035e3 ;
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.e3; dyCore = 100.e3;
xInd = 75.e3; dxInd = 25.e3; dyInd = 50.e3;
rInt = 200.e3; rExt = 250.e3;
s = 1.;
p0 = 12.e3 *s;
pCorex = 4.e3 *s; pCorey0 = 8.e3 *s; pCorey = 4.e3 *s;
pIndx = 5.e3 *s; pIndy = 5.e3 *s;
pInt = 12.5e3*s; pExt = 12.5e3*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 */
Appendix C Compiling the source code
************************************
Stable releases and source snapshots are available from
. You can also access the Git repository
directly:
1. The first time you want to download the latest full source, type:
git clone
2. To update your local version to the latest and greatest, go in the
getdp directory and type:
git pull
Once you have the source code, you need to run CMake to configure your
build (see the README.txt
(http://gitlab.onelab.info/getdp/getdp/tree/master/README.txt) file in
the toplevel source directory for detailed information on how to run
CMake).
Each build can be configured using a series of options, to selectively
enable optional modules or features. Here is the list of CMake options:
'ENABLE_ARPACK'
Enable Arpack eigensolver (requires Fortran) (default: ON)
'ENABLE_BLAS_LAPACK'
Enable BLAS/Lapack for linear algebra (e.g. for Arpack) (default:
ON)
'ENABLE_BUILD_LIB'
Enable 'lib' target for building static GetDP library (default:
OFF)
'ENABLE_BUILD_SHARED'
Enable 'shared' target for building shared GetDP library (default:
OFF)
'ENABLE_BUILD_DYNAMIC'
Enable dynamic GetDP executable (linked with shared lib) (default:
OFF)
'ENABLE_BUILD_ANDROID'
Enable Android NDK library target (experimental) (default: OFF)
'ENABLE_BUILD_IOS'
Enable iOS (ARM) library target (experimental) (default: OFF)
'ENABLE_FORTRAN'
Enable Fortran (needed for Arpack/Sparskit/Zitsol & Bessel)
(default: ON)
'ENABLE_GMSH'
Enable Gmsh functions (for field interpolation) (default: ON)
'ENABLE_GSL'
Enable GSL functions (for some builtin functions) (default: ON)
'ENABLE_KERNEL'
Enable kernel (required for actual computations) (default: ON)
'ENABLE_MMA'
Enable MMA optimizer (default: ON)
'ENABLE_MPI'
Enable MPI parallelization (with PETSc/SLEPc) (default: OFF)
'ENABLE_MULTIHARMONIC'
Enable multiharmonic support (default: OFF)
'ENABLE_NR'
Enable NR functions (if GSL is unavailable) (default: ON)
'ENABLE_NX'
Enable proprietary NX extension (default: OFF)
'ENABLE_OCTAVE'
Enable Octave functions (default: OFF)
'ENABLE_OPENMP'
Enable OpenMP parallelization of some functions (experimental)
(default: OFF)
'ENABLE_PETSC'
Enable PETSc linear solver (default: ON)
'ENABLE_PRIVATE_API'
Enable private API (default: OFF)
'ENABLE_PYTHON'
Enable Python functions (default: ON)
'ENABLE_SLEPC'
Enable SLEPc eigensolver (default: ON)
'ENABLE_SMALLFEM'
Enable experimental SmallFem assembler (default: OFF)
'ENABLE_SPARSKIT'
Enable Sparskit solver instead of PETSc (requires Fortran)
(default: ON)
'ENABLE_SYSTEM_CONTRIB'
Use system versions of contrib libraries, when possible (default:
OFF)
'ENABLE_PEWE'
Enable PeWe exact solutions (requires Fortran) (default: ON)
'ENABLE_WRAP_PYTHON'
Build Python wrappers (default: OFF)
'ENABLE_ZITSOL'
Enable Zitsol solvers (requires PETSc and Fortran) (default: OFF)
Appendix D Frequently asked questions
*************************************
D.1 The basics
==============
1. What is GetDP?
GetDP is a scientific software environment for the numerical
solution of integrodifferential 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.
2. What are the terms and conditions of use?
GetDP is distributed under the terms of the GNU General Public
License. See *note License:: for more information.
3. What does 'GetDP' mean?
It's an acronym for a "General environment for the treatment of
Discrete Problems".
4. Where can I find more information?
is the primary location to obtain information
about GetDP. There you will for example find the complete reference
manual and the bug tracking database
(https://gitlab.onelab.info/getdp/getdp/issues).
D.2 Installation
================
1. Which OSes does GetDP run on?
Gmsh runs on Windows, MacOS X, Linux and most Unix variants.
2. What do I need to compile GetDP from the sources?
You need a C++ and a Fortran compiler as well as the GSL (version
1.2 or higher; freely available from
).
3. How do I compile GetDP?
You need cmake () and a C++ compiler (and a
Fortran compiler depending on the modules/solvers you want to
compile). See *note Compiling the source code:: and the README.txt
(http://gitlab.onelab.info/getdp/getdp/tree/master/README.txt) file
in the toplevel source directory for more information.
4. GetDP [from a binary distribution] complains about missing
libraries.
Try 'ldd getdp' (or 'otool L getdp' on MacOS 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.
D.3 Usage
=========
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 . This format being
very simple (see the Gmsh reference manual for more details), it
should be straightforward to write a converter from your mesh
format to the 'msh' format.
2. How can I visualize the results produced by GetDP?
You can specify a format in all postprocessing operations.
Available formats include 'Table', 'SimpleTable', 'TimeTable' and
'Gmsh'. 'Table', 'SimpleTable' and 'TimeTable' output lists of
numbers easily readable by Excel/gnuplot/Caleida Graph/etc. 'Gmsh'
outputs postprocessing views directly loadable by Gmsh.
3. How do I change the linear solver used by GetDP?
It depends on which linear solver toolkit was enabled when GetDP
was compiled (PETSc or Sparskit).
With PETScbased linear solvers you can either specify options on
the command line (e.g. with 'ksp_type gmres pc_type ilu'),
through a specific option file (with 'solver file'), through the
'.petscrc' file located in your home directly, or directly in the
'Resolution' field using the 'SetGlobalSolverOptions[]' command.
With Sparskitbased linear solvers can either specify options
directly on command line (e.g. with 'Nb_Fill 200'), specify an
option file explicitly (with 'solver file'), or edit the
'solver.par' file in the current working directory. If no
'solver.par' file exists in the current directory, GetDP will give
create it the next time you perform a linear system solution.
Appendix E Tips and tricks
**************************
* Install the 'info' version of this user's guide! On your (Unix)
system, this can be achieved by 1) copying all getdp.info* files to
the place where your info files live (usually /usr/info), and 2)
issuing the command 'installinfo /usr/info/getdp.info
/usr/info/dir'. You will then be able to access the documentation
with the command 'info getdp'. Note that particular sections
("nodes") can be accessed directly. For example, 'info getdp
functionspace' will take you directly to the definition of the
FunctionSpace object.
* Use emacs to edit your files, and load the C++ mode! This permits
automatic syntax highlighting and easy indentation. Automatic
loading of the C++ mode for '.pro' files can be achieved by adding
the following command in your '.emacs' file: '(setq automodealist
(append '(("\\.pro$" . c++mode)) automodealist))'.
* Define integration and Jacobian method in separate files, reusable
in all your problem definition structures (*note Includes::).
Define meshes, groups, functions and constraints in one file
dependent of the geometrical model, and function spaces,
formulations, resolutions and postprocessings in files independent
of the geometrical model.
* Use 'All' as soon as possible in the definition of topological
entities used as 'Entity' of 'BasisFunction's. This will prevent
GetDP from constructing unnecessary lists of entities.
* Intentionally misspelling an object type in the problem definition
structure will produce an error message listing all available types
in the particular context.
* If you don't specify the mandatory arguments on the command line,
GetDP will give you the available choices. For example, 'getdp
test pos' (the name of the PostOperation is missing) will produce
an error message listing all available PostOperations.
Appendix F Version history
**************************
3.5.0 (May 13, 2022): generalized Trace operator on nonconforming meshes; new
Errf function; source code reorganization.
3.4.0 (September 23, 2021): new Min and Max functions on constants (at parse
time); fixed regression in trees of edges in 2D; added support for nonASCII
paths on command line on Windows; GetDP now requires C++11 and CMake 3.3; small
bug fixes.
3.3.0 (December 21, 2019): improved support for curved elements; added support
for autosimilar trees of edges (e.g. for sliding surfaces in 3D); update for
latest Gmsh version.
3.2.0 (July 1, 2019): improved node and edge link constraints search using
rtree; added support for BF_Edge basis functions on curved elements; small
fixes.
3.1.0 (April 19, 2019): added support for highorder (curved) Lagrange elements
(P2, P3 and P4); added support for latest Gmsh version; code refactoring.
3.0.4 (December 9, 2018): allow general groups in Jacobian definitions; fixed
string parser regression.
3.0.3 (October 18, 2018): new AtGaussPoint PostOperation option; bug fixes.
3.0.2 (September 10, 2018): small compilation fixes.
3.0.1 (September 7, 2018): small bug fixes.
3.0.0 (August 22, 2018): new extrapolation (see SetExtrapolationOrder) in
timedomain resolutions; new string macros; added support for Gmsh MSH4 file
format; new file handling operations and ElementTable format in PostOperation;
added support for curved (2nd order) simplices; enhanced communication of
postprocessing data with ONELAB; many new functions (Atanh, JnSph, YnSph,
ValueFromTable, ListFromServer, GroupExists, ...); various small bug fixes.
2.11.3 (November 5, 2017): new 'Eig' operator for general eigenvalue problems
(polynomial, rational); small improvements and bug fixes.
2.11.2 (June 23, 2017): minor build system changes.
2.11.1 (May 13, 2017): small bug fixes and improvements.
2.11.0 (January 3, 2017): small improvements (complex math functions, mutual
terms, one side of, get/save runtime variables) and bug fixes.
2.10.0 (October 9, 2016): ONELAB 1.3 with usability and performance
improvements.
2.9.2 (August 21, 2016): small bug fixes.
2.9.1 (August 18, 2016): small improvements (CopySolution[], cpu) and bug
fixes.
2.9.0 (July 11, 2016): new ONELAB 1.2 protocol with native support for lists;
simple C++ and Python API for exchanging (lists of) numbers and strings;
extended .pro language for the construction of extensible problem definitions
("Append"); new VolCylShell transformation; new functions (Min, Max, SetDTime,
...); small fixes.
2.8.0 (March 5, 2016): new Parse[], {Set,Get}{Number,String}[] and
OnPositiveSideOf commands; added support for lists of strings; various
improvements and bug fixes for better interactive use with ONELAB.
2.7.0 (November 7, 2015): new Else/ElseIf commands; new timing and memory
reporting functions.
2.6.1 (July 30, 2015): enhanced Print[] command; minor fixes.
2.6.0 (July 21, 2015): new ability to define and use Macros in .pro files; new
runtime variables (act as registers, but with userdefined names starting with
'$') and runtime ONELAB Get/Set functions; new Append*ToFileName PostOperation
options; new GetResdidual and associated operations; fixes and extended format
support in MSH file reader; fixed UpdateConstraint for complexsimulatedreal
and multiharmonic calculations.
2.5.1 (April 18, 2015): enhanced Python[] and DefineFunction[].
2.5.0 (March 12, 2015): added option to embed Octave and Python interpreters;
extended "Field" functions with gradient; extended string and list handling
functions; new resolution and postprocessing functions (RenameFile, While, ...);
extended EigenSolve with eigenvalue filter and high order polynomial EV
problems; small bug fixes.
2.4.4 (July 9, 2014): better stability, updated onelab API version and inline
parameter definitions, fixed UpdateConstraint in harmonic case, improved
performance of multiharmonic assembly, fixed memory leak in parallel MPI
version, improved EigenSolve (quadratic EVP with SLEPC, EVP on real matrices),
new CosineTransform, MPI_Printf, SendMergeFileRequest parser commands, small
improvements and bug fixes.
2.4.3 (February 7, 2014): new mandatory 'Name' attribute to define onelab
variables in DefineConstant[] & co; minor bug fixes.
2.4.2 (Septembre 27, 2013): fixed function arguments in nested expressions;
minor improvements.
2.4.1 (July 16, 2013): minor improvements and bug fixes.
2.4.0 (July 9, 2013): new twostep Init constraints; faster network computation
(with new cache); improved Update operation; better cpu/memory reporting; new
setnumber, setstring and gmshread command line options; accept unicode file
paths on Windows; small bug fixes.
2.3.1 (May 11, 2013): updated onelab; small bug fixes.
2.3.0 (March 9, 2013): moved build system from autoconf to cmake; new family of
Field functions to use data imported from Gmsh; improved list handling; general
code cleanup.
2.2.1 (July 15, 2012): cleaned up nonlinear convergence tests and integrated
experimental adaptive time loop code; small bug fixes.
2.2.0 (June 19, 2012): new solver interface based on ONELAB; parallel SLEPC
eigensolvers; cleaned up syntax for groups, moving band and global basis
functions; new Field[] functions to interpolate postprocessing datasets from
Gmsh; fixed bug in Sur/Lin transformation of 2 forms; fixed bug for periodic
constraints on highorder edge elements.
2.1.1 (April 12, 2011): default direct solver using MUMPS.
2.1.0 (October 24, 2010): parallel resolution using PETSc solvers; new Gmsh2
output format; new experimental SLEPcbased eigensolvers; various bug and
performance fixes (missing face basis functions, slow PETSc assembly with global
quantities, ...)
2.0.0 (March 16, 2010): general code cleanup (separated interface from kernel
code; removed various undocumented, unstable and otherwise experimental
features; moved to C++); updated input file formats; default solvers are now
based on PETSc; small bug fixes (binary .res read, Newmark restart).
1.2.1 (March 18, 2006): Small fixes.
1.2.0 (March 10, 2006): Windows versions do not depend on Cygwin anymore; major
parser cleanup (loops & co).
1.1.2 (September 3, 2005): Small fixes.
1.1.0 (August 21, 2005): New eigensolver based on Arpack (EigenSolve);
generalized old Lanczos solver to work with GSL+lapack; reworked PETSc
interface, which now requires PETSc 2.3; documented many previously undocumented
features (loops, conditionals, strings, link constraints, etc.); various
improvements and bug fixes.
1.0.1 (February 6, 2005): Small fixes.
1.0.0 (April 24, 2004): New license (GNU GPL); added support for latest Gmsh
mesh file format; more code cleanups.
0.91: Merged moving band and multiharmonic code; new loops and conditionals in
the parser; removed old readline code (just use GNU readline if available);
upgraded to latest Gmsh postprocessing format; various small enhancements and
bug fixes.
0.89 (March 26, 2003): Code cleanup.
0.88: Integrated FMM code.
0.87: Fixed major performance problem on Windows (matrix assembly and
postprocessing can be up to 34 times faster with 0.87 compared to 0.86,
bringing performance much closer to Unix versions); fixed stack overflow on Mac
OS X; Reintroduced face basis functions mistakenly removed in 0.86; fixed
postprocessing bug with pyramidal basis functions; new build system based on
autoconf.
0.86 (January 25, 2003): Updated Gmsh output format; many small bug fixes.
0.85 (January 21, 2002): Upgraded communication interface with Gmsh; new
ChangeOfValues option in PostOperation; many internal changes.
0.84 (September 6, 2001): 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
postprocessing 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
postprocessing); added tolerance in transformation jacobians; fixed parsing of
DOS files (carriage return problems); automatic memory reallocation in
ILUD/ILUK.
0.79: Various bug fixes (mainly for the postprocessing 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
postprocessing formats; new binary formats; new error diagnostics.
0.76: Reorganized high order shape functions; optimization of the
postprocessing (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 postprocessing; tensors;
integral quantities; postprocessing facilities.
0.3: First distributed version.
Appendix G Copyright and credits
********************************
GetDP is copyright (C) 19972022
Patrick Dular
and
Christophe Geuzaine
University of Liege
Major code contributions to GetDP have been provided by Johan Gyselinck, Ruth
Sabariego, Michael Asam, Bertrand Thierry, Francois Henrotte, Guillaume
Dem\'esy. Other code contributors include: David Colignon, Tuan Ledinh, Patrick
Lefevre, Andre Nicolet, JeanFrancois Remacle, Timo Tarhasaari, Christophe
Trophime, Marc Ume and Peter Binde. See the source code for more details.
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, Alejandro Angulo, Geoffrey Deliege, Mark Evans, Philippe Geuzaine,
Eric Godard, Sebastien Guenneau, Daniel Kedzierski, Samuel Kvasnica, Benoit
Meys, Uwe Pahner, Georgia Psoni, Robert Struijs, Ahmed Rassili, Thierry
Scordilis, Herve Tortel, Jose Geraldo A. Brito Neto, Matthias Fenner, Daryl Van
Vorst.
The AVL tree code (src/common/avl.*) is copyright (C) 19881993, 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.
The KissFFT code (src/numeric/kissfft.hh) is copyright (c) 20032010 Mark
Borgerding. Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met: *
Redistributions of source code must retain the above copyright notice, this list
of conditions and the following disclaimer. * Redistributions in binary form
must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with
the distribution. * Neither the author nor the names of any contributors may be
used to endorse or promote products derived from this software without specific
prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
The picojson code (src/common/picojson.h) is Copyright 20092010 Cybozu Labs,
Inc., Copyright 20112014 Kazuho Oku, All rights reserved. Redistribution and
use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met: 1. Redistributions of source
code must retain the above copyright notice, this list of conditions and the
following disclaimer. 2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution. THIS
SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This version of GetDP may contain code (in the contrib/Arpack subdirectory)
written by Danny Sorensen, Richard Lehoucq, Chao Yang and Kristi Maschhoff from
the Dept. of Computational & Applied Mathematics at Rice University, Houston,
Texas, USA. See http://www.caam.rice.edu/software/ARPACK/ for more info.
This version of GetDP may contain code (in the contrib/Sparskit subdirectory)
copyright (C) 1990 Yousef Saad: check the configuration options.
Appendix H License
******************
GetDP is provided under the terms of the GNU General Public License
(GPL), Version 2 or later.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 021101301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
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
softwareto 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.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
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.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
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.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
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.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machinereadable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machinereadable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
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.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royaltyfree redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
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.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
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.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
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.
Copyright (C)
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 021111307 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) year 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
mouseclicks or menu itemswhatever 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.
, 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.
Concept index
*************
* Menu:
* .msh file: Input file format. (line 6079)
* .pre file: File pre. (line 6128)
* .res file: File res. (line 6177)
* Acknowledgments: Copyright and credits.
(line 6786)
* Analytical integration: Integration. (line 1747)
* Approximation spaces: FunctionSpace. (line 1588)
* Arguments: Functions. (line 1022)
* Arguments, definition: Arguments. (line 1112)
* Axisymmetric, transformation: Jacobian. (line 1704)
* Basis Functions: FunctionSpace. (line 1588)
* Binary operators: Operator types. (line 928)
* Boundary conditions: Constraint. (line 1517)
* Boundary Element Method: Which problems can GetDP actually solve?.
(line 307)
* Bugs, reporting: Bug reports. (line 353)
* Builtin functions: Functions. (line 1022)
* Change of coordinates: Jacobian. (line 1704)
* Changelog: Version history. (line 6558)
* Circuit equations: Constraint. (line 1517)
* Command line options: Running GetDP. (line 405)
* Comments: Comments. (line 611)
* Complete examples: Complete examples. (line 5209)
* Complexvalued, system: Resolution. (line 1895)
* Concepts, index: Concept index. (line 7221)
* Conditionals: Macros loops and conditionals.
(line 1284)
* Constant, definition: Constants. (line 693)
* Constant, evaluation: Constants. (line 693)
* Constraint, definition: Constraint. (line 1517)
* Constraint, examples: Constraint examples.
(line 4496)
* Constraint, types: Types for Constraint.
(line 2953)
* Contributors, list: Copyright and credits.
(line 6786)
* Coordinate change: Jacobian. (line 1704)
* Copyright: Copying conditions. (line 152)
* Copyright <1>: Copyright and credits.
(line 6786)
* Credits: Copyright and credits.
(line 6786)
* Curl: Fields. (line 1169)
* Current values: Current values. (line 1056)
* Dependences, objects: Numerical tools as objects.
(line 216)
* Derivative, exterior: Fields. (line 1169)
* Derivative, time: Formulation. (line 1795)
* Developments, future: Which problems can GetDP actually solve?.
(line 307)
* Differential operators: Fields. (line 1169)
* Discrete function spaces: FunctionSpace. (line 1588)
* Discrete quantities: Fields. (line 1169)
* Discretized Geometry: Group. (line 1385)
* Divergence: Fields. (line 1169)
* Document syntax: Syntactic rules. (line 383)
* Download: Obtaining GetDP. (line 142)
* Download <1>: Copying conditions. (line 152)
* Edge element space, example: Magnetostatics. (line 4902)
* Efficiency, tips: Tips and tricks. (line 6524)
* Electromagnetism: Which problems can GetDP actually solve?.
(line 307)
* Electrostatic formulation: Electrostatics. (line 4844)
* Elementary matrices: Formulation. (line 1795)
* Entities, topological: Group. (line 1385)
* Equations: Formulation. (line 1795)
* Evaluation mechanism: Constants. (line 693)
* Evaluation, order: Evaluation order. (line 1004)
* Examples, complete: Complete examples. (line 5209)
* Examples, short: Short examples. (line 4358)
* Exporting results: PostOperation. (line 2038)
* Expression, definition: Expression definition.
(line 636)
* Exterior derivative: Fields. (line 1169)
* FAQ: Frequently asked questions.
(line 6422)
* Fields: Fields. (line 1169)
* File, .msh: Input file format. (line 6079)
* File, .pre: File pre. (line 6128)
* File, .res: File res. (line 6177)
* File, comment: Comments. (line 611)
* File, include: Includes. (line 622)
* File, mesh: Input file format. (line 6079)
* File, preprocessing: File pre. (line 6128)
* File, result: File res. (line 6177)
* Finite Difference Method: Which problems can GetDP actually solve?.
(line 307)
* Finite Element Method: Which problems can GetDP actually solve?.
(line 307)
* Finite Volume Method: Which problems can GetDP actually solve?.
(line 307)
* Floating point numbers: Constants. (line 693)
* Floating potential, example: Electrostatics 2. (line 4876)
* Format, output: PostOperation. (line 2038)
* Formulation, definition: Formulation. (line 1795)
* Formulation, electrostatics: Electrostatics. (line 4844)
* Formulation, examples: Formulation examples.
(line 4841)
* Formulation, types: Types for Formulation.
(line 3257)
* Frequency: Resolution. (line 1895)
* Frequently asked questions: Frequently asked questions.
(line 6422)
* Function groups: Group. (line 1385)
* Function space, definition: FunctionSpace. (line 1588)
* Function space, examples: FunctionSpace examples.
(line 4547)
* Function space, types: Types for FunctionSpace.
(line 3008)
* Function, definition: Functions. (line 1022)
* Function, definition <1>: Function. (line 1474)
* Function, examples: Function examples. (line 4411)
* Future developments: Which problems can GetDP actually solve?.
(line 307)
* Gauss, integration: Integration. (line 1747)
* Geometric transformations: Jacobian. (line 1704)
* Global quantity: Formulation. (line 1795)
* Global quantity, example: Electrostatics 2. (line 4876)
* Gmsh, examples: Gmsh examples. (line 6205)
* Gmsh, file format: Input file format. (line 6079)
* Gradient: Fields. (line 1169)
* Grid: Group. (line 1385)
* Group, definition: Group. (line 1385)
* Group, examples: Group examples. (line 4382)
* Group, types: Types for Group. (line 2124)
* Hierarchical basis functions: FunctionSpace. (line 1588)
* History, versions: Version history. (line 6558)
* Includes: Includes. (line 622)
* Index, concepts: Concept index. (line 7221)
* Index, metasyntactic variables: Metasyntactic variable index.
(line 0)
* Index, syntax: Syntax index. (line 0)
* Input file format: Input file format. (line 6079)
* Integer numbers: Constants. (line 693)
* Integral Equation Method: Which problems can GetDP actually solve?.
(line 307)
* Integral quantity: Formulation. (line 1795)
* Integration, definition: Integration. (line 1747)
* Integration, examples: Integration examples.
(line 4818)
* Integration, types: Types for Integration.
(line 3215)
* Internet address: Obtaining GetDP. (line 142)
* Internet address <1>: Copying conditions. (line 152)
* Interpolation: Fields. (line 1169)
* Interpolation <1>: FunctionSpace. (line 1588)
* Introduction: Overview. (line 191)
* Iterative loop: Resolution. (line 1895)
* Jacobian, definition: Jacobian. (line 1704)
* Jacobian, examples: Jacobian examples. (line 4786)
* Jacobian, types: Types for Jacobian. (line 3141)
* Keywords, index: Syntax index. (line 0)
* License: Copying conditions. (line 152)
* License <1>: License. (line 6874)
* Linear system solving: Resolution. (line 1895)
* Linking, objects: Numerical tools as objects.
(line 216)
* Local quantity: Formulation. (line 1795)
* Loops: Macros loops and conditionals.
(line 1284)
* Macros: Macros loops and conditionals.
(line 1284)
* Maps: PostOperation. (line 2038)
* Matrices, elementary: Formulation. (line 1795)
* Mechanics: Which problems can GetDP actually solve?.
(line 307)
* Mesh: Group. (line 1385)
* Mesh, examples: Gmsh examples. (line 6205)
* Mesh, file format: Input file format. (line 6079)
* Metasyntactic variables, index: Metasyntactic variable index.
(line 0)
* Method of Moments: Which problems can GetDP actually solve?.
(line 307)
* Networks: Constraint. (line 1517)
* Newmark, time scheme: Resolution. (line 1895)
* Newton, nonlinear scheme: Resolution. (line 1895)
* Nodal function space, example: Electrostatics. (line 4844)
* Nonlinear system solving: Resolution. (line 1895)
* Numbers, integer: Constants. (line 693)
* Numbers, real: Constants. (line 693)
* Numerical integration: Integration. (line 1747)
* Objects, definition: Objects. (line 1376)
* Objects, dependences: Numerical tools as objects.
(line 216)
* Objects, types: Types for objects. (line 2121)
* Operating system: Running GetDP. (line 405)
* Operation, priorities: Evaluation order. (line 1004)
* Operators, definition: Operator types. (line 928)
* Operators, differential: Fields. (line 1169)
* Options, command line: Running GetDP. (line 405)
* Order of evaluation: Evaluation order. (line 1004)
* Output file format: Output file format. (line 6125)
* Overview: Overview. (line 191)
* Parameters: Functions. (line 1022)
* Parse: Macros loops and conditionals.
(line 1284)
* Philosophy, general: Numerical tools as objects.
(line 216)
* Physical problems: Which problems can GetDP actually solve?.
(line 307)
* Picard, nonlinear scheme: Resolution. (line 1895)
* Piecewise functions: Functions. (line 1022)
* Piecewise functions <1>: Function. (line 1474)
* Platforms: Running GetDP. (line 405)
* Postoperation, definition: PostOperation. (line 2038)
* Postoperation, examples: PostOperation examples.
(line 5146)
* Postoperation, types: Types for PostOperation.
(line 3912)
* Postprocessing, definition: PostProcessing. (line 1976)
* Postprocessing, examples: PostProcessing examples.
(line 5105)
* Postprocessing, types: Types for PostProcessing.
(line 3897)
* Priorities, operations: Evaluation order. (line 1004)
* Processing cycle: Numerical tools as objects.
(line 216)
* Quantities, discrete: Fields. (line 1169)
* Quantity, global: Formulation. (line 1795)
* Quantity, integral: Formulation. (line 1795)
* Quantity, local: Formulation. (line 1795)
* Quantity, postprocessing: PostProcessing. (line 1976)
* Questions, frequently asked: Frequently asked questions.
(line 6422)
* Reading, guidelines: How to Read this Manual.
(line 366)
* Real numbers: Constants. (line 693)
* Region groups: Group. (line 1385)
* Registers, definition: Runtime variables and registers.
(line 1124)
* Relaxation factor: Resolution. (line 1895)
* Reporting bugs: Bug reports. (line 353)
* Resolution, definition: Resolution. (line 1895)
* Resolution, examples: Resolution examples.
(line 4966)
* Resolution, types: Types for Resolution.
(line 3328)
* Results, exploitation: PostProcessing. (line 1976)
* Results, export: PostOperation. (line 2038)
* Rules, syntactic: Syntactic rules. (line 383)
* Runtime variables, definition: Runtime variables and registers.
(line 1124)
* Running GetDP: Running GetDP. (line 405)
* Scope of GetDP: Which problems can GetDP actually solve?.
(line 307)
* Sections: PostOperation. (line 2038)
* Short examples: Short examples. (line 4358)
* Solving, system: Resolution. (line 1895)
* Spaces, discrete: FunctionSpace. (line 1588)
* String: Constants. (line 693)
* Symmetry, integral kernel: Formulation. (line 1795)
* Syntax, index: Syntax index. (line 0)
* Syntax, rules: Syntactic rules. (line 383)
* System, definition: Resolution. (line 1895)
* Ternary operators: Operator types. (line 928)
* Thermics: Which problems can GetDP actually solve?.
(line 307)
* Theta, time scheme: Resolution. (line 1895)
* Time derivative: Formulation. (line 1795)
* Time stepping: Resolution. (line 1895)
* Time, discretization: Resolution. (line 1895)
* Tips: Tips and tricks. (line 6524)
* Tools, order of definition: Numerical tools as objects.
(line 216)
* Topology: Group. (line 1385)
* Transformations, geometric: Jacobian. (line 1704)
* Tree: Group. (line 1385)
* Tricks: Tips and tricks. (line 6524)
* Types, definition: Types for objects. (line 2121)
* Unary operators: Operator types. (line 928)
* Userdefined functions: Function. (line 1474)
* Values, current: Current values. (line 1056)
* Variables, index: Metasyntactic variable index.
(line 0)
* Versions: Version history. (line 6558)
* Web site: Obtaining GetDP. (line 142)
* Web site <1>: Copying conditions. (line 152)
* Wiki: Complete examples. (line 5209)
Metasyntactic variable index
****************************
* Menu:
* :: Syntactic rules. (line 383)
* <, >: Syntactic rules. (line 383)
* : Syntactic rules. (line 383)
* ...: Syntactic rules. (line 383)
* AFFECTATION: Constants. (line 693)
* ARGUMENT: Arguments. (line 1112)
* BASISFUNCTIONID: FunctionSpace. (line 1588)
* BASISFUNCTIONLIST: FunctionSpace. (line 1588)
* BASISFUNCTIONTYPE: FunctionSpace. (line 1588)
* BASISFUNCTIONTYPE <1>: Types for FunctionSpace.
(line 3008)
* BUILTINFUNCTIONID: Functions. (line 1022)
* COEFID: FunctionSpace. (line 1588)
* CONSTANTDEF: Constants. (line 693)
* CONSTANTID: Constants. (line 693)
* CONSTRAINTCASEID: Constraint. (line 1517)
* CONSTRAINTCASEVAL: Constraint. (line 1517)
* CONSTRAINTID: Constraint. (line 1517)
* CONSTRAINTTYPE: Constraint. (line 1517)
* CONSTRAINTTYPE <1>: Types for Constraint.
(line 2953)
* CONSTRAINTVAL: Constraint. (line 1517)
* COORDFUNCTIONID: Coordinate functions.
(line 2668)
* ELEMENTTYPE: Integration. (line 1747)
* ELEMENTTYPE <1>: Types for Integration.
(line 3215)
* ETC: Syntactic rules. (line 383)
* EXPRESSION: Expression definition.
(line 636)
* EXPRESSIONCHAR: Constants. (line 693)
* EXPRESSIONCST: Constants. (line 693)
* EXPRESSIONCSTLIST: Constants. (line 693)
* EXPRESSIONCSTLISTITEM: Constants. (line 693)
* EXPRESSIONLIST: Expression definition.
(line 636)
* EXTENDEDMATHFUNCTIONID: Extended math functions.
(line 2377)
* FORMULATIONID: Formulation. (line 1795)
* FORMULATIONLIST: Resolution. (line 1895)
* FORMULATIONTYPE: Formulation. (line 1795)
* FORMULATIONTYPE <1>: Types for Formulation.
(line 3257)
* FUNCTIONID: Function. (line 1474)
* FUNCTIONSPACEID: FunctionSpace. (line 1588)
* FUNCTIONSPACETYPE: FunctionSpace. (line 1588)
* FUNCTIONSPACETYPE <1>: Types for FunctionSpace.
(line 3008)
* GLOBALQUANTITYID: FunctionSpace. (line 1588)
* GLOBALQUANTITYTYPE: FunctionSpace. (line 1588)
* GLOBALQUANTITYTYPE <1>: Types for FunctionSpace.
(line 3008)
* GREENFUNCTIONID: Green functions. (line 2466)
* GROUPDEF: Group. (line 1385)
* GROUPID: Group. (line 1385)
* GROUPLIST: Group. (line 1385)
* GROUPLISTITEM: Group. (line 1385)
* GROUPSUBTYPE: Group. (line 1385)
* GROUPTYPE: Group. (line 1385)
* GROUPTYPE <1>: Types for Group. (line 2124)
* INTEGER: Constants. (line 693)
* INTEGRALVALUE: PostProcessing. (line 1976)
* INTEGRATIONID: Integration. (line 1747)
* INTEGRATIONTYPE: Integration. (line 1747)
* INTEGRATIONTYPE <1>: Types for Integration.
(line 3215)
* JACOBIANID: Jacobian. (line 1704)
* JACOBIANTYPE: Jacobian. (line 1704)
* JACOBIANTYPE <1>: Types for Jacobian. (line 3141)
* LOCALTERMTYPE: Formulation. (line 1795)
* LOCALTERMTYPE <1>: Types for Formulation.
(line 3257)
* LOCALVALUE: PostProcessing. (line 1976)
* LOOP: Macros loops and conditionals.
(line 1284)
* MATHFUNCTIONID: Math functions. (line 2215)
* MISCFUNCTIONID: Miscellaneous functions.
(line 2693)
* OPERATORBINARY: Operator types. (line 928)
* OPERATORTERNARYLEFT: Operator types. (line 928)
* OPERATORTERNARYRIGHT: Operator types. (line 928)
* OPERATORUNARY: Operator types. (line 928)
* POSTOPERATIONFMT: PostOperation. (line 2038)
* POSTOPERATIONFMT <1>: Types for PostOperation.
(line 4294)
* POSTOPERATIONID: PostOperation. (line 2038)
* POSTOPERATIONOP: PostOperation. (line 2038)
* POSTPROCESSINGID: PostProcessing. (line 1976)
* POSTQUANTITYID: PostProcessing. (line 1976)
* POSTQUANTITYTYPE: PostProcessing. (line 1976)
* POSTVALUE: PostProcessing. (line 1976)
* POSTVALUE <1>: Types for PostProcessing.
(line 3897)
* PRINTOPTION: PostOperation. (line 2038)
* PRINTOPTION <1>: Types for PostOperation.
(line 3999)
* PRINTSUPPORT: PostOperation. (line 2038)
* PRINTSUPPORT <1>: Types for PostOperation.
(line 3912)
* QUANTITY: Fields. (line 1169)
* QUANTITYDOF: Fields. (line 1169)
* QUANTITYID: Fields. (line 1169)
* QUANTITYOPERATOR: Fields. (line 1169)
* QUANTITYTYPE: Formulation. (line 1795)
* QUANTITYTYPE <1>: Types for Formulation.
(line 3257)
* REAL: Constants. (line 693)
* REGISTERGET: Runtime variables and registers.
(line 1124)
* REGISTERSET: Runtime variables and registers.
(line 1124)
* RESOLUTIONID: Resolution. (line 1895)
* RESOLUTIONOP: Resolution. (line 1895)
* RESOLUTIONOP <1>: Types for Resolution.
(line 3328)
* STRING: Constants. (line 693)
* STRINGID: Constants. (line 693)
* SUBSPACEID: FunctionSpace. (line 1588)
* SYSTEMID: Resolution. (line 1895)
* SYSTEMTYPE: Resolution. (line 1895)
* TERMOPTYPE: Formulation. (line 1795)
* TERMOPTYPE <1>: Types for Formulation.
(line 3257)
* TYPEFUNCTIONID: Type manipulation functions.
(line 2503)
* VARIABLEGET: Runtime variables and registers.
(line 1124)
* VARIABLESET: Runtime variables and registers.
(line 1124)
Syntax index
************
* Menu:
* !: Operator types. (line 928)
* !=: Operator types. (line 928)
* #EXPRESSIONCST: Runtime variables and registers.
(line 1124)
* #include: Includes. (line 622)
* $A: Current values. (line 1056)
* $B: Current values. (line 1056)
* $Breakpoint: Current values. (line 1056)
* $C: Current values. (line 1056)
* $DTime: Current values. (line 1056)
* $EigenvalueImag: Current values. (line 1056)
* $EigenvalueReal: Current values. (line 1056)
* $INTEGER: Arguments. (line 1112)
* $Iteration: Current values. (line 1056)
* $Theta: Current values. (line 1056)
* $Time: Current values. (line 1056)
* $TimeStep: Current values. (line 1056)
* $X: Current values. (line 1056)
* $XS: Current values. (line 1056)
* $Y: Current values. (line 1056)
* $YS: Current values. (line 1056)
* $Z: Current values. (line 1056)
* $ZS: Current values. (line 1056)
* %: Operator types. (line 928)
* &: Operator types. (line 928)
* &&: Operator types. (line 928)
* (): Evaluation order. (line 1004)
* *: Operator types. (line 928)
* +: Operator types. (line 928)
* : Operator types. (line 928)
*  <1>: Operator types. (line 928)
* adapt: Running GetDP. (line 513)
* bin: Running GetDP. (line 527)
* cache: Running GetDP. (line 523)
* cal: Running GetDP. (line 440)
* check: Running GetDP. (line 535)
* cpu: Running GetDP. (line 546)
* gmshread: Running GetDP. (line 471)
* help: Running GetDP. (line 581)
* info: Running GetDP. (line 573)
* msh: Running GetDP. (line 459)
* msh_scaling: Running GetDP. (line 466)
* name: Running GetDP. (line 487)
* onelab: Running GetDP. (line 558)
* order: Running GetDP. (line 518)
* p: Running GetDP. (line 550)
* pos: Running GetDP. (line 450)
* pre: Running GetDP. (line 429)
* progress: Running GetDP. (line 551)
* res: Running GetDP. (line 482)
* restart: Running GetDP. (line 493)
* setnumber: Running GetDP. (line 563)
* setstring: Running GetDP. (line 568)
* slepc: Running GetDP. (line 509)
* solve: Running GetDP. (line 498)
* solver: Running GetDP. (line 503)
* split: Running GetDP. (line 478)
* v: Running GetDP. (line 539)
* v2: Running GetDP. (line 531)
* verbose: Running GetDP. (line 540)
* version: Running GetDP. (line 577)
* /: Operator types. (line 928)
* /*, */: Comments. (line 611)
* //: Comments. (line 611)
* /\: Operator types. (line 928)
* 0D: Constants. (line 693)
* 1D: Constants. (line 693)
* 2D: Constants. (line 693)
* 3D: Constants. (line 693)
* <: Operator types. (line 928)
* <<: Operator types. (line 928)
* <=: Operator types. (line 928)
* =: Constants. (line 693)
* = <1>: Group. (line 1385)
* = <2>: Function. (line 1474)
* ==: Operator types. (line 928)
* >: Operator types. (line 928)
* >=: Operator types. (line 928)
* >>: Operator types. (line 928)
* ?:: Operator types. (line 928)
* ^: Operator types. (line 928)
* : Operator types. (line 928)
* : Operator types. (line 928)
* ~: Constants. (line 693)
* Abs: Math functions. (line 2307)
* Acos: Math functions. (line 2259)
* Adapt: Types for PostOperation.
(line 4166)
* Adaptation: Types for PostOperation.
(line 4351)
* AliasOf: Types for FunctionSpace.
(line 3131)
* All: Group. (line 1385)
* All <1>: Jacobian. (line 1704)
* Analytic: Integration. (line 1747)
* Append: Constraint. (line 1517)
* Append <1>: FunctionSpace. (line 1588)
* Append <2>: Jacobian. (line 1704)
* Append <3>: Integration. (line 1747)
* Append <4>: Formulation. (line 1795)
* Append <5>: Resolution. (line 1895)
* Append <6>: PostProcessing. (line 1976)
* Append <7>: PostOperation. (line 2038)
* AppendExpressionFormat: Types for PostOperation.
(line 4092)
* AppendExpressionToFileName: Types for PostOperation.
(line 4086)
* AppendStringToFileName: Types for PostOperation.
(line 4104)
* AppendTimeStepToFileName: Types for PostOperation.
(line 4098)
* AppendToExistingFile: Types for PostOperation.
(line 4018)
* Apply: Types for Resolution.
(line 3474)
* Asin: Math functions. (line 2248)
* Assign: Types for Constraint.
(line 2955)
* AssignFromResolution: Types for Constraint.
(line 2965)
* AssociatedWith: Types for FunctionSpace.
(line 3134)
* Atan: Math functions. (line 2270)
* Atan2: Math functions. (line 2276)
* AtGaussPoints: Types for PostOperation.
(line 4040)
* AtIndex: Miscellaneous functions.
(line 2766)
* BasisFunction: FunctionSpace. (line 1588)
* BF: Fields. (line 1213)
* BF_CurlEdge: Types for FunctionSpace.
(line 3053)
* BF_CurlGroupOfEdges: Types for FunctionSpace.
(line 3069)
* BF_CurlGroupOfPerpendicularEdge: Types for FunctionSpace.
(line 3082)
* BF_CurlPerpendicularEdge: Types for FunctionSpace.
(line 3076)
* BF_dGlobal: Types for FunctionSpace.
(line 3110)
* BF_DivFacet: Types for FunctionSpace.
(line 3056)
* BF_DivPerpendicularFacet: Types for FunctionSpace.
(line 3090)
* BF_Edge: Types for FunctionSpace.
(line 3041)
* BF_Facet: Types for FunctionSpace.
(line 3044)
* BF_Global: Types for FunctionSpace.
(line 3106)
* BF_GradGroupOfNodes: Types for FunctionSpace.
(line 3062)
* BF_GradNode: Types for FunctionSpace.
(line 3050)
* BF_GroupOfEdges: Types for FunctionSpace.
(line 3066)
* BF_GroupOfNodes: Types for FunctionSpace.
(line 3059)
* BF_GroupOfPerpendicularEdge: Types for FunctionSpace.
(line 3079)
* BF_Node: Types for FunctionSpace.
(line 3038)
* BF_NodeX: Types for FunctionSpace.
(line 3114)
* BF_NodeY: Types for FunctionSpace.
(line 3117)
* BF_NodeZ: Types for FunctionSpace.
(line 3120)
* BF_One: Types for FunctionSpace.
(line 3126)
* BF_PerpendicularEdge: Types for FunctionSpace.
(line 3073)
* BF_PerpendicularFacet: Types for FunctionSpace.
(line 3086)
* BF_Region: Types for FunctionSpace.
(line 3094)
* BF_RegionX: Types for FunctionSpace.
(line 3097)
* BF_RegionY: Types for FunctionSpace.
(line 3100)
* BF_RegionZ: Types for FunctionSpace.
(line 3103)
* BF_Volume: Types for FunctionSpace.
(line 3047)
* BF_Zero: Types for FunctionSpace.
(line 3123)
* Break: Types for Resolution.
(line 3621)
* Call STRING  EXPRESSIONCHAR;: Macros loops and conditionals.
(line 1309)
* Cart2Cyl: Type manipulation functions.
(line 2642)
* Cart2Pol: Type manipulation functions.
(line 2532)
* Cart2Sph: Type manipulation functions.
(line 2636)
* Case: Constraint. (line 1517)
* Case <1>: Jacobian. (line 1704)
* Case <2>: Integration. (line 1747)
* Ceil: Math functions. (line 2318)
* ChangeOfCoordinates: Types for PostOperation.
(line 4206)
* ChangeOfValues: Types for PostOperation.
(line 4215)
* Closed: Types for PostOperation.
(line 4144)
* Color: Types for PostOperation.
(line 4132)
* CompElementNum: Miscellaneous functions.
(line 2744)
* Complex: Type manipulation functions.
(line 2505)
* ComplexScalarField: Miscellaneous functions.
(line 2849)
* ComplexTensorField: Miscellaneous functions.
(line 2861)
* ComplexVectorField: Miscellaneous functions.
(line 2855)
* Complex_MH: Type manipulation functions.
(line 2512)
* CompX: Type manipulation functions.
(line 2576)
* CompXX: Type manipulation functions.
(line 2591)
* CompXY: Type manipulation functions.
(line 2596)
* CompXZ: Type manipulation functions.
(line 2601)
* CompY: Type manipulation functions.
(line 2581)
* CompYX: Type manipulation functions.
(line 2606)
* CompYY: Type manipulation functions.
(line 2611)
* CompYZ: Type manipulation functions.
(line 2616)
* CompZ: Type manipulation functions.
(line 2586)
* CompZX: Type manipulation functions.
(line 2621)
* CompZY: Type manipulation functions.
(line 2626)
* CompZZ: Type manipulation functions.
(line 2631)
* Conj: Type manipulation functions.
(line 2527)
* Constraint: Constraint. (line 1517)
* Constraint <1>: FunctionSpace. (line 1588)
* CopyResidual: Types for Resolution.
(line 3524)
* CopyResidual <1>: Types for Resolution.
(line 3533)
* CopyRightHandSide: Types for Resolution.
(line 3509)
* CopyRightHandSide <1>: Types for Resolution.
(line 3518)
* CopySolution: Types for Resolution.
(line 3494)
* CopySolution <1>: Types for Resolution.
(line 3503)
* Cos: Math functions. (line 2254)
* Cosh: Math functions. (line 2287)
* Cos_wt_p: Extended math functions.
(line 2433)
* CreateDir  CreateDirectory: Types for Resolution.
(line 3864)
* CreateSolution: Types for Resolution.
(line 3462)
* CreateSolution <1>: Types for Resolution.
(line 3468)
* Criterion: Integration. (line 1747)
* Cross: Extended math functions.
(line 2379)
* Curl: Fields. (line 1225)
* d: Fields. (line 1219)
* D1: Fields. (line 1232)
* D2: Fields. (line 1255)
* DecomposeInSimplex: Types for PostOperation.
(line 4223)
* DefineConstant: Constants. (line 693)
* DefineFunction: Function. (line 1474)
* DefineGroup: Group. (line 1385)
* DeleteFile: Types for Resolution.
(line 3854)
* Depth: Types for PostOperation.
(line 4032)
* deRham: Types for Formulation.
(line 3268)
* DestinationSystem: Resolution. (line 1895)
* Det: Extended math functions.
(line 2416)
* dFunction: FunctionSpace. (line 1588)
* Dimension: Types for PostOperation.
(line 4059)
* dInterpolationAkima: Miscellaneous functions.
(line 2802)
* dInterpolationBilinear: Miscellaneous functions.
(line 2790)
* dInterpolationLinear: Miscellaneous functions.
(line 2779)
* Distance: Miscellaneous functions.
(line 2867)
* Div: Fields. (line 1229)
* dJn: Math functions. (line 2353)
* Dof: Fields. (line 1188)
* Dt: Types for Formulation.
(line 3289)
* DtDof: Types for Formulation.
(line 3293)
* DtDofJacNL: Types for Formulation.
(line 3316)
* DtDt: Types for Formulation.
(line 3296)
* DtDtDof: Types for Formulation.
(line 3300)
* DualEdgesOf: Types for Group. (line 2200)
* DualFacetsOf: Types for Group. (line 2203)
* DualNodesOf: Types for Group. (line 2197)
* DualVolumesOf: Types for Group. (line 2206)
* dYn: Math functions. (line 2367)
* EdgesOf: Types for Group. (line 2142)
* EdgesOfTreeIn: Types for Group. (line 2187)
* Eig: Types for Formulation.
(line 3304)
* EigenSolve: Types for Resolution.
(line 3659)
* EigenvalueLegend: Types for PostOperation.
(line 4287)
* ElementNum: Miscellaneous functions.
(line 2756)
* ElementsOf: Types for Group. (line 2157)
* ElementTable: Types for PostOperation.
(line 4329)
* ElementVol: Miscellaneous functions.
(line 2728)
* Else: Macros loops and conditionals.
(line 1358)
* ElseIf ( EXPRESSIONCST ): Macros loops and conditionals.
(line 1352)
* ENABLE_ARPACK: Compiling the source code.
(line 6354)
* ENABLE_BLAS_LAPACK: Compiling the source code.
(line 6356)
* ENABLE_BUILD_ANDROID: Compiling the source code.
(line 6368)
* ENABLE_BUILD_DYNAMIC: Compiling the source code.
(line 6365)
* ENABLE_BUILD_IOS: Compiling the source code.
(line 6370)
* ENABLE_BUILD_LIB: Compiling the source code.
(line 6359)
* ENABLE_BUILD_SHARED: Compiling the source code.
(line 6362)
* ENABLE_FORTRAN: Compiling the source code.
(line 6372)
* ENABLE_GMSH: Compiling the source code.
(line 6375)
* ENABLE_GSL: Compiling the source code.
(line 6377)
* ENABLE_KERNEL: Compiling the source code.
(line 6379)
* ENABLE_MMA: Compiling the source code.
(line 6381)
* ENABLE_MPI: Compiling the source code.
(line 6383)
* ENABLE_MULTIHARMONIC: Compiling the source code.
(line 6385)
* ENABLE_NR: Compiling the source code.
(line 6387)
* ENABLE_NX: Compiling the source code.
(line 6389)
* ENABLE_OCTAVE: Compiling the source code.
(line 6391)
* ENABLE_OPENMP: Compiling the source code.
(line 6393)
* ENABLE_PETSC: Compiling the source code.
(line 6396)
* ENABLE_PEWE: Compiling the source code.
(line 6412)
* ENABLE_PRIVATE_API: Compiling the source code.
(line 6398)
* ENABLE_PYTHON: Compiling the source code.
(line 6400)
* ENABLE_SLEPC: Compiling the source code.
(line 6402)
* ENABLE_SMALLFEM: Compiling the source code.
(line 6404)
* ENABLE_SPARSKIT: Compiling the source code.
(line 6406)
* ENABLE_SYSTEM_CONTRIB: Compiling the source code.
(line 6409)
* ENABLE_WRAP_PYTHON: Compiling the source code.
(line 6414)
* ENABLE_ZITSOL: Compiling the source code.
(line 6416)
* EndFor: Macros loops and conditionals.
(line 1344)
* EndIf: Macros loops and conditionals.
(line 1363)
* Entity: FunctionSpace. (line 1588)
* EntitySubType: FunctionSpace. (line 1588)
* EntityType: FunctionSpace. (line 1588)
* Equation: Formulation. (line 1795)
* Error: Types for Resolution.
(line 3597)
* Evaluate: Types for Resolution.
(line 3567)
* Exit: Types for Resolution.
(line 3626)
* Exp: Math functions. (line 2223)
* Fabs: Math functions. (line 2302)
* FacetsOf: Types for Group. (line 2147)
* FacetsOfTreeIn: Types for Group. (line 2192)
* FemEquation: Types for Formulation.
(line 3259)
* Field: Miscellaneous functions.
(line 2813)
* Field <1>: Miscellaneous functions.
(line 2820)
* File: Types for PostOperation.
(line 4001)
* File <1>: Types for PostOperation.
(line 4006)
* File <2>: Types for PostOperation.
(line 4013)
* Floor: Math functions. (line 2312)
* Fmod: Math functions. (line 2324)
* For ( EXPRESSIONCST : EXPRESSIONCST ): Macros loops and conditionals.
(line 1312)
* For ( EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST ): Macros loops and conditionals.
(line 1319)
* For STRING In { EXPRESSIONCST : EXPRESSIONCST : EXPRESSIONCST }: Macros loops and conditionals.
(line 1335)
* For STRING In { EXPRESSIONCST : EXPRESSIONCST }: Macros loops and conditionals.
(line 1327)
* Form0: Types for FunctionSpace.
(line 3010)
* Form1: Types for FunctionSpace.
(line 3013)
* Form1P: Types for FunctionSpace.
(line 3022)
* Form2: Types for FunctionSpace.
(line 3016)
* Form2P: Types for FunctionSpace.
(line 3026)
* Form3: Types for FunctionSpace.
(line 3019)
* Format: PostOperation. (line 2038)
* Format <1>: Types for PostOperation.
(line 4161)
* Formulation: FunctionSpace. (line 1588)
* Formulation <1>: Formulation. (line 1795)
* FourierTransform: Types for Resolution.
(line 3682)
* Frequency: Resolution. (line 1895)
* Frequency <1>: Types for PostOperation.
(line 4156)
* FrequencyLegend: Types for PostOperation.
(line 4280)
* Function: Function. (line 1474)
* Function <1>: FunctionSpace. (line 1588)
* FunctionSpace: FunctionSpace. (line 1588)
* Gauss: Types for Integration.
(line 3217)
* GaussLegendre: Types for Integration.
(line 3220)
* Generate: Types for Resolution.
(line 3330)
* GenerateGroup: Types for Resolution.
(line 3387)
* GenerateJac: Types for Resolution.
(line 3353)
* GenerateOnly: Types for Resolution.
(line 3377)
* GenerateOnlyJac: Types for Resolution.
(line 3382)
* GenerateRightHandSideGroup: Types for Resolution.
(line 3391)
* GenerateSeparate: Types for Resolution.
(line 3368)
* GeoElement: Integration. (line 1747)
* GetCpuTime: Miscellaneous functions.
(line 2875)
* GetMemory: Miscellaneous functions.
(line 2887)
* GetNormSolution  GetNormRightHandSide  GetNormResidual  GetNormIncrement: Types for Resolution.
(line 3427)
* GetNumberRunTime: Miscellaneous functions.
(line 2906)
* GetNumElements: Miscellaneous functions.
(line 2750)
* GetResidual: Types for Resolution.
(line 3421)
* GetVariable: Miscellaneous functions.
(line 2921)
* GetVolume: Miscellaneous functions.
(line 2739)
* GetWallClockTime: Miscellaneous functions.
(line 2881)
* Global: Types for Group. (line 2133)
* Global <1>: Types for Formulation.
(line 3278)
* GlobalEquation: Formulation. (line 1795)
* GlobalQuantity: FunctionSpace. (line 1588)
* GlobalTerm: Formulation. (line 1795)
* Gmsh: Types for PostOperation.
(line 4296)
* GmshClearAll: Types for Resolution.
(line 3843)
* GmshParsed: Types for PostOperation.
(line 4297)
* GmshRead: Types for Resolution.
(line 3806)
* GmshRead <1>: Types for Resolution.
(line 3821)
* GmshRead <2>: Types for Resolution.
(line 3830)
* GmshWrite: Types for Resolution.
(line 3837)
* Gnuplot: Types for PostOperation.
(line 4338)
* Grad: Fields. (line 1222)
* GradHelmholtz: Green functions. (line 2494)
* GradLaplace: Green functions. (line 2482)
* Group: Group. (line 1385)
* Group <1>: FunctionSpace. (line 1588)
* GroupOfRegionsOf: Types for Group. (line 2183)
* GroupsOfEdgesOf: Types for Group. (line 2170)
* GroupsOfEdgesOnNodesOf: Types for Group. (line 2177)
* GroupsOfNodesOf: Types for Group. (line 2166)
* HarmonicToTime: Types for PostOperation.
(line 4053)
* Helmholtz: Green functions. (line 2488)
* Hexahedron: Types for Integration.
(line 3238)
* Hidden: Types for PostOperation.
(line 4138)
* Hypot: Extended math functions.
(line 2384)
* If ( EXPRESSIONCST ): Macros loops and conditionals.
(line 1347)
* Im: Type manipulation functions.
(line 2522)
* In: Formulation. (line 1795)
* In <1>: PostProcessing. (line 1976)
* Include: Includes. (line 622)
* IndexOfSystem: Formulation. (line 1795)
* Init: Types for Constraint.
(line 2958)
* InitFromResolution: Types for Constraint.
(line 2968)
* InitSolution: Types for Resolution.
(line 3444)
* InitSolution1: Types for Resolution.
(line 3456)
* Integral: PostProcessing. (line 1976)
* Integral <1>: Types for Formulation.
(line 3265)
* Integral <2>: Types for Formulation.
(line 3283)
* Integral <3>: Types for PostProcessing.
(line 3904)
* Integration: Integration. (line 1747)
* Integration <1>: Formulation. (line 1795)
* Integration <2>: PostProcessing. (line 1976)
* InterpolationAkima: Miscellaneous functions.
(line 2796)
* InterpolationBilinear: Miscellaneous functions.
(line 2785)
* InterpolationLinear: Miscellaneous functions.
(line 2773)
* Interval: Extended math functions.
(line 2457)
* Inv: Extended math functions.
(line 2411)
* Iso: Types for PostOperation.
(line 4190)
* Iso <1>: Types for PostOperation.
(line 4196)
* IterativeLinearSolver: Types for Resolution.
(line 3797)
* IterativeLoop: Types for Resolution.
(line 3757)
* IterativeLoopN: Types for Resolution.
(line 3767)
* JacNL: Types for Formulation.
(line 3312)
* Jacobian: Jacobian. (line 1704)
* Jacobian <1>: Formulation. (line 1795)
* Jacobian <2>: PostProcessing. (line 1976)
* Jn: Math functions. (line 2346)
* Lanczos: Types for Resolution.
(line 3672)
* Laplace: Green functions. (line 2477)
* LastTimeStepOnly: Types for PostOperation.
(line 4081)
* LevelTest: Macros loops and conditionals.
(line 1366)
* Lin: Types for Jacobian. (line 3150)
* Line: Types for Integration.
(line 3226)
* Link: Types for Constraint.
(line 2974)
* LinkCplx: Types for Constraint.
(line 3000)
* List: Constants. (line 693)
* ListAlt: Constants. (line 693)
* Local: PostProcessing. (line 1976)
* Local <1>: Types for Formulation.
(line 3273)
* Local <2>: Types for PostProcessing.
(line 3899)
* Log: Math functions. (line 2228)
* Log10: Math functions. (line 2233)
* Loop: Formulation. (line 1795)
* Macro ( EXPRESSIONCHAR , EXPRESSIONCHAR ) ;: Macros loops and conditionals.
(line 1296)
* Macro STRING  EXPRESSIONCHAR: Macros loops and conditionals.
(line 1286)
* Max: Math functions. (line 2335)
* Min: Math functions. (line 2330)
* MPI_Barrier: Types for Resolution.
(line 3879)
* MPI_BroadcastFields: Types for Resolution.
(line 3884)
* MPI_BroadcastVariables: Types for Resolution.
(line 3889)
* MPI_SetCommSelf: Types for Resolution.
(line 3869)
* MPI_SetCommWorld: Types for Resolution.
(line 3874)
* Name: Constraint. (line 1517)
* Name <1>: FunctionSpace. (line 1588)
* Name <2>: Jacobian. (line 1704)
* Name <3>: Integration. (line 1747)
* Name <4>: Formulation. (line 1795)
* Name <5>: Resolution. (line 1895)
* Name <6>: PostProcessing. (line 1976)
* Name <7>: PostOperation. (line 2038)
* Name  Label: Types for PostOperation.
(line 4025)
* NameOfBasisFunction: FunctionSpace. (line 1588)
* NameOfCoef: FunctionSpace. (line 1588)
* NameOfConstraint: FunctionSpace. (line 1588)
* NameOfConstraint <1>: Formulation. (line 1795)
* NameOfFormulation: Resolution. (line 1895)
* NameOfFormulation <1>: PostProcessing. (line 1976)
* NameOfMesh: Resolution. (line 1895)
* NameOfPostProcessing: PostOperation. (line 2038)
* NameOfSpace: Formulation. (line 1795)
* NameOfSystem: PostProcessing. (line 1976)
* Network: Formulation. (line 1795)
* Network <1>: Types for Constraint.
(line 2971)
* NeverDt: Types for Formulation.
(line 3321)
* Node: Formulation. (line 1795)
* NodesOf: Types for Group. (line 2137)
* NodeTable: Types for PostOperation.
(line 4320)
* NoMesh: Types for PostOperation.
(line 4114)
* NoNewLine: Types for PostOperation.
(line 4202)
* Norm: Extended math functions.
(line 2389)
* Normal: Miscellaneous functions.
(line 2706)
* NormalSource: Miscellaneous functions.
(line 2711)
* NumberOfPoints: Integration. (line 1747)
* OnBox: Types for PostOperation.
(line 3988)
* OnElementsOf: Types for PostOperation.
(line 3914)
* OnGlobal: Types for PostOperation.
(line 3926)
* OnGrid: Types for PostOperation.
(line 3938)
* OnGrid <1>: Types for PostOperation.
(line 3946)
* OnLine: Types for PostOperation.
(line 3967)
* OnPlane: Types for PostOperation.
(line 3977)
* OnPoint: Types for PostOperation.
(line 3961)
* OnRegion: Types for PostOperation.
(line 3921)
* OnSection: Types for PostOperation.
(line 3929)
* Operation: Resolution. (line 1895)
* Operation <1>: PostOperation. (line 2038)
* Order: Miscellaneous functions.
(line 2808)
* OriginSystem: Resolution. (line 1895)
* OverrideTimeStepValue: Types for PostOperation.
(line 4109)
* Parse [ EXPRESSIONCHAR ];: Macros loops and conditionals.
(line 1370)
* Period: Extended math functions.
(line 2451)
* Pi: Constants. (line 693)
* Point: Types for Integration.
(line 3247)
* PostOperation: PostOperation. (line 2038)
* PostOperation <1>: Types for Resolution.
(line 3801)
* PostProcessing: PostProcessing. (line 1976)
* Print: PostOperation. (line 2038)
* Print <1>: Types for Resolution.
(line 3642)
* Print <2>: Types for Resolution.
(line 3649)
* Printf: Miscellaneous functions.
(line 2695)
* Prism: Types for Integration.
(line 3241)
* Pyramid: Types for Integration.
(line 3244)
* Quadrangle: Types for Integration.
(line 3232)
* QuadraturePointIndex: Miscellaneous functions.
(line 2761)
* Quantity: FunctionSpace. (line 1588)
* Quantity <1>: Formulation. (line 1795)
* Quantity <2>: PostProcessing. (line 1976)
* Rand: Miscellaneous functions.
(line 2701)
* Re: Type manipulation functions.
(line 2517)
* ReadTable: Types for Resolution.
(line 3848)
* Region: Types for Group. (line 2130)
* Region <1>: Constraint. (line 1517)
* Region <2>: Jacobian. (line 1704)
* RemoveLastSolution: Types for Resolution.
(line 3552)
* RenameFile: Types for Resolution.
(line 3859)
* Residual: Types for Resolution.
(line 3489)
* Resolution: FunctionSpace. (line 1588)
* Resolution <1>: Resolution. (line 1895)
* Return: Macros loops and conditionals.
(line 1291)
* Rot: Fields. (line 1226)
* Rotate: Extended math functions.
(line 2421)
* SaveSolution: Types for Resolution.
(line 3539)
* SaveSolutions: Types for Resolution.
(line 3544)
* Scalar: Types for FunctionSpace.
(line 3030)
* ScalarField: Miscellaneous functions.
(line 2828)
* SendToServer: Types for PostOperation.
(line 4120)
* SendToServer <1>: Types for PostOperation.
(line 4126)
* SetDTime: Types for Resolution.
(line 3582)
* SetExtrapolationOrder: Types for Resolution.
(line 3636)
* SetFrequency: Types for Resolution.
(line 3587)
* SetGlobalSolverOptions: Types for Resolution.
(line 3346)
* SetNumberRunTime: Miscellaneous functions.
(line 2893)
* SetNumberRunTimeWithChoices: Miscellaneous functions.
(line 2898)
* SetRightHandSideAsSolution: Types for Resolution.
(line 3484)
* SetSolutionAsRightHandSide: Types for Resolution.
(line 3479)
* SetTime: Types for Resolution.
(line 3572)
* SetTimeStep: Types for Resolution.
(line 3577)
* SetVariable: Miscellaneous functions.
(line 2913)
* Sign: Math functions. (line 2340)
* SimpleTable: Types for PostOperation.
(line 4311)
* Sin: Math functions. (line 2243)
* Sinh: Math functions. (line 2282)
* Sin_wt_p: Extended math functions.
(line 2442)
* Skin: Types for PostOperation.
(line 4045)
* Sleep: Types for Resolution.
(line 3631)
* Smoothing: Types for PostOperation.
(line 4048)
* Solve: Types for Resolution.
(line 3335)
* SolveAgain: Types for Resolution.
(line 3340)
* SolveJac: Types for Resolution.
(line 3360)
* Solver: Resolution. (line 1895)
* Sort: Types for PostOperation.
(line 4184)
* Sqrt: Math functions. (line 2238)
* SquDyadicProduct: Type manipulation functions.
(line 2571)
* SquNorm: Extended math functions.
(line 2395)
* StoreInField: Types for PostOperation.
(line 4260)
* StoreInMeshBasedField: Types for PostOperation.
(line 4266)
* StoreInRegister: Types for PostOperation.
(line 4235)
* StoreInVariable: Types for PostOperation.
(line 4228)
* StoreMaxInRegister: Types for PostOperation.
(line 4242)
* StoreMaxXinRegister: Types for PostOperation.
(line 4251)
* StoreMaxYinRegister: Types for PostOperation.
(line 4252)
* StoreMaxZinRegister: Types for PostOperation.
(line 4253)
* StoreMinInRegister: Types for PostOperation.
(line 4241)
* StoreMinXinRegister: Types for PostOperation.
(line 4248)
* StoreMinYinRegister: Types for PostOperation.
(line 4249)
* StoreMinZinRegister: Types for PostOperation.
(line 4250)
* SubRegion: Constraint. (line 1517)
* SubSpace: FunctionSpace. (line 1588)
* Support: FunctionSpace. (line 1588)
* Sur: Types for Jacobian. (line 3146)
* SurAxi: Types for Jacobian. (line 3157)
* SurfaceArea: Miscellaneous functions.
(line 2733)
* SwapSolutionAndResidual: Types for Resolution.
(line 3434)
* SwapSolutionAndRightHandSide: Types for Resolution.
(line 3439)
* Symmetry: Formulation. (line 1795)
* System: Resolution. (line 1895)
* SystemCommand: Types for Resolution.
(line 3592)
* Table: Types for PostOperation.
(line 4301)
* Tan: Math functions. (line 2265)
* Tangent: Miscellaneous functions.
(line 2717)
* TangentSource: Miscellaneous functions.
(line 2722)
* Tanh: Math functions. (line 2292)
* TanhC2: Math functions. (line 2297)
* Target: Types for PostOperation.
(line 4172)
* Tensor: Type manipulation functions.
(line 2543)
* TensorDiag: Type manipulation functions.
(line 2566)
* TensorField: Miscellaneous functions.
(line 2843)
* TensorSym: Type manipulation functions.
(line 2561)
* TensorV: Type manipulation functions.
(line 2553)
* Test: Types for Resolution.
(line 3602)
* Test <1>: Types for Resolution.
(line 3608)
* Tetrahedron: Types for Integration.
(line 3235)
* TimeFunction: Constraint. (line 1517)
* TimeImagValue: Types for PostOperation.
(line 4076)
* TimeLegend: Types for PostOperation.
(line 4273)
* TimeLoopAdaptive: Types for Resolution.
(line 3725)
* TimeLoopNewmark: Types for Resolution.
(line 3714)
* TimeLoopTheta: Types for Resolution.
(line 3693)
* TimeStep: Types for PostOperation.
(line 4066)
* TimeTable: Types for PostOperation.
(line 4315)
* TimeValue: Types for PostOperation.
(line 4071)
* TransferSolution: Types for Resolution.
(line 3558)
* Transpose: Extended math functions.
(line 2406)
* Triangle: Types for Integration.
(line 3229)
* TTrace: Extended math functions.
(line 2428)
* Type: Constraint. (line 1517)
* Type <1>: FunctionSpace. (line 1588)
* Type <2>: Integration. (line 1747)
* Type <3>: Formulation. (line 1795)
* Type <4>: Resolution. (line 1895)
* Unit: Extended math functions.
(line 2400)
* Units: Types for PostOperation.
(line 4150)
* UnitVectorX: Type manipulation functions.
(line 2650)
* UnitVectorY: Type manipulation functions.
(line 2655)
* UnitVectorZ: Type manipulation functions.
(line 2660)
* Update: Types for Resolution.
(line 3395)
* Update <1>: Types for Resolution.
(line 3405)
* UpdateConstraint: Types for Resolution.
(line 3415)
* UsingPost: PostOperation. (line 2038)
* Value: PostProcessing. (line 1976)
* Value <1>: Types for PostOperation.
(line 4178)
* ValueFromIndex: Miscellaneous functions.
(line 2928)
* ValueFromTable: Miscellaneous functions.
(line 2940)
* Vector: Type manipulation functions.
(line 2538)
* Vector <1>: Types for FunctionSpace.
(line 3033)
* VectorField: Miscellaneous functions.
(line 2837)
* VectorFromIndex: Miscellaneous functions.
(line 2935)
* Vol: Types for Jacobian. (line 3143)
* VolAxi: Types for Jacobian. (line 3153)
* VolAxiRectShell: Types for Jacobian. (line 3200)
* VolAxiSphShell: Types for Jacobian. (line 3181)
* VolAxiSqu: Types for Jacobian. (line 3161)
* VolAxiSquRectShell: Types for Jacobian. (line 3206)
* VolAxiSquSphShell: Types for Jacobian. (line 3187)
* VolCylShell: Types for Jacobian. (line 3172)
* VolRectShell: Types for Jacobian. (line 3193)
* VolSphShell: Types for Jacobian. (line 3165)
* VolumesOf: Types for Group. (line 2152)
* While: Types for Resolution.
(line 3615)
* X: Coordinate functions.
(line 2670)
* XYZ: Coordinate functions.
(line 2685)
* Y: Coordinate functions.
(line 2675)
* Yn: Math functions. (line 2360)
* Z: Coordinate functions.
(line 2680)