132 Page 4 of 20 Eur. Phys. J. C (2015) 75 :132
use in multi-threaded applications: this greatly restricts its
scalability in the current multi-core computing era.
2.2 Correctness problems
The last set of problems with LHAPDF 5 relate, concern-
ingly, to the correctness of the output. For example different
generations of PDF fit families share the same interpolation
code, although they may have different ranges of validity in
x–Q phase space, and wrong ranges are sometimes reported.
The reporting of
QCD
and other metadata has also been
problematic, to the extent that PYTHIA 6’s many tunes
depend on LHAPDF returning a nonsense value which is
then reset to the default of 0.192 GeV. Since the multiset
mode is often only implemented as a multiplying factor on
the size and indexing offsets, reported values of metadata
such as α
S
and x & Q boundaries do not always correspond
to the currently active PDF slot, but rather to properties of
the last set to have been initialised.
2.3 Maintainability problems
Aside from the technical issues discussed above, the design of
LHAPDF 5 (and earlier versions) tightly couples PDF avail-
ability to the release cycle of the LHAPDF code library –
as in PDFLIB. As PDF fitting has become more diverse,
with many different groups releasing PDF fits in response to
new LHC and other data, the mismatch of the slow software
releases (typically two releases per year) and the faster, less
predictable release rate of new PDF sets has become evident.
It is neither desirable for new PDF data to have to wait for
months before becoming publicly available via an LHAPDF
release, nor for experiments and other users to be deluged
with new software versions to be installed and tested.
In addition, since adding new PDFs involved interfacing
external Fortran code via “wrapper” routines, it both required
significant coding and testing work from the LHAPDF main-
tainers, and blocked PDF fitting groups from using lan-
guages other than Fortran for their fitting/interpolation codes.
The (partial) sharing of wrapper routines between some sets
which did not provide their own interpolation code made
any changes to existing wrapper code dangerous and fragile.
An attempt was made to make it easier for users to make
custom PDFs by using one of three generic set names to trig-
ger a polynomial spline interpolation, but this was also very
restricted in functionality and saw minimal use.
A final logistical issue was the lack of version tracking
in PDF data files, which would periodically be found to be
buggy, and no way to indicate which versions of the LHAPDF
library were required to use a particular PDF. This led to some
problems where for space-saving reasons PDF data would be
shared between different versions of the library, producing
unintended numerical changes and potentially introducing
buggy outputs from previously functional installations.
2.4 Summary of LHAPDF 5 issues
Many of the problems of LHAPDF 5 stem from the combi-
nation of the static nature of Fortran memory handling and
from the way that evolving user demands on LHAPDF forced
retro-fitting of features such as grid interpolation and multiset
mode on to a system not originally designed to incorporate
them. These have combined with more logistical features
such as the lack of any versioned connection between the
PDF data files and the library, the menagerie of interpola-
tion grid formats, and the need to modify the library to use
a new PDF to make LHAPDF 5 difficult both to use and to
maintain. These issues became critical during Run 1 of the
LHC, leading to the development of LHAPDF 6 to deal with
the increased demands on parton density usage in Run2 and
beyond. Version 5.9.1 of LHAPDF was the last in the For-
tran series; all new development and maintenance (including
provision of new PDF sets) is restricted to LHAPDF 6 only.
3 Design of LHAPDF 6
LHAPDF 6 is a ground-up redesign and re-implementation
of the LHAPDF system, specifically to address all the above
problems of the Fortran LHAPDF versions. As so many of
these problems fundamentally stem from Fortran(77) static
memory limitations, and the bulk of new experimental and
event generator code is written in C++, we have also chosen
to write the new LHAPDF 6 in object oriented C++. Since
the Python scripting language has also become widely used
in high-energy physics, we also provide a Python interface to
the C++ LHAPDF library, which can be particularly useful
for interactive PDF testing and exploration.
3.1 PDF value access
The central code/design object in LHAPDF 6 is the
PDF,an
interface class representing parton density functions for sev-
eral parton flavours, typically but not necessarily the gluon
plus the lightest 5 quark (and anti-quark) flavours. An extra
object,
PDFSet is provided purely for (significant) conve-
nience in accessing PDF set metadata and all the mem-
bers in the set, e.g. for making systematic variations within
a set. The set level of data grouping is unavoidable, even
in the case of single-member sets, and a list of all avail-
able PDF sets on the user’s system can be obtained via
the
LHAPDF::availablePDFSets() function. There is no
LHAPDF 6 user-interface type to represent a single-flavour
parton density.
Unlike in LHAPDF 5, where a few PDFs included a parton
density for a non-standard flavour such as a photon or gluino
123