Closed cschwan closed 3 years ago
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...).
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 :smile: :
struct FkTable {
table: Grid,
}
That's a fair solution. Simple and effective :ok_hand: Maybe inheritance might have been more suitable for the task, nevertheless it's bad that I feel lost without.
I added a first implementation in commit 497a446651aa2805807fe5668abd68df4c072c65.
Implemented in the pyo3 branch: #51.
Add a new struct
FkTable
, which is a special case ofGrid
, butSubgrid
sx1
andx2
grids are the same for eachSubgrid
initial_state_1
andinitial_state_2
are implicitly set to2212
(proton) if not present inGrid
, but forFkTable
they must be explicitly setlumi_id_types
which is eitherpdg_mc_ids
if the luminosity function uses MC PDG IDs (for the flavour basis), orevo_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) and235
(T35)FkTable