Content uploaded by Adeel Asghar

Author content

All content in this area was uploaded by Adeel Asghar on Oct 15, 2019

Content may be subject to copyright.

API for Accessing OpenModelica Models From Python

B. Lie

University College of Southeast Norway

Porsgrunn, Norway

Email: Bernt.Lie@hit.no

S. Bajracharya, A. Mengist, L. Buffoni, A. Kumar

M. Sj¨

olund, A. Asghar, A. Pop, P. Fritzson

Link¨

oping University

Sweden

Email: peter.fritzson@liu.se

Abstract—This paper describes a new API for operating

on Modelica models in Python, through OpenModelica.

Modelica is an object oriented, acausal language for describ-

ing dynamic models in the form of Differential Algebraic

Equations. Modelica and various implementations such as

OpenModelica have limited support for model analysis, and

it is of interest to integrate Modelica code with scripting lan-

guages such as Python, which facilitate the needed analysis

possibilities. The API is based on a new class ModelicaSystem

within package OMPython of OpenModelica, with methods

that operate on instantiated models. Emphasis has been put

on speciﬁcation of a systematic structure for the various

methods of the class. A simple case study involving a water

tank is used to illustrate the basic ideas.

Keywords-OpenModelica, Modelica, Python, Python API

I. INTRODUCTION

Modelica is a modern, equation based, acausal language

for encoding models of dynamic systems in the form

of differential algebraic equations (DAEs), see e.g. [3]

on Modelica and e.g. [2] on DAEs. OpenModelica1[4]

is a mature, freely available toolset that includes Open-

Modelica Connection Editor (ﬂow sheeting, textual editor

with debugging facilities, and simulation environment)

and the OMShell (command line execution, script based

execution). OpenModelica Shell supports commands for

simulation of Modelica models, for use of the Modelica

extension Optimica, for carrying out analytic linearization

via the Modelica package Modelica LinearSystem2, and

for converting Modelica models into Functional Mock-Up

Units (FMUs) as well as for converting FMUs back to

Modelica models. A tool OMPython has been developed

and communicates with OpenModelica via CORBA, [5],

[6]. Essentially, OMPython is a Python package which

makes it possible to pass OpenModelica Shell commands

as strings to a Python function, and then receive the results

back into Python. This possibility does, however, require

good knowledge of OpenModelica Shell commands and

syntax. A tool, PySimulator,2has been developed to ease

the use of Modelica from Python, [9], [6]. Essentially,

PySimulator provides a GUI based on Python, where Mod-

elica models can be run and results can presented. It is also

possible to analyze the results using various packages in

Python, e.g. FFT analysis. However, PySimulator currently

does not give the user full freedom to integrate Modelica

models with Python and use the full available set of

1www.openmodelica.org

2https://pypi.python.org/pypi/PySimulator

packages in Python, or freely develop one’s own analysis

routines in Python.

Modelica and OpenModelica Shell in themselves have

relatively little support for advanced analysis of models.

Examples of such desirable analysis capabilities could

be (i) study of model sensitivity, (ii) random number

generation and statistical analysis, (iii) Monte Carlo sim-

ulation, (iv) advanced plotting capabilities, (v) general

optimization capabilities, (vi) linear analysis and control

synthesis, etc. Scripting languages such as MATLAB and

Python hold most of these desirable analysis capabilities,

and it is of interest to integrate Modelica models with such

script languages. The free JModelica.org tool includes a

Python package for converting Modelica models to FMUs,

and then for importing the FMU as a Python object. This

way, Modelica models can essentially be simulated from

Python — Optimica is also supported. It is possible to do

more advanced analysis with JModelica.org3via CasADi,

see e.g. [7] and [8]. However, the possibilities in the work

of Perera et al. use an old version of JModelica.org. It

would be more ideal if these possibilities were supported

by the tool developer.

It is thus of interest to develop an extension of

OMPython which enables simulation and analysis of Mod-

elica models with a better integration with the Python

language, and in particular that such an extension is pro-

vided by the OpenModelica developers. A Python API4for

controlling Modelica simulation and analysis from Python

was proposed in February 20155. Based on this proposal,

a ﬁrst version of a Python API has been implemented [1],

and has then been further revised. This paper discusses

the API, and illustrates how it can be used for automatic

analysis of Modelica models from Python, exempliﬁed by

a simple water tank model. The paper is organized as

follows. In Section 2, an overview of the API is given.

In Section 3, use of the API is illustrated through simple

analysis of a nonlinear reactor model. In Section 4, the API

is discussed, some conclusions are drawn, and future work

is discussed. Appendices hold details of the nonlinear

reactor model.

3www.JModelica.org

4API = Application Programming Interface

5Python API for Accessing OpenModelica Models, by B. Lie, February

20, 2015, communicated to P. Fritzson at Link¨

oping University.

II. OVE RVI EW OF PYTHON API

A. Goal

Modeling and the use of Modelica with Python is of

interest to a wide range of engineering disciplines. The

computer science threshold of using Modelica with Python

should be low. Ideally, the OMPython extension should

work with simple one-click Python installations such

as Anaconda6and Canopy7. Furthermore, the extension

should support both 32 bit and 64 bit OpenModelica,

work with both 32 bit and 64 bit Python, with Python

2.7 and Python 3.X, and on platforms Windows, OSX and

Linux. These requirements e.g. imply that results should

be returned as standard Python structures. However, it is

reasonable that the OMPython extension depends on the

NumPy package. Because Python has excellent plotting

capabilities e.g. via Matplotlib, the OpenModelica Shell

facility for plotting results should not be implemented —

this is more naturally handled directly in Python.

B. Installing the OMPython extension

Under Windows, the new OMPython

extension will be automatically installed

in a ﬁle __init__.py in directory

share\omc\scripts\PythonInterface\OMPython

in the OpenModelica directory when OpenModelica

is downloaded and installed. In order to activate the

extension, the user must next run the command python

setup.py install from the command line in

the directory of the setup.py ﬁle, which is in the

PythonInterface subdirectory. It follows that in

order to activate the extension, the user must ﬁrst install

Python on the relevant computer. Under Linux/OSX,

OMPython is part of pip (pypi) and is not shipped

with the OpenModelica installer.

C. Status

Currently, the Python API is in a development status

and has been tested with 32 bit Python 2.7 from the

Anaconda installation in tandem with 32 bit OpenMod-

elica v. 1.9.4 under Windows 8.1 and OpenModelica v.

1.9.6 under Windows 10, and a modiﬁed __init__.py

ﬁle. OpenModelica uses CORBA for communication, and

CORBA compatibility needs some reﬁnement. The code

is somewhat unstable when run from the Spyder IDE used

with the Anaconda installation, but runs ﬁne from Jupyter

notebooks.

D. Description of the API

The API is described in the subsections below.

1) Python Class and Constructor: The name of the

Python class which is used for operation on Modelica

models, is ModelicaSystem. This class is equipped with

an object constructor of the same name as the class. In

addition, the class is equipped with a number of methods

for manipulating the instantiated objects.

6www.continuum.io/downloads

7www.enthought.com/products/canopy

In this subsection, we discuss how to import the class,

and how to use the constructor to instantiate an object.

The object is imported from package OMPython, i.e.

with Python commands8:

>>> from OMPython import ModelicaSystem

Other Python packages to be used such as numpy,

matplotlib,pandas, etc. must be imported in a

similar manner.

The object constructor requires a minimum of 2 input

arguments which are strings, and may need a third string

input argument.

•The ﬁrst input argument must be a string with the

ﬁle name of the Modelica code, with Modelica ﬁle

extension .mo. If the Modelica ﬁle is not in the

current directory of Python, then the ﬁle path must

also be included.

•The second input argument must be a string with the

name of the Modelica model, including the names-

pace if the model is wrapped within a Modelica

package.

•A third input argument is used if the Modelica model

builds on other Modelica code, e.g. the Modelica

Standard Library.

The result of using the object constructor is a Python

object.

Example 1: Use of constructor.

Suppose we have a Modelica model with name CSTR

wrapped in a Modelica package Reactors — stored in ﬁle

Reactor.mo:

package Reactors

// ...

model CSTR

/// ...

end CSTR;

//

end Reactors;

If this model does not use any external Modelica code

and the ﬁle is located in the current Python directory, the

following Python code instantiates a Python object mod:

>>> mod = ModelicaSystem(’Reactors.mo’,

’Reactors.CSTR’)

The user is free to choose any valid Python label name

for the Python object.

All methods of class ModelicaSystem refers to the

instantiated object, in standard Python fashion. Thus,

method simulate() is invoked with the Python com-

mand:

>>> mod.simulate()

In the subsequent overview of methods, the object name

is not included. In practice, of course, it must be included

in order to operate on the object in question.

8The Python prompt >>> is not typed, and does not appear in script

ﬁles, in iPython or in Jupyter notebooks.

Methods may have no input arguments, one, or several

input arguments. Methods may or may not return results

— if the methods do not return results, the results are

stored within the object.

2) Utility routines, converting Modelica ↔FMU: Two

utility methods convert ﬁles between Modelica ﬁles with

ﬁle extension .mo and Functional Mock-up Unit (FMU)

ﬁles with ﬁle extension .fmu.

1) convertMo2Fmu() — method for converting the

Modelica model of the object, say ModelName,

into FMU ﬁle.

•Required input arguments: none, operates on the

Modelica ﬁle associated with the object.

•Optional input arguments:

–className: string with the class name that

should be translated,

–version: string with FMU version, “1.0”

or “2.0”; the default is “1.0”.

–fmuType: string with FMU type, “me”

(model exchange) or “cs” (co-simulation);

the default is “me”.

–fileNamePrefix: string; the default is

\’className\’.

–generatedFileName: string, returns the

full path of the generated FMU.

•Result: ﬁle ModelName.fmu in the current

directory

2) convertFmu2Mo(s) — method for converting an

FMU ﬁle into a Modelica ﬁle.

•Required input arguments: string s, where sis

name of FMU ﬁle, including extension .fmu.

•Optional input arguments: a number of optional

input arguments, e.g. the possibility to change

working directory for the imported FMU ﬁles.

•Result: Assume the name of the

ﬁle is fmuName.fmu. Then ﬁle

fmuName_me_FMU.mo is generated in

the current Python directory.

3) Getting and setting information: Quite a few meth-

ods are dedicated to getting and setting information about

objects. With two exceptions — getQuantities()

and getSolutions() — the get methods have identi-

cal use of input arguments and results, while all the set

methods have identical use of input arguments, with results

stored in the object.

Getting quantity information: Method

getQuantities() does not accept input arguments,

and returns a list of dictionaries, one dictionary for each

quantity. Each dictionary has the following keys — with

values being strings, too.

•Changeable — value ’true’ or ’false’,

•Description — the string used in Modelica to

describe the quantity, e.g. ’Mass in tank, kg’,

•Name — the name of the quantity, e.g. ’T’,

’der(T)’,’n[1]’,’mod1.T’, etc.,

•Value — the value of the quantity, e.g. ’None’,

’5.0’, etc.,

•Variability —’continuous’,

’parameter’.

When applying the Pandas method DataFrame to the

returned list of dictionaries, the result is a conveniently

typeset table in Jupyter notebooks. Modelica constants

are not included in the returned quantities.

Standard get methods: We consider

methods getXXXs(), where XXXs is in

{Continuous,Parameters,Inputs,Outputs,

SimulationOptions,OptimizationOptions,

LinearizationOptions}. Thus, methods

getContinuous(),getParameters(), etc.

Two calling possibilities are accepted.

•getXXXs(), i.e. without input argument, returns a

dictionary with names as keys and values as ... values.

•getXXXs(S), where Sis a sequence of strings of

names, returns a tuple of values for the speciﬁed

names.

Getting solutions: We consider method

getSolutions(). Two calling possibilities are

accepted.

•getSolutions(), i.e. without input arguments,

returns a list of strings of names of quantities for

which there is a solution = time series.9

•getSolutions(S), where Sis a sequence of

strings of names, returns a tuple of values = 1D

numpy arrays = time series for the speciﬁed names.

Setting methods: The information that can

be set is a subset of the information that can

be set. Thus, we consider methods setXXXs(),

where XXXs is in {Parameters,Inputs,

SimulationOptions,OptimizationOptions,

LinearizationOptions}, thus methods

setParameters(),setInputs(), etc. Two

calling possibilities are accepted.

•setXXXs(K), with Kbeing a sequence of keyword

assignments of type quantity name = value.

Here, the quantity name could be a parameter name

(i.e., not a string), an input name, etc.

–For parameters and simula-

tion/optimization/linearization options, the

value should be a numerical value or a string

(e.g. a string of ODE solver name such as

’dassl’, etc.).

–For inputs, the value could be a numerical value

if the input is constant in the time range of the

simulation,

–For inputs, the value could alternatively

be a list of tuples (tj, uj), i.e.,

[(t1, u1),(t2, u2),...,(tN, uN)] where the

input varies linearly between (tj, uj)and

(tj+1, uj+1 ), where tj≤tj+1, and where

at most two subsequent time indices tj, tj+1

can have the same value. As an example,

[..., (1,10), (1,20), ...] describes

9The reason why a dictionary with every name as key and time series

as values is not returned, is that the amount of data would be exhaustive.

Figure 1. Driven water tank, with externally available quantities framed

in red: initial mass is emptied through bottom at rate ˙me, while at the

same time water enters the tank at rate ˙mi.

a perfect jump in input value from value 10 to

value 20 at time instance 1.

–This type of sequence of input arguments

does not work for certain quantity names,

e.g. ’der(T)’,’n[1]’,’mod1.T’, because

Python does not allow for label names der(T),

n[1],mod1.T, etc.

•setXXXs(**D), with Dbeing a dictionary with

quantity names as keywords and values as described

with the alternative input argument K.

4) Operating on Python object: simulation, optimiza-

tion: The following methods operate on the object, and

have no input arguments. The methods have no return

values, instead the results are stored within the object.

•simulate() — simulates the system with the

given simulation options

•optimize() — optimizes the Optimica problem

with the given optimization options

To retrieve the results, method getSolutions() is

used as described previously.

5) Operating on Python object: linearization10:The

following methods are proposed for linearization:

•linearize() — with no input argument, returns

a tuple of 2D numpy arrays (matrices) A,B,Cand

D.

•getLinearInputs() — with no input argument,

returns a list of strings of names of inputs used when

forming matrices Band D.

•getLinearOutputs() — with no input argu-

ment, returns a list of strings of names of outputs

used when forming matrices Cand D.

•getLinearStates() — with no input argument,

returns a list of strings of names of states used when

forming matrices A,B,Cand D.

III. USE O F API FO R MOD EL A NA LYSIS

A. Case study: simple tank ﬁlled with liquid

We consider the tank in Fig. 1 ﬁlled with water.

10This part of the API is not completed at the moment, and may

change.

Figure 2. Functional diagram of tank with inﬂuent and efﬂuent ﬂow.

Table I

PARAMETERS FOR DRIVEN TANK WITH CONSTANT CROSS SECTIONAL

AR EA.

Parameter Value Unit Comment

ρ1 kg /LDensity of liquid

A5 dm2Constant cross sectional area

K5 kg /sValve constant

hO3 dm Level scaling

Water with initial mass m(0) is emptied by gravity

through a hole in the bottom at efﬂuent mass ﬂow rate

˙me, while at the same time water is ﬁlled into the tank at

inﬂuent mass ﬂow rate ˙mi.

Our modeling objective is to ﬁnd the liquid level h.

This objective is illustrated by the functional diagram in

Fig. 2. The functional diagram depicts the causality of

the system (“Tank with inﬂuent and efﬂuent mass ﬂow”),

where inputs (green arrow) cause a change in the system

and is observed at outputs (orange arrow)11. Here, the

input variable is the inﬂuent mass ﬂow rate ˙mi, while the

output variable is the quantity we are interested in, h.

B. Model summary

The model can be summarized in a form suitable for

implementation in Modelica as

dm

dt = ˙mi−˙me

m=ρV

V=Ah

˙me=Krh

hO.

To complete the model description, we need to specify

model parameters and operating conditions. Model param-

eters (constants) are given in Table I.

The operating conditions are given in Table II.

C. Modelica encoding of model

The Modelica code describes the core model of the tank,

ModWaterTank, and consists of a ﬁrst section where

11Although Modelica is an acausal modeling language, it is useful to

think in terms of causality during model development.

Table II

OPERATING CONDITION FOR DRIVEN TANK WITH CONSTANT CROSS

SECTIONAL AREA.

Quantity Value Unit Comment

h(0) 1.5 dm Initial level

m(0) ρh (0) Akg Initial mass

˙mi(t) 2 kg /sNominal inﬂuent mass ﬂow rate;

may be varied

constants and variables are speciﬁed, and a second section

where the model equations are speciﬁed.

model ModWaterTank

// Main driven water tank model

// author: Bernt Lie

// University College of

// Southeast Norway

// April 18, 2016

//

// Parameters

constant Real rho = 1 "Density";

parameter Real A = 5 "Tank area";

parameter Real K = 5 "Valve const";

parameter Real h_max = 3 "Scaling";

// Initial state parameters

parameter Real h_0 = 1.5

"Init.level";

parameter Real m_0 = rho*h_0*A

"Init.mass";

// Declaring variables

// -- states

Real m(start = m_0, fixed = true)

"Mass in tank, kg";

// -- auxiliary variables

Real V "Tank liquid volume, L";

Real md_e "Effluent mass flow";

// -- input variables

input Real md_i "Influent mass

flow";

// -- output variables

output Real h "Tank liquid level,

dm";

// Equations constituting the model

equation

// Differential equation

der(m) = md_i - md_e;

// Algebraic equations

m = rho*V;

V=A*h;

md_e = K*sqrt(h/h_max);

end ModWaterTank;

As seen from the ﬁrst section of model

ModWaterTank, the model has 4essential parameters

(rho-h_max) of which one is a Modelica constant

(rho) while other 3are design parameters, compare this

to Table I. Furthermore, the model contains 2“initial

state” parameters, where 1of them can be chosen at

liberty, h_0, while the other one, m_0, is computed

automatically from h_0, see Table II. The purpose of

the “free parameter” h_0 is that it is easier for the

user to specify level than mass. Also, free “initial state”

parameters makes it possible for the user to change the

initial states from outside of model ModWaterTank,

e.g., from Python.

Next, one variable is given with initial value — the

state m— is initialized with the “initial state” parameter

m_0. Then, 2variables are deﬁned as auxiliary variables

(algebraic variables), Vand md_e.12

One input variable is deﬁned — md_i — this is

the inﬂuent mass ﬂow rate ˙mi, see Table II. Inputs are

characterized by that their values are not speciﬁed in

model the core model — here ModWaterTank. Instead,

their values must be given in an external model/code —

we will specify this input in Python. Finally, 1output is

given — h.

In the second section of model ModWaterTank, the

Model equations exactly map the mathematical model

given in Section III-B.

For illustrative purposes, the core model

ModWaterTank is wrapped within a package named

WaterTank and stored in ﬁle WaterTank.mo,

package WaterTank

// Package for simulating

// driven water tank

// author: Bernt Lie

// University College of

// Southeast Norway

// April 18, 2016

//

model ModWaterTank

// Main driven water tank model

// ....

....

end ModWaterTank;

// End package

end WaterTank;

D. Use of Python API

First, the following Python statements are executed —

we did this in Jupyter notebook.

from OMPython import ModelicaSystem

import numpy as np

import numpy.random as nr

%matplotlib inline

import matplotlib.pyplot as plt

import pandas as pd

LW = 2

Here, we use NumPy to handle simulation results,

etc. The random number package will be used in

a sensitivity/Monte Carlo study. The magic function

%matplotlib inline is used to embed Matplotlib

plots within the Jupyter notebook; to save these plots into

ﬁles, simply right-click the plots. However, more options

for saving ﬁles are available if the magic function is

excluded, and instead command plt.show() is added

after the plot commands have been completed. Pandas

are used to illustrate presenting data in tables in Jupyter

notebook. Finally, label LW is used to give a conform line

width in plots.

E. Basic simulation of model

We instantiate object tank with the following com-

mand:

12md is notation for m with a dot, ˙m, i.e., a mass ﬂow rate.

Figure 3. Typesetting of Data Frame of quantity list in Jupyter notebook.

tank = ModelicaSystem(’WaterTank.mo’,

’WaterTank.ModWaterTank’)

whereupon Python/Jupyter notebook responds that the

OMC Server is up and running the ﬁle. Next, we are

interested in which quantities are available in the model.

In the sequel, Python prompt >>> is used when Jupyter

notebook actually uses In[*]— where *is some num-

ber, while the response in Jupyter notebook is prepended

with Out[*].

>>> q = tank.getQuantities()

>>> type(q)

list

>>> len(q)

11

>>> q[0]

{’Changeable’: ’true’,

’Description’: ’Mass in tank, kg’,

’Name’: ’m’,

’Value’: None,

’Variability’: ’continuous’}

>>> pd.DataFrame(q)

The last command leads Jupyter notebook to typeset a

tabular presentation of the quantities, Fig. 3. The results

in Fig. 3 should be compared to the Modelica model in

Section III-C. Observe that Modelica constants are not

included in the quantity list.

Next, we check the simulation options:

>>> tank.getSimulationOptions()

{’solver’: ’dassl’,

’startTime’: 0.0,

’stepSize’: 0.002,

’stopTime’: 1.0,

’tolerance’: 1e-06}

It should be observed that the stepSize is the fre-

quency at which solutions are stored, and is not the step

size of the solver. The number of data points stored, is

thus (stopTime-startTime)/stepSize with due

rounding. This means that if we increase the stopTime to

a large number, we should also increase the stepSize to

avoid storing a large number of information.

Figure 4. Tank level when starting from steady state, and ˙mi(t)varies

in a straight line between the points (tj,˙mi(tj)) given by the list

[(0,3),(2,3),(2,4),(6,4),(6,2),(10,2)].

To this end, we want to simulate the system for a long

time, until the level reaches steady state. Possible inputs

are:

>>> tank.getInputs()

{’md_i’: None}

where value None implies that the available input, md_i,

has yet not been set. We could use None as input,

which will be interpreted as zero. But let us instead set

˙mi= 3, simulate for a long time, and change “initial state”

parameter h(0) to the steady state value of h:

>>> tank.setInputs(md_i=3)

>>> tank.setSimulationOptions\

(stopTime=1e4, stepSize=10)

>>> tank.simulate()

>>> h = tank.getSolutions(’h’)

>>> tank.setParameters(h_0 = h[-1])

Next, we set back to stop time to 10, and specify an

input sequence with a couple of jumps:

>>> tank.setSimulationOptions\

(stopTime=10, stepSize=0.02)

>>> tank.setInputs(md_i = [(0,3),(2,3),

(2,4),(6,4),(6,2),(10,2)])

Finally, we simulate the model with the time varying input,

and plot the result:

>>> tank.simulate()

>>> tm, h = tank.getSolutions(’time’,\

’h’)

>>> plt.plot(tm,h,linewidth=LW,

color=’blue’, label=r’$h$’)

>>> plt.title(’Water tank level’)

>>> plt.xlabel(r’time $t$ [s]’)

>>> plt.ylabel(r’$h$ [dm]’)

The result is displayed in Fig. 4.

Figure 5. Uncertainty in tank level with a 5% uncertainty in valve

constant K. The input is like in Fig. 4.

F. Parameter sensitivity/Monte Carlo simulation

It is of interest to study how the model behavior varies

with varying uncertain parameter values, e.g. the efﬂuent

valve constant K. This can be done as follows:

>>> par = tank.getParameters()

>>> K = par[’K’]

>>> KK = K + (nr.randn(10)-0.5)*K/20

>>> tank.simulate()

>>> tm, h = tank.getSolutions(’time’,\

’h’)

>>> plt.plot(tm,h,linewidth = LW,

color = ’red’, label=r’$h$’)

>>> for k in KK:

tank.setParameters(K=k);

tank.simulate()

tm, h = tank.getSolutions\

(’time’,’h’)

plt.plot(tm,h,linewidth=LW,

color=’red’,linestyle=\

’dotted’,label=’_nolabel_’)

>>> plt.title(’Tank level sensitivity’)

>>> plt.xlabel(r’time $t$ [s]’)

>>> plt.ylabel(r’$h$ [dm]’)

>>> plt.legend()

The result is as shown in Fig. 5.

IV. DISCUSSION AND CONCLUSIONS

This paper introduces some ongoing work on extend-

ing OpenModelica with a Python API, so that Modelica

models can be run and analyzed from within Python. The

new Python API is brieﬂy described, and the use of this

API is then illustrated by simulating a very simple model

of a water tank.

Future work will include further testing, e.g., with

optimization, extending the API so that it works on more

platforms, and extending the API to include analytic model

linearization.

REFERENCES

[1] Bajracharya, S. (2016). Enhanced OpenModelica Python

Interface. MSc thesis, Department of Computer and Infor-

mation Science, Link¨

oping University, Sweden.

[2] Brenan, K.E., Campbell, S.L., Petzold, L.R. (1987). Nu-

merical Solution of Initial-Value Problems in Differential-

Algebraic Equations, 2nd edition. SIAM, Philadelphia.

[3] Fritzson, P. (2014). Principles of Object-Oriented Modeling

and Simulation with Modelica 3.3: A Cyber-Physical Ap-

proach, second edition. Wiley-IEEE Press, Piscataway, NJ.

ISBN 978-1-118-85912-4.

[4] Fritzson, P., Aronsson, P., Pop, A., Lundvall, H., Nystr¨

om,

K., Saldamli, L., Broman, D., Sandholm, A. (2006). “Open-

Modelica – A Free Open-Source Environment for System

Modeling, Simulation, and Teaching”. Proceedings of the

2006 IEEE Conference on Computer Aided Control System

Design, Munich, Germany, October 4–6, 2006.

[5] Ganeson, A.K. (2012). Design and Implementation of a

User Friendly OpenModelica - Python interface. Master’s

Thesis, Department of Computer and Information Sci-

ence, Link¨

oping University. Reg Nr: LIU-IDA/LITH-EX-

A12/037SE .

[6] Ganeson, A.K., Fritzson, F., Rogovchenko, O., Asghar, A.,

Sj¨

olund, M., Pfeiffer, A. (2012). “An OpenModelica Python

Interface and its use in PySimulator ”. Proceedings of the 9th

International Modelica Conference, September 3-5, 2012,

Munich, Germany. DOI 10.3384/ecp12076537.

[7] Perera, M. Anushka S., Lie, B., and Pfeiffer, C.F. (2015).

“Structural Observability Analysis of Large Scale Systems

Using Modelica and Python”. Modeling, Identiﬁcation and

Control,Vol 36, No 1, pp. 53–65.

[8] Perera, M. Anushka S., Hauge, T.A., and Pfeiffer, C.F.

(2015). “Parameter and State Estimation of Large-Scale

Complex Systems Using Python Tools”. Modeling, Identi-

ﬁcation and Control,Vol 36, No 3, pp. 189–198.

[9] Pfeiffer, A., Hellerer, M., Hartweg, S., Otter, M., and Reiner,

M. (2012). “PySimulator – A Simulation and Analysis Envi-

ronment in Python with Plugin Infrastructure”. Proceedings

of the 9th International Modelica Conference, September 3-

5, 2012, Munich, Germany. DOI 10.3384/ecp12076523.