|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)|
Another issue with AtRest processes:
G4SteppingManager::InvokeAtRestDoItProcs first queries all available AtRest processes for their GPIL, and (in principle) calls the AtRestDoIt function of the process which returned the shortest lifetime. However, when this AtRestDoIt function is called, the time of the track is not updated by this shortest lifetime. That is, if there is a delayed AtRest process, which happens to be the winner, and which reported GPIL=T,its AtRestDoIt function will be called 'at the time' when the the particle stopped, and not by T time later, i.e. it must store T, and then generate the eventual secondaries in AtRestDoIt delayed by T compared to the global time of the track in question.
It might be intentional - is it? (I know I should read the docs but I don't remember having seen such details in those chapters which I have read).
My logic would work like this:
- query all AtRest processes for their GPIL
- select the one which returned the shortest value
- track.time += this_shortest_value
- call winnerprocess.AtRestDoIt
Although I admit that in this logic it is difficult to cope with those AtRest processes which were not the winner but which are forced to be called...
|Inline Depth:||Outline Depth:||Add message:|