|Message: Re: Processing order||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)|
> What is the default processing order of main particles generated by the > primary generator
Last in First out!
> and all its produced secondary particles?
Again, LIFO, and it depends on the process that generates the secondaries in what order it puts them on the list. This is not generally documented and can be understood by looking at the DoIt method, or simply with tracking-verbosity.
> I believe I read somewhere that in each vertex when new > (secondary) particles are produced, they will get tracked first before > continuing back to the original particle (I guess the so called parent > particle)?
NO, this is generally not the behaviour of Geant4. It is true, and the default, for processes that generate optical photons - such as G4Cerenkov and G4Scintillation - but these are the exceptions. A particle is tracked until it stops, no matter how many secondaries it generates along the way. An inelastic process may 'kill' the incoming neutron, and put another, different, neutron as a secondary on the stack. In that case, some other partice that might also be a secondary, may be tracked in between the incoming and outgoing neutron.
Generally, the ordering of tracking should not by of a concern to you.
> Also, what is the best way to check how a particle gets killed?
In SteppingAction (or ProcessHits):
aStep->GetTrack()->GetTrackStatus() == fStopAndKill
This doesn't tell you 'how' it got killed but that is was 'killed' by one of the processes active during the current step. For possible TrackStatus see:
> For > example, for neutrons, the particle could be killed by leaving the > universe,
which you get with:
aStepStatus = aStep->GetPostStepPoint()->GetStepStatus();
> or by going inelastic interaction, or by energy/time cut off > thresholds or by thermal capture.
If you want to know the process that defined the simulation step:
const G4VProcess* process = aStep->GetPostStepPoint()->GetProcessDefinedStep();
If you want to know all processes that were active during a step, it is more complicated, see:
but luckily, all you got to do is simple increase the /tracking/verbose until you get the information you need.
> Other ideas?
Yes, all this information you could have obtained by reading our documentation and/or the tips and FAQ section on our website.
|Inline Depth:||Outline Depth:||Add message:|