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