e_extracellular=0 with finitialize()

[nikkip]

Hi,

I think it would make sense for finitialize() to zero all extracellular potentials if that mechanism is being used.

Nikki

[ted]

Why? e_extracellular is already 0 by default; one has to do something to make it nonzero. That being the case, if a user wants e_extracellular to have a particular value at t==0, why should finitialize() override that?

[nikkip]

Because when I do a parameter sweep (let's say I'm changing the stimulation amplitude), and I repeatedly call my stimulation procedure, the e_extracellular values will still be unchanged from the end of the previous parameter value, rather than being reinitialized to zero.

Nikki

[ted]

You may want finitialize() to force e_extracellular to 0, but that may not be what the next modeler (or the next 999 modelers) wants to do--e.g. somebody who is interested in the effects of a sustained extracellular potential gradient may want e_extracellular to vary with position during initialization and for all t>=0.

e_extracellular's default value is 0, so if it happens to be nonzero at the end of a simulation, that can only occur because some user-written code assigned a nonzero value to it at some point in that simulation. If that user wants e_extracellular to be 0 at the beginning of the next simulation, it's up to that user to make that happen. If the perturbation of e_extracellular was implemented with Vector play, that should be easy to accomplish--just make the first elements in the driving vector and the associated time vector be 0. If the perturbation was implemented with events, then it's just as easy to undo with one or more assignment statements executed by an FInitializeHandler.

[nikkip]

But if a modeller would want e_extracellular initialized to non-zero values, they will explicitly initialize it as appropriate for their simulation. However, in my case, I assumed it would be initialized to zero, which thankfully manifested itself in a visibly incorrect results. I then knew I had to hunt for the problem. Specifically:

1) Run a simulation with stim.amp=1
2) Start the next simulation with stim.amp=2: Initialize to steady-state using the code on p. 197 (Section 8.4.2) of the NEURON book by calling finitialize() and taking large fixed time steps from t<<0 to t=0.

However, during this steady-state initialization, I had e_extracellular!=0 leftover from the first simulation, and since finitialize() didn't reset e_extracellular=0, my steady-state initialization was doing weird things to my gating variables, then causing spurious action potentials when I started the actual simulation for t>0.

[ted]

during this steady-state initialization, I had e_extracellular!=0 leftover from the first simulation, and since finitialize() didn't reset e_extracellular=0, my steady-state initialization was doing weird things to my gating variables

Yes, that would really mess things up, but I don't see how it could happen if you are using Vector play to drive e_extracellular. The first statement in proc init() is finitialize, and finitialize resets Vector play. Suppose you are using a "step function" waveform that is defined by this pair of vectors
objref evec,tvec
evec = new Vector(4)
tvec = new Vector(4)
evec.x[0]=0
evec.x[1]=0
evec.x[2]=1
evec.x[3]=1
tvec.x[0]=0
tvec.x[1]=1
tvec.x[2]=2
tvec.x[3]=3
i.e. for the first ms the played value is 0, and for t>=1 it becomes 1. finitialize forces the played value back to 0, and the "steady state initialization" code then jumps to t < 0 so the played value stays at 0 throughout the initialization run.

[nikkip]

Fair enough. I'm just not currently using Vector.play() to apply my stimulus.

[ted]

So set e_extracellular to 0 with whatever method you are using to change the value of e_extracellular.