[PPS][NanoAOD] Generator-level proton information

[forthommel]

PR description:

This PR introduces a new flat table for the storage of GEN-level proton properties at NanoAOD level. As described in this cross-POG presentation the expected new collection size is at the order of 12-19 B/event, with a ~0.03 ms/event filling time.
The stored proton attributes are:

• its vertex longitudinal coordinate (to point at simulated vertex position)
• its transverse and longitudinal momentum (providing Mandelstam-t and the adimensional xi fractional momentum loss)
• a boolean flag stating if the proton arises from signal (e.g. central exclusive processes), or from pileup.

PR validation:

Code developed in 10_6_X, forward-ported to master branch, and tested in both environments. Compiles, produces the expected output ; matrix tests running.

if this PR is a backport please specify the original PR and why you need to backport that PR: N/A

Before submitting your pull requests, make sure you followed this checklist:

• verify that the PR is really intended for the chosen branch
• verify that changes follow CMS Naming, Coding, And Style Rules
• verify that the PR passes the basic test procedure suggested in the CMSSW PR instructions

cc: @michael-pitt, @fabferro

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36080/26553

• This PR adds an extra 28KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File PhysicsTools/NanoAOD/python/nano_cff.py modified in PR(s): Refactoring gen weight storage in EDM + Nano integration #32167, add back DeepMET in NanoAOD #35460

[cmsbuild]

A new Pull Request was created by @forthommel (Laurent Forthomme) for master.

It involves the following packages:

• PhysicsTools/NanoAOD (xpog)

@cmsbuild, @mariadalfonso, @gouskos, @fgolf can you please review it and eventually sign? Thanks.
@gpetruc, @swertz this is something you requested to watch as well.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[mariadalfonso]

please test

[cmsbuild]

-1

Failed Tests: RelVals-INPUT
Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-f31462/20441/summary.html
COMMIT: cf78c6e
CMSSW: CMSSW_12_2_X_2021-11-10-1100/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/36080/20441/install.sh to create a dev area with all the needed externals and cmssw changes.

RelVals-INPUT

• 1329.11329.1_ZEE_13_80XNanoAODINPUT+ZEE_13_80XNanoAODINPUT+NANOEDMMC2016_80X+HARVESTNANOAODMC2016_80X/step2_ZEE_13_80XNanoAODINPUT+ZEE_13_80XNanoAODINPUT+NANOEDMMC2016_80X+HARVESTNANOAODMC2016_80X.log

Comparison Summary

Summary:

• No significant changes to the logs found
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 2 differences found in the comparisons
• DQMHistoTests: Total files compared: 42
• DQMHistoTests: Total histograms compared: 2901890
• DQMHistoTests: Total failures: 5
• DQMHistoTests: Total nulls: 1
• DQMHistoTests: Total successes: 2901862
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.004 KiB( 41 files compared)
• DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
• Checked 177 log files, 37 edm output root files, 42 DQM output files
• TriggerResults: no differences found

[forthommel]

Failure in 1329.1 is a perfect example of an input file where the tag to the PU protons collection was attributed an extra genPUProtons postfix. We have a fix for these particular cases in https://github.com/cms-sw/cmssw/pull/36080/files#diff-7a4d1f8a67af14c00720d67b77419e6ae6d79974bb64881badf5ccf5da19bdfaR26, but unfortunately it seems to apply only for a certain class of samples (still did not find a common rule so far...)
Any idea on how to accommodate with this? Is there a particular (set of) era modifier(s) we can use?

[mariadalfonso]

Failure in 1329.1 is a perfect example of an input file where the tag to the PU protons collection was attributed an extra genPUProtons postfix. We have a fix for these particular cases in https://github.com/cms-sw/cmssw/pull/36080/files#diff-7a4d1f8a67af14c00720d67b77419e6ae6d79974bb64881badf5ccf5da19bdfaR26, but unfortunately it seems to apply only for a certain class of samples (still did not find a common rule so far...)
Any idea on how to accommodate with this? Is there a particular (set of) era modifier(s) we can use?

This postfix problem is isolated for the old miniAOD samples ? or can vary between samples of UL or Run3 ?

We already switched off the PPS for the old EOY nano, we can set of also these GenProtons

https://github.com/cms-sw/cmssw/pull/36080/files?authenticity_token=1VK9u43oz66LD3rvIX5ViQqnShItUvktU3i2kqwlbtWADeo7jtE4ZDoUqwgtZQ03OmFn8Lhxt%2F38RR5bbPjJMA%3D%3D&file-filters%5B%5D=.py#diff-7a4d1f8a67af14c00720d67b77419e6ae6d79974bb64881badf5ccf5da19bdfaR72-R73

[forthommel]

@mariadalfonso My bad, upon further investigation it seems that the input collection was not at all present in 8_0_X relvals. This postfix issue is therefore not involved in this failed matrix test (it seems the genPUProtons collection was only introduced in the 9_4_X cycle, see #20172).
Once I find the proper era modifier for these UL samples I will disable it in a later push.
But to follow up on this collection name issue I am still tracking down the MC production campaign(s) that introduced the extra label.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36080/26567

• This PR adds an extra 28KB to repository

• There are other open Pull requests which might conflict with changes you have proposed:

  • File PhysicsTools/NanoAOD/python/nano_cff.py modified in PR(s): add back DeepMET in NanoAOD #35460, Refactoring gen weight storage in EDM + Nano integration #32167

[cmsbuild]

Pull request #36080 was updated. @cmsbuild, @mariadalfonso, @gouskos, @fgolf can you please check and sign again.

[forthommel]

As previously discussed, a3c03d6 disables the genProtonTablesTask for 8_0_X legacy samples.

[perrotta]

Is this PR still waiting for this #36771 to be resolved ?

No, just forget about that workflow for the moment

[grzanka]

@perrotta it seems #36771 is fixed now

[perrotta]

please test
(just to refresh them)

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-f31462/22118/summary.html
COMMIT: 1f74f4b
CMSSW: CMSSW_12_3_X_2022-01-31-2300/slc7_amd64_gcc10
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/36080/22118/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• No significant changes to the logs found
• ROOTFileChecks: Some differences in event products or their sizes found
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 43
• DQMHistoTests: Total histograms compared: 3449612
• DQMHistoTests: Total failures: 0
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3449590
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 42 files compared)
• Checked 181 log files, 42 edm output root files, 43 DQM output files
• TriggerResults: no differences found

[mariadalfonso]

@forthommel
do you plan to update to further reduce the size ?

[mariadalfonso]

@forthommel ping

[forthommel]

Hello @mariadalfonso, @gouskos, and thanks for your patience!
Together with @michael-pitt we studied the possible reduction in the overall footprint of this new collection. In particular, we left the mantissa bits multiplicity as a free parameter, and observed the effect of the precision drop as translated into variables of interest for PPS/forward physics studies.
These variables are namely, the proton usual p_T, the longitudinal momentum loss ξ = Δp_z/p_z, and the longitudinal coordinate of the scattered proton vertex.
From the plot below, we observe that a 5-bit mantissa would be enough to achieve a MeV-scale precision in the proton p_T. For the most significant variable ξ we would leave it unchanged to a 8-bit mantissa to achieve a sub-percent absolute precision, and a precision-5 or 6 would work for the proton vertex longitudinal coordinate.

In addition, here is a numbered summary of the added variable size (in byte/event) as a function of this mantissa dynamics:

Variable	n=4	n=5	n=6	n=8	uncons.
GenProton_px	4.8	5.2	5.4	6.1	11.6
GenProton_py	4.8	5.2	5.5	6.0	11.6
GenProton_pz	2.5	2.9	3.3	4.0	9.9
GenProton_vz	4.6	5.0	5.2	5.8	10.7

Hence, given the figures derived above, we would go from a ~21.9 to 19.4-19.6 b/event for the floating-point variables only (in addition to the fixed 2.1 b/event for the indexing integer/GenProton_isPU boolean).
@michael-pitt can possibly comment on the effect of further constraining the proton selection cut.

[gouskos]

Hi @forthommel and @michael-pitt thank you very much for the detailed and very useful studies!
I think we can stick with the current precision [=8]
Let me rerun the NanoAOD checks ones more and then we merge

[forthommel]

It looks like the NanoAOD checks yielded a comparable O(20 b/ev) increase in 10_6_X MC workflows.

[gouskos]

+xpog

Changes in agreement with the proposed changes
https://gitlab.cern.ch/cms-nanoAOD/nanoAOD-integration/-/issues/135#note_5273080

[cmsbuild]

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. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[forthommel]

@perrotta, @dpiparo, @qliphy, is there anything we can provide to ease your review of this PR?

[perrotta]

+1

[forthommel]

Many thanks, @perrotta !