3 bugs in the muon decay implementation in SPhenoBoundaryEW.m

[MarkusBach]

Hello Florian,

while comparing the calculation of the W pole mass via muon decay in the SPheno code created by SARAH for the MRSSM with the routine from FlexibleSUSY 2.0, I found 3 numerically relevant bugs in SPhenoBoundaryEW.m:

1. In the code

Code: Select all

WriteString[sphenoSugra,"xt2=3._dp*(G_F*mf_u2(3)*oo8pi2*oosqrt2)**2&\n"];
WriteString[sphenoSugra,"    &*Abs("<>SPhenoForm[HiggsMixingMatrix]<>"(1,2))**2*rho_2(Sqrt("<>SPhenoForm[SPhenoMassSq[HiggsBoson]]<>"(1))/mf_U(3))&\n"];
WriteString[sphenoSugra,"    &*((1._dp+tanb**2)/tanb**2)\n"];
WriteString[sphenoSugra,"fac(1)=alphaMZ*alphaS_mZ*oo4pi&\n"];
WriteString[sphenoSugra,"      &*(2.145_dp*mf_u2(3)/mZ2+0.575*Log(mf_u(3)/mZ)-0.224_dp&\n"];
WriteString[sphenoSugra,"      &-0.144_dp*mZ2/mf_u2(3))/Pi\n"];
WriteString[sphenoSugra,"fac(2)=alphamZ*alphaS_mZ*oo4pi&\n"];
WriteString[sphenoSugra,"      &*(-2.145_dp*mf_u2(3)/mW2+1.262*Log(mf_u(3)/mZ)-2.24_dp&\n"];
WriteString[sphenoSugra,"      &-0.85_dp*mZ2/mf_u2(3))/Pi\n"];

right before line 2000, mf_u(3) denotes the top pole mass while mf_u2(3) denotes the squared top DRbar mass (after the first iteration). According to Refs. arXiv:hep-ph/9606211 and arXiv:hep-ph/9212285, the pole mass should be used everywhere.

2. Some lines below in the self energies

Code: Select all

MakeCall["Pi1Loop"<>ToString[VectorZ],Flatten[{massesZ,couplingsZ}],{"mZ2"},{"kont","dmZ2"},sphenoSugra];
.
.
.
MakeCall["Pi1Loop"<>ToString[VectorW],Flatten[{massesW,couplingsW}],{"mW2"},{"kont","dmW2"},sphenoSugra];
MakeCall["Pi1Loop"<>ToString[VectorW],Flatten[{massesW,couplingsW}],{"0._dp"},{"kont","dmW2_0"},sphenoSugra];

, again the top DRbar mass is used (after the first iteration) instead of the more appropriate pole mass (see arXiv:hep-ph/9212285).

3. Another few lines below, the code

Code: Select all

WriteString[sphenoSugra,"delta_rw=delta_rho*(1._dp-delta_r)+delta_r\n"];

appears twice. Here, delta_rho is a pure 1-loop quantity, which leads to the formula

Code: Select all

WriteString[sphenoSugra,"mW2=mZ2*rho*(0.5_dp& \n"];
WriteString[sphenoSugra,"   &+Sqrt(0.25_dp-alphamz*pi/(sqrt2*G_F*mz2*rho*(1._dp-delta_rw))))\n"];

, where rho contains the leading SM 2-loop corrections, not being compatible with the previously calculated weak mixing angle

Code: Select all

WriteString[sphenoSugra,"CosW2SinW2=pi*alphamZ/(sqrt2*mZ2*G_F*(1-delta_r))\n"];
WriteString[sphenoSugra,"sinW2_Q=0.5_dp-Sqrt(0.25_dp-CosW2SinW2)\n\n"];

. In the computation of delta_rw, delta_rho should be replaced by (delta_rho+fac(2)/sinW2_Q+xt2), also taking the leading SM 2-loop corrections into account.

Altogether, these bugs account for a deviation in the calculated W pole mass of about 100 MeV for BMP1 from arXiv:1410.4791 (with the second bug having the largest numerical influence). Considering the experimental uncertainty of 15 MeV, the bugs are very relevant and should be fixed.

Cheers,
Markus

[FStaub]

Hi,

thank you for the report. I'll take a look asap.

Cheers,
Florian

[FStaub]

Hi,

where exactly is written that the pole masses should be used (and only the one for the top but not for bottom?)? We can't find it in the two papers you mentioned.

Best,
Florian

[MarkusBach]

arXiv:hep-ph/9212285, page 5:
"We emphasize the important fact that the magnitude of the O(αα_s) effects depends sensitively on the precise definition of m_t. Our detailed calculations, as well as the other papers in the literature, employ the “on-shell” definition of m_t."

arXiv:hep-ph/0301101, page 16:
"All masses appearing in the loops are running except for the top-quark, because the 2-loop part is given for an on-shell definition of the top mass."

I guess it cannot be stated more clearly and especially the second paper should be quite relevant for your code.
But after some additional investigations, I found out that all 3 bugs are also included in Werner Porod's SPheno code, so there seems to be a mismatch between the paper and the actual implementation.

[FStaub]

Thanks.

Yes, the implementation in SPheno is identical and I sent Werner already a link to the discussion here.

Cheers
Florian

[FStaub]

Hi,

I have implemented the changes, but found actually a very small difference in the results for the MSSM of O(5 MeV). I haven't checked the MRSSM yet, but expect the same there.
The reason is that the BoundaryEW shouldn't be used anymore but has been replaced by BoundarySM & BoundaryBSM. In BoundarySM the difference between the running top mass and the MS top mass is much smaller than in BoundaryEW before, i.e. the effects are much less pronounced. BoundaryEW is still included to compare the difference between the one- and two-scale matching, and can be chosen via flag 66.

Cheers,
Florian

[MarkusBach]

Hello Florian,

indeed I had set the flag 66 in the SPHENOINPUT block to 0 to use the old one-scale matching. With this setting I have found a large influence of the described bugs both in the MRSSM and in the MSSM. For the new two-scale matching (flag 66 set to 1), I also find a smaller influence of the bugs but the actual results for the W pole mass are quite different from the ones calculated using the one-scale matching. Actually, I have doubts about the suitability of the two-scale matching for a calculation of the W pole mass, induced by a discussion I just had with Dominik Stöckinger. He mentioned that the two-scale matching procedure forces the W pole mass to be in agreement with the SM value and therefore might not give a meaningful MW prediction of the investigated model. If this is really the case, one should definitely use the old one-scale matching for predictions of the W pole mass. What are your thoughts regarding this issue?

Aside from the previous discussion, before the two-scale matching has been introduced to SARAH/SPheno, people used the old one-scale matching procedure for which the described bugs definitely have a large influence on the W pole mass calculation. So in the past, several investigations using the SARAH/SPheno code might have drawn the wrong conclusions regarding the W pole mass (this is at least the case for the already mentioned paper arXiv:1410.4791). I hope that people affected by this problem will be aware of it.

Cheers,
Markus

PS: Could it be the case that with flag 66 set to 1 (two-scale matching) the output 24 in the MASS block is not the W pole mass but some running mass? I get strange values of around 79.3 GeV which are completely different from what I get by directly putting a print statement into the code.

[FStaub]

Hi,

I see your point. I need to think a bit further about this, but here a some (un-ordered) comments:

1) Concerning the last question: what is printed in block MASS for the W-mass is the loop corrected mass at the renormalisation scale, i.e. M_SUSY.
2) It is correct that m_W in BoundarySM doesn't contain any BSM contributions. The two scale matching should not improve the calculation of m_W but the one of the SUSY/Higgs mass spectrum as well as the one of the gauge couplings which are crucial for GUT models.
3) From these two points it becomes clear that mW printed in the MASS block is not really something you should consider to compare with the experimental value. I admit that this should be expressed clearly somewhere. I never thought about this, because it never came to my mind to use mW as observables to constrain BSM models, but I always took \delta\rho or the newly calculated oblique parameters.
4) It's not clear to me that mW calculated with the old routine is a very reliable prediction even if the top pole mass is used: in particular for heavy new physics, there will be large logs which introduce a large uncertainty.
5) The best approach would be to use the 2-scale matching and calculate BSM contributions to mW at the scale Q and run it down to M_Z to combine it with the SM corrections consistently. I'm not sure, if this is some reference how this is done correctly, ie which EFT operators are needed and how they are combined with the SM calculation.

Cheers,
Florian