Closed sethrj closed 1 month ago
A follow-on pull request should map our internal "event ID"
We may want to rename our internal "event ID" to avoid confusion with the external ones.
3 279 files 5 076 suites 3m 30s :stopwatch: 1 528 tests 1 501 :white_check_mark: 27 :zzz: 0 :x: 16 929 runs 16 866 :white_check_mark: 63 :zzz: 0 :x:
Results for commit 4342e428.
ATLAS integration is currently failing because the framework is now setting the Geant4 event ID based on the global event context, whose event number is a globally unique identifier. In contrast, Celeritas expected the event number to be a counter (and a thread-local one at that). Since there are far more than 4 billion total events simulated across all runs and all simulations, and each event should have a unique random sequence, we need to define a special long integer for seeding.
Since the unique event ID (aka the event ID from geant4) doesn't necessarily correlate to the event counter, I'm forcing the EventId that we use for the primary (used for track counting) to zero. This may hurt "debuggability" but means that we can eliminate the "max events" from Geant4 integration. A follow-on PR will add support a special mode for resetting the track counter at the beginning of each event (and having a single "global" event ID) rather than using a unique event-ID-based slot.
A follow-on pull request should map our internal "event ID" (which is consecutive from zero and local to a thread) to the external "event ID" (which is some arbitrary integer used to reference an event, whether from ATLAS or a HepMC3 file etc) for user output.
See #1144 , #1233