<input_vevs> Confusion

Questions concerning the interface to Vevacious

Moderator: benoleary

loganmorrison
Posts: 1
Joined: 3. Jul 2018, 00:48

<input_vevs> Confusion

Postby loganmorrison » 3. Jul 2018, 06:56

Hey, All:

Colleagues and I are investigating one-loop effects to scalar VEVs in the THDM (with a Z_2 symmetry so that Lambda6 and Lambda7 are zero). We have a large set of parameter-space points (consisting of M_{11}^{2}, M_{22}^{2}, M_{12}^{2}, \Lambda_{1}, ..., \Lambda_{5} from https://arxiv.org/pdf/1106.0034.pdf Eqn. (98)) for which a charge breaking extrema and normal minimum exist, at tree-level. We wish to determine the one-loop effects. Namely, if one-loop effects allow the normal minimum to remain the deepest minimum. We figure that Vevacious is the best way to investigate. Right now, we are ignoring gauge boson and fermions.

I am having difficulties figuring out what the <input_vevs> does. If I put in the charge breaking extrema, I get different results than if I put in the normal extrema. For example, the SPheno file I am using is:

Code: Select all

Block MINPAR Q=  1.60000000E+02  # Input parameters
   1   3.8624972E+01   #v1
   2   1.5942701E+02   #v2
   3   7.0762566E+01   #alpha
Block GAUGE Q=  1.60000000E+02  # (Renormalization Scale)
   1   3.5912481E-01   #g1
   2   6.4500093E-01   #g1
   3   1.1769405E-01   #g1
Block HMIX Q=  1.60000000E+02  # (Renormalization Scale)
   35   -3.9958700E-01   #Lambda5
   31   6.9360059E+00   #Lambda1
   34   -1.8689667E+00   #Lambda4
   33   2.0303633E+00   #Lambda3
   32   3.8802934E-01   #Lambda2
   22   -6.9847223E+03   #M12
   20   -4.8342188E+04   #M112
   21   -1.1529163E+04   #M222


The tree-level normal minimum is located at :
    alpha 0.00000
    v1 107.03483
    v2 221.49389

The tree-level charge breaking extrema is located at :
    alpha 70.762566
    v1 38.624972
    v2 159.427010

If I set the <input_vevs> to the tree-level normal minimum, I get:
    global = {'alpha': 0.0, 'v2': 225.771957156, 'rel_depth': -194091630.339, 'v1': 108.77759553}
    input = {'alpha': 0.0, 'v2': 225.771969622, 'rel_depth': -194091630.331, 'v1': 108.777595947}

If I set the <input_vevs> to the tree-level charge breaking extremum, I get:
    global = {'alpha': 0.00111456911801, 'v2': 288.501203148, 'rel_depth': -640892745.669, 'v1': -135.597882641}
    input = {'alpha': 0.0184444018859, 'v2': 288.588504063, 'rel_depth': -640892504.23, 'v1': -135.624102169}

I would assume that Vevacious would find the same global minimum regardless of what I specify for <input_vevs>. Is this a numerical issue? If so, how can I increase the precision (currently I've set roll_tolerance=0.00000001).

Thank you.

- Logan A. Morrison

Additional notes: I run Vevacious with --should_tunnel=False since cosmotransitions often fails for me. Here are initialization file an my .vin:

initialization file

Code: Select all

<Vevacious_defaults>

<!--
#  VevaciousInitialization.xml
#
#  Created on: Oct 8, 2012
#      Author: Ben O'Leary (benjamin.oleary@gmail.com)
#      Copyright 2012 Ben O'Leary
#
#      This file is part of Vevacious, released under the
#      GNU General Public License. Please see the accompanying
#      README.Vevacious.txt file for a full list of files, brief documentation
#      on how to use these classes, and further details on the license.
#
 -->

  <!-- hom4ps2_dir is where the executable hom4ps2 is. absolute paths such as
       /home/hom4ps2/ can be used. -->
  <hom4ps2_dir>
      ~/HEP-Tools/HOM4PS2_Mac/
  </hom4ps2_dir>

  <!-- homotopy_type is 1 for polyhedral homotopy or 2 for linear homotopy.
       actually, for generic QFT potentials, linear homotopy is probably the
       faster option. -->
  <homotopy_type>
      2
  </homotopy_type>

  <!-- imaginary_tolerance is the tolerance for imaginary parts of VEVs found
       as solutions to the tree-level tadpole equations, 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
       GeV, as the other dimensionful values are assumed so since that is how
       they are in the SLHA standard. -->
  <imaginary_tolerance>
      0.00000001
  </imaginary_tolerance>

  <!-- python_wrapper is which Python wrapper for MINUIT to use. originally
       Vevacious required PyMinuit specifically, but now IMinuit can be used
       instead, which is probably preferable, as PyMinuit has been abandoned by
       its author. the choice here is either PYMINUIT or IMINUIT, but is not
       case-sensitive (e.g. iminuit or PyMinuit will also be accepted). -->
  <python_wrapper>
      IMINUIT
  </python_wrapper>

  <!-- model_file is where the loop-corrected potential stuff as written by
       SARAH is. absolute paths such as /home/vevacious/MyModel/MyModel.vin can
       be used. -->
  <model_file>
      ~/HEP-Tools/Vevacious/THDM/THDM.vin
  </model_file>

  <!-- slha_file is where the Lagrangian parameters in SLHA format are.
       absolute paths such as /home/spheno/MyModel/SPheno.spc.MyModel can be
       used. -->
  <slha_file>
     ~/HEP-Tools/Vevacious/THDM/SPheno.spc.THDM
  </slha_file>

  <!-- output is where the loop-corrected minimum, as found by PyMinuit
       starting from the HOM4PS2 extrema, should be written. absolute paths
       such as /home/vevacious/MyModel/MyResult.vout can be used. -->
  <result_file>
      ~/HEP-Tools/Vevacious/THDM/THDM_vout.xml
  </result_file>

  <!-- saddle_nudges is the comma-separated list of nudges in GeV that should
       be used to nudge PyMinuit off any saddle points where it has come to
       rest. -->
  <saddle_nudges>
      1.0, 5.0, 20.0
  </saddle_nudges>

  <!-- roll_tolerance is the tolerance for whether extrema are identified with
       each other. If roll_tolerance is for example 0.05, then extrema A and B
       are considered to be both at the same extremum within numerical errors
       if the length of the vector of VEV differences is less than 0.05 * the
       length of the longer of the 2 vectors of VEVs. 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.05 * 246.2140, so A & B are considered to be the same extremum. (This
       is important to avoid attempting calculating the tunneling time from the
       input VEVs to what should be exactly the same point, that was just not
       found exactly due to numerical issues.) -->
  <roll_tolerance>
      0.00000001
  </roll_tolerance>

  <!-- ct_path is the path to where pathDeformation.py & tunneling1D.py are
       found. absolute paths such as /home/cosmotransitions/ can be used. -->
  <ct_path>
      ~/HEP-Tools/Vevacious/CosmoTransitions-2.0.2/CosmoTransitions/
  </ct_path>

  <direct_time>
      100000000.
  </direct_time>

  <deformed_time>
      10000.
  </deformed_time>

  <!-- lifetime_threshold is the fraction of the age of the known Universe used
       as a threshold for whether a parameter point is denoted as short-lived
       or long-lived by comparison with its calculated tunneling time at zero
       temperature. The default of 0.217 (about 3 gigayears) corresponds to a
       survival probability of about 1% assuming a Poisson distribution. -->
  <lifetime_threshold>
      -1.
  </lifetime_threshold>

  <!-- thermal_survival_threshold is the fraction used as a threshold for
       whether a parameter point is denoted as having a low or high probability
       to survive thermal tunneling. -->
  <thermal_survival_threshold>
     0.99
  </thermal_survival_threshold>


</Vevacious_defaults>



.vin

Code: Select all

<Vevacious_stuff>
<input_vevs alpha="SLHA::MINPAR[3]" v1="SLHA::MINPAR[1]" v2="SLHA::MINPAR[2]">
</input_vevs>

<polynomial_part>
(0.5*alpha^2*SLHA::HMIX[20.])
  + (0.5*v1^2*SLHA::HMIX[20.])
  + (0.5*v2^2*SLHA::HMIX[21.])
  + (-1.*v1*v2*SLHA::HMIX[22.])
  + (0.125*alpha^4*SLHA::HMIX[31.])
  + (0.25*alpha^2*v1^2*SLHA::HMIX[31.])
  + (0.125*v1^4*SLHA::HMIX[31.])
  + (0.125*v2^4*SLHA::HMIX[32.])
  + (0.25*alpha^2*v2^2*SLHA::HMIX[33.])
  + (0.25*v1^2*v2^2*SLHA::HMIX[33.])
  + (0.25*v1^2*v2^2*SLHA::HMIX[34.])
  + (0.25*v1^2*v2^2*SLHA::HMIX[35.])
</polynomial_part>

<tadpoles>
{
(alpha*SLHA::HMIX[20.])
+(0.5*alpha^3*SLHA::HMIX[31.])
+(0.5*alpha*v1^2*SLHA::HMIX[31.])
+(0.5*alpha*v2^2*SLHA::HMIX[33.])
;
(v1*SLHA::HMIX[20.])
+(-1.*v2*SLHA::HMIX[22.])
+(0.5*alpha^2*v1*SLHA::HMIX[31.])
+(0.5*v1^3*SLHA::HMIX[31.])
+(0.5*v1*v2^2*SLHA::HMIX[33.])
+(0.5*v1*v2^2*SLHA::HMIX[34.])
+(0.5*v1*v2^2*SLHA::HMIX[35.])
;
(v2*SLHA::HMIX[21.])
+(-1.*v1*SLHA::HMIX[22.])
+(0.5*v2^3*SLHA::HMIX[32.])
+(0.5*alpha^2*v2*SLHA::HMIX[33.])
+(0.5*v1^2*v2*SLHA::HMIX[33.])
+(0.5*v1^2*v2*SLHA::HMIX[34.])
+(0.5*v1^2*v2*SLHA::HMIX[35.])
;
}
</tadpoles>


<mass-squared_matrix
particle="hh"  rotationmatrix="ZH"  spin="scalar" factor="1" >
(SLHA::HMIX[20.]+0.5*alpha^2*SLHA::HMIX[31.]+1.5*v1^2*SLHA::HMIX[31.]+0.5*v2^2*SLHA::HMIX[33.]+0.5*v2^2*SLHA::HMIX[34.]+0.5*v2^2*SLHA::HMIX[35.]),
(-1.*SLHA::HMIX[22.]+v1*v2*SLHA::HMIX[33.]+v1*v2*SLHA::HMIX[34.]+v1*v2*SLHA::HMIX[35.]),
(0.),
(0.),
(0.),
(alpha*v1*SLHA::HMIX[31.]),
(0.),
(0.5*alpha*v2*SLHA::HMIX[34.]+0.5*alpha*v2*SLHA::HMIX[35.]),
(-1.*SLHA::HMIX[22.]+v1*v2*SLHA::HMIX[33.]+v1*v2*SLHA::HMIX[34.]+v1*v2*SLHA::HMIX[35.]),
(SLHA::HMIX[21.]+1.5*v2^2*SLHA::HMIX[32.]+0.5*alpha^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[34.]+0.5*v1^2*SLHA::HMIX[35.]),
(0.),
(0.),
(0.),
(alpha*v2*SLHA::HMIX[33.]),
(0.),
(0.5*alpha*v1*SLHA::HMIX[34.]+0.5*alpha*v1*SLHA::HMIX[35.]),
(0.),
(0.),
(SLHA::HMIX[20.]+0.5*alpha^2*SLHA::HMIX[31.]+0.5*v1^2*SLHA::HMIX[31.]+0.5*v2^2*SLHA::HMIX[33.]+0.5*v2^2*SLHA::HMIX[34.]-0.5*v2^2*SLHA::HMIX[35.]),
(-1.*SLHA::HMIX[22.]+v1*v2*SLHA::HMIX[35.]),
(0.),
(0.),
(-0.5*alpha*v2*SLHA::HMIX[34.]+0.5*alpha*v2*SLHA::HMIX[35.]),
(0.),
(0.),
(0.),
(-1.*SLHA::HMIX[22.]+v1*v2*SLHA::HMIX[35.]),
(SLHA::HMIX[21.]+0.5*v2^2*SLHA::HMIX[32.]+0.5*alpha^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[34.]-0.5*v1^2*SLHA::HMIX[35.]),
(0.),
(0.),
(0.5*alpha*v1*SLHA::HMIX[34.]-0.5*alpha*v1*SLHA::HMIX[35.]),
(0.),
(0.),
(0.),
(0.),
(0.),
(SLHA::HMIX[20.]+0.5*alpha^2*SLHA::HMIX[31.]+0.5*v1^2*SLHA::HMIX[31.]+0.5*v2^2*SLHA::HMIX[33.]),
(0.),
(-1.*SLHA::HMIX[22.]+0.5*v1*v2*SLHA::HMIX[34.]+0.5*v1*v2*SLHA::HMIX[35.]),
(0.),
(alpha*v1*SLHA::HMIX[31.]),
(alpha*v2*SLHA::HMIX[33.]),
(0.),
(0.),
(0.),
(SLHA::HMIX[20.]+1.5*alpha^2*SLHA::HMIX[31.]+0.5*v1^2*SLHA::HMIX[31.]+0.5*v2^2*SLHA::HMIX[33.]),
(0.),
(-1.*SLHA::HMIX[22.]+0.5*v1*v2*SLHA::HMIX[34.]+0.5*v1*v2*SLHA::HMIX[35.]),
(0.),
(0.),
(-0.5*alpha*v2*SLHA::HMIX[34.]+0.5*alpha*v2*SLHA::HMIX[35.]),
(0.5*alpha*v1*SLHA::HMIX[34.]-0.5*alpha*v1*SLHA::HMIX[35.]),
(-1.*SLHA::HMIX[22.]+0.5*v1*v2*SLHA::HMIX[34.]+0.5*v1*v2*SLHA::HMIX[35.]),
(0.),
(SLHA::HMIX[21.]+0.5*v2^2*SLHA::HMIX[32.]+0.5*alpha^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[33.]+0.5*alpha^2*SLHA::HMIX[34.]-0.5*alpha^2*SLHA::HMIX[35.]),
(0.),
(0.5*alpha*v2*SLHA::HMIX[34.]+0.5*alpha*v2*SLHA::HMIX[35.]),
(0.5*alpha*v1*SLHA::HMIX[34.]+0.5*alpha*v1*SLHA::HMIX[35.]),
(0.),
(0.),
(0.),
(-1.*SLHA::HMIX[22.]+0.5*v1*v2*SLHA::HMIX[34.]+0.5*v1*v2*SLHA::HMIX[35.]),
(0.),
(SLHA::HMIX[21.]+0.5*v2^2*SLHA::HMIX[32.]+0.5*alpha^2*SLHA::HMIX[33.]+0.5*v1^2*SLHA::HMIX[33.]+0.5*alpha^2*SLHA::HMIX[34.]+0.5*alpha^2*SLHA::HMIX[35.])
</mass-squared_matrix>

benoleary
Posts: 42
Joined: 3. May 2016, 10:49

Re: <input_vevs> Confusion

Postby benoleary » 3. Jul 2018, 15:17

Crap, I just lost a long explanation because the forum logged me out.

1) You are right, the <input_vevs> should not have an influence on what is determined to be the global minimum, with the exception that if there are multiple solutions which just differ in some signs of some VEVs, it is possible that different runs choose different sign combinations as the global minimum.

2) Your potential looks like it has several sign-flipped possibilities.

3) Check the file where the tree-level solutions are recorded, and check that the expected neutral and charge-breaking vacua are present, and that the calculated depths are in line with expectations about which is lower than which.

4) Check the file where the one-loop-level solutions are recorded, and check for sign-flipped (though with some numerical noise) duplicates, and get an idea of how much variance there is in the depths of the minima.

5) Read the output from the execution of Vevacious: if MINUIT has numerical problems, it will be printed, along with all the annoying junk which I was never able to turn off which just numbs users so much that nobody pays any attention to anything printed on the screen eventually.

Feel free to send the files and the console output to me by e-mail (the Gmail address in the Vevacious README) if you need more help.


Return to “Vevacious”

Who is online

Users browsing this forum: No registered users and 1 guest