The LO estimate for the width of particle 36 differs from the one in the banner by 52 percent

Asked by Khawla Jaffel on 2021-03-19

Hello experts,

Is it normal to have 52% difference between the computed width from madspin and the one i get from theory !
I set decay width for h3= id 36 to 1.727326 GeV : value i get from Sushi
The one i get from madspin is 3.641527 GeV

I don't have such warning when i set the width to "" Auto "" !

So, I don't which to trust the computation done by mg or the theory one, and why this difference is huge ?
I tried for different masses , i get 46 % !!!

will be reasonable to switch to Auto for my process which @NLO : p p > h2 > h3 Z b b~ [QCD]

here part of madpin output where i see the warning ...

set ms_dir ./madspingrid
set max_weight_ps_point 400 # number of PS to estimate the maximum for each event
decay h3 > b b~
decay z > l+ l-
launch
INFO: Will use seed 637106503
WARNING: set the mass of the b-quark to its value in the param_card.dat: 4.7 GeV
INFO: We need to recalculate the branching fractions for h3,z
INFO: using the FeynRules formula present in the model (arXiv:1402.1178)
WARNING: The LO estimate for the width of particle 36
WARNING: differs from the one in the banner by 52 percent
INFO:
INFO: decay channels for h3 : ( width = 3.641527 GeV )
INFO: BR d1 d2
INFO: 9.544697e-01 b~ b
INFO: 4.553027e-02 ta+ ta-
INFO: 4.620101e-22 a h1
INFO:
INFO:
INFO: decay channels for z : ( width = 2.412132 GeV )
INFO: BR d1 d2
INFO: 1.520426e-01 s~ s
INFO: 1.520426e-01 d~ d
INFO: 1.504006e-01 b~ b
INFO: 1.178035e-01 c~ c
INFO: 1.178035e-01 u~ u
INFO: 6.877077e-02 vt~ vt
INFO: 6.877077e-02 vm~ vm
INFO: 6.877077e-02 ve~ ve
INFO: 3.453168e-02 ta+ ta-
INFO: 3.453168e-02 mu+ mu-
INFO: 3.453168e-02 e+ e-
INFO:
INFO: generating the production square matrix element
INFO: generate p p > h2 > h3 Z b b~ @0 --no_warning=duplicate;define pert_QCD = -4 -3 -2 -1 1 2 3 4 21;add process p p > h2 > h3 Z b b~ pert_QCD @0 --no_warning=duplicate;
INFO: Done 66.34
INFO: generating the full matrix element squared (with decay)
INFO: generate p p > h2 > h3 Z b b~ , h3 > b b~ QCD=99, z > l+ l- QCD=99 @0 --no_warning=duplicate;define pert_QCD = -4 -3 -2 -1 1 2 3 4 21;add process p p > h2 > h3 Z b b~ pert_QCD , h3 > b b~ QCD=99, z > l+ l- QCD=99 @0 --no_warning=duplicate;
INFO: Done 72.14

I appreciate any feeback,

Cheers
Khawla

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2021-03-19
Last reply:
2021-03-22

From the log, the width are computed directly from analytical formula given by FeynRules.
So, you can check them by using the syntax
generate h2 > all all
output
launch
Which will be evaluated those numerically.

Now note that neither Feynrules (so the auto mode) or the syntax above will include loop-induced decay.

MadSpin is using the "auto" mode to compute the width automatically, so obviously those number will match with those of FeynRules.

Cheers,

Olivier

Khawla Jaffel (kjaffel) said : #2

Hello Olivier,

Thanks a lots for the fast replay !

So i checked with mg the width computed with FR as you suggested and this what i got !
import model 2HDMtII_NLO
generate h2> all all
output
launch

INFO: Idle: 13, Running: 0, Completed: 0 [ 0.22s ]
INFO: Idle: 13, Running: 0, Completed: 0 [ 0.47s ]
INFO: Idle: 6, Running: 0, Completed: 7 [ 1m 0s ]
INFO: All jobs finished
INFO: Idle: 0, Running: 0, Completed: 13 [ 2m 1s ]
INFO: Combining runs
INFO: finish refine
refine 10000 --treshold=0.9
No need for second refine due to stability of cross-section
INFO: Combining Events
  === Results Summary for run: run_01 tag: tag_1 ===

     Width : 0.007759 +- 1.501e-06 GeV
     Nb of events : 10000

store_events
INFO: Storing parton level results
INFO: End Parton
reweight -from_cards
decay_events -from_cards
INFO: storing files of previous run
INFO: Done
quit

i don't see any hint that the width have been re-computed in the param_card
please see more information in https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_FRwidth/index.html

An other cross check i did is to compute widths with Madwidth !

MG5_aMC>import model 2HDMtII_NLO
INFO: Change particles name to pass to MG5 convention
Kept definitions of multiparticles l- / j / vl / l+ / p / vl~ unchanged
Defined multiparticle all = g ghg ghg~ u c d s u~ c~ d~ s~ a gha gha~ ve vm vt e- mu- ta- ve~ vm~ vt~ e+ mu+ ta+ t b t~ b~ z w+ ghz ghwp ghwm h+ h1 h2 h3 w- ghz~ ghwp~ ghwm~ h-
MG5_aMC>
MG5_aMC>
MG5_aMC>
MG5_aMC>compute_widths all
Please note that the automatic computation of the width is
    only valid in narrow-width approximation and at tree-level.
INFO: Get two body decay from FeynRules formula
partial width of particle t lower than QCD scale:0.0410202637468. Set it to zero. ([37, 5])
Results written to /nfs/user/kjaffel/MG5_aMC_v2_7_3/models/2HDMtII_NLO/param_card.dat
INFO: get decay diagram for t
Vertexlist of this model has not been searched.Automatically run the model.find_vertexlist()
Found 5 stable particles
INFO: get decay diagram for z
INFO: get decay diagram for w+
INFO: get decay diagram for h1
INFO: get decay diagram for h2
INFO: get decay diagram for h3
INFO: get decay diagram for h+
Pass to numerical integration for computing the widths:
INFO: More info in temporary files:
    /nfs/user/kjaffel/MG5_aMC_v2_7_3/tmpwtpcr_/temp_decay/index.html
using cluster: slurm
INFO: compile directory
compile Source Directory
Using random number seed offset = 21
INFO: Running Survey
Creating Jobs
Working on SubProcesses
INFO: P0_hp_wpbxb
INFO: P0_h2_vtwmtap
INFO: P0_h2_wptamvtx
INFO: P0_h2_bzbx
INFO: P0_h2_uwmdx
INFO: P0_h2_wpdux
INFO: P0_h2_vewmep
INFO: P0_h2_wpemvex
INFO: P0_h2_dzdx
INFO: P0_h2_uzux
INFO: P0_hp_h1udx
INFO: P0_hp_h1veep
INFO: Idle: 2, Running: 4, Completed: 7 [ 0.22s ]
INFO: Idle: 2, Running: 4, Completed: 7 [ 0.47s ]
INFO: Job 24763249 Finally found the missing output.
INFO: Job 24763250 Finally found the missing output.
INFO: Job 24763251 Finally found the missing output.
INFO: Job 24763252 Finally found the missing output.
INFO: All jobs finished
INFO: Idle: 0, Running: 0, Completed: 13 [ 1m 0s ]
  === Results Summary for run: decay tag: tag_1 ===

     Width : 0.00202 +- 5.763e-06 GeV
     Nb of events : 0

INFO: End survey
INFO: Combining Events
WARNING: Order of particle in the event did not agree with parent/child order. This might be problematic for some code.
INFO: fail to reach target 10000
Results written to /nfs/user/kjaffel/MG5_aMC_v2_7_3/tmpwtpcr_/temp_decay/Events/decay/param_card.dat
INFO: storing files of previous run
INFO: Done
INFO:
Results written to https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_h3w_withMadWidth_param_card.dat

In both cases the Results Summary for the widths are different the first is 0.007 GeV and the later 0.002 GeV

>> Now note that neither Feynrules (so the auto mode) or the syntax above will include loop-induced decay.
yes my process is not loop induced here, it's b -associated production

Now, I still don't understand, if i am using Madspin why i see this log !
INFO: We need to recalculate the branching fractions for h3,z
INFO: using the FeynRules formula present in the model (arXiv:1402.1178)
I thought Madwith will be used for width computation and not Feynman-Rules !

Cheers,
Khawla

So the situation is the following:
if you do h2 > all all. you only get two body decay width (normal)
in that case you get 0.007759 GeV

if you use compute_width h2
Then you get two body decay width and three body decay width
in that case you get a width of 0.009276769
with the most important three body decay is
W j j contributing to a width of 4*0.00023404001436399995 GeV

If the BR information is missing in the param_card when using madspin, madspin will call the auto-width module with like this
compute_width h2 --body_decay=2
which assume that three body decay are not important (MadSpin can not handle such type of decay so far)
But indeed in that case the width automatically computed is 0.007759 and you should get the warning if the total width included was 0.009276769

Cheers,

Olivier

Khawla Jaffel (kjaffel) said : #4

Hello,

Okay things become more clear to me, thanks for checking !

So I give in the param_card width 1.727326 GeV == > Sushi : width_in_the_banner
auto computed width for 2 body decay 3.641527 GeV == > madspin : recalculated_width

relative_diff=abs(recalculated_width-width_in_the_banner)/recalculated_width *100 ==> ~ 52 %

if madspin in auto computed width mode is only LO precision and does not include 3 body decay doesn't make sense to me to get 50 % difference comparing to theory !

But could a difference in bottom quark mass could bring such a difference in h3 width? in the end i am decaying h3 > b b ~ .
So the default value of mb in my UFO MODEL( 2HDMtII_NLO ) 4.7 GeV
and the value that Sushi is using : 4.41835327e+00 GeV

Cheers,
Khawla

Hi,

> But could a difference in bottom quark mass could bring such a difference in h3 width? in the end i am decaying h3 > b b ~ .
> So the default value of mb in my UFO MODEL( 2HDMtII_NLO ) 4.7 GeV
> and the value that Sushi is using : 4.41835327e+00 GeV

I guess that this is something that you can cross-check easily, do not forget to change the yukawa mass if that mass is separated from the pole mass in your model.

Cheers,

Olivier

> On 22 Mar 2021, at 11:45, Khawla Jaffel <email address hidden> wrote:
>
> Question #696148 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/696148
>
> Khawla Jaffel posted a new comment:
> Hello,
>
> Okay things become more clear to me, thanks for checking !
>
> So I give in the param_card width 1.727326 GeV == > Sushi : width_in_the_banner
> auto computed width for 2 body decay 3.641527 GeV == > madspin : recalculated_width
>
> relative_diff=abs(recalculated_width-
> width_in_the_banner)/recalculated_width *100 ==> ~ 52 %
>
> if madspin in auto computed width mode is only LO precision and does
> not include 3 body decay doesn't make sense to me to get 50 %
> difference comparing to theory !
>
> But could a difference in bottom quark mass could bring such a difference in h3 width? in the end i am decaying h3 > b b ~ .
> So the default value of mb in my UFO MODEL( 2HDMtII_NLO ) 4.7 GeV
> and the value that Sushi is using : 4.41835327e+00 GeV
>
> Cheers,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Can you help with this problem?

Provide an answer of your own, or ask Khawla Jaffel for more information if necessary.

To post a message you must log in.