Skip to content

[PWGHF] Species-dependent minimum prong pt cut in skimming#15755

Draft
Marcellocosti wants to merge 3 commits intoAliceO2Group:masterfrom
Marcellocosti:min_pt
Draft

[PWGHF] Species-dependent minimum prong pt cut in skimming#15755
Marcellocosti wants to merge 3 commits intoAliceO2Group:masterfrom
Marcellocosti:min_pt

Conversation

@Marcellocosti
Copy link
Copy Markdown
Contributor

@Marcellocosti Marcellocosti commented Apr 14, 2026

This PR implements the possibility to have different minimum prong pt selections for the HF 3 prong candidates in the trackIndexSkimCreator workflow.

@github-actions github-actions bot added the pwghf PWG-HF label Apr 14, 2026
@github-actions
Copy link
Copy Markdown

github-actions bot commented Apr 14, 2026

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

Please consider the following formatting changes to AliceO2Group#15755
@fgrosa
Copy link
Copy Markdown
Collaborator

fgrosa commented Apr 16, 2026

Hi @Marcellocosti, thanks! Please before merging this PR, it is important to profile the CPU consumption (for Pb-Pb especially).

@Marcellocosti
Copy link
Copy Markdown
Contributor Author

Hi @fgrosa, thanks for the suggestion!

I just have a doubt: do you want me to profile the CPU consumption related to these code changes or to lower min-pt selections with respect to the ones currently used? Because with this implementation we will be anyway able to run with the min-pt selections used until now with no increase in CPU usage, given that just one check is added. And maybe hyperloop is best suited to monitor the impact of lowering the pt thresholds.

@fgrosa
Copy link
Copy Markdown
Collaborator

fgrosa commented Apr 16, 2026

Hi @fgrosa, thanks for the suggestion!

I just have a doubt: do you want me to profile the CPU consumption related to these code changes or to lower min-pt selections with respect to the ones currently used? Because with this implementation we will be anyway able to run with the min-pt selections used until now with no increase in CPU usage, given that just one check is added. And maybe hyperloop is best suited to monitor the impact of lowering the pt thresholds.

I would say that at least you should check that without changing the cut (i.e. setting them all as we have now) it does not introduce an overhead. Then, I would suggest also to check what is the impact of lowering even only one since keep in mind that this usecase will be only useful for Pb-Pb, since in pp anyway there is no point in reducing it further.
For local tests, you can then use this tool to visualise the performance metrics: https://alimonitor.cern.ch/hyperloop/performance-graphs

@Marcellocosti
Copy link
Copy Markdown
Contributor Author

Okay, I will post here the checks you suggested before marking the PR as ready for review. For the use-cases, I was thinking more of lowering it in OO collisions (from the current 0.4 GeV/c), but of course it would be nice to see if also the Pb-Pb case can be lowered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pwghf PWG-HF

Development

Successfully merging this pull request may close these issues.

3 participants