Exa couplings2

[niclaurenti]

This PR implements the alphaem exact running in the Alpha class in the validphys.photon module.
In this way it is consistent with the running used in EKO for QED.
Such running also considers the mixed terms between the RGEs of alphas and alphaem (therefore they are evolved together).
Edit: Since the solution must enter in the fiatlux integral, and the exact solution is slower than the truncated one, the strategy is to compute $\alpha$ for some reference values in the integration range and then interpolate with scipy (the function is continuous since the matching is applied to $\alpha_s$ only but probably not smooth in the matching points)
Edit n. 2: interpolating with scipy was still too slow so I interpolated with numpy, that is faster
Edit n. 3 (Theoretical issue): the Lux formula uses $\alpha(Q^2)$ to very low values of $Q^2$, below the Landau pole of $\alpha_s$. For this reason I had to remove the mixed terms in the evolution of $\alpha(Q^2)$, i.e. the terms that couple the evolutions of the two couplings. In this way $\alpha$ running is decoupled from $\alpha_s$ running.
It means that the evolution will be slightly inconsistent with the one used in EKO (but in the perturbative regions the difference is sub-permil).

I've performed a fit with this branch and it seems to be good:

• report:
  https://vp.nnpdf.science/U27tsiK-TS6xejU0tw5trQ==
• Photon comparison with NNPDF40_ecc_qed:
  https://vp.nnpdf.science/9gdZCX7wQdyScO6LrrfZbQ==/#PDFscalespecs0_Basespecs1_PDFnormalize1_plot_pdfs_photon
• Photon comparison with NNPDF31_ecc_qed:
  https://vp.nnpdf.science/L2bZ5BABQsq4eKhftwwufg==/#PDFscalespecs0_Basespecs1_PDFnormalize1_plot_pdfs_photon

[scarlehoff]

Thanks for opening the new branch!

I've left a few comments. The general trend is that some more explanation on the docstr (and some comments in the parts where the code might get a bit confusing, specially when many things are happening in the background e.g. due to eko doing stuff) would be good.

[scarlehoff]

Instead of doing like this, you might want to use the hypothesis module to test random values of q (one example here)

https://github.com/NNPDF/nnpdf/blob/master/validphys2/src/validphys/tests/test_utils.py

This has the advantage of being more robust, but the disadvantage that you might not want to test some fringe values.
Not required just in case you want to play a bit with this. It will make the tests more robust and cleaner!

[niclaurenti]

I would skip this since my fear is that some values of q would make the test fail. For example in test_exa_interpolation I had to manually increase the error until I found the one for which the tests were passing, but maybe there are some values for which the error is larger.
Anyway, with the last commit this PR is done

[niclaurenti]

Hi @scarlehoff and @Zaharid , for the reason that I explained in

nnpdf/validphys2/src/validphys/photon/compute.py

Line 500 in d2ecc69

RGEs for the couplings. See Eqs. (5-6) of arXiv:hep-ph/9803211.

I had to decouple the $\alpha$ evolution from the $\alpha_s$ evolution. Therefore, all the $\alpha_s$ part in the photon module is now unused. This will cause a little inconsistence with the EKO evolution but the differences are very small in the perturbative region of QCD.
So what I can do is the following:

• I can leave it implemented, with some parts that are commented out, so that if some day we will need it or we will find a solution we don't have to reimplement it (and moreover it is not slowing down the code).
• I can remove it
  What do you think?

[scarlehoff]

I'm in favor of the removal since if/when someone wants to deal with the problem either this would be the smallest part of the job (and they will have to recheck that everything is correct anyway) or (if it is you or someone already involved in the project) would be able to find the commit in which it was removed looking at this PR

(and past experiences tell me that dead code starts smelling after a while and ends up being removed anyway)

That said, if other people want to keep it I won't make a fuss about it.

edit: unless there's a plan already of dealing with this in the near future, but from your msg I understand this is something that won't be deal with any time soon

[niclaurenti]

I'm in favor of the removal since if/when someone wants to deal with the problem either this would be the smallest part of the job (and they will have to recheck that everything is correct anyway) or (if it is you or someone already involved in the project) would be able to find the commit in which it was removed looking at this PR

(and past experiences tell me that dead code starts smelling after a while and ends up being removed anyway)

That said, if other people want to keep it I won't make a fuss about it.

edit: unless there's a plan already of dealing with this in the near future, but from your msg I understand this is something that won't be deal with any time soon

ok then I'll remove it

[scarlehoff]

Are you running the qed fits already with this branch? (if so I guess everything works so feel free to merge)

[niclaurenti]

Are you running the qed fits already with this branch? (if so I guess everything works so feel free to merge)

Yes. Then as soon as the tests pass I will merge