Fix EmissionVetoHook for BB4L

[lauridsj]

PR description:

This PR fixes a bug in the Pythia showering hook specific to the bb4l generator, described in #40459.
bb4l generates up to three real emissions at the LHE level - one from the initial state, and one each from two possible top quarks. This requires a special shower hook to handle, implemented in CMSSW in PowhegHooksBB4L.h. The showering is set up in such a way that emissions that are outside a resonance, i.e. do not come from top quarks, are handled by the normal EmissionVetoHook1.cc hook, while PowhegHooksBB4L.h handles emissions that are inside a resonance.

Looking at the single changed line, it can be clearly seen that the condition in the code needs to be changed for this to happen correctly - if the emission is in resonance, the EmissionVetoHook should not consider it (i.e. return false to not proceed to the actual vetoing), and leave it up to PowhegHooksBB4L.

Due to the second part of the if condition, it is clear that only bb4l is affected.

PR validation:

I tested this change against a standalone pythia setup that uses a hook provided by the bb4l authors. Changes are only minimal, and only in variables that are very sensitive to FSR. There is a small change due to the fix in the number of jets, seen here as well as angular variables between jets, e.g. dR of the first two light jets here. In both cases the fixed version agrees with the standalone setup. Lepton observables seem unaffected.

If this PR is a backport please specify the original PR and why you need to backport that PR. If this PR will be backported please specify to which release cycle the backport is meant for:

This PR will need to be backported to CMSSW 10 for UL event generation and, eventually, to CMSSW 12 for Run 3 event generation.

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-42264/36288

• This PR adds an extra 16KB to repository

[cmsbuild]

A new Pull Request was created by @lauridsj (Laurids Jeppe) for master.

It involves the following packages:

• GeneratorInterface/Pythia8Interface (generators)

@SiewYan, @mkirsano, @Saptaparna, @cmsbuild, @alberto-sanchez, @menglu21, @GurpreetSinghChahal can you please review it and eventually sign? Thanks.
@alberto-sanchez, @mkirsano this is something you requested to watch as well.
@perrotta, @dpiparo, @rappoccio you are the release manager for this.

cms-bot commands are listed here

[menglu21]

@cmsbuild please test

[cmsbuild]

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-f3bd26/33746/summary.html
COMMIT: 05ab984
CMSSW: CMSSW_13_2_X_2023-07-18-1100/el8_amd64_gcc11
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/42264/33746/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

• You potentially added 5 lines to the logs
• Reco comparison results: 7 differences found in the comparisons
• DQMHistoTests: Total files compared: 48
• DQMHistoTests: Total histograms compared: 3195634
• DQMHistoTests: Total failures: 8
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 3195604
• DQMHistoTests: Total skipped: 22
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 47 files compared)
• Checked 207 log files, 159 edm output root files, 48 DQM output files
• TriggerResults: no differences found

[Saptaparna]

Discussed PR with @lauridsj and ready to sign.

[Saptaparna]

+1

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

[perrotta]

Also the comment line should be updated accordingly

And please fix also the PR description, which is misleading:
"The showering is set up in such a way that emissions that are outside a resonance, i.e. do not come from top quarks, are handled by the normal EmissionVetoHook1.cc hook, while PowhegHooksBB4L.h handles emissions that are inside a resonance.
Looking at the single changed line, it can be clearly seen that the condition needs to be the other way around for this to happen correctly - if the emission is in resonance, the EmissionVetoHook should not consider it, and leave it up to PowhegHooksBB4L."
(You say that the condition needs to be to other way around, but you repeat the same conditions as before)

[lauridsj]

Hi,
I've updated the PR description to hopefully make it more clear. As far as I can tell, the comment is already correct (it was not describing the code before the change, which is partly how I found the bug).

[perrotta]

+1