73X - consumes migration XI

[vadler]

After the integration of the new reco::JetCorrector with #5141 to resolve the issue of edm::ConsumesCollectors to be passed to an ES object, this PR makes use of the new ED product and its producer in the scope of AT.
Beside some necessary code changes, it mostly consists of configuration changes/additions, since the new approach requires to add EDProducers, where the JetCorrectionService has been called before.
No regressions are expected. Some example comparisons showing identity of before/after are attached.

[cmsbuild]

A new Pull Request was created by @vadler (Volker Adler) for CMSSW_7_3_X.

73X - consumes migration XI

It involves the following packages:

CommonTools/ParticleFlow
DQMOffline/Trigger
ElectroWeakAnalysis/WENu
JetMETCorrections/Configuration
JetMETCorrections/Modules
JetMETCorrections/TauJet
JetMETCorrections/Type1MET
PhysicsTools/PatAlgos
PhysicsTools/PatUtils
Validation/RecoMET

@nclopezo, @StoyanStoynev, @danduggan, @rovere, @monttj, @cmsbuild, @deguio, @slava77, @vadler, @ojeda can you please review it and eventually sign? Thanks.
@TaiSakuma, @imarches, @pvmulder, @acaudron, @abbiendi, @mmarionncern, @nhanvtran, @schoef, @ferencek, @battibass, @mariadalfonso, @trocino, @rociovilar 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.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[vadler]

@deguio : I also migrated some small pieces of DQM code/configs, because they were very "close" to the touched JetMETCorrection configs.

[vadler]

@rappoccio : Could you also take a look, please?

[vadler]

@mmarionncern : Is this fix correct?

[rappoccio]

Overall looks good to me, but perhaps I have one question : does this maintain the "FWLite" method that takes in text files? This was a popular method of access in Run 1 (i.e. talking to the DB, pulling in the constants, writing a text file, and using the text file in FWlite).

[vadler]

@rappoccio : FWLite is not affected by the consumes-migration (but the consumes-migration is affected by FWLite). The original services and producers are still available. The "talking to DB" part" should in principle be migrated also there, but I assume this is mostly about private code, not official production WFs, right?

[rappoccio]

@vadler Correct, this should be okay then. Thanks!

[vadler]

@rappoccio : I have also one question:
JetMETCorrections/Configuration/python/CorrectedJetProducers_cff.py is essentially a derivative of JetMETCorrections/Configuration/python/JetCorrectionProducers_cff.py (and the same for JetMETCorrections/Configuration/python/JetCorrectors_cff.py and JetMETCorrections/Configuration/python/JetCorrectionServices_cff.py). I found some missing pieces, which I added to the new files in vadler@b961b4f . Were they missing intentionally, or should they also be added to the original files?

[rappoccio]

@vadler : if the services are missing, usually it means they don't exist so we take them out to avoid confusion. That way the user gets descriptive errors at compile time rather than opaque errors at run time.

[vadler]

@rappoccio : I see. Then the changes in vadler@b961b4f#diff-1 and their correspondences in vadler@b961b4f#diff-0 should be reverted, right?

[rappoccio]

@vadler : Yes, probably that is for the best.

[slava77]

+1

for #5944 878506b
no changes in reco

the issue in JetMETCorrections/Type1MET/interface/JetCorrExtractorT.h should be followed up, I guess.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes (tests are also fine). This pull request will be automatically merged.

[vadler]

@slava77 : Follow-up is in
https://hypernews.cern.ch/HyperNews/CMS/get/progQuestions/320.html

[vadler]

It looks like it was my mistake, overlooking the obvious somehow :-(
I will provide a fix right away...

[vadler]

I think, I slipped into the wrong diff (CaloJetMETcorrInputProducerT).

[slava77]

@vadler
Volker,
apparently this one broke 140.51:

----- Begin Fatal Exception 30-Oct-2014 14:01:33 CET-----------------------
An exception of category 'ProductNotFound' occurred while
   [0] Processing run: 152698 lumi: 17 event: 49592
   [1] Running path 'dqmoffline_step'
   [2] Calling event method for module L1FastjetCorrectorProducer/'ak4CaloL1FastjetCorrector'
Exception Message:
Principal::getByToken: Found zero products matching all criteria
Looking for type: double
Looking for module label: fixedGridRhoFastjetAllCalo
Looking for productInstanceName: 

[vadler]

@slava77 : Hmm, the old ESProducer requests the same data:
https://github.com/cms-sw/cmssw/blob/CMSSW_7_3_X/JetMETCorrections/Configuration/python/JetCorrectionServices_cff.py#L43
Looking into it...

[slava77]

it could as well be that the ESProducer's products were never requested, the EDProducer now runs, since this is a scheduled mode

[vadler]

@slava77 , @deguio : Looking closer to it, I rather claim an inconsistency between RECO and DQM in the failing WFs (300.0, 301.0, 302.0, 140.0, 140.51, 140.52, 140.53). The module in question is the JetMETHLTOfflineSource, which silently bails out in case of missing jet collections. So far, the jet correction services have never been called due to that in these WFs w/o standard RECO, but now we have the JetCorrector sequence, where a standard RECO element is needed before the JetMETHLTOfflineSource is run and has the chance to die silently. In fact, #5944 (comment) describes it exactly.
IMHO, the sequence jetMETHLTOfflineAnalyzer should not appear at all in these WFs; the Matrix should be fixed.
The symptoms in WFs 10025.0, 11325.0 are different. I will check them tomorrow.

[vadler]

Just for "bookkeeping": Discussion is continued in
https://hypernews.cern.ch/HyperNews/CMS/get/swReleases/4128.html ff.