Celeritas is a new Monte Carlo transport code designed to accelerate scientific discovery in high energy physics by improving detector simulation throughput and energy efficiency using GPUs.
In preparation for a multi-stream "end run gather" (https://github.com/celeritas-project/celeritas/issues/1296) that will apply to timers, calorimeters, etc., this refactors the local transporter and hit processor so that the hit processor is owned by the local thread and referenced by the hit manager, as opposed to being owned by hit manager. This means that when the local transport is allocated/deallocated (which happens at Begin/EndOfRun on the worker thread) the hit processor will also be allocated/deallocated, necessary to make Geant4 thread-local allocators play nicely. To make this safer, we keep a weak pointer on the hit manager that does a debug check for hit processor being alive.
As part of the refactoring I devised a slightly cleaner way of setting up the output registry to keep the detector output, eliminating a couple of "hack: remove in v0.5 " bits of code.
While looking through the debug output I also noticed that the "looping track" warning was not very clear, so I refactored it and now have the tracking cut action print at a debug level even if the track is not in an "error" state:
[1/2] ../src/celeritas/global/alongstep/detail/PropagationApplier.hh:164: error: Track (pid=1, E=1.17434 MeV) is looping after 100 steps
[1/2] ../src/celeritas/phys/detail/TrackingCutExecutor.hh:72: debug: Killing track (ID 1926 of event 5, track slot 935) at {-17.844418516047, -25.727498848885, -1072.3128574325} [cm] along {-0.096423674800004, 0.44785031455201, -0.88889401544488}: depositing 1.15475 [MeV] in volume 7
In preparation for a multi-stream "end run gather" (https://github.com/celeritas-project/celeritas/issues/1296) that will apply to timers, calorimeters, etc., this refactors the local transporter and hit processor so that the hit processor is owned by the local thread and referenced by the hit manager, as opposed to being owned by hit manager. This means that when the local transport is allocated/deallocated (which happens at Begin/EndOfRun on the worker thread) the hit processor will also be allocated/deallocated, necessary to make Geant4 thread-local allocators play nicely. To make this safer, we keep a weak pointer on the hit manager that does a debug check for hit processor being alive.
As part of the refactoring I devised a slightly cleaner way of setting up the output registry to keep the detector output, eliminating a couple of "hack: remove in v0.5 " bits of code.
While looking through the debug output I also noticed that the "looping track" warning was not very clear, so I refactored it and now have the tracking cut action print at a debug level even if the track is not in an "error" state: