ODIN run files: WFM disc translation applies the full separation readback to each disc (discuss with file producers)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
Hướng nghiên cứu
Start with the WFM positioner layout and the stated readback and vector behavior in this issue, then review the NeXus structure file coda_odin_999999_00028003.hdf and the related discussion in #833. The issue needs input from the file producers on whether per-disc readbacks will be available or how one shared positioner should represent half-readback scaling; done means agreeing on a structure that avoids incorrect positions and duplicate PV streams.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Split out of #833, which is resolved for all other instruments by the 2026-11-03 run files. Points to discuss with the producers of the NeXus structure files (ECDC).
Current layout
coda_odin_999999_00028003.hdf (2026-11-03). Each WFM disc has its own positioner. Both positioners record the same stage motor, as separate datasets:
/entry/instrument/wfm1_translation NXpositioner
value NXlog @source='ODIN-ChpLin:MC-LinX-01:Mtr.RBV' @topic='odin_motion'
@vector=[0, 0, 1] @depends_on='.' units: mm
target_value NXlog @source='ODIN-ChpLin:MC-LinX-01:Mtr.VAL'
idle_flag NXlog @source='ODIN-ChpLin:MC-LinX-01:Mtr.DMOV'
/entry/instrument/wfm2_translation NXpositioner
value NXlog @source='ODIN-ChpLin:MC-LinX-01:Mtr.RBV' (same PV)
@vector=[0, 0, -1] @depends_on='.'
target_value, idle_flag: same PVs as wfm1_translation
wfm1: translation = -53.725 m (z) -> wfm1_translation/value
wfm2: translation = -53.275 m (z) -> wfm2_translation/value
moderator at -60.5 m (z)
Both positioners carry this description:
The readback is the change in WFM disc separation from the widest position; each disc moves by only half of it, but the transformation applies the full value. Both WFM positioners read the same stage motor until each disc has its own PV.
Problems
- Magnitude. At readback 0 the discs are 0.45 m apart. The opposite vectors move them towards each other, which fits a readback that measures the change in separation. Each chain applies the full readback, so the computed separation changes by twice the readback. The WFM chopper positions are wrong whenever the readback is not 0. NeXus asks for a unit-length
@vector, so[0, 0, ±0.5]is not a clean fix. - Two NXlogs for one PV. Each positioner has its own
@vector,@transformation_typeand@depends_on, so the two can drift apart in a later structure-file edit (the risk described in #833). Consumers that map Kafka streams by(topic, source)also see the three PVs twice. For example, esslivedata's stream lookup table would feed only one of the two NXlogs.
Questions for the file producers
- Will the motion control system provide a position readback per disc? With one PV per disc, each positioner would record its own disc's position and both problems disappear.
- If not: should the file have a single
wfmc_translationpositioner, with the half-readback scaling expressed somewhere other than@vector?
- Ngôn ngữ chính
- Python
- Star
- 3
- Fork
- 5
- Merge trung bình
- 2 ngày 19 giờ
- Pull request đã merge (30 ngày)
- 32
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của scipp/ess
-
[essnmx] essmandi-reduce writes entry/instrument/name = "NMX" for MANDI dataCó thể đã có người làm @YooSunYoung đã nhận 55 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[essnmx] Fix typo in NXLauetof application definitionCó thể làm lại được @nightcityblade đã nhận 48 ngày trước và không có pull request nào đang mở. Đang mởessnmx good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
Maintainer thường phản hồi trong vòng 1 ngày
-
essdiffraction
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[essimaging] `maximum_resolution_achievable` should not hardcode "time" as the "third" dimensionCó thể đã có người làm @jokasimr đã nhận 211 ngày trước. Đang mởessimaging
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
Significant-Gravitas/AutoGPT#16733 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
changelog investigate
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 74/100
ramnes/notion-sdk-py#444 ·
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
Judgment-Pack/judgment-pack-spec#299 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
QuantConnect/Documentation#2858 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
btclib-org/btclib#3047 ·
Maintainer thường phản hồi trong vòng 1 ngày