## Phase Space Cuts

`PhaseSpace` is base class for all hard-process phase-space generators, either generic 2 → 1 or 2 → 2 ones, or specialized ones like for elastic and diffractive scattering.

In it, it is possible to constrain the kinematics of most processes. (Exceptions are "soft physics", i.e. minimum bias, elastic and diffractive processes. The Coulomb singularity for elastic scatterings, if simulated, is handled separately.) These constraints apply in the rest frame of the hard subprocess, and topologies normally would be changed e.g. by subsequent showering activity. The cross section of a process is adjusted to only correspond to the allowed phase space.

The more particles in the final state, the more cuts could be applied. Here we have tried to remain with the useful minimum, however. More generic possibilities could be handled by the user hooks facility.

### Cuts in all processes

`parm` PhaseSpace:mHatMin (`default = 4.`; `minimum = 0.`)
The minimum invariant mass.

`parm` PhaseSpace:mHatMax (`default = -1.`)
The maximum invariant mass. A value below `mHatMin` means there is no upper limit.

### Cuts in 2 → 1 processes

When a resonance `id` is produced, the `mMin(id)` and `mMax(id)` methods restrict the allowed mass range of this resonance. Therefore the allowed range is chosen to be the overlap of this range and the `mHatMin` to `mHatMax` range above. Most resonances by default have no upper mass limit, so effects mainly concern the lower limit. Should there be no overlap between the two ranges then the process will be switched off.

### Cuts in 2 → 2 processes

`parm` PhaseSpace:pTHatMin (`default = 0.`; `minimum = 0.`)
The minimum invariant pT.

`parm` PhaseSpace:pTHatMax (`default = -1.`)
The maximum invariant pT. A value below `pTHatMin` means there is no upper limit.

`parm` PhaseSpace:pTHatMinDiverge (`default = 1.`; `minimum = 0.5`)
Extra pT cut to avoid the divergences of some processes in the limit pT → 0. Specifically, if either or both produced particles have a mass below `pTHatMinDiverge` then pT is limited from below by the larger of `pTHatMin` and `pTHatMinDiverge`.

`flag` PhaseSpace:useBreitWigners (`default = on`)
Allows masses to be selected according to Breit-Wigner shapes in 2 → 2 processes, whenever particles have been declared with a nonvanishing width above the threshold below. In those cases also the limits below will be used for the mass selection. For 2 → 1 processes the Breit-Wigner shape is part of the cross section itself, and therefore always included.

`parm` PhaseSpace:minWidthBreitWigners (`default = 0.01`; `minimum = 1e-6`)
The minimum width a resonance must have for the mass to be dynamically selected according to a Breit-Wigner shape, within the limits set below. The Breit-Wigner shape is deformed by the variation of the cross section across the peak. Only applies when `useBreitWigners` is on; else the nominal mass value is always used.

`parm` PhaseSpace:minWidthNarrowBW (`default = 1e-6`; `minimum = 1e-10`)
A particle that is not wide enough to qualify for the dynamical mass generation above can still qualify for a simplified treatment if it has a width above this value. Then the mass is selected according to a simple symmetric Breit-Wigner that will not be (significantly) distorted by the cross section variation. Only applies when `useBreitWigners` is on; else the nominal mass value is always used. Note that this parameter is also used for mass selection in the MPI machinery.

For a particle with a Breit-Wigner shape selected, according to the rules above and to the rules of the particle species itself, the `mMin(id)` and `mMax(id)` methods restrict the allowed mass range of the particle, just like for the 2 → 1 processes.

`parm` PhaseSpace:Q2Min (`default = 0.0`; `minimum = 0.0`)
The minimum value for the DIS variable Q^2 = - tHat. Can only meaningfully be used for scattering processes between two non-identical particles, i.e. where tHat and uHat are experimentally distinguishable. No cut will be applied for `Q2Min < pTHatMinDiverge^2`.

### Cuts in 2 → 3 processes

There are two main classes of 2 → 3 processes. One is the processes such as WW/ZZ-fusion Higgs production, i.e. q q → q q H, where there are no special singularities associated with two partons in the final state being collinear, or even for pT → 0. For this class, no further cuts have been introduced than those already available for 2 → 2 processes. Specifically, for now all three are restricted exactly the same way by `pTHatMin` and `pTHatMax`. As above, Breit-Wigner mass ranges can be restricted.

The other 2 → 3 event class is QCD processes, such as g g → g g g. Here the soft and collinear singularities play a major role, and the phase space generation and cuts have been adapted to this. For this class, an alternative set of cuts is used, as outlined in the following. First of all the three outgoing partons are ordered in falling pT, i.e. pT_3 > pT_4 > pT_5 (where the labeling 3, 4, 5 of the outgoing partons is random, i.e. unrelated to the order specified in the process name). The allowed ranges of pT_3 and pT_5 can be specified, but obviously pT_3max >= pT_5max and pT_3min >= pT_5min. The pT_4 is not constrained explicitly, but is constructed from the vector sum of pT_3 and pT_5, subject to the constraint that it has to lie between the two in magnitude. While the pT cuts take care of singularities collinear with the incoming beams, it is also necessary to handle final-state singularities, when two outgoing partons become collinear. This is done by requiring a minimal separation in R, where R^2 = (Delta eta)^2 + (Delta phi)^2. Finally, a note about efficiency. The QCD 2 → 3 phase space is not set up to explicitly include mHat as one of the basic variables. Such a cut is only done after a phase space point is already selected, which means that a narrow mass choice will slow down the program appreciably. Also narrow pT_3 and pT_5 bins are likely to give inefficient generation, if it gives rise to significant indirect restrictions on pT_4.

`parm` PhaseSpace:pTHat3Min (`default = 10.`; `minimum = 0.`)
The minimum invariant pT of the highest-pT parton in QCD 2 → 3 processes.

`parm` PhaseSpace:pTHat3Max (`default = -1.`)
The maximum invariant pT of the highest-pT parton in QCD 2 → 3 processes A value below `pTHat3Min` means there is no upper limit.

`parm` PhaseSpace:pTHat5Min (`default = 10.`; `minimum = 0.`)
The minimum invariant pT of the lowest-pT parton in QCD 2 → 3 processes.

`parm` PhaseSpace:pTHat5Max (`default = -1.`)
The maximum invariant pT of the lowest-pT parton in QCD 2 → 3 processes A value below `pTHat5Min` means there is no upper limit.

`parm` PhaseSpace:RsepMin (`default = 1.`)
The minimum separation R in (eta, phi) space between any two outgoing partons in QCD 2 → 3 processes.

### Cuts for a second hard process

If you use the machinery that allows the generation of a specified second hard process then, by default, the same phase space cuts will be used for it as listed above. Optionally, however, you may use a second set of cuts, as described here. In this context "first" and "second" is merely a technical distinction; you are welcome e.g. to pick pT ranges such that the second interaction always has a larger pT than the first.

`flag` PhaseSpace:sameForSecond (`default = on`)
By default use the same cuts for a second hard process as for the first. If `off` then instead use the mass and pT cuts below, where relevant. (The other cuts above still remain the same.)

`parm` PhaseSpace:mHatMinSecond (`default = 4.`; `minimum = 0.`)
The minimum invariant mass for a second interaction, if separate.

`parm` PhaseSpace:mHatMaxSecond (`default = -1.`)
The maximum invariant mass for a second interaction, if separate. A value below `mHatMin` means there is no upper limit.

`parm` PhaseSpace:pTHatMinSecond (`default = 0.`; `minimum = 0.`)
The minimum invariant pT for a second interaction, if separate.

`parm` PhaseSpace:pTHatMaxSecond (`default = -1.`)
The maximum invariant pT for a second interaction, if separate. A value below `pTHatMin` means there is no upper limit.

### Generation strategy and documentation

During the initialization stage a simplified function is found, that is intended to be above the true cross-section behaviour over the whole of phase space. It is chosen to be easily integrable and invertible. That way a trial phase space point can be selected according this simple function, and then be accepted by the ratio of true to the simple function. For a good efficiency the ratio should be close to unity, yet never above it. This constrains the absolute normalization of the simple function. The initial search may fail to find the phase space point where the true-to-simple ratio is maximal, however. This then can lead to subsequent maximum violations, where the ratio is above unity. Two alternative strategies are implemented to handle such situations, see below.

`flag` PhaseSpace:showSearch (`default = off`)
Possibility to print information on the search for phase-space coefficients that (in a multichannel approach) provides an analytical upper envelope of the differential cross section, and the corresponding upper estimate of the cross section. Of interest for crosschecks by expert users only.

`flag` PhaseSpace:showViolation (`default = off`)
Possibility to print information whenever the assumed maximum differential cross section of a process is violated, i.e. when the initial maximization procedure did not find the true maximum. Also, should negative cross sections occur, print whenever a more negative value is encountered.

`flag` PhaseSpace:increaseMaximum (`default = off`)
Strategy for handling cases where a larger cross section is obtained during the event generation than was assumed at initialization, i.e. when a violation occurs.
off:each event comes with a weight, which normally is unity (as a consequence of the acceptance/rejection step), and is found in `Info::weight()`. For events which exceed the maximum instead the true-to-simple ratio is stored as event weight, which then is above unity. If the user so wishes this weight can then be carried along when event properties are histogrammed. Since normally such violations should be rare and not too much above unity one could expect most users to ignore such issues be default. Should maximum violations turn out to be frequent (visible in the `Pythia::stat()` output) the option exists to use the information.
on:the maximum is increased whenever it is exceeded. Thus events generated after this point will be "correctly" distributed, while ones generated previously obviously then have had too high a relative weight. If violations occur early on and/or are small this strategy should do a good job of correcting to the desired phase-space distribution. This strategy may be more convenient for the normal user, who would not wish to worry about event weights. It does have the disadvantage that the raised maximum introduces an extra amount of "history memory" to the generation sequence, so that it becomes less easy to save-and-restore the random-number state for debugging purposes.

### Reweighting of 2 → 2 processes

Events normally come with unit weight, i.e. are distributed across the allowed phase space region according to the appropriate differential cross sections. Sometimes it may be convenient to have an uneven distribution of events. The classical example here is that many cross sections drop off with transverse momentum pT, such that few events are generated at large pT scales. If one wants to plot the pT cross section, and all that comes with it, the statistical error will then degrade with increasing pT where fewer events end up.

One solution is to split the full pT range into several separate subranges, where the events of each subsample obtains a different overall normalization. Specifically, if you generate a comparable number of events in each pT bin, such that larger pT bins are oversampled, these bins come with a correspondingly reduced overall weight, that needs to be taken into account when the bins are combined. The other is to have a continuously increasing oversampling of events at larger pT scales, which is compensated by a continuously decreasing weight for the event.

Both of these solutions are supported. Specifically, for 2 → 2 processes, the pTHat scale offers a convenient classification of the event. (Of course, two events starting out from the same pTHat scale will experience different parton shower evolutions, etc., and may therefore look quite different at the end.) The two cuts `PhaseSpace:pTHatMin` and `PhaseSpace:pTHatMax` therefore offers a way to slice a pT range into subranges, see e.g. `main08.cc`. Alternatively the User Hooks machinery offers the possibility for you to define your own reweighting of phase space sampling, with a corresponding event weight, with `UserHooks::canBiasSelection` and related methods.

As a simplified option, we here offer the possibility to bias the 2 → 2 sampling by a power of pTHat, then with events having a weight the inverse of this. This fast track will only work under a number of strict conditions, implemented to reduce the risk of abuse. (Whereas a `UserHooks` setup can be flexible.) Specifically it will work if only high-pT 2 → 2 processes already implemented in PYTHIA are requested, notably the `HardQCD` ones. That is, you cannot mix with 2 → 1 or 2 → 3 processes, nor with external processes (notably Les Houches input) or `SoftQCD` ones, and you cannot use the option to define a second hard process in the same event. Furthermore you have to be careful about the choice of `PhaseSpace:pTHatMin`, since a pTHat = 0 event would come with an infinite weight.

`flag` PhaseSpace:bias2Selection (`default = off`)
Possibility to switch on a biased phase space sampling, with compensatingly weighted events, for 2 → 2 processes. Can only be used under the specific conditions explained in the paragraph above; under other conditions the initialization will abort.

`parm` PhaseSpace:bias2SelectionPow (`default = 4.`; `minimum = 0.`; `maximum = 10.`)
If the above flag is on, then a 2 → 2 process at a scale pTHat will be oversampled in phase space by an amount (pTHat/pTRef)^pow, where you set the power pow here. Events are assigned a compensating weight the inverse of this, i.e. `Info::weight()` will return (pTRef/pTHat)^pow. This weight should then be used in the histogramming of event properties. The final overall normalization also involves the `Info::weightSum()` value.

`parm` PhaseSpace:bias2SelectionRef (`default = 10.`; `minimum = 1.`)
The reference scale pTRef introduced above, such that events with this pTHat obtain unit weight in the reweighting procedure. The value of this parameter has no impact on the final result of the reweighting procedure, but is only there for convenience, i.e. to give "reasonably-sized" weights.