Friday, November 14, 2008

Integration of solvers using Neurospaces

subject: a soliton solver and a compartmental solver

Just wanted to clarify something that was brought up yesterday during our journalclub.

So what I said was that it is a bad idea to integrate a soliton solver (fluid dynamics, hyperbolic partial differential equations) with a compartmental solver (parabolic partial differential equations), because the structure of the equations and their solutions is very different.

This does not mean that integration with neurospaces / G3 is a bad idea. The only thing to pay attention to, is that one has to keep the code base of the two solvers entirely separate, for ease of development / maintenance / testing. During simulation, both are coupled by an appropriate communication framework that comes with neurospaces / G3.

Such a situation is very close to the TMS stimulation engine that Reese and I have worked on.

This is very different from hsolve of G2 where all kinds of solvers and their internal communication mechanisms share a single entangled code base (and development ceased).

So again, it is just a matter of modular design,

Ah and BTW. before I forget to mention: this also facilitates optimization. I recently added a very simple optimizer to the SSP scheduler, and it runs about 30% faster now. Single neuron simulations on G3 run faster than on G2.

This will be posted on the neurospaces blog.

Tuesday, November 4, 2008

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.

Saturday, November 1, 2008

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.