www.neuron.yale.edu

Dear all,
I used NEURON+Python a lot during my PhD, I am using it a lot, I will keep using it a lot and I like this combination. But I also love to deconstruct/reconstruct things, so I am wondering how NEURON could be completly recoded in pure python or cython. How would you start such a project? Do you know someone already trying to do that? I would like to start by recoding the core of NEURON, namely the part which solves the differential equations.
Cordially
Romain

In some ways that is a daunting prospect because of all the variations of methods involved to deal with high performance in special circumstances. E.g. threads, mpi cluster, multisplit for load balance, global variable time step, local variable time step, integration over minimum NetCon delay interval, all the spike exchange special circumstance optimization choices, gap junctions in a parallel environment, and computing with a gpu. And nmodl should be superseded by something at the python level. It turns out that the ReactionDiffusion extensions are being written in Python and I hoping it is possible to do all (or most) future extensions in python as well. Probably the major requirement at the user level is the replacement of InterViews by a Python GUI.

Romain: It certainly is an interesting (and, as hines says, daunting) prospect, I imagine if pure Python was used there would be major performance issues. Having said that, there are several libraries written in C with Python bindings which might make life a lot easier.

Hines: Would a GUI be necessary? I get the feeling that in NEURON modelling there is a move away from GUIs, however I could be mistaken.

vellamike wrote:Would a GUI be necessary? I get the feeling that in NEURON modelling there is a move away from GUIs, however I could be mistaken.

Mistaken indeed. The GUI is an excellent entry point for nonprogrammers; abandoning it would be a great way to make NEURON the favorite tool of a small and dwindling circle of "experts." Those who ignore NEURON's GUI (often individuals justifiably proud of their programming skills before they started using NEURON) are deliberately depriving themselves of key tools whose functionality would be difficult if not impossible to replicate by writing one's own code. Examples include ModelView, Import3D, Channel Builder, Linear Circuit Builder, and the CellBuilder and Network Builder (excellent for the quality of the cell class definitions that they generate).

NEURON users who start with the GUI, then go on to serious modeling projects, naturally tend to do more and more with code as their programming skills eveolve, but they still find the GUI very helpful for debugging, rapid development, and interactive analysis and understanding of models developed by others.

Dear Ted and Vellamike,

I agree with Ted; removing the GUI would be a mistake, I still remember my marvel when I saw the first spike generated by a NEURON model (a souvenir almost as sweet as the first time I witnessed a real spike).
But Vellamike is right, the NEURON GUI despite its richness is underused and many new tools are developed without it, the best solution to make everybody happy might be to refresh the GUI.
Indeed, this is one of the reason why recoding in python could be useful. Enthought and others have developped amazing tools to build very efficient GUI in no time (see for ex:http://code.enthought.com/projects/traits_gui/).

An example: there are many useful tools already existing in the GUI, but I spent quite an extensive time of my life fighting with the pointprocess manager. The number of synapses to be placed correlates exponentially, however, with the time (I) spend on this menu. In theory, we could wrap every hoc bits into python objects and then use them in the interface; in practise it is (I think) faster (and cleaner) to recode everything in PYTHON and directly interface it with c libraries.

P.S for Vellamike: What are these C libraries you are talking about? Don't you think that numpy would be sufficient?
Best,
Romain

romain.caze wrote:the NEURON GUI despite its richness is underused

That's probably a result of lack of user knowledge more than anything else. Code tends to be better documented than GUI tools because writing code means exercising declarative knowledge, and declarative knowledge is inherently easy to communicate in words. Using GUI tools involves exercising procedural knowledge, description of which is hard to create without being either too concise or mindnumbingly detailed.

many new tools are developed without it

Could you please name three that are (or should be) widely known? Maybe we should start building a list of these.

Enthought and others have developped amazing tools to build very efficient GUI in no time (see for ex:http://code.enthought.com/projects/traits_gui/).

Great for creating new tools. I'm not so sure it can be used to replicate the functionality of many existing tools, or whether the effort would be worth it. My particular favorites--which would be difficult to replicate or do without--are the Channel Builder, CellBuider, Impedance tools, Network Builder, Linear Circuit Builder, Model View, Import3D, Variable Step Control, and Parallel Computing tool. And I guess also the Print and File Window Manager.

Apropos of which, here's a challenge for any who wish to accept it: use any toolkit with Python or any other programming language to replicate the functionality of one of the most underrated tools--NEURON's built-in, Interviews-based Graph class. Specifically, create a new object class whose instances can display plots of one or more dependent variables against an independent variable, in the course of a simulation, and replicates the following features of the Graph class, which are accessible either by mousing around and clicking on the graph or by executing code:
Crosshair
Plot what? (which displays a browsable list of variable names and object classes that may have plottable attributes)
Pick vector
Color brush
Axis type
Keep lines
Erase
Move text
Change text
Delete
View = plot
Set view
Zoom in and out
New view
Translate
Scene = view
For the sake of fairness, that list omits about 10% of the Graph class's features, on the premise that "90% of the job takes 10% of the effort." That should make the job 90% easier! One more requirement: after a user customizes an instance of this new class, the user must be able to, at the click of a mouse button, export a text file that contains statements that, when executed, will recreate a duplicate instance with all customizations intact.

An example: there are many useful tools already existing in the GUI, but I spent quite an extensive time of my life fighting with the pointprocess manager. The number of synapses to be placed correlates exponentially, however, with the time (I) spend on this menu.

Avid GUI user that I am, I wouldn't imagine trying to use more than a very few PointProcessManagers with any model. Indeed, I can't recall ever using more than 4 instances of the PointProcessManager at one time. The PointProcessGroupManager
(NEURON Main Menu / Tools / Point Processes / Managers / Point Group)
is only a bit less cumbersome. Try to imagine painting a scene at a park using lots and lots of little pastel dots, one dot at a time . . . oh, somebody did that already.

A completely different metaphor is required. My opinion is that GUI-based direct management of N individual items becomes very tedious when N exceeds about 5. At that point I usually steal reusable code from the GUI, and switch to algorithms and object oriented programming using lists.