New Features in FeynArts & Friends, and how they got used in FeynHiggs

TL;DR

This paper discusses recent updates to FeynArts, FormCalc, and LoopTools, and demonstrates how these new features were utilized in the development of the latest FeynHiggs version.

Contribution

It introduces new features in FeynArts, FormCalc, and LoopTools and shows their application in improving FeynHiggs.

Findings

Enhanced capabilities in FeynArts, FormCalc, and LoopTools.

Successful integration of new features into FeynHiggs.

Improved accuracy or efficiency in FeynHiggs computations.

Abstract

This note gives an update on recent developments in FeynArts, FormCalc, and LoopTools, and shows how the new features were used in making the latest version of FeynHiggs.

Full text

1 Introduction

The FeynArts [3], FormCalc & LoopTools [4] triad of packages are used for the generation and calculation of Feynman diagrams up to one loop. With QCD and Standard Model calculations moving to higher orders their main focus has shifted somewhat to BSM models and package building, where the availability of analytical results in conjunction with a toolkit of functions and options in Mathematica, rather than a monolithic program, has proven very useful in implementing non-standard tasks like special approximations, extraction of coefficients, or nontrivial renormalizations [5].

FormCalc’s code generator has been used a lot for package building, for FeynHiggs [6] as described in more detail in the following but also e.g. in SARAH [7] and SloopS [8].

The remainder of this note starts with a overview of the code structure of FeynHiggs, discusses improvements made to the generated parts, and then describes the new functions and options which were added to FeynArts and FormCalc to achieve this.

2 FeynHiggs Code Structure

FeynHiggs est omnis divisa in partes tres.

Code hand-written for FeynHiggs

The ‘back bone’ of FeynHiggs is of course written by hand. This includes all structural code, utility functions, and the contributions taken from literature. 2. 2.

Code generated from external expressions

In several cases analytical expressions are available from external sources, usually in Mathematica format, from which parts of the FeynHiggs code are generated. Examples are the two-loop Higgs self-energies, some EFT ingredients, the muon $g_{\mu}{-}2$, or the two-loop parts of $\Delta r$.

This is an improvement over hand-coded expressions since small changes can easily be applied, and the code can be optimized and re-generated as necessary. 3. 3.

Code generated from calculations done in/for FeynHiggs

Full control over model content, particle selection, renormalization prescription, resummations, etc. is achieved in the calculations done for and included in FeynHiggs, in the gen subdirectory. Complete, model-independent automatization, sometimes dubbed the ‘generator generator’ approach, is not intended as the produced code still needs to be embedded in and called from the main program, in which the inputs have to be properly adjusted.

3 Improvements in FeynHiggs Code Generation

The unrenormalized one-loop Higgs self-energies have been generated with a high degree of automatization since FeynHiggs 2.0. Before version 2.14, however, the entire renormalization was hard-coded.

The new procedure instead reads the renormalization (counter-terms plus renormalization constants) from the model file [9]. It knows about a few flags governing the renormalization, such as $MHpInput, which selects whether$M_{A}$or$M_{H^{+}}$is the input mass for the Higgs sector, but otherwise makes as few model assumptions as possible. All renormalized self-energies are split into parts ($t/\tilde{t}$;$t/\tilde{t}$+$b/\tilde{b}$; all$f/\tilde{f}$; all) to preserve the possibility to look at individual sectors only, though this is mostly done for comparison and debugging today.

To achieve the desired level of automation, several of FormCalc’s code-generation functions had to be enhanced or added.

4 Enhanced and New FormCalc Functions

4.1 Declarations and Code in One File

A generated file containing both declarations and code cannot straightforwardly be included in a language like Fortran, which requires the strict order “declarations before code.”

This is addressed through the new $\texttt{DeclIf}\to\mathit{var}$ option of FormCalc’s WriteExpr, which inserts preprocessor statements as follows:

#ifndef $\mathit{var}$ #define $\mathit{var}$ (declarations) #else (code) #endif

The $\mathit{var}$ argument must be a variable name acceptable to the preprocessor but has no purpose beyond that. The file thus created can be included twice, once in the declarations section and once in the code section.

4.2 Temporary Variables

FormCalc’s code generator has already in the past had the notion of ‘temporary variables’ which would typically be introduced through optimization, i.e. when duplicate code was detected it was computed once and stored in a temporary variable.

Temporary variables can now also be added by the user explicitly, through the MakeTmp option of PrepareExpr. Its argument is a function which is applied to the input expressions and may insert any number of variable definitions ($\mathit{var}\to\mathit{value}$) into the list.

Usually the new function ToVars[$\mathit{patt}$, $\mathit{name}$][$\mathit{exprlist}$] is used with MakeTmp, which puts subexpressions that match the pattern $\mathit{patt}$ into variables that begin with $\mathit{name}$. Example:

WriteExpr[$\mathit{expr}$, MakeTmp $\to$ ToVars[LoopIntegrals, Head]]

The second argument Head means to take the head of the abbreviated expression for the variable name, which in the case of loop integrals might result in names like C0i7, D0i3, etc.

The advantages are twofold: Firstly the effect of optimization can be enhanced, say if a loop integral that does not depend on an index is abbreviated from a larger expression that does, then the loop integral can be hoisted outside the loop over the index.

Secondly, the abbreviated variables can be inspected at run-time using the debugging apparatus for generated code (DebugLines, $DebugCmd).

4.3 Improved Abbreviations

Also the abbreviations introduced through Abbreviate have been improved. The function Abbreviate still works in two modes:

Abbreviate[$\mathit{expr}$, $\mathit{level}$] Abbreviate[$\mathit{expr}$, $\mathit{func}$]

where the $\mathit{level}$ (integer) specification [unchanged] means to introduce abbreviations below that level in the expression tree.

The $\mathit{func}$ (function) mode also traverses the expression tree but for every subexpression ‘asks’ $\mathit{func}$ whether an abbreviation should be introduced. Allowed responses were True and False so far; it can now also be an expression, usually a part of its argument, for which the abbreviation will then be introduced. For example, a numerical prefactor can be stripped off to avoid having many abbreviations that differ only by a number.

Secondly, the list of abbreviations returned with Abbr and Subexpr now has proper patterns on the left-hand sides. Outwardly the effect seems rather minuscule, e.g.

(old) Sub333[Gen5] $\to$ A0[Mf2[2,Gen5]] - ... (new) Sub333[Gen5_] $\to$ A0[Mf2[2,Gen5]] - ...

but while the old version was in general good only for write-out to a Fortran program, the new version can actually be used to substitute Mathematica expressions.

4.4 Finding Dependencies

The new FormCalc function FindDeps[$\mathit{list}$, $\mathit{patt}$] finds all variables in $\mathit{list}$ whose r.h.s. directly or indirectly depends on $\mathit{patt}$.

Example: FindDeps[{a $\to$ x, b $\to$ 2, c $\to$ 3 + a, d $\to$ b + c}, x] gives {a, c, d}.

4.5 Named Array Indices

A special treatment of named array indices may not seem necessary since Mathematica can itself deal with ‘indices’ of any type. For the automated generation of declarations the array dimensions must be known, however, and they cannot be inferred from named indices.

The new FormCalc function Enum associates labels with numbers and works similarly to the C enum keyword. ClearEnum removes all such associations again. Label definitions are used for dimension computations only, never actually substituted in expressions.

Example: Enum["h0h0", "HHHH" $\to$ 3, "h0HH"] respectively associates the strings h0h0, HHHH, and h0HH with array indices 1, 3, and 4.

4.6 Persistent Names for Generic Objects

FeynArts’ Generic amplitudes contain objects not representable in FORM (or later on in Fortran), such as G[$\mathit{s}$][$\mathit{cto}$][$\mathit{fi}$][$\mathit{kin}$] for a generic coupling. CalcFeynAmp must replace them by simple names before the computation can commence.

In former versions numbered symbols were used, e.g. Coupling5, which were of course not persistent beyond one FormCalc session. This was never a problem with computations at deeper levels, where the generic identifiers got substituted by their actual values even before CalcFeynAmp returned.

To make the Generic amplitude useful by itself a portable name-mangling scheme has now been implemented. This allows to produce Generic ‘building blocks’ for applications, though at the price of rather unwieldy symbol names like GV1VbtVbbg12Kp3g23Pq1g13kQ2.

4.7 Propagator-dependent Masses and Vertices

FeynArts can now distinguish masses and couplings for different propagator types. A particle can have different masses inside and outside of a loop, for example. The change in syntax is such that existing model files are not affected.

In the particle list M$ClassesDescription a loop-level mass would be declared as e.g.

S[1] == {..., Mass $\to$ MHtree, Mass[Loop] $\to$ MH, ...}

The couplings in M$CouplingMatrices can similarly be extended as e.g.  C[S[1,t1], S[2,t2], S[2,t3]] ==$\mathit{coupling}$

except that in this case the t1,2,3 on the left must be placeholders (symbols), not literals as ‘Loop’, and may appear in the $\mathit{coupling}$ function on the r.h.s., e.g. in an If-statement.

4.8 Changes for Mixing Fields

Mixing fields propagate as themselves but couple as their left and right partners. A classic example is the $G^{0}$–$Z$ and $G^{\pm}$–$W^{\pm}$ mixing in the Standard Model in a non-Feynman gauge.

Reversed mixing fields used to be represented in FeynArts as Rev[$\mathit{g}$,$\mathit{g^{\prime}}$] at Generic level, but as 2 Mix[$\mathit{g}$,$\mathit{g^{\prime}}$] at Classes level. This lead to inconsistencies (too many/few diagrams) so that now the reversed field is represented by Rev[$\mathit{g}$,$\mathit{g^{\prime}}$] also at Classes level.

Unfortunately this change does affect existing model files, though mixing fields are not a very commonly implemented feature.

5 Mixed Precision in One Code

The numerical stability of FeynHiggs is generally satisfactory but e.g. the non-degenerate two-loop EFT threshold corrections exhibit numerical artifacts even in not-too-extreme scenarios.

All-out quadruple precision has been available for long (./configure --quad) but is much slower than double precision. For everyday use higher precision must be restricted to critical parts. A simple solution portable across all major Fortran compilers turned out to be a ‘poor man’s template programming’ using the preprocessor. The relevant part of types.h reads

#ifdef QuadPrec

define RealSize 16

define ComplexSize 32

define RealSuffix Q

#else

define RealSize 8

define ComplexSize 16

define RealSuffix D

#endif #define RealQuad realRealSize #define ComplexQuad complexComplexSize #define _id(s) s #define _R(s) _id(s)RealSuffix #define N(n) _id(n)id()RealSize

Three aspects are addressed here:

• •

extended real and complex types (Real,ComplexQuad),

• •

treatment of number literals (N(1.234)), and

• •

name mangling for routines needed in more than one precision (_R(routine)).

Code outfitted with these macros can be switched from double to quadruple precision by just defining QuadPrec. The increase in the overall runtime due to the extra precision required by a handful of routines was in the end hardly noticeable.

6 Evaluation of generic Mathematica Expressions in FORM

Sending Mathematica expressions to FORM for fast evaluation is one of the central principles of FormCalc, hence the name. Beyond the speed aspect there is also a curious complementarity of instruction sets which makes some operations vastly simpler in FORM (and conversely others in Mathematica), for example removing terms higher than a certain power in an expansion is done in FORM with a mere declaration.

FormCalc’s interfacing code is now available in a separate package, FormRun, available from the FormCalc Web page. It implements a function of the same name used as

FormRun[$\mathit{exprlist}$, $\mathit{decl}$, $\mathit{cmd}$]

This sends $\mathit{exprlist}$ to FORM for evaluation, with $\mathit{decl}$ extra declarations and $\mathit{cmd}$ FORM commands to be executed. Both $\mathit{decl}$ and $\mathit{cmd}$ are optional. Variables for which no specific declaration is given are symbols in FORM. There is no protection against expressions FORM cannot represent (e.g. h[1][2]).

The input $\mathit{exprlist}$ can be just a single, unnamed expression, but the output will always be a list of expressions, simply because the FORM output may contain more than one expression. Vector and matrix expressions are returned element-wise, e.g. M $\to$ $\mathit{(matrix)}$ comes back as a list of expressions M11, M12, etc. An unnamed expression comes back as expr.

7 Summary

This note describes many small functions and additions to FeynArts, FormCalc & LoopTools, mostly triggered by FeynHiggs development. Together they yield significant improvements, in particular in code generation.