Segmentation violation realtime

[Nin]

I'm trying to add a mechanism consisting in a simple step function. For that I wrote:

Code: Select all

NEURON {
    SUFFIX step
    RANGE del, dur, amp 
    RANGE nt
}

UNITS {
    (mM) = (milli/liter) 
}

PARAMETER {
    del (ms)
    dur (ms) <0,1e9>
    amp (mM)
}

ASSIGNED {
    nt (mM)
}

INITIAL {
    nt = 0
}

BREAKPOINT {
    if  ( t < del + dur && t > del) {
        nt = amp
    }
    else {
        nt = 0
    }
}

When I compile the mod file everything runs OK, but once I start neuron I get the following error:
in stdrun.hoc near line 522
realtime = startsw() - rtstart
^
xopen("stdgui.hoc")
execute1("{xopen("stdgui.hoc")}")
load_file("stdgui.hoc")

What am I missing ?

I use NEURON 7.3 (726:af0c90e31572)

[ted]

When I compile the mod file everything runs OK, but once I start neuron I get the following error:

Code: Select all

 in stdrun.hoc near line 522
                realtime = startsw() - rtstart
                                 ^
        xopen("stdgui.hoc")
      execute1("{xopen("stdgui.hoc")}")
    load_file("stdgui.hoc")

What am I missing ?

The clue is in the error message that came earlier:

Code: Select all

syntax error
 in stdrun.hoc near line 521
 		step()
      ^
        xopen("stdrun.hoc")

Giving your mechanism the name "step" causes a problem when stdrun.hoc is loaded.

"But I didn't load stdrun.hoc."

stdrun.hoc is one of the files that NEURON loads automatically if you start NEURON by executing
nrngui
or if your program contains one of these statements:
load_file("nrngui.hoc")
load_file("noload.hoc")
load_file("stdgui.hoc")

stdrun.hoc defines many important variables, procedures, and functions that are part of NEURON's standard run system. One of those procedures is called step. Maybe that's why the error occurred.

The problem will vanish if you simply change
SUFFIX step
to
SUFFIX mystep
or, better,
SUFFIX pulse
pulse is also a better name than step for your mechanism because "step" implies a single transition, but your mechanism specifies two transitions--the first from off to on, and the second from on to off.


Other comments and suggestions:

There are lots of ways to change a parameter during a simulation, but which is easiest or "best" depends on whether you want a density mechanism (something that would affect many compartments) or a point process (something that affects only one compartment). A second but possibly important issue is that it would be good for the mechanism to be compatible with variable time steps. Anything that relies on testing t in the BREAKPOINT block will not work reliably with variable time steps; events would be better.

Am I correct to assume that you are trying to change the concentration of something? If the answer is yes, I should inform you that no other mechanism will "see" the concentration change. There is a proper way to implement concentration changes, but due to limited time I won't get into that unless it is really relevant to what you are trying to do.

[Nin]

These were fantastic pieces of advice!!!!

A second but possibly important issue is that it would be good for the mechanism to be compatible with variable time steps. Anything that relies on testing t in the BREAKPOINT block will not work reliably with variable time steps; events would be better.

Now I'm curious. Should I add a solver to the BREAKPOINT statement to support a variable time discretization? Or use the FUNCTION/PROCEDURE statement in stead?

Am I correct to assume that you are trying to change the concentration of something? If the answer is yes, I should inform you that no other mechanism will "see" the concentration change. There is a proper way to implement concentration changes, but due to limited time I won't get into that unless it is really relevant to what you are trying to do.

Yes, my idea was to use pulse to use a POINTER in a kinetic scheme of a channel described in mod and then simply use (in Python)

Code: Select all

h.setpointer(pre(0.5)._ref_nt_pulse, 'Concentration', myChannel)

I was tempted to use NetCon together with NET_RECEIVE, but I was not very sure about the following implementation.

Code: Select all

myNetCon = h.NetCon(pre(0.5)._ref_v, myChannel)
myNetCon.threshold = 0
myNetCon.delay = 2.5
myNetCon.weight[0] = 1 # concentration in mM
myNetCon.weigth[1] = 1 # duration in ms?

would appreciate a reference about this last.

Thanks a lot!!!

[ted]

Should I add a solver to the BREAKPOINT statement to support a variable time discretization? Or use the FUNCTION/PROCEDURE statement in stead?

Neither. To force an abrupt parameter change one should either use Vector play or make direct use of events e.g. by using cvode.event or Netcon event in hoc or Python, or an ARTIFICIAL_CELL or POINT_PROCESS with a NET_RECEIVE block that is driven by events.

my idea was to use pulse to use a POINTER in a kinetic scheme of a channel described in mod

Interesting. I'm reasonably sure that what you want to do (once I understand what that is) can be implemented in a way that is both "natural and efficient" for NEURON and also easy for you to use. It's probably best for us to continue this discussion by email. If you can email me
ted dot carnevale at yale dot edu
a somewhat more complete description of what you are trying to represent in your model, plus the mod file for the channel that you want to control, I'll be able to give you more specific suggestions and possibly even some working code that you can then customize for yourself.