Anticipate how POS FK tables are parsed in the new commondata reader

[Radonirinaunimi]

I am not entirely sure yet how the positivity FK tables will be parsed in the new commondata reader. At one of the CMs, it was proposed to read the $(x, Q^2)$ info from the FK tables directly therefore removing the need for a commondata file. However, it might still be better (and more flexible) to parse the positivity exactly in the same way as experimental data (as in the old commondata way). This is especially crucial for the polarised fit in which a positivity dataset is composed of compound FK tables with non-null operation.

[scarlehoff]

This is now implemented in ea06b2d

It is not necessary to define data or uncertainties, only kinematics and the number of datapoints.

[Radonirinaunimi]

Thanks a lot for this! I've tested and the reading of the FK tables are fine, however, there is still one small issue remaining which is the passing of the operation into the positivity object. Currently, even if operation is not null in the metadata, operation_name is still NULL. If you want, I could also try to take care of this.

[scarlehoff]

I don't underdstand what you mean? Operation name should be read directly also for positivity. Can you send me the metadata failing?

Can I reproduce it by simply adding an op?

[Radonirinaunimi]

At the moment, if I catch the operation_name from the following line, for example:

nnpdf/n3fit/src/n3fit/model_gen.py

Line 175 in ec76404

operation_name = dataset.operation

the value is always NULL for positivity dataset regardless of what is defined in the metadata.

Can I reproduce it by simply adding an op?

Yes, you can reproduce the behavior by taking one of the POS data that you converted and add just operation under theory.

[scarlehoff]

ok, found it. It is read ok but at some point vp drops operations from positivity and integrability. It will be fixed in the next commit in a few minutes.

[Radonirinaunimi]

Awesome, thanks! Tested it and it works fine.