SLHA input for Vevacious

Preparing the SLHA data

To check for the global minimum in a given model for a specific parameter point all necessary numerical values of parameters have to be provided via an SLHA spectrum file. The conventions of this file have to be, of course, identical to the ones used for preparing the Vevacious model file.

The SLHA (1 and 2 ) conventions are only concerned with the MSSM and the NMSSM, but do specify that extra Block swithin the same format should be acceptable within SLHA files, and should be ignored by programs that do not recognize them. Vevacious is intended to be used for many other models, so accepts any Block sthat are mentioned in its model file and looks for them in the given SLHA file. In this sense, the user is free to define Block sas long as the names are unbroken strings of alphanumeric characters (e.g. BLOCK THISISAVALIDNAME or BLOCK MY_BLOCK_0123 [1]). However, we strongly advise against redefining those Block sspecified by and , or any of their elements, to have meanings other than those given in and .

With this in mind, two sets of pre-generated model files for the MSSM (each file within a set allowing for different scalars to have non-zero VEVs) are provided: one set being that produced by SARAH, which assumes a certain extension of the SLHA BLOCK HMIX, the other restricted to quantities completely specified by the SLHA 1 and 2 conventions. The extensions of HMIX are three additional elements: 101, providing the value of m₃² (often written as B_μ) directly, and 102 and 103 providing the values of v_d and v_u respectively. All three can be derived from elements 2, 3, and 4 of HMIX, but are much more suited to conversion between renormalization schemes and different gauges (as v_d and v_u, and thus tan β, are gauge-dependent quantities, with values which also depend on the renormalization conditions).

Scale dependence in the SLHA file

Vevacious is a tool for finding minima for a one-loop effective potential evaluated at a single scale, and thus it is important that the Lagrangian parameters are provided consistently at this scale. The scale is also required to be given explicitly. Since the SLHA convention specifies that running parameters are given in Block seach with their own scale, at first glance this may seem problematic. Even worse, the format allows for multiple instances of the same Block , each with its own scale. However, the default behaviour of SPheno, SoftSUSY, SuSpect, and ISAJET when writing SLHA output is to give all running parameters consistently at a single scale. This is the behaviour that Vevacious assumes.

The explicit value of the scale Q used in V^mass in eq. ([eq:potential_loop_corrections]) is that given by the Block GAUGE. All other Block sare assumed to be at this same scale Although it is not the default behaviour of any of the popular spectrum generators to give the same Block sat different scales, if Vevacious finds multiple instances of the same Block , the Block with the lowest scale is used and the others ignored. In addition, Vevacious performs a consistency check that all the Block sused have the same scale, aborting the calculation if not.

SLHA expression of parameters at different loop orders

The output Block senumerated in the SLHA papers are specified to be in the \overline{\mathrm{DR}}' renormalization scheme[2], but some users may prefer a different renormalization scheme. The SLHA does not insist on private Blocks adhering to the same standards of those explicitly part of the accord, so Vevacious allows for a certain pattern of private Blocks to give values for a different renormalization scheme. (Again, we strongly advise against using the Block sexplicitly mentioned in to convey values that do not adhere to the definitions in .) The additional renormalization schemes that Vevacious allows are those where the finite parts of Lagrangian parameters are themselves apportioned into loop expansions, e.g. μ + δ**μ, where δ**μ is considered to be a parameter already of at least one order higher than μ.

To allow for different renormalization conditions of this type, Vevacious first looks for extra (“private”) SLHA  Block sthat specify particular loop orders. Since Vevacious deals with one-loop effective potentials, it has two categories of parameters: “tree-level” and “one-loop”. When writing the minimization conditions for the tree-level potential, it uses exclusively the “tree-level” values. When writing the full one-loop effective potential, it uses both sets appropriately to avoid including spurious two-loop terms. With reference to eqs. ([eq:tree_level_potential]), ([eq:potential_in_parts]), and ([eq:potential_loop_corrections]), Vevacious writes combines the sum V^tree + V^counter by inserting the “one-loop” parameter values into V^tree as part of V^1-loop. (The tree-level potential function that is also written automatically for convenience, as mentioned in sec. [subsec:features], uses the “tree-level” values, of course.) The term V^mass is already a loop correction, so “tree-level” values are used in the M̄_n²(Φ)functions. If only a single value for any parameter is given, it is assumed to be in a scheme where it has a single value which is to be used in all parts of the effective potential.

As an example, within the renormalization used by SPheno, at the point SPS1a′, μ has the value 374.9 GeV at tree level, and 394.4 GeV at one loop. Vevacious inserts the value 374.9 for μ in the minimization conditions (as the units are assumed to be in , as per the SLHA standard), and also into the “mass-squared” matrices that are part of the evaluation of the V^mass contributions to the one-loop effective potential. Vevacious inserts the value 394.4 for μ in the polynomial part of the potential, accounting for the contributions of both V^tree and V^counter together.

In detail, when inserting a “tree-level” value, Vevacious looks for an SLHA Block with the prefix “TREE” first, and uses that value as its “tree-level” value. If there is no Block with that prefix, or if there is such a Block but it does not specify the appropriate element, then the Block without the prefix is assumed to have the appropriate value. Likewise, when inserting a “one-loop” value, Block swith the prefix “LOOP” have priority. Hence for the SPS1a′ example above, Vevacious could be given an SLHA file with 394.4 as element 1 of HMIX [3] and 374.9 as element 1 of TREEHMIX. When Vevacious is writing the “tree-level” value of μ, it would first look for element 1 of TREEHMIX, and since it would find 374.9, this value would be used, and element 1 of HMIX would not be looked for. When writing the “one-loop” value, element 1 of LOOPHMIX would be looked for, but not found, and because of this, element 1 of HMIX would then be looked for, and 394.4 would be found and used. One can specify element 1 of both TREEHMIX and LOOPHMIX, and then Vevacious would never use element 1 of HMIX, which could give the {\overline{\mathrm{DR}}}' value, for example, without worrying that it might mix schemes in the calculation. (If one prefers to use other prefixes, both “TREE” and “LOOP” can be replaced by other strings in the model file in the <block_prefixes> element; e.g. <block_prefixes tree=ZEROLOOP loop=ONELOOP />, so that ZEROLOOPHMIX and ONELOOPHMIX would be looked for appropriately).

Those aspects are taken into account in the SPheno  output of SARAH. For this purpose, a new flag has been introduced which can be used in the SLHA input file

Block SPhenoInput    # SPheno specific input
 ...
 530 1.       # Use Vevacious conventions

In that case, the new tree and one-loop level block will be present.

See also

[1] The SLHA papers do not specify whether Block names should be case-sensitive (so that HMIX and Hmix would be considered equivalent for example) and many spectrum generators have already adopted different case conventions for their output, so Vevacious reads in Block names as case-insensitive.

[2] The {\overline{\mathrm{DR}}}' scheme is often just called the \overline{\mathrm{DR}} scheme, however.

[3] Technically this is already an abuse of the Block , since the value entering here is not exactly the value it should have in the {\overline{\mathrm{DR}}}' scheme, but the difference is a two-loop order effect.