Error: Failed despite same graph (STOP 4) in SMEFTsim for operator involving gluon fields

Asked by Giacomo

Dear MadGraph authors,

I am trying to generate interference and pure quadratic samples for the operator cHG defined in SMEFTsim topU3l UFO model [1] and process:

import model SMEFTsim_topU3l_MwScheme_UFO_b_massless-cHG_massless
define p = g u d d~ b b~
define j = g u d d~ b b~
generate p p > e+ ve j j j j SMHLOOP=0 QCD=2 NP=1
output emVjj_cHG_SM_LI_QU

Although we are aware of the problems related to these kind of operators involving gluon fields but without dependence on as [3], it is still not clear the source of the following error:

Added good helicity 208 89.392844928797473 in event 1 local: 1
RESET CUMULATIVE VARIABLE
RESET CUMULATIVE VARIABLE
Error: Failed despite same graph: 1296
Have jets (>0) 0 0 0 0 0 1 0 1
Should be 6 7 8
STOP 4

This happens for MG5 version 2.6.5, 2.7.3 and LS 2.9.11.

The puzzling fact is that the MG reweighting at LO works, starting from the SM and reweighting to cHG=+1, cHG=-1 [4].

We tried the following combination for initial and final state partons but we can't find a clear connection with the success or fail for the execution of MG5:

define p = g; define j = g u u~ d -> OK
define p = g u; define j = g u u~ d -> OK
define p = g u d; define j = g u u~ d -> OK
define p = g u u~; define j = g u u~ d -> OK
define p = g u u~ d; define j = g u u~ d -> OK
define p = g u d u~ d~; define j = g u u~ d -> ERROR

Could you tell us what is happening behind the curtains? Should we "thrust" the result from the LO reweighting?

Thank you,
Best

--------------------------
[1]

https://gboldrin.web.cern.ch/gboldrin/generators/SMEFTsim_topU3l_MwScheme_UFO_b_massless.tar.gz

[2]
https://answers.launchpad.net/mg5amcnlo/+question/690133
https://answers.launchpad.net/mg5amcnlo/+question/687936

[3]

Starting point:
import model SMEFTsim_topU3l_MwScheme_UFO_b_massless-SMlimit_massless
define p = g u u~ d d~ s s~ c c~ b b~
define j = p
generate p p > e- ve~ j j j j SMHLOOP=0 QCD=2

We change process and model at reweighting:

INFO: change model SMEFTsim_topU3l_MwScheme_UFO_b_massless-cHG_massless
KEEP: change process p p > e- ve~ j j j j NP=1 QCD=2 SMHLOOP=0
INFO: Event nb 0 current time: 03h12
INFO: Event nb 10 0.16s
INFO: Event nb 20 0.28s
INFO: Event nb 30 0.37s
INFO: Event nb 40 0.41s
INFO: Event nb 50 0.45s
INFO: Event nb 60 0.52s
INFO: Event nb 70 0.56s
INFO: Event nb 80 0.62s
INFO: Event nb 90 0.68s
INFO: Event nb 100 0.74s
INFO: Event nb 200 1.3s
INFO: Event nb 300 1.8s
INFO: Event nb 400 2.3s
INFO: Event nb 500 2.8s
INFO: Event nb 600 3.3s
INFO: Event nb 700 3.7s
INFO: Event nb 800 4.1s
INFO: Event nb 900 4.4s
INFO: All event done (nb_event: 1000) 4.7s
INFO: Event /srv/emVjj_ewk_qcd_dim6/emVjj_ewk_qcd_dim6_gridpack/work/process/madevent/Events/pilotrun/unweighted_events.lhe have now the additional weight
INFO: new cross-section is : 31.7643 pb (indicative error: 0.518991 pb)
INFO: Original cross-section: 32.14466 +- 0.03739602 pb (cross-section from sum of weights: 32.144645)
INFO: Computed cross-section:
INFO: cHG : 31.7642987594 +- 0.51899110219 pb

Question information

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

Did you try to avoid the CKKW scale?
Having a simpler dynamical scale like HT/2 typically solves such issue.
(dynamical_scale_choice=3)

Cheers,

Olivier

Revision history for this message
Giacomo (giacbold) said :
#2

Dear Olivier,

yes it does work with dynamical_scale_choice=3. Do you know why having the default dynamical scale yield such error?
Is the result from the reweighting with default dyn scale thrustworthy? We know from previous threads that predictions may change significantly with the dyn scale choice https://answers.launchpad.net/mg5amcnlo/+question/683400

Best,
Giacomo

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

Hi,

> Do you know why having the default dynamical scale yield such error?

Some model are too different from the Standard Model for the CKKW merging algorithm to make sense and this is likely your issue too. For the same reason your process/model will not work with MLM merging.

> Is the result from the reweighting with default dyn scale thrustworthy?

The CKKW merging scaling is not reachable via reweighting.

> We know from previous threads that predictions may change significantly with the dyn scale choice

That is just the fact that scale uncertainty are quite large at LO. So yes, different prior for the scale choice will lead to different prediction (typically within that scale uncertainty band)

Cheers,

Olivier

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

Just to give a bit more details,

the issue is that madgraph detects that the for some of the symmetric configuration that MG5aMCNLO does integrate together, the determination of the which jet does (or not) enter into the QCD merging is not the same meaning that meta data associated to merging will not be correct and can not be processed correctly later by the parton-shower.

When the algorithm is only used for the scale computation alone, this is obviously not critical but this check is crucial for MLM so I will not remove it from the code (especially since this means that the determination of the scale by this procedure is also not fully justify anyway).

Cheers,

Olivier

Revision history for this message
Giacomo (giacbold) said :
#5

Thanks Olivier Mattelaer, that solved my question.