Error with latest changes to nocmodl: "xxx not really a STATE; Ie. No differential equation for it." about nrn HOT 9 CLOSED

Sorry. That is a case I forgot to handle in the new state discontinuity adjustments in NET_RECEIVE
blocks. A fix should come today.

from nrn.

A new commit with the message
Some kinds of state discontinuity adjustments require cvode.
If that is not available then the adjustment code is not emitted.
A notice is printed.
$ nocmodl ProbAMPANMDA_EMS.mod
Translating ProbAMPANMDA_EMS.mod into ProbAMPANMDA_EMS.c
Notice: This mechanism cannot be used with CVODE
Notice: A_AMPA discontinuity adjustment not available.
Notice: B_AMPA discontinuity adjustment not available.
Notice: A_NMDA discontinuity adjustment not available.
Notice: B_NMDA discontinuity adjustment not available.
Warning: dt undefined. (declared within VERBATIM?)
Thread Safe

from nrn.

I'm leaving it open as to the possibility of emitting proper state discontinuity adjustment code for this case.

from nrn.

Thanks Michael for the fix! New changes allow now to build neurodamus without any issue.

from nrn.

@nrnhines
I'm having the same problem with a version of NEURON I compiled from source (this repository, master branch) today. This was not a problem in previous versions of NEURON.

vI not really a STATE; Ie. No differential equation for it.

Full mod file here:

TITLE Mod file for component: Component(id=RS type=izhikevich2007Cell)

NEURON {
    POINT_PROCESS RS 
    NONSPECIFIC_CURRENT i                    : To ensure v of section follows vI
    RANGE v0                                : parameter
    RANGE k                                 : parameter
    RANGE vr                                : parameter
    RANGE vt                                : parameter
    RANGE vpeak                             : parameter
    RANGE a                                 : parameter
    RANGE b                                 : parameter
    RANGE c                                 : parameter
    RANGE d                                 : parameter
    RANGE C                                 : parameter
    RANGE iSyn                              : exposure
    RANGE iMemb                             : exposure
    RANGE copy_v                           : copy of v on section
}

UNITS {  
    (nA) = (nanoamp)
    (uA) = (microamp)
    (mA) = (milliamp)
    (A) = (amp)
    (mV) = (millivolt)
    (mS) = (millisiemens)
    (uS) = (microsiemens)
    (molar) = (1/liter)
    (kHz) = (kilohertz)
    (mM) = (millimolar)
    (um) = (micrometer)
    (umol) = (micromole)
    (S) = (siemens)  
}

PARAMETER {
    v0 = -60 (mV)
    k = 7.0E-4 (uS / mV)
    vr = -60 (mV)
    vt = -40 (mV)
    vpeak = 35 (mV)
    a = 0.030000001 (kHz)
    b = -0.002 (uS)
    c = -50 (mV)
    d = 0.1 (nA)
    C = 1.0E-4 (microfarads)
}

ASSIGNED {
    v (mV)
    i (mA/cm2)
    copy_v (mV)
    iSyn (nA)                              : derived variable
    iMemb (nA)                             : derived variable
    rate_v (mV/ms)
    rate_u (nA/ms)  
}

STATE {
    vI (nA) 
    u (nA)   
}

INITIAL {
    rates()
    rates() ? To ensure correct initialisation.
    net_send(0, 1) : go to NET_RECEIVE block, flag 1, for initial state
    u = 0
}

BREAKPOINT {
    SOLVE states METHOD cnexp
    copy_v = v
    i = vI * C
}

NET_RECEIVE(flag) {  
    if (flag == 1) { : Setting watch for top level OnCondition...
        WATCH (v >  vpeak) 1000
    }
    if (flag == 1000) {
        v = c
        vI = 0 : Setting rate of change of v to 0
        u = u  +  d
    }
    if (flag == 1) { : Set initial states
        v = v0
    }
}

DERIVATIVE states {
    rates()
    u' = rate_u 
}

PROCEDURE rates() {
    iSyn = 0
    iMemb = k  * (v-  vr  ) * (v-  vt  ) +  iSyn  -  u
    rate_v = iMemb  /  C
    rate_u = a  * (  b   * (v-  vr  ) -   u  )
    vI = -1 * rate_v
}

from nrn.

In this case, it really is the case that vI is not a STATE and it should be declared ASSIGNED.
STATE is supposed to be reserved for the case where a variable is not just an assigned value but
a dependent variable of a set of equations. By the way, setting vI in the NET_RECEIVE block and in the rates procedure makes the detailed effect of vI quite obscure since its value is transiently 0 which should
have no real effect since it is immediately replaced by the value of a function of v and u. Choosing a smaller dt will cause the transient 0 to have less and less effect. And what effect it has is only due
to implementation details of the fixed step method. Why do you not call rates() from the NET_RECEIVE
block to set vI to its correct value with respect to the new values of v and u.

from nrn.

This mod file was programatically generated by jNeuromL and was compatible with previous versions of NEURON. If this implementation is not longer permitted, I'll let the jNeuroML developers know that they need to avoid pseudo-states like this.
The source LEMS file was https://github.com/OpenSourceBrain/IzhikevichModel/blob/master/NeuroML2/LEMS_2007One.xml and I converted it with jnml LEMS_2007One.xml -neuron)

from nrn.

@pgleeson What do you think?

from nrn.

The reason for the greater strictness is because NET_RECEIVE block state discontinuities can now
be integrated more accurately when the nrn_netrec_state_adjust flag is set. STATE has always been
intended to list the unknown or dependent variables of simultaneous algebraic, ODE, or kinetic scheme
states that need to be managed by blocks called by the "SOLVE" statement.

from nrn.