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

`filewriter`: Neutron histogram data (`raw_data_1/detector_1`)

Ouverte
#84 3 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
30/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active

Piste de recherche

L’issue ne nomme aucun fichier ni test ; commencez par localiser le filewriter existant du mode événementiel et la gestion NeXuS pour raw_data_1/detector_1. Clarifiez les combinaisons histogramme/événement prises en charge et les attentes concernant les histogrammes diffusés, puis vérifiez que l’approche retenue produit la sortie .nxs requise en mode histogramme.

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

Description

filewriter

The file-writing infrastructure must be able to write out histogram-mode data (.nxs files without an NXevent_data group).

This refers to the NeXuS groups under raw_data_1/detector_1.

The issue is intentionally phrased as

file-writing infrastructure

because this does not necessarily have to be done in the same process as the event-mode filewriter (though having it in the filewriter would be more performant and potentially more flexible in future).

Questions

  • Support streamed histograms (hs00) at some point in future? i.e. a scheme where a monitor emits a histogram every N frames, where N could be 1 in the extreme case. This then lets a run be sliced a bit like event mode, but only on N-frame boundaries.
    • This might be needed for SANDALS2 if monitor event-rates are too high for pure-event mode.
    • Need to define how we would write this kind of data to .nxs.

Approaches

  • This could be an option in the filewriter process itself (preferred). It would then need various options to cope with:
    • event files only
    • combined histogram+event files
    • separate histogram and event files
  • This could be implemented as a separate process which reads in an event-mode .nxs file and outputs a histogram-mode .nxs file.
    • But that then makes it harder to support all combinations of files we may need to generate, e.g. event-only, histogram-only, event+histogram in the same file, event-detectors with histogram-monitors, etc.
    • This may also have a performance disadvantage as all of the events need to be written by one process, then read back in to another process before histograms can be generated. For large files this file-loading cost may be significant, especially for beamlines that ultimately only care about the histogram files.

Potential differences from existing files

None known at this time.

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 Backend & API Design

Recevez les nouvelles issues par e-mail

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