initial state

[eagmon]

This PR aims to extract the initial state from parameters retrieved with get_parameters_variables_for_simulation. The first commit is very sloppy, with hardcoded assumptions about naming. This needs to be improved before merging.

[eagmon]

@jonrkarr -- I began work on extracting the initial state as you described in #4. To do this, I look through all the parameter.target strings in parameters to see which end with '@initialConcentration' -- instead of inspecting strings, we should more directly extract the intended data type. I also had to do some string parsing to get the molecule name from parameter.name, and then added dynamic_species_ to the front so that it matches the variable names in self.variables. I'm sure there is a better way to do this.

[jonrkarr]

We can add options to return the SBML component ids and names rather than a name for the variable and intended data types so no parsing is needed.

This is easy to change. I'll get his changed this week.

[jonrkarr]

For the purpose of joining models, we could also return the metadata about each model component. This information could be used for model construction. Metadata is a more complicated issue that we can push on over time.

[eagmon]

@jonrkarr -- you mentioned that you maintain a python environment that includes some subset of the BioSimulators. Is that pip installable? I would like to use it in this repo so that we can simply import a BioSimulators in the BiosimulatorProcess's __init__()

[jonrkarr]

The easiest path are these Docker images https://github.com/orgs/biosimulators/packages?repo_name=Biosimulators

The Dockerfiles are at https://github.com/biosimulators/Biosimulators. This includes pipenv files.

There's two images. One with the Biosimulators python packages (as of last week). A second just with their non-python dependencies.

This has 17 of 20 simulation tools. We don't have a Python API for VCell yet. OpenCOR can't easily be installed together. They're working on this, but it will be a while. We've only verified RBApy with CPLEX, which isn't available for Python 3.9 yet. We're going to try to get Gurobi working instead, which would also simplify licensing.

Currently, no licenses are needed. This will change soon once we get RBApy working with Gurobi.

We still need to start versioning these Docker images.

Long- term, it would be much better to execute individual tools in separate docker images because one Python environment is unscalable.

[eagmon]

@jonrkarr -- when we meet this week, let's talk about how to access the integrated python environment. I am not very familiar with pipenv -- can I use these files to install modules in a local python environment, or is it more like docker?

We will rely on having an integrated environment in the short term, as the distributed vivarium with docker images and network API is a significant project that will require higher bandwidth. I completely agree this is unscalable for the long-term. @prismofeverything and I talked about this just recently, and estimated it would take about a month of full-time work.

[jonrkarr]

Agreed, plenty can be done without isolating each tool into a separate environment. For now, we can mostly manage that environment. If we can get the community to start contributing tools more independently, this will eventually become unsustainable.

For now, the easiest path is to use our Docker image.

If you need more flexibility, pipenv captures much of what is needed to replicate the environment.

pipenv is a command-line tool for managing Python environments. Roughly, pipenv combines dependency information from setup.py scripts and pip freeze. It captures the required version range of each dependency and the specific version that is installed. This makes it easy for me to manage the environment and (in theory) for you to replicate that on your machine. This is useful because the combination of simulation tools requires specific versions of dependencies. We then install the environment managed with pipenv into a Docker image.