Correct array/scan-point index mixup

[dagewa]

Correct instances where an array-index, which might not start from 0, is conflated with a scan-point index, which always starts from zero.

Two of these are in plot generation code. This issue is more pernicious than first thought (#1929) as it is not limited to merely shifting of the X-axis. If there are multiple crystals in the experiment, and these have different scan ranges (possible due to scan-trimming) then the plots themselves are also shifted relative to one another.

Here's an example with two crystals in the same imageset with scans that go from -24.1° to 24.9° and from -35.1° to 22.9°. Previously the orientation plot from dials.plot_scan_varying_model incorrectly showed both scan-varying models starting from -44.1°, which is the result of scan.get_angle_from_array_index(0) from either of the scans.

wrong behaviour on main:

WIth these changes the two scans are correctly displayed as starting at -24.1° and -35.1°.

correct behaviour on branch:

The third instance is in dials.sequence_to_stills, for which Aaron is tagged for review.

[dagewa]

@phyy-nx I am working on some code in a different branch in which the scan-varying model at the start and end of a frame is interpolated to give a crystal model for the frame centre. I think that concept could be introduced in dials.sequence_to_stills too, which I can do outside this PR.

[phyy-nx]

@kmdalton would you or someone in your group like to take a look at this? You use this more than I.

[kmdalton]

@PrinceWalnut, can you look at these modifications to dials.sequence_to_stills and see if they impact your indexing code? (ideally pull this version and run it)

[PrinceWalnut]

@PrinceWalnut, can you look at these modifications to dials.sequence_to_stills and see if they impact your indexing code? (ideally pull this version and run it)

This version works as well as the previous version, which is to say it works for scan-varying crystals but not scan-static crystal models, or for models which have not had shoeboxes assigned yet (particularly those for which force2d=True was set during spotfinding). You can get around the shoebox issue by using the following snippet to select refls for including into the still:

_, _, _, _, z1, z2 = reflections["bbox"].parts()
subrefls = reflections.select((i_scan_point >= z1) & (i_scan_point < z2))

To handle scan-static models, the crystal.get_A_at_scan_point() function needs to either be dropped in favour of manually applying the appropriate rotation matrix to crystal.get_A() or by including that functionality into the function itself and detecting scan-static models to use it then.

EDIT: I have developed a few variants of this script specifically for dealing with scan-static and for multi-beam experiments. Perhaps these should be added as either separate scripts, or into this script with some smart selection depending on arguments?

[PrinceWalnut]

I would suggest approving this request, and I can update my fork and my scripts and form a pull request later with the extra functionality I have. My scripts will also have this array bug, so I need to change them first.

[PrinceWalnut]

@phyy-nx That's all the input I have here. I can pull this fix and add my own for the mentioned issues above if it's useful for you. Otherwise LGTM

[phyy-nx]

Great! And a separate pull request to add those features seems good. Thanks!