|Message: Re: Strange behaviour for AtRest processes||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
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.