## 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

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 obtained with `Info::code()`, while the further subdivision given by `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 `pythia.stat()` output.

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.
returns the process name for process code `i`.
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.
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 `sigmaGen()` below.
normally 0, but if Les Houches events are input then it gives the event weighting strategy, see Les Houches Accord.

### Event Weight

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 filling histograms.
(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.)

### CKKW-L and NLO Merging Weights

combined leading-order merging weight assigned to the current event, if tree-level multi-jet merging (i.e. CKKW-L or 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 UMEPS Merging.
combined NLO merging weight assigned to the current event, if NLO multi-jet merging (i.e. NL3 or UNLOPS merging) is attempted. If NLO multi-jet merging is performed, all histograms should be filled with this weight, as discussed in NLO Merging.

Note that there are two schemes to handle the combination of merging weight and event weight. These can be selected by using the setting

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 printed by `Info::sigmaGen()` includes the effect of CKKW-L merging.

### User Hooks Weights

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 in the `selBias` member variable, such that this routine can return `1/selBias`. The weight is also returned by the `Info::weight()` method, which may be more convenient to use.
If you use enhanced emissions, it is paramount to attribute a corrective weight to each event containing enhanced emissions. This function returns this weight. In the presence of enhancements, all histograms and output events must account for this weight.

### 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 documentation.

The following methods give access to the groups of uncertainty weights:

returns the number of groups
returns the name of the iG-th group
returns the weight of the iG-th group

Correspondingly, the individual parameter-variation weights can also be accessed:

returns number of individual parameter-variation weights
name="string Info::weightLabel(int i)"> returns label of i-th individual parameter-variation weight
returns value of i-th indivudal parameter-variation weight

Note, `weight(0)` returns the same value as `weight()`, 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 `1` for the first up to `nWeights()` for 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 `HepMC2` and `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 LHE files, 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 `main44.cc` and `main45.cc` 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). Note that shower variations are treated as "atomic", meaning that individual variations are stored. Weight groups are currently not supported.
Returns the name of the i'th weight. For example, if "i" indexes a shower variation, this would e.g. return `fsr:muRfac=0.5` 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.
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.
Returns a vector of all weight names. The ordering of entries in synchronized with the order of `Info::weightValueVector()`.
Returns a vector of all weight values. The ordering of entries in synchronized with the order of `Info::weightNameVector()`.

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 `Info::weightNameByIndex` and `Info::weightNameVector` 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 `AUX_` weights.

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 remain.