forked from PMunkes/LHAPDF
-
Notifications
You must be signed in to change notification settings - Fork 1
/
TODO
187 lines (106 loc) · 6.07 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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
/**
@page todolist Project to-do list
LHAPDF6 TODO list
=================
UNVERSIONED
-----------
- **Document the lhapdf command**
On the website
- **HERA 1.0 and LHeC PDF migration and approval**
Same procedure as for ATLAS and HERA 1.5. Prod Voica for an update.
- **nCTEQ15 PDFs**
- **PDF4LHC15 Nf=4**
VERSION 6.1.7
-------------
- **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.
- **Check LHAGlue getthresholdm_ etc.**
- **Consider extrapolated cubic splines at subgrid edges (cf. Valerio Berton et al)**
- **Remove #pragma once -- it's not fully portable**
- **Make it possible to find all metadata keys -- both locally and cascaded (AB)**
- **.LHgrid etc. old-name-tolerance control -- TranslateLHA5Names flag?**
- **Add an lhapdf show command**
To print pdfsets.index + cat .info for already installed PDFs.
VERSION 6.2
-----------
- **Nuclear 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?
- **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.
- **Provide a nicer Fortran interface?**
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: require nset and nmem args for *all* commands, i.e. no "current" set slot.
Requests: way to get LHAPDF ID from current set/PDF.
VERSION 6.3
-----------
- **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.
- **Remove remaining Boost dependencies / move to C++11 (AB)**
Boost was being more trouble than it was worth, but maybe now that we're not
using the filesystem stuff it is ok. Full removal would require several changes:
- multiarray: replace with Martin's array/SSE code
- foreach: iterators or require C++11
- lexical_cast: stringstream wrappers to_str, from_str (and C++11)
- shared_ptr: manual deletes or require C++11
- bind: C++11 or something less cool
Actually this would be rather good, but requires C++11 which is not an option
just yet.
AS AND WHEN
-----------
- **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? Add instructions for that to manual/website.
- **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::/boost::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?
*/