G4HadronicProcessStore::Clean() gone -- what to do instead?

Physics Lists
1

We are working on migrating our simulation framework to Geant4 11.3.2 (11.4.0 after December). I’ve run into one problem that I’m not sure how to solve. We have a Messenger class to configure a customized physics list, which includes adding or removing various pieces of hadronic physics. After /run/initialize, the processes defined by those physics builders are added to G4HadronicProcessStore.

In order to support reconfiguring the physics list between runs of a single job, our Messenger class has an “updatePhysics” command which tries to reset everything to the “PreInit” state:

  • Removes all processes from the particles (via G4ProcessVector::clear() in the usual pdIter loop)
  • Removes all the hadronic processes from the store, via G4HadronicProcessStore::Clean()
  • Calls physicsList->Construct() to redo all the process building and registration
  • Calls RM->PhysicsHasBeenModified() to trigger all the table building at the next /run/initialize or beamOn

@civanch removed the G4HadronicProcessStore::Clean() function in October 2023, to solve a “constant crashes” problem (I think!). Should I just remove the call to Clean(), and assume everything will magically get deleted? Is it no longer possible to change the physics list at this low level between runs within a job? Is there an example which shows how a user application is supposed to do this properly?

Geant4 Version: Moving to 11.3.2
Operating System: Ubuntu 24
Compiler/Version: GCC 13.3.0

1 Like
2

I can’t find anywhere in the Geant4 source code for either 11.2.1 or 10.07.p04 (including the examples/ directory tree) that G4HadronicProcessStore::Clean() was ever called (I do see lots of calls to ...->PrintInfo() and other things). So removing it makes sense, if it was “never used,” not even by RunManager.

This suggests that it ought to be perfectly safe to remove the call from our simulation code. But I’m still concerned about memory leaks and dangling pointers, especially for jobs which involve multiple runs with different configurations.

1 Like