ISISComputingGroup / ISISComputingGroup/DataStreaming

`filewriter`: `selog/EPICS_PUTLOG`

未关闭
#91 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
filewriter
主要语言
没有语言数据
星标
0
派生
0
PR 合并指标
30 天内没有已合并 PR

描述

The current `.nxs` files contain the EPICS putlog as a string-typed `selog` entry.

The baseline assumption is that the putlog entries will be streamed to a dedicated Kafka topic as a [`vs00`](https://github.com/ess-dmsc/streaming-data-types/blob/master/schemas/vs00_strings.fbs) or similar schema, by some separate process to-be-written.

This requirement is low-priority for the immediate future, but we should still consider supporting it long term.

## Questions

The ISISICP currently writes strings in a way that is not nexus-compliant.
* Do we want to continue to do that?
* There is a new NXtextlog nexus class for storing string-logs: https://github.com/nexusformat/definitions/pull/1590 . But will using that cause problems for Mantid?

## Potential differences from existing files

- Some of the PV names (particularly the DAE PVs) will be different in the datastreaming system, and may not be captured in the CA putlog as they are served over PVA instead. For example if downstream analysis is expecting to be able to parse strings like `Changed PV: IN:SANS2D:DAE:BEGINRUNEX new=0 old=0 ` from this log, then that would no longer be valid.

贡献指南

这个仓库没有索引到贡献指南

调研方向

Start by examining how the current .nxs files represent the string-typed selog EPICS putlog, then compare the proposed vs00 Kafka representation with the NXtextlog Nexus class. Resolve whether the format remains Nexus-compliant and compatible with Mantid, including the listed PV-name differences; done means the long-term storage and streaming approach is decided.

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

评估

技术栈
kafka
领域
data-engineering
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
冷清
描述清晰度
需要澄清
新手友好度
25/100

把新 issue 发到你的邮箱

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