Trying to use VecStim
Trying to use VecStim
I started learning how to implement VecStim by checking out the vecevent* files in nrn\examples\nrniv\netcon. I found that when I simply typed load_file("vecevent.ses"), it caused NEURON to crash almost instantly, so that I didn't even have time to read the error that was generated. I am running NEURON 7.2 on a Windows 7 PC. Thanks.
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Trying to use VecStim
Did you compile vecevent.mod first? Proper usage of the vecevent* files in nrn/examples/nrniv/netcon requires that you first use mknrndll (or nrnivmodl if you're using UNIX/Linux) to compile the mod file. If you omit this step, the VecStim class will not exist.
After vecevent.mod has been compiled, then use NEURON to execute vecevent.hoc. If you simply start NEURON, then
load_file("vecevent.ses")
there will be no error message, and clicking on the RunControl panel's Init & Run button will produce no error message, but there will be no spike train. vecevent.hoc contains statements that create a Vector, fill it with event times, and tell the VecStim instance to generate events at the times specified in the Vector.
After vecevent.mod has been compiled, then use NEURON to execute vecevent.hoc. If you simply start NEURON, then
load_file("vecevent.ses")
there will be no error message, and clicking on the RunControl panel's Init & Run button will produce no error message, but there will be no spike train. vecevent.hoc contains statements that create a Vector, fill it with event times, and tell the VecStim instance to generate events at the times specified in the Vector.
Re: Trying to use VecStim
Thanks, Ted, that seemed to work. I guess I just didn't think to compile the mod file, since when I use netstim.mod I don't need to compile it. Also, there are many other times when I receive an error and the program crashes without allowing me to read the error message--is there any way to prevent this in general? Thanks.
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Trying to use VecStim
because you're not using netstim.mod. You're using the NetStim class, which is built into NEURON. By design, only a very small set of channel mechanisms and artificial spiking cell classes is built into NEURON, and these are all documented in the Programmer's Reference.pascal wrote:Thanks, Ted, that seemed to work. I guess I just didn't think to compile the mod file, since when I use netstim.mod I don't need to compile it.
Everything else must be added, either by using the Channel Builder (for ligand- and voltage-gated channels described by kinetic schemes or Hodgkin-Huxley style differential equations) or by compiling model specifications written in NMODL (channels, ion accumulation and transport mechanisms, artificial spiking cells, anything that can be written in the NMODL programming language or C).
I never encountered an error message that was too shy to stick around. Are these syntax or run time errors? Syntax errors (occur before run() is called) tend to be helpful and specific. Run time errors are harder to diagnose and fix. Are you throwing a lot of freshly written, untried code at the interpreter, or are you proceeding more incrementally?Also, there are many other times when I receive an error and the program crashes without allowing me to read the error message--is there any way to prevent this in general?
Re: Trying to use VecStim
Thanks for the explanation on NetStim. That makes sense. Also, I was able to induce a "crash" with some very simple code. First, I wrote the file test.hoc:
The code should generate an error, since the second line should be "vec = new Vector(4)". When I load test.hoc by itself, it generates an error, and NEURON does not crash. Everything is fine. But then I made the file "open_test.hoc":
When I start NEURON, move to the appropriate directory, and then load "open_test.hoc", the whole program crashes. So it appears that somehow the crashing is caused by using one file to open another file that has an error in it. Also, it's interesting to note that if "test.hoc" does NOT have the assignment vec.x[1]=1, then the system does not crash--it just generates an error, as it should. And again, I'm running on a Windows 7 PC.
Code: Select all
objref vec
vec = Vector(4)
vec.x[1]=1
Code: Select all
load_file("test.hoc")
-
- Site Admin
- Posts: 6384
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: Trying to use VecStim
Looks like a problem with error handling under MSWin. With Linux,
nrngui test.hoc
generates a useful error message
and so does
nrngui open_test.hoc
nrngui test.hoc
generates a useful error message
Code: Select all
/usr/local/nrn/i686/bin/nrniv: syntax error
in test.hoc near line 2
vec = Vector(4)
^
nrngui open_test.hoc
Code: Select all
/usr/local/nrn/i686/bin/nrniv: syntax error
in test.hoc near line 2
vec = Vector(4)
^
xopen("test.hoc")
execute1("{xopen("test.hoc")}")
load_file("test.hoc")
0
/usr/local/nrn/i686/bin/nrniv: Segmentation violation
in test.hoc near line 3
vec.x[1]=1
^
Re: Trying to use VecStim
I'll see if I can fix that. The xopen or load_file is returning 0 as it is supposed to. But then the calling code continues on and executes something that relied
on the success of the xopen and then neuron exits which causes the terminal to close. What is needed is for the first error to stop the interpreter and wait for input.
A work around to prevent the terminal from closing is to start from the rxvt terminal and then explicitly launch nrniv by cd'ing to the proper place and executing
nrniv <hoc file>
on the success of the xopen and then neuron exits which causes the terminal to close. What is needed is for the first error to stop the interpreter and wait for input.
A work around to prevent the terminal from closing is to start from the rxvt terminal and then explicitly launch nrniv by cd'ing to the proper place and executing
nrniv <hoc file>
Re: Trying to use VecStim
Thanks for the work-around. That works perfectly.