Feature wishlist

[felixhekhorn]

I would like to see more features to make this a full drop-in replacement.

1. add a PDFSet equivalent - i.e. the ensemble itself and not any specific member there of. In particular I would need the uncertainty, has_key, and get_entry methods
2. I would love to do a import neopdf.blub as lhapdf and that act as a true drop-in replacement - it might be too ambitious I know ... the current from neopdf.pdf import PDF as lhapdf does only work for mkPDF at the moment, but then lhapdf.setVerbosity(0) (which could for example do exactly nothing) or lhapdf.getPDFSet (see above) fail

I was hoping using neopdf I could bypass https://gitlab.com/hepcedar/lhapdf/-/commit/d71a58e18565786f276d32e21a82ea0e10374c04 - but then I realised that this creates actually more problems ...

[Radonirinaunimi]

Thanks for the comments @felixhekhorn!

1. add a [`PDFSet`](https://gitlab.com/hepcedar/lhapdf/-/blob/main/src/PDFSet.cc?ref_type=heads) equivalent - i.e. the ensemble itself and not any specific member there of. In particular I would need the `uncertainty`, `has_key`, and `get_entry` methods

This, I am currently working on, especially in the view of NNPDF/pineappl#370.

2. I would love to do a `import neopdf.blub as lhapdf` and that act as a true drop-in replacement - it might be too ambitious I know ... the current `from neopdf.pdf import PDF as lhapdf` does only work for `mkPDF` at the moment, but then `lhapdf.setVerbosity(0)` (which could for example do exactly nothing) or `lhapdf.getPDFSet` (see above) fail

For this, I am not entirely sure about the best way to implement it without polluting the modules/namespaces with duplicated methods.

I was hoping using neopdf I could bypass https://gitlab.com/hepcedar/lhapdf/-/commit/d71a58e18565786f276d32e21a82ea0e10374c04 - but then I realised that this creates actually more problems ...

Could you perhaps summarize what exactly is the premise of this?

[felixhekhorn]

I was hoping using neopdf I could bypass https://gitlab.com/hepcedar/lhapdf/-/commit/d71a58e18565786f276d32e21a82ea0e10374c04 - but then I realised that this creates actually more problems ...

Could you perhaps summarize what exactly is the premise of this?

I thought I was affected by that bug, which was wrong - so please ignore that

2. I would love to do a `import neopdf.blub as lhapdf` and that act as a true drop-in replacement - it might be too ambitious I know ... the current `from neopdf.pdf import PDF as lhapdf` does only work for `mkPDF` at the moment, but then `lhapdf.setVerbosity(0)` (which could for example do exactly nothing) or `lhapdf.getPDFSet` (see above) fail

For this, I am not entirely sure about the best way to implement it without polluting the modules/namespaces with duplicated methods.

I'm not sure Rust has the same feature, but in Python you could just re-export the relevant methods, no? is that what you mean? in any case, as already said, I'm not sure how far you want to go with this ...