I have an application where we track low energy electrons and holes in a solid. The tracks are created with initial energy of order 1 eV, and we have the appropriate G4EqMagElectricField subclass to define the momentum change (drift electrons follow valleys in the solid lattice, which the code implements).
The problem I’m having at the moment, with just one track out of many, is that it appears to get stopped during transport, and the job spews an infinite number of G4ChordFinder “GeomField0003” warning messages:
-------- WWWW ------- G4Exception-START -------- WWWW -------
*** G4Exception : GeomField0003
issued by : G4ChordFinder::FindNextChord()
Exceeded maximum number of trials= 75
Current sagita dist= nan
Step sizes (actual and proposed):
Last trial = 4.29198e-80
Next trial = 4.29198e-81
Proposed for chord = 8.58397e-80
*** This is just a warning message. ***
-------- WWWW -------- G4Exception-END --------- WWWW -------
I ran in the debugger (LLDB on a MacBook), and found that the track was created with 0.16 eV of kinetic energy, and at this error, during the second step of the trajectory, the track’s fDynamicParticle reported zero kinetic energy.
I know that G4 does not like having particles get stopped and turned around in an electric field (I remember several old Hypernews postings about it). Is there something relatively safe and robust I could do in our own code, e.g., in the equation of motion, to protect against this? Alternatively, we are using 10.03.p03 as our base G4 version; is this an issue that’s been fixed in 10.4 or 10.5?
Hi Mike,
Did you create a workaround - or is this still a ‘live’ issue?
From my reading of the values, it seems that the particle is simply moving far too little, making the sagita NaN and never progressing. I think that there are small improvements in 10.4 or 10.5, but it is difficult to say if they will make any difference.
It would be best to understand how/why the step size has decayed this much.
It may be that using a different equation of motion is needed for this - one in which the independent variable is time, not the length of the step along the track. This seems to be the approach with most promise for particles stopping in an electric field.
Hi, John. I should have followed up with this. Yes, I did solve the problem, which turned out to involve the assigned particle mass. After stepping through things in the debugger, I discovered the following:
The charged particle being tracked reported its fDynamicParticle mass was zero. It should have been more like 0.12 * mElectron.
In our code, because we’re dealing with solid-state stuff, we use masses in “kg-like” units (so MeV/c^2, not MeV), and we carry around a full 2D mass tensor. We don’t use the G4Track or G4DynamicParticle scalar mass values directly.
I found that at some point in our code, the kg-like mass was passed into G4DynamicParticle.
In my jobs built against 10.3.3, I had the problem described above. When I linked and ran against 10.5.1, I got an FPE error because G4DynamicParticle actually reset the (bad) input mass to zero, as it failed the EnergyMomentumRelationAllowance test.
When I fixed the latter problem, by properly passing the new track’s mass in “MeV-like” units (our mass * c_squared), both the FPE error and the G4ChordFinder problem went away, and hasn’t returned.