[PWGHF] Add centrality information to Xic0 #9128
Conversation
The FT0M, FT0A, FT0C and numContrib has been added to Xic0 event lever
Tao-Fang
requested review from
alibuild,
vkucera,
fcolamar,
fgrosa,
fcatalan92,
mfaggin,
mmazzilli,
deepathoms,
NicoleBastid,
hahassan7,
jpxrk and
apalasciano
as code owners
github-actions
bot
changed the title
Please consider the following formatting changes to AliceO2Group#9128
| } | ||
|
|
||
| template <typename T> | ||
| void fillCandidate(const T& candidate, int8_t flagMc, int8_t debugMc, int8_t originMc, bool collisionMatched) | ||
| { | ||
| rowCandidateFull( | ||
| candidate.collisionId(), |
There was a problem hiding this comment.
Why do you need to keep the collision Id? Please note that this doesn't allow you to link it to your event table, since the same collisionId can be found in different original DF, and you loose the info of the original DF in self-contained derived data due to AO2D merging. In fact, the addition of this index implies the error of unbound indices since the original collision table is not stored.
Also, even in case you want to store the collision Id (which is however not useful for the reason mentioned above), there is no need to declare the column as index column (because it doesn't point to any table that you store).
| @@ -356,6 +418,7 @@ struct HfTreeCreatorToXiPi { | |||
| if (candidate.resultSelections() && candidate.statusPidCharmBaryon() && candidate.statusInvMassLambda() && candidate.statusInvMassCascade() && candidate.statusInvMassCharmBaryon()) { | |||
|
|
|||
| rowCandidateLite( | |||
| candidate.collisionId(), | |||
There was a problem hiding this comment.
The addition of this index implies the error of unbound indices since the original collision table is not stored. We should not add it here (especially in the lite table which is typically meant for the production of samples for ML trainings and does not require the collisionId info)
| @@ -218,9 +249,11 @@ struct HfTreeCreatorToXiPi { | |||
| Produces<o2::aod::HfToXiPiEvs> rowEv; | |||
|
|
|||
| Configurable<float> zPvCut{"zPvCut", 10., "Cut on absolute value of primary vertex z coordinate"}; | |||
| Configurable<bool> useCentrality{"useCentrality", false, "Decide whether to use centrality information"}; | |||
There was a problem hiding this comment.
Instead of adding a configurable, I would templetize the process function in order to have one version that consumes the centrality tables, and another one that doesn't (otherwise regardless the value of this configurable, the user must always add the centrality task since this workflow always consumes the centrality tables)
The FT0M, FT0A, FT0C and numContrib has been added to Xic0 event lever