www.neuron.yale.edu

Posted: **Fri Jul 15, 2005 1:17 pm**

I would like to get an explaination for the behaviour demonstrated by this code (using NEURON v5.7). On my machine, the section diameters of the imaginary neuron are reported as 500 um before the shape display is created, but are correct afterwards.

Code: Select all

create dendrite[5]

dendrite[0] {
	pt3dadd(0,0,0,1)
	pt3dadd(2,2,2,1)
}

{dendrite[0] connect dendrite[1](0), 1}
dendrite[1] {
	pt3dadd(2,2,2,1)
	pt3dadd(4,2,2,2)
}

{dendrite[1] connect dendrite[2](0), 1}
dendrite[2] {
	pt3dadd(4,2,2,2)
	pt3dadd(4,2,5,1.5)
}

{dendrite[2] connect dendrite[3](0), 1}
dendrite[3] {
	pt3dadd(4,2,5,1.5)
	pt3dadd(10,0,0,2)
}

{dendrite[3] connect dendrite[4](0), 1}
dendrite[4] {
	pt3dadd(10,0,0,2)
	pt3dadd(12,0,0,1)
}

print "seg diameters before shape is created: "
forall print diam

objref s
s = new Shape()
s.show(0)

print "seg diameters after shape is created: "
forall print diam

We discovered this in attempting to use a morphology file from the Duke-Southampton archive (from which we adapted the syntax and structure for the example code). At the end of our script, the diameters will not update until we create a shape object. We have circumvented the problem for now by creating a shape object and then immediately discarding it. This works, but seems inelegant. I'd like to understand the underlying problem.

I suspect the documentation for "pt3dconst" holds some clues: "after a call to an internal function such as area() or finitialize(), the 3d point info will be used to determine the values of the segment diameters." So it appears that one must force the diameters to be updated by calling some "internal function", one of which must be called in the creation of a shape object. Is there a better way to do this?

Brad

Posted: **Fri Jul 15, 2005 4:57 pm**

NEURON keeps 3D data in internal data structures that respond
immediately in response to the various pt3d . . . statements. However,
determining effective diameters, areas etc. requires actual computation,
so for the sake of efficiency is deferred until a func or proc is called that
really needs such information, e.g. area(), finitialize(), or creation of a
Shape object. This way the time required to parse a list of pt3dadd
statements scales linearly with the number of statements. Other strategies
would be less efficient.

Merely invoking the name of a range variable, e.g. secname.diam, is not
a function call and therefore does not have the same effect as calling
area(), finitialize(), etc..

If you're not really going to run a simulation, the most efficient way to ensure
that all diam and L have been updated is to just call area(0.5).

www.neuron.yale.edu

failure to "update" diam

failure to "update" diam

Computation of effective L and diam is deferred