Can physics lists be modified after registration?

Physics Lists
1

The situation I describe below is not addressed in the Geant4 documentation. I’m hoping that a G4 developer can respond here, and possibly expand the documentation to cover this situation.

Our simulation framework includes a set of macro commands to allow users to adjust the physics configuration. We do this by making use of the proper modular physics lists, starting with one of the official reference lists (FTFP_BERT, Shielding, etc.) and adding or modifying physics constructors by way of RegisterPhysics() or ReplacePhysics() calls.

Because of Geant4’s configuration requirements, we have to register a physics list at the very beginning of main(), before we get to instantiate the UI. So we register the basic list first, and the user can then use macro commands to adjust its content.

I’ve run into a problem with this, where if the user adds new physics, which provides new particles (via the proper ConstructParticle() action), we get a cascade of errors at /run/initialize complaining that particles are being instantiated outside the PreInit state. This despite the fact that we open the UI in PreInit, and G4 is in the PreInit state when /run/initialize is called.

As near as I can tell, it seems that the PL’s ConstructParticle() function gets called at the time it is passed to the RunManager. Any additional physics constructors passed in later do not get their ConstructParticle() functions called. This results is a series of error messages when those “late” constructors try to do their thing, and the job crashes.

Should we be calling ConstructParticle() ourselves, when a new block of physics is requested via UI command? Should we re-call the whole PL’s ConstructParticle() function to trigger this?

2

My expectation would be that modification could be made before the PhysicsList’s methods are called by the RunManager, in particular ConstructParticle() and ConstructPhysics(), but not after this.

Could you clarify, though, whether the problems occur in a sequential run or a multi-threaded run ? In the MT case the initialisation is significantly more complex.

3

Your expectation was mine as well. We are using MT exclusively now (with the default number of worker threads set to 1).

ConstructParticle() gets called immediately when the PL is registered, so I’ve put in explicit calls to each “optional” physics constructor’ own ConstructParticle(), when it is instantiated and added to the PL. It’s a bit ugly, but at least it’s consistent.

4

Hi Mike,

please, have a look into $G4INSTALL/examples/extended/exotic_physics/monopol

There is the valid receipt how to add an extra particle. Similar approaches are used by ATLAS and CMS. The main problem you face: ConstructParticle() is called very early.

VI

5

Thanks, Vladimir! It’s the early call to ConstructParticle() that was getting me. We give our users the ability to “create” (really, to modify) our basic physics list with macro commands. But the UI doesn’t exist until after the physics list has been registered.

Now I know we need to be sure to call ConstructParticle() as part of those UI commands, and everything works.