I’d need to understand if it is possible by any means to re-configure the simulation at the start of each event. By “re-configure” I mean:
enable/disable physics processes
enable/disable user actions
Point 2 is easily achievable with e.g. a custom version of G4MultiEventAction implementing an enabled flag and forwarding the calls only to enabled actions, so I think I can work it out if nothing similar is available. But for point 1 I’m really clueless and I’d need some developer to clarify if it’s feasible and eventually how can it be achieved.
Thanks in advance for any help.
Your (1) is likely to be kind of ugly. The basic idea is simple: put the code for this into your EventAction::BeginOfEventAction (put it in a function that you call from there). You’ll probably want a Messenger you can use to specify which processes you want to enable/disable. You can use G4ProcessManager::SetProcessActivation() to enable/disable each process, finding the process pointer via GetProcess().
The problem is that physics processes are registered for each individual particle. In some builders, there’s just one process instance, and it gets registered many times. But in other builders, the process’ new is inside the loop over particles, so you get a bunch of different instances! You’ll either have know which particles you want this to apply to, or you’re going to have to loop over the whole particle table.
Thanks @mkelsey. I independently stumbled upon G4ProcessManager::SetProcessActivation so I’m glad you confirm I am on the right path, and I was not aware of the per-particle detail so your tip will be very useful for me.
My use case at the moment consists of building a general purpose physics list, then at each event disable all the processes and re-enable only the few needed for that particular event. So I guess I can (easily?) identify for each event which processes have to be re-enabled.
Check out some of the examples where they create a physics list from scratch, instead of using a proper G4 reference list. You’ll see where they do a loop over particles and register processes with each one.
This doesn’t sound like the way Geant4 is “intended to work.” Generally speaking, individual event behaviour is not as useful as statistical distributions from many events in a run. I would expect that you’d either have different physics lists that you’d instantiate for each “kind of physics,” and then you’d run separate jobs with many events for each configuration.
The method you describe seems to me very difficult for doing analysis of the results. But I’d have to understand your use case better to make any concrete suggestions.
I need to write a simulation where, for performance reason, the single event must be simulated in two steps: first, a primary particle must be propagated in a transparent medium, recording its energy releases and eventually propagating secondaries. Then, the energy releases have to be used to generate Cherenkov photons, to be propagated as well. I need yo be able to replace Geant with other tools in one of these stages, to perform systematics studies. For usability reasons I’d prefer to be able to perform the two steps for a single event and the proceed with the next event, rather than simulating the first step for all the events and then start from there for the second step (this will also allow to remove the necessity of an intermediate output file). There are also other considerations that makes this scenario desirable for me, but these are not strictly related to G4 so I won’t bother you with these.
I see your problem. What you’re trying to do, in the general case, might require modifications to the Geant4 event loop, which is not a road you want to go down :-/
I was thinking about running each single step as a single event by manually invoking G4RunManager::ProcessOneEvent, instead of calling BeamOn. Moreover, I see that in version 11 several relevant methods of the G4RunManager interface have been made virtual, so I can probably override G4RunManager::DoEventLoop and G4RunManager::ProcessOneEvent if I need to do so (in the past they were not virtual, plus I needed to override the behavior of a private method of G4RunManager, so I had my hard time and I agree it’s better to not have to put my hands too deep).
Our experiment is still using 10.7.4 (yes, really), and I had a hard enough time just overriding ConfirmBeamOnCondition(). If they’ve made custom run managers and custom event loops easier, that’s great!