BR and madspin decay

Asked by Shubhani Jain on 2021-04-07

Hi

I am trying to generate events for process gg<H<hh<bbbb, with commands, generate gg<H<hh [QCD] using 2hdmtII_nlo and then decaying h to bb using madspin. Before I was getting a very small cross-section after madspin decay, so now I am specifying the decay widths and BR in the parameter card :

DECAY 25 4.22511644e-03 # Wh1
 # BR NDA ID1 ID2
       6.06491310e-01 2 5 -5
DECAY 35 1.17027585e+01 # Wh2
# BR NDA ID1 ID2
       3.97585905e-03 2 25 25

The cross-section seems to be in the magnitude we expect it to be if we calculate sigma(gg>H)*BR(H>hh)*BR(h>bb)^2. But during madspin run I get an error

CRITICAL: Branching ratio larger than one for 25

What could be the reason behind that, do I need to define the BRs in some other format>

Any help would be much appreciated.

Thanks
Shubhani

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

Hi,

Is this a NLO computation or a LO (loop-induced) computation?

If this is the first, then I guess that you are using the default mode of madspin, while if in the second, I guess that you are in spinmode=non.

When using the spinmode=none,
MadSpin request MadEvent to generate events for the decay process (in your case h > b b~), at the same time as generating events, MadEvent will compute the partial-width associated to that decay. The Branching ratio used is then
partial-width divided by full width.
If that branching ratio is larger than one, it means that you have an issue in your benchmark and I would expect such type of warning.

Cheers,

Olivier

> On 7 Apr 2021, at 09:50, Shubhani Jain <email address hidden> wrote:
>
> New question #696423 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/696423
>
> Hi
>
> I am trying to generate events for process gg<H<hh<bbbb, with commands, generate gg<H<hh [QCD] using 2hdmtII_nlo and then decaying h to bb using madspin. Before I was getting a very small cross-section after madspin decay, so now I am specifying the decay widths and BR in the parameter card :
>
> DECAY 25 4.22511644e-03 # Wh1
> # BR NDA ID1 ID2
> 6.06491310e-01 2 5 -5
> DECAY 35 1.17027585e+01 # Wh2
> # BR NDA ID1 ID2
> 3.97585905e-03 2 25 25
>
> The cross-section seems to be in the magnitude we expect it to be if we calculate sigma(gg>H)*BR(H>hh)*BR(h>bb)^2. But during madspin run I get an error
>
> CRITICAL: Branching ratio larger than one for 25
>
> What could be the reason behind that, do I need to define the BRs in some other format>
>
> Any help would be much appreciated.
>
> Thanks
> Shubhani
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Shubhani Jain (s2697661) said :
#2

Hi Olivier

I am using spinmode=none for the computation. Okay, then do I need to specify decay width for others as well for example
###################################
## INFORMATION FOR DECAY
###################################
DECAY 6 1.508336e+00 # WT
DECAY 23 2.495200e+00 # WZ
DECAY 24 2.085000e+00 # WW
DECAY 25 1.000000e+00 # Wh1
DECAY 35 1.000000e+00 # Wh2
DECAY 36 1.000000e+00 # Wh3
DECAY 37 1.000000e+00 # whc

Because at present I am only specifying decay for and BR 25, 35 pdg code . Will that help the problem or changing to more suitable benchmark is the key?

Regards
Shubhani

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

Hi,

For the moment you width for 25 is likely completely wrong since your total width is smaller than the partial width for h > b b~
I doubt that changing the width of the rest of the particles will fix that but I do not know your model and how the Higgs couple to the b quark in your model.

My suggestions will be to set all those widths to “Auto” such that we will use that paper to compute the total width: 1402.1178 <https://arxiv.org/abs/1402.1178>
I typically do not advise to use that mode for the Higgs since it does not include loop-induced decay of the Higgs and therefore under-estimate that total width.
But I guess that this is not an issue in your case (looking at your BR that you were setting)

Cheers,

Olivier

> On 7 Apr 2021, at 10:11, Shubhani Jain <email address hidden> wrote:
>
> Question #696423 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/696423
>
> Shubhani Jain posted a new comment:
> Hi Olivier
>
> I am using spinmode=none for the computation. Okay, then do I need to specify decay width for others as well for example
> ###################################
> ## INFORMATION FOR DECAY
> ###################################
> DECAY 6 1.508336e+00 # WT
> DECAY 23 2.495200e+00 # WZ
> DECAY 24 2.085000e+00 # WW
> DECAY 25 1.000000e+00 # Wh1
> DECAY 35 1.000000e+00 # Wh2
> DECAY 36 1.000000e+00 # Wh3
> DECAY 37 1.000000e+00 # whc
>
> Because at present I am only specifying decay for and BR 25, 35 pdg code
> . Will that help the problem or changing to more suitable benchmark is
> the key?
>
> Regards
> Shubhani
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Shubhani Jain (s2697661) said :
#4

Hi

I am using these :

DECAY 25 4.22511644e-03 # Wh1
 # BR NDA ID1 ID2
       6.06491310e-01 2 5 -5
DECAY 35 1.17027585e+01 # Wh2
# BR NDA ID1 ID2
       3.97585905e-03 2 25 25

And the model we use is 2HDMtII_nlo. But I will try your suggestion and see if it works for us.

Thanks
Shubhani

Revision history for this message
Shubhani Jain (s2697661) said :
#5

Also, this is from the benchmark file we get from 2HDMC run interfaced with HiggsBounds and HiggsSignal:

Decay table for h
Total width: 4.225e-03 GeV BR
h -> s s 9.371e-07 2.218e-04
h -> c c 1.223e-04 2.894e-02
h -> b b 2.562e-03 6.065e-01
h -> e e 2.052e-11 4.856e-09
h -> mu mu 8.772e-07 2.076e-04
h -> ta ta 2.478e-04 5.865e-02
h -> ga ga 9.241e-06 2.187e-03
h -> Z Z 1.055e-04 2.496e-02
h -> W+ W- 8.442e-04 1.998e-01
h -> Z ga 6.215e-06 1.471e-03
h -> g g 3.256e-04 7.706e-02
---------------------------------------

Decay table for H
Total width: 1.170e+01 GeV BR
H -> s s 8.780e-06 7.502e-07
H -> c c 2.091e-04 1.787e-05
H -> b b 2.494e-02 2.131e-03
H -> t t 1.157e+01 9.890e-01
H -> e e 2.750e-10 2.350e-11
H -> mu mu 1.176e-05 1.005e-06
H -> ta ta 3.325e-03 2.841e-04
H -> ga ga 7.222e-05 6.172e-06
H -> Z Z 9.959e-03 8.510e-04
H -> W+ W- 2.041e-02 1.744e-03
H -> Z ga 2.575e-05 2.200e-06
H -> g g 2.378e-02 2.032e-03
H -> h h 4.653e-02 3.976e-03
H -> W+ H- 4.179e-06 3.571e-07
H -> H+ W- 4.179e-06 3.571e-07

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

I guess that the auto-width computation will not agree on those number neither a full madevent computation
(generate h > all all)

You will need to understand why they did not agree (I would bet a problem of benchmark or maybe of scale)

Cheers,

Olivier

Revision history for this message
Shubhani Jain (s2697661) said :
#7

Thanks for the help, maybe worth trying to use the new benchmark and see if we still have the same problem.

Regards
Shubhani

Revision history for this message
Shubhani Jain (s2697661) said :
#8

Thanks Olivier Mattelaer, that solved my question.