feat(geom): add Run1B production geometry and virtual detector ids - #1923
feat(geom): add Run1B production geometry and virtual detector ids#1923oksuzian wants to merge 1 commit into
Conversation
|
☀️ The build tests passed at b4620c6.
N.B. These results were obtained from a build of this Pull Request at b4620c6 after being merged into the base branch at 1891b32. For more information, please check the job page here. |
There was a problem hiding this comment.
I suggest to delete EMC_Source, EMC_Source2 and EMC_0_Front
michaelmackenzie
left a comment
There was a problem hiding this comment.
This looks good to me
b4620c6 to
615cf5c
Compare
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 615cf5c: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 615cf5c.
N.B. These results were obtained from a build of this Pull Request at 615cf5c after being merged into the base branch at 1891b32. For more information, please check the job page here. |
615cf5c to
2ce8202
Compare
Adds geom_run1_b_v40.txt and its DS-on counterpart, a gdml dump driver for v40, and 19 tracker FEB virtual detector identifiers (117-135), together with the code that registers and places them. The FEB virtual detectors are ported from the Run1B branch behind a new configuration key, hasTrackerFEBVirtualDetectors, which defaults to false and is set by no geometry file in the repository, so no existing geometry is affected. This deliberately differs from the Run1B branch, which gates the same code on TrackerHasBrassRings -- a key about brass rings in the tracker, not about virtual detectors, and one set true in tracker_v4 through tracker_v7, i.e. in every current tracker geometry. On the branch these detectors are therefore built in nominal running; here they are strictly opt-in. geom_run1_b_v40.txt does not set the key either: the capability ships, opting in is a separate one-line decision. The unguarded cout diagnostics that came with the branch code are folded into the verbosityLevel > 0 blocks used by the surrounding code. The placement loop in constructVirtualDetectors.cc is entered only when VirtualDetectorMaker has registered the identifiers, so with the key off it does no work at all. VirtualDetectorId::isFEBTracker() is a three-line enum-range predicate matching the existing isTrackerFront()/isTrackerBack() accessors in the same header. geom_common.txt is untouched, so nominal running is unaffected -- verified by normalized gdml dumps of geom_common.txt and geom_run1_a.txt being byte-identical to main (13767 and 14355 volumes), and by a plain v40 dump containing zero FEB volumes. With the key forced true on top of v40 in a scratch geometry, exactly 19 FEB volumes appear (copy numbers 117-135) and Geant4 reports no overlaps. The new identifiers are appended before lastEnum, so no existing enumerator changes position or value. VIRTUALDETECTORID_NAMES gains 19 matching strings in the same order, keeping the BOOST_STATIC_ASSERT in VirtualDetectorId.cc:65 satisfied at 136 == 136. Repairs a dangling cross-repo reference: Production main's Tests/Run1BReco.fcl already points at geom_run1_b_v40.txt, which exists only on the Run1B branch today. Per review, the EMC_Source, EMC_Source2 and EMC_0_Front identifiers carried on the Run1B branch are not included. The first two served a study calorimeter between Coll5 and the tracker rather than production hardware, and EMC_0_Front duplicates the existing EMC_0_FrontIn and EMC_0_FrontOut detectors that already back isDisk0(). None of the three is referenced by any code, fcl or geometry file. No EMC code is ported from the branch either. Four commented-out blocks are dropped from geom_run1_b_v40.txt. They recorded an abandoned attempt to extend DS2Vacuum over the tracker, and the first of them -- tracker.inDS2Vacuum -- is read by no code on main, so uncommenting it would have silently done nothing. The v40 gdml dump is byte-identical with and without them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2ce8202 to
7523dd0
Compare
|
@FNALbuild run build test |
|
@sdifalco Thanks — agreed on both counts, and all three identifiers are removed as of 615cf5c. Checking before cutting them, your case was if anything stronger than stated: The PR now adds 19 identifiers rather than 22, all This also removes the only reason for a follow-up PR that would have registered and placed those virtual detectors, so that work is dropped rather than deferred. One addition since your review, in Since that is 75 lines of C++ added after the green build test at 615cf5c, I |
|
⌛ The following tests have been triggered for 7523dd0: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 7523dd0.
N.B. These results were obtained from a build of this Pull Request at 7523dd0 after being merged into the base branch at 5c9ca42. For more information, please check the job page here. |



Ports the Run1B production geometry to main.
geom_common.txtis deliberately not changed — main keepsgeom_run1_a_stickman.txtas its default. That was the review comment thatblocked #1849, and it is addressed by construction here.
Why
Production main's
Tests/Run1BReco.fcland the prodtools Run1B digi/recotemplates already reference
Offline/Mu2eG4/geom/geom_run1_b_v40.txt, whichtoday exists only on the
Run1Bbranch. This repairs that dangling cross-reporeference.
Only v40 is ported
Run1B has two stopping targets: the thin 37-foil target shared with Run1A, and
a disk at the face of TS5.
geom_run1_b_v40.txtmodels this correctly — itinherits
geom_run1_a.txtuntouched, so the 37 foils and their supportstructure survive, and adds a two-piece aluminium assembly at the TS5 face (the
TSdA as a 600 mm plate with a 135 mm aperture at z = 4195, and the pion degrader
repurposed as a 150 mm mobile target at z = 4235).
ds_on_v40is v40 with themobile target rotated out of the beam.
The earlier v01–v06 line instead overrode
stoppingTarget.radiito a single600 mm disk, replacing the foil target rather than adding to it. v40
superseded that line and is what the Run1Ban and Run1Bap campaigns run, so only
v40 is ported here.
Everything v40 needs already exists on main — no
constructTSdA.cc,constructStoppingTarget.ccorMu2eWorld.ccchanges are required. Confirmedfrom the dump: v40 yields
TSdA4at rmax 600 / rmin 135 / z 17.5 inStoppingTarget_Al(nominal gives 525 / 235 / 50.8), and its stopping-targetfoil count is identical to
geom_run1_a.txt.Tracker FEB virtual detectors, off by default
19 identifiers (117–135) and the code that builds them: annular virtual
detectors on the upstream face of every second tracker plane's front-end board,
plus one behind the last plane.
These are gated on a new key,
hasTrackerFEBVirtualDetectors, defaultingfalse, which no geometry file sets. This deliberately differs from the
Run1Bbranch, which gates them on
TrackerHasBrassRings— a key settrueintracker_v4/v5/v6/v7.txt, i.e. every current geometry, so on the branch thesedetectors are built in nominal running. Re-gating keeps the capability available
without changing anyone's simulation.
The registration block is the only place the key is read; placement follows via
the existing
vdg->exist(vdId)guard and is additionally fenced behindvdg->exist(Tracker_FEB_0_SurfIn), so the disabled path constructs nothing andperforms no geometry lookups. Diagnostic output is behind
verbosityLevel > 0,matching the surrounding code.
Enum safety
The identifiers are appended before
lastEnum, so no existing enumeratorchanges position or value and existing art files stay readable.
VIRTUALDETECTORID_NAMESgains 19 matching strings in the same order; theBOOST_STATIC_ASSERTatVirtualDetectorId.cc:65is satisfied at 136 == 136,verified pairwise across all 136 entries. A survey of
lastEnumconsumers foundno fixed-size array dimensioned on a literal, no persisted format with a baked-in
width, and no switch assuming a maximum id.
Per review, the branch's
EMC_Source,EMC_Source2andEMC_0_Frontidentifiers are not included — the first two served a study calorimeter
between Coll5 and the tracker rather than production hardware, and
EMC_0_Frontduplicates the existing
EMC_0_FrontIn/EMC_0_FrontOutthat already backisDisk0().Verification
Normalized gdml dumps (Geant4 pointer suffixes stripped) of both nominal
geometries are byte-identical to main:
geom_common.txt85b9f421823ab803c4250e95214ff8f1geom_run1_a.txt1d0cbf23ebbae35a2c14660cc535f90bThe harness was validated before being trusted: two dumps of the same unchanged
geometry are byte-identical after normalization, while the raw pre-normalization
dumps differ by 125,118 lines from pointer addresses alone.
The FEB detectors were also exercised in the enabled state — a scratch geometry
setting
hasTrackerFEBVirtualDetectors = trueon top of v40 produces exactly 19volumes at copy numbers 117–135 with no Geant4 overlaps, while a plain v40 dump
produces none and is byte-identical to v40 before this change.