Comment 3 for bug 1914822

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
>> 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
>