# Number of loops for alpha_s computation

Asked by Andrey Popov on 2017-08-30

Dear experts,

I'm trying to understand how MadGraph implements the running of alpha_s with energy. I found the relevant function in [1] (and its translation into Python in [2]), but I'm confused about the choice of the number of loops used in the computation. I know that this argument is somehow determined by the chosen PDF set, but how exactly is it done? Naively, I thought that an LO PDF would call for the one-loop computation, NLO for the two-loop one, and so on. However, numbers do not support this hypothesis.

What I do is generating few events with MadGraph, using a fixed scale, and then checking what value of alpha_s has been written in the LHE file. I compare it against the value computed by Alphas_Runner from [2] for that scale. When running with NNPDF30_lo_as_0130, I reproduce the alpha_s from LHE by setting nloop = 1. However, for the default PDF set "nn23lo1" (which is NNPDF23_lo_as_0130_qed, according to [3]) I had to set nloop = 2 in order to get the value written in the LHE. But both PDF sets are LO ones.

Could you please explain how this parameter is chosen or point me to the relevant documentation? I used MadGraph5_aMC@NLO 2.6.0 for the study if it matters.

[1] Template/LO/Source/alphas_functions.f

Cheers,
Andrey

## Question information

Language:
English Edit question
Status:
Solved
For:
Assignee:
Juan Rojo Edit question
Solved by:
Andrey Popov
Solved:
2017-08-30
Last query:
2017-08-30
2017-08-30
 Andrey Popov (rainfinder) said on 2017-08-30: #1

From file
Template/LO/Source/PDF/pdf_list.txt
it seems that PDF set "nn23lo1" was supposed to be used with nloop = 1, and then there is probably a bug around line 252 of
Template/LO/Source/PDF/pdfwrap.f
where the default nloop = 2 should have been changed to 1, as for some other PDF sets.

I cannot find where nloop is set with LHAPDF though.

Cheers,
Andrey

 Olivier Mattelaer (olivier-mattelaer) said on 2017-08-30: #2

Hi,

The choice of nloop has nothing to do with LO/NLO indeed.
Actually this is a pure choice which is correlated to the value that you choose at MZ.
A good material to understand this was the lecture of Peter Skands at the last MCnet school:
https://indico.cern.ch/event/611360/contributions/2471033/attachments/1486427/2308506/17-MCnet-School-1.pdf

Cheers,

Olivier

PS: In presence of lhpadf, the running of alphas is done directly by lhapdf and not by our code.

> On 30 Aug 2017, at 17:18, Andrey Popov <email address hidden> wrote:
>
> New question #657139 on MadGraph5_aMC@NLO:
>
> Dear experts,
>
>
> I'm trying to understand how MadGraph implements the running of alpha_s with energy. I found the relevant function in [1] (and its translation into Python in [2]), but I'm confused about the choice of the number of loops used in the computation. I know that this argument is somehow determined by the chosen PDF set, but how exactly is it done? Naively, I thought that an LO PDF would call for the one-loop computation, NLO for the two-loop one, and so on. However, numbers do not support this hypothesis.
>
> What I do is generating few events with MadGraph, using a fixed scale, and then checking what value of alpha_s has been written in the LHE file. I compare it against the value computed by Alphas_Runner from [2] for that scale. When running with NNPDF30_lo_as_0130, I reproduce the alpha_s from LHE by setting nloop = 1. However, for the default PDF set "nn23lo1" (which is NNPDF23_lo_as_0130_qed, according to [3]) I had to set nloop = 2 in order to get the value written in the LHE. But both PDF sets are LO ones.
>
> Could you please explain how this parameter is chosen or point me to the relevant documentation? I used MadGraph5_aMC@NLO 2.6.0 for the study if it matters.
>
> [1] Template/LO/Source/alphas_functions.f
>
>
> Cheers,
> Andrey
>
>
> --

 Andrey Popov (rainfinder) said on 2017-08-30: #3

Hello Olivier,

Thank you for the reply. I guess the bottom line for PDF sets included in the MadGraph distribution is that the running of alpha_s is done with the value of nloop that is hard-coded for each set in one of the files I referenced above (and it has been chosen based on the order imposed in the fit for running alpha_s, which is also tied with its numeric value at mZ).

While this and especially your remark about LHAPDF answers my question, I still think that nloop is not set correctly for the "nn23lo1" built-in set. The corresponding set in LHAPDF has alpha_s order 0 (i.e. one-loop running), and the value at mZ is around 0.130. Also, values of alpha_s I obtain for this PDF set from LHAPDF do not agree with the ones computed by MadGraph. Please consider this a bug report.

Cheers,
Andrey

 Olivier Mattelaer (olivier-mattelaer) said on 2017-08-31: #4

Dear Andrey,

I have the following line in the file that you point out:
NNPDF23NLO nn23nlo NNPDF23nlo_as_0119_qed_mem0.grid 0.119 2
NNPDF23LO nn23lo NNPDF23_lo_as_0119_qed_mem0.grid 0.119 2
NNPDF23LO1 nn23lo1 NNPDF23_lo_as_0130_qed_mem0.grid 0.130 1

Those lines have been written by NNPDF author directly, so I should assign this bug to them directly such that they can check themself. However, I'm confuse by your bug report since I have a feeling that you do not have the same line as me.
Is this feeling correct? If so, which version of the code are you using?

Cheers,

Olivier

 Andrey Popov (rainfinder) said on 2017-08-31: #5

Hello Olivier,

> I have the following line in the file that you point out:
> NNPDF23NLO nn23nlo NNPDF23nlo_as_0119_qed_mem0.grid 0.119 2
> NNPDF23LO nn23lo NNPDF23_lo_as_0119_qed_mem0.grid 0.119 2
> NNPDF23LO1 nn23lo1 NNPDF23_lo_as_0130_qed_mem0.grid 0.130 1

This excerpt from Template/LO/Source/PDF/pdf_list.txt looks fine to me. What I'm saying is that in Template/LO/Source/PDF/pdfwrap.f, where, as far as I can tell, nloop is actually set, nloop for "nn23lo1" is set to 2, not 1. Numerical values of alpha_s I get from an LHE files also confirm that the running is done with nloop = 2.

Cheers,
Andrey

 Olivier Mattelaer (olivier-mattelaer) said on 2017-08-31: #6

Ok thanks it is more clear now.

Juan, did you do that on purpose? or is it a real bug in your implementation?

Cheers,

Olivier