Cross section with average = event_norm

Asked by Bing

Hello,

I am generating events with a Z' model (Z->mumu, one muon radiates a Z' which then decays to another two muons), with PDF NNPDF30_nlo_as_0118 (260000). Please see the details in the end.

When I use "average = event_norm", I get the cross section of 2.355e-4 fb with 33600 number of events
When I use "sum = event_norm", I get the cross section of 9.96527 fb

My question is should I use the 9.96 fb or 2.355e-4*33600 = 7.9128 fb for the correct cross section, and why they are different?

Thanks a lot!

Best,
Bing Li

import model Leptophilic_UFO
define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
define l+ = e+ mu+
define l- = e- mu-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
define p = g u c d s b u~ c~ d~ s~ b~
define j = g u c d s b u~ c~ d~ s~ b~
set group_subprocesses Auto
set ignore_six_quark_processes False
set gauge unitary
set complex_mass_scheme False
generate p p > mu+ mu- Zp, Zp > mu+ mu-
output -f -nojpeg

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

How do you get those values?
The value printed on the screen (or in the <init> block) should not be affected by this parameter
(but the weight of the events are).

Now is it possible for your process to have this process?
generate p p > Zp Zp
In that case, you have an issue of symmetry with your above syntax and therefore your above syntax will lead to badly define symmetry factor.
So you should likely not use the above syntax but the following one:
generate p p > Zp mu+ mu- $ Zp, Zp > mu+ mu-
add process p p > Zp Zp, Zp > mu+ mu-

If interference is important then obviously the only method is
generate p p > 2mu+ 2mu-
(in that case it is unlikely safe to ask at least one Zp)

Cheers,

Olivier

> On 18 Sep 2020, at 11:30, Bing <email address hidden> wrote:
>
> average = event_norm

Revision history for this message
Bing (llll2469) said :
#2

Hi Olivier,

Thanks for the prompt reply!

1. Yes those numbers are taken from the <init> block.

2. In this specific model we are looking into, the Z' only couples to muon and muon neutrinos so there is no p p > Zp Zp.

Best,
Bing Li

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#3

is the model. available online?

I would not trust any of those numbers.

Cheers,

olivier

> On 18 Sep 2020, at 11:55, Bing <email address hidden> wrote:
>
> Question #692985 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/692985
>
> Bing posted a new comment:
> Hi Olivier,
>
> Thanks for the prompt reply!
>
> 1. Yes those numbers are taken from the <init> block.
>
> 2. In this specific model we are looking into, the Z' only couples to
> muon and muon neutrinos so there is no p p > Zp Zp.
>
> Best,
> Bing Li
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Tiesheng Dai (daits) said :
#4

Hello Oliver
   Thanks for the help.
   The model is integrated into ATLAS ATHENA software, I used ATHENA AthGeneration 21.6.40 to generate events. Somehow I can not reproduce the issue anymore, now the cross-section does not depending on my "event_norm" initial setting on run_card.dat. Also from LHE event, it is always "average = event_norm", while the event weight is total cross-section. see:

>>>
...
  average = event_norm ! average/sum. Normalization of the weight in the LHEF
....
</initrwgt>
<MGGenerationInfo>
# Number of Events : 33600
# Integrated weight (pb) : 0.00996239190081
</MGGenerationInfo>
</header>
<init>
2212 2212 6.500000e+03 6.500000e+03 0 0 260000 260000 -4 1
   +9.9628353e-03 +1.5167745e-05 +9.9671365e-03 1
<generator name='MadGraph5_aMC@NLO' version='2.7.3'>please cite 1405.0301 </generator>
</init>
<event>
 8 1 +9.9666929e-03 8.69638200e+01 7.81860800e-03 1.18852900e-01
        2 -1 0 0 501 0 +0.0000000000e+00 +0.0000000000e+00 +2.2332199346e+01 2.2332199492e+01 2.5500000000e-03 0.0000e+00 1.0000e+00
       -2 -1 0 0 0 501 -0.0000000000e+00 -0.0000000000e+00 -8.4661459363e+01 8.4661459401e+01 2.5500000000e-03 0.0000e+00 -1.0000e+00
       23 2 1 2 0 0 +0.0000000000e+00 +3.5527136788e-15 -6.2329260017e+01 1.0699365889e+02 8.6963822300e+01 0.0000e+00 0.0000e+00
   999888 2 3 3 0 0 -7.9295947792e+00 -1.4232913141e+01 -1.1883846391e+01 2.0776906237e+01 4.9999737903e+00 0.0000e+00 0.0000e+00
      -13 1 3 3 0 0 -5.5618826049e+00 -1.5637998335e+01 +8.5928161547e+00 1.8690350011e+01 1.0566000000e-01 0.0000e+00 1.0000e+00
       13 1 3 3 0 0 +1.3491477384e+01 +2.9870911476e+01 -5.9038229780e+01 6.7526402644e+01 1.0566000000e-01 0.0000e+00 -1.0000e+00
      -13 1 4 4 0 0 -2.1427091148e+00 -8.4902519799e+00 -4.8599266017e+00 1.0015269924e+01 1.0566000000e-01 0.0000e+00 1.0000e+00
       13 1 4 4 0 0 -5.7868856643e+00 -5.7426611610e+00 -7.0239197894e+00 1.0761636314e+01 1.0566000000e-01 0.0000e+00 -1.0000e+00
<mgrwt>
<rscale> 0 0.86963822E+02</rscale>
...
>>>>

regards
Tiesheng

Can you help with this problem?

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

To post a message you must log in.