3.3.2.10. NXmx

Status:

application definition, extends NXobject

Description:

functional application definition for macromolecular crystallography

Symbols:

These symbols will be used below to coordinate datasets ...

These symbols will be used below to coordinate datasets with the same shape. Most MX x-ray detectors will produce two-dimensional images. Some will produce three-dimensional images, using one of the indices to select a detector module.

dataRank: Rank of the data field

nP: Number of scan points

i: Number of detector pixels in the slowest direction

j: Number of detector pixels in the second slowest direction

k: Number of detector pixels in the third slowest direction

m: Number of channels in the incident beam spectrum, if known

groupIndex: An array of the hierarchical levels of the parents of detector elements or groupings of detector elements. A top-level element or grouping has parent level -1.

Groups cited:

NXattenuator, NXbeam, NXcollection, NXdata, NXdetector_channel, NXdetector_group, NXdetector_module, NXdetector, NXentry, NXinstrument, NXsample, NXsource, NXtransformations

Structure:

ENTRY: (required) NXentry

Note, it is recommended that ``file_name`` and ``file_time`` are included ...

Note, it is recommended that file_name and file_time are included as attributes at the root of a file that includes NXmx. See NXroot.

@version: (optional) NX_CHAR

Describes the version of the NXmx definition used to write this data. ...

Describes the version of the NXmx definition used to write this data. This must be a text (not numerical) representation. Such as:

@version="1.0"

Obligatory value: 1.0

title: (optional) NX_CHAR ⤆

start_time: (required) NX_DATE_TIME ⤆

ISO 8601 time/date of the first data point collected in UTC, ...

ISO 8601 time/date of the first data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone.

end_time: (optional) NX_DATE_TIME ⤆

ISO 8601 time/date of the last data point collected in UTC, ...

ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone. This field should only be filled when the value is accurately observed. If the data collection aborts or otherwise prevents accurate recording of the end_time, this field should be omitted.

end_time_estimated: (required) NX_DATE_TIME

ISO 8601 time/date of the last data point collected in UTC, ...

ISO 8601 time/date of the last data point collected in UTC, using the Z suffix to avoid confusion with local time. Note that the time zone of the beamline should be provided in NXentry/NXinstrument/time_zone. This field may be filled with a value estimated before an observed value is available.

definition: (required) NX_CHAR ⤆

NeXus NXDL schema to which this file conforms ...

NeXus NXDL schema to which this file conforms

Obligatory value: NXmx

DATA: (required) NXdata ⤆

data: (recommended) NX_NUMBER (Rank: dataRank, Dimensions: [nP, i, j, [k]]) ⤆

For a dimension-2 detector, the rank of the data array will be 3. ...

For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the first index.

data_scaling_factor: (optional) NX_NUMBER ⤆

An optional scaling factor to apply to the values in ``data``. ...

An optional scaling factor to apply to the values in data.

The elements in data are often stored as integers for efficiency reasons and need further correction, generating floats. The two fields data_scaling_factor and data_offset allow linear corrections using the following convention:

corrected_data = (data + offset) * scaling_factor

This formula will derive the corrected value, when necessary.

data_scaling_factor is sometimes known as gain and data_offset is sometimes known as pedestal or background, depending on the community.

Use these fields to specify constants that need to be applied to the data to correct it to physical values. For example, if the detector gain is 10 counts per photon and a constant background of 400 needs to be subtracted off the pixels, specify data_scaling_factor as 0.1 and data_offset as -400 to specify the required conversion from raw counts to corrected photons. It is implied processing software will apply these corrections on-the-fly during processing.

The rank of these fields should either be a single value for the full dataset, a single per-pixel array applied to every image (dimensions (i, j) or (i, j, k)), or a per-image correction specified with an array whose slowest rank is nP (dimensions (np, 1), (np, i, j) or (np, i, j, k)).

When omitted, the scaling factor is assumed to be 1.

data_offset: (optional) NX_NUMBER ⤆

An optional offset to apply to the values in data. ...

An optional offset to apply to the values in data.

When omitted, the offset is assumed to be 0.

See data_scaling_factor for more information.

SAMPLE: (required) NXsample ⤆

name: (required) NX_CHAR ⤆

Descriptive name of sample

depends_on: (required) NX_CHAR ⤆

This is a requirement to describe for any scan experiment. ...

This is a requirement to describe for any scan experiment.

The axis on which the sample position depends may be stored anywhere, but is normally stored in the NXtransformations group within the NXsample group.

If there is no goniometer, e.g. with a jet, depends_on should be set to “.”

temperature: (optional) NX_NUMBER {units=NX_TEMPERATURE}

TRANSFORMATIONS: (optional) NXtransformations ⤆

This is the recommended location for sample goniometer ...

This is the recommended location for sample goniometer and other related axes.

This is a requirement to describe for any scan experiment. The reason it is optional is mainly to accommodate XFEL single shot exposures.

Use of the depends_on field and the NXtransformations group is strongly recommended. As noted above this should be an absolute requirement to have for any scan experiment.

The reason it is optional is mainly to accommodate XFEL single shot exposures.

INSTRUMENT: (required) NXinstrument ⤆

name: (required) NX_CHAR ⤆

Name of instrument. Consistency with the controlled ...

Name of instrument. Consistency with the controlled vocabulary beamline naming in https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_beamline.html and https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.type.html is highly recommended.

@short_name: (optional) NX_CHAR ⤆

Short name for instrument, perhaps the acronym.

time_zone: (recommended) NX_DATE_TIME

ISO 8601 time_zone offset from UTC.

ATTENUATOR: (optional) NXattenuator ⤆

attenuator_transmission: (optional) NX_NUMBER {units=NX_UNITLESS}

DETECTOR_GROUP: (recommended) NXdetector_group ⤆

Optional logical grouping of detectors. ...

Optional logical grouping of detectors.

Each detector is represented as an NXdetector with its own detector data array. Each detector data array may be further decomposed into array sections by use of NXdetector_module groups. Detectors can be grouped logically together using NXdetector_group. Groups can be further grouped hierarchically in a single NXdetector_group (for example, if there are multiple detectors at an endstation or multiple endstations at a facility). Alternatively, multiple NXdetector_groups can be provided.

The groups are defined hierarchically, with names given in the group_names field, unique identifying indices given in the field group_index, and the level in the hierarchy given in the group_parent field. For example if an x-ray detector group, DET, consists of four detectors in a rectangular array:

DTL        DTR
DLL        DLR

We could have:

group_names: ["DET", "DTL", "DTR", "DLL", "DLR"]
 group_index: [1, 2, 3, 4, 5]
 group_parent:  [-1, 1, 1, 1, 1]

group_names: (required) NX_CHAR ⤆

An array of the names of the detectors or the names of ...

An array of the names of the detectors or the names of hierarchical groupings of detectors.

group_index: (required) NX_INT (Rank: 1, Dimensions: [i]) ⤆

An array of unique identifiers for detectors or groupings ...

An array of unique identifiers for detectors or groupings of detectors.

Each ID is a unique ID for the corresponding detector or group named in the field group_names. The IDs are positive integers starting with 1.

group_parent: (required) NX_INT (Rank: 1, Dimensions: [groupIndex]) ⤆

An array of the hierarchical levels of the parents of detectors ...

An array of the hierarchical levels of the parents of detectors or groupings of detectors.

A top-level grouping has parent level -1.

DETECTOR: (required) NXdetector ⤆

Normally the detector group will have the name ``detector``. ...

Normally the detector group will have the name detector. However, in the case of multiple detectors, each detector needs a uniquely named NXdetector.

depends_on: (optional) NX_CHAR ⤆

NeXus path to the detector positioner axis that most directly ...

NeXus path to the detector positioner axis that most directly supports the detector. In the case of a single-module detector, the detector axis chain may start here.

data: (recommended) NX_NUMBER (Rank: dataRank, Dimensions: [nP, i, j, [k]]) ⤆

For a dimension-2 detector, the rank of the data array will be 3. ...

For a dimension-2 detector, the rank of the data array will be 3. For a dimension-3 detector, the rank of the data array will be 4. This allows for the introduction of the frame number as the first index.

description: (recommended) NX_CHAR ⤆

name/manufacturer/model/etc. information.

time_per_channel: (optional) NX_CHAR {units=NX_TIME}

For a time-of-flight detector this is the scaling ...

For a time-of-flight detector this is the scaling factor to convert from the numeric value reported to the flight time for a given measurement.

distance: (recommended) NX_FLOAT {units=NX_LENGTH} ⤆

Distance from the sample to the beam center. ...

Distance from the sample to the beam center. Normally this value is for guidance only, the proper geometry can be found following the depends_on axis chain, But in appropriate cases where the dectector distance to the sample is observable independent of the axis chain, that may take precedence over the axis chain calculation.

distance_derived: (recommended) NX_BOOLEAN

Boolean to indicate if the distance is a derived, rather than ...

Boolean to indicate if the distance is a derived, rather than a primary observation. If distance_derived true or is not specified, the distance is assumed to be derived from detector axis specifications.

dead_time: (optional) NX_FLOAT {units=NX_TIME} ⤆

Detector dead time.

count_time: (recommended) NX_NUMBER {units=NX_TIME} ⤆

Elapsed actual counting time.

beam_center_derived: (optional) NX_BOOLEAN

Boolean to indicate if the distance is a derived, rather than ...

Boolean to indicate if the distance is a derived, rather than a primary observation. If true or not provided, that value of beam_center_derived is assumed to be true.

beam_center_x: (recommended) NX_FLOAT {units=NX_LENGTH} ⤆

This is the x position where the direct beam would hit the ...

This is the x position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute. Normally, this should be derived from the axis chain, but the direct specification may take precedence if it is not a derived quantity.

beam_center_y: (recommended) NX_FLOAT {units=NX_LENGTH} ⤆

This is the y position where the direct beam would hit the ...

This is the y position where the direct beam would hit the detector. This is a length and can be outside of the actual detector. The length can be in physical units or pixels as documented by the units attribute. Normally, this should be derived from the axis chain, but the direct specification may take precedence if it is not a derived quantity.

angular_calibration_applied: (optional) NX_BOOLEAN ⤆

True when the angular calibration has been applied in the ...

True when the angular calibration has been applied in the electronics, false otherwise.

angular_calibration: (optional) NX_FLOAT (Rank: dataRank, Dimensions: [i, j, [k]]) ⤆

Angular calibration data.

flatfield_applied: (optional) NX_BOOLEAN ⤆

True when the flat field correction has been applied in the ...

True when the flat field correction has been applied in the electronics, false otherwise.

flatfield: (optional) NX_NUMBER (Rank: dataRank, Dimensions: [i, j, [k]])

Flat field correction data. If provided, it is recommended ...

Flat field correction data. If provided, it is recommended that it be compressed.

flatfield_error: (optional) NX_NUMBER (Rank: dataRank, Dimensions: [i, j, [k]])

*** Deprecated form. Use plural form *** ...

* Deprecated form. Use plural form * Errors of the flat field correction data. If provided, it is recommended that it be compressed.

flatfield_errors: (optional) NX_NUMBER (Rank: dataRank, Dimensions: [i, j, [k]])

Errors of the flat field correction data. If provided, it is recommende ...

Errors of the flat field correction data. If provided, it is recommended that it be compressed.

pixel_mask_applied: (optional) NX_BOOLEAN ⤆

True when the pixel mask correction has been applied in the ...

True when the pixel mask correction has been applied in the electronics, false otherwise.

pixel_mask: (recommended) NX_INT (Rank: 2, Dimensions: [i, j]) ⤆

The 32-bit pixel mask for the detector. Can be either one mask ...

The 32-bit pixel mask for the detector. Can be either one mask for the whole dataset (i.e. an array with indices i, j) or each frame can have its own mask (in which case it would be an array with indices nP, i, j).

Contains a bit field for each pixel to signal dead, blind, high or otherwise unwanted or undesirable pixels. They have the following meaning:

  • bit 0: gap (pixel with no sensor)

  • bit 1: dead

  • bit 2: under-responding

  • bit 3: over-responding

  • bit 4: noisy

  • bit 5: -undefined-

  • bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others)

  • bit 7: -undefined-

  • bit 8: user defined mask (e.g. around beamstop)

  • bits 9-30: -undefined-

  • bit 31: virtual pixel (corner pixel with interpolated value)

Normal data analysis software would not take pixels into account when a bit in (mask & 0x0000FFFF) is set. Tag bit in the upper two bytes would indicate special pixel properties that normally would not be a sole reason to reject the intensity value (unless lower bits are set.

If the full bit depths is not required, providing a mask with fewer bits is permissible.

If needed, additional pixel masks can be specified by including additional entries named pixel_mask_N, where N is an integer. For example, a general bad pixel mask could be specified in pixel_mask that indicates noisy and dead pixels, and an additional pixel mask from experiment-specific shadowing could be specified in pixel_mask_2. The cumulative mask is the bitwise OR of pixel_mask and any pixel_mask_N entries.

If provided, it is recommended that it be compressed.

countrate_correction_applied: (optional) NX_BOOLEAN ⤆

Counting detectors usually are not able to measure all incoming particle ...

Counting detectors usually are not able to measure all incoming particles, especially at higher count-rates. Count-rate correction is applied to account for these errors.

True when count-rate correction has been applied, false otherwise.

countrate_correction_lookup_table: (optional) NX_NUMBER (Rank: 1, Dimensions: [m]) ⤆

The countrate_correction_lookup_table defines the LUT used for count-rat ...

The countrate_correction_lookup_table defines the LUT used for count-rate correction. It maps a measured count \(c\) to its corrected value \(countrate\_correction\_lookup\_table[c]\).

\(m\) denotes the length of the table.

virtual_pixel_interpolation_applied: (optional) NX_BOOLEAN ⤆

True when virtual pixel interpolation has been applied, false otherwise. ...

True when virtual pixel interpolation has been applied, false otherwise.

When virtual pixel interpolation is applied, values of some pixels may contain interpolated values. For example, to account for space between readout chips on a module, physical pixels on edges and corners between chips may have larger sensor areas and counts may be distributed between their logical pixels.

bit_depth_readout: (recommended) NX_INT ⤆

How many bits the electronics record per pixel.

detector_readout_time: (optional) NX_FLOAT {units=NX_TIME} ⤆

Time it takes to read the detector (typically milliseconds). ...

Time it takes to read the detector (typically milliseconds). This is important to know for time resolved experiments.

frame_time: (optional) NX_FLOAT {units=NX_TIME} ⤆

This is time for each frame. This is exposure_time + readout ...

This is time for each frame. This is exposure_time + readout time.

gain_setting: (optional) NX_CHAR ⤆

The gain setting of the detector. This influences ...

The gain setting of the detector. This influences background. This is a detector-specific value meant to document the gain setting of the detector during data collection, for detectors with multiple available gain settings.

Examples of gain settings include:

  • standard

  • fast

  • auto

  • high

  • medium

  • low

  • mixed high to medium

  • mixed medium to low

Developers are encouraged to use one of these terms, or to submit additional terms to add to the list.

saturation_value: (optional) NX_NUMBER ⤆

The value at which the detector goes into saturation. ...

The value at which the detector goes into saturation. Data above this value is known to be invalid.

For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value.

underload_value: (optional) NX_NUMBER ⤆

The lowest value at which pixels for this detector ...

The lowest value at which pixels for this detector would be reasonably be measured.

For example, given a saturation_value and an underload_value, the valid pixels are those less than or equal to the saturation_value and greater than or equal to the underload_value.

sensor_material: (required) NX_CHAR ⤆

At times, radiation is not directly sensed by the detector. ...

At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the name of this converter material.

sensor_thickness: (required) NX_FLOAT {units=NX_LENGTH} ⤆

At times, radiation is not directly sensed by the detector. ...

At times, radiation is not directly sensed by the detector. Rather, the detector might sense the output from some converter like a scintillator. This is the thickness of this converter material.

threshold_energy: (optional) NX_FLOAT {units=NX_ENERGY} ⤆

Single photon counter detectors can be adjusted for a certain ...

Single photon counter detectors can be adjusted for a certain energy range in which they work optimally. This is the energy setting for this. If the detector supports multiple thresholds, this is an array.

type: (optional) NX_CHAR ⤆

Description of type such as scintillator, ...

Description of type such as scintillator, ccd, pixel, image plate, CMOS, …

TRANSFORMATIONS: (optional) NXtransformations ⤆

Location for axes (transformations) to do with the ...

Location for axes (transformations) to do with the detector. In the case of a single-module detector, the axes of the detector axis chain may be stored here.

COLLECTION: (optional) NXcollection ⤆

Suggested container for detailed non-standard detector ...

Suggested container for detailed non-standard detector information like corrections applied automatically or performance settings.

DETECTOR_MODULE: (required) NXdetector_module ⤆

Many detectors consist of multiple smaller modules that are ...

Many detectors consist of multiple smaller modules that are operated in sync and store their data in a common dataset. To allow consistent parsing of the experimental geometry, this application definiton requires all detectors to define a detector module, even if there is only one.

This group specifies the hyperslab of data in the data array associated with the detector that contains the data for this module. If the module is associated with a full data array, rather than with a hyperslab within a larger array, then a single module should be defined, spanning the entire array.

Note, the pixel size is given as values in the array fast_pixel_direction and slow_pixel_direction.

data_origin: (required) NX_INT ⤆

A dimension-2 or dimension-3 field which gives the indices ...

A dimension-2 or dimension-3 field which gives the indices of the origin of the hyperslab of data for this module in the main area detector image in the parent NXdetector module.

The data_origin is 0-based.

The frame number dimension (nP) is omitted. Thus the data_origin field for a dimension-2 dataset with indices (nP, i, j) will be an array with indices (i, j), and for a dimension-3 dataset with indices (nP, i, j, k) will be an array with indices (i, j, k).

The order of indices (i, j or i, j, k) is slow to fast.

data_size: (required) NX_INT ⤆

Two or three values for the size of the module in pixels in ...

Two or three values for the size of the module in pixels in each direction. Dimensionality and order of indices is the same as for data_origin.

data_stride: (optional) NX_INT

Two or three values for the stride of the module in pixels in ...

Two or three values for the stride of the module in pixels in each direction. By default the stride is [1,1] or [1,1,1], and this is the most likely case. This optional field is included for completeness.

module_offset: (optional) NX_NUMBER {units=NX_LENGTH} ⤆

Offset of the module in regards to the origin of the detector in an ...

Offset of the module in regards to the origin of the detector in an arbitrary direction.

@transformation_type: (required) NX_CHAR ⤆

Obligatory value: translation

@vector: (required) NX_NUMBER ⤆

@offset: (required) NX_NUMBER ⤆

@depends_on: (required) NX_CHAR ⤆

fast_pixel_direction: (required) NX_NUMBER {units=NX_LENGTH} ⤆

Values along the direction of :ref:`fastest varying

Values along the direction of fastest varying pixel direction. The direction itself is given through the vector attribute.

@transformation_type: (required) NX_CHAR ⤆

Obligatory value: translation

@vector: (required) NX_NUMBER ⤆

@offset: (required) NX_NUMBER ⤆

@depends_on: (required) NX_CHAR ⤆

slow_pixel_direction: (required) NX_NUMBER {units=NX_LENGTH} ⤆

Values along the direction of :ref:`slowest varying

Values along the direction of slowest varying pixel direction. The direction itself is given through the vector attribute.

@transformation_type: (required) NX_CHAR ⤆

Obligatory value: translation

@vector: (required) NX_NUMBER ⤆

@offset: (required) NX_NUMBER ⤆

@depends_on: (required) NX_CHAR ⤆

CHANNELNAME_channel: (required) NXdetector_channel ⤆

Group containing the description and metadata for a single channel from ...

Group containing the description and metadata for a single channel from a multi-channel detector.

Given an NXdata group linked as part of an NXdetector group that has an axis with named channels (see the example in NXdata), the NXdetector will have a series of NXdetector_channel groups, one for each channel, named CHANNELNAME_channel.

BEAM: (required) NXbeam ⤆

@flux: (optional) NX_CHAR

Which field contains the measured flux. One of ``flux``, ...

Which field contains the measured flux. One of flux, total_flux, flux_integrated, or total_flux_integrated.

Alternatively, the name being indicated could be a link to a dataset in an NXmonitor group that records per shot beam data.

incident_wavelength: (required) NX_FLOAT {units=NX_WAVELENGTH} ⤆

In the case of a monchromatic beam this is the scalar ...

In the case of a monchromatic beam this is the scalar wavelength.

Several other use cases are permitted, depending on the presence or absence of other incident_wavelength_X fields.

In the case of a polychromatic beam this is an array of length m of wavelengths, with the relative weights in incident_wavelength_weights.

In the case of a monochromatic beam that varies shot- to-shot, this is an array of wavelengths, one for each recorded shot. Here, incident_wavelength_weights and incident_wavelength_spread are not set.

In the case of a polychromatic beam that varies shot-to- shot, this is an array of length m with the relative weights in incident_wavelength_weights as a 2D array.

In the case of a polychromatic beam that varies shot-to- shot and where the channels also vary, this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_wavelength_weights as a 2D array.

Note, variants are a good way to represent several of these use cases in a single dataset, e.g. if a calibrated, single-value wavelength value is available along with the original spectrum from which it was calibrated.

incident_wavelength_weight: (optional) NX_FLOAT

DEPRECATED: use incident_wavelength_weights, see https://github.com/nexusformat/definitions/issues/837

In the case of a polychromatic beam this is an array of ...

In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding wavelengths in incident_wavelength.

In the case of a polychromatic beam that varies shot-to- shot, this is a 2D array of dimensions nP by m (slow to fast) of the relative weights of the corresponding wavelengths in incident_wavelength.

incident_wavelength_weights: (optional) NX_FLOAT ⤆

In the case of a polychromatic beam this is an array of ...

In the case of a polychromatic beam this is an array of length m of the relative weights of the corresponding wavelengths in incident_wavelength.

In the case of a polychromatic beam that varies shot-to- shot, this is a 2D array of dimensions np by m (slow to fast) of the relative weights of the corresponding wavelengths in incident_wavelength.

incident_wavelength_spread: (optional) NX_FLOAT {units=NX_WAVELENGTH} ⤆

The wavelength spread FWHM for the corresponding ...

The wavelength spread FWHM for the corresponding wavelength(s) in incident_wavelength.

In the case of shot-to-shot variation in the wavelength spread, this is a 2D array of dimension nP by m (slow to fast) of the spreads of the corresponding wavelengths in incident_wavelength.

flux: (optional) NX_FLOAT {units=NX_FLUX}

Flux density incident on beam plane area in photons ...

Flux density incident on beam plane area in photons per second per unit area.

In the case of a beam that varies in flux shot-to-shot, this is an array of values, one for each recorded shot.

total_flux: (optional) NX_FLOAT {units=NX_FREQUENCY}

Flux incident on beam plane in photons per second. In other words ...

Flux incident on beam plane in photons per second. In other words this is the flux integrated over area.

Useful where spatial beam profiles are not known.

In the case of a beam that varies in total flux shot-to-shot, this is an array of values, one for each recorded shot.

flux_integrated: (optional) NX_FLOAT {units=NX_PER_AREA}

Flux density incident on beam plane area in photons ...

Flux density incident on beam plane area in photons per unit area. In other words this is the flux integrated over time.

Useful where temporal beam profiles of flux are not known.

In the case of a beam that varies in flux shot-to-shot, this is an array of values, one for each recorded shot.

total_flux_integrated: (optional) NX_FLOAT {units=NX_DIMENSIONLESS}

Flux incident on beam plane in photons. In other words this is the :ref: ...

Flux incident on beam plane in photons. In other words this is the flux integrated over time and area.

Useful where temporal beam profiles of flux are not known.

In the case of a beam that varies in total flux shot-to-shot, this is an array of values, one for each recorded shot.

incident_beam_size: (recommended) NX_FLOAT (Rank: 1, Dimensions: [2]) {units=NX_LENGTH}

Two-element array of FWHM (if Gaussian or Airy function) or ...

Two-element array of FWHM (if Gaussian or Airy function) or diameters (if top hat) or widths (if rectangular) of the beam in the order x, y

profile: (recommended) NX_CHAR

The beam profile, Gaussian, Airy function, top-hat or ...

The beam profile, Gaussian, Airy function, top-hat or rectangular. The profile is given in the plane of incidence of the beam on the sample.

Any of these values: Gaussian | Airy | top-hat | rectangular

incident_polarisation_stokes: (optional) NX_NUMBER (Rank: 2, Dimensions: [nP, 4])

DEPRECATED: use incident_polarization_stokes, see https://github.com/nexusformat/definitions/issues/708

Polarization vector on entering beamline ...

Polarization vector on entering beamline component using Stokes notation

incident_polarization_stokes: (recommended) NX_NUMBER (Rank: 2, Dimensions: [nP, 4]) ⤆

Polarization vector on entering beamline ...

Polarization vector on entering beamline component using Stokes notation. See incident_polarization_stokes in NXbeam

incident_wavelength_spectrum: (optional) NXdata ⤆

This group is intended for use cases that do not fit the ...

This group is intended for use cases that do not fit the incident_wavelength and incident_wavelength_weights fields above, perhaps for example a 2D spectrometer.

SOURCE: (required) NXsource

The neutron or x-ray storage ring/facility. Note, the NXsource base class ...

The neutron or x-ray storage ring/facility. Note, the NXsource base class has many more fields available, but at present we only require the name.

name: (required) NX_CHAR ⤆

Name of source. Consistency with the naming in ...

Name of source. Consistency with the naming in https://mmcif.wwpdb.org/dictionaries/mmcif_pdbx_v50.dic/Items/_diffrn_source.pdbx_synchrotron_site.html controlled vocabulary is highly recommended.

@short_name: (optional) NX_CHAR ⤆

short name for source, perhaps the acronym

Hypertext Anchors

List of hypertext anchors for all groups, fields, attributes, and links defined in this class.

NXDL Source:

https://github.com/nexusformat/definitions/blob/main/applications/NXmx.nxdl.xml