ISISComputingGroup / ISISComputingGroup/DataStreaming

`filewriter`: `runlog/icp_event`

Ouverte
#92 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
filewriter
Langage dominant
Aucune donnée de langage
Étoiles
0
Forks
0
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

The filewriter must be able to write the `runlog/icp_event` group, as parts of this are currently parsed by Mantid.

From discussions, my current understanding is that Mantid:
- _Does_ read `CHANGE_PERIOD` and `CHANGE` events. We will emulate these by looking at the event data stream and emitting a fake `CHANGE_PERIOD` message each time we see incoming data with a different period number.
- _Does_ read `START_COLLECTION`, `STOP_COLLECTION`, `ABORT` messages.
- _Can_ read `BEGIN`, `RESUME`, `END_SE_WAIT`, `PAUSE`, `END`, `ABORT`, `UPDATE`, `START_SE_WAIT` messages, but only if `oldStyle` is being used.
- _Does not_ parse the numbers from `GF x RF x GUAH x` messages.

## Potential differences from existing files

- Proposal is to only write the `newStyle` commands, so `START_COLLECTION`, `STOP_COLLECTION`, `CHANGE`, `CHANGE_PERIOD`, `ABORT`.
- All data will be emulated (derived from the underlying event data):
* `START_COLLECTION` written at the beginning, and then on any transition from a bad frame to a good frame.
* `STOP_COLLECTION` written on any transition from a good frame to a bad frame, and then at the end.
* `ABORT` - not convinced this is meaningful, if the run is aborted then won't get a `.nxs` file at all...
* `CHANGE_PERIOD` will be written any time we get a frame which has a different period than the most-recently-seen frame
- `CHANGE_PERIOD` will account for hardware periods as well as software periods (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of `CHANGE_PERIOD` events than previously.
- `START_COLLECTION` and `STOP_COLLECTION` will account for hardware vetos as well as pause/runcontrol (they look the same to the filewriter in the streaming system). This means that there could be a much higher frequency of `START_COLLECTION` and `STOP_COLLECTION` events than previously.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

Start by tracing how the filewriter consumes the underlying event data stream and how it currently writes runlog groups. Compare the proposed newStyle commands with Mantid's stated parsing behavior, then verify that START_COLLECTION, STOP_COLLECTION, CHANGE, and CHANGE_PERIOD reflect good/bad frame and period transitions; resolve whether ABORT belongs before considering the work done.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Domaine
data-engineering, stream-processing
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
42/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.