FLAIR volume calculation tool shows unexpected behavior

Dear community


My name is David and I’ve encountered a strange behavior of the volume calculation tool contained in the geometry tab in Flair (v13.1-15.1) for one of my more complex simulation models (containing multiple transformed quadrics).


The calculation tool shows 0 cm^3 volume for a fully defined finite region. To showcase this unexpected behavior, I’ve copied the corresponding region (“target”) to a test file (attached to this post).


  1. Do you get the same unexpected behaviour, i.e. 0 cm^3 volume?
  2. Is there a solution or a work-around for this problem?

Thank you very much for your support

Volume_test.flair (2.9 KB)
Volume_test.inp (2.4 KB)

My specs: FLUKA 4-2.2, FLAIR 13.1-15.1, Operating System: WSL Ubuntu 18.04 LTS, Xming display server

Dear David,

Thanks a lot for reporting this, and for the very clear presentation of the problem.

I could indeed reproduce the issue.
I had a glance at the code. The issue comes from non-supported cases in geoviewer (the geometry algorithms engine, which Flair calls under the hood).
If, for any given dimension, a quadratic surface is used as a constraint to define a region, then the bounding box is considered infinite in that dimension. This results in null tracklenths in the ray shooter used to compute the volume in a Monte Carlo way. This, in turn, leads to volume/surface wrongly estimated to 0.
For example, in your case, the region TARGET is constrained in each of Ymin, Ymax, Zmin and Zmax, by at least one plane. Instead, in the X dimension, quadratic surfaces are involved, leading to infinite bounding box in that dimension, and the null volume calculation.

A proper solution would be to add support to the geoviewer algorithms, for these types of non-planar constraints on the region definition. One could use the fact the the region is finite, hence for any given dimension, the quadratic surface admits an upper bound.
For example, in your case, the algorithms could compute Xmin and Xmax extrema, reached by the quadratic surfaces on [Ymin, Ymax]x[Zmin, Zmax].

A very simple hack for now, to get the TARGET volume/surface anyway, would be to manually add planes normal to X, to bound the TARGET region.
You can for example add a YZP at x=-100 cm; let’s call it TH_pxtl2.
Then, you simply need to add +TH_pxtl -TH_pxtl2 in the TARGET region definition (do not forget to update the VOID definition accordingly).
The TARGET volume/surface computation should now work properly (volume ~ 4E5 cm3, surface ~ 4E4 cm2).
You can take any value for the x of TH_pxtl2. Of course, it should be chosen far enough from your actual TARGET, so that it does not intersect it (hence modify its volume/surface).

NB: As often (always?), this visual, by hand approach could also provide a possible algorithm for the geoviewer implementation: if, for any given dimension, the constraint used to define a region involves quadratic surface(s), then, for the bounding box, consider a random plane. Place the plane further and further away from the region of interest (e.g. doubling a with X=a in our example), up to the iteration where the plane does not intersect the region anymore (this is guaranteed to happen, because the region is finite).
We might provide more generic algorithms in geoviewer to support these cases (but this will take a bit of time).

Thanks again for your report, this is very helpful,

Dear Gabrielle

Thank you very much for your swift reply. I really appreciate your support.

Regarding the proposed work-around, I have only one small follow-up question:

I’ve tested your work-around for the target and void regions individually and it works perfectly. However, in my tests, it doesn’t matter, if one adds the additional bounding planes also to the void region or not. In other words, the volume calculator tool seems to work for both the void and target region, if one adds the bounding planes only to the target region. Can you confirm that?

I’m looking forward to the implementation of the suggested algorithm for the geoviewer in a new FLAIR update.


Dear David,

Great that the proposed work-around works for now!

Yes the bounding planes in the VOID region is just for the good practice (to be sure we have the complementary, in case the bounding planes are accidentally intersecting the TARGET), should not be needed for the VOID volume calculation.

In any case, we will try to add a more robust support to address all these use cases,

Thanks again for your report,