Bug Report: starting varibles with an i

Suggestions for improvements to the NEURON Forum.
Post Reply
HPCGuy
Posts: 8
Joined: Thu Aug 19, 2010 10:17 pm
Contact:

Bug Report: starting varibles with an i

Post by HPCGuy » Fri Jul 06, 2012 10:12 am

An error I have been having revealed something that dictates good style as well as something that needs to be fixed-- don't start your variables with an 'i' and 'e' or end with an 'i'

For example 'in = 0' as I just found in a file that is part of neuron this conflicts with the standard that for an ion named n the current will be called 'in' as in: USEION n READ en WRITE in --

So when seeing 'in' in that file -- neuron complained that there was no n_ion inserted -- which normally doesn't come up, but sometimes it does...

The mod file that uses the n ion is: http://senselab.med.yale.edu/ModelDB/Sh ... 5Cican.mod... The file that wants the n_ion is mview/distinctparm.hoc

- Method to recreate the error:
>>> from neuron import h
>>> a = h.Section()
Try to open modelview
- Error Message:

Code: Select all

n_ion mechanism not inserted in section PySec_0x1043c90
/usr/arch/nrn/x86_64/bin/nrniv: 
 in mview/distinctparm.hoc near line 8
 in=0
     ^

 xopen("mview/distinctparm.hoc")
      xopen("mview.hoc")
    execute1("{xopen("mview.hoc")}")
  load_file("mview.hoc", "ModelView")
/usr/arch/nrn/x86_64/bin/nrniv: mview undefined function
 in mview/distinctparm.hoc near line 8
 {mview()}
          ^
        mview()
      execute("mview()")

ted
Site Admin
Posts: 5091
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Bug Report: starting varibles with an i

Post by ted » Fri Jul 06, 2012 10:55 am

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
for (x)
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>create dend
oc>access dend
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
1 
1 
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
0.5 
0.5 
0.5 
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.

hines
Site Admin
Posts: 1449
Joined: Wed May 18, 2005 3:32 pm

Re: Bug Report: starting varibles with an i

Post by hines » Fri Jul 06, 2012 11:03 am

The specific conflict involving 'in' has been fixed in
http://www.neuron.yale.edu/hg/neuron/nr ... e851bf347c

HPCGuy
Posts: 8
Joined: Thu Aug 19, 2010 10:17 pm
Contact:

Re: Bug Report: starting varibles with an i

Post by HPCGuy » Fri Jul 06, 2012 11:09 am

hines wrote:The specific conflict involving 'in' has been fixed in
http://www.neuron.yale.edu/hg/neuron/nr ... e851bf347c
Thank you very much

HPCGuy
Posts: 8
Joined: Thu Aug 19, 2010 10:17 pm
Contact:

Re: Bug Report: starting varibles with an i

Post by HPCGuy » Fri Jul 06, 2012 11:27 am

ted wrote: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?
Well the simple guard would be to suggest a coding convention that variables not start with 'i' or 'e'... Or at least in neuron source code. That would solve an issue like this. Indeed it is very much an outlier, but a plausible case that can be avoided. Most programming languages have recommended "good practice" docs. I was just suggesting it be placed there.

HPCGuy
Posts: 8
Joined: Thu Aug 19, 2010 10:17 pm
Contact:

Re: Bug Report: starting varibles with an i

Post by HPCGuy » Fri Jul 06, 2012 11:39 am

ted wrote:
By the way, the model specifications in this ModelDB entry have repeated instances of a real error: use of
for (x)
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()
Oh! Thank you very much -- I will take a look at that.

Post Reply