Below is a collection of brief tutorials on BioSimulators:

  • Creating COMBINE archives with SED-ML documents for simulation experiments.
  • Finding simulations tools that have the capabilities to execute specific COMBINE archives.
  • Using simulation tools to execute COMBINE archives:
    • In the cloud using runBioSimulations or its REST API.
    • Locally using Docker.
    • In HPC environments using Singularity.
  • Developing standardized interfaces to simulation tools and contributing them to BioSimulators.

This information was presented at the HARMONY meeting on 3/22.

  • Video
  • Slides

The containerized biosimulation tools in the BioSimulators registry require modeling projects (one or more simulations of one or more models) to be described by an OMEX file and packaged into a COMBINE archive. Please follow these steps to create OMEX and COMBINE files. Alternatively, COMBINE/OMEX files that describe modeling projects can be obtained from the BioSimulations repository of modeling projects .

  1. Create a directory for the modeling project.
  2. Create one or more models: Create files that describe the models that you would like to simulate and save these files to the directory for the modeling project. Currently, the simulation tools in the BioSimulators collection support several languages, including the BioNetGen Language (BNGL) and Systems Biology Markup Language (SBML) formats. More information about BNGL and SBML is available from their websites. Alternatively, models can be obtained from BioModels , BioSimulations , and other model repositories.
  3. Create or more simulations: Create a Simulation Experiment Description Markup Language (SED-ML) file which describes the simulations that you would like to execute and the simulation results that you would like to record. Currently, all of the validated simulation tools support a subset of SED-ML L1V3 including models (sedml:model) and model attribute changes (sedml:changeAttribute, steady-state, one step, and timecourse simulations (sedml:steadyState, sedml:oneStep, and sedml:uniformTimeCourse), tasks for the execution of individual simulations of individual models (sedml:task), algorithms (sedml:algorithm) and algorithm parameters (sedml:algorithmParameter), data generators for individual variables (sedml:dataGenerator, sedml:variable), and report outputs (sedml:report). Some of the simulation tools support the full SED-ML specification, including repeated tasks (sedml:repeatedTask), data generators for mathematical expressions (sedml:dataGenerator/@math), and plot outputs (sedml:plot2D and sedml:plot3D). Save this file to the directory for your modeling project. More information about SED-ML is available from the SED-ML website. Alternatively, simulations can be obtained from the BioSimulations repository of modeling projects .
  4. Create an OMEX file which describes your model and simulation files and package them into a COMBINE archive file: OMEX is a format for describing a collection of modeling files, and a COMBINE archive is a zip file which contains an OMEX file and all of the other files which comprise the modeling project. Several example COMBINE archives are available here . More information about the OMEX and COMBINE formats is available at the COMBINE website . The COMBINE website lists several software tools for creating COMBINE archives, including COMBINE Archive and COMBINE Archive Web .
The simulation tools in the BioSimulators collection support different modeling frameworks, different simulation algorithms, and different model formats. The simulators page outlines the modeling frameworks, simulation algorithms, and model formats supported by each tool. After determining the framework and format of your model and the simulation algorithm which you would like to execute, use this page to identify a simulation tool that is capable of executing your modeling project.

Two web applications are available for using the BioSimulators simulation tools to execute simulations. runBioSimulations is a simple application that uses BioSimulators to execute modeling studies. BioSimulations is a platform for publishing modeling studies that also uses BioSimulators to execute published modeling studies.

The BioSimulators simulation tools can also be used to execute simulations on your own machine. Please follow these steps to use a containerized simulation tool to execute a modeling study on your own machine.

  1. Install the Docker container engine: Detailed instructions for all major operating systems are available from the Docker website .
  2. Download the simulator(s) that you wish to use: From your console, execute docker pull biosimulators/{{ '{' }} simulator-id {{ '}' }} for each simulator that you wish to use. This will download the simulators and install them onto your machine.
  3. Use the selected simulator(s) to execute simulations and save their results: Execute the following from your console:

    docker run \
      --tty \
      --rm \
      --mount type=bind,source={{ '{' }} path-to-directory-of-COMBINE-archive {{ '}' }},target=/tmp/project,readonly \
      --mount type=bind,source={{ '{' }} path-to-save-results {{ '}' }},target=/tmp/results \
      ghcr.io/biosimulators/{{ '{' }} simulator-id {{ '}' }} \
        --archive /tmp/project/{{ '{' }} name-of-COMBINE-archive {{ '}' }} \
        --out-dir /tmp/results

    Your COMBINE archive should be located at path-to-directory-of-COMBINE-archive/name-of-COMBINE-archive.

    The results will be saved to path-to-save-results. The data for reports and plots will be saved in Hierarchical Data Format 5 (HDF5) format and plots will be saved in Portable Document Format (PDF) and bundled into a single zip archive. See the specifications for reports for more information about the format of reports.

    For reports, the rows of each data table will represent the data sets (sedml:dataSet) outlined in the SED-ML definition of the report. The heading of each row will be the label of the corresponding data set. For plots, the rows of each data table will represent the data generators (sedml:dataGenerator) outlined in the SED-ML definition of the plot. The heading of each row will be the id of the corresponding data generator

    Report tables of steady-state simulations will have a single column of the steady-state predictions of each data set. Report tables of one step simulations will have two columns that represent the predicted start and end states of each data set. Report tables of time course simulations will have multiple columns that represent the predicted time course of each data set. Report tables of non-spatial simulations will not have additional dimensions. Report tables of spatial simulations will have additional dimensions that represent the spatial axes of the simulation.

The BioSimulators simulation tools can also be running in high-performance computing (HPC) environments where root access is not available by first converting the Docker images for the tools into Singularity images .

All of the validated images for simulation tools are compatible with Singularity. As part of the validation process, we check that each Docker image can be converted into a Singularity image.

The steps below illustrate how Singularity can be used to execute the simulation tools in HPC environments.

  1. Install Singularity: Instructions are available at https://sylabs.io/docs/.
  2. Pull the Docker image by executing docker pull ghcr.io/biosimulators/{{ '{' }} id {{ '}' }}:{{ '{' }} version {{ '}' }}.
  3. Convert the Docker image to a Singularity image by executing singularity pull {{ '{' }} /path/to/save/singularity-image.sif {{ '}' }} docker://ghcr.io/biosimulators/{{ '{' }} id {{ '}' }}:{{ '{' }} version {{ '}' }}.
  4. Run the Singularity image by executing singularity run {{ '{' }} /path/to/save/singularity-image.sif {{ '}' }} ....
An API is available for retrieving information about the simulation tools in the BioSimulators collection. Please see the documentation for the REST API for more information.

We welcome contributions of additional simulation tools!

All simulation tools submitted for validation by BioSimulators should support at least one modeling language, SED-ML, KiSAO, and COMBINE/OMEX.

  • Modeling languages. Containers should support at least a subset of at least one modeling language such as BNGL, CellML, Kappa, NeuroML/LEMS, pharmML, SBML, or Smoldyn.
  • SED-ML. Currently, containers should support at least the following features of SED-ML L1V3:
    • Model and model attribute changes: sedml:model, sedml:changeAttribute.
    • At least one of steady-state, one step, or timecourse simulations: sedml:steadyState, sedml:oneStep, or sedml:uniformTimeCourse.
    • Tasks for the execution of individual simulations of individual models: sedml:task.
    • Algorithms and algorithm parameters: sedml:algorithm, sedml:algorithmParameter.
    • Data generators for individual variables: sedml:dataGenerator, sedml:variable
    • Report outputs: sedml:report.
  • KiSAO. SED-ML documents interpreted by containers should use KiSAO terms to indicate algorithms and algorithm parameters. As necessary, use the KiSAO issue tracker to request terms for additional algorithms and algorithm parameters.
  • COMBINE/OMEX. Containers should support the full COMBINE/OMEX specification.

Please follow the steps below to create a containerized simulation tool that adheres to the BioSimulators standards. Several examples are available from the BioSimulators GitHub organization . A template repository with template Python code for a command-line interface and a template for a Dockerfile is available here .

  1. Optionally, create a Git repository for your command-line interface and Dockerfile.
  2. Implement a BioSimulators-compliant command-line interface to your simulation tool. The interface should accept two keyword arguments:

    • -i, --archive: A path to a COMBINE archive that contains descriptions of one or more simulation tasks.
    • -o, --out-dir: A path to a directory where the outputs of the simulation tasks should be saved. Data for plots and reports should be saved in HDF5 format (see the specifications for data sets for more information) and plots should be saved in Portable Document Format (PDF) bundled into a single zip archive. Data for reports and plots should be saved to {{ '{ ' }}out-dir{{ ' }' }}/reports.h5 and plots should be saved to {{ '{ ' }}out-dir/plots.zip{{ ' }' }}. Within the HDF5 file and the zip file, reports and plots should be saved to paths equal to the relative path of their parent SED-ML documents within the parent COMBINE/OMEX archive and the id of the report/plot.

      For reports, the rows of the data tables should correspond to the data sets (sedml:dataSet) specified in the SED-ML definition of the report (e.g., time, specific species). The heading of each row should be the label of the corresponding data set.

      For plots, the rows of the data tables should correspond to the data generators (sedml:dataGenerator) specified in the SED-ML definition of each curve and surface of the plot (e.g., time, specific species). The heading of each row should be the id of the corresponding data generator.

      Data tables of steady-state simulations should have a single column of the steady-state predictions of each data set. Data tables of one step simulations should have two columns that represent the predicted start and end states of each data set. Data tables of time course simulations should have multiple columns that represent the predicted time course of each data set. Data tables of non-spatial simulations should not have additional dimensions. Data tables of spatial simulations should have additional dimensions that represent the spatial axes of the simulation.

      See the specifications for reports for more information.

    In addition, we recommend providing optional arguments for reporting help and version information about your simulator:

    • -h, --help: This argument should instruct the command-line program to print help information about itself.
    • -v, --version: This argument should instruct the command-line program to report version information about itself.
  3. Create a Dockerfile which describes how to build an image for your simulation tool.
    • Use the FROM directive to choose a base operating system such as Ubuntu.
    • Use the RUN directive to describe how to install your tool and any dependencies. Because Docker images are typically run as root, reserve /root for the home directory of the user which executes the image. Similarly, reserve /tmp for temporary files that must be created during the execution of the image. Install your simulation tool into a different directory than /root and /tmp such as /usr/local/bin.
    • Ideally, the simulation tools inside images should be installed from internet sources so that the construction of an image is completely specified by its Dockerfile and, therefor, reproducible and portable. Additional files needed during the building of the image, such as licenses to commerical software, can be copied from a local directory such as assets/. These files can then be deleted and squashed out of the final image and injected again when the image is executed.
    • Set the ENTRYPOINT directive to the path to your command-line interface.
    • Set the CMD directive to [].
    • Use the ENV directive to declare all environment variables that your simulation tool supports.
    • Do not use the USER directive to set the user which will execute the image so that the user can be set at execution time.
    • Use the LABEL directive to provide the metadata about your simulation tool described below. This metadata is also necessary to submit your image to BioContainers , a broad registry of images for biological research.

      • Open Containers Initiative labels
        • org.opencontainers.image.title: Human-readable title of the image.
        • org.opencontainers.image.version: Version of the software in the image.
        • org.opencontainers.image.revision: Source control revision identifier of the software in the image.
        • org.opencontainers.image.description: Human-readable description of the software in the image.
        • org.opencontainers.image.url: URL to find more information about the image.
        • org.opencontainers.image.documentation: URL to get documentation about the image.
        • org.opencontainers.image.source: URL to get the Dockerfile for building the image.
        • org.opencontainers.image.authors: Contact details of the people or organization responsible for the image.
        • org.opencontainers.image.vendor: Name of the entity, organization or individual which distributes the image.
        • org.opencontainers.image.licenses: SPDX expression that describes the license(s) under which the software in the image is distributed.
        • org.opencontainers.image.created: Date and time when the image was built (RFC 3339).
      • BioContainers labels:
        • version: Version of your image (e.g., 1.0.0)
        • software: Simulation program wrapped into your image (e.g., BioNetGen).
        • software.version: Version of the simulation program wrapped into your image (e.g., 2.5.0).
        • about.summary: Short description of the simulation program (e.g., Package for rule-based modeling of complex biochemical systems).
        • about.home: URL for the simulation program (e.g., https://bionetgen.org/).
        • about.documentation: URL for documentation for the simulation program (e.g., https://bionetgen.org/).
        • about.license_file: URL for the license for the simulation program (e.g., https://github.com/RuleWorld/bionetgen/blob/master/LICENSE).
        • about.license: SPDX license id for the license for the simulation program (e.g., SPDX:MIT). See SPDX for a list of licenses and their ids.
        • about.tags: Comma-separated list of tags which describe the simulation program (e.g., rule-based modeling,dynamical simulation,systems biology,BNGL,BioSimulators). Please include the tag BioSimulators.
        • extra.identifiers.biotools: Optionally, the bio.tools identifier for the simulation program (e.g., bionetgen). Visit bio.tools to request an identifier for your simulation program.
        • maintainer: Name and email of the person/team who developed the image (e.g., Jonathan Karr <karr@mssm.edu>).

      Below is an example of metadata for the BioNetGen image.

  4. Use Docker and the Dockerfile to build an image for your simulation tool by executing the following from your console:

    docker build \
      --tag {{ '{' }} dockerhub-user-id {{ '}' }}/{{ '{' }} simulator-id {{ '}' }}:{{ '{' }} simulator-version {{ '}' }} \
      --tag {{ '{' }} dockerhub-user-id {{ '}' }}/{{ '{' }} simulator-id {{ '}' }}:latest \
      --file {{ '{' }} path-to-Dockerfile {{ '}' }} \
      .
  5. Create a JSON-encoded file that specifies the capabilities of your simulation tool. This file should adhere to the schema described in the BioSimulators API .

    Use SBO, KiSAO, and EDAM to describe the modeling frameworks, simulation algorithms, and modeling formats that your simulation tool supports. As necessary, use the following issue trackers to request additional SBO , KiSAO , and EDAM terms. As necessary, also use the SED-ML issue tracker to request URNs for additional modeling languages. Currently, there is no process to request additional model format specification URLs for using COMBINE with additional model formats.

  6. Use the BioSimulators test suite to validate your image and its specifications. This will check that the image provides a BioSimulators-compliant Docker structure and command-line interface, and that it provides all of the simulation algorithms described in its specifications.

    pip install biosimulators-test-suite
    biosimulators-test-suite validate {{ '{' }} dockerhub-user-id {{ '}' }}/{{ '{' }} image-id {{ '}' }} {{ '{' }} path-to-specifications.json {{ '}' }}

We welcome contributions of additional simulation tools! We encourage developers to submit tools that support BioSimulators' standard containerized command-line interface. Supporting these standards makes it easier for other investigators to use simulators. However, BioSimulators also accepts simulation tools that are not available via standardized Docker images.

Please follow these steps to contribute a tool to BioSimulators:

  1. Annotate the capabilities of your simulation tool (e.g., supported modeling frameworks, simulation algorithms, model formats) using the BioSimulators format for the specifications of simulation tools.
  2. Optionally, build a standardized command-line interface for your simulator. This interface should support the following standards and conventions:

    BioSimulators utils provides tools for implementing these standards. A detailed template for using BioSimulators utils to build a command-line interface for a simulator is available here.

  3. Optionally, containerize the command-line interface for your simulator. Such an image will make it easier for others to use your tool. Containerized simulation tools should follow BioSimulators' standard for Docker images for simulation tools.
  4. Optionally, publish your image to a public repository such as Docker Hub , GitHub Container Registry , or Quay by executing docker push {{ '{' }} image-url {{ '}' }}. Docker Hub, GitHub Container Registry, and Quay each provide free accounts for public images.
  5. Submit an issue to the BioSimulators GitHub repository that describes briefly describes the URL to the specifications of your tool. This will initiate an automated workflow that will validate your simulation tool and either commit your tool to the BioSimulators registry or report problems with your simulation tool that must be addressed. The first version of each simulation tool submitted to the BioSimulators registry will also be manually reviewed by the BioSimulators Team prior to incorporation into the BioSimulators registry.
  6. Optionally, set up your continuous integration workflow to automatically push each release to BioSimulators. Within your continuous integration workflow (e.g., CircleCI, GitHub actions, Jenkins, Travis), use the GitHub REST API to automatically create issues that submit versions of your simulator to BioSimulators.

    This requires a GitHub account and a personal access token with the public_repo scope. Instructions for creating an access token are available in the GitHub documentation .

    • Endpoint: http://api.github.com/repos/biosimulators/Biosimulators/issues
    • Method: POST
    • Auth: {{ '{' }} github-username {{ '}' }}:{{ '{' }} github-person-access-token {{ '}' }}
    • Headers:
      • Accept: application/vnd.github.v3+json
    • Body (JSON-encoded)
      • title: Submit {{ '{' }} simulator-name {{ '}' }} {{ '{' }} simulator-version {{ '}' }}
      • body:
        ---
        name: {{ '{' }} simulator-name {{ '}' }}
        version: "{{ '{' }} simulator-version {{ '}' }}"
        specificationsUrl: {{ '{' }} specifications-url {{ '}' }}
        specificationsPatch:
          version: "{{ '{' }} simulator-version {{ '}' }}"
          image:
            url: {{ '{' }} docker-image-repo-url {{ '}' }}:{{ '{' }} simulator-version {{ '}' }}
        validateImage: true
        
        ---
        To skip the validation of your Docker image, or to submit a simulation tool for which there is no Docker image that provides a BioSimulators-compliant command-line entrypoint, set validateImage to false.

    curl code sample:

    curl \
      -X POST \
      -u jonrkarr:********* \
      -H "Accept: application/vnd.github.v3+json" \
      https://api.github.com/repos/biosimulators/Biosimulators/issues \
      -d '{{ '{' }}"labels": ["Validate/submit simulator"], "title": "Submit tellurium 2.1.6", "body": "---\nname: tellurium\nversion: 2.1.6\nspecificationsUrl: https://raw.githubusercontent.com/biosimulators/Biosimulators_tellurium/2.1.6/biosimulators.json\nvalidateImage: true\ncommitSimulator: true\n\n---"{{ '}' }}'

    The above is implemented by the Python method biosimulators_utils.simulator_registry.submit.submit_simulator_to_biosimulators_registry. See the documentation for more information.

  7. Optionally, also publish the source code for your simulation tool to a repository such as BitBucket , GitHub , or GitLab .
  8. Optionally, also publish your simulation tool to a software repository such as CRAN (R), NPM (JavaScript), or PyPi (Python).
  9. Optionally, also register your tool with bio.tools. Visit bio.tools to submit your tool to their regsitry of research tools.
  10. Optionally, also submit your Dockerfile to BioContainers. BioContainers accepts contributions via pull requests. See the BioContainers image registry for more information.

A sample continuous integration workflow for GitHub Actions is available in the template simulator repository. Instructions for setting up this workflow are in the README .

Each time a commit is pushed to the repository, the workflow executes the following tasks:

  1. Clones the repository.
  2. Installs the simulator and its dependencies.
  3. Lints the code for the simulator.
  4. Builds the Docker image for the simulator and tags the image ghcr.io/<owner>/<repo>/<simulator_id>:<simulator_version and ghcr.io/<owner>/<repo>/<simulator_id>:latest.
  5. Runs the unit tests for the simulator and saves the coverage data for the tests.
  6. Uploads the coverage results to Codecov .
  7. Compiles the documentation for the simulator.

Each time the repository is tagged (git tag ...; git push --tags), the workflow also runs the above tasks. If the above tasks succeed, the workflow executes the follwing additional tasks:

  1. Creates a GitHub release for the tag.
  2. Pushes the compiled documentation to the repository (e.g., so it can be served by GitHub pages).
  3. Builds the simulator and submits it to a software repository such as PyPI .
  4. Pushes the Docker image to the GitHub Container Registry with the above tags.
  5. Pushes the simulator to the BioSimulators Registry by using the GitHub API to create an issue to add a new version of the simulator to the BioSimulators database. This issue will then automatically use the BioSimulators test suite to validate the simulator and add a new version of the simulator to the database once the simulator passes the test suite.

We welcome contributions to the BioSimulators platform (e.g., web application, REST API, database)! Please see the Guide to Contributing for information about how to contribute to the platform.