Scale Variations Expanded

[giacomomagni]

• Move scale variation to a subpackage
• implementation of scheme B (ModSV=expanded)
• Generalise quad ker
• Generalise Operator class (try parallel integration)
• Benchmark: Pegasus/Lha ModSV=exponentiated
• Benchmark: Apfel ModSV=exponentiated. Bug found and fixed.

[codecov]

Codecov Report

Merging #91 (1456443) into develop (3b843e3) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           develop       #91    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           32        35     +3     
  Lines         2429      2556   +127     
==========================================
+ Hits          2429      2556   +127     

Flag	Coverage Δ
isobench	54.94% <63.40%> (-12.07%)	⬇️
unittests	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/eko/matching_conditions/__init__.py	100.00% <ø> (ø)
src/eko/evolution_operator/__init__.py	100.00% <100.00%> (ø)
src/eko/evolution_operator/grid.py	100.00% <100.00%> (ø)
src/eko/interpolation.py	100.00% <100.00%> (ø)
src/eko/kernels/singlet.py	100.00% <100.00%> (ø)
...eko/matching_conditions/operator_matrix_element.py	100.00% <100.00%> (ø)
src/eko/mellin.py	100.00% <100.00%> (ø)
src/eko/msbar_masses.py	100.00% <100.00%> (ø)
src/eko/scale_variations/__init__.py	100.00% <100.00%> (ø)
src/eko/scale_variations/expanded.py	100.00% <100.00%> (ø)
... and 3 more

[alecandido]

Hi @giacomomagni, I like a lot the way you're structuring it :D

About modules naming: since it's not ambiguous inside scale_variations subpackage, I'd call scheme_A.py just a.py, keeping the docstring inside the module telling that is scheme A implementation. It would look like

import scale_variations.a

that is not that bad.

On the other hand, it is always true that explicit is better than implicit, so if you don't like you can also keep scheme_a, but at least make it lowercase to respect conventions :)

P.S.: same thing goes for B, of course

[giacomomagni]

Hi @giacomomagni, I like a lot the way you're structuring it :D

About modules naming: since it's not ambiguous inside scale_variations subpackage, I'd call scheme_A.py just a.py, keeping the docstring inside the module telling that is scheme A implementation. It would look like

import scale_variations.a

that is not that bad.

On the other hand, it is always true that explicit is better than implicit, so if you don't like you can also keep scheme_a, but at least make it lowercase to respect conventions :)

P.S.: same thing goes for B, of course

I agree, I like the first option as well!

[felixhekhorn]

let's stick to our default choice, that is we speak in Q2 and not Q (you can do Q2=7**2 ...) - and actually why don't you go for math: - we speak about math here ...

[giacomomagni]

I thought it was more clear to follow the same syntax we use in the code since we are referring directly to our implementation. I have fixed the squared, which were not consistent.

[alecandido]

I completed my review, there are only minor fixes requested, mainly in the docs.

[alecandido]

There is still the open question about benchmark_APFEL_msbar_solution, but all in all I should not block because of this (it's nice to perfectly understand everything exactly when you're doing it, but in this case it's not really a priority).

Let's merge 🚀