N3LO msbar and alpha_s

[giacomomagni]

• Allow for N3LO msbar running and fix issue Call anomalous mass dimension \gamma_m #84.

• Allow for N3LO alpha_s evolution:

[felixhekhorn]

Tests will fail until N3LO alpha_s is not allowed.

I'd say maybe let's merge on top of #83 instead of develop and maybe even rebase on that

[giacomomagni]

Tests will fail until N3LO alpha_s is not allowed.

I'd say maybe let's merge on top of #83 instead of develop and maybe even rebase on that

I thought #83 was already big enough and better have small PR...
What if we add also N3LO alpha_s here? I have to add beta_3 in any case to complete this and we are missing only these expression:

• matching_coeffs_up (if available..., I checked the refs quickly but was not able to find them straight )
• the expanded solution at N3LO

[felixhekhorn]

I thought #83 was already big enough and better have small PR... What if we add also N3LO alpha_s here? I have to add beta_3 in any case to complete this and we are missing only these expression:

* [matching_coeffs_up](https://github.com/N3PDF/eko/blob/feature/N3LO_msbar/src/eko/strong_coupling.py#:~:text=def%20compute_matching_coeffs_up(mass_scheme)%3A) (if available..., I checked the refs quickly but was not able to find them straight )

* the expanded solution at N3LO

maybe that's a good idea (and it even makes the other PR smaller ...)

re: matching coeffs: maybe try to ask to Juan or simply search a bit more (following the authors e.g., Chetyrkin et al., if I remember corrrectly ...)

[codecov]

Codecov Report

Merging #85 (c8a52c1) into develop (175672d) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##           develop       #85   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           32        32           
  Lines         2375      2431   +56     
=========================================
+ Hits          2375      2431   +56     

Flag	Coverage Δ
unittests	100.00% <100.00%> (ø)

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

Impacted Files	Coverage Δ
src/eko/anomalous_dimensions/harmonics.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/lo.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/nlo.py	100.00% <100.00%> (ø)
src/eko/anomalous_dimensions/nnlo.py	100.00% <100.00%> (ø)
src/eko/beta.py	100.00% <100.00%> (ø)
src/eko/gamma.py	100.00% <100.00%> (ø)
src/eko/msbar_masses.py	100.00% <100.00%> (ø)
src/eko/runner.py	100.00% <100.00%> (ø)
src/eko/strong_coupling.py	100.00% <100.00%> (ø)

[giacomomagni]

Hi @felixhekhorn,
I found the values in this two references: Chetyrkin:1997sg (eq 6 for MSbar and eq 9 for pole, there is a factor of 4 (and 4^2 ...) ) and in Vogt:2004ns (eq 2.43).
Furthermore this values were also reported in apfel.
However while I was double checking the values I found that there might be some inconsistencies: what do you think?

I attach here my understanding of the situation:

matching_coeffs_up = np.zeros((4, 4))
    if mass_scheme == "MSBAR":
        matching_coeffs_up[2, 0] = -22.0 / 9.0
        
        # TODO: here apfel and Chetyrkin:1997sg (eq 6) do not agree...
        # Apfel has: matching_coeffs_up[2, 1] = 22.0 / 3.0 while the other report same coeff for pole and |MSbar|
        
        matching_coeffs_up[3, 0] = (
            (82043.0 / 27648.0) * zeta3 - 564731.0 / 124416.0 + 2633.0 / 31104.0 * nf
        ) * 4 ** 3
        matching_coeffs_up[3, 1] = 6793.0 / 27.0 - 281.0 / 27.0 * nf

    elif mass_scheme == "POLE":
        matching_coeffs_up[2, 0] = 14.0 / 3.0
      
        # TODO: this value is not in agreement between Chetyrkin:1997sg and  Vogt:2004ns
        # Chetyrkin:1997sg: matching_coeffs_up[3, 1] = 8512.0 / 27.0 - 409.0 / 27.0 * nf
        matching_coeffs_up[3, 1] = 8941.0 / 27.0 - 409.0 / 27.0 * nf
        # TODO: same here, the part prop to nf is in agreement the other no...
        matching_coeffs_up[3, 0] = 340.729 - 16.7981 * nf

    matching_coeffs_up[1, 1] = 4.0 / 3.0 * constants.TR
    matching_coeffs_up[2, 1] = 38.0 / 3.0
    matching_coeffs_up[2, 2] = 4.0 / 9.0
    matching_coeffs_up[3, 3] = 8.0 / 27.0

    # TODO: this value is not in agreement between Chetyrkin:1997sg and  Vogt:2004ns
    # Chetyrkin:1997sg: matching_coeffs_up[3, 2] = 131.0 / 9.0
    matching_coeffs_up[3, 2] = 511.0 / 9.0

Edit: solution, Chetyrkin:1997sg is writing the backward relation while, Vogt:2004ns the forward one, now the values are in agreement except for this:

# TODO: here apfel and Chetyrkin:1997sg (eq 6) do not agree...
# Apfel has: matching_coeffs_up[2, 1] = 22.0 / 3.0 while the other report same coeff for pole and |MSbar|

I believe it's better to follow the paper rather than Apfel.

Final solution:

• The most recent and we believe correct reference is: Schroder:2005hy see eq 3.1 for Msbar and App A for pole mass. Our values will agree with this reference. Note that in the papar is presented the backward matching
• Apfel is in agreement with the correct reference
• Pegasus pole coefficients are correct
• PDG suggest that up to NNLO the only difference between MSbar and pole mass is the coefficient c_20 pdg, eq 9.4, but this is not true, so this is not fully correct.
• Chetyrkin:1997sg eq 6 and 9 are not correct, as they contain typos for c21, c32, c31 both for pole and Msbar coefficients

[felixhekhorn]

• Please add a docstring here https://github.com/N3PDF/eko/blob/6139861c08e71e990f1aef0d849bab8f804701fe/src/eko/gamma.py#L13
  similar to this one
  https://github.com/N3PDF/eko/blob/6139861c08e71e990f1aef0d849bab8f804701fe/src/eko/beta.py#L15
• you can add numba to gamma

[felixhekhorn]

Actually, is it a version problem, because we need banana@develop?

[alecandido]

For sure we need develop at the moment, but I'll make soon another release (as soon as I'll have the time to implement a proper solution, instead of a temporary hack).

If we're not in a hurry to merge this, let's wait a second :)

[giacomomagni]

For sure we need develop at the moment, but I'll make soon another release (as soon as I'll have the time to implement a proper solution, instead of a temporary hack).

If we're not in a hurry to merge this, let's wait a second :)

Sure, no problem. Thanks for your review and inputs, @alecandido , @felixhekhorn

[giacomomagni]

Shall we merge ?

[alecandido]

If you're done, I'll re-review as soon as possible (worst case tomorrow morning during the PC) and we can merge :)

[felixhekhorn]

Actually, is it a version problem, because we need banana@develop?

For sure we need develop at the moment, but I'll make soon another release (as soon as I'll have the time to implement a proper solution, instead of a temporary hack).

If we're not in a hurry to merge this, let's wait a second :)

[alecandido]

As of NNPDF/banana@1e1b576 banana has been merged, we don't need develop any longer.

[felixhekhorn]

Can we then merge?

[alecandido]

I would revert src/eko/output.py (personally, I prefer to preserve original names, where possible).

I checked everything else, and I'm fine with it.

[giacomomagni]

I would revert src/eko/output.py (personally, I prefer to preserve original names, where possible).

I checked everything else, and I'm fine with it.

then we keep pylint complaining?

[alecandido]

I don't see it complaining on CodeFactor: if it were, it shoud be listed here https://www.codefactor.io/repository/github/n3pdf/eko/pull/fixed/85

Which version of pylint do you have? What is complaining about?

[giacomomagni]

I don't see it complaining on CodeFactor: if it were, it shoud be listed here https://www.codefactor.io/repository/github/n3pdf/eko/pull/fixed/85

Which version of pylint do you have? What is complaining about?

Indeed codeFactor is complaining about import. yaml:
third party import "import yaml" should be placed before "import lz4.frame
that's why I originally modified this. see here

[alecandido]

Okay, then the solution is not to change the name: we need to reconcile isort with pylint (otherwise this problem might come back over and over).

There are two possible ways of doing it:

• we select/define an isort profile that is compliant with pylint (but we already selected one that is compatible with black, and we change too much we have to maintain ourselves), i.e. configure isort
• we prevent pylint to complain, whatever isort does is fine: we're giving up on the check, but on the other hand we are all using isort, so we can also configure pylint and give up on the double check

[alecandido]

At the end of the day, they come from the same place pylint-dev/pylint#3817 (comment)

[giacomomagni]

At the end of the day, they come from the same place PyCQA/pylint#3817 (comment)

Yes I agree this is the origin of this issue, so may solution was just a workaround. I can revert it and we solve this on a later stage properly.

[felixhekhorn]

Yes I agree this is the origin of this issue, so may solution was just a workaround. I can revert it and we solve this on a later stage properly.

agreed - after that you can merge 👍