Engines and Runners

Engines and Runners

Introduction

CellBlender supports different kinds of simulations (engines) run on different kinds of computing platforms (runners). The Engines and Runners API provides a specification for ensuring that each kind of simulator (engine) can be run on each computing platform (runner).

General Approach

• Separate the Things to Run (simulation “engines”) from the Ways to Run them (simulation “runners”).
• Support “pluggable” modules that can be added and detected without changing any CellBlender code.
• Provide a simple API for writing of new engines and runners without requiring any Blender knowledge.
• Ensure that the API also allows using Blender features (as desired) for writing advanced engines and runners.

Implementation Approach

The Engines and Runners API is currently designed around Python modules which can be inspected for the existence of pre-defined functions and data. The API will define both required and optional functions and data. The API will also define a priority (or search order) when multiple functions and/or data can be used to perform the same task. The priority order is typically chosen so that the higher performance options will be chosen over the lower performance options.

For example, the Engine API defines 3 functions to prepare files for a series of runs. The fastest (but most complicated) function is prepare_runs_no_data_model. This function is expected to get all of its data from CellBlender's internal properties, so there's no need to construct and pass a data model. If this function is present in a runner, then it will be called whenever runs need to be prepared. If that function isn't present, then the second priority function prepare_runs_data_model_no_geom will be called. This second priority function expects a data model describing everything in the system except the geometry data. This second priority function is expected to know how to get its geometry directly from Blender and CellBlender. The third priority function is prepare_runs_data_model_full. As its name implies, it is expecting to get all of its information (including geometry) from the data model. This will be slower since a full geometry data model must be created, but it will be considerably easier to write because it's a simple dictionary/list representation of the data.

Preliminary API Data Items (for Engines or Runners)

parameter_dictionary
parameter_layout

Preliminary API Functions for Engines

Prepare Runs (at least one is required)

1st Priority: prepare_runs_no_data_model
2nd Priority: prepare_runs_data_model_no_geom
3rd Priority: prepare_runs_data_model_full

Provide Status (optional)

get_progress_message_and_status ( stdout_txt )

Post-Run Processing

postprocess_runs