Different tracking results in versions 0.7.1 and 0.7.2

[alberdibenat]

Dear all,

I have been using the attached script to calculate the dynamic aperture of a ring with some kind of Flood Fill algorithm that relies on the track function of pyAT. I have the development version 0.7.2 of pyAT that I have cloned from git, and I get a result of 14.50mm^2 as an output. However, when I tried to cross-check the results in another system with the 0.7.1 version of pyAT, I got 13.93mm^2. This mismatch happened for several different lattices.

I understand that both versions should give the same result when tracking and registering particle losses.

at_track_issue.zip

[oscarxblanco]

Dear @alberdibenat ,
I see your lattice has more than 1900 elements which makes it difficult and slow to verify.
The passmethods are only six:

{'IdentityPass', 'ThinMPolePass', 'DriftPass', 'StrMPoleSymplectic4RadPass', 'BndMPoleSymplectic4RadPass', 'RFCavityPass'}

Could you check for a single element per pass methods which tracking is giving you a different result between versions and report it ? That would be more effective.
You could track a single element as follows:

>>> import numpy as np
>>> zin = np.zeros((6))
>>> ring[0].track(zin)
array([0., 0., 0., 0., 0., 0.])
>>> zin[1] = 10e-6
>>> ring[0].track(zin) # track first element in your ring
array([2.8e-05, 1.0e-05, 0.0e+00, 0.0e+00, 0.0e+00, 1.4e-10])

[oscarxblanco]

One more thing, for pass methods ending in RadPass and the RFCavityPass, you will need to add the energy as argument:

ring[0].track(zin,energy=ring.energy)

(See issue #1015 )

[alberdibenat]

Hi @oscarxblanco,

I have tested the tracking through one element per each of the different passmethods, and I get the same result for both versions of pyAT. However, after a consultation with @TeresiaOlsson, I understand that the difference may come from the registration of the position of the particle losses and acceptance boundaries: 84657e2

[oscarxblanco]

Hi @alberdibenat ,
were you running flood fill in a gpu ? The commit you cite comes from the gpu implementation.

[alberdibenat]

Hi @oscarxblanco ,
No, then it must be something else. I will try to pin the problem down and post again when I find the source of the difference.

[oscarxblanco]

OK, I had a look on your jupyter notebook and if you don't mind having extra suggestions I would do two 2D plots, each with Y vs X and color set by the survival test, black/white for survival or color as a function of the number of turns (this is what I did to check the parallel floodfill you could find here #1011).

On those two plots you expect to see the differences you claim to have between versions. I would then track only those particles again to see more details.

[alberdibenat]

Hello @oscarxblanco ,

I have had a look again and tested the two versions of pyAT with your floodfill algorithm. You can see in the plots that I get substantially different results, mostly at the boundary of the DA. I am still not sure what causes the differences.

The versions I have used for the plots are: 0.7.1 and 0.7.2.dev38+ga22c9b19. I am using a lattice with misalignments and errors. Could it be that those are treated differently in the two versions? I will check the particles at the boundary and try to figure something out.

at_issue_test_FoodFill.py

[TeresiaOlsson]

Ah! Maybe something could have changed with how the errors are handled. Have you tested it also for a lattice without errors?

[alberdibenat]

I have tested it with an ideal lattice, and the results for both versions are much more similar than for the lattice with errors, but there are still small differences in the boundary region.

[oscarxblanco]

@alberdibenat, thank you for using my flood fill implementation. Could you check with a 4D ring and post it again ?
Also, ignore the closed orbit, do not add it. I wonder if the differences in the ideal lattice come from energy offsets.

[alberdibenat]

@oscarxblanco you are right, the results for a 4D ring are identical for both versions and both cases (ideal lattice and lattice with errors).

[oscarxblanco]

That's great to hear, it discards a few pass methods common to 6D and 4D tracking in your lattice ('IdentityPass', 'ThinMPolePass', 'DriftPass',).

The remaining pass methods 'StrMPoleSymplectic4RadPass', 'BndMPoleSymplectic4RadPass', 'RFCavityPass' still need to be checked. My proposal would be to bisect the commits between 7.1 and your 7.2x, then compile and check and repeat until we find it. One could use git bisect, have you ever use it ?

It could be also done by hand, and checking for modifications on those pass methods.

[oscarxblanco]

I had a quick look on the git modifications of 'StrMPoleSymplectic4RadPass.c', 'BndMPoleSymplectic4RadPass.c', 'RFCavityPass.c' using the blame tab and I see no modifications between June the 3rd (release 7.1) and yours.

I guess it must be something on the track function, but, one would go through the commit history bisecting until we could find the difference. There are 55 commits from Jun3/2025 up to now, so, you will need to repeat 6 times the bisecting to get there.

[TeresiaOlsson]

These are the results I get.

Version 0.7.1

17 Aug a6fd964

20 Aug e053163

21 Aug 84657e2

17 Dec a6840dd

I think commit 84657e2 is when the tracking results changed. @JeanLucPons do you perhaps know why this could be?