Implement QED exact solution

[niclaurenti]

• if math.isnan(couplings.alphaem.scale) then deactivate the $\alpha$ running
  • to be traded for the current alphaem_running flag

[codecov]

Codecov Report

Merging #135 (55e80fe) into develop (3eda004) will decrease coverage by 1.35%.
The diff coverage is 93.00%.

❗ Current head 55e80fe differs from pull request most recent head bd11a38. Consider uploading reports for the commit bd11a38 to get more accurate results

@@             Coverage Diff             @@
##           develop     #135      +/-   ##
===========================================
- Coverage   100.00%   98.64%   -1.36%     
===========================================
  Files           78       81       +3     
  Lines         3725     4365     +640     
===========================================
+ Hits          3725     4306     +581     
- Misses           0       59      +59     

Flag	Coverage Δ
isobench	?
unittests	98.64% <93.00%> (-1.33%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/eko/scale_variations/exponentiated.py	100.00% <ø> (ø)
src/eko/couplings.py	84.08% <58.92%> (-15.92%)	⬇️
src/eko/evolution_operator/__init__.py	95.11% <90.16%> (-4.89%)	⬇️
src/eko/anomalous_dimensions/__init__.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/aem1.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/aem2.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/as1.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/as1aem1.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/as2.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/as3.py	100.00% <100.00%> (ø)
... and 13 more

[niclaurenti]

@felixhekhorn @alecandido Question about names: in the nonsinglet evolution for the pure QCD we had the terms j00, j01 etc where the j functions are the integrals of as^k/beta_N^iLO(as). In that case k starts from 1.
However in the QED case we have also the case k=0. Should we rename the already implemented j_ki by shifting by 1 the first index (i.e. j00 -> j10, j01 -> j11, etc) such that k=0 is the integral of 1/beta(as)? Or maybe we should find another name?

[felixhekhorn]

@niclaurenti since your touching solutions here and #137 was doing as well, maybe make sure by merging that your fine with the changes there ...
EDIT: actually I'm wrong: #137 only updated ads - so you should be fine ...

[felixhekhorn]

325 commits so far - I'm afraid I have to take some responsibility for that ...

[alecandido]

325 commits so far - I'm afraid I have to take some responsibility for that ...

Commits are not always a good measurement unit, in this case I believe the more relevant one is "days". Even though the two things are of course correlated (and the conversion in this case approaches 1).

Since this PR is never-ending, and we are being unable to merge, and even to review, we should reconsider a minimal goal and way to test.
Something like:

1. it should change existing tests as little as possible (new ones are more than welcome), and of course pass them
2. it should pass a few relevant benchmarks against APFEL
3. existing configurations should be unaffected; to be tested in practice by rerunning some EKOs with this branch and main, and test for a compatible (if possible bit-per-bit equal) result

If the present status passes all these checks, I'd rather merge even if it is not perfect, and incrementally improve and refactor, otherwise we'll keep some manpower stuck on this development, and pay over and over the cost of reviewing an extensive bunch of code...

[felixhekhorn]

1. it should change existing tests as little as possible (new ones are more than welcome), and of course pass them

2. it should pass a few relevant benchmarks against APFEL

3. existing configurations should be unaffected; to be tested in practice by rerunning some EKOs with this branch and main, and test for a compatible (if possible bit-per-bit equal) result

@niclaurenti if you confirm @alecandido's list- let's merge!

[niclaurenti]

1. it should change existing tests as little as possible (new ones are more than welcome), and of course pass them
2. it should pass a few relevant benchmarks against APFEL
3. existing configurations should be unaffected; to be tested in practice by rerunning some EKOs with this branch and main, and test for a compatible (if possible bit-per-bit equal) result

@niclaurenti if you confirm @alecandido's list- let's merge!

Yes they are not affected. But let me run some pure QCD benchmarks in order to be 100% sure