mg5amc undershooting requested number of events in *some* software env (ssWW polarized LL)

Dear Cyril,

The fact that you do not get the requested number of events, is not a surprise and was actually expected when we started this polarization project.

The fact that it depends of the machine is surprising.
But this can be expected by different reason. the most probably one is that your seed is set to 0 in your run_card so you might not have used the same seed on both machines and the efficiency can fluctuate a lot from one seed to the next,.

Now they are quite interesting news coming on the efficiency of the phase-space integrator.
In version 2.8.0 (already released) the efficiency/speed of those processes should have been improved, allowing to get more reliably the requested number of events. However this version does not fully fix the issue and it is actually still common to not get the number of events requested.

The next version 2.9.0 (still in active development) improves A LOT the situation.
So far the only case where I failed to reach the requested number of events is when I ask to go to 100 TeV collider.

Cheers,

Olivier

> On 7 Oct 2020, at 12:25, Cyril Becot <email address hidden> wrote:
>
> New question #693332 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/693332
>
> Hey mg5amc team,
>
> We are trying to generate polarized sample for the same-sign W VBS process, and we are having an issue with the LL sample that isn't consistent across servers or software setups. The problem was seen on mg5amc v2.7.3, the run_card is the same than the one in https://bugs.launchpad.net/mg5amcnlo/+bug/1898854 and the full proc_card is pasted at the end of this message.
>
> In some software setups (including the one used by our experiment), the number of events we get in the LHE file undershoots the requested number of events, potentially by a lot. However, when I run this process on my own personal computer, I do not get anything wrong. We were wondering if this could somehow be linked to python/gcc/perl incompatibilities with this newer functionality ?
>
> This is the detailed setups that have been tested, both using stand-alone mg5amc v2.7.3. The tests were done by two different persons, but we made sure the proc and run card were the same.
>
> --- Personal computer, where everything work :
> Python 2.7.17
> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> perl 5, version 26, subversion 1
>
> --- Lab server, where it undershoots the # of events :
> Python 2.7.15
> gcc (GCC) 7.3.0
> perl 5, version 28, subversion 0
>
> And I'm not sure whether there is any other software version that would be relevant to see discussion - just let us know and we will add more.
> Has this behaviour already be seen / is it expected in some setups ?
>
> Thanks,
> Kind regards
>
> Cyril
>
>
> set low_mem_multicore_nlo_generation False
> set default_unset_couplings 99
> set group_subprocesses Auto
> set ignore_six_quark_processes False
> set loop_optimized_output True
> set loop_color_flows False
> set gauge unitary
> set complex_mass_scheme False
> set max_npoint_for_channel 0
> import model sm-no_b_mass
> define p = g u c d s u~ c~ d~ s~
> define j = g u c d s u~ c~ d~ s~
> define l+ = e+ mu+
> define l- = e- mu-
> define p = 21 2 4 1 3 -2 -4 -1 -3 5 -5
> define j = p
> define l+ = e+ mu+ ta+
> define vl = ve vm vt
> define l- = e- mu- ta-
> define vl~ = ve~ vm~ vt~
> define p = g u c d s u~ c~ d~ s~ b b~
> define j = g u c d s u~ c~ d~ s~ b b~
> generate p p > w+{0} w+{0} j j QED=4 QCD=0, w+ > l+ vl @1
> add process p p > w-{0} w-{0} j j QED=4 QCD=0, w- > l- vl~ @1
> output -f -nojpeg
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Hi Olivier,

Thanks for the super-fast answer - then I only have one follow-up question : is this problem "purely technical" or should it raise worries from us on the quality of the modelling we get at the end ? It sounds like it may effectively carve out parts of the phase space no ?

Thanks again,
Cheers
Cyril

Hi,

> is this problem "purely technical" or should it raise worries
> from us on the quality of the modelling we get at the end ?

Not reaching the requested number of events is certainly a huge warning that something does not behave as it should. So yes each time it happens, you need to be more careful than usual.

> It sounds
> like it may effectively carve out parts of the phase space no ?

I do not think that the cross-section is missing a contribution in this particular case.

One trick to improve the chance of reaching the number of events in non gridpack mode is typically to set in the run_card
1 = hard_survey
(since 2.8.0 before 2.8.0 you can set True = hard_survey)
But I do not know if this impact the gridpack mode.

Cheers,

Olivier

> On 7 Oct 2020, at 13:20, Cyril Becot <email address hidden> wrote:
>
> Question #693332 on MadGraph5_aMC@NLO changed:
> https://answers.launchpad.net/mg5amcnlo/+question/693332
>
> Cyril Becot posted a new comment:
> Hi Olivier,
>
> Thanks for the super-fast answer - then I only have one follow-up
> question : is this problem "purely technical" or should it raise worries
> from us on the quality of the modelling we get at the end ? It sounds
> like it may effectively carve out parts of the phase space no ?
>
> Thanks again,
> Cheers
> Cyril
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.

Great, thanks a lot !