reweight_interface.py CRITICAL error

Asked by Riccardo on 2021-01-19

Dear experts,

I am using MG5 v2.6.5 together with SMEFTsim_A_U35_MwScheme_UFO model and I am generating Vector Boson Scattering (VBS) processes: I managed to generate ZW- and ZW+, thanks to the patch that Olivier provided me here ( https://answers.launchpad.net/mg5amcnlo/+question/694807 ), but when I try to generate ZZ VBS, I get the following error during the reweighting step:

INFO: Running Reweighting
change helicity False
change rwgt_dir rwgt
launch
INFO: detected model: SMEFTsim_A_U35_MwScheme_UFO_v3_1-cHbox_massless. Loading...
INFO: generating the square matrix element for reweighting
INFO: generate p p > z z j j QCD=0 SMHLOOP=0 NP=1, z > l+ l- NP=1, z > j j NP=1 @0 NP=1 ;
INFO: Done 218
CRITICAL: tag, onedir =  ((-4, 4), (-13, -4, -2, 2, 4, 13)) rw_me [reweight_interface.py at line 1803]
CRITICAL: data[tag][:-1] = (([4, -4], [-13, 13, 4, -4, 2, -2]), '/home/genproductions/bin/gridpacks/ZZ_cHbox_SM_LI_QU/ZZ_cHbox_SM_LI_QU_gridpack/work/process/madevent/rwgt/rw_me/SubProcesses') [reweight_interface.py at line 1804]
CRITICAL: order, pdir, = ([4, -4], [-13, 13, 2, -2, 4, -4]) /home/genproductions/bin/gridpacks/ZZ_cHbox_SM_LI_QU/ZZ_cHbox_SM_LI_QU_gridpack/work/process/madevent/rwgt/rw_me/SubProcesses reweight_interface.py at line 1805

Thanks in advance for your support.

Kind Regards,

Riccardo

Question information

Language:
English Edit question
Status:
Answered
For:
MadGraph5_aMC@NLO Edit question
Assignee:
No assignee Edit question
Last query:
2021-01-19
Last reply:
2021-01-19

Yes this is one of the limitation of the re-weighting procedure.
The issue is that you have jet comming from the production matrix-element and jet coming from the decay.
And the reweighting module is not able to distinguish which jet of the lhe event need to be used where.

We do have a way to handle that (in principle) in newer version of the code, but this requires that the order of the particle in the lhef is ordered in the exact same way as the mg5 syntax (which is not 100% guarantee by our code but it is very often the case).

Looks like this has been introduced within 2.6.6 (according to the update note):

      OM: Add an option "keep_ordering" for reweighting feature to allow to sometimes use decay chain even if you have ambiguity between final state particles.

I found the following change to the code, but I'm pretty sure that this was not enough and that this was likely creating other issue (maybe for other processes I do not remember) so it is likely that you need some additional patches (so I strongly discourage you to use those in general --at most only for this specific production --)
https://bazaar.launchpad.net/~mg5core1/mg5amcnlo/2.6.6/revision/318
https://bazaar.launchpad.net/~mg5core1/mg5amcnlo/2.6.6/revision/319

Cheers,

Olivier

> On 19 Jan 2021, at 11:55, Riccardo <email address hidden> wrote:
>
> New question #695083 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/695083
>
> Dear experts,
>
> I am using MG5 v2.6.5 together with SMEFTsim_A_U35_MwScheme_UFO model and I am generating Vector Boson Scattering (VBS) processes: I managed to generate ZW- and ZW+, thanks to the patch the Olivier provided me here ( https://answers.launchpad.net/mg5amcnlo/+question/694807 ), but when I try to generate ZZ VBS, I get the following error during the reweighting step:
>
> INFO: Running Reweighting
> change helicity False
> change rwgt_dir rwgt
> launch
> INFO: detected model: SMEFTsim_A_U35_MwScheme_UFO_v3_1-cHbox_massless. Loading...
> INFO: generating the square matrix element for reweighting
> INFO: generate p p > z z j j QCD=0 SMHLOOP=0 NP=1, z > l+ l- NP=1, z > j j NP=1 @0 NP=1 ;
> INFO: Done 218
> CRITICAL: tag, onedir =  ((-4, 4), (-13, -4, -2, 2, 4, 13)) rw_me [reweight_interface.py at line 1803]
> CRITICAL: data[tag][:-1] = (([4, -4], [-13, 13, 4, -4, 2, -2]), '/home/genproductions/bin/gridpacks/ZZ_cHbox_SM_LI_QU/ZZ_cHbox_SM_LI_QU_gridpack/work/process/madevent/rwgt/rw_me/SubProcesses') [reweight_interface.py at line 1804]
> CRITICAL: order, pdir, = ([4, -4], [-13, 13, 2, -2, 4, -4]) /home/genproductions/bin/gridpacks/ZZ_cHbox_SM_LI_QU/ZZ_cHbox_SM_LI_QU_gridpack/work/process/madevent/rwgt/rw_me/SubProcesses reweight_interface.py at line 1805
>
> Thanks in advance for your support.
>
> Kind Regards,
>
> Riccardo
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Riccardo (ricbrs) said : #2

Dear Olivier,

Thanks for your answer. I do not understand why [1] and [2] work, thanks to the patch [3] you provided, whilst [4] seems to be affected by this "CRITICAL" error.

So I have another question: are the events produced according to [1] and [2] together with the reweighting okay or are they wrong and I should better discard them ?

Cheers,

Riccardo

[1] generate p p > z w+ j j QCD=0 SMHLOOP=0 NP=1, z > l+ l- NP=1, w+ > j j NP=1 @0 NP=1

[2] generate p p > z w- j j QCD=0 SMHLOOP=0 NP=1, z > l+ l- NP=1, w- > j j NP=1 @0 NP=1

[3] https://answers.launchpad.net/mg5amcnlo/+question/694807

[4] generate p p > z z j j QCD=0 SMHLOOP=0 NP=1, z > l+ l- NP=1, z > j j NP=1 @0 NP=1

Hi,

As indicated in the previous thread, I do not recommend to use that syntax (overall coupling order) and re-weighting due to basically a lack of support for such syntax in years (this syntax was added as a retro-compatible syntax such that 100% of the functionality of mG4 was possible in mg5 but no one ever used it). So yes I'm worried that you are using such type of syntax (especially for re-weighting) with 2.6.5.

Now to answer your question, Indeed you also have an ambiguity for the two other processes.
The ambiguity is technically not the same since for those process, they are no ambiguity between two matrix-element but just a unique matrix-element. This explains that the code did not notice such issue.
In most of the case, the ordering in the lhef will be the one expected within MG5aMC and then this is not an issue (I bet your computation is ok respecting to that) but indeed I should think of a way to check such issue as well in the next version and force the user to check that they do not have any ordering issue.

Cheers,

Olivier

Can you help with this problem?

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

To post a message you must log in.