Abstract and Figures

This paper describes a new API for operating on Modelica models in Python, through OpenModelica. Modelica is an object oriented, acausal language for describing 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 languages 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 specification 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.
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
oping University
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 specification 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
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 (flow 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
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 first 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, exemplified 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.
4API = Application Programming Interface
5Python API for Accessing OpenModelica Models, by B. Lie, February
20, 2015, communicated to P. Fritzson at Link¨
oping University.
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 file __init__.py in directory
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 file, which is in the
PythonInterface subdirectory. It follows that in
order to activate the extension, the user must first 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 modified __init__.py
file. OpenModelica uses CORBA for communication, and
CORBA compatibility needs some refinement. The code
is somewhat unstable when run from the Spyder IDE used
with the Anaconda installation, but runs fine from Jupyter
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.
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 first input argument must be a string with the
file name of the Modelica code, with Modelica file
extension .mo. If the Modelica file is not in the
current directory of Python, then the file 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
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
Example 1: Use of constructor.
Suppose we have a Modelica model with name CSTR
wrapped in a Modelica package Reactors — stored in file
package Reactors
// ...
model CSTR
/// ...
end CSTR;
end Reactors;
If this model does not use any external Modelica code
and the file is located in the current Python directory, the
following Python code instantiates a Python object mod:
>>> mod = ModelicaSystem(’Reactors.mo’,
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-
>>> 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
files, 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 files between Modelica files with
file extension .mo and Functional Mock-up Unit (FMU)
files with file extension .fmu.
1) convertMo2Fmu() — method for converting the
Modelica model of the object, say ModelName,
into FMU file.
Required input arguments: none, operates on the
Modelica file 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
generatedFileName: string, returns the
full path of the generated FMU.
Result: file ModelName.fmu in the current
2) convertFmu2Mo(s) — method for converting an
FMU file into a Modelica file.
Required input arguments: string s, where sis
name of FMU file, including extension .fmu.
Optional input arguments: a number of optional
input arguments, e.g. the possibility to change
working directory for the imported FMU files.
Result: Assume the name of the
file is fmuName.fmu. Then file
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’,
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
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 specified
Getting solutions: We consider method
getSolutions(). Two calling possibilities are
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 specified 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,
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
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 tjtj+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
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.
A. Case study: simple tank filled with liquid
We consider the tank in Fig. 1 filled with water.
10This part of the API is not completed at the moment, and may
Figure 2. Functional diagram of tank with influent and effluent flow.
Table I
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 effluent mass flow rate
˙me, while at the same time water is filled into the tank at
influent mass flow rate ˙mi.
Our modeling objective is to find 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 influent and effluent mass flow”),
where inputs (green arrow) cause a change in the system
and is observed at outputs (orange arrow)11. Here, the
input variable is the influent mass flow 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
dt = ˙mi˙me
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 first section where
11Although Modelica is an acausal modeling language, it is useful to
think in terms of causality during model development.
Table II
Quantity Value Unit Comment
h(0) 1.5 dm Initial level
m(0) ρh (0) Akg Initial mass
˙mi(t) 2 kg /sNominal influent mass flow rate;
may be varied
constants and variables are specified, and a second section
where the model equations are specified.
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
parameter Real m_0 = rho*h_0*A
// 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
// -- output variables
output Real h "Tank liquid level,
// Equations constituting the model
// Differential equation
der(m) = md_i - md_e;
// Algebraic equations
m = rho*V;
md_e = K*sqrt(h/h_max);
end ModWaterTank;
As seen from the first 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 defined as auxiliary variables
(algebraic variables), Vand md_e.12
One input variable is defined — md_i — this is
the influent mass flow rate ˙mi, see Table II. Inputs are
characterized by that their values are not specified 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 file 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
files, simply right-click the plots. However, more options
for saving files 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-
12md is notation for m with a dot, ˙m, i.e., a mass flow rate.
Figure 3. Typesetting of Data Frame of quantity list in Jupyter notebook.
tank = ModelicaSystem(’WaterTank.mo’,
whereupon Python/Jupyter notebook responds that the
OMC Server is up and running the file. 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)
>>> len(q)
>>> 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
To this end, we want to simulate the system for a long
time, until the level reaches steady state. Possible inputs
>>> 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),
Finally, we simulate the model with the time varying input,
and plot the result:
>>> tank.simulate()
>>> tm, h = tank.getSolutions(’time’,\
>>> 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 effluent
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’,\
>>> plt.plot(tm,h,linewidth = LW,
color = ’red’, label=r’$h$’)
>>> for k in KK:
tm, h = tank.getSolutions\
>>> 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.
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 briefly 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
[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¨
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.,
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, Identification 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-
fication 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.
Full-text available
This work presents the results of experimental operation of a solar‐driven climate system using mixed‐integer nonlinear model predictive control (MPC). The system is installed in a university building and consists of two solar thermal collector fields, an adsorption cooling machine with different operation modes, a stratified hot water storage with multiple inlets and outlets as well as a cold water storage. The system and the applied modeling approach is described and a parallelized algorithm for mixed‐integer nonlinear MPC and a corresponding implementation for the system are presented. Finally, we show and discuss the results of experimental operation of the system and highlight the advantages of the mixed‐integer nonlinear MPC application.
Full-text available
This paper discusses the topics related to automating parameter, disturbance and state estimation analysis of large-scale complex nonlinear dynamic systems using free programming tools. For large-scale complex systems, before implementing any state estimator, the system should be analyzed for structural observability and the structural observability analysis can be automated using Modelica and Python. As a result of structural observability analysis, the system may be decomposed into subsystems where some of them may be observable - with respect to parameter, disturbances, and states - while some may not. The state estimation process is carried out for those observable subsystems and the optimum number of additional measurements are prescribed for unobservable subsystems to make them observable. In this paper, an industrial case study is considered: the copper production process at Glencore Nikkelverk, Kristiansand, Norway. The copper production process is a large-scale complex system. It is shown how to implement various state estimators, in Python, to estimate parameters and disturbances, in addition to states, based on available measurements.
Full-text available
State observability of dynamic systems is a notion which determines how well the states can be inferred from input-output data. For small-scale systems, observability analysis can be done manually, while for large-scale systems an automated systematic approach is advantageous. Here we present an approach based on the concept of structural observability analysis, using graph theory. This approach can be automated and applied to large-scale, complex dynamic systems modeled using Modelica. Modelica models are imported into Python via the JModelica.org-CasADi interface, and the Python packages NetworkX (for graph-theoretic analysis) and PyGraphviz (for graph layout and visualization) are used to analyze the structural observability of the systems. The method is demonstrated with a Modelica model created for the Copper production plant at Glencore Nikkelverk, Kristiansand, Norway. The Copper plant model has 39 states, 11 disturbances and 5 uncertain parameters. The possibility of estimating disturbances and parameters in addition to estimating the states are also discussed from the graph-theory point of view. All the software tools used on the analysis are freely available.
Full-text available
Part I: Introduction. Chapter 1: Introduction to Modeling and Simulation. Chapter 2: A Quick Tour of Modelica. Part II: The Modelica Language. Chapter 3: Classes, Types, and Declarations. Chapter 4: Inheritance, Modifications, and Generics. Chapter 5: Components, Connectors, and Connections. Chapter 6: Literals, Operators, and Expressions. Chapter 7: Arrays. Chapter 8: Equations. Chapter 9: Algorithms and Functions. Chapter 10: Packages. Chapter 11: Annotations, Units, and Quantities. Part III: Modeling and Applications. Chapter 12: System Modeling Methodology and Continuous Model Representation. Chapter 13: Discrete Event, Hybrid, and Concurrency Modeling. Chapter 14: Basic Laws of Nature. Chapter 15: Application Examples. Chapter 16: Modelica Library Overview. Part IV: Technology and Tools. Chapter 17: A Mathematical Representation for Modelica Models. Chapter 18: Techniques and Research. Chapter 19: Environments. Appendix A: Modelica Formal Syntax. Appendix B: Mathematica-style Modelica Syntax. Appendix C: Solutions for Exercises. Appendix D: Modelica Standard Library. Appendix E: Modelica Scripting Commands. Appendix F: Related Object-Oriented Modeling Languages. Appendix G: A Modelica XML Representation. References. Index.
Conference Paper
Full-text available
How can Python users be empowered with the robust simulation, compilation and scripting abilities of a non-proprietary object-oriented, equation based modeling language such as Modelica? The immediate objective of this work is to develop an application programming interface for the OpenModelica modeling and simulation environment that would bridge the gap between the two agile programming languages Python and Modelica. The Python interface to OpenModelica – OMPython, is both a tool and a functional library that allows Python users to realize the full capabilities of OpenModelica's scripting and simulation environment requiring minimal setup actions. OMPython is designed to combine both the simulation and model building processes. Thus domain experts (people writing the models) and computational engineers (people writing the solver code) can work on one unified tool that is industrially viable for optimization of Modelica models, while offering a flexible platform for algorithm development and research.
Conference Paper
Full-text available
Modelica is a modern, strongly typed, declarative, and object-oriented language for modeling and simulation of complex systems. This paper gives a quick overview of some aspects of the OpenModelica environment - an open-source environment for modeling, simulation, and development of Modelica applications. An introduction of the objectives of the environment is given, an overview of the architecture is outlined and a number of examples are illustrated.
A new simulation and analysis environment in Python is introduced. The environment provides a graphical user interface for simulating different model types (currently Functional Mockup Units and Modelica Models), plotting result variables and applying simulation result analysis tools like Fast Fourier Transform. Additionally advanced tools for linear system analysis are provided that can be applied to the automatically linearized models. The modular concept of the software enables easy development of further plugins for both simulation and analysis.
In the last decade the use of differential-algebraic equations (DAE's) has become standard modeling practice in many applications, such as constrained mechanics and chemical process simulation. The advantages of using implicit, often computer-generated, models for dynamical processes are encouraging the use of DAE's in new areas. The information in the 1989 edition of this book is still timely. We believe that those six chapters provide a good introduction to DAE's, to some of the mathematical and numerical difficulties in working with them, and to numerical techniques that are available for their numerical solution. The BDF-based code DASSL, carefully discussed in the first edition, still is arguably the best general-purpose index one DAE integrator.
Enhanced OpenModelica Python Interface
  • S Bajracharya
Bajracharya, S. (2016). Enhanced OpenModelica Python Interface. MSc thesis, Department of Computer and Information Science, Linköping University, Sweden.