Repository navigation
filewriter: copy information from instrument_components.nxs #106
Description
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/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 excludingprobe- 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.
Activity
[-]`filewriter`: MARI specials[/-][+]`filewriter`: MARI special files (copy information from `instrument_components.nxs`)[/+][-]`filewriter`: MARI special files (copy information from `instrument_components.nxs`)[/-][+]`filewriter`: copy information from `instrument_components.nxs`[/+]mattclarke commentedon Aug 28, 2026
The ESS filewriter should be able to handle this.
mducle commentedon Oct 15, 2026
So this information was included for use in Horace for instrument resolution calculations when modelling data. There's a package eniius which is used to write the
instrument_component.nxsfile using Python /h5py/nexusformatwhich is then copied byisisicpinto the raw file. It's a bit cumbersome because I didn't want to write a lot of new C code inisisicpto do this (way before Claude!) so if this can be done with the ESS filewriter that would be really good.Greg Tucker from ESS was also interested in this and has taken it a bit further. The idea with both projects is to facilitate conversions between instrument definitions in a NeXus file and a McStas
.instrsince there's not quite a one-to-one mapping between components in the two, soeniiusmakes a list of explicitly convertable components which can handle most instruments (I think - I only needed it for the inelastic spectrometers and haven't tested it on anything else). Because of additional metadata (parameters) required by the McStas components, a conversion from a barebones NeXus -> McStas usually doesn't work since NeXus doesn't require any parameters to be specified. But McStas -> NeXus -> McStas works and NeXus -> McStas -> NeXus will also give you back the NeXus description even if the McStas.instrfile generated will error when running McStas.Tom-Willemsen commentedon Oct 15, 2026
@mducle - can you stick a meeting in my calendar to discuss some details of this?
We've chosen to go with a greenfield filewriter design, which should be quite flexible in terms of adding 'extra' information, but I'd like to discuss more about exactly the best ways to get this information to and from the nexus file.
RichardWaiteSTFC commentedon Oct 15, 2026
As discussed offline with @mducle - resolution convoluted fitting is also planned to be implemented in Mantid, so it is not just Horace that will require this additional instrument geometry information in the future. Though it appears to be present in the files I'm not sure it is currently used in Mantid yet - I find no mention of anything here (other than source frequency) in
https://github.com/mantidproject/mantid/blob/91d24dfaf4404fa13f3266c7c12dc066b2a537dc/docs/source/algorithms/LoadISISNexus-v2.rst#L4