and avoid problems such as inconsistent units, failed compilation, or runtime errors,
there are a few simple rules to follow when organizing NMODL source code.
1. It's always a good idea to put a COMMENT block at the very start of a mod file. Include
a short description of what the specified mechanism does, and cite appropriate
2. The NEURON block should be next. This is where anyone who wants to use the mod
file is going to look to discover the name of the mechanism, and how to access its
parameters and variables.
3. If there is a UNITS block, it should be right after the NEURON block.
4. Variable declaration blocks are next. In NMODL, variables must be declared before
they are used. That's why variable declaration blocks must preced equation blocks.
A reasonable sequence is
because, when you're reading a mod file, you're probably going to check parameter
values right after you read the initial COMMENTs and the NEURON block.
5. Last but not least are the equation blocks. I like to use this sequence
DERIVATIVE or KINETIC
FUNCTIONs and PROCEDUREs
but you can do whatever you like, but if there is a DERIVATIVE block, it must be placed
after the BREAKPOINT block. To quote Michael Hines,
Putting the DERIVATIVE block in front of the BREAKPOINT block may cause incorrectsometimes the METHOD in the SOLVE statement determines some of the parsing when the DERIVATIVE block is seen.
Starting with NEURON v. 5.9.1501, compiling a mod file that has a DERIVATIVE
block that precedes its BREAKPOINT block will produce an error message--
Code: Select all
[hines@localhost mod_bad]$ nrnivmodl /home/hines/tmp/mod_debug/mod_bad naf.mod naf.mod "/home/hines/neuron/nrnobj/x86_64/bin/nocmodl" naf Translating naf.mod into naf.c INCLUDEing var_funcs.inc INCLUDEing inact_gate_states.inc INCLUDEing inact_na_currs.inc The SOLVE statement must be before the DERIVATIVE block for states at line 15 in file inact_na_currs.inc ina = gbar*(m^exp_m)*(h^exp_h)*(v - ena) ^ make: *** [naf.c] Error 1 [hines@localhost mod_bad]$