NP^2==2 interpreted as NP^2<=2 at fixed-order NLO

Hi Gauthier,

> It finds both NP^2==0 and NP^2==2 contributions, while NP^2==2 was specified.

I'm not sure that this is really a bug here since you do fixed-order computation.
And that we need to compute those amplitude anyway for such computation (we could save time by not squaring them obviously but this irrelevant in term of speed in such cases).

But I agree that for the plotting routine this can be confusing to have to do the filtering by hand.

Cheers,

Olivier

Hi Olivier,

Thanks for your reply!

Beside the histograms, the cross-section summary can also be misleading since it silently sums both NP^2==0 and NP^2==2 contributions despite NP^2==2 being specified at process generation.

I suspect event generation could behave in the same way, but I haven't actually checked.

The pole mis-cancellation occurring with NP^2==2 specification but not with NP^2<=2 is another item.

Cheers,
Gauthier

Hi Gauthier,
>
> It seems NP^2==2 is effectively interpreted as NP^2<=2 at NLO (I tried
> fixed order, v3.4.2, with SMEFTatNLO). If that is the desired
> behaviour, maybe a warning could be considered to inform the user.

this is the case.
However, it may be that the == syntax has some side effects, such as those related to the poles.
Mignt need to add some warning, as you suggest.

Best,

Marco

> On 19 Apr 2023, at 11:51, Gauthier <email address hidden> wrote:
>
> Hi Olivier,
>
> Thanks for your reply!
>
> Beside the histograms, the cross-section summary can also be misleading
> since it silently sums both NP^2==0 and NP^2==2 contributions despite
> NP^2==2 being specified at process generation.
>
> I suspect event generation could behave in the same way, but I haven't
> actually checked.
>
> The pole mis-cancellation occurring with NP^2==2 specification but not
> with NP^2<=2 is another item.
>
> Cheers,
> Gauthier
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/2016434
>
> Title:
> NP^2==2 interpreted as NP^2<=2 at fixed-order NLO
>
> Status in MadGraph5_aMC@NLO:
> New
>
> Bug description:
> Dear Developers,
>
> It seems NP^2==2 is effectively interpreted as NP^2<=2 at NLO (I tried
> fixed order, v3.4.2, with SMEFTatNLO). If that is the desired
> behaviour, maybe a warning could be considered to inform the user.
>
> Enclosed is a standalone bash script testing this in pp>W⁺Z, looking
> at the cWWW dependence, with a fixed-order HwU analysis that splits
> the different NP^2 orders. It finds both NP^2==0 and NP^2==2
> contributions, while NP^2==2 was specified. (The constant+linear
> dependence can also be extracted by varying the coefficient in a few
> runs.)
>
> Another issue that is possibly related to this affects the pole
> cancellation check: it sometimes fails with NP^2==2 specified but
> succeeds with NP^2<=2. A specific case in which the crash can be
> reproduced, is again in pp>W⁺Z but using a restriction card where only
> cWWW is allowed. With the script enclosed, this can be reproduced when
> line 49 "#COEFFS=(cWWW)" is un-commented. (You may need to change the
> OUTDIR name, if it already exists in the current directory, to ensure
> the process is generated and outputted.) The mis-cancellation seemed
> very bad, indicating something structural goes wrong; it didn't look
> like an accidental numerical glitch.
>
> Why this pole mis-cancellation issue didn't occur when several other
> operator coefficients were enabled in the restriction card (i.e.
> "#COEFFS=(cWWW)" left commented out) but set to irrelevant 1e-5 values
> at runtime is a last mystery (maybe numerical this time).
>
> Thanks in advance for the time you may spend on this!
>
> Cheers,
> Gauthier
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/2016434/+subscriptions
>