The logos are courtesy of Amanda Pasquali (thanks, Amanda !)

Introduction

The GEneral NEural SImulation System, GENESIS for short, started as a very advanced software package in the late eighties, for biologically accurate neuronal modeling. Besides being used as a neuronal simulator, it was also applied to various domains outside computational neuroscience. Right now, the package contains ill-structured and duplicate code, inconsistencies prevent automatic testing and there is currently a general, yet logical, lack of engagement in the neuroscience community to further contribute to the package (who wants to contribute if nobody else can tell what is and what is not correct and respects the fundamental design philosophy of the code ?). One of the core problems responsible for this situation, is that GENESIS is a monolithic software system, implementing many different user-visible functions.

The Neurospaces project is a departure from the monolithic software system design. It is a development center for software components of computational neuroscience simulators. There are many advantages of developing independent software components:

• Interfacing to an individual component is obviously more simple than interfacing to a do-all monolithic system. The compartmental solver developed for the Neurospaces project (Heccer) can be connected to Matlab fi.
• It simplifies the individual components and encourages other developers to get involved.
• It allows for separate testing of the components. More than 1000 use case tests been defined for these software components, including integration tests.
• Integrating different component, gives different flavours of the same simulator, and enhances the user experienced consistency when doing multilevel simulations.
• A component based software system avoids vendor-lockin. Its life-cycle is more smooth than that of a monolithic system, because software components can be upgraded one at a time.

• Heccer: a fast compartmental solver, a backend.
• Dash: a second compartmental solver faster than Heccer, for simpler models.
• Neurospaces Model Container.
• Discrete event system: consists of a discrete event distributor and queuer. This is used for abstract modeling of an action potential as a 'discrete event'.
• SSP: a flexible scheduler written in perl, to run simulations with Neurospaces and Heccer.
• The Neurospaces Studio: some tools for graphical browsing and command line usage.
• The Genesis Script Layer: a scripting layer that reads Genesis scripts and feeds them to Neurospaces.
• The Geometry Library is a general purpose geometry library, with some essential geometrical operators, not commonly found in other geometrical libraries.
• Using the Geometry Library, a Reconstruct Interface has been written. This interface supports the conversion of contours exported by the Reconstruct software to the Neurospaces declarative NDF format.
• The Neurospaces project browser for browsing projects and inspecting simulation results.
• The Installer package contains the Neurospaces installer and developer tools that have emerged from developing Neurospaces software components.
• The Configurator package contains configuration utilities for the other tools. It is not needed for the other tools to work properly. Rather, it allows to set up database servers in a convenient way.

• There is also a wiki at googlecode for the Neurospaces project, with information for developers.

Some software engineers have expressed interest in what methodology and technology I use for Neurospaces development. You can find more information here.

Download:

Neurospaces, Heccer, SSP, the Studio, and the Installer can be downloaded here. If you find the Neurospaces project interesting or useful, you can always let me know (I reply to all my email).

Other packages will be available for download in a couple of months.

Neurospaces Model Container

The Neurospaces model container API abstracts away all the mathematical and computational details of the simulator. Optimized to store large models in little memory -- it stores neuronal models in a fraction of the memory that would be used by conventional simulators -- it allows for automatic partitioning of the model such that simulations can be run in parallel. From the modeler's side, Neurospaces will be able to import and export NeuroML files, facilitating exchange of models and ideas, and fostering computational neuroscience.

Features:

• Covers from the network level down to the mechanism level. The perl interface converts and reads in GENESIS .p and SWC morphology files. It converts such models to active models when needed (e.g. it can reproduce an exact match with the Purkinje cell model, see purkinje cell model ).
• Defines models in a purely declarative, extensible language.
• Keeps and maintains a conceptual 'algorithmic' representation of the model, as well as an expanded representation of the model.
• Knows about biological entities like cells, populations and projections (note that for simulators such entities are sometimes commands instead of biological entities).
• Annotates the structures and concepts of the model with biological, physics and mathematical quantities.
• Supports setup of the most complicated mathematical solvers. In principle, supports transparant setup of multiscale models and simulations (this is work in progress, see also the references at the bottom of the page).
• Gives different views on the same network model. These views are visualized in the GUI. Take a look at the screenshots.
• Knows about specific parameters vs actual parameters, e.g. specific membrane capacitance vs scaled membrane capacitance. Put more generally, the biological objects in neurospaces rely on their parent, children and siblings to infer a number of their own properties.
• Allows for arbitrary nesting of network models, including nesting of projections and populations.
• Allows to inspect the connectivity of a network model in an intuitive way.
• Stores huge models in little memory, needed for full model inspection and automated validation (the more complicated the model the more efficient the compression scheme (from the theoretical perspective the compressed image scales logarithmically with the original)).
• Can save and reload connections between components. Costly computation of connections has to be done only once.

The presentation given at the CNS2006 meeting gives a good view and feeling of the functionality of Neurospaces.

Notes:

1. This presentation was given before Heccer existed. Replace Hsolve with Heccer and the global picture looks the same (the reason Hsolve was replaced with Heccer is explained in a brief section about history of Neurospaces.
2. Just recently the memory performance of neurospaces was proven to be more than 1000 times more efficient than that of GENESIS when storing a Purkinje cell population. This additional efficiency is in agreement with predictions based on the data structures that are used by Neurospaces.

A word about the history of Neurospaces.

Neurospaces is constantly undergoing regression tests. You can see the output of these tests here.

These tests give an idea of the detailed functionality of Neurospaces as a data container.

Heccer

Heccer is a fast compartmental solver, that is based on hsolve of the GENESIS simulator. The numerical principles implemented in Heccer are described here. Why Heccer is much more efficient that many other compartmental solvers currently available is explained here.

Heccer can be instantiated from C, or from Perl (or other scripting languages). It is also possible to link Heccer directly to Matlab. Heccer comes with Swig interface definitions, such that linking Heccer to any other technologies should be easy.

Adding new channel types to Heccer can be done using callouts. The callout mechanism allows for general user extensions that contribute a current or conductance at a particular time in a simulation. Heccer automatically integrates this contribution into the membrane potential.

The source code of Heccer contains inline developer documentation. There is no stable API yet, but the Swig interfaces for Heccer are not expected to change much. If you are interested in this, look at a simple example for driving Heccer from perl, and another example with active channels and a calcium pool. Heccer is currently capable of simulating purkinje cells (see purkinje cell model ), and, at first evaluation, runs slightly faster than hsolve (It is difficult to assess why exactly: while the hsolve implementation is much more optimized than Heccer's, the Heccer design is slightly better optimized than Hsolve's.).

Based on the mentioned sets of documentation, more extended documentation will be assembled when the time is ripe.

Features:

• Can be driven from C, Perl, SSP or the model container.
• Computes the behaviour of single neurons.
• Integrates Hodgkin-Huxley alike channels.
• Integrates exponentially decaying calcium concentrations and nernst potentials. Interfaces will be provided for more elaborate calcium models.
• Can operate in a 'passive-only' mode, what means that all channels in a model are ignored with exception of the synaptic channels.
• Tables to speed up computations, are generated and optimized on the fly.
• All parts of the model with the same kinetics share tables automatically.
• Computes the contribution of one channel type to the overall dendritic current, e.g. the contribution of all calcium channels or the contribution of all persistent calcium channels.
• Can serialize the current neuron state to an external stream for later resuming the simulation (or for multiple use).
• In combination with the previous point, can be initialized from external sources.
• Can be used with or without the Neurospaces model container. To use Heccer without the Neurospaces model container, configure the package with the command line './configure --without-neurospaces' (currently broken, sorry folks). To use Heccer with the model container, the model container must be installed before Heccer is compiled.

Heccer has been validated with a purkinje cell model and produces an exact match with hsolve (see purkinje cell model and the purkinje cell tutorial in the GENESIS simulator distribution). Heccer is constantly undergoing regression tests. You can see the output of these tests here.

These tests give an idea of the functionality of Heccer as a compartmental solver.

Besides being open source, Heccer is also hypersource. The Heccer source code can be browsed here. An example test file with points of entry into Heccer, can be found here.

Dash

Features:

• Can be driven from C, Python, SSP or the model container.
• Computes the behaviour of single compartment neurons in large networks.
• Integrates dual-exponential and alpha equations with the cable equation.
• Tables to speed up computations, are generated and optimized on the fly.
• Can be used with or without the Neurospaces model container. To use Dash without the Neurospaces model container, configure the package with the command line './configure --without-neurospaces' (currently broken, sorry folks). To use Dash with the model container, the model container must be installed before Dash is compiled.

Dash is currently being integrated with the other Neurospaces software components.

DES: the discrete event system

From a software architecture viewpoint, DES is a separate solver: it simulates action potential propagation in an efficient way. Splitting this functionality from the rest of the simulator, facilitates customization for modeling of sophisticated learning rules, especially related to STDP, diffusion and spillover.

Internally, the discrete event system contains two subcomponents, one component for event distribution that contains a connectivity matrix, a second component for event queuing.

Features:

• delivers a single event to many targets.
• queues the event whenever applicable.
• allows for easy customization, e.g. to associate 'secondary' data with a connection, like weight, delay and other data specific for the model.

Note: at the time of writing this component is distributed as part of the Heccer package. This is likely to change in the near future.

SSP

Below is a typical configuration file for SSP. It first configures SSP to use Neurospaces as the modeling service. Then, it instructs SSP to load a model called 'cells/tensizesp.ndf', and to instantiate a solver called 'Heccer' for a part of the model (namely '/tensizesp'). The simulation of the model is run using the 'apply' entry in the configuration file (note that the order in the configuration file is alphabetical, not chronological. A user may specify the entries in any order that he chooses.).

--- !!perl/hash:SSP
apply:
  simulation:
    - arguments:
        - 10
        - 1
      method: steps
    - arguments:
        - 0.1
      method: advance
models:
  - modelname: /tensizesp
    solverclass: heccer
name: tensizesp
services:
  neurospaces:
    initializers:
      - arguments:
          -
            - ./example
            - -P
            - tests/cells/tensizesp.ndf
        method: read
    module_name: Neurospaces
solverclasses:
  heccer:
    module_name: Heccer
    service_name: neurospaces
      

--- !!perl/hash:SSP
apply:
  simulation:
    - arguments:
        - 1000
        - 1
      method: steps
    - arguments:
        - 0.1
      method: advance
models:
  - modelname: /pool1_feedback1
    solverclass: heccer
name: pool1_feedback1
outputclasses:
  double_2_ascii:
    constructor: Heccer::Output
    module_name: Heccer
outputs:
  - component_name: '/pool1_feedback1/segments/main[0]'
    field: Vm
    outputclass: double_2_ascii
  - component_name: '/pool1_feedback1/segments/main[0]/Ca_pool'
    field: Ca
    outputclass: double_2_ascii
services:
  neurospaces:
    initializers:
      - arguments:
          -
            - ./tests/perl/pool1-feedback1
            - -P
            - tests/cells/pool1_feedback1.ndf
        method: read
    module_name: Neurospaces
solverclasses:
  heccer:
    constructor_settings:
      configuration:
        reporting:
          granularity: 100
          tested_things: 6225920
      dStep: 1e-06
    module_name: Heccer
    service_name: neurospaces
      

Features:

• Uses declarative configuration files, and can be driven from scripts.
• Integrates other components into a consistent API for user interfaces. SSP is not Neurospaces or Heccer aware, but loads the external libraries on the fly, when needed.
• Allows to set options for the backends (e.g. the time step of integration for Heccer).
• Has hooks for setting model parameters before the model is run. This can be used for parameter searches (e.g. see neurofitter).

SSP is constantly undergoing regression tests. You can see the output of these tests here.

These tests are SSP stand-alone tests, and integration tests with Neurospaces and Heccer.

Neurospaces Studio

Additionally, the Neurospaces studio comes with a shell command that uses the Neurospaces model container Swig bindings to get access to the model stored by the model container.

Features:

• Visualizes models stored by Neurospaces.
• Allows to query a model from a shell command line.
• Is being used for a Purkinje cell comparison study, yet still under construction.

The studio is a necessary part of the project browser. It is being used at this moment for a purkinje cell comparison study. Below is an example of the command line tool to inspect the delayed rectifier conductance after conversion of a passive purkinje cell morphology to an active model. Also note how neurospaces does shrinkage correction on the fly.

$ neurospaces morphologies/genesis/gp_pc1.p --shrinkage 1.111111 --traversal-symbol / --reporting-field G_MAX --condition '$d->{context} =~ /kdr/i'
calling morphology2ndf  --shrinkage 1.111111 morphologies/genesis/gp_pc1.p >/tmp/i0a37qeDQl
neurospaces: No errors for /tmp/i0a37qeDQl.
/gp_pc1/segments/soma/kdr->G_MAX = 6000
/gp_pc1/segments/p0b1[0]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1[1]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1[2]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1[3]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1b2[0]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1b2b2[0]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1b2b2[1]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1b2b2[2]/kdr->G_MAX = 600
/gp_pc1/segments/p0b1b2b2b2[0]/kdr->G_MAX = 600
Traversal ok
      

A second example, showing how many spines get attached to the morphology:

$ neurospaces morphologies/genesis/gp_pc1.p --spine Purk_spine --algo Spines
calling morphology2ndf  --spine-prototypes Purk_spine --shrinkage 1 morphologies/genesis/gp_pc1.p >/tmp/3YWitXpVmH
neurospaces: No errors for /tmp/3YWitXpVmH.


SpinesInstance          Spines__0__Purk_spine :
-----------------------------------------------
        Number of added/virtual spines : 1984/131729.077346
        Number of tries (adding spines) : 1984
        Number of failures (adding spines) : 0
        SpinesInstance prototype : Purk_spine
        SpinesInstance surface : 1.33079e-12
      

$ neurospaces morphologies/genesis/gp_pc1.p --shrinkage 1.111111 --spine Purk_spine --algo Spines
calling morphology2ndf  --spine-prototypes Purk_spine --shrinkage 1.111111 morphologies/genesis/gp_pc1.p >/tmp/mCz74N5CvO
neurospaces: No errors for /tmp/mCz74N5CvO.


SpinesInstance          Spines__0__Purk_spine :
-----------------------------------------------
        Number of added/virtual spines : 1969/145163.160838
        Number of tries (adding spines) : 1969
        Number of failures (adding spines) : 0
        SpinesInstance prototype : Purk_spine
        SpinesInstance surface : 1.33079e-12
      

$ neurospaces morphologies/genesis/gp_pc1.p --shrinkage 1.111111 --spine Purk_spine --traversal / --type '^T_sym_segment$' --reporting-field SURFACE --cumulate
$ neurospaces morphologies/genesis/gp_pc1.p --shrinkage 1.111111 --spine Purk_spine --traversal / --type '^T_sym_segment$' --reporting-field SURFACE --condition '$d->{context} =~ /Purk_spine/i' --cumulate 
      

$ neurospaces cells/purkinje/edsjb1994.ndf --traversal-symbol / --reporting-field LENGTH --reporting-field DIA --type 'segment' --condition '$d->{context} !~ /spine/i' | less
      

The Neurospaces studio is constantly undergoing regression tests. You can see the output of these tests here.

These tests give an idea of the functionality of the Neurospaces studio for examining complicated neuronal models.

PS: most (but not all) of this front-end used to be distributed with the Neurospaces model container, for legacy reasons. This introduced ambiguity in the packaging system, and a number of installation problems. Factoring out the studio solves those problems.

Genesis Script Layer

From principle, this component is a specific version of the Genesis simulator that binds to Neurospaces components, and delegates all model construction statements to the Neurospaces model container, delegates simulation management statements to SSP, and delegates statements related to temporal accuracy to Heccer.

GUI and XODUS related statements are under consideration for support to.

This component is currently under construction.

Geometry Library

Reconstruct Interface

Neurospaces Project Browser

The specific aims of the project browser are introduced in the presentation given at the model sharing workshop at the CNS*2007 meeting in Toronto.

The project browser uses distributed version control mechanisms to physically distribute your project. The coupling to a web server allows to inspect your simulations and compare results, regardless of location. You can take a look at the screenshots.

Installer Package

Configurator Package

Additional background information

• The Neurospaces project develops software components that match with the CBI simulator architecture, which is also used in GENESIS 3 as a common framework. Despite the apparant size of this project, already many components have been developed and integrated into a working simulator (more information to follow, yet see also the poster presentation at the Society for Neuroscience Meeting, November 2007)
• The Neurospaces project encompasses an increasing number of projects. So correct and consistent deployment becomes more important. The autotools do a lot of things automatically. I try to develop tools that are compliant with the Filesystem Hierarchy Standard.
• Neurospaces uses a mixture of XML indexing and node identification techniques. I should give a pointer here to relevant background information.
• At the data modeling level, none of the lower-level tools presented here make a difference between data and meta-data, because it is in the end the application that must make this difference. As a result, all data formats developed for the Neurospaces project allow easy information extraction from the application data as well as the application 'meta-data'. If such statements are more like English Chinese to you, and you think it is important to understand these subtle differences, see e.g. this entry in wikipedia. In neuroscience modeling, these differences are extremely important, simply because any model has numerous builtin assumptions about its immediate environment. So there is no explicit separation possible between the different dimensions of the data.

Publications:

• Allan D. Coop, George N. Reeke Jr.: The Composite Neuron: A Realistic One-Compartment Purkinje Cell Model Suitable for Large-Scale Neuronal Network Simulations. Journal of Computational Neuroscience 10(2): 173-186 (2001)
  explains the capabilities of the Dash compartmental solver.
• George N. Reeke Jr., Allan D. Coop: Estimating the Temporal Interval Entropy of Neuronal Discharge. Neural Computation 16(5): 941-970 (2004))
• H. Cornelis and E. De Schutter, Neurospaces: Separating modeling and simulation, Neurocomputing 52-54: 227-231 (2003)
  http://www.tnb.ua.ac.be/publications/pub065/Cornelis_NeuComp_03.pdf
  Explains the Neurospaces design goals.
• H. Cornelis and E. De Schutter, Neurospaces parameter handling, Neurocomputing 58-60: 1079-1084 (2004)
  http://www.tnb.ua.ac.be/publications/pub081/CornelisNC04.pdf
  Explains algorithms that allow (1) to access models in an intuitive way, and (2) to optimize the memory use of Neurospaces. The latter is actually a preparation of partitioning algorithms for large models, see below.
• H. Cornelis, Examining Neuronal models with Neurospaces studio (poster presentation at Wam-bamm 2006).
• H. Cornelis and E. De Schutter, Neurospaces: towards automated model partitioning for parallel computers (Neurocomputing Volume 70, Issues 10-12, June 2007, Pages 2117-2121, http://www.sciencedirect.com/science/article/B6V10-4MC12J2-6/2/809ad2a06d0761296cff8133b96272b5).
  Explains a partitioning algorithm to enable transparant parallelization of large heterogeneous simulations.
• Hugo Cornelis, Huo Lu, Angelica Esquivel and James M. Bower, Modeling a single dendritic compartment using Neurospaces and GENESIS-3 (poster presentation, CNS 2007).
  Reports about a multiple scale computational neuroscience project, using tools of the Neurospaces project.
• Hugo Cornelis, Huo Lu, Julia S. Georgi and James M. Bower, Comparative computational study of cerebellar Purkinje cell form and function (poster presentation, Society for Neuroscience Meeting, November 2007).
  Reports about a project that compares the passive electrical properties of Purkinje cells of 5 different species. In total 120,000 simulations were run in about four weeks of time. The Neurospaces project browser was crucial to run and manage the simulations, analyze the results, and visualize color-coded representations of the morphologies.
• Hugo Cornelis, Michael Edwards, Allan Coop, James Bower: The CBI Architecture for Computational Simulation of Realistic Neurons and Circuits in the GENESIS 3 Software Federation (poster presentation, Computational Neuroscience Meeting, July 2008).
  Establishes the relationships between the CBI architecture, the GENESIS 3 neuronal simulator, and the Neurospaces project.
• Hugo Cornelis, Allan Coop, James Bower: The Role of the Neurospaces Project Browser in the GENESIS 3 Software Federation: Design and Targets (poster presentation, Computational Neuroscience Meeting, July 2008).
  Documents the capabilities of the Neurospaces project browser, the interfaces, the file distribution mechanisms.