Skip to content

KKExtrap: clamp the calo search time into the trajectory range - #2076

Merged
oksuzian merged 1 commit into
Mu2e:mainfrom
oksuzian:fix-tocalodisk-timerange
Oct 28, 2026
Merged

oksuzian merged 1 commit into
Mu2e:mainfrom
oksuzian:fix-tocalodisk-timerange

Conversation

@oksuzian

Copy link
Copy Markdown
Collaborator

Summary

Fixes the nightly reco_03 crash: LoopHelixFit/KKUe throws Invalid Time Range on run 1430, subrun 1652, event 852 of dig.mu2e.CeMLeadingLogMix1BB.MDC2025au_best_v1_3.001430_00001612.art.

KKExtrap::toCaloDisk (added in #2059) searches for calorimeter intersections between tref and the end of the trajectory in the direction of the calorimeter. tref is ftraj.t0(), captured before any extrapolation. PiecewiseTrajectory::t0() is the helix time at z=0. It is not guaranteed to lie inside the trajectory's time range, for example for a track whose hits are all in one half of the tracker. When it lies outside, TimeRange(ftraj.range().begin(), tref) is reversed and its constructor throws.

On event 852, the second KKUe track has tref = 466.92 ns and a trajectory range of 480.92 to 587.87 ns. ExtrapolateToZ does not extend it towards the calorimeter, because the track's start is heading away from the calorimeter, so the range never reaches back to tref.

The fix clamps tref into the trajectory range with TimeRange::forceRange, as toTrackerPerimeter already does for its own reference time (c4673ba). In every case where tref was already inside the range, it is unchanged, so the output is unchanged. In the case that used to throw, the search range is empty and the track gets no calorimeter intersections, which is correct because the track never reaches the calorimeter. The existing toCaloDisk debug printout now also prints tref and the trajectory range.

Testing

Offline main 77c4233d with this change, built with Production 4479f3fa and mu2e-trig-config a664b74b (the same three commits as the nightly build museCIBuild/main/77c4233d_4479f3fa_a664b74b), envset p109. The build had no warnings.

  • Event 852 alone: the nightly build exits with Invalid Time Range, as in the nightly. With this change it exits 0. With ToCaloD0/ToCaloD1 off for KKUe only, the nightly build also exits 0, which shows the calorimeter step is the cause.
  • The whole reco_03 input, all 16508 events of the two files, in six chunks. Every KalSeed collection was printed per event with PrintModule at verbose 2, which includes the fit summary and every intersection:
    • With this change, all 16508 events run and none fails.
    • The nightly build, run with services.scheduler.SkipEvent : [ "StdException" ], fails only event 852.
    • For the other 16507 events, the printouts are identical between the two builds. That covers KKDe, KKUe, KKDmu and KKUmu (the trigger-level collections in the input are identical too), about 1.28 million intersections in all.

🤖 Generated with Claude Code

toCaloDisk searched for calorimeter intersections in
TimeRange(begin, tref) or TimeRange(tref, end), where tref is ftraj.t0()
taken before any extrapolation. PiecewiseTrajectory::t0() is the helix
time at z=0 and need not lie inside the trajectory. When it does not,
the range is reversed and its constructor throws "Invalid Time Range".
This stopped the nightly reco_03 job in LoopHelixFit/KKUe on run 1430,
subrun 1652, event 852 (tref 466.92 ns, trajectory 480.92-587.87 ns).

Clamp tref with forceRange, as toTrackerPerimeter already does. When tref
was inside the range nothing changes; otherwise the search range is empty
and the track, which never reaches the calorimeter, gets no calorimeter
intersections. The toCaloDisk debug printout now also shows tref and the
trajectory range.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@FNALbuild

Copy link
Copy Markdown
Collaborator

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

  • Mu2eKinKal

which require these tests: build.

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

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

About FNALbuild. Code review on Mu2e/Offline.

@RobMina RobMina 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.

I will follow up with another PR later to make the extrapolation more robust. For the time being this looks like the right fix.

@FNALbuild

Copy link
Copy Markdown
Collaborator

☀️ The build tests passed at 68b28d6.

Test Result Details
test with ✅ Command did not list any other PRs to include
merge ✅ Merged 68b28d6 at 77c4233
build (prof) ✅ Log file. Build time: 04 min 29 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 (2) FIXME (0) in 1 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 68b28d6 after being merged into the base branch at 77c4233.

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.

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