New MET correction/uncertainty tool

[mmarionncern]

This PR contains the new MET correction and uncertainty tool. It can be used for both miniAOD production and MET reprocessing on top of miniAOD.
New features :

• new pat::MET format,, takes benefit of the additional MET properties (for both corrections and uncertainties)
• 74X backward compatibility, the pat::MET format is able to read the 74X MET format and reprocess the 74X MET in 75X with e.g. new JEC. The 74X pat::MET content is empty with a 75X production.
• ME phi correction new code implemented, corrections are stored in pat::MET and can be reprocessed on top of the miniAOD
• type0 MET correction stored
• smeared MET correction stored (not up to date! still 8 TeV smearing, kept for experts)
• preparation for storage of the MET significance in miniAOD (currently not enabled per default)
• Type2 MET discarded, not supported for an analysis use
• added warning when negative JEC corrections are used in Type1MET computation

Expected changes in performances :

• size of pat::MET should be smaller than before (less uncertainty variables stored)
• no change in MET contents, physics observables are the same
• could be a bit faster than the previous tool (less modules called), but not checked

Packages changed :

• DataFormats/PatCandidates
• JetMETCorrections/Type1MET
• PhysicsTools/PatAlgos
• PhysicsTools/PatUtils

@arizzi @gpetruc, you may want to check the performances on miniAODs, let me know if you request modifications or extra checks

[cmsbuild]

A new Pull Request was created by @mmarionncern for CMSSW_7_5_X.

New MET correction/uncertainty tool

It involves the following packages:

DataFormats/PatCandidates
JetMETCorrections/Type1MET
PhysicsTools/PatAlgos
PhysicsTools/PatUtils

@cmsbuild, @vadler, @nclopezo, @monttj can you please review it and eventually sign? Thanks.
@rappoccio, @imarches, @ahinzmann, @acaudron, @TaiSakuma, @jdolen, @nhanvtran, @schoef, @ferencek, @gpetruc, @mariadalfonso, @pvmulder 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.

[cmsbuild]

-1

Tested at: c596467
I found errors in the following unit tests:

---> test testJetMETCorrectionsType1MET had ERRORS

you can see the results of the tests here:
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-9117/4754/summary.html

[cmsbuild]

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

[davidlange6]

+1

[davidlange6]

@mmarionncern - this looks to have broken workflow 11325 (unscheduled reco+pat) - likely due to all of the met validation that is on an endpath (that should not be). Could you have a look and provide a quick fix.

Thanks

[mmarionncern]

@davidlange6 I found the issue, but it confuses me a bit. The type0 correction is causing the problem, where some of the producer modules (namely the pfCandidateToVertexAssociation module) are not called properly by the unscheduled mode, while it is clearly used and seen in the log of the edmConfigDump.
As the slimmedMETs producer is not in any sequence and is used in the miniAOD validation step, I don't think the scheduled to unscheduled mode conversion is the issue.

Here is the "architecture of the error" :
patPFMetT0Corr, defined at https://github.com/cms-sw/cmssw/blob/CMSSW_7_5_X/PhysicsTools/PatUtils/python/patPFMETCorrections_cff.py#L66, is asking for the output of pfCandidateToVertexAssociation
The pfCandidateToVertexAssociation module is called from the import done at https://github.com/cms-sw/cmssw/blob/CMSSW_7_5_X/PhysicsTools/PatUtils/python/patPFMETCorrections_cff.py#L65
and thus clearly exists.

Unless i missed something fundamental in the unscheduled mode and how to define and call modules in that mode, that sequence should work. What do you think?

[davidlange6]

@mmarioncern @deguio

I dug a little - the (first) issue is

type0PFMEtCorrectionPFCandToVertexAssociation = cms.Sequence(
selectedVerticesForPFMEtCorrType0

• selectedPrimaryVertexHighestPtTrackSumForPFMEtCorrType0
• particleFlowDisplacedVertex
• pfCandidateToVertexAssociation
  )

type0PFMEtCorrectionPFCandToVertexAssociationForValidation = cms.Sequence(
cms.ignore(selectedVerticesForPFMEtCorrType0)

• cms.ignore(selectedPrimaryVertexHighestPtTrackSumForPFMEtCorrType0)
• particleFlowDisplacedVertex
• pfCandidateToVertexAssociation
  )

e.g., pfCandidateToVertexAssociation is in two places (but thats ok). Tracing up the “ForValidation” one, you find it is on the METValidation path (METRelVarForDQM_cff.py). This is the usual problem with MET changes - if something is on an end path in unscheduled mode, then it stays on the end path and no one can use it. Most of what is on the validation end path should not be there and should instead be on the revalidation path (which is normal path, not an end path meant only for HLT specific items)

So the fix is to move pfCandidateToVertexAssociation off of the end path.

On Jul 1, 2015, at 11:07 AM, mmarionncern notifications@github.com wrote:

@davidlange6 I found the issue, but it confuses me a bit. The type0 correction is causing the problem, where some of the producer modules (namely the pfCandidateToVertexAssociation module) are not called properly by the unscheduled mode, while it is clearly used and seen in the log of the edmConfigDump.
As the slimmedMETs producer is not in any sequence and is used in the miniAOD validation step, I don't think the scheduled to unscheduled mode conversion is the issue.

Here is the "architecture of the error" :
patPFMetT0Corr, defined at https://github.com/cms-sw/cmssw/blob/CMSSW_7_5_X/PhysicsTools/PatUtils/python/patPFMETCorrections_cff.py#L66, is asking for the output of pfCandidateToVertexAssociation
The pfCandidateToVertexAssociation module is called from the import done at https://github.com/cms-sw/cmssw/blob/CMSSW_7_5_X/PhysicsTools/PatUtils/python/patPFMETCorrections_cff.py#L65
and thus clearly exists.

Unless i missed something fundamental in the unscheduled mode and how to define and call modules in that mode, that sequence should work. What do you think?

—
Reply to this email directly or view it on GitHub.