Numerical FONLL

[andreab1997]

FONLL prescription can also be applied at observable level, i.e. computing structure functions with PDFs with different number of active flavors and then subtracting them. Meaning of this PR is to implement this kind of prescription which is very convenient and clearer than the coefficient function level implementation.

@alecandido @felixhekhorn @giacomomagni @niclaurenti Please add whatever step and/or suggestion to this (very sketchy) checklist.

• compute asymptotic structure functions, for any given number of flavors
• Implement numerical fonll, i.e. allow the computation of two different grids for the same dataset with the correct ingredients.
• Benchmark it with current implementation.
• Start the necessary PRs in pineko and eko
• Remove current implementation.

[alecandido]

If possible, try to do it as we discussed last wiki: generate grids with master, and benchmark against them, such that the two implementations do not have to live side-by-side.

[andreab1997]

If possible, try to do it as we discussed last wiki: generate grids with master, and benchmark against them, such that the two implementations do not have to live side-by-side.

Yes, this is just because I wanted to open the PR. However I am still confused: why is avoiding that the two implementations live side-by-side (even only for the time being) so important? What I would (naively) do is implementing a flag for the moment and then, after having benchmarked everything, removing it and also removing the old implementation. Why is this a problem?

[alecandido]

The organization of yadism is:

coeff_func
  heavyness
    obs_process
      Component

So, to implement another FONLL setup, you'd actually need fonll2 heavyness or another bunch of Components, that in FONLL are already too many.

Furthermore:

• you need to reintroduce expressions for any, stripping the matching conditions
• you need to add the new asy observables (before unaccessible)
• you need to avoid collecting multiple ingredients
• and instead compute many observables

And I believe the list will grow even a bit more. So, there is not a single clean place where to add "just a flag", but you should just propagate the flag in a lot of places, and branch everywhere.

We want to simplify the code, not to make it more complex. It's already complex enough.
And we've alternatives for benchmarking, so it's not really a good motivation.

Let's not pay twice the price of the transition, and try to aim directly for the final product (otherwise we'll need another clean-up session later on, and who's going to do it? when? and why, since at that point we'll already have a messy code, that works, and people will put pressure to do more physics, not just to clean up the code)

[felixhekhorn]

I guess we can close this in favor of #195 ? cc @RoyStegeman

[RoyStegeman]

Closed in favour of #195

The changes in the branch connected to this PR are empty, and the discussion can continue in #195.