<div dir="ltr">Hello all,<div><br></div><div>I have just checked into the trunk a cluster of updates that implements the new random number seed policy that was agreed upon at the data challenge meeting on 3/14.</div><div><br>
</div><div>All processes that employ random numbers in analyzing or updating an event should initialize the random generator to the seeds listed in the event record at the beginning of each event.  If the event record contains no seeds upon input, or if those seeds are all 0, any program that needs random number seeds should generate its own set at the start of each event, and save them in the output event record to be reused by all subsequent analysis stages that require randoms.</div>
<div><br></div><div>That was my understanding of the policy we agreed to, and that is what I implemented in the changes I just checked in.  In anticipation of the extended seeds needed for Geant4, I extended the list to 4 32-bit seeds, and programs that need fewer bits to initialize their internal generators should consume as many as they need, starting at seed1.  This required an update to the data model, which means that any analysis programs built after this change is implemented will not be able to read simulation files that were generated prior to this change.  This restriction does NOT apply to rest files, only intermediate simulation files like hdgeant.hddm or hdgeant_smeared.hddm files that were generated with the earlier <random> tags.  This restriction also does NOT apply to reading the output of bggen files that were generated earlier, only the output from hdgeant and mcsmear, which are the only ones directly affected by the new policy.</div>
<div><br></div><div>-Richard Jones</div></div>