New jet data

[t7phy]

No description provided.

[scarlehoff]

Hi @t7phy thanks for this.

Two questions,

1. These four datasets are completely new right?
2. I understand you have fktables already for this (since there is a theory block)? They are in theory 600 right?

[t7phy]

Hi @t7phy thanks for this.

Two questions,

1. These four datasets are completely new right?

Yes

2. I understand you have fktables already for this (since there is a theory block)? They are in theory 600 right?

NLO with SV: 401-409
NNLO: 600
NNLO SV: 601-604 and 606-609

[scarlehoff]

Thank you very much for this. These datasets (with theory 600) mostly work out of the box. I'll put here a list of comments. At the bottom there's a few pictures for the theory-data comparisons.

1. The "process_type" key is missing, when there are no reference (like in this case) you can have a look at the file

   nnpdf/validphys2/src/validphys/plotoptions/kintransforms.py

   Line 35 in e005a42

   {'DIS': ('$x$', '$Q^2 (GeV^2)$', '$y$'),

   and use the one that looks the closest (in this case you have JET and DIJET)].
2. You can use x_scale: log for a nicer picture. I've added it manually for some of the plots below. This is aesthetics of course.
3. Please use the latex markers $$ e.g. $GeV^2$ in the units as well.
4. Please remove the implemented by part, git keeps track of all authorship and much more reliably than just the name at the beginning of the file (I know there are some files that have it scattered around the code, mostly from people using sypder I think, we should probably do a pass at some point to remove that).

Everything else seems fine to me. I've tested theory 600. From the plots as you say there seems to be some mismatch between the data and the predictions but I think I agree with you that given the trend it looks more like a grid-problem than a data-problem.

Data-Theory comparisons plots

[scarlehoff]

Everything seems fine to me.

Here's a vp report with chi2, data theory comparison plot, etc

https://vp.nnpdf.science/3vtMtF9yQFe1V-kmiGbh2w==

I'll have a closer look before merging but I think everything is ok and ready to go :)

[scarlehoff]

Ok, I think this can be merged. I don't see any problems with it and want to have a "cannonical example" in #1813 that people can use for reference. I've even tried to use it in a fit and it works fine.
If it needs to be updated later so be it.

There's a few comments however that might be relevant:

1. We should use always the same notation, and maybe have a collection of variables somewhere. Something like this. In principle it doesn't matter since we are no longer relying on "k1, k2, k3" but rather defining their names in the metadata. However it would be nice if everybody uses the same "p_T2" or "pt_sqr" or whatever. "y" or "eta" (which might be different but we are using equivalently in some cases) etc.

2. I need to update how the cuts are applied because they are still relying in the k1/k2/k3 order, so if you try to test the cuts with the new reader it will only work if they happen to be in the expected order for the process_type. I'll do this in the next few days.

3. Points 1 and 2 might be a problem for people implementing old commondata in the new format. But until I don't have some examples I won't be able to see the ways in which this can introduce problems so we'll see :P