Madspin: Higgs decay - Branching ratio larger than one for 25

Asked by Luis Felipe Coelho on 2019-10-12

I'm trying to generate the process p p > h h [QCD] and let one Higgs decay into two photons (h > a a) and the other into one bottom and one anti-bottom (h > b b~) with MadSpin. I'm able to run the process but I get this warning: "CRITICAL: Branching ratio larger than one for 25".
I'm using the model loop_qcd_qed_sm-with_b_mass and the following madspin_card.dat:

# MadSpin
# P. Artoisenet, R. Frederix, R. Rietkerk, O. Mattelaer
# Part of the MadGraph5_aMC@NLO Framework:
# The MadGraph5_aMC@NLO Development Team - Find us at
# Manual:
#Some options (uncomment to apply)
# set seed 1
# set Nevents_for_max_weigth 75 # number of events for the estimate of the max. weight
# set BW_cut 15 # cut on how far the particle can be off-shell
# set spinmode onshell # Use one of the madspin special mode
set spinmode none
set max_weight_ps_point 400 # number of PS to estimate the maximum for each event

import model loop_qcd_qed_sm-with_b_mass

# specify the decay for the final state particles
decay t > w+ b, w+ > all all
decay t > w- b, w- > all all
decay w+ > all all
decay w- > all all
decay z > all all
decay h > a a [noborn=QED]
decay h > b b~
# running the actual code

Could someone please let me know what I’m doing wrong?
Many thanks!


Question information

English Edit question
MadGraph5_aMC@NLO Edit question
No assignee Edit question
Solved by:
Hua-Sheng Shao
Last query:
Last reply:

This question was reopened


In this mode the BR is computed as the ratio of the width computed via the decay syntax (computed by MadEvent --standard LO phase-space integration without any cut--)
and the one that you put in your param_card. (which should be the total one).

So one possiblity is that you put a too small width. (or that the mass of the b is not the same in the various model and that it leads to a BR larger than one.

With the model
import model loop_qcd_qed_sm-with_b_mass
h> b b~ is given at
  === Results Summary for run: run_01 tag: tag_1 ===

     Width : 0.004744 +- 9.318e-12 GeV

While the default width for the higgs in the loop_sm
DECAY 25 6.382339e-03 # WH
So it should be ok

This being said the syntax
import model loop_qcd_qed_sm-with_b_mass
is not save since you have to specify a new benchmark point when using a new model.




Thank you for your response, but I am not sure if I understand

The default width for the Higgs in the model "loop_qcd_qed_sm-with_b_mass" in my parm.card is
DECAY 25 3.514960e-03 # WH and not 6.382339e-03

This value is smaller than 0.004744 (h> b b~ width)
Is this right?

Thank you,

So this is indeed your issue.
I will contact the author of the model to check if this small value was done on purpose or if they can change it in the model.



Best Hua-Sheng Shao (erdissshaw) said : #4


If you are using the model to do the EW corrections with version 3.X, the finite b mass is not supported yet. However, if you are only interested in LO or QCD corrections or loop-induced with the model, you can use the configuration (i.e. b mass).

The default Higgs width in the with_b_mass parameter card may be not optimal. You can update the correct numbers in the following ways:

1. just calculate LO width with MadWidth as Olivier said. It is correct in the sense that you sum all decay channels with MadSpin, you will get total branching ratio to be 1. However, for Higgs, many important channels may miss (e.g. the loop-induced channels H-> gg, or you set zero because of zero Yukawa coupling H->tau tau, H-> c cbar).

2. You can also use HDECAY to calculate it directly in MG5_aMC, which has been shipped in SMWidth package in version 3.X. The syntax is described in appendix E.3.2 in 1804.10017, i.e.

MG5_aMC> compute_widths h --nlo

It will give you a more precise total width. On contrast to item 1, if you let decay with MadSpin, you may have the sum of BRs =/= 1. You need to check it the impact yourself. (these values you can also see with simply 'import model loop_qcd_qed_sm').

3. Just take the number from the literature with the same setup or close setup. It will have the similar issue as the above item, i.e. the sum of BRs =/= 1.

If I check the LHCHXWG report (1101.0593) in Table 28, I see MH=125 GeV, the total width is 4.03e-3.

Thanks Hua-Sheng Shao, that solved my question.