Difference between cross section from gridpack and event generation

I've produced a gridpack for p p > e- ve~ mu+ mu- j j, with minimal cuts (essentially just mjj > 100 and mll > 60). At the gridpack generation time, I get a cross section of 0.0006804 +- 1.076e-06 pb. After generating 100 events from the gridpack, the output cross section, and the one written to the LHE file is 0.64498281176E-03 =- 0.11946674812E-04. For other combinations of events/seed, I get different results. For example, with 5000 events, I see 6.700e-04 +/- 2.732e-06. In general the results are not in statistical agreement.

I think this issue is well-known and seems to be related to processes with difficult phase space. My real question is, why not just use the gridpack cross section every time? I thought for NLO this was the case.

1) if you ask reasonable size events (around 10k) then using those cross-section can be usefull since by averaging them you should get a more accurate cross-section than the one reported by the gridpack. (For small sample, I will no garantee the above property without deeply checking inside the code how that cross-section is computed.

2) It is easy to force a-posteriori to the cross-section to the gridpack. While the opposite is simply not possible. So you are actually loosing usefull information.

Cheers,

Olivier

PS: For small sample generated, it is likely that many channels are discarded (which is by design) and I do not know if those channel are included or not in the total cross-section. If they are not, then indeed this can increase the fluctuation of the reported cross-section out of the gridpack (even if the average should still be ok actually)

> On 21 Feb 2018, at 11:57, Kenneth Long <email address hidden> wrote:
>
> Question #664751 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/664751
>
> Kenneth Long gave more information on the question:
> Sorry, I should add that I'm using V 2.6.0
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Can you help with this problem?

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