Skip to content

Fix LHA VFNS SV benchmark #218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
felixhekhorn wants to merge 1 commit into from
Closed

Fix LHA VFNS SV benchmark #218

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion benchmarks/lha_paper_bench.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -246,8 +246,9 @@ def run_lha(self, theory_updates):

if __name__ == "__main__":
# Benchmark to LHA
obj = BenchmarkFFNS_polarized()
# obj = BenchmarkFFNS_polarized()
# obj = BenchmarkFFNS()
obj = BenchmarkVFNS()
# obj.benchmark_plain(1)
obj.benchmark_sv(1)

Expand Down
2 changes: 1 addition & 1 deletion src/eko/runner/legacy.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,7 @@ def __init__(
couplings=new_theory.couplings,
order=new_theory.order,
method=couplings_mod_ev(new_operator.configs.evolution_method),
masses=masses,
masses=np.array(masses) / new_theory.xif**2,
Copy link
Copy Markdown
Collaborator

@alecandido alecandido Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Copy Markdown
Collaborator

@andreab1997 andreab1997 Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Copy Markdown
Collaborator

@giacomomagni giacomomagni Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think masses are squared as well

Copy link
Copy Markdown
Collaborator Author

@felixhekhorn felixhekhorn Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed they are:

eko/src/eko/runner/legacy.py

Line 75 in 4f9920f

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

Copy link
Copy Markdown
Collaborator Author

@felixhekhorn felixhekhorn Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

@giacomomagni giacomomagni Feb 24, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@andreab1997 andreab1997 Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Collaborator

@andreab1997 andreab1997 Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@giacomomagni giacomomagni Feb 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree on both counts

hqm_scheme=new_theory.quark_masses_scheme,
thresholds_ratios=thresholds_ratios,
)
Expand Down