[Flexiblesusy-commits] [FlexibleSUSY/FlexibleSUSY] d9ec4c: tadpole[2] is not exactly zero due to higher order...

[GitHub]

  Branch: refs/heads/feature-complex-parameters
  Home:   https://github.com/FlexibleSUSY/FlexibleSUSY
  Commit: d9ec4c70c9baf1e2f2458f6d88e0c65396e8750b
      https://github.com/FlexibleSUSY/FlexibleSUSY/commit/d9ec4c70c9baf1e2f2458f6d88e0c65396e8750b
  Author: Alexander Voigt <Alexander.Voigt at desy.de>
  Date:   2015-04-17 (Fri, 17 Apr 2015)

  Changed paths:
    M test/test_CMSSMCPV_ewsb.cpp

  Log Message:
  -----------
  tadpole[2] is not exactly zero due to higher order effects.

tadpole[0,1,3] are fixed by the three EWSB eqs.  tadpole[2] is not
directly fixed by any EWSB eq.  However, the relation

   tadpole[2]/tadpole[3] = vu/vd           (1)

is valid, up to higher order effects.  After the iteration tadpole[2]
is not exactly zero, because during the iteration the relation (1) is
spoiled by higher order effects: During the iteration Mu and BMu pick
up tree-level and one-loop tadpole contributions.  The new values for
Mu and BMu in the next iteration step are then used to recalculate the
tree-level spectrum, which is then used to calculate the one-loop
tadpoles.  I.e. during this iterative procedure higher order
contributions are put into Mu and BMu, which leads to a violation of
(1).  For this reason, tadpole[2] is not exactly zero, even if
tadpole[3] is exactly zero.