The STAR experiment

The values of pseudo-random number generator were initialized via ranlux assuming a 32-bit unsigned integer is used. Instead, the software parses it into a signed number which wraps around to negative values. The subsequent logic in the software checks if the seed is negative and resets it to a fixed number. A fix for this issue was submitted as PR #215.

The effect of this bug on this production was limited by the following two factors:

• For a long time in the production the opportunity for overflow was limited until 7ba28f9d3f232c780738304611348b0975640125 was applied. Thus not all of the production is affected.
• The pythia and geant are sharing the PRNG state. So even when initialized with a fixed seed, the enthropy was likely picked up from propagating particles originating at the vertex position that is sampled from pseudo-random sequences that were independent between runs.

Due to a programming error, the RUN parameter to the pythia6.kumac macro was stuck at 13072020. This value gots propagated to the StEvtHddr structures, so analyzer has to rely on other means to detect the real run number (e.g. by looking at the filename).

The value of the run number does not affect the simulation in any way: starsim produces nearly-identical zebra files for different run numbers.

Some events have a negative event number that starts with -499. The event number is being propagated from the geant event number. That event number counter is initialized by the rung statement in the kumac file to be set to ([CYCLE]-1)*500. The script sets the value of CYCLE to the value of the "repeat", which starts counting at 0, thus we get negative values. This issue is harmless.