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.).