v2.0.9

In order of implementation, here are the list of additions in v2.0.9

• More unit tests for C++ API using conventional Googletest

• More unit tests for Python API using conventional unittests module

• Added developers documentation

• Refactoring of IntegratorFactory and SteadyStateSolverFactory. Their logic is identical and so there is no need for duplicated code. The logic was refactored into a superclass RegistrationFactory and Integrator/SteadyStateSolver Factories now derive from them. SensitivitySolverFactory was added in a similar fashion.

• Removal of the "Registrar" system. Until now each Solver class needed a side class classed SolverRegistrar. They all do the same thing. This is not only requires twice as many classes but also required static and non-static version of the same methods in the Solver classes. The problem was resolved by introducing a Registrable interface which is a superclass of Solver. The registration system is the same, but the implementation is more elegant (extendable, maintainable etc.). Furthermore, there used to be a manager SolverFactoryMgr class. This was found to be superfluous (and abuse of abstraction/encapsulation concepts of OOP) - the job of constructing instances of Solver objects has been transferred to the RegistrationFactorys themselves.

• Implemented a rr::Matrix<T> template type, which is derived from the ls::Matrix type. The issue is that roadrunners main data type for results is a type from rr-libstruct in the dependencies package. However, we need to be able to maintain/extend/tweak this type. Instead of moving rr-libstruct from the dependencies package, this release implements a type rr:Matrix<T> that derives from ls::Matrix<T> and extends it to include operations such as comparison operators (operator== and operator!=) as well as an almostEquals for floating point comparisons and sorting rows/columns by row and column names.

• Implemented a rr::Matrix3D<IndexType, DataType> type. This was mainly implemented for storing results of a time series sensitivity analysis, which is a 3D matrix, but has been generalized so that any data type can be stored and any data type can be used as an index. Since time series sensitivities requires rr::Matrix3D<double, double>, this is the main data type that the Matrix3D has been tested with at this time. The IndexType is used to store time whereas the DataType is used to store sensitivity data at each time point.

• Bugfix in CVODEIntegrator where initial concentrations were always 0 and not updated inside CVODEIntegrator but instead by the RoadRunner class. This caused a bug whereby the CVODEIntegrator could not be used as a stand alone class.

• Implemented a new set of interfaces for SensitivitySolver that derives from Solver and distinguishes between TimeSeriesSensitivitySolver and SteadyStateSensitivitySolver. The main difference between these interfaces is that the return types of the main solve methods are either 3D or 2D matrices respectively. Note - SteadyStateSensitivitySolver is just a stub to be implemented in a future version.

• Implemented a ForwardSensitivitySolver class that implements the TimeSeriesSensitivitySolver interface. This class uses sundials cvodes for both integrating the model and for solving the sensitivity equations at each time step. One option for the design is to inherit from Solver (via TimeSeriesSensitivitySolver and SensitivitySolver) and from CVODEIntegrator. This works but requires changing solver types to use virtual inheritance because of the introduced diamond inheritance problem. Instead, we opt to use composition instead of inheritance and use the CVODEIntegrator for the main integration routines for code reuse. Options for ForwardSensitivitySolver include choosing parameters for sensitivity analysis (vs all model variables), choosing the nonlinear solver (newton vs fixed point), choosing finite difference approx method (central or forward) and choosing the method of computing sensitivities (either simultaneous or staggered).

• Implemented a typemap in roadrunner's swig-Python bindings for converting rr::Matrix3D<double, double> to a 3D numpy.ndarray. The actual return type is a 4-tuple: (1d time array, 3d results array, rownames, column names). The NamedArray type was not used because it is Python wizardry.

• Added some interfaces to the TestModelFactory test suite so that we can test structural properties, jabobians, mca and eigenvalues using this test suite. These are swigged so that we can implement the same tests from both C++ and Python. Python test suits have been added that use unittest and they are built in such a way that requires minimal effort to add a test case (developers would add a new TestModel to TestModelFactory, implement the desired interfaces and then the relevant test methods should already work.

• Modified Azure pipelines so that the "other" Python tests are actually executed. We make use pytest to easily find and run roadrunner-python tests in a Python standard way.

• Solver types have a number of methods inside RoadRunner class. They are: getSolver, getSolverByName, makeSolver, getExistingSolverNames, getRegisteredSolverNames, setSolver, SolverExists, replacing solver with either Integrator, SteadyState or Sensitivity. These have been added for Sensitivity solver and the missing ones added for SteadyState solvers. Notably, there is a lot of duplicated logic here, it should be the subject of future efforts to abstract this logic and to implement it in a generalized way.

• Added an "Examples" section to the documentation, which is populated only by sensitivity examples at this time.