Error in MG5 QED process output [fixed]

[Manning]

I'm testing a new model (two universal extra dimensions from FeynRules UFO output) in MG5 and am running into errors with my QED interactions and the command output. Some of the errors include:

for the process, p p > e1p+ e1p- where e1p is an essentially a heavier electron I get the following errors when I invoke the command: output pp_e1pe1p

ALOHAERROR : unknow type in Lorentz Evaluation

I've attached the MG_debug file as MG_debug_1 in the MG_debug.tgz file.

Another error I get is for the process: p p > t t~ t t~ QCD=6 QED=6 ,

INFO: Generating Helas calls for process: g g > t t~ t t~ QED=6 QCD=6
Command "output pp_ttbarttbar" interrupted with error:
ValueError : String 1/4 Nc^2 T(-1000,3) T(-1000,6) cannot be simplified to a number!

I've attached the debug file as MG_debug_2 in the MG_debug.tgz file.

I haven't had any problems with QCD processes, so I'm not sure if this is my model or a bug. Thanks for any assistance!!

[Manning (petermanningjr)]

I've narrowed the channel down to a T-channel decay, specifically,
e+ e1p+
    \ /
     |
     bh10
    |
   / \
e- e1p-

where bh10 is a scalar. I hope this helps. I believe the vertex info from the model's vertices.py, lorentz.py and couplings.py files are:

V_28 = Vertex(name = 'V_28',
              particles = [ P.e__plus__, P.e1p__minus__, P.BH10 ],
              color = [ '1' ],
              lorentz = [ L.FFS4 ],
              couplings = {(0,0):C.GC_6})

FFS4 = Lorentz(name = 'FFS4',
               spins = [ 2, 2, 1 ],
               structure = 'ProjM(2,1) + (4*complex(0,1)*ProjM(2,1))/

GC_6 = Coupling(name = 'GC_6',
                value = 'g1/2.',
                order = {'QED':1})

[Manning (petermanningjr)]

Figured I might as well give the particle info as well:

BH11 = Particle(pdg_code = 9000063,
                name = 'BH11',
                antiname = 'BH11',
                spin = 1,
                color = 1,
                mass = Param.MBH11,
                width = Param.ZERO,
                texname = 'BH11',
                antitexname = 'BH11',
                charge = 0,
                LeptonNumber = 0,
                GhostNumber = 0)

e1p__minus__ = Particle(pdg_code = 9000006,
                        name = 'e1p-',
                        antiname = 'e1p+',
                        spin = 2,
                        color = 1,
                        mass = Param.L10,
                        width = Param.ZERO,
                        texname = 'e1p-',
                        antitexname = 'e1p-',
                        charge = -1,
                        LeptonNumber = 1,
                        GhostNumber = 0)

e1p__plus__ = e1p__minus__.anti()

[Olivier Mattelaer (olivier-mattelaer)]

Hi,

Thanks for the bug report.

Concerning the p p > e1p+ e1p-.
It should be a problem with the expression inside the FFS4 structure which is not recognize by the ALOHA program.
It seems to me that your expression of FFS4 is not complete.
The easiest might be that you join the model in attachment such that, I can test this on my computer.

Concerning the
g g > t t~ t t~
I already face this problem in a UFO model. The point is that all particle should be in the 3 representation of SU(3) and all anti-particle should be in -3 representation of SU(3). If this is not done correctly, this creates some un-realistic color flow.

Could you check this point on your model?

Olivier

[Manning (petermanningjr)]

I've attached the entire model file as a tgz on the bug report, I hope this
helps. Thanks!

-Peter

On Mon, Mar 28, 2011 at 3:43 PM, Olivier Mattelaer <
<email address hidden>> wrote:

> Hi,
>
> Thanks for the bug report.
>
> Concerning the p p > e1p+ e1p-.
> It should be a problem with the expression inside the FFS4 structure which
> is not recognize by the ALOHA program.
> It seems to me that your expression of FFS4 is not complete.
> The easiest might be that you join the model in attachment such that, I can
> test this on my computer.
>
> Concerning the
> g g > t t~ t t~
> I already face this problem in a UFO model. The point is that all particle
> should be in the 3 representation of SU(3) and all anti-particle should be
> in -3 representation of SU(3). If this is not done correctly, this creates
> some un-realistic color flow.
>
> Could you check this point on your model?
>
> Olivier
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/744236
>
> Title:
> Error in MG5 QED process output
>
> Status in The MadGraph Matrix Element Generator version 5:
> New
>
> Bug description:
> I'm testing a new model (two universal extra dimensions from FeynRules
> UFO output) in MG5 and am running into errors with my QED interactions
> and the command output. Some of the errors include:
>
> for the process, p p > e1p+ e1p- where e1p is an essentially a heavier
> electron I get the following errors when I invoke the command: output
> pp_e1pe1p
>
> ALOHAERROR : unknow type in Lorentz Evaluation
>
> I've attached the MG_debug file as MG_debug_1 in the MG_debug.tgz
> file.
>
> Another error I get is for the process: p p > t t~ t t~ QCD=6 QED=6 ,
>
> INFO: Generating Helas calls for process: g g > t t~ t t~ QED=6 QCD=6
> Command "output pp_ttbarttbar" interrupted with error:
> ValueError : String 1/4 Nc^2 T(-1000,3) T(-1000,6) cannot be simplified to
> a number!
>
> I've attached the debug file as MG_debug_2 in the MG_debug.tgz file.
>
> I haven't had any problems with QCD processes, so I'm not sure if this
> is my model or a bug. Thanks for any assistance!!
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/madgraph5/+bug/744236/+subscribe
>

[Manning (petermanningjr)]

I've tracked down at least a subset of the decay chains that cause the
error. I've attached the eps file with the main decay, which is u u~ > g11
bh11. The g11 and the bh11 then decay each to ttbar.

-Peter

On Mon, Mar 28, 2011 at 3:43 PM, Olivier Mattelaer <
<email address hidden>> wrote:

> Hi,
>
> Thanks for the bug report.
>
> Concerning the p p > e1p+ e1p-.
> It should be a problem with the expression inside the FFS4 structure which
> is not recognize by the ALOHA program.
> It seems to me that your expression of FFS4 is not complete.
> The easiest might be that you join the model in attachment such that, I can
> test this on my computer.
>
> Concerning the
> g g > t t~ t t~
> I already face this problem in a UFO model. The point is that all particle
> should be in the 3 representation of SU(3) and all anti-particle should be
> in -3 representation of SU(3). If this is not done correctly, this creates
> some un-realistic color flow.
>
> Could you check this point on your model?
>
> Olivier
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/744236
>
> Title:
> Error in MG5 QED process output
>
> Status in The MadGraph Matrix Element Generator version 5:
> New
>
> Bug description:
> I'm testing a new model (two universal extra dimensions from FeynRules
> UFO output) in MG5 and am running into errors with my QED interactions
> and the command output. Some of the errors include:
>
> for the process, p p > e1p+ e1p- where e1p is an essentially a heavier
> electron I get the following errors when I invoke the command: output
> pp_e1pe1p
>
> ALOHAERROR : unknow type in Lorentz Evaluation
>
> I've attached the MG_debug file as MG_debug_1 in the MG_debug.tgz
> file.
>
> Another error I get is for the process: p p > t t~ t t~ QCD=6 QED=6 ,
>
> INFO: Generating Helas calls for process: g g > t t~ t t~ QED=6 QCD=6
> Command "output pp_ttbarttbar" interrupted with error:
> ValueError : String 1/4 Nc^2 T(-1000,3) T(-1000,6) cannot be simplified to
> a number!
>
> I've attached the debug file as MG_debug_2 in the MG_debug.tgz file.
>
> I haven't had any problems with QCD processes, so I'm not sure if this
> is my model or a bug. Thanks for any assistance!!
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/madgraph5/+bug/744236/+subscribe
>

[Olivier Mattelaer (olivier-mattelaer)]

Concerning the p p > e1p+ e1p- problem,
this is a very very stupid bug, due to a situation that we never face in UFO.

The easiest way to solve this is to put in the file
aloha/create_aloha.py

the line:
import cmath

just before the line
import copy
(This is the first not commented line)

Thanks a bunch to have found this point.
I'm going to move on the 4 top problem.

[Olivier Mattelaer (olivier-mattelaer)]

Concerning the problem of 4 top, I think that the problem is linked to this interactions (and may be some other)

mg5>display interactions 399
Interactions 399 has the following property:
{
    'id': 399,
    'particles': [-2,2,9000063],
    'color': [1 ],
    'lorentz': ['FFS43', 'FFS66'],
    'couplings': {(0, 1): 'GC_296', (0, 0): 'GC_278'},
    'orders': {'QED': 1, 'QCD': 1}
}

while for the color content, I would naivly expect the same behavior as the t t~ h interactions in the sm:
mg5>display interactions 41
Interactions 41 has the following property:
{
    'id': 59,
    'particles': [-6,6,25],
    'color': [1 T(1,0)],
    'lorentz': ['FFS2'],
    'couplings': {(0, 0): 'GC_97'},
    'orders': {'QED': 1}
}

So I would tend to claim that this is a FR problem (since the color is not correctly set).
I will send an email to claude such that, it will be aware of this report and can interact with you,

All the best,

Olivier

[Olivier Mattelaer (olivier-mattelaer)]

This the answer of claude: (wich might be interesting for other people):

The FeynRules convention is that either all indices are written, or none. In your case, the latter option does not apply. So you have to write out *all* indices for the quarks, including the color index.
The correct syntax for the Lagrangian above then reads:

XXsiuqL[n] (Ga[mu, r, ss] ProjM[ss, s] uqbar[r, n, i].uq[s, n, i])) (del[BH11, mu]).

If you omit the indices, you miss the delta function for the color lines, which results in the observed troubles in MG5.
With the above syntax, all problems disappear :)

[Olivier Mattelaer (olivier-mattelaer)]

I pass to bug report to a question, since the color problem might be recurent.
For the bug linked to aloha, I just release the fix, and it will be in the official version at the end of the week.

Thanks a lot for those reports,

Olivier