Optimizing PROCEDURE equations in mod files

Using the Multiple Run Fitter, praxis, etc..
Post Reply
neuromau
Posts: 97
Joined: Mon Apr 20, 2009 7:02 pm

Optimizing PROCEDURE equations in mod files

Post by neuromau »

Hi, I have a cell model that contains a channel mechanism. I want to use the Multiple Run Fitter to adjust some equations in a PROCEDURE block of the channel definition. Before I get to that, I have to settle a more general issue, though. I can't seem to manually update the variable values in these equations after setting them the first time. Not sure what I'm doing wrong.

I have variables such as "offset1" that I want to update, so I made them RANGE variables in the NEURON block. I played around with putting them either in the PARAMETER or the ASSIGNED (where I think they go) block, but had the problem in both cases:

Code: Select all

NEURON { 
	SUFFIX ch_Nav
	RANGE offset1
	...}
ASSIGNED {
	offset1 (mV) 
        ...}
BREAKPOINT {
	SOLVE states
        ... }
PROCEDURE states() {
	trates(v)	
        ... }
PROCEDURE trates(v) { 
        ...                                   
	rates(v)
        ...}
PROCEDURE rates(v) {
        ...
	alpha = -1*slope1*vtrap((v-offset1),-5)
        ...}
...
Then I have some hoc code that creates the cell and sets the value of offset1. And then a hoc initialization function that inserts the ch_Nav mechanism and sets its offset1_ch_Nav value to offset1.

If I start a fresh instance of nrngui and then run the hoc code with, say, offset1=20, it runs fine. If I start a fresh nrngui and set offset1=0 and run the hoc code, again it runs as expected.

However, if I start out with offset1=20 and then later, at the command prompt, I enter offset1=0, that's when I have trouble. I rerun the initialization code, check that the value of soma.offset1_ch_Nav is now 0 (it is), but then when I run a simulation, the simulation behaves as if offset1 is still 20. After the simulation, I again print soma.offset1_ch_Nav and it is still 0. So why doesn't the voltage trace from soma.v(0.5) look like it does when I open a fresh nrngui and immediately run with offset1=0?

Let me know if I should send you my code. Thanks.
ted
Site Admin
Posts: 6287
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Optimizing PROCEDURE equations in mod files

Post by ted »

Send the code.
ted dot carnevale at yale dot edu

What version are you running (what's the first line printed to the interpreter's terminal at startup)?
ted
Site Admin
Posts: 6287
Joined: Wed May 18, 2005 4:50 pm
Location: Yale University School of Medicine
Contact:

Re: Optimizing PROCEDURE equations in mod files

Post by ted »

Great question, raises a lot of issues.

First, the issue of PARAMETER vs. ASSIGNED. It is best to declare parameters in the PARAMETER block. PARAMETERs can have default values, and these are automatically exposed to hoc as GLOBALs or, if declared RANGE in the NEURON block, as RANGE variables. PARAMETERs also appear "where you would expect them" in the GUI's model specification tools (CellBuilder, PointProcessManager, Network Builder etc.). This makes it much easier to use the GUI for debugging and interactive simulation.

Now for the symptom you encountered. "Changing the value of a parameter has no effect on simulation results" typically means a problem with a TABLE statement.

In ch_Navngf.mod the original PROCEDURE trates() was

Code: Select all

PROCEDURE trates(v) {
	LOCAL tinc
	TABLE minf, mexp, hinf, hexp, mtau, htau
  DEPEND dt, celsius FROM -100 TO 100 WITH 200

	rates(v)
  tinc = -dt * q10
  mexp = 1 - exp(tinc/mtau)
  hexp = 1 - exp(tinc/htau)
}
where rates() is a PROCEDURE that assigns values to minf, hinf, mtau, and htau. When trates() is called during a simulation, it gets the values of minf, hinf, mtau, and htau from the table, instead of calling rates(). So hoc statements that assign new values to offset*_ch_Navngf or slope*_ch_Navngf won't affect results unless you either
change dt or celsius, which tricks ch_Navngf into rebuilding the table
or
set usetable_ch_Navngf to 0, which disables ch_Navngf's use of the table

Now that we have discussed the cause of the symptom you reported, let's consider a performance issue. PROCEDURE trates() includes mexp and hexp in the TABLE statement, but PROCEDURE rates() contains no statements that would assign values to them. Consequently the corresponding table entries will hold zeros or garbage values.

That seems pretty serious--why doesn't it break your simulation?

Because the last two statements in trates() calculate the values of mexp and hexp at each time step. The result is a mechanism that uses additional memory (for the mexp and hexp tables) but isn't as fast as it could be. The fix is to move the calculation of tinc, mexp, and hexp into rates().

I'll email you a repaired ch_Navngf.mod, a very simple model (single compartment with just this mechanism, SEClamp, RunControl, graphs, and parameter panel) that you can use to verify that this ch_Navngf.mod works correctly, and some other suggestions.
neuromau
Posts: 97
Joined: Mon Apr 20, 2009 7:02 pm

Re: Optimizing PROCEDURE equations in mod files

Post by neuromau »

Thanks!
zylittlep
Posts: 9
Joined: Sat Feb 16, 2019 6:36 pm

Re: Optimizing PROCEDURE equations in mod files

Post by zylittlep »

Hi Ted,

Do you mind sharing the modified code, please? It seemed that I ran into a similar problem.

Thank you.

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

Re: Optimizing PROCEDURE equations in mod files

Post by ted »

I don't think I have that mod file on this machine. No matter; a better example is hh.mod, which you will find in NEURON's source code under nrn/src/nrnoc
Post Reply