Inconsistency in automatic calculation of three-body decays

Asked by Manu

Dear experts,

I am having difficulties with the automatic width calculation of three-body decays of a scalar (S) to three SM vector bosons, mediated by off-shell scalars (s_i) with anomalous couplings to two vector bosons.
I am comparing two methods (using version 3.4.0):
1) compute_widths S s_i --body_decay=3.0025
2) First prepare a param_card with the widths of the s_i by 'compute_widths s_i --body_decay=3.0025', then 'generate S > vec vec vec' where 'vec = w+ w- z a' with the prepared param_card

For some of the decay channels, the partial widths coincide very well, but for some the two methods differ by a factor 2-4. From comparing the hierarchy of the widths with the couplings in the lagrangian, the results from method 2) seem to be correct, while 1) gives unreasonable results.

Could you please have a look at this? I'd be happy to send you my UFO and steering files (preferably by email as the UFO is not public yet). Please let me know if you need further information.

Best,
Manuel

Question information

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

You can send me the model at <email address hidden> with
a link to this webpage: https://answers.launchpad.net/mg5amcnlo/+question/701760 such that I can know for which question this is.

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

Hi,

Looks like your benchmark is a quite compressed spectra and therefore NWA is not valid here.
The issue is that you do have s104 which has a mass close to s103 and a large width breaking NWA (both since the width is at 10% but also because it is larger than the mass gap).
And therefore your computation indeed depends on the ordering in which you do compute those widths.

I have never studied how one can compute correctly width in such cases.

Cheers,

Olivier

Revision history for this message
Manu (manuphysics) said :
#3

Hi Olivier,

thanks for your comments. I redid the calculation with MS104 = MS112 = 700. In this case, the width is ~3% of the mass and the mass gap is 200, but the issue remains and the offending widths are off by the exact same factors. Is a 3% width/mass still too large for NWA to apply?

And when I calculate the widths by "generate s103 > vec vec vec" with the prepared param_card, can I trust the results in that case or is the breakdown of NWA an issue there as well?

Best,
Manuel

Revision history for this message
Manu (manuphysics) said :
#4

Hi again,

sorry, I was too quick before: for the parameters I sent you (MS104 = 520, MS103 = 500), I get a small width of 3.7e-04 GeV for the S104 (PID 6104001). Why does this break NWA?

Best,
Manuel

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

In my computation it was at 50 GeV....

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

Not sure I can reproduce such 50 GeV

But I do have issue with the s102 particles which has a width larger than it's (very large as well) mass.

In any case since both computation use the same matrix-element this sounds like a width dependence issue (which should not be present in NWA)

Cheers,

Olivier

Revision history for this message
Manu (manuphysics) said :
#7

Ok thanks, I see. I took the MS102 so large to "integrate out" the S102 but didn't consider effects on NWA.

However, when I set MS102 smaller the issue remains. In my current example, MS102 = 600, MS12 = MS112 = MS104 = 550 and MS11 = MS103 = 500, the S102 has a width/mass of only 0.5%, and all other widths are smaller by orders of magnitude.

When I use compute_widths to first calculate the widths of all intermediate states, followed by a second call of compute_widths for just s103, does MadGraph use the updated param_card for the second call?

Can you help with this problem?

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

To post a message you must log in.