HERA 1.0 and LHeC PDF migration and approval
Same procedure as for ATLAS and HERA 1.5. Prod Voica for an update.
Remove remaining Boost dependencies / move to C++11 (AB)
Only remaining use is multiarray: replace with Martin's array/SSE code
Check that unique_ptr and shared_ptr semantics (e.g. ptr-populating code) work as intended.
New Fortran API
Surely something nicer than the LHAPDF5 API can be made? Fortran isn't going away from the the theory world. Suggest prefixing all functions with "lhapdf" and basing it on the PDFManager, with explicit commands for switching current PDF.
Ideas: uniform "lhapdf_" prefix, require nset and nmem args for all commands, i.e. no "current" set slot.
Requests: way to get LHAPDF ID from current set/PDF. Arbitrary PIDs.
Provide a single-string-arg version of lookupPDF
Needs the signature of the function(s) for PDF string decoding to be final before exposing in the API; it's currently in an anon namespace in Factories.cc.
Optimize the grid PDF interpolator code
Cache log(x), log(Q) between samplings -> log() still accounts for 15% of CPU: can reduce by factor of 13 in some use cases (only one call for a whole flavour interpolation set at the same point). Below threshold? Sherpa already report performance increases due to being able to interpolated one flavour at a time, so perhaps this use case is not valid in all generators and could be a more complexity than it is worth.
Speed up interpolation (MR)
Many studies already... and Martin has done the important work to de-Boostify the interpolation grid data objects.
Report of 6.0.4 slowness relative to LHAPDF5 (on CT10). Weird, we tested this at version 6.0.0 and it was outperforming LHA5. Maybe it is slower for CT10 and ~same for CT10nlo. Juan reports that the NNPDF functions are faster.
Possible speed-ups: caching the last log(x) and log(Q2) values, caching grid index lookup, caching interpolation weights, using a native array implementation in place of Boost::multiarray, doing a faster hybrid search in the grids, GCC builtins for SSE auto-vectorisation.
Martin has got some speed-up out of a native array implementation, and found no benefit of changing the index search. Andy will look into caching.
Add an lhapdf show command
To print pdfsets.index + cat .info for already installed PDFs.
There's definitely a need for interfaces both to individual nuclear modification functions (like PDFs themselves, a function of x,Q2) for application on top of nucleon PDFs, and for all-inclusive nuclear PDFs. Individual "sets" for each nucleus (A) as well as error sets: need to decide on groupings as well as the API. Quite active, cf. "Lisbon Accord".
In contact with Hannu. Extend string access syntax to include multiplication of PDFs e.g. mkPDF("foo/0 * bar"), mkPDF("foo * bar/0"), mkPDF("foo * bar") returns PDF <- CompositePDF More general than just nPDFs. Move extended ID string decoding to user-accessible functions.
Introduce minimal abstract C++ interface
Since composite PDFs don't obviously have some current PDF features. Prefer to re-purpose PDF as the interface than to add a new PDFBase or similar?
Handle zipped PDF .dat files (AB)
Prefer zipped single member data files rather than virtual filesystem access to the tarball. Can transparently read zipped files with LD_PRELOAD and zlibc: is that enough? Or
Speed up interpolation with GPUs
Interpolation of PDFs seems like an potential use case for GPUs, since it's normal to query for all partons in the set at once: if we can load the relevant ipol anchors for all flavours onto the GPU then we can maybe get a substantial speedup. OpenMP did not particuarly help, from quick tests.
PDF flavor aliasing mechanism
e.g. allow anti-flavours to be identical without duplicating their grids in the data files or memory. How could we implement this?
Allow use of valence/sea etc. decompositions?
GridPDF may be inherited from to allow the returned values to be built from separate interpolations of component PDFs such as interpolated valence, sea, or difference PDFs that are combined to make the physical ones. The PDG ID code range for "generator specific" applications may be used, but we'll need to bear in mind that this will mean that the flavor ID list has different meanings and contents for internal and external purposes: maybe the "internal" PDG ID list needs to become part of the grid data header, or can the metadata be used?
Separate the x and Q2 inter/extrapolation?
Allow mix & match combinations. Would this simplify the code since the 1D interpolation methods are very simple and the 2D is built from them?
Make GridPDFs not read their info or data blocks until an xf value is requested?!
Super-laziness! But is there a real gain other than < 1 sec initialization speed?