Branching ratio in the param_card

Hi,

> In the case where I let MadSpin handle the BR computation, I can still see that Madspin includes other BR that are not in the decay chain, why ??

In order to compute a Branching ratio, one need to compute the ratio between two quantity
1) the partial width in the final state
2) the total width of the particle
In order to compute the total width of the particle, one need to sum all the partial width.
So since that information has been computed it is better to include it than thrash it away (and maybe recompute it later)

Secondly, MadSpin does not compute the Branching ratio but simply use the following paper/tool for such computation:
1402.1178 <https://arxiv.org/abs/1402.1178>. that tools has option to limit computation to two body (which Madspin does use) but not to limit to a given final state.

> But I don't want Madspin to compute the BR for me( since the width accordingly will be changed )!

Do remember that Narrow-width approximation should be valid for madspin to work.
If you want to change it because of NLO correction or due to missing contribution (three body/loop-induced) this is fine.
But if you want to do that to put an artificial small width, this is typically not good enough for MadSpin to work correctly.
(especially if you put a fake total-width, smaller than the real partial-width in which you decay)

> in that case, the total width should be the partial_width of h3 -> bb~ ??

No the total width should always be the total width.

Cheers,

Olivier

> On 12 May 2021, at 13:25, Khawla Jaffel <email address hidden> wrote:
>
> New question #697024 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/697024
>
> Dear experts,
>
> I have a question regarding the BR in the param_card.
> If my process pp > h2 > h3 Z [QCD]
> and I am interested only in the decay of h3 > b b~ and Z > l+ l-
> But I don't want Madspin to compute the BR for me( since the width accordingly will be changed )!
>
> In this case, do I need to add the full list of the BR in the param_card, or only the BR of ( h3 -> b b~ ) and the BR( Z -> l+ l- ) should be enough, Is this still right on a physical level?
>
>
>
> 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.75 GeV 
> INFO: We need to recalculate the branching fractions for h3,z
> INFO: using the FeynRules formula present in the model (arXiv:1402.1178)
> INFO:
> INFO: decay channels for h3 : ( width = 5.111729 GeV )
> INFO: BR d1 d2
> INFO: 8.672213e-01 b~ b
> INFO: 1.135230e-01 ta+ ta-
> INFO: 1.736779e-02 t~ t
> INFO: 1.887907e-03 z h1
> INFO: 7.171028e-21 a h1
> INFO:
> INFO:
> INFO: decay channels for z : ( width = 2.412048 GeV )
> INFO: BR d1 d2
> INFO: 1.520479e-01 s~ s
> INFO: 1.520479e-01 d~ d
> INFO: 1.503708e-01 b~ b
> INFO: 1.178076e-01 c~ c
> INFO: 1.178076e-01 u~ u
> INFO: 6.877319e-02 vt~ vt
> INFO: 6.877319e-02 vm~ vm
> INFO: 6.877319e-02 ve~ ve
> INFO: 3.453289e-02 ta+ ta-
> INFO: 3.453289e-02 mu+ mu-
> INFO: 3.453289e-02 e+ e-
>
> If the latest still right( ie. to add BR of the decay we are interested in only ), in that case, the total width should be the partial_width of h3 -> bb~ ??
>
> DECAY 36 4.822
> # BR NDA ID1 ID2 ...
> 8.672213e-01 2 5 -5 # 4.822
>
> Cheers,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

The problem we are actually trying to solve is that our resonances decay into final states that we are not interested in. For example, if we assume H->ZA where A>350 GeV then A starts decaying also to tt, which also gives bb in the final state but we can't reconstruct the mass from the 2 b jets. Similarly, we saw H->hh in the A->ZH case, so that the mbb instead of peaking at the mass of the H, it peaked at 125 GeV. While these decays are allowed we would like to not include them in our MC production.

Is there a way to do that?

Thanks a lot,

Agni

I do not see any issue here. Just specify the full width and either let the code to compute the branching ratio or provide them.

Hello Olivier,

Our concern about giving the full table is what you see in this plot actually :
https://cp3.irmp.ucl.ac.be/~kjaffel/forOlivier_different_param_card_issue/oslep_resolved_at_least_2bjets_genmbb_logy.png
We don't understand why the benchmarks (800,700) in cyan and (1000, 500) in green, do not pick at 700 GeV, 500 GeV respectively!

Another issue we face is a double pick in the di-bjets mass distribution(mbb) as you can see here in this plot: https://cp3.irmp.ucl.ac.be/~kjaffel/oslep_resolved_at_least_2bjets_genmbb_before_removing_h125_decay_logy.png

solved when we forbid SM higgs from decaying to bb~ : https://cp3.irmp.ucl.ac.be/~kjaffel/oslep_resolved_at_least_2bjets_genmbb_logy.png
By adding '25:mayDecay = false' flag to pythia8 fragment when generating events;
        processParameters = cms.vstring(
                'Higgs:useBSM = on',# allow BSM Higgs production
                '25:mayDecay = false',
                '36:onMode = off' , # turn off all h3 decays
                '36:onIfMatch = 35 23', # turn on only h3 to h2 Z
                '36:isResonance = true',
                '36:doForceWidth = on',
                '35:onMode = off' , # turn off all h2 decays
                '35:onIfAny = 5', # turn on only h2 to b b~
                '35:isResonance = true',
                '35:doForceWidth = on', )

Those 2 issues you see in the plots are the main reason why I want to know what the additional decay in the BR table does when generating events?
according to your answer, they contribute only to the total width, and having them or not won't change anything as far as the total width is right and the BR of the decay chain we are interested in is there in the param_card!

>>Secondly, MadSpin does not compute the Branching ratio but simply use the following paper/tool for such computation:
>>1402.1178 <https://arxiv.org/abs/1402.1178>. that tools have the option to limit computation to two body (which Madspin does use) >>but not to limit to a given final state.
That's true I should use the term Madwidth instead, and actually, in the table below we get for the benchmark (800, 700) using the command from the paper you pointed:

import model 2HDMtII_NLO
compute_widths 35 36 --path=./param_card.date --output=./param_card.dat --body_decay=2
then we see the decay that contributes to the total width of 35 and 36 and then we modify them with the values given by 2HDMCalculator.

# PDG Width
DECAY 35 1.188000e+01
# BR NDA ID1 ID2 ...
   9.865000e-01 2 6 -6 # 1.17200000000e+01
   7.569000e-03 2 25 25 # 8.99400000000e-02
   2.303000e-03 2 5 -5 # 2.73700000000e-02
   8.595000e-04 2 -24 24 # 1.02100000000e-02
   4.191000e-04 2 23 23 # 4.98000000000e-03
   2.783000e-04 2 15 -15 # 3.30700000000e-03
   6.322000e-06 2 22 22 # 7.51200000000e-05
#
# PDG Width
#
# PDG Width
DECAY 36 1.768000e+01
# BR NDA ID1 ID2 ...
   9.867000e-01 2 6 -6 # 1.74400000000e+01
   8.414000e-03 2 35 23 # 1.48800000000e-01
   1.728000e-03 2 5 -5 # 3.05500000000e-02
   8.459000e-04 2 25 23 # 1.49600000000e-02
   2.110000e-04 2 15 -15 # 3.73000000000e-03
   3.349173e-18 2 22 35 # 6.36110936293e-17
   1.134516e-21 2 22 25 # 2.15479473659e-20

you can see here that the top contribution to the total width is not negligible in the same for SM Higgs and we were wondering if the reason for having a shifted pic for this benchmark is that because the 35 > t t~ have a non-neglibe BR and we lost these decay when we turn all decay off: '35:onMode = off' and then we ask for '35:onIfAny = 5' .
then this doesn't make sense to me anymore, because I thought if the contribution that you see in the table above it was just needed to sum over all the partial width, not allowing them to decay shouldn't my distribution!

>>Do remember that Narrow-width approximation should be valid for madspin to work.
>>If you want to change it because of NLO correction or due to missing contribution (three body/loop-induced) this is fine.
>>But if you want to do that to put an artificial small width, this is typically not good enough for MadSpin to work correctly.
>>(especially if you put a fake total-width, smaller than the real partial-width in which you decay)

yes, I am aware and I totally agree! What I don't agree about is the FR given by the UFO model to Madwidth in order to compute the partial widths.
From my perspective, I see that 2HDMC does much better when comes to couplings, alpha_s corrections, resummation of the leading logarithmic corrections is implemented to all orders by using the running MS fermion masses in the Higgs couplings ...
Please have a look at my slides n. 13, 14, and 15 ! https://docs.google.com/presentation/d/1QerE-qiOYURpwiDfKjvG1zSS0GBuFmVmCXgw74Ctes4/edit#slide=id.p
When I let the code re-compute the width when no BRs are provided! The width is much larger than we expect, larger by a factor of 97 % and 54 % difference in most cases!
In any way to avoid any confusion, the decay here in pythia8 and not in M

Very much appreciated it if you share your thoughts/comments with us!

Khawla

Does your model contains a decays.py file?
If so the two body decay computation is done by FeynRules if that's the case, you should be able to cross-check the total width easily via madgraph by either removing that file and/or
by running
generate 35 > all all
output
launch

I guess here you have to understand why 2HDMC and MadWidth are so different. Is this a problem of the model (and then you should not use that one) or a problem that 2HDMC does not compute such width correctly. What is the BR to top in 2HDMC?

Cheers,

Olivier

Hello Olivier,

>> Does your model contains a decays.py file?
Yes.

I checked the total width and this what I get :
############################################################################
Creating Jobs
INFO: Refine results to 10000
INFO: Generating 10000.0 unweighted events.
INFO: Effective Luminosity 1020.99421604 pb^-1
INFO: need to improve 1 channel
- Current estimate of cross-section: 11.7532497359 +- 4.58014046569e-08
    P1_h2_aa
    P1_h2_az
    P1_h2_ah3
    P1_h2_ghaghax
    P1_h2_ghaghzx
    P1_h2_ghaxghz
    P1_h2_tamtap
    P1_h2_ttx
    P1_h2_bbx
    P1_h2_zz
    P1_h2_zh3
    P1_h2_wpwm
    P1_h2_wphm
    P1_h2_ghzghzx
    P1_h2_ghwpghwpx
    P1_h2_hpwm
    P1_h2_hphm
    P1_h2_h1h1
    P1_h2_h1h2
    P1_h2_h2h2
    P1_h2_h3h3
INFO: Idle: 8, Running: 4, Completed: 0 [ 0.14s ]
INFO: Idle: 8, Running: 4, Completed: 0 [ 0.32s ]
INFO: All jobs finished
INFO: Idle: 0, Running: 0, Completed: 12 [ 1m 0s ]
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_02 tag: tag_1 ===

     Width : 11.75 +- 0.0004317 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
INFO:
more information in /nfs/user/kjaffel/MG5_aMC_v2_7_3/PROC_2HDMtII_NLO_1/index.html
MG5_aMC>
############################################################################

>> What is the BR to top in 2HDMC?
H ==pdg(35) -> t t : 9.865e-01
A == pdg(36) -> t t : 9.867e-01

The full decay table from 2HDMC :
############################################################################
Decay table for H
Total width: 1.188e+01 GeV BR
H -> s s 8.919e-06 7.505e-07
H -> c c 2.182e-04 1.836e-05
H -> b b 2.737e-02 2.303e-03
H -> t t 1.172e+01 9.865e-01
H -> e e 2.735e-10 2.302e-11
H -> mu mu 1.169e-05 9.840e-07
H -> ta ta 3.307e-03 2.783e-04
H -> ga ga 7.512e-05 6.322e-06
H -> Z Z 4.980e-03 4.191e-04
H -> W+ W- 1.021e-02 8.595e-04
H -> Z ga 2.309e-05 1.943e-06
H -> g g 2.370e-02 1.994e-03
H -> h h 8.994e-02 7.569e-03
---------------------------------------

Decay table for A
Total width: 1.768e+01 GeV BR
A -> s s 1.016e-05 5.747e-07
A -> c c 2.538e-04 1.436e-05
A -> b b 3.055e-02 1.728e-03
A -> t t 1.744e+01 9.867e-01
A -> e e 3.085e-10 1.745e-11
A -> mu mu 1.319e-05 7.460e-07
A -> ta ta 3.730e-03 2.110e-04
A -> ga ga 1.137e-04 6.432e-06
A -> Z ga 3.195e-05 1.807e-06
A -> g g 3.749e-02 2.120e-03
A -> Z h 1.496e-02 8.459e-04
A -> Z H 1.488e-01 8.414e-03
---------------------------------------
############################################################################

So the results here are more or less close( i.e the one from 2HDMC and from Madwidth ) !
But let me say that this not always the case, I have other benchmarks where the difference in width becomes very large and brings me to lots of troubles at the generation. An example, MH-800_MA-700 with tanbeta =20:

Here the results from 2HDMC again for this benchmark!
############################################################################
Decay table for H
Total width: 6.345e+00 GeV BR
              #Partial_width#
H -> s s 1.774e-03 2.796e-04
H -> c c 9.058e-07 1.428e-07
H -> b b 5.399e+00 8.509e-01
H -> t t 5.320e-02 8.385e-03
H -> e e 5.489e-08 8.651e-09
H -> mu mu 2.347e-03 3.698e-04
H -> ta ta 6.638e-01 1.046e-01
H -> ga ga 5.352e-07 8.434e-08
H -> Z Z 7.616e-03 1.200e-03
H -> W+ W- 1.553e-02 2.448e-03
H -> Z ga 4.385e-07 6.910e-08
H -> g g 6.903e-04 1.088e-04
H -> h h 5.236e-02 8.252e-03
H -> Z A 1.488e-01 2.344e-02
---------------------------------------

Decay table for A
Total width: 5.503e+00 GeV BR
              #Partial_width#
A -> s s 1.584e-03 2.879e-04
A -> c c 1.276e-06 2.319e-07
A -> b b 4.822e+00 8.763e-01
A -> t t 8.556e-02 1.555e-02
A -> e e 4.799e-08 8.720e-09
A -> mu mu 2.052e-03 3.728e-04
A -> ta ta 5.803e-01 1.055e-01
A -> ga ga 1.114e-06 2.024e-07
A -> Z ga 5.182e-07 9.417e-08
A -> g g 1.452e-03 2.639e-04
A -> Z h 9.651e-03 1.754e-03
---------------------------------------
############################################################################

In, addition the results From MadWidth :

import model 2HDMtII_NLO
compute_widths 36 35 --path=./param_card_PROC_2HDMtII_NLO_HToZA_800-700.dat --output=./param_card_PROC_2HDMtII_NLO_HToZA_800-700.dat --body_decay=2

############################################################################
# PDG Width
DECAY 35 1.195963e+01
# BR NDA ID1 ID2 ...
9.211218e-01 2 5 -5 # 11.0162791778
5.550302e-02 2 15 -15 # 0.663795852927
1.243799e-02 2 36 23 # 0.148753861869
4.587243e-03 2 6 -6 # 0.0548617475069
4.376756e-03 2 25 25 # 0.0523443970125
1.323434e-03 2 -24 24 # 0.0158277835966
6.497840e-04 2 23 23 # 0.0077711788035
5.318816e-18 2 22 36 # 6.36110936293e-17
1.442821e-23 2 22 22 # 1.72556135062e-22
#
# PDG Width
DECAY 36 1.031054e+01
# BR NDA ID1 ID2 ...
9.341713e-01 2 5 -5 # 9.63180900471
5.628212e-02 2 15 -15 # 0.580298987325
8.610552e-03 2 6 -6 # 0.0887794256874
9.359999e-04 2 25 23 # 0.00965066258013
2.370155e-21 2 22 25 # 2.44375708944e-20
#
############################################################################

Or, if you want via :
generate 35 > all all
output
launch

############################################################################
refine 1000
Creating Jobs
INFO: Refine results to 1000
INFO: Generating 1000.0 unweighted events.
INFO: Effective Luminosity 100.339825692 pb^-1
INFO: need to improve 1 channels
- Current estimate of cross-section: 11.9593590254 +- 2.59986784656e-08
P1_h2_aa
P1_h2_az
P1_h2_ah3
P1_h2_ghaghax
P1_h2_ghaghzx
P1_h2_ghaxghz
P1_h2_tamtap
P1_h2_ttx
P1_h2_bbx
P1_h2_zz
P1_h2_zh3
P1_h2_wpwm
P1_h2_wphm
P1_h2_ghzghzx
P1_h2_ghwpghwpx
P1_h2_hpwm
P1_h2_hphm
P1_h2_h1h1
P1_h2_h1h2
P1_h2_h2h2
P1_h2_h3h3
INFO: Idle: 2, Running: 0, Completed: 0 [ 0.13s ]
INFO: All jobs finished
INFO: Idle: 0, Running: 0, Completed: 2 [ 1m 0s ]
INFO: Combining runs
INFO: finish refine
refine 1000 --treshold=0.9
No need for second refine due to stability of cross-section
    INFO: Combining Events
=== Results Summary for run: run_02 tag: tag_1 ===

        Width : 11.96 +- 5.838e-08 GeV
        Nb of events : 1000

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
INFO:
more information in /nfs/user/kjaffel/MG5_aMC_v2_7_3/PROC_2HDMtII_NLO_0/index.html
MG5_aMC>
############################################################################

So, it's a 46.94%, 46.62 % difference in total width for h2==PDG(35) and h3==PDG(36) respectively .
But, you may have noticed already that MadWidth gets similar partial width comparing to 2HMDC for all decay channels except the decay to bb~.
The BR off-course will be wrong since it's computed as BR = partial_width/total_width, so if the Partial_width ( h3-> bb or h2 > bb ) wrong, this will lead to wrong BRs and wrong total width no matter what !

That's why I still think that the Feynam rule of the decay ( h2/h3 > b b~ ) in 2HDMtII_NLO/decays.py is what causes the problem!
I don't know what's going on wrong exactly or if it's me missing something!
My impression is that 2HMC take cares of tanbeta enhanced contributions as well the QCD radiative corrections (the bottom-quark mass is inserted in the MS scheme mb(mb), together with the input value of alpha_s(mZ), alpha_s(mb(mb)) is calculated by 4-loop running with 5 active flavors. While the FR relies mostly on SM inputs!

I tend to trust 2HDMC more to be honest!

My only concern at the moment is the plots you see above where the masses don't pick where they should be?
Do you have any ideas/thoughts on what can cause such effect!

Many thanks to you in advance,
Khawla

I'm not an expert in 2HDM (but you do have expert in CP3) so I can not comment on the validity of such BR.
But If you trust 2HDMMC then you need to stop to use this UFO model.

It seems that both madwidth and madevent agrees on the total width (and both disagrees with 2HDMC).
if you do not trust madevent for h > b b~ partial width computation, how can you trust any MadGraph tool for decaying h > b b~? The result can only be wrong.
If you think that an effect is include in 2HDMC and not in FR that explains the difference, you will need to re-gerenreate a new UFO model with such effect in FR such that you can do such generation.

> My only concern at the moment is the plots you see above where the masses don't pick where they should be?
> Do you have any ideas/thoughts on what can cause such effect!

First, If you are not in narrow-width approximation, then I do not see why you would expect a peak.
Second, MadWidth and Madevent claims that you are not in Narrow-Width-Approximation regime and therefore MadSpin can not be used,... .

> My only concern at the moment is the plots you see above where the masses don't pick where they should be?
> Do you have any ideas/thoughts on what can cause such effect!

I do not think that it should be your concern.
Now I'm trying to reproduce your workflow but that one is broken in 2.8.x due to python3 migration.
So I have fix the madspin gridpack mode first (already passed 5 days on trying to fix it) and then i should be able to look at the other technical issue.

But fixing this is pointless if you do not trust the UFO model obviously. Since you will not be able to trust the result of the computation anyway.

Cheers,

Olivier

> On 18 May 2021, at 16:05, Khawla Jaffel <email address hidden> wrote:
>
> Question #697024 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697024
>
> Status: Solved => Open
>
> Khawla Jaffel is still having a problem:
> Hello Olivier,
>
>>> Does your model contains a decays.py file?
> Yes.
>
> I checked the total width and this what I get :
> ############################################################################
> Creating Jobs
> INFO: Refine results to 10000
> INFO: Generating 10000.0 unweighted events.
> INFO: Effective Luminosity 1020.99421604 pb^-1
> INFO: need to improve 1 channel
> - Current estimate of cross-section: 11.7532497359 +- 4.58014046569e-08
> P1_h2_aa
> P1_h2_az
> P1_h2_ah3
> P1_h2_ghaghax
> P1_h2_ghaghzx
> P1_h2_ghaxghz
> P1_h2_tamtap
> P1_h2_ttx
> P1_h2_bbx
> P1_h2_zz
> P1_h2_zh3
> P1_h2_wpwm
> P1_h2_wphm
> P1_h2_ghzghzx
> P1_h2_ghwpghwpx
> P1_h2_hpwm
> P1_h2_hphm
> P1_h2_h1h1
> P1_h2_h1h2
> P1_h2_h2h2
> P1_h2_h3h3
> INFO: Idle: 8, Running: 4, Completed: 0 [ 0.14s ]
> INFO: Idle: 8, Running: 4, Completed: 0 [ 0.32s ]
> INFO: All jobs finished
> INFO: Idle: 0, Running: 0, Completed: 12 [ 1m 0s ]
> 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_02 tag: tag_1 ===
>
> Width : 11.75 +- 0.0004317 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
> INFO:
> more information in /nfs/user/kjaffel/MG5_aMC_v2_7_3/PROC_2HDMtII_NLO_1/index.html
> MG5_aMC>
> ############################################################################
>
>
>>> What is the BR to top in 2HDMC?
> H ==pdg(35) -> t t : 9.865e-01
> A == pdg(36) -> t t : 9.867e-01
>
> The full decay table from 2HDMC :
> ############################################################################
> Decay table for H
> Total width: 1.188e+01 GeV BR
> H -> s s 8.919e-06 7.505e-07
> H -> c c 2.182e-04 1.836e-05
> H -> b b 2.737e-02 2.303e-03
> H -> t t 1.172e+01 9.865e-01
> H -> e e 2.735e-10 2.302e-11
> H -> mu mu 1.169e-05 9.840e-07
> H -> ta ta 3.307e-03 2.783e-04
> H -> ga ga 7.512e-05 6.322e-06
> H -> Z Z 4.980e-03 4.191e-04
> H -> W+ W- 1.021e-02 8.595e-04
> H -> Z ga 2.309e-05 1.943e-06
> H -> g g 2.370e-02 1.994e-03
> H -> h h 8.994e-02 7.569e-03
> ---------------------------------------
>
> Decay table for A
> Total width: 1.768e+01 GeV BR
> A -> s s 1.016e-05 5.747e-07
> A -> c c 2.538e-04 1.436e-05
> A -> b b 3.055e-02 1.728e-03
> A -> t t 1.744e+01 9.867e-01
> A -> e e 3.085e-10 1.745e-11
> A -> mu mu 1.319e-05 7.460e-07
> A -> ta ta 3.730e-03 2.110e-04
> A -> ga ga 1.137e-04 6.432e-06
> A -> Z ga 3.195e-05 1.807e-06
> A -> g g 3.749e-02 2.120e-03
> A -> Z h 1.496e-02 8.459e-04
> A -> Z H 1.488e-01 8.414e-03
> ---------------------------------------
> ############################################################################
>
>
> So the results here are more or less close( i.e the one from 2HDMC and from Madwidth ) !
> But let me say that this not always the case, I have other benchmarks where the difference in width becomes very large and brings me to lots of troubles at the generation. An example, MH-800_MA-700 with tanbeta =20:
>
> Here the results from 2HDMC again for this benchmark!
> ############################################################################
> Decay table for H
> Total width: 6.345e+00 GeV BR
> #Partial_width#
> H -> s s 1.774e-03 2.796e-04
> H -> c c 9.058e-07 1.428e-07
> H -> b b 5.399e+00 8.509e-01
> H -> t t 5.320e-02 8.385e-03
> H -> e e 5.489e-08 8.651e-09
> H -> mu mu 2.347e-03 3.698e-04
> H -> ta ta 6.638e-01 1.046e-01
> H -> ga ga 5.352e-07 8.434e-08
> H -> Z Z 7.616e-03 1.200e-03
> H -> W+ W- 1.553e-02 2.448e-03
> H -> Z ga 4.385e-07 6.910e-08
> H -> g g 6.903e-04 1.088e-04
> H -> h h 5.236e-02 8.252e-03
> H -> Z A 1.488e-01 2.344e-02
> ---------------------------------------
>
> Decay table for A
> Total width: 5.503e+00 GeV BR
> #Partial_width#
> A -> s s 1.584e-03 2.879e-04
> A -> c c 1.276e-06 2.319e-07
> A -> b b 4.822e+00 8.763e-01
> A -> t t 8.556e-02 1.555e-02
> A -> e e 4.799e-08 8.720e-09
> A -> mu mu 2.052e-03 3.728e-04
> A -> ta ta 5.803e-01 1.055e-01
> A -> ga ga 1.114e-06 2.024e-07
> A -> Z ga 5.182e-07 9.417e-08
> A -> g g 1.452e-03 2.639e-04
> A -> Z h 9.651e-03 1.754e-03
> ---------------------------------------
> ############################################################################
>
>
> In, addition the results From MadWidth :
>
> import model 2HDMtII_NLO
> compute_widths 36 35 --path=./param_card_PROC_2HDMtII_NLO_HToZA_800-700.dat --output=./param_card_PROC_2HDMtII_NLO_HToZA_800-700.dat --body_decay=2
>
>
> ############################################################################
> # PDG Width
> DECAY 35 1.195963e+01
> # BR NDA ID1 ID2 ...
> 9.211218e-01 2 5 -5 # 11.0162791778
> 5.550302e-02 2 15 -15 # 0.663795852927
> 1.243799e-02 2 36 23 # 0.148753861869
> 4.587243e-03 2 6 -6 # 0.0548617475069
> 4.376756e-03 2 25 25 # 0.0523443970125
> 1.323434e-03 2 -24 24 # 0.0158277835966
> 6.497840e-04 2 23 23 # 0.0077711788035
> 5.318816e-18 2 22 36 # 6.36110936293e-17
> 1.442821e-23 2 22 22 # 1.72556135062e-22
> #
> # PDG Width
> DECAY 36 1.031054e+01
> # BR NDA ID1 ID2 ...
> 9.341713e-01 2 5 -5 # 9.63180900471
> 5.628212e-02 2 15 -15 # 0.580298987325
> 8.610552e-03 2 6 -6 # 0.0887794256874
> 9.359999e-04 2 25 23 # 0.00965066258013
> 2.370155e-21 2 22 25 # 2.44375708944e-20
> #
> ############################################################################
>
> Or, if you want via :
> generate 35 > all all
> output
> launch
>
>
> ############################################################################
> refine 1000
> Creating Jobs
> INFO: Refine results to 1000
> INFO: Generating 1000.0 unweighted events.
> INFO: Effective Luminosity 100.339825692 pb^-1
> INFO: need to improve 1 channels
> - Current estimate of cross-section: 11.9593590254 +- 2.59986784656e-08
> P1_h2_aa
> P1_h2_az
> P1_h2_ah3
> P1_h2_ghaghax
> P1_h2_ghaghzx
> P1_h2_ghaxghz
> P1_h2_tamtap
> P1_h2_ttx
> P1_h2_bbx
> P1_h2_zz
> P1_h2_zh3
> P1_h2_wpwm
> P1_h2_wphm
> P1_h2_ghzghzx
> P1_h2_ghwpghwpx
> P1_h2_hpwm
> P1_h2_hphm
> P1_h2_h1h1
> P1_h2_h1h2
> P1_h2_h2h2
> P1_h2_h3h3
> INFO: Idle: 2, Running: 0, Completed: 0 [ 0.13s ]
> INFO: All jobs finished
> INFO: Idle: 0, Running: 0, Completed: 2 [ 1m 0s ]
> INFO: Combining runs
> INFO: finish refine
> refine 1000 --treshold=0.9
> No need for second refine due to stability of cross-section
> INFO: Combining Events
> === Results Summary for run: run_02 tag: tag_1 ===
>
> Width : 11.96 +- 5.838e-08 GeV
> Nb of events : 1000
>
> 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
> INFO:
> more information in /nfs/user/kjaffel/MG5_aMC_v2_7_3/PROC_2HDMtII_NLO_0/index.html
> MG5_aMC>
> ############################################################################
>
> So, it's a 46.94%, 46.62 % difference in total width for h2==PDG(35) and h3==PDG(36) respectively .
> But, you may have noticed already that MadWidth gets similar partial width comparing to 2HMDC for all decay channels except the decay to bb~.
> The BR off-course will be wrong since it's computed as BR = partial_width/total_width, so if the Partial_width ( h3-> bb or h2 > bb ) wrong, this will lead to wrong BRs and wrong total width no matter what !
>
> That's why I still think that the Feynam rule of the decay ( h2/h3 > b b~ ) in 2HDMtII_NLO/decays.py is what causes the problem!
> I don't know what's going on wrong exactly or if it's me missing something!
> My impression is that 2HMC take cares of tanbeta enhanced contributions as well the QCD radiative corrections (the bottom-quark mass is inserted in the MS scheme mb(mb), together with the input value of alpha_s(mZ), alpha_s(mb(mb)) is calculated by 4-loop running with 5 active flavors. While the FR relies mostly on SM inputs!
>
> I tend to trust 2HDMC more to be honest!
>
> My only concern at the moment is the plots you see above where the masses don't pick where they should be?
> Do you have any ideas/thoughts on what can cause such effect!
>
> Many thanks to you in advance,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hello Olivier,

>>First, If you are not in narrow-width approximation, then I do not see why you would expect a peak.
Second, MadWidth and Madevent claims that you are not in Narrow-Width-Approximation regime and therefore MadSpin can not be used,... .

Sorry, but how did you conclude from the decay of MadWidth and Madevent results I show that I am not in the NWA!
I thought if the Width /Mass < 10 e-8 then the NWA is no longer valid! But I don't actually know the maximum Width /Mass so that the NWA still also valid?

If the NWA is not valid, will I be sensitive to non-resonant contributions no matter where I include decay in the Matrix Element, pythia8, or Madspin, is this true?

Cheers,
Khawla

>

Hi,

> Sorry, but how did you conclude from the decay of MadWidth and Madevent results I show that I am not in the NWA!
> I thought if the Width /Mass < 10 e-8 then the NWA is no longer valid! But I don't actually know the maximum Width /Mass so that the NWA still also valid?

For Width /Mass < 10 e-8, MG5aMC has issue to perform the phase-space integration correctly and then assume NWA and use a fake width to avoid the numerical accuracy issue.
In itself, the condition Width /Mass <<1 is a necessary condition but it is not enough to guarantee that NWA holds.

In general NWA is invalid if Width /Mass is bigger than a few percent.
In your case i have seen width of ~100 GeV for ~700 GeV mass this is not a narrow-width regime for my point of view.

> If the NWA is not valid, will I be sensitive to non-resonant
> contributions no matter where I include decay in the Matrix Element,
> pythia8, or Madspin, is this true?

Yes.

Olivier

> On 18 May 2021, at 18:55, Khawla Jaffel <email address hidden> wrote:
>
> Question #697024 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697024
>
> Status: Answered => Open
>
> Khawla Jaffel is still having a problem:
>
> Hello Olivier,
>
>>> First, If you are not in narrow-width approximation, then I do not see why you would expect a peak.
> Second, MadWidth and Madevent claims that you are not in Narrow-Width-Approximation regime and therefore MadSpin can not be used,... .
>
> Sorry, but how did you conclude from the decay of MadWidth and Madevent results I show that I am not in the NWA!
> I thought if the Width /Mass < 10 e-8 then the NWA is no longer valid! But I don't actually know the maximum Width /Mass so that the NWA still also valid?
>
> If the NWA is not valid, will I be sensitive to non-resonant
> contributions no matter where I include decay in the Matrix Element,
> pythia8, or Madspin, is this true?
>
> Cheers,
> Khawla
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Thank you very much, Olivier, that helps a lot!

Hi Olivier,

I still dont think that we have addressed the main issue here.
We want to study specific decays of H and A. We are only interested in either A->ZH, Z->ll and H->bb or H->ZA,Z->ll and A->bb.

The way the samples are produced now we allow for all the possible decays of the resonances. How can we produce events with only the desired decays?

Cheers,

Agni

If everything is in NWA and onshell decay are therefore kinematically possible then you can use the syntax (and A a massive, i.e. not the photon)
decay A > Z H, Z > l l, H > b b~
or
decay H > Z A, Z > l l, A > b b~

This is not what we see in the samples though. In A->ZH if H is large enough decays first to a hh pair which then gives a bb pair.
It a similar problem with the tt threshold, when the mass of the H is large enough, the decay is allowed because it does give a bb pair in the end.

Olivier, would it be ok with you to arrange a meeting sometime in the following days to discuss these issues? I feel that through these messages we are not getting anywhere fast.

> This is not what we see in the samples though. In A->ZH if H is large enough decays first to a hh pair which then gives a bb pair.

Yes but if you use MadSpin for the decay, only that decay should appear in the lhe file.
Did you check that?
It seems like you are using the lhe file before madspin decay for the showering and therefore letting pythia8 to do the decay.

Olivier

> On 20 May 2021, at 11:05, Agni Bethani <email address hidden> wrote:
>
> Question #697024 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697024
>
> Agni Bethani posted a new comment:
> This is not what we see in the samples though. In A->ZH if H is large enough decays first to a hh pair which then gives a bb pair.
> It a similar problem with the tt threshold, when the mass of the H is large enough, the decay is allowed because it does give a bb pair in the end.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.