ODIN run files: WFM disc translation applies the full separation readback to each disc (discuss with file producers)

オープン
  • 何か問題がありますか？
#856 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
活発
技術スタック
python
領域
data

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

  1. 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.
  2. Two NXlogs for one PV. Each positioner has its own @vector, @transformation_type and @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

  1. 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.
  2. If not: should the file have a single wfmc_translation positioner, with the half-readback scaling expressed somewhere other than @vector?
主要言語
Python
スター
3
フォーク
5
平均マージ
2日 19時間
マージ済み PR（30日）
32

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

scipp/ess のほかの issue

scipp/ess の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。