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.
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. 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
Potential differences from existing files
None known at this time.
The file-writing infrastructure must be able to write out histogram-mode data (
.nxsfiles without anNXevent_datagroup).This refers to the NeXuS groups under
raw_data_1/detector_1.The issue is intentionally phrased as
because this does not necessarily have to be done in the same process as the event-mode filewriter.
Questions
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..nxs.Approaches
.nxsfile and outputs a histogram-mode.nxsfilePotential differences from existing files
None known at this time.