Introducing an interface between FeynRules and WHIZARD

While Monte Carlo event generators like Whizard have become indispensable tools in studying the impact of new physics on collider observables over the last decades, the implementation of new models in such packages has remained a rather awkward and error-prone process. Recently, the FeynRules package was introduced which greatly simplifies this process by providing a single unified model format from which model implementations for many different Monte Carlo codes can be derived automatically. In this note, we present an interface which extends FeynRules to provide this functionality also for the Whizard package, thus making Whizard’s strengths and performance easily available to model builders.


Introduction
The Standard Model (SM) of particle physics provides a successful description of all experimental high-energy data to date.However, despite its success, many fundamental questions remain unanswered, such as the origin of electroweak symmetry breaking, the nature of neutrino masses, the large hierarchy between the electroweak and the Planck scales and the origins of dark matter and the cosmological constant.Attempts to address these questions have led to a wide range of new physics theories, most of them predicting new phenomena at the TeV scale.The Large Hadron Collider (LHC) at CERN is currently probing this scale and will hopefully make it possible to discover, constrain and/or exclude some of the theories beyond the Standard Model (BSM).
a e-mail: neilc@pitt.edub e-mail: claude.duhr@durham.ac.uk c e-mail: benjamin.fuks@iphc.cnrs.frd e-mail: juergen.reuter@desy.dee e-mail: christian.speckner@physik.uni-freiburg.deMonte Carlo simulations of the particle collisions to be observed at the LHC will play a key role in the exploration of the weak scale, both from the theoretical and experimental sides.While proper modelling of the strong interactions, including parton showering, fragmentation and hadronization, is essential in order to achieve a realistic description of the event distributions at the LHC, BSM signals are expected to show up predominantly in the underlying hard interaction.Therefore, a lot of effort has been put into the development of multi-purpose matrixelement and parton-level event generators such as Com-pHep/CalcHep [1,2,3], MadGraph/MadEvent [4,5,6,7,8], Sherpa [9] and Whizard [10,11], which allow, at least in principle, the generation of parton-level events for a large class of Lagrangian-based quantum field theory models.
In practice, however, the implementation of a BSM model into any of these tools can be a tedious and errorprone task.Not only might a model contain hundreds, if not thousands, of interaction vertices which need to be encoded in a format suitable for the generator in question, but in addition, each code follows its own format conventions which need to be respected.To improve this situation, a framework based on the FeynRules package [12], addressing not only the implementation but also the validation of new physics models in multi-purpose matrix-element and event generators has recently been proposed [13] and its virtue illustrated in the context of the programs CompHep/CalcHep, MadGraph/Mad-Event and Sherpa.
In this paper we present a new interface from Feyn-Rules to the event generator Whizard.It follows the same approach as the already existing interfaces, and allows to export any model implemented in FeynRules directly to Whizard, extending thus the aforementioned framework to the Whizard package.The paper is organized as follows: after giving a short overview of the Feyn-Rules and Whizard packages in Section 2, we discuss the usage, features and limitations of the new interface in Section 3. Finally, we give a few examples of using the interface in Section 4 before concluding in Section 5.The Appendix contains an exhaustive list of the interface options (Appendix A) and a selection of numerical results from the interface validation (Appendix B). 2 The Whizard and FeynRules packages

FeynRules
FeynRules is a Mathematica1 package that allows to derive Feynman rules from any perturbative quantum field theory-based Lagrangian in an automated way.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.Up to now, the public release of Feyn-Rules supports scalar, vector, fermion (Dirac, Majorana and Weyl [14]) and spin-two fields, as well as Faddeev-Popov ghosts, while recently, superfields have also been included [15].Once this information is provided, Feyn-Rules can perform basic checks on the sanity of the implementation (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, Feyn-Rules can export the interaction vertices to various matrixelement generators by means of interfaces provided by the package [13].The current public release contains interfaces to CalcHep/CompHep, FeynArts/FormCalc, GoSam [16,17], MadGraph/MadEvent (both 4 and 5), Sherpa and the newly developed interface to Whizard which we present in this note.
Since the matrix-element generators very often have color and/or Lorentz structures hardcoded, the different interfaces check whether all the vertices are compliant with the structures supported by the corresponding matrixelement generators, and discard them in the case they are not supported.The output of an interface consists of a set of files organized in a single directory which can be installed into the relevant matrix-element generator and used as any other built-in models.

Whizard
Whizard [11] is a program package for the automatic and efficient generation of unweighted parton-level events for multileg tree-level processes in both the Standard Model and a large number of BSM models.While the original version of Whizard (1.xx) was geared towards ILC physics by offering elaborate options for controlling the beam setup, the new version Whizard 2.x.x has been redesigned as a hadron collider tool vastly extending but also including the (ILC) features of version 1 (it now also includes both a k T -ordered and an analytic parton shower [18]).Although many QCD/NLO and SM background physics topics (cf.e.g.[20,14,21,19]) have been tackled using the package, its main focus lies on BSM physics and its collider phenomenology (cf.e.g.[32]).Specifically models focusing on alternative scenarios have been incorporated in Whizard and independently been tested and validated [22,24,27,28,29,30,31], where specifically also new physics effects from higher-dimensional operators have been investigated.The new interface to FeynRules described in this paper makes such studies considerably easier.
The program is not designed as a monolithic block, but instead shows a high degree of modularity including the, in principle, independent and stand-alone usable matrixelement generator O'Mega and the adaptive multi-channel Monte Carlo integrator Vamp as well as several dedicated sub-packages for lepton collider physics, all of which are contained in an easy-to-use package.This design is shown schematically in Fig. 1.Whizard has been designed such that this structure is completely transparent to the user.
For providing additional functionality like convolution with parton distributions, hadronization or support for additional event formats, Whizard can be linked against external packages like Lhapdf [36], Pythia [37] or also HepMC [38].
O'Mega: O'Mega [10] is a generator for tree-level matrix elements which generates a symbolic representation of the scattering amplitude and translates it into Fortran 90 code.As this is a computer-algebraic process which is rather similar to the workflow of an optimizing compiler, the OCaml language has been chosen for the implementation of O'Mega.
The algorithm is based on the algebraic paradigm of so-called Directed Acyclical Graphs (DAGs) which allow a re-usage of all already computed components.Inspired by the ideas of Helas [39], amplitudes are constructed by building a representation of the matrix element as a tree of one-particle irreducible wave functions (1POWs, Greens functions with all but one leg amputated) which is then translated into highly optimized Fortran 90 code to WHIZARD core user interface, steering, phase space O'Mega matrix elements VAMP Monte-Carlo integration USER process setup, cuts, analysis definitions, etc. evaluate the matrix element by numerically fusing 1POWs.This approach avoids the repeated and redundant evaluation of subdiagrams present in any Feynman diagram based approach and brings the factorial growth in complexity of the latter down to an exponential behavior.In addition, the optimized structure of the amplitudes is especially well-suited to cope with big cancellations present in theories with gauge invariances.
The algebraic O'Mega algorithm bears similarities to the numerical recursive solution of Schwinger-Dyson equations of motion implemented in the code Alpha [40].In this program, however, the evaluation proceeds fully numerically and no symbolic representation of the amplitude is constructed.
While there is no design limitation on the spin of the fields or on their interactions, O'Mega currently supports spin 0, 1  2 , 1, 3 2 and 2 fields, most dimension three and four couplings between those (in particular all dimension four gauge interactions) and a small set of higher dimension operators 2 .
Color treatment in O'Mega leverages the color flow [41,42] decomposition and currently supports fields transforming either as singlets, triplets, antitriplets or octets.Only the vertex factor belonging to a predefined flow is implemented in the model definition, and the other flows are derived by O'Mega from the SU(3) C representations of the fields.
Models are represented in O'Mega as OCaml modules which contain symbolic definitions of the fields and coupling constants, vertex lists, translation functions which map the fields onto their Lorentz / SU(3) C representations and a number of auxiliary maps which provide textual representations of the fields and constants for interfacing and code generation purposes.These modules are compiled and linked with the O'Mega framework to obtain executables which can be called to transform a process definition into Fortran code.
Vamp: Vamp [43] is a multichannel extension of the Vegas [44] algorithm.For all possible singularities in the integrand, suitable maps and integration channels are chosen which are then weighted and superimposed to build the phase space parameterization.Both grids and weights are modified in the adaption phase of the integration.
The multichannel integration algorithm is implemented as a Fortran 90 library with the task of mapping out the integrand and finding suitable parameterizations being completely delegated to the calling program (Whizard core in this case).This makes the actual Vamp library completely agnostic of the model under consideration.
Whizard core: With matrix element generation and Monte Carlo integration being outsourced into dedicated building blocks, it is the job of the program core to roll O'Mega and Vamp transparently into a package which can be operated without dealing with the components directly.
To this end, the core provides a command-line based user interface which is used to specify the process, event generation and analysis setup and to control the runs of the event generator.In addition, it is responsible for all physics pieces not covered by the other two components, most importantly phase space generation and beam (parton densities) setup.
The major task of the Whizard core is to generate the phase space and map out the integrand, for which it needs information on the model under consideration.In the legacy 1.x branch of Whizard, the core is implemented as a set of Fortran 90 modules, Perl glue for managing the code generation and Makefiles for steering the build process.New models have to be added to the build framework in order to be available to the user.
The recently published 2.x branch of Whizard supersedes the old versions and features a complete rewriting of the core as a single Fortran 2003 program, discarding the old Perl code.Models are loaded dynamically and searched for in a configurable search path, allowing the user to add new models without modifying the Whizard package itself.Moreover, the dedicated scripting language Sindarin has been introduced which steers all aspects of the simulation and which replaces the set of input files used in previous versions.
3 Implementing new models in Whizard using FeynRules

General strategy
In this Section, we describe how to implement generic BSM models into Whizard in an efficient way by means of the newly developed interface from FeynRules to Whizard.
This new interface brings the implementation of new models into Whizard in line with the approach introduced in Ref. [13], where its power to develop, implement and validate models has been demonstrated in the context of CalcHep/CompHep, MadGraph/MadEvent and Sherpa.This approach is built around FeynRules, a Mathematica package where any perturbative and local quantum field theory Lagrangian can be implemented and its Feynman rules obtained in an automated way.The interaction vertices can then be passed, together with all relevant information, to various matrix element generators through dedicated interfaces.
The new FeynRules interface to Whizard allows the user to integrate any model implemented in Feyn-Rules into the Whizard/O'Mega framework, although some technical restrictions apply and will be explained in the next section.The interface produces a set of files that contain all the particle and parameter definitions of the model together with the interaction vertices.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.

Features and restrictions of the Whizard -FeynRules interface
In this Section we describe in detail the features and restrictions of the new interface from FeynRules to Whizard.After initializing FeynRules and loading a model definition, the code can be invoked in a similar fashion as the other interfaces described in Ref. [13] in order to transform the Feynman rules obtained automatically from a Lagrangian into a set of model files ready to use with Whizard.Both the legacy branch 1.9x as well as the current 2.x series of Whizard are actively supported by the code generator.Options that can be passed to the interface are introduced only as needed, while a detailed explanation of all options can be found in Appendix A.
Supported fields and vertices: All fields currently supported by FeynRules (scalars, Dirac and Majorana fermions, vectors and symmetric tensors) are handled by the interface.The set of accepted operators, the full list of which can be found in Tab. 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.
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. 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.
In models generated for the 1.9x branch of Whizard, a hardcoded limit exists on the maximum number n cf of external color lines which is related to the number of external octets n 8 and triplets / antitriplets n 3 as This limit is set to n cf = 4 by default and can be changed via the option WOMaxNcf.No such limit applies to Whizard 2.0.0 and higher.
Running α S : Starting with version 2.0, Whizard supports a running strong coupling.While this is fully supported by the interface, a choice has to be made which quantities are to be reevaluated when the strong coupling is evolved.We choose to implement the running such that  All parity conserving dimension four operators are supported.TSS, TVV, TFF The three point couplings in the Appendix of Ref. [45] are supported.
Table 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.by default aS, G (see Ref. [12] 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.As older versions of Whizard do not evolve the strong coupling, the interface does not support running with Whizard 1.x.

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 is a tree-level tool working with helicity amplitudes, the ghost sector is irrelevant for Whizard and can be left out.Ghosts and interactions involving ghosts are dropped by the interface.

Usage
Installation and basic usage: From version 1.6.0onward, the interface is included into the official FeynRules distribution.In addition, the latest version can be downloaded from the Whizard homepage on HepForge.An installer is included which installs the interface into an existing FeynRules installation (this allows to use the program with FeynRules 1.4.xwhere it is not part of the package).
Once installed, the interface can be called and used in the same way as the other interfaces described in Ref. [12].For example, once the FeynRules environment has been initialized and a model has been loaded, the command WriteWOOutput[L] will call FeynmanRules 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 with 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 Appendix A).Instead of using a Lagrangian, it is also possible to call the interface on a 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 Ref. [12] for the other interfaces.Issuing

WriteWOExtParams[filename]
will write a list of all the external parameters to filename.The format of the output depends on the Whizard version it is targeted at: for 1.9x, it is a Fortran namelist suitable for use in whizard.in,while a Sindarin script is generated for 2.x.The target version is selected with the option WOWhizardVersion (which is the only option accepted by the command).
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.
Propagating the output to Whizard: After the interface has run successfully and written the model files to the output directory, the model must be imported into Whizard.This step depends on whether the code has been generated for the legacy 1.9x branch or for 2.x.
In the case of version 1.9x, the model files must be patched into the Whizard tree before the model can be used.For this purpose, a script called inject.sh is created in the output directory.For most applications, this step is as easy as issuing (assuming that the output directory is the current working directory) ./inject.sh/path/to/whizard (replacing the path with the correct path to the Whizard installation).After reconfiguring and recompiling Whizard, the model is available and can be used in a similar fashion as the built-in ones.The installer supports several options for more complex usage scenarios which are described in the INSTALL created in the output directory.
For the new 2.x branch, the model files are 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 issuing ./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 configure which are listed in the INSTALL file created in the output directory.

Validation of the interface
The output of the interface has been extensively validated for both the 1.9x and 2.x branches.Specifically, the integrated cross sections for all possible 2 → 2 processes in the FeynRules SM, the MSSM and the Three-Site Higgsless Model [46] have been compared between Whizard, Mad-Graph and CalcHep (for all three of which interfaces are included in FeynRules).In addition, the native versions of these models for the respective codes have also been included into the comparison 4 .For those codes which support it (CalcHep and Whizard), different gauges have been checked as well.In all comparisons, excellent agreement within the Monte Carlo errors was achieved.Several tables showcasing the results for selected processes in all three models can be found in Appendix B.

Usage examples
In order to illustrate the usage of the interface as detailed above, we will now show several examples of generating output for Whizard 2. 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 Whizard versions of other FeynRules models.

Standard Model
To start off, we will create Whizard 2 versions of the Standard Model as implemented in FeynRules for different gauge choices.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.The modified gauge is reflected in the output of the interface 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 in the previous Section by issuing (from the shell) ./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)

Minimal Supersymmetric Standard Model
In this Section, we illustrate the usage of the interface between FeynRules and Whizard in the context of the MSSM.For the conventions on the names of the particles and the relative signs entering the different terms of the Lagrangian, we refer to Refs.[13,15].All the parameters of the model are then ordered in Les Houches blocks and counters following the SUSY Les Houches Accord (SLHA) [47,48].Let us emphasize that implementing any model in FeynRules only requires a SLHA-like structure, whilst the choice of the SLHA conventions for the MSSM is only due to the author of the model implementation.
The neutralino sector deserves special attention.After diagonalization of the mass matrix expresssed in terms of the gaugino and higgsino eigenstates, the resulting mass eigenvalues may be either negative or positive.In this case, two procedures can be followed.Either the masses are rendered positive and the associated mixing matrix gets purely imaginary entries or the masses are kept signed, the mixing matrix in this case being real.According to the SLHA agreement, the second option is adopted.For a specific eigenvalue, the phase is absorbed into the definition of the relevant eigenvector, rendering the mass negative.However, Whizard does not officially support negative masses.For the case of the interface to FeynRules this means, that one must be careful using a SLHA file with explicit factors of the complex unity in the mixing matrix, and on the other hand, real and positive masses for the neutralinos.For the hard-coded SUSY models, this is completely handled internally, and the SUSY implementations in WHIZARD have been extensively tested [23,25,26,33,34,35].Especially Ref. [33] discusses the details of the neutralino (and chargino) mixing matrix.
After having downloaded the model from the Feyn-Rules website, we store it in a new directory, labelled MSSM, of the model library of the local installation of Feyn-Rules.The model can then be loaded in Mathematica as SetDirectory["<path-to-FeynRules>"]; <<FeynRules' LoadModel["Models/MSSM/MSSM.fr"];FeynmanGauge = False; As it can be seen from the last command line, we have adopted the unitarity gauge.Other choices, such as Feynman gauge, are also possible, and we refer to Section 4.1 for using the interface with other gauge choice.
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 FeynRules and Whizard.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 most optimal 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 the commands FeynmanRules and WriteWOOutput.The Feynman rules of the MSSM are then computed by issuing in the Mathematica notebook, 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 file must therefore be loaded.We choose the SPS1a5 benchmark point [49], where we take care of setting all the masses of the neutralinos to positive values and adapt the associated mixing matrix accordingly.This parameter file, named sps1a_wo.dat,can be downloaded from the FeynRules website, and loaded into FeynRules as ReadLHAFile[Input -> "sps1a_wo.dat"]; We note that 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. [50] for details).
The vertices are now ready to be exported to Whizard with the help of the command

WriteWOOutput[Input -> rules];
For compilation and usage of the produced model, we refer to Section 4.1.Finally, let us note that the numerical values of the parameters of the model can be modified directly at the level of the Whizard program, without having to generate a second time the Whizard model files from FeynRules.To this end, a Sindarin script is created by FeynRules with the help of the instruction WriteWOExtParams["parameters.sin"]; and can be further modified according to the needs of the user when employing the Whizard program.

Three-Site Higgsless Model
The Three-Site or Minimal Higgsless Model (MHM) [46] is a minimal deconstructed Higgsless model which contains only the first resonance in the tower of Kaluza-Klein modes of a Higgsless extra-dimensional model.It is a nonrenormalizable, effective theory whose gauge group is an extension of the SM with an extra SU (2) gauge group.The breaking of the extended electroweak gauge symmetry is accomplished by a set of nonlinear sigma fields which represent the effects of physics at a higher scale and make the theory nonrenormalizable.The physical vector boson spectrum contains the usual photon, W ± and Z bosons as well as a W ′± and Z ′ boson.Additionally, a new set of heavy fermions are introduced to accompany the new gauge group "site" which mix to form the physical eigenstates.This mixing is controlled by the small mixing parameter ǫ L which is adjusted to satisfy constraints from precision observables, such as the S parameter [51].
The MHM has been implemented into LanHEP [52], FeynRules [13] and independently into Whizard [53], and the collider phenomenology has been studied by making use of these implementations [52,22,53].Furthermore, the independent implementations in FeynRules and directly into Whizard have been compared and found to agree (see Appendix B).In this Section, we describe the use of the Whizard interface to generate Whizard model files for the MHM.This 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 described in Appendix A. 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 the nonlinear sigma field many higher dimensional operators are included in the model which are not supported by Whizard.Although Whizard can reject these vertices and print a warning message to the user, it is preferable to remove the vertices with the option MaxCanonicalDimension->4 which is passed to FeynmanRules and restricts the Feynman rules to those of dimension four and smaller 6 .Since the use of different gauges was already illustrated in Section 4.1, we will simply make use of this interface to output the model in Feynman gauge.We load Feyn-Rules with where <path-to-FeynRules> is the path to the Feyn-Rules files.The MHM is 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 initiated with the command 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 (see Appendix A).As in the SM (see Section 4.1), the interface begins by writing a short informational message: After calculating the Feynman rules and processing the vertices, the interface gives the 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.

Conclusions
In this paper, we presented the interface between Feyn-Rules, a program to automatically generate Feynman rules from a generic input Lagrangian, to the multi-particle event generator Whizard.The interface can be used both for the legacy version Whizard 1.xx as well as the actual release line Whizard 2.x and is included in FeynRules from version 1.6 on.There has been a quite exhaustive validation of the interface both with FeynRules models used with other Monte Carlo generators as well as with hard-coded implementations of models.We tried to keep the description of the interface rather self-contained, but recommend the user to consult both Whizard and FeynRules manuals when performing a calculation with the interface.The paper gives a complete overview of the supported particle types as well as the Lorentz and color structures of interaction vertices.We listed the options and flags which steer the compilation of physics models and the transferring of the Feynman rules into the generator.In order to give examples of the workflow, we applied it to the three models used in our validation procedure.
From the steps given in the paper to go from the Lagrangian formulation of that model through FeynRules to a simulation within Whizard, the user can easily apply the interface to his or her own preferred model.The presented FeynRules/Whizard interface hopefully facilitates phenomenological studies at present and future collider experiments.A prime example of using the combination between FeynRules and an event generator like Whizard is to investigate models whose particle content depend on the point in parameter space, which is however a separate project and will be presented elsewhere [54].

A Options of the Whizard interface
In the following we present a comprehensive list of all the options accepted by WriteWOOutput.Additionally, we note that all options of 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. 3.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.Please note that models for versions 1.9x must start with "fr " if they are to be picked up by Whizard automatically.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.

WOGaugeParameter
The external or internal parameter representing the gauge ξ in the R ξ gauges (cf.Section 3.2).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 WOMaxNcf Maximum number of color flows provided for in the output.Essentially, this is n 8 − 1 2 n 3 where n 8 is the maximum number of external color octets and n 3 is the maximum number of external triplets and antitriplets.Note that this only affects Whizard 1.9x; there is no limit for 2.0.0+.Default: 4

WORunParameters
The list of all internal parameters which will be recalculated if α S is evolved (see above

B Validation Tables
In this Appendix we summarize the validation of the interface from FeynRules to Whizard which was performed by calculating the integrated cross sections related to all possible two-to-two partonic processes in the SM, the MSSM and the Minimal Higgsless Model.We evaluated this quantity both with the FeynRules-generated model files and the built-in ("stock") implementations of the various matrix-element generators, if existing, in the framework of CalcHep, MadGraph/MadEvent and Whizard/O'mega.Where supported by both model and generator, we also checked both Feynman and unitarity gauge.We ran the codes such that the Monte Carlo uncertainty was pushed below one percent, and excellent agreement at this level was achieved in all cases.In Tab. 6 and 7 we present a selection of the results we obtained.The full list of results is available from the FeynRules website.
In order to avoid collinear divergences, we imposed a cut on the p T of each final state particle, For the MSSM, the parameter set used corresponds to the benchmark point SPS1a [49] (with the strong coupling set to α s (M z ) = 0.1172), whereas for the SM and MHM the values of the input parameters are summarized in Tab. 4 and 5.The strong coupling was evolved to √ s for each process.All particle widths were set to zero.0.00220 0.00220 0.00220 0.00220 0.00220 0.00220 0.00220 0.00220 Table 7. Cross sections for a selection of two-to-two processes in the MHM.The results for CalcHep, MadGraph /MadEvent, Whizard 1.x and Whizard 2.0 are denoted by CH, MG, WO1 and WO2, respectively.'F' and 'U' refer to the choice of the gauge in which the calculation was performed, Feyman or unitarity.The pT cuts were fixed according to Eq. ( 2), and the unit for all cross sections is pb.A trailing prime "′" at the end of a particle identifier denotes its heavy partner (cf.Ref. [46]).x and Whizard 2.0 are denoted by CH, MG, WO1 and WO2, respectively.'F' and 'U' refer to the choice of the gauge in which the calculation was performed, Feyman or unitarity.The pT cuts were fixed according to Eq. ( 2), and the unit for all cross sections is pb.The sfermions are labeled according to the SLHA2 conventions (cf.Ref. [48]).

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 2 version of the model is now as easy as doing 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.3Maximum 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.
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];

CS has been supported
by the Deutsche Forschungsgemeinschaft through the Research Training Groups GRK 1147 Theoretical Astrophysics and Particle Physics and GRK 1102 Physics of Hadron Accelerators.JRR has been partially supported by the Ministery of Science and Culture (MWK) of the German state Baden-Württemberg.BF acknowledges support by the Theory-LHC Franceinitiative of the CNRS/IN2P3.NDC was supported by the US National Science Foundation under grants PHY-0354226 and PHY-0705682 and by the PITTsburgh Particle physics, Astrophysics and Cosmology Center.CS would like to thank the Michigan State University and especially S. Chivukula and L. Simmons for their hospitality and T. Ohl for encouraging him to start this project.
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

Table 2 .
All Supported only if at least two of the octets are identical particles.881,8811Supported in output for Whizard 1.96 and higher (including the new 2.x branch) only3.3388 Supported only if the octets are identical particles.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.
As Whizard does not depend on the ghost sector, 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 Again, this line tells us that there were no problemsthe only discarded interactions involved the ghost sector which is irrelevant for Whizard.
).This only affects Whizard 2.0.0+.Default: {aS, G}WOFastIf 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.

Table 4 .
Input parameters for the SM.

Table 5 .
Input parameters for the MHM.

Table 6 .
Cross sections for a selection of two-to-two processes in the SM.The results for CalcHep, MadGraph /MadEvent, Whizard 1.x and Whizard 2.0 are labeled by CH, MG, WO1 and WO2, respectively.'F'and'U' refer to the choice of the gauge in which the calculation was performed, Feyman or unitarity.The pT cuts were fixed according to Eq. (2), and the unit for all cross sections is pb.

Table 8 .
Cross sections for a selection of two-to-two processes in the MSSM.The results for CalcHep, MadGraph /MadEvent, Whizard 1.