Per-mass GM-VFNS

[alecandido]

Plan

• define elements
• print preview
• add light components
• add heavy components
• update missing KernelGroup
  • missing has to accept one more parameter: which flavor(s) are coupling to the photon
• include intrinsic

Implementation

• provide all KernelGroup == Generator
• upgrade combiner
• review all generators

---

Info

• propagate info to xs and exs
• propagate info to Kernel and PartonicChannel

[alecandido]

I thought a bit about how to proceed (detect things and replace by sed, make intermediate steps, and so on), but at the end of the day the easiest was simply to break everything from the top level, and then propagate the new layout by fixing broken things.

With f929570 I started the operation of breaking, reshuffling stuffs from SF to the new class RunnerConfigs. Of course, it has to be propagated at the same level in XS, and down below (ESF -> Kernel -> PartonicChannel).

Worst case, we can just revert, but I'm pretty confident we can manage to solve in a reasonable amount of time (less than one day, hopefully less than half).

[alecandido]

In 5d58def I started introducing yadbox.

I don't want to push for its development, but I just thought it was a nice place to put helpers for runcards generation (in a way that is suitable to expose to the end user).

[alecandido]

RunnerConfigs have been propagated down to ESFInfo in 07a32df.

According to the new plan, we should further restrict the information available in KernelInfo and PCInfo.
Nevertheless, at this point yadism is back working, so we can do it incrementally.

[codecov]

Codecov Report

Merging #124 (20d9cc4) into develop (5e2913d) will decrease coverage by 8.71%.
The diff coverage is 23.58%.

❗ Current head 20d9cc4 differs from pull request most recent head edae7c0. Consider uploading reports for the commit edae7c0 to get more accurate results

@@             Coverage Diff             @@
##           develop     #124      +/-   ##
===========================================
- Coverage    76.16%   67.44%   -8.72%     
===========================================
  Files           81       81              
  Lines         3637     3671      +34     
===========================================
- Hits          2770     2476     -294     
- Misses         867     1195     +328     

Flag	Coverage Δ
unittests	67.44% <23.58%> (-8.72%)	⬇️

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

Impacted Files	Coverage Δ
src/yadism/coefficient_functions/fonll/kernels.py	11.76% <0.00%> (-45.59%)	⬇️
.../yadism/coefficient_functions/intrinsic/kernels.py	12.50% <0.00%> (-66.67%)	⬇️
src/yadism/coefficient_functions/kernels.py	15.00% <0.00%> (-33.34%)	⬇️
src/yadism/coefficient_functions/light/kernels.py	11.42% <0.00%> (-68.58%)	⬇️
src/yadism/xs.py	64.00% <0.00%> (ø)
src/yadism/coefficient_functions/__init__.py	16.96% <9.87%> (-46.78%)	⬇️
src/yadism/coefficient_functions/heavy/kernels.py	14.63% <20.00%> (-75.61%)	⬇️
src/yadism/sf.py	50.00% <20.00%> (-41.84%)	⬇️
src/yadism/runner.py	80.34% <42.30%> (-5.38%)	⬇️
src/yadism/esf/esf.py	30.76% <47.05%> (-64.95%)	⬇️
... and 17 more

[alecandido]

The plan is almost finished, to run it:

cd extras
python -m gmvfns

You can set the heavy flavors and the observable as options.

[alecandido]

[ ] provide all KernelGroup == Generator

I definitely want a Generator class for the Kernel collectors in the kernel.py modules.

Actually I would not care so much about an entire class, I want a type for the generator, to tell that I'm going to use a generator, and if someone wonders about what a generator is, it can look for the definition and documentation.
But since in python types do not exist, then I want a class.

We can still do it in two ways:

• we make a unique class, and we instantiate multiple times: this is the best one, but since the difference between the instances is actually the code they execute to collect kernels, we need to assign the generator functions as attributes to the instance
• otherwise we can keep going with subclassing as usual (I'm starting hating classes proliferation)

However, there is an elegant syntax we can use to implement the first way: we make a decorator.
At the end of the day a decorator is simply a function that eats a function, so what I'm suggesting is to make the higher order function to be a constructor.

class Generator:
    def __init__(self, collector):
        self.collector = collector
    def __call__(self,  nf, ihq, ...):
        self.collector(nf, ihq, ...)

@Generator
def generate_light_kernels(nf, ihq, ...):
    ...

[alecandido]

P.S.: we could think about reuse the pattern above to kill some exceeding classes even somewhere else...

[alecandido]

Planning completed, now I need a review, i.e. run the thing and check the output is correct, who cares about the code itself...

[felixhekhorn]

I think, I mostly agree, however there are two things:

• Fmiss(3f:b, /b, ~~1) - I don't understand what exactly the nomenclature is, but I think one of the two bs is redundant; or at least I couldn't generate a configuration with the two things different
• we should continue to provide the "heavy-light":

  $ python -mgmvfns   -o charm
  ┌───────────────────┐                                                            
  │ active flavors: 4 │                                                            
  └───────────────────┘                                                            
  Fcharm =
  

  this should be Flight(zm:1|c); otherwise we run immediately again into trouble for Hera, since most of the points are in the 5FS patch ... of course

  Flight = Flight(zm:4)
  Ftotal = Flight
  

  still holds

[felixhekhorn]

• maybe we should make a heavy-collector? because Fheavy does not correspond to the heavy pc package for FONLL
• and in the new structure we need to reflect somehow the fact that e.g. Fbottom can be three different things: Fheavy(4f:b), Fheavy(FO:b), Flight(zm:6, ~~b)
• by the way FO:b contains the implicit information that there are 4 light flavors - here 3f:b this is explicit

[alecandido]

• maybe we should make a heavy-collector? because Fheavy does not correspond to the heavy pc package for FONLL

The heavy collection is not the same, but still intertwined with total, that's why it is happening in the same place.
Even though we can factorize the common part and still write two functions (and then even three, with a separate one for light).

• and in the new structure we need to reflect somehow the fact that e.g. Fbottom can be three different things: Fheavy(4f:b), Fheavy(FO:b), Flight(zm:6, ~~b)

This only depends on the mass treatment and the patch, and it's already accounted for. Nothing else to do.

• by the way FO:b contains the implicit information that there are 4 light flavors - here 3f:b this is explicit

This is intended:

• you might have 3f:b and 4f:b
• but when FONLL is involved this is always active in that specific patch, so it determines by itself the number of light flavors

[alecandido]

@felixhekhorn: I tried to include intrinsic in the simulation, so as soon as you can please have a look if the printed simulation actually make sense

[alecandido]

At the moment actually I didn't solve the full intrinsic problem:

1. we have intrinsic up to NLO
2. by def, intrinsic has always an incoming quark

Singlet channel only appears in NNLO (so ruled out by 1), and gluon is of course not intrinsic (so ruled out by 2.).

Nevertheless, at some point we might have to deal with intrinsic NNLO, there you can have a couple more channels:

• intrinsic -> gluon -> heavy coupling (possibly a different flavor, is it a 2-mass effect?)
• intrinsic -> gluon -> light coupling

For the time being is already quite a mess without this further complication...

[alecandido]

It might be working (except intrinsic, for which I still need a review of the plan).

Can you @felixhekhorn please try to review with sandbox?

(At this point, I regret both missing APFEL benchmarks, and regression tests)

[alecandido]

Actually (surprisingly enough), IC+FONLL almost work as before, it only screws a bit more the smallest Q2 bins (~4%), that were already a bit screwed with the former implementation (~2%).

Nevertheless, IC+ FFNS is screwed all over the place, I'm currently checking if it's a compatibility problem, or it's genuinely the new algorithm to be bugged.

[alecandido]

Problem solved in abdab2f:

• mostly due to missing intrinsic contribution in FFNS
• partly even consisting in compatibility: the effect of bottom and top masses are only relevant in the new scheme, where we are adding all the missing contributions

In principle (assuming we choose compatible setups) the new implementation produce the exact same numbers of the old one.

Still to be tested deeper and by someone else than me, I'm rather biased

[felixhekhorn]

On a first quick glance looks alright! I want to test it more extensively on Thursday though ...