Cluster hardware best practices for NEURON

[tcleland]

Hi folks. This is a hardware configuration question for best use of parallel NEURON.

Assume that I am running parallel NEURON on a Beowulf cluster, and want to interactively work with NEURON while not on the head node of the cluster. That is, I am connecting to the cluster over ethernet. I would like to see graphical output as if I were at the head node. There are a few options for this that I envision, but wonder which in people's experience is best.

for clarity: 'Head node' here refers to the console that is physically part of the cluster and on the same rack; 'console' refers to wherever the human is sitting, which might be the head node or might be a remote workstation connected to the cluster over ethernet.

* Have the console on which I am working be nominally a part of the cluster, acting as [another] head node, even though it is some distance away and probably on a slower (100bT or even 10bT) ethernet connection. Most tasks would be delegated to the nodes that are closely attached to each other on the cluster proper, but display would occur on this remote console. This solution requires that the console be running the same OS as the cluster and have the necessary cluster tools installed, so it requires a dedicated workstation and isn't good for checking in on a simulation from a random computer or for enabling multiple remote users to make use of the cluster.

* Connect to the head node over VNC, NX, or another remote video connection system. Graphics would be slow, but possibly manageable. Better over 100bT than slower connections.

* Run an X server on the head node and connect to it from remote consoles using X. Graphics display would be local (so not slow), and one could tune in to the same simulation from multiple remote sites (that can be running any operating system that has an X client). But I don't know if NEURON graphics will display well over X Windows remotely -- I assume they will, but can anybody confirm this for sure?

* Use a KVM solution to connect to the head node from a remote console -- very easy for a console in the next room, very expensive for a console elsewhere in the same building, impossible for out-of-building connections.

In the end, probably a mix of these will be used, but I would appreciate any advice or additional options/insights, and particularly would like to know if there are any problems displaying NEURON graphics on a remote X Windows client.

thank you!
Thom

[ted]

would like to know if there are any problems displaying NEURON graphics on a remote X Windows client.

There won't be any problems because there won't be any graphics in the first place. As of this date, the only parallel configuration in which NEURON's GUI is operational is multithreaded execution on a single workstation with multiple processor, shared memory architecture (e.g. using one of the Intel "multicore" CPUs).

The modus operandi on Beowulf clusters and massively parallel supercomputer architectures is to stores network activity for postprocessing analysis and display. Fortunately, with network models in which connections between cells are implemented with NetCons, this doesn't mean having to store the time course of every state variable. It is only necessary to store the spike time of each cell in the net. --just store the spike time of each cell in the net. Then the detailed activity of any subnet A can be recreated by implementing a model of just that subnet, and using the spike times recorded from non-A (the cells that constitute the remainder of the original network) to recreate the "afferent drive" to A (in a sense, recreating A's "synaptic milieu"). This involves use of something called PatternStim, but the only documentation and example of PatternStim of which I am aware is in
Hines M, Eichner H, Schuermann F (2008) Neuron splitting in compute-bound parallel network simulations enables runtime scaling with twice as many processors J Comput Neurosci 25(1):203-210
which has a preprint you can get from here
http://www.neuron.yale.edu/neuron/paper ... itcell.pdf
and an entry in ModelDB
http://senselab.med.yale.edu/ModelDB/Sh ... odel=97917

[tcleland]

That does make things conceptually simpler. Thanks, Ted. And for the PatternStim reference.

Thom