Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
#83 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Calme

Piste de recherche

Commencez par le point d’entrée de filewriter et comparez sa sortie actuelle avec le groupe NXevent_data sous raw_data_1/detector_1_events. Examinez le comportement de event_aggregator et clarifiez les questions concernant event_time_bins, l’ordre des temps de référence, l’ordre des événements et les indicateurs de veto. Le travail est terminé lorsque le format requis de fichier d’événements en streaming et les règles de traitement sont convenus et implémentés.

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

Description

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.
Langage dominant
Aucune donnée de langage
Étoiles
0
Forks
0
Métriques de merge des PR
Aucune PR mergée en 30 j

Guide de contribution

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

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ISISComputingGroup/DataStreaming

Toutes les issues de ISISComputingGroup/DataStreaming

Issues similaires

Plus d'issues Data Engineering

Recevez les nouvelles issues par e-mail

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