|
|
---
|
|
|
title: SLHA input for Vevacious
|
|
|
permalink: /SLHA_input_for_Vevacious/
|
|
|
---
|
|
|
# SLHA input for Vevacious
|
|
|
|
|
|
Preparing the SLHA data
|
|
|
-----------------------
|
... | ... | @@ -26,7 +23,7 @@ To allow for different renormalization conditions of this type, Vevacious first |
|
|
|
|
|
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*<sup>mass</sup> 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*<sup>tree</sup> and *V*<sup>counter</sup> 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).
|
|
|
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
|
|
|
|
... | ... | @@ -41,6 +38,6 @@ 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.
|
|
|
[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. |
|
|
\ No newline at end of file |
|
|
[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. |
|
|
\ No newline at end of file |