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
  • Setting_up_Vevacious

Last edited by Martin Gabelmann Jun 28, 2019
Page history

Setting_up_Vevacious

Setting up Vevacious

There are many options that can be passed to Vevacious. If values other than the defaults are required, they can either be passed by command-line arguments or with an initialization file in XMLformat. If an option is given by both commmand-line argument and in an initialization file, the command-line argument takes precedence.

We enumerate the options as they would be as command-line arguments setting the options to the defaults. All floating point numbers may be given as standard decimals, such as 0.1234, or in scientific E notation, such as 1.234E-1 (uppercase ‘E’ or lowercase ‘e’, with or without preceeding ‘0’ characters, with or without ‘+’ in the exponent, e.g. 987 or 9.874E+002 or 0098.7e001 ).

  1. –hom4ps2_dir=./HOM4PS2/ This is a string giving the path to the directory where the HOM4PS2executable is.
  2. –homotopy_type=1 This is an integer used to decide which mode HOM4PS2should run in: 1 is used for polyhedral homotopy and 2 for linear homotopy.
  3. –imaginary_tolerance=0.0000001 This is a floating-point number giving the tolerance for imaginary parts of VEVsfound as solutions to the tree-level minimization conditions, since it is possible that a numerical precision error could lead to what should be an exact cancellation leaving behind a small imaginary part. It is in units of , as the other dimensionful values are assumed to be so since that is how they are in the SLHAstandard.
  4. –model_file=./MyModel.vin This is a string giving the name of the model file, including the (relative or absolute) directory path.
  5. –slha_file=./MyParameters.slha.out This is a string giving the name of the SLHA including the (relative or absolute) directory path.
  6. –result_file=./MyResult.vout This is a string giving the name of the XMLoutput file to write, including the (relative or absolute) directory path.
  7. <saddle_nudges>1.0, 5.0, 20.0</saddle_nudges> (Unfortunately this option does not work very well as a command-line argument, so instead here we display the XMLelement as it should appear in the XMLinitialization file. No initialization file has to be used, of course, if the default 1.0, 5.0, 20.0 is fine.) PyMinuitmay get stuck at saddle points, and Vevaciouscreates pairs of nearby points as new starting points for PyMinuitin an attempt to get it to roll away to minima. Using the default list shown, if Vevaciousfinds that PyMinuitstopped at a saddle point, it will create two new starting points displaced by 1.0 GeV either side of this saddle point. If PyMinuitrolls from either or both of these displaced points to new saddle points (or just does not roll as it is still in a region that is too flat), Vevaciouswill repeat the process for each new saddle point, but this time displacing the new starting points by 5.0 GeV. Vevaciouscan repeat this a third time, using 20.0 GeV, but after this gives up. Giving a longer comma-separated list of floating-point numbers will lead to Vevaciousperforming this “nudging” as many times as there are elements of the list.
  8. –max_saddle_nudges=3 This is an integer giving the length of the list of floating-point numbers of the saddle_nudges option: if it is larger than the length of the list Vevaciousalready has, the list is extended with copies of the last element; if it is shorter, the list is truncated after the given number of elements.
  9. –ct_path=./CosmoTransitions This is a string giving the path to the directory where the CosmoTransitionsfiles pathDeformation.py and tunneling1D.py are.
  10. –roll_tolerance=0.1 This is a floating-point number giving a tolerance for extrema are identified with each other, since PyMinuitmay roll to the same minimum from two different starting points, but not stop at exactly the same point numerically. If the length of the vector that is the difference of the two field configurations is less than the tolerance multiplied by the length of the longer of the two vectors that are the displacements of the two field configurations from the origin, then the two field configurations are taken to be the same minimum within errors; e.g. if A is vd = 24.42, vu = 245.0 and B is vd = 24.39, vu = 242.7, the length of A is 246.2140, the length of B is 243.9225, so the longer length is 246.2140; the length of their difference is 2.300196 which is less than 0.1 * 246.2140, so A and B are considered to be the same extremum. (This is important for avoiding attempting to calculate a tunneling time from a point back to itself.)
  11. –direct_time=0.1 This is a floating-point number giving a threshold tunneling time as a fraction of the age of the Universe for whether the metastability is decided by the upper bound from the fast CosmoTransitionscalculation taking a straight line from the false vacuum to the true vacuum. If the upper bound resulting from this calculation is below this number, the input vacuum is considered to be short-lived and no refinement in calculating the tunneling time is pursued; e.g. if it is 0.1, and the upper bound on the tunneling time is found to be 10−20 times the age of the Universe, the input vacuum is judged to be short-lived since the tunneling time is definitely below 0.1 times the age of the Universe. If the value given for direct_time is negative, this fast calculation is skipped.
  12. –deformed_time=0.1 This is a floating-point number giving a threshold tunneling time as a fraction of the age of the Universe for whether the input vacuum is consider short-lived or long-lived when the full CosmoTransitionscalculation is performed. If the tunneling time was calculated to have an upper bound above the threshold given by the direct_time option (or if the calculation of the upper bound was skipped because direct_time was given a negative value), then CosmoTransitionsis called to calculate the bounce action allowing it to deform the path in VEVspace to find the minimal bounce action. If the tunneling time calculated from this bounce action is less than the deformed_time value, the input vacuum is considered short-lived, otherwise it is reported to be long-lived. (In order to prevent overflow errors when exponentiating a potentially very large number, the bounce action is capped at 1000.) If deformed_time is set to a negative value, this calculation is skipped.

As mentioned above, an XMLinitialization file can be provided with values for these options. By default, Vevaciouslooks for ./VevaciousInitialization.xml for these options, but a different file can be specified with the command-line option –input=/example/MyVevaciousInit.xml to use /example/MyVevaciousInit.xml as the initialization file. Any other command-ine arguments take priority over options set in the initialization file.

An example XMLinitialization file called VevaciousInitialization.xml is provided with the download, which shows how to set each option.

It does not matter what the root element is called (the example file provided with the download uses <Vevacious_defaults>, but it really doesn’t matter, as long as it is closed properly). Taking the option slha_file as an example, the body of the XMLelement with the name slha_file is used as the value of the option (stripped of leading and trailing whitespace). Hence

  <slha_file>
  /path/to/Vevacious/MSSM/SPheno.spc.MSSM.SPS1ap
  </slha_file>

would serve instead of –slha_file=/path/to/Vevacious/MSSM/SPheno.spc.MSSM.SPS1ap being passed as a command-line argument. Likewise,

  <direct_time> 0.01 </direct_time>

would set the quick calculation threshold to a more conservative time of a hundredth of the age of the Universe.

See also

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