Context Navigation

← Previous Revision
Latest Revision
Next Revision →
Blame
Revision Log

EventRecord.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: 25.6 KB

Line
1	<html>
2	<head>
3	<title>The Event Record</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>
10	function stopRKey(evt) {
11	var evt = (evt) ? evt : ((event) ? event : null);
12	var node = (evt.target) ? evt.target :((evt.srcElement) ? evt.srcElement : null);
13	if ((evt.keyCode == 13) && (node.type=="text"))
14	{return false;}
15	}
16
17	document.onkeypress = stopRKey;
18	</script>
19	<?php
20	if($_POST['saved'] == 1) {
21	if($_POST['filepath'] != "files/") {
22	echo "<font color='red'>SETTINGS SAVED TO FILE</font><br/><br/>"; }
23	else {
24	echo "<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='EventRecord.php'>
29
30	<h2>The Event Record</h2>
31
32	A <code>Pythia</code> instance contains two members of the
33	<code>Event</code> class. The one called <code>process</code> provides
34	a brief summary of the main steps of the hard process, while the
35	one called <code>event</code> contains the full history. The
36	user would normally interact mainly with the second one, so
37	we will examplify primarily with that one.
38
39	<p/>
40	The <code>Event</code> class to first approximation is a vector of
41	<code>Particle</code>s, so that it can expand to fit the current
42	event size. The index operator is overloaded, so that e.g.
43	<code>event[i]</code> corresponds to the <i>i</i>'th particle
44	of the object <code>event</code>. Thus <code>event[i].id()</code>
45	returns the identity of the <i>i</i>'th particle, and so on.
46	Therefore the methods of the
47	<code><?php $filepath = $_GET["filepath"];
48	echo "<a href='ParticleProperties.php?filepath=".$filepath."' target='page'>";?>Particle</a></code> class
49	are at least as essential as those of the <code>Event</code> class
50	itself.
51
52	<p/>
53	As used inside PYTHIA, some conventions are imposed on the structure
54	of the event record. Entry 0 of the <code>vector<Particle></code>
55	is used to represent the event as a whole, with its total four-momentum
56	and invariant mass, but does not form part of the event history.
57	Lines 1 and 2 contains the two incoming beams, and only from here on
58	history tracing works as could be expected. That way unassigned mother
59	and daughter indices can be put 0 without ambiguity. Depending on the
60	task at hand, a loop may therefore start at index 1 rather than 0
61	without any loss. Specifically, for translation to other event record
62	formats such as HepMC [<a href="Bibliography.php" target="page">Dob01</a>], where the first index is 1, the
63	Pythia entry 0 definitely ought to be skipped in order to minimize the
64	danger of indexing errors.
65
66	<p/>
67	In the following we will list the methods available.
68	Only a few of them have a function to fill in normal user code.
69
70	<h3>Basic output methods</h3>
71
72	Some methods are available to read out information on the
73	current event record:
74
75	<a name="method1"></a>
76	<p/><strong>Particle& Event::operator[](int i)  </strong> <br/>
77
78	<strong>const Particle& Event::operator[](int i)  </strong> <br/>
79
80	<strong>Particle& Event::at(int i)  </strong> <br/>
81	returns a (<code>const</code>) reference to the <i>i</i>'th particle
82	in the event record, which can be used to get (or set) all the
83	<?php $filepath = $_GET["filepath"];
84	echo "<a href='ParticleProperties.php?filepath=".$filepath."' target='page'>";?>properties</a> of this particle.
85
86
87	<a name="method2"></a>
88	<p/><strong>int Event::size()  </strong> <br/>
89	The event size, i.e. the sie of the <code>vector<Particle></code>.
90	Thus valid particles, to be accessed by the above indexing operator,
91	are stored in the range <i>0 <= i < size()</i>. See comment
92	above about the (ir)relevance of entry 0.
93
94
95	<a name="method3"></a>
96	<p/><strong>void Event::list()  </strong> <br/>
97
98	<strong>void Event::list(ostream& os)  </strong> <br/>
99
100	<strong>void Event::list(bool showScaleAndVertex, bool showMothersAndDaughters = false)  </strong> <br/>
101
102	<strong>void Event::list(bool showScaleAndVertex, bool showMothersAndDaughters, ostream& os)  </strong> <br/>
103	Provide a listing of the whole event, i.e. of the
104	<code>vector<Particle></code>. The methods with fewer arguments
105	call the final one with the respective default values, and are
106	non-inlined so they can be used in a debugger. The basic identity
107	code, status, mother, daughter, colour, four-momentum and mass data
108	are always given, but the methods can also be called with a few
109	optional arguments for further information:
110	<br/><code>argument</code><strong> showScaleAndVertex </strong> (<code>default = <strong>false</strong></code>) : optionally give a
111	second line for each particle, with the production scale (in GeV),
112	the particle polarization (dimensionless), the production vertex
113	(in mm or mm/c) and the invariant lifetime (also in mm/c).
114
115	<br/><code>argument</code><strong> showMothersAndDaughters </strong> (<code>default = <strong>false</strong></code>) :
116	gives a list of all daughters and mothers of a particle, as defined by
117	the <code>motherList(i)</code> and <code>daughterList(i)</code> methods
118	described below. It is mainly intended for debug purposes.
119
120	<br/><code>argument</code><strong> os </strong> (<code>default = <strong>cout</strong></code>) : a reference to the <code>ostream</code>
121	object to which the event listing will be directed.
122
123
124
125
126	<p/>
127	Each <code>Particle</code> has two mother and two daughter indices.
128	These may be used to encode zero, one, two or more mothers/daughters,
129	depending on the combination of values and status code, according to
130	well-defined <?php $filepath = $_GET["filepath"];
131	echo "<a href='ParticleProperties.php?filepath=".$filepath."' target='page'>";?>rules</a>. The
132	two methods below can do this job easier for you.
133
134	<a name="method4"></a>
135	<p/><strong>vector<int> Event::motherList(int i)  </strong> <br/>
136	returns a vector of all the mother indices of the particle at index
137	<i>i</i>. This list is empty for entries 0, 1 and 2,
138	i.e. the "system" in line 0 is not counted as part of the history.
139	Normally the list contains one or two mothers, but it can also be more,
140	e.g. in string fragmentation the whole fragmenting system is counted
141	as mothers to the primary hadrons. Many particles may have the same
142	<code>motherList</code>. Mothers are listed in ascending order.
143
144
145	<a name="method5"></a>
146	<p/><strong>vector<int> Event::daughterList(int i)  </strong> <br/>
147	returns a vector of all the daughter indices of the particle at index
148	<i>i</i>. This list is empty for a particle that did
149	not decay (or, if the evolution is stopped early enough, a parton
150	that did not branch), while otherwise it can contain a list of
151	varying length, from one to many. For the two incoming beam particles,
152	all shower initiators and beam remnants are counted as daughters,
153	with the one in slot 0 being the one leading up to the hardest
154	interaction. The "system" in line 0 does not have any daughters,
155	i.e. is not counted as part of the history. Many partons may have the
156	same <code>daughterList</code>. Daughters are listed in ascending order.
157
158
159	<a name="method6"></a>
160	<p/><strong>int Event::statusHepMC(int i)  </strong> <br/>
161	returns the status code according to the HepMC conventions agreed in
162	February 2009. This convention does not preserve the full information
163	provided by the internal PYTHIA status code, as obtained by
164	<code>Particle::status()</code>, but comes reasonably close.
165	The allowed output values are:
166	<ul>
167	<li>0 : an empty entry, with no meaningful information and therefore
168	to be skipped unconditionally (should not occur in PYTHIA);</li>
169	<li>1 : a final-state particle, i.e. a particle that is not decayed
170	further by the generator (may also include unstable particles that
171	are to be decayed later, as part of the detector simulation);</li>
172	<li>2 : a decayed Standard Model hadron or tau or mu lepton, excepting
173	virtual intermediate states thereof (i.e. the particle must undergo
174	a normal decay, not e.g. a shower branching);</li>
175	<li>3 : a documentation entry (not used in PYTHIA);</li>
176	<li>4 : an incoming beam particle;</li>
177	<li>11 - 200 : an intermediate (decayed/branched/...) particle that does
178	not fulfill the criteria of status code 2, with a generator-dependent
179	classification of its nature; in PYTHIA the absolute value of the normal
180	status code is used.</li>
181	</ul>
182
183
184
185	<h3>Further output methods</h3>
186
187	The above methods are the main ones that a normal user would make
188	frequent use of. There are some further methods that also could come
189	in handy, in the exploration of the history of an event, but where
190	the outcome is not always obvious if one is not familiar with the
191	detailed structure of an event record.
192
193	<a name="method7"></a>
194	<p/><strong>int Event::iTopCopy(int i)  </strong> <br/>
195
196	<strong>int Event::iBotCopy(int i)  </strong> <br/>
197	are used to trace carbon copies of the particle at index <i>i</i> up
198	to its top mother or down to its bottom daughter. If there are no such
199	carbon copies, <i>i</i> itself will be returned. A carbon copy is
200	when the "same" particle appears several times in the event record, but
201	with changed momentum owing to recoil effects.
202
203
204	<a name="method8"></a>
205	<p/><strong>int Event::iTopCopyId(int i)  </strong> <br/>
206
207	<strong>int Event::iBotCopyId(int i)  </strong> <br/>
208	also trace top mother and bottom daughter, but do not require carbon
209	copies, only that one can find an unbroken chain, of mothers or daughters,
210	with the same flavour <code>id</code> code. When it encounters ambiguities,
211	say a <i>g -> g g</i> branching or a <i>u u -> u u</i> hard scattering,
212	it will stop the tracing and return the current position. It can be confused
213	by nontrivial flavour changes, e.g. a hard process <i>u d -> d u</i>
214	by <i>W^+-</i> exchange will give the wrong answer. These methods
215	therefore are of limited use for common particles, in particular for the
216	gluon, but should work well for "rare" particles.
217
218
219	<a name="method9"></a>
220	<p/><strong>vector<int> Event::sisterList(int i)  </strong> <br/>
221	returns a vector of all the sister indices of the particle at index
222	<i>i</i>, i.e. all the daughters of the first mother, except the
223	particle itself.
224
225
226	<a name="method10"></a>
227	<p/><strong>vector<int> Event::sisterListTopBot(int i,bool widenSearch = true)  </strong> <br/>
228	returns a vector of all the sister indices of the particle at index
229	<i>i</i>, tracking up and back down through carbon copies
230	if required. That is, the particle is first traced up with
231	<code>iTopCopy()</code> before its mother is found, and then all
232	the particles in the <code>daughterList()</code> of this mother are
233	traced down with <code>iBotCopy()</code>, omitting the original
234	particle itself. Any non-final particles are removed from the list.
235	Should this make the list empty the search criterion is widened so that
236	all final daughters are allowed, not only carbon-copy ones. A second
237	argument <code>false</code> inhibits the second step, and increases
238	the risk that an empty list is returned. A typical example of this
239	is for ISR cascades, e.g. <i>e -> e gamma</i> where the photon
240	may not have any obvious sister in the final state if the bottom copy
241	of the photon is an electron that annihilates and thus is not part of
242	the final state.
243
244
245	<a name="method11"></a>
246	<p/><strong>bool Event::isAncestor(int i, int iAncestor)  </strong> <br/>
247	traces the particle <i>i</i> upwards through mother, grandmother,
248	and so on, until either <i>iAncestor</i> is found or the top of
249	the record is reached. Normally one unique mother is required,
250	as is the case e.g. in decay chains or in parton showers, so that
251	e.g. the tracing through a hard scattering would not work. For
252	hadronization, first-rank hadrons are identified with the respective
253	string endpoint quark, which may be useful e.g. for <i>b</i> physics,
254	while higher-rank hadrons give <code>false</code>. Currently also
255	ministrings that collapsed to one single hadron and junction topologies
256	give <code>false</code>.
257
258
259	<p/>
260	One data member in an <code>Event</code> object is used to keep track
261	of the largest <code>col()</code> or <code>acol()</code> colour tag set
262	so far, so that new ones do not clash.
263
264	<br/><br/><table><tr><td><strong>Event:startColTag </td><td></td><td> <input type="text" name="1" value="100" size="20"/>   (<code>default = <strong>100</strong></code>; <code>minimum = 0</code>; <code>maximum = 1000</code>)</td></tr></table>
265	This sets the initial colour tag value used, so that the first one
266	assigned is <code>startColTag + 1</code>, etc. The Les Houches accord
267	[<a href="Bibliography.php" target="page">Boo01</a>] suggests this number to be 500, but 100 works equally
268	well.
269
270
271	<a name="method12"></a>
272	<p/><strong>void Event::initColTag(int colTag = 0)  </strong> <br/>
273	forces the current colour tag value to be the larger of the input
274	<code>colTag</code> and the above <code>Event:startColTag</code>
275	values.
276
277
278	<a name="method13"></a>
279	<p/><strong>int Event::lastColTag()  </strong> <br/>
280	returns the current maximum colour tag.
281
282
283	<a name="method14"></a>
284	<p/><strong>int Event::nextColTag()  </strong> <br/>
285	increases the current maximum colour tag by one and returns this
286	new value. This method is used whenever a new colour tag is needed.
287
288
289	<p/>
290	Many event properties are accessible via the <code>Info</code> class,
291	<?php $filepath = $_GET["filepath"];
292	echo "<a href='EventInformation.php?filepath=".$filepath."' target='page'>";?>see here</a>. Since they are used
293	directly in the event generation, a few are stored directly in the
294	<code>Event</code> class, however.
295
296	<a name="method15"></a>
297	<p/><strong>void Event::scale( double scaleIn)  </strong> <br/>
298
299	<strong>double Event::scale()  </strong> <br/>
300	set or get the scale (in GeV) of the hardest process in the event.
301	Matches the function of the <code>scale</code> variable in the
302	<?php $filepath = $_GET["filepath"];
303	echo "<a href='LesHouchesAccord.php?filepath=".$filepath."' target='page'>";?>Les Houches Accord</a>.
304
305
306	<a name="method16"></a>
307	<p/><strong>void Event::scaleSecond( double scaleSecondIn)  </strong> <br/>
308
309	<strong>double Event::scaleSecond()  </strong> <br/>
310	set or get the scale (in GeV) of a second hard process in the event,
311	in those cases where such a one
312	<?php $filepath = $_GET["filepath"];
313	echo "<a href='SecondHardProcess.php?filepath=".$filepath."' target='page'>";?>has been requested</a>.
314
315
316	<h3>Constructors and modifications of the event record</h3>
317
318	Although you would not normally need to create your own
319	<code>Event</code> instance, there may be times where that
320	could be convenient. The typical exampel would be if you want to
321	create a new event record that is the sum of a few different ones,
322	e.g. if you want to simulate pileup events. There may also be cases
323	where you want to add one or a few particles to an existing event
324	record.
325
326	<a name="method17"></a>
327	<p/><strong>Event::Event(int capacity = 100)  </strong> <br/>
328	creates an empty event record, but with a reserved size
329	<i>capacity</i> for the <code>Particle</code> vector.
330
331
332	<a name="method18"></a>
333	<p/><strong>Event& Event::operator=(const Event& oldEvent)  </strong> <br/>
334	copies the input event record.
335
336
337	<a name="method19"></a>
338	<p/><strong>Event& Event::operator+=(const Event& addEvent)  </strong> <br/>
339	appends an event to an existing one. For the appended particles
340	mother, daughter and colour tags are shifted to make a consistent
341	record. The zeroth particle of the appended event is not copied,
342	but the zeroth particle of the combined event is updated to the
343	full energy-momentum content.
344
345
346	<a name="method20"></a>
347	<p/><strong>void Event::init(string headerIn = "", ParticleData* particleDataPtrIn = 0, int startColTagIn = 100)  </strong> <br/>
348	initializes colour, the pointer to the particle database, and the
349	header specification used for the event listing. We remind that a
350	<code>Pythia</code> object contains two event records
351	<code>process</code> and <code>event</code>. Thus one may e.g.
352	call either <code>pythia.process.list()</code> or
353	<code>pythia.event.list()</code>. To distinguish those two rapidly
354	at visual inspection, the <code>"Pythia Event Listing"</code> header
355	is printed out differently, in one case adding
356	<code>"(hard process)"</code> and in the other
357	<code>"(complete event)"</code>. When <code>+=</code> is used to
358	append an event, the modified event is printed with
359	<code>"(combination of several events)"</code> as a reminder.
360
361
362	<a name="method21"></a>
363	<p/><strong>void Event::clear()  </strong> <br/>
364	empties event record. Specifically the <code>Particle</code> vector
365	size is reset to zero.
366
367
368	<a name="method22"></a>
369	<p/><strong>void Event::reset()  </strong> <br/>
370	empties the event record, as <code>clear()</code> above, but then
371	fills the zero entry of the <code>Particle</code> vector with the
372	pseudoparticle used to represent the event as a whole. At this point
373	the pseudoparticle is not assigned any momentum or mass.
374
375
376	<a name="method23"></a>
377	<p/><strong>void Event::popBack(int n = 1)  </strong> <br/>
378	removes the last <i>n</i> particle entries; must be a positive
379	number.
380
381
382	<a name="method24"></a>
383	<p/><strong>int Event::append(Particle entryIn)  </strong> <br/>
384	appends a particle to the bottom of the event record and
385	returns the index of this position.
386
387
388	<a name="method25"></a>
389	<p/><strong>int Event::append(int id, int status, int mother1, int mother2, int daughter1, int daughter2, int col, int acol, double px, double py, double pz, double e, double m = 0., double scale = 0., double pol = 9.)  </strong> <br/>
390	appends a particle to the bottom of the event record and
391	returns the index of this position;
392	<?php $filepath = $_GET["filepath"];
393	echo "<a href='ParticleProperties.php?filepath=".$filepath."' target='page'>";?>see here</a> for the meaning
394	of the various particle properties.
395
396
397	<a name="method26"></a>
398	<p/><strong>int Event::append(int id, int status, int mother1, int mother2, int daughter1, int daughter2, int col, int acol, Vec4 p, double m = 0., double scale = 0., double pol = 9.)  </strong> <br/>
399	appends a particle to the bottom of the event record and
400	returns the index of this position, as above but with four-momentum
401	as a <code>Vec4</code>.
402
403
404	<a name="method27"></a>
405	<p/><strong>int Event::append(int id, int status, int col, int acol, double px, double py, double pz, double e, double m = 0., double scale = 0., double pol = 9.)  </strong> <br/>
406
407	<strong>int Event::append(int id, int status, int col, int acol, Vec4 p, double m = 0., double scale = 0., double pol = 9.)  </strong> <br/>
408	appends a particle to the bottom of the event record and
409	returns the index of this position, as above but with vanishing
410	(i.e. zero) mother and daughter indices.
411
412
413	<a name="method28"></a>
414	<p/><strong>int Event::setPDTPtr(int iSet = -1)  </strong> <br/>
415	send in a pointer to the <code>ParticleData</code> database for
416	particle <code>iSet</code>, by default the most recently appended
417	particle. Also generates a pointer to the
418	<code>ParticleDataEntry</code> object of the identity code
419	of the particle.
420
421
422	<a name="method29"></a>
423	<p/><strong>int Event::copy(int iCopy, int newStatus = 0)  </strong> <br/>
424	copies the existing particle in entry <code>iCopy</code> to the
425	bottom of the event record and returns the index of this position.
426	By default, i.e. with <code>newStatus = 0</code>, everything is
427	copied precisely as it is, which means that history information
428	has to be modified further by hand to make sense. With a positive
429	<code>newStatus</code>, the new copy is set up to be the daughter of
430	the old, with status code <code>newStatus</code>, while the status
431	code of <code>iCopy</code> is negated. With a negative
432	<code>newStatus</code>, the new copy is instead set up to be the
433	mother of <code>iCopy</code>. An attempt to copy an out-of-range
434	entry will return -1.
435
436
437	<a name="method30"></a>
438	<p/><strong>Particle& Event::back()  </strong> <br/>
439	returns a reference to the last particle in the event record.
440
441
442	<a name="method31"></a>
443	<p/><strong>void Event::restorePtrs()  </strong> <br/>
444	each particle in the event record has a pointer to the whole database
445	and another to the particle species itself, used to find some particle
446	properties. The latter pointer is automatically set/changed whenever
447	the particle identity is set/changed by one of the normal methods.
448	(It is the "changed" part that prompts the inclusion of a pointer
449	to the whole database.) Of course the pointer values are specific to
450	the memory locations of the current run, and so it has no sense to
451	save them if events are written to file. Should you use some
452	persistency scheme that bypasses the normal methods when the event is
453	read back in, you can use <code>restorePtrs()</code> afterwards to set
454	these pointers appropriately.
455
456
457	<p/>
458	A few methods exist to rotate and boost events. These derive from the
459	<?php $filepath = $_GET["filepath"];
460	echo "<a href='FourVectors.php?filepath=".$filepath."' target='page'>";?>Vec4</a> methods, and affect both the
461	momentum and the vertex (position) components of all particles.
462
463	<a name="method32"></a>
464	<p/><strong>void Event::rot(double theta, double phi)  </strong> <br/>
465	rotate all particles in the event by this polar and azimuthal angle
466	(expressed in radians).
467
468
469	<a name="method33"></a>
470	<p/><strong>void Event::bst(double betaX, double betaY, double betaZ)  </strong> <br/>
471
472	<strong>void Event::bst(double betaX, double betaY, double betaZ, double gamma)  </strong> <br/>
473
474	<strong>void Event::bst(const Vec4& vec)  </strong> <br/>
475	boost all particles in the event by this three-vector.
476	Optionally you may provide the <i>gamma</i> value as a fourth argument,
477	which may help avoid roundoff errors for big boosts. You may alternatively
478	supply a <code>Vec4</code> four-vector, in which case the boost vector
479	becomes <i>beta = p/E</i>.
480
481
482	<a name="method34"></a>
483	<p/><strong>void Event::rotbst(const RotBstMatrix& M)  </strong> <br/>
484	rotate and boost by the combined action encoded in the
485	<code><?php $filepath = $_GET["filepath"];
486	echo "<a href='FourVectors.php?filepath=".$filepath."' target='page'>";?>RotBstMatrix</a> M</code>.
487
488
489	<h3>The Junction Class</h3>
490
491	The event record also contains a vector of junctions, which often
492	is empty or else contains only a very few per event. Methods are
493	available to add further junctions or query the current junction list.
494	This is only for the expert user, however, and is not discussed
495	further here, but only the main points.
496
497	<p/>
498	A junction stores the properites associated with a baryon number that
499	is fully resolved, i.e. where three different colour indices are
500	involved. There are two main applications,
501	<ol>
502	<li>baryon beams, where at least two valence quarks are kicked out,
503	and so the motion of the baryon number is notrivial;</li>
504	<li>baryon-number violating processes, e.g. in SUSY with broken
505	<i>R</i>-parity.</li>
506	</ol>
507	Information on junctions is set, partly in the process generation,
508	partly in the beam remnants machinery, and used by the fragmentation
509	routines, but the normal user does not have to know the details.
510
511	<p/>
512	For each junction, information is stored on the kind of junction, and
513	on the three (anti)colour indices that are involved in the junction.
514	The possibilities foreseen are:
515	<ul>
516	<li><code>kind = 1</code> : incoming colourless particle to three
517	outgoing colours (e.g. baryon beam remnant or
518	<i>neutralino -> q q q</i>);</li>
519	<li><code>kind = 2</code> : incoming colourless particle to three
520	outgoing anticolours;</li>
521	<li><code>kind = 3</code> : one incoming anticolour (stored first)
522	and two outgoing colours (e.g. antisquark decaying to two quarks, or
523	gluino decay to three quarks);</li>
524	<li><code>kind = 4</code> : one incoming colour (stored first) and two
525	outgoing anticolours (e.g. squark decaying to two antiquarks, or
526	gluino decaying to three antiquarks);</li>
527	<li><code>kind = 5</code> : two incoming anticolours (stored first)
528	and one outgoing colour (e.g. resonant squark production through RPV);</li>
529	<li><code>kind = 6</code> : two incoming colours (stored first)
530	and one outgoing anticolour (e.g. resonant antisquark production
531	through RPV);
532	</li>
533	</ul>
534	The odd (even) <code>kind</code> codes corresponds to a +1 (-1) change in
535	baryon number across the junction.
536
537	<p/>
538	The kind and colour information in the list of junctions can be set
539	or read with methods of the <code>Event</code> class, but are not of
540	common interest and so not described here.
541
542	<p/>
543	A listing of current junctions can be obtained with the
544	<code>listJunctions()</code> method.
545
546	<h3>Subsystems</h3>
547
548	Separate from the event record as such, but closely tied to it is the
549	<code><?php $filepath = $_GET["filepath"];
550	echo "<a href='AdvancedUsage.php?filepath=".$filepath."' target='page'>";?>PartonSystems</a></code> class,
551	which mainly stores the parton indices of incoming and outgoing partons,
552	classified by collision subsystem. Such information is needed to
553	interleave multiparton interactions, initial-state showers and final-state
554	showers, and append beam remnants. It could also be used in other places.
555	It is intended to be accessed only by experts, such as implementors of
556	<?php $filepath = $_GET["filepath"];
557	echo "<a href='ImplementNewShowers.php?filepath=".$filepath."' target='page'>";?>new showering models</a>.
558
559	<input type="hidden" name="saved" value="1"/>
560
561	<?php
562	echo "<input type='hidden' name='filepath' value='".$_GET["filepath"]."'/>"?>
563
564	<table width="100%"><tr><td align="right"><input type="submit" value="Save Settings" /></td></tr></table>
565	</form>
566
567	<?php
568
569	if($_POST["saved"] == 1)
570	{
571	$filepath = $_POST["filepath"];
572	$handle = fopen($filepath, 'a');
573
574	if($_POST["1"] != "100")
575	{
576	$data = "Event:startColTag = ".$_POST["1"]."\n";
577	fwrite($handle,$data);
578	}
579	fclose($handle);
580	}
581
582	?>
583	</body>
584	</html>
585
586	<!-- Copyright (C) 2012 Torbjorn Sjostrand -->

Note: See TracBrowser for help on using the repository browser.

Context Navigation

source: HiSusy/trunk/Pythia8/pythia8170/phpdoc/EventRecord.php @ 1

Download in other formats: