Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
#83 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig

Rechercherichtung

Beginne am filewriter-Einstiegspunkt und vergleiche seine bestehende Ausgabe mit der NXevent_data-Gruppe unter raw_data_1/detector_1_events. Lies das Verhalten von event_aggregator und kläre die Fragen zu event_time_bins, der Reihenfolge der Referenzzeit, der Ereignisreihenfolge und den Veto-Flags. Als erledigt gilt die Aufgabe, wenn das erforderliche Streaming-Ereignisdateiformat und die Regeln für die Verarbeitung vereinbart und implementiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.
Vorherrschende Sprache
Keine Sprachdaten
Sterne
0
Forks
0
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus ISISComputingGroup/DataStreaming

Alle Issues in ISISComputingGroup/DataStreaming

Ähnliche Issues

Weitere Issues zu Data Engineering

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.