Is matching_order correctly determined?

[felixhekhorn]

Actually here I think we have introduced a bug.
matching_order follows PTO (ie is 2 for NNLO) so here we should subtract one, once doing the default, no?

Originally posted by @giacomomagni in #299 (comment)

[felixhekhorn]

hmm? to me it seems the LHA benchmarks have passed, which should test the default - and also the N3LO benchmarks seemed alright, which should test the overwriting ... or do you mean we can no longer access the N3LO matching?

[niclaurenti]

Hi @giacomomagni and @felixhekhorn , but looking at

eko/src/eko/evolution_operator/operator_matrix_element.py

Line 66 in 10f0733

if matching_order[0] >= 2:

matching_order must be 2 at NNLO:
It should be $\delta_{ij}$ at LO, $a_s A^{(1)}$ at NLO and $a_s^2 A^{(2)}$ at NNLO.

[giacomomagni]

Indeed, we matching_oder should have a shift wrt to order.
@felixhekhorn I think this bug affects only the "new runcards", while in the LH benchmarks run through the old format no ?

[felixhekhorn]

Okay, so you are worried about this line specifically:

eko/src/eko/runner/parts.py

Line 93 in 10f0733

else tcard.order,

then maybe I agree with you, there is a bug - do you agree as well @niclaurenti ? When fixing this, we should provide also a unit test

[niclaurenti]

Ok @giacomomagni you are right. Sorry for doubting.
Previously I did a test with the "old runcards" (via apfel_bench.py) and it was ok.
Now I did another one with the new ones and in build_ome we have matching_order=(3,0) at NNLO.

The point in which it must be changed is:

https://github.com/NNPDF/eko/blob/10f0733635c012ce7e1f0fd4cdfc497619292830/src/eko/evolution_operator/operator_matrix_element.py#L167C17-L167C17

[giacomomagni]

Ok @giacomomagni you are right. Sorry for doubting. Previously I did a test with the "old runcards" (via apfel_bench.py) and it was ok. Now I did another one with the new ones and in build_ome we have matching_order=(3,0) at NNLO.

The point in which it must be changed is:

https://github.com/NNPDF/eko/blob/10f0733635c012ce7e1f0fd4cdfc497619292830/src/eko/evolution_operator/operator_matrix_element.py#L167C17-L167C17

mmm wait, now I disagree. We should just adjust the lines modified in that PR.
In particular:

https://github.com/NNPDF/eko/blob/10f0733635c012ce7e1f0fd4cdfc497619292830/src/eko/runner/parts.py#L92C1-L93

[felixhekhorn]

The point in which it must be changed is:

https://github.com/NNPDF/eko/blob/10f0733635c012ce7e1f0fd4cdfc497619292830/src/eko/evolution_operator/operator_matrix_element.py#L167C17-L167C17

I agree with @giacomomagni:

1. we need to change there
2. on top we should drop

   eko/src/eko/runner/legacy.py

   Lines 81 to 82 in 10f0733

   	if new_theory.matching_order is not None
   	else new_theory.order,

   because after

   eko/src/eko/runner/legacy.py

   Line 46 in 10f0733

   new_theory, new_operator = runcards.update(theory_card, operators_card)

   new_theory has matching_order https://github.com/NNPDF/eko/blob/10f0733635c012ce7e1f0fd4cdfc497619292830/src/eko/io/runcards.py#L216C14-L216C28 (this is the reason why "old style" was working)

[niclaurenti]

Yes I agree, I've read Felix's comment after posting mine