My answers are often guided by the principle "better to teach how to fish than to give a fish." That was the point of including proc alldist() in my previous message. Don't just stick it, verbatim, into your own code. It's not a mystical incantation that must be recited word for word. It's an illustration of how to use distance().
Second, I see that your cell definition appears to use a template. Are you going to be working with model networks or models of individual cells? Templates are useful for network models, but that utility comes at the cost of introducing a host of programming complications that are best avoided during initial development and debugging of the individual cell classes. It is generally advisable to defer wrapping any particular cell model inside a template until the last instant, after it has been debugged and is ready to be incorporated into a network model.
Case in point:
Code: Select all
//Create section for channel reference
objectref s
s = new SectionList()
dend[0] s.append()
dend[1] s.append()
forsec s print secname()
This bit of code, stuck inside a template but not contained in a proc or func, will do nothing useful because it will be executed only when the template is parsed by hoc. It will never be executed again. It must be inside a proc or func, and that proc or func must be called each time a new instance of the class defined by the template is created. See what I mean about "complications that are best avoided"?
Code: Select all
dend[0] is connected to soma[1], so the distance calculation from somatic edge will be off by 1, correct?
Off by 1 what? Don't confuse soma[1] with location 1 on the soma. soma[1] is the name of a section; square brackets are used for indices, as when one declares multiple sections
create soma[2]
or multiple objrefs
objref foo[2]
Location 1 on the soma, on the other hand, is the "distal" end of the soma.
What is the "somatic edge", from the perspective of dend[0]? "The point at which dend[0] is attached to soma"?
In the model I'm using, gkbar drops off from distance to the somatic edge.
If that is the case for all sections other than soma, and if no sections are attached to the 0 or 0.5 location on the soma, you could just define the 1 end of soma as the origin for distance measurements
soma distance(0,1)
Then there is no need to subtract anything from any value returned by distance()
In proc setparam() don't forget that gkbar belongs to a density mechanism so you need to include that mechanism's suffix, e.g. for the hh mechanism the complete hoc name would be gkbar_hh.
In the channel .mod, gkbar is defined as a constant in the PARAMETERs. It is also mentioned in the RANGE. Will this override the .hoc calculation of gkbar
No, but you should check for yourself.
I assume gkbar should be deleted from PARAMETERs and moved to ASSIGNED?
Declaring a variable name in the PARAMETER block will make it appear in GUI tools such as the CellBuilder alongside widgets that make it easy for users to change its value. It will not appear in these tools if it is declared in the ASSIGNED block. By default, PARAMETERs are "global" i.e. have the same value in all segments of all sections in which the mechanism has been inserted. Declaring it as RANGE in the NEURON block means that it is allowed to have different values at all internal nodes of all sections, i.e. it is a "range variable". ASSIGNED variables are range variables by default.
To check that the dendritic conductance falls off as segment number increases, is there a print command that would allow me to check each segment individually, maybe something like "print dend[0] seg3 gkbar" ?
Starting from the example of proc alldist(), you could create a new proc that iterates over all internal nodes of all sections, printing each section name, the distance of the node from the reference point, and the value of your potassium conductance density. I'd suggest calling the new proc something like report(). The print statement would look something like this
for (x,0) print x, " ", distance(x), " ", gkbar_suffix(x)
where
suffix should be replaced by your mechanism's SUFFIX.
Another suggestion: use the ModelView tool (see link to tutorial at
http://www.neuron.yale.edu/neuron/docs).