Dear，
When we use the model file
pure_SLHA2_NMSSM_JustNormalHiggsAndSingletVevs.vin
to calculate the stability of the parameter point named spectr12.dat which is in the attachment. We find the error message (labeled as E1):
tunneling1D.PotentialError: ('Barrier height is not positive, does not exist.', 'no barrier')
And for calculating the stability of the parameter point named spectr71.dat which is also in the attachment (input.tar.gz), we find another error (labeled as E2):
tunneling1D.PotentialError: ('V(phi_metaMin) <= V(phi_absMin); tunneling cannot occur.', 'stable, not metastable')

I wonder that
(1) If the error E1 happen, is it right these parameter points are metastable and short-lived?
(2) When I commented the relative codes of E1, i.e. these codes in tunneling1D.py
if Vtop <= 0:
raise PotentialError("Barrier height is not positive, "
"does not exist.", "no barrier")
The Vevacious would run successfully and generate the result file. Is it OK to use the result in the file?
(3) About E2, does it suggest that the point is stable?

What’s more, I wonder that why most of our points could not successfully generate the result files. And I have put these files (input.tar.gz) in the attachment.

We also put the VevaciousInitialization.xml of spectr12.dat in the attachment.

P.S. (1) When I installed the LHPC package, I found the following error,
make: [lib//libLHPC.a] Error 1 (ignored)
I wonder if this is OK for running Vevacious.
(2) Sorry for my same reply in the topic ‘There is a typo in the model file in the Vevacious-1.2.1 and some other questions’, which I could not delete. But I think this is a new topic so I post it in a new post.

Best wishes and regards,
Liang

Dear Liang,

I took a quick look and ran your spectrum file with the NMSSM model files and I get the same issue. Looking closely, it seems that your "physical" minimum does not really seem to be a minimum of the potential defined by the parameters (I tried just numerically minimizing the tree-level potential in Mathematica for one of the points and it does agree with the output in Vevacious_tree-level_extrema.txt, so HOM4PS2 is doing its job). This can be seen for example in this output:

trying to minimize { { vd -> ( 18.121952075 ), vu -> ( 240.309090308 ), vS -> ( 922.576617509 ) }, TreeLevelPotentialValue -> -32268262401.2, EffectivePotentialValue -> -24263963711.5 } (T = 0.0)
rolled to { { vd -> ( 8120.1798705 ), vu -> ( 9113.6348223 ), vS -> ( 10004.0702537 ) }, TreeLevelPotentialValue -> -1.04578885607e+15, EffectivePotentialValue -> -2.3996317017e+14 }

Where you see that the "physical" minimum rolls to field values around 10 TeV. In other words, I believe the parameter point (I tried a couple and they have similar issues) is such that one needs to consider two-loop corrections in order to find the "physical" minimum.

What happens then is that the numerical minimization goes a bit crazy as it starts "rolling down" from a point nowhere near a minimum of the one-loop effective potential and just stops at some flat-ish point with very high VEVs.

The issue is that then both the "physical" minima and the minima found by HOM4PS2 "roll" down to a point in the potential with very high field values and very similar depth, thus triggering the errors you see in CosmoTransitions.

Sadly, I think Vevacious can not really tackle this problem at the time, as it would require the inclusion of two-loop corrections of the effective potential.

Dear Eliel,
Thank you for your reply.
But I have one more question. What’s the inputting parameters for the potential you choose. Is it M_su^2, M_sq^2, etc. or others? In our work, we scan for tan\beta, so vu and vd are inputting parameters for the potential.

Best wishes and regards,
Liang

Hi,

I think you have to be careful using a spectrum file of NMSSMTools with Vevacious. It does quite some things different compared to SPheno in the renormalisation of the Higgs sector, see eg. 1507.05093. We tried with the 'pure_SLHA" model file to mimic the renormalisation scheme of SoftSUSY, but this is also not identical to NMSSMTools.
In particular when you set flag MODSEL[8] to 1, there can be large effects from the leading-log calculation of higher order corrections, which is not necessarily very accurate. You could try with flag 8 set to 3 what is much closer to the scheme used by SPheno or SoftSUSY. (One should actually use always flag 3 independent of that because it's the most reliable calculation!)
If this still doesn't work, you might consider to change to a SPheno version of the NMSSM which also has some other advantages like the full two-loop corrections to the Higgs mass, see 1411.4665, and which should work smoothly together with Vevacious.

Cheers,
Florian

Dear Florian,
Thank you for your reply. And I will try as your suggestion.

Best wishes and regards,
Liang