Main Neurospaces logo

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

Welcome to the home of the Neurospaces project.

This web page reflects the status as for project version alpha of the Neurospaces project.

Download the software Documentation Source Code Repository HTMLified browsable source code Doxygenized APIs Automated Use Case Menu Vision Blog

Loading

Introduction

The GEneral NEural SImulation System, GENESIS for short, started as a very advanced software application for biologically accurate neuronal modeling in the late eighties. Besides being used as a neuronal simulator it was also applied to various domains outside computational neuroscience. At present the software contains ill-structured and duplicate code, inconsistencies prevent automated regression testing and there is currently a general, yet logical, lack of engagement in the neuroscience community to further contribute and extend the source code of this application (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:

The Neurospaces project embodies many software components that all have been developed in full isolation. The core of the most important components is finished. The current development focus has shifted from component integration to the support of specific use case with an emphasis on single neuron modeling.

This is a list of software components that have been developed or are under construction:

Together, these tools give the core for the upcoming GENESIS 3 GUI. Another alternative core for the GENESIS 3 GUI is Moose, developed in India by the group of Upi Bhalla.

Download:

The interactive shell, the model container, Heccer, SSP, the Studio, and the Developer Package can be downloaded here. Other packages will be available for download soon.

The source code of the latest version of available packages is accessible in a source code repository. More information can be found here.

If you find the Neurospaces project interesting or useful, you can always let us know.

Neurospaces Model Container

The Neurospaces Model Container is used as an abstraction layer on top of a simulator and deals with biological entities and end-user concepts instead of mathematical equations. It provides a solver independent internal storage format for models to allow user invisible optimizations of the numerical core. By 'containing' the biological model, the model container reliefs the implementation of the numerical core from the software implementation pressures typically associated with heterogeneously structured data such as dendritic morphologies.

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:

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

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 the Neurospaces Model Container.
  2. Just recently the memory performance of the Neurospaces model container 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 the model container.

A word about the history of the Neurospaces model container.

The model container is constantly undergoing regression tests. You can see the output of these tests here.

These tests give an idea of the functionality of the model container as an internal storage format for biologically realistic models.

The Exchange Module

The Exchange Module is a system for convenient interfacing to XML based model descriptions such as NeuroML and NineML.

Heccer

The optimization of a neuronal solver consists of ultimate accuracy and performance. Transforming complex biological parameters into precomputed tables and optimizing for a high CPU cache hit ratio are the most important features for a good solver, and gives the solver a performance boost of about a factor four to six (the Neuron simulator has recently taken the same approach).

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:

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

An alternative way to run models very fast is by limiting the complexity of the modeled biology. The Dash compartmental solver is not as sophisticated as Heccer, but can easily be used for network simulations. This solver was contributed to the Neurospaces project by Allan D. Coop (see publications for more information).

Features:

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

DES: the discrete event system

The Discrete Event System is used for abstract modeling of action potentials. This functionality is needed for running network simulations. Action potentials generated at the soma of one neuron, are translated to a discrete event, that is delivered at a synaptic target of a connected neuron. The DES component borrows ideas from previous research in discrete event simulation.

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:

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

The model container, Heccer and DES are stand-alone components. They need to be glued together before they are useful. Besides that, they also need to be activated correctly, such that they can work together on a single simulation. This is exactly what the SSP scheduler does. The Simple Scheduler in Perl, activates other software components according to a configurable schedule. Because the SSP scheduler does not have any computational load, its implementation is very simple, and configurable. It is actually the configuration that instructs SSP to load the model container and Heccer, and to activate them for a simulation. Other configurations will connect SSP to other modeling services or solvers. SSP achieves this by loading on the fly those software modules referenced in its configuration. Other modules are not loaded.

Below is a typical configuration file for SSP. It first configures SSP to use the model container for internal storage (called Neurospaces for legacy reasons). It then instructs SSP to load a model called 'cells/tensizesp.ndf', and to instantiate a solver called 'Heccer' for that part of the model ('/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 these entries in any order.).

--- !!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
      
Below is a slightly enhanced SSP configuration file. Additionally, this file also shows how to pass specific options to Heccer: Heccer will give a small report after every time step in the simulation, and the time step is set to a new value. This configuraton file also specifies the output classes and actual outputs of the simulation. The specified outputs are written to a file in the file system (in this case using a default filename).
--- !!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:

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 the Neurospaces model container and Heccer.

Neurospaces Studio

The Neurospaces studio has a GUI front-end to the Neurospaces model container and allows browsing and visualization of the model. Note that the Neurospaces studio is not a graphical editor or construction kit. I prefer to rely on external applications for this type of functionality, a good example is neuroConstruct.

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:

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 shrinkage correction is done 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
      

And now again, but with shrinkage correction:
$ 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
      
So when applying shrinkage correction, you get fewer spiny dendrites that get fewer physical spines. Nevertheless the compartments are longer, such that more surface correction for the spiny dendrites has been done. Read the documentation of the GENESIS cell reader (specifically the section on spines) for more information on how exactly the spines get attached to a morphology and how dendritic surface scaling works.

It is also possible to calculate total dendritic surface, or total dendritic spine surface:
$ 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 
      
Now you can easily compare the total dendritic surface area, and compare it with the total spines area, and see if your model makes sense.

Here is the command line I use when looking for segments with a particular combination of diameter and length. As you can see I am not interested in segments from spines:
$ neurospaces cells/purkinje/edsjb1994.ndf --traversal-symbol / --reporting-field LENGTH --reporting-field DIA --type 'segment' --condition '$d->{context} !~ /spine/i' | less
      
Instead of using 'less' or 'more' to browse the results, you can obviously also do a 'grep' or feed everything to a file and then open the file in a editor. This tool obviously supports many other use cases.

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.

Genesis 3 Shell

The Genesis 3 Shell is a simple replacement for the Genesis 2 SLI. It is not meant to be a full replacement, but rather allows to initiate modeling projects from scratch for both simple and complex models. The model description and simulation configuration can be exported to the project browser when the modeling project becomes mature. One of the main targets of the gshell is to become a communication abstraction layer on top of the model-container / Heccer / SSP.

You can see the output of the gshell tests here.

Genesis 2 Script Layer

The Genesis 2 Script Layer is a scripting interface that reads Genesis 2 SLI scripts and feeds them to Neurospaces software components. The Genesis scripts that create a model and run a simulation in Genesis, also create a model and run a simulation in Neurospaces.

From principle, this component is a reconfigured version of the Genesis 2 simulator that binds to Neurospaces components for the real work. It 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. The simulation itself is run by (a) Heccer instance(s).

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

The Output of the regression tests for the backward compatibility module can be found here.

Geometry Library

The Geometry Library is a general purpose geometry library, with some essential geometrical operators, not commonly found in other geometrical libraries. It gives a low-level data representation of 3D and 2D lines, and defines operations on them like volume, surface and intersection calculations. This library is meant to be a gateway for more complex operations too (like dendritic surface reconstruction from a stack of EM images).

Reconstruct Interface

The Reconstruct Interface reads XML files written by the Reconstruct software, and writes it out to Neurospaces declarative NDF format. This involves geometrical operations, so this interface relies on the Geometry Library. The interface allows to separate out contours with different tags.

Neurospaces Project Browser

The Neurospaces project browser is a set of modules for the Usermin web server. This allows you to browse projects, inspect, and compare simulation results or other data over a web interface.

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

The Developer Package contains the Neurospaces installer and developer tools that have emerged from developing Neurospaces software components.

Configurator Package

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 and simulator servers in a convenient way. The configurator package is used by developers to automate the synchronization of software code repositories, and is required to implement distributed model mining services.

Additional background information

Publications:


© 1999-2008 -- All material on this website, including figures and presentation, is copyrighted 1999-2010 by Hugo Cornelis unless otherwise noted. Please contact the author for more information.
Last modified: Wed Jun 22 22:18:27 CEST 2011