Action Potential Prediction

Welcome to AP-Nimbus’s documentation

Project Home:https://github.com/CardiacModelling/ap-nimbus
Documentation:https://ap-nimbus.readthedocs.io/
Created:Jul 23, 2020
Version:0.0.1

IMPORTANT

This activity represents the next step in the development of the original AP-Portal work – towards a container-based / cloud solution.

AP-Nimbus is available at https://github.com/CardiacModelling/ap-nimbus and is being developed by the University of Nottingham’s School of Mathematical Sciences .

Preamble

  • Unlike AP-Portal, this work includes the installation of ApPredict, the cardiac simulation software.
  • Also unlike AP-Portal, this work, by nature of containerisation, means that AP-Nimbus work does not embody a single application, it is instead a collection of containers where each can operate in isolation, e.g. as a standalone Docker or Singularity container, or alternatively, orchestrated in a microservice architecture (e.g. Kubernetes or Docker Compose).

Singularity

This documentation predominantly covers Docker container environments, however it has been relatively straightforward to create Singularity containers (e.g. singularity build app-manager.img docker://cardiacmodelling/ap-nimbus-app-manager:0.0.10) and use those [1].

Sample invocation scripts can be found at ap-predict-online’s app-manager –> tools section.

Diagrammatic Representation

For the role each of the containers has in the overall AP-Nimbus activity please see Activity Overview.

ApPredict

ApPredict is the underlying cardiac simulation engine.

Building or installing ApPredict is a complex and time-consuming process and by distributing in container form it’s possible to have it installed in a fraction of the time [2].

ApPredict in Containers.

Warning

cardiacmodelling/ap-nimbus-app-manager does not currently handle either of PKPD or Dynamic CellML operations. These activities can only take place when using the CLI cardiacmodelling/appredict-no-emulators or cardiacmodelling/appredict-with-emulators.

Orchestration

The following illustrates a microservice-based solution to potentially running many ApPredicts concurrently.

ApPredict container orchestration.

It is equally feasible to run as .. :

  • Containerised
    • docker run .. a single cardiacmodelling/ap-nimbus-app-manager container and call it with HTTP POST and GET requests, or;
    • docker run .. either of the cardiacmodelling/appredict-with-emulators or cardiacmodelling/appredict-no-emulators containers directly from a CLI to run their internal ApPredicts, or;
  • Non-containerised
    • Run cardiacmodelling/ap-nimbus-app-manager and/or cardiacmodelling/ap-nimbus-client-direct locally as a non-containerised development environment, e.g. by running their ./kick_off.sh scripts manually [3]
      This is covered in Developer Section.

See also

For instructions on how to run containers, see the more detailed section on Running.

Security

Developer Section

Footnotes

[1]Singularity containers (or rather, a Singularity version of just cardiacmodelling/ap-nimbus-app-manager so far) have been trialled operating in isolation, not in an orchestrated environment.
[2]So long as there’s a container runtime, e.g. Docker, running somewhere!
[3]Running cardiacmodelling/ap-nimbus-app-manager and/or cardiacmodelling/ap-nimbus-client-direct in a non-container form requires a local installation of ApPredict and other software, e.g. Node.js, inotify, jq.