[PWGHF] [xic0omegac0] Updated candidate creator & candidate selector

[jinhyunni]

candidateCreatorXic0Omegac0Qa:

• Removed unused configurables massOfBach, massOfCharmBaryon
• Removed unnecessary configurables for storing pdg Id of final state hadrons in case of anti-Xic0

candidateSelectorToXiPiQa:

• Removed continue statement inside candidate loop

[github-actions]

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

[vkucera]

Always initialise in declaration.

[jinhyunni]

Hi @vkucera,
They are set to be initialized within init function.
Do they still needed to be initialized at the moment of declaration?

[vkucera]

Yes, it can be just with {}, but it should always be there.

[jinhyunni]

I wasn't aware of that issue.
Thanks for letting me know!
I've added commit to incorporate your comment.

[zhangbiao-phy]

candidateCreatorXic0Omegac0Qa:

• Removed unused configurables massOfBach, massOfCharmBaryon
• Removed unnecessary configurables for storing pdg Id of final state hadrons in case of anti-Xic0

candidateSelectorToXiPiQa:

• Removed continue statement inside candidate loop

Hi @jinhyunni, why you remove continue? then which means you can't filter the candidates based on BDT preselection, this is really you want to do?

[jinhyunni]

candidateCreatorXic0Omegac0Qa:

• Removed unused configurables massOfBach, massOfCharmBaryon
• Removed unnecessary configurables for storing pdg Id of final state hadrons in case of anti-Xic0

candidateSelectorToXiPiQa:

• Removed continue statement inside candidate loop

Hi @jinhyunni, why you remove continue? then which means you can't filter the candidates based on BDT preselection, this is really you want to do?

Hi @zhangbiao-phy.
This action was done to prevent the possible error we've dicussed in the mattermost.
I though if I leave continue statement within in the candidate loop, than the output of candidate selection table might have different rows with candidate table.
That's why I removed them.

[zhangbiao-phy]

candidateCreatorXic0Omegac0Qa:

• Removed unused configurables massOfBach, massOfCharmBaryon
• Removed unnecessary configurables for storing pdg Id of final state hadrons in case of anti-Xic0

candidateSelectorToXiPiQa:

• Removed continue statement inside candidate loop

Hi @jinhyunni, why you remove continue? then which means you can't filter the candidates based on BDT preselection, this is really you want to do?

Hi @zhangbiao-phy. This action was done to prevent the possible error we've dicussed in the mattermost. I though if I leave continue statement within in the candidate loop, than the output of candidate selection table might have different rows with candidate table. That's why I removed them.

Hi @jinhyunni, I see your point. maybe we can try to address this at a later stage, when you subscribe to the table. You can refer to the solution used for the 3-prong case here:

O2Physics/PWGHF/TableProducer/treeCreatorLcToPKPi.cxx

Lines 1165 to 1166 in 482efe6

	soa::Join<aod::HfCand3ProngWPidPiKaPr, aod::HfSelLc> const& candidates,
	aod::HfMlLcToPKPi const& candidateMlScores,

. If you remove the continue here, the final tree will become very large. This issue will be even more pronounced in Pb–Pb analyses.

[jinhyunni]

candidateCreatorXic0Omegac0Qa:

• Removed unused configurables massOfBach, massOfCharmBaryon
• Removed unnecessary configurables for storing pdg Id of final state hadrons in case of anti-Xic0

candidateSelectorToXiPiQa:

• Removed continue statement inside candidate loop

Hi @jinhyunni, why you remove continue? then which means you can't filter the candidates based on BDT preselection, this is really you want to do?

Hi @zhangbiao-phy. This action was done to prevent the possible error we've dicussed in the mattermost. I though if I leave continue statement within in the candidate loop, than the output of candidate selection table might have different rows with candidate table. That's why I removed them.

Hi @jinhyunni, I see your point. maybe we can try to address this at a later stage, when you subscribe to the table. You can refer to the solution used for the 3-prong case here:

O2Physics/PWGHF/TableProducer/treeCreatorLcToPKPi.cxx

Lines 1165 to 1166 in 482efe6

	soa::Join<aod::HfCand3ProngWPidPiKaPr, aod::HfSelLc> const& candidates,
	aod::HfMlLcToPKPi const& candidateMlScores,

. If you remove the continue here, the final tree will become very large. This issue will be even more pronounced in Pb–Pb analyses.

Thanks for your thoughtful comment on this update.
I'm not sure if it's the best way to mitigate this issue, but for now, I've swaped the order of filling candidate selection table.

[jinhyunni]

And sorry for accidentaly closing this PR without appropriate consultion.
I wanted to push the comment button, but accidently pushed close this comment button 😅