Incorrectly set G4 Process and Subprocess types?

[drinkingkazu]

There seem to be an issue with values filling TG4TrajectoryPoint::Process and TG4TrajectoryPoint::Subprocess attributes. If I generate an event with particles (defined by me), these attribute values are set to 0. In TG4Trajectory.h, G4ProcessType enum is defined with the value 0 associated with kProcessNotDefined. For G4ProcessSubtype, 0 is not defined but I assume this is the right values to be filled for user-injected particles.

Here's the issue:
If I look at the 2nd and 3rd events where identical set of particles are injected into Geant4 world for tracking, these attributes (Process and Subprocess) are filled with non-zero values. This seems like a bug but please correct me if I am missing something.

Here's a sample data file produced using edep-sim.
Here is a print-out of TrackId, ParentId, Process, and Subprocess attribute values for the first three events.

Entry 0
Track ID 0 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 1 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 2 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 3 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 4 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 5 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 6 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 7 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 8 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 9 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 10 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 
Track ID 11 Parent ID -1  G4ProcessType 0 G4SubProcessType 0 

Entry 1
Track ID 0 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 1 Parent ID -1  G4ProcessType 2 G4SubProcessType 12 
Track ID 2 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 3 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 4 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 5 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 6 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 7 Parent ID -1  G4ProcessType 2 G4SubProcessType 13 
Track ID 8 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 
Track ID 9 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 
Track ID 10 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 11 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 

Entry 2
Track ID 0 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 1 Parent ID -1  G4ProcessType 2 G4SubProcessType 13 
Track ID 2 Parent ID -1  G4ProcessType 4 G4SubProcessType 111 
Track ID 3 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 4 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 
Track ID 5 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 6 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 
Track ID 7 Parent ID -1  G4ProcessType 2 G4SubProcessType 13 
Track ID 8 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 9 Parent ID -1  G4ProcessType 4 G4SubProcessType 111 
Track ID 10 Parent ID -1  G4ProcessType 2 G4SubProcessType 2 
Track ID 11 Parent ID -1  G4ProcessType 2 G4SubProcessType 22 

Below, you find a simple python script I am running to printout this information.

from ROOT import TChain
import sys
ch=TChain('EDepSimEvents')
ch.AddFile(sys.argv[1])

for idx in range(ch.GetEntries()):

    print('\nEntry',idx)
    ch.GetEntry(idx)

    for p in ch.Event.Trajectories:

        if p.GetParentId() >= 0: continue

        msg1 = 'Track ID %d Parent ID %d ' % (p.GetTrackId(), p.GetParentId())

        pt = p.Points.front()

        msg2 = 'G4ProcessType %d G4SubProcessType %d ' % (pt.GetProcess(),pt.GetSubprocess())

        print(msg1,msg2)

[drinkingkazu]

Sorry I forgot to quote: I used edep-sim built in this container if anyone would like to know/see.

[ClarkMcGrew]

The process and sub-process type are copied directly from the underlying G4VProcess* for the step or track. I suspect that you are looking at a particles with an undefined process.

Can you please attach the simplest input kinematics file and the associated geant4 macro file that will reproduce the issue.

[drinkingkazu]

I have no doubt they are supposed to be copied from G4 and there appears to be no room of a mistake.
Yet, these particles are injected by me.
12 muons per event, all with identical momentum to the floating point precision (not printed out above but i'm sure you can check by yourself easily, + easy modification to above script).
So I expect them to have the same Process and Subprocess attribute values.

Unfortunately I don't have a g4 macro that works handy because this came out from running a custom event generator.
If you are certain that this cannot happen (that Process and Subprocess attribute values should be correctly reset to 0 by Geant4 for all subsequent events after the first one) because this is explicitly verified (rather than considered "should not happen"), I am happy to postpone this discussion till I can give you a run script.

But if somehow you could take a look, that would be great. Sorry for not being able to attend this problem right now... I will for now comment as a potential bug in my software that depend on edep-sim and mark as unreliable information when ParentId == -1.

[ClarkMcGrew]

The trajectory point values should be a faithful representation of the internal G4 values (and if G4 doesn't initialize the value, it should be a faithful copy of that too). Have you seen evidence that the value is not a good copy of the step that created the trajectory point?

What needs to be checked, and which I haven't reproduced, is an example where the process/subprocess values copied into the TG4TrajectoryPoint object do not match the values present in the G4VProcess (actually the derived class) associated with the step that is creating the trajectory point, or that the value in the TG4TrajectoryPoint object is being incorrectly modified after it is assigned.

[drinkingkazu]

@ClarkMcGrew to me, above stored values are enough evidences.

But let me understand this point clearly: so you are suggesting the issue may be in Geant4 rather than edep-sim?

I expect Geant4 to give an identical tag for creation process for injected particles if Geant4 is correctly reset for each event simulation. In the past, I have dealt with G4String rather than a combination of process and subprocess enums (not in edep-sim, different experiments different G4 wrapper softwares / running bare G4). But I don't have a reason to doubt it should be different (i.e. like G4String I assume process and subprocess enums to be reset).

Yes, I am glad to hear you have not done the check = this remains as a possibility. That was my question (whether this was actually checked before) and I appreciate the answer that this is never validated.

is because whenever I dealt with Geant4 in the past, the G4String associated with a creation process of injected particles have been consistent

[ClarkMcGrew]

My understanding is that you have found a case where the saved process and subprocess values do not match your expectation, and you have isolated the problem to be that the saved edep-sim values to do not match internal geant4 values.

The validation includes inputs similar to what I think you describe, and does not reproduce your report. It "works for me".

I do not have example inputs where the process and subprocess values are incorrectly saved.

To debug, I need example inputs which produce incorrect results and that can be used to write a test. The output is not sufficient.

Alternatively, I would be very happy to have a PR with a test (and, ideally, a fix), which can be validated and merged.

[ClarkMcGrew]

Bug not verified.