Fix LHA VFNS SV benchmark

[felixhekhorn]

Closes #215

The fix here mirrors the original behaviour in

eko/src/eko/couplings.py

Lines 445 to 453 in d32b95a

	# adjust factorization scale / renormalization scale
	fact_to_ren = theory_card["fact_to_ren_scale_ratio"]
	heavy_flavors = "cbt"
	if masses is None:
	masses = np.power(
	[theory_card[f"m{q}"] / fact_to_ren for q in heavy_flavors], 2
	)
	else:
	masses = masses / fact_to_ren**2

I wonder whether we need to guard this division by scheme A ...

[alecandido]

This is changing everything, and in particular also the MHOU computed by @andreab1997

In principle, if it was a bug is a good thing. But why do you believe this should be so general?
I'm not sure why, if I change the factorization scale, the quark masses values should change in the $\alpha_s$ running...

[andreab1997]

Yes this is really strange. Moreover you are rescaling them by xif squared but the masses seem to be linear. If this fixes the benchmark, it suggestes a bug somewhere else...

[giacomomagni]

I think masses are squared as well

[felixhekhorn]

Indeed they are:

eko/src/eko/runner/legacy.py

Line 75 in 4f9920f

masses = [mq.value**2 for mq in new_theory.quark_masses]

[felixhekhorn]

Note that this has indeed no impact in FFNS, as masses are there either 0 or $\infty$, and thus is not discussed by our scheme B check

[giacomomagni]

This is also consistent with what we have in benchmarks:

eko/benchmarks/eko/benchmark_strong_coupling.py

Line 443 in 4f9920f

masses=(threshold_list / fact_to_ren_lin**2).tolist(),

the other place where Couplings is called is in msbar_masses.py , but since SV with \bar{MS} masses are not supported, that should be it.

[andreab1997]

Discussing with @felixhekhorn we convinced ourselves that whatever we do for alpha_s in scheme A we should do exactly the same in scheme B. In fact, there is no reason to do different things for the two schemes in that they are doing basically the same evolution (the only difference being that scheme A is using the varied splitting functions and scheme B is not). Note that (according to @felixhekhorn ) in eko==0.10 all the masses were shifted in this way, including also scheme B. In particular, in scheme B we have as1 that is used (correctly) for both the evolution and the "additional sv term" and we actually need to compute it rescaling the masses (as we were doing before). So, according to us, scheme B in eko==0.12 is now bugged. Do you agree?

[andreab1997]

Of course we still need to understand why we should rescale the masses but this is not something new. My current hypothesis is that, since the masses always enter as ratio like m^2 / mu^2, dividing m^2 / xif ^2 is actually equivalent to multiply mu^2 * xif^2 = mu_f ^2 which in fact is the factorization scale.

[giacomomagni]

Yes I agree on both counts

[giacomomagni]

@felixhekhorn, should we remove all the fact_to_ren_ratio still around before merging this?

[alecandido]

If this is recognized as a clear bug, we can merge this as a bug fix also without a clear reason, but consistently for any scheme (and if possible removing all fac_to_ren and related).

However, in case open a further dedicated issue, please. Identifying the reason is extremely relevant to be sure we are acting correctly and consistently.

[andreab1997]

If this is recognized as a clear bug, we can merge this as a bug fix also without a clear reason, but consistently for any scheme (and if possible removing all fac_to_ren and related).

However, in case open a further dedicated issue, please. Identifying the reason is extremely relevant to be sure we are acting correctly and consistently.

About this, @felixhekhorn Have you tried running the test rescaling the scales (so multiplying them by xif^2) instead of rescaling the masses? If the results turn out to be the same (or still compatible with the benchmark) I would say that what I said in the previous comment is correct and it is a resonable fix (and we should propagate immediately to scheme B).

[felixhekhorn]

Close in favor of #222