MadGraph5_aMC@NLO

Wrong cross-sections for Monotop model in Madgraph 5 version 1.5.5

Asked by Timothée Theveneaux-Pelzer

Hello,

I am currently working on the Monotop effective theory which has been implemented in Feynrules: http://feynrules.irmp.ucl.ac.be/wiki/Monotops .
As a first step of my analysis, I am trying to reproduce the results given in that page, in particular the total cross-sections obtained for the 5 scenarios for LHC pp collisions.
I noticed that the 5 .lhe files give all the needed Cards, so for each scenario I retrived the parameters in the param_card and I use the given proc_card to edit mine.
To obtain the total cross-section, I drop all cuts in the run_card, and I do not specify the t quark decay channel in proc_card.

My problem is that I do not obtain the same cross-section values as the ones given in the model wiki page for scenario 1 and 2, which are the cases in which a resonance is produced.
For Scenario 1, my value is 5.308e-09 pb while it should be 5.521 pb (so 9 orders of magnitude less).
For Scenario 2, my value is 5.596 pb while it should be 56.14 pb (so 1 order of magnitude less).
In these 2 cases there is a warning saying that some sub-processes do not have available phase-space; I have carefully checked the mass spectrum and it matches exactly with the parameters given in the .lhe files from the wiki page.

For Scenario 3, my value is 0.9052 pb which matches the value of 0.903 pb given in the wiki page.
For Scenario 4, my value is 148.1 pb which matches the value of 148.6 pb given in the wiki page.
In these 2 scenarios no heavy resonance is produced.

Last, for Scenario 5, my value is 6.009e-07 pb while it should be 1.514e-04. In this case a heavy resonance is produced.

The problem may be due to the different Madgraph versions: the .lhe files given in the twiki were generated with version 1.3.1 of Madgraph 5 while I use the latest 1.5.5.
For instance, in the run_card I have let the default vaules for the parameters "auto_ptj_mjj" (F) "cut_decays" (T) and "nhel" (0) which were apparently not asked for in Madgraph 5 1.3.1's run_card files.

So, I am a bit puzzled. The fact that I have the same results for scenarii 3 and 4 tends to make me thinks that the implementation of the model is ok, but that some additional parameters are needed for the perhaps more exotic Scenarii 1,2 and 3.

Thanks in advance for your help!

Cheers,
Timothée

Question information

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

Hello Timothée,

Can you please send me the UFO files? I can't seem to download them from the FR website. My email is jalwall_at_ntu.edu.tw.

Thanks,
Johan

Revision history for this message
Timothée Theveneaux-Pelzer (tpelzer) said : 		#2

Hello again,

I have sent you the UFO files.

In addition I must report a bug which occurs when I apply the kinematic cuts defined in the wiki page of the model, for the Scenario 5. The cuts are:
    * deltaR(jet,jet) > 0.5
    * eta(jet) < 2.5
    * pt(jet) > 50 GeV

In that case, the generation crashes with the following error message:
Command "generate_events " interrupted in sub-command:
"generate_events" with error:
MadEventError : Error detected Stop running: Error: failed to reduce to color indices: 0 0

It does not happens if the pt(jet) cut is lowered at 40 or 45 GeV, or with pt(jet) > 50 GeV but without any cut on eta(jet) (I tested several combinaisons).

This seems very strange to me, so I submit a bug report.

Cheers,
Timothée

Revision history for this message
Johan Alwall (johan-alwall) said : 		#3

Hello Timothée,

When I run with the cards from the banner (header) of the Scenario 1 event file, and simply change the process definition to
generate d~ s~ > t fmet MT1=0 MT2=0 MT3=2 MT4=0
add process s~ d~ > t fmet MT1=0 MT2=0 MT3=2 MT4=0
add process d s > t~ fmet MT1=0 MT2=0 MT3=2 MT4=0
add process s d > t~ fmet MT1=0 MT2=0 MT3=2 MT4=0
(using the unchanged UFO model from the FR wiki, apart from fixing the color assignment problem as indicated in the bug response), I get perfect agreement with the numbers quoted:
Cross section with decays and cuts: 0.3682 ± 0.0011
Cross section without top decay: 5.523 ± 0.0026
This is with the latest version of MG5, v. 1.5.5, but that shouldn't make any difference.

I would guess that the problem is in how you edited the model parameters in the UFO files.

All the best,
Johan

Revision history for this message
Timothée Theveneaux-Pelzer (tpelzer) said : 		#4

Hello Johan,

Fixing the color assignement solved the problem for Scenarii I and V; I did only change the masses and width of the particles from the UFO model.
Now I obtain the right cross-sections with or without cuts and top decay.
However, for Scenario II I still have cross-sections 10 times lower than expected. In this scenario none of the particles which had a wrong color assignement (9000004 or 9000006) is produced, only 9000005 (for which I don't see any obvious mistake).

Cheers,
Timothée

Revision history for this message
Best Benjamin Fuks (fuks) said : 		#5

Hello Timothee,

I have updated the monotop UFO files on the FeynRules webpage using the latest version of the UFO interface. As Johan, I am reproducing the good old numbers without any problem (for scenario I) with the latest version of MadGraph. I think that the issue might be related to your way to modify the model parameters so that at the end you are comparing apples with pears.

Cheers,

Benjamin

Revision history for this message
Timothée Theveneaux-Pelzer (tpelzer) said : 		#6

Hello Benjamin,

I solved my problem with Scenario 2 by putting the right widths for the BSM particles.
Now everything work perfectly fine.
By the way: I think the particles phic and tphic still have wrong color multiplicities in particles.py in the updated UFO files on the FeynRules webpage (1 instead of 3).

Thanks a lot for your help!

Cheers,
Timothée

Revision history for this message
Timothée Theveneaux-Pelzer (tpelzer) said : 		#7

Thanks Benjamin Fuks, that solved my question.

Revision history for this message
Benjamin Fuks (fuks) said : 		#8

I have once again uploaded the wrong file... Now it is really fixed... sorry about that.