Different partial widhts when changing the order of final state particles

Asked by Nicolas Mileo on 2021-06-03

Dear MadGraph team,

We are trying to understand some results we are getting for some partial widths of a sterile neutrino within the context of a new physics model. More precisely, we are obtaining different partial widhts just by changing the syntax we use to generate the decay process. For example, when using

n > ta- e+ ve

we obtain 1.028 x 10^-16 GeV for a sterile neutrino mass of 82 GeV,

while with the syntax

n > ve ta- e+

we obtain 1.239 x 10^-16 GeV for the same mass.

The discrepancy decreases significantly for masses well below the W boson mass (which mediates this three-body decay). However, for masses above it, for example Mn=90GeV, we obtain 7.189 x 10^-16 GeV without any problem with the first syntax, while with the second one the computation fails to generate the requested number of events (10k) and ends up giving inconsistent values for the width which fluctuate drastically from run to run. In all the runs less than 10 events are generated.

Finally, if we set the complex_mass_scheme to True and then generate the decay with the second syntax, all the values are pretty much consistent: for example, we obtain 1.033 x 10^-16 GeV for Mn=82 GeV and 7.187 x 10^-16 GeV for Mn=90 GeV.

Could you help us to clarify what is going on?

Thanks in advance,
Nico.-

Question information

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

Hi,

If you only have 10 events generated I guess that the statistical error on the computed width is much more than 10% and therefore your results are compatible with each other.

I can see two types of problem for such type of compuation
1) a typical numerical error (your width is so small that it can be at the level of precision of the computer.
2) an issue with the W width. Since the issue appears when the W can be onshell, you need the W width to regulate the computation and if that one is not set correctly your amplitude can be infinite and lead to such issue.

Cheers,

Olivier

> On 4 Jun 2021, at 01:35, Nicolas Mileo <email address hidden> wrote:
>
> New question #697380 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/697380
>
> Dear MadGraph team,
>
> We are trying to understand some results we are getting for some partial widths of a sterile neutrino within the context of a new physics model. More precisely, we are obtaining different partial widhts just by changing the syntax we use to generate the decay process. For example, when using
>
> n > ta- e+ ve
>
> we obtain 1.028 x 10^-16 GeV for a sterile neutrino mass of 82 GeV,
>
> while with the syntax
>
> n > ve ta- e+
>
> we obtain 1.239 x 10^-16 GeV for the same mass.
>
> The discrepancy decreases significantly for masses well below the W boson mass (which mediates this three-body decay). However, for masses above it, for example Mn=90GeV, we obtain 7.189 x 10^-16 GeV without any problem with the first syntax, while with the second one the computation fails to generate the requested number of events (10k) and ends up giving inconsistent values for the width which fluctuate drastically from run to run. In all the runs less than 10 events are generated.
>
> Finally, if we set the complex_mass_scheme to True and then generate the decay with the second syntax, all the values are pretty much consistent: for example, we obtain 1.033 x 10^-16 GeV for Mn=82 GeV and 7.187 x 10^-16 GeV for Mn=90 GeV.
>
> Could you help us to clarify what is going on?
>
> Thanks in advance,
> Nico.-
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Nicolas Mileo (nmileo) said :
#2

Hi Olivier,

Thanks for your reply. In the case when the runs give less than 10 generated events the result is 0.003105 ± 0.0015 GeV, so the error is ~50% but still it is inconsistent with 7.189 x 10^-16 GeV (the result obtained with the first syntax).

We have some further questions regarding the two types of problems you pointed out :

1) If the problem were a numerical error, why the computation with the first syntax goes well? In fact, the order of magnitude obtained for the width in that case is reasonable comparing with theoretical estimations.

2) We don't see how the W width could be the problem since it is set in both cases to ~2 GeV. In fact, the param_card and run_card are the same for both directories. We also checked that the Feynman diagram assigned to the decay process (there is only one) is the same in both cases. The only difference between the directories is the structure of the Subprocesses folder. Is this expected when just the order of the final state particles changes?

Finally, we would like to understand why the second syntax becomes compatible with the first one when we use the complex_mass_scheme option.

Thanks again for your help,

Cheers,
Nico.-

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

> Thanks for your reply. In the case when the runs give less than 10
> generated events the result is 0.003105 ± 0.0015 GeV, so the error is
> ~50% but still it is inconsistent with 7.189 x 10^-16 GeV (the result
> obtained with the first syntax).

Here I'm confused since in your first message you were speaking of
 1.028 x 10^-16 GeV
and
 1.239 x 10^-16 GeV

> 2) We don't see how the W width could be the problem since it is set in
> both cases to ~2 GeV. In fact, the param_card and run_card are the same
> for both directories. We also checked that the Feynman diagram assigned
> to the decay process (there is only one) is the same in both cases. The
> only difference between the directories is the structure of the
> Subprocesses folder. Is this expected when just the order of the final
> state particles changes?

Which version of MG5aMC are you using?
Can you try with the latest one? This might be related to a bug that was introduced in 2.8.0
and where indeed setting to complex-mass-scheme will fix the issue (and the issue can indeed be related to the ordering of particle)

Cheers,

Olivier

> On 4 Jun 2021, at 23:05, Nicolas Mileo <email address hidden> wrote:
>
> Question #697380 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697380
>
> Status: Answered => Open
>
> Nicolas Mileo is still having a problem:
> Hi Olivier,
>
> Thanks for your reply. In the case when the runs give less than 10
> generated events the result is 0.003105 ± 0.0015 GeV, so the error is
> ~50% but still it is inconsistent with 7.189 x 10^-16 GeV (the result
> obtained with the first syntax).
>
> We have some further questions regarding the two types of problems you
> pointed out :
>
> 1) If the problem were a numerical error, why the computation with the
> first syntax goes well? In fact, the order of magnitude obtained for the
> width in that case is reasonable comparing with theoretical estimations.
>
> 2) We don't see how the W width could be the problem since it is set in
> both cases to ~2 GeV. In fact, the param_card and run_card are the same
> for both directories. We also checked that the Feynman diagram assigned
> to the decay process (there is only one) is the same in both cases. The
> only difference between the directories is the structure of the
> Subprocesses folder. Is this expected when just the order of the final
> state particles changes?
>
> Finally, we would like to understand why the second syntax becomes
> compatible with the first one when we use the complex_mass_scheme
> option.
>
> Thanks again for your help,
>
> Cheers,
> Nico.-
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Nicolas Mileo (nmileo) said :
#4

Hi Olivier,

We moved from version 2.8.1 to 3.0.1 and now both syntax give consistent results. However, when we use MadWidth in order to compute more efficiently the total width of the sterile neutrino for different masses we get in most of the cases the message:

"INFO: fail to reach target 10000", and in the results summary of the runs the number of events is equal to zero, even when the computed width appears to be reasonable.
For example, for Mn = 50 GeV, we obtain (we rescaled the couplings to have larger widths)

  === Results Summary for run: decay tag: tag_1 ===

     Width : 0.218 +- 0.0003435 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

Since the only particles that mediate the three-body decays are W and Z bosons and the products of the decay are standard quarks and leptons, we don't understand where is the problem with the numerical integration. Is the result reliable when the above messages appear? It is strange for us that for all the considered masses (we scan from 50 to 110 GeV) we always get "Nb of events: 0".

Thanks again,

Cheers,
Nico.-

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

Hi,

Which command are you running? Are you using CMS/aTLAS framework?
They are mode for width computation where the generation of events is bypassed on purpose.
and therefore 0 events is normal.

CMS have reported that in some of those cases they see the warning
""INFO: fail to reach target 10000" but so far I have never succeed to reproduce such printout issue in the official version of MG5aMC and therefore incline to think that this is due to a unofficial patch that CMS is using.

Concerning:
> WARNING: Order of particle in the event did not agree with parent/child order. This might be problematic for some code.

Some code can complain if a child appears before their parent in the lhef code, this is an issue that occurs quite often in MG5aMC when doing 1> 3 body decay. If a code after MG5aMC crashes because of that then you need to post-process the lhef file to reorder the line. (our internal lhe_reader.py should be able to do that in case)

Cheers,

Olivier

> On 7 Jun 2021, at 01:10, Nicolas Mileo <email address hidden> wrote:
>
> Question #697380 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697380
>
> Status: Answered => Open
>
> Nicolas Mileo is still having a problem:
> Hi Olivier,
>
> We moved from version 2.8.1 to 3.0.1 and now both syntax give consistent
> results. However, when we use MadWidth in order to compute more
> efficiently the total width of the sterile neutrino for different masses
> we get in most of the cases the message:
>
> "INFO: fail to reach target 10000", and in the results summary of the runs the number of events is equal to zero, even when the computed width appears to be reasonable.
> For example, for Mn = 50 GeV, we obtain (we rescaled the couplings to have larger widths)
>
>
> === Results Summary for run: decay tag: tag_1 ===
>
> Width : 0.218 +- 0.0003435 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
>
> Since the only particles that mediate the three-body decays are W and Z
> bosons and the products of the decay are standard quarks and leptons, we
> don't understand where is the problem with the numerical integration.
> Is the result reliable when the above messages appear? It is strange for
> us that for all the considered masses (we scan from 50 to 110 GeV) we
> always get "Nb of events: 0".
>
> Thanks again,
>
> Cheers,
> Nico.-
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Nicolas Mileo (nmileo) said :
#6

Hi Olivier,

We are not using any CMS/ATLAS framework, we are running the command

compute_widhts n --output=xxxx

(with n the label of the sterile neutrino) in the official version 3.0.1 that we downloaded from the MG launchpad. I could share the UFO of the model and maybe you can reproduce the warning message and the 0 events result.

Thanks for your comment on the warning concerning the order of the particle, it's now clear to us how to proceed if we find problems with other codes.

Cheers,
Nico.-

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

Ok yes, this is one of the case where we configure the code to reach a given accuracy and not a given number of events which explains why it fails to reach that given number of events. So nothing to be worried about
(this is actually an information not even a warning in this case).
I will see what I can do to reduce that printout to a debug statement (or simply remove it) in this case.

Thanks,

Olivier

> On 7 Jun 2021, at 09:08, Olivier Mattelaer <email address hidden> wrote:
>
> Hi,
>
> Which command are you running? Are you using CMS/aTLAS framework?
> They are mode for width computation where the generation of events is bypassed on purpose.
> and therefore 0 events is normal.
>
> CMS have reported that in some of those cases they see the warning
> ""INFO: fail to reach target 10000" but so far I have never succeed to reproduce such printout issue in the official version of MG5aMC and therefore incline to think that this is due to a unofficial patch that CMS is using.
>
>
> Concerning:
> > WARNING: Order of particle in the event did not agree with parent/child order. This might be problematic for some code.
>
> Some code can complain if a child appears before their parent in the lhef code, this is an issue that occurs quite often in MG5aMC when doing 1> 3 body decay. If a code after MG5aMC crashes because of that then you need to post-process the lhef file to reorder the line. (our internal lhe_reader.py should be able to do that in case)
>
> Cheers,
>
> Olivier
>
>
>> On 7 Jun 2021, at 01:10, Nicolas Mileo <<email address hidden> <mailto:<email address hidden>>> wrote:
>>
>> Question #697380 on MadGraph5_aMC@NLO changed:
>> https://answers.launchpad.net/mg5amcnlo/+question/697380 <https://answers.launchpad.net/mg5amcnlo/+question/697380>
>>
>> Status: Answered => Open
>>
>> Nicolas Mileo is still having a problem:
>> Hi Olivier,
>>
>> We moved from version 2.8.1 to 3.0.1 and now both syntax give consistent
>> results. However, when we use MadWidth in order to compute more
>> efficiently the total width of the sterile neutrino for different masses
>> we get in most of the cases the message:
>>
>> "INFO: fail to reach target 10000", and in the results summary of the runs the number of events is equal to zero, even when the computed width appears to be reasonable.
>> For example, for Mn = 50 GeV, we obtain (we rescaled the couplings to have larger widths)
>>
>>
>> === Results Summary for run: decay tag: tag_1 ===
>>
>> Width : 0.218 +- 0.0003435 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
>>
>> Since the only particles that mediate the three-body decays are W and Z
>> bosons and the products of the decay are standard quarks and leptons, we
>> don't understand where is the problem with the numerical integration.
>> Is the result reliable when the above messages appear? It is strange for
>> us that for all the considered masses (we scan from 50 to 110 GeV) we
>> always get "Nb of events: 0".
>>
>> Thanks again,
>>
>> Cheers,
>> Nico.-
>>
>> --
>> You received this question notification because you are an answer
>> contact for MadGraph5_aMC@NLO.
>

Revision history for this message
Nicolas Mileo (nmileo) said :
#8

Ok, then we can ignore that information. Just to confirm, does the same apply to the "Nb of events=0" in the results summary?. It would be great to reduce this printout in order to avoid doubts regarding the reliability of the obtained results for the width. Please, let me know in case you may need the UFO of the model we used.

Thanks for your help,

Nico.-

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

Actually you likely have generated more than 0 events, (the minimum is always one event, it is impossible to generate less than one event) and we print 0 to make clear that this is a mode where do not care about event generation.

But yes I will try to improve such message.

Cheers,

Olivier

> On 9 Jun 2021, at 16:00, Nicolas Mileo <email address hidden> wrote:
>
> Question #697380 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/697380
>
> Status: Answered => Open
>
> Nicolas Mileo is still having a problem:
> Ok, then we can ignore that information. Just to confirm, does the same
> apply to the "Nb of events=0" in the results summary?. It would be great
> to reduce this printout in order to avoid doubts regarding the
> reliability of the obtained results for the width. Please, let me know
> in case you may need the UFO of the model we used.
>
> Thanks for your help,
>
> Nico.-
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Revision history for this message
Nicolas Mileo (nmileo) said :
#10

Thanks Olivier Mattelaer, that solved my question.