Problems in recognizing a new parameter

[felipeagf]

Hello Florian

Starting from model directory UMSSM of SARAH/Models, I put a new parameter called "ThetaE6" in the model file with its definition in the parameters.m file and its input value in SPheno.m file. When I started this new model in SARAH it worked well and when I runned the command MakeSPheno [] in SARAH it finally also worked.
However, after copying the SPheno module created by SARAH to the main Model directory of this model in SPheno, I had troubles when running the command "make Model=UMSSM". The output of this operation shows some error messages saying that some Symbols located in the file "RGEs_UMSSM.f90" created by SARAH with my new parameter has no IMPLICIT type. What does it mean when SPheno says that a symbol has no IMPLICIT type?

I attached here these error messages and the files related to them so that you can clearly see the problem. You can see both the original file RGEs_UMSSM.f90'.m related to the original model and the other RGEs_UMSSM.f90.m file that includes my new parameter to compare them easily if necessary.

What do you recommend me to do to solve this problem?



Thank you very much.
Best regards



Cheers
Felipe

[FStaub]

Hi,

the problem is that only U(1) charges are expected which are real numbers, but not functions. Therefore, the more convenient way to do what you want is to keep the symbols Qq, Ql, QHd,... as in the standard model file, and calculate these charges once in SPheno via the boundary conditions.

Code: Select all

BoundarySUSYScale = {
...
{Qq,-1/Sqrt[40]*Cos[ThetaE6]+1/Sqrt[24]*Sin[ThetaE6]},
{Ql,...},
...
};

(As you can see, I also wouldn't use \[Theta] for something what should go to SPheno; the safest choice are always pure Strings)

That should also result in a much faster code.

Cheers,
Florian

[felipeagf]

Hi Florian

Thank you very much for your explanation. Now I am using the symbols Qq, Ql, QHd,... to define the extra U(1) charges as in the standard model file and I wrote the expressions of the charges in the SPheno.m file so that they can be calculated via the boundary SUSY Scale conditions. However, when I run the command MakeSPheno[] in SARAH it begins working well, but when it arrives at the part of calculating two-loop mass corrections it fails. When this operation ends, the Output directory does not contain the Two-loop subdirectory with as usual and the Output/MODEL/EWSB/SPheno directory is almost empty containing only the following files: Couplings_UMSSM.f90, LoopCouplings_UMSSM.f90, RGEs_UMSSM.f90 and TreeLevelMasses_UMSSM.f90. This is weird because I just changed a little bit the SPheno.m file of my model following your explanations and this problem did not happen when I did this same operation with the model files that I attached here in the last question where the expressions of the charges were defined in the main model file and when I used \[Theta]E6 in the SPheno.m file. What's wrong with SPheno in this case?

Attached here are all the model files that I used and also a picture of the screen showing the error messages in SARAH so that you can clearly see what causes this problem.




Cheers
Felipe

[FStaub]

Hi,

good question; I have no idea what goes on. It seems to be that you are forbidden to create new files in your output directory. Are you running out of quota, maybe?

Cheers,
Florian

[felipeagf]

Hi Florian

Yes, you are right. It is not a problem of SARAH as this operation worked when I did it in my Laptop. It seems to be only a problem of my University account. I will see how to solve this problem.

And, to help you to improve SARAH, I inform you that the SPheno.m file of the model UMSSM already included in SARAH seems to have an incorrect distribution of the DefaultInputValues of the extra charges as the values written there are included in the case where sin[ThetaE6]=1 but some of the charges have wrong sign. And also I found a little error in the particles.m file of this model in the lines 140 and 142 where the field sigmaS which describes the CP-odd part of the scalar singlet S is written as ¨Scalar Singlet¨ and the field phiS which describes the CP-even part of the scalar singlet S is written as "Pseudo Scalar Singlet". I am informing you these problems so that they will not appear in the next updated version of SARAH.

Best regards

Cheers
Felipe

[felipeagf]

Hi Florian

Thanks you very much for all your replies.
I would like to know two things:

First about the command ¨make Model=(NAME OF THE MODEL)¨
1) When I runned this command in the case of the standard model UMSSM writing ¨make Model=UMSSM¨ it worked perfectly and created the SPheno executable with the name I expected SPhenoUMSSM. The model I created from the standard UMSSM model files in which I defined the ThetaE6 mixing angle as a new parameter is called UMSSMmine. When I runned the command make Model=UMSSMmine it seemed to work well but it did not create a new executable with the name I expected, which is SPhenoUMSSMmine. Does that mean that when we create new model files in SARAH starting from a standar model already implemented in SARAH we don't need to change also the binary SPheno executable? Can I be sure that if I compile my new model UMSSMmine with the old binary SPhenoUMSSM SPheno will note all the new things I added in my LesHouches input file, so that I don't need to create a new SPheno executable with the same name I put in my model file?

Second about running a low energy input file of UMSSM
2) The high energy input file LesHouches.in.UMSSM worked well. But, as I would also like to obtain a low energy spectrum of this model, when I runned the command ./bin/SPhenoUMSSM LesHouches.in.UMSSM_low SPheno.spc.UMSSM_low putting the input and output names as arguments, there was an error message saying that
Problem with RGE running. Errorcode: -2
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
This happened with the low energy input file that I attached here especially when I put lower values to the parameter lambda. When I put bigger values like 2.90E+01 it shows an error message that says that this coupling behaves as a non-perturbative coupling at GUT scale
Non pertubative coupling at GUT scale lam
Problem with RGE running. Errorcode: -12
And if I decrease the value of vS SPheno shows a lot of warnings indicating the appearance of negative mass squared of particles eigenstates like hh and Ah. How can I solve the problem with RGE running which has the Errorcode: -2? Is there a table in a specific file that shows all these Errorcodes, what causes them and how to fix them? If so, let me know.


Best regards


Cheers
Felipe

[FStaub]

Hi,

concerning 1): you need to change in the model file

Code: Select all

Model`Name = "UMSSM";

concerning 2): all these errors just tell you that your point is physically not valid. E.g. lambda > sqrt(4 Pi) is just forbidden by perturbation theory. However, these are physical problems related to the model you want to study. That goes beyond the support I can give here. Sorry.

Cheers,
Florian

[felipeagf]

Hi Florian

I want to put the extra U(1) charges of UMSSM as new input parameters, but when I write them in the block EXTPAR of my low scale input file ¨LesHouches.in.UMSSM_low¨ and runSPheno it shows the following messages

Unknown entry for Block EXTPAR 200
Unknown entry for Block EXTPAR 201
Unknown entry for Block EXTPAR 202
Unknown entry for Block EXTPAR 203
Unknown entry for Block EXTPAR 204
Unknown entry for Block EXTPAR 205
Unknown entry for Block EXTPAR 206
Unknown entry for Block EXTPAR 207
Unknown entry for Block EXTPAR 208


This is weird because the SPheno.m file contains all these parameters already declared in the block EXTPAR and when I run the high scale input file ¨LesHouches.in.UMSSM¨ with all these parameters written in the block EXTPAR this problem does not occur. Does that mean that SPheno.m file can only be recognized by the high scale input of the model but not by the low scale input of the same model?

Do you think I should write these charges in another block called XCharge as is written in the parameters.m file? If so, how can SPheno read them as extra input parameters?

Attached here are all the files input files together with SPheno.m and parameters.m files.



Best regards
Cheers
Felipe

[felipeagf]

Hi Florian

Finally I decided to delete my old SPheno executable of UMSSM located in SPheno/bin and create a new executable. After that, when I runned SPheno with the same low energy input file I attached here it worked better and SPheno recognized the charges as extra parameters. But I don't know why this happens. Do you recommend me to always repeat the operation that creates a new binary for the model after changing just a little bit my input parameter point before running SPheno code with this new parameter point or it is not necessary to do that?

After solving this problem, when I runned SPheno code I finally got a spectrum file but in the Messages.out file appears the following error messages

Numerical problem in D00check
Involved masses: 7.5451120976192990E-006 2.5047362702126341E-007 0.0000000000000000 359392686.20461941
Numerical problem in D00check
Involved masses: 7.5451120976192990E-006 2.5047362702126341E-007 0.0000000000000000 359392704.16746080
Numerical problem in D00check
Involved masses: 7.5451120976192990E-006 2.5047362702126341E-007 359392686.20461941 0.0000000000000000
Numerical problem in D00check
Involved masses: 7.5451120976192990E-006 2.5047362702126341E-007 359392704.16746080 0.0000000000000000


What is D00check? What does this error message mean and what do you recommend me to do in order to solve it?




Best regards and Thanks a lot


Cheers
Felipe

[FStaub]

Hi,

1) you don't have to delete everything, but it can be helpful to run

Code: Select all

make cleanall
make Model=...

if you have changed the code and experience a strange behaviour. That deletes all libraries and recompiles everything from scratch. If you want to switch compilers you need to do that.

2) D00check is a function which calculates box integrals for the flavour observables. Those diverge for specific mass combinations. This is in particular the case if massless states appear in the loop. However, usually this doesn't make problems because photons or gluons have no flavour changing interaction, i.e. the integrals are multiplied by zero. Thus,as long as the flavour observables are numerical stable, no action should be necessary.