multiparticles in BSM models

My first idea here, is that you are sensitive to numerical cancellation.
The question here is why you have such small value for your width.
If this is due to something like A-B where A and B are very close to each other, then you certainly face a numerical issue.

Cheers,

Olivier

We don’t expect such small values nor any cancellations in this computation. In fact, we think the larger result is the correct one (or at least it is close to the correct one), so we don’t understand the very small values obtained for the subprocesses separately. The width is expected to be small because of the mass we are using, in the O(100) MeV range.

Also, do you know why the vl multiparticle definition reappears, if we haven't declared it? if this is something that madgraph does automatically, we think that this could be part of the issue...mostly, because it seems to reappear in combination with the very small (and incorrect) values.

Thanks again,

Pilar

Hi,

Then I guess I would need to have the model in order to comment.

For the vl, this is perfectly normal, this is the group subprocess feature of madgraph which has nothing to do with your definition of the multi-particles so I do not see anything to be worried about here.
One can obviously set it to off (via set group_subprocesses False) but I would not be particularly beworry about this.

Cheers,

Olivier

Hi,

well, the thing is that there are no ve, vm, vt particles in this model: we removed them, and we are just using the mass eigenstates.

So, how does MadGraph define the vl in this case?

I will send you the files by email so you can take a look, though. Thanks again,
Pilar

Hi,

I have run your process and observe the following:

1. In the log, I see a lot of "Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG"
-> this is a sign of issue with numerical stability (at this stage I do not know what causing it but it is bad

2. The statistical error of your process is 100%:
  === Results Summary for run: run_01 tag: tag_1 ===

     Width : 4.271e-37 +- 2.159e-37 GeV
     Nb of events : 10000

Meaning that you can not trust such result.

3. The reason of this large error, can be seen if you are in debug mode: In that case, you would have seen such lines:

find 12 multijob in /Users/omattelaer/Documents/workspace/2.6.7/PROC_test_UFO_0/SubProcesses/P1_n1_v1v1xv3/G8.2
multi run are inconsistent: 0.0 < 2.13503333333e-37 - 25* 0.0: assign error 4.3188e-37
Combined 6 file generating 37967 events for /Users/omattelaer/Documents/workspace/2.6.7/PROC_test_UFO_0/SubProcesses/P1_n1_v1v1xv3/G8.2

4. Now by debugging the reason of the such numerical error, it is actually linked to the running of alpha_s. So I would suggest to pass in fix scale computation for alpha_s (and force a large scale). If needed you can correct yourself for the value of alphas at such low scale but we are not able to compute it.

5. Fixing alphas, is actually not enough, you have issue with at least the "Z" propagator .
When computing the Z propagator alone, it actually sometimes returns 0 (not sure if this is due to a physics reason or not. Is this expected for you?).

6. When generating such decay without the Z propagator, then you get:
     Width : 1.94e-40 +- 5.978e-41 GeV
     Nb of events : 10000
while separatly for the 3 of them you get:
     Width : 3.775e-41 +- 4.09e-44 GeV
     Nb of events : 10000
-------
     Width : 1.888e-41 +- 2.045e-44 GeV
     Nb of events : 10000
-------
     Width : 1.888e-41 +- 2.045e-44 GeV
     Nb of events : 10000

7. Issue is fixed if you set "set subprocesses_group True" (which is counter-intuitive so I need to understand why)

I will continue to look at this, but this is the current progress that I have done so far (and this give you potentially a way to generate this correctly already).

Cheers,

Olivier

Hi,

Thank you very much for taking time to look into this.

Indeed you are right, the individual subprocesses have too large errors when generated with the multiparticles and this seems to be fixed by doing "set subprocesses_group True" as you suggested.

However, we think that the values computed this way are too small (even now, with small errors) and therefore incorrect. Our estimations of these processes are that they should be order 10^-26 GeV. And, in fact, if we generate instead the related process

n1 > Z > nu e+ e-

we do obtain 7.902e-27 +- 7.078e-30 GeV, in line with our expectations. However

n1 > Z > nu nu~ nu

returns 0 with the following message:

Survey return zero cross section.
   Typical reasons are the following:
   1) A massive s-channel particle has a width set to zero.
   2) The pdf are zero for at least one of the initial state particles
      or you are using maxjetflavor=4 for initial state b:s.
   3) The cuts are too strong.
   Please check/correct your param_card and/or your run_card.

In answer to your question regarding the width of the Z in this model: no, we do not expect it to change significantly with respect to the SM value). In fact, we checked that the Z width is set to its correct value in the param_card of the model:

DECAY 23 2.495200e+00 # WZ

We then thought we might have a problem with the Z coupling to nu, but when we compute

Z > nu nu~

we obtain Width : 0.4976 +- 7.17e-10 GeV. This is consistent with the invisible width of the Z in the SM,
so the coupling seems to fine (at least for this process).

Do you have any suggestions we could try? We also fixed the running scale for alpha_s as you suggested in all the tests described above, but that didn't solve the issue either...

By the way, we are using version 2.6.6 (from your response it seems you might be using 2.6.7).

Thank you very much for you help again!
Best,
Pilar

Great!!! Indeed, when we did as you suggested, the returned width is correct and the error is reasonable. So I am marking this question as solved.

However, note that when generating the events we still get:

Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG

So I am not sure if we will run into numerical issues later on. In that case, I will reopen this thread (let's hope that's not the case...).

Thanks a lot again, Olivier, for all your help!
Pilar

Thanks Olivier Mattelaer, that solved my question.

Did you turn off the running of alpha_s ?
I do not face any of such numerical issue.

Cheers,

Olivier

> On 2 Aug 2019, at 08:12, Pilar <email address hidden> wrote:
>
> Question #682437 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/682437
>
> Pilar posted a new comment:
> Great!!! Indeed, when we did as you suggested, the returned width is
> correct and the error is reasonable. So I am marking this question as
> solved.
>
> However, note that when generating the events we still get:
>
> Note: The following floating-point exceptions are signalling:
> IEEE_INVALID_FLAG
>
> So I am not sure if we will run into numerical issues later on. In that
> case, I will reopen this thread (let's hope that's not the case...).
>
> Thanks a lot again, Olivier, for all your help!
> Pilar
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

oh, you are right. Sorry, we forgot to fix it in that run...it seems that this is completely solved then!
Thanks again,
Pilar