sorting and trimming of pixel vertices

[missirol]

While testing a Run-3 HLT menu with the Patatrack pixel reconstruction, I think I might have stumbled upon a small difference between the sorting of the hltPixelVertices and the so-called 'trimmed' pixel vertices, i.e. hltTrimmedPixelVertices.

For what I understood so far, reading the code:

• the vertices from PixelVertexProducerCUDA are ordered using a SumPt2 criterion, implemented in gpuSortByPt2, using tracks selected in gpuVertexFinder::loadTracks;

• in the module that creates the trimmed collection at HLT, i.e. PixelVertexCollectionTrimmer, the PV sorting criterion uses again SumPt2 as figure of merit, but the track selection for the sum calculation is different, and based on a PSet named HLTPSetPvClusterComparerForIT at HLT (see for example HLT_FULL_cff); the calculation of SumPt2 is ultimately done here.

One issue is that the current implementation of PixelVertexCollectionTrimmer is rather fragile, because it implicitly assumes that the inputs are already sorted according to the same criterion used by the trimming module itself (the 1st entry of the input collection is assumed to have the highest f.o.m.). This was indeed the case in the Run-2 HLT (the same PSet and sorter were used for both hltPixelVertices and hltTrimmedPixelVertices). In the Patatrack case, this is not enforced anymore.

In general, it might be useful to make PixelVertexCollectionTrimmer a bit more robust (e.g. remove assumptions on the order of the input vertices); an attempt can be found here.

I was just wondering if all this is already known (in case it is confirmed).

---

Some relevant printouts can be found here, and were obtained as follows

cmsrel CMSSW_11_2_1_Patatrack
cd CMSSW_11_2_1_Patatrack/src
cmsenv
git cms-merge-topic missirol:devel_1121pa_pixvtx_logs
scram b -j 8
voms-proxy-init --voms cms --rfc
hltGetConfiguration /dev/CMSSW_11_2_0/GRun/V19 --no-output --no-prescale --process HLT2 --globaltag 112X_mcRun3_2021_realistic_v16 --input /store/mc/Run3Winter20DRMiniAOD/DYToLL_M-50_TuneCP5_14TeV-pythia8/GEN-SIM-RAW/DRFlatPU30to80_110X_mcRun3_2021_realistic_v6-v2/240001/7988A14E-9D3F-6A4A-B8AD-3AF6DB751185.root --max-events 10 --customise HLTrigger/Configuration/customizeHLTforPatatrack.customizeHLTforPatatrack > tmp.py
echo 'del process.FastTimerService' >> tmp.py
echo 'process.options.wantSummary = False' >> tmp.py
echo 'process.options.numberOfThreads = 1' >> tmp.py
cmsRun tmp.py

[AdrianoDee]

Hi Marino, thanks a lot! From my side it was not know. Anyway I think that your solution of "resorting" the vertices in the trimmer makes quite sense, given that, apart from Patatrack case, it may not always be the case that the sorter is the same. Do you have any feeling of if and how it affects timing?

[missirol]

Hi Adriano. No, I haven't checked this. I would assume that the impact is small, but of course it should be checked.

The second question would be whether the trimmer should use the exact same sorting as the original vertices (I'm assuming that the best sorter for the Patatrack pixel vertices is the one in the Patatrack workflow). Being able to use different sorters in PixelVertexCollectionTrimmer would require improving that module a bit further.

[missirol]

As suggested by @AdrianoDee, I opened a PR related to this in https://github.com/cms-sw/cmssw/pull/33091.

[AdrianoDee]

Thanks!

[missirol]

The technical side of this was addressed in https://github.com/cms-sw/cmssw/pull/33091, so I think the issue can be closed.

Worth noting that, as things as are now, the trimmer will continue to use its own vertex sorting (from Run-2), even when it is applied to Patatrack pixel vertices (which are sorted in a slightly different way).