David Nickerson, 9 June 2014.

Contributions from Alan Garny, Jonathan Cooper, Mike Cooling, Tommy Yu, Hugh Sorby, Randall Britten and the CellML Community, but no time yet for full consensus.

These requirements and milestones are derived from the CellML API May 2014 Requirements collected from the CellML community, with input from the primary target users (application developers) and the CellML Editorial Board. Previous editorial board discussions have also been incorporated into this roadmap.

Clearly, the milestones defined below are to be worked on in numerical order and previous milestones will be completed before work on subsequent milestones begins. 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

  • Focus on CellML 2.0 and beyond.
    • The implementation of libCellML should be driven by the requirements for supporting CellML 2.0 and beyond.
    • Implementing support for core+secondary specifications is likely to be a big challenge for libCellML.
      • libCellML should be designed to support the core specification with the flexibility for extra restrictions/constraints coming from the secondary specifications.
      • Multiple secondary specifications could be used in one model.
      • Secondary specifications may exist for a period of time before they are integrated or consolidated into a new version of CellML (if at all, there is still a lot to learn about how secondary specifications will evolve).
    • libCellML should always be able to import earlier CellML version models.
    • To begin with, libCellML must be able to export CellML 2.0 models to CellML 1.1 (probably using API marked as deprecated from the beginning and removed once Milestone 3 is achieved).
  • Develop the libCellML API as work progresses through the milestones outlined below.


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


  • Documentation: made available on 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.
  • Development: the next objective to be worked on is discussed and agreed with the community before work is started on an objective.

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 0: setting up development environment

  1. Share an UML-esque document with the community via GitHub describing a CellML specific object model.
    1. The form of the API to libCellML should not be dictated by the XML serialisation but by the objects tool developers desire to work with
    2. Respond to feedback
  2. Setup the cross platform build and test environment using the ABI’s build and test server (BaTS).
    1. Builds required: Windows 64 bit, OS X 10.9, Ubuntu 14.04 64 bit
    2. Using Buildbot for CI framework
    3. Interact with GitHub to process changes
    4. Make Buildbot status available from
  3. Document the development process/workflow.
    1. Code contribution document
    2. Developer setup document
    3. Code review document

Milestone 1: starting to get useful code (timeframe: ? months)

  1. Create a CellML 2.0 model from scratch and save it to XML
    1. Create a new model, add imports, components, variables, units and mathematics.
    2. The first test case?
  2. Load a CellML 2.0 model, make changes to it and save it.
    1. Ability to preserve the underlying XML structure/ordering for documents read in and written out.
  3. Load a CellML 2.0 model and validate it.
    1. This is important to get out early as it will help make sure the normative specification is “complete” and sensible.
    2. It will ensure that we can test models as we work on getting the specification completed (c.f. the error ridden examples from the CellML 1.0 and 1.1 specifications).
    3. It must include proper units validation of the mathematics.
    4. libCellML should have a validation framework based on the core specification and then secondary specifications can add their specific rules.
    5. For CellML 2.0, this is mainly the mathematics, so the core validation can probably validate a model, but it needs the actual restricted subset of MathML from the secondary specifications to fully validate units consistency.
  4. Import CellML 1.0/1.1 models.
  5. Export to CellML 1.1 (and, by extension, CellML 1.0), so that we can still use existing tools (e.g. simulation, annotation, NeSI), preserving model and XML structure/ordering/modularity where possible.
  6. Platform support: Windows, Linux and OS X.
    1. Native installers (using CPack, pip).
    2. Easy to setup build environment (good documentation).
  7. Language support: C++, Python, Java, MATLAB.
  8. Documentation available.
    1. API.
    2. Tutorials/documented code examples.
    3. Integrating libCellML into various common IDEs (Visual Studio, Eclipse, Qt Creator, NetBeans…).

Milestone 2: toward simulation support (timeframe: ? months)

  1. Conversion to intermediate representation.
    1. Conversion to CellML structureless mathematics (i.e. just the mathematics, but with units information) into an intermediate representation that can be transformed / analysed by other tools.
    2. Ability to maintain the CellML structure (as much as possible), perhaps via object annotation (e.g. COR).
    3. Will form the basis for tools using libCellML to perform numerical simulation.
  2. Improved support for model authoring/editing/manipulation.
    1. Provide an events system to monitor changes in the model.
    2. Provide access to data contained in CellML models in external namespaces (RDF, extensions, etc.).
  3. Documentation, documentation and more documentation!

Milestone 3: functional library for tool developers (timeframe: ? months)

  1. Establish the process/API required to generate procedural code from the intermediate representation.
    1. Generic code vs solver specific code.
    2. Could be a role for being informed from SED-ML what solver is to be used and customising the generated code appropriately.
    3. It would be a tool sitting on top of libCellML, not directly part of it.
  2. Being able to run simulations with CellML 2.0.
    1. While not directly part of libCellML, helping tool developers get to the point where they can execute simulations is critically important.
    2. CellML 2.0 will not be released until we can do this (in addition to the other requirements above).

Milestone 4: advanced capabilities (timeframe: ? months)

  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.

Milestone 5: broadening accessibility (timeframe: ? months)

  1. Support for more platforms.
    1. Android, iOS.
  2. And languages.
    1. JS, C#/.NET, C, Fortran[77|90|20XX].