Error due to non-QCD emission of gluon

Asked by Hannes

Hi,

when one imports a SMEFT model in MadGraph, one will get the following warning "CRITICAL: Model with non QCD emission of gluon. This type of model is not fully supported within MG5aMC. Restriction on LO dynamical scale and MLM matching/merging can occur for some processes. Use such features with care."

The word CRITICAL in this context has worried some ATLAS user. So to be clear, if one is not using dynamic scales or matching merging, using these models should be fine?

Would it be possible to (1) downgrade the wording from "CRITICAL" to something like "Warning" and (2) to not put it into the err stream (with the same reasoning as question/690004).

Cheers,
Hannes

Question information

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

Hi,

My first idea for this message was that it should be a crash and that we should prevent MG5aMC to fully support such type of model.
This is the reason why the level of the warning is so high since it is suppose to forbid to use the model.
Other author/contributor make me remove the associated crash and I try to block as much as possible any feature that i can clearly linked to a bad behavior.

However One can not be sure that I spot all of them and that such model can not have still some bad handling.
I really think that the user need to be aware that such model can have some bad issue and that many external tools/features can be ill behaved.

This is something much more serious than our typical warning. So I would keep this message as it is (and I'm glad that it scare some people: it should, at least I am)

Cheers,

Olivier

Revision history for this message
Hannes (hannes3) said :
#2

Hi Olivier,

thanks. I would still like to understand better how worried one should be.

The warning comes already when importing the model . And even with a restriction card that restricts away all the gluon couplings the warning is still the same. I would have though if I only focus on, say, an operator affecting triple gauge couplings and set all gluon couplings to zero, than there might be less of an issue?

And so far I have been taking the message at face value and thought that as long as we don't rely on matching/merging or dynamic scales we are fine. But apparently much more things are potentially wrong with this class of models, even when not using these features?

Cheers,
Hannes

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

Hi,

We use a strategy of making crashing when the user request options that we know are not working.
And allow all the rest.
It is therefore possible that some options are allowed but making assumptions about QCD gluon and not 100% save.
It is possible that no one picked some slight effect on the leading color pick (affecting only shape after parton-shower or equivalent).

I can not be more precise since If I was sure that something was not working, I would have prevent that part of the code to be used (or fixed it if this is easy enough).

Cheers,

Olivier

Revision history for this message
Andy Buckley (andy-insectnation) said :
#4

Hi Olivier, at least in my slightly old version of MG5, this warning is produced with the EFT SMEFTsim and dim6top models, which are used a *lot*! So it would be good to understand if this is really a problem for typical use-cases, i.e. should we avoid jet merging? (probably?), is it ok to factor generation into interference and squared-term samples?, etc.

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

This is exactly the reason why I do not want to decrease this.
This will force some collaborator(s) to investigate those issues in details.

Cheers,

Olivier

Note that if you do not include those gluons in your process, then you should not have any issue at all.

Revision history for this message
Andy Buckley (andy-insectnation) said :
#6

Understood!

To be clear, is this only an issue for ME-level gluon *emission*? I.e. is tt~ production where the g -> tt~ vertex is complemented by O_tG expected to be "safe", provided we don't specify extra-jet multiplicities? Good if so, but we will still need to be careful, since neglected recoils from enhanced gluon emissions could distort the observables we're fitting on. Thanks.

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

Hi,

> To be clear, is this only an issue for ME-level gluon *emission*? I.e.
> is tt~ production where the g -> tt~ vertex is complemented by O_tG
> expected to be "safe", provided we don't specify extra-jet
> multiplicities? Good if so, but we will still need to be careful, since
> neglected recoils from enhanced gluon emissions could distort the
> observables we're fitting on. Thanks.

As soon as O_tg is ON, and that you have a gluon, I can not claim that you are safe.
I would believe that the cross-section computation should be ok.
On the other hand, I would not trust scale variation without a validation (most likely fine).
I would like also to be sure that this does not impact the parton-shower (mainly due to the method of picking the leading color written in the lhe file).

Cheers,

Olivier

> On 30 Apr 2020, at 16:17, Andy Buckley <email address hidden> wrote:
>
> Question #690133 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/690133
>
> Andy Buckley posted a new comment:
> Understood!
>
> To be clear, is this only an issue for ME-level gluon *emission*? I.e.
> is tt~ production where the g -> tt~ vertex is complemented by O_tG
> expected to be "safe", provided we don't specify extra-jet
> multiplicities? Good if so, but we will still need to be careful, since
> neglected recoils from enhanced gluon emissions could distort the
> observables we're fitting on. Thanks.
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Can you help with this problem?

Provide an answer of your own, or ask Hannes for more information if necessary.

To post a message you must log in.