Page 1 of 1
Changing from deterministic to stochastic channels
Posted: Tue Dec 01, 2009 9:33 am
by willy
Dear NEURON developers,
I would like to replace the HH-like sodium channels in my model with stochastic channels. I used the kinetics of
http://senselab.med.yale.edu/modeldb/Sh ... odel=37857
and followed the ChannelBuilder tutorial
http://www.neuron.yale.edu/neuron/stati ... /main.html
As I understood it, for the Rubinstein approach, it would not be correct to implement just two gating processes
c_m <-> o_m with power = 3
and
c_h <-> o_h
yielding
g = g_max * o_m^3 * o_h
since the m-transitions are not treated as three separate events, right?
Anyway I received the error:
Code: Select all
/usr/local/neuron/nrn/x86_64/bin/nrniv: KSChan single channel mode implemented only for single ks gating complex to first power
near line 0
{set_single(single_)}
^
Does this mean the only possibility would be to transform the *inf and *tau parameters into the gating variables alpha and beta
inf = alpha/(alpha+beta)
tau=1/(alpha+beta)
==>
alpha = inf / tau *** CORRECTED 3.12.2009 ***
beta = 1/tau - alpha
and then use 8 states with 10 transitions as in
http://senselab.med.yale.edu/modeldb/sh ... odel=50391
Furthermore: for which reason did you choose to develop a different kinetic scheme for the potassium channels in the tutorials?
Thank you for your time!
Best regards,
Willy
Re: Changing from deterministic to stochastic channels
Posted: Tue Dec 01, 2009 11:50 am
by ted
willy wrote:As I understood it, for the Rubinstein approach, it would not be correct to implement just two gating processes
c_m <-> o_m with power = 3
and
c_h <-> o_h
yielding
g = g_max * o_m^3 * o_h
since the m-transitions are not treated as three separate events, right?
All I can say about the "Rubinstein approach" is "what's that?"
To implement a mechanism with stochastic gating in the Channel Builder, you must first express the mechanism as an ordinary Markov model i.e. a family of transitions between pairs of states of the form
state1 <-> state2
where the forward and reverse rates are functions of voltage or some ligand. Any HH-style representation of channel gating with integer exponents, such as m^3 h, can be expressed in an equivalent Markov form e.g.
Code: Select all
m0h0 <-> m1h0 <-> etc.
^
|
v
m0h1 <-> etc.
but the current design of the Channel Builder doesn't give you any help with that--you have to expand it yourself, and that includes making sure you get the relationships between rate constants right. Fortunately, if you find an existing stochastic channel mechanism implemented with the Channel Builder that has the right topology of state transitions, and the rate functions are of the same general form as what you need, you can save a lot of effort by starting with that and making whatever modifications are necessary to suit your needs.
for which reason did you choose to develop a different kinetic scheme for the potassium channels in the tutorials?
Just eliminating complexities that do not contribute to the primary aim of the tutorial, which is to teach about the Channel Builder. In other words, applying the KISS principle.
Re: Changing from deterministic to stochastic channels
Posted: Tue Dec 01, 2009 1:25 pm
by willy
Thank you for the quick response and sorry about my sloppy phrasing. I was thinking about
Comparison of algorithms for the simulation of action potentials with stochastic sodium channels.
Mino H, Rubinstein JT, White JA.
Ann Biomed Eng. 2002 Apr;30(4):578-87.
where slightly different implementations are compared. I wrote "Rubinstein approach" because I hoped there would be some way to use the "implicit" Markov form to describe a gating system like the classical m^3*h (eq.14 in the paper)
Code: Select all
c_m1 <-> o_m1
c_m2 <-> o_m2
c_m3 <-> o_m3
c_h <-> o_h
N_open = sum ( m_1,i * m_2,i * m_3,i * h_i) with i iterating over the number of channels.
If I'm not confused the first three transitions have the same rate constants alpha and beta, which would further simplify the implementation and allow to directly use the *inf and *tau expressions instead.
I will try the explicit implementation.
Thanks again!
Willy
Re: Changing from deterministic to stochastic channels
Posted: Tue Dec 01, 2009 1:42 pm
by ted
willy wrote:I wrote "Rubinstein approach" because I hoped there would be some way to use the "implicit" Markov form to describe a gating system like the classical m^3*h (eq.14 in the paper)
Code: Select all
c_m1 <-> o_m1
c_m2 <-> o_m2
c_m3 <-> o_m3
c_h <-> o_h
N_open = sum ( m_1,i * m_2,i * m_3,i * h_i) with i iterating over the number of channels.
If I'm not confused the first three transitions have the same rate constants alpha and beta, which would further simplify the implementation and allow to directly use the *inf and *tau expressions instead.
Unfortunately you have to end up with individual states that are open or closed, e.g. m3h1 would be open but m2h1 etc. would be closed. The Channel Builder allows partial conductance states, so for example total conductance would be
gbar*(0.5*m3h1 + 0.3*m2h1 + 0.2*m1h1)
where m3h1, m2h1, and m1h1 are understood to be the fractional number of channels that are in each of the coresponding states. But it doesn't allow you to say that conductance is proportional to the product of the values of two or more states.
Re: Changing from deterministic to stochastic channels
Posted: Wed Dec 02, 2009 11:57 am
by hines
As a deterministic channel, the kinetic scheme above can be entered directly into the channel builder as is and result in
a conductance of (I used the default O# and C# names)
gmax*O*O2*O3*O4
If one selects Properties/AllowSingleChannels, an error message is emitted:
KSChan single channel mode implemented only for single ks gating complex to first power.
With a loss of computational efficiency for one single channel. (one has to follow four particles, one for each
gate, and for n single channels there are a total of 4*n particles), the src/nrniv/ksingle.cpp could be extended to allow
the product form of channel specification.
For either deterministic or single channel models,the transitions may be specified in either (a,b) or (tau, inf) form.