Unexpected navigation behaviour with overlapping nodes

In the simple geometry (4 nodes) at the end of this post, one of the nodes (outer_box) is added to the top node using the TGeoNode::AddNodeOverlap() method, even though it is fully contained within its parent and does not overlap with any of its siblings. This may be inefficient, but as far as I understand it is allowed because it does not violate any pre-condition.

Now, if I try to navigate from a point very close to the surface of this box towards the inside of the box, the navigator sees neither the box nor its child volume, and proceeds directly to the surface of the clipped_box behind it. The expected behaviour would be to hit the surface of either outer_box or filler (depending on rounding, since the point is precisely at the surface).

There are two ways I can restore the expected behaviour:

  1. change container.AddNodeOverlap(outer_box, 1, t1) into container.AddNode(outer_box, 1, t1);
  2. suppress the clipped_box node;

Tested with ROOT v5.34.30 and v6.6.0.

Is this a bug?

Full PyROOT listing:

from ROOT import gROOT, TGeoManager, TGeoTranslation, TGeoMaterial, TGeoMedium, TMath

mgr = TGeoManager("Geom","Geom")

# lengths
box_side = 7.62
inner_box_side = 7.
half_height = 52.874
container_half_height = 56.684

material = TGeoMaterial('material')
medium = TGeoMedium('medium', 1, material)

# volumes
container = mgr.MakeTube("container", medium, 0., 80.9625/2, container_half_height)
outer_box = mgr.MakeBox("outer_box", medium, box_side/2, box_side/2, half_height)
filler = mgr.MakeBox("filler", medium, inner_box_side/2, inner_box_side/2, half_height)
clipped_box = mgr.MakeBox("clipped_box", medium, box_side/2, box_side, half_height)

# nodes
outer_box.AddNode(filler, 1)

t1 = TGeoTranslation(box_side*0.5,box_side*-4.5, container_half_height - half_height)
container.AddNodeOverlap(outer_box, 1, t1)

t2 = TGeoTranslation(box_side*1.5,-box_side*5, container_half_height - half_height)
container.AddNodeOverlap(clipped_box, 1, t2)

# adminstratrivia

# testing
# this point is right on the north face of /container_1/outer_box_1
point = (1.506819e+00, -3.048000e+01, -3.266042e+01)
# pointing inwards
omega = [8.198252e-01, -5.061459e-01, 0.0]
omega_norm = TMath.Sqrt(omega[0] * omega[0] + omega[1] * omega[1] + omega[2] * omega[2])
omega[0] /= omega_norm
omega[1] /= omega_norm
omega[2] /= omega_norm

node = mgr.InitTrack(point[0], point[1], point[2], omega[0], omega[1], omega[2])
next_node = mgr.FindNextBoundaryAndStep()
print("from=" + node.GetName())
print("to=" + next_node.GetName())
print("step=" + str(mgr.GetStep()))
if next_node.GetName() != 'filler_1':
    print('The filler box has not been seen!')


This was a bug and it is now fixed in the master. Note however that AddNodeOverlap is likely to create problems specially when the nodes declared to overlap have some daughters, which at their turn will overlap with a sibling of their mother. Any particular reason why you use this feature?

Hi, thanks for answering,

First I should add that I have reproduced the bug in an even simpler geometry, without the outer_box node and with the starting point moved some 10 cm to the right. The red volume in the picture above is missed.

The main motivation for my use of AddNodeOverlap() is that it is much simpler than boolean intersections. I have revised my geometry (which is much more complex than the MWE above) to replace all calls to AddNodeOverlap() with the suitable boolean composite shapes, and it was a real pain.

It would be great if at least the limitations of AddNodeOverlap() were clearly spelt out somewhere. I could not find any trace of your warning in the docs. Even better, if you know for sure that this feature may fail in certain cases, it may make sense to deprecate it.

Will the fix be available in the next release?

Thanks again,

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.