Update NHitCuts_byTrackAlgo for hgcalTrack

[hatakeyamak]

...to be consistent as that for GeneralTracksImporter.

PR description:

The sixth entry of
https://github.com/cms-sw/cmssw/blob/master/RecoParticleFlow/PFTracking/python/hgcalTrackCollection_cfi.py#L10
has been known as a nonsensical value. See: #16914.
I didn't really trace all the history, but I checked how the PF output changes when we set it to a "reasonable" value which is consistent as that used for GeneralTrackImporter, and I don't see anything alarming [0].

For simPFProducer outputs, after this NHitCuts_byTrackAlgo, I see slightly smaller neutral hadron entries of low pt [1] and a very minor change in PF electrons and photons [2]. I think this is because we are including more tracks (from muonSeededStepInOut/OutIn) in the hgcalTrack collection, and consequently more HGCalHE hits are associated to tracks.

Remarks: Right now, PF muons are produced from particleFlowTmpBarrel when they are RECO muons, even if the muons are in endcap [3], and simPFProducer skips [4] muons from reco muon collection. While ticl attempts to reconstruct these endcap muons, as expected. When we switch from simPFProducer to pfTICL, it's likely that we will have to do some duplicate removal between pfTICL and particleFlowTmpBarrel at least for muons. I am hoping to address this in a follow-up PR.

[1] http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/ZMM_ParticleFlow/PackedCandidates/neutralHadron/neutralHadronEta.pdf
[2] http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/ZMM_ParticleFlow/PackedCandidates/electron/electronEta.pdf
http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/ZMM_ParticleFlow/PackedCandidates/photon/photonEta.pdf

[3] because veto skips tracks with muonref: https://cmssdt.cern.ch/lxr/source/RecoParticleFlow/PFProducer/plugins/importers/GeneralTracksImporterWithVeto.cc#0133
[4] https://cmssdt.cern.ch/lxr/source/RecoParticleFlow/PFSimProducer/plugins/SimPFProducer.cc#0389

PR validation:

Ran PF validation on ZMM with and without PU:
[0] http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/
PF candidates stay almost identical, as discussed above. The "offset" plot is nearly identical:
http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/OffsetStacks/stack_ZMM_NHitCuts3_ref_vs_ZMM_ref.pdf

Since #16914 unexpectedly discussed about large reco muon changes, here we checked that slimmedMuons are not affected.
[5] http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/SlimmedMuonEta_ZMMNoPU.pdf
[6] http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/SlimmedMuonEta_ZMMPU.pdf

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

This is not a backport.

Att: @bendavid @rovere @felicepantaleo @kpedro88

[cmsbuild]

The code-checks are being triggered in jenkins.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31681/18819

• This PR adds an extra 12KB to repository

[cmsbuild]

A new Pull Request was created by @hatakeyamak (Kenichi Hatakeyama) for master.

It involves the following packages:

RecoParticleFlow/PFTracking

@perrotta, @jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@mmarionncern, @makortel, @rovere, @lgray, @lecriste, @cbernet, @seemasharmafnal 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-06-1100/slc7_amd64_gcc820: https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/9757/console Started: 2020/10/06 14:45

[kpedro88]

thanks @hatakeyamak !

[cmsbuild]

+1
Tested at: f134c7f
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-ef96cd/9757/summary.html
CMSSW: CMSSW_11_2_X_2020-10-06-1100
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 164 differences found in the comparisons
• DQMHistoTests: Total files compared: 35
• DQMHistoTests: Total histograms compared: 2542225
• DQMHistoTests: Total failures: 1023
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2541180
• 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

[perrotta]

@hatakeyamak @kpedro88

Issue #16914 (since 2016!) reported that by "using the supposedly-correct value of 3 resulted in losing most endcap muons"

From the validation plots provided in the PR description I see that in the far endcaps you probably don't loose "most" muons, but certainly a large part of them:

Is this accepted/understood? Is it something that can be fixed in the follow-up PR? (Maybe the answer to this is in the "Remark" paragraph in the PR description, but I admit I could not follow it completely)

[hatakeyamak]

Thank you @perrotta
Actually the validation plot had a mistake for NoPU ZMM, the comparison picked up the difference with and without --customise SLHCUpgradeSimulations/Configuration/aging.customise_aging_1000.
When we make comparison with the above customization consistently for both previous and new NHitCuts value, this particular plot show no difference. This mistake for validation plots was only for NoPU ZMM (and not for PU ZMM)

The plots at the link are now updated (http://hep.baylor.edu/hatake/PFval/val_11_2_pre6_NHitCuts_byTrackAlgo/plots/)

[perrotta]

+1

• Moving the sixth entry for the cuts on NHitCuts_byTrackAlgo to some "reasonable" value results in some very limited reshuffling of PF categories, as outlined in the PR description
• Jenkins tests pass and testify the same small changes reported in the description

[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)

[perrotta]

assign upgrade
(because this is for hgcal, and moreover @kpedro88 was the submitter of the github issue #16914, which can be closed when this PR will get merged)

[cmsbuild]

New categories assigned: upgrade

@kpedro88 you have been requested to review this Pull request/Issue and eventually sign? Thanks

[kpedro88]

+upgrade

[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