Faulty saved strings for parent isotope

Hello everyone,

I am simulating primordial decay chains from material surrounding my active volume which is defined as sensitive detector. As I am not only interested in the straight-forwards secondaries (e.g., the e- in the beta decay), but also I want to know the parent isotope for their secondaries (e.g., the delta electrons of the beta e-), I cannot simply use the parent type.

So far I have solved this problem by creating a static map in the EventAction of the type static map<G4int,G4String>. This map associates to each track ID the name of the parent isotope. It is filled in the SteppingAction, where at each step the map is updated as follows: if the current particle is an ion, then its name is saved in the map corresponding to the current ID (e.g., track ID is 1 for U238, so the saved parent type is U238). If the particle is not an ion, then the parent ID is considered and the string type of that parent ID is saved (e.g., track ID is 2 and particle is an alpha, so the parent type saved in the map for ID=2 (and parent ID=1) is map[2] = map[1], in this case U238).

When I produce small simulations, this works fine and I have no issues. When I do massive simulations, I see that in around one out of 105 events the string of the parent type has issues. For example I see that instead of Ac228 it is Ac222 (and I am sure that in the Th232 chain there is no Ac222) or, if I apply the same including neutron as possible parent type, I see that instead of neutron, a bunch of events show neu or neut. The limited extension of the problem does not make it really a problem in my case, but I would like to know if you have any idea why that: do you think this is an issue of saving in root file or is it the too often access and update of the static map? Do you have any other reliable way to save this information? I am working with multitasking, but different events should be in different tasks, so there should not be problems due to memory access requiring mutex.

I am using GEANT4 11.0.3.

Thank you,

I think the magic keyword here could be “thread-local singleton”.

storing the history of encountered volumes in an event sounds quite similar: List of Encountered Volumes