Pre-determined spike train artificial cell

NMODL and the Channel Builder.
Post Reply
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Pre-determined spike train artificial cell

Post by Eelke Spaak »

I am building a model that I now want to adapt to include input from artificial spiking cells, rather than current input. The NetStim process seemed like a good place to start; however, I want to be able to change the spike times from HOC, to be able to later easily change the input to a variable-rate spiking cell.

The mechanism I came up with was to make a very simple SpikeTrain artificial cell:

Code: Select all

NEURON  {
  ARTIFICIAL_CELL SpikeTrain
  RANGE doSpike
}

BREAKPOINT {
    if (doSpike > 0) {
        net_send(0)
    }
}
and then, in HOC, create a vector that has, for each time step, a flag indicating whether the SpikeTrain should spike at that time or not, i.e. [0 0 0 1 0 0 1 1 0] etc. Then, using vec.play(&st.doSpike), the process would know when it has to spike. Using this mechanism, I would have full control in HOC over the spike times and would be able to adjust it easily without having to change the underlying point process.

However, I found out that it is not possible to call net_send() from a BREAKPOINT block, only from INITIAL and NET_RECEIVE. Is there any other way to have a process check a certain condition at a specified interval (1ms would probably be accurate enough) and then still be able to send an event in response to this? I thought about having a net_send() in INITIAL and then another one in NET_RECEIVE (so the process would keep sending events to itself), but of course then any NetCons hooked up to this process would also continuously receive these events.

Or am I attempting to do this in a completely wrong way?
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Re: Pre-determined spike train artificial cell

Post by Eelke Spaak »

I just realised that I could, of course, also use the NetCon.event() method to activate my synapses (and not use an artificial cell at all), but that would require a HOC check on each simulation time step, which is probably very slow.
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Re: Pre-determined spike train artificial cell

Post by Eelke Spaak »

Sorry to bother you all with this, I already solved it. I changed the SpikeTrain process to something even simpler:

Code: Select all

NEURON  {
  POINT_PROCESS SpikeTrain
  RANGE x
}
PARAMETER {
    x
}
And then I vec.play()-ed the SpikeTrain.x variable and had NetCon check it for passing a threshold of 0.5. This accomplishes exactly what I want: having a HOC vector determine the spike times of an artificial cell.
ted
Site Admin
Posts: 6289
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Pre-determined spike train artificial cell

Post by ted »

That is one way to deal with the problem. "Best practice," though, is to exploit the event delivery system, either by using an FInitializeHandler (see http://www.neuron.yale.edu/neuron/stati ... ithnd.html) to stuff the event queue during initialization, or (if the number of events to be stuffed is very large but they are separated by long times) to "stuff events on the fly" by using an FInitializeHandler in combination with cvode.event()--see
viewtopic.php?f=16&t=1327&p=4615&hilit= ... dler#p4615

I think I'll make that a new item in the "Hot tips" section of the Forum.
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Re: Pre-determined spike train artificial cell

Post by Eelke Spaak »

Thanks for you reply, I thought I'd let you know of my findings with the different methods of generating spike trains.

To examine whether or not it would be worthwhile (in terms of computational time) changing my (already working) implementation to the "best practice" one, I first did some tests on a very simple dummy 10s simulation consisting of a single compartment HH model that received the spikes of my artificial spike train. It turned out that the FInitializeHandler method (stuffing the queue on initialization, not on the fly) was 1/6 faster (2.5s vs 3s) than my play(&st.x) method, so I decided to adapt my model to this method.

However, the actual model I use would have to deliver about 24000 spike events, and I found that NEURON's memory usage jumped up to around 1GB (!) in this case, obviously not an ideal situation. So I decided to try the on-the-fly event queueing with cvode.event(). This method did not lead to excessive memory usage, but did result in an extremely slow simulation. After 5-10 minutes or so, I manually stopped the simulation. A simulation using my original method takes about 1-2 minutes (not exactly timed, just a guess).

So for now I am sticking with the "somewhat less good" practice :)
hines
Site Admin
Posts: 1682
Joined: Wed May 18, 2005 3:32 pm

Re: Pre-determined spike train artificial cell

Post by hines »

Back at the first post
vec.play()-ed the SpikeTrain.x variable and had NetCon check it for passing a threshold of 0.5
An alternative that would compress the Vector to just being a list of spike times is to use
nrn/examples/nrniv/netcon/vecevent.mod
(Edit first and change POINT_PROCESS to ARTIFICIAL_CELL)
I'd be interested in a performance comparison with that.

With regard to 24000 events on the queue using a GB of memory. That is certainly a bug and
I'll look into it. WIth regard to cvode.event taking excessive time, that is also unexpected if the
hoc handler is only accessing a Vector element but it would be quite a bit slower than the
above vecevent.mod method. Can you send me a zip file with all the hoc,ses,mod
files that exhibits th 1gb memory usage. It may be that the memory leak depends on details of the hoc
code. Send to michael.hines@yale.edu
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Re: Pre-determined spike train artificial cell

Post by Eelke Spaak »

I'm very sorry, I do not have that code anymore. I changed the code back to its working version and went on developing. Changing it back to the memory leak version is not really an option. I checked my automatic backups but they are also not relevant.
Eelke Spaak
Posts: 10
Joined: Tue Oct 21, 2008 4:43 am

Re: Pre-determined spike train artificial cell

Post by Eelke Spaak »

hines wrote:Back at the first post
vec.play()-ed the SpikeTrain.x variable and had NetCon check it for passing a threshold of 0.5
An alternative that would compress the Vector to just being a list of spike times is to use
nrn/examples/nrniv/netcon/vecevent.mod
(Edit first and change POINT_PROCESS to ARTIFICIAL_CELL)
I'd be interested in a performance comparison with that.
I've changed the code to using a modified version of vecevent.mod, and the performance is dramatically increased with respect to my custom SpikeTrain.mod solution, so thanks a lot! Simulations that used to take more than 5 minutes are now done in less than one.
Post Reply