Backport of ecal pfcluster corrections to 73x

[bendavid]

May still change in case problems are seen in 74x jet met validation.

[cmsbuild]

A new Pull Request was created by @bendavid (Josh Bendavid) for CMSSW_7_3_X.

Backport of ecal pfcluster corrections to 73x

It involves the following packages:

DataFormats/CaloRecHit
RecoEcal/EgammaCoreTools
RecoHI/Configuration
RecoParticleFlow/PFClusterProducer
RecoParticleFlow/PFProducer

@cmsbuild, @cvuosalo, @nclopezo, @slava77 can you please review it and eventually sign? Thanks.
@echapon, @mmarionncern, @Sam-Harper, @MiheeJo, @jazzitup, @argiro, @appeltel, @richard-cms, @yenjie, @kurtejung, @lgray, @mandrenguyen, @dgulhan, @bachtis, @yetkinyilmaz 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.
@nclopezo you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[mandrenguyen]

@bendavid
I must have missed it in the 74X PR, but the following line looks suspicious to me:
particleFlowClusterECAL.energyCorrector.verticesLabel = cms.InputTag('hiPixelAdaptiveVertex')
hiSelectedVertex is the pixel-track vertex collection used for essentially everything in the HI reco.
hiPixelAdaptiveVertex is an intermediate step.
Please switch to hiSelectedVertex, unless there's a good justification for this.

[bendavid]

Ok, but I think we can fix it later (and first in 74x)

The vertex collection is ONLY used to count the number of vertices, and there's an inconsistency there with the pp training no matter what. So I would say the difference is not relevant.

[mandrenguyen]

Thanks for the info. I still suggest to fix this at some point to avoid confusion.
Apparently someone is going to have run the training procedure for the HI sequence, if this is essential for particle flow.

[bendavid]

The pp trained corrections may be only mildly suboptimal, but will need to be checked. (The old corrections are still available with a configuration switch at least)

[slava77]

Josh,
is the number of mostly a proxy to the OOT PU or is its main target the in-time PU?
The OOT PU virtually doesn't exist due to > 200 ns bunch spacing.
If the corrections depend strongly on ambient occupancy, then for HI it would be more appropriate to use something like track multiplicity (this can vary from a few hundred in minbias-like events to close to over a few K (3-5K) depending on the kind of collision).

Matt,
what's the expected pileup in the upcoming HI runs? What was the maximum in the Run-1 data?

[mandrenguyen]

Slava, the probability of two PbPb collisions in the same bx, was on the order of 1% in 2011. For 2015 it will be on the order of several times that. OOT will still be negligible.

[bendavid]

The number is targeting mainly the in time pileup.

Agreed that track multiplicity or rho might be a better proxy in that case.
(Matteo is also looking at related questions for the HLT)

[bendavid]

To first order the consqeuence of getting this wrong is "just" a few % scale shift.

[slava77]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.

[cmsbuild]

+1
Tested at: e0227fc
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-7690/2541/summary.html

[slava77]

Hi Josh,

was there a request to update 73X GT to include the ecal pf calibration payloads?
ESPrefer is a stopgap.

What's the purpose of this backport, BTW?
I'm guessing to finalize the run2 MC high level object calibration; is this correct?

[bendavid]

Well eventually it's needed for that, but we were at some point going to wait until the jet and met performance had been checked in 74x. (From relvals I suppose). Since if there are problems then the corrections might still need to be updated.

Since the JetMet group can't or won't do any private checks in 74x, they insisted to have the 73x branch sooner, so I made it. Then I got annoyed and just made the pull request. (As I said on the mail thread in sw-devel, I make the pull request in case it's needed.

It can also just sit here and be either merged or updated when the final ok of the corrections is ascertained in 74x. Someone should figure out what is the fastest/most convenient way to get higher stats checks on the jet/met performance. (Jet energy scale and resolution vs eta would go a LONG way)

[bendavid]

As for whether the corrections are in 73x global tags, I don't know if @dguida added them also there or not.

[slava77]

@diguida
Salvatore, can you pick these up in 73X as well?

[diguida]

@slava77 @bendavid queueing them...

[diguida]

@slava77 @bendavid
I was finally able to have the tests running fine also in 73X.
See #7941 with the changes in the labels within the consumer code and the new GTs.

[slava77]

-1

superseded by #7941