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
Mantid currently loads some information from the isis_vms_compat group.
Primarily this is UDET and SPEC, information which doesn't appear elsewhere in the .nxs file, but if the isis_vms_compat group exists at all then mantid apparently needs all of:
A summary of recent findings regarding isis_vms_compat:
SPB, RSPB
Relates to sample geometry.
The code already checks for alternate locations in the standard NeXus locations - the if just needs switching around.
IRPB, RRPB
Relates to run details: proton charge, source frequency.
The code again checks in alternate, more standard, locations - the if just needs switching around.
NSP1, UDET, SPEC
Relates to the spectrum-detector mapping.
The code is a bit misleading as there is a fallback but it only applies to Muon Nexus V2 files and does not work for neutron NeXus files.
This is an area where changes in Mantid and in the structure of the file would be required. Currently detector_1/spectrum_index lists the spectrum numbers but the UDET field has no corresponding entry elsewhere. It looks as if the NeXus component NXdetector can contain a detector_number field that looks suitable for this purpose.
Need to check with other analysis programs e.g. GudRun for SANDALS-2, to what extent they need isis_vms_compat. My understanding is they currently use .raw files but also have ability to use .nxs.
I remember checking with Tristan during the MNeudata requirements gathering and he said:
"Gudrun actually reads both. On SANDALS they use NeXuS files as standard now - on NIMROD we are still in the RAW file era, but there isn't really a reason why we couldn't easily shift to using NeXuS.
From the perspective of MNeuData I would agree and say that RAW files shouldn't be an option, for what it's worth. I have my reservations with HDF5, sure, but I appreciate that RAW is not a sustainable format moving forward."
Activity
martyngigg commentedon Jul 27, 2026
A summary of recent findings regarding
isis_vms_compat:SPB, RSPB
Relates to sample geometry.
The code already checks for alternate locations in the standard NeXus locations - the
ifjust needs switching around.IRPB, RRPB
Relates to run details: proton charge, source frequency.
The code again checks in alternate, more standard, locations - the
ifjust needs switching around.NSP1, UDET, SPEC
Relates to the spectrum-detector mapping.
The code is a bit misleading as there is a fallback but it only applies to Muon Nexus V2 files and does not work for neutron NeXus files.
This is an area where changes in Mantid and in the structure of the file would be required. Currently
detector_1/spectrum_indexlists the spectrum numbers but theUDETfield has no corresponding entry elsewhere. It looks as if the NeXus component NXdetector can contain adetector_numberfield that looks suitable for this purpose.Tom-Willemsen commentedon Jul 27, 2026
Need to check with other analysis programs e.g. GudRun for SANDALS-2, to what extent they need
isis_vms_compat. My understanding is they currently use.rawfiles but also have ability to use.nxs.martyngigg commentedon Jul 27, 2026
I remember checking with Tristan during the MNeudata requirements gathering and he said:
"Gudrun actually reads both. On SANDALS they use NeXuS files as standard now - on NIMROD we are still in the RAW file era, but there isn't really a reason why we couldn't easily shift to using NeXuS.
From the perspective of MNeuData I would agree and say that RAW files shouldn't be an option, for what it's worth. I have my reservations with HDF5, sure, but I appreciate that RAW is not a sustainable format moving forward."
Tom-Willemsen commentedon Jul 28, 2026
Tris has confirmed that GudRun does not use information from
isis_vms_compat.