Vevacious error for THDMCPV generated by SARAH

[AWlotzka]

Dear Florian Staub,

when I'm running Vevacious with input file THDMCPV.vin generated by SARAH by "MakeVevacious[]", and a spectrum
file which I generated using a default input file from the SPheno version
generated by "MakeSPheno[]", I get the following error:

Code: Select all

1.142-172: syntax error
forrtl: severe (59): list-directed I/O syntax error, unit 12, file $Vevaciouspath/HOM4PS2/./bin/input.num
Image              PC                Routine            Line        Source             
flwcrv             00000000004EF041  Unknown               Unknown  Unknown
flwcrv             00000000004EE015  Unknown               Unknown  Unknown
flwcrv             000000000049853A  Unknown               Unknown  Unknown
flwcrv             0000000000470AA2  Unknown               Unknown  Unknown
flwcrv             00000000004702D1  Unknown               Unknown  Unknown
flwcrv             00000000004834AA  Unknown               Unknown  Unknown
flwcrv             0000000000481F8D  Unknown               Unknown  Unknown
flwcrv             000000000043F687  Unknown               Unknown  Unknown
flwcrv             00000000004002EC  Unknown               Unknown  Unknown
flwcrv             00000000004FCFE7  Unknown               Unknown  Unknown
flwcrv             00000000004001E9  Unknown               Unknown  Unknown

($Vevaciouspath is the correct path on my disk) Probably this is something
related to the input of HOM4PS2, but I couldn't figure out what went wrong.
Can you please help me to solve this? For other models generated by SARAH (e.g. MSSM, BLSSM) I don't have this
problem.

Thank you very much,
Alexander Wlotzka

[benoleary]

Hi, that is definitely a HOM4PS2 error.

I am not blaming HOM4PS2 per se though. I suspect that Vevacious is creating the HOM4PS2 input file incorrectly, which might have been through the .vin file having some problems.

If you send the files to me (my e-mail address is in the Vevacious README), I can have a look. I would like to see the .vin file and also the file Vevacious created for HOM4PS2, which should be somewhere in the HOM4PS2 directory, called "current_tadpoles.in". I'll try to have an answer for you by Monday. (I'm not promising a bug fix though, just an answer about what the problem probably is...)

Regards,
Ben O'Leary

[FStaub]

Hi Ben,

I just wonder if it possible at all to get HOM4PS2 running for this model without changes in Vevacious, because one of the problems seem to be the terms like

Code: Select all

2.718281828459045^((0. + 2.*I)*SLHA::HMIX[500.]

in the tadpole equations, which are actually nothing else than

Code: Select all

Exp[((-2*I)*eta)]

which show up because of the Higgs phases. Thus, it would be necessary that Vevacious inserts the values of the phases which it gets from the SLHA file and simplifies the number before writing the input for HOM4PS.

Cheers,
Florian

[benoleary]

Uh, it looks difficult. HOM4PS2 definitely will not understand exponentiating anything (except for integer powers of the variables which it is supposed to solve for) and furthermore, it looks like the tadpoles are not purely real, which again is something that HOM4PS2 would have a problem with: the real and imaginary parts of a sesquilinear constraint have to be separated into 2 real constraints.

My suggestion is that SARAH creates 2 more terms which are cos(theta) and sin(theta) rather than leaving theta itself in the potential, for the purposes of making the Vevacious file, and also that cos(theta) and sin(theta) would be printed out in the HMIX block somehow. The tadpoles in the model file need to have things like (-0.5*2.718281828459045^((0. + 1.*I)*SLHA::HMIX[500.])*v1*v2*SLHA::HMIX[22.]) written purely as (-0.5*SLHA::HMIX[index for cos(theta)]*v1*v2*SLHA::HMIX[22.]) with another tadpole for the bit involving sin(theta), if it plays a role in the tadpoles rather than actually cancelling out because of reality conditions. Also ((-0.5*v1*v2*SLHA::HMIX[22.])/2.718281828459045^((0. + 1.*I)*SLHA::HMIX[500.])) is really problematic, as not only is it constant^(SLHA "variable"), it is a division, though I guess that it's actually easy when considered to actually be 0.5 * complex conjugate of constant^(SLHA "variable") rather than 0.5 / constant^(SLHA "variable").

It wouldn't be so bad if we were using Vevacious++, as I'd put it in as a special case to interpret exponentiation in the model file, but Vevacious++ is still in alpha and may never really be ready...

Ben

[FStaub]

Hi again,

here is an idea to circumvent that problem: http://stauby.de/sarah_userforum/viewtopic.php?f=8&t=19
If you agree that this approach should work in general there wouldn't be any need to hack SARAH or Vevacious.

Cheers,
Florian

[benoleary]

Oh, yes, that should work.