celeritas icon indicating copy to clipboard operation
celeritas copied to clipboard

Celeritas offloading interfaces do not support multiple runs in Geant4

Open drbenmorgan opened this issue 1 year ago • 6 comments

I only spotted this in testing Celeritas in the celer-adept integration exercise. Offloading Geant4 tracks to Celeritas using any of the offload interfaces (Simple/FastSimulation/TrackingManager) results in a fatal exception from celeritas on the second invocation of G4RunManager::BeamOn:

G4WT6 > SimpleOffload.cc:149: [7/36] status: Finalizing Celeritas
SimpleOffload.cc:149: status: Finalizing Celeritas
info: Creating 0 device streams
SharedParams.cc:214: status: Initializing Celeritas shared data

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : celer0001
      issued by : /.../src/corecel/sys/Device.cc:303
celeritas::activate_device may be called only once per application
*** Fatal Exception *** core dump ***
 **** Track information is not available at this moment
 **** Step information is not available at this moment

-------- EEEE -------- G4Exception-END --------- EEEE -------


*** G4Exception: Aborting execution ***

If the device activation is only once per program execution, then can we make it safe to call more than once, e.g. first call wins?

drbenmorgan avatar Jun 13 '24 13:06 drbenmorgan

Ah, I guess I didn't know that multiple "beam on" could be run per execution 😅 The intended behavior for SharedParams is to be set up once and torn down once. We don't want to recreate the VecGeom geometry every time we run a beam, for example. If begin/end of run is potentially called multiple times per execution, what's the right way to "initialize on startup" and "finalize on teardown"?

sethrj avatar Jun 13 '24 13:06 sethrj

It depends... Between runs, Geant4 is in its "idle" state and so the geometry can completely change, the physics can change in certain aspects like parameters and (de)activation of some models (but it's much more limited). I'll have a look through the examples for the relevant cases and what/how gets triggered to rebuild.

However, would a useful first step be to simply allow multiple runs under the assumption that there are no changes in geometry/physics? The canonical use case is simply changing the particle gun configuration between runs and nothing else.

drbenmorgan avatar Jun 13 '24 13:06 drbenmorgan

Huh, I didn't know the physics or geometry could change after the program started... it certainly seems like you can't change anything after closing the run manager which is where my misconception comes from.

sethrj avatar Jun 13 '24 14:06 sethrj

@sethrj, given the update in drbenmorgan/celer-adept#6, should we close this? Or leave open to note as a possible feature for the future if a hard requirement comes along?

drbenmorgan avatar Jul 17 '24 12:07 drbenmorgan

I could go either way, but I think you're right that this will be almost impossible to support (and not much better than restarting the whole simulation) since we won't be able to tell what GPU data needs to be regenerated and what can stay the same. We'd basically have to reload Celeritas every time to be safe.

sethrj avatar Jul 19 '24 13:07 sethrj

Needed by B5 (https://github.com/celeritas-project/gpu-delta-review-2025/issues/2) ; but vecgeom doesn't support multiple geometry loads. Maybe worth trying with orange geometry...

sethrj avatar Mar 16 '25 19:03 sethrj

Fixed by #1938

sethrj avatar Sep 26 '25 17:09 sethrj