source: HiSusy/trunk/Pythia8/pythia8170/xmldoc/PhaseSpaceCuts.xml @ 1

Last change on this file since 1 was 1, checked in by zerwas, 11 years ago

first import of structure, PYTHIA8 and DELPHES

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