Implementation of muon L1 prefiring weights

[JanFSchulte]

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:

• A weight just for muons, separate from the ECAL prefiring (as it is implemented now)?
• A combined producer that produces a global prefiring weight? This one could potentially also provide the individual weights for muons, jets, and photons.

Thanks,
Laurent & Jan

@rappoccio @mariadalfonso @gouskos @afloren @sscruz @lathomas @dpiparo

[cmsbuild]

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

[mariadalfonso]

@bendavid
as the Wmass group will be among the main users

@lathomas since he implemented the ECAL one

[bendavid]

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.)

[lathomas]

I agree with Josh that having a single weight would be easier for most analyses.
That can obviously can be achieved with separate producers or a single one. I don't have a strong opinion on what approach is the best. I guess separate producers is a bit more code to write (since one then need to combine the various products in a single one). Maybe @slava77 @jpata have a preference?

[JanFSchulte]

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.

[mariadalfonso]

@lathomas and @bendavid
please comment on #33758

[mariadalfonso]

assign xpog

[cmsbuild]

New categories assigned: xpog

@fgolf,@mariadalfonso,@gouskos you have been requested to review this Pull request/Issue and eventually sign? Thanks

[mariadalfonso]

@JanFSchulte
one general question: the Up and Down variations now include both the statistical and systematic component, right ?
if you have both sources available, would it be possible to add them separately ? it can help the Wmass like analysis

[JanFSchulte]

@mariadalfonso

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.

[mariadalfonso]

maybe worth to update the L1PreFiringWeightMuon_Up L1PreFiringWeightMuon_Down:
to something like L1PreFiringWeightMuon_StatUp L1PreFiringWeightMuon_StatDown , L1PreFiringWeightMuon_SystUp L1PreFiringWeightMuon_SystDown as only these will be used for precision measurement

@bendavid will be ok ?

[bendavid]

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.

[JanFSchulte]

Thanks for confirming. I have implemented the split.

[mariadalfonso]

+xpog

This items is being finalised in respectively PR

[cmsbuild]

This issue is fully signed and ready to be closed.