The Idea of Automated Fitting

[EmsArnold]

Currently GDA provides automated fitting for 1D datasets, and serves results to users to act upon. This is incredibly useful for alignment scans. It fits multiple options (see the image below, from left to right):

1. One Gaussian to a scan: Used for aligning to the centre of something vaguely guassian shaped, here an imperfect top-hat. This can be used for determining the centre position of any multitude of objects.
2. One Gaussian to the 1st derivative of a scan: Usually used for aligning to a knife edge scan, for example finding the edge of a slit or any other object with a hard edge.
3. Two Gaussians to the 1st derivative of a scan: Usually used to find the middle of two edges something vaguely top-hat shaped. This can be used for aligning a number of things which have an inconsistent intensity across (a heterogeneous sample for instance), but have clear edges.

The current use of this feature is by doing a scan, then requesting to move to a particular position:

rscan my_motor -5 5 1 my_detector
go peak

This is particularly useful for more complex (automated) fitting routines which are in regular use around the ring. Need to align your slits? That's a relatively stable process which takes 15 minutes, but you don't need there to be making the decisions about where your slit edge sits. You just need reliable fitting which your plan can act on.

There is a potential solution in bluesky, but currently I believe this implementation has drawbacks:

1. It seems you can only fit one model at a time - not ideal if we're not sure if fit 1 or fit 3 will work better for us (usually this distinction is made by eye and by asking the question "Is my signal Gaussian enough for that Gaussian fit?")
2. As far as I can tell, you need to provide a model and initial guess before you collect your signal (when you subscribe before the scan). I've found that even relatively good guesses for a perfect Gaussian (accurate position and sigma, but inaccurate intensities) will fail to find a fit completely. Not ideal for a generic scan when I may have decades of intensity differences across different detectors.

Perhaps this is a candidate for use with the new live-processing service, perhaps @RJCD-Diamond could comment on this?

Acceptance Criteria

• There is a mechanism for automated alignment which allows users to action future plans based on these fitting results.
• This mechanism is centrally available so at least the most-used fitting procedures don't need to be defined at each instrument.

[RJCD-Diamond]

like this? This is sample centring on i15-1. It fits N peaks (gaussian, lorentzian, top-hat etc), a background and then returns the sample centre to bluesky. The plot shows the data, the fit, the obs-calc and any markers. The marker in this case indicate where we decide the sample centre is.

A POST request is sent from bluesky to heliotrapi, and then heliotrapi pushes the fit to xrpddatavis

This is currently executing whatever functions I have in xrpd-toolbox, but if this was to become a general solution we'd need a list of a bunch of simple fitting functions that all beamlines would want, eg fit a gaussian, fit N lorentzians, which could then become part of the base heliotrapi install (or whatever solution we come up with)

This is all automated, if we are to have some more control over the input parameter and give that to a user, then we'd need proper auth. So some work is required

[RJCD-Diamond]

This mechanism is centrally available so at least the most-used fitting procedures don't need to be defined at each instrument.

Think it should be a central solution, central adopted deployable service but should be have one deployed per beamline.

This feels more data-analysis than daq, because it would be useful to have it be extensible beyond simple fitting procedures, but also this is very interlinked with bluesky and bluesky needs to know the results to make its next move, so we need both teams working on this IMO