3. Architecture

DAE Tools consists of six packages: core, activity, solvers, datareporting, logging, and units. All packages provide a set of interfaces (abstract classes) that define the required functionality. Interfaces are realised by the implementation classes. The implementation classes share the same name with the interface they realise with the suffix _t dropped (i.e. the class daeVariable implements interface daeVariable_t).

3.1. Package “core”

This package contains the key modelling concepts. The class diagram with interfaces (abstract classes) and their interdepedency is presented in Fig. 3.1. The key modelling concepts in DAE Tools are given in Table 3.1. Interface realisations are given in Fig. 3.2.


Fig. 3.1 UML class diagram: the core package interfaces

Table 3.1 The key modelling concepts in DAE Tools
Concept Implementation class Description
daeVariableType_t daeVariableType Defines a variable type that has the units, lower and upper bounds, a default value and an absolute tolerance
daeDomain_t daeDomain 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
daeParameter_t daeParameter Defines time invariant quantities that do not change during a simulation, such as a physical constant, number of discretisation points in a domain etc.
daeVariable_t daeVariable Defines time varying quantities that change during a simulation
daePort_t daePort Defines connection points between model instances for exchange of continuous quantities; similar to the models, ports can contain domains, parameters and variables
daeEventPort_t daeEventPort 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
daePortConnection_t daePortConnection Defines connections between two ports
daeEventPortConnection_t daeEventPortConnection Defines connections between two event ports
daeEquation_t daeEquation Defines model equations given in an implicit/acausal form
daeSTN_t daeSTN, daeIF 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
daeOnConditionActions_t daeOnConditionActions Defines actions to be performed when a specified condition is satisfied
daeOnEventActions_t daeOnEventActions Defines actions to be performed when an event is triggered on the specified event port
daeState_t daeState Defines a state in a state transition network; contains equations and on_event/condition action handlers
daeModel_t daeModel Represents a model

Fig. 3.2 UML class diagram: the core package interface implementations

Models in DAE Tools are represented by the daeModel class and contain the following elements: domains, parameters, variables, equations, state transition networks, ports, event ports, actions to be performed when a given condition is satisfied, actions to be performed when an event is triggered on a given event port, and components (instances of other models, used to form a hierarchy of models). The daeModel UML class diagram is presented in Fig. 3.3.


Fig. 3.3 UML class diagram: daeModel class

3.2. Package “activity”

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: daeSimulation_t (defines a functionality used to perfom simulations) and daeOptimization_t (defines a functionality used to perform optimisations).

3.3. Package “solvers”

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 Fig. 3.4.


Fig. 3.4 UML class diagram: the solvers package interfaces

Table 3.2 The key concepts in the solvers pakage
Concept Description
daeDAESolver_t Defines a functionality for the solution of DAE systems
daeNLPSolver_t Defines a functionality for the solution of (MI)NLP problems
daeLASolver_t Defines functionality for the solution of systems of linear equations
daeIDALASolver_t Derived from daeLASolver_t, used by Sundials IDAS linear solvers

Interface realizations are given in Fig. 3.5. Current implementations include Sundials IDAS DAE solver, IPOPT, BONMIN and NLOPT (MI)NLP solvers and SuperLU, SuperLU_MT, PARDISO, Intel PARDISO and Trilinos (Amesos and AztecOO) sparse matrix linear solvers. Since all these linear equation solvers use different sparse matrix representations, a generic interface (template daeMatrix<typename FLOAT>) has been developed for the basic operations performed by DAE Tools software such as setting/getting the values and obtaining the matrix properties. This way, DAE Tools objects can access the matrix data in a generic fashion while hiding the internal implementation details. To date, three matrix types have been implemented: daeDenseMatrix, daeLapackMatrix (basically wrappers around C/C++ and Fortran two-dimensional arrays), a template class daeSparseMatrix<typename FLOAT, typename INT> (sparse matrix) and its realization daeCSRMatrix<typename FLOAT, typename INT> implementing the compressed row storage (CSR) sparse matrix representation.


Fig. 3.5 UML class diagram: the solvers package interface implementations

3.4. Package “datareporting”

This package contains interfaces that define an API for processing of simulation results by the daeSimulation_t and daeDAESolver_t classes, and the data structures available to access those data by the users. Two interfaces are defined: daeDataReporter_t (defines a functionality used by a simulation object to report the simulation results) and daeDataReceiver_t (defines a functionality/data structures for accessing the simulation results). A number of data reporters have been developed for: (a) sending the results via TCP/IP protocol to the DAE Tools Plotter application (daeTCPIPDataReporter), (b) plotting the results using the Matplotlib Python library (daePlotDataReporter), and (c) exporting the results to various file formats (such as Matlab MAT, Microsoft Excel, html, xml, json and HDF5). An overview of the implemented classes is given in Fig. 3.6.


Fig. 3.6 UML class diagram: the datareporting package interface implementations

3.5. Package “logging”

This package contains only one interface daeLog_t that define an API for sending messages from the simulation to the user. Interface realizations are given in Fig. 3.7. Three implementations exist: daeStdOutLog (prints messages to the standard output), daeFileLog (stores messages to the specified text file), and daeTCPIPLog (sends messages via TCP/IP protocol to the daeTCPIPLogServer; used when a simulation is running on a remote computer).


Fig. 3.7 UML class diagram: the logging interface implementations

3.6. Package “units”

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: unit and quantity. Both classes have overloaded operators +, -, *, / and ** to support creation of derived units and operations on quantities that contain a numerical value and units. In addition, the package defines the basic mathematical functions that operate on quantity objects (such as sin, cos, tan, sqrt, pow, log, log10, exp, min, max, floor, ceil, abs etc.).