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

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

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

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
32/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
领域
data

调研方向

首先检查 MARI 源文件 instrument_components.nxs 以及链接的 ISISICP pull request 39,然后将列出的 MARI 数据集与现有的 ESS-filewriter 风格 nexus 布局进行比较。当 aperture、fermi、moderator、source 和 geometry 信息的要求及一套达成共识的灵活布局完成文档化后,此 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. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

ISISComputingGroup/DataStreaming 的其他 Issue

查看 ISISComputingGroup/DataStreaming 的全部 Issue

相似的 Issue

更多 Data Engineering Issue

把新 issue 发到你的邮箱

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