Global tags and JECs and whatnot.

[iross]

Hey guys-- So it seems like the new VBF categorization for the ZZ analysis requires a set of global tags other than what we've used in the current pattuple recipes. The only effect I've noticed so far is that the jet energy corrections are different and so there are differences in jet Pts (leading to counting/categorization differences).

Short term, does anybody know of a way to extract the jet corrections from a global tag so we can apply them offline.

And long term, is this going to be a recurring issue? I'm surprised that the global tags aren't really locked in, in the sense that apparently different analyses are using different recommendations. Is there any practical solution for the potential case where different users need pattuples with different tags for whatever reason?

[jjswan33]

Hi Ian, In principle I think since we save particle flow you should be able to rerun any jets you want with whatever JEC that you want. Josh

[mcepeda]

Hi Ian,

I guess you have already looked at this https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookJetEnergyCorrections#CorrOnTheFly ?

But yeah, I am surprised they are not locked in. How different are them? Which are the GRs? This is not listed in the JES corrections twiki, I think you can complain about this to the JetMet POG....

Maria

[ekfriis]

I guess are we sure that ZZ isn't right, and we need to update the for next round pat tuples?

In the H2Tau group we specifically decided not to update the JEC for the top-up, I am surprised that ZZ would since they are even less sensitive than us to the jets.

On Thu, Jan 24, 2013 at 12:28 AM, mcepeda notifications@github.com wrote:

Hi Ian,

I guess you have already looked at this https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookJetEnergyCorrections#CorrOnTheFly?

But yeah, I am surprised they are not locked in. How different are them? Which are the GRs? This is not listed in the JES corrections twiki, I think you can complain about this to the JetMet POG....

Maria

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/136#issuecomment-12628818.

[dabelknap]

We use the jets for VBF categorization.

[iross]

I guess I sort of misrepresented the problem here. The GTs are fine in the 'old' (HCP-era) pattuple approach, meaning ZZ isn't switching to new ones for the top-up. The issue is that the electron/muon corrections we need are only in most recent versions, which also include the latest and greatest global tags..

I'll look into the on-the-fly corrections. Thanks!

[dabelknap]

@mcepeda Maria, have you ever used the on-the-fly jet corrections? It is unclear from the TWiki exactly how it is supposed to be used. I'm not sure exactly what arguments it accepts, or how to parse them using iSetup.

[mcepeda]

Hi Austin,

No, I havent, but I remember Michalis had a setup for it in analysisTools. Back in 2011.

Maria

[ekfriis]

Hi @dabelknap,

The example on the twiki is for PFJets, so it might not work directly for you, since you have the PAT jets. Here is what I would do:

1) First, you need to un-correct the original jets, so you can apply the other corrections on top of a clean collection. I would make an EDProducer which takes the current, corrected jets, and un-corrects them. Here is an example that shows you how to make an new jet collection + access uncorrected value:

https://github.com/uwcms/FinalStateAnalysis/blob/master/PatTools/plugins/PATJetUncorrectedEmbedder.cc#L58-L63

(the highlighted lines are for using an advanced technique of embedding crap, you don't need to worry about them. Just set the p4 of the output jets to be the uncorrected value)

2) I would generate new PAT jet correction factors, which are how the PAT figures out the correction. This is just a ValueMap which maps jets -> their corrected value.

http://cmslxr.fnal.gov/lxr/source/PhysicsTools/PatAlgos/python/recoLayer0/jetCorrFactors_cfi.py#004

You'll want to change "payload" to be AK5PF instead of CaloJets, since that's what the jets where built on. You'll need to change the src to your collection of uncorrected pat jets.

3) Now make a producer which takes the uncorrected PAT jets from (1), your collection of correction factors from (2) and sticks them into a new, correctly collected set of jets.

You'll need to extract the logic from the current PAT jet producer related to applying the correction factors. The meat of it is here:

http://cmslxr.fnal.gov/lxr/source/PhysicsTools/PatAlgos/plugins/PATJetProducer.cc#277

but you'll need to grep for addJetCorrFactors_ to see what other things need to be done.

The output of (3) should be what you want.

I think you'll also need to load

/JetMETCorrections/Configuration/python/JetCorrectionServices_cff.py

into your cfg, along with the correct global tag.

Let me know if you have questions.

Evan

[dabelknap]

Hi Evan,

From what you are saying, it sounds like it would require a modification of the PAT-tuple recipe. If this is the case, then it defeats the purpose of using the on-the-fly corrections, since the idea was to avoid having to reproduce the PAT-tuples with the GlobalTags we need.

Also, I was under the impression that the PAT-tuples contained the uncorrected jet energies already. Is this not the case?

-Austin

[ekfriis]

Hi Austin,

No, you are just using the (PAT) objects in the PAT tuple, modifying them into new PAT objects on the fly, and then using those in your analysis.

They do have the uncorrected energies in the PAT tuple, but just not in the form that the jet-corrector tools in step (2) expect (they want jet->p4() to return the uncorrected energy) so you need to modify them in step (1) so they have the right format.

Evan

On Mon, Jan 28, 2013 at 2:31 PM, Austin Belknap notifications@github.comwrote:

Hi Evan,

From what you are saying, it sounds like it would require a modification of the PAT-tuple recipe. If this is the case, then it defeats the purpose of using the on-the-fly corrections, since the idea was to avoid having to reproduce the PAT-tuples with the GlobalTags we need.

Also, I was under the impression that the PAT-tuples contained the uncorrected jet energies already. Is this not the case?

-Austin

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/136#issuecomment-12781598.

[ekfriis]

OK, after talking to Sascha, I think he has a better simpler solution. Here are some tips on how to implement it:

Step a)

Run the corrections on the regular RECO ak5PFJets. See calibratedAK5PFJetsForPFMEtMVA in [1] for an example how to do this, it's easy.

Step b)

Embed these corrections into our patJets collection. You'll need to make an EDProducer which takes as input the calibratedAK5PFJetsForPFMEtMVA and selectedPatJets, matches them in eta-phi, and embeds the pt from the calibratedAK5 jets as userFloats into the selectedPatJets. See this muon-into-jet embedder by Maria for an example of how to do so [2].

[1] http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/CMSSW/JetMETCorrections/METPUSubtraction/python/mvaPFMET_Data_cff.py?revision=1.3&view=markup

[2] https://github.com/uwcms/FinalStateAnalysis/blob/master/PatTools/plugins/PATMuonInJetEmbedder.cc

[dabelknap]

I can give this a try. However, I am concerned about the extent to which this will affect the jet ID variables.

[ekfriis]

Hi Austin,

It's possible it will effect the MVA jet ID, but maybe not, I would just try it and see what happens. If it does need to be fixed, you'll just need to repeat the same excercise but also running the MVA ID on your new-corrections reco jets before you do the matching.

Evan

On Mon, Jan 28, 2013 at 4:15 PM, Austin Belknap notifications@github.comwrote:

I can give this a try. However, I am concerned about the extent to which this will affect the jet ID variables.

— Reply to this email directly or view it on GitHubhttps://github.com/uwcms/FinalStateAnalysis/issues/136#issuecomment-12786229.

[ekfriis]

@dabelknap did you figure this out?

[dabelknap]

It was decided that we would wait until the HZZ4L settled on what corrections and such to use since the PAT-Tuple had the latest tags which they would eventually be switching to anyways. For the time being at least, we decided not to mess with the on-the-fly corrections.