[1] | 1 | <chapter name="Phase Space Cuts"> |
---|
| 2 | |
---|
| 3 | <h2>Phase Space Cuts</h2> |
---|
| 4 | |
---|
| 5 | <code>PhaseSpace</code> is base class for all hard-process phase-space |
---|
| 6 | generators, either generic <ei>2 -> 1</ei> or <ei>2 -> 2</ei> ones, |
---|
| 7 | or specialized ones like for elastic and diffractive scattering. |
---|
| 8 | |
---|
| 9 | <p/> |
---|
| 10 | In it, it is possible to constrain the kinematics of most processes. |
---|
| 11 | (Exceptions are "soft physics", i.e. minimum bias, elastic and |
---|
| 12 | diffractive processes. The Coulomb singularity for elastic scatterings, |
---|
| 13 | if simulated, is <aloc href="TotalCrossSections">handled separately</aloc>.) |
---|
| 14 | These constraints apply in the rest frame of the hard subprocess, and |
---|
| 15 | topologies normally would be changed e.g. by subsequent showering |
---|
| 16 | activity. The cross section of a process is adjusted to only |
---|
| 17 | correspond to the allowed phase space. |
---|
| 18 | |
---|
| 19 | <p/> |
---|
| 20 | The more particles in the final state, the more cuts could be applied. |
---|
| 21 | Here we have tried to remain with the useful minimum, however. More |
---|
| 22 | generic possibilities could be handled by the |
---|
| 23 | <aloc href="UserHooks">user hooks</aloc> facility. |
---|
| 24 | |
---|
| 25 | <h3>Cuts in all processes</h3> |
---|
| 26 | |
---|
| 27 | <parm name="PhaseSpace:mHatMin" default="4." min="0."> |
---|
| 28 | The minimum invariant mass. |
---|
| 29 | </parm> |
---|
| 30 | |
---|
| 31 | <parm name="PhaseSpace:mHatMax" default="-1."> |
---|
| 32 | The maximum invariant mass. |
---|
| 33 | A value below <code>mHatMin</code> means there is no upper limit. |
---|
| 34 | </parm> |
---|
| 35 | |
---|
| 36 | <h3>Cuts in <ei>2 -> 1</ei> processes</h3> |
---|
| 37 | |
---|
| 38 | When a resonance <code>id</code> is produced, the |
---|
| 39 | <code><aloc href="ParticleDataScheme">mMin(id)</aloc></code> and |
---|
| 40 | <code><aloc href="ParticleDataScheme">mMax(id)</aloc></code> |
---|
| 41 | methods restrict the allowed mass range |
---|
| 42 | of this resonance. Therefore the allowed range is chosen to be the |
---|
| 43 | overlap of this range and the <code>mHatMin</code> to |
---|
| 44 | <code>mHatMax</code> range above. Most resonances by default have no |
---|
| 45 | upper mass limit, so effects mainly concern the lower limit. |
---|
| 46 | Should there be no overlap between the two ranges then the process |
---|
| 47 | will be switched off. |
---|
| 48 | |
---|
| 49 | <h3>Cuts in <ei>2 -> 2</ei> processes</h3> |
---|
| 50 | |
---|
| 51 | <parm name="PhaseSpace:pTHatMin" default="0." min="0."> |
---|
| 52 | The minimum invariant <ei>pT</ei>. |
---|
| 53 | </parm> |
---|
| 54 | |
---|
| 55 | <parm name="PhaseSpace:pTHatMax" default="-1."> |
---|
| 56 | The maximum invariant <ei>pT</ei>. |
---|
| 57 | A value below <code>pTHatMin</code> means there is no upper limit. |
---|
| 58 | </parm> |
---|
| 59 | |
---|
| 60 | <parm name="PhaseSpace:pTHatMinDiverge" default="1." min="0.5"> |
---|
| 61 | Extra <ei>pT</ei> cut to avoid the divergences of some processes |
---|
| 62 | in the limit <ei>pT -> 0</ei>. Specifically, if either or both |
---|
| 63 | produced particles have a mass below <code>pTHatMinDiverge</code> |
---|
| 64 | then <ei>pT</ei> is limited from below by the larger of |
---|
| 65 | <code>pTHatMin</code> and <code>pTHatMinDiverge</code>. |
---|
| 66 | </parm> |
---|
| 67 | |
---|
| 68 | <flag name="PhaseSpace:useBreitWigners" default="on"> |
---|
| 69 | Allows masses to be selected according to Breit-Wigner shapes in |
---|
| 70 | <ei>2 -> 2</ei> processes, whenever particles have been declared |
---|
| 71 | with a nonvanishing width above the threshold below. In those cases |
---|
| 72 | also the limits below will be used for the mass selection. For |
---|
| 73 | <ei>2 -> 1</ei> processes the Breit-Wigner shape is part of the |
---|
| 74 | cross section itself, and therefore always included. |
---|
| 75 | </flag> |
---|
| 76 | |
---|
| 77 | <parm name="PhaseSpace:minWidthBreitWigners" default="0.01" min="1e-6"> |
---|
| 78 | The minimum width a resonance must have for the mass to be dynamically |
---|
| 79 | selected according to a Breit-Wigner shape, within the limits set below. |
---|
| 80 | Only applies when <code>useBreitWigners</code> is on; else the nominal |
---|
| 81 | mass value is always used. |
---|
| 82 | </parm> |
---|
| 83 | |
---|
| 84 | <p/> |
---|
| 85 | For a particle with a Breit-Wigner shape selected, according to the |
---|
| 86 | rules above and to the rules of the particle species itself, the |
---|
| 87 | <code><aloc href="ParticleDataScheme">mMin(id)</aloc></code> and |
---|
| 88 | <code><aloc href="ParticleDataScheme">mMax(id)</aloc></code> |
---|
| 89 | methods restrict the allowed mass range of the particle, just like for |
---|
| 90 | the <ei>2 -> 1 </ei> processes. |
---|
| 91 | |
---|
| 92 | <h3>Cuts in <ei>2 -> 3</ei> processes</h3> |
---|
| 93 | |
---|
| 94 | There are two main classes of <ei>2 -> 3</ei> processes. One is the |
---|
| 95 | processes such as <ei>WW/ZZ</ei>-fusion Higgs production, i.e. |
---|
| 96 | <ei>q q -> q q H</ei>, where there are no special singularities |
---|
| 97 | associated with two partons in the final state being collinear, |
---|
| 98 | or even for <ei>pT -> 0</ei>. For this class, no further cuts |
---|
| 99 | have been introduced than those already available for <ei>2 -> 2</ei> |
---|
| 100 | processes. Specifically, for now all three are restricted exactly the |
---|
| 101 | same way by <code>pTHatMin</code> and <code>pTHatMax</code>. As above, |
---|
| 102 | Breit-Wigner mass ranges can be restricted. |
---|
| 103 | |
---|
| 104 | <p/> |
---|
| 105 | The other <ei>2 -> 3</ei> event class is QCD processes, such as |
---|
| 106 | <ei>g g -> g g g</ei>. Here the soft and collinear singularities |
---|
| 107 | play a major role, and the phase space generation and cuts have |
---|
| 108 | been adapted to this. For this class, an alternative set of cuts |
---|
| 109 | is used, as outlined in the following. First of all the three |
---|
| 110 | outgoing partons are ordered in falling <ei>pT</ei>, i.e. |
---|
| 111 | <ei>pT_3 > pT_4 > pT_5</ei> (where the labelling 3, 4, 5 of the outgoing |
---|
| 112 | partons is random, i.e. unrelated to the order specified in the |
---|
| 113 | process name). The allowed ranges of <ei>pT_3</ei> and <ei>pT_5</ei> |
---|
| 114 | can be specified, but obviously <ei>pT_3max >= pT_5max</ei> and |
---|
| 115 | <ei>pT_3min >= pT_5min</ei>. The <ei>pT_4</ei> is not constrained |
---|
| 116 | explicitly, but is constructed from the vector sum of <ei>pT_3</ei> |
---|
| 117 | and <ei>pT_5</ei>, subject to the constraint that it has to lie |
---|
| 118 | between the two in magnitude. While the <ei>pT</ei> cuts take care |
---|
| 119 | of singularities collinear with the incoming beams, it is also |
---|
| 120 | necessary to handle final-state singularities, when two outgoing |
---|
| 121 | partons become collinear. This is done by requiring a minimal |
---|
| 122 | separation in <ei>R</ei>, where |
---|
| 123 | <ei>R^2 = (Delta eta)^2 + (Delta phi)^2</ei>. |
---|
| 124 | Finally, a note about efficiency. The QCD <ei>2 -> 3</ei> phase space |
---|
| 125 | is not set up to explicitly include <ei>mHat</ei> as one of the basic |
---|
| 126 | variables. Such a cut is only done after a phase space point is already |
---|
| 127 | selected, which means that a narrow mass choice will slow down the |
---|
| 128 | program appreciably. Also narrow <ei>pT_3</ei> and <ei>pT_5</ei> bins |
---|
| 129 | are likely to give inefficient generation, if it gives rise to |
---|
| 130 | significant indirect restrictions on <ei>pT_4</ei>. |
---|
| 131 | |
---|
| 132 | <parm name="PhaseSpace:pTHat3Min" default="10." min="0."> |
---|
| 133 | The minimum invariant <ei>pT</ei> of the highest-<ei>pT</ei> parton in |
---|
| 134 | QCD <ei>2 -> 3</ei> processes. |
---|
| 135 | </parm> |
---|
| 136 | |
---|
| 137 | <parm name="PhaseSpace:pTHat3Max" default="-1."> |
---|
| 138 | The maximum invariant <ei>pT</ei> of the highest-<ei>pT</ei> parton in |
---|
| 139 | QCD <ei>2 -> 3</ei> processes |
---|
| 140 | A value below <code>pTHat3Min</code> means there is no upper limit. |
---|
| 141 | </parm> |
---|
| 142 | |
---|
| 143 | <parm name="PhaseSpace:pTHat5Min" default="10." min="0."> |
---|
| 144 | The minimum invariant <ei>pT</ei> of the lowest-<ei>pT</ei> parton in |
---|
| 145 | QCD <ei>2 -> 3</ei> processes. |
---|
| 146 | </parm> |
---|
| 147 | |
---|
| 148 | <parm name="PhaseSpace:pTHat5Max" default="-1."> |
---|
| 149 | The maximum invariant <ei>pT</ei> of the lowest-<ei>pT</ei> parton in |
---|
| 150 | QCD <ei>2 -> 3</ei> processes |
---|
| 151 | A value below <code>pTHat5Min</code> means there is no upper limit. |
---|
| 152 | </parm> |
---|
| 153 | |
---|
| 154 | <parm name="PhaseSpace:RsepMin" default="1."> |
---|
| 155 | The minimum separation <ei>R</ei> in <ei>(eta, phi)</ei> space between |
---|
| 156 | any two outgoing partons in QCD <ei>2 -> 3</ei> processes. |
---|
| 157 | </parm> |
---|
| 158 | |
---|
| 159 | |
---|
| 160 | <h3>Cuts for a second hard process</h3> |
---|
| 161 | |
---|
| 162 | If you use the machinery that allows the generation of a specified |
---|
| 163 | <aloc href="ASecondHardProcess">second hard process</aloc> then, |
---|
| 164 | by default, the same phase space cuts will be used for it as listed |
---|
| 165 | above. Optionally, however, you may use a second set of cuts, as |
---|
| 166 | described here. In this context "first" and "second" is merely a |
---|
| 167 | technical distinction; you are welcome e.g. to pick <ei>pT</ei> ranges |
---|
| 168 | such that the second interaction always has a larger <ei>pT</ei> than |
---|
| 169 | the first. |
---|
| 170 | |
---|
| 171 | <flag name="PhaseSpace:sameForSecond" default="on"> |
---|
| 172 | By default use the same cuts for a second hard process as for the |
---|
| 173 | first. If <code>off</code> then instead use the mass and <ei>pT</ei> |
---|
| 174 | cuts below, where relevant. (The other cuts above still remain the same.) |
---|
| 175 | </flag> |
---|
| 176 | |
---|
| 177 | <parm name="PhaseSpace:mHatMinSecond" default="4." min="0."> |
---|
| 178 | The minimum invariant mass for a second interaction, if separate. |
---|
| 179 | </parm> |
---|
| 180 | |
---|
| 181 | <parm name="PhaseSpace:mHatMaxSecond" default="-1."> |
---|
| 182 | The maximum invariant mass for a second interaction, if separate. |
---|
| 183 | A value below <code>mHatMin</code> means there is no upper limit. |
---|
| 184 | </parm> |
---|
| 185 | |
---|
| 186 | <parm name="PhaseSpace:pTHatMinSecond" default="0." min="0."> |
---|
| 187 | The minimum invariant <ei>pT</ei> for a second interaction, if separate. |
---|
| 188 | </parm> |
---|
| 189 | |
---|
| 190 | <parm name="PhaseSpace:pTHatMaxSecond" default="-1."> |
---|
| 191 | The maximum invariant <ei>pT</ei> for a second interaction, if separate. |
---|
| 192 | A value below <code>pTHatMin</code> means there is no upper limit. |
---|
| 193 | </parm> |
---|
| 194 | |
---|
| 195 | <h3>Generation strategy and documentation</h3> |
---|
| 196 | |
---|
| 197 | During the initialization stage a simplified function is found, |
---|
| 198 | that is intended to be above the true cross-section behaviour |
---|
| 199 | over the whole of phase space. It is chosen to be easily integrable |
---|
| 200 | and invertible. That way a trial phase space point can be selected |
---|
| 201 | according this simple function, and then be accepted by the ratio of |
---|
| 202 | true to the simple function. For a good efficieny the ratio should be |
---|
| 203 | close to unity, yet never above it. This constrains the absolute |
---|
| 204 | normalization of the simple function. The initial search may fail to |
---|
| 205 | find the phase space point where the true-to-simple ratio is maximal, |
---|
| 206 | however. This then can lead to subsequent maximum violations, where the |
---|
| 207 | ratio is above unity. Two alternative strategies are implemented to |
---|
| 208 | handle such situations, see below. |
---|
| 209 | |
---|
| 210 | <flag name="PhaseSpace:showSearch" default="off"> |
---|
| 211 | Possibility to print information on the search for phase-space |
---|
| 212 | coefficients that (in a multichannel approach) provides an analytical |
---|
| 213 | upper envelope of the differential cross section, and the |
---|
| 214 | corresponding upper estimate of the cross section. Of interest |
---|
| 215 | for crosschecks by expert users only. |
---|
| 216 | </flag> |
---|
| 217 | |
---|
| 218 | <flag name="PhaseSpace:showViolation" default="off"> |
---|
| 219 | Possibility to print information whenever the assumed maximum |
---|
| 220 | differential cross section of a process is violated, i.e. when |
---|
| 221 | the initial maximization procedure did not find the true maximum. |
---|
| 222 | Also, should negative cross sections occur, print whenever a more |
---|
| 223 | negative value is encountered. |
---|
| 224 | </flag> |
---|
| 225 | |
---|
| 226 | <flag name="PhaseSpace:increaseMaximum" default="off"> |
---|
| 227 | Strategy for handling cases where a larger cross section is |
---|
| 228 | obtained during the event generation than was assumed at initialization, |
---|
| 229 | i.e. when a violation occurs. |
---|
| 230 | <br/><b>off:</b>each event comes with a weight, which normally is unity |
---|
| 231 | (as a consequence of the acceptance/rejection step), and is found in |
---|
| 232 | <code><aloc href="EventInformation">Info::weight()</aloc></code>. |
---|
| 233 | For events which exceed the maximum instead the true-to-simple ratio |
---|
| 234 | is stored as event weight, which then is above unity. If the user so |
---|
| 235 | wishes this weight can then be carried along when event properties are |
---|
| 236 | histogrammed. Since normally such violations should be rare and not |
---|
| 237 | too much above unity one could expect most users to ignore such issues |
---|
| 238 | be default. Should maximum violations turn out to be frequent (visible |
---|
| 239 | in the <code><aloc href="EventStatistics">Pythia::statistics()</aloc></code> |
---|
| 240 | output) the option exists to use the information. |
---|
| 241 | <br/><b>on:</b>the maximum is increased whenever it is exceeded. Thus |
---|
| 242 | events generated after this point will be "correctly" distributed, |
---|
| 243 | while ones generated previously obviously then have had too high a |
---|
| 244 | relative weight. If violations occur early on and/or are small this |
---|
| 245 | strategy should do a good job of correcting to the desired phase-space |
---|
| 246 | distribution. This strategy may be more convenient for the normal user, |
---|
| 247 | who would not wish to worry about event weights. It does have the |
---|
| 248 | disadvantage that the raised maximum introduces an extra amount of |
---|
| 249 | "history memory" to the generation sequence, so that it becomes less |
---|
| 250 | easy to save-and-restore the <aloc href="RandomNumbers">random-number |
---|
| 251 | state</aloc> for debugging purposes. |
---|
| 252 | </flag> |
---|
| 253 | |
---|
| 254 | <h3>Reweighting of <ei>2 -> 2</ei> processes</h3> |
---|
| 255 | |
---|
| 256 | Events normally come with unit weight, i.e. are distributed across |
---|
| 257 | the allowed phase space region according to the appropriate differential |
---|
| 258 | cross sections. Sometimes it may be convenient to have an uneven |
---|
| 259 | distribution of events. The classical example here is that many cross |
---|
| 260 | sections drop off with transverse momentum <ei>pT</ei>, such that few |
---|
| 261 | events are generated at large <ei>pT</ei> scales. If one wants to |
---|
| 262 | plot the <ei>pT</ei> cross section, and all that comes with it, the |
---|
| 263 | statistical error will then degrade with increasing <ei>pT</ei> |
---|
| 264 | where fewer events end up. |
---|
| 265 | |
---|
| 266 | <p/> |
---|
| 267 | One solution is to split the full <ei>pT</ei> range into several |
---|
| 268 | separate subranges, where the events of each subsample obtains a |
---|
| 269 | different overall normalization. Specifically, if you generate a |
---|
| 270 | comparable number of events in each <ei>pT</ei> bin, such that |
---|
| 271 | larger <ei>pT</ei> bins are oversampled, these bins come with a |
---|
| 272 | correspondingly reduced overall weight, that needs to be taken into |
---|
| 273 | account when the bins are combined. The other is to have a continuously |
---|
| 274 | increasing oversampling of events at larger <ei>pT</ei> scales, which |
---|
| 275 | is compensated by a continuously decreasing weight for the event. |
---|
| 276 | |
---|
| 277 | <p/> |
---|
| 278 | Both of these solutions are supported. Specifically, for |
---|
| 279 | <ei>2 -> 2</ei> processes, the <ei>pTHat</ei> scale offers a |
---|
| 280 | convenient classification of the event. (Of course, two events |
---|
| 281 | starting out from the same <ei>pTHat</ei> scale will experience |
---|
| 282 | different parton shower evolutions, etc., and may therefore look |
---|
| 283 | quite different at the end.) The two cuts |
---|
| 284 | <code>PhaseSpace:pTHatMin</code> and <code>PhaseSpace:pTHatMax</code> |
---|
| 285 | therefore offers a way to slice a <ei>pT</ei> range into subranges, |
---|
| 286 | see e.g. <code>main08.cc</code>. Alternatively the |
---|
| 287 | <aloc href="UserHooks">User Hooks</aloc> machinery offers the |
---|
| 288 | possibility for you to define your own reweighting of phase space |
---|
| 289 | sampling, with a corresponding event weight, with |
---|
| 290 | <code>UserHooks::canBiasSelection</code> and related methods. |
---|
| 291 | |
---|
| 292 | <p/> |
---|
| 293 | As a simplified option, we here offer the possibility to bias the |
---|
| 294 | <ei>2 -> 2</ei> sampling by a power of <ei>pTHat</ei>, then with |
---|
| 295 | events having a weight the inverse of this. This fast track will only |
---|
| 296 | work under a number of strict conditions, implemented to reduce the |
---|
| 297 | risk of abuse. (Whereas a <code>UserHooks</code> setup can be more |
---|
| 298 | flexible.) Specifically it will work if only high-<ei>pT</ei> |
---|
| 299 | <ei>2 -> 2</ei> processes already implemented in PYTHIA are requested, |
---|
| 300 | notably the <code>HardQCD</code> ones. That is, you cannot mix with |
---|
| 301 | <ei>2 -> 1</ei> or <ei>2 -> 3</ei> processes, nor with external |
---|
| 302 | processes (notably Les Houches input) or <code>SoftQCD</code> ones, |
---|
| 303 | and you cannot use the option to define a |
---|
| 304 | <aloc href="ASecondHardProcess">second hard process</aloc> in |
---|
| 305 | the same event. Furthermore you have to be careful about the choice |
---|
| 306 | of <code>PhaseSpace:pTHatMin</code>, since a <ei>pTHat = 0</ei> |
---|
| 307 | event would come with an infinite weight. |
---|
| 308 | |
---|
| 309 | <flag name="PhaseSpace:bias2Selection" default="off"> |
---|
| 310 | Possibility to switch on a biased phase space sampling, |
---|
| 311 | with compensatingly weighted events, for <ei>2 -> 2</ei> processes. |
---|
| 312 | Can only be used under the specific conditions explained in |
---|
| 313 | the paragraph above; under other conditions the initialization |
---|
| 314 | will abort. |
---|
| 315 | </flag> |
---|
| 316 | |
---|
| 317 | <parm name="PhaseSpace:bias2SelectionPow" default="4." min="0." max="10."> |
---|
| 318 | If the above flag is on, then a <ei>2 -> 2</ei> process at a scale |
---|
| 319 | <ei>pTHat</ei> will be oversampled in phase space by an amount |
---|
| 320 | <ei>(pTHat/pTRef)^pow</ei>, where you set the power <ei>pow</ei> |
---|
| 321 | here. Events are assigned a compensating |
---|
| 322 | <aloc href="EventInformation">weight</aloc> the inverse of this, |
---|
| 323 | i.e. <code>Info::weight()</code> will return <ei>(pTRef/pTHat)^pow</ei>. |
---|
| 324 | This weight should then be used in the histogramming of event properties. |
---|
| 325 | The final overall normalization also involves the |
---|
| 326 | <code>Info::weightSum()</code> value. |
---|
| 327 | </parm> |
---|
| 328 | |
---|
| 329 | <parm name="PhaseSpace:bias2SelectionRef" default="10." min="1."> |
---|
| 330 | The reference scale <ei>pTRef</ei> introduced above, such that events |
---|
| 331 | with this <ei>pTHat</ei> obtain unit weight in the reweighting procedure. |
---|
| 332 | The value of this parameter has no impact on the final result of the |
---|
| 333 | reweighting procedure, but is only there for convenience, i.e. to |
---|
| 334 | give "reasonably-sized" weights. |
---|
| 335 | </parm> |
---|
| 336 | |
---|
| 337 | </chapter> |
---|
| 338 | |
---|
| 339 | <!-- Copyright (C) 2012 Torbjorn Sjostrand --> |
---|