MARI nexus files contain a different set of datasets than other neutron instruments.
These 'special' nexus files are not needed for HRPD-X or SANDALS-2, but I'd like to take these requirements into account when designing the filewriter to ease future implementation when we need to move MARI to datastreaming at some point in the future.
This mechanism appears to correspond to https://github.com/ISISNeutronMuon/ISISICP/pull/39 so @mducle may be able to comment on the underlying need. The nexus file this information is copied from is \\ndxmari\c$\Data\instrument_components.nxs.
On MARI specifically, this causes various information to get added to the generated .nxs for each run:
instrument/apertureinstrument/fermi exists and contains metadata from the fermi chopper including rotation speed, slit parameters, etc.instrument/moderator contains more information than other beamlines: it contains a pulse shape distribution, moderator type, temperature, transforms.instrument/source contains different information compared to a regular nexus file, including frequency and target_material but excluding probe- Various geometry information is added, in a similar way to what was previously possible with
detector.dat. My understanding is that MARI do actually use this geometry information in preference to the Mantid IDF.
Questions
- Would an ESS-filewriter style 'nexus layout' structure be sufficiently flexible to cater for this need - I think it should be? But it might tie us into a more complicated architecture than we might otherwise need...
Note that MARI is not on any near-term datastreaming list that I've seen, so we can indefinitely defer actually implementing this functionality. This issue exists primarily for requirements-gathering.
MARI nexus files contain a different set of datasets than other neutron instruments.
These 'special' nexus files are not needed for HRPD-X or SANDALS-2, but I'd like to take these requirements into account when designing the filewriter to ease future implementation when we need to move MARI to datastreaming at some point in the future.
This mechanism appears to correspond to https://github.com/ISISNeutronMuon/ISISICP/pull/39 so @mducle may be able to comment on the underlying need. The nexus file this information is copied from is
\\ndxmari\c$\Data\instrument_components.nxs.On MARI specifically, this causes various information to get added to the generated
.nxsfor each run:instrument/apertureinstrument/fermiexists and contains metadata from the fermi chopper including rotation speed, slit parameters, etc.instrument/moderatorcontains more information than other beamlines: it contains a pulse shape distribution, moderator type, temperature, transforms.instrument/sourcecontains different information compared to a regular nexus file, includingfrequencyandtarget_materialbut excludingprobedetector.dat. My understanding is that MARI do actually use this geometry information in preference to the Mantid IDF.Questions
Note that MARI is not on any near-term datastreaming list that I've seen, so we can indefinitely defer actually implementing this functionality. This issue exists primarily for requirements-gathering.