Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
SARAH SARAH
  • Project overview
    • Project overview
    • Details
    • Activity
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
Collapse sidebar
  • GOODSELL Mark
  • SARAHSARAH
  • Wiki
  • SLHA_input_for_Vevacious

Last edited by Martin Gabelmann Jun 28, 2019
Page history

SLHA_input_for_Vevacious

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 m32 (often written as Bμ) directly, and 102 and 103 providing the values of vd and vu 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 vd and vu, 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 Vmass in eq. ([eq:potentialloopcorrections]) 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:treelevelpotential]), ([eq:potentialinparts]), and ([eq:potentialloopcorrections]), Vevacious writes combines the sum Vtree + Vcounter by inserting the “one-loop” parameter values into Vtree as part of V1-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 Vmass is already a loop correction, so “tree-level” values are used in the M̄n2(Φ)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 Vmass 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 Vtree and Vcounter 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.

Clone repository

Home

Index

  • Additional terms in Lagrangian
  • Advanced usage of FlavorKit
  • Advanced usage of FlavorKit to calculate new Wilson coefficients
  • Advanced usage of FlavorKit to define new observables
  • Already defined Operators in FlavorKit
  • Already defined observables in FlavorKit
  • Auto-generated templates for particles.m and parameters.m
  • Automatic index contraction
  • Basic definitions for a non-supersymmetric model
  • Basic definitions for a supersymmetric model
  • Basic usage of FlavorKit
  • Boundary conditions in SPheno
  • CalcHep CompHep
  • Calculation of flavour and precision observables with SPheno
  • Checking the particles and parameters within Mathematica
  • Checks of implemented models
  • Conventions
  • Decay calculation with SPheno
  • Defined FlavorKit parameters
  • Definition of the properties of different eigenstates
  • Delete Particles
  • Different sets of eigenstates
  • Diphoton and digluon vertices with SPheno
  • Dirac Spinors
  • FeynArts
  • Fine-Tuning calculations with SPheno
  • Flags for SPheno Output
  • Flags in SPheno LesHouches file
  • FlavorKit
  • FlavorKit Download and Installation
  • Flavour Decomposition
  • GUT scale condition in SPheno
  • Gauge Symmetries SUSY
  • Gauge Symmetries non-SUSY
  • Gauge fixing
  • Gauge group constants
  • General information about Field Properties
  • General information about model implementations
  • Generating files with particle properties
  • Generic RGE calculation
  • Global Symmetries SUSY
  • Global Symmetries non-SUSY
  • Handling of Tadpoles with SPheno
  • Handling of non-fundamental representations
  • HiggsBounds
  • Higher dimensionsal terms in superpotential
  • Input parameters of SPheno
  • Installation
  • Installing Vevacious
  • LHCP
  • LHPC
  • LaTeX
  • Lagrangian
  • Loop Masses
  • Loop calculations
  • Loop functions
  • Low or High scale SPheno version
  • Main Commands
  • Main Model File
  • Matching to the SM in SPheno
  • MicrOmegas
  • ModelOutput
  • Model files for Monte-Carlo tools
  • Model files for other tools
  • Models with Thresholds in SPheno
  • Models with another gauge group at the SUSY scale
  • Models with several generations of Higgs doublets
  • More precise mass spectrum calculation
  • No SPheno output possible
  • Nomenclature for fields in non-supersymmetric models
  • Nomenclature for fields in supersymmetric models
  • One-Loop Self-Energies and Tadpoles
  • One-Loop Threshold Corrections in Scalar Sectors
  • Options SUSY Models
  • Options non-SUSY Models
  • Parameters.m
  • Particle Content SUSY
  • Particle Content non-SUSY
  • Particles.m
  • Phases
  • Potential
  • Presence of super-heavy particles
  • RGE Running with Mathematica
  • RGEs
  • Renormalisation procedure of SPheno
  • Rotations angles in SPheno
  • Rotations in gauge sector
  • Rotations in matter sector
  • SARAH in a Nutshell
  • SARAH wiki
  • SLHA input for Vevacious
  • SPheno
  • SPheno Higgs production
  • SPheno Output
  • SPheno and Monte-Carlo tools
  • SPheno files
  • SPheno mass calculation
  • SPheno threshold corrections
  • Setting up SPheno.m
  • Setting up Vevacious
  • Setting up the SPheno properties
  • Special fields and parameters in SARAH
  • Superpotential
  • Support of Dirac Gauginos
  • Supported Models
  • Supported gauge sectors
  • Supported global symmetries
  • Supported matter sector
  • Supported options for symmetry breaking
  • Supported particle mixing
  • Tadpole Equations
  • The renormalisation scale in SPheno
  • Tree-level calculations
  • Tree Masses
  • Two-Loop Self-Energies and Tadpoles
  • UFO
  • Usage of tadpoles equations
  • Using SPheno for two-loop masses
  • Using auxiliary parameters in SPheno
  • VEVs
  • Vertices
  • Vevacious
  • WHIZARD