Changing n3lo_cf_variations from int to list

[jekoorn]

The update in YADISM/388 NNPDF/yadism#388 will break the definition of TheoryCard. Either we accept both a list or an integer, or we go and make sure theory cards will all possess a list.

Example of what could happen

 File "/nnpdf/nnpdf_data/nnpdf_data/utils.py", line 169, in parse_yaml_inp
    raise ValidationError('\n'.join(error_text_lines)) from e
validobj.errors.ValidationError: Problem processing key at line 46 in /nnpdf/nnpdf_data/nnpdf_data/theory_cards/40007005.yaml:
Cannot process field 'n3lo_cf_variation' of value into the corresponding field of 'TheoryCard'
No match for any possible type:
Not a valid match for 'list': Expecting value of type 'list', not int.
Not a valid match for 'NoneType': Expecting value of type 'NoneType', not int.

[scarlehoff]

I think the theory cards here were not supposed to be yadism-compatible @felixhekhorn ?

That said, if n3lo_cf_variation is only relevant for yadism (and not for eko) I guess we should have it synchronised.

[jekoorn]

Doesn't it become an issue then, when you use these n3lo_cf_variation cards for anything else that calls this util?
Otherwise we should have just kept the convention to be an integer for the default card, and only change it to a list for the 8 theory cards that require a variation. But I think a synchronisation is still better and more fool-proof.

[scarlehoff]

Doesn't it become an issue then, when you use these n3lo_cf_variation cards for anything else that calls this util?

This is why we need @felixhekhorn's input ^^U, if it is a yadism-only flag then we can change it at will and it is not a problem

[felixhekhorn]

That said, if n3lo_cf_variation is only relevant for yadism (and not for eko) I guess we should have it synchronised.

the "cf" means "coefficient function"

I think the theory cards here were not supposed to be yadism-compatible @felixhekhorn ?

mh? how do you mean? the theory cards here are supposed to hold all information which define a theory (in the sense of this repository), thus it must be a list. Am I missing something?

This is why we need @felixhekhorn's input ^^U, if it is a yadism-only flag then we can change it at will and it is not a problem

why would be yadism here different from eko? if we have a new feature in either code we usually want to import it to here ... (There is a small overlap with NNPDF/eko#473 )

[scarlehoff]

mh? how do you mean? the theory cards here are supposed to hold all information which define a theory (in the sense of this repository), thus it must be a list. Am I missing something?

Then it must be a list and that's it.

What I mean is that these cards don't need to be read (unmodified) by yadism at any point.

[jekoorn]

Additionally I am afraid
https://github.com/NNPDF/nnpdf/blob/master/validphys2/src/validphys/scalevariations/pointprescriptions.yaml
needs to be updated as well, since it contains the old 'central DIS', 'lower bound DIS', 'upper bound DIS' variations. But this will make any old N3LO CF variation break.

Edit: in validphys2/src/validphys/theorycovariance/construction.py the dis hou will also need to take a 9 point construction, and the full covmat also needs its own construction function (it seems to be not implemented)

[felixhekhorn]

This line conflicts with this one

nnpdf/validphys2/src/validphys/scalevariations/scalevariationtheoryids.yaml

Line 459 in ee3069f

(0, 0, 0, 0): 41_042_000

I think the obvious conclusion is that this PR should sit on top of #2494 and the necessary changes should be done there to vp; i.e. this PR should only do what it says and no more

[jekoorn]

yeah I am screwing up a bit, I will revert this back.