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.
    • In local containers using Docker.
    • In containers in HPC environments using Singularity.
    • With command-line interafaces.
    • With Python.
  • Developing standardized interfaces to simulation tools and contributing them to BioSimulators.

The next live tutorial will be presented on 10/13/2022 during the COMBINE meeting. Videos and slides for past tutorials are available below.

  • Video
  • Slides

In adddition, several interactive tutorials for BioSimulators' Python packages and APIs are available from Binder .

The simulation tools in the BioSimulators registry require modeling projects (one or more simulations of one or more models) to be encapsulated into a COMBINE/OMEX archive. Please follow these steps to create COMBINE/OMEX archives. Alternatively, COMBINE/OMEX archives 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 project. Currently, the simulation tools in the BioSimulators collection support several languages, including the BioNetGen Language (BNGL), CellML, the GINsim Markup Language (GINML, ZGINML), NeuroML/LEMS, the RBApy format, the Smoldyn format, the Systems Biology Markup Language (SBML), the SBML flux balance constraints (SBML-fbc) and SBML qualititative (SBML-qual) models packages, the SBML Mass Action Stoichiometric Simulation (MASS) schema, and the XPP ODE format. More information about BNGL and SBML is available from their websites. Alternatively, models can be obtained from model repositiories such as BioModels and BioSimulations .
  3. Create or more simulations: Create a Simulation Experiment Description Markup Language (SED-ML) file which describes the simulation(s) 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), data generators for mathematical expressions (sedml:dataGenerator/@math), and report and plot outputs (sedml:report, sedml:plot2D and sedml:plot3D). Some of the simulation tools support the full SED-ML specification, including more complex model changes and repeated tasks (sedml:repeatedTask). 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 manifest file which describes your model and simulation files: OMEX manifest is a format for describing a collection of files, including the format (e.g., CellML, SBML) of each file. Several example COMBINE archives are available here. More information about the OMEX manifest format is available at the COMBINE website .
  5. Package your project into a COMBINE archive: A COMBINE archive is a zip file which contains an OMEX manifest file and all of the other files which comprise a 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 model formats, modeling frameworks, simulation types, simulation algorithms, and observables. First, determine the format and framework of your model and the simulation type and algorithm which you would like to execute. Second, browse the simulators to identify a tool which can execute your project. In addition, RunBioSimulations provides a tool which can recommend simulators for specific combinations of model formats, modeling frameworks, simulation types, and simulation algorithms.

runBioSimulations is a simple application that uses BioSimulators to execute modeling studies. runBioSimulations also provides a REST API for programmatically executing simulations.

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 {{ '}' }} ....

The command-line interfaces for simulation tools can also be installed and run locally. Note, this typically requires additional effort beyond using the Docker images because it requires installing the dependencies for simulation tools.

Please follow these steps to use a command-line interface for a simulation tool to execute a modeling study.

  1. Install Python >= 3.7.
  2. Install pip.
  3. Install the dependencies for the simulation tool. Links to installation instructions are available from the pages for each simulation tool.
  4. Install the command-line application for the simulation tool. From your console, use pip to install the Python package which provides the command-line application. The names of the Python packages which provide the command-line applications are available from the pages for each simulation tool.
  5. Use the command-line program to execute a simulation project and save its results: Execute the following from your console:

    biosimulators-{{ '{' }} simulator-id {{ '}' }} \
        --archive {{ '{' }} /path/to/COMBINE-archive.omex {{ '}' }} \
        --out-dir {{ '{' }} /path/to/save/outputs {{ '}' }}

    In the above example, the simulation project is located at /path/to/COMBINE-archive.omex and the results will be saved to /path/to/save/outputs.

The Python APIs for simulation tools provide additional flexibility beyond their Docker images and command-line interaces. However, using these APIs typically requires additional effort beyond using the Docker images because it requires installing the dependencies for simulation tools, as well as some knowledge of the data structures used by BioSimulators.

Please follow these steps to use a Python API for a simulation tool to execute a modeling study.

  1. Install Python >= 3.7.
  2. Install pip.
  3. Install the dependencies for the simulation tool. Links to installation instructions are available from the pages for each simulation tool.
  4. Install the Python API for the simulation tool. From your console, use pip to install the Python package which provides the Python API. The names of the Python packages which provide the Python APIs are available from the pages for each simulation tool.
  5. Open a Python shell.
  6. Import the Python API for the simulation tool. Import the Python module which provides the Python API. The names of the Python modules which provide the Python APIs are available from the pages for each simulation tool.
  7. Use the Python API to execute a simulation project and save its results: Execute the following from your Python shell:

    In the above example, the simulation project is located at /path/to/COMBINE-archive.omex and the results will be saved to /path/to/save/outputs.

    The ghcr.io/biosimulators/biosimulators Docker image contains most of the available Python APIs inside a single Python environment. An ipython shell to this environment can be launched by executing the following from your console:

    docker pull ghcr.io/biosimulators/biosimulators
    docker run -it --rm ghcr.io/biosimulators/biosimulators
    

Additional interactive tutorials are available from Binder .

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.

An interactive tutorial for using the API is available from Binder .

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.

    The easiest way to create a BioSimulators-compliant command-line interface is to create a BioSimulators-compliant Python API and then use methods in BioSimulators-utils to build a command-line interface from this API. Implementing a BioSimulators-compliant Python API primarily entails implementing a single method for executing a single simulation of a single model. Additional information about creating BioSimulators-compliant Python APIs, command-line interfaces, and Docker images, including templates, is available here.

  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 {{ '}' }}

    The command-line program for the test suite provides several helpful options such as for executing tasks directly through command-line interfaces and for executing individual test cases. More information is available here

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.