[PWGHF] First draft of Xic0Omegac0 workflow update

[jinhyunni]

First draft of workflow to analyze Xic0 and Xicp at pp 5.36 TeV reference data with DCAFitter and KFParticle method.

Xic0 workflow implemented first, and pull requested to run this workflow on hyperloop to make data set needed for BDT training.

Xicp workflow will be added later, with similar reconstruction algorithm with Xic0

---

The purpose of this pull request has been revised.

This PR aims to update exisiting Xic0Omegac0 workflow to make it more maintainable and easier to use.
I've added "Qa" suffix to each codes, so that each codes to represents what they are aiming to replace in the future.

Details of each updated codes is as follows :

candidateCreatorXic0Omegac0Qa

• Removed unnecessary duplications in the code
• Udpated candidate reconstruction with KFParticle package in more compact way(creating candidate directly from Xic0 daughters, not starting from V0 daughters). This candidate reconstruction scheme is also being used in Xic+ to Xi Pi Pi reconstruction.

candidateSelectorToXiPiQa

• Merged two candidate selection codes for Xic0(candidateSelectorToXiPi, candidateSelectorToXiPiKF).

treeCreatorToXiPiQa

• Merged two tree creator codes for Xic0(treeCreatorToXiPi, treeCreatorToXiPiKf)

[github-actions]

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

[zhangbiao-phy]

First draft of workflow to analyze Xic0 and Xicp at pp 5.36 TeV reference data with DCAFitter and KFParticle method.

Xic0 workflow implemented first, and pull requested to run this workflow on hyperloop to make data set needed for BDT training.

Xicp workflow will be added later, with similar reconstruction algorithm with Xic0

Hi @jinhyunni, Thanks for the development! However, as you’ve seen, the workflows of commonly used channels for Xic0 and Xic+ already exist in the framework. So in principle, to avoid code duplication, we recommend building on top of the existing code rather than creating new separate workflows for different energies. BTW is there a specific reason you’re not using the existing ones? Please feel free let me know if I missed something.

[jinhyunni]

First draft of workflow to analyze Xic0 and Xicp at pp 5.36 TeV reference data with DCAFitter and KFParticle method.
Xic0 workflow implemented first, and pull requested to run this workflow on hyperloop to make data set needed for BDT training.
Xicp workflow will be added later, with similar reconstruction algorithm with Xic0

Hi @jinhyunni, Thanks for the development! However, as you’ve seen, the workflows of commonly used channels for Xic0 and Xic+ already exist in the framework. So in principle, to avoid code duplication, we recommend building on top of the existing code rather than creating new separate workflows for different energies. BTW is there a specific reason you’re not using the existing ones? Please feel free let me know if I missed something.

First draft of workflow to analyze Xic0 and Xicp at pp 5.36 TeV reference data with DCAFitter and KFParticle method.
Xic0 workflow implemented first, and pull requested to run this workflow on hyperloop to make data set needed for BDT training.
Xicp workflow will be added later, with similar reconstruction algorithm with Xic0

Hi @jinhyunni, Thanks for the development! However, as you’ve seen, the workflows of commonly used channels for Xic0 and Xic+ already exist in the framework. So in principle, to avoid code duplication, we recommend building on top of the existing code rather than creating new separate workflows for different energies. BTW is there a specific reason you’re not using the existing ones? Please feel free let me know if I missed something.

Hi @zhangbiao-phy! Thanks for the quick reply.

We are currently analyzing the hadronic decay channels of Xic0 and Xicp using the pp reference run data. While existing workflows for these channels are available within the framework, they were primarily developed for the 13.6 TeV dataset and are highly customized for that specific energy and corresponding conditions.

Given the level of customization, we found that reusing the existing workflows as-is for the reference run analysis would introduce significant overhead in adapting and restructuring the code. Therefore, we decided to develop a new workflow tailored to our analysis needs.

The new workflow is designed to integrate both Xic0->Xi pi and Xicp -> Xi pi pi decay channels in a unified framework. It also supports both the DCA-based vertexing and the KFParticle approach, allowing us to cross-check and compare both reconstruction strategies within the same codebase. Our goal is to provide a flexible and modular structure that can handle both Xic0 and Xicp analyses efficiently for different energies and reconstruction methods.

Of course, we are happy to explore how to align or refactor the new implementation with the existing workflows in the future to ensure better integration and avoid duplication, if that becomes feasible.
Please let us know if you have any further suggestions or insights!

[vkucera]

Hi @jinhyunni , please give an explicit list of the customisations that prevent you from using the existing framework.

[jinhyunni]

Hi @jinhyunni , please give an explicit list of the customisations that prevent you from using the existing framework.

Hi Vit! Thanks for having a look.

The current workflows for Ξc⁰ and Ξc⁺ reconstruction are the Xic0OmegaC0 and XicToXiPiPi workflows, respectively. In principle, the reconstruction algorithms for Ξc⁰ and Ξc⁺ should be nearly identical, as the only difference between their hadronic decay channels is the presence of an additional charged pion.

However, in the current implementations using the KFParticle, the Xic0OmegaC0 and XicToXiPiPi workflows differ in ways beyond just the number of pions involved. For example, XicToXiPiPi workflow directly uses cascades information provided from LF strangenessBuilder workflow, while Xic0Omegac0 workflow uses cascades information to re-build KFParticle objects.

This is one of the main reasons we aim to develop a new, unified workflow for reconstructing both Ξc⁰ and Ξc⁺ in a consistent and compact manner—by simply adding one more charged pion for Ξc⁺—using both the DCAFitter and KFParticle methods.

[fgrosa]

Hi @jinhyunni , please give an explicit list of the customisations that prevent you from using the existing framework.

Hi Vit! Thanks for having a look.

The current workflows for Ξc⁰ and Ξc⁺ reconstruction are the Xic0OmegaC0 and XicToXiPiPi workflows, respectively. In principle, the reconstruction algorithms for Ξc⁰ and Ξc⁺ should be nearly identical, as the only difference between their hadronic decay channels is the presence of an additional charged pion.

However, in the current implementations using the KFParticle, the Xic0OmegaC0 and XicToXiPiPi workflows differ in ways beyond just the number of pions involved. For example, XicToXiPiPi workflow directly uses cascades information provided from LF strangenessBuilder workflow, while Xic0Omegac0 workflow uses cascades information to re-build KFParticle objects.

This is one of the main reasons we aim to develop a new, unified workflow for reconstructing both Ξc⁰ and Ξc⁺ in a consistent and compact manner—by simply adding one more charged pion for Ξc⁺—using both the DCAFitter and KFParticle methods.

Hi @jinhyunni I would agree with @zhangbiao-phy and @vkucera and avoid having copies of tasks that are supposed to do the same. In particular:

• the differences that you mention are not because of specific-energy customisations, but only analysis choices. For instances, in the case you mentioned about the cascade reconstruction, it would be sufficient to add a configurable to optionally choose the cascade reconstruction with the DCAFitter, or instead to redo it with the KFParticle
• In general duplicating the code is not ideal because the developments tend to diverge and it's then more difficult to maintain and understand possible differences. In addition, it is beneficial to share the same "core" code among different analysers, because this allows for mutual cross-checks and validation. Finally, it also slows down the O2Physics compilation unnecessarily (because we just duplicate tasks that in principle could be only one)

I am very sorry that you did a lot of work in this direction already, but in case of "core" developments (i.e. not a specific task for a specific analysis that is not yet present) I would always advice of contacting beforehand the PWG and PAG coordinators, to get their feedback.
Thanks a lot! Cheers, Fabrizio