-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minor fixes to variables for lepton MVA #45860
Conversation
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-45860/41599
|
A new Pull Request was created by @namapane for master. It involves the following packages:
@cmsbuild, @ftorrresd, @hqucms, @vlimant can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
enable nano |
please test |
+1 Size: This PR adds an extra 40KB to repository Comparison SummarySummary:
NANO Comparison SummarySummary:
Nano size comparison Summary:
|
The proposed modifications to the electron collection look good to me, thank you @namapane . @cms-sw/egamma-pog-l2 |
type egamma |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @rappoccio, @mandrenguyen, @sextonkennedy, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
type muon |
+1 |
Hi @hqucms, all, |
Hi @namapane -- the next nanoAOD campaign will be based on CMSSW_15_X so there is no need to backport this. |
PR description:
This PR is a follow up of #45754, moved to 14_2_X as requested.
We recently realized that the inputs for the muonPROMPTMVA (and likewise for electronPROMPTMVA) are almost, but not fully recoverable from nanoAODs. This means that it is not possible to check data/MC agreement for input variables from central productions, nor to test new trainings.
This can be fixed easily and cheaply with two small changes (using muons for illustration, same applies to electrons):
Muon_jetDF
, corresponding to theLepGood_jetDF
MVA inputMuon_jetRelIso
with respect to the variable that is intended to correspond to,LepGood_jetPtRatio
. With the current definition,jetRelIso = (1/ptRatio-1)
if a jet is present,pfRelIso04_all
otherwise. Unfortunately the actual MVA input variable is defined in a slightly different way, with amax(ptRatio, 1.5)
applied in the case a jet is associated. Since it is not possible to figure out unambiguously if this was the case, recovering the exact definition ofLepGood_jetPtRatio
that was used for the MVA is tricky.Our proposal is to store
jetRelIso=(1/ptRatio-1)
but with a default of -1 if no jet is matched. This has some advantages:ptRatio
withpfRelIso04_all
, which is already available in its own variable. This improves clarity and also saves some disk space as -1 gets compressed betterMuon_jetRelso
as defined now, it can be computed easily as well (just need to pick isolation when no jet is presentElectron
variables. In this case,Electron_pfRelIso04_all
is also added since this variable, used inElectron_jetRelso
, was not yet present.PR validation:
Muon_jetDF
andElectron_jetDF
cost 2.2 b/item eachMuon_jetPtRatio
andElectron_jetPtRatio
space is take less space (-0.2 and -0.1 b/item respectively), because we now store -1 when no associated jet is foundElectron_pfRelIso04_all
costs 2.5 b/item