seed issue for decay-chain

Bug #1914822 reported by Olivier Mattelaer
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MadGraph5_aMC@NLO
Won't Fix
Low
Unassigned

Bug Description

Using vanilla MG v2.8.2, I ran the following two scripts:

generate p p > t t~ QED=0 QCD=2
output test_nodecay
launch test_nodecay
    set nevents 1000
    set iseed 12345
launch test_nodecay
    set nevents 1000
    set iseed 12345
launch test_nodecay
    set nevents 1000
    set iseed 12345
launch test_nodecay -i
    print_results --path=./xsec_nodecay.txt --format=short

generate p p > t t~ QED=0 QCD=2, t > w+ b, t~ > w- b~
output test_decay
launch test_decay
    set nevents 1000
    set iseed 12345
launch test_decay
    set nevents 1000
    set iseed 12345
launch test_decay
    set nevents 1000
    set iseed 12345
launch test_decay -i
    print_results --path=./xsec_decay.txt --format=short

The first script, which doesn't decay the tops, produces the following cross sections:
run_01 tag_1 503.307 1.75095850431 1000
run_02 tag_1 503.307 1.75095850431 1000
run_03 tag_1 503.307 1.75095850431 1000

as expected, given the random seed is the same in each run.

On the other hand, adding the decay chain as in the second script:
run_01 tag_1 484.54 1.6126228715 1000
run_02 tag_1 482.07 1.51073567367 1000
run_03 tag_1 482.07 1.51073567367 1000

So it seems that something is at play here, with the decay syntax, that somehow ignores the choice of iseed in the first run?

Changed in mg5amcnlo:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
James Howarth (jhowarth) wrote :

A further issue that may or not be related to this bug (if not, I will open a new report), when doing the second and subsequent runs, the run card has different formatting than the first run (the beam polarisation options appear but they are not present in the runcard in the first run).

I'm guessing that this is to do with how the cards are generated and there is something different between the generation that happens when an output directory is first created, and when a new run is started after the first one.

Cheers,

Jay

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote : Re: [Bug 1914822] seed issue for decay-chain

Ah I never noted that.
This is a templating issue when the seed is reset the 0 in the run_card such that the second run can automatically use a new seed and not the same one.
This explains why I see people with those weirdly formatted cards.

for the next run it looks like the
template of the run_card does not trigger some of the magic to hide a bunch of the irrelevant parameter.
This explains why experimentalist provide so often such weird card.
I do not think that this is related to the seed but we will see fast enough.

Cheers,

Olivier

> On 4 Mar 2021, at 12:58, James Howarth <email address hidden> wrote:
>
> A further issue that may or not be related to this bug (if not, I will
> open a new report), when doing the second and subsequent runs, the run
> card has different formatting than the first run (the beam polarisation
> options appear but they are not present in the runcard in the first
> run).
>
> I'm guessing that this is to do with how the cards are generated and
> there is something different between the generation that happens when an
> output directory is first created, and when a new run is started after
> the first one.
>
> Cheers,
>
> Jay
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1914822
>
> Title:
> seed issue for decay-chain
>
> Status in MadGraph5_aMC@NLO:
> Confirmed
>
> Bug description:
> Using vanilla MG v2.8.2, I ran the following two scripts:
>
> generate p p > t t~ QED=0 QCD=2
> output test_nodecay
> launch test_nodecay
> set nevents 1000
> set iseed 12345
> launch test_nodecay
> set nevents 1000
> set iseed 12345
> launch test_nodecay
> set nevents 1000
> set iseed 12345
> launch test_nodecay -i
> print_results --path=./xsec_nodecay.txt --format=short
>
> generate p p > t t~ QED=0 QCD=2, t > w+ b, t~ > w- b~
> output test_decay
> launch test_decay
> set nevents 1000
> set iseed 12345
> launch test_decay
> set nevents 1000
> set iseed 12345
> launch test_decay
> set nevents 1000
> set iseed 12345
> launch test_decay -i
> print_results --path=./xsec_decay.txt --format=short
>
> The first script, which doesn't decay the tops, produces the following cross sections:
> run_01 tag_1 503.307 1.75095850431 1000
> run_02 tag_1 503.307 1.75095850431 1000
> run_03 tag_1 503.307 1.75095850431 1000
>
> as expected, given the random seed is the same in each run.
>
> On the other hand, adding the decay chain as in the second script:
> run_01 tag_1 484.54 1.6126228715 1000
> run_02 tag_1 482.07 1.51073567367 1000
> run_03 tag_1 482.07 1.51073567367 1000
>
> So it seems that something is at play here, with the decay syntax,
> that somehow ignores the choice of iseed in the first run?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mg5amcnlo/+bug/1914822/+subscriptions

Revision history for this message
Olivier Mattelaer (olivier-mattelaer) wrote :
Download full text (3.7 KiB)

Hi,

I have fixed the formatting issue of the run_card:
https://bazaar.launchpad.net/~maddevelopers/mg5amcnlo/2.9.3/revision/306 <https://bazaar.launchpad.net/~maddevelopers/mg5amcnlo/2.9.3/revision/306>

This does not seem to fix the seed issue, that I was not yet able to find the origin.
Interestingly tough your process has 3 channel of integration and only one of the three does not provide the same result.
The two others behave as it should. This might be correlated to the fact that we keep less log for that channel compare to the first one (to reduce disk usage actually). But did not had time to investigate further away.

Cheers,

Olivier

> On 4 Mar 2021, at 13:29, Olivier Mattelaer <email address hidden> wrote:
>
> Ah I never noted that.
> This is a templating issue when the seed is reset the 0 in the run_card such that the second run can automatically use a new seed and not the same one.
> This explains why I see people with those weirdly formatted cards.
>
> for the next run it looks like the
> template of the run_card does not trigger some of the magic to hide a bunch of the irrelevant parameter.
> This explains why experimentalist provide so often such weird card.
> I do not think that this is related to the seed but we will see fast enough.
>
> Cheers,
>
> Olivier
>
>> On 4 Mar 2021, at 12:58, James Howarth <email address hidden> wrote:
>>
>> A further issue that may or not be related to this bug (if not, I will
>> open a new report), when doing the second and subsequent runs, the run
>> card has different formatting than the first run (the beam polarisation
>> options appear but they are not present in the runcard in the first
>> run).
>>
>> I'm guessing that this is to do with how the cards are generated and
>> there is something different between the generation that happens when an
>> output directory is first created, and when a new run is started after
>> the first one.
>>
>> Cheers,
>>
>> Jay
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1914822
>>
>> Title:
>> seed issue for decay-chain
>>
>> Status in MadGraph5_aMC@NLO:
>> Confirmed
>>
>> Bug description:
>> Using vanilla MG v2.8.2, I ran the following two scripts:
>>
>> generate p p > t t~ QED=0 QCD=2
>> output test_nodecay
>> launch test_nodecay
>> set nevents 1000
>> set iseed 12345
>> launch test_nodecay
>> set nevents 1000
>> set iseed 12345
>> launch test_nodecay
>> set nevents 1000
>> set iseed 12345
>> launch test_nodecay -i
>> print_results --path=./xsec_nodecay.txt --format=short
>>
>> generate p p > t t~ QED=0 QCD=2, t > w+ b, t~ > w- b~
>> output test_decay
>> launch test_decay
>> set nevents 1000
>> set iseed 12345
>> launch test_decay
>> set nevents 1000
>> set iseed 12345
>> launch test_decay
>> set nevents 1000
>> set iseed 12345
>> launch test_decay -i
>> print_results --path=./xsec_decay.txt --format=short
>>
>> The first script, which doesn't decay the tops, produces the following cross sections:
>> run_01 tag_1 503.307 1.75095850431 1000
>> run_02 tag_1 503.307 1.75095850431 1000
>> ...

Read more...

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

We change the behavior of the see in 2.9.7 and 3.3.1
To avoid bias within the multiple code (re)setting the seed in all direction
(madevent, madspin, auto-width, ...)
Only one set of the seed is allowed per python run.

So now in both case, the three run will return different cross-section since only the first seed will be taken into account.

Cheers,

Olivier

Changed in mg5amcnlo:
status: Confirmed → Won't Fix
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.