Enable nf=3 with evolven3fit_new.

[scarlehoff]

This PR enables the possibility of running evolven3fit_new with a fit in nf=3.

In order to make it more general now the operator receives a card where every time there is a threshold the Q_threshold is passed for both nf and nf+1 in order to avoid the hack of simply repeating one value.

The problem at the bottom threshold still remains.

Testing a fit evolved with apfel and eko for theory 200/400, they agree with a relative precision of 1e-3 for all points in x and for Q != mb (for nf=5 the agreement is a bit worse when you are close to mb).
I've done the same test for theory 211 (perturbative charm, fit done in nf=3), there we again have a problem at the bottom threshold but as far as I can see the same problem doesn't appear at the charm threshold not sure why.

-> The problem at Q=mb for nf=5 is being investigated. Might be connected to this issue: NNPDF/eko#173

-> The problem at Q=mb for nf=4 is due to eko which at the moment returns an object after evolution which is pdf(q), and pdf(q, nf=4) get's overwritten by pdf(q, nf=5). (same thing happens at nf=3 in theory).

This is still a draft because I would like to:

• Organize better the Q-grids in a separate file.
• Decide whether to set to 0.0 from n3fit the exportgrid for nf > nf0.

[scarlehoff]

This is ready for review. Some notes:

1. The agreement between an apfel and eko evolved PDF is mostly at the level of a relative difference of 1e-3 but for some points it can go up to 1e-1 (specially at lower values of x)
2. There is no agreement at the quark thresholds, at both sides of the threshold. This seems to be a genuine difference Check predictions near threshold eko#173
3. At every threshold we have two instances of the threshold Q: (Q, nf-1) and (Q, nf). At the moment eko cannot deal (at evolution time) with two values of nf for the same Q so I've added a -epsilon for nf-1.

Organize better the Q-grids in a separate file.

I think they actually fit well in the utils.py module which has only those grids and functions around them. So I've added the one for nf=3 there.

Decide whether to set to 0.0 from n3fit the exportgrid for nf > nf0.

Right now there is no nf0 in the theory and would need to be derived. So I'll pospone this decision to #1756

[scarlehoff]

At every threshold we have two instances of the threshold Q: (Q, nf-1) and (Q, nf). At the moment eko cannot deal (at evolution time) with two values of nf for the same Q so I've added a -epsilon for nf-1.

@giacomomagni @andreab1997 @niclaurenti once this PR is merged it will be necessary to recompute previous eko due to the -epsilon. So whether to merge this change or not depends on whether you rather prefer to keep the same eko (but have at nf-1 the result of nf). And this depends on whether you believe eko is giving the right results around the thresholds (@felixhekhorn @alecandido) because if it isn't then it doesn't matter (that much) how wrong they are.

Alternatively, this can be fixed in the eko side, do a new release and then previous ekos should even work (since the value for (Q, nf-1) is included in the operator, the bug is only for the evolution.

[scarlehoff]

I've opened an issue in eko NNPDF/eko#283

I will remove the hack of - epsilon since the current bug is just a "reimplementation" of the old behaviour, and that -epsilon forces a recomputation of the eko.

[scarlehoff]

I've reverted the hack. Please @andreab1997 have a look at this when you have time, as far as I am concerned this can be merged.

[andreab1997]

Just a few comments but it looks good to me

[giacomomagni]

I understand this work, so in principle is fine.
When you call generate_q2grid with both Q2s given nf0 is ignored. On contrary by default from the cli here we have Q2s to None so you actually want to use nf0, it's just a bit confusing, but I don't see a quick fix as well

[scarlehoff]

Yes, the nf0 is acting a bit like a secret parameter to generate the q2grid from the defaults.
I guess another option is not to call generate_q2grid when there is nothing to generate (just a default being used).

[giacomomagni]

maybe that's more clean.

[alecandido]

Just to point out: nf0 parameter is going to disappear, or better to move. Now that we are propagating evolution points from EKO, everything should be an evolution point (a point on a lane, rather than on the ladder), and also fitting scale will be an evolution point.

So nf0 should be always used, and never None (despite being always 4, at least for the time being - but remember that is 3 for perturbative charm). You should be allowed to discard the nf information only at the latest possible time (i.e. when generating the LHAPDF grid file).

nf0 is an EKO extension to the NNPDF theory database, and inferred from the comparison of Q0 with mc * kcThr, but it would be better to always have it explicit, and infer as little as possible.

[scarlehoff]

@niclaurenti @andreab1997 check that this version is compatible with QED also for 0.13.5 and if so please feel free to merge, there's still the nf-qgrid reorganization open but I won't be back until late next week and I think having all these fixes in master would be best.

[niclaurenti]

@scarlehoff did you apply the changes I was doing in #1758?