All of a sudden I started getting errors when trying to run my model, with this message:
CVode-- At t=0 and step size h=1.48177e-14, the corrector
convergence failed repeatedly or with |h| = hmin.
CVode 1012c610 MSN[0].soma advance_tn failed, err=-6.
err=-6
nrniv: variable step integrator error near line 452
{run()}
The error source sometimes jumps from soma to spine or dendrite. I assume that it has something to do with my .mod files, as I have been writing my own. But the strange thing is I don't think I have modified the .mod files that significantly before the error started occuring.
By the way, removing all mechanisms from the soma (save pas and Na hh channel) still results in the above error. Turning off Variable Step Control and running that way works (albeit slow), but no values seem to get calculated.
Any hints/ideas as to where I should start looking?
Sorry, bad choice of words.. Of course, that is not probable, which is why I do suspect my .mod files. However, I am at a loss as to what exactly is causing the problem, I have gone over the files, recompiled them and even tried removing most from the hoc.
What change I remember making was adding a slow decay component to the total current equation...
Well, sometimes bizarre things do happen, typically as a consequence of something
that was overlooked, which is why I asked.
NMODL has many traps, even for the wary. To diagnose the problem, it will be
necessary for me to be able to reproduce it. It would be most helpful if you could
cobble up as simple a context as possible, i.e. a minimal model with as little code
and/or GUI embellishment as you can get away with, that will generate the
symptom. Unless the source files are truly small, it would be most practical
not to post them to the Forum, but instead zip them up and send them directly
to me as an email attachment.
I am getting a similar error to the one described above. Unfortunately, I did not change anything in my mod files and the error only occurs for certain cell morphologies but not for others (and I can't find any bugs in the morphologies that get the bug.) Here's what happens:
I get an error like this:
exp(3.64504e+08) out of range, returning exp(700)
No more errno warnings during this execution
CVode-- At t = 2.48765 and h = 1.73591e-14, the corrector
convergence failed repeatedly or with |h| = hmin.
In my mod file I have functions that use exp() and so I put a printf statement in it:
FUNCTION var_inf(v(mV), vhalf(mV), vsteep(mV)) {
LOCAL a
a = (v - vhalf)/vsteep
if (a > 100) {
printf("Trying to call exp() with argument %f in var_inf(%f,%f,%f)\n", a, v, vhalf, vsteep)
}
var_inf = 1 / (1 + exp(a))
}
The if statement catches it and then I get a lot of print outs like this:
Trying to call exp() with argument 1249.647180 in var_inf(12423.471804,-73.000000,10.000000)
Trying to call exp() with argument 832.564854 in var_inf(12423.472804,-65.000000,15.000000)
Trying to call exp() with argument 832.564787 in var_inf(12423.471804,-65.000000,15.000000)
Trying to call exp() with argument 6236.736402 in var_inf(12423.472804,-50.000000,2.000000)
So something is indeed passing in very large voltages into the mechanism. So I added something to my main loop that for every time step executes:
forall {
if (v > 100) {
print "v=",v," in ", secname()
}
}
But this print statement is never executed. So from the level of the program no section ever has an odd large voltage. But something in the mechanism is passing very large voltage values into the var_inf function.
As I mentioned at the top of the page, I didn't change anything in the mod files to get this bug. I am using 3-D morphologies and I get this error on some of my cells, but not others. Each cell is run with identical code. The only difference is that for each cell there is a different sequence of create, connect, and pt3dadd statements to build the cell from the 3-D data. At present I am checking my morphologies for errors like zero diameters or wrong connections, but haven't found anything.
What else can I do to diagnose this? Is there any way to find out what section/segment a bit of nmodl code is executing in? (something like secname() that can be accessed in NMODL?) If it is a bug in the morphology it would be helpful if I could at least determine which section is having the problem...
It's possible that the bug has already been fixed in the very latest development version.
If not, it remains to be diagnosed and fixed. The key to doing that is being able to
reproduce it, preferably in a minimal model.
The problems are likely unrelated. Both of you should send me the hoc/ses/mod files necessary to reproduce the problem in a zip file. michael.hines@yale.edu
But is there an answer to the question at the end of my post: is there a way from NMODL code to know which is the current compartment (section name and x)? That would have made debugging this error much more efficient, I think. Then if you have a weird error condition you could add a printf to the NMODL code to catch the condition and tell you where in the cell it was happening.
(Although it seems like an obvious error, in a file with >1000 lines specifying lots of 3D sections it certainly didn't leap out to grab my attention! I had to resort to commenting out each dendritic tree in turn until I found the one with the problem, then add in each section in that tree until the problem re-appeared. Then when I looked at that section it was completely obvious what the problem was, but first I had to isolate it...)
in a file with >1000 lines specifying lots of 3D sections it certainly didn't leap out to grab my attention!
How to quickly detect bad lengths and diameters:
First, execute
area(0.5)
to ensure that all data structures are consistent with the geometry specification.
Then iterate over the model and test for unlikely or erroneous dimensions.