UL: IDs

[mcremone]

Need to have a UL version of this:

https://github.com/mcremone/decaf/blob/master/analysis/utils/ids.py

thresholds need to be adjusted to satisfy the UL requirements. It requires a lot of boring searches into POG twikies. Please add the reference to the twiki as a comment.

[alejands]

Where are the minimum pt cuts coming from? For electrons, I can't seem to find a minimum pt requirement in any of the twikis from the EGamma POG.

Electrons don't have different ID thresholds for UL (see CutBasedElectronIdentificationRun2), but there's no mention of pt.

[mcremone]

whenever you don't find it on official twikies, pT cuts come from other analyses. I'd say, as a general rule, unless something different is explicitly required on official twikies for UL, we keep what we have.

[alejands]

decaf/analysis/utils/ids.py

Lines 62 to 71 in 8e989f5

	#bitmask 1 = VVLoose, 2 = VLoose, 4 = Loose, 8 = Medium, 16 = Tight, 32 = VTight, 64 = VVTight
	def isLooseTau(pt,eta,decayMode,decayModeDMs,ide,idj,idm,year):
	mask = ~(pt==np.nan)#just a complicated way to initialize a jagged array with the needed shape to True
	if year=='2016':
	mask = (pt>20)&(abs(eta)<2.3)&~(decayMode==5)&~(decayMode==6)&(decayModeDMs)&((ide&16)==16)&((idj&4)==4)&((idm&2)==2)
	elif year=='2017':
	mask = (pt>20)&(abs(eta)<2.3)&~(decayMode==5)&~(decayMode==6)&(decayModeDMs)&((ide&16)==16)&((idj&4)==4)&((idm&2)==2)
	elif year=='2018':
	mask = (pt>20)&(abs(eta)<2.3)&~(decayMode==5)&~(decayMode==6)&(decayModeDMs)&((ide&16)==16)&((idj&4)==4)&((idm&2)==2)
	return mask

The tau bitmask values documented in UL NanoAODs are different from what's in our documentation.

ide:

byDeepTau2017v2p1VSe ID working points (deepTau2017v2p1):
bitmask 1 = VVVLoose, 2 = VVLoose, 4 = VLoose, 8 = Loose, 16 = Medium, 32 = Tight, 64 = VTight, 128 = VVTight

idj:

byDeepTau2017v2p1VSjet ID working points (deepTau2017v2p1):
bitmask 1 = VVVLoose, 2 = VVLoose, 4 = VLoose, 8 = Loose, 16 = Medium, 32 = Tight, 64 = VTight, 128 = VVTight

idmu:

byDeepTau2017v2p1VSmu ID working points (deepTau2017v2p1):
bitmask 1 = VLoose, 2 = Loose, 4 = Medium, 8 = Tight

Based of this, we have ide = Medium, idj = VLoose, and idmu = Loose. Is this what we want, or should we have all 3 IDs set to Loose?

[ParticleChef]

I updated the ids.py file for UL monotop analysis. https://github.com/ParticleChef/decaf/blob/UL/analysis/utils/ids.py
I included twiki links on it. I follow the monotop analysis definitions referring to pog recommend on twiki.

[alejands]

Thanks @ParticleChef! It seems you had already taken care of this!

https://github.com/ParticleChef/decaf/blob/c542b9f0eaa9ee740aed2cc143ef71f962c83281/analysis/utils/ids.py#L71-L76

@mcremone Do we need updated Tau IDs for any of other the other analyses?

[mcremone]

@alejands the tau ID you find is targeting a 90% efficiency. Working points for different IDs that give a 90% efficiency are taken from here:

https://arxiv.org/pdf/2201.08458.pdf#page=13

based on this the following working points were selected:

((ide&16)==16)&((idj&4)==4)&((idm&2)==2)

I don't think this changed between pre-legacy and UL.

[mcremone]

@ParticleChef I have a few comments:

1. You may want to verify that this is still ok:

https://github.com/ParticleChef/decaf/blob/UL/analysis/utils/ids.py#L103-L114

More specifically, the different pT thresholds per year, especially because the comment "2017/18 pT requirement adjusted to match monojet, using dedicated ID SFs" is not relevant anymore with UL. You are now using UL corrections from the EGM POG.

2. You may want to verify that the loose ID is properly applied here:

https://github.com/ParticleChef/decaf/blob/UL/analysis/utils/ids.py#L96

the fact that the requirement is applied differently in 2016 with respect to 2017/18. You may want to check this still applies in UL.

3. Check if we still need a dedicated HEM jet definition for an HEM veto in UL. If not, remove this part:

https://github.com/ParticleChef/decaf/blob/UL/analysis/utils/ids.py#L140-L146

[alejands]

2. You may want to verify that the loose ID is properly applied here:

https://github.com/ParticleChef/decaf/blob/UL/analysis/utils/ids.py#L96

the fact that the requirement is applied differently in 2016 with respect to 2017/18. You may want to check this still applies in UL.

Photon ID now uses the Fall17V2 bitmap just like the electron ID, but the thresholds are the same. See my version of the documentation:

https://github.com/alejands/decaf/blob/f88a5a1b20b410095563a01202ed41909e582163/analysis/utils/ids.py#L106-L116

# The electron ID and photon IDs remain to be the Fall17V2 IDs for ULs
# https://twiki.cern.ch/twiki/bin/view/CMS/EgammaUL2016To2018

# 94X-V2 ID is the recommended ID for all 3 years of Run 2, ie, 2016 legacy
# rereco, 2017 rereco & UL and 2018 rereco. This ID was tuned using 2017 94X
# samples.
# https://twiki.cern.ch/twiki/bin/view/CMS/CutBasedPhotonIdentificationRun2

# Photon_cutBased
# cut-based ID bitmap, Fall17V2, (0:fail, 1:loose, 2:medium, 3:tight)
# https://twiki.cern.ch/twiki/bin/view/CMS/EgammaNanoAOD#NanoAOD_Variables

The descriptions are copied from the NanoAODv9 self documentation (which are the same for all 3 years): https://cms-nanoaod-integration.web.cern.ch/autoDoc/

I had originally changed all the photon IDs to loose_id>=1 to match the convention used for electrons, but (loose_id&1)==1 should be functionally equivalent.

[alejands]

I had originally changed all the photon IDs to loose_id>=1 to match the convention used for electrons, but (loose_id&1)==1 should be functionally equivalent.

Scratch that. They're not equivalent and medium ID would return false.

The photon ID should be set to loose_id>=1 for all years.

[mcremone]

@alejands I actually think that is equivalent. It is good that medium ID return false, because it never happens that a medium photon is exclusively medium. If it's medium, it's also loose. Therefore the ID will be constructed in a way such that, if the photon is medium, (loose_id&1)==1 will return true. I personally prefer using conditions like (loose_id&1)==1 instead of loose_id>=1

[alejands]

There are two definitions for the ID in the NanoAOD, so if we go with the bitmap we have to be careful about our choice and the bitmap definition only applies to Fall17V1, which is deprecated

Photon_cutBased.                Int_t  cut-based ID bitmap, Fall17V2, (0:fail, 1:loose, 2:medium, 3:tight)
Photon_cutBased_Fall17V1Bitmap  Int_t  cut-based ID bitmap, Fall17V1, 2^(0:loose, 1:medium, 2:tight).

Using loose_id>=1 would work for both. We can still use (loose_id&1)==1 as long as we're sure to use the bitmap variable. In this case, loose_id>=1 should be used.

Side note: There isn't a similar Electron_cutBased_Fall17V1Bitmap variable, only Electron_cutBased

Electron_cutBased	Int_t	cut-based ID Fall17 V2 (0:fail, 1:veto, 2:loose, 3:medium, 4:tight)

[alejands]

I've attached a sample from one of the DY PFNano outputs. This is Run3 data, but the NanoAOD variable description is similar, just with a different era used for calibration. (I will note that the data type in Run3 is UChar_t instead of Int_t). In here, the bin corresponding to 2 is still filled.

Photon_cutBased	UChar_t	cut-based ID bitmap, RunIIIWinter22V1, (0:fail, 1:loose, 2:medium, 3:tight)

Given all various versions of formatting this variable, I suggest we use loose_id>=1 to play it safe.

Screenshot