Error running systematics module on generated events

Bug #1831262 reported by Kelci Mohrman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Fix Released
Undecided
Unassigned

Bug Description

Hi,
We are submitting this question as a bug report so that we can try to attach the LHE file as per Olivier's request. The original question is below.

------------------

Hello MG experts,

I have a question about an error that is produced when trying to make a 0+1 parton process gridpack. We are using the dim6top_LO_UFO model and our MadGraph version is 2.6.0.

In our process card, we have:

define p = p b b~
define j = p
define l+ = e+ mu+ ta+
define l- = e- mu- ta-
define vl = ve vm vt
define vl~ = ve~ vm~ vt~
generate p p > t t~ l+ vl DIM6=1 @0
add process p p > t t~ l- vl~ DIM6=1 @1
add process p p > t t~ l+ vl j DIM6=1 @2
add process p p > t t~ l- vl~ j DIM6=1 @3

When can generate events from the gridpack, but when we try to run the systematics module over these events, we get the following error:

Command "systematics GridRun_PostProc_42 --remove_wgts=all --start_id=1001 --pdf=306000,322500@0,322700@0,322900@0,323100@0,323300@0,323500@0,323700@0,323900@0,305800,13000,13065@0,13069@0,13100,13163@0,13167@0,13200@0,25200,25300,25000@0,42780,90200,91200,90400,91400,61100,61130,61200,61230,13400,82200,292200,292600@0,315000@0,315200@0,262000@0,263000@0 --mur=1,2,0.5 --muf=1,2,0.5 --together=muf,mur,dyn --dyn=-1,1,2,3,4" interrupted with error:
Exception : <rscale> -1 0.10700227E+04</rscale>
 <asrwt> 1 0.19826937E+02</asrwt>
 <pdfrwt beam="1"> 1 2 0.12435204E+00 0.12779190E+04</pdfrwt>
 <pdfrwt beam="2"> 1 -1 0.19537244E+00 0.62814801E+03</pdfrwt>
 <totfact> 0.11828276E+01</totfact>
  not parsed

We are not sure what is causing this error or how to fix it.

As one further note, when we looked at the LHE file, the only difference between this event and the preceding events appears to be the -1 in the <rscale> tag (the others are all non-negative). We are not sure whether or not this is related to the issue, but we are wondering what this integer means.

Thank you! - Kelci

Revision history for this message
Kelci Mohrman (kmohrman) wrote :
Revision history for this message
Kelci Mohrman (kmohrman) wrote :
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi,

Sorry it was busy those days. I have started to look at it and have contact the model author to try to understand some particularities of the model.
I'm also trying to reproduce it on my laptop (but it will probably need a bit of time to have the results due to the number of non-QCD diagram that you include in the computation and the fact that you do no use any model restriction to optimise the computation.

I will be back to you when I will have a feedback from the model authors.

Cheers,

Olivier

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Could you also attach your UFO model?
Looks like the one with the same name on my machine does not fully match your param_card.

Additionally, I'm puzzled about the param_card that you use. Am I correct that you are doing a pure SM computation here? (but with that model)

Cheers,

Olivier

Revision history for this message
Kelci Mohrman (kmohrman) wrote :

Hi Olivier,

I attached the model that we used.

Regarding your question about whether or not this is a pure SM computation, for this particular run, we left the Wilson coefficients at their standard model values, but we did additional tests where we set the WC to non-SM values, and got the same error.

Thank you! - Kelci

Changed in mg5amcnlo:
status: New → Confirmed
Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :

Hi,

Looks like that MG5aMC has some hypothesis on the gluon emission (that gluon emission from quark are QCD related). This creates a lot of error to face a model where this is not the case.

Relaxing such hypothesis, will actually require some huge changes to the code and we can not assume that this is going to be fixed "soon".

I will include some change in the next version of the code (2.6.6) to prevent to run with such type of model any of the feature that are problematic (and that's a lot)
so for such model you can not
1) compute scale uncertainties
2) using MLM (i.e. merging multiple multiplicities)
3) using the default CKKW like matching/merging

Thanks a lot for the bug report,

Cheers,

Olivier

Changed in mg5amcnlo:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.