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