Remove need for _template.yaml

[evagroenendijk]

Remove the need for _template.yaml as in issue #202

[evagroenendijk]

https://github.com/NNPDF/pineko/blob/f4097f29dec964e8b2c17818b502575ffa3444f0/tests/test_evolve.py#L55C1-L55C43

@scarlehoff Could I maybe just remove this test? I could make it check that the theory cards' Q0 is the same as the default one, but to me it seems a bit superfluous

[scarlehoff]

Sure, shuffling around the _template and the operators might change which tests are needed.

[felixhekhorn]

some quick things I noticed last week

[evagroenendijk]

@felixhekhorn The regression benchmark comparing convolved predictions failed, but the maximal relative difference is 0.03497747. Would you say it's close enough?

[felixhekhorn]

@felixhekhorn The regression benchmark comparing convolved predictions failed, but the maximal relative difference is 0.03497747. Would you say it's close enough?

I'm quite worried by this

Your theory has a different evolution method than the default(iterate-exact vs truncated).The evolution method will be set to the default value iterate-exact, check if this is what you want
Warning! The number of iteration in the theory and template is different, (60 vs 1).The number of iterations will be set to default value 60, check if this is what you want

this sounds like we can no longer run actually truncated - i.e. we can no longer reproduce 4.0. If that would be true that must be changed. This might well explain the difference we observe. We want to enforce consistent settings, i.e. "if method=truncated then iterations=1", but we don't want to enforce method=exact everywhere.

[scarlehoff]

This has to do with the comment I left. We just want to ensure that the evolution settings are coming from the theory not from a constant setting.

[evagroenendijk]

@felixhekhorn The regression benchmark comparing convolved predictions failed, but the maximal relative difference is 0.03497747. Would you say it's close enough?

I'm quite worried by this

Your theory has a different evolution method than the default(iterate-exact vs truncated).The evolution method will be set to the default value iterate-exact, check if this is what you want
Warning! The number of iteration in the theory and template is different, (60 vs 1).The number of iterations will be set to default value 60, check if this is what you want

this sounds like we can no longer run actually truncated - i.e. we can no longer reproduce 4.0. If that would be true that must be changed. This might well explain the difference we observe. We want to enforce consistent settings, i.e. "if method=truncated then iterations=1", but we don't want to enforce method=exact everywhere.

You're right! I think here I ran the benchmark while using iterate-exact (which I hardcoded into template.py). But as Juan suggested I will now let the evolution method be totally determined by the theory card. Then it would also do truncated evolution

[scarlehoff]

Let me know when I should try to test this again!

Btw, perhaps it would be good to rebase on top of master (or merge the changes from master)?

[evagroenendijk]

@scarlehoff Yes thanks, I implemented the changes you suggested and made the necessary adjustment, let me know if you agree! Sorry, I took the day off on Friday so I just finished it today

[scarlehoff]

Thanks, this now works for me in a folder with no template and

It would be great if @kamillaurent could check explicitly that the fktables he computed didn't change. The best course of action is to select to datasets (one hadronic, one DIS, they can be quite small so that it goes faster), ideally from a theory with scale variations, and check that the results of the fktables ran with this branch are identical to the previous ones.

[scarlehoff]

To make it more consistent, it would be better if the integration cores were also in the eko command in the case of the normal fktables.

[evagroenendijk]

Okay, and what about interpolation_is_log and interpolation_polynomial_degree?

[scarlehoff]

Those I think belong in the operator card. This option does not exist in fonll so it is what it is.
But the cores is something that might indeed be changed even with the same operator card (and which doesn´t change the numerical results, only how long it takes)

[scarlehoff]

@kamillaurent did you have a change to test this?

[kamillaurent]

@scarlehoff no, because I saw there was movement on the PR. Also I am working on PR #247 and I thought it would be easier to test this after merging the previous one (so I apply the changes on top of it and I test if everything is consistent).

If for some reason PR #247 can't be merged in the short term, I will test this one without waiting for the other to be merged.

[scarlehoff]

@evagroenendijk is this one final?

@kamillaurent I'm actually unsure what the best course of action is, because these two have conflicting changes. If you confirm that #247 is now final, I will merge that one and, if @evagroenendijk confirms this one is also final, we can merge master into this branch (I favour rebase but it would require too much manual work) and then you test that

(but it is important that you test with an exact commit that is available the repo)

[kamillaurent]

I confirm that #247 is final, if you have no other change request.

[felixhekhorn]

I dislike the fact that ipd=4 is now defined in several places, but for the sake of getting this PR done I will ignore it here for the moment ...

[felixhekhorn]

Suggested change

	operators_card["configs"]["interpolation_is_log"] = iil
	operators_card["configs"]["interpolation_is_log"] = iil
	operators_card["configs"]["n_integration_cores"] = 1

Let's still write cards, which can be executed out of the box (without pineko being present to add stuff)

[felixhekhorn]

why did you remove the options from the ekos command?