Higgs-to-Higgs Cascade

Asked by Jonas Wittbrodt

Dear Madgraph Team,

we are trying to generate cascade decays of BSM Higgs bosons in a singlet extension (called the TRSM, see 1908.08554). The model contains three CP-even scalars and we are interested in the p p -> h125 -> h1 h2 -> h1 h1 h1 decay chain, where h125 denotes the SM-like Higgs boson.

I generated a UFO for the model with Feynrules (can be found here https://desycloud.desy.de/index.php/s/tj9mqeWoZDrAWQK) that includes heft higgs gluon couplings. I can run the following and get reasonable results:

import model TRSM
generate p p > h3 > h1 h2
launch
set mh1 20
set mh2 60
set decay 25 auto
set decay 35 auto
set decay 36 auto

(where h1=25, h2=35, h3=36 and mh3=125 by default) yielding a cxn of ~0.37. For this parameter point the BR(h2->h1 h1) is essentially 1 and madgraph correctly calculates it to be 9.999389e-1. Using madspin to do the decay

import model TRSM
generate p p > h3 > h1 h2
launch
madspin=ON
set mh1 20
set mh2 60
set decay 25 auto
set decay 35 auto
set decay 36 auto
set spinmode none
decay h2 > h1 h1

works as expected and gives essentially the identical cxn ~0.37. So far so good, if I instead use madgraph to do the decay

import model TRSM
generate p p > h3 > h1 h2, h2 > h1 h1
launch
set mh1 20
set mh2 60
set decay 25 auto
set decay 35 auto
set decay 36 auto

I get a cross section that is smaller by several orders of magnitude ~0.00078. I tried explicitly disabling cuts for h1 by setting {25: 0} = pt_min_pdg, cut_decays is False anyway, and massively increasing bwcutoff had no relevant impact on the result. Note that the width of both h3 and h2 is pretty small (few MeV), so the narrow width approximation should be very good.

I am lost to what is happening here, any help would be appreciated.
Thanks,
Jonas

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
Last query:
Last reply:
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#1

Which version of MG5aMC are you using?
Very small width are very difficult to integrate correctly and a special trick was put in place in recent version of the code. So I would need to know if your version has that method implemented or not.

Cheers,

Olivier

> On 12 Sep 2019, at 18:03, Jonas Wittbrodt <email address hidden> wrote:
>
> New question #683879 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/683879
>
> Dear Madgraph Team,
>
> we are trying to generate cascade decays of BSM Higgs bosons in a singlet extension (called the TRSM, see 1908.08554). The model contains three CP-even scalars and we are interested in the p p -> h125 -> h1 h2 -> h1 h1 h1 decay chain, where h125 denotes the SM-like Higgs boson.
>
> I generated a UFO for the model with Feynrules (can be found here https://desycloud.desy.de/index.php/s/tj9mqeWoZDrAWQK) that includes heft higgs gluon couplings. I can run the following and get reasonable results:
>
> import model TRSM
> generate p p > h3 > h1 h2
> launch
> set mh1 20
> set mh2 60
> set decay 25 auto
> set decay 35 auto
> set decay 36 auto
>
> (where h1=25, h2=35, h3=36 and mh3=125 by default) yielding a cxn of ~0.37. For this parameter point the BR(h2->h1 h1) is essentially 1 and madgraph correctly calculates it to be 9.999389e-1. Using madspin to do the decay
>
> import model TRSM
> generate p p > h3 > h1 h2
> launch
> madspin=ON
> set mh1 20
> set mh2 60
> set decay 25 auto
> set decay 35 auto
> set decay 36 auto
> set spinmode none
> decay h2 > h1 h1
>
> works as expected and gives essentially the identical cxn ~0.37. So far so good, if I instead use madgraph to do the decay
>
> import model TRSM
> generate p p > h3 > h1 h2, h2 > h1 h1
> launch
> set mh1 20
> set mh2 60
> set decay 25 auto
> set decay 35 auto
> set decay 36 auto
>
> I get a cross section that is smaller by several orders of magnitude ~0.00078. I tried explicitly disabling cuts for h1 by setting {25: 0} = pt_min_pdg, cut_decays is False anyway, and massively increasing bwcutoff had no relevant impact on the result. Note that the width of both h3 and h2 is pretty small (few MeV), so the narrow width approximation should be very good.
>
> I am lost to what is happening here, any help would be appreciated.
> Thanks,
> Jonas
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Rickard Stroem (lstroem) said :
#2

Dear Olivier,

Thanks for taking a look!
We're using MG5aMC v2.6.5

Best,
Rickard

Revision history for this message
Rickard Stroem (lstroem) said :
#3

Dear Olivier,

What version would be more suitable in this case?

Best,
Rickard

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) said :
#4

Hi,

I have reproduce this effect and I do not understand it. I will need more time to understand what's going on.

Cheers,

Olivier

Revision history for this message
Rickard Stroem (lstroem) said :
#5

Ok, thanks for looking into it!

Revision history for this message
Best Olivier Mattelaer (olivier-mattelaer) said :
#6

Looks like that you have two interactions with h2 > h1 h1 one tagged as QED=1 and one as QED=2
however the one that seems to dominate here is the one with QED=2 (which seems to indicate that you have some perturbative issue in your model).

So you need to force the code to include contributions that are neglected by default, i.e you should use the following syntax:
generate p p > h3 > h1 h2 QED<=99 , h2 > h1 h1 QED<=2

Cheers,

Olivier

PS: It would also make more sense that the PDG code with value 25 is assign to the standard model higgs to avoid issue with Pythia/detector simulation

Revision history for this message
Jonas Wittbrodt (nandurius) said :
#7

Dear Olivier,

thanks a ton for looking into it. There was a mistake in the model file, with the corrected QED=-1 assignment for the singlet vevs everything works as expected.

Cheers,
Jonas

Revision history for this message
Jonas Wittbrodt (nandurius) said :
#8

Thanks Olivier Mattelaer, that solved my question.