We'd like PineAPPL as well to be able to consume an EKO one Q2 at a time, since evolving grids requesting a huge number of Q2 points would require splitting the grid otherwise.
In order to do this, the easiest is to directly provide and maintain a Rust crate that is able to manage the EKO output format.
Indeed, PyO3 would make it possible to run Python code from Rust, but it is more a handle on the interpreter itself, rather than proper bindings in this direction (even though it might be used for this, but it can be painful).
So, the easiest thing it's to make a standalone crate in this repository (unfortunately eko is already lost as a name, but we can still use something like get eko, i.e. geko).
In order to do this, we don't really need many ingredients:
- a
tar library, for which the one linked is an obvious candidate
a yaml library, that is another easy choice
- an
npy library, and here it becomes difficult; the alternatives are
npyz not much maintained, but should be complete enoughndarray-npy, slightly more maintained in the recent future, but it does not seem to have a complete feature setnpy, that is mentioned by the previous, and the number 1. claims to be its fork, but it looks untouched from 2018
In light of the release of the new runner, and the associated new internal format, I'd speed up the implementation of a first version of the loader.
First iteration (strictly required):
Second iteration (nice-to-have):
We'd like PineAPPL as well to be able to consume an EKO one
Q2at a time, since evolving grids requesting a huge number ofQ2points would require splitting the grid otherwise.In order to do this, the easiest is to directly provide and maintain a Rust crate that is able to manage the EKO output format.
Indeed, PyO3 would make it possible to run Python code from Rust, but it is more a handle on the interpreter itself, rather than proper bindings in this direction (even though it might be used for this, but it can be painful).
So, the easiest thing it's to make a standalone crate in this repository (unfortunately
ekois already lost as a name, but we can still use something like get eko, i.e.geko).In order to do this, we don't really need many ingredients:
tarlibrary, for which the one linked is an obvious candidateayamllibrary, that is another easy choiceserde-yamlnpylibrary, and here it becomes difficult; the alternatives arenpyznot much maintained, but should be complete enoughndarray-npy, slightly more maintained in the recent future, but it does not seem to have a complete feature setnpy, that is mentioned by the previous, and the number 1. claims to be its fork, but it looks untouched from 2018#242 loader
In light of the release of the new runner, and the associated new internal format, I'd speed up the implementation of a first version of the loader.
First iteration (strictly required):
syncerSecond iteration (nice-to-have):