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
NanoAOD: add flag to keep all PS weights #31276
NanoAOD: add flag to keep all PS weights #31276
Conversation
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31276/17971
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31276/17973
|
A new Pull Request was created by @swertz (Sébastien Wertz) for master. It involves the following packages: PhysicsTools/NanoAOD @gouskos, @cmsbuild, @fgolf, @mariadalfonso, @santocch, @peruzzim can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Indeed, so it would be more consistent to also leave the PSWeight array empty if there are no weights. |
My concern was not so much consistency, but more being stable for users. I would prefer keeping the current implementation. |
+xpog If activated by the flag, the PS weights appear as listed here |
+generators |
+1 |
@swertz |
@mariadalfonso What about 10_2 and 9_4? Can one backport? |
@agrohsje Note: NanoGen is only available in 11_2 |
v7 is currently using 10_2: |
We will not be making anymore V7 centrally, and we didn't get requests on fixing older releases for private renano of the V7. |
Hi @mariadalfonso . The problem is that we had failing HIG requests due to the bug. So they would need to resubmit nano-aod. I assume for this it might be easiest to update v7? |
ok, we will follow up with the PC group, so that's will be clear what are the requests for the EOY and 10_2 and how to best help the private reprocessing. There are other bug-fixes besides this one among the cms-nanoAOD#533 For the time being let's complete the 10_6 |
+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 be automatically merged. |
PR description:
Add a flag (default false) to keep all the available PS weights instead of the regular 4 (ISR/FSR x up/down), as asked by JME for their custom ntuple production. If set to true, the whole PS weight array is kept, apart from the first two entries (these correspond to either
[XWGTUP * PSweight * match_eff, XWGTUP * PSweight]
or[PSweight * match_eff, PSweight]
, so they'll be equal to 1 most of the time after normalizing the weights by the second entry, see Fix PSWeight being incorrectly scaled cms-nanoAOD/cmssw#506).The flag is set to true for the nanoGEN format
Add the PS weights to nanoDQM
Fix the PS weight normalization in the case where the weights are parsed according to the lumi header (see Saving LHE weights in nanoAOD when using randomised parameter scans cms-nanoAOD/cmssw#441): the PS weights should be normalized by the
Baseline
weight (assumed to be the first PS weight seen).Add a protection for the case of empty weight arrays - fixes Bug for MC genweight vector of size 1 cms-nanoAOD/cmssw#538
Note: was originally cms-nanoAOD#542
FYI @camclean @alefisico
PR validation:
Tested in 106X: produced nanoAOD files for TTToSemiLeptonic (2016 and 2018) and for one of the parameter scan files mentioned in cms-nanoAOD#441 [1].
[1] /store/mc/RunIIAutumn18MiniAOD/SMS-TChiWZ_ZToLL_mZMin-0p1_mC1-325to1000_TuneCP2_13TeV-madgraphMLM-pythia8/MINIAODSIM/GridpackScan_102X_upgrade2018_realistic_v15-v1/70000/FFE78E85-6F7A-9441-8963-980A38403D1F.root