diff --git a/Makefile b/Makefile index 3a882c2568..e1d0696fa5 100644 --- a/Makefile +++ b/Makefile @@ -60,9 +60,6 @@ test :: clean :: $(RM) -rf $(BUILD_DIR) - $(RM) -rf $(BASE_CLASS_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(APPDEF_DIR)/$(NYAML_SUBDIR) - $(RM) -rf $(CONTRIB_DIR)/$(NYAML_SUBDIR) prepare :: $(PYTHON) -m dev_tools manual --prepare --build-root $(BUILD_DIR) @@ -97,24 +94,10 @@ all :: @echo "HTML built: `ls -lAFgh $(BUILD_DIR)/manual/build/html/index.html`" @echo "PDF built: `ls -lAFgh $(BUILD_DIR)/manual/build/latex/nexus.pdf`" -$(BASE_CLASS_DIR)/%.nxdl.xml : $(BASE_CLASS_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(CONTRIB_DIR)/%.nxdl.xml : $(CONTRIB_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -$(APPDEF_DIR)/%.nxdl.xml : $(APPDEF_DIR)/$(NYAML_SUBDIR)/%.yaml - nyaml2nxdl $< --output-file $@ - -nxdl: $(YBC_NXDL_TARGETS) $(YCONTRIB_NXDL_TARGETS) $(YAPPDEF_NXDL_TARGETS) - -nyaml: - $(MAKE) -f nyaml.mk - # NeXus - Neutron and X-ray Common Data Format # -# Copyright (C) 2008-2024 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2022 NeXus International Advisory Committee (NIAC) # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public @@ -130,4 +113,4 @@ nyaml: # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# For further information, see http://www.nexusformat.org +# For further information, see http://www.nexusformat.org \ No newline at end of file diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index f33b6d699b..2af067b575 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,5 +1,5 @@ - - + + - - - - These symbols will be used below to illustrate the coordination of the - rank and sizes of datasets and the preferred ordering of the - dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering - principle is slowest to fastest. The type of each dimension should - follow the order of scan points, detector output (e.g. pixels), then - time-of-flight (i.e. spectroscopy, spectrometry). Note that the output - of a detector is not limited to single values (0D), lists (1D) and - images (2), but three or higher dimensional arrays can be produced by - a detector at each trigger. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - 1. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - 2. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - + + + + + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + + number of scan points (only present in scanning measurements) + number of detector pixels in the first (slowest) direction + number of detector pixels in the second (faster) direction + number of detector pixels in the third (if necessary, fastest) direction + number of bins in the time-of-flight histogram + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + + + Total time of flight + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + + + + + + + + + + + Title of measurement + + + + Integral of data as check of data integrity + + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + name/manufacturer/model/etc. information + + + + Serial number for the detector + + + + Local name for the detector + + + + Position and orientation of detector + + + + Solid angle subtended by the detector at the sample + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + + Group containing the description and metadata for a single channel from a multi-channel + detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with + named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), + the NXdetector will have a series of NXdetector_channel groups, one for each channel, + named CHANNELNAME_channel. + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + + + 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. + + + + + + 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. + + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + Angular calibration data. + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + Flat field correction data. + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + 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 or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * 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. + + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + + 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. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + 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. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. 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. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + 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. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + 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. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + 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. + + + + + 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. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - 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. - - - - - 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. - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - 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 or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * 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. - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - 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. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - 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. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. 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. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - 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. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - 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. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - 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. - - - - - 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. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - - - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - - raw data output from the detector - + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + + raw data output from the detector + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + The reference point of the detector is the center of the first pixel. + In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + diff --git a/contributed_definitions/nyaml/NXinstrument.yaml b/contributed_definitions/nyaml/NXinstrument.yaml deleted file mode 100644 index 4607aa5ae5..0000000000 --- a/contributed_definitions/nyaml/NXinstrument.yaml +++ /dev/null @@ -1,190 +0,0 @@ -category: base -doc: | - Collection of the components of the instrument or beamline. - - Template of instrument descriptions comprising various beamline components. - Each component will also be a NeXus group defined by its distance from the - sample. Negative distances represent beamline components that are before the - sample while positive distances represent components that are after the sample. - This device allows the unique identification of beamline components in a way - that is valid for both reactor and pulsed instrumentation. -type: group -NXinstrument(NXobject): - name: - doc: | - Name of instrument - \@short_name: - doc: | - short name for instrument, perhaps the acronym - energy_resolution(NX_FLOAT): - unit: NX_ENERGY - doc: | - Energy resolution of the experiment (FWHM or gaussian broadening) - momentum_resolution(NX_FLOAT): - unit: NX_WAVENUMBER - doc: | - Momentum resolution of the experiment (FWHM) - angular_resolution(NX_FLOAT): - unit: NX_ANGLE - doc: | - Angular resolution of the experiment (FWHM) - spatial_resolution(NX_FLOAT): - unit: NX_LENGTH - doc: | - Spatial resolution of the experiment (Airy disk radius) - temporal_resolution(NX_FLOAT): - unit: NX_TIME - doc: | - Temporal resolution of the experiment (FWHM) - (NXaperture): - (NXattenuator): - (NXbeam): - (NXbeam_stop): - (NXbending_magnet): - (NXcollimator): - (NXcollection): - (NXcapillary): - (NXcrystal): - (NXdetector): - (NXdetector_group): - (NXdisk_chopper): - (NXevent_data): - (NXfabrication): - (NXfermi_chopper): - (NXfilter): - (NXflipper): - (NXguide): - (NXinsertion_device): - (NXmirror): - (NXmoderator): - (NXmonochromator): - (NXpolarizer): - (NXpositioner): - (NXsource): - (NXtransformations)DIFFRACTOMETER: - (NXvelocity_selector): - (NXxraylens): - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 331d6037bd4c05402a42cab90e3df4c3115b21231d57ef54b1221e1ed859584d -# -# -# -# -# -# Collection of the components of the instrument or beamline. -# -# Template of instrument descriptions comprising various beamline components. -# Each component will also be a NeXus group defined by its distance from the -# sample. Negative distances represent beamline components that are before the -# sample while positive distances represent components that are after the sample. -# This device allows the unique identification of beamline components in a way -# that is valid for both reactor and pulsed instrumentation. -# -# -# -# Name of instrument -# -# -# -# short name for instrument, perhaps the acronym -# -# -# -# -# -# Energy resolution of the experiment (FWHM or gaussian broadening) -# -# -# -# -# Momentum resolution of the experiment (FWHM) -# -# -# -# -# Angular resolution of the experiment (FWHM) -# -# -# -# -# Spatial resolution of the experiment (Airy disk radius) -# -# -# -# -# Temporal resolution of the experiment (FWHM) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# diff --git a/contributed_definitions/nyaml/NXsource.yaml b/contributed_definitions/nyaml/NXsource.yaml deleted file mode 100644 index 1692b666ea..0000000000 --- a/contributed_definitions/nyaml/NXsource.yaml +++ /dev/null @@ -1,521 +0,0 @@ -category: base -doc: | - The neutron or x-ray storage ring/facility. -type: group -NXsource(NXobject): - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - Effective distance from sample - Distance as seen by radiation from sample. This number should be negative - to signify that it is upstream of the sample. - name: - doc: | - Name of source - \@short_name: - doc: | - short name for source, perhaps the acronym - type: - doc: | - type of radiation source (pick one from the enumerated list and spell exactly) - enumeration: [Spallation Neutron Source, Pulsed Reactor Neutron Source, Reactor Neutron Source, Synchrotron X-ray Source, Pulsed Muon Source, Rotating Anode X-ray, Fixed Tube X-ray, UV Laser, Free-Electron Laser, Optical Laser, Ion Source, UV Plasma Source, Metal Jet X-ray] - probe: - doc: | - type of radiation probe (pick one from the enumerated list and spell exactly) - enumeration: [neutron, x-ray, muon, electron, ultraviolet, visible light, positron, proton] - power(NX_FLOAT): - unit: NX_POWER - doc: | - Source power - emittance_x(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in X (horizontal) direction. - emittance_y(NX_FLOAT): - unit: NX_EMITTANCE - doc: | - Source emittance (nm-rad) in Y (horizontal) direction. - sigma_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in x - sigma_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - particle beam size in y - flux(NX_FLOAT): - unit: NX_FLUX - doc: | - Source intensity/area (example: s-1 cm-2) - energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - Source energy. - For storage rings, this would be the particle beam energy. - For X-ray tubes, this would be the excitation voltage. - current(NX_FLOAT): - unit: NX_CURRENT - doc: | - Accelerator, X-ray tube, or storage ring current - voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Accelerator voltage - frequency(NX_FLOAT): - unit: NX_FREQUENCY - doc: | - Frequency of pulsed source - period(NX_FLOAT): - unit: NX_PERIOD - doc: | - Period of pulsed source - target_material: - doc: | - Pulsed source target material - enumeration: [Ta, W, depleted_U, enriched_U, Hg, Pb, C] - notes(NXnote): - doc: | - any source/facility related messages/events that - occurred during the experiment - bunch_pattern(NXdata): - doc: | - For storage rings, description of the bunch pattern. - This is useful to describe irregular bunch patterns. - title: - doc: | - name of the bunch pattern - number_of_bunches(NX_INT): - doc: | - For storage rings, the number of bunches in use. - bunch_length(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, temporal length of the bunch - bunch_distance(NX_FLOAT): - unit: NX_TIME - doc: | - For storage rings, time between bunches - pulse_width(NX_FLOAT): - unit: NX_TIME - doc: | - temporal width of source pulse - - # pulsed sources or storage rings could use this - pulse_shape(NXdata): - doc: | - source pulse shape - - # pulsed sources or storage rings could use this - mode: - doc: | - source operating mode - enumeration: - Single Bunch: - doc: | - for storage rings - Multi Bunch: - doc: | - for storage rings - - # other sources could add to this - - # other sources could add to this - top_up(NX_BOOLEAN): - doc: | - Is the synchrotron operating in top_up mode? - last_fill(NX_NUMBER): - unit: NX_CURRENT - doc: | - For storage rings, the current at the end of the most recent injection. - \@time: - type: NX_DATE_TIME - doc: | - date and time of the most recent injection. - photon_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - The center photon energy of the source, before it is - monochromatized or converted - center_wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - The center wavelength of the source, before it is - monochromatized or converted - pulse_energy(NX_FLOAT): - unit: NX_ENERGY - doc: | - For pulsed sources, the energy of a single pulse - peak_power(NX_FLOAT): - unit: NX_POWER - doc: | - For pulsed sources, the pulse energy divided - by the pulse duration - bunch_number_start(NX_INT): - doc: | - Some facilities tag each bunch. - First bunch of the measurement - bunch_number_end(NX_INT): - doc: | - Last bunch of the measurement - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the source and NXoff_geometry to describe its shape instead - doc: | - "Engineering" location of source. - (NXfabrication): - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the beam line component - distribution(NXdata): - doc: | - The wavelength or energy distribution of the source - \@default: - doc: | - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - depends_on(NX_CHAR): - doc: | - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the - z axis. - - .. image:: source/source.png - :width: 40% - (NXtransformations): - doc: | - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 19f1ee4e446868766ab035145a5835ce38e26b04d8e8ee50bf641392cb5c3525 -# -# -# -# -# -# The neutron or x-ray storage ring/facility. -# -# -# -# Effective distance from sample -# Distance as seen by radiation from sample. This number should be negative -# to signify that it is upstream of the sample. -# -# -# -# -# Name of source -# -# -# -# short name for source, perhaps the acronym -# -# -# -# -# -# type of radiation source (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# type of radiation probe (pick one from the enumerated list and spell exactly) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# Source power -# -# -# -# -# Source emittance (nm-rad) in X (horizontal) direction. -# -# -# -# -# Source emittance (nm-rad) in Y (horizontal) direction. -# -# -# -# -# particle beam size in x -# -# -# -# -# particle beam size in y -# -# -# -# -# Source intensity/area (example: s-1 cm-2) -# -# -# -# -# Source energy. -# For storage rings, this would be the particle beam energy. -# For X-ray tubes, this would be the excitation voltage. -# -# -# -# -# Accelerator, X-ray tube, or storage ring current -# -# -# -# -# Accelerator voltage -# -# -# -# -# Frequency of pulsed source -# -# -# -# -# Period of pulsed source -# -# -# -# -# Pulsed source target material -# -# -# -# -# -# -# -# -# -# -# -# -# -# any source/facility related messages/events that -# occurred during the experiment -# -# -# -# -# For storage rings, description of the bunch pattern. -# This is useful to describe irregular bunch patterns. -# -# -# -# name of the bunch pattern -# -# -# -# -# -# For storage rings, the number of bunches in use. -# -# -# -# -# For storage rings, temporal length of the bunch -# -# -# -# -# For storage rings, time between bunches -# -# -# -# -# temporal width of source pulse -# -# -# -# -# -# source pulse shape -# -# -# -# -# -# source operating mode -# -# -# -# -# for storage rings -# -# -# -# -# for storage rings -# -# -# -# -# -# -# -# -# Is the synchrotron operating in top_up mode? -# -# -# -# -# For storage rings, the current at the end of the most recent injection. -# -# -# -# date and time of the most recent injection. -# -# -# -# -# -# The center photon energy of the source, before it is -# monochromatized or converted -# -# -# -# -# The center wavelength of the source, before it is -# monochromatized or converted -# -# -# -# -# For pulsed sources, the energy of a single pulse -# -# -# -# -# For pulsed sources, the pulse energy divided -# by the pulse duration -# -# -# -# -# Some facilities tag each bunch. -# First bunch of the measurement -# -# -# -# -# Last bunch of the measurement -# -# -# -# -# "Engineering" location of source. -# -# -# -# -# This group describes the shape of the beam line component -# -# -# -# -# The wavelength or energy distribution of the source -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the source plane is its center in the x and y axis. The source is considered infinitely thin in the -# z axis. -# -# .. image:: source/source.png -# :width: 40% -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# -# -#