should cropping update the positions of atoms?

[tpchuckles]

suppose i have a 50 unit cell long structure (25 uc of material A, 25 uc of material B). That's a pretty big area though, and i'm just doing HAADF in the middle, so i can crop it to save memory (and not need to compute such a large potential):

trajectory=trajectory.slice_positions( x_range=[18*a,32*a] ) # crops 25|25 into 7|7 unit cells

when i do the full-length ADF, i get a periodic structure, as expected:

probe_xs = np.linspace(0,50*a,16*8,endpoint=False)

but what i did not expect was to find my interface still at 25*a. in other words, we cropped the system, but atom positions are still referenced to the original origin of the system, not the new origin of the system. is this weird?

this is more apparent if I try to do HAADF over a smaller region, e.g. a 4|4 unit cell length area, i need to choose coordinates centered on the original system:

probe_xs = np.linspace(21*a,29*a,16*8,endpoint=False)

and NOT coordinates centered on the new system:

probe_xs = np.linspace(3*a,11*a,16*8,endpoint=False)

i don't know if this is surprising behavior to anyone else?

[tpchuckles]

discussed offline: yes, we think this should be expected behavior.

• The user who is, for example, opening their MD results in ovito or some other tool might actually be confused to find their features at different coordinates (my interface is at 136 in the second figure above, so it's good our ADF plot shows that!)
• Needing to remember to adjust the positions (if we were to change the origin, or subtract off x1,y1,z1 from all atomic positions) is confusing.
• We don't consider crop_positions to be changing the system, but rather, selecting a smaller region of the whole (so further selecting within that down-sized region should be done using the original coordinate system).

[tpchuckles]

I wanted to re-open this discussion PR #97 changed the functionality, in disagreement with the conclusions from this issue and discussion.

So what should the behavior be, and how do we resolve possible discrepancies between real and expected behavior?

Another use case: I am currently attempting to generate giant-FOV HAADF simulations, which i do by chunking the system, running for a subset of probe positions across a sliced trajectory for each chunk. With the new changes in behavior, my old code broke, because if the system is shifted to zero, then i also need to shift my probe positions to zero.

I think there are valid use cases for both, and "annoying extra steps" to get the behavior you want if your use case doesn't match whatever is implemented. So maybe slice_positions could simply have a flag "reset_coordinate_system=True" would do the shifting Paul and Claude think we should do, and reset_coordinate_system=False would avoid the shift?

[tpchuckles]

addressed by commits 880628c and dc665ad
testing now, will close once my batched giant-FOV test is finished.