Fix in PF reconstruction for the spike at MET=0.0

[bachtis]

This PR contains two bug-fixes:

A) There is a post cleaning algorithm that is deactivated since 62X. This algorithm has two sub-algortihms . One to remove HF candidates from PF if noisy/spikey and one to add HF cleaned hits if they were previously cleaned by DPG but they balance better the MET.
The second one method: checkCleaning() in PFAlgo was not deactivated. In 25 ns data taking the second one can start adding to PF cleaned out of time hits picking the ones that balance the MET better biasing the MET. This bias would make the MET O(200) MeV

B)There was an additional small bug in the new clustering that adds hits below threshold to the collection of the cleaned HF hits while in this collection we need only the DPG cleaned hits. The checkCleaning() sequence runs on those very low energy hits and finds a combination that can bring the MET down from 200 MeV down to 10 MeV or less!

The fix A dominates the spike that is seen only in the data . If we apply only fix B then the met will still peak at 0.0 but at 100 MeV instead of 20 MeV

The fix B has also a small effect of the MC since low energy HF hits can be added back but the energy of those hits is so small that they can only change the Jet/MET by 100 MeV max

Tests were performed with any combination of cleaning and bug fixes. The conclusion is:
+checkCleaning needs to be deactivated since postCleaning is deactivated
+Fix needed to not add the below threshold hits to the Cleaned collection

Notes

1.The nature and understanding of the problem implies that the problem will not appear on metNoHF which is the default one for now in CMS

2.The problem is also at HLT but cannot change efficiency or rate since the change of MET is max 5-10 GeV - much lower than the HLT thresholds

[cmsbuild]

A new Pull Request was created by @bachtis (Michalis Bachtis) for CMSSW_7_4_X.

Fix in PF reconstruction for the spike at MET=0.0

It involves the following packages:

RecoParticleFlow/PFClusterProducer
RecoParticleFlow/PFProducer

@cmsbuild, @cvuosalo, @slava77 can you please review it and eventually sign? Thanks.
@mmarionncern, @lgray this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
If you are a L2 or a release manager you can ask for tests by saying 'please test' in the first line of a comment.
@Degano you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

+1
Tested at: e5edabd
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-11280/8123/summary.html

[cmsbuild]

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

[slava77]

+1

for #11280 e5edabd

• changes are the same as in 76X/75X versions
• the necessity to have this change in 74X is less significant (HF is essentially deemed unusable)
• based on preceding discussion, there should be a confirmation from PPD for this to go in this release
• jenkins tests pass and comparisons with the baseline show single event differences only in 4.53 workflow (same as in 75X/76X) with very small differences
• there are more notes in Fix in PF reconstruction for the spike at MET=0.0 - 76X version  #11284 thread

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_4_X IBs (tests are also fine) and once validation in the development release cycle CMSSW_7_6_X is complete. This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @Degano, @smuzaffar

[slava77]

@bachtis
this change is not going to the mainstream 74X until we are fully done with data processing.
Please review this PR to see if you can implement the changes configurable: changes off by default, but could be enabled with a function.

Most significant other changes in the JetMET reprocessing request can be configured on/off (I'm talking about HCAL hit cleaning and flagging).
If this one can be done the same way, a release with needed features can be more easily available.

[slava77]

@davidlange6
I think that this PR can be closed
Even if we do something with 2015, it will be 76X.