input minimum changes from DSB minimum and nearly degenerate vacua

[jyotiranjan]

Dear Vevavious team,

I came across a situation where the input minimum reported by
Vevacious is not the DSB vacuum. This is happening when DSB
vacuum is almost degenerate with another close by vacuum.

I guess the stability flag reported by Vevacious may not be correct
in that case. I suspect the following line used in Vevacious class
might be responsible for that.

Code: Select all

self.dsbVacuum = self.TryToMinimize( dsbInput )

Could you please clarify the issue.

Best regards,
Jyotiranjan

[benoleary]

Hi,

unfortunately it is a consequence of an intended behavior. In short, it is to ensure consistency for the tunneling calculation.

The main problem is best explained with an example. SPheno reports a DSB at say vA = 103.4 and vb = 23.5, which is accurate in its tadpole evaluation of one-loop corrections. However, due to differences in handling higher-order terms, the 1-loop potential as evaluated within Vevacious might have a minimum at vA = 103.2 and vb = 23.6, and the potential at vA = 103.4 and vb = 23.5 might be steep enough that the tunneling calculation goes totally crazy.

Also because the user has to specify what the DSB should be (how would Vevacious know what it should be?), it might be unfeasible to require a very large number of significant figures to be entered , while some potentials might be steep enough in the vicinity that a large number of significant figures would be required for a numerically stable tunneling calculation.

I would ask you to also be sure that what you think is the real DSB position which Vevacious is not finding, is itself really a minimum. A common pitfall of not reading the manual is assuming that e.g. an MSSM minimum produced by SoftSusy using 2-loop corrections will automatically be a minimum of the 1-loop potential evaluated by Vevacious, which is in general very much not the case.

Finally, Vevacious always needs supervision by a human - if you're getting weird results, you should indeed check the numbers. This case is also worthy of deeper consideration: if the DSB is known to be very near some other degenerate vacua, is a vacuum stability calculation sensible? If it is close enough that MINUIT rolls there instead of where you want it to go, then there's probably no hope of a sensible calculation for that potential anyway. I would expect vacua separated by about a GeV or less - does that make sense, physically?

Regards,
Ben

[jyotiranjan]

Hi Ben,

Thanks a lot for your quick answer. I am using SARAH generated SPheno for the MSSM.

I have a case where v1=0,v2=0,vu= 243.46,vd=14.67 is the DSB vacuum with potential
-106297024.625 GeV^4. However, it rolls to v1=24.27,v2=-382.58,vu= 56.34,vd=4.67
with potential -372418436.201 GeV^4.

Hence, I understand that Vevacious is getting the correct DSB vacuum configuartion as
the input. At the end, it flags it as a stable vacuum with the following message.

<quantum_stability> stable </quantum_stability>
<thermal_stability> stable </thermal_stability>
<global_minimum relative_depth="-372418436.201" v1="24.0730335869" v2="-382.577130051" vd="4.66925415423" vu="56.3443716298" />
<input_minimum relative_depth="-372418436.201" v1="24.0730335869" v2="-382.577130051" vd="4.66925415423" vu="56.3443716298"/>

I hope this configuration may not be a stable configuration as tunneling is not calculated
from the DSB vacuum. Could you please specify if I am doing something wrong.

Best regards,
Jyotiranjan

[benoleary]

Hi, Jyotiranjan.

Unfortunately a lot could go wrong.

First of all, are you using a consistent level of loop order? In especially fine-tuned parts of the MSSM parameter space (and probably in other models, but we have had a lot of experience with this effect in the MSSM at least), there is no minimum with VEVs close to the desired SM-like symmetry-breaking configuration when using the tree-level potential, or even when using the one-loop potential. If you are using SPheno with its default flags, then probably it is including the dominant 2-loop corrections in the tadpole equations, and if you are in such an especially fine-tuned region of parameter space, those 2-loop corrections might make the difference between a minimum existing where you want it or not.

A big hint for such an effect is if the 2-loop corrections to the Higgs mass are very large.

Another possibility is if the stau mass is extremely low for the configuration you require, as similarly higher order loop effects might be necessary to turn a 1-loop saddle point into a 2-loop minimum.

Regards,
Ben

[Eliel]

Hi Jyotiranjan,

You can see an example of such behaviour (with 2-loop corrections being necessary for a stable DSB) in https://arxiv.org/abs/1605.02072. As Ben very well said, 2-loop corrections can be the difference between having a DSB minimum or not at all. If Vevacious goes to a point in field space you say is the DSB, it will find the closest minimum by "rolling" and call it DSB (which makes sense if one assumes the user is telling the truth). However, if the point is only a minimum when considering 2-loop corrections, it will just roll down to whatever minimum it finds. I suspect that is what is happening in your case.

Best regards,
Eliel

[jyotiranjan]

Hi Ben and Eliel,

Thanks a lot for your remarks and the reference. Is it possible that I can have a minimum both
at 1-loop and at 2-loop (which I call DSB), but still, Vevacious may assign the new minimum as
the new DSB as it calls " self.dsbVacuum = self.TryToMinimize( dsbInput )"?

The parameter point I am talking about, gives mass of h1 as 116.3 GeV (122.6 GeV) at 1-loop
(2 loop) in SPheno.

Best regards,
Jyotiranajn

[Eliel]

Hi again,

Vevacious will start at the point you tell it and numerically minimize the one-loop potential. Modulo numerical errors or pathologically very shallow potentials, it will find the closest (or one of the closer) minima. If the DSB is there at one-loop but far away from the two-loop minimum (the one you give it as an input), it might roll to a closer minimum with v1 and v2 \neq 0. My suggestion is that you try to run the point without two-loop corrections using the appropriate SPheno flag and see what happens.

Best,
E.

[jyotiranjan]

Thanks a lot Ben and Eliel. The so called DSB vacuum that I
am supplying to Vevacious assuming it to be a minimum is
not really a minimum of the full potential (1-loop at least)
with additional vevs. Hence, Vevacious is assigning the rolled
down value as the input instead of the one that I supplied.

Best regards,
Jyotiranjan

[benoleary]

I am glad that you sorted out the problem. It is unfortunate, but Vevacious cannot analyse potentials with a physicist's intuition, and cannot report if the potential doesn't seem right in the first place.

Also though, it is good that you asked, and this is the right place to come to ask such questions!

Regards,
Ben