[Common] Fix TPC side determination in VDrift correction - #17846
Conversation
|
O2 linter results: ❌ 0 errors, |
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Hi @matthias-kleiner, thanks a lot for this fix! However, I was wondering what will happen with data for which the TPC side flags are not stored: this is relevant, since those were added only in February this year. Further, since they were added "adiabatically" by taking unused bits in the flags integer, older datasets will appear to have all tracks only in one side, and thus the fix will break in that situation. Is there perhaps some way in which the TPC side information could be inferred from other parameters that existed already before? For instance, a combination of tgl and the sign of Z (given we store tracks at the position of their innermost update?)... Sorry if I am overlooking something. Thanks again! |
The TPCSideA/TPCSideC flags were only added to the AOD format in February 2026, so datasets produced before that always have neither bit set. Detect CE-crossing tracks from the track's asymmetric time margins and otherwise infer the side from a cross-check of Z and tgl sign, per TPC domain expert guidance, instead of silently skipping the correction for all tracks in older datasets. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hi @ddobrigk , |
|
Hi @matthias-kleiner, thanks a lot! I have one question and a request, if I may:
Thanks again - and please only worry about this whenever convenient and don't let me disturb your weekend! |
This comment was marked as outdated.
This comment was marked as outdated.
Introduce TPCVDriftManagerParam::useSideBasedCorrection (default off) to gate the new TPC-side-flag-based correction behind a ConfigurableParam, settable from any workflow via --configKeyValues without touching each task that owns a TPCVDriftManager instance. Keeps existing analyses on the legacy tgl-sign behaviour until explicitly opted in for testing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hi @ddobrigk , I think it could in principle recover some efficiency loss: when the sign of the tgl disagrees with the actual TPC side, the old code shifts the tracks Z the wrong way instead of correcting it, which would hurt topological cuts. How much depends on how large the vDrift correction is and how often the vertex position/track topology puts tgl and Z sign at different sign. The best would be to make a direct A/B comparison with the switch. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Error while checking build/O2Physics/staging for ec64032 at 2026-09-14 21:21: Full log here. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Hi @matthias-kleiner ! Thank you very much for the PR! I have taken the liberty to try out your changes in order to test whether the configurable is available in the The simplest alternative is maybe to add the variable My 2 cents. |
…e-based correction switch O2ParamDef only declares the static sInstance member; defining it requires O2ParamImpl in a compiled .cxx, but TPCVDriftManager is a header-only library with none, so Instance() left an unresolved symbol for every consumer. Switch to a plain member + setter, as suggested in review; tasks using TPCVDriftManager can later expose this via their own Configurable. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hi @romainschotter , |
|
Many, many thanks @matthias-kleiner ! (and @romainschotter for taking a look too). Will approve |
5 participants
No description provided.