Hello, moving from G4.10.6.p2 to G4.10.7.p2 I observe that the tracking procedure for primaries has probably changed. While in the older version the primary particle was tracked until it died due to decay, it is now suspended at each hIoni process step in a radiator gas, i.e. the track status is now 4 (suspend) instead of 0 as it was using the older G4 at very such step. Then after each such step, the G4UserTrackingAction::PostUserTrackingAction is now executed, which was not the case in the older version (probably due to track status =0). However, to my understanding this execution should not happen since the track is still alive and wil be tracked further later on. Three questions arise: 1) Has the tracking order (for primary particles) changed and if so why? 2) Why does the track status ‘suspend’ lead to the execution of the PostUserTrackingAction if the track will be tracked later further? 3) Is this is a bug or a feature? If the latter is true, is a StackingAction code needed to go back to the old tracking order? The result of this change is that the the primary particle gets stored 70 times extra since the PostUserTrackingAction is executed at every hIoni step and the storage is triggered there. Thank you very much in advance for feedback.
Hello. Geant4 kernel does not set "suspend" status. This is an artificial state provided to the user. Which example code are you using? Could you please check if your user stepping action sets it for some reason?
Hello, thank you for your reply. The point is, that I only changed the Geant4 version, nothing else and nothing in the user code. We do not set 'suspend' track status in any user function (also not in the SteppingAction) since there is no reason to do so and we do not have a StackingAction running. What I am concerned about is that the G4UserTrackingAction::PostUserTrackingAction is executed serveral times during the tracking of the same (primary) particle leading to the extra storage of the related particle properties during the same event. To my understanding, this function should be executed only once at the end of the tracking. Since this issue is observed due to the change in Geant4 version, I thought something has changed between 10.6 and 10.7 that could be responsible for it. I isolated the cases where this happens and it turned out that the primary particle track status changed from 0 to 4 (which I understand from G4 source code is 'suspsend', is that correct?) in these cases. This only appears when the process hIoni is involved. But I did not test extra interactions, so it can well be true for other processes not being involved here. But maybe this is all not connected and it would thus be great to get guidance for what else to check in order to pin down the real problem when moving from 10.6 to 10.7. Thank you very much.
Hello, can you, please, reproduce the problem in any Geant4 example? It is your choice. If the issue happens in the sequential mode you may use $G4INSTALL/examples/extended/hadronic/Hadr01, if instead in the MT mode may be $G4INSTALL/examples/extended/electromagnetic/TestEm5 VI
Hi Simone, Does youe application have Scintillation or Cerencov process?
(In reply to asai from comment #4) > Hi Simone, > Does youe application have Scintillation or Cerencov process? Hello, thank you for your reply. In this radiator gas, also Cerenkov and Scintillation processes are involved, however, they appear only for secondary particles and other types than the primary particle, which is a K+ of 75 GeV/c. This is a bit strange, since using the older G4, I indeed see Cerenkov processes for the primary K+. But this could maybe also be by chance. The observation described in this ticket, appears to be solely linked to hIoni. I checked the step before hIoni is performed and the track status change happens the first time. But there, I only see Transportation. So we have a case: PreStep: Transportation, PostStep: hIoni which has changed track status 4 compared to the step before. Another example is: PreStep: nothing and then PostStep hIoni with track status 4 Has anything changed concerning charged Kaon processing, i.e cross-sections, tracking? Best regards, Simone
Hi Simone, By default, the optical processes G4Cerenkov and G4Scintillation put the primary track status to suspend, and track optical photons before resuming tracking of the primary particle. This is because there may be many optical photons generated, and they will fill up available memory. It may also be that it is hIoni that is limiting the step, not the optical processes. But the optical processes may still be active in the step. Thus, it may be possible that with 10.6.2, the suspension of primary tracks was turned off in your application, and in 10.7.2 it is not for some reason. If you add /process/optical/scintillation/setTrackSecondariesFirst false /process/optical/cerenkov/setTrackSecondariesFirst false to your macro, the primary should not be suspended. If this works, I'd appreciate further information as to your setup, to figure out why the behaviour changed. Also, as you note, these comments might not be relevant.
Hi Simone, Is it possible to printout in which volume the track was suspended? Is it a volume where Scintillation or Cerenkov should happen?
(In reply to Daren Sawkey from comment #6) > Hi Simone, > > By default, the optical processes G4Cerenkov and G4Scintillation put the > primary track status to suspend, and track optical photons before resuming > tracking of the primary particle. This is because there may be many optical > photons generated, and they will fill up available memory. > > It may also be that it is hIoni that is limiting the step, not the optical > processes. But the optical processes may still be active in the step. > > Thus, it may be possible that with 10.6.2, the suspension of primary tracks > was turned off in your application, and in 10.7.2 it is not for some reason. > > If you add > /process/optical/scintillation/setTrackSecondariesFirst false > /process/optical/cerenkov/setTrackSecondariesFirst false > to your macro, the primary should not be suspended. > > If this works, I'd appreciate further information as to your setup, to > figure out why the behaviour changed. > > Also, as you note, these comments might not be relevant. Hello Daran, thank you for your reply and the explanation. The lines you suggest are already part of our physics list code, hence they should be active. They are set using the G4Scintillation and G4Cerenkov pointer, not via G4OpticalParameters as I see in some G4 examples. Could this make a difference? Apart from the changed tracking order, the a point why this ticket was created is that together with this changed order, the PostUserTrackingAction is triggered every time the track gets status 'suspend'. Is this forseen like this? I could not find any documentation about it. To my knowledge, this function is invoked at the end of the full tracking chain of each track, i.e when the particle is dead.
(In reply to asai from comment #7) > Hi Simone, > > Is it possible to printout in which volume the track was suspended? Is it a > volume where Scintillation or Cerenkov should happen? Hello, both processes are part of our simulation. The volume, where the described issue happens, is filled with gaseous N2 and Cerenkov light is expected. While addressing the comments here in this ticket, I realised that there is indeed an issue when using 10.7.2, since I do not see Cerenkov for the primary any more in the prestep and poststep printout. I focussed too much on the hIoni and the suspend status causing the multiple storage of the primary, that I overlocked this fact. As I wrote in my comment #5 I thought first this is by chance that I did not see Cerenkov in the printout, but I checked more seeds and I get the same result: no Cerenkov processes any longer now for the primary compared to 10.6.2 in the steps. BUT: I do see optical photons, which were indeed produced by Cerenkov (=creatorprocess) in this volume and the parent is indeed the primary track. So the question is: why is Cerenkov not present in the prestep and poststep process printout? Of course I cannot exclude that our settings/setup are not perfect and that in the past this was not an issue but with the new G4 version it now is, so that potential issues on our side are now revealed. But I would not know how to proceed.
Hi Simone, > I do not see Cerenkov for the primary any more in the prestep and poststep printout. If I understand correctly, you see the optical photons, but they are not printed out each step. Are you referring to the printout provided by the G4Cerenkov process, or a different printout? If the G4Cerenkov process, it may be the same reason as the track being suspended. It seems like configuration of the process is being overwritten by the G4OpticalParameters. > But I would not know how to proceed. If the above is the explanation: starting with 10.7 there is the G4OpticalParameters that stores the parameters for the various optical classes. This is done for thread safety. The recommended way to set the parameters is either in code: get the G4OpticalParameters instance and configure it: auto opticalParams = G4OpticalParameters::Instance(); opticalParams->SetCerenkovVerboseLevel(val); // 0,1,2 opticalParams->SetVerboseLevel(val2); // all optical processes or in macro: /process/optical/cerenkov/verbose 1
(In reply to Daren Sawkey from comment #10) > auto opticalParams = G4OpticalParameters::Instance(); > opticalParams->SetCerenkovVerboseLevel(val); // 0,1,2 > opticalParams->SetVerboseLevel(val2); // all optical processes Hi Daran, thank you for this hint! Using the above verbose function, I indeed see Cerenkov processes for the primary kaon. However, in the pre/post step info that I print in SteppingAction, this still does not appear. This is similar to the observation I had last time, when I did see optical photons stemming from the kaon and being created via Cerenkov, but the kaon did not seem to have underwent that process as the printout in SteppingAction did not show it, but hIoni instead. An example individual printout with the opt. proc. verbose level increased as suggested by you above for the kaon+ = primary: %%%%%%%%%%%%%%%%%%%%% ID 1 preproc: hIoni postproc: hIoni track status 0 PreStep: -7.6 5.7 69682.2 232.4 | 1.400426 2.499062 75667.658434 75669.268914 | kaon+ CedarFrontPipeRadiatorGas 4 PostStep: -7.6 5.7 69703.6 232.5 | 1.474964 2.462486 75667.650876 75669.261357 | kaon+ CedarFrontPipeRadiatorGas 4 G4VRestDiscreteProcess::PostStepGetPhysicalInteractionLength() - [ Scintillation] Particle type - kaon+ mass: 0.493677[GeV] charge: 1[e] Direction x: 1.94927e-05, y: 3.25434e-05, z: 1 Total Momentum = 75.6677[GeV] Momentum: 0.00147496[GeV], y: 0.00246249[GeV], z: 75.6677[GeV] Total Energy = 75.6693[GeV] Kinetic Energy = 75.1756[GeV] MagneticMoment [MeV/T]: 0 ProperTime = 0.0115024[ns] in Material Cedar_Radiator InteractionLength= 1.79769e+307[cm] Exiting from G4Cerenkov::DoIt -- NumberOfSecondaries = 3 %%%%%%%%%%%%%%%%%%%%% ID 1 preproc: hIoni postproc: hIoni track status 0 PreStep: -7.6 5.7 69703.6 232.5 | 1.474964 2.462486 75667.650876 75669.261357 | kaon+ CedarFrontPipeRadiatorGas 4 PostStep: -7.6 5.7 69713.9 232.5 | 1.403958 2.473802 75667.646178 75669.256658 | kaon+ CedarFrontPipeRadiatorGas 4 So, process hIoni is communicated at step level, despite Cerenkov process active as the additional printout says. But maybe I misunderstand the relation of the two prints here. BUT: Using now the class 'G4OpticalParameters' instead of e.g. 'G4Cerenkov' for *all* the related settings, finally restored the behaviour of 10.6. concerning the track status 'suspend' and the occurance of Cerenkov in the printout. Thanks for your help!!!
Nonetheless, I am sorry if I repeat myself: why is the track status 'suspend' triggering the PostUserTrackingAction everytime? From what I read in the docs it should be triggered when the particle is killed/decayed. To me, this appears to be independent of the above problem. Is this also new in 10.7?
Hi Simone, When the track is put into Suspend status, PostUserTrackAction is intentionally called. This is because this is when both the primary and secondary particles are available to the user. If you don't want anything to happen in this case, you can test for the track status being Suspend, and return. I suspect that hIoni is printed out as the process that is limiting the step size. Cerenkov (and scintillation if applicable) will still be active. In summary: there is a bug in that configuring optical processes directly silently fails. But you can use macro commands or G4OpticalParameters instead. Is this correct?
Geant4 code is updated (for version 11) so that setting parameters via a pointer to the process works again. This restores the original behaviour. It remains possible to change parameters via G4OpticalParameters. Makoto, could you please mark this as resolved.
*** Problem 2422 has been marked as a duplicate of this problem. ***
