Internal nn23nlo PDF says 0119 but uses 0118?

Hi Josh,

You are correct this is not reported correctly. This is actually already fixed in 2.4.0.
Which is currently release as beta/golden master version and should be the official release probably at the end of the week.

Cheers,

Olivier

> On Apr 25, 2016, at 17:57, Josh McFayden <email address hidden> wrote:
>
> New question #292223 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/292223
>
> Hi all,
>
> We have generated some NLO samples using MG5_aMC_v2.3.3 with this PDF choice in the run card:
> 'nn23nlo' = pdlabel ! PDF set
>
> If I look in MG5_aMC_v2_3_3/Template/NLO/Source/PDF/pdfwrap.f it seems that nn23nlo should correspond to NNPDF23nlo_as_0119_qed_mem0.grid
>
> But then in the init block of the LHE file we have this:
> <init>
> 2212 2212 0.65000000E+04 0.65000000E+04 -1 -1 244600 244600 -4 1
> 0.12719609E+00 0.23663163E-02 0.60717824E+00 0
> </init>
>
> where it seems that LHAPDF ID 244600 is used which corresponds to NNPDF23_nlo_as_0118_qed (not the a_S=0.119 version).
>
> Also, in the event block we see:
> <event>
> 6 0 -.60717824E+00 0.18062950E+03 0.78186083E-02 0.11800000E+00
> ...
>
> which shows that a_S=0.118 is the value being used.
>
> Is this a a mistake in Template/NLO/Source/PDF/pdfwrap.f? Or perhaps I should be looking somewhere else for information about what is being used for each internal PDF?
>
> Best,
>
> Josh.
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Thanks Olivier!

Hi Olivier,

Sorry, just to be 100% sure :-)
It's the value of 0.119 reported in pdfwrap.f that's wrong, correct?
0.118 is what's actually used?

Best,

Josh.

Dear Josh, Olivier,

There were indeed 2 bugs in the code. One was fixed in the 2.4.0beta release and the other I just fixed in the 2.4.1 development branch. The bugs were the following:

1. The internal 'nn23nlo' PDF set is the NNPDF23_nlo_as_0119_qed PDF set. The problem was that the LHAGLUE PDF identifier written in the <init> block corresponded to the NNPDF23_nlo_as_0118_qed PDF set, which is obviously wrong. This was fixed in the release 2.4.0beta to correct correspond to the PDF set with alpha_s(MZ)=0.119.

2. The second bug, which was just fixed, is that for the very first event in every integration channel (which means that there could be several in the final event sample), the value of alpha_s written in the event file, is the value given in the param_card.dat and not the value that was actually used in the computation of the event. The events itself are not wrong ---the correct alpha_s and scales were used--- it's only the value of alpha_s written in the event file itself that is not correct.

Best,
Rikkert

Hi Rikkert,

Ah ok, so for 100% clarity:
- Previously for "nn23nlo" a_S=0.119 really is used, as stated in pdfwrap.f?
- And therfore what's written in the LHE is wrong?
- Can you confirm that the other information about the parton id, pdf and x values are correct though?

Of course this isn't deliberate, but just to say it anyway, this causes quite a lot of hassle for us, since we need to perform PDF reweighting based on metadata which is extracted from the LHE file.

Best,

Josh.

Dear Josh,

>Ah ok, so for 100% clarity:
>- Previously for "nn23nlo" a_S=0.119 really is used, as stated in pdfwrap.f?

Yes. This hasn't changed.

>- And therfore what's written in the LHE is wrong?

Exactly.

>- Can you confirm that the other information about the parton id, pdf and x values are correct though?

Confirmed.

>Of course this isn't deliberate, but just to say it anyway, this causes quite a lot of hassle for us, since we need to perform PDF reweighting based on metadata which is extracted from the LHE file.

This I don't understand. You cannot do the reweighting off-line with the LHE file and still keep the NLO accuracy: there are several contributions with various values of Bjorken x's, scales, etc. inside a single event, and they cannot be reweighted by a single value. Doing so leads only to approximate results. Note that we have implemented the reweighting directly into MG5_aMC as described in arXiv:1110.4738. With the latest (beta) release, we have extended this feature to allow even for reweighting over multiple PDF sets.

Best,
Rikkert

Hi Josh,

I will just add one comment to Rik answer:

> With the latest (beta) release, we have extended this feature to allow even for reweighting over multiple PDF sets.

In that version, we have also add an option to keep such information by writting it directly in the file.
This should allow to have accurate PDF re-weighting method off-line.
Our understanding, is that they were few interest in a off-line PDF re-weighting. But if this is not the case, please tell us.

Cheers,

Olivier