www.neuron.yale.edu

Hi, Ted,
Excuse me for not posting another new thread.
Even though this is an old thread, it's really helpful and informative. So I just want to follow up with my questions here.
I'm now using COBA IF neuron in my project . For some reason, we need to make this COBA neuron more realistic. That is to say, once the membrane potential hits the threshold(let's say -50mV), can the membrane potential goes up further (for instance, to go to 20mV) by modifying the speakout.mod file ? We have refractory period in COBA, so can we do this: the first half of the refractory, the voltage goes to 20mV linearly or non-linearly from threshold , and drops to vrefrac at 0.5*refractory, after that, potential stays at vrefrac for another 0.5*refractory.
I've been thinking how to implement this for some time, but still, couldn't figure out how to do this.
Hope can have your suggestions and help on this.
Thanks in advance.

Sorry this reply is so delayed.

At the heart of the coba model cell is a point process called SpikeOut that acts like a triggerable single electrode voltage clamp. This clamp is controlled by a state machine that is implemented by a set of conditional statements in the NET_RECEIVE block of the NMODL code that defines the point process:The original SpikeOut has two states: OFF, during which it is waiting for a threshold crossing and the clamp's conductance g is 0 so it delivers no current, and ON, during which the clamp's conductance g is supposed to be large enough to force local membrane potential very close to vrefrac regardless of what other current sources (including synapses and voltage-gated currents) might be doing. Its INITIAL block contains the statements
g = 0
net_send(0, 3)
which makes the clamp's series resistance (1/g) infinite and launches a self-event with flag=3. The self-event returns at t=0, i.e. immediately, and activates the WATCH statement in the NET_RECEIVE block so that local v is monitored throughout the rest of the simulation.

Threshold crossing (v rising above thresh) launches a self-event with flag=1 that returns immediately. This causes execution of the contents of NET_RECEIVE's first conditional clause, i.e.
1. net_event(t) launches an "output event" that is picked up by whatever NetCons have this point process as their spike source
2. net_send(refrac, 2) launches a self-event with flag=2 that will return refrac ms in the future
3. g is increased to grefrac, and v is set equal to vrefrac.

Arrival of the self-event with flag=2 forces g back to 0, so the clamp delivers no more current to the segment to which it is attached.

Only a few changes are needed to accomplish your goal. The most important are in the NET_RECEIVE blockThis new state machine has three states: OFF, during which the mechanism is waiting for a threshold crossing and the clamp delivers no current, ON0 during which the clamp's conductance g is large and the command potential is set to vrefrac0, and ON1 during which the command potential is set to vrefrac1. In addition to executing the WATCH statement, NEURON's event system must now trigger three state transitions--from OFF to ON0, from ON0 to ON1, and from ON1 back to OFF--so the new mechanism needs four different self-events: one that arrives at t=0 and has flag=4 that is used to execute the WATCH statement, and self-events with flags=1, 2, and 3 to drive the state transitions.

As with the original SpikeOut mechanism, the new one has a post-spike refractory interval whose duration is specified by the refrac parameter. A new parameter p is introduced that controls the fraction of the refractory
interval that is spent in the ON1 state. If p=0, the clamp's command potential stays equal to vrefrac0 for the entire refractory interval; if p=1, the command potential stays equal to vrefrac1 for the entire refractory interval.

I call the new mechanism XSpikeOut; its source code is contained in the file xspikeout.mod which is one of the files contained in https://www.neuron.yale.edu/ftp/ted/neu ... ikeout.zip
Download and expand this file, compile the mod file, and use NEURON to execute init.hoc. This is a model of a single compartment cell with pas to which an IClamp and an instance of XSpikeOut have been attached. It includes a panel that makes it easy to change the XSpikeOut's parameters.

Notice that, in addition to the changes that give XSpikeOut its additional state and new parameters, I have also "bulletproofed" it, i.e. included code that traps nonsense parameter values.

Hi, Ted,

Thank you so much for you reply. Yes, I tried the code you sent, it works. The voltage is clamped at certain level once it crosses the threshold, for some period of time.
Instead of clamped at certain level, is there any methods to make the voltage goes linearly up to peak and down, after it reaches the threshold? Just like what happened in the realist HH model.
Another question, I don't think we can set membrane potential variable v arbitrarily, right? For instance, we cannot set v'=XXXX. But I noticed that in spikeout.mod or the latest one you send me xspikeout.mod, we can set v to any value at net_receive block. I couldn't understand why we can do this in net_receive block?

breakwave922 wrote:Instead of clamped at certain level, is there any methods to make the voltage goes linearly up to peak and down, after it reaches the threshold? Just like what happened in the realist HH model.

If the exact time course of membrane potential is all that critical to your application, just use the HH mechanism and stop tinkering with approximations. Look, there's a point at which this starts to get ridiculous, and you may be nearing that point. Remember that a model is only an approximation to a physical system, and that the only reason to include this or that complexity or feature into a model is if the complexity or feature is essential to the hypothesis that you are using the model to test. Also remember that every model makes enormous simplifying assumptions--most aspects of biology are omitted from any model of a biological system. So if you're imagining adding this or that feature, stop and ask yourself whether it is essential or merely cosmetic.

Another question, I don't think we can set membrane potential variable v arbitrarily, right? For instance, we cannot set v'=XXXX. But I noticed that in spikeout.mod or the latest one you send me xspikeout.mod, we can set v to any value at net_receive block. I couldn't understand why we can do this in net_receive block?

Good question. Look closely at xspikeout.mod and you'll see that the statement
v = vrefrac
is preceded by a semicolon, which means that line is only a comment and is not executed. So v is never set equal to anything except at initialization, and that happens internally in NEURON, not in any mod file. The old spikeout.mod file does execute the statement
v = vrefrac
when an event with flag == 1 is received, but that really isn't necessary, and here's why:

An XSpikeOut instance generates a current that is given by the product
i = g*(v-vrev)
When g is very large compared to other ionic conductances and the loading effect of adjacent segments, the XSpikeOut acts like a single electrode clamp with command potential equal to vrev--it will very quickly pull v toward vrev in the segment to which it is attached.

Ted,
Thank you so much for your reply.
Yes. I just noticed that you commented out v = vrefrac in xspikeout.mod.
Just one more question about this COBA cell. About that WATCH statement, I saw you replied to other questions, stating that "A WATCH statement only needs to be executed once, during simulation initialization." I couldn't understand this. When initialization, WATCH statement is executed, because flag is set to 4. Then, as time evolved, voltage changes. Once the voltage cross threshold, flag is set to 1. This means, WATCH statement has always been in effective before threshold reached, right? After threshold, flag is set to 1,2 and finally 3, which completing a spiking cycle. But it seems WATCH statement is needed for the next spike. If it's not executed, how come the next spike happen?
COBA cell works fine for me. But regarding this part of the code, I always feel confused.

breakwave922 wrote:About that WATCH statement

It will be very informative to changetoThen recompile the mod files, run a simulation, and see what happens.

Hi, Ted,

Yes, I ran the simulation after adding that printf statement, and noticed that flag=3 only executed once upon initialization.
Does this mean, once WATCH statement is executed, it's always monitoring the voltage? It's like some program always working at the backstage, but needs kick-off at the beginning. Otherwise, how does the net_event(t) broadcast each spike?
Sorry for my not familiar with the WATCH statement.
Thank you.

Execution of a WATCH statement during initialization tells NEURON's standard run system to check, at each fadvance(), for a positive-going threshold crossing by a specifed variable. This effect of a WATCH statement lasts only until the next initialization.