Grouping of subprocess in NLO production

Asked by SEN DENG on 2020-11-28

Dear experts,

Recently I am doing some test on NLO.

generate p p > l+ l- l+ vl [QCD]

And for testing, I add some restrictions in run_card:
e.g.
1.0 = mll
1.0 = mll_sf

I noticed that in LO, mll cut will occur some bugs due to grouping issues, which is also mentioned in the link below.
https://answers.launchpad.net/mg5amcnlo/+question/675565

But in NLO, it seems that these kinds of mll cut will not cause this bug and I generate events successfully. Since NLO is quite different with LO, I am wonder if this kind of cut will cause some potential bugs in the production.

Best,
Sen

Question information

Language:
English Edit question
Status:
Solved
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Solved by:
Olivier Mattelaer
Solved:
2020-11-28
Last query:
2020-11-28
Last reply:
2020-11-28

This is not a bug, just that the our default LO is too much optimized and this prevents such cut to be possible. You can forbid MG5aMC to apply such optimization (and having a much slower code).

At NLO such optimization is not yet done.

Cheers,

Olivier

> On 28 Nov 2020, at 08:11, SEN DENG <email address hidden> wrote:
>
> New question #694226 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/694226
>
> Dear experts,
>
> Recently I am doing some test on NLO.
>
> generate p p > l+ l- l+ vl [QCD]
>
> And for testing, I add some restrictions in run_card:
> e.g.
> 1.0 = mll
> 1.0 = mll_sf
>
> I noticed that in LO, mll cut will occur some bugs due to grouping issues, which is also mentioned in the link below.
> https://answers.launchpad.net/mg5amcnlo/+question/675565
>
> But in NLO, it seems that these kinds of mll cut will not cause this bug and I generate events successfully. Since NLO is quite different with LO, I am wonder if this kind of cut will cause some potential bugs in the production.
>
>
> Best,
> Sen
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

SEN DENG (sdeng) said : #2

Dear Olivier,

Thanks for you answer. So do you mean that such cut is not physical so it is prevented? Or is there only effiecient problem here?

So does it mean adding such cut at NLO is appropriate?

Best,
Sen

Hi,

> So do you mean that such cut is not physical so
> it is prevented?

The cut is physical but you have to generate the code in a less optimized way (either by having mass for the muon or by using the option "set group_subprocesses False" such that the code will be able to apply such cut. The downside of those two method is that your code will run slower.

> So does it mean adding such cut at NLO is appropriate?

Yes no issue at NLO

Cheers,

Olivier

> On 28 Nov 2020, at 09:20, SEN DENG <email address hidden> wrote:
>
> Question #694226 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/694226
>
> Status: Answered => Open
>
> SEN DENG is still having a problem:
> Dear Olivier,
>
> Thanks for you answer. So do you mean that such cut is not physical so
> it is prevented? Or is there only effiecient problem here?
>
> So does it mean adding such cut at NLO is appropriate?
>
>
> Best,
> Sen
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

SEN DENG (sdeng) said : #4

Thanks Olivier Mattelaer, that solved my question.