Add NeoPDF interface to handlle non-perturbative functions #369

Activity

1. Radonirinaunimi

   added

   enhancementNew feature or requestNew feature or request

   physics

   LHAPDF

   on Jan 20, 2026
2. t7phy commented on Jan 20, 2026

   

   t7phy

   on Jan 20, 2026

   Collaborator

   More actions

   @Radonirinaunimi This seems like a very great improvement and would definitely be helpful. However I think it would still be good to not strip away the LHAPDF dependence. LHAPDF is too widely used and it is probably not a good idea to remove already existing and working interfaces.
   What we should probably do is to allow the usage of PineAPPL (specifically the CLI which automatically uses LHAPDF) even when LHAPDF is not in the system, by relying completely on NeoPDF.
3. Radonirinaunimi commented on Jan 20, 2026

   

   Radonirinaunimi

   on Jan 20, 2026

   MemberAuthor

   More actions

   What we should probably do is to allow the usage of PineAPPL (specifically the CLI which automatically uses LHAPDF) even when LHAPDF is not in the system, by relying completely on NeoPDF.

   I guess in some sense this is what I mean. Practically, neopdf will replace the managed-lhapdf dependency, and from the user's point of view everything else will stay the same (ie, being able to load the usual LHAPDF files). The difference is only that instead of the actual LHAPDF calls, NeoPDF would be the one that provides the interpolation (which when used on standard LHAPDF sets provide the exact same results, beyond numerical precision). And for this indeed, then installation of LHAPDF will no longer be required on the system.

   👍React with 👍1Reacted by Tanishq Sharma
4. cschwan commented on Jan 21, 2026

   

   cschwan

   on Jan 21, 2026

   Contributor

   More actions

   This is a great idea, which I fully support. I'm not quite sure to what extend we can completely replace LHAPDF, at least fastNLO (which we use for import) relies on it. I suppose for testing and later for testing the NeoPDF against LHAPDF and vice versa I would be nice to switch the libraries at run-time.

   A good start would be to refactor all symbols used from lhapdf:: to the helpers module in pineappl_cli. There aren't too many:

   ./src/export.rs:use lhapdf::Pdf;
   ./src/import.rs:use lhapdf::Pdf;
   ./src/import.rs:    assert_eq!(conv_funs.lhapdf_names.len(), 1);
   ./src/import.rs:    let mut file = ffi::make_fastnlo_lhapdf_with_name_file_set(
   ./src/import.rs:        &conv_funs.lhapdf_names[0],
   ./src/import.rs:        let mut reader = ffi::downcast_lhapdf_to_reader_mut(file.as_mut().unwrap());
   ./src/import.rs:    let mut reader = ffi::downcast_lhapdf_to_reader_mut(file.as_mut().unwrap());
   ./src/evolve.rs:use lhapdf::Pdf;
   ./src/import/fastnlo.rs:    let file_as_reader = ffi::downcast_lhapdf_to_reader(file);
   ./src/import/fastnlo.rs:    let file_as_table = ffi::downcast_lhapdf_to_table(file);
   ./src/import/applgrid.rs:use lhapdf::Pdf;
   ./src/lib.rs:    pub lhapdf_banner: bool,
   ./src/export/applgrid.rs:use lhapdf::Pdf;
   ./src/pull.rs:use lhapdf::{Pdf, PdfSet};
   ./src/pull.rs:    #[arg(default_value_t = lhapdf::CL_1_SIGMA, long)]
   ./src/main.rs:    if !opts.configuration.lhapdf_banner {
   ./src/main.rs:        lhapdf::set_verbosity(0);
   ./src/uncert.rs:    #[arg(default_value_t = lhapdf::CL_1_SIGMA, long)]
   ./src/uncert.rs:                cell!(c->format!("{}\n[{y_unit}]          [%]     [%]", self.conv_funs.lhapdf_names[index]))
   ./tests/read.rs:  lhapdf        = pdlabel ! PDF set
   ./tests/read.rs:  324900        = lhaid ! If pdlabel=lhapdf, this is the lhapdf number. Only 
   ./tests/import.rs:    use lhapdf::Pdf;
   ./tests/main.rs:      --lhapdf-banner          Allow LHAPDF to print banners
   

   Then you could write functions that allow selecting the 'convolution function backend' (LHAPDF/NeoPDF) in helper.rs.
5. cschwan

   assigned

   cschwan

   and

   Radonirinaunimi

   and unassigned

   cschwan

   on Jul 25, 2026
6. cschwan commented on Jul 25, 2026

   

   cschwan

   on Jul 25, 2026

   Contributor

   More actions

   Since we've merged #370, I think this can be closed; what do you think, @Radonirinaunimi?

   👍React with 👍1Reacted by Tanjona R. Rabemananjara
7. Radonirinaunimi commented on Jul 28, 2026

   

   Radonirinaunimi

   on Jul 28, 2026

   MemberAuthor

   More actions

   Hi @cschwan, yes, this could indeed be merged.
8. Radonirinaunimi

   closed this as completedon Jul 28, 2026