FK Spec about pineko

[felixhekhorn]

I think @scarlehoff you're happy with the current layout in pineappl_py, right? Please reopen if you don't agree

[cschwan]

Concerning the C factors and other factors applied by apfelcomb, I'd like to know what they are used for. I know of the following uses:

1. NNLO QCD and/or NLO EW K factors and
2. to convert between different units: some grids are given femtobarn, or are in picobarn, therefore one had to add a factor 1000 somewhere

Are there more? @scarlehoff @scarrazza

The use of 1) should IMO be implemented in PineAPPL, see NNPDF/pineappl#7, because I don't like related data in different places. Different units as in 2) are already taken care of by metadata in PineAPPL, where y_unit is either fb or pb (or pb/GeV, ...).

[cschwan]

@scarlehoff I've had a quick look at the FK tables and saw that they're text files where the numbers are written with the full double precision. PineAPPL grids instead are binary files, and I've made sure that zeros are not stored at all. Overall that makes me quite optimistic about the total size of all PineAPPL FKtables.

[alecandido]

Input

I will ask for the fktable by giving the following information:

theoryid: 200
dataset_inputs:
    - {dataset: ATLAS_WZ_TOT_13TEV, cfac: [NRM, QCD]}

Ok fine, so there will be a dataset database somewhere and ATLAS_WZ_TOT_13TEV works like an id for it. Then also the pineapplgrids relative to yadism will be generated ahead of time (even if they will be quite fast you could generate on the fly).

* `ndata`: number of experimental data points

* `nx`: number of points in the x-grid

* `nbasis`: number of non-zero channels

* `hadronic`: boolean flag telling me whether the process is hadronic or not

3 out of 4 can be computed from the previous data (essentially calling len(ciao) or len(ciao.shape()) == 3), nevertheless if it's convenient for you it costs us nothing to provide them as @property.

Note that I don't put any constraints in the type of the different objects. To actually operate with them I will make them into tensorflow tensors so numpy arrays is the more natural choice but I can work with anything.

The only other option it's to provide some raw rust structure (i.e. ndarray == numrust), but then I would say that the only reasonable option it's numpy arrays.

Wishlist

I'm not entirely sure you can compress the current .dat files much more than they currently are (I don't know how much effort was put into compressing them back in the day) but it would make me much happier if instead of downloading 3 GB to do a fit I could download just 1.

We are using pineapplgrids as output format, and to my understanding @cschwan put already a lot of effort in compressing them, so if there was room for further compression they will be compressed, but we'll keep an eye.

[scarlehoff]

3 out of 4 can be computed from the previous data (essentially calling len(ciao) or len(ciao.shape()) == 3), nevertheless if it's convenient for you it costs us nothing to provide them as @property.

All of them. If the basis is rank-2 then it is hadronic. This just makes my life easier. Mainly I won't have to remember whether the first dimension of the fktable is the ndata or the nx.

Are there more?

I don't know right now, but there might be "special" studies for which other cfactors-like objects are used @scarrazza ?

[alecandido]

All of them. If the basis is rank-2 then it is hadronic. This just makes my life easier. Mainly I won't have to remember whether the first dimension of the fktable is the ndata or the nx.

I was wondering just about the nbasis since you said nonzero elements, but then I realized it was one of the dimensions of the array. Then yes: all will be provided as @property.