from the HddmOutput object which contains a value that was loaded
with the current run number in hdgeant.cc, in contrast to the
G4 run number that normally starts off with zero and increments
each time a new simulation run is started. The G4 event number
is a serial number that G4 assigns to each event in the order
they are picked up by one of the worker threads. It is used by
the internal random seeds bookkeeping so we do not want to change
it to match the event number from the input hddm file and screw
up that bookkeeping. Similarly, we don't want to mess with what
G4 calls the "RunID" which is a unique sequence number assigned
at each invocation of /run/beamOn, and does not correspond to the
GlueX run number that is written in the output file. If we keep
our own run/event numbers separate and distinct from the G4 run/
event numbers then this confusion should not come back to bite us
again in the future.
from the HddmOutput object which contains a value that was loaded with the current run number in hdgeant.cc, in contrast to the G4 run number that normally starts off with zero and increments each time a new simulation run is started. The G4 event number is a serial number that G4 assigns to each event in the order they are picked up by one of the worker threads. It is used by the internal random seeds bookkeeping so we do not want to change it to match the event number from the input hddm file and screw up that bookkeeping. Similarly, we don't want to mess with what G4 calls the "RunID" which is a unique sequence number assigned at each invocation of /run/beamOn, and does not correspond to the GlueX run number that is written in the output file. If we keep our own run/event numbers separate and distinct from the G4 run/ event numbers then this confusion should not come back to bite us again in the future.