Automated Variations of Shower Parameters for Uncertainty Bands

While a number of different central "tunes" of the Pythia parameters are provided, it is often desired to study how event properties change when some of the parameters (such as those describing the parton showers) are varied. Pythia8 now has the ability to provide a series of weights to reflect the change in probability for a particular final state to occur when a subset of parton-shower parameters are varied. Details on the implementation and interpretation of these weights can be found in [Mre16]. Currently, the list of available automated variations (see full list below) includes: Similar variations would be possible for QED emissions, but these have not yet been implemented.

Since the computation of the uncertainty variations takes additional CPU time (albeit much less than would be required for independent runs with the equivalent variations), the automated uncertainty variations are switched off by default.

flag  UncertaintyBands:doVariations   (default = off)
Master switch to perform variations.

The main intended purpose of these variations is to estimate perturbative uncertainties associated with the parton showers. Due to the pole at LambdaQCD, however, branchings near the perturbative cutoff can nominally result in very large reweighting factors, which is unwanted for typical applications. We therefore enable to limit the absolute (plus/minus) magnitude by which alphaS is allowed to vary by

parm  UncertaintyBands:deltaAlphaSmax   (default = 0.2; minimum = 0.0; maximum = 1.0)
The allowed range of variation of alphaS, interpreted as abs(alphaSprime - alphaS) < deltaAlphaSmax.

Likewise, non-singular-term variations are mainly intended to capture uncertainties related to missing higher-order tree-level matrix elements and are hence normally uninteresting for very soft branchings. The following parameter allows to switch off the variations of non-singular terms below a fixed perturbative threshold:

parm  UncertaintyBands:cNSpTmin   (default = 5.0; minimum = 0.0; maximum = 20.0)
Variations of non-singular terms will not be performed for branchings occurring below this threshold.

By default, the automated shower uncertainty variations are enabled for the showers off the hardest interaction (and associated resonance decays), but not for the showers off MPI systems which would be more properly labeled as underlying-event uncertainties. If desired, the variations can be applied also to showers off MPI systems via the following switch:

flag  UncertaintyBands:MPIshowers   (default = off)
Flag specifying whether the automated shower variations include showers off MPI systems or not. Note that substantially larger weight fluctuations must be expected when including shower variations for MPI, due to the (many) more systems which then enter in the reweightings.

UserHooks Warning: the calculation of uncertainty variations will only be consistent in the absence of any external modifications to the shower branching probabilities via the UserHooks framework. It is therefore strongly advised to avoid combining the automated uncertainty calculations with any such UserHooks modifications.

Merging Warning: in multi-jet merging approaches, trial showers are used to generate missing Sudakov factor corrections to the hard matrix elements. Currently that framework is not consistently combined with the variations introduced here, so the two should not be used simultaneously. This restriction will be lifted in a future release.

Specifying the Variations

When UncertaintyBands:doVariations is switched on, the user can define an arbitrary number of (combinations of) uncertainty variations to perform. Each variation is defined by a string with the following generic format: 
 
    Label keyword1=value keyword2=value ...
where the user has complete freedom to specify the label, and each keyword must be selected from the list of currently recognised keywords below. Instead of an equal sign it is also possible to leave a blank between a keyword and its value.

To exemplify, an uncertainty variation corresponding to simultaneously increasing both the ISR and FSR renormalisation scales by a factor of two would be defined as follows 

 
    myVariation1 fsr:muRfac=2.0 isr:muRfac=2.0

Staying within the context of this example, the user might also want to check what a variation of the two scales independently of each other would produce. This can be achieved within the same run by adding two further variations, as follows: 

 
    myVariation2 fsr:muRfac=2.0 
    myVariation3 isr:muRfac=2.0
Different histograms can then be filled with each set of weights as desired (see accessing the uncertainty weights below). Variations by smaller or larger factors can obviously also be added in the same way, again within one and the same run.

Once a list of variations defined as above has been decided on, the whole list should be passed to Pythia in the form of a single "vector of strings", defined as follows:

wvec  UncertaintyBands:List   (default = {alphaShi fsr:muRfac=0.5 isr:muRfac=0.5, alphaSlo fsr:muRfac=2.0 isr:muRfac=2.0, hardHi fsr:cNS=2.0 isr:cNS=2.0, hardLo fsr:cNS=-2.0 isr:cNS=-2.0})
Vector of uncertainty-variation strings defining which variations will be calculated by Pythia whenUncertaintyBands:doVariations is switched on.

For completeness, we note that a command-file specification equivalent to the above default variations could look as follows: 

 
    UncertaintyBands:List = { 
        alphaShi fsr:muRfac=0.5 isr:muRfac=0.5, 
        alphaSlo fsr:muRfac=2.0 isr:muRfac=2.0, 
        hardHi fsr:cNS=2.0 isr:cNS=2.0, 
        hardLo fsr:cNS=-2.0 isr:cNS=-2.0 
    }
Note that each of the individual uncertainty-variation definitions (the elements of the vector) are separated by commas and that keywords separated only by spaces are interpreted as belonging to a single combined variation. Note also that the beginning and end of the vector is marked by curly braces.

Accessing the Uncertainty Weights

During the event generation, uncertainty weights will be calculated for each variation defined above, via the method described in [Mre16]. The resulting alternative weights for the event are accessible through the Pythia::info.weight(int iWeight=0) method.

The baseline weight for each event (normally unity for an ordinary unweighted event sample) is not modified and corresponds to iWeight = 0. The uncertainty-variation weights are thus enumerated starting from iWeight = 1 for the first variation up to N for the last variation, in the order they were specified in UncertaintyBands:List.

The total number of variations that have been defined, N, can be queried using Pythia::info.nWeights().

NLO Compensation Term for Renormalisation-Scale Variations

Additionally, there is a run-time parameter:

flag  UncertaintyBands:muSoftCorr   (default = on)
This flags tells the shower to apply an O(αS2) compensation term to the renormalization-scale variations, which reduces their magnitude for soft emissions, as described in [Mre16].

List of Recognised Keywords for Uncertainty Variations

The following keywords adjust the renormalisation scales and non-singular terms for all FSR and ISR branchings, respectively: Note that the muRfac parameters are applied linearly to the renormalisation scale, hence μ2 → (muRfac)2*μ2.

Optionally, a further level of detail can be accessed by specifying variations for specific types of branchings, with the global keywords above corresponding to setting the same value for all branchings. Using the fsr:muRfac parameter for illustration, the individual branching types that can be specified are:

For the distinction between Q2QG and X2XG, the following switch can be used to control whether b and t quarks are considered to be Q or X particles (e.g. providing a simple way to control top-quark or bottom-quark radiation independently of the rest of the shower uncertainties):

mode  UncertaintyBands:nFlavQ   (default = 6; minimum = 2; maximum = 6)
Number of quark flavours controlled via Q2QG keywords, with higher ID codes controlled by X2XG keywords. Thus a change to 5 would mean that top-quark variations would use X2XG keyword values instead of the corresponding Q2QG ones.