~5% Disagreement in cross section between LO Drell-Yan in Pythia and Madgraph

Asked by CW

Hi Madgraph team,

I'm having a problem where the resultant cross section for the process p p > e+ e- /z diagrees between madgraph and pythia at about the 5% level. This can't be correct since it's a purely leading order calculation, right? I want to get them to agree. Below are the steps and ideas I've taken to try and make it happen.

In order to do this comparison, I've tried to set everything in pythia to match what's in the param_card.dat and run_card.dat file as faithfully as possible.

I've disabled any cuts on the leptons in madgraph, so in the run_card.dat file I have: 'F = cut_decays' and any other lepton parameters are left as their defaults. The only lepton cuts I have included specify the invariant mass range of the lepton pair, so
 70 = mmll ! min invariant mass of l+l- (same flavour) lepton pair
 400 = mmllmax ! max invariant mass of l+l- (same flavour) lepton pair

I'm using cteq6l1 as the pdf for each generator. In pythia I made sure to set alphaS(mZ) to its ct6l1 value. I've also made sure that alphaS and alphaEM run at first order.

In pythia I've turned off any sort of tuning, isr and fsr radiation, and made sure to disable the intermediate Z. The reason I disabled the Z was to rule out any discrepancies in the definitions of electroweak parameters between generators, but it doesn't seem like that's the case.

One thing I've noticed is that the value of alphaEW(mZ) used in madgraph 'aEWM1' doesn't match pythia, but that's because it's consistent with what the calculator gives, so I shouldn't have to worry about that right? Editing that value myself to match pythia's ~1/128 gives an even worse appoximation to the cross section than leaving it as its default ~1/132.

Anyway, I'm running out of ideas and I know at leading order I should be getting identical results. For reference the actual cross sections are:

madgraph: 18.38 +- 0.007408 pb
pythia: 19.39 +- 2.842e-02 pb

where sqrt(s)=8 TeV.

Thank you very much for your time.

Cheers,
CW

Question information

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

Hi,

Actually the MMLL cut is currently bugged so this is the reason.
This was identified very recently and this is going to be fixed in the next version of the code (which should be released on Friday)

Sorry for that,

Olivier

On Mar 16, 2014, at 1:31 AM, CW <email address hidden> wrote:

> New question #245570 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/245570
>
> Hi Madgraph team,
>
> I'm having a problem where the resultant cross section for the process p p > e+ e- /z diagrees between madgraph and pythia at about the 5% level. This can't be correct since it's a purely leading order calculation, right? I want to get them to agree. Below are the steps and ideas I've taken to try and make it happen.
>
> In order to do this comparison, I've tried to set everything in pythia to match what's in the param_card.dat and run_card.dat file as faithfully as possible.
>
> I've disabled any cuts on the leptons in madgraph, so in the run_card.dat file I have: 'F = cut_decays' and any other lepton parameters are left as their defaults. The only lepton cuts I have included specify the invariant mass range of the lepton pair, so
> 70 = mmll ! min invariant mass of l+l- (same flavour) lepton pair
> 400 = mmllmax ! max invariant mass of l+l- (same flavour) lepton pair
>
> I'm using cteq6l1 as the pdf for each generator. In pythia I made sure to set alphaS(mZ) to its ct6l1 value. I've also made sure that alphaS and alphaEM run at first order.
>
> In pythia I've turned off any sort of tuning, isr and fsr radiation, and made sure to disable the intermediate Z. The reason I disabled the Z was to rule out any discrepancies in the definitions of electroweak parameters between generators, but it doesn't seem like that's the case.
>
> One thing I've noticed is that the value of alphaEW(mZ) used in madgraph 'aEWM1' doesn't match pythia, but that's because it's consistent with what the calculator gives, so I shouldn't have to worry about that right? Editing that value myself to match pythia's ~1/128 gives an even worse appoximation to the cross section than leaving it as its default ~1/132.
>
> Anyway, I'm running out of ideas and I know at leading order I should be getting identical results. For reference the actual cross sections are:
>
> madgraph: 18.38 +- 0.007408 pb
> pythia: 19.39 +- 2.842e-02 pb
>
> where sqrt(s)=8 TeV.
>
> Thank you very much for your time.
>
> Cheers,
> CW
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
CW (christopherwillis) said :
#2

Hi Olivier,

Thanks for the swift response. Is the mll cut bugged in all versions of madgraph or just the most recent 2.X? I was using the older Madgraph 1.5.15.

Cheers,
CW

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

I don’t know when this bug was introduce.

You will find a patch for this bug in the following thread (starting from 2.1.0): https://bugs.launchpad.net/mg5amcnlo/+bug/1287999
could you test with this patch, and tell me if you have agreement then?

Cheers,

Olivier

On Mar 16, 2014, at 7:36 AM, CW <email address hidden> wrote:

> Question #245570 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/245570
>
> CW posted a new comment:
> Hi Olivier,
>
> Thanks for the swift response. Is the mll cut bugged in all versions of
> madgraph or just the most recent 2.X? I was using the older Madgraph
> 1.5.15.
>
> Cheers,
> CW
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
CW (christopherwillis) said :
#4

Hi Olivier,

I tested your patch on Madgraph 2.1.0 and it successfully constrains the leptons between the mll and mllmax cut values, however this still doesn't reproduce the correct cross section relative to pythia. Using Madgraph 1.5.15, I never had the problem that the invariant mass distribution of the two leptons was not constrained between the cut values - it always was. Anyway, again after using Madgraph 2.1.0 with the applied patch, I obtain 18.25 +- 0.03262 pb. Still not sure why I'm not seeing agreement.

Thanks again.

Cheers,
CW

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

Thanks,

Actually they are one potential difference between the two computation is the scale used for estimate the PDF.
With the default cut, I pass from 890 pb to 990 pb just by choosing a fix scale instead of a dynamical one.
So this should explains your differences.

Note that MG has now the possibility (since 2.0) to automatically evaluate the scale uncertainty (you need to
1) install lhapdf on your system
2) type "install SysCalc" in the mg5 interface
3) set use_syst on True inside the run_card.

Cheers,

Olivier

Revision history for this message
CW (christopherwillis) said :
#6

Hi Olivier,

Thank you again for the swift response. Unfortunately, I'm not sure the scale choice is the problem. I tried comparisons between the generators with the renormalization and factorization scales fixed at the Z mass. The cross sections I get are
pythia: 19.54 +- 0.002854 pb
madgraph: 18.38 +- 0.007937 pb
with the same lepton invariant mass cuts I mentioned in my original post.

Cheers,
CW

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

Hi Christopher,

I suceed to reproduce you madgraph number, and I don't see anything weird about that result.

>One thing I've noticed is that the value of alphaEW(mZ) used in madgraph 'aEWM1' doesn't match pythia, but that's because it's >consistent with what the calculator gives, so I shouldn't have to worry about that right? Editing that value myself to match pythia's >~1/128 gives an even worse appoximation to the cross section than leaving it as its default ~1/132.

Now if I use 128 instead of 132, then I get for madgraph:
19.63 +- 0.02427 pb. So this is actually much better. I don't reproduce your "worse" approximation stuff.

This is a small scan on the value of the cross-section depending of the aewm1 value:
INFO: 128: 19.63 +- 0.02427 pb
INFO: 128.05 : 19.6186699205
INFO: 128.1 : 19.6033577885
INFO: 128.15 : 19.5880635759
INFO: 128.2 : 19.5727872547
INFO: 128.25 : 19.5575287971
INFO: 128.3 : 19.5422881752
INFO: 128.35 : 19.5270653612
INFO: 128.4 : 19.5118603274
INFO: 128.45 : 19.4966730462
INFO: 128.5 : 19.4815034898
INFO: 128.55 : 19.4663516308
INFO: 128.6 : 19.4512174416
INFO: 128.65 : 19.4361008947
INFO: 128.7 : 19.4210019627
INFO: 128.75 : 19.4059206183
INFO: 128.8 : 19.3908568342
INFO: 128.85 : 19.3758105831
INFO: 128.9 : 19.3607818379
INFO: 120.95 : 19.3457705712
INFO: 129 : 19.3307767562

So which is the value used by Pythia? If it is close to 128.3 then we should have pretty good agreement.

Cheers,

Olivier

Revision history for this message
CW (christopherwillis) said :
#8

Hi again Olivier,

I'm sorry, but I'm failing to see exactly how you changed aEWM1 and got such good agreement. Naively when I edit the param_card.dat file, I change aEWM1 from its default ~ 1/132 to ~1/128, the cross section comes out to be 3.003e+04 +- 49.94 pb, in strong disagreement with your value, so I must be missing something.

Pythia's default value for alphaEM(mZ) is 0.00781751 ~ 1/127.92

Thanks again for your patience.

Cheers,
CW

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

Hi,

Personally I’m using scripting to do everything:
I’ve written a file with the following lines:
generate p p > e+ e- / z
output
launch
set ebeam1 4000
set ebeam2 4000
set mmll 70
set mmllmax 400
set ptl 0
set drll 0
set fixed_ren_scale T
set fixed_fac_scale T
set etal -1
set aewm1 127.912

and then run it as ./bin/mg5_aMC PATH_OF_FILE

and it returns me:
     Cross-section : 19.66 +- 0.0243 pb
     Nb of events : 10000

You can also change directly the line of the param_card.dat corresponding to the SMINPUTS block information:
This is the one used/generated by the command above.
BLOCK SMINPUTS #
      1 1.279120e+02 # aewm1
      2 1.166390e-05 # gf
      3 1.180000e-01 # as

Could you retry to do that run? I guess that you forget to define a cut correctly or something similar.

Cheers,

Olivier

On Mar 19, 2014, at 3:06 PM, CW <email address hidden> wrote:

> Question #245570 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/245570
>
> Status: Answered => Open
>
> CW is still having a problem:
> Hi again Olivier,
>
> I'm sorry, but I'm failing to see exactly how you changed aEWM1 and got
> such good agreement. Naively when I edit the param_card.dat file, I
> change aEWM1 from its default ~ 1/132 to ~1/128, the cross section comes
> out to be 3.003e+04 +- 49.94 pb, in strong disagreement with your value,
> so I must be missing something.
>
> Pythia's default value for alphaEM(mZ) is 0.00781751 ~ 1/127.92
>
> Thanks again for your patience.
>
> Cheers,
> CW
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
CW (christopherwillis) said :
#10

Hi Olivier,

Yes, you are right. I had replaced the 'e' exponent term in the definition of the value for aewm1 with a '0', which was the source of the ridiculous result I was getting. This solves my problem. For the cuts and settings used I find that pythia and madgraph agree within 1%. Thank you again for your time and patience.

Cheers,
CW

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

Great that this is solve:-)

Cheers,

Olivier
On Mar 20, 2014, at 5:46 PM, CW <email address hidden> wrote:

> Question #245570 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/245570
>
> Status: Answered => Solved
>
> CW confirmed that the question is solved:
> Hi Olivier,
>
> Yes, you are right. I had replaced the 'e' exponent term in the
> definition of the value for aewm1 with a '0', which was the source of
> the ridiculous result I was getting. This solves my problem. For the
> cuts and settings used I find that pythia and madgraph agree within 1%.
> Thank you again for your time and patience.
>
> Cheers,
> CW
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.