Skip to content

Add optional protonabsorber.zStartInMu2e: absolute IPA position - #1913

Open
oksuzian wants to merge 1 commit into
Mu2e:mainfrom
oksuzian:ipa-absolute-position
Open

Add optional protonabsorber.zStartInMu2e: absolute IPA position#1913
oksuzian wants to merge 1 commit into
Mu2e:mainfrom
oksuzian:ipa-absolute-position

Conversation

@oksuzian

@oksuzian oksuzian commented Aug 1, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The MECO-style inner proton absorber is placed relative to the stopping
target: MECOStyleProtonAbsorberMaker computes targetEnd from the live
StoppingTarget and derives everything from it — body placement, DS2/DS3
segmentation, the cone-radius interpolation anchor, and the IPA
support-wire ring positions. But the IPA is fixed hardware;
protonAbsorber_cylindrical_v04.txt itself documents
distFromTargetEnd = 625.; //mu2e z positions are 6901-7901 mm.

Anyone varying stopping-target geometry gets a silently displaced
absorber. In our stopping-target optimization study a longer foil stack
dragged the IPA 133.33 mm downstream as a rigid body (measured with
protonabsorber.verbosityLevel = 1: 7034.35–8034.35 vs the design
6901.02–7901.02) through 414 grid evaluations before it was noticed. For
a cylindrical IPA this is exactly compensable by adjusting
distFromTargetEnd; for the conical variant it is not (the taper anchor
moves with the target) — hence a first-class option.

Change

New optional key protonabsorber.zStartInMu2e. When present, the maker
derives its reference plane from the given absolute z
(targetEnd = zStartInMu2e - distFromTargetEnd), so the absorber's
upstream end lands exactly at the given z and its full geometry (length,
DS2/DS3 split, cone radii, support wires) is independent of the stopping
target. When absent — the default everywhere — the new branch never
executes and output is bit-identical to today. One commented example
added to protonAbsorber_cylindrical_v04.txt.

Validation (Offline v13_32_10 + SimJob/Run1Bap backing)

Six single-event G4 runs with full surface check
(protonabsorber.verbosityLevel = 1), stopping-target stack extents
400 / 800 / 1100 mm, each extent probed twice — config-compensated
distFromTargetEnd (no new key) vs stock 625 + zStartInMu2e = 6901.02:

probe mechanism absorber Z extent printed overlaps
extent 400, expression distFromTargetEnd = 825.0 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0
extent 800, expression distFromTargetEnd = 625.0 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0
extent 1100, expression distFromTargetEnd = 475.0 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0
extent 400, option only zStartInMu2e = 6901.02, dist = stock 625 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0
extent 800, option only zStartInMu2e = 6901.02, dist = stock 625 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0
extent 1100, option only zStartInMu2e = 6901.02, dist = stock 625 constructProtonAbsorber protonabs1 Z extent in Mu2e : 6901.02, 7901.02 0

All six print the identical absorber extent 6901.02–7901.02 with zero
overlaps. With the key unset, a golden-parity harness (real G4 preflight
replay) reproduces baseline output unchanged.

🤖 Generated with Claude Code

The MECO-style inner proton absorber is placed relative to the stopping
target (targetEnd), but it is fixed hardware -- the geometry file itself
documents 'mu2e z positions are 6901-7901 mm'. Studies that vary the
stopping-target geometry silently drag the absorber (and its support-wire
rings) with it. When the new key is set, the maker derives its reference
plane from the given absolute z instead of the live target; unset, the
code path is untouched and output is bit-identical.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R5HnfdYMwXXrJGAkYVE48c
@FNALbuild

Copy link
Copy Markdown
Collaborator

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

  • GeometryService
  • Mu2eG4

which require these tests: build.

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

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

About FNALbuild. Code review on Mu2e/Offline.

@FNALbuild

Copy link
Copy Markdown
Collaborator

☔ The build is failing at a894d5d.

scons: *** [build/al9-prof-e29-p103/Offline/tmp/CosmicReco/src/LineFinder_module.os] Error 1
Test Result Details
test with Command did not list any other PRs to include
merge Merged a894d5d at e9b2fbd
build (prof) Log file.
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 1 files
clang-tidy ➡️ 0 errors 59 warnings
whitespace check no whitespace errors found

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

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.

@FNALbuild

Copy link
Copy Markdown
Collaborator

📝 The HEAD of main has changed to ed58b12. Tests are now out of date.

@oksuzian

oksuzian commented Aug 1, 2026

Copy link
Copy Markdown
Collaborator Author

@FNALbuild run build test

@FNALbuild

Copy link
Copy Markdown
Collaborator

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

@FNALbuild

Copy link
Copy Markdown
Collaborator

☀️ The build tests passed at a894d5d.

Test Result Details
test with Command did not list any other PRs to include
merge Merged a894d5d at ed58b12
build (prof) Log file. Build time: 10 min 46 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 1 files
clang-tidy ➡️ 0 errors 59 warnings
whitespace check no whitespace errors found

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

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.

@AndrewEdmonds11 AndrewEdmonds11 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is OK with me as a patch. I think ideally we would number a new version and then have new code that would not refer to the target position at all but I appreciate that that would be a lot of effort

// stopping target; distFromTargetEnd then only anchors the cone-radius
// interpolation. Unset (default): stock target-relative behavior.
if ( _config.hasName("protonabsorber.zStartInMu2e") ) {
targetEnd = _config.getDouble("protonabsorber.zStartInMu2e") - distFromTargetEnd;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the distFromTargetEnd parameter still need to be set correctly? By default it is zero and so here the targetEnd would be the starting position of the IPA...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants