Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

`filewriter`: Neutron event data (`raw_data_1/detector_1_events`)

Aperta
#83 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla

Direzione di ricerca

Inizia dal punto di ingresso di filewriter e confronta il suo output esistente con il gruppo NXevent_data in raw_data_1/detector_1_events. Leggi il comportamento di event_aggregator e risolvi le questioni relative a event_time_bins, all’ordinamento dei tempi di riferimento, all’ordinamento degli eventi e ai flag di veto. Il lavoro è completato quando il formato richiesto del file di eventi in streaming e le regole di gestione sono concordati e implementati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

filewriter

The filewriter must be able to write out event-mode data.

This means the contents of the NXevent_data group in raw_data_1/detector_1_events

Questions

  • What do we want to do with event_time_bins, which aren't meaningful in streaming system?
  • Due to an underlying UDP connection from hardware, the streaming system cannot guarantee that frame N+1 will have a later reference_time than frame N. Do any consumers make assumptions about this?
    • This affects whether we can stream events to file directly, or whether we have to buffer, sort by reference time, and then write to file
  • Does mantid have a dependency on event time-of-flights being ordered within a frame? Currently this sort is (optionally) done at event_aggregator level as multiple consumers benefit from improved performance with sorted events.

Potential differences from existing files

  • We likely no longer need to apply a random event_time_offset_shift, as the new electronics has a much higher time resolution than the old DAE electronics. See https://github.com/ISISComputingGroup/DataStreaming/issues/22 .
  • We want to be able to write the veto flags for each frame alongside the event data, to enable downstream consumers to retroactively enable or disable a veto if it chooses:
    • active_vetos: the veto signals that were actually active for a given frame
    • enabled_vetos: the vetoes that were enabled in IBEX at the time of data acquisition
    • By default downstream consumers will want to mask any events where active_vetos & enabled_vetos != 0.
    • If adding this logic is problematic for Mantid, we could (optionally) drop the frames at filewriter level instead - at the cost of reducing flexibility and reducing diagnostics we have access to.
Lingua principale
Nessun dato sulla lingua
Stelle
0
Fork
0
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ISISComputingGroup/DataStreaming

Tutte le issue di ISISComputingGroup/DataStreaming

Issue simili

Altre issue su Data Engineering

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.