Proceedings

of the 4th International Modelica Conference,

Hamburg, March 7-8, 2005,
Gerhard Schmitz (editor)

M. Najafi, S. Furic, R. Nikoukhah

Imagine; INRIA-Rocquencourt, France
SCICOS: a general purpose modeling and simulation environment
pp. 367-374

Paper presented at the 4th International Modelica Conference, March 7-8, 2005,
Hamburg University of Technology, Hamburg-Harburg, Germany,
organized by The Modelica Association and the Department of Thermodynamics, Hamburg University
of Technology

All papers of this conference can be downloaded from

http://www.Modelica.org/events/Conference2005/

Program Committee

• Prof. Gerhard Schmitz, Hamburg University of Technology, Germany (Program chair).

• Prof. Bernhard Bachmann, University of Applied Sciences Bielefeld, Germany.
• Dr. Francesco Casella, Politecnico di Milano, Italy.
• Dr. Hilding Elmqvist, Dynasim AB, Sweden.
• Prof. Peter Fritzson, University of Linkping, Sweden
• Prof. Martin Otter, DLR, Germany
• Dr. Michael Tiller, Ford Motor Company, USA
• Dr. Hubertus Tummescheit, Scynamics HB, Sweden

Local Organization: Gerhard Schmitz, Katrin Prölß, Wilson Casas, Henning Knigge, Jens Vasel, Stefan
Wischhusen, TuTech Innovation GmbH
 SCICOS: a general purpose modeling and simulation environment

SCICOS: a general purpose modeling and simulation environment

M. Najafi‡ , S. Furic, R. Nikoukhah †‡

Abstract
Partial support for Modelica is now provided by the
general purpose dynamical system simulator Scicos.
In particular it is now possible to use component mod-
els in Scicos diagrams where the dynamics of the com-
ponent has been described in Modelica. This paper
presents this new extension of Scicos.
KEYWORDS: Dynamic system simulation; Simulation
software; Component level modeling; Scilab; Model-
ica

Figure 1: A system modeled in Scicos.

1 Introduction
Scicos is a Scilab1 toolbox for modeling and simu-
lation of dynamical systems [1, 2]. Scicos provides
a hierarchical graphical editor for the construction of
complex dynamical systems, a simulator and a code
generator. For many applications, the Scilab/Scicos
environment provides a free open-source alternative to
Matlab/Simulink and MatrixX.
Very general dynamical systems, including hybrid sys-
tems, can be modeled in Scicos [3, 4, 5, 6]. A typical
Scicos diagram is presented in Fig. 1. This diagram
is used to evaluate the performance of an observer by
simulation; the simulation results are given in Fig. 2.
The model of Fig. 1 is composed of ”explicit” blocks,
i.e., block with explicitly identified inputs and outputs.
Modeling with such blocks is called system level mod-
eling. Component level modeling, on the other hand, Figure 2: Simulation result of model of Fig. 1 in Sci-
allows the use of ”implicit” blocks which are blocks cos.
with port connections which a-priori are not labeled
as inputs or outputs [7]. Implicit blocks are essential
for constructing models which include physical com-
ponents such as resistors, capacitors, etc., in electric- modynamics. In Modelica community implicit blocks
ity, or pipes, nozzles, etc., in hydraulics. They are also are called acausal [13].
useful in many other areas such as mechanics and ther-


Contrary to explicit blocks, implicit blocks cannot be
IMAGINE (www.amesim.com) modeled as black box objects. The equations realiz-
† Corresponding author (ramine.nikoukhah@inria.fr)
‡ M. Najafi, R. Nikoukhah are with INRIA-Rocquencourt, Do-
ing the behavior of an implicit block must be available
maine de Voluceau, 78153 Le Chesnay Cedex, France
to the compiler for system reduction and code genera-
1 Scilab is a free open-source software for scientific computa- tion. To describe the behavior of these blocks in Sci-
tion, see www.scilab.org and www.scicos.org. cos, the Modelica language has been adopted.

The Modelica Association 367 Modelica 2005, March 7-8, 2005

M. Najafi, S. Furic, R. Nikoukhah

2 Modelica and Scicos developed using Modelica language. As shown in the

flowchart, if the model contains an implicit block, af-
Even though Modelica is a rich language having the ter a series of automatic preprocessing steps, implicit
capacity to handle continuous-time and discrete-time part of model is abstracted into a standard block with
behaviors, for the start, we are mainly using Modelica explicit input/outputs; the resulting model can then be
and implicit blocks to model continuous-time dynam- simulated by Scicos [7].
ics; only minimal support is provided for discrete-time
behavior. The discrete-time behavior, in the Scicos en- Block Construction level
MODELICA
vironment, is provided via explicit blocks. xd=f(x,u)
y=g(x,u) Language
The addition of implicit blocks has been done without
changing significantly Scicos formalism. Even though
implicit blocks can be used anywhere inside a Scicos Standard Blocks Implicit Blocks Toolbox
diagram, they are grouped and replaced with a single
block in a precompilation phase [7]. The mechanism,
which can be compared to the way an amesim 2 or
Dymola3 model is integrated in Simulink, is com- Model design Design level

pletely transparent to the user.

All blocks No
are standard?

Create modelica model

Yes of the implicit part

Modelica to C translator

Create a new block

Incrementally linking the

new block with scicos

Figure 3: Scicos diagram containing both types of

blocks.

Consider for example the Scicos diagram in Fig. 3.

compiling scicos diagram Compile level
Here we have a fluid level control system. To model
this system in a natural way, a hydraulic source, a reg-
ulated valve, a container, a tube, and a well have been Simulation Simulation level
(ODE/DAE solver)
used. The container has a built-in level sensor which
makes the interface with the explicit part of the system,
similarly the valve is regulated through an input signal
from the explicit part of model. The controller and the Figure 4: system flowchart
display mechanism have been implemented using ex-
plicit blocks and the blocks in gray are implicit blocks
that have been developed in Modelica language.
2.2 Available implicit toolboxes
2.1 Scicos architecture
To be able to use implicit blocks in addition to ex-
To illustrate our method, a simple flowchart given in plicit ones in Scicos, several new features have been
Fig. 4 shows how Scicos and Modelica interact. A added to Scicos. So far, only two palettes with implicit
designer can select blocks from either standard or im- blocks are available for testing purposes: the electri-
plicit toolboxes. Blocks in implicit toolbox have been cal and the thermodynamics palettes. The thermo-
2 www.amesim.com hydraulic toolbox and available blocks are shown in
3 www.dymola.com Fig. 5.

The Modelica Association 368 Modelica 2005, March 7-8, 2005

 SCICOS: a general purpose modeling and simulation environment

block having explicit inputs and outputs. Then it gen-

erates a Modelica code expressing the behavior of the
new block and save it in a temporary file. This file
is then processed by modelicac 4 which translates
this Modelica code into a C-code describing the be-
havior of the new Scicos block. Once the C-code is
compiled and incrementally linked in Scilab, Scicos
sees this new block as a standard explicit block; see
Fig. 7. At the end of this procedure, the model is no
longer implicit because all blocks are standard explicit
blocks, so the model can be compiled and simulated
as usual. It should be noted that this procedure is com-
pletely transparent to the user [7].

Figure 5: Thematic toolbox

2.3 New link and port type

Implicit blocks or components are interfaced via spe-
cial links associated with physical quantities such as
current or voltage in electronics, or, flow or pressure
in hydraulics. It would be meaningless for a link rep-
resenting a voltage to be connected to another link rep-
resenting the output value of a PID controller. To dis-
tinguish between these two, two different link types Figure 7: In a precompilation phase, all implicit blocks
have been defined: explicit and implicit links that in- are grouped to form an explicit block.
terconnect explicit and implicit ports respectively. In
Fig. 6 we have a hydraulic container which has four
implicit ports (marked IP) representing liquid outlets 2.5 New numerical Solver
and an explicit port (marked EO) representing a liquid Most of the time, after generating C code for im-
level sensor output. plicit part of the model, we end up with a set of
Differential-Algebraic Equations (DAE) that no longer
can be integrated via ordinary differential equation
solvers. It is for this reason that the DAE solver
DASKR [8, 9, 10, 11, 12] has been incorporated into
Scicos.

3 Modelicac, a Modelica compiler

Figure 6: An implicit block can have implicit and ex- Modelicac (acronym of ”Modelica compiler”) is a
plicit ports. compiler for the subset of the Modelica language we
felt necessary to handle in order to cover the needs of
simulating hybrid models under Scicos. Modelicac is
2.4 Compiling a mixed diagram an external tool, i.e. it is independent of Scilab, so
To compile and simulate a model containing implicit 4 A Modelica compiler and C code generator written in

blocks, Scicos groups all implicit blocks into a single Objective Caml and included in the Scilab distribution.

The Modelica Association 369 Modelica 2005, March 7-8, 2005

M. Najafi, S. Furic, R. Nikoukhah
one may use it like an ordinary compiler e.g., like a C
compiler. By default, modelicac comes with a module
that generates C code for the Scilab target. However,
since modelicac is free and open source, it is possible
to develop a code generator for another target.
3.1 Modelicac development
Modelicac has been developed in Objective Caml 5
which is a functional programming language devel-
oped at INRIA since 1985. This language is dis-
tributed with two compiler-development tools (i.e.,
Ocamllex and Ocamlyacc) that offer some nice facil-
ities to build compilers. Furthermore the Objective
Caml compiler is free and open source, that’s why we
adopted it to develop modelicac [16].
3.2 Modelica compilation using modelicac
Modelicac is invoked for two purposes: compiling ba-
sic models from libraries and generating code for the
target simulation environment. To fulfill the first task,
like generating an object file with a C compiler, mod-
elicac is invoked with the appropriate options from the
command line to generate an object file with ”*.moc”
extension to be used later. The second task of mod-
elicac is compiling the ”main” Modelica model (here
provided by Scicos) and generating a code for the tar-
get (here, a C code). In this phase instead of generating
an object file, modelicac performs several simplifica-
tion steps to generate a code as compact as possible. In
Fig. 8 a simple flowchart shows how modelicac gener-
ates a C file from modelica model of a Scicos diagram.
3.3 Supported Modelica subset
As said previously, the current version of modelicac
(1.x.x) does not handle the full set of Modelica lan-
guage constructs. It actually allows only the descrip-
tion of physical models at ”equation” level. A phys-
ical model is built as the aggregation of sub-models
or basic types with constraints between variables, and
explicit event declarations (”When”). Currently mod-
elicac has the following main limitations:
Only ”Real” data type is supported.
Inheritance is not currently supported.
”Algorithm” is not supported but it can be defined
as an external C function. class Resistor
5 caml.inria.fr
The Modelica Association
Modelica file
Modelica generated by scicos
Libraries *.mo
*.moc
"Close" model
"Open" models Modelica
compilation
Internal Flat Model
Simplification
Code generation
*.c
Figure 8: Modelicac translation flowchart
3.3.1 Modelica source files
Modelica source files must contain only one class dec-
laration, introduced either by the ”class” keyword or
by the ”function” keyword. So a Modelica source file
may define one of the following things:
An ”open” model is a model with free variables.
There are more variables than equations (e.g. the
model of a resistor in electrical library). The open
models are introduced by the ”class” keyword,
A ”close” model is a model with equal number of
variables and constraints. It is also introduced by the
”class” keyword,
An external function, introduced by the ”function”
keyword.
Of course, only closed models can be simulated. In
order to find classes in the host file system hierarchy,
it is required that the name of the file be the same as
the name of the enclosed class. To compile the ”close”
model modelicac searches the libraries used in the cur-
rent compilation directory and also in user-defined di-
rectories.
The following source code describes a simple resistor
enclosed in a ”Resistor.mo” file:
Pin p, n;
parameter Real R "Resistance";
370 Modelica 2005, March 7-8, 2005
 SCICOS: a general purpose modeling and simulation environment
equation
R*p.i = p.v - n.v;
p.i = -n.i;
end Resistor;
An instance of ”Resistor” has two ”connectors” (”p”
and ”n”), that have their own potentials and flows vari-
ables (here, the voltage and the current, respectively).
A resistor has also a resistance parameter imposed by
the component through the first equation. The second
equation simply states that the current that flows in the
resistor through ”p” is equal to the current that flows
out through ”n”.
3.4 Model simplification
The following tasks are fulfilled by modelicac to sim-
plify and generate a C source file from a Modelica
source code and library object code files:
Obtaining a flat model by replacing an aggrega-
tion of sub-models by the set of all their variables
and equations merged together and replacing connec-
tion equations by ordinary equations. Symbolic ma-
nipulations in modelicac are performed using classical
acyclic graph manipulation techniques
Simplification of trivial or unnecessary equations us-
ing symbolic manipulations e.g. in the following sys-
tem



cos  x  sin  y   0



 cos  x 
sin  y   0 the Gauss method (to solve linear systems) and sim-
z
x
y 0 ple symbolic simplification methods based on a set of
whose nodes on the right represent constraints be-
tween variables (i.e., equations). There is an edge
between a left-side node and a right-side node if
and only if the variable represented by the left-
side node appears in the equation represented by
the right-side node.
2. Finding a coupling (using the Ford and Fulkerson
method for instance)
3. Giving the edges an orientation depending on the
results of the previous step. Edges that link two
coupled nodes are all oriented in a given direction
(either left-to-right or right-to-left) and the other
ones in the opposite direction.
4. Finding strongly connected components in the re-
sulting oriented graph (using Tarjan’s algorithm
for instance)
5. Sorting the resulting nodes in a topological order.
Each strongly connected component represents a sub-
system of the whole system and it is now possible to
perform symbolic simplification steps in order to re-
duce the number of variables in the system.
3.4.2 Modelicac simplification strategy
Symbolic simplifications typically involve variants of
f  x  y z  v 
 0 predetermined patterns (for efficiency reasons) to try
the first two equations are fully non-linear and only
the numerical solver can solve the system for x and y.
But the third equation is trivial and z can be obtained
in terms of x and y, so in the rest of equations z is
replaced by x  y. Most of the variables used to con-
nect Modelica components (”connection variables”),
are eliminated in this way.
Causality analysis, i.e. computation of system’s Ja-
cobian matrix. It will be explained further.
3.4.1 Causality analysis
Causality analysis performs a few operations in order
to find the so-called ”strongly connected components”
of a system of equations viewed as a directed bipartite
graph [13]:
1. Constructing a bipartite graph whose nodes on
the left represent variables in the system and
The Modelica Association
to solve the remaining equations. In modelicac we fo-
cused on the second class of simplification methods.
The problem when trying to solve a set of non-linear
equations is to determine a coupling in the bipartite
graph described above that triggers as many simpli-
fications as possible. So the Ford and Fulkerson (or
equivalent) method is not enough for our purposes: in-
stead of taking the first encountered coupling, we want
in addition that the coupling satisfy a given criterion
(e.g. maximizing the potential number of simplifica-
tions in the system). Hence the use of a variant of the
Hungarian method which can be seen in modelicac as
a method for finding a coupling based on an additional
constraint called the ”satisfaction”. Practically, that is
done in modelicac by associating a set of pairs (vari-
able, weight) with each equation: given an equation,
each weight indicates whether the equation is ”easy” to
solve with respect to its associated variable or not. For
instance, if an equation contains only one variable, the
weight associated with that variable is low whereas the
371 Modelica 2005, March 7-8, 2005
M. Najafi, S. Furic, R. Nikoukhah

weight associated with any other variable is infinite. p.v = 0;

Since modelicac associates low weights with variables end Ground;
that appear in linear systems, the Hungarian method
”discovers” linear systems by itself and symbolic sub- class Capacitor
Pin p, n;
stitution techniques, when applied to those linear sys-
Real v;
tems, achieve the same effect as Gaussian elimination. Real i;
Even though we did not consider the Gaussian elimi- parameter Real C "Capacitance";
nation algorithms in modelicac, we got good results. equation
C*der(v) = i;
v = p.v - n.v;
3.5 A complete (yet simple) example
0 = p.i + n.i;
First, we present the Modelica source code of a few i = p.i;
electrical models from electrical library and then show end Capacitor;
how to use these models to construct and compile elab-
class Inductor "Ideal electrical inductor"
orated electrical models with modelicac. Pin p, n;
Real v;
3.5.1 Connectors Real i;
parameter Real L "Inductance";
In Scicos libraries ”connectors” are the most basic equation
open models. Each particular domain (e.g., electrical, v = L*der(i);
hydraulic, etc.) has a its own connectors that connect v = p.v - n.v;
two or more models and exchange quantities. The are 0 = p.i + n.i;
two connector types: i = p.i;
Internal connectors, that allow connection of two end Inductor;
Modelica components, such as ”p” and ”n” pins used
in electrical resistor model. class VsourceAC "Sin-wave voltage source"
Pin p, n;
class Pin Real v;
Real v; Real i;
flow Real i; parameter Real VA=220 "Amplitude";
end Pin; parameter Real f=50 "Frequency";
parameter Real PI=3.1415926 "PI";
External connectors, that allow communication of equation
a Modelica component with an external environment v = VA*2*PI*f*time;
(Explicit part of model in Scicos environment, for in- v = p.v - n.v;
stance). Instances of ”InPutPort” and ”OutPutPort” 0 = p.i + n.i;
are examples of these connectros types i = p.i;
class InPutPort end VsourceAC;
input Real vi;
end InPutPort;

class OutPort 3.5.3 ”Main class”

output Real v;
end OutPort; In order to perform the simulation of an electrical cir-
cuit one normally has to describe the circuit using
These types of connectors are used in sensor and actu- Modelica by defining the components involved (i.e.
ator blocks that can be seen in Fig. 3 and 9. giving their names and the value of their parameters)
and the connections to establish. Then, modelicac
3.5.2 Electrical component classes should be invoked with the appropriate options and ar-
guments. This task is done by Scicos, provided that
These models include the ideal resistor, capacitor, in- the appropriate library exist in Scicos;
ductor, sinusoidal voltage source and ground.
In fact it is not necessary to write any Modelica code
class Ground "Ground" to build a circuit: one can assemble components using
Pin p; the Scicos editor and then Scicos automatically builds
equation the Modelica source code from the graphical specifica-

The Modelica Association 372 Modelica 2005, March 7-8, 2005

 SCICOS: a general purpose modeling and simulation environment

number of zero-crossings = 0
I/O direct dependency = false
*/

#include <math.h>
#include <scicos/scicos_block.h>

void rlc(scicos_block *block, int flag)

{
double *rpar = block->rpar;
double *z = block->z;
double *x = block->x;
double *xd = block->xd;
double **y = block->outptr;
double **u = block->inptr;
double *g = block->g;
double *res = block->res;
int *jroot = block->jroot;
int *mode = block->mode;
int nevprt = block->nevprt;
Figure 9: An electrical circuit modeled in Scicos. int property[3];
/* Intermediate variables */
double v0,v1;

if (flag == 0) {
tion and invokes modelicac to convert Modelica code res[0] = x[1]-xd[0]*rpar[0];
into C code. In Fig. 9 there is a model of an electrical res[1] = x[0]+xd[1]*rpar[1]-x[2];
v1=get_scicos_time();
circuit modeled in Scicos. Here is its Modelica class res[2] = x[1]+x[2]*rpar[3]+sin(6.28318530718*v1*rpar[4])*u[0][0];
} else if (flag == 1) {
automatically generated by Scicos: if (get_phase_simulation() == 1) {
y[0][0] = x[1]; /* main.B8.vo */
y[1][0] = -x[2]; /* main.B9.vo */
} else {
class imppart_rlc y[0][0] = x[1]; /* main.B8.vo */
y[1][0] = -x[2]; /* main.B9.vo */
parameter Real P1=0.0001; }
parameter Real P2=0.1; } else if (flag == 2 && nevprt < 0) {
} else if (flag == 4) {
parameter Real P3=25.0; x[0] = 0.0; /* main.B1.i */
x[1] = rpar[2]; /* main.B2.v */
parameter Real P4=0.2; x[2] = 0.0; /* main.B6.p.i */
parameter Real P5=50.0; Set_Jacobian_flag(1);
} else if (flag == 6) {
Inductor B1(L=P1); } else if (flag == 7) {
property[0] = 1; /* main.B1.i (state variable) */
Capacitor B2(C=P2, v(start=P3)); property[1] = 1; /* main.B2.v (state variable) */
property[2] = -1; /* main.B6.p.i (algebraic variable) */
Ground B3; set_pointer_xproperty(property);
VoltageSensor B4; } else if (flag == 9) {
} else if (flag == 10) {
CurrentSensor B5; v0 = Get_Jacobian_parameter();
res[0] = -rpar[0]*v0;
Resistor B6(R=P4); res[1] = 1.0;
VVsourceAC B7(f=P5); res[2] = 0.0;
res[3] = 1.0;
OutPutPort B8; res[4] = rpar[1]*v0;
res[5] = 1.0;
OutPutPort B9; res[6] = 0.0;
res[7] = -1.0;
InPutPort B10; res[8] = rpar[3];
equation res[9] = 0.0;
res[10] = 0.0;
connect (B5.p,B3.p); res[11] = sin(6.28318530718*get_scicos_time()*rpar[4])
res[12] = 0.0;
connect (B7.p,B3.p); res[13] = 0.0;
connect (B2.p,B1.p); res[14] = 1.0;
res[15] = 0.0;
connect (B4.p,B1.p); res[16] = 0.0;
res[17] = -1.0;
connect (B6.n,B1.p); res[18] = 0.0;
res[19] = 0.0;
connect (B2.n,B1.n); set_block_error(0);
connect (B4.n,B1.n); }
return;
connect (B5.n,B1.n); }
connect (B7.n,B6.p);
B4.v = B8.vi;
B5.i = B9.vi;
B10.vo = B7.VA;
Conclusion
end imppart_rlc;
The use of Modelica in Scicos provides a versatile
For this model modelicac generates a C code. This C modeling and simulation tool.
code is incrementally linked with Scicos to be used as
a standard block.
/*
References
number of discrete variables = 0
number of variables = 3
number of inputs = 1 [1] C. Bunks, J. P. Chancelier, F. Delebecque, C.
number of outputs = 2
number of modes = 0 Gomez(ed.), M. Goursat, R. Nikoukhah and

The Modelica Association 373 Modelica 2005, March 7-8, 2005

M. Najafi, S. Furic, R. Nikoukhah

S. Steer, Engineering and Scientific Computing [13] P. F RITZSON ,Principles of Object-Oriented

with Scilab, Birkhauser, 1999.
[2] J. P. Chancelier, F. Delebecque, C. Gomez, M.
Goursat, R. Nikoukhah, and S. Steer, Introduc- [14] S.E. M ATTSSON , H. E LMQVIST, M. OTTER ,
tion à Scilab, Springer-Verlag, 2002.
[3] R. Nikoukhah and S. Steer,Scicos a dynamic
system builder and simulator, IEEE I NTERNA -
TIONAL C ONFERENCE ON CACSD, Dearborn,
Michigan, 1996.
Modeling and Simulation with Modelica 2.1,
W ILEY-IEEE P RESS , 2004
AND H. O LSSON , ”I NITIALIZATION OF H Y-
BRID D IFFERENTIAL -A LGEBRAIC E QUATIONS
IN M ODELICA 2.0”, 2nd Inter. Modelica Con-
ference 2002, DYNASIM AB, S WEDEN AND
DLR O BERPFAFFENHOFEN , G ERMANY, 2002,
PP. 9–15.

[4] R. Nikoukhah and S. Steer, Hybrid systems: [15] R. N IKOUKHAH AND S. S TEER , ”C ONDI -
modeling and simulation, COSY: M ATHEMAT- TIONING IN HYBRID SYSTEM FORMALISM ”,
ICAL M ODELLING OF C OMPLEX S YSTEM, International Conference Automation of Mixed
Lund, Sweden, Sept. 1996. Processes:A D P M Hybrid Dynamic Systems,
D ORTMUND , G ERMANY, 2000.
[5] A. Benveniste, Compositional and Uniform
Modeling of Hybrid Systems, IEEE Trans. Au- [16] W EIS , P IERRE , L EROY, X AVIER , Le Langage
tomat. Control, AC-43, 1998. CAML, 2 ND ED , D UNOD P RESS , 1999
[6] R. Nikoukhah and S. Steer, Scicos: A Dynamic
System Builder and Simulator, User’s Guide -
Version 1.0, INRIA Technical Report, RT-0207,
June 1997.

[7] M. Najafi, A.Azil, and R. Nikoukhah, Extending

scicos from system to component level simula-
tion, ESMc2004 international conference, Paris,
France, October 2004.

[8] K. E. Brenan, S. L. Campbell, and L. R. Pet-

zold, Numerical Solution of Initial-Value Prob-
lems in Differential-Algebraic Equations, SIAM
publication, Philadelphia, 1996.

[9] A. C. Hindmarsh, ”LSODE and LSODI, Two

New Initial Value Ordinary Differential Equa-
tion Solvers”, ACM-Signum Newsletter, Vol. 15,
1980, pp. 10–11.

[10] L. R. Petzold, ”Automatic selection of methods

for solving stiff and nonstiff systems of ordinary
differential equations”, SIAM J. Sci. Stat. Com-
put., No. 4, 1983.

[11] L. R. Petzold. ”A Description of DASSL: A Dif-

ferential/Algebraic System Solver”, In Proceed-
ings of the 10th IMACS World Congress, Mon-
treal, 1982, pp. 8-13.

[12] P. N. Brown, A. C. Hindmarsh, and L. R.

Petzold, Consistent Initial Condition Calcula-
tion for Differential-Algebraic Systems, SIAM J.
S CI . C OMP., NO . 19, 1998.

The Modelica Association 374 Modelica 2005, March 7-8, 2005