Context Navigation

← Previous Revision
Latest Revision
Next Revision →
Blame
Revision Log

SemiInternalProcesses.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: 33.2 KB

Line
1	<html>
2	<head>
3	<title>Semi-Internal Processes</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='SemiInternalProcesses.php'>
29
30	<h2>Semi-Internal Processes</h2>
31
32	Normally users are expected to implement new processes via the
33	<?php $filepath = $_GET["filepath"];
34	echo "<a href='LesHouchesAccord.php?filepath=".$filepath."' target='page'>";?>Les Houches Accord</a>. Then
35	you do all flavour, colour and phase-space selection externally,
36	before your process-level events are input for further processing
37	by PYTHIA. However, it is also possible to implement a
38	new process in exactly the same way as the internal PYTHIA
39	ones, thus making use of the internal phase space selection machinery
40	to sample an externally provided cross-section expression.
41	The MadGraph 5 program [<a href="Bibliography.php" target="page">Alw11</a>] allows you to do exactly that,
42	i.e. it can be used to generate C++ code that can be linked into
43	the existing PYTHIA framework, see
44	<?php $filepath = $_GET["filepath"];
45	echo "<a href='MadGraph5Processes.php?filepath=".$filepath."' target='page'>";?>here</a>.
46
47	<p/>
48	Should you decide to go ahead on your own,
49	this page gives a brief summary how to do that. If you additionally
50	want to introduce a new resonance species, with its own internal
51	width calculations, you will find further instructions
52	<?php $filepath = $_GET["filepath"];
53	echo "<a href='SemiInternalResonances.php?filepath=".$filepath."' target='page'>";?>here</a>. It is strongly
54	recommended to shop around for a similar process that has already
55	been implemented, and to use that existing code as a template.
56	Look for processes with the same combinations of incoming flavours
57	and colour flows, rather than the shape of the cross section itself.
58	With a reasonable such match the task should be of medium difficulty,
59	without it more demanding.
60
61	<p/>
62	PYTHIA is rather good at handling the phase space of
63	<i>2 -> 1</i> and <i>2 -> 2</i> processes, is more primitive for
64	<i>2 -> 3</i> ones and does not at all address higher multiplicities.
65	This limits the set of processes that you can implement in this
66	framework. The produced particles may be resonances, however, so it is
67	possible to end up with bigger "final" multiplicities through sequential
68	decays, and to include further matrix-element weighting in those decays.
69
70	<p/>
71	There are three steps involved in implementing a process:
72	<ol>
73	<li>making use of the PYTHIA-provided kinematics information to
74	calculate the relevant cross section,</li>
75	<li>writing a new class, where the matrix elements are implemented,
76	including information on incoming and outgoing flavours and colours,
77	and</li>
78	<li>making the process available.</li>
79	</ol>
80	We consider these aspects in turn. An example where it all comes
81	together is found in <code>main22.cc</code>.
82
83	<h3>The Cross Section Calculation</h3>
84
85	The key method for the cross section calculation is
86	<code>SigmaProcess::sigmaHat()</code>, described below. At the point when
87	it is called, the kinematics has already been set up, and from these
88	phase space variables the differential cross section is to be calculated.
89
90	<p/>
91	For a <i>2 -> 1</i> process, the returned value should be
92	<i>sigmaHat(sHat)</i>, where <code>mH</code> (= <i>mHat</i>),
93	<code>sH</code> (= <i>sHat</i>) and <code>sH2</code> (= <i>sHat^2</i>)
94	are available to be used. Incoming partons are massless. Overload the
95	<code>convertM2()</code> method below if you instead plan to return
96	<i>\|M\|^2</i>.
97
98	<p/>
99	For a <i>2 -> 2</i> process, instead <i>d(sigmaHat)/d(tHat)</i>
100	should be returned, based on provided
101	<code>mH, sH, sH2, tH, tH2, uH, uH2, m3, s3, m4, s4</code> and
102	<code>pT2</code> values (<code>s3 = m3*m3</code> etc.). Incoming
103	partons are massless. Overload the <code>convertM2()</code> method
104	below if you instead plan to return <i>\|M\|^2</i>.
105
106	<p/>
107	For a <i>2 -> 3</i> process, instead <i>\|M\|^2</i> should be
108	returned, with normalization such that <i>\|M\|^2 / (2 sHat)</i> integrated
109	over the three-body phase space gives the cross section. Here no standard
110	set of Mandelstam-style variables exists. Instead the obvious ones,
111	<code>mH, sH, m3, s3, m4, s4, m5, s5</code>, are complemented by the
112	four-vectors <code>p3cm, p4cm, p5cm</code>, from which further invariants
113	may be calculated. The four-vectors are defined in the CM frame of the
114	subcollision, with massless incoming partons along the <i>+-z</i> axis.
115
116	<p/>
117	In either case, <i>alpha_s</i> and <i>alpha_em</i> have already
118	been calculated, and are stored in <code>alpS</code> and <code>alpEM</code>.
119	Also other standard variables may be used, like
120	<code>CoupEW::sin2thetaW()</code>, and related flavour-dependent
121	vector and axial couplings in <code>CoupEW</code> and CKM combinations
122	in <code>VCKM</code>.
123
124	<p/>
125	In case some of the final-state particles are resonances, their
126	squared masses have already been selected according to a Breit-Wigner
127	with a linearly running width <i>Gamma(m) = Gamma(m_0) * m / m_0</i>.
128	More precisely, the mass spectrum is weighted according to
129	<i>w_BW(m^2) d(m^2)</i>, where
130	<br/><i>
131	w_BW(m^2) = (1/pi) * (m * Gamma(m)) / ( (m^2 - m_0^2)^2 + (m * Gamma(m))^2 ) .
132	</i><br/>
133	If you would like to have another expression, the above weights are stored
134	in <code>runBW3</code>, <code>runBW4</code> and <code>runBW5</code>,
135	respectively. If you divide out one of these factors, you just remain with
136	a phase space selection <i>d(m^2)</i> for this particle,
137	and can multiply on your desired shape factor instead. Unfortunately, the
138	Monte Carlo efficiency will drop if your new mass distribution differs
139	dramatically from the input one. Therefore it does make sense to adjust the
140	database value of the width to be slightly (but not too much) broader
141	than the distribution you have in mind. Also note that, already by default,
142	the wings of the Breit-Wigner are oversampled (with a compensating lower
143	internal weight) by partly sampling like <i>(a + b/m^2 + c/m^4) d(m^2)</i>,
144	where the last term is only used for <i>gamma^*/Z^0</i>.
145
146	<p/>
147	As alternative to the kinematics variables defined above, also the two
148	arrays <code>mME[5]</code> and <code>pME[5]</code>, for masses and
149	four-momenta, respectively, can be used for cross-section calculations.
150	Here indices 0 and 1 are the two incoming beams, and 2 and onwards the
151	outgoing particles. Note that this differs by one step from the normal
152	internal labelling, where slot 0 is left empty. The four-momenta are
153	defined in the rest frame of the subcollision, with the incoming partons
154	along the <i>+-z</i> direction. The kinematics need not agree with the
155	"correct" one stored in the event record, for three reasons.
156	<br/>1) Gauge invariance forces matrix-element calculations to use
157	the same masses for incoming as outgoing legs of a particle species,
158	say <i>b</i> quarks. Therefore the kinematics of the two incoming
159	partons is recalculated, relative to the normal event record, to put
160	the partons on the mass shell. (Note that initial masses is a technical
161	issue, not the correct physics picture: the incoming partons are likely
162	to be spacelike virtual rather than on the mass shell.)
163	<br/>2) In principle each fermion flavour has to be treated separately,
164	owing to a different mass. However, in many cases fermions can be
165	assumed massless, which speeds up the calculations, and further gains
166	occur if then different flavours can use the same cross-section
167	expression. In MadGraph the default is that fermions up to and including
168	the <i>c</i> quark and the <i>mu</i> lepton are considered massless,
169	while the <i>b</i> quark and the <i>tau</i> lepton are considered
170	massive. This can be modified however, and below we provide four flags
171	that can be used to consider the "borderline" fermions either as
172	massless or as massive when matrix elements are evaluated, to match the
173	assumptions made for the matrix elements themselves.
174	<br/>3) For <i>2 -> 2</i> and <i>2 -> 3</i> processes of massive
175	identical particles (or antiparticles) in the final state, such as
176	<i>t tbar</i> or <i>W^+ W^-</i>, the kinematics is here adjusted
177	so that the two or three particles have the same mass, formed as a
178	suitable average of the actual Breit-Wigner-distributed masses. This
179	allows the evaluation of matrix-element expressions that only have
180	meaning if the two/three have the same mass.
181	<br/>Thus the mass array <code>mME[5]</code> and the four-momentum array
182	<code>pME[5]</code> present values both for initial- and final-state
183	particles based on these mass principles suited for matrix-element input.
184	Note that these variables therefore differ from the kinematics stored in
185	the event record proper, where incoming fermions are always massless and
186	outgoing resonances have independent Breit-Wigner mass distributions.
187	<br/>The conversion from the normal to the special kinematics is done
188	by calling the <code>setupForME()</code> method. This you have to do
189	yourself in the <code>SigmaHat()</code> member of your derived class.
190	Alternatively it could be done in <code>SigmaKin()</code>, i.e. before
191	the loop over incoming flavours, but then these would be considered
192	massless. The identity of final-state particles is obtained from the
193	<code>id3Mass()</code>, <code>id4Mass()</code> and <code>id5Mass()</code>
194	methods. Should the conversion to <code>mME[5]</code> and
195	<code>pME[5]</code> not work, <code>setupForME()</code> will return
196	<code>false</code>, and then the cross section should be put zero.
197
198	<br/><br/><strong>SigmaProcess:cMassiveME</strong> <input type="radio" name="1" value="on"><strong>On</strong>
199	<input type="radio" name="1" value="off" checked="checked"><strong>Off</strong>
200	(<code>default = <strong>off</strong></code>)<br/>
201	Let the <i>c</i> quark be massive or not in the kinematics set up for
202	external matrix-element evaluation.
203
204
205	<br/><br/><strong>SigmaProcess:bMassiveME</strong> <input type="radio" name="2" value="on" checked="checked"><strong>On</strong>
206	<input type="radio" name="2" value="off"><strong>Off</strong>
207	(<code>default = <strong>on</strong></code>)<br/>
208	Let the <i>b</i> quark be massive or not in the kinematics set up for
209	external matrix-element evaluation.
210
211
212	<br/><br/><strong>SigmaProcess:muMassiveME</strong> <input type="radio" name="3" value="on"><strong>On</strong>
213	<input type="radio" name="3" value="off" checked="checked"><strong>Off</strong>
214	(<code>default = <strong>off</strong></code>)<br/>
215	Let the <i>mu</i> lepton be massive or not in the kinematics set up for
216	external matrix-element evaluation.
217
218
219	<br/><br/><strong>SigmaProcess:tauMassiveME</strong> <input type="radio" name="4" value="on" checked="checked"><strong>On</strong>
220	<input type="radio" name="4" value="off"><strong>Off</strong>
221	(<code>default = <strong>on</strong></code>)<br/>
222	Let the <i>tau</i> lepton be massive or not in the kinematics set up for
223	external matrix-element evaluation.
224
225
226
227	<h3>The Cross Section Class</h3>
228
229	The matrix-element information has to be encoded in a new class.
230	The relevant code could either be put before the main program in the
231	same file, or be stored separately, e.g. in a matched pair
232	of <code>.h</code> and <code>.cc</code> files. The latter may be more
233	convenient, in particular if the cross sections are lengthy, or if you
234	intend to build up your own little process library, but of course
235	requires that these additional files are correctly compiled and linked.
236
237	<p/>
238	The class has to be derived either from
239	<code>Sigma1Process</code>, for <i>2 -> 1</i> processes, from
240	<code>Sigma2Process</code>, for <i>2 -> 2</i> ones, or from
241	<code>Sigma3Process</code>, for <i>2 -> 3</i> ones. (The
242	<code>Sigma0Process</code> class is used for elastic, diffractive
243	and minimum-bias events, and is not recommended for use beyond that.)
244	These are in their turn derived from the <code>SigmaProcess</code>
245	base class.
246
247	<p/>
248	The class can implement a number of methods. Some of these are
249	compulsory, others strongly recommended, and the rest are to be
250	used only when the need arises to override the default behaviour.
251	The methods are:
252
253	<p/>
254	A <b>constructor</b> for the derived class obviously must be available.
255	Here you are quite free to allow a list of arguments, to set
256	the parameters of your model, or even to create a set of closely
257	related but distinct processes. For instance, <i>g g -> Q Qbar</i>,
258	<i>Q = c</i> or <i>b</i>, is only coded once, and then the
259	constructor takes the quark code (4 or 5) as argument,
260	to allow the proper amount of differentiation.
261
262	<p/>
263	A <b>destructor</b> is only needed if you plan to delete the process
264	before the natural end of the run, and require some special behaviour
265	at that point. If you call such a destructor you will leave a pointer
266	dangling inside the <code>Pythia</code> object you gave it in to,
267	if that still exists.
268
269	<a name="method1"></a>
270	<p/><strong>void SigmaProcess::initProc()  </strong> <br/>
271	is called once during initalization, and can then be used to set up
272	parameters, such as masses and couplings, and perform calculations
273	that need not be repeated for each new event, thereby saving time.
274	This method needs not be implemented, since in principle all
275	calculations can be done in <code>sigmaHat</code> below.
276
277
278	<a name="method2"></a>
279	<p/><strong>void SigmaProcess::sigmaKin()  </strong> <br/>
280	is called once a kinematical configuration has been determined, but
281	before the two incoming flavours are known. This routine can therefore
282	be used to perform calculations that otherwise might have to be repeated
283	over and over again in <code>sigmaHat</code> below. For instance
284	a flavour-independent cross section calculation for a <i>q g</i>
285	initial state would be repeated 20 times in <code>sigmaHat</code>,
286	five times for the five quark flavours allowed in the incoming beams,
287	times twice to include antiquarks, times twice since the (anti)quark
288	could be in either of the two beams. You could therefore calculate the
289	result once only and store it as a private data member of the class.
290	It is optional whether you want to use this method, however, or put
291	everything in <code>sigmaHat</code>.
292
293
294	<a name="method3"></a>
295	<p/><strong>double SigmaProcess::sigmaHat()  </strong> <br/>
296	is the key method for cross section calculations and returns a cross section
297	value, as described in the previous section. It is called when also a
298	preliminary set of incoming flavours has been picked, in addition to the
299	kinematical ones already available for <code>sigmaKin</code>.
300	Typically <code>sigmaHat</code> is called inside a loop over all allowed
301	incoming flavour combinations, stored in <code>id1</code> and
302	<code>id2</code>, with fixed kinematics, as already illustrated above.
303	The sum over the different flavour combinations provides the total
304	cross section, while their relative size is used to make a selection of
305	a specific incomimg state.
306
307
308	<a name="method4"></a>
309	<p/><strong>bool SigmaProcess::setupForME()  </strong> <br/>
310	to be called by the user from inside <code>sigmaHat()</code>
311	(or possibly <code>sigmaKin()</code>) to setup alternative kinematics
312	in the <code>mME[5]</code> and <code>pME[5]</code> arrays, better
313	suited for matrix-element calculations. See the end of the previous
314	section for a more detailed description. Should the method return
315	<code>false</code> then the conversion did not work, and
316	<code>sigmaHat()</code> (or <code>sigmaKin()</code>) should be set to
317	vanish.
318
319
320	<a name="method5"></a>
321	<p/><strong>void SigmaProcess::setIdColAcol()  </strong> <br/>
322	is called only once an initial state and a kinematical configuration has
323	been picked. This routine must set the complete flavour information and
324	the colour flow of the process. This may involve further random choices,
325	between different possible final-state flavours or between possible
326	competing colour flows. Private data members of the class may be used to
327	retain some information from the previous steps above.
328	<br/>When this routine is called the two incoming flavours have already
329	been selected and are available in <code>id1</code> and <code>id2</code>,
330	whereas the one, two or three outgoing ones either are fixed for a given
331	process or can be determined from the instate (e.g. whether a <i>W^+</i>
332	or <i>W^-</i> was produced). There is also a standard method in
333	<code>VCKM</code> to pick a final flavour from an initial one with CKM
334	mixing. Once you have figured out the value of
335	<code>id3</code> and, the case being, <code>id4</code> and
336	<code>id5</code>, you store these values permanently by a call
337	<code>setId( id1, id2, id3, id4, id5)</code>, where the last two may be
338	omitted if irrelevant.
339	<br/>Correspondingly, the colours are stored with
340	<code>setColAcol( col1, acol1, col2, acol2, col3, acol3, col4, acol4,
341	col5, acol5)</code>, where the final ones may be omitted if irrelevant.
342	Les Houches style colour tags are used, but starting with number 1
343	(and later shifted by the currently requested offset). The
344	input is grouped particle by particle, with the colour index before the
345	anticolour one. You may need to select colour flow dynamically, depending
346	on the kinematics, when several distinct possibilities exist. Trivial
347	operations, like swapping colours and anticolours, can be done with
348	existing methods.
349	<br/>When the <code>id3Mass()</code> and <code>id4Mass()</code>
350	methods have been used, the order of the outgoing particles may be
351	inconsistent with the way the <i>tHat</i> and <i>uHat</i>
352	variables have been defined. A typical example would be a process like
353	<i>q g -> q' W</i> with <i>tHat</i> defined between incoming and
354	outgoing quark, but where <code>id3Mass() = 24</code> and so the
355	process is to be stored as <i>q g -> W q'</i>. One should then put
356	the variable <code>swapTU = true</code> in <code>setIdColAcol()</code>
357	for each event where the <i>tHat</i> and <i>uHat</i> variables
358	should be swapped before the event kinematics is reconstructed. This
359	variable is automatically restored to <code>false</code> for each new
360	event.
361
362
363	<a name="method6"></a>
364	<p/><strong>double SigmaProcess::weightDecayFlav( Event& process)  </strong> <br/>
365	is called to allow a reweighting of the simultaneous flavour choices of
366	resonance decay products. Is currently only used for the
367	<i>q qbar -> gamma/Z^0 gamma/Z^0</i> process, and will likely not
368	be of interest for you.
369
370
371	<a name="method7"></a>
372	<p/><strong>double SigmaProcess::weightDecay( Event& process, int iResBeg, int iResEnd)  </strong> <br/>
373	is called when the basic process has one or several resonances, after each
374	set of related resonances in <code>process[i]</code>,
375	<code>iResBeg</code> <= <code>i </code> <= <code>iResEnd</code>,
376	has been allowed to decay. The calculated weight, to be normalized
377	to the range between 0 and 1, is used to decide whether to accept the
378	decay(s) or try for a new decay configuration. The base-class version of
379	this method returns unity, i.e. gives isotropic decays by default.
380	This method may be called repeatedly for a single event. For instance, in
381	<i>q qbar -> H^0 Z^0</i> with <i>H^0 -> W^+ W^-</i>, a first call
382	would be made after the <i>H^0</i> and <i>Z^0</i> decays, and then
383	depend only on the <i>Z^0</i> decay angles since the <i>H^0</i>
384	decays isotropically. The second call would be after the <i>W^+ W^-</i>
385	decays and then involve correlations between the four daughter fermions.
386
387
388	<a name="method8"></a>
389	<p/><strong>string SigmaProcess::name()  </strong> <br/>
390	returns the name of the process, as you want it to be shown in listings.
391
392
393	<a name="method9"></a>
394	<p/><strong>int SigmaProcess::code()  </strong> <br/>
395	returns an integer identifier of the process. This has no internal function,
396	but is only intended as a service for the user to rapidly (and hopefully
397	uniquely) identify which process occured in a given event. Numbers below
398	10000 are reserved for internal PYTHIA use.
399
400
401	<a name="method10"></a>
402	<p/><strong>string SigmaProcess::inFlux()  </strong> <br/>
403	this string specifies the combinations of incoming partons that are
404	allowed for the process under consideration, and thereby which incoming
405	flavours <code>id1</code> and <code>id2</code> the <code>sigmaHat()</code>
406	calls will be looped over. It is always possible to pick a wider flavour
407	selection than strictly required and then put to zero cross sections in
408	the superfluous channels, but of course this may cost some extra execution
409	time. Currently allowed options are:
410	<br/>* <code>gg</code>: two gluons.
411	<br/>* <code>qg</code>: one (anti)quark and one gluon.
412	<br/>* <code>qq</code>: any combination of two quarks, two antiquarks or
413	a quark and an antiquark.
414	<br/>* <code>qqbarSame</code>: a quark and its antiquark;
415	this is a subset of the above <code>qq</code> option.
416	<br/>* <code>ff</code>: any combination of two fermions, two antifermions
417	or a fermion and an antifermion; is the same as <code>qq</code> for
418	hadron beams but also allows processes to work with lepton beams.
419	<br/>* <code>ffbarSame</code>: a fermion and its antifermion; is the
420	same as <code>qqbarSame</code> for hadron beams but also allows processes
421	to work with lepton beams.
422	<br/>* <code>ffbarChg</code>: a fermion and an antifermion that combine
423	to give charge +-1.
424	<br/>* <code>fgm</code>: a fermion and a photon (gamma).
425	<br/>* <code>ggm</code>: a gluon and a photon.
426	<br/>* <code>gmgm</code>: two photons.
427
428
429	<a name="method11"></a>
430	<p/><strong>bool SigmaProcess::convert2mb()  </strong> <br/>
431	it is assumed that cross sections normally come in dimensions such that
432	they, when integrated over the relevant phase space, obtain the dimension
433	GeV^-2, and therefore need to be converted to mb. If the cross section
434	is already encoded as mb then <code>convert2mb()</code> should be
435	overloaded to instead return <code>false</code>.
436
437
438	<a name="method12"></a>
439	<p/><strong>bool SigmaProcess::convertM2()  </strong> <br/>
440	it is assumed that <i>2 -> 1</i> cross sections are encoded as
441	<i>sigmaHat(sHat)</i>, and <i>2 -> 2</i> ones as
442	<i>d(sigmaHat)/d(tHat)</i> in the <code>SigmaProcess::sigmaHat()</code>
443	methods. If <code>convertM2()</code> is overloaded to instead return
444	<code>true</code> then the return value is instead assumed to be the
445	squared matrix element <i>\|M\|^2</i>, and
446	<code>SigmaProcess::sigmaHatWrap(...)</code> converts to
447	<i>sigmaHat(sHat)</i> or <i>d(sigmaHat)/d(tHat)</i>, respectively.
448	This switch has no effect on <i>2 -> 3</i> processes, where
449	<i>\|M\|^2</i> is the only allowed input anyway.
450
451
452	<a name="method13"></a>
453	<p/><strong>int SigmaProcess::id3Mass()  </strong> <br/>
454
455	<strong>int SigmaProcess::id4Mass()  </strong> <br/>
456
457	<strong>int SigmaProcess::id5Mass()  </strong> <br/>
458	are the one, two or three final-state flavours, where masses are to be
459	selected before the matrix elements are evaluated. Only the absolute value
460	should be given. For massless particles, like gluons and photons, one need
461	not give anything, i.e. one defaults to 0. The same goes for normal light
462	quarks, where masses presumably are not implemented in the matrix elements.
463	Later on, these quarks can still (automatically) obtain constituent masses,
464	once a <i>u</i>, <i>d</i> or <i>s</i> flavour has been selected.
465
466
467	<a name="method14"></a>
468	<p/><strong>int SigmaProcess::resonanceA()  </strong> <br/>
469
470	<strong>int SigmaProcess::resonanceB()  </strong> <br/>
471	are the codes of up to two <i>s</i>-channel resonances contributing to
472	the matrix elements. These are used by the program to improve the phase-space
473	selection efficiency, by partly sampling according to the relevant
474	Breit-Wigners. Massless resonances (the gluon and photon) need not be
475	specified.
476
477
478	<a name="method15"></a>
479	<p/><strong>bool SigmaProcess::isSChannel()  </strong> <br/>
480	normally the choice of renormalization and factorization scales in
481	<i>2 -> 2</i> and <i>2 -> 3</i> processes is based on the assumption
482	that <i>t</i>- and <i>u</i>-channel exchanges dominates the
483	cross section. In cases such as <i>f fbar -> gamma* -> f' fbar'</i> a
484	<i>2 -> 2</i> process actually ought to be given scales as a
485	<i>2 -> 1</i> one, in the sense that it proceeds entirely through
486	an <i>s</i>-channel resonance. This can be achieved if you override the
487	default <code>false</code> to return <code>true</code>. See further the
488	page on <?php $filepath = $_GET["filepath"];
489	echo "<a href='CouplingsAndScales.php?filepath=".$filepath."' target='page'>";?>couplings and scales</a>.
490
491
492	<a name="method16"></a>
493	<p/><strong>int SigmaProcess::idSChannel()  </strong> <br/>
494	normally no intermediate state is shown in the event record for
495	<i>2 -> 2</i> and <i>2 -> 3</i> processes. However, in case
496	that <code>idSChannel</code> is overloaded to return a nonzero value,
497	an intermediate particle with that identity code is inserted into the
498	event record, to make it a <i>2 -> 1 -> 2</i> or <i>2 -> 1 -> 3</i>
499	process. Thus if both <code>isSChannel</code> and <code>idSChannel</code>
500	are overloaded, a process will behave and look like it proceeded through
501	a resonance. The one difference is that the implementation of the
502	matrix element is not based on the division into a production and a
503	decay of an intermediate resonance, but is directly describing the
504	transition from the initial to the final state.
505
506
507	<a name="method17"></a>
508	<p/><strong>int SigmaProcess::isQCD3body()  </strong> <br/>
509	there are two different 3-body phase-space selection machineries,
510	of which the non-QCD one is default. If you overload this method
511	instead the QCD-inspired machinery will be used. The differences
512	between these two is related to which
513	<?php $filepath = $_GET["filepath"];
514	echo "<a href='PhaseSpaceCuts.php?filepath=".$filepath."' target='page'>";?>phase space cuts</a>
515	can be set, and also that the QCD machinery assumes (almost) massless
516	outgoing partons.
517
518
519	<a name="method18"></a>
520	<p/><strong>int SigmaProcess::idTchan1()  </strong> <br/>
521
522	<strong>int SigmaProcess::idTchan2()  </strong> <br/>
523	the non-QCD <i>2 -> 3</i> phase space selection machinery is rather
524	primitive, as already mentioned. The efficiency can be improved in
525	processes that proceed though <i>t</i>-channel exchanges, such as
526	<i>q qbar' -> H^0 q qbar'</i> via <i>Z^0 Z^0</i> fusion, if the identity
527	of the <i>t</i>-channel-exchanged particles on the two side of the
528	event are provided. Only the absolute value is of interest.
529
530
531	<a name="method19"></a>
532	<p/><strong>double SigmaProcess::tChanFracPow1()  </strong> <br/>
533
534	<strong>double SigmaProcess::tChanFracPow2()  </strong> <br/>
535	in the above kind of <i>2 -> 3</i> phase-space selection, the
536	sampling of <i>pT^2</i> is done with one part flat, one part weighted
537	like <i>1 / (pT^2 + m_R^2)</i> and one part like
538	<i>1 / (pT^2 + m_R^2)^2</i>. The above values provide the relative
539	amount put in the latter two channels, respectively, with the first
540	obtaining the rest. Thus the sum of <code>tChanFracPow1()</code> and
541	<code>tChanFracPow2()</code> must be below unity. The final results
542	should be independent of these numbers, but the Monte Carlo efficiency
543	may be quite low for a bad choice. Here <i>m_R</i> is the mass of the
544	exchanged resonance specified by <code>idTchan1()</code> or
545	<code>idTchan2()</code>. Note that the order of the final-state
546	listing is important in the above <i>q qbar' -> H^0 q qbar'</i> example,
547	i.e. the <i>H^0</i> must be returned by <code>id3Mass()</code>,
548	since it is actually the <i>pT^2</i> of the latter two that are
549	selected independently, with the first <i>pT</i> then fixed
550	by transverse-momentum conservation.
551
552
553	<a name="method20"></a>
554	<p/><strong>bool SigmaProcess::useMirrorWeight()  </strong> <br/>
555	in <i>2 -> 3</i> processes the phase space selection used here
556	involves a twofold ambiguity basically corresponding to a flipping of
557	the positions of last two outgoing particles. These are assumed equally
558	likely by default, <code>false</code>, but for processes proceeding entirely
559	through <i>t</i>-channel exchange the Monte Carlo efficiency can be
560	improved by making a preselection based on the relative propagator
561	weights, <code>true</code>.
562
563
564	<a name="method21"></a>
565	<p/><strong>int SigmaProcess::gmZmode()  </strong> <br/>
566	allows a possibility to override the global mode
567	<code><?php $filepath = $_GET["filepath"];
568	echo "<a href='ElectroweakProcesses.php?filepath=".$filepath."' target='page'>";?>WeakZ0:gmZmode</a></code>
569	for a specific process. The global mode normally is used to switch off
570	parts of the <i>gamma^*/Z^0</i> propagator for test purposes. The
571	above local mode is useful for processes where a <i>Z^0</i> really is
572	that and nothing more, such as <i>q qbar -> H^0 Z^0</i>. The default
573	value -1 returned by <code>gmZmode()</code> ensures that the global
574	mode is used, while 0 gives full <i>gamma^*/Z^0</i> interference,
575	1 <i>gamma^*</i> only and 2 <i>Z^0</i> only.
576
577
578	<h3>Access to a process</h3>
579
580	Once you have implemented a class, it is straightforward to make use of
581	it in a run. Assume you have written a new class <code>MySigma</code>,
582	which inherits from <code>Sigma1Process</code>, <code>Sigma2Process</code>
583	or <code>Sigma3Process</code>, which in their turn inherit from
584	<code>SigmaProcess</code>. You then create an instance of this class
585	and hand it in to a <code>pythia</code> object with
586	<pre>
587	SigmaProcess* mySigma = new MySigma();
588	pythia.setSigmaPtr( mySigma);
589	</pre>
590	If you have several processes you can repeat the procedure any number
591	of times. When <code>pythia.init(...)</code> is called these processes
592	are initialized along with any internal processes you may have switched on,
593	and treated in exactly the same manner. The <code>pythia.next()</code>
594	will therefore generate a mix of the different kinds of processes without
595	distinction. See also the <?php $filepath = $_GET["filepath"];
596	echo "<a href='ProgramFlow.php?filepath=".$filepath."' target='page'>";?>Program Flow</a>
597	description.
598
599	<p/>
600	If the code should be of good quality and general usefulness, it would
601	be simple to include it as a permanently available process in the
602	standard program distribution. The final step of that integration ought to
603	be left for the PYTHIA authors, but here is a description of what is
604	required.
605
606	<p/>
607	A flag has to be defined, that allows the process to be switched on;
608	by default it should always be off. The name of the flag should be
609	chosen of the type <code>model:process</code>. Here the
610	<code>model</code> would be related to the general scenario considered,
611	e.g. <code>Compositeness</code>, while <code>process</code> would
612	specify instate and outstate, separated by a 2 (= to), e.g.
613	<code>ug2u*g</code>.
614	When several processes are implemented and "belong together" it is
615	also useful to define a <code>model:all</code> switch that affects
616	all the separate processes.
617
618	<p/>
619	The flags should normally be stored in the <code>ProcessSelection.xml</code>
620	file or one of its daughters for a specific kind of processes. This is to
621	make them easily found by users. You could create and use your own
622	<code>.xml</code> file, so long as you then add that name to the
623	list of files in the <code>Index.xml</code> file. (If not,
624	the flags would never be created and the program would not work.)
625
626	<p/>
627	In the <code>ProcessContainer.c</code> file, the
628	<code>SetupContainers::init()</code> method needs to be expanded to
629	create instances of the processes switched on. This code is fairly
630	repetitive, and should be easy to copy and modify from the code
631	already there. The basic structure is
632	<br/>(i) check whether a process is requested by the user and, if so,
633	<br/>(ii) create an instance of the matrix-element class,
634	<br/>(iii)create a container for the matrix element and its associated
635	phase-space handling, and
636	<br>(iv) add the container to the existing process list.
637
638	<p/>
639	Two minor variations are possible. One is that a set of related
640	processes are lumped inside the the same initial check, i.e. are
641	switched on all together. The second is that the matrix-element
642	constructor may take arguments, as specified by you (see above).
643	If so, the same basic matrix element may be recycled for a set of
644	related processes, e.g. one for a composite <i>u</i> and one for
645	a composite <i>d</i>. Obviously these variations may be combined.
646
647	<input type="hidden" name="saved" value="1"/>
648
649	<?php
650	echo "<input type='hidden' name='filepath' value='".$_GET["filepath"]."'/>"?>
651
652	<table width="100%"><tr><td align="right"><input type="submit" value="Save Settings" /></td></tr></table>
653	</form>
654
655	<?php
656
657	if($_POST["saved"] == 1)
658	{
659	$filepath = $_POST["filepath"];
660	$handle = fopen($filepath, 'a');
661
662	if($_POST["1"] != "off")
663	{
664	$data = "SigmaProcess:cMassiveME = ".$_POST["1"]."\n";
665	fwrite($handle,$data);
666	}
667	if($_POST["2"] != "on")
668	{
669	$data = "SigmaProcess:bMassiveME = ".$_POST["2"]."\n";
670	fwrite($handle,$data);
671	}
672	if($_POST["3"] != "off")
673	{
674	$data = "SigmaProcess:muMassiveME = ".$_POST["3"]."\n";
675	fwrite($handle,$data);
676	}
677	if($_POST["4"] != "on")
678	{
679	$data = "SigmaProcess:tauMassiveME = ".$_POST["4"]."\n";
680	fwrite($handle,$data);
681	}
682	fclose($handle);
683	}
684
685	?>
686	</body>
687	</html>
688
689	<!-- Copyright (C) 2012 Torbjorn Sjostrand -->

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

Context Navigation

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

Download in other formats: