Closed aoeftiger closed 4 years ago
Thank you for reporting this issue and for providing a minimal example for reproducing the problem!
The problem was a combination of a missing initial-state check in the track_line
method and an overly enthusiastic global aperture check, happily re-labeling already lost particles if they meet the global aperture criteria.
Note, that the problem is most likely also affecting other backends (i.e. CPU and OpenCL track jobs). However, since the main use-case for track_line
is currently the deep integeration with other cuda libraries, this has not been found earlier.
Excellent job, @martinschwinzerl ! https://github.com/SixTrack/sixtracklib/pull/129 solves the mystery!
When tracking only part of a beam line -- step-by-step with
cudatrackjob.track_line
-- and losing particles in an aperture, they will be "revived" after starting the next turn: theirstate
variable was 0 after the end of the turn, but a nexttrack_line
will set them back tostate=1
.Perhaps I'm not using the SixTrackLib python API correctly, but the attached example should demonstrate just what I mean:
reproducing.ipynb.zip reproducing.py.zip