This is very much an "outlier example" and the error message received tipped you off to the naming conflict. What strategy might be applied that would guard against such rare occurrences, without imposing strictures elsewhere?
By the way, the model specifications in this ModelDB entry have repeated instances of a real error: use of
to iterate over nodes in order to specify spatial variation of a range variable. That is, at many points in IBcell.hoc and RScell.hoc there are statements of the form
for (x) abc(x) = f()
where abc is a range variable (typically the maximum channel density of a density mechanism) and f is a function of distance from a reference point. The problem is that for (x)
iterates over all nodes of a section, including the nodes at 0 and 1. Consequently, the last iteration attempts to assign a value to abc(1) but the value that is changed is abc(1 - 1/(2*nseg)), i.e. the value of the range variable in the "last" compartment in the section. This is because abc(somevalue) always refers to the value of abc at the nearest internal node. The deviation from the expected result can be quite large if nseg is small--for example:
Code: Select all
oc>nseg = 1
oc>for (x) diam = x // we (mistakenly) expect diam to be 0,0.5,1 at x=0,0.5,1
oc>for (x) print diam(x) // but diam turns out to be 1
oc>for (x,0) diam = x // for (x,0) iterates only over the internal node(s)
oc>for (x) print diam(x) // and the result is correct
This is all documented in the Programmer's Reference and the NEURON Book, but who reads manuals or checks their models to make sure that what's in the computer is a close match to what's in their head? Watch out for similar errors in other models by these and other authors. "Trust but verify."
The fix is to change NEURON so that attempts to assign values to range variables at 0 or 1 have no effect (and probably should also generate a warning message); this is planned for the near future, if it hasn't already happened in the latest development code.