Fix geometry overlap: nudge dirtCentralStairwellLower3 face by 1 um - #1926
Fix geometry overlap: nudge dirtCentralStairwellLower3 face by 1 um#1926oksuzian wants to merge 1 commit into
Conversation
dirtCentralStairwellLower3, added in Mu2e#1918, abuts CentralStairwellLowerStairs at Mu2e z = 6375.4. That neighbour is rotated by -1.5707963268, which is pi/2 truncated at the 10th decimal, so its face is tilted ~5e-12 rad off square and pokes into the new volume. overlapCheck.C uses CheckOverlaps(1e-12), so the artifact is reported on the default geometry: Overlap ov00000: HallAir/dirtCentralStairwellLower3 overlapping HallAir/CentralStairwellLowerStairs ovlp=3.11047e-10 Move the abutting face out by 1 um so the volumes no longer touch. This is the same remedy already applied to the neighbour itself, whose yHalfThickness carries "remove 1 um to prevent conflict as the rotation angle is not exactly pi/2". Verified by regenerating mu2e_common.gdml from the patched geometry and rerunning overlapCheck.C: 1 illegal overlap -> 0. The regenerated GDML differs from the baseline in exactly the two twoDimVertex entries for this face, with identical volume counts (9987 physvol), so no other volume is perturbed. Fixes Mu2e#1925
1cbd142 to
ea88441
Compare
|
Replaced the original approach (full-precision pi/2 on the rotation literal) with a 1 um face nudge — same result, 0 overlaps, but no 16-digit constant to maintain. Force-pushed; the PR body above describes the current change. Details on why shortening the angle literal doesn't work are in the "Why not fix the rotation angle instead" section. |
|
☀️ The build tests passed at 1cbd142.
N.B. These results were obtained from a build of this Pull Request at 1cbd142 after being merged into the base branch at 1891b32. For more information, please check the job page here. |
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for ea88441: build (Build queue - API unavailable) |
|
☀️ The build tests passed at ea88441.
N.B. These results were obtained from a build of this Pull Request at ea88441 after being merged into the base branch at 1891b32. For more information, please check the job page here. |
Fixes #1925.
dirtCentralStairwellLower3, added in #1918, abutsCentralStairwellLowerStairsat Mu2e z = 6375.4. That neighbour is rotated by-1.5707963268— π/2 truncated at the 10th decimal — so its face is tilted ~5e-12 rad off square and pokes into the new volume.bin/overlapCheck.CcallsCheckOverlaps(1e-12), so the artifact is reported on the default geometry (geom_common.txt):This moves the abutting face out by 1 µm so the volumes no longer touch — the same remedy already applied to the neighbour itself, whose
yHalfThicknesscarries "remove 1 um to prevent conflict as the rotation angle is not exactly pi/2".Validation
Regenerated
mu2e_common.gdmlfrom the patched geometry viagdmldump.fcl(art exit 0) and reranoverlapCheck.C:main@1891b328)Diffing the regenerated GDML against the baseline after stripping Geant4 pointer suffixes shows exactly the two
twoDimVertexentries for this face:Volume counts identical (9987
physvol), and the neighbour's rotation is untouched. No physics consequence — 1 µm on a dirt volume, against an original discrepancy of 3e-13 m.Why not fix the rotation angle instead
I first tried replacing the truncated literal with a full-precision π/2, which also gives 0 overlaps. Two reasons I abandoned it:
SimpleConfighas no π constant and no expression evaluation — values go throughstrtod, soM_PI/2isn't available. It would have to be the bare literal-1.5707963267948966, which is unpleasant to read and invites someone to "tidy" it back to something shorter later.-1.5707963267(10 decimals, erring short of π/2 on the theory it would open a gap) and it still overlaps, atovlp=5.78e-09— worse than the original. Any inexact right angle tilts a corner in somewhere; only the full 16-digit value clears the tolerance. So the angle route is all-or-nothing on that literal.The 1 µm nudge sidesteps the precision question entirely and matches the idiom already in these files.
Note for a follow-up
Two sibling volumes carry the same truncated literal:
bldg/centralStairwellUpperStairs1.txt:11bldg/centralStairwellUpperStairs2.txt:11Neither currently overlaps anything, so they're out of scope here. Worth knowing they're the same latent pattern if a new volume is ever placed against them. @sdifalco — these are your files, happy to defer if you'd rather handle the family differently.