[ALICE3] Implement task and tree creator for 3-prong candidates

[Marcellocosti]

In this PR, the selector, task, and tree creator for simulation performance of HF 3-prong candidates is implemented. Moreover, an header to apply bdt selection is also added. The current code covers only the Lc baryon, but the aim is to cover all 3-prong species with proper templetization.

[github-actions]

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

[Marcellocosti]

Hi all, I moved the implementation under the ALICE3 folder, please let me know if I overlooked anything!

[vkucera]

Hi all, I moved the implementation under the ALICE3 folder, please let me know if I overlooked anything!

Hi @Marcellocosti , thanks for the update, but now it seems that you are duplicating a lot of Run3 HF stuff. I thought you would just put in ALICE3 the stuff that is different from the Run3 stuff. Why do you need a new full candidate table a new selector array and a new ML response?

[Marcellocosti]

Hi Vit, thanks for the comment, here my ideas

• The new ML response is needed as Run 5 BDT models will have different PID variables from Run3, and these represent the majority of the features I implemented
• For the new selector array, the existing ones for Run 3 are specific to each particle specie in their name. Given that for simulation we have a simplified workflow compared to Run 3 analyses, I thought of implementing Alice3HfSelector3Prong, Alice3HfTask3Prong and Alice3HfTreeCreator3Prong which can cover D+, Ds, Lc, Xic with templetization of process functions. Therefore, I thought that defining a new selector array would be better
• I introduced a new candidate table with the aim to decouple ALICE3 code from Run 3 code

Please let me know if you have any suggestion on these points

[vkucera]

Hi Vit, thanks for the comment, here my ideas

* The new ML response is needed as Run 5 BDT models will have different PID variables from Run3, and these represent the majority of the features I implemented
* For the new selector array, the existing ones for Run 3 are specific to each particle specie in their name. Given that for simulation we have a simplified workflow compared to Run 3 analyses, I thought of implementing `Alice3HfSelector3Prong`, `Alice3HfTask3Prong` and `Alice3HfTreeCreator3Prong` which can cover D+, Ds, Lc, Xic with templetization of process functions. Therefore, I thought that defining a new selector array would be better
* I introduced a new candidate table with the aim to decouple ALICE3 code from Run 3 code

Please let me know if you have any suggestion on these points

Thanks for the clarification. Indeed, after a closer look I can see that it is not a copy-paste and it has ALICE3-specific features. That makes sense to me.

[Marcellocosti]

Hi @vkucera, I have implemented your comments!

[vkucera]

Hi @vkucera, I have implemented your comments!

Thanks a lot, @Marcellocosti . Sorry, the comment about the prong index columns was a mistake.

[alibuild]

Error while checking build/O2Physics/o2 for d574c2f at 2025-11-21 11:20:

## sw/BUILD/O2Physics-latest/log
CMake Error at ALICE3/TableProducer/CMakeLists.txt:54:

Full log here.

[ktf]

Are you sure you do not want an array, for nSigTrkPi0 / nSigTrkPi1 /nSigTrkPi2 ?