K-factors for theory 400

[enocera]

As I'm about to replace theory 400 with the updated K factors, I have some questions.

1. May I remove the unused K-factors, e.g. all the CF_Y and CF_Z?
2. Are there any PineAPPL grids in theory 400 that are accurate to NNLO? For FT DY in particular, are the PineAPPL grids accurate to NLO or to NNLO? I'm asking because, for some data sets (DYE605, DYE906) the name of the PineAPPL grid contains explicitly a nlo string, while it does not for DYE886P and DYE886R Also, if I specify the QCD K-factors in a validphys runcard to compute , e.g. the chi2, validphys crashes for DYE886P because apparently the wrong K-factor file is matched to the PineAPPL grid (and therefore there is a mismatch in the number of data points).
3. Should I keep the [MAS] K factors for NuTeV or are these replaced by PineAPPL grids that include the infamous Jun Gao computation?

[scarlehoff]

May I remove the unused K-factors, e.g. all the CF_Y and CF_Z?

Yes.

Are there any PineAPPL grids in theory 400 that are accurate to NNLO

The accuracy of the grids in th 400 is equal to that of th 200 or I thought that was the agreement. But maybe we decided to update the FTDY? @andreab1997 was this decided at some point? Or maybe all grids were updated?

(I know that for the fit in Gargnano they were NLO and the kfactors work, as I still have that version of theory 400 in my computer and it does work for DYE886P)

Should I keep the [MAS] K factors for NuTeV or are these replaced by PineAPPL grids that include the infamous Jun Gao computation?

@felixhekhorn @alecandido ?

[scarlehoff]

@enocera @andreab1997 ok, wrt to DYE, the problem is that the yaml file in the theory 400 currently in the server has an underscore that shouldn't have. It says DYE886_P when it should be DYE886P. Not sure how that got there, but it seems that everything is NLO as expected.

[enocera]

@enocera @andreab1997 ok, wrt to DYE, the problem is that the yaml file in the theory 400 currently in the server has an underscore that shouldn't have. It says DYE886_P when it should be DYE886P. Not sure how that got there, but it seems that everything is NLO as expected.

Ah, OK, that makes sense. Thanks!

[alecandido]

Should I keep the [MAS] K factors for NuTeV or are these replaced by PineAPPL grids that include the infamous Jun Gao computation?

@felixhekhorn @alecandido ?

You should keep, unfortunately. This has been the bottleneck to yadism publication for some time, and it's still there. For the time being we are (or I am) lacking resources to work on this project, that is a bit more demanding than expected (if you wish I can provide further details at some meeting)

[alecandido]

Are there any PineAPPL grids in theory 400 that are accurate to NNLO

To the best of my knowledge, the answer is "all and only DIS grids".
Since yadism is now producing PineAPPL grids, that's technically correct, but I guess you were aware of DIS, and interested in everything else.

[enocera]

Are there any PineAPPL grids in theory 400 that are accurate to NNLO

To the best of my knowledge, the answer is "all and only DIS grids". Since yadism is now producing PineAPPL grids, that's technically correct, but I guess you were aware of DIS, and interested in everything else.

Of course, my bad, the question was not formulated correctly: in my mind I wanted to ask "Are there any PineAPPL grids in theory 400 that are accurate to NNLO, EXCEPT DIS grids?"

[enocera]

Should I keep the [MAS] K factors for NuTeV or are these replaced by PineAPPL grids that include the infamous Jun Gao computation?

@felixhekhorn @alecandido ?

You should keep, unfortunately. This has been the bottleneck to yadism publication for some time, and it's still there. For the time being we are (or I am) lacking resources to work on this project, that is a bit more demanding than expected (if you wish I can provide further details at some meeting)

OK, no problem, good to know.

[enocera]

Theory 400 is now updated with the K factors. I've also corrected the DYE886P.yaml file. As a check that everything works as it should, here's a comparison between the exp chi2 computed with theories 200 and 400 with NNPDF40_nnlo_as_01180
https://vp.nnpdf.science/1Ztq4PJYSzOZOxp1EHA4NA==
The difference in total chi2 is 0.03 (mostly driven by DIS, I'd say), which is slightly more than 1sigma in units of chi2 for 4618 data points. I'm looking forward to see whether this difference can be reduced once the data set is refitted with theory 400.

[scarlehoff]

Great, thanks! I'll try to send the fit today.

[scarlehoff]

Fit finished, this is the comparison. The quality of the fit is still worse... https://vp.nnpdf.science/K0hKnnd-T2qzGp5S-sHnaw==/

I am not happy with this dataset in particular https://vp.nnpdf.science/K0hKnnd-T2qzGp5S-sHnaw==/matched_datasets_from_dataspecs74_dataset_report_report.html#matched_datasets_from_dataspecs74_dataset_report_Datanorm_plot_fancy_dataspecs_0

This is the one that had the wrong factor for the first set of bins, which we fixed https://github.com/NNPDF/fktables/issues/5 /cc @cschwan @felixhekhorn @alecandido

I'm wondering whether that wrong factor propagated to the commondata or the kfactor?

[enocera]

I'm wondering whether that wrong factor propagated to the commondata or the kfactor?

I don't think that the K-factor can be the culprit: even if there were a factor wrong, it'd be the same in the numerator and in the denominator of the K-factor, therefore it will cancel out.

The commondata seems OK to me.

[scarlehoff]

Maybe we overcompensated in the new fktables then? but I am surprised that the previous (wrong one) was so close to the data if the effect was that big…

[enocera]

Is theory 414 the NLO version of theory 400? I'm asking because I'd like to look at the difference between the NLO and NNLO description of the data set. The old and new K-factors vary by 1.5% for certain bins, so I'd like to see whether most of the discrepancy we now see between data and theory comes from the NLO theory or from the NNLO K-factor.

[scarlehoff]

@andreab1997 did all the 4XY theories so I'm pinging him :P

[andreab1997]

Is theory 414 the NLO version of theory 400? I'm asking because I'd like to look at the difference between the NLO and NNLO description of the data set. The old and new K-factors vary by 1.5% for certain bins, so I'd like to see whether most of the discrepancy we now see between data and theory comes from the NLO theory or from the NNLO K-factor.

Yes indeed, 414 is the NLO version of theory 400. It is going to change soon because some bugs have been found and I am now recomputing everything. Anyway, I don't expect 414 to really change because the bugs should only have affected the scale varied theories (and 414 is of course the central).

[alecandido]

Just for the sake of reporting: it is true that CMS_TTBAR_2D_DIFF_MTT_TRAP_NORM was the one with the wrong K-factor, but it was only the very first bin!
https://github.com/NNPDF/fktables/issues/5#issue-1053582915 (look in that comment, the first, for the dataset name, unfortunately I've not been able to find back the discussion)

[enocera]

@alecandido I guess that you mean the first invariant mass bin - which is the bin where we see the normalisation issue.

[alecandido]

Yes, exactly. They are actually 4 bins of the 2D distribution, but it seemed like only 3 bins had a major difference https://github.com/NNPDF/fktables/issues/5#issuecomment-1073211835

The discussion continues in the following comments, however, I believe that has been basically the agreement.

[enocera]

@scarlehoff I think that I've fixed the problem with the CMS 8TeV ttbar 2D diff measurement. The problem was that, after fixing the normalisation of the first invariant mass bin, the total fiducial cross section was not making the normalised differential distribution integrate to one. I have therefore recomputed the FK table (with the new pipeline) for the denominator. I've taken this opportunity to re-check the data implementation. Everything is OK, except for the fact that one bin, which is clearly linearly dependent from the others, must be removed. This is done in #1633. Theory 400 is updated on the server.
So @scarlehoff I'd be grateful if you could run what will hopefully become the NNPDF4.0 new baseline fit. In order to do this you have to:

• review and merge Adding filter rule to remove one linearly dependent bin from the CMS 2D top distribution #1633;
• erase theory 400 and download it again from scratch from the server.

[enocera]

@scarlehoff As a check you can see here a data/theory comparison
https://vp.nnpdf.science/zHcJkbiNS9yxFQbdOcgfHg==

[enocera]

cc @cschwan I believe that there are a couple of PRs related to this one:

• the pinecards used to generate the pineapplgrid Added pinecards for the normalising cross section of the CMS 2D mtt yt diff distr. pinecards#157
• the pineappl grid obtained by running madgraph on the former Added pineapplgrid for CMS_TTB_8TEV_2D_TTM_TRAP normalising cross section pineapplgrids#28

[enocera]

@cschwan @alecandido @felixhekhorn I confess that it remains a little unclear to me whether I should also open a PR in pineko and push the relevant cards there.

[scarlehoff]

I think the one you opened here NNPDF/pinecards#157 is sufficient to reproduce the grid, so it should be enough.

[enocera]

@scarlehoff OK, thanks, then @cschwan will dismiss NNPDF/pineapplgrids#28 if need be.

[scarlehoff]

That we might want to have just to have a place where to download the grids from.

[cschwan]

@enocera they way you did it is basically how I would've done it 👍 .

[alecandido]

@cschwan @alecandido @felixhekhorn I confess that it remains a little unclear to me whether I should also open a PR in pineko and push the relevant cards there.

Pineko repo has no runcards, the official place is actually NNPDF/runcards, and no one else :)

Moreover, Pineko never generates directly grids, can only consume already computed ones, and for time being manually pulled.
The program computing grids is Pinefarm, and it is actually in the NNPDF/runcards repo at the moment (maybe it will have its own repo later on, and maybe not).

P.S.: the reason for Pinefarm being inside NNPDF/runcards is mostly historical, it is just the evolution of old good run.sh by @cschwan, so there has been no clear decision about where to place it, because it adiabatically evolved from a single script

[enocera]

@cschwan @alecandido @felixhekhorn I confess that it remains a little unclear to me whether I should also open a PR in pineko and push the relevant cards there.

Pineko repo has no runcards, the official place is actually NNPDF/runcards, and no one else :)

Thanks for the clarification. I have indeed noticed that no runcards are stored in pineko. I was thinking about the .yaml file in the ymldb folder, but clearly you do not consider that these files need to be stored somewhere. Anyway, as far as this issue is concerned, I understand that what I did is sufficient. Thanks for the confirmation.

[alecandido]

clearly you do not consider that these files need to be stored somewhere

They will have to, it is simply not properly done at the moment.
The main problem has been that we already know the final solution (that will be including that information inside the new Commondata), but we should have addressed better the issue, since that one is not going to come anytime soon.

[enocera]

clearly you do not consider that these files need to be stored somewhere

They will have to, it is simply not properly done at the moment. The main problem has been that we already know the final solution (that will be including that information inside the new Commondata), but we should have addressed better the issue, since that one is not going to come anytime soon.

Colpito e affondato.

[scarlehoff]

I will try to push the new commondata as soon as the new baseline with the new pipeline is ready (doing the report right now!) I'm hoping the yamldb doesn't get used beyond this new baseline.

[enocera]

Well, Tommaso and I are also making good progress with the translation of the NNPDF4.0 data set in the new format.

[alecandido]

Colpito e affondato.

Sorry, my intention was not to accuse of something, but rather apologize not to have implemented a better temporary solution 😅 (I guess @andreab1997 is copy-pasting it for MHOU computation)

[enocera]

Colpito e affondato.

Sorry, my intention was not to accuse of something, but rather apologize not to have implemented a better temporary solution sweat_smile (I guess @andreab1997 is copy-pasting it for MHOU computation)

I know, I know, but I like to blame myself.

[scarlehoff]

This can be closed I believe?

[enocera]

Yes.