# Volume Calculation Taking a Long Time **URL:** \ **Category:** User Support\ **Created:** [February 15, 2024, 3:11pm UTC](https://openmc.discourse.group/t/volume-calculation-taking-a-long-time/3914 "2024-02-15T15:11:03Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![pshriwise](https://yyz2.discourse-cdn.com/free1/user_avatar/openmc.discourse.group/pshriwise/32/3863_2.png) [@pshriwise](https://openmc.discourse.group/u/pshriwise)\ **Post date:** [February 20, 2024, 3:54pm UTC](https://openmc.discourse.group/t/volume-calculation-taking-a-long-time/3914/7 "2024-02-20T15:54:07Z")
Ah I see. Thanks for sharing that script with me. Please see this post on applying triggers for volume calculations > [@Negative volume value](https://openmc.discourse.group/t/negative-volume-value/832/5): > > Hi @kingyue, @LucasB Thanks for reporting this issue! I took a look at this using the BEAVRS benchmark (found [here](https://github.com/mit-crpg/beavrs)) 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](https://github.com/openmc-dev/openmc/pull/2270) 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… The gist is that use of a trigger on the standard deviation of volume values can lead to extremely long run times due to the large number of samples required, particularly for a problem involving TRISO particles. You may be better off using relative error as a metric for your trigger or reducing your requirement for the maximum standard deviation on your current trigger. --- _[View the full topic](https://openmc.discourse.group/t/volume-calculation-taking-a-long-time/3914)._