Require highPurity for isolated tracks in heavy-ion workflows

[mandrenguyen]

PR description:

In #31647 it was pointed out that isolatedTracks has a high CPU consumption in central heavy-ion events.
This PR requires that only highPurity tracks are considered, which cuts the timing by a factor of 4 in wf 140.5611
Non-highPurity tracks have a rather large fake rate and are not used for many purposes.

PR validation:

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

Before submitting your pull requests, make sure you followed this checklist:

• verify that the PR is really intended for the chosen branch
• verify that changes follow CMS Naming, Coding, And Style Rules
• verify that the PR passes the basic test procedure suggested in the CMSSW PR instructions

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

-code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31727/18924

• This PR adds an extra 32KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File PhysicsTools/PatAlgos/plugins/PATIsolatedTrackProducer.cc modified in PR(s): Add track-based isolation, recHit energy sum to IsolatedTrack class #31399
  • File PhysicsTools/PatAlgos/python/slimming/isolatedTracks_cfi.py modified in PR(s): Add track-based isolation, recHit energy sum to IsolatedTrack class #31399

Code check has found code style and quality issues which could be resolved by applying following patch(s)

• code-format:
  https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31727/18924/code-format.patch
  e.g. curl https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31727/18924/code-format.patch | patch -p1
  You can also run scram build code-format to apply code format directly

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31727/18926

• This PR adds an extra 32KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File PhysicsTools/PatAlgos/plugins/PATIsolatedTrackProducer.cc modified in PR(s): Add track-based isolation, recHit energy sum to IsolatedTrack class #31399
  • File PhysicsTools/PatAlgos/python/slimming/isolatedTracks_cfi.py modified in PR(s): Add track-based isolation, recHit energy sum to IsolatedTrack class #31399

[cmsbuild]

A new Pull Request was created by @mandrenguyen (Matthew Nguyen) for master.

It involves the following packages:

PhysicsTools/PatAlgos

@perrotta, @jpata, @cmsbuild, @santocch, @slava77 can you please review it and eventually sign? Thanks.
@jdamgov, @rappoccio, @gouskos, @jdolen, @ahinzmann, @smoortga, @riga, @schoef, @emilbols, @mariadalfonso, @JyothsnaKomaragiri, @nhanvtran, @gkasieczka, @clelange, @hatakeyamak, @ferencek, @gpetruc, @andrzejnovak, @peruzzim, @seemasharmafnal, @mmarionncern this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

• CMSSW_11_2_X_2020-10-08-2300/slc7_amd64_gcc820: https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/9830/console Started: 2020/10/09 16:10

[cmsbuild]

+1
Tested at: e2cdd93
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b1e6ab/9830/summary.html
CMSSW: CMSSW_11_2_X_2020-10-08-2300
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-b1e6ab/9830/summary.html

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 24 differences found in the comparisons
• DQMHistoTests: Total files compared: 35
• DQMHistoTests: Total histograms compared: 2542225
• DQMHistoTests: Total failures: 13
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2542190
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 34 files compared)
• Checked 149 log files, 22 edm output root files, 35 DQM output files

[jpata]

Thanks Matt for this PR and Slava for running the tests. It looks like the only reco differences are in the HI workflow 158.01, with a reduction in tracks as expected.

https://cmssdt.cern.ch/SDT/jenkins-artifacts/baseLineComparisons/CMSSW_11_2_X_2020-10-08-2300+b1e6ab/39223/validateJR/all_OldVSNew_HydjetQB12ppRECOin2018reMINIAODwf158p01/all_OldVSNew_HydjetQB12ppRECOin2018reMINIAODwf158p01c_log10patIsolatedTracks_isolatedTracks__DQM_obj_pt.png

https://cmssdt.cern.ch/SDT/jenkins-artifacts/baseLineComparisons/CMSSW_11_2_X_2020-10-08-2300+b1e6ab/39223/validateJR/all_OldVSNew_HydjetQB12ppRECOin2018reMINIAODwf158p01/all_OldVSNew_HydjetQB12ppRECOin2018reMINIAODwf158p01c_patIsolatedTracks_isolatedTracks__DQM_obj_isHighPurityTrack.png

If these low-purity tracks are not used by HI as you say, then this change is lightweight and I think very welcome. I have no comments on the code, it looks fine as it is. I notice there are no fillDescriptions for the producer, but maybe they are hidden somewhere with inheritance.

@mandrenguyen can you comment if you expect any retuning of downstream track-dependent quantities in HI from this?

[mandrenguyen]

@jpata It doesn't appear any downstream modules in miniAOD consume isolatedTracks. I'm not really sure what this collection is used for, honestly. I do see in LXR that it's used in a muon POG skim, perhaps they are the main customer? Presumably no one has ever used this collection in PbPb events, since we haven't yet ever produced miniAOD.

[jpata]

OK, thanks for the clarifications. In this case, I only see a possible issue that it's adding extra functionality to the PATIsolatedTrackProducer which could perhaps also be achieved in the HI workflows by adding a PATObjectSelector in front of isolatedTracks. This would help to decouple functionality between various modules and perhaps be more modular.

[slava77]

OK, thanks for the clarifications. In this case, I only see a possible issue that it's adding extra functionality to the PATIsolatedTrackProducer which could perhaps also be achieved in the HI workflows by adding a PATObjectSelector in front of isolatedTracks. This would help to decouple functionality between various modules and perhaps be more modular.

IIRC, isolatedTracks from the start had somewhat elaborate selections in the producer itself.
@jpata
Is your point to move out all of the selections out of PhysicsTools/PatAlgos/plugins/PATIsolatedTrackProducer.cc or just for this HP track selection?
For the latter, it seems like too much of an overhead.
Either way, I recall that the module relies on Ref/Ptr information between multiple collections; so, having a skimmed/thinned collection as input may end up complicating the logic of the producer itself and making the combination much more complex.

[mandrenguyen]

@jpata We create a collection called highPurityGeneralTracks using TrackSelector. However, when I use it as input to isolatedTracks, I get the error
ValueMap: no associated value for given product and index

I believe that comes from the fact that particle flow uses the full generalTracks as input.

[mandrenguyen]

IIRC, isolatedTracks from the start had somewhat elaborate selections in the producer itself.

It looks like you can hand it a string as a selection, but that's only for the dE/dx part of the code.

[jpata]

OK good, thanks for the checks, then I see no reason to go forward as implemented and tested already here.

[jpata]

+reconstruction

• introduces new boolean useHighPurity for PATIsolatedTrackProducer
• the default settings do not affect any workflows
• enabled for HI workflows, in which case, only tracks passing high purity selection are used
• we see only the expected reco differences, only in HI workflows

[santocch]

+1

[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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[qliphy]

+1