Number of loops for alpha_s computation

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

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:
> https://answers.launchpad.net/mg5amcnlo/+question/657139
>
> 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
> [2] models/model_reader.py
> [3] https://answers.launchpad.net/mg5amcnlo/+question/403755
>
>
> Cheers,
> Andrey
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

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

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

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

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