Does not finish run in the points with almost degenerate vacuua

[RobertoFranceschini]

Hello Florian,
we are running VeVacious and it nicely finds points of the parameter space when there is a minimum deeper than another one. So we find regions in which the vacuum A is deeper and another region where the vacuum B is deeper. Of course there is a transition region in which the depth of A and B are similar. It seems that in this transition region VeVacious gets stuck, so I was wondering under what circumstances (i.e. relative or absolute difference of the depths or other features of the potential barrier) VeVacious it is known to not make it to end, signaling a non conclusive calculation.

FYI we are using VeVacious version 1.1.03, if that matters.

Thanks a lot for your reply,
Roberto

[Eliel]

Dear Roberto,

It would be useful to know with a bit more detail what is going on. I don't see a priori why Vevacious should crash if the depth is very close. Could you specify which model are you using and exactly at which point Vevacious crashes? perhaps if possible you can post what is the output when it does crash.

[benoleary]

Just to add:
I've never seen HOM4PS2 get stuck.
MINUIT can somtimes go a bit crazy, but I don't think that I ever saw it get stuck in an infinite loop.
CosmoTransitions can sometimes take a *very* long time, especially with more than 6 varying fields.

If any piece of the process gets stuck, it is most likely to be CosmoTransitions. How and why CT could get stuck are things which you would have to ask the author, Dr Wainwright.

[FStaub]

Hi,

actually, I encountered sometimes the problem that Vevacious indeed get stuckes: that happens when calculating thermal corrections and when Vevacious checks for the optimal Temperature. At some point T=infinity is considered, but Vevacious still tries to increase that and never finishes because of that. Thus, if this is your problem, a first try would be to run without thermal corrections.
Another 'common' problem I had is that Vevacious tries to tunnel between minima which have actually the same depth but just because of some numerical differences it thinks that one is depper. However, in that case CT usually returns an error and doesn't get stucked. In that case, it should help to increase the numerical threshold.

If you have another problem, some more details would be indeed helpful.

Cheers,
Florian

[AugustoMedeiros]

The error we are getting is in the FindOptimalTemperature routine, as such:

Traceback (most recent call last):
File "./Vevacious.py", line 198, in <module>
dsbEvaporationTemperature )
File "/export/home/augusto/Vevacious1/bin/VevaciousParameterDependent.py", line 1616, in FindOptimalTunnelingTemperature
actionArray )
File "/opt/anaconda/lib/python2.7/site-packages/numpy/linalg/linalg.py", line 381, in solve
r = gufunc(a, b, signature=signature, extobj=extobj)
ValueError: solve1: Operand 1 has a mismatch in its core dimension 0, with gufunc signature (m,m),(m)->(m) (size 2 is different from 3)

[benoleary]

OK, well, the tunneling temperature calculation was improved by version 1.2, so please try that.

[AugustoMedeiros]

The error persisted by updating. Also, I tried adding negative direct time and deformed time flags when running to skip this step but it is still doing it - what is the correct way to skip the thermal calculations?

Thanks,
Augusto.

[benoleary]

Vevacious.exe --tunnel_thermally=False

[benoleary]

Sorry, the "timeout" variables do not do a great job - there is no easy way to interrupt CosmoTransitions in the middle of its calculation, so the timeout logic rarely can come into force, and even then only if the zero-temperature calculation timed out, in which case the non-zero temperature calculation should be skipped.