Question about PolynomialPart vs. TreeLevelPotential

[AWlotzka]

Hello,

I'm working in the THDM-II model and generated the THDMII.vin and the SPheno version for it via SARAH and I got three questions:
In the file VevaciousParameterDependent.py which is automatically generated, there are the two functions for the treelevel potential and the polynomial part, e.g.:

Code: Select all

def TreeLevelPotential( a, b, temperatureValue = 0.0 ):
    return ( (0.5*a**2*(2.31839565E+05))   + (0.5*b**2*(1.42151682E+05))   + (a*b*(-1.89577000E+05))   + (0.25*a**4*(1.11922872E-01))   + (0.25*b**4*(1.32757126E-01))   + (0.25*a**2*b**2*(9.06795657E-01))   + (0.25*a**2*b**2*(1.18619980E+00))   + (0.25*a**2*b**2*(-1.83080451E+00)) )

def PolynomimalPartOfPotential( a, b ):
    return ( (0.5*a**2*(0.00000000E+00))   + (0.5*b**2*(0.00000000E+00))   + (a*b*(-1.89577000E+05))   + (0.25*a**4*(1.11922872E-01))   + (0.25*b**4*(1.32757126E-01))   + (0.25*a**2*b**2*(9.06795657E-01))   + (0.25*a**2*b**2*(1.18619980E+00))   + (0.25*a**2*b**2*(-1.83080451E+00)) )

They are the same with the exception of the m11 and m22 terms (first two terms).
Question 1:Is it correct that these two terms are not part of the polynomial part, as the parameters m11 and m22 are not free but determined by the tadpole-equations directly by SPheno? (also for other models, the corresponding coefficients are set to zero.)

Question 2: In the function LoopAndThermalCorrectedPotential (file PotentialMinimizer.cpp) it looks like you return the polynomial part + Coleman Weinberg corrections + thermal corrections. Why are you using the polynomial part here instead of the treelevel potential value (i.e. the m11 and m22 terms of the potential are not in)?

Question 3 (related to 2): Is it correct, that the return value of the function LoopAndThermalCorrectedPotential is the value of the effective potential with Coleman Weinberg and thermal corrections at the given temperature and vevs?

Thanks, cheers,
Alexander

[benoleary]

Hi, Alexander.

First of all, please provide the SPheno spectrum file which has the parameters you are using. I need to check what values are defined in what blocks, because I am suspicious of some of the values in the functions you provided (m11 and m22 should not be zero in PolynomialPartOfPotential except in some very extraordinary circumstances).

Short answers, but please read further to understand the short answers:
1. No, it's not correct. Do you have some but not all values defined in TREEHMIX or TREEMSOFT? I would not expect those zeroes to be in that expression. However, there is a conceptual error in your question. The parameters m11 and m22 are not really determined by the tadpole equations. They are reverse-engineered so that the tadpole equations are solved by the VEVs which you give as input. They are parameters hypothetically describing Nature, and the VEVs are determined by the tadpole equations, and the meaning of all these numbers is very dependent on the renormalization scheme which one is using.

2. The function TreeLevelPotential is there for convenience and is not used because of the way SPheno uses its own, not-actually-DR-bar renormalization scheme.

3. Yes, LoopAndThermalCorrectedPotential returns the value of the potential evaluated fully at the 1-loop order including the thermal corrections relevant at the 1-loop order, for a given field configuration (which are only VEVs if the field configuration corresponds to a configuration which solves the 1-loop tadpole equations!) and temperature.


Further explanation:

These polynomial functions are described indirectly in Section VI.B.1 of the Vevacious manual, but it could definitely do with some clarification.

Most (all?) expressions in the literature for the potential energy function at the 1-loop order are given in the MS-bar scheme or, if for a supersymmetric theory, the DR-bar scheme. In such a scheme, the bare Lagrangian parameters are split into a renormalized parameter which is scale-dependent plus a counter-term which is divergent and incorporates a fixed finite part for convenience. The renormalized parameter is just a (scale-dependent) number and appears everywhere in loop expansions with the same value for a given scale.

There are other renormalization schemes, and the one used internally by SPheno is not quite DR-bar. For each tadpole equation solved, one of the renormalized parameters is itself split up into a perturbation series, such that the VEVs of the desired symmetry-breaking vacuum (under normal circumstances, just vd and vu) are constant at every loop order. Concretely, in normal MSSM SPheno, the parameters mu and Bmu are treated as a perturbation series of parts of successively higher loop order, so that the same values of vd and vu solve simultaneously the tree-level tadpole equations and the 1-loop tadpole equations.

VERY IMPORTANT: The values of the VEVs in the SPheno scheme remain constant across loop orders ONLY FOR A SINGLE SOLUTION OF THE TADPOLE EQUATIONS. If there is a CCB minimum with say stop VEVs vstopL and vstopR, then EVEN IN THE SPheno SCHEME, the values of vstopL and vstopR which solve the tree-level tadpoles WILL NOT solve the 1-loop tadpoles exactly. This is the reason that Vevacious has to use the tree-level extrema as starting points for a numerical minimization of the 1-loop potential even in the SPheno scheme.

In MS-bar and DR-bar, the VEVs are not constant between orders of the loop expansion.

For consistency with the internal workings of SPheno, Vevacious allows for SPheno to pass it the values SPheno uses internally, and Vevacious uses these values analogously to how they are used within SPheno: each parameter may be given as a loop expansion (e.g. muTree + muDelta), and the "loop correction" of each parameter is not used in the loop corrections to the potential, as this would give a contribution from the 2-loop level (a loop correction within a loop correction).

The MS-bar and DR-bar schemes are, as far as Vevacious is concerned, compatible with the above scheme if one just considers the expansions to be the normal MS-bar/DR-bar value as the leading term, plus a series of zeroes for the higher orders. (Note that this is just as far as Vevacious is concerned, for the purposes of evaluating the potential at the 1-loop order. These schemes are not very compatible for other calculations beyond tree level.)

Conceptually then there is V0, which is the tree-level potential as normal, evaluated just with the first term in the expansion of the Lagrangian parameters. The 1-loop corrections are the divergent part of the loop diagrams, plus the counter-terms, leaving terms of the form m^4 ln(m^2/Q^2), which we denote here as V1mass, plus finite polynomial terms of the same form as the tree-level part, which we denote here as V1poly. In the MS-bar and DR-bar schemes, V1poly is zero. In the SPheno scheme, it is not zero.

Vevacious takes the tree-level tadpoles from the .vin file generated by SARAH, and prepares them with the leading terms of the expansions of the Lagrangian parameters, yielding the tree-level tadpoles (in both MS-bar/DR-bar and the SPheno scheme). If the values for the Lagrangian parameters passed in are in the DR-bar scheme, for example, the VEVs which solve those tadpoles are to be understood as the tree-level VEVs of the DR-bar scheme, which in general will not solve the 1-loop tadpoles exactly. That's OK for Vevacious, it only uses the tree-level solutions as starting points for minimizing the 1-loop potential. If the values for the Lagrangian parameters passed in are in the SPheno scheme, then the VEVs which solve the tadpoles are to be understood as being in the SPheno scheme. Physical observables at the 1- or especially 2-loop level will NOT be the same using the VEVs from one scheme as the VEVs for another scheme. Vevacious still calculates the tunneling decay width consistently within one scheme, of course.

So, the tadpoles are the minimization conditions of V0. Within VevaciousParameterDependent.py, TreeLevelPotential is the function to evaluate V0 as well, but it is not used by default. It is there if someone wants to do a tunneling calculation only at tree level.

PolynomimalPartOfPotential is the function which evaluates the sum (V0 + V1poly). Since V1poly is zero in the DR-bar scheme, these two functions will be identical for parameter points given in the DR-bar scheme. However, in the SPheno scheme, since it mixes loop orders, it is not to be used on its own, and must be added to V1mass.


In short though, those zeroes for the a**2 and b**2 terms in PolynomimalPartOfPotential look very wrong. I suspect that the SPheno output was not correct, and there was a problem with HMIX, LOOPHMIX, and TREEHMIX.

Regards,
Ben

[AWlotzka]

Dear Ben,

thanks for your detailed answer.
First of all: Please find the .vin file and the spectrum attached.

Ok, I thought SPheno takes the 246 GeV vev, takes the tanbeta input to get v1 and v2 and then uses the tadpole equations to determine m11 and m22 - is this the same as you mean by reverse engineered?
I thought exactly what you are describing, I plan to introduce shifts to the treelevel parameters as you explain in 1307.1477 in section VI B (i.e. defining a non-zero V^counter in your manual), to have the one loop vev staying at the treelevel value (at T=0), as this is not the case if the pure Coleman Weinberg corrections are added in MSbar/DRbar (denoted V^mass in your manual). From what you write, I understand that SPheno is doing that internally, Vevacious not by default but you have to do it as described in your manual (and which I will do eventually).

Cheers,
Alexander

[FStaub]

Hi,

only briefly since I think Ben will give more details :
Vevacious takes for the one-loop potential the entries from LOOPHMIX (which are the values shifted by the one-loop tadpoles) which are zero in your spc file. The reason is most likely that loop-corrections are turned off via flag 55.
Actually, this is today the default option for that flag since most people are prefer to use tree-level masses for non-SUSY models which they want to interpret as 'pole-masses'. It's a bit a matter of taste, I would say. In many models it might work because one can define indeed a full on-shell scheme where all shifts in the masses are absorbed into redefined parameters. However, Vevacious assumes a MS or DR renormalisation. Thus, in order to use it with SPheno files one needs to do the MS/DR loop calculations with SPheno.

Cheers,
Florian

[AWlotzka]

Hi,

thanks for the fast answer, you are right, the flag was turned off in the SPheno input.
This makes it clearer now! In the first place I wanted Vevacious to simply use the treelevel values, so I should have deleted the LOOPHMIX block or I should have copied the treelevel values to it.
So couldn't one simply omit the output of LOOPHMIX when choosing the flag 55 to 0?

With flag 55 to 1, the m11 and m22 are shifted to keep the vev at the treelevel value at one loop.
So this means that to accomplish what I wanted to do manually in the previous post can also be done by simply using the loop corrections from SPheno and the generated values in the LOOPHMIX block for Vevacious?
(for certain Higgs mass values one would of course use different inputs with loop corrections than without)

Cheers,
Alexander

[benoleary]

Hi, Alexander,

OK, so the source of the odd values was that it wasn't clear that LOOPHMIX is meant to be the full value of the parameter for the purposes of 1-loop calcuations, NOT the loop correction difference on its own. (LOOPHMIX is meant to be "m11_tree + delta-m11" in a sense, not just delta-m11, if you get what I mean.)

Yes, just let SPheno print TREEHMIX and LOOPHMIX and Vevacious will use them consistently with how they are used within SPheno, which appears to be exactly what you want.

Also, yes, I know that it is common usage to say "use the VEVs to determine the Lagrangian parameters", but I worry that too many people think that the VEVs themselves are fundamental Lagrangian parameters. (Well, OK, the basis for the fundamental parameters of the Lagrangian can be re-arranged as you like, and can be cast to have some of the parameters end up as corresponding exactly to the VEVs which should describe our physical universe, but I think that there is still a conceptual difference.) Anyway, just a semantics issue which is actually unimportant.

Vevacious was built expecting to receive SPheno input usually, which is why it accepts TREEHMIX and so on. So technically it does by default do exactly as SPheno does when given SPheno input (in the TREEHMIX/LOOPHIX format, of course). If it gets standard SLHA input it assumes that the parameters in those blocks are defined as they should be by the SLHA. Despite Florian's (not irrational) misgivings, it doesn't matter so much normally: if the LOOPHMIX values are put into the loop corrections, there are spurious 2-loop contributions, but they don't affect delicate cancellations required for gauge invariance in the 1-loop potential. (The potential energy function isn't actually gauge invariant, only physical observables are, such as the energy of a minimum in the potential, the symmetries which are broken at that minimum, and the tunneling decay width between minima - but things like the potential energy evaluated at field configurations away from the minima, even though it is part of the calculation of the tunneling, are not gauge invariant, and in particular the values of the VEVs are not gauge invariant, in general.) I think that I saw differences of only a GeV or so in vd and vu when using LOOPHMIX values everywhere in some early MSSM tests.

The only renormalization thing Vevacious actually requires, I think, is that the regularization is dimensional regularization (or dimensional reduction for supersymmetry), as that affects some of the factors for vector bosons.

Regards,
Ben

[AWlotzka]

Thanks for the detailed answers and explanations!

Cheers,
Alexander