Modeling and Optimization with Optimica andJModelica.org—Languages and Tools for SolvingLarge-Scale Dynamic Optimization Problems
J. Åkesson∗,a,b, K-E. Årzéna, M. Gäfvertb, T. Bergdahlb, H. Tummescheitb
aDepartment of Automatic Control, Lund University
P.O. Box 118, SE-221 00 Lund, SwedenbModelon AB, Ideon Science Park, SE-223 70 LUND, Sweden
Abstract
The Modelica language, targeted at modeling of complex physical systems, has
gained increased attention during the last decade. Modelica is about to establish
itself as a de facto standard in the modeling community with strong support both
within academia and industry. While there are several tools, both commercial and
free, supporting simulation of Modelica models few efforts have been made in the
area of dynamic optimization of Modelica models. In this paper, an extension to
the Modelica language, entitled Optimica, is reported. Optimica enables compact
and intuitive formulations of optimization problems, static and dynamic, based
on Modelica models. The paper also reports a novel Modelica-based open source
project, JModelica.org, specifically targeted at dynamic optimization. JModel-
ica.org supports the Optimica extension and offers an open platform based on
established technologies, including Python, C, Java and XML. Examples are pro-
∗Corresponding authorEmail addresses: [email protected] (J. Åkesson),
karl[email protected] (K-E. Årzén), [email protected] (M.Gäfvert), [email protected] (T. Bergdahl), [email protected](H. Tummescheit)
Preprint submitted to Computers & Chemical Engineering November 13, 2009
Figure 1: A typical work cycle for formulation and solution of dynamic optimization problems.
vided to demonstrate the capabilities of Optimica and JModelica.org.
Key words:
Modelica, Optimica, Dynamic optimization, Model predictive control
1. Introduction
The complexity of products and processes is rapidly increasing. This complex-
ity stems both from the increasing size of systems, and increasing heterogeneity
of systems. In order to manage such complexity and to encode system knowledge
in a structured way, modeling languages, primarily intended for simulation of dy-
namic models, have been traditionally used. An example of such a language is
Modelica [1].
While modeling and simulation remain important tools for engineers in many
disciplines, the landscape is shifting towards a more flexible and diverse use of
model-based design methodologies. This trend raises new demands on associated
tools. In particular, model-based process and product development commonly
includes activities such as simulation, parameter sensitivity analysis, design op-
timization and control system development and deployment. Commonly, these
2
activities are performed in a highly iterative manner. Figure 1 illustrates a typical
work cycle. Accordingly, flexibility and interoperability are key success factors
for algorithms and tools in order to meet future challenges.
This paper focuses on dynamic optimization in the context of high-level mod-
eling languages, in particular Modelica. Optimization is used extensively in many
industrial branches, in particular in the process industry. Applications include
design optimization to develop optimal processes, set-point optimization to mini-
mize raw material and energy consumption, and on-line optimal control strategies
such as model predictive control. While there are several tools supporting dy-
namic optimization, they are typically restricted to a particular modeling domain
and a particular numerical algorithm. In this paper, a different approach is taken.
In particular, the problem of optimizing heterogeneous physical systems while
enabling use of a wide range of numerical algorithms is considered.
Sophisticated numerical optimization algorithms often have cumbersomeAPIs,
which do not always match the engineering need for high-level description for-
mats. For example, it is not uncommon for such numerical packages to be written
in C, or in Fortran, and that they require the dynamic system to be modeled as an
ODE/DAE, which is also encoded in C or Fortran. In addition, it may be required
to also encode first and second order derivatives. Although there are efficient tools
for automatic differentiation encoding of dynamic optimization problems in low-
level languages1 like C or FORTRAN is often cumbersome and error-prone. An
important goal of developing high-level languages for dynamic optimization is
therefore to bridge the gap between the engineering need for high-level descrip-
1The term low-level is relative, but is here used in relation to domain-specific languages like
Modelica.
3
tions and the APIs of numerical algorithms.
This paper presents an extension of the Modelica language [1], entitled Optim-
ica, dedicated to high-level formulation of dynamic optimization problems based
on Modelica models. Optimica consists of a few but powerful new language
constructs that enable the user to express optimization problems using high-level
descriptions on par with Modelica. Using the Optimica extension, optimization
interval, cost function, constraints and information related to the numerical algo-
rithm used to solve the problem can be specified. A key feature of Optimica is
that the formulation of the optimization problem is done independently of the nu-
merical algorithm used to solve the problem. Rather, the algorithm and associated
control parameters are specified using light weight language constructs that make
it easy to evaluate the applicability of several different algorithms.
In order to demonstrate the feasibility and effectiveness of the proposed Opti-
mica extension, a Modelica-based open source platform called JModelica.org [2]
is under development. The objective of the JModelica.org platform is to create
a flexible and extensible Modelica environment focused on optimization. The
software consists of several parts; compiler front-ends to transform Modelica and
Optimica code into a canonical representation, compiler back-ends to generate
efficient model code (currently C and XML), implementations of dynamic opti-
mization algorithms. In addition, the compilers and algorithms have been inter-
faced with Python in order to offer a convenient scripting and prototyping envi-
ronment. The main objective of the project is to create an industrially viable Mod-
elica environment for optimization, yet offering rich opportunities for research. In
particular, JModelica.org forms a vehicle for communicating industrially relevant
applications into the academic community and for propagating state of the art
4
numerical algorithms developed in the academic community into industrial use.
JModelica.org can also be used for experimental language design where Model-
ica is extended with new functionality, or as a comprehensive environment for
teaching. For more information, see the JModelica.org home page [2].
The paper is outlined as follows. In Section 2, backgrounds on Modelica, dy-
namic optimization, and optimization tools is given. In Section 3, the Optimica
extension is presented. Section 4 gives an overview of the JModelica.org open
source project, and examples are given in Section 5. The paper ends with a sum-
mary in Section 6.
2. Background
2.1. Modelica
Modelica is the result of an effort to create a unified modeling language for
complex heterogeneous physical systems. The effort started in the mid nineties
with the objective of gathering practitioners from several application fields, in-
cluding thermo-fluid systems, robotics, electronics, mechanics and avionics. In
addition, researchers specializing in computer science were part of the group that
published the first version of the Modelica language specification in 1997. The
language is continuously maintained and developed by the non-profit organization
The Modelica Association [1]—-since the start in 1997 there have been about 60
design meetings where the language has been discussed and improved. The latest
version of the specification, Modelica 3.0, was published in September 2007.
TheModelica language builds on principles of earlier languages, notably Omola [3].
Also, the bond graph formalism [4], influenced the design. One of the main tar-
gets of Modelica is to enable modeling of different physical domains in one uni-
5
fied language. This approach differs from some other modeling frameworks such
as SPICE [5] and VHDL-AMS [6] which are specialized on electrical circuits,
gPROMS [7] specialized in chemical processes, and ADAMS [8] specialized in
simulation of mechanical systems. While this heterogeneous modeling strategy
enables a high degree of flexibility, it should also be noted that Modelica lacks
some specialized features, for example intrinsic PDE support.
Modelica shares several properties with other modern modeling languages,
including gPROMS and VHDL-AMS. Modelica is an object-oriented language,
supporting fundamental concepts such as packages, classes, inheritance, and com-
ponents. These abstractions enable structuring and reuse of complex models.
Modelica is based on acausal equations, rather than assignment statements. This
property has far-reaching consequences in terms of ease of use, since it enables
the user to input equations, both differential and algebraic, in a natural text-book
style. In particular, this features eliminates the need to solve for the derivatives.
In order to enable component-based modeling, Modelica offers a mechanism to
explicitly model acausal physical interfaces: connectors. A connector models the
physical quantities involved in the interface by means of through and across vari-
ables, e.g., flow and pressure. When a component with connectors of the same
type is connected, the signal directions need not be determined by the user, but
are rather given by the topology of the component network. This methodology is
fundamentally different from that of block-based modeling used in e.g., Simulink,
see [9] for a discussion. Modelica also supports joint textual and graphical mod-
eling, mixed continuous discrete (hybrid behavior), user defined functions, and
interfacing with external C or Fortran code. For a comprehensive overview of
Modelica, see[10].
6
Figure 2: The Modelica compilation process.
Typically, Modelica code is organized into reuseable model libraries. Com-
monly, domain expert knowledge is encoded in the form of Modelica libraries,
which are then used by application engineers to construct model instances cor-
responding to a particular process or plant. The users of Modelica can then be
roughly categorized into two groups: library developers and application develop-
ers. Library developers typically work with encoding of the laws of nature in the
form of differential algebraic equations and structuring of the code. Application
engineers on the other hand, typically use predefined components and connect
them together in a graphical model editor. There are numerous Modelica libraries
available, both commercially and freely available, ranging from thermodynamics
and power plants to automotive and space applications. There is also a freely
available standard library for Modelica from The Modelica Association [1].
While the Modelica language provides a convenient modeling environment,
Modelica code is typically not immediately suitable for integration with numeri-
cal algorithms. AModelica tool therefore needs to perform several transformation
steps in order to produce model code which in turn can be interfaced with an al-
gorithm for simulation or optimization. The procedure is illustrated in Figure 2.
In a first step called flattening, the hierarchical Modelica code is transformed into
7
a flat representation consisting essentially of variables and equations. This rep-
resentation corresponds to a hybrid DAE, but it is still not suitable for use with
numerical algorithms, since it may be of high index, and it may also contain sev-
eral alias variables which can be eliminated. In a second step, structural and sym-
bolic algorithms are applied in order transform the DAE into a structured form.
The equations are then sorted using Tarjans algorithm [11] and index reduction is
performed if needed [12]. The result is a structured hybrid DAE of index one. In
a final step, efficient code (typically C code) is generated. This code, in turn, is
suited for integration with numerical algorithms.
There are several tools supporting Modelica, both commercial and free. Com-
mercial tools include Dymola [13], Simulation X [14] and MapleSim [15]. The
open source project OpenModelica [16] offers an freeModelica environment which
is mainly targeted at simulation.
2.2. Dynamic optimization
During the last five decades, the theory of dynamic optimization has received
much attention. In 1957, Bellman formulated the celebrated principle of optimal-
ity, and showed that dynamic programming was applicable to a broad range of
applications, [17]. Following this work, dynamic programming has been applied
to various fields, notably inventory control, economics, statistics, and engineering.
For a modern description, see [18, 19]. Using dynamic programming, an optimal
control law can be derived from the solution of a partial differential equation, the
Hamilton-Jacobi-Bellman equation.
Another important contribution to the theory of optimal control is the maxi-
mum principle, which was presented by Pontryagin and co-workers in 1962, see
[20]. Whereas dynamic programming provides a closed loop control law (the con-
8
trol law as a function of the system states), the maximum principle provides the
necessary conditions for an open loop control law (the control law as a function
of time) to be optimal2.
Both dynamic programming and the maximum principle has practical draw-
backs that make them hard to apply to large scale-systems. For example, in the
presence of inequality constraints, the activation sequence must be known a pri-
ori. Also, it may be difficult to find initial guesses for adjoint variables. In the last
two decades, a new family of methods has emerged to overcome these difficulties.
These methods are referred to as direct methods. Direct methods attempt to solve
dynamic optimization problems by transcribing the original infinite dimensional
dynamic problem into a finite dimensional static optimization problem. There are
two main branches within the family of direct methods, referred to as sequential
and simultaneous methods, see [21] for an overview. The sequential methods rely
on state of the art numerical integrators, typically also capable of computing state
sensitivities, and standard nonlinear programming (NLP) codes. The controls are
then usually approximated by piece-wise polynomials, which render the controls
to be parametrized by a finite number of parameters. These parameters are then
optimized. See e.g., [22, 23] for details on sequential methods. Simultaneous
methods, on the other hand, are based on collocation, and approximate both the
state and the control variables by means of piece-wise polynomials, see [24] for an
overview. This strategy requires a fine-grained discretization of the states, in order
to approximate the dynamic constraint with sufficient accuracy. Accordingly, the
NLPs resulting from application of simultaneous methods are very large, but also
2There are some exceptions, where the maximum principle yields a closed loop control law,
for example in the case of linear systems and quadratic cost.
9
sparse. In order to solve large-scale problems, the structure of the problem needs
to be explored. A detailed treatment of direct collocation methods is given in [25].
A popular extension of the single shooting algorithms ismultiple shooting [26].
In a multiple shooting algorithm, the optimization interval [t0, t f ] is divided into a
number of segments. New optimization variables corresponding to the initial con-
ditions for the states in each segment, are then introduced. This enables the dy-
namics, as well as the sensitivity equations, to be integrated independently in each
segment. In order to enforce continuity of the state profiles, equality constraints
are introduced in the optimization problem to ensure continuous state profiles. Ex-
tensions of the multiple shooting algorithm include the DAE case, see [27], and
application to real-time model predictive control, see [28].
2.3. Optimization tools
There are several tools for optimization on the market, offering different fea-
tures. In essence, three different categories of tools can be distinguished, although
the functionality is sometimes overlapping. Model integration tools addresses the
problem of interfacing several design tools into a a single computation environ-
ment, where analysis, simulation and optimization can be performed. Examples
are ModelCenter, [29], OptiY, [30], modeFRONTIER [31], and iSIGHT, [32].
Typically, such tools are dedicated to design optimization of extremely complex
systems which may be composed from subsystems encoded in different tools. Ac-
cordingly, model integration tools typically offers interfaces to CAD and finite el-
ement software as well as simulation tools for, e.g., mechanical and hydraulic sys-
tems. As a result of the heterogeneity and complexity of the target models, models
are usually treated as black boxes, i.e. the result of a computation is propagated
to the tool, but the structure of a particular model is not explored. Accordingly,
10
heuristic optimization algorithms which do not require derivative information or
detailed structural information, are usually employed. In addition, model integra-
tion tools often have sophisticated features supporting model approximation and
visualization.
Several modeling tools come with optimization add-ons, e.g., Dymola [13],
gPROMS [7] and Jacobian [33], which is a successor of the Abacuss system [34].
Such tools typically offer strong support for modeling of physical systems and
simulation. The level of support for optimization in this category differs between
different tools. Dymola, for example, offers add-ons for parameter identification
and design optimization, [35]. gPROMS, specifically the module gOPT, on the
other hand, offers support for solution of optimal control problems and has the
additional benefit in comparison with Modelica tools to provide support for par-
tial differential equations (PDEs). Tools in this category are usually limited to a
predefined set of optimization algorithms. Integration of new algorithms may be
difficult if the tools do not provide the necessary API:s.
In the third category we have numerical packages for dynamic optimization,
often developed as part of research programs. Examples are ACADO [36], Mus-
cod II [37], and DynoPC [38], which is based on Ipopt [39]. Such packages are
typically focused on efficient implementation of an optimization algorithm for a
particular class of dynamic systems. Also, detailed information about the model
to optimize is generally required in order for such algorithms to work, including
accurate derivatives and in some cases also sparsity patterns. Some of the pack-
ages in this category are also targeting optimal control and estimation problems
in real-time, e.g., non-linear model predictive control, which require fast conver-
gence. While these packages offer state of the art algorithms, they typically come
11
with simple or no user interface. Their usage is therefore limited due to the effort
required to code the model and optimization descriptions.
The JModelica.org platform is positioned to fill the gap left between simu-
lation tools offering optimization capabilities and state of the art numerical al-
gorithms. In comparison with gPROMS/gOPT, the main advantages of JModel-
ica.org are that it is based on an open standard, Modelica, it comes with open
interfaces suitable for algorithm integration, and that it is freely available as open
source software. Now, gPROMS/gOPT are highly sophisticated products which
have been applied in a large number of industrial applications. JModelica.org, on
the other hand, is currently more geared towards experimental algorithm develop-
ment, research and education.
Primarily, target algorithms of JModelica.org are gradient-based methods of-
fering fast convergence. Never the less, JModelica.org is well suited for use also
with heuristic direct search methods; the requirements with respect to execution
interface is typically a subset of the requirements for gradient based methods.
The problems addressed by model integration tools is currently beyond the scope
of JModelica.org, even though its integration with Python offers extensive pos-
sibilities to develop custom applications based on the solution of simulation and
optimization problems.
3. Optimica
3.1. Information structure
In order to formulate a dynamic optimization problem, to be solved by a nu-
merical algorithm, the user must supply different kinds of information. It is natural
to categorize this information into three levels, corresponding to increasing levels
12
of detail.
• Level I. At the mathematical level, a canonical formulation of a dynamic
optimization problem is given. This include variables and parameters to
optimize, cost function to minimize, constraints, and the Modelica model
constituting the dynamic constraint. The optimization problem formulated
at this level is in general infinite dimensional, and is thereby only partial in
the respect that it cannot be directly used by a numerical algorithm without
additional information, for example, concerning transcription of continuous
variables.
• Level II. At the transcription level, a method for translating the problem
from an infinite dimensional problem to a finite dimensional problem needs
to be provided. This might include discretization meshes as well as initial
guesses for optimization parameters and variables. It should be noticed
that the information required at this level is dependent on the numerical
algorithm that is used to solve the problem.
• Level III. At the algorithm level, information such as tolerances and algo-
rithm control parameters may be given. Such parameters are often critical in
order to achieve acceptable performance in terms of convergence, numerical
reliability, and speed.
An important issue to address is whether information associated with all levels
should be given in the language extension. In Modelica, only information corre-
sponding to Level I is expressed in the actual model description. Existing Mod-
elica tools then typically use automatic algorithms for critical tasks such as state
selection and calculation of consistent initial conditions, although the algorithms
13
can be influenced by the user via the Modelica code, by means of annotations3, or
attributes, such as StateSelect. Yet other information, such as choice of solver,
tolerances and simulation horizon is provided directly to the tool, either by means
of a graphical user interface, a script language, or alternatively, in annotations.
For dynamic optimization, the situation is similar, but the need for user input
at the algorithm level is more emphasized. Automatic algorithms, for example
for mesh selection, exist, but may not be suitable for all kinds of problems. It
is therefore desirable to include, in the language, means for the user to specify
most aspects of the problem in order to maintain flexibility, while allowing for
automatic algorithms to be used when possible and suitable.
Relating to the three levels described above, the approach taken in the design
of Optimica is to extend the Modelica language with a few new language con-
structs corresponding to the elements of the mathematical description of the opti-
mization problem (level I). The information included in levels II and III, however,
may rather be specified by means of annotations.
3.2. Dynamic system model
The scope of Optimica can be separated into two parts. The first part is con-
cerned with the class of models that can be described in Modelica. Arguably,
this class is large, since very complex, non-linear and hybrid behavior can be en-
coded in Modelica. From a dynamic optimization perspective, the inherent com-
plexity of Modelica models is a major challenge. Typically, different algorithms
for dynamic optimization support different model structures. In fact, the key to
3Annotations are light weight Modelica language elements that are typically used to provide
options to algorithms and solvers.
14
developing efficient algorithms lies in exploiting the structure of the model be-
ing optimized. Consequently, there are different algorithms for different model
structures, such as linear systems, non-linear ODEs, general DAEs, and hybrid
systems. In general, an algorithm can be expected to have better performance, in
terms of convergence properties and shorter execution times, if the model struc-
ture can be exploited. For example, if the model is linear, and the cost function is
quadratic, the problem can be obtained very efficiently by solving a Riccati equa-
tion. On the other hand, optimization of general non-linear and hybrid DAEs is
still an area of active research, see for example [40]. As a result, the structure of
the model highly affects the applicability of different algorithms. The Optimica
compiler presented in this paper relies on a direct collocation algorithm in order
to demonstrate the proposed concept. Accordingly, the restrictions imposed on
model structure by this algorithm apply when formulating the Modelica model,
upon which the optimization problem is based. For example, this excludes the use
of hybrid constructs, since the right hand side of the dynamics is assumed to be
twice continuously differentiable. Obviously, this restriction excludes optimiza-
tion of many realistic Modelica models. On the other hand, in some cases, re-
formulation of discontinuities to smooth approximations may be possible in order
to enable efficient optimization. This is particularly important in on-line applica-
tions. The Optimica extension, as presented in this paper, could also be extended
to support other algorithms, which are indeed applicable to a larger class of mod-
els.
3.3. The dynamic optimization problem
The second part of the scope of Optimica is concerned with the remaining el-
ements of the optimization problem. This includes cost functions, constraints and
15
variable bounds. Consider the following formulation of a dynamic optimization
problem:
minu(t),p
ψ(z, p) (1)
subject to the dynamic system
F(x(t),x(t),y(t),u(t), p, t)= 0, t ∈ [t0, t f ] (2)
and the constraints
cineq(x(t),y(t),u(t), p)≤ 0 t ∈ [t0, t f ] (3)
ceq(x(t),y(t),u(t), p) = 0 t ∈ [t0, t f ] (4)
cpineq(z, p) ≤ 0 (5)
cpeq(z, p) = 0 (6)
where x(t) ∈ Rnx are the dynamic variables, y(t) ∈ Rny are the algebraic variables,
u(t)∈ Rnu are the control inputs, and p ∈ Rnp are parameters which are free in the
optimization. In addition, the optimization is performed on the interval t ∈ [t0, t f ],
where t0 and t f can be fixed or free, respectively. The initial values of the dynamic
and algebraic variables may be fixed or free in the optimization. The vector z is
composed from discrete time points of the states, controls and algebraic variables;
z = [x(t1), ..,x(tNp),y(t1), ..,y(tNp
),u(t1), ..,u(tNp)]T , ti ∈ [t0, t f ], where Np denotes
the number of time points included in the optimization problem.
The constraints include inequality and equality path constraints, (3)-(4). In
addition, inequality and equality point constraints, (5)-(6), are supported. Point
constraints are typically used to express initial or terminal constraints, but can
also be used to specify constraints for time points in the interior of the interval.
16
The cost function (1) is a generalization of a terminal cost function, φ(t f ), in
that it admits inclusion of variable values at other time instants. This form in-
cludes some of the most commonly used cost function formulations. A Lagrange
cost function can be obtained by introducing an additional state variable, xL(t),
with the associated differential equation xL(t) = L(x(t),u(t)), and the cost func-
tion ψ(t f ) = xL(t f ). The need to include variable values at discrete points in the
interior of the optimization interval in the cost function arises for example in pa-
rameter estimation problems. In such cases, a sequence of measurements, yd(ti),
obtained at the sampling instants ti, i ∈ 1 . . .Nd is typically available. A cost func-
tion candidate is then:
Nd
∑i=1
(y(ti)− yd(ti))TW (y(ti)− yd(ti)) (7)
where y(ti) is the model response at time ti andW is a weighting matrix.
Another important class of problems is static optimization problems on the
form:minu,p
ϕ(x,y,u, p)
subject to
F(0,x,y,u, p, ts) = 0
cineq(x,u, p) ≤ 0
ceq(x,u, p) = 0
(8)
In this case, a static optimization problem is derived from a, potentially, dynamic
Modelica model by setting all derivatives to zero. Since the problem is static, all
variables are algebraic and accordingly, no transcription procedure is necessary.
The variable ts denotes the time instant at which the static optimization problem
is defined.
17
In this paper a direct collocation method (see for example [24]) will be used to
illustrate how the transcription step can also be encoded in the Optimica extension.
The information that needs to be provided by the user is then a mesh specification,
the collocation points, and the coefficients of the interpolation polynomials.
3.4. The Optimica extension
In this section, the Optimica extension will be presented and informally de-
fined. The presentation will be made using the following dynamic optimization
problem, based on a double integrator system, as an example:
minu(t)
∫ t f
01dt (9)
subject to the dynamic constraint
x(t) = v(t), x(0) = 0
v(t) = u(t), v(0) = 0(10)
andx(t f ) = 1, v(t f ) = 0
v(t) ≤ 0.5, −1≤ u(t)≤ 1(11)
In this problem, the final time, t f , is free, and the objective is thus to minimize the
time it takes to transfer the state of the double integrator from the point (0,0) to
(1,0), while respecting bounds on the velocity v(t) and the input u(t). A Modelica
model for the double integrator system is shown in Listing 1.
In summary, the Optimica extension consists of the following elements:
• A new specialized class: optimization
• New attributes for the built-in type Real: free and initialGuess.
18
model DoubleIntegrator
Real x(start=0);
Real v(start=0);
input Real u;
equation
der(x)=v;
der(v)=u;
end DoubleIntegrator;
Listing 1: A Modelica model of a double integrator system.
• A new function for accessing the value of a variable at a specified time
instant
• Class attributes for the specialized class optimization: objective, startTime,
finalTime and static
• A new section: constraint
• Inequality constraints
• An annotation for providing transcription information
3.4.1. A new specialized class
It is convenient to introduce a new specialized class, called optimization,
in which the proposed Optimica-specific constructs are valid. This approach is
consistent with the Modelica language, since there are already several other spe-
cialized classes, e.g., record, function and model. By introducing a new spe-
cialized class, it also becomes straightforward to check the validity of a program,
19
since the Optimica-specific constructs are only valid inside an optimization
class. The optimization class corresponds to an optimization problem, static or
dynamic, as specified in Section 3.3. Apart from the Optimica-specific constructs,
an optimization class can also contain component and variable declarations, lo-
cal classes, and equations.
It is not possible to declare components from optimization classes in the
current version of Optimica. Rather, the underlying assumption is that an optimization
class defines an optimization problem, that is solved off-line. An interesting ex-
tension would, however, be to allow for optimization classes to be instantiated.
With this extension, it would be possible to solve optimization problems, on-line,
during simulation. A particularly interesting application of this feature is model
predictive control, which is a control strategy that involves on-line solution of
optimization problems during execution.
As a starting-point for the formulation of the optimization problem (9)-(11),
consider the optimization class:
optimization DIMinTime
DoubleIntegrator di;
end DIMinTime;
This class contains only one component representing the dynamic system model,
but will be extended in the following to incorporate also the other elements of the
optimization problem.
20
3.4.2. Attributes for the built-in type Real
In order to superimpose information on variable declarations, two new at-
tributes are introduced for the built-in type Real4. Firstly, it should be possible
to specify that a variable, or parameter, is free in the optimization. Modelica pa-
rameters are normally considered to be fixed after the initialization step, but in
the case of optimization, some parameters may rather be considered to be free. In
optimal control formulations, the control inputs should be marked as free, to indi-
cate that they are indeed optimization variables. For these reasons, a new attribute
for the built-in type Real, free, of boolean type is introduced. By default, this
attribute is set to false.
Secondly, an attribute, initialGuess, is introduced to enable the user to pro-
vide an initial guess for variables and parameters. In the case of free optimiza-
tion parameters, the initialGuess attribute provides an initial guess to the op-
timization algorithm for the corresponding parameter. In the case of variables,
the initialGuess attribute is used to provide the numerical solver with an initial
guess for the entire optimization interval. This is particularly important if a simul-
taneous or multiple-shooting algorithm is used, since these algorithms introduce
optimization variables corresponding to the values of variables at discrete points
over the interval. Notice that such initial guesses may be needed both for control
and state variables. For such variables, however, the proposed strategy for provid-
ing initial guesses may sometimes be inadequate. In some cases, a better solution
is to use simulation data to initialize the optimization problem. This approach is
also supported by the Optimica compiler.
4The same attributes may be introduced for the built-in type Integer, in order to support also
variables of type Integer in the optimization formulation
21
In the double integrator example, the control variable u is a free optimization
variable, and accordingly, the free attribute is set to true. Also, the initialGuess
attribute is set to 0.0.
optimization DIMinTime
DoubleIntegrator di(u(free=true,
initialGuess=0.0));
end DIMinTime;
3.4.3. A Function for accessing instant values of a variable
An important component of some dynamic optimization problems, in partic-
ular parameter estimation problems where measurement data is available, is vari-
able access at discrete time instants. For example, if a measurement data value, yi,
has been obtained at time ti, it may be desirable to penalize the deviation between
yi and a corresponding variable in the model, evaluated at the time instant ti. In
Modelica, it is not possible to access the value of a variable at a particular time
instant in a natural way, and a new construct therefore has to be introduced.
All variables in Modelica are functions of time. The variability of variables
may be different—some are continuously changing, whereas others can change
value only at discrete time instants, and yet others are constant. Nevertheless, the
value of a Modelica variable is defined for all time instants within the simulation,
or optimization, interval. The time arguments of variables are not written explic-
itly in Modelica, however. One option for enabling access to variable values at
specified time instants is therefore to associate an implicitly defined function with
a variable declaration. This function can then be invoked by the standard Model-
ica syntax for function calls, y(t_i). The name of the function is identical to the
name of the variable, and it has one argument; the time instant at which the vari-
22
able is evaluated. This syntax is also very natural since it corresponds precisely to
the mathematical notation of a function. Notice that the proposed syntax y(t_i)
makes the interpretation of such an expression context dependent. In order for
this construct to be valid in standard Modelica, y must refer to a function decla-
ration. With the proposed extension, y may refer either to a function declaration
or a variable declaration. A compiler therefore needs to classify an expression
y(t_i) based on the context, i.e., what function and variable declarations are vis-
ible. An alternative syntax would have been to introduce a new built-in function,
that returns the value of a variable at a specified time instant. While this alterna-
tive would have been straightforward to implement, the proposed syntax has the
advantages of being easier to read and that it more closely resembles the corre-
sponding mathematical notation. This feature of Optimica is used in the constraint
section of the double integrator example, and is described below.
3.4.4. Class attributes
In the optimization formulations (1)-(6) and (8), there are elements that occur
only once, i.e., the cost function and the optimization interval in (1)-(6), and in
the static case (8), only the cost function. These elements are intrinsic properties
of the respective optimization formulations, and should be specified, once, by the
user. In this respect the cost function and optimization interval differ from, for
example, constraints, since the user may specify zero, one or more of the latter.
One option for providing this kind of information is to introduce a built-in
class, call it Optimization, and require that all optimization classes inherit
from Optimization. Information about the cost function and optimization inter-
val may then be given as modifications of components in this built-in class:
optimization DIMinTime
23
extends Optimization(
objective=cost(finalTime),
startTime=0,
finalTime(free=true,initialGuess=1));
Real cost;
DoubleIntegrator di(u(free=true,
initialGuess=0.0));
equation
der(cost) = 1;
end DIMinTime;
Here, objective, startTime and finalTime are assumed to be components
located in Optimization, whereas cost is a variable which is looked up in the
scope of the optimization class itself. Notice also how the cost function, cost,
has been introduced, and that the finalTime attribute is specified to be free in
the optimization. This approach of inheriting from a built-in class has been used
previously, in the tool Mosilab [41], where the Modelica language is extended to
support statecharts. In the statechart extension, a new specialized class, state,
is introduced, and properties of a state class (for example whether the state is
an initial state) can be specified by inheriting from the built-in class State and
applying suitable modifications.
The main drawback of the above approach is its lack of clarity. In particular,
it is not immediately clear that Optimization is a built-in class, and that its con-
tained elements represent intrinsic properties of the optimization class, rather
than regular elements, as in the case of inheritance from user or library classes.
To remedy this deficiency, the notion of class attributes is proposed. This idea
24
is not new, but has been discussed previously within the Modelica community.
A class attribute is an intrinsic element of a specialized class, and may be mod-
ified in a class declaration without the need to explicitly extend from a built-in
class. In the Optimica extension, four class attributes are introduced for the spe-
cialized class optimization. These are objective, which defines the cost func-
tion, startTime, which defines the start of the optimization interval, finalTime,
which defines the end of the optimization interval, and static, which indicates
whether the class defines a static or dynamic optimization problem. The proposed
syntax for class attributes is shown in the following optimization class:
optimization DIMinTime (
objective=cost(finalTime),
startTime=0,
finalTime(free=true,initialGuess=1))
Real cost;
DoubleIntegrator di(u(free=true,
initialGuess=0.0));
equation
der(cost) = 1;
end DIMinTime;
The default value of the class attribute static is false, and accordingly, it does
not have to be set in this case. In essence, the keyword extends and the refer-
ence to the built-in class have been eliminated, and the modification construct is
instead given directly after the name of the class itself. The class attributes may
be accessed and modified in the same way as if they were inherited.
25
3.4.5. Constraints
Constraints are similar to equations, and in fact, a path equality constraint is
equivalent to a Modelica equation. But in addition, inequality constraints, as well
as point equality and inequality constraints should be supported. It is therefore
natural to have a separation between equations and constraints. In Modelica, ini-
tial equations, equations, and algorithms are specified in separate sections, within
a class body. A reasonable alternative for specifying constraints is therefore to in-
troduce a new kind of section, constraint. Constraint sections are only allowed
inside an optimization class, and may contain equality, inequality as well as
point constraints. In the double integrator example, there are several constraints.
Apart from the constraints specifying bounds on the control input u and the ve-
locity v, there are also terminal constraints. The latter are conveniently expressed
using the mechanism for accessing the value of a variable at a particular time in-
stant; di.x(finalTime)=1 and di.v(finalTime)=0. In addition, bounds may
have to be specified for the finalTime class attribute. The resulting optimization
formulation may now be written:
optimization DIMinTime (
objective=cost(finalTime),
startTime=0,
finalTime(free=true,initialGuess=1))
Real cost;
DoubleIntegrator di(u(free=true,
initialGuess=0.0));
equation
der(cost) = 1;
constraint
26
finalTime>=0.5;
finalTime<=10;
di.x(finalTime)=1;
di.v(finalTime)=0;
di.v<=0.5;
di.u>=1; di.u<=1;
end DIMinTime;
3.4.6. Annotations for specification of the transcription scheme
The transcription scheme used to transform the infinite-dimensional dynamic
optimization problem into a finite-dimensional approximate problem usually in-
fluences the properties of the numerical solution. Nevertheless, transcription in-
formation can be considered to be complimentary information, that is not part
of the mathematical definition of the optimization problem itself. Also, tran-
scription information is closely related to particular numerical algorithms. It is
therefore reasonable not to introduce new language constructs, but rather new an-
notations for specification of transcription schemes. This solution is also more
flexible, which is important in order easily accommodate transcription schemes
corresponding to algorithms other than the direct collocation method currently
supported.
4. The JModelica.org platform
In order to demonstrate the feasibility and effectiveness of the proposed Op-
timica extension, a prototype compiler was developed, [42]. Currently, the initial
prototype compiler is being developed with the objective of creating a Modelica-
based open source platform focused on dynamic optimization.
27
Figure 3: Overview of the JModelica.org platform architecture.
The architecture of the JModelica.org platform is illustrated in Figure 3. The
platform consists essentially of two main parts: the compiler and the JModel-
ica.org Model Interface (JMI) run-time library. The compiler translates Modelica
and Optimica source code into a flat model description, then applies symbolic al-
gorithms to transform the model into a hybrid DAE, and finally generates C and
XML code. The generated C code contains the actual model equations in a format
suitable for efficient evaluation, whereas the XML code contains model meta data,
such as variable names and parameter values. The JMI run-time library provides
a C interface which in turn can be interfaced with numerical algorithms. There is
also an Eclipse plug-in and a Python integration module under development. In
this section, the key parts of the JModelica.org platform will be described.
28
model M
Real x;
equation
x = 1;
end M;
Figure 4: A simple Modelica model (left) and its corresponding abstract syntax tree (right). The
dashed arrow represents the reference attribute myDecl which binds an identifier to its declaration.
4.1. Compiler development—JastAdd
Compiler construction has traditionally been associated with intricate pro-
gramming techniques within the area of computer science. Recent research effort
has, however, resulted in new compiler construction frameworks that are easier
to use and where it is feasible to develop compilers with a comparatively reason-
able effort. One such framework is JastAdd [43, 44]. JastAdd is a Java-based
compiler construction framework based on concepts such as object-orientation,
aspect-orientation and reference attributed grammars [45]. At the core of JastAdd
is an abstract syntax specification, which defines the structure of a computer pro-
gram. Based on an abstract syntax tree (AST), the compiler performs tasks such as
name analysis, i.e, finding declarations corresponding to identifiers, type analysis,
i.e., verifying the type correctness of a program, and code generation.
The JastAdd way of building compilers involves specification of attributes
and equations based on the abstract syntax specification. This feature is very sim-
ilar to ordinary Knuth-style attribute grammars [46] but enhanced with reference
attributes. Accordingly, attributes may be used to specify, declaratively, links be-
tween different nodes in the AST. For example, identifier nodes can be bound to
29
their declaration nodes. In Figure 4, an example of a small Modelica program and
its corresponding AST is shown. Notice how the reference attribute myDecl links
an identifier (IdUse) to its declaration (CompDecl).
JastAdd attributes and equations are organized into separate aspects, which
form a convenient abstraction for encoding of cross cutting behavior. Typically,
implementation of a semantic function, for example type analysis, involves adding
code to large number of classes in the AST specification. Using aspects, much like
in AspectJ [47], cross cutting behavior can be modularized in a natural way. In
addition, this approach is the basis for one of the distinguishing features of Jas-
tAdd: it enables development of modularly extensible compilers. This means that
it is feasible to develop, with a comparatively moderate effort, modular extensions
of an existing JastAdd compiler without changing the core compiler. This feature
has been used in the implementation of the JModelica.org Modelica and Optimica
compilers, where the Optimica compiler is a fully modular extension of the core
Modelica compiler.
The JastAdd compiler transforms the JastAdd specification into pure Java
code, where the definition of the abstract grammar translates into Java classes
corresponding to Modelica classes, components, functions, and equations. The
JastAdd attributes are woven into the Java classes as methods. In addition, meth-
ods for traversing an AST and query properties of a particular AST class, e.g.,
obtain a list of variables contained in a class declaration, are automatically gener-
ated. As a result of this approach, compilers produced by JastAdd are in the form
of standard Java packages, which in turn can be integrated in other applications.
It is therefore not necessary to know the particular details of how to write JastAdd
specifications in order to use the JModelica.org compilers, knowledge of Java is
30
generally sufficient.
4.2. The Modelica and Optimica compilers
At the core of the JModelica.org platform is a Modelica compiler that is capa-
ble of transforming Modelica code into a flat representation and of generating C
code. In the Modelica compiler, several design strategies, for example name look-
up, developed for a Java compiler developed using JastAdd [48], were reused. For
additional details on the implementation of the compiler, see [49]. In order to
support also the Optimica extension, an extended compiler capable of translating
standard Modelica enhanced with the new Optimica syntax presented in Section 3
has also been developed.
The JModelica.orgModelica compiler currently supports a subset of Modelica
version 3.0. The Modelica Standard Library version 3.0.1 can be parsed and the
corresponding source AST can be constructed. Flattening support is more limited,
but is being continuously improved.
4.3. Code generation
The JModelica.org offers a code generation framework implemented in Java
as part of the compilers. The framework facilitates development of custom code
generation modules and is based on templates and tags. A template is used to
specify the structure of the generated code and tags are used to define elements
of the template which is to be replaced by generated code. In order to develop
a custom code generation module, the compiler developer needs to define a tem-
plate and a set of tags, and then implement the actual code generation behavior
corresponding to each tag. In order to perform the latter, the AST for the flattened
Modelica model is typically used, where objects corresponding to declarations,
31
equations and functions are queried for information used to generate the target
code.
The JModelica.org platform contains two code generation modules, one for
C and one for XML. The generated C code contains the model equations and is
intended to be compiled and linked with the JModelica.org Model Interface (see
below) in order to offer efficient evaluation of the model equations. The XML
export is described below in Section 4.5
4.4. C API
The JModelica.org platform offers a C API, entitled the JModelica.org Model
Interface (JMI5), suitable for integration with numerical algorithms. The inter-
face provides functions for accessing and setting parameter and state values, for
evaluation of the DAE residual function and for evaluation of cost functions and
constraints specified in an Optimica model. In addition, Jacobians and sparsity
patterns can be obtained for all functions in the interface. To meet this end, a
package for automatic differentiation, CppAD [50], has been integrated into JMI.
Computation of derivatives may be done in several ways. One option is to use
symbolic or automatic differentiation based on the ASTs in the compiler and then
generate C code for the differentiated expressions. Another option is to export an
XML model representation and then define an automatic differentiation scheme
as an XSLT transformation, [51, 52]. The choice of CppAD was done in order
to provide derivatives and sparsity patterns in a simple way in the context of the
execution interface. The JMI code is intended to be compiled with the C code that
is generated by the compiler into an executable, or into a shared object file.
5Notice that this acronym is unrelated to Java Metadata interface
32
The JMI interface consists of four parts: the ODE interface, the DAE interface,
the DAE initialization interface, and the Optimization interface. These interfaces
provide access to functions relevant for different parts of the optimization speci-
fication. The ODE and DAE interfaces provide evaluation functions for the right
hand side of the ODE and the DAE residual function respectively. The DAE ini-
tialization problem provides functions for solving the DAE initialization problem,
whereas the Optimization interface provides functions for evaluation of the cost
functions and the constraints.
4.5. XML export
The XML output consists of model meta data such as specifications of vari-
ables, including their names, attributes and type. Also, the XML output includes a
separate file for parameter values. The XML output is similar to what is discussed
within the FMI initiative [53], and the intention is for the JModelica.org XML
output to be compliant with FMI once finalized. In addition, there is on-going
work aimed to develop an XML specification for flattened Modelica models, in-
cluding variable declarations, functions, and equations [54]. This XML format is
similar to CapeML, [55], although geared towards representation of flat Model-
ica models. Providing XML export as a complement to the C model execution
interface is motivated by the large body of general purpose tools for transforming
XML into various formats. As noted above, an automatic differentiation scheme
may be encoded as an XSLT transformation. Also, XSLT transformations may be
used to encode code generation schemes.
33
4.6. Interactive environment—Python
Solution of engineering problems typically involves atomization of tasks in the
form of user scripts. Common examples are batch simulations, parameter sweeps,
post processing of simulation results and plotting. Given that JModelica.org is
directed towards scientific computing, Python, see [56], is an attractive option.
Python is a free open-source highly efficient and mature scripting language with
strong support in the scientific community. Packages such as NumPy [57] and
SciPy [58], and bindings to state-of-the art numerical codes implemented in C and
Fortran make Python a convenient glue between JModelica.org and numerical al-
gorithms. In addition, IPython [59] with the visualization package matplotlib [60]
and the PyLab mode offer an interactive numerical environment similar to the
ones offered by Matlab and Scilab.
The JModelica.org Pyhon package includes sub packages for running the com-
pilers, for managing file input/output of simulation/optimization results and for
accessing the function provided by the JMI interface. The compilers are run in
a Java Virtual Machine (JVM) which is connected to the Python environment by
the package JPype, [61]. One of JPype’s main features is to enable direct access
to Java objects from a Python shell or script. This feature is used to communi-
cate with the compilers, but can also be used to retrieve the ASTs generated by
the compilers. The latter feature enables the user to traverse and query the ASTs
interactively, to perform analyses and transformations of models.
The integration of the JMI is based on the ctypes package [62]. Using ctypes,
a dynamically linked library (DLL) can be loaded into Python, All the contained
functions of the DLL are then exposed and can be called directly from the Python
shell. In order to enable use of NumPy arrays and matrices as arguments to the
34
JMI functions, the argument types have been explicitly encoded using standard
features of ctypes. In order to provide a more convenient interface to the JMI
functions, a Python class, Model has been created. This class encapsulates loading
of a DLL and typing of the JMI functions, and also provides wrapper functions
supporting Python exceptions. In addition, upon creation of a Model class, the
generated XMLmeta data files are loaded and parameter values and start attributes
are set in the loaded model instance. Model objects can then be manipulated, e.g.,
by setting new parameter values, or passed as an argument to a simulation or
optimization algorithm.
4.7. Optimization algorithms
The JModelica.org platform offers two different algorithms for solving dy-
namic optimization problems. The first is a simultaneous optimization method
based on orthogonal collocation on finite elements [24]. Using this method, state
and input profiles are parametrized by Lagrange polynomials which are based on
Radau points. This method corresponds to a fully implicit Runge-Kutta method,
and accordingly it possesses well known and strong stability properties. By pa-
rameterizing the variable profiles by polynomials, the dynamic optimization prob-
lem is translated into a non-linear programming (NLP) problem which may be
solved by a numerical NLP solver. This NLP is, however, very large. In order to
efficiently find a solution to the NLP, derivative information as well as the sparsity
patterns of the constraint Jacobians need to be provided to the solver. The simulta-
neous optimization algorithm has been interfaced with the large-scale NLP solver
Ipopt [39], which has been developed particularly to solve NLP problems arising
in simultaneous dynamic optimization methods. The algorithm is implemented in
C as an extension of JMI, and provides an example of how to implement algo-
35
rithms based on the JMI functions. In particular, Jacobians computed by CppAD
are used, including sparsity patterns.
In addition to the simultaneous optimization algorithm, JModelica.org con-
tains a multiple shooting algorithm, [26]. The algorithm is based on an integra-
tor which is used to simulate the system dynamics and thereby evaluate the cost
function, and an optimization algorithm which modifies the optimization vari-
ables. Typically, the optimization variables are Modelica parameters in the case
of a design or parameter optimization problem, or parameters resulting from dis-
cretization of a control input. The multiple shooting algorithm is implemented
in Python, and relies on the integrator SUNDIALS [63], its Python interface Py-
SUNDIALS [64], and the optimization algorithm scipy_slsqp, which is included
in Scipy. In order to improve the convergence of the optimization algorithm sen-
sitivities are computed and propagated to the optimization algorithm. The sen-
sitivities are computed using SUNDIALS. The implementation serves also as an
example of how to develop algorithms based on the JModelica.org Python inter-
face. The multiple shooting algorithm is described in more detail in [65].
The above algorithms are both based on the availability of derivatives. For
some optimization problems, it is not possible to reliably compute derivatives,
and accordingly, numerical optimization algorithms requiring derivative informa-
tion may fail. This situation may occur for certain classes of hybrid systems. In
such cases, heuristic methods which do not require derivativemethods may be bet-
ter suited. Examples of such methods are genetic algorithms, pattern matching,
simulated annealing, and simplex (Nelder-Mead). Some methods of this class are
freely available for Python, see the OpenOpt project [66] for more information,
and may be integrated with the JMI Python interface.
36
4.8. Applications
Prototype versions of the JModelica.org software have been used successfully
in applications in different domains. In [67], an application is reported where op-
timal start-up trajectories are computed for a plate reactor. The problem is chal-
lenging not only due to the complexity of the model (approx. 130 differential and
algebraic equations), but also due to non-linear and in some conditions unstable
dynamics. A main challenge in this project was to obtain trajectories robust to
parameter variations. The procedure of finding acceptable solutions was highly
iterative in that the cost function and the constraints required several redesigns.
The high-level specification framework in combination with automatic code gen-
eration offered by Optimica and the JModelica.org platform proved very useful
in this respect and motivated further efforts to develop the platform into an open
source project.
The prototype software has as also been used in a number of other projects
involving vehicle systems. For example, in [68] optimal tracks for racing cars
were optimized, and in [69], optimal rail profiles were computed for a novel mass
transportation system, the NoWait train concept. Other examples where Optimica
has been used are reported in [70] where minimum time optimization for an in-
dustrial robot is considered and in [71] where an optimal control application of a
pendulum system is reported.
5. Examples
The examples presented in this section, together with several others, are freely
available at [2].
37
5.1. Model predictive control of a CSTR system
We consider the Hicks-Ray Continuously Stirred Tank Reactor (CSTR) con-
taining an exothermic reaction, [72]. The states of the system are the reactor
temperature T and the reactant concentration c. The reactant inflow rate, F0, con-
centration, c0, and temperature, T0, are assumed to be constant. The input of the
system is the cooling flow temperature Tc. The dynamics of the system is then
given by:
c(t) = F0(c0− c(t))/V − k0e−EdivR/T (t)c(t)
T (t) = F0(T0−T (t))/V −dH/(ρCp)k0e−EdivR/T (t)c(t)+2U/(rρCp)(Tc(t)−T(t))
(12)
where r, k0, EdivR,U , ρ , Cp, dH, and V are physical parameters.
Based on the CSTR model, the following dynamic optimization problem is
formulated:
minTc(t)
∫ t f
0(cre f − c(t))2+(T re f
−T (t))2+(T re fc −Tc(t))
2dt (13)
subject to the dynamics (12). The cost function corresponds to a load change of
the system and penalizes deviations from a desired operating point given by target
values cre f , T re f and Tre fc for c, T and Tc respectively. Stationary operating con-
ditions were computed based on constant cooling temperatures Tc = 250 (initial
conditions) and Tc = 280 (reference point). The stationary points were computed
using a initialization algorithm available in JModelica.org.
The load change defined by (13) corresponds to ignition of the reactor, i.e., the
initial conditions correspond to a cold reactor were little reaction takes place and
the target set-point corresponds to production conditions. Due to the exothermic
character of the reaction and the highly temperature dependent reaction kinetics,
38
0 20 40 60 80 100 120 140 1603004005006007008009001000
c
0 20 40 60 80 100 120 140 160240260280300320340360
T
0 20 40 60 80 100 120 140 160t
260280300320340360380
Tc
Figure 5: Optimization result for the CSTR example. The target set-points are indicated by dashed
lines.
ignition of the reactor while avoiding temperature overshoot is a challenging con-
trol problem. An additional bound on the temperature was therefore added
T (t)≤ 350. (14)
The Modelica and Optimica descriptions for the CSTR model and the optimal
control problem, respectively, were translated into C code by the Optimica com-
piler and the resulting NLP was solved using IPOPT, see Section 4 for details on
the collocation method implemented in JModelica.org. The optimal control pro-
files are shown in Figure 5. As can be seen, the state profiles are converging to the
39
reference set-point.
The optimal control problem formulated above can also be used in conjunc-
tion with other algorithms available in JModelica.org. To demonstrate this, a sim-
ple non-linear model predictive controller (NMPC) has been implemented. The
NMPC control strategy is based on the receding horizon principle, where an open
loop optimal control problem is solved in each sample. Simulation of an NMPC
requires joint simulation of the plant and solution of the optimal control problem.
Simulation is supported in JModelica.org by the SUNDIALS DAE integrator, see
Section 4. The algorithm for executing the NMPC and the simulation algorithm
were implemented in a Python script.
In order to avoid numerical difficulties resulting from infeasible initial con-
ditions in operating conditions where the temperature bound is active, the hard
constraint was complemented by a soft constraint penalty term:
γ(t) = i f T (t) <= 345 then 0 else (T (t)−345)4 (15)
which gives the augmented cost function
minTc(t)
∫ t f
0(cre f − c(t))2+(T re f
−T (t))2+(T re fc −Tc(t))
2+1000γ(t)dt. (16)
Notice that the term γ does not introduce any discontinuity in the cost function.
Also, the temperature bound was kept in the optimization formulation. The result
of executing the NMPC is shown in Figure 6. The prediction horizon was set to
50s and the sampling interval was assumed to be 2s.
5.2. Distillation column load change
As a second example, we consider a distillation column previously reported
in [73, 74]. The distillation column consists of 30 trays and separates a binary
40
mixture containing components A and B. The relative volatility is assumed to
have a constant value of 1.6. The feed stream, xF , is introduced at the middle of
the column, in tray 17, and has a constant composition of 0.5. The model has 32
states corresponding to the liquid compositions of component A, xi(t). The vapor
compositions of component A are denoted yi(t). Apart from the 30 trays, volumes
for the condenser and the reboiler, respectively, are included in the model. The
controlled input of the model is the reflux ratio, u(t).
A load change problem transferring the state of the distillation between two
stationary operating points is considered. The operating points correspond, re-
spectively to reflux ratios of 3.0 and 2.0. This in turn gives stationary values of the
distillate and bottom purities of y1 = 0.96, y32 = 0.099 and y1 = 0.90, y32 = 0.23
respectively. The control objective of the optimal control problem is defined
minu(t)
∫ 50
0α(0.90− y1(t))
2+(2.0−u(t))2dt (17)
where α = 1000 is a constant weight. This objective penalizes deviations from
the target operating point in the distillate vapor composition of component A and
in the reflux ratio. The reflux ratio term is included in the cost function in order
to guarantee a unique solution of the problem. In practice, the target values of
the vapor composition and the reflux ratio are typically computed by a plant-wide
coordinating optimization layer considering economic objectives. In addition, the
reflux ratio is assumed to be constrained in the optimization by 1.0≤ u(t)≤ 5.0.
The dynamics of the system was discretized on a mesh consisting of 50 el-
ements by means of collocation based on cubic Lagrange polynomials, see Sec-
tion 4 for details on the algorithm. The optimal vapor composition profiles are
shown in Figure 7, and the corresponding reflux ratio profile is shown in Fig-
ure 8. As can be seen, the distillate vapor composition converges to the specified
42
0 10 20 30 40 500.890.900.910.920.930.940.950.96
y1
Vapor composition
0 10 20 30 40 500.60950.61000.61050.61100.61150.61200.61250.61300.61350.6140
y17
0 10 20 30 40 50t [s]
0.080.100.120.140.160.180.200.220.24
y32
Figure 7: Optimal vapor composition profiles.
43
0 10 20 30 40 50t [s]
0.8
1.0
1.2
1.4
1.6
1.8
2.0
2.2
u
Reflux ratio
Figure 8: Optimal reflux ratio profile.
44
set-point. The problem was solved on a standard desktop computer in 230s.
6. Summary and conclusions
This paper reports an extension of the Modelica modeling language, entitled
Optimica, targeting dynamic optimization. Optimica extends the Modelica lan-
guage to also include constructs needed when formulating optimization problems,
including specification of optimization interval, the cost function, and the con-
straints.
The Optimica language is supported by the novel Modelica-based open source
project JModelica.org, featuring code generation to C, a C API for evaluation of
model equations and a Python integration. JModelica.org offers an accessible
platform for modeling, optimization and simulation of complex physical systems,
which are often encountered in process control applications. One of the main ob-
jectives of the JModelica.org project is to facilitate technology transfer between
the academic community and industry by providing a platform suitable for exper-
imental algorithm design in an environment where relevant industrial applications
are easily accessible.
The capabilities of Optimica and JModelica.org have been demonstrated by
means of two examples. Firstly, a CSTR system was controlled by an NMPC con-
troller. This example demonstrates the flexibility provided by the Python scripting
environment, where in this case, simulation and optimization tasks were executed
jointly. In a second example, an optimal control problem for a distillation col-
umn was solved. This example demonstrates the ability of JModelica.org to solve
large-scale problems.
Experiences from using Optimica and JModelica.org in a number of projects
45
in different application domains indicate that Modelica/Optimica specifications
are perceived as compact and intuitive. Also, students and engineers with a control
background but lacking expertise in dynamic optimization are typically able to
quickly set up and solve realistic problems. In this respect, the use of Python
serves as a convenient environment for development of prototype applications
involving dynamic optimization.
While the current version of JModelica.org features two particular methods for
solving dynamic optimization problems, one multiple shooting method and one
based on collocation, it is expected that additional algorithms will be interfaced
with the platform. This will further extend the scope of the JModelica.org and
increase its applicability.
Acknowledgements
The authors would like to thank Professor Carl Laird and Gabriel Hackebeil
at Texas A&MUniveristy, Texas, USA, for assistance with the distillation column
example presented in Section 5.2. This work was sponsored by LCCC—Lund
Center for Control of Complex Engineering Systems funded by the Swedish Re-
search Council.
References
[1] The Modelica Association, The Modelica Association Home Page, http:
//www.modelica.org (2007).
[2] Modelon AB, JModelica Home Page, http://www.jmodelica.org
(2009).
46
[3] S. E. Mattsson, M. Andersson, Omola—An object-oriented modelling lan-
guage, in: Colloquium on Open systems: The Way Forward in Computer
Aided Control Engineering, The Institution of Electrical Engineers, London,
UK, 1992.
[4] D. Karnopp, R. Rosenberg, Analysis and simulation of multiport systems—
The bond graph approach to physical system dynamics, MIT Press, Cam-
bridge, MA, USA, 1968.
[5] L. Nagel, D. O. Pederson, Simulation program with integrated circuit em-
phasis (spice), Tech. rep., Electronics Research Laboratory, College of En-
gineering, University of California Berkeley, CA, USA, memorandum ERL-
M382 (1973).
[6] IEEE, Standard vhdl analog and mixed-singnal extensions, Tech. rep., IEEE
(1997).
[7] Process Systems Enterprise, gPROMS Home Page, http://www.
psenterprise.com/gproms/index.html (2007).
[8] MSC Software, ADAMS Home Page, http://www.mscsoftware.com/
products/adams.cfm (2007).
[9] K. J. Åström, H. Elmqvist, S. E. Mattsson, Evolution of continuous-time
modeling and simulation, in: Proceedings of the 12th European Simulation
Multiconference, ESM’98, Society for Computer Simulation International,
Manchester, UK, 1998, pp. 9–18.
[10] P. Fritzson, Principles of Object-Oriented Modeling and Simulation with
Modelica 2.1, John Wiley & Sons, 2004.
47
[11] R. Tarjan, Depth-first search and linear graph algorithms, SIAM J. Comput-
ing 1 (2) (1972) 146–160.
[12] S. E. Mattsson, G. Söderlind, Index reduction in differential-algebraic equa-
tions using dummy derivatives, SIAM Journal of Scientific and Statistical
Computing 14 (3) (1993) 677–692.
[13] Dynasim AB, Dynasim AB Home Page, http://www.dynasim.se (2009).
[14] ITI GmbH, ITI GmbH Home Page, http://www.iti.de/ (2009).
[15] Maplesoft, MapleSim—High-Performance Multi-Domain Modeling and
Simulation, http://www.maplesoft.com/products/maplesim/index.
aspx (2009).
[16] PELAB, The OpenModelica Project, http://www.ida.liu.se/~pelab/
modelica/OpenModelica.html (2009).
[17] R. Bellman, Dynamic Programming, Princeton University Press, Princeton,
N.J., 1957.
[18] D. P. Bertsekas, Dynamic Programming and Optimal Control, vol 1, Athena
Scientific, 2000.
[19] D. P. Bertsekas, Dynamic Programming and Optimal Control, vol 2, Athena
Scientific, 2000.
[20] L. S. Pontryagin, V. G. Boltyanskii, R. V. Gamkrelidze, E. F. Mishchenko,
The Mathematical Theory of Optimal Processes, John Wiley & Sons Inc,
1962.
48
[21] T. Binder, L. Blank, H. Bock, R. Bulirsch, W. Dahmen, M. Diehl, T. Kro-
nseder, W. Marquardt, J. Schlöder, O. v. Stryk, Online Optimization of Large
Scale Systems, Springer-Verlag, Berlin Heidelberg, 2001, Ch. Introduction
to model based optimization of chemical processes on moving horizons, pp.
295–339.
[22] V. Vassiliadis, Computational solution of dynamic optimization problem
with general differnetial-algebraic constraints, Ph.D. thesis, Imerial Collage,
London, UK (1993).
[23] D. Kraft, Algorithm 733: Tmp-fortran modules for optimal control calcula-
tions, ACM Transactions on Mathematical Software 20 (3).
[24] L. Biegler, A. Cervantes, A. Wächter, Advances in simultaneous strategies
for dynamic optimization, Chemical Engineering Science 57 (2002) 575–
593.
[25] J. T. Betts, Practical Methods for Optimal Control Using Nonlinear Program-
ming, Society for Industrial and Applied Mathematics, 2001.
[26] H. Bock, K. J. Plitt, A multiple shooting algorithm for direct solution of
optimal control problems, in: Ninth IFAC world congress, Budapest, 1984.
[27] H. Bock, E. Eich, J. Schlöder, Numerical Treatment of Differential Equa-
tions, Teubner, 1988, Ch. Numerical solution of constrained least squares
boundary value problems in differential-algebraic equations.
[28] M. Diehl, H. Bock, J. Schloder, R. Findeisen, Z. Nagy, F. Allgower, Real-
time optimization and nonlinear model predictive control of processes gov-
49
erned by differential-algebraic equations, Journal of Process Control 12 (4)
(2002) 577–585.
[29] Phoenix Integration, ModelCenter Home Page, http://www.
phoenixint.com/software/phx_modelcenter.php (2009).
[30] OptiY, OptiY Home Page, http://www.optiy.de/ (2009).
[31] ESTECO, modeFRONTIER Home Page, http://www.esteco.com/
(2009).
[32] Dassault Systèmes, iSIGHT Home Page, http://www.simulia.com/
products/isight.html (2009).
[33] Numerica Technolgy, Jacobian, http://www.numericatech.com/
jacobian.htm (2007).
[34] J. A. Clabaugh, ABACUSS II syntax manual, Massachusetts Institute of
Technology, http://yoric.mit.edu/abacuss2/syntax.html (2001).
[35] H. Elmqvist, H. Olsson, S. Mattsson, D. Brück, C. Schweiger, D. Joos,
M. Otter, Optimization for design and parameter estimation, in: In 7th Inter-
national Modelica Conference 2009, Modelica Association, 2005.
[36] OPTEC K.U. Leuven, ACADO Home Page, http://www.acadotoolkit.
org/ (2009).
[37] University of Heidelberg, MUSCOD-II Home Page, http://www.iwr.
uniheidelberg.de/~agbock/RESEARCH/muscod.php (2009).
50
[38] Y. Lang, L. Biegler, A software environment for simultaneous dynamic op-
timization, Computers and Chemical Engineering 31 (8) (2007) 931–942.
[39] A. Wächter, L. T. Biegler, On the implementation of an interior-point filter
line-search algorithm for large-scale nonlinear programming., Mathematical
Programming 106 (1) (2006) 25–58.
[40] P. Barton, C. K. Lee, Modeling, simulation, sensitivity analysis, and opti-
mization of hybrid systems, ACM Transactions on Modeling and Computer
Simulation 12 (4).
[41] C. Nytsch-Geusen, MosiLab Home Page, http://www.mosilab.de/
(2007).
[42] J. Åkesson, Tools and languages for optimization of large-scale systems,
Ph.D. thesis, Department of Automatic Control, Lund University, Sweden
(Nov. 2007).
[43] G. Hedin, E. Magnusson, JastAdd: an aspect-oriented compiler construc-
tion system, Science of Computer Programming 47 (1) (2003) 37–58.
doi:http://dx.doi.org/10.1016/S0167-6423(02)00109-0.
[44] T. Ekman, G. Hedin, E. Magnusson, JastAdd, http://jastadd.cs.lth.se/web/
(2006).
[45] T. Ekman, G. Hedin, Rewritable Reference Attributed Grammars, in: Pro-
ceedings of ECOOP 2004, Vol. 3086 of LNCS, Springer-Verlag, 2004, pp.
144–169.
51
[46] D. E. Knuth, Semantics of context-free languages, Mathematical Systems
Theory 2 (2) (1968) 127–145, correction: Mathematical Systems Theory 5,
1, pp. 95-96 (March 1971).
[47] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W. G. Griswold,
An overview of AspectJ, LNCS 2072 (2001) 327–355.
[48] T. Ekman, G. Hedin, The jastadd extensible java compiler, in: Proceedings
of OOPSLA 2007, 2007.
[49] J. Åkesson, T. Ekman, G. Hedin, Implementation of a modelica com-
piler using jastadd attribute grammars, Science of Computer Programming-
Doi:10.1016/j.scico.2009.07.003.
[50] B. M. Bell, CppAD Home Page, http://www.coinor.org/CppAD/
(2008).
[51] A. Elsheikh, Sensitivity analysis of modelica applications via automatic dif-
ferentiation, in: In 6th International Modelica Conference 2008, Modelica
Association, 2008.
[52] C. Bischof, H. M. Bücker, W. Marquardt, M. Petera, J. Wyes, Automatic
differentiation: applications theory and tools, Springer, 2006, Ch. Trans-
forming equation-based models in process engineering, pp. 189–198.
[53] DLR, Dynasim, ITI and QTronic, The functional model interface, draft.
[54] F. Casella, D. Filippo, J. Åkesson, n XML Representation of DAE Systems
Obtained from Modelica Models, in: In 7th International Modelica Confer-
ence 2009, Modelica Association, 2009.
52
[55] L. von Wedel, CapeML – A model exchange language for chemical process
modeling, Tech. rep., Lehrstuhl für Prozesstechnik, RWTH Aachen Univer-
sity (2002).
[56] P. S. Foundation, Python Programming Language – Official Website, http:
//www.python.org/ (2009).
[57] T. Oliphant, Numpy Home Page, http://numpy.scipy.org/ (2009).
[58] I. Enthought, SciPy, http://www.scipy.org/ (2009).
[59] I. Enthought, IPython FrontPage, http://ipython.scipy.org/moin/
(2009).
[60] J. Hunter, D. Dale, M. Droettboom, matplotlib: python plotting, http://
matplotlib.sourceforge.net/ (2009).
[61] S. Menard, JPype Home Page, http://jpype.sourceforge.net/ (2009).
[62] P. S. Foundation, ctypes: A foreign function library for Python, http://
docs.python.org/library/ctypes.html (2009).
[63] C. f. A. S. C. Lawrence Livermore National Laboratory, SUNDIALS
(SUite of Nonlinear and DIfferential/ALgebraic equation Solvers), https:
//computation.llnl.gov/casc/sundials/main.html (2009).
[64] T.-J. G. f. M. C. P. University of Stellenbosch, PySUNDIALS: Python
SUite of Nonlinear and DIfferential/ALgebraic equation Solvers, http:
//pysundials.sourceforge.net/ (2009).
53
[65] J. Rantil, J. Åkesson, C. Führer, M. Gäfvert, Multiple-ShootingOptimization
using the JModelica.org Platform, in: In 7th International Modelica Confer-
ence 2009, Modelica Association, 2009.
[66] Dmitrey L. Kroshko, OpenOpt Home Page, http://openopt.org/
Welcome (2009).
[67] S. Haugwitz, J. Åkesson, P. Hagander, Dynamic start-up optimization of a
plate reactor with uncertainties, Journal of Process Control 19 (4) (2009)
686–700.
[68] H. Danielsson, Vehicle path optimisation, Master’s Thesis ISRN
LUTFD2/TFRT--5797--SE, Department of Automatic Control, Lund Uni-
versity, Sweden (Jun. 2007).
[69] J. Tuszynskia, M. Persson, J. Åkesson, J. Andreasson, M. Gäfvert, Model-
based approach for design and validation of a novel concept of public mass
transport, in: 21st International Symposium on Dynamics of Vehicles on
Roads and Tracks, 2009, accepted for publication.
[70] M. Hast, J. Åkesson, A. Robertsson, Optimal Robot Control using Modelica
and Optimica, in: In 7th International Modelica Conference 2009, Modelica
Association, 2009.
[71] P. Giselsson, J. Åkesson, A. Robertsson, Optimization of a pendulum system
using optimica and modelica, in: In 7th International Modelica Conference
2009, Modelica Association, 2009.
[72] G. A. Hicks, W. H. Ray, Approximation methods for optimal control synthe-
sis, Can. J. Chem. Eng. 20 (1971) 522 –529.
54
[73] A. Benallou, D. Seborg, D. Mellichamp, Dynamic compartmental models
for separation processes, AIChE Journal 32 (7) (1986) 1067–1078.
[74] J. Hahn, T. Edgar, An improved method for nonlinear model reduction us-
ing balancing of empirical gramians, Computers and Chemical Engineering
26 (10) (2002) 1379–1397.
55