MRF on Channels?

Using the Multiple Run Fitter, praxis, etc..
Post Reply
mctavish
Posts: 74
Joined: Tue Mar 14, 2006 6:10 pm
Location: New Haven, CT

MRF on Channels?

Post by mctavish » Tue Mar 14, 2006 6:18 pm

I'm somewhat new to NEURON and very new to the MRF. I am trying to obtain channel coefficients using MRF. I've gone through the two tutorials online, but is there more documentation that can help? Does someone have a channels example they can share?

Thanks,
Tom

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

Making ChannelBuilder parameters available to the MRF

Post by ted » Wed Mar 15, 2006 12:33 pm

The channel builder's parameters must be accessible from hoc so that the MRF can
adjust them. 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)

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 / chnl_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.      <<< these names are just examples!
  double click on aC202. in right column -->        <<< the names you see may be different!
    edit field changes to ChannelBuild[0].aliases.aC202.,
    and right column shows A, d, k
So the "complete" hoc names of these three parameters are
ChannelBuild[0].aliases.aC202.A, ChannelBuild[0].aliases.aC202.d, etc.
For this particular example, these would be the names that you would enter into the
MRF's Parameters panel.

--Ted

mctavish
Posts: 74
Joined: Tue Mar 14, 2006 6:10 pm
Location: New Haven, CT

Post by mctavish » Thu Mar 23, 2006 2:19 am

Thanks for the reply, Ted,

I was swarmed with other things and have just come back to this... I can stay on top of it now, if you can give me a quick response!

I've started into an example like you suggest. What I've done is taken the simple HH Channel tutorial (with "myna" etc) and set up MRF with the following equation:
ChannelBuild[0].aliases.ah.A*exp(ChannelBuild[0].aliases.ah.k*($1-ChannelBuild[0].aliases.ah.d)).
This is in the hopes of finding parameter ChannelBuild[0].aliases.ah.A (which should be 0.07).

I believe this equation in the MulRunFitter starts off correctly, but I need to account for the injected current. IClamp = 1ms, .1ms, .1nA. What do I do to get the current accounted for? Or am I way off base, here?

Is there a way to upload a session file here? If so, I can send you what I have...

Thanks,
Tom

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

Post by ted » Thu Mar 23, 2006 10:31 am

I need to account for the injected current. IClamp = 1ms, .1ms, .1nA. What do I do to get the current accounted for?
I haven't the foggiest idea what you mean.
Is there a way to upload a session file here? If so, I can send you what I have...
You can zip it up and email it to me
ted dot carnevale at yale dot edu
But lacking an explanation of your reference to injected current, I'm not sure what good
would come of it.

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

Step back from the problem and imagine a manual approach

Post by ted » Sun Mar 26, 2006 3:32 pm

Followup:

mctavish sent me a ses file that recreated a single compartment model with HH (which
includes gna_hh, gk_hh, and gl_hh), plus his myna mechanism. gnabar_hh was 0, so
that all of the sodium conductance was attributable to myna. His goal was to adjust the
parameter A in the expression for the forward reaction rate for the h gating state
ah=A*exp(k*(v-d)
so that the model would generate a spike that matches a normal HH spike.

The ses file also recreated an Multiple Run Fitter (MRF hereafter) that was nicely
configured--with one exception that is mentioned below.

When confronted with an unfamiliar task and an unfamiliar tool, it sometimes helps to
step back from all of the NEURON-specific details for a moment, and consider how
to proceed if you had to do everything manually. For this example, you would choose
a value of A, run a simulation, compare the model's membrane potential waveform
with a recording of a "normal spike," and decide what further adjustment to make to A.

So you need an MRF with a Run Fitness Generator (RFG) that is set up to use
soma.v(0.5) as the "variable to fit." At every iteration, the MRF will launch a new
simulation, and the time course of somatic membrane potential will be plotted in the
RFG. To compare this with a recording of a normal spike, a spike waveform should
be pasted into the RFG.

mctavish's MRF did have an RFG with a normal spike pasted into it, and the MRF's
Parameter Panel used the proper alias
ChannelBuild[0].aliases.ah.A
to refer to A. He also was careful to stipulate that A was positive definite.

The only problem was that, instead of soma.v(0.5), the RFG was set up to use
ChannelBuild[0].aliases.ah.A*exp(ChannelBuild[0].aliases.ah.k*($1-ChannelBuild[0].aliases.ah.d))
as the "variable to fit." In other words, this RFG was comparing the forward reaction
rate for h against somatic membrane potential. Sure enough, clicking on the RFG's
ErrorValue button produced a very low amplitude trace that showed the time course
of ah during a simulation. Of course, this bore no resemblance to the spike waveform,
so the error value was very large, and Praxis was totally unable to force the time course
of ah to fit the spike.

The fix was easy--just disable the existing RFG, and create a new one, specifying that
the variable to fit is soma.v(0.5).

Many steps are involved in setting up an optimization protocol, and it is easy to make
one or more mistakes at each step. In this case, the problem was caused by losing
track of what was to be compared with what. Everything else was exactly as it should
be. Diagnosing and fixing such an error can be particularly difficult for the person who
made it, at least partly because of being overwhelmed by wrestling with details. As I
mentioned above, it can be helpful to imagine a "human" or "manual" approach to the
task, and then re-examine the implementation on the computer.

Post Reply