Geant4 process identifier attribute type and enums about edep-sim

[ClarkMcGrew]

I don't precisely understand your questions, but I think you are asking about geant4, and not edepsim.

The values assigned to the TG4TrajectoryPoint process and subprocess fields are copied from the geant4 G4VProcess object attached to the step (or track) which created the trajectory point. The actual values are defined by geant4.

The G4VProcess object created by geant4 has process and subprocess values that are assigned based on which physics process geant4 chose to terminate the step. You can find more information about it in the geant4 physics reference, but a lot of the information has to be read from the geant4 code.

The process types are not associated with the particles. The connection comes because physics processes are assigned to each particle based on the physics list.

There is no entry associated to value 0 for G4ProcessSubtype enum. Shouldn't there be?

I'm guessing that you are asking about TG4TrajectoryPoint::G4ProcessSubtype, but I don't understand your point. Why do you expect an entry for 0?

[drinkingkazu]

I don't precisely understand your questions, but I think you are asking about geant4, and not edepsim.

Which question are you having hard time to understand? I assume all of them. But if not, I am happy to help you more.

The values assigned to the TG4TrajectoryPoint process and subprocess fields are copied from the geant4 G4VProcess object attached to the step (or track) which created the trajectory point. The actual values are defined by geant4.

I understand this. But you copied some (not all) enum values from Geant4. This process involved modification. For instance, you dropped subprocess types below

   fCerenkov = 21,
   fScintillation = 22,
   fSynchrotronRadiation = 23,
   fTransitionRadiation = 24 

defined in G4EmProcessSubType.hh. You indeed comment in TG4Trajectory.h that you skimmed it.

So my question:

There is no entry associated to value 0 for G4ProcessSubtype enum. Shouldn't there be?

... hopefully makes sense to you. You can answer could be something like: "No, this is absolutely not defined in Geant4 and they do return integer type value, not enum type value, 0" (i.e. if enum is the return type, undefined integer value cannot be casted and compilation should not work). I hope this helps you to understand one question concerning this point.

The G4VProcess object created by geant4 has process and subprocess values that are assigned based on which physics process geant4 chose to terminate the step. You can find more information about it in the geant4 physics reference, but a lot of the information has to be read from the geant4 code.

Yes, I know. I've been w/ HEP software for more than a decade :)

I'm guessing that you are asking about TG4TrajectoryPoint::G4ProcessSubtype, but I don't understand your point. Why do you expect an entry for 0?

I expect because I see that in edep-sim output files. Please see issue #25.
Furthermore, I still don't understand why you stored integer type and not the defined enum type as TG4TrajectoryPoint::G4ProcessSubtype attribute. This gave me a feeling there was an intention to modify value and not wanting to keep the enum type (i.e. 0 shouldn't be allowed if the type is enum which does not define 0).

[drinkingkazu]

... By the way, G4ProcessSubtype enum does not define value 22 (you dropped this when you hand copy&paste from Geant4 header) but it does frequently appear in edep-sim for DUNE near detector. This shouldn't be a surprise. I am wondering what was your decision point as to what to keep and what to drop. Similar to the decision of using int type to store subprocess attribute, I am just curious of your design decisions.

[ClarkMcGrew]

Do you have a specific change or feature request? If you have something that you'd like, I can think about it. I'm also happy to have pull requests for features, bug-fixes or new documentation to discuss.