User-custom physics modelID can't be used for TrackInfo?

Particles, Track, Event, Run and Biasing
1

Geant4 Version: 11.4.2
Operating System: Linux, MacOS
Compiler/Version: various
CMake Version: various

We are using a “very low energy” add-on library (G4CMP) which includes custom physics processes to which we assign a custom Physics ModelID. With many thanks from us, Alberto Ribon re-implemented the ability to register custom models in G4PhysicsModelCatalog as part of Geant4 11.4.2. That ability replaces our “local hack” of overriding the G4PhysicsModelCatalog::Initialize() function, to add G4CMP to the “offical Geant4 list” of models.

Unfortunately, the new feature doesn’t work. In our job initialization, we use the new code

  G4PhysicsModelCatalog::RegisterCustomModel("G4CMP process");
  fPhysicsModelID = G4PhysicsModelCatalog::GetModelID("G4CMP process");

which in our case results in fPhysicsModelID = 40000. Later, we attempt to attach our AuxiliaryTrackInformation object by using that registered modelID:

  track.SetAuxiliaryTrackInformation(G4CMPConfigManager::GetPhysicsModelID(),
                                     trackInfo);

(where trackInfo is an instance of our subclass of G4VAuxiliaryTrackInformation).

This results in a Geant4 FatalException:

-------- EEEE ------- G4Exception-START -------- EEEE -------
*** G4Exception : TRACK0982
      issued by : G4VAuxiliaryTrackInformation::G4VAuxiliaryTrackInformation()
Process/model ID <40000> is invalid.
*** Fatal Exception *** core dump ***

Is this a known problem? Do we need to do something different with the SetAuxiliary... function for custom model IDs?

2

@ribon ? Do we need to do something different now to associate track info with a custom modelID?

3

Hi Mike,

you are right, also this time: there is indeed a problem in Geant4!

This time, it is not a missing feature, or something wrong, with the class G4PhysicsModelCatalog.
It is instead a kind of “relic” of the past in the class G4Track, when there was only one type of model-id, rather than the two current ones - modelID (the one to be used nearly always) and model-index (to be used only for plotting).

The fix is simple: the following few lines should be deleted:

void G4Track::SetAuxiliaryTrackInformation( G4int id, G4VAuxiliaryTrackInformation* info ) const {
…
if ( G4PhysicsModelCatalog::GetModelIndex( id ) < 0 ) { //<—TO-BE-DELETED
G4ExceptionDescription ED; //<—TO-BE-DELETED
ED << “Process/model ID <” << id << “> is invalid.”; //<—TO-BE-DELETED
G4Exception( “G4VAuxiliaryTrackInformation::G4VAuxiliaryTrackInformation()”, //<—TO-BE -DELETED
“TRACK0982”, FatalException, ED ); //<—TO-BE-DELETED
} //<—TO-BE-DELETED
…
}

I’ll do a MR and it will be ready in 11.5 and for the next patch, 11.4.3 (not yet scheduled).
In the meantime, just edit the file G4Track.cc and comment our the above few lines!

Thanks, once more, for the feedback!

Cheers,
Alberto

4

Thanks, Alberto! So it looks like it’s just removing the ModelIdex test (which doesn’t exist for user-custom models), and going with “any” model ID.

Should there be some kind of test that the number being passed into SetAuxTrackInfo() is valid? I notice that G4PhysicsModelCatalog doesn’t have such a test (it looks like GetModelIndex() was being used for that purpose). Maybe something like

G4bool G4PhysicsModelCatalog::IsValidModelID(const G4int modelID) {
  return ( (modelID >= GetMinAllowedModelIDValue()  &&  modelID <= GetMaxAllowedModelIDValue())
           || (modelID > GetMaxAllowedModelIDValue()  &&
               modelID <= GetMaxAllowedModelIDValue() + G4int(theVectorOfCustomM
odelNames->size()))
          );
}

Without some test like that, I can see user custom code passing in an arbitrary “large number” that wasn’t actually registered.

5

I confirm that the fix has been introduced in the development version of Geant4, and it will appear in the December release, 11.5. It will also be included in the next patch of the current version, 11.4.3, but this patch has not yet been scheduled.

Regarding your suggestion of checking that model-ID has a meaningful value, this is already present in the method G4PhysicsModelCatalog::SanityCheck, which is called by G4PhysicsModelCatalog::Initialize.

In my opinion, the map:

std::map< G4int, G4VAuxiliaryTrackInformation* >* fpAuxiliaryTrackInformationMap

which is a private member of the class G4Track, can and should be more general regarding the meaning of the integer, first argument, not necessarily a “model-ID”. Therefore, for the next major release of Geant4, 12(not yet scheduled), where it is allowed to break user code, I would propose to remove the method:

void G4Track::RemoveAuxiliaryTrackInformation(G4String& name) {
if (fpAuxiliaryTrackInformationMap != nullptr) {
G4int id = G4PhysicsModelCatalog::GetModelID(name);
RemoveAuxiliaryTrackInformation(id);
}
}

which assumes that the integer of the map is a model-ID.
I would keep instead the method:

void G4Track::RemoveAuxiliaryTrackInformation(G4int id) {
if ( fpAuxiliaryTrackInformationMap != nullptr &&
fpAuxiliaryTrackInformationMap->find(id) != fpAuxiliaryTrackInformationMap->cend() ) {
fpAuxiliaryTrackInformationMap->erase(id);
}
}

which is more general (i.e. it does not assume that the integer in the map is a model-ID).

6

Thanks, Alberto! I think it makes sense to keep Add and Remove by name (where the name string is assumed to to be a proper physics model), and remove the ID check from the Add/Remove by number.