Linkping Studies in Science and Technology

Thesis No. 990

PDEModelica - Towards a High-Level Language for

Modeling with Partial Differential Equations
by

Levon Saldamli

Submitted to the School of Engineering at Linkping University in partial

fulfilment of the requiremens for degree of Licentiate of Engineering
Department of Computer and Information Science
Linkpings universitet
SE-581 83 Linkping, Sweden
Linkping 2002

PDEModelica - Towards a High-Level Language for

Modeling with Partial Differential Equations
by
Levon Saldamli
Dec. 2002
ISBN 91-7373-560-4
Linkping Studies in Science and Technology
Thesis No. 990
ISSN 0280-7971
LiU-Tek-Lic-2002:63
ABSTRACT
This thesis describes initial language extensions to the Modelica language to define a more
general language called PDEModelica, with built-in support for modeling with partial
differential equations (PDEs). Modelica is a standardized modeling language for objectoriented, equation-based modeling. It also supports component-based modeling where
existing components with modified parameters can be combined into new models. The aim
of the language presented in this thesis is to maintain the advantages of Modelica and also
add partial differential equation support.
Partial differential equations can be defined using a coefficient-based approach, where a
predefined PDE is modified by changing its coefficient values. Language operators to
directly express PDEs in the language are also discussed. Furthermore, domain geometry
description is handled and language extensions to describe geometries are presented.
Boundary conditions, required for a complete PDE problem definition, are also handled.
A prototype implementation is described as well. The prototype includes a translator written
in the relational meta-language, RML, and interfaces to external software such as mesh
generators and PDE solvers, which are needed to solve PDE problems. Finally, a few
examples modeled with PDEModelica and solved using the prototype are presented.
This work has been supported by the Swedish Foundation for Strategic Research in the ECSEL graduate school and the VISIMOD project, the European Commission in the RealSim
project, and by Vinnova in the VISP project.

Department of Computer and Information Science

Linkpings universitet
SE-581 83 Linkping, Sweden

Acknowledgments
First of all I would like to thank my supervisor Peter Fritzson for the inspiration for doing the work and writing this thesis, and for improving my
writing. I would also like to thank Vadim Engelson, Bernhard Bachmann
and Mikael Adlers for their guidance during this work.
Many thanks go to my colleagues at PELAB (Programming Environments
Laboratory) for contributing to an interesting and stimulating environment
with lively and sometimes too long coee break discussions. In particular,
I would like to thank the members of the pelab-modelica group, and especially Peter Aronsson and Peter Bunus for many meetings and exchange
of ideas. Many thanks also to Andrzej Bednarski and Jon Edvardsson for
om for her help
LATEX support. Special thanks to Bodil Mattsson Kihlstr
with all the administrative issues. Also thanks to Lillemor Wallgren and
Bodil Carlsson at IDA for their support with other administrative tasks,
and to Ivan Rankin at IDA for language review of this thesis.
I would also like to thank the members of the Modelica Association, for
developing the Modelica language, and especially Hans-Ju
rg Wiesmann and
Hubertus Tummescheit for their ideas and comments on this work.

ii

Contents

1. Introduction
1.1. PDE-based Model Example . . .
1.1.1. Connection to ODE/DAE
1.2. Contributions . . . . . . . . . . .
1.3. Overview of the Thesis . . . . . .

. . . . .
models .
. . . . .
. . . . .

2. Background
2.1. Modelica . . . . . . . . . . . . . . . . . . .
2.2. Partial Dierential Equations . . . . . . .
2.2.1. Classication . . . . . . . . . . . .
2.3. Solution of Partial Dierential Equations
2.3.1. Finite Dierence Methods . . . . .
2.3.2. Finite Element Methods . . . . . .
2.3.3. Finite Volume Methods . . . . . .
2.3.4. Method of Lines . . . . . . . . . .

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

3. Related Work
3.1. Libraries and Programming Language-Based Packages .
3.1.1. Dipack . . . . . . . . . . . . . . . . . . . . . . .
3.1.2. Overture . . . . . . . . . . . . . . . . . . . . . .
3.1.3. Compose . . . . . . . . . . . . . . . . . . . . . .
3.2. High Level Packages and Problem Solving Environments
3.2.1. gPROMS . . . . . . . . . . . . . . . . . . . . . .
3.2.2. PELLPACK . . . . . . . . . . . . . . . . . . . . .
3.2.3. PDESpec . . . . . . . . . . . . . . . . . . . . . .
3.2.4. FEMLAB . . . . . . . . . . . . . . . . . . . . . .
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.

1
2
3
5
6

.
.
.
.
.
.
.
.

7
7
14
16
17
17
18
19
20

.
.
.
.
.
.
.
.
.
.

21
21
22
22
22
23
23
24
25
26
28

4. PDEModelica
31
4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2. PDE Problem Specication . . . . . . . . . . . . . . . . . . . 31
4.3. Domain Geometry Denition . . . . . . . . . . . . . . . . . . 32

iii

Contents
4.3.1.
4.3.2.
4.3.3.
4.4. Model
4.4.1.
4.4.2.

Boundary Description . . . . . . . . . . . . . .
Complex Domains . . . . . . . . . . . . . . . .
Domain Classes and Boundary Classes . . . . .
Denition . . . . . . . . . . . . . . . . . . . . .
Operators . . . . . . . . . . . . . . . . . . . . .
Hierarchical Denition of PDEs and Boundary
ditions . . . . . . . . . . . . . . . . . . . . . . .
4.4.3. Complete Model Denition . . . . . . . . . . .
4.5. Summary of Extensions in PDEModelica . . . . . . . .
5. Implementation
5.1. Modelica Parser . . . . . . . . . . . . . . . . .
5.1.1. PDEModelica Extensions . . . . . . .
5.2. Modelica Translator . . . . . . . . . . . . . .
5.2.1. RML . . . . . . . . . . . . . . . . . . .
5.2.2. Modelica Translator Specied in RML
5.2.3. PDEModelica Extensions . . . . . . .
5.2.4. Code Generation . . . . . . . . . . . .
5.3. Numerical Solver . . . . . . . . . . . . . . . .
5.3.1. Domain Discretization . . . . . . . . .
5.3.2. Mesh Generator . . . . . . . . . . . .
5.3.3. Finite Element Solver . . . . . . . . .
5.4. Future Extensions in the Implementation . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

. . . .
. . . .
. . . .
. . . .
. . . .
Con. . . .
. . . .
. . . .

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

32
35
36
37
37
39
42
43
45
45
48
49
50
51
52
56
62
62
63
64
68

6. Examples
69
6.1. Electrostatic Fields . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2. Static Currents . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3. Heat Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7. Conclusions and Future Work
7.1. Conclusions . . . . . . . . . . .
7.2. Future Work . . . . . . . . . .
7.2.1. Complex Domains . . .
7.2.2. Generalized Connectors
7.2.3. Expressing PDEs . . . .
7.2.4. Debugging . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

77
77
77
77
78
78
78

References

79

A. PDE Solver Using Rheolef

83

B. FEMLAB Domain Generation Interface Routine

87

iv

Contents
C. Problem Formulation Generated for FEMLAB

89

D. PDE Formulation Generated for Mathematica Based Solver

91

Contents

vi

Chapter 1.
Introduction
In mathematical modeling of a physical system, the behaviour of dierent
parts of the system is typically modeled using dierential equations or a
system of dierential and algebraic equations, i.e. algebraic equations containing derivatives.
For large scale models, some properties of the physical system that is
modeled are usually approximated; for example when controlling the temperature of a uid in a container, the temperature can be assumed to be
the same everywhere inside the container. This way, the space dependency
is eliminated, resulting in models containing only ordinary dierential equations (ODEs), or dierential and algebraic equations (DAEs), i.e. equations
where all derivatives are with respect to time. This greatly simplies the
solution of the equations and the simulation.
However, sometimes a more detailed model with explicit space dependency is needed for the whole system or some part of the system. Such
space-dependent models are used to study the behaviour on a smaller scale,
and contain partial derivatives, i.e. derivatives with respect to space variables
like x, y and z in a Cartesian coordinate system. Dierential equations containing partial derivatives are called partial dierential equations (PDEs),
and are used in many elds to model physical behaviour, for example structural mechanics, computational uid dynamics and electrostatics.
There are many tools for modeling and simulation with ordinary dierential equations as well as with partial dierential equations. However, most
of these tools are specialized for certain application domains or special kinds
of models.
An eort to dene a general, application domain and tool-independent
modeling language is made by Modelica Association, with the Modelica language as a result. Modelica [15, 27] is a standard language designed for
component-based modeling, where previously dened models can be reused
as components in new models. Object oriented constructs, equation-based
and declarative modeling support, as well as a connection concept make

Chapter 1. Introduction
this possible. Currently, the Modelica language only supports models with
ordinary dierential equations. Several Modelica implementations and simulation tools exist [2, 5, 16, 18].
Thanks to the progress in computer performance, the use of detailed models containing partial dierential equations is becoming increasingly common. The aim of this work is to dene a language based on Modelica, in
order to handle partial dierential equation based models in addition to differential and algebraic equation based models. This language is called PDEModelica, and this thesis discusses the initial language extensions needed for
the desired support.

1.1. PDE-based Model Example

Consider a simplied model of heat distribution in a rectangular room where
only the distribution in the x and y directions is studied and the temperature
in the z direction is assumed to be constant. A heater is installed on one
of the walls and there is a window on another wall. The domain of this
problem can be seen in Figure 1.1. A heater is represented by assigning
constant temperature to the middle part of the upper edge. The window
is modeled by a non-zero heat ow through the middle left edge that is
proportional to the temperature dierence between both sides of the edge.
The rest of the edges are modeled as insulated edges, i.e. no heat ow occurs
through these edges.
Heater
T = 30o C
Tout = 20o C
Window

Figure 1.1.: Example of stationary heat conduction.

The stationary heat conduction problem can be modeled using the Laplace
equation if no heat sources exist in the room. The boundary conditions are
the following:

1.1. PDE-based Model Example

a Dirichlet1 boundary condition for the heated wall,
a Neumann2 boundary condition for the insulated walls, and
a Robin3 (mixed) boundary condition for the window which is poorly
insulated.
This problem can be modeled in PDEModelica with the geometry and the
model description shown in Figure 1.2. The domain geometry is dened by
describing its boundary in a specic direction in order to nd out on what
side of the boundary the actual domain is. The boundary is built up of
several sections dened as named components in the domain description.
Hence, when dening the PDE model, boundary conditions can be assigned
to each section using the name of each boundary component. The denition
of the boundary conditions and the PDE are not shown in this example;
they can be dened as described in Chapter 4. The solution to a similar
example can be found in Section 6.3.

1.1.1. Connection to ODE/DAE models

The previous example shows a stationary model of heat conduction. Another application is to study the heat distribution over time, starting from
an initial state. A time derivative is then added to the Laplace equation.
Furthermore, using a time-dependent model, a system with active temperature control can be modeled. A temperature sensor can be approximated
by reading the computed temperature at some point in the domain, and the
temperature can be used as a signal to a controller that controls a heater.
The overview of the system is illustrated in Figure 1.3.
The controller is modeled by an ODE, resulting in a problem consisting
of a PDE part modeling the temperature distribution, and an ODE part
modeling the controller. This can be compared to a simplied system where
the temperature is assumed to be the same at all points. The temperature
distribution can then be modeled using an ODE based model, which results
in a complete system with only ODEs. Coupled ODE and PDE models are
needed in cases where some part of an ODE model is replaced with a PDE
model because the spatial variations are important for the model.
This example is simplied by the fact that the sensor is replaced with a
simple result reading. In other situations, the connection between the PDE
1 Value

of the unknown variable known on the boundary. See also Section 2.2.
of the outward normal derivative of the unknown variable is known on the boundary. The outward normal derivative is the space derivative in the outward normal
direction. See also Section 2.2.
3 The sum of the unknown variable and its outward normal derivative is known on the
boundary. See also Section 2.2.
2 Value

Chapter 1. Introduction

domain Rectangular "Geometry"

Line2D right (x0= 3,
y0=-2,
x1= 3, y1= 2);
Line2D top1 (x0=right.x1, y0=right.y1, x1= 1, y1= 2);
Line2D top2 (x0=top1.x1, y0=top1.y1, x1=-1, y1= 2);
Line2D top3 (x0=top2.x1, y0=top2.y1, x1=-3, y1= 2);
Line2D left1 (x0=top3.x1, y0=top3.y1, x1=-3, y1= 1);
Line2D left2 (x0=left1.x1, y0=left1.y1, x1=-3, y1=-1);
Line2D left3 (x0=left2.x1, y0=left2.y1, x1=-3, y1=-2);
Line2D bottom(x0=left3.x1, y0=left3.y1, x1= 3, y1=-2);
boundary
composite(right, top1, top2, top3, left1, left2, left3, bottom);
end Rectangular;
model PDEModel "Equations and boundary conditions"
HeatRobin heatloss(Tout=20);
Dirichlet constheat(c=30);
Neumann isolated;
HeatConduction ht;
Rectangular dom;
equation
dom.eq = ht;
dom.left1.bc = isolated;
dom.left2.bc = bc_robin;
dom.left3.bc = isolated;
dom.right.bc = isolated;
dom.top1.bc = isolated;
dom.top2.bc = constheat;
dom.top3.bc = isolated;
dom.bottom.bc = isolated;
end PDEModel;

Figure 1.2.: The PDEModelica code to dene the heat conduction problem
in Section 1.1. Predened PDE and boundary condition models
have been left out. The syntax is explained in Chapter 4.

1.2. Contributions
model and the ODE model can be more complex. Chapter 7 discusses future
work on this issue.
Coupled models are not yet fully supported in the implementation, see Section 5.4 for details.
Controller

Heater
T = 30o C
Tout = 20o C
Window

Sensor

Figure 1.3.: A coupled PDE and ODE model. Time dependent heat transfer
model with a controller.

1.2. Contributions
The result of this work is preliminary design and implementation of an
object-oriented modeling language, PDEModelica, with support for
object-oriented modeling with PDEs and boundary conditions,
complex geometry description with lines, polygons, parametric curves
and a combination of these,
component-based geometry denition,
hierarchical modeling and decomposition with a general connection
concept, and
modeling of combined ODE/DAE and PDE problems.

Chapter 1. Introduction
We believe that the combination of these aspects in a single language is
rather new.
A prototype translator and solver environment is set up as well, with a
basic PDE solver interface for adding new solvers and mesh generators.
Some of the work discussed in this thesis has been published previously
in the following publications:
1. L. Saldamli and P. Fritzson. Object-Oriented Modeling with Partial
Dierential Equations. In Proceedings of the Modelica Workshop 2000,
Lund, Sweden, October 2000 [35].
2. L. Saldamli and P. Fritzson. A Modelica-Based Language for ObjectOriented Modeling with Partial Dierential Equations. In Proceedings
of the 4th International EUROSIM Congress, Delft, The Netherlands,
June 2001 [37].
3. L. Saldamli and P. Fritzson. Domains and Partial Dierential Equations in Modelica. In Proceedings of the 42nd SIMS Conference, Porsgrunn, Norway, October 2001 [36].
4. L. Saldamli, P. Fritzson and B. Bachmann. Extending Modelica for
Partial Dierential Equations. In Proceedings of the 2nd International
Modelica Conference, Oberpfaenhofen, Germany, March 2002 [38].

1.3. Overview of the Thesis

The thesis is organized as follows. Chapter 2 contains background information relevant for the thesis: a short overview of the Modelica language, a
basic introduction to partial dierential equations and some existing numerical solution methods for partial dierential equations.
Chapter 3 presents an overview of related work. Dierent low-level and
high-level tools with varying modeling language support are summarized.
Chapter 4 describes the main work and goes through the extensions to
the Modelica language for domain description and PDE denition.
Chapter 5 provides the details about the implementation of the prototype,
which implements the extensions dened in Chapter 4.
Chapter 6 contains examples with the PDEModelica code and the solutions.
Finally, in Chapter 7 some conclusions and possible future work directions
are discussed.

Chapter 2.
Background
The basic concepts of Modelica are presented in the rst part of this chapter. In the second part, the topic of partial dierential equations (PDEs)
and classication of PDEs are briey presented, and nally an overview of
dierent numerical solution methods is given.

2.1. Modelica
Modelica [17, 27] is a modeling language for equation-based, object-oriented
modeling and simulation of physical systems. Using object-oriented concepts, it allows hierarchical, component-based modeling which in turn makes
reuse of existing models possible. The general modeling concepts in Modelica allow it to be used in dierent application domains and in multi-domain
modeling, for example when dening a combined electrical and mechanical
model. There is a free Modelica Standard Library [28] and other free Modelica libraries with packages of existing models from dierent domains that
can be used as components in specic models. Non-causal modeling, i.e.
modeling using equations - not assignment statements, allows single models
to be used in dierent data ow contexts since variables are not explicitly
declared as input or output but this information is rather derived from the
context where the model is used. In his PhD thesis, H. Tummescheit [45]
discusses design and implementation of modeling libraries using Modelica.
Models in Modelica are hierarchically built from submodels that are dened separately, which in turn can be built in the same way. Hence, a model
can contain one or more instances of other models with dierent set of parameter values for each instance, and a set of connections between these
components. Additionally, each model can have variables of built-in types,
and equations that dene the relationship between these variables and also
between variables in submodels.

Chapter 2. Background
Classes
The basic structural unit in Modelica is class. A class can contain other
classes, variable declarations, equations and algorithms. An example of a
class can be seen in Figure 2.1. Other keywords can be used to denote classes,
restricted classes that are special cases of classes with some restrictions.
These are record, type, connector, model, block, package and function.
Dierent restricted classes and restrictions that apply to them can be seen
in Table 2.1.
model MyModel "Short description of this model"
Real x,y;
equation
x + y = 5;
x + 2y = 11;
end MyModel;

Figure 2.1.: Example of a Modelica class.

Table 2.1.: Restricted classes in Modelica.

Restricted class
record
type
connector
model
block
package
function

Restrictions
No equations are allowed.
May only be used to extend primitive types.
No equations are allowed.
Model instances may not be used in connections.
Fixed causality. Each variable must be declared
as input or output.
May only contain classes and constants. Is allowed
to import from.
Similar to block. No equations, at most one algorithm
section. May be called using positional arguments.
May be recursive.

Variable Declarations
Variable declarations consist of a type and a variable name. The type can
be one of the primitive types or another class name. The primitive types
are Real, Integer, String, Boolean and Enumeration. Each declaration
can also have type modiers, such as the type variability prex constant,
discrete, or parameter, or a causality prex, input or output.

2.1. Modelica
Variables with the constant or parameter prex keep their value constant during a simulation, i.e. they are constants. The dierence between
parameters and constants is that values of parameters can be changed before
each simulation without needing to recompile the Modelica code. Variables
of type Real declared without the constant or parameter modiers are implicitly time-dependent, i.e. functions of time. Time derivatives of variables
can be represented using the der() operator. Using the time derivatives, ordinary dierential equations can be expressed, and full systems of dierential
and algebraic equations (DAEs) can be specied.
Subtyping and Inheritance
Modelica models can be dened using inheritance. The extends clause is
used together with a class name to inherit that class. Multiple inheritance
is allowed using several extends clauses, one for each inherited class. Inheritance is equivalent to inserting the contents of the inherited class at the
place where the extends clause resides.
Type equivalence in Modelica is dened as follows: Two types T and U
are equivalent if
they denote the same primitive type (see previous section), or
T and U are classes containing the same elements (according to their
names) and the elements types are equivalent.
Subtypes in Modelica are dened independently from the inheritance
mechanism. A class C is a subtype of a class S if
S and C are type equivalent, or
both of the following statements hold:
every public element of S also exists in C (according to its name).
the type of each such element in C is a subtype of the type of the
corresponding element in S.
If a class C is a subtype of a class S then S is called the supertype of C.
Subtypes and supertypes do not necessarily need to be in an inheritance
hierarchy, but a class that is inherited from, a base class, is a supertype of a
class that inherits from it, a derived class. An example is shown in Figure 2.2.
The TempResistor class cannot extend the Resistor class because it
has a dierent equation in the equation section, but it is still a subtype of

Chapter 2. Background

partial model OnePort

Pin p,n;
Voltage v "Voltage drop";
equation
v = p.v - n.v;
p.i + n.i = 0;
end OnePort;
model Resistor;
extends OnePort;
parameter Real R(unit="Ohm") "Resistance";
equation
v = p.i * R;
end Resistor;
model TempResistor "Temperature dependent resistor"
extends OnePort;
parameter Real R(unit="Ohm") "Resistance at reference temperature";
parameter Real RT(unit="Ohm/degC") = 0 "Temperature dependent resistance";
parameter Real Tref(unit="degC") = 20 "Reference temperature";
Real Temp = 20 "Actual temperature";
equation
v = p.i * (R + RT * (Temp - Tref));
end TempResistor;

Figure 2.2.: Subtyping in Modelica. TempResistor does not inherit from

Resistor, but it is a subtype of Resistor. They both inherit
from OnePort.

10

2.1. Modelica
Resistor because it contains all the elements in Resistor, and additional
elements. Both classes inherit from the OnePort1 class, though.

Modications
Modications in Modelica are used to modify parameter values when declaring instances of classes. Since models are built up hierarchically, modications can be overridden, in which case the topmost (outermost) modication
is applied. A modication can also be hierarchical, in order to modify a lower
level parameter directly. Each modication consists of a component reference and an expression that is evaluated in the context where the declaration
resides. Example of modications can be seen in Figure 2.3. Declarations
preceded by the final keyword are nal elements and cannot be modied
using modications. The final keyword can also precede modications, in
which case it prevents further modications of that variable in outer modications.
model ModelA
parameter Real pa = 0; // default value
end ModelA;
model ModelB
ModelA compa(pa=1);
// modification
parameter Real pb = 0;
end ModelB;
model MyModel
parameter Real mypa=3, mypb=4;
ModelB compb(pb=mypb, compa(pa=mypa)); // hierarchical modification
end MyModel;

Figure 2.3.: Modications in Modelica. The resulting value of the variable

compb.compa.pa is mypa, i.e. 3.
Modication can also be applied when extending another class, together
with the extends clause. For example:
model MyNewModel
extends MyModel(mypb=5);
When instantiating components of MyNewModel the default value of mypb
will be 5.
1 The

term OnePort is used by specialists in the electrical modeling community to denote

electrical components with two physical connection points.

11

Chapter 2. Background
Equations and Algorithms
The keywords equation and algorithm denote equation and algorithm sections, respectively. There can be several such sections of each kind in a class.
During compilation, all equation sections are merged into a single equations
section.
Equation sections can contain standard equation clauses, connect equations, conditional equations, for equations and when equations. Standard
equations consist of two expressions and the equality operator denoted by
=. The assignment operator := is not allowed in equation sections, whereas
the equality operator = is not allowed in algorithm sections. Besides the
common operators like arithmetic operators and function calls, Modelica
has if-expressions, which can be used in situations like:
equation
x = if (z > 0) 2*z else (-2*z);
Connect equations consist of the connect() operator with two arguments
that are references to connectors. Connectors are instances of connector
restricted classes and usually contain two kinds of variables, ow (e.g. current) and non-ow (e.g. potential) variables, the former being denoted by
the flow keyword. Connect equations are translated into standard equations during compilation, where for each connection the non-ow variables
of the involved connectors are set equal, and the sum of all the ow variables
is set to be equal to zero. Figure 2.4 illustrates the use of connectors and
connections, and the resulting equations.
Conditional equations are written using the if-elseif-else construct
with equations in the body. for equations are useful for repetitive equation structures involving arrays. when clauses are used for discrete event
simulation.
Algorithm section can contain assignments, conditional statements, forloops, while-loops and when-statements. The dierence from equation sections is that algorithm sections contain assignments instead of equations,
and the contents of the algorithms are executed sequentially. An assignment consists of a variable reference, the assignment operator := and an
expression.
Replaceable Elements
Elements in classes in Modelica can be declared as replaceable, in which
case they can be replaced by another type of element that is type compatible
when the containing class is extended or instantiated. Generic classes with
type parameters is supported in Modelica through the replaceable mechanism.

12

2.1. Modelica

B
p

p
C
(a) Visual view of a connector and connection example.

connector Pin "Electrical pin"

flow Current i;
Voltage v;
end Pin;
model OnePin
Pin p;
end OnePin;
model Test
OnePin a, b, c;
equation
connect(a.p, b.p);
connect(b.p, c.p);
end Test;
(b) Textual view of a connector and connection example.

equation
a.p.i + b.p.i + c.p.i = 0;
a.p.v = b.p.v;
b.p.v = c.p.v;
(c) Resulting equations

Figure 2.4.: Example of connectors and connections and the resulting simple
equations after compilation.

13

Chapter 2. Background
The type restriction of a redeclaration is that the new declared type must
be a subtype of the original declared type, a constraining type.

2.2. Partial Dierential Equations

Dierential equations are commonly used in mathematical models of physical
phenomena that are distributed in time and/or space. Examples include
heat transfer, uid ow, structural mechanics, wave propagation, etc. Such
mathematical models relate certain variables, dependent variables and their
derivatives, to other variables, independent variables.
In some cases a variable that is distributed in space and/or time, e.g. a
temperature eld, can be approximated by a scalar variable. For example,
when the temperature of a uid in a container is studied, the temperature could be assumed to be the same throughout the entire container at
each specic time instant, and one can study the temperature change as a
function of time based on the incoming and outgoing uid ow. Since the
simplied model depends only on one variable, time, derivatives that occur
are time derivatives, and the equations of the model are ordinary dierential
equations (ODEs).
In more complex models when the temperature distribution over the container is studied with a dierent temperature at dierent positions inside
the container, the temperature is a function of the independent variables
representing the space coordinates inside the container, and also of the time
variable if time-dependent behaviour is studied. Derivatives that occur in
such models are partial derivatives with respect to one of the variables, the
space coordinates or time.
Dierential equations involving partial derivatives are thus called partial
dierential equations (PDEs). If time dependency is present, the models are
called time-dependent problems, otherwise stationary.
The order of a partial dierential equation is dened to be the highest
dierentiation order that occurs in that equation. The most commonly
used PDEs in models of many practical systems are second-order PDEs,
containing second order derivatives. A partial derivative can be stated in
dierent ways. The rst-order partial derivative of a dependent variable u
with respect to the independent variable x is represented using the following
three variants of mathematical notation:
u
= x u = ux
x
A second order derivative can be written accordingly as
2u
= xx u = uxx
x2

14

2.2. Partial Dierential Equations

The second dierentiation can be done with respect to a dierent variable y
than the rst dierentiation, e.g. xy u = uxy , which is also a second order
derivative, a mixed partial derivative.
A general, second order PDE with an unknown dependent variable u and
the independent variables x and y can be stated as
f (u, ux , uxx , uy , uyy , uxy , uyx , x, y) = 0

(2.1)

The denition domain, i.e. the geometric region on which the PDE is dened, denoted , is in most cases a closed region in space as dened by the
independent variables, see Figure 2.5.

Figure 2.5.: The denition domain , its boundary and the outward
normal vector n.
Boundary conditions in a PDE problem specify the behaviour of the model
on the boundary of the domain , denoted , and usually contain derivatives of one order less than the PDE. A general boundary condition corresponding to equation (2.1) can be expressed as
g(u, ux, x) = 0

(2.2)

Boundary conditions usually contain a directional derivative instead of the

partial derivative with respect to one variable. A common directional derivative is the outward normal derivative, which is obtained by the scalar product
of the outward normal on the domain boundary and a vector of the partial
derivatives. The outward normal derivative is denoted n and is commonly
used in boundary conditions to specify e.g. heat ux through the boundary.
Three kinds of boundary conditions that often occur have been given
special names:
Dirichlet :

u=g

on

N eumann :

n u

=g

Robin :

n u

+ qu = g

on
on

15

Chapter 2. Background
In cases where the right-hand side is zero, the corresponding condition is
called homogeneous, otherwise non-homogeneous.

2.2.1. Classication
PDEs are classied based on linearity properties. An equation expressed
using the linear operator2 L() in the form
L(u + v) = 0
is linear if
L(u + v) = L(u) + L(v)
If a PDE with the dependent variable u and the independent variables x
and y can be expressed in the following form:
auxx + 2buxy + cuyy = d

(2.3)

where the coecients a, b and c are constants, the PDE is linear. If the
coecients are functions of the independent variables only, x and y in this
example, the PDE is semi-linear, and if the coecients also depend on u or
its rst-order derivatives the PDE is quasi-linear. Equations that cannot be
expressed linearly in the second order derivatives as in equation (2.1) are
nonlinear. In this text, semi-linear PDEs will be regarded as linear, while
quasi-linear PDEs will be classied together with the nonlinear.
If a > 0, Equation (2.3) is classied further into three categories depending
on the value of b2 ac:
Elliptic :

b2 ac < 0

P arabolic :

b2 ac = 0

Hyperbolic :

b2 ac > 0

Elliptic equations typically occur in stationary heat conduction models,

whereas parabolic equations arise in time-dependent models. The wave
equation used for modeling propagation of waves such as sound waves in
gas or electro-magnetic waves is an example of a hyperbolic equation.
2 An

16

example of a linear operator is the derivative operator.

2.3. Solution of Partial Dierential Equations

2.3. Solution of Partial Dierential Equations

A very small number of PDE problems can be solved symbolically, and even
fewer of these are solvable with practically useful boundary conditions. For
this reason, much research has been done on numerical solution of PDEs
and dierent methods have been developed. Unlike for solution of ordinary
dierential equations, there is no unied method for solution of general PDE
problems, however, and an appropriate numerical solver must be selected for
the specic kind PDE being solved.
The solution method depends on whether a stationary or a time-dependent
PDE is solved. Only space discretization is needed for stationary problems,
whereas time-dependent problems need both space and time discretization.
The methods described below, except Section 2.3.4, are used for space discretization. Time discretization can be done using for example nite dierences, or the PDE can be discretized in space rst and the resulting ODEs
can be solved with traditional ODE solvers, as described in Section 2.3.4.

2.3.1. Finite Dierence Methods

In order to nd the unknown function, the domain, i.e. the geometry on
which the problem is dened is discretized into a set of grid points and the
values of the function at these points are calculated. When the domain is
discretized, the partial derivatives can be approximated by equations using
the values at the grid points. Using Taylors theorem, dierent approximations can be derived [43]. The rst-order derivative of u with respect to x
using a grid with the distance h between the points can be approximated by
for instance:
u(x + h) u(x h)
u
=
+ O(h2 )
x
2h
Here, O(h2 ) represents the approximation error. This equation is called a
central-dierence approximation. Other approximations can be derived, for
example
u(x + h) u(x)
u

x
h
which is called a forward-dierence formula, and
u
u(x) u(x h)

x
h
which is called a backward-dierence formula. Higher-order derivatives can
be approximated similarly. The derivatives in the PDE are then replaced by
the approximations and repeated for each grid point, generating an equation
system with the values of u at the grid points as unknowns. The boundary

17

Chapter 2. Background
conditions are applied at the grid points neighboring the boundary, depending on the kind of boundary conditions. With Dirichlet boundary conditions,
the values on the boundary are known and can be used directly. With Neumann and Robin conditions, the derivative is approximated in the same way
as in the PDE and equations involving the grid points outside the domain are
generated, that can be used to express the unknown values on the boundary.
When solving time-dependent problems, the time derivatives can be approximated with nite dierences as well. Note however, that when using
nite dierence methods, the discretization steps must be chosen according
to certain conditions in order to maintain stability.

2.3.2. Finite Element Methods

A common way of solving a PDE numerically is to approximate the dependent variable U with a series of known basis functions, also known as trial
functions, and then to nd out the coecients that satisfy the equation as
well as possible, by minimizing the error introduced by the approximation.
of u can be stated
If the basis functions are denoted vk , the approximation u
as:
N


ak vk (x)
(2.4)
u
(x) =
k=0

Dierent solution methods use dierent norms of how close the approximation is to the unknown function, when calculating the coecients. Since
there are a nite number of basis functions and nite number of unknown
coecients, it is possible to numerically calculate the coecients, given the
PDE and known values at some points, i.e. the boundary conditions.
The Galerkin method is a basic method for calculating the unknown coecients. For a partial dierential equation of the form
L(u(x)) = 0
where L() is a linear operator containing u and its derivatives, a residual
error R of an approximation u
is dened by
R(
u(x)) = L(
u(x))
The residual error measures how well the approximation satises the partial
dierential equation. If it is identical to zero, i.e. R(
u(x)) 0 for all x in
the domain, then the approximation is the exact solution. A criterion for
measuring how close a function is to being zero is to look at its orthogonality
to a chosen set of functions. Orthogonality of two functions f (x) and g(x)
is dened as

f (x)g(x) dx = 0

18

2.3. Solution of Partial Dierential Equations

The residual of the exact solution R(u(x)) is orthogonal to all functions
according to this denition. The residual of the approximation is checked
against a set of test functions from an appropriate test space. It is sucient
to check the basis vectors of the test space to assure orthogonality to all
functions in the test space.
The Galerkin method uses the trial space as the test space as well, and
the basis functions vk are used as the test functions:

R(
u(x))vk (x) dx

k = 0..N

Substituting u
with its denition in (2.4) and calculating the integrals gives
an equation system that can be solved to nally obtain the coecients to
the trial functions and the approximation to the solution.
The selection of the trial and test functions lead to dierent solution methods. Using polynomials as basis functions for the trial space requires global
support from the polynomials, because each basis function contributes to
the entire domain. In order to increase the accuracy of the approximation
the degree of the polynomials must be increased.
A more exible method is to divide the domain into m subdomains and
use basis functions with local support, where each function vk is zero outside
of one subdomain and its neighboring domains. This method is called the
nite element method, elements being the subdomains, and can be applied to
the dierent solution methods using dierent test functions. Usually lower
order polynomials can be used because local support simplies the approximation. Instead of polynomials of higher degree, smaller elements can be
used for better approximation, especially for the parts of the domain where
the solution has steep changes. Subdivision of the domain can be performed
in dierent ways, triangulation being a common method. Adaptive triangulation can also be used, to rene the mesh iteratively on parts of the solution
where the error is too large.

2.3.3. Finite Volume Methods

As with the nite element method the domain is discretized with a mesh
generator. Then, a control volume is dened over each grid point, such that
the control volumes do not overlap, and the PDE is integrated over each
control volume. This integral can be approximated by nite dierences of
adjacent grid points. The result is a discretization equation with the values
of the dependent variable on the grid points.

19

Chapter 2. Background

2.3.4. Method of Lines

The method of lines is a solution method that converts a PDE into a set of
ODEs involving only time-dependent functions and time-derivatives. The
conversion is done by discretizing the PDE in space, leaving a number of
unknowns and their time derivatives. For the space discretization, any of the
methods described earlier can be used. For example, if the nite dierence
method is used, the space discretization leads to one unknown and its time
derivative at each grid point on the domain, i.e. a set of ODEs.
One advantage of the method of lines is that advanced numerical solution
methods exist for solving general ODEs that do not yet exist for PDEs.
There are, for instance, solvers with automatic step adjustment to nd a
solution with required accuracy. Another advantage is that coupled systems
containing both ODE and PDE based models become easier to solve because
the space discretization of the PDEs results in ODEs that can be solved
together with the already existing ODEs.
One disadvantage, though, is that the space discretization is independent
of the error controlled step adjustment that is done in the ODE solution
process. Thus, even though the ODE solver solves the given ODEs with a
desired accurately, error introduced during the space discretization can be
much larger if space discretization is performed without caution.
Also, the relation between the step sizes in the space and time domain
must fulll certain criteria in order to get a numerically stable solution.
However, this is not checked by a pure ODE solver.

20

Chapter 3.
Related Work
This chapter contains an overview of work done on tools for modeling and
simulation of partial dierential equation based models, categorized by the
user interaction level. The rst category of tools requires the user to write the
problem formulation and the solution algorithm in an ordinary programming
language such as Fortran, C or C++, with library support from the tool.
The second category provides a high-level interface, a problem description
language or a graphical user interface, where the problem can be specied.

3.1. Libraries and Programming Language-Based

Packages
There exist several libraries of PDE solver algorithms with solver routines
suitable for dierent PDE problems. When using these libraries the PDE
problem is formulated by dening the appropriate functions and data structures and solved by calling the appropriate solver routine. Programming
experience and knowledge of programming languages is required to use such
libraries. Mathematical and numerical knowledge is also needed to use appropriate solution methods. Repositories of solution algorithms exist, for
example Netlib [29], with many stand-alone subroutines that are freely available for download. There are also commercial library packages, such as Dipack [12], specialized for solving PDE problems with support for both nite
dierence and nite element methods.
Some PDE solver packages are written as frameworks, usually in objectoriented languages, with a level of abstraction that is higher than just using
solver libraries directly. A specic PDE problem is solved by a program written in a programming language, usually C++ for object-oriented packages.
Classes and objects from the framework are used directly in the program, or
new extension classes are added to the framework and subsequently used.

21

Chapter 3. Related Work

3.1.1. Dipack
Dipack [12] is a C++ library package with data structures and numerical
methods that are used to solve PDE problems. The package is divided into
a kernel and application-specic toolboxes for use in dierent engineering
areas. Dipack includes support for solving sparse linear systems using iterative methods and solving non-linear systems, using nite element and nite
dierence methods with a collection of nite elements and nite dierence
schemes, adaptive meshes, domain decomposition methods and multi-grid
methods. The package also includes support for administrative tasks, such as
report generation, simulation result handling and data entry using a graphical user interface.

3.1.2. Overture
Overture [32] is a framework for writing PDE solvers in C++ using nite difference or nite volume methods. Built-in classes are used to represent domains, discretized domains, dierentiation operators, solution vectors, and
other data needed in a PDE solver system. The framework also includes grid
generators, solvers, and graphical interface classes for plotting the results.
Overture uses overlapping grids to support composition of domain geometries. A grid generator is used to generate overlapping grids which are
used for domains composed of several domain components. In a composite domain, common grid points are generated for the overlapping parts of
the domain components that comprise the nal domain. This method is also
useful for moving overlapping grids where the domain components move over
time, in which case the grid is regenerated each time a domain component
is moved.

3.1.3. Compose
Compose [44] is an object-oriented framework built on top of Overture. The
Compose framework has been developed using object-oriented analysis, design and implementation, with the objective of separating the classes used
for problem formulation from the classes concerned with the numerical solution process. Hence, the equation classes, domain classes, and other classes
that represent the mathematical model are separated from classes that handle discretization and solution of the PDEs. Thus, compared to Overture,
where the formulation of the mathematical model and the numerical solution
method are more tightly coupled, Compose has a higher level of abstraction.
However, there is no automatic solver selection support in Compose compared to many problem solving environments. Equations and equation dis-

22

3.2. High Level Packages and Problem Solving Environments

cretizers must be associated for an equation to be discretized appropriately.
The framework is extensible, so that new types of equations and corresponding equation discretizers can be added to the system.

3.2. High Level Packages and Problem Solving

Environments
One of the rst attempts to dene a language for PDE problem formulation
was PDEL [10]. In modern high-level language based or graphical user
interface based PDE solving systems, the PDE and boundary conditions
are specied directly, either in text form in a special purpose language or
interactively in a specialized editor. The system automatically solves the
PDE problem using a general solver or by selecting an appropriate solver
from a set of existing solvers. The details about the solution process can be
hidden from the user, although it is still possible to manually direct a solver
or to select a solver to use.

3.2.1. gPROMS
gPROMS is a general process modeling system for dynamic simulation of
chemical processes, with support for combined lumped and distributed models [30]. gPROMS uses a high-level language for modeling and simulation of
mixed systems of integral, partial, and ordinary dierential, and algebraic
equations (IPDAEs) over rectangular domains.
MODEL TubularReactor
PARAMETER
NbrComp
...
ReactorLength, ReactorRadius
DISTRIBUTION_DOMAIN
Axial
Radial

AS INTEGER
AS REAL

AS ( 0 : ReactorLength )
AS ( 0 : ReactorRadius )

Figure 3.1.: Example of a model denition in gPROMS.

A model denition in the gPROMS language is depicted in Figure 3.1.
Axial and Radial in the model are the independent variables.
A dependent variable that is to be solved over this domain is declared as
follows:

23

Chapter 3. Related Work

VARIABLE
Temp

AS DISTRIBUTION (Axial, Radial) OF Temperature

Here, Temp is of type Temperature that is dened elsewhere, and its geometric domain is the three-dimensional area dened by the independent
variables Axial and Radial and their limits as dened in Figure 3.1. This
declaration is similar to declaration of arrays in the gPROMS language,
which is done using the array keyword:
F

AS ARRAY ( NbrComp )

OF Flowrate

For partial dierentiation the partial operator is used. partial(expr,

var) is the partial derivative of the expression expr with respect to the
variable var (i.e. r T emp(z, R)), i.e. the partial operator supports dierentiation of entire expressions, not only single variables.
For loops are used for restricting the applicability of an expression or
equation to a part of the domain. An example can be seen in Figure 3.2,
where a boundary condition is dened for the wall of the tubular reactor,
which has an axial distribution but not radial. The boundary condition
applies for values of z between 0 and ReactorLength.
FOR z:= 0 TO ReactorLength DO
- Kr * PARTIAL( Temp(z, ReactorRadius), Radial) =
Uh * ( Temp(z, ReactorRadius) - TWall(z) );
END

Figure 3.2.: For loops for restricting an equation to part of a domain as

specied in gPROMS.

3.2.2. PELLPACK
PELLPACK [19] is a problem solving environment for specication, solution
and post-processing of PDE problems. A PDE language is used to specify
the PDE, the domain geometry, the boundary conditions, the discretization
method, the solution method, and other method-specic parameters that
are needed to solve the problem. There are also tools providing graphical
user interfaces for specifying dierent parts of the problem, from which the
specication in the same PDE language is generated.
The PDE language used in PELLPACK is an extension of the ELLPACK
language. The ELLPACK language is divided into sections where the PDE
problem is specied and the solution method is selected. The equation
section contains the PDE written in mathematical form. The boundary
section denes the geometry by dening the domain boundary. The boundary conditions are also written in the boundary section together with the

24

3.2. High Level Packages and Problem Solving Environments

domain boundary descriptions. Other sections are grid, discretization,
solution and output which specify the modules to use in dierent stages
of the solution process.
The ELLPACK language also supports embedded Fortran code in fortran
sections. The PELLPACK language additionally has the mesh section to
support the nite-element method, and sections for domain decomposition
to support parallel solutions. The language is also extended to contain
information produced from the graphical user interface that needs to be
preserved.
In the ELLPACK language, there are predened names for the solution
variable and its derivatives, such as U, UX (x U ), UYY (yy U ) and the spatial variables X, Y and Z. These variables are used to specify the PDE. For
example:
EQUATION.

UXX + UYY

+ 3.0*UX - 4.0*U = EXP(X+Y)*SIN(PI*X)

The boundary conditions can be specied in dierent ways, using lines and
parametric curves. A circular domain is dened as in Figure 3.3, where the
boundary section species the condition that the function is zero on a circle
with radius 1 and center (1, 1). The boundary statement also denes the geometry of the problem. The equation and boundary parts of an ELLPACK
program are declarative, whereas the rest grid, discretization, fortran
etc., are executed in a sequential order.
BOUNDARY.

U = 0.0 ON

X = 1. - COS(PI*THETA), &
Y = 1. - SIN(PI*THETA) &
FOR THETA = 0. TO 2.

Figure 3.3.: Domain denition and boundary condition assignment in ELLPACK.

The PDE and the boundary conditions written in the PDE language are
symbolically processed using the Macsyma [24] symbolic system. Procedural (Fortran) code is generated and linked with the selected libraries and
executed. The PELLPACK system contains libraries of modules for the different steps of the solution process, such as domain discretization modules
and PDE solver libraries. There are several integrated libraries that are
ready to use in the system. It is also possible to integrate new libraries by
writing the appropriate interfaces on dierent levels of the software architecture.

3.2.3. PDESpec
S. Weerawarana [46] presents a high-level language PDESpec where the PDE
problem is specied using objects. Dierent types of objects are equation, do-

25

Chapter 3. Related Work

main, boundary condition, initial condition, mesh, decomposition, algorithm,
solve and solution. Figure 3.4 shows an example of an equation object describing the steady-state heat ow, where T x represents x T and Dx(A) is
an alias for diff(A, x) which represents x (A). Aliases, the dimension of
the problem, and names of the independent variables are dened as defaults
for equation objects. The domain dome is dened as a separate object, as
well as the boundary conditions and their equations. The denition of the
domain object can be seen in Figure 3.5.
equation (
name = "steady-state heat flow",
domain = "dome",
expressions = [ Dx( k(x,y)*Tx ) + Dy( k(x,y)*Ty ) = 0 ],
properties = [ [self-adjoint], [steady-state] ]
);

Figure 3.4.: An equation object in PDESpec describing the steady-state heat

ow.

domain (
name = "dome",
type = piecewise_parametric,
boundary = [
orientation = clockwise,
parametric (x=3, y=.7-t, t, 0, .7),
...
]
);

Figure 3.5.: Denition of a domain object in PDESpec.

Besides PDESpec, a problem solving environment with an extensible architecture for dierent solvers and an intelligent PDE solver selection based
on expert system methodology are presented.

3.2.4. FEMLAB
FEMLAB [13] is a Matlab package for solving PDE problems. Both steadystate and time-dependent problems can be solved, as well as scalar PDEs
and systems of PDEs. An environment with a graphical user interface as
well as the Matlab command line interface is used for problem specication,
solution, and visualization. Figure 3.6 shows an example of the FEMLAB
user interface, where surfaces of the three-dimensional domain can be individually highlighted and assigned dierent boundary conditions.

26

3.2. High Level Packages and Problem Solving Environments

Figure 3.6.: Surface selection in the FEMLAB graphical user interface, useful
for example during boundary condition specication.

Figure 3.7.: Visualization of the PDE solution in FEMLAB. The solution

shows an example from structural mechanics, more specically
the static deformation of a feeder clamp.

27

Chapter 3. Related Work

FEMLAB provides dierent modes, each with several built-in models. In
the PDE Mode, the coecients of a predened PDE are specied in coecient form or in general form suited for non-linear problems. In the Physics
Application Mode, the model can be described by its physical parameters
rather than through its PDE coecients. There are several built-in models
to choose from in a number of application areas like electromagnetics, heat
transfer, structural mechanics etc. There is also support for multiphysics
problems, where, for instance both electric and thermal eects can be studied simultaneously.
Once a model has been selected, the domain geometry is dened using a
built-in two- or three-dimensional geometry editor with predened geometric
objects that can be combined to build complex geometries. Then the PDE
and boundary conditions are assigned to each part of the domain and its
boundary. Next, a nite element mesh is automatically generated, which
can be viewed and rened interactively. Finally, the problem is solved and
the result can be visualized and analyzed, see Figure 3.7.

3.3. Discussion
In the beginning of this chapter we classied available systems for solving
PDEs into two groups:
programming language based packages,
high-level packages.
The rst category of tools is directed towards users with numerical knowledge and some programming language skills. Also, a varying degree of manual work on the solution must be done before the actual implementation.
On the other hand, an ecient solver can be obtained for a specic problem.
The second category contains tools that do not require numerical knowledge to the same extent, and the details of the solution process are hidden.
This is true especially for the problem solving environments, and in particular FEMLAB. In FEMLAB, existing models can be used directly, with
some modication of the parameters and new models can be dened using
the graphical user interface. Although, the language support is poor, model
parameters can be set directly using the Matlab interface and there is a
number of help functions. PELLPACK has a more advanced, but still limited, specication language. The tool with the most advanced language is
gPROMS, which denes a formal modeling language and supports hierarchical modeling, domain description, etc., but only rectangular domains are
supported.

28

3.3. Discussion
PDEModelica belongs to the second category, being a high-level language,
and aims to hide numerical details from the user. The closest tool to PDEModelica is gPROMS which only supports simpler domains. Compared to
the other packages PDEModelica has additional object-orientation support,
like inheritance, as well as support for a general connection concept.

29

Chapter 3. Related Work

30

Chapter 4.
PDEModelica
This chapter denes the problem to be solved in this thesis and presents
a possible solution. The solution is a set of language extensions to the
Modelica language, consisting of constructs for component-based domain
geometry description, operators to express partial dierential equations in
the language, and constructs for dening a complete PDE model containing
the domain, the equations and the boundary conditions.

4.1. Problem Statement

The purpose of this work is to examine whether a general, object-oriented,
declarative modeling language with support for ordinary, algebraic, and partial dierential equations as well as component based modeling can be dened. Another goal is to design language constructs for this purpose, based
on the existing modeling language Modelica, and to evaluate whether the
extended language fullls the given requirements. The problem is to design
language constructs that allow a modeler to describe domain geometries,
boundary conditions and partial dierential equations in a language using
object orientation and component-based, hierarchical modeling. Part of this
problem also involves the denition of a connection concept for PDE-based
models and a connection mechanism for connecting ODE- and PDE-based
models.

4.2. PDE Problem Specication

The following parts are specied for describing a PDE problem:
the geometry of the solution domain,
the partial dierential equation,

31

Chapter 4. PDEModelica
the boundary conditions, and
the initial conditions in case the PDE problem is time-dependent.
The computed solution is a function of space for a stationary problem, and
a function of space and time for a time-dependent problem.

4.3. Domain Geometry Denition

The domain of a PDE problem is D Rn . In this work we mainly consider
the two-dimensional case, n = 2. In order to dene the domain a geometric
region must be described. This can be done by describing the boundary of
the geometric region or by combining previously dened regions into new
regions.

4.3.1. Boundary Description

In most practical cases it is sucient to dene the domain by a parametric
curve {(xs , ys ) | s [sstart , send ]} describing the boundary of the region,
which is a suciently general way of stating the geometry of the domain.
In the case of more complex geometries, the boundary can be divided into
several parts and each part can be described by a separate parametric curve.
The complete curve should be closed and not be self-intersecting for the
parameter range specied. In the two-dimensional case, the XY-plane is
divided into two regions by the curve, with the intended domain being the
region on the left side of the curve in the forward direction with respect to
the parameter. A domain class can also be used to dene a partial, i.e. nonclosed boundary that can be used in another domain as part of a complete
boundary.
The boundary Section
The description of the domain in a domain restricted class is specied by
a boundary section, identied by the keyword boundary. The boundary
section is a special case of the general Modelica equation section to specify
equations that constrain the space coordinates to be on the domain. When
the domain restricted class denes a boundary, the boundary section constrains the space coordinates to be on the boundary.
For convenience boundary description operators are provided. Currently,
three boundary description operators are dened in PDEModelica, line(),
curve(), and composite().

32

4.3. Domain Geometry Denition

The line() Operator
This operator species a list of two-dimensional coordinates that dene a list
of connected lines, called a polyline. Each pair of consecutive points in the
list dene a line, building a continuous curve with corners at the connection
points, see Figure 4.1. The resulting lines must not be self-intersecting. If
the domain class with the boundary described by line() is to be used as
the domain geometry in a PDE problem, the boundary must be closed, i.e.
the start and the end points must have the same coordinates.
(x0 , y0 )
(xn , yn )
(x1 , y1 ) (x2 , y2 )

(xn1 , yn1 )

Figure 4.1.: A set of connected lines that is described by the line() construct line({{x0,y0},{x1,y1},...,{xn,yn}})
The simplest case is a single line dened by its start and end points.
Figure 4.2 shows the PDEModelica code that denes a Line2D class.
domain Line2D "A line segment"
extends Cartesian2D;
parameter Real x0=0, y0=0, x1=1, y1=1;
boundary
line({{x0,y0},{x1,y1}});
end Line2D;

Figure 4.2.: Denition of the Line2D class using the line() operator

The curve() Operator

The curve() operator species a parametric expression that denes the
boundary or boundary part. One parameter is needed in the parametric
expression for a curve in two-dimensional space. The parameter is assumed
to be in the interval [0, 1]. The curve() operator contains one expression
for each coordinate, i.e. one for each of the x and y coordinates in two
dimensions. As with the line() operator, in order to be used to specify
the complete domain geometry of a model, the curve must be not be selfintersecting and should be closed.
Figure 4.3 shows how a Bezier2D class can be dened which can be used
to represent boundary parts using Bezier curves. Bezier curves [8, 9] are
parametric curves dened by a number of control points. Position of each

33

Chapter 4. PDEModelica
point on the curve is calculated by a weighted sum of all the control points,
where the weights are functions of the position on the curve varying between 0 and 1. One simple way of calculating the points of the curve is
using de Casteljaus algorithm [9, 11], which is implemented in the function
bezierfunc in Figure 4.3.
When declaring an instance of the Bezier2D class in Figure 4.3, two arrays
must be given as parameters, one array containing the x-coordinates of the
control points and one containing the y-coordinates.
function bezierfunc
input Real px[:];
input Real u;
output Real res;
Real qx[size(px,1)];
algorithm
qx := px;
for k in 1:size(px, 1) - 1 loop
for i in 1:size(px,1) - k loop
qx[i] := (1-u)*qx[i] + u*qx[i+1];
end for;
end for;
res := qx[1];
end bezierfunc;
domain Bezier2D "Boundary domain"
extends Cartesian2D;
parameter Real px[:];
parameter Real py[size(px,1)];
parameter Real u;
boundary
curve(bezierfunc(px, u), bezierfunc(py, u));
end Bezier2D;

Figure 4.3.: Denition of the Bezier2D class using the curve() operator.

The composite() Operator

This operator denes a composite boundary from a list of boundary components declared in the domain class it resides. The boundary components
are instances of domain classes dened separately, which in turn are dened
using one of the three operators. The boundary components must be listed
in the correct order so that the end point and the start point of consecutive
components have the same coordinates. The end point of the last component and the start point of the rst component must also have the same
coordinate so that the complete curve is closed, if the domain is to be used
to dene the geometry of a PDE problem.

34

4.3. Domain Geometry Denition

Figure 4.4 shows an example of a composite domain Rectangular2D consisting of four sides declared as separate boundary components. The domain
is illustrated in Figure 4.5.
domain Rectangle2D "Two-dimensional domain"
extends Cartesian2D;
parameter Real cx=0, cy=0, w=1, h=1;
Line2D right (x0=cx+w, y0=cy-h, x1=cx+w ,y1=cy+h);
Line2D top
(x0=cx+w, y0=cy+h, x1=cx-w, y1=cy+h);
Line2D left (x0=cx-w, y0=cy+h, x1=cx-w, y1=cy-h);
Line2D bottom(x0=cx-w, y0=cy-h, x1=cx+w, y1=cy-h);
boundary
composite(right, top, left, bottom);
end Rectangle2D;

Figure 4.4.: Denition of the Rectangle2D class using the composite() operator.
top
h
w

left

right

(cx, cy)
bottom
Figure 4.5.: The domain dened by the Rectangle2D class in Figure 4.4.

4.3.2. Complex Domains

Many PDE problems are based on physical systems consisting of several
dierent physical materials with dierent properties, see for example Figure 4.6. When dening such problems the complete domain is the union
of the subdomains dened for each dierent material. Parts with dierent
materials can be seen as dierent components that are combined together
to build the nal system. Such domains can be dened using aggregation,
declaring subdomains as components and combining them using operators.
Boolean operators such as union, intersection and dierence can be used
to combine domains. Using dierence, subdomains can be dened to represent holes in the domain. Furthermore, the connector concept can be
generalized to several dimensions in order to be used for component based
modeling with multidimensional objects, see Section 7.2.2. Using union or

35

Chapter 4. PDEModelica
connector operators, models such as the static current problem in Section 6.2
can be specied.
aluminum
copper
aluminum
Figure 4.6.: Example of a complex domain consisting of three subdomains
with two dierent physical materials.
In our current work, building really complex geometric domains has not
yet been investigated.

4.3.3. Domain Classes and Boundary Classes

There is a need to separate two dierent kinds of domain classes:
classes that dene the boundary of a domain, and
classes that dene the domain itself.
The boundary classes have one dimension less than the domain classes, but
they still need to be dened in the same number of dimensions. The current
implementation does not distinguish these two kinds in the language. Instead, if the composite() operator is present in a domain class, that domain
class is assumed to dene the domain itself, not just a composite boundary.
For example, the boundary based description in Section 4.3.1 describes
the line() and the curve() operators which dene one-dimensional regions distributed in two-dimensional space, whereas the current implementation of the composite() operator denes two-dimensional domains in twodimensional space.
The domain classes use instances of the boundary classes to dene a domain. See Figure 4.7 for an example. A domain class using the curve() operator denes a one-dimensional domain, a curve, in two-dimensional space,
as seen in Figure 4.7 (a). When an instance of this class is used in another
domain with the composite() operator, a two-dimensional domain is dened, as seen in Figure 4.7 (b). In order to dene complex domains, domain
classes must be able to instantiate two dimensional domains and combine
them to dene a complex domain. Further investigation and design is needed
to support and clarify this issue in PDEModelica.

36

4.4. Model Denition

(b) A two-dimensional domain.

(a) A one-dimensional domain dened in two-dimensional space.

Figure 4.7.: Two boundaries that dene domains with dierent dimensionality.

4.4. Model Denition

This section discusses the denition of the PDE-based model in terms of
the formulation of the partial dierential equation itself and the associated
boundary conditions. A coecient based approach is described where a
predened general PDE is assumed and only the coecients remain to be
dened, as well as new operators that are required for conveniently expressing PDEs in PDEModelica.

4.4.1. Operators
In order to represent the equations of the model, the initial conditions and
the boundary conditions, new operators need to be introduced in PDEModelica. The basic operator is the new partial derivative operator for derivatives
with respect to space variables, analogous to the der() operator in Modelica
that represents time derivative of variables.
An operator for the normal derivative on a domain boundary is also needed
for certain boundary conditions.
Moreover, special derivative operators such as divergence and gradient are
often used in mathematics to more conveniently express certain PDEs.
Partial Derivative
m

For partial derivatives of the form x

m (expr), a natural choice is to use
the operator pder(expr,x,m), where expr is an expression and x is a space
variable or the time variable, and m is the dierentiation order that by default is one if omitted. The der() operator in Modelica is equivalent to
pder(expr,time) with time being the builtin time variable in Modelica.

37

Chapter 4. PDEModelica
Divergence and Gradient
A short and very common mathematical notation for expressing PDE models
involves the gradient and the divergence operators, and respectively. If
a Cartesian coordinate system in two-dimensional space is used, the gradient
operator is dened as


x u
u =
y u
Hence, the gradient operator increases the dimensionality of its argument.
On the other hand, the divergence reduces the dimensionality of its argument. With the same coordinate system, and using the argument


u1
u=
u2
the divergence operator is dened as
u = x u1 + y u2
Thus, using these operators together, the Laplace equation can be expressed
as
(u) = 0
which given the same coordinate system as above, is equivalent to
xx u + yy u = 0
These operators can be introduced in PDEModelica, divergence() for
the divergence operator and gradient() for the gradient operator. The advantage of also introducing these operators besides the pder() operator is
that the syntax of these special operators is independent of the dimensionality of the problem and the names of the coordinates unlike the pder()
operator.
Directional Derivative
In some boundary conditions, the outward
normal derivative on the domain
m
boundary occurs, usually written nm (expr), most commonly only being the
rst-order derivative, m = 1. The outward normal derivative is the directional space derivative in the outward normal direction, see Figure 4.8. Since
the normal vector depends on the domain geometry, this derivative cannot
be represented by the pder() operator alone. Either the normal vector
must be available or a special operator must be used to represent the normal derivative, for example the operator nder(expr,m), with nder(expr)
corresponding to m = 1.

38

4.4. Model Denition

Outward Normal Vector
The normal derivative can also be expressed by a scalar product between
the normal vector and the gradient. If the formulation using the gradient
operator is preferred also when the boundary conditions are specied, the
outward normal vector needs to be made available. This can either be a builtin component or a keyword in the language that is automatically replaced by
the normal vector during translation since the domain will not be available
during the formulation of the boundary condition; this is done separately
from the domain denition.
n

Figure 4.8.: The normal vector on the boundary that is used in the normal
derivative operator. The normal derivative is the directional
space derivative in the normal direction.

4.4.2. Hierarchical Denition of PDEs and Boundary

Conditions
In order to simplify PDE model denition, a general PDE model can be
expressed as a base model in PDEModelica with the coecients as parameters. This model can either be instantiated directly with appropriate modications to the parameters or used as a base class to dene a more specic
PDE model with some parameters set that can subsequently be instantiated
and used when needed.
Analogously, boundary conditions can be dened using base models and
inheritance. A coecient-based PDE base model can be dened as in Figure 4.9. The variable u represents the unknown variable, which is a function
of time and the space variables. All parameters can be constants or functions of the space variables. However, in this example the coecients da,
c, a and f are restricted to be constants only, for clarity. The equation in
PDECoeff2D expressed in mathematical notation:
da

u
(cu) + au = f
t

39

Chapter 4. PDEModelica
model PDE2D
space Real x,y;
Real u(x,y);
end PDE2D;
model PDECoeff2D
extends PDE2D;
parameter Real da = 0;
parameter Real c = 0;
parameter Real a = 0;
parameter Real f = 0;
equation
da*der(u) - div(c*grad(u)) + a*u = f;
end PDECoeff2D;

Figure 4.9.: A coecient-based PDE base class.

Using PDECoeff2D as the base class, a simple, steady-state heat transfer
model can now be stated:
model HeatTransfer
extends PDECoeff2D(c=1);
end HeatTransfer;

This represents the Poisson equation. A general, time-dependent HeatTransfer model with coecients common for heat transfer problem formulations can be dened as follows:
model HeatTransfer
extends PDECoeff2D(da=rho*C, c=k, a=h, f=Q+h*T_ext);
parameter Real rho=0 "density";
parameter Real C=0 "heat capacity";
parameter Real k=0 "thermal conductivity";
parameter Real h=0 "convection coefficient";
parameter Real T_ext=0 "External temperature";
end HeatTransfer;

This model represents the following equation:

C

u
(ku) = Q + h(Text u)
t

with u being the temperature, i.e. the solution. Hence, time dependency is
chosen by modifying the coecient of the time derivative term.
Boundary Conditions
A Robin boundary condition, used in a heat transfer problem to describe a
boundary that is neither a perfect conductor nor a perfect insulator, can be

40

4.4. Model Denition

stated by rst writing a general Robin boundary condition, as seen in Figure 4.10. In mathematical notation this equation is formulated as follows:
c

u + qu = g
n

model Robin "Robin boundary condition"

extends PDE2D;
parameter Real c = 1;
parameter Real q = 1;
parameter Real g = 0;
equation
c*nder(u) + q*u = g;
end Robin;

Figure 4.10.: General Robin boundary condition model.

Other types of boundary conditions, e.g. Dirichlet and Neumann conditions, can be used to describe a perfect heat conductor and a perfect insulator, respectively. Both of these boundary conditions can be dened by
extending the Robin class and setting the appropriate parameters to zero,
for example the Neumann and Dirichlet boundary condition models in Figure 4.11.
model Neumann
extends Robin(q=0);
end Neumann;
model Dirichlet
extends Robin(c=0);
end Dirichlet;

Figure 4.11.: Boundary conditions derived from the Robin model.

Regarding heat transfer problems, a more specic version of the Robin
boundary condition can be dened by inheriting the Robin class, adding
application specic parameters, and mapping them to the general parameters, see Figure 4.12. The corresponding mathematical equation with these
parameters is

(ku) = qh + hh(Text u)
n
where qh is the source term, hh is the heat transfer coecient and Text is
the external temperature.

41

Chapter 4. PDEModelica
model HeatRobin "For heat transfer"
extends Robin(c = k,
q = hh,
g = qh + hh*T_ext);
parameter Real k = 1;
parameter Real qh = 0
"Heat flux";
parameter Real hh = 1
"Heat transfer coefficient";
parameter Real T_ext = 25 "External temperature";
end HeatRobin;

Figure 4.12.: Heat transfer specic model derived from the general Robin
model.

4.4.3. Complete Model Denition

Once the model classes for the PDE and the boundary conditions have been
formulated and the domain is dened, the problem can be put together by
instantiating the PDE model, the boundary conditions, and the domain and
associating the boundary conditions with the boundary parts.
In order to associate boundary conditions and boundary elements, an
implicit variable bc (short for boundary condition) is introduced in the restricted class domain. For each domain instance this variable is assigned the
desired boundary condition.
Similarly, a PDE is associated with a domain by instantiating the PDE
model and setting the instance equal to the variable eq (short for equation),
also a built-in variable of the restricted class domain.
The complete problem statement can be seen in Figure 4.13. Here, a
Dirichlet condition with a constant value of 50 for u is used to emulate a
heat source on the right side of the domain. A Robin boundary condition is
used for a non-isolating glass layer on the left side, and a Neumann boundary
condition is used for the isolated top and bottom sides. The PDE model
HeatTransfer is instantiated as ht, and used in the interior of the domain
dom, which is an instance of the Rectangle2D class.
With time-dependent problems, initial conditions must be supplied. The
Real type in Modelica has an attribute called start for this purpose. Also,
an initial equation section can be dened as of Modelica version 2.0 [27], as
follows:
model PDEModel
Rectangle2D dom;
HeatTransfer ht(u(start=0)); // first alternative
initial equation
ht.u = 0;
// second alternative
equation
dom.eq = ht;
end PDEModel;

42

4.5. Summary of Extensions in PDEModelica

model PDEModel
Neumann
h_iso;
Dirichlet
h_heated(g=50);
HeatRobin
h_glass(hh=30000);
HeatTransfer ht;
Rectangle2D dom "Region with rectangular geometry";
equation
dom.eq
= ht;
dom.left.bc
= h_glass;
dom.right.bc = h_heated;
dom.top.bc
= h_iso;
dom.bottom.bc = h_iso;
end PDEModel;

Figure 4.13.: Complete specication of a PDE problem using previously dened domains, PDE and boundary condition models.
Initial values that are not constant over the domain can be expressed by
dening a function. However, this has not been tested yet in the current
work and needs to be further investigated.

4.5. Summary of Extensions in PDEModelica

A summary of the introduced extensions in PDEModelica follows:
space: For declaring space variables to represent space coordinates.
domain: New restricted class.
boundary: New section in domain restricted classes for domain geometry denition.
curve(): Boundary description using parametric curves.
line(): Boundary description using straight lines.
composite(): Boundary geometry description composed by other boundary segments.
nder(): Outward normal derivative operator.
pder(): Partial derivative operator.
divergence(): Divergence operator.
gradient(): Gradient operator.

43

Chapter 4. PDEModelica
eq: Predened variable in domain restricted classes for assigning PDEs
to domains.
bc: Predened variable in domain restricted classes for assigning boundary conditions to boundary segments.

44

Chapter 5.
Implementation
The PDEModelica prototype consists of several modules. The input model
specication to the system is a text le containing PDEModelica code.
PDEModeq is the Modelica translator Modeq with PDE extensions which
extracts domain information and PDE parameters from the input source.
From the domain denitions in PDEModelica, a discrete domain description is generated by the domain discretizer for the specic mesh generator
used. The mesh generator and the PDE solver can be external software
modules freely available with source code. Figure 5.1 provides an overview
of the system.
The Modelica translator consists of several parts. The rst step is the
lexer and the parser that reads textual Modelica code and generates an
abstract syntax tree. Next, a generated compiler interprets the code and
translates the models into a at set of dierential and algebraic equations
and possibly a set of functions. A numerical solver is then used to solve
the set of equations and simulate the models. The dierent steps of the
translation process and the tools used can be seen in Figure 5.2.
The PDE extensions are described separately, in sections Section 5.1.1
and Section 5.2.3. This implementation uses the coecient-based approach,
assuming that a certain general equation is used, and only handles the parameters of the PDE model, ignoring the equations sections. Thus, the special operators for dening PDEs are not mentioned. Future work regarding
these issues is discussed in Chapter 7.

5.1. Modelica Parser

The Modelica lexer and parser are implemented using ANTLR [4], a translator generator with special meta-languages for grammar specications. The
lexer grammar specication consists of denition of the tokens, special characters and comments. The reserved keywords of the language are listed in
a tokens section:

45

Chapter 5. Implementation
User input

PDE-Modeq
Parser

PDE-Modelica

Domain
Discretizer

Domain

Translator

Mesh generator

Parameters

Solver
External software

Figure 5.1.: Overview of the PDEModelica prototype.

Module

Tool

Scanner and parser

ANTLR Lexer and Parser

Absyn tree builder

ANTLR Tree Walker

Abstract syntax
tree in ANTLR

Abstract syntax
tree in RML
Translator

RML

DAE-list
in-RML
Figure 5.2.: The dierent steps of the translation process, the tools used and
the intermediate results.

46

5.1. Modelica Parser

tokens {
...
CLASS
CONNECT
CONNECTOR
...
}

= "class"
= "connect"
= "connector"

;
;
;

The new keywords introduced in PDEModelica compared to Modelica are

domain, boundary, line, curve, composite and space.
Operators, special characters, comments and literals are dened using
rules. Each rule consists of a name and a denition, and optionally actions
to be performed when the rule is matched. The syntax for a rule is:
rule_name
: alternative_1
| alternative_2
...
| alternative_n
;

Each alternative contains a rule that is checked for a match. Table 5.1 lists
some of the symbols used in ANTLR rules.
Table 5.1.: Some symbols in ANTLR used in rules, consisting of regular
expressions.
Symbol
(. . . )
(. . . )*
(. . . )+
(. . . )?
{. . . }
|
..
.

Description
Subrule
Closure subrule (repeat zero or more times)
Positive closure subrule (repeat one or more times)
Optional
Semantic action
Alternative operator
Range operator
Wildcard

Rules are also used in the parser, but instead of characters a stream of
tokens is the input that is being parsed, and a parse tree is automatically
generated.
ANTLR also supports the implementation of tree walkers using a metalanguage similar to the lexer and parser denition meta-languages. Tree
walkers can be used to traverse a syntax tree built by the parser and perform
some actions or transformations on the tree.

47

Chapter 5. Implementation

5.1.1. PDEModelica Extensions

Some additions have been done to the Standard Modelica parser to handle
the PDE extensions. New keywords and operators are summarized in Table 5.2. domain is a new kind of restricted class to describe domain geometry,
with a new section called the boundary section. The boundary section is
described by the rules shown in Figure 5.3.
Table 5.2.: New keywords and operators in PDEModelica.
Keyword
space
domain
boundary
curve(), line(), composite()
eq, bc

Description
Space variables for coordinates
New restricted class domain
New section in classes for domain
geometry denition
Boundary geometry description
operators
Predened variables in domain classes

boundary
: (
| line_clause
| curve_clause
| composite_clause
)
comment!
;
line_clause :
LINE^ LPAR! e:expression RPAR!
;
curve_clause :
CURVE^ LPAR! e:expression_list RPAR!
;
composite_clause :
COMPOSITE^ LPAR! el:component_reference_list RPAR!
;

Figure 5.3.: Parser rules in ANTLR for the boundary section.

For description of the operators, see Section 4.3.1.
All three pseudo functions use a syntax with parentheses similar to the
connect operator, represented by LPAR and RPAR. The symbols ^ and

48

5.2. Modelica Translator

! are used to control the automatic parse tree generation, ^ denes a
node to be the root node of a current subtree, and ! suppresses the node
from the subtree. Figure 5.5 shows the abstract syntax tree resulting from
the PDEModelica domain example in Figure 5.4.
domain TestDomain
space Real x,y;
parameter Real PI = 3.141593;
parameter Real u;
boundary
curve(cos(2*PI*u), sin(2*PI*u), u);
end TestDomain;

Figure 5.4.: A domain example in PDEModelica.

ROOT

DOMAIN
TestDomain

PUBLIC

ELEMENT

ELEMENT

COMPONENTS

space

Real

COMPONENT
x

BOUNDARY

ELEMENT

COMPONENTS

COMPONENT
y

parameter

Real

CURVE
cos(2*PI*u)
sin(2*PI*u)

COMPONENTS

COMPONENT
PI

parameter

Real

COMPONENT
u

MODIFICATION
= 3.141593

Figure 5.5.: The abstract syntax tree for the domain class example in Figure 5.4. The expression subtrees are compressed into single
strings for readability.

5.2. Modelica Translator

A tree walker written in ANTLR traverses the abstract syntax tree generated by the parser and creates a corresponding tree using the data types

49

Chapter 5. Implementation
declared in RML. The tree is subsequently processed further by the Modelica
translator described in the following sections.

5.2.1. RML
RML (Relational Meta Language) [14, 33] is a meta language for formal
specication of language semantics using Natural Semantics [21]. A translator for the language described in RML is automatically generated using the
rml2c compiler, which generates ecient C code that is compiled into an
executable.
Specications in Natural Semantics are expressed using inference rules
similar to natural deduction used in logics. Inference rules with the same
input and output formal parameters can be grouped into signatures. Each
rule is dened by a set of propositions called premises and a proposition
called conclusion. A proposition is proved by applying a rule with a conclusion that can be instantiated to that proposition, and the premises of that
rule are proven similarly. An inference rule with the premises p1 ..pn and the
conclusion p is written
p1 p2 pn
p
In RML, signatures are dened using relations. Each relation consist of
a set of rules. Rules contain propositions consisting of relation invocation
with arguments and results separated by the => symbol. The premises and
the conclusion are separated by a line with two or more consecutive dashes,
see Figure 5.6. The syntax is otherwise similar to that of Standard ML [26].
An example relation can be seen in Figure 5.6.
The rst part of an RML specication le contains the data type declarations and relation declarations that are visible to other modules. The
module exprmod in Figure 5.6 contains one data type, Exp, that can be either an integer constant or an addition operation with two subexpressions.
Integer numbers are represented by the primitive type int. The only relation in this module is called eval, which evaluates the value of an expression
with the integer value as the result.
Rules without premises are called axioms, as in the rst rule of the eval
relation, which returns the value of an integer constant. The second rule
handles the addition operations by rst evaluating the subexpressions and
adding their values using the built-in RML operator int_add. The result of
the rule is then the result of that addition.

50

5.2. Modelica Translator

module exprmod:
datatype Exp = INTCONST of int
| OP_ADD of Exp * Exp
relation eval : Exp => int
end
relation eval : Exp => int =
axiom eval INTCONST(v) => v
rule

eval (e1) => v1 &

eval (e2) => v2 &
int_add (v1, v2) => v3
--------------------eval (OP_ADD (e1, e2)) => v3

...
end

Figure 5.6.: Example of an RML

data type denitions
second part contains
type, and int_add is

specication. The rst part contains the

and the module interface denition. The
the relations. int is the built-in integer
the built-in integer addition operator.

5.2.2. Modelica Translator Specied in RML

A partial semantic specication of an early version of Modelica was initially
developed by David K
agedal [22,23] in RML, and has later been substantially
expanded and improved. This specication describes the static semantics of
the Modelica language, i.e. the interpretation of the object-oriented structure, typing, and declarations dened in the models. The dynamic semantics
involving the run-time simulation of the models is not included. Hence, this
specication describes the translation of Modelica models with structural
and compositional information into a at list of equations.
The translator is divided into several modules. The Absyn module contains the representation of the abstract syntax tree, with data types that
represent classes, variable declarations, equations, algorithms, expressions,
and statements. The Absyn representation is close to the source representation of the Modelica code, i.e. the source can be recreated from the abstract
syntax.
From the abstract syntax tree the SCode intermediate tree is generated.
This tree is dened in the SCode module. The SCode tree is a canonical
representation of the Modelica code for more convenient translation. For
example, the Modelica code and consequently the abstract syntax tree can
contain multiple equation sections, depending on how the code was entered.
In the SCode representation the equation sections are merged into one list

51

Chapter 5. Implementation
of equations that is semantically equivalent and makes further processing
simpler.
From the SCode representation, the appropriate Modelica class is instantiated by the Inst module. The result of the instantiation is the DAE representation dened in the DAE module, which contains the resulting functions
and a at set of equations resulting from the translation. Instantiating a
Modelica class means:
retrieving the class denition of the extended classes if there are any
extends clauses and inserting their contents into the current model,
retrieving the class denition of the declared class of each component
in the model,
instantiating their contents with the current component name prex
to avoid name clashes,
applying the modications and inserting their contents into the current
model,
building connections sets and generating equations from these, and
merging the equations from the instantiated subcomponents updated
with the new component names.
During the instantiation, some type checking and constant expression evaluation are also performed. Type checking also includes checking whether
the subtype relationship holds between Modelica classes. Figure 5.7 shows
the RML relation that checks subtyping and type equivalence as dened
in Section 2.1.

5.2.3. PDEModelica Extensions

In this section the additions to the Modelica translator to handle domain
restricted classes and PDE parameters are described. These are additional
data types in the RML representation of the abstract syntax tree, and rules
for instantiation of domains and code generation for domains and PDE parameter initialization.
Representation
Several extensions have been in dierent parts of the Modelica semantics
specication to represent and translate PDEs and domains. In the Absyn
module, the Restriction data type is extended with the R_DOMAIN and
R_PREDEFINED_DOMAIN. The ClassPart data type is modied to support a

52

5.2. Modelica Translator

relation subtype : (Type, Type) => bool =

axiom
axiom
axiom
axiom

subtype
subtype
subtype
subtype

(T_INTEGER,T_INTEGER)
(T_REAL,T_REAL)
(T_STRING,T_STRING)
(T_BOOL,T_BOOL)

=>
=>
=>
=>

true
true
true
true

...
rule subtype_varlist(el1, el2) => true
----------------------------------subtype(T_COMPLEX(st1, el1), T_COMPLEX(st2, el2)) => true
axiom subtype(t1,t2) => false
end

relation equivtypes : (Type, Type) => bool =

rule

subtype(t1, t2) => true &

subtype(t2, t1) => true
----------------------equivtypes(t1, t2) => true

axiom equivtypes(t1, t2) => false

end

Figure 5.7.: The RML relations that check subtyping and type equivalence
between to Modelica classes. Subtyping rules regarding arrays
and tuples are not shown. The relation subtype_varlist calls
the subtype relation for the declared types of each pair of variables in the given variable lists.

53

Chapter 5. Implementation
boundary node with a list of boundary elements, where each element can be
one of the three boundary types, see Figure 5.8. In the current prototype,
the representation is kept simple, using the Exp data type for the LINES node,
which corresponds to the list of points written as a single expression using
the array syntax. Similarly, the CURVE node contains a list of expressions,
one for each of the coordinates.
datatype ClassPart =
|
|
|
|

PUBLIC of Element list

PROTECTED of Element list
EQUATIONS of Equation list
ALGORITHMS of Algorithm list
BOUNDARY of Boundary list

datatype Boundary = LINES of Exp

| CURVE of Exp list
| COMPOSITE of ComponentRef list

Figure 5.8.: Data type extensions for domain representation in the Absyn
module.
The representation of boundaries in the SCode module are the same as
in the Absyn module, but the ClassDef data type has been modied to
represent domain information as well (see Figure 5.9).
datatype ClassDef = PARTS of Element list
* Equation list
* Algorithm list
| DERIVED of Path
* Absyn.ArrayDim option
* Mod
| DOMAINPARTS of Element list
* Boundary list

Figure 5.9.: Data type extensions for domain representation in the SCode
module.
The DAE representation is also extended with nodes needed to represent
the extra information related to PDEs, see Figure 5.10. Data types for
expressions stored in the DAE representation are dened in the Exp module,
and contain the statically analyzed expressions, as opposed to the Absyn.Exp
data type which contains the expressions before the analysis. The DAElist
stored in the CURVE node is needed during code generation to determine
which component references in the curve expressions that are parameters, in
order to prex them with the correct prex. See Section 5.2.4 for description
of the code generation phase.

54

5.2. Modelica Translator

datatype DAElist = DAE of Element list
datatype Element = VAR of Exp.ComponentRef * VarKind *
VarDirection * Type * Exp.Exp option
| DEFINE of Exp.ComponentRef * Exp.Exp
| EQUATION of Exp.Exp * Exp.Exp
| ALGORITHM of Algorithm.Algorithm
| COMP of Ident * DAElist
| FUNCTION of Absyn.Path * DAElist *
Types.Type
| DOMAIN of Exp.ComponentRef * Boundary list
datatype Boundary = LINES of Exp.Exp * Static.Properties
| CURVE of Exp.Exp list * DAElist
| COMPOSITE of Exp.Exp list

Figure 5.10.: Additions in the DAE module for storing domain information.
The only addition in the Element data type is the DOMAIN node.
Translation
The SCode module contains the relations that convert the Absyn representation to the SCode representation, beginning with the elaborate relation.
Some relations in this module are modied to handle the domain extensions. The elab_class relation redirects the translation to elab_domaindef
instead of elab_classdef if the current class has the restriction type R_DOMAIN, i.e. if the class being translated is a domain class. Conversion of the
declaration part in elab_domaindef is identical to the conversion of other
classes, but the conversion of equation and algorithm sections are replaced
with a relation that converts the boundary section. The result of the boundary section conversion is the SCode.DOMAINPARTS structure. The rst part
of this structure are the elements from the declaration part, and the second
part is the boundary description consisting of SCode.Boundary elements
generated by the relation elab_boundary_parts, see Figure 5.11.
The translation is done in the Inst module in dierent ways depending on the type of the SCode.ClassDef node, one of PARTS, DERIVED or
DOMAINPARTS. In the latter case, the rule for translating the domains is activated. The declaration part is handled as for other classes. The boundary
part is instantiated using the relation inst_boundary, see Figure 5.12. In
this relation the three dierent kinds of boundary descriptions POINTS, CURVE
and COMPOSITE are recognized and corresponding DAE nodes are generated.
The common steps for each kind is:
static analysis: constant expression evaluation, type analysis and type
annotation of expressions, variable references, etc. In the COMPOSITE

55

Chapter 5. Implementation
relation elabbndparts: Absyn.Boundary list => Boundary list =
axiom elabbndparts ([]) => []
rule

elabbndparts (rest) => bnds &

let bnds = POINTS(e)::bnds
-----------------------elabbndparts (Absyn.POINTS(e)::rest) => bnds

rule

elabbndparts (rest) => bnds &

let bnds = CURVE(elist)::bnds
-----------------------elabbndparts (Absyn.CURVE(elist)::rest) => bnds

rule

elabbndparts (rest) => bnds &

let bnds = COMPOSITE(elist)::bnds
-----------------------elabbndparts (Absyn.COMPOSITE(elist)::rest) => bnds

end

Figure 5.11.: The relation elab_boundary_parts (abbreviated to elabbndparts) in the SCode module that handles the boundary description parts from the Absyn module.
case, only variable references are checked, because that is the only kind
of expression allowed in the composite() operator.
prexing expressions: adding the correct prex to variable references
in the current instantiation environment. A reference to a variable v
in a variable comp in the class being instantiated is prexed by comp.
to build comp.v.
state transition in class inference: modifying the state in the class
inference module ClassInf which keeps track of the class state in
order to check if the class contents is consistent with the restricted
class type. In this case the transition to FOUND_BOUNDARY has been
added.

5.2.4. Code Generation

The result of the Modelica translation phase is the DAE representation that
contains the list of variables, parameters, functions, equations, algorithms,
and domains. In this prototype, there is also a code generation module for
setting up the PDE problem in C++ code so that it can be compiled and
linked with a PDE solver. The code generation phase produces code for

56

5.2. Modelica Translator

relation inst_bnd:(Env, Mod, Prefix, Connect.Sets,

ClassInf.State, SCode.Boundary, DAE.DAElist)
=> (DAE.Boundary list, Env, Connect.Sets, ClassInf.State) =
rule Static.elab_exp(env, e) => (e, prop) &
PrefixCode.prefix_exp (env, e, pre) => e &
ClassInf.trans(st, ClassInf.FOUND_BOUNDARY) => st
---------------------------------------------inst_bnd(env, _, pre, csets, st, SCode.POINTS(e), dae)
=> ([DAE.POINTS(e, prop)], env, csets, st)
rule Static.elab_exp_list(env, elist) => (el, _) &
PrefixCode.prefix_exp_list (env, el, pre) => el &
ClassInf.trans(st, ClassInf.FOUND_BOUNDARY) => st
---------------------------------------------inst_bnd(env, _, pre, csets, st, SCode.CURVE(elist), dae)
=> ([DAE.CURVE(el,dae)], env, csets, st)
rule Static.elab_cref_list(env, crlst) => (el,_,_) &
canon_cref_list(env, el) => el &
PrefixCode.prefix_exp_list (env, el, pre) => el &
ClassInf.trans(st, ClassInf.FOUND_BOUNDARY) => st
---------------------------------------------inst_bnd(env, _, pre, csets, st, SCode.COMPOSITE(crlst), dae)
=> ([DAE.COMPOSITE(el)], env, csets, st)
end

Figure 5.12.: The inst_boundary relation that instantiates the three dierent kinds of boundary elements, POINTS, CURVE and COMPOSITE
and builds the corresponding DAE structures.

57

Chapter 5. Implementation
declaration and initialization of parameters, function denitions, creating
functions for parameterized boundary description and associating boundary
conditions and boundary sections. The generated code is incomplete, and is
combined with prewritten C++ code.
Model Parameters
The model parameters declared in functions are collected and generated as
elds in separate C++ structs, one for each function instance. The model
parameters of the instantiated, complete model are generated as elds in a
struct that contains all the parameters of all subcomponents as a at list
of C++ variables. Initialization of all model parameters of all functions is
performed in an initialization routine, and another routine initializes the
values of the model parameters. The pointer to the model parameter struct
is passed to functions so that model parameters can be accessed from within
instantiated functions.
Functions
The rst step of function code generation is to generate a unique C++ struct
for each function, containing the Modelica parameters of that function. A
global struct variable is declared at the same time, with a name corresponding to the full name of the function with dots replaced by underscores. Later,
initialization code is generated for assigning the parameter values for all
function parameters.
Next, the function head is generated. The input variables are generated as
arguments of the function with their type and value and output variables are
generated as the return value. For simple variable types simple C++ variables
are generated, like int, real, etc. For complex types a C++ struct is generated and the name of the struct is used as the type. If there is only one
output variable, the type of that variable is used as the return type of the
function. If there are more output variables, a return type struct is created
and used as the return value containing all the output variables. The return
variable is declared at the beginning of the function body and if a struct is
used, the output variables are prexed with the structs name appropriately.
The function body is generated from the algorithm section of the corresponding Modelica function which has a close correspondence to C++ code.
Finally, the return statement is constructed.
Function Instances
Code instances of parameterized functions are implemented using the replaceable function feature of Modelica. PDE and boundary condition mod-

58

5.2. Modelica Translator

els contain replaceable functions that represent coecients that can depend
on space variables. These Modelica functions are instantiated for each instance of a PDE or a boundary condition class, and a unique C++ function
is generated in each case. The generated code for each function instance is
identical to that for the Modelica function class that the function is an instance of, except that the parameter references are replaced with references
to a separate parameter struct.
Domains
A set of C++ classes has been developed in order to simplify code generation for domain classes. The class hierarchy can be seen in Figure 5.13.
The three kinds of boundary descriptions use dierent approaches to code
generation, but has the same interface so that the discretization is done automatically. The Object2D() class is the base class containing the interface
method getPoints(), which returns a required maximum number of discrete points describing the boundary. The Object2D() class also contains
the isComposite() and the getCurves() methods needed for hierarchically
composed curves.
Object
-name: string

Object2D
+getPoints(): point_vector
+getCurves(): curvep_vector
+isComposite(): bool

Curve2D
+func(u:Real): Point2D

DiscreteCurve2D
-points: point_vector
+add(point:Point2D)

Composite2D
-curves: curvep_vector
+add(in curve:Object2D)

Figure 5.13.: The class hierarchy for the C++ classes written to generate
domain descriptions. Line2D objects are represented by the
DiscreteCurve2D class.
The curve approach to boundary description uses a parametric expression that denes the boundary curve. The description is symbolic, but is
discretized before the triangulation can be made. This is handled by generating a function which calculates the coordinates of a point on the curve for
a given parameter value. For example, the boundary description:
curve(cos(2*PI*u), sin(2*PI*u), u);

59

Chapter 5. Implementation
is translated into a C++ function with the structure shown in Figure 5.14.
Point2D func(Real u) {
Point2D res;
res.x = cos(2*PI*u);
res.y = sin(2*PI*u);
return res;
}

Figure 5.14.: Function generated for the boundary

curve(cos(2*PI*u), sin(2*PI*u), u);

described

as

The class Curve2D is used to represent parametric curve based descriptions. A new, specialized class is generated for each such domain description, which inherits Curve2D and overloads the func() method to calculate
the correct curve. The Curve2D class can be seen in Figure 5.15. The
getPoints() method automatically calls the func() method to generate
the required number of discrete points on the curve.
class Curve2D : public Object2D {
public:
Curve2D(string name=string("Curve2DObject"))
: Object2D(name) {
}
virtual Point2D func(Real u)=0;
virtual point_vector* getPoints(int n);
};

Figure 5.15.: The Curve2D class that represents parametric curves. Each
specic boundary description inherits this class and overloads
the func() method.
When the lines method is used for boundary description, the class DiscreteCurve2D is instantiated and the set of points from the lines description is added to that instance. See Figure 5.16 for the contents of the DiscreteCurve2D class. The list of points added to an instance is directly returned from the getPoints() method, ignoring the desired maximum number of points, for simplicity. Hence, it is assumed that the number of points
given in the lines operator is always less than the required number of discretization points on the boundary. If this does not hold, the result will be
a ner discretization than what is desired.
The composite method is slightly more complex to handle. Figure 5.17
shows the declaration of the Composite2D class that represents composite
boundaries. A composite curve is discretized by retrieving its constituent

60

5.2. Modelica Translator

class DiscreteCurve2D : public Object2D {
point_vector points;
public:
DiscreteCurve2D(string name=string("DiscreteCurve2D"))
: Object2D(name) {
}
void add(const Point2D& p);
void add(const Point2D* p, int n);
virtual point_vector* getPoints(int n);
};

Figure 5.16.: The DiscreteCurve2D class that represents a set of connected

lines. Each specic boundary description instantiates this class
and adds the present set of points to that instance using the
add() method.

curve segments and discretizing them, compensating for the overlaps at the
joints. The getCurves() method is used to access the curve segments. It traverses the composition hierarchy and collects all non-composite curves into
a single list. Hence, if a curve segment itself is composite, the getCurves()
method is called recursively on that curve object and the resulting list of
curves is inserted into the top level list. Thus, the list of curves returned
only contains Curve2D or DiscreteCurve2D objects.
class Composite2D : public Object2D {
curvep_vector curves;
public:
Composite2D(string name=string("Composite2D"))
: Object2D(name) {
}
virtual point_vector* getPoints(int n);
curvep_vector* getCurves();
void add(Object2D* c);
void add(Object2D** c, int n);
virtual bool isComposite() {
return true;
}
};

Figure 5.17.: The Composite2D class that represents a boundary that is composed of one or more other boundary objects, composite or
plain (curve or discrete curve). The getCurves() method recursively goes through any constituent composite curves, returning only a at list of non-composite curve segments.

61

Chapter 5. Implementation
Boundary Conditions
Boundary conditions are represented by the BoundaryCondition C++ class,
see Figure 5.18. The same class can be used for the three dierent kinds
of boundary conditions: Dirichlet, Robin, and Neumann conditions. The
names of the boundary condition objects are mapped from their names in
the Modelica domain description. The mesh generator and the PDE solver
supports named boundary segments. The code generation consists of instantiating the boundary condition objects and putting them in a list to be
passed to the solver.
class BoundaryCondition {
public:
space_function* g;
Float q;
bool is_dirichlet;
string name;
public:
typedef Float space_function (const point& p);
BoundaryCondition();
};

Figure 5.18.: The BoundaryCondition class that is used to represent the

three kinds of boundary conditions. The type space_function
is used for functions that depend on the space variables. The
type point represents the space coordinates in two or three
dimensions.

5.3. Numerical Solver

The solution of a PDE problem involves discretization of the domain, mesh
generation for the nite element solver, and solution of the discretized problem using a linear equation solver. The mesh generation and the solution is
handled by external software, with some adaptation to support the approach
taken in this thesis. The class diagram for the dierent parts of the solution
process can be seen in Figure 5.19.

5.3.1. Domain Discretization

Domain discretization is performed by the DiscreteDomain2D class. In the
case with a parametric curve description, this involves sampling a given

62

5.3. Numerical Solver

MeshGenerator

DiscreteDomain2D

+generate(domain:Object2D)

BamgMeshGenerator

GeoMeshGenerator

+discretize(curve:Object2D)
+optimize()
+getPoints()
+getSegments()
+getSubnames()

EasymeshMeshGenerator

Solver
+solve(domain,bclist,reglist)

RheolefSolver

MathFEMSolver

FEMLABSolver

Figure 5.19.: The class diagram for the mesh generator and the solver classes.
number of points on the boundary and creating a polygon with these points
as the corners of the polygon, in practice approximating the curve with
linear segments. The discretization is performed by calling the getPoints()
method of the Object2D interface. The discretizer also keeps track of the
boundary section names in order to pass the information to the PDE solver
for the boundary conditions to be applied appropriately.
This discretization is done because most mesh generators support the
boundary representation based on corner points and linear segments. In the
future, splines and other higher-order representations may be supported.

5.3.2. Mesh Generator

The mesh generator interface consists of a function generate() which takes
an Object2D object. The mesh generator classes use the DiscreteDomain2D
class to generate the polygonal approximation of the boundary from the
Object2D object. The DiscreteDomain2D class traverses the boundary description objects that can be a hierarchy of composite boundary objects and
connected lines and curve objects, and generates a at boundary description
of connected lines, i.e. a polygon.
From the discrete domain description, each mesh generator class generates the output in the corresponding format. Two mesh generators are
supported, Bamg [1], Easymesh [3], using the classes BamgMeshGenerator
and RheolefMeshGenerator. The mesh generator class GeoMeshGenerator
is used to convert a Bamg mesh into the Geo format that one of the solvers,
Rheolef, uses.

63

Chapter 5. Implementation

5.3.3. Finite Element Solver

The solver interface contains one function, solve() which takes three arguments: An Object2D object describing the boundary, a list of BoundaryCondition objects and a list of DomainRegion objects. BoundaryCondition
objects are named and contain the parameters of the boundary conditions
for the boundary sections with matching names. The DomainRegion objects
represent dierent regions in the domain that have dierent PDE coecients. Only some of the coecients can be dierent in dierent regions
though, depending on which solver that is used.
Three dierent PDE solvers can be used with this prototype. The dierent
modules involved when using each solver can be seen in Figure 5.20 and
Figure 5.21.
Coecient Based Solver
With the coecient-based solver, a solver for a predened, general PDE is
used, with the proper parameters from the present PDE problem. Dierent
solvers for dierent predened PDEs can be used. In this work Rheolef and
FEMLAB are used to solve equations of the form (cu) = f .
Rheolef [39,40] is a publicly available package for solving PDEs using nite
element methods. Besides some supporting Unix commands, it contains a
set of C++ classes to handle domains, domain boundaries, elds and other
PDE related objects. The problem is formulated in variational form by
writing a C++ routine that is used together with the Rheolef package.
The PDE problem mentioned above was converted to variational form
manually, together with the dierent possible boundary conditions. The
coecients of the problem are passed to the solver after the translation
process. This formulation is independent of the domain geometry, and the
occurrence and number of the boundary conditions, as long as the supported
kinds of boundary conditions are used. Currently, it handles the three kinds
of boundary conditions that are used in the prototype: Dirichlet, Neumann,
and Robin conditions. The list of boundary condition objects are passed
to the solver which generates the correct problem formulation and further
calls the Rheolef equation solver. Rheolef supports meshes generated using
Bamg, with a converter that converts the mesh into a Geo mesh, that can
be processed by the solver. Boundaries can be referred to by names which
is utilized by the PDE Modelica translator. The Rheolef solver routine can
be found in Appendix A.
The FEMLAB solver interface is simpler since FEMLAB also uses the
coecient-based problem formulation. The FEMLAB programming interface is used and coecient assignments are generated into a Matlab script

64

5.3. Numerical Solver

le. Mesh generation is handled internally by FEMLAB, but the discrete
domain description is transfered through the same interface and a FEMLAB polygon object is generated. A special routine was written though,
in order to rearrange the boundary condition indices on the edges because
FEMLABs polygon creation routine sorts the boundary vertices which invalidates the boundary condition indices on the edges. The rearrange routine
nds the vertices according to their coordinates and determines the new edge
indices so that the boundary conditions are applied correctly. This routine
is available in Appendix B.
Finally, mesh generation and solution commands are generated and put
into the Matlab script le. The script can then be executed and FEMLABs
post-processing tools can be used to analyze the solution. An example of a
generated le can be seen in Appendix C.

Solver Generator in Mathematica

The Mathematica-based solver generator supports general Mathematica differential equation formulation of a PDE. Hence, no manual conversion to
variational form is necessary, and the solver can be used for PDEs with different structure. Mathematica is used for symbolic processing of the equations and generating a nite element solver for the specic domain. The
resulting equation system can be solved by Mathematicas built-in linear
solver or an external solver such as SuperLU.
Both a nite dierence method [41,42] implementation and a nite element
method implementation exist, as well as a method of lines implementation
using nite dierences. The nite dierence and the method of lines solvers
are used with a translator implemented in MathModelica [18, 25].
The current implementation of the translator uses the nite element implementation, MathFEM, but complete equation generation is not yet supported. Instead, a coecient based PDE is generated together with the
coecient value settings. The problem description generation is similar to
that of FEMLAB described previously, but here a Mathematica script le is
generated. Appendix D contains a listing of a generated example.
There is also ongoing work on a solver in Mathematica based on the
method of lines using nite elements. Here, space discretization is performed by the solver which generates only time dependent ordinary dierential equations. Standard Modelica code can be generated from this solver
that can be solved further using existing Modelica environments, for example the modeling and simulation tool Dymola [2], the Open Source Modelica
environment [5, 16, 31], or the MathModelica environment [18].

65

Chapter 5. Implementation

User input

PDE-Modeq
Parser

PDE-Modelica

Discretizer

domain

Translator

discrete domain boundary

Mesh generator
mesh
Solver

boundary condition parameters

equation parameters

External software
Figure 5.20.: Solution method using an external PDE solver or a pregenerated solver. This method is used with Rheolef and FEMLAB.

66

5.3. Numerical Solver

User input

PDE-Modeq
Parser

PDE-Modelica

domain

Discretizer

Translator

equations
boundary conditions
parameters

discrete domain boundary

Mesh generator
External software

mesh

Solver generator
Mathematica

New parameter values

Solver

Parameter values

Figure 5.21.: Solution method with dynamic solver generation. This method
is used with the MathFEM solver.

67

Chapter 5. Implementation

5.4. Future Extensions in the Implementation

Some parts of the prototype implementation are not completed. The mixed
ODE and PDE based models cannot be translated automatically yet. The
missing part is a method of lines solver implementation to convert the PDE
models into ODE models and merge with the rest of the ODE models, maintaining the connections between the models.
Representation of complex domains is not yet implemented in PDEModelica and the translator, and incomplete in the mesh generator interface.
Although support for complex domains with subdomains is included in the
PDE solver interface.
Another issue is that the composite() operator has the following inconsistent properties:
dening a boundary segment consisting of other boundary segments.
increasing the dimension of the domain, i.e. the domain containing
the composite() operator automatically becomes a two-dimensional
domain. To assure a correct domain, open composite boundaries are
automatically closed, using a line segment between the end points.
Thus, complex boundary segments that are not treated as one-dimensional
boundary domains, and which can be used as boundaries in other domains,
are not supported. The correct semantics of composite() yet to be implemented is to dene a possibly non-closed boundary segment consisting of
several parts.

68

Chapter 6.
Examples
This chapter contains three examples solved using the prototype implementation. The static current example in Section 6.2 was only partially dened
in PDEModelica, because of lack of subdomain support. The heat transfer example in Section 6.3 was solved using both Rheolef and FEMLAB for
comparison. Time-dependent problems can be solved using FEMLAB, and
an experimental time-dependent solver is implemented for Rheolef, but no
time-dependent examples are mentioned here.

6.1. Electrostatic Fields

Given the electric potential on the boundary of a geometric domain, the
electrostatic eld inside the domain can be calculated. The relationship
between the conservative electric eld intensity E, which is a vector eld,
and the electric scalar potential V is as follows:
E = V

(6.1)

The simplication of Maxwells equations for electrostatic elds gives the

equations
D=
D = E
where D is the electric ux density, the charge density, and the electric
permittivity of the specic material where the electric eld is studied. Using
equation (6.1) with these gives
(V ) =
This is Poissons equation dening the electric potential distribution in a
material with electric permittivity and the charge density . If the charge
density is zero, the Laplace equation is obtained.

69

Chapter 6. Examples
V=500kV

E
D

Transformer

V=0

Figure 6.1.: An electrostatic eld problem. Potentials on the boundaries are

given, and the eld inside the domain is calculated.

Consider a high voltage substation in the vicinity of an electrically grounded transformer [20], illustrated in Figure 6.1. The line labeled A represents
the high voltage part with the potential V = 500kV , and line B denes the
transformer and the ground with V = 0. The lines C and D are chosen
to be far away from the transformer, where the electrical eld becomes approximately vertical and thus tangential to the lines C and D. No change
in electric eld intensity occurs across lines C and D because of the Neumann boundary conditions. The lines A and B have constant potential,
corresponding to Dirichlet boundary conditions.
The PDEModelica code for this example is shown in Figure 6.2. The
model is translated, compiled, and executed. The resulting plot can be seen
in Figure 6.3.

6.2. Static Currents

This example illustrates calculation of current distribution in a conductor consisting of two layers with dierent materials, copper and aluminum.
When the current dierence between two boundaries is known, the distribution can be calculated by the following equation in the two-dimensional
case, involving the electrical vector potential T:
1 T
1 T
+
=0
x x
y y

70

(6.2)

6.2. Static Currents

domain VoltageLine
extends Domain2D;
boundary
line({{4.5, 2.}, {2., 2.}, {2., 1.0}, {-0.5, 1.0}, {-1.5, 2.},
{-4.5, 2.}});
end VoltageLine;
domain Transformer
extends Domain2D;
boundary
line({{-4.5, -2.}, {-1., -2.}, {-1., -1.5}, {-1.5, -1.}, {-1.5, 0.},
{1.5, 0.}, {1.5, -1.}, {1., -1.5}, {1., -2.}, {4.5, -2.}});
end Transformer;
domain TransformerDomain
extends Domain2D;
VoltageLine voltageline;
Transformer transformer;
Line2D left (x0=-4.5, y0= 2, x1=-4.5, y1=-2);
Line2D right(x0= 4.5, y0=-2, x1= 4.5, y1= 2);
boundary
composite(voltageline, left, transformer, right);
end TransformerDomain;
model ElectricField
parameter Real rho=0, epsilon=1;
extends PDECoeff2D(c=epsilon, f=rho);
end ElectricField;
model PDEModel
Dirichlet voltageline(g=500), ground(g=0);
Neumann verticalfield;
ElectricField ef;
equation
dom.eq=ef;
dom.left.bc=verticalfield;
dom.right.bc=verticalfield;
dom.voltageline.bc=voltageline;
dom.transformer.bc=ground;
end PDEModel;

Figure 6.2.: PDEModelica code for the electric eld calculation example
in Section 6.1 with a high voltage substation and a grounded
transformer.

71

Chapter 6. Examples
2
480
450
420
390
360
330
300
270
240
210
180
150
120
90
60
30
0

2
4

4.5

Figure 6.3.: Solution of the transformer problem dened in Section 6.1.

The domain geometry can be seen in Figure 6.4. The current is known on
the boundaries C and D where Dirichlet boundary conditions are applied.
On A and B where E is perpendicular to the boundary, Neumann boundary conditions are applied. The solution with the current lines can be seen
in Figure 6.5. The result shows that the current in the copper layer is approximately 60% higher than in the aluminum layer, which is a result of the conductivity of copper being approximately 60% higher than the conductivity of
aluminum (copper = 5.7 107 (m)1 and aluminum = 3.5 107 (m)1 ).
This example is only partially implemented in PDEModelica, because of
lack of support for complex domains, see Section 4.3.2 and Section 7.2.1. The
missing parts of the domain geometry description was manually inserted into
the generated intermediate les.

6.3. Heat Transfer

An example similar to the heat transfer example described in Section 1.1
is solved with a more complex boundary for illustration. The outside temperature of 20o C is used and the constant temperature of 60o C is used on
the middle section of the bottom boundary. The right boundary is the noninsulated side, the other sides are perfectly insulated. The PDEModelica
code for the boundary description is shown in Figure 6.8. This problem was
solved with two dierent solvers for comparison, the solution using Rheolef
can be seen in Figure 6.6 and the solution from FEMLAB is shown in Figure 6.7. The generated FEMLAB input le for this problem is listed in
Appendix C.

72

6.3. Heat Transfer

A

Va

C
B

E
copper
E

aluminium

Vb

Figure 6.4.: A static current problem. The current on the boundaries C and
D is given, and the current distribution inside the domain is
calculated.
0.84

0.28
0.24

0.88

0.8

0.64
0.6

0.52

0.72

0.44

0.32

0.04

0.96

0.76

0.56

0.68

0.48
0.4

0.2
0.16
0.12
0.08

0.92

0.36
0.84

0.28

0.24

0.88 .8
0
44

0.

2
0.3

0.2

0.6
4
0.5 0.6
2

0.72

0.0
8

0.88
0.8

0.56

0.48

0.4

0.28

0.16

0.76

0.68

0.72

0.64
0.6
0.52

0.44
0.36

0.32

0.12

0.96

0.92
0.84

68 0.7

0.04

0.3

0.96

0.
0.5

0.16

0.2

0.12

0.08

0.4

0.4

0.28

0.2

0.24

0.2
0.16
0.12

0.04

0.08

0.04

1
1

Figure 6.5.: Solution of the static current problem dened in Section 6.2.

73

Chapter 6. Examples

2
59
57.6
56.2
54.7
53.3
51.8
50.4
49
47.5
46.1
44.6
43.2
41.8
40.3
38.9
37.4
36

2
5

Figure 6.6.: Solution of the stationary heat conduction example in Section 6.3 using Rheolef.

Figure 6.7.: Solution of the stationary heat conduction example in Section 6.3 using FEMLAB.

74

6.3. Heat Transfer

domain Circle2D
extends Cartesian2D;
parameter Real PI=3.14159265358979;
parameter Real x0=0, y0=0, ra=1, rb=ra, a=2*PI, b=0;
parameter Real u;
boundary
curve(x0 + ra*cos(a*u + b), y0 + rb*sin(a*u + b));
end Circle2D;
domain TestDomain
extends Domain2D;
parameter Real PI=3.14159265358979;
Bezier2D right(px=[ 1.0, 1.3, -4.0, -4.0, 1.3, 1.0],
py=[-2.0, 0.0, -3.0, 3.0, 0.0, 2.0]);
Line2D top(x0=1, y0=2, x1=-1, y1=2);
Circle2D left(x0=-1, y0=-2, ra=4, a=PI/2, b=PI/2);
Line2D bottom1(x0=-5, y0=-2, x1=-3, y1=-2);
Line2D bottom2(x0=-3, y0=-2, x1=-1, y1=-2);
Line2D bottom3(x0=-1, y0=-2, x1=1, y1=-2);
boundary
composite(right, top, left, bottom1, bottom2, bottom3);
end TestDomain;

Figure 6.8.: The domain geometry for the example in Section 6.3. See Figure 4.3 and Figure 4.2 for the denitions of Bezier2D and
Line2D, respectively.

75

Chapter 6. Examples

76

Chapter 7.
Conclusions and Future Work
This chapter presents some conclusions drawn from the results of this research, and outlines future work that is needed to achieve a more complete
solution to the problem.

7.1. Conclusions
The language extensions described in this thesis and implemented in the
prototype suce to solve PDE problems based on a general PDE with coecients that can be modied. The three most common types of boundary conditions are supported, which allows formulation and solution of a
wide range of problems that are based on the predened PDE. Complex
domain boundaries are supported thanks to the curve() operator which
allows a parametric description of the boundary, and the composite() operator which can combine boundary segments of curves and lines.

7.2. Future Work

Possible future research directions are discussed in this section.

7.2.1. Complex Domains

Support for complex domains as discussed in Section 4.3.2 will be added to
the language and implemented in the prototype. There is currently some
basic support in the solver part of the prototype for subdomains with different PDE parameters, i.e. the use of domain regions, but the language
denition and the translator must be modied to support subdomains. This
issue is somewhat related to the issue of generalized, spatially distributed
connectors. Subdomains and separate domains that are connected are two

77

Chapter 7. Conclusions and Future Work

approaches to describe problems where dierent PDEs, or the same PDEs
with dierent coecients, occur in dierent subdomains.

7.2.2. Generalized Connectors

The current connector concept in Modelica can be generalized to support
connectors with spatial distribution. The static current calculation in Section 6.2 is an example where a connection would be used between two kinds
of physical materials. Such a connector needs to be dened with respect
to two issues; the geometric description of the interface and the mathematical behaviour of the model across the interface are required. Modelica
connectors are also acausal, i.e. the unknown variable is not predetermined
but dened by how the components are connected in the nal model. This
feature should be maintained for generalized connectors.
Additional solver support is also needed to test the extensions in the
prototype. One possible approach for solving such models can be to use the
interface relaxation method [34].
A connection mechanism to connect ODE-based models and PDE-based
models is a very important feature that is needed in order to integrate PDEbased models into existing Modelica models and to simulate combined ODEand PDE-based models, for example ODE based control systems. The example shown in Section 1.1.1 illustrates a combined ODE and PDE based
system. The solution of mixed ODE and PDE models can be implemented
by a method of lines solver that converts the PDEs into ODEs, which can be
merged with the rest of the ODE models for solution with existing Modelica
implementations.

7.2.3. Expressing PDEs

The operators presented in Section 4.4.1 needed for expressing PDEs and
boundary conditions explicitly in the language will be implemented and evaluated. This will allow explicitly written PDEs in models, which is dierent
from the current, coecient-based approach with only parameter modication. Furthermore, the PDE solver interface must be extended to support
transfer of equations to the solver.

7.2.4. Debugging
There is ongoing work on debugging of declarative equation based languages,
specically debugging of Modelica models [6,7]. It is useful to also investigate
debugging of PDE based models, for example checking of sucient denition
of initial and boundary conditions.

78

References
[1] BAMG home page. http://www-rocq.inria.fr/gamma/cdrom/www/
bamg/eng.htm.
[2] Dynasim AB. http://www.dymola.com/.
[3] EasyMesh home page.
http://www-dinma.univ.trieste.it/
~nirftc/research/easymesh/easymesh.html.
[4] ANTLR home page. http://www.antlr.org/.
[5] P. Aronsson, P. Fritzson, L. Saldamli, and P. Bunus. Incremental Declaration Handling in Open Source Modelica. In Martin Otter, editor,
Proc. of the SIMS - 43rd Conference on Simulation and Modeling, Oulu,
Finland, September 2002.
[6] P. Bunus and P. Fritzson. A Debugging Scheme for Declarative Equation Based Languages. In Proceedings of the 4th International Symposium on Practical Aspects of Declarative Languages, volume 2257 of
LNCS. Springer-Verlag, 2002.
[7] Peter Bunus. Debugging and Structural Analysis of Declarative
Equation-Based Languages. Licentiate Thesis, PELAB, Dept. of Computer and Information Science, Link
opings universitet, 2002.
[8] Pierre E. Bezier. The First Years of CAD/CAM and the UNISURF
CAD System. In Les Piegl, editor, Fundamental Developments of
Computer-Aided Geometric Modeling, pages 1326. Academic Press,
1993.
[9] C.-K.Shene. Introduction to Computing with Geometry. http://www.
cs.mtu.edu/~shene/COURSES/cs3621/NOTES/notes.html.
[10] A. F. Cardenas and W. J. Karplus. PDEL a Language for Partial
Dierential Equations. Communications of the ACM, 13(3):184191,
March 1970.

79

References
[11] Paul de Casteljau. Polar Forms for Curve and Surface Modeling as
Used at Citroen. In Les Piegl, editor, Fundamental Developments
of Computer-Aided Geometric Modeling, pages 112. Academic Press,
1993.
[12] Dipack home page. http://www.diffpack.com/.
[13] FEMLAB home page. http://www.femlab.com/.
[14] P. Fritzson. Ecient Language Implementation by Natural Semantics.
Personal communication. Book draft 1996.
[15] P. Fritzson. Principles of Object-Oriented Modeling and Simulation.
Personal communication. Book draft 2002. Chapter 1 on http://www.
ida.liu.se/~pelab/modelica/.
[16] P. Fritzson, P. Aronsson, P. Bunus, V. Engelson, L. Saldamli, H. Johansson, and A. Karstr
om. The Open Source Modelica Project. In Martin Otter, editor, Proc. of the 2nd International Modelica Conference,
Oberpfaenhofen, Germany, March 2002. http://www.modelica.
org/.
[17] P. Fritzson and P. Bunus. Modelica, a General Object-Oriented Language for Continuous and Discrete-Event System Modeling and Simulation. In Proceedings of the 35th Annual Simulation Symposium, San
Diego, California, April 2002.
[18] P. Fritzson, J. Gunnarsson, and M. Jirstrand. MathModelica - An Extensible Modeling and Simulation Environment with Integrated Graphics and Literate Programming. In Proc. of the 2nd International Modelica Conference, Munich, March 2002. http://www.modelica.org/.
[19] E. N. Houstis, J. R. Rice, S. Weerawarana, A. C. Catlin, P. Papachiou, K.-Y. Wang, and M. Gaitatzes. PELLPACK: A ProblemSolving Environment for PDE-Based Applications on Multicomputer
Platforms. ACM Transactions on Mathematical Software, 24(1):3073,
March 1998.
[20] Nathan Ida and Jo
ao P.A. Bastos. Electromagnetics and Calculation of
Fields, chapter 9.10, pages 391392. Springer, 2nd edition, 1997.
[21] G. Kahn. Natural semantics. In Proceedings of the Symposium on
Theoretical Aspects of Computer Science, STACS87, volume 247 of
LNCS, pages 2239. Springer-Verlag, 1987.

80

References
[22] D. K
agedal. A Natural Semantics Specication for the Equation-based
Modeling Language Modelica. Masters thesis, PELAB, Dept. of Computer and Information Science, Link
opings universitet, October 1998.
LiTH-IDA-Ex-98/48.
[23] D. K
agedal and P. Fritzson. Generating a Modelica Compiler from
Natural Semantics Specications. In Proceedings of the 1998 Summer
Computer Simulation Conference (SCSC98), Reno, Nevada, July 1998.
[24] Macsyma home page. http://www.scientek.com/macsyma/main.htm.
[25] MathCore. http://www.mathcore.com.
[26] R. Milner, M. Tofte, R. Harper, and D. MacQueen. The Denition of
Standard ML (Revised). MIT Press, 1997.
[27] Modelica Association. Modelica A Unied Object-Oriented Language
for Physical Systems Modeling - Language Specication Version 2.0,
Jan 2002. http://www.modelica.org/.
[28] Modelica Association. Modelica Standard Library, 2002. http://www.
modelica.org/libraries.shtml.
[29] NETLIB home page. http://www.netlib.org/.
[30] M. Oh. Modelling and Simulation of Combined Lumped and Distributed
Processes. PhD thesis, University of London, 1995.
[31] Open Source Modelica home page. http://www.ida.liu.se/~pelab/
modelica.
[32] Overture home page. http://www.llnl.gov/CASC/Overture/.
[33] M. Pettersson. Compiling Natural Semantics. volume 1549 of LNCS.
Springer-Verlag, 1999.
[34] J. R. Rice. An Agent-based Architecture for Solving Partial Dierential
Equations. SIAM News, 31(6), 1998.
[35] L. Saldamli and P. Fritzson. Object-Oriented Modeling with Partial
Dierential Equations. In Proc. of Modelica Workshop 2000, Lund,
Sweden, October 2000. http://www.modelica.org/.
[36] L. Saldamli and P. Fritzson. Domains and Partial Dierential Equations
in Modelica. In Tor Anders Hauge, Bernt Lie, Rolf Ergon, Marta Due
nas Des, Glenn-Ole Kaasa, Anita Dale, Bjorn Glemmestad, and Are
Mjaavatten, editors, Proc. of the 42nd SIMS Conference, Porsgrunn,
Norway, October 2001.

81

References
[37] L. Saldamli and P. Fritzson. A Modelica-based Language for ObjectOriented Modeling with Partial Dierential Equations. In A. Heemink,
L. Dekker, H. de Swaan Arons, I. Smith, and T. van Stijn, editors, Proc.
of the 4th International EUROSIM Congress, Delft, The Netherlands,
June 2001.
[38] L. Saldamli, P. Fritzson, and B. Bachmann. Extending Modelica for
Partial Dierential Equations. In Martin Otter, editor, Proc. of the 2nd
International Modelica Conference, Oberpfaenhofen, Germany, March
2002.
[39] Pierre Saramito and Nicolas Roquet. Rheolef home page. http://
www-lmc.imag.fr/lmc-edp/Pierre.Saramito/rheolef/, 2002.
[40] Pierre Saramito and Nicolas Roquet. Rheolef users manual. Technical report, LMC-IMAG, 2002. http://www-lmc.imag.fr/lmc-edp/
Pierre.Saramito/rheolef/usrman.ps.gz.
[41] K. Sheshadri and P. Fritzson. A Mathematica-based PDE-solver generator. In Proc. of the Scandinavian Simulation Society (SIMS) Conference, Linko
ping University, Linko
ping, Sweden, September 1999.
[42] K. Sheshadri and P. Fritzson. A General Symbolic PDE-Solver Generator: Explicit Schemes. Accepted for publication in Scientic Programming, 2001.
[43] G. D. Smith. Numerical Solution of Partial Dierential Equations:
Finite Dierence Methods, chapter one, pages 69. Oxford University
Press, third edition, 1985.
[44] K.
Ahlander. An Object-Oriented Framework for PDE Solvers. PhD
thesis, Uppsala University, 1999.
[45] Hubertus Tummescheit. Design and Implementation of Object-Oriented
Model Libraries using Modelica. PhD thesis, Lund Institute of Technology, 2002.
[46] S. Weerawarana. Problem Solving Environments for Partial Dierential
Equation based Applications. PhD thesis, Department of Computer
Sciences, Purdue University, August 1994.

82

Appendix A.
PDE Solver Using Rheolef
Rheolef specic parts from RheolefSolver.cc:
/

 Common r o u t i n e to c r e a t e th e Xh s p a c e based on th e
 boundary c o n d i t i o n s .
/

void makeXh ( geo &

const
const
space

omega ,
string & eltype ,
v e c t o r<BoundaryCondition > & b c l i s t ,
& Xh ) {

domain t o b l o c k ;
i n t n d i r =0;
f o r ( unsigned i n t i = 0 ; i<b c l i s t . s i z e ( ) ; i ++) {
domain d = omega [ b c l i s t [ i ] . getName ( ) ] ;
if ( bclist [ i ]. is dirichlet ) {
n d i r ++;
t o b l o c k += d ;
}
}
i f ( ndir > 0)
Xh . b l o c k ( t o b l o c k ) ;
}
/

 Steadys t a t e s o l v e r . e l t y p e i s one o f th e e l e m e n t t y p e s
 used i n R h e o l e f , e . g . P1 . Each DomainRegion c o n t a i n s
 th e c and f c o e f f i c i e n t s o f th e PDE . Only d i f f e r e n t
 c c o e f f i c i e n t s a r e s u p p o r te d ( same f f o r th e e n t i r e
 domain ) .
/

void h e a t g e n e r i c ( geo & omega ,

const v e c t o r<BoundaryCondition > & b c l i s t ,
const s t r i n g & e l t y p e ,
DomainRegion : : s p a c e f u n c t i o n p t r f ,
const v e c t o r<DomainRegion > & r e g l i s t ) {

83

Appendix A. PDE Solver Using Rheolef

i n t nneumann = 0 , n r o b i n =0;
s p a c e Xh( omega , e l t y p e ) ;
makeXh ( omega , e l t y p e , b c l i s t , Xh ) ;
s p a c e Qh ( omega , P0 , v e c t o r ) ;
f i e l d e t a ( Qh , 1 ) ;
i f ( r e g l i s t . s i z e () == 1) {
e t a = r e g l i s t [ 0 ] . pde>c ;
}
else {
f o r ( unsigned i n t i = 0 ; i< r e g l i s t . s i z e ( ) ; i ++) {
e t a [ r e g l i s t [ i ] . name ] = r e g l i s t [ i ] . pde>c ;
c o u t << r e g l i s t [ i ] . name << = << r e g l i s t [ i ] . pde>c ;
c o u t << e n d l ;
}
}
form diag d ( eta ) ;
form grad ( Xh , Qh , grad ) ;
form m ( Xh , Xh , mass ) ;
form inv m ( Qh , Qh , i n v m a s s ) ;
f i e l d f h = i n t e r p o l a t e ( Xh , f ) ;
f i e l d uh ( Xh ) ;
v e c<F l o a t > s o l v e c = m. uu  f h . u + m. ub  f h . b ;
form a = t r a n s ( grad )  ( inv m  d )  grad ;
f o r ( unsigned i n t i = 0 ; i< b c l i s t . s i z e ( ) ; i ++) {
domain d = omega [ b c l i s t [ i ] . getName ( ) ] ;
s p a c e Wh ( omega , d , e l t y p e ) ;
f i e l d gh = i n t e r p o l a t e (Wh, b c l i s t [ i ] . g ) ;
if ( bclist [ i ]. is dirichlet ) {
uh [ d ] = gh ;
} else {
form mb (Wh, Xh , mass bdr ) ;
s o l v e c += mb . uu  gh . u + mb . ub  gh . b ;
i f ( b c l i s t [ i ] . q == 0)
nneumann++;
else {
n r o b i n++;
form ab ( Xh , Xh , mass bdr , d ) ;
a = a + b c l i s t [ i ] . q  ab ;
}
}
}

84

s o l v e c = a . ub  uh . b ;
s s k<F l o a t > f a c t = l d l t ( a . uu ) ;
uh . u = f a c t . s o l v e ( s o l v e c ) ;
c o u t << uh ;
}
/

 Time dependent s o l v e r . Time d e r i v a t i v e i s approximated

 with th e backward E u l e r scheme ( Langtangen  p . 1 2 3 ) .
 S o l u t i o n from th e p r e v i o u s time s t e p must be s e n t i n th e
 uprev p a r a m e te r .
/

void h e a t g e n e r i c t i m e ( geo & omega ,

const v e c t o r<BoundaryCondition > & b c l i s t ,
const s t r i n g & e l t y p e ,
F l o a t da ,
Float c ,
BoundaryCondition : : s p a c e f u n c t i o n p t r f ,
F l o a t dt ,
f i e l d & uprev ,
const v e c t o r<DomainRegion > & r e g l i s t ) {
i n t nneumann = 0 , n r o b i n =0;
dt = dt / da ;
s p a c e Xh( omega , e l t y p e ) ;
makeXh ( omega , e l t y p e , b c l i s t , Xh ) ;
s p a c e Qh ( omega , P0 , v e c t o r ) ;
f i e l d e t a ( Qh ) ;
i f ( r e g l i s t . s i z e () == 1) {
e t a = r e g l i s t [ 0 ] . pde>c ;
}
else {
f o r ( unsigned i n t i = 0 ; i< r e g l i s t . s i z e ( ) ; i ++) {
e t a [ r e g l i s t [ i ] . name ] = r e g l i s t [ i ] . pde>c ;
c o u t << r e g l i s t [ i ] . name << = << r e g l i s t [ i ] . pde>c ;
c o u t << e n d l ;
}
}
form diag d ( eta ) ;
form grad ( Xh , Qh , grad ) ;
form m ( Xh , Xh , mass ) ;
form inv m ( Qh , Qh , i n v m a s s ) ;

85

Appendix A. PDE Solver Using Rheolef

f i e l d f h = dt  i n t e r p o l a t e ( Xh , f ) + uprev ;
f i e l d uh ( Xh ) ;
v e c<F l o a t > s o l v e c = m. uu  f h . u + m. ub  f h . b ;
form ut ( Xh , Xh , mass ) ;
form a = ut dt  t r a n s ( grad )  ( inv m  d )  grad ;
/ / t h e t a = 1 , backward e u l e r scheme . See Langtangen p . 1 2 3
f o r ( unsigned i n t i = 0 ; i< b c l i s t . s i z e ( ) ; i ++) {
domain d = omega [ b c l i s t [ i ] . getName ( ) ] ;
s p a c e Wh ( omega , d , e l t y p e ) ;
f i e l d gh = i n t e r p o l a t e (Wh, b c l i s t [ i ] . g ) ;
if ( bclist [ i ]. is dirichlet ) {
uh [ d ] = gh ;
} else {
form mb (Wh, Xh , mass bdr ) ;
mb = dt  mb ;
s o l v e c += mb . uu  gh . u + mb . ub  gh . b ;
i f ( b c l i s t [ i ] . q == 0)
nneumann++;
else {
n r o b i n++;
form ab ( Xh , Xh , mass bdr , d ) ;
a = a + b c l i s t [ i ] . q  dt  ab ;
}
}
}
s o l v e c = a . ub  uh . b ;
s s k<F l o a t > f a c t = l d l t ( a . uu ) ;
uh . u = f a c t . s o l v e ( s o l v e c ) ;
uprev = uh ;
}

86

Appendix B.
FEMLAB Domain Generation
Interface Routine
The Matlab routine femlabdomainfix for reordering of the boundary conditions after FEMLABs vertex sorting. The input variables are the array
of points with coordinates and boundary condition indices v, the array of
edges with vertex indices and boundary condition indices and e. The output variables are the generated FEMLAB polygon object poly and the array
neweb of boundary condition indices with the correct order according to the
created polygon.

femlabdomainfix.m:
vx = v ( : , 1 ) ;
vy = v ( : , 2 ) ;
vb = v ( : , 3 ) ;
es = e ( : , 1 ) ;
ee = e ( : , 2 ) ;
eb = e ( : , 3 ) ;
p o l y=l i n e 2 ( vx , vy ) ;
n e w v e r t i c e s=flgeomvtx ( p o l y ) ;
newedges=flgeomse ( p o l y ) ;
newvx=n e w v e r t i c e s ( : , 1 ) ;
newvy=n e w v e r t i c e s ( : , 2 ) ;
newes=newedges ( : , 1 ) ;
newee=newedges ( : , 2 ) ;
n=length ( newes ) ;
neweb=ones ( n , 1 ) ;

87

Appendix B. FEMLAB Domain Generation Interface Routine

myeps = ep s  1 0 0 ;
f o r i =1: n
news = newes ( i ) ;
newe = newee ( i ) ;
newsx = newvx ( news ) ;
newsy = newvy ( news ) ;
newex = newvx ( newe ) ;
newey = newvy ( newe ) ;
f o r j =1:n
s2 = es ( j ) ;
e2 = ee ( j ) ;
s x = vx ( s 2 ) ;
s y = vy ( s 2 ) ;
ex = vx ( e2 ) ;
ey = vy ( e2 ) ;
i f ( ( abs ( newsxs x ) <
( abs ( newexex ) <
( ( abs ( newsxex ) <
( abs ( newexs x ) <
neweb ( i ) = eb ( j ) ;
end
end
end

88

myeps )
myeps )
myeps )
myeps )

&
&
&
&

( abs ( newsys y )
( abs ( neweyey )
( abs ( newsyey )
( abs ( neweys y )

<
<
<
<

myeps ) & . . .
myeps ) ) | . . .
myeps ) & . . .
myeps ) )

Appendix C.
Problem Formulation Generated
for FEMLAB
The generated problem formulation code for the heat transfer example in
Section 6.3 for solving with FEMLAB. The arrays v and e are passed to
femlabdomainfix.m, shown in Appendix B, which creates the FEMLAB
polygon in poly and puts the boundary conditions in neweb.

femlabproblem.m:
c l e a r fem ;
fem . dim = { u } ;
fem . form = c o e f f i c i e n t ;
fem . equ . f = 0 ;
fem . equ . c = 1 ;
bnd . g = { { { 1 . 0 8 e + 0 6 } } , { { 0 } } , { { 0 } } ,
{{0}}, {{0}}, {{0}}};
bnd . q = { { { 3 0 0 0 0 } } , { { 0 } } , { { 0 } } ,
{{0}}, {{0}}, {{0}}};
bnd . h = { { { 0 } } , { { 0 } } , { { 0 } } ,
{{0}}, {{1}}, {{0}}};
bnd . r = { { { 0 } } , { { 0 } } , { { 0 } } ,
{{0}}, {{60}}, {{0}}};
v = [1 2 1;0.989529 1.70911 1;0.87162 1.50575 1;0.670313
1.36317 1;0.407803 1.25928 1;0.104429 1.17629 1;0.221312
1.10036 1;0.552779 1.02119 1;0.875175 0.93169
1;1.17556 0.827545 1;1.44283 0.706894 1;1.66774
0.569928 1;1.8429 0.418526 1;1.96275 0.255877 1;2.0236
0.0861045 1;2.0236 0.0861045 1;1.96275 0.255877 1;1.8429
0.418526 1;1.66774 0.569928 1;1.44283 0.706894 1;1.17556
0.827545 1;0.875175 0.93169 1;0.552779 1.02119 1;0.221312
1.10036 1;0.104429 1.17629 1;0.407803 1.25928 1;0.670313
1.36317 1;0.87162 1.50575 1;0.989529 1.70911 1;1 2 1;1 2

89

Appendix C. Problem Formulation Generated for FEMLAB

2;1.21656 1.99413 3;1.43248 1.97655 3;1.64713 1.94731
3;1.85988 1.90648 3;2.07011 1.8542 3;2.27721 1.79061
3;2.48055 1.71591 3;2.67956 1.6303 3;2.87363 1.53405
3;3.06222 1.42743 3;3.24475 1.31076 3;3.4207 1.18437
3;3.58955 1.04865 3;3.7508 0.903982 3;3.90398 0.750798
3;4.04865 0.589545 3;4.18437 0.420697 3;4.31076 0.244748
3;4.42743 0.0622154 3;4.53405 0.126366 3;4.6303
0.320444 3;4.71591 0.519447 3;4.79061 0.722794
3;4.8542 0.929887 3;4.90648 1.14012 3;4.94731 1.35287
3;4.97655 1.56752 3;4.99413 1.78344 3;5 2 3;3 2 4;1
2 5;];
e = [1 2 1;2 3 1;3 4 1;4 5 1;5 6 1;6 7 1;7 8 1;8 9 1;9 10
1;10 11 1;11 12 1;12 13 1;13 14 1;14 15 1;15 16 1;16 17 1;17
18 1;18 19 1;19 20 1;20 21 1;21 22 1;22 23 1;23 24 1;24 25
1;25 26 1;26 27 1;27 28 1;28 29 1;29 30 1;30 31 2;31 32 3;32
33 3;33 34 3;34 35 3;35 36 3;36 37 3;37 38 3;38 39 3;39 40
3;40 41 3;41 42 3;42 43 3;43 44 3;44 45 3;45 46 3;46 47 3;47
48 3;48 49 3;49 50 3;50 51 3;51 52 3;52 53 3;53 54 3;54 55
3;55 56 3;56 57 3;57 58 3;58 59 3;59 60 3;60 61 4;61 62 5;62
1 6;];
myhmax = 0 . 1 ;
run . / s o l v e r / f e m l a b d o m a i n f i x .m;
bnd . i n d = neweb ;
fem . bnd = bnd ;
fem . geom = p o l y ;
fem . mesh = meshinit ( fem , hmax , myhmax ) ;
fem . s o l = femlin ( fem ) ;

90

Appendix D.
PDE Formulation Generated for
Mathematica Based Solver
The generated problem formulation code for the heat transfer example in
Section 6.3 for the Mathematica based FEM solver. Two les are generated, the rst one for the solver generation and then code generation using
MathCode, and the second one for the execution of the solver.

Solver generation code:

Needs [ MathFEM ] ;
p a r a m e te r s = { } ; p a r t y p e s = { } ;
pdeeq = { 1  (D[ v [ x , y ] , { x , 2 } ] + D[ v [ x , y ] , { y , 2 } ] ) = = 0 } ;
boundaryconditions = {
{ 1 , 1  OutwardNormalDer [ v [ x , y ] , 1 ] + 3 0 0 0 0  v [ x+y ]==1.08 e +06},
{ 2 , 1  OutwardNormalDer [ v [ x , y ] , 1 ] = = 0 } ,
{ 3 , 1  OutwardNormalDer [ v [ x , y ] , 1 ] = = 0 } ,
{ 4 , 1  OutwardNormalDer [ v [ x , y ] , 1 ] = = 0 } ,
{ 5 , v [ x , y ]==60},
{ 6 , 1  OutwardNormalDer [ v [ x , y ] , 1 ] = = 0 }
};
e q u a t i o n s = Prepend [ b o u n d a r y c o n d i t i o n s , pdeeq ] ;
meshdata =
EasyMeshData [ { mathfemmesh . n , mathfemmesh . e , mathfemmesh . s } ,
6];
{Nn , Ne , nmark , m a x s i z e 1 , m a x s i z e 2 , m a t s i z e , I n t e r i o r S i z e } =
{Length [ meshdata [ [ 5 ] ] ] ,
Length [ meshdata [ [ 6 ] ] ] ,
Length [ meshdata [ [ 1 ] ] ] ,
Apply [Max, Map[ Length , meshdata [ [ 1 ] ] ] ] ,
Apply [Max, Map[ Length , meshdata [ [ 7 ] ] ] ] ,
Apply [ Plus , Append [ meshdata [ [ 3 ] ] , meshdata [ [ 4 ] ] ] ] ,
meshdata [ [ 4 ] ]

91

Appendix D. PDE Formulation Generated for Mathematica Based Solver

};
Attributes [ d e c l a r e ]={ HoldAll } ;
s ta t e m e n t =
Statement [ d e c l a r e , p a r t y p e s , Nn , Ne , nmark ,
maxsize1 , maxsize2 , matsize , I n t e r i o r S i z e ] ;
Clear [ mat1 ] ;
mat1 [ n1 , n2 ] : = MATRIX [ [ 1 | n1 , 1 | n2 ] ] ;
Off [ Syntax : : s n t o c t 1 ] ;
Needs [ MathCode ] ;
( BeginPackage [ MathFEM , { T o E x p r es s i o n [ MathCodeContexts ] } ] ;
Begin [ MathFEM ] ;
s ta t e m e n t / . d e c l a r e : > T o E x p r e s s i o n [ D e c l a r e ] ;
End [ ] ;
Begin [ MathFEM P r i v a t e ] ;
End [ ] ;
EndPackage [ ] ; ) ;
BuildCode [ MathFEM , Language > C++] ;

Solver execution code:

Needs [ MathFEM ] ;
Off [ Syntax : : s n t o c t 1 ] ;
Needs [ MathCode ] ;
I n s t a l l C o d e [ MathFEM ] ;
meshdata =
EasyMeshData [ { mathfemmesh . n , mathfemmesh . e , mathfemmesh . s } ,
6];
{Nn , Ne , nmark , m a x s i z e 1 , m a x s i z e 2 , m a t s i z e , I n t e r i o r S i z e } =
{Length [ meshdata [ [ 5 ] ] ] ,
Length [ meshdata [ [ 6 ] ] ] ,
Length [ meshdata [ [ 1 ] ] ] ,
Apply [Max, Map[ Length , meshdata [ [ 1 ] ] ] ] ,
Apply [Max, Map[ Length , meshdata [ [ 7 ] ] ] ] ,
Apply [ Plus , Append [ meshdata [ [ 3 ] ] , meshdata [ [ 4 ] ] ] ] ,
meshdata [ [ 4 ] ]
};
paramvalues = {} ;
Apply [ G e n e r a t e M a t r i c e s , J o i n [ meshdata , p a r a m v a l u es ] ] ;
l i s t 1 = mat1 [ m a t s i z e , m a t s i z e + 1 ] ;
l h s = Table [ l i s t 1 [ [ i , j ] ] , { i , 1 , m a t s i z e } , { j , 1 , m a t s i z e } ] ;
r h s = Table [ l i s t 1 [ [ i , m a t s i z e + 1 ] ] , { i , 1 , m a t s i z e } ] ;
s o l u t i o n = LinearSolve [ l hs , rhs ] ;
s o l u t i o n >> s o l u t i o n .m ;

92

Datum
Date

Avdelning, Institution
Division, department

Institutionen fr datavetenskap
LINKPINGS UNIVERSITET

Sprk
Language

Svenska/Swedish
Engelska/English

2002-12-18

Department of Computer and

Information Science

Rapporttyp
Report: category

ISBN

ISRN

Licentiatavhandling
Examensarbete
C-uppsats
D-uppsats
vrig rapport

91- 7373-560-4
LiU-Tek-Lic- 2002:63

Serietitel och serienummer

Title of series, numbering

ISSN

0280-7971

Linkping Studies in Science and Technology

URL fr elektronisk version

Thesis No. 990

Titel
Title

PDEModelica - Towards a High-Level Language for Modeling with Partial Differential Equations
Frfattare
Author

Levon Saldamli

Sammandrag
Abstract

This thesis describes initial language extensions to the Modelica language to define a more general
language called PDEModelica, with built-in support for modeling with partial differential equations
(PDEs). Modelica is a standardized modeling language for object-oriented, equation-based modeling. It also supports component-based modeling where existing components with modified parameters can be combined into new models. The aim of the language presented in this thesis is to maintain
the advantages of Modelica and also add partial differential equation support.
Partial differential equations can be defined using a coefficient-based approach, where a predefined
PDE is modified by changing its coefficient values. Language operators to directly express PDEs in
the language are also discussed. Furthermore, domain geometry description is handled and language
extensions to describe geometries are presented. Boundary conditions, required for a complete PDE
problem definition, are also handled.
A prototype implementation is described as well. The prototype includes a translator written in the
relational meta-language, RML, and interfaces to external software such as mesh generators and PDE
solvers, which are needed to solve PDE problems. Finally, a few examples modeled with PDEModelica and solved using the prototype are presented.

Nyckelord
Keywords

modeling language, object-oriented, PDE, equation-based

Department of Computer and Information Science

Linkpings universitet
Linkping Studies in Science and Technology
Faculty of Arts and Sciences - Licentiate Theses
No 17
No 28
No 29
No 48
No 52
No 60
No 71
No 72
No 73
No 74
No 104
No 108
No 111
No 113
No 118
No 126
No 127
No 139
No 140
No 146
No 150
No 165
No 166
No 174
No 177
No 181
No 184
No 187
No 189
No 196
No 197
No 203
No 212
No 230
No 237
No 250
No 253
No 260
No 283
No 298
No 318
No 319
No 326
No 328
No 333
No 335
No 348
No 352
No 371
No 378
No 380
No 381
No 383
No 386
No 398

Vojin Plavsic: Interleaved Processing of Non-Numerical Data Stored on a Cyclic Memory. (Available at:
FOA, Box 1165, S-581 11 Linkping, Sweden. FOA Report B30062E)
Arne Jnsson, Mikael Patel: An Interactive Flowcharting Technique for Communicating and Realizing Algorithms, 1984.
Johnny Eckerland: Retargeting of an Incremental Code Generator, 1984.
Henrik Nordin: On the Use of Typical Cases for Knowledge-Based Consultation and Teaching, 1985.
Zebo Peng: Steps Towards the Formalization of Designing VLSI Systems, 1985.
Johan Fagerstrm: Simulation and Evaluation of Architecture based on Asynchronous Processes, 1985.
Jalal Maleki: ICONStraint, A Dependency Directed Constraint Maintenance System, 1987.
Tony Larsson: On the Specification and Verification of VLSI Systems, 1986.
Ola Strmfors: A Structure Editor for Documents and Programs, 1986.
Christos Levcopoulos: New Results about the Approximation Behavior of the Greedy Triangulation, 1986.
Shamsul I. Chowdhury: Statistical Expert Systems - a Special Application Area for Knowledge-Based Computer Methodology, 1987.
Rober Bilos: Incremental Scanning and Token-Based Editing, 1987.
Hans Block: SPORT-SORT Sorting Algorithms and Sport Tournaments, 1987.
Ralph Rnnquist: Network and Lattice Based Approaches to the Representation of Knowledge, 1987.
Mariam Kamkar, Nahid Shahmehri: Affect-Chaining in Program Flow Analysis Applied to Queries of Programs, 1987.
Dan Strmberg: Transfer and Distribution of Application Programs, 1987.
Kristian Sandahl: Case Studies in Knowledge Acquisition, Migration and User Acceptance of Expert Systems, 1987.
Christer Bckstrm: Reasoning about Interdependent Actions, 1988.
Mats Wirn: On Control Strategies and Incrementality in Unification-Based Chart Parsing, 1988.
Johan Hultman: A Software System for Defining and Controlling Actions in a Mechanical System, 1988.
Tim Hansen: Diagnosing Faults using Knowledge about Malfunctioning Behavior, 1988.
Jonas Lwgren: Supporting Design and Management of Expert System User Interfaces, 1989.
Ola Petersson: On Adaptive Sorting in Sequential and Parallel Models, 1989.
Yngve Larsson: Dynamic Configuration in a Distributed Environment, 1989.
Peter berg: Design of a Multiple View Presentation and Interaction Manager, 1989.
Henrik Eriksson: A Study in Domain-Oriented Tool Support for Knowledge Acquisition, 1989.
Ivan Rankin: The Deep Generation of Text in Expert Critiquing Systems, 1989.
Simin Nadjm-Tehrani: Contributions to the Declarative Approach to Debugging Prolog Programs, 1989.
Magnus Merkel: Temporal Information in Natural Language, 1989.
Ulf Nilsson: A Systematic Approach to Abstract Interpretation of Logic Programs, 1989.
Staffan Bonnier: Horn Clause Logic with External Procedures: Towards a Theoretical Framework, 1989.
Christer Hansson: A Prototype System for Logical Reasoning about Time and Action, 1990.
Bjrn Fjellborg: An Approach to Extraction of Pipeline Structures for VLSI High-Level Synthesis, 1990.
Patrick Doherty: A Three-Valued Approach to Non-Monotonic Reasoning, 1990.
Tomas Sokolnicki: Coaching Partial Plans: An Approach to Knowledge-Based Tutoring, 1990.
Lars Strmberg: Postmortem Debugging of Distributed Systems, 1990.
Torbjrn Nslund: SLDFA-Resolution - Computing Answers for Negative Queries, 1990.
Peter D. Holmes: Using Connectivity Graphs to Support Map-Related Reasoning, 1991.
Olof Johansson: Improving Implementation of Graphical User Interfaces for Object-Oriented KnowledgeBases, 1991.
Rolf G Larsson: Aktivitetsbaserad kalkylering i ett nytt ekonomisystem, 1991.
Lena Srmbck: Studies in Extended Unification-Based Formalism for Linguistic Description: An Algorithm for Feature Structures with Disjunction and a Proposal for Flexible Systems, 1992.
Mikael Pettersson: DML-A Language and System for the Generation of Efficient Compilers from Denotational Specification, 1992.
Andreas Kgedal: Logic Programming with External Procedures: an Implementation, 1992.
Patrick Lambrix: Aspects of Version Management of Composite Objects, 1992.
Xinli Gu: Testability Analysis and Improvement in High-Level Synthesis Systems, 1992.
Torbjrn Nslund: On the Role of Evaluations in Iterative Development of Managerial Support Sytems,
1992.
Ulf Cederling: Industrial Software Development - a Case Study, 1992.
Magnus Morin: Predictable Cyclic Computations in Autonomous Systems: A Computational Model and Implementation, 1992.
Mehran Noghabai: Evaluation of Strategic Investments in Information Technology, 1993.
Mats Larsson: A Transformational Approach to Formal Digital System Design, 1993.
Johan Ringstrm: Compiler Generation for Parallel Languages from Denotational Specifications, 1993.
Michael Jansson: Propagation of Change in an Intelligent Information System, 1993.
Jonni Harrius: An Architecture and a Knowledge Representation Model for Expert Critiquing Systems, 1993.
Per sterling: Symbolic Modelling of the Dynamic Environments of Autonomous Agents, 1993.
Johan Boye: Dependency-based Groudness Analysis of Functional Logic Programs, 1993.

No 402
No 406
No 414
No 417
No 436
No 437
No 440
FHS 3/94
FHS 4/94
No 441
No 446
No 450
No 451
No 452
No 455
FHS 5/94
No 462
No 463
No 464
No 469
No 473
No 475
No 476
No 478
FHS 7/95
No 482
No 488
No 489
No 497
No 498
No 503
FHS 8/95
FHS 9/95
No 513
No 517
No 518
No 522
No 538
No 545
No 546
FiF-a 1/96
No 549
No 550
No 557
No 558
No 561
No 563
No 567
No 575
No 576
No 587
No 589
No 591
No 595
No 597

Lars Degerstedt: Tabulated Resolution for Well Founded Semantics, 1993.

Anna Moberg: Satellitkontor - en studie av kommunikationsmnster vid arbete p distans, 1993.
Peter Carlsson: Separation av fretagsledning och finansiering - fallstudier av fretagsledarutkp ur ett agentteoretiskt perspektiv, 1994.
Camilla Sjstrm: Revision och lagreglering - ett historiskt perspektiv, 1994.
Cecilia Sjberg: Voices in Design: Argumentation in Participatory Development, 1994.
Lars Viklund: Contributions to a High-level Programming Environment for a Scientific Computing, 1994.
Peter Loborg: Error Recovery Support in Manufacturing Control Systems, 1994.
Owen Eriksson: Informationssystem med verksamhetskvalitet - utvrdering baserat p ett verksamhetsinriktat och samskapande perspektiv, 1994.
Karin Pettersson: Informationssystemstrukturering, ansvarsfrdelning och anvndarinflytande - En komparativ studie med utgngspunkt i tv informationssystemstrategier, 1994.
Lars Poignant: Informationsteknologi och fretagsetablering - Effekter p produktivitet och region, 1994.
Gustav Fahl: Object Views of Relational Data in Multidatabase Systems, 1994.
Henrik Nilsson: A Declarative Approach to Debugging for Lazy Functional Languages, 1994.
Jonas Lind: Creditor - Firm Relations: an Interdisciplinary Analysis, 1994.
Martin Skld: Active Rules based on Object Relational Queries - Efficient Change Monitoring Techniques,
1994.
Pr Carlshamre: A Collaborative Approach to Usability Engineering: Technical Communicators and System
Developers in Usability-Oriented Systems Development, 1994.
Stefan Cronholm: Varfr CASE-verktyg i systemutveckling? - En motiv- och konsekvensstudie avseende arbetsstt och arbetsformer, 1994.
Mikael Lindvall: A Study of Traceability in Object-Oriented Systems Development, 1994.
Fredrik Nilsson: Strategi och ekonomisk styrning - En studie av Sandviks frvrv av Bahco Verktyg, 1994.
Hans Olsn: Collage Induction: Proving Properties of Logic Programs by Program Synthesis, 1994.
Lars Karlsson: Specification and Synthesis of Plans Using the Features and Fluents Framework, 1995.
Ulf Sderman: On Conceptual Modelling of Mode Switching Systems, 1995.
Choong-ho Yi: Reasoning about Concurrent Actions in the Trajectory Semantics, 1995.
Bo Lagerstrm: Successiv resultatavrkning av pgende arbeten. - Fallstudier i tre byggfretag, 1995.
Peter Jonsson: Complexity of State-Variable Planning under Structural Restrictions, 1995.
Anders Avdic: Arbetsintegrerad systemutveckling med kalkylkprogram, 1995.
Eva L Ragnemalm: Towards Student Modelling through Collaborative Dialogue with a Learning Companion, 1995.
Eva Toller: Contributions to Parallel Multiparadigm Languages: Combining Object-Oriented and Rule-Based
Programming, 1995.
Erik Stoy: A Petri Net Based Unified Representation for Hardware/Software Co-Design, 1995.
Johan Herber: Environment Support for Building Structured Mathematical Models, 1995.
Stefan Svenberg: Structure-Driven Derivation of Inter-Lingual Functor-Argument Trees for Multi-Lingual
Generation, 1995.
Hee-Cheol Kim: Prediction and Postdiction under Uncertainty, 1995.
Dan Fristedt: Metoder i anvndning - mot frbttring av systemutveckling genom situationell metodkunskap
och metodanalys, 1995.
Malin Bergvall: Systemfrvaltning i praktiken - en kvalitativ studie avseende centrala begrepp, aktiviteter och
ansvarsroller, 1995.
Joachim Karlsson: Towards a Strategy for Software Requirements Selection, 1995.
Jakob Axelsson: Schedulability-Driven Partitioning of Heterogeneous Real-Time Systems, 1995.
Gran Forslund: Toward Cooperative Advice-Giving Systems: The Expert Systems Experience, 1995.
Jrgen Andersson: Bilder av smfretagares ekonomistyrning, 1995.
Staffan Flodin: Efficient Management of Object-Oriented Queries with Late Binding, 1996.
Vadim Engelson: An Approach to Automatic Construction of Graphical User Interfaces for Applications in
Scientific Computing, 1996.
Magnus Werner : Multidatabase Integration using Polymorphic Queries and Views, 1996.
Mikael Lind: Affrsprocessinriktad frndringsanalys - utveckling och tillmpning av synstt och metod,
1996.
Jonas Hallberg: High-Level Synthesis under Local Timing Constraints, 1996.
Kristina Larsen: Frutsttningar och begrnsningar fr arbete p distans - erfarenheter frn fyra svenska fretag. 1996.
Mikael Johansson: Quality Functions for Requirements Engineering Methods, 1996.
Patrik Nordling: The Simulation of Rolling Bearing Dynamics on Parallel Computers, 1996.
Anders Ekman: Exploration of Polygonal Environments, 1996.
Niclas Andersson: Compilation of Mathematical Models to Parallel Code, 1996.
Johan Jenvald: Simulation and Data Collection in Battle Training, 1996.
Niclas Ohlsson: Software Quality Engineering by Early Identification of Fault-Prone Modules, 1996.
Mikael Ericsson: Commenting Systems as Design SupportA Wizard-of-Oz Study, 1996.
Jrgen Lindstrm: Chefers anvndning av kommunikationsteknik, 1996.
Esa Falkenroth: Data Management in Control Applications - A Proposal Based on Active Database Systems,
1996.
Niclas Wahllf: A Default Extension to Description Logics and its Applications, 1996.
Annika Larsson: Ekonomisk Styrning och Organisatorisk Passion - ett interaktivt perspektiv, 1997.
Ling Lin: A Value-based Indexing Technique for Time Sequences, 1997.

No 598
No 599
No 607
No 609
FiF-a 4
FiF-a 6
No 615
No 623
No 626
No 627
No 629
No 631
No 639
No 640
No 643
No 653
FiF-a 13
No 674
No 676
No 668
No 675
FiF-a 14
No 695
No 700
FiF-a 16
No 712
No 719
No 723
No 725
No 730
No 731
No 733
No 734
FiF-a 21
FiF-a 22
No 737
No 738
FiF-a 25
No 742
No 748
No 751
No 752
No 753
No 754
No 766
No 769
No 775
FiF-a 30
No 787
No 788
No 790
No 791
No 800
No 807

Rego Granlund: C3Fire - A Microworld Supporting Emergency Management Training, 1997.

Peter Ingels: A Robust Text Processing Technique Applied to Lexical Error Recovery, 1997.
Per-Arne Persson: Toward a Grounded Theory for Support of Command and Control in Military Coalitions,
1997.
Jonas S Karlsson: A Scalable Data Structure for a Parallel Data Server, 1997.
Carita bom: Videomtesteknik i olika affrssituationer - mjligheter och hinder, 1997.
Tommy Wedlund: Att skapa en fretagsanpassad systemutvecklingsmodell - genom rekonstruktion, vrdering och vidareutveckling i T50-bolag inom ABB, 1997.
Silvia Coradeschi: A Decision-Mechanism for Reactive and Coordinated Agents, 1997.
Jan Ollinen: Det flexibla kontorets utveckling p Digital - Ett std fr multiflex? 1997.
David Byers: Towards Estimating Software Testability Using Static Analysis, 1997.
Fredrik Eklund: Declarative Error Diagnosis of GAPLog Programs, 1997.
Gunilla Ivefors: Krigsspel coh Informationsteknik infr en ofrutsgbar framtid, 1997.
Jens-Olof Lindh: Analysing Traffic Safety from a Case-Based Reasoning Perspective, 1997
Jukka Mki-Turja:. Smalltalk - a suitable Real-Time Language, 1997.
Juha Takkinen: CAFE: Towards a Conceptual Model for Information Management in Electronic Mail, 1997.
Man Lin: Formal Analysis of Reactive Rule-based Programs, 1997.
Mats Gustafsson: Bringing Role-Based Access Control to Distributed Systems, 1997.
Boris Karlsson: Metodanalys fr frstelse och utveckling av systemutvecklingsverksamhet. Analys och vrdering av systemutvecklingsmodeller och dess anvndning, 1997.
Marcus Bjreland: Two Aspects of Automating Logics of Action and Change - Regression and Tractability,
1998.
Jan Hkegrd: Hiera rchical Test Architecture and Board-Level Test Controller Synthesis, 1998.
Per-Ove Zetterlund: Normering av svensk redovisning - En studie av tillkomsten av Redovisningsrdets rekommendation om koncernredovisning (RR01:91), 1998.
Jimmy Tjder: Projektledaren & planen - en studie av projektledning i tre installations- och systemutvecklingsprojekt, 1998.
Ulf Melin: Informationssystem vid kad affrs- och processorientering - egenskaper, strategier och utveckling, 1998.
Tim Heyer: COMPASS: Introduction of Formal Methods in Code Development and Inspection, 1998.
Patrik Hgglund: Programming Languages for Computer Algebra, 1998.
Marie-Therese Christiansson: Inter-organistorisk verksamhetsutveckling - metoder som std vid utveckling
av partnerskap och informationssystem, 1998.
Christina Wennestam: Information om immateriella resurser. Investeringar i forskning och utveckling samt
i personal inom skogsindustrin, 1998.
Joakim Gustafsson: Extending Temporal Action Logic for Ramification and Concurrency, 1998.
Henrik Andr-Jnsson: Indexing time-series data using text indexing methods, 1999.
Erik Larsson: High-Level Testability Analysis and Enhancement Techniques, 1998.
Carl-Johan Westin: Informationsfrsrjning: en frga om ansvar - aktiviteter och uppdrag i fem stora svenska organisationers operativa informationsfrsrjning, 1998.
se Jansson: Miljhnsyn - en del i fretags styrning, 1998.
Thomas Padron-McCarthy: Performance-Polymorphic Declarative Queries, 1998.
Anders Bckstrm: Vrdeskapande kreditgivning - Kreditriskhantering ur ett agentteoretiskt perspektiv,
1998.
Ulf Seigerroth: Integration av frndringsmetoder - en modell fr vlgrundad metodintegration, 1999.
Fredrik berg: Object-Oriented Frameworks - A New Strategy for Case Tool Development, 1998.
Jonas Mellin: Predictable Event Monitoring, 1998.
Joakim Eriksson: Specifying and Managing Rules in an Active Real-Time Database System, 1998.
Bengt E W Andersson: Samverkande informationssystem mellan aktrer i offentliga taganden - En teori om
aktrsarenor i samverkan om utbyte av information, 1998.
Pawel Pietrzak: Static Incorrectness Diagnosis of CLP (FD), 1999.
Tobias Ritzau: Real-Time Reference Counting in RT-Java, 1999.
Anders Ferntoft: Elektronisk affrskommunikation - kontaktkostnader och kontaktprocesser mellan kunder
och leverantrer p producentmarknader,1999.
Jo Skmedal: Arbete p distans och arbetsformens pverkan p resor och resmnster, 1999.
Johan Alvehus: Mtets metaforer. En studie av berttelser om mten, 1999.
Magnus Lindahl: Bankens villkor i lneavtal vid kreditgivning till hgt belnade fretagsfrvrv: En studie
ur ett agentteoretiskt perspektiv, 2000.
Martin V. Howard: Designing dynamic visualizations of temporal data, 1999.
Jesper Andersson: Towards Reactive Software Architectures, 1999.
Anders Henriksson: Unique kernel diagnosis, 1999.
Pr J. gerfalk: Pragmatization of Information Systems - A Theoretical and Methodological Outline, 1999.
Charlotte Bjrkegren: Learning for the next project - Bearers and barriers in knowledge transfer within an
organisation, 1999.
Hkan Nilsson: Informationsteknik som drivkraft i granskningsprocessen - En studie av fyra revisionsbyrer,
2000.
Erik Berglund: Use-Oriented Documentation in Software Development, 1999.
Klas Gre: Verksamhetsfrndringar i samband med IS-infrande, 1999.
Anders Subotic: Software Quality Inspection, 1999.
Svein Bergum: Managerial communication in telework, 2000.

No 809
FiF-a 32
No 808
No 820
No 823
No 832
FiF-a 34
No 842
No 844
FiF-a 37
FiF-a 40
FiF-a 41
No. 854
No 863
No 881
No 882
No 890
Fif-a 47
No 894
No 906
No 917
No 916
Fif-a-49
Fif-a-51
No 919
No 915
No 931
No 933
No 938
No 942
No 956
FiF-a 58
No 964
No 973
No 958
Fif-a 61
No 985
No 982
No 989
No 990

Flavius Gruian: Energy-Aware Design of Digital Systems, 2000.

Karin Hedstrm: Kunskapsanvndning och kunskapsutveckling hos verksamhetskonsulter - Erfarenheter
frn ett FOU-samarbete, 2000.
Linda Askens: Affrssystemet - En studie om teknikens aktiva och passiva roll i en organisation, 2000.
Jean Paul Meynard: Control of industrial robots through high-level task programming, 2000.
Lars Hult: Publika Grnsytor - ett designexempel, 2000.
Paul Pop: Scheduling and Communication Synthesis for Distributed Real-Time Systems, 2000.
Gran Hultgren: Ntverksinriktad Frndringsanalys - perspektiv och metoder som std fr frstelse och
utveckling av affrsrelationer och informationssystem, 2000.
Magnus Kald: The role of management control systems in strategic business units, 2000.
Mikael Cker: Vad kostar kunden? Modeller fr intern redovisning, 2000.
Ewa Braf: Organisationers kunskapsverksamheter - en kritisk studie av knowledge management, 2000.
Henrik Lindberg: Webbaserade affrsprocesser - Mjligheter och begrnsningar, 2000.
Benneth Christiansson: Att komponentbasera informationssystem - Vad sger teori och praktik?, 2000.
Ola Pettersson: Deliberation in a Mobile Robot, 2000.
Dan Lawesson: Towards Behavioral Model Fault Isolation for Object Oriented Control Systems, 2000.
Johan Moe: Execution Tracing of Large Distributed Systems, 2001.
Yuxiao Zhao: XML-based Frameworks for Internet Commerce and an Implementation of B2B
e-procurement, 2001.
Annika Flycht-Eriksson: Domain Knowledge Management inInformation-providing Dialogue systems,
2001.
Per-Arne Segerkvist: Webbaserade imaginra organisationers samverkansformer, 2001.
Stefan Svarn: Styrning av investeringar i divisionaliserade fretag - Ett koncernperspektiv, 2001.
Lin Han: Secure and Scalable E-Service Software Delivery, 2001.
Emma Hansson: Optionsprogram fr anstllda - en studie av svenska brsfretag, 2001.
Susanne Odar: IT som std fr strategiska beslut, en studie av datorimplementerade modeller av verksamhet
som std fr beslut om anskaffning av JAS 1982, 2002.
Stefan Holgersson: IT-system och filtrering av verksamhetskunskap - kvalitetsproblem vid analyser och beslutsfattande som bygger p uppgifter hmtade frn polisens IT-system, 2001.
Per Oscarsson:Informationsskerhet i verksamheter - begrepp och modeller som std fr frstelse av informationsskerhet och dess hantering, 2001.
Luis Alejandro Cortes: A Petri Net Based Modeling and Verification Technique for Real-Time Embedded
Systems, 2001.
Niklas Sandell: Redovisning i skuggan av en bankkris - Vrdering av fastigheter. 2001.
Fredrik Elg: Ett dynamiskt perspektiv p individuella skillnader av heuristisk kompetens, intelligens, mentala
modeller, ml och konfidens i kontroll av mikrovrlden Moro, 2002.
Peter Aronsson: Automatic Parallelization of Simulation Code from Equation Based Simulation Languages,
2002.
Bourhane Kadmiry: Fuzzy Control of Unmanned Helicopter, 2002.
Patrik Haslum: Prediction as a Knowledge Representation Problem: A Case Study in Model Design, 2002.
Robert Sevenius: On the instruments of governance - A law & economics study of capital instruments in limited liability companies, 2002.
Johan Petersson: Lokala elektroniska marknadsplatser - informationssystem fr platsbundna affrer, 2002.
Peter Bunus: Debugging and Structural Analysis of Declarative Equation-Based Languages, 2002.
Gert Jervan: High-Level Test Generation and Built-In Self-Test Techniques for Digital Systems, 2002.
Fredrika Berglund: Management Control and Strategy - a Case Study of Pharmaceutical Drug Development,
2002.
Fredrik Karlsson: Meta-Method for Method Configuration - A Rational Unified Process Case, 2002.
Sorin Manolache: Schedulability Analysis of Real-Time Systems with Stochastic Task Execution Times,
2002.
Diana Szentivnyi: Performance and Availability Trade-offs in Fault-Tolerant Middleware, 2002.
Iakov Nakhimovski: Modeling and Simulation of Contacting Flexible Bodies in Multibody Systems, 2002.
Levon Saldamli: PDEModelica - Towards a High-Level Language for Modeling with Partial Differential
Equations, 2002.