Merge lp:~maddevelopers/mg5amcnlo/v3_syntax_handler into lp:mg5amcnlo

[Olivier Mattelaer]

Hi,

This implements the checks that a syntax might not have the same syntax between 3.0 and 3.1
and returns crash (or in some case just warning).

The error message is not yet complete (need reference from Rik)
The functionality is checked via an unnitest that shows various syntax for the various categories
- crashing
- just warning
- no error

If you are worried about some specific case, please do not simply test the interface, it would be much safer to add such syntax in the unittest such that we can all agree on that syntax.

if you do not agree on the category related to one of the processes, then the best is to mentioned it here (I guess some might not be happy to just have warning for "[QCD]") and if debate then we can vote/...

[Olivier Mattelaer (olivier-mattelaer)]

Any comment on this?

I think that it does not make that much sense to wait months before releasing it (otherwise this will be even more uglier).

Olivier

[Rikkert Frederix (frederix)]

I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that describes the coupling order syntax and also "fixes" the automation of EW corrections paper. Please have a look.

Best,
Rikkert

[Richard Ruiz (rruiz)]

Hi Rikkert,

Thank you for the webpage and the hard work!

I think that the instructions are clear. Just a quick question: would it be
useful to add a line or comment for BSM and SMEFT scenarios? For example,
while QED<=4 QCD=0 NP<=1 may be possible, where NP=some new physics
coupling, presumably aNP (or alpha_NP) is not automatically defined (is
it?).

cheers

On Sun, Apr 18, 2021 at 9:01 PM Rikkert Frederix <email address hidden>
wrote:

> I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that
> describes the coupling order syntax and also "fixes" the automation of EW
> corrections paper. Please have a look.
>
> Best,
> Rikkert
>
> --
>
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
> Your team MadDevelopers is subscribed to branch
> lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>

[lp:~maddevelopers/mg5amcnlo/v3_syntax_handler]

968. By olivier-mattelaer on 2021-04-19

set the link of rikkert for the warning/crash

[Olivier Mattelaer (olivier-mattelaer)]

Thanks Rik, this is good. I have replace the "xxxx" in the message by that link.
I guess it makes sense to wait our next meeting to be 100% sure that everyone agree before releasing it?

Cheers,

Olivier

@Richard: no aNP (or any equivalent) is not supported. Not sure it would help.

[Hua-Sheng Shao (erdissshaw)]

Hi Rikkert, thanks a lot for the efforts. Would it be possible to update the generation syntax for the examples listed in table 2 and those in subsection 6.3 (below equation 6.24) in 1804.10017, besides the general syntax. Cheers, Hua-Sheng
On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:

> I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that describes the coupling order syntax and also "fixes" the automation of EW corrections paper. Please have a look.
>
> Best,
> Rikkert
>
> --
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.

[marco zaro (marco-zaro)]

Thank you Rikkert for setting up the page!
cheers,
m

> On 19 Apr 2021, at 09:48, Hua-Sheng Shao <email address hidden> wrote:
>
> Hi Rikkert, thanks a lot for the efforts. Would it be possible to update the generation syntax for the examples listed in table 2 and those in subsection 6.3 (below equation 6.24) in 1804.10017, besides the general syntax. Cheers, Hua-Sheng
> On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:
>
>> I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that describes the coupling order syntax and also "fixes" the automation of EW corrections paper. Please have a look.
>>
>> Best,
>> Rikkert
>>
>> --
>> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>
>
> --
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.

[davide.pagani.85 (davide-pagani)]

Thanks Rik.
It looks great!

Cheers
Davide

On 19.04.21 10:00, marco zaro wrote:
> Thank you Rikkert for setting up the page!
> cheers,
> m
>
>> On 19 Apr 2021, at 09:48, Hua-Sheng Shao <email address hidden> wrote:
>>
>> Hi Rikkert, thanks a lot for the efforts. Would it be possible to update the generation syntax for the examples listed in table 2 and those in subsection 6.3 (below equation 6.24) in 1804.10017, besides the general syntax. Cheers, Hua-Sheng
>> On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:
>>
>>> I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that describes the coupling order syntax and also "fixes" the automation of EW corrections paper. Please have a look.
>>>
>>> Best,
>>> Rikkert
>>>
>>> --
>>> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
>>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>>
>> --
>> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>

[Stefano Frixione (stefano-frixione)]

Hi Rikkert,
thanks a lot for this; please find a number of minor comments below.

- General: do I understand correctly, that = and <= are identical?
   If so, I'd remove one of the two (preferably =).
- Second bullet: " strong), at the diagram level, respectively" -->
  "strong), respectively, at the diagram level".
- Fourth bullet, "requests" -> "imposes".
- Seventh bullet, "greatly adviced" -> "strongly advised"

For what concerns 1804.10017:
- First bullet, "this paper" -> "that paper"; "coupling orders need to
  be specified" -> "coupling orders had been understood"; "while, if
  interpreted...level" -> "while, if the same syntax used in 1804.10017
  were employed literally with the current version of the code, they
  would been applied at the amplitude level".
- Second bullet, "all the apperarance of" -> "all the instances of".

Cheers, Stefano.

On Sun, 18 Apr 2021, Rikkert Frederix wrote:

> I've created a small webpage, http://amcatnlo.cern.ch/co.htm , that describes the coupling order syntax and also "fixes" the automation of EW corrections paper. Please have a look.
>
> Best,
> Rikkert
>
> --
> https://code.launchpad.net/~maddevelopers/mg5amcnlo/v3_syntax_handler/+merge/400921
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>

[Rikkert Frederix (frederix)]

hi all,

Hua-Sheng: I think it's not needed to copy the examples/tables/definitions of the paper explicitly to this page. Also, because we do have have these "equations" labeled in the paper, so it's difficult to directly refer to them.

Stefano: I think we need to keep both to make sure that all is consistent and backwards compatible with the MG5_aMC (non-v3.0) code. Hence, it makes sense to list both "<=" and "=" even though they do the same, since most users will be used to using "=", while it makes formally more sense to use "<=".
Thanks for your other suggestions, I've updated the text accordingly.

Best,
Rikkert

[davide.pagani.85 (davide-pagani)]

Hi Olivier,

I started to play with it and I noticed that if I do

generate p p > t t~ QCD=1 QED=1 [/*QED*/]

I get

/Interpreting 'QED=1' as 'QED<=1'//
//Interpreting 'QCD=1' as 'QCD<=1'//
//Command "generate p p > t t~ QCD=1 QED=1 [QED]" interrupted with error://
//Exception : Potentially ambigious syntax detected. Note that the
syntax of paper 1804.10017 (used in 3.0.x) is not used anymore (since
version 3.1.0).//
//    If you want to follow the syntax of that paper, you can just
replace "QED" by "aEW" and "QCD" by "aS".//
//    More information here: http://amcatnlo.cern.ch/co.htm//
//    If you know the current meaning of the syntax you can bypass this
crash by running (once per machine) this command://
//     set acknowledged_v3.1_syntax True --global//
//Please report this bug on https://bugs.launchpad.net/mg5amcnlo//
//More information is found in 'MG5_debug'.//
//Please attach this file to your report./

and the code stops, that I think it is what we want.

If instead I do

generate p p > t t~ QCD=1 QED=1 [/*QCD*/]

I obtain:

/Potentially ambigious syntax detected. Note that the syntax of paper
1804.10017 (used in 3.0.x) is not used anymore (since version 3.1.0).//
//If you want to follow the syntax of that paper, you can just replace
"QED" by "aEW" and "QCD" by "aS".//
//More information here: http://amcatnlo.cern.ch/co.htm//
//
//Order QED is not constrained as squared_orders. Using: QED^2=2//
//Order QCD is not constrained as squared_orders. Using: QCD^2=2//
//WARNING: Use of multiparticles is non-trivial for NLO process
generation and depends on the orders included, the process considered,
as well as the PDF set chosen. See appendix D of arXiv:1804.10017
[hep-ph] for some guidance. /

and the code keeps running.

If I am not wrong, this is not what we wanted. If I remember correctly,
the first output should always appear unless one is either not
specifying QCD=* QED=* or setting QCD=99 AND QED=99 together with [QCD QED].

Marco: should also QCD=99 AND QED=99 [QCD] or QCD=99 AND QED=99 [QED]
raise an error?

Cheers
Davide

On 14.04.21 15:15, Olivier Mattelaer wrote:
> Any comment on this?
>
> I think that it does not make that much sense to wait months before releasing it (otherwise this will be even more uglier).
>
> Olivier

[Olivier Mattelaer (olivier-mattelaer)]

Hi,

Yes as I said in our last meeting (and in the merge request), I have weaken a bit the scope in which we crash and provide only a warning for a series of case where the syntax was already possible in 2.x and were the paper 1804.10017 is not an issue per say. Do you think that a warning is not enough?

> Marco: should also QCD=99 AND QED=99 [QCD] or QCD=99 AND QED=99 [QED] raise an error?

In this case they are no ambiguity and therefore I would say that even a warning is not needed.
This is for me the same case as if the user does not provide anything.
I strongly believe that we should not put warning if we know that syntaxes between 2.x, 3.x and 3.1.x are the same.
Useless warning are the best way for people to ignore them.

Cheers,

Olivier

> On 10 May 2021, at 12:54, davide.pagani.85 <email address hidden> wrote:
>
> Hi Olivier,
>
> I started to play with it and I noticed that if I do
>
> generate p p > t t~ QCD=1 QED=1 [/*QED*/]
>
> I get
>
>
> /Interpreting 'QED=1' as 'QED<=1'//
> //Interpreting 'QCD=1' as 'QCD<=1'//
> //Command "generate p p > t t~ QCD=1 QED=1 [QED]" interrupted with error://
> //Exception : Potentially ambigious syntax detected. Note that the
> syntax of paper 1804.10017 (used in 3.0.x) is not used anymore (since
> version 3.1.0).//
> // If you want to follow the syntax of that paper, you can just
> replace "QED" by "aEW" and "QCD" by "aS".//
> // More information here: http://amcatnlo.cern.ch/co.htm//
> // If you know the current meaning of the syntax you can bypass this
> crash by running (once per machine) this command://
> // set acknowledged_v3.1_syntax True --global//
> //Please report this bug on https://bugs.launchpad.net/mg5amcnlo//
> //More information is found in 'MG5_debug'.//
> //Please attach this file to your report./
>
> and the code stops, that I think it is what we want.
>
> If instead I do
>
> generate p p > t t~ QCD=1 QED=1 [/*QCD*/]
>
> I obtain:
>
> /Potentially ambigious syntax detected. Note that the syntax of paper
> 1804.10017 (used in 3.0.x) is not used anymore (since version 3.1.0).//
> //If you want to follow the syntax of that paper, you can just replace
> "QED" by "aEW" and "QCD" by "aS".//
> //More information here: http://amcatnlo.cern.ch/co.htm//
> //
> //Order QED is not constrained as squared_orders. Using: QED^2=2//
> //Order QCD is not constrained as squared_orders. Using: QCD^2=2//
> //WARNING: Use of multiparticles is non-trivial for NLO process
> generation and depends on the orders included, the process considered,
> as well as the PDF set chosen. See appendix D of arXiv:1804.10017
> [hep-ph] for some guidance. /
>
> and the code keeps running.
>
> If I am not wrong, this is not what we wanted. If I remember correctly,
> the first output should always appear unless one is either not
> specifying QCD=* QED=* or setting QCD=99 AND QED=99 together with [QCD QED].
>
> Marco: should also QCD=99 AND QED=99 [QCD] or QCD=99 AND QED=99 [QED]
> raise an error?
>
> Cheers
> Davide
>
>
>
> On 14.04.21 15:15, Olivier Mattelaer wrote:
>> Any comment on this?
>>
>> I think that it does not make that much sense to wait months before releasi...

[davide.pagani.85 (davide-pagani)]

Hi Olivier,

I think that whenever someone is doing something following the
instructions given in 1804.10017 and the code is doing something
different than what is explained in that reference not only a warning
but a stop and a request to do

set acknowledged_v3.1_syntax True --global

should appear.

This indeed happens already with

generate p p > t t~ QCD=1 QED=1 [/*QED*/]

but it does not with

generate p p > t t~ QCD=1 QED=1 [/*QCD*/]

I do not understand why there is a difference in the two cases. In the
first one it generates amplitudes contributing to LO_2 and add
corrections order alpha to the diagrams only, leading to an incomplete
and IR divergent NLO_3 (p p > t t~ QCD=0 QED=2 [/*QCD*/] is missing).
The situation is probably even worse because the only amplitude
available is    a g > t t~. In the second case it generates again
amplitudes contributing t LO_2 and add corrections order alpha_s,
leading to an incomplete and IR divergent NLO_2 (p p > t t~ QCD=2 QED=0
[/*QED*/] is missing).

So the real question is: why the reaction of the code to an old-style
syntax is different in the two previous cases?
Both are not doing what is explained in 1804.10017.

If instead I do  p p > t t~ [QED] or p p > t t~ QCD=99 QED=99 [QCD QED]
I obtain what I expect from 1804.10017. So indeed no warning is
necessary, no stop is necessary.

Concerning the part in which I mentioned Marco, I was asking a
confirmation to what you say. If indeed there is no difference with the
old syntax, warning should not be there.

Cheers
Davide

On 10.05.21 13:18, Olivier Mattelaer wrote:
> Hi,
>
> Yes as I said in our last meeting (and in the merge request), I have weaken a bit the scope in which we crash and provide only a warning for a series of case where the syntax was already possible in 2.x and were the paper 1804.10017 is not an issue per say. Do you think that a warning is not enough?
>
>> Marco: should also QCD=99 AND QED=99 [QCD] or QCD=99 AND QED=99 [QED] raise an error?
> In this case they are no ambiguity and therefore I would say that even a warning is not needed.
> This is for me the same case as if the user does not provide anything.
> I strongly believe that we should not put warning if we know that syntaxes between 2.x, 3.x and 3.1.x are the same.
> Useless warning are the best way for people to ignore them.
>
>
> Cheers,
>
> Olivier
>
>
>> On 10 May 2021, at 12:54, davide.pagani.85 <email address hidden> wrote:
>>
>> Hi Olivier,
>>
>> I started to play with it and I noticed that if I do
>>
>> generate p p > t t~ QCD=1 QED=1 [/*QED*/]
>>
>> I get
>>
>>
>> /Interpreting 'QED=1' as 'QED<=1'//
>> //Interpreting 'QCD=1' as 'QCD<=1'//
>> //Command "generate p p > t t~ QCD=1 QED=1 [QED]" interrupted with error://
>> //Exception : Potentially ambigious syntax detected. Note that the
>> syntax of paper 1804.10017 (used in 3.0.x) is not used anymore (since
>> version 3.1.0).//
>> // If you want to follow the syntax of that paper, you can just
>> replace "QED" by "aEW" and "QCD" by "aS".//
>> // More information here: http://amcatnlo.cern.ch/co.htm//
>> // If you know the current meaning of the syntax you can bypass this
>> crash ...

[marco zaro (marco-zaro)]

Hi,
I would have the same behaviour in the two cases that Davide considered. I do not see any motivation to have a crash for [QED] (computing NLO3) and a warning for [QCD] (NLO2), when both cases receive mixed QCD-EW corrections.
I would consider QED=99, QCD=99 as a syntax that does not need any warning. In general, this **could** be the case for any order constraint that does not discard any diagram (I am not saying that this should be implemented). The absence of constraint should automatically lead the code to consider the maximally-QCD amplitude (LO1), with the proper squared-order constraints.

Cheers,

Marco

> On 10 May 2021, at 13:18, Olivier Mattelaer <email address hidden> wrote:
>
> Hi,
>
> Yes as I said in our last meeting (and in the merge request), I have weaken a bit the scope in which we crash and provide only a warning for a series of case where the syntax was already possible in 2.x and were the paper 1804.10017 is not an issue per say. Do you think that a warning is not enough?
>
>> Marco: should also QCD=99 AND QED=99 [QCD] or QCD=99 AND QED=99 [QED] raise an error?
>
> In this case they are no ambiguity and therefore I would say that even a warning is not needed.
> This is for me the same case as if the user does not provide anything.
> I strongly believe that we should not put warning if we know that syntaxes between 2.x, 3.x and 3.1.x are the same.
> Useless warning are the best way for people to ignore them.
>
>
> Cheers,
>
> Olivier
>
>
>> On 10 May 2021, at 12:54, davide.pagani.85 <<email address hidden> <mailto:<email address hidden>>> wrote:
>>
>> Hi Olivier,
>>
>> I started to play with it and I noticed that if I do
>>
>> generate p p > t t~ QCD=1 QED=1 [/*QED*/]
>>
>> I get
>>
>>
>> /Interpreting 'QED=1' as 'QED<=1'//
>> //Interpreting 'QCD=1' as 'QCD<=1'//
>> //Command "generate p p > t t~ QCD=1 QED=1 [QED]" interrupted with error://
>> //Exception : Potentially ambigious syntax detected. Note that the
>> syntax of paper 1804.10017 (used in 3.0.x) is not used anymore (since
>> version 3.1.0).//
>> // If you want to follow the syntax of that paper, you can just
>> replace "QED" by "aEW" and "QCD" by "aS".//
>> // More information here: http://amcatnlo.cern.ch/co.htm//
>> // If you know the current meaning of the syntax you can bypass this
>> crash by running (once per machine) this command://
>> // set acknowledged_v3.1_syntax True --global//
>> //Please report this bug on https://bugs.launchpad.net/mg5amcnlo//
>> //More information is found in 'MG5_debug'.//
>> //Please attach this file to your report./
>>
>> and the code stops, that I think it is what we want.
>>
>> If instead I do
>>
>> generate p p > t t~ QCD=1 QED=1 [/*QCD*/]
>>
>> I obtain:
>>
>> /Potentially ambigious syntax detected. Note that the syntax of paper
>> 1804.10017 (used in 3.0.x) is not used anymore (since version 3.1.0).//
>> //If you want to follow the syntax of that paper, you can just replace
>> "QED" by "aEW" and "QCD" by "aS".//
>> //More information here: http://amcatnlo.cern.ch/co.htm//
>> //
>> //Order QED is not constrained as squared_orders. Using: QED^2=2//
>> //Order QCD is not cons...

[Olivier Mattelaer (olivier-mattelaer)]

Ok,

So I guess this is valid for all the test case in my unnitest
# check case where the code write a warning (critical level)
right?

The rest are fine.

Cheers,

Olivier

[lp:~maddevelopers/mg5amcnlo/v3_syntax_handler]

969. By olivier-mattelaer on 2021-05-10

remove the warnning level

[Olivier Mattelaer (olivier-mattelaer)]

Sorry my last message was not clear.

So I have update the unittest to remove the warning category.
And also already fix the code to pass the new test.

So do you see any case where a warning would be in order?
Or do you see any additional case that my test should check?

Olivier

[davide.pagani.85 (davide-pagani)]

Hi,

It seems to me that now the stop works correctly, in this context I do
not see a case where a Warning is necessary.

Now, if I do

set acknowledged_v3.1_syntax True --global

the codes does not stop and runs as expected.
However, if I do

generate p p > t t~ QCD=1 QED=1 [QCD]

I obtain

Interpreting 'QED=1' as 'QED<=1'
Interpreting 'QCD=1' as 'QCD<=1'
Order QED is not constrained as squared_orders. Using: QED^2=2
Order QCD is not constrained as squared_orders. Using: QCD^2=2
WARNING: Use of multiparticles is non-trivial for NLO process generation
and depends on the orders included, the process considered, as well as
the PDF set chosen. See appendix D of arXiv:1804.10017 [hep-ph] for some
guidance.
INFO: Generating FKS-subtracted matrix elements for born process: g g >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: g a >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: u u~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: c c~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: d d~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: s s~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: u~ u >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: c~ c >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (8 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: d~ d >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (9 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: s~ s >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (10 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: b b~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (11 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: b~ b >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (12 / 13)
INFO: Generating FKS-subtracted matrix elements for born process: a g >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (13 / 13)
INFO: Generating virtual matrix element with MadLoop for process: g g >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)

I do not understand if

Order QED is not constrained as squared_orders. Using: QED^2=2
Order QCD is not constrained as squared_orders. Using: QCD^2=2

is a suggestion or a description of what is happening. If it is the
latter, it is not what we want I guess. The command set
acknowledged_v3.1_syntax True --global I thought allows the expert users
to play with amplitudes and not squared orders, regardless of IR
finiteness or consistency.

On the other hand, by looking at the code generated it seems  that is
/*partially*/ doing what we expect, since virtual matrix elements are
present only in the directories P0_ag_ttx and P0_ga_ttx, that is the
code should produce the Born amplitude only for ag_ttx or ga_ttx
(although I see born.f in all folders) and builds QCD Virtuals only for
that.
I thought  the code builds a...

[Olivier Mattelaer (olivier-mattelaer)]

Hi Davide,

> is a suggestion or a description of what is happening.

It is a description of the value used.
(which I think makes sense if such limitation are meant for the born --that's the case right?--)

But this has nothing to do with the flag
"acknowledged_v3.1_syntax" (and therefore this review)

This is the same behaviour as the 3.1.0 release that we agree to release.
So I'm a bit worried about your comment on this.
I would propose that you create a bug report and that we discuss the situation in that thread.

Such that we can approve this merge, and then we can obviously discuss if that bug report is worth to postpose the release of 3.1.1 (with this branch and other small patch) or not.

Cheers,

Olivier

> On 12 May 2021, at 14:21, davide.pagani.85 <email address hidden> wrote:
>
> Hi,
>
> It seems to me that now the stop works correctly, in this context I do
> not see a case where a Warning is necessary.
>
> Now, if I do
>
> set acknowledged_v3.1_syntax True --global
>
> the codes does not stop and runs as expected.
> However, if I do
>
> generate p p > t t~ QCD=1 QED=1 [QCD]
>
> I obtain
>
> Interpreting 'QED=1' as 'QED<=1'
> Interpreting 'QCD=1' as 'QCD<=1'
> Order QED is not constrained as squared_orders. Using: QED^2=2
> Order QCD is not constrained as squared_orders. Using: QCD^2=2
> WARNING: Use of multiparticles is non-trivial for NLO process generation
> and depends on the orders included, the process considered, as well as
> the PDF set chosen. See appendix D of arXiv:1804.10017 [hep-ph] for some
> guidance.
> INFO: Generating FKS-subtracted matrix elements for born process: g g >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: g a >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: u u~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: c c~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: d d~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: s s~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: u~ u >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: c~ c >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (8 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: d~ d >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (9 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: s~ s >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (10 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: b b~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (11 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: b~ b >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (12 / 13)
> INFO: Generating FKS-subtracted matrix elements for born process: a g >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (13 / 13)
> INFO: Generating virtual matrix element ...

[marco zaro (marco-zaro)]

Hi,
As olivier said, the message
>> Order QED is not constrained as squared_orders. Using: QED^2=2
>> Order QCD is not constrained as squared_orders. Using: QCD^2=2
is what the code does, internally.
However, squared orders are applied **on top of** the usual orders, and the orders always put stronger constraints than the corresponding squared orders.
So I would say yes, this is expected and (should be) consistent with what the user asks.

Cheers,

Marco

> On 12 May 2021, at 15:12, Olivier Mattelaer <email address hidden> wrote:
>
> Hi Davide,
>
>> is a suggestion or a description of what is happening.
>
> It is a description of the value used.
> (which I think makes sense if such limitation are meant for the born --that's the case right?--)
>
> But this has nothing to do with the flag
> "acknowledged_v3.1_syntax" (and therefore this review)
>
> This is the same behaviour as the 3.1.0 release that we agree to release.
> So I'm a bit worried about your comment on this.
> I would propose that you create a bug report and that we discuss the situation in that thread.
>
> Such that we can approve this merge, and then we can obviously discuss if that bug report is worth to postpose the release of 3.1.1 (with this branch and other small patch) or not.
>
> Cheers,
>
> Olivier
>
>
>
>
>
>> On 12 May 2021, at 14:21, davide.pagani.85 <<email address hidden> <mailto:<email address hidden>>> wrote:
>>
>> Hi,
>>
>> It seems to me that now the stop works correctly, in this context I do
>> not see a case where a Warning is necessary.
>>
>> Now, if I do
>>
>> set acknowledged_v3.1_syntax True --global
>>
>> the codes does not stop and runs as expected.
>> However, if I do
>>
>> generate p p > t t~ QCD=1 QED=1 [QCD]
>>
>> I obtain
>>
>> Interpreting 'QED=1' as 'QED<=1'
>> Interpreting 'QCD=1' as 'QCD<=1'
>> Order QED is not constrained as squared_orders. Using: QED^2=2
>> Order QCD is not constrained as squared_orders. Using: QCD^2=2
>> WARNING: Use of multiparticles is non-trivial for NLO process generation
>> and depends on the orders included, the process considered, as well as
>> the PDF set chosen. See appendix D of arXiv:1804.10017 [hep-ph] for some
>> guidance.
>> INFO: Generating FKS-subtracted matrix elements for born process: g g >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: g a >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: u u~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: c c~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: d d~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: s s~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: u~ u >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
>> INFO: Generating FKS-subtracted matrix elements for born process: c~ c >
>> t t~ QCD<=2 QED<=1 QCD^2=4 Q...

[marco zaro (marco-zaro)]

Hi Olivier,
after all this, I think it is good to go

Thanks a lot!
Cheers,

Marco

review: Approve

[Olivier Mattelaer (olivier-mattelaer)]

Hi Davide,

Do you agree on the merge? Or should we have a meeting about this?

Olivier

[davide.pagani.85 (davide-pagani)]

Thanks Olivier!

I think it can be approved, bearing in mind that when using the old syntax QCD=X QED=Y

For the general user:

- fine, the code stops when it is required to do things with the old
syntax that are different to what one would expect from the 2018 paper.

For the expert user:

- if one types "set acknowledged_v3.1_syntax True --global" it is not
clear what is happening. Borns are produced for folders where they
should not be produced, real radiations are not present in folders where
I guess should also be present. Virtuals seems to be done correctly

Since it is not obvious how the code should behave for QCD=X QED=Y in the expert mode (it leads to a calculation of something that is not well defined) we can leave this issue open up to the moment when someone will need to use it.

review: Approve

=== modified file 'input/.mg5_configuration_default.txt'
--- input/.mg5_configuration_default.txt	2020-09-18 11:00:14 +0000
+++ input/.mg5_configuration_default.txt	2021-05-10 20:52:12 +0000
@@ -25,6 +25,13 @@
 #    one version of MG5. 
 #
 ################################################################################
+
+#! Allow/Refuse syntax that changed meaning in version 3.1 of the code
+#! (Compare to 3.0, 3.1 is back to the meaning of 2.x branch)
+#!
+# acknowledged_v3.1_syntax = False
+
+
 #! Prefered Fortran Compiler
 #! If None: try to find g77 or gfortran on the system
 #!

=== modified file 'madgraph/interface/loop_interface.py'
--- madgraph/interface/loop_interface.py	2021-02-08 22:58:11 +0000
+++ madgraph/interface/loop_interface.py	2021-05-10 20:52:12 +0000
@@ -282,6 +282,18 @@
 """
             logger.warning(msg%proc.nice_string().replace('Process:','process'))
 
+        if proc['perturbation_couplings'] and proc['orders'] and not proc['squared_orders']:
+            if any(val not in [0,99] for val in proc['orders'].values()):
+                message = "Potentially ambigious syntax detected. Note that the syntax of paper 1804.10017 (used in 3.0.x) is not used anymore (since version 3.1.0).\n" +\
+                    'If you want to follow the syntax of that paper, you can just replace "QED" by "aEW" and "QCD" by "aS".\n' +\
+                    'More information here: http://amcatnlo.cern.ch/co.htm\n'
+                if not self.options['acknowledged_v3.1_syntax']:
+                    raise Exception(message+ 'If you know the current meaning of the syntax you can bypass this crash by running (once per machine) this command:\n set acknowledged_v3.1_syntax True --global')
+
+
+
+
+
     def validate_model(self, loop_type='virtual',coupling_type=['QCD'], stop=True):
         """ Upgrade the model sm to loop_sm if needed """
 

=== modified file 'madgraph/interface/madgraph_interface.py'
--- madgraph/interface/madgraph_interface.py	2021-03-29 21:43:03 +0000
+++ madgraph/interface/madgraph_interface.py	2021-05-10 20:52:12 +0000
@@ -823,6 +823,9 @@
         logger.info(" > (default: False) If set on True any python2 UFO model will be automatically converted to pyton3 format")   
         logger.info("nlo_mixed_expansion <value>",'$MG:color:GREEN') 
         logger.info("deactivates mixed expansion support at NLO, goes back to MG5aMCv2 behavior")
+        logger.info("acknowledged_v3.1_syntax <value>",'$MG:color:GREEN') 
+        logger.info("if set to True allows to use syntax which have change meaning between 3.0 and 3.1 version")
+
           
 #===============================================================================
 # CheckValidForCmd
@@ -2978,6 +2981,7 @@
                        'output_dependencies':'external',
                        'crash_on_error':False,
                        'auto_convert_model': False,
+                       'acknowledged_v3.1_syntax': False
                        }
 
     options_madgraph= {'group_subprocesses': 'Auto',
@@ -7898,7 +7902,7 @@
             else:
                 raise self.InvalidCmd('expected bool for notification_center')
         # True/False formatting
-        elif args[0] in ['crash_on_error', 'auto_convert_model']:
+        elif args[0] in ['crash_on_error', 'auto_convert_model', 'acknowledged_v3.1_syntax']:
             try:
                 tmp = banner_module.ConfigFile.format_variable(args[1], bool, args[0])
             except Exception:

=== added file 'tests/unit_tests/interface/test_amcatnlo.py'
--- tests/unit_tests/interface/test_amcatnlo.py	1970-01-01 00:00:00 +0000
+++ tests/unit_tests/interface/test_amcatnlo.py	2021-05-10 20:52:12 +0000
@@ -0,0 +1,110 @@
+##############################################################################
+#
+# Copyright (c) 2010 The MadGraph5_aMC@NLO Development team and Contributors
+#
+# This file is a part of the MadGraph5_aMC@NLO project, an application which 
+# automatically generates Feynman diagrams and matrix elements for arbitrary
+# high-energy processes in the Standard Model and beyond.
+#
+# It is subject to the MadGraph5_aMC@NLO license which should accompany this 
+# distribution.
+#
+# For more information, visit madgraph.phys.ucl.ac.be and amcatnlo.web.cern.ch
+#
+################################################################################
+from __future__ import absolute_import
+from cmd import Cmd
+""" Basic test of the command interface """
+
+import unittest
+import madgraph
+
+import madgraph.interface.master_interface as master_cmd
+import madgraph.interface.madgraph_interface  as mg_cmd
+import madgraph.interface.extended_cmd as ext_cmd
+import madgraph.interface.amcatnlo_interface as mecmd
+import madgraph.various.misc as misc
+import os
+from six import StringIO
+import logging
+
+root_path = os.path.split(os.path.dirname(os.path.realpath( __file__ )))[0]
+root_path = os.path.dirname(root_path)
+# root_path is ./tests
+pjoin = os.path.join
+
+class MGerror(Exception): pass
+
+class TestMadEventCmd(unittest.TestCase):
+    """ check if the ValidCmd works correctly """
+    
+        
+    def test_v31_syntax_crash(self):
+        """Check that process with ambiguous syntax correctly crashes if the flag is not set correctly
+        """
+        #cmd = mecmd.aMCatNLOInterface()
+        #category = set()
+        #valid_command = [c for c in dir(cmd) if c.startswith('do_')]
+
+        interface = master_cmd.MasterCmd()
+        interface.no_notification()
+        interface.do_import('model loop_qcd_qed_sm')
+        
+        #run_cmd('import model %s' % model)
+
+        stream = StringIO()
+        handler_stream = logging.StreamHandler(stream)
+        log = logging.getLogger('cmdprint')
+        log.setLevel(logging.CRITICAL)
+
+        for handler in log.handlers: 
+            log.removeHandler(handler)
+        log.addHandler(handler_stream)
+
+
+        def check_message(line):
+            """return False if not warning is raised, return True is a warning is raised"""
+            
+            stream.seek(0)
+            stream.truncate(0)
+            myprocdef = interface.extract_process(line)
+            try: 
+                interface.proc_validity(myprocdef,'aMCatNLO_all')
+            except Exception as error:
+                if '1804.10017' in str(error):
+                    raise MGerror
+
+            text = stream.getvalue()
+            if '1804.10017' in text:
+                return True
+            else:
+                return False
+
+        # force the option to not by bypassed
+        interface.options['acknowledged_v3.1_syntax'] = False
+
+        # check case where the code crash
+        self.assertRaises(MGerror, check_message, "p p > t t~ QED=1 [QED]")
+        self.assertRaises(MGerror,check_message, "p p > t t~ QCD=1 [QED QCD]")
+
+        # check case where the code write a warning (critical level)
+        self.assertRaises(MGerror, check_message, "p p > t t~ QED=1 [QCD]")
+        self.assertRaises(MGerror, check_message, "p p > t t~ QCD=1 QED=0 [QCD]")
+        self.assertRaises(MGerror, check_message, "p p > t t~ QED=98 [QCD]")
+        self.assertRaises(MGerror, check_message, "p p > t t~ QED=99 QCD=1 [QCD]")
+        # check case where the code does not complain
+        self.assertFalse(check_message("p p > t t~ QED=0 [QCD]"))
+        self.assertFalse(check_message("p p > t t~ / z QCD=0 [QCD]"))
+        self.assertFalse(check_message("p p > t t~ QCD=1 QED^2==2 [QCD]"))
+        self.assertFalse(check_message("p p > w+ w- QED=99 [QCD]"))
+        self.assertFalse(check_message("p p > w+ w- j j $ h QED<=99 [QCD]"))
+
+        # force the option to not  be by bypassed
+        interface.options['acknowledged_v3.1_syntax'] = True 
+        # and check that no crash/warning is raised anymore
+        self.assertFalse(check_message( "p p > t t~ QED=1 [QED]"))
+        self.assertFalse(check_message( "p p > t t~ QCD=1 [QED QCD]"))
+        self.assertFalse(check_message("p p > t t~ QED=1 [QCD]"))
+        self.assertFalse(check_message("p p > t t~ QCD=1 QED=0 [QCD]"))
+        self.assertFalse(check_message("p p > t t~ QED=98 [QCD]"))
+        self.assertFalse(check_message("p p > t t~ QED=99 QCD=1 [QCD]"))