Add new struct FkTable

[cschwan]

Add a new struct FkTable, which is a special case of Grid, but

• has a single scale Q^2 for all Subgrids
• guarantees that the x1 and x2 grids are the same for each Subgrid
• has a simplified luminosity function, in the sense that each combination of initial-states appears only once
• has exactly one order, with all powers set to zero, because all powers are added on top with each other with the right powers in the strong coupling constant
• must contain the following metadata:
  • initial_state_1 and initial_state_2 are implicitly set to 2212 (proton) if not present in Grid, but for FkTable they must be explicitly set
  • lumi_id_types which is either pdg_mc_ids if the luminosity function uses MC PDG IDs (for the flavour basis), or evo_basis_ids for the evolution basis, which has the following possible ids: 21 (gluon), 22 (photon), 100 (V), 103 (V3), 108 (V8), 115 (V15), 124 (V24), 135 (V35), 200 (sigma), 203 (T3), 208 (T8), 215 (T15), 224 (T24) and 235 (T35)
  • more metadata to explicitly specify the evolution kernel operators that were used to produce the FkTable
• must not contain any K-factors, which instead are built into table

[alecandido]

I agree this will simplify the interaction at boundaries (both eko and fit).

The moment you provide the implementation we can migrate the python interface, but there is not so much to actually migrate: being a special case of Grid will provide a similar API, so we can just test and fix few incompatibilities.

Personal interest: being that there is no inheritance, how are you going to implement this structure? My natural answer would have been to promote the API to a trait (with some default implementations), and have two trait implementers, but doing this a posteriori would require a massive code rework (and after all it's an approximation to subclassing, I'm too used to it...).

[cschwan]

Personal interest: being that there is no inheritance, how are you going to implement this structure? My natural answer would have been to promote the API to a trait (with some default implementations), and have two trait implementers, but doing this a posteriori would require a massive code rework (and after all it's an approximation to subclassing, I'm too used to it...).

Like this 😄 :

struct FkTable {
    table: Grid,
}

[alecandido]

That's a fair solution. Simple and effective 👌
Maybe inheritance might have been more suitable for the task, nevertheless it's bad that I feel lost without.

[cschwan]

I added a first implementation in commit 497a446.

[cschwan]

Implemented in the pyo3 branch: #51.