Center-of-mass

[Tom-Willemsen]

When doing a continuous scan using the laser/laser diode against sample changer pos on LOQ, we used bluesky's PeakStats callback to get a centre of mass. It returned an implausible result, well outside the actual peak. i.e. for a peak that looked like this:

(scan uid bed72c78-61bc-49c6-98ac-8974162b2e08), we got a centre of mass of 507.4936482348703 - which just visually is clearly badly wrong.

A few things it could have been getting confused by:

• The scan would not have had constant point spacing, was continuous motion so some motor acceleration/deceleration will be present (i.e. points close to edges will be closer together)
• Some of the intensities were negative (range was about -7.5 .. +9)
• The scan was a "there-and-back" scan so x points would be like: -2 -1 0 1 2 1 0 -1 -2

CoM should be able to cope with all of these, but suspect one of the above is not handled well and that's what caused a bad result.

Acceptance criteria

• Investigate, fix upstream if possible, or if upstream won't accept a fix for this then write our own center-of-mass callback.

Planning

10/01/25 - 00:21:30
Discussed 19/12/20224 - agreed to push to next spring

[Tom-Willemsen]

Proposed as CoM is a pretty "core" thing that lots of beamlines will need & it came up in LOQ bluesky testing.