BW_cut restrictions

You are right that conceptually nothing changed.

We faced many issues related to large value of BWcut (as one should have expect)

The problems were double:
1) we faced low (actually very low) efficiency of madspin is bwcut is set too large.
2) we faced that madspin can be stuck in an infinite loop when bwcut was set to too large value.

The first issue is off course expected, since using NWA outside the NWA regime can lead to many issue (starting by the breaking of gauge invariance).
and therefore the amplitude can have un-physical behavior (and indeed we have observed such un-physical behavior) which then in turn kill the efficiency of the madspin generation of the decay.
(since the maximum-weight does not match the theoretical formula and can even be not bounded)

POWHEG does have method to preserve in all cases the gauge invariance that we do not have (and therefore the reason of the bwcut off).
At the same time the use of the POWHEG algorithm outside of the NWA is also something that I do not consider as very solid.
(So I would also advice, for physical consideration, to use a BWcut when using POWHEG at least at the analysis level. )

The second issue is related to some physics issue related to large off-shell effect and therefore, I decide to not investigate that further.
Since many user complains about the speed of madspin and of the issue with the breaking of the gauge invariance.

I have indeed added a warning at 25 and a crash at 100 to be sure that MadSpin is not used in such un-physical regime.
The reason to have a warning first, is to allow quite large bwcut for particle with very small width (i.e. smaller than 1e-3) and also make clear to the user that they are pushing the code to the limit.
Even for extremely small width, the interest to allow to have large bwcut than 100 is likely irrelevant. I personally consider the bound used here as quite high (if not too high already).

Now if you have a physical case where 100 is working (no gauge issue) and where using such large value is really relevant. I can obviously increase the threshold of that crash.
But having it at some value is certainly important to avoid that (many) user set such value too large (which they seems to do in general).

Cheers,

Olivier

> On 30 May 2022, at 16:15, Hannes <email address hidden> wrote:
>
> New question #702011 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/702011
>
> Hi,
>
> we saw that there will be a warning for BW_cut>25 and an error for BW_cut>100 in MadSpin.
> https://bazaar.launchpad.net/~madteam/mg5amcnlo/3.x/revision/78.444.100#MadSpin/interface_madspin.py
>
> Is this just to be more explicit about the limitations of the NWA or did something change as well?
>
> Just so you are aware, in ATLAS we generate ttbar production with a BW_cut>50. We are aware that there are limitations in this off-shell regime but do think it is better to include these contributions than no contributions at all? This is also more in line with what is done in other generators like Powheg.
>
> Cheers,
> Hannes
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.