NEURON exits with a syntax error that reports failure of an insert statement like
Code: Select all
. . . nrniv: syntax error
in foo.hoc near line 2
soma insert bar
^
Code: Select all
. . . nrniv: Bar is not a template
in foo.hoc near line 4
soma baz = new Bar(0.5)
^
The hoc code asked NEURON to use an unrecognized density mechanism ("distributed mechanism") or object class (point process or a class defined by a template).
Possible causes:
1. Typographical error in the name of the density mechanism or class.
2. Omission of hoc code that uses a template to define a class.
3. Failure to load the ses file for a Channel Builder that defines a density mechanism or point process.
4. The density mechanism or point process was defined by a mod file, but the mod file was not compiled, either because the user forgot to compile it, or because compilation failed.
5. The mod file was compiled successfully, but the compiled mechanism(s) did not load when NEURON started.
Diagnosis and treatment of causes 1 - 3 is generally straightforward and will not be discussed further. Failure to compile mod files under MSWin usually means badly broken NMODL code; the fix is highly case-specific and must be addressed on a case-by-case basis. Failure to compile under OS X, Linux, and UNIX most often means that the development tools and libraries have not been installed; the fix, which is to install the development tools and libraries, is OS-specific and has been discussed in multiple threads on this Forum.
Failure to load compiled mechanisms occurs rarely, and when it does, it is typically in the context of programs that are organized so as to place mod files in one or more directories that are different from the directories that contain the hoc and ses files. Sometimes it can be useful to break programs into multiple files that are distributed over elaborate directory structures (for a good example of how to do this properly, see the NEURON code for Brette et al. 2007 http://senselab.med.yale.edu/modeldb/Sh ... odel=83319), but most often the result is obfuscating complexity that interferes with program use, debugging, and maintentance.
But failure to load compiled mechanisms can also have much simpler causes. For example, suppose you're in a directory where you successfully compiled some mod files, and you execute this command:
nrngui foo.hoc
where foo.hoc is the name of a hoc file in that directory. NEURON will start, read the compiled mechanisms, and then it will read and execute the statements in foo.hoc. So far, so good. Now suppose you try this instead:
nrniv foo.hoc
NEURON will start, but it won't load the compiled mechanisms. Instead, it will immediately start reading and executing the statements in foo.hoc. If any of those statements needs one of the compiled mechanisms, you're going to get an error message, because NEURON won't know anything about the compiled mechanisms.
"But I can fix that by putting a nrn_load_dll() statement in my hoc file, right?"
Sure you can, but the statement will be OS-specific. On a 32 bit Linux machine, it would be
nrn_load_dll("i686/.libs/libnrnmech.so.0")
But under 64 bit Linux it would have to be
nrn_load_dll("x86_64/.libs/libnrnmech.so.0")
and under MSWin it would be
nrn_load_dll("nrnmech.dll")
So why bother? Just use
nrngui foo.hoc
and you won't have to worry about all these OS-specific details.
"But I don't want the GUI."
Fine. Start neuron like this:
nrngui -nogui foo.hoc