www.neuron.yale.edu

Dear Mike and Ted-

We continually see users attempting to change the currently accessed section using an "access" statement, which is often admonished as a "bad practice." Are there technical reasons why you guys can't ammend the usage/behavior so that it's acceptable to use "access" this way? The reason I ask is two-fold:

1. It's apparently natural for users to do this as we've seen it so many times.
2. It seems to "work" in every case I've run across.

But I don't know if it messes up the pushing and popping of sections and other nitty-gritty details that I don't like to think about if I don't have to. But from a usability standpoint, it might make things a little easier to have this "rule" relaxed if possible.

Another option is to get rid of it altogether if it really does cause problems (I guess there is a backwards compatability issue, which is a deal-breaker) and there are good alternatives (my strategy is to just make a SectionRef to my priveledged sections (ie somas)).

Brad

access is provided as a convenience so that there can be a default section. This should
be a "conceptually priveleged" section, i.e. some part of the model whose variables
and/or parameters are of particular importance to you, so you can refer to them by just
using the name of the variable or parameter. Code that has multiple access statements
has the consequence that an unqualified variable or parameter name, such as
v(0.5)
refers to a property of a completely different part of the cell.

If that doesn't bother you, think about the fact that many of NEURON's GUI tools
require that a default section exists. Here's a thought experiment: imagine that you're
using a program that, for the moment, has soma as the default section. Bring up a
voltage axis graph. Its plot list includes v(.5) which means soma.v(0.5). Now suppose
you call a proc in your program that asserts
access dend
and then you bring up another voltage axis graph. Guess what v(.5) means this time.

There is never a reason to use more than one access statement. hoc offers two
perfectly good methods for specifying which section you mean:
dot notation i.e. sectionname.attribute
and the "temporary section stack" forms
sectionname statement
and
sectionname { stmt1 stmt2 . . . }
These unambiguous forms are easy to write, read, and understand.

there are good alternatives (my strategy is to just make a SectionRef to my priveledged sections (ie somas)).

That escapes me--could you please explain how that helps manage the privileged
section?

--Ted

...could you please explain how that helps manage the privileged
section?

Well, when I say "mark a section as 'priveledged'", I mean that I make a SectionRef to it and explicitly refer to it with the sectionname statement method whenever I want to use it. I didn't mean to imply that I was somehow able to use a SectionRef instance in exactly the same way as an "accessed" section.

I see your point about all the built-in GUI tools using the default section, but this has always struck me as perhaps unecessary. I am always "forced" to access a section before I even open up the plot. The chain of events that often happens to me is

1. open hoc file that specifies morphology and some kind of run proc
2. select shape plot from the menu
3. DANG! I haven't accessed a section where I would gladly have just selected the single section from the shape plot anyway if given the chance
4. jump down to the oc promt, type access blah
5. continue...

Not that it's a terrible pain (not enough that I have felt compelled to complain about it; but I have considered altering nrngui just to see what happens if I remove the check for accessed section), but it's often a stumbling block for me and the way I use it and the conceptual model of the NEURON system I carry around in my head. I usually just want information from several sections anyway, not just the "priveledged" section, whose identity might actually change from run to run.

I am all for having it around for convenience, just that it's use is a little less powerfull than you might expect of an ideal case.

I hope the last part about abandoning it altoghether (this was an attempt to make the dialogue complete) didn't overshadow my question: Is it possible to make the NEURON environment properly handle multiple access statement, or is it just that it would merely destroy the concept of a priveledged section, and thus, it's utility?

Well, when I say "mark a section as 'priveledged'", I mean that I make a SectionRef to it and explicitly refer to it with the sectionname statement method whenever I want to use it. I didn't mean to imply that I was somehow able to use a SectionRef instance in exactly the same way as an "accessed" section.

Perhaps I am dense, but this doesn't seem to be an improvement on either dot notation
or the
secname statement
or
secname { stmt1 stmt2 . . . }
syntax.

I am always "forced" to access a section before I even open up the plot.

NEURON Main Menu / Graph / Shape plot
is one of the tools that requires a default section to exist. But do you even need a
shape plot? If you are merely trying to spawn a graph that shows voltage, current,
or some other variable vs. time, just write a bit of hoc code that spawns a graph and
plots the variable you want. If you're not sure about syntax, or need to see an example
of working code because the Programmer's Reference is too terse, do it once with the
GUI (bring up a Voltage axis, Current axis, or State axis graph and then use that
graph's Plot what? tool to specify the variable), and save that graph to a session file.
Then figure out how to write your own code by examining the contents of the session
file.

4. jump down to the oc promt, type access blah

Wow, a form of access abuse that I have not yet encountered. You're laying a series
of traps for yourself. This is a good way to create massive problems when you find it
impossible to reproduce your own results.

--Ted

I was just trying to bring up an issue that I've observed a few people "wrestle" with. I try to avoid using "access" in order not to abuse it (maybe overkill, but I like the "rigidness" required to explicitly specify my sections). If no one else has these issues, then I am more than happy to let it drop.

..this doesn't seem to be an improvement...

I must not be communicating myself well enough: In my code, I have exactly zero access statements. All section locations are specified with one of the two methods you have illustrated. If I have a "priveledged section" such as a soma, there's just a and if I want to do something to the priveledged section just etc. By my reading, this is one of the types of things for which this class was made. Now, I don't have to remember the actual name of my priveledged section (I just have to remember the generic name of my section ref) and I can change the priveledged section by changing just one line of code. For my purposes, this captures a large amount of the utilty of access.

Wow, a form of access abuse that I have not yet encountered.

It may very well be, but I only do that for quick, one-shot kind of scenarios where I want to do a preliminary exploration of something without writing a script, like "Can I generate a local spike here?" (just an example), etc. For anything more repetitive, I whip up a hoc file. But this kind of illustrates my point: an access statement loses its convenience if you can get into trouble (ie get spurious results) with it so easily. I don't think the scanario I gave is too outlandish, especially for a beginner, and the unsuspecting user does something quite reasonable, but it just might give you a wrong answer.

I am trying to look at it from a new user's perspective who has just worked through one of the tutorials. "Well there's 'access', that's how I move around." But better not abuse it, or your results are in question. Now, if we're lucky and they don't give up and go back to their pipettes and petri dishes, they've got to dive into to documentation and learn that sectionname.varname takes precedence ("Why is there a dot?"), followed by sectionname {stmt}, and then access. Suddenly a little excursion into neuron simulations becomes an exercise in computer science, where a little more lattitude in the usage of access might have been helpful.

I thoroughly enjoy using NEURON; it's a great tool and I am grateful that you make it available and listen to the grievances of the masses. Just trying to do what little I can to suggest improvements. If there are technical reasons why access can't be made to behave this way, so be it. If it's merely a convention, then maybe a redefinition could be useful.