[Common] Force the update of the LUT when changing runs

[romainschotter]

• Force the update of the LUT when changing runs
• Add QA histogram in TrackPropagationModule to help debugging

Thank you @fchinu for reporting the bug!

@ddobrigk @dsekihat for your information

[github-actions]

O2 linter results: ❌ 2 errors, ⚠️ 1 warnings, 🔕 0 disabled

[ddobrigk]

Hi @romainschotter, thanks a lot! However, the LUT does not change with run, and with the change you propose, you add extra unnecessary ccdb traffic. How about capturing the situation in which a LUT is already loaded and avoid replacing it with a nullptr in that case? That should be sufficient I believe...

[romainschotter]

Hi @ddobrigk ! Apologies for the delay!
In the end, I compared the LUT tables between the two runs which were used for this test and all elements were the same.
Although updating the LUT is not strictly necessary, I would still keep the changes in this PR in the rare case when LUT might be different in 2 runs from the same period.
Please let me know what you think! :-)

[alibuild]

Error while checking build/O2Physics/code-check for 454ae0c at 2026-08-19 12:49:

## sw/BUILD/O2Physics-code-check-latest/log
--
========== List of issues found ==========
++ echo 'Found 9 errors and 0 warnings.'
Found 9 errors and 0 warnings.
++ [[ 9 -gt 0 ]]
++ cat /sw/BUILD/3ce5022bf87e6eaadfd78adc13cf7137da967726/O2Physics-code-check/errors.txt
Common/Tools/StandardCCDBLoader.h:36:1: error: nested namespaces can be concatenated [modernize-concat-nested-namespaces,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:57:5: error: 'mMeanVtx' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:58:5: error: 'grpmag' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:59:5: error: 'lut' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:93:41: error: use nullptr [modernize-use-nullptr,-warnings-as-errors]
Common/Tools/TrackPropagationModule.h:58:1: error: nested namespaces can be concatenated [modernize-concat-nested-namespaces,-warnings-as-errors]
Common/Tools/TrackPropagationModule.h:88:3: error: use '= default' to define a trivial default constructor [modernize-use-equals-default,-warnings-as-errors]
Common/Tools/TrackPropagationModule.h:161:17: error: redundant string initialization [readability-redundant-string-init,-warnings-as-errors]
Common/Tools/TrackPropagationModule.h:282:7: error: use auto when initializing with a cast to avoid duplicating the type name [modernize-use-auto,-warnings-as-errors]
++ [[ 0 -gt 0 ]]
++ [[ 9 -gt 0 ]]
++ exit 1
--

Full log here.

[shahor02]

Hi,

I am also not sure why would we need to update the LUT with the run number. Even if for some reason two runs were produced with the different LUTs, which should not happen the same pass of the same year data, this would reflect the evolution of the geometry with the time rather than the run-specific differences

[alibuild]

Error while checking build/O2Physics/code-check for f650de2 at 2026-08-20 10:17:

## sw/BUILD/O2Physics-code-check-latest/log
--
========== List of issues found ==========
++ echo 'Found 3 errors and 5 warnings.'
Found 3 errors and 5 warnings.
++ [[ 3 -gt 0 ]]
++ cat /sw/BUILD/5325ce55cd8b032594541609a8ba73447bebad1c/O2Physics-code-check/errors.txt
Common/Tools/StandardCCDBLoader.h:57:5: error: 'mMeanVtx' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:58:5: error: 'grpmag' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
Common/Tools/StandardCCDBLoader.h:59:5: error: 'lut' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer,-warnings-as-errors]
++ [[ 5 -gt 0 ]]
++ cat /sw/BUILD/5325ce55cd8b032594541609a8ba73447bebad1c/O2Physics-code-check/warnings.txt
Common/Tools/StandardCCDBLoader.h:36:1: warning: nested namespaces can be concatenated [modernize-concat-nested-namespaces]
Common/Tools/TrackPropagationModule.h:58:1: warning: nested namespaces can be concatenated [modernize-concat-nested-namespaces]
Common/Tools/TrackPropagationModule.h:88:3: warning: use '= default' to define a trivial default constructor [modernize-use-equals-default]
Common/Tools/TrackPropagationModule.h:161:17: warning: redundant string initialization [readability-redundant-string-init]
Common/Tools/TrackPropagationModule.h:282:7: warning: use auto when initializing with a cast to avoid duplicating the type name [modernize-use-auto]
++ [[ 3 -gt 0 ]]
++ exit 1
--

Full log here.

[romainschotter]

Hi @shahor02 !
The changes in this PR will likely not affect anyone. When running on the grid, jobs only process files from the same run. It can only be a problem if someone is running a workflow locally on 2 files from different runs. Even so, as you said, they would need to have been produced with different LUTs. However, in the event that an analyser runs a local test over 2 files with different LUTs somehow, the appropriate LUT is picked up for each file when it is processed.
That was at least the idea behind this PR.
Maybe I misunderstood your comment. If so, please let me know

[shahor02]

Well, what meant is that there is appropriate LUT for the run. In the unlikely use case of processing together two runs from different passes or different years, in general, the latest would be more correct.

[romainschotter]

Sorry if this is a naive question: shouldn't we use the same LUT that was used when the data was processed?

Let's say, someone would run the same workflow on 2 files: one from LHC22o pass7 and one from 2026 pp thinned. If the material budget was updated between the two productions, in my understanding, we now have a new LUT. When running over LHC22opass7, shouldn't we use the LUT that were used to produce 22o pass7? And similarly, use the LUT that were used to produce 2026 pp thinned?

[shahor02]

I would say there is no well-defined answer to that: except for tiny differences due to the alignment, the difference in LUTs comes from the improvements in the geometry modelling and LUT grid granularity. So, in principle, the most recent LUT would be closer to reality and would be preferable, e.g. for propagation of IU tracks to PV.
At the same time, if the AOD track is propagated outwards, i.e. we are undoing the e-loss correction applied during reconstruction, then the "native" LUT will indeed be less biasing. So, this is a grey zone...

[romainschotter]

Hi @shahor02 !

Thanks a lot for the clarification!

Agreed that the latest LUT is the better choice for propagation to the PV. But if we take the earlier example of a workflow running over two files, one from LHC22o pass7 and one from 2026 pp thinned: depending on which file is processed first, either the latest LUT or the LHC22o pass7 one (the worst one) ends up being used for both. Which LUT is applied then depends on file ordering rather than on the data itself.

The least biasing approach would be to load the LUT corresponding to the run being processed, as this PR does. That said, this is admittedly a very rare edge case, so treating it as a non-problem and closing the PR is also reasonable. In my humble opinion, it would be preferable to merge it, but I will leave the decision to the code owners :-)

Thank you very much!

[shahor02]

Hi @romainschotter
I am not saying that updating the LUT will create extra problems: averaged over the rare scenarios you refer to, it will not have any effect. That's why I am saying it is in the grey zone. So, indeed, let the code owners decide :)