Finally: Network Modeling

Thu Sep 23 15:06:12 CEST 2010


After many struggles, a couple of rewrites from scratch of the discrete event system (DES), we recently got our first network model completely working. The spiker3 network which was already available as a low-level Heccer / DES test case, was converted to a high-level NDF model and then instantiated and run from SSP. Although it is a very simple test case with only one source and two target neurons, it proves that all low-level components are instantiated for correct simulation of this network model. Note that the model-container presents an abstraction of the model to DES making it transparant whether it is a network of multicompartmental neurons or of more abstract neuron models. I will equip SSP with a couple of network simulation templates (and likely will need to do some debugging here and there). But running network models with different stimulation protocols from a unix shell command line will now become easier than ever. Afterwards it will also become trivial to add commands for network models to the gshell.

From the technical point of view this means that the core functionality of the Neurospaces based simulation architecture has been finished. Documentation and tutorials still need to be developed, interfacing to the documentation system is on its way.

As a natural consequence, it is also time to revise the organization of GENESIS 3 development. In the past I have been the main contributor to the core of the code, but now, the core has been finished and only additions tangential to the existing functions are needed. Some of the these additions can be challenging (such as parallelization), but they will neither change the existing functionality nor interfaces. In other words, while I have been carrying Neurospaces and the core components of the architecture of GENESIS 3, now these components have been successfully finished. From here on development will focus on the GUI as an essential tool for tutorials, documentation and model publication. As a logical consequence, the role of each developer in this project needs to be revised too.

After a prototyping stage over the last year during which we integrated the (working) documentation system with the (prototype) GUI, the core design of the publication system is now in place. Build around sets of publication document snippets and an ontology for these snippets, we strongly believe we have all the essential ingredients to implement a extremely powerful GUI that integrates all of the Neurospaces software components with the documentation system. This will not only facilitate research simulation projects, it will also show the relationships between different projects (and their models). This system will help to accelerate knowledge production in a controlled manner. And that is why we are doing it.

NeuroML, NineML and Neurospaces / GENESIS 3

Two initiatives, NineML and NeuroML that compete for the same market that is so small that it does not exist yet. So no reason to get anxious nor excited about it. As long as they have complementary visions, under community control of course, this is a good thing and the future looks bright: as Ted Carnevale pointed out during the NeuroML meeting in Arizona: the competition between the Genesis and Neuron simulators has been beneficial for both, and at the same time these simulators have always been substantially different, serving different parts of the computational neuroscience community.

With the now mature core of the Neurospaces software components, I have focused development more on building interfaces of various sorts to create powerful links with external systems. Experimental interfaces implemented in the past include the Geometry libray and most importantly the interface with the Neuromorpho database.

I have worked on preliminary NeuroML and NineML interfaces in the new 'exchange' software component. This component connects directly to the API of the model-container such that G-3 has native NeuroML and NineML support (rather than indirect over XSLT as in G-2). Mando has a first interface between the GUI and the documentation system (although we will need to do some lining up of the interfaces between the GUI and other software components (gshell, documentation system and project-browser)).

So where do we go from here? The current roles in the G-3 team can be summarized as:

• Dave
  
  
  
  • GUI scripting in python (evaluation)
    
  • backward compatibility feedback
    
  • enhance and document debugging functionality of models and simulations.
    
  
  
• Allan
  
  
  
  • continue write documentation
    
  • specific GUI design documents based on Purkinje cell
    
  • develop relationship categories between computational models (different types of lineage ao.).
    
  • integrate this with the documentation tagging system
    
  
  
• Jim
  
  
  
  • GUI story board.
    
  
  
• Mando
  
  
  
  • lead of GUI development
    
  • packaging
    
  
  
• Zhiwei
  
  
  
  • read documentation
    
  • get familiar with software structure
    
  • get familiar with development processes and flows
    
  • interact with Mando
    
  
  
• Hugo
  
  
  
  • all the rest
    
    
    
    • network modeling (currently at 75%)
      
    
    
  • current focus on interfacing
    
    
    
    • continued SLI development
      
    • continued neuroml development
      
    • continued nineml development
      
    • pynn development
      
      
      
      • timed with the visit to the pynn code jam
        
      
      
    
    
  
  

Working bits and pieces of the Neurospaces / GENESIS documentation system

The Neurospaces / GENESIS 3 documentation system consists of a flat set of simple documents that are hyperlinked together. The main entry point into the documentation can be found here. The basic outline of the structure of the documentation can be found here. Most of the documentation is structured according to the GENESIS user workflow, a simple description of operations that a user executes when he simulates a model.

Today we had some fun identifying more flows through the documentation. As such there are vertical flows that go into depth, and horizontal flows that give an overview of concepts or technology. There is also a 'related pages' flow and a hierarchical flow (also known by software engineers as 'breadcrumbs').

The GENESIS documentation system has a convenient tagging system to implement all these flows. For example, the content page for level 1 documentation (high-level overviews), lists all published documents that have the named tag 'level1'. All the pages that are related to the model-container (allows for efficient internal storage of models), are tagged with 'related-model-container'. This makes it easy to identify and name different flows through the documentation and link those documents in a dynamically way using tools that understand the tags and create the appropriate HTML just-in-time.

By design, the documentation system also allows to tag and describe pages and documents that are not directly under our own control. For example, we can tag and link to scientific publications on other websites, or to documentation of software that is not maintained by us.

Anyway, as you can imagine, working on such a system is a lot of fun, especially with this team, and especially when everything starts to work...

Funding for continued GENESIS development

Last week we learned that GENESIS 3 development will receive additional funding. This funding was requested in the form of an administrative supplement to the original GENESIS 3 grant a couple of weeks ago. The money will be used to accelerate the development of documentation specific to GENESIS 3.

It is indeed a shame that there is so much software there, in the form of Neurospaces software components and software components specific to GENESIS 3, but it is still a mystery how to record channel response from a voltage clamp protocol, just one example. Not that this is difficult to do, there is actually a test case for it, but it is just hidden for users who are new to this system (meaning almost everybode out there).

The money of the administrative supplement should come in soon, in a couple of weeks. Both regular documentation, additional documentation infrastructure and tutorials will be developed.

About a week ago, we have made available the monotone repositories of the Neurospaces Studio and the Project Browser. The installer script 'neurospaces_build' can now seemlessly pull from these repositories, and create a directory structure required for Neurospaces development. Preparing a developer PC can now be done in a couple of minutes. The distributed nature of the monotone version control system starts to play a crucial role for such functions to work correctly.

Over last weekend, I have also started working on a simple replacement for the Genesis 2 SLI. This new software component called GShell, allows to construct simple models, and then export them to the Neurospaces NDF format , and an SSP configuration file. This provides a basic interface to the Project Browser.

The GShell is basically agnostic about how to create a model. Instead of having hardcoded constructs for Neuroscience models, it pulls information from the model container, and transforms it using meta programming techniques to perl code that talks to the model container and allows to construct a model. A model container specific to air flow simulations would allow to create models of air flow using the GShell. Obviously the model container of the Neurospaces project only knows about elements of neuroscience models.

Because of the use of meta programming techniques, the source code of the GShell is only about 800 lines of code, and it can instantiate any model supported by the model container.

Mando continues his work on the GENESIS 2 SLI: for some time, the target has been to get the classic Purkinje cell model to work because it uses different types of channels, has a complex morphology, and obviously because its behavior is well described and links nicely with experiments that have been done in the past. It seems like quite soon this model will work, from using the vanilla GENESIS 2 scripts. And for sake of completeness, this model obviously works already for a long time using Neurospaces NDF model files and SSP stimulation configuration files.

Last week I have worked a fair bit on the project browser, such that the morphology analyzer built into the model container can be accessed. This means that a project can have say 10 different morphology files in .p files or NDF files, and your webbrowser allows to examine the number of branchpoints between soma and terminal tips, compute cell surface area and other things. These operations can be applied transparantly on individual morphologies or groups of morphologies. The part to define the groups from the morphologies in the project still needs some work, right now I use a configuration text file in the YAML format.

One thing that became more and more clear over the last few days is that it would be good from a maintenance point of view to merge the project browser and the Neurospaces studio. From the user / installer viewpoint, this means that the Neurospaces project only ships one integrated GUI rather than two, which is obviously a good point too.

Starting to mature

With the Neurospaces project maturing and becoming more useful, I decided to start blogging on tangible progress of the software development. The intent is to give a weekly update, for myself and other people interested and participating in the project.

People somewhat familiar with the project know that we are currently focusing on single neuron modeling. This does not mean that network modeling is not supported, but instead that we are focusing on a complete toolchain that allows scientists to build single neuron models from scratch, explore their behavior, compare the results between alternative models.

Over the last few months, the Neurospaces software toolchain has been used for all the functions mentioned in the previous paragraph by scientists doing scientific research. Multicompartmental models as well as single compartment models have been used, from passive morphologies til active morphologies showing spike frequency adaptation due to the calcium dynamics.

We hope to do a first alpha release early next year. And as said, this alpha release will focus on single neuron modeling.

More to follow.