There is a negative value in the result obtained by OpenMC’s volume calculation shown below. The trigger of the calculation is 1E-3 relative error.
The volume of this cell is much larger than other cells’. If I remove the smallest cells from the list of cell to calculate, the result becomes correct.
Could this be due to an overflow?
Thanks for reporting @kingyue. Do you have a script/model you can share that can reproduce this behavior?
I’m not allowed to upload this model. I will try to reproduce this behavior with other models.
I wanted to add something here since I was having the same issue. I found that commenting out the set_trigger line in Python fixed it. Furthermore, when I had the std_dev trigger set, the volume calculation would take about an hour, regardless of how many samples I used (I tried 100 to 1,000,000), or what I set the std_dev to (tried 1e-2 to 1e-5). I also tried it with and without a defined bounding box, which made no difference. After commenting that line out, it only took a few seconds, even with 1,000,000 samples. I can’t share my model, but I hope this is helpful.
Thanks for reporting this issue! I took a look at this using the BEAVRS benchmark (found here) and could reproduce the negative volume values. This was caused by overflow in the int type used to track the total number of hits for a given cell/material/universe during the volume calculation process. I’ve created this pr to address that.
The other side of this is that the number of samples, N, required to reach the value specified on the trigger may be very, very large. Like any value computed in a Monte Carlo process the std. dev. will decrease as 1/\sqrt{N}. As an example, one of the cells in the BEAVRS model had a result of
Cell 76: 37701.4920406969 +/- 11.265745477911146
after 3.18 \times 10^{10} samples, so a std. dev. of 1e-2 would take an estimated 4 \times 10^{16} samples 
. While using relative error as the trigger type is probably more tractable, even that can result in some really large sample sizes – as we see in @kingyue’s case.
The updates I’ve made allow for a much higher number of samples and I’ve added a warning if the number of samples exceeds the max value of the C++ type we’re using now (uint64_t) to count samples and hits in cells/materials/universes, but this can still happen. Just something to keep in mind when using the triggers in the volume calculations.
-Patrick
1 Like
Just wanted to note here that this fix is part of the latest OpenMC release and is ready for use Release OpenMC 0.13.2 · openmc-dev/openmc · GitHub