Chapter ‍17 New External Physics Models

• 17.1 New physics models via SARAH
• 17.2 New physics models via FeynRules
• 17.3 New physics models via the UFO file format

It is never possible to include all incarnations of physics models that can be described by the maybe weirdest form of a quantum field theory in a tailor-made implementation within a program like WHIZARD. Users clearly want to be able to use their own special type of model; in order to do so there are external tools to translate models described by their field content and Lagrangian densities into Feynman rules and make them available in an event generator like WHIZARD. In this chapter, we describe the interfaces to two such external models, SARAH and FeynRules.

The FeynRules interface had been started already for the legacy version WHIZARD1 (where it had to be downloaded from https://whizard.hepforge.org as a separate package), but for the WHIZARDtwo release series it has been included in the FeynRules package (from their version v1.6.0 on). Note that there was a regression for the usage of external models (from either SARAH or FeynRules) in the first release of series v2.2, v2.2.0. This has been fixed in all upcoming versions.

Besides using SARAH or FeynRules via their interfaces, there is now a much easier way to let those programs output model files in the "Universal FeynRules Output" (or UFO). This option does not have any principle limitations for models, and also does not rely on the never truly constant interfaces between two different tools. Their usage is described in Sec. ‍17.3.

17.1 New physics models via SARAH

SARAH ‍[75, 76, 77, 78, 79] is a Mathematica ‍[80] package which derives for a given model the minimum conditions of the vacuum, the mass matrices, and vertices at tree-level as well as expressions for the one-loop corrections for all masses and the full two-loop renormalization group equations (RGEs). The vertices can be exported to be used with WHIZARD/O’Mega. All other information can be used to generate Fortran source code for the RGE solution tool and spectrum generator SPheno ‍[81, 82] to get a spectrum generator for any model. The advantage is that SPheno calculates a consistent set of parameters (couplings, masses, rotation matrices, decay widths) which can be used as input for WHIZARD. SARAH and SPheno can be also downloaded from the HepForge server:

17.1.1 WHIZARD/O’Mega model files from SARAH

Generating the model files

Here we are giving only the information relevant to generate models for WHIZARD. For more details about the installation of SARAH and an exhaustion documentation about its usage, confer the SARAH manual.

To generate the model files for WHIZARD/O’Mega with SARAH, a new Mathematica session has to be started. SARAH is loaded via

<<SARAH-4.2.1/SARAH.m;

if SARAH has been stored in the applications directory of Mathematica. Otherwise, the full path has to be given

<<[Path_to_SARAH]/SARAH.m;

To get an overview which models are delivered with SARAH, the command ShowModels can be used. As an example, we use in the following the triplet extended MSSM (TMSSM) and initialize it in SARAH via

Start["TMSSM"];

Finally, the output intended for WHIZARD/O’Mega is started via

MakeWHIZARD[Options]

The possible options of the MakeWHIZARD command are

1. WriteOmega, with values: True or False, default: True
   Defines if the model files for O’Mega should be written
2. WriteWHIZARD, with values: True or False, default: True
   Defines if the model files for WHIZARD should be written
3. Exclude, with values: list of generic type, Default: {SSSS}
   Defines which generic vertices are not exported to the model file
4. WOModelName, with values: string, default: name of the model in SARAH followed by _sarah
   Gives the possibility to change the model name
5. MaximalCouplingsPerFile, with values: integer, default: 150
   Defines the maximal number of couplings written per file
6. Version, with values: formatted number, Default: 2.2.1 ‍¹,
   Defines the version of WHIZARD for which the model file is generated

All options and the default values are also shown in the Mathematica session via
Options[MakeWHIZARD].

Using the generated model files with WHIZARD

After the interface has completed evaluation, the generated files can be found in the subdirectory WHIZARD_Omega of SARAHs output directory. In order to use it the generated code must be compiled and installed. For this purpose, open a terminal, enter the output directory

<PATH_to_SARAH>/Output/TMSSM/EWSB/WHIZARD_Omega/

and run

./configure
make install

By default, the last command installs the compiled model into .whizard in current user’s home directory where it is automatically picked up by WHIZARD. Alternative installation paths can be specified using the --prefix option to WHIZARD.

./configure --prefix=/path/to/installation/prefix

If the files are installed into the WHIZARD installation prefix, the program will also pick them up automatically, while WHIZARD’s --localprefix option must be used to communicate any other choice to WHIZARD. In case WHIZARD is not available in the binary search path, the WO_CONFIG environment variable can be used to point configure to the binaries

./configure WO_CONFIG=/path/to/whizard/binaries

More information on the available options and their syntax can be obtained with the --help option.

After the model is compiled it can be used in WHIZARD as

model = tmssm_sarah

17.1.2 Linking SPheno and WHIZARD

As mentioned above, the user can also use SPheno to generate spectra for its models. This is done by means of Fortran code for SPheno, exported from SARAH. To do so, the user has to apply the command MakeSPheno[]. For more details about the options of this command and how to compile and use the SPheno output, we refer to the SARAH manual.
As soon as the SPheno version for the given model is ready it can be used to generate files with all necessary numerical values for the parameters in a format which is understood by WHIZARD. For this purpose, the corresponding flag in the Les Houches input file of SPheno has to be turned on:

Block SPhenoInput   # SPheno specific input
...
75 1               # Write WHIZARD files

Afterwards, SPheno returns not only the spectrum file in the standard SUSY Les Houches accord (SLHA) format (for more details about the SLHA and the WHIZARD SLHA interface cf. Sec. ‍10.2), but also an additional file called WHIZARD.par.TMSSM for our example. This file can be used in the SINDARIN input file via

include ("WHIZARD.par.TMSSM")

17.1.3 BSM Toolbox

A convenient way to install SARAH together with WHIZARD, SPheno and some other codes are the BSM Toolbox scripts ² ‍[83]. These scripts are available at

The Toolbox provides two scripts. First, the configure script is used via

toolbox-src-dir> mkdir build
toolbox-src-dir> cd build
toolbox-src-dir> ../configure

The configure script checks for the requirements of the different packages and downloads all codes. All downloaded archives will be placed in the tarballs subdirectory of the directory containing the configure script. Command line options can be used to disable specific packages and to point the script to custom locations of compilers and of the Mathematica kernel; a full list of those can be obtained by calling configure with the --help option.

After configure finishes successfully, make can be called to build all configured packages

toolbox-build-dir> make

configure creates also the second script which automates the implementation of a new model into all packages. The butler script takes as argument the name of the model in SARAH, e.g.

> ./butler TMSSM

The butler script runs SARAH to get the output in the same form as the WHIZARD/O’Mega model files and the code for SPheno. Afterwards, it installs the model in all packages and compiles the new WHIZARD/O’Mega model files as well as the new SPheno module.

17.2 New physics models via FeynRules

In this section, we present the interface between the external tool FeynRules [84, 85, 86] and WHIZARD. FeynRules is a Mathematica ‍[80] package that allows to derive Feynman rules from any perturbative quantum field theory-based Lagrangian in an automated way. It can be downloaded from

The input provided by the user is threefold and consists of the Lagrangian defining the model, together with the definitions of all the particles and parameters that appear in the model. Once this information is provided, FeynRules can perform basic checks on the sanity of the implementation (e.g. hermiticity, normalization of the quadratic terms), and finally computes all the interaction vertices associated with the model and store them in an internal format for later processing. After the Feynman rules have been obtained, FeynRules can export the interaction vertices to WHIZARD via a dedicated interface ‍[87]. The interface checks whether all the vertices are compliant with the structures supported by WHIZARD’s matrix element generator O’Mega, and discard them in the case they are not supported. The output of the interface consists of a set of files organized in a single directory which can be injected into WHIZARD/O’Mega and used as any other built-in models. Together with the model files, a framework is created which allows to communicate the new models to WHIZARD in a well defined way, after which step the model can be used exactly like the built-in ones. This specifically means that the user is not required to manually modify the code of WHIZARD/O’Mega, the models created by the interface can be used directly without any further user intervention. We first describe the installation and general usage of the interface, and then list the general properties like the supported particle types, color quantum numbers and Lorentz structures as well as types of gauge interactions.

17.2.1 Installation and Usage of the WHIZARD-FeynRules interface

Installation and basic usage:

From FeynRules version 1.6.0 onward, the interface to WHIZARD is part of the FeynRules distribution³. In addition, the latest version of the interface can be downloaded from the WHIZARD homepage on HepForge. There you can also find an installer that can be used to inject the interface into an existing FeynRules installation (which allows to use the interface with the FeynRules release series1.4.x where it is not part of the package).

Once installed, the interface can be called and used in the same way FeynRules’ other interfaces described in ‍[84]. The details of how to install and use FeynRules itself can be found there, ‍[84, 85, 86]. Here, we only describe how to use the interface to inject new models into WHIZARD. For example, once the FeynRules environment has been initialized and a model has been loaded, the command

  WriteWOOutput[L]

will call the FeynmanRules command to extract the Feynman rules from the Lagrangian L, translate them together with the model data and finally write the files necessary for using the model within WHIZARD to an output directory (the name of which is inferred from the model name by default). Options can be added for further control over the translation process (see Sec. ‍17.2.2). Instead of using a Lagrangian, it is also possible to call the interface on a pure vertex list. For example, the following command

  WriteWOOutput[Input -> list]

will directly translate the vertex list list. Note that this vertex list must be given in flavor-expanded form in order for the interface to process it correctly.

The interface also supports the WriteWOExtParams command described in ‍[84]. Issuing

  WriteWOExtParams[filename]

will write a list of all the external parameters to filename. This is done in the form of a SINDARIN script. The only option accepted by the command above is the target version of WHIZARD, set by the option WOWhizardVersion.

During execution, the interface will print out a series of messages. It is highly advised to carefully read through this output as it not only summarizes the settings and the location of the output files, but also contains information on any skipped vertices or potential incompatibilities of the model with WHIZARD.

After the interface has run successfully and written the model files to the output directory, the model must be imported into WHIZARD. For doing so, the model files have to be compiled and can then be installed independently of WHIZARD. In the simplest scenario, assuming that the output directory is the current working directory and that the WHIZARD binaries can be found in the current ${PATH}, the installation is performed by simply executing

./configure~\&\&~make clean~\&\&~make install

This will compile the model and install it into the directory ${HOME}/.whizard, making it fully available to WHIZARD without any further intervention. The build system can be adapted to more complicated cases through several options to the configure which are listed in the INSTALL file created in the output directory. A detailed explanation of all options can be found in Sec. ‍17.2.2.

Supported fields and vertices:

The following fields are currently supported by the interface: scalars, Dirac and Majorana fermions, vectors and symmetric tensors. The set of accepted operators, the full list of which can be found in Tab. ‍17.1, is a subset of all the operators supported by O’Mega. While still limited, this list is sufficient for a large number of BSM models. In addition, a future version of WHIZARD/O’Mega will support the definition of completely general Lorentz structures in the model, allowing the interface to translate all interactions handled by FeynRules. This will be done by means of a parser within O’Mega of the UFO file format for model files from FeynRules.

---

Particle spins	Supported Lorentz structures
FFS	All operators of dimension four are supported.
FFV	All operators of dimension four are supported.
SSS	All dimension three interactions are supported.
SVV	Supported operators:     dimension 3: O3 = V1µV2µφ dimension 5: O5 = φ (∂µV1ν− ∂νV1µ) (∂µV2ν − ∂νV2µ) Note that O5 generates the effective gluon-gluon-Higgs couplings obtained by integrating out heavy quarks.
SSV	(φ1∂µφ2 − φ2∂µφ1)Vµ  type interactions are supported.
SSVV	All dimension four interactions are supported.
SSSS	All dimension four interactions are supported.
VVV	All parity-conserving dimension four operators are supported, with the restriction that non-gauge interactions may be split into several vertices and can only be handled if all three fields are mutually different.
VVVV	All parity conserving dimension four operators are supported.
TSS, TVV, TFF	The three point couplings in the Appendix of Ref. [89] are supported.

Table 17.1: All Lorentz structures currently supported by the WHIZARD-FeynRules interface, sorted with respect to the spins of the particles. “S” stands for scalar, “F” for fermion (either Majorana or Dirac) and “V” for vector.

---

Color:

Color is treated in O’Mega in the color flow decomposition, with the flow structure being implicitly determined from the representations of the particles present at the vertex. Therefore, the interface has to strip the color structure from the vertices derived by FeynRules before writing them out to the model files. While this process is straightforward for all color structures which correspond only to a single flow assignment, vertices with several possible flow configurations must be treated with care in order to avoid mismatches between the flows assigned by O’Mega and those actually encoded in the couplings. To this end, the interface derives the color flow decomposition from the color structure determined by FeynRules and rejects all vertices which would lead to a wrong flow assignment by O’Mega (these rejections are accompanied by warnings from the interface)⁴.

At the moment, the SU(3)_C representations supported by both WHIZARD and the interface are singlets (1), triplets (3), antitriplets (3) and octets (8). Tab. ‍17.2 shows all combinations of these representations which can form singlets together with the support status of the respective color structures in WHIZARD and the interface. Although the supported color structures do not comprise all possible singlets, the list is sufficient for a large number of SM extensions. Furthermore, a future revision of WHIZARD/O’Mega will allow for explicit color flow assignments, thus removing most of the current restrictions.

---

SU(3)C representations	Support status
111,  331,  338, 1111, 3311, 3381	Fully supported by the interface
888,  8881	Supported only if at least two of the octets are identical particles.
881,  8811	Fully supported by the interface5.
3388	Supported only if the octets are identical particles.
8888	The only supported flow structure is · Γ(1,2,3,4)  +  all acyclic permutations where Γ(1,2,3,4) represents the Lorentz structure associated with the first flow.
333,  333,  3331 3331, 3333	Unsupported (at the moment)

Table 17.2: All possible combinations of three or four SU(3)C representations supported by FeynRules which can be used to build singlets, together with the support status of the corresponding color structures in WHIZARD and the interface.

---

Running α_S:

While a running strong coupling is fully supported by the interface, a choice has to be made which quantities are to be reevaluated when the strong coupling is evolved. By default aS, G (see Ref. ‍[84] for the nomenclature regarding the QCD coupling) and any vertex factors depending on them are evolved. The list of internal parameters that are to be recalculated (together with the vertex factors depending on them) can be extended (beyond aS and G) by using the option WORunParameters when calling the interface ‍⁶.

Gauge choices:

The interface supports the unitarity, Feynman and R_ξ gauges. The choice of gauge must be communicated to the interface via the option WOGauge. Note that massless gauge bosons are always treated in Feynman gauge.

If the selected gauge is Feynman or R_ξ, the interface can automatically assign the proper masses to the Goldstone bosons. This behavior is requested by using the WOAutoGauge option. In the R_ξ gauges, the symbol representing the gauge ξ must be communicated to the interface by using the WOGaugeSymbol option (the symbol is automatically introduced into the list of external parameters if WOAutoGauge is selected at the same time). This feature can be used to automatically extend models implemented in Feynman gauge to the R_ξ gauges.

Since WHIZARD (at least until the release series 2.3) is a tree-level tool working with helicity amplitudes, the ghost sector is irrelevant for WHIZARD and hence dropped by the interface.

17.2.2 Options of the WHIZARD-FeynRules interface

In the following we present a comprehensive list of all the options accepted by WriteWOOutput. Additionally, we note that all options of the FeynRules command FeynmanRules are accepted by WriteWOOutput, which passes them on to FeynmanRules.

Input

An optional vertex list to use instead of a Lagrangian (which can then be omitted).

WOWhizardVersion

Select the WHIZARD version for which code is to be generated. The currently available choices are summarized in Tab. ‍17.3.

---

WOWhizardVersion	WHIZARD versions supported
"2.0.3" (default)	2.0.3+
"2.0"	2.0.0 – 2.0.2
"1.96"	1.96+   (deprecated)
"1.93"	1.93 – 1.95   (deprecated)
"1.92"	1.92   (deprecated)

Table 17.3: Currently available choices for the WOWhizardVersion option, together with the respective WHIZARD versions supported by them.

---

This list will expand as the program evolves. To get a summary of all choices available in a particular version of the interface, use the command ?WOWhizardVersion.

WOModelName

The name under which the model will be known to WHIZARD⁷. The default is determined from the FeynRules model name.

Output

The name of the output directory. The default is determined from the FeynRules model name.

WOGauge

Gauge choice (cf. Sec. ‍17.2.1). Possible values are: WOUnitarity (default), WOFeynman, WORxi

WOGaugeParameter

The external or internal parameter representing the gauge ξ in the R_ξ gauges (cf. Sec. ‍17.2.1). Default: Rxi

WOAutoGauge

Automatically assign the Goldstone boson masses in the Feynman and R_ξ gauges and automatically append the symbol for ξ to the parameter list in the R_ξ gauges. Default: False

WORunParameters

The list of all internal parameters which will be recalculated if α_S is evolved (see above)⁸. Default: {aS, G}

WOFast

If the interface drops vertices which are supported, this option can be set to False to enable some more time consuming checks which might aid the identification. Default: True

WOMaxCouplingsPerFile

The maximum number of couplings that are written to a single Fortran file. If compilation takes too long or fails, this can be lowered. Default: 500

WOVerbose

Enable verbose output and in particular more extensive information on any skipped vertices. Default: False

17.2.3 Validation of the interface

The output of the interface has been extensively validated. Specifically, the integrated cross sections for all possible 2→ 2 processes in the FeynRules SM, the MSSM and the Three-Site Higgsless Model have been compared between WHIZARD, MadGraph, and CalcHep, using the respective FeynRules interfaces as well as the in-house implementations of these models (the Three-Site Higgsless model not being available in MadGraph). Also, different gauges have been checked for WHIZARD and CalcHep. In all comparisons, excellent agreement within the Monte Carlo errors was achieved. The detailed comparison including examples of the comparison tables can be found in ‍[87].

17.2.4 Examples for the WHIZARD-/FeynRules interface

Here, we will use the Standard Model, the MSSM and the Three-Site Higgsless Model as prime examples to explain the usage of the interface. Those are the models that have been used in the validation of the interface in ‍[87]. The examples are constructed to show the application of the different options of the interface and to serve as a starting point for the generation of the user’s own WHIZARD versions of other FeynRules models.

WHIZARD-FeynRules example: Standard Model

To start off, we will create Whizard 2 versions of the Standard Model as implemented in FeynRules for different gauge choices.

SM: Unitarity Gauge

In order to invoke FeynRules, we change to the corresponding directory and load the program in Mathematica via

$FeynRulesPath =
     SetDirectory["<path-to-FeynRules>"];
<<FeynRules`

The model is loaded by

LoadModel["Models/SM/SM.fr"];
FeynmanGauge = False;

Note that the second line is required to switch the Standard Model to Unitarity gauge as opposed to Feynman gauge (which is the default). Generating a WHIZARD model is now simply done by

WriteWOOutput[LSM];

After invokation, the interface first gives a short summary of the setup

Short model name is "fr_standard_model"
Gauge: Unitarity
Generating code for WHIZARD / O'Mega
                        version 2.0.3
Maximum number of couplings per FORTRAN
                           module: 500
Extensive lorentz structure checks disabled.

Note that, as we have not changed any options, those settings represent the defaults. The output proceeds with the calculation of the Feynman rules from the Standard Model Lagrangian LSM. After the rules have been derived, the interface starts generating output and tries to match the vertices to their WHIZARD/O’Mega counterparts.

   10 of 75 vertices processed...
   20 of 75 vertices processed...
   30 of 75 vertices processed...
   40 of 75 vertices processed...
   50 of 75 vertices processed...
   60 of 75 vertices processed...
   70 of 75 vertices processed...
processed a total of 75 vertices, kept 74
   of them and threw away 1, 1 of which
   contained ghosts or goldstone bosons.

The last line of the above output is particularily interesting, as it informs us that everything worked out correctly: the interface was able to match all vertices, and the only discarded vertex was the QCD ghost interaction. After the interface has finished running, the model files in the output directory are ready to use and can be compiled using the procedure described in the previous section.

SM: Feynman and R_ξ gauges

As the Standard Model as implemented in FeynRules also supports Feynman gauge, we can use the program to generate a Feynman gauge version of the model. Loading FeynRules and the model proceeds as above, with the only difference being the change

FeynmanGauge = True;

In order to inform the interface about the modified gauge, we have to add the option WOGauge

WriteWOOutput[LSM, WOGauge -> WOFeynman];

The modified gauge is reflected in the output of the interface

Short model name is "fr_standard_model"
Gauge: Feynman
Generating code for WHIZARD / O'Mega
                        version 2.0.3
Maximum number of couplings per FORTRAN
                           module: 500
Extensive lorentz structure checks disabled.

The summary of the vertex identification now takes the following form

processed a total of 163 vertices, kept 139
   of them and threw away 24, 24 of which
   contained ghosts.

Again, this line tells us that there were no problems — the only discarded interactions involved the ghost sector which is irrelevant for the tree-level part of WHIZARD.

For a tree-level calculation, the only difference between the different gauges from the perspective of the interface are the gauge boson propagators and the Goldstone boson masses. Therefore, the interface can automatically convert a model in Feynman gauge to a model in R_ξ gauge. To this end, the call to the interface must be changed to

WriteWOOutput[LSM, WOGauge -> WORxi,
               WOAutoGauge -> True];

The WOAutoGauge argument instructs the interface to automatically

1. Introduce a symbol for the gauge parameter ξ into the list of external parameters
2. Generate the Goldstone boson masses from those of the associated gauge bosons (ignoring the values provided by FeynRules)

The modified setup is again reflected in the interface output

Short model name is "fr_standard_model"
Gauge: Rxi
Gauge symbol: "Rxi"
Generating code for WHIZARD / O'Mega
                       version 2.0.3
Maximum number of couplings per FORTRAN
                         module: 500
Extensive lorentz structure checks disabled.

Note the default choice Rxi for the name of the ξ parameter – this can be modified via the option WOGaugeParameter.

While the WOAutoGauge feature allows to generate R_ξ gauged models from models implemented in Feynman gauge, it is of course also possible to use models genuinely implemented in R_ξ gauge by setting this parameter to False. Also, note that the choice of gauge only affects the propagators of massive fields. Massless gauge bosons are always treated in Feynman gauge.

Compilation and usage

In order to compile and use the freshly generated model files, change to the output directory which can be determined from the interface output (in this example, it is fr_standard_model-WO). Assuming that WHIZARD is available in the binary search path, compilation and installation proceeds as described above by executing

./configure && make && make install

The model is now ready and can be used similarly to the builtin WHIZARD models. For example, a minimal WHIZARD input file for calculating the e⁺e⁻ —→ W⁺W⁻ scattering cross section in the freshly generated model would look like

model = fr_standard_model
process test = "e+", "e-" -> "W+", "W-"
sqrts = 500 GeV
integrate (test)

WHIZARD/FeynRules example: MSSM

In this Section, we illustrate the usage of the interface between FeynRules and Whizard in the context of the MSSM. All the parameters of the model are then ordered in Les Houches blocks and counters following the SUSY Les Houches Accord (SLHA) [52, 53, 54] (cf. also Sec. ‍10.2).

After having downloaded the model from the FeynRules website, we store it in a new directory, labelled MSSM, of the model library of the local installation of FeynRules. The model can then be loaded in Mathematica as in the case of the SM example above

$FeynRulesPath =
        SetDirectory["<path-to-FeynRules>"];
<<FeynRules`
LoadModel["Models/MSSM/MSSM.fr"];
FeynmanGauge = False;

We are again adopting unitarity gauge.

The number of vertices associated to supersymmetric Lagrangians is in general very large (several thousands). For such models with many interactions, it is recommended to first extract all the Feynman rules of the theory before calling the interface between WHIZARD and FeynRules. The reason is related to the efficiency of the interface which takes a lot of time in the extraction of the interaction vertices. In the case one wishes to study the phenomenology of several benchmark scenarios, this procedure, which is illustrated below, allows to use the interface in the best way. The Feynman rules are derived from the Lagrangian once and for all and then reused by the interface for each set of WHIZARD model files to be produced, considerably speeding up the generation of multiple model files issued from a single Lagrangian. In addition, the scalar potential of supersymmetric theories contains a large set of four scalar interactions, in general irrelevant for collider phenomenology. These vertices can be neglected with the help of the Exclude4Scalars->True option of both interface commands FeynmanRules and WriteWOOutput. The Feynman rules of the MSSM are then computed within the Mathematica notebook by

rules = FeynmanRules[lag,
   Exclude4Scalars->True, FlavorExpand->True];

where lag is the variable containing the Lagrangian.

By default, all the parameters of the model are set to the value of 1. A complete parameter <slha_params>.dat file must therefore be loaded. Such a parameter file can be downloaded from the FeynRules website or created by hand by the user, and loaded into FeynRules as

ReadLHAFile[Input -> "<slha_params>.dat"];

This command does not reduce the size of the model output by removing vertices with vanishing couplings. However, if desired, this task could be done with the LoadRestriction command (see Ref. [90] for details).

The vertices are exported to WHIZARD by the command

WriteWOOutput[Input -> rules];

Note that the numerical values of the parameters of the model can be modified directly from WHIZARD, without having to generate a second time the WHIZARD model files from FeynRules. A SINDARIN script is created by the interface with the help of the instruction

WriteWOExtParams["parameters.sin"];

and can be further modified according to the needs of the user.

WHIZARD-FeynRules example: Three-Site Higgsless Model

The Three-Site Higgsless model or Minimal Higgsless model (MHM) has been implemented into LanHEP ‍[91], FeynRules and independently into WHIZARD ‍[39], and the collider phenomenology has been studied by making use of these implementations [91, 50, 39]. Furthermore, the independent implementations in FeynRules and directly into Whizard have been compared and found to agree ‍[87]. After the discovery of a Higgs boson at the LHC in 2012, such a model is not in good agreement with experimental data any more. Here, we simply use it as a guinea pig to describe the handling of a model with non-renormalizable interactions with the FeynRules interface, and discuss how to generate WHIZARD model files for it. The model has been implemented in Feynman gauge as well as unitarity gauge and contains the variable FeynmanGauge which can be set to True or False. When set to True, the option WOGauge-> WOFeynman must be used, as explained in ‍[87]. R_ξ gauge can also be accomplished with this model by use of the options WOGauge -> WORxi and WOAutoGauge -> True.

Since this model makes use of a nonlinear sigma field of the form

many higher dimensional operators are included in the model which are not currently not supported by WHIZARD. Even for a future release of WHIZARD containing general Lorentz structures in interaction vertices, the user would be forced to expand the series only up to a certain order. Although WHIZARD can reject these vertices and print a warning message to the user, it is preferable to remove the vertices right away in the interface by the option MaxCanonicalDimension->4. This is passed to the command FeynmanRules and restricts the Feynman rules to those of dimension four and smaller⁹.

As the use of different gauges was already illustrated in the SM example, we discuss the model only in Feynman gauge here. We load FeynRules:

$FeynRulesPath =
     SetDirectory["<path-to-FeynRules>"];
<<FeynRules`

The MHM model itself is then loaded by

SetDirectory["<path-to-MHM>"];
LoadModel["3-Site-particles.fr",
   "3-Site-parameters.fr",
   "3-Site-lagrangian.fr"];
FeynmanGauge = True;

where <path-to-MHM> is the path to the directory where the MHM model files are stored and where the output of the WHIZARD interface will be written. The WHIZARD interface is then initiated:

WriteWOOutput[LGauge, LGold, LGhost, LFermion,
   LGoldLeptons, LGoldQuarks,
   MaxCanonicalDimension->4,
   WOGauge->WOFeynman, WOModelName->"fr_mhm"];

where we have also made use of the option WOModelName to change the name of the model as seen by WHIZARD. As in the case of the SM, the interface begins by writing a short informational message:

Short model name is "fr_mhm"
Gauge: Feynman
Generating code for WHIZARD / O'Mega
                       version 2.0.3
Automagically assigning Goldstone
                        boson masses...
Maximum number of couplings per FORTRAN
                        module: 500
Extensive lorentz structure checks disabled.

After calculating the Feynman rules and processing the vertices, the interface gives a summary:

processed a total of 922 vertices, kept 633
  of them and threw away 289, 289 of which
  contained ghosts.

showing that no vertices were missed. The files are stored in the directory fr_mhm and are ready to be installed and used with WHIZARD.

17.3 New physics models via the UFO file format

In this section, we describe how to use the Universal FeynRules Output (UFO, [88]) format for physics models inside WHIZARD. Please refer the manuals of e.g. ‍FeynRules manual for details on how to generate a UFO file for your favorite physics model. UFO files are a collection of Python scripts that encode the particles, the couplings, the Lorentz structures, the decays, as well as parameters, vertices and propagators of the corresponding model. They reside in a directory of the exact name of the model they have been created from.

If the user wants to generate events for processes from a physics model from a UFO file, then this directory of scripts generated by FeynRules is immediately available if it is a subdirectory of the working directory of WHIZARD. The directory name will be taken as the model name. (The UFO-model file name must not start with a non-letter character, i.e. especially not a number. In case such a file name wants to be used at all costs, the model name in the SINDARIN script has to put in quotation marks, but this is not guaranteed to always work.) Then, a UFO model named, e.g., test_model is accessed by an extra ufo tag in the model assignment:

  model = test_model (ufo)

If desired, WHIZARD can access a directory of UFO files elsewhere on the file system. For instance, if FeynRules output resides in the subdirectory MyMdl of /home/users/john/ufo, WHIZARD can use the model named MyMdl as follows

  model = MyMdl (ufo ('/home/users/john/my_ufo_models'))

that is, the SINDARIN keyword ufo can take an argument. Note however, that the latter approach can backfire — in case just the working directory is packed and archived for future reference.

1

Due to a regression in WHIZARD version v2.2.0, SARAH models cannot be successfully linked within that version. Hence, the default value here has been set to version number 2.2.1

2

Those script have been published under the name SUSY Toolbox but SARAH is with version 4 no longer restricted to SUSY models

3

Note that though the main interface of FeynRules to WHIZARD is for the most recent WHIZARD release, but also the legacy branch WHIZARD1 is supported.

4

For the old WHIZARD1 legacy branch, there was a maximum number of external color flows that had to explicitly specified. Essentially, this is n₈ − 1/2n₃ where n₈ is the maximum number of external color octets and n₃ is the maximum number of external triplets and antitriplets. This can be set in the WHIZARD/FeynRules interface by the WOMaxNcf command, whose default is 4.

5

Not available in version 1.95 and earlier. Note that in order to use such couplings in 1.96/97, the O’Mega option 2g must be added to the process definition in whizard.prc.

6

As the legacy branch, WHIZARD1, does not support a running strong coupling, this is also vetoed by the interface when using WHIZARD1.x.

7

For versions 1.9x, model names must start with “fr_” if they are to be picked up by WHIZARD automatically.

8

Not available for versions older than 2.0.0

9

MaxCanonicalDimension is an option of the FeynmanRules function rather than of the interface, itself. In fact, the interface accepts all the options of FeynmanRules and simply passes them on to the latter.