-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Implementation of muon L1 prefiring weights #33661
Comments
A new Issue was created by @JanFSchulte Jan-Frederik Schulte. @Dr15Jones, @dpiparo, @silviodonato, @smuzaffar, @makortel, @qliphy can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
I would say it's desirable to have both the combined and individual weights (so that users can in general just use the combined one, but so that comparisons of the individual contributions are still possible at nanoaod level, and also so that a custom measurement can still be used for one of the pieces, while keeping the default for the others if needed.) |
I agree with Josh that having a single weight would be easier for most analyses. |
Ok, makes sense to me. I have added a combined weight producer that produces a combined weight as well as separate weights for jets, photons, and muons. |
assign xpog |
New categories assigned: xpog @fgolf,@mariadalfonso,@gouskos you have been requested to review this Pull request/Issue and eventually sign? Thanks |
@JanFSchulte |
Yes, right now stat. and syst. uncertainty are added in quadrature and only the total variation is provided by the weight producer (same as for ECAL). I can add the variations for stat. and syst. separately if that is desired and it is ok to add that many more entries to the nanoAOD. |
maybe worth to update the @bendavid will be ok ? |
Yes this splitting sounds reasonable (and for events with one muon it's should be enough that we can use the provided variations directly.) For events with multiple muons in order to do this strictly correctly, I think precision analyses will anyways need to recompute the variations on the fly (since e.g. if you have one muon in the central region and one in the forward region, there are two different uncorrelated systematic variations applying to the event and one needs to keep track of the eta of both muons to properly assign this to nuisance parameters.) Dealing with this properly is probably beyond the scope of the precomputed weights though, and it should be possible to deal with this at analysis level, even on top of NANOAOD, so it should be fine. |
Thanks for confirming. I have implemented the split. |
+xpog This items is being finalised in respectively PR |
This issue is fully signed and ready to be closed. |
Hi,
we have performed a measurement of the L1 prefire probability for muons during Run 2, see https://indico.cern.ch/event/1034615/contributions/4344897/attachments/2237683/3793236/20210503_L1Prefiring_JSchulte.pdf .
We are now implementing a weight producer for CMSSW to make a correction available for analysis, following the existing weight producer for ECAL prefiring: https://github.com/cms-sw/cmssw/blob/master/PhysicsTools/PatUtils/plugins/L1ECALPrefiringWeightProducer.cc
A first implementation of the muon version is available here: master...JanFSchulte:L1MuonPrefire and is being validated right now.
The question we want to to raise in the issue is how to best provide these weights for analysis. Do we prefer:
Thanks,
Laurent & Jan
@rappoccio @mariadalfonso @gouskos @afloren @sscruz @lathomas @dpiparo
The text was updated successfully, but these errors were encountered: