Possible bug in EmissionVetoHook1.cc for bb4l vetoing

[lauridsj]

When showering LHE events generated by Powheg with Pythia, the file EmissionVetoHook1.cc is used to veto Pythia emissions above the scale set by Powheg to avoid double counting. For the BB4L event generator in Powheg, which generates gg -> bbnunull at full NLO, this presents additional complications since BB4L can generate up to three real emissions at Powheg level (one from the initial state and one from each top decay). For this, the additional file PowhegHooksBB4L.h is used, which takes care of the FSR vetos.

To make sure that EmissionVetoHook1.cc does not also veto the FSR in this case, it contains the following lines (l. 444):

// only use for outside resonance vetos in combination with bb4l:FSREmission:veto
if (!inResonance && settingsPtr->flag("POWHEG:bb4l:FSREmission:veto") == 1)
    return false;

According to the comment, when bb4l is enabled, EmissionVetoHook1.cc should still take care of decays outside of the resonance (which are not taken care of by PowhegHooksBB4L.h). However, the if condition does the opposite of this due to the exclamation mark in front - it skips the veto for events that are outside the resonance. I think this exclamation mark needs to be removed.

To check this, I compared with a local implementation using the standard PowhegHooks.h from Pythia 8.3. Without the exclamation mark, the results are identical, while as the code is now, there is a non-negligible difference.

Pinging @mseidel42 and @agrohsje as the ones who AFAIK originally implemented this.

[cmsbuild]

A new Issue was created by @lauridsj Laurids Jeppe.

@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

[Dr15Jones]

assign generator

[makortel]

assign generators

[cmsbuild]

New categories assigned: generators

@mkirsano,@menglu21,@alberto-sanchez,@SiewYan,@GurpreetSinghChahal,@Saptaparna you have been requested to review this Pull request/Issue and eventually sign? Thanks

[agrohsje]

Thanks @lauridsj for noticing. Unfortunately the old link to my DESY webspace doesn't work anymore. However, I said in the talk that we achieved perfect agreement and the link points to TTbarValidation.cc, so the same routine that you are using. I assume the "!" was already in the modified main31 we received from the authors and that we used for validation. Not sure @mseidel42 can still re-member. In any case, I agree with your conclusion: main31 should be for non-resonant FSR veto.

[mseidel42]

Hi Laurids, just to get the full picture of which code is called, could you post your generator fragment here, please?

Other than that, I agree that the "!" should probably be removed, as the code now seems to not veto FSR outside resonances (while it vetoes FSR in resonances twice).

There is a possibility that this actually shows up in jet multiplicity, you could run https://gitlab.cern.ch/cms-gen/Rivet/-/blob/master/TOP/src/CMS_2018_I1703993.cc for a comparison with 2016 data (with the caveat that single top was subtracted there).

[lauridsj]

Hi Markus, I did not do an actual run in CMSSW - I copied the EmissionVetoHook code and used it standalone with Pythia. If you like, I can try to run it in CMSSW.

For my local setup, I did indeed see a small difference in jet multiplicity as well as in dphi and dR between jets.

[lauridsj]

Hi all, I did a check where I showered my locally produced bb4l LHE files in CMSSW using the standard settings, once with the proposed fix and with the master branch. There is a small difference visible in a few distributions, most notably dphi between the first two light jets: link

A full set of plots from Rivet can be found here: https://www.desy.de/~lauridsj/bb4l_pythia_cmssw_170123

Unfortunately, I unwisely generated the LHE files at 13.6 TeV, so I cannot run a meaningful comparison with data. At some point I need to regenerate them at 13 TeV.

The cmsDriver command used is:

cmsDriver.py Configuration/GenProduction/python/${FRAGMENT}.py --python_filename PythiaBB4L_Rivet.py --customise Configuration/DataProcessing/Utils.addMonitoring --filein "file:$LHEFILE" --conditions 106X_upgrade2018_realistic_v4 --beamspot Realistic25ns13TeVEarly2018Collision --customise_commands="process.MessageLogger.cerr.FwkReport.reportEvery = 200\nprocess.RandomNumberGeneratorService.generator.initialSeed = ${SEED1}" --step GEN --geometry DB:Extended --era Run2_2018 --no_exec --mc -n $NEVENTS

and the fragment is (taken from the central bb4l gridpack):

import FWCore.ParameterSet.Config as cms
from Configuration.Generator.Pythia8CommonSettings_cfi import *
from Configuration.Generator.MCTunes2017.PythiaCP5Settings_cfi import *
from Configuration.Generator.Pythia8PowhegEmissionVetoSettings_cfi import *
from Configuration.Generator.PSweightsPythia.PythiaPSweightsSettings_cfi import *
generator = cms.EDFilter("Pythia8HadronizerFilter",
maxEventsToPrint = cms.untracked.int32(1),
pythiaPylistVerbosity = cms.untracked.int32(1),
filterEfficiency = cms.untracked.double(1.0),
pythiaHepMCVerbosity = cms.untracked.bool(False),
comEnergy = cms.double(13000.),

#bbbar_4l settings
emissionVeto1 = cms.untracked.PSet(),
EV1_vetoOn = cms.bool(True),
EV1_maxVetoCount = cms.int32(100),
EV1_pThardMode = cms.int32(0),
EV1_pTempMode = cms.int32(0),
EV1_emittedMode = cms.int32(0),
EV1_pTdefMode = cms.int32(1),
EV1_MPIvetoOn = cms.bool(True),
EV1_nFinalMode = cms.int32(2),
EV1_nFinal = cms.int32(999),

# set Pythia internal parameters
PythiaParameters = cms.PSet(
pythia8CommonSettingsBlock,
pythia8CP5SettingsBlock,
pythia8PSweightsSettingsBlock,
pythia8BBBar4lSettings = cms.vstring(
            'SpaceShower:pTmaxMatch = 2', # 1 without main31; 2 for main31
            'TimeShower:pTmaxMatch  = 2', # 1 without main31; 2 for main31
            'MultipartonInteractions:pTmaxMatch = 2',
            'POWHEGres:calcScales = off',   # obsolete routine, don't use
            'POWHEG:bb4l = on', # should be on
            'POWHEG:bb4l:FSREmission:veto = true', # default veto implemented using doVetoFSREmission hook
            'POWHEG:bb4l:FSREmission:onlyDistance1 = false', # whether to veto only the first emission, or all of them. Due to shower evolution scale mismatch, all should be vetoed. The pheno impact seems negligible. Only applies to FSREmission veto
            'POWHEG:bb4l:FSREmission:dryRun = false',   # debug switch, don't modify
            'POWHEG:bb4l:FSREmission:vetoAtPL = false', # for debugging only, don't modify
            'POWHEG:bb4l:FSREmission:vetoQED = false',  # whether to veto QED emissions. QED emissions should not be vetoed in b_bbar_4l
            'POWHEG:bb4l:PartonLevel:veto = false',     # alternative veto implemented using doVetoPartonLevel hook. Should yield results equivalent to the FSREmission veto but it is much slower. This is because vetoing individual emissions, the event is completely reshowered if at the first emission should be vetoed. Note that this veto requires features not available in the public version of Pythia (as of version 8.230)
            'POWHEG:bb4l:PartonLevel:excludeFSRConflicting = false', # debug switch, don't modify
            'POWHEG:bb4l:DEBUG = false',  # debug switch, don't modify
            'POWHEG:bb4l:ScaleResonance:veto = false', # alternative veto implemented using ScaleResonance hook. Suffers from scale definition mismatch.
            'POWHEG:bb4l:FSREmission:vetoDipoleFrame = false', # whether or not to calculate veto pt in the dipole frame instead of the resonance frame
            'POWHEG:bb4l:FSREmission:pTpythiaVeto = false', # whether or not to use Pythia's definition of pt
            'POWHEG:bb4l:pTminVeto = 0.8', # hardness in the case of no radiation from the top decay. This should effectively align with Pythia's IR cutoff
            ),

processParameters = cms.vstring(
        'POWHEG:nFinal = 2', ## Number of final state particles
        ## (BEFORE THE DECAYS) in the LHE
        ## other than emitted extra parton
        'TimeShower:mMaxGamma = 1.0',#cutting off lepton-pair production
        ##in the electromagnetic shower
        ##to not overlap with ttZ/gamma* samples
        '6:m0 = 172.5',    # top mass'
),
parameterSets = cms.vstring('pythia8CommonSettings',
'pythia8CP5Settings',
'pythia8BBBar4lSettings',
'pythia8PSweightsSettings',
'processParameters'
)
)
)
ProductionFilterSequence = cms.Sequence(generator)

While the difference is only slight, it should probably still be corrected. If no one has any objections, I will make a PR.

[mseidel42]

Hi Laurids, shouldn't 'pythia8PowhegEmissionVetoSettings' be included in parameterSets to actually "do main31" (veto ISR)? I hope Alexander can confirm.

[lauridsj]

Hi Markus, I am not sure. All I can say that I copied this fragment from what was used to generate the central BB4L MC sample, and that I checked the logs and they do say that ISR emissions are vetoed. Maybe Alexander can clarify.

[Saptaparna]

@lauridsj and @agrohsje any updates on this?

[lauridsj]

@Saptaparna Hi, we sent an email to Tomas (the author of bb4l) about this issue since he seems to have originally provided this code. Otherwise, I would be ready to make a PR (which, given that this is just a stray exclamation mark, should not take long :) )

Regarding what Markus raised about the fragment, I am reasonably certain that what I did actually did ISR vetoing based on the logs, but maybe Alexander could quickly confirm. Specifically, I think what this fragment does is use the EmissionVetoHook1.cc file instead of the standard PowhegHooks.h from Pythia8 (by specifying emissionVeto1 = cms.untracked.PSet(), etc.)