Produce scale variation dataspecs

[voisey]

I would like to have a production rule that given a central theoryid and point_prescription produces a dataspecs such as the one on line 15 of the first example here https://docs.nnpdf.science/vp/theorycov/examples.html, as this would eliminate one more annoying thing that the user has to specify in a runcard that uses the theory covmat. I've just written something that does this (it's essentially just an extension of #664) and it works fine. I can therefore just do something like the following in the runcard:

dataspecs:
  from_: scale_variation_dataspecs

However, I would also like it to work for the validation runcard here: https://docs.nnpdf.science/vp/theorycov/examples.html#validation-report. There we have something like:

dataspecs:
       - theoryid: 163
          speclabel: $(\xi_F,\xi_R)=(1,1)$
          experiments: *experiments_list_nlo
       - theoryid: 177
          speclabel: $(\xi_F,\xi_R)=(2,1)$
          experiments: *experiments_list_nlo
       - theoryid: 176
          speclabel: $(\xi_F,\xi_R)=(0.5,1)$
          experiments: *experiments_list_nlo
       - theoryid: 179
          speclabel: $(\xi_F,\xi_R)=(1,2)$
          experiments: *experiments_list_nlo
       - theoryid: 174
          speclabel: $(\xi_F,\xi_R)=(1,0.5)$
          experiments: *experiments_list_nlo

so what I did for the first case doesn't work, because dataspecs also includes experiments. Is there some way that we could not write the experiments in the dataspecs, so that the dataspecs is simpler, and looks like it does in the first case?

[RosalynLP]

@voisey This will be affected by #515 because the structure of the experiments list will be converted to a flat list of data. But at the moment I think the problem is we need the experiments for each dataspec because we have to get experiments_results for each dataspec and this requires experiments, right?

[voisey]

Sure sure, thanks. Yes, it must be something like that. It errored when I didn't set one experiments per dataspec. So I guess this means that there's no way around it? If so, then there's the question of whether it's worth having this production rule anyway, even though it only works in one set of runcards. What do you think?

[RosalynLP]

I'm not sure, probably in the future we're likely to be wanting to do more stuff with theory errors so it might be a good idea to invest time in these sorts of things, however I think it makes sense to wait until #515 is merged at least (should be soon) because this will definitely affect things. Also I was planning to overhaul the whole theorycovariance module in the light of #515 (hopefully simplifying it a lot) so I'm not sure what influence that would have.

[RosalynLP]

Also that #515 merge has been done now so I am happy to take a look at doing this

[RosalynLP]

@voisey you said you had made a start on this (" I've just written something that does this (it's essentially just an extension of #664) and it works fine. I can therefore just do something like the following in the runcard"), do you have a branch for this? I want to try and solve this issue if possible but if you've already done work on it I don't want to redo it!

[voisey]

I don't believe I still have the branch unfortunately!

[RosalynLP]

OK no problem!