www.neuron.yale.edu

Hi, I would like plot the rate process time constants for the K+ activation gate and the Na+ activation and inactivation gates.
There is a easy way to do it with neuron?

thanks
Menica

"rate process time constant" is not a familiar concept, and a Google search find no instance of this phrase. Maybe you want to plot the time course of the rate constants or time constants of voltage-gated ion channels.

menica wrote:There is a easy way to do it with neuron?

Yes, if these two statements are true:
1. the channel definitions are written in mod files
2. the variables in which you are interested are accessible to hoc

If statement 1 is true but statement 2 is not true, the NMODL code can probably be revised to make the variables accessible to hoc.

To provide more specific information, I will have to see the NMODL files that define the channel properties.

I need to plot the time constants for the three gates.
For rate process time constant I mean
mtau, htau, ntau
They are GLOBAL variables in the hh.mod, so are not accessible to hoc.
How can I modify the hh.mod?

menica wrote:I need to plot the time constants for the three gates.
. . .
mtau, htau, ntau
They are GLOBAL variables in the hh.mod, so are not accessible to hoc.

Not so. An NMODL GLOBAL variable is indeed visible to hoc, and if your entire model has only one compartment, it's entirely OK to study the time course of an NMODL GLOBAL. However, there is a potential problem if more than one compartment in your model has the hh mechanism. Why? Because each compartment that has hh will share the same storage location in memory for mtau. Likewise, there will be a shared memory location for htau, and another shared location for ntau. During an fadvance, the statements in each compartment's BREAKPOINT block are executed, one compartment after another. The value that remains in an NMODL GLOBAL after an fadvance() is the value that was calculated for the last compartment whose BREAKPOINT block was executed. You have no control over that sequence of execution, and you won't know if the value you get is from the location that you are interested in.

Of course the workaround is to declare these variables as RANGE. This increases memory utilization slightly (each compartment has its own locations for storing mtau, htau, and ntau).

So copy hh.mod to your working directory, and call this copy hhx.mod. Then edit hhx.mod and make the following changesMaybe you'd also like change all 6 GLOBALs to RANGE--it's up to you.

Next, compile the mod file and do whatever you want with this new hhx mechanism. Your new RANGE variables will be accessible with the same syntax that is used for hh's RANGE variable parameters gnabar, gkbar etc..

Dear Ted,
thanks for your explanation