Fatal error entry 2 is not monotonically increasing

[khary23]

I am trying a different energy spectrum in a code I am writing and get the following error when I try to run the it.

0.61247 0.88454
fatal error entry 2 of si 3 is not monotonically increasing

This has me confused because the two values above are monotonically increasing as are the preceding values. Is there a formatting or syntax issue that I am missing?

 

[FactChecker]

I can't open the .txt file.

 

[khary23]

I can't open the .txt file.

Strange I just opened it on my phone.

 

[DEvens]

Heh, you could have mentioned at some point it was MCNP.

Two things:

SI3 = 0 0.06149 0.063 0.06512 0.06683 0.07108 0.07141

The space between SI3 and = should not be there. You are better off using the form with no = at all.

Next, the number of entries on SI3 does not match the number on SP3.

 

[khary23]

I noticed the SI3 issue right after I posted, but the space with the equal sign...who knew.

 

[DEvens]

I noticed the SI3 issue right after I posted, but the space with the equal sign...who knew.

MCNP is a huge code with a lot of history. And there are many competing incentives for where development and documentation effort is expended. The result is, a significant number of really weird things. It's by no means the only error message that is difficult to diagnose.

The most annoying one I have found so far is an error message that arises when certain internal limits are exceeded. These are not limits that the code advertises, but somewhere inside there is an array or a depth or something that is exceeded. The error message is something about a degenerate torus. I *think* it's because the code has some kind of resource leak or not-properly-cleaned-up pointer or something, and this is the first error message in a group of messages. This error message can occur even in an input with no torus surface. But the worst part for me was, it first showed up in my work when I did add a torus to the model. And my torus was deliberately degenerate. So I wasted several days hunting through 50,000 lines of MCNP input trying to figure out what was wrong. Sigh.

Eventually you are forced to fall back on old-time debugging. Cut out half the model and see if the error goes away. Then put the first half back and cut out the second half. And then cut out half the remaining error-showing part, and so on until you reduce it down to three or four lines. Then you just have to nudge-and-poke. It can be very annoying, time consuming, and budget damaging.

Wait until you get lost particles because you tried to make a pizza-slice division of a cylinder. I was working on a project that had three bundles in a channel in 120 degree sectors. It was modeled as three equal wedges meeting at the center. And it lost particles quite often. That wasted a bunch of time.

The MCNP mailing list can be helpful. You need to be registered with RSICC to be on that mailing list. Just as here, it's all volunteers. Though sometimes you get actual MCNP developers answering.

 

[DEvens]

By the way, I wish I could help with your TMESH question on the other thread, but I have never used TMESH.

 

[khary23]

By the way, I wish I could help with your TMESH question on the other thread, but I have never used TMESH.

No worries, thank you for all of your help by the way!

can one use FMESH in spherical coordinates?

 

[khary23]

I requested to be on the mailing list