-NSTACK: Stack size too small

[Brad]

I have a process with a couple of large, nested FOR loops which generates the following message:

"ERROR nrniv: Stack size too small. Increase -NSTACK"

After some trial and error, I changed the values of *NSTACK to 100000 in

Windows:
$NRN_HOME/lib/nrn.def and
$NRN_HOME/lib/nrn.defaults.in

Linux:
$NRN_HOME/share/lib/nrn.defaults
$NRN_HOME/share/lib/nrn.defaults.in

and this seems to take care of the problem for now. (Alternatively, it seems one can pass this option on the command line as -NSTACK stacksize; I have not tested this.) However, these FOR loops might grow in the future and I would like some assistance on intelligently setting this value.

Furthermore, there seems to be a companion, NFRAME, which also might come into play at some point. How would one pick reasonable values for NFRAME?

Finally, what is the distinction between nrn.def and nrn.defaults.in?


Brad

[hines]

The hoc stack size is important only if you have very deep recursion. It should not be an issue with for loops. I would need to look at your loops to see why it is using the stack.

NFRAME is even more specific to recursion and refers to the maximum procedure call depth. The default values for NSTACK and NFRAME are 1000 and 200 respectively.

nrn.defaults.in is the autoconf precursor file from which a machine and configuration specific nrn.defaults file is constructed. The
nrn.def file is a copy of the nrn.defaults file for the mswin distribution and dates back to the days when dos could not handle suffixes with more than three characters.

[Brad]

The limits of the nested FOR loops depend on the interation value of the outer loop.

Here's an attempt at a representation (this is not the acutal code, because the real code has a bunch of other "stuff"):

Code: Select all

for i = 0,A {
	for j = 0,vec1.x[i] {
		for k = 0,vec2.x[i] {
			...
		}
	}
}

vec1 and vec2 are not changed within the loop.

I don't know if this techically counts as recursion, but increasing NSTACK definitely solved the problem. I believe that I am not "recursively" calling procedures, so I don't think increasing NFRAME is necessary in this case.

I've hand-checked the output and am confident that it produces correct results for the parameter space I am interested in, so I am satisfied.

Concerning the config files, if nrn.defaults.in is a "precursor" file, it's only the "nrn.def" (Win) and "nrn.defaults" (Unix) that actually take effect?

Thanks for the info.

[hines]

Can you post or email me a simple three nested loop that demonstrates a default stack size stack problem that I can execute and trace the stack usage?
Thanks, Michael

[Brad]

While paring down my code to post an example, I discovered that the stack size warning was not triggered at the loops even though the message was pointing there. (Sorry for the inaccurate post. Increasing NSTACK solved my problem so I didn't investigate further.) But I discovered that if I run the following code with NSTACK = 10 (artificially low) I can see what actually triggered the error I first reported.

Code: Select all

objref vec

num = 4     // typically num <=5
count = 3   // typically count <=5

vec = new Vector(num*3)

vec.x[0] = count

for i = 1,vec.size()-1 {
	vec.x[i] = vec.x[i-1]*count
}

generates this message:

nrniv: Stack too deep. Increase with -NSTACK stacksize option in C:/.../example2.hoc near line 11
vec.x = vec.x[i-1]*count

[What I wanted to do was slightly more complicated than this. Even though it appears to be an overblown way to calculate an exponential, it is the most reduced case that illustrates the problem.]

Is the setting of an array element while referencing the previous element a subtle form of recursion? (Well, to my brain, most recursion is subtle!)

Increasing NSTACK to at least 10000 allows NEURON to handle all the ranges in which I'm interested, so I'm hoping that all this is now just an academic pursuit. Is there any danger to having NSTACK set too large?

[hines]

I'm afraid an NSTACK of 10 is not a good test for unusual stack usage. I encourage you to send me all your original code (mod, ses, hoc files in a zip file) that demonstrates the stack error with default stack size and let me figure out the reason the stack is not large enough. You can send me the zip file at
michael.hines@yale.edu.