[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-19 13:17:

## sw/BUILD/O2Physics-code-check-latest/log
--
========== List of issues found ==========
++ echo 'Found 8 errors and 0 warnings.'
Found 8 errors and 0 warnings.
++ [[ 8 -gt 0 ]]
++ cat /sw/BUILD/6b2d7e46780c34a9ee2d3e85e210267c7729413a/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/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 ]]
++ [[ 8 -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?