<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 &rarr; 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} &lt; x &lt; 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 --> 
