2. Programming Paradigms

2.1. The Hybrid approach

In general, two main approaches to mathematical modelling currently exist: (a) use of modelling languages, either domain specific or multi-domain such as Modelica, Ascend, gPROMS, GAMS, Dymola, APMonitor, and (b) use of general-purpose programming languages, either lower level third-generation languages such as C, C++ and Fortran (i.e. PETSc and SUNDIALS), or higher level fourth-generation languages such as Python (i.e. Assimulo) and multi-paradigm numerical languages: Matlab, Mathematica, Maple, Scilab, and GNU Octave. Domain Specific Languages (DSL) are a special-purpose programming or specification languages dedicated to a particular problem domain and directly support the key concepts necessary to describe the underlying problems. They are created specifically to solve problems in a particular domain and usually not intended to be able to solve problems outside it (although that may be technically possible in some cases). More versatile, multi-domain modelling languages (such as Modelica or gPROMS) are capable of solving problems in different application domains. Despite their versatility, modelling languages commonly lack or have a limited access to the operating system, third-party numerical libraries and other capabilities that characterise full-featured programming languages, scripting or otherwise. In contrast, general-purpose languages are created to solve problems in a wide variety of application domains, do not support concepts from any domain, and have a direct access to the operating system, low-level functions and third-party libraries.

DAE Tools approach is a type of a 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 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 (i.e. calculating derivatives and sensitivities, solving linear and DAE systems and optimisation problems)

API comparison between Modelica, gPROMS and DAE Tools for a very simple dynamical model (basically a tank with a liquid inside, an inlet and an outlet flow where the outlet flowrate depends on the liquid level in the tank):

a) Modelica	b) gPROMS	c) DAE Tools

DAE Tools provide the low-level modelling concepts such as parameters, variables, equations, ports, models, state transition networks, discrete events etc. so that the key concepts from new application domains can be added on top of those low level concepts. For instance, the key modelling concepts from the simulator-independent xml-based domain specific language for modelling of biological neural networks NineML such as neurones, synapses, connectivity patterns, populations of neurones, projections etc. are based on DAE Tools low-level concepts.

Side-by-side comparison between the DSL approach and the DAE Tools hybrid approach:

DSL Approach	DAE Tools Approach
Domain-specific languages allow solutions to be expressed in the idiom and at the level of abstraction of the problem domain (direct support for all modelling concepts by the language syntax)	Modelling concepts cannot be expressed directly in the programming language and have to be emulated in the API or in some other way
Clean, concise, ellegant and natural way of building model descriptions: the code can be self documenting	The support for modelling concepts is much more verbose and less elegant; however, DAE Tools can generate XML+MathML based model reports that can be either rendered in XHTML format using XSLT transformations (representing the code documentation) or used as an XML-based model exchange language.
Domain-specific languages could enhance quality, productivity, reliability, maintainability and portability
DSLs could be and often are simulator independent making a model exchange easier	Programming language dependent; however, a large number of scientific software libraries exposes its functionality to Python via Python wrappers
Cost of designing, implementing, and maintaining a domain-specific language as well as the tools required to develop with it (IDE): a compiler/lexical parser/interpreter must be developed with all burden that comes with it (such as error handling, grammar ambiguities, hidden bugs etc)	A compiler/lexical parser/interpreter is an integral part of the programming language (c++, Python) with a robust error handling, universal grammar and massively tested
Cost of learning a new language vs. its limited applicability: users are required to master a new language (yet another language grammar)	No learning of a new language required (everything done in a favourite programming language)
Increased difficulty of integrating the DSL with other components: calling external functions/libraries and interaction with other software is limited by the existence of wrappers around a simulator engine (for instance some scripting languages like Python or javascript)	Calling external functions/libraries and interaction with other software is a built-in feature
Models usually cannot be created in the runtime/on the fly (or at least not easily) and cannot be modified in the runtime	Models can be created in the runtime/on the fly and easily modified in the runtime
Setting up a simulation (ie. the values of parameters values, initial conditions, initially active states) is embedded in the language and it is typically difficult to do it on the fly or to obtain the values from some other software (for example to chain several software calls where outputs of previous calls represent inputs to the subsequent ones)	Setting up a simulation is done programmaticaly and the initial values can be obtained from some other software (chaining several software calls is easy since a large number of libraries make Python wrappers available)
Schedules (operating procedures) are not flexible; manipulation of model parameters, variables, equations, simulation results etc is limited to only those operations provided by the language	Schedules are completely flexible (within the limits of a programming language itself) and a manipulation of model parameters, variables, equations, simulation results etc can be done in any way which a user considers suitable for her problem
Only the type of results provided by the language/simulator is available; custom processing is usually not possible or if a simulator does provide a way to build extensions it is limited to the functionality made available to them	The results processing can be done in any way which a user considers suitable(again within the limits of a programming language itself)

2.2. The Equation-Oriented approach

In general, three approaches to process modelling exist ([1]):

• Sequential Modular (SeqM) approach

• Simultaneous Modular (SimM) approach

• Equation-Oriented (EO) approach

The pros & cons of the first two approaches are extensively studied in the literature. Under the EO approach all equations and variables which constitute the model representing the process are gathered together. The equations are solved simultaneously using a suitable mathematical algorithm (Morton, 2003 [1]). Equation-oriented simulation requires simultaneous solution of a set of differential algebraic equations (DAE) which itself requires a solution of a set of nonlinear algebraic equations (NLAE) and linear algebraic equations (LAE). The Newton’s method or some variant of it is almost always used to solve problems described by NLAEs. A brief history of Equation-Oriented solvers and comparison of SeqM and EO approaches as well as descriptions of the simultaneous modular and equation-oriented methods can be found in Morton, 2003 ([1]). Also a good overview of the equation-oriented approach and its application in gPROMS is given by Barton & Pantelides ([2] [3] [4]).

DAE Tools apply the Equation-Oriented approach to process modelling. The following types of processes can be modelled:

• Lumped and distributed

• Steady-state and dynamic

Problems can be formulated as linear, non-linear, and (partial) differential algebraic systems (of index 1). The most common problems are initial value problems of implicit form. Equations can be ordinary or discontinuous, where discontinuities are automatically handled by the framework. A good overview of discontinuous equations and a procedure for location of equation discontinuities is given by Park & Barton ([5]) and in Sundials IDA (used in DAE Tools).

The main characteristics of the Equation-oriented (acausal) approach:

• Equations are given in an implicit form (as a residual):

  \[F(\dot {x}, x, y, p) = 0\]

  where \(x\) and \(\dot {x}\) are state variables and their derivatives, \(y\) are degrees of freedom and \(p\) are parameters.

• Input-Output causality is not fixed

  The benefits are:

  • Increased model re-use

  • Support for different simulation scenarios (based on a single model) by specifying different degrees of freedom. For instance, an equation given in the following form:

    \[x_1 + x_2 + x_3 = 0\]

    can be used to determine either x1, x2 or x3 depending on what combination of variables is known:

    \[ \begin{align}\begin{aligned}x_1 = -x_2 - x_3 \newline\\\vee \newline\\x_2 = -x_1 - x_3 \newline\\\vee \newline\\x_3 = -x_1 - x_2\end{aligned}\end{align} \]

Footnotes

[1] (1,2,3)

Morton, W., Equation-Oriented Simulation and Optimization. Proc. Indian Natl. Sci. Acad. 2003, 317-357.

[2]

Pantelides, C. C., and P. I. Barton, Equation-oriented dynamic simulation current status and future perspectives, Computers & Chemical Engineering, vol. 17, no. Supplement 1, pp. 263 - 285, 1993.

[3]

Barton, P. I., and C. C. Pantelides, gPROMS - a Combined Discrete/Continuous Modelling Environment for Chemical Processing Systems, Simulation Series, vol. 25, no. 3, pp. 25-34, 1993.

[4]

Barton, P. I., and C. C. Pantelides, Modeling of combined discrete/continuous processes”, AIChE Journal, vol. 40, pp. 966-979, 1994.

[5]

Park, T., and P. I. Barton, State event location in differential-algebraic models”, ACM Transactions on Modeling and Computer Simulation, vol. 6, no. 2, New York, NY, USA, ACM, pp. 137-165, 1996.

2.3. The Object-Oriented approach

The Object-Oriented approach to process modelling is adopted in DAE Tools. The main characteristics of such an approach are:

• Everything is an object

• Models are classes derived from the base daeModel class

• Basically all OO concepts supported by the target language (c++, Python) are allowed, except few exceptions

  • Multiple inheritance is supported

  • Models can be parametrized (using templates in c++)

  • Derived classes always inherit all declared parameters, variables, equations etc. (polymorphism achieved through virtual functions where the declaration takes place)

  • All parameters, variables, equations etc. remain public

• Hierarchical model decomposition

2.4. Programming language

DAE Tools core libraries are written in standard c++. However, Python programming language is used as the main modelling language.

An excellent overview of Python is given by Hoyt Koepke (University of Washington): 10 Reasons Python Rocks for Research.

The main reason for use of Python is (as the authors say): “Python is an easy to learn, powerful programming language. It has efficient high-level data structures and a simple but effective approach to object-oriented programming. Python’s elegant syntax and dynamic typing, together with its interpreted nature, make it an ideal language for scripting and rapid application development in many areas on most platforms” link.

And: “Often, programmers fall in love with Python because of the increased productivity it provides. Since there is no compilation step, the edit-test-debug cycle is incredibly fast” link. Also, please have a look on a comparison to the other languages. Based on the information available online, and according to the personal experience, the python programs are much shorter and take an order of magnitude less time to develop it. Initially I developed daePlotter module in c++; it took me about one month of part time coding. But, then I moved to python: reimplementing it in PyQt took me just two days (with several new features added), while the code size shrank from 24 cpp modules to four python modules only!

“Where Python code is typically 3-5 times shorter than equivalent Java code, it is often 5-10 times shorter than equivalent C++ code! Anecdotal evidence suggests that one Python programmer can finish in two months what two C++ programmers can’t complete in a year. Python shines as a glue language, used to combine components written in C++” link.

Obviously, not everything can be developed in python; a heavy c++ artillery is still necessary for highly complex projects.