You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
filewriter: Neutron histogram data (raw_data_1/detector_1) #84
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.
ESS is doing something similar, the beam monitors readouts are histogramming the data and then sending it to Kafka.
We are using the very generic da00 schema but I don't think that is the best choice. hs01 or something more specific would be better.
Activity
Tom-Willemsen commentedon Jul 27, 2026
If we did want to do this as a separate process, the following may be relevant:
[-]`filewriter`: Neutron histogram data[/-][+]`filewriter`: Neutron histogram data (`raw_data_1/detector_1`)[/+]mattclarke commentedon Sep 3, 2026
ESS is doing something similar, the beam monitors readouts are histogramming the data and then sending it to Kafka.
We are using the very generic da00 schema but I don't think that is the best choice. hs01 or something more specific would be better.
Tom-Willemsen commentedon Sep 3, 2026
How often are those monitor histograms sent at ESS - once per frame, at a set time/number of frames interval, or only at the end of a run?