diff --git a/Makefile b/Makefile index e1d0696fa5..3a882c2568 100644 --- a/Makefile +++ b/Makefile @@ -60,6 +60,9 @@ 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) @@ -94,10 +97,24 @@ 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-2022 NeXus International Advisory Committee (NIAC) +# Copyright (C) 2008-2024 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 @@ -113,4 +130,4 @@ all :: # 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 \ No newline at end of file +# For further information, see http://www.nexusformat.org diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 4f878263b2..74ed194f03 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -48,6 +48,17 @@ Note, it is recommended to use NXtransformations instead. + + + This is to be used if there is no actuator/sensor that controls/measures + the environment parameters, but the user would still like to give a value for + it. An example would be a room temperature experiment where the temperature is + not actively measured, but rather estimated. + + Note that this method for recording the environment parameters is not advised, + but using NXsensor and NXactuator is strongly recommended instead. + + NeXus positions components by applying a set of translations and rotations @@ -69,6 +80,29 @@ Additional information, LabView logs, digital photographs, etc - - + + + Any actuator used to control the environment. This can be linked to an actuator + defined in an NXinstrument instance. + + + + + Any sensor used to monitor the environment. This can be linked to a sensor + defined in an NXinstrument instance. + + + + + .. 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/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 0de6103994..5348d55b5f 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -101,5 +101,4 @@ Individual lenses in the collection column section - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 5ad424d384..db991447d2 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -154,5 +154,4 @@ Individual lenses outside the main optics ensambles described by the subclasses - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 03fb871c8e..3207888517 100644 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ b/contributed_definitions/NXenergydispersion.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. @@ -87,5 +87,4 @@ Individual lenses in the energy dispersive section - diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index b412effe62..dff2584fcf 100644 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ b/contributed_definitions/NXmanipulator.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Extension of NXpositioner to include fields to describe the use of manipulators in photoemission experiments. @@ -79,7 +79,6 @@ Class to describe the motors that are used in the manipulator - Refers to the last transformation specifying the positon of the manipulator in diff --git a/contributed_definitions/nyaml/NXdetector.yaml b/contributed_definitions/nyaml/NXdetector.yaml deleted file mode 100644 index 8fd286fc58..0000000000 --- a/contributed_definitions/nyaml/NXdetector.yaml +++ /dev/null @@ -1,1758 +0,0 @@ -category: base -doc: | - A detector, detector bank, or multidetector. -symbols: - doc: | - 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. - nP: | - number of scan points (only present in scanning measurements) - i: | - number of detector pixels in the first (slowest) direction - j: | - number of detector pixels in the second (faster) direction - k: | - number of detector pixels in the third (if necessary, fastest) - direction - tof: | - number of bins in the time-of-flight histogram -type: group -(NXobject)NXdetector: - time_of_flight(NX_FLOAT): - unit: NX_TIME_OF_FLIGHT - doc: | - Total time of flight - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - Total time of flight - raw_time_of_flight(NX_INT): - unit: NX_PULSES - doc: | - In DAQ clock pulses - dimensions: - rank: 1 - dim: [[1, tof+1]] - \@frequency: - type: NX_NUMBER - doc: | - Clock frequency in Hz - detector_number(NX_INT): - doc: | - Identifier for detector (pixels) - Can be multidimensional, if needed - data(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - \@long_name: - doc: | - Title of measurement - \@check_sum: - type: NX_INT - doc: | - Integral of data as check of data integrity - data_errors(NX_NUMBER): - unit: NX_ANY - doc: | - 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. - dimensions: - rank: 4 - dim: [[1, nP], [2, i], [3, j], [4, tof]] - x_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in x-direction. - Can be multidimensional when needed. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - x-axis offset from detector center - y_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [2] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - z_pixel_offset(NX_FLOAT): - unit: NX_LENGTH - doc: | - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@axis: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [3] - \@primary: - type: NX_POSINT - deprecated: | - see: https://github.com/nexusformat/definitions/issues/436 - enumeration: [1] - \@long_name: - doc: | - y-axis offset from detector center - distance(NX_FLOAT): - unit: NX_LENGTH - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - polar_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - azimuthal_angle(NX_FLOAT): - unit: NX_ANGLE - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - description: - doc: | - name/manufacturer/model/etc. information - serial_number: - doc: | - Serial number for the detector - local_name: - doc: | - Local name for the detector - (NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the detector and NXoff_geometry to describe its shape instead - doc: | - Position and orientation of detector - solid_angle(NX_FLOAT): - unit: NX_SOLID_ANGLE - doc: | - Solid angle subtended by the detector at the sample - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - x_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - y_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each detector pixel. If it is scalar all pixels are the same size - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - Detector dead time - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - gas_pressure(NX_FLOAT): - unit: NX_PRESSURE - doc: | - Detector gas pressure - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - detection_gas_path(NX_FLOAT): - unit: NX_LENGTH - doc: | - maximum drift space dimension - crate(NX_INT): - doc: | - Crate number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - slot(NX_INT): - doc: | - Slot number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - input(NX_INT): - doc: | - Input number of detector - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - \@local_name: - doc: | - Equivalent local term - type: - doc: | - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - efficiency(NXdata): - doc: | - Spectral efficiency of detector with respect to e.g. wavelength - \@signal: - enumeration: [efficiency] - \@axes: - - # TODO: clarify the various use cases - enumeration: [., . ., . . ., . . . ., wavelength] - \@wavelength_indices: - - # TODO: clarify the actual possibilities - enumeration: [0] - efficiency(NX_FLOAT): - unit: NX_DIMENSIONLESS - doc: | - efficiency of the detector - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - wavelength(NX_FLOAT): - unit: NX_WAVELENGTH - doc: | - 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. - dimensions: - rank: 3 - dim: [[1, i], [2, j], [3, k]] - real_time(NX_NUMBER): - unit: NX_TIME - doc: | - 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). - dimensions: - rank: 3 - dim: [[1, nP], [2, i], [3, j]] - start_time(NX_FLOAT): - unit: NX_TIME - doc: | - start time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - stop_time(NX_FLOAT): - unit: NX_TIME - doc: | - stop time for each frame, with the ``start`` attribute as absolute reference - dimensions: - rank: 1 - dim: [[1, nP]] - \@start: - type: NX_DATE_TIME - calibration_date(NX_DATE_TIME): - doc: | - date of last calibration (geometry and/or efficiency) measurements - calibration_method(NXnote): - doc: | - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - layout: - doc: | - How the detector is represented - enumeration: [point, linear, area] - count_time(NX_NUMBER): - unit: NX_TIME - doc: | - Elapsed actual counting time - dimensions: - rank: 1 - dim: [[1, nP]] - data_file(NXnote): - (NXcollection): - doc: | - Use this group to provide other data related to this NXdetector group. - sequence_number(NX_INT): - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, nBrightFrames]] - beam_center_x(NX_FLOAT): - unit: NX_LENGTH - doc: | - 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. - beam_center_y(NX_FLOAT): - unit: NX_LENGTH - doc: | - 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. - frame_start_number(NX_INT): - doc: | - 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. - diameter(NX_FLOAT): - unit: NX_LENGTH - doc: | - The diameter of a cylindrical detector - acquisition_mode(NX_CHAR): - doc: | - The acquisition mode of the detector. - enumeration: [gated, triggered, summed, event, histogrammed, decimated] - angular_calibration_applied(NX_BOOLEAN): - doc: | - True when the angular calibration has been applied in the - electronics, false otherwise. - angular_calibration(NX_FLOAT): - doc: | - Angular calibration data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_applied(NX_BOOLEAN): - doc: | - True when the flat field correction has been applied in the - electronics, false otherwise. - flatfield(NX_FLOAT): - doc: | - Flat field correction data. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - flatfield_errors(NX_FLOAT): - doc: | - Errors of the flat field correction data. - The form flatfield_error is deprecated. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - pixel_mask_applied(NX_BOOLEAN): - doc: | - True when the pixel mask correction has been applied in the - electronics, false otherwise. - pixel_mask(NX_INT): - doc: | - 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. - dimensions: - rank: 2 - dim: [[1, i], [2, j]] - image_key(NX_INT): - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, np]] - countrate_correction_applied(NX_BOOLEAN): - doc: | - 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(NX_NUMBER): - doc: | - 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. - dimensions: - rank: 1 - dim: [[1, m]] - virtual_pixel_interpolation_applied(NX_BOOLEAN): - doc: | - 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(NX_INT): - doc: | - 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, ... - detector_readout_time(NX_FLOAT): - unit: NX_TIME - doc: | - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - trigger_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - 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. - trigger_delay_time_set(NX_FLOAT): - unit: NX_TIME - doc: | - User-specified trigger delay. - trigger_internal_delay_time(NX_FLOAT): - unit: NX_TIME - doc: | - 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. - trigger_dead_time(NX_FLOAT): - unit: NX_TIME - doc: | - 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. - frame_time(NX_FLOAT): - unit: NX_TIME - doc: | - This is time for each frame. This is exposure_time + readout time. - dimensions: - rank: 1 - dim: [[1, nP]] - gain_setting(NX_CHAR): - doc: | - 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. - saturation_value(NX_NUMBER): - doc: | - 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. - underload_value(NX_NUMBER): - doc: | - 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. - number_of_cycles(NX_INT): - doc: | - 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. - sensor_material(NX_CHAR): - doc: | - 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(NX_FLOAT): - unit: NX_LENGTH - doc: | - 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(NX_FLOAT): - unit: NX_ENERGY - doc: | - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - (NXdetector_module): - doc: | - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - pixel_shape(choice): - (NXoff_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - detector_shape(choice): - (NXoff_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - (NXcylindrical_geometry): - doc: | - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - \@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. - amplifier_type(NX_CHAR): - doc: | - Type of electron amplifier, MCP, channeltron, etc. - detector_type(NX_CHAR): - doc: | - Description of the detector type, DLD, Phosphor+CCD, CMOS. - detector_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to detector. - amplifier_voltage(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - Voltage applied to the amplifier. - amplifier_bias(NX_FLOAT): - unit: NX_VOLTAGE - doc: | - The low voltage of the amplifier migh not be the ground. - sensor_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Size of each imaging sensor chip on the detector. - sensor_count(NX_INT): - unit: NX_UNITLESS - doc: | - Number of imaging sensor chips on the detector. - sensor_pixel_size(NX_FLOAT): - unit: NX_LENGTH - doc: | - Physical size of the pixels of the imaging chip on the detector. - sensor_pixels(NX_INT): - unit: NX_UNITLESS - doc: | - Number of raw active elements in each dimension. Important for swept scans. - (NXfabrication): - (NXdata): - doc: | - raw data output from the detector - 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 detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - (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 ++++++++++++++++++++++++++++++++++ -# 6b256ef0615dca7d8faf4a3bc04d3e62f29a1745e9cd35205e5f0bb9e2c6520c -# -# -# -# -# -# -# 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. -# -# -# -# -# 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. -# -# -# -# -# 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 -# -# -# -# -# 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/NXsensor.yaml b/contributed_definitions/nyaml/NXsensor.yaml deleted file mode 100644 index a70f2a533e..0000000000 --- a/contributed_definitions/nyaml/NXsensor.yaml +++ /dev/null @@ -1,324 +0,0 @@ -category: base -doc: | - A sensor used to monitor an external condition - - The condition itself is described in :ref:`NXenvironment`. -type: group -NXsensor(NXobject): - model: - doc: | - Sensor identification code/model number - name: - doc: | - Name for the sensor - short_name: - doc: | - Short name of sensor used e.g. on monitor display program - attached_to: - doc: | - where sensor is attached to ("sample" | "can") - geometry(NXgeometry): - deprecated: | - Use the field `depends_on` and :ref:`NXtransformations` to position the beamstop and NXoff_geometry to describe its shape instead - doc: | - Defines the axes for logged vector quantities if they are not the global instrument axes. - measurement: - doc: | - name for measured signal - enumeration: [temperature, pH, magnetic_field, electric_field, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] - type: - doc: | - The type of hardware used for the measurement. - Examples (suggestions but not restrictions): - - :Temperature: - J | K | T | E | R | S | Pt100 | Rh/Fe - :pH: - Hg/Hg2Cl2 | Ag/AgCl | ISFET - :Ion selective electrode: - specify species; e.g. Ca2+ - :Magnetic field: - Hall - :Surface pressure: - wilhelmy plate - run_control(NX_BOOLEAN): - doc: | - Is data collection controlled or synchronised to this quantity: - 1=no, 0=to "value", 1=to "value_deriv1", etc. - high_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Upper control bound of sensor reading if using run_control - low_trip_value(NX_FLOAT): - unit: NX_ANY - doc: | - Lower control bound of sensor reading if using run_control - value(NX_FLOAT): - unit: NX_ANY - doc: | - nominal setpoint or average value - - need [n] as may be a vector - dimensions: - dim: [[1, n]] - value_deriv1(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average first derivative of value - e.g. strain rate - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_deriv2(NX_FLOAT): - unit: NX_ANY - doc: | - Nominal/average second derivative of value - - same dimensions as "value" (may be a vector) - dimensions: - dim: [[1, ]] - dim_parameters: - ref: ['value'] - value_log(NXlog): - doc: | - Time history of sensor readings - value_deriv1_log(NXlog): - doc: | - Time history of first derivative of sensor readings - value_deriv2_log(NXlog): - doc: | - Time history of second derivative of sensor readings - external_field_brief: - enumeration: [along beam, across beam, transverse, solenoidal, flow shear gradient, flow vorticity] - external_field_full(NXorientation): - doc: | - For complex external fields not satisfied by External_field_brief - (NXoff_geometry): - exists: ['min', '0'] - doc: | - This group describes the shape of the sensor when necessary. - (NXfabrication): - \@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. - - .. todo:: - Add a definition for the reference point of a sensor. - (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 ++++++++++++++++++++++++++++++++++ -# df8bc397cbcbf114091b84ed357f6312641ca9abbf2d51795c37802450e7e628 -# -# -# -# -# -# A sensor used to monitor an external condition -# -# The condition itself is described in :ref:`NXenvironment`. -# -# -# Sensor identification code/model number -# -# -# Name for the sensor -# -# -# Short name of sensor used e.g. on monitor display program -# -# -# where sensor is attached to ("sample" | "can") -# -# -# -# Defines the axes for logged vector quantities if they are not the global instrument axes. -# -# -# -# name for measured signal -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The type of hardware used for the measurement. -# Examples (suggestions but not restrictions): -# -# :Temperature: -# J | K | T | E | R | S | Pt100 | Rh/Fe -# :pH: -# Hg/Hg2Cl2 | Ag/AgCl | ISFET -# :Ion selective electrode: -# specify species; e.g. Ca2+ -# :Magnetic field: -# Hall -# :Surface pressure: -# wilhelmy plate -# -# -# -# -# Is data collection controlled or synchronised to this quantity: -# 1=no, 0=to "value", 1=to "value_deriv1", etc. -# -# -# -# -# Upper control bound of sensor reading if using run_control -# -# -# -# -# Lower control bound of sensor reading if using run_control -# -# -# -# -# nominal setpoint or average value -# - need [n] as may be a vector -# -# -# -# -# -# -# -# Nominal/average first derivative of value -# e.g. strain rate -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# -# Nominal/average second derivative of value -# - same dimensions as "value" (may be a vector) -# -# -# -# -# -# -# Time history of sensor readings -# -# -# Time history of first derivative of sensor readings -# -# -# Time history of second derivative of sensor readings -# -# -# -# -# -# -# -# -# -# -# -# -# For complex external fields not satisfied by External_field_brief -# -# -# -# This group describes the shape of the sensor when necessary. -# -# -# -# -# .. 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. -# -# .. todo:: -# Add a definition for the reference point of a sensor. -# -# -# -# -# -# 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/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. -# -# -#