Neurospaces Home Page

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

Welcome to the home of the Neurospaces project. (Terms and Conditions )

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

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:

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 1500 use case tests have been defined for the individual software components. Of course there are also many integration tests. The regression tester output can be found here.
Integrating different components, gives different flavors of the same simulator, and enhances the user experienced consistency when constructing, exploring and running multi-scale models.
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.

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:

GShell: an interactive front-end that integrates with other software components.
Heccer: a fast compartmental solver, a backend.
Dash: a second compartmental solver faster than Heccer, for simpler models.
Neurospaces Model Container: provides a solver independent internal and external storage format for models.
The Exchange Module:: provides the model-container with interfaces to XML based model descriptions such as NeuroML and NineML.
Discrete event system: consists of a discrete event distributor and queuer. This is used for abstract modeling of an action potential traveling inside an axon as a 'discrete event'.
SSP: a flexible scheduler written in perl, to run simulations with the Neurospaces model container and Heccer.
The Neurospaces Studio: some tools for graphical browsing and command line usage.
The Genesis Script Language Interface: a scripting component that reads Genesis 2 scripts and feeds them to the Neurospaces model container.
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 Developer 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 model database and simulation servers in a convenient way.

There is also a Neurospaces blog --> for the Neurospaces project.

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:

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 the model container 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 for the functionality of the model container.

Notes:

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.
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:

Can be driven from C, Perl, SSP, and can fetch the model parameters from the Neurospaces 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'. 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

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:

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'. 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

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:

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

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:

Uses declarative configuration files, and can be driven from scripts.
Integrates other components into a consistent API for user interfaces. SSP is not aware of the internal details of the model container or Heccer aware, but loads their functions on the fly, and only if 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 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:

Visualizes models stored by the model container.
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 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

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.
The Neurospaces model container uses 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 multi-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 D. Coop, James M. 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 D. Coop, James M. Bower: 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.
James M. Bower, Hugo Cornelis, Rachael Wilcox: Comparative Evolutionary Computational Analysis of Cerebellar Purkinje Cell Structure and Function (poster presentation, Computational Neuroscience Meeting, July 2009).
Allan D. Coop, Hugo Cornelis, Armando Rodriguez, James M. Bower: Using GENESIS 3 for single neuron modeling (poster presentation, Computational Neuroscience Meeting, July 2009).
Documents the capabilities of the GENESIS 3 simulation and documentation systems.
Allan D. Coop, Hugo Cornelis, Fidel Santamaria: Using mutual information to quantify the contribution of dendritic excitability to information processing in a Purkinje cell model. Frontiers in Computational Neuroscience (2009, submitted).
A paper that uses the GENESIS 3 simulation system to conveniently run thousands of research simulations with the project browser.
Hugo Cornelis, Allan D. Coop, James M. Bower: Python as a Federation Tool for GENESIS 3 (in preparation, 2009).
Documents the use of the Python programming language to establish the CBI as a open and federated software architecture.

© 1999-2016 -- All material on this website, including figures and presentation, is copyrighted 1999-2016 by Hugo Cornelis unless otherwise noted. Please contact the author for more information. (Terms and Conditions )

Last modified: Sun Feb 21 09:52:44 CET 2016