Add minus to expanded

[felixhekhorn]

• this breaks explicitly test_scale_variation_a_vs_b
• I'm quite convinced of "a" minus at NLO due to the investigations in https://github.com/NNPDF/pineko/blob/feature/bugfix-sv/debug3.py
• I'm not sure on where to put it, but the constraint is to not break the Les Houches benchmarks
• hopefully the conclusion will become clear with the ongoing investigations in the file mentioned above
• my current guess keeps the internal structure (so the relation L to L**2) untouched

[alecandido]

• this breaks explicitly test_scale_variation_a_vs_b

But, the way it is broken, it is unrecoverable:

E                x: array([[ 0.022168+0.j, -0.006421+0.j],
E                      [-0.000623+0.j,  0.057012+0.j]])
E                y: array([[-0.127935+0.j,  0.00936 +0.j],
E                      [ 0.003328+0.j, -0.30069 +0.j]])

I would say, if this was one of your possible options @felixhekhorn (but not the only one), now it should be excluded, and keep trying with the next one.

[giacomomagni]

Hi @felixhekhorn, if this is the solution then you have to flip also the sign in non_singlet_variation, then at NLO you can recover the test but now the difference between the schemes will be:

 g[0] * k * a0 - 2 * a1 * k * g[0]

I can try to recompute also the difference at NNLO (and N3LO maybe ).

Are you sure that the minus is present at all orders? I mean in the end this minus is coming from L -> - L or other reasons?

[felixhekhorn]

But, the way it is broken, it is unrecoverable

indeed - the only way to recover the test is by changing directly the test (as @giacomomagni proposed - although I didn't check the math explicitly)

if this is the solution then you have to flip also the sign in non_singlet_variation

yes, you're right - done in bda69f3

keep trying with the next one

Just to list the other possibilities I considered:

• changing the explicit sign in variation_as1

  eko/src/eko/scale_variations/expanded.py

  Line 32 in 2f2755c

  return -L * gamma[0]

  and flip all sign of L at odd powers inside the related functions. This breaks the current relation between L and L**2 (as said above) and that's why I don't like this option. I trust @giacomomagni was at least consistent with himself when typing the expression ;-) . This would also break the test.
• changing the global sign when calling the integrand

  eko/src/eko/evolution_operator/__init__.py

  Line 374 in 2f2755c

  L=np.log(self.fact_to_ren),

  this will break however the LHA benchmark (exponentiated), unless I do a further change in how the reference data is loaded

  eko/src/ekomark/benchmark/external/LHA_utils.py

  Lines 151 to 156 in 2f2755c

  	if fact_to_ren > np.sqrt(2):
  	part = 3
  	elif fact_to_ren < np.sqrt(1.0 / 2.0):
  	part = 2
  	else:
  	part = 1

  . I think this option would not break the test as it is a global redefinition, but I would exclude it since the heading in the paper and this definition seem to be consistent (i.e. what the paper calls $\mu_f^2/\mu_r^2$ is fact_to_ren).
• the only remaining option is the one I propose here - do you agree?

[alecandido]

@felixhekhorn if you change the sign in the test, does it pass?

If yes, we should start wondering if it is the correct one or not. If there is no way to make test passing (even with a large tolerance), then it is not an option.

[giacomomagni]

Thanks for the detailed explanation. The explanation of this could be due to a different convention on gamma signs in the expanded ref, right?

[felixhekhorn]

Hi @felixhekhorn, if this is the solution then you have to flip also the sign in non_singlet_variation, then at NLO you can recover the test but now the difference between the schemes will be:

 g[0] * k * a0 - 2 * a1 * k * g[0]

@giacomomagni this fix does indeed restore the NLO test!

I can try to recompute also the difference at NNLO (and N3LO maybe ).

if you can, please

Are you sure that the minus is present at all orders? I mean in the end this minus is coming from L -> - L or other reasons?

while the minus at NLO has now been found independently by @andreab1997 (see NNPDF/pineko#29) the origin remains unclear ... @andreab1997 is currently trying to extend the check to NNLO and so we maybe have a clearer indication (as this involves also non-linear terms)

[giacomomagni]

while the minus at NLO has now been found independently by @andreab1997 (see NNPDF/pineko#29) the origin remains unclear ... @andreab1997 is currently trying to extend the check to NNLO and so we maybe have a clearer indication (as this involves also non-linear terms)

In order to restore the test (and actually do the proper fix of the NNLO expanded) we need to know the origin of the minus sign. either there is a global sign as it is now either the sign comes from the different convention on gamma (so we have to flip only odd powers). Do you all agree on the current fix or shall we try the second case?

[andreab1997]

while the minus at NLO has now been found independently by @andreab1997 (see NNPDF/pineko#29) the origin remains unclear ... @andreab1997 is currently trying to extend the check to NNLO and so we maybe have a clearer indication (as this involves also non-linear terms)

In order to restore the test (and actually do the proper fix of the NNLO expanded) we need to know the origin of the minus sign. either there is a global sign as it is now either the sign comes from the different convention on gamma (so we have to flip only odd powers). Do you all agree on the current fix or shall we try the second case?

I am trying now to understand the source of this minus sign looking to NNLO. Just to be sure (and in order to try the same), the current fix is basically just flipping the sign of every K function?

[andreab1997]

So I tested a bit of possible solutions. Namely:

1. Global minus sign in the kernel K (the current solution)
2. Minus sign in the gamma definition
3. Minus sign in the definition of the logarithm L
4. Same of 1 but with also a minus sign in the beta_0

All of them fix the NLO so in principle they all can be the correct solution. However, solutions 2 and 3 lead to up to 1000% difference with scheme C at NNLO which is clearly wrong. Instead, solutions 1 and 4 lead to ~20% difference for the gluon channel and ~1% difference for the quark channel (btw solution 4 is slightly better). These differences I am still not able to fully predict because, as you know, I need first to implement a couple of splitting functions inside yadism (namely pgg^1 and pgq^1). However, using the previous order version of them (just to have something that may be of the same order of magnitude) I can get a predicted difference of the same order of magnitude of the "measured" difference. I believe then one between 1 and 4 to be the correct solution but I will be sure after implementing the correct splitting functions and after being able of fully predicting the difference. @felixhekhorn @alecandido @giacomomagni

[andreab1997]

So I tested a bit of possible solutions. Namely:

1. Global minus sign in the kernel K (the current solution)
2. Minus sign in the gamma definition
3. Minus sign in the definition of the logarithm L
4. Same of 1 but with also a minus sign in the beta_0

All of them fix the NLO so in principle they all can be the correct solution. However, solutions 2 and 3 lead to up to 1000% difference with scheme C at NNLO which is clearly wrong. Instead, solutions 1 and 4 lead to ~20% difference for the gluon channel and ~1% difference for the quark channel (btw solution 4 is slightly better). These differences I am still not able to fully predict because, as you know, I need first to implement a couple of splitting functions inside yadism (namely pgg^1 and pgq^1). However, using the previous order version of them (just to have something that may be of the same order of magnitude) I can get a predicted difference of the same order of magnitude of the "measured" difference. I believe then one between 1 and 4 to be the correct solution but I will be sure after implementing the correct splitting functions and after being able of fully predicting the difference. @felixhekhorn @alecandido @giacomomagni

You can reproduce all the tests using the branch feature/bugfix-sv (#151). However you will miss the actual fktables and the pdfs. The latter you can generate easily with banana starting either from NNPDF40_nlo_as_01180 or NNPDF40_nnlo_as_01180. The former you can generate as well but if you want I can just send them to you.

[andreab1997]

Can I close this? (since I am doing everything again in #191)

[felixhekhorn]

Consider to cherry-pick fd85f32 - apart from that, agreed

[alecandido]

Can I close this? (since I am doing everything again in #191)

The part touched here should not have major changes, so you can even attempt a rebase on develop. If you find conflicts, or you don't want even to try (since you believe you take less doing it manually), feel free to close this PR and open a new one.

EDIT: sorry, too fast: since you already opened the other one, yes, you can close this