Problem 1216

Who kills the particle if there is no AtRestDoIt process? You need to have at least one.

Dear Takashi,

The printing happens for stable particles like e- or gammas which get just stopped after loosing their energy (see verbose output below).
In case the physics processes are defined just via G4EmStandard physics,
there is no warning about no AtRestDoIt process active. So I would expect the same behavior when scintillation is added and inactivated.

Could you, please, have a look once more at this?

Thank you,

Ivana

*********************************************************************************************************
* G4Track Information:   Particle = e-,   Track ID = 60,   Parent ID = 59
*********************************************************************************************************

Step#      X         Y         Z        KineE    dEStep   StepLeng  TrakLeng    Volume     Process
    0  -5.52 cm  -4.34 cm   2.29 mm    2.3 keV     0 eV      0 fm      0 fm         Tank    initStep
    1  -5.52 cm  -4.34 cm   2.29 mm      0 eV    2.3 keV   202 nm    202 nm         Tank       eIoni
ERROR - G4SteppingManager::InvokeAtRestDoItProcs()
        No AtRestDoIt process is active!
    2  -5.52 cm  -4.34 cm   2.29 mm      0 eV      0 eV      0 fm    202 nm         Tank       eIoni

Why do you need an AtRestDoIt process for e-?

Let me corret myself. Scintilation needs an AtRestDoItProcess for any particle types. 

When Scintilation is inactivated, ProcessManager->GetAtRestPrcessVector->entries() should return 0.

 If a process is inactivated, the process manager set its pointer to 0 in the Process Vector. The process is not removed from the vector in order to simplify procedures of re-activation. So, ProcessManager->GetAtRestPrcessVector->entries() does not change if  Scintillation is inactivated,

 I think that the Scintillation need not be attached to the AtRest for the stable particles such as proton and electron. No other AtRestDoIt is applied for the stable particles. It means that the AtRestDoIt of Scintillation process is invoked but nothing will happen because no energy deposit is expected in the step.

There is the possibility that the secondary charged particles produced
are below the 'range cut' set for the application. In this case, the kin.
energy of them will be attributed to the energy loss of the stopped particle (in particular, gammas, for example in the photo-electric effect). So the G4Scintillation process also needs to be attached for AtRest to the gamma (which btw is a stable particle).

I am not certain that the gamma is the only stable particle that can give energy to the medium when already at rest. Back in 2002 we found that the G4Scintillation process did not receive the total energy of a 500keV electron in liquid xenon. The problem was discovered to result from three causes:

     (i)  When G4Scintillation is not the last discrete process invoked in the
process loop
      (ii) Energy lost at rest by any particle did not lead to scintillation
      (iii) In case a process sets the 'StopAndKill' flag, no PostStep process
is invoked, even those with 'forced' condition, except the first
(Transportation).

To solve (ii) G4Scintillation was made to inherit from G4VRestDiscreteProcess and an AtRestDoIt was implemented which simply invokes the PostStepDoIt.

To solve (i) SetProcessOrderingToLast method for the G4Scintillation process in PostStep and AtRest actions.

Some developers at the time championed the idea of a new type of process (besides Along, Post and AtRest). These would be invoked after all other processes when it is guaranteed that all the energy during a step has indeed been accumulated. By design, such processes cannot act on the G4Track itself. The first candidate for such a process type is G4Scintillation. Other developers were against this idea because they felt it leads to a proliferation of process types.

tag: phys-lists-V09-04-45 hopes to address this bug report