Comment 4 for bug 2016434

Revision history for this message
marco zaro (marco-zaro) wrote : Re: [Bug 2016434] NP^2==2 interpreted as NP^2<=2 at fixed-order NLO

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
>