Change alpha_s evaluation point in K

[felixhekhorn]

After todays Milan meeting we're convinced that the scale variation kernel $K$ should be evaluated with $\alpha_s(Q^2)$, so with the strong coupling at the process scale. This should be mirrored in scheme C, where everything should be evaluated at the process scale (assuming always, of course, XIR=1).

@giacomomagni can you have a look on how this would impact the comparison between A and B? (so test_scale_variation_a_vs_b)

From a naive point of view I think #151 is still needed: the fact that I could match B and C together with this change is due to the fact that also C was suffering from the related bug. However, the two things are independent.

Tests are passing currently, i.e. they are not sensitive to this change (which is a problem - at least conceptually)

[alecandido]

Move from here, such that as_raw is not between as0 and as1:

• the first one corresponds to the point at which it has to be evaluated for the expanded part of the predictions (the "as value")
• the latter two are the boundaries of the running (so the "as function"), the way it is used for DGLAP solution (and it is there only because we are trading the fact scale dependency for an as dependency through the "as function", but it is not related in any way to the as used for the process)

[giacomomagni]

Okay LGTM. I think it's okay that the test is unchanged, since there we are just plugging two values of a_s no matter if now a1 is called as_raw and it is unrelated from the integral boundary condition. The expansions to derive the expanded solution are performed in the limit of L -> 0 and a_s -> a0 if I recall correctly

[alecandido]

@andreab1997 let's decide ourselves where do we want to put as_raw, and right after we'll merge.

[andreab1997]

This morning I was finally able to predict analitically the FKs for both scheme B and scheme C produced with this branch (and their difference of course). You can have a look here. However, as you can notice, I have also confirmed the minus sign issue that @felixhekhorn was suspecting from a long time: I was able to predict everything only changing the sign of the scale varied part. Of course at NLO that was enough but at NNLO most likely it won't. Therefore I would propose to keep this PR open and use it to find this minus sign problem. Do you agree? @felixhekhorn @alecandido

If you want some more details on the benchmarks just ask me :)

[alecandido]

I was finally able to predict analitically the FKs

Great, that is definitely good news.

Of course at NLO that was enough but at NNLO most likely it won't.

For the NNLO, we only have uncertainty on the minus sign source. If the guess is right, it might also work out of the box.

Therefore I would propose to keep this PR open and use it to find this minus sign problem. Do you agree?

Since this is a known and solved bug, I would close this PR here: we already fixed something, and there is no uncertainty on the $\alpha_s$ evaluation, at this point.
Also, making shorter and more focused PRs helps the review process. We should do more of these, especially when we are not implementing new features :)

[andreab1997]

For the NNLO, we only have uncertainty on the minus sign source. If the guess is right, it might also work out of the box.

Yes of course, I will try soon.

Since this is a known and solved bug, I would close this PR here: we already fixed something, and there is no uncertainty on the αs evaluation, at this point. Also, making shorter and more focused PRs helps the review process. We should do more of these, especially when we are not implementing new features :)

Ok fine :). For me this is fine to be merged even now.

[alecandido]

Thinking once more: maybe raw it is not the best name ever, since there is nothing that is "derived", and that is not the "original" one (we are probably using raw too much in general, but in this case I really don't see how it is describing the variable).
I may suggest as_process, or someone can propose an even more telling name (we know names to be a major pitfall...).

In any case, it is well documented, so it is a relevant detail, but still a detail :)

[andreab1997]

Thanks for this :)