Is "pre-run-simulation" a playback mode?

[interim17]

What needs to happen?

Current "pre-runs" (remote example being current BioSimulators API) emit a complete trajectory, so in that sense they are not a playback mode, but really a process that results in precomputed playback mode (ID_TRAJECTORY_FILE_PLAYBACK).

In "live mode" we have a procedural simulator and can be rendering its most recent output as our playback behavior. In the pre-run case we may have a procedural simulator, but it would only ever emit complete trajectories which would be loaded as a block into a standard pre-computed playback mode.

It seems the thing to clarify is the relationship between pre-computed playback mode a a simulator that may or may not be able of emitting new frames, or sets of frames.

• can a given instance of a procedural simulator switch between live and pre-run mode
• make a test procedural simulator that does not operate in live mode but takes a config and emits a complete trajectory file
• make a test procedural simulator that can do both

Why should we do this?

When does this need to get done?

[toloudis]

Do BioSimulators trajectories go through Octopus?

[interim17]

Do BioSimulators trajectories go through Octopus?

Yes, currently they go through Octopus.

Current state of BioSimulators work is to: send their API a config, receive back a precomputed Smoldyn file, pass it through our converter on Octopus to get a precomputed simularium file, then load that file wholesale.

So the end result looks almost the same as querying a trajectory from our s3 bucket with a RemoteSimulator, only difference being its somewhat ephemeral and would need to be saved locally if long term storage is desired.

@ascibisz could speak to the viability of a "live mode" type querying of BioSimulators.