[PWGHF] Add KFParticle Quality Assurance

[Rrantu]

Evaluate the resolution of the particles reconstructed using the KFParticle method.

[github-actions]

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

[vkucera]

Hi @Rrantu , such a huge PR deserves some comments.

• First of all, what is your goal?
• Second, why do you need so many variables, new structs, histograms and tables?
• Why do you need to do further MC matching?
• How much more memory does the extra stuff cost?
• Last but not least, fix the issues first, only then make the PR ready.

[Rrantu]

Hi @vkucera , I'm trying to check the resolution of the particles reconstructed using the KFParticle method. For this, I need the information saved in runXic0Omegac0Creator function, Therefore, I’ve added a new tree within the runXic0Omegac0Creator function to store these variables.
Because KFParticle reconstruction starts from V0s, my MC matching also needs to begin from V0s. So, I’ve written a new process function to read the new tree and do the MC matching accordingly.
I’m not exactly sure how much memory this will consume, but it should be minimal because the new tree is relatively small.
And for the O2 linter issues, they were not introduced by my changes.

[zhangbiao-phy]

hi @Rrantu, Thanks for the implementation! I have a few comments. See the review

[zhangbiao-phy]

Hi @vkucera , I'm trying to check the resolution of the particles reconstructed using the KFParticle method. For this, I need the information saved in runXic0Omegac0Creator function, Therefore, I’ve added a new tree within the runXic0Omegac0Creator function to store these variables. Because KFParticle reconstruction starts from V0s, my MC matching also needs to begin from V0s. So, I’ve written a new process function to read the new tree and do the MC matching accordingly. I’m not exactly sure how much memory this will consume, but it should be minimal because the new tree is relatively small. And for the O2 linter issues, they were not introduced by my changes.

Hi @Rrantu, Thanks! Please fix the O2 linter issues next time!

[fgrosa]

Hi @Rrantu, thanks for the development! I have however a few comments (some of them follow the doubts raised by @vkucera). You can always retrieve the info about the matching from the "default" table and, if you want to add more flags for matching for intermediate states, you can do it in the MC process function as well without duplicating

[alibuild]

Error while checking build/O2Physics/o2 for 3268c45 at 2025-04-25 16:23:

## sw/BUILD/O2Physics-latest/log
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
Error in cling::AutoLoadingVisitor::InsertIntoAutoLoadingState:
/sw/SOURCES/O2Physics/10972-slc9_x86-64/0/PWGHF/TableProducer/candidateCreatorXic0Omegac0.cxx:2579:86: error: 'const struct o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> >::TableIteratorBase<o2::soa::DefaultIndexPolicy, o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> > >' has no member named 'invMassV0Sig'; did you mean 'invMassV0Err'?
/sw/SOURCES/O2Physics/10972-slc9_x86-64/0/PWGHF/TableProducer/candidateCreatorXic0Omegac0.cxx:2660:89: error: 'const struct o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> >::TableIteratorBase<o2::soa::DefaultIndexPolicy, o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> > >' has no member named 'invMassXiSig'; did you mean 'invMassXiErr'?
/sw/SOURCES/O2Physics/10972-slc9_x86-64/0/PWGHF/TableProducer/candidateCreatorXic0Omegac0.cxx:2727:94: error: 'const struct o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> >::TableIteratorBase<o2::soa::DefaultIndexPolicy, o2::soa::Table<o2::aod::Hash<3036674320>, o2::aod::Hash<295670893>, o2::aod::Hash<2286545062> > >' has no member named 'invMassXic0Sig'; did you mean 'invMassXic0Err'?
ninja: build stopped: subcommand failed.

Full log here.

[vkucera]

That's a lot of bins. Please evaluate the extra RAM consumption when running.

[vkucera]

Suggested change

	template <o2::hf_centrality::CentralityEstimator centEstimator, int decayChannel, typename TMyRecoCand>
	template <o2::hf_centrality::CentralityEstimator centEstimator, aod::hf_cand_xic0_omegac0::DecayType decayChannel, typename TMyRecoCand>

Please fix this elsewhere too.

[vkucera]

I guess you want to throw a LOGF(fatal, here?

[vkucera]

Use logging and severity properly. Do not write WARNING, use the correct logging level.
What do you want to do when his happens?

[vkucera]

Also what is the purpose of the debug variable? Usually, it's a flag for logging level which is not the case here.

[Rrantu]

Hi @vkucera , thanks for your feedback. I’ve updated the code accordingly, and the debug variable wasn’t needed, so I removed it.

[vkucera]

It's still there.

[vkucera]

Suggested change

	if constexpr (decayChannel != aod::hf_cand_xic0_omegac0::DecayType::XiczeroToXiPi) {
	LOGF(fatal, "ERROR: Quality validation is restricted to Xic0 → Xi Pi decay processes at this stage");
	}
	if constexpr (decayChannel != aod::hf_cand_xic0_omegac0::DecayType::XiczeroToXiPi) {
	LOGF(fatal, "Quality validation is restricted to Xic0 → Xi Pi decay processes at this stage");
	}

• The severity level is already defined with fatal. Adding a text "ERROR" is not only redundant but also misleading because error is a different severity level.
• Any sanity check should be done asap before any unrelated calculations.
• The result of this check is known at compile time. Making it fail at run time is too late.
• What is the point of making decayChannel a parameter when only one value is valid?

[Rrantu]

Thank you for the suggestion. The decayChannel selection was already applied before the match, so I have removed the check accordingly.

[fgrosa]

It is OK for me, once the comments of @vkucera are also resolved it can be merged