<chapter name="Parton Distributions"> <h2>Parton Distributions</h2> The parton distributions file contains the <code>PDF</code> class. <code>PDF</code> is the base class, from which specific <code>PDF</code> classes are derived. <p/> The choice of which PDF to use is made by settings in the <code>Pythia</code> class, see <aloc href="PDFSelection">here</aloc>. These settings also allow to access all the proton PDF's available in the LHAPDF library <ref>Wha05</ref>. Thus there is no need for a normal user to study the <code>PDF</code> class. The structure must only be understood when interfacing new PDF's, e.g. ones not yet found in LHAPDF. <h3>The PDF base class</h3> <code>PDF</code> defines the interface that all PDF classes should respect. The constructor requires the incoming beam species to be given: even if used for a proton PDF, one needs to know whether the beam is actually an antiproton. This is one of the reasons why <code>Pythia</code> always defines two PDF objects in an event, one for each beam. <p/> Once a <code>PDF</code> object has been constructed, call it <code>pdf</code>, the main method is <code>pdf.xf( id, x, Q2)</code>, which returns <ei>x*f_id(x, Q2)</ei>, properly taking into account whether the beam is an antiparticle or not. <p/> Whenever the <code>xf</code> member is called with a new flavour, <ei>x</ei> or <ei>Q^2</ei>, the <code>xfUpdate</code> member is called to do the actual updating. This routine may either update that particular flavour or all flavours at this <ei>(x, Q^2)</ei> point. (In the latter case the saved <code>id</code> value <code>idSav</code> should be set to 9.) The choice is to be made by the producer of a given set, based on what he/she deems most effective, given that sometimes only one flavour need be evaluated, and about equally often all flavours are needed at the same <ei>x</ei> and <ei>Q^2</ei>. Anyway, the latest value is always kept in memory. This is the other reason why <code>Pythia</code> has one separate <code>PDF</code> object for each beam, so that values at different <ei>x</ei> can be kept in memory. <p/> Two further public methods are <code>xfVal( id, x, Q2)</code> and <code>xfSea( id, x, Q2)</code>. These are simple variants whereby the quark distributions can be subdivided into a valence and a sea part. If these are not directly accessible in the parametrization, one can make the simplified choices <ei>u_sea = ubar_sea, u_val = u_tot - u_sea</ei>, and correspondingly for <ei>d</ei>. (Positivity will always be guaranteed at output.) The <code>xfUpdate</code> method should also take care of updating this information. <p/> A method <code>setExtrapolate(bool)</code> allows you to switch between freezing parametrizations at the <ei>x</ei> and <ei>Q^2</ei> boundaries (<code>false</code>) or extrapolating them outside the boundaries (<code>true</code>). This method is only implemented for the LHAPDF class below. If you implement a new PDF you are free to use this method, but it would be smarter to hardcode the desired limiting behaviour. <h3>Derived classes</h3> There is only one pure virtual method, <code>xfUpdate</code>, that therefore must be implemented in any derived class. A reasonable number of such classes come with the program: <p/> For protons: <ul> <li><code>LHAPDFinterface</code> provides an interface to the LHAPDF library<ref>Wha05</ref>.</li> <li><code>GRV94L</code> gives the GRV 94 L parametrization <ref>Glu95</ref>.</li> <li><code>CTEQ5L</code> gives the CTEQ 5 L parametrization <ref>Lai00</ref>.</li> <li><code>MSTWpdf</code> gives the four distributions of the MRST/MSTW group that have been implemented.</li> <li><code>CTEQ6pdf</code> gives the six distributions of the CTEQ/CT group that have been implemented.</li> <li><code>NNPDF</code> gives four distributions from the NNPDF 2.3 QCD+QED sets that have been implemented.</li> </ul> The current default is CTEQ 5L, which has been used in most studies to date. <p/> For charged pions: <ul> <li><code>GRVpiL</code> gives the GRV 1992 pi+ parametrization.</li> </ul> <p/> For Pomerons (used to describe diffraction): <ul> <li><code>PomFix</code> gives a simple but flexible <ei>Q2</ei>-independent parametrization.</li> <li><code>PomH1FitAB</code> gives the H1 2006 Fit A and Fit B parametrizations.</li> <li><code>PomH1Jets</code> gives the H1 2007 Jets parametrization.</li> </ul> <p/> For charged leptons (e, mu, tau): <ul> <li><code>Lepton</code> gives a QED parametrization <ref>Kle89</ref>. In QED there are not so many ambiguities, so here one set should be enough. On the other hand, there is the problem that the lepton-inside-lepton pdf is integrably divergent for <ei>x → 1</ei>, which gives numerical problems. Like in PYTHIA 6, the pdf is therefore made to vanish for <ei>x > 1 - 10^{-10}</ei>, and scaled up in the range <ei>1 - 10^{-7} < x < 1 - 10^{-10}</ei> in such a way that the total area under the pdf is preserved.</li> <li><code>LeptonPoint</code> gives the trivial distribution of a pointlike (i.e. unresolved) charged lepton.</li> </ul> <p/> For neutrinos: <ul> <li><code>NeutrinoPoint</code> is the only method, so there is no choice. Analogously to <code>LeptonPoint</code> it gives the distribution of a pointlike (i.e. unresolved) neutrino. A difference, however, is that neutrinos always are lefthanded, so there is no need to average over incoming spin states. Since the PYTHIA formalism assumes unpolarized beams, and thus implicitly includes a 1/2 for incoming fermions, the <code>NeutrinoPoint</code> PDF is normalized to 2 rather than 1 to compensate for this.</li> </ul> <p/> There is another method, <code>isSetup()</code>, that returns the base-class boolean variable <code>isSet</code>. This variable is initially <code>true</code>, but could be set <code>false</code> if the setup procedure of a PDF failed, e.g. if the user has chosen an unknown PDF set. <p/> The MRST/MSTW, CTEQ/CT, NNPDF and H1 PDF routines are based on the interpolation in <ei>(x, Q)</ei> grids. The grid files are stored in the <code>xmldoc</code> subdirectory, like settings and particle data. Only PDF sets that will be used are read in during the initialization stage. </chapter> <!-- Copyright (C) 2014 Torbjorn Sjostrand -->