RPV Susy diagrams are confusing

[kesterlester]

Out-of-the-box, Madgraph does not support R-Parity violating (RPV) supersymmetry. Nonetheless, it has the capacity to do so via addons, such as that found here:

https://feynrules.irmp.ucl.ac.be/wiki/RPVMSSM

I was playing with the UFO found at the above page, to allow madgraph to generate events in which one of the lambda-prime couplings was non-zero. Specifically I was using lambda-prime_{231} which should create (among other things) a vertex connecting:

    a LEFT-sumon, a top-quark, and a down quark.

That coupling should not create a vertex connecting:

    a RIGHT-smuon, a top-quark, and a down quark,

as may be seen from the LDQ Lagrangian terms shown in equation (A.54) on page 177 of https://arxiv.org/pdf/hep-ph/0101105v1.pdf -- the only charged slepton(s) this lagrangian contains feature are LEFT-sleptons.

I was therefore surprised when the "display diagrams" command in Madgraph (MG5_aMC_v2_4_3) drew for me diagrams including the reverse .... only RIGHT-sleptons (in this case smuons), and no LEFT-smuons!

I attach a screen grab of some of the diagrams it drew. The diagrams shown would be valid for my process if they said "mul-" instead of "mur-", etc. The same problem is seen in selectron diagrams, so I do not believe this drawing issue is related to the fact that the same UFO files happen to have fully off diagonal elements in the smuon parts of the 6-flavour slepton mixing matrix (effectively interchanging the meanings of PDF codes 1000013 and 2000013 when setting sparticle masses) since the same is not true for the selectron sector.

It is not clear to me whether this behaviour is (1) the fault of madgraph, or (2) is a fault in the example RPV UFO file available from the above link, or (3) is not really a fault at all, but rather a manifestation of a perverse desire to label diagrams according to some convention I have not heard of [e.g. it could be intended that "mur-" should mean "the Left-smuon component of the 5th lightest slepton state, while "mul-" should mean "the Left-smuon component of the second lightest smuon state", since in 6-favour mixing models the slepton pdg codes are re-used to indicate masses rather than flavours. However I don't believe that is what is happening here. ]

Regardless of the cause, the effect will be confusing for many people, as it was confusing for me, so it may be something that someone wishes to give some consideration to fixing.

P.S. I have reason to believe that the bug affects only the DRAWN diagrams, not the actual calculations and events that madgraph made. These seem to accurately reflect the intended input files.

[Valentin Hirschi (valentin-hirschi)]

First of all, I have to stress a detail about naming convention for MSSM models.
As you can see in the 'particles.py' file of the UFO model you are using, the particle names are different there and reflect the group structure of your model.

However, by default MG5aMC will change the name of SUSY particles to conventional ones, following PDG-name association rules in the file <MG5DIR>/input/particles_name_default.txt.
You can see there the following:

 1000013 mul-
-1000013 mul+
 2000013 mur-
-2000013 mur+

(Notice that you can prevent MG5aMC from applying this naming translation rules by importing the model with the option --modelname).
This means that 'mul-' and 'mur-' really correspond to the following original particles in the RPV UFO model:

sl2__minus__ = Particle(pdg_code = 1000013,
                        name = 'sl2-',
                        antiname = 'sl2+',
                        [...]
and

sl5__minus__ = Particle(pdg_code = 2000013,
                        name = 'sl5-',
                        antiname = 'sl5+',
                        [...]
Now the interactions of these particles with the muons are:
(you can type 'display interactions sl2- mu- in MG5aMC after having loaded the model to see all interactions involving these two particles):

MG5_aMC>display interactions sl2- mu+
597 : mu+ n1 sl2-
603 : mu+ n2 sl2-
609 : mu+ n3 sl2-
615 : mu+ n4 sl2-
700 : ve~ mu+ sl2-
704 : vt~ mu+ sl2-

and for sl5- (labelled mur-):

MG5_aMC>display interactions sl5- mu+
598 : mu+ n1 sl5-
604 : mu+ n2 sl5-
610 : mu+ n3 sl5-
616 : mu+ n4 sl5-
635 : mu+ ve sl5-
652 : mu+ vt sl5-

So, as you can see it seems that indeed both mur- and mul- couple to the muon (the swap in the muon sign is just because in this display all particles are considered incoming).

Now this is of course with the default values of the mixing parameters for this model.
So I suggest that you create a restrict card in your UFO model where you set the parameters to your desired value and then really double check with the above commands that you still have the offending vertex you mentioned.
You can create a restrict card by copying a parameter card in this UFO model directory (or creating one by typing 'python write_card.py' in the UFO model) and renaming it 'restrict_myRestrictName.dat'.
You can then load the model with
'import model RPVMSSM_UFO-myRestrictName'
And all interactions whose coupling are zero will be automatically removed.

Hopefully, with the information above you can check and understand if your model imported in MG5aMC really has the offending vertex.