Message: Re: Processing order Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Feedback Re: Processing order 

Forum: Event and Track Management
Re: Question Processing order (C Mos)
Date: 02 Nov, 2012
From: Gumplinger Peter <Gumplinger Peter>

Hi Chris,

> 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,

see StepStatus:

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:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Question: Re: Processing order   (C Mos - 04 Nov, 2012)
1 More: Re: Processing order   (C Mos - 04 Nov, 2012)
1 Feedback: Re: Processing order   (Gumplinger Peter - 05 Nov, 2012)
2 Feedback: Re: Processing order   (Gumplinger Peter - 05 Nov, 2012)
1 Agree: Re: Processing order   (C Mos - 05 Nov, 2012)
2 None: Re: Processing order   (Michael H. Kelsey - 06 Nov, 2012)
 Add Message Add Message
to: "Re: Processing order"

 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 ]