Support reading v0.13 and v0.14 files

[felixhekhorn]

Okay, this will need some thinking, as we maybe want to come up with a more future-proof strategy (see e.g. #145 #328)

• this drops the Legacy runner, i.e. closes Drop legacy runner #398 - this will break many things potentially again, i.e. this is surely another major break to master. eko.runner.managed.solve which is the new default does only accept new runcards, i.e. if you need to convert the user has to do that before calling the function (see also below)
• this drops the old file converter which was for files before v0.11 (I think)
• then continuing from Legacy to versions #175:
  • we still have eko.io.runcards.Legacy: 1. we should rename that to NnpdfDb or similar (and maybe move it?) and 2. I guess we need to maintain that also midterm (or even forever)
  • we haven't increased the __data_version__ since we introduced it, but I guess we should start doing so to disentangle a change in API (__version__) from a change in the file format (__data_version__). The latter also refers any file in the tar, i.e. including all .yaml files. We should increase it to 3 and rely on versions beyond v0.15 on that (1 ~ v0.13, 2 ~ v0.14 although the latter was never applied).
• I don't know how to recover from Change manipulate to act on Operator #292 : old ekos might be rotated (on any of the four axes) and we would need to counteract this everywhere ... any ideas? It is true that the old format and the new format are technical the same, but the content might not

cc @scarlehoff

[scarlehoff]

(or even forever)

4ever

But I'm happy with moving it to the theory parser in NNPDF (i.e., having an attribute in the Theory file which is return_eko_theory or something).
But I would say let's do things incrementally, for now let's keep it here, let's make sure things are working and then we move it.

since we introduced it, but I guess we should start doing so to disentangle a change in API

I agree. The ones in 0.15 are surely a data version different from what we have

I don't know how to recover from

from the nnpdf side I don't mind not having this. In practice it would mean that the x-grid is completely fixed. If I understand correctly this feature has been more a convenience for people that could create more custom ekos and then got the 192x LHAPDF grid as the output? (did I understood it correctly @giacomomagni ?)

[giacomomagni]

• this drops the Legacy runner, i.e. closes Drop legacy runner #398 - this will break many things potentially again, i.e. this is surely another major break to master. eko.runner.managed.solve which is the new default does only accept new runcards, i.e. if you need to convert the user has to do that before calling the function (see also below)

since we are updating evolven3fit we might consider to update as well pineko... but it will require a bit of work.

• this drops the old file converter which was for files before v0.11 (I think)

here we are safe I think, it's already impossible to read 0.12 (?)

• I don't know how to recover from Change manipulate to act on Operator #292 : old ekos might be rotated (on any of the four axes) and we would need to counteract this everywhere ... any ideas? It is true that the old format and the new format are technical the same, but the content might not

so in order to use the old ekos (0.13) you'd need to convert them, can't we add some checks while applying the conversion and warn the user?

[scarlehoff]

so in order to use the old ekos (0.13) you'd need to convert them, can't we add some checks while applying the conversion and warn the user?

Wait, I thought the pdf ekos that we have were already ok without rotation? Or do you mean the fktables ekos?

[felixhekhorn]

But I would say let's do things incrementally, for now let's keep it here, let's make sure things are working and then we move it.

definitely. I'm not sure, if that is better here or in NNPDF - we may want to move it e.g. into ekobox though

since we are updating evolven3fit we might consider to update as well pineko... but it will require a bit of work.

yes, but it will require anyway work since this is a major change already

here we are safe I think, it's already impossible to read 0.12 (?)

I think so - that was never requested and so with this PR I put a hard limit on v0.13

so in order to use the old ekos (0.13) you'd need to convert them, can't we add some checks while applying the conversion and warn the user?

just warning would be doable - but is that sufficient?

from the nnpdf side I don't mind not having this. In practice it would mean that the x-grid is completely fixed. If I understand correctly this feature has been more a convenience for people that could create more custom ekos and then got the 192x LHAPDF grid as the output? (did I understood it correctly @giacomomagni ?)

Wait, I thought the pdf ekos that we have were already ok without rotation? Or do you mean the fktables ekos?

that's the thing: eko can not know for what you use the it - and FK-ekos are rotated by default, even on multiple axes (I think). The main post-fit eko might be safe by chance. You can still rotate the eko in any way you like, but it is now always stored in the "canconical basis" (of course you can force your way)

[scarlehoff]

Yes, they might be correct by chance... but if they are correct then we are happy I'd say, chance or not