Since Geant4.10.0 optical photons trigger ProcessHits method at boundaries automatically. Watching the boundary in the RootSteppingAction and triggering this method by hand is not necessary anymore. If implemented nevertheless each hit will be written down twice. I suggest to update the example.
Thanks for pointing this out.
Hi, thanks. How are you able to see that hits are recorded twice? I don't see any double counting occurring. The automatically-invoked LXePMTSD::ProcessHits(...) doesn't do anything. Counting is done by LXePMTSD::ProcessHits_constStep(...), called by Stepping action. The code might be more readable if LXePMTSD::ProcessHits(...) was used. I'll investigate.
It seems the LXe output is correct, even with the automatic triggering of ProcessHits. This can be verified by turning of the automatic triggering with /process/optical/boundary/setInvokeSD false in the macro. This is because LXePMTSD::ProcessHits simply returns false. UserSteppingAction calls LXePMTSD::ProcessHits_constStep. The next question is, why not use the automatic G4OpBoundaryProcess::InvokeSD, rather than the LXeSteppingAction? G4OpBoundaryProcess::InvokeSD is only triggered for Detection events, but LXeSteppingAction deals with other types of interaction like Absorption and Backscattering as well. [1] However, I don't think G4OpBoundaryProcess::InvokeSD works exactly as advertised. In G4OpBoundaryProcess::PostStepDoIt, InvokeSD is only explicitly called for Detection. [2]. But G4OpBoundaryProcess::PostStepDoIt can return early, for example for case StepTooSmall [3], calling the base G4VDiscreteProcess::PostStepDoIt whcih eventually calls LXePMTSD::ProcessHits. Therefore, to use G4OpBoundaryProcess::InvokeSD, it is necessary to check in the application SD ProcessHits (e.g. LXePMTSD::ProcessHits) that the status is Detection. A better approach might be to remove the Detection check in G4OpBoundaryProcess::PostStepDoIt [2] and have the user check for boundary status in ProcessHits. This way one can handle all boundary statuses with a sensitive detector. This should maybe be a separate bug report. The above isn't in agreement with the README [4]. I'm going to mark this bug report as Invalid, because I have to mark it as something and none of the options really fit. Thanks for reporting this. [1] https://geant4.kek.jp/lxr/source/examples/extended/optical/LXe/src/LXeSteppingAction.cc#L173 [2] https://geant4.kek.jp/lxr/source/processes/optical/src/G4OpBoundaryProcess.cc#L480 [3] https://geant4.kek.jp/lxr/source/processes/optical/src/G4OpBoundaryProcess.cc#L187 [4] https://geant4.kek.jp/lxr/source/examples/extended/optical/LXe/README#L138
new bug report: https://bugzilla-geant4.kek.jp/show_bug.cgi?id=2222
