Symptom: gammas (possibly other neutrals) get StopAndKill from G4CoupledTransportation::AlongStepGetPhysicalInteractionLength during the first tracking step, for no apparent reason. This continues within this thread until the next charged particle comes up for tracking.

Conditions: the previously tracked particle in this thread before this symptom occurs was a charged particle which was abandoned due to fParticleIsLooping being set to true in the G4PropagatorInField.

Special circumstances: our simulation has fGlobalFieldExists set to false because we have several different spectrometers in the setup, and all of our fields are local to particular subregions of the geometry.

Suggested fix #1 (G4CoupledTransportation.cc)
$ diff G4CoupledTransportation.cc-orig G4CoupledTransportati
on.cc
947c947
<   if( fGlobalFieldExists )
---
>   if( fFieldPropagator )

Suggested fix #2 (G4Transportation.cc)
$ diff G4Transportation.cc-orig G4Transportation.cc
791c791
<   if( DoesGlobalFieldExist() )
---
>   if( fFieldPropagator )

Detailed discussion:
Here is a detailed description of the bug. 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.

A charged particle stuck in some corner of a calorimeter block triggers the infinite loop catching condition (fParticleIsLooping) in G4PropagatorInField, resulting in StopAndKill being generated for that track in G4CoupledTransportation. The next particle is dequeued for tracking, and it happens to be neutral, so G4PropagatorInField::ComputeStep is not called for this track, and the fTrackIsLooping flag remains set.
G4PropagatorInField::ClearPropagatorState is normally 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. 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 the current track 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 aborted at the start of transportation. This continues for all new tracks 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!!! This condition is confined to a single thread, but that thread now chews through new particle gun triggers so fast that virtually none of the other threads have time to simulate their events.

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 the parallel bug in G4Transportation does not seem to affect our hdgeant4 sims at present, it may do so in the future.