# Cross section with average = event_norm

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:
For:
Assignee:
No assignee Edit question
Last query:
2020-09-18
2020-09-18
 Olivier Mattelaer (olivier-mattelaer) said on 2020-09-18: #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

 Bing (llll2469) said on 2020-09-18: #2

Hi Olivier,

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

 Olivier Mattelaer (olivier-mattelaer) said on 2020-09-18: #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:
>
> 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
>
> --

 Tiesheng Dai (daits) said on 2020-09-18: #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>
<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
</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