Pythia class should
be used in the user-supplied main program, further outlined in the
following. Since the nature of the run is defined at the initialization
stage, this is where most of the PYTHIA user code has to be written.
So as not to confuse the reader unduly, the description of initialization
options has been subdivided into what would normally be used and what is
intended for more special applications.
#include "Pythia.h"
To simplify typing, it also makes sense to declare
using namespace Pythia8;
Pythia pythia;
It is this object that we will use from now on. Normally a run
will only contain one Pythia object. (Hypothetically
you could use several Pythia objects sequentially,
but if done in parallel the static character of some
program elements is likely not to give the desired behaviour.)Pythia will be on the
cout stream, but the list methods below do
allow output to alternative streams or files (by an optional
last argument, a reference to an ostream, usually not
explicitly written out here).
Pythia
constructor. The default values can then be changed, primarily
by one of the two ways below, or by a combination of them.
pythia.readString(string);
method provides a covenient uniform interface to all of them.
The information in the string is case-insensitive, but upper- and
lowercase can be combined for clarity. The rules are thatpythia.particleData.readString(string);pythia.settings.readString(string).false is used to
switch off warnings.
pythia.readString("111:mayDecay = false");
pythia.readString("TimeShower:pTmin = 1.0");
The readString(string) method is intended primarily for
a few changes. It can also be useful if you want to construct a
parser of input files that contain commands to several different
libraries.
pythia.readFile(fileName);
Each line in this file with be processes by the
readString(string) method introduced above. You can thus
freely mix comment lines and lines handed on to Settings
or to ParticleDataTable.
Again, an optional second argument false allows
you to switch off warning messages for unknown variables.readString(string), and can also avoid having to
recompile and relink your main program between runs.
init(...) method allows a few different input formats,
so you can pick the one convenient for you:pythia.init( idA, idB, eA, eB);pythia.init( idA, idB, eCM);pythia.init(fileName); pythia.init();Main
group of variables, which provides you with the same possibilities as
the above options a, b and c. If you don't change any of those you will
default to proton-proton collisions at 14 TeV, i.e. the nominal LHC
values.
pythia.init( LHAinit*, LHAevnt*); LHAinit class object, and that LHA event
information will be provided by the LHAevnt class object,
and that pointers to these objects are handed in
(further instructions).
pythia.settings.listChanged();
pythia.settings.listAll();
pythia.particleData.listChanged();
pythia.particleData.listAll();
next() method,
pythia.next();
This method takes no arguments; everything has already been specified.
It does return a bool value, however, false when the
generation failed. This can be a "programmed death" when the
supply of input parton-level configurations on file is exhausted,
but also caused by a failure of Pythia to generate an event,
or that an event was generated but something strange was detected
in it. It makes sense to allow a few false
values before a run is aborted, so long as the related faulty
events are skipped.
event
object, of type Event, which is a public member of
pythia. You therefore have access to all the tools described
on the pages under the "Study Output" header in the index. For instance,
an event can be listed with
pythia.event.list(), the identity of the i'th
particle is given by pythia.event[i].id(), and so on.process, also of type Event.info, which offers a set of
one-of-a kind pieces of information about the most recent event
(further information).
pythia.statistics();
to get some run statistics, on cross sections and the number of errors
and warnings encountered. With optional argument true
also further statistics is printed. Currently this means the number of
different subprocesses generated in the multiple-interactions
framework.
examples subdirectory. However, in the
general case, you must provide the path to the .xml files,
originally stored in the xmldoc directory, where default
settings and particle data are found. This can be done in two ways.
PYTHIA8DATA to
contain the location of the xmldoc directory. In the
csh and tcsh shells this could e.g. be
setenv PYTHIA8DATA /home/myname/pythia8095/xmldoc
while in other shells it could be
export PYTHIA8DATA=/home/myname/pythia8095/xmldoc
Recall that environment variables set locally are only defined in the
current instance of the shell. The above lines should go into your
.cshrc and .bashrc files, respectively,
if you want a more permanant assignment.
Pythia
constructor, e.g.
Pythia pythia("/home/myname/pythia8095/xmldoc");
PYTHIA8DATA is set it takes precedence, else
the path in the constructor is used, else one defaults to the
../xmldoc directory.
B) You can override the default behaviour of PYTHIA not only by the
settings and particle data, but also by replacing some of the
PYTHIA standard routines by ones of your own. Of course, this is only
possible if your routines fit into the general PYTHIA framework.
Therefore they must be coded according to the the rules relevant
in each case, as a derived class of a PYTHIA base class, and a pointer
to such an object must be handed in by one of the methods below.
These calls must be made before the pythia.init(...) call.
setPDFPtr(...) method
pythia.setPDFptr( pdfAPtr, pdfBPtr);
where pdfAPtr and pdfBPtr are pointers to
two Pythia PDF objects
(further instructions).
Note that pdfAPtr and pdfBPtr cannot point
to the same object; even if the PDF set is the same, two copies are
needed to keep track of two separate sets of x and density
values.
pythia.setPDFptr( pdfAPtr, pdfBPtr, pdfHardAPtr, pdfHardBPtr);
allows you to specify those separately, and then the first two sets
would only be used for the showers and for multiple interactions.
setDecayPtr(...)
method
pythia.setDecayPtr( decayHandlePtr, particles);
where the decayHandlePtr derives from the
DecayHandler base class and particles is a
vector of particle codes to be handled
(further instructions).
setRndmEnginePtr(...) method
pythia.setRndmEnginePtr( rndmEnginePtr);
where rndmEnginePtr derives from the RndmEngine
base class (further instructions).
The Pythia default random number generator is perfectly good,
so this is only intended for consistency in bigger frameworks.
pythia.setUserHooksPtr( userHooksPtr);
where userHooksPtr derives from the UserHooks
base class (further instructions).
pythia.setSigmaPtr( sigmaPtr);
where sigmaPtr of type SigmaProcess* is an
instance of a class derived from one of the Sigma1Process,
Sigma2Process and Sigma3Process base classes
(further instructions).
This call can be used repeatedly to hand in several different processes.
pythia.setShowerPtr( timesDecPtr, timesPtr, spacePtr);
where timesDecPtr and timesPtr
derive from the TimeShower base class, and
spacePtr from SpaceShower
(further instructions).
Pythia object in an executable
at any time. For multicore processors, if you want to use all cores,
the most efficient way presumably is to start correspondingly many jobs,
with different random number seeds, and add the statistics at the end.
As a consequence, it is not possible to generate signal and pileup
events simultaneously, by using one Pythia object for each.
Instead you may need to store events on disk, in two separate files,
and mix afterwards.
pythia object once for each subrun, in which case they are
completely separate. You can also use the same pythia object,
only doing a new init(...) call for each subrun. In that
case, the settings and particle databases remain as they were in the
previous subrun, only affected by the specific changes you introduced in
the meantime. You can put those changes in the main program, with
pythia.readString(string), using your own logic to decide
which ones to execute in which subrun. A corresponding possibility
exists with pythia.readFile(fileName, subrun), which
as second argument can take a non-negative subrun number. (Or,
alternatively use the longer form
pythia.readFile(fileName, warn, subrun).) Then only those
sections of the file before any Main:subrun = ... line
or with matching subrun number will be read. That is, the
file could have a structure like
( lines always read, i.e. "default values" always (re)set )
Main:subrun = 1
( lines only read with readFile(fileName, 1) )
Main:subrun = 2
( lines only read with readFile(fileName, 2) )
Both of these possibilities are illustrated in main08.cc.
pythia.init(fileName, skipInit).
Alternatively, the tag Main:LHEFskipInit can be put
in a file of commands to obtain the same effect.
Here skipInit defaults to false,
but if set true then the new file will be simulated
with the same initialization data as already set in a previous
pythia.init(...) call. The burden rests on you to ensure
that this is indeed correct, e.g. that the two event samples have not
been generated for different beam energies.