Unable to reproduce SM result for g g > t t~

Asked by Matthias König

Hello,

I am probably missing something really obvious, but I have spent a few hours trying to pin down the problem, so please forgive me if this is a dumb question.

I am using MG5 to cross-check a computation, specifically the process g g > t t~ in the SM. I have computed the cross section by hand and get precisely the result given in eq. (50.21) here:

http://pdg.lbl.gov/2017/reviews/rpp2017-rev-cross-section-formulae.pdf

Now, the number I obtain for the total cross section does not at all match the number that MG gives me.

Since my number is larger than the one from MG, I suppose I might be missing a cut. However, I have switched off all cuts in the run_card (to my knowledge).

To obtain my number, I use the values for the couplings taken from MG's param_card. I am also setting the top-width to zero and am fixing the RG scale to the Z mass.

Furthermore, generating the process with g g > t t~ / t, I get a cross-section from MG for purely the s-channel diagram. This number agrees perfectly with my analytic computation. Vice versa, if I exclude the s-channel diagram, the result is completely different.

I have checked g g > u u~ and agree perfectly with MGs numbers, including cuts etc.

Are there any cuts/other subtleties I might have missed here? I'd be very grateful for any hints!

Kindly,
Matthias

Question information

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

Hi,

What is the script that you are using?

I would use a script like that one:
(See https://answers.launchpad.net/mg5amcnlo/+faq/2186)

generate g g > t t~
output
launch
set no_parton_cut
set wt 0
set fixed_scale 91.188
set lpp 0
set ebeam 1000

I have run that script with both the latest and with some quite old version (validated both by ATLAS and CMS)
and they all give the same number. So yes I expect something on your side but without a script like the above one, it is difficult to know what you are missing.

Note that it might be more efficient to not compare the cross-section but the amplitude square directly.
For that you can do "output standalone". This will at least simplify the comparison since you bypass the phase-space integration.

Cheers,

Olivier

> On 3 Oct 2018, at 16:02, Matthias König <email address hidden> wrote:
>
> New question #674631 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/674631
>
> Hello,
>
> I am probably missing something really obvious, but I have spent a few hours trying to pin down the problem, so please forgive me if this is a dumb question.
>
> I am using MG5 to cross-check a computation, specifically the process g g > t t~ in the SM. I have computed the cross section by hand and get precisely the result given in eq. (50.21) here:
>
> http://pdg.lbl.gov/2017/reviews/rpp2017-rev-cross-section-formulae.pdf
>
> Now, the number I obtain for the total cross section does not at all match the number that MG gives me.
>
> Since my number is larger than the one from MG, I suppose I might be missing a cut. However, I have switched off all cuts in the run_card (to my knowledge).
>
> To obtain my number, I use the values for the couplings taken from MG's param_card. I am also setting the top-width to zero and am fixing the RG scale to the Z mass.
>
> Furthermore, generating the process with g g > t t~ / t, I get a cross-section from MG for purely the s-channel diagram. This number agrees perfectly with my analytic computation. Vice versa, if I exclude the s-channel diagram, the result is completely different.
>
> I have checked g g > u u~ and agree perfectly with MGs numbers, including cuts etc.
>
> Are there any cuts/other subtleties I might have missed here? I'd be very grateful for any hints!
>
> Kindly,
> Matthias
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Matthias König (koenigma-qraum) said :
#2

Very nice, I did not know about the option of checking the matrix element directly.!

I was able to pin down the problem - it was indeed on my side. Thanks for the time and sorry for the trouble!

Cheers,
Matthias