# Narrow width approximation for small width particles

Asked by Shuer Yang on 2021-01-03

Dear MG Authors
We are trying to study exotic decay at future Z factory in the framework of some BSM by using MG5_2.7.3 (Actually we firstly use the version 2.6 which suffer the small width calculation problem). I have read the post https://answers.launchpad.net/mg5amcnlo/+faq/3053 . But I am still confused about the handle on small width particles.
1) I generate e+ e- > Z > x vm vm~, x > mu+ mu- at the Z pole Ecm =91 GeV . Here, the x is a new particle with small width and mx =5 gev. I set the width of mx as 9.00e-5 and get the xsection 0.000345. Furthermore, I found that when I set the width of x to auto or some value such as 0 or 0.5e-6*mx, there is no obvious change. It is wired.
2) I generate e+ e- > Z > x vm vm~ and get the xsection 0.223. I expect the xsection of it times the branching ratio of x > mu mu Br =2.44e-5 should equals to the xsection 0.000345 of the above process under narrow width approximation. But they are very different. I wonder whether my realization is correct.
3) I generate e+ e- > z > x vm vm~ and set madspin on. And then set decay x > mu+ mu. I get an error PRWIDTH(-1)=ZERO Error: Symbol ‘zero’ at (1) has no IMPLICIT type. I have no idea that how to fix this problem.

I would be grateful if you could provide some help.
Best regards,
Shuer

## Question information

Language:
English Edit question
Status:
Solved
For:
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
2021-01-26
Last query:
2021-01-26
2021-01-04
 Olivier Mattelaer (olivier-mattelaer) said on 2021-01-03: #1

Hi,

My first guess is that your UFO model has the width of x hardcoded to a given value (likely 0 or 1).
In principle if it is the case, the default param_card should have a comment for that parameter like
: 0.0

You should also see some warning in the log of the computation such that you try to modify an moot parameter.

If it is not that, I would need to know which BSM model you are using in order to reproduce the issue

Cheers,

Olivier

> On 3 Jan 2021, at 12:50, Shuer Yang <email address hidden> wrote:
>
> New question #694769 on MadGraph5_aMC@NLO:
>
> Dear MG Authors
> We are trying to study exotic decay at future Z factory in the framework of some BSM by using MG5_2.7.3 (Actually we firstly use the version 2.6 which suffer the small width calculation problem). I have read the post https://answers.launchpad.net/mg5amcnlo/+faq/3053 . But I am still confused about the handle on small width particles.
> 1) I generate e+ e- > Z > x vm vm~, x > mu+ mu- at the Z pole Ecm =91 GeV . Here, the x is a new particle with small width and mx =5 gev. I set the width of mx as 9.00e-5 and get the xsection 0.000345. Furthermore, I found that when I set the width of x to auto or some value such as 0 or 0.5e-6*mx, there is no obvious change. It is wired.
> 2) I generate e+ e- > Z > x vm vm~ and get the xsection 0.223. I expect the xsection of it times the branching ratio of x > mu mu Br =2.44e-5 should equals to the xsection 0.000345 of the above process under narrow width approximation. But they are very different. I wonder whether my realization is correct.
> 3) I generate e+ e- > z > x vm vm~ and set madspin on. And then set decay x > mu+ mu. I get an error PRWIDTH(-1)=ZERO Error: Symbol ‘zero’ at (1) has no IMPLICIT type. I have no idea that how to fix this problem.
>
> I would be grateful if you could provide some help.
> Best regards,
> Shuer
>
> --

 Shuer Yang (fortunetellery) said on 2021-01-04: #2

Dear Oliveier
I used the axion like particle effective field theory model (linear ). Please kindly find the attached model file and some tag files generated by MG5.

I generate e+ e- > z > x vm vm~ again and set madspin on. And then set decay x > mu+ mu. I find that even if I set the width of ax to a value, it is still set to 0 in the calculation as recored in the tag file.

In addition, I generate e+ e- > z , z > x vm vm~ and use madspin to decay x to mu mu. And I get a warning "WARNING: For consistency, the width of particle 9000005 (ax) is changed to 0.0." and a report as " 1) A massive s-channel particle has a width set to zero."
As you pointed out, these problems might be because that the width of x is hardcoded to 0. But I have no idea that how to turn off the hardcode and modify the width of x as a assumped value.

Best regards,
Shur

At 2021-01-04 03:45:52, "Olivier Mattelaer" <email address hidden> wrote:
>
>
>Olivier Mattelaer proposed the following answer:
>Hi,
>
>My first guess is that your UFO model has the width of x hardcoded to a given value (likely 0 or 1).
>In principle if it is the case, the default param_card should have a comment for that parameter like
>: 0.0
>
>You should also see some warning in the log of the computation such that
>you try to modify an moot parameter.
>
>If it is not that, I would need to know which BSM model you are using in
>order to reproduce the issue
>
>Cheers,
>
>Olivier
>
>> On 3 Jan 2021, at 12:50, Shuer Yang <email address hidden> wrote:
>>
>> New question #694769 on MadGraph5_aMC@NLO:
>>
>> Dear MG Authors
>> We are trying to study exotic decay at future Z factory in the framework of some BSM by using MG5_2.7.3 (Actually we firstly use the version 2.6 which suffer the small width calculation problem). I have read the post https://answers.launchpad.net/mg5amcnlo/+faq/3053 . But I am still confused about the handle on small width particles.
>> 1) I generate e+ e- > Z > x vm vm~, x > mu+ mu- at the Z pole Ecm =91 GeV . Here, the x is a new particle with small width and mx =5 gev. I set the width of mx as 9.00e-5 and get the xsection 0.000345. Furthermore, I found that when I set the width of x to auto or some value such as 0 or 0.5e-6*mx, there is no obvious change. It is wired.
>> 2) I generate e+ e- > Z > x vm vm~ and get the xsection 0.223. I expect the xsection of it times the branching ratio of x > mu mu Br =2.44e-5 should equals to the xsection 0.000345 of the above process under narrow width approximation. But they are very different. I wonder whether my realization is correct.
>> 3) I generate e+ e- > z > x vm vm~ and set madspin on. And then set decay x > mu+ mu. I get an error PRWIDTH(-1)=ZERO Error: Symbol ‘zero’ at (1) has no IMPLICIT type. I have no idea that how to fix this problem.
>>
>> I would be grateful if you could provide some help.
>> Best regards,
>> Shuer
>>
>> --
>
>--
>know that it is solved:
>
>If you still need help, you can reply to this email or go to the
>following page to enter your feedback:
>

 Olivier Mattelaer (olivier-mattelaer) said on 2021-01-04: #3

Hi,

You need to modify the UFO model.
If you are the author of the UFO model then you need to regenerate it and remove such restriction.

If you are not the author of the model then one solution is off course to ask the author.
The second options is obviously to modify the UFO model by hand.

They are two solutions to hardcode a parameter.
One within the UFO model itself (see https://arxiv.org/abs/1108.2040)

So you would need to check which of the two apply and fix it accordingly.

Cheers,

Olivier

> On 4 Jan 2021, at 09:55, Shuer Yang <email address hidden> wrote:
>
> Question #694769 on MadGraph5_aMC@NLO changed:
>
>
> Shuer Yang is still having a problem:
>
>
> Dear Oliveier
> I used the axion like particle effective field theory model (linear ). Please kindly find the attached model file and some tag files generated by MG5.
>
> I generate e+ e- > z > x vm vm~ again and set madspin on. And then set
> decay x > mu+ mu. I find that even if I set the width of ax to a value,
> it is still set to 0 in the calculation as recored in the tag file.
>
> In addition, I generate e+ e- > z , z > x vm vm~ and use madspin to decay x to mu mu. And I get a warning "WARNING: For consistency, the width of particle 9000005 (ax) is changed to 0.0." and a report as " 1) A massive s-channel particle has a width set to zero."
> As you pointed out, these problems might be because that the width of x is hardcoded to 0. But I have no idea that how to turn off the hardcode and modify the width of x as a assumped value.
>
>
>
> Best regards,
> Shur
>
>
> At 2021-01-04 03:45:52, "Olivier Mattelaer" <email address hidden> wrote:
>>
>>
>> Olivier Mattelaer proposed the following answer:
>> Hi,
>>
>> My first guess is that your UFO model has the width of x hardcoded to a given value (likely 0 or 1).
>> In principle if it is the case, the default param_card should have a comment for that parameter like
>> : 0.0
>> instead of a variable name.
>>
>> You should also see some warning in the log of the computation such that
>> you try to modify an moot parameter.
>>
>> If it is not that, I would need to know which BSM model you are using in
>> order to reproduce the issue
>>
>> Cheers,
>>
>> Olivier
>>
>>> On 3 Jan 2021, at 12:50, Shuer Yang <email address hidden> wrote:
>>>
>>> New question #694769 on MadGraph5_aMC@NLO:
>>>
>>> Dear MG Authors
>>> We are trying to study exotic decay at future Z factory in the framework of some BSM by using MG5_2.7.3 (Actually we firstly use the version 2.6 which suffer the small width calculation problem). I have read the post https://answers.launchpad.net/mg5amcnlo/+faq/3053 . But I am still confused about the handle on small width particles.
>>> 1) I generate e+ e- > Z > x vm vm~, x > mu+ mu- at the Z pole Ecm =91 GeV . Here, the x is a new particle with small width and mx =5 gev. I set the width of mx as 9.00e-5 and get the xsection 0.000345. Furthermore, I found that when I set the width of x to auto or some value such as 0 or 0.5e-6*mx, there is no obvious change. It is wired.
>>> 2) I generate e+ e- > Z > x vm vm~ and get the xsection 0.223. I expect the xsection of it times the branching ratio of x > mu mu Br =2.44e-5 should equals to the xsection 0.000345 of the above process under narrow width approximation. But they are very different. I wonder whether my realization is correct.
>>> 3) I generate e+ e- > z > x vm vm~ and set madspin on. And then set decay x > mu+ mu. I get an error PRWIDTH(-1)=ZERO Error: Symbol ‘zero’ at (1) has no IMPLICIT type. I have no idea that how to fix this problem.
>>>
>>> I would be grateful if you could provide some help.
>>> Best regards,
>>> Shuer
>>>
>>> --
>>
>> --
>> know that it is solved:
>>
>> If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>>