Size the degrader mother volume to its contents - #1927
Merged
Conversation
The degrader mother half-width came from 2*filter_hl + frame_hl + 1 while its children were placed from a different expression, leaving the mother oversized and overrunning its contents downstream. Sizes it as filter_hl + frame_hl + 0.1 and places the filter at its upstream edge with the frame directly downstream. No material moves. The mother volume is DSVacuum sitting inside DS2Vacuum, which is also DSVacuum, so resizing and re-centring it displaces nothing; and the filter, frame and rod keep identical absolute z, read out of the gdml dumps -- nominal filter z = 4236.00 mm, frame and rod z = 4243.35 mm; with geom_run1_b_v40.txt filter z = 4243.75 mm, frame and rod z = 4258.85 mm. Their offsets inside the mother change only to compensate for the mother's own shift. The mother half-width goes 9.35 -> 7.45 mm in nominal geometries and 24.85 -> 15.20 mm with geom_run1_b_v40.txt's 1.75 cm plate, and its centre moves upstream by 0.90 mm and 8.65 mm respectively. On v40 the old downstream face sat at z = 4283.70 mm and overlapped protonabs3 by 3.7 mm and degraderSupportPlate by 2.3 mm. A surface-check run (g4.doSurfaceCheck over 10486 volumes) reports both overlaps before the change and none after. degraderCounterweight is deliberately left at its original expression, z0 + 2*filter_hl + frame_hl. That is a one-line deviation from the Run1B branch, which retied it to the new mother-centre expression and so moved it 8.65 mm out of plane with the rod it counterbalances on v40. Leaving it alone costs nothing -- the v40 surface check still reports zero overlaps -- and keeps the counterweight coplanar with the frame and rod. Note the degrader IS built in nominal running -- degrader_v02.txt sets degrader.build = true, and 'off by default' means rotation = 120 deg, out of the beam. The nominal gdml diff is therefore non-empty but bounded: 39 lines against both gdmldump.fcl and gdmldump_run1_a.fcl, covering the degraderOutline box z, the Degrader mother placement, the three compensating child offsets, and the reordering that follows from placing the filter before the frame. Every volume outside the degrader assembly is byte-identical. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
michaelmackenzie
approved these changes
Aug 9, 2026
michaelmackenzie
left a comment
Contributor
There was a problem hiding this comment.
This looks good to me, bringing in the degrader positioning fixes
Collaborator
|
☀️ The build tests passed at fd1a90b.
N.B. These results were obtained from a build of this Pull Request at fd1a90b after being merged into the base branch at 1891b32. For more information, please check the job page here. |
sdifalco
approved these changes
Aug 10, 2026
sdifalco
left a comment
Collaborator
There was a problem hiding this comment.
The suggested fix solves the problem
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sizes the pion degrader's mother volume to its contents.
The bug
The mother's half-width was computed as
2*filter_hl + frame_hl + 1while itschildren were placed from a different expression, so the mother overran its
contents downstream — by 1.9 mm in nominal geometries and 9.65 mm with
geom_run1_b_v40.txt, whose filter is 8.75 mm half-length rather than 1.00 mm.On v40 that overrun produced two real Geant4 overlaps:
Both reproduce exactly from the geometry constants. The support-plate case:
the old v40 mother's downstream face sits at
4258.85 + 24.85 = 4283.70, andthe plate's front face at
4235 + 245 - 186 - 6.25 - 0.1 - 6.25 = 4281.40—a 2.30 mm overlap, matching what Geant4 reports.
Nominal was never affected: its mother face at 4252.70 is already 8.7 mm clear
of a plate face at 4261.40.
The fix
Size the mother as
filter_hl + frame_hl + 0.1and place the filter at itsupstream edge with the frame directly downstream. With surface checking
enabled (
g4.doSurfaceCheck = true), v40 goes from 2 overlaps to 0.Effect on nominal running
The degrader is built in nominal geometries —
degrader_v02.txtsetsdegrader.build = true, and "off by default" meansrotation = 120.0, swungout of the beam rather than absent. So this is not dead code and the nominal
gdml dump does change. It changes in a bounded way:
No material moves. The
Degradermother is filled withDSVacuumand sitsinside
DS2Vacuum, which is alsoDSVacuum— resizing it displaces nothing.The filter, frame, rod and counterweight all keep their exact absolute z:
The normalized gdml diff against
geom_common.txtandgeom_run1_a.txtis 39lines each and identical between them. 34 of those lines are file reordering
(the filter is now emitted before the frame;
degraderFrame's solid isbyte-identical). The remaining changes are the
degraderOutlinebox dimension,the
degraderMotherplacement, and three compensating child offsets that existprecisely so the absolute positions above stay fixed. x and y are untouched
throughout, and no volume outside the degrader assembly appears in either diff.
Step boundaries do shift even where material does not, so re-simulations will
not be bit-reproducible against earlier output.
One deliberate deviation from the Run1B branch
The branch also rewrote
location2InMu2eto reuse the mother-centreexpression, which dragged
degraderCounterweightupstream by 0.90 mm innominal and 8.65 mm on v40 — leaving it non-coplanar with the rod it
counterbalances. That reads as incidental rather than intended, so this PR
keeps the original
dgr_z0 + 2.0*filterDims.at(2) + frameDims.at(2). Neitheroverlap involves the counterweight, and the 0-overlap result was re-measured
after the revert to confirm the fix still holds. @sdifalco / Run1B authors:
please confirm this was not deliberate.
Minor, noted not fixed
The filter's upstream face is exactly flush with the mother wall — all 0.2 mm
of slack sits downstream. Legal and overlap-free, but coincident surfaces are
generally discouraged, and on v40 that filter is in the beam. Happy to bias the
filter 0.1 mm downstream if reviewers prefer.