ISISComputingGroup / ISISComputingGroup/DataStreaming
`filewriter`: `selog/EPICS_PUTLOG`
- 主要語言
- 沒有語言資料
- 星號
- 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