MadGraph5_aMC@NLO

assumptions about squark mixing?

Asked by Matthew Reece

In MG4 I understood what was expected in an SLHA file and what assumptions were being made: stops and sbottoms could mix, the other squarks didn't, and the blocks STOPMIX and SBOTMIX contained the mixings. It wasn't as general as possible, but at least the assumptions were very clear.

In MG5, I'm confused about what assumptions are being made. I thought the full USQMIX block defined in 0801.1800, which relates the basis (u_L, c_L, t_L, u_R, c_L, t_R) to a mass-ordered basis of all up-type squarks (and the analogous thing for down-type squarks) was being used. However, in parameters.py, it looks like only a subset of the mixing angles (RRu13, RRu16, RRu23, RRu26, RRu35, RRu44, RRu51, and RRu62) are defined, so I think implicitly the same assumption is being made that only the stops are mixing. Also, I'm confused about the ordering; 0801.1800 says that USQMIX maps the gauge/flavor eigenstate basis to a basis that is "mass-ordered," which I take to mean that, e.g., if stop1 and stop2 are lightest they are assigned codes 1000002 and 1000004, independent of the old conventions for flavor labeling, whereas if they are heaviest they are assigned codes 2000004 and 2000006. However, that looks inconsistent with the apparent assumption being made in parameters.py that the mixed states are #1 and #2 (which are mixtures of 3 and 6 in the gauge/flavor basis, i.e. of stop_L and stop_R) -- this would only be mass-ordered if the stops are the lightest.

This confusion is compounded by the relabeling of su1, su2, ... su6 as ul, cl, ... t2 defined in input/particles_name_default.txt.

Is there some documentation of the precise assumptions being made in the MG5 code? If the goal really is to read the full USQMIX matrix, then shouldn't there be parameter definitions for RRu11, RRu12, and so on? Or maybe I've just misread the code and it's more general than it appears to be at first glance.

Thanks for any help clearing up my confusion on this point.

Best regards,

Matt

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Johan Alwall
Solved:
Last query:
Last reply:
Revision history for this message
Best Johan Alwall (johan-alwall) said : 		#1

Hi Matt,

The MSSM model in MG5 is (almost) completely equivalent to the one in MG4, i.e. is a restricted version of the full MSSM. The param_card is of the SLHA2 form, but is in fact also equivalent to an SLHA1 card. You can download the full MSSM model from the FeynRules wiki page, but this model has enormous numbers of interactions which gives numerous spurious diagrams, if you are only interested in CMSSM-type models (no CPV, RPV, light generation mixing, etc). If you need these extra features, then of course the full model is necessary. You can make custom restrictions both in FeynRules and MG5 to minimize process generation and event generation time for your particular needs.

In a future version of MG5 (which should be out in a couple of weeks or so) we have a card converter so you can feed MadEvent with an SLHAI card also for the UFO MSSM model in MG5.

Hope this answers your question,
Johan

Revision history for this message
Matthew Reece (mreece) said : 		#2

Hi Johan,

Thanks for the prompt reply; I think you've pretty much answered my question. So, my understanding is that despite the SLHA2 convention that the basis used is mass-ordered, the way MG5 is using the files is to keep the stops in 1000006 and 2000006, consistent with your "t1" and "t2" naming conventions.

Also, above I listed the wrong set of RRu variables that are defined to be nonzero -- that was the list I extracted from the FeynRules RPV model, which chooses a *different* convention for where to put the stops. But I guess that's an entirely different issue. I guess the bottom line is that SLHA2 files for "restricted" MSSM parameter spaces don't really have a universal format.

Best regards,
Matt

Revision history for this message
Matthew Reece (mreece) said : 		#3

Thanks Johan Alwall, that solved my question.