1. Almost every mechanism in this model defines its own ion. For example, the K+ channels, rather than each using the 'k' ion, invent their own K+ ions. I think that has the effect of NEURON thinking they are all separate ion types, and not counting them towards the potassium concentration. I can't think of why one should do this, unless the current consisted of multiple ion types and the proportion of each type varied or was unknown. And in that case, shouldn't one just use the NONSPECIFIC current?
Ex: gskch.mod calcium-activated potassium channel (non-voltage-dependent) uses ion: sk
CaGk.mod calcium activated K channel (voltage dependent) uses ion: k
bgka.mod Borg-Graham type generic K-A channel uses ion: k
ichan2.mod (which has K+ fast and slow delayed rectifiers, in addition to other channels, all in one mechanism) uses ions: kf and ks
In general it can be difficult to know a programmer's intent, and in some cases it may even be more difficult to decide what is intentional and what is accidental (especially when the topic is NMODL source code--not least because NMODL's strange syntax tends to invite what might be called "superstitious programming" i.e. odd bits and pieces of code or syntax that serve no evident purpose, but got there by virtue of rote replication of excerpts lifted from prior examples of "working code").
Here's one situation in which it may be useful to define different ionic species: suppose there is a close anatomical association between a particular class of Ca channels and a particular class of Ca-gated K channels, so that when the Ca channels open, there is a very localized accumulation of Ca that affects the K channels. Also suppose that current through other kinds of Ca channels has little effect on the Ca-gated K channels. In this case, it might make sense to define a new ion for the Ca channels that affect the Ca-gated K channels, so it can have its own accumulation mechanism. Of course this opens questions about how Ca is cleared from this special pool (including membrane transport and ion exchanges between this pool of intracelluar Ca and all the other intracellular Ca), but those are different issues. Did the example you cite do something like that?
If not, maybe the programmer's goal was to facilitate identification of which potassium current component was generated by which mechanism. There are better ways to accomplish such a goal--ways that do not interfere with proper management of mass balance. Example:
Code: Select all
USEION k READ ek WRITE ik
RANGE g, i : so you can define ASSIGNED i that will be known to hoc as i_sk
. . .
. . .
. . .
g = whatever
i = g*(e-ek)
ik = i : because this mechanism has to WRITE ik
Note the following:
1. The mechanism WRITEs ik, so it affects charge balance AND k mass balance.
2. The mechanism uses an auxiliary variable i, declared to be RANGE, so that one can discover the current generated by this mechanism (value will be known to hoc as i_sk). This variable does NOT affect charge balance or mass balance.
3. SUFFIX and variable names have been deliberately crafted to be concise yet mnemonic, while avoiding ugly hiccups--i_sk is far preferable to isk_gskch. Much existing NMODL code seems to be afflicted by very poor naming strategies that reduce code legibility.
Code: Select all
2. One of the mechanisms defines separate ions for the fast and slow components of its current. Again, I don't know what is to be gained from this. If it's easier to calculate the fast and slow components separately, shouldn't one still add them together at the end and set a single ion's current equal to the sum of the components?
Ex: hyperde3.mod (HCN channel) uses the following ions: hyf, hys, hyhtf, hyhts
(the other thing that I find odd about this mechanism is both the control (hy?) and experimental (hyht?) current types seem as if they would both be active at the same time.)
That is a bit of a wart, isn't it? Not to mention its unnecessary INDEPENDENT statement and superfluous VERBATIM block. And it uses the long-deprecated "analytical solution" approach to coding HH-style mechanisms, and contains the (unnecessary for this mechanism, and unused) FUNCTION vtrap. I can see that one might want to know the values of the fast and slow components, but this is doable by calculating auxiliary variables that can then be summed to find the total ik.