PaperlayerView exact revision on arXiv

Source-linked AI summary

FeynRules 2.0 - A complete toolbox for tree-level phenomenology

Adam Alloul, Neil D. Christensen, Celine Degrande, Claude Duhr, Benjamin Fuks

arXiv:1310.1921v2hep-ph

TL;DR

Particle-physics models historically required generator-specific syntax, code modifications, and tedious vertex-by-vertex implementation. FeynRules 2.0 provides a unified Lagrangian-based Mathematica workflow with expanded physics support, interfaces, automation, and validation. The package supports a complete path from theoretical model to simulation and comparison with experiment, with improved speed and efficiency.

  • Problem

    Implementing new theoretical models across simulation tools required generator-specific syntax, code changes, and tedious hand coding of many vertices.

  • Method

    FeynRules accepts fields, parameters, symmetry groups, and a Lagrangian, computes Feynman rules, and exports complete model information through dedicated and universal interfaces.

  • Results

    FeynRules 2.0 adds broader field and superspace support, automatic mass and decay calculations, expanded interfaces, improved speed, and validation tools for taking models from theory to simulation.

  • Takeaways & Limitations

    The unified workflow makes model implementations more robust, dependable, and transferable across supported Feynman-diagram and Monte Carlo packages.

  • Takeaways & Limitations

    The web validation requires users to test that model, restriction, and parameter files load beforehand and does not provide backup or versioning for long-term storage.

Abstract

from arXiv · show

FeynRules is a Mathematica-based package which addresses the implementation of particle physics models, which are given in the form of a list of fields, parameters and a Lagrangian, into high-energy physics tools. It calculates the underlying Feynman rules and outputs them to a form appropriate for various programs such as CalcHEP, FeynArts, MadGraph, Sherpa and Whizard. Since the original version, many new features have been added: support for two-component fermions, spin-3/2 and spin-2 fields, superspace notation and calculations, automatic mass diagonalization, completely general FeynArts output, a new universal FeynRules output interface, a new Whizard interface, automatic 1 to 2 decay width calculation, improved speed and efficiency, new guidelines for validation and a new web-based validation package. With this feature set, FeynRules enables models to go from theory to simulation and comparison with experiment quickly, efficiently and accurately.

PROGRAM SUMMARY

FeynRules computes Feynman rules from four-dimensional quantum-field-theory Lagrangians and exports model interactions to multiple diagram calculators and Monte Carlo programs.

  • Program function: FeynRules computes Feynman rules directly from a model Lagrangian expressed in four-dimensional spacetime.The Lagrangian must satisfy locality, Lorentz invariance, and gauge invariance.
  • Solution method: The workflow converts fields when necessary, derives rules using canonical commutation relations, and exports the model through dedicated interfaces.The documented three-step process covers field representation, rule derivation, and implementation in FeynArts and Monte Carlo programs.
  • Scope and support: Supported fields include spin 0, 1/2, 1, 3/2, and 2, with superfields expandable into component fields for superspace computations.Superfields are supported alongside the listed particle-field spins.

1 Introduction

FeynRules 2.0 addresses the difficulty of implementing new theoretical models across simulation tools by combining a unified Lagrangian-based workflow with broader physics support, interfaces, automation, and validation.

  • 1 Introduction: New models historically required generator-specific syntax, code changes, and error-prone hand coding of hundreds or thousands of vertices.These implementation practices transferred poorly between theorists and experimentalists.
  • 1 Introduction: FeynRules lets users implement a model once in unified Mathematica syntax and enter its Lagrangian instead of individual vertices.The package computes vertices and exports files for supported event generators without requiring generator-specific syntax knowledge.
  • 1 Introduction: The updated core supports two-component Weyl fermions, automatically converting the Lagrangian to four-component fermions for matrix-element generators.This can facilitate implementation of complicated models while retaining compatibility with generators that generally use four-component fermions.
  • 1 Introduction: FeynRules 2.0 adds support for spin-3/2 fields, superspace models, and automatic extraction and numerical diagonalization of tree-level mass matrices.The spin-3/2 output was tested across three models, while the superspace module was tested on non-trivial supersymmetric models including the MSSM.
  • 1 Introduction: New interfaces extend FeynArts to non-standard Lorentz structures, provide the universal UFO format, and export models natively to Whizard, including automatic Rξ-gauge files.The Whizard output was tested across gauges and against CalcHep and MadGraph for the SM, MSSM, and 3-Site model.
  • 1 Introduction: Automated 1 →2 decay widths, core speedups, model-quality guidelines, and web-based cross-generator and cross-gauge validation broaden the package’s workflow.The validation platform generates 2 →2 processes, compares results, and flags large discrepancies for investigation.
  • 1 Introduction: The manual integrates instructions for model implementation, Lagrangian construction, Mathematica use, export interfaces, performance, and web validation.Its sections span the implementation workflow from model definition through code generation and validation.

2 The Model Description

FeynRules model files encode model metadata, fields, indices, parameters, and Lagrangians in Mathematica-compatible syntax. Users must define the relevant index types and ranges before describing indexed quantities.

  • Model files: Model implementations must be written in valid Mathematica syntax using FeynRules-specific variables and macros.Final model versions are suggested to be stored in pure text files, although notebooks can assist during development.
  • Model information: M$ModelName identifies the model, while M$Information stores an electronic signature with authors, institutions, references, version, and date.The information is printed when the model loads and can be retrieved with ModelInformation[].
  • Indices and Lagrangians: A Lagrangian is generally polynomial in fields, derivatives, and model parameters, which may carry indices associated with their components or symmetry transformations.Gauge fields can simultaneously carry Lorentz and adjoint gauge indices.
  • Indices and Lagrangians: Each model file must define the index types appearing in the model and the range of values allowed for each type.Indexed fields use expressions such as psi[index1, index2, ...], with each index represented by Index[name, value].
  • Model information: Table 1 summarizes the model-information fields used to document an implementation.The supplied passage identifies the table but does not reproduce its contents.

2.3 The model parameters

FeynRules stores model parameters in M$Parameters, separating scalar parameters from tensorial parameters according to whether they carry indices. Each parameter is declared through a label and Mathematica replacement rules describing its properties.

  • Parameter organization: All coupling constants, mixing quantities, masses, and related model inputs are implemented as elements of M$Parameters.Each element uses a user-defined label associated with a list of Mathematica replacement rules.
  • Parameter organization: FeynRules divides parameters into scalar parameters without indices and tensorial parameters carrying one or more indices.Scalar and tensorial parameter implementations are discussed separately.

2.3.1 Scalar parameters

Scalar parameters are declared with attributes controlling their numerical or formula-based values, interface metadata, notation, and physical descriptions. External parameters are independent inputs, whereas internal parameters are derived from other model quantities.

  • External and internal parameters: The strong coupling example treats αs as an experimentally determined external input and gs as an internal parameter derived from it.The example uses αs = g_s^2/(4π) as the input quantity and relates g_s through a formula.
  • Parameter attributes: Index behavior can be controlled through attributes such as NoUnfold and Unfold, while tensorial parameters may be marked Unitary, Hermitian, or Orthogonal.The latter properties default to False and encode corresponding matrix properties.
  • Index attributes: FeynRules provides predefined index types for Lorentz, Dirac-spinor, and left- and right-handed Weyl-spinor indices.These are named Lorentz, Spin, Spin1, and Spin2, with ranges 1–4, 1–4, 1–2, and 1–2 respectively.
  • Parameter values: The strong-coupling example assigns αs an external value of 0.1184 and gs the internal formula Sqrt[4 Pi aS].The example also assigns interaction orders and Les Houches metadata to the two parameters.
  • External and internal parameters: ParameterType distinguishes External from Internal parameters, whose Value is respectively a real number or a Mathematica formula.Complex external parameters must be split into separately declared real and imaginary parts.
  • Parameter values: Definitions can replace Value for specifying a parameter through a Mathematica replacement rule.A defined parameter is substituted into derived interaction vertices, while a parameter supplied through Value remains symbolically associated with the vertices.
  • Parameter attributes: Scalar-parameter attributes include interface placement, TeX notation, and a textual physical description.OrderBlock specifies an external parameter’s position in a Les Houches block, while TeX and Description control notation and meaning.

2.3.2 Tensorial parameters

FeynRules represents indexed quantities as tensorial parameters and supports their mathematical properties, explicit component values, and definitions during vertex extraction. These features help encode compact flavor and generation structures while controlling summation and zero-vertex removal.

  • Tensorial parameter declarations: Tensorial parameters carry indices declared through the Indices attribute, such as Scalar and Generation indices.Their values or definitions are lists of replacement rules covering possible index values.
  • Parameter properties: Unitary, Hermitian, and orthogonal properties can be encoded by setting the corresponding attributes to True.These attributes are especially relevant for matrix-valued parameters.
  • Example: CKM matrix: The CKM example combines indexed declarations, Unitary and ComplexParameter settings, explicit values, and definitions that set selected elements to zero.FeynRules removes the vanishing CKM vertices during interaction-vertex extraction.
  • Summation conventions: AllowSummation permits a single-index parameter to be summed together with two other indices when ordinary pairwise index contraction is insufficient.This option is available only for parameters carrying one single index.
  • Related field organization: Particle classes group particles with identical quantum-number index structures, enabling compact Lagrangian expressions and automatic antiparticle handling for non-self-conjugate fields.Spin and Lorentz indices are inferred automatically, while symmetry and flavor indices can be specified explicitly.

2.6.1 Gauge group declaration

FeynRules declares each simple factor of a simple or semi-simple gauge group independently, specifying its algebraic and field content. It also supports charge checks, inferred representations, and analytical definitions while warning that exporters may impose additional restrictions.

  • Gauge-group structure: A model gauge group is simple or semi-simple, with each simple factor defined independently in M$GaugeGroups.Each declaration associates a subgroup label with replacement rules describing that factor.
  • Group type and charges: The Abelian option distinguishes Abelian from non-Abelian groups, while Charge enables U(1) charge-conservation checks for Abelian factors.The checks assume field quantum numbers have been declared consistently.
  • Non-Abelian data: Non-Abelian declarations specify generators, structure constants, symmetric tensors, and representations, with analytical formulas supplied through Definitions.FeynRules can infer representation information from the GaugeBoson or Superfield attribute when it is not explicitly provided.
  • Export considerations: Exporter compatibility can restrict supported gauge groups and representations, so vertices may need to be fully expanded into component fields.FeynRules itself has no limitation on consistently defined representation matrices.
  • Representations: FeynRules treats a representation and its complex conjugate without distinction by representing an antifield through the conjugate field transformation.Thus an SU(3) antitriplet can be introduced as the Hermitian-conjugate field of a triplet.
  • Gauge-field associations: Gauge-group declarations identify the associated gauge boson and coupling constant through the GaugeBoson and CouplingConstant attributes.For non-Abelian symmetries, the gauge boson carries the adjoint index.

2.6.2 FeynRules functions related to gauge groups

FeynRules provides built-in functions for gauge field strengths, supersymmetric field strengths, and covariant derivatives, while restrictions and mixing declarations streamline model construction and basis changes.

  • Gauge-group functions: Gauge-group declarations automatically construct field strength tensors, superfield strength tensors, and covariant derivatives for use in Lagrangians.Covariant derivatives are accessed through DC[phi, mu], while field strengths use FS and supersymmetric field-strength functions.
  • Gauge-group functions: The field-strength functions support abelian and non-abelian gauge groups, with non-abelian expressions involving the coupling and structure constants.The abelian limit follows directly from the non-abelian definitions.
  • Model restrictions: Restriction files apply replacement rules to the Lagrangian before Feynman-rule evaluation, allowing parameters such as off-diagonal CKM elements to be removed.For a diagonal CKM restriction, applying the rules removes flavor-changing quark interactions; loaded restrictions cannot be undone without restarting the kernel.
  • Model restrictions: ZeroValues.rst removes numerically vanishing parameters and can considerably speed calculations performed with Feynman diagram generators.The file is generated for complicated benchmark models and can be loaded like other restriction files.
  • Mixing declarations: The mass-spectrum module extracts tree-level mass matrices and can pass them to ASperGe for numerical rotations into a diagonal mass basis.The module does not support kinetic mixing among gauge bosons associated with different U(1) factors.
  • Mixing declarations: Mixing declarations specify gauge and mass bases and may use numerical matrices, while analytically known matrices must instead be declared as standard model parameters.Unmixed indices, such as color indices, are preserved through the basis transformation.
  • Mixing declarations: Vacuum expectation values are supplied through M$vevs, whose pairs associate unphysical scalar fields with the symbols representing their vevs.This information supports shifting neutral scalar fields within particle-mixing handling.

3 The Lagrangian

FeynRules builds Lagrangians from fields and functions, enforces index and fermion-ordering conventions, provides consistency checks, and automates supersymmetric component-Lagrangian construction.

  • Lagrangian construction: Lagrangians are built from model fields and FeynRules or Mathematica functions, with field indices explicitly represented according to field type.Fields are accessed through their ClassName and indexed arguments.
  • Lagrangian construction: All monomial indices must be contracted and explicitly spelled out, while Mathematica Dot preserves the ordering of anticommuting fields and parameters.FeynRules can restore suppressed indices in certain fermion bilinears, but explicit indices are recommended when uncertain.
  • Lagrangian construction: Covariant derivatives and field strengths can be inserted through DC[phi, mu] and FS[G, mu, nu, a], with gauge fields and generators determined by field indices and group definitions.These functions provide gauge-invariant building blocks for implemented Lagrangians.
  • Fermion representations: WeylToDirac converts a Lagrangian written with two-component fermions into an equivalent four-component form required by most diagram calculators.The conversion combines left- and right-handed Weyl spinors into Dirac fermions.
  • Lagrangian checks: Lagrangian-manipulation functions include ExpandIndices[], which returns the Lagrangian with all indices written explicitly.Additional functions return specified parts of the Lagrangian.
  • Lagrangian checks: Consistency checks test Hermiticity, diagonal kinetic and mass terms, kinetic normalization, and agreement between computed and declared mass spectra.These checks are collected with other Lagrangian tools in the documented function tables.
  • Lagrangian checks: FeynRules does not use quadratic Lagrangian pieces, and checks for spin-3/2, spin-2, and Weyl-fermion kinetic or mass terms are not fully supported.Propagator conventions in FeynRules and event generators still assume appropriate quadratic terms.
  • Supersymmetric Lagrangians: Supersymmetric Lagrangians can be constructed from superfields, with component extraction functions selecting the required θ and θ̄ expansion terms.CSFKineticTerms supplies chiral-supermultiplet kinetic and gauge interactions, while vector-superfield terms are handled by VSFKineticTerms.

4 Running FeynRules

FeynRules is loaded into Mathematica before the model description, after which users can load models, define Lagrangians, extract Feynman rules, manipulate vertices and parameters, and perform superspace computations. Model changes generally require reloading, while Lagrangian changes do not.

  • Loading models: FeynRules is loaded before the model description, which is then imported with LoadModel or supplied directly in the notebook.Model files use the .fr extension; directly entered descriptions require LoadModel[] after all model lines are loaded.
  • Reloading models: Changing the model description requires restarting and reloading the Mathematica kernel, package, and model, although the Lagrangian may be changed without reloading model information.This restriction applies to model information rather than Lagrangian edits.
  • Extracting vertices: The FeynmanRules command derives interaction vertices from a defined Lagrangian and stores them internally as particle lists paired with analytical expressions.Vertices can be generated all at once or separately and later merged with MergeVertices.
  • Expanding indices: FlavorExpand generates separate vertices for individual flavor assignments, while Unfold forces expansion over specified indices and non-physical-state decompositions.FlavorExpansion[] can be faster because it expands after vertices are computed.
  • Controlling calculations: Selection options restrict derived vertices by particle count, canonical dimension, particle content, conserved quantum numbers, or other filters.SelectVertices provides corresponding filtering for already computed vertex lists.
  • Parameters and superspace: NumericalValue evaluates numerical parameter expressions, and predefined superspace functions support supersymmetric algebra and superderivative calculations.The package also provides superspace functionality summarized in Table 21.
  • Decay widths: The decay-width functionality is limited to two-body channels, while some external tools can compute widths on the fly and include N-body channels.The FeynRules calculation uses selected three-point vertices involving at least one massive particle and excludes ghosts and Goldstone bosons.

5 A Simple Example

The example implements a two-field complex scalar theory in FeynRules, illustrating indices, parameters, mixing, gauge-to-mass rotations, and a complete model-file workflow. The example is pedagogical and does not use every FeynRules feature.

  • Model setup: The example uses a variant of φ4 theory with two complex scalar fields interacting through a Lagrangian.The mass and coupling matrices are assumed real and symmetric.
  • Model setup: The implementation demonstrates index definitions, flavor expansions, mixing matrices, gauge-to-mass rotations, and gauge interactions.The example constructs these features incrementally to provide a starting point for new model implementations.
  • Mass diagonalization: Because the mass matrix is non-diagonal, gauge eigenstates are related to mass eigenstates by an orthogonal transformation U.The rotation matrix can be parametrized by one mixing angle, while the couplings generally retain explicit mixing dependence.
  • Mass diagonalization: General mass-matrix diagonalization may require external numerical codes or the ASperGe package.The example computes its simple case with Mathematica eigenvalue and eigenvector functions instead.
  • Model-file declarations: The model file declares the Scalar index over the range {1,2} and specifies its printed index style.Index declarations are mandatory for every index type appearing in the model.
  • Parameter declarations: Six independent external parameters define the two real symmetric matrices, while internal parameters encode mass eigenvalues, the mixing angle, and the rotation matrix.The complete model file contains nine parameters, of which six are independent.
  • Field declarations: The fields are declared separately in gauge and mass bases, with a replacement rule specifying the rotation between them.The mass eigenstate class contains Phi1 and Phi2 with internal masses M1 and M2.

6 Interfaces

FeynRules exports model Feynman rules through interfaces to several diagram generators, translating a unified model description into tool-specific files. Interface compatibility depends on each generator’s supported particles, representations, and interaction structures.

  • Available interfaces: FeynRules provides interfaces for CalcHep/CompHep, FeynArts/FormCalc, Sherpa, UFO, and Whizard/Omega.The interfaces export Feynman rules as text files specific to each supported code.
  • Available interfaces: The UFO interface stores model information abstractly as Python objects in a generic model format.UFO is described as a universal FeynRules output format.
  • Running interfaces: Interfaces are invoked with commands of the form WriteXOutput[L1,L2,..., options], with X replaced by the interface label.Each interface has its own tool-specific implementation details.
  • Compatibility limits: Interface outputs are restricted by the native support of the target generator for particle spins, color representations, and interaction forms or dimensions.A model must satisfy the constraints imposed by the chosen generator.
  • Compatibility limits: FeynRules itself is model-agnostic, whereas diagram generators may contain hard-coded Standard Model information such as running coupling constants.This difference affects how model information is interpreted during export and calculation.
  • Naming and identification: Exported names may need explicit ParameterName, ParticleName, and AntiParticleName values because calculators can be case-insensitive or reject Greek-letter names.PDG codes should also be assigned whenever possible because many programs use them internally.
  • Widths and scans: FeynRules can provide widths through internal calculations, external calculators, on-the-fly evaluation, or dedicated model-specific tools.Widths and branching fractions must be reevaluated whenever an external parameter changes because they are benchmark-dependent.
  • Interaction orders: Effective gluon-Higgs interactions can model single-Higgs gluon fusion, but reusing the vertex for double-Higgs production omits box-type contributions.The interaction-order setting limits the largest power of gNP appearing in an amplitude.

6.2 The ASperGe interface

The ASperGe interface generates a model-specific program that extracts and numerically diagonalizes tree-level mass matrices, then returns mixing matrices and physical masses in SLHA-compatible form. Its algorithm requires Hermitian matrices and imposes additional restrictions on internal parameters and Majorana mixing.

  • Purpose and workflow: ASperGe is generated from FeynRules mixing information to diagonalize the model’s tree-level mass matrices numerically.The interface can target all mass matrices or a user-selected subset.
  • Generated code: The interface first extracts mass matrices and then writes model-independent C++ matrix, parameter, SLHA-mapping, utility, and build files.It also creates model-dependent source files for diagonalization and parameter relations.
  • Numerical algorithm: ASperGe uses symmetric bi-diagonalization followed by QR reduction and therefore diagonalizes Hermitian matrices, including M†M when needed.The Hermiticity requirement is the algorithm’s stated condition for use.
  • Execution and output: The compiled program accepts an external-parameter input file and an output file, producing numerical mixing matrices and physical masses.Masses are stored in the SLHA MASS block, and complex mixing matrices are split into real and imaginary parts.
  • Compatibility limits: ASperGe requires internal parameters not to depend on particle masses or mixing matrices.This restriction is stated as necessary for correct execution.
  • Execution and output: For Majorana particles, ASperGe requires real mixing matrices, so some mass eigenvalues may be negative.The output otherwise includes input parameters, mixing matrices, and masses of physical eigenstates.
  • Execution and output: The interface can compile and execute ASperGe directly from Mathematica and load the resulting parameter values back into the kernel.The generated output is stored in out.dat before being imported.

6.3 The CalcHep/CompHep interface

The CalcHep/CompHep interface converts FeynRules Lagrangians into model files for particle definitions, parameters, functions, and interactions. It supports automatic widths, LHA parameters, selective omission of four-scalar vertices, and direct use in CalcHep or CompHep, but has constraints on color structures.

  • Output generation: WriteCHOutput generates CalcHep/CompHep model files from Lagrangian pieces, including particle, parameter, function, and interaction data.The output directory and model number are configurable.
  • Limitations: CalcHep/CompHep represent color implicitly, so general complicated vertices may require auxiliary-field decompositions that FeynRules does not fully support.Current support includes the gluon four-point vertex and a limited class of related interactions.
  • Compatibility: CalcHep and CompHep can directly use the generated model files, with CompHep selected through the CompHEP option.A model that works correctly in CalcHep also works in CompHep and gives the same physics results.
  • Options: The interface can configure automatic decay-width calculations, LHA-based external parameters, and selective removal of four-scalar interactions.Automatic widths are enabled by default, while Exclude4Scalars defaults to False.
  • Related output: FeynArts output is generated through WriteFeynArtsOutput and can be moved into the FeynArts model directory as a built-in-style model.The generated files include generic, model, and parameter components.

6.5 The Sherpa interface

The Sherpa interface exports FeynRules models into a collection of Sherpa-readable text files and supports configurable gauges and parameters. Its coverage is limited by the Lorentz and color structures and spins handled by Sherpa’s matrix-element generator.

  • Output: WriteSHOutput exports a model into Sherpa files describing particles, external and internal parameters, and interaction vertices.The output includes Particle.dat, param_card.dat, ident_card.dat, param_definition.dat, and Interactions.dat.
  • Invocation: The generated model is enabled in Sherpa through the model section of the run card or the command line.The interface provides a master switch for using the FeynRules-generated model.
  • Limitations: Sherpa supports only Lorentz and color structures already included in the Standard Model or MSSM and only fields with spin 0, 1/2, or 1.Fermion-number-violating interactions are discouraged for the Sherpa interface.
  • Model interfaces: The interface supports model input through Lagrangian pieces and can also generate UFO Python modules for linking to existing diagram calculators.UFO output stores model information in a Python module and is used by Aloha.
  • Whizard support: The Whizard interface handles spins 0, 1/2, 1, and 2, selected color representations, and unitary, Feynman, and Rξ gauges.Unsupported vertices are skipped with a warning while processing continues.

7 Running time

FeynRules 2.0 substantially improves execution speed through revised handling of lists and long expressions and through parallelization across CPU cores. Benchmarks compare FeynRules 1.6 and 2.0 for Standard Model and MSSM workflows, with interface-specific optimizations for four-scalar interactions and decay widths.

  • Performance: FeynRules 2.0 significantly improves speed over earlier versions, especially when more than one CPU core is used.The core routines were validated by comparing version 2.0 with version 1.6.
  • Parallelization: Parallel execution lets FeynRules use multiple Mathematica slave kernels, while users can restrict the number of employed CPU cores.Increasing the number of kernels requires restarting FeynRules.
  • Benchmarks: Tables 28–30 compare FeynmanRules, CalcHep, and UFO running times across FeynRules versions and one, two, four, or eight CPU cores.The MSSM benchmarks remove four-scalar interactions for the interface comparisons.
  • MSSM setup: For the MSSM interface tests, hundreds of four-scalar vertices are removed because they are generally less relevant for tree-level computations.The tests use SPS 1a parameters, with restrictions applied in the final benchmark context.
  • UFO performance: FeynRules 2.0’s UFO interface may appear less efficient than version 1.6 on one core, but the generated UFO library handles model parameters more efficiently during later matrix-element calculations.The reported gain appears in calculations with tools such as MadGraph 5.

8 Model Validation and Debugging

The paper presents model-validation guidelines and a web-based service that compares calculations across matrix-element generators and gauges. Validation can identify implementation problems, but the service remains limited in debugging support and model storage.

  • Validation rationale: FeynRules reduces faulty model implementations, but validation remains necessary because errors can arise from user input or software bugs.The authors distinguish package validation from validation of each newly implemented model.
  • Validation guidelines: Recommended checks compare literature results, Standard Model processes, independent implementations, gauges, unitarity cancellations, and several matrix-element generators.The guidelines emphasize documentation and reproducibility alongside numerical comparisons.
  • Web validation: The web validation service lets authors upload FeynRules models while generator experts run matrix-element-generator tests on the server.The service abstracts details of generator setup through a web interface.
  • Limitations: The web validation service does not support model or validation backup and versioning and should not be used for long-term storage.Backup and versioning were planned for a future version.
  • Validation results: Validation histograms compare process χ2 values with a theoretical χ2 distribution, and correctly implemented models should be at least as good as that curve.The strongest success occurs when multiple generators are compared in one gauge or gauge invariance is tested separately with one generator.
  • Debugging: Following the proposed debugging steps enables most bugs to be removed before requesting author assistance.Support requests should include a minimal reproducible case and software-version information.

9 Conclusions

FeynRules 2.0 provides a unified model format that computes Feynman rules and exports them to multiple diagram-calculation packages, making implementations more robust, dependable, and transferable. The paper also identifies automated computation of universal NLO ingredients as a future extension.

  • FeynRules accepts fields, parameters, symmetry groups, and a Lagrangian in a unified format independent of the chosen matrix element generator.Available interfaces support CalcHep/CompHep, FeynArts/FormCalc, MadGraph, Sherpa, and Whizard/Omega without modifying those packages.
  • The package computes Feynman rules and exports them in formats appropriate for multiple Feynman diagram calculators.
  • These interfaces make model implementations more robust, dependable, and transferable.
  • Future FeynRules versions are intended to compute the universal ingredients required for NLO event generation automatically from a tree-level Lagrangian.The ingredients are universal for a given model and can be computed once and for all.
Loading 1310.1921v2…