[Halld-offline] diagnosis and fix

[Richard Jones]

[posted from git issues to mailing list so it does not disappear after
issue is resolved]

Here is a detailed description of the bug, and the fix that eliminates it.
You have to know something about the classes that are responsible for
tracking in G4 to fully appreciate what is going on, but here it is in a
nutshell. At the start of a new track, or the resumption of a suspended
track, G4CoupledTransportation is supposed to clear the internal state of
the G4PropagatorInField. However, this statement is bypassed in the case of
the GlueX geometry because it is conditioned by if (fGlobalFieldExists)
which is false for our geometry. GlueX has multiple magnetic fields
(solenoid, pair spectrometer, sweeps) which are handled separately rather
than as a single global field map. Because of this, the tracking of
neutrals would fail in the following scenario.

   1. A charged particle stuck in some corner of a calorimeter block
   triggers the infinite loop catching condition (fTrackIsLooping) in
   G4PropagatorInField, resulting in StopAndKill being generated for that
   track.
   2. The next particle is dequeued for tracking, and it happens to be
   neutral, so G4PropagatorInField::ComputeStep is not called for this track,
   and so the fTrackIsLooping remains set.
   3. G4PropagatorInField::ClearPropagatorState is normalled called at the
   start of each track, but only if fGlobalFieldExists is true. This
   fGlobalFieldExists is not true for the GlueX geometry because we have
   multiple field maps, eg. Solenoid, pair spectrometer, sweep magnets, etc.
   As a result, in our geometry the fTrackIsLooping condition persists until
   the next charged particle shows up to be tracked.
   4. The AlongStepGetPhysicalInteractionLength method of the main track
   following class G4CoupledTransportation does a StopAndKill on any track
   whenever the G4PropagatorInField reports that fTrackIsLooping==true,
   regardless of whether it is charged or not.

The upshot of all this is that all neutrals that come up after a charged
particle is killed off (for looping too long) get dropped. This continues
until the next charged particle shows up for tracking. This is normally not
too bad because the looping condition hardly ever happens (once per few 10k
events or so) and even when it does, if there are charged particles still
on the stack to be tracked, the condition will be reset as soon as the
in-field propagation causes G4PropagateInField::ComputeStep to be called,
which resets fTrackIsLooping at the start of each step. *BUT* if that stuck
looping particle happened to be the last one in an event, and the next
event has only neutral primaries in it (eg. gammas from the particle gun)
then all of the tracking will do StopAndKill on the first step for ALL
REMAINING EVENTS in the simulation!!!

The fix was simple: remove the if (fGlobalFieldExists condition around the
ClearPropagatorState at the start of each new track. When starting a new
track, when would you ever want the state of the previous track to be
remembered? I also apply the same fix to G4Transportation where the same
pathology also appears. Although it does not seem to affect our hdgeant4
sims at present, it may in the future.


-Richard Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20190303/bf0c4fa7/attachment.html>