From 669c018dbe508a49a9b005b28863a8c799867e7a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 22 Sep 2023 16:08:48 +0200 Subject: [PATCH 01/29] Add NXactuator base class # Conflicts: # base_classes/NXenvironment.nxdl.xml # base_classes/NXinstrument.nxdl.xml # base_classes/nyaml/NXinstrument.yaml # contributed_definitions/NXmanipulator.nxdl.xml # contributed_definitions/NXmpes.nxdl.xml # contributed_definitions/nyaml/NXmanipulator.yaml # contributed_definitions/nyaml/NXmpes.yaml --- base_classes/NXenvironment.nxdl.xml | 62 +++++++++++++++++------------ 1 file changed, 37 insertions(+), 25 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 4f878263b2..1b29320fe2 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -1,9 +1,9 @@ - + - - Parameters for controlling external conditions + + + Parameters for controlling external conditions + - Apparatus identification code/model number; e.g. OC100 011 + + Apparatus identification code/model number; e.g. OC100 011 + - Alternative short name, perhaps for dashboard display like a present Seblock name + + Alternative short name, perhaps for dashboard display like a present Seblock + name + - Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 + + Type of apparatus. This could be the SE codes in scheduling database; e.g. + OC/100 + - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump + - Program controlling the apparatus; e.g. LabView VI name + + Program controlling the apparatus; e.g. LabView VI name + @@ -50,25 +60,27 @@ - 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. + 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. - 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. + 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. - Additional information, LabView logs, digital photographs, etc + + Additional information, LabView logs, digital photographs, etc + + - From 02819a4455360cb36855b9e9c978fb549d69f410 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 14:09:08 +0100 Subject: [PATCH 02/29] make NXenvironment.nxdl.xml --- base_classes/NXenvironment.nxdl.xml | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 1b29320fe2..42017ad26c 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -1,10 +1,10 @@ - + - - - Parameters for controlling external conditions - + + Parameters for controlling external conditions - - Apparatus identification code/model number; e.g. OC100 011 - + Apparatus identification code/model number; e.g. OC100 011 - - Alternative short name, perhaps for dashboard display like a present Seblock - name - + Alternative short name, perhaps for dashboard display like a present Seblock name - - Type of apparatus. This could be the SE codes in scheduling database; e.g. - OC/100 - + Type of apparatus. This could be the SE codes in scheduling database; e.g. OC/100 - - Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - + Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump - - Program controlling the apparatus; e.g. LabView VI name - + Program controlling the apparatus; e.g. LabView VI name @@ -64,33 +54,31 @@ 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 - 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. + 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. - 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. + 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. - - Additional information, LabView logs, digital photographs, etc - + Additional information, LabView logs, digital photographs, etc @@ -107,10 +95,10 @@ .. 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 From 90ee8c96adaf832ca250904048f648f4264dfeef Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 18:38:03 +0200 Subject: [PATCH 09/29] revert unintentional changes from cherry-pick --- Makefile | 21 +++++++++++++++++-- .../NXcollectioncolumn.nxdl.xml | 13 ------------ .../NXelectronanalyser.nxdl.xml | 13 ------------ 3 files changed, 19 insertions(+), 28 deletions(-) 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/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 6002fc530b..5348d55b5f 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -85,19 +85,6 @@ the reference coordinate system. - - - .. 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. - - The size and position of an aperture inserted in the column, e.g. field aperture diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index e8eeacd342..db991447d2 100644 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ b/contributed_definitions/NXelectronanalyser.nxdl.xml @@ -124,19 +124,6 @@ should relate to the reference coordinate system. - - - .. 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. - - Describes the electron collection (spatial and momentum imaging) column From 5a8d6d6f0135ad36562e0b03b63e75c09c430b35 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 18:39:22 +0200 Subject: [PATCH 10/29] --- base_classes/NXactuator.nxdl.xml | 127 ++++++++++++++++++++++++++++ base_classes/NXenvironment.nxdl.xml | 44 ++-------- base_classes/NXfabrication.nxdl.xml | 70 +++++++++++++++ 3 files changed, 202 insertions(+), 39 deletions(-) create mode 100644 base_classes/NXactuator.nxdl.xml create mode 100644 base_classes/NXfabrication.nxdl.xml diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml new file mode 100644 index 0000000000..3fe0a4108f --- /dev/null +++ b/base_classes/NXactuator.nxdl.xml @@ -0,0 +1,127 @@ + + + + + + An actuator used to control an external condition. + + The condition itself is described in :ref:`NXenvironment`. + + + + Actuator identification code/model number + + + + + Name of the actuator + + + + + Short name of actuator used e.g. on monitor display program + + + + + Describe where the actuator is attached to. + This could be an instance of NXsample or a device on NXinstrument. + + + + + Name for the physical quantity effected by the actuation + + Examples: + temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | + pressure | flow | stress | strain | shear | surface_pressure + + + + + The type of hardware used for the actuation. + + Examples (suggestions, but not restrictions): + + :Temperature: laser | gas lamp | filament | resistive + :Pressure: anvil cell + :Voltage: potentiostat + + + + + Any output that the actuator produces. + For example, a heater can have the field heater_power(NX_FLOAT). + + + + + Time history of actuator outputs. + + + + + If the actuator is PID-controlled, the settings of the PID controller can be + stored here. + + + + Nominal actuator setpoint. + Can be a scalar or a vector (of [n] actuations). + + + + + Time history of actuator setpoints. + + + + + + Refers to the last transformation specifying the position of the actuator + in the NXtransformations chain. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the actuator within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + .. 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/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index d7e060b7af..4f878263b2 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -2,9 +2,9 @@ + + + Details about a component as it is defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + If different versions exist are possible, the value in this field should be made + specific enough to resolve the version. + + + + + + Ideally, (globally) unique persistent identifier. This may contain e.g. a hash + identifier of the component. + + + + + Serial number of the component. + + + + + Datetime of components initial construction. This refers to the date of + first measurement after new construction or to the relocation date, + if it describes a multicomponent/custom-build setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + From 6bf33c30e7961e9540d76b58a68181acc168608b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 27 Sep 2023 12:24:48 +0200 Subject: [PATCH 11/29] Add NXfabrication to all MPES instrument-related base classes # Conflicts: # base_classes/NXdetector.nxdl.xml # base_classes/NXinstrument.nxdl.xml # base_classes/NXsensor.nxdl.xml # base_classes/NXsource.nxdl.xml --- base_classes/NXsensor.nxdl.xml | 332 ++-- base_classes/nyaml/NXdetector.yaml | 1758 +++++++++++++++++ base_classes/nyaml/NXinstrument.yaml | 190 ++ base_classes/nyaml/NXsensor.yaml | 324 +++ base_classes/nyaml/NXsource.yaml | 521 +++++ .../NXcollectioncolumn.nxdl.xml | 1 + .../NXelectronanalyser.nxdl.xml | 3 +- .../NXenergydispersion.nxdl.xml | 3 +- .../NXmanipulator.nxdl.xml | 3 +- contributed_definitions/nyaml/NXdetector.yaml | 1758 +++++++++++++++++ .../nyaml/NXinstrument.yaml | 190 ++ contributed_definitions/nyaml/NXsensor.yaml | 324 +++ contributed_definitions/nyaml/NXsource.yaml | 521 +++++ 13 files changed, 5766 insertions(+), 162 deletions(-) create mode 100644 base_classes/nyaml/NXdetector.yaml create mode 100644 base_classes/nyaml/NXinstrument.yaml create mode 100644 base_classes/nyaml/NXsensor.yaml create mode 100644 base_classes/nyaml/NXsource.yaml create mode 100644 contributed_definitions/nyaml/NXdetector.yaml create mode 100644 contributed_definitions/nyaml/NXinstrument.yaml create mode 100644 contributed_definitions/nyaml/NXsensor.yaml create mode 100644 contributed_definitions/nyaml/NXsource.yaml diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 5917c370f3..b020a4bb8e 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -1,9 +1,9 @@ - + - - - 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. - - + + + 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. + .. 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. - + 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. + 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/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml new file mode 100644 index 0000000000..8fd286fc58 --- /dev/null +++ b/base_classes/nyaml/NXdetector.yaml @@ -0,0 +1,1758 @@ +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/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml new file mode 100644 index 0000000000..4607aa5ae5 --- /dev/null +++ b/base_classes/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +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/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml new file mode 100644 index 0000000000..a70f2a533e --- /dev/null +++ b/base_classes/nyaml/NXsensor.yaml @@ -0,0 +1,324 @@ +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/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml new file mode 100644 index 0000000000..1692b666ea --- /dev/null +++ b/base_classes/nyaml/NXsource.yaml @@ -0,0 +1,521 @@ +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. +# +# +# diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 5348d55b5f..0de6103994 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -101,4 +101,5 @@ Individual lenses in the collection column section + diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index db991447d2..5ad424d384 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,4 +154,5 @@ 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 3207888517..03fb871c8e 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,4 +87,5 @@ Individual lenses in the energy dispersive section + diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml index dff2584fcf..b412effe62 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,6 +79,7 @@ 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 new file mode 100644 index 0000000000..8fd286fc58 --- /dev/null +++ b/contributed_definitions/nyaml/NXdetector.yaml @@ -0,0 +1,1758 @@ +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 new file mode 100644 index 0000000000..4607aa5ae5 --- /dev/null +++ b/contributed_definitions/nyaml/NXinstrument.yaml @@ -0,0 +1,190 @@ +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 new file mode 100644 index 0000000000..a70f2a533e --- /dev/null +++ b/contributed_definitions/nyaml/NXsensor.yaml @@ -0,0 +1,324 @@ +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 new file mode 100644 index 0000000000..1692b666ea --- /dev/null +++ b/contributed_definitions/nyaml/NXsource.yaml @@ -0,0 +1,521 @@ +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. +# +# +# From 66f0edc99703d3c7d3176860d1cf78d014fc3fad Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Fri, 5 Jan 2024 14:13:05 +0100 Subject: [PATCH 12/29] make nxdls # Conflicts: # base_classes/NXinstrument.nxdl.xml # base_classes/nyaml/NXenvironment.yaml --- base_classes/NXsensor.nxdl.xml | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index b020a4bb8e..789c839022 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -1,10 +1,10 @@ - + - - - 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. - - + + + 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. + .. 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. + 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. + 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/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml deleted file mode 100644 index 8fd286fc58..0000000000 --- a/base_classes/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/base_classes/nyaml/NXinstrument.yaml b/base_classes/nyaml/NXinstrument.yaml deleted file mode 100644 index 4607aa5ae5..0000000000 --- a/base_classes/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/base_classes/nyaml/NXsensor.yaml b/base_classes/nyaml/NXsensor.yaml deleted file mode 100644 index a70f2a533e..0000000000 --- a/base_classes/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/base_classes/nyaml/NXsource.yaml b/base_classes/nyaml/NXsource.yaml deleted file mode 100644 index 1692b666ea..0000000000 --- a/base_classes/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. -# -# -# From 22867024124480270cf37cd4351dbe6e34b1f600 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 18:39:41 +0200 Subject: [PATCH 16/29] revert unintentional changes from cherry-pick bring back files lost during cherry pick --- Makefile | 21 +- base_classes/NXenvironment.nxdl.xml | 38 +- .../NXcollectioncolumn.nxdl.xml | 1 - .../NXelectronanalyser.nxdl.xml | 3 +- .../NXenergydispersion.nxdl.xml | 3 +- .../NXmanipulator.nxdl.xml | 3 +- contributed_definitions/nyaml/NXdetector.yaml | 1758 ----------------- .../nyaml/NXinstrument.yaml | 190 -- contributed_definitions/nyaml/NXsensor.yaml | 324 --- contributed_definitions/nyaml/NXsource.yaml | 521 ----- 10 files changed, 58 insertions(+), 2804 deletions(-) delete mode 100644 contributed_definitions/nyaml/NXdetector.yaml delete mode 100644 contributed_definitions/nyaml/NXinstrument.yaml delete mode 100644 contributed_definitions/nyaml/NXsensor.yaml delete mode 100644 contributed_definitions/nyaml/NXsource.yaml 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. -# -# -# From d814a87f6d98cb1a484d703f4c640d108ef9c2c8 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 19:06:44 +0200 Subject: [PATCH 17/29] move NXfabrication to base_classes --- .../NXfabrication.nxdl.xml | 51 ------------------- 1 file changed, 51 deletions(-) delete mode 100644 contributed_definitions/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/contributed_definitions/NXfabrication.nxdl.xml deleted file mode 100644 index 1f940f0795..0000000000 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ /dev/null @@ -1,51 +0,0 @@ - - - - - - Details about a component as defined by its manufacturer. - - - - Company name of the manufacturer. - - - - - Version or model of the component named by the manufacturer. - - - - - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. - - - - - Free-text list with eventually multiple terms of - functionalities which the component offers. - - - - From ca0479a13f6aaf180184d75cb658c771d40c55b9 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Mon, 23 Sep 2024 19:14:40 +0200 Subject: [PATCH 18/29] bring in NXidentifier --- base_classes/NXidentifier.nxdl.xml | 49 ++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 base_classes/NXidentifier.nxdl.xml diff --git a/base_classes/NXidentifier.nxdl.xml b/base_classes/NXidentifier.nxdl.xml new file mode 100644 index 0000000000..ce05800f9e --- /dev/null +++ b/base_classes/NXidentifier.nxdl.xml @@ -0,0 +1,49 @@ + + + + + + An identifier for a (persistent) resource, e.g., a DOI or orcid. + + + + The service by which the resource can be resolved. + + Examples: doi, urn, hdl, purl, orcid, iso, url + + + + + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. + + + + + True if the identifier is persistent (i.e., unique and available indefinitely), + False otherwise. + + + From 86794070faa847fcf3ef191ac21a9855d122eebd Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:14:02 +0200 Subject: [PATCH 19/29] Apply suggestions from NIAC review Co-authored-by: Aaron S. Brewster --- base_classes/NXfabrication.nxdl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml index 76f48e3b84..a74d963c20 100644 --- a/base_classes/NXfabrication.nxdl.xml +++ b/base_classes/NXfabrication.nxdl.xml @@ -36,7 +36,7 @@ - If different versions exist are possible, the value in this field should be made + If it is possible that different versions exist, the value in this field should be made specific enough to resolve the version. @@ -54,7 +54,7 @@ - Datetime of components initial construction. This refers to the date of + Datetime of component's initial construction. This refers to the date of first measurement after new construction or to the relocation date, if it describes a multicomponent/custom-build setup. Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, From 838b85866b7aadc19809c27a4b62c5f80927432f Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:16:00 +0200 Subject: [PATCH 20/29] reviewed changes to NXfabrication --- base_classes/NXfabrication.nxdl.xml | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml index a74d963c20..49bd2fb7c2 100644 --- a/base_classes/NXfabrication.nxdl.xml +++ b/base_classes/NXfabrication.nxdl.xml @@ -41,12 +41,6 @@ - - - Ideally, (globally) unique persistent identifier. This may contain e.g. a hash - identifier of the component. - - Serial number of the component. @@ -57,14 +51,12 @@ Datetime of component's initial construction. This refers to the date of first measurement after new construction or to the relocation date, if it describes a multicomponent/custom-build setup. - Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, - otherwise the local time zone is assumed per ISO8601. + It is recommended to add an explicit time zone. - Free-text list with eventually multiple terms of - functionalities which the component offers. + Free-text list of functionalities which the component offers. From c0388470866334e9904a3e2e192ea135e9102e7b Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:16:33 +0200 Subject: [PATCH 21/29] remove NXidentifier --- base_classes/NXidentifier.nxdl.xml | 49 ------------------------------ 1 file changed, 49 deletions(-) delete mode 100644 base_classes/NXidentifier.nxdl.xml diff --git a/base_classes/NXidentifier.nxdl.xml b/base_classes/NXidentifier.nxdl.xml deleted file mode 100644 index ce05800f9e..0000000000 --- a/base_classes/NXidentifier.nxdl.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - - - An identifier for a (persistent) resource, e.g., a DOI or orcid. - - - - The service by which the resource can be resolved. - - Examples: doi, urn, hdl, purl, orcid, iso, url - - - - - The unique code, IRI or hash to resolve this reference. - Typically, this is stated by the service which is considered a complete - identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` - or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. - - - - - True if the identifier is persistent (i.e., unique and available indefinitely), - False otherwise. - - - From 05f5c72a23d38fa6064dd4670f914c23429b48f4 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:23:08 +0200 Subject: [PATCH 22/29] move NXpid to base_classes --- .../NXpid.nxdl.xml | 20 +++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) rename {contributed_definitions => base_classes}/NXpid.nxdl.xml (80%) diff --git a/contributed_definitions/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml similarity index 80% rename from contributed_definitions/NXpid.nxdl.xml rename to base_classes/NXpid.nxdl.xml index 62fad3f835..cc7c3d887c 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/base_classes/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -59,6 +59,10 @@ that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. + The Type switches controller parameters between P/I (proportional gain/integral gain) + and P/T (proportional gain/time constant). The formula for the controller in the + frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time + constant are related as follows I = P/T. @@ -81,4 +85,12 @@ action is termed the derivative gain, K_d + + + The Type switches controller parameters between P/I (proportional gain/integral + gain) and P/T (proportional gain/time constant). The formula for the controller + in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and + time constant are related as follows I = P/T. + + From 5a7f7304c3035c013e06c8591884ab57ba3b95da Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:36:27 +0200 Subject: [PATCH 23/29] implement suggestions on NXactuator --- base_classes/NXactuator.nxdl.xml | 23 +---------------------- base_classes/NXpid.nxdl.xml | 14 +------------- 2 files changed, 2 insertions(+), 35 deletions(-) diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index 3fe0a4108f..0431c00a18 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -27,11 +27,6 @@ The condition itself is described in :ref:`NXenvironment`. - - - Actuator identification code/model number - - Name of the actuator @@ -68,33 +63,17 @@ :Voltage: potentiostat - + Any output that the actuator produces. For example, a heater can have the field heater_power(NX_FLOAT). - - - Time history of actuator outputs. - - If the actuator is PID-controlled, the settings of the PID controller can be stored here. - - - Nominal actuator setpoint. - Can be a scalar or a vector (of [n] actuations). - - - - - Time history of actuator setpoints. - - diff --git a/base_classes/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml index cc7c3d887c..d7f8f471b3 100644 --- a/base_classes/NXpid.nxdl.xml +++ b/base_classes/NXpid.nxdl.xml @@ -59,10 +59,6 @@ that is proportional to the current error value. The proportional response can be adjusted by multiplying the error by a constant Kp, called the proportional gain constant. - The Type switches controller parameters between P/I (proportional gain/integral gain) - and P/T (proportional gain/time constant). The formula for the controller in the - frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and time - constant are related as follows I = P/T. @@ -82,15 +78,7 @@ the slope of the error over time and multiplying this rate of change by the derivative gain K_d. The magnitude of the contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - - - - - The Type switches controller parameters between P/I (proportional gain/integral - gain) and P/T (proportional gain/time constant). The formula for the controller - in the frequency domain is G(s) = P + I/s = P(1 + 1/(Ts)). The integral gain and - time constant are related as follows I = P/T. + action is termed the derivative gain, K_d. From 2a26f2a6bf9d48f1facc65018d1845ab5367dc25 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:38:01 +0200 Subject: [PATCH 24/29] remove default from NXenvironment --- base_classes/NXenvironment.nxdl.xml | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 74ed194f03..91ba2549e1 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -92,17 +92,4 @@ 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. - - From 1820ea080ad64d8355e4b10d265266f95efda2f1 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Tue, 1 Oct 2024 11:42:38 +0200 Subject: [PATCH 25/29] remove default from NXactuator --- base_classes/NXactuator.nxdl.xml | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index 0431c00a18..9c96a03151 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -89,18 +89,5 @@ other component groups. - - - .. 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. - - From eed11b20b51fd1edafae96b07d4f35bfc1920b4a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Dec 2024 13:41:28 +0100 Subject: [PATCH 26/29] remove NXpid --- base_classes/NXactuator.nxdl.xml | 6 --- base_classes/NXpid.nxdl.xml | 84 -------------------------------- 2 files changed, 90 deletions(-) delete mode 100644 base_classes/NXpid.nxdl.xml diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index 9c96a03151..c8553f2dad 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -69,12 +69,6 @@ For example, a heater can have the field heater_power(NX_FLOAT). - - - If the actuator is PID-controlled, the settings of the PID controller can be - stored here. - - Refers to the last transformation specifying the position of the actuator diff --git a/base_classes/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml deleted file mode 100644 index d7f8f471b3..0000000000 --- a/base_classes/NXpid.nxdl.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - Contains the settings of a PID controller. - - - - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - - - - - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - - - - - The actual timeseries data fed back to the PID loop. - - - - - - - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - - - - - Proportional term. The proportional term produces an output value - that is proportional to the current error value. - The proportional response can be adjusted by multiplying the error - by a constant Kp, called the proportional gain constant. - - - - - The contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - - - - - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d. - - - From d2139bef0704bf140e3f9b0ffa47fa07a56692e1 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Wed, 11 Dec 2024 13:42:56 +0100 Subject: [PATCH 27/29] restore NXpid in contributed --- contributed_definitions/NXpid.nxdl.xml | 84 ++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) create mode 100644 contributed_definitions/NXpid.nxdl.xml diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml new file mode 100644 index 0000000000..62fad3f835 --- /dev/null +++ b/contributed_definitions/NXpid.nxdl.xml @@ -0,0 +1,84 @@ + + + + + + Contains the settings of a PID controller. + + + + Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. + + For example, a set of sensors could be averaged over before feeding it back into the loop. + + + + + The sensor representing the Process Value used in the feedback loop for the PID. + + In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. + + + + + The actual timeseries data fed back to the PID loop. + + + + + + + The Setpoint(s) used as an input for the PID controller. + + It can also be a link to an NXsensor.value field. + + + + + Proportional term. The proportional term produces an output value + that is proportional to the current error value. + The proportional response can be adjusted by multiplying the error + by a constant Kp, called the proportional gain constant. + + + + + The contribution from the integral term is proportional to both + the magnitude of the error and the duration of the error. + The integral in a PID controller is the sum of the instantaneous + error over time and gives the accumulated offset that should have + been corrected previously. The accumulated error is then + multiplied by the integral gain (Ki) and added to the + controller output. + + + + + The derivative of the process error is calculated by determining + the slope of the error over time and multiplying this rate of + change by the derivative gain K_d. The magnitude of the + contribution of the derivative term to the overall control + action is termed the derivative gain, K_d + + + From 14532fa12c5f91b516c8015cbf63838865a9950a Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Dec 2024 12:00:27 +0100 Subject: [PATCH 28/29] Apply suggestions from code review Co-authored-by: Aaron S. Brewster --- base_classes/NXactuator.nxdl.xml | 4 ++-- base_classes/NXfabrication.nxdl.xml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index c8553f2dad..067ce74d56 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -63,10 +63,10 @@ :Voltage: potentiostat - + Any output that the actuator produces. - For example, a heater can have the field heater_power(NX_FLOAT). + For example, a heater can have the field output_power(NX_NUMBER). diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml index 49bd2fb7c2..a3e3cfc91d 100644 --- a/base_classes/NXfabrication.nxdl.xml +++ b/base_classes/NXfabrication.nxdl.xml @@ -46,12 +46,12 @@ Serial number of the component. - + Datetime of component's initial construction. This refers to the date of first measurement after new construction or to the relocation date, if it describes a multicomponent/custom-build setup. - It is recommended to add an explicit time zone. + Just the year is often sufficient, but if a full date/time is used, it is recommended to add an explicit time zone. From f1445708ce19cb5fdd4df8065fcdc63aa5071ac5 Mon Sep 17 00:00:00 2001 From: Lukas Pielsticker <50139597+lukaspie@users.noreply.github.com> Date: Thu, 19 Dec 2024 12:04:51 +0100 Subject: [PATCH 29/29] actuation_target in NXactuator --- base_classes/NXactuator.nxdl.xml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml index 067ce74d56..2223c6ed23 100644 --- a/base_classes/NXactuator.nxdl.xml +++ b/base_classes/NXactuator.nxdl.xml @@ -37,10 +37,11 @@ Short name of actuator used e.g. on monitor display program - + - Describe where the actuator is attached to. - This could be an instance of NXsample or a device on NXinstrument. + The physical component on which this actuator acts. + This should be a path in the NeXus tree structure. + For example, this could be an instance of NXsample or a device on NXinstrument.