GENESIS: Documentation

Add the PulseGen{} Object to SSP

Reading Parameters

To integrate a solver object (here, we use the example PulseGen{}) with SSP, SSP must first be made aware of the parameters of the object. PulseGen{} takes parameters for Level1, Width1, Delay1, Level2, Width2, Delay2, BaseLevel{}, and TriggerMode{}, so SSP must be able to read in a value for each as an argument.

First, variables are declared for the optional arguments near the top of the bin/ssp file:

   my $option_pulsegen_level1;
   my $option_pulsegen_width1;
   my $option_pulsegen_delay1;
   my $option_pulsegen_level2;
   my $option_pulsegen_width2;
   my $option_pulsegen_delay2;
   my $option_pulsegen_baselvel;
   my $option_pulsegen_triggermode;

Then in the Perl subroutine read_cmd_line we add the options to be read in to the call to GetOptions():

   "pulsegen-level1=s" => \$option_pulsegen_level1,
   "pulsegen-width1=s" => \$option_pulsegen_width1,
   "pulsegen-delay1=s" => \$option_pulsegen_delay1,
   "pulsegen-level2=s" => \$option_pulsegen_level2,
   "pulsegen-width2=s" => \$option_pulsegen_width2,
   "pulsegen-delay2=s" => \$option_pulsegen_delay2,

This allows the values to be read from the command line and placed into memory. They must then be passed on to PulseGen{}.

Passing data to PulseGen{}

Now that PulseGen{} can read in values, each parameter must be checked and passed on to the PulseGen{} object. We do this by using a simple if statement that checks whether a variable has been defined and then passes on a value to SSP. A block similar to the following must be made for each parameter to be accepted byPulseGen{}. Here is an example for setting width1 in PulseGen{}:

   if (defined $option_pulsegen_width1)
   {
      my $pulsegen_inputclassname = "pulsegen";

      my $inputclass
         = {
               module_name => "Experiment",
               options => {
                  command => $option_pulsegen_width1,
                  name => "pulsegen set to $option_pulsegen_width1",
               },
               package => "Experiment::Pulsegen",
            };

      my $inputs
         = [
            {
               component_name => "$model_root/segments/soma",
               field => "WIDTH1",
               inputclass => $pulsegen_inputclassname,
            },
         ];

      $scheduler->{inputclasses}->{$pulsegen_inputclassname} = $inputclass;

         if (!defined $scheduler->{inputs})
         {
            $scheduler->{inputs} = [];
         }

         push @{$scheduler->{inputs}}, @$inputs;
   }

—

Creating a SSP specification

For testing purposes, a SSP specification is created to check the functionality of the PulseGen{} object. A test will load a model, create a PulseGen{} solver object, then clamp the PulseGen{} output to the model’s membrane potential (V _m) at the soma. Although not biologically correct, this provides a good base case for a test.

First, a file pulsegen_freerun.yml is created as a large YAML hash. The simulation runs for 200 steps, similar to the examples in Create a Heccer Test and the associated GENESIS 2 script :

--- !!perl/hash:SSP
apply:
  results:
    - arguments:
        - commands:
            - perl -e ’my $result = [ ‘cat /tmp/output‘, ]’
      method: shell
  simulation:
    - arguments:
        - 200
      method: steps

Here, the PulseGen{} object is created as an input class and all of the parameters previously used in the Create a Heccer Test and GENESIS 2 scripts are assigned to it.

inputclasses:
  pulsegen:
    module_name: Experiment
    options:
      level1: 50.0
      width1: 3.0
      delay1: 5.0
      level2: -20.0
      width2: 5.0
      delay2: 8.0
      baselevel: 10.0
      triggermode: 0
    package: Experiment::PulseGen

The PulseGen{} object is then ”clamped” to the model’s soma.

inputs:
  - component_name: /Purkinje/segments/soma
    field: Vm
    inputclass: pulsegen
models:
  - modelname: /Purkinje
    solverclass: heccer
name: purkinje cell pulsegen

An output object double_2_ascii is then created that writes V _m to the file /tmp/output.

outputclasses:
  double_2_ascii:
    module_name: Experiment
    options:
      filename: /tmp/output
    package: Experiment::Output
outputs:
  - component_name: /Purkinje/segments/soma
    field: Vm
    outputclass: double_2_ascii

Here, the Model Container is invoked to load the desired model. Parameters for the Model Container can also be set in this block:

services:
  model_container:
    initializers:
      - arguments:
          - filename: cells/purkinje/edsjb1994.ndf
            no-use-library: 1
          -
            - ssp configuration for edsjb1994 using pulsegen
            - -R
            - -A
        method: load
    module_name: Neurospaces

Finally, Heccer is invoked. The output granularity is set to 1 and the step size to 0.5 seconds. Again, in line with the previous examples:

solverclasses:
  heccer:
    constructor_settings:
      configuration:
        reporting:
          granularity: 1
          tested_things: 6225920
      dStep: 0.5
      options:
        iOptions: 4
    module_name: Heccer
    service_name: model_container

After saving the specification, the simulation is started with the command:

ssp pulsegen_freerun.yml

The expected output is then written to the file /tmp/output as declared in the specification.