Long time reader, first time poster. I’m currently in the process of modifying Geant4 10.7-compatible code to version 11 compatibility and one of the changes introduced is causing us serious problems.
In versions 10.7 and below, G4PhysicsModelCatalog had a public, static Register() method that user code could leverage in order to make custom physics models available. In version 11, this method has been removed, and all physics model registration is now performed using the private, static InsertModel() method. This effectively removes any capability to add to the physics model catalog outside of the Initialize() method, at least as far as I can tell.
Is this right, or is there another, preferred way in which custom physics models can be added to the catalog? If there is no alternative, what was the purpose of removing the Register() method?
@ribon@makotoasai Could one of you address this? We (the G4CMP library) make use of the ModelCatalog in order to provide the unique index for G4Track::SetAuxiliaryTrackInformation(). If it is no longer possible to register non-G4 entries to the ModelCatalog, is there a different public interface we should be using for this purpose?
I do realize that we are coming into this conversation very late, so I don’t think we’re asking to revert the change made in G4 11.0, we just want to know what to do instead.
unfortunately I forgot completely about custom physics models when the class was revised for the major version 11.0! There were plenty of complains regarding the changing ID of (official, Geant4-distributed) physics models, as well as about the wish to have short and continuous IDs - rather than long and sparse - for plotting them (as some experiments are used to do). Because of that, I tried to solve these problems, forgetting about custom models. Even thinking now about it - thanks to this post - I don’t have a solution that allows to keep the stability of IDs regardless of the Geant4 application, physics list and version, as promised from version G4 11.0 onwards.
I’ll keep thinking about it: but if you have some solutions to propose, I am more than happy to consider them. In the meantime, I would suggest to modify the class G4PhysicsModelCatalog, by adding by hand your models…
For the existing G4 processes, I certainly understand wanting to have them continuous and invariant.
Could there be a public interface that supports registering models into the catalog in a separate “block” of indices? That block probably could not be invariant in the same sense, since it would depend on registration outside of Geant4 itself. I’m picturing restoring Register(), but maybe with a different implementation that doesn’t just append contiguously to the Geant4 stuff.
That doesn’t seem like a good solution: it means users are not using an “out of the box” version of Geant4. And for us, it means that every individual user who wants to work with the G4CMP library would have to individual modify their Geant4 source code and rebuild it.
If we copy over the G4PhysicsModelCatalog code from some specific Geant4 version, modify it, and add it to the G4CMP library, then aren’t we locked into that G4 version? If y’all add new entries to the catalog in a future G4 release, our copy would not include those changes.
This is probably the best direction for a solution. I myself hadn’t realise how hardcoded the models had become, and this also has slight implications for the “modularisation” work (breaking/merging the toolkit libraries into more coherent units, some, including physics, becoming optional).
This requirement should be noted at the upcoming collaboration meeting, and maybe we can form a small group amongst the people here to work on this after that (what do you think @ribon?). We won’t be able to get it into 11.4 given release deadlines, but I think it should be possible to design things such that it could be patched into at least a few 11.X versions (no guarantees there…) since the primary changes would be additions to the public interface, not breaking backward compatibility.
Thanks for the positive response, Ben! I’ll talk with @jakeinman and see if we can create a slide to describe our situation for the Tech Forum in a couple of weeks.
I tried putting together a simple fix by just re-adding a static, public Register()method, but the class has been re-worked since version 10.4 and the ID/name vectors are no longer mutable after initialization. I think removing this restriction would be the only way to make custom model registration feasible, but I also don’t know what the impetus behind making this particular change was.
One way to allow custom model registration while avoiding ID/name collisions would be to force custom model IDs to be assigned by the catalog at registration (e.g., either by creating another model ID category in the 40000+ range or assigning a predefined set of 30000+ IDs to custom models) and only accepting the model name as input to the public Register()method.
yes, Mike’s suggestion looks like a good solution!
Adding a new, public method, e.g. RegisterCustomModel() which should be called by the users willing to register their custom models, with their corresponding indices treated separately from the built-in models, seems to solve the problem.
By putting an offset to the “natural” indices of these custom models, as suggested also in the last post, these custom models will have a unique ID different from those of the built-in models, while keeping all the wanted properties for the latter; for the custom models, instead, they will have the same bad features of the old approach (i.e. the one before Geant4 version 11.0), namely that their IDs will change according to the application, physics list and Geant4 version, with the only guarantee to be consistently unique in each application.
Regarding Ben’s “modularisation”, I think there is no problem : the IDs of the built-in models are all set in G4PhysicsModelCatalog, regardless whether some of these models are actually used or not in an application, therefore pieces of physics libraries can become optional without affecting the IDs of the used built-in models.
Yes Ben, we can discuss about it at the Collboration meeting : I will write a few slides about it…
Many thanks for the very useful comments and suggestions!
Thank you very much, Alberto and Ben! I didn’t register for the Collaboration Meeting (my direct participation in G4 is too low, and not directly supported, to allow me to travel), but I would be happy to join a discussion of this if you would like me to. It’s not necessary, bur I can be available if y’all would like.
In the mean time (since this would not be available until 11.5 at the earliest), I think we can “hack” things by temporarily copying the 11.4 version of G4PhysicsModelCatalog.cc into G4CMP, and adding the single model ourselves under “other”. Our reference to it in the G4CMP code will force our local .o to resolve it at compile/link time, superseding the Geant4 library. We did this in the CDMS simulation long ago to pull in patches for some geometry stuff, so I know it works, even though it’s horribly ugly.