www.neuron.yale.edu

Posted: **Fri Jun 20, 2014 5:38 am**

Issue when updating nseg via custom init()

I was trying to test my model for certain calculated parameters with various values of nseg. The calculations required me to record voltage as well as time using vectors. It seemed appropriate to implement such an exercise using loops. But I encountered some weird (because I couldn't explain it) behaviour. After a run, the voltage vector shows the correct contents but the time vector turns out to be empty.

I tried developing a simple model in order to track down the source of the error, and having located the code responsible for it, I am still at a loss to understand its origin.

Here is the relevant hoc file:

Code: Select all

load_file("nrngui.hoc")

create cell
GLOBAL_nseg = 5

cell {
	L = 10
	diam = 5
	
	nseg = 51
}

proc init() {    
	finitialize(v_init)
	
	//----------------------------------
	nseg = GLOBAL_nseg	
	//----------------------------------
	
    if (cvode.active()) {
      cvode.re_init()
    } else {
      fcurrent()
    }
    frecord_init()
}

objref recv, rect

proc runSim() {
	rect = new Vector()
	recv = new Vector()
	
	rect.record(&t)
	recv.record(&cell.v(0.5))
	
	tstop = 5
	run()
	
	print "nseg = ", nseg
	print "rect.size() = ", rect.size()
	print "recv.size() = ", recv.size()
	print ""
}

xpanel("Run Simulation")
	xlabel("Run Simulation")
	xvalue("nseg", "GLOBAL_nseg")
	xbutton("Run & Record", "runSim()")
xpanel(100, 600)

Run the model using "Run & Record" button on panel.
There are quite a few interesting cases, so I will list them out:

1> With nseg <= 25 (odd number) on the GUI, output is:

oc>nseg = 5
rect.size() = 1
recv.size() = 201

2> With nseg > 25 (odd number) on the GUI, output is:

oc>nseg = 101
rect.size() = 201
recv.size() = 201

3> With > nseg < 51 (even number) on the GUI, output is:

oc>nseg = 50
rect.size() = 201
recv.size() = 1

4> With nseg > 51 (even number) on the GUI, output is:

oc>nseg = 100
rect.size() = 201
recv.size() = 201

5> Running with nseg <= 25 (odd number) on the GUI twice in succession, output is:

oc>nseg = 5
rect.size() = 1
recv.size() = 201

nseg = 5
rect.size() = 201
recv.size() = 201

I managed to avoid the error by two methods:
a) Removing the nseg assignment from the section specification
b) Removing the custom init() and directly using the GUI to update 'cell.nseg'
Also, all the error cases worked properly when run a second time in succession (e.g. case 5 above).

Several questions here:
Q1. Why does recording time (t) get affected with a change in value of nseg? I could foresee some issue in voltage recording involving change in the recording location with seg, but couldn't relate it to time.

Q2. Why does this effect arise for only a certain range of nseg values (here nseg <= 25)? From experimentation, I find that this range appears to be related to 1/2 the value of nseg defined in the section specification, e.g. for nseg = 25, it is around 12. No clue why so!

Q3. Also, why does the voltage vector also suffer for even numbered values in this range (<=25 here) and some what differently for double that range (25 to 51 here)?

I did read your comment on the forum that

Vector recording falls into the category that one might call "instrumentation code," but initialization belongs to the category of "simulation control code." Development and debugging are easiest if these categories are kept separate from each other.

I agree that it might be better to move my statements in the custom init() to runSim(), but I am still curious to know the origin of this behaviour.

Posted: **Fri Jun 20, 2014 5:39 pm**

If you change the system equations, you invalidate the previous initialization of the system equations. nseg specifies how many compartments are in the model, so changing nseg requires a new initialization.

Posted: **Sat Jun 21, 2014 7:12 am**

I am just surprised that changing nseg affected the recording of time 't' which I believe is independent of the number of compartments in a model. I could have expected the voltage vector to spring a surprise because of the change in system equations, but interestingly it records properly with the correct values. How is nseg affecting recording of time 't'?

Also, when you say...

changing nseg requires a new initialization

does this mean a call to stdinit() / init() / finitialize()?

Posted: **Wed Jul 02, 2014 4:54 pm**

An instance of a Vector.record is disabled when the variable it watches is freed. For voltage at 0.5, the memory is reused for any odd number of nseg but may be freed for an even number of segments.
It turns out that for purposes of associating t with the correct thread and local variable time step, vector.record(&t) is assocated with the first node of the currently accessed section. This node may be
freed in response to a change from a nseg enterned into your field editor back to 5 depending on wheter the first orginal segment contains the arc position of 0.1. Even if the recording is disabled
after finitialize, during finitialize a recording was done at time 0 and hence the size is 1.
Anyway, if you change nseg then you should also re-execute any Vector.record and play statements and then call finitialize again.

Posted: **Thu Jul 03, 2014 1:07 am**

Thanks, that explains it.
I was a bit perplexed as I didn't see it coming and found the issue arising when I changed nseg as (nseg=5; nseg<=51; nseg+=2) but not when (nseg=51; nseg>=5; nseg-=2). Not I can see that in the former case, the location of the initial first node might have been drifting towards inner segments, whereas in the latter I believe it always remains in the first segment.

www.neuron.yale.edu

Issue when updating nseg via custom init()

Issue when updating nseg via custom init()

Re: Issue when updating nseg via custom init()

Re: Issue when updating nseg via custom init()

Re: Issue when updating nseg via custom init()

Re: Issue when updating nseg via custom init()