NXcanSAS v1.1
THIS PAGE IS WORK IN PROGRESS
Latest News
2024-09 : Proposals for NXcanSAS v1.1 in development
Overview
Since its release in 2017, the NXcanSAS format has served the community well, but mostly in the role of an HDF equivalent to the CanSAS1D XML format. However, as is evident in its founding discussions, far greater functionality was originally envisaged. Advances in instrumentation and science are now starting to push at the boundaries of NXcanSAS v1.0. One such area is what may be termed Magnetic-SANS which encompasses a number of different SANS techniques involving manipulation of the neutron spin. To meet the needs of this area revisions are required to both NXcanSAS v1.0 and NeXus.
NXcanSAS is currently implemented by Mantid and SasView.
The Magnetic-SANS Problem
To reliably and unambigulously interpret Magnetic-SANS data it is necessary to know the spin history of the neutrons during the measurement. This, in turn, requires NXcanSAS to:
- have a way to include the polarization (aka spin state) information with the SANS data;
- have a way to denote the polarization;
- have a way to identify the type of Magnetic-SANS technique that generated the data, and;
- to include metadata relating to the spin manipulating devices (order encountered, type, etc) used during the measurement of the data.
NXcanSAS v1.0 and NeXus provide for some, but alas not all, of this information.
v1.1 Sub-group
- Dirk Honecker (ISIS)
- Steve King (ISIS & CanSAS)
- Annika Stellhorn (ESS)
- Lucas Wilkins (ISIS Data Scientist)
Proposals
Throughout these proposals, all references to polarization and its derivative forms shall be deemed to use American English (ie, spelt with a "z")!
For NXcanSAS v1.1
PROPOSAL 1: That the polarization simply be included as additional, optional, data axes within <SASdata/>. This functionality is already part of v1.0, but perhaps had not been envisaged for this particular use case!
Aside: This proposal does mean that every Q point will have associated polarization information (if the file contains Magnetic-SANS data), but this can be leveraged to address other requirements (see below), and the overhead is tiny. It also means the polarization data is directly available to a file reader. An alternative that was considered was something like <SASdata name="title" polarization="value"/>, but this was rejected because it would a) require processing and b) require introducing something else to denote the type of Magnetic-SANS measurement.
PROPOSAL 2: (Mandatory) That the additional polarization axes be named Pin and Pout for before and after the sample, respectively. The units of each are "none". Either both axes must be present, or neither.
Aside: This was the proposal that generated the most discussion in the sub-group! In the Magnetic-SANS literature Pin and Pout are variously called P_i / P_f, P_0 / P, or P / P'. Concerns were also expressed that any use of "P" risked confusion with pressure (amongst other quantities). However, examination of axis labels already in use in CanSAS1D and NXcanSAS showed a preference for concise labels without underscores (eg, Q, I, T, Idev, Qdev, Tdev, and Lambda) and it was not clear what else one might call polarization!. This proposal is thus a compromise that was reached, rather than a unanimous endorsement!
PROPOSAL 3: (Mandatory) That each polarization axis is restricted to one of the following values: +1 when the polarization is parallel to the polarizer; -1 when the polarization is antiparallel to the polarizer; and 0 when there is no polarisation. When both polarization axes would take the value 0 - ie, a conventional, unpolarised, SANS measurement - the polarization axes need not be specified.
Aside: Other options considered were: "0" / "1" (eg, denoting a flipper is off / on), but this carries the risk that a coding error could be interpreted as off or not polarized), and "+" / "-", "p" / "m" (eg, denoting plus / minus), or "p" / "a" (eg, denoting parallel / antiparallel), but which require translation into a number or boolean for use in a program. It was noted that ORSO have opted for "p" / "m" in their emerging NR data format.
PROPOSAL 4: (Mandatory) That the definition of the polarization be "For a magnetically saturated sample with collinear magnetic moments aligned along the polarization axis z, the non-spin-flip component with higher intensity is defined as the <minus, minus> spin state, but denoted here as [-1, -1]". This definition is to be incorporated in all relevant documentation relating to the production and use of NXcanSAS files.
Aside: A definition of the spin states is mandatory if the data is to have any meaning! This definition is a less ambiguous statement of the Moon-Riste-Koehler definition "for a polariser in the Northern hemisphere with the field aligned to the Earth's magnetic field, the transmitted beam is defined as - / minus." And in other literature the <minus, minus> state is said to transmit higher intensity than the <plus, plus> state.
Note: The astute reader will realise that this definition must invert in the Southern hemisphere! Data reduction software for polarized-SANS data measured at facilities there would need to correctly compensate if writing NXcanSAS files.
PROPOSAL 5a: (Recommended) That the wavelength-dependent neutron transmissions of polarizers, flippers or analyzers be written as separate <SAStransmission_spectrum/> blocks with appropriate names (eg, <SAStransmission_spectrum name="polarizer">), in exactly the same way that TOF-SANS CanSAS1D / NXcanSAS files presently incorporate the sample or background transmissions.
PROPOSAL 5b: (Recommended) That the fixed-wavelength neutron transmissions of polarizers, flippers or analyzers be written as a single value (@transmission) under their respective sub-class in <SASinstrument/>.
PROPOSAL 6a: (Recommended) That the wavelength-dependent efficiency of polarizers, flippers or analyzers be written as separate <SASefficiency_spectrum/> blocks with appropriate names (eg, <SASefficiency_spectrum name="polarizer">), by analogy with way that TOF-SANS CanSAS1D / NXcanSAS files presently incorporate the sample or background transmissions (see proposal 5a).
PROPOSAL 6b: (Recommended) That the fixed-wavelength efficiency of polarizers, flippers or analyzers be written as a single value (@efficiency) under their respective sub-class in <SASinstrument/>.
For NeXus
WiP
5. NXpolarizer & NXflipper need @transmission
6. NXflipper needs @efficiency
Pseudo-code Example
please check back
