Fix unclustered energy variations in NanoAODv15

[BlancoFS]

This PR aims to fix a bug related to the computation of the MET unclustered energy variation during post-processing of samples. There is a bug in the computation of this uncertainty, since the CMSJMECalculator expects the $\Delta x$ and $\Delta y$, but we were passing the X and Y components of the varied MET, not the difference with respect to the nominal.

Here is the piece of code from CMSJMECalculator.

For NanoAOD versions below 15, this is not a problem since the variables are already taken from NanoAOD. Since the total X-Y components were subtracted, the variations were of the order of 100% the MET value.

Validation made with DYto2Tau-2Jets_MLL50 sample:

Before

• Nominal: [34.7, 44.8, 9.48, 33.1, ..., 55.9, 76.1, 108, 9.1]
• unclustEnup: [74.8, 94.4, 17.3, 68.7, ..., 56.6, 47.6, 9.37]
• unclustEndo: [7.25, 9.45, 7.36, 2.04, ..., 1.14, 8.72, 12.5]

After

• Nominal: [34.7, 44.8, 9.48, 33.1, ..., 55.9, 76.1, 108, 9.1]
• unclustEnup: [35.6, 46.6, 10.4, 35.6, ..., 54.6, 75.8, 107, 6.88]
• unclustEndo: [34.3, 42.6, 9.98, 31.4, ..., 57.5, 77.3, 108, 11.6]

Tagging: @NTrevisani @squinto5

[squinto5]

Hi @BlancoFS , thanks for the PR! I have a doubt on the type1met corrections that maybe you can answer. Can you point me to where the CMSJMECalculators does the step 1.5(.1) of the reccomendations? I just want to make sure that we are not "double correcting" jets when we apply the MET corrections. I hope I made myself clear. In any case, thanks for the PR and spotting this. I guess that once it is merged it should be possible to rerun the postprocessing only for the met variations part, keeping the other files unchanged. Maybe @NTrevisani know this better.

[BlancoFS]

Ciao @squinto5, I am defenitely not an expert on that code, but I believe you are refearing to this part of the code:

https://gitlab.cern.ch/cms-analysis/general/CMSJMECalculators/-/blob/main/src/Type1METVariationsCalculator.cc#L246

Here, if I understood correctly, what it does is to evaluate the difference in pT between the corrected and uncorrected and add it as a variation. Checking out the object that is returned by the method, I don't see any information about the jets, so I would naively expect them not to be corrected twice. But maybe you are asking about the possibility of being corrected jets that are already corrected to compute this difference, isn't?

[BlancoFS]

I think you might be right, and maybe we need to change a bit the code in order to take the uncorrected jet variables instead of the corrected ones, like having:
df = df.Define("newJet_pt", "Take(Jet_pt, CleanJet_jetIdx)")
Instead of:
df = df.Define("newJet_pt", "CleanJet_pt")
When we define the input variables for the MET. Let me know what do you think

[squinto5]

Exactly, what I meant is that if we are sure that we are not taking an already corrected jet, applying the full set of corrections on that and then doing something like Dpt = pt_{alreadycorrected}(+ full set of corrections) - pt_{alreadycorrected} (+ L1 corrections). I am quite busy in these days so I won't be able to check, really. But I think it is worth having a closer look, since we are into it.

[BlancoFS]

I would appreciate if anyone else can take a look as well to cross-check, but after a quick view it seems to me that it's the case. I see that exactly the same functions are applied to the jets. Here, for the JECs applyJEC:

• Type1MET (link), then the variations are computed over the jet_pt times the correction factor
• JetVariation (link)

Here, for the JER smearing applyJERSmearing:

• Type1MET (link)
• JetVariation (link)

I will update the PR to use the original jet variables as input.

[BlancoFS]

I think this might be the reason why in the past we computed the MET previously to the jets

[BlancoFS]

It's committed now (@NTrevisani @squinto5 ), I made a second test and the uncertainties look similar (maybe a bit reduced?) now:

before

• Nominal: [34.7, 47.7, 13.3, 33.1, ...]
• AbsoluteUp: [35.1, 45.1, 9.64, 33.1, ...]

after

• AbsoluteUp: [34.8, 48.3, 14.9, 33.4, ...]

[BlancoFS]

Just as a note here (@squinto5 @NTrevisani), I am not sure if here we are indeed storing the MET with the corrections applied twice for jets:
https://gitlab.cern.ch/cms-analysis/general/CMSJMECalculators/-/blob/main/src/Type1METVariationsCalculator.cc?ref_type=heads#L246

[squinto5]

Hi @BlancoFS and @NTrevisani , I see that in the latest commit you use the Jet_pt and Jet_eta directly from NanoAODs. Shouldn't it be the uncorrected CleanJet_pt? I am just asking to be sure and raise the point to look at it, probably you are right in what you are doing?

[BlancoFS]

Hi @squinto5

Yes, I believe that's the only way to access the original pT and eta of the jets, since we don't store the correction factors. The jets are not corrected before running the JMECalculator, so taking the original values in the Jet collection from NanoAOD looks correct to me. Maybe I just missed something.

[squinto5]

Hi @BlancoFS and @NTrevisani , I've made a small commit to use the whole jet collection and PuppiMET to compute the variations. I still need to run local validation. Nonetheless, I still have a doubt. Is the absolute value needed here?

[BlancoFS]

Ciao @squinto5, @NTrevisani, I don't think this is a correct approach, since if we take the whole Jet collection from NanoAOD we are taking leptons that are reconstructed as jets. I believe we must not do that. Additionally, these changes imply treating the Jet and MET correction differently, which shouldn't be the case. I would personally revert the changes from this commit.

[BlancoFS]

About your second question, no. That was the error that triggered this PR. The function needs to take the relative variation, i.e. the difference between the nominal (e.g. PuppiMET_pt * std::cos(PuppiMET_phi)) and the up variation (e.g. PFMET_ptUnclusteredUp * std::cos(PFMET_phiUnclusteredUp))

[squinto5]

About your second question, no. That was the error that triggered this PR. The function needs to take the relative variation, i.e. the difference between the nominal (e.g. PuppiMET_pt * std::cos(PuppiMET_phi)) and the up variation (e.g. PFMET_ptUnclusteredUp * std::cos(PFMET_phiUnclusteredUp))

Sorry, I was not clear on this point, what I meant is if we need to use abs(.....) or not

[BlancoFS]

Ah ok then maybe I misunderstood, sorry :). Mmm, that's a good point. After checking it, I think that in the end it does not matter at all, since it just sums in one variation and subtracts in the other. It's here:

https://gitlab.cern.ch/cms-analysis/general/CMSJMECalculators/-/blob/main/src/Type1METVariationsCalculator.cc?ref_type=heads#L163

[squinto5]

Ok, I guess the absolute value works fine. Regarding the jet collection, I was actually thinking of restructuring the framework so that the CleanJet Collection is actually defined at the end of the postprocessing. So that we are sure to correctly apply all the corrections from JME, in the correct order and then after all of this we select a subset of the Jet collection. Ideally I would like to follow this scheme.

[BlancoFS]

I am unsure about that proposal, cause that means, for example, that the MET would be varied by the JECs applied to muons reconstructed as jets. That shouldn't be the case. In fact, we vary the MET when we apply the scale and smearing corrections for that same reason. I believe the safest way to do the postprocessing is to filter the jets at first glance.

Anyway, I will let others comment on that cause I might be wrong.

[BlancoFS]

Hi @squinto5 @NTrevisani, I think we should converge on this as soon as possible. Can we go back to the approach using CleanJets with the Jet variables?

[squinto5]

Hi @BlancoFS , I am actually preparing some slides to discuss this during today's meeting

[NTrevisani]

I would close this PR, since we merged the relevant updates in PR_101

[BlancoFS]

Agree, closing it