Particle names not recognised when running MadSpin

Bug #1879639 reported by Luca Panizzi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Fix Released
Undecided
Unassigned

Bug Description

Hi,
I am running processes with the model dmsimpt_v1.2 (t-channel DM simplified models) and I am getting error messages when running MadSpin, not being able to recognise some particle names.

Specifically, after importing the model via the command

import model DMSimp_t-F3S_uR --modelname

and generating events for the process:

define yy = yf3u1 yf3u1~
define excl = yf3qu1 yf3qu2 yf3qu3 yf3qd1 yf3qd2 yf3qd3 yf3u2 yf3u3 yf\
3d1 yf3d2 yf3d3 ys3qu1 ys3qu2 ys3qu3 ys3qd1 ys3qd2 ys3qd3 ys3u1 ys3u2 \
ys3u3 ys3d1 ys3d2 ys3d3 xc xd xm xv xw a z
generate p p > yy yy DMT^2==2 / excl

Giving the following commands in the MadSpin card:
set spinmode none
decay yf3u1 > xs u
decay yf3u1~ > xs u~

MadSpin complains that it cannot recognise particles which share the same PDG code as SUSY particles (all the coloured scalar mediators) and returns this message:

Command "decay_events MY500_MX150 " interrupted with error:
InvalidCmd : No particle ys3qu1 in model

I have digged a bit into the MadGraph/MadSpin files and found that the following lines of the function do_import in madgraph_interface.py:

if '-modelname' not in args:
                self._curr_model.pass_particles_name_in_mg_default()

are applied and the above particles are not recognised anymore.

Indeed, the arguments of the function do not contain the string "--modelname"; if I print the args variable I obtain:

['model', '/home/panizzi/Research/MadGraph/MG5_aMC_v2_6_3_2/models/DMSimp_t-F3S_uR']

As a temporary workaround I have commented the previous lines, and MadSpin works. But I wonder why the arguments are not passed properly and what can be a better solution.

I am using MG v 2.6.3.2 but I could reproduce the same error with 2.6.7 and 2.7.2

Hope the information I provided help to reproduce the error, but let me know if you need cards or further info.

Thank you.
Luca

Revision history for this message
Luca Panizzi (lcpnzz) wrote :

I have included in the tarball the model file, the proc_card, run_card, param_card and madspin_card.

Notice that I rename the model when I copy it into the models folder of MG, so the model which is loaded in the proc_card is indeed the one I attached.

Revision history for this message
Luca Panizzi (lcpnzz) wrote :

Ah, I forgot to attach the debug log. Here it is

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi,

Sorry I can not reproduce such error even your model...
Commenting the line "madgraph_interface.py" should have no impact on madspin at all.

Are you sure that you have the exact same error in 2.7.2?
Could you maybe attach the debug file for that version?

Cheers,

Olivier

Revision history for this message
Luca Panizzi (lcpnzz) wrote :

Here is the debug file for version 2.7.2.

One more piece of information: if I do not set the gauge to Feynman before importing the model, MadSpin works in both versions of MG (2.6.3.2 and 2.7.2).

Cheers,
Luca

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi,

I have look with Benj but still fail to reproduce the issue.
Which version of python did you use?
Not sure that I will be to help here...

Cheers,

Olivier

Changed in mg5amcnlo:
status: New → Incomplete
Revision history for this message
Luca Panizzi (lcpnzz) wrote :

Hi Olivier,
I have Python 2.7.17. If needed we can chat on skype (my name is lcpnzz) and I can let you know how I identified the lines which, if commented in my system, make MadSpin work. I just tried to see what writes the arguments of the function which gives the error, and after writing some print statements I spotted those lines eventually.

Maybe this can help?

Thanks a lot,
Luca

Changed in mg5amcnlo:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.