[PWGHF] Add centrality branch to Lc candidate tree

[GiuliaRusso02]

Add centrality (CentFT0C) branch to the candidate tables
(HfCandLcLites and HfCandLcFulls) in the Lc->pKpi tree creator.
Centrality is propagated from the collision to each candidate
via fillLiteTable and fillFullTable, consistent with how it is
already filled in the event table.

[github-actions]

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

[vkucera]

@GiuliaRusso02 Can you please clarify why the current code does not satisfy your needs?

[zhangbiao-phy]

@GiuliaRusso02 Can you please clarify why the current code does not satisfy your needs?

Hi @vkucera, @GiuliaRusso02 would like to save the centrality information directly in the lite tree for convenience in ML training. For the HF derived data in OO collisions, we do not apply centrality splitting at the derived-data level. Therefore, analyzers usually run the MC or Data over a larger centrality interval, for example 0–80%. However, Giulia would like to train separate models for different centrality intervals, such as 0–20%, 20–50%, and 50–80%. In this case, it would be useful to store the centrality information in the lite tree, so that one does not need to run several trains separately for different centrality intervals.

[vkucera]

@GiuliaRusso02 Can you please clarify why the current code does not satisfy your needs?

Hi @vkucera, @GiuliaRusso02 would like to save the centrality information directly in the lite tree for convenience in ML training. For the HF derived data in OO collisions, we do not apply centrality splitting at the derived-data level. Therefore, analyzers usually run the MC or Data over a larger centrality interval, for example 0–80%. However, Giulia would like to train separate models for different centrality intervals, such as 0–20%, 20–50%, and 50–80%. In this case, it would be useful to store the centrality information in the lite tree, so that one does not need to run several trains separately for different centrality intervals.

What's the problem of getting it from the event table?

[GiuliaRusso02]

@vkucera The candidate tree is used directly for ML training on Hyperloop. Having centrality already in the candidate tree avoids the need to join with the event table at training time, and allows splitting candidates by centrality interval in a single train instead of running multiple separate trains.

Moreover, I think that since the Lite candidate table does not contain a collision ID (due to unbound indices in AO2D merging, see https://aliceo2group.github.io/analysis-framework/docs/hyperloop/userdocumentation.html#8-unbound-indices-detected-in-ao2d-merging), the join with the event table at training time would actually be impossible, not just unwanted.

[vkucera]

@GiuliaRusso02 @zhangbiao-phy Thanks for the details.
Please note that, in general, if you need output tables with collision information linked to the candidates/particles, you should use the derived-data creator.
If that is too much hassle, in this case, I guess adding one column is tolerable.

[lubynets]

@vkucera @zhangbiao-phy could you allow the CI tests for this PR (since @GiuliaRusso02 has the first contribution, the tests did not start automatically and require admins' approval)?