source: HiSusy/trunk/Pythia8/pythia8170/htmldoc/AdvancedUsage.html @ 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: 10.9 KB
Line 
1<html>
2<head>
3<title>Advanced Usage</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>Advanced Usage</h2>
10
11On this page we collect information on a number of classes that
12the normal user would not encounter. There are cases where the
13information is essential, however, for instance to
14<a href="ImplementNewShowers.html" target="page">implement your own showers</a>.
15
16<h3>The subsystems</h3>
17
18One aspect that complicates administration is that an event
19can contain several subsystems, each consisting of one MPI and its
20associated ISR and FSR. To first approximation these systems are
21assumed to evolve independently, but to second they are connected by
22the interleaved evolution, and potentially by rescattering effects.
23The partons of a given subsystem therefore do not have to be stored
24consecutively.
25
26<p/>
27The <code>PartonSystems</code> class is primarily used to keep track
28of the current positions of all partons belonging to each system,
29represented by the index <code>iPos</code> for a parton stored in the
30event-record slot <code>event[iPos]</code>. With "all" we mean the
31currently defined two incoming partons, or none for a resonance decay,
32and the current set of outgoing partons, but with all ISR and FSR
33intermediate-state partons omitted. That is, it stores all partons
34that could be subject to some action in the next step of the
35combined MPI/ISR/FSR/BR description. As a special case, an outgoing
36parton is stored even if it undergoes a rescattering, and thus no
37longer belongs to the final state proper.
38
39<p/>
40The <code>partonSystems</code> instance of <code>PartonSystems</code> 
41class is a public member of the <code>Pythia</code> top-level class,
42but is also available as a pointer <code>partonSystemsPtr</code> in
43various <code>PartonLevel</code> classes, e.g. inside the current
44instances of the <code>TimeShower</code> and <code>SpaceShower</code> 
45classes.
46
47<p/>
48A number of <code>PartonSystems</code> methods can be used to set or
49get information on the subsystems:
50<ul>
51<li><code>clear()</code> resets all the contents in preparation for the
52next event.
53<li><code>addSys()</code> add a new (initially empty) subsystem to the
54current list and return its index <code>iSys</code> in the list,
55where index 0 is the hardest subcollision and so on.
56<li><code>sizeSys()</code> the number of separate subsystems.</li>
57<li><code>setInA(iSys, iPos), setInB(iSys, iPos)</code> store position
58<code>iPos</code> of the incoming parton from beam A or beam B to the
59<code>iSys</code>'th subcollision. These values are 0 initially, and
60should so remain if there are no beams, such as in resonance decays.
61</li> 
62<li><code>addOut(iSys, iPos)</code> store position <code>iPos</code>
63of a new outgoing parton in the <code>iSys</code>'th subcollision,
64by appending it at the end of the current vector, with beginning in
65slot 0.</li> 
66<li><code>setOut(iSys, iMem, iPos)</code> store position <code>iPos</code>
67in the <code>iMem</code>'th slot in the vector of outgoing partons in the
68<code>iSys</code>'th subcollision. Here <code>iMem</code> must be in
69the range already constructed by <code>addOut</code> calls. </li> 
70<li><code>replace(iSys, iPosOld, iPosNew)</code> replace the existing
71incoming or outgoing parton position <code>iPosOld</code> by
72<code>iPosNew</code> in the <code>iSys</code>'th subcollision.</li> 
73<li><code>setSHat(iSys, sHat)</code> set the invariant squared mass
74<code>sHat</code> of the <code>iSys</code>'th subcollision.</li> 
75<li><code>hasInAB(iSys)</code> true if an incoming parton has been set
76for beam A or beam B (and hence should have been set for both) in the
77<code>iSys</code>'th subcollision, else false.</li> 
78<li><code>getInA(iSys), getInB(iSys)</code> the position <code>iPos</code>
79of the incoming parton from beam A or beam B to the <code>iSys</code>'th
80subcollision.</li> 
81<li><code>sizeOut(iSys)</code> the number of outgoing partons
82in the <code>iSys</code>'th subcollision.</li> 
83<li><code>getOut(iSys, iMem)</code> the position <code>iPos</code>
84of an outgoing parton in the <code>iSys</code>'th subcollision,
85with the <code>iMem</code> range limited by <code>sizeOut(iSys)</code>.
86These partons are not guaranteed to appear in any particular order. </li> 
87<li><code>sizeAll(iSys)</code> the total number of incoming and outgoing
88partons in the <code>iSys</code>'th subcollision.</li> 
89<li><code>getAll(iSys, iMem)</code> the position <code>iPos</code>
90of an incoming or outgoing parton in the <code>iSys</code>'th subcollision.
91In case there are beams it gives same as <code>getInA(iSys) </code> and
92<code> getInB(iSys)</code> for indices 0 and 1, and thereafter agrees with
93<code>getOut(iSys, iMem)</code> offset two positions. If there are no
94beams it is identical with <code>getOut(iSys, iMem)</code>.</li> 
95<li><code>getSHat(iSys)</code> the invariant squared mass
96<code>sHat</code> of the <code>iSys</code>'th subcollision.</li> 
97<li><code>list()</code> print a listing of all the system information,
98except for the <code>sHat</code> values.</li> 
99</ul>
100
101<p/>
102New systems are created from the hard process and by the MPI, not from
103any of the other components. Both FSR and ISR modify the position
104of partons, however. Since an FSR or ISR branching typically implies
105a new state with one more parton than before, an outgoing parton must
106be added to the system. Furthermore, in a branching, several existing
107partons may also be moved to new slots, including the incoming beam ones.
108In a FSR <i>1 -> 2</i> branching it is irrelevant which parton position
109you let overwrite the existing slot and which is added to the end of
110the system.
111
112<p/>
113The system information must be kept up-to-date. Both the MPI, ISR, FSR and
114BR descriptions make extensive use of the existing information. As an
115example, the introduction of primordial <i>kT</i> in the beam remnants
116will fail if the information on which final-state partons belong to which
117system is out-of-date. The introduction of rescattering as part of the
118MPI framework adds further complications, where an outgoing parton of one
119subsystem may be the incoming one of another system. This part of the code
120is still under development.
121
122<p/>
123Currently the system information is kept throughout the continued
124history of the event. Specifically, resonance decays create new systems,
125appended to the existing ones. This could be useful during the
126hadronization stage, to collect the partons that belong to a resonace
127with preserved mass when a small string collapses to one particle,
128but is not yet used for that.
129
130<h3>The beams</h3>
131 
132The different subsystems are tied together by them sharing the same
133initial beam particles, and thereby being restricted by energy-momentum
134and flavour conservation issues. The information stored in the two
135beam particles, here called <code>beamA</code> and <code>beamB</code>,
136is therefore as crucial to keep correct as the above subsystem list.
137
138<p/>
139Both beam objects are of the <code>BeamParticle</code> class.
140Each such object contains a vector with the partons extracted from it.
141The number of such partons, <code>beamX.size()</code> (X = A or B),
142of course is the same as the above number of subsystems in the event
143record. (The two diverge at the BR step, where further beam remnants
144are added to the beams without corresponding to new subsystems.)
145The individual partons are accessed by an overloaded indexing
146operator to a vector of <code>ResolvedParton</code> objects. The
147<code>iPos()</code> property corresponds to the <code>iPos</code>
148one above, i.e. providing the position in the main event record of
149a parton. In particular,
150<code>beamA[iSys].iPos() = partonSystemsPtr->getInA(iSys)</code> and
151<code>beamB[iSys].iPos() = partonSystemsPtr->getInB(iSys)</code>.
152Whereas thus the indices of the two incoming partons to a subsystem
153are stored in two places, the ones of the outgoing partons only
154appear in the system part of the <code>PartonSystems</code> class.
155
156<p/>
157Just as the subsystems in <code>PartonSystems</code> must be updated,
158so must the information in the two <code>BeamParticle</code>'s, e.g.
159with methods<code>beamX[iSys].iPos( iPosIn)</code> when an incoming
160parton is replaced by a new one in line <code>iPosIn</code>. Furthermore
161the new parton identity should be set by <code>beamX[iSys].id( idIn)</code> 
162and the new <i>x</i> energy-momentum fraction by
163<code>beamX[iSys].x( xIn)</code>. The three can be combined in one go
164by <code>beamX[iSys].update( iPosIn, idIn, xIn)</code>.
165
166<p/>
167To be specific, it is assumed that, at each step, the two incoming
168partons are moving along the <i>+-z</i> axis and are massless.
169Since the event is constructed in the c.m. frame of the incoming
170beams this implies that <i>x = 2 E / E_cm</i>.     
171If the <i>x</i> values are not defined accordingly or not kept
172up-to-date the BR treatment will not conserve energy-momentum.
173 
174<p/>
175In return, the <code>BeamParticle</code> objects give access to some
176useful methods. The <code>beamX.xf( id, x, Q2)</code> returns the
177standard PDF weight <i>x f_id(x, Q^2)</i>. More intererstingly,
178<code>beamX.xfISR( iSys, id, x, Q2)</code> returns the modified weight
179required when several subsystems have to share the energy and flavours.
180Thus <code>iSys</code> is added as an extra argument, and the momentum
181already assigned to the other subsystems is not available for evolution,
182i.e. the maximal <i>x</i> is correspondingly smaller than unity.
183Also flavour issues are handled in a similar spirit.   
184 
185<p/>
186An additional complication is that a parton can be either valence or
187sea, and in the latter case the BR treatment also distinguishes
188companion quarks, i.e. quark-antiquark pairs that are assumed to
189come from the same original <i>g -> q qbar</i> branching, whether
190perturbative or not. This can be queried either with the
191<code>beamX[iSys].companion()</code> method, for detailed information,
192or with the <code>beamX[iSys].isValence()</code>,
193<code>beamX[iSys].isUnmatched()</code> and
194<code>beamX[iSys].isCompanion()</code> metods for yes/no answers
195whether a parton is valence, unmatched sea or matched sea.
196This choice should affect the ISR evolution; e.g., a valence quark
197cannot be constructed back to come from a gluon.
198 
199<p/>
200To keep this info up-to-date, the <code>beamX.pickValSeaComp()</code>
201method should be called whenever a parton of a new flavour has been
202picked in the ISR backwards evolution, but not if the flavour has not
203been changed, since then one should not be allowed to switch back and
204forth between the same quark being considered as valence or as sea.
205Since the <code>pickValSeaComp()</code> method makes use of the
206current parton-density values, it should be preceded by a call
207to <code>beamX.xfISR( iSys, id, x, Q2)</code>, where the values in
208the call are the now finally accepted ones for the newly-found mother.
209(Such a call is likely to have been made before, during the evolution,
210but is not likely to be the most recent one, i.e. still in memory, and
211therefore had better be redone.)
212     
213</body>
214</html>
215
216<!-- Copyright (C) 2012 Torbjorn Sjostrand -->
Note: See TracBrowser for help on using the repository browser.