PFDisplacedVertexCandidateFinder: fix deltaPhi cut, don't use std::abs

[mmusich]

resolves #38068

PR description:

Implements suggestion at #38068 (comment).

• possibly solve CPU speedup: PFDisplacedVertexProducer takes 1-2% of reco time #31158 (EDIT see: PFDisplacedVertexCandidateFinder: fix deltaPhi cut, don't use std::abs #38080 (comment))

PR validation:

cmssw compiles, waiting for a more thorough validation from PF group.

if this PR is a backport please specify the original PR and why you need to backport that PR:

N/A

[mmusich]

enable profiling

[mmusich]

type pf

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38080/30170

• This PR adds an extra 12KB to repository

[cmsbuild]

A new Pull Request was created by @mmusich (Marco Musich) for master.

It involves the following packages:

• RecoParticleFlow/PFTracking (reconstruction)

@jpata, @cmsbuild, @clacaputo, @slava77 can you please review it and eventually sign? Thanks.
@mmarionncern, @rovere, @lgray, @lecriste, @hatakeyamak, @ebrondol, @seemasharmafnal this is something you requested to watch as well.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[jpata]

@cmsbuild please test

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-38080/30178

• This PR adds an extra 12KB to repository

[cmsbuild]

Pull request #38080 was updated. @jpata, @cmsbuild, @clacaputo, @slava77 can you please check and sign again.

[mmusich]

please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7c08e5/25002/summary.html
COMMIT: 16b3837
CMSSW: CMSSW_12_5_X_2022-05-24-2300/el8_amd64_gcc10
Additional Tests: PROFILING
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/38080/25002/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• Reco comparison results: 320 differences found in the comparisons
• DQMHistoTests: Total files compared: 50
• DQMHistoTests: Total histograms compared: 3650985
• DQMHistoTests: Total failures: 21
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3650942
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 49 files compared)
• Checked 208 log files, 45 edm output root files, 50 DQM output files
• TriggerResults: no differences found

[jpata]

baseline
https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_5_X_2022-05-24-2300/el8_amd64_gcc10/profiling/11834.21/igprofCPU_step3/16

PR
https://cmssdt.cern.ch/SDT/cgi-bin/igprof-navigator/CMSSW_12_5_X_2022-05-24-2300/el8_amd64_gcc10/profiling/11834.21/PR-7c08e5/25002/igprofCPU_step3/16

Although it's a reasonable physics fix, it looks like the timing is not appreciably different. Maybe some tuning of cuts in the PFDisplacedVertexProducer is still in order?

[mmusich]

Although it's a reasonable physics fix, it looks like the timing is not appreciably different. Maybe some tuning of cuts in the PFDisplacedVertexProducer is still in order?

certainly it looks like it is, but I would let this to be handled by the PF group (@rappoccio mentioned in #38068 (comment) that a fix was available?). I was just curious to see if this relatively easy change could have mitigated the problem and it looks like it's not.
If it's preferred to have both the physics fix and the computational fix in the same PR I will gladly close this one.

[perrotta]

@mmusich @jpata I think that the fix is uncontroversial. the code currently in CMSSW being simply wrong.
I'd suggest that the computational optimization will be investigated separately

[jpata]

+reconstruction

• bugfix for Phi wraparound bug in PFDisplacedVertexCandidateFinder?  #38068 (addresses the physics bug)
• minor physics changes in PF and downstream
• I agree with Andrea above that this fix could go in as-is, and the investigations by the PF group into the computational performance of displaced vertices continue

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[perrotta]

+1

[rappoccio]

Yes, @laurenhay and I went through this for a few hours last week but still have not discovered the other bug. Stay tuned, we will work on it more this week.

[hatakeyamak]

I doubt this is a bug per se. It's just that linking criteria is currently loose, and given large number of tracks, we are connecting too many tracks into a leading block (displaced vertex candidate). So, I think the easiest route is to find the effective criteria to tighten links.

[rappoccio]

Hi, @hatakeyamak I'm not convinced that tightening track cuts will reduce the number of tracks from 1500 to 4. Considering that this is always in the first event, I think there really is a bug. We'll keep looking at it.

[hatakeyamak]

From the current way of how iteratively tracks get linked, the observed certainly-undesired feature is not too surprising to me at least, but we will see. Probably we can look at this from two different angles.

[rappoccio]

Could be. We can check.