FieldManager::ConfigureForTrack() not called before first step of new track

Particles, Track, Event, Run and Biasing
1

Geant4 Version: 11.4.1 and 10.07.p04
Operating System: various
Compiler/Version: various
CMake Version: various

When a new charged track is started immediately after another one, FieldManager::ConfigureForTrack() is not invoked before the first integration step. In practice, it is only called starting from step 1, meaning that during step 0 the equation-of-motion object still contains cached state information from the previous track (e.g. charge, mass, etc.).

As a result, with a custom equation-of-motion class, the wrong kinematics are calculated for step 0 of successive tracks.

2

Can you share a small reproducer for this issue?

Also, can you say if your setup uses parallel worlds, scoring worlds, biasing worlds, or anything else that may enable G4CoupledTransportation / G4PathFinder?

I ask because I could not reproduce it in a simple single world test, but I do see a similar effect in a parallel-world / coupled-transportation path.

3

We are using G4CoupledTransportation. Here is the printout for track 2 :

G4WT0 > *********************************************************************************************************
G4WT0 > * G4Track Information:   Particle = G4CMPDriftElectron,   Track ID = 2,   Parent ID = 0
G4WT0 > *********************************************************************************************************
G4WT0 >
G4WT0 > Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
G4WT0 >     0        0        0        0  1.58e-06        0        0         0         Zip initStep
G4WT0 > EqofMotion cached track informations. Charge : -1 and mass : 0.00250171
G4WT0 > G4CMPFieldManager::ConfigureForTrack 2/1 @ (0,0,0) in Zip
G4WT0 >     1 3.32e-10 1.75e-10 -9.27e-10  1.58e-06        0    1e-09     1e-09         Zip G4CMPTimeStepper
G4WT0 > G4CMPFieldManager::ConfigureForTrack 2/2 @ (3.31660821794253e-10,1.748784338933015e-10,-9.270483442872799e-10) in Zip
G4WT0 > EqofMotion cached track informations. Charge : -1 and mass : 0.002501705703392355
G4WT0 >     2 3.76e-06 1.98e-06 -1.05e-05  1.57e-06        0 1.13e-05  1.13e-05         Zip G4CMPLukeScattering
G4WT0 > G4CMPFieldManager::ConfigureForTrack 2/3 @ (3.75921682526529e-06,1.982163592457108e-06,-1.050764796038287e-05) in Zip
  1. Notice that EqOfMotion gets called (multiple times, duplicates suppressed) after Step #0 is completed, but beforeConfigureForTrack() is called for Step #1.
  2. How do the correct mass and charge get passed into EqOfMotion without ConfigureForTrack() being called?

And note that our field manager has ConfigureForTrack() which acquires and caches additional track information, which is not being done for the calls to EqOfMotion before Step #1.

4

Thanks. I can reproduce this too…

I see the same problem in a G4CoupledTransportation-G4PathFinder setup. G4PathFinder can use the field before ConfigureForTrack() is called for the current track,step.

This explains why charge and mass can still look correct: they are passed separately through G4Track → G4FieldTrack → SetChargeMomentumMass(). But any extra track data prepared only in ConfigureForTrack() can be missing or stale on the first field call.

This looks like a real Geant4 bug.

Could you please open an official geant4 bugzilla issue?

5

Thank you! I have created bugzilla 2732 : 2732 – FieldManager::ConfigureForTrack() not called before first step of new track

6

Thank you very much, Dmitri! This has been causing us problems with our G4CMP (solid state physics) library. We use ConfigureForTrack() in order to set some of the peculiar conduction-band parameters (like electron valleys).

In the full CDMS simulation framework, we have the parallel-world + field geometry that you’ve seen before, which triggers G4CoupledTransportation. Thank you also for explaining that there is a separate path to get charge/mass/momentum set in EqEMField. That was really confusing me.