Roadmap

Updated: 29 May 2019.

The current roadmap had evolved from that present in the 0.1.0 release of libCellML.

Each milestone may consist of several ‘releases’ and future requirements may impact the design and implementation of earlier releases of libCellML. Major changes in the API will be accepted up to the release of libCellML version 1.0.0.

High level objectives

libCellML is focused on CellML 2.0 and beyond.

  • The implementation of libCellML should be driven by the requirements for supporting CellML 2.0 and beyond.
    • libCellML should be designed to support the CellML specification with the flexibility for extra restrictions, constraints, or additions coming from future proposals for changing the specification.
  • libCellML should be able to parse models in CellML 2.0 and newer versions of the specification.
  • libCellML will only serialise models to the current version of the specification.

Environment

This section will specify the environment for the development of libCellML.

  • GitHub to host the primary libCellML source repository and issue tracker under the CellML organisation (current and former editorial board members).
  • Development language: C++ with SWIG bindings.
  • Build: CMake for generating cross-platform build rules.
  • Test: using Buildbot on the ABI BaTS to run continuous integration testing.
  • Test: unit testing to use gtest.
  • Documentation: written in reStructuredText.
  • Documentation: API and source code examples will be documented using C++-style Doxygen comments.

Requirements

  • Documentation: made available on readthedocs.io. Read the Docs uses Sphinx for generating documentation.
  • Documentation: is amenable for inclusion in external documentation efforts
  • Development: Agile, test driven development where:
    • Functionality is more important than API stability in early releases.
    • Release early and often.
  • Development: code review prior to acceptance into the primary repository using the pull request feature on GitHub.
  • Development: objectives are added and broken down into incremental tasks.
  • Development: a single task should be no more than two weeks.

We should avoid using non-standard system libraries unless there is a compelling reason. Once features are available, the API can be fine tuned in consultation with the CellML community.

Milestone 1: Python bindings, validation, code generation, and documentation

  1. Python bindings.
    1. Wrap the libCellML API using Swig to be able to generate Python bindings for the library.
    2. Package the bindings so they can be easily installed across Windows, Linux, and macOS.
  2. Load a CellML 2.0 model and validate it.
    1. Validate models against the rules defined in the current draft of the CellML 2.0 specification (currently an active document, outstanding issues regarding the new reset construct are likely to require updates to the validation implementation).
  3. Code generation.
    1. Focus on non-DAE models.
    2. Generate code for any simulatable non-DAE CellML model in PMR (i.e., translated from CellML 1.0/1.1).
    3. Guide the code generated for a given model (e.g., a variable to be controlled from an external data source, SED-ML defined changes, etc.).
  4. Documentation available.
    1. API.
    2. Tutorials/documented code examples.
    3. Integrating libCellML into common IDEs (Visual Studio, Qt Creator, and PyCharm).
    4. Provide documentation on the installation and use of the Python bindings across Windows, Linux, and macOS.

Milestone 2: units, JavaScript, and resets

  1. Units.
    1. Checking units within mathematical expressions.
    2. Debugging assistance for model authors regarding units.
  2. JavaScript.
    1. Use Emscripten to create a JavaScript API for libCellML.
    2. Provide a suitable packaged version of the JavaScript API for integration in common JavaScript environments (e.g., Node, Webpack).
    3. Document the installation and use of the JavaScript API.
  3. Resets.
    1. Extend libCellML implementation to fully support resets.

Milestone 3: DAE models

  1. DAE models.
    1. Code generation support for models with DAEs.

Milestone 4: advanced capabilities

  1. High-order model manipulation (recall the discussion with Andrew McCulloch at the 8th CellML workshop).
    1. Again, it is outside the scope of libCellML, but helping tool developers provide these kinds of services is very important.