Chapter 9 Methods for Hard Interactions
The hard interaction process is the core of any physics simulation within an MC event generator. One tries to describe the dominant particle interaction in the physics process of interest at a given order in perturbation theory, thereby making use of field-theoretic factorization theorems, especially for QCD, in order to separate non-perturbative physics like parton distribution functions (PDFs) or fragmentation functions from the perturbative part. Still, it is in many cases not possible to describe the perturbative part completely by means of fixed-order hard matrix elements: in soft and/or collinear regions of phase space, multiple emission of gluons and quarks (in general QCD jets) and photons necessitates a resummation, as large logarithms accompany the perturbative coupling constants and render fixed-order perturbation theory unreliable. The resummation of these large logarithms can be done analytically or (semi-)numerically, however, usually only for very inclusive quantities. At the level of exclusive events, these phase space regions are the realm of (QCD and also QED) parton showers that approximate multi-leg matrix elements from the hard perturbative into to the soft-/collinear regime. The hard matrix elements are then the core building blocks of the physics description inside the MC event generator. WHIZARD generates these hard matrix elements at tree-level (or sometimes for loop-induced processes using effective operators as insertions) as leading-order processes. This is done by the O’Mega subpackage that is automatically called by WHIZARD. Besides these physical matrix elements, there exist a couple of methods to generate dummy matrix elements for testing purposes, or for generating beam profiles and using them with externally linked special matrix elements. Especially for one-loop processes (next-to-leading order for tree-allowed processes or leading-order for loop-induced processes), WHIZARD allows to use matrix elements from external providers, so called OLP programs (one-loop providers). Of course, all of these external packages can also generate tree-level matrix elements, which can then be used as well in WHIZARD. We start the discussion with the two different options for test matrix elements, internal test matrix elements with no generated compiled code in Sec. 9.1 and so called template matrix elements with actual Fortran code that is compiled and linked, and can also be modified by the user in Sec. 9.2. Then, we move to the main matrix element method by the matrix element generator O’Mega in Sec. 9.3. Matrix elements from the external matrix element generators are discussed in the order of which interfaces for the external tools have been implemented: Gosam in Sec. 9.4, OpenLoops in Sec. 9.5, and Recola in Sec. 9.6. 9.1 Internal test matrix elementsThis method is merely for internal consistency checks inside WHIZARD, and is not really intended to be utilized by the user. The method is invoked by
This particular method is only applicable for the internal test model Test.mdl, which just contains a Higgs boson and a top quark. Technically, it will also works within model specifications for the Standard Model, or the Minimal Supersymmetric Standard Model (MSSM), or all models which contain particles named as H and t with PDG codes 25 and 6, respectively. So, the models QED and QCD will not work. Irrespective of what is given in the SINDARIN file as a scattering input process, WHIZARD will always take the process
or for the test model:
as corresponding process. (This is the same process, just with differing nomenclature in the different models). No matrix element code is generated and compiled, the matrix element is completely internal, included in the WHIZARD executable (or library), with a unit value for the squared amplitude. The integration will always be performed for this particularly process, even if the user provides a different process for that method. Hence, the result will always be the volume of the relativistic two-particle phase space. The only two parameters that influence the result are the collider energy, sqrts, and the mass of the Higgs particle with PDG code 25 (this mass parameter can be changed in the model Test as ms, while it would be mH in the Standard Model SM. It is also possible to use a test matrix element, again internal, for decay processes, where again WHIZARD will take a predefined process:
in the SM model or
Again, this is the same process with PDG codes 25 → 6 −6 in the corresponding models. Note that in the model SM the mass of the quark is set via the variable mtop, while it is mf in the model Test. Besides the fact that the user always gets a fixed process and cannot modify any matrix element code by hand, one can do all things as for a normal process like generating events, different weights, testing rebuild flags, using different setups and reweight events accordingly. Also factorized processes with production and decay can be tested that way. In order to avoid confusion, it is highly recommended to use this method unit_test only with the test model setup, model Test. On the technical side, the method unit_test does not produce a process library (at least not an externally linked one), and also not a makefile in order to modify any process files (which anyways do not exist for that method). Except for the logfiles and the phase space file, all files are internal. 9.2 Template matrix elementsMuch more versatile for the user than the previous matrix element method in 9.1, are two different methods with constant template matrix elements. These are written out as Fortran code by the WHIZARD main executable (or library), providing an interface that is (almost) identical to the matrix element code produced by the O’Mega generator (cf. the next section, Sec. 9.3. There are actually two different methods for that purpose, providing matrix elements with different normalizations:
generates matrix elements which give after integration over phase space exactly one. Of course, for multi-particle final states the integration can fluctuate numerically and could then give numbers that are only close to one but not exactly one. Furthermore, the normalization is not exact if any of the external particles have non-zero masses, or there are any cuts involved. But otherwise, the integral from WHIZARD should give unity irrespective of the number of final state particles. In contrast to this, the second method,
gives a unit matrix elements, or rather a matrix element that contains helicity and color averaging factors for the initial state and the square root of the factorials of identical final state particles in the denominator. Hence, integration over the final state momentum configuration gives a cross section that corresponds to the volume of the n-particle final state phase space, divided by the corresponding flux factor, resulting in
for the massless case and
for the massive case. Here, m1 and m2 are the masses of the incoming, m3 and m4 the masses of the outgoing particles, and λ(x,y,z) = x2 + y2 + z2 − 2xy − 2xz − 2yz. For the general massless case with no cuts, the integral should be exactly
where the volume of the massless n-particle phase space is given by
For n≠2 the phase space volume is dimensionful, so the units of the integral are fb×GeV2(n−2). (Note that for physical matrix elements this is compensated by momentum factors from wave functions, propagators, vertices and possibly dimensionful coupling constants, but here the matrix element is just equal to unity.) Note that the phase-space integration for the template and template_unity matrix element methods is organized in the same way as it would be for the real 2→ n process. Since such a phase space parameterization is not optimized for the constant matrix element that is supplied instead, good convergence is not guaranteed. (Setting ?stratified = true may be helpful here.) The possibility to call a dummy matrix element with this method allows to histogram spectra or structure functions: Choose a trivial process such as uu→ dd, select the template_unity method, switch on structure functions for one (or both) beams, and generate events. The distribution of the final-state mass squared reflects the x dependence of the selected structure function. Furthermore, the constant in the source code of the unit matrix elements can be easily modified by the user with their Fortran code in order to study customized matrix elements. Just rerun WHIZARD with the --recompile option after the modification of the matrix element code. Both methods, template and template_unity will also work even if no OCaml compiler is found or used and consequently the O’Mega matrix elemente generator (cf. Sec. 9.3 is disable. The methods produce a process library for their corresponding processes, and a makefile, by which WHIZARD steers compilation and linking of the process source code. There is also a specialized third version of template matrix elements, called template_gg_had, which should only be used for a dedicated simulation of low-p⊥ hadrons in photon-photon collisions (either from the beam spectrum at an electron-positron or a photon collider) or in collinear splittings of photons off leptons using the equivalent photon approximation (EPA). For it, parton shower and hadronization from PYTHIA6 has to be switched on. WHIZARD will use special parameterizations from e.g. the Crystal Ball experiment on the total cross section and distribution of hadrons in photon-photon collisions. 9.3 The O’Mega matrix elementsO’Mega is a subpackage of WHIZARD, written in OCaml, which can produce matrix elements for a wide class of implemented physics models (cf. Sec. 10.1.1 and 10.1.2 for a list of all implemented physics models), and even almost arbitrary models when using external Lagrange level tools, cf. Chap. 17. There are two different variants for matrix elements from O’Mega: the first one is invoked as
and is the default method for WHIZARD. It produces matrix element as Fortran code which is then compiled and linked. An alternative method, which for the moment is only available for the Standard Model and its variants as well models which are quite similar to the SM, e.g. the Two-Higgs doublet model or the Higgs-singlet extension. This method is taken when setting
The acronym ovm stands for O’Mega Virtual Machine (OVM). The first (default) method (omega) of O’Mega matrix elements produces Fortran code for the matrix elements,that is compiled by the same compiler with which WHIZARD has been compiled. The OVM method (ovm) generates an ASCII file with so called op code for operations. These are just numbers which tell what numerical operations are to be performed on momenta, wave functions and vertex expression in order to yield a complex number for the amplitude. The op codes are interpreted by the OVM in the same as a Java Virtual Machine. In both cases, a compiled Fortran is generated which for the omega method contains the full expression for the matrix element as Fortran code, while for the ovm method this is the driver file of the OVM. Hence, for the ovm method this file always has roughly the same size irrespective of the complexity of the process. For the ovm method, there will also be the ASCII file that contains the op codes, which has a name with an .hbc suffix: <process_name>.hbc. For both O’Mega methods, there will be a process library created as for the template matrix elements (cf. Sec. 9.2) named default_lib.f90 which can be given a user-defined name using the library = "<library>" command. Again, for both methods omega and ovm, a makefile named <library>_lib.makefile is generated by which WHIZARD steers compilation, linking and clean-up of the process sources. This makefile can handily be adapted by the user in case she or he wants to modify the source code for the process (in the case of the source code method). Note that WHIZARD’s default ME method via O’Mega allows the user to specify many different options either globally for all processes in the SINDARIN, or locally for each process separately in curly brackets behind the corresponding process definition. Examples are
With the exception of the restrictions steered by the $restrictions = "<restriction>" string expression, these options have to be set in their specific O’Mega syntax verbatim via the string command $omega_flags = "<expr>". 9.4 Interface to GoSamOne of the supported methods for automated matrix elements from external providers is for the Gosam package. This program package which is a combination of Python scripts and Fortran libraries, allows both for tree and one-loop matrix elements (which is leading or next-to-leading order, depending on whether the corresponding process is allowed at the tree level or not). In principle, the advanced version of Gosam also allows for the evaluation of two-loop virtual matrix elements, however, this is currently not supported in WHIZARD. This method is invoked via the command
Of course, this will only work correctly of Gosam with all its subcomponents has been correctly found during configuration of WHIZARD and then subsequently correctly linked. In order to generate the tables for spin, flavor and color states for the corresponding process, first O’Mega is called to provide Fortran code for the interfaces to all the metadata for the process(es) to be evaluated. Next, the Gosam Python script is automatically invoked that first checks for the necessary ingredients to produce, compile and link the Gosam matrix elements. These are the the Qgraf topology generator for the diagrams, Form to perform algebra, the Samurai, AVHLoop, QCDLoop and Ninja libraries for Passarino-Veltman reduction, one-loop tensor integrals etc. As a next step, Gosam automatically writes and executes a configure script, and then it exchanges the Binoth Les Houches accord (BLHA) contract files between WHIZARD and itself [37, 38] to check whether it actually generate code for the demanded process at the given order. Note that the contract and answer files do not have to be written by the user by hand, but are generated automatically within the program work flow initiated by the original SINDARIN script. Gosam then generates Fortran code for the different components of the processes, compiles it and links it into a library, which is then automatically accessible (as an external process library) from inside WHIZARD. The phase space setup and the integration as well as the LO (and NLO) event generation work then in exactly the same way as for O’Mega matrix elements. As an NLO calculation consists of different components for the Born, the real correction, the virtual correction, the subtraction part and possible further components depending on the details of the calculation, there is the possible to separately choose the matrix element method for those components via the keywords $loop_me_method, $real_tree_me_method, $correlation_me_method etc. These keywords overwrite the master switch of the $method keyword. For more information on the switches and details of the functionality of Gosam, cf. http://gosam.hepforge.org. 9.5 Interface to OpenloopsVery similar to the case of Gosam, cf. Sec. 9.4, is the case for OpenLoops matrix elements. Also here, first O’Mega is called in order to provide an interface for the spin, flavor and color degrees of freedom for the corresponding process. Information exchange between WHIZARD and OpenLoops then works in the same automatic way as for Gosam via the BLHA interface. This matrix element method is invoked via
This again is the master switch that will tell WHIZARD to use OpenLoops for all components, while there are special keywords to tailor-make the setup for the different components of an NLO calculation (cf. Sec. 9.4. The main difference between OpenLoops and Gosam is that for OpenLoops there is no process code to be generated, compiled and linked for a process, but a precompiled library is called and linked, e.g. ppllj for the Drell-Yan process. Of course, this library has to be installed on the system, but if that is not the case, the user can execute the OpenLoops script in the source directory of OpenLoops to download, compile and link the corresponding dynamic library. This limits (for the moment) the usage of OpenLoops to processes where pre-existint libraries for that specific processes have been generated by the OpenLoops authors. A new improved generator for general process libraries for OpenLoops will get rid of that restriction. For more information on the installation, switches and details of the functionality of OpenLoops, cf. http://openloops.hepforge.org. 9.6 Interface to RecolaThe third one-loop provider (OLP) for external matrix elements that is supported by WHIZARD, is Recola. In contrast to Gosam, cf. Sec. 9.4, and OpenLoops, cf. Sec. 9.5, Recola does not use a BLHA interface to exchange information with WHIZARD, but its own tailor-made C interoperable library interface to communicate to the Monte Carlo side. Recola matrix elements are called for via
Recola uses a highly efficient algorithm to generate process code for LO and NLO SM amplitudes in a fully recursive manner. At the moment, the setup of the interface within WHIZARD does not allow to invoke more than one different process in Recola: this would lead to a repeated initialization of the main setup of Recola and would consequently crash it. It is foreseen in the future to have a safeguard mechanism inside WHIZARD in order to guarantee initialization of Recola only once, but this is not yet implemented. Further information on the installation, details and parameters of Recola can be found at http://recola.hepforge.org. 9.7 Special applicationsThere are also special applications with combinations of matrix elements from different sources for dedicated purposes like e.g. for the matched top–anti-top threshold in e+e−. For this special application which depending on the order of the matching takes only O’Mega matrix elements or at NLO combines amplitudes from O’Mega and OpenLoops, is invoked by the method:
|
