PhysicsList in rdecay01 example (\extended\radioactivedecay)

Looking at the PhysicsList.cc file of rdecay01 example, the ConstructProcess() function registers G4Radioactivation() process with G4GenericIon::GenericIon().

This is odd in two aspects…
(i) there is no particle of G4GenericIon::GenericIon() type defined in ConstructParticle().
(ii) all the particles (e.g., geantino, gamma, elenctron) defined in ConstructParticle() are not associated with any physics processes in ConstructProcess().

I must be missing something. Could anyone please shed some light on this?

The answer to the second question could be found in the manual:
“if just the G4Geantino particle class is required, only the transportation process need be registered… the AddTransportation() method is provided in the G4VUserPhysicsList class to register the G4Transportation class with all particle classes.”

The first question still stands, but let me rephrase it a bit. The README file for the rdecay01 example says that “all particles and ions behave as geantino, eg. no energy loss.” I assume the following lines of code do the work, i.e., direct the program to consider all the particles and ions (created in ContructParticle()) as geantino.

G4PhysicsListHelper* ph = G4PhysicsListHelper::GetPhysicsListHelper();
ph->RegisterProcess(radioactiveDecay, G4GenericIon::GenericIon());

However, shouldn’t it use G4Geantino::GeantinoDefinition(), instead of G4GenericIon::GenericIon()?

may I suggest the following : in contructParticles(), suppress 1 particle, for example gamma, recompile and try to execute macro rdecay01.in

This is odd. Note that G4GenericIon is a “special” thing, which is used to collect the common set of processes used by all G4Ions instances. The fact that it’s missing from the RDM physics constructor may just be an oversight, which doesn’t cause an error because it’s been instantiated elsewhere in the physics list.

Those other particles are instantiated here because they (with the exception of G4Geantino) are possible final state particles from RadioactiveDecay, so they need to exist in order for RadioactiveDecay to do its job.

ConstructParticle() is there to ensure that the particle tables are fully populated in the master thread, before the event loop begins. The only particles that are allowed to be created “on demand” (within events) are specific G4Ions instances (particular Z,A combinations).

Suppressing one of the particles, the program doesn’t even start… After the change, I don’t notice any problem with the compilation and building. However, when I execute the program, it shuts down right after displaying the following message in the command prompt: “Available UI session types: [ Qt, Win32, GAG, csh ]”.

Yes you right! G4GenericIon::GenericIon() is one of the ions defined in the G4IonConstructor::ConstructLightIons(), which is called by G4IonConstructor::ConstructParticle().

I still have difficulty with understanding how these two lines make "all particles and ions behave as geantino, eg. no energy loss.” as described in the README file:

G4PhysicsListHelper* ph = G4PhysicsListHelper::GetPhysicsListHelper();
ph->RegisterProcess(radioactiveDecay, G4GenericIon::GenericIon());

The particle associated with the G4RadioActivation process is G4GenericIon::GenericIon(). Am I understanding your answer correctly that, using G4GenericIon, all the G4Ions instances will be associated with the process? What about the particles (i.e., non-ions)?

Also, the registered process is G4RadioActivation. Could it be G4RadioactiveDecay or G4RadioactiveDecayBase instead? For example, could it be like this?
ph->RegisterProcess(new G4RadioactiveDecay, G4GenericIon::GenericIon());

Radioactive decay only operates on atoms. No other particle uses it. For decays of “beamlike” particles (muons, pions, K mesons, etc.), the G4DecayProcess is used.

With the explanations you provided to this and another posting, I can see now what’s going on.
The GenericIon is associated with the radioactive decay process, while all the other particles are associated with only the transportation process (no other physical processes), which makes them behave as geantino. I incorrectly assumed that there was a command directing the particles to behave as geantino. Thank you so much for the helpful explanations.