GENESIS is composed of several independent software components, each of which has a presence in Python. It is possible via the API of components such as the Model Container, Heccer, and Experiment, to script your simulations via Python. However this is not desirable since all simulations would be composed of code which contain their own control flow, that would often times require the user to understand all of the internals in order to expand on existing simulations. SSPy is designed in the same vein as the SSP (Simple Scheduler in Perl) in that it encapsulates the operations for loading and running a complete simulation while allowing for complete control of simulation parameters and simulator options via a declarative configuration file. It also provides an easy plugin framework so that new modeling services, experimental protocols and solvers can be dynamically loaded from a plugin directory, making them immediately available without the need to change any of the core code. For more information on the plugin framework and extending SSPy, see the SSPy developer document.
SSPy has a top level executable file named ’sspy’ that is used to run simulations on the command line. To run an existing schedule you simply type out the path to the sspy executable and pass it the schedule file as an argument. This example is performed when in the ’0’ directory of the SSPy package:
This particular simulation loads a model, runs for 2500 steps and places the output in a file called /tmp/output.
SSPy has an interactive shell that allows you to create and run a simulation. To start SSPy in interactive mode use the ’–shell’ flag:
To bring up the help screen type ’help’ or ’?’, this will present a list of all commands with documented help. A number of other features are available such as auto completion for commands and loaded model elements, basic history (up and down keys) and previous command execution. The shell may be used for debugging existing simulations interactively. If you want to inspect the purk_test simulation, you can start SSPy like this:
./sspy --shell yaml/purk_test.yml
This will load the purk_test simulation specification and drop into the shell, allowing you to list elements, add model parameters, outputs, and inputs. A user can run the simulation the complete simulation as loaded in steps mode or time mode with this shell command:
sspy> run 2500
Note that passing an integer value will run the simulation in steps mode, passing a float value (with a decimal point) will run the simulation in time mode. In the shell it is possible to create and run an entire simulation. Here is an example of the commands required to run the purk_test example. For sake of space and readbility, only one output is applied to the voltage potential of the soma:
sspy> ndf_load tests/cells/purk_test.ndf
sspy> model_parameter_add /purk_test/segments/soma INJECT 2e-09
sspy> heccer_set_timestep 2e-05
sspy> output_add /purk_test/segments/soma Vm
sspy> run /purk_test 2500
After successful execution of these commands the output can be found in the file /tmp/OutputGenerator.
If you wish to create more customized simulations and interfaces, you may access the top level API of SSPy. The API makes it very easy to interface with GUI toolkits, websites, and customized shells (the shell previously covered makes use of the API). This example performs the same purk_test example shown previously in the shell example:
from sspy import SSPy
scheduler = SSPy(verbose=True)
my_model_container = None
# Create a model container service and load an ndf file
my_model_container = scheduler.CreateService(name="My Model Container",
# Must create solver.
my_heccer = scheduler.CreateSolver(’My solver’, ’heccer’, verbose=True)
# Sets the segment of the model to run from
# set the timestep for the entire scheduler (solvers, inputs and outputs)
# Create Outputs
my_output = scheduler.CreateOutput(’My output object’, ’double_2_ascii’)
Should note that the model_container and heccer that are called are plugin abstractions over the Model Container and Heccer packages, not the objects themselves. The core objects are accessible via a method call.