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