Tests for evolven3fit_new and lhapdf .info files.

[scarlehoff]

I've added a tests that takes an existing fit (with theory 399) and performs the convolution with the eko internal to the theory.

After which the LHAPDF .info file is loaded and a few quick check are performed.
Feel free to suggest further things to check (I've added the ones suggested in #1729 by @cschwan)

Note (@niclaurenti) that I've added the tests with

@pytest.mark.parametrize("fitname", ["Basic_runcard_3replicas_lowprec_399"])

once theory 398 is ready, you can just create a small fit equivalent to Basic_runcard_3replicas_lowprec_399 and add it there and it should work ootb.

[scarlehoff]

@cschwan @RoyStegeman do you know if the order of the flavours in the .info file and the .dat files needs to be the same? (because it isn't right now with eko evolved fits, but I don't know whether this is a bug or a feature at this point)

cc @alecandido @andreab1997

[alecandido]

I guess it would be better if the order were monotonic...

[scarlehoff]

I guess it would be better if the order were monotonic...

The gluon being 21 is problematic :P But regardless, I don't know whether they are supposed to be in the same order so not sure whether the tests should fail right now or not.

[RoyStegeman]

The gluon being 21 is problematic :P

Well apparently you'd be okay with changing the order in one place so might as well move the gluon to the end of the list.

To answer your question - no, I don't know if they need to be the same or where lhapdf uses each internally.

[alecandido]

The gluon being 21 is problematic :P But regardless, I don't know whether they are supposed to be in the same order so not sure whether the tests should fail right now or not.

Ah, sorry, I was thinking to a different type of flavor (the blocks for active number of flavors, but most likely they do not appear in the .info file).

However, the flavors are embedded in each member file, so I guess that is the one used for .xfxQ2() function. Instead, the one in the .info file is most likely "non-standard" as all the other keys there, so it is only used for reporting (with the .info() methods), but not directly by the LHAPDF library itself.

In principle, the answer should then be no, they do not have to be the same. But in practice this depends on users code: if someone relies on them to be the same (despite not being guaranteed by LHAPDF), it would be surprising if they are not.

[alecandido]

https://gitlab.com/hepcedar/lhapdf/-/blob/main/src/Info.cc#L18-65

The only entries of .info known to the LHAPDF library are:

• "Format"
• "AlphaS_OrderQCD"
• "MinLHAPDFVersion"
• "Interpolator"
• "ErrorConfLevel"

apparently...
https://gitlab.com/search?group_id=6283098&language%5B%5D=C%2B%2B&nav_source=navbar&project_id=19453268&repository_ref=main&scope=blobs&search=get_entry+path%3Asrc%2F&search_code=true

(I would have expected more for $\alpha_s$...)

UPDATE: there were more in the headers, but still not flavors

• "SetDesc"
• "XMin"
• "Verbosity"

https://gitlab.com/search?group_id=6283098&language%5B%5D=C%2B%2B&nav_source=navbar&project_id=19453268&repository_ref=main&scope=blobs&search=get_entry+path%3Ainclude%2F&search_code=true

[scarlehoff]

But you are right:

But in practice this depends on users code:

Let's make sure they have the same order because who knows in which weird ways people is using LHAPDF. We don't want to produce broken sets.

[andreab1997]

Everything seems good to me. Before approving this, let me add just a few commits

[felixhekhorn]

Can you add a test where you actually read the PDF using LHAPDF? something along the lines of

import lhapdf # or vp equivalent
pdf = lhapdf.mkPDF("Blub",0)
for q2 in [10,100]: # make them in two different FNS
  assert type(pdf.xfxQ2(pid, x, Q2)) == float # check LHAPDF can actually read for some chosen pid and x
  assert type(pdf.alphasQ2(Q2)) == float # check LHAPDF can actually read

[alecandido]

Can you add a test where you actually read the PDF using LHAPDF? something along the lines of

Then you would have to install LHAPDF in the CI...

Or run inside the lhapdf container, of course :)
https://github.com/NNPDF/workflows/pkgs/container/lhapdf

[RoyStegeman]

Then you would have to install LHAPDF in the CI...

That's already being done (through conda)

[scarlehoff]

RE the explicit LHAPDF test (cc @felixhekhorn) I'm not doing postfit or creating an actual PDF fit. I'm looking at the .dat and .info files in the nnfit folder.

I'm not going to do it here since this PR is already growing a bit too much (and a bit out of scope due to the bugs found while doing it), but I'm planning to do a full fit (setupfit -> fit (2 replicas) -> eko -> postfit) to check that the entire fitting pipeline runs since at the moment each bit is tested by itself.