ITS: perVertex do low multiplicty vertices first

[f3sch]

• simplifies the rof/vertex loop
• in perVertex mode re-orders the processing to do low multiplicity vertices first (@mpuccio 's idea)

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[mconcas]

I did not check if this breaks the delta rof but this is anyways not enabled anywhere right

DeltaRof is currently being studied in dedicated studies on MC, please check if you suspect this might break it.

[f3sch]

Actually, looking at it again, I think what I said was completely unfounded and will have no effect on this at all.

[shahor02]

@f3sch did you check if now low-mult. vertices not stealing tracks from the high mult. ones?

[f3sch]

@shahor02 no, I did not. Max wanted to study this now.

[alibuild]

Error while checking build/O2/fullCI_slc9 for 9687dd3 at 2025-06-14 15:53:

## 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:

Full log here.

[mpuccio]

I used an implementation I have locally of the inverted ordering, and studied the perROF vs perPV vs perPV inverted order (from low mult to high mult) performance in a Pb-Pb 38kHz simulation. Here the results:

** Per ROF:
	- Total number of tracks: 153691
	- Total number of tracks not corresponding to particles: 1 (0.000650656%)
	- Total number of fakes: 17455 (11.3572%)
	- Total number of good: 136235 (88.6421%)
	- Total number of good cluster attachments: 924652 (97.2887%)
	- Average length of good tracks: 6.31326

** Per Vertex:
	- Total number of tracks: 154122
	- Total number of tracks not corresponding to particles: 1 (0.000648837%)
	- Total number of fakes: 17579 (11.4059%)
	- Total number of good: 136542 (88.5935%)
	- Total number of good cluster attachments: 925813 (97.3065%)
	- Average length of good tracks: 6.30531

** Inverted per vertex:
	- Total number of tracks: 154129
	- Total number of tracks not corresponding to particles: 2 (0.00129761%)
	- Total number of fakes: 17700 (11.4839%)
	- Total number of good: 136427 (88.5148%)
	- Total number of good cluster attachments: 925076 (97.2697%)
	- Average length of good tracks: 6.30467

The per PV with inverted order shows worse performance than the other two, so I won't discuss it further. The per PV vs per ROF comparison show very similar performance, with per ROF having slightly better average track length for good tracks and the per Vertex finding more good tracks in absolute value but slightly worse in proportion to the total number of tracks. Here also the comparison of the number of cluster populations:

to me from these numbers is very difficult to assess if the perPV will improve or worsen the global tracking performance. @shahor02 if you have any suggestions for further checks, I can try them.

[shahor02]

Thanks @mpuccio !
What is the difference between "good" and "good cluster attachment" tracks?

From your statistics I would assume you have ~150 collisions, at 38kHz you should have ~35 ROFs with >1 collisions and they will be mostly low mult., hardly one can see the effect reported by Igor:

For that one would need to process order of magnitude larger stat and check only ROFs with >1 PV of relatively high. mult. That said, I don't exclude that with the cuts we have now in the ITS tracking (on the short tracks pTs and starting layers) the effect would be reduced.

[f3sch]

For my own education how sure are we, that this stealing comes only from the perVertex and is not some convolution with deltaROF=1, which was from what I can see also enabled in this production?

[shahor02]

Well, in 16kHz data I posted above, the ROFs neighbouring with the one having collisions are empty most of the time (except the noise) so the deltaROF should not matter. Also, we had test productions
LHC24as_apass1_noDeltaRof_yesPerPV,
LHC24as_apass1_noDeltaRof_noPerPV,
LHC23zzh_apass4_NoMultiROFs
LHC23zzh_apass4_WithPerPV
LHC23zzh_apass4_NoPerPV
and I believe they were processed by Igor (will ask him comment).

[altsybee]

Hello,
yes, the correlation between two collisions in the same ROF appears when the perPV regime is On,
and the multiROF reco (almost) doesn't influence the pattern.
This check was done with 544116 (37kHz) in Nov 2024:

[mpuccio]

Hi @shahor02,
while I wait for some more central Pb-Pb statistics being produced on my machine, I tried to see what was the effect of the pt cuts to the perROF/perPV reconstruction modes:

** per PV no Pt cuts:
	- Total number of tracks: 173960
	- Total number of tracks not corresponding to particles: 52 (0.0298919%)
	- Total number of fakes: 43622 (25.0759%)
	- Total number of good: 130286 (74.8942%)
	- Total number of good cluster attachments: 964150 (92.7143%)
	- Average length of good tracks: 6.42615

** per ROF no Pt cuts:
	- Total number of tracks: 173279
	- Total number of tracks not corresponding to particles: 52 (0.0300094%)
	- Total number of fakes: 42894 (24.7543%)
	- Total number of good: 130333 (75.2157%)
	- Total number of good cluster attachments: 963853 (92.667%)
	- Average length of good tracks: 6.43795

Overall, the difference is not striking even without the pt cuts, so indeed more statistics will be required. However, with the pt cuts the perPV was finding more good tracks than the perROF in absolute terms and the difference between the number of fakes is smaller. Still, margins are thin and I will wait for the new, larger MC with only central Pb-Pb collisions.

P.S. the total number of good cluster attachments is the number of clusters for which the MC label matches the one of the track they are assigned to.

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.

[github-actions]

This PR did not have any update in the last 30 days. Is it still needed? Unless further action in will be closed in 5 days.