]> git.uio.no Git - u/mrichter/AliRoot.git/blame - PYTHIA8/pythia8170/xmldoc/MultipartonInteractions.xml
Protection for dereferencing fTDCErrorBuffer. see ALIROOT-5749
[u/mrichter/AliRoot.git] / PYTHIA8 / pythia8170 / xmldoc / MultipartonInteractions.xml
CommitLineData
63ba5337 1<chapter name="Multiparton Interactions">
2
3<h2>Multiparton Interactions</h2>
4
5The starting point for the multiparton interactions physics scenario in
6PYTHIA is provided by <ref>Sjo87</ref>. Recent developments have
7included a more careful study of flavour and colour correlations,
8junction topologies and the relationship to beam remnants
9<ref>Sjo04</ref>, interleaving with initial-state radiation
10<ref>Sjo05</ref>, making use of transverse-momentum-ordered
11initial- and final-state showers, with the extension to fully
12interleaved evolution covered in <ref>Cor10a</ref>. A framework to
13handle rescattering is described in <ref>Cor09</ref>.
14
15<p/>
16A big unsolved issue is how the colour of all these subsystems is
17correlated. For sure there is a correlation coming from the colour
18singlet nature of the incoming beams, but in addition final-state
19colour rearrangements may change the picture. Indeed such extra
20effects appear necessary to describe data, e.g. on
21<ei>&lt;pT&gt;(n_ch)</ei>. A simple implementation of colour
22rearrangement is found as part of the
23<aloc href="BeamRemnants">beam remnants</aloc> description.
24
25<h3>Main variables</h3>
26
27<h4>Matching to hard process</h4>
28
29The maximum <ei>pT</ei> to be allowed for multiparton interactions is
30related to the nature of the hard process itself. It involves a
31delicate balance between not doublecounting and not leaving any
32gaps in the coverage. The best procedure may depend on information
33only the user has: how the events were generated and mixed (e.g. with
34Les Houches Accord external input), and how they are intended to be
35used. Therefore a few options are available, with a sensible default
36behaviour.
37<modepick name="MultipartonInteractions:pTmaxMatch" default="0" min="0"
38max="2">
39Way in which the maximum scale for multiparton interactions is set
40to match the scale of the hard process itself.
41<option value="0"><b>(i)</b> if the final state of the hard process
42(not counting subsequent resonance decays) contains only quarks
43(<ei>u, d, s, c ,b</ei>), gluons and photons then <ei>pT_max</ei>
44is chosen to be the factorization scale for internal processes
45and the <code>scale</code> value for Les Houches input;
46<b>(ii)</b> if not, interactions are allowed to go all the way up
47to the kinematical limit.
48The reasoning is that the former kind of processes are generated by
49the multiparton-interactions machinery and so would doublecount hard
50processes if allowed to overlap the same <ei>pT</ei> range,
51while no such danger exists in the latter case.
52</option>
53<option value="1">always use the factorization scale for an internal
54process and the <code>scale</code> value for Les Houches input,
55i.e. the lower value. This should avoid doublecounting, but
56may leave out some interactions that ought to have been simulated.
57</option>
58<option value="2">always allow multiparton interactions up to the
59kinematical limit. This will simulate all possible event topologies,
60but may lead to doublecounting.
61</option>
62</modepick>
63
64<h4>Cross-section parameters</h4>
65
66The rate of interactions is determined by
67<parm name="MultipartonInteractions:alphaSvalue" default="0.127"
68min="0.06" max="0.25">
69The value of <ei>alpha_strong</ei> at <ei>m_Z</ei>. Default value is
70picked equal to the one used in CTEQ 5L.
71</parm>
72
73<p/>
74The actual value is then regulated by the running to the scale
75<ei>pT^2</ei>, at which it is evaluated
76<modepick name="MultipartonInteractions:alphaSorder" default="1"
77min="0" max="2">
78The order at which <ei>alpha_strong</ei> runs at scales away from
79<ei>m_Z</ei>.
80<option value="0">zeroth order, i.e. <ei>alpha_strong</ei> is kept
81fixed.</option>
82<option value="1">first order, which is the normal value.</option>
83<option value="2">second order. Since other parts of the code do
84not go to second order there is no strong reason to use this option,
85but there is also nothing wrong with it.</option>
86</modepick>
87
88<p/>
89QED interactions are regulated by the <ei>alpha_electromagnetic</ei>
90value at the <ei>pT^2</ei> scale of an interaction.
91
92<modepick name="MultipartonInteractions:alphaEMorder" default="1"
93min="-1" max="1">
94The running of <ei>alpha_em</ei> used in hard processes.
95<option value="1">first-order running, constrained to agree with
96<code>StandardModel:alphaEMmZ</code> at the <ei>Z^0</ei> mass.
97</option>
98<option value="0">zeroth order, i.e. <ei>alpha_em</ei> is kept
99fixed at its value at vanishing momentum transfer.</option>
100<option value="-1">zeroth order, i.e. <ei>alpha_em</ei> is kept
101fixed, but at <code>StandardModel:alphaEMmZ</code>, i.e. its value
102at the <ei>Z^0</ei> mass.
103</option>
104</modepick>
105
106<p/>
107Note that the choices of <ei>alpha_strong</ei> and <ei>alpha_em</ei>
108made here override the ones implemented in the normal process machinery,
109but only for the interactions generated by the
110<code>MultipartonInteractions</code> class.
111
112<p/>
113In addition there is the possibility of a global rescaling of
114cross sections (which could not easily be accommodated by a
115changed <ei>alpha_strong</ei>, since <ei>alpha_strong</ei> runs)
116<parm name="MultipartonInteractions:Kfactor" default="1.0" min="0.5"
117max="4.0">
118Multiply all cross sections by this fix factor.
119</parm>
120
121<p/>
122The processes used to generate multiparton interactions form a subset
123of the standard library of hard processes. The input is slightly
124different from the standard hard-process machinery, however,
125since incoming flavours, the <ei>alpha_strong</ei> value and most
126of the kinematics are aready fixed when the process is called.
127It is possible to regulate the set of processes that are included in the
128multiparton-interactions framework.
129
130<modepick name="MultipartonInteractions:processLevel" default="3"
131min="0" max="3">
132Set of processes included in the machinery.
133<option value="0">only the simplest <ei>2 -> 2</ei> QCD processes
134between quarks and gluons, giving no new flavours, i.e. dominated by
135<ei>t</ei>-channel gluon exchange.</option>
136<option value="1">also <ei>2 -> 2</ei> QCD processes giving new flavours
137(including charm and bottom), i.e. proceeding through <ei>s</ei>-channel
138gluon exchange.</option>
139<option value="2">also <ei>2 -> 2</ei> processes involving one or two
140photons in the final state, <ei>s</ei>-channel <ei>gamma</ei>
141boson exchange and <ei>t</ei>-channel <ei>gamma/Z^0/W^+-</ei>
142boson exchange.</option>
143<option value="3">also charmonium and bottomonium production, via
144colour singlet and colour octet channels.</option>
145</modepick>
146
147<h4>Cross-section regularization</h4>
148
149There are two complementary ways of regularizing the small-<ei>pT</ei>
150divergence, a sharp cutoff and a smooth dampening. These can be
151combined as desired, but it makes sense to coordinate with how the
152same issue is handled in <aloc href="SpacelikeShowers">spacelike
153showers</aloc>. Actually, by default, the parameters defined here are
154used also for the spacelike showers, but this can be overridden.
155
156<p/>
157Regularization of the divergence of the QCD cross section for
158<ei>pT -> 0</ei> is obtained by a factor <ei>pT^4 / (pT0^2 + pT^2)^2</ei>,
159and by using an <ei>alpha_s(pT0^2 + pT^2)</ei>. An energy dependence
160of the <ei>pT0</ei> choice is introduced by two further parameters,
161so that <ei>pT0Ref</ei> is the <ei>pT0</ei> value for the reference
162CM energy, <ei>pT0Ref = pT0(ecmRef)</ei>.
163<note>Warning:</note> if a large <ei>pT0</ei> is picked for multiparton
164interactions, such that the integrated interaction cross section is
165below the nondiffractive inelastic one, this <ei>pT0</ei> will
166automatically be scaled down to cope.
167
168<p/>
169The actual <ei>pT0</ei> parameter used at a given CM energy scale,
170<ei>ecmNow</ei>, is obtained as
171<eq>
172 pT0 = pT0(ecmNow) = pT0Ref * (ecmNow / ecmRef)^ecmPow
173</eq>
174where <ei>pT0Ref</ei>, <ei>ecmRef</ei> and <ei>ecmPow</ei> are the
175three parameters below.
176
177<parm name="MultipartonInteractions:pT0Ref" default="2.15" min="0.5"
178max="10.0">
179The <ei>pT0Ref</ei> scale in the above formula.
180<note>Note:</note> <ei>pT0Ref</ei> is one of the key parameters in a
181complete PYTHIA tune. Its value is intimately tied to a number of other
182choices, such as that of colour flow description, so unfortunately it is
183difficult to give an independent meaning to <ei>pT0Ref</ei>.
184</parm>
185
186<parm name="MultipartonInteractions:ecmRef" default="1800.0" min="1.">
187The <ei>ecmRef</ei> reference energy scale introduced above.
188</parm>
189
190<parm name="MultipartonInteractions:ecmPow" default="0.24" min="0.0"
191max="0.5">
192The <ei>ecmPow</ei> energy rescaling pace introduced above.
193</parm>
194
195<p/>
196Alternatively, or in combination, a sharp cut can be used.
197<parm name="MultipartonInteractions:pTmin" default="0.2" min="0.1"
198max="10.0">
199Lower cutoff in <ei>pT</ei>, below which no further interactions
200are allowed. Normally <ei>pT0</ei> above would be used to provide
201the main regularization of the cross section for <ei>pT -> 0</ei>,
202in which case <ei>pTmin</ei> is used mainly for technical reasons.
203It is possible, however, to set <ei>pT0Ref = 0</ei> and use
204<ei>pTmin</ei> to provide a step-function regularization, or to
205combine them in intermediate approaches. Currently <ei>pTmin</ei>
206is taken to be energy-independent.
207</parm>
208
209<p/>
210G&ouml;sta Gustafson has proposed (private communication, unpublished)
211that the amount of screening, as encapsulated in the <ei>pT0</ei>
212parameter, fluctuates from one event to the next. Specifically,
213high-activity event are more likely to lead to interactions at large
214<ei>pT</ei> scales, but the high activity simultaneously leads to a
215larger screening of interactions at smaller <ei>pT</ei>. Such a scenario
216can approximately be simulated by scaling up the <ei>pT0</ei> by a
217factor <ei>sqrt(n)</ei>, where <ei>n</ei> is the number of interactions
218considered so far, including the current one. That is, for the first
219interaction the dampening factor is <ei>pT^4 / (pT0^2 + pT^2)^2</ei>,
220for the second <ei>pT^4 / (2 pT0^2 + pT^2)^2</ei>, for the third
221<ei>pT^4 / (3 pT0^2 + pT^2)^2</ei>, and so on. Optionally the scheme
222may also be applied to ISR emissions. For simplicity the same
223<ei>alpha_s(pT0^2 + pT^2)</ei> is used throughout. Note that, in this
224scenario the <ei>pT0</ei> scale must be lower than in the normal case
225to begin with, since it later is increased back up. Also note that the
226idea with this scenario is to propose an alternative to colour
227reconnection to understand the rise of <ei>&lt;pT&gt;(n_ch)</ei>,
228so that the amount of colour reconnection should be reduced.
229<modepick name="MultipartonInteractions:enhanceScreening" default="0"
230min="0" max="2">
231Choice to activate the above screening scenario, i.e. an increasing
232effective <ei>pT0</ei> for consecutive interactions.
233<option value="0">No activity-dependent screening, i.e. <ei>pT0</ei>
234is fixed.</option>
235<option value="1">The <ei>pT0</ei> scale is increased as a function
236of the number of MPI's, as explained above. ISR is not affected,
237but note that, if <code>SpaceShower:samePTasMPI</code> is on,
238then <code>MultipartonInteractions:pT0Ref</code> is used also for ISR,
239which may or may not be desirable.
240 </option>
241<option value="2">Both MPI and ISR influence and are influenced by the
242screening. That is, the dampening is reduced based on the total number
243of MPI and ISR steps considered so far, including the current one.
244This dampening is implemented both for MPI and for ISR emissions,
245for the latter provided that <code>SpaceShower:samePTasMPI</code> is on
246(default).
247</option>
248</modepick>
249
250<h4>Impact-parameter dependence</h4>
251
252The choice of impact-parameter dependence is regulated by several
253parameters. The ones listed here refer to nondiffractive topologies
254only, while their equivalents for diffractive events are put in the
255<aloc href="Diffraction">Diffraction</aloc> description. Note that
256there is currently no <code>bProfile = 4</code> option for diffraction.
257Other parameters are assumed to agree between diffractive and
258nondiffractive topologies.
259
260<modepick name="MultipartonInteractions:bProfile" default="1"
261min="0" max="4">
262Choice of impact parameter profile for the incoming hadron beams.
263<option value="0">no impact parameter dependence at all.</option>
264<option value="1">a simple Gaussian matter distribution;
265no free parameters.</option>
266<option value="2">a double Gaussian matter distribution,
267with the two free parameters <ei>coreRadius</ei> and
268<ei>coreFraction</ei>.</option>
269<option value="3">an overlap function, i.e. the convolution of
270the matter distributions of the two incoming hadrons, of the form
271<ei>exp(- b^expPow)</ei>, where <ei>expPow</ei> is a free
272parameter.</option>
273<option value="4">a Gaussian matter distribution with a width
274that varies according to the selected <ei>x</ei> value of an interaction,
275<ei>1. + a1 log (1 / x)</ei>, where <ei>a1</ei> is a free parameter.
276Note that once <ei>b</ei> has been selected for the hard process,
277it remains fixed for the remainder of the evolution.
278</option>
279</modepick>
280
281<parm name="MultipartonInteractions:coreRadius" default="0.4"
282min="0.1" max="1.">
283When assuming a double Gaussian matter profile, <ei>bProfile = 2</ei>,
284the inner core is assumed to have a radius that is a factor
285<ei>coreRadius</ei> smaller than the rest.
286</parm>
287
288<parm name="MultipartonInteractions:coreFraction" default="0.5"
289min="0." max="1.">
290When assuming a double Gaussian matter profile, <ei>bProfile = 2</ei>,
291the inner core is assumed to have a fraction <ei>coreFraction</ei>
292of the matter content of the hadron.
293</parm>
294
295<parm name="MultipartonInteractions:expPow" default="1." min="0.4" max="10.">
296When <ei>bProfile = 3</ei> it gives the power of the assumed overlap
297shape <ei>exp(- b^expPow)</ei>. Default corresponds to a simple
298exponential drop, which is not too dissimilar from the overlap
299obtained with the standard double Gaussian parameters. For
300<ei>expPow = 2</ei> we reduce to the simple Gaussian, <ei>bProfile = 1</ei>,
301and for <ei>expPow -> infinity</ei> to no impact parameter dependence
302at all, <ei>bProfile = 0</ei>. For small <ei>expPow</ei> the program
303becomes slow and unstable, so the min limit must be respected.
304</parm>
305
306<parm name="MultipartonInteractions:a1" default="0.15" min="0." max="2.">
307When <ei>bProfile = 4</ei>, this gives the <ei>a1</ei> constant in the
308Gaussian width. When <ei>a1 = 0.</ei>, this reduces back to the single
309Gaussian case.
310</parm>
311
312<h4>Rescattering</h4>
313
314It is possible that a parton may rescatter, i.e. undergo a further
315interaction subsequent to the first one. The machinery to model this
316kind of physics has only recently become fully operational
317<ref>Cor09</ref>, and is therefore not yet so well explored.
318
319<p/>
320The rescatting framework has ties with other parts of the program,
321notably with the <aloc href="BeamRemnants">beam remnants</aloc>.
322
323<flag name="MultipartonInteractions:allowRescatter" default="off">
324Switch to allow rescattering of partons; on/off = true/false.<br/>
325<b>Note:</b> the rescattering framework has not yet been implemented
326for the <code>MultipartonInteractions:bProfile = 4</code> option,
327and can therefore not be switched on in that case.
328<b>Warning:</b> use with caution since machinery is still not
329so well tested.
330</flag>
331
332<flag name="MultipartonInteractions:allowDoubleRescatter" default="off">
333Switch to allow rescattering of partons, where both incoming partons
334have already rescattered; on/off = true/false. Is only used if
335<code>MultipartonInteractions:allowRescatter</code> is switched on.<br/>
336<b>Warning:</b> currently there is no complete implementation that
337combines it with shower evolution, so you must use
338<code>PartonLevel:ISR = off</code> and <code>PartonLevel:FSR = off</code>.
339If not, a warning will be issued and double rescattering will not be
340simulated. The rate also comes out to be much lower than for single
341rescattering, so to first approximation it can be neglected.
342</flag>
343
344<modepick name="MultipartonInteractions:rescatterMode" default="0"
345min="0" max="4">
346Selection of which partons rescatter against unscattered partons
347from the incoming beams A and B, based on their rapidity value
348<ei>y</ei> in the collision rest frame. Here <ei>ySep</ei> is
349shorthand for <code>MultipartonInteractions:ySepRescatter</code> and
350<ei>deltaY</ei> for <code>MultipartonInteractions:deltaYRescatter</code>,
351defined below. The description is symmetric between the two beams,
352so only one case is described below.
353<option value="0">only scattered partons with <ei>y > 0</ei>
354can collide with unscattered partons from beam B.</option>
355<option value="1">only scattered partons with <ei>y > ySep</ei>
356can collide with unscattered partons from beam B.</option>
357<option value="2">the probability for a scattered parton to be considered
358as a potential rescatterer against unscattered partons in beam B increases
359linearly from zero at <ei>y = ySep - deltaY</ei> to unity at
360<ei>y = ySep + deltaY</ei>.</option>
361<option value="3">the probability for a scattered parton to be considered
362as a potential rescatterer against unscattered partons in beam B increases
363with <ei>y</ei> according to
364<ei>(1/2) * (1 + tanh( (y - ySep) / deltaY))</ei>.</option>
365<option value="4">all partons are potential rescatterers against both
366beams.</option>
367</modepick>
368
369<parm name="MultipartonInteractions:ySepRescatter" default="0.">
370used for some of the <code>MultipartonInteractions:rescatterMode</code>
371options above, as the rapidity for which a scattered parton has a 50%
372probability to be considered as a potential rescatterer.
373A <ei>ySep > 0</ei> generally implies that some central partons cannot
374rescatter at all, while a <ei>ySep < 0</ei> instead allows central
375partons to scatter against either beam.
376</parm>
377
378<parm name="MultipartonInteractions:deltaYRescatter" default="1." min="0.1">
379used for some of the <code>MultipartonInteractions:rescatterMode</code>
380options above, as the width of the rapidity transition region, where the
381probability rises from zero to unity that a scattered parton is considered
382as a potential rescatterer.
383</parm>
384
385
386<h3>Further variables</h3>
387
388These should normally not be touched. Their only function is for
389cross-checks.
390
391<modeopen name="MultipartonInteractions:nQuarkIn" default="5" min="0"
392max="5">
393Number of allowed incoming quark flavours in the beams; a change
394to 4 would thus exclude <ei>b</ei> and <ei>bbar</ei> as incoming
395partons, etc.
396</modeopen>
397
398<modeopen name="MultipartonInteractions:nSample" default="1000" min="100">
399The allowed <ei>pT</ei> range is split (unevenly) into 100 bins,
400and in each of these the interaction cross section is evaluated in
401<ei>nSample</ei> random phase space points. The full integral is used
402at initialization, and the differential one during the run as a
403"Sudakov form factor" for the choice of the hardest interaction.
404A larger number implies increased accuracy of the calculations.
405</modeopen>
406
407<h3>Technical notes</h3>
408
409Relative to the articles mentioned above, not much has happened.
410The main news is a technical one, that the phase space of the
411<ei>2 -> 2</ei> (massless) QCD processes is now sampled in
412<ei>dy_3 dy_4 dpT^2</ei>, where <ei>y_3</ei> and <ei>y_4</ei> are
413the rapidities of the two produced partons. One can show that
414<eq>
415 (dx_1 / x_1) * (dx_2 / x_2) * d(tHat) = dy_3 * dy_4 * dpT^2
416</eq>
417Furthermore, since cross sections are dominated by the "Rutherford"
418one of <ei>t</ei>-channel gluon exchange, which is enhanced by a
419factor of 9/4 for each incoming gluon, effective structure functions
420are defined as
421<eq>
422 F(x, pT2) = (9/4) * xg(x, pT2) + sum_i xq_i(x, pT2)
423</eq>
424With this technical shift of factors 9/4 from cross sections to parton
425densities, a common upper estimate of
426<eq>
427 d(sigmaHat)/d(pT2) &lt; pi * alpha_strong^2 / pT^4
428</eq>
429is obtained.
430
431<p/>
432In fact this estimate can be reduced by a factor of 1/2 for the
433following reason: for any configuration <ei>(y_3, y_4, pT2)</ei> also
434one with <ei>(y_4, y_3, pT2)</ei> lies in the phase space. Not both
435of those can enjoy being enhanced by the <ei>tHat -> 0</ei>
436singularity of
437<eq>
438 d(sigmaHat) propto 1/tHat^2.
439</eq>
440Or if they are, which is possible with identical partons like
441<ei>q q -> q q</ei> and <ei>g g -> g g</ei>, each singularity comes
442with half the strength. So, when integrating/averaging over the two
443configurations, the estimated <ei>d(sigmaHat)/d(pT2)</ei> drops.
444Actually, it drops even further, since the naive estimate above is
445based on
446<eq>
447 (4 /9) * (1 + (uHat/sHat)^2) &lt; 8/9 &lt; 1
448</eq>
449The 8/9 value would be approached for <ei>tHat -> 0</ei>, which
450implies <ei>sHat >> pT2</ei> and thus a heavy parton-distribution
451penalty, while parton distributions are largest for
452<ei>tHat = uHat = -sHat/2</ei>, where the above expression
453evaluates to 5/9. A fudge factor is therefore introduced to go the
454final step, so it can easily be modifed when further non-Rutherford
455processes are added, or should parton distributions change significantly.
456
457<p/>
458At initialization, it is assumed that
459<eq>
460 d(sigma)/d(pT2) &lt; d(sigmaHat)/d(pT2) * F(x_T, pT2) * F(x_T, pT2)
461 * (2 y_max(pT))^2
462</eq>
463where the first factor is the upper estimate as above, the second two
464the parton density sum evaluated at <ei>y_3 = y_ 4 = 0</ei> so that
465<ei>x_1 = x_2 = x_T = 2 pT / E_cm</ei>, where the product is expected
466to be maximal, and the final is the phase space for
467<ei>-y_max &lt; y_{3,4} &lt; y_max</ei>.
468The right-hand side expression is scanned logarithmically in <ei>y</ei>,
469and a <ei>N</ei> is determined such that it always is below
470<ei>N/pT^4</ei>.
471
472<p/>
473To describe the dampening of the cross section at <ei>pT -> 0</ei> by
474colour screening, the actual cross section is multiplied by a
475regularization factor <ei>(pT^2 / (pT^2 + pT0^2))^2</ei>, and the
476<ei>alpha_s</ei> is evaluated at a scale <ei>pT^2 + pT0^2</ei>,
477where <ei>pT0</ei> is a free parameter of the order of 2 - 4 GeV.
478Since <ei>pT0</ei> can be energy-dependent, an ansatz
479<eq>
480 pT0(ecm) = pT0Ref * (ecm/ecmRef)^ecmPow
481</eq>
482is used, where <ei>ecm</ei> is the current CM frame energy,
483<ei>ecmRef</ei> is an arbitrary reference energy where <ei>pT0Ref</ei>
484is defined, and <ei>ecmPow</ei> gives the energy rescaling pace. For
485technical reasons, also an absolute lower <ei>pT</ei> scale <ei>pTmin</ei>,
486by default 0.2 GeV, is introduced. In principle, it is possible to
487recover older scenarios with a sharp <ei>pT</ei> cutoff by setting
488<ei>pT0 = 0</ei> and letting <ei>pTmin</ei> be a larger number.
489
490<p/>
491The above scanning strategy is then slightly modified: instead of
492an upper estimate <ei>N/pT^4</ei> one of the form
493<ei>N/(pT^2 + r * pT0^2)^2</ei> is used. At first glance, <ei>r = 1</ei>
494would seem to be fixed by the form of the regularization procedure,
495but this does not take into account the nontrivial dependence on
496<ei>alpha_s</ei>, parton distributions and phase space. A better
497Monte Carlo efficiency is obtained for <ei>r</ei> somewhat below unity,
498and currently <ei>r = 0.25</ei> is hardcoded.
499
500In the generation a trial <ei>pT2</ei> is then selected according to
501<eq>
502 d(Prob)/d(pT2) = (1/sigma_ND) * N/(pT^2 + r * pT0^2)^2 * ("Sudakov")
503</eq>
504For the trial <ei>pT2</ei>, a <ei>y_3</ei> and a <ei>y_4</ei> are then
505selected, and incoming flavours according to the respective
506<ei>F(x_i, pT2)</ei>, and then the cross section is evaluated for this
507flavour combination. The ratio of trial/upper estimate gives the
508probability of survival.
509
510<p/>
511Actually, to profit from the factor 1/2 mentioned above, the cross
512section for the combination with <ei>y_3</ei> and <ei>y_4</ei>
513interchanged is also tried, which corresponds to exchanging <ei>tHat</ei>
514and <ei>uHat</ei>, and the average formed, while the final kinematics
515is given by the relative importance of the two.
516
517<p/>
518Furthermore, since large <ei>y</ei> values are disfavoured by dropping
519PDF's, a factor
520<eq>
521 WT_y = (1 - (y_3/y_max)^2) * (1 - (y_4/y_max)^2)
522</eq>
523is evaluated, and used as a survival probability before the more
524time-consuming PDF+ME evaluation, with surviving events given a
525compensating weight <ei>1/WT_y</ei>.
526
527<p/>
528An impact-parameter dependencs is also allowed. Based on the hard
529<ei>pT</ei> scale of the first interaction, and enhancement/depletion
530factor is picked, which multiplies the rate of subsequent interactions.
531
532<p/>
533Parton densities are rescaled and modified to take into account the
534energy-momentum and flavours kicked out by already-considered
535interactions.
536
537</chapter>
538
539<!-- Copyright (C) 2012 Torbjorn Sjostrand -->