Incorrectly set G4 Process and Subprocess types? about edep-sim

[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.