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,

Gabrielle