There is some problem with the G4HadronicProcess. We (LHCb) have been getting particles with ToF being not a number and after some investigation I have concluded the following. What happens is that there is a sigma+ (but the same can happen to other hadrons) which loses all its kinetic energy in the AlongStep trough hIonisation, and gets its status changed to StopButAlive (which is correct). In the PostStepAction, however, there is SigmaPlusInelastic process called which changes(!) the status back to Alive (although the kinetic energy is 0!)... This is of course wrong, and in particular leads to the ToF becoming NaN, next time 'transportation' is called (you divide by the velocity which is 0). As far as I can see there are two problems in the code. Let's start from G4HadronInelasticProcess::PostStepDoIt. From there, you directly jump to G4HadronicProcess::GeneralPostStepDoIt where you do theInteraction = ChooseHadronicInteraction( and afterward result = theInteraction->ApplyYourself( This brings us to : G4LESigmaPlusInelastic::ApplyYourself where in the second line you have: if (originalIncident->GetKineticEnergy()<= 0.1*MeV) which is of course satified, because the kinetic energy is 0. This brings you directly to return &theParticleChange; BUT (!!!) as far as I could see, theParticleChange object was never initialised with the correct (i.e. set in the along step actions) value. I mean, my understanding is that in the above 'return', your intention is not to change anything as far as the particle is concerned, and in particular leave it's status as it was - this, however, is not the case. Anyway, you return to G4HadronicProcess::GeneralPostStepDoIt and you go out of the while(!result) loop. At the end, you call G4HadronicProcess::FillTotalResult where you set theTotalResult->SetStatusChange(fAlive); ignoring that the status of the track is already StopButAlive. Once you are back to G4SteppingManager::InvokePSDIP, the track gets updated with 'theTotalResult' and in particular the status gets incorrectly changed from StopButAlive to Alive... In my opinion, one should properly initialise theParticleChange (from G4HadronicInteraction) object before calling the ApplyYourself method and then in G4HadronicProcess::FillTotalResult one should check whether the status was not StopButAlive.
thank you for reporting this. I'll check entrance conditions in G4HadronicProcess, to avoid the incident. In general, this will be one for takashi, though. I do not think that the PostStepDoit should be called for tracks that have StopButAlive state. Many greetings, Hans-Peter. Many greetings, Hans-Peter.
I may not understand what Hans-Peter means, but G4SteppingManger invokes PostStepDoit's as processes requested. One (or more) of processes are considered to change the flag StopButAlive to Alive. Giving higher verbose level to processes should help to find such a process.
Hi, If this is such, we may have a subtle design error. An inelastic process cannot deal with a particle that has no energy left, hence the above fault. What has happened was this. The (inelastic) process estimated a interaction point. At the same time, between multiple scattering and energy loss, the real distance to go was reduced below that, (I would assume) due to fluctuations. So while the inelastic process had limited the step, the energy of the particle goes to zero before that step length, and thergy loss (correctly) sets stopAndKill or stopedButAlife. In this state, inelastic, or any post-step action for that matter, cannot do anything sensible with the particle any more... We should discuss more if this outside bugzilla. Many greetings, Hans-Peter.
