Error in madgraph for MUED model file

Dear Debabrata, which version of LanHEP did use to generate ufo file? .t
means auxiliary tensors we have used to split complicated vertices. We
did not check if LanHEP is fully compatible with Madgraph for such a
sophisticated model. I believe that the main problem is that Madgraph
can not deal with complex vertices and splitting them into simplier one
sing tensor auxiliary particles. The solution for this problem is to use
CalcHEP which would allow you to quickly and effectively study the
phenomenology of MUED model as we did in our paper. Best regards Alexander
On 08/11/2025 14:00, Debabrata Sahoo wrote:
> [You don't often get email <email address hidden>. Learn why this is important athttps://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION: This e-mail originated outside the University of Southampton.
>
> New question #822831 on HEPMDB:
> https://answers.launchpad.net/hepmdb/+question/822831
>
> Dear Experts,
>
> I took the MUED file and generated ufo file and got this error in MadGraph:
>
> File "/home/debabrata/softwares/MG5_aMC_v3_5_5/models/mued/vertices.py", line 25122, in <module>
> particles = [ P.GX_S.t, P.G_2, P.G_2 ],
> ^^^^^^^^
> AttributeError: 'Particle' object has no attribute 't'
>
>
> Which might be coming due to these lines in the code:
>
> parameter Maux=1.
> vector GX_S/GX_S: (GX_S, mass Maux, color c8, * ),
> GX_T/GX_T: (GX_T, mass Maux, color c8, * ),
> GX_U/GX_U: (GX_U, mass Maux, color c8, * ),
> GX_V/GX_V: (GX_V, mass Maux, color c8, * ),
> GX_W/GX_W: (GX_W, mass Maux, color c8, * ).
>
>
> let Gnonab00^mu^nu^a=i*GS*f_SU3^a^b^c*G^mu^b*G^nu^c,
> Gnonab11^mu^nu^a=i*GS*f_SU3^a^b^c*'G_1'^mu^b*'G_1'^nu^c,
> Gnonab22^mu^nu^a=i*GS*f_SU3^a^b^c*'G_2'^mu^b*'G_2'^nu^c,
> Gnonab01^mu^nu^a=i*GS*f_SU3^a^b^c*G^mu^b*'G_1'^nu^c,
> Gnonab10^mu^nu^a=i*GS*f_SU3^a^b^c*'G_1'^mu^b*G^nu^c,
> Gnonab02^mu^nu^a=i*GS*f_SU3^a^b^c*G^mu^b*'G_2'^nu^c,
> Gnonab20^mu^nu^a=i*GS*f_SU3^a^b^c*'G_2'^mu^b*G^nu^c,
> Gnonab12^mu^nu^a=i*GS*f_SU3^a^b^c*'G_1'^mu^b*'G_2'^nu^c,
> Gnonab21^mu^nu^a=i*GS*f_SU3^a^b^c*'G_2'^mu^b*'G_1'^nu^c.
>
>
> lterm -F**2/4 where F=deriv^mu*Gtot^nu^a-deriv^nu*Gtot^mu^a.
> lterm -1/4*(F*Gnonab+Gnonab*F)
> where
> F=deriv^mu*Gtot^nu^a-deriv^nu*Gtot^mu^a,
> Gnonab=i*GS*f_SU3^a^b^c*Gtot^mu^b*Gtot^nu^c.
>
> lterm -i*1/Sqrt2*'GX_S.t'*(Gnonab00+Gnonab11+Gnonab22).
> lterm -i*1/Sqrt2*'GX_T.t'*(Gnonab01+Gnonab10+1/Sqrt2*(Gnonab12+Gnonab21)).
> lterm -i*1/Sqrt2*'GX_U.t'*(Gnonab02+Gnonab20+1/Sqrt2*Gnonab11).
> lterm -i*1/Sqrt2*'GX_V.t'*(Gnonab12+Gnonab21).
> lterm -i*1/Sqrt2*'GX_W.t'*(1/Sqrt2*Gnonab22).
>
> What is .t here?
>
> Then I tried to remove the postfix terms like .t from these terms in vertices.py file and tried in MadGraph, and got this critical warning:
>
> CRITICAL: Model with non-QCD emission of gluon (found 84 of those).
> This type of model is not fully supported within MG5aMC.
> Restriction on LO dynamical scale and MLM matching/merging can occur for some processes.
> Use such features with care.
>
> Can collider studies be done with ufo file generated with lanhep?
> How can this issue be resolved?
>
> Thank you for your time.
>
> With regards,
> Debabrata Sahoo
>
> --
> You received this question notification because your team hepmdb is an
> answer contact for HEPMDB.

--
................................
Professor Alexander S Belyaev
https://www.soton.ac.uk/~ab1u06
.......
Physics & Astronomy 46/5047
University of Southampton
Southampton SO171BJ
................................

Dear Prof. Belyaev,

Thank you for your response.

I have used version 4.0.0 to generate the UFO file.

In your paper, you have analyzed at the parton level, I guess. If one wants to do a detector simulation, can one take the LHE file generated from Calchep and then use Pythia and Delphes to generate the root files for both signal and background? Since all this can be done at a go in MadGraph, I was trying to have a UFO file.

With regards,
Debabrata Sahoo

The core issue is a **syntax mismatch** where the LanHEP code, which uses the suffix **`.t`** (likely representing a field strength tensor or contracted field) in terms like `'GX_S.t'`, is incorrectly translated into the UFO's Python code, resulting in an `AttributeError` because the particle object **`P.GX_S` has no attribute `.t`**. Manually removing `.t` causes a **critical warning** about "non-QCD emission of gluon" because the resulting vertices lack the necessary **Lorentz structure**. To resolve this, you must either find the correct LanHEP syntax for contracted fields that translates properly to UFO, or switch to using **FeynRules** to generate a more robust UFO model that correctly defines these complex gauge interactions, allowing for reliable collider studies. https://www.ez-passva.com

Dear Debabrata,

indeed we restricte ourself to parton-level analysis but we do take into
account
realistic electromagnetic energy resolution, using a value of
0.15/sqrt(E), as well as their typical hadronic energy
resolution of 0.5/sqrt(E)

It is very straightforward to use Pythia and Delphes to generate the
root files for both signal and background in one go with  ChecMATE using
LHE files generated by the CalcHEP.
If you like I can guide you though this.
Moreover CheckMATE also does statistical analysis on the top of this.

Best
Alexander

On 10/11/2025 09:55, Debabrata Sahoo wrote:
> [You don't often get email <email address hidden>. Learn why this is important athttps://aka.ms/LearnAboutSenderIdentification ]
>
> CAUTION: This e-mail originated outside the University of Southampton.
>
> Question #822831 on HEPMDB changed:
> https://answers.launchpad.net/hepmdb/+question/822831
>
> Status: Answered => Solved
>
> Debabrata Sahoo confirmed that the question is solved:
> Dear Prof. Belyaev,
>
> Thank you for your response.
>
> I have used version 4.0.0 to generate the UFO file.
>
> In your paper, you have analyzed at the parton level, I guess. If one
> wants to do a detector simulation, can one take the LHE file generated
> from Calchep and then use Pythia and Delphes to generate the root files
> for both signal and background? Since all this can be done at a go in
> MadGraph, I was trying to have a UFO file.
>
> With regards,
> Debabrata Sahoo
>
> --
> You received this question notification because your team hepmdb is an
> answer contact for HEPMDB.

--
................................
Professor Alexander S Belyaev
https://www.soton.ac.uk/~ab1u06
.......
Physics & Astronomy 46/5047
University of Southampton
Southampton SO171BJ
................................

Dear Daniele,

.t is the tensor for the respective field,
I believe that LanHEP does a correct job of putting it into UFO format,
and I think the problem is in Madgraph.

I will check details later, I am not the author of LanHEP,
though taking care of it from now.

The easiest solution to study MUED physics is to generate LHE files for
the signal
from CalcHEP can pass them through PYTHIA and Delphes in one go,
using CheckMATE for example or pythn scripts.

This is what ATLAS and CMS have been doing.

Best  regards
Alexander

On 10/11/2025 10:35, danielle moore wrote:
> CAUTION: This e-mail originated outside the University of Southampton.
>
> Question #822831 on HEPMDB changed:
> https://answers.launchpad.net/hepmdb/+question/822831
>
> danielle moore posted a new comment:
> The core issue is a **syntax mismatch** where the LanHEP code, which
> uses the suffix **`.t`** (likely representing a field strength tensor or
> contracted field) in terms like `'GX_S.t'`, is incorrectly translated
> into the UFO's Python code, resulting in an `AttributeError` because the
> particle object **`P.GX_S` has no attribute `.t`**. Manually removing
> `.t` causes a **critical warning** about "non-QCD emission of gluon"
> because the resulting vertices lack the necessary **Lorentz structure**.
> To resolve this, you must either find the correct LanHEP syntax for
> contracted fields that translates properly to UFO, or switch to using
> **FeynRules** to generate a more robust UFO model that correctly defines
> these complex gauge interactions, allowing for reliable collider
> studies. https://www.ez-passva.com/
>
> --
> You received this question notification because your team hepmdb is an
> answer contact for HEPMDB.

--
................................
Professor Alexander S Belyaev
https://www.soton.ac.uk/~ab1u06
.......
Physics & Astronomy 46/5047
University of Southampton
Southampton SO171BJ
................................

Dear Prof. Belyaev,

I would love to know how one can generate the root files with CheckMATE using LHE files generated from CalcHEP, as I am new to CheckMATE.

With regards,
Debabrata Sahoo

Lets take this off this thread -- please write to me at
<email address hidden>
Best
Alexander

On 10/11/2025 13:20, Debabrata Sahoo wrote:
> CAUTION: This e-mail originated outside the University of Southampton.
>
> Question #822831 on HEPMDB changed:
> https://answers.launchpad.net/hepmdb/+question/822831
>
> Debabrata Sahoo posted a new comment:
> Dear Prof. Belyaev,
>
> I would love to know how one can generate the root files with CheckMATE
> using LHE files generated from CalcHEP, as I am new to CheckMATE.
>
> With regards,
> Debabrata Sahoo
>
> --
> You received this question notification because your team hepmdb is an
> answer contact for HEPMDB.

--
................................
Professor Alexander S Belyaev
https://www.soton.ac.uk/~ab1u06
.......
Physics & Astronomy 46/5047
University of Southampton
Southampton SO171BJ
................................