NMODL variable name conflicts: names that start with D
Posted: Thu Jan 28, 2010 5:12 pm
User-defined names that start with the letter D may conflict with automatically generated names for state derivatives.
I ran into such a conflict when writing NMODL code for a calcium accumulation mechanism that involved calcium and two buffers. One of the buffers (Bufs) was stationary, but calcium and the other buffer (Bufm) were mobile--able to diffuse radially between shells.
The symptom
I was building the mechanism incrementally, and the mod file was called cdp.mod. Version 1 of cdp.mod just had calcium accumulation and diffusion, with no buffering, and it worked fine. Version 2 included the stationary buffer Bufs, and it worked too. But then I added Bufm, the mobile buffer, so that the KINETIC block contained the reactionand compilation of cdp.mod file exited with an error message that contained, among other stuff, this line:
Diagnosing the cause
cdp.c, which was produced by compiling cdp.mod, contained the clues to what went wrong:
with one exception, for each state foo there was an automatically-generated variable Dfoo that represented the derivative of that state. Here is the STATE block from cdp.modand here is the list of automatically-generated state derivatives from cdp.cNotice that, although Bufm appears in the STATE block, there is no corresponding DBufm in cdp.c's list of state derivatives.
Why?
Because the name "DBufm" had already been declared in cdp.mod's PARAMETER blockSure enough, cdp.c contained a DBufm, but this wasn't a state derivative--it was just a constant.
Notice that there was no name conflict for the stationary buffer Bufs because I hadn't defined a diffusion constant called DBufs (after all, Bufs is stationary!). And there was no conflict for ca because the automatically-generated state derivative was Dca, which didn't collide with the user-defined name for the diffusion constant DCa.
The cure
Change the name of the parameter or state. One suggestion is to call the parameter DBufmparm. Another is to leave the parameter name as DBufm but call the state bufm (by analogy to ca and DCa).
I ran into such a conflict when writing NMODL code for a calcium accumulation mechanism that involved calcium and two buffers. One of the buffers (Bufs) was stationary, but calcium and the other buffer (Bufm) were mobile--able to diffuse radially between shells.
The symptom
I was building the mechanism incrementally, and the mod file was called cdp.mod. Version 1 of cdp.mod just had calcium accumulation and diffusion, with no buffering, and it worked fine. Version 2 included the stationary buffer Bufs, and it worked too. But then I added Bufm, the mobile buffer, so that the KINETIC block contained the reaction
Code: Select all
~ ca[i] + Bufm[i] <-> caBufm[i] (kfm*dsqvol, (0.001)*KDm*kfm*dsqvol)
Code: Select all
cdp.c:421: error: subscripted value is neither array nor pointer
cdp.c, which was produced by compiling cdp.mod, contained the clues to what went wrong:
with one exception, for each state foo there was an automatically-generated variable Dfoo that represented the derivative of that state. Here is the STATE block from cdp.mod
Code: Select all
STATE {
ca[Nannuli] (mM)
Bufs[Nannuli] (mM) : the stationary buffer
caBufs[Nannuli] (mM) : ca+Bufs <-> caBufs
Bufm[Nannuli] (mM) : the mobile buffer
caBufm[Nannuli] (mM) : ca+Bufm <-> caBufm
}
Code: Select all
#define Dca (_p + 25)
#define DBufs (_p + 29)
#define DcaBufs (_p + 33)
#define DcaBufm (_p + 37)
Why?
Because the name "DBufm" had already been declared in cdp.mod's PARAMETER block
Code: Select all
PARAMETER {
DCa = 0.22 (um2/ms) : Fink et al. 2000
DBufm = 0.050 (um2/ms)
. . .
}
Code: Select all
#define DBufm DBufm_cdp
double DBufm = 0.05;
The cure
Change the name of the parameter or state. One suggestion is to call the parameter DBufmparm. Another is to leave the parameter name as DBufm but call the state bufm (by analogy to ca and DCa).