Geometry overlap after #1918: dirtCentralStairwellLower3 vs CentralStairwellLowerStairs (ovlp=3.1e-10)

[oksuzian]

Offline/bin/overlapCheck.C reports an overlap in the default geometry after #1918:

Processing Offline/bin/overlapCheck.C("build/al9-prof-e29-p103/Offline/gen/gdml/mu2e_common.gdml")...
 = Overlap ov00000: HallAir/dirtCentralStairwellLower30x545f8d0
                    overlapping HallAir/CentralStairwellLowerStairs0x55f22b0  ovlp=3.11047e-10

Verified on main @ 1891b3289. Originally seen in a nightly build.

Cause

dirtCentralStairwellLower3 was added by #1918 (merged 2026-08-08). CentralStairwellLowerStairs is pre-existing and untouched by that PR, so this is new-volume-against-old-volume.

The two share a coincident face at x = 9956.8 mm:

• bldg/dirtCentralStairwellLower3.txt — xPositions = {9956.8, 11617.2, 11617.2, 9956.8}
• bldg/centralStairwellLowerStairs.txt — xPositions span 1.0 … 9956.8, and the volume is rotated by angles = {0., 0., -1.5707963268}

-1.5707963268 is π/2 truncated at the 10th decimal, so the rotation is off true right-angle by ~1e-11 rad. Against a ~1.2 m lever arm that puts the rotated face a few times 1e-10 mm past the neighbour — which is exactly the reported 3.11e-10.

Severity: cosmetic, but it does break the check

The magnitude is 3.11e-10 mm = 3e-13 m, about a thousandth of an atomic diameter. There is no physics consequence; no particle transport is affected.

It matters only because bin/overlapCheck.C calls CheckOverlaps(1e-12), and #1523 deliberately tightened that tolerance to catch small extrusions early. So the check is doing its job — this is a genuine coincident-face artifact that the stringent tolerance is designed to surface. I would not loosen the tolerance to silence it.

Suggested fix

The codebase already has a precedent for exactly this, on the other volume of this same pair — bldg/centralStairwellLowerStairs.txt:10:

double building.central.stairwell.lower.stairs.yHalfThickness = 609.599;
  // remove 1 um to prevent conflict as the rotation angle is not exactly pi/2

Same root cause, same remedy. Shave ~1 µm off the new volume so the faces no longer touch, e.g. in bldg/dirtCentralStairwellLower3.txt:

-double dirt.central.stairwell.lower3.yHalfThickness = 1260.45;
+double dirt.central.stairwell.lower3.yHalfThickness = 1260.449;  // remove 1 um to prevent conflict, cf. centralStairwellLowerStairs

Whether the right axis is yHalfThickness or a 1 µm nudge on the xPositions face at 9956.8 depends on which the author intends as the free dimension — @sdifalco, you'll know which is dimensionally meaningful here. Either way it's a micron on a dirt volume.

Scope

dirtCentralStairwellLower3 enters via mu2eHall_v03.txt:663, which is reached by ~43 top-level geometries including geom_common.txt (the current default, via geom_run1_a_stickman.txt). So this is not confined to a frozen campaign geometry — anyone running the overlap check on default geometry sees it.

Happy to open the one-line PR if you'd rather not bother, just say which dimension to trim.

[oksuzian]

Correction to my suggested fix above — wrong axis. PR #1926 fixes this instead.

I suggested trimming yHalfThickness by ~1 µm, following the precedent comment on line 10 of centralStairwellLowerStairs.txt. That would have suppressed the overlap, but it treats the symptom on the wrong axis. yHalfThickness is the vertical extent; the two volumes actually meet face-to-face in Mu2e z, at z = 6375.4:

• CentralStairwellLowerStairs spans z −3580.40 … 6375.40
• dirtCentralStairwellLower3 spans z 6375.40 … 8035.80

The overlap is caused entirely by the rotation angle -1.5707963268 being π/2 truncated at the 10th decimal (5.1e-12 rad short). Over the 609.599 mm half-thickness that tilts the rotated face by 3.1e-9 mm. The arithmetic closes: predicted 3.1111e-10 cm vs reported 3.11047e-10 cm, ratio 1.0002 — so the truncated angle is the whole effect, with nothing left for a dimensional fudge to explain.

Using the full double representation of π/2 removes the cause outright and needs no 1 µm shave. Verified by regenerating the GDML and rerunning the check: 1 overlap → 0, with exactly one line changed in the output and identical volume counts.

Also worth noting for anyone reading this later: the GDML makes it visible directly, y="89.9999999997076" instead of y="90".

[sdifalco]

The problem with pi/2 rotation was in the past observed by Leo who has created the central stairs volume. I was following the hint to use no gap between that volumes but a safety gap in this case is needed. I think that 1 um is much less than the precision that we need to cover gaps so I approve the suggested fix.
In the past Krzysztof has found other overlaps reducing the overlap check precision to less than 10^-12 but we agreed that this was too much. We shouldn't have problems in running Geant4 because of that