Announcement: GENESIS 2.4 beta tutorial at the Computational Neuroscience Meeting in Quebec City

This is a public announcement of the GENESIS-2.4 tutorial at the
Computational Neuroscience meeting (CNS) in Quebec City and the
official public beta release of GENESIS 2.4.  This new release
includes support for spike-timing dependent plasticity in large
networks of multicompartmental cells, bug fixes, comes with new python
utilities and tutorial materials.

The "Ultimate GENESIS Tutorial Distribution", included in this
release, contains updated course materials for the tutorial
Constructing biologically realistic neuron and network models with
GENESIS.

The tutorial brings together material that is available as separate
downloads from the GENESIS web site and through the GENESIS Users
Group. It includes several simulator-independent tutorials on
biologically realistic neural modeling, as well as both tutorial and
research simulations that have been implemented with GENESIS.

The latest version of this GENESIS tutorial distribution will be
available at http://genesis-sim.org/GENESIS/UGTD.html.

The GENESIS tutorial at the CNS meeting is introductory and aimed at
people who are new to or have only elementary knowledge about the
GENESIS-2 simulator, as well as those who have used GENESIS in the
past and would like to learn of new developments in cortical network
modeling with GENESIS.

* introduction and overview

** Why are we doing this?

** resources

** installation and configuration overview

* single neuron modeling and visualization

* debugging model and script

* fast simulations with hsolve

* network modeling

* spike-timing dependent plasticity

During the last hour of the tutorial, I will show in detail how to
technically debug models, scripts and source code, at various levels
of implementation.

The latest news can always be found at http://genesis-sim.org/GENESIS/

Sun Nov 11 11:51:33 CET 2012

Armistice Day, Remembrance Day or Veterans Day -- just choose the one you prefer ...  a new update ... after two years of silence ...

Things have happened -- for the good and for the bad.

Briefly: (1) there is now a new biochemical pathway solver, Chemesis-3 -- working but immature, (2) the network modelling functionality is now available from the gshell -- many thanks to Dave Beeman for his constant commitment for making this functionality useful and his understanding of the design of the system's infrastructure, (3) the python bindings have been further developed, thanks Mando, but they also have problems that need to be resolved -- we are using the gshell interface to implement a better and improved python API, (4) we organized a first workshop in Luebeck a couple of weeks ago -- some users tried interfacing with NeuroConstruct, with some success, (5) we got two papers accepted and published, and one in the pipeline (but unfortunately rejected for silly reasons so far -- a couple of years ago a reviewer of the same group gave us a 4/10 for English writing and figures ... guess what ... -- ah ... let's hope he leaves a comment here :-) science is about open discussion, conversation and convergence).

After pretty all of the core functionality has been finished, interfacing -- in the general sense of the word -- is now the highest priority for me.  Interfacing outward means graphics -- we have already done some work there: (1) Mando and Dave implemented a couple of python widgets that comply with the user workflow, (2) just recently I implemented a developer GUI that supports the developer workflows.  For sure, there is more to come here.  Horizontal interfacing is about interoperability with NeuroML / NineML, NeuroConstruct, PyNN and others.  So that's already started by user demand, see above.  Inward interfacing??  That's the essence of the CBI architecture, and, for instance, includes multi-scale modeling ... you can read about it here The CBI Federated Software Architecture.

Now, the bad news: my own personal situation and relation with G-3 development ...  Between October 2010 and November 2011 I was not being paid -- a complicated story, trials, blocked funding etc.  Then since November 2011, I am working for about 25% on G-3.  That is something, but not much.  Development has been very slow during the last two years and will continue to be slow if the situation persists the way it is today.  That's bad.

We hope that the competitive renewal that we just submitted will help -- but uncertainty is the master in sciences nowadays and those who master uncertainty have always the advantage.  I still hope that the uncertainty will never become a certainty -- that would require manager skills.

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.