Aug 26 geometry updates

[sdifalco]

These are the geometry fixes described in doc-db 57505:

• air gaps
• materials
• volume dimensions

[FNALbuild]

Hi @sdifalco,
You have proposed changes to files in these packages:

• Mu2eG4

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for e77630c: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at e77630c.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged e77630c at 1ce31db
build (prof)	✅	Log file. Build time: 04 min 24 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 0 files
clang-tidy	✅	0 errors 0 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at e77630c after being merged into the base branch at 1ce31db.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[oksuzian]

PR Review Summary

Mu2e/Offline PR #1918 — "Aug 26 geometry updates" (sdifalco, branch AugGeomFixes)
Reviewed at head e77630c6
Base 1ce31dbc · 27 files · +458 / −103 · no prior reviews or review comments on the PR (only the FNALbuild CI posts), no locally staged draft — this is a first review, nothing to carry forward.

Decision

• 🟡 comment only — the geometry work checks out against every structural and overlap test I could run, and the stated intent is measurably achieved. Two items should be answered before merge: the OPA support material change (#1) and the 0.1 mm slit through the DS-area first floor (#2).

Scope understood

• 24 building/dirt extruded-solid definitions under Mu2eG4/geom/bldg/ are edited or added (8 new files), plus the include/prefix wiring in Mu2eG4/geom/mu2eHall_v03.txt. Net effect: close air gaps around the TS-area W1 notch, the central stairwell and the DS-area elevator shield; split dsAreaFirstFloorS into a thinner concrete slab (S2) with dirt underneath; fix two wrong materials.
• One unrelated file: Mu2eG4/geom/protonAbsorber_cylindrical_v04.txt changes the OPA support structure material from StainlessSteel316 to Al7075.
• Everything reaches production: mu2eHall_v03.txt ← mu2eHall_v04.txt ← geom_run1_a.txt / geom_run1.txt / geom_2021_PhaseI* / geom_common.txt, and protonAbsorber_cylindrical_v04.txt is included by the same geom_run1*.txt / geom_2021_PhaseI* set. Mu2e/Production JobConfig/cosmic/geom_cosmic_run1_a.txt is a one-line #include "Offline/Mu2eG4/geom/geom_run1_a.txt", so the cosmic campaigns inherit all of it.
• No C++, no FHiCL, no build files. No data product, module, or interface change.

---

Findings

1. 🟠 [S1] OPA support material change is a physics change to a versioned file used by all production geometry, made in place, with no stated justification or validation

   • Evidence: Mu2eG4/geom/protonAbsorber_cylindrical_v04.txt — protonabsorber.oPASupportMaterialName, the six-entry oPASupportMaterials, oPASupportSlatMaterials, and crossSupportMaterial all go StainlessSteel316 → Al7075. From Mu2eG4/src/ConstructMaterials.cc at head: StainlessSteel316 is 8.00 g/cm³ (line 403), Al7075 is 2.81 g/cm³ (line 635) — a ~65 % mass reduction on six support rings, three slats and three cross supports sitting inside the DS. Al7075 is a real, defined material (also used by Mu2eG4/geom/tracker_v7.txt), so nothing will throw.
   • Consumers verified at head: geom_run1.txt:66, geom_run1_a.txt:66, geom_2021_PhaseI{,_v02,_v03}.txt, geom_reduced_DSTS_shielding.txt — i.e. every production and CI geometry. geom_common.txt → geom_2021_PhaseI_v03.txt, so the green CI ran against the new material.
   • Impact: (a) this silently re-defines what protonAbsorber_cylindrical_v04 means, so MDC/Run-1 samples produced before this merge are no longer reproducible from the same file name; (b) it is a material-budget change in the DS with no accompanying background/acceptance check; (c) it is a different topic from the hall/building work that makes up the other 26 files.
   • Suggested fix: state in the PR body which item of doc-db 57505 this implements (drawing/serial number for the OPA support alloy), and say explicitly whether an in-place edit is intended rather than a protonAbsorber_cylindrical_v05.txt. If the simulation/production conveners are content with in-place, a one-line note in the PR body recording that decision is enough. Splitting it into its own PR would make it far easier to bisect later.

2. 🟡 [S2] The dsAreaFirstFloorS / dsAreaFirstFloorS2 split leaves a 0.1 mm air slit running the full length of the first floor

   • Evidence: dsAreaFirstFloorS.txt now ends at yPositions = -12014.2 (indices 22, 23), while dsAreaFirstFloorS2.txt starts at -12014.3 (indices 0, 1); dirtDsAreaFirstFloorS2.txt also uses -12014.3. Both slabs share the vertical band 7543.8–7772.4 mm above the floor surface. Sampling the head include chain at (x = 20000, y = −12014.25) returns no solid at all between 7366 and 7800, where base returns building.dsArea.firstFloor.S over 7366–7772.4. At y = −12013 and y = −12016 the head stack is fully covered. The slit is 0.1 mm wide, ~406 mm tall, and runs from x = −2921 to x = 38163.5 (~41 m).
   • Impact: physically negligible for shielding, but it is exactly the sliver class this PR is meant to remove, and coincident-ish thin gaps are the usual source of G4 navigation noise. g4surfaceCheck is green, so nothing is failing today.
   • Suggested fix: one character — make dsAreaFirstFloorS2.yPositions[0,1] and dirtDsAreaFirstFloorS2.yPositions[0,1] -12014.2, matching dsAreaFirstFloorS and dsAreaUpper (which this PR moves to -12014.2).

3. 🟡 [S2] Sub-millimetre standoffs and non-shared coordinates appear throughout the new volumes — confirm they are deliberate

   • Evidence, all at head:
     • dsAreaElevatorShield.txt: offsetFromFloorSurface.y = 1143.10 with yHalfThickness = 1143.00 → bottom at +0.10 mm above the floor surface. (This is the gap fix: base left 152.4 mm of air under the block; probing (31000, −9000) gives base gaps (0, 152.4) and head (0, 0.1).)
     • dirtCentralStairwellLower3.txt: 1260.5 ± 1260.4 → bottom at +0.10 mm.
     • dirtCentralStairwellMiddle2 top = 2825.65 vs Middle3 bottom = 2825.75 → 0.10 mm apart (Middle3/Middle4 abut exactly at 5120.64, so the convention is not applied uniformly).
     • dirtCentralStairwellMiddle5.txt yPositions use -23376.25, while Middle2/3/4 and centralStairwellUpperWall{E,W}.txt use -23376.1 — 0.15 mm mismatch on what should be one shared plane.
     • centralStairwellLowerWallN.txt and tsAreaStairwell.txt move 11366.5 → 11617.2, but centralStairwellUpperWallW2.txt still carries 11617.325 — 0.125 mm off the value this PR is standardising on.
   • Impact: none measurable; it is a maintainability/consistency issue that makes future "does this abut?" reviews harder, and it defeats the intent of the gap-closing exercise at the 0.1 mm level.
   • Suggested fix: if the 0.1 mm standoff is a deliberate anti-coincident-surface convention, add a one-line comment saying so in one of the new files and apply it uniformly; otherwise round all of the above onto the shared coordinate.

4. 🟡 [S2] psAreaUpperN_v02 moves off a coordinate shared with five other files

   • Evidence: psAreaUpperN_v02.txt yPositions[2,3] go 6502.40 → 6857.90. 6502.4 is still used by psAreaUpper2N.txt, dirtPsAreaUpper2N.txt, psAreaHatchLower.txt, dirtBeamlineBerm_Layer748a.txt and dirtBeamlineBerm_Layer750a.txt; 6857.9 now appears in no other file in Mu2eG4/geom/bldg/.
   • Impact: no overlap is produced (checked, see Validation), but if 6502.40 was a shared building line, the neighbours are now out of step with it.
   • Suggested fix: confirm the neighbours are meant to stay at 6502.40; if not, move them in the same PR.

5. 🟡 [S2] Central-stairwell backfill: dirtCentralStairwellMiddle2..5 place MBOverburden inside the stairwell footprint — worth one sentence of justification

   • Evidence: the four new volumes occupy x ∈ [12014.3, 13233.3], y ∈ [−14892.65, −25908], i.e. 0.1 mm inside the walls centralStairwellUpperWallN (x from 12014.2) and centralStairwellUpperWallE2 (x from 13233.4), which this PR simultaneously extends south to −23376.1 and up to 7543.8. Probing (12600, −20000) shows the head stack gaining middle2 (2520.95–2825.65), middle3 (2825.75–5120.64) and middle4 (5120.64–5297.16), where base had only dirt.central.stairwell.lower up to 2520.95.
   • Impact: adds several tens of m³ of MBOverburden inside what reads, from the volume names, like a stairwell shaft. If correct it is a shielding improvement; if the shaft is meant to stay open below the first floor it over-shields that column. I could not settle this from the geometry alone.
   • Suggested fix: one line in the PR body (or a comment in mu2eHall_v03.txt) saying which part of the stairwell is backfilled and which stays open, referencing the doc-db 57505 figure.

6. ⚪ [S3] dirtExtMonStairsGap polygon is asymmetric — confirm 150.1 is not a typo

   • Evidence: dirtExtMonStairsGap.txt xPositions = {75.9, −75.9, −75.9, 75.9} but yPositions = {306.05, 150.1, −306.05, −306.05}, giving a wedge rather than the 151.8 × 612.1 mm rectangle the other three vertices imply.
   • Impact: cosmetic if intended (the sibling extMonStairsWallN_v02.txt is a genuine staircase profile, so an irregular quad is plausible here).
   • Suggested fix: confirm; if the intent was a rectangle, 150.1 should be 306.05.

7. ⚪ [S3] Vertex-label comments degraded in three of the touched files

   • dirtCentralStairwellMiddle5.txt: xPositions labelled g1, g2, g4, g4 (no g3, g4 twice) while yPositions are labelled h, h0, h1, h2 — inconsistent with each other and with Middle2/3/4.
   • dsAreaUpper.txt: indices 31/32 relabelled i8/i9 → h1/h2, which now collide with the h1/h2 already used at indices 15/16.
   • backfillTSarea-W1UpperNotchUpper3.txt: the auto-generated provenance header is rewritten from geom/geom_FillW-TSUpper1notch4.ccl to geom/geom_FillW-TSUpper2notch2.ccl, which is the same source the new Upper2.txt claims. If the .ccl files are the upstream source of truth, one of the two headers is now wrong.
   • Suggested fix: relabel consistently; point Upper3 at whichever .ccl actually produced it.

8. ⚪ [S3] Pre-existing, out of scope, noted only because you are in these files: dirt.extMon.upper (dirtExtMonUpper_v02.txt) is fully defined but appears in no prefix list, so it is never built; and building.N.retaining.Wall.W.extension3, building.foundation.ExtMon.PSarea.R, dirt.foundation.ExtMon.PSarea.R have self-intersecting polygons. None are touched by this PR — no action required here.

---

Verified correct — no action needed

• 🟢 The headline material fix is real and large. dirtNRetainingWallExtension_v02.txt was declaring a 13.8 m³ dirt volume in the berm as StainlessSteel (8.02 g/cm³) — ≈111 t of steel where there should be ≈30 t of MBOverburden (2.15 g/cm³). Straightforward bug, correctly fixed.
• 🟢 The stated intent is measurably achieved. Sampling vertical material coverage over the touched regions, base vs head: TS-area W1 notch column mean uncovered thickness 514 mm → 32 mm; central-stairwell column 3304 mm → 2060 mm; elevator shield floor gap 152.4 mm → 0.1 mm.
• 🟢 Include / prefix wiring is complete. Parsing the whole mu2eHall_v04 → v03 chain at head (383 files) and resolving all four prefix lists: 255 bldg + 107 dirt + 14 rotated + 3 dirt-trap prefixes, and every one resolves to a complete block (.name, .material, .xPositions, .yPositions, all three offsets, .yHalfThickness); len(x) == len(y) everywhere; no listed-but-undefined and no newly-defined-but-unlisted volume. All eight new files are both #included and listed.
• 🟢 The new rotated solid is wired correctly. dirt.extMon.stairs.gap is added to rotated.prefix.list only, which matches how Mu2eHallMaker::makeRotated consumes that list into the separate rotatedSolids_ map, and matches the existing rotated entries (none of which appear in bldg.prefix.list). It supplies the required .angles vector.
• 🟢 No macroscopic solid–solid overlap introduced: all 24 changed/new volumes tested pairwise against all 362 listed hall solids for simultaneous vertical-interval and footprint intersection — zero hits. Consistent with green rootOverlaps and g4surfaceCheck.
• 🟢 No new self-intersecting or zero-area polygon among the changed volumes.
• 🟢 The DS-area first-floor split preserves coverage at the stairwell walls: raising centralStairwellUpperWall{E2,W2,N} from 6578.6 ± 787.4 to 6667.5 ± 876.3 keeps the bottom at 5791.2 and lifts the top to exactly 7543.8, which is exactly where the thinned dsAreaFirstFloorS2 concrete now begins. Probes at (11800, −17000) and (13400, −17000) show zero gap in head.
• 🟢 The TS-area notch stack is contiguous: Upper3 [5181.6, 6096] → Upper2 [6096, 6553.2] → Upper1 [6553.2, 7366], with no overlap. Upper3 was previously present in the tree but never #included or listed, so re-purposing its values regresses nothing. Deleting the commented-out //#include ".../backfillTSarea-W1UpperNotch2.txt" is pure cleanup — that file does not exist at head.
• 🟢 Both build systems are satisfied with no build-file change. The eight new files land in the existing Mu2eG4/geom/bldg/, which CMake installs wholesale via install(DIRECTORY geom DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/Offline/Mu2eG4) (Mu2eG4/CMakeLists.txt:307 at head), and which scons/muse resolves off MU2E_SEARCH_PATH from the source tree (Mu2eG4/src/SConscript present at head, data files not enumerated there). No plugin, no source file, no configure_file input added or removed, so no LIBRARIES mirroring is at stake. CI check_cmake is green.
• 🟢 No cross-repo change required. Mu2e/Production and Mu2e/mu2e-trig-config contain zero references to protonAbsorber_cylindrical* or mu2eHall_v0*; Production reaches this geometry only through JobConfig/cosmic/geom_cosmic_run1_a.txt → Offline/Mu2eG4/geom/geom_run1_a.txt, which needs no edit.
• 🟢 Units and conventions are consistent throughout: all lengths mm, angles in radians in .angles (-1.5708), matching the sibling rotated files.

---

Validation check

• Build/tests run: yes, by CI at this exact head. FNALbuild reports all green at e77630c6 merged into 1ce31dbc (job 3267): build (prof) 4 min 24 s, ceSimReco, g4test_03MT, transportOnly, POT, g4study, cosmicSimReco, cosmicOffSpill, ceSteps, ceDigi, muDauSteps, ceMix, rootOverlaps, g4surfaceCheck, trigger, check_cmake, clang-tidy 0/0, whitespace clean. For a geometry PR the two overlap/surface tests are the load-bearing ones, and they exercise the changed files — surfaceCheck.fcl → geom_SurfaceCheck.txt → geom_common_current.txt → geom_2021_PhaseI_v03.txt → both mu2eHall_v04.txt and protonAbsorber_cylindrical_v04.txt.
• Independent checks I ran (read-only, against the PR head and base tarballs):
  • gh api repos/Mu2e/Offline/tarball/e77630c6 and .../tarball/1ce31dbc, extracting Mu2eG4/geom/
  • a SimpleConfig include-chain parser over mu2eHall_v04.txt (383 files) → prefix-list completeness, x/y length parity, .angles presence for rotated solids, self-intersection and zero-area scan
  • sampled footprint-intersection × vertical-interval-overlap test, 24 changed volumes × 362 listed solids
  • vertical material-coverage profiles, base vs head, over the DS-area slab band, the central-stairwell column, and the TS-area W1 notch column
  • Limitation to state plainly: the overlap and coverage tests are grid-sampled (90×90 per pair; 300–400 random points per region), so sub-millimetre slivers below the sampling pitch would not be caught by them. Finding #2 was found by targeted probing at the seam coordinate, not by the scan. The green g4surfaceCheck is the better evidence at that scale.
• Config contract check: pass — no FHiCL touched; all SimpleConfig keys referenced by Mu2eHallMaker::loadSolids / loadRotSolids are present for every listed prefix.
• Cross-repo consistency: pass — nothing required in Production or mu2e-trig-config.
• PR hygiene: the description cites doc-db 57505 with three category bullets, which is a reasonable anchor, but there is no per-file mapping and no validation section, and the proton-absorber material change is a separate topic from the 26 hall/building files. Best-practice reminder, not a gate.

---

Residual risk

• All of this lands on the production geometry chain used by the Run-1/MDC campaigns and by Production's cosmic configs (geom_run1_a.txt). The berm steel→dirt fix alone removes ~81 t of high-Z material from the overburden, which will move cosmic-induced rates; campaign owners should expect a step change and re-baseline rather than treat it as a regression.
• The OPA support stainless→aluminium change alters the material budget inside the DS; if any tuned background estimate depends on protonAbsorber_cylindrical_v04, it silently changes meaning at merge.
• Concrete→dirt substitution in the DS-area first floor: over the S2 footprint, 177.8 mm of CONCRETE_MARS (2.35 g/cm³) becomes MBOverburden (2.15 g/cm³). Small (~8 % density over 178 mm), but it is a real shielding change, not just a gap fix.
• I could not independently verify the numbers against doc-db 57505; consistency with the drawings is taken on the author's word.

---

Author follow-ups

1. Confirm the OPA support material change (StainlessSteel316 → Al7075) is intended as an in-place edit of protonAbsorber_cylindrical_v04.txt rather than a new _v05, and note in the PR body which doc-db 57505 item backs it. Consider moving it to its own PR.
2. Align the dsAreaFirstFloorS / dsAreaFirstFloorS2 / dirtDsAreaFirstFloorS2 seam onto a single value (-12014.2) to close the 0.1 mm slit.
3. Say whether the ~0.1 mm standoffs (elevator shield, dirtCentralStairwellLower3, Middle2↔Middle3) are a deliberate anti-coincident-surface convention; if so apply it uniformly and comment it, otherwise round Middle5's -23376.25 → -23376.1 and centralStairwellUpperWallW2's 11617.325 → 11617.2.
4. Confirm psAreaUpper2N / dirtPsAreaUpper2N / psAreaHatchLower / dirtBeamlineBerm_Layer748a / _750a are meant to stay at 6502.40 now that psAreaUpperN_v02 moved to 6857.90.
5. Add one sentence on which part of the central stairwell is backfilled with MBOverburden (dirtCentralStairwellMiddle2..5) and which stays open.
6. Confirm dirtExtMonStairsGap.yPositions[1] = 150.1 is intended and not a typo for 306.05.
7. Tidy the vertex-label comments in dirtCentralStairwellMiddle5.txt and dsAreaUpper.txt, and fix the .ccl provenance header on backfillTSarea-W1UpperNotchUpper3.txt.
8. Best-practice reminder: please add a short validation section to the PR body (what you checked beyond CI — e.g. a GDML/event-display sweep of the touched regions) and, where practical, keep a PR to a single topic.

[sdifalco]

1. I agree that the validation of OPA supports geometry an materials deserves a dedicated PR. I have expunged it from this PR.
2. I have implemented the suggested fix
3. I have implemented the suggested fixes. It's true that the 0.1 mm safety gap is used to avoid volume interferences, so I reduced to less than 0.1 mm the gaps where possible and checked with surfaceCheck that there are no interferences
4. This is a deliberated choice to fills a gap without creating a new volume
5. This is in agreement with the drawing SC-19. At the time the central stairs volume have been created the volume under the steps was filled with concrete instead of MBOverburden to reduce the number of volumes, leaving some air gaps. These residual air gaps have now be filled with MBOverburden
6. yes it must be asymmetric to fit the basement of the Extinction Monitor stairs
7. ccl files are no longer used

[oksuzian]

PR Review Summary — second pass on "Aug 26 geometry updates" (#1918)

Reviewed at head 84674ab2 (2026-08-07). Prior review: 🟡 at e77630c6 (review 4879365261, 8 findings). The delta is four commits, e77630c6..84674ab2, touching 15 files: the OPA change reverted, three files deleted, and coordinate fixes. Every prior finding is accounted for below and verified in the geometry at this head rather than taken from the commit messages or the reply.

Decision

• 🟡 Comment. Every substantive item is resolved — the OPA material change is fully backed out, the 0.1 mm floor slit is closed exactly, and the two standoffs I flagged now sit at zero. Your answers on the deliberate items are good enough for me; I am not carrying them further. Two things keep this from being an approve, and neither is about the geometry: CI has not run at this head (mu2e/buildtest is still pending and rootOverlaps / g4surfaceCheck are the load-bearing tests for this PR), and the three file deletions left two #include lines pointing at files that no longer exist. Both are cheap. Ping me when CI is green and I will approve.

Scope understood (delta only)

• 5038da5b reverts protonAbsorber_cylindrical_v04.txt; cfdd3fc2/f4a756a8 delete dirtExtMonUpper.txt, dirtExtMonUpper_v02.txt, psAreaUpper2N.txt; 84674ab2 applies the coordinate fixes across 12 bldg/ files.

---

Findings

1. 🟡 [S2] Three files were deleted but two of them are still #included.

   • Evidence, at this head:
     • Mu2eG4/geom/mu2eHall.txt:83 — #include ".../bldg/psAreaUpper2N.txt", file deleted. The prefix is also still listed twice, at :195 ("building.psArea.upper2.N") and :346 ("dirt.psArea.upper2.N").
     • Mu2eG4/geom/mu2eHall_v02.txt:473 — #include ".../bldg/dirtExtMonUpper_v02.txt", file deleted.
     • dirtExtMonUpper.txt had no references at all — that deletion is clean, and it is the dead volume I flagged as out-of-scope last time, so thank you for taking it.
   • Impact: none today, and I want to be precise about why rather than overstate it. I parsed the include graph at base and at head: mu2eHall.txt and mu2eHall_v02.txt were already unloadable before this PR — between them they #include 17 files that do not exist at base (calorimeter_CsI.txt, protonBeamDump_v02.txt, extMonBitN.txt, dirtSRetainingWallFoot.txt, the dirtTempDirtBackfillPsArea*_v02 set, and others). So the eight legacy configs that reach them (geom_common_cd3_s3p2, geom_common_cd3_s4p2, geom_common_hayman_v2, geom_MARS_2019, geom_common_MARSrunMay17, geom_common_DOE_review_2017, geom_common_haymanLowerDensity, geom_common_TrackerShldStdyJun17) were already broken and this PR does not change that. Nothing in the live chain, in CI, or in Production is affected.
   • Suggested fix: delete the two #include lines and the two psArea.upper2.N prefix entries in mu2eHall.txt. It is four lines, it keeps the deletion self-consistent, and it means the next person auditing those legacy files has two fewer false leads.

2. ⚪ [S3] Vertex-label comments — carried over from finding 7, unaddressed (the files were not touched in this delta).

   • dirtCentralStairwellMiddle5.txt still labels xPositions as g1, g2, g4, g4 (no g3, g4 twice) against yPositions labelled h, h0, h1, h2.
   • dsAreaUpper.txt still labels indices 31/32 as h1/h2, colliding with the h1/h2 at indices 15/16.
   • Your answer that the .ccl files are no longer used settles the third part of that finding — the stale provenance header on backfillTSarea-W1UpperNotchUpper3.txt is then documentation of a retired workflow, not a wrong pointer. Worth deleting those headers wholesale someday, but not here.

---

Carry-forward accounting (vs review 4879365261 at e77630c6)

1. 🟢 [was S1] OPA support material — WITHDRAWN FROM THE PR, verified. protonAbsorber_cylindrical_v04.txt at this head is byte-identical to base 1ce31dbc (diff -q clean): oPASupportMaterialName, all six oPASupportMaterials, oPASupportSlatMaterials and crossSupportMaterial are back to StainlessSteel316. This was the right call — it takes a material-budget change to every production geometry out of a hall-geometry PR, and it can now get the validation it deserves on its own.
2. 🟢 [was S2] The 0.1 mm slit through the DS-area first floor — FIXED, verified. dsAreaFirstFloorS.yPositions[22,23] is -12014.2, and both dsAreaFirstFloorS2 and dirtDsAreaFirstFloorS2 now start at -12014.2 (was -12014.3). The seam is exact; the 41 m long, 0.1 mm wide air sliver is gone.
3. 🟡 [was S2] Sub-millimetre standoffs — MOSTLY FIXED, and the remainder is your call, accepted.
   • dsAreaElevatorShield: offsetFromFloorSurface.y = 1143.10, yHalfThickness = 1143.10 → bottom at exactly 0.00. Fixed.
   • dirtCentralStairwellLower3: 1260.45 ± 1260.45 → bottom at exactly 0.00. Fixed.
   • centralStairwellUpperWallW2: 11617.325 → 11617.2, now matching centralStairwellLowerWallN and tsAreaStairwell. Fixed.
   • Middle2 top (2673.3 + 152.35 = 2825.65) vs Middle3 bottom (3973.17 − 1147.465 = 2825.705): the gap is now 0.055 mm, down from 0.10 mm. That matches what you described — reduced below 0.1 mm where possible, kept non-zero to avoid coincident surfaces, and checked with surfaceCheck. That is a legitimate G4 practice and I am not going to argue it. It would still be worth one comment line in one of these files recording the convention, so the next reviewer does not re-derive this exchange.
   • Middle5 at -23376.25 — I withdraw this one. New evidence: -23376.25 is not an outlier, it is one of two consistently-used planes. centralStairwellUpperLanding.txt, centralStairwellUpperStairs2.txt and dirtCentralStairwellMiddle.txt all use -23376.25, while centralStairwellUpperWall{E,W} and Middle2/3/4 use -23376.1. Middle5 joining the landing/stairs family reads as deliberate, and none of those three files is touched by this PR. My original framing — "what should be one shared plane" — was wrong.
4. 🟢 [was S2] psAreaUpperN_v02 moving off 6502.40 — ANSWERED, accepted. You describe it as filling a gap without creating a new volume, and psAreaUpper2N.txt — the file I cited as still sitting at 6502.40 — is deleted in this PR. Confirmed it was reachable only from mu2eHall.txt, never from the live mu2eHall_v04 → v03 chain, so deleting it changes no production geometry (the leftover #include is finding 1).
5. 🟢 [was S2] Central-stairwell backfill — ANSWERED. Drawing SC-19; the volume under the steps was originally filled with concrete rather than MBOverburden to keep the volume count down, leaving air gaps, and dirtCentralStairwellMiddle2..5 now fill those. That is exactly the sentence I was asking for — please put it in the PR body, where it survives the comment thread.
6. 🟢 [was S3] dirtExtMonStairsGap asymmetry — ANSWERED. Deliberate, to fit the Extinction Monitor stairs basement. Not a typo.
7. ⚪ [was S3] Vertex labels — PARTIAL, now finding 2; the .ccl sub-item is answered.
8. 🟢 [was S3] Pre-existing dead dirt.extMon.upper — ACTED ON. Both dirtExtMonUpper.txt and dirtExtMonUpper_v02.txt are deleted, which is more than I asked for on an out-of-scope note. The leftover #include in mu2eHall_v02.txt is the only loose end (finding 1). The three self-intersecting polygons I mentioned in the same finding are untouched, as expected.

---

Verified 🟢 — no action needed

• 🟢 The live production chain is complete and self-consistent at this head. Re-parsed mu2eHall_v04 → v03 from the head tarball: 382 files, zero missing includes; the four prefix lists resolve to 255 bldg + 107 dirt + 14 rotated + 3 dirt.trap, and every prefix has a complete block (.name, .material, .xPositions, .yPositions, all three offsets, .yHalfThickness, plus .angles for rotated); no x/y length mismatch; no listed-but-undefined and no newly-defined-but-unlisted volume. The three deletions do not touch this chain.
• 🟢 I chased three apparent overlaps to ground and they are test artifacts, not findings. My grid overlap scan flagged dirt.central.stairwell.lower3 × building.tsArea.stairwell and dirt.central.stairwell.middle3 × building.central.stairwell.upper.wall.{e,w}. Running the identical test at e77630c6 reproduces all three with the same point counts — and rootOverlaps and g4surfaceCheck were green at that head. The delta moves those boundaries by ≤0.055 mm. So the flags come from my projected point-in-polygon test, not from a real solid intersection. Recording it so you know the check was run and resolved rather than skipped.
• 🟢 No cross-repo impact, re-confirmed. With the proton-absorber file reverted, this PR touches only Mu2eG4/geom/bldg/ and mu2eHall_v03.txt. Production reaches this geometry solely via JobConfig/cosmic/geom_cosmic_run1_a.txt → Offline/Mu2eG4/geom/geom_run1_a.txt → mu2eHall_v04.txt, which is intact; mu2e-trig-config has no geometry reference.
• 🟢 Both build systems still need no edit. No file is added in this delta and the three deletions are data files inside Mu2eG4/geom/bldg/, which CMake installs wholesale via install(DIRECTORY geom ...) and scons resolves off MU2E_SEARCH_PATH. No source, plugin or configure_file input changes.
• 🟢 Everything cleared in the first review that this delta does not touch still holds — the dirtNRetainingWallExtension_v02 steel→dirt fix (≈111 t → ≈30 t), the gap closures (TS-area W1 notch 514 → 32 mm, elevator shield 152.4 → now 0 mm), the rotated-solid wiring for dirt.extMon.stairs.gap, and the TS-area notch stack contiguity.

Validation check

• Build/tests run: not yet at this head. mu2e/buildtest at 84674ab2 is pending ("This test has not been triggered yet"); only jenkins/ghprb has reported. The combined status is pending, which is why the PR reads mergeable_state: unstable. The previous head e77630c6 was fully green including rootOverlaps and g4surfaceCheck — for a geometry PR those two are the evidence that matters, and they have not seen this head.
• Independent checks I ran (read-only, on the base/prev/head tarballs): full SimpleConfig include-graph parse of the whole Mu2eG4/geom tree at base and head to separate new from pre-existing broken includes; prefix-list completeness and x/y parity over the live mu2eHall_v04 chain; the seam and standoff arithmetic quoted above; grid footprint × vertical-interval overlap for the changed volumes against all 379 listed solids, cross-checked at e77630c6.
• Limitation, same as last time and worth repeating: my overlap scan is grid-sampled, so sub-millimetre slivers below the sampling pitch will not show up in it. g4surfaceCheck is the better instrument at that scale, and it has not run on this head.
• Config contract check: pass — no FHiCL touched; all SimpleConfig keys required by Mu2eHallMaker::loadSolids/loadRotSolids are present for every listed prefix in the live chain.
• Cross-repo consistency: pass.

Residual risk

• The berm StainlessSteel → MBOverburden fix still removes ~81 t of high-Z material from the overburden and the DS-area first-floor concrete → dirt substitution is still a real shielding change. Campaign owners should expect a step change in cosmic-induced rates and re-baseline rather than treat it as a regression. That was true last pass and reverting the OPA change does not affect it.
• Two legacy hall configs gain dangling includes on top of the ones they already had (finding 1). The risk is not that something breaks now, it is that mu2eHall.txt / mu2eHall_v02.txt drift further from repairable.
• Still taking consistency with doc-db 57505 on your word — I have no way to check the drawings.

Author follow-ups

1. Remove the two dead #include lines (mu2eHall.txt:83, mu2eHall_v02.txt:473) and the two psArea.upper2.N prefix entries at mu2eHall.txt:195,346 (finding 1).
2. Let CI finish — rootOverlaps and g4surfaceCheck are the ones I want to see green at this head before approving.
3. Move your answers on the stairwell backfill (SC-19) and the ExtMon stairs gap into the PR body; the comment thread is not where the next person will look.
4. Optional: one comment line recording the deliberate sub-0.1 mm standoff convention, and the vertex labels in finding 2.

[oksuzian]

@FNALbuild run build test

[FNALbuild]

⌛ The following tests have been triggered for 84674ab: build (Build queue - API unavailable)

[sdifalco]

I have to update dimension and position of Remote Handling Room south door, I am checking the numbers provided by George with what's in reduced_ExtShielsUpstream_v07.txt.
I will probably have to change ExtShielsUpstream_v07.txt to keep it aligned

[FNALbuild]

☀️ The build tests passed at 84674ab.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 84674ab at 1ce31db
build (prof)	✅	Log file. Build time: 04 min 21 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 0 files
clang-tidy	✅	0 errors 0 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 84674ab after being merged into the base branch at 1ce31db.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[sdifalco]

@FNALbuild

[sdifalco]

Remote handling room south door dimension and position fixed following George's findings (see updated doc-db 57505). I have also updated ExtShieldUpstream_v07.txt since this fix is common to the two geometries.
Surface check completed. All ready to be merged from my side.

[oksuzian]

PR Review Summary — third pass on "Aug 26 geometry updates" (#1918)

Reviewed at head faffc80f. Prior reviews: 🟡 at e77630c6 (review 4879365261, 8 findings) and 🟡 at 84674ab2 (review 4887335976, 2 open findings). The delta since the last pass is one commit, 84674ab2..faffc80f, touching two files and four lines: the Remote Handling Room south door. Every prior finding is re-checked at this head below, and the two conclusions I reached by withdrawal/attribution last time were re-derived from scratch rather than repeated.

Decision

• 🟡 Comment. Last pass I said I would approve once rootOverlaps and g4surfaceCheck went green. They did, at 84674ab2 (build 3273, both ✅) — that condition was met. But the head then moved, and the new commit is not a no-op: the resized door introduces one 🟠 [S1] that I do not think either of those tests can see, because both look for overlaps and what the new numbers create is a gap. One question to answer and, if the answer is "yes, re-seat it", two numbers to change. Happy to approve straight after.

Scope understood (delta only)

• faffc80f changes ExtShieldUpstream.dimsType20 from {609.6,4418,6426.2} to {609.6,3810,6400.8} and centerType20Box1 from {9381,-103,-12077.7} to {9392.9,-109.6,-12077.7}, identically in Mu2eG4/geom/ExtShieldUpstream_v07.txt and Mu2eG4/geom/reduced_ExtShieldUpstream_v07.txt.
• Reach: this is live production geometry, and more of it than the earlier bldg/ commits. reduced_…_v07.txt is pulled in by geom_run1_a.txt, geom_run1_a_stickman.txt, and therefore by geom_common.txt (→ geom_run1_a_stickman.txt), geom_run1_b_v01.txt, geom_SurfaceCheck_run1a.txt, and Production/JobConfig/cosmic/geom_cosmic_run1_a.txt. ExtShieldUpstream_v07.txt is pulled in by geom_run1.txt and geom_run2.txt. Verified by resolving the include graphs at this head.

---

Findings

1. 🟠 [S1] The door was resized about its old centre, so all three faces that used to be flush now stand off — the "closed" door has ~0.3 m of air under it, ~0.3 m over it, and 12.7 mm at the wall it closes against.

   • Evidence. ExtShieldUpstreamMaker::make halves the config dimensions (tempDoubleVec[itmp] *= (CLHEP::mm/2.0), with the comment "Divide dimensions by 2.0 because G4 boxes are created in terms of half-lengths"), and centerType20Box1 is "the center of the box in Mu2e coords". So:
     • was: half-lengths {304.8, 2209, 3213.1} about {9381, -103, -12077.7} → x ∈ [9076.2, 9685.8], y ∈ [-2312.0, 2106.0], z ∈ [-15290.8, -8864.6]
     • now: half-lengths {304.8, 1905, 3200.4} about {9392.9, -109.6, -12077.7} → x ∈ [9088.1, 9697.7], y ∈ [-2014.6, 1795.4], z ∈ [-15278.1, -8877.3]
   • The room around it, resolved from the live chain (geom_run1_a → mu2eHall_v04 → v03):
     • floorRemote (floorRemote_v02.txt, offsetFromFloorSurface.y = -76.2, yHalfThickness = 76.2) has its top at y = -2312.0, and its footprint covers 100% of the door footprint (3321/3321 sample points).
     • remoteHandlingCeiling (remoteHandlingCeiling_v03.txt, 4800.6 ± 381) has its bottom at y = +2107.6, footprint coverage again 100%.
     • remoteHandling (remoteHandling_v02.txt, 2133.6 ± 2286) spans y ∈ [-2464.4, 2107.6]; its polygon's face at z = -15290.8 (vertices 4→5, x from 7805.4 to 16949.4) is the NW end wall the door closes against — OpenDistance opens the door in +z, so OpenDistance = 0.0 is meant to be against that wall.
   • So the room's clear height is 2107.6 − (−2312.0) = 4419.6 mm = 14′6″ exactly. The old door was 4418 mm tall and sat with its bottom at exactly -2312.0 (on the floor) and its top 1.6 mm under the ceiling — a full-height plug, flush against the NW wall. The new door is 3810 mm = 12′6″, and at y = -109.6 it leaves 297.4 mm of HallAir below it and 312.2 mm above it; the 25.4 mm length reduction was split evenly about the unchanged z, leaving 12.7 mm between the door and the wall face at z = -15290.8. Nothing fills any of the three: I grid-tested the new door volume against all 379 hall solids and the other 28 ExtShieldUpstream boxes and there is no volume in the gaps (and no overlap either — see below).
   • Note the new dimensions are 2′ × 12′6″ × 21′0″, all exact — they read as correct drawing numbers. It is the seating that looks unintended: -109.6 is 7.4 mm off the room's vertical mid-plane (-102.2), i.e. the box was shrunk about roughly where it already was rather than re-placed.
   • Impact: a 2 ft thick CONCRETE_MARS shielding door with a continuous 0.61 m × 6.4 m slot under it and another over it is not a closed door. The physics consequence is modest — this is an internal partition in a service room well north of the detector, air on both sides — but it is in geom_common.txt and in the cosmic production geometry, so it is not a niche config, and it silently weakens a shielding boundary that used to seal. g4surfaceCheck and rootOverlaps will not catch this: both hunt for intersecting solids, and this is the opposite failure.
   • Suggested fix: if the door rests on the floor and closes against the NW wall, centerType20Box1 = {9392.9, -407.0, -12090.4} puts the bottom at -2312.0 and the closing face at -15290.8 with the new drawing dimensions unchanged (−2312 + 1905 = −407; −15290.8 + 3200.4 = −12090.4). Then the 609.6 mm now spare above the door is a header that wants concrete, so either extend the ceiling/wall down or say why air is right there. If instead the door really does hang clear of the floor, please put that in the PR body with the elevation it comes from — it is the kind of thing the next reviewer will re-flag.

2. 🟡 [S2] Three deleted files, two of them still #included — carried over from finding 1 of review 4887335976, unaddressed (the delta did not touch these files).

   • Verified again at faffc80f: Mu2eG4/geom/mu2eHall.txt:83 still #includes bldg/psAreaUpper2N.txt and still lists the prefix twice, at :195 ("building.psArea.upper2.N") and :346 ("dirt.psArea.upper2.N"); Mu2eG4/geom/mu2eHall_v02.txt:473 still #includes bldg/dirtExtMonUpper_v02.txt; all three deleted files are absent from the tree.
   • Impact unchanged and still bounded — see the re-derivation in the verified section: those two legacy hall files were already unloadable before this PR, and the count of dangling includes in each is unchanged by this PR. Nothing live is affected.
   • Suggested fix: four lines — drop the two #includes and the two psArea.upper2.N prefix entries.

3. 🟡 [S2] Pre-existing, not introduced here, and explicitly not gating — the door open/close mechanism moves the wrong box, and this PR is the natural place to notice it.

   • Evidence: GeometryService/src/ExtShieldUpstreamMaker.cc builds every box, then does CLHEP::Hep3Vector WorkingPosition = sites.back(); … sites.pop_back(); sites.push_back(ShieldDoorCenter); where ShieldDoorCenter = {x+FrameGap, y, z+OpenDistance}. With numberOfBoxTypes = 21, nBoxType20 = 1 and nBoxType21 = 3, sites.back() is Type21Box3 at {2531.4,-252.35,2810.65} — the North-East external TS shielding — not the Type20 door this PR is editing.
   • Inert today: OpenDistance and FrameGap are 0.0 in every file that defines them (ExtShieldUpstream_v0{6,7}.txt, reduced_…_v0{6,7}.txt) and nothing else in the repo overrides them, so the pop/push is a no-op. It is wrong the moment anyone opens the door for a study — they would displace TS shielding and leave the door shut. Present since the mechanism landed (74290484, 2023) and in v06 as well as v07, so it is not yours.
   • While you are in the file: nBoxType21 = 3; // Remote handling room door is a copy-paste comment — Type21 is the NE external TS shielding.

4. ⚪ [S3] Vertex-label comments — carried over from finding 2 of review 4887335976, unaddressed.

   • bldg/dirtCentralStairwellMiddle5.txt still labels xPositions g1, g2, g4, g4 (no g3, g4 twice).
   • bldg/dsAreaUpper.txt still labels the last three yPositions h1, h2, j0 where the matching xPositions are i8, i9, j0, so entries 32 and 33 of 34 disagree between the two lists (and re-use h1/h2, already spelled H1/H2 at entries 16/17).

---

Carry-forward accounting

vs review 4887335976 (84674ab2):

1. 🟡 [was S2] Dangling #includes after the deletions — UNADDRESSED, now finding 2.
2. ⚪ [was S3] Vertex labels — UNADDRESSED, now finding 4.
3. The approval condition I stated ("ping me when CI is green") — MET at 84674ab2 (build 3273: rootOverlaps ✅, g4surfaceCheck ✅, all 21 checks ✅) and then invalidated by faffc80f. See Validation.

vs review 4879365261 (e77630c6) — all eight were closed out in review 4887335976; re-verified at this head that the closures still hold:

1. 🟢 [was S1] OPA support material — still withdrawn from the PR: protonAbsorber_cylindrical_v04.txt does not appear in the PR's 34-file list at this head.
2. 🟢 [was S2] DS-area first-floor 0.1 mm slit — still closed: dsAreaFirstFloorS, dsAreaFirstFloorS2 and dirtDsAreaFirstFloorS2 all sit on -12014.2, no 12014.3 anywhere in the three.
3. 🟢/🟡 [was S2] Sub-millimetre standoffs — still as accepted last pass: dsAreaElevatorShield 1143.10 ± 1143.10 and dirtCentralStairwellLower3 1260.45 ± 1260.45 both bottom out at exactly 0.00; centralStairwellUpperWallW2 is on 11617.2, matching centralStairwellLowerWallN and tsAreaStairwell. The 0.055 mm Middle2/3 gap stands as your deliberate convention.
4. 🟢 [was S2] psAreaUpperN_v02 — answered; psAreaUpper2N.txt deleted.
5. 🟢 [was S2] Central-stairwell backfill (drawing SC-19) — answered.
6. 🟢 [was S3] dirtExtMonStairsGap asymmetry — answered.
7. ⚪ [was S3] Vertex labels — see finding 4.
8. 🟢 [was S3] Pre-existing dead dirt.extMon.upper — acted on.

Re-derived, not inherited

• 🟢 The Middle5 -23376.25 withdrawal stands. Re-derived from the tree at this head, not from the earlier note: -23376.25 appears in centralStairwellUpperLanding.txt, centralStairwellUpperStairs2.txt, dirtCentralStairwellMiddle.txt, dirtCentralStairwellMiddle5.txt; -23376.1 in centralStairwellUpperWall{E,W}.txt and dirtCentralStairwellMiddle{2,3,4}.txt. All nine are in the live mu2eHall_v03 chain and all nine carry offsetFromMu2eOrigin.x = 947.4, so the raw numbers are directly comparable — two coexisting planes, and Middle5 joining the landing/stairs family is consistent, not an outlier.
• 🟢 The dangling-include attribution stands, with my own numbers. I re-parsed both include graphs at the merge base (1ce31dbc) and at faffc80f: mu2eHall.txt has 4 missing includes at base and 4 at head; mu2eHall_v02.txt has 14 at base and 14 at head. This PR is net-neutral on both counts — it repairs pre-existing dangles (e.g. it adds backfillTSarea-W1UpperNotchUpper2.txt, missing at base) while its deletions create the two in finding 2. Both files were already unloadable before this PR; the live chain is not.

Verified 🟢 — no action needed

• 🟢 The two v07 files were kept in lockstep, exactly as you said. The 84674ab2..faffc80f patch is character-for-character the same two lines in ExtShieldUpstream_v07.txt and reduced_ExtShieldUpstream_v07.txt; diff against main for each file shows only those two lines.
• 🟢 No new overlap is introduced by the door change. Point-in-polygon grid test (41 × 81 over the footprint) of both the old and the new door volume against all 379 live hall solids, plus 3-D interval overlap against the other 28 ExtShieldUpstream boxes: zero hits in both cases. The new box does reach 11.9 mm further north (x max 9697.7 vs 9685.8) but stays clear of the remoteHandling concrete (0/4141 sample points inside its polygon). Consistent with your local surface check passing — and, again, that is exactly why the check cannot be the evidence for finding 1.
• 🟢 The live production chain is complete and self-consistent at this head. Re-parsed geom_run1_a → mu2eHall_v04 → v03: zero missing includes; the four prefix lists resolve to 255 bldg + 107 dirt + 14 rotated + 3 dirt.trap = 379; every prefix has a complete key block (.name, .material, .xPositions, .yPositions, all three offsets, .yHalfThickness); no xPositions/yPositions length mismatch; no duplicate volume name. Same for geom_run1.txt, geom_run2.txt, geom_run1_a_stickman.txt.
• 🟢 Both build systems still need no edit — checked, not assumed. The delta modifies two existing data files under Mu2eG4/geom/; nothing is added or removed. CMake installs the directory wholesale (Mu2eG4/CMakeLists.txt:307, install(DIRECTORY geom DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/Offline/Mu2eG4)), there is no SConscript under Mu2eG4/ at all so scons resolves these off MU2E_SEARCH_PATH, and there is no source, plugin LIBRARIES, or configure_file input in the delta. check_cmake was ✅ at 84674ab2.
• 🟢 Cross-repo consistency: pass. Production reaches the changed file through JobConfig/cosmic/geom_cosmic_run1_a.txt → Offline/Mu2eG4/geom/geom_run1_a.txt → reduced_ExtShieldUpstream_v07.txt; the chain is intact and needs no Production edit. mu2e-trig-config has no geometry reference.

Validation check

• Build/tests run: not at this head. At faffc80f, mu2e/buildtest is pending — "This test has not been triggered yet"; only jenkins/ghprb has reported, so the combined status is pending. For the record, 84674ab2 was fully green (build 3273, all 21 checks including rootOverlaps and g4surfaceCheck), so the condition from my last review was genuinely satisfied — it just no longer applies to the code in the branch. Your @FNALbuild comment at 08:08 had an empty body; the trigger phrase is @FNALbuild run build test.
• Independent checks I ran (read-only, on the merge-base and faffc80f tarballs): SimpleConfig include-graph resolution for mu2eHall{,_v02,_v03,_v04}.txt and all four geom_run* configs at both commits; prefix-list completeness and x/y parity over the live chain; the box-half-length arithmetic above against ExtShieldUpstreamMaker.cc; footprint coverage of floorRemote and remoteHandlingCeiling over the door; grid overlap of old and new door against 379 solids + 28 boxes; OpenDistance/FrameGap override search across all .txt/.fcl.
• Limitation: my overlap test is grid-sampled, so slivers below the sampling pitch would not show. That is g4surfaceCheck's job, and it has not seen this head.
• Config contract check: pass — no FHiCL touched; all keys ExtShieldUpstreamMaker reads for types 1–21 are present in both files.
• Cross-repo consistency: pass.

Residual risk

• Finding 1 is the only one that changes physics at this head, and it is a quiet change: no test in the suite fails on a missing shield, so if the seating is wrong it merges silently and stays wrong.
• Unchanged from the previous passes, and worth repeating for campaign owners rather than treating as a regression: the berm StainlessSteel → MBOverburden fix removes ~81 t of high-Z material from the overburden, and the DS-area first-floor concrete → dirt substitution is a real shielding change. Expect a step change in cosmic-induced rates and re-baseline.
• Two legacy hall configs gain dangling includes on top of the ones they already had (finding 2). Nothing breaks now; the cost is that mu2eHall.txt / mu2eHall_v02.txt drift further from repairable.
• Consistency with doc-db 57505 and George's numbers is still taken on your word — I have no way to read the drawings, which is exactly why finding 1 is a question about seating and not about the dimensions.

Author follow-ups

1. Confirm or correct the door seating (finding 1). If it rests on the floor and closes against the NW wall: centerType20Box1 = {9392.9, -407.0, -12090.4} in both v07 files, and say what fills the 609.6 mm above it. If the standoffs are real, one line in the PR body with the source elevation.
2. Trigger CI at this head with @FNALbuild run build test — and please note for the record that rootOverlaps/g4surfaceCheck green is necessary but not sufficient for finding 1.
3. Remove the two dead #include lines (mu2eHall.txt:83, mu2eHall_v02.txt:473) and the two psArea.upper2.N prefix entries (mu2eHall.txt:195,346) (finding 2).
4. Optional, and separable into its own PR: sites.back() in ExtShieldUpstreamMaker.cc and the nBoxType21 comment (finding 3); the vertex labels (finding 4); and moving your SC-19 / ExtMon-stairs answers from the comment thread into the PR body.

[sdifalco]

1. the answer is yes: the new dimension and position (including gaps) of the remote handling room south door are intentional and close to final even if 'as built' reality is still not available. Last message from George: 'the precise height of that stack of materials will not be set until the steel baseplates are installed and leveled, and the grout is injected beneath those steel baseplates.'
2. For what I see mu2eHall.txt is obsolete: Mu2eG4/geom/geom_run1_a.txt (that is included also for run1b) calls mu2eHall_v03.txt and this is where I have delete the includes of the obsolete files.

[oksuzian]

@FNALbuild run build test

[FNALbuild]

⌛ The following tests have been triggered for faffc80: build (Build queue - API unavailable)

[FNALbuild]

☀️ The build tests passed at faffc80.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged faffc80 at a126eb4
build (prof)	✅	Log file. Build time: 08 min 49 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 0 files
clang-tidy	✅	0 errors 0 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at faffc80 after being merged into the base branch at a126eb4.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.