Message: Re: Strange behaviour for AtRest processes Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: Strange behaviour for AtRest processes 

Forum: Event and Track Management
Re: Warning Strange behaviour for AtRest processes (Daniel Barna)
Date: 02 Nov, 2012
From: Tom Roberts <Tom Roberts>

This leads to one of my problems with AtRest processes: only one time step is allowed. Why doesn't the Geant4 kernel do the same thing for AtRest that it does for normal tracking? -- repeat steps until the track has been killed.

I have two different use-cases for this:
 1. I have a modified version the geant4 tracking kernel that takes 
    steps in time for a std::vector<> of tracks. This is so collective
    beam processes can be implemented at each time step (e.g. space
    charge). It does not work correctly for tracks that stop in a
    material (i.e. are AtRest).

 2. In an inverse cyclotron, muons are stopped in a low-pressure
    gas, and then are extracted by a time-dependent electric field
    that turns on and accelerates them out. Multiple AtRest steps
    are required to wait for the E field to turn on.

In both cases I have attached a process to the particles that limits each step to the value of the global time for the next time step. For #2 I would also have a process that changes the status of the particle from fStopButAlive to fAlive, when the E field comes on.

It would be VERY useful to me if the Geant4 kernel were modified to take multiple steps in time for an AtRest track. There may be multiple AtRest processes, and at each step, the one with the shortest AtRestGPIL should be called, just as for PostStepGPIL. For AtRest, GPIL returns a step "length" in nanoseconds, as documented.

For the usual (current) case of a single Decay AtRest process, the behavior would be the same, as Decay will have the shortest (the only) GPIL, and will kill the track. Ditto for MuonMinusCaptureAtRest.

 Add Message Add Message
to: "Re: Strange behaviour for AtRest processes"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]