Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

The Idea of Automated Fitting

未关闭
#1,676 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
45/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
python
领域
backend, data

调研方向

Start by reading the Bluesky callbacks documentation linked in the issue and reviewing the existing rscan and go peak workflow shown there. Define how multiple fitting options and post-scan results would support future plans, then verify that the mechanism is centrally available and satisfies both acceptance criteria.

由索引模型根据 Issue 内容生成。

描述

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.
Image

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.
主要语言
Python
星标
13
派生
14
平均合并
7 天 1 小时
30 天内合并 PR
12

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

DiamondLightSource/blueapi 的其他 Issue

查看 DiamondLightSource/blueapi 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。