Experiment Layer specification

[tclose]

Alex Cope was saying that SpineML already includes a rudimentary form of this but we may need to make it a bit more rigorous (while just aiming for something relatively modest at this point).

[apdavison]

We certainly need this. I have a strong preference for extending SEDML rather than rolling our own.

[tclose]

Could you draft up a list of SEDML (+extensions) tags you think we would need to support?

[iraikov]

One thing that seems missing or underspecified in SED-ML is the issue of specifying input waveforms or sources of spike events. Perhaps a minimal experimental layer could include a simple way of specifying a waveform or a list of spike times, along with a population mask/selector that applies the given stimulus to the specified population. This would allows users to generate a stimulus pattern (e.g. a Poisson spike train) and apply it to multiple simulation runs. I don't see how to do this in SED-ML currently.

[tclose]

NineML standards meeting provisional discussion:

Alex will look into this and come up with a proposal

[tclose]

The more I have thought about splitting the user layer into a composition and parameterisation layer (see #41), and then adding an additional "state" layer as Alex proposed (see #36) the more I think it is a good idea.

One reason I have just come to is that it makes designing (what I reckon will be) a pretty comprehensive experimental layer fairly trivial. What I have in mind consists of:

• a duration
• a model (consisting of composition & abstraction layers)
• initial parameterisation and states (parameterisation & state layers)
• "updates" at arbitrary time points using full or partial parameterisation & state layer descriptions.
• "recording" (maybe using XPath-like syntax to select model elements)
• "playing" to input pre-recorded (or experimental) data.

Something like this

<?xml version="1.0"?>
<NineML>
  <Experiment name="test">
    <Duration unit="ms">2000</Duration>
    <Model>
      <Reference url="www.opensourcebrain.org/MyNetwork.xml">MyNetwork</Reference>
    </Model>
    <ModelParameters>
      <Reference url="www.opensourcebrain.org/MyNetwork.xml">MyNetworkParameters</Reference>
    </ModelParameters>
    <InitialState>
      <Reference url="www.opensourcebrain.org/MyNetwork.xml">MyNetworkInitialState</Reference>
    </InitialState>
    <Update>
      <AtTime units="ms">100</AtTime>
      <NetworkState>
        <PopulationState name="mossyFibres">
          <ComponentState name="poissonTrain">
            <InRegime name="spiking"/>
          </ComponentState>
        </PopulationState>
      </NetworkState>
    </Update>
    <Record name="granule_voltage">
      <Element>granule_cells/v</Element>
      <Indices>
        <ArrayValue>
          <ArrayValueRow index="10"/>
          <ArrayValueRow index="20"/>
          <ArrayValueRow index="30"/>
          <ArrayValueRow index="40"/>
          <ArrayValueRow index="50"/>
        </ArrayValue>
      </Indices>
    </Record>
    <Play>
      <ListeningPort>granule_cells/neuromodulator</ListeningPort>
      <DataSource>
        <ExternalArrayValue url="..."/>
      </DataSource>
    </Play>
  </Experiment>
  <Unit symbol="ms" dimension="time" power="0"/>
  <Dimension name="time" t="1"/>
</NineML>

Events and step changes could be implemented by updating the regime from idle to active.

I haven't looked at SEDML so I don't know how close this is to what they have but what do you think?

[tclose]

Maybe this could be called the "Temporal Layer" to be explicit about what is and isn't included, i.e. all experimental apparatus, current injections, voltage clamps, etc.. would be included in the composition layer.

[tclose]

Here is the link to the SED-ML specification http://co.mbine.org/specifications/sed-ml.level-1.version-2.pdf

[tclose]

I have had a quick look at SED-ML to see how well it fits to our needs, which I will try to summarise a little bit here. A rough overview of the SED-ML structure (taken from the document above) is

• models
• simulations
  • algorithm (KiSAO ontology)
  • parameters
  • time course
    • initial time
    • output start/end
    • number of samples
  • "OneStep" update
  • Not an integration solver step, but a more conceptual update step
  • roughly analogous to a NEST minimum delay step (I think)
  • Steady-state
• tasks (in specified order of execution, including loops)
  • set values
  • ranges (over model elements)
  • uniform
  • vector (explicit)
  • functional
  • changes to values
• data-generators (post-processing of model output)
• outputs
  • plotting
  • reports

I think there are a number of issues/incompatibilities with the direction we had planned (or at least my take on it):

• SED-ML attempts to define the algorithm and solving methods (although we may want to borrow some ideas for "solver-hints" in annotations such as KiSAO)
• A lot of functionality that the tasks structures (setting ranges of values) is already part of the user (parameterisation)-layer
• Plotting and generating reports are probably outside the scope of what we are looking to implement
• Also may not be many uses for data-generators for the extra effort required to implement them. However, they are quite an interesting idea.
• Minor stylistic points
  • Relies on X-Path syntax, which may not be that applicable to non-XML formats for 9ML
  • Aesthetically designed to match SBML (plenty of "listOf*"s), which would jar slightly with 9ML

So although it is nice to use existing standards I would favour trying to take advantage of the proposed layer structure to come up with something lightweight like I have attempted above. However, I think there could be some good ideas we could borrow in the SED-ML design.