PYTHIA8/pythia8170/phpdoc/SemiInternalProcesses.php

   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  &nbsp;&nbsp;(<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  &nbsp;&nbsp;(<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  &nbsp;&nbsp;(<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  &nbsp;&nbsp;(<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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</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) &nbsp;</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) &nbsp;</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> &lt;= <code>i </code> &lt;= <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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</strong> <br/>
 454
 455 <strong>int SigmaProcess::id4Mass() &nbsp;</strong> <br/>
 456
 457 <strong>int SigmaProcess::id5Mass() &nbsp;</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() &nbsp;</strong> <br/>
 469
 470 <strong>int SigmaProcess::resonanceB() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</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() &nbsp;</strong> <br/>
 521
 522 <strong>int SigmaProcess::idTchan2() &nbsp;</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() &nbsp;</strong> <br/>
 533
 534 <strong>double SigmaProcess::tChanFracPow2() &nbsp;</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() &nbsp;</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() &nbsp;</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 -->