Thanks for a tough question, porio. Working out the answer taught me a lot. First of all,
I discovered that my initial suggestion wasn't going to work. The hoc file that is emitted by
the Channel Builder uses a bunch of objrefs to set up the internal data structures that
NEURON uses to simulate the channel. However, the very last statement in that hoc file
is {objref ks, ksvec, ksgate, ksstates, kstransitions, tobj}, which destroys the links
between these objrefs and the internal data structures. Result: you have a new object
class that you can treat like any other point process class, but hoc can only see the
public members of this class--which are Nsingle, g, gmax, i, e, and the gating states
themselves. There is no obvious way to get at the parameters for the equations that
govern the state transitions.
A little digging reveals that the parameters are actually stored as elements of Vectors,
so in theory one could access them from hoc using statements of the form
print Vector
.x[j]
Vector.x[j] = somevalue
But this means using the "unique name" of an object, which is a bad idea. Quoting from
chapter 13 of The NEURON Book:
Object references vs. object names
Up to this point we have been using object references to refer to objects, emphasizing
the difference between an object itself and what we call it. Actually, each object does
have a unique name that can be used anywhere a reference to the object is used.
However, these unique names are primarily intended for use by the library routines that
construct NEURON's graphical interface. While it may occasionally be useful to employ
these unique names in user-written code (e.g. for diagnostic or didactic purposes),
this should never be done in ordinary programming. Object names are not guaranteed
to be the same between different sessions of NEURON unless the sequence of
creation and destruction of objects of the same type is identical. This is because the
object name is defined as classname[index], where the "index" is automatically
incremented every time a new instance of that class is created. Index numbers are
not reused after objects are deleted except when there are no existing objects of
that type; then the index starts over again at 0.
So to change rate parameters from hoc, we need to use aliases. To make aliases
available, the KSChan must be managed by a Channel Builder. Here's how:
Code: Select all
(this isn't really code; I'm just using this "code block" to preserve the indented
formatting of the following outline)
Get the channel specification into a Channel Builder
nrngui sthcn.hoc
NEURON Main Menu / Build / Channel Builder / import KSChan / sthcn
Aliases exist only when requested by the user, so
ChannelBuild[0] / Properties / Provide transition aliases
For future use, save this Channel Builder to a session file
with aliases enabled
File / save session / sthcn_with_aliases.ses
Use a graph's Plot what? to discover the alias names
NEURON Main Menu / Graph / Current axis (this does not require a default section)
Graph's menu box / Plot what?
Plot what? / Show / Objects
scroll down list in first column to ChannelBuild_
double click on ChannelBuild_ -->
ChannelBuild_ appears in text edit field at top of Plot what?,
and 0. appears in Plot what?'s middle column,
double click on 0. in middle column -->
edit field changes to ChannelBuild[0].,
and middle column shows a list of names
double click on aliases. in middle column -->
edit field changes to ChannelBuild[0].aliases.,
and right column shows aC202., aCC2., etc.
double click on aC202. in right column -->
edit field changes to ChannelBuild[0].aliases.aC202.,
and right column shows A, d, k
So the "complete" names of these three parameters are
ChannelBuild[0].aliases.aC202.A, ChannelBuild[0].aliases.aC202.d, etc.
-------- an aside --------
Well, we don't have to refer to Vector
(good because we and the GUI are liable to
create lots of Vectors, so we especially want to avoid referring to Vectors by their
unique names). We still have to refer to a particular ChannelBuild object, but at least
creation and destruction of ChannelBuild objects is something that is completely under
our control, and isn't going to be done automatically by the GUI or runtime library.
If we had a lot of point process ChannelBuild objects, and especially if they controlled
different kinds of channels, we'd probably want to use Lists to manage them (i.e. for
each kind of channel, there would be a List whose elements were each instance of
that channel). That would make it easy to iterate over all instances of a particular
kind of channel, in order to specify their properties.
-------- end of aside --------
Testing what we think we know about aliases: type one of them at the oc> prompt
and see if hoc returns its value--
Code: Select all
oc>ChannelBuild[0].aliases.aC2O2.A
0.0067
So it works.
For your particular channel model, the forward rate parameter aliases are
ChannelBuild[0].aliases.aCO.A
ChannelBuild[0].aliases.aC2O2.A
ChannelBuild[0].aliases.aCC2.A
ChannelBuild[0].aliases.aOO2.A
and the backward rate parameter aliases are
ChannelBuild[0].aliases.bCO.A
ChannelBuild[0].aliases.bC2O2.A
ChannelBuild[0].aliases.bCC2.A
ChannelBuild[0].aliases.bOO2.A
and we have enough information to set them all from hoc.
Now we need a custom proc init() that will assign the proper values to these, depending
on celsius. A first stab at this, using the temperature dependence that you are
assuming, is
Code: Select all
proc setrates() {
qv = 4^((celsius - 22)/10)
ChannelBuild[0].aliases.aCO.A = 0.0015*qv
. . . plus statements to assign values to the 7 other rate terms . . .
}
proc init() {
setrates()
finitialize(v_init)
}