In this work, DAE Tools modelling, simulation and optimisation software, its programming paradigms and main features are presented. The current approaches to mathematical modelling such as the use of modelling languages and general-purpose programming languages are analysed. The common set of capabilities required by the typical simulation software are discussed, and the shortcomings of the current approaches recognised. A new hybrid approach is introduced, and the modelling languages and the hybrid approach are compared in terms of the grammar, compiler, parser and interpreter requirements, maintainability and portability. The most important characteristics of the new approach are discussed, such as: (1) support for the runtime model generation; (2) support for the runtime simulation set-up; (3) support for complex runtime operating procedures; (4) interoperability with the third party software packages (i.e. NumPy/SciPy); (5) suitability for embedding and use as a web application or software as a service; and (6) code-generation, model exchange and co-simulation capabilities. The benefits of an equation-based approach to modelling, implemented in a fourth generation object-oriented general purpose programming language such as Python are discussed. The architecture and the software implementation details as well as the type of problems that can be solved using DAE Tools software are described. Finally, some applications of the software at different levels of abstraction are presented, and its embedding capabilities and suitability for use as a software as a service is demonstrated.

In general, two main approaches to mathematical modelling currently exist: (a) use of modelling languages, either domain specific or multi-domain such as Modelica (

The most important tasks required to solve a typical simulation or optimisation problem include: the model specification, the simulation setup, the simulation execution, the numerical solution of the system of algebraic/differential equations, and the processing of the results. Each task may require a call or a chained sequence of calls to other software libraries, the methods in those libraries must be available to be called with no significant additional pre-processing and must be able to operate on shared/common data structures. All of these require a two-way interoperability between the software and third-party libraries. Also, the model structure is often not fully defined beforehand and a runtime generation of models (“on-the-fly”) using the results from other software is required. Frequently, simulations can not be limited to a straightforward, step-wise integration in time but the custom user-defined operating procedures are required, which can be performed only using the fully-featured programming languages. In addition, it is often desired to compare/benchmark the simulation results between different simulators. This requires the code-generation and the model-exchange capabilities to automatically generate the source code for the target language or export the model definition to a specified (often simulator-independent) model specification language. Exposing the functionality of the developed models to another simulator through a predefined standard interface such as the CAPE-OPEN (

A modelling language implemented as a single monolithic software package can rarely deliver all capabilities required. For instance, the Modelica modelling language allows calls to “C” functions from external shared libraries but with some additional pre-processing. Simple operating procedures are supported directly by the language but they must be embedded into a model, rather than separated into an independent section or function. gPROMS also allows very simple operating procedures to be defined as tasks (only in simulation mode), and user-defined output channels for custom processing of the results. The runtime model generation and complex operating procedures are not supported. Invocation from other software is either not possible or requires an additional application layer. On the other hand, Python, MATLAB and the software suites such as PETSc have an access to an immense number of scientific software libraries, support runtime model generation, completely flexible operating procedures and processing of the results. However, the procedural nature and lack of object-oriented features in MATLAB and absence of fundamental modelling concepts in all three types of environments make development of complex models or model hierarchies difficult.

In this work, a new approach has been proposed and implemented in DAE Tools software which offers some of the key advantages of the modelling languages coupled with the power and flexibility of the general-purpose languages. It is a type of hybrid approach–it is implemented using the general-purpose programming languages such as C++ and Python, but provides the Application Programming Interface (API) that resembles a syntax of modelling languages as much as possible and takes advantage of the higher level general purpose languages to offer an access to the operating system, low-level functions and large number of numerical libraries to solve various numerical problems. To illustrate the new concept, the comparison between Modelica and gPROMS grammar and DAE Tools API for a very simple dynamical model is given in the

model BufferTank
// Import libs
import Modelica.Math.*;
parameter Real Density;
parameter Real CrossSectionalArea;
parameter Real Alpha;
Real HoldUp(start = 0.0);
Real FlowIn;
Real FlowOut;
Real Height;
equation
// Mass balance
der (HoldUp) = FlowIn − FlowOut;
// Relation between liquid level and holdup
HoldUp = CrossSectionalArea * Height * Density;
// Outlet flowrate as a function of the liquid level
FlowOut = Alpha * sqrt(Height);
end BufferTank;

PARAMETER
Density AS Real
CrossSectionalArea AS Real
Alpha AS Real
VARIABLE
HoldUp AS Mass
FlowIn AS Flowrate
FlowOut AS Flowrate
Height AS Length
EQUATION
# Mass balance
$HoldUp = FlowIn − FlowOut;
# Relation between liquid level and holdup
HoldUp = CrossSectionalArea * Height * Density;
# Outlet flowrate as a function of the liquid level
FlowOut = Alpha * sqrt(Height);

class BufferTank(daeModel):
def __init__(self, Name, Parent = None, Description = "" ):
daeModel.__init__(self, Name, Parent, Description)
self.Density = daeParameter("Density" , kg/m**3, self)
self.Area = daeParameter("Area" , m**2, self)
self.Alpha = daeParameter("Alpha" , unit(), self)
self.HoldUp = daeVariable("HoldUp" , mass_t, self)
self.FlowIn = daeVariable("FlowIn" , flowrate_t, self)
self.FlowOut = daeVariable("FlowOut" , flowrate_t, self)
self.Height = daeVariable("Height" , length_t, self)
def DeclareEquations(self):
# Mass balance
eq = self.CreateEquation("MassBalance" )
eq.Residual = self.HoldUp.dt() − self.FlowIn() + self.FlowOut()
# Relation between liquid level and holdup
eq = self.CreateEquation("LiquidLevelHoldup" )
eq.Residual = self.HoldUp() − self.Area() * self.Height() * self.Density()
# Outlet flowrate as a function of the liquid level
eq = self.CreateEquation("OutletFlowrate" )
eq.Residual = self.FlowOut() − self.Alpha() * Sqrt(self.Height())

The article is organised in the following way. First, the DAE Tools programming paradigms and the main features are introduced and discussed. Next, its architecture and the software implementation details are analysed. After that, the algorithm for the solution of DAE systems is presented and some basic information on how to develop models in DAE Tools given. Then, two applications of the software are demonstrated: (a) multi-scale modelling of phase-separating electrodes, and (b) a reference implementation simulator for a new domain specific language. Finally, a summary of the most important characteristics of the software is given in the last section.

DAE Tools is free software released under the GNU General Public Licence. The source code, the installation packages and more information about the software can be found on the website (

Broadly speaking, DAE Tools is not a modelling language (such as Modelica and gPROMS) nor an integrated software suite of data structures and routines for scientific applications (such as PETSc), but rather a higher level structure–an architectural design of interdependent software components providing an API for: (a) model development/specification, (b) activities on developed models such as simulation, optimisation and parameter estimation, (c) processing of the results, (d) report generation, and (e) code generation and model exchange. However, it can easily be integrated into a software suite with the Graphical User Interface (GUI), embedded into another software or even run as a web service on the server (as it was demonstrated in the section

Regarding the available modelling techniques, three approaches currently exist (

The hybrid approach allows an easy interaction with other software packages/libraries. First, other numerical libraries can be accessed directly from the code, and since the Python’s design allows an easy development of extension modules from different languages, a vast number of numerical libraries is readily available. Second, DAE Tools are developed with a built-in support for NumPy (

The automatic differentiation is always utilised to analytically generate the Jacobian matrix if the direct sparse linear solvers are used, or to generate a preconditioner matrix for the iterative linear solvers using the software suites such as Trilinos AztecOO, IFPACK, and ML. The automatic differentiation is also applied to sensitivity analysis where it is used to calculate derivatives of model equations per parameters with respect to which sensitivities are requested. Only the continuous-time systems are supported and the forward sensitivity method provided by the Sundials IDAS solver is available at the moment. The forward sensitivity equations are integrated together with the original DAE system leading to the DAE system of size _{s}_{s} is the number of model parameters. More information about the sensitivity analysis using the forward sensitivity method can be found in the Sundials documentation.

DAE Tools also provide code generators and co-simulation/model exchange standards/interfaces for other simulators. This way, the developed models can be simulated in other simulators either by generating the source code, exporting a model specification file or through some of the standard co-simulation interfaces. To date, the source code generators for c99, Modelica and gPROMS languages have been developed. In addition, DAE Tools functionality can be exposed to MATLAB, Scilab and GNU Octave via MEX-functions, to Simulink via user-defined S-functions and to the simulators that support FMI co-simulation capabilities. The future work will concentrate on support for the additional interfaces (i.e. CAPE-OPEN) and development of additional code generators.

Parallel computation is supported using only the shared-memory parallel programming model at the moment. Since a repeated solution of the system of linear equations typically requires around 90–95% of the total simulation time, the linear equations solver represents the major bottleneck in the simulation. Therefore, the main focus was put on performance improvement of the solution of linear equations using one of the available multi-threaded solvers such as SuperLU_MT, Pardiso and Intel Pardiso.

DAE Tools consists of six packages:

This package contains the key modelling concepts. The class diagram with interfaces (abstract classes) is presented in

Concept | Description |
---|---|

Defines a variable type that has the units, lower and upper bounds, a default value and an absolute tolerance | |

Defines ordinary arrays or spatial distributions such as structured and unstructured grids; parameters, variables, equations and even models and ports can be distributed on domains | |

Defines time invariant quantities that do not change during a simulation, such as a physical constant, number of discretisation points in a domain etc. | |

Defines time varying quantities that change during a simulation | |

Defines connection points between model instances for exchange of continuous quantities; similar to the models, ports can contain domains, parameters and variables | |

Defines connection points between model instances for exchange of discrete messages/events; events can be triggered manually or when a specified condition is satisfied; the main difference between event and ordinary ports is that the former allow a discrete communication between models while latter allow a continuous exchange of information | |

Defines connections between two ports | |

Defines connections between two event ports | |

Defines model equations given in an implicit/acausal form | |

Defines state transition networks used to model discontinuous equations, that is equations that take different forms subject to certain conditions; symmetrical/non-symmetrical and reversible/irreversible state transitions are supported | |

Defines actions to be performed when a specified condition is satisfied | |

Defines actions to be performed when an event is triggered on the specified event port | |

Defines a state in a state transition network; contains equations and on_event/condition action handlers | |

Represents a model |

This package contains interfaces that define an API for activities that can be performed on developed models. To date, only two interfaces are defined and implemented:

This package contains interfaces that define an API for numerical solution of systems of Differential Algebraic Equations (DAE), systems of Linear Equations (LA), and (mixed-integer) nonlinear programming problems (NLP or MINLP), and auxiliary classes. The class diagram with the defined interfaces is presented in

This package contains interfaces that define an API for processing of simulation results by the

This package contains only one interface

Parameters and variables in DAE Tools have a numerical value in terms of a unit of measurement (quantity) and units-consistency of equations and logical conditions is strictly enforced (although it can be switched off, if required). The package contains only two classes:

The solution of a DAE system requires the functionality provided by the following objects: (a) simulation object implementing the

DAE Tools simulation/optimisation.

DAE Tools simulation.

A sequence of calls during the initialisation in

A sequence of calls during the calculation of initial conditions in

A sequence of calls during the integration of the system in

This phase includes a call to

In DAE Tools, models are developed by deriving new classes from the base model class (_{p}_{in}_{surr}

from daetools.pyDAE import *
from pyUnits import m, kg, s, K, Pa, J, W
# Part 1: creating a model
class CopperBlock(daeModel):
def __init__(self, Name, Parent = None, Description = "" ):
daeModel.__init__(self, Name, Parent, Description)
self.m = daeParameter("m" , kg, self, "Mass of the copper block" )
self.cp = daeParameter("c_p" , J/(kg*K), self, "Specific heat capacity" )
self.alpha = daeParameter("α" , W/((m**2)*K), self, "Heat transfer coefficient" )
self.A = daeParameter("A" , m**2, self, "Surface area for the heat transfer" )
self.Tsurr = daeParameter("T_surr" , K, self, "Temperature of the surroundings" )
self.Qin = daeVariable("Q_in" , power_t, self, "Power of the heater" )
self.T = daeVariable("T" , temperature_t, self, "Block temperature" )
def DeclareEquations(self):
daeModel.DeclareEquations(self)
eq = self.CreateEquation("HeatBalance" , "Integral heat balance equation" )
eq.Residual = self.m() * self.cp() * self.T.dt() − self.Qin() + \
self.alpha() * self.A() * (self.T() − self.Tsurr())

Definition of a simulation in DAE Tools requires the following steps: (a) deriving a new class from the base simulation

# Part 2: setting up a simulation
class simCopperBlock(daeSimulation):
def __init__(self):
daeSimulation.__init__(self)
self.m = CopperBlock("CopperBlock" )
def SetUpParametersAndDomains(self):
self.m.cp.SetValue(385 * J/(kg*K))
self.m.m.SetValue(1 * kg)
self.m.alpha.SetValue(200 * W/((m**2)*K))
self.m.A.SetValue(0.1 * m**2)
self.m.Tsurr.SetValue(283 * K)
def SetUpVariables(self):
# Set input power of the heater
# It is a degree of freedom (DOF) and must be assigned
self.m.Qin.AssignValue(1500 * W)
# Set an initial condtion for the temperature
self.m.T.SetInitialCondition(283 * K)

Running a simulation requires the following steps: (a) instantiation of DAE and LA solvers, data reporter, data receiver, and log objects; (b) setting a time horizon and a reporting interval; (c) initialisation of the simulation; (d) calculation of the initial conditions; (e) running simulation; and (f) cleaning up. The simulation performed in Python is given in the

# Part 3: running a simulation
# Create Log, Solver, DataReporter and Simulation object
log = daePythonStdOutLog()
daesolver = daeIDAS()
datareporter = daeTCPIPDataReporter()
simulation = simCopperBlock()
# Enable reporting of all variables
simulation.m.SetReportingOn(True)
# Set the time horizon and the reporting interval
simulation.ReportingInterval = 10
simulation.TimeHorizon = 500
# Connect the TCP/IP data reporter (the default address is "localhost:50000")
datareporter.Connect("" , "CopperBlock" )
# Initialize the simulation
simulation.Initialize(daesolver, datareporter, log)
# Solve the system at time = 0
simulation.SolveInitial()
# Run the simulation
simulation.Run()
# Clean-up
simulation.Finalize()

The previous example was very simple. DAE Tools also support some advanced features such as discontinuous equations and state transition networks. More information about state transition networks and their types can be found in

class CopperBlock(daeModel):
…
def DeclareEquations(self):
…
self.IF(Time() < Constant(200*s))
eq = self.CreateEquation("Q_on" , "The heater is on" )
eq.Residual = self.Qin() − Constant(1500 * W)
self.ELSE()
eq = self.CreateEquation("Q_off" , "The heater is off" )
eq.Residual = self.Qin()
self.END_IF()

Another commonly used type of state transition networks is a non-symmetrical STN. This type of STN in DAE Tools can be created by using

class CopperBlock(daeModel):
…
def DeclareEquations(self):
…
self.stnRegulator = self.STN("Regulator" )
self.STATE("HeaterOn" )
eq = self.CreateEquation("HeaterInput" )
eq.Residual = self.Qin() − Constant(1500 * W)
self.ON_CONDITION(self.T() > Constant(340*K),
switchToStates = [ ('Regulator' , 'HeaterOff' ) ] )
self.ON_CONDITION(Time() > Constant(350*s),
switchToStates = [ ('Regulator' , 'RegulatorOff' ) ] )
self.STATE("HeaterOff" )
eq = self.CreateEquation("HeaterInput" )
eq.Residual = self.Qin()
self.ON_CONDITION(self.T() < Constant(320*K),
switchToStates = [ ('Regulator' , 'HeaterOn' ) ])
self.ON_CONDITION(Time() > Constant(350*s),
switchToStates = [ ('Regulator' , 'RegulatorOff ') ] )
self.STATE("RegulatorOff" )
eq = self.CreateEquation("HeaterInput" )
eq.Residual = self.Qin()
self.END_STN()

To date, DAE Tools have been applied to several diverse scientific areas such as gas adsorption, porous membranes, crystallisation, electrochemistry and biological neural networks. Two projects utilising DAE Tools software at different levels of abstraction are presented in this work. The first example illustrates applicability of DAE Tools to development of multi-scale models. In this example, the authors took advantage of the built-in interoperability with Python NumPy library to perform vector operations on NumPy arrays to form the DAE system. The second example illustrates two important DAE Tools capabilities: (a) embedding into another software (a domain specific language simulator) running on a server and providing its functionality through a web service or web application, and (b) defining the modelling concepts from a new application domain using the DAE Tools fundamental modelling concepts.

In the work of _{4} can be found in

The resulting discretised set of equations is a large system of DAE’s. Differential equations come from the discretised transport equations, and algebraic constraints arise from electrostatic equations and constraints on the total integrated reaction rate (current). In ^{−3} in MATLAB and 10^{−5} in DAE Tools), a number of simulations were carried out using both the MATLAB implementation and the DAE Tools implementation, and in each case the simulation outputs were indistinguishable. Despite obtaining equivalent outputs, the implementation using DAE Tools consistently ran more quickly (

DAE Tools software has been used as a reference implementation simulator for the “Network Interchange format for NEuroscience” (NineML) Modelling Language. NineML is an open source xml-based domain specific language for modelling of networks of spiking neurones. It is a simulator-independent language with the aim of providing an unambiguous description of neuronal network models for efficient model sharing and reusability between different simulators (such as NEURON, NEST, NeuroML/LEMS etc.). The language has emerged from a joint effort of experts in the fields of computational neuroscience, simulator development and simulator-independent language initiatives (NeuroML, PyNN), grouped in the INCF Multiscale Modelling Task Force (

The purpose of the application is validation and testing of abstraction layer components and generation of model reports (as a help to components developers). The application is available in three flavours: (a) desktop application with the pyQt graphical user interface; (b) web application with the jQuery user interface; and (c) web service with the REpresentational State Transfer (REST) API. The latter two were implemented using the Web Service Gateway Interface (WSGI) running under Apache HTTP Debian GNU/Linux server with the mod_python server module. The application inputs are: the AL component, one or more tests (optional), parameters values, initial conditions and inputs to the analogue and event ports. The application produces the model report (in PDF or html format) and tests results (variable plots). The role of DAE Tools software is to process NineML xml input files, generate the model structure using the lib9ml library, execute the server-side simulations, produce reports and deliver them to the clients.

The NineML reference implementation simulator represents a small scale simulator for testing and validating purposes, with the full support for the NineML language. All input information are given in a simulator-independent format: NineML xml files (mathematical models) and SED-ML xml file (simulation settings). SED-ML is the Simulation Experiment Description Markup Language an xml-based format for encoding simulation experiments (

DAE Tools modelling, simulation and optimisation software, its programming paradigms, the main features and capabilities have been presented in this work. Some shortcomings of the current approaches to mathematical modelling have been recognised and analysed, and a new hybrid approach proposed. The hybrid approach offers some of the key advantages of modelling languages paired with the flexibility of the general purpose languages. Its benefits have been discussed such as the support for the runtime model generation, runtime simulation set-up and complex runtime operating procedures, interoperability with the third party software packages, and embedding and code-generation capabilities. The software architecture and the procedure for transformation of the model hierarchy into a DAE system as well as the algorithm for the solution of the DAE system have been presented. The most important modelling concepts available in the DAE Tools API required for model development and simulation execution have been outlined.

The software has successfully been applied to two different scientific problems. In the first example, the authors took advantage of the object-oriented characteristics of the software and the interoperability with the NumPy library for the development of a model hierarchy to mathematically describe operation of lithium-ion batteries at different physical scales. In the second example, the DAE Tools software has been used as a reference implementation simulator for the new XML-based domain specific language (NineML). DAE Tools embedding capabilities have been utilised to provide a simulator available in three versions: (a) desktop application, (b) web application and (c) web service.

The current work concentrates on a further support for systems with distributed parameters (i.e. high-resolution finite volume schemes with flux limiters), the additional optimisation algorithms and the parallel computation using the general purpose graphics processing units and systems with the distributed memory. The parallel computation will rely on the code generation capabilities to produce the C source code for the DAE/ODE solvers that support the MPI interface such as PETSc and Sundials IDAS/PVODE, including the data partitioning and the routines for the inter-process communication of data.

The case study

Dragan Nikolić is an employee of DAE Tools Project, Belgrade, Serbia.

The following information was supplied regarding data availability: