Setting iseed yields same cross section but different events

Hi Daniel,

Yes this is correct.

More exactly the weighted events are actually the same (for a given seed) and this is why the cross-section is exactly the same.
The difference originates from the unweighting procedure (performed in python) and which used the python random algorithm.
That algorithm is very robust.
So with the same seed, you have a subset of the events which will be identical (but not all of them) since they are coming from the same weighted events.

On the other-hand, you still have the important property that having two seed ensure to have two fully independent sample (which is the crucial point for me).

The solution in your case, would be to fix the python seed at the time where you launch python:
https://docs.python.org/2/library/random.html#random.seed

Cheers,

Olivier

> On Nov 2, 2016, at 13:57, Daniel <email address hidden> wrote:
>
> New question #403733 on MadGraph5_aMC@NLO:
> https://answers.launchpad.net/mg5amcnlo/+question/403733
>
> Hi,
>
> I am using MadGraph5_aMC@NLO version 2.4.3 and have the following issue: If I have two identical output directories and I set '5 = iseed' in both respective run_cards and generate events, I do get the same cross sections in both cases but not the same parton event files.
>
> Note that I am _not_ talking about run01-events and run02-events, for which - I guess - this behaviour expected. I am talking about performing the same "generate xy; launch" command chain with the same Cards with a constant iseed and not getting the same .lhe file.
>
> As an example, I just entered in the mg5_aMC@NLO executable
>
> import model mssm
> generate p p > t1 t1~
> output myfolder_1
> generate p p > t1 t1~
> output myfolder_2
>
> changed "iseed" to 5 in both myfolder_1/Cards/run_card.dat and myfolder_2/Cards/run_card.dat" and did
> launch myfolder_1
> and
> launch myfolder_2
> in two separate mg5_aMC@NLO calls.
>
> In both cases, my .lhe files yield
> <MGGenerationInfo>
> # Number of Events : 10000
> # Integrated weight (pb) : 1.25687
> </MGGenerationInfo>
>
> however, the first event of _1 reads
> <event>
> 4 1 +1.2568700e-04 7.35083500e+02 7.81653100e-03 9.65904700e-02
> 2 -1 0 0 502 0 +0.0000000000e+00 +0.0000000000e+00 +8.1321269988e+02 8.1321269988e+02 0.0000000000e+00 0.0000e+00 1.0000e+00
> -2 -1 0 0 0 501 -0.0000000000e+00 -0.0000000000e+00 -7.0716068191e+02 7.0716068191e+02 0.0000000000e+00 0.0000e+00 -1.0000e+00
> 1000006 1 1 2 502 0 -5.9012349439e+02 +1.7990870062e+02 -1.3377345332e+02 7.4715669434e+02 3.9966850000e+02 0.0000e+00 0.0000e+00
> -1000006 1 1 2 0 501 +5.9012349439e+02 -1.7990870062e+02 +2.3982547128e+02 7.7321668745e+02 3.9966850000e+02 0.0000e+00 0.0000e+00
> <mgrwt>
> <rscale> 2 0.73508353E+03</rscale>
> <asrwt>0</asrwt>
> <pdfrwt beam="1"> 1 2 0.12510965E+00 0.73508353E+03</pdfrwt>
> <pdfrwt beam="2"> 1 -2 0.10879395E+00 0.73508353E+03</pdfrwt>
> <totfact> 0.23103930E+01</totfact>
> </mgrwt>
> </event>
>
>
> while the first event of _2 reads
>
> <event>
> 4 1 +1.2568700e-04 6.24461900e+02 7.81653100e-03 9.85591600e-02
> 21 -1 0 0 501 502 +0.0000000000e+00 +0.0000000000e+00 +1.5460202741e+02 1.5460202741e+02 0.0000000000e+00 0.0000e+00 -1.0000e+00
> 21 -1 0 0 502 503 -0.0000000000e+00 -0.0000000000e+00 -2.5378515457e+03 2.5378515457e+03 0.0000000000e+00 0.0000e+00 -1.0000e+00
> 1000006 1 1 2 501 0 +4.7434292918e+02 -7.2225588078e+01 -1.0862406926e+03 1.2529451313e+03 3.9966850000e+02 0.0000e+00 0.0000e+00
> -1000006 1 1 2 0 503 -4.7434292918e+02 +7.2225588078e+01 -1.2970088257e+03 1.4395084418e+03 3.9966850000e+02 0.0000e+00 0.0000e+00
> <mgrwt>
> <rscale> 2 0.62446190E+03</rscale>
> <asrwt>0</asrwt>
> <pdfrwt beam="1"> 1 21 0.23784927E-01 0.62446190E+03</pdfrwt>
> <pdfrwt beam="2"> 1 21 0.39043870E+00 0.62446190E+03</pdfrwt>
> <totfact> 0.11400585E+02</totfact>
> </mgrwt>
> </event>
>
>
> If this is true (and I didn't do a mistake), this behaviour is quite unfortunate, because we'd like to do the MG5_aMC@NLO event generation within CheckMATE and we are very keen in beeing able to reproduce results by fixing random seeds. (Otherwise fixing these seeds wouldn't make sense anyway).
>
>
> Cheers,
> Daniel
>
>
> --
> You received this question notification because you are an answer
> contact for MadGraph5_aMC@NLO.