no ordering relation is defined for complex numbers

Are you using FeynRules to generate this model and you did not modify it by hand?
If yes, then the Assignee of this question will be able to help you.

Otherwise, and if you generated this effective vertex by hand, then it means that in one of the python expression you coded yourself in the UFO, you have introduced statements like:

Arg < 0.0

where Arg is defined as a (or involves) complex parameter (i.e. defined as 'complex' in Parameters.py). Keep in mind that it doesn't matter if the imaginary part is zero, if the parameter is defined as complex, then it will *not* work.

As a result, MG5aMC will crash upon loading this model as it will test the expression in python where these comparative operators are only allows for real arguments, not complex ones.

answer (in another question) from Avirup:

I have written the FeynRules file for effective vertex hAA/hGG (generalised way, applicable for both \tau> 1 and \tau<1) in the following way

f[t_] := If[t > 1, (-1/4)*(Log[(1 + Sqrt[1 - 1/t])/(1 - Sqrt[1 - 1/t])] - I*Pi)^2, (ArcSin[Sqrt[t]])^2 ];

Ahalf[t_]:= 2/t + 2*(t-1)/t^2*f[t];

Aone[t_]:= -2 - 3/t - (3*(2*t-1)/t^2)*f[t];

Azero[t_]:= -1/t + (1/t^2)*f[t];

AHM == {ParameterType -> Internal,
       Value-> (hffbar*Ahalf[(MH/2/MT)^2]+Aone[(MH/2/MW)^2]+
              (MW^2/(2*cw^2*MHP^2))*hHpHm*Azero[(MH/2/MHP)^2]+
              (MW^2/(2*cw^2*MH2P^2))*4*hHppHmm*Azero[(MH/2/MH2P)^2])},

AH == {TeX -> Subscript[A, H],
       ParameterType -> Internal,
       InteractionOrder -> {HIG, 1},
       Value -> ee^2/4/Pi/(Pi*vev)*Abs[AHM]},

where hHpHm and hHppHmm are some real multiples.

Using this , When I have generated UFO file then, no error has been detected. However when I have imported the UFO file in the madgraph, the followin error has been detected.

Error detected in "output MY_GGH"
write debug file MG5_debug
If you need help with this issue please contact us on https://answers.launchpad.net/mg5amcnlo
MadGraph5Error : Unable to evaluate mdl_AHM = -2 + mdl_hffbar*((8*mdl_MT__exp__2)/mdl_MH__exp__2 + (32*( -(-(cmath.pi*mdl_complexi) + cmath.log((1 + cmath.sqrt(1 - (4*mdl_MT__exp__2)/mdl_MH__exp__2))/(1 - cmath.sqrt(1 - (4*mdl_MT__exp__2)/mdl_MH__exp__2))))**2/4. if mdl_MH__exp__2/(4.*mdl_MT__exp__2)>1 else cmath.asin(cmath.sqrt(mdl_MH__exp__2/mdl_MT__exp__2)/2.)**2 )*(-1 + mdl_MH__exp__2/(4.*mdl_MT__exp__2))*mdl_MT__exp__4)/mdl_MH__exp__4) - (12*mdl_MW__exp__2)/mdl_MH__exp__2 + (2*mdl_hHppHmm*((-4*mdl_MH2P__exp__2)/mdl_MH__exp__2 + (16*( -(-(cmath.pi*mdl_complexi) + cmath.log((1 + cmath.sqrt(1 - (4*mdl_MH2P__exp__2)/mdl_MH__exp__2))/(1 - cmath.sqrt(1 - (4*mdl_MH2P__exp__2)/mdl_MH__exp__2))))**2/4. if mdl_MH__exp__2/(4.*mdl_MH2P__exp__2)>1 else cmath.asin(cmath.sqrt(mdl_MH__exp__2/mdl_MH2P__exp__2)/2.)**2 )*mdl_MH2P__exp__4)/mdl_MH__exp__4)*mdl_MW__exp__2)/(mdl_cw__exp__2*mdl_MH2P__exp__2) + (mdl_hHpHm*((-4*mdl_MHP__exp__2)/mdl_MH__exp__2 + (16*( -(-(cmath.pi*mdl_complexi) + cmath.log((1 + cmath.sqrt(1 - (4*mdl_MHP__exp__2)/mdl_MH__exp__2))/(1 - cmath.sqrt(1 - (4*mdl_MHP__exp__2)/mdl_MH__exp__2))))**2/4. if mdl_MH__exp__2/(4.*mdl_MHP__exp__2)>1 else cmath.asin(cmath.sqrt(mdl_MH__exp__2/mdl_MHP__exp__2)/2.)**2 )*mdl_MHP__exp__4)/mdl_MH__exp__4)*mdl_MW__exp__2)/(2.*mdl_cw__exp__2*mdl_MHP__exp__2) - (48*( -(-(cmath.pi*mdl_complexi) + cmath.log((1 + cmath.sqrt(1 - (4*mdl_MW__exp__2)/mdl_MH__exp__2))/(1 - cmath.sqrt(1 - (4*mdl_MW__exp__2)/mdl_MH__exp__2))))**2/4. if mdl_MH__exp__2/(4.*mdl_MW__exp__2)>1 else cmath.asin(cmath.sqrt(mdl_MH__exp__2/mdl_MW__exp__2)/2.)**2 )*(-1 + mdl_MH__exp__2/(2.*mdl_MW__exp__2))*mdl_MW__exp__4)/mdl_MH__exp__4

Hi,

The problem is clearly related to the condition:
mdl_MH__exp__2/(4.*mdl_MW__exp__2)>1
which is related to the
If[t > 1,

My suggestion would be to explicitely convert t as a real number and this should fix the problem.

Cheers,

Olivier

previous answer made at another place:

However, I would like to mention that "t" is indeed a real number.
Further, I would like to know that, is there any restriction that we can
not impose any "if" statement in the FynRules file? So that for the two
different conditions (t>1 or t<1) we can generate the generalised hAA/ hGG
vertex.

Hi,

In python, variable do not have a pre-defined type. So even if a number is a real number it can be written in memory as a complex number (this is actually common in UFO model since it uses the cmath python module and not the math python module).

For your other question, this sounds a FeynRules questions. I have no idea of the answer and therefore recommend that you contact them directly and/or read their manual to get that information.

Cheers,

Olivier