/usr/share/doc/pythia8-doc/html/PhaseSpaceCuts.html is in pythia8-doc-html 8.1.86-1.2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 | <html>
<head>
<title>Phase Space Cuts</title>
<link rel="stylesheet" type="text/css" href="pythia.css"/>
<link rel="shortcut icon" href="pythia32.gif"/>
</head>
<body>
<h2>Phase Space Cuts</h2>
<code>PhaseSpace</code> is base class for all hard-process phase-space
generators, either generic <i>2 → 1</i> or <i>2 → 2</i> ones,
or specialized ones like for elastic and diffractive scattering.
<p/>
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 <a href="TotalCrossSections.html" target="page">handled separately</a>.)
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.
<p/>
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
<a href="UserHooks.html" target="page">user hooks</a> facility.
<h3>Cuts in all processes</h3>
<p/><code>parm </code><strong> PhaseSpace:mHatMin </strong>
(<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant mass.
<p/><code>parm </code><strong> PhaseSpace:mHatMax </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant mass.
A value below <code>mHatMin</code> means there is no upper limit.
<h3>Cuts in <i>2 → 1</i> processes</h3>
When a resonance <code>id</code> is produced, the
<code><a href="ParticleDataScheme.html" target="page">mMin(id)</a></code> and
<code><a href="ParticleDataScheme.html" target="page">mMax(id)</a></code>
methods restrict the allowed mass range
of this resonance. Therefore the allowed range is chosen to be the
overlap of this range and the <code>mHatMin</code> to
<code>mHatMax</code> 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.
<h3>Cuts in <i>2 → 2</i> processes</h3>
<p/><code>parm </code><strong> PhaseSpace:pTHatMin </strong>
(<code>default = <strong>0.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant <i>pT</i>.
<p/><code>parm </code><strong> PhaseSpace:pTHatMax </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant <i>pT</i>.
A value below <code>pTHatMin</code> means there is no upper limit.
<p/><code>parm </code><strong> PhaseSpace:pTHatMinDiverge </strong>
(<code>default = <strong>1.</strong></code>; <code>minimum = 0.5</code>)<br/>
Extra <i>pT</i> cut to avoid the divergences of some processes
in the limit <i>pT → 0</i>. Specifically, if either or both
produced particles have a mass below <code>pTHatMinDiverge</code>
then <i>pT</i> is limited from below by the larger of
<code>pTHatMin</code> and <code>pTHatMinDiverge</code>.
<p/><code>flag </code><strong> PhaseSpace:useBreitWigners </strong>
(<code>default = <strong>on</strong></code>)<br/>
Allows masses to be selected according to Breit-Wigner shapes in
<i>2 → 2</i> 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
<i>2 → 1</i> processes the Breit-Wigner shape is part of the
cross section itself, and therefore always included.
<p/><code>parm </code><strong> PhaseSpace:minWidthBreitWigners </strong>
(<code>default = <strong>0.01</strong></code>; <code>minimum = 1e-6</code>)<br/>
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.
Only applies when <code>useBreitWigners</code> is on; else the nominal
mass value is always used.
<p/>
For a particle with a Breit-Wigner shape selected, according to the
rules above and to the rules of the particle species itself, the
<code><a href="ParticleDataScheme.html" target="page">mMin(id)</a></code> and
<code><a href="ParticleDataScheme.html" target="page">mMax(id)</a></code>
methods restrict the allowed mass range of the particle, just like for
the <i>2 → 1 </i> processes.
<h3>Cuts in <i>2 → 3</i> processes</h3>
There are two main classes of <i>2 → 3</i> processes. One is the
processes such as <i>WW/ZZ</i>-fusion Higgs production, i.e.
<i>q q → q q H</i>, where there are no special singularities
associated with two partons in the final state being collinear,
or even for <i>pT → 0</i>. For this class, no further cuts
have been introduced than those already available for <i>2 → 2</i>
processes. Specifically, for now all three are restricted exactly the
same way by <code>pTHatMin</code> and <code>pTHatMax</code>. As above,
Breit-Wigner mass ranges can be restricted.
<p/>
The other <i>2 → 3</i> event class is QCD processes, such as
<i>g g → g g g</i>. 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 <i>pT</i>, i.e.
<i>pT_3 > pT_4 > pT_5</i> (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 <i>pT_3</i> and <i>pT_5</i>
can be specified, but obviously <i>pT_3max >= pT_5max</i> and
<i>pT_3min >= pT_5min</i>. The <i>pT_4</i> is not constrained
explicitly, but is constructed from the vector sum of <i>pT_3</i>
and <i>pT_5</i>, subject to the constraint that it has to lie
between the two in magnitude. While the <i>pT</i> 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 <i>R</i>, where
<i>R^2 = (Delta eta)^2 + (Delta phi)^2</i>.
Finally, a note about efficiency. The QCD <i>2 → 3</i> phase space
is not set up to explicitly include <i>mHat</i> 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 <i>pT_3</i> and <i>pT_5</i> bins
are likely to give inefficient generation, if it gives rise to
significant indirect restrictions on <i>pT_4</i>.
<p/><code>parm </code><strong> PhaseSpace:pTHat3Min </strong>
(<code>default = <strong>10.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant <i>pT</i> of the highest-<i>pT</i> parton in
QCD <i>2 → 3</i> processes.
<p/><code>parm </code><strong> PhaseSpace:pTHat3Max </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant <i>pT</i> of the highest-<i>pT</i> parton in
QCD <i>2 → 3</i> processes
A value below <code>pTHat3Min</code> means there is no upper limit.
<p/><code>parm </code><strong> PhaseSpace:pTHat5Min </strong>
(<code>default = <strong>10.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant <i>pT</i> of the lowest-<i>pT</i> parton in
QCD <i>2 → 3</i> processes.
<p/><code>parm </code><strong> PhaseSpace:pTHat5Max </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant <i>pT</i> of the lowest-<i>pT</i> parton in
QCD <i>2 → 3</i> processes
A value below <code>pTHat5Min</code> means there is no upper limit.
<p/><code>parm </code><strong> PhaseSpace:RsepMin </strong>
(<code>default = <strong>1.</strong></code>)<br/>
The minimum separation <i>R</i> in <i>(eta, phi)</i> space between
any two outgoing partons in QCD <i>2 → 3</i> processes.
<h3>Cuts for a second hard process</h3>
If you use the machinery that allows the generation of a specified
<a href="ASecondHardProcess.html" target="page">second hard process</a> 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 <i>pT</i> ranges
such that the second interaction always has a larger <i>pT</i> than
the first.
<p/><code>flag </code><strong> PhaseSpace:sameForSecond </strong>
(<code>default = <strong>on</strong></code>)<br/>
By default use the same cuts for a second hard process as for the
first. If <code>off</code> then instead use the mass and <i>pT</i>
cuts below, where relevant. (The other cuts above still remain the same.)
<p/><code>parm </code><strong> PhaseSpace:mHatMinSecond </strong>
(<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant mass for a second interaction, if separate.
<p/><code>parm </code><strong> PhaseSpace:mHatMaxSecond </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant mass for a second interaction, if separate.
A value below <code>mHatMin</code> means there is no upper limit.
<p/><code>parm </code><strong> PhaseSpace:pTHatMinSecond </strong>
(<code>default = <strong>0.</strong></code>; <code>minimum = 0.</code>)<br/>
The minimum invariant <i>pT</i> for a second interaction, if separate.
<p/><code>parm </code><strong> PhaseSpace:pTHatMaxSecond </strong>
(<code>default = <strong>-1.</strong></code>)<br/>
The maximum invariant <i>pT</i> for a second interaction, if separate.
A value below <code>pTHatMin</code> means there is no upper limit.
<h3>Generation strategy and documentation</h3>
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.
<p/><code>flag </code><strong> PhaseSpace:showSearch </strong>
(<code>default = <strong>off</strong></code>)<br/>
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.
<p/><code>flag </code><strong> PhaseSpace:showViolation </strong>
(<code>default = <strong>off</strong></code>)<br/>
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.
<p/><code>flag </code><strong> PhaseSpace:increaseMaximum </strong>
(<code>default = <strong>off</strong></code>)<br/>
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.
<br/><b>off:</b>each event comes with a weight, which normally is unity
(as a consequence of the acceptance/rejection step), and is found in
<code><a href="EventInformation.html" target="page">Info::weight()</a></code>.
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 <code><a href="EventStatistics.html" target="page">Pythia::statistics()</a></code>
output) the option exists to use the information.
<br/><b>on:</b>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 <a href="RandomNumbers.html" target="page">random-number
state</a> for debugging purposes.
<h3>Reweighting of <i>2 → 2</i> processes</h3>
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 <i>pT</i>, such that few
events are generated at large <i>pT</i> scales. If one wants to
plot the <i>pT</i> cross section, and all that comes with it, the
statistical error will then degrade with increasing <i>pT</i>
where fewer events end up.
<p/>
One solution is to split the full <i>pT</i> 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 <i>pT</i> bin, such that
larger <i>pT</i> 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 <i>pT</i> scales, which
is compensated by a continuously decreasing weight for the event.
<p/>
Both of these solutions are supported. Specifically, for
<i>2 → 2</i> processes, the <i>pTHat</i> scale offers a
convenient classification of the event. (Of course, two events
starting out from the same <i>pTHat</i> scale will experience
different parton shower evolutions, etc., and may therefore look
quite different at the end.) The two cuts
<code>PhaseSpace:pTHatMin</code> and <code>PhaseSpace:pTHatMax</code>
therefore offers a way to slice a <i>pT</i> range into subranges,
see e.g. <code>main08.cc</code>. Alternatively the
<a href="UserHooks.html" target="page">User Hooks</a> machinery offers the
possibility for you to define your own reweighting of phase space
sampling, with a corresponding event weight, with
<code>UserHooks::canBiasSelection</code> and related methods.
<p/>
As a simplified option, we here offer the possibility to bias the
<i>2 → 2</i> sampling by a power of <i>pTHat</i>, 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 <code>UserHooks</code> setup can be more
flexible.) Specifically it will work if only high-<i>pT</i>
<i>2 → 2</i> processes already implemented in PYTHIA are requested,
notably the <code>HardQCD</code> ones. That is, you cannot mix with
<i>2 → 1</i> or <i>2 → 3</i> processes, nor with external
processes (notably Les Houches input) or <code>SoftQCD</code> ones,
and you cannot use the option to define a
<a href="ASecondHardProcess.html" target="page">second hard process</a> in
the same event. Furthermore you have to be careful about the choice
of <code>PhaseSpace:pTHatMin</code>, since a <i>pTHat = 0</i>
event would come with an infinite weight.
<p/><code>flag </code><strong> PhaseSpace:bias2Selection </strong>
(<code>default = <strong>off</strong></code>)<br/>
Possibility to switch on a biased phase space sampling,
with compensatingly weighted events, for <i>2 → 2</i> processes.
Can only be used under the specific conditions explained in
the paragraph above; under other conditions the initialization
will abort.
<p/><code>parm </code><strong> PhaseSpace:bias2SelectionPow </strong>
(<code>default = <strong>4.</strong></code>; <code>minimum = 0.</code>; <code>maximum = 10.</code>)<br/>
If the above flag is on, then a <i>2 → 2</i> process at a scale
<i>pTHat</i> will be oversampled in phase space by an amount
<i>(pTHat/pTRef)^pow</i>, where you set the power <i>pow</i>
here. Events are assigned a compensating
<a href="EventInformation.html" target="page">weight</a> the inverse of this,
i.e. <code>Info::weight()</code> will return <i>(pTRef/pTHat)^pow</i>.
This weight should then be used in the histogramming of event properties.
The final overall normalization also involves the
<code>Info::weightSum()</code> value.
<p/><code>parm </code><strong> PhaseSpace:bias2SelectionRef </strong>
(<code>default = <strong>10.</strong></code>; <code>minimum = 1.</code>)<br/>
The reference scale <i>pTRef</i> introduced above, such that events
with this <i>pTHat</i> 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.
</body>
</html>
<!-- Copyright (C) 2014 Torbjorn Sjostrand -->
|