Hi Zach,

Looks like that the pdf reweighting was not performed anymore.
If you were running with pdfwgt = F you will see that both were in agreement (like CMS is running if I’m correct).
This clearly indicates that you are sensitive to scale variation since such changes are related to the PDF scale.
(so in itself this is not a catastrophic bug to my point of view)

I have created a patch that should put him back.
(see below) I will run some tests with some other process to check that this is not introducing some other problem.
After that  fix,  I observes that for the gluon channel, I indeed have an error of 50% due to scale uncertainty (so this seems coherent).

Cheers,

Olivier



> On Nov 9, 2017, at 02:33, Zachary Marshall <email address hidden> wrote:1
> Public bug reported:
> 
> Hi there,
> 
> I'm hoping that you can help us track this issue down, as it's holding
> up our validation of MadGraph 2.6.0.  Emma Kuwertz and I found that
> between older and newer MadGraph releases, the cross section of p p > go
> go j processes changed by 50% or more.  I set up and run out of the box:
> 
> import model mssm
> generate p p > go go
> add process p p > go go j
> output -f
> 
> in MadGraph 2.3.3 and 2.4.3.  I run the same in MadGraph 2.6.0, but with
> `import model MSSM_SLHA2`.  In both releases I then set the masses of
> all SUSY particles to be 10**9 GeV, except the gluino which is set to 1
> TeV.  All other parameters I leave as they are, out of the box, but a
> quick check suggests that there aren't wild new cuts that have appeared.
> With 2.3.3 the cross section I get is:
> 
>     Cross-section :   0.662 +- 0.00212 pb
> 
> With 2.4.3 and 2.6.0, I get the same answer:
> 
>     Cross-section :   0.7888 +- 0.002181 pb
> 
> There, the cross section files suggest that most of the difference is
> due to a large (>25%) change in g g > go go g.  I don't see any
> difference in the PDFs that might cause such a change, though.
> 
> In Emma's run inside the ATLAS framework, we were looking at more modest
> total cross section changes, but large changes to the go go j cross
> section (of order 50%) that led to significantly harder kinematics in
> one case than the other.
> 
> Is there some known feature of the releases that would have caused these
> differences?  I tried to look over the update notes, but I didn't find
> anything sinister.
> 
> 
> Thanks,
> Zach
> 
> ** Affects: mg5amcnlo
>     Importance: Undecided
>         Status: New
> 
> -- 
> You received this bug notification because you are subscribed to
> MadGraph5_aMC@NLO.
> https://bugs.launchpad.net/bugs/1731086
> 
> Title:
>  Change in production xsecs in SUSY models in 2.6.0
> 
> Status in MadGraph5_aMC@NLO:
>  New
> 
> Bug description:
>  Hi there,
> 
>  I'm hoping that you can help us track this issue down, as it's holding
>  up our validation of MadGraph 2.6.0.  Emma Kuwertz and I found that
>  between older and newer MadGraph releases, the cross section of p p >
>  go go j processes changed by 50% or more.  I set up and run out of the
>  box:
> 
>  import model mssm
>  generate p p > go go
>  add process p p > go go j
>  output -f
> 
>  in MadGraph 2.3.3 and 2.4.3.  I run the same in MadGraph 2.6.0, but
>  with `import model MSSM_SLHA2`.  In both releases I then set the
>  masses of all SUSY particles to be 10**9 GeV, except the gluino which
>  is set to 1 TeV.  All other parameters I leave as they are, out of the
>  box, but a quick check suggests that there aren't wild new cuts that
>  have appeared.  With 2.3.3 the cross section I get is:
> 
>       Cross-section :   0.662 +- 0.00212 pb
> 
>  With 2.4.3 and 2.6.0, I get the same answer:
> 
>       Cross-section :   0.7888 +- 0.002181 pb
> 
>  There, the cross section files suggest that most of the difference is
>  due to a large (>25%) change in g g > go go g.  I don't see any
>  difference in the PDFs that might cause such a change, though.
> 
>  In Emma's run inside the ATLAS framework, we were looking at more
>  modest total cross section changes, but large changes to the go go j
>  cross section (of order 50%) that led to significantly harder
>  kinematics in one case than the other.
> 
>  Is there some known feature of the releases that would have caused
>  these differences?  I tried to look over the update notes, but I
>  didn't find anything sinister.
> 
> 
>  Thanks,
>  Zach
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1731086/+subscriptions