cms-sw
phase2 PV sorting is not using HGCAL inputs (only the barrel and HF contribute to ak4CaloJetsForTrk) will be needed for jetCore as well
this is a follow up to #31743 https://github.com/cms-sw/cmssw/issues/31743#issuecomment-711253630
CaloJets (ak4CaloJetsForTrk made out of caloTowerForTrk) are used in PV sorting and none of the HGCAL inputs are used in the phase-2 setup.
The jets are used to assign (otherwise unattached to a vertex due to displacement) tracks to a vertex if there is some alignment of the track with a calojet axis.
It's still probably making it for just a suboptimal performance rather than a bug for vertexing in phase2.
Still, some assessment and possible resolution is needed.
It could be that the calojets should not be used this way at all in phase-2 high-pileup.
@mtosi @vmariani @hatakeyamak @bendavid
[added May 15, 2024] investigations of cluster merging in jet cores have also shown that jet core splitting will be beneficial in phase-2 tracking https://indico.cern.ch/event/1396796/#30-jetcore-and-cluster-splitti some pre-tracking jet activity measure would be needed in the HGCAL direction @langufo @emiglior @VourMa @kskovpen @mmasciov
A new Issue was created by @slava77 Slava Krutelyov.
@Dr15Jones, @dpiparo, @silviodonato, @smuzaffar, @makortel, @qliphy can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
New categories assigned: upgrade,reconstruction
@slava77,@perrotta,@jpata,@kpedro88 you have been requested to review this Pull request/Issue and eventually sign? Thanks
CaloJets (
ak4CaloJetsForTrkmade out ofcaloTowerForTrk) are used in PV sorting and none of the HGCAL inputs are used in the phase-2 setup. The jets are used to assign (otherwise unattached to a vertex due to displacement) tracks to a vertex if there is some alignment of the track with a calojet axis.
Just for record: https://github.com/cms-sw/cmssw/blob/master/CommonTools/RecoAlgos/python/sortedPrimaryVertices_cfi.py#L28
@mariadalfonso @gouskos @werdmann sorry, but the PV sorting is xPOG or TRK POG ?
@mariadalfonso @gouskos @werdmann sorry, but the PV sorting is xPOG or TRK POG ?
the sorting is currently used in firstStepPrimaryVertices as well, which I'd say is a part of tracking rather than xPOG
https://github.com/cms-sw/cmssw/blob/master/CommonTools/RecoAlgos/python/sortedPrimaryVertices_cfi.py#L28 is not
I'm curious if there was any progress here.
Do we have an equivalent of ak4CaloJetsForTrk that would include all detectors in phase-2?
@lathomas @kirschen
Do we have an equivalent of
ak4CaloJetsForTrkthat would include all detectors in phase-2?
To my knowledge, we don't. Indeed, I think this suboptimal approach (i.e. CaloJets-without-HGCal-inputs used for PV sorting) was used in the HLT TDR, for lack of an alternative or a dedicated study.
The only PV-sorting studies I remember for Phase-2 were done by @AdrianoDee, so he might have some more (quantitative) insight.
FYI: @fwyzard @trtomei
Mhm, OK, I thought for the PV sorting we were using only the track information ?
This is the case, track-only sorting, for Pixel Vertices (and then for the trimming related selection). For offline-like PVs we still use ak4CaloJetsForTrk given, as @missirol highlighted, no viable and tested solution was ready to be used. This is a work in progress.
Hi @fwyzard , for sorting of PVs from 'full' tracks, I think for HLT Phase-2 we are currently doing the same as Offline, and that uses a more sophisticated method. One reference is this (but others might have better ones..): https://indico.cern.ch/event/369417/contributions/1788757/attachments/734933/1008272/pv-sorting-xpog.pdf
This is the case, track-only sorting, for Pixel Vertices (and then for the trimming related selection).
OK, this is the part I had in mind (the part that we run before the full tracking).
It could be that the calojets should not be used this way at all in phase-2 high-pileup.
Indeed... since it's not clear if there will be "calo" jets from HGCAL, what prevents using the full particle flow jets (barrel PF + TICL) instead ?
Apart form "somebody has to do it", of course.
For HLT it would mean we have to run TICL (basically) anytime we run tracking just for the PV sorting. This is the only issue (?) I see. Apart from the "somebody has to do it" one.
For HLT it would mean we have to run TICL (basically) anytime we run tracking just for the PV sorting. This is the only issue (?) I see. Apart from the "somebody has to do it" one.
Maybe, a simpler approach for TDR studies would be to try and disable the jet-dependent part of PV sorting, to understand what its quantitative impact is.
OK, then let me ask... what is the PV sorting used for ?
One thing is PU mitigation. For example, PUPPI needs to know what the "leading PV" (the first, after sorting) is.
One thing is PU mitigation. For example, PUPPI needs to know what the "leading PV" (the first, after sorting) is.
Right - and in this case, we have already run TICL and PF.
Yes; at least for jets and MET in the Phase-2 HLT config, TICL already runs on all events for which we run full tracking, so I guess one could (in principle) use PFJets instead of the CaloJets for the sorting, in this particular case. Of course, this assumes that we can run PF before PV sorting (in other words, that PF does not rely on PV sorting), which I guess it's the case, but I don't know for sure.
@fwyzard some background here: Currently "the" PV is already used in the construction of the PF candidates (mainly for assigning the direction of neutrals), so that part has to run before PF.
It's been discussed to have an "additional" pv sorting step making use of higher level information, to be used for Puppi, etc, also for Run 3, but not implemented yet.
The CaloJets are used currently to help recover displaced tracks from B decays, but performing some additional checks with respect to the jet axis.
OK, then let me ask... what is the PV sorting used for ?
in addition to what @bendavid described above in https://github.com/cms-sw/cmssw/issues/31843#issuecomment-778170808
in the earlier steps firstStepPrimaryVertices (which is also relying on ak4CaloJetsForTrk) is used to define the leading 5 vertices for the pixel pair step iteration of the iterative tracking.
One note unrelated to PV sorting: it seems that the ak4CaloJets are also used by the module muons1stStep (although I don't know if this has any actual impact on the reconstruction).
Yes, because as far as I know no PV sorter has been implemented to take into account HGCal and it is still relying on ak4CaloJetsForTrk. Maybe @cms-sw/xpog-l2 or @cms-sw/tracking-pog-l2 have a better insight.
investigations of cluster merging in jet cores have also shown that jet core splitting will be beneficial in phase-2 tracking https://indico.cern.ch/event/1396796/#30-jetcore-and-cluster-splitti some pre-tracking jet activity measure would be needed in the HGCAL direction @langufo @emiglior @VourMa @kskovpen @mmasciov
@rovere @felicepantaleo please advise if some information from HGCAL can be available to estimate the jet activity without tracking
Yes we can run AK4 directly on layer clusters and produce jets, for example. The plugin is in release. It just needs manpower to set it up.
