Matching with light jets in lowest multiplicity sample

Asked by Hannah Banks on 2021-02-18

Hello, I am new to matching and would be extremely grateful for any help that anyone can offer with this.

I am looking to generate the following BSM processes involving a z-prime boson. I am working in a 5 flavour scheme and showering using Pythia 8.

I set up the process in the following way

define p = p b b~
define q = b b~
define j = j b b~

generate p p > zp > b b~

add process p p > zp > b b~ q

 I need to use matching to avoid double counting here I think.

I have been trying to implement the MLM procedure in Madgraph (with xqcut in the run card set to 20GeV).

In the pythia8 card I set JetMatching:nJetMax = 3
and JetMatching:nJet = 2

The process runs, however the matched cross section that I get out is significantly lower that the cross section that I get when I just generate the lowest multiplicity process (p p > zp > b b~). My understanding is that the matched cross section when including both processes must always be greater than that of the lowest multiplicity sample?

Is this happening because the MLM scheme only works when the lowest multiplicity process does not contain any jets, or am I doing something wrong? Do I need to use CKKW-L instead?

The relevant part of the run_card is:

# Matching parameter (MLM only)
#*********************************************************************
  1 = ickkw ! 0 no matching, 1 MLM
  1.0 = alpsfact ! scale factor for QCD emission vx
  False = chcluster ! cluster only according to channel diag
  5 = asrwgtflavor ! highest quark flavor for a_s reweight
  True = auto_ptj_mjj ! Automatic setting of ptj and mjj if xqcut >0
                                   ! (turn off for VBF and single top processes)
  20.0 = xqcut ! minimum kt jet measure between partons
#***********************************************************************

and the pythia card is:

! Pythia8 cmd card automatically generated by MadGraph5_aMC@NLO
! For more information on the use of the MG5aMC / Pythia8 interface, visit
! https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/LOPY8Merging
!
! ==================
! General parameters
! ==================
!
Main:numberOfEvents = -1
!
! -------------------------------------------------------------------
! Specify the HEPMC output of the Pythia8 shower. You can set it to:
! auto : MG5aMC will automatically place it the run_<i> directory
! /dev/null : to turn off the HEPMC output.
! <path> : to select where the HEPMC file must written. It will
! therefore not be placed in the run_<i> directory. The
! specified path, if not absolute, will be relative to
! the Event/run_<i> directory of the process output.
! fifo : to have MG5aMC setup the piping of the PY8 output to
! analysis tools such as MadAnalysis5.
! fifo@<fifo_path> :
! Same as 'fifo', but selecting a custom path to create the
! fifo pipe. (useful to select a mounted drive that supports
! fifo). Note that the fifo file extension *must* be '.hepmc.fifo'.
! -------------------------------------------------------------------
!
HEPMCoutput:file = auto

! Parameters relevant only when performing MLM merging, which can be
! turned on by setting ickkw to '1' in the run_card and chosing a
! positive value for the parameter xqcut.
! For details, see section 'Jet Matching' on the left-hand menu of
! http://home.thep.lu.se/~torbjorn/pythia81html/Welcome.html
! --------------------------------------------------------------------
! If equal to -1.0, MadGraph5_aMC@NLO will set it automatically based
! on the parameter 'xqcut' of the run_card.dat
JetMatching:qCut = -1.0000000000e+00
! Use default kt-MLM to match parton level jets to those produced by the
! shower. But the other Shower-kt scheme is available too with this option.
JetMatching:doShowerKt = off
! A value of -1 means that it is automatically guessed by MadGraph.
! It is however always safer to explicitly set it.
JetMatching:nJetMax = 3
!
! --------------------------------------------------------------------
! Parameters relevant only when performing CKKW-L merging, which can
! be turned on by setting the parameter 'ptlund' *or* 'ktdurham' to
! a positive value.
! For details, see section 'CKKW-L Merging' on the left-hand menu of
! http://home.thep.lu.se/~torbjorn/pythia81html/Welcome.html
! --------------------------------------------------------------------
! Central merging scale values you want to be used.
! If equal to -1.0, then MadGraph5_aMC@NLO will set this automatically
! based on the parameter 'ktdurham' of the run_card.dat
Merging:TMS = -1.0000000000e+00
! This must be set manually, according to Pythia8 directives.
! An example of possible value is 'pp>LEPTONS,NEUTRINOS'
! Alternatively, from Pythia v8.223 onwards, the value 'guess' can be
! used to instruct Pythia to guess the hard process. The guess would mean
! that all particles apart from light partons will be considered as a part
! of the hard process. This guess is prone to errors if the desired hard
! process is complicated (i.e. contains light partons). The user should
! then be wary of suspicious error messages in the Pythia log file.
Merging:Process =
! A value of -1 means that it is automatically guessed by MadGraph.
! It is however always safer to explicitly set it.
Merging:nJetMax = -1
!
! For all merging schemes, decide whehter you want the merging scale
! variation computed for only the central weights or all other
! PDF and scale variation weights as well
SysCalc:fullCutVariation = off
!
! ==========================
! User customized parameters
! ==========================
!
! By default, Pythia8 generates multi-parton interaction events. This is
! often irrelevant for phenomenology and very slow. You can turn this
! feature off by uncommenting the line below if so desired.
!partonlevel:mpi = off
!
! Additional general parameters.
!
partonlevel:mpi=off
jetmatching:njet=2

I would be extremely grateful if anyone could help me with this.
Thanks ever so much!

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2 hours ago
Last reply:
2 hours ago

Hi,

First if you want to do a 5 flavor computation, you need to set the b mass to zero at the model level.
In that case you do not need the line
define p = p b b~
define j = j b b~
Since this is automaticly done (as well as a bunch of other flag which will be setup for 5 flavor computation as well)
Here are some instruction to do that:
https://answers.launchpad.net/mg5amcnlo/+faq/2312

> generate p p > zp > b b~
> add process p p > zp > b b~ q

Your second process is not complete since you do not allow gluon in the final state.
It is also better to use the following syntax
> generate p p > zp, zp > b b~
> add process p p > zp j, zp > b b~

The syntax that you used is strongly discouraged in general (and especially here)

> In the pythia8 card I set JetMatching:nJetMax = 3
> and JetMatching:nJet = 2

Please check the py8 manual but I do believe that the correct JetMatching:nJetMax should be one here.
(the b coming from the decay do not participate to the matching)

> Is this happening because the MLM scheme only works when the lowest multiplicity process does not contain any jets, or am I doing something wrong? Do I need to use CKKW-L instead?

With the above change you can use either MLM or CKKW-L this is up to you.

Cheers,

Olivier

> On 18 Feb 2021, at 12:35, Hannah Banks <email address hidden> wrote:
>
> New question #695618 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/695618
>
> Hello, I am new to matching and would be extremely grateful for any help that anyone can offer with this.
>
> I am looking to generate the following BSM processes involving a z-prime boson. I am working in a 5 flavour scheme and showering using Pythia 8.
>
> I set up the process in the following way
>
> define p = p b b~
> define q = b b~
> define j = j b b~
>
> generate p p > zp > b b~
>
> add process p p > zp > b b~ q
>
> I need to use matching to avoid double counting here I think.
>
> I have been trying to implement the MLM procedure in Madgraph (with xqcut in the run card set to 20GeV).
>
> In the pythia8 card I set JetMatching:nJetMax = 3
> and JetMatching:nJet = 2
>
> The process runs, however the matched cross section that I get out is significantly lower that the cross section that I get when I just generate the lowest multiplicity process (p p > zp > b b~). My understanding is that the matched cross section when including both processes must always be greater than that of the lowest multiplicity sample?
>
> Is this happening because the MLM scheme only works when the lowest multiplicity process does not contain any jets, or am I doing something wrong? Do I need to use CKKW-L instead?
>
> The relevant part of the run_card is:
>
>
> # Matching parameter (MLM only)
> #*********************************************************************
> 1 = ickkw ! 0 no matching, 1 MLM
> 1.0 = alpsfact ! scale factor for QCD emission vx
> False = chcluster ! cluster only according to channel diag
> 5 = asrwgtflavor ! highest quark flavor for a_s reweight
> True = auto_ptj_mjj ! Automatic setting of ptj and mjj if xqcut >0
> ! (turn off for VBF and single top processes)
> 20.0 = xqcut ! minimum kt jet measure between partons
> #***********************************************************************
>
> and the pythia card is:
>
> ! Pythia8 cmd card automatically generated by MadGraph5_aMC@NLO
> ! For more information on the use of the MG5aMC / Pythia8 interface, visit
> ! https://cp3.irmp.ucl.ac.be/projects/madgraph/wiki/LOPY8Merging
> !
> ! ==================
> ! General parameters
> ! ==================
> !
> Main:numberOfEvents = -1
> !
> ! -------------------------------------------------------------------
> ! Specify the HEPMC output of the Pythia8 shower. You can set it to:
> ! auto : MG5aMC will automatically place it the run_<i> directory
> ! /dev/null : to turn off the HEPMC output.
> ! <path> : to select where the HEPMC file must written. It will
> ! therefore not be placed in the run_<i> directory. The
> ! specified path, if not absolute, will be relative to
> ! the Event/run_<i> directory of the process output.
> ! fifo : to have MG5aMC setup the piping of the PY8 output to
> ! analysis tools such as MadAnalysis5.
> ! fifo@<fifo_path> :
> ! Same as 'fifo', but selecting a custom path to create the
> ! fifo pipe. (useful to select a mounted drive that supports
> ! fifo). Note that the fifo file extension *must* be '.hepmc.fifo'.
> ! -------------------------------------------------------------------
> !
> HEPMCoutput:file = auto
>
> ! Parameters relevant only when performing MLM merging, which can be
> ! turned on by setting ickkw to '1' in the run_card and chosing a
> ! positive value for the parameter xqcut.
> ! For details, see section 'Jet Matching' on the left-hand menu of
> ! http://home.thep.lu.se/~torbjorn/pythia81html/Welcome.html
> ! --------------------------------------------------------------------
> ! If equal to -1.0, MadGraph5_aMC@NLO will set it automatically based
> ! on the parameter 'xqcut' of the run_card.dat
> JetMatching:qCut = -1.0000000000e+00
> ! Use default kt-MLM to match parton level jets to those produced by the
> ! shower. But the other Shower-kt scheme is available too with this option.
> JetMatching:doShowerKt = off
> ! A value of -1 means that it is automatically guessed by MadGraph.
> ! It is however always safer to explicitly set it.
> JetMatching:nJetMax = 3
> !
> ! --------------------------------------------------------------------
> ! Parameters relevant only when performing CKKW-L merging, which can
> ! be turned on by setting the parameter 'ptlund' *or* 'ktdurham' to
> ! a positive value.
> ! For details, see section 'CKKW-L Merging' on the left-hand menu of
> ! http://home.thep.lu.se/~torbjorn/pythia81html/Welcome.html
> ! --------------------------------------------------------------------
> ! Central merging scale values you want to be used.
> ! If equal to -1.0, then MadGraph5_aMC@NLO will set this automatically
> ! based on the parameter 'ktdurham' of the run_card.dat
> Merging:TMS = -1.0000000000e+00
> ! This must be set manually, according to Pythia8 directives.
> ! An example of possible value is 'pp>LEPTONS,NEUTRINOS'
> ! Alternatively, from Pythia v8.223 onwards, the value 'guess' can be
> ! used to instruct Pythia to guess the hard process. The guess would mean
> ! that all particles apart from light partons will be considered as a part
> ! of the hard process. This guess is prone to errors if the desired hard
> ! process is complicated (i.e. contains light partons). The user should
> ! then be wary of suspicious error messages in the Pythia log file.
> Merging:Process =
> ! A value of -1 means that it is automatically guessed by MadGraph.
> ! It is however always safer to explicitly set it.
> Merging:nJetMax = -1
> !
> ! For all merging schemes, decide whehter you want the merging scale
> ! variation computed for only the central weights or all other
> ! PDF and scale variation weights as well
> SysCalc:fullCutVariation = off
> !
> ! ==========================
> ! User customized parameters
> ! ==========================
> !
> ! By default, Pythia8 generates multi-parton interaction events. This is
> ! often irrelevant for phenomenology and very slow. You can turn this
> ! feature off by uncommenting the line below if so desired.
> !partonlevel:mpi = off
> !
> ! Additional general parameters.
> !
> partonlevel:mpi=off
> jetmatching:njet=2
>
>
> I would be extremely grateful if anyone could help me with this.
> Thanks ever so much!
>
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannah Banks (hb1314) said : #2

Hi Olivier,
Thank you so much for your response - I am very grateful.

I did not generate the UFO that I am using myself, but it appears that none of the quarks are massless by default:

e.g. the parameter card looks like:

###################################
## INFORMATION FOR MASS
###################################
Block MASS
    1 5.040000e-03 # MD
    2 2.550000e-03 # MU
    3 1.010000e-01 # MS
    4 1.270000e+00 # MC
    5 4.700000e+00 # MB
    6 1.720000e+02 # MT
   11 5.110000e-04 # Me
   13 1.056600e-01 # MMU
   15 1.777000e+00 # MTA
   23 9.118760e+01 # MZ
   25 1.250000e+02 # MH
   32 1.000000e+03 # MZp

and similarly for the Yukawa couplings:

## INFORMATION FOR YUKAWA
###################################
Block YUKAWA
    1 5.040000e-03 # ymdo
    2 2.550000e-03 # ymup
    3 1.010000e-01 # yms
    4 1.270000e+00 # ymc
    5 4.700000e+00 # ymb
    6 1.720000e+02 # ymt
   11 5.110000e-04 # yme
   13 1.056600e-01 # ymm
   15 1.777000e+00 # ymtau

The reason for this I believe, is that the UFO does not use the default SM.fr file in which the massless.rst and diagonalckm.rst are loaded. Instead, an alternative fr file is used in which every one of the CKM matrix elements is non zero - these are needed in order to set the coupling to the zp (which couples preferentially to third generation) I believe.

Should the light quarks have all been set to massless when the UFO for this model was generated? In which case, should I just put a restrict_XXXX.dat file in the UFO setting all of the quarks up to b and their Yukawa couplings set to 0?

The reason that I was generating using the command p p > zp > b b~ as opposed to p p > zp, zp > b b~ was that I believed that the latter sets the zp to be on shell. However is it the case that if BW_cut is set to a sufficiently large value then the latter will essentially include the off-shell case?

Finally, the reason that I was generating p p > zp q as opposed to p p > zp j was that the contribution from the b quark was significantly greater than any of the other quarks due to its coupling to the zp. I did not test with the gluon however. I found that running with j as opposed to q made the process much much slower. Should I therefore include a gluon in my definition of q and run with this, or will the fact that I am going to set all of the quarks to massless mean that the process with j becomes much quicker?

Thank you very much for all of your help, I really am incredibly grateful.
All the very best

Hannah Banks (hb1314) said : #3

If anyone has any ideas on this, I would be extremely grateful.
Thank you so much
All the best

> Should the light quarks have all been set to massless when the UFO for this model was generated? In which case, should I just put a restrict_XXXX.dat file in the UFO setting all of the quarks up to b and their Yukawa couplings set to 0?

Yes this is the way to go.

> The reason that I was generating using the command p p > zp > b b~ as
> opposed to p p > zp, zp > b b~ was that I believed that the latter sets
> the zp to be on shell. However is it the case that if BW_cut is set to a
> sufficiently large value then the latter will essentially include the
> off-shell case?

If you set the bwcutoff to infinity, you will get the same matrix-element for the full phase-space with the two syntax.
However both syntax will return you non physical results if you allow the full phase-space to be cover.
This is especially true here in presence of matching/merging.
In general the matching/merging procedure implemented assume a factorization between production and decay and such factorization is met by the decay chain syntax (the one with the comma).
But setting bwcutoff to a very large value is NOT a valid option both physically and computationally (we do assume reasonable choice for bwcutoff, i.e that narrow-width approximation is not a bad approximation within the full bwcutoff range).

Our default for bwcutoff is 15 which is already quite large actually. I would not use larger without any dedicated study/carefull reason. I'm actually thinking to make madgraph to crash for any attempt to use bwcutoff larger than something like 50 or 100.

> Finally, the reason that I was generating p p > zp q as opposed to p p >
> zp j was that the contribution from the b quark was significantly
> greater than any of the other quarks due to its coupling to the zp. I
> did not test with the gluon however. I found that running with j as
> opposed to q made the process much much slower.

If you do matching/merging it is important to include the full contribution. Otherwise you will screw the procedure and your sample will not be physical. So you have to use "p" and "j" label everywhere (and use the default value for your model if/when that one will be a 4/5 flavour model.)

> Should I therefore
> include a gluon in my definition of q and run with this, or will the
> fact that I am going to set all of the quarks to massless mean that the
> process with j becomes much quicker?

You will certainly speed-up the computation (a lot) by setting all the mass to 0 since this means that the phase-space is first identical for all those final state and also that many of those matrix-element will be identical.
This will speed-up the computation (but also needed disk space) by quite large factor. (see 1106.0522 <https://arxiv.org/abs/1106.0522> for details)

Cheers,

Olivier

> On 22 Feb 2021, at 12:15, Hannah Banks <email address hidden> wrote:
>
> Question #695618 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/695618
>
> Status: Answered => Open
>
> Hannah Banks is still having a problem:
> Hi Olivier,
> Thank you so much for your response - I am very grateful.
>
> I did not generate the UFO that I am using myself, but it appears that
> none of the quarks are massless by default:
>
> e.g. the parameter card looks like:
>
> ###################################
> ## INFORMATION FOR MASS
> ###################################
> Block MASS
> 1 5.040000e-03 # MD
> 2 2.550000e-03 # MU
> 3 1.010000e-01 # MS
> 4 1.270000e+00 # MC
> 5 4.700000e+00 # MB
> 6 1.720000e+02 # MT
> 11 5.110000e-04 # Me
> 13 1.056600e-01 # MMU
> 15 1.777000e+00 # MTA
> 23 9.118760e+01 # MZ
> 25 1.250000e+02 # MH
> 32 1.000000e+03 # MZp
>
> and similarly for the Yukawa couplings:
>
> ## INFORMATION FOR YUKAWA
> ###################################
> Block YUKAWA
> 1 5.040000e-03 # ymdo
> 2 2.550000e-03 # ymup
> 3 1.010000e-01 # yms
> 4 1.270000e+00 # ymc
> 5 4.700000e+00 # ymb
> 6 1.720000e+02 # ymt
> 11 5.110000e-04 # yme
> 13 1.056600e-01 # ymm
> 15 1.777000e+00 # ymtau
>
> The reason for this I believe, is that the UFO does not use the default
> SM.fr file in which the massless.rst and diagonalckm.rst are loaded.
> Instead, an alternative fr file is used in which every one of the CKM
> matrix elements is non zero - these are needed in order to set the
> coupling to the zp (which couples preferentially to third generation) I
> believe.
>
> Should the light quarks have all been set to massless when the UFO for
> this model was generated? In which case, should I just put a
> restrict_XXXX.dat file in the UFO setting all of the quarks up to b and
> their Yukawa couplings set to 0?
>
> The reason that I was generating using the command p p > zp > b b~ as
> opposed to p p > zp, zp > b b~ was that I believed that the latter sets
> the zp to be on shell. However is it the case that if BW_cut is set to a
> sufficiently large value then the latter will essentially include the
> off-shell case?
>
> Finally, the reason that I was generating p p > zp q as opposed to p p >
> zp j was that the contribution from the b quark was significantly
> greater than any of the other quarks due to its coupling to the zp. I
> did not test with the gluon however. I found that running with j as
> opposed to q made the process much much slower. Should I therefore
> include a gluon in my definition of q and run with this, or will the
> fact that I am going to set all of the quarks to massless mean that the
> process with j becomes much quicker?
>
> Thank you very much for all of your help, I really am incredibly grateful.
> All the very best
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannah Banks (hb1314) said : #5

Thank you so much for your speedy response - I am extremely grateful.

Could I ask another very naive question please? What is the effect of the model that I have been using not having set the light quarks and Yukawa couplings massless? Are the results generated with them massive wrong?

Thanks so much for all of your help
All the very best

> Could I ask another very naive question please? What is the effect of
> the model that I have been using not having set the light quarks and
> Yukawa couplings massless? Are the results generated with them massive
> wrong?

I do not know the answer to that question.
You have likely a lot of inconsistencies by doing that.
The first one is that the PDF assume massless quark for the RGE.

For the matching/merging sensitivity to such inconsistency is of course increased and can likely lead to wrong matching behaviour. But when done with care such inconsistency can sometimes lead to nice feature and advanced user sometimes does such inconsistency on purpose to improve the simulation in some context.

Cheers,

Olivier

> On 23 Feb 2021, at 12:45, Hannah Banks <email address hidden> wrote:
>
> Question #695618 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/695618
>
> Status: Answered => Open
>
> Hannah Banks is still having a problem:
> Thank you so much for your speedy response - I am extremely grateful.
>
> Could I ask another very naive question please? What is the effect of
> the model that I have been using not having set the light quarks and
> Yukawa couplings massless? Are the results generated with them massive
> wrong?
>
> Thanks so much for all of your help
> All the very best
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannah Banks (hb1314) said : #7

Thank you so much for all of your help - I'm incredibly grateful.

Please could I just ask another very stupid question?

I am also interested in generating the following :

generate p p > zp, zp > mu+ mu-
add process p p > zp j, zp > mu+ mu-

My signal consists of the muon pair. I presume that there is not much benefit to using pythia in this instance as I am not really interested in the jet? i.e. that I should be able to get a decent approximation without needing to shower.

However I find that running at Parton level I need to put a cut on ptj otherwise the cross-section becomes large and infact if ptj = 0 the simulation never completes. Using a cut of 20Gev gives me a cross section of 4 x10^-6 pb,
however if I do however with pythia and match with MLM I find that for an xqcut of 20-30 GeV (which appears to be a good choice from the djr plots etc) the cross section is 2.31 x10^-6 pb.
The lowest multiplicity sample (without pythia) has a cross section of 2.108x10-6pb.

Should I be using pythia and matching in this case? Or is a parton level simulation sufficient? If so, is the discrepancy between the two procedures that I get because I need to set my cut on ptj higher?

Thanks so much, I really appreciate it.

Hi,

A 10% difference on the cross-section is nothing to be worried about since this is LO computation (so huge theoretical uncertainty). So with the information that you provide I do not see any obvious issue.

> My signal consists of the muon pair. I presume that there is not much
> benefit to using pythia in this instance as I am not really interested
> in the jet? i.e. that I should be able to get a decent approximation
> without needing to shower.

This is something that you can consider (to be clear use ONLY generate p p > zp, zp > mu+ mu-)
But this is not my call to make and I certainly not have enough information to advise you correctly on that.

cheers,

Olivier

> On 25 Feb 2021, at 13:20, Hannah Banks <email address hidden> wrote:
>
> Question #695618 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/695618
>
> Status: Answered => Open
>
> Hannah Banks is still having a problem:
> Thank you so much for all of your help - I'm incredibly grateful.
>
> Please could I just ask another very stupid question?
>
> I am also interested in generating the following :
>
> generate p p > zp, zp > mu+ mu-
> add process p p > zp j, zp > mu+ mu-
>
> My signal consists of the muon pair. I presume that there is not much
> benefit to using pythia in this instance as I am not really interested
> in the jet? i.e. that I should be able to get a decent approximation
> without needing to shower.
>
> However I find that running at Parton level I need to put a cut on ptj otherwise the cross-section becomes large and infact if ptj = 0 the simulation never completes. Using a cut of 20Gev gives me a cross section of 4 x10^-6 pb,
> however if I do however with pythia and match with MLM I find that for an xqcut of 20-30 GeV (which appears to be a good choice from the djr plots etc) the cross section is 2.31 x10^-6 pb.
> The lowest multiplicity sample (without pythia) has a cross section of 2.108x10-6pb.
>
> Should I be using pythia and matching in this case? Or is a parton level
> simulation sufficient? If so, is the discrepancy between the two
> procedures that I get because I need to set my cut on ptj higher?
>
> Thanks so much, I really appreciate it.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannah Banks (hb1314) said : #9

Thanks for your reply.

As above, I am actually seeing a 50% difference between parton showering of both processes (with merging) compared to parton level calculation (of both processes) with ptj cut.

"This is something that you can consider (to be clear use ONLY generate p p > zp, zp > mu+ mu-)
But this is not my call to make and I certainly not have enough information to advise you correctly on that."

Do you mean just look at this process with and without pythia in order to examine the difference and see whether that is what is causing the above difference?

Thanks very much

If you refer to this:

>Using a cut of 20Gev gives me a cross section of 4 x10^-6 pb,

That number is not to be used and is not physical. You have huge double counting between
generate p p > zp, zp > mu+ mu-
add process p p > zp j, zp > mu+ mu-

Since the second line is actually fully contained in the first.
The action of the matching/merging is actually to remove such double counting (and doing it smoothly).
which is done correctly (as far as i can tell) since the cross-section decreases to 2.31 x10^-6 pb.

Cheers,

Olivier

> On 25 Feb 2021, at 14:20, Hannah Banks <email address hidden> wrote:
>
> Question #695618 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/695618
>
> Status: Answered => Open
>
> Hannah Banks is still having a problem:
> Thanks for your reply.
>
> As above, I am actually seeing a 50% difference between parton showering
> of both processes (with merging) compared to parton level calculation
> (of both processes) with ptj cut.
>
> "This is something that you can consider (to be clear use ONLY generate p p > zp, zp > mu+ mu-)
> But this is not my call to make and I certainly not have enough information to advise you correctly on that."
>
> Do you mean just look at this process with and without pythia in order
> to examine the difference and see whether that is what is causing the
> above difference?
>
> Thanks very much
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hannah Banks (hb1314) said : #11

Thank you so much for your reply - although that result is a parton level result run without any showering. Can you get double counting issues even when running at the parton level then?
Many many thanks!

Sure,

generate p p > zp, zp > mu+ mu-
add process p p > zp j, zp > mu+ mu-

is a clear case where you do have double counting and this is why you need the matching/merging procedure to fix such double counting.

Hannah Banks (hb1314) said : #13

i.e. at parton level does ickkw need to be 1? As the quoted result above was with it set to zero as I thought this would have no effect as pythia is not being run

If you use:

generate p p > zp, zp > mu+ mu-
add process p p > zp j, zp > mu+ mu-

you have to run a parton-shower and a matching/merging procedure.
This can be MLM (which needs ickkw=1) or CKKW-L (which needs ickkw=0).
But whatever value you choose 0/1, the result will be wrong (as you have observed) without the removal of the double counting by one appropriate method and therefore you need a parton-shower.

What you can do is to run ONLY
generate p p > zp, zp > mu+ mu-
and there you can use the event distribution in a physical way with or without parton-shower.

Cheers,

Olivier

Cheers,

Olivier

Can you help with this problem?

Provide an answer of your own, or ask Hannah Banks for more information if necessary.

To post a message you must log in.