Closed amandalund closed 1 year ago
What is the track position and direction at this crash?
All these failed cases with the number of iterations (nit
) above the default FieldDriverOptions::max_nsteps (100)
happen when the energy of the input particle is very small, O(eV)
, with a relatively large step length,O(mm)
- so one good step (to advance) within the given relative tolerance is limited by a small delta step, O(0.01mm)
, equivalently requires many sub-steps to integrate along the given step length. See
nit | step (cm) | energy (MeV) |
---|---|---|
311 | 0.0930969 | 3.35963e-07 |
124 | 0.0315987 | 3.35963e-07 |
109 | 0.0273674 | 3.35963e-07 |
108 | 0.0270646 | 3.35963e-07 |
312 | 0.0937436 | 3.35963e-07 |
133 | 0.0342916 | 3.35963e-07 |
307 | 0.0938099 | 3.48505e-07 |
148 | 0.0393166 | 3.48505e-07 |
259 | 0.0944304 | 5.31415e-07 |
159 | 0.0528794 | 5.31415e-07 |
234 | 0.0946951 | 6.81869e-07 |
174 | 0.0951561 | 1.35744e-06 |
139 | 0.0953275 | 2.26955e-06 |
116 | 0.0953957 | 3.41271e-06 |
112 | 0.0954019 | 3.63209e-06 |
So, the question is why these charged particles with very small energy are still survived from the previous step as a particle with energy below eloss_calc_limit (1keV
) deposits all its energy locally and should be stopped.
Right now that cutoff is applied before the energy loss, so it's possible to end up with charged particles with very small post-step energies.
This energy cutoff will probably fix issue #616 as well.
So, how do we treat the case that the calculated mean energy loss is very close to the particle energy? - which should matter not only to avoid very small particle energy (to be self-consistent in conjunction with the use of the eloss_cal_limit which serves as a rough approximated limit for the fidelity of the eloss calculation), but also to apply the fluctuation of eloss in a meaningful way.
Propose to close this issue with a summary of investigation and potential solutions or optimizations:
@whokion Excellent discussion points. Perhaps to close this out: were you able to replicate the assertion failure in a unit test? If so, let's do two little tests: one with nsteps
cranked up arbitrarily high and test the post-step position and momentum. Then let's remove the assertion and reduce nsteps
to a smaller value, and compare the positional error. Or we could also make this a test in the propagator where we do a bunch of propagations until some path length is reached, and compare the accumulated position/momentum error there.
I think removing the assertion is the expedient solution, but later we'll definitely want some sort of tracking cut to prevent this from occurring in the first place.
Failure:
Regression problem:
cms2018+field+msc-vecgeom-gpu
JSON input
Diagnosis:
max_nsteps = 100
in the field driver is not always sufficient: occasionally 2-3x more iterations are required to converge (e.g. 311, 124, 109, 108, 312, 133, 307, 148, 259, 159, 234, 174, 139, 116, 112, ...).Note:
After increasing
max_nsteps
, the problem crashes with a Warp Out-of-range Address error.Backtrace