Merge lp:~maddevelopers/mg5amcnlo/v3_syntax_handler into lp:mg5amcnlo
 v3_syntax_handler
 Merge into 3.x
Status:  Merged 

Merged at revision:  966 
Proposed branch:  lp:~maddevelopers/mg5amcnlo/v3_syntax_handler 
Merge into:  lp:mg5amcnlo 
Diff against target: 
186 lines (+134/1) 4 files modified
input/.mg5_configuration_default.txt (+7/0) madgraph/interface/loop_interface.py (+12/0) madgraph/interface/madgraph_interface.py (+5/1) tests/unit_tests/interface/test_amcatnlo.py (+110/0) 
To merge this branch:  bzr merge lp:~maddevelopers/mg5amcnlo/v3_syntax_handler 
Related bugs: 
Reviewer  Review Type  Date Requested  Status 

davide.pagani.85 (community)  Approve  
marco zaro  Approve  
Review via email: mp+400921@code.launchpad.net 
Commit message
Description of the change
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 (oliviermattelaer) wrote :  # 
Rikkert Frederix (frederix) wrote :  # 
I've created a small webpage, http://
Best,
Rikkert
Richard Ruiz (rruiz) wrote :  # 
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://
> describes the coupling order syntax and also "fixes" the automation of EW
> corrections paper. Please have a look.
>
> Best,
> Rikkert
>
> 
>
> https:/
> Your team MadDevelopers is subscribed to branch
> lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>
 968. By oliviermattelaer

set the link of rikkert for the warning/crash
Olivier Mattelaer (oliviermattelaer) wrote :  # 
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.
HuaSheng Shao (erdissshaw) 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, HuaSheng
On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:
> I've created a small webpage, http://
>
> Best,
> Rikkert
>
> 
> https:/
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
marco zaro (marcozaro) wrote :  # 
Thank you Rikkert for setting up the page!
cheers,
m
> On 19 Apr 2021, at 09:48, HuaSheng 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, HuaSheng
> On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:
>
>> I've created a small webpage, http://
>>
>> Best,
>> Rikkert
>>
>> 
>> https:/
>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>
>
> 
> https:/
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
davide.pagani.85 (davidepagani) wrote :  # 
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, HuaSheng 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, HuaSheng
>> On Apr 18, 2021, at 9:01 PM, Rikkert Frederix <email address hidden> wrote:
>>
>>> I've created a small webpage, http://
>>>
>>> Best,
>>> Rikkert
>>>
>>> 
>>> https:/
>>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>>
>> 
>> https:/
>> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>
Stefano Frixione (stefanofrixione) wrote :  # 
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.
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://
>
> Best,
> Rikkert
>
> 
> https:/
> Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/v3_syntax_handler.
>
Rikkert Frederix (frederix) wrote :  # 
hi all,
HuaSheng: I think it's not needed to copy the examples/
Stefano: I think we need to keep both to make sure that all is consistent and backwards compatible with the MG5_aMC (nonv3.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 (davidepagani) 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://
// If you know the current meaning of the syntax you can bypass this
crash by running (once per machine) this command://
// set acknowledged_
//Please report this bug on https:/
//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://
//
//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 nontrivial 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
[hepph] 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 (oliviermattelaer) 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://
> // If you know the current meaning of the syntax you can bypass this
> crash by running (once per machine) this command://
> // set acknowledged_
> //Please report this bug on https:/
> //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://
> //
> //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 nontrivial 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
> [hepph] 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 (davidepagani) wrote :  # 
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_
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 oldstyle
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://
>> // If you know the current meaning of the syntax you can bypass this
>> crash ...
marco zaro (marcozaro) wrote :  # 
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 QCDEW 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 maximallyQCD amplitude (LO1), with the proper squaredorder 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://
>> // If you know the current meaning of the syntax you can bypass this
>> crash by running (once per machine) this command://
>> // set acknowledged_
>> //Please report this bug on https:/
>> //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://
>> //
>> //Order QED is not constrained as squared_orders. Using: QED^2=2//
>> //Order QCD is not cons...
Olivier Mattelaer (oliviermattelaer) wrote :  # 
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
 969. By oliviermattelaer

remove the warnning level
Olivier Mattelaer (oliviermattelaer) wrote :  # 
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 (davidepagani) 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_
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 nontrivial 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 [hepph] for some
guidance.
INFO: Generating FKSsubtracted matrix elements for born process: g g >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: g a >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: u u~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: c c~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: d d~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: s s~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: u~ u >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: c~ c >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (8 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: d~ d >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (9 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: s~ s >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (10 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: b b~ >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (11 / 13)
INFO: Generating FKSsubtracted matrix elements for born process: b~ b >
t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (12 / 13)
INFO: Generating FKSsubtracted 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_
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 (oliviermattelaer) 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_
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_
>
> 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 nontrivial 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 [hepph] for some
> guidance.
> INFO: Generating FKSsubtracted matrix elements for born process: g g >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: g a >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: u u~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: c c~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: d d~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: s s~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: u~ u >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: c~ c >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (8 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: d~ d >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (9 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: s~ s >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (10 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: b b~ >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (11 / 13)
> INFO: Generating FKSsubtracted matrix elements for born process: b~ b >
> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (12 / 13)
> INFO: Generating FKSsubtracted 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 (marcozaro) wrote :  # 
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_
>
> 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_
>>
>> 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 nontrivial 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 [hepph] for some
>> guidance.
>> INFO: Generating FKSsubtracted matrix elements for born process: g g >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (1 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: g a >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (2 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: u u~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (3 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: c c~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (4 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: d d~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (5 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: s s~ >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (6 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: u~ u >
>> t t~ QCD<=2 QED<=1 QCD^2=4 QED^2=2 (7 / 13)
>> INFO: Generating FKSsubtracted matrix elements for born process: c~ c >
>> t t~ QCD<=2 QED<=1 QCD^2=4 Q...
marco zaro (marcozaro) wrote :  # 
Hi Olivier,
after all this, I think it is good to go
Thanks a lot!
Cheers,
Marco
Olivier Mattelaer (oliviermattelaer) wrote :  # 
Hi Davide,
Do you agree on the merge? Or should we have a meeting about this?
Olivier
davide.pagani.85 (davidepagani) wrote :  # 
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_
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.
Preview Diff
1  === modified file 'input/.mg5_configuration_default.txt' 
2   input/.mg5_configuration_default.txt 20200918 11:00:14 +0000 
3  +++ input/.mg5_configuration_default.txt 20210510 20:52:12 +0000 
4  @@ 25,6 +25,13 @@ 
5  # one version of MG5. 
6  # 
7  ################################################################################ 
8  + 
9  +#! Allow/Refuse syntax that changed meaning in version 3.1 of the code 
10  +#! (Compare to 3.0, 3.1 is back to the meaning of 2.x branch) 
11  +#! 
12  +# acknowledged_v3.1_syntax = False 
13  + 
14  + 
15  #! Prefered Fortran Compiler 
16  #! If None: try to find g77 or gfortran on the system 
17  #! 
18  
19  === modified file 'madgraph/interface/loop_interface.py' 
20   madgraph/interface/loop_interface.py 20210208 22:58:11 +0000 
21  +++ madgraph/interface/loop_interface.py 20210510 20:52:12 +0000 
22  @@ 282,6 +282,18 @@ 
23  """ 
24  logger.warning(msg%proc.nice_string().replace('Process:','process')) 
25  
26  + if proc['perturbation_couplings'] and proc['orders'] and not proc['squared_orders']: 
27  + if any(val not in [0,99] for val in proc['orders'].values()): 
28  + 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" +\ 
29  + 'If you want to follow the syntax of that paper, you can just replace "QED" by "aEW" and "QCD" by "aS".\n' +\ 
30  + 'More information here: http://amcatnlo.cern.ch/co.htm\n' 
31  + if not self.options['acknowledged_v3.1_syntax']: 
32  + 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') 
33  + 
34  + 
35  + 
36  + 
37  + 
38  def validate_model(self, loop_type='virtual',coupling_type=['QCD'], stop=True): 
39  """ Upgrade the model sm to loop_sm if needed """ 
40  
41  
42  === modified file 'madgraph/interface/madgraph_interface.py' 
43   madgraph/interface/madgraph_interface.py 20210329 21:43:03 +0000 
44  +++ madgraph/interface/madgraph_interface.py 20210510 20:52:12 +0000 
45  @@ 823,6 +823,9 @@ 
46  logger.info(" > (default: False) If set on True any python2 UFO model will be automatically converted to pyton3 format") 
47  logger.info("nlo_mixed_expansion <value>",'$MG:color:GREEN') 
48  logger.info("deactivates mixed expansion support at NLO, goes back to MG5aMCv2 behavior") 
49  + logger.info("acknowledged_v3.1_syntax <value>",'$MG:color:GREEN') 
50  + logger.info("if set to True allows to use syntax which have change meaning between 3.0 and 3.1 version") 
51  + 
52  
53  #=============================================================================== 
54  # CheckValidForCmd 
55  @@ 2978,6 +2981,7 @@ 
56  'output_dependencies':'external', 
57  'crash_on_error':False, 
58  'auto_convert_model': False, 
59  + 'acknowledged_v3.1_syntax': False 
60  } 
61  
62  options_madgraph= {'group_subprocesses': 'Auto', 
63  @@ 7898,7 +7902,7 @@ 
64  else: 
65  raise self.InvalidCmd('expected bool for notification_center') 
66  # True/False formatting 
67   elif args[0] in ['crash_on_error', 'auto_convert_model']: 
68  + elif args[0] in ['crash_on_error', 'auto_convert_model', 'acknowledged_v3.1_syntax']: 
69  try: 
70  tmp = banner_module.ConfigFile.format_variable(args[1], bool, args[0]) 
71  except Exception: 
72  
73  === added file 'tests/unit_tests/interface/test_amcatnlo.py' 
74   tests/unit_tests/interface/test_amcatnlo.py 19700101 00:00:00 +0000 
75  +++ tests/unit_tests/interface/test_amcatnlo.py 20210510 20:52:12 +0000 
76  @@ 0,0 +1,110 @@ 
77  +############################################################################## 
78  +# 
79  +# Copyright (c) 2010 The MadGraph5_aMC@NLO Development team and Contributors 
80  +# 
81  +# This file is a part of the MadGraph5_aMC@NLO project, an application which 
82  +# automatically generates Feynman diagrams and matrix elements for arbitrary 
83  +# highenergy processes in the Standard Model and beyond. 
84  +# 
85  +# It is subject to the MadGraph5_aMC@NLO license which should accompany this 
86  +# distribution. 
87  +# 
88  +# For more information, visit madgraph.phys.ucl.ac.be and amcatnlo.web.cern.ch 
89  +# 
90  +################################################################################ 
91  +from __future__ import absolute_import 
92  +from cmd import Cmd 
93  +""" Basic test of the command interface """ 
94  + 
95  +import unittest 
96  +import madgraph 
97  + 
98  +import madgraph.interface.master_interface as master_cmd 
99  +import madgraph.interface.madgraph_interface as mg_cmd 
100  +import madgraph.interface.extended_cmd as ext_cmd 
101  +import madgraph.interface.amcatnlo_interface as mecmd 
102  +import madgraph.various.misc as misc 
103  +import os 
104  +from six import StringIO 
105  +import logging 
106  + 
107  +root_path = os.path.split(os.path.dirname(os.path.realpath( __file__ )))[0] 
108  +root_path = os.path.dirname(root_path) 
109  +# root_path is ./tests 
110  +pjoin = os.path.join 
111  + 
112  +class MGerror(Exception): pass 
113  + 
114  +class TestMadEventCmd(unittest.TestCase): 
115  + """ check if the ValidCmd works correctly """ 
116  + 
117  + 
118  + def test_v31_syntax_crash(self): 
119  + """Check that process with ambiguous syntax correctly crashes if the flag is not set correctly 
120  + """ 
121  + #cmd = mecmd.aMCatNLOInterface() 
122  + #category = set() 
123  + #valid_command = [c for c in dir(cmd) if c.startswith('do_')] 
124  + 
125  + interface = master_cmd.MasterCmd() 
126  + interface.no_notification() 
127  + interface.do_import('model loop_qcd_qed_sm') 
128  + 
129  + #run_cmd('import model %s' % model) 
130  + 
131  + stream = StringIO() 
132  + handler_stream = logging.StreamHandler(stream) 
133  + log = logging.getLogger('cmdprint') 
134  + log.setLevel(logging.CRITICAL) 
135  + 
136  + for handler in log.handlers: 
137  + log.removeHandler(handler) 
138  + log.addHandler(handler_stream) 
139  + 
140  + 
141  + def check_message(line): 
142  + """return False if not warning is raised, return True is a warning is raised""" 
143  + 
144  + stream.seek(0) 
145  + stream.truncate(0) 
146  + myprocdef = interface.extract_process(line) 
147  + try: 
148  + interface.proc_validity(myprocdef,'aMCatNLO_all') 
149  + except Exception as error: 
150  + if '1804.10017' in str(error): 
151  + raise MGerror 
152  + 
153  + text = stream.getvalue() 
154  + if '1804.10017' in text: 
155  + return True 
156  + else: 
157  + return False 
158  + 
159  + # force the option to not by bypassed 
160  + interface.options['acknowledged_v3.1_syntax'] = False 
161  + 
162  + # check case where the code crash 
163  + self.assertRaises(MGerror, check_message, "p p > t t~ QED=1 [QED]") 
164  + self.assertRaises(MGerror,check_message, "p p > t t~ QCD=1 [QED QCD]") 
165  + 
166  + # check case where the code write a warning (critical level) 
167  + self.assertRaises(MGerror, check_message, "p p > t t~ QED=1 [QCD]") 
168  + self.assertRaises(MGerror, check_message, "p p > t t~ QCD=1 QED=0 [QCD]") 
169  + self.assertRaises(MGerror, check_message, "p p > t t~ QED=98 [QCD]") 
170  + self.assertRaises(MGerror, check_message, "p p > t t~ QED=99 QCD=1 [QCD]") 
171  + # check case where the code does not complain 
172  + self.assertFalse(check_message("p p > t t~ QED=0 [QCD]")) 
173  + self.assertFalse(check_message("p p > t t~ / z QCD=0 [QCD]")) 
174  + self.assertFalse(check_message("p p > t t~ QCD=1 QED^2==2 [QCD]")) 
175  + self.assertFalse(check_message("p p > w+ w QED=99 [QCD]")) 
176  + self.assertFalse(check_message("p p > w+ w j j $ h QED<=99 [QCD]")) 
177  + 
178  + # force the option to not be by bypassed 
179  + interface.options['acknowledged_v3.1_syntax'] = True 
180  + # and check that no crash/warning is raised anymore 
181  + self.assertFalse(check_message( "p p > t t~ QED=1 [QED]")) 
182  + self.assertFalse(check_message( "p p > t t~ QCD=1 [QED QCD]")) 
183  + self.assertFalse(check_message("p p > t t~ QED=1 [QCD]")) 
184  + self.assertFalse(check_message("p p > t t~ QCD=1 QED=0 [QCD]")) 
185  + self.assertFalse(check_message("p p > t t~ QED=98 [QCD]")) 
186  + self.assertFalse(check_message("p p > t t~ QED=99 QCD=1 [QCD]")) 
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