Skip to content
This repository was archived by the owner on Aug 31, 2026. It is now read-only.

Split the propagation-time correction into independent hit-time and time-window flags - #17

Merged
madbaron merged 1 commit into
MuonColliderSoft:mainfrom
jburzy:jburzyns-fixTimeWindowNoCorrection
Jul 10, 2026
Merged

Split the propagation-time correction into independent hit-time and time-window flags#17
madbaron merged 1 commit into
MuonColliderSoft:mainfrom
jburzy:jburzyns-fixTimeWindowNoCorrection

Conversation

@jburzy

@jburzy jburzy commented Jul 10, 2026

Copy link
Copy Markdown

DDPlanarDigi had a single CorrectTimesForPropagation flag that subtracted the
propagation time-of-flight (radial distance/c) from the hit time before the time
window cut. This coupled two independent choices: whether the time window is defined
relative to the expected arrival time, and whether the stored hit times are
TOF-corrected. In particular, it was impossible to apply the usual TOF-corrected time
window while keeping absolute hit times in the output — which is needed when the
downstream tracking wants to use the physical hit time (e.g. time-aware seeding and
4D track finding).

This PR changes the old behavior of CorrectTimesForPropagation and adds an additional flag:

  • CorrectTimesForPropagation — subtract the propagation TOF from the
    stored (digitized) hit time
  • CorrectTimeWindowForPropagation — subtract the propagation TOF from the hit
    time only when applying the time window cut, leaving the stored time untouched

Setting both reproduces the old CorrectTimesForPropagation=True behaviour.

@madbaron

@madbaron

Copy link
Copy Markdown

Thanks @jburzy!
I'd have a slight preference for keeping CorrectHitTimesForPropagation as CorrectTimesForPropagation and set both to true by default so that we don't break anybody's workflow.

Is there any strong reason not to do this?

@jburzy

jburzy commented Jul 10, 2026

Copy link
Copy Markdown
Author

Fair point, I was thinking that it would be better to loudly break existing workflows rather than silently break them, since with CorrectTimesForPropagation=true but CorrectTimeWindowForPropagation=false (e.g what you would get if you ran existing MAIAConfig), the time window cuts won't be applied as they were before

Alternatively, if I go with your suggestion but default CorrectTimeWindowForPropagation=true, then the existing MAIAConfig should give the same behavior. I don't have a strong preference either way.

@madbaron

Copy link
Copy Markdown

Then if you don't mind I'd go for keeping the name of the existing flag and defaulting CorrectTimeWindowForPropagation to True and keep existing workflows alive and unchanged.

I see that you closed key4hep#57 in the meantime, so we don't have to worry about consistency of the PRs.

…me window cut

Split the time window cut's propagation time-of-flight correction out of
CorrectTimesForPropagation into a new independent flag:

- CorrectTimesForPropagation (default false, unchanged): subtract the
  propagation time-of-flight (radial distance/c) from the stored hit time
- CorrectTimeWindowForPropagation (new, default true): subtract the
  propagation time-of-flight from the hit time when applying the time
  window cut

This allows applying the time window cut on TOF-corrected times without
altering the stored hit times. Configurations that set
CorrectTimesForPropagation=True behave exactly as before without
changes.
@jburzy
jburzy force-pushed the jburzyns-fixTimeWindowNoCorrection branch from 00c38f1 to 58eb687 Compare July 10, 2026 12:51
@madbaron
madbaron merged commit 6282f2a into MuonColliderSoft:main Jul 10, 2026
2 of 5 checks passed
@madbaron

Copy link
Copy Markdown

Merged - the tests failures are unrelated

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants