search

KIT-CMS / Excalibur

Analysis repository for Z+Jet studies
1 stars 4 forks source link

Adding MPF contribution splittings to the NTuple #58

Closed HerrHorizontal closed 4 years ago

HerrHorizontal commented 4 years ago

Functionality was added to compute and add MPF contribution variables (according to https://indico.cern.ch/event/896070/contributions/3778153/attachments/2000301/3338791/MPFbias_draft_20200305.pdf) for all correctionLevels to the NTuples.

HerrHorizontal commented 4 years ago

I have produced the NTuples for a few events and everything seems to behave as intended. You can see the full MPF and the MPF contribution of the leading jet in the attached plots. mpf.pdf mpflead.pdf

HerrHorizontal commented 4 years ago

I see a problem in the GetMPFjets method. Since the KLV struct doesn't support addition of KLVs (see https://github.com/KIT-CMS/Kappa/blob/c78f96aaed141a36cb423f2b6a1cfcaf75c4c0a4/DataFormats/interface/KBasic.h) the simple GetNegativeTransverseProjectionFraction method proposed would only work for GetMPF and GetMPFlead. I am not sure if this would improve readability.

dsavoiu commented 4 years ago

I see a problem in the GetMPFjets method. Since the KLV struct doesn't support addition of KLVs (see https://github.com/KIT-CMS/Kappa/blob/c78f96aaed141a36cb423f2b6a1cfcaf75c4c0a4/DataFormats/interface/KBasic.h) the simple GetNegativeTransverseProjectionFraction method proposed would only work for GetMPF and GetMPFlead. I am not sure if this would improve readability.

If I understand correctly, this would mean adding together the jet p4s in GetMPFlead and projecting them at the end, right? In that case I see your point, but I think this can be solved by redefining GetNegativeTransverseProjectionFraction to work with RMFLV*s directly and passing e.g. m_z.p4 instead of m_z. The readability of that is debatable, but IMO this still beats having the identical projection code showing up 3 times.

(For maximum readability, the GetNegativeTransverseProjectionFraction can be overloaded to take KLV*s as well so that you can pass m_z directly, but that might just be a step too far.)

dsavoiu commented 4 years ago

On an unrelated note, this PR seems to build upon the (unrelated) GENWeights branch. Is there a reason for this? If not, I would consider rebasing this directly onto master so we can merge it quickly; otherwise, we would need to merge GENWeights (and solve any open issues there) before merging this.

HerrHorizontal commented 4 years ago

Yes you are absolutely right, this branch should be based on master. My fault.

HerrHorizontal commented 4 years ago

I have implemented @dsavoiu request to use a helper method for the splitted MPF. Please have a look.

dsavoiu commented 4 years ago

Mikko answered to my questions: It seems he wants indeed the projection of the pT_jet to pT_Z. Which means, I change remove all Pz components and change MET to pT_Z.

I guess that makes sense. In that case, should we provide the cosine of <(pT1,ptZ) separately from the sum of all other angle cosines? This quantifies our main DeltaPhi and could be useful to disentangle a small bias from additional jet activity (in addition to our alpha approach).

Might I also suggest implementing GetAngleCosine in the same vein as GetTransverseProjectionFraction?

HerrHorizontal commented 4 years ago

I guess that makes sense. In that case, should we provide the cosine of <(pT1,ptZ) separately from the sum of all other angle cosines?

For the moment Mikko is happy with just the sum over all jet contributions.

HerrHorizontal commented 4 years ago

Might I also suggest implementing GetAngleCosine in the same vein as GetTransverseProjectionFraction?

Indeed, this could improve the readability. But since one of the arguments would have to be a vector of LVs this might get rather dirty and/or misleading.

dsavoiu commented 4 years ago

Might I also suggest implementing GetAngleCosine in the same vein as GetTransverseProjectionFraction?

Indeed, this could improve the readability. But since one of the arguments would have to be a vector of LVs this might get rather dirty and/or misleading.

It doesn't have to be, though. Just write GetAngleCosine for two RMFLVs and add together the results in a loop.

Edit: It should probably be called GetTransverseAngleCosine if you only include the Px() and Py().

HerrHorizontal commented 4 years ago

I have changed the behaviour of GetJNPF to calculate a single jet contribution using a helper function GetTransverseAngularCosine and looping over all jets.