Automatise numerical FONLL

[giacomomagni]

In this PR we try to automatise the procedure to generate numerical FONLL fk tables.

• We introduce 2 additional commands that will do the job, reusing the ekos where possible Reuse ekos for nFONLL #130.
• We add a documentation how to run numerical fonll.
• Fix FONLL-B bug.
• Test and review.
• Expand documentation

[andreab1997]

Hi @giacomomagni, thanks for this. Are you planning to solve here the issue of FONLL-B? Otherwise I can do it myself.
Also, should I review this now or is it better to wait?

[giacomomagni]

Hi @giacomomagni, thanks for this. Are you planning to solve here the issue of FONLL-B?

If you can solve it, I guess it's faster.
If you can solve it here, so much the better.
Keep in mind that this PR might take a bit longer (as we need to write docs),
so if it's just a commit better do it on master.

Also, should I review this now or is it better to wait?

Yes, it works right now. The new commands are:

pineko fonll_ekos -c config.toml 800 INTEGXT3 INTEGXT8
pineko fonll_fks -c config.toml 800 INTEGXT3 INTEGXT8

Although multiple datasets are supported the ekos are running sequentially,
so it might be faster to call the command twice instead than appending datasets in fonll_ekos.
But this is up to the user.

[andreab1997]

Hi @giacomomagni, thanks for this. Are you planning to solve here the issue of FONLL-B?

If you can solve it, I guess it's faster. If you can solve it here, so much the better. Keep in mind that this PR might take a bit longer (as we need to write docs), so if it's just a commit better do it on master.

Also, should I review this now or is it better to wait?

Yes, it works right now. The new commands are:

pineko fonll_ekos -c config.toml 800 INTEGXT3 INTEGXT8
pineko fonll_fks -c config.toml 800 INTEGXT3 INTEGXT8

Although multiple datasets are supported the ekos are running sequentially, so it might be faster to call the command twice instead than appending datasets in fonll_ekos. But this is up to the user.

Ok then let me take care of the PTO part and then I will review your part, after also the docs have been added.

[andreab1997]

It seems generally good to me. Just a question: have you tried to compute one fktable in both the ways and check if the results are the same we have?

Anyway I am now going to fix the PTO problem.

[andreab1997]

Please @giacomomagni when you can have a look at 28b8fe8 and maybe try to compute an fktable to see that we get the correct result.

Note that in 28b8fe8 I was forced to add an entry to the tcard (PTOEKO) because otherwise there is no way to distinguish between, say, the 00 contribution of FONLL-B and of FONLL-C as their theory cards are exactly the same.

[giacomomagni]

Please @giacomomagni when you can have a look at 28b8fe8 and maybe try to compute an fktable to see that we get the correct result.

I checked that the automatized FONLL reproduces an older FKTable.

Note that in 28b8fe8 I was forced to add an entry to the tcard (PTOEKO) because otherwise there is no way to distinguish between, say, the 00 contribution of FONLL-B and of FONLL-C as their theory cards are exactly the same.

Regarding your fix, the only way to avoid this additional key would be to act at the level of the opcard creation, but it's a bit more convoluted, as you need to detect the FONLL-B/D and the correct scheme to switch, so as you prefer...

[andreab1997]

Please @giacomomagni when you can have a look at 28b8fe8 and maybe try to compute an fktable to see that we get the correct result.

I checked that the automatized FONLL reproduces an older FKTable.

Ok good!

Note that in 28b8fe8 I was forced to add an entry to the tcard (PTOEKO) because otherwise there is no way to distinguish between, say, the 00 contribution of FONLL-B and of FONLL-C as their theory cards are exactly the same.

Regarding your fix, the only way to avoid this additional key would be to act at the level of the opcard creation, but it's a bit more convoluted, as you need to detect the FONLL-B/D and the correct scheme to switch, so as you prefer...

How do you mean? Also, I am not sure why you are talking about the opcard that should be unchanged, right?

[giacomomagni]

How do you mean? Also, I am not sure why you are talking about the opcard that should be unchanged, right?

Not really, if I understand correctly, right now you are consuming PTOEKO exactly when computing the eko...
So this operation can be done when writing the opcard.

[andreab1997]

How do you mean? Also, I am not sure why you are talking about the opcard that should be unchanged, right?

Not really, if I understand correctly, right now you are consuming PTOEKO exactly when computing the eko... So this operation can be done when writing the opcard.

But I don't understand what you would put in the opcard exactly

[giacomomagni]

But I don't understand what you would put in the opcard exactly

Yes that would not be much cleaner than this, never mind.

[andreab1997]

Can someone review this? I can review @giacomomagni's part but it does not make sense reviewing my own part. @felixhekhorn @RoyStegeman

[felixhekhorn]

yes, sorry - I promised to take a look, but haven't had the time so far 🙈 I'll try again tomorrow

[RoyStegeman]

Some comments on the docs only.

I think we should add docs under THEORY as well. To introduce the FONLL scheme

[RoyStegeman]

Hmm this is a bit ugly. I understand wanting to keep things modular, but I think we should really have a step-by-step guide somewhere that explains how to use pinefarm/yadism together with pineko to create nFONLL FKtables. We will put it in the paper, but it would also be good to have it in a living document, i.e. docs, somewhere.

[giacomomagni]

True, but this is why I wanted a single place where you can run everything...
As far as pineko is concerned we can add a link to pinefarm of pineline (although the page would be non existing yet.)

[giacomomagni]

I think we should add docs under THEORY as well. To introduce the FONLL scheme

Regarding this, we have some docs in Yadism:

https://yadism.readthedocs.io/en/latest/theory/fns.html#fonll

if you prefer we can move it/ copy /link it here ...

[RoyStegeman]

I was indeed aware of the docs in yadism. I would say the should be moved here since yadism no longer does FONLL. However, since FONLL is precisely the motivation for having FFN0, it may be nice to then link in yadism to these pineko docs when the FONLL scheme is mentioned under FFN0.

P.S. if you go to the "files changed" tab you can batch the suggestions into a single commit.

[felixhekhorn]

I was indeed aware of the docs in yadism. I would say the should be moved here since yadism no longer does FONLL. However, since FONLL is precisely the motivation for having FFN0, it may be nice to then link in yadism to these pineko docs when the FONLL scheme is mentioned under FFN0.

I started to shuffle the docs around, but yes this needs more work. We need to move the whole yadism stuff here to explain what we are actually talking about; we need to massage it such that we talk about an abstract observable, which for illustrative purpose is a DIS structure function.

We also need some business about the 2 mass problem ...

[giacomomagni]

Since from 3365f2e we are breaking the old implementation, i think we can fix also #138 here.

[giacomomagni]

@felixhekhorn , @RoyStegeman and @andreab1997 maybe we can try to merge this PR and the improve the docs in a subsequent branch. Would that work for you?

[andreab1997]

@felixhekhorn , @RoyStegeman and @andreab1997 maybe we can try to merge this PR and the improve the docs in a subsequent branch. Would that work for you?

I agree

[felixhekhorn]

@felixhekhorn , @RoyStegeman and @andreab1997 maybe we can try to merge this PR and the improve the docs in a subsequent branch. Would that work for you?

fine - let's just not delay it too long, in any case we need it for our paper