Cross Sections and Weights
Although Pythia's baseline setup is for generating sets of fully
unweighted events (each representing an equal fraction of the total
generated cross section), some options and interfaces
allow for, and even mandate, generation of weighted events.
Methods related to retrieving both the integrated cross sections
computed by Pythia as well as various kinds of event weights are
collected on this page.
- Cross Sections and Weight Sums
- Event Weight
- CKKW-L and NLO Merging Weights
- User Hooks Weight
- Shower Uncertainty-Variation Weights
- The Weight Container
Cross Sections and Weight Sums
Here are the currently available methods related to the event sample
as a whole, for the default value
i = 0, and otherwise for
the specific process code provided as argument. This is the number
Info::code(), while the further subdivision
Info::codeSub() is not bookkept. While continuously
updated during the run, it is recommended only to study these properties
at the end of the event generation, when the full statistics is available.
The individual process results are not available if
a second hard process has been
chosen, but can be gleaned from the
returns a vector with all the process codes set up for the current run,
i.e. the valid nonzero arguments for the five methods below.
string Info::nameProc(int i = 0)
returns the process name for process code
long Info::nTried(int i = 0)
long Info::nSelected(int i = 0)
long Info::nAccepted(int i = 0)
the total number of tried phase-space points, selected hard processes
and finally accepted events, summed over all allowed processes
i = 0) or for the given process.
The first number is only intended for a study of the phase-space selection
efficiency. The last two numbers usually only disagree if the user introduces
some veto during the event-generation process; then the former is the number
of acceptable events found by PYTHIA and the latter the number that also
were approved by the user. If you set a
second hard process there may also be a mismatch.
double Info::sigmaGen(int i = 0)
double Info::sigmaErr(int i = 0)
the estimated cross section and its estimated error,
summed over all allowed processes (
i = 0) or for the given
process, in units of mb. The numbers refer to the accepted event sample
above, i.e. after any user veto.
Sum of weights accumulated during the run. For unweighted events this
agrees with the number of generated events. In order to obtain
histograms normalized "per event", at the end of a run, histogram
contents should be divided by this weight. (And additionally
divided by the bin width.) Normalization to cross section also
required multiplication by
normally 0, but if Les Houches events are input then it gives the
event weighting strategy, see
Les Houches Accord.
weight assigned to the current event. Is normally 1 and thus
uninteresting. However, there are several cases where one may have
nontrivial event weights. These weights must the be used e.g. when
(i) In the
PhaseSpace:increaseMaximum = off default strategy,
an event with a differential cross-section above the assumed one
(in a given phase-space point) is assigned a weight correspondingly
above unity. This should happen only very rarely, if at all, and so
could normally be disregarded.
(ii) The User Hooks class offers
the possibility to bias the selection of phase space points, which
means that events come with a compensating weight, stored here.
(iii) For Les Houches events some strategies allow negative weights,
which then after unweighting lead to events with weight -1. There are
also Les Houches strategies where no unweighting is done, so events
come with a weight. Specifically, for strategies +4 and
-4, the event weight is in units of pb. (Internally in mb,
but converted at output.)
(iv) If enhanced parton shower emissions are activated, the corrective
weight to each event containing enhanced emissions is included here.
CKKW-L and NLO Merging Weights
combined leading-order merging weight assigned to the current event, if
tree-level multi-jet merging (i.e.
UMEPS merging) is attempted.
If tree-level multi-jet merging is performed, all histograms should be
filled with this weight, as discussed in
CKKW-L Merging and
combined NLO merging weight assigned to the current event, if
NLO multi-jet merging (i.e.
UNLOPS merging) is attempted.
If NLO multi-jet merging is performed, all histograms should be filled
with this weight, as discussed in
Note that there are two schemes to handle the combination of merging
weight and event weight. These can be selected by using the setting
default = on)
If on, then the reweighting of events in the CKKW-L scheme is included
in the event weight
Info::weight(), the merging weight
Info:mergingWeight() is unity, and the cross section
Info::sigmaGen() includes the effect of CKKW-L
User Hooks Weight
virtual double UserHooks::biasedSelectionWeight()
Returns the weight you should assign to the event, to use e.g. when
you histogram results. It is the exact inverse of the weight you
used to modify the phase-space sampling, a weight that must be stored
selBias member variable, such that this routine
1/selBias. The weight is also returned by the
Info::weight() method, which may be more convenient to use.
Shower Uncertainty-Variation Weights
As discussed in the sections on Parton Showers, the user can
request Pythia to compute (sets of) alternative event weights
representing (groups of) variations of shower parameters.
See [Mre16] and the page on
Automated Variations for further
The following methods give access to the groups of uncertainty weights:
returns the number of groups
string Info::getGroupName(int iG)
returns the name of the iG-th group
double Info::getGroupWeight(int iG)
returns the weight of the iG-th group
Correspondingly, the individual parameter-variation weights can also
returns number of individual parameter-variation weights
string Info::weightLabel(int i)
returns label of i-th individual parameter-variation weight
double Info::weight(int i)
returns value of i-th indivudal parameter-variation weight
weight(0) returns the same value as
which is the baseline weight for each event (normally unity for an
ordinary unweighted event sample). The individual parameter-variation
weights are thus enumerated starting from
the first up to
the last individual parameter variation.
The Weight Container
In the long run, we plan to consolidate all possible weights into
one structure with a simple getter for the user. This strategy
is currently used when producing
HepMC3 output. In these two cases, all weights
that appear in the event generation will automatically be
transferred to the output files. This means that the HepMC file will
automatically contain weights from various sources, e.g. weights from
automated shower variations, etc. Note that
for LHEF files, only the detailed format is currently
supported in the weight container, and that the names of weights
appearing in HepMC will use the convention discussed in
[But14], page 162. The sample main programs
illustrate this behaviour.
In this context, the following program methods are relevant:
The total length of the set of all weights, similar to
Info::nWeights above (which returns the length of the set
of shower variation weights).
string Info::weightNameByIndex(int i)
Returns the name of the i'th weight. For example, if "i" indexes a
shower variation, this would e.g. return
and so on. If "i" pertains to a weight read from an input LHEF file
(see Les Houches Event Files for further
details), then the name will be returned in the convention discussed
in [But14], page 162. These latter names are constructed from
the content of the "<weight>" tags in the LHE file header.
double Info::weightValueByIndex(int i)
Returns the value of the i'th weight. The normalization of all weights
is synchronized. For unweighted event generation (as would be the case
when running stand-alone, of for LHEFs employing weight strategy 3),
the value is relative to the cross section. For weighted events
(e.g. when using LHEFs employing weight strategy +-4), the value will
include the cross section prefactor.
main44.cc gives an
example for both these cases.
vector <string> Info::weightNameVector() const
Returns a vector of all weight names. The ordering of entries in synchronized
with the order of
vector <double> Info::weightValueVector() const
Returns a vector of all weight values. The ordering of entries in synchronized
with the order of
Custom weights such as shower variations weights, shower variation group
weights, and weights directly included from LHEF input receive an
AUX_ prefix in the weight name as reported by the methods
to mark them as auxiliary output. This allows the user to further process or
combine the weights in a meaningful way. Since the number of these weights
depends on the LHEF input, different numbers of weights might occur in the
output when processing multiple LHEF input files. To avoid this, the following
flag allows to suppress the output of
default = off)
If on, the output of weights with
AUX prefix will be
suppressed in the five above mentioned methods. The nominal weight and
combined weight variations from LHEF, parton shower and merging