Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

`filewriter`: copy information from `instrument_components.nxs`

オープン
#106 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
32/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
領域
data

調査の方向性

まず MARI のソースファイル instrument_components.nxs と、リンクされている ISISICP pull request 39 を調査し、次に、一覧にある MARI データセットを既存の ESS-filewriter 形式の nexus レイアウトと比較します。要件と、アパーチャ、Fermi、モデレーター、ソース、ジオメトリの情報に対応する合意済みの柔軟なレイアウトが文書化された時点で、この issue は完了です。実装は明示的に延期します。

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

説明

filewriter

MARI nexus files contain a different set of datasets than other neutron instruments.

These 'special' nexus files are not needed for HRPD-X or SANDALS-2, but I'd like to take these requirements into account when designing the filewriter to ease future implementation when we need to move MARI to datastreaming at some point in the future.

This mechanism appears to correspond to https://github.com/ISISNeutronMuon/ISISICP/pull/39 so @mducle may be able to comment on the underlying need. The nexus file this information is copied from is \\ndxmari\c$\Data\instrument_components.nxs.

On MARI specifically, this causes various information to get added to the generated .nxs for each run:

  • instrument/aperture
  • instrument/fermi exists and contains metadata from the fermi chopper including rotation speed, slit parameters, etc.
  • instrument/moderator contains more information than other beamlines: it contains a pulse shape distribution, moderator type, temperature, transforms.
  • instrument/source contains different information compared to a regular nexus file, including frequency and target_material but excluding probe
  • Various geometry information is added, in a similar way to what was previously possible with detector.dat. My understanding is that MARI do actually use this geometry information in preference to the Mantid IDF.

Questions

  • Would an ESS-filewriter style 'nexus layout' structure be sufficiently flexible to cater for this need - I think it should be? But it might tie us into a more complicated architecture than we might otherwise need...

Note that MARI is not on any near-term datastreaming list that I've seen, so we can indefinitely defer actually implementing this functionality. This issue exists primarily for requirements-gathering.

主要言語
言語のデータがありません
スター
0
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

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

ISISComputingGroup/DataStreaming のほかの issue

ISISComputingGroup/DataStreaming の issue をすべて見る

似ている issue

Data Engineering の issue をもっと見る

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

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