Inconsistent OutputForm for mixing matrix

Report the bugs you found
Post Reply
JPEllis
Posts: 71
Joined: 28. Apr 2016, 10:34

Inconsistent OutputForm for mixing matrix

Post by JPEllis » 16. Jan 2018, 06:34

I encountered a bug when generating the 2LPole_<model>.f90 in which have the line:

Code: Select all

tad1LmatrixSim=matmul(ImagScalarMixing,matmul(tad1LmatrixSim,transpose(ImagScalarMixing)))
which fails to compile as ImagScalarMixing is not defined. Instead, it should be `ZSI` which is declared beforehand. I believe the relevant lines that generate this are around lines 1332 in SPheno2LPole.m. The same errors happens with the real scalar mixing matrix.

Josh
Joshua Ellis jpellis.me

MDGoodsell
Posts: 17
Joined: 25. Aug 2017, 08:41

Re: Inconsistent OutputForm for mixing matrix

Post by MDGoodsell » 22. Jan 2018, 14:44

Hi Josh,

This shouldn't happen if ZSI is defined as the mixing matrix of the field in the <model name>.m file in DEFINITION[EWSB][MatterSector] = { ... }. The code is looking in the ListTree variable where the second entry for your scalars should be ZSI and not "ImagScalarMixing", and I don't know where that is coming from.

If your DEFINITION[EWSB][MatterSector] is defined correctly and you are sure this is a SARAH problem could you send me the model files you are using so I can reproduce the bug? In the interim I suspect that a quick fix would be to define

ImagScalarMixing = ZSI;
in SPheno.m, and similarly for your real scalars.

On the other hand, it sounds like you have implemented a model with neutral scalars that do not mix with the Higgs. It is possible that this might cause some bugs in the two-loop routines, where the combinatorics assume that it is only possible to make such definitions if there is some symmetry that prevents the mixing.

Best
Mark

JPEllis
Posts: 71
Joined: 28. Apr 2016, 10:34

Re: Inconsistent OutputForm for mixing matrix

Post by JPEllis » 23. Jan 2018, 02:24

Thanks for getting back to me. At no point in the Mathematica files do I have ZSI as a symbol. In my parameters.m file, I have

Code: Select all

  {ImagScalarMixing, {
    Description        -> "Pseudo-Scalar-Mixing-Matrix", (*X*)
    LaTeX              -> "U^S_\\Im",
    OutputName         -> "ZSI",
    LesHouches         -> "IMAGSCALARMIXING",
    Real               -> False,
    Value              -> None,
    Dependence         -> None,
    DependenceNum      -> None,
    DependenceOptional -> None,
    DependenceSPheno   -> None,
   }},
and in the DEFINITION[EWSB][MatterSector], I used ImagScalarMixing (note that is exactly the same as the quark mixing which works fine). Are you really suggesting that I replace it with the string "ZSI"? Also, most scalar mixing is fine and uses ZSI and it is just one file which doesn't correctly replace the scalar mixing matrix with ZSI.

Your last comment is spot on. I have indeed implemented a model with a neutral scalar that does not mix with the Higgs (to be precise, I have three scalars, two of them mix and the last is protected by a Z2 symmetry). What should I do then to avoid possible bugs with the two-loop routines?
Joshua Ellis jpellis.me

MDGoodsell
Posts: 17
Joined: 25. Aug 2017, 08:41

Re: Inconsistent OutputForm for mixing matrix

Post by MDGoodsell » 23. Jan 2018, 17:01

Ah ok, I understand now. I never tested on an example where the OutputName of a mixing matrix is different from the internal name. I can see two good solutions:

1) If you want to "fix" the code then you can replace the line 1287 in SPheno2LPole.m:

mixmat=relevanttreemasses[[ii,5]];

by

mixmatN=relevanttreemasses[[ii,5]];
mixmat=getOutputNameParameter/@mixmatN;

*and* then change line 1331 from

If[conj[part]=!=part&&FreeQ[realVar,mixmat],

to

If[conj[part]=!=part&&FreeQ[realVar,mixmatN],

In principle there will be similar problems if you want to define mass matrices to be different from their output names. I suspect I'll bump this into the next release.

2) Just use the same symbol for the mixing matrix as its output name.

Regarding potential problems with neutral scalars, there are two issues. One is if there are two types of complex structure for a given coupling, which can only happen if you cheat with your definitions (i.e. group fields together that can't mix). On the other hand I will have to think if it is a problem when fields *should* mix but you give them different names, i.e. you have some neutral scalars but no symmetry (so you could e.g. have Pi_{hS} for your neutral scalar S) ...

Post Reply