The option to rotate sample in the *xy*-plane does likely not work correctly

[mondracek]

• There is an option --rotate available in ppafm/cli/relaxed_scan.py (or for the ppafm-relaxed-scan command). The option is described as "Rotates sampling in xy-plane". As I am working on Suggest cleanup of geometry handling in the CPU version #198, I was checking the order of indices for arrays that represent the force field components. The index order used to implement the rotation seems to be inconsistent with the index order elsewhere. For example, the line
  ff_vdw[0, :, :, :], ff_vdw[1, :, :, :] = rotate_ff(ff_vdw[0, :, :, :], ff_vdw[1, :, :, :], opt_dict["rotate"])
  in ppafm/cli/relaxed_scan.py suggests that the first index distinguishes the vector components of the field, but the vector field has been loaded by the io.load_vec_field function a line before and this function, as far as I know, returns the data field in an arrangement in which the vector component is defined by the last index, not the first one.

• I tried to verify my suspicion that there is an error by running the examples/Graphene example with ppafm-relaxed-scan -k 0.5 -q -0.05 --rotate 3.14159265 (which should correspond to 180 degree rotation) and comparing the resulting examples/Graphene/Q-0.05K0.50/OutFz.xsf file with the original file obtained without the -rotate option. The problem is, I am not sure I understand what exactly is the rotation supposed to do. However, I would expect something like the data in the OutFz.xsf file being flipped or rotated in some way but otherwise the same. This is not really what I have seen when I looked at both versions of the OutFz.xsf with the Vesta viewer. So I think my suspicion is confirmed.

• The problem could likely be fixed just by flipping the array indices in those lines of relaxed_scan.py which call rotate_ff. I will test later whether that really helps. Also, I suspect nobody is actually using this feature, which is why the problem has not been notices earlier. Nevertheless, I have to admit I am rather happy for finding this bug, as it stresses the importance of doing what I propose in Suggest cleanup of geometry handling in the CPU version #198. Now it is not purely about making the code look nicer, there seems to be something really wrong in the present form of the code.

[mondracek]

Now I have verified that indeed, just changing the index order for force-filed arrays in ppafm/cli/relaxed_scan.py resolves the issue. I have created a new branch rotate where the issue is fixed this way in the code, but I am intentionally not creating a PR yet. I would prefer to fix this along with a thorough redefinition of array indexing throughout the code so that it is consistent everywhere, as discussed under #198. If someone urgently needs to fix this issue (I doubt so), you can create a PR to merge the rotate branch, I will approve it.

[mondracek]

Note: I have merged the rotate branch into a reverse branch and subsequently deleted rotate as a separate branch. The reverse branch is intended to address the issue of index order, as discussed in #198 and merging it now would also resolve this issue #346.