Namespace Clash (causing infinite loop in MakeWHIZARD)

Question how to implement a model or how to change a model implementation
Post Reply
JPEllis
Posts: 71
Joined: 28. Apr 2016, 10:34

Namespace Clash (causing infinite loop in MakeWHIZARD)

Post by JPEllis » 1. May 2016, 07:37

I've been having issues with the MakeWHIZARD hanging for very long times. I have found that it occurs in the OmegaConstructor function inside WOMathematicaInterface.m at line ~925:

Code: Select all

c = WO`FirstUpper[WO`SanitizeString[s]];
where the sanitising function is

Code: Select all

WO`SanitizeString[s_] := WO`StringReplaceAll[s, WO`StringRules];
WO`StringReplaceAll[s_, l_List] := FixedPoint[StringReplace[#, l]&, s]
and if an input string does not result in a fixed point will cause Mathematica to hang.

In my particular case, it tries to sanitise "{{2}}" which causes the following sequence:

Code: Select all

{{2}}
__2__
_2_
2__
__2
_2
2_
_2
2_
_2
2_
...
In particular, this occurs because both leading digits and underscores are moved to the end, causing them to be swapped over and over.

Looking at the way OmegaConstructor is used though, I suspect the bug is really somewhere else as I doubt "{{2}"" is an expected input. The bug occurs when OmegaConstructor parses plist on line ~1120. Tracing back where the "{{2}}" comes from, it comes from getOutputName[y_,gen_,fla___] on line 1779 of mathParticleProp.m.

Ultimately, it was because I had a particle called "SP" which results in the name "SP2" and when getOutputName generates the name, it actually evaluates the name:

Code: Select all

ToExpression[SP <> ToString[2]]
In this instance, it tries to evaluate SP2 as defined in Susyno to be {{2}}.

As a temporary solution, I have renamed the "SP" particle to something else that doesn't conflict, but perhaps this could be changed in the future so that any particle name could be used.
Joshua Ellis jpellis.me

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

Re: Namespace Clash (causing infinite loop in MakeWHIZARD)

Post by JPEllis » 1. May 2016, 08:10

The following diff seems to work:

Code: Select all

--- a/SARAH-4.8.5/Package/mathParticleProp.m
+++ b/SARAH-4.8.5/Package/mathParticleProp.m
@@ -1761,11 +1761,11 @@ Return[ToString[y]];
 getOutputNameAnti[y_,gen_,fla___]:=Block[{temp},
 temp = getOutputName[y,gen,fla];
 If[AntiField[y]===y,
-Return[ToExpression[temp]];,
+Return[ToString[temp]];,
 If[getType[y]===F,
-Return[ToExpression[ToString[temp]<>"bar"]];,
-(* Return[ToExpression["c"<>ToString[temp]]]; *)
-Return[ToExpression[ToString[temp]<>"c"]];
+Return[ToString[temp]<>"bar"];,
+(* Return["c"<>ToString[temp]]; *)
+Return[ToString[temp]<>"c"];
 ];
 ];
 ];
@@ -1781,17 +1781,17 @@ temp = getOutputName[y];
 If[temp===None || temp===NONE, Return[temp];];
 If[gen==0,
 If[Head[temp]===List,
-Return[ToExpression[temp[[1]]]];,
-Return[ToExpression[temp]];
+Return[temp[[1]]];,
+Return[temp];
 ];,
 If[Head[temp]===List,
 temp=temp[[1]];
 ];
 If[getGen[y]==1,
-Return[ToExpression[temp]];,
+Return[temp];,
 If[getFla[y]>1,
-Return[ToExpression[temp<>ToString[gen]<>ToString[fla]]];,
-Return[ToExpression[temp<>ToString[gen]]];
+Return[temp<>ToString[gen]<>ToString[fla]];,
+Return[temp<>ToString[gen]];
 ];
 ];
 ];
At the very least, running MakeAll[] on the MSSM model did not produce any errors (I haven't validated all the outputs).
Joshua Ellis jpellis.me

FStaub
Site Admin
Posts: 822
Joined: 13. Apr 2016, 14:05

Re: Namespace Clash (causing infinite loop in MakeWHIZARD)

Post by FStaub » 1. May 2016, 10:35

It seems to me that you want to return Strings instead of Expressions for the OutputName. Without testing it, I have some doubts that this will work correctly in all parts.
As a temporary solution, I have renamed the "SP" particle to something else that doesn't conflict, but perhaps this could be changed in the future so that any particle name could be used.
Since there might be many other names which will cause conflicts, that's the best solution. However, it might be good to improve CheckModels in that way that it prints warning if a name is used in the model which is already occupied by something else.

I'll move the thread to the implementation forum, because I think it fits better there.

Post Reply