forked from alisw/LHAPDF
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
157 lines (87 loc) · 5.04 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
/**
@page todolist Project to-do list
LHAPDF6 TODO list
=================
VERSION 6.5.x
-------------
- **Use pdfsets.index lookup from core lib in lhapdf script**
For consistency in index-file combination, etc. in "lhapdf update" and so-on.
Cf. Matt Feickert bug report.
- **Expose setInterpolator/setExtrapolator functions in Python**
It would be useful to be able to overload the .info-specified interpolator and
extrapolator of a PDF or set from Python as well as C++, at least via the string-arg
overloads. But these functions are specific to GridPDF... do we need to expose that
as a derived type, and use it for the PDFs built that way?
- **Mix and match 1D interpolators**
The whole-function polynomials will require a lot of evaluations if
performed in both directions. We should implement the 1D Lagrange and
other interpolators as free "ipol utility" functions, so they can be
mixed and matched, e.g. "Chebyshev-Lagrange" in x, with mini-spline type
interpolation of a given order in the other.
Mix-and-match mode will require the PDF code to ask the second-direction
interpolator what values it needs evaluations for, before executing the
first-direction interpolator on them.
The string-based ipol specification probably needs to become a bit more
intelligent, parsing a string format for ipol order & scheme specs rather
than the current fixed-value approach. Perhaps a version of the function
accepting two strings, one for x and one for Q2, to be joined correctly
into the single-string form.
- **Consider extrapolated cubic splines at subgrid edges (cf. Valerio Bertone et al)**
VERSION 6.6.x
-------------
- **3- and 4-param interpolation for resolved-photon/TMD PDFs**
Cf. Max/Peter/Andy project.
- **Lagrange polynomial interpolation with Chebyshev knots**
The idea is to provide a smooth "whole function" interpolation with no
derivative discontinuities across knot points... at the cost of having
to perform whole-function fits. Chebyshev knots are denser at the
ends of the range, to calm Runge's phenomenon.
Done by Max and Andy, need N3LO testing.
- **GPU/etc. grid PDF implementation via KOKKOS**
Done by Max, to be made public.
- **5th order polynomials with fallback**
Based on Tushar's GSoC work.
VERSION 7.0.x
-------------
- **Restructure for greater use of vectorisation, GPUs, MPI, etc.?**
Requires very clear specification of use-cases from e.g. DISTRESS profiling,
NLO Sherpa HPC experience, etc.
- **Resolved photon PDFs and TMDs (requires higher-dimensional interpolation)**
AS AND WHEN
-----------
- **New Fortran API completeness**
Extrapolation, interpolation, and alpha_s control, and metadata & uncertainty functions in Fortran.
- **Add C++ SFINAE helpers for no-inheritance PDF interface definition**
We don't want LHAPDF to become a code dependency just to define what a "PDF object"
behaves like. Could using SFINAE template specialisation be a more hands-off route
than inheritance? These would probably just be examples, so in doc rather than code?
- **Handle zipped data 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 embed a zip-stream and link against zlib?
- **Make it possible to find all metadata keys -- both locally and cascaded (AB)**
- **.LHgrid etc. old-name-tolerance control -- TranslateLHA5Names flag?**
- **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?
- **Using std::function to generically modify the interpolation measures in x, Q (AB)**
- **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?
*/