Skip to content

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

Open
jburzy wants to merge 2 commits into
key4hep:mainfrom
jburzy:jburzyns-DDPlanarHitTimeDigi
Open

Split the propagation-time correction into independent hit-time and time-window flags#65
jburzy wants to merge 2 commits into
key4hep:mainfrom
jburzy:jburzyns-DDPlanarHitTimeDigi

Conversation

@jburzy

@jburzy jburzy commented Sep 2, 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.

Copied from MuonColliderSoft fork: MuonColliderSoft#17

@madbaron

BEGINRELEASENOTES

  • Added a CorrectTimeWindowForPropagation property (default: true) to
    DDPlanarDigi, which applies the propagation time-of-flight correction to the
    hit time only when evaluating the time window cut. CorrectTimesForPropagation
    (default: false, unchanged) now only corrects the stored hit times. This
    allows cutting on TOF-corrected times while keeping absolute hit times in the
    output, as needed for time-aware (4D) tracking. Configurations that set
    CorrectTimesForPropagation=True behave exactly as before; configurations
    that used a time window without it now cut on TOF-corrected instead of raw
    times.

ENDRELEASENOTES

…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.

@tmadlener tmadlener left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It took me a bit to understand the logic, but I think it's sound and correctly implemented.

"Correct the stored hit time for the propagation time-of-flight: radial distance/c (default: false)"};
Gaudi::Property<bool> m_correctTimeWindowForPropagation{
this, "CorrectTimeWindowForPropagation", true,
"Correct the hit time for the propagation time-of-flight when applying the time window cut (default: true)"};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think this should also state that this does not affect the stored time.

double windowT = hitT;
if (m_correctTimeWindowForPropagation) {
windowT -= oldPos.r() / (TMath::C() / 1e6);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

A debug (or maybe better verbose) log output here could help in figuring out why hits are dropped via inspecting the logs.

@jmcarcell

Copy link
Copy Markdown
Member

Related (or previous attempt): #57

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants