Cross section numbers

Asked by Lailin Xu

Hi,

I'm generating VBF qq->ZZjj, ZZ->4l events with MadGraph:

define p = g u c d s u~ c~ d~ s~
define j = g u c d s u~ c~ d~ s~
define za = z a
generate p p > j j za za QCD=0 QED=4, za > e+ e-, za > mu+ mu-
add process p p > j j za za QCD=0 QED=4, za > e+ e-, za > e+ e-
add process p p > j j za za QCD=0 QED=4, za > mu+ mu-, za > mu+ mu-

I firstly run Gridpack, and I got the cross section number from log file:
     Cross-section : 0.0007272 +- 5.745e-06 pb
     Nb of events : 0

Then I run event generation with the Gridpack, asking 5500 events for each job. But I got only a few hundred
of events generated per job. I understand that this might be expected for VBF processes with MadGraph.
So to reach expected total number of events, I run more jobs.
For each LHE file, I think there are two places to extract the cross section numbers, one from the header
and the other one from the <init> part. But I see these two numbers are inconsistent, for example:

<MGGenerationInfo>
# Number of Events : 10000
# Integrated weight (pb) : 0.000672010392961
</MGGenerationInfo>
</header>
<init>
2212 2212 6.500000e+03 6.500000e+03 0 0 262000 262000 -3 1
6.543485e-05 8.309022e-07 6.667212e-08 3
<generator name='MadGraph5_aMC@NLO' version='5.2.4.3'>please cite 1405.0301 </generator>
</init>

So now I have 3 numbers:
1. from Gridpack generation: 0.0007272 +- 5.745e-06 pb
2. from LHE header <MGGenerationInfo>: 0.000672010392961 pb
3. from <init>: 6.543485e-05 pb

Which number should I trust?

Also, since I run multiple event generation jobs, how should I get the combined cross section? Just average the
number from each job, or take the weighted average according to the number of events generated for each job?

It seems that the cross section number from each job can vary a lot, for example from another job I see:

<MGGenerationInfo>
# Number of Events : 10000
# Integrated weight (pb) : 0.000697978653906
</MGGenerationInfo>
</header>
<init>
2212 2212 6.500000e+03 6.500000e+03 0 0 262000 262000 -3 1
1.363760e-04 1.619496e-06 6.928464e-08 3
<generator name='MadGraph5_aMC@NLO' version='5.2.4.3'>please cite 1405.0301 </generator>
</init>

The cross section in <init> is significantly different than the other jobs. Does this number make sense?

Sorry for asking so many questions and thanks a lot for your help in advance!

Lailin

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

Hi,

Your syntax does not make any sense.
You can not ask a photon to be on shell.

Cheers,

Olivier

> On 8 Feb 2017, at 02:53, Lailin Xu <email address hidden> wrote:
>
> New question #452500 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/452500
>
> Hi,
>
> I'm generating VBF qq->ZZjj, ZZ->4l events with MadGraph:
>
> define p = g u c d s u~ c~ d~ s~
> define j = g u c d s u~ c~ d~ s~
> define za = z a
> generate p p > j j za za QCD=0 QED=4, za > e+ e-, za > mu+ mu-
> add process p p > j j za za QCD=0 QED=4, za > e+ e-, za > e+ e-
> add process p p > j j za za QCD=0 QED=4, za > mu+ mu-, za > mu+ mu-
>
> I firstly run Gridpack, and I got the cross section number from log file:
> Cross-section : 0.0007272 +- 5.745e-06 pb
> Nb of events : 0
>
> Then I run event generation with the Gridpack, asking 5500 events for each job. But I got only a few hundred
> of events generated per job. I understand that this might be expected for VBF processes with MadGraph.
> So to reach expected total number of events, I run more jobs.
> For each LHE file, I think there are two places to extract the cross section numbers, one from the header
> and the other one from the <init> part. But I see these two numbers are inconsistent, for example:
>
> <MGGenerationInfo>
> # Number of Events : 10000
> # Integrated weight (pb) : 0.000672010392961
> </MGGenerationInfo>
> </header>
> <init>
> 2212 2212 6.500000e+03 6.500000e+03 0 0 262000 262000 -3 1
> 6.543485e-05 8.309022e-07 6.667212e-08 3
> <generator name='MadGraph5_aMC@NLO' version='5.2.4.3'>please cite 1405.0301 </generator>
> </init>
>
> So now I have 3 numbers:
> 1. from Gridpack generation: 0.0007272 +- 5.745e-06 pb
> 2. from LHE header <MGGenerationInfo>: 0.000672010392961 pb
> 3. from <init>: 6.543485e-05 pb
>
> Which number should I trust?
>
> Also, since I run multiple event generation jobs, how should I get the combined cross section? Just average the
> number from each job, or take the weighted average according to the number of events generated for each job?
>
> It seems that the cross section number from each job can vary a lot, for example from another job I see:
>
> <MGGenerationInfo>
> # Number of Events : 10000
> # Integrated weight (pb) : 0.000697978653906
> </MGGenerationInfo>
> </header>
> <init>
> 2212 2212 6.500000e+03 6.500000e+03 0 0 262000 262000 -3 1
> 1.363760e-04 1.619496e-06 6.928464e-08 3
> <generator name='MadGraph5_aMC@NLO' version='5.2.4.3'>please cite 1405.0301 </generator>
> </init>
>
> The cross section in <init> is significantly different than the other jobs. Does this number make sense?
>
>
> Sorry for asking so many questions and thanks a lot for your help in advance!
>
> Lailin
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Lailin Xu (xlltoade) said :
#2

Hi Olivier,

Thanks for your quick response.
I reason I did it like this was to include the photon diagrams. But you made a good point that I could not ask
a photon to be on shell. I tried to use pp > jj l+ l- l+ l- QCD=0 QED=6, but it took quite long time to generate
the gridpack.

However, I also tried the following without photon diagrams:

generate p p > j j z z QCD=0 QED=4, z > e+ e-, z > mu+ mu-
add process p p > j j z z QCD=0 QED=4, z > e+ e-, z > e+ e-
add process p p > j j z z QCD=0 QED=4, z > mu+ mu-, z > mu+ mu-

I got the same kind of problems, i.e. fewer events generated than requested, different cross section numbers.
Do you have any suggestions?

Thanks,
Lailin

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

Hi,

Since you have only few hundreds of generated events, you clearly have huge statistical uncertainty which means that all those number are within your statistical uncertainty range.
My guess is that even for such large statistical error (10%) you will still be dominated by the systematics uncertainty (I did not run the number but they are typically much bigger than 10% at LO).

Now you can see that the statistical problem is already at the grid pack level, since you have a quite high error for a grid pack generation.

Cheers,

Olivier

Revision history for this message
Lailin Xu (xlltoade) said :
#4

Hi Olivier,

Thanks for your explanation.
Just for curiosity, for the first syntax I mentioned:

define za = z a
generate p p > j j za za QCD=0 QED=4, za > e+ e-, za > mu+ mu-
add process p p > j j za za QCD=0 QED=4, za > e+ e-, za > e+ e-
add process p p > j j za za QCD=0 QED=4, za > mu+ mu-, za > mu+ mu-

I do see a lot of diagrams with photon. I forgot to mention that I set bwcutoff as 10000000. Perhaps
that's the reason I have photon diagrams?
Do you think it still makes sense to use the generated LHE events, but just use the cross section at
the gridpack level?

Thanks,
Lailin

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

Dear Lailin,

1) Zero (the width of the photon) times any number (bwcutoff) is still zero.

So the photon contribution will be handle in a way which might not be physical. With such syntax I do not guarantee at all the results.

2) If you set bwcutoff as 10000000 this explains why your convergence is so bad, since you actually allowed your Z to be off-shell
While by stating that those need to be on-shell all the code is optimised to have those on shell. The off-shell part of the Z is assumed to be suppressed
(which is certainly not the case in presence of the photon diagram)

With such large cut, the full phase-space will be cover but it deeply rely on numerical adaptation of the grid to cover the low q-square part of your phase-space.
If you really want the full phase-space then you should use another syntax like

> generate p p > j j e+ e- mu+mu- QCD=0 QED=4

Your syntax is indeed faster but simply do not converge correctly (forgetting that the syntax is just wrong in presence of photon).

> Perhaps
> that's the reason I have photon diagrams?

The bwcutoff is a parameter of the phase-space integration. You have the diagram because you ask such diagram.
We are not able to forbid all the syntax which does not make sense. We try to be as much user friendly as possible but at the same time,
This is the user responsibility to ask something which make sense. (My philosophy is to only forbid stuff which will NEVER make sense)

> Do you think it still makes sense to use the generated LHE events, but just use the cross section at
> the gridpack level?

For your syntax. No.

Cheers,

Olivier

> On 8 Feb 2017, at 10:53, Lailin Xu <email address hidden> wrote:
>
> Question #452500 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/452500
>
> Lailin Xu posted a new comment:
> Hi Olivier,
>
> Thanks for your explanation.
> Just for curiosity, for the first syntax I mentioned:
>
> define za = z a
> generate p p > j j za za QCD=0 QED=4, za > e+ e-, za > mu+ mu-
> add process p p > j j za za QCD=0 QED=4, za > e+ e-, za > e+ e-
> add process p p > j j za za QCD=0 QED=4, za > mu+ mu-, za > mu+ mu-
>
> I do see a lot of diagrams with photon. I forgot to mention that I set bwcutoff as 10000000. Perhaps
> that's the reason I have photon diagrams?
> Do you think it still makes sense to use the generated LHE events, but just use the cross section at
> the gridpack level?
>
> Thanks,
> Lailin
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Can you help with this problem?

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

To post a message you must log in.