diff --git a/.github/workflows/validate.yaml b/.github/workflows/validate.yaml index 6c52e36367..94c3a0e0b8 100644 --- a/.github/workflows/validate.yaml +++ b/.github/workflows/validate.yaml @@ -36,4 +36,4 @@ jobs: - name: validate run: | - python -m dev_tools nxtest \ No newline at end of file + python -m dev_tools nxtest diff --git a/.gitignore b/.gitignore index 3fd234f70f..779dba46c3 100644 --- a/.gitignore +++ b/.gitignore @@ -9,6 +9,7 @@ __pycache__/ # Build artifacts build/ makelog.txt +# nyaml/ # Distribution / packaging .Python @@ -30,4 +31,10 @@ share/python-wheels/ *.egg MANIFEST -*_parsed.yaml \ No newline at end of file +*_parsed.yaml +# Unknown +/python/ +__github_creds__.txt + +# used locally to validate nxdl.xsd and nxdlTypes.xsd +XMLSchema.xsd diff --git a/CHANGES.rst b/CHANGES.rst index de734d0974..7527dadcc3 100644 --- a/CHANGES.rst +++ b/CHANGES.rst @@ -21,11 +21,41 @@ Highlights of each release are described below. For more details, see our wiki (https://github.com/nexusformat/definitions/wiki/Release-Notes) which provides links to the Release Notes (itemized list of changes) for any release. +.. incoming change for next release -v2023.06 + v2025.mm + ++++++++ + + for release sometime in *2025* + + Maintenance + ----------- + + * Add nameType="partial" to NXDL schema. + * Use 'nameType' attribute in fields, groups, and attributes. + +v2024.02 ++++++++ -expected *2023-06* +released *2024-02-09* + +This release is the result of a NIAC meeting in 2022-09, +NeXus Code Camps in 2022-06 and 2023-06, +and substantial work by the NeXus Community, the FAIRmat consortium and NIAC members. + +Summary statistics from the GitHub definitions repository show +this activity since the (previous) v2022.07 release: + +============= ======== +activity quantity +============= ======== +Pull Requests 67 +Issues 34 +Commits 413 +============= ======== + +See the wiki for more details: +https://github.com/nexusformat/definitions/wiki/releasenotes__v2024.02 New Features ------------ @@ -37,31 +67,68 @@ recommendation that this attribute be specified. NXxas: Added `NXdata/mode` to report detection method. +Add various flux fields to NXbeam. + +Add virtual pixel handling to NXdetector. + +Add h5py example scripts. + +Add equipment_component attribute to NXtransformations. + +Add countrate_correction_lookup_table to NXdetector for NXmx. + +Allow axis fields to be numbers or strings and add a default_slice attribute to NXdata. + +Add new NXdetector_channel base class. + +Add favicon to manual web pages. + +Add many new contributed definitions from FAIRmat. + +Allow NeXus definitions to be created with YAML. + +Add recent contributors links to NeXus classes html pages. + +Improve link navigation in application definition items and collapse doc strings. + + Fixes ----------- -Added missing close parenthesis in rendering of suggested target. +Add missing close parenthesis in rendering of suggested target. + +Amend text that mistakenly deprecated NXaperture. + +Generalize NXsource type for electron sources. Maintenance ----------- -NXdata: clarify how errors are described in documentation. +NXdata: clarify how errors are described in documentation; remove obsolete dimension +index attribute; clarify that attributes that name other fields must be existing +children of group; improve documentation on axes. -NXmx: clarify pixel size. +NXmx: clarify pixel size, update NXbeam documentation on incident_wavelength_spectrum, +make countrate_correction_lookup_table optional -NXsas: Various fields and groups changed to optional. Only those deemed +NXsas: Various fields and groups changed to optional. Only those deemed necessary for data reduction are required. -NXtransformations: Add ``equipment_component`` attribute +NXtransformations: Add ``equipment_component`` attribute. NXxas: `data` fields` changed from `NX_INT` to `NX_NUMBER`. -NXxpcs: clarify use of ``entry_identifier``, ``entry_identifier_uuid``, and ``scan_number``. +NXxpcs: clarify use of ``entry_identifier``, ``entry_identifier_uuid``, and ``scan_number``; +fix some units. + +Clarify how NXbeam can be in NXinstrument groups or NXsample. + + Deprecations ------------ -NXdata: deprecate `errors` field in favor of `VARIABLE_errors` for the signal field. +NXdata: deprecate `errors` field in favor of `FIELDNAME_errors` for the signal field. .. Contributors diff --git a/Makefile b/Makefile index 78f3af7719..2555d073aa 100644 --- a/Makefile +++ b/Makefile @@ -117,7 +117,7 @@ nyaml: # 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 diff --git a/NXDL_VERSION b/NXDL_VERSION index ff7b2777d4..670d92f8f3 100644 --- a/NXDL_VERSION +++ b/NXDL_VERSION @@ -1 +1 @@ -v2022.07 +v2024.02 diff --git a/applications/NXarchive.nxdl.xml b/applications/NXarchive.nxdl.xml index 79b41857b1..650847b804 100644 --- a/applications/NXarchive.nxdl.xml +++ b/applications/NXarchive.nxdl.xml @@ -3,7 +3,7 @@ - - - This is an application definition for angular resolved photo electron spectroscopy. - - It has been drawn up with hemispherical electron analysers in mind. - - This definition is a legacy support for older NXarpes experiments. - There is, however, a newer definition to collect data & metadata - for general photoemission experiments, called :ref:NXmpes, - as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." - - - - - NeXus convention is to use "entry1", "entry2", ... - for analysis software to locate each entry. - - - - - - - Official NeXus NXDL schema to which this file conforms. - - - - + + + This is an application definition for angular resolved photo electron spectroscopy. + + It has been drawn up with hemispherical electron analysers in mind. + + This definition is a legacy support for older NXarpes experiments. + There is, however, a newer definition to collect data & metadata + for general photoemission experiments, called :ref:NXmpes, + as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." + + + + + + Official NeXus NXDL schema to which this file conforms. + + + + + + + + + + + + + + + + + + + + + setting for the electron analyser lens + + + + + + + + + + + + + + + dial setting of the entrance slit + + + size of the entrance slit + + + energy of the electrons on the mean path of the analyser - - - - - - - - - - - - - - - - - - setting for the electron analyser lens - - - - - - - - - - - - - - - - - dial setting of the entrance slit - - - - - size of the entrance slit - - - - - energy of the electrons on the mean path of the analyser - - - - - todo: define more clearly - - - - - Angular axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - - Energy axis of the analyser data - which dimension the axis applies to is defined - using the normal NXdata methods. - - - - - number of raw active elements in each dimension - - - - - - - - origin of rectangular region selected for readout - - - - - - - - size of rectangular region selected for readout - - - - - - - - - - - Descriptive name of sample - - - - - + + todo: define more clearly + + + + Angular axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + + Energy axis of the analyser data + which dimension the axis applies to is defined + using the normal NXdata methods. + + + + number of raw active elements in each dimension + + + + + + origin of rectangular region selected for readout + + + + + + size of rectangular region selected for readout + + + + + + + + + Descriptive name of sample + + + + diff --git a/applications/NXcanSAS.nxdl.xml b/applications/NXcanSAS.nxdl.xml index e562257c4d..6c255e8194 100644 --- a/applications/NXcanSAS.nxdl.xml +++ b/applications/NXcanSAS.nxdl.xml @@ -3,7 +3,7 @@ .. index:: NXcanSAS (applications); Q @@ -425,7 +425,7 @@ - + .. index:: NXcanSAS (applications); I @@ -1187,7 +1187,7 @@ ============================ --> - + The *SAStransmission_spectrum* element @@ -1215,7 +1215,7 @@ - the wavelengths field (as a dimension scale) corresponding to this transmission + the wavelengths field (as axis coordinates) corresponding to this transmission diff --git a/applications/NXdirecttof.nxdl.xml b/applications/NXdirecttof.nxdl.xml index 2648930f40..94c6576f6a 100644 --- a/applications/NXdirecttof.nxdl.xml +++ b/applications/NXdirecttof.nxdl.xml @@ -3,7 +3,7 @@ - Official NeXus NXDL schema to which this file conforms diff --git a/applications/NXlauetof.nxdl.xml b/applications/NXlauetof.nxdl.xml index 514a47a4ad..060efbc11a 100644 --- a/applications/NXlauetof.nxdl.xml +++ b/applications/NXlauetof.nxdl.xml @@ -3,7 +3,7 @@ -# -# -# This is an application definition for angular resolved photo electron spectroscopy. -# -# It has been drawn up with hemispherical electron analysers in mind. -# -# This definition is a legacy support for older NXarpes experiments. -# There is, however, a newer definition to collect data & metadata -# for general photoemission experiments, called :ref:NXmpes, -# as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." -# -# -# -# -# NeXus convention is to use "entry1", "entry2", ... -# for analysis software to locate each entry. -# -# -# -# -# -# -# Official NeXus NXDL schema to which this file conforms. -# -# -# -# +# +# +# This is an application definition for angular resolved photo electron spectroscopy. +# +# It has been drawn up with hemispherical electron analysers in mind. +# +# This definition is a legacy support for older NXarpes experiments. +# There is, however, a newer definition to collect data & metadata +# for general photoemission experiments, called :ref:NXmpes, +# as well as a specialization for ARPES experiments, called :ref:NXmpes_arpes." +# +# +# +# +# +# Official NeXus NXDL schema to which this file conforms. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# setting for the electron analyser lens +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# dial setting of the entrance slit +# +# +# size of the entrance slit # -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# setting for the electron analyser lens -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# dial setting of the entrance slit -# -# -# -# -# size of the entrance slit -# -# -# -# -# energy of the electrons on the mean path of the analyser -# -# -# -# -# todo: define more clearly -# -# -# -# -# Angular axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# Energy axis of the analyser data -# which dimension the axis applies to is defined -# using the normal NXdata methods. -# -# -# -# -# number of raw active elements in each dimension -# -# -# -# -# -# -# -# origin of rectangular region selected for readout -# -# -# -# -# -# -# -# size of rectangular region selected for readout -# -# -# -# -# -# -# -# -# -# -# Descriptive name of sample -# -# -# -# -# +# +# energy of the electrons on the mean path of the analyser +# +# +# todo: define more clearly +# +# +# +# Angular axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# +# Energy axis of the analyser data +# which dimension the axis applies to is defined +# using the normal NXdata methods. +# +# +# +# number of raw active elements in each dimension +# +# +# +# +# +# origin of rectangular region selected for readout +# +# +# +# +# +# size of rectangular region selected for readout +# +# +# +# +# +# +# +# +# Descriptive name of sample +# +# # +# +# # diff --git a/applications/nyaml/NXcanSAS.yaml b/applications/nyaml/NXcanSAS.yaml index 0e27825f90..a0d5612413 100644 --- a/applications/nyaml/NXcanSAS.yaml +++ b/applications/nyaml/NXcanSAS.yaml @@ -217,6 +217,7 @@ NXcanSAS(NXobject): ISO-8601 time [#iso8601]_ Q(NX_NUMBER): unit: NX_PER_LENGTH + nameType: specified # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of doc: | @@ -356,6 +357,7 @@ NXcanSAS(NXobject): In such cases, use additional datasets or a :ref:`NXnote` subgroup to include that detail. I(NX_NUMBER): + nameType: specified # http://www.cansas.org/formats/canSAS2012/1.0/doc/basics.html#definition-of-intensity doc: | @@ -1042,6 +1044,7 @@ NXcanSAS(NXobject): # ============================ TRANSMISSION_SPECTRUM(NXdata): exists: ['min', '0'] + nameType: any doc: | The *SAStransmission_spectrum* element @@ -1064,7 +1067,7 @@ NXcanSAS(NXobject): enumeration: T: doc: | - the wavelengths field (as a dimension scale) corresponding to this transmission + the wavelengths field (as axis coordinates) corresponding to this transmission \@name: doc: | Identify what type of spectrum is being described. @@ -1121,13 +1124,13 @@ NXcanSAS(NXobject): This array is of the same shape as ``lambda`` and ``T``. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d181fc353dfaec09af015c68748da4a534f94cea06c91f9f660323fd3f1c2b75 +# d13370a0680a2f9193a51c096c1d2a2afa0d4cec52b4137a216292f8cca86504 # # # # # .. index:: NXcanSAS (applications); Q @@ -1549,7 +1552,7 @@ NXcanSAS(NXobject): # # # -# +# # # # .. index:: NXcanSAS (applications); I @@ -2311,7 +2314,7 @@ NXcanSAS(NXobject): # ============================ # --> # -# +# # # The *SAStransmission_spectrum* element # @@ -2339,7 +2342,7 @@ NXcanSAS(NXobject): # # # -# the wavelengths field (as a dimension scale) corresponding to this transmission +# the wavelengths field (as axis coordinates) corresponding to this transmission # # # diff --git a/applications/nyaml/NXdirecttof.yaml b/applications/nyaml/NXdirecttof.yaml index 8ced0bc49d..188dd6178a 100644 --- a/applications/nyaml/NXdirecttof.yaml +++ b/applications/nyaml/NXdirecttof.yaml @@ -3,7 +3,7 @@ doc: | This is a application definition for raw data from a direct geometry TOF spectrometer type: group NXdirecttof(NXtofraw): - (NXentry)entry: + (NXentry): title: start_time(NX_DATE_TIME): definition: @@ -11,7 +11,7 @@ NXdirecttof(NXtofraw): Official NeXus NXDL schema to which this file conforms enumeration: [NXdirecttof] (NXinstrument): - (NXfermi_chopper)fermi_chopper: + fermi_chopper(NXfermi_chopper): exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY @@ -21,7 +21,7 @@ NXdirecttof(NXtofraw): unit: NX_ENERGY doc: | energy selected - (NXdisk_chopper)disk_chopper: + disk_chopper(NXdisk_chopper): exists: ['min', '0'] rotation_speed(NX_FLOAT): unit: NX_FREQUENCY @@ -36,13 +36,13 @@ NXdirecttof(NXtofraw): a fermi_chopper or a disk_chopper group is required. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1d47a6d74aba3fd326b8022400cf62c8d44aa409690508a10b91dce0f188c23c +# 1c986cb037afe19455a4c7666b6b918441dd844869d2e70c7e5d4babb6084944 # # # -# # # # Official NeXus NXDL schema to which this file conforms diff --git a/applications/nyaml/NXlauetof.yaml b/applications/nyaml/NXlauetof.yaml index 3f6dff0c21..7682268af7 100644 --- a/applications/nyaml/NXlauetof.yaml +++ b/applications/nyaml/NXlauetof.yaml @@ -12,13 +12,13 @@ symbols: Time of flight type: group NXlauetof(NXobject): - (NXentry)entry: + (NXentry): definition: doc: | Official NeXus NXDL schema to which this file conforms enumeration: [NXlauetof] - (NXinstrument)instrument: - (NXdetector)detector: + instrument(NXinstrument): + detector(NXdetector): doc: | This assumes a planar 2D detector. All angles and distances refer to the center of the detector. @@ -48,7 +48,7 @@ NXlauetof(NXobject): dimensions: rank: 1 dim: (nTOF,) - (NXsample)sample: + sample(NXsample): name: doc: | Descriptive name of sample @@ -69,7 +69,7 @@ NXlauetof(NXobject): dimensions: rank: 1 dim: (6,) - (NXmonitor)control: + control(NXmonitor): mode: doc: | Count to a preset value based on either clock time (timer) or received monitor counts @@ -89,20 +89,20 @@ NXlauetof(NXobject): dimensions: rank: 1 dim: (nTOF,) - (NXdata)name: + name(NXdata): data(link): target: /NXentry/NXinstrument/NXdetector/data time_of_flight(link): target: /NXentry/NXinstrument/NXdetector/time_of_flight # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3b3c42ead6a490b049752b0c63333dd216712f49125c64e376f31ddb71a49ba3 +# c1361e1498fd61441c0398d9328c605c0e34b21949d8b42972627ad4e1853a37 # # # + + + An actuator used to control an external condition. + + The condition itself is described in :ref:`NXenvironment`. + + + + Name of the actuator + + + + + Short name of actuator used e.g. on monitor display program + + + + + 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. + + + + + 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 output_power(NX_NUMBER). + + + + + + If the actuator is PID-controlled, the settings of the PID controller can be + stored here. + + + diff --git a/base_classes/NXaperture.nxdl.xml b/base_classes/NXaperture.nxdl.xml index 0fe4ec6d76..030c5d9e23 100644 --- a/base_classes/NXaperture.nxdl.xml +++ b/base_classes/NXaperture.nxdl.xml @@ -1,9 +1,9 @@ - + - + - A beamline aperture. This group is deprecated, use NXslit instead. + A beamline aperture. + + Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. + + You can specify the geometry of the aperture using either NXoff_geometry or for simpler geometry shape and size. - - 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 aperture is its center in the x and y axis. The reference point on the z axis is the - surface of the aperture pointing towards the source. - - In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. - - .. image:: aperture/aperture.png - :width: 40% - + + The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the + surface of the aperture pointing towards the source. + + In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. + + .. image:: aperture/aperture.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. - + + + Use this group to describe the shape of the aperture. + @@ -59,32 +53,26 @@ - location and shape of aperture - - .. TODO: documentation needs improvement, contributions welcome - - * description of terms is poor and leaves much to interpretation - * Describe what is meant by translation _here_ and ... - * Similar throughout base classes - * Some base classes do this much better - * Such as where is the gap written? + Location and shape of aperture + + .. TODO: documentation needs improvement, contributions welcome + + * description of terms is poor and leaves much to interpretation + * Describe what is meant by translation _here_ and ... + * Similar throughout base classes + * Some base classes do this much better + * Such as where is the gap written? + - - location and shape of each blade - + location and shape of each blade - - - - Absorbing material of the aperture - + + Absorbing material of the aperture - - Description of aperture - + Description of aperture @@ -111,20 +99,7 @@ - describe any additional information in a note* + Describe any additional information in a note. - - - .. 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/NXattenuator.nxdl.xml b/base_classes/NXattenuator.nxdl.xml index 19780362d4..52ff615574 100644 --- a/base_classes/NXattenuator.nxdl.xml +++ b/base_classes/NXattenuator.nxdl.xml @@ -3,7 +3,7 @@ + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + A description of the procedures employed. + + + + + The physical quantity of the calibration, e.g., + energy, momentum, time, etc. + + + + + A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement + used for this instrument, e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the NeXus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption (e.g. in a research data management system (RDMS)). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + Array containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + + + + The name of each ``TERM`` is used as the symbol to be used in the ``fit_formula_description``, i.e., + if the field name is `my_field` you should refer to this axis by `my_field` in the ``fit_formula_description``. + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + + For non-linear energy calibrations, e.g. in a time-of-flight (TOF) detector, a polynomial function is fitted + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the fit coefficients. + + + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the + ``fit_formula_description``. + + + + + + For non-linear energy calibrations. Here we can store a description of the formula + used for the fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients group. + + Use x0, x1, ..., xm for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` group. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. + + + + + For linear calibration. Scaling parameter. + This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. + + For a more detailed description of scaling factors, see + :ref:`/NXdata/FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>`. + + + + + For linear calibration. Offset parameter. + This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. + + For a more detailed description of offset, see + :ref:`/NXdata/FIELDNAME_offset </NXdata/FIELDNAME_offset-field>`. + + + + + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. + + + + + An array representing the axis after calibration, matching the data length + + + + + + + + Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. + NXdata groups can be used for multidimensional data which are relevant to the calibration + + + + + .. 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/NXcapillary.nxdl.xml b/base_classes/NXcapillary.nxdl.xml index 235c99a9e5..8691c980e4 100644 --- a/base_classes/NXcapillary.nxdl.xml +++ b/base_classes/NXcapillary.nxdl.xml @@ -3,7 +3,7 @@ diff --git a/base_classes/NXcollimator.nxdl.xml b/base_classes/NXcollimator.nxdl.xml index 22a3923d8b..26ab51300b 100644 --- a/base_classes/NXcollimator.nxdl.xml +++ b/base_classes/NXcollimator.nxdl.xml @@ -3,7 +3,7 @@ - Base class for components of an instrument - real ones or a simulated ones. + Base class for components of an instrument - real ones or simulated ones. - - - Specifies the position of the component by pointing to the last - transformation in the transformation chain that is defined - via the NXtransformations group. - - Was the component used? @@ -39,26 +32,61 @@ - Given name + Name of the component. - Ideally, use instances of :ref:`NXidentifier` to point to a resource + Ideally, use instances of ``identifierNAME`` to point to a resource that provides further details. - - If such a resource does not exist or should not be used, use this, though - discouraged, free-text. + + If such a resource does not exist or should not be used, use this free text, + although it is not recommended. + + + + + Instance or list of instances of ``NXcomponent`` (or base classes + extending ``NXcomponent``) or ``NXbeam`` that act as input(s) to this + component. + + Each input should point to the path of the group acting as input. + + An example usage would be to chain components and/or beams together to describe + the beam path in an experiment. + + + Instance or list of instances of ``NXcomponent`` (or base classes + extending ``NXcomponent``) or ``NXbeam`` that act as output(s) of this + component. + + For more information, see :ref:`inputs </NXcomponent/inputs-field>`. + + - + + + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. + + 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. + + Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. + location and geometry of the component in the instrument. The dependency + chain may however traverse similar groups in other component groups. - + diff --git a/base_classes/NXcrystal.nxdl.xml b/base_classes/NXcrystal.nxdl.xml index ebbe12a2ae..a21c16d86b 100644 --- a/base_classes/NXcrystal.nxdl.xml +++ b/base_classes/NXcrystal.nxdl.xml @@ -3,7 +3,7 @@ - - - - - These symbols will be used below to coordinate fields with the same - shape. - - - - rank of the ``DATA`` field - - - - - length of the ``AXISNAME`` field - - - - - length of the ``x`` field - - - - - length of the ``y`` field - - - - - length of the ``z`` field - - - - - :ref:`NXdata` describes the plottable data and related dimension scales. - - .. index:: plotting - - It is strongly recommended that there is at least one :ref:`NXdata` - group in each :ref:`NXentry` group. - Note that the fields named ``AXISNAME`` and ``DATA`` - can be defined with different names. - (Upper case is used to indicate that the actual name is left to the user.) - The ``signal`` and ``axes`` attributes of the - ``data`` group define which items - are plottable data and which are *dimension scales*, respectively. - - :ref:`NXdata` is used to implement one of the basic motivations in NeXus, - to provide a default plot for the data of this :ref:`NXentry`. The actual data - might be stored in another group and (hard) linked to the :ref:`NXdata` group. - - * Each :ref:`NXdata` group will define one field as the default - plottable data. The value of the ``signal`` attribute names this field. - Additional fields may be used to describe the dimension scales and - uncertainities. - The ``auxiliary_signals`` attribute is a list of the other fields - to be plotted with the ``signal`` data. - * The plottable data may be of arbitrary rank up to a maximum - of ``NX_MAXRANK=32`` (for compatibility with backend file formats). - * The plottable data will be named as the value of - the group ``signal`` attribute, such as:: - - data:NXdata - @signal = "counts" - @axes = "mr" - @mr_indices = 0 - counts: float[100] --> the default dependent data - mr: float[100] --> the default independent data - - The field named in the ``signal`` attribute **must** exist, either - directly as a NeXus field or defined through a link. - - * The group ``axes`` attribute will name the - *dimension scale* associated with the plottable data. - - If available, the standard deviations of the data are to be - stored in a data set of the same rank and dimensions, with the name ``errors``. - - * For each data dimension, there should be a one-dimensional array - of the same length. - * These one-dimensional arrays are the *dimension scales* of the - data, *i.e*. the values of the independent variables at which the data - is measured, such as scattering angle or energy transfer. - - .. index:: link - .. index:: axes (attribute) - - The preferred method to associate each data dimension with - its respective dimension scale is to specify the field name - of each dimension scale in the group ``axes`` attribute as a string list. - Here is an example for a 2-D data set *data* plotted - against *time*, and *pressure*. (An additional *temperature* data set - is provided and could be selected as an alternate for the *pressure* axis.):: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @pressure_indices=1 - @temperature_indices=1 - @time_indices=0 - data: float[1000,20] - pressure: float[20] - temperature: float[20] - time: float[1000] - - .. rubric:: Old methods to identify the plottable data - - There are two older methods of associating - each data dimension to its respective dimension scale. - Both are now out of date and - should not be used when writing new data files. - However, client software should expect to see data files - written with any of these methods. - - * One method uses the ``axes`` - attribute to specify the names of each *dimension scale*. - - * The oldest method uses the ``axis`` attribute on each - *dimension scale* to identify - with an integer the axis whose value is the number of the dimension. - - .. index: !plot; axis label - plot, axis units - units - dimension scale - - Each axis of the plot may be labeled with information from the - dimension scale for that axis. The optional ``@long_name`` attribute - is provided as the axis label default. If ``@long_name`` is not - defined, then use the name of the dimension scale. A ``@units`` attribute, - if available, may be added to the axis label for further description. - See the section :ref:`Design-Units` for more information. - - .. index: !plot; axis title - - The optional ``title`` field, if available, provides a suggested - title for the plot. If no ``title`` field is found in the :ref:`NXdata` - group, look for a ``title`` field in the parent :ref:`NXentry` group, - with a fallback to displaying the path to the :ref:`NXdata` group. - - NeXus is about how to find and annotate the data to be plotted - but not to describe how the data is to be plotted. - (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of additional - signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html - - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: signal attribute value - - Declares which NeXus field is the default. - The value is the :ref:`name <validItemName>` of the data field to be plotted. - This field or link *must* exist and be a direct child of this NXdata group. - - It is recommended (as of NIAC2014) to use this attribute - rather than adding a signal attribute to the field. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - .. index:: plotting - - Array of strings holding the :ref:`names <validItemName>` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal </NXdata@signal-attribute>` - as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. - - One name is provided for every dimension in the *signal* or *auxiliary signal* fields. - - The *axes* values are the names of fields or links that *must* exist and be direct - children of this NXdata group. - - An axis slice is specified using a field named ``AXISNAME_indices`` - as described below (where the text shown here as ``AXISNAME`` is to be - replaced by the actual field name). - - When no default axis is available for a particular dimension - of the plottable data, use a "." in that position. - Such as:: - - @axes=["time", ".", "."] - - Since there are three items in the list, the *signal* field - must be a three-dimensional array (rank=3). The first dimension - is described by the values of a one-dimensional array named ``time`` - while the other two dimensions have no fields to be used as dimension scales. - - See examples provided on the NeXus wiki: - https://www.nexusformat.org/2014_axes_and_uncertainties.html - - If there are no axes at all (such as with a stack of images), - the axes attribute can be omitted. - - - - - Points to the path of a field defining the data to which the `DATA` group refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - - - - - - - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - - - - - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - - - - A *dimension scale* must have a rank of 1 and has length ``n``. - - - - - - Axis label - - - - - ``0|false``: single value, - ``1|true``: multiple values - - - - - Index of first good value - - - - - Index of last good value - - - - - Index (positive integer) identifying this specific set of numbers. - - N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. - - - - - Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. - - This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Examples: - If a calibration has been performed, ``@reference`` links to the result of - that calibration: - - @reference: '/entry/process/calibration/calibrated_axis' - - If the axis corresponds to a coordinate of a detector, ``@reference`` links - to that detector axis: - - @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector - - If the axis is a scanned motor, ``@reference`` links to the transformation - describing the respective motion, e.g.: - - @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - - - - - - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. - - - - - .. index:: plotting - - This field contains the data values to be used as the - NeXus *plottable data*. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - - - - The rank (``dataRank``) of the ``data`` must satisfy - ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. - - - - - .. index:: plotting - - Plottable (independent) axis, indicate index number. - Only one field in a :ref:`NXdata` group may have the - ``signal=1`` attribute. - Do not use the ``signal`` attribute with the ``axis`` attribute. - - - - - Defines the names of the dimension scales - (independent axes) for this data set - as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred - method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - - - - - data label - - - - - Points to the path of a field defining the data to which the `DATA` field refers. - - This concept allows to link the data to a respective field in the NeXus hierarchy, thereby - defining the physical quantity it represents. - - Here, *DATA* is to be replaced by the name of each - data field. - - Example: - If the data corresponds to a readout of a detector, ``@reference`` links - to that detectors data: - - @reference: '/entry/instrument/detector/data' for a 2D detector - - - - - - Standard deviations of data values - - the data array is identified by the group attribute ``signal``. - The ``errors`` array must have the same dimensions as ``DATA``. - Client is responsible for defining the dimensions of the data. - - - - The ``errors`` must have - the same rank (``dataRank``) - as the ``data``. - At least one ``dim`` must have length "n". - - - - - - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. - - - - - An optional offset to apply to the values in data. - - - - - Title for the plot. - - - - - This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. - - - - - - - - This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. - - - - - + + + + + + These symbols will be used below to coordinate fields with the same shape. + rank of the ``DATA`` field(s) + length of the ``x`` field + length of the ``y`` field + length of the ``z`` field + + + + The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. + NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their + associated axis coordinates (sometimes referred to as *axes* or *independent variables*). + + The actual names of the :ref:`DATA </NXdata/DATA-field>` and :ref:`AXISNAME </NXdata/AXISNAME-field>` fields + can be chosen :ref:`freely <validItemName>`, as indicated by the upper case (this is a common convention in all NeXus classes). + + .. note:: ``NXdata`` provides data and coordinates to be plotted but + does not describe how the data is to be plotted or even the dimensionality of the plot. + https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute + + **Signals:** + + .. index:: plotting + + The :ref:`DATA </NXdata/DATA-field>` fields contain the signal values to be plotted. The name of the field + to be used as the *default plot signal* is provided by the :ref:`signal </NXdata@signal-attribute>` attribute. + The names of the fields to be used as *secondary plot signals* are provided by the + :ref:`auxiliary_signals</NXdata@auxiliary_signals-attribute>` attribute. + + An example with three signals, one of which being the default + + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + data1: float[10,20,30] --> the default signal + data2: float[10,20,30] + data3: float[10,20,30] + + **Axes:** + + .. index:: axes (attribute) + .. index:: coordinates + + The :ref:`AXISNAME </NXdata/AXISNAME-field>` fields contain the axis coordinates associated with the data values. + The names of all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are listed in the + :ref:`axes </NXdata@axes-attribute>` attribute. + + `Rank` + + :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are typically one-dimensional arrays, which annotate one of the dimensions. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order matters + data: float[10,20] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. + + However, the fields can also have a rank greater than 1, in which case the rank of each + :ref:`AXISNAME </NXdata/AXISNAME-field>` must be equal to the number of data dimensions it spans. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order does NOT matter + @x_indices = [0, 1] + @y_indices = [0, 1] + data: float[10,20] + x: float[10,20] --> coordinates along both dimensions + y: float[10,20] --> coordinates along both dimensions + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. + + `Dimensions` + + The data dimensions annotated by an :ref:`AXISNAME </NXdata/AXISNAME-field>` field are defined by the + :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attribute. When this attribute is missing, + the position(s) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` string in the + :ref:`axes </NXdata@axes-attribute>` attribute are used. + + When all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are one-dimensional, and none of the data dimensions + have more than one axis, the :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes + are often omitted. If one of the data dimensions has no :ref:`AXISNAME </NXdata/AXISNAME-field>` field, + the string “.” can be used in the corresponding index of the axes list. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", ".", "z"] --> the order matters + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When using :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` this becomes + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "z"] --> the order does NOT matter + data: float[10,20,30] + @x_indices = 0 + @z_indices = 2 + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When providing :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes it is recommended + to do it for all axes. + + `Non-trivial axes` + + What follows are two examples where :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes + cannot be omitted. + + The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents + a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` + for the last dimension (or vice versa). + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter + @x_indices = 0 + @y_indices = 1 + @energy_indices = 2 + @wavelength_indices = 2 + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + energy: float[30] --> coordinates along the third dimension + wavelength: float[30] --> coordinates along the third dimension + + The second is an example with coordinates that span more than one dimension. The NXdata group represents data + from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates + ``[x[i,j,k], y[i,j,k], energy[k]]``. + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy"] --> the order does NOT matter + @x_indices = [0, 1, 2] + @y_indices = [0, 1, 2] + @energy_indices = 2 + data: float[10,20,30] + x: float[10,20,30] --> coordinates along all dimensions + y: float[10,20,30] --> coordinates along all dimensions + energy: float[30] --> coordinates along the third dimension + + **Uncertainties:** + + Standard deviations on data values as well as coordinates can be provided by + :ref:`FIELDNAME_errors </NXdata/FIELDNAME_errors-field>` fields where ``FIELDNAME`` is the name of a + :ref:`DATA </NXdata/DATA-field>` field or an :ref:`AXISNAME </NXdata/AXISNAME-field>` field. + + An example of uncertainties on the signal, auxiliary signals and axis coordinates + + .. code-block:: + + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + @axes = ["x", "z"] + @x_indices = 0 + @z_indices = 2 + data1: float[10,20,30] + data2: float[10,20,30] + data3: float[10,20,30] + x: float[10] + z: float[30] + data1_errors: float[10,20,30] + data2_errors: float[10,20,30] + data3_errors: float[10,20,30] + x_errors: float[10] + z_errors: float[30] + + + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: signal attribute value + + The value is the :ref:`name <validItemName>` of the signal that contains + the default plottable data. This field or link *must* exist and be a direct child + of this NXdata group. + + It is recommended (as of NIAC2014) to use this attribute + rather than adding a signal attribute to the field. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + .. index:: plotting + + Array of strings holding the :ref:`names <validItemName>` of additional + signals to be plotted with the :ref:`default signal </NXdata@signal-attribute>`. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. + + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + + + + + Which slice of data to show in a plot by default. This is useful especially for + datasets with more than 2 dimensions. + + Should be an array of length equal to the number of dimensions + in the data, with the following possible values: + + * ".": All the data in this dimension should be included + * Integer: Only this slice should be used. + * String: Only this slice should be used. Use if ``AXISNAME`` is a string + array. + + Example:: + + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "difference", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] + + Here, a data array with four dimensions, including the number of images + (nP) and number of channels (nC), specifies more dimensions than can be + visualized with a 2D image viewer for a given image. Therefore the + default_slice attribute specifies that the "difference" channel should be + shown by default. + + Alternate version using an integer would look like this (note 2 is a string):: + + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "2", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] + + + + + + Points to the path of a field defining the data to which the `DATA` group refers. + + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector + + + + + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` + dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). + + When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME </NXdata/AXISNAME-field>` field, its value becomes the index + (or indices) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` name in the :ref:`axes </NXdata@axes-attribute>` attribute. + + .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array + of integers and not a comma separated string. + + + + + .. index:: plotting + + The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME </NXdata/AXISNAME-field>` fields + that contain the values of the coordinates along the :ref:`data </NXdata/DATA-field>` dimensions. + + .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array + of strings and not a single comma separated string. + + + + + + + Coordinate values along one or more :ref:`data </NXdata/DATA-field>` dimensions. The rank must be equal + to the number of dimensions it spans. + + As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely <validItemName>`. + The :ref:`axes </NXdata@axes-attribute>` attribute can be used to find all datasets in the + ``NXdata`` that contain coordinate values. + + Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, + an array of NX_CHAR can be provided. + + Axis label + + + Unit in which the coordinate values are expressed. + See the section :ref:`Design-Units` for more information. + + + + + ``0|false``: single value, + ``1|true``: multiple values + + + Index of first good value + Index of last good value + + + Index (positive integer) identifying this specific set of numbers. + + N.B. The ``axis`` attribute is the old way of designating a link. + Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. + The :ref:`axes </NXdata@axes-attribute>` attribute is now preferred. + + + + + Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. + + This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Examples: + If a calibration has been performed, ``@reference`` links to the result of + that calibration: + + @reference: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@reference`` links + to that detector axis: + + @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@reference`` links to the transformation + describing the respective motion, e.g.: + + @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + + + + + .. index:: plotting + + Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` + indicates, the names of the ``DATA`` fields can be chosen :ref:`freely <validItemName>`. The :ref:`signal attribute </NXdata@signal-attribute>` + and :ref:`auxiliary_signals attribute</NXdata@auxiliary_signals-attribute>` can be used to find all datasets in the ``NXdata`` + that contain data values. + + The maximum rank is ``32`` for compatibility with backend file formats. + + + + The rank (``dataRank``) of the ``data`` must satisfy + ``1 <= dataRank <= NX_MAXRANK=32``. + + + + + .. index:: plotting + + Plottable (independent) axis, indicate index number. + Only one field in a :ref:`NXdata` group may have the + ``signal=1`` attribute. + Do not use the ``signal`` attribute with the ``axis`` attribute. + + + + + Defines the names of the coordinates + (independent axes) for this data set + as a colon-delimited array. + NOTE: The :ref:`axes </NXdata@axes-attribute>` attribute is the preferred + method of designating a link. + Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. + + + + data label + + + + Points to the path of a field defining the data to which the `DATA` field refers. + + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *DATA* is to be replaced by the name of each + data field. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector + + + + + + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. + + + + + Standard deviations of data values - + the data array is identified by the group attribute ``signal``. + The ``errors`` array must have the same dimensions as ``DATA``. + Client is responsible for defining the dimensions of the data. + + + + The ``errors`` must have the same rank (``dataRank``) + as the ``data``. + + + + + + + + An optional scaling factor to apply to the values in any field named ``FIELDNAME`` + in this ``NXdata`` group. This can be a :ref:`DATA </NXdata/DATA-field>` field + (signal or auxiliary signal) or a :ref:`AXISNAME </NXdata/AXISNAME-field>` + field (axis). + + The elements stored in NXdata datasets are often stored as integers for efficiency + reasons and need further correction or conversion, generating floats. For example, + raw values could be stored from a device that need to be converted to values that + represent the physical values. The two fields FIELDNAME_scaling_factor and + FIELDNAME_offset allow linear corrections using the following convention: + + .. code-block:: + + corrected values = (FIELDNAME + offset) * scaling_factor + + This formula will derive the values to use in downstream applications, when necessary. + + When omitted, the scaling factor is assumed to be 1. + + + + + An optional offset to apply to the values in FIELDNAME (usually the signal). + + When omitted, the offset is assumed to be 0. + + See :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>` for more information. + + + + + + The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. + However, scaling_factor is ambiguous in the case of multiple signals. Therefore + scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when + only a single signal is present. + + + + + The offset and FIELDNAME_offset fields have similar semantics. + However, offset is ambiguous in the case of multiple signals. Therefore + offset is deprecated. Use FIELDNAME_offset instead, even when + only a single signal is present. + + + + + + + + Title for the plot. + + + + + + + This is an array holding the values to use for the x-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + + + + This is an array holding the values to use for the y-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + + + + This is an array holding the values to use for the z-axis of + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` + kept for backward compatiblity. + + + + + diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index f33b6d699b..17287df03f 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -1,9 +1,9 @@ - - + + - - - - These symbols will be used below to illustrate the coordination of the - rank and sizes of datasets and the preferred ordering of the - dimensions. Each of these are optional (so the rank of the datasets - will vary according to the situation) and the general ordering - principle is slowest to fastest. The type of each dimension should - follow the order of scan points, detector output (e.g. pixels), then - time-of-flight (i.e. spectroscopy, spectrometry). Note that the output - of a detector is not limited to single values (0D), lists (1D) and - images (2), but three or higher dimensional arrays can be produced by - a detector at each trigger. - - - - number of scan points (only present in scanning measurements) - - - - - number of detector pixels in the first (slowest) direction - - - - - number of detector pixels in the second (faster) direction - - - - - number of detector pixels in the third (if necessary, fastest) - direction - - - - - number of bins in the time-of-flight histogram - - - - - A detector, detector bank, or multidetector. - - - - Total time of flight - - - - - - - - - - - - - - - - - Total time of flight - - - - - - In DAQ clock pulses - - - - - - - Clock frequency in Hz - - - - - - Identifier for detector (pixels) - Can be multidimensional, if needed - - - - - Data values from the detector. The rank and dimension ordering should follow a principle of - slowest to fastest measurement axes and may be explicitly specified in application definitions. - - Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be - the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions - of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single - scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. - Repetition of an experiment in a time series tends to be used similar to a slow scan axis - and so will often be in the first dimension of the data array. - - The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions - (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an - imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data - will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to - be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. - - Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift - detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. - - The type of each dimension should should follow the order of scan points, detector pixels, - then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) - shown here are merely illustrative of coordination between related datasets. - - - - - - - - - - Title of measurement - - - - - Integral of data as check of data integrity - - - - - - The best estimate of the uncertainty in the data value (array size should match the data field). Where - possible, this should be the standard deviation, which has the same units - as the data. The form data_error is deprecated. - - - - - - - - - - - Offset from the detector center in x-direction. - Can be multidimensional when needed. - - - - - - - - - - - - - - - - - - x-axis offset from detector center - - - - - - Offset from the detector center in the y-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - Offset from the detector center in the z-direction. - Can be multidimensional when different values are required for each pixel. - - - - - - - - - - - - - - - - - - y-axis offset from detector center - - - - - - This is the distance to the previous component in the - instrument; most often the sample. The usage depends on the - nature of the detector: Most often it is the distance of the - detector assembly. But there are irregular detectors. In this - case the distance must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the polar angle of the detector towards the previous - component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the polar_angle of the detector assembly. - But there are irregular detectors. - In this - case, the polar_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - This is the azimuthal angle angle of the detector towards - the previous component in the instrument; most often the sample. - The usage depends on the - nature of the detector. - Most often it is the azimuthal_angle of the detector assembly. - But there are irregular detectors. - In this - case, the azimuthal_angle must be specified for each detector pixel. - - Note, it is recommended to use NXtransformations instead. - - - - - - - - - - name/manufacturer/model/etc. information - - - - - Serial number for the detector - - - - - Local name for the detector - - - - - Position and orientation of detector - - - - - Solid angle subtended by the detector at the sample - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size. - - - - - - - - - Size of each detector pixel. If it is scalar all pixels are the same size - - - - - - - - - Detector dead time - - - - - - - - - - Detector gas pressure - - - - - - - - - maximum drift space dimension - - - - - Crate number of detector - - - - - - - - Equivalent local term - - - - - - Slot number of detector - - - - - - - - Equivalent local term - - - - - - Input number of detector - - - - - - - - Equivalent local term - - - - - - Description of type such as He3 gas cylinder, He3 PSD, scintillator, - fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, - CMOS, ... - - - - - Spectral efficiency of detector with respect to e.g. wavelength - - - - - - - - - - - - - - - - - - - - - - - - - efficiency of the detector - - - - - - - - - - This field can be two things: - - 1. For a pixel detector it provides the nominal wavelength - for which the detector has been calibrated. - - 2. For other detectors this field has to be seen together with - the efficiency field above. - For some detectors, the efficiency is wavelength dependent. - Thus this field provides the wavelength axis for the efficiency field. - In this use case, the efficiency and wavelength arrays must - have the same dimensionality. - - - - - - - - - - - Real-time of the exposure (use this if exposure time varies for - each array element, otherwise use ``count_time`` field). - - Most often there is a single real time value that is constant across - an entire image frame. In such cases, only a 1-D array is needed. - But there are detectors in which the real time - changes per pixel. In that case, more than one dimension is needed. Therefore - the rank of this field should be less than or equal to (detector rank + 1). - - - - - - - - - - start time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - stop time for each frame, with the ``start`` attribute as absolute reference - - - - - - - - - date of last calibration (geometry and/or efficiency) measurements - - - - - summary of conversion of array data to pixels (e.g. polynomial - approximations) and location of details of the calibrations - - - - - How the detector is represented - - - - - - - - - - Elapsed actual counting time - - - - - - - - - Use this group to provide other data related to this NXdetector group. - + + + + + These symbols will be used below to illustrate the coordination of the rank and sizes of datasets and the + preferred ordering of the dimensions. Each of these are optional (so the rank of the datasets + will vary according to the situation) and the general ordering principle is slowest to fastest. + The type of each dimension should follow the order of scan points, detector output (e.g. pixels), + then time-of-flight (i.e. spectroscopy, spectrometry). Note that the output of a detector is not limited + to single values (0D), lists (1D) and images (2), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + + number of scan points (only present in scanning measurements) + number of detector pixels in the first (slowest) direction + number of detector pixels in the second (faster) direction + number of detector pixels in the third (if necessary, fastest) direction + number of bins in the time-of-flight histogram + + + + A detector, detector bank, or multidetector. + + + + Total time of flight + + + + + + + + + + + + + + + + + + + Total time of flight + + + + + In DAQ clock pulses + + + + + + + Clock frequency in Hz + + + + + + Identifier for detector (pixels) + Can be multidimensional, if needed + + + + + + Data values from the detector. The rank and dimension ordering should follow a principle of + slowest to fastest measurement axes and may be explicitly specified in application definitions. + + Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be + the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions + of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single + scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. + Repetition of an experiment in a time series tends to be used similar to a slow scan axis + and so will often be in the first dimension of the data array. + + The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions + (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an + imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data + will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to + be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. + + Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift + detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. + + The type of each dimension should should follow the order of scan points, detector pixels, + then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) + shown here are merely illustrative of coordination between related datasets. + + + + + + + + + + + Title of measurement + + + + Integral of data as check of data integrity + + + + + + + The best estimate of the uncertainty in the data value (array size should match the data field). Where + possible, this should be the standard deviation, which has the same units + as the data. The form data_error is deprecated. + + + + + + + + + + + + + + Offset from the detector center in x-direction. + Can be multidimensional when needed. + + + + + + + + + + + + + + + + + + + + + x-axis offset from detector center + + + + + + Offset from the detector center in the y-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + + Offset from the detector center in the z-direction. + Can be multidimensional when different values are required for each pixel. + + + + + + + + + + + + + + + + + + + + + y-axis offset from detector center + + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the polar angle of the detector towards the previous + component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the polar_angle of the detector assembly. + But there are irregular detectors. + In this + case, the polar_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + + This is the azimuthal angle angle of the detector towards + the previous component in the instrument; most often the sample. + The usage depends on the + nature of the detector. + Most often it is the azimuthal_angle of the detector assembly. + But there are irregular detectors. + In this + case, the azimuthal_angle must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + + name/manufacturer/model/etc. information + + + + Serial number for the detector + + + + Local name for the detector + + + + Position and orientation of detector + + + + Solid angle subtended by the detector at the sample + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size. + + + + + + + + + + Size of each detector pixel. If it is scalar all pixels are the same size + + + + + + + + + Detector dead time + + + + + + + + + + Detector gas pressure + + + + + + + + + maximum drift space dimension + + + + Crate number of detector + + + + + + + + Equivalent local term + + + + + Slot number of detector + + + + + + + + Equivalent local term + + + + + Input number of detector + + + + + + + + Equivalent local term + + + + + + Description of type such as He3 gas cylinder, He3 PSD, scintillator, + fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, + CMOS, ... + + + + + + Group containing the description and metadata for a single channel from a multi-channel + detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with + named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), + the NXdetector will have a series of NXdetector_channel groups, one for each channel, + named CHANNELNAME_channel. + + + + + Spectral efficiency of detector with respect to e.g. wavelength + + + + + + + + + + + + + + + + + + + + + + + + efficiency of the detector + + + + + + + + + + + This field can be two things: + + #. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + #. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + + + + + Real-time of the exposure (use this if exposure time varies for + each array element, otherwise use ``count_time`` field). + + Most often there is a single real time value that is constant across + an entire image frame. In such cases, only a 1-D array is needed. + But there are detectors in which the real time + changes per pixel. In that case, more than one dimension is needed. Therefore + the rank of this field should be less than or equal to (detector rank + 1). + + + + + + + + + + start time for each frame, with the ``start`` attribute as absolute reference + + + + + + + stop time for each frame, with the ``start`` attribute as absolute reference + + + + + + + + + date of last calibration (geometry and/or efficiency) measurements + + + + + + summary of conversion of array data to pixels (e.g. polynomial + approximations) and location of details of the calibrations + + + + + How the detector is represented + + + + + + + + + + Elapsed actual counting time + + + + + + + + + + + Use this group to provide other data related to this NXdetector group. + + + + + + In order to properly sort the order of the images taken in (for + example) a tomography experiment, a sequence number is stored with each + image. + + + + + + + + + + This is the x position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the y position where the direct beam would hit the detector. + This is a length and can be outside of the actual + detector. The length can be in physical units or pixels + as documented by the units attribute. + + + + + + This is the start number of the first frame of a scan. In protein crystallography measurements one + often scans a couple of frames on a give sample, then does something else, + then returns to the same sample and scans some more frames. Each time with + a new data file. This number helps concatenating such measurements. + + + + + The diameter of a cylindrical detector + + + + The acquisition mode of the detector. + + + + + + + + + + + + + True when the angular calibration has been applied in the + electronics, false otherwise. + + + + Angular calibration data. + + + + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + Flat field correction data. + + + + + + + + Errors of the flat field correction data. + The form flatfield_error is deprecated. + + + + + + + + + True when the pixel mask correction has been applied in the + electronics, false otherwise. + + + + + The 32-bit pixel mask for the detector. Can be either one mask + for the whole dataset (i.e. an array with indices i, j) or + each frame can have its own mask (in which case it would be + an array with indices np, i, j). + + Contains a bit field for each pixel to signal dead, + blind or high or otherwise unwanted or undesirable pixels. + They have the following meaning: + + .. can't make a table here, a bullet list will have to do for now + + * bit 0: gap (pixel with no sensor) + * bit 1: dead + * bit 2: under responding + * bit 3: over responding + * bit 4: noisy + * bit 5: -undefined- + * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) + * bit 7: -undefined- + * bit 8: user defined mask (e.g. around beamstop) + * bits 9-30: -undefined- + * bit 31: virtual pixel (corner pixel with interpolated value) + + Normal data analysis software would + not take pixels into account + when a bit in (mask & 0x0000FFFF) is + set. Tag bit in the upper + two bytes would indicate special pixel + properties that normally + would not be a sole reason to reject the + intensity value (unless + lower bits are set. + + If the full bit depths is not required, providing a + mask with fewer bits is permissible. + + If needed, additional pixel masks can be specified by + including additional entries named pixel_mask_N, where + N is an integer. For example, a general bad pixel mask + could be specified in pixel_mask that indicates noisy + and dead pixels, and an additional pixel mask from + experiment-specific shadowing could be specified in + pixel_mask_2. The cumulative mask is the bitwise OR + of pixel_mask and any pixel_mask_N entries. + + + + + + + + + + This field allow to distinguish different types of exposure to the same detector "data" field. + Some techniques require frequent (re-)calibration inbetween measuremnts and this way of + recording the different measurements preserves the chronological order with is important for + correct processing. + + This is used for example in tomography (`:ref:`NXtomo`) sample projections, + dark and flat images, a magic number is recorded per frame. + + The key is as follows: + + * projection (sample) = 0 + * flat field = 1 + * dark field = 2 + * invalid = 3 + * background (no sample, but buffer where applicable) = 4 + + In cases where the data is of type :ref:`NXlog` this can also be an NXlog. + + + + + + + + + Counting detectors usually are not able to measure all incoming particles, + especially at higher count-rates. Count-rate correction is applied to + account for these errors. + + True when count-rate correction has been applied, false otherwise. + + + + + The countrate_correction_lookup_table defines the LUT used for count-rate + correction. It maps a measured count :math:`c` to its corrected value + :math:`countrate\_correction\_lookup\_table[c]`. + + :math:`m` denotes the length of the table. + + + + + + + + True when virtual pixel interpolation has been applied, false otherwise. + + When virtual pixel interpolation is applied, values of some pixels may + contain interpolated values. For example, to account for space between + readout chips on a module, physical pixels on edges and corners between + chips may have larger sensor areas and counts may be distributed between + their logical pixels. + + + + + How many bits the electronics reads per pixel. + With CCD's and single photon counting detectors, + this must not align with traditional integer sizes. + This can be 4, 8, 12, 14, 16, ... + + + + + Time it takes to read the detector (typically milliseconds). + This is important to know for time resolved experiments. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector firmware after receiving the trigger signal + to when the detector starts to acquire the exposure, including any user set delay.. + This is important to know for time resolved experiments. + + + + + User-specified trigger delay. + + + + + Time it takes to start exposure after a trigger signal has been received. + This is the reaction time of the detector hardware after receiving the + trigger signal to when the detector starts to acquire the exposure. + It forms the lower boundary of the trigger_delay_time when the user + does not request an additional delay. + + + + + Time during which no new trigger signal can be accepted. + Typically this is the + trigger_delay_time + exposure_time + readout_time. + This is important to know for time resolved experiments. + + + + + This is time for each frame. This is exposure_time + readout time. + + + + + + + + The gain setting of the detector. This is a detector-specific value + meant to document the gain setting of the detector during data + collection, for detectors with multiple available gain settings. + + Examples of gain settings include: + + * ``standard`` + * ``fast`` + * ``auto`` + * ``high`` + * ``medium`` + * ``low`` + * ``mixed high to medium`` + * ``mixed medium to low`` + + Developers are encouraged to use one of these terms, or to submit + additional terms to add to the list. + + + + + The value at which the detector goes into saturation. + Especially common to CCD detectors, the data + is known to be invalid above this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + The lowest value at which pixels for this detector would be reasonably + measured. The data is known to be invalid below this value. + + For example, given a saturation_value and an underload_value, the valid + pixels are those less than or equal to the saturation_value and greater + than or equal to the underload_value. + + The precise type should match the type of the data. + + + + + CCD images are sometimes constructed by summing + together multiple short exposures in the + electronics. This reduces background etc. + This is the number of short exposures used to sum + images for an image. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the name of this converter material. + + + + + At times, radiation is not directly sensed by the detector. + Rather, the detector might sense the output from some + converter like a scintillator. + This is the thickness of this converter material. + + + + + Single photon counter detectors can be adjusted + for a certain energy range in which they + work optimally. This is the energy setting for this. + + + + + For use in special cases where the data in NXdetector + is represented in several parts, each with a separate geometry. + + + + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape. + - - - In order to properly sort the order of the images taken in (for - example) a tomography experiment, a sequence number is stored with each - image. - - - - - - - - This is the x position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the y position where the direct beam would hit the detector. - This is a length and can be outside of the actual - detector. The length can be in physical units or pixels - as documented by the units attribute. - - - - - This is the start number of the first frame of a scan. In protein crystallography measurements one - often scans a couple of frames on a give sample, then does something else, - then returns to the same sample and scans some more frames. Each time with - a new data file. This number helps concatenating such measurements. - - - - - The diameter of a cylindrical detector - - - - - The acquisition mode of the detector. - - - - - - - - - - - - - - True when the angular calibration has been applied in the - electronics, false otherwise. - - - - - Angular calibration data. - - - - - - - - - True when the flat field correction has been applied in the - electronics, false otherwise. - - - - - Flat field correction data. - - - - - - - - - Errors of the flat field correction data. - The form flatfield_error is deprecated. - - - - - - - - - True when the pixel mask correction has been applied in the - electronics, false otherwise. - - - - - The 32-bit pixel mask for the detector. Can be either one mask - for the whole dataset (i.e. an array with indices i, j) or - each frame can have its own mask (in which case it would be - an array with indices np, i, j). - - Contains a bit field for each pixel to signal dead, - blind or high or otherwise unwanted or undesirable pixels. - They have the following meaning: - - .. can't make a table here, a bullet list will have to do for now - - * bit 0: gap (pixel with no sensor) - * bit 1: dead - * bit 2: under responding - * bit 3: over responding - * bit 4: noisy - * bit 5: -undefined- - * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) - * bit 7: -undefined- - * bit 8: user defined mask (e.g. around beamstop) - * bits 9-30: -undefined- - * bit 31: virtual pixel (corner pixel with interpolated value) - - Normal data analysis software would - not take pixels into account - when a bit in (mask & 0x0000FFFF) is - set. Tag bit in the upper - two bytes would indicate special pixel - properties that normally - would not be a sole reason to reject the - intensity value (unless - lower bits are set. - - If the full bit depths is not required, providing a - mask with fewer bits is permissible. - - If needed, additional pixel masks can be specified by - including additional entries named pixel_mask_N, where - N is an integer. For example, a general bad pixel mask - could be specified in pixel_mask that indicates noisy - and dead pixels, and an additional pixel mask from - experiment-specific shadowing could be specified in - pixel_mask_2. The cumulative mask is the bitwise OR - of pixel_mask and any pixel_mask_N entries. - - - - - - - - - This field allow to distinguish different types of exposure to the same detector "data" field. - Some techniques require frequent (re-)calibration inbetween measuremnts and this way of - recording the different measurements preserves the chronological order with is important for - correct processing. - - This is used for example in tomography (`:ref:`NXtomo`) sample projections, - dark and flat images, a magic number is recorded per frame. - - The key is as follows: - - * projection (sample) = 0 - * flat field = 1 - * dark field = 2 - * invalid = 3 - * background (no sample, but buffer where applicable) = 4 - - In cases where the data is of type :ref:`NXlog` this can also be an NXlog. - - - - - - - - Counting detectors usually are not able to measure all incoming particles, - especially at higher count-rates. Count-rate correction is applied to - account for these errors. - - True when count-rate correction has been applied, false otherwise. - - - - - The countrate_correction_lookup_table defines the LUT used for count-rate - correction. It maps a measured count :math:`c` to its corrected value - :math:`countrate\_correction\_lookup\_table[c]`. - - :math:`m` denotes the length of the table. - - - - - - - - True when virtual pixel interpolation has been applied, false otherwise. - - When virtual pixel interpolation is applied, values of some pixels may - contain interpolated values. For example, to account for space between - readout chips on a module, physical pixels on edges and corners between - chips may have larger sensor areas and counts may be distributed between - their logical pixels. - - - - - How many bits the electronics reads per pixel. - With CCD's and single photon counting detectors, - this must not align with traditional integer sizes. - This can be 4, 8, 12, 14, 16, ... - - - - - Time it takes to read the detector (typically milliseconds). - This is important to know for time resolved experiments. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector firmware after receiving the trigger signal - to when the detector starts to acquire the exposure, including any user set delay.. - This is important to know for time resolved experiments. - - - - - User-specified trigger delay. - - - - - Time it takes to start exposure after a trigger signal has been received. - This is the reaction time of the detector hardware after receiving the - trigger signal to when the detector starts to acquire the exposure. - It forms the lower boundary of the trigger_delay_time when the user - does not request an additional delay. - - - - - Time during which no new trigger signal can be accepted. - Typically this is the - trigger_delay_time + exposure_time + readout_time. - This is important to know for time resolved experiments. - - - - - This is time for each frame. This is exposure_time + readout time. - - - - - - - - The gain setting of the detector. This is a detector-specific value - meant to document the gain setting of the detector during data - collection, for detectors with multiple available gain settings. - - Examples of gain settings include: - - * ``standard`` - * ``fast`` - * ``auto`` - * ``high`` - * ``medium`` - * ``low`` - * ``mixed high to medium`` - * ``mixed medium to low`` - - Developers are encouraged to use one of these terms, or to submit - additional terms to add to the list. - - - - - The value at which the detector goes into saturation. - Especially common to CCD detectors, the data - is known to be invalid above this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - The lowest value at which pixels for this detector would be reasonably - measured. The data is known to be invalid below this value. - - For example, given a saturation_value and an underload_value, the valid - pixels are those less than or equal to the saturation_value and greater - than or equal to the underload_value. - - The precise type should match the type of the data. - - - - - CCD images are sometimes constructed by summing - together multiple short exposures in the - electronics. This reduces background etc. - This is the number of short exposures used to sum - images for an image. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the name of this converter material. - - - - - At times, radiation is not directly sensed by the detector. - Rather, the detector might sense the output from some - converter like a scintillator. - This is the thickness of this converter material. - - - - - Single photon counter detectors can be adjusted - for a certain energy range in which they - work optimally. This is the energy setting for this. - - - - - For use in special cases where the data in NXdetector - is represented in several parts, each with a separate geometry. - + + + Shape description of each pixel. Use only if all pixels in the detector + are of uniform shape and require being described by cylinders. + - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape. - - - - - Shape description of each pixel. Use only if all pixels in the detector - are of uniform shape and require being described by cylinders. - - - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape. - - - - - Shape description of the whole detector. Use only if pixels in the - detector are not of uniform shape and require being described by cylinders. - - - - - - .. index:: plotting - - Declares which child group contains a path leading - to a :ref:`NXdata` group. - - It is recommended (as of NIAC2014) to use this attribute - to help define the path to the default dataset to be plotted. - See https://www.nexusformat.org/2014_How_to_find_default_data.html - for a summary of the discussion. - - - - - Type of electron amplifier, MCP, channeltron, etc. - - - - - Description of the detector type, DLD, Phosphor+CCD, CMOS. - - - - - Voltage applied to detector. - - - - - Voltage applied to the amplifier. - - - - - The low voltage of the amplifier migh not be the ground. - - - - - Size of each imaging sensor chip on the detector. - - - - - Number of imaging sensor chips on the detector. - - - - - Physical size of the pixels of the imaging chip on the detector. - - - - - Number of raw active elements in each dimension. Important for swept scans. - - - - - - raw data output from the detector - + + + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape. + - - - NeXus positions components by applying a set of translations and rotations - to apply to the component starting from 0, 0, 0. The order of these operations - is critical and forms what NeXus calls a dependency chain. The depends_on - field defines the path to the top most operation of the dependency chain or the - string "." if located in the origin. Usually these operations are stored in a - NXtransformations group. But NeXus allows them to be stored anywhere. - - The reference point of the detector is the center of the first pixel. - In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. - - - - - This is the group recommended for holding the chain of translation - and rotation operations necessary to position the component within - the instrument. The dependency chain may however traverse similar groups in - other component groups. - + + + Shape description of the whole detector. Use only if pixels in the + detector are not of uniform shape and require being described by cylinders. + + + + + 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. + + diff --git a/base_classes/NXdetector_channel.nxdl.xml b/base_classes/NXdetector_channel.nxdl.xml new file mode 100644 index 0000000000..2ca7c684cf --- /dev/null +++ b/base_classes/NXdetector_channel.nxdl.xml @@ -0,0 +1,162 @@ + + + + + + + + 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 (2D), but three or higher dimensional arrays can be produced + by a detector at each trigger. + + + Rank of the ``data`` field associated with this detector + number of scan points + number of detector pixels in the slowest direction + number of detector pixels in the second slowest direction + number of detector pixels in the third slowest direction + + + + Description and metadata for a single channel from a multi-channel detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the + example in :ref:`NXdata </NXdata@default_slice-attribute>`), the NXdetector will have a series of NXdetector_channel groups, one for each + channel, named CHANNELNAME_channel. + + Example, given these axes in the NXdata group:: + + @axes = ["image_id", "channel", ".", "."] + + And this list of channels in the NXdata group:: + + channel = ["threshold_1", "threshold_2", "difference"] + + The NXdetector group would have three NXdetector_channel groups:: + + detector:NXdetector + ... + threshold_1_channel:NXdetector_channel + threshold_energy = float + flatfield = float[i, j] + pixel_mask = uint[i, j] + flatfield_applied = bool + pixel_mask_applied = bool + threshold_2_channel:NXdetector_channel + threshold_energy = float + flatfield = float[i, j] + pixel_mask = uint[i, j] + flatfield_applied = bool + pixel_mask_applied = bool + difference_channel:NXdetector_channel + threshold_energy = float[2] + + + + Energy at which a photon will be recorded + + + + + True when the flat field correction has been applied in the + electronics, false otherwise. + + + + + Response of each pixel given a constant input + + + + + + + + + + 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. + + + + + + Custom pixel mask for this channel. May include nP as the first dimension for + masks that vary for each scan point. + + + + + + + + + + + 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. + + + diff --git a/base_classes/NXdetector_group.nxdl.xml b/base_classes/NXdetector_group.nxdl.xml index 50397e76b3..499cc4fe09 100644 --- a/base_classes/NXdetector_group.nxdl.xml +++ b/base_classes/NXdetector_group.nxdl.xml @@ -3,7 +3,7 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays @@ -45,11 +45,6 @@ Subclass of NXprocess to describe post-processing distortion correction. - - - Indicates the name of the last operation applied in the NXprocess sequence. - - Has the distortion correction been applied? diff --git a/base_classes/NXelectron_detector.nxdl.xml b/base_classes/NXelectron_detector.nxdl.xml new file mode 100644 index 0000000000..2f8f6294aa --- /dev/null +++ b/base_classes/NXelectron_detector.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + A subclass of NXdetector for detectors that detect electrons. + + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the electron detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to the electron detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier might not be the ground. + + + \ No newline at end of file diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml old mode 100644 new mode 100755 index 0935e6b740..82e59bca61 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -1,9 +1,9 @@ - - + + - - - (**required**) :ref:`NXentry` describes the measurement. - - The top-level NeXus group which contains all the data and associated - information that comprise a single measurement. - It is mandatory that there is at least one - group of this type in the NeXus file. - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names <validItemName>` a child group. If that group - itself has a ``default`` attribute, continue this chain until an - :ref:`NXdata` group is reached. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - - - - - The data group - - .. note:: Before the NIAC2016 meeting [#]_, at least one - :ref:`NXdata` group was required in each :ref:`NXentry` group. - At the NIAC2016 meeting, it was decided to make :ref:`NXdata` - an optional group in :ref:`NXentry` groups for data files that - do not use an application definition. - It is recommended strongly that all NeXus data files provide - a NXdata group. - It is permissable to omit the NXdata group only when - defining the default plot is not practical or possible - from the available data. - - For example, neutron event data may not have anything that - makes a useful plot without extensive processing. - - Certain application definitions override this decision and - require an :ref:`NXdata` group - in the :ref:`NXentry` group. The ``minOccurs=0`` attribute - in the application definition will indicate the - :ref:`NXdata` group - is optional, otherwise, it is required. - - .. [#] NIAC2016: - https://www.nexusformat.org/NIAC2016.html, - https://github.com/nexusformat/NIAC/issues/16 - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, - defined by the facility, - possibly linked to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or NXentry - - - - - Brief summary of the collection, including grouping criteria. - - - - - unique identifier for the measurement, defined by the facility. - - - - - UUID identifier for the measurement. - - - - Version of UUID used - - - - - - Reserved for future use by NIAC. - - See https://github.com/nexusformat/definitions/issues/382 - - - - - (alternate use: see same field in :ref:`NXsubentry` for preferred) - - Official NeXus NXDL schema to which this entry conforms which must be - the name of the NXDL file (case sensitive without the file extension) - that the NXDL schema is defined in. - - For example the ``definition`` field for a file that conformed to the - *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. - - This field is provided so that :ref:`NXentry` can be the overlay position - in a NeXus data file for an application definition and its - set of groups, fields, and attributes. - - *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the entry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the entry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement - - - - - Duration of measurement - - - - - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range - - - - - Such as "2007-3". Some user facilities organize their beam time into run cycles. - - - - - Name of program used to generate this file - - - - Program version number - - - - - configuration of the program - - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - - The mime type should be an ``image/*`` - - - - - - - + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names <validItemName>` a child group. If that group + itself has a ``default`` attribute, continue this chain until an + :ref:`NXdata` group is reached. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + (**required**) :ref:`NXentry` describes the measurement. + + The top-level NeXus group which contains all the data and associated + information that comprise a single measurement. + It is mandatory that there is at least one + group of this type in the NeXus file. + + + + The data group + + .. note:: Before the NIAC2016 meeting [#]_, at least one + :ref:`NXdata` group was required in each :ref:`NXentry` group. + At the NIAC2016 meeting, it was decided to make :ref:`NXdata` + an optional group in :ref:`NXentry` groups for data files that + do not use an application definition. + It is recommended strongly that all NeXus data files provide + a NXdata group. + It is permissable to omit the NXdata group only when + defining the default plot is not practical or possible + from the available data. + + For example, neutron event data may not have anything that + makes a useful plot without extensive processing. + + Certain application definitions override this decision and + require an :ref:`NXdata` group + in the :ref:`NXentry` group. The ``minOccurs=0`` attribute + in the application definition will indicate the + :ref:`NXdata` group + is optional, otherwise, it is required. + + .. [#] NIAC2016: + https://www.nexusformat.org/NIAC2016.html, + https://github.com/nexusformat/NIAC/issues/16 + + + + + + + ISIS Muon IDF_Version + + + Extended title for entry + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or NXentry + + + User or Data Acquisition defined group of NeXus files or NXentry + + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + unique identifier for the measurement, defined by the facility. + + + UUID identifier for the measurement. + Version of UUID used + + + UUID identifier for the measurement. + Version of UUID used + - - City and country where the experiment took place - + City and country where the experiment took place - Start time of experimental run that includes the current - measurement, for example a beam time. + Start time of experimental run that includes the current + measurement, for example a beam time. @@ -297,12 +171,107 @@ How do we set a default value for the type attribute?--> Name of the laboratory or beamline - - - - - - - - + + + Reserved for future use by NIAC. + + See https://github.com/nexusformat/definitions/issues/382 + + + + + (alternate use: see same field in :ref:`NXsubentry` for preferred) + + Official NeXus NXDL schema to which this entry conforms which must be + the name of the NXDL file (case sensitive without the file extension) + that the NXDL schema is defined in. + + For example the ``definition`` field for a file that conformed to the + *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. + + This field is provided so that :ref:`NXentry` can be the overlay position + in a NeXus data file for an application definition and its + set of groups, fields, and attributes. + + *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. + + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the entry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the entry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The mime type should be an ``image/*`` + + + + + + + + + + + + + + diff --git a/base_classes/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 5d2a59ed70..91ba2549e1 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 @@ -104,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. - - diff --git a/base_classes/NXevent_data.nxdl.xml b/base_classes/NXevent_data.nxdl.xml index ede968baf7..7e9c173433 100644 --- a/base_classes/NXevent_data.nxdl.xml +++ b/base_classes/NXevent_data.nxdl.xml @@ -3,7 +3,7 @@ - - - - .. 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 fresnel zone plate. - - - "Engineering" position of the fresnel zone plate - - 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/NXgeometry.nxdl.xml b/base_classes/NXgeometry.nxdl.xml index bb3b688a09..d978f58739 100644 --- a/base_classes/NXgeometry.nxdl.xml +++ b/base_classes/NXgeometry.nxdl.xml @@ -3,7 +3,7 @@ - - - - .. 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 bending grating. - diff --git a/base_classes/NXguide.nxdl.xml b/base_classes/NXguide.nxdl.xml index cd1fd5bb03..7d399e3f11 100644 --- a/base_classes/NXguide.nxdl.xml +++ b/base_classes/NXguide.nxdl.xml @@ -3,7 +3,7 @@ - - - .. 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 entry opening of the guide lies on the reference plane. The center of the opening on that plane is the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends @@ -215,16 +195,7 @@ .. image:: guide/guide.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/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml similarity index 68% rename from contributed_definitions/NXhistory.nxdl.xml rename to base_classes/NXhistory.nxdl.xml index 4208410914..8b4c191335 100644 --- a/contributed_definitions/NXhistory.nxdl.xml +++ b/base_classes/NXhistory.nxdl.xml @@ -3,7 +3,7 @@ - - - Any physical process that was performed on the physical entity prior or during the - experiment. - - - - - Any chemical process that was performed on the physical entity prior or during the + Any activity that was performed on the physical entity prior or during the experiment. - + An ID or reference to the location or a unique (globally persistent) identifier of e.g. another file which gives as many as possible details of the history event. - - - + + A descriptor to keep track of the treatment of the physical entity before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities + using the base classes above. This group can also be used to pull in any activities that are not well described by an existing base class definition. + + Any number of instances of NXnote are allowed for describing extra details of + this activity. diff --git a/base_classes/NXinsertion_device.nxdl.xml b/base_classes/NXinsertion_device.nxdl.xml index b4d264c28d..4c3eace644 100644 --- a/base_classes/NXinsertion_device.nxdl.xml +++ b/base_classes/NXinsertion_device.nxdl.xml @@ -3,7 +3,7 @@ - - - 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 - - - + + + 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 + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - + + + + - - - - - - + + + + + + - - - - - - - - .. 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/NXlog.nxdl.xml b/base_classes/NXlog.nxdl.xml index 813d0e918d..66d218ac71 100644 --- a/base_classes/NXlog.nxdl.xml +++ b/base_classes/NXlog.nxdl.xml @@ -3,7 +3,7 @@ - + - A wavelength defining device. - - This is a base class for everything which - selects a wavelength or energy, be it a - monochromator crystal, a velocity selector, - an undulator or whatever. - - The expected units are: - - * wavelength: angstrom - * energy: eV + A wavelength defining device. + + This is a base class for everything which + selects a wavelength or energy, be it a + monochromator crystal, a velocity selector, + an undulator or whatever. + + The expected units are: + + * wavelength: angstrom + * energy: eV + - - wavelength selected - - - - - wavelength standard deviation - + wavelength selected + + + wavelength standard deviation - - wavelength standard deviation - + wavelength standard deviation - - energy selected - - - - - energy standard deviation - - + energy selected + + + energy standard deviation + - - energy standard deviation - + energy standard deviation - + - Energy dispersion at the exit slit, typically given as eV/mm. + Energy dispersion at the exit slit. - + Wavelength dispersion at the exit slit. @@ -85,56 +80,20 @@ Size, position and shape of the exit slit of the monochromator. - + - - This group describes the shape of the beam line component - - - - - Use as many crystals as necessary to describe - - - - - - For diffraction grating based monochromators + + This group describes the shape of the beam line component - - - .. 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. - - + Use as many crystals as necessary to describe + + For diffraction grating based monochromators - 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 monochromator. + .. todo:: + Add a definition for the reference point of a monochromator. - - - 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/NXnote.nxdl.xml b/base_classes/NXnote.nxdl.xml index b1fe185214..2f677b8879 100644 --- a/base_classes/NXnote.nxdl.xml +++ b/base_classes/NXnote.nxdl.xml @@ -3,7 +3,7 @@ - + + + + + + + + NXlog group containing logged values of GROUPNAME. + + + + + Target values of FIELDNAME. + + + + + Uncertainties of FIELDNAME values. + + + + + Weights of FIELDNAME values. + + + + + Boolean mask of FIELDNAME values. The value is masked if set to 1. + + + + + An identifier for a (persistent) resource. + + An identifier, provided by some authority, that has been assigned to an + object described by this ``NXobject``. To be useful, the identifier + must not be reassigned to a different real-world object. It is typical for + there to be some mechanism to resolve an identifier, obtaining metadata + about the object. Identifiers for which some guarantees exist regarding + this resolution process are called persistent identifiers. + Persistent identifiers are also known as PIDs. + + + + The type of identifier used. + + It is recommended to use the most specific type when describing the identifier. + + For example, all IGSNs (see below) are DOIs and all DOIs are Handles; however, an IGSN should have type IGSN (and not DOI or Hdl). + Similarly, an ARK, Purl, ORCID and ROR identifiers should have their corresponding types and should not use the more generic URL identifier. + + + + + Archival Resource Key. + + An ARK is a Uniform Resource Identifier (URI) designed to support long-term access to a variety of information objects. + + Syntax: https://NMA/ark:/NAAN/Name[Qualifier]. Brackets indicate optional elements. + Example: https://example.org/ark:/12345/abcde + + + + + Digital Object Identifier. + + A DOI is a unique alphanumeric string used to identify digital content. It consists of a prefix and a suffix, separated by a slash. + + Syntax: 10.XXXX/XXXXXX + Example: 10.1107/S1600576714027575 + + + + + A handle is a unique identifier that consists of a prefix indicating the naming authority and a suffix representing the local name + of a resource. + + A handle is a unique identifier used to facilitate the identification and management of digital objects. It is composed of a prefix that + indicates the naming authority and a suffix that specifies the resource's local name. + + This refers specifically to an ID in the Handle system operated by the Corporation for National Research Initiatives (CNRI). + + Syntax: prefix/identifier + Example: 123456789/abc123 + + + + + International Generic Sample Number. + + The IGSN is a unique identifier assigned to a specific sample or specimen in the context of scientific research. + Since 2021, IGSNs are issued by DataCite, meaning that there are now DataCite-issued DOIs for all IGSNs, + including those historical IGSNs issued beforehand. Therefore, the syntax is the same as for DOIs. + + Syntax: 10.XXXX/XXXXXX + Example: 10.1107/S1600576714027575 + + + + + ISNI is an ISO standard to uniquely identify individuals and organizations involved in creative work, including pseudonyms + and other public personas. + + An ISNI-ID is made up of 16 digits, the last character being a check character. The check character may be either a decimal digit + or the character “X”. + + A URL can be generated from the ISNI ID by combining it with the prefix https://isni.org/isni/, resulting in + https://isni.org/isni/{ISNI-ID}. + + Syntax: 16 base-10 digits stored without any spaces. + Example: 0000000121032683 + + + + + International Standard Serial Number + + An ISSN is an 8-digit unique identifier used to distinguish a serial publication, whether in print or electronic form. + The last character (a digit or 'X') serves as a check character, making the ISSN uniquely defined by its first seven digits. + + Syntax: NNNN-NNNC, where N a decimal digit character (i.e., in the set {0,1,2,...,9}), and C is in {0,1,2,...,9,X} + Example: 1234-5678 or 1234-567X + + + + + Linking ISSN + + The linking ISSN, or ISSN-L, is a specific ISSN that groups the different media of the same serial publication. + + Syntax: NNNN-NNNC, where N a decimal digit character (i.e., in the set {0,1,2,...,9}), and C is in {0,1,2,...,9,X} + Example: 1234-5678 or 1234-567X + + + + + Open Researcher and Contributor identifier. + + ORCID provides a free and persistent identifier that uniquely distinguishes authors and contributors in scientific research. + + Syntax: https://orcid.org/XXXX-XXXX-XXXX-XXXX + Example: https://orcid.org/0000-0002-1825-0097 + + + + + Persistent Uniform Resource Locator. + + A Persistent Uniform Resource Locator (PURL) is a type of URL designed to provide a stable, long-term reference to a web + resource by using a resolver to redirect users to the resource's current location, even if it moves over time. + + A PURL has three parts: (1) a protocol, (2) a resolver address, and (3) a name. + + Syntax: https://purl.org/foo/bar + Example: https://purl.org/dc/elements/1.1/title + + + + + Research Organization Registry + + A ROR ID is a globally unique identifier for research organizations, enabling unambiguous linking of institutions across systems. + + Syntax: https://ror.org/{ROR-ID} + Example: https://ror.org/052gg0110 + + + + + Uniform Resource Locator + + Also known as web address, a URL is the address used to access a resource on the internet, + specifying its location and the protocol to retrieve it. + + Syntax: scheme://domain:port/path?query_string#fragment_id + Example: https://www.example.com/about + + + + + Uniform Resource Name + + A URN is a unique, persistent identifier for a resource regardless of where it is stored. + + It is recommended that identifiers with more specific type attribute (such as DOI or ISSN) values should not be stored as a URN, + even when this is valid. As an example, the URN doi:10.1107/S1600576714027575 is a valid URN-based representation for the DOI + 10.1107/S1600576714027575, but it is recommended to use type="DOI" in this case. + + Syntax: urn:<namespace>:<namespace-specific-string>. The leading urn: sequence is case-insensitive. + Example: urn:isbn:0000000000000 + + + + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group or a group using a base class + extending :ref:`NXdata`. + + 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/NXoff_geometry.nxdl.xml b/base_classes/NXoff_geometry.nxdl.xml index ec5e145853..e7e932122a 100644 --- a/base_classes/NXoff_geometry.nxdl.xml +++ b/base_classes/NXoff_geometry.nxdl.xml @@ -3,7 +3,7 @@ A parameter (also known as a term) that is used in or results from processing. - - - .. 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/NXpdb.nxdl.xml b/base_classes/NXpdb.nxdl.xml index 98407dbb4f..5f3317f7cf 100644 --- a/base_classes/NXpdb.nxdl.xml +++ b/base_classes/NXpdb.nxdl.xml @@ -3,7 +3,7 @@ - + - A generic positioner such as a motor or piezo-electric transducer. + A generic positioner such as a motor or piezo-electric transducer. - - symbolic or mnemonic name (one word) - + symbolic or mnemonic name (one word) - - description of positioner - + description of positioner - - best known value of positioner - need [n] as may be scanned - - - - + best known value of positioner - need [n] as may be scanned + - - raw value of positioner - need [n] as may be scanned - - - - + raw value of positioner - need [n] as may be scanned + - - targeted (commanded) value of positioner - need [n] as may be scanned - - - - + targeted (commanded) value of positioner - need [n] as may be scanned + - - maximum allowable difference between target_value and value - - - - + maximum allowable difference between target_value and value + - - minimum allowed limit to set value - + minimum allowed limit to set value - - maximum allowed limit to set value - + maximum allowed limit to set value - - velocity of the positioner (distance moved per unit time) - + velocity of the positioner (distance moved per unit time) - - time to ramp the velocity up to full speed - + time to ramp the velocity up to full speed - + - - Hardware device record, e.g. EPICS process variable, taco/tango. - + Hardware device record, e.g. EPICS process variable, taco/tango ... - 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 positioner. + .. todo:: + Add a definition for the reference point of a positioner. - - - 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. - - - The actuator of the positioner which is responsible for the movement of the - probe. + The actuator of the positioner which is responsible for the movement of the + probe. - + - The feedback of the actual position of the positioner. + The feedback of the actual position of the positioner. - If present, the value and the value_log of this pv_sensor is the same as - the value and raw_value of the position itself. + If present, the value and the value_log of this pv_sensor is the same as + the value and raw_value of the position itself. diff --git a/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index ac5a8b81de..2dac1278af 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -1,9 +1,9 @@ - + - - - Document an event of data processing, reconstruction, or analysis for this data. - + + Document an event of data processing, reconstruction, or analysis for this data. - - Name of the program used - + Name of the program used - Sequence index of processing, - for determining the order of multiple **NXprocess** steps. - Starts with 1. + Sequence index of processing, + for determining the order of multiple **NXprocess** steps. + Starts with 1. - - Version of the program used - + Version of the program used - - Date and time of processing. - + Date and time of processing. - - - Describes the operations of image registration - - - - - Describes the operations of image distortion correction - - - - - Describes the operations of calibration procedures, e.g. axis calibrations. - - - The note will contain information about how the data was processed - or anything about the data provenance. - The contents of the note can be anything that the processing code - can understand, or simple text. - - The name will be numbered to allow for ordering of steps. + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or simple text. + + The name will be numbered to allow for ordering of steps. - - - .. 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/NXreflections.nxdl.xml b/base_classes/NXreflections.nxdl.xml index 1b0be97f7d..560964ac03 100644 --- a/base_classes/NXreflections.nxdl.xml +++ b/base_classes/NXreflections.nxdl.xml @@ -645,17 +645,4 @@ Describes the dataset - - - .. 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/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 83% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml index 7314742c57..313385cc4c 100644 --- a/contributed_definitions/NXregistration.nxdl.xml +++ b/base_classes/NXregistration.nxdl.xml @@ -3,7 +3,7 @@ - + Describes image registration procedures. @@ -30,11 +30,6 @@ Has the registration been applied? - - - Indicates the name of the last operation applied in the NXprocess sequence. - - Specifies the position by pointing to the last transformation in the diff --git a/base_classes/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml new file mode 100644 index 0000000000..c5856f6a4d --- /dev/null +++ b/base_classes/NXresolution.nxdl.xml @@ -0,0 +1,102 @@ + + + + + + Describes the resolution of a physical quantity. + + + + The physical quantity of the resolution, e.g., + energy, momentum, time, area, etc. + + + + + The process by which the resolution was determined. + + + + + + + + + + + Additional details of the estimate or description of the calibration procedure + + + + + The resolution of the physical quantity. + + + + + Standard deviation of the resolution of the physical quantity. + + + + + Ratio of the resolution at a specified measurand value to that measurand value. + + + + + Standard deviation of the relative resolution of the physical quantity. + + + + + The response of the instrument or part of the instrument to a infinitesimally sharp input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the full width at half maximum (FWHM) + of the response function. + + This could have an AXISNAME field ```input``` (the input axis or grid of the response function) + and a ``DATA`` field ```magnitude```. Both of these should have the same unit. The dimensions + should match those of the :ref:`resolution </NXresolution/resolution-field>` field. + + + + + Symbols linking to another path in the NeXus tree to be referred to from the + `resolution_formula_description` field. The ``TERM`` should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field. + + + + + A description of the resolution formula to determine the resolution from a set of symbols as + entered by the `formula_...` fields. This should be an english description of the math used. + + + + + For storing details and data of a calibration to derive a resolution from data. + + + diff --git a/base_classes/NXroot.nxdl.xml b/base_classes/NXroot.nxdl.xml index 68c179c8c4..cd6b894880 100644 --- a/base_classes/NXroot.nxdl.xml +++ b/base_classes/NXroot.nxdl.xml @@ -1,9 +1,9 @@ - - + + - - - Definition of the root NeXus group. - + + Definition of the root NeXus group. - The root of any NeXus data file is an ``NXroot`` class - (no other choice is allowed for a valid NeXus data file). - This attribute cements that definition. + The root of any NeXus data file is an ``NXroot`` class + (no other choice is allowed for a valid NeXus data file). + This attribute cements that definition. - + - - Date and time file was originally created - + Date and time file was originally created - - File name of original NeXus file - + File name of original NeXus file - - Date and time of last file change at close - + Date and time of last file change at close - + - A repository containing the application definitions - used for creating this file. - If the NeXus_version attribute contains a commit distance and hash - this should refer to this repository. + Version of NeXus API used in writing the file. + + Note that this is different from the version of the + base class or application definition version number. - + - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. - - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. + A repository containing the application definitions + used for creating this file. + If the ``NeXus_release`` attribute contains a commit distance and hash, + this should refer to this repository. - + - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. + The version of NeXus definitions used in writing the file. This can either be a date-based + NeXus release (e.g., YYYY.MM), see https://github.com/nexusformat/definitions/releases or + a version tag that includes additional development information, such as a commit distance and + a Git hash. This is typically formatted as `vYYYY.MM.post1.dev<commit-distance>-g<git-hash>`, + where `YYYY.MM` refers to the base version of the NeXus definitions. `post1.dev<commit-distance>` + indicates that the definitions are based on a commit after the base version (post1), with + `<commit-distance>` being the number of commits since that version. `g<git-hash>` is the + abbreviated Git hash that identifies the specific commit of the definitions being used. + + If the version includes both a commit distance and a Git hash, the ``NeXus_repository`` + attribute must be included, specifying the URL of the repository containing that version. - - Version of HDF (version 4) library used in writing the file - + Version of HDF (version 4) library used in writing the file - Version of HDF5 library used in writing the file. - - Note this attribute is spelled with uppercase "V", - different than other version attributes. + Version of HDF5 library used in writing the file. + + Note this attribute is spelled with uppercase "V", + different than other version attributes. - - Version of XML support library used in writing the XML file - + Version of XML support library used in writing the XML file + Version of h5py Python package used in writing the file + + - Version of h5py Python package used in writing the file + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. - - facility or program where file originated - + facility or program where file originated - - Version of facility or program used in writing the file - + Version of facility or program used in writing the file - - - entries - + + entries - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXentry` group contains - the data to be shown by default. - It is used to resolve ambiguity when - more than one :ref:`NXentry` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus 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:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXentry` group contains + the data to be shown by default. + It is used to resolve ambiguity when + more than one :ref:`NXentry` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus 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. - + \ No newline at end of file diff --git a/base_classes/NXsample.nxdl.xml b/base_classes/NXsample.nxdl.xml index 1ac42099ce..10717cb594 100644 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - - symbolic array lengths to be coordinated between various fields - - - - number of compositions - - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - Any information on the sample. - - This could include scanned variables that - are associated with one of the data dimensions, e.g. the magnetic field, or - logged data, e.g. monitored temperature vs elapsed time. - - - - Descriptive name of sample - - - - - Identification number or signatures of the sample used. - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - * This is the *Hill* system used by Chemical Abstracts. - - - - - Sample temperature. This could be a scanned variable - - - - - - - - - Applied electric field - - - - - + + + + symbolic array lengths to be coordinated between various fields + number of compositions + number of temperatures + number of values in applied electric field + number of values in applied magnetic field + number of values in applied pressure field + number of values in applied stress field + + + + Any information on the sample. + + This could include scanned variables that + are associated with one of the data dimensions, e.g. the magnetic field, or + logged data, e.g. monitored temperature vs elapsed time. + + + Descriptive name of sample + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + * This is the *Hill* system used by Chemical Abstracts. + + + + Sample temperature. This could be a scanned variable + + + + + + Applied electric field + + + - - - - - + + + + + - - - - Applied magnetic field - - - - - + + + Applied magnetic field + + + - - - - - + + + + + - - - - Applied external stress field - - - - - + + + Applied external stress field + + + - - - - - + + + + + - - - - Applied pressure - - - - - - - - - Sample changer position - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Unit cell parameters (lengths and angles) - - - - - - - - - Volume of the unit cell - - - - - - - - This will follow the Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - Orientation matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 - - - - - - - - - - UB matrix of single crystal sample using Busing-Levy convention: - W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is - the multiplication of the orientation_matrix, given above, - with the :math:`B` matrix which - can be derived from the lattice constants. - - - - - + + + Applied pressure + + + + + + Sample changer position + + + Crystallography unit cell parameters a, b, and c + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + Unit cell parameters (lengths and angles) + + + + + + + Volume of the unit cell + + + + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which + can be derived from the lattice constants. + + + + + + + + + Mass of sample + + + + + + Density of sample + + + + + + Relative Molecular Mass of sample + + + + + + + + + + + + + + + + + + + + + The atmosphere will be one of the components, which is where + its details will be stored; the relevant components will be + indicated by the entry in the sample_component member. + + + + + + + + + + + + + + Description of the sample + + + + Date of preparation of the sample + + + The position and orientation of the center of mass of the sample + + + Details of beam incident on sample - used to calculate sample/beam interaction point + + + + One group per sample component + This is the perferred way of recording per component information over the n_comp arrays + + + + Details of the component of the sample and/or can + + + + + + Type of component + + + + + + + + + + + + Concentration of each component + + + + + + Volume fraction of each component + + + + + + Scattering length density of each component + + + + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + Crystallographic space group + + + + + + Crystallographic point group, deprecated if space_group present + + - - - - Mass of sample - - - - - - - - Density of sample - - - - - - - - Relative Molecular Mass of sample - - - - - - - - - - - - - - - - - - - - - - The atmosphere will be one of the components, which is where - its details will be stored; the relevant components will be - indicated by the entry in the sample_component member. - - - - - - - - - - - - - - Description of the sample - - - - - Date of preparation of the sample - - - - - The position and orientation of the center of mass of the sample - - - - - Details of beam incident on sample - used to calculate sample/beam interaction - point - - - - - One group per sample component - This is the perferred way of recording per component information over the n_comp arrays - - - - - Details of the component of the sample and/or can - - - - - - - - Type of component - - - - - - - - - - - - - - Concentration of each component - - - - - - - - Volume fraction of each component - - - - - - - - Scattering length density of each component - - - - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - - - - Crystallographic point group, deprecated if space_group present - - - - - - - - Path length through sample/can for simple case when - it does not vary with scattering direction - - - - - Thickness of a beam entry/exit window on the can (mm) - - assumed same for entry and exit - - - - - sample thickness - - - - - As a function of Wavelength - - - - - temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value - - - - - Additional sample temperature environment information - - - - - magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value - - - - - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value - - - - - Additional sample magnetic environment information - - - - - value sent to user's sample setup - - - - - logged value (or logic state) read from user's setup - - - - - 20 character fixed length sample description for legends - - - - - - Optional rotation angle for the case when the powder diagram has - been obtained through an omega-2theta scan like from a traditional - single detector powder diffractometer. - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the X-direction of the laboratory coordinate system - Note, it is recommended to use NXtransformations instead. - - - - - Translation of the sample along the Z-direction of the laboratory coordinate system. - Note, it is recommended to use NXtransformations instead. - - - - - Any positioner (motor, PZT, ...) used to locate the sample - - - - - - This group describes the shape of the sample - - - - - Physical form of the sample material. - Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. - - - - - If the sample is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - - - - - - Details about the sample vendor (company or research group) - - - - - An (ideally) globally unique identifier for the sample. - - - - - - Any environmental or external stimuli/measurements. - These can include, among others: - applied pressure, surrounding gas phase and gas pressure, - external electric/magnetic/mechanical fields, temperature, ... - - - - - A set of physical processes that occurred to the sample prior/during experiment. - - - - - .. 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. - - - - - 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. - - + + + + Path length through sample/can for simple case when + it does not vary with scattering direction + + + + + Thickness of a beam entry/exit window on the can (mm) + - assumed same for entry and exit + + + + sample thickness + + + As a function of Wavelength + + + temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value + + + Additional sample temperature environment information + + + magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value + + + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value + + + Additional sample magnetic environment information + + + value sent to user's sample setup + + + logged value (or logic state) read from user's setup + + + 20 character fixed length sample description for legends + + + + + Optional rotation angle for the case when the powder diagram has + been obtained through an omega-2theta scan like from a traditional + single detector powder diffractometer. + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the X-direction of the laboratory coordinate system + Note, it is recommended to use NXtransformations instead. + + + + + Translation of the sample along the Z-direction of the laboratory coordinate system. + Note, it is recommended to use NXtransformations instead. + + + + Any positioner (motor, PZT, ...) used to locate the sample + + + + This group describes the shape of the sample + + + + + + Physical form of the sample material. + Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. + + + + + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/mechanical fields, temperature, ... + + + + + A set of physical processes that occurred to the sample prior/during experiment. + + diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index ac9b3a1275..a3eda86d89 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - - symbolic array lengths to be coordinated between various fields - - - - number of temperatures - - - - - number of values in applied electric field - - - - - number of values in applied magnetic field - - - - - number of values in applied pressure field - - - - - number of values in applied stress field - - - - - One group like this per component can be recorded For a sample consisting of - multiple components. - - - - Descriptive name of sample component - - - - - Identification number or signatures of the sample component used. - - - - - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard: - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - - * This is the *Hill* system used by Chemical Abstracts. - - - - - Crystallography unit cell parameters a, b, and c - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma - - - - - - - - Volume of the unit cell - - - - - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 - (1967) - - - - - - - - Orientation matrix of single crystal sample component. - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) - - - - - - - - - Mass of sample component - - - - - Density of sample component - - - - - Relative Molecular Mass of sample component - - - - - Description of the sample component - - - - - Volume fraction of component - - - - - Scattering length density of component - - - - - In case it is all we know and we want to record/document it - - - - - - - - - - - - - - Crystallographic space group - - - - - Crystallographic point group, deprecated if space_group present - - - - - As a function of Wavelength - - - - - If the component is a single crystal, add description of single crystal and unit - cell. - - - - - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - - - - - - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - - - - - - Details about the sample component vendor (company or research group) - - + + + + symbolic array lengths to be coordinated between various fields + number of temperatures + number of values in applied electric field + number of values in applied magnetic field + number of values in applied pressure field + number of values in applied stress field + + + + One group like this per component can be recorded for a sample consisting of multiple components. + + + Descriptive name of sample component + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + * This is the *Hill* system used by Chemical Abstracts. + + + + Crystallography unit cell parameters a, b, and c + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + Volume of the unit cell + + + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + Orientation matrix of single crystal sample component. + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) + + + + + + + + Mass of sample component + + + Density of sample component + + + Relative Molecular Mass of sample component + + + + Description of the sample component + + + + Volume fraction of component + + + Scattering length density of component + + + + In case it is all we know and we want to record/document it + + + + + + + + + + + + + Crystallographic space group + + + Crystallographic point group, deprecated if space_group present + + + As a function of Wavelength + A set of physical processes that occurred to the sample component prior/during experiment. - - - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - - - - - .. 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/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 3e01482037..3350cad325 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. - - - 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. + .. 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/NXshape.nxdl.xml b/base_classes/NXshape.nxdl.xml index 31f903cdc9..1e75b9199e 100644 --- a/base_classes/NXshape.nxdl.xml +++ b/base_classes/NXshape.nxdl.xml @@ -3,7 +3,7 @@ - - - Radiation source emitting a beam. - - Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). - This base class can also be used to describe neutron or x-ray storage ring/facilities. - - - - 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) - - - - - - - - - - - - - - - + + + Radiation source emitting a beam. + + Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). + This base class can also be used to describe neutron or x-ray storage ring/facilities. + + + + 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) + + + + + + + + + + + + + + - + - + - + - - - - - - Specification of type, may also go to name. - - - - - 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. Typically, this would be the energy of - the emitted beam. For storage rings, this would be - the particle beam energy. - - - - - 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 wavelength of the radiation emitted by the source. - - - - - For pulsed sources, the energy of a single pulse. - - - - - For pulsed sources, the pulse energy divided - by the pulse duration - - - - - Material of the anode (for X-ray tubes). - - - - - Filament current (for X-ray tubes). - - - - - Emission current of the generated beam. - - - - - Gas pressure inside ionization source. - - + + + 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. Typically, this would be the energy of + the emitted beam. For storage rings, this would be + the particle beam energy. + + + + 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 wavelength of the radiation emitted by the source. + + + + + For pulsed sources, the energy of a single pulse. + + + + + For pulsed sources, the pulse energy divided + by the pulse duration + + + + + Material of the anode (for X-ray tubes). + + + + + Filament current (for X-ray tubes). + + + + + Emission current of the generated beam. + + + + + Gas pressure inside ionization source. + + Single instance or list of instances of NXsource pointing to the sources from which a beam originated to reach this source. This can be used, for example, for secondary sources to describe which other source(s) they are derived from. - + An example is the white light source in transient absorption spectroscopy, which is a supercontinuum crystal that is pumped by a another laser. - + In case of a primary source, this field should not be filled. - - - "Engineering" location of source. - - - - - The size and position of an aperture inside the source. - - - - - Deflectors inside the source. - - - - - Individual electromagnetic lenses inside the 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. - - - + + + "Engineering" location of source. + + + + + The size and position of an aperture inside the source. + + + + + Deflectors inside the source. + + + + + + This group describes the shape of the beam line component + + + + The wavelength or energy distribution of the source + + + + 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% + + + + \ No newline at end of file diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index c5e72259d1..a707386a50 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -1,10 +1,10 @@ - - + + - - - Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. - - ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` - and is used as the (overlay) location for application definitions. - Use a separate ``NXsubentry`` for each application definition. - - To use ``NXsubentry`` with a hypothetical application definition - called ``NXmyappdef``: - - * Create a group with attribute ``NX_class="NXsubentry"`` - * Within that group, create a field called ``definition="NXmyappdef"``. - * There are two optional attributes of definition: ``version`` and ``URL`` - - The intended use is to define application definitions for a - multi-modal (a.k.a. multi-technique) :ref:`NXentry`. - Previously, an application definition - replaced :ref:`NXentry` with its own definition. - With the increasing popularity of instruments combining - multiple techniques for data collection (such as SAXS/WAXS instruments), - it was recognized the application definitions must be entered in the NeXus - data file tree as children of :ref:`NXentry`. - - - - .. index:: find the default plottable data - .. index:: plotting - .. index:: default attribute value - - Declares which :ref:`NXdata` group contains the data - to be shown by default. - It is used to resolve ambiguity when - one :ref:`NXdata` group exists. - The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The - value must be the name of a child of the current group. The child must be a - NeXus group or a link to a NeXus group. - - For more information about how NeXus identifies the default - plottable data, see the - :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` - section. - - - - - - ISIS Muon IDF_Version - - - - - Extended title for entry - - - - - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals - - - - - Brief summary of the experiment, including key objectives. - - - - - Description of the full experiment (document in pdf, latex, ...) - - - - - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - - - - - Brief summary of the collection, including grouping criteria. - + + + + + .. index:: find the default plottable data + .. index:: plotting + .. index:: default attribute value + + Declares which :ref:`NXdata` group contains the data + to be shown by default. + It is used to resolve ambiguity when + one :ref:`NXdata` group exists. + The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The + value must be the name of a child of the current group. The child must be a + NeXus group or a link to a NeXus group. + + For more information about how NeXus identifies the default + plottable data, see the + :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` + section. + + + + + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + + ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` + and is used as the (overlay) location for application definitions. + Use a separate ``NXsubentry`` for each application definition. + + To use ``NXsubentry`` with a hypothetical application definition + called ``NXmyappdef``: + + * Create a group with attribute ``NX_class="NXsubentry"`` + * Within that group, create a field called ``definition="NXmyappdef"``. + * There are two optional attributes of definition: ``version`` and ``URL`` + + The intended use is to define application definitions for a + multi-modal (a.k.a. multi-technique) :ref:`NXentry`. + Previously, an application definition + replaced :ref:`NXentry` with its own definition. + With the increasing popularity of instruments combining + multiple techniques for data collection (such as SAXS/WAXS instruments), + it was recognized the application definitions must be entered in the NeXus + data file tree as children of :ref:`NXentry`. + + + + + ISIS Muon IDF_Version + + + + Extended title for entry + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + + + + Brief summary of the experiment, including key objectives. + + + Description of the full experiment (document in pdf, latex, ...) + + + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + + + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + + + Brief summary of the collection, including grouping criteria. + + + unique identifier for the measurement, defined by the facility. + + + unique identifier for the measurement, defined by the facility. + + + City and country where the experiment took place - + - unique identifier for the measurement, defined by the facility. - - - - - Official NeXus NXDL schema to which this subentry conforms - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Local NXDL schema extended from the subentry - specified in the ``definition`` field. - This contains any locally-defined, - additional fields in the subentry. - - - - NXDL version number - - - - - URL of NXDL file - - - - - - Starting time of measurement - - - - - Ending time of measurement + Start time of experimental run that includes the current + measurement, for example a beam time. - + - Duration of measurement + End time of experimental run that includes the current + measurement, for example a beam time. - + - Time transpired actually collecting data i.e. taking out time when collection was - suspended due to e.g. temperature out of range + Name of the institution hosting the facility - + - Such as "2007-3". Some user facilities organize their beam time into run cycles. + Name of the experimental facility - + - Name of program used to generate this file + Name of the laboratory or beamline - - - Program version number - - - - - configuration of the program - - - - - Revision id of the file due to re-calibration, reprocessing, new analysis, new - instrument definition format, ... - - - - - - This is the flightpath before the sample position. This can be determined by a chopper, - by the moderator or the source itself. In other words: it the distance to the component - which gives the T0 signal to the detector electronics. If another component in the - NXinstrument hierarchy provides this information, this should be a link. - - - - - Notes describing entry - - - - - A small image that is representative of the entry. An example of this is a 640x480 - jpeg image automatically produced by a low resolution plot of the NXdata. - - - - The value should be an ``image/*`` - - - - - - - - - - - - - - - + + Official NeXus NXDL schema to which this subentry conforms + NXDL version number + URL of NXDL file + + + + Local NXDL schema extended from the subentry + specified in the ``definition`` field. + This contains any locally-defined, + additional fields in the subentry. + + NXDL version number + URL of NXDL file + + + Starting time of measurement + + + Ending time of measurement + + + Duration of measurement + + + + Time transpired actually collecting data i.e. taking out time when collection was + suspended due to e.g. temperature out of range + + + + Such as "2007-3". Some user facilities organize their beam time into run cycles. + + + Name of program used to generate this file + Program version number + configuration of the program + + + + Revision id of the file due to re-calibration, reprocessing, new analysis, new + instrument definition format, ... + + + + + + This is the flightpath before the sample position. This can be determined by a chopper, + by the moderator or the source itself. In other words: it the distance to the component + which gives the T0 signal to the detector electronics. If another component in the + NXinstrument hierarchy provides this information, this should be a link. + + + + Notes describing entry + + + + A small image that is representative of the entry. An example of this is a 640x480 + jpeg image automatically produced by a low resolution plot of the NXdata. + + + The value should be an ``image/*`` + + + + + + + + + + + + + + diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index 41d2d5d7da..4af8f7fe72 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -2,9 +2,9 @@ - Collection of axis-based translations and rotations to describe a geometry. - May also contain axes that do not move and therefore do not have a transformation - type specified, but are useful in understanding coordinate frames within which - transformations are done, or in documenting important directions, such as the - direction of gravity. - - A nested sequence of transformations lists the translation and rotation steps - needed to describe the position and orientation of any movable or fixed device. - - There will be one or more transformations (axes) defined by one or more fields - for each transformation. Transformations can also be described by NXlog groups when - the values change with time. The all-caps name ``AXISNAME`` designates the - particular axis generating a transformation (e.g. a rotation axis or a translation - axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the - units will be appropriate to the ``transformation_type`` attribute: - - * ``NX_LENGTH`` for ``translation`` - * ``NX_ANGLE`` for ``rotation`` - * ``NX_UNITLESS`` for axes for which no transformation type is specified - - This class will usually contain all axes of a sample stage or goniometer or - a detector. The NeXus default :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` - is assumed, but additional useful coordinate axes may be defined by using axes for which - no transformation type has been specified. - - **Transformation chain** - - The entry point of a chain of transformations is a field called ``depends_on`` - will be outside of this class and points to a field in here. Following the chain may - also require following ``depends_on`` links to transformations outside, for example - to a common base table. If a relative path is given, it is relative to the group - enclosing the ``depends_on`` specification. - - For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` - which in turn depends on :math:`T_3`, the final *active* transformation - matrix :math:`T_f` is - - .. math:: T_f = T_3 . T_2 . T_1 - - For example when positioning a flat detector, its pixel positions in the laboratory - reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) - can be calculated by - - .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} - - Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first - to the pixel coordinates. - - When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that - the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. - So the activate coordinate transformation :math:`A` needs to be applied to a coordinate - before applying :math:`B`. In other words :math:`X' = B . A . X`. - - **Transformation matrix** - - In explicit terms, the transformations are a subset of affine transformations expressed as - 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. - - For rotation and translation, - - .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} - - where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, - :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and - :math:`t` is the translation vector. - - :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` - attribute multiplied by the field value, and :math:`R` is defined as a rotation - about an axis in the direction of ``vector``, of angle of the field value. - - **Usage** - - One possible use of ``NXtransformations`` is to define the motors and - transformations for a diffractometer (goniometer). Such use is mentioned - in the ``NXinstrument`` base class. Use one ``NXtransformations`` group - for each diffractometer and name the group appropriate to the device. - Collecting the motors of a sample table or xyz-stage in an NXtransformations - group is equally possible. - - Following the section on the general description of axis in NXtransformations is a section which - documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever - there is a need for positioning a beam line component please use the existing names. Use as many fields - as needed in order to position the component. Feel free to add more axis if required. In the description - given below, only those atttributes which are defined through the name are spcified. Add the other attributes - of the full set: - - * vector - * offset - * transformation_type - * depends_on - - as needed. - - **Example 1: goniometer** - - Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. - - The sample is oriented as follows - - .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s - - where - - * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` - * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` - * :math:`X_s` a coordinate in the sample reference frame. - - .. code-block:: - - entry:NXentry - sample:NXsample - depends_on=transformations/phi - transformations:NXtransformations - phi=0 - @depends_on=chi - @transformation_type=rotation - @vector=[-1 -0.0037 -0.002] - @units=degrees - chi=0 - @depends_on=sam_x - @transformation_type=rotation - @vector=[0.0046 0.0372 0.9993] - @units=degrees - sam_x=0 - @depends_on=sam_y - @transformation_type=translation - @vector=[1 0 0] - @units=mm - sam_y=0 - @depends_on=sam_z - @transformation_type=translation - @vector=[0 1 0] - @units=mm - sam_z=0 - @depends_on=omega - @transformation_type=translation - @vector=[0 0 1] - @units=mm - omega=174 - @depends_on=. - @transformation_type=rotation - @vector=[-1 0 0] - @units=degrees - - **Example 2: different coordinate system** - - Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. - Three point detectors are positioned in this reference: - - * *transmission*: - * point detector in the beam - * 20 cm downstream from the sample (the origin of the reference frame) - * *vertical*: - * point detector 10 cm downstream from the sample - * making an angle of 5 degrees with the beam w.r.t. the sample - * positioned in the XZ-plane above the XY-plane - * *horizontal*: - * point detector 11 cm downstream from the sample - * making an angle of 6 degrees with the beam w.r.t. the sample - * positioned in the XY-plane above the XZ-plane - - The coordinates of the point detectors in the laboratory reference frame are - - * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` - * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` - * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` - - where - - * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes - * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes - * :math:`X_d` is a coordinate in the detector reference frame. - - Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. - - .. code-block:: - - entry:NXentry - instrument:NXinstrument - vertical:NXdetector - depends_on=position/distance - position:NXtransformations - distance=10 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=5 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=0 # stay in the vertical plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - horizontal:NXdetector - depends_on=position/distance - position:NXtransformations - distance=11 # move downstream from the sample - @depends_on=polar - @units=cm - @vector=[1 0 0] - polar=6 # title above the horizontal plane - @depends_on=azimuth - @units=degrees - @vector=[0 -1 0] - azimuth=90 # rotate to the horizontal plane - @depends_on=/entry/coordinate_system/beam - @units=degrees - @vector=[-1 0 0] - transmission:NXdetector - depends_on=position/distance - position:NXtransformations - distance=20 # move downstream from the sample - @depends_on=/entry/coordinate_system/beam - @units=cm - @vector=[1 0 0] - coordinate_system:NXtransformations - beam=NaN # value is never used - @depends_on=gravity - @vector=[1 0 0] # X-axis points in the beam direction - gravity=NaN # value is never used - @depends_on=. # end of the chain - @vector=[0 0 -1] # Z-axis points up + Collection of axis-based translations and rotations to describe a geometry. + May also contain axes that do not move and therefore do not have a transformation + type specified, but are useful in understanding coordinate frames within which + transformations are done, or in documenting important directions, such as the + direction of gravity. + + A nested sequence of transformations lists the translation and rotation steps + needed to describe the position and orientation of any movable or fixed device. + + There will be one or more transformations (axes) defined by one or more fields + for each transformation. Transformations can also be described by NXlog groups when + the values change with time. The all-caps name ``AXISNAME`` designates the + particular axis generating a transformation (e.g. a rotation axis or a translation + axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the + units will be appropriate to the ``transformation_type`` attribute: + + * ``NX_LENGTH`` for ``translation`` + * ``NX_ANGLE`` for ``rotation`` + * ``NX_UNITLESS`` for axes for which no transformation type is specified + + This class will usually contain all axes of a sample stage or goniometer or + a detector. The NeXus default :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` + is assumed, but additional useful coordinate axes may be defined by using axes for which + no transformation type has been specified. + + **Transformation chain** + + The entry point of a chain of transformations is a field called ``depends_on`` + will be outside of this class and points to a field in here. Following the chain may + also require following ``depends_on`` links to transformations outside, for example + to a common base table. If a relative path is given, it is relative to the group + enclosing the ``depends_on`` specification. + + For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` + which in turn depends on :math:`T_3`, the final *active* transformation + matrix :math:`T_f` is + + .. math:: T_f = T_3 . T_2 . T_1 + + For example when positioning a flat detector, its pixel positions in the laboratory + reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) + can be calculated by + + .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} + + Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first + to the pixel coordinates. + + When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that + the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. + So the activate coordinate transformation :math:`A` needs to be applied to a coordinate + before applying :math:`B`. In other words :math:`X' = B . A . X`. + + **Transformation matrix** + + In explicit terms, the transformations are a subset of affine transformations expressed as + 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. + + For rotation and translation, + + .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} + + where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, + :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and + :math:`t` is the translation vector. + + :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` + attribute multiplied by the field value, and :math:`R` is defined as a rotation + about an axis in the direction of ``vector``, of angle of the field value. + + **Usage** + + One possible use of ``NXtransformations`` is to define the motors and + transformations for a diffractometer (goniometer). Such use is mentioned + in the ``NXinstrument`` base class. Use one ``NXtransformations`` group + for each diffractometer and name the group appropriate to the device. + Collecting the motors of a sample table or xyz-stage in an NXtransformations + group is equally possible. + + Following the section on the general description of axis in NXtransformations is a section which + documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever + there is a need for positioning a beam line component please use the existing names. Use as many fields + as needed in order to position the component. Feel free to add more axis if required. In the description + given below, only those atttributes which are defined through the name are spcified. Add the other attributes + of the full set: + + * vector + * offset + * transformation_type + * depends_on + + as needed. + + **Example 1: goniometer** + + Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. + + The sample is oriented as follows + + .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . + T(\vec{v}_z, \text{sam}_z) . + T(\vec{v}_y, \text{sam}_y) . + T(\vec{v}_x, \text{sam}_x) . + R(\vec{v}_\chi, \chi) . + R(\vec{v}_\varphi, \varphi) . X_s + + where + + * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` + * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` + * :math:`X_s` a coordinate in the sample reference frame. + + .. code-block:: + + entry:NXentry + sample:NXsample + depends_on=transformations/phi + transformations:NXtransformations + phi=0 + @depends_on=chi + @transformation_type=rotation + @vector=[-1 -0.0037 -0.002] + @units=degrees + chi=0 + @depends_on=sam_x + @transformation_type=rotation + @vector=[0.0046 0.0372 0.9993] + @units=degrees + sam_x=0 + @depends_on=sam_y + @transformation_type=translation + @vector=[1 0 0] + @units=mm + sam_y=0 + @depends_on=sam_z + @transformation_type=translation + @vector=[0 1 0] + @units=mm + sam_z=0 + @depends_on=omega + @transformation_type=translation + @vector=[0 0 1] + @units=mm + omega=174 + @depends_on=. + @transformation_type=rotation + @vector=[-1 0 0] + @units=degrees + + **Example 2: different coordinate system** + + Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. + Three point detectors are positioned in this reference: + + * *transmission*: + * point detector in the beam + * 20 cm downstream from the sample (the origin of the reference frame) + * *vertical*: + * point detector 10 cm downstream from the sample + * making an angle of 5 degrees with the beam w.r.t. the sample + * positioned in the XZ-plane above the XY-plane + * *horizontal*: + * point detector 11 cm downstream from the sample + * making an angle of 6 degrees with the beam w.r.t. the sample + * positioned in the XY-plane above the XZ-plane + + The coordinates of the point detectors in the laboratory reference frame are + + * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` + * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` + * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` + + where + + * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes + * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes + * :math:`X_d` is a coordinate in the detector reference frame. + + Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. + + .. code-block:: + + entry:NXentry + instrument:NXinstrument + vertical:NXdetector + depends_on=position/distance + position:NXtransformations + distance=10 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=5 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=0 # stay in the vertical plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + horizontal:NXdetector + depends_on=position/distance + position:NXtransformations + distance=11 # move downstream from the sample + @depends_on=polar + @units=cm + @vector=[1 0 0] + polar=6 # title above the horizontal plane + @depends_on=azimuth + @units=degrees + @vector=[0 -1 0] + azimuth=90 # rotate to the horizontal plane + @depends_on=/entry/coordinate_system/beam + @units=degrees + @vector=[-1 0 0] + transmission:NXdetector + depends_on=position/distance + position:NXtransformations + distance=20 # move downstream from the sample + @depends_on=/entry/coordinate_system/beam + @units=cm + @vector=[1 0 0] + coordinate_system:NXtransformations + beam=NaN # value is never used + @depends_on=gravity + @vector=[1 0 0] # X-axis points in the beam direction + gravity=NaN # value is never used + @depends_on=. # end of the chain + @vector=[0 0 -1] # Z-axis points up - + - Units need to be appropriate for translation or rotation - - The name of this field is not forced. The user is free to use any name - that does not cause confusion. When using more than one ``AXISNAME`` field, - make sure that each field name is unique in the same group, as required - by HDF5. - - The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. + Units need to be appropriate for translation or rotation + + The name of this field is not forced. The user is free to use any name + that does not cause confusion. When using more than one ``AXISNAME`` field, + make sure that each field name is unique in the same group, as required + by HDF5. + + The values given should be the start points of exposures for the corresponding + frames. The end points should be given in ``AXISNAME_end``. - - - The transformation_type may be ``translation``, in which case the - values are linear displacements along the axis, ``rotation``, - in which case the values are angular rotations around the axis. - - If this attribute is omitted, this is an axis for which there - is no motion to be specifies, such as the direction of gravity, - or the direction to the source, or a basis vector of a - coordinate frame. - - - - - - - - - - Three values that define the axis for this transformation. - The axis should be normalized to unit length, making it - dimensionless. For ``rotation`` axes, the direction should be - chosen for a right-handed rotation with increasing angle. - For ``translation`` axes the direction should be chosen for - increasing displacement. For general axes, an appropriate direction - should be chosen. - - - - - - - - A fixed offset applied before the transformation (three vector components). - This is not intended to be a substitute for a fixed ``translation`` axis but, for example, - as the mechanical offset from mounting the axis to its dependency. - - - - - - - - Units of the offset. Values should be consistent with NX_LENGTH. - - - - - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. - - - - - An arbitrary identifier of a component of the equipment to which - the transformation belongs, such as 'detector_arm' or 'detector_module'. - NXtransformations with the same equipment_component label form a logical - grouping which can be combined together into a single change-of-basis - operation. - - + + + The transformation_type may be ``translation``, in which case the + values are linear displacements along the axis, ``rotation``, + in which case the values are angular rotations around the axis. + + If this attribute is omitted, this is an axis for which there + is no motion to be specifies, such as the direction of gravity, + or the direction to the source, or a basis vector of a + coordinate frame. In this case the value of the ``AXISNAME`` field + is not used and can be set to the number ``NaN``. + + + + + + + + + + Three values that define the axis for this transformation. + The axis should be normalized to unit length, making it + dimensionless. For ``rotation`` axes, the direction should be + chosen for a right-handed rotation with increasing angle. + For ``translation`` axes the direction should be chosen for + increasing displacement. For general axes, an appropriate direction + should be chosen. + + + + + + + + A fixed offset applied before the transformation (three vector components). + This is not intended to be a substitute for a fixed ``translation`` axis but, for example, + as the mechanical offset from mounting the axis to its dependency. + + + + + + + + Units of the offset. Values should be consistent with NX_LENGTH. + + + + + Points to the path to a field defining the axis on which this + depends or the string ".". + + + + + An arbitrary identifier of a component of the equipment to which + the transformation belongs, such as 'detector_arm' or 'detector_module'. + NXtransformations with the same equipment_component label form a logical + grouping which can be combined together into a single change-of-basis + operation. + + - + - ``AXISNAME_end`` is a placeholder for a name constructed from the actual - name of an axis to which ``_end`` has been appended. - - The values in this field are the end points of the motions that start - at the corresponding positions given in the ``AXISNAME`` field. + ``AXISNAME_end`` is a placeholder for a name constructed from the actual + name of an axis to which ``_end`` has been appended. + + The values in this field are the end points of the motions that start + at the corresponding positions given in the ``AXISNAME`` field. - - - ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual - name of an axis to which ``_increment_set`` has been appended. - - The value of this optional field is the intended average range through which - the corresponding axis moves during the exposure of a frame. Ideally, the - value of this field added to each value of ``AXISNAME`` would agree with the - corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - + + + ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual + name of an axis to which ``_increment_set`` has been appended. + + The value of this optional field is the intended average range through which + the corresponding axis moves during the exposure of a frame. Ideally, the + value of this field added to each value of ``AXISNAME`` would agree with the + corresponding values of ``AXISNAME_end``, but there is a possibility of significant + differences. Use of ``AXISNAME_end`` is recommended. + - - - .. 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. - - - + \ No newline at end of file diff --git a/base_classes/NXtranslation.nxdl.xml b/base_classes/NXtranslation.nxdl.xml index 1ab7ca9c03..e34967989d 100644 --- a/base_classes/NXtranslation.nxdl.xml +++ b/base_classes/NXtranslation.nxdl.xml @@ -3,7 +3,7 @@ - - - Contact information for a user. - - The format allows more - than one user with the same affiliation and contact information, - but a second :ref:`NXuser` group should be used if they have different - affiliations, etc. - - - - Name of user responsible for this entry - - - - - Role of user responsible for this entry. - Suggested roles are "local_contact", - "principal_investigator", and "proposer" - - - - - Affiliation of user - - - - - Address of user - - - - - Telephone number of user - - - - - Fax number of user - - - - - Email of user - - - - - facility based unique identifier for this person - e.g. their identification code on the facility - address/contact database - - - - - Details about an author code, open researcher, or contributor - (persistent) identifier, e.g. defined by https://orcid.org and expressed - as a URI. - - - - - .. 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. - - + + + Contact information for a user. + + The format allows more + than one user with the same affiliation and contact information, + but a second :ref:`NXuser` group should be used if they have different + affiliations, etc. + + + Name of user responsible for this entry + + + + Role of user responsible for this entry. + Suggested roles are "local_contact", + "principal_investigator", and "proposer" + + + + Affiliation of user + + + Address of user + + + Telephone number of user + + + Fax number of user + + + Email of user + + + + facility based unique identifier for this person + e.g. their identification code on the facility + address/contact database + + + + + an author code, Open Researcher and Contributor ID, + defined by https://orcid.org and expressed as a URI + + + diff --git a/base_classes/NXvelocity_selector.nxdl.xml b/base_classes/NXvelocity_selector.nxdl.xml index bf9e3a9c10..49056dee72 100644 --- a/base_classes/NXvelocity_selector.nxdl.xml +++ b/base_classes/NXvelocity_selector.nxdl.xml @@ -3,7 +3,7 @@ +# +# +# An actuator used to control an external condition. +# +# The condition itself is described in :ref:`NXenvironment`. +# +# +# +# Name of the actuator +# +# +# +# +# Short name of actuator used e.g. on monitor display program +# +# +# +# +# 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. +# +# +# +# +# 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 output_power(NX_NUMBER). +# +# +# +# +# +# If the actuator is PID-controlled, the settings of the PID controller can be +# stored here. +# +# +# diff --git a/base_classes/nyaml/NXaperture.yaml b/base_classes/nyaml/NXaperture.yaml index 7b123ba21b..40f41fe7bd 100644 --- a/base_classes/nyaml/NXaperture.yaml +++ b/base_classes/nyaml/NXaperture.yaml @@ -1,19 +1,16 @@ category: base doc: | - A beamline aperture. This group is deprecated, use NXslit instead. + A beamline aperture. + + Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. + + You can specify the geometry of the aperture using either NXoff_geometry or for simpler geometry shape and size. type: group -NXaperture(NXobject): +NXaperture(NXcomponent): # TODO compare with "screens" in SHADOW 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 aperture is its center in the x and y axis. The reference point on the z axis is the surface of the aperture pointing towards the source. @@ -21,12 +18,9 @@ NXaperture(NXobject): .. image:: aperture/aperture.png :width: 40% - (NXtransformations): + (NXoff_geometry): 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. + Use this group to describe the shape of the aperture. (NXpositioner): doc: | Stores the raw positions of aperture motors. @@ -34,7 +28,7 @@ NXaperture(NXobject): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the aperture and :ref:`NXoff_geometry` to describe its shape doc: | - location and shape of aperture + Location and shape of aperture .. TODO: documentation needs improvement, contributions welcome @@ -67,27 +61,16 @@ NXaperture(NXobject): diameter (NXnote): doc: | - describe any additional information in a note* - \@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. + Describe any additional information in a note. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 958de5809c55ea9bb7eda83a612cf4e2770cbce001cc16a5944e072279415895 +# 9fdb8914b833f97b0b1b92fd05d047b11d89c43141dc560f9495936918eaca02 # -# +# # -# +# # -# A beamline aperture. This group is deprecated, use NXslit instead. +# A beamline aperture. +# +# Note, the group was incorrectly documented as deprecated, but it is not and it is in common use. +# +# You can specify the geometry of the aperture using either NXoff_geometry or for simpler geometry shape and size. # # # -# -# 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 aperture is its center in the x and y axis. The reference point on the z axis is the -# surface of the aperture pointing towards the source. -# -# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. -# -# .. image:: aperture/aperture.png -# :width: 40% -# +# +# The reference point of the aperture is its center in the x and y axis. The reference point on the z axis is the +# surface of the aperture pointing towards the source. +# +# In complex (asymmetric) geometries an NXoff_geometry group can be used to provide an unambiguous reference. +# +# .. image:: aperture/aperture.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. -# +# +# +# Use this group to describe the shape of the aperture. +# # # # @@ -143,32 +120,26 @@ NXaperture(NXobject): # # # -# location and shape of aperture -# -# .. TODO: documentation needs improvement, contributions welcome -# -# * description of terms is poor and leaves much to interpretation -# * Describe what is meant by translation _here_ and ... -# * Similar throughout base classes -# * Some base classes do this much better -# * Such as where is the gap written? +# Location and shape of aperture +# +# .. TODO: documentation needs improvement, contributions welcome +# +# * description of terms is poor and leaves much to interpretation +# * Describe what is meant by translation _here_ and ... +# * Similar throughout base classes +# * Some base classes do this much better +# * Such as where is the gap written? +# # # # -# -# location and shape of each blade -# +# location and shape of each blade # -# -# -# -# Absorbing material of the aperture -# +# +# Absorbing material of the aperture # # -# -# Description of aperture -# +# Description of aperture # # # @@ -195,20 +166,7 @@ NXaperture(NXobject): # # # -# describe any additional information in a note* +# Describe any additional information in a note. # # -# -# -# .. 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/NXattenuator.yaml b/base_classes/nyaml/NXattenuator.yaml index cf09fa8397..60ac41eb6b 100644 --- a/base_classes/nyaml/NXattenuator.yaml +++ b/base_classes/nyaml/NXattenuator.yaml @@ -6,7 +6,7 @@ doc: | or :ref:`NXattenuator` (reduces beam intensity), then choose :ref:`NXattenuator`. type: group -NXattenuator(NXobject): +NXattenuator(NXcomponent): # TODO compare with SHADOW definition "screen" # TODO SHADOW: https://github.com/oasys-kit/shadow3 @@ -41,26 +41,8 @@ NXattenuator(NXobject): doc: | time stamp for this observation enumeration: [in, out, moving] - \@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 attenuator is its center in the x and y axis. The reference point on the z axis is the surface of the attenuator pointing towards the source. @@ -68,24 +50,18 @@ NXattenuator(NXobject): .. image:: attenuator/attenuator.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. shape(NXoff_geometry): doc: | Shape of this component. Particulary useful to define the origin for position and orientation in non-standard cases. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ccc379e1d6f240bec5db3a346762284e5a11dc4c8d493d2127d6c6650249f89c +# d53dd3e039d3be8879ca8f2a17ed5def3589475e130e4f11a04493c0853e52c6 # # # +# +# +# +# The symbols used in the schema to specify e.g. dimensions of arrays +# +# +# +# Number of points of the calibrated and uncalibrated axes +# +# +# +# +# Subclass of NXprocess to describe post-processing calibrations. +# +# +# +# A description of the procedures employed. +# +# +# +# +# The physical quantity of the calibration, e.g., +# energy, momentum, time, etc. +# +# +# +# +# A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a +# calibration method but no actual calibration data. +# +# +# +# +# A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement +# used for this instrument, e.g., a measurement of a known standard containing calibration information. +# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. +# +# +# +# +# A file serialisation of a calibration which may not be publicly available (externally from the NeXus file). +# +# This metadata can be a documentation of the source (file) or database (entry) from which pieces +# of information have been extracted for consumption (e.g. in a research data management system (RDMS)). +# It is also possible to include the actual file by using the `file` field. +# +# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. +# +# +# +# +# Indicates the name of the last operation applied in the NXprocess sequence. +# +# +# +# +# Has the calibration been applied? +# +# +# +# +# Array containing the data coordinates in the original uncalibrated axis +# +# +# +# +# +# +# The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. +# This should comply to the following naming rules (similar to python's naming rules): +# +# * A variable name must start with a letter or the underscore character +# * A variable name cannot start with a number +# * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) +# * Variable names are case-sensitive (age, Age and AGE are three different variables) +# +# +# +# +# The path from which this data is derived, e.g., raw detector axis. +# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. +# +# +# +# +# +# Additional input axis to be used in the formula. +# +# +# +# The name of each ``TERM`` is used as the symbol to be used in the ``fit_formula_description``, i.e., +# if the field name is `my_field` you should refer to this axis by `my_field` in the ``fit_formula_description``. +# +# +# +# The path from which this data is derived, e.g., raw detector axis. +# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. +# +# +# +# +# +# +# For non-linear energy calibrations, e.g. in a time-of-flight (TOF) detector, a polynomial function is fitted +# to a set of features (peaks) at well defined energy positions to determine +# E(TOF). Here we can store the fit coefficients. +# +# +# +# Use a0, a1, ..., an for the coefficients, corresponding to the values in the +# ``fit_formula_description``. +# +# +# +# +# +# For non-linear energy calibrations. Here we can store a description of the formula +# used for the fit function. +# +# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients group. +# +# Use x0, x1, ..., xm for the nth position in the `original_axis` field. +# If there is the symbol attribute specified for the `original_axis` this may be used instead of x. +# If you want to use the whole axis use `x`. +# Alternate axis can also be available as specified by the `input_SYMBOL` group. +# The data should then be referred here by the `SYMBOL` name, e.g., for a field +# name `input_my_field` it should be referred here by `my_field` or `my_field0` if +# you want to read the zeroth element of the array. +# +# +# +# +# For linear calibration. Scaling parameter. +# This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. +# +# For a more detailed description of scaling factors, see +# :ref:`/NXdata/FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>`. +# +# +# +# +# For linear calibration. Offset parameter. +# This should yield the relation `calibrated_axis` = (`original_axis` + `offset`) * `scaling_factor`. +# +# For a more detailed description of offset, see +# :ref:`/NXdata/FIELDNAME_offset </NXdata/FIELDNAME_offset-field>`. +# +# +# +# +# Mapping data for calibration. +# +# This can be used to map data points from uncalibrated to calibrated values, +# i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. +# +# +# +# +# An array representing the axis after calibration, matching the data length +# +# +# +# +# +# +# +# Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. +# NXdata groups can be used for multidimensional data which are relevant to the calibration +# +# +# +# +# .. 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/NXcapillary.yaml b/base_classes/nyaml/NXcapillary.yaml index aacb021fd6..4dcdf26acc 100644 --- a/base_classes/nyaml/NXcapillary.yaml +++ b/base_classes/nyaml/NXcapillary.yaml @@ -4,7 +4,7 @@ doc: | Based on information provided by Gerd Wellenreuther (DESY). type: group -NXcapillary(NXobject): +NXcapillary(NXcomponent): type(NX_CHAR): doc: | Type of the capillary @@ -17,10 +17,10 @@ NXcapillary(NXobject): unit: NX_ANGLE accepting_aperture(NX_FLOAT): unit: NX_ANGLE - (NXdata)gain: + gain(NXdata): doc: | The gain of the capillary as a function of energy - (NXdata)transmission: + transmission(NXdata): doc: | The transmission of the capillary as a function of energy working_distance(NX_FLOAT): @@ -28,43 +28,19 @@ NXcapillary(NXobject): focal_size(NX_FLOAT): doc: | The focal size in FWHM - \@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 capillary lens. - (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 ++++++++++++++++++++++++++++++++++ -# 532702bd23065d69a03c9e0b7aaf7136d411799faab901669a8be1f5d007b6c9 +# 9fc502a9bf37a49493cf3a56a2c151c2d8077e2ef4eeb84160373982ee545925 # # # diff --git a/base_classes/nyaml/NXcollimator.yaml b/base_classes/nyaml/NXcollimator.yaml index baab547487..453b17fed3 100644 --- a/base_classes/nyaml/NXcollimator.yaml +++ b/base_classes/nyaml/NXcollimator.yaml @@ -2,7 +2,7 @@ category: base doc: | A beamline collimator. type: group -NXcollimator(NXobject): +NXcollimator(NXcomponent): (NXgeometry): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the collimator and NXoff_geometry to describe its shape instead @@ -26,7 +26,7 @@ NXcollimator(NXobject): unit: NX_FREQUENCY doc: | Frequency of oscillating collimator - (NXlog)frequency_log: + frequency_log(NXlog): doc: | Log of frequency blade_thickness(NX_FLOAT): @@ -47,47 +47,23 @@ NXcollimator(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - \@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. - Assuming a collimator with a "flat" entry surface, the reference plane is the plane which contains this surface. The reference point of the collimator in the x and y axis is the centre of the collimator entry surface on that plane. The reference plane is orthogonal to the z axis and the location of this plane is the reference point on the z axis. The collimator faces negative z values. .. image:: collimator/collimator.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 ++++++++++++++++++++++++++++++++++ -# 00a9964086dc22e6087e2003333b5cff83695a44785b893c6d1604e7052defb2 +# de2a6328d9ad396131e6e302f7e92aa3e0a07afa4f2ce02e68e9b1f76882cb1f # # # +# +# +# Base class for components of an instrument - real ones or simulated ones. +# +# +# +# Was the component used? +# +# +# +# +# Name of the component. +# +# +# +# +# Ideally, use instances of ``identifierNAME`` to point to a resource +# that provides further details. +# +# If such a resource does not exist or should not be used, use this free text, +# although it is not recommended. +# +# +# +# +# Instance or list of instances of ``NXcomponent`` (or base classes +# extending ``NXcomponent``) or ``NXbeam`` that act as input(s) to this +# component. +# +# Each input should point to the path of the group acting as input. +# +# An example usage would be to chain components and/or beams together to describe +# the beam path in an experiment. +# +# +# +# +# Instance or list of instances of ``NXcomponent`` (or base classes +# extending ``NXcomponent``) or ``NXbeam`` that act as output(s) of this +# component. +# +# For more information, see :ref:`inputs </NXcomponent/inputs-field>`. +# +# +# +# +# +# +# Specifies the position of the component by pointing to the last +# transformation in the transformation chain that is defined +# via the NXtransformations group. +# +# 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. +# +# +# +# +# Collection of axis-based translations and rotations to describe the +# location and geometry of the component in the instrument. The dependency +# chain may however traverse similar groups in other component groups. +# +# +# +# diff --git a/base_classes/nyaml/NXcrystal.yaml b/base_classes/nyaml/NXcrystal.yaml index 4708d5a991..04a0c859a6 100644 --- a/base_classes/nyaml/NXcrystal.yaml +++ b/base_classes/nyaml/NXcrystal.yaml @@ -20,7 +20,7 @@ symbols: i: | number of wavelengths type: group -NXcrystal(NXobject): +NXcrystal(NXcomponent): (NXgeometry): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the crystal and NXoff_geometry to describe its shape instead @@ -259,16 +259,16 @@ NXcrystal(NXobject): unit: NX_ANY doc: | how lattice parameter changes with temperature - (NXlog)temperature_log: + temperature_log(NXlog): doc: | log file of crystal temperature - (NXdata)reflectivity: + reflectivity(NXdata): doc: | crystal reflectivity versus wavelength - (NXdata)transmission: + transmission(NXdata): doc: | crystal transmission versus wavelength - (NXshape)shape: + shape(NXshape): deprecated: Use NXoff_geometry instead to describe the shape of the monochromator doc: | A NXshape group describing the shape of the crystal arrangement @@ -276,31 +276,10 @@ NXcrystal(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - \@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 crystal. - (NXtransformations): - doc: | - Transformations used by this component to define its position and orientation. # TODO need more parameters here, such as ... # list from Rainer Gehrke, DESY (some items may already be present) @@ -329,13 +308,13 @@ NXcrystal(NXobject): # 7. Polynomial (degree of polynom, array with polynom coefficients) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 66f32a8306d406c445998423febd92863d4a1a798329b40f8577dce46858829a +# 15b35664fda589474ae03c6fe2418821a001152c7db5cc84b1b624bb6a7432a1 # # # the default dependent data - mr: float[100] --> the default independent data - - The field named in the ``signal`` attribute **must** exist, either - directly as a NeXus field or defined through a link. - - * The group ``axes`` attribute will name the - *dimension scale* associated with the plottable data. - - If available, the standard deviations of the data are to be - stored in a data set of the same rank and dimensions, with the name ``errors``. - - * For each data dimension, there should be a one-dimensional array - of the same length. - * These one-dimensional arrays are the *dimension scales* of the - data, *i.e*. the values of the independent variables at which the data - is measured, such as scattering angle or energy transfer. - - .. index:: link + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + data1: float[10,20,30] --> the default signal + data2: float[10,20,30] + data3: float[10,20,30] + + **Axes:** + .. index:: axes (attribute) + .. index:: coordinates + + The :ref:`AXISNAME ` fields contain the axis coordinates associated with the data values. + The names of all :ref:`AXISNAME ` fields are listed in the + :ref:`axes ` attribute. + + `Rank` + + :ref:`AXISNAME ` fields are typically one-dimensional arrays, which annotate one of the dimensions. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order matters + data: float[10,20] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. + + However, the fields can also have a rank greater than 1, in which case the rank of each + :ref:`AXISNAME ` must be equal to the number of data dimensions it spans. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y"] --> the order does NOT matter + @x_indices = [0, 1] + @y_indices = [0, 1] + data: float[10,20] + x: float[10,20] --> coordinates along both dimensions + y: float[10,20] --> coordinates along both dimensions + + In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. + + `Dimensions` + + The data dimensions annotated by an :ref:`AXISNAME ` field are defined by the + :ref:`AXISNAME_indices ` attribute. When this attribute is missing, + the position(s) of the :ref:`AXISNAME ` string in the + :ref:`axes ` attribute are used. + + When all :ref:`AXISNAME ` fields are one-dimensional, and none of the data dimensions + have more than one axis, the :ref:`AXISNAME_indices ` attributes + are often omitted. If one of the data dimensions has no :ref:`AXISNAME ` field, + the string “.” can be used in the corresponding index of the axes list. + + An example of this would be + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", ".", "z"] --> the order matters + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When using :ref:`AXISNAME_indices ` this becomes + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "z"] --> the order does NOT matter + data: float[10,20,30] + @x_indices = 0 + @z_indices = 2 + x: float[10] --> coordinates along the first dimension + z: float[30] --> coordinates along the third dimension + + When providing :ref:`AXISNAME_indices ` attributes it is recommended + to do it for all axes. + + `Non-trivial axes` + + What follows are two examples where :ref:`AXISNAME_indices ` attributes + cannot be omitted. + + The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents + a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` + for the last dimension (or vice versa). + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter + @x_indices = 0 + @y_indices = 1 + @energy_indices = 2 + @wavelength_indices = 2 + data: float[10,20,30] + x: float[10] --> coordinates along the first dimension + y: float[20] --> coordinates along the second dimension + energy: float[30] --> coordinates along the third dimension + wavelength: float[30] --> coordinates along the third dimension + + The second is an example with coordinates that span more than one dimension. The NXdata group represents data + from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates + ``[x[i,j,k], y[i,j,k], energy[k]]``. + + .. code-block:: + + data:NXdata + @signal = "data" + @axes = ["x", "y", "energy"] --> the order does NOT matter + @x_indices = [0, 1, 2] + @y_indices = [0, 1, 2] + @energy_indices = 2 + data: float[10,20,30] + x: float[10,20,30] --> coordinates along all dimensions + y: float[10,20,30] --> coordinates along all dimensions + energy: float[30] --> coordinates along the third dimension + + **Uncertainties:** + + Standard deviations on data values as well as coordinates can be provided by + :ref:`FIELDNAME_errors ` fields where ``FIELDNAME`` is the name of a + :ref:`DATA ` field or an :ref:`AXISNAME ` field. + + An example of uncertainties on the signal, auxiliary signals and axis coordinates + + .. code-block:: - The preferred method to associate each data dimension with - its respective dimension scale is to specify the field name - of each dimension scale in the group ``axes`` attribute as a string list. - Here is an example for a 2-D data set *data* plotted - against *time*, and *pressure*. (An additional *temperature* data set - is provided and could be selected as an alternate for the *pressure* axis.):: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @pressure_indices=1 - @temperature_indices=1 - @time_indices=0 - data: float[1000,20] - pressure: float[20] - temperature: float[20] - time: float[1000] - - .. rubric:: Old methods to identify the plottable data - - There are two older methods of associating - each data dimension to its respective dimension scale. - Both are now out of date and - should not be used when writing new data files. - However, client software should expect to see data files - written with any of these methods. - - * One method uses the ``axes`` - attribute to specify the names of each *dimension scale*. - - * The oldest method uses the ``axis`` attribute on each - *dimension scale* to identify - with an integer the axis whose value is the number of the dimension. - - .. index: !plot; axis label - plot, axis units - units - dimension scale - - Each axis of the plot may be labeled with information from the - dimension scale for that axis. The optional ``@long_name`` attribute - is provided as the axis label default. If ``@long_name`` is not - defined, then use the name of the dimension scale. A ``@units`` attribute, - if available, may be added to the axis label for further description. - See the section :ref:`Design-Units` for more information. - - .. index: !plot; axis title - - The optional ``title`` field, if available, provides a suggested - title for the plot. If no ``title`` field is found in the :ref:`NXdata` - group, look for a ``title`` field in the parent :ref:`NXentry` group, - with a fallback to displaying the path to the :ref:`NXdata` group. - - NeXus is about how to find and annotate the data to be plotted - but not to describe how the data is to be plotted. - (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) + data:NXdata + @signal = "data1" + @auxiliary_signals = ["data2", "data3"] + @axes = ["x", "z"] + @x_indices = 0 + @z_indices = 2 + data1: float[10,20,30] + data2: float[10,20,30] + data3: float[10,20,30] + x: float[10] + z: float[30] + data1_errors: float[10,20,30] + data2_errors: float[10,20,30] + data3_errors: float[10,20,30] + x_errors: float[10] + z_errors: float[30] # The ignoreExtra* attributes are used in the definition to # avoid warning messages that would be generated from unexpected fields or attributes. @@ -117,12 +189,9 @@ doc: | # without this attribute being set to "true". symbols: doc: | - These symbols will be used below to coordinate fields with the same - shape. + These symbols will be used below to coordinate fields with the same shape. dataRank: | - rank of the ``DATA`` field - n: | - length of the ``AXISNAME`` field + rank of the ``DATA`` field(s) nx: | length of the ``x`` field ny: | @@ -133,70 +202,80 @@ type: group ignoreExtraFields: true ignoreExtraAttributes: true NXdata(NXobject): - \@auxiliary_signals: - doc: | - .. index:: plotting - - Array of strings holding the :ref:`names ` of additional - signals to be plotted with the default :ref:`signal `. - These fields or links *must* exist and be direct children of this NXdata group. - - Each auxiliary signal needs to be of the same shape as the default signal. - - .. NIAC2018: - https://www.nexusformat.org/NIAC2018Minutes.html + + # Attributes for data and coordinate field detection \@signal: doc: | .. index:: find the default plottable data .. index:: plotting .. index:: signal attribute value - Declares which NeXus field is the default. - The value is the :ref:`name ` of the data field to be plotted. - This field or link *must* exist and be a direct child of this NXdata group. + The value is the :ref:`name ` of the signal that contains + the default plottable data. This field or link *must* exist and be a direct child + of this NXdata group. It is recommended (as of NIAC2014) to use this attribute rather than adding a signal attribute to the field. See https://www.nexusformat.org/2014_How_to_find_default_data.html for a summary of the discussion. - \@axes: + \@auxiliary_signals: doc: | .. index:: plotting - Array of strings holding the :ref:`names ` of - the independent data fields used in the default plot for all of - the dimensions of the :ref:`signal ` - as well as any :ref:`auxiliary signals `. + Array of strings holding the :ref:`names ` of additional + signals to be plotted with the :ref:`default signal `. + These fields or links *must* exist and be direct children of this NXdata group. + + Each auxiliary signal needs to be of the same shape as the default signal. - One name is provided for every dimension in the *signal* or *auxiliary signal* fields. + .. NIAC2018: + https://www.nexusformat.org/NIAC2018Minutes.html + \@default_slice(NX_CHAR_OR_NUMBER): + doc: | + Which slice of data to show in a plot by default. This is useful especially for + datasets with more than 2 dimensions. - The *axes* values are the names of fields or links that *must* exist and be direct - children of this NXdata group. + Should be an array of length equal to the number of dimensions + in the data, with the following possible values: - An axis slice is specified using a field named ``AXISNAME_indices`` - as described below (where the text shown here as ``AXISNAME`` is to be - replaced by the actual field name). + * ".": All the data in this dimension should be included + * Integer: Only this slice should be used. + * String: Only this slice should be used. Use if ``AXISNAME`` is a string + array. - When no default axis is available for a particular dimension - of the plottable data, use a "." in that position. - Such as:: + Example:: - @axes=["time", ".", "."] + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "difference", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] - Since there are three items in the list, the *signal* field - must be a three-dimensional array (rank=3). The first dimension - is described by the values of a one-dimensional array named ``time`` - while the other two dimensions have no fields to be used as dimension scales. + Here, a data array with four dimensions, including the number of images + (nP) and number of channels (nC), specifies more dimensions than can be + visualized with a 2D image viewer for a given image. Therefore the + default_slice attribute specifies that the "difference" channel should be + shown by default. - See examples provided on the NeXus wiki: - https://www.nexusformat.org/2014_axes_and_uncertainties.html + Alternate version using an integer would look like this (note 2 is a string):: - If there are no axes at all (such as with a stack of images), - the axes attribute can be omitted. + data:NXdata + @signal = "data" + @axes = ["image_id", "channel", ".", "."] + @image_id_indices = 0 + @channel_indices = 1 + @default_slice = [".", "2", ".", "."] + image_id = [1, ..., nP] + channel = ["threshold_1", "threshold_2", "difference"] + data = uint[nP, nC, i, j] \@reference: doc: | Points to the path of a field defining the data to which the `DATA` group refers. - + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby defining the physical quantity it represents. @@ -204,67 +283,48 @@ NXdata(NXobject): If the data corresponds to a readout of a detector, ``@reference`` links to that detectors data: - @reference: '/entry/instrument/detector/data' for a 2D detector + @reference: '/entry/instrument/detector/data' for a 2D detector \@AXISNAME_indices(NX_INT): - - # nxdl.xsd rules do not allow us to show this as a variable name - # - we'll use ALL CAPS (see #562) - - # AXISNAME_indices documentation copied from datarules.rst + nameType: partial + doc: | + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data ` + dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). + + When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME ` field, its value becomes the index + (or indices) of the :ref:`AXISNAME ` name in the :ref:`axes ` attribute. + + .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array + of integers and not a comma separated string. + \@axes: doc: | - Each ``AXISNAME_indices`` attribute indicates the dependency - relationship of the ``AXISNAME`` field (where ``AXISNAME`` - is the name of a field that exists in this ``NXdata`` group) - with one or more dimensions of the plottable data. - - Integer array that defines the indices of the *signal* field - (that field will be a multidimensional array) - which need to be used in the *AXISNAME* field in - order to reference the corresponding axis value. - - The first index of an array is ``0`` (zero). - - Here, *AXISNAME* is to be replaced by the name of each - field described in the ``axes`` attribute. - An example with 2-D data, :math:`d(t,P)`, will illustrate:: - - data_2d:NXdata - @signal="data" - @axes=["time", "pressure"] - @time_indices=0 - @pressure_indices=1 - data: float[1000,20] - time: float[1000] - pressure: float[20] - - This attribute is to be provided in all situations. - However, if the indices attributes are missing - (such as for data files written before this specification), - file readers are encouraged to make their best efforts - to plot the data. - Thus the implementation of the - ``AXISNAME_indices`` attribute is based on the model of - "strict writer, liberal reader". - - .. note:: Attributes potentially containing multiple values - (axes and _indices) are to be written as string or integer arrays, - to avoid string parsing in reading applications. - AXISNAME(NX_NUMBER): + .. index:: plotting + + The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME ` fields + that contain the values of the coordinates along the :ref:`data ` dimensions. + + .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array + of strings and not a single comma separated string. + + # Data and coordinate fields + AXISNAME(NX_CHAR_OR_NUMBER): nameType: any doc: | - Dimension scale defining an axis of the data. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. - dimensions: - rank: 1 - doc: | - A *dimension scale* must have a rank of 1 and has length ``n``. - dim: (n,) + Coordinate values along one or more :ref:`data ` dimensions. The rank must be equal + to the number of dimensions it spans. + + As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely `. + The :ref:`axes ` attribute can be used to find all datasets in the + ``NXdata`` that contain coordinate values. + + Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, + an array of NX_CHAR can be provided. \@long_name: doc: | Axis label + \@units: + doc: | + Unit in which the coordinate values are expressed. + See the section :ref:`Design-Units` for more information. \@distribution(NX_BOOLEAN): doc: | ``0|false``: single value, @@ -281,8 +341,8 @@ NXdata(NXobject): Index (positive integer) identifying this specific set of numbers. N.B. The ``axis`` attribute is the old way of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. - The ``axes`` *group* attribute is now preferred. + Do not use the :ref:`axes ` attribute with the ``axis`` attribute. + The :ref:`axes ` attribute is now preferred. \@reference: doc: | Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. @@ -294,43 +354,33 @@ NXdata(NXobject): If a calibration has been performed, ``@reference`` links to the result of that calibration: - @reference: '/entry/process/calibration/calibrated_axis' + @reference: '/entry/process/calibration/calibrated_axis' If the axis corresponds to a coordinate of a detector, ``@reference`` links to that detector axis: - @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector + @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector If the axis is a scanned motor, ``@reference`` links to the transformation describing the respective motion, e.g.: - @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector - FIELDNAME_errors(NX_NUMBER): - nameType: any - doc: | - "Errors" (meaning *uncertainties* or *standard deviations*) - associated with any field named ``FIELDNAME`` in this ``NXdata`` - group (e.g. an axis, signal or auxiliary signal). - - The dimensions of the ``FIELDNAME_errors`` field must match - the dimensions of the ``FIELDNAME`` field. + @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector DATA(NX_NUMBER): nameType: any doc: | .. index:: plotting - This field contains the data values to be used as the - NeXus *plottable data*. - Client is responsible for defining the dimensions of the data. - The name of this field may be changed to fit the circumstances. - Standard NeXus client tools will use the attributes to determine - how to use this field. + Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` + indicates, the names of the ``DATA`` fields can be chosen :ref:`freely `. The :ref:`signal attribute ` + and :ref:`auxiliary_signals attribute` can be used to find all datasets in the ``NXdata`` + that contain data values. + + The maximum rank is ``32`` for compatibility with backend file formats. dimensions: rank: dataRank doc: | The rank (``dataRank``) of the ``data`` must satisfy ``1 <= dataRank <= NX_MAXRANK=32``. - At least one ``dim`` must have length ``n``. \@signal(NX_POSINT): deprecated: Use the group ``signal`` attribute (NIAC2014) doc: | @@ -343,12 +393,12 @@ NXdata(NXobject): \@axes: deprecated: Use the group ``axes`` attribute (NIAC2014) doc: | - Defines the names of the dimension scales + Defines the names of the coordinates (independent axes) for this data set as a colon-delimited array. - NOTE: The ``axes`` attribute is the preferred + NOTE: The :ref:`axes ` attribute is the preferred method of designating a link. - Do not use the ``axes`` attribute with the ``axis`` attribute. + Do not use the :ref:`axes ` attribute with the ``axis`` attribute. \@long_name: doc: | data label @@ -366,7 +416,16 @@ NXdata(NXobject): If the data corresponds to a readout of a detector, ``@reference`` links to that detectors data: - @reference: '/entry/instrument/detector/data' for a 2D detector + @reference: '/entry/instrument/detector/data' for a 2D detector + FIELDNAME_errors(NX_NUMBER): + nameType: partial + doc: | + "Errors" (meaning *uncertainties* or *standard deviations*) + associated with any field named ``FIELDNAME`` in this ``NXdata`` + group (e.g. an axis, signal or auxiliary signal). + + The dimensions of the ``FIELDNAME_errors`` field must match + the dimensions of the ``FIELDNAME`` field. errors(NX_NUMBER): deprecated: Use ``DATA_errors`` instead (NIAC2018) doc: | @@ -377,28 +436,68 @@ NXdata(NXobject): dimensions: rank: dataRank doc: | - The ``errors`` must have - the same rank (``dataRank``) + The ``errors`` must have the same rank (``dataRank``) as the ``data``. - At least one ``dim`` must have length "n". + + # Data vs. plot coordinates + FIELDNAME_scaling_factor(NX_NUMBER): + nameType: partial + doc: | + An optional scaling factor to apply to the values in any field named ``FIELDNAME`` + in this ``NXdata`` group. This can be a :ref:`DATA ` field + (signal or auxiliary signal) or a :ref:`AXISNAME ` + field (axis). + + The elements stored in NXdata datasets are often stored as integers for efficiency + reasons and need further correction or conversion, generating floats. For example, + raw values could be stored from a device that need to be converted to values that + represent the physical values. The two fields FIELDNAME_scaling_factor and + FIELDNAME_offset allow linear corrections using the following convention: + + .. code-block:: + + corrected values = (FIELDNAME + offset) * scaling_factor + + This formula will derive the values to use in downstream applications, when necessary. + + When omitted, the scaling factor is assumed to be 1. + FIELDNAME_offset(NX_NUMBER): + nameType: partial + doc: | + An optional offset to apply to the values in FIELDNAME (usually the signal). + + When omitted, the offset is assumed to be 0. + + See :ref:`FIELDNAME_scaling_factor ` for more information. scaling_factor(NX_FLOAT): + deprecated: Use FIELDNAME_scaling_factor instead doc: | - The elements in data are usually float values really. For - efficiency reasons these are usually stored as integers - after scaling with a scale factor. This value is the scale - factor. It is required to get the actual physical value, - when necessary. + The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. + However, scaling_factor is ambiguous in the case of multiple signals. Therefore + scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when + only a single signal is present. offset(NX_FLOAT): + deprecated: Use FIELDNAME_offset instead doc: | - An optional offset to apply to the values in data. + The offset and FIELDNAME_offset fields have similar semantics. + However, offset is ambiguous in the case of multiple signals. Therefore + offset is deprecated. Use FIELDNAME_offset instead, even when + only a single signal is present. + + # Other fields title: doc: | Title for the plot. + + # Deprecated fields x(NX_FLOAT): unit: NX_ANY doc: | This is an array holding the values to use for the x-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: (nx,) @@ -406,7 +505,10 @@ NXdata(NXobject): unit: NX_ANY doc: | This is an array holding the values to use for the y-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: (ny,) @@ -414,20 +516,23 @@ NXdata(NXobject): unit: NX_ANY doc: | This is an array holding the values to use for the z-axis of - data. The units must be appropriate for the measurement. + data. The units must be appropriate for the measurement. + + This is a special case of a :ref:`AXISNAME field ` + kept for backward compatiblity. dimensions: rank: 1 dim: (nz,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e4fd69cdcfd50c1d339187f758bdf058385ef46b753619f1e78bd830dba29835 +# ba7388ef25ef2d8f5883723999d5ca8e0bc82a359244e6c6675e5f350319efea # # # -# -# -# -# -# These symbols will be used below to coordinate fields with the same -# shape. -# -# -# -# rank of the ``DATA`` field -# -# -# -# -# length of the ``AXISNAME`` field -# -# -# -# -# length of the ``x`` field -# -# -# -# -# length of the ``y`` field -# -# -# -# -# length of the ``z`` field -# -# -# -# -# :ref:`NXdata` describes the plottable data and related dimension scales. -# -# .. index:: plotting -# -# It is strongly recommended that there is at least one :ref:`NXdata` -# group in each :ref:`NXentry` group. -# Note that the fields named ``AXISNAME`` and ``DATA`` -# can be defined with different names. -# (Upper case is used to indicate that the actual name is left to the user.) -# The ``signal`` and ``axes`` attributes of the -# ``data`` group define which items -# are plottable data and which are *dimension scales*, respectively. -# -# :ref:`NXdata` is used to implement one of the basic motivations in NeXus, -# to provide a default plot for the data of this :ref:`NXentry`. The actual data -# might be stored in another group and (hard) linked to the :ref:`NXdata` group. -# -# * Each :ref:`NXdata` group will define one field as the default -# plottable data. The value of the ``signal`` attribute names this field. -# Additional fields may be used to describe the dimension scales and -# uncertainities. -# The ``auxiliary_signals`` attribute is a list of the other fields -# to be plotted with the ``signal`` data. -# * The plottable data may be of arbitrary rank up to a maximum -# of ``NX_MAXRANK=32`` (for compatibility with backend file formats). -# * The plottable data will be named as the value of -# the group ``signal`` attribute, such as:: -# -# data:NXdata -# @signal = "counts" -# @axes = "mr" -# @mr_indices = 0 -# counts: float[100] --> the default dependent data -# mr: float[100] --> the default independent data -# -# The field named in the ``signal`` attribute **must** exist, either -# directly as a NeXus field or defined through a link. -# -# * The group ``axes`` attribute will name the -# *dimension scale* associated with the plottable data. -# -# If available, the standard deviations of the data are to be -# stored in a data set of the same rank and dimensions, with the name ``errors``. -# -# * For each data dimension, there should be a one-dimensional array -# of the same length. -# * These one-dimensional arrays are the *dimension scales* of the -# data, *i.e*. the values of the independent variables at which the data -# is measured, such as scattering angle or energy transfer. -# -# .. index:: link -# .. index:: axes (attribute) -# -# The preferred method to associate each data dimension with -# its respective dimension scale is to specify the field name -# of each dimension scale in the group ``axes`` attribute as a string list. -# Here is an example for a 2-D data set *data* plotted -# against *time*, and *pressure*. (An additional *temperature* data set -# is provided and could be selected as an alternate for the *pressure* axis.):: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @pressure_indices=1 -# @temperature_indices=1 -# @time_indices=0 -# data: float[1000,20] -# pressure: float[20] -# temperature: float[20] -# time: float[1000] -# -# .. rubric:: Old methods to identify the plottable data -# -# There are two older methods of associating -# each data dimension to its respective dimension scale. -# Both are now out of date and -# should not be used when writing new data files. -# However, client software should expect to see data files -# written with any of these methods. -# -# * One method uses the ``axes`` -# attribute to specify the names of each *dimension scale*. -# -# * The oldest method uses the ``axis`` attribute on each -# *dimension scale* to identify -# with an integer the axis whose value is the number of the dimension. -# -# .. index: !plot; axis label -# plot, axis units -# units -# dimension scale -# -# Each axis of the plot may be labeled with information from the -# dimension scale for that axis. The optional ``@long_name`` attribute -# is provided as the axis label default. If ``@long_name`` is not -# defined, then use the name of the dimension scale. A ``@units`` attribute, -# if available, may be added to the axis label for further description. -# See the section :ref:`Design-Units` for more information. -# -# .. index: !plot; axis title -# -# The optional ``title`` field, if available, provides a suggested -# title for the plot. If no ``title`` field is found in the :ref:`NXdata` -# group, look for a ``title`` field in the parent :ref:`NXentry` group, -# with a fallback to displaying the path to the :ref:`NXdata` group. -# -# NeXus is about how to find and annotate the data to be plotted -# but not to describe how the data is to be plotted. -# (https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute) -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of additional -# signals to be plotted with the default :ref:`signal </NXdata@signal-attribute>`. -# These fields or links *must* exist and be direct children of this NXdata group. -# -# Each auxiliary signal needs to be of the same shape as the default signal. -# -# .. NIAC2018: -# https://www.nexusformat.org/NIAC2018Minutes.html -# -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: signal attribute value -# -# Declares which NeXus field is the default. -# The value is the :ref:`name <validItemName>` of the data field to be plotted. -# This field or link *must* exist and be a direct child of this NXdata group. -# -# It is recommended (as of NIAC2014) to use this attribute -# rather than adding a signal attribute to the field. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# .. index:: plotting -# -# Array of strings holding the :ref:`names <validItemName>` of -# the independent data fields used in the default plot for all of -# the dimensions of the :ref:`signal </NXdata@signal-attribute>` -# as well as any :ref:`auxiliary signals </NXdata@auxiliary_signals-attribute>`. -# -# One name is provided for every dimension in the *signal* or *auxiliary signal* fields. -# -# The *axes* values are the names of fields or links that *must* exist and be direct -# children of this NXdata group. -# -# An axis slice is specified using a field named ``AXISNAME_indices`` -# as described below (where the text shown here as ``AXISNAME`` is to be -# replaced by the actual field name). -# -# When no default axis is available for a particular dimension -# of the plottable data, use a "." in that position. -# Such as:: -# -# @axes=["time", ".", "."] -# -# Since there are three items in the list, the *signal* field -# must be a three-dimensional array (rank=3). The first dimension -# is described by the values of a one-dimensional array named ``time`` -# while the other two dimensions have no fields to be used as dimension scales. -# -# See examples provided on the NeXus wiki: -# https://www.nexusformat.org/2014_axes_and_uncertainties.html -# -# If there are no axes at all (such as with a stack of images), -# the axes attribute can be omitted. -# -# -# -# -# Points to the path of a field defining the data to which the `DATA` group refers. -# -# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Example: -# If the data corresponds to a readout of a detector, ``@reference`` links -# to that detectors data: -# -# @reference: '/entry/instrument/detector/data' for a 2D detector -# -# -# -# -# -# -# Each ``AXISNAME_indices`` attribute indicates the dependency -# relationship of the ``AXISNAME`` field (where ``AXISNAME`` -# is the name of a field that exists in this ``NXdata`` group) -# with one or more dimensions of the plottable data. -# -# Integer array that defines the indices of the *signal* field -# (that field will be a multidimensional array) -# which need to be used in the *AXISNAME* field in -# order to reference the corresponding axis value. -# -# The first index of an array is ``0`` (zero). -# -# Here, *AXISNAME* is to be replaced by the name of each -# field described in the ``axes`` attribute. -# An example with 2-D data, :math:`d(t,P)`, will illustrate:: -# -# data_2d:NXdata -# @signal="data" -# @axes=["time", "pressure"] -# @time_indices=0 -# @pressure_indices=1 -# data: float[1000,20] -# time: float[1000] -# pressure: float[20] -# -# This attribute is to be provided in all situations. -# However, if the indices attributes are missing -# (such as for data files written before this specification), -# file readers are encouraged to make their best efforts -# to plot the data. -# Thus the implementation of the -# ``AXISNAME_indices`` attribute is based on the model of -# "strict writer, liberal reader". -# -# .. note:: Attributes potentially containing multiple values -# (axes and _indices) are to be written as string or integer arrays, -# to avoid string parsing in reading applications. -# -# -# -# -# Dimension scale defining an axis of the data. -# Client is responsible for defining the dimensions of the data. -# The name of this field may be changed to fit the circumstances. -# Standard NeXus client tools will use the attributes to determine -# how to use this field. -# -# -# -# A *dimension scale* must have a rank of 1 and has length ``n``. -# -# -# -# -# -# Axis label -# -# -# -# -# ``0|false``: single value, -# ``1|true``: multiple values -# -# -# -# -# Index of first good value -# -# -# -# -# Index of last good value -# -# -# -# -# Index (positive integer) identifying this specific set of numbers. -# -# N.B. The ``axis`` attribute is the old way of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# The ``axes`` *group* attribute is now preferred. -# -# -# -# -# Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. -# -# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Examples: -# If a calibration has been performed, ``@reference`` links to the result of -# that calibration: -# -# @reference: '/entry/process/calibration/calibrated_axis' -# -# If the axis corresponds to a coordinate of a detector, ``@reference`` links -# to that detector axis: -# -# @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector -# -# If the axis is a scanned motor, ``@reference`` links to the transformation -# describing the respective motion, e.g.: -# -# @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector -# -# -# -# -# -# "Errors" (meaning *uncertainties* or *standard deviations*) -# associated with any field named ``FIELDNAME`` in this ``NXdata`` -# group (e.g. an axis, signal or auxiliary signal). -# -# The dimensions of the ``FIELDNAME_errors`` field must match -# the dimensions of the ``FIELDNAME`` field. -# -# -# -# -# .. index:: plotting -# -# This field contains the data values to be used as the -# NeXus *plottable data*. -# Client is responsible for defining the dimensions of the data. -# The name of this field may be changed to fit the circumstances. -# Standard NeXus client tools will use the attributes to determine -# how to use this field. -# -# -# -# The rank (``dataRank``) of the ``data`` must satisfy -# ``1 <= dataRank <= NX_MAXRANK=32``. -# At least one ``dim`` must have length ``n``. -# -# -# -# -# .. index:: plotting -# -# Plottable (independent) axis, indicate index number. -# Only one field in a :ref:`NXdata` group may have the -# ``signal=1`` attribute. -# Do not use the ``signal`` attribute with the ``axis`` attribute. -# -# -# -# -# Defines the names of the dimension scales -# (independent axes) for this data set -# as a colon-delimited array. -# NOTE: The ``axes`` attribute is the preferred -# method of designating a link. -# Do not use the ``axes`` attribute with the ``axis`` attribute. -# -# -# -# -# data label -# -# -# -# -# Points to the path of a field defining the data to which the `DATA` field refers. -# -# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby -# defining the physical quantity it represents. -# -# Here, *DATA* is to be replaced by the name of each -# data field. -# -# Example: -# If the data corresponds to a readout of a detector, ``@reference`` links -# to that detectors data: -# -# @reference: '/entry/instrument/detector/data' for a 2D detector -# -# -# -# -# -# Standard deviations of data values - -# the data array is identified by the group attribute ``signal``. -# The ``errors`` array must have the same dimensions as ``DATA``. -# Client is responsible for defining the dimensions of the data. -# -# -# -# The ``errors`` must have -# the same rank (``dataRank``) -# as the ``data``. -# At least one ``dim`` must have length "n". -# -# -# -# -# -# The elements in data are usually float values really. For -# efficiency reasons these are usually stored as integers -# after scaling with a scale factor. This value is the scale -# factor. It is required to get the actual physical value, -# when necessary. -# -# -# -# -# An optional offset to apply to the values in data. -# -# -# -# -# Title for the plot. -# -# -# -# -# This is an array holding the values to use for the x-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the y-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# -# -# -# This is an array holding the values to use for the z-axis of -# data. The units must be appropriate for the measurement. -# -# -# -# -# +# +# +# +# +# +# These symbols will be used below to coordinate fields with the same shape. +# rank of the ``DATA`` field(s) +# length of the ``x`` field +# length of the ``y`` field +# length of the ``z`` field +# +# +# +# The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. +# NXdata groups contain plottable data (sometimes referred to as *signals* or *dependent variables*) and their +# associated axis coordinates (sometimes referred to as *axes* or *independent variables*). +# +# The actual names of the :ref:`DATA </NXdata/DATA-field>` and :ref:`AXISNAME </NXdata/AXISNAME-field>` fields +# can be chosen :ref:`freely <validItemName>`, as indicated by the upper case (this is a common convention in all NeXus classes). +# +# .. note:: ``NXdata`` provides data and coordinates to be plotted but +# does not describe how the data is to be plotted or even the dimensionality of the plot. +# https://www.nexusformat.org/NIAC2018Minutes.html#nxdata-plottype--attribute +# +# **Signals:** +# +# .. index:: plotting +# +# The :ref:`DATA </NXdata/DATA-field>` fields contain the signal values to be plotted. The name of the field +# to be used as the *default plot signal* is provided by the :ref:`signal </NXdata@signal-attribute>` attribute. +# The names of the fields to be used as *secondary plot signals* are provided by the +# :ref:`auxiliary_signals</NXdata@auxiliary_signals-attribute>` attribute. +# +# An example with three signals, one of which being the default +# +# .. code-block:: +# +# data:NXdata +# @signal = "data1" +# @auxiliary_signals = ["data2", "data3"] +# data1: float[10,20,30] --> the default signal +# data2: float[10,20,30] +# data3: float[10,20,30] +# +# **Axes:** +# +# .. index:: axes (attribute) +# .. index:: coordinates +# +# The :ref:`AXISNAME </NXdata/AXISNAME-field>` fields contain the axis coordinates associated with the data values. +# The names of all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are listed in the +# :ref:`axes </NXdata@axes-attribute>` attribute. +# +# `Rank` +# +# :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are typically one-dimensional arrays, which annotate one of the dimensions. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y"] --> the order matters +# data: float[10,20] +# x: float[10] --> coordinates along the first dimension +# y: float[20] --> coordinates along the second dimension +# +# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i], y[j]]``. +# +# However, the fields can also have a rank greater than 1, in which case the rank of each +# :ref:`AXISNAME </NXdata/AXISNAME-field>` must be equal to the number of data dimensions it spans. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y"] --> the order does NOT matter +# @x_indices = [0, 1] +# @y_indices = [0, 1] +# data: float[10,20] +# x: float[10,20] --> coordinates along both dimensions +# y: float[10,20] --> coordinates along both dimensions +# +# In this example each data point ``data[i,j]`` has axis coordinates ``[x[i,j], y[i,j]]``. +# +# `Dimensions` +# +# The data dimensions annotated by an :ref:`AXISNAME </NXdata/AXISNAME-field>` field are defined by the +# :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attribute. When this attribute is missing, +# the position(s) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` string in the +# :ref:`axes </NXdata@axes-attribute>` attribute are used. +# +# When all :ref:`AXISNAME </NXdata/AXISNAME-field>` fields are one-dimensional, and none of the data dimensions +# have more than one axis, the :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes +# are often omitted. If one of the data dimensions has no :ref:`AXISNAME </NXdata/AXISNAME-field>` field, +# the string “.” can be used in the corresponding index of the axes list. +# +# An example of this would be +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", ".", "z"] --> the order matters +# data: float[10,20,30] +# x: float[10] --> coordinates along the first dimension +# z: float[30] --> coordinates along the third dimension +# +# When using :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` this becomes +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "z"] --> the order does NOT matter +# data: float[10,20,30] +# @x_indices = 0 +# @z_indices = 2 +# x: float[10] --> coordinates along the first dimension +# z: float[30] --> coordinates along the third dimension +# +# When providing :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes it is recommended +# to do it for all axes. +# +# `Non-trivial axes` +# +# What follows are two examples where :ref:`AXISNAME_indices </NXdata@AXISNAME_indices-attribute>` attributes +# cannot be omitted. +# +# The first is an example where data dimensions have alternative axis coordinates. The NXdata group represents +# a stack of images collected at different energies. The ``wavelength`` is an alternative axis of ``energy`` +# for the last dimension (or vice versa). +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y", "energy", "wavelength"] --> the order does NOT matter +# @x_indices = 0 +# @y_indices = 1 +# @energy_indices = 2 +# @wavelength_indices = 2 +# data: float[10,20,30] +# x: float[10] --> coordinates along the first dimension +# y: float[20] --> coordinates along the second dimension +# energy: float[30] --> coordinates along the third dimension +# wavelength: float[30] --> coordinates along the third dimension +# +# The second is an example with coordinates that span more than one dimension. The NXdata group represents data +# from 2D mesh scans performed at multiple energies. Each data point ``data[i,j,k]`` has axis coordinates +# ``[x[i,j,k], y[i,j,k], energy[k]]``. +# +# .. code-block:: +# +# data:NXdata +# @signal = "data" +# @axes = ["x", "y", "energy"] --> the order does NOT matter +# @x_indices = [0, 1, 2] +# @y_indices = [0, 1, 2] +# @energy_indices = 2 +# data: float[10,20,30] +# x: float[10,20,30] --> coordinates along all dimensions +# y: float[10,20,30] --> coordinates along all dimensions +# energy: float[30] --> coordinates along the third dimension +# +# **Uncertainties:** +# +# Standard deviations on data values as well as coordinates can be provided by +# :ref:`FIELDNAME_errors </NXdata/FIELDNAME_errors-field>` fields where ``FIELDNAME`` is the name of a +# :ref:`DATA </NXdata/DATA-field>` field or an :ref:`AXISNAME </NXdata/AXISNAME-field>` field. +# +# An example of uncertainties on the signal, auxiliary signals and axis coordinates +# +# .. code-block:: +# +# data:NXdata +# @signal = "data1" +# @auxiliary_signals = ["data2", "data3"] +# @axes = ["x", "z"] +# @x_indices = 0 +# @z_indices = 2 +# data1: float[10,20,30] +# data2: float[10,20,30] +# data3: float[10,20,30] +# x: float[10] +# z: float[30] +# data1_errors: float[10,20,30] +# data2_errors: float[10,20,30] +# data3_errors: float[10,20,30] +# x_errors: float[10] +# z_errors: float[30] +# +# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: signal attribute value +# +# The value is the :ref:`name <validItemName>` of the signal that contains +# the default plottable data. This field or link *must* exist and be a direct child +# of this NXdata group. +# +# It is recommended (as of NIAC2014) to use this attribute +# rather than adding a signal attribute to the field. +# See https://www.nexusformat.org/2014_How_to_find_default_data.html +# for a summary of the discussion. +# +# +# +# +# .. index:: plotting +# +# Array of strings holding the :ref:`names <validItemName>` of additional +# signals to be plotted with the :ref:`default signal </NXdata@signal-attribute>`. +# These fields or links *must* exist and be direct children of this NXdata group. +# +# Each auxiliary signal needs to be of the same shape as the default signal. +# +# .. NIAC2018: +# https://www.nexusformat.org/NIAC2018Minutes.html +# +# +# +# +# Which slice of data to show in a plot by default. This is useful especially for +# datasets with more than 2 dimensions. +# +# Should be an array of length equal to the number of dimensions +# in the data, with the following possible values: +# +# * ".": All the data in this dimension should be included +# * Integer: Only this slice should be used. +# * String: Only this slice should be used. Use if ``AXISNAME`` is a string +# array. +# +# Example:: +# +# data:NXdata +# @signal = "data" +# @axes = ["image_id", "channel", ".", "."] +# @image_id_indices = 0 +# @channel_indices = 1 +# @default_slice = [".", "difference", ".", "."] +# image_id = [1, ..., nP] +# channel = ["threshold_1", "threshold_2", "difference"] +# data = uint[nP, nC, i, j] +# +# Here, a data array with four dimensions, including the number of images +# (nP) and number of channels (nC), specifies more dimensions than can be +# visualized with a 2D image viewer for a given image. Therefore the +# default_slice attribute specifies that the "difference" channel should be +# shown by default. +# +# Alternate version using an integer would look like this (note 2 is a string):: +# +# data:NXdata +# @signal = "data" +# @axes = ["image_id", "channel", ".", "."] +# @image_id_indices = 0 +# @channel_indices = 1 +# @default_slice = [".", "2", ".", "."] +# image_id = [1, ..., nP] +# channel = ["threshold_1", "threshold_2", "difference"] +# data = uint[nP, nC, i, j] +# +# +# +# +# +# Points to the path of a field defining the data to which the `DATA` group refers. +# +# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Example: +# If the data corresponds to a readout of a detector, ``@reference`` links +# to that detectors data: +# +# @reference: '/entry/instrument/detector/data' for a 2D detector +# +# +# +# +# The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` +# dimension(s) are spanned by the corresponding axis. The first dimension index is ``0`` (zero). +# +# When the ``AXISNAME_indices`` attribute is missing for an :ref:`AXISNAME </NXdata/AXISNAME-field>` field, its value becomes the index +# (or indices) of the :ref:`AXISNAME </NXdata/AXISNAME-field>` name in the :ref:`axes </NXdata@axes-attribute>` attribute. +# +# .. note:: When ``AXISNAME_indices`` contains multiple integers, it must be saved as an actual array +# of integers and not a comma separated string. +# +# +# +# +# .. index:: plotting +# +# The ``axes`` attribute is a list of strings which are the names of the :ref:`AXISNAME </NXdata/AXISNAME-field>` fields +# that contain the values of the coordinates along the :ref:`data </NXdata/DATA-field>` dimensions. +# +# .. note:: When ``axes`` contains multiple strings, it must be saved as an actual array +# of strings and not a single comma separated string. +# +# +# +# +# +# +# Coordinate values along one or more :ref:`data </NXdata/DATA-field>` dimensions. The rank must be equal +# to the number of dimensions it spans. +# +# As the upper case ``AXISNAME`` indicates, the names of the ``AXISNAME`` fields can be chosen :ref:`freely <validItemName>`. +# The :ref:`axes </NXdata@axes-attribute>` attribute can be used to find all datasets in the +# ``NXdata`` that contain coordinate values. +# +# Most AXISNAME fields will be sequences of numbers but if an axis is better represented using names, such as channel names, +# an array of NX_CHAR can be provided. +# +# Axis label +# +# +# Unit in which the coordinate values are expressed. +# See the section :ref:`Design-Units` for more information. +# +# +# +# +# ``0|false``: single value, +# ``1|true``: multiple values +# +# +# Index of first good value +# Index of last good value +# +# +# Index (positive integer) identifying this specific set of numbers. +# +# N.B. The ``axis`` attribute is the old way of designating a link. +# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. +# The :ref:`axes </NXdata@axes-attribute>` attribute is now preferred. +# +# +# +# +# Points to the path of a field defining the axis to which the ``AXISNAME`` axis refers. +# +# This concept allows to link an axis to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Examples: +# If a calibration has been performed, ``@reference`` links to the result of +# that calibration: +# +# @reference: '/entry/process/calibration/calibrated_axis' +# +# If the axis corresponds to a coordinate of a detector, ``@reference`` links +# to that detector axis: +# +# @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector +# +# If the axis is a scanned motor, ``@reference`` links to the transformation +# describing the respective motion, e.g.: +# +# @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector +# +# +# +# +# +# .. index:: plotting +# +# Data values to be used as the NeXus *plottable data*. As the upper case ``DATA`` +# indicates, the names of the ``DATA`` fields can be chosen :ref:`freely <validItemName>`. The :ref:`signal attribute </NXdata@signal-attribute>` +# and :ref:`auxiliary_signals attribute</NXdata@auxiliary_signals-attribute>` can be used to find all datasets in the ``NXdata`` +# that contain data values. +# +# The maximum rank is ``32`` for compatibility with backend file formats. +# +# +# +# The rank (``dataRank``) of the ``data`` must satisfy +# ``1 <= dataRank <= NX_MAXRANK=32``. +# +# +# +# +# .. index:: plotting +# +# Plottable (independent) axis, indicate index number. +# Only one field in a :ref:`NXdata` group may have the +# ``signal=1`` attribute. +# Do not use the ``signal`` attribute with the ``axis`` attribute. +# +# +# +# +# Defines the names of the coordinates +# (independent axes) for this data set +# as a colon-delimited array. +# NOTE: The :ref:`axes </NXdata@axes-attribute>` attribute is the preferred +# method of designating a link. +# Do not use the :ref:`axes </NXdata@axes-attribute>` attribute with the ``axis`` attribute. +# +# +# +# data label +# +# +# +# Points to the path of a field defining the data to which the `DATA` field refers. +# +# This concept allows to link the data to a respective field in the NeXus hierarchy, thereby +# defining the physical quantity it represents. +# +# Here, *DATA* is to be replaced by the name of each +# data field. +# +# Example: +# If the data corresponds to a readout of a detector, ``@reference`` links +# to that detectors data: +# +# @reference: '/entry/instrument/detector/data' for a 2D detector +# +# +# +# +# +# "Errors" (meaning *uncertainties* or *standard deviations*) +# associated with any field named ``FIELDNAME`` in this ``NXdata`` +# group (e.g. an axis, signal or auxiliary signal). +# +# The dimensions of the ``FIELDNAME_errors`` field must match +# the dimensions of the ``FIELDNAME`` field. +# +# +# +# +# Standard deviations of data values - +# the data array is identified by the group attribute ``signal``. +# The ``errors`` array must have the same dimensions as ``DATA``. +# Client is responsible for defining the dimensions of the data. +# +# +# +# The ``errors`` must have the same rank (``dataRank``) +# as the ``data``. +# +# +# +# +# +# +# +# An optional scaling factor to apply to the values in any field named ``FIELDNAME`` +# in this ``NXdata`` group. This can be a :ref:`DATA </NXdata/DATA-field>` field +# (signal or auxiliary signal) or a :ref:`AXISNAME </NXdata/AXISNAME-field>` +# field (axis). +# +# The elements stored in NXdata datasets are often stored as integers for efficiency +# reasons and need further correction or conversion, generating floats. For example, +# raw values could be stored from a device that need to be converted to values that +# represent the physical values. The two fields FIELDNAME_scaling_factor and +# FIELDNAME_offset allow linear corrections using the following convention: +# +# .. code-block:: +# +# corrected values = (FIELDNAME + offset) * scaling_factor +# +# This formula will derive the values to use in downstream applications, when necessary. +# +# When omitted, the scaling factor is assumed to be 1. +# +# +# +# +# An optional offset to apply to the values in FIELDNAME (usually the signal). +# +# When omitted, the offset is assumed to be 0. +# +# See :ref:`FIELDNAME_scaling_factor </NXdata/FIELDNAME_scaling_factor-field>` for more information. +# +# +# +# +# +# The scaling_factor and FIELDNAME_scaling_factor fields have similar semantics. +# However, scaling_factor is ambiguous in the case of multiple signals. Therefore +# scaling_factor is deprecated. Use FIELDNAME_scaling_factor instead, even when +# only a single signal is present. +# +# +# +# +# The offset and FIELDNAME_offset fields have similar semantics. +# However, offset is ambiguous in the case of multiple signals. Therefore +# offset is deprecated. Use FIELDNAME_offset instead, even when +# only a single signal is present. +# +# +# +# +# +# +# +# Title for the plot. +# +# +# +# +# +# +# This is an array holding the values to use for the x-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# +# +# +# This is an array holding the values to use for the y-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# +# +# +# This is an array holding the values to use for the z-axis of +# data. The units must be appropriate for the measurement. +# +# This is a special case of a :ref:`AXISNAME field </NXdata/AXISNAME-field>` +# kept for backward compatiblity. +# +# +# +# +# # diff --git a/base_classes/nyaml/NXdetector.yaml b/base_classes/nyaml/NXdetector.yaml index 56e2ef79d4..4c8e650038 100644 --- a/base_classes/nyaml/NXdetector.yaml +++ b/base_classes/nyaml/NXdetector.yaml @@ -3,16 +3,13 @@ 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. + 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: | @@ -20,12 +17,11 @@ symbols: j: | number of detector pixels in the second (faster) direction k: | - number of detector pixels in the third (if necessary, fastest) - direction + 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: +(NXcomponent)NXdetector: time_of_flight(NX_FLOAT): unit: NX_TIME_OF_FLIGHT doc: | @@ -288,19 +284,31 @@ type: group Description of type such as He3 gas cylinder, He3 PSD, scintillator, fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, CMOS, ... + CHANNELNAME_channel(NXdetector_channel): + nameType: partial + doc: | + Group containing the description and metadata for a single channel from a multi-channel + detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with + named channels (see the example in :ref:`NXdata `), + the NXdetector will have a series of NXdetector_channel groups, one for each channel, + named CHANNELNAME_channel. 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] + enumeration: + + # TODO: clarify the various use cases + items: [., . ., . . ., . . . ., wavelength] \@wavelength_indices: - - # TODO: clarify the actual possibilities - enumeration: [0] + enumeration: + + # TODO: clarify the actual possibilities + items: [0] efficiency(NX_FLOAT): unit: NX_DIMENSIONLESS doc: | @@ -313,10 +321,10 @@ type: group doc: | This field can be two things: - 1. For a pixel detector it provides the nominal wavelength + #. 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 + #. 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. @@ -384,7 +392,7 @@ type: group image. dimensions: rank: 1 - dim: (nBrightFrames,) + dim: (nP,) beam_center_x(NX_FLOAT): unit: NX_LENGTH doc: | @@ -673,81 +681,19 @@ type: group 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 ++++++++++++++++++++++++++++++++++ -# 055d691f6d52260c723491fd5accd9362b13886c04f933c3f8f979702d40e6cc -# -# +# bbf96a27a822e91127e7219bf7f4e308221898c0012e7cc0c3cd4855f0628fda +# +# # -# -# -# -# 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. +# 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. # -# -# -# 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. -# +# +# number of scan points (only present in scanning measurements) +# number of detector pixels in the first (slowest) direction +# number of detector pixels in the second (faster) direction +# number of detector pixels in the third (if necessary, fastest) direction +# number of bins in the time-of-flight histogram +# +# +# +# A detector, detector bank, or multidetector. +# +# +# +# Total time of flight +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# Total time of flight +# +# +# +# +# In DAQ clock pulses +# +# +# +# +# +# +# Clock frequency in Hz +# +# +# +# +# +# Identifier for detector (pixels) +# Can be multidimensional, if needed +# +# +# +# +# +# Data values from the detector. The rank and dimension ordering should follow a principle of +# slowest to fastest measurement axes and may be explicitly specified in application definitions. +# +# Mechanical scanning of objects (e.g. sample position/angle, incident beam energy, etc) tends to be +# the slowest part of an experiment and so any such scan axes should be allocated to the first dimensions +# of the array. Note that in some cases it may be useful to represent a 2D set of scan points as a single +# scan-axis in the data array, especially if the scan pattern doesn't fit a rectangular array nicely. +# Repetition of an experiment in a time series tends to be used similar to a slow scan axis +# and so will often be in the first dimension of the data array. +# +# The next fastest axes are typically the readout of the detector. A point detector will not add any dimensions +# (as it is just a single value per scan point) to the data array, a strip detector will add one dimension, an +# imaging detector will add two dimensions (e.g. X, Y axes) and detectors outputting higher dimensional data +# will add the corresponding number of dimensions. Note that the detector dimensions don't necessarily have to +# be written in order of the actual readout speeds - the slowest to fastest rule principle is only a guide. +# +# Finally, detectors that operate in a time-of-flight mode, such as a neutron spectrometer or a silicon drift +# detector (used for X-ray fluorescence) tend to have their dimension(s) added to the last dimensions in the data array. +# +# The type of each dimension should should follow the order of scan points, detector pixels, +# then time-of-flight (i.e. spectroscopy, spectrometry). The rank and dimension sizes (see symbol list) +# shown here are merely illustrative of coordination between related datasets. +# +# +# +# +# +# +# +# +# +# +# Title of measurement +# +# +# +# Integral of data as check of data integrity +# +# +# +# +# +# +# The best estimate of the uncertainty in the data value (array size should match the data field). Where +# possible, this should be the standard deviation, which has the same units +# as the data. The form data_error is deprecated. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Offset from the detector center in x-direction. +# Can be multidimensional when needed. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# x-axis offset from detector center +# +# +# +# +# +# Offset from the detector center in the y-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# +# Offset from the detector center in the z-direction. +# Can be multidimensional when different values are required for each pixel. +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# y-axis offset from detector center +# +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the polar angle of the detector towards the previous +# component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the polar_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the polar_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# +# This is the azimuthal angle angle of the detector towards +# the previous component in the instrument; most often the sample. +# The usage depends on the +# nature of the detector. +# Most often it is the azimuthal_angle of the detector assembly. +# But there are irregular detectors. +# In this +# case, the azimuthal_angle must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# +# name/manufacturer/model/etc. information +# +# +# +# Serial number for the detector +# +# +# +# Local name for the detector +# +# +# +# Position and orientation of detector +# +# +# +# Solid angle subtended by the detector at the sample +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size. +# +# +# +# +# +# +# +# +# +# Size of each detector pixel. If it is scalar all pixels are the same size +# +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# +# +# Detector gas pressure +# +# +# +# +# +# +# +# +# maximum drift space dimension +# +# +# +# Crate number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Slot number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# Input number of detector +# +# +# +# +# +# +# +# Equivalent local term +# +# +# +# +# +# Description of type such as He3 gas cylinder, He3 PSD, scintillator, +# fission chamber, proportion counter, ion chamber, ccd, pixel, image plate, +# CMOS, ... +# +# +# +# +# +# Group containing the description and metadata for a single channel from a multi-channel +# detector. +# +# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with +# named channels (see the example in :ref:`NXdata </NXdata@default_slice-attribute>`), +# the NXdetector will have a series of NXdetector_channel groups, one for each channel, +# named CHANNELNAME_channel. +# +# +# +# +# Spectral efficiency of detector with respect to e.g. wavelength +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# +# +# +# This field can be two things: +# +# #. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# #. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# +# +# +# +# Real-time of the exposure (use this if exposure time varies for +# each array element, otherwise use ``count_time`` field). +# +# Most often there is a single real time value that is constant across +# an entire image frame. In such cases, only a 1-D array is needed. +# But there are detectors in which the real time +# changes per pixel. In that case, more than one dimension is needed. Therefore +# the rank of this field should be less than or equal to (detector rank + 1). +# +# +# +# +# +# +# +# +# +# start time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# stop time for each frame, with the ``start`` attribute as absolute reference +# +# +# +# +# +# +# +# +# date of last calibration (geometry and/or efficiency) measurements +# +# +# +# +# +# summary of conversion of array data to pixels (e.g. polynomial +# approximations) and location of details of the calibrations +# +# +# +# +# How the detector is represented +# +# +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# +# +# +# +# Use this group to provide other data related to this NXdetector group. +# +# +# +# +# +# In order to properly sort the order of the images taken in (for +# example) a tomography experiment, a sequence number is stored with each +# image. +# +# +# +# +# +# +# +# +# +# This is the x position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the y position where the direct beam would hit the detector. +# This is a length and can be outside of the actual +# detector. The length can be in physical units or pixels +# as documented by the units attribute. +# +# +# +# +# +# This is the start number of the first frame of a scan. In protein crystallography measurements one +# often scans a couple of frames on a give sample, then does something else, +# then returns to the same sample and scans some more frames. Each time with +# a new data file. This number helps concatenating such measurements. +# +# +# +# +# The diameter of a cylindrical detector +# +# +# +# The acquisition mode of the detector. +# +# +# +# +# +# +# +# +# +# +# +# +# True when the angular calibration has been applied in the +# electronics, false otherwise. +# +# +# +# Angular calibration data. +# +# +# +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# Flat field correction data. +# +# +# +# +# +# +# +# Errors of the flat field correction data. +# The form flatfield_error is deprecated. +# +# +# +# +# +# +# +# +# True when the pixel mask correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# The 32-bit pixel mask for the detector. Can be either one mask +# for the whole dataset (i.e. an array with indices i, j) or +# each frame can have its own mask (in which case it would be +# an array with indices np, i, j). +# +# Contains a bit field for each pixel to signal dead, +# blind or high or otherwise unwanted or undesirable pixels. +# They have the following meaning: +# +# .. can't make a table here, a bullet list will have to do for now +# +# * bit 0: gap (pixel with no sensor) +# * bit 1: dead +# * bit 2: under responding +# * bit 3: over responding +# * bit 4: noisy +# * bit 5: -undefined- +# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) +# * bit 7: -undefined- +# * bit 8: user defined mask (e.g. around beamstop) +# * bits 9-30: -undefined- +# * bit 31: virtual pixel (corner pixel with interpolated value) +# +# Normal data analysis software would +# not take pixels into account +# when a bit in (mask & 0x0000FFFF) is +# set. Tag bit in the upper +# two bytes would indicate special pixel +# properties that normally +# would not be a sole reason to reject the +# intensity value (unless +# lower bits are set. +# +# If the full bit depths is not required, providing a +# mask with fewer bits is permissible. +# +# If needed, additional pixel masks can be specified by +# including additional entries named pixel_mask_N, where +# N is an integer. For example, a general bad pixel mask +# could be specified in pixel_mask that indicates noisy +# and dead pixels, and an additional pixel mask from +# experiment-specific shadowing could be specified in +# pixel_mask_2. The cumulative mask is the bitwise OR +# of pixel_mask and any pixel_mask_N entries. +# +# +# +# +# +# +# +# +# +# This field allow to distinguish different types of exposure to the same detector "data" field. +# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of +# recording the different measurements preserves the chronological order with is important for +# correct processing. +# +# This is used for example in tomography (`:ref:`NXtomo`) sample projections, +# dark and flat images, a magic number is recorded per frame. +# +# The key is as follows: +# +# * projection (sample) = 0 +# * flat field = 1 +# * dark field = 2 +# * invalid = 3 +# * background (no sample, but buffer where applicable) = 4 +# +# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. +# +# +# +# +# +# +# +# +# Counting detectors usually are not able to measure all incoming particles, +# especially at higher count-rates. Count-rate correction is applied to +# account for these errors. +# +# True when count-rate correction has been applied, false otherwise. +# +# +# +# +# The countrate_correction_lookup_table defines the LUT used for count-rate +# correction. It maps a measured count :math:`c` to its corrected value +# :math:`countrate\_correction\_lookup\_table[c]`. +# +# :math:`m` denotes the length of the table. +# +# +# +# +# +# +# +# True when virtual pixel interpolation has been applied, false otherwise. +# +# When virtual pixel interpolation is applied, values of some pixels may +# contain interpolated values. For example, to account for space between +# readout chips on a module, physical pixels on edges and corners between +# chips may have larger sensor areas and counts may be distributed between +# their logical pixels. +# +# +# +# +# How many bits the electronics reads per pixel. +# With CCD's and single photon counting detectors, +# this must not align with traditional integer sizes. +# This can be 4, 8, 12, 14, 16, ... +# +# +# +# +# Time it takes to read the detector (typically milliseconds). +# This is important to know for time resolved experiments. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector firmware after receiving the trigger signal +# to when the detector starts to acquire the exposure, including any user set delay.. +# This is important to know for time resolved experiments. +# +# +# +# +# User-specified trigger delay. +# +# +# +# +# Time it takes to start exposure after a trigger signal has been received. +# This is the reaction time of the detector hardware after receiving the +# trigger signal to when the detector starts to acquire the exposure. +# It forms the lower boundary of the trigger_delay_time when the user +# does not request an additional delay. +# +# +# +# +# Time during which no new trigger signal can be accepted. +# Typically this is the +# trigger_delay_time + exposure_time + readout_time. +# This is important to know for time resolved experiments. +# +# +# +# +# This is time for each frame. This is exposure_time + readout time. +# +# +# +# +# +# +# +# The gain setting of the detector. This is a detector-specific value +# meant to document the gain setting of the detector during data +# collection, for detectors with multiple available gain settings. +# +# Examples of gain settings include: +# +# * ``standard`` +# * ``fast`` +# * ``auto`` +# * ``high`` +# * ``medium`` +# * ``low`` +# * ``mixed high to medium`` +# * ``mixed medium to low`` +# +# Developers are encouraged to use one of these terms, or to submit +# additional terms to add to the list. +# +# +# +# +# The value at which the detector goes into saturation. +# Especially common to CCD detectors, the data +# is known to be invalid above this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# The lowest value at which pixels for this detector would be reasonably +# measured. The data is known to be invalid below this value. +# +# For example, given a saturation_value and an underload_value, the valid +# pixels are those less than or equal to the saturation_value and greater +# than or equal to the underload_value. +# +# The precise type should match the type of the data. +# +# +# +# +# CCD images are sometimes constructed by summing +# together multiple short exposures in the +# electronics. This reduces background etc. +# This is the number of short exposures used to sum +# images for an image. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the name of this converter material. +# +# +# +# +# At times, radiation is not directly sensed by the detector. +# Rather, the detector might sense the output from some +# converter like a scintillator. +# This is the thickness of this converter material. +# +# +# +# +# Single photon counter detectors can be adjusted +# for a certain energy range in which they +# work optimally. This is the energy setting for this. +# +# +# +# +# For use in special cases where the data in NXdetector +# is represented in several parts, each with a separate geometry. +# +# +# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape. +# # -# -# -# In order to properly sort the order of the images taken in (for -# example) a tomography experiment, a sequence number is stored with each -# image. -# -# -# -# -# -# -# -# This is the x position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the y position where the direct beam would hit the detector. -# This is a length and can be outside of the actual -# detector. The length can be in physical units or pixels -# as documented by the units attribute. -# -# -# -# -# This is the start number of the first frame of a scan. In protein crystallography measurements one -# often scans a couple of frames on a give sample, then does something else, -# then returns to the same sample and scans some more frames. Each time with -# a new data file. This number helps concatenating such measurements. -# -# -# -# -# The diameter of a cylindrical detector -# -# -# -# -# The acquisition mode of the detector. -# -# -# -# -# -# -# -# -# -# -# -# -# -# True when the angular calibration has been applied in the -# electronics, false otherwise. -# -# -# -# -# Angular calibration data. -# -# -# -# -# -# -# -# -# True when the flat field correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# Flat field correction data. -# -# -# -# -# -# -# -# -# Errors of the flat field correction data. -# The form flatfield_error is deprecated. -# -# -# -# -# -# -# -# -# True when the pixel mask correction has been applied in the -# electronics, false otherwise. -# -# -# -# -# The 32-bit pixel mask for the detector. Can be either one mask -# for the whole dataset (i.e. an array with indices i, j) or -# each frame can have its own mask (in which case it would be -# an array with indices np, i, j). -# -# Contains a bit field for each pixel to signal dead, -# blind or high or otherwise unwanted or undesirable pixels. -# They have the following meaning: -# -# .. can't make a table here, a bullet list will have to do for now -# -# * bit 0: gap (pixel with no sensor) -# * bit 1: dead -# * bit 2: under responding -# * bit 3: over responding -# * bit 4: noisy -# * bit 5: -undefined- -# * bit 6: pixel is part of a cluster of problematic pixels (bit set in addition to others) -# * bit 7: -undefined- -# * bit 8: user defined mask (e.g. around beamstop) -# * bits 9-30: -undefined- -# * bit 31: virtual pixel (corner pixel with interpolated value) -# -# Normal data analysis software would -# not take pixels into account -# when a bit in (mask & 0x0000FFFF) is -# set. Tag bit in the upper -# two bytes would indicate special pixel -# properties that normally -# would not be a sole reason to reject the -# intensity value (unless -# lower bits are set. -# -# If the full bit depths is not required, providing a -# mask with fewer bits is permissible. -# -# If needed, additional pixel masks can be specified by -# including additional entries named pixel_mask_N, where -# N is an integer. For example, a general bad pixel mask -# could be specified in pixel_mask that indicates noisy -# and dead pixels, and an additional pixel mask from -# experiment-specific shadowing could be specified in -# pixel_mask_2. The cumulative mask is the bitwise OR -# of pixel_mask and any pixel_mask_N entries. -# -# -# -# -# -# -# -# -# This field allow to distinguish different types of exposure to the same detector "data" field. -# Some techniques require frequent (re-)calibration inbetween measuremnts and this way of -# recording the different measurements preserves the chronological order with is important for -# correct processing. -# -# This is used for example in tomography (`:ref:`NXtomo`) sample projections, -# dark and flat images, a magic number is recorded per frame. -# -# The key is as follows: -# -# * projection (sample) = 0 -# * flat field = 1 -# * dark field = 2 -# * invalid = 3 -# * background (no sample, but buffer where applicable) = 4 -# -# In cases where the data is of type :ref:`NXlog` this can also be an NXlog. -# -# -# -# -# -# -# -# Counting detectors usually are not able to measure all incoming particles, -# especially at higher count-rates. Count-rate correction is applied to -# account for these errors. -# -# True when count-rate correction has been applied, false otherwise. -# -# -# -# -# The countrate_correction_lookup_table defines the LUT used for count-rate -# correction. It maps a measured count :math:`c` to its corrected value -# :math:`countrate\_correction\_lookup\_table[c]`. -# -# :math:`m` denotes the length of the table. -# -# -# -# -# -# -# -# True when virtual pixel interpolation has been applied, false otherwise. -# -# When virtual pixel interpolation is applied, values of some pixels may -# contain interpolated values. For example, to account for space between -# readout chips on a module, physical pixels on edges and corners between -# chips may have larger sensor areas and counts may be distributed between -# their logical pixels. -# -# -# -# -# How many bits the electronics reads per pixel. -# With CCD's and single photon counting detectors, -# this must not align with traditional integer sizes. -# This can be 4, 8, 12, 14, 16, ... -# -# -# -# -# Time it takes to read the detector (typically milliseconds). -# This is important to know for time resolved experiments. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector firmware after receiving the trigger signal -# to when the detector starts to acquire the exposure, including any user set delay.. -# This is important to know for time resolved experiments. -# -# -# -# -# User-specified trigger delay. -# -# -# -# -# Time it takes to start exposure after a trigger signal has been received. -# This is the reaction time of the detector hardware after receiving the -# trigger signal to when the detector starts to acquire the exposure. -# It forms the lower boundary of the trigger_delay_time when the user -# does not request an additional delay. -# -# -# -# -# Time during which no new trigger signal can be accepted. -# Typically this is the -# trigger_delay_time + exposure_time + readout_time. -# This is important to know for time resolved experiments. -# -# -# -# -# This is time for each frame. This is exposure_time + readout time. -# -# -# -# -# -# -# -# The gain setting of the detector. This is a detector-specific value -# meant to document the gain setting of the detector during data -# collection, for detectors with multiple available gain settings. -# -# Examples of gain settings include: -# -# * ``standard`` -# * ``fast`` -# * ``auto`` -# * ``high`` -# * ``medium`` -# * ``low`` -# * ``mixed high to medium`` -# * ``mixed medium to low`` -# -# Developers are encouraged to use one of these terms, or to submit -# additional terms to add to the list. -# -# -# -# -# The value at which the detector goes into saturation. -# Especially common to CCD detectors, the data -# is known to be invalid above this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# The lowest value at which pixels for this detector would be reasonably -# measured. The data is known to be invalid below this value. -# -# For example, given a saturation_value and an underload_value, the valid -# pixels are those less than or equal to the saturation_value and greater -# than or equal to the underload_value. -# -# The precise type should match the type of the data. -# -# -# -# -# CCD images are sometimes constructed by summing -# together multiple short exposures in the -# electronics. This reduces background etc. -# This is the number of short exposures used to sum -# images for an image. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the name of this converter material. -# -# -# -# -# At times, radiation is not directly sensed by the detector. -# Rather, the detector might sense the output from some -# converter like a scintillator. -# This is the thickness of this converter material. -# -# -# -# -# Single photon counter detectors can be adjusted -# for a certain energy range in which they -# work optimally. This is the energy setting for this. -# -# -# -# -# For use in special cases where the data in NXdetector -# is represented in several parts, each with a separate geometry. -# +# +# +# Shape description of each pixel. Use only if all pixels in the detector +# are of uniform shape and require being described by cylinders. +# # -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape. -# -# -# -# -# Shape description of each pixel. Use only if all pixels in the detector -# are of uniform shape and require being described by cylinders. -# -# -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape. -# -# -# -# -# Shape description of the whole detector. Use only if pixels in the -# detector are not of uniform shape and require being described by cylinders. -# -# -# -# -# -# .. index:: plotting -# -# Declares which child group contains a path leading -# to a :ref:`NXdata` group. -# -# It is recommended (as of NIAC2014) to use this attribute -# to help define the path to the default dataset to be plotted. -# See https://www.nexusformat.org/2014_How_to_find_default_data.html -# for a summary of the discussion. -# -# -# -# -# Type of electron amplifier, MCP, channeltron, etc. -# -# -# -# -# Description of the detector type, DLD, Phosphor+CCD, CMOS. -# -# -# -# -# Voltage applied to detector. -# -# -# -# -# Voltage applied to the amplifier. -# -# -# -# -# The low voltage of the amplifier migh not be the ground. -# -# -# -# -# Size of each imaging sensor chip on the detector. -# -# -# -# -# Number of imaging sensor chips on the detector. -# -# -# -# -# Physical size of the pixels of the imaging chip on the detector. -# -# -# -# -# Number of raw active elements in each dimension. Important for swept scans. -# -# -# -# -# -# raw data output from the detector -# +# +# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape. +# # -# -# -# NeXus positions components by applying a set of translations and rotations -# to apply to the component starting from 0, 0, 0. The order of these operations -# is critical and forms what NeXus calls a dependency chain. The depends_on -# field defines the path to the top most operation of the dependency chain or the -# string "." if located in the origin. Usually these operations are stored in a -# NXtransformations group. But NeXus allows them to be stored anywhere. -# -# The reference point of the detector is the center of the first pixel. -# In complex geometries the NXoff_geometry groups can be used to provide an unambiguous reference. -# -# -# -# -# This is the group recommended for holding the chain of translation -# and rotation operations necessary to position the component within -# the instrument. The dependency chain may however traverse similar groups in -# other component groups. -# +# +# +# Shape description of the whole detector. Use only if pixels in the +# detector are not of uniform shape and require being described by cylinders. +# # +# +# +# +# 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. +# +# # diff --git a/base_classes/nyaml/NXdetector_channel.yaml b/base_classes/nyaml/NXdetector_channel.yaml new file mode 100644 index 0000000000..0cfe05d48c --- /dev/null +++ b/base_classes/nyaml/NXdetector_channel.yaml @@ -0,0 +1,285 @@ +category: base +doc: | + Description and metadata for a single channel from a multi-channel detector. + + Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the + example in :ref:`NXdata `), the NXdetector will have a series of NXdetector_channel groups, one for each + channel, named CHANNELNAME_channel. + + Example, given these axes in the NXdata group:: + + @axes = ["image_id", "channel", ".", "."] + + And this list of channels in the NXdata group:: + + channel = ["threshold_1", "threshold_2", "difference"] + + The NXdetector group would have three NXdetector_channel groups:: + + detector:NXdetector + ... + threshold_1_channel:NXdetector_channel + threshold_energy = float + flatfield = float[i, j] + pixel_mask = uint[i, j] + flatfield_applied = bool + pixel_mask_applied = bool + threshold_2_channel:NXdetector_channel + threshold_energy = float + flatfield = float[i, j] + pixel_mask = uint[i, j] + flatfield_applied = bool + pixel_mask_applied = bool + difference_channel:NXdetector_channel + threshold_energy = float[2] +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 (2D), but three or higher dimensional arrays can be produced + by a detector at each trigger. + dataRank: | + Rank of the ``data`` field associated with this detector + nP: | + number of scan points + i: | + number of detector pixels in the slowest direction + j: | + number of detector pixels in the second slowest direction + k: | + number of detector pixels in the third slowest direction +type: group +(NXobject)NXdetector_channel: + threshold_energy(NX_FLOAT): + unit: NX_ENERGY + doc: | + Energy at which a photon will be recorded + flatfield_applied(NX_BOOLEAN): + doc: | + True when the flat field correction has been applied in the + electronics, false otherwise. + flatfield(NX_NUMBER): + doc: | + Response of each pixel given a constant input + dimensions: + rank: dataRank + 1: + value: i + 2: + value: j + 3: + value: k + required: false + flatfield_errors(NX_FLOAT): + doc: | + Errors of the flat field correction data. + The form flatfield_error is deprecated. + dimensions: + rank: 2 + dim: (i, 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: | + Custom pixel mask for this channel. May include nP as the first dimension for + masks that vary for each scan point. + dimensions: + rank: dataRank + 2: + value: i + 3: + value: j + 4: + value: k + required: false + 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. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# 0e41563b15b2e34fa2cd80146679d7cf6e14600182590333d049d312a6c6829b +# +# +# +# +# +# +# +# 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 (2D), but three or higher dimensional arrays can be produced +# by a detector at each trigger. +# +# +# Rank of the ``data`` field associated with this detector +# number of scan points +# number of detector pixels in the slowest direction +# number of detector pixels in the second slowest direction +# number of detector pixels in the third slowest direction +# +# +# +# Description and metadata for a single channel from a multi-channel detector. +# +# Given an :ref:`NXdata` group linked as part of an NXdetector group that has an axis with named channels (see the +# example in :ref:`NXdata </NXdata@default_slice-attribute>`), the NXdetector will have a series of NXdetector_channel groups, one for each +# channel, named CHANNELNAME_channel. +# +# Example, given these axes in the NXdata group:: +# +# @axes = ["image_id", "channel", ".", "."] +# +# And this list of channels in the NXdata group:: +# +# channel = ["threshold_1", "threshold_2", "difference"] +# +# The NXdetector group would have three NXdetector_channel groups:: +# +# detector:NXdetector +# ... +# threshold_1_channel:NXdetector_channel +# threshold_energy = float +# flatfield = float[i, j] +# pixel_mask = uint[i, j] +# flatfield_applied = bool +# pixel_mask_applied = bool +# threshold_2_channel:NXdetector_channel +# threshold_energy = float +# flatfield = float[i, j] +# pixel_mask = uint[i, j] +# flatfield_applied = bool +# pixel_mask_applied = bool +# difference_channel:NXdetector_channel +# threshold_energy = float[2] +# +# +# +# Energy at which a photon will be recorded +# +# +# +# +# True when the flat field correction has been applied in the +# electronics, false otherwise. +# +# +# +# +# Response of each pixel given a constant input +# +# +# +# +# +# +# +# +# +# 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. +# +# +# +# +# +# Custom pixel mask for this channel. May include nP as the first dimension for +# masks that vary for each scan point. +# +# +# +# +# +# +# +# +# +# +# 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. +# +# +# diff --git a/base_classes/nyaml/NXdetector_group.yaml b/base_classes/nyaml/NXdetector_group.yaml index 0f40373412..bb709feb68 100644 --- a/base_classes/nyaml/NXdetector_group.yaml +++ b/base_classes/nyaml/NXdetector_group.yaml @@ -61,26 +61,15 @@ NXdetector_group(NXobject): dimensions: 1: ref: group_index - \@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 ++++++++++++++++++++++++++++++++++ -# f45191db44919853b9541c745aaf9cc258949e6765ba309e82c059a1c6c13abe +# fe39ff1d50f0c35d9df400d11b7d312b6e43aef5fdde206c393c4bfeb682895d # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays @@ -109,11 +106,6 @@ NXdistortion(NXobject): # # Subclass of NXprocess to describe post-processing distortion correction. # -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# # # # Has the distortion correction been applied? diff --git a/base_classes/nyaml/NXelectron_detector.yaml b/base_classes/nyaml/NXelectron_detector.yaml new file mode 100644 index 0000000000..c408c751aa --- /dev/null +++ b/base_classes/nyaml/NXelectron_detector.yaml @@ -0,0 +1,86 @@ +category: base +doc: | + A subclass of NXdetector for detectors that detect electrons. +type: group +(NXdetector)NXelectron_detector: + amplifier_type(NX_CHAR): + doc: | + Type of electron amplifier, MCP, channeltron, etc. + detector_type(NX_CHAR): + doc: | + Description of the electron detector type, DLD, Phosphor+CCD, CMOS. + detector_voltage(NX_FLOAT): + unit: NX_VOLTAGE + doc: | + Voltage applied to the electron 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 might not be the ground. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# d8e0701316826dc2989f6bf9bb0f3884ca2f7b2285dc8e80de17b7f8577f6ca1 +# +# +# +# +# +# A subclass of NXdetector for detectors that detect electrons. +# +# +# +# Type of electron amplifier, MCP, channeltron, etc. +# +# +# +# +# Description of the electron detector type, DLD, Phosphor+CCD, CMOS. +# +# +# +# +# Voltage applied to the electron detector. +# +# +# +# +# Voltage applied to the amplifier. +# +# +# +# +# The low voltage of the amplifier might not be the ground. +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXentry.yaml b/base_classes/nyaml/NXentry.yaml index 8bfaf10480..cd1c3ba9ac 100644 --- a/base_classes/nyaml/NXentry.yaml +++ b/base_classes/nyaml/NXentry.yaml @@ -62,7 +62,14 @@ NXentry(NXobject): title: doc: | Extended title for entry - experiment_identifier(NXidentifier): + experiment_identifier: + deprecated: | + Use the field :ref:`identifier_experiment ` instead. + doc: | + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + identifier_experiment: doc: | Unique identifier for the experiment, defined by the facility, @@ -70,24 +77,62 @@ NXentry(NXobject): experiment_description: doc: | Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: + experiment_documentation(NXnote): doc: | Description of the full experiment (document in pdf, latex, ...) - collection_identifier(NXidentifier): + collection_identifier: + deprecated: | + Use the field :ref:`identifier_collection ` instead. + doc: | + User or Data Acquisition defined group of NeXus files or NXentry + identifier_collection: doc: | User or Data Acquisition defined group of NeXus files or NXentry collection_description: doc: | Brief summary of the collection, including grouping criteria. - entry_identifier(NXidentifier): + entry_identifier: + deprecated: | + Use the field :ref:`identifier_entry ` instead. + doc: | + unique identifier for the measurement, defined by the facility. + identifier_entry: doc: | unique identifier for the measurement, defined by the facility. - entry_identifier_uuid(NXidentifier): + entry_identifier_uuid: + deprecated: | + Use the field :ref:`identifier_entry_uuid ` instead. doc: | UUID identifier for the measurement. \@version: doc: | Version of UUID used + identifier_entry_uuid: + doc: | + UUID identifier for the measurement. + \@version: + doc: | + Version of UUID used + experiment_location: + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current + measurement, for example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current + measurement, for example a beam time. + experiment_institution: + doc: | + Name of the institution hosting the facility + experiment_facility: + doc: | + Name of the experimental facility + experiment_laboratory: + doc: | + Name of the laboratory or beamline features: doc: | Reserved for future use by NIAC. @@ -178,30 +223,11 @@ NXentry(NXobject): \@type: doc: | The mime type should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the type attribute? - enumeration: [image/*] - experiment_location: - doc: | - City and country where the experiment took place - experiment_start_date(NX_DATE_TIME): - doc: | - Start time of experimental run that includes the current - measurement, for example a beam time. - experiment_end_date(NX_DATE_TIME): - doc: | - End time of experimental run that includes the current - measurement, for example a beam time. - experiment_institution: - doc: | - Name of the institution hosting the facility - experiment_facility: - doc: | - Name of the experimental facility - experiment_laboratory: - doc: | - Name of the laboratory or beamline + enumeration: + + # This is not perfect. + # How do we set a default value for the type attribute? + items: [image/*] (NXuser): (NXsample): (NXinstrument): @@ -212,13 +238,13 @@ NXentry(NXobject): (NXsubentry): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# ba5f7505e546fdcea01c457a4cce6c4bdaa3b0dae46e4f59d538b40ffcab8d5d -# -# +# fda44a0cda4f39df02b4ac1bc8629310f88dc0a413ed4e70d53c4ae6ac8f5f26 +# +# # -# -# -# (**required**) :ref:`NXentry` describes the measurement. -# -# The top-level NeXus group which contains all the data and associated -# information that comprise a single measurement. -# It is mandatory that there is at least one -# group of this type in the NeXus file. -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXdata` group contains the data -# to be shown by default. -# It is used to resolve ambiguity when -# one :ref:`NXdata` group exists. -# The value :ref:`names <validItemName>` a child group. If that group -# itself has a ``default`` attribute, continue this chain until an -# :ref:`NXdata` group is reached. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# The data group -# -# .. note:: Before the NIAC2016 meeting [#]_, at least one -# :ref:`NXdata` group was required in each :ref:`NXentry` group. -# At the NIAC2016 meeting, it was decided to make :ref:`NXdata` -# an optional group in :ref:`NXentry` groups for data files that -# do not use an application definition. -# It is recommended strongly that all NeXus data files provide -# a NXdata group. -# It is permissable to omit the NXdata group only when -# defining the default plot is not practical or possible -# from the available data. -# -# For example, neutron event data may not have anything that -# makes a useful plot without extensive processing. -# -# Certain application definitions override this decision and -# require an :ref:`NXdata` group -# in the :ref:`NXentry` group. The ``minOccurs=0`` attribute -# in the application definition will indicate the -# :ref:`NXdata` group -# is optional, otherwise, it is required. -# -# .. [#] NIAC2016: -# https://www.nexusformat.org/NIAC2016.html, -# https://github.com/nexusformat/NIAC/issues/16 -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# -# Extended title for entry -# -# -# -# -# Unique identifier for the experiment, -# defined by the facility, -# possibly linked to the proposals -# -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# -# -# User or Data Acquisition defined group of NeXus files or NXentry -# -# -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# -# -# UUID identifier for the measurement. -# -# -# -# Version of UUID used -# -# -# -# -# -# Reserved for future use by NIAC. -# -# See https://github.com/nexusformat/definitions/issues/382 -# -# -# -# -# (alternate use: see same field in :ref:`NXsubentry` for preferred) -# -# Official NeXus NXDL schema to which this entry conforms which must be -# the name of the NXDL file (case sensitive without the file extension) -# that the NXDL schema is defined in. -# -# For example the ``definition`` field for a file that conformed to the -# *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. -# -# This field is provided so that :ref:`NXentry` can be the overlay position -# in a NeXus data file for an application definition and its -# set of groups, fields, and attributes. -# -# *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Local NXDL schema extended from the entry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the entry. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Starting time of measurement -# -# -# -# -# Ending time of measurement -# -# -# -# -# Duration of measurement -# -# -# -# -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range -# -# -# -# -# Such as "2007-3". Some user facilities organize their beam time into run cycles. -# -# -# -# -# Name of program used to generate this file -# -# -# -# Program version number -# -# -# -# -# configuration of the program -# -# -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# Notes describing entry -# -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# -# The mime type should be an ``image/*`` -# -# -# -# -# -# -# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXdata` group contains the data +# to be shown by default. +# It is used to resolve ambiguity when +# one :ref:`NXdata` group exists. +# The value :ref:`names <validItemName>` a child group. If that group +# itself has a ``default`` attribute, continue this chain until an +# :ref:`NXdata` group is reached. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# (**required**) :ref:`NXentry` describes the measurement. +# +# The top-level NeXus group which contains all the data and associated +# information that comprise a single measurement. +# It is mandatory that there is at least one +# group of this type in the NeXus file. +# +# +# +# The data group +# +# .. note:: Before the NIAC2016 meeting [#]_, at least one +# :ref:`NXdata` group was required in each :ref:`NXentry` group. +# At the NIAC2016 meeting, it was decided to make :ref:`NXdata` +# an optional group in :ref:`NXentry` groups for data files that +# do not use an application definition. +# It is recommended strongly that all NeXus data files provide +# a NXdata group. +# It is permissable to omit the NXdata group only when +# defining the default plot is not practical or possible +# from the available data. +# +# For example, neutron event data may not have anything that +# makes a useful plot without extensive processing. +# +# Certain application definitions override this decision and +# require an :ref:`NXdata` group +# in the :ref:`NXentry` group. The ``minOccurs=0`` attribute +# in the application definition will indicate the +# :ref:`NXdata` group +# is optional, otherwise, it is required. +# +# .. [#] NIAC2016: +# https://www.nexusformat.org/NIAC2016.html, +# https://github.com/nexusformat/NIAC/issues/16 +# +# +# +# +# +# +# ISIS Muon IDF_Version +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or NXentry +# +# +# User or Data Acquisition defined group of NeXus files or NXentry +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# UUID identifier for the measurement. +# Version of UUID used +# +# +# UUID identifier for the measurement. +# Version of UUID used +# # -# -# City and country where the experiment took place -# +# City and country where the experiment took place # # # -# Start time of experimental run that includes the current -# measurement, for example a beam time. +# Start time of experimental run that includes the current +# measurement, for example a beam time. # # # @@ -512,12 +412,107 @@ NXentry(NXobject): # Name of the laboratory or beamline # # -# -# -# -# -# -# -# -# +# +# +# Reserved for future use by NIAC. +# +# See https://github.com/nexusformat/definitions/issues/382 +# +# +# +# +# (alternate use: see same field in :ref:`NXsubentry` for preferred) +# +# Official NeXus NXDL schema to which this entry conforms which must be +# the name of the NXDL file (case sensitive without the file extension) +# that the NXDL schema is defined in. +# +# For example the ``definition`` field for a file that conformed to the +# *NXarpes.nxdl.xml* definition must contain the string **NXarpes**. +# +# This field is provided so that :ref:`NXentry` can be the overlay position +# in a NeXus data file for an application definition and its +# set of groups, fields, and attributes. +# +# *It is advised* to use :ref:`NXsubentry`, instead, as the overlay position. +# +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the entry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the entry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The mime type should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# # diff --git a/base_classes/nyaml/NXenvironment.yaml b/base_classes/nyaml/NXenvironment.yaml index e9a5d9652e..2e1f99e4ca 100644 --- a/base_classes/nyaml/NXenvironment.yaml +++ b/base_classes/nyaml/NXenvironment.yaml @@ -8,12 +8,10 @@ NXenvironment(NXobject): Apparatus identification code/model number; e.g. OC100 011 short_name: doc: | - 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: doc: | - 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: doc: | Description of the apparatus; e.g. 100mm bore orange cryostat with Roots pump @@ -60,27 +58,16 @@ NXenvironment(NXobject): doc: | Any sensor used to monitor the environment. This can be linked to a sensor defined in an NXinstrument instance. - \@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 ++++++++++++++++++++++++++++++++++ -# 96f50b91956658459a6a86c0208cadb3396b27a68a7ac25d9eca1b04dafc57c6 -# -# +# 42ff61c479ba3c4466f8ad723cb3f07af542a72fc8dc15cf2519c8aeb221feff +# +# # -# -# -# 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 # # # @@ -140,33 +117,31 @@ NXenvironment(NXobject): # 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 # # # @@ -180,17 +155,4 @@ NXenvironment(NXobject): # 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/base_classes/nyaml/NXevent_data.yaml b/base_classes/nyaml/NXevent_data.yaml index 7725221860..78f7e6f365 100644 --- a/base_classes/nyaml/NXevent_data.yaml +++ b/base_classes/nyaml/NXevent_data.yaml @@ -78,26 +78,15 @@ NXevent_data(NXobject): doc: | Index into the event_id, event_time_offset pair matching the corresponding cue_timestamp. - \@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 ++++++++++++++++++++++++++++++++++ -# e8837e194fa0c000c2db7af81704e24a4b6f3f137639114e7191aa98f6d9bec5 +# f6906010c7c8919a81a00373200d1f8b536ba22ba717cf4788b1faee834ec30b # # # -# # # -# -# -# .. 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 fresnel zone plate. # # # -# -# -# "Engineering" position of the fresnel zone plate -# -# 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/NXgeometry.yaml b/base_classes/nyaml/NXgeometry.yaml index 5c1dfb277f..4a554408dd 100644 --- a/base_classes/nyaml/NXgeometry.yaml +++ b/base_classes/nyaml/NXgeometry.yaml @@ -32,26 +32,15 @@ NXgeometry(NXobject): Position of the component along the beam path. The sample is at 0, components upstream have negative component_index, components downstream have positive component_index. - \@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 ++++++++++++++++++++++++++++++++++ -# d7d64aa78775fa8184154f30651e5def6856d4f76f490ba44df0f5a37463b670 +# e0ba459b34c226ad28da5b6e55e2b177840f25fd60f3a5b22a13d14d5b709be9 # # # -# # -# -# -# .. 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 bending grating. -# # # # diff --git a/base_classes/nyaml/NXguide.yaml b/base_classes/nyaml/NXguide.yaml index 2d7946d398..f03536911c 100644 --- a/base_classes/nyaml/NXguide.yaml +++ b/base_classes/nyaml/NXguide.yaml @@ -32,7 +32,7 @@ symbols: nwl: | number of wavelengths type: group -NXguide(NXobject): +NXguide(NXcomponent): (NXgeometry): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the guid and NXoff_geometry to describe its shape instead @@ -45,7 +45,7 @@ NXguide(NXobject): unit: NX_ANGLE doc: | TODO: documentation needed - (NXdata)reflectivity: + reflectivity(NXdata): doc: | Reflectivity as function of reflecting surface and wavelength \@signal: @@ -146,26 +146,8 @@ NXguide(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - \@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 entry opening of the guide lies on the reference plane. The center of the opening on that plane is the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends @@ -173,21 +155,15 @@ NXguide(NXobject): .. image:: guide/guide.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 ++++++++++++++++++++++++++++++++++ -# 96b88aec5f6a62f0d4ec42fda4d365ec13150eab33fdb4b421e9f6f81f583f43 +# a276144986e9e9a54511db731379c390134bc655cfdddb5ba84ce80ca24c0681 # # # # # -# -# -# .. 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 entry opening of the guide lies on the reference plane. The center of the opening on that plane is # the reference point on the x and y axis. The reference plane is orthogonal to the z axis and is the # reference point along the z axis. Given no bend in the guide, it is parallel with z axis and extends @@ -399,16 +355,7 @@ NXguide(NXobject): # # .. image:: guide/guide.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/nyaml/NXhistory.yaml b/base_classes/nyaml/NXhistory.yaml similarity index 64% rename from contributed_definitions/nyaml/NXhistory.yaml rename to base_classes/nyaml/NXhistory.yaml index 718d73a015..23e4a54d76 100644 --- a/contributed_definitions/nyaml/NXhistory.yaml +++ b/base_classes/nyaml/NXhistory.yaml @@ -7,49 +7,38 @@ doc: | type: group NXhistory(NXobject): (NXactivity): + exists: ['min', '1'] doc: | - Any activity that was performed on the physical entity prior or during the experiment. In - the future, if there is base class inheritance, this can describe any activity, - including processes and measurements. - - # For now, one workaround would be to have NXactivity as a application definition with a subentry. - # subentry(NXsuxbentry): - # doc: | - # Any activity that was performed on the physical entity prior or during the experiment. - # definition: ["NXactivity"] - (NXphysical_process): - doc: | - Any physical process that was performed on the physical entity prior or during the - experiment. - (NXchemical_process): - doc: | - Any chemical process that was performed on the physical entity prior or during the + Any activity that was performed on the physical entity prior or during the experiment. - (NXidentifier): + \@identifierNAME: + nameType: partial doc: | An ID or reference to the location or a unique (globally persistent) identifier of e.g. another file which gives as many as possible details of the history event. - - # There should be more activities here, like measurement. - notes(NXnote): + (NXnote): + nameType: any doc: | A descriptor to keep track of the treatment of the physical entity before or during the experiment (NXnote allows to add pictures, audio, movies). Alternatively, a reference to the location or a unique identifier or other metadata file. In the case these are not available, free-text description. This should only be used in case that there is no rigorous description - using the base classes above. This field can also be used to pull in any activities + using the base classes above. This group can also be used to pull in any activities that are not well described by an existing base class definition. + + Any number of instances of NXnote are allowed for describing extra details of + this activity. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fa4467df160ff5018d01d51f9e8ba0b99a97e7401629333819545c96880e5572 +# ea9f59bd7d87a58540dc078c82ddbef88fd0636f33506f13bd76f860e5034c9d # # # -# -# -# Any physical process that was performed on the physical entity prior or during the -# experiment. -# -# -# -# -# Any chemical process that was performed on the physical entity prior or during the +# Any activity that was performed on the physical entity prior or during the # experiment. # # -# +# # # An ID or reference to the location or a unique (globally # persistent) identifier of e.g. another file which gives # as many as possible details of the history event. # -# -# -# +# +# # # A descriptor to keep track of the treatment of the physical entity before or during the # experiment (NXnote allows to add pictures, audio, movies). Alternatively, a # reference to the location or a unique identifier or other metadata file. In the # case these are not available, free-text description. # This should only be used in case that there is no rigorous description -# using the base classes above. This field can also be used to pull in any activities +# using the base classes above. This group can also be used to pull in any activities # that are not well described by an existing base class definition. +# +# Any number of instances of NXnote are allowed for describing extra details of +# this activity. # # # diff --git a/base_classes/nyaml/NXinsertion_device.yaml b/base_classes/nyaml/NXinsertion_device.yaml index a766eea7f8..9403ab5ee4 100644 --- a/base_classes/nyaml/NXinsertion_device.yaml +++ b/base_classes/nyaml/NXinsertion_device.yaml @@ -2,7 +2,7 @@ category: base doc: | An insertion device, as used in a synchrotron light source. type: group -NXinsertion_device(NXobject): +NXinsertion_device(NXcomponent): type: enumeration: [undulator, wiggler] gap(NX_FLOAT): @@ -47,7 +47,7 @@ NXinsertion_device(NXobject): unit: NX_UNITLESS doc: | harmonic number of peak - (NXdata)spectrum: + spectrum(NXdata): doc: | spectrum of insertion device (NXgeometry): @@ -59,43 +59,19 @@ NXinsertion_device(NXobject): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - \@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 insertion device. - (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 ++++++++++++++++++++++++++++++++++ -# 66cc252b3f21c2e74504d10b2f495979e96ee7818751b8cfca5265c900729b97 +# 4795840e6602e35f9ef20e2a14396e8221693f3ebebe407da06ae56ae27fa25c # # # -# -# -# 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 -# -# -# +# +# +# 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 +# +# # -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# -# -# -# +# +# +# +# # -# -# -# -# -# -# +# +# +# +# +# +# # -# -# -# -# -# -# -# -# .. 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/NXlog.yaml b/base_classes/nyaml/NXlog.yaml index d83f7423cb..cf29180c87 100644 --- a/base_classes/nyaml/NXlog.yaml +++ b/base_classes/nyaml/NXlog.yaml @@ -18,8 +18,8 @@ doc: | can be used to accomodate non standard clocks. - This method of storing logged data helps to distinguish - instances in which a variable is a dimension scale of the data, in which case it is stored + This method of storing logged data helps to distinguish instances in which a variable contains signal or + axis coordinate values of plottable data, in which case it is stored in an :ref:`NXdata` group, and instances in which it is logged during the run, when it should be stored in an :ref:`NXlog` group. @@ -94,26 +94,15 @@ NXlog(NXobject): doc: | Index into the time, value pair matching the corresponding cue_timestamp_zero. - \@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 ++++++++++++++++++++++++++++++++++ -# 9b63a3c7893197663b594741b4e3abc7e23d5c74b083332ea8e03ec65dca59d8 +# 1f21564c252376ec9f6358da62aab20eb4844b74ea583c799253a09225e41efd # # # -# +# # -# A wavelength defining device. -# -# This is a base class for everything which -# selects a wavelength or energy, be it a -# monochromator crystal, a velocity selector, -# an undulator or whatever. -# -# The expected units are: -# -# * wavelength: angstrom -# * energy: eV +# A wavelength defining device. +# +# This is a base class for everything which +# selects a wavelength or energy, be it a +# monochromator crystal, a velocity selector, +# an undulator or whatever. +# +# The expected units are: +# +# * wavelength: angstrom +# * energy: eV +# # # -# -# wavelength selected -# -# -# -# -# wavelength standard deviation -# +# wavelength selected +# +# +# wavelength standard deviation # # -# -# wavelength standard deviation -# +# wavelength standard deviation # # -# -# energy selected -# -# -# -# -# energy standard deviation -# -# +# energy selected +# +# +# energy standard deviation +# # -# -# energy standard deviation -# +# energy standard deviation # -# +# # -# Energy dispersion at the exit slit, typically given as eV/mm. +# Energy dispersion at the exit slit. # # -# +# # # Wavelength dispersion at the exit slit. # @@ -188,56 +159,20 @@ NXmonochromator(NXobject): # Size, position and shape of the exit slit of the monochromator. # # -# +# # # -# -# This group describes the shape of the beam line component +# +# This group describes the shape of the beam line component # # -# -# -# Use as many crystals as necessary to describe -# -# -# -# -# -# For diffraction grating based monochromators -# -# -# -# -# .. 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. -# -# +# Use as many crystals as necessary to describe +# +# For diffraction grating based monochromators # # -# 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 monochromator. +# .. todo:: +# Add a definition for the reference point of a monochromator. # # -# -# -# 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/NXnote.yaml b/base_classes/nyaml/NXnote.yaml index 229f0c82b0..2c6680e018 100644 --- a/base_classes/nyaml/NXnote.yaml +++ b/base_classes/nyaml/NXnote.yaml @@ -18,6 +18,21 @@ NXnote(NXobject): file_name: doc: | Name of original file name if note was read from an external source + identifierNAME(NX_CHAR): + nameType: partial + doc: | + Identifier of the resource if that resource that has been serialized. + + For example, the identifier to a resource in another database. + checksum(NX_CHAR): + doc: | + Value of the hash that is obtained when running algorithm + on the content of the resource referred to by ``identifierNAME``. + algorithm(NX_CHAR): + doc: | + Name of the algorithm whereby the ``checksum`` was computed. + + Examples: md5, sha256 description: doc: | Title of an image or other details of the note @@ -28,26 +43,15 @@ NXnote(NXobject): data(NX_BINARY): doc: | Binary note data - if text, line terminator is [CR][LF]. - \@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 ++++++++++++++++++++++++++++++++++ -# cac46891aabdb595f69910c7ddb6a496bd16f4e98055ddc5570ef01fbeed1e73 +# 4562afd6ad243a15e49b8dd6f7898735862d8288df9da8ddea9baa53a84c7cb3 # # # -# +# +# +# +# +# +# +# +# NXlog group containing logged values of GROUPNAME. +# +# +# +# +# Target values of FIELDNAME. +# +# +# +# +# Uncertainties of FIELDNAME values. +# +# +# +# +# Weights of FIELDNAME values. +# +# +# +# +# Boolean mask of FIELDNAME values. The value is masked if set to 1. +# +# +# +# +# An identifier for a (persistent) resource. +# +# An identifier, provided by some authority, that has been assigned to an +# object described by this ``NXobject``. To be useful, the identifier +# must not be reassigned to a different real-world object. It is typical for +# there to be some mechanism to resolve an identifier, obtaining metadata +# about the object. Identifiers for which some guarantees exist regarding +# this resolution process are called persistent identifiers. +# Persistent identifiers are also known as PIDs. +# +# +# +# The type of identifier used. # +# It is recommended to use the most specific type when describing the identifier. +# +# For example, all IGSNs (see below) are DOIs and all DOIs are Handles; however, an IGSN should have type IGSN (and not DOI or Hdl). +# Similarly, an ARK, Purl, ORCID and ROR identifiers should have their corresponding types and should not use the more generic URL identifier. +# +# +# +# +# Archival Resource Key. +# +# An ARK is a Uniform Resource Identifier (URI) designed to support long-term access to a variety of information objects. +# +# Syntax: https://NMA/ark:/NAAN/Name[Qualifier]. Brackets indicate optional elements. +# Example: https://example.org/ark:/12345/abcde +# +# +# +# +# Digital Object Identifier. +# +# A DOI is a unique alphanumeric string used to identify digital content. It consists of a prefix and a suffix, separated by a slash. +# +# Syntax: 10.XXXX/XXXXXX +# Example: 10.1107/S1600576714027575 +# +# +# +# +# A handle is a unique identifier that consists of a prefix indicating the naming authority and a suffix representing the local name +# of a resource. +# +# A handle is a unique identifier used to facilitate the identification and management of digital objects. It is composed of a prefix that +# indicates the naming authority and a suffix that specifies the resource's local name. +# +# This refers specifically to an ID in the Handle system operated by the Corporation for National Research Initiatives (CNRI). +# +# Syntax: prefix/identifier +# Example: 123456789/abc123 +# +# +# +# +# International Generic Sample Number. +# +# The IGSN is a unique identifier assigned to a specific sample or specimen in the context of scientific research. +# +# Since 2021, IGSNs are issued by DataCite, meaning that there are now DataCite-issued DOIs for all IGSNs, +# including those historical IGSNs issued beforehand. Therefore, the syntax is the same as for DOIs. +# +# Syntax: 10.XXXX/XXXXXX +# Example: 10.1107/S1600576714027575 +# +# +# +# +# ISNI is an ISO standard to uniquely identify individuals and organizations involved in creative work, including pseudonyms +# and other public personas. +# +# An ISNI-ID is made up of 16 digits, the last character being a check character. The check character may be either a decimal digit +# or the character “X”. +# +# A URL can be generated from the ISNI ID by combining it with the prefix https://isni.org/isni/, resulting in +# https://isni.org/isni/{ISNI-ID}. +# +# Syntax: 16 base-10 digits stored without any spaces. +# Example: 0000000121032683 +# +# +# +# +# International Standard Serial Number +# +# An ISSN is an 8-digit unique identifier used to distinguish a serial publication, whether in print or electronic form. +# The last character (a digit or 'X') serves as a check character, making the ISSN uniquely defined by its first seven digits. +# +# Syntax: NNNN-NNNC, where N a decimal digit character (i.e., in the set {0,1,2,...,9}), and C is in {0,1,2,...,9,X} +# Example: 1234-5678 or 1234-567X +# +# +# +# +# Linking ISSN +# +# The linking ISSN, or ISSN-L, is a specific ISSN that groups the different media of the same serial publication. +# +# Syntax: NNNN-NNNC, where N a decimal digit character (i.e., in the set {0,1,2,...,9}), and C is in {0,1,2,...,9,X} +# Example: 1234-5678 or 1234-567X +# +# +# +# +# Open Researcher and Contributor identifier. +# +# ORCID provides a free and persistent identifier that uniquely distinguishes authors and contributors in scientific research. +# +# Syntax: https://orcid.org/XXXX-XXXX-XXXX-XXXX +# Example: https://orcid.org/0000-0002-1825-0097 +# +# +# +# +# Persistent Uniform Resource Locator. +# +# A Persistent Uniform Resource Locator (PURL) is a type of URL designed to provide a stable, long-term reference to a web +# resource by using a resolver to redirect users to the resource's current location, even if it moves over time. +# +# A PURL has three parts: (1) a protocol, (2) a resolver address, and (3) a name. +# +# Syntax: https://purl.org/foo/bar +# Example: https://purl.org/dc/elements/1.1/title +# +# +# +# +# Research Organization Registry +# +# A ROR ID is a globally unique identifier for research organizations, enabling unambiguous linking of institutions across systems. +# +# Syntax: https://ror.org/{ROR-ID} +# Example: https://ror.org/052gg0110 +# +# +# +# +# Uniform Resource Locator +# +# Also known as web address, a URL is the address used to access a resource on the internet, +# specifying its location and the protocol to retrieve it. +# +# Syntax: scheme://domain:port/path?query_string#fragment_id +# Example: https://www.example.com/about +# +# +# +# +# Uniform Resource Name +# +# A URN is a unique, persistent identifier for a resource regardless of where it is stored. +# +# It is recommended that identifiers with more specific type attribute (such as DOI or ISSN) values should not be stored as a URN, +# even when this is valid. As an example, the URN doi:10.1107/S1600576714027575 is a valid URN-based representation for the DOI +# 10.1107/S1600576714027575, but it is recommended to use type="DOI" in this case. +# +# Syntax: urn:<namespace>:<namespace-specific-string>. The leading urn: sequence is case-insensitive. +# Example: urn:isbn:0000000000000 +# +# +# +# +# +# +# +# .. index:: plotting +# +# Declares which child group contains a path leading +# to a :ref:`NXdata` group or a group using a base class +# extending :ref:`NXdata`. +# +# 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/NXoff_geometry.yaml b/base_classes/nyaml/NXoff_geometry.yaml index 1991dfe111..0e917f7828 100644 --- a/base_classes/nyaml/NXoff_geometry.yaml +++ b/base_classes/nyaml/NXoff_geometry.yaml @@ -3,7 +3,7 @@ doc: | Geometry (shape) description. The format closely matches the Object File Format (OFF) which can be output by most CAD software. - It can be used to describe the shape of any beamline component, including detectors. + It can be used to describe the shape of any component, including detectors. In the case of detectors it can be used to define the shape of a single pixel, or, if the pixel shapes are non-uniform, to describe the shape of the whole detector. symbols: @@ -56,26 +56,15 @@ NXoff_geometry(NXobject): dimensions: rank: 2 dim: (l, 2) - \@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 ++++++++++++++++++++++++++++++++++ -# 5391b51bb2d18dca46cdea71f12ce8dc6a00884937e05fcbc2cdc4e76b0b7adb +# 81632fdb953035a7b1b1d221e316fa0d84b979a62debbb4bac0e1bedfa6210db # # # # A parameter (also known as a term) that is used in or results from processing. # # -# -# -# .. 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/NXpdb.yaml b/base_classes/nyaml/NXpdb.yaml index 24cfd73920..348bc9e63c 100644 --- a/base_classes/nyaml/NXpdb.yaml +++ b/base_classes/nyaml/NXpdb.yaml @@ -149,7 +149,7 @@ NXpdb(NXobject): # -# +# # -# A generic positioner such as a motor or piezo-electric transducer. +# A generic positioner such as a motor or piezo-electric transducer. # # -# -# symbolic or mnemonic name (one word) -# +# symbolic or mnemonic name (one word) # # -# -# description of positioner -# +# description of positioner # # -# -# best known value of positioner - need [n] as may be scanned -# -# -# -# +# best known value of positioner - need [n] as may be scanned +# # # -# -# raw value of positioner - need [n] as may be scanned -# -# -# -# +# raw value of positioner - need [n] as may be scanned +# # # -# -# targeted (commanded) value of positioner - need [n] as may be scanned -# -# -# -# +# targeted (commanded) value of positioner - need [n] as may be scanned +# # # -# -# maximum allowable difference between target_value and value -# -# -# -# +# maximum allowable difference between target_value and value +# # # -# -# minimum allowed limit to set value -# +# minimum allowed limit to set value # # -# -# maximum allowed limit to set value -# +# maximum allowed limit to set value # # -# -# velocity of the positioner (distance moved per unit time) -# +# velocity of the positioner (distance moved per unit time) # # -# -# time to ramp the velocity up to full speed -# +# time to ramp the velocity up to full speed # -# +# # -# -# Hardware device record, e.g. EPICS process variable, taco/tango. -# +# Hardware device record, e.g. EPICS process variable, taco/tango ... # # # -# 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 positioner. +# .. todo:: +# Add a definition for the reference point of a positioner. # # -# -# -# 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. -# -# # # -# The actuator of the positioner which is responsible for the movement of the -# probe. +# The actuator of the positioner which is responsible for the movement of the +# probe. # -# +# # -# The feedback of the actual position of the positioner. +# The feedback of the actual position of the positioner. # # # -# If present, the value and the value_log of this pv_sensor is the same as -# the value and raw_value of the position itself. +# If present, the value and the value_log of this pv_sensor is the same as +# the value and raw_value of the position itself. # # # diff --git a/base_classes/nyaml/NXprocess.yaml b/base_classes/nyaml/NXprocess.yaml index 3dbc4ee78a..08c1bb8972 100644 --- a/base_classes/nyaml/NXprocess.yaml +++ b/base_classes/nyaml/NXprocess.yaml @@ -17,15 +17,6 @@ NXprocess(NXobject): date(NX_DATE_TIME): doc: | Date and time of processing. - (NXregistration): - doc: | - Describes the operations of image registration - (NXdistortion): - doc: | - Describes the operations of image distortion correction - (NXcalibration): - doc: | - Describes the operations of calibration procedures, e.g. axis calibrations. (NXnote): doc: | The note will contain information about how the data was processed @@ -34,26 +25,15 @@ NXprocess(NXobject): can understand, or simple text. The name will be numbered to allow for ordering of steps. - \@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 ++++++++++++++++++++++++++++++++++ -# efb5f4cc611c1eb8c9de82497bd906c59a237a2ba2cc2bccaa74209af288d5ff +# 6c22762a03d66eb4d983bfd65020e29612873eb4310fd9ce15a7baf5e70887a0 # -# +# # -# -# -# Document an event of data processing, reconstruction, or analysis for this data. -# +# +# Document an event of data processing, reconstruction, or analysis for this data. # -# -# Name of the program used -# +# Name of the program used # # # -# Sequence index of processing, -# for determining the order of multiple **NXprocess** steps. -# Starts with 1. +# Sequence index of processing, +# for determining the order of multiple **NXprocess** steps. +# Starts with 1. # # # -# -# Version of the program used -# +# Version of the program used # # -# -# Date and time of processing. -# +# Date and time of processing. # -# -# -# Describes the operations of image registration -# -# -# -# -# Describes the operations of image distortion correction -# -# -# -# -# Describes the operations of calibration procedures, e.g. axis calibrations. -# -# # # -# The note will contain information about how the data was processed -# or anything about the data provenance. -# The contents of the note can be anything that the processing code -# can understand, or simple text. -# -# The name will be numbered to allow for ordering of steps. +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or simple text. +# +# The name will be numbered to allow for ordering of steps. # # -# -# -# .. 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/NXreflections.yaml b/base_classes/nyaml/NXreflections.yaml index cf0d0fbfa9..199c247f71 100644 --- a/base_classes/nyaml/NXreflections.yaml +++ b/base_classes/nyaml/NXreflections.yaml @@ -591,20 +591,9 @@ NXreflections(NXobject): \@description: doc: | Describes the dataset - \@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 ++++++++++++++++++++++++++++++++++ -# 668d29ae4cf835fc3cbc4e104dcf63203c4827eaadbd5b21bdccb7f8ea636edf +# 91e623ec5a3bf9a35319924e014385a12400af7a65e7d92266c658486fd3f31d # # # -# +# # # Describes image registration procedures. # @@ -55,11 +52,6 @@ NXregistration(NXobject): # Has the registration been applied? # # -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# # # # Specifies the position by pointing to the last transformation in the diff --git a/base_classes/nyaml/NXresolution.yaml b/base_classes/nyaml/NXresolution.yaml new file mode 100644 index 0000000000..bdad2a9185 --- /dev/null +++ b/base_classes/nyaml/NXresolution.yaml @@ -0,0 +1,161 @@ +category: base +doc: | + Describes the resolution of a physical quantity. +type: group +NXresolution(NXobject): + physical_quantity: + doc: | + The physical quantity of the resolution, e.g., + energy, momentum, time, area, etc. + type: + doc: | + The process by which the resolution was determined. + enumeration: [estimated, derived, calibrated, other] + note(NXnote): + doc: | + Additional details of the estimate or description of the calibration procedure + resolution(NX_FLOAT): + unit: NX_ANY + doc: | + The resolution of the physical quantity. + resolution_errors(NX_FLOAT): + unit: NX_ANY + doc: | + Standard deviation of the resolution of the physical quantity. + relative_resolution(NX_FLOAT): + unit: NX_ANY + doc: | + Ratio of the resolution at a specified measurand value to that measurand value. + relative_resolution_errors(NX_FLOAT): + unit: NX_DIMENSIONLESS + doc: | + Standard deviation of the relative resolution of the physical quantity. + response_function(NXdata): + doc: | + The response of the instrument or part of the instrument to a infinitesimally sharp input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the full width at half maximum (FWHM) + of the response function. + + This could have an AXISNAME field ```input``` (the input axis or grid of the response function) + and a ``DATA`` field ```magnitude```. Both of these should have the same unit. The dimensions + should match those of the :ref:`resolution ` field. + formula_symbols(NXparameters): + doc: | + Symbols linking to another path in the NeXus tree to be referred to from the + `resolution_formula_description` field. The ``TERM`` should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field. + resolution_formula_description(NX_CHAR): + doc: | + A description of the resolution formula to determine the resolution from a set of symbols as + entered by the `formula_...` fields. This should be an english description of the math used. + (NXcalibration): + doc: | + For storing details and data of a calibration to derive a resolution from data. + +# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ +# a8a53adb80c6122d2d1de91a1637430ec6543e9c45319c8edbe931573655e233 +# +# +# +# +# +# Describes the resolution of a physical quantity. +# +# +# +# The physical quantity of the resolution, e.g., +# energy, momentum, time, area, etc. +# +# +# +# +# The process by which the resolution was determined. +# +# +# +# +# +# +# +# +# +# +# Additional details of the estimate or description of the calibration procedure +# +# +# +# +# The resolution of the physical quantity. +# +# +# +# +# Standard deviation of the resolution of the physical quantity. +# +# +# +# +# Ratio of the resolution at a specified measurand value to that measurand value. +# +# +# +# +# Standard deviation of the relative resolution of the physical quantity. +# +# +# +# +# The response of the instrument or part of the instrument to a infinitesimally sharp input signal +# along the physical quantity of this group. +# This is also sometimes called instrument response function for time resolution or +# point spread function for spatial response. +# The resolution is typically determined by taking the full width at half maximum (FWHM) +# of the response function. +# +# This could have an AXISNAME field ```input``` (the input axis or grid of the response function) +# and a ``DATA`` field ```magnitude```. Both of these should have the same unit. The dimensions +# should match those of the :ref:`resolution </NXresolution/resolution-field>` field. +# +# +# +# +# Symbols linking to another path in the NeXus tree to be referred to from the +# `resolution_formula_description` field. The ``TERM`` should be a valid path inside this application +# definition, i.e., of the form /entry/instrument/my_part/my_field. +# +# +# +# +# A description of the resolution formula to determine the resolution from a set of symbols as +# entered by the `formula_...` fields. This should be an english description of the math used. +# +# +# +# +# For storing details and data of a calibration to derive a resolution from data. +# +# +# diff --git a/base_classes/nyaml/NXroot.yaml b/base_classes/nyaml/NXroot.yaml index 9a722150b9..b53f70bcb6 100644 --- a/base_classes/nyaml/NXroot.yaml +++ b/base_classes/nyaml/NXroot.yaml @@ -18,33 +18,32 @@ NXroot(NXobject): \@file_update_time(NX_DATE_TIME): doc: | Date and time of last file change at close + \@NeXus_version: + deprecated: NAPI is frozen. + doc: | + Version of NeXus API used in writing the file. + + Note that this is different from the version of the + base class or application definition version number. \@NeXus_repository: doc: | A repository containing the application definitions used for creating this file. - If the NeXus_version attribute contains a commit distance and hash + If the ``NeXus_release`` attribute contains a commit distance and hash, this should refer to this repository. - \@NeXus_version: + \@NeXus_release: doc: | - Version of NeXus definitions used in writing the file. - This may either be a date based version tag of the form `vYYYY.MM` - or a version tag with a commit distance and source control (e.g., git) hash of - the form `vYYYY.MM.post1.dev.g`. - It may contain an additional `.dYYYYMMDD` timestamp appendix - for dirty repositories. - If the version contains a commit distance and hash the - NeXus_repository attribute should be written with the - repository url containing this version. + The version of NeXus definitions used in writing the file. This can either be a date-based + NeXus release (e.g., YYYY.MM), see https://github.com/nexusformat/definitions/releases or + a version tag that includes additional development information, such as a commit distance and + a Git hash. This is typically formatted as `vYYYY.MM.post1.dev-g`, + where `YYYY.MM` refers to the base version of the NeXus definitions. `post1.dev` + indicates that the definitions are based on a commit after the base version (post1), with + `` being the number of commits since that version. `g` is the + abbreviated Git hash that identifies the specific commit of the definitions being used. - Only used when the NAPI or pynxtools has written the file. - Note that this is different from the version of the - base class or application definition version number. - \@partial: - doc: | - A list of concepts in an application definition this file describes. - This is for partially filling an application definition. - If this attribute is not present the application definition is assumed - to be valid, if not only the specified concepts/paths are assumed to be valid. + If the version includes both a commit distance and a Git hash, the ``NeXus_repository`` + attribute must be included, specifying the URL of the repository containing that version. \@HDF_version: doc: | Version of HDF (version 4) library used in writing the file @@ -60,6 +59,12 @@ NXroot(NXobject): \@h5py_version: doc: | Version of h5py Python package used in writing the file + \@partial: + doc: | + A list of concepts in an application definition this file describes. + This is for partially filling an application definition. + If this attribute is not present the application definition is assumed + to be valid, if not only the specified concepts/paths are assumed to be valid. \@creator: doc: | facility or program where file originated @@ -90,13 +95,13 @@ NXroot(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6ea5a6c52ba9ecaf5567ae29e03f82ba5c7fdd42e80afb48fa4a8942c38fa2dd -# -# +# 3e6dc214616996ee7a7349986fb6c35d848e7eda391428945efeef4017941ea2 +# +# # -# -# -# Definition of the root NeXus group. -# +# +# Definition of the root NeXus group. # # -# The root of any NeXus data file is an ``NXroot`` class -# (no other choice is allowed for a valid NeXus data file). -# This attribute cements that definition. +# The root of any NeXus data file is an ``NXroot`` class +# (no other choice is allowed for a valid NeXus data file). +# This attribute cements that definition. # # -# +# # # # -# -# Date and time file was originally created -# +# Date and time file was originally created # # -# -# File name of original NeXus file -# +# File name of original NeXus file # # -# -# Date and time of last file change at close -# +# Date and time of last file change at close # -# +# # -# A repository containing the application definitions -# used for creating this file. -# If the NeXus_version attribute contains a commit distance and hash -# this should refer to this repository. +# Version of NeXus API used in writing the file. +# +# Note that this is different from the version of the +# base class or application definition version number. # # -# +# # -# Version of NeXus definitions used in writing the file. -# This may either be a date based version tag of the form `vYYYY.MM` -# or a version tag with a commit distance and source control (e.g., git) hash of -# the form `vYYYY.MM.post1.dev<commit-distance>.g<git-hash>`. -# It may contain an additional `.dYYYYMMDD` timestamp appendix -# for dirty repositories. -# If the version contains a commit distance and hash the -# NeXus_repository attribute should be written with the -# repository url containing this version. -# -# Only used when the NAPI or pynxtools has written the file. -# Note that this is different from the version of the -# base class or application definition version number. +# A repository containing the application definitions +# used for creating this file. +# If the ``NeXus_release`` attribute contains a commit distance and hash, +# this should refer to this repository. # # -# +# # -# A list of concepts in an application definition this file describes. -# This is for partially filling an application definition. -# If this attribute is not present the application definition is assumed -# to be valid, if not only the specified concepts/paths are assumed to be valid. +# The version of NeXus definitions used in writing the file. This can either be a date-based +# NeXus release (e.g., YYYY.MM), see https://github.com/nexusformat/definitions/releases or +# a version tag that includes additional development information, such as a commit distance and +# a Git hash. This is typically formatted as `vYYYY.MM.post1.dev<commit-distance>-g<git-hash>`, +# where `YYYY.MM` refers to the base version of the NeXus definitions. `post1.dev<commit-distance>` +# indicates that the definitions are based on a commit after the base version (post1), with +# `<commit-distance>` being the number of commits since that version. `g<git-hash>` is the +# abbreviated Git hash that identifies the specific commit of the definitions being used. +# +# If the version includes both a commit distance and a Git hash, the ``NeXus_repository`` +# attribute must be included, specifying the URL of the repository containing that version. # # # -# -# Version of HDF (version 4) library used in writing the file -# +# Version of HDF (version 4) library used in writing the file # # # -# Version of HDF5 library used in writing the file. -# -# Note this attribute is spelled with uppercase "V", -# different than other version attributes. +# Version of HDF5 library used in writing the file. +# +# Note this attribute is spelled with uppercase "V", +# different than other version attributes. # # # -# -# Version of XML support library used in writing the XML file -# +# Version of XML support library used in writing the XML file # # +# Version of h5py Python package used in writing the file +# +# # -# Version of h5py Python package used in writing the file +# A list of concepts in an application definition this file describes. +# This is for partially filling an application definition. +# If this attribute is not present the application definition is assumed +# to be valid, if not only the specified concepts/paths are assumed to be valid. # # # -# -# facility or program where file originated -# +# facility or program where file originated # # -# -# Version of facility or program used in writing the file -# +# Version of facility or program used in writing the file # -# -# -# entries -# +# +# entries # # # -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXentry` group contains -# the data to be shown by default. -# It is used to resolve ambiguity when -# more than one :ref:`NXentry` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus 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:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXentry` group contains +# the data to be shown by default. +# It is used to resolve ambiguity when +# more than one :ref:`NXentry` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus 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. # # -# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXsample.yaml b/base_classes/nyaml/NXsample.yaml index f80d828603..8a8914175d 100644 --- a/base_classes/nyaml/NXsample.yaml +++ b/base_classes/nyaml/NXsample.yaml @@ -21,13 +21,10 @@ symbols: n_sField: | number of values in applied stress field type: group -NXsample(NXobject): +NXsample(NXcomponent): name: doc: | Descriptive name of sample - sample_id: - doc: | - Identification number or signatures of the sample used. chemical_formula: doc: | The chemical formula specified using CIF conventions. @@ -182,8 +179,7 @@ NXsample(NXobject): The position and orientation of the center of mass of the sample (NXbeam): doc: | - Details of beam incident on sample - used to calculate sample/beam interaction - point + Details of beam incident on sample - used to calculate sample/beam interaction point (NXsample_component): doc: | One group per sample component @@ -267,8 +263,7 @@ NXsample(NXobject): deprecated: | use ``magnetic_field``, see: https://github.com/nexusformat/definitions/issues/816 doc: | - magnetic_field_log.value is a link to e.g. - magnetic_field_env.sensor1.value_log.value + magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value magnetic_field_env(NXenvironment): doc: | Additional sample magnetic environment information @@ -282,8 +277,8 @@ NXsample(NXobject): short_title: doc: | 20 character fixed length sample description for legends - - # How is the string length limitation imposed by the XSD? + + # How is the string length limitation imposed by the XSD? rotation_angle(NX_FLOAT): unit: NX_ANGLE doc: | @@ -305,39 +300,16 @@ NXsample(NXobject): doc: | Any positioner (motor, PZT, ...) used to locate the sample (NXoff_geometry): - - # exists: ['min', '0'] + exists: ['min', '0'] doc: | This group describes the shape of the sample physical_form: + + # REVISIT: should this be an open enumeration? doc: | Physical form of the sample material. Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. - (NXsingle_crystal): - doc: | - If the sample is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sample components and their configuration. - There can only be one NXsample_component_set in one component. - - # exists: [max, 1] - (NXsubstance): - doc: | - If the sample is made from a pure substance and cannot be further divided using - NXsample_component. - - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample vendor (company or research group) - identifier(NXidentifier): - doc: | - An (ideally) globally unique identifier for the sample. (NXenvironment): - - # eventually, this should be stored in the application definitions doc: | Any environmental or external stimuli/measurements. These can include, among others: @@ -346,41 +318,16 @@ NXsample(NXobject): history(NXhistory): doc: | A set of physical processes that occurred to the sample prior/during experiment. - \@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: - 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. - (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 ++++++++++++++++++++++++++++++++++ -# e854e59b1f73a57d815ba55c7dfbda5e05ba16e04c70870587aef9f89c7261ab -# -# +# d964c0b31851de1cc9663c69e60eaf247e837674256628cbbe6f09d7684c2994 +# +# # -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of compositions -# -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# Any information on the sample. -# -# This could include scanned variables that -# are associated with one of the data dimensions, e.g. the magnetic field, or -# logged data, e.g. monitored temperature vs elapsed time. -# -# -# -# Descriptive name of sample -# -# -# -# -# Identification number or signatures of the sample used. -# -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * Only recognized element symbols may be used. -# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. -# * A space or parenthesis must separate each cluster of (element symbol + count). -# * Where a group of elements is enclosed in parentheses, the multiplier for the -# group must follow the closing parentheses. That is, all element and group -# multipliers are assumed to be printed as subscripted numbers. -# * Unless the elements are ordered in a manner that corresponds to their chemical -# structure, the order of the elements within any group or moiety depends on -# whether or not carbon is present. -# * If carbon is present, the order should be: -# -# - C, then H, then the other elements in alphabetical order of their symbol. -# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# -# Sample temperature. This could be a scanned variable -# -# -# -# -# -# -# -# -# Applied electric field -# -# -# -# -# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of compositions +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# Any information on the sample. +# +# This could include scanned variables that +# are associated with one of the data dimensions, e.g. the magnetic field, or +# logged data, e.g. monitored temperature vs elapsed time. +# +# +# Descriptive name of sample +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * Only recognized element symbols may be used. +# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. +# * A space or parenthesis must separate each cluster of (element symbol + count). +# * Where a group of elements is enclosed in parentheses, the multiplier for the +# group must follow the closing parentheses. That is, all element and group +# multipliers are assumed to be printed as subscripted numbers. +# * Unless the elements are ordered in a manner that corresponds to their chemical +# structure, the order of the elements within any group or moiety depends on +# whether or not carbon is present. +# * If carbon is present, the order should be: +# +# - C, then H, then the other elements in alphabetical order of their symbol. +# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# Applied electric field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied magnetic field -# -# -# -# -# +# +# +# Applied magnetic field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied external stress field -# -# -# -# -# +# +# +# Applied external stress field +# +# +# # -# -# -# -# -# +# +# +# +# +# # -# -# -# -# Applied pressure -# -# -# -# -# -# -# -# -# Sample changer position -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Unit cell parameters (lengths and angles) -# -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# -# -# -# This will follow the Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 -# -# -# -# -# -# -# -# -# -# UB matrix of single crystal sample using Busing-Levy convention: -# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is -# the multiplication of the orientation_matrix, given above, -# with the :math:`B` matrix which -# can be derived from the lattice constants. -# -# -# -# -# -# -# -# -# -# Mass of sample -# -# -# -# -# -# -# -# Density of sample -# -# -# +# +# +# Applied pressure +# +# +# +# +# +# Sample changer position +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Unit cell parameters (lengths and angles) +# +# +# +# +# +# +# Volume of the unit cell +# +# +# +# +# +# +# This will follow the Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# Orientation matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 +# +# +# +# +# +# +# +# +# +# UB matrix of single crystal sample using Busing-Levy convention: +# W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is +# the multiplication of the orientation_matrix, given above, +# with the :math:`B` matrix which +# can be derived from the lattice constants. +# +# +# +# +# +# +# +# +# Mass of sample +# +# +# +# +# +# Density of sample +# +# +# +# +# +# Relative Molecular Mass of sample +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# The atmosphere will be one of the components, which is where +# its details will be stored; the relevant components will be +# indicated by the entry in the sample_component member. +# +# +# +# +# +# +# +# +# +# +# +# +# +# Description of the sample +# +# +# +# Date of preparation of the sample +# +# +# The position and orientation of the center of mass of the sample +# +# +# Details of beam incident on sample - used to calculate sample/beam interaction point +# +# +# +# One group per sample component +# This is the perferred way of recording per component information over the n_comp arrays +# +# +# +# Details of the component of the sample and/or can +# +# +# +# +# +# Type of component +# +# +# +# +# +# +# +# +# +# +# +# Concentration of each component +# +# +# +# +# +# Volume fraction of each component +# +# +# +# +# +# Scattering length density of each component +# +# +# +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# +# +# +# Crystallographic point group, deprecated if space_group present +# +# # -# -# -# -# Relative Molecular Mass of sample -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# The atmosphere will be one of the components, which is where -# its details will be stored; the relevant components will be -# indicated by the entry in the sample_component member. -# -# -# -# -# -# -# -# -# -# -# -# -# -# Description of the sample -# -# -# -# -# Date of preparation of the sample -# -# -# -# -# The position and orientation of the center of mass of the sample -# -# -# -# -# Details of beam incident on sample - used to calculate sample/beam interaction -# point -# -# -# -# -# One group per sample component -# This is the perferred way of recording per component information over the n_comp arrays -# -# -# -# -# Details of the component of the sample and/or can -# -# -# -# -# -# -# -# Type of component -# -# -# -# -# -# -# -# -# -# -# -# -# -# Concentration of each component -# -# -# -# -# -# -# -# Volume fraction of each component -# -# -# -# -# -# -# -# Scattering length density of each component -# -# -# -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# -# -# -# Path length through sample/can for simple case when -# it does not vary with scattering direction -# -# -# -# -# Thickness of a beam entry/exit window on the can (mm) -# - assumed same for entry and exit -# -# -# -# -# sample thickness -# -# -# -# -# As a function of Wavelength -# -# -# -# -# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value -# -# -# -# -# Additional sample temperature environment information -# -# -# -# -# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value -# -# -# -# -# magnetic_field_log.value is a link to e.g. -# magnetic_field_env.sensor1.value_log.value -# -# -# -# -# Additional sample magnetic environment information -# -# -# -# -# value sent to user's sample setup -# -# -# -# -# logged value (or logic state) read from user's setup -# -# -# -# -# 20 character fixed length sample description for legends -# -# -# -# -# -# Optional rotation angle for the case when the powder diagram has -# been obtained through an omega-2theta scan like from a traditional -# single detector powder diffractometer. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the X-direction of the laboratory coordinate system -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Translation of the sample along the Z-direction of the laboratory coordinate system. -# Note, it is recommended to use NXtransformations instead. -# -# -# -# -# Any positioner (motor, PZT, ...) used to locate the sample -# -# -# -# -# -# This group describes the shape of the sample -# -# -# -# -# Physical form of the sample material. -# Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. -# -# -# -# -# If the sample is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sample components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the sample is made from a pure substance and cannot be further divided using -# NXsample_component. -# -# -# -# -# -# Details about the sample vendor (company or research group) -# -# -# -# -# An (ideally) globally unique identifier for the sample. -# -# -# -# -# -# Any environmental or external stimuli/measurements. -# These can include, among others: -# applied pressure, surrounding gas phase and gas pressure, -# external electric/magnetic/mechanical fields, temperature, ... -# -# -# -# -# A set of physical processes that occurred to the sample prior/during experiment. -# -# -# -# -# .. 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. -# -# -# -# -# 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. -# -# +# +# +# +# Path length through sample/can for simple case when +# it does not vary with scattering direction +# +# +# +# +# Thickness of a beam entry/exit window on the can (mm) +# - assumed same for entry and exit +# +# +# +# sample thickness +# +# +# As a function of Wavelength +# +# +# temperature_log.value is a link to e.g. temperature_env.sensor1.value_log.value +# +# +# Additional sample temperature environment information +# +# +# magnetic_field.value is a link to e.g. magnetic_field_env.sensor1.value +# +# +# magnetic_field_log.value is a link to e.g. magnetic_field_env.sensor1.value_log.value +# +# +# Additional sample magnetic environment information +# +# +# value sent to user's sample setup +# +# +# logged value (or logic state) read from user's setup +# +# +# 20 character fixed length sample description for legends +# +# +# +# +# Optional rotation angle for the case when the powder diagram has +# been obtained through an omega-2theta scan like from a traditional +# single detector powder diffractometer. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the X-direction of the laboratory coordinate system +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# Translation of the sample along the Z-direction of the laboratory coordinate system. +# Note, it is recommended to use NXtransformations instead. +# +# +# +# Any positioner (motor, PZT, ...) used to locate the sample +# +# +# +# This group describes the shape of the sample +# +# +# +# +# +# Physical form of the sample material. +# Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. +# +# +# +# +# Any environmental or external stimuli/measurements. +# These can include, among others: +# applied pressure, surrounding gas phase and gas pressure, +# external electric/magnetic/mechanical fields, temperature, ... +# +# +# +# +# A set of physical processes that occurred to the sample prior/during experiment. +# +# # diff --git a/base_classes/nyaml/NXsample_component.yaml b/base_classes/nyaml/NXsample_component.yaml index 285d268779..6982effa17 100644 --- a/base_classes/nyaml/NXsample_component.yaml +++ b/base_classes/nyaml/NXsample_component.yaml @@ -1,7 +1,6 @@ category: base doc: | - One group like this per component can be recorded For a sample consisting of - multiple components. + One group like this per component can be recorded for a sample consisting of multiple components. symbols: doc: | symbolic array lengths to be coordinated between various fields @@ -16,13 +15,10 @@ symbols: n_sField: | number of values in applied stress field type: group -NXsample_component(NXobject): +NXsample_component(NXcomponent): name: doc: | Descriptive name of sample component - sample_id: - doc: | - Identification number or signatures of the sample component used. chemical_formula: doc: | The chemical formula specified using CIF conventions. @@ -62,8 +58,7 @@ NXsample_component(NXobject): sample_orientation(NX_FLOAT): unit: NX_ANGLE doc: | - This will follow the Busing and Levy convention from Acta.Crysta v22, p457 - (1967) + This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) dimensions: rank: 1 dim: (3,) @@ -109,54 +104,20 @@ NXsample_component(NXobject): transmission(NXdata): doc: | As a function of Wavelength - (NXsingle_crystal): - doc: | - If the component is a single crystal, add description of single crystal and unit - cell. - (NXsample_component_set): - doc: | - Set of sub-components and their configuration. - There can only be one NXsample_component_set in one component. - - # exists: [max, 1] - (NXsubstance): - doc: | - If the component is made from a pure substance and cannot be further divided - using NXsample_component. - - # exists: [max, 1] - (NXfabrication): - doc: | - Details about the sample component vendor (company or research group) history(NXhistory): doc: | A set of physical processes that occurred to the sample component prior/during experiment. - depends_on: - doc: | - Any NXsample_component depends on the instance of NXsample_component_set, at the same level of - description granularity where the component is located. - \@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 ++++++++++++++++++++++++++++++++++ -# b960bd293312840707c515049b609dd3402071808dd0189a0cd4c54ae271721d -# -# +# 5a3f469257b602b4afb5c1c78c7599dcca5c826cca23d173439035e99857e8c0 +# +# # -# -# -# -# symbolic array lengths to be coordinated between various fields -# -# -# -# number of temperatures -# -# -# -# -# number of values in applied electric field -# -# -# -# -# number of values in applied magnetic field -# -# -# -# -# number of values in applied pressure field -# -# -# -# -# number of values in applied stress field -# -# -# -# -# One group like this per component can be recorded For a sample consisting of -# multiple components. -# -# -# -# Descriptive name of sample component -# -# -# -# -# Identification number or signatures of the sample component used. -# -# -# -# -# The chemical formula specified using CIF conventions. -# Abbreviated version of CIF standard: -# -# * Only recognized element symbols may be used. -# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. -# * A space or parenthesis must separate each cluster of (element symbol + count). -# * Where a group of elements is enclosed in parentheses, the multiplier for the -# group must follow the closing parentheses. That is, all element and group -# multipliers are assumed to be printed as subscripted numbers. -# * Unless the elements are ordered in a manner that corresponds to their chemical -# structure, the order of the elements within any group or moiety depends on -# whether or not carbon is present. -# * If carbon is present, the order should be: -# -# - C, then H, then the other elements in alphabetical order of their symbol. -# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. -# -# * This is the *Hill* system used by Chemical Abstracts. -# -# -# -# -# Crystallography unit cell parameters a, b, and c -# -# -# -# -# -# -# -# Crystallography unit cell parameters alpha, beta, and gamma -# -# -# -# -# -# -# -# Volume of the unit cell -# -# -# -# -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 -# (1967) -# -# -# -# -# -# -# -# Orientation matrix of single crystal sample component. -# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) -# -# -# -# -# -# -# -# -# Mass of sample component -# -# -# -# -# Density of sample component -# -# -# -# -# Relative Molecular Mass of sample component -# -# -# -# -# Description of the sample component -# -# -# -# -# Volume fraction of component -# -# -# -# -# Scattering length density of component -# -# -# -# -# In case it is all we know and we want to record/document it -# -# -# -# -# -# -# -# -# -# -# -# -# -# Crystallographic space group -# -# -# -# -# Crystallographic point group, deprecated if space_group present -# -# -# -# -# As a function of Wavelength -# -# -# -# -# If the component is a single crystal, add description of single crystal and unit -# cell. -# -# -# -# -# Set of sub-components and their configuration. -# There can only be one NXsample_component_set in one component. -# -# -# -# -# -# If the component is made from a pure substance and cannot be further divided -# using NXsample_component. -# -# -# -# -# -# Details about the sample component vendor (company or research group) -# -# +# +# +# +# symbolic array lengths to be coordinated between various fields +# number of temperatures +# number of values in applied electric field +# number of values in applied magnetic field +# number of values in applied pressure field +# number of values in applied stress field +# +# +# +# One group like this per component can be recorded for a sample consisting of multiple components. +# +# +# Descriptive name of sample component +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * Only recognized element symbols may be used. +# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. +# * A space or parenthesis must separate each cluster of (element symbol + count). +# * Where a group of elements is enclosed in parentheses, the multiplier for the +# group must follow the closing parentheses. That is, all element and group +# multipliers are assumed to be printed as subscripted numbers. +# * Unless the elements are ordered in a manner that corresponds to their chemical +# structure, the order of the elements within any group or moiety depends on +# whether or not carbon is present. +# * If carbon is present, the order should be: +# +# - C, then H, then the other elements in alphabetical order of their symbol. +# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Crystallography unit cell parameters a, b, and c +# +# +# +# +# +# Crystallography unit cell parameters alpha, beta, and gamma +# +# +# +# +# +# Volume of the unit cell +# +# +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# Orientation matrix of single crystal sample component. +# This will follow the Busing and Levy convention from Acta.Crysta v22, p457 (1967) +# +# +# +# +# +# +# +# Mass of sample component +# +# +# Density of sample component +# +# +# Relative Molecular Mass of sample component +# +# +# +# Description of the sample component +# +# +# +# Volume fraction of component +# +# +# Scattering length density of component +# +# +# +# In case it is all we know and we want to record/document it +# +# +# +# +# +# +# +# +# +# +# +# +# Crystallographic space group +# +# +# Crystallographic point group, deprecated if space_group present +# +# +# As a function of Wavelength +# # # # A set of physical processes that occurred to the sample component prior/during # experiment. # # -# -# -# Any NXsample_component depends on the instance of NXsample_component_set, at the same level of -# description granularity where the component is located. -# -# -# -# -# .. 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 index de220d4c7c..7f37b861c0 100644 --- a/base_classes/nyaml/NXsensor.yaml +++ b/base_classes/nyaml/NXsensor.yaml @@ -4,7 +4,7 @@ doc: | The condition itself is described in :ref:`NXenvironment`. type: group -NXsensor(NXobject): +NXsensor(NXcomponent): model: doc: | Sensor identification code/model number @@ -21,12 +21,13 @@ NXsensor(NXobject): 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. + 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, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] + enumeration: + open_enum: true + items: [temperature, pH, magnetic_field, electric_field, current, conductivity, resistance, voltage, pressure, flow, stress, strain, shear, surface_pressure] type: doc: | The type of hardware used for the measurement. @@ -97,44 +98,20 @@ NXsensor(NXobject): 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 ++++++++++++++++++++++++++++++++++ -# 40d1ed4cb50344e251cc8cec9dcbaeef0fe93ee78f95d9fafdb6dec2c64a2979 -# -# +# 03e9b2b899eadaf52d22e91a46ab395b87baa6549bfeafedf0faa03c91a3c84a +# +# # -# -# -# 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. -# -# # # -# 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. +# .. 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/NXshape.yaml b/base_classes/nyaml/NXshape.yaml index d98352f340..a855e0920d 100644 --- a/base_classes/nyaml/NXshape.yaml +++ b/base_classes/nyaml/NXshape.yaml @@ -33,26 +33,15 @@ NXshape(NXobject): dim: (numobj, nshapepar) direction: enumeration: [concave, convex] - \@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 ++++++++++++++++++++++++++++++++++ -# ca2fe277bdbf06632a5d6558871856ca8a509938878364d2a26e0c73b7e4ea04 +# 4b6fddb9a3b87b2644723de4bd7dc4930f3542d7d47e5ca3d8e03d05353ebfa2 # # # -# -# -# Radiation source emitting a beam. -# -# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). -# This base class can also be used to describe neutron or x-ray storage ring/facilities. -# -# -# -# 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) -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# +# Radiation source emitting a beam. +# +# Examples include particle sources (electrons, neutrons, protons) or sources for electromagnetic radiation (photons). +# This base class can also be used to describe neutron or x-ray storage ring/facilities. +# +# +# +# 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) +# +# +# +# +# +# +# +# +# +# +# +# +# +# # -# +# # -# +# # -# +# # # # -# -# -# -# -# -# Specification of type, may also go to name. -# -# -# -# -# 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. Typically, this would be the energy of -# the emitted beam. For storage rings, this would be -# the particle beam energy. -# -# -# -# -# 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 wavelength of the radiation emitted by the source. -# -# -# -# -# For pulsed sources, the energy of a single pulse. -# -# -# -# -# For pulsed sources, the pulse energy divided -# by the pulse duration -# -# -# -# -# Material of the anode (for X-ray tubes). -# -# -# -# -# Filament current (for X-ray tubes). -# -# -# -# -# Emission current of the generated beam. -# -# -# -# -# Gas pressure inside ionization source. -# -# +# +# +# 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. Typically, this would be the energy of +# the emitted beam. For storage rings, this would be +# the particle beam energy. +# +# +# +# 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 wavelength of the radiation emitted by the source. +# +# +# +# +# For pulsed sources, the energy of a single pulse. +# +# +# +# +# For pulsed sources, the pulse energy divided +# by the pulse duration +# +# +# +# +# Material of the anode (for X-ray tubes). +# +# +# +# +# Filament current (for X-ray tubes). +# +# +# +# +# Emission current of the generated beam. +# +# +# +# +# Gas pressure inside ionization source. +# +# # # # Single instance or list of instances of NXsource pointing to the sources from which a beam originated to reach this source. # This can be used, for example, for secondary sources to describe which other source(s) they are derived from. -# +# # An example is the white light source in transient absorption spectroscopy, which is a supercontinuum crystal that is pumped by a # another laser. -# +# # In case of a primary source, this field should not be filled. # # -# -# -# "Engineering" location of source. -# -# -# -# -# The size and position of an aperture inside the source. -# -# -# -# -# Deflectors inside the source. -# -# -# -# -# Individual electromagnetic lenses inside the 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. -# -# -# +# +# +# "Engineering" location of source. +# +# +# +# +# The size and position of an aperture inside the source. +# +# +# +# +# Deflectors inside the source. +# +# +# +# +# +# This group describes the shape of the beam line component +# +# +# +# The wavelength or energy distribution of the source +# +# +# +# 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% +# +# +# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXsubentry.yaml b/base_classes/nyaml/NXsubentry.yaml index f99cf3de60..5f66960faf 100644 --- a/base_classes/nyaml/NXsubentry.yaml +++ b/base_classes/nyaml/NXsubentry.yaml @@ -49,25 +49,63 @@ NXsubentry(NXobject): title: doc: | Extended title for entry - experiment_identifier(NXidentifier): + experiment_identifier: + deprecated: | + Use the field :ref:`identifier_experiment ` instead. doc: | - Unique identifier for the experiment, defined by - the facility, possibly linked to the proposals + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals + identifier_experiment: + doc: | + Unique identifier for the experiment, + defined by the facility, + possibly linked to the proposals experiment_description: doc: | Brief summary of the experiment, including key objectives. - (NXnote)experiment_documentation: + experiment_documentation(NXnote): doc: | Description of the full experiment (document in pdf, latex, ...) - collection_identifier(NXidentifier): + collection_identifier: + deprecated: | + Use the field :ref:`identifier_collection ` instead. + doc: | + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` + identifier_collection: doc: | User or Data Acquisition defined group of NeXus files or :ref:`NXentry` collection_description: doc: | Brief summary of the collection, including grouping criteria. - entry_identifier(NXidentifier): + entry_identifier: + deprecated: | + Use the field :ref:`identifier_entry ` instead. doc: | unique identifier for the measurement, defined by the facility. + identifier_entry: + doc: | + unique identifier for the measurement, defined by the facility. + experiment_location: + doc: | + City and country where the experiment took place + experiment_start_date(NX_DATE_TIME): + doc: | + Start time of experimental run that includes the current + measurement, for example a beam time. + experiment_end_date(NX_DATE_TIME): + doc: | + End time of experimental run that includes the current + measurement, for example a beam time. + experiment_institution: + doc: | + Name of the institution hosting the facility + experiment_facility: + doc: | + Name of the experimental facility + experiment_laboratory: + doc: | + Name of the laboratory or beamline definition: doc: | Official NeXus NXDL schema to which this subentry conforms @@ -138,10 +176,11 @@ NXsubentry(NXobject): \@mime_type: doc: | The value should be an ``image/*`` - - # This is not perfect. - # How do we set a default value for the mime_type attribute? - enumeration: [image/*] + enumeration: + + # This is not perfect. + # How do we set a default value for the mime_type attribute? + items: [image/*] (NXuser): (NXsample): (NXinstrument): @@ -152,14 +191,14 @@ NXsubentry(NXobject): (NXprocess): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d7b7886c7be3ba7287e599facfbb4cc0a69f66c1011cd89bc2e5100004b9f881 -# -# +# 9b2ca666e12fe0dd9c8172548b3080b85d5c98cca0b0ed921e59c0d30d9e9560 +# +# # -# -# -# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. -# -# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` -# and is used as the (overlay) location for application definitions. -# Use a separate ``NXsubentry`` for each application definition. -# -# To use ``NXsubentry`` with a hypothetical application definition -# called ``NXmyappdef``: -# -# * Create a group with attribute ``NX_class="NXsubentry"`` -# * Within that group, create a field called ``definition="NXmyappdef"``. -# * There are two optional attributes of definition: ``version`` and ``URL`` -# -# The intended use is to define application definitions for a -# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. -# Previously, an application definition -# replaced :ref:`NXentry` with its own definition. -# With the increasing popularity of instruments combining -# multiple techniques for data collection (such as SAXS/WAXS instruments), -# it was recognized the application definitions must be entered in the NeXus -# data file tree as children of :ref:`NXentry`. -# -# -# -# .. index:: find the default plottable data -# .. index:: plotting -# .. index:: default attribute value -# -# Declares which :ref:`NXdata` group contains the data -# to be shown by default. -# It is used to resolve ambiguity when -# one :ref:`NXdata` group exists. -# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The -# value must be the name of a child of the current group. The child must be a -# NeXus group or a link to a NeXus group. -# -# For more information about how NeXus identifies the default -# plottable data, see the -# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` -# section. -# -# -# -# -# -# ISIS Muon IDF_Version -# -# -# -# -# Extended title for entry -# -# -# -# -# Unique identifier for the experiment, defined by -# the facility, possibly linked to the proposals -# -# -# -# -# Brief summary of the experiment, including key objectives. -# -# -# -# -# Description of the full experiment (document in pdf, latex, ...) -# -# -# -# -# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` -# -# -# -# -# Brief summary of the collection, including grouping criteria. -# -# -# -# -# unique identifier for the measurement, defined by the facility. -# -# -# -# -# Official NeXus NXDL schema to which this subentry conforms -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# -# -# -# -# Local NXDL schema extended from the subentry -# specified in the ``definition`` field. -# This contains any locally-defined, -# additional fields in the subentry. -# -# -# -# NXDL version number -# -# -# -# -# URL of NXDL file -# -# +# +# +# +# +# .. index:: find the default plottable data +# .. index:: plotting +# .. index:: default attribute value +# +# Declares which :ref:`NXdata` group contains the data +# to be shown by default. +# It is used to resolve ambiguity when +# one :ref:`NXdata` group exists. +# The value :ref:`names <validItemName>` the default :ref:`NXentry` group. The +# value must be the name of a child of the current group. The child must be a +# NeXus group or a link to a NeXus group. +# +# For more information about how NeXus identifies the default +# plottable data, see the +# :ref:`Find Plottable Data, v3 <Find-Plottable-Data-v3>` +# section. +# +# +# +# +# Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. +# +# ``NXsubentry`` is a base class virtually identical to :ref:`NXentry` +# and is used as the (overlay) location for application definitions. +# Use a separate ``NXsubentry`` for each application definition. +# +# To use ``NXsubentry`` with a hypothetical application definition +# called ``NXmyappdef``: +# +# * Create a group with attribute ``NX_class="NXsubentry"`` +# * Within that group, create a field called ``definition="NXmyappdef"``. +# * There are two optional attributes of definition: ``version`` and ``URL`` +# +# The intended use is to define application definitions for a +# multi-modal (a.k.a. multi-technique) :ref:`NXentry`. +# Previously, an application definition +# replaced :ref:`NXentry` with its own definition. +# With the increasing popularity of instruments combining +# multiple techniques for data collection (such as SAXS/WAXS instruments), +# it was recognized the application definitions must be entered in the NeXus +# data file tree as children of :ref:`NXentry`. +# +# +# +# +# ISIS Muon IDF_Version +# +# +# +# Extended title for entry +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# +# Unique identifier for the experiment, +# defined by the facility, +# possibly linked to the proposals +# +# +# +# Brief summary of the experiment, including key objectives. +# +# +# Description of the full experiment (document in pdf, latex, ...) +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# User or Data Acquisition defined group of NeXus files or :ref:`NXentry` +# +# +# Brief summary of the collection, including grouping criteria. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# unique identifier for the measurement, defined by the facility. +# +# +# City and country where the experiment took place # -# +# # -# Starting time of measurement +# Start time of experimental run that includes the current +# measurement, for example a beam time. # # -# +# # -# Ending time of measurement +# End time of experimental run that includes the current +# measurement, for example a beam time. # # -# +# # -# Duration of measurement +# Name of the institution hosting the facility # # -# +# # -# Time transpired actually collecting data i.e. taking out time when collection was -# suspended due to e.g. temperature out of range +# Name of the experimental facility # # -# +# # -# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# Name of the laboratory or beamline # # -# -# -# Name of program used to generate this file -# -# -# -# Program version number -# -# -# -# -# configuration of the program -# -# -# -# -# -# Revision id of the file due to re-calibration, reprocessing, new analysis, new -# instrument definition format, ... -# -# -# -# -# -# This is the flightpath before the sample position. This can be determined by a chopper, -# by the moderator or the source itself. In other words: it the distance to the component -# which gives the T0 signal to the detector electronics. If another component in the -# NXinstrument hierarchy provides this information, this should be a link. -# -# -# -# -# Notes describing entry -# -# -# -# -# A small image that is representative of the entry. An example of this is a 640x480 -# jpeg image automatically produced by a low resolution plot of the NXdata. -# -# -# -# The value should be an ``image/*`` -# -# -# -# -# -# -# -# -# -# -# -# -# -# -# +# +# Official NeXus NXDL schema to which this subentry conforms +# NXDL version number +# URL of NXDL file +# +# +# +# Local NXDL schema extended from the subentry +# specified in the ``definition`` field. +# This contains any locally-defined, +# additional fields in the subentry. +# +# NXDL version number +# URL of NXDL file +# +# +# Starting time of measurement +# +# +# Ending time of measurement +# +# +# Duration of measurement +# +# +# +# Time transpired actually collecting data i.e. taking out time when collection was +# suspended due to e.g. temperature out of range +# +# +# +# Such as "2007-3". Some user facilities organize their beam time into run cycles. +# +# +# Name of program used to generate this file +# Program version number +# configuration of the program +# +# +# +# Revision id of the file due to re-calibration, reprocessing, new analysis, new +# instrument definition format, ... +# +# +# +# +# +# This is the flightpath before the sample position. This can be determined by a chopper, +# by the moderator or the source itself. In other words: it the distance to the component +# which gives the T0 signal to the detector electronics. If another component in the +# NXinstrument hierarchy provides this information, this should be a link. +# +# +# +# Notes describing entry +# +# +# +# A small image that is representative of the entry. An example of this is a 640x480 +# jpeg image automatically produced by a low resolution plot of the NXdata. +# +# +# The value should be an ``image/*`` +# +# +# +# +# +# +# +# +# +# +# +# +# +# # diff --git a/base_classes/nyaml/NXtransformations.yaml b/base_classes/nyaml/NXtransformations.yaml index 29225cd587..17d25b7cab 100644 --- a/base_classes/nyaml/NXtransformations.yaml +++ b/base_classes/nyaml/NXtransformations.yaml @@ -100,11 +100,11 @@ doc: | The sample is oriented as follows .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . - T(\vec{v}_z, \text{sam}_z) . - T(\vec{v}_y, \text{sam}_y) . - T(\vec{v}_x, \text{sam}_x) . - R(\vec{v}_\chi, \chi) . - R(\vec{v}_\varphi, \varphi) . X_s + T(\vec{v}_z, \text{sam}_z) . + T(\vec{v}_y, \text{sam}_y) . + T(\vec{v}_x, \text{sam}_x) . + R(\vec{v}_\chi, \chi) . + R(\vec{v}_\varphi, \varphi) . X_s where @@ -246,7 +246,7 @@ NXtransformations(NXobject): by HDF5. The values given should be the start points of exposures for the corresponding - frames. The end points should be given in ``AXISNAME_end``. + frames. The end points should be given in ``AXISNAME_end``. \@transformation_type: exists: optional doc: | @@ -257,10 +257,12 @@ NXtransformations(NXobject): If this attribute is omitted, this is an axis for which there is no motion to be specifies, such as the direction of gravity, or the direction to the source, or a basis vector of a - coordinate frame. - - # - enumeration: [translation, rotation] + coordinate frame. In this case the value of the ``AXISNAME`` field + is not used and can be set to the number ``NaN``. + enumeration: + + # + items: [translation, rotation] \@vector(NX_NUMBER): exists: optional doc: | @@ -287,9 +289,8 @@ NXtransformations(NXobject): Units of the offset. Values should be consistent with NX_LENGTH. \@depends_on(NX_CHAR): doc: | - Points to the path of a field defining the axis on which this instance of - NXtransformations depends or the string ".". It can also point to an instance of - ``NX_coordinate_system`` if this transformation depends on it. + Points to the path to a field defining the axis on which this + depends or the string ".". \@equipment_component(NX_CHAR): doc: | An arbitrary identifier of a component of the equipment to which @@ -299,8 +300,8 @@ NXtransformations(NXobject): operation. AXISNAME_end(NX_NUMBER): unit: NX_TRANSFORMATION - nameType: any - exists: ['min', '0'] + nameType: partial + exists: ['min', '0', 'max', 'unbounded'] doc: | ``AXISNAME_end`` is a placeholder for a name constructed from the actual name of an axis to which ``_end`` has been appended. @@ -309,7 +310,7 @@ NXtransformations(NXobject): at the corresponding positions given in the ``AXISNAME`` field. AXISNAME_increment_set(NX_NUMBER): unit: NX_TRANSFORMATION - nameType: any + nameType: partial exists: ['min', '0'] doc: | ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual @@ -319,28 +320,17 @@ NXtransformations(NXobject): the corresponding axis moves during the exposure of a frame. Ideally, the value of this field added to each value of ``AXISNAME`` would agree with the corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. - \@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. + differences. Use of ``AXISNAME_end`` is recommended. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 35bf78e4f3e8e66235231bb6c6d8f3a9e64bd5cd5300a45b407541057f377c0a +# 5ec435b84c65b2ce2864006e1089ceac5bef99fcd7ff06487384f43384f8b5f5 # # # # # -# Collection of axis-based translations and rotations to describe a geometry. -# May also contain axes that do not move and therefore do not have a transformation -# type specified, but are useful in understanding coordinate frames within which -# transformations are done, or in documenting important directions, such as the -# direction of gravity. -# -# A nested sequence of transformations lists the translation and rotation steps -# needed to describe the position and orientation of any movable or fixed device. -# -# There will be one or more transformations (axes) defined by one or more fields -# for each transformation. Transformations can also be described by NXlog groups when -# the values change with time. The all-caps name ``AXISNAME`` designates the -# particular axis generating a transformation (e.g. a rotation axis or a translation -# axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the -# units will be appropriate to the ``transformation_type`` attribute: -# -# * ``NX_LENGTH`` for ``translation`` -# * ``NX_ANGLE`` for ``rotation`` -# * ``NX_UNITLESS`` for axes for which no transformation type is specified -# -# This class will usually contain all axes of a sample stage or goniometer or -# a detector. The NeXus default :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` -# is assumed, but additional useful coordinate axes may be defined by using axes for which -# no transformation type has been specified. -# -# **Transformation chain** -# -# The entry point of a chain of transformations is a field called ``depends_on`` -# will be outside of this class and points to a field in here. Following the chain may -# also require following ``depends_on`` links to transformations outside, for example -# to a common base table. If a relative path is given, it is relative to the group -# enclosing the ``depends_on`` specification. -# -# For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` -# which in turn depends on :math:`T_3`, the final *active* transformation -# matrix :math:`T_f` is -# -# .. math:: T_f = T_3 . T_2 . T_1 -# -# For example when positioning a flat detector, its pixel positions in the laboratory -# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) -# can be calculated by -# -# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} -# -# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first -# to the pixel coordinates. -# -# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that -# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. -# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate -# before applying :math:`B`. In other words :math:`X' = B . A . X`. -# -# **Transformation matrix** -# -# In explicit terms, the transformations are a subset of affine transformations expressed as -# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. -# -# For rotation and translation, -# -# .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} -# -# where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, -# :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and -# :math:`t` is the translation vector. -# -# :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` -# attribute multiplied by the field value, and :math:`R` is defined as a rotation -# about an axis in the direction of ``vector``, of angle of the field value. -# -# **Usage** -# -# One possible use of ``NXtransformations`` is to define the motors and -# transformations for a diffractometer (goniometer). Such use is mentioned -# in the ``NXinstrument`` base class. Use one ``NXtransformations`` group -# for each diffractometer and name the group appropriate to the device. -# Collecting the motors of a sample table or xyz-stage in an NXtransformations -# group is equally possible. -# -# Following the section on the general description of axis in NXtransformations is a section which -# documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever -# there is a need for positioning a beam line component please use the existing names. Use as many fields -# as needed in order to position the component. Feel free to add more axis if required. In the description -# given below, only those atttributes which are defined through the name are spcified. Add the other attributes -# of the full set: -# -# * vector -# * offset -# * transformation_type -# * depends_on -# -# as needed. -# -# **Example 1: goniometer** -# -# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. -# -# The sample is oriented as follows -# -# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . -# T(\vec{v}_z, \text{sam}_z) . -# T(\vec{v}_y, \text{sam}_y) . -# T(\vec{v}_x, \text{sam}_x) . -# R(\vec{v}_\chi, \chi) . -# R(\vec{v}_\varphi, \varphi) . X_s -# -# where -# -# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` -# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` -# * :math:`X_s` a coordinate in the sample reference frame. -# -# .. code-block:: -# -# entry:NXentry -# sample:NXsample -# depends_on=transformations/phi -# transformations:NXtransformations -# phi=0 -# @depends_on=chi -# @transformation_type=rotation -# @vector=[-1 -0.0037 -0.002] -# @units=degrees -# chi=0 -# @depends_on=sam_x -# @transformation_type=rotation -# @vector=[0.0046 0.0372 0.9993] -# @units=degrees -# sam_x=0 -# @depends_on=sam_y -# @transformation_type=translation -# @vector=[1 0 0] -# @units=mm -# sam_y=0 -# @depends_on=sam_z -# @transformation_type=translation -# @vector=[0 1 0] -# @units=mm -# sam_z=0 -# @depends_on=omega -# @transformation_type=translation -# @vector=[0 0 1] -# @units=mm -# omega=174 -# @depends_on=. -# @transformation_type=rotation -# @vector=[-1 0 0] -# @units=degrees -# -# **Example 2: different coordinate system** -# -# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. -# Three point detectors are positioned in this reference: -# -# * *transmission*: -# * point detector in the beam -# * 20 cm downstream from the sample (the origin of the reference frame) -# * *vertical*: -# * point detector 10 cm downstream from the sample -# * making an angle of 5 degrees with the beam w.r.t. the sample -# * positioned in the XZ-plane above the XY-plane -# * *horizontal*: -# * point detector 11 cm downstream from the sample -# * making an angle of 6 degrees with the beam w.r.t. the sample -# * positioned in the XY-plane above the XZ-plane -# -# The coordinates of the point detectors in the laboratory reference frame are -# -# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` -# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` -# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` -# -# where -# -# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes -# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes -# * :math:`X_d` is a coordinate in the detector reference frame. -# -# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. -# -# .. code-block:: -# -# entry:NXentry -# instrument:NXinstrument -# vertical:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=10 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=5 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=0 # stay in the vertical plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# horizontal:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=11 # move downstream from the sample -# @depends_on=polar -# @units=cm -# @vector=[1 0 0] -# polar=6 # title above the horizontal plane -# @depends_on=azimuth -# @units=degrees -# @vector=[0 -1 0] -# azimuth=90 # rotate to the horizontal plane -# @depends_on=/entry/coordinate_system/beam -# @units=degrees -# @vector=[-1 0 0] -# transmission:NXdetector -# depends_on=position/distance -# position:NXtransformations -# distance=20 # move downstream from the sample -# @depends_on=/entry/coordinate_system/beam -# @units=cm -# @vector=[1 0 0] -# coordinate_system:NXtransformations -# beam=NaN # value is never used -# @depends_on=gravity -# @vector=[1 0 0] # X-axis points in the beam direction -# gravity=NaN # value is never used -# @depends_on=. # end of the chain -# @vector=[0 0 -1] # Z-axis points up +# Collection of axis-based translations and rotations to describe a geometry. +# May also contain axes that do not move and therefore do not have a transformation +# type specified, but are useful in understanding coordinate frames within which +# transformations are done, or in documenting important directions, such as the +# direction of gravity. +# +# A nested sequence of transformations lists the translation and rotation steps +# needed to describe the position and orientation of any movable or fixed device. +# +# There will be one or more transformations (axes) defined by one or more fields +# for each transformation. Transformations can also be described by NXlog groups when +# the values change with time. The all-caps name ``AXISNAME`` designates the +# particular axis generating a transformation (e.g. a rotation axis or a translation +# axis or a general axis). The attribute ``units="NX_TRANSFORMATION"`` designates the +# units will be appropriate to the ``transformation_type`` attribute: +# +# * ``NX_LENGTH`` for ``translation`` +# * ``NX_ANGLE`` for ``rotation`` +# * ``NX_UNITLESS`` for axes for which no transformation type is specified +# +# This class will usually contain all axes of a sample stage or goniometer or +# a detector. The NeXus default :ref:`McSTAS coordinate frame<Design-CoordinateSystem>` +# is assumed, but additional useful coordinate axes may be defined by using axes for which +# no transformation type has been specified. +# +# **Transformation chain** +# +# The entry point of a chain of transformations is a field called ``depends_on`` +# will be outside of this class and points to a field in here. Following the chain may +# also require following ``depends_on`` links to transformations outside, for example +# to a common base table. If a relative path is given, it is relative to the group +# enclosing the ``depends_on`` specification. +# +# For a chain of three transformations, where :math:`T_1` depends on :math:`T_2` +# which in turn depends on :math:`T_3`, the final *active* transformation +# matrix :math:`T_f` is +# +# .. math:: T_f = T_3 . T_2 . T_1 +# +# For example when positioning a flat detector, its pixel positions in the laboratory +# reference frame (:ref:`McSTAS coordinate frame<Design-CoordinateSystem>` by default) +# can be calculated by +# +# .. math:: X_\text{lab} = T_f . X_\text{pixel} = T_3 . T_2 . T_1 . X_\text{pixel} +# +# Note that :math:`T_1` comes first in the *depends-on* chain and is also applied first +# to the pixel coordinates. +# +# When we say transformation :math:`A` *depends on* transformation :math:`B` we mean that +# the physical motor that realizes :math:`A` is *stacked on top of* the motor that realizes :math:`B`. +# So the activate coordinate transformation :math:`A` needs to be applied to a coordinate +# before applying :math:`B`. In other words :math:`X' = B . A . X`. +# +# **Transformation matrix** +# +# In explicit terms, the transformations are a subset of affine transformations expressed as +# 4x4 active transformation matrices that act on homogeneous coordinates, :math:`X=[x,y,z,1]^T`. +# +# For rotation and translation, +# +# .. math:: T_r &= \begin{pmatrix} R & o \\ 0_3 & 1 \end{pmatrix} \\ T_t &= \begin{pmatrix} I_3 & t + o \\ 0_3 & 1 \end{pmatrix} +# +# where :math:`R` is the usual 3x3 rotation matrix, :math:`o` is an offset vector, +# :math:`0_3` is a row of 3 zeros, :math:`I_3` is the 3x3 identity matrix and +# :math:`t` is the translation vector. +# +# :math:`o` is given by the ``offset`` attribute, :math:`t` is given by the ``vector`` +# attribute multiplied by the field value, and :math:`R` is defined as a rotation +# about an axis in the direction of ``vector``, of angle of the field value. +# +# **Usage** +# +# One possible use of ``NXtransformations`` is to define the motors and +# transformations for a diffractometer (goniometer). Such use is mentioned +# in the ``NXinstrument`` base class. Use one ``NXtransformations`` group +# for each diffractometer and name the group appropriate to the device. +# Collecting the motors of a sample table or xyz-stage in an NXtransformations +# group is equally possible. +# +# Following the section on the general description of axis in NXtransformations is a section which +# documents the fields commonly used within NeXus for positioning purposes and their meaning. Whenever +# there is a need for positioning a beam line component please use the existing names. Use as many fields +# as needed in order to position the component. Feel free to add more axis if required. In the description +# given below, only those atttributes which are defined through the name are spcified. Add the other attributes +# of the full set: +# +# * vector +# * offset +# * transformation_type +# * depends_on +# +# as needed. +# +# **Example 1: goniometer** +# +# Position a sample mounted on a goniometer in the :ref:`McSTAS coordinate frame<Design-CoordinateSystem>`. +# +# The sample is oriented as follows +# +# .. math:: X_\text{lab} = R(\vec{v}_\omega, \omega) . +# T(\vec{v}_z, \text{sam}_z) . +# T(\vec{v}_y, \text{sam}_y) . +# T(\vec{v}_x, \text{sam}_x) . +# R(\vec{v}_\chi, \chi) . +# R(\vec{v}_\varphi, \varphi) . X_s +# +# where +# +# * :math:`R(\vec{v},a)` is a rotation around vector :math:`\vec{v}` with angle :math:`a` +# * :math:`T(\vec{u},t)` is a translation along vector :math:`\vec{u}` over a distance :math:`t` +# * :math:`X_s` a coordinate in the sample reference frame. +# +# .. code-block:: +# +# entry:NXentry +# sample:NXsample +# depends_on=transformations/phi +# transformations:NXtransformations +# phi=0 +# @depends_on=chi +# @transformation_type=rotation +# @vector=[-1 -0.0037 -0.002] +# @units=degrees +# chi=0 +# @depends_on=sam_x +# @transformation_type=rotation +# @vector=[0.0046 0.0372 0.9993] +# @units=degrees +# sam_x=0 +# @depends_on=sam_y +# @transformation_type=translation +# @vector=[1 0 0] +# @units=mm +# sam_y=0 +# @depends_on=sam_z +# @transformation_type=translation +# @vector=[0 1 0] +# @units=mm +# sam_z=0 +# @depends_on=omega +# @transformation_type=translation +# @vector=[0 0 1] +# @units=mm +# omega=174 +# @depends_on=. +# @transformation_type=rotation +# @vector=[-1 0 0] +# @units=degrees +# +# **Example 2: different coordinate system** +# +# Define a laboratory reference frame with the X-axis along the beam and the Z-axis opposite to the direction of gravity. +# Three point detectors are positioned in this reference: +# +# * *transmission*: +# * point detector in the beam +# * 20 cm downstream from the sample (the origin of the reference frame) +# * *vertical*: +# * point detector 10 cm downstream from the sample +# * making an angle of 5 degrees with the beam w.r.t. the sample +# * positioned in the XZ-plane above the XY-plane +# * *horizontal*: +# * point detector 11 cm downstream from the sample +# * making an angle of 6 degrees with the beam w.r.t. the sample +# * positioned in the XY-plane above the XZ-plane +# +# The coordinates of the point detectors in the laboratory reference frame are +# +# * *transmission*: :math:`X_\text{lab} = T_x(20) . X_d` +# * *vertical*: :math:`X_\text{lab} = R_y(-5) . T_x(10) . X_d` +# * *horizontal*: :math:`X_\text{lab} = R_x(-90) . R_y(-6) . T_x(11) . X_d` +# +# where +# +# * :math:`T_x`, :math:`T_y`, :math:`T_z`: active transformation matrices for translation along the X, Y and Z axes +# * :math:`R_x`, :math:`R_y`, :math:`R_z`: active transformation matrices for rotation around the X, Y and Z axes +# * :math:`X_d` is a coordinate in the detector reference frame. +# +# Note that as these are point detectors, we only have one coordinate :math:`X_d=[0,0,0,1]^T`. +# +# .. code-block:: +# +# entry:NXentry +# instrument:NXinstrument +# vertical:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=10 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=5 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=0 # stay in the vertical plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# horizontal:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=11 # move downstream from the sample +# @depends_on=polar +# @units=cm +# @vector=[1 0 0] +# polar=6 # title above the horizontal plane +# @depends_on=azimuth +# @units=degrees +# @vector=[0 -1 0] +# azimuth=90 # rotate to the horizontal plane +# @depends_on=/entry/coordinate_system/beam +# @units=degrees +# @vector=[-1 0 0] +# transmission:NXdetector +# depends_on=position/distance +# position:NXtransformations +# distance=20 # move downstream from the sample +# @depends_on=/entry/coordinate_system/beam +# @units=cm +# @vector=[1 0 0] +# coordinate_system:NXtransformations +# beam=NaN # value is never used +# @depends_on=gravity +# @vector=[1 0 0] # X-axis points in the beam direction +# gravity=NaN # value is never used +# @depends_on=. # end of the chain +# @vector=[0 0 -1] # Z-axis points up # -# +# # -# Units need to be appropriate for translation or rotation -# -# The name of this field is not forced. The user is free to use any name -# that does not cause confusion. When using more than one ``AXISNAME`` field, -# make sure that each field name is unique in the same group, as required -# by HDF5. -# -# The values given should be the start points of exposures for the corresponding -# frames. The end points should be given in ``AXISNAME_end``. +# Units need to be appropriate for translation or rotation +# +# The name of this field is not forced. The user is free to use any name +# that does not cause confusion. When using more than one ``AXISNAME`` field, +# make sure that each field name is unique in the same group, as required +# by HDF5. +# +# The values given should be the start points of exposures for the corresponding +# frames. The end points should be given in ``AXISNAME_end``. # -# -# -# The transformation_type may be ``translation``, in which case the -# values are linear displacements along the axis, ``rotation``, -# in which case the values are angular rotations around the axis. -# -# If this attribute is omitted, this is an axis for which there -# is no motion to be specifies, such as the direction of gravity, -# or the direction to the source, or a basis vector of a -# coordinate frame. -# -# -# -# -# -# -# -# -# -# Three values that define the axis for this transformation. -# The axis should be normalized to unit length, making it -# dimensionless. For ``rotation`` axes, the direction should be -# chosen for a right-handed rotation with increasing angle. -# For ``translation`` axes the direction should be chosen for -# increasing displacement. For general axes, an appropriate direction -# should be chosen. -# -# -# -# -# -# -# -# A fixed offset applied before the transformation (three vector components). -# This is not intended to be a substitute for a fixed ``translation`` axis but, for example, -# as the mechanical offset from mounting the axis to its dependency. -# -# -# -# -# -# -# -# Units of the offset. Values should be consistent with NX_LENGTH. -# -# -# -# -# Points to the path of a field defining the axis on which this instance of -# NXtransformations depends or the string ".". It can also point to an instance of -# ``NX_coordinate_system`` if this transformation depends on it. -# -# -# -# -# An arbitrary identifier of a component of the equipment to which -# the transformation belongs, such as 'detector_arm' or 'detector_module'. -# NXtransformations with the same equipment_component label form a logical -# grouping which can be combined together into a single change-of-basis -# operation. -# -# +# +# +# The transformation_type may be ``translation``, in which case the +# values are linear displacements along the axis, ``rotation``, +# in which case the values are angular rotations around the axis. +# +# If this attribute is omitted, this is an axis for which there +# is no motion to be specifies, such as the direction of gravity, +# or the direction to the source, or a basis vector of a +# coordinate frame. In this case the value of the ``AXISNAME`` field +# is not used and can be set to the number ``NaN``. +# +# +# +# +# +# +# +# +# +# Three values that define the axis for this transformation. +# The axis should be normalized to unit length, making it +# dimensionless. For ``rotation`` axes, the direction should be +# chosen for a right-handed rotation with increasing angle. +# For ``translation`` axes the direction should be chosen for +# increasing displacement. For general axes, an appropriate direction +# should be chosen. +# +# +# +# +# +# +# +# A fixed offset applied before the transformation (three vector components). +# This is not intended to be a substitute for a fixed ``translation`` axis but, for example, +# as the mechanical offset from mounting the axis to its dependency. +# +# +# +# +# +# +# +# Units of the offset. Values should be consistent with NX_LENGTH. +# +# +# +# +# Points to the path to a field defining the axis on which this +# depends or the string ".". +# +# +# +# +# An arbitrary identifier of a component of the equipment to which +# the transformation belongs, such as 'detector_arm' or 'detector_module'. +# NXtransformations with the same equipment_component label form a logical +# grouping which can be combined together into a single change-of-basis +# operation. +# +# # -# +# # -# ``AXISNAME_end`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_end`` has been appended. -# -# The values in this field are the end points of the motions that start -# at the corresponding positions given in the ``AXISNAME`` field. +# ``AXISNAME_end`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_end`` has been appended. +# +# The values in this field are the end points of the motions that start +# at the corresponding positions given in the ``AXISNAME`` field. # # -# -# -# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual -# name of an axis to which ``_increment_set`` has been appended. -# -# The value of this optional field is the intended average range through which -# the corresponding axis moves during the exposure of a frame. Ideally, the -# value of this field added to each value of ``AXISNAME`` would agree with the -# corresponding values of ``AXISNAME_end``, but there is a possibility of significant -# differences. Use of ``AXISNAME_end`` is recommended. -# +# +# +# ``AXISNAME_increment_set`` is a placeholder for a name constructed from the actual +# name of an axis to which ``_increment_set`` has been appended. +# +# The value of this optional field is the intended average range through which +# the corresponding axis moves during the exposure of a frame. Ideally, the +# value of this field added to each value of ``AXISNAME`` would agree with the +# corresponding values of ``AXISNAME_end``, but there is a possibility of significant +# differences. Use of ``AXISNAME_end`` is recommended. +# # -# -# -# .. 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. -# -# -# +# \ No newline at end of file diff --git a/base_classes/nyaml/NXtranslation.yaml b/base_classes/nyaml/NXtranslation.yaml index a11f0a82e2..cb805d93e2 100644 --- a/base_classes/nyaml/NXtranslation.yaml +++ b/base_classes/nyaml/NXtranslation.yaml @@ -20,26 +20,15 @@ NXtranslation(NXobject): orthonormal. dimensions: dim: (numobj, 3) - \@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 ++++++++++++++++++++++++++++++++++ -# 2f8b7eb59ddd7d4f82b69c1f7968c182049ed20f1d8aa4d365e40c14804ebd13 +# 2d235cc05f37ace5ebffc2c8360b70ee0b2ce36c7a402373166a8d5cf3d38f3b # # # -# -# -# Contact information for a user. -# -# The format allows more -# than one user with the same affiliation and contact information, -# but a second :ref:`NXuser` group should be used if they have different -# affiliations, etc. -# -# -# -# Name of user responsible for this entry -# -# -# -# -# Role of user responsible for this entry. -# Suggested roles are "local_contact", -# "principal_investigator", and "proposer" -# -# -# -# -# Affiliation of user -# -# -# -# -# Address of user -# -# -# -# -# Telephone number of user -# -# -# -# -# Fax number of user -# -# -# -# -# Email of user -# -# -# -# -# facility based unique identifier for this person -# e.g. their identification code on the facility -# address/contact database -# -# -# -# -# Details about an author code, open researcher, or contributor -# (persistent) identifier, e.g. defined by https://orcid.org and expressed -# as a URI. -# -# -# -# -# .. 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. -# -# +# +# +# Contact information for a user. +# +# The format allows more +# than one user with the same affiliation and contact information, +# but a second :ref:`NXuser` group should be used if they have different +# affiliations, etc. +# +# +# Name of user responsible for this entry +# +# +# +# Role of user responsible for this entry. +# Suggested roles are "local_contact", +# "principal_investigator", and "proposer" +# +# +# +# Affiliation of user +# +# +# Address of user +# +# +# Telephone number of user +# +# +# Fax number of user +# +# +# Email of user +# +# +# +# facility based unique identifier for this person +# e.g. their identification code on the facility +# address/contact database +# +# +# +# +# an author code, Open Researcher and Contributor ID, +# defined by https://orcid.org and expressed as a URI +# +# # +# diff --git a/base_classes/nyaml/NXvelocity_selector.yaml b/base_classes/nyaml/NXvelocity_selector.yaml index fdfa162b96..ca034fefd7 100644 --- a/base_classes/nyaml/NXvelocity_selector.yaml +++ b/base_classes/nyaml/NXvelocity_selector.yaml @@ -2,7 +2,7 @@ category: base doc: | A neutron velocity selector type: group -NXvelocity_selector(NXobject): +NXvelocity_selector(NXcomponent): type: doc: | velocity selector type @@ -50,50 +50,26 @@ NXvelocity_selector(NXobject): unit: NX_WAVELENGTH doc: | deviation FWHM /Wavelength - (NXgeometry)geometry: + geometry(NXgeometry): deprecated: | Use the field `depends_on` and :ref:`NXtransformations` to position the velocity selector and NXoff_geometry to describe its shape instead (NXoff_geometry): exists: ['min', '0'] doc: | This group describes the shape of the beam line component - \@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 velocity selector. - (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 ++++++++++++++++++++++++++++++++++ -# 61472a40691792e17964faecd4c6ebba73b460c2519fe2b0a97f7d46e51d6c08 +# 2a3afd5347ab478f1b83c219fa3dc922333d80c70158591334188de84945d561 # # # - - - 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/contributed_definitions/NXafm.nxdl.xml b/contributed_definitions/NXafm.nxdl.xml index 9bf4dec316..6072a7c99b 100644 --- a/contributed_definitions/NXafm.nxdl.xml +++ b/contributed_definitions/NXafm.nxdl.xml @@ -23,13 +23,13 @@ --> - An application definition to describe atomic force microscopy (AFM) scanning - technique. + An application definition to describe atomic force microscopy (AFM) scanning + technique. - Name of the definition that is used for the application. + Name of the definition that is used for the application. @@ -37,7 +37,7 @@ - The mode of the scan. + The mode of the scan. @@ -49,49 +49,49 @@ - The group explains the core instruments' setup of the AFM experiment as well as the environment of the corresponding - instruments. + The group explains the core instruments' setup of the AFM experiment as well as the environment of the corresponding + instruments. - Information about the quadrant photodiode deflection detector. + Information about the quadrant photodiode deflection detector. - The cantilever information. - - Generally speaking, the cantilever resembles a leaf spring, which behaves as a simple harmonic oscillator. - When the probe (tip or particle) on the end of the cantilever is close to the surface of the sample, - an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. - The detector (typically a light pointer hitting a quadrant photodiode) measures this deformation and, therefore, - the force acting on the cantilever. - In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting - on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of - this loop controls the vertical position of the cantilever. + The cantilever information. + + Generally speaking, the cantilever resembles a leaf spring, which behaves as a simple harmonic oscillator. + When the probe (tip or particle) on the end of the cantilever is close to the surface of the sample, + an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. + The detector (typically a light pointer hitting a quadrant photodiode) measures this deformation and, therefore, + the force acting on the cantilever. + In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting + on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of + this loop controls the vertical position of the cantilever. - When a cantilever is oscillated close to its resonance, this describes the oscillator properties. - - A cantilever can be used in direct contact mode to detect interaction forces or oscillated close to its - resonance frequency. Changes in the oscillation amplitude, phase (between oscillated tail and moving tip) - or resonance frequency are very sensitive to changes in the interction potential field, giving rise of - various measurement modes, such as non-contact or intermittent-contact (tapping) modes. + When a cantilever is oscillated close to its resonance, this describes the oscillator properties. + + A cantilever can be used in direct contact mode to detect interaction forces or oscillated close to its + resonance frequency. Changes in the oscillation amplitude, phase (between oscillated tail and moving tip) + or resonance frequency are very sensitive to changes in the interction potential field, giving rise of + various measurement modes, such as non-contact or intermittent-contact (tapping) modes. - The threshold voltage for oscillator excitation. + The threshold voltage for oscillator excitation. - Phase locked loop for cantilever lock-in device. + Phase locked loop for cantilever lock-in device. - The reference amplitude (also called drive amplitude) of the cantilever. + The reference amplitude (also called drive amplitude) of the cantilever. @@ -99,73 +99,84 @@ - The environment information. + The environment information. - Link to the group ENTRY[entry]/experiment_instrument/height_piezo_sensor. + Link to the group ENTRY[entry]/experiment_instrument/height_piezo_sensor. - + - Link to the group ENTRY[entry]/experiment_instrument/XY_piezo_sensor. + Link to the group ENTRY[entry]/experiment_instrument/XY_piezo_sensor. - Link to the group ENTRY[entry]/experiment_instrument/cantilever_temperature. + Link to the group ENTRY[entry]/experiment_instrument/cantilever_temperature. - The sensor information for the height piezo device. + The sensor information for the height piezo device. - The piezo configuration information like piezoelectric calibration and material - properties. + The piezo configuration information like piezoelectric calibration and material + properties. - The material description and properties of the piezoelectric scanner materials. + The material description and properties of the piezoelectric scanner materials. - The positioner information like the position of the tip, the position of the - sample, PID loop feedback etc. + The positioner information like the position of the tip, the position of the + sample, PID loop feedback etc. - + - The sensor information for the xy piezo device. + The sensor information for the xy piezo device. - The piezo configuration information like piezoelectric calibration and material - properties. + The piezo configuration information like piezoelectric calibration and material + properties. - The material description and properties of the piezoelectric scanner materials. + The material description and properties of the piezoelectric scanner materials. - The positioner information like the position of the end of the cantilever, the position of the - sample, PID loop feedback etc. + The positioner information like the position of the end of the cantilever, the position of the + sample, PID loop feedback etc. - The temperature of the scan environment or tip of the cantilever. + The temperature of the scan environment or tip of the cantilever. + + + The group of indicators (links to the existing fields in different groups) that measure + the reproducibility of the experiment. + + + + + The group of indicators (links to the existing fields in different groups) that + + diff --git a/contributed_definitions/NXapm.nxdl.xml b/contributed_definitions/NXapm.nxdl.xml index cd1806d70f..e7161dc8d6 100644 --- a/contributed_definitions/NXapm.nxdl.xml +++ b/contributed_definitions/NXapm.nxdl.xml @@ -24,28 +24,28 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of pulses collected in between start_time and end_time resolved by an - instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of - ions included in the reconstructed volume if the application definition is used - to store results of an already reconstructed datasets. + Number of pulses collected in between start_time and end_time resolved by an + instance of :ref:`NXevent_data_apm`. If this is not defined, p is the number of + ions included in the reconstructed volume if the application definition is used + to store results of an already reconstructed datasets. - Number of ions spatially filtered from results of the hit_finding algorithm - from which an instance of a reconstructed volume has been generated. - These ions get new identifier assigned in the process (the so-called - evaporation_identifier). This identifier must not be confused with - the pulse_identifier. + Number of ions spatially filtered from results of the hit_finding algorithm + from which an instance of a reconstructed volume has been generated. + These ions get new identifier assigned in the process (the so-called + evaporation_identifier). This identifier must not be confused with + the pulse_identifier. - Application definition for atom probe and field ion microscopy experiments. + Application definition for atom probe and field ion microscopy experiments. @@ -56,26 +56,26 @@ - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) + which was used to generate this NeXus file instance. - + - A collection of all programs and libraries which are considered relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. + A collection of all programs and libraries which are considered relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. @@ -83,54 +83,48 @@ - - - - - + - + - The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For - Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the - run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. - For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, - or the instruments at GPM in Rouen, use the identifier which matches - best conceptually to the LEAP run number. - The field does not have to be required if the information is recoverable - in the dataset which for LEAP instruments is the case (provided these - RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored as via the NXserialized group - in the hit_finding algorithm section. - - As a destructive microscopy technique, a run can be performed only once. - It is possible, however, to interrupt a run and restart data acquisition - while still using the same specimen. In this case, each evaporation run - needs to be distinguished with different run numbers. - We follow this habit of most atom probe groups. Such interrupted runs - should be stored as individual :ref:`NXentry` instances in one NeXus file. + The identifier whereby the experiment is referred to in the control software. + This is neither the specimen_name nor the identifier_experiment. For + Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the + run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. + For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, + or the instruments at GPM in Rouen, use the identifier which matches + best conceptually to the LEAP run number. + The field does not have to be required if the information is recoverable + in the dataset which for LEAP instruments is the case (provided these + RHIT or HITS files respectively are stored alongside a data artifact). + With NXapm the RHIT or HITS can be stored as via the NXnote group + in the hit_finding algorithm section. + + As a destructive microscopy technique, a run can be performed only once. + It is possible, however, to interrupt a run and restart data acquisition + while still using the same specimen. In this case, each evaporation run + needs to be distinguished with different run numbers. + We follow this habit of most atom probe groups. Such interrupted runs + should be stored as individual :ref:`NXentry` instances in one NeXus file. - Either an identifier or an alias that is human-friendly so that scientists find that experiment again. - For experiments usually this is the run_number but for simulation typically no run_numbers are issued. + Either an identifier or an alias that is human-friendly so that scientists find that experiment again. + For experiments usually this is the run_number but for simulation typically no run_numbers are issued. - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn in how far the + current base classes need extension based on user feedback. - ISO 8601 time code with local time zone offset to UTC information - included when the atom probe session started. If the exact duration of - the measurement is not relevant start_time only should be used. - - Often though it is useful to specify both start_time and end_time to - capture more detailed bookkeeping of the experiment. The user should - be aware that even with having both dates specified, it may not be - possible to infer how long the experiment took or for how long data - were collected. - - More detailed timing data over the course of the experiment have to be - collected to compute this event chain during the experiment. For this - purpose the :ref:`NXevent_data_apm` instance should be used. + ISO 8601 time code with local time zone offset to UTC information + included when the atom probe session started. If the exact duration of + the measurement is not relevant start_time only should be used. + + Often though it is useful to specify both start_time and end_time to + capture more detailed bookkeeping of the experiment. The user should + be aware that even with having both dates specified, it may not be + possible to infer how long the experiment took or for how long data + were collected. + + More detailed timing data over the course of the experiment have to be + collected to compute this event chain during the experiment. For this + purpose the :ref:`NXevent_data_apm` instance should be used. - ISO 8601 time code with local time zone offset to UTC included - when the atom probe session ended. + ISO 8601 time code with local time zone offset to UTC included + when the atom probe session ended. - + - + - What type of atom probe experiment is performed? This field is meant to - inform research data management systems to allow filtering: - - * apt are experiments where the analysis_chamber has no imaging gas. - experiment with LEAP instruments are typically performed such. - * fim are experiments where the analysis_chamber has an imaging gas, - which should be specified with the atmosphere in the analysis_chamber group. - * apt_fim should be used for combinations of the two imaging modes. - few experiments of this type have been performed as this can be detrimental - to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). - * other should be used in combination with the user specifying details - in the experiment_documentation field. - - If NXapm is used for storing details about a simulation use other for now. + What type of atom probe experiment is performed? This field is meant to + inform research data management systems to allow filtering: + + * apt are experiments where the analysis_chamber has no imaging gas. + experiment with LEAP instruments are typically performed such. + * fim are experiments where the analysis_chamber has an imaging gas, + which should be specified with the atmosphere in the analysis_chamber group. + * apt_fim should be used for combinations of the two imaging modes. + few experiments of this type have been performed as this can be detrimental + to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). + * other should be used in combination with the user specifying details + in the experiment_documentation field. + + If NXapm is used for storing details about a simulation use other for now. @@ -202,34 +196,30 @@ the appdef definition here is nothing else then the documentation of this for a - - - - - + - Description of the sample from which the specimen was prepared or - site-specifically cut out using e.g. a focused-ion beam instrument. - - The sample group is currently a place for storing suggestions from - atom probers about knowledge they have gained about the sample. - There are cases where the specimen is machined further or exposed to - external stimuli during the experiment. In this case, these details should - not be stored under sample but suggestions should be made - how this application definition can be improved. - - In the future also details like how the grain_diameter was characterized, - how the sample was prepared, how the material was heat-treated etc., - should be stored. For this specific application definitions/schemas can be - used which are then arranged and documented with a description of the - workflow so that actionable graphs become instantiatable. + Description of the sample from which the specimen was prepared or + site-specifically cut out using e.g. a focused-ion beam instrument. + + The sample group is currently a place for storing suggestions from + atom probers about knowledge they have gained about the sample. + There are cases where the specimen is machined further or exposed to + external stimuli during the experiment. In this case, these details should + not be stored under sample but suggestions should be made + how this application definition can be improved. + + In the future also details like how the grain_diameter was characterized, + how the sample was prepared, how the material was heat-treated etc., + should be stored. For this specific application definitions/schemas can be + used which are then arranged and documented with a description of the + workflow so that actionable graphs become instantiatable. - A qualifier whether the sample is a real one - or a virtual one (in a computer simulation). + A qualifier whether the sample is a real one + or a virtual one (in a computer simulation). @@ -238,120 +228,114 @@ the appdef definition here is nothing else then the documentation of this for a - Given name/alias for the sample. + Given name/alias for the sample. - - - - - + - Qualitative information about the grain size, here specifically - described as the equivalent spherical diameter of an assumed - average grain size for the crystal ensemble. - Users of this information should be aware that although the grain - diameter or radius is often referred to as grain size. - - In atom probe it is possible that the specimen may contain a few - crystals only. In this case the grain_diameter is not a reliable - descriptor. Reporting a grain size may be useful though as it allows - judging if specific features are expected to be found in the - detector hit map. + Qualitative information about the grain size, here specifically + described as the equivalent spherical diameter of an assumed + average grain size for the crystal ensemble. + Users of this information should be aware that although the grain + diameter or radius is often referred to as grain size. + + In atom probe it is possible that the specimen may contain a few + crystals only. In this case the grain_diameter is not a reliable + descriptor. Reporting a grain size may be useful though as it allows + judging if specific features are expected to be found in the + detector hit map. - Magnitude of the standard deviation of the grain_diameter. + Magnitude of the standard deviation of the grain_diameter. - + - The temperature of the last heat treatment step before quenching. - Knowledge about this value can give an idea how the sample - was heat treated. However, if a documentation of the annealing - treatment as a function of time is available one should better - rely on this information and have it stored alongside the NeXus file. + The temperature of the last heat treatment step before quenching. + Knowledge about this value can give an idea how the sample + was heat treated. However, if a documentation of the annealing + treatment as a function of time is available one should better + rely on this information and have it stored alongside the NeXus file. - Magnitude of the standard deviation of the heat_treatment_temperature. + Magnitude of the standard deviation of the heat_treatment_temperature. - Rate of the last quenching step. Knowledge about this value can give - an idea how the sample was heat treated. However, there are many - situations where one can imagine that the scalar value for just the - quenching rate is insufficient. - - An example is when the sample was left in the furnace after the - furnace was switched off. In this case the sample cools down with - a specific rate of how this furnace cools down in the lab. - Processes which in practice are often not documented. - - This can be problematic though because when the furnace door was left open - or the ambient temperature in the lab changed, i.e. for a series of - experiments where one is conducted on a hot summer day and the next - during winter this can have an effect on the evolution of the microstructure. - There are many cases where this has been reported to be an QA issue in industry, - e.g. think about aging aluminium samples left on the factory - parking lot on a hot summer day. + Rate of the last quenching step. Knowledge about this value can give + an idea how the sample was heat treated. However, there are many + situations where one can imagine that the scalar value for just the + quenching rate is insufficient. + + An example is when the sample was left in the furnace after the + furnace was switched off. In this case the sample cools down with + a specific rate of how this furnace cools down in the lab. + Processes which in practice are often not documented. + + This can be problematic though because when the furnace door was left open + or the ambient temperature in the lab changed, i.e. for a series of + experiments where one is conducted on a hot summer day and the next + during winter this can have an effect on the evolution of the microstructure. + There are many cases where this has been reported to be an QA issue in industry, + e.g. think about aging aluminium samples left on the factory + parking lot on a hot summer day. - Magnitude of the standard deviation of the heat_treatment_quenching_rate. + Magnitude of the standard deviation of the heat_treatment_quenching_rate. - The chemical composition of the sample. Typically, it is assumed that - this more macroscopic composition is representative for the material - so that the composition of the typically substantially less voluminous - specimen probes from the more voluminous sample. + The chemical composition of the sample. Typically, it is assumed that + this more macroscopic composition is representative for the material + so that the composition of the typically substantially less voluminous + specimen probes from the more voluminous sample. - Reporting compositions as atom and weight percent yields both - dimensionless quantities but their conceptual interpretation differs. - A normalization based on atom_percent counts relative to the - total number of atoms which are of a particular type. - By contrast, weight_percent normalization factorizes in the - respective mass of the elements. Python libraries like pint are - challenged by these differences as at.-% and wt.-% are both - fractional quantities. + Reporting compositions as atom and weight percent yields both + dimensionless quantities but their conceptual interpretation differs. + A normalization based on atom_percent counts relative to the + total number of atoms which are of a particular type. + By contrast, weight_percent normalization factorizes in the + respective mass of the elements. Python libraries like pint are + challenged by these differences as at.-% and wt.-% are both + fractional quantities. - + - Human-readable name of the element (e.g. Fe). - Name has to be a symbol of an element from the periodic table. - All symbols in the set of NXion instances inside the group - chemical_composition need to be disjoint. + Human-readable name of the element (e.g. Fe). + Name has to be a symbol of an element from the periodic table. + All symbols in the set of NXion instances inside the group + chemical_composition need to be disjoint. - Composition value for the element/ion referred to under name. - The value is normalized based on normalization, i.e. composition - is either an atom or weight percent quantity. + Composition value for the element/ion referred to under name. + The value is normalized based on normalization, i.e. composition + is either an atom or weight percent quantity. - Magnitude of the standard deviation of the composition (value). + Magnitude of the standard deviation of the composition (value). @@ -360,7 +344,7 @@ schema for heat treatment - A qualifier whether the specimen is a real one or a virtual one. + A qualifier whether the specimen is a real one or a virtual one. @@ -369,138 +353,131 @@ schema for heat treatment - Given name an alias. Better use identifier and parent_identifier instead. - A single NXentry should be used only for the characterization of a single specimen. + Given name an alias. Better use identifier and parent_identifier instead. + A single NXentry should be used only for the characterization of a single specimen. - - - - - - + + - Identifier of the sample from which the specimen was cut or the string - n/a. The purpose of this field is to support functionalities for - tracking sample provenance via a research data management system. + Identifier of the sample from which the specimen was cut or the string + n/a. The purpose of this field is to support functionalities for + tracking sample provenance via a research data management system. - - - - + - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known time - the measured specimen surface was actively prepared. Ideally, this - matches the last timestamp that is mentioned in the digital resource - pointed to by parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is - especially required for environmentally sensitive material such as - hydrogen charged specimens or experiments including tracers with a - short half time. Additional time stamps prior to preparation_date - should better be placed in resources which describe but which do not - pollute the description here with prose. Resolving these connected - pieces of information is considered within the responsibility of the - research data management system. + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known time + the measured specimen surface was actively prepared. Ideally, this + matches the last timestamp that is mentioned in the digital resource + pointed to by parent_identifier. + + Knowing when the specimen was exposed to e.g. specific atmosphere is + especially required for environmentally sensitive material such as + hydrogen charged specimens or experiments including tracers with a + short half time. Additional time stamps prior to preparation_date + should better be placed in resources which describe but which do not + pollute the description here with prose. Resolving these connected + pieces of information is considered within the responsibility of the + research data management system. - List of comma-separated elements from the periodic table that are - contained in the specimen. If the specimen substance has multiple - components, all elements from each component must be included in - `atom_types`. - - The purpose of the field is to offer research data management systems an - opportunity to parse the relevant elements without having to interpret - these from the resources pointed to by parent_identifier or walk through - eventually deeply nested groups in data instances. + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by parent_identifier or walk through + eventually deeply nested groups in data instances. - Discouraged free-text field. + Discouraged free-text field. - Report if the specimen is polycrystalline, in which case it - contains a grain or phase boundary, or if the specimen is a - single crystal. + Report if the specimen is polycrystalline, in which case it + contains a grain or phase boundary, or if the specimen is a + single crystal. - Report if the specimen is amorphous. + Report if the specimen is amorphous. - Ideally measured otherwise best elaborated guess of the initial radius of the - specimen. + Ideally measured otherwise best elaborated guess of the initial radius of the + specimen. - Ideally measured otherwise best elaborated guess of the (initial) shank angle. - This is a measure of the specimen taper. Define it in such a way that the base of the specimen - is modelled as a conical frustrum so that the shank angle is the (shortest) angle between - the specimen space z-axis and a vector on the lateral surface of the cone. + Ideally measured otherwise best elaborated guess of the (initial) shank angle. + This is a measure of the specimen taper. Define it in such a way that the base of the specimen + is modelled as a conical frustrum so that the shank angle is the (shortest) angle between + the specimen space z-axis and a vector on the lateral surface of the cone. - Set to hold different coordinate systems conventions. - Inspect the description of the :ref:`NXcoordinate_system_set` - and :ref:`NXcoordinate_system` base classes how to define - coordinate systems in NeXus. Specific details for application - in atom probe microscopy follow. - - In this research field scientists usually distinguish several - Euclidean coordinate systems (CS): - - * World space; - a CS specifying a local coordinate system of the planet earth which - identifies into which direction gravity is pointing such that - the laboratory space CS can be rotated into this world CS. - * The laboratory space; - a CS specifying the room where the instrument is located in or - a physical landmark on the instrument, e.g. the direction of the - transfer rod where positive is the direction how the rod - has to be pushed during loading a specimen into the instrument. - In summary, this CS is defined by the chassis of the instrument. - * The specimen space; - a CS affixed to either the base or the initial apex of the specimen, - whose z axis points towards the detector. - * The detector space; - a CS affixed to the detector plane whose xy plane is usually in the - detector and whose z axis points towards the specimen. - This is a distorted space with respect to the reconstructed ion - positions. - * The reconstruction space; - a CS in which the reconstructed ion positions are defined. - The orientation depends on the analysis software used. - * Eventually further coordinate systems attached to the - flight path of individual ions might be defined. - - In atom probe microscopy a frequently used choice for the detector - space (CS) is discussed with the so-called detector space image - (stack). This is a stack of two-dimensional histograms of detected ions - within a predefined evaporation identifier interval. Typically, the set of - ion evaporation sequence IDs is grouped into chunks. - - For each chunk a histogram of the ion hit positions on the detector - is computed. This leaves the possibility for inconsistency between - the so-called detector space and the e.g. specimen space. - - To avoid these ambiguities, instances of :ref:`NXtransformations` should - be used. + Set to hold different coordinate systems conventions. + Inspect the description of the :ref:`NXcoordinate_system_set` + and :ref:`NXcoordinate_system` base classes how to define + coordinate systems in NeXus. Specific details for application + in atom probe microscopy follow. + + In this research field scientists usually distinguish several + Euclidean coordinate systems (CS): + + * World space; + a CS specifying a local coordinate system of the planet earth which + identifies into which direction gravity is pointing such that + the laboratory space CS can be rotated into this world CS. + * The laboratory space; + a CS specifying the room where the instrument is located in or + a physical landmark on the instrument, e.g. the direction of the + transfer rod where positive is the direction how the rod + has to be pushed during loading a specimen into the instrument. + In summary, this CS is defined by the chassis of the instrument. + * The specimen space; + a CS affixed to either the base or the initial apex of the specimen, + whose z axis points towards the detector. + * The detector space; + a CS affixed to the detector plane whose xy plane is usually in the + detector and whose z axis points towards the specimen. + This is a distorted space with respect to the reconstructed ion + positions. + * The reconstruction space; + a CS in which the reconstructed ion positions are defined. + The orientation depends on the analysis software used. + * Eventually further coordinate systems attached to the + flight path of individual ions might be defined. + + In atom probe microscopy a frequently used choice for the detector + space (CS) is discussed with the so-called detector space image + (stack). This is a stack of two-dimensional histograms of detected ions + within a predefined evaporation identifier interval. Typically, the set of + ion evaporation sequence IDs is grouped into chunks. + + For each chunk a histogram of the ion hit positions on the detector + is computed. This leaves the possibility for inconsistency between + the so-called detector space and the e.g. specimen space. + + To avoid these ambiguities, instances of :ref:`NXtransformations` should + be used. @@ -518,7 +495,7 @@ schema for heat treatment - + @@ -548,14 +525,14 @@ schema for heat treatment - + - The wavelength of the radiation emitted by the source. + The wavelength of the radiation emitted by the source. @@ -565,8 +542,8 @@ stage_lab(NXstage_lab):--> - The space inside the atom probe along which ions pass nominally - when they leave the specimen and travel to the detector. + The space inside the atom probe along which ions pass nominally + when they leave the specimen and travel to the detector. @@ -652,8 +629,8 @@ turbomolecular_pump(NXpump):--> - A region-of-interest analyzed either during or after the session for which - specific processed data of the measured or simulated data are available. + A region-of-interest analyzed either during or after the session for which + specific processed data of the measured or simulated data are available. - SEM or TEM image of the initial specimen i.e. - ideally taken prior to the data acquisition. + SEM or TEM image of the initial specimen i.e. + ideally taken prior to the data acquisition. - + @@ -692,15 +669,15 @@ NEW ISSUE: make this rather an own subentry NXapm_ranging--> a time series of the specimen shape evolution--> - + - + - + @@ -712,15 +689,15 @@ does not have to be exposed (although this clearly is against FAIR principles bu is does not have the authority to decide which portions of proprietary code have to be public we can only make recommendations--> - + - + - + @@ -728,7 +705,7 @@ we can only make recommendations--> - + @@ -747,56 +724,56 @@ we can only make recommendations--> - + - + - + - + - Integer used to name the first pulse to know if there is an - offset of the evaporation_identifier to zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. + Integer used to name the first pulse to know if there is an + offset of the identifier_evaporation to zero. + + Identifiers can be defined either implicitly or explicitly. + For implicit indexing identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + + Therefore, implicit identifier are completely defined by the value of + identifier_offset and cardinality. For example if identifier run from + -2 to 3 the value for identifier_offset is -2. + + For explicit indexing the field identifier has to be used. + Fortran-/Matlab- and C-/Python-style indexing have specific implicit + identifier conventions where identifier_offset is 1 and 0 respectively. - + - (Molecular) ion identifier which resolves the sequence in which - the ions were evaporated but taking into account that a hit_finding - and spatial_filtering was applied. + (Molecular) ion identifier which resolves the sequence in which + the ions were evaporated but taking into account that a hit_finding + and spatial_filtering was applied. @@ -813,14 +790,14 @@ i number of hits after hits finding but prior calibrations--> - + - + - + @@ -843,14 +820,14 @@ Relevant for ranging are the calibrated data, thats why only these - + - + - + @@ -864,40 +841,40 @@ results--> - + - + - For LEAP and IVAS/APSuite-based analyses root file which stores - the settings whereby an RHIT/HITS file can be used to regenerate the - reconstruction that is here referred to. - - The respective RHIT/HITS file should ideally be specified in the serialized - group of the hit_finding section of this application definition. + For LEAP and IVAS/APSuite-based analyses root file which stores + the settings whereby an RHIT/HITS file can be used to regenerate the + reconstruction that is here referred to. + + The respective RHIT/HITS file should ideally be specified in the serialized + group of the hit_finding section of this application definition. - + - + - For LEAP and IVAS/APSuite-based analyses the resulting typically - file with the reconstructed positions and (calibrated) mass-to-charge - state ratio values. - - For other data collection/analysis software the data artifact which comes - closest conceptually to AMETEK/Cameca's typical file formats. - - These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, - which should be stored alongside this record in the research data - management system. + For LEAP and IVAS/APSuite-based analyses the resulting typically + file with the reconstructed positions and (calibrated) mass-to-charge + state ratio values. + + For other data collection/analysis software the data artifact which comes + closest conceptually to AMETEK/Cameca's typical file formats. + + These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, + which should be stored alongside this record in the research data + management system. - + @@ -913,7 +890,7 @@ results--> - + @@ -923,8 +900,8 @@ results--> - - @@ -957,17 +934,17 @@ results--> - + - + - The respective ranging definitions file RNG/RRNG/ENV/HDF5. + The respective ranging definitions file RNG/RRNG/ENV/HDF5. - + @@ -975,7 +952,7 @@ results--> - + @@ -985,7 +962,7 @@ results--> - + @@ -1004,26 +981,26 @@ results--> - + - (Out-of-sync) background levels in ppm/ns - reported by e.g. IVAS/APSuite for LEAP systems. + (Out-of-sync) background levels in ppm/ns + reported by e.g. IVAS/APSuite for LEAP systems. - MRP, mass-resolving power, `D. Larson et al. - <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). + MRP, mass-resolving power, `D. Larson et al. + <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). - MRP, at which mrp_value was specified. + MRP, at which mrp_value was specified. @@ -1033,27 +1010,27 @@ NEW ISSUE: add parameters of the background model in an e.g. work of A. London et al.--> - + - + - Category for the peak offering a qualitative statement of the location of the peak - in light of limited mass-resolving power that is relevant for - composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ - for examples of each category: - - * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` - * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` - * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states - * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` - * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` - * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` + Category for the peak offering a qualitative statement of the location of the peak + in light of limited mass-resolving power that is relevant for + composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ + for examples of each category: + + * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` + * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` + * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states + * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` + * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` + * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` @@ -1070,12 +1047,12 @@ in an e.g. work of A. London et al.--> - + - + diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml index 9469d79ce9..7e12763db9 100644 --- a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -40,9 +40,8 @@ - - + Specification of the tomographic reconstruction used for this analysis. Typically, reconstructions in the field of atom probe tomography are communicated via @@ -68,7 +67,7 @@ - + Specification of the ranging definitions used for this analysis. @@ -76,7 +75,7 @@ iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. - + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml index d702a29f5e..765c369193 100644 --- a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -24,32 +24,32 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality of the grid. + The dimensionality of the grid. - Total number of voxels. + Total number of voxels. - Total number of ions in the reconstructed dataset. + Total number of ions in the reconstructed dataset. - Application definition for results of the CompositionSpace tool used in atom probe. - - * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ - - This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure - use case IUC09 that explores how to improve the organization and results storage of the - CompositionSpace software using NeXus. + Application definition for results of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ + + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace software using NeXus. @@ -61,18 +61,17 @@ - + - - + - Configuration file that was used in this analysis. + Configuration file that was used in this analysis. @@ -83,13 +82,13 @@ for if desired all the dependencies and libraries--> - Step during which the point cloud is discretized to compute element-specific composition fields. - Iontypes are atomically decomposed to correctly account for the multiplicity of each element that - was ranged for each ion. - - Using a discretization grid that is larger than the average distance between reconstructed ion positions - reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods - used in atom probe for characterizing microstructural features using the ion position data directly. + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + Using a discretization grid that is larger than the average distance between reconstructed ion positions + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods + used in atom probe for characterizing microstructural features using the ion position data directly. @@ -126,7 +125,7 @@ for if desired all the dependencies and libraries--> - Position of each cell in Euclidean space. + Position of each cell in Euclidean space. @@ -135,7 +134,7 @@ for if desired all the dependencies and libraries--> - Discrete coordinate of each voxel. + Discrete coordinate of each voxel. @@ -145,7 +144,7 @@ for if desired all the dependencies and libraries--> - For each ion, the identifier of the voxel into which the ion binned. + For each ion, the identifier of the voxel into which the ion binned. @@ -154,23 +153,23 @@ for if desired all the dependencies and libraries--> - Total number of weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms. + Total number of weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms. - + - Chemical symbol of the element from the periodic table. + Chemical symbol of the element from the periodic table. - Element-specific weight (counts for discretization with a rectangular transfer function) - for the occupancy of each voxel with atoms of this element. + Element-specific weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms of this element. @@ -180,8 +179,8 @@ for if desired all the dependencies and libraries--> - Optional step during which the subsequent segmentation step is prepared to - improve the segmentation. + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. @@ -191,32 +190,32 @@ for if desired all the dependencies and libraries--> - + - Element identifier stored sorted in descending order of feature importance. + Element identifier stored sorted in descending order of feature importance. - Axis caption + Axis caption - Element relative feature importance stored sorted in descending order of feature - importance. + Element relative feature importance stored sorted in descending order of feature + importance. - Axis caption + Axis caption @@ -224,12 +223,12 @@ for if desired all the dependencies and libraries--> - Step during which the voxel set is segmented into voxel sets with different - chemical composition. + Step during which the voxel set is segmented into voxel sets with different + chemical composition. - PCA in the chemical space (essentially composition correlation analyses). + PCA in the chemical space (essentially composition correlation analyses). @@ -240,11 +239,11 @@ for if desired all the dependencies and libraries--> - + - Explained variance values + Explained variance values @@ -252,8 +251,8 @@ for if desired all the dependencies and libraries--> - Elements identifier matching those from ENTRY/voxelization/elementID as the - principal component analysis. + Elements identifier matching those from ENTRY/voxelization/elementID as the + principal component analysis. @@ -263,7 +262,7 @@ for if desired all the dependencies and libraries--> - Information criterion minimization. + Information criterion minimization. @@ -271,18 +270,18 @@ for if desired all the dependencies and libraries--> - + - Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. - n_components argument of the Gaussian mixture model. + n_components argument of the Gaussian mixture model. - y_pred return values of the computation. + y_pred return values of the computation. @@ -291,15 +290,15 @@ for if desired all the dependencies and libraries--> - Information criterion as a function of number of n_ic_cluster aka dimensions. + Information criterion as a function of number of n_ic_cluster aka dimensions. - + - Akaike information criterion values + Akaike information criterion values @@ -307,7 +306,7 @@ for if desired all the dependencies and libraries--> - Bayes information criterion values + Bayes information criterion values @@ -315,7 +314,7 @@ for if desired all the dependencies and libraries--> - Actual n_ic_cluster values used + Actual n_ic_cluster values used @@ -326,9 +325,9 @@ for if desired all the dependencies and libraries--> - Step during which the chemically segmented voxel sets are analyzed for their spatial organization - into different spatial clusters of voxels in the same chemical set but representing individual object - not-necessarily watertight or topologically closed objects built from individual voxels. + Step during which the chemically segmented voxel sets are analyzed for their spatial organization + into different spatial clusters of voxels in the same chemical set but representing individual object + not-necessarily watertight or topologically closed objects built from individual voxels. @@ -338,25 +337,25 @@ for if desired all the dependencies and libraries--> - Respective DBScan clustering result for each segmentation/ic_opt case. + Respective DBScan clustering result for each segmentation/ic_opt case. - - + + - The maximum distance between voxel pairs in a neighborhood to be considered - connected. + The maximum distance between voxel pairs in a neighborhood to be considered + connected. - The number of voxels in a neighborhood for a voxel to be considered as a core - point. + The number of voxels in a neighborhood for a voxel to be considered as a core + point. - Raw label return values + Raw label return values @@ -364,10 +363,10 @@ for if desired all the dependencies and libraries--> - Voxel identifier - - Using these identifiers correlated element-wise with the values in the label array - specifies for which voxel in the grid clusters from this process were found. + Voxel identifier + + Using these identifiers correlated element-wise with the values in the label array + specifies for which voxel in the grid clusters from this process were found. diff --git a/contributed_definitions/NXapm_hit_finding.nxdl.xml b/contributed_definitions/NXapm_hit_finding.nxdl.xml index a897e5ce72..5f1a1aa5b0 100644 --- a/contributed_definitions/NXapm_hit_finding.nxdl.xml +++ b/contributed_definitions/NXapm_hit_finding.nxdl.xml @@ -49,7 +49,7 @@ Base class for the configuration and results from a hit finding algorithm. - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml index 32eb034ab6..04f21d75fe 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -70,7 +70,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> a binary file that is formatted like a POS file but cluster labels written out using floating point numbers. - + @@ -78,7 +78,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> - + File with the results of the cluster analyses that was computed with IVAS / AP suite (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). @@ -95,7 +95,7 @@ n_disjoint_clusters: Number of disjoint cluster.--> Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction - for recovering for each position in the :ref:`NXserialized` results the closest matching position + for recovering for each position in the :ref:`NXnote` results the closest matching position (within floating point accuracy). This can be useful when users wish to recover the original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster results POS files that is referred to results. @@ -109,12 +109,12 @@ doc: | in dataset/dataset/dataset_name_reconstruction where covered by the IVAS/APSuite cluster analysis. This can be useful to recover the region of interest.--> - + This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - + @@ -122,14 +122,14 @@ doc: | - + - + Distance between each ion and triangulated surface mesh. @@ -368,7 +368,7 @@ optics(NXprocess): e.g. https://doi.org/10.1017/S1431927607070900--> - + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml index ee9fe6ba4c..b3d24ca198 100644 --- a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -51,9 +51,9 @@ - + - + @@ -65,7 +65,7 @@ - + Results of a DBScan clustering analysis. @@ -253,7 +253,7 @@ number_of_objects(NX_UINT): - + @@ -267,7 +267,7 @@ number_of_objects(NX_UINT): - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml index b734a98444..e44c9f05ec 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -40,9 +40,8 @@ - - + @@ -50,7 +49,7 @@ - + @@ -135,7 +134,7 @@ composed into one joint triangle set for the analysis. - + Each triangle_set that is referred to here should be a face_list_data_structure, i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) @@ -186,7 +185,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml index 243a7bf93c..94770eb0e9 100644 --- a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -24,33 +24,33 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The total number of points, i.e. ions in the reconstruction. + The total number of points, i.e. ions in the reconstruction. - The total number of triangles in the set. + The total number of triangles in the set. - Application definition for results files of the paraprobe-distancer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each - member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the - distance is computed as the projected distance, this tool evaluates robustly the exact distance between - a point and a triangle. - - Triangles can represent for instance the facets of a triangulated surface mesh like those returned by - paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. - - Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, - what their topology is, or whether or not these triangles are consistently oriented. + Application definition for results files of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each + member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the + distance is computed as the projected distance, this tool evaluates robustly the exact distance between + a point and a triangle. + + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by + paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. + + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, + what their topology is, or whether or not these triangles are consistently oriented. @@ -63,7 +63,7 @@ - + @@ -77,8 +77,8 @@ - The shortest analytical distance of each point to their - respectively closest triangle from the joint triangle set. + The shortest analytical distance of each point to their + respectively closest triangle from the joint triangle set. @@ -86,8 +86,8 @@ - For each point the identifier of the triangle for which the - shortest distance was found + For each point the identifier of the triangle for which the + shortest distance was found @@ -95,10 +95,10 @@ - A support field to enable the visualization of each point - by an explicit identifier on the interval [0, n_ions - 1]. - The field can be used to visualize the points as a function - of their distance to the triangle set (e.g. via XDMF/Paraview). + A support field to enable the visualization of each point + by an explicit identifier on the interval [0, n_ions - 1]. + The field can be used to visualize the points as a function + of their distance to the triangle set (e.g. via XDMF/Paraview). @@ -106,30 +106,30 @@ - A bitmask that identifies which of the distance values is - assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - - For points whose bit is set to 0 the distance is correct - but the sign is not reliable. + A bitmask that identifies which of the distance values is + assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + + For points whose bit is set to 0 the distance is correct + but the sign is not reliable. - Number of triangles covered by the mask. + Number of triangles covered by the mask. - Bitdepth of the elementary datatype that is used to store - the information content of the mask (typically 8 bit, uint8). + Bitdepth of the elementary datatype that is used to store + the information content of the mask (typically 8 bit, uint8). - The content of the mask. Like for all masks used in the tools - of the paraprobe-toolbox, padding is used when number_of_objects - is not an integer multiple of bitdepth. If padding is used, - padded bits are set to 0. + The content of the mask. Like for all masks used in the tools + of the paraprobe-toolbox, padding is used when number_of_objects + is not an integer multiple of bitdepth. If padding is used, + padded bits are set to 0. @@ -138,8 +138,8 @@ - A bitmask that identifies which of the triangles in the set were - considered when certain triangles have been filtered out. + A bitmask that identifies which of the triangles in the set were + considered when certain triangles have been filtered out. @@ -156,7 +156,7 @@ triangles in this case--> - + @@ -170,9 +170,9 @@ triangles in this case--> - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml index 8b32a2d79c..aa3672d432 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -24,18 +24,18 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of entries + Number of entries - Application definition for a configuration file of the paraprobe-intersector tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -46,38 +46,38 @@ - How many v_v_spatial_correlation tasks should the tool execute. + How many v_v_spatial_correlation tasks should the tool execute. - + - Tracking volume_volume_spatial_correlations (v_v) is the process of building logical - relations between objects, their proximity and eventual volumetric intersections. - Here, objects are assumed to be represented as a set of triangulated surface meshes. - - Volumetric overlap and proximity of volumetric features is identified for members of - sets of features to members of other sets of volumetric features. Specifically, for each time - step :math:`k` pairs of sets are compared: - Members of a so-called current_set to members of a so-called next_set. - Members can be different types of volumetric features. + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical + relations between objects, their proximity and eventual volumetric intersections. + Here, objects are assumed to be represented as a set of triangulated surface meshes. + + Volumetric overlap and proximity of volumetric features is identified for members of + sets of features to members of other sets of volumetric features. Specifically, for each time + step :math:`k` pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. - Specifies the method whereby to decide if two objects intersect volumetrically. - For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, - it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). - - Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to - tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra - to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner - cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. - These cases were virtually always associated with complicated non-convex polyhedra which had portions - of the mesh that were connected by almost point like tubes of triangles. - - Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve - the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron - intersections in paraprobe-intersector. + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, + it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). + + Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra + to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner + cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. + These cases were virtually always associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + + Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve + the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron + intersections in paraprobe-intersector. @@ -85,81 +85,81 @@ - Specifies if the tool evaluates if objects intersect volumetrically. + Specifies if the tool evaluates if objects intersect volumetrically. - Specifies if the tool evaluates if objects lay closer to one another than - threshold_proximity. + Specifies if the tool evaluates if objects lay closer to one another than + threshold_proximity. - Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting - or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ - for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order local groups. + Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting + or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ + for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order local groups. - The maximum Euclidean distance between two objects below which they are - considered within proximity. + The maximum Euclidean distance between two objects below which they are + considered within proximity. - Specifies if the tool stores the so-called forward relations between nodes representing members of the - current_set to nodes representing members of the next_set. + Specifies if the tool stores the so-called forward relations between nodes representing members of the + current_set to nodes representing members of the next_set. - Specifies if the tool stores the so-called backward relations between nodes representing members of the - next_set to nodes representing members of the current_set. + Specifies if the tool stores the so-called backward relations between nodes representing members of the + next_set to nodes representing members of the current_set. - Current set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the current_set. - The meshes were generated as a result of some other meshing process. + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features, key is that they were all generated for one set, here the - current_set. + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features, key is that they were all generated for one set, here the + current_set. - + - Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the - members of the set as instances of NXcg_polyhedron_set. + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the + members of the set as instances of NXcg_polyhedron_set. - Descriptive category explaining what these features are. + Descriptive category explaining what these features are. @@ -175,15 +175,15 @@ - Absolute path to the group with geometry data in the HDF5 file referred to by - path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. - Array of identifier whereby the path to the geometry data can be interferred - automatically. + Array of identifier whereby the path to the geometry data can be interferred + automatically. @@ -193,39 +193,39 @@ - Next set stores a set of members, meshes of volumetric features, - which will be checked for proximity and/or volumetric intersection, - to members of the next_set. - The meshes were generated as a result of some other meshing process. + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. - This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) - step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). - The total number of distinguished feature sets featureID. - It is assumed that the members within all these featureID sets - are representing a set together. As an example this set might represent - all volumetric_features. However, users might have formed - a subset of this set where individuals were regrouped. - For paraprobe-nanochem this is the case for objects and proxies. - Specifically, objects are distinguished further into those far - from and those close to the edge of the dataset. - Similarly, proxies are distinguished further into those far - from and those close to the edge of the dataset. - So while these four sub-sets contain different so-called types of - features key is that they were all generated for one set, here the - next_set. + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. - + - Descriptive category explaining what these features are. + Descriptive category explaining what these features are. @@ -240,15 +240,15 @@ - Absolute path to the group with geometry data in the HDF5 file referred to by - path. + Absolute path to the group with geometry data in the HDF5 file referred to by + path. - Array of identifier whereby the path to the geometry data can be interferred - automatically. + Array of identifier whereby the path to the geometry data can be interferred + automatically. @@ -257,12 +257,12 @@ - - + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml index 7927598112..6375b5705a 100644 --- a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -222,13 +222,13 @@ - + - + - + @@ -242,7 +242,7 @@ - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml index d3b3c5c503..1b8d4d8732 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -96,9 +96,8 @@ - - + @@ -106,14 +105,14 @@ - + - + A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control @@ -136,7 +135,7 @@ - + Distance between each ion and triangulated surface mesh. @@ -204,7 +203,7 @@ identifier(NX_UINT):--> - + Serialized result of an already computed delocalization which is for performance reasons here just loaded and not computed again. @@ -560,9 +559,8 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> paraprobe-nanochem uses inspection functionalities which detect potential geometric inconsistencies or self-interactions of the evolved DCOM mesh. - - + @@ -570,14 +568,14 @@ NEW ISSUE: here we need to specify how the meshes were smoothened--> - + - + A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control @@ -667,7 +665,7 @@ identifier(NX_UINT):--> - + Details about the control point file used. @@ -789,9 +787,8 @@ identifier(NX_UINT):--> intersection of triangles and convex polyhedra is a robust but currently not implemented method to quantify intersections. - - + @@ -799,14 +796,14 @@ identifier(NX_UINT):--> - + - + A precomputed triangulated surface mesh representing a model (of the surface) of the edge of the dataset. This model can be used to detect and control @@ -829,7 +826,7 @@ identifier(NX_UINT):--> - + Distance between each ion and triangulated surface mesh. @@ -845,7 +842,7 @@ identifier(NX_UINT):--> - + A precomputed triangulated mesh of the feature representing a model of the interface at which to place ROIs to profile. This can be the mesh of an @@ -891,7 +888,7 @@ from normals of neighboring facets, type of weighting schemes can affect results - + To enable an additional filtration of specific parts of the feature mesh it is recommended to feed precomputed distances of each ion to @@ -1024,7 +1021,7 @@ but cylinders are most frequently used--> - + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml index ea407ba65c..0d9cc93919 100644 --- a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -24,70 +24,70 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The total number of ions in the reconstruction. + The total number of ions in the reconstruction. - The total number of atoms in the atomic_decomposition match filter. + The total number of atoms in the atomic_decomposition match filter. - The total number of isotopes in the isotopic_decomposition match filter. + The total number of isotopes in the isotopic_decomposition match filter. - The dimensionality of the delocalization grid. + The dimensionality of the delocalization grid. - The cardinality/total number of cells/grid points in the delocalization grid. + The cardinality/total number of cells/grid points in the delocalization grid. - The total number of faces of triangles. + The total number of faces of triangles. - The total number of XDMF values to represent all faces of triangles via XDMF. + The total number of XDMF values to represent all faces of triangles via XDMF. - The total number of entries in a feature dictionary. + The total number of entries in a feature dictionary. - The total number of volumetric features. + The total number of volumetric features. - The total number of member distinguished when reporting composition. + The total number of member distinguished when reporting composition. - The total number of ROIs placed in an oned_profile task. + The total number of ROIs placed in an oned_profile task. - Application definition for results files of the paraprobe-nanochem tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + Application definition for results files of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -97,7 +97,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -111,11 +111,11 @@ The cardinality/total number of triangles in the triangle soup.--> - How were results of the kernel-density estimation normalized: - * total, the total number (intensity) of ions or elements. - * candidates, the total number (intensity) of ions matching weighting_model - * composition, the value for candidates divided by the value for total, - * concentration, the value for candidates divided by the volume of the cell. + How were results of the kernel-density estimation normalized: + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. @@ -126,7 +126,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The discretized domain/grid on which the delocalization is applied. + The discretized domain/grid on which the delocalization is applied. @@ -137,7 +137,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The total number of cells/voxels of the grid. + The total number of cells/voxels of the grid. @@ -147,7 +147,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The symmetry of the lattice defining the shape of the unit cell. + The symmetry of the lattice defining the shape of the unit cell. @@ -155,8 +155,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The unit cell dimensions according to the coordinate system defined under - coordinate_system. + The unit cell dimensions according to the coordinate system defined under + coordinate_system. @@ -164,12 +164,12 @@ The cardinality/total number of triangles in the triangle soup.--> - Number of unit cells along each of the d-dimensional base vectors. - The total number of cells, or grid points has to be the cardinality. - If the grid has an irregular number of grid positions in each direction, - as it could be for instance the case of a grid where all grid points - outside some masking primitive are removed, this extent field should - not be used. Instead use the coordinate field. + Number of unit cells along each of the d-dimensional base vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. @@ -178,17 +178,17 @@ The cardinality/total number of triangles in the triangle soup.--> - Integer which specifies the first index to be used for distinguishing identifiers for cells. - Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are - defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. - Halfwidth of the kernel about the central voxel. - The shape of the kernel is that of a cuboid - of extent 2*kernel_extent[i] + 1 in each dimension i. + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. @@ -196,7 +196,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Functional form of the kernel (Ansatz function). + Functional form of the kernel (Ansatz function). @@ -204,8 +204,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Standard deviation :math:`\sigma_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + Standard deviation :math:`\sigma_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. @@ -213,8 +213,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Expectation value :math:`\mu_i` of the kernel in each dimension - in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + Expectation value :math:`\mu_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. @@ -222,51 +222,51 @@ The cardinality/total number of triangles in the triangle soup.--> - A tight axis-aligned bounding box about the grid. + A tight axis-aligned bounding box about the grid. - For atom probe should be set to true. + For atom probe should be set to true. - Integer which specifies the first index to be used for distinguishing - hexahedra. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. - For explicit indexing the identifier array has to be defined. + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. - Integer which specifies the first index to be used for distinguishing - identifiers for vertices. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. - Integer which specifies the first index to be used for distinguishing - identifiers for faces. Identifiers are defined either implicitly or explicitly. - For implicit indexing the identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array - has to be defined. + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. - Positions of the vertices. - Users are encouraged to reduce the vertices to unique set of positions - and vertices as this supports a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. - Naively here means that one for example stores each vertex of a triangle - mesh even though many vertices are shared between triangles and thus - the positions of these vertices do not have to be duplicated. + Positions of the vertices. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. @@ -275,16 +275,16 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -293,10 +293,10 @@ The cardinality/total number of triangles in the triangle soup.--> - Six equally formatted sextets chained together. For each sextett the first entry is an - XDMF primitive topology key (here 5 for polygon), the second entry the XDMF - primitive count value (here 4 because each face is a quad). - The remaining four values are the vertex indices. + Six equally formatted sextets chained together. For each sextett the first entry is an + XDMF primitive topology key (here 5 for polygon), the second entry the XDMF + primitive count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. @@ -304,15 +304,15 @@ The cardinality/total number of triangles in the triangle soup.--> - How many distinct boundaries are distinguished? - Most grids discretize a cubic or cuboidal region. In this case - six sides can be distinguished, each making an own boundary. + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. - Name of the boundaries. E.g. left, right, front, back, bottom, top, - The field must have as many entries as there are number_of_boundaries. + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. @@ -320,14 +320,14 @@ The cardinality/total number of triangles in the triangle soup.--> - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet @@ -335,20 +335,20 @@ The cardinality/total number of triangles in the triangle soup.--> - - + + - The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces - will be computed. In commercial software so far there is no possibility to export this information. - - If the intensity for all matches of the weighting_model are summarized name this NXdata instance - scalar_field_magn_total. - - If the intensity is reported for each iontype one can avoid many subsequent - computations as individual intensities can be reinterpreted using a different weighting_model in - down-stream usage of the here reported values (e.g. with Python scripting). - In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as - per the configuration of the ranging definitions used. + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces + will be computed. In commercial software so far there is no possibility to export this information. + + If the intensity for all matches of the weighting_model are summarized name this NXdata instance + scalar_field_magn_total. + + If the intensity is reported for each iontype one can avoid many subsequent + computations as individual intensities can be reinterpreted using a different weighting_model in + down-stream usage of the here reported values (e.g. with Python scripting). + In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as + per the configuration of the ranging definitions used. @@ -358,7 +358,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The actual delocalized intensity values. + The actual delocalized intensity values. @@ -368,7 +368,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along x. + Cell center of mass positions along x. @@ -376,7 +376,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along y. + Cell center of mass positions along y. @@ -384,7 +384,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along z. + Cell center of mass positions along z. @@ -392,7 +392,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Intensity of the field at given point + Intensity of the field at given point @@ -400,8 +400,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Center of mass positions of each voxel for rendering the scalar field - via XDMF in e.g. Paraview. + Center of mass positions of each voxel for rendering the scalar field + via XDMF in e.g. Paraview. @@ -410,18 +410,18 @@ The cardinality/total number of triangles in the triangle soup.--> - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDMF in e.g. Paraview. + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. - + - The three-dimensional gradient :math:`\nabla \Phi`. - Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. + The three-dimensional gradient :math:`\nabla \Phi`. + Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. @@ -431,7 +431,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The actual point-wise component values. + The actual point-wise component values. @@ -442,7 +442,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along x. + Cell center of mass positions along x. @@ -450,7 +450,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along y. + Cell center of mass positions along y. @@ -458,7 +458,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Cell center of mass positions along z. + Cell center of mass positions along z. @@ -466,8 +466,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The gradient vector formatted for direct visualization via XDMF in e.g. - Paraview. + The gradient vector formatted for direct visualization via XDMF in e.g. + Paraview. @@ -476,8 +476,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Center of mass positions of each voxel for rendering the scalar field gradient - via XDMF in e.g. Paraview. + Center of mass positions of each voxel for rendering the scalar field gradient + via XDMF in e.g. Paraview. @@ -486,58 +486,58 @@ The cardinality/total number of triangles in the triangle soup.--> - XDMF topology for rendering in combination with xdmf_xyz the scalar field - via XDFM in e.g. Paraview. + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDFM in e.g. Paraview. - - + + - An iso-surface is the boundary between two regions across which the magnitude of a - scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. - - For applications in atom probe microscopy, the location and shape of such a boundary (set) - is typically approximated by discretization - triangulation to be specific. - - This yields a complex of not necessarily connected geometric primitives. - Paraprobe-nanochem approximates this complex with a soup of triangles. + An iso-surface is the boundary between two regions across which the magnitude of a + scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. + + For applications in atom probe microscopy, the location and shape of such a boundary (set) + is typically approximated by discretization - triangulation to be specific. + + This yields a complex of not necessarily connected geometric primitives. + Paraprobe-nanochem approximates this complex with a soup of triangles. - The threshold or iso-contour value :math:`\varphi`. + The threshold or iso-contour value :math:`\varphi`. - Details about the specific marching cubes algorithm that was used for computing - the iso-surface. + Details about the specific marching cubes algorithm that was used for computing + the iso-surface. - Reference to the specific implementation of marching cubes used. - The value placed here should be a DOI. If there are no specific - DOI or details write not_further_specified, or give at least a - free-text description. The program and version used is the - specific paraprobe-nanochem. + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. - The resulting triangle soup computed via marching cubes. + The resulting triangle soup computed via marching cubes. - Integer which specifies the first index to be used for distinguishing triangles. - Identifiers are defined either implicitly or explicitly. For implicit indexing the - identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + Integer which specifies the first index to be used for distinguishing triangles. + Identifiers are defined either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. @@ -547,13 +547,13 @@ The cardinality/total number of triangles in the triangle soup.--> - Positions of the vertices. - - Users are encouraged to reduce the vertices to a unique set as this may - result in a more efficient storage of the geometry data. - It is also possible though to store the vertex positions naively in which - case vertices_are_unique is likely False. Naively here means that each - vertex is stored even though many share the same positions. + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. @@ -562,16 +562,16 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of identifiers from vertices which describe each face. - - The first entry is the identifier of the start vertex of the first face, - followed by the second vertex of the first face, until the last vertex - of the first face. Thereafter, the start vertex of the second face, the - second vertex of the second face, and so on and so forth. - - Therefore, summating over the number_of_vertices, allows to extract - the vertex identifiers for the i-th face on the following index interval - of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. @@ -579,9 +579,9 @@ The cardinality/total number of triangles in the triangle soup.--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). @@ -590,7 +590,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Direction of each normal. + Direction of each normal. @@ -599,12 +599,12 @@ The cardinality/total number of triangles in the triangle soup.--> - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -612,11 +612,11 @@ The cardinality/total number of triangles in the triangle soup.--> +exists: optional--> - Direction of each normal. + Direction of each normal. @@ -625,12 +625,12 @@ The cardinality/total number of triangles in the triangle soup.--> - Qualifier how which specifically oriented normal to its - primitive each normal represents. - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -638,32 +638,32 @@ The cardinality/total number of triangles in the triangle soup.--> - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. +doc: | +Triangle normals are oriented in the direction of the +gradient vector of the local delocalized scalar field. +Sum of squared values of cross product of triangle normal +construction. +unit: NX_ANY +dim: (k,)--> - Triangle normals are oriented in the direction of the - gradient vector of the local delocalized scalar field. - The projection variable here describes the cosine of the - angle between the gradient direction and the normal - direction vector. - This is a descriptor of how parallel the projection is - that is especially useful to document those triangles - for whose the projection is almost perpendicular. + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose the projection is almost perpendicular. @@ -677,9 +677,9 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of edge length values. For each triangle the edge length - is reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. @@ -688,10 +688,10 @@ The cardinality/total number of triangles in the triangle soup.--> - Array of interior angle values. For each triangle the angle - is reported for the angle opposite to the edges which are - traversed according to the sequence in which vertices - are indexed in triangles. + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. @@ -700,7 +700,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The center of mass of each triangle. + The center of mass of each triangle. @@ -709,36 +709,36 @@ The cardinality/total number of triangles in the triangle soup.--> - Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. - Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a - connectivity analysis on the triangle soup representation of such iso-surface. - This may yield a set of connected features whose individual surfaces are discretized - by a triangulated mesh each. Such volumetric features can be processed further using - paraprobe-nanochem using a workflow with at most two steps. - - In the first step, the tool distinguishes three types of (v) i.e. volumetric features: - - 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. - These objects were already watertight within the triangulated iso-surface. - 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated - iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh - processing operations (hole filling, refinement, fairing operations). - 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality - that are not transformable into proxies or for which no transformation into proxies was - instructed. - - These features can be interpreted as microstructural features. Some of them may be precipitates, - some of them may be poles, some of them may be segments of dislocation lines or other - crystal defects which are decorated (or not) with solutes. - - In the second step, the tool can be used to analyze the proximity of these objects to a - model of the surface (edge) of the dataset. + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. + Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup representation of such iso-surface. + This may yield a set of connected features whose individual surfaces are discretized + by a triangulated mesh each. Such volumetric features can be processed further using + paraprobe-nanochem using a workflow with at most two steps. + + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: + + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. + These objects were already watertight within the triangulated iso-surface. + 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated + iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh + processing operations (hole filling, refinement, fairing operations). + 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality + that are not transformable into proxies or for which no transformation into proxies was + instructed. + + These features can be interpreted as microstructural features. Some of them may be precipitates, + some of them may be poles, some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + In the second step, the tool can be used to analyze the proximity of these objects to a + model of the surface (edge) of the dataset. - The identifier which the triangle_soup connectivity analysis - returned, which constitutes the first step of the - volumetric_feature identification process. + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. @@ -746,7 +746,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of keywords of feature_type dictionary. + The array of keywords of feature_type dictionary. @@ -754,8 +754,8 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of values for each keyword of the - feature_type dictionary. + The array of values for each keyword of the + feature_type dictionary. @@ -763,10 +763,10 @@ The cardinality/total number of triangles in the triangle soup.--> - The array of controlled keywords, need to be from - feature_type_dict_keyword, which specify which type - each feature triangle cluster belongs to. - Keep in mind that not each feature is an object or proxy. + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. @@ -774,7 +774,7 @@ The cardinality/total number of triangles in the triangle soup.--> - The explicit identifier of features. + The explicit identifier of features. @@ -782,21 +782,21 @@ The cardinality/total number of triangles in the triangle soup.--> - In all situations instances of the parent NXprocess group are returned with a very similar - information structuring and thus we here replace the template name FEATURE - with one of the following types feature-specific group names: - - * objects, objects, irrespective their distance to the surface - * objects_close_to_edge, sub-set of v_feature_object close surface - * objects_far_from_edge, sub-set of v_feature_object not close to the surface - * proxies, proxies, irrespective their distance to the surface - * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface - * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface + In all situations instances of the parent NXprocess group are returned with a very similar + information structuring and thus we here replace the template name FEATURE + with one of the following types feature-specific group names: + + * objects, objects, irrespective their distance to the surface + * objects_close_to_edge, sub-set of v_feature_object close surface + * objects_far_from_edge, sub-set of v_feature_object not close to the surface + * proxies, proxies, irrespective their distance to the surface + * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface + * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface - Explicit identifier of the feature a sub-set of the feature_identifier in the - parent group. + Explicit identifier of the feature a sub-set of the feature_identifier in the + parent group. @@ -804,7 +804,7 @@ The cardinality/total number of triangles in the triangle soup.--> - Volume of the feature. NaN for non-watertight objects. + Volume of the feature. NaN for non-watertight objects. @@ -812,11 +812,11 @@ The cardinality/total number of triangles in the triangle soup.--> - An oriented bounding box (OBB) to each object. + An oriented bounding box (OBB) to each object. - Edge length of the oriented bounding box from largest to smallest value. + Edge length of the oriented bounding box from largest to smallest value. @@ -825,8 +825,8 @@ The cardinality/total number of triangles in the triangle soup.--> - Oriented bounding box aspect ratio. - YX versus ZY or second-largest over largest and smallest over second largest. + Oriented bounding box aspect ratio. + YX versus ZY or second-largest over largest and smallest over second largest. @@ -835,9 +835,9 @@ The cardinality/total number of triangles in the triangle soup.--> - Position of the geometric center, which often is but - not necessarily has to be the center_of_mass of the - hexahedrally-shaped sample/sample part. + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. @@ -846,8 +846,8 @@ The cardinality/total number of triangles in the triangle soup.--> - A simple approach to describe the entire set of hexahedra when the main intention - is to store the shape of the hexahedra for visualization. + A simple approach to describe the entire set of hexahedra when the main intention + is to store the shape of the hexahedra for visualization. @@ -855,8 +855,8 @@ The cardinality/total number of triangles in the triangle soup.--> - + @@ -869,7 +869,7 @@ The cardinality/total number of triangles in the triangle soup.--> - + - Array of evaporation_identifier / ion_identifier which details which ions - lie inside or on the surface of the feature. + Array of evaporation_identifier / ion_identifier which details which ions + lie inside or on the surface of the feature. @@ -917,22 +917,22 @@ face_identifier_offset(NX_UINT):--> - Total (count) of ions inside or on the surface of the feature relevant for normalization. - NaN for non watertight objects. + Total (count) of ions inside or on the surface of the feature relevant for normalization. + NaN for non watertight objects. - + - Count or weight which, when divided by total, yields the composition of this element, - nuclide, or (molecular) ion within the volume of the feature/object. + Count or weight which, when divided by total, yields the composition of this element, + nuclide, or (molecular) ion within the volume of the feature/object. @@ -956,16 +956,16 @@ face_identifier_offset(NX_UINT):--> - The multiplicity whereby the ion position is accounted for - irrespective whether the ion is considered as a decorator - of the interface or not. - As an example, with atom probe it is typically not possible - to resolve the positions of the atoms which arrive at the detector - as molecular ions. Therefore, an exemplar molecular ion of two carbon - atoms can be considered to have a multiplicity of two to account that - this molecular ion contributes two carbon atoms at the reconstructed - location considering that the spatial resolution of atom probe - experiments is limited. + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. @@ -973,8 +973,8 @@ face_identifier_offset(NX_UINT):--> - The multiplicity whereby the ion position is accounted for when - the ion is considered one which is a decorator of the interface. + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. @@ -982,25 +982,25 @@ face_identifier_offset(NX_UINT):--> - The equation of the plane that is fitted initially. + The equation of the plane that is fitted initially. - The four parameter :math:`ax + by + cz + d = 0` which define the plane. + The four parameter :math:`ax + by + cz + d = 0` which define the plane. - + - The triangle surface mesh representing the interface model. - Exported at state before or after the next DCOM step. + The triangle surface mesh representing the interface model. + Exported at state before or after the next DCOM step. - Was this state exported before or after the next DCOM step. + Was this state exported before or after the next DCOM step. @@ -1030,7 +1030,7 @@ face_identifier_offset(NX_UINT):--> - Direction of each vertex normal. + Direction of each vertex normal. @@ -1039,12 +1039,12 @@ face_identifier_offset(NX_UINT):--> - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -1058,7 +1058,7 @@ face_identifier_offset(NX_UINT):--> - Direction of each face normal. + Direction of each face normal. @@ -1067,12 +1067,12 @@ face_identifier_offset(NX_UINT):--> - Qualifier which details how specifically oriented the - face normal is with respect to its primitive (triangle): - - * 0 - undefined - * 1 - outer - * 2 - inner + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner @@ -1091,9 +1091,9 @@ face_identifier_offset(NX_UINT):--> - Array of edge length values. For each triangle the edge length is - reported for the edges traversed according to the sequence - in which vertices are indexed in triangles. + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. @@ -1102,9 +1102,9 @@ face_identifier_offset(NX_UINT):--> - Array of interior angle values. For each triangle the angle is - reported for the angle opposite to the edges which are traversed - according to the sequence in which vertices are indexed in triangles. + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. @@ -1122,17 +1122,17 @@ face_identifier_offset(NX_UINT):--> - The ROIs are defined as cylinders for the computations. To visualize these we discretize - them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, - resolves the lateral surface of each cylinder such that their renditions are smooth in - visualization software like Paraview. + The ROIs are defined as cylinders for the computations. To visualize these we discretize + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + resolves the lateral surface of each cylinder such that their renditions are smooth in + visualization software like Paraview. - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. @@ -1141,8 +1141,8 @@ face_identifier_offset(NX_UINT):--> - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. @@ -1152,7 +1152,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI by its identifier. + XDMF support to enable colouring each ROI by its identifier. @@ -1160,7 +1160,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI whether it has edge contact or not. + XDMF support to enable colouring each ROI whether it has edge contact or not. @@ -1168,7 +1168,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI by its number of atoms. + XDMF support to enable colouring each ROI by its number of atoms. @@ -1176,7 +1176,7 @@ face_identifier_offset(NX_UINT):--> - XDMF support to enable colouring each ROI by its number of ions. + XDMF support to enable colouring each ROI by its number of ions. @@ -1184,22 +1184,22 @@ face_identifier_offset(NX_UINT):--> - Distance and iontype-specific processed data for each ROI. - Arrays signed_distance and nuclide_hash are sorted by increasing - distance. - Array nuclide_hash reports one hash for each atom of each isotope. - Effectively, this can yield to groups of values on signed_distance - with the same distance value as molecular ions are reported decomposed - into their atoms. - Therefore, the XDMF support fields number_of_atoms and number_of_ions - are only expected to display pairwise the same values respectively, - if all ions are built from a single atom only. + Distance and iontype-specific processed data for each ROI. + Arrays signed_distance and nuclide_hash are sorted by increasing + distance. + Array nuclide_hash reports one hash for each atom of each isotope. + Effectively, this can yield to groups of values on signed_distance + with the same distance value as molecular ions are reported decomposed + into their atoms. + Therefore, the XDMF support fields number_of_atoms and number_of_ions + are only expected to display pairwise the same values respectively, + if all ions are built from a single atom only. - + - Sorted in increasing order projected along the positive direction - of the ROI as defined by orientation in the parent group. + Sorted in increasing order projected along the positive direction + of the ROI as defined by orientation in the parent group. @@ -1207,7 +1207,7 @@ face_identifier_offset(NX_UINT):--> - Hashvalue as defined in :ref:`NXion`. + Hashvalue as defined in :ref:`NXion`. @@ -1220,13 +1220,13 @@ face_identifier_offset(NX_UINT):--> - + - + @@ -1240,9 +1240,9 @@ face_identifier_offset(NX_UINT):--> - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml index 19b701fad4..0907a4c558 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -52,9 +52,8 @@ - - + @@ -62,7 +61,7 @@ - + @@ -229,7 +228,7 @@ algorithm(NX_CHAR): ranging_definitions(NX_CHAR):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml index 79239410d3..694fdf743a 100644 --- a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -87,13 +87,13 @@ config--> - + - + @@ -107,7 +107,7 @@ config--> - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index c6c8477b22..4f267b6bf7 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -40,9 +40,8 @@ - - + @@ -50,7 +49,7 @@ - + @@ -109,7 +108,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index ebc0b11a2f..0483304ce1 100644 --- a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -59,13 +59,13 @@ - + - + @@ -79,7 +79,7 @@ - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml index 69e38f157c..55a70b95c3 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -24,28 +24,28 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. - Number of different source iontypes to distinguish. + Number of different source iontypes to distinguish. - Number of different target iontypes to distinguish. + Number of different target iontypes to distinguish. - Application definition for a configuration file of the paraprobe-spatstat tool. - - This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + Application definition for a configuration file of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. @@ -56,13 +56,13 @@ - How many spatial_statistics tasks should the tool execute. + How many spatial_statistics tasks should the tool execute. - - + + - + @@ -70,16 +70,16 @@ - + - + - Distance between each ion and triangulated surface mesh. + Distance between each ion and triangulated surface mesh. @@ -88,26 +88,26 @@ - Threshold to define how far an ion has to lay at least from the edge - of the dataset so that the ion can act as a source. This means that - an ROI is placed at the location of the ion and its neighbors are - analyzed how they contribute to the computed statistics. - - The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a - microstructural feature an ROI is placed. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. + Threshold to define how far an ion has to lay at least from the edge + of the dataset so that the ion can act as a source. This means that + an ROI is placed at the location of the ion and its neighbors are + analyzed how they contribute to the computed statistics. + + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a + microstructural feature an ROI is placed. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. - + - Distance between each ion and triangulated mesh of microstructural features. - In addition to spatial filtering and considering how far ions lie to the - edge of the dataset, it is possible to restrict the analyses to a sub-set of - ions within a distance not farther away to a feature than the feature_distance - threshold value. + Distance between each ion and triangulated mesh of microstructural features. + In addition to spatial filtering and considering how far ions lie to the + edge of the dataset, it is possible to restrict the analyses to a sub-set of + ions within a distance not farther away to a feature than the feature_distance + threshold value. @@ -115,19 +115,19 @@ - Absolute path in the (HDF5) file which points to the distance of each - ion to the closest feature. + Absolute path in the (HDF5) file which points to the distance of each + ion to the closest feature. - Threshold to define how close an ion has to lay to a feature so that - the ion can at all qualify as a source, i.e. that an ROI is placed - at the location of the ion and its neighbors are then analyzed - how they contribute to the computed statistics. - - Recall that this feature_distance threshold is used in combination - with the edge_distance threshold when placing ROI about source ions. + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that this feature_distance threshold is used in combination + with the edge_distance threshold when placing ROI about source ions. @@ -166,7 +166,7 @@ @@ -182,12 +182,12 @@ identifier(NX_UINT):--> - Specifies, if the iontypes are randomized for the point cloud or not. - Internally, paraprobe uses a sequentially executed deterministic MT19987 - (MersenneTwister) pseudo-random number generator to shuffle the - iontypes randomly across the entire set of ions. That is the total - number of ions of either type remain the same but the information about - their location is randomized. + Specifies, if the iontypes are randomized for the point cloud or not. + Internally, paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontypes randomly across the entire set of ions. That is the total + number of ions of either type remain the same but the information about + their location is randomized. @@ -197,35 +197,35 @@ identifier(NX_UINT):--> - How should the iontype be interpreted on the source-side, i.e. - all these ion positions where a regions-of-interest (ROI) around - so-called source ions will be placed. Different options exist - how iontypes are interpreted given an iontype represents - in general a (molecular) ion with different isotopes that have - individually different multiplicity. - - The value resolve_all will set an ion active in the analysis regardless - of which iontype it is. Each active ion is accounted for once. - - The value resolve_unknown will set an ion active when the ion is - of the UNKNOWNTYPE type. Each active ion is accounted for once. - - The value resolve_ion will set an ion active if it is of the specific - iontype, irregardless of its elemental or isotopic details. - Each active ion is counted once. - - The value resolve_element will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - atoms of elements in the whitelist ion_query_isotope_vector. - - The value resolve_isotope will set an ion active, and most importantly, - account for each as many times as the (molecular) ion contains - isotopes in the whitelist ion_query_isotope_vector. - - In effect, ion_query_isotope_vector acts as a whitelist to filter - which ions are considered as source ions of the correlation statistics - and how the multiplicity of each ion will be factorized, i.e. how - often it is accounted for. + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. @@ -237,13 +237,13 @@ identifier(NX_UINT):--> - Matrix of isotope vectors, as many as rows as different candidates - for iontypes should be distinguished as possible source iontypes. - In the simplest case, the matrix contains only the proton number - of the element in the row, all other values set to zero. - Combined with ion_query_type_source set to resolve_element this will - recover usual spatial correlation statistics like the 1NN C-C - spatial statistics. + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. @@ -252,14 +252,14 @@ identifier(NX_UINT):--> - Similarly as ion_query_type_source how should iontypes be interpreted - on the target-side, i.e. how many counts will be bookkept for ions - which are neighbors of source ions within or on the surface of each - inspection/ROI about each source ion. - Source ion in the center of the ROI are not accounted for during - counting the summary statistics. - For details about the resolve values consider the explanations in - ion_query_type_source. These account for ion_query_type_target as well. + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. @@ -272,9 +272,9 @@ identifier(NX_UINT):--> - Matrix of isotope vectors, as many as rows as different candidates for - iontypes to distinguish as possible targets. See additional comments - under ion_query_isotope_vector_source. + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. @@ -283,20 +283,20 @@ identifier(NX_UINT):--> - Specifies which spatial statistics to compute. + Specifies which spatial statistics to compute. - Compute k-th nearest neighbour statistics. + Compute k-th nearest neighbour statistics. - Order k. + Order k. - Minimum value, increment, and maximum value of the histogram binning. + Minimum value, increment, and maximum value of the histogram binning. @@ -305,11 +305,11 @@ identifier(NX_UINT):--> - Compute radial distribution function. + Compute radial distribution function. - Minimum value, increment, and maximum value of the histogram binning. + Minimum value, increment, and maximum value of the histogram binning. @@ -322,7 +322,7 @@ identifier(NX_UINT):--> NEW ISSUE: two_point(NXcollection):--> - + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml index a12156c6d8..99f18fb528 100644 --- a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -55,7 +55,7 @@ - + @@ -148,13 +148,13 @@ - + - + @@ -168,7 +168,7 @@ - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml index fcb4151c95..ffc81b9a39 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -50,9 +50,8 @@ - - + @@ -60,7 +59,7 @@ - + @@ -219,7 +218,7 @@ - + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml index 94a559e02e..47f496a2dc 100644 --- a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -24,41 +24,41 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The total number of ions in the reconstruction. + The total number of ions in the reconstruction. - The number of vertices of the alpha complex. + The number of vertices of the alpha complex. - The number of faces of the alpha complex. + The number of faces of the alpha complex. - The total number of XDMF values to represent all faces of triangles via XDMF. + The total number of XDMF values to represent all faces of triangles via XDMF. - The total number of XDMF values to represent all faces of tetrahedra via XDMF. + The total number of XDMF values to represent all faces of tetrahedra via XDMF. - Application definition for results files of the paraprobe-surfacer tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. - The purpose and need of the paraprobe-surfacer tool is the generation of meshed - representation of the surface of the the reconstructed volume (or a portion) of it - using different algorithms from the computational geometry community. + Application definition for results files of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-surfacer tool is the generation of meshed + representation of the surface of the the reconstructed volume (or a portion) of it + using different algorithms from the computational geometry community. @@ -70,19 +70,19 @@ - Paraprobe-surfacer can be used to load a ROI that is the entire or a - sub-set of the ion point cloud. In the point_cloud_wrapping process - the tool computes a triangulated surface mesh which encloses the - ROI/point cloud. This mesh can be seen as a model for the edge of - the dataset. - - Different algorithms can be used with paraprobe-surfacer to create - this mesh such as convex hulls, alpha-shapes as their generalization, - or alpha wrappings. - - Ideally, the resulting mesh should be a watertight polyhedron. - This polyhedron is not necessarily convex. For some algorithms there - is no guarantee that the resulting mesh yields a watertight mesh. + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. @@ -91,35 +91,35 @@ - + - A bitmask which identifies exactly all those ions whose positions - were considered when defining the filtered point set from which - that alpha_complex instance was computed. - - This window can be different to the window of the *point_set_wrapping* - parent group because irrelevant ions might have been filtered out in addition - to the window defined in *point_set_wrapping* to reduce e.g. computational - costs of the alpha complex computation. + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + that alpha_complex instance was computed. + + This window can be different to the window of the *point_set_wrapping* + parent group because irrelevant ions might have been filtered out in addition + to the window defined in *point_set_wrapping* to reduce e.g. computational + costs of the alpha complex computation. - Number of ions covered by the mask. + Number of ions covered by the mask. - Number of bits assumed matching on a default datatype. + Number of bits assumed matching on a default datatype. - The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for - how this bitfield is to be interpreted. + The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for + how this bitfield is to be interpreted. @@ -151,8 +151,8 @@ for eventually performed preprocessing--> - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. @@ -175,9 +175,9 @@ for eventually performed preprocessing--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tri * (1+1+3). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). @@ -185,26 +185,26 @@ for eventually performed preprocessing--> - Do the triangles define a triangulated surface mesh that is watertight? + Do the triangles define a triangulated surface mesh that is watertight? - The volume which the triangulated surface mesh - encloses if that mesh is watertight. + The volume which the triangulated surface mesh + encloses if that mesh is watertight. - The set of tetrahedra which represent the interior volume - of the complex if that is a closed two-manifold. + The set of tetrahedra which represent the interior volume + of the complex if that is a closed two-manifold. - The accumulated volume of all interior tetrahedra. + The accumulated volume of all interior tetrahedra. @@ -220,9 +220,9 @@ for eventually performed preprocessing--> - A list of as many tuples of XDMF topology key, XDMF number - of vertices and a triple of vertex indices specifying each - triangle. The total number of entries is n_f_tet * (1+1+4). + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). @@ -237,13 +237,13 @@ For the future as we may wish to wrap primitives other like triangles or polylin - + - + @@ -257,9 +257,9 @@ For the future as we may wish to wrap primitives other like triangles or polylin - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml index 255a5bcf80..b32d733723 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -41,9 +41,8 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - - + @@ -51,14 +50,14 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin - + - + @@ -159,7 +158,7 @@ if windowing_method is bitmasked_points: sum cardinality of NXcg := 0 and cardin minValue: EPSILON--> - + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml index 886db85c9d..74aa89eb0f 100644 --- a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -24,29 +24,29 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The total number of ions in the reconstruction. + The total number of ions in the reconstruction. - The total number of values required to represent all faces of each cell. + The total number of values required to represent all faces of each cell. - The total number of values required to represent all faces of each cell - (polyhedron) using XDMF. + The total number of values required to represent all faces of each cell + (polyhedron) using XDMF. - Application definition for results files of the paraprobe-tessellator tool. - - This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + Application definition for results files of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. @@ -58,13 +58,13 @@ - The tool can be used to compute a Voronoi tessellation the entire - or of a sub-set of the reconstructed volume. Each point (ion) is wrapped - in one (Voronoi) cell. The point cloud in the ROI is wrapped into an - axis-aligned bounding box (AABB) that is tight. This means points at - the edge of the point cloud can lay on the surface of the bounding box. - The tool detects if cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. + The tool can be used to compute a Voronoi tessellation the entire + or of a sub-set of the reconstructed volume. Each point (ion) is wrapped + in one (Voronoi) cell. The point cloud in the ROI is wrapped into an + axis-aligned bounding box (AABB) that is tight. This means points at + the edge of the point cloud can lay on the surface of the bounding box. + The tool detects if cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. @@ -75,12 +75,12 @@ - The (tight) axis-aligned bounding box about the point cloud. + The (tight) axis-aligned bounding box about the point cloud. - Coordinate triplet of the corner that lays closests - to the origin of the *paraprobe* coordinate system. + Coordinate triplet of the corner that lays closests + to the origin of the *paraprobe* coordinate system. @@ -88,8 +88,8 @@ - Coordinate triplet of the corner that lays farthest away - from the origin of the *paraprobe* coordinate system. + Coordinate triplet of the corner that lays farthest away + from the origin of the *paraprobe* coordinate system. @@ -104,12 +104,12 @@ - The number of points (and thus cells). + The number of points (and thus cells). - Volume of each Voronoi cell. + Volume of each Voronoi cell. @@ -117,7 +117,7 @@ - Which MPI process computed which Voronoi cell. + Which MPI process computed which Voronoi cell. @@ -125,7 +125,7 @@ - Which OpenMP thread computed which Voronoi cell. + Which OpenMP thread computed which Voronoi cell. @@ -133,9 +133,9 @@ - The number of faces for each cell. Faces of adjoining polyhedra are counted - for each polyhedron. This field can be used to interpret the concatenated vector - with the individual values for the area of each face. + The number of faces for each cell. Faces of adjoining polyhedra are counted + for each polyhedron. This field can be used to interpret the concatenated vector + with the individual values for the area of each face. @@ -144,8 +144,8 @@ - A simple approach to describe the entire set of polyhedra when the main - intention is to store the shape of the polyhedra for visualization purposes. + A simple approach to describe the entire set of polyhedra when the main + intention is to store the shape of the polyhedra for visualization purposes. @@ -155,12 +155,12 @@ - Sequence of tuples, concatenated in the order of the Voronoi cells. - Each tuple contains encodes information to visualize using XDMF: - Firstly, an XDMF geometric primitive type key. - Secondly, the number of vertices of the polygon. - Third, the sequence of vertex identifier which define the facet. - Tuples encode faces faster than cells. + Sequence of tuples, concatenated in the order of the Voronoi cells. + Each tuple contains encodes information to visualize using XDMF: + Firstly, an XDMF geometric primitive type key. + Secondly, the number of vertices of the polygon. + Third, the sequence of vertex identifier which define the facet. + Tuples encode faces faster than cells. @@ -168,12 +168,12 @@ - Sequence of cell identifier, concatenated such that each face is - associated with its cell. Given that paraprobe-tessellator assigns - each cell the evaporation_id of the ion that the cell wraps this - information enables the segmentation of the tessellation and - thus correlate per-ion properties with the volume that each cell - represents. + Sequence of cell identifier, concatenated such that each face is + associated with its cell. Given that paraprobe-tessellator assigns + each cell the evaporation_id of the ion that the cell wraps this + information enables the segmentation of the tessellation and + thus correlate per-ion properties with the volume that each cell + represents. @@ -182,10 +182,10 @@ - A bitmask that documents which of the cells are likely truncated because they - share at least one face with the *aabb* of the point cloud. This field encodes the - result of the boolean or operator applied to the value of all six wall_contact groups - that document contact in specific outer unit normal directions of the *aabb*. + A bitmask that documents which of the cells are likely truncated because they + share at least one face with the *aabb* of the point cloud. This field encodes the + result of the boolean or operator applied to the value of all six wall_contact groups + that document contact in specific outer unit normal directions of the *aabb*. @@ -199,9 +199,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length--> - In the spirit of wall_contact_global, the left face of *aabb*. - Its outer unit normal points in the opposite direction of the - x-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the left face of *aabb*. + Its outer unit normal points in the opposite direction of the + x-axis of the *paraprobe* coordinate system. @@ -213,9 +213,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the right face of *aabb*. - Its outer unit normal points in the direction of the x-axis - of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the right face of *aabb*. + Its outer unit normal points in the direction of the x-axis + of the *paraprobe* coordinate system. @@ -227,9 +227,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - y-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + y-axis of the *paraprobe* coordinate system. @@ -241,9 +241,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the rear face of *aabb*. - Its outer unit normal points in the direction of the y-axis - of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the rear face of *aabb*. + Its outer unit normal points in the direction of the y-axis + of the *paraprobe* coordinate system. @@ -255,9 +255,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the opposite direction of the - z-axis of the *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + z-axis of the *paraprobe* coordinate system. @@ -269,9 +269,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - In the spirit of wall_contact_global, the front face of *aabb*. - Its outer unit normal points in the direction of the z-axis of the - *paraprobe* coordinate system. + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the direction of the z-axis of the + *paraprobe* coordinate system. @@ -285,13 +285,13 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - + @@ -305,9 +305,9 @@ dim: (i,) # one would not need to constrain this but doing so communicates that - + - If used, metadata of at least the person who performed this analysis. + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml index f2bd4d139e..c63dd724bd 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -60,14 +60,13 @@ - Internal identifier used by the tool to refer to an analysis (aka simulation id). - + The configuration file that was used to parameterize the algorithms that this tool has executed. diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml index e4c3e27ed8..8dcdb3d1bf 100644 --- a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -44,8 +44,7 @@ Hierarchical Data Format 5 (HDF5). - - + Internal identifier used by the tool to refer to an analysis (aka simulation id). @@ -62,7 +61,7 @@ - + Specification of the tomographic reconstruction to use for this analysis. @@ -85,7 +84,7 @@ base class from which tool-specific appdefs inherit--> - + Specification of the ranging definitions to use for this analysis. @@ -105,7 +104,7 @@ base class from which tool-specific appdefs inherit--> - + Specification of the triangulated surface mesh to use for this analysis. @@ -117,7 +116,7 @@ base class from which tool-specific appdefs inherit--> doc: | Name of the (parent) node directly below which (in the hierarchy) an instance of :ref:`NXcg_triangle_set` is stored.--> - + Specification of the point-to-triangulated-surface-mesh distances to use for this analysis. diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml index 064fe397a5..20a3a00ba0 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -43,9 +43,8 @@ official NeXus appdef headers--> - - + @@ -53,7 +52,7 @@ official NeXus appdef headers--> - + Specification of the ranging definition file to use for this analysis. @@ -67,7 +66,7 @@ official NeXus appdef headers--> filter--> - + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml index 80963f2cf4..264d5b468d 100644 --- a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -87,7 +87,7 @@ i be careful n_comb can vary for every instance of (NXion) !--> - + @@ -167,13 +167,13 @@ config--> - + - + @@ -187,7 +187,7 @@ config--> - + If used, metadata of at least the person who performed this analysis. diff --git a/contributed_definitions/NXapm_ranging.nxdl.xml b/contributed_definitions/NXapm_ranging.nxdl.xml index c24b7f3926..2397081b9f 100644 --- a/contributed_definitions/NXapm_ranging.nxdl.xml +++ b/contributed_definitions/NXapm_ranging.nxdl.xml @@ -36,7 +36,7 @@ * `M. Kühbach et al. <https://doi.org/10.1017/S1431927621012241>`_ - + How many ion types are distinguished. If no ranging was performed, each diff --git a/contributed_definitions/NXapm_reconstruction.nxdl.xml b/contributed_definitions/NXapm_reconstruction.nxdl.xml index 832c4e04ae..3a5aa8a873 100644 --- a/contributed_definitions/NXapm_reconstruction.nxdl.xml +++ b/contributed_definitions/NXapm_reconstruction.nxdl.xml @@ -46,7 +46,7 @@ - + diff --git a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml index 1210a61f17..977bb7f29a 100644 --- a/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml +++ b/contributed_definitions/NXapm_volt_and_bowl.nxdl.xml @@ -43,7 +43,7 @@ flight path differences, detector biases, and nonlinearities. - + - - - +NXtransformations? => discussion needed--> + - A beam path consisting of one or more optical elements. - - NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement - of optical elements between the excitation source and the sample, or between - the sample and the detector unit. - - To describe the order of the elements, use 'order(NXtransformations)', where - each element's position points to the preceding element via '@depends_on'. - Special case beam splitter: A beam splitter is a device which separates the - beam into two or more beams. If such a device is part of the beam path use - two or more NXbeam_paths to describe the beam paths after the beam splitter. - In this case, in the dependency chain of the new beam paths, the first - elements each point to the beam splitter, as this is the previous element. - - Describe the relevant optical elements in the beam path by using the - appropriate base classes. You may use as many elements as needed, also - several elements of the same type as long as each element has its own name. + A beam path consisting of one or more optical elements. + + NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement + of optical elements between the excitation source and the sample, or between + the sample and the detector unit. + + To describe the order of the elements, use 'order(NXtransformations)', where + each element's position points to the preceding element via '@depends_on'. + Special case beam splitter: A beam splitter is a device which separates the + beam into two or more beams. If such a device is part of the beam path use + two or more NXbeam_paths to describe the beam paths after the beam splitter. + In this case, in the dependency chain of the new beam paths, the first + elements each point to the beam splitter, as this is the previous element. + + Describe the relevant optical elements in the beam path by using the + appropriate base classes. You may use as many elements as needed, also + several elements of the same type as long as each element has its own name. - Entry point of the dependency chain defined by the NXtransformations - field, i.e. a link to the last element in the beam path. - Example: /entry/instrument/beam_path/detector. + Entry point of the dependency chain defined by the NXtransformations + field, i.e. a link to the last element in the beam path. + Example: /entry/instrument/beam_path/detector. @@ -65,49 +67,49 @@ translation and rotation (2) Base class similar to NXtransformations but for changes of optical properties (e.g. polarization state).--> - Specify the order of the optical elements by defining a dependency chain. - For each element, a '@depends_on' attribute should be used to state the - position of the element in the beam path by pointing to the previous - element. For the very first element, use the string "." instead. + Specify the order of the optical elements by defining a dependency chain. + For each element, a '@depends_on' attribute should be used to state the + position of the element in the beam path by pointing to the previous + element. For the very first element, use the string "." instead. - For each element in the beam path, one such field must exist with a - '@depends_on' attribute defined to specify its position in the beam - path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows - ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and - 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the - dependency chain, i.e. may have an entry in this class even if they are - not described in the beam path. - ELEMENT is a place holder for the name of an optical beam path element. - Note that the name of this field must be exactly the same as the - element's field name. + For each element in the beam path, one such field must exist with a + '@depends_on' attribute defined to specify its position in the beam + path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows + ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and + 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the + dependency chain, i.e. may have an entry in this class even if they are + not described in the beam path. + ELEMENT is a place holder for the name of an optical beam path element. + Note that the name of this field must be exactly the same as the + element's field name. - Add a link to the previous beam path element. + Add a link to the previous beam path element. - Excitation source. One or more may be needed (e.g. two for a pump-probe - setup with one pump and one probe beam). - Depending on the source type, different properties are relevant, which - are provided through the respective base class (e.g. use NXopt_source for - lamps or lasers, NXchem_source for chemical reaction etc.). - Some base classes are incomplete (NXchem_source, NXbio_source); the - expertise of the respective communities is needed. + Excitation source. One or more may be needed (e.g. two for a pump-probe + setup with one pump and one probe beam). + Depending on the source type, different properties are relevant, which + are provided through the respective base class (e.g. use NXopt_source for + lamps or lasers, NXchem_source for chemical reaction etc.). + Some base classes are incomplete (NXchem_source, NXbio_source); the + expertise of the respective communities is needed. - Use this field to point to the previous optical element. + Use this field to point to the previous optical element. - Type of excitation source. + Type of excitation source. @@ -141,40 +143,40 @@ UV Plasma Source Metal Jet X-ray--> - Lifespan of the excitation (typically provided in hours). + Lifespan of the excitation (typically provided in hours). - How many hours has the lamp been used? + How many hours has the lamp been used? - Wavelengths or energy vector of the excitation source. This can be a - single value or a spectrum, depending on the type of experiment. + Wavelengths or energy vector of the excitation source. This can be a + single value or a spectrum, depending on the type of experiment. - Unit of wavelength or energy. + Unit of wavelength or energy. - Two- or three-dimensional beam profile. + Two- or three-dimensional beam profile. @@ -183,67 +185,67 @@ doc: Specify the properties of the optical source.--> - Power of one light pulse if the source is a pulsed source. + Power of one light pulse if the source is a pulsed source. - Is the excitation source continuous wave (CW)? + Is the excitation source continuous wave (CW)? - Power of CW beam. + Power of CW beam. - FWHM bandwidth of the excitation source. + FWHM bandwidth of the excitation source. - Coherence length. + Coherence length. - Divergence of the excitation beam. + Divergence of the excitation beam. - Use this field to describe a simple pinhole (round geometry). Define its - dimension using 'diameter'. For more complex geometries, 'NXaperture' - should be used. + Use this field to describe a simple pinhole (round geometry). Define its + dimension using 'diameter'. For more complex geometries, 'NXaperture' + should be used. - Use this field to describe a simple slit (rectangular geometry). Define - its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, - 'NXaperture' should be used. + Use this field to describe a simple slit (rectangular geometry). Define + its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, + 'NXaperture' should be used. - + - Use this field to describe an aperture. To specify a window, use the - field 'window_NUMBER(NXaperture)'. + Use this field to describe an aperture. To specify a window, use the + field 'window_NUMBER(NXaperture)'. - + - A window, e.g. an entry or exit window of a cryostat. + A window, e.g. an entry or exit window of a cryostat. - Use this field to point to the previous optical element. + Use this field to point to the previous optical element. - The material of the window. + The material of the window. @@ -258,89 +260,89 @@ doc: Specify the properties of the optical source.--> - If you specified 'other' as material, decsribe here what it is. + If you specified 'other' as material, decsribe here what it is. - Thickness of the window + Thickness of the window - Angle of the window normal (outer) vs. the substrate normal - (similar to the angle of incidence). + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). - If reference data were measured add a link to the NeXus file where they - are described. + If reference data were measured add a link to the NeXus file where they + are described. - + - A device that reduces the intensity of a beam by attenuation. + A device that reduces the intensity of a beam by attenuation. - The transmitted intensity divided by the incident intensity. + The transmitted intensity divided by the incident intensity. - Attenuation of the attenuator in dB. + Attenuation of the attenuator in dB. - Unit of the measured data is not covered by NXDL units state - here which unit was used. + Unit of the measured data is not covered by NXDL units state + here which unit was used. - Input and output aperture of the attenuator. + Input and output aperture of the attenuator. - Geometry (shape, size etc.) of the attenuator. + Geometry (shape, size etc.) of the attenuator. - A diffraction grating. Define relevant parameters in the corresponding - fields, e.g. order of diffration (diffraction_order) or angular - dispersion (angular_dispersion). + A diffraction grating. Define relevant parameters in the corresponding + fields, e.g. order of diffration (diffraction_order) or angular + dispersion (angular_dispersion). - Define the type of the grating. + Define the type of the grating. - Dispersion of the grating in nm/mm (or e.g. nm/mrad). + Dispersion of the grating in nm/mm (or e.g. nm/mrad). - Number of grooves per mm. + Number of grooves per mm. - Blaze wavelength of the grating. + Blaze wavelength of the grating. - Efficiency curve versus wavelength or energy. + Efficiency curve versus wavelength or energy. @@ -348,94 +350,94 @@ doc: Specify the properties of the optical source.--> - Spectral values, e.g. wavelength or energy. Vector of length - N_spectrum. + Spectral values, e.g. wavelength or energy. Vector of length + N_spectrum. - Unit of wavelength array (e.g. nanometer or Angstrom) + Unit of wavelength array (e.g. nanometer or Angstrom) - A device blocking the beam in a temporal periodic pattern, e.g. a optical - chopper wheel. Specify the frequency range using 'min_frequency' and - 'max_frequency'. + A device blocking the beam in a temporal periodic pattern, e.g. a optical + chopper wheel. Specify the frequency range using 'min_frequency' and + 'max_frequency'. - Minimum frequency in Hertz. + Minimum frequency in Hertz. - Maximum frequency in Hertz. + Maximum frequency in Hertz. - Frequency resolution in Hertz. + Frequency resolution in Hertz. - A monochromator or spectrometer. + A monochromator or spectrometer. - Spectral values of the monochromator, e.g. wavelength or energy values - used for the measurement. + Spectral values of the monochromator, e.g. wavelength or energy values + used for the measurement. - Unit of wavelength array (e.g. nanometer or Angstrom) + Unit of wavelength array (e.g. nanometer or Angstrom) - Diffraction grating. If two or more gratings were used, define the - angular dispersion and the wavelength range (min/max wavelength) for - each grating and make sure that the wavelength ranges do not overlap. - The dispersion should be defined for the entire wavelength range of the - experiment. + Diffraction grating. If two or more gratings were used, define the + angular dispersion and the wavelength range (min/max wavelength) for + each grating and make sure that the wavelength ranges do not overlap. + The dispersion should be defined for the entire wavelength range of the + experiment. - Dispersion of the grating in nm/mm. + Dispersion of the grating in nm/mm. - Minimum wavelength of the grating. + Minimum wavelength of the grating. - Maximum wavelength of the grating. + Maximum wavelength of the grating. - Spectral resolution of the instrument. + Spectral resolution of the instrument. - Define the width of the monochromator slit in the subfield x_gap. + Define the width of the monochromator slit in the subfield x_gap. - Was the slit width fixed? + Was the slit width fixed? - If slit width was not fixed, define the maximum slit width. + If slit width was not fixed, define the maximum slit width. diff --git a/contributed_definitions/NXbeam_splitter.nxdl.xml b/contributed_definitions/NXbeam_splitter.nxdl.xml index 1459f886fe..f5be70ac45 100644 --- a/contributed_definitions/NXbeam_splitter.nxdl.xml +++ b/contributed_definitions/NXbeam_splitter.nxdl.xml @@ -1,4 +1,4 @@ - + - - + + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the beam splitter material and/or coating is defined. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. - Length of the spectrum vector (e.g. wavelength or energy) for which the - reflectance or transmission of the beam splitter is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. - Number of parameters needed do descripe the shape of the beam splitter. + Number of parameters needed do descripe the shape of the beam splitter. - Number of objects the beam splitter is made up of. + Number of objects the beam splitter is made up of. - Number of outputs, i.e. number of paths the beam takes after being split by - the beam splitter. + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. - A beam splitter, i.e. a device splitting the light into two or more beams. - - Information about types and properties of beam splitters is provided e.g. - [here](https://www.rp-photonics.com/beam_splitters.html). - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. - Specify the beam splitter type (e.g. dielectric mirror, pellicle, - dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension - should be described in 'geometry'. Define if the beam splitter is - polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. @@ -85,29 +86,29 @@ - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. + If you selected 'other' in 'type' use this field to specify which type of + beam splitter was used. - Is the beam splitter polarizing? + Is the beam splitter polarizing? - Does the beam splitter have multiple outputs (diffractive optical - element), i.e. more than two outputs? + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? - Describe the geometry (shape, dimension etc.) of the beam splitter. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). - Describe the shape (plate, cube, wedged, prism etc.). + Describe the shape (plate, cube, wedged, prism etc.). @@ -130,32 +131,32 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - If you chose 'other' in 'shape' describe what it is. + If you chose 'other' in 'shape' describe what it is. - Sketch of the beam splitter showing its geometry. The paths of the - incoming and split beam should be illustrated and labelled (0 for the - incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split - beam paths)). + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). - Physical extent of the beam splitter device. The beam splitter might be - made up of one or more objects (NX_objects). The meaning and location - of the axes used will vary according to the value of the 'shape' - variable. 'N_shapepar' defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. @@ -164,41 +165,41 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - Wedge angle if 'shape' is 'wedged'. + Wedge angle if 'shape' is 'wedged'. +doc: | +Specify the length of the beam splitter. If the device has a wedged +shape provide the minimum and maximum length of the device. +Otherwise, if the beam splitter has a homogeneous thickness, the two +values are equal. +dimensions: +rank: 1 +dim: [[1,2]]--> - Beam splitting ratio(s) for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. @@ -206,30 +207,30 @@ length(NX_FLOAT): - Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of - length and height for square geometry). + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). - Substrate of the beam splitter. Describe the material of the substrate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. - Specify the material of the beam splitter. If the device has a coating - it should be described in coating/coating_material. Is the material - birefringent? + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? - Thickness of the beam splitter substrate. Define the minimum and - maximum thickness (for a wedged geomtry). For a homogeneous thickness - (e.g. as in plate beam splitters) the minimum and maximum values are - equal. + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geomtry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. @@ -237,8 +238,8 @@ length(NX_FLOAT): - Complex index of refraction of the beam splitter substrate. Specify at - given spectral values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). @@ -248,32 +249,32 @@ length(NX_FLOAT): - Is the beam splitter coated? If yes, specify the type and material of the - coating and the spectral range for which it is designed. If known, you - may also provide its index of refraction. For a beam splitter cube - consisting of two prisms which are glued together, you may want to - specify the the glue and the coatings of each prism. + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Specify the coating material. + Specify the coating material. - Thickness of the coating. + Thickness of the coating. - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. @@ -281,8 +282,8 @@ length(NX_FLOAT): - Complex index of refraction of the coating. Specify at given spectral - values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). @@ -292,10 +293,10 @@ length(NX_FLOAT): - Wavelength range for which the beam splitter is designed. Enter the - minimum and maximum values of the wavelength range. Alternatively, or - additionally, you may define the wavelength range for the coating in - coating/wavelength_range_coating. + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. @@ -303,11 +304,11 @@ length(NX_FLOAT): - Optical loss of the beam splitter for the various outputs (i.e. the paths - of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. @@ -315,20 +316,20 @@ length(NX_FLOAT): - Optimized angle of incidence for the desired splitting ratio. + Optimized angle of incidence for the desired splitting ratio. - Angle of deflection corresponding to the optimized angle of incidence - defined in incident_angle. + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. - + - Range of the angles of incidence (AOI) for which the beam splitter can be - operated. Specify the minimum and maximum angles of the range. + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. @@ -341,7 +342,7 @@ If this is the case for some devices, we might also have to define a field for the corresponding defelction angles...--> - Reflectance of the beam splitter at given spectral values. + Reflectance of the beam splitter at given spectral values. @@ -349,11 +350,11 @@ for the corresponding defelction angles...--> - Transmission at given spectral values for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. diff --git a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml index ab16a56178..614fb183b0 100644 --- a/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml +++ b/contributed_definitions/NXbeam_transfer_matrix_table.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Variables used throughout the document, e.g. dimensions or parameters. @@ -33,17 +33,17 @@ - Contains datastructures of an experimental optical setup (i.e., multiple + Contains datastructures of an experimental optical setup (i.e., multiple transfermatrix tables). These datastructures are used to relate physical properties of two beams (NXbeam) which have one common optical element (NXopt_element) (one specific transfermatrix). One of these beams in an input beam and the other one is an output beam. - The data describes the change of beam properties, e.g. the intensity of a + The data describes the change of beam properties, e.g. the intensity of a beam is reduced because the transmission coefficient of the beam device is lower than 1. - + Select which type of data was recorded, for example aperture and focal length. @@ -72,7 +72,7 @@ - Contains the datastructure which relates beam properties of an + Contains the datastructure which relates beam properties of an input and output beam as result of the input beam interaction with the beam device. diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml index eb2068292e..f90a2b5b34 100644 --- a/contributed_definitions/NXbias_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXbias_spectroscopy.nxdl.xml @@ -23,21 +23,21 @@ --> - A base class for bias spectroscopy to describe the change in the physical properties - of the sample with respect to the sweep voltage applied on a sample of STM/AFM/... experiment. - - In these experiments an electric potential is applied between the (conductive) sample and the probe - (tip), and the physical properties (e.g. tunnelling current) is measured as the function of this - potential. The potential is varied in so-called voltage sweeps and the corresponding properties are - recorded accordingly. + A base class for bias spectroscopy to describe the change in the physical properties + of the sample with respect to the sweep voltage applied on a sample of STM/AFM/... experiment. + + In these experiments an electric potential is applied between the (conductive) sample and the probe + (tip), and the physical properties (e.g. tunnelling current) is measured as the function of this + potential. The potential is varied in so-called voltage sweeps and the corresponding properties are + recorded accordingly. - The measurement of the I(V) curve can come in two ways: - 1. Constant spacing: The bias voltage is swept from the start to the end with a constant - spacing between the tip and surface. - 2. Variable spacing: The bias voltage is swept from the start to the end in a discretized - spacing between the tip and surface. (Either an array of voltages, or the steps are defined). + The measurement of the I(V) curve can come in two ways: + 1. Constant spacing: The bias voltage is swept from the start to the end with a constant + spacing between the tip and surface. + 2. Variable spacing: The bias voltage is swept from the start to the end in a discretized + spacing between the tip and surface. (Either an array of voltages, or the steps are defined). @@ -46,16 +46,16 @@ - The PID (proportional, integral, differential feedback system) positioner information while running - bias voltage-tunneling current measurement. - - These components position the probe relative to the sample, thus help obtaining maps of the data - across the sample surface. + The PID (proportional, integral, differential feedback system) positioner information while running + bias voltage-tunneling current measurement. + + These components position the probe relative to the sample, thus help obtaining maps of the data + across the sample surface. - The z-offset is a starting tip position before the sweep starts (typically the position of a - piezo element). + The z-offset is a starting tip position before the sweep starts (typically the position of a + piezo element). @@ -64,32 +64,32 @@ scan_time?--> - The time or period is taken by a bias sweep to acquire the data for - a single bias sweep point (when the given point or whole sweep is started.). + The time or period is taken by a bias sweep to acquire the data for + a single bias sweep point (when the given point or whole sweep is started.). - The time or period is taken by a bias sweep to be displayed. + The time or period is taken by a bias sweep to be displayed. - The time or period is taken by the circuit to measure a full bias sweep voltage or - bias current. (duration of the measurement) + The time or period is taken by the circuit to measure a full bias sweep voltage or + bias current. (duration of the measurement) - The time or period is taken by the circuit to indicate the bias sweep voltage - after measuring the voltage. + The time or period is taken by the circuit to indicate the bias sweep voltage + after measuring the voltage. - The bias sweep information. + The bias sweep information. - The type of scan like mesh, spiral, etc. - - This combines not only how the voltages are changed, but how the voltage values are - correlated to a position across the sample surface, measuring sweeps are each spatial - coordinate or mapping the response at constant voltage, etc. - For STS experiment, the scan type is usually a single-point scan (trajectory scan). + The type of scan like mesh, spiral, etc. + + This combines not only how the voltages are changed, but how the voltage values are + correlated to a position across the sample surface, measuring sweeps are each spatial + coordinate or mapping the response at constant voltage, etc. + For STS experiment, the scan type is usually a single-point scan (trajectory scan). @@ -110,91 +110,91 @@ each other (e.g. spiral)--> - The number of sweeps taken during the bias spectroscopy. + The number of sweeps taken during the bias spectroscopy. - The initial time is taken to settle the bias voltage at the desired value. - On each sweep usually, the system takes time to settle to the bias voltage - at the next value. + The initial time is taken to settle the bias voltage at the desired value. + On each sweep usually, the system takes time to settle to the bias voltage + at the next value. - The time is taken to settle the bias voltage at the desired value. - The time (at the last sweep) to settle for the last value of the sweep. + The time is taken to settle the bias voltage at the desired value. + The time (at the last sweep) to settle for the last value of the sweep. - The rate at which the amplifier responds to the voltage change - (to reach at the desired value). It defines if the tip movement and - voltage sweep are synchronized. + The rate at which the amplifier responds to the voltage change + (to reach at the desired value). It defines if the tip movement and + voltage sweep are synchronized. - The z position after the sweeps are done. + The z position after the sweeps are done. - The total time needed for the entire voltage sweep. + The total time needed for the entire voltage sweep. - The region of the scan area. + The region of the scan area. - The range of the scan area. + The range of the scan area. - The offset of the scan area in 2D (X and Y) space. + The offset of the scan area in 2D (X and Y) space. - + - The N (substring) denotes the angle of the scan area with different physical - axes. + The N (substring) denotes the angle of the scan area with different physical + axes. - The linear scan information for scanning of a smaple. - - In this scan type the probe is scanned with a constant velocity across the surface, - and parameters are measured along the line. + The linear scan information for scanning of a smaple. + + In this scan type the probe is scanned with a constant velocity across the surface, + and parameters are measured along the line. - The speed of the scanner or the probe during the scan. + The speed of the scanner or the probe during the scan. - The time taken by the scanner to scan the entire area. + The time taken by the scanner to scan the entire area. - Speed of the scanner or the probe moves forward direction. + Speed of the scanner or the probe moves forward direction. - Speed of the scanner or the probe that moves backward direction. + Speed of the scanner or the probe that moves backward direction. - + - The data that comes from scanning the area. + The data that comes from scanning the area. diff --git a/contributed_definitions/NXbias_sweep.nxdl.xml b/contributed_definitions/NXbias_sweep.nxdl.xml index 21d6f90a9d..70ba835c4e 100644 --- a/contributed_definitions/NXbias_sweep.nxdl.xml +++ b/contributed_definitions/NXbias_sweep.nxdl.xml @@ -23,70 +23,70 @@ --> - A base class that defines how the bias voltage sweep is performed in the - scanning probe microscopy experiments. + A base class that defines how the bias voltage sweep is performed in the + scanning probe microscopy experiments. - The scan region is the area of phase space or sub-phase space where the scan is - performed. + The scan region is the area of phase space or sub-phase space where the scan is + performed. - The starting voltage of the bias sweep. The range of voltages for the sweep can - be defined with scan voltage offset and scan voltage range (difference between - minimum and maximum voltage values in a sweep) + The starting voltage of the bias sweep. The range of voltages for the sweep can + be defined with scan voltage offset and scan voltage range (difference between + minimum and maximum voltage values in a sweep) - The range of voltages for the sweep can be defined with scan voltage offset and - scan voltage range (difference between minimum and maximum voltage values in a - sweep) + The range of voltages for the sweep can be defined with scan voltage offset and + scan voltage range (difference between minimum and maximum voltage values in a + sweep) - The start of the bias scan voltage. + The start of the bias scan voltage. - The end value of the bias scan voltage. + The end value of the bias scan voltage. - In the linear sweep, the bias voltage is changed linearly from the start value - to the end value. + In the linear sweep, the bias voltage is changed linearly from the start value + to the end value. - If the bias voltage sweep is also performed in the opposite direction. + If the bias voltage sweep is also performed in the opposite direction. - The number of voltage points per sweep. + The number of voltage points per sweep. - The step size between the two consecutive bias voltage values during the sweep. + The step size between the two consecutive bias voltage values during the sweep. - The reset_bias defines whether the bias voltage should be reset to the starting - value after the sweep is completed. + The reset_bias defines whether the bias voltage should be reset to the starting + value after the sweep is completed. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, - please duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, + please duplicate this NXdata group for each. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml deleted file mode 100644 index d01b9bbf9c..0000000000 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ /dev/null @@ -1,248 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - A description of the procedures employed. - - - - - The start time of the calibration. - - - - - The end time of the calibration. - - - - - The time difference between the start and end time of the calibration. - Or the value directly comes from the instrument. - - - - - The period for which the calibration is valid. Usually, every instrument or part of the - needs to be calibrated at regular intervals. - - - - - The type of calibration, e.g., active calibration, passive calibration, - or according to the laboratory defined type. - - - - - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - - - - - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - - - - - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - Name of the software used for this calibration. - - - - Software version. - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - - - - - - - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - - - - - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - - - - - - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - - - - - .. 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/NXcantilever_spm.nxdl.xml b/contributed_definitions/NXcantilever_spm.nxdl.xml index e32f4a186a..46f16c2a1f 100644 --- a/contributed_definitions/NXcantilever_spm.nxdl.xml +++ b/contributed_definitions/NXcantilever_spm.nxdl.xml @@ -23,144 +23,144 @@ --> - A base class to describe the cantilever used in Atomic Force Microscopy (AFM) - techniques. + A base class to describe the cantilever used in Atomic Force Microscopy (AFM) + techniques. - Generally speaking, the cantilever resembles a simple harmonic oscillator. - When the cantilever tip is close to the surface of the sample, an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. The detector (typically a photodiode) measures this deformation and, therefore, the force acting on the cantilever. - In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of this loop controls the vertical position of the cantilever. - This part describes the oscillator driving the oscillations of a cantilever in an AFM or other experiment. + Generally speaking, the cantilever resembles a simple harmonic oscillator. + When the cantilever tip is close to the surface of the sample, an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. The detector (typically a photodiode) measures this deformation and, therefore, the force acting on the cantilever. + In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of this loop controls the vertical position of the cantilever. + This part describes the oscillator driving the oscillations of a cantilever in an AFM or other experiment. - The reference amplitude (also called drive amplitude) of the cantilever. + The reference amplitude (also called drive amplitude) of the cantilever. - The reference frequency (also called drive frequency or resonance frequency) of - the cantilever. + The reference frequency (also called drive frequency or resonance frequency) of + the cantilever. - The harmonic (e.g., second harmonic of the fundamental frequency) frequency of - the cantilever. + The harmonic (e.g., second harmonic of the fundamental frequency) frequency of + the cantilever. - Phase locked loop for cantilever lock-in device. + Phase locked loop for cantilever lock-in device. - Describes the cantilever frequency positioner, if it exists. + Describes the cantilever frequency positioner, if it exists. - Describes the cantilever phase positioner, if it exists. + Describes the cantilever phase positioner, if it exists. - Describes the cantilever frequency positioner, if it exists. + Describes the cantilever frequency positioner, if it exists. - The phase difference between the reference signal of cantilever and response - signal. + The phase difference between the reference signal of cantilever and response + signal. - Shift in the resonance frequency of the cantilever. + Shift in the resonance frequency of the cantilever. - The cutoff frequency of the cantilever. + The cutoff frequency of the cantilever. - The bandwidth of the resonance frequency. + The bandwidth of the resonance frequency. - The target amplitude of the cantilever to start the AFM/SPM experiment. + The target amplitude of the cantilever to start the AFM/SPM experiment. - The active frequency of the cantilever to start the experiment. + The active frequency of the cantilever to start the experiment. - The reference phase of the cantilever oscillator. + The reference phase of the cantilever oscillator. - The configuration information of the cantilever such as calibration information, - material properties, size, resonance, etc. + The configuration information of the cantilever such as calibration information, + material properties, size, resonance, etc. - The coating material of the cantilever. + The coating material of the cantilever. - + - The radius of curvature of the cantilever tip. The (substring) N denotes X or Y. + The radius of curvature of the cantilever tip. The (substring) N denotes X or Y. - The shape of the cantilever as a general text, such as A-shape, beam, or arrow. + The shape of the cantilever as a general text, such as A-shape, beam, or arrow. - Nominal length between base and end of the cantilever in micrometers. + Nominal length between base and end of the cantilever in micrometers. - Nominal width of the cantilever in microns. + Nominal width of the cantilever in microns. - Nominal thickness of the cantilever in microns. + Nominal thickness of the cantilever in microns. - Nominal free resonance frequency of the cantilever in air, in kHz. + Nominal free resonance frequency of the cantilever in air, in kHz. - The calibration information of the cantilever. + The calibration information of the cantilever. - A force applied to the cantilever tip will cause a change in - cantilever's oscillation amplitude (in dynamic mode) or deflection of the cantilever. - The sensitivity of the cantilever is calculated as the ratio of this change to the force causing it. + A force applied to the cantilever tip will cause a change in + cantilever's oscillation amplitude (in dynamic mode) or deflection of the cantilever. + The sensitivity of the cantilever is calculated as the ratio of this change to the force causing it. - The spring constant coefficient of the cantilever. + The spring constant coefficient of the cantilever. diff --git a/contributed_definitions/NXcg_alpha_complex.nxdl.xml b/contributed_definitions/NXcg_alpha_complex.nxdl.xml index fb6e401251..a78604a216 100644 --- a/contributed_definitions/NXcg_alpha_complex.nxdl.xml +++ b/contributed_definitions/NXcg_alpha_complex.nxdl.xml @@ -25,25 +25,25 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hull of a point set.--> - Computational geometry of alpha shapes or alpha wrappings about primitives. - - For details see: - - * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, - * https://dx.doi.org/10.1145/174462.156635 for 3D, - * https://dl.acm.org/doi/10.5555/871114 for weighted, and - * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation - * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings - - in CGAL, the Computational Geometry Algorithms Library. - As a starting point, we follow the conventions of the CGAL library. + Computational geometry of alpha shapes or alpha wrappings about primitives. + + For details see: + + * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, + * https://dx.doi.org/10.1145/174462.156635 for 3D, + * https://dl.acm.org/doi/10.5555/871114 for weighted, and + * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation + * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings + + in CGAL, the Computational Geometry Algorithms Library. + As a starting point, we follow the conventions of the CGAL library. - Type of alpha complex following the terminology used by CGAL for now. - - Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes - created using the alpha_wrapping algorithm. + Type of alpha complex following the terminology used by CGAL for now. + + Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes + created using the alpha_wrapping algorithm. @@ -53,15 +53,15 @@ The so-called spectrum or sets of (weighted) alpha shapes includes the convex hu - Are singular faces removed, i.e. has the alpha complex - been regularized or not. + Are singular faces removed, i.e. has the alpha complex + been regularized or not. - The alpha parameter, i.e. the radius of the alpha-sphere that - is used when computing the alpha complex. + The alpha parameter, i.e. the radius of the alpha-sphere that + is used when computing the alpha complex. - The offset distance parameter used when computing alpha_wrappings. + The offset distance parameter used when computing alpha_wrappings. - - + + - Point cloud for which the alpha shape or wrapping has been computed. + Point cloud for which the alpha shape or wrapping has been computed. - + - Triangle soup for which the alpha wrapping has been computed. + Triangle soup for which the alpha wrapping has been computed. - + - Triangle mesh representing the alpha complex. + Triangle mesh representing the alpha complex. - + - Set of tetrahedra representing the volume inside the alpha complex. + Set of tetrahedra representing the volume inside the alpha complex. - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The cardinality of the set, i.e. the number of hexahedra. + The cardinality of the set, i.e. the number of hexahedra. - Computational geometry description of a set of hexahedra in Euclidean space. - - This class can also be used to describe cuboids or cubes, axis-aligned or not. - The class represents different access and description levels to offer both - applied scientists and computational geometry experts an approach whereby - different specific views can be implemented using the same base class: - - * In the simplest case experimentalists may use this base class to describe - the dimensions or size of a specimen. In this case the alignment with axes - is not relevant as eventually only the volume of the specimen is of interest. - * In many cases, take for example an experiment where a specimen was cut out - from a specifically deformed piece of material, the orientation of the - specimen's edges with the experiment coordinate system is of high relevance. - Examples include knowledge about the specimen edge, whether it is - parallel to the rolling, the transverse, or the normal direction. - * While the above-mentioned use cases are sufficient to pinpoint the sample - within a known laboratory/experiment coordinate system, these descriptions - are not detailed enough to specify e.g. a CAD model of the specimen. - * Therefore, groups and fields for an additional, computational-geometry- - based view of hexahedra is offered to serve additional computational - tasks: storage-oriented simple views or detailed topological/graph-based - descriptions. - - Hexahedra are important geometrical primitives, which are among the most - frequently used elements in finite element meshing/modeling. - - As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra - are assumed non-degenerated, closed, and built of polygons that are - not self-intersecting. - - The term hexahedra will be used throughout this base class but includes - the special cases cuboid, cube, box, axis-aligned bounding box (AABB), - and optimal bounding box (OBB). - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a cuboid whose edges are aligned with the - base vectors of a coordinate system. As a part of binary trees, these data - objects are important for making time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best - tightly fitting box about an arbitrary object. In general, such boxes are - rotated. Exact and substantially faster in practice approximate algorithms - exist to compute optimal or near optimal bounding boxes for sets of points. + Computational geometry description of a set of hexahedra in Euclidean space. + + This class can also be used to describe cuboids or cubes, axis-aligned or not. + The class represents different access and description levels to offer both + applied scientists and computational geometry experts an approach whereby + different specific views can be implemented using the same base class: + + * In the simplest case experimentalists may use this base class to describe + the dimensions or size of a specimen. In this case the alignment with axes + is not relevant as eventually only the volume of the specimen is of interest. + * In many cases, take for example an experiment where a specimen was cut out + from a specifically deformed piece of material, the orientation of the + specimen's edges with the experiment coordinate system is of high relevance. + Examples include knowledge about the specimen edge, whether it is + parallel to the rolling, the transverse, or the normal direction. + * While the above-mentioned use cases are sufficient to pinpoint the sample + within a known laboratory/experiment coordinate system, these descriptions + are not detailed enough to specify e.g. a CAD model of the specimen. + * Therefore, groups and fields for an additional, computational-geometry- + based view of hexahedra is offered to serve additional computational + tasks: storage-oriented simple views or detailed topological/graph-based + descriptions. + + Hexahedra are important geometrical primitives, which are among the most + frequently used elements in finite element meshing/modeling. + + As a specialization of the :ref:`NXcg_primitive_set` base class hexahedra + are assumed non-degenerated, closed, and built of polygons that are + not self-intersecting. + + The term hexahedra will be used throughout this base class but includes + the special cases cuboid, cube, box, axis-aligned bounding box (AABB), + and optimal bounding box (OBB). + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a cuboid whose edges are aligned with the + base vectors of a coordinate system. As a part of binary trees, these data + objects are important for making time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best + tightly fitting box about an arbitrary object. In general, such boxes are + rotated. Exact and substantially faster in practice approximate algorithms + exist to compute optimal or near optimal bounding boxes for sets of points. - Qualifier for the shape of each hexahedron. + Qualifier for the shape of each hexahedron. @@ -96,9 +96,9 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier that is useful in cases when one edge is longer than all other - edges of the hexahedra. Often the term length is associated with the - assumption that one edge is parallel to an axis of the coordinate system. + Qualifier that is useful in cases when one edge is longer than all other + edges of the hexahedra. Often the term length is associated with the + assumption that one edge is parallel to an axis of the coordinate system. @@ -106,11 +106,11 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the extent of an object in the horizontal - direction assuming a specific coordinate system. - - For the sake of explicitness quantities like length, width, and height - should not be reported without specifying also the assumed reference frame. + Qualifier often used to describe the extent of an object in the horizontal + direction assuming a specific coordinate system. + + For the sake of explicitness quantities like length, width, and height + should not be reported without specifying also the assumed reference frame. @@ -118,8 +118,8 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Qualifier often used to describe the extent of an object in the vertical - direction assuming a specific coordinate system. + Qualifier often used to describe the extent of an object in the vertical + direction assuming a specific coordinate system. @@ -127,7 +127,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Volume of each hexahedron. + Volume of each hexahedron. @@ -135,7 +135,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Total (surface) area (of all six faces) of each hexahedron. + Total (surface) area (of all six faces) of each hexahedron. @@ -143,7 +143,7 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Area of each of the six faces of each hexahedron. + Area of each of the six faces of each hexahedron. @@ -152,8 +152,8 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Specifies if the hexahedra represent cuboids or cubes eventually rotated - ones but at least not too exotic six-faced polyhedra. + Specifies if the hexahedra represent cuboids or cubes eventually rotated + ones but at least not too exotic six-faced polyhedra. @@ -161,9 +161,9 @@ from MarDI, for now let's assume we do not need polytopes for d > 3--> - Only to be used if is_box is present. In this case, this field describes - whether hexahedra are boxes whose primary edges are parallel to the - axes of the coordinate system. + Only to be used if is_box is present. In this case, this field describes + whether hexahedra are boxes whose primary edges are parallel to the + axes of the coordinate system. @@ -177,17 +177,17 @@ orientation(NXorientation_set):--> - Combined storage of all primitives of all hexahedra. + Combined storage of all primitives of all hexahedra. - + - Individual storage of each hexahedron. + Individual storage of each hexahedron. - + - Individual storage of each hexahedron as a graph. + Individual storage of each hexahedron as a graph. diff --git a/contributed_definitions/NXcg_marching_cubes.nxdl.xml b/contributed_definitions/NXcg_marching_cubes.nxdl.xml index ba7b6918de..d0779fe517 100644 --- a/contributed_definitions/NXcg_marching_cubes.nxdl.xml +++ b/contributed_definitions/NXcg_marching_cubes.nxdl.xml @@ -25,30 +25,30 @@ symbols:--> - Base class to detail the marching cubes (MC) algorithm. - - Documenting which specific version of MC was used helps with understanding - how robust the results are with respect to the topology of the triangulation. + Base class to detail the marching cubes (MC) algorithm. + + Documenting which specific version of MC was used helps with understanding + how robust the results are with respect to the topology of the triangulation. - Metadata of the grid on which the here specified MC is operating. + Metadata of the grid on which the here specified MC is operating. - + - Reference to the specific implementation of marching cubes used. - - See for example the following papers for details about specific - MC implementations: - - * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ - * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ + Reference to the specific implementation of marching cubes used. + + See for example the following papers for details about specific + MC implementations: + + * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ + * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ - + - Free text field in case a proper identifier is not available. + Free text field in case a proper identifier is not available. diff --git a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml index eb56d2c866..8b5866ee91 100644 --- a/contributed_definitions/NXcg_parallelogram_set.nxdl.xml +++ b/contributed_definitions/NXcg_parallelogram_set.nxdl.xml @@ -24,54 +24,54 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The cardinality of the set, i.e. the number of parallelograms. + The cardinality of the set, i.e. the number of parallelograms. - Computational geometry description of a set of parallelograms. - - This class can also be used to describe rectangles or squares, irrespective - whether these are axis-aligned or not. The class represents different - access and description levels to embrace applied scientists and computational - geometry experts with their different views: - - * The simplest case is the communication of dimensions aka the size of a - region of interest in the 2D plane. In this case, communicating the - alignment with axes is maybe not as relevant as it is to report the area - of the ROI. - * In other cases the extent of the parallelogram is relevant though. - * Finally, in CAD models it should be possible to specify the polygons - which the parallelograms represent with exact numerical details. - - Parallelograms are important geometrical primitives as their usage for - describing many scanning experiments shows where typically parallelogram-shaped - ROIs are scanned across the surface of a sample. - - The term parallelogram will be used throughout this base class thus including - the important special cases rectangle, square, 2D box, axis-aligned bounding box - (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D - counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. - - An axis-aligned bounding box is a common data object in computational science - and simulation codes to represent a rectangle whose edges are aligned with the - axes of a coordinate system. As a part of binary trees AABBs are important data - objects for executing time- as well as space-efficient queries - of geometric primitives in techniques like kd-trees. - - An optimal bounding box is a common data object which provides the best, i.e. - most tightly fitting box about an arbitrary object. In general such boxes are - rotated. Other than in 3D dimensions, the rotation calipher method offers - a rigorous approach to compute an optimal bounding box to a point set in 2D. + Computational geometry description of a set of parallelograms. + + This class can also be used to describe rectangles or squares, irrespective + whether these are axis-aligned or not. The class represents different + access and description levels to embrace applied scientists and computational + geometry experts with their different views: + + * The simplest case is the communication of dimensions aka the size of a + region of interest in the 2D plane. In this case, communicating the + alignment with axes is maybe not as relevant as it is to report the area + of the ROI. + * In other cases the extent of the parallelogram is relevant though. + * Finally, in CAD models it should be possible to specify the polygons + which the parallelograms represent with exact numerical details. + + Parallelograms are important geometrical primitives as their usage for + describing many scanning experiments shows where typically parallelogram-shaped + ROIs are scanned across the surface of a sample. + + The term parallelogram will be used throughout this base class thus including + the important special cases rectangle, square, 2D box, axis-aligned bounding box + (AABB), or optimal bounding box (OBB) as analogous 2D variants to their 3D + counterparts. See :ref:`NXcg_hexahedron_set` for the generalization in 3D. + + An axis-aligned bounding box is a common data object in computational science + and simulation codes to represent a rectangle whose edges are aligned with the + axes of a coordinate system. As a part of binary trees AABBs are important data + objects for executing time- as well as space-efficient queries + of geometric primitives in techniques like kd-trees. + + An optimal bounding box is a common data object which provides the best, i.e. + most tightly fitting box about an arbitrary object. In general such boxes are + rotated. Other than in 3D dimensions, the rotation calipher method offers + a rigorous approach to compute an optimal bounding box to a point set in 2D. - To specify which parallelogram is a rectangle. + To specify which parallelogram is a rectangle. @@ -79,9 +79,9 @@ - Only to be used if is_rectangle is present. In this case, this field - describes whether parallelograms are rectangles whose primary edges - are parallel to the axes of the coordinate system. + Only to be used if is_rectangle is present. In this case, this field + describes whether parallelograms are rectangles whose primary edges + are parallel to the axes of the coordinate system. @@ -89,18 +89,16 @@ - + - Combined storage of all primitives of all parallelograms. + Combined storage of all primitives of all parallelograms. - + - Individual storage of each parallelogram. + Individual storage of each parallelogram. - diff --git a/contributed_definitions/NXcg_polygon_set.nxdl.xml b/contributed_definitions/NXcg_polygon_set.nxdl.xml index 2f97f7d2ea..976af1136e 100644 --- a/contributed_definitions/NXcg_polygon_set.nxdl.xml +++ b/contributed_definitions/NXcg_polygon_set.nxdl.xml @@ -27,78 +27,76 @@ when using the defines_plc and related topological and boundary constraint descriptors.--> - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be either 2 or 3. + The dimensionality, which has to be either 2 or 3. - The cardinality of the set, i.e. the number of polygons. + The cardinality of the set, i.e. the number of polygons. - The total number of vertices when visiting every polygon. + The total number of vertices when visiting every polygon. - + - Computational geometry description of a set of polygons in Euclidean space. - - Polygons are specialized polylines: - - * A polygon is a geometric primitive that is bounded by a closed polyline - * All vertices of this polyline lay in the d-1 dimensional plane. - whereas vertices of a polyline do not necessarily lay on a plane. - * A polygon has at least three vertices. - - Each polygon is built from a sequence of vertices (points with identifiers). - The members of a set of polygons may have a different number of vertices. - Sometimes a collection/set of polygons is referred to as a soup of polygons. - - As three-dimensional objects, a set of polygons can be used to define the - hull of what is effectively a polyhedron; however users are advised to use - the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed - polyhedra. Even more general complexes can be thought of. An example are the - so-called piecewise-linear complexes used in the TetGen library. - - As these complexes can have holes though, polyhedra without holes are one - subclass of such complexes, users should rather design an own - base class e.g. NXcg_polytope_set to describe such even more - complex primitives instead of abusing this base class for such purposes. + Computational geometry description of a set of polygons in Euclidean space. + + Polygons are specialized polylines: + + * A polygon is a geometric primitive that is bounded by a closed polyline + * All vertices of this polyline lay in the d-1 dimensional plane. + whereas vertices of a polyline do not necessarily lay on a plane. + * A polygon has at least three vertices. + + Each polygon is built from a sequence of vertices (points with identifiers). + The members of a set of polygons may have a different number of vertices. + Sometimes a collection/set of polygons is referred to as a soup of polygons. + + As three-dimensional objects, a set of polygons can be used to define the + hull of what is effectively a polyhedron; however users are advised to use + the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed + polyhedra. Even more general complexes can be thought of. An example are the + so-called piecewise-linear complexes used in the TetGen library. + + As these complexes can have holes though, polyhedra without holes are one + subclass of such complexes, users should rather design an own + base class e.g. NXcg_polytope_set to describe such even more + complex primitives instead of abusing this base class for such purposes. - The total number of vertices in the set. + The total number of vertices in the set. - Combined storage of all primitives of all polygons. + Combined storage of all primitives of all polygons. - + - Individual storage of the mesh of each polygon. + Individual storage of the mesh of each polygon. - + - Individual storage of each polygon as a graph. + Individual storage of each polygon as a graph. - For each polygon its accumulated length along its edges. + For each polygon its accumulated length along its edges. @@ -106,11 +104,11 @@ somewhat redundant as there is NXoff_geometry but easier to understand - Interior angles for each polygon. There are as many values per polygon - as the are number_of_vertices. - The angle is the angle at the specific vertex, i.e. between the adjoining - edges of the vertex according to the sequence in the polygons array. - Usually, the winding_order field is required to interpret the value. + Interior angles for each polygon. There are as many values per polygon + as the are number_of_vertices. + The angle is the angle at the specific vertex, i.e. between the adjoining + edges of the vertex according to the sequence in the polygons array. + Usually, the winding_order field is required to interpret the value. @@ -118,11 +116,11 @@ somewhat redundant as there is NXoff_geometry but easier to understand - Curvature type: - - * 0 - unspecified, - * 1 - convex, - * 2 - concave + Curvature type: + + * 0 - unspecified, + * 1 - convex, + * 2 - concave diff --git a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml index 93ce32882b..65ebec1342 100644 --- a/contributed_definitions/NXcg_polyhedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_polyhedron_set.nxdl.xml @@ -34,40 +34,40 @@ for clean graph-based descriptions of polyhedra.--> - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The cardinality of the set, i.e. the number of polyhedra. + The cardinality of the set, i.e. the number of polyhedra. - The total number of edges for all polyhedra. + The total number of edges for all polyhedra. - The total number of faces for all polyhedra. + The total number of faces for all polyhedra. - Computational geometry description of a set of polyhedra in Euclidean space. - - Polyhedra or so-called cells (especially in the convex of tessellations) are - constructed from polygon meshes. Polyhedra may make contact to allow a usage - of this base class for a description of tessellations. - - For the description of more complicated manifolds and especially for polyhedra - with holes, users are advised to check if their particular needs are described - by creating customized instances of an :ref:`NXcg_polygon_set`. + Computational geometry description of a set of polyhedra in Euclidean space. + + Polyhedra or so-called cells (especially in the convex of tessellations) are + constructed from polygon meshes. Polyhedra may make contact to allow a usage + of this base class for a description of tessellations. + + For the description of more complicated manifolds and especially for polyhedra + with holes, users are advised to check if their particular needs are described + by creating customized instances of an :ref:`NXcg_polygon_set`. - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. + The number of faces for each polyhedron. Faces of adjoining polyhedra + are counted for each polyhedron. @@ -75,7 +75,7 @@ for clean graph-based descriptions of polyhedra.--> - Area of each of faces. + Area of each of faces. @@ -83,13 +83,13 @@ for clean graph-based descriptions of polyhedra.--> - The number of edges for each polyhedron. Edges of adjoining polyhedra - are counterd for each polyhedron. + The number of edges for each polyhedron. Edges of adjoining polyhedra + are counterd for each polyhedron. - Length of each edge. + Length of each edge. @@ -98,17 +98,17 @@ for clean graph-based descriptions of polyhedra.--> - Combined storage of all primitives of all polyhedra. + Combined storage of all primitives of all polyhedra. - + - Individual storage of each polyhedron. + Individual storage of each polyhedron. - + - Individual storage of each polygon as a graph. + Individual storage of each polygon as a graph. diff --git a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml index 22f5d692fc..aa6a8539b1 100644 --- a/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml +++ b/contributed_definitions/NXcg_tetrahedron_set.nxdl.xml @@ -24,25 +24,25 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The cardinality of the set, i.e. the number of tetrahedra. + The cardinality of the set, i.e. the number of tetrahedra. - Computational geometry description of a set of tetrahedra. - - Among hexahedral elements, tetrahedral elements are one of the most - frequently used geometric primitive for meshing and describing volumetric - objects in continuum-field simulations. + Computational geometry description of a set of tetrahedra. + + Among hexahedral elements, tetrahedral elements are one of the most + frequently used geometric primitive for meshing and describing volumetric + objects in continuum-field simulations. - Area of each of the four triangular faces of each tetrahedron. + Area of each of the four triangular faces of each tetrahedron. @@ -51,7 +51,7 @@ - Length of each edge of each tetrahedron. + Length of each edge of each tetrahedron. @@ -61,26 +61,25 @@ - Combined storage of all primitives of all tetrahedra. + Combined storage of all primitives of all tetrahedra. - + - Individual storage of each tetrahedron. + Individual storage of each tetrahedron. - + - Individual storage of each tetrahedron as a graph. + Individual storage of each tetrahedron as a graph. diff --git a/contributed_definitions/NXcg_triangle_set.nxdl.xml b/contributed_definitions/NXcg_triangle_set.nxdl.xml index 60996f281d..6e87a68614 100644 --- a/contributed_definitions/NXcg_triangle_set.nxdl.xml +++ b/contributed_definitions/NXcg_triangle_set.nxdl.xml @@ -24,58 +24,58 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - The dimensionality, which has to be at least 2. + The dimensionality, which has to be at least 2. - The cardinality of the set, i.e. the number of triangles. + The cardinality of the set, i.e. the number of triangles. - The number of unique vertices supporting the triangles. + The number of unique vertices supporting the triangles. - Computational geometry description of a set of triangles. + Computational geometry description of a set of triangles. - Number of unique vertices in the triangle set. + Number of unique vertices in the triangle set. - Combined storage of all primitives of all triangles. - - This description resembles the typical representation of primitives - in file formats such as OFF, PLY, VTK, or STL. + Combined storage of all primitives of all triangles. + + This description resembles the typical representation of primitives + in file formats such as OFF, PLY, VTK, or STL. - + - Individual storage of each triangle. - Users are advised that using such individual storage of primitives - may be less storage efficient than creating a combined storage. + Individual storage of each triangle. + Users are advised that using such individual storage of primitives + may be less storage efficient than creating a combined storage. - - Length of the edges of each triangle. - - For each triangle values are reported via traversing - the vertices in the sequence as these are defined. + Length of the edges of each triangle. + + For each triangle values are reported via traversing + the vertices in the sequence as these are defined. @@ -84,10 +84,10 @@ properties of triangles--> - Interior angles of each triangle. - - For each triangle values are reported for the angle opposite - to the respective edges in the sequence how vertices are defined. + Interior angles of each triangle. + + For each triangle values are reported for the angle opposite + to the respective edges in the sequence how vertices are defined. diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml index 2b67795ef7..67c7a2a9d7 100644 --- a/contributed_definitions/NXchamber.nxdl.xml +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class for a chamber in an instrument that stores real or simulated objects. @@ -37,5 +37,4 @@ For example out of which material was the chamber built. - diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/contributed_definitions/NXcollectioncolumn.nxdl.xml index 317bea84c7..4f59e3a655 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/contributed_definitions/NXcollectioncolumn.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. @@ -81,37 +81,6 @@ The magnification of the electron lens assembly. - - - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component 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. - - The size and position of an aperture inserted in the column, e.g. field aperture diff --git a/contributed_definitions/NXcontainer.nxdl.xml b/contributed_definitions/NXcontainer.nxdl.xml index c32854f305..075f843e96 100644 --- a/contributed_definitions/NXcontainer.nxdl.xml +++ b/contributed_definitions/NXcontainer.nxdl.xml @@ -3,7 +3,7 @@ - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. + Base class to hold different coordinate systems and representation conversions. + + How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? + + * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across + the application definition, an instance of NXcoordinate_system is defined, + the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ + coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and + NXcoordinate_system base classes backwards compatible to older + NeXus conventions and classes. + * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed + as high up in the node hierarchy (ideally right below an instance of NXentry) + of the application definition tree as possible. + This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system + instance. This shall be named such that it is clear how this coordinate system is + typically referred to in a community. For the NeXus `McStas coordinate system, it is + advised to call it mcstas for the sake of improved clarity. + Additional NXcoordinate_system instances should be specified if possible in that same + :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. + + If this is the case, it is assumed that the NXcoordinate_system_members + overwrite the NeXus default McStas coordinate system, i.e. users can thereby + conveniently and explicitly specify the coordinate system(s) that + they wish to use. + + Users are encouraged to write also explicit and clean depends_on fields in + all groups that encode information about where the interpretation of coordinate + systems is relevant. If these depends_on hints are not provided, it is + automatically assumed that all children (to arbitrary depth) + of that branch and sub-branches below the one in which that + :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set + instance in that set or the application definition is considered + underconstrained which should at all costs be avoided and in which case + again McStas is assumed. + * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified + somewhere in the tree, different interpretations are possible as to which + of these coordinate system sets and instances apply or take preference. + We realize that such ambiguities should at all costs be avoided. + However, the opportunity for multiple sets and their instances enables to + have branch-specific coordinate system conventions which could especially + be useful for deep classes where multiple scientific methods are combined or + cases where having a definition of global translation and conversion tables + how to convert between representations in different coordinate systems + is not desired or available for now. + We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective + NXcoordinate_system instances makes the interpretation eventually unnecessary + complicated. Instead, developers of application definitions should always try + to work for clarity and thus use only one top-level coordinate system set. + + For these reasons we conclude that the option with one top-level + :ref:`NXcoordinate_system_set` instance is the preferred choice. + + McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance + of NXcoordinate_system is specified. However, even in this case it is better + to be explicit like for every other coordinate system definition to support + users with interpreting the content and logic behind every instance of the tree. + + How to store coordinate systems inside :ref:`NXcoordinate_system_set`? + Individual coordinate systems should be specified as members of the + :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. + + How many individual instances of NXcoordinate_system to allow within one + instance of :ref:`NXcoordinate_system_set`? + + * 0; This case should be avoided for the sake of clarity but this case could + mean the authors of the definition meant that McStas is used. We conclude, + McStas is used in this case. + * 1; Like above-mentioned this case has the advantage that it is explicit + and faces no ambiguities. However, in reality typically multiple + coordinate systems have to be mastered especially for complex + multi-signal modality experiments. + * 2 or more; If this case is realized, the best practice is that in every + case where a coordinate system should be referred to the respective class + has a depends_on field which resolves the possible ambiguities which specific + coordinate systems is referred to. The benefit of this explicit and clear + specifying of the coordinate system used in every case is that especially + in combination with having coordinate systems inside deeper branches + makes up for a very versatile, backwards compatible, but powerful system + to express different types of coordinate systems using NeXus. In the case + of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, + it is also advised to specify the relationship between the two coordinate systems by + using the (NXtransformations) group within NXcoordinate_system. + + In effect, 1 should be the preferred choice. However, if more than one coordinate + system is defined for practical purposes, explicit depends_on fields should + always guide the user for each group and field which of the coordinate system + one refers to. - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. + Convention how a positive rotation angle is defined when viewing + from the end of the rotation unit vector towards its origin, + i.e. in accordance with convention 2 of + DOI: 10.1088/0965-0393/23/8/083501. + Counter_clockwise is equivalent to a right-handed choice. + Clockwise is equivalent to a left-handed choice. @@ -131,9 +131,9 @@ use depends_on field - not attribute - to point to conventions used--> - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. @@ -143,12 +143,12 @@ use depends_on field - not attribute - to point to conventions used--> - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. + How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) + according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. + + The most frequently used convention is zxz, which is based on the work of H.-J. Bunge + but other conventions are possible. Apart from undefined, proper Euler angles + are distinguished from (improper) Tait-Bryan angles. @@ -168,9 +168,9 @@ use depends_on field - not attribute - to point to conventions used--> - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. + To which angular range is the rotation angle argument of an + axis-angle pair parameterization constrained according to + convention 5 of DOI: 10.1088/0965-0393/23/8/083501. @@ -179,9 +179,9 @@ use depends_on field - not attribute - to point to conventions used--> - Which sign convention is followed when converting orientations - between different parameterizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. + Which sign convention is followed when converting orientations + between different parameterizations/representations according + to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. @@ -195,46 +195,46 @@ use depends_on field - not attribute - to point to conventions used--> convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system--> - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. + Details about eventually relevant named directions that may give reasons for anisotropies. + The classical example is mechanical processing where one has to specify which directions + (e.g. rolling, transverse, and normal direction) align how with the direction of the base + vectors of the sample_reference_frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xp, Yp, Zp. - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. + Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xs, Ys, Zs. - + - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. + Details about the detector_reference_frame for a specific detector. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the + base vectors of this coordinate system as Xd, Yd, Zd. + + It is assumed that the configuration is inspected by looking towards the sample surface + from a position that is located behind the detector. + + If any of these assumptions is not met, the user is required to explicitly state this. diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml index 241195445f..e5ca234e02 100644 --- a/contributed_definitions/NXcorrector_cs.nxdl.xml +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -26,60 +26,60 @@ https://doi.org/10.1017/9781316337455.022--> - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of images taken, at least one. + Number of images taken, at least one. - Base class for a corrector reducing (spherical) aberrations in electron microscopy. - - Different technology partners use different naming schemes and - models for quantifying the aberration coefficients. - - The corrector in an electron microscope is composed of multiple lenses - and multipole stigmators with details specific for the technology partner - and microscope. Many of their technical details is proprietary knowledge. - - If functionalities for correcting multiple aberrations are included in - one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ - use multiple groups: - - * :ref:`NXcorrector_cs` for spherical aberration - * :ref:`NXmonochromator` for energy filtering or chromatic aberration - * corrector_ax in :ref:`NXem` for axial astigmatism correction + Base class for a corrector reducing (spherical) aberrations in electron microscopy. + + Different technology partners use different naming schemes and + models for quantifying the aberration coefficients. + + The corrector in an electron microscope is composed of multiple lenses + and multipole stigmators with details specific for the technology partner + and microscope. Many of their technical details is proprietary knowledge. + + If functionalities for correcting multiple aberrations are included in + one :ref:`NXcomponent` `like it is reported here <https://www.ceos-gmbh.de/en/research/electrostat>`_ + use multiple groups: + + * :ref:`NXcorrector_cs` for spherical aberration + * :ref:`NXmonochromator` for energy filtering or chromatic aberration + * corrector_ax in :ref:`NXem` for axial astigmatism correction - Was the corrector used? + Was the corrector used? - + - Specific information about the alignment procedure that is a process during which - the corrector is configured to enable calibrated usage of the instrument. - - This :ref:`NXprocess` group should also be used when one describes in a computer - simulation the specific details about the modelled or assumed aberration - corrections. + Specific information about the alignment procedure that is a process during which + the corrector is configured to enable calibrated usage of the instrument. + + This :ref:`NXprocess` group should also be used when one describes in a computer + simulation the specific details about the modelled or assumed aberration + corrections. - Discouraged free-text field to add further details about the alignment - procedure. + Discouraged free-text field to add further details about the alignment + procedure. - The outer tilt angle of the beam in tableau acquisition. - - TODO: The relevant axes which span the tilt_angle need a - cleaner description. + The outer tilt angle of the beam in tableau acquisition. + + TODO: The relevant axes which span the tilt_angle need a + cleaner description. @@ -87,7 +87,7 @@ https://doi.org/10.1017/9781316337455.022--> - The exposure time of single tilt images. + The exposure time of single tilt images. @@ -95,8 +95,8 @@ https://doi.org/10.1017/9781316337455.022--> - The factor of enlargement of the apparent size, - not the physical size, of an object. + The factor of enlargement of the apparent size, + not the physical size, of an object. @@ -104,16 +104,16 @@ https://doi.org/10.1017/9781316337455.022--> - The images taken during the alignment procedure. + The images taken during the alignment procedure. - Place for storing measured or estimated aberrations (for each image or final). - - See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) - for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how - to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. + Place for storing measured or estimated aberrations (for each image or final). + + See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how + to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. @@ -123,13 +123,13 @@ https://doi.org/10.1017/9781316337455.022--> +unit: NX_LENGTH--> +unit: NX_LENGTH--> +unit: NX_LENGTH--> +unit: NX_LENGTH--> @@ -155,7 +155,7 @@ https://doi.org/10.1017/9781316337455.022--> +unit: NX_LENGTH--> @@ -168,7 +168,7 @@ https://doi.org/10.1017/9781316337455.022--> +unit: NX_LENGTH--> diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml index d20c14d90d..a8a1c5f90f 100644 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ b/contributed_definitions/NXcrystal_structure.nxdl.xml @@ -71,12 +71,12 @@ used algorithm. Dictionary-based alternatives are emerging.--> - + Reference to another resource that was used for instantiating this structure model. - + Crystallography unit cell parameters a, b, and c. @@ -154,7 +154,7 @@ used algorithm. Dictionary-based alternatives are emerging.--> False if space group is consider a non-chiral one. - + Identifier for each phase. @@ -173,11 +173,11 @@ used algorithm. Dictionary-based alternatives are emerging.--> Name of the phase/alias. - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. + If the ``identifier_phase`` is 0 and one would like to use the field + ``phase_name``, the value should be n/a. - + Label for each atom position. diff --git a/contributed_definitions/NXcsg.nxdl.xml b/contributed_definitions/NXcsg.nxdl.xml index b095387486..941620273b 100644 --- a/contributed_definitions/NXcsg.nxdl.xml +++ b/contributed_definitions/NXcsg.nxdl.xml @@ -3,7 +3,7 @@ - + Deflectors as they are used e.g. in an electron analyser. @@ -39,14 +39,7 @@ Colloquial or short name for the deflector. For manufacturer names and - identifiers use respective manufacturer fields. - - - - - - Ideally an identifier, persistent link, or free text which gives - further details about the deflector. + identifiers use ``NXfabrication`` and ``identifierNAME``. @@ -73,22 +66,4 @@ ```offset_x```). - - - Specifies the position of the deflector by pointing to the last transformation - in the transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - :ref:`NXtransformations` base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index 075928fd10..ed2f3bcd35 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -1,4 +1,4 @@ - + - + - NXdispersion + NXdispersion - An application definition for a dispersive material. + An application definition for a dispersive material. - Version number to identify which definition of this application definition was - used for this entry/data. + Version number to identify which definition of this application definition was + used for this entry/data. - URL where to find further material (documentation, examples) relevant to the - application definition + URL where to find further material (documentation, examples) relevant to the + application definition + + + Name of the program used for creating this dispersion + + + + + Version of the program used + + + + + Date and time of creating this dispersion. + + - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. - The colloquial name of the material, e.g. graphite or diamond for carbon. + The colloquial name of the material, e.g. graphite or diamond for carbon. - The phase of the material + The phase of the material @@ -74,47 +89,47 @@ - Additional information about the phase if the - material phase is other. + Additional information about the phase if the + material phase is other. - This field may be used to denote additional phase information, - such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. + This field may be used to denote additional phase information, + such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. - Denotes whether the dispersion is calculated or derived from an experiment + Denotes whether the dispersion is calculated or derived from an experiment - + - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagionalized permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -146,13 +161,13 @@ - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagionalized + permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -184,14 +199,14 @@ - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized perimittivty tensor. + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagionalized perimittivty tensor. - The name of this dispersion model. + The name of this dispersion model. diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml index 3df6b9c0d7..8c62f652d2 100644 --- a/contributed_definitions/NXebeam_column.nxdl.xml +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -21,10 +21,9 @@ # # For further information, see http://www.nexusformat.org --> - - + + Base class for a set of components providing a controllable electron beam. diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml index 29eb93d453..cb37242323 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 @@ -240,37 +240,6 @@ - - - Refers to the last transformation specifying the position of the electron analyser - in the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or "." (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - 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 diff --git a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml index 552eb562a6..16d9bfeab8 100644 --- a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml +++ b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml @@ -3,7 +3,7 @@ - +Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus. +This explicitly refers to a wish to add: "exposure time, number of scans"--> - Variables used throughout the document, e.g. dimensions or parameters. + Variables used throughout the document, e.g. dimensions or parameters. - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. - Number of detection angles of the beam reflected or scattered off the - sample. + Number of detection angles of the beam reflected or scattered off the + sample. - Number of angles of incidence of the incident beam. + Number of angles of incidence of the incident beam. - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition specifies optical spectroscopy (NXopt), by extending - the terms and setting specific requirements. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition specifies optical spectroscopy (NXopt), by extending + the terms and setting specific requirements. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 - An application definition for ellipsometry. + An application definition for ellipsometry. - Version number to identify which definition of this application - definition was used for this entry/data. + Version number to identify which definition of this application + definition was used for this entry/data. - URL where to find further material (documentation, examples) relevant - to the application definition. + URL where to find further material (documentation, examples) relevant + to the application definition. @@ -136,9 +135,9 @@ TODO (Workshop output): - Specify the type of the optical experiment. - - You may specify fundamental characteristics or properties in the experimental sub-type. + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. @@ -146,7 +145,7 @@ TODO (Workshop output): - Specify the type of ellipsometry. + Specify the type of ellipsometry. @@ -160,16 +159,16 @@ TODO (Workshop output): - If the ellipsometry_experiment_type is `other`, a name should be specified here. + If the ellipsometry_experiment_type is `other`, a name should be specified here. - Properties of the ellipsometry equipment. + Properties of the ellipsometry equipment. - What type of ellipsometry was used? See Fujiwara Table 4.2. + What type of ellipsometry was used? See Fujiwara Table 4.2. @@ -189,13 +188,13 @@ TODO (Workshop output): - If the ellipsometer_type is `other`, a specific ellipsometry_type" should be - added here. + If the ellipsometer_type is `other`, a specific ellipsometry_type" should be + added here. - Define which element rotates, e.g. polarizer or analyzer. + Define which element rotates, e.g. polarizer or analyzer. @@ -206,8 +205,8 @@ TODO (Workshop output): - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. @@ -221,39 +220,39 @@ TODO (Workshop output): - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? - Specify the angular spread caused by the focussing probes. + Specify the angular spread caused by the focussing probes. - Properties of the rotating element defined in - 'instrument/rotating_element_type'. + Properties of the rotating element defined in + 'instrument/rotating_element_type'. - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). - Specify the maximum value of revolutions of the rotating element - for each measurement. + Specify the maximum value of revolutions of the rotating element + for each measurement. @@ -261,8 +260,8 @@ TODO (Workshop output): - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. @@ -273,32 +272,32 @@ included in the generic NXopt, but is now keept limited to NXellipsometry.--> - Measured data, data errors, and varied parameters. This may be used to describe - indirectly derived data or data transformed between different descriptions, - such as: - Raw Data --> Psi - Delta Psi, Delta --> N,C,S - Mueller matrix --> N,C,S - Mueller matrix --> Psi, Delta - etc. - - Other types of data, such as temperature or sample location, may be saved - in a generic (NXdata) concept from NXopt, or better directly in the - location of the sample positioner or temperature sensor. + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. - An identifier to correlate data to the experimental conditions, - if several were used in this measurement; typically an index of 0-N. + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. - Select which type of data was recorded, for example intensity, - reflectivity, transmittance, Psi and Delta etc. - It is possible to have multiple selections. The enumeration list - depends on the type of experiment and may differ for different - application definitions. + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. @@ -312,36 +311,36 @@ NXellipsometry.--> - + - Spectral values (e.g. wavelength or energy) used for the measurement. - An array of 1 or more elements. Length defines N_spectrum. Replace - 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. - Resulting data from the measurement, described by 'data_type'. - - The first dimension is defined by the number of measurements taken, - (N_measurements). The instructions on how to order the values - contained in the parameter vectors given in the doc string of - INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, - define the N_measurements parameter sets. For example, if the - experiment was performed at three different temperatures - (T1, T2, T3), two different pressures (p1, p2) and two different - angles of incidence (a1, a2), the first measurement was taken at the - parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. @@ -350,16 +349,16 @@ NXellipsometry.--> - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. - Specified uncertainties (errors) of the data described by 'data_type' - and provided in 'measured_data'. + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. @@ -368,16 +367,16 @@ NXellipsometry.--> - If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. - If the unit of the measured data is not covered by NXDL units state - here which unit was used. + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. - List of links to the values of the sensors. Add a link for each - varied parameter (i.e. for each sensor). + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). @@ -385,35 +384,35 @@ NXellipsometry.--> - Link to the NeXus file which describes the reference data if a - reference measurement was performed. Ideally, the reference - measurement was performed using the same conditions as the actual - measurement and should be as close in time to the actual measurement - as possible. + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and/or - metadata (in most cases, this is the same as INSTRUMENT/software). - If home written, one can provide the actual steps in the NOTE - subfield here. + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. - Website of the software. + Website of the software. diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml index 8e8e2ab972..04412665ac 100644 --- a/contributed_definitions/NXem.nxdl.xml +++ b/contributed_definitions/NXem.nxdl.xml @@ -23,15 +23,15 @@ --> - Application definition for normalized representation of electron microscopy research. - - This application definition is a comprehensive example for a general description - with which to normalize specific pieces of information and data collected within - electron microscopy research. - - NXem is designed to be used for documenting experiments or computer simulations in which - controlled electron beams are used for studying electron-beam matter interaction to explore - physical mechanisms and phenomena, or to characterize materials with an electron microscope. + Application definition for normalized representation of electron microscopy research. + + This application definition is a comprehensive example for a general description + with which to normalize specific pieces of information and data collected within + electron microscopy research. + + NXem is designed to be used for documenting experiments or computer simulations in which + controlled electron beams are used for studying electron-beam matter interaction to explore + physical mechanisms and phenomena, or to characterize materials with an electron microscope. @@ -55,262 +55,248 @@ starting to reorganize the docstrings, as a list of blocks: - The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) - which was used to generate this NeXus file instance. + The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) + which was used to generate this NeXus file instance. - + - A collection of all programs and libraries that are considered as relevant - to understand with which software tools this NeXus file instance was - generated. Ideally, to enable a binary recreation from the input data. - - Examples include the name and version of the libraries used to write the - instance. Ideally, the software which writes these NXprogram instances - also includes the version of the set of NeXus classes i.e. the specific - set of base classes, application definitions, and contributed definitions - with which the here described concepts can be resolved. - - For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ - which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ - research data management system, it makes sense to store e.g. the GitHub - repository commit and respective submodule references used. + A collection of all programs and libraries that are considered as relevant + to understand with which software tools this NeXus file instance was + generated. Ideally, to enable a binary recreation from the input data. + + Examples include the name and version of the libraries used to write the + instance. Ideally, the software which writes these NXprogram instances + also includes the version of the set of NeXus classes i.e. the specific + set of base classes, application definitions, and contributed definitions + with which the here described concepts can be resolved. + + For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ + which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ + research data management system, it makes sense to store e.g. the GitHub + repository commit and respective submodule references used. - + - Ideally, a (globally) unique persistent identifier for referring to this experiment. - - An experiment should be understood in that this can be an experiment - in reality or a computer simulation because also the latter is an experiment - (see the Cambridge Dictionary experiment *a test done in order to find out - something, eg if an idea is correct*). - - The identifier is usually issued by the facility, laboratory, or the principle investigator. - The identifier enables to link experiments/simulations to e.g. proposals. + Ideally, a (globally) unique persistent identifier for referring to this experiment. + + An experiment should be understood in that this can be an experiment + in reality or a computer simulation because also the latter is an experiment + (see the Cambridge Dictionary experiment *a test done in order to find out + something, eg if an idea is correct*). + + The identifier is usually issued by the facility, laboratory, or the principle investigator. + The identifier enables to link experiments/simulations to e.g. proposals. - - - - + - Alias which scientists can easier identify this experiment by. + Alias which scientists can easier identify this experiment by. - Free-text description about the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into the field. The reason is that such free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn in how far the - current base classes need extension based on user feedback. + Free-text description about the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into the field. The reason is that such free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn in how far the + current base classes need extension based on user feedback. - ISO 8601 time code with local time zone offset to UTC information included - when the microscope session started. If the application demands that time - codes in this section of the application definition should only be used - for specifying when the experiment was performed - and the exact - duration is not relevant use this start_time field. - - Often though it is useful to specify a time interval via setting both a start_time - and an end_time because this enables software tools and users to collect a - more detailed bookkeeping of the experiment. - - Users should be aware though that even with having both time instances - specified, it may not be possible to infer how long the experiment took or - for how long data were acquired. - - More detailed timing data over the course of the experiment have - to be collected to compute this. These computations can take - advantage of individual time stamps start_time and end_time - in :ref:`NXevent_data_em` instances. + ISO 8601 time code with local time zone offset to UTC information included + when the microscope session started. If the application demands that time + codes in this section of the application definition should only be used + for specifying when the experiment was performed - and the exact + duration is not relevant use this start_time field. + + Often though it is useful to specify a time interval via setting both a start_time + and an end_time because this enables software tools and users to collect a + more detailed bookkeeping of the experiment. + + Users should be aware though that even with having both time instances + specified, it may not be possible to infer how long the experiment took or + for how long data were acquired. + + More detailed timing data over the course of the experiment have + to be collected to compute this. These computations can take + advantage of individual time stamps start_time and end_time + in :ref:`NXevent_data_em` instances. - ISO 8601 time code with local time zone offset to UTC included when - the microscope session ended. - - See docstring of the start_time field to see how to use the - start_time and end_time together. + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + See docstring of the start_time field to see how to use the + start_time and end_time together. - - + + - Possibility to store a collection of serialized resources associated with the - experiment. - - An example how to use this set could be to document from which files, which have been - e.g. generated by software of technology partners, the information in an instance of - NXem was filled with during parsing or transcoding between different formats. + Possibility to store a collection of serialized resources associated with the + experiment. + + An example how to use this set could be to document from which files, which have been + e.g. generated by software of technology partners, the information in an instance of + NXem was filled with during parsing or transcoding between different formats. - + - - + + - Information about persons who performed or were involved in the microscope - session or simulation run. - - This can be the principle investigator who performed this experiment or the student who performed simulations. - Adding multiple users if relevant is recommended. + Information about persons who performed or were involved in the microscope + session or simulation run. + + This can be the principle investigator who performed this experiment or the student who performed simulations. + Adding multiple users if relevant is recommended. - Given (first) name and surname. + Given (first) name and surname. - Name of the affiliation at the point in time when the experiment was performed. + Name of the affiliation at the point in time when the experiment was performed. - Postal address of the affiliation. + Postal address of the affiliation. - Email address at the point in time when the experiment was performed. - - Writing the most permanently used email is recommended. + Email address at the point in time when the experiment was performed. + + Writing the most permanently used email is recommended. - Telephone number at the point in time when the experiment was performed. + Telephone number at the point in time when the experiment was performed. - User role at the point in time when the experiment was performed. - - Examples are technician operating the microscope, student, postdoc, - principle investigator, or guest. + User role at the point in time when the experiment was performed. + + Examples are technician operating the microscope, student, postdoc, + principle investigator, or guest. - + - Identifier offered by a service to report the user other than by using its name. - - Examples could be an ORCID or social media account of the user. + Identifier offered by a service to report the user other than by using its name. + + Examples could be an ORCID or social media account of the user. - - - - + - A physical entity which contains material intended to be investigated. - Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. - - This concept is related to term `Specimen`_ of the EMglossary standard. - - .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 + A physical entity which contains material intended to be investigated. + Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. + + This concept is related to term `Specimen`_ of the EMglossary standard. + + .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 - Qualifier whether the sample is a real or a virtual one. + Qualifier whether the sample is a real or a virtual one. - + - Ideally, (globally) unique persistent identifier which distinguishes the sample from all others - and especially the predecessor/origin from where that sample was cut. The terms sample - and specimen are here considered as exact synonyms. - - This field must not be used for an alias! Instead, use name. - - In cases where multiple specimens were loaded into the microscope, the identifier has to resolve - the specific sample, whose results are stored by this :ref:`NXentry` instance because a single - NXentry should be used for the characterization of a single specimen. - - Details about the specimen preparation should be stored in resources referring to parent_identifier. + Ideally, (globally) unique persistent identifier which distinguishes the sample from all others + and especially the predecessor/origin from where that sample was cut. The terms sample + and specimen are here considered as exact synonyms. + + This field must not be used for an alias! Instead, use name. + + In cases where multiple specimens were loaded into the microscope, the identifier has to resolve + the specific sample, whose results are stored by this :ref:`NXentry` instance because a single + NXentry should be used for the characterization of a single specimen. + + Details about the specimen preparation should be stored in resources referring to parent_identifier. - - - - - + + - Identifier of the sample from which the sample was cut or the string *None*. - - The purpose of this field is to support functionalities for tracking - sample provenance in a research data management system. + Identifier of the sample from which the sample was cut or the string *None*. + + The purpose of this field is to support functionalities for tracking + sample provenance in a research data management system. - - - - + - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. Ideally, this matches - the last timestamp that is mentioned in the digital resource pointed to by - parent_identifier. - - Knowing when the specimen was exposed to e.g. specific atmosphere is especially - required for environmentally sensitive material such as specimen charged with hydrogen - or experiments including tracers that have a short halflife. Additional time stamps - prior to preparation_date should better be placed in resources which describe but - which do not pollute the description here with prose. Resolving these connected - pieces of information is considered the responsibility of the - research data management system not of a NeXus file. + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. Ideally, this matches + the last timestamp that is mentioned in the digital resource pointed to by + identifier_parent. + + Knowing when the specimen was exposed to e.g. specific atmosphere is especially + required for environmentally sensitive material such as specimen charged with hydrogen + or experiments including tracers that have a short halflife. Additional time stamps + prior to preparation_date should better be placed in resources which describe but + which do not pollute the description here with prose. Resolving these connected + pieces of information is considered the responsibility of the + research data management system not of a NeXus file. - An alias used to refer to the specimen to please readability for humans. + An alias used to refer to the specimen to please readability for humans. - List of comma-separated elements from the periodic table that are contained in the sample. - If the sample substance has multiple components, all elements from each component - must be included in atom_types. - - The purpose of the field is to offer research data management systems an opportunity - to parse the relevant elements without having to interpret these from the resources - pointed to by parent_identifier or walk through eventually deeply nested groups in - individual data instances. + List of comma-separated elements from the periodic table that are contained in the sample. + If the sample substance has multiple components, all elements from each component + must be included in atom_types. + + The purpose of the field is to offer research data management systems an opportunity + to parse the relevant elements without having to interpret these from the resources + pointed to by identifier_parent or walk through eventually deeply nested groups in + individual data instances. - (Measured) sample thickness. - - The information is recorded to qualify if the beam used was likely - able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. + (Measured) sample thickness. + + The information is recorded to qualify if the beam used was likely + able to shine through the specimen. For scanning electron microscopy, + in many cases the specimen is typically thicker than what is + illuminatable by the electron beam. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. - (Measured) density of the specimen. - - For multi-layered specimens this field should only be used to describe - the density of the excited volume. For scanning electron microscopy - the usage of this field is discouraged and instead an instance of an - :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` - instances can provide a cleaner description of the relevant details - why one may wish to store the density of the specimen. + (Measured) density of the specimen. + + For multi-layered specimens this field should only be used to describe + the density of the excited volume. For scanning electron microscopy + the usage of this field is discouraged and instead an instance of an + :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` + instances can provide a cleaner description of the relevant details + why one may wish to store the density of the specimen. - Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system - should provide this contextualization. + Discouraged free-text field to provide further detail although adding + identifier_parent and having a working research data management system + should provide this contextualization. - Set to hold different coordinate systems conventions. - - Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes - how to define coordinate systems in NeXus. + Set to hold different coordinate systems conventions. + + Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes + how to define coordinate systems in NeXus. @@ -364,14 +350,14 @@ are the ibeam description capabilities not sufficient enough?--> - Location of the origin of the processing_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. + Location of the origin of the processing_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -387,8 +373,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing x-axis base vector of the - processing_reference_frame. + Direction of the positively pointing x-axis base vector of the + processing_reference_frame. @@ -402,8 +388,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing y-axis base vector of the - processing_reference_frame. + Direction of the positively pointing y-axis base vector of the + processing_reference_frame. @@ -417,8 +403,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing z-axis base vector of the - processing_reference_frame. + Direction of the positively pointing z-axis base vector of the + processing_reference_frame. @@ -434,8 +420,8 @@ are the ibeam description capabilities not sufficient enough?--> - Reference to the specifically named :ref:`NXsample` instance(s) for - which these conventions apply (e.g. /entry1/sample1). + Reference to the specifically named :ref:`NXsample` instance(s) for + which these conventions apply (e.g. /entry1/sample1). @@ -443,14 +429,14 @@ are the ibeam description capabilities not sufficient enough?--> - Location of the origin of the sample_reference_frame. - - It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. - Edges are interpreted by inspecting the direction of their outer unit normals - (which point either parallel or antiparallel) along respective base vector direction - of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. + Location of the origin of the sample_reference_frame. + + It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. + Edges are interpreted by inspecting the direction of their outer unit normals + (which point either parallel or antiparallel) along respective base vector direction + of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -466,8 +452,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing x-axis base vector of the - sample_reference_frame. + Direction of the positively pointing x-axis base vector of the + sample_reference_frame. @@ -481,8 +467,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing y-axis base vector of the - sample_reference_frame. + Direction of the positively pointing y-axis base vector of the + sample_reference_frame. @@ -496,8 +482,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing z-axis base vector of the - sample_reference_frame. + Direction of the positively pointing z-axis base vector of the + sample_reference_frame. @@ -510,11 +496,11 @@ are the ibeam description capabilities not sufficient enough?--> - + - Reference to the specifically named :ref:`NXdetector` instance for - which these conventions apply (e.g. /entry1/instrument/detector1). + Reference to the specifically named :ref:`NXdetector` instance for + which these conventions apply (e.g. /entry1/instrument/detector1). @@ -522,13 +508,13 @@ are the ibeam description capabilities not sufficient enough?--> - Location of the origin of the detector_reference_frame. - - If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted - by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) - along respective base vector direction of the reference frame. - - If any of these assumptions is not met, the user is required to explicitly state this. + Location of the origin of the detector_reference_frame. + + If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted + by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) + along respective base vector direction of the reference frame. + + If any of these assumptions is not met, the user is required to explicitly state this. @@ -544,8 +530,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing x-axis base vector of the - detector_reference_frame. + Direction of the positively pointing x-axis base vector of the + detector_reference_frame. @@ -559,8 +545,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing y-axis base vector of the - detector_reference_frame. + Direction of the positively pointing y-axis base vector of the + detector_reference_frame. @@ -574,8 +560,8 @@ are the ibeam description capabilities not sufficient enough?--> - Direction of the positively pointing z-axis base vector of the - detector_reference_frame. + Direction of the positively pointing z-axis base vector of the + detector_reference_frame. @@ -598,11 +584,11 @@ we just say we compose using the base class NXcoordinate_system--> - + - + - Details about the control program used for operating the microscope. + Details about the control program used for operating the microscope. @@ -613,13 +599,13 @@ we just say we compose using the base class NXcoordinate_system--> - + - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 + This concept is related to term `Source`_ of the EMglossary standard. + + .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 @@ -627,7 +613,7 @@ we just say we compose using the base class NXcoordinate_system--> - + - + - + - + - + - + - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + Device for improving energy resolution or reducing chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - Qualitative type of the component. + Qualitative type of the component. @@ -675,59 +661,57 @@ technical design perspective--> - + - + - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. - + - Electron biprism as it is used e.g. for electron holography. + Electron biprism as it is used e.g. for electron holography. - + - - +lenses i.e. devices which can affect the pathes of beams--> + - Device that causes a change in the phase of an electron wave. - - * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ - * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ + Device that causes a change in the phase of an electron wave. + + * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ + * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ - Qualitative type + Qualitative type @@ -737,11 +721,11 @@ lenses i.e. devices which can affect the pathes of beams - + - - + + @@ -749,35 +733,35 @@ lenses i.e. devices which can affect the pathes of beams - + - + - + - + - + - + - Device for improving energy resolution or reducing chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + Device for improving energy resolution or reducing chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - Qualitative type of the component. + Qualitative type of the component. @@ -791,26 +775,24 @@ lenses i.e. devices which can affect the pathes of beams - + - - + + - + - - + @@ -819,7 +801,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -832,19 +814,19 @@ lenses i.e. devices which can affect the pathes of beams - + - + - + - + @@ -865,7 +847,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -889,7 +871,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -916,7 +898,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -930,10 +912,10 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -943,7 +925,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -957,10 +939,10 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -973,7 +955,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -987,10 +969,10 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -1006,19 +988,19 @@ lenses i.e. devices which can affect the pathes of beams - + - + - + - + @@ -1030,7 +1012,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -1045,7 +1027,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -1063,7 +1045,7 @@ lenses i.e. devices which can affect the pathes of beams - + @@ -1084,12 +1066,12 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -1099,12 +1081,12 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -1117,12 +1099,12 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -1138,12 +1120,12 @@ lenses i.e. devices which can affect the pathes of beams - + - + @@ -1165,101 +1147,101 @@ lenses i.e. devices which can affect the pathes of beams - This concept is related to term `Source`_ of the EMglossary standard. - - .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 + This concept is related to term `Source`_ of the EMglossary standard. + + .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 - The potential difference between anode and cathode. - - This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. - - .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 + The potential difference between anode and cathode. + + This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. + + .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 - Voltage which is utilised to create an electric field that draws particles from - the source. - - This concept is related to term `Extraction Voltage`_ of the EMglossary standard. - - .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + Voltage which is utilised to create an electric field that draws particles from + the source. + + This concept is related to term `Extraction Voltage`_ of the EMglossary standard. + + .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - Electrical current which is released from the source. - - This concept is related to term `Emission Current`_ of the EMglossary standard. - - .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 + Electrical current which is released from the source. + + This concept is related to term `Emission Current`_ of the EMglossary standard. + + .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 - Electrical current which flows through the source. - - This concept is related to term `Filament Current`_ of the EMglossary standard. - - .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 + Electrical current which flows through the source. + + This concept is related to term `Filament Current`_ of the EMglossary standard. + + .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 - + - + - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. + Relevant value from the control software. + + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. - + - Device to improve energy resolution or chromatic aberration. - - Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector - like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ + Device to improve energy resolution or chromatic aberration. + + Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector + like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ - Was the corrector used? + Was the corrector used? - Energy dispersion in e.g. µm/eV. + Energy dispersion in e.g. µm/eV. - Corresponding voltage for that energy dispersion. + Corresponding voltage for that energy dispersion. - + @@ -1385,42 +1367,42 @@ ceos--> basically optional use of NXaberration therein at least some value required--> - Device reshaping an ellipse-shaped electron beam to a circular one. - - * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ - * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ - - Stigmator is an exact synonym. + Device reshaping an ellipse-shaped electron beam to a circular one. + + * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ + * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ + + Stigmator is an exact synonym. - Was the corrector used? + Was the corrector used? - Descriptor for the correction strength along the first direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). + Descriptor for the correction strength along the first direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). - Descriptor for the correction strength along the second direction when exact technical details - are unknown or not directly controllable as the control software of the microscope does not - enable or was not configured to display these values (for end users). + Descriptor for the correction strength along the second direction when exact technical details + are unknown or not directly controllable as the control software of the microscope does not + enable or was not configured to display these values (for end users). - - - + + + - This concept is related to term `Electron Beam`_ of the EMglossary standard. - - .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 + This concept is related to term `Electron Beam`_ of the EMglossary standard. + + .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 @@ -1429,36 +1411,36 @@ basically optional use of NXaberration therein at least some value required--> - + - + - Relevant value from the control software. - - This is not always just the diameter of the aperture (not even in the case) - of a circular aperture. Usually, it is a value that is set in the control - software whereby a specific configuration of an aperture is selected by the - software. - - The control software of commercial microscope typically offers the user - access at a high abstraction level because of which many details about - the actual settings of the electrical components are typically unknown. - - However, if more details are known or should be documented one should - use the description field for this. + Relevant value from the control software. + + This is not always just the diameter of the aperture (not even in the case) + of a circular aperture. Usually, it is a value that is set in the control + software whereby a specific configuration of an aperture is selected by the + software. + + The control software of commercial microscope typically offers the user + access at a high abstraction level because of which many details about + the actual settings of the electrical components are typically unknown. + + However, if more details are known or should be documented one should + use the description field for this. - + - - + + - + @@ -1470,17 +1452,17 @@ basically optional use of NXaberration therein at least some value required--> - Nominal current of the heater. + Nominal current of the heater. - Nominal voltage of the heater. + Nominal voltage of the heater. - Nominal power of the heater. + Nominal power of the heater. @@ -1498,14 +1480,14 @@ basically optional use of NXaberration therein at least some value required--> - + - A region-of-interest analyzed either during or after the session - for which specific processed data are available. - - This concept is related to term `Region Of Interest`_ of the EMglossary standard. - - .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 + A region-of-interest analyzed either during or after the session + for which specific processed data are available. + + This concept is related to term `Region Of Interest`_ of the EMglossary standard. + + .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 +nameType: partial +exists: optional--> @@ -1538,18 +1521,18 @@ is required to provide such information in this way!--> - + - + - + - + @@ -1557,53 +1540,56 @@ is required to provide such information in this way!--> - + - + - + - + +nameType: partial +exists: recommended +projection_direction(NX_NUMBER): +map(NXdata): +\@signal(NX_CHAR): +\@axes(NX_CHAR): +\@AXISNAME_indices(NX_INT): + nameType: partial +title(NX_CHAR): +data(NX_NUMBER): +\@long_name(NX_CHAR): +axis_x(NX_NUMBER): +\@long_name(NX_CHAR): +axis_y(NX_NUMBER): +exists: optional +\@long_name(NX_CHAR): +axis_z(NX_NUMBER): +exists: optional +\@long_name(NX_CHAR): +legend(NXdata): +\@signal(NX_CHAR): +\@axes(NX_CHAR): +\@AXISNAME_indices(NX_INT): + nameType: partial +title(NX_CHAR): +data(NX_NUMBER): +\@long_name(NX_CHAR): +axis_x(NX_NUMBER): +\@long_name(NX_CHAR): +axis_y(NX_NUMBER): +\@long_name(NX_CHAR):--> - + @@ -1622,7 +1608,7 @@ is required to provide such information in this way!--> - + @@ -1636,7 +1622,7 @@ is required to provide such information in this way!--> - + diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml index 45a0edfa1d..d0d3fc4c5f 100644 --- a/contributed_definitions/NXem_calorimetry.nxdl.xml +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -27,40 +27,40 @@ NeXus version, h5py version, again can be done later, we have tons of examples-- - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of pattern + Number of pattern - Number of azimuthal integration bins + Number of azimuthal integration bins - Number of coordinates along i axis. + Number of coordinates along i axis. - Number of coordinates along j axis. + Number of coordinates along j axis. - Application definition for minimal example in-situ calorimetry. - - What is the technique about. - - General context. - - Literature references. + Application definition for minimal example in-situ calorimetry. + + What is the technique about. + + General context. + + Literature references. @@ -72,7 +72,7 @@ ii) that people think hard about how their base vectors are aligned with what an - + @@ -87,47 +87,47 @@ e.g. NXem, NXapm_paraprobe_* which shows how to add context--> - Reference to the resource which stores acquired pattern from the experiment. - - Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. + Reference to the resource which stores acquired pattern from the experiment. + + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. - + - Reference to the resource which stores actuator log file from the experiment. + Reference to the resource which stores actuator log file from the experiment. - + - Assumptions and computations whereby timestamp data from the - detector used for collecting diffraction pattern and the actuator - (heating chip) were synchronized. + Assumptions and computations whereby timestamp data from the + detector used for collecting diffraction pattern and the actuator + (heating chip) were synchronized. - + - Timestamp when pattern acquisition started. + Timestamp when pattern acquisition started. @@ -135,7 +135,7 @@ alternatively--> - Timestamp when pattern acquisition ended. + Timestamp when pattern acquisition ended. @@ -148,8 +148,8 @@ alternatively--> +doc: | +Hint to help resolve in which coordinate system position values are defined.--> @@ -161,7 +161,7 @@ alternatively--> - + @@ -179,14 +179,12 @@ alternatively--> - + - Acquired diffraction pattern azimuthally integrated as a function of time. + Acquired diffraction pattern azimuthally integrated as a function of time. - + @@ -196,7 +194,7 @@ no exists, i.e. assuming required - + @@ -205,7 +203,7 @@ no exists, i.e. assuming required - + @@ -220,7 +218,7 @@ no exists, i.e. assuming required - Time since start of the in-situ experiment + Time since start of the in-situ experiment @@ -231,7 +229,7 @@ no exists, i.e. assuming required - + @@ -242,12 +240,12 @@ no exists, i.e. assuming required - Azimuthally integrated diffraction intensities corrected for background as a - function of time. + Azimuthally integrated diffraction intensities corrected for background as a + function of time. - + @@ -256,7 +254,7 @@ no exists, i.e. assuming required - + @@ -271,7 +269,7 @@ no exists, i.e. assuming required - Time since start of the in-situ experiment + Time since start of the in-situ experiment @@ -281,9 +279,9 @@ no exists, i.e. assuming required diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/contributed_definitions/NXem_ebsd.nxdl.xml index 7c584b21e3..d3965fbe69 100644 --- a/contributed_definitions/NXem_ebsd.nxdl.xml +++ b/contributed_definitions/NXem_ebsd.nxdl.xml @@ -25,150 +25,150 @@ - Number of arguments per orientation for given parameterization. + Number of arguments per orientation for given parameterization. - Number of scan points. + Number of scan points. - Number of pixel along the slowest changing dimension for a rediscretized, - i.e. standardized default plot orientation mapping. + Number of pixel along the slowest changing dimension for a rediscretized, + i.e. standardized default plot orientation mapping. - Number of pixel along slow changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. + Number of pixel along slow changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. - Number of pixel along fast changing dimension for a rediscretized i.e. - standardized default plot orientation mapping. + Number of pixel along fast changing dimension for a rediscretized i.e. + standardized default plot orientation mapping. - Number of phase solutions + Number of phase solutions - Base class method-specific for Electron Backscatter Diffraction (EBSD). - - The general procedure of an EBSD experiment is as follows. - Users load the specimen, collect first a coarse image of the surface. - Next, they set an approximate value for the calibrated working distance and - tilt the stage to set the desired diffraction conditions. - - Users then typically configure the microscope for collecting higher quality data - and push in the EBSD detector. Subsequently, they fine tune the illumination - and aberration corrector settings and select one or multiple ROIs for - the microscope to machine off automatically. They configure on-the-fly - indexing parameter and start the measurement queue. - - Nowadays, this is in most cases an automated process. The pattern - collection runs during the allocated microscope session until the - queue finishes or gets interrupted by errors or the next user terminates - sessions which run over time. - - Kikuchi pattern surplus eventually multi-modal detector signals are - collected and usually indexed on-the-fly. Patterns may be stored or not - so one should not assume that raw data are always stored. - - Results are stored in files, which afterwards are typically copied - automatically or manual for archival purposes to certain storage - locations or further consumption. The result of such an EBSD - measurement/experiment is a set of usually proprietary or open files - from technology partners. - - This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific - data, metadata, and connections between these for the research field of - electron microscopy. - - More specifically, exemplified here for electron backscatter diffraction (EBSD) - we show how NeXus can be used to solve two key documentation issues so far - missing in the field of EBSD. - - Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted - according to NXem_ebsd) stores the connection between the microscope session and - the key datasets which are considered typically results of the various processing - steps involved when working with EBSD data. - - Different groups in NXem_ebsd make connections to data artifacts which were collected - when working with electron microscopes via the NXem application definition. - Using a file which stores information according to the NXem application definition - has the benefit that it connects the sample, references to the sample processing, - the user operating the microscope, details about the microscope session, - and details about the acquisition and eventual indexing of Kikuchi pattern, - associated overview images, like secondary electron or backscattered electron - images of the region-of-interest probed and many more pieces of information. - - Secondly, NXem_ebsd connects and stores the conventions and reference frames - which were used and which are the key to a correct mathematical interpretation - of every EBSD result. Otherwise, results would be ripped out of their context, - as it is the current situation with many traditional studies where EBSD data - were indexed on-the-fly and shared with the community only via sharing - the strongly processed results file in some technology-partner-specific file - format but without communicating all conventions or relying on the assumptions - that colleagues likely know these conventions even though multiple definitions - are possible. - - NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- - dimensional EBSD datasets. The third dimension is either time (in the case of - quasi in-situ experiments) or space (in the case of serial-sectioning) methods - where a combination of mechanical or ion milling is used repetitively to measure - the same region-of-interest at different depth increments. Material removal - can be achieved with electron or ion polishing, using manual - steps or using automated equipment like a robot system. - - Three-dimensional experiments require to follow a sequence of specimen, surface - preparation, and data collection steps. By nature these methods are destructive - in that they either require the removal of the previously measured material region - or that the sample surface can degrade due to e.g. contamination or other - electron-matter interaction. - - For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are - combined into one reconstructed stack. That is serial-sectioning is mainly a - computational workflow. Users collect data for each serial sectioning step - via an experiment. This assures that data for associated microscope sessions - and steps of data processing stay connected and contextualized. - - Eventual tomography methods also use such a workflow because first diffraction - images are collected (e.g. with X-ray) and then these imagres are indexed and - computed into a 3D orientation mapping. The here proposed NXem_ebsd application - definition contains conceptual ideas how this splitting between measurement and - post-processing can be granularized also for such X-ray-based techniques, whether - it be 3DXRD or HEDM. - - This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. - - .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 + Base class method-specific for Electron Backscatter Diffraction (EBSD). + + The general procedure of an EBSD experiment is as follows. + Users load the specimen, collect first a coarse image of the surface. + Next, they set an approximate value for the calibrated working distance and + tilt the stage to set the desired diffraction conditions. + + Users then typically configure the microscope for collecting higher quality data + and push in the EBSD detector. Subsequently, they fine tune the illumination + and aberration corrector settings and select one or multiple ROIs for + the microscope to machine off automatically. They configure on-the-fly + indexing parameter and start the measurement queue. + + Nowadays, this is in most cases an automated process. The pattern + collection runs during the allocated microscope session until the + queue finishes or gets interrupted by errors or the next user terminates + sessions which run over time. + + Kikuchi pattern surplus eventually multi-modal detector signals are + collected and usually indexed on-the-fly. Patterns may be stored or not + so one should not assume that raw data are always stored. + + Results are stored in files, which afterwards are typically copied + automatically or manual for archival purposes to certain storage + locations or further consumption. The result of such an EBSD + measurement/experiment is a set of usually proprietary or open files + from technology partners. + + This :ref:`NXem_ebsd` base class is a proposal how to represent method-specific + data, metadata, and connections between these for the research field of + electron microscopy. + + More specifically, exemplified here for electron backscatter diffraction (EBSD) + we show how NeXus can be used to solve two key documentation issues so far + missing in the field of EBSD. + + Firstly, an instance of NXem_ebsd (such as a NeXus/HDF5 file which is formatted + according to NXem_ebsd) stores the connection between the microscope session and + the key datasets which are considered typically results of the various processing + steps involved when working with EBSD data. + + Different groups in NXem_ebsd make connections to data artifacts which were collected + when working with electron microscopes via the NXem application definition. + Using a file which stores information according to the NXem application definition + has the benefit that it connects the sample, references to the sample processing, + the user operating the microscope, details about the microscope session, + and details about the acquisition and eventual indexing of Kikuchi pattern, + associated overview images, like secondary electron or backscattered electron + images of the region-of-interest probed and many more pieces of information. + + Secondly, NXem_ebsd connects and stores the conventions and reference frames + which were used and which are the key to a correct mathematical interpretation + of every EBSD result. Otherwise, results would be ripped out of their context, + as it is the current situation with many traditional studies where EBSD data + were indexed on-the-fly and shared with the community only via sharing + the strongly processed results file in some technology-partner-specific file + format but without communicating all conventions or relying on the assumptions + that colleagues likely know these conventions even though multiple definitions + are possible. + + NXem_ebsd covers experiments with one-, two-dimensional, and so-called three- + dimensional EBSD datasets. The third dimension is either time (in the case of + quasi in-situ experiments) or space (in the case of serial-sectioning) methods + where a combination of mechanical or ion milling is used repetitively to measure + the same region-of-interest at different depth increments. Material removal + can be achieved with electron or ion polishing, using manual + steps or using automated equipment like a robot system. + + Three-dimensional experiments require to follow a sequence of specimen, surface + preparation, and data collection steps. By nature these methods are destructive + in that they either require the removal of the previously measured material region + or that the sample surface can degrade due to e.g. contamination or other + electron-matter interaction. + + For three-dimensional EBSD, multiple two-dimensional EBSD orientation mappings are + combined into one reconstructed stack. That is serial-sectioning is mainly a + computational workflow. Users collect data for each serial sectioning step + via an experiment. This assures that data for associated microscope sessions + and steps of data processing stay connected and contextualized. + + Eventual tomography methods also use such a workflow because first diffraction + images are collected (e.g. with X-ray) and then these imagres are indexed and + computed into a 3D orientation mapping. The here proposed NXem_ebsd application + definition contains conceptual ideas how this splitting between measurement and + post-processing can be granularized also for such X-ray-based techniques, whether + it be 3DXRD or HEDM. + + This concept is related to term `Electron Backscatter Diffraction`_ of the EMglossary standard. + + .. _Electron Backscatter Diffraction: https://purls.helmholtz-metadaten.de/emg/EMG_00000019 - Details about the gnomonic (projection) reference frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the - base vectors of this coordinate system as Xg, Yg, Zg. + Details about the gnomonic (projection) reference frame. + + It is assumed that the configuration is inspected by looking towards the sample surface. + If a detector is involved, it is assumed that the configuration is inspected from a position + that is located behind this detector. + + If any of these assumptions is not met, the user is required to explicitly state this. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the + base vectors of this coordinate system as Xg, Yg, Zg. - Origin of the gnomonic_projection_reference_frame. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to - assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. + Origin of the gnomonic_projection_reference_frame. + + Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to + assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. @@ -177,8 +177,8 @@ - Direction of the positively pointing x-axis base vector of the - gnomonic_reference_frame. + Direction of the positively pointing x-axis base vector of the + gnomonic_reference_frame. @@ -192,8 +192,8 @@ - Direction of the positively pointing y-axis base vector of the - gnomonic_reference_frame. + Direction of the positively pointing y-axis base vector of the + gnomonic_reference_frame. @@ -207,8 +207,8 @@ - Direction of the positively pointing z-axis base vector of the - gnomonic_reference_frame. + Direction of the positively pointing z-axis base vector of the + gnomonic_reference_frame. @@ -223,28 +223,28 @@ - Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. - - Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. - Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane - (of the detector reference frame). - - When the normalization direction is the same as e.g. the detector x-axis direction one - effectively normalizes in fractions of the width of the detector. - - The issue with terms like width and height is that these degenerate if the detector - region-of-interest is square-shaped. This is why instead of referring to width and height - one should report as if one were to measure practically with a ruler and one is specific - about in which direction positive distances are measured. - - For the concepts used to specify the boundary_convention it is assumed that the - region-of-interest is defined by a rectangle, referring to the direction of outer-unit - normals to the respective edges of this rectangle. + Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. + + Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. + Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane + (of the detector reference frame). + + When the normalization direction is the same as e.g. the detector x-axis direction one + effectively normalizes in fractions of the width of the detector. + + The issue with terms like width and height is that these degenerate if the detector + region-of-interest is square-shaped. This is why instead of referring to width and height + one should report as if one were to measure practically with a ruler and one is specific + about in which direction positive distances are measured. + + For the concepts used to specify the boundary_convention it is assumed that the + region-of-interest is defined by a rectangle, referring to the direction of outer-unit + normals to the respective edges of this rectangle. - From which border of the EBSP (in the detector reference frame) is the pattern - centre's x-position (PCx) measured. + From which border of the EBSP (in the detector reference frame) is the pattern + centre's x-position (PCx) measured. @@ -256,8 +256,8 @@ - In which direction are positive values for the x-axis coordinate value measured - from the specified boundary. + In which direction are positive values for the x-axis coordinate value measured + from the specified boundary. @@ -269,8 +269,8 @@ - From which border of the EBSP (in the detector reference frame) is the pattern - centre's y-position (PCy) measured. + From which border of the EBSP (in the detector reference frame) is the pattern + centre's y-position (PCy) measured. @@ -282,8 +282,8 @@ - In which direction are positive values for the y-axis coordinate value measured - from the specified boundary. + In which direction are positive values for the y-axis coordinate value measured + from the specified boundary. @@ -306,174 +306,174 @@ will be used in practice. enumeration: [undefined, Bruker, JEOL, FEI, Oxford]--> - This group documents relevant details about the conditions and the tools - used for measuring a stack of Kikuchi diffraction pattern with an - electron microscope. - - The most frequently collected EBSD data are captured for rectangular - regions-of-interested which are sampled with regular square or - hexagon-shaped pixels. + This group documents relevant details about the conditions and the tools + used for measuring a stack of Kikuchi diffraction pattern with an + electron microscope. + + The most frequently collected EBSD data are captured for rectangular + regions-of-interested which are sampled with regular square or + hexagon-shaped pixels. - Physical time since the beginning of a timestamp that is required to be - same for all experiments in the set. The purpose of this marker is - to identify how all experiments in the set need to be arranged - sequentially based on the time elapsed. - The time is relevant to sort e.g. experiments of consecutive quasi - in-situ experiments where a measurement was e.g. taken after 0 minutes, - 30 minutes, 6 hours, or 24 hours of annealing. + Physical time since the beginning of a timestamp that is required to be + same for all experiments in the set. The purpose of this marker is + to identify how all experiments in the set need to be arranged + sequentially based on the time elapsed. + The time is relevant to sort e.g. experiments of consecutive quasi + in-situ experiments where a measurement was e.g. taken after 0 minutes, + 30 minutes, 6 hours, or 24 hours of annealing. - Timestamp relative to which time was counted to aid - converting between time and timestamp. + Timestamp relative to which time was counted to aid + converting between time and timestamp. +doc: | +True if pattern were stored and are retrieveable via depends_on or source.--> - If available and it is stored in an instance of an application definition this field - specifies the path to an instance of :ref:`NXdata` where the measured patterns - are stored. + If available and it is stored in an instance of an application definition this field + specifies the path to an instance of :ref:`NXdata` where the measured patterns + are stored. - + - Reference (e.g. path and filename) to an existent data artifact which - stores either the measured pattern or input (already processed EBSD data). + Reference (e.g. path and filename) to an existent data artifact which + stores either the measured pattern or input (already processed EBSD data). - This group documents relevant details about the conditions and the tools - used for simulating a stack of Kikuchi diffraction pattern with some - physical model. - - This group should not be confused with a group named simulation that - is however an instance of NXem_sim. Instead, the simulation group here - should be used if (e.g. instead of a measurement) a stack of pattern - were simulated that one wishes to use for indexing patterns. - - In many practical cases where pattern are analyzed on-the-fly and dictionary - indexing strategies are used, so-called master pattern(s) are used to compare - measured or simulated pattern with the master pattern. In this case, - master pattern are the result of a computer simulation and thus should - be stored using an own properly documented entry within a simulation - group as an instance of :ref:`NXem_sim`. + This group documents relevant details about the conditions and the tools + used for simulating a stack of Kikuchi diffraction pattern with some + physical model. + + This group should not be confused with a group named simulation that + is however an instance of NXem_sim. Instead, the simulation group here + should be used if (e.g. instead of a measurement) a stack of pattern + were simulated that one wishes to use for indexing patterns. + + In many practical cases where pattern are analyzed on-the-fly and dictionary + indexing strategies are used, so-called master pattern(s) are used to compare + measured or simulated pattern with the master pattern. In this case, + master pattern are the result of a computer simulation and thus should + be stored using an own properly documented entry within a simulation + group as an instance of :ref:`NXem_sim`. - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - + - Reference (e.g. path and filename) to an existent digital resource which - stores either the pattern or input (already processed EBSD data) - which is now processed further as described by this NXem_ebsd instance. + Reference (e.g. path and filename) to an existent digital resource which + stores either the pattern or input (already processed EBSD data) + which is now processed further as described by this NXem_ebsd instance. - The EBSD system, including components like the electron gun, pole-piece, - stage tilting, EBSD detector, and the gnomonic projection have to be - calibrated to achieve reliable indexing results. - - Specifically, the gnomonic projection has to be calibrated. - Typically, silicon or quartz crystals are used for this purpose. - - Considering a system is well-calibrated, it is much more frequently the - case in practice that users assume the system is calibrated (and thus usable) - vs. they perform the calibration of the EBSD system. - - In the first case, the user assumes that the principle geometry of the - hardware components and the settings in the control and EBSD pattern - acquisition software has been calibrated. Consequently, users pick from - an existent library of phase candidates, i.e. - :ref:`NXcrystal_structure` instances. Examples are - reflector models as stored in CRY files (HKL/Channel 5/Flamenco). - - In the second case, users calibrate the system during the session - using standards (silicon, quartz, or other common specimens). - There is usually one person in each lab responsible for doing such - calibrations. Often this person or technician is also in charge of - configuring the graphical user interface and software with which most - users control and perform their analyses. - - For EBSD this has key implications: Taking TSL OIM/EDAX as an example, - the conventions how orientations are stored is affected by how the - reference frames are configured and this setup is made at the level - of the GUI software. - - Unfortunately, these pieces of information are not necessarily stored - in the results files. In effect, key conventions become disconnected - from the data so it remains the users' obligation to remember these - settings or write these down in a lab notebook. Otherwise, these metadata - get lost. All these issues are a motivation and problem which - :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. + The EBSD system, including components like the electron gun, pole-piece, + stage tilting, EBSD detector, and the gnomonic projection have to be + calibrated to achieve reliable indexing results. + + Specifically, the gnomonic projection has to be calibrated. + Typically, silicon or quartz crystals are used for this purpose. + + Considering a system is well-calibrated, it is much more frequently the + case in practice that users assume the system is calibrated (and thus usable) + vs. they perform the calibration of the EBSD system. + + In the first case, the user assumes that the principle geometry of the + hardware components and the settings in the control and EBSD pattern + acquisition software has been calibrated. Consequently, users pick from + an existent library of phase candidates, i.e. + :ref:`NXcrystal_structure` instances. Examples are + reflector models as stored in CRY files (HKL/Channel 5/Flamenco). + + In the second case, users calibrate the system during the session + using standards (silicon, quartz, or other common specimens). + There is usually one person in each lab responsible for doing such + calibrations. Often this person or technician is also in charge of + configuring the graphical user interface and software with which most + users control and perform their analyses. + + For EBSD this has key implications: Taking TSL OIM/EDAX as an example, + the conventions how orientations are stored is affected by how the + reference frames are configured and this setup is made at the level + of the GUI software. + + Unfortunately, these pieces of information are not necessarily stored + in the results files. In effect, key conventions become disconnected + from the data so it remains the users' obligation to remember these + settings or write these down in a lab notebook. Otherwise, these metadata + get lost. All these issues are a motivation and problem which + :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. - If available and it is stored in an instance of an application definition this field specifies - the path to an instance of :ref:`NXem_msr` where calibration is stored. + If available and it is stored in an instance of an application definition this field specifies + the path to an instance of :ref:`NXem_msr` where calibration is stored. - + - Reference to a digital resource where the calibration is stored. + Reference to a digital resource where the calibration is stored. - Indexing is a data processing step performed either after or while - (on-the-fly) the beam scans the specimen. The resulting method is also - known as orientation imaging microscopy (OIM). - - Different algorithms can be used to index EBSD pattern. Common to them - is the computational step where simulated reference pattern are compared - with measured or simulated patterns. These latter patterns are referred - to via the measurement or simulation groups of this base class. - - Quality descriptors are defined based on which an indexing algorithm - yields a quantitative measure of how similar measured and reference - pattern are, and thus if no, one, or multiple so-called solutions - were found. - - Assumed or simulated pattern are simulated using kinematic or dynamical - theory of electron diffraction delivering master pattern. - - The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). - Recently, dictionary-based indexing methods are increasingly becoming used - partly driven by the interest to use artificial intelligence algorithms. + Indexing is a data processing step performed either after or while + (on-the-fly) the beam scans the specimen. The resulting method is also + known as orientation imaging microscopy (OIM). + + Different algorithms can be used to index EBSD pattern. Common to them + is the computational step where simulated reference pattern are compared + with measured or simulated patterns. These latter patterns are referred + to via the measurement or simulation groups of this base class. + + Quality descriptors are defined based on which an indexing algorithm + yields a quantitative measure of how similar measured and reference + pattern are, and thus if no, one, or multiple so-called solutions + were found. + + Assumed or simulated pattern are simulated using kinematic or dynamical + theory of electron diffraction delivering master pattern. + + The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). + Recently, dictionary-based indexing methods are increasingly becoming used + partly driven by the interest to use artificial intelligence algorithms. - + - This group enables to establish a logical connection between previous - processing steps or on-the-fly-performed indexing of the EBSD map. - Typically these processing steps are performed with commercial software. - Therefore, in many cases a results file from this indexing is often - all that is communicated and saved. These are typically files in a format - specific to the instrument and its configuration. - - Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. + This group enables to establish a logical connection between previous + processing steps or on-the-fly-performed indexing of the EBSD map. + Typically these processing steps are performed with commercial software. + Therefore, in many cases a results file from this indexing is often + all that is communicated and saved. These are typically files in a format + specific to the instrument and its configuration. + + Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. - Principal algorithm used for indexing. + Principal algorithm used for indexing. @@ -485,38 +485,38 @@ pattern_available(NX_BOOLEAN): - Details about the background correction applied to each Kikuchi pattern. + Details about the background correction applied to each Kikuchi pattern. - Binning i.e. downsampling of the pattern. + Binning i.e. downsampling of the pattern. - Specific parameter relevant only for certain algorithms used. + Specific parameter relevant only for certain algorithms used. - + - Details for each phase used as a model with which the patterns were - indexed. Instances of :ref:`NXcrystal_structure` in this group must - have the group name prefix phase. The identifier in the name is an - integer. We start counting from 1 because the value 0 is reserved for - the special phase that is the null-model, i.e. the null phase, notIndexed. + Details for each phase used as a model with which the patterns were + indexed. Instances of :ref:`NXcrystal_structure` in this group must + have the group name prefix phase. The identifier in the name is an + integer. We start counting from 1 because the value 0 is reserved for + the special phase that is the null-model, i.e. the null phase, notIndexed. - Which return value did the indexing algorithm yield for each scan point. - Practically useful is to use an uint8 mask. - - * 0 - Not analyzed - * 1 - Too high angular deviation - * 2 - No solution - * 100 - Success - * 255 - Unexpected errors + Which return value did the indexing algorithm yield for each scan point. + Practically useful is to use an uint8 mask. + + * 0 - Not analyzed + * 1 - Too high angular deviation + * 2 - No solution + * 100 - Success + * 255 - Unexpected errors @@ -524,21 +524,21 @@ pattern_available(NX_BOOLEAN): - How many phases i.e. crystal structure models were used to index each - scan point if any? Let's assume an example to explain how this field - should be used: In the simplest case users collected one pattern for - each scan point and have indexed using one phase, i.e. one instance - of an NXem_ebsd_crystal_structure_model. - - In another example users may have skipped some scan points (not indexed) - them at all) and/or used differing numbers of phases for different scan - points. - - The cumulated of this array decodes how phase_identifier and phase_matching - arrays have to be interpreted. In the simplest case (one pattern per scan - point, and all scan points indexed using that same single phase model), - phase_identifier has as many entries as scan points - and phase_matching has also as many entries as scan points. + How many phases i.e. crystal structure models were used to index each + scan point if any? Let's assume an example to explain how this field + should be used: In the simplest case users collected one pattern for + each scan point and have indexed using one phase, i.e. one instance + of an NXem_ebsd_crystal_structure_model. + + In another example users may have skipped some scan points (not indexed) + them at all) and/or used differing numbers of phases for different scan + points. + + The cumulated of this array decodes how phase_identifier and phase_matching + arrays have to be interpreted. In the simplest case (one pattern per scan + point, and all scan points indexed using that same single phase model), + phase_identifier has as many entries as scan points + and phase_matching has also as many entries as scan points. @@ -546,28 +546,28 @@ pattern_available(NX_BOOLEAN): - The array n_phases_per_scan_point details how the phase_identifier - and the phase_matching arrays have to be interpreted. - - For the example with a single phase phase_identifier has trivial - values either 0 (no solution) or 1 (solution matching - sufficiently significant with the model for phase 1). - - When there are multiple phases, it is possible (although not frequently - needed) that a pattern matches eventually (not equally well) sufficiently - significant with multiple pattern. This can especially happen in cases of - pseudosymmetry and more frequently with an improperly calibrated system - or false or inaccurate phase models e.g. (ferrite, austenite). - Having such field is especially relevant for recent machine learning - or dictionary based indexing schemes because in combination with - phase_matching these fields communicate the results in a model-agnostic - way. - - Depending on the n_phases_per_scan_point value phase_identifier and - phase_matching arrays represent a collection of concatenated tuples, - which are organized in sequence: The solutions for the 0-th scan point, - the 1-th scan point, the n_sc - 1 th scan point and omitting tuples - for those scan points with no phases according to n_phases_per_scan_point + The array n_phases_per_scan_point details how the phase_identifier + and the phase_matching arrays have to be interpreted. + + For the example with a single phase phase_identifier has trivial + values either 0 (no solution) or 1 (solution matching + sufficiently significant with the model for phase 1). + + When there are multiple phases, it is possible (although not frequently + needed) that a pattern matches eventually (not equally well) sufficiently + significant with multiple pattern. This can especially happen in cases of + pseudosymmetry and more frequently with an improperly calibrated system + or false or inaccurate phase models e.g. (ferrite, austenite). + Having such field is especially relevant for recent machine learning + or dictionary based indexing schemes because in combination with + phase_matching these fields communicate the results in a model-agnostic + way. + + Depending on the n_phases_per_scan_point value phase_identifier and + phase_matching arrays represent a collection of concatenated tuples, + which are organized in sequence: The solutions for the 0-th scan point, + the 1-th scan point, the n_sc - 1 th scan point and omitting tuples + for those scan points with no phases according to n_phases_per_scan_point @@ -575,10 +575,10 @@ pattern_available(NX_BOOLEAN): - One-dimensional array, pattern by pattern labelling the solutions found. - The array n_phases_per_scan_point has to be specified because it details - how the phase_identifier and the phase_matching arrays have to be interpreted. - See documentation of phase_identifier for further details. + One-dimensional array, pattern by pattern labelling the solutions found. + The array n_phases_per_scan_point has to be specified because it details + how the phase_identifier and the phase_matching arrays have to be interpreted. + See documentation of phase_identifier for further details. @@ -586,9 +586,9 @@ pattern_available(NX_BOOLEAN): - Phase_matching is a descriptor for how well the solution matches or not. - Examples can be confidence_index, mean_angular_deviation, some AI-based - matching probability (other), i.e. the details are implementation-specific. + Phase_matching is a descriptor for how well the solution matches or not. + Examples can be confidence_index, mean_angular_deviation, some AI-based + matching probability (other), i.e. the details are implementation-specific. @@ -598,22 +598,18 @@ pattern_available(NX_BOOLEAN): - + - +to sample_reference_frame--> - Calibrated center positions of each scan point - in the sample surface reference system. + Calibrated center positions of each scan point + in the sample surface reference system. @@ -622,27 +618,31 @@ to sample_reference_frame - Fraction of successfully indexed pattern with a phase - not the null-phase vs the number_of_scan_points. + Fraction of successfully indexed pattern with a phase + not the null-phase vs the number_of_scan_points. - Number of scan points in the original mapping. + Number of scan points in the original mapping. - An overview of the entire ROI. + An overview of the entire ROI. - Descriptor representing the image contrast. + Descriptor representing the image contrast. @@ -661,12 +661,12 @@ overview over the entire map, rediscretized on a tight aabb--> \@long_name:--> - Title of the default plot. + Title of the default plot. - Descriptor values displaying the ROI. + Descriptor values displaying the ROI. @@ -677,33 +677,33 @@ in axes fast to fastest while for _indices fastest to fast--> - Descriptor values. + Descriptor values. - Calibrated coordinate along the y-axis. + Calibrated coordinate along the y-axis. - Label for the y axis + Label for the y axis - Calibrated coordinate along the x-axis. + Calibrated coordinate along the x-axis. - Label for the x axis + Label for the x axis diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml index 9eb780132f..2077c053a7 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. diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXfiber.nxdl.xml index 21f5bdc96f..495f3fb926 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXfiber.nxdl.xml @@ -22,7 +22,7 @@ # For further information, see http://www.nexusformat.org --> - + diff --git a/contributed_definitions/NXfit.nxdl.xml b/contributed_definitions/NXfit.nxdl.xml index 25fbe0da5f..cc2cec8d51 100644 --- a/contributed_definitions/NXfit.nxdl.xml +++ b/contributed_definitions/NXfit.nxdl.xml @@ -72,7 +72,7 @@ - + One peak of the peak model. If there is no characteristic name for each peak component, is envisioned that peaks @@ -104,7 +104,7 @@ - + One fitted background (functional form, position, and intensities) of the peak fit. If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled @@ -151,7 +151,7 @@ - + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model fits the measured observations. diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml index 0afcaf2be3..e7847d294c 100644 --- a/contributed_definitions/NXibeam_column.nxdl.xml +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -21,7 +21,9 @@ # # For further information, see http://www.nexusformat.org --> - + + Base class for a set of components equipping an instrument with FIB capabilities. diff --git a/contributed_definitions/NXidentifier.nxdl.xml b/contributed_definitions/NXidentifier.nxdl.xml deleted file mode 100644 index f279ab0162..0000000000 --- a/contributed_definitions/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. - - - diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/contributed_definitions/NXimage_set.nxdl.xml index 496d1a97dd..018abbd91a 100644 --- a/contributed_definitions/NXimage_set.nxdl.xml +++ b/contributed_definitions/NXimage_set.nxdl.xml @@ -106,7 +106,7 @@ https://en.wikipedia.org/wiki/Euclidean_tilings_by_convex_regular_polygons--> Details how NXdata instance were processed from detector readings/raw data. - + Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index 33d0cb551b..2850421d17 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -24,41 +24,41 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. + Grinding and polishing of a sample using abrasives in a wet lab. + Manual procedures, electro-chemical, vibropolishing. - Version specifier of this application definition. + Version specifier of this application definition. - Official NeXus NXDL schema with which this file was written. + Official NeXus NXDL schema with which this file was written. - + - - + + - + - + - A preparation step performed by a human or a robot/automated system. + A preparation step performed by a human or a robot/automated system. @@ -67,15 +67,15 @@ one person or not each person performs all polishing steps--> - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. + Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - Medium on the abrasive_medium_carrier (cloth or grinding plate) - whereby material is abrasively weared. + Medium on the abrasive_medium_carrier (cloth or grinding plate) + whereby material is abrasively weared. - Lubricant + Lubricant - Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs - choose manual and estimate the nominal average rotation. - If the rotation was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal rotation. - If programmed use rotation_history (e.g. for automated/robot systems). + Qualitative statement how the revelation of the machine was configured. + If the rotation was controlled manually, e.g. by turning knobs + choose manual and estimate the nominal average rotation. + If the rotation was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal rotation. + If programmed use rotation_history (e.g. for automated/robot systems). @@ -109,14 +109,14 @@ learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk?--> - Qualitative statement how the (piston) force with which the sample - was pressed into/against the abrasive medium was controlled if at all. - If the force was controlled manually e.g. by turning knobs - choose manual and estimate nominal average force. - If the force was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal force. - If programmed use force_history (e.g. for automated/robot systems). + Qualitative statement how the (piston) force with which the sample + was pressed into/against the abrasive medium was controlled if at all. + If the force was controlled manually e.g. by turning knobs + choose manual and estimate nominal average force. + If the force was controlled via choosing from a fixed set + of options offered by the machine choose fixed and + specify the nominal force. + If programmed use force_history (e.g. for automated/robot systems). @@ -127,9 +127,9 @@ learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk?--> - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. + Qualitative statement for how long (assuming regular uninterrupted) + preparation at the specified conditions the preparation step was + applied. @@ -140,24 +140,24 @@ learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk?--> - Turns per unit time. + Turns per unit time. - Force exerted on the sample to press it into the abrasive. + Force exerted on the sample to press it into the abrasive. - Seconds + Seconds - Qualitative statement how the material removal was characterized. + Qualitative statement how the material removal was characterized. @@ -167,7 +167,7 @@ learn from our colleagues within NFDI4Cat, NFDI4Chem, and NFDI-MatWerk?--> - How thick a layer was removed. + How thick a layer was removed. @@ -177,10 +177,10 @@ electro-chemical preparation is nothing but an I(V) curve within a corrosive medium, eventually some wet lab steps have characteristics of pure grinding, mechanical polishing, or a mixture with corrosive attack--> - + - A preparation step performed by a human or a robot/automated system - with the aim to remove residual abrasive medium from the specimen surface. + A preparation step performed by a human or a robot/automated system + with the aim to remove residual abrasive medium from the specimen surface. diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 112270c29d..353e494652 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -24,40 +24,40 @@ - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Embedding of a sample in a medium for easing processability. + Embedding of a sample in a medium for easing processability. - Version specifier of this application definition. + Version specifier of this application definition. - Official NeXus NXDL schema with which this file was written. + Official NeXus NXDL schema with which this file was written. - - + + - + - Qualitative statement how the sample was mounted. + Qualitative statement how the sample was mounted. @@ -66,7 +66,7 @@ - Type of material. + Type of material. @@ -75,7 +75,7 @@ - Electrical conductivity of the embedding medium. + Electrical conductivity of the embedding medium. diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml index c8cda047c2..aef48a4913 100644 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -21,68 +21,69 @@ # # For further information, see http://www.nexusformat.org --> - - - + - Base class for an electro-magnetic lens or a compound lens. - - For :ref:`NXtransformations` the origin of the coordinate system is placed - in the center of the lens (its polepiece, pinhole, or another - point of reference). The origin should be specified in the :ref:`NXtransformations`. - - For details of electro-magnetic lenses in the literature - see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + Base class for an electro-magnetic lens or a compound lens. + + For :ref:`NXtransformations` the origin of the coordinate system is placed + in the center of the lens (its polepiece, pinhole, or another + point of reference). The origin should be specified in the :ref:`NXtransformations`. + + For details of electro-magnetic lenses in the literature + see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use ``NXfabrication`` and ``identifierNAME``. + + - Descriptor for the lens excitation when the exact technical details - are unknown or not directly controllable as the control software of - the microscope does not enable or was not configured to display these - values (for end users). - - Although this value does not document the exact physical voltage or - excitation, it can still give useful context to reproduce the lens - setting, provided a properly working instrument and software sets the lens - into a similar state to the technical level possible when no more - information is available physically or accessible legally. + Descriptor for the lens excitation when the exact technical details + are unknown or not directly controllable as the control software of + the microscope does not enable or was not configured to display these + values (for end users). + + Although this value does not document the exact physical voltage or + excitation, it can still give useful context to reproduce the lens + setting, provided a properly working instrument and software sets the lens + into a similar state to the technical level possible when no more + information is available physically or accessible legally. - Descriptor for the operation mode of the lens when other details are not - directly controllable as the control software of the microscope - does not enable or is not configured to display these values. - - Like value, the mode can only be interpreted for a specific microscope - but can still be useful to guide users as to how to repeat the measurement. + Descriptor for the operation mode of the lens when other details are not + directly controllable as the control software of the microscope + does not enable or is not configured to display these values. + + Like value, the mode can only be interpreted for a specific microscope + but can still be useful to guide users as to how to repeat the measurement. - Excitation voltage of the lens. - - For dipoles it is a single number. - For higher order multipoles, it is an array. + Excitation voltage of the lens. + + For dipoles it is a single number. + For higher order multipoles, it is an array. - Excitation current of the lens. - - For dipoles it is a single number. - For higher-order multipoles, it is an array. + Excitation current of the lens. + + For dipoles it is a single number. + For higher-order multipoles, it is an array. - Qualitative type of lens with respect to the number of pole pieces. + Qualitative type of lens with respect to the number of pole pieces. diff --git a/contributed_definitions/NXlens_opt.nxdl.xml b/contributed_definitions/NXlens_opt.nxdl.xml index a57b1f9fa4..fac73aee1c 100644 --- a/contributed_definitions/NXlens_opt.nxdl.xml +++ b/contributed_definitions/NXlens_opt.nxdl.xml @@ -24,33 +24,33 @@ - + - Size of the wavelength array for which the refractive index of the material - is given. + Size of the wavelength array for which the refractive index of the material + is given. - Size of the wavelength array for which the refractive index of the coating - is given. + Size of the wavelength array for which the refractive index of the coating + is given. - Size of the wavelength array for which the reflectance or transmission of - the lens is given. + Size of the wavelength array for which the reflectance or transmission of + the lens is given. - Description of an optical lens. + Description of an optical lens. - Type of the lens (e.g. concave, convex etc.). + Type of the lens (e.g. concave, convex etc.). @@ -65,38 +65,38 @@ A draft of a new base class describing an optical lens - If you chose 'other' as type specify what it is. + If you chose 'other' as type specify what it is. - Is it a chromatic lens? + Is it a chromatic lens? - Diameter of the lens. + Diameter of the lens. - Properties of the substrate material of the lens. If the lens has a - coating specify the coating material and its properties in 'coating'. + Properties of the substrate material of the lens. If the lens has a + coating specify the coating material and its properties in 'coating'. - Specify the substrate material of the lens. + Specify the substrate material of the lens. - Thickness of the lens substrate at the optical axis. + Thickness of the lens substrate at the optical axis. - Complex index of refraction of the lens material. Specify at given - wavelength (or energy, wavenumber etc.) values. + Complex index of refraction of the lens material. Specify at given + wavelength (or energy, wavenumber etc.) values. @@ -104,40 +104,38 @@ A draft of a new base class describing an optical lens - - + + - If the lens has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the lens are coated with different - materials, use separate COATING(NXsample) fields to describe the coatings - on the front and back side, respectively. For example: - coating_front(NXsample) and coating_back(NXsample). + If the lens has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the lens are coated with different + materials, use separate COATING(NXsample) fields to describe the coatings + on the front and back side, respectively. For example: + coating_front(NXsample) and coating_back(NXsample). - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Describe the coating material (e.g. MgF2). + Describe the coating material (e.g. MgF2). - Thickness of the coating. + Thickness of the coating. - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). @@ -147,7 +145,7 @@ the lens has different coatings on the front and back side. - Reflectance of the lens at given spectral values. + Reflectance of the lens at given spectral values. @@ -155,7 +153,7 @@ the lens has different coatings on the front and back side. - Transmission of the lens at given spectral values. + Transmission of the lens at given spectral values. @@ -163,36 +161,36 @@ the lens has different coatings on the front and back side. - Focal length of the lens on the front side (first value), i.e. where the - beam is incident, and on the back side (second value). + Focal length of the lens on the front side (first value), i.e. where the + beam is incident, and on the back side (second value). - + - Curvature radius of the lens. - Instead of 'FACE' in the name of this field, the user is advised to - specify for which surface (e.g. front or back) the curvature is provided: - e.g. curvature_front or curvature_back. The front face is the surface on - which the light beam is incident, while the back face is the one from - which the light beam exits the lens. + Curvature radius of the lens. + Instead of 'FACE' in the name of this field, the user is advised to + specify for which surface (e.g. front or back) the curvature is provided: + e.g. curvature_front or curvature_back. The front face is the surface on + which the light beam is incident, while the back face is the one from + which the light beam exits the lens. - + - Abbe number (or V-number) of the lens. + Abbe number (or V-number) of the lens. - The numerical aperture of the used incident light optics. + The numerical aperture of the used incident light optics. - + diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml index b3feb956ad..f9a3dc2d47 100644 --- a/contributed_definitions/NXlockin.nxdl.xml +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -23,49 +23,49 @@ --> - A base class definition for a lock-in amplifier. - - The lock-in amplifier information: the device is being used to extract a (potentially) - very weak input signal buried in the noisy background, where the input signal has - the same frequency (or its harmonic) as a known reference signal, using heterodyne - detection. - This method extracts the amplitude and phase shift of the current signal to the reference. - The reference signal might be created by a generator built-in into the lock-in amplifier. + A base class definition for a lock-in amplifier. + + The lock-in amplifier information: the device is being used to extract a (potentially) + very weak input signal buried in the noisy background, where the input signal has + the same frequency (or its harmonic) as a known reference signal, using heterodyne + detection. + This method extracts the amplitude and phase shift of the current signal to the reference. + The reference signal might be created by a generator built-in into the lock-in amplifier. - Hardware manufacturers and type (product number) of lock-in amplifier. + Hardware manufacturers and type (product number) of lock-in amplifier. - Description of the amplifier (after detection of the signal from the noise) + Description of the amplifier (after detection of the signal from the noise) - Bias divider for lock-in channel if if has. - Bias divider = V(ref)/[V(ref)+V(input)] + Bias divider for lock-in channel if if has. + Bias divider = V(ref)/[V(ref)+V(input)] - Switch the lock-in modulation on or off. + Switch the lock-in modulation on or off. - A periodic voltage signal generated by the lock-in, - usually applied to a sample and used to create a reference signal for the detection of the input signal + A periodic voltage signal generated by the lock-in, + usually applied to a sample and used to create a reference signal for the detection of the input signal - The sign (1 or -1) that defines the sign of the lock-in current. - The calibration procedure with retracted tip is normally performed to compensate for the signal phase delay - in SPM. The procedure yields two possible solutions, this number should be equal - to 1 or -1 depending on which solution is chosen (this concept mainly used in STS experiments, - e.g. in Nanonis machine). + The sign (1 or -1) that defines the sign of the lock-in current. + The calibration procedure with retracted tip is normally performed to compensate for the signal phase delay + in SPM. The procedure yields two possible solutions, this number should be equal + to 1 or -1 depending on which solution is chosen (this concept mainly used in STS experiments, + e.g. in Nanonis machine). @@ -74,97 +74,97 @@ these (reference amplitude, frequency and phase) should be specivied on channel even when common reference is sent to different channels--> - Amplitude of the reference signal for the lock-in amplifier. + Amplitude of the reference signal for the lock-in amplifier. - Frequency of the reference signal for the lock-in amplifier. + Frequency of the reference signal for the lock-in amplifier. - Phase of the reference signal set in the lock-in amplifier. + Phase of the reference signal set in the lock-in amplifier. - Type of the demodulated signal, current | voltage. + Type of the demodulated signal, current | voltage. - The frequency of the demodulated signal. + The frequency of the demodulated signal. - The bandwidth of the modulated signal that can be applied in frequency - demodulation mechanism. + The bandwidth of the modulated signal that can be applied in frequency + demodulation mechanism. - The amplitude of the demodulated signal. + The amplitude of the demodulated signal. - The phase of the demodulated signal. + The phase of the demodulated signal. - List of the demodulator channels. + List of the demodulator channels. - + - Frequency of the low-pass filter applied on the demodulated - signals (X,Y), cut-off frq (low pass filter) (for each DemodulatorChannels). + Frequency of the low-pass filter applied on the demodulated + signals (X,Y), cut-off frq (low pass filter) (for each DemodulatorChannels). - + - Frequency of the high-pass filter applied on the demodulation - signal cut-off frq (hi pass filter) (for each DemodulatorChannels). + Frequency of the high-pass filter applied on the demodulation + signal cut-off frq (hi pass filter) (for each DemodulatorChannels). - + - Order of the low-pass filter applied on the demodulated signals (X, Y). - Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, - but increases settling and measurement times. + Order of the low-pass filter applied on the demodulated signals (X, Y). + Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, + but increases settling and measurement times. - + - Order of the high-pass filter applied on the demodulation - signal. This is used mainly to suppress a DC component of the input - signal noise. + Order of the high-pass filter applied on the demodulation + signal. This is used mainly to suppress a DC component of the input + signal noise. - + - An extra reference phase offset of reference signal with respect to the demodulated signal - (foreach Channels). + An extra reference phase offset of reference signal with respect to the demodulated signal + (foreach Channels). - Integration time for the product of the input and the reference signals + Integration time for the product of the input and the reference signals - + - The reference signal can be a higher harmonic of the modulation signal. - Here the order of the harmonic is stored. + The reference signal can be a higher harmonic of the modulation signal. + Here the order of the harmonic is stored. - Ratio of output signal amplitude to input signal amplitue (V/V). + Ratio of output signal amplitude to input signal amplitue (V/V). diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 78543de83f..1ce3aec0bf 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -3,7 +3,7 @@ - - + - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. - Name of the manipulator. + Name of the manipulator. - A description of the manipulator. + A description of the manipulator. - Type of manipulator, Hexapod, Rod, etc. + Type of manipulator, Hexapod, Rod, etc. - Cryostat for cooling the sample. + Cryostat for cooling the sample. - + - In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). + In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. @@ -69,7 +69,7 @@ - Temperature sensor measuring the sample temperature. + Temperature sensor measuring the sample temperature. @@ -78,23 +78,23 @@ - In case of a single or averaged temperature measurement, this is the scalar temperature measured - by the sample temperature sensor. It can also be a 1D array of measured temperatures - (without time stamps). + In case of a single or averaged temperature measurement, this is the scalar temperature measured + by the sample temperature sensor. It can also be a 1D array of measured temperatures + (without time stamps). - In the case of an experiment in which the temperature changes and is recorded with time stamps, - this is an array of length m of temperatures. + In the case of an experiment in which the temperature changes and is recorded with time stamps, + this is an array of length m of temperatures. - Device to heat the sample. + Device to heat the sample. @@ -103,30 +103,30 @@ - In case of a fixed or averaged heating power, this is the scalar heater power. - It can also be a 1D array of heater powers (without time stamps). + In case of a fixed or averaged heating power, this is the scalar heater power. + It can also be a 1D array of heater powers (without time stamps). - In the case of an experiment in which the heater power is changed and recorded with time stamps, - this is an array of length m of temperature setpoints. + In the case of an experiment in which the heater power is changed and recorded with time stamps, + this is an array of length m of temperature setpoints. - + - In case of a fixed or averaged temperature, this is the scalar temperature setpoint. - It can also be a 1D array of temperature setpoints (without time stamps). + In case of a fixed or averaged temperature, this is the scalar temperature setpoint. + It can also be a 1D array of temperature setpoints (without time stamps). - In the case of an experiment in which the temperature is changed and the setpoints are - recorded with time stamps, this is an array of length m of temperature setpoints. + In the case of an experiment in which the temperature is changed and the setpoints are + recorded with time stamps, this is an array of length m of temperature setpoints. @@ -134,7 +134,7 @@ - Amperemeter measuring the drain current of the sample and sample holder. + Amperemeter measuring the drain current of the sample and sample holder. @@ -143,40 +143,40 @@ - In case of a single or averaged drain current measurement, this is the scalar drain current measured between - the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). + In case of a single or averaged drain current measurement, this is the scalar drain current measured between + the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). - In the case of an experiment in which the current changes and is recorded with - time stamps, this is an array of length m of currents. + In the case of an experiment in which the current changes and is recorded with + time stamps, this is an array of length m of currents. - Actuator applying a voltage to sample and sample holder. + Actuator applying a voltage to sample and sample holder. - + - In case of a fixed or averaged applied bias, this is the scalar voltage applied between - sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). + In case of a fixed or averaged applied bias, this is the scalar voltage applied between + sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). - In the case of an experiment in which the bias is changed and the setpoints are - recorded with time stamps, this is an array of length m of voltage setpoints. + In the case of an experiment in which the bias is changed and the setpoints are + recorded with time stamps, this is an array of length m of voltage setpoints. @@ -184,7 +184,7 @@ - Sensor measuring the voltage applied to sample and sample holder. + Sensor measuring the voltage applied to sample and sample holder. @@ -193,65 +193,33 @@ - In case of a single or averaged bias measurement, this is the scalar voltage measured between - sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). + In case of a single or averaged bias measurement, this is the scalar voltage measured between + sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). - In the case of an experiment in which the bias changes and is recorded with - time stamps, this is an array of length m of voltages. + In the case of an experiment in which the bias changes and is recorded with + time stamps, this is an array of length m of voltages. - Any additional actuator on the manipulator used to control an external - condition. + Any additional actuator on the manipulator used to control an external + condition. - Any additional sensors on the manipulator used to monitor an external condition. + Any additional sensors on the manipulator used to monitor an external condition. - Class to describe the motors that are used in the manipulator + Class to describe the motors that are used in the manipulator - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the manipulator as a component in the instrument. Conventions from - the NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component 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. - - - diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml index 661239dad9..f926738fca 100644 --- a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -24,18 +24,18 @@ - + - Application definition for configuring GraGLeS. - - GraGLeS is a continuum-scale model for shared-memory-parallelized simulations - of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. - CPU parallelization is achieved with OpenMP. - - The code has been implemented by C. Mießen in the group of G. Gottstein - at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. - - Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. + Application definition for configuring GraGLeS. + + GraGLeS is a continuum-scale model for shared-memory-parallelized simulations + of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. + CPU parallelization is achieved with OpenMP. + + The code has been implemented by C. Mießen in the group of G. Gottstein + at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. + + Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. @@ -45,12 +45,12 @@ type: group--> - Simulation ID as an alias to refer to this simulation. + Simulation ID as an alias to refer to this simulation. - Discouraged free-text field to add further details to the computation. + Discouraged free-text field to add further details to the computation. @@ -65,9 +65,9 @@ type: group--> - Programs and libraries representing the computational environment + Programs and libraries representing the computational environment - + @@ -80,48 +80,48 @@ read the next three from input file Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file Microstructure.SimID.10.uds 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file--> - + - From which file should the microstructure be instantiated. + From which file should the microstructure be instantiated. - + - The formulation of mean curvature flow in the GraGLeS model is scale invariant. - Therefore, the discretization has to be scaled to the actual physical length - of the simulation domain (ve, ROI). - For GraGLeS the discretization is always a square or cubic axis-aligned - bounding box with a regular tiling into material points - (either squares or cubes respectively). - - Edge_length is the length of the entire domain along its edge not - the length of the Wigner-Seitz cell about each material point! + The formulation of mean curvature flow in the GraGLeS model is scale invariant. + Therefore, the discretization has to be scaled to the actual physical length + of the simulation domain (ve, ROI). + For GraGLeS the discretization is always a square or cubic axis-aligned + bounding box with a regular tiling into material points + (either squares or cubes respectively). + + Edge_length is the length of the entire domain along its edge not + the length of the Wigner-Seitz cell about each material point! - Configuration when snapshots of the system should be taken. - - Keep in mind that essentially geometry snapshot data store the - polylines and polyhedra of all grains which can take substantial disk - space. + Configuration when snapshots of the system should be taken. + + Keep in mind that essentially geometry snapshot data store the + polylines and polyhedra of all grains which can take substantial disk + space. - Generate a snapshot of the properties of the grains to follow - the evolution of the microstructure every :math:`n`-th iteration. - Setting zero causes that no property snapshots are taken. + Generate a snapshot of the properties of the grains to follow + the evolution of the microstructure every :math:`n`-th iteration. + Setting zero causes that no property snapshots are taken. - Generate a snapshot of the geometry of the entire grain boundary network - every :math:`n`-th iteration. Setting zero instructs to store no geometry data. + Generate a snapshot of the geometry of the entire grain boundary network + every :math:`n`-th iteration. Setting zero instructs to store no geometry data. @@ -129,30 +129,30 @@ read the next three from input file 1--> - Configuration when the simulation should be stopped in a controlled manner. - Whichever criterion is fulfilled first triggers the controlled stop of - and termination of GraGLeS. + Configuration when the simulation should be stopped in a controlled manner. + Whichever criterion is fulfilled first triggers the controlled stop of + and termination of GraGLeS. - The simulation stops if the total number of grains - becomes smaller than this criterion. + The simulation stops if the total number of grains + becomes smaller than this criterion. - The simulation stops if more iterations than this criterion have been computed. + The simulation stops if more iterations than this criterion have been computed. - Configuration of numerical details of the solver. + Configuration of numerical details of the solver. - Which type of convolution kernel and model is used. + Which type of convolution kernel and model is used. @@ -162,7 +162,7 @@ read the next three from input file - Constant to calibrate the real time scaling of the simulation. + Constant to calibrate the real time scaling of the simulation. @@ -183,33 +183,33 @@ only guru i.e. in C++ code configurable options --> - Configuration of the grid coarsement algorithm whereby the representation - of the system is continuously rediscretized such that on average grains - are discretized with discretization many material points along each - direction. - - Grid coarsement can reduce the computational costs substantially although - it cannot be ruled out completely that the rediscretizing may have an effect - on the system evolution. Without grid coarsement the total number of material - points to consider stays the same throughout the simulation. + Configuration of the grid coarsement algorithm whereby the representation + of the system is continuously rediscretized such that on average grains + are discretized with discretization many material points along each + direction. + + Grid coarsement can reduce the computational costs substantially although + it cannot be ruled out completely that the rediscretizing may have an effect + on the system evolution. Without grid coarsement the total number of material + points to consider stays the same throughout the simulation. - Number of material points along each direction to discretize the - average grain. The larger this value is chosen the finer the curvature - details are that can be resolved but also the longer the simulation - takes. + Number of material points along each direction to discretize the + average grain. The larger this value is chosen the finer the curvature + details are that can be resolved but also the longer the simulation + takes. - If true grid coarsement is active, otherwise it is not. + If true grid coarsement is active, otherwise it is not. - Fraction how strongly the number of grains has to reduce - to trigger a grid coarsement step in an iteration. + Fraction how strongly the number of grains has to reduce + to trigger a grid coarsement step in an iteration. @@ -219,20 +219,20 @@ only guru i.e. in C++ code configurable options 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated--> - Physically-based model of the assumed mobility of the grain boundaries. - - Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent - especially as grain boundaries in reality are decorated with defects as a consequence of which - the actual mobility is a combination of the mobility of the individual defects and the attached - boundary patches. Grain boundaries have different degrees of microscopic freedom. - Therefore, their mobility follows a distribution. + Physically-based model of the assumed mobility of the grain boundaries. + + Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent + especially as grain boundaries in reality are decorated with defects as a consequence of which + the actual mobility is a combination of the mobility of the individual defects and the attached + boundary patches. Grain boundaries have different degrees of microscopic freedom. + Therefore, their mobility follows a distribution. - Fundamental model how :math:`m` is assumed a function of the disorientation - angle :math:`\Theta`. + Fundamental model how :math:`m` is assumed a function of the disorientation + angle :math:`\Theta`. @@ -241,39 +241,39 @@ only guru i.e. in C++ code configurable options - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - Mobility scaling factor :math:`c_2`. Typically 5. + Mobility scaling factor :math:`c_2`. Typically 5. - Mobility scaling factor :math:`c_3`. Typically 9. + Mobility scaling factor :math:`c_3`. Typically 9. - Physically-based model of the assumed grain boundary surface energy. - - Like for the grain boundary mobility, defects cause a distribution of energies for the - patches of which the boundary is composed. In practice a too complicated dependency - of the energy and mobility model is observed as a function of the type and chemical - decoration of the defects. Therefore, simplifying assumptions are typically made. + Physically-based model of the assumed grain boundary surface energy. + + Like for the grain boundary mobility, defects cause a distribution of energies for the + patches of which the boundary is composed. In practice a too complicated dependency + of the energy and mobility model is observed as a function of the type and chemical + decoration of the defects. Therefore, simplifying assumptions are typically made. - Fundamental type of assumption if energies are considered isotropic or not. + Fundamental type of assumption if energies are considered isotropic or not. @@ -282,8 +282,8 @@ only guru i.e. in C++ code configurable options - Fundamental model how :math:`\gamma` is assumed a function of the disorientation - angle :math:`\Theta`. + Fundamental model how :math:`\gamma` is assumed a function of the disorientation + angle :math:`\Theta`. @@ -291,9 +291,9 @@ only guru i.e. in C++ code configurable options - Mean grain boundary surface energy that is assumed a function of the - disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. - This value factorizes the curvature_driving_force model. + Mean grain boundary surface energy that is assumed a function of the + disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. + This value factorizes the curvature_driving_force model. @@ -304,43 +304,43 @@ only guru i.e. in C++ code configurable options these Scaling parameter are not read as well but utilized in the ReadShockley enery model-\->--> - A continuum-scale curvature of an interface causes the interface to - migrate towards the center of the curvature radius. + A continuum-scale curvature of an interface causes the interface to + migrate towards the center of the curvature radius. - If true the curvature_driving_force is considered, otherwise it is not. + If true the curvature_driving_force is considered, otherwise it is not. - A continuum-scale difference of the stored elastic energy in dislocation - configurations across a grain boundary can exert a driving force on the - grain boundary such that the boundary migrates into the volume with the - higher stored elastic energy. + A continuum-scale difference of the stored elastic energy in dislocation + configurations across a grain boundary can exert a driving force on the + grain boundary such that the boundary migrates into the volume with the + higher stored elastic energy. - If true the dislocation_driving_force is considered, otherwise it is not. + If true the dislocation_driving_force is considered, otherwise it is not. - Prefactor :math:`0.5Gb^2` that factorizes the average - stored elastic energy per length dislocation line. + Prefactor :math:`0.5Gb^2` that factorizes the average + stored elastic energy per length dislocation line. - In case of an applied magnetic field, a difference of the magnetic - susceptibility can exert a driving force on the grain boundary such that - the boundary migrates into the volume with the higher magnetic energy. + In case of an applied magnetic field, a difference of the magnetic + susceptibility can exert a driving force on the grain boundary such that + the boundary migrates into the volume with the higher magnetic energy. - If true the magnetic_driving_force is considered, otherwise it is not. + If true the magnetic_driving_force is considered, otherwise it is not. @@ -348,20 +348,20 @@ these Scaling parameter are not read as well but utilized in the ReadShockley en https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml--> - A triple line mediates the atomic arrangement differences between three - interface patches. Therefore, the triple line is a defect that may not - have the same mobility as adjoining grain boundaries and thus it may - exert what can be conceptualized as a drag (resistance) to the motion - of the adjoining interface patches. + A triple line mediates the atomic arrangement differences between three + interface patches. Therefore, the triple line is a defect that may not + have the same mobility as adjoining grain boundaries and thus it may + exert what can be conceptualized as a drag (resistance) to the motion + of the adjoining interface patches. - Assumed triple junction drag. + Assumed triple junction drag. - - + diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml index c49c50a317..53b6cfe7b5 100644 --- a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -72,13 +72,13 @@ Programs and libraries representing the computational environment - + - + @@ -88,7 +88,7 @@ - + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml index 4b3ca3448c..9548714a70 100644 --- a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -85,14 +85,14 @@ Programs and libraries representing the computational environment - + - + @@ -104,7 +104,7 @@ - + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml index c66873292f..9737ad7701 100644 --- a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -25,46 +25,46 @@ - Number of Bunge-Euler angle triplets for deformed grains. + Number of Bunge-Euler angle triplets for deformed grains. - Number of Bunge-Euler angle triplets for recrystallization nuclei. + Number of Bunge-Euler angle triplets for recrystallization nuclei. - Number of support points for the linearized drag profile. + Number of support points for the linearized drag profile. - Number of suport points for the desired time-temperature profile. + Number of suport points for the desired time-temperature profile. - Number of entries when to defragment i.e. garbage collect the memory holding - state information for recrystallized cells. + Number of entries when to defragment i.e. garbage collect the memory holding + state information for recrystallized cells. - Number of entries when to collect snapshots of the evolving microstructure. + Number of entries when to collect snapshots of the evolving microstructure. - Number of solitary unit domains to export. + Number of solitary unit domains to export. - Application definition to configure a simulation with the SCORE model. - - * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ - * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + Application definition to configure a simulation with the SCORE model. + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ @@ -74,12 +74,12 @@ - Simulation ID as an alias to refer to this simulation. + Simulation ID as an alias to refer to this simulation. - Discouraged free-text field to add further details to the computation. + Discouraged free-text field to add further details to the computation. @@ -94,9 +94,9 @@ - Programs and libraries representing the computational environment + Programs and libraries representing the computational environment - + @@ -104,19 +104,19 @@ - Relevant data to instantiate a starting configuration that is typically - a microstructure in deformed conditions where stored (elastic) energy - is stored in the form of crystal defects, which in the SCORE model are - is considered as mean-field dislocation content. + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. - Extend of each CA domain in voxel along the x, y, and z direction. - Deformation of sheet material is assumed. - The x axis is assumed pointing along the rolling direction. - The y axis is assumed pointing along the transverse direction. - The z axis is assumed pointing along the normal direction. + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. @@ -124,11 +124,11 @@ - Details how the deformed grains should be modelled. + Details how the deformed grains should be modelled. - Which model should be used to generate a starting microstructure. + Which model should be used to generate a starting microstructure. @@ -139,8 +139,8 @@ - Extent of each deformed grain in voxel along the - x, y, and z direction when type is cuboidal. + Extent of each deformed grain in voxel along the + x, y, and z direction when type is cuboidal. @@ -148,32 +148,32 @@ - Average spherical diameter when type is poisson_voronoi. + Average spherical diameter when type is poisson_voronoi. - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of deformed grains randomly from. + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of deformed grains randomly from. - + - The EBSD dataset from which the initial microstructure is - instantiated if model is ebsd. + The EBSD dataset from which the initial microstructure is + instantiated if model is ebsd. - + - Extent of the pixel of the EBSD orientation mapping assuming square-shaped - pixels. + Extent of the pixel of the EBSD orientation mapping assuming square-shaped + pixels. @@ -183,16 +183,16 @@ - Phenomenological model according to which recrystallization nuclei - are placed into the domain and assumed growing. + Phenomenological model according to which recrystallization nuclei + are placed into the domain and assumed growing. - According to which model will the nuclei become distributed spatially: - - * csr, complete spatial randomness. - * custom, implementation specific. - * gb, nuclei placed at grain boundaries + According to which model will the nuclei become distributed spatially: + + * csr, complete spatial randomness. + * custom, implementation specific. + * gb, nuclei placed at grain boundaries @@ -202,7 +202,7 @@ - According to which model will the nuclei start to grow. + According to which model will the nuclei start to grow. @@ -210,7 +210,7 @@ - According to which model will the nuclei get their orientation assigned. + According to which model will the nuclei get their orientation assigned. @@ -218,8 +218,8 @@ - Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) - to sample orientations of nuclei randomly from. + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of nuclei randomly from. @@ -229,18 +229,18 @@ - (Mechanical) properties of the material which scale - the amount of stored (elastic) energy in the system and - thus mainly affect recrystallization kinetics. + (Mechanical) properties of the material which scale + the amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. - Shear modulus at zero Kelvin. + Shear modulus at zero Kelvin. - Magnitude at the Burgers vector at zero Kelvin. + Magnitude at the Burgers vector at zero Kelvin. - Melting temperature in degrees Celsius. + Melting temperature in degrees Celsius. - Model for the assumed mobility of grain boundaries with different disorientation - essentially implementing variations of Turnbull's model for - thermally-activated migration. + Model for the assumed mobility of grain boundaries with different disorientation + essentially implementing variations of Turnbull's model for + thermally-activated migration. - Which type of fundamental model for the grain boundary mobility. - - Grain boundaries with disorientation angle smaller than 15 degree are considered - as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + Which type of fundamental model for the grain boundary mobility. + + Grain boundaries with disorientation angle smaller than 15 degree are considered + as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. @@ -275,80 +275,80 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Parameter of the Sebald-Gottstein migration model. + Parameter of the Sebald-Gottstein migration model. - At which disorientation angle are grain boundary considered as high-angle grain - boundaries. + At which disorientation angle are grain boundary considered as high-angle grain + boundaries. - Pre-exponential factor for low-angle grain boundaries. + Pre-exponential factor for low-angle grain boundaries. - Migration activation enthalpy for low-angle grain boundaries. + Migration activation enthalpy for low-angle grain boundaries. - Pre-exponential factor for high-angle grain boundaries. + Pre-exponential factor for high-angle grain boundaries. - Migration activation enthalpy for high-angle grain boundaries. + Migration activation enthalpy for high-angle grain boundaries. - Pre-exponential factor for particularly mobile boundaries. + Pre-exponential factor for particularly mobile boundaries. - Migration activation enthalpy for particularly mobile boundaries. + Migration activation enthalpy for particularly mobile boundaries. - Parameter of the Rollett-Holm migration model. + Parameter of the Rollett-Holm migration model. - The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed - temperature. GraGLeS was developed for modelling isothermal annealing. + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. - Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. - Mobility scaling factor :math:`c_2`. Typically 5. + Mobility scaling factor :math:`c_2`. Typically 5. - Mobility scaling factor :math:`c_3`. Typically 9. + Mobility scaling factor :math:`c_3`. Typically 9. - Time-dependent reduction of the stored (elastic) energy to account for recovery. + Time-dependent reduction of the stored (elastic) energy to account for recovery. - Which type of recovery model. + Which type of recovery model. @@ -357,12 +357,12 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Reduction of the grain boundary migration speed due to the presence of dispersoids - through which the total grain boundary area of the recrystallization front can be reduced. + Reduction of the grain boundary migration speed due to the presence of dispersoids + through which the total grain boundary area of the recrystallization front can be reduced. - Which type of drag model. + Which type of drag model. @@ -371,23 +371,23 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Parameter of the Zener-Smith drag model. + Parameter of the Zener-Smith drag model. - Configuration-dependent constant which factorizes the drag pressure. + Configuration-dependent constant which factorizes the drag pressure. - Average surface energy of the grain-boundary-dispersoid-surface configuration - which factorizes the drag pressure. + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. - Support point of the linearized curve of simulated time matching - a specific support point of the average dispersoid radius. + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. @@ -395,7 +395,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Support point of the linearized curve of the average dispersoid radius. + Support point of the linearized curve of the average dispersoid radius. @@ -405,12 +405,12 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Desired simulated time-temperature profile + Desired simulated time-temperature profile - Support point of the linearized curve of simulated time matching - a specific support point of the temperature. + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. @@ -418,7 +418,7 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Support point of the linearized curve of the temperature. + Support point of the linearized curve of the temperature. @@ -427,61 +427,61 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Criteria which enable to stop the simulation in a controlled manner. - Whichever criterion is fulfilled first stops the simulation. + Criteria which enable to stop the simulation in a controlled manner. + Whichever criterion is fulfilled first stops the simulation. - Maximum recrystallized volume fraction. + Maximum recrystallized volume fraction. - Maximum simulated physical time. + Maximum simulated physical time. - Maximum number of iteration steps. + Maximum number of iteration steps. - Settings relevant for stable numerical integration. + Settings relevant for stable numerical integration. - Maximum fraction equivalent to the migration of the - fastest grain boundary in the system how much a cell - may be consumed in a single iteration. + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. - Fraction of the total number of cells in the CA which - should initially be allocated for offering cells in the - recrystallization front. + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. - By how much more times should the already allocated memory - be increased to offer space for storing states of cells - in the recrystallization front. + By how much more times should the already allocated memory + be increased to offer space for storing states of cells + in the recrystallization front. - Should the cache for cells in the recrystallization front - be defragmented on-the-fly. + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. - Heuristic recrystallized volume target values at which - the cache for cells in the recrystallization front - will be defragmented on-the-fly. + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. @@ -491,18 +491,18 @@ TODO: add equation for the Rollett-Holm model the following equation--> - List of recrystallized volume target values at which a - snapshot of the CA state should be stored. - - The code documents summary statistics like recrystallized volume fraction - for each iteration. However, snapshots of the microstructure can take much - space as SCORE is able to evolve automata with up to :math:`1600^3` cells. - Snapshot data document the current microstructure which includes the grain - assigned to each of these cells plus the state of the recrystallization front. - - Despite these front data make up for approximately one order of magnitude - less cells than represented in the domain, more numerical data have to be - collected each cell in the front than just a grain identifier. + List of recrystallized volume target values at which a + snapshot of the CA state should be stored. + + The code documents summary statistics like recrystallized volume fraction + for each iteration. However, snapshots of the microstructure can take much + space as SCORE is able to evolve automata with up to :math:`1600^3` cells. + Snapshot data document the current microstructure which includes the grain + assigned to each of these cells plus the state of the recrystallization front. + + Despite these front data make up for approximately one order of magnitude + less cells than represented in the domain, more numerical data have to be + collected each cell in the front than just a grain identifier. @@ -512,26 +512,26 @@ TODO: add equation for the Rollett-Holm model the following equation--> - Perform a statistical analyses of the results as it was - proposed by M. Kühbach (solitary unit model ensemble approach). + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). - How many independent cellular automaton domains - should be instantiated. + How many independent cellular automaton domains + should be instantiated. - Into how many time steps should the real time interval be discretized upon - during post-processing the results with the solitary unit modeling approach. + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. - List of identifier for those domain which should be rendered. - Identifier start from 0. + List of identifier for those domain which should be rendered. + Identifier start from 0. diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml index 328428cfdd..d28bd09f30 100644 --- a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -113,7 +113,7 @@ inspect comments behind NXmicrostructure--> Programs and libraries representing the computational environment - + @@ -222,7 +222,7 @@ https://docs.lammps.org/Howto_triclinic.html NXcg_polyhedron because a parallele - + Documentation of the spatiotemporal evolution @@ -354,7 +354,7 @@ the typical lean summary statistics flattened--> - + @@ -528,16 +528,16 @@ the typical lean summary statistics flattened--> +exists: optional +current_working_directory: +command_line_call: +exists: optional +start_time(NX_DATE_TIME): +exists: recommended +end_time(NX_DATE_TIME): +exists: recommended +total_elapsed_time(NX_NUMBER): +number_of_processes(NX_POSINT): +number_of_threads(NX_POSINT): +number_of_gpus(NX_POSINT):--> diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml index a6cc4eddc2..0c83c02ee9 100644 --- a/contributed_definitions/NXmpes.nxdl.xml +++ b/contributed_definitions/NXmpes.nxdl.xml @@ -24,23 +24,23 @@ - The symbols used in the schema to specify e.g. dimensions of arrays + The symbols used in the schema to specify e.g. dimensions of arrays - Number of data points in the transmission function. + Number of data points in the transmission function. - This is the most general application definition for - photoemission experiments. - - Groups and fields are named according to the - `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 + This is the most general application definition for + photoemission experiments. + + Groups and fields are named according to the + `ISO 18115-1:2023`_ specification as well as the `IUPAC Recommendations 2020`_. + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _IUPAC Recommendations 2020: https://doi.org/10.1515/pac-2019-0404 @@ -52,76 +52,76 @@ - Datetime of the start of the measurement. - 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. + Datetime of the start of the measurement. + 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. - Datetime of the end of the measurement. - 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. + Datetime of the end of the measurement. + 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. - Name of the experimental method. - - If applicable, this name should match the terms given by `Clause 11`_ of - the `ISO 18115-1:2023`_ specification. - - Examples include: - * X-ray photoelectron spectroscopy (XPS) - * angle-resolved X-ray photoelectron spectroscopy (ARXPS) - * ultraviolet photoelectron spectroscopy (UPS) - * angle-resolved photoelectron spectroscopy (ARPES) - * hard X-ray photoemission spectroscopy (HAXPES) - * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) - * photoelectron emission microscopy (PEEM) - * electron spectroscopy for chemical analysis (ESCA) - * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) - * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) - * momentum microscopy - - .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html - .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 + Name of the experimental method. + + If applicable, this name should match the terms given by `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * angle-resolved photoelectron spectroscopy (ARPES) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * photoelectron emission microscopy (PEEM) + * electron spectroscopy for chemical analysis (ESCA) + * time-resolved angle-resolved X-ray photoelectron spectroscopy (trARPES) + * spin-resolved angle-resolved X-ray photoelectron spectroscopy (spin-ARPES) + * momentum microscopy + + .. _ISO 18115-1:2023: https://www.iso.org/standard/74811.html + .. _Clause 11: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:sec:11 - Description of one or more coordinate systems that are specific to the setup - and the measurement geometry. + Description of one or more coordinate systems that are specific to the setup + and the measurement geometry. - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. + Contact information of at least the user of the instrument or the investigator + who performed this experiment. Adding multiple users if relevant is recommended. - Name of the user. + Name of the user. - Name of the affiliation of the user at the time when the experiment was - performed. + Name of the affiliation of the user at the time when the experiment was + performed. - Description of the photoemission spectrometer and its individual parts. - - This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. - - .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 + Description of the photoemission spectrometer and its individual parts. + + This concept is related to term `12.58`_ of the ISO 18115-1:2023 standard. + + .. _12.58: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.58 - Overall energy resolution of the photoemission instrument. + Overall energy resolution of the photoemission instrument. @@ -131,41 +131,41 @@ - Minimum distinguishable energy separation in the energy spectra. - - This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. - - .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 + Minimum distinguishable energy separation in the energy spectra. + + This concept is related to term `10.24`_ of the ISO 18115-1:2023 standard. + + .. _10.24: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.24 - Ratio of the energy resolution of the photoemission spectrometer at a specified energy - value to that energy value. - - This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. - - .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + Ratio of the energy resolution of the photoemission spectrometer at a specified energy + value to that energy value. + + This concept is related to term `10.7 ff.`_ of the ISO 18115-1:2023 standard. + + .. _10.7 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 - + - + - A source used to generate a beam. Properties refer strictly to parameters of the - source, not of the output beam. For example, the energy of the source is not the - optical power of the beam, but the energy of the electron beam in a synchrotron - or similar. - - Note that the uppercase notation in sourceTYPE means that multiple sources can - be provided. The uppercase part can be substituted with any string that consists - of alphanumeric characters, including both uppercase and lowercase letters from A to Z - and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible - to have both a `source_probe` and a `source_pump`. + A source used to generate a beam. Properties refer strictly to parameters of the + source, not of the output beam. For example, the energy of the source is not the + optical power of the beam, but the energy of the electron beam in a synchrotron + or similar. + + Note that the uppercase notation in sourceTYPE means that multiple sources can + be provided. The uppercase part can be substituted with any string that consists + of alphanumeric characters, including both uppercase and lowercase letters from A to Z + and numerical digits from 0 to 9. For example, in pump-probe experiments, it is possible + to have both a `source_probe` and a `source_pump`. @@ -185,7 +185,7 @@ - Specification of type, may also go to name. + Specification of type, may also go to name. @@ -193,31 +193,31 @@ - + - A reference to a beam emitted by this source. - Should be named with the same appendix, e.g., - for `source_probe` it should refer to `beam_probe`. - - Example: - * /entry/instrument/source_probe = /entry/instrument/beam_probe + A reference to a beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_probe` it should refer to `beam_probe`. + + Example: + * /entry/instrument/source_probe = /entry/instrument/beam_probe - + - Properties of the photon beam at a given location. - Should be named with the same appendix as sourceTYPE, e.g., - for `source_probe` it should refer to `beam_probe`. + Properties of the photon beam at a given location. + Should be named with the same appendix as sourceTYPE, e.g., + for `source_probe` it should refer to `beam_probe`. - Distance between the point where the current NXbeam instance is evaluating - the beam properties and the point where the beam interacts with the sample. - For photoemission, the latter is the point where the the centre of the beam - touches the sample surface. + Distance between the point where the current NXbeam instance is evaluating + the beam properties and the point where the beam interacts with the sample. + For photoemission, the latter is the point where the the centre of the beam + touches the sample surface. @@ -226,13 +226,13 @@ - The source that emitted this beam. - Should be named with the same appendix, e.g., - for `beam_probe` it should refer to `source_probe`. - This should be specified if an associated source exists. - - Example: - * /entry/instrument/beam_probe = /entry/instrument/source_probe + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_probe` it should refer to `source_probe`. + This should be specified if an associated source exists. + + Example: + * /entry/instrument/beam_probe = /entry/instrument/source_probe @@ -240,7 +240,7 @@ - + @@ -259,7 +259,7 @@ - Scheme of the electron collection column. + Scheme of the electron collection column. @@ -274,30 +274,30 @@ - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. + The size and position of the field aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. + The size and position of the contrast aperture inserted in the column. To add + additional or other apertures use the APERTURE group of NXcollectioncolumn. - Size, position and shape of the iris inserted in the column. - - The iris is an aperture in the lens with a variable diameter which can reduce the number of - electrons entering the analyzer. - - To add additional or other slits use the APERTURE group of NXcollectioncolumn. + Size, position and shape of the iris inserted in the column. + + The iris is an aperture in the lens with a variable diameter which can reduce the number of + electrons entering the analyzer. + + To add additional or other slits use the APERTURE group of NXcollectioncolumn. - + @@ -313,41 +313,41 @@ - Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working - with hemispherical analysers. + Either `pass_energy` or `drift_energy` must be supplied. `pass_energy` should be used when working + with hemispherical analysers. - Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the - energy dispersive part of the electron analyzer. + Either `pass_energy` or `drift_energy` must be supplied. `drift_energy` should be used if a TOF is used in the + energy dispersive part of the electron analyzer. - Size, position and shape of the entrance slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the entrance slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. - Size, position and shape of the exit slit in dispersive analyzers. - - To add additional or other slits use the APERTURE group of NXenergydispersion. + Size, position and shape of the exit slit in dispersive analyzers. + + To add additional or other slits use the APERTURE group of NXenergydispersion. - + - Type of electron amplifier in the first amplification step. + Type of electron amplifier in the first amplification step. @@ -356,7 +356,7 @@ - Description of the detector type. + Description of the detector type. @@ -370,44 +370,44 @@ - + - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This group ideally collects the data with the lowest level of processing - possible. - - Fields should be named according to the following convention: - - - **pixel_x**: Detector pixel in x direction. - - **pixel_y**: Detector pixel in y direction. - - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Unit category: NX_ANGLE (° or rad) - - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT - - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. - - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This group ideally collects the data with the lowest level of processing + possible. + + Fields should be named according to the following convention: + + - **pixel_x**: Detector pixel in x direction. + - **pixel_y**: Detector pixel in y direction. + - **energy**: (Un)calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **kx**: (Un)calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: (Un)calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: (Un)calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Unit category: NX_ANGLE (° or rad) + - **time_of_flight**: Total time of flight. Unit category: NX_TIME_OF_FLIGHT + - **time_of_flight_adc**: Time-of-flight values, analog-to-digital converted. + - **external_AXIS**: Describes an axis which is coming from outside the detectors scope. + + Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most + common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. @@ -416,7 +416,7 @@ - Raw data before calibration. + Raw data before calibration. @@ -424,7 +424,7 @@ - Manipulator for positioning of the sample. + Manipulator for positioning of the sample. @@ -445,7 +445,7 @@ - + @@ -457,7 +457,7 @@ - + @@ -489,19 +489,19 @@ - + - + - Device to measure the gas pressure in the instrument. + Device to measure the gas pressure in the instrument. @@ -512,22 +512,22 @@ - In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. - It can also be an 1D array of measured pressures (without time stamps). + In case of a single or averaged gas pressure measurement, this is the scalar gas pressure. + It can also be an 1D array of measured pressures (without time stamps). - In the case of an experiment in which the gas pressure changes and is recorded, - this is an array of length m of gas pressures. + In the case of an experiment in which the gas pressure changes and is recorded, + this is an array of length m of gas pressures. - Device to bring low-energy electrons to the sample for charge neutralization + Device to bring low-energy electrons to the sample for charge neutralization @@ -538,45 +538,45 @@ - In case of a fixed or averaged electron current, this is the scalar current. - It can also be an 1D array of output current (without time stamps). + In case of a fixed or averaged electron current, this is the scalar current. + It can also be an 1D array of output current (without time stamps). - In the case of an experiment in which the electron current is changed and - recorded with time stamps, this is an array of length m of current setpoints. + In the case of an experiment in which the electron current is changed and + recorded with time stamps, this is an array of length m of current setpoints. - A set of activities that occurred to the instrument prior to/during the photoemission - experiment, including any activities performed on the individual instrument parts. - This group can be used to describe the preparation of the instrument prior to the - experiment, e.g. the cleaning procedure for a spin filter crystal. + A set of activities that occurred to the instrument prior to/during the photoemission + experiment, including any activities performed on the individual instrument parts. + This group can be used to describe the preparation of the instrument prior to the + experiment, e.g. the cleaning procedure for a spin filter crystal. - Document an event of data processing, reconstruction, or analysis for this data. - The appropriate axis calibrations for a given experiment should be described using - one or more of the following NXcalibrations. The individual calibrations for a given - `AXISNAME` in `data` should be called `AXISNAME_calibration`. + Document an event of data processing, reconstruction, or analysis for this data. + The appropriate axis calibrations for a given experiment should be described using + one or more of the following NXcalibrations. The individual calibrations for a given + `AXISNAME` in `data` should be called `AXISNAME_calibration`. - + - + - + @@ -601,7 +601,7 @@ - Kinetic energy values + Kinetic energy values @@ -609,7 +609,7 @@ - Relative transmission efficiency for the given kinetic energies + Relative transmission efficiency for the given kinetic energies @@ -620,24 +620,24 @@ - + - For samples containing a single pure substance. For mixtures use the - NXsample_component_set and NXsample_component group in NXsample instead. + For samples containing a single pure substance. For mixtures use the + NXsample_component_set and NXsample_component group in NXsample instead. - The chemical formula of the sample (using CIF conventions). + The chemical formula of the sample (using CIF conventions). - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. @@ -651,167 +651,167 @@ - A set of activities that occurred to the sample prior to/during photoemission - experiment. + A set of activities that occurred to the sample prior to/during photoemission + experiment. - Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, - in-situ growth, sputtering/annealing, etc.). + Details about the sample preparation for the photoemission experiment (e.g. UHV cleaving, + in-situ growth, sputtering/annealing, etc.). - Details about the method of sample preparation before the photoemission - experiment. + Details about the method of sample preparation before the photoemission + experiment. - Sample temperature (either controlled or just measured) and actuators/sensors - controlling/measuring it. + Sample temperature (either controlled or just measured) and actuators/sensors + controlling/measuring it. - Temperature sensor measuring the sample temperature. - - In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor - if a manipulator is present in the instrument. + Temperature sensor measuring the sample temperature. + + In most cases, this can be a link to /entry/instrument/manipulator/temperature_sensor + if a manipulator is present in the instrument. - Device to heat the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_heater - if a manipulator is present in the instrument. + Device to heat the sample. + + In most cases, this can be a link to /entry/instrument/manipulator/sample_heater + if a manipulator is present in the instrument. - Cryostat for cooling the sample. - - In most cases, this can be a link to /entry/instrument/manipulator/cryostat - if a manipulator is present in the instrument. + Cryostat for cooling the sample. + + In most cases, this can be a link to /entry/instrument/manipulator/cryostat + if a manipulator is present in the instrument. - This is to be used if there is no actuator/sensor that controls/measures - the temperature. - - 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 temperature is not advised, but using - NXsensor and NXactuator is strongly recommended instead. + This is to be used if there is no actuator/sensor that controls/measures + the temperature. + + 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 temperature is not advised, but using + NXsensor and NXactuator is strongly recommended instead. - Gas pressure surrounding the sample and actuators/sensors controlling/measuring - it. + Gas pressure surrounding the sample and actuators/sensors controlling/measuring + it. - Gauge measuring the gas pressure. - - In most cases, this can be a link to /entry/instrument/pressure_gauge or to another - NXsensor measuring gas pressure (typically, the gauge in closest proximity to the - sample) if such a pressure gauge is present in the instrument. + Gauge measuring the gas pressure. + + In most cases, this can be a link to /entry/instrument/pressure_gauge or to another + NXsensor measuring gas pressure (typically, the gauge in closest proximity to the + sample) if such a pressure gauge is present in the instrument. - This is to be used if there is no actuator/sensor that controls/measures - the gas pressure around the sample. An example would be a UHV experiment where the - gas pressure is not monitored. - - Note that this method for recording the gas pressure is not advised, but using - NXsensor and NXactuator is strongly recommended instead. + This is to be used if there is no actuator/sensor that controls/measures + the gas pressure around the sample. An example would be a UHV experiment where the + gas pressure is not monitored. + + Note that this method for recording the gas pressure is not advised, but using + NXsensor and NXactuator is strongly recommended instead. - Bias of the sample with respect to analyser ground and actuators/sensors - controlling/measuring it. - - This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. - - .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 + Bias of the sample with respect to analyser ground and actuators/sensors + controlling/measuring it. + + This concept is related to term `8.41`_ of the ISO 18115-1:2023 standard. + + .. _8.41: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:8.41 - Sensor measuring the applied voltage. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter - if a manipulator is present in the instrument. + Sensor measuring the applied voltage. + + In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_voltmeter + if a manipulator is present in the instrument. - Actuator applying a voltage to sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat - if a manipulator is present in the instrument. + Actuator applying a voltage to sample and sample holder. + + In most cases, this can be a link to /entry/instrument/manipulator/sample_bias_potentiostat + if a manipulator is present in the instrument. - This is to be used if there is no actuator/sensor that controls/measures - the bias. - - Note that this method for recording the bias is not advised, but using - NXsensor and NXactuator is strongly recommended instead. + This is to be used if there is no actuator/sensor that controls/measures + the bias. + + Note that this method for recording the bias is not advised, but using + NXsensor and NXactuator is strongly recommended instead. - Drain current of the sample and sample holder. + Drain current of the sample and sample holder. - Amperemeter measuring the drain current of the sample and sample holder. - - In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter - if a manipulator is present in the instrument. + Amperemeter measuring the drain current of the sample and sample holder. + + In most cases, this can be a link to /entry/instrument/manipulator/drain_current_amperemeter + if a manipulator is present in the instrument. - This is to be used if there is no actuator/sensor that controls/measures - the drain current. - - Note that this method for recording the drain current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. + This is to be used if there is no actuator/sensor that controls/measures + the drain current. + + Note that this method for recording the drain current is not advised, but using + NXsensor and NXactuator is strongly recommended instead. - Current of low-energy electrons to the sample (for charge neutralization) and - actuators/sensors controlling/measuring it. + Current of low-energy electrons to the sample (for charge neutralization) and + actuators/sensors controlling/measuring it. - Flood gun creating a current of low-energy electrons. - - In most cases this can be a link to /entry/instrument/flood_gun - if a flood_gun is present in the instrument. + Flood gun creating a current of low-energy electrons. + + In most cases this can be a link to /entry/instrument/flood_gun + if a flood_gun is present in the instrument. - This is to be used if there is no actuator/sensor that controls/measures - the drain_current. - - Note that this method for recording the flood gun current is not advised, but using - NXsensor and NXactuator is strongly recommended instead. + This is to be used if there is no actuator/sensor that controls/measures + the drain_current. + + Note that this method for recording the flood gun current is not advised, but using + NXsensor and NXactuator is strongly recommended instead. @@ -819,40 +819,40 @@ - The default NXdata group containing a view on the measured data. - This NXdata group contains a collection of the main relevant fields (axes). - If you want to provide additional views on your data, you can additionally use - the generic NXdata group of NXentry. - - In NXmpes, it is recommended to provide an energy axis. - - Fields should be named according to the following convention: - - - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). - - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). - - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). - - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). - - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). - Unit category: NX_ANGLE - - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_ANGLE - - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) - Unit category: NX_LENGTH - - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) - Unit category: NX_LENGTH - - **delay**: Calibrated delay time. Unit category: NX_TIME (s). - - **polarization_angle**: Linear polarization angle of the incoming or - outgoing beam. This could be a link to - /entry/instrument/beam/incident_polarization_angle or - /entry/instrument/beam/final_polarization_angle if they exist. - Unit category: NX_ANGLE (° or rad) - - **ellipticity**: Ellipticity of the incoming or outgoing beam. - Could be a link to /entry/instrument/beam/incident_ellipticity or - /entry/instrument/beam/final_ellipticity if they exist. - Unit category: NX_ANGLE (° or rad) - - Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most - common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. + The default NXdata group containing a view on the measured data. + This NXdata group contains a collection of the main relevant fields (axes). + If you want to provide additional views on your data, you can additionally use + the generic NXdata group of NXentry. + + In NXmpes, it is recommended to provide an energy axis. + + Fields should be named according to the following convention: + + - **energy**: Calibrated energy (kinetic or binding energy). Unit category: NX_ENERGY (e.g., eV). + - **kx**: Calibrated x axis in k-space. Unit category: NX_ANY (e.g., 1/Angström). + - **ky**: Calibrated y axis in k-space. Unit category: NX_ANY (1/Angström). + - **kz**: Calibrated z axis in k-space. Unit category: NX_ANY (1/Angström). + - **angular0**: Fast-axis angular coordinate (or second slow axis if angularly integrated). + Unit category: NX_ANGLE + - **angular1**: Slow-axis angular coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_ANGLE + - **spatial0**: Fast-axis spatial coordinate (or second slow axis if spatially integrated) + Unit category: NX_LENGTH + - **spatial1**: Slow-axis spatial coordinate (or second fast axis if simultaneously dispersed in 2 dimensions) + Unit category: NX_LENGTH + - **delay**: Calibrated delay time. Unit category: NX_TIME (s). + - **polarization_angle**: Linear polarization angle of the incoming or + outgoing beam. This could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + Unit category: NX_ANGLE (° or rad) + - **ellipticity**: Ellipticity of the incoming or outgoing beam. + Could be a link to /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + Unit category: NX_ANGLE (° or rad) + + Note that this list is a glossary with explicitly named axis names, which is only intended to cover the most + common measurement axes and is therefore not complete. It is possible to add axes with other names at any time. @@ -861,54 +861,54 @@ - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. + Represents a measure of one- or more-dimensional photoemission counts, where the + varied axis may be for example energy, momentum, spatial coordinate, pump-probe + delay, spin index, temperature, etc. The axes traces should be linked to the + actual encoder position in NXinstrument or calibrated axes in NXprocess. - Calibrated energy axis. - - Could be linked from the respective '@reference' field. + Calibrated energy axis. + + Could be linked from the respective '@reference' field. - The energy can be either stored as kinetic or as binding energy. + The energy can be either stored as kinetic or as binding energy. - Calibrated kinetic energy axis. - - In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` - (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are - provided as :math:`E-E_F`. - - This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. - - .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + Calibrated kinetic energy axis. + + In case the kinetic energy axis is referenced to the Fermi level :math:`E_F` + (e.g., in entry/process/energy_referencing), kinetic energies :math:`E` are + provided as :math:`E-E_F`. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 - Calibrated binding energy axis. - - This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. - - .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 - The energy can be dispersed according to different strategies. ``@reference`` points to - the path of a field defining the calibrated axis which the ``energy`` axis refers. - - For example: - @reference: 'entry/process/energy_calibration/calibrated_axis' + The energy can be dispersed according to different strategies. ``@reference`` points to + the path of a field defining the calibrated axis which the ``energy`` axis refers. + + For example: + @reference: 'entry/process/energy_calibration/calibrated_axis' diff --git a/contributed_definitions/NXmpes_arpes.nxdl.xml b/contributed_definitions/NXmpes_arpes.nxdl.xml index 2af10d039c..3f932b3fdf 100644 --- a/contributed_definitions/NXmpes_arpes.nxdl.xml +++ b/contributed_definitions/NXmpes_arpes.nxdl.xml @@ -57,7 +57,7 @@ with higher granularity in the data description.--> - + Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. @@ -73,7 +73,7 @@ with higher granularity in the data description.--> - + Analyzer angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. diff --git a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml index 83b3f94d98..6b26be7a76 100644 --- a/contributed_definitions/NXoptical_spectroscopy.nxdl.xml +++ b/contributed_definitions/NXoptical_spectroscopy.nxdl.xml @@ -40,51 +40,51 @@ TODO: - Variables used throughout the document, e.g. dimensions or parameters. + Variables used throughout the document, e.g. dimensions or parameters. - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. - A general application definition of optical spectroscopy elements, which may - be used as a template to derive specialized optical spectroscopy experiments. - - Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, - reflectivity/transmission spectroscopy. - - A general optical experiment consists of (i) a light/photon source, (ii) a sample, - (iii) a detector. - - For any free text descriptions, it is recommended to enter data in english - language, as this is the most FAIR representation. + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. + + For any free text descriptions, it is recommended to enter data in english + language, as this is the most FAIR representation. - An application definition describing a general optical experiment. + An application definition describing a general optical experiment. - Version number to identify which definition of this application - definition was used for this entry/data. + Version number to identify which definition of this application + definition was used for this entry/data. - URL where to find further material (documentation, examples) relevant - to the application definition. + URL where to find further material (documentation, examples) relevant + to the application definition. @@ -94,67 +94,64 @@ TODO: - Datetime of the start of the measurement. - 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 required to enter at least one of both measurement times, either "start_time" or "end_time". + Datetime of the start of the measurement. + 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 required to enter at least one of both measurement times, either "start_time" or "end_time". - Datetime of the end of the measurement. - 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 required to enter at least one of both measurement times, either "start_time" or "end_time". + Datetime of the end of the measurement. + 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 required to enter at least one of both measurement times, either "start_time" or "end_time". - + - A (globally persistent) unique identifier of the experiment. - (i) The identifier is usually defined by the facility, laboratory or - principal investigator. - (ii) The identifier enables to link experiments to e.g. proposals. + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility, laboratory or + principal investigator. + (ii) The identifier enables to link experiments to e.g. proposals. - - - + - Select the range of validity of this identier. - Local: Setup#1 at Institute building #2 in Room #3 - Global: Unique identification of with by unique location and unique - globally persistent time stamp. + Select the range of validity of this identier. + Local: Setup#1 at Institute building #2 in Room #3 + Global: Unique identification of with by unique location and unique + globally persistent time stamp. - - - + + - An optional free-text description of the experiment. - - Users are strongly advised to parameterize the description of their experiment - by using respective groups and fields and base classes instead of writing prose - into this field. - - The reason is that such a free-text field is difficult to machine-interpret. - The motivation behind keeping this field for now is to learn how far the - current base classes need extension based on user feedback. + An optional free-text description of the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. - Specify the type of the optical experiment. - - Chose other if none of these methods are suitable. You may specify - fundamental characteristics or properties in the experimental sub-type. - - For Raman spectroscopy or ellipsometry use the respective specializations - of NXoptical_spectroscopy. + Specify the type of the optical experiment. + + Chose other if none of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. @@ -165,8 +162,8 @@ TODO: - Specify a special property or characteristic of the experiment, which specifies - the generic experiment type. + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. @@ -177,97 +174,97 @@ TODO: - If "other" was selected in "experiment_type" and/or in "experiment_sub_type", - specify the experiment here with a free text name, which is knwon in the - respective community of interest. + If "other" was selected in "experiment_type" and/or in "experiment_sub_type", + specify the experiment here with a free text name, which is knwon in the + respective community of interest. - Description of one or more coordinate systems that are specific to the - experiment. Examples are beam centered, sample-normal centered, - laboratory-system centered, sample-stage centered, crystal-symmetry centered. + Description of one or more coordinate systems that are specific to the + experiment. Examples are beam centered, sample-normal centered, + laboratory-system centered, sample-stage centered, crystal-symmetry centered. - This refers to the coordinate system along the beam path. The origin and - base is defined at z=0, where the incident beam hits the sample at the surface. + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. - This is the default NeXus coordinate system (McStas), if the transformation - does not change the coordinate system at all - i.e. it is unity. - Otherwise, by this a respective transformation of the beam - reference frame to the default reference frame could be made. i.e. - exchange of x and z coordinate, rotation of respective coordinates - towards each other. + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. - Link to transformations defining the sample-normal base coordinate system, - which is defined such that the positive z-axis is parallel to the sample normal, - and the x-y-plane lies inside the sample surface. + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. - Set of transformations, describing the orientation of the sample-normal coordinate system - with respect to the beam coordinate system (.). + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). - Contact information and eventually details of at persons who - performed the measurements. This can be for example the principal - investigator or student. Examples are: name, affiliation, address, telephone - number, email, role as well as identifiers such as orcid or similar. - It is recommended to add multiple users if relevant. - - Due to data privacy concerns, there is no minimum requirement. - If no user with specific name is allowed to be given, it is required to - assign at least an affiliation + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation - Devices or elements of the optical spectroscopy setup described with its - properties and general information. - - This includes for example: - - The beam device's or instrument's model, company, serial number, construction year, etc. - - Used software or code - - Experiment descriptive parameters as reference frames, resolution, calibration - - Photon beams with their respective properties such as angles and polarization - - Various optical beam path devices, which interact, manipulate or measure optical beams - - Characteristics of the medium surrounding the sample - - "Beam devices" for a beam path description - - Stages(NXmanipulator) - - Sensors and actuators to control or measure sample or beam properties + Devices or elements of the optical spectroscopy setup described with its + properties and general information. + + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties - + - This can be used to describe properties of a photon beam. - A beam is always defined between two beam_devices, via - "previous_device" and "next_device". - - It is required to define at least one incident beam which is incident - to the sample. You may specify if this beam parameters are acutally measured - or just nominal. - If this beam is the output of a source, chose the same - name appendix as for the NXsource instance (e.g. TYPE=532nm) + This can be used to describe properties of a photon beam. + A beam is always defined between two beam_devices, via + "previous_device" and "next_device". + + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are acutally measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) - Select the reliability of the respective beam characteristics. Either, - the parameters are measured via another device or method or just given - nominally via the properties of a light source properties (532nm, 100mW). + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). @@ -280,16 +277,16 @@ TODO: - The path to the device which emitted this beam (light source or frequency doubler). - - This parameter is recommended, if the previous optical element is a photon source. - In this way, the properties of the laser or light souce can be described - and associated. - The beam should be named with the same appendix as the source, e.g., - for TYPE=532nmlaser, there should be both a NXsource named - "source_532nmlaser" and a NXbeam named "beam_532nmlaser". - - Example: /entry/instrument/source_532nmlaser + The path to the device which emitted this beam (light source or frequency doubler). + + This parameter is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light souce can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". + + Example: /entry/instrument/source_532nmlaser @@ -303,14 +300,14 @@ TODO: - Angle of the linear polarized light, with respect to a fixed arbitrary - defined 0° position. This can be used if no definition of respective - cooridnate systems for beam and sample normal is done. If coordinate systems - are defined, refer to beam "incident_polarization". + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. This can be used if no definition of respective + cooridnate systems for beam and sample normal is done. If coordinate systems + are defined, refer to beam "incident_polarization". - + @@ -319,7 +316,7 @@ TODO: - Description of the detector type. + Description of the detector type. @@ -336,16 +333,16 @@ TODO: - Type of detector, if "other" was selected in "detector_type". + Type of detector, if "other" was selected in "detector_type". - Contains the raw data collected by the detector before calibration. - The data which is considered raw might change from experiment to experiment - due to hardware pre-processing of the data. - This field ideally collects the data with the lowest level of processing - possible. + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. - Allows description of beam properties via matrices, which relate ingoing with - outgoing beam properties. + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. - Sample stage (or manipulator) for positioning of the sample. This should - only contain the spatial orientation of movement. + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. - Specify the type of the sample stage. + Specify the type of the sample stage. @@ -771,24 +768,24 @@ Can be used to describe a beam splitter as optical element.--> - If "other" was chosen in stage_type, enter here a free text description - of the stage type. + If "other" was chosen in stage_type, enter here a free text description + of the stage type. - This allows a description of the stages relation or orientation and - position with respect to the sample or beam, if an laboratory or - an stage coordinate system is defined. + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. - Description of relation of the beam with the sample. How dit the - sample hit the beam, e.g. 'center of sample, long edge parallel - to the plane of incidence'. - Is redundent, if a full orientation description is done via the - stages "transformations" entry. + Description of relation of the beam with the sample. How dit the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + Is redundent, if a full orientation description is done via the + stages "transformations" entry. @@ -804,10 +801,10 @@ Can be used to describe a beam splitter as optical element.--> - + - Type of control for the sample temperature. Replace TYPE by "cryostat" or - "heater" to specify it. + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. @@ -823,75 +820,75 @@ Can be used to describe a beam splitter as optical element.--> - Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive - + - General device information of the optical spectroscopy setup, if - suitable (e.g. for a tabletop spectrometer or other non-custom build setups). - For custom build setups, this may be limited to the construction year. + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. - + - + - Commercial or otherwise defined given name of the program that was - used to control any parts of the optical spectroscopy setup. - The uppercase TYPE should be replaced by a specification name, i.e. - "software_detector" or "software_stage" to specify the respective - program or software components. + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. - Description of the software by persistent resource, where the program, - code, script etc. can be found. + Description of the software by persistent resource, where the program, + code, script etc. can be found. - + - Pre-calibration of an arbitrary device of the instrumental setup, which - has the name DEVICE. You can specify here how, at which time by which method - the calibration was done. As well the accuracy and a link to the calibration - dataset. + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. - Path to the device, which was calibrated. - Example: entry/instrument/DEVICE + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE - Provide data about the determined accuracy of the device, this may - may be a single value or a dataset like wavelength error vs. wavelength etc. + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. - Was a calibration performed? If yes, when was it done? If the - calibration time is provided, it should be specified in - ENTRY/INSTRUMENT/calibration/calibration_time. + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. @@ -903,21 +900,21 @@ Can be used to describe a beam splitter as optical element.--> - If calibtration status is 'calibration time provided', specify the - ISO8601 date when calibration was last performed before this - measurement. UTC offset should be specified. + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. - Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. - This can be for example the instrument response function. + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. - The overall resolution of the optical instrument. + The overall resolution of the optical instrument. @@ -927,16 +924,16 @@ Can be used to describe a beam splitter as optical element.--> - Minimum distinguishable wavelength separation of peaks in spectra. + Minimum distinguishable wavelength separation of peaks in spectra. - Array of pairs of complex refractive indices n + ik of the medium - for every measured spectral point/wavelength/energy. - Only necessary if the measurement was performed not in air, or - something very well known, e.g. high purity water. + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. @@ -946,71 +943,71 @@ Can be used to describe a beam splitter as optical element.--> - Properties of the sample, such as sample type, layer structure, - chemical formula, atom types, its history etc. - Information about the sample stage and sample environment should be - described in ENTRY/INSTRUMENT/sample_stage. + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. - Locally unique ID of the sample, used in the reasearch institute or group. + Locally unique ID of the sample, used in the reasearch institute or group. - State the form of the sample, examples are: - thin film, single crystal, poly crystal, amorphous, single layer, - multi layer, liquid, gas, pellet, powder. - Generic properties of liquids or gases see NXsample properties. + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. - Free text description of the sample. + Free text description of the sample. - Chemical formula of the sample. Use the Hill system (explained here: - https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write - the chemical formula. In case the sample consists of several layers, - this should be a list of the chemical formulas of the individual - layers, where the first entry is the chemical formula of the top - layer (the one on the front surface, on which the light incident). - The order must be consistent with layer_structure + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure - List of comma-separated elements from the periodic table that are - contained in the sample. If the sample substance has multiple - components, all elements from each component must be included in - 'atom_types'. + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. - ISO 8601 time code with local time zone offset to UTC information - when the specimen was prepared. - - Ideally, report the end of the preparation, i.e. the last known timestamp when - the measured specimen surface was actively prepared. + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. - A set of activities that occurred to the sample prior to/during the experiment. + A set of activities that occurred to the sample prior to/during the experiment. - Sample temperature (either controlled or just measured). + Sample temperature (either controlled or just measured). - If no sensor was available for the determination of temperature, selected - a nominal value which represents approximately the situation of sample temperature. + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. @@ -1021,38 +1018,38 @@ Can be used to describe a beam splitter as optical element.--> - If temperature_nominal is "other", enter here a nominal/assumed/estimated - sample temperature. + If temperature_nominal is "other", enter here a nominal/assumed/estimated + sample temperature. - Temperature sensor measuring the sample temperature. - This should be a link to /entry/instrument/manipulator/temperature_sensor. + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. - Device to heat the sample. - This should be a link to /entry/instrument/manipulator/sample_heater. + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. - Device for cooling the sample (Cryostat, Airflow cooler, etc.). - This should be a link to /entry/instrument/manipulator/cryostat. + Device for cooling the sample (Cryostat, Airflow cooler, etc.). + This should be a link to /entry/instrument/manipulator/cryostat. - Arbirary sample property which may be varied during the experiment - and controlled by a device. Examples are pressure, voltage, magnetic field etc. - Similar to the temperautre description of the sample. + Arbirary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperautre description of the sample. - Medium, in which the sample is placed. + Medium, in which the sample is placed. @@ -1069,72 +1066,72 @@ Can be used to describe a beam splitter as optical element.--> - (Measured) sample thickness. - - The information is recorded to qualify if the light used was likely - able to shine through the sample. - - In this case the value should be set to the actual thickness of - the specimen viewed for an illumination situation where the nominal - surface normal of the specimen is parallel to the optical axis. + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. - If a thickness if given, please specify how this thickness was estimated or - determined. + If a thickness if given, please specify how this thickness was estimated or + determined. - Qualitative description of the layer structure for the sample, - starting with the top layer (i.e. the one on the front surface, on - which the light incident), e.g. native oxide/bulk substrate, or - Si/native oxide/thermal oxide/polymer/peptide. + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. - Specify the sample orientation, how is its sample normal oriented - relative in the laboratory reference frame, incident beam reference - frame. + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. - If the sample is grown or fixed on a substrate, specify this here by - a free text description. + If the sample is grown or fixed on a substrate, specify this here by + a free text description. - Here generic types of data may be saved.. This may refer to data derived - from single or multiple raw measurements (i.e. several intensities are - evaluated for different parameters: ellipsometry -> psi and delta) - - i.e. non-raw data. - As well plotable data may be stored/linked here, which provides the most suitable - representation of the data (for the respective community). - - You may provide multiple instances of NXdata + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). + + You may provide multiple instances of NXdata - Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) - Spectrum, i.e. y-axis of the data (e.g. counts, intensity) + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) - + - Location to save the calibrated wavelength data. + Location to save the calibrated wavelength data. @@ -1145,11 +1142,11 @@ raw data from ellipsometry as polarization values to the usually used psi and delta values), will be done later after the NXopt workshop.--> - Parameters that are derived from the measured data. + Parameters that are derived from the measured data. - Light loss due to depolarization as a value in [0-1]. + Light loss due to depolarization as a value in [0-1]. @@ -1159,7 +1156,7 @@ psi and delta values), will be done later after the NXopt workshop.--> - Jones quality factor. + Jones quality factor. @@ -1169,7 +1166,7 @@ psi and delta values), will be done later after the NXopt workshop.--> - Reflectivity. + Reflectivity. @@ -1179,7 +1176,7 @@ psi and delta values), will be done later after the NXopt workshop.--> - Transmittance. + Transmittance. @@ -1187,22 +1184,22 @@ psi and delta values), will be done later after the NXopt workshop.--> - + - Commercial or otherwise defined given name of the program that was - used to generate or calculate the derived parameters. - If home written, one can provide the actual steps in the NOTE - subfield here. + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. - Either version with build number, commit hash, or description of a - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml deleted file mode 100644 index 1390770b10..0000000000 --- a/contributed_definitions/NXpid.nxdl.xml +++ /dev/null @@ -1,111 +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. - - - - - Time log of the setpoint(s) used as an input for the PID controller. - - - - - 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 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. - - - - - 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 - - - - - 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. - - - - - .. 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/NXpid_controller.nxdl.xml b/contributed_definitions/NXpid_controller.nxdl.xml new file mode 100644 index 0000000000..d4ac03ad16 --- /dev/null +++ b/contributed_definitions/NXpid_controller.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + 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. + + + + + Time log of the setpoint(s) used as an input for the PID controller. + + + + + 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 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. + + + + + 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 + + + + + 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. + + + + + .. 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/NXpiezo_config_spm.nxdl.xml b/contributed_definitions/NXpiezo_config_spm.nxdl.xml index 49da37c8b8..9c4bab1e03 100644 --- a/contributed_definitions/NXpiezo_config_spm.nxdl.xml +++ b/contributed_definitions/NXpiezo_config_spm.nxdl.xml @@ -25,28 +25,28 @@ Discussion: No need to create this base class rather we can define in spm application definition.--> - A base class describing piezo actuator settings for scanning probe microscopy. - - Piezoelectric actuators work utilizing the inverse-piezoelectric effect, when a voltage - is applied on the material and it deforms proportional to the applied voltage. - Description below shows calibration coefficients and other configuration parameters of open loop piezo actuators (that is actuators without capacitive sensor feedback systems). + A base class describing piezo actuator settings for scanning probe microscopy. + + Piezoelectric actuators work utilizing the inverse-piezoelectric effect, when a voltage + is applied on the material and it deforms proportional to the applied voltage. + Description below shows calibration coefficients and other configuration parameters of open loop piezo actuators (that is actuators without capacitive sensor feedback systems). - The material description and properties of the piezoelectric scanner materials. + The material description and properties of the piezoelectric scanner materials. - + - The N (substring) denotes X or Y. There are 2 parameters in X and Y directions. It can be set - approximately to the length of the piezo tube along X and Y axis. + The N (substring) denotes X or Y. There are 2 parameters in X and Y directions. It can be set + approximately to the length of the piezo tube along X and Y axis. - The name of the calibration type, sometimes it is called - `active calibration`. + The name of the calibration type, sometimes it is called + `active calibration`. @@ -55,68 +55,68 @@ Discussion: No need to create this base class rather we can define in spm applic - A specific name of the calibration (e.g. active type with name 'LHe'). + A specific name of the calibration (e.g. active type with name 'LHe'). - The date of the calibration. + The date of the calibration. - + - The AXIS (substring) denotes X, Y or Z. There are three directions X, Y, and Z for calibration, - along with three available parameters each: Calibration (m/V), Range (m), and HV gain. Only - two of these parameters are required to define the calibration. Consequently, when any - value is changed, one of the other values will be automatically updated. + The AXIS (substring) denotes X, Y or Z. There are three directions X, Y, and Z for calibration, + along with three available parameters each: Calibration (m/V), Range (m), and HV gain. Only + two of these parameters are required to define the calibration. Consequently, when any + value is changed, one of the other values will be automatically updated. - + - The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For - these systems, the HV gain should be automatically adjusted whenever the gain is - changed at the high voltage amplifier. + The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For + these systems, the HV gain should be automatically adjusted whenever the gain is + changed at the high voltage amplifier. - + - The N (substring) denotes X or Y or Z. There are 3 parameters in X, Y and Z directions. The range - is the maximum distance the piezo can move. + The N (substring) denotes X or Y or Z. There are 3 parameters in X, Y and Z directions. The range + is the maximum distance the piezo can move. - + - The calibration coefficient is the ratio of the actual distance moved by the piezo due to - the voltage applied to the piezo. It is also called first-order correction. + The calibration coefficient is the ratio of the actual distance moved by the piezo due to + the voltage applied to the piezo. It is also called first-order correction. - + - The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according - to the actual surface. + The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according + to the actual surface. - + - The N (substring) denotes X and Y directions. If you know them, you can enter the 2nd order piezo - characteristics to compensate the error for that axis. - The following equation shows the - interpretation of the 2nd order correction parameters, For the X-piezo: "Ux = 1/cx · X + cxx · X2" - with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" - where cx is the calibration of the piezo X and cxx is the 2nd order correction. The unit for - such the second-order correction is (V/m^2). + The N (substring) denotes X and Y directions. If you know them, you can enter the 2nd order piezo + characteristics to compensate the error for that axis. + The following equation shows the + interpretation of the 2nd order correction parameters, For the X-piezo: "Ux = 1/cx · X + cxx · X2" + with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" + where cx is the calibration of the piezo X and cxx is the 2nd order correction. The unit for + such the second-order correction is (V/m^2). - The drift correction status (true / false) in calibration step of piezo. + The drift correction status (true / false) in calibration step of piezo. - + - The N (substring) denotes X, Y and Z directions. Define the - drift speed [m/s] for all three axes. When the compensation is on, the piezo will start to - move at that speed. + The N (substring) denotes X, Y and Z directions. Define the + drift speed [m/s] for all three axes. When the compensation is on, the piezo will start to + move at that speed. diff --git a/contributed_definitions/NXpiezoelectric_material.nxdl.xml b/contributed_definitions/NXpiezoelectric_material.nxdl.xml index 510036fc09..b3b0084c5d 100644 --- a/contributed_definitions/NXpiezoelectric_material.nxdl.xml +++ b/contributed_definitions/NXpiezoelectric_material.nxdl.xml @@ -23,9 +23,9 @@ --> - Description and properties of the piezoelectric actuator materials. - The piezoelectric actuator is usually composed of polycrystalline solids and - attached at the head of the tip or cantilever. The material deforms when the external electric field is applied. + Description and properties of the piezoelectric actuator materials. + The piezoelectric actuator is usually composed of polycrystalline solids and + attached at the head of the tip or cantilever. The material deforms when the external electric field is applied. - The name of the material of the piezo scanner such as Lead Zirconate Titanates - (PZTs). + The name of the material of the piezo scanner such as Lead Zirconate Titanates + (PZTs). - + - The identifier of the piezo material. + The identifier of the piezo material. - - - The identifier of the piezo material. - - - + - The chemical formula of the material of the piezo scanner such as Pb(Zr,Ti)O3. + The chemical formula of the material of the piezo scanner such as Pb(Zr,Ti)O3. - The type of the material of the piezo scanner (e.g. piezoelectric ceramics, - polymer-film piezoelectrics). + The type of the material of the piezo scanner (e.g. piezoelectric ceramics, + polymer-film piezoelectrics). - The density of the piezo material. + The density of the piezo material. - The relative permittivity (dielectric constant) of the piezo material. + The relative permittivity (dielectric constant) of the piezo material. - + - The piezoelectric charge coefficients of the material. The coefficients describe the electric - polarization generated by the applied stress in material. Different coefficients correspond to different - relative directions of the polarization and the stress. + The piezoelectric charge coefficients of the material. The coefficients describe the electric + polarization generated by the applied stress in material. Different coefficients correspond to different + relative directions of the polarization and the stress. - + - The constants define the electric field produced by the external mechanical strain. Different coefficients - correspond to different relative directions of the electric field and the strain. + The constants define the electric field produced by the external mechanical strain. Different coefficients + correspond to different relative directions of the electric field and the strain. - + - The electromechanical constant measures the efficiency of the conversion of mechanical energy - into electrical energy. + The electromechanical constant measures the efficiency of the conversion of mechanical energy + into electrical energy. - + - The pyroelectric constant defines the change of the polarization vector of the piezoelectric material - per unit change in temperature. + The pyroelectric constant defines the change of the polarization vector of the piezoelectric material + per unit change in temperature. - The acoustic impedance of the piezo material. + The acoustic impedance of the piezo material. - The Young's modulus of the piezo material. + The Young's modulus of the piezo material. - The surface resistivity of the piezo material. + The surface resistivity of the piezo material. - The temperature range of the piezo material. + The temperature range of the piezo material. - The range of temperature where a piezoelectric hard material transforms into the - viscous state. + The range of temperature where a piezoelectric hard material transforms into the + viscous state. diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXpolarizer_opt.nxdl.xml index 5689ef0f78..b90e9358b2 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXpolarizer_opt.nxdl.xml @@ -23,7 +23,7 @@ --> - + diff --git a/contributed_definitions/NXpositioner_spm.nxdl.xml b/contributed_definitions/NXpositioner_spm.nxdl.xml index 127f00d17e..ba85d3dbc1 100644 --- a/contributed_definitions/NXpositioner_spm.nxdl.xml +++ b/contributed_definitions/NXpositioner_spm.nxdl.xml @@ -23,38 +23,38 @@ --> - Extending positioner from NXpositioner to maintain a measurement signal through - a feedback loop, specialized for scanning probe microscopy applications. + Extending positioner from NXpositioner to maintain a measurement signal through + a feedback loop, specialized for scanning probe microscopy applications. - + - This controller's task is to continuously adjust the Z position of the STM/STS tip in order - to keep the selected control signal as close as possible to the Set Point. Different control - signals lead to different controller's behavior. - - The second PID feedback loop intends to position the tip in the Z direction. - - p_gain (proportional gain) from z_controller is the same as K_p_value from PID controller. - i_gain (integral gain) from z_controller is the same as K_i_value from PID controller. - setpoint from z_controller is the same as setpoint from PID controller. + This controller's task is to continuously adjust the Z position of the STM/STS tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different controller's behavior. + + The second PID feedback loop intends to position the tip in the Z direction. + + p_gain (proportional gain) from z_controller is the same as K_p_value from PID controller. + i_gain (integral gain) from z_controller is the same as K_i_value from PID controller. + setpoint from z_controller is the same as setpoint from PID controller. - Offset added to the initial averaged position tip on Z-axis before starting to - scan. + Offset added to the initial averaged position tip on Z-axis before starting to + scan. - Indicate the tip position Z. The tip position can also be varied when the controller is not running. - This is the final position after the tip reaches an equilibrium state. + Indicate the tip position Z. The tip position can also be varied when the controller is not running. + This is the final position after the tip reaches an equilibrium state. - Controller name. This name which will be displayed at places where you can select a - controller. + Controller name. This name which will be displayed at places where you can select a + controller. diff --git a/contributed_definitions/NXpositioner_sts.nxdl.xml b/contributed_definitions/NXpositioner_sts.nxdl.xml index d76e65d4e2..2750d55bde 100644 --- a/contributed_definitions/NXpositioner_sts.nxdl.xml +++ b/contributed_definitions/NXpositioner_sts.nxdl.xml @@ -1,4 +1,4 @@ - + - A generic positioner such as a motor or piezo-electric transducer. + A generic positioner such as a motor or piezo-electric transducer. - symbolic or mnemonic name (one word) + symbolic or mnemonic name (one word) - description of positioner + description of positioner - best known value of positioner - need [n] as may be scanned + best known value of positioner - need [n] as may be scanned @@ -45,7 +45,7 @@ - raw value of positioner - need [n] as may be scanned + raw value of positioner - need [n] as may be scanned @@ -53,7 +53,7 @@ - targeted (commanded) value of positioner - need [n] as may be scanned + targeted (commanded) value of positioner - need [n] as may be scanned @@ -61,7 +61,7 @@ - maximum allowable difference between target_value and value + maximum allowable difference between target_value and value @@ -69,242 +69,242 @@ - minimum allowed limit to set value + minimum allowed limit to set value - maximum allowed limit to set value + maximum allowed limit to set value - velocity of the positioner (distance moved per unit time) + velocity of the positioner (distance moved per unit time) - time to ramp the velocity up to full speed + time to ramp the velocity up to full speed - Hardware device record, e.g. EPICS process variable, taco/tango ... + Hardware device record, e.g. EPICS process variable, taco/tango ... - .. 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 positioner. + 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 positioner. - 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. - To clarify the frame laboratory frame. The scanning area in x, y, and z position in the - frame. + To clarify the frame laboratory frame. The scanning area in x, y, and z position in the + frame. - This controllers task is to continuously adjust the Z position of the stm tip in order - to keep the selected control signal as close as possible to the Set Point. Different control - signals lead to different contronller beahvior. + This controllers task is to continuously adjust the Z position of the stm tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different contronller beahvior. - Offset added to the initial averaged position Zaver before starting to swepp. + Offset added to the initial averaged position Zaver before starting to swepp. - Indicate the tip position Z between tip and sample. The tip position can also be varied when - the controller is not running. + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. - Controller name. This name which will be displayed at places where you can select a - controller. + Controller name. This name which will be displayed at places where you can select a + controller. - Set Point is the desired value of the control signal. It can be set by editing the number - or using the slider bar. Click the "Set" button above the input field to use the actual - value as Set Point. The slider shows the Set Point as well as the current value. + Set Point is the desired value of the control signal. It can be set by editing the number + or using the slider bar. Click the "Set" button above the input field to use the actual + value as Set Point. The slider shows the Set Point as well as the current value. - Lifts the tip by the specified amount when then controller is switched off. This can be - a positive or a negative number, i.e. the tip can also be moved towards the sample. Be - careful with sign and value when using this feature. + Lifts the tip by the specified amount when then controller is switched off. This can be + a positive or a negative number, i.e. the tip can also be moved towards the sample. Be + careful with sign and value when using this feature. - Use this parameter for a reproducible position when switching off the Z-controller. - When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues - to run for the specified time and averages the Z position. + Use this parameter for a reproducible position when switching off the Z-controller. + When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues + to run for the specified time and averages the Z position. - (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during - the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters - are disabled. + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during + the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. - The final z-position during the bias spectroscopy scan. The availability of values is - related to the mode of scanning. + The final z-position during the bias spectroscopy scan. The availability of values is + related to the mode of scanning. +doc: | +To control the tip and various scan operations.--> - Configure the scan frame like x position; y position; width; height. + Configure the scan frame like x position; y position; width; height. - Scan resolution by setting the Lines equal to Pixels. + Scan resolution by setting the Lines equal to Pixels. - Define the image resolution. + Define the image resolution. - Define the scan forward speed in the forward direction. + Define the scan forward speed in the forward direction. - Define the scan backward speed in the forward direction. + Define the scan backward speed in the forward direction. - Piezo calibration module is used to define the X Y Z piezos calibration. + Piezo calibration module is used to define the X Y Z piezos calibration. - The name of calibration type. + The name of calibration type. - + +doc: The unit of setpoint during the scanning.--> - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` - (proportional gain/time constant). The formula for the controller in the frequency domain is: - :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. - The integral gain and time constant are related as follows: :math:`I = P/T`. + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` + (proportional gain/time constant). The formula for the controller in the frequency domain is: + :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. + The integral gain and time constant are related as follows: :math:`I = P/T`. - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - P/T (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: `:math:I = P/T`. + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: `:math:I = P/T`. - The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and - :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency - domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related - as follows: :math:`I = P/T`. + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: :math:`I = P/T`. +doc: | +(In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) +during the sweep. It is selected by default. When deselected, Z-offset and Z control time +parameters are disabled.--> - There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order - piezo characteristics to compensate for it. The following equation shows the interpretation - of the 2nd order correction parameter: For the X-piezo: - :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` - where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order + piezo characteristics to compensate for it. The following equation shows the interpretation + of the 2nd order correction parameter: For the X-piezo: + :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` + where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` - There are 2 parameters in X and Y directions. Define the drift speed for all three axes. - When the compensation is on, the piezos will start to move at that speed. + There are 2 parameters in X and Y directions. Define the drift speed for all three axes. + When the compensation is on, the piezos will start to move at that speed. - Use the button to turn on/off the drift compensation. + Use the button to turn on/off the drift compensation. diff --git a/contributed_definitions/NXprocess_mpes.nxdl.xml b/contributed_definitions/NXprocess_mpes.nxdl.xml index d642b722d2..eedb284c22 100644 --- a/contributed_definitions/NXprocess_mpes.nxdl.xml +++ b/contributed_definitions/NXprocess_mpes.nxdl.xml @@ -75,7 +75,7 @@ - + Calibration event on a k-space axis. @@ -98,7 +98,7 @@ - + Calibration event of an angular axis. @@ -117,7 +117,7 @@ - + Calibration event of a spatial axis. diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml index eca1eba2bd..328560157a 100644 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ b/contributed_definitions/NXpulser_apm.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. @@ -37,8 +37,7 @@ Base class for a laser- and/or voltage-pulsing device used in atom probe microscopy. - - + Detail whereby ion extraction is triggered methodologically. diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml index ec12aa8eb5..c291c1d2f5 100644 --- a/contributed_definitions/NXpump.nxdl.xml +++ b/contributed_definitions/NXpump.nxdl.xml @@ -21,12 +21,11 @@ # # For further information, see http://www.nexusformat.org --> - + Device to reduce an atmosphere (real or simulated) to a controlled pressure. - - + Principle type of the pump. diff --git a/contributed_definitions/NXquadric.nxdl.xml b/contributed_definitions/NXquadric.nxdl.xml index 8f061f3af0..b7a07611c8 100644 --- a/contributed_definitions/NXquadric.nxdl.xml +++ b/contributed_definitions/NXquadric.nxdl.xml @@ -3,7 +3,7 @@ - - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -59,7 +59,6 @@ Given name/alias. - Free-text field to specify further details about the reflectron. diff --git a/contributed_definitions/NXregion.nxdl.xml b/contributed_definitions/NXregion.nxdl.xml index bffff2da59..0d15038858 100644 --- a/contributed_definitions/NXregion.nxdl.xml +++ b/contributed_definitions/NXregion.nxdl.xml @@ -3,7 +3,7 @@ - - - Describes the resolution of a physical quantity. - - - - The physical quantity of the resolution, e.g., - energy, momentum, time, etc. - - - - - The process by which the resolution was determined. - - - - - - - - - - - Additional details of the estimate or description of the calibration procedure - - - - - The resolution of the physical quantity. - - - - - Standard deviation of the resolution of the physical quantity. - - - - - Ratio of the resolution at a specified measurand value to that measurand value, - - - - - Standard deviation of the relative resolution of the physical quantity. - - - - - The response of the instrument or part to a infinitesimally sharp input signal - along the physical quantity of this group. - This is also sometimes called instrument response function for time resolution or - point spread function for spatial response. - The resolution is typically determined by taking the full width at half maximum (FWHM) - of the response function. - - - - The input axis or grid of the response function. - The unit should match the one of the resolution field. - - - - - The magnitude of the response function corresponding to the points - in the input axis or grid. - This field should have the same dimensions as `input`. - - - - - - A symbol linking to another path in this appdef to be referred to from the - `resolution_formula` field. This should be a valid path inside this application - definition, i.e., of the form /entry/instrument/my_part/my_field. - - - - - A resolution formula to determine the resolution from a set of symbols as - entered by the `formula_...` fields. - The output unit should match the provided unit of this field. - - - - - .. 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. - - - - - For storing details and data of a calibration to derive a resolution from data. - - - diff --git a/contributed_definitions/NXscan_control.nxdl.xml b/contributed_definitions/NXscan_control.nxdl.xml index e989edd25a..5e26ed80de 100644 --- a/contributed_definitions/NXscan_control.nxdl.xml +++ b/contributed_definitions/NXscan_control.nxdl.xml @@ -24,54 +24,54 @@ - A scan is performed inside an N-dimensional phase space, where each dimension can correspond not only to real space coordinates (x,y) but also to any other parameter. This class contains detailed information about controlling the scan in such a phase space (or its subspace). - - scan_types: - Trajectory: A list of N-dimensional sequential vectors describes the trajectory line for a full scan. - Mesh: For each dimension a range and a direction are chosen. When a scan along a dimension is done, a single step in the next dimension is taken, and then the scan in the previous dimension is repeated. As such we can speak about the fastest and the slowest scan axes. - Snake: Similar to a mesh scan but with the scanning direction reversed after each line. - Spiral: A scan taken along a spiral trajectory. - Tilt: At each step, a proportional movement is done in all dimensions. - Linear: A scan where the scanning will be performed along a single independent axis. - - Scan_control_types: - Stepping: At each step, a movement to the next point is performed; correction (for example backlash) or active regulation (feedback loop) may or may not be applied. After the movement is done, the measurement is performed without the movement. - Continuous: The scanning of each line in an N-dimensional phase space is done without stopping; measurements are done simultaneously with the movement. - Oscillating: Scanning over a scan point continuously and then moving to start scanning at the next position. + A scan is performed inside an N-dimensional phase space, where each dimension can correspond not only to real space coordinates (x,y) but also to any other parameter. This class contains detailed information about controlling the scan in such a phase space (or its subspace). + + scan_types: + Trajectory: A list of N-dimensional sequential vectors describes the trajectory line for a full scan. + Mesh: For each dimension a range and a direction are chosen. When a scan along a dimension is done, a single step in the next dimension is taken, and then the scan in the previous dimension is repeated. As such we can speak about the fastest and the slowest scan axes. + Snake: Similar to a mesh scan but with the scanning direction reversed after each line. + Spiral: A scan taken along a spiral trajectory. + Tilt: At each step, a proportional movement is done in all dimensions. + Linear: A scan where the scanning will be performed along a single independent axis. + + Scan_control_types: + Stepping: At each step, a movement to the next point is performed; correction (for example backlash) or active regulation (feedback loop) may or may not be applied. After the movement is done, the measurement is performed without the movement. + Continuous: The scanning of each line in an N-dimensional phase space is done without stopping; measurements are done simultaneously with the movement. + Oscillating: Scanning over a scan point continuously and then moving to start scanning at the next position. - The start time of the scan. + The start time of the scan. - The end time of the scan. + The end time of the scan. - A list of scan axes which are controlled independently of each other. - (e.g. X, Y, Z, or other physical dimensions) - - The list is in the order of axes of the scan from the fastest to the slowest. + A list of scan axes which are controlled independently of each other. + (e.g. X, Y, Z, or other physical dimensions) + + The list is in the order of axes of the scan from the fastest to the slowest. - + - Define the scan resolution along each dimension as the number of steps per unit of the dimension parameters. - - Rename the field according to the name of the independent dimension (e.g. scan_resolution_x, scan_resolution_voltage). + Define the scan resolution along each dimension as the number of steps per unit of the dimension parameters. + + Rename the field according to the name of the independent dimension (e.g. scan_resolution_x, scan_resolution_voltage). - + - Define the accuracy of the scan probe. + Define the accuracy of the scan probe. - This group specifies how the trajectory of the scan is defined. + This group specifies how the trajectory of the scan is defined. @@ -82,7 +82,7 @@ - This strig describes how the scan was performed. + This strig describes how the scan was performed. @@ -92,162 +92,162 @@ - The scan region is the area of phase space or sub-phase space where the scan is - performed. The region could be N-dimensional and is defined by the minimum and - maximum values of the scan axes. + The scan region is the area of phase space or sub-phase space where the scan is + performed. The region could be N-dimensional and is defined by the minimum and + maximum values of the scan axes. - + - The offset of center of the scan region from the origin along the specific scan axis. - - 'N' denotes the name of the specific scan axis. (Offset, start and end positions are related) + The offset of center of the scan region from the origin along the specific scan axis. + + 'N' denotes the name of the specific scan axis. (Offset, start and end positions are related) - + - The range of the scan is the length of the scan region along the dimension 'N'. + The range of the scan is the length of the scan region along the dimension 'N'. - + - The orientation of the scan region or subspace. Usually, the scan_offset and scan_range are enough - to define the scan region. This field defines how the spatial space is oriented with respect to - the frame of reference. - - Rename the field describing the angle with an axis of the spatial space (e.g. scan_angle_x). + The orientation of the scan region or subspace. Usually, the scan_offset and scan_range are enough + to define the scan region. This field defines how the spatial space is oriented with respect to + the frame of reference. + + Rename the field describing the angle with an axis of the spatial space (e.g. scan_angle_x). - + - The start of the scan is the starting point of the scan region (phase space or sub-phase space) - for each independent scan axis. - - For N-dimensional, it is a list of N numbers. + The start of the scan is the starting point of the scan region (phase space or sub-phase space) + for each independent scan axis. + + For N-dimensional, it is a list of N numbers. - + - The end of the scan is the ending point of the scan region (phase space or sub-phase space) - for each independent scan axis. - - Note: The scan_offset and scan_range are equivalent to the scan_start and scan_end. - - For N-dimensional, it is a list of N numbers. + The end of the scan is the ending point of the scan region (phase space or sub-phase space) + for each independent scan axis. + + Note: The scan_offset and scan_range are equivalent to the scan_start and scan_end. + + For N-dimensional, it is a list of N numbers. - + - For each dimension a range and a direction are chosen. When a scan along a dimension is done, - a single step in the next dimension is taken, and then the scan in the previous dimension is - repeated. As such we can speak about the fastest and the slowest scan axes. + For each dimension a range and a direction are chosen. When a scan along a dimension is done, + a single step in the next dimension is taken, and then the scan in the previous dimension is + repeated. As such we can speak about the fastest and the slowest scan axes. - + - Define the scan speed in the forward direction along the axis if forward and backward - speeds below are not specified. - - If the scan goes in the negative direction, the speed should be negative. - - Rename the field, according to the name of the dimension (e.g. scan_speed_x, scan_speed_voltage). + Define the scan speed in the forward direction along the axis if forward and backward + speeds below are not specified. + + If the scan goes in the negative direction, the speed should be negative. + + Rename the field, according to the name of the dimension (e.g. scan_speed_x, scan_speed_voltage). - + - Define the scan speed in the forward directions. - Rename the field, according to the name of the dimension. + Define the scan speed in the forward directions. + Rename the field, according to the name of the dimension. - + - Define the scan speed in the backward directions. - Rename the field, according to the name of the dimension. + Define the scan speed in the backward directions. + Rename the field, according to the name of the dimension. - + - Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is - to represent the name of the dimensions. - - Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). + Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is + to represent the name of the dimensions. + + Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). - + - Define the total number of points in the given axis scan to be performed. - - Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). + Define the total number of points in the given axis scan to be performed. + + Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). - + - The number of steps the probe jumps over the scan steps or points. This describes when not - every point from the scan_points is measured along an axis. - - Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). + The number of steps the probe jumps over the scan steps or points. This describes when not + every point from the scan_points is measured along an axis. + + Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). - If the scan probe jumps over a number of scan steps or points (more than one) - to perform each scan. By default, it is False. + If the scan probe jumps over a number of scan steps or points (more than one) + to perform each scan. By default, it is False. - + - The length of each step in the scan on each dimension. - - Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). + The length of each step in the scan on each dimension. + + Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). - + - If the scan probe moves continuously over the scan points or steps, use True. The default value is True. - Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves - in steps. - - Rename the field, according to the name of the dimension (e.g. continuous_voltage). + If the scan probe moves continuously over the scan points or steps, use True. The default value is True. + Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves + in steps. + + Rename the field, according to the name of the dimension (e.g. continuous_voltage). - + - If the scan probe oscillates over the scan point, use True. - The default value is False. + If the scan probe oscillates over the scan point, use True. + The default value is False. - The number of oscillations on each scanning point per second. + The number of oscillations on each scanning point per second. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, please - duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, please + duplicate this NXdata group for each. - + - To define the spiral or circular scan, use this group. + To define the spiral or circular scan, use this group. - + - Define the scan speed in forward (clockwise) directions. - - If the scan goes in the negative (anti-clockwise) direction, the speed should be negative. - - Rename the field, according to the circle index. The circle near the center starts with 0. - In case, the speed is the same for all the circles, replace 'N' by 'all'. + Define the scan speed in forward (clockwise) directions. + + If the scan goes in the negative (anti-clockwise) direction, the speed should be negative. + + Rename the field, according to the circle index. The circle near the center starts with 0. + In case, the speed is the same for all the circles, replace 'N' by 'all'. - Define the direction of the spiral scan. (e.g. clockwise, anticlockwise from looking back - along the surface normal) + Define the direction of the spiral scan. (e.g. clockwise, anticlockwise from looking back + along the surface normal) @@ -255,356 +255,356 @@ - + - Define the scan speed in the forward (clockwise) directions. - Rename the field, according to the circle index. The circle near the center starts with 0. - - In case, the speed is the same for all the circles, replace 'N' by 'all'. + Define the scan speed in the forward (clockwise) directions. + Rename the field, according to the circle index. The circle near the center starts with 0. + + In case, the speed is the same for all the circles, replace 'N' by 'all'. - + - Define the scan speed in the backward (anti-clockwise) directions. - Rename the field, according to the circle index. The circle near the center starts with 0. - - In case, the speed is the same for all the circles, replace 'N' by 'all'. + Define the scan speed in the backward (anti-clockwise) directions. + Rename the field, according to the circle index. The circle near the center starts with 0. + + In case, the speed is the same for all the circles, replace 'N' by 'all'. - + - Define the radius of the spiral circle of scanning. - - Rename the field, according to the circle order, the nearest circle to the center is 0. + Define the radius of the spiral circle of scanning. + + Rename the field, according to the circle order, the nearest circle to the center is 0. - + - Define the total number of points in a given circle scan to be performed. - - Rename the field, according to the circle order, the nearest circle to the center - is 0 (e.g. scan_points_2). + Define the total number of points in a given circle scan to be performed. + + Rename the field, according to the circle order, the nearest circle to the center + is 0 (e.g. scan_points_2). - + - If the scan probe steps over a number of scan points. - - Rename the field, according to the circle index. The circle near the center starts with 0. - In case, the stepping is the same for all the circles, replace 'N' by 'all'. + If the scan probe steps over a number of scan points. + + Rename the field, according to the circle index. The circle near the center starts with 0. + In case, the stepping is the same for all the circles, replace 'N' by 'all'. - If the scan probe jumps over a number of scan steps or points (more than one), use True. - The default value is False. + If the scan probe jumps over a number of scan steps or points (more than one), use True. + The default value is False. - + - Define the number of points that the scan probe steps over. - - Rename the field, according to the circle index. The circle near the center or lowest value of a - parameter starts with 0. - In case, the step size is the same for all the circles, replace 'N' by 'all'. + Define the number of points that the scan probe steps over. + + Rename the field, according to the circle index. The circle near the center or lowest value of a + parameter starts with 0. + In case, the step size is the same for all the circles, replace 'N' by 'all'. - + - If the scan probe moves continuously over the scan points, use True. The default value is True. - A scan process can run continuously in the spatial dimension but can be discretized in time or - other physical dimensions (e.g. voltage). - - Rename this field according to the dimensions, considering continuous scan in a two-dimensional space - rename the field as continuous_x_y. + If the scan probe moves continuously over the scan points, use True. The default value is True. + A scan process can run continuously in the spatial dimension but can be discretized in time or + other physical dimensions (e.g. voltage). + + Rename this field according to the dimensions, considering continuous scan in a two-dimensional space + rename the field as continuous_x_y. - + - If the scan probe oscillates over the scan point, use True. The default value is - False. + If the scan probe oscillates over the scan point, use True. The default value is + False. - Number of oscillation on each scanning point per second. + Number of oscillation on each scanning point per second. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, please - duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, please + duplicate this NXdata group for each. - + - To define the snake scan, use this group. + To define the snake scan, use this group. - + - Define the scan speed for the type of snake scan. For the same speed along the - positive and negative directions, use a single number - - Rename the field, according to the name of the fast and slow axis e.g. scan_speed_x. + Define the scan speed for the type of snake scan. For the same speed along the + positive and negative directions, use a single number + + Rename the field, according to the name of the fast and slow axis e.g. scan_speed_x. - The field defines the scan speed in the positive direction on the fast axis. - - Rename the field, according to the name of the fast axis. + The field defines the scan speed in the positive direction on the fast axis. + + Rename the field, according to the name of the fast axis. - The field defines the scan speed in the negative direction on the fast axis. - - Rename the field, according to the name of the fast axis. + The field defines the scan speed in the negative direction on the fast axis. + + Rename the field, according to the name of the fast axis. - + - Define the total number of points in the given axis scan to be performed. - - Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). + Define the total number of points in the given axis scan to be performed. + + Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). - + - The number of steps the probe jumps over the scan steps or points. - - Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). + The number of steps the probe jumps over the scan steps or points. + + Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). - If the scan probe jumps over a number of scan steps or points (more than one) - to perform each scan. By default, it is False. - - Rename the field, according to the name of the dimension. + If the scan probe jumps over a number of scan steps or points (more than one) + to perform each scan. By default, it is False. + + Rename the field, according to the name of the dimension. - + - The length of each step in the scan on each dimension. - - Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). + The length of each step in the scan on each dimension. + + Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). - + - Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is - to represent the name of the dimensions. - - Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). + Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is + to represent the name of the dimensions. + + Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). - + - If the scan probe moves continuously over the scan points or steps, use True. The default value is True. - Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves - in a stepping manner. - - Rename the field, according to the name of the dimension (e.g. continuous_voltage). + If the scan probe moves continuously over the scan points or steps, use True. The default value is True. + Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves + in a stepping manner. + + Rename the field, according to the name of the dimension (e.g. continuous_voltage). - + - If the scan probe oscillates over the scan point, use True. - The default value is False. + If the scan probe oscillates over the scan point, use True. + The default value is False. - The number of oscillations on each scanning point per second. + The number of oscillations on each scanning point per second. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, please - duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, please + duplicate this NXdata group for each. - + - To define the trajectory scan, use this group. + To define the trajectory scan, use this group. - Define the scan speed through the trajectory points. + Define the scan speed through the trajectory points. - The field defines the scan speed in the forward directions through the - trajectory points. + The field defines the scan speed in the forward directions through the + trajectory points. - The field defines the scan speed in the backward directions (backtracking) - through the trajectory points. + The field defines the scan speed in the backward directions (backtracking) + through the trajectory points. - + - Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is - to represent the name of the dimensions. - - Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). + Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is + to represent the name of the dimensions. + + Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). - The number of trajectory points in the entire scan. + The number of trajectory points in the entire scan. - The trajectory points are the N-dimensional vectors describing all the scan points sequentially. - - The second rank dataset should contain total number of trajectory points (nTraj) and - a full coordinate (nD) of each trajectory point. + The trajectory points are the N-dimensional vectors describing all the scan points sequentially. + + The second rank dataset should contain total number of trajectory points (nTraj) and + a full coordinate (nD) of each trajectory point. - + - Define the total number of scan points between two trajectory points. - - Rename the field, according to the index of the second trajectory points. - For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. + Define the total number of scan points between two trajectory points. + + Rename the field, according to the index of the second trajectory points. + For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. - + - The number of steps the probe jumps over the scan steps or points along the trajectory line from between two trajectory points. - - Rename the field, according to the index of the second trajectory points. - For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. + The number of steps the probe jumps over the scan steps or points along the trajectory line from between two trajectory points. + + Rename the field, according to the index of the second trajectory points. + For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. - If the scan probe jumps over a number of scan steps or points (more than one) - to perform each scan. By default, it is False. + If the scan probe jumps over a number of scan steps or points (more than one) + to perform each scan. By default, it is False. - The length of each step along the entire trajectory line. + The length of each step along the entire trajectory line. - If the scan probe moves continuously over the scan points or steps between two - trajectory points, use True. The default value is True. + If the scan probe moves continuously over the scan points or steps between two + trajectory points, use True. The default value is True. - + - If the scan probe oscillates over the scan point, use True. - The default value is False. + If the scan probe oscillates over the scan point, use True. + The default value is False. - The number of oscillations on each scanning point per second. + The number of oscillations on each scanning point per second. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, please - duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, please + duplicate this NXdata group for each. - + - Define the scan mode that is performed for a single independent data axis. + Define the scan mode that is performed for a single independent data axis. - Define the scan speed of the scan disregarding the forward or backward - direction. + Define the scan speed of the scan disregarding the forward or backward + direction. - Define the scan speed in the forward directions. + Define the scan speed in the forward directions. - Define the scan speed in the backward directions. + Define the scan speed in the backward directions. - + - Name of the channel that records the scan data for the given dimension. + Name of the channel that records the scan data for the given dimension. - + - Define the total number of points in the given axis scan to be performed. - - Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). + Define the total number of points in the given axis scan to be performed. + + Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). - + - The number of steps the probe jumps over the scan steps or points. - - Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). + The number of steps the probe jumps over the scan steps or points. + + Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). - If the scan probe jumps over a number of scan steps or points (more than one) - to perform each scan. By default, it is False. + If the scan probe jumps over a number of scan steps or points (more than one) + to perform each scan. By default, it is False. - + - The length of each step in the scan on each dimension. - - Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). + The length of each step in the scan on each dimension. + + Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). - + - If the scan probe moves continuously over the scan points or steps, use True. The default value is True. - Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves - in a stepping manner. - - Rename the field, according to the name of the dimension (e.g. continuous_voltage). + If the scan probe moves continuously over the scan points or steps, use True. The default value is True. + Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves + in a stepping manner. + + Rename the field, according to the name of the dimension (e.g. continuous_voltage). - + - If the scan probe oscillates over the scan point, use True. - The default value is False. + If the scan probe oscillates over the scan point, use True. + The default value is False. - The number of oscillations on each scanning point per second. + The number of oscillations on each scanning point per second. - + - The scan data is the data collected during the scan. - If the scan has several channels or derivatives from the channel data, please - duplicate this NXdata group for each. + The scan data is the data collected during the scan. + If the scan has several channels or derivatives from the channel data, please + duplicate this NXdata group for each. diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml index 904612e6bd..668af68220 100644 --- a/contributed_definitions/NXscanbox_em.nxdl.xml +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Scan box and coils which deflect a beam of charged particles in a controlled manner. diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 418b287a28..fb717cc819 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -24,32 +24,32 @@ - Variables used to set a common size for collected sensor data. + Variables used to set a common size for collected sensor data. - The number of scan points measured in this scan. + The number of scan points measured in this scan. - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. - .. 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 visualised upon entry. - 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 visualised upon entry. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. @@ -58,122 +58,122 @@ - + - The unique identifier for the entry. The identifier is mainly lab-defined and - can be a combination of the sample name, date and time, experiment condition - (such as temperature) or instrument-generated unique identifier. + The unique identifier for the entry. The identifier is mainly lab-defined and + can be a combination of the sample name, date and time, experiment condition + (such as temperature) or instrument-generated unique identifier. - - + + - The unique identifier for the collection. The identifier is used to group a - number of the experiments run upon the same setup and/or same sample. + The unique identifier for the collection. The identifier is used to group a + number of the experiments run upon the same setup and/or same sample. - + - - + + - Define the program that was used to generate the results file(s) - with measured data and metadata. + Define the program that was used to generate the results file(s) + with measured data and metadata. - Commercial or otherwise defined given name of the program - (or a link to the instrument software). + Commercial or otherwise defined given name of the program + (or a link to the instrument software). - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. - Website of the software. + Website of the software. - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. - Name of the user. + Name of the user. - Name of the affiliation of the user at the point in time when - the experiment was performed. + Name of the affiliation of the user at the point in time when + the experiment was performed. - Full address (street, street number, ZIP, city, country) - of the user's affiliation. + Full address (street, street number, ZIP, city, country) + of the user's affiliation. - Email address of the user. + Email address of the user. - Author ID defined by https://orcid.org/. + Author ID defined by https://orcid.org/. - Official telephone number of the user. + Official telephone number of the user. - Any additional information or notes (e.g. purpose of the experiment) that might - be useful to understand the experiment. + Any additional information or notes (e.g. purpose of the experiment) that might + be useful to understand the experiment. - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each - measurement sensor. - - For example, in a temperature-dependent IV measurement, the temperature and voltage must be - present as independently scanned controllers and the current sensor must also be present with - its readings. + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each + measurement sensor. + + For example, in a temperature-dependent IV measurement, the temperature and voltage must be + present as independently scanned controllers and the current sensor must also be present with + its readings. - Plot of measured signal as a function of the timestamp of when they have been - acquired is also possible. + Plot of measured signal as a function of the timestamp of when they have been + acquired is also possible. - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. @@ -181,37 +181,37 @@ - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. - + - A list of names of NXsensor groups used as independently scanned controllers. + A list of names of NXsensor groups used as independently scanned controllers. - A list of names of NXsensor groups used as measurement sensors. + A list of names of NXsensor groups used as measurement sensors. @@ -222,8 +222,8 @@ - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index be3e7ce26f..ff96465cb1 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -3,7 +3,7 @@ - define position of beamline element relative to production target - + current set on magnet supply. - + current read from magnet supply. - + voltage read from magnet supply. - + current set on HT supply. - + current read from HT supply. - + voltage read from HT supply. diff --git a/contributed_definitions/NXserialized.nxdl.xml b/contributed_definitions/NXserialized.nxdl.xml deleted file mode 100644 index 04be319906..0000000000 --- a/contributed_definitions/NXserialized.nxdl.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - - - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. - - - - Answers into what resource the information was serialized. - - - - - - - - - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - - - - - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - - - - - Name of the algorithm whereby the checksum was computed. - - - - - - Extracted file containing the serialized information. - - - diff --git a/contributed_definitions/NXsolenoid_magnet.nxdl.xml b/contributed_definitions/NXsolenoid_magnet.nxdl.xml index 457d5225b2..96539142f9 100644 --- a/contributed_definitions/NXsolenoid_magnet.nxdl.xml +++ b/contributed_definitions/NXsolenoid_magnet.nxdl.xml @@ -3,7 +3,7 @@ - Details how spectra were processed from the detector readings. - + Resolvable data artifact (e.g. filename) from which all values in the :ref:`NXdata` instances in this :ref:`NXspectrum_set` were loaded during parsing. diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index a86744af3f..ebc303c316 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -3,7 +3,7 @@ - define position of beamline element relative to production target - + current set on magnet supply. - + current read from magnet supply. - + voltage read from magnet supply. - + current set on HT supply. - + current read from HT supply. - + voltage read from HT supply. diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/contributed_definitions/NXspindispersion.nxdl.xml index 90e03c9bc1..37b1b297b4 100644 --- a/contributed_definitions/NXspindispersion.nxdl.xml +++ b/contributed_definitions/NXspindispersion.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. @@ -66,24 +66,6 @@ Date of last preparation of the spin target - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - - Deflectors in the spin dispersive section diff --git a/contributed_definitions/NXspm.nxdl.xml b/contributed_definitions/NXspm.nxdl.xml index e1aa357e0c..dc50692e26 100644 --- a/contributed_definitions/NXspm.nxdl.xml +++ b/contributed_definitions/NXspm.nxdl.xml @@ -23,16 +23,16 @@ --> - Scanning Probe Microscopy (SPM) is a branch of microscopy that utilizes a physical probe to scan the surface of - sample and image it at the atomic level. - - The application class NXspm is designed as a skeleton and contains common technical concepts - for specific SPM sub-techniques such as STM, STS, AFM etc. + Scanning Probe Microscopy (SPM) is a branch of microscopy that utilizes a physical probe to scan the surface of + sample and image it at the atomic level. + + The application class NXspm is designed as a skeleton and contains common technical concepts + for specific SPM sub-techniques such as STM, STS, AFM etc. - Name of the definition that is used for the application. + Name of the definition that is used for the application. @@ -40,7 +40,7 @@ - The technique of the experiment like STM, STS, AFM, etc. + The technique of the experiment like STM, STS, AFM, etc. @@ -50,362 +50,362 @@ - The mode of the scan. The possible options depend on the type of experiment. - For example, in STM, the scan mode could be constant height or constant current, - in AFM, the scan mode could be contact mode, tapping mode or non-contact mode. + The mode of the scan. The possible options depend on the type of experiment. + For example, in STM, the scan mode could be constant height or constant current, + in AFM, the scan mode could be contact mode, tapping mode or non-contact mode. - The type of the scan. It mainly describes how scan probe moves in the scan region, e.g. - forward, backward, or both (if scan is repeated). + The type of the scan. It mainly describes how scan probe moves in the scan region, e.g. + forward, backward, or both (if scan is repeated). - + - The identifiers for the experiment which should be unique at least in lab. + The identifiers for the experiment which should be unique at least in lab. - + - The description of the experiment like comments, ontes from from the experiment. + The description of the experiment like comments, ontes from from the experiment. - The instrument information. + The instrument information. - The hardware description of the core instrument setup of the experiment. - Usually, the entire instrument is supplied by a single manufacturer. - To describe the hardware from any sub-components, use the hardware group of that - sub-component (child group of the NXinstrument group) group. + The hardware description of the core instrument setup of the experiment. + Usually, the entire instrument is supplied by a single manufacturer. + To describe the hardware from any sub-components, use the hardware group of that + sub-component (child group of the NXinstrument group) group. - Company name of the manufacturer. + Company name of the manufacturer. - Version or model of the hardware setup provided by the manufacturer. + Version or model of the hardware setup provided by the manufacturer. - If different versions are possible, the value in this field should be made - specific enough to resolve the version. + If different versions are possible, the value in this field should be made + specific enough to resolve the version. - The software description of the core instrument setup of the experiment. - Usually, the entire instrument is supplied by a single name/manufacturer/model/etc. - To describe the software from any sub-components, use the software group of that component. + The software description of the core instrument setup of the experiment. + Usually, the entire instrument is supplied by a single name/manufacturer/model/etc. + To describe the software from any sub-components, use the software group of that component. - Company name of the manufacturer. + Company name of the manufacturer. - Version or model of the component named by the manufacturer. + Version or model of the component named by the manufacturer. - If different versions are possible, the value in this field should be made - specific enough to resolve the version. + If different versions are possible, the value in this field should be made + specific enough to resolve the version. - The real-time controller information. + The real-time controller information. - The frequency of the real-time controller system which indicated the number of close-loop process - (gathering data, process data and update system) control cycles per second. + The frequency of the real-time controller system which indicated the number of close-loop process + (gathering data, process data and update system) control cycles per second. - The lock-in amplifier information. + The lock-in amplifier information. - Information of the scan environment. + Information of the scan environment. - Temperature of STM head. Note: At least one field from tip_temp, - cryo_bottom_temp and cryo_shield_temp must be provided. + Temperature of STM head. Note: At least one field from tip_temp, + cryo_bottom_temp and cryo_shield_temp must be provided. - Temperature of the cold tail of the cryostat. Note: At least one field from - tip_temp, cryo_bottom_temp and cryo_shield_temp must be provided. + Temperature of the cold tail of the cryostat. Note: At least one field from + tip_temp, cryo_bottom_temp and cryo_shield_temp must be provided. - Temperature of liquid nitrogen shield. Note: At - least one field from tip_temp, cryo_bottom_temp and cryo_shield_temp. + Temperature of liquid nitrogen shield. Note: At + least one field from tip_temp, cryo_bottom_temp and cryo_shield_temp. - The name of the scan, mainly lab defined, that helps to differentiate among different - scans performed in the lab. + The name of the scan, mainly lab defined, that helps to differentiate among different + scans performed in the lab. - This is a link to the current_sensor under the instrument group: - entry/experiment_instrument/current_sensor. + This is a link to the current_sensor under the instrument group: + entry/experiment_instrument/current_sensor. - + - This is a link to the voltage_sensor under the instrument group: - entry/experiment_instrument/voltage_sensor. + This is a link to the voltage_sensor under the instrument group: + entry/experiment_instrument/voltage_sensor. - This is a link to the piezo_sensor under the instrument group: - entry/experiment_instrument/piezo_sensor. + This is a link to the piezo_sensor under the instrument group: + entry/experiment_instrument/piezo_sensor. - The scan control information like scan region or phase space, type of scan (e.g. - mesh, spiral, etc.), and scan speed, etc. This group mainly stores the raw scan - data. For processed data or final experimental data would go to NXdata group. + The scan control information like scan region or phase space, type of scan (e.g. + mesh, spiral, etc.), and scan speed, etc. This group mainly stores the raw scan + data. For processed data or final experimental data would go to NXdata group. - The name of the scan, mainly lab defined, that helps to differentiate among different - scans performed in lab. This field is intended for several types of scan control - run under the same environment. + The name of the scan, mainly lab defined, that helps to differentiate among different + scans performed in lab. This field is intended for several types of scan control + run under the same environment. - Information for current sensor. + Information for current sensor. - An amplifier information for the input signal (e.g. from tip). + An amplifier information for the input signal (e.g. from tip). - The sensor information for the voltage device. + The sensor information for the voltage device. - The piezo sensor refers to the height (or Z) piezo sensor if nothing is - mentioned along the X and Y directions. + The piezo sensor refers to the height (or Z) piezo sensor if nothing is + mentioned along the X and Y directions. - The x position of the piezo. In STS experiment, the piezo stays fixed at - x,y and z and the the tunneling current is measured with respect to the - bias voltage (sweep voltage). + The x position of the piezo. In STS experiment, the piezo stays fixed at + x,y and z and the the tunneling current is measured with respect to the + bias voltage (sweep voltage). - The y position of the piezo. + The y position of the piezo. - The z position of the piezo. + The z position of the piezo. - The piezo configuration information like piezoelectric calibration and material - properties. + The piezo configuration information like piezoelectric calibration and material + properties. - Calibration of the piezo device. + Calibration of the piezo device. - The positioner information like the position of the tip, the position of the - sample, PID loop feedback etc. + The positioner information like the position of the tip, the position of the + sample, PID loop feedback etc. - + - The PID controller information for the z-axis. + The PID controller information for the z-axis. - To indicate the relative tip position z between tip and sample. The tip position - can also be varied when the z_controller is not running. + To indicate the relative tip position z between tip and sample. The tip position + can also be varied when the z_controller is not running. - Status if controller is active. + Status if controller is active. - The material description and properties of the piezoelectric scanner materials. + The material description and properties of the piezoelectric scanner materials. - + - A group handling the temperature such as cryo, shield and tip. For different - type of temperature sensors repeat this group. + A group handling the temperature such as cryo, shield and tip. For different + type of temperature sensors repeat this group. - The temperature of the sample. + The temperature of the sample. - + - The name of the channel to measure the temperature. + The name of the channel to measure the temperature. - Calibration of the temperature measurement. + Calibration of the temperature measurement. - The coefficients of the calibration. + The coefficients of the calibration. - + - Data (e.g, record from SPM head temperature) from temperature sensor. + Data (e.g, record from SPM head temperature) from temperature sensor. - To explain bias (sweep measurement) voltage applied to the sample. + To explain bias (sweep measurement) voltage applied to the sample. - Setup and scan data for continuous measurement of bias-voltage on the subject of experiment - vs tunneling current from probe. + Setup and scan data for continuous measurement of bias-voltage on the subject of experiment + vs tunneling current from probe. - The positioner information like the position of the tip, PID loop feedback etc. + The positioner information like the position of the tip, PID loop feedback etc. - + - The PID controller information for the z-axis. + The PID controller information for the z-axis. - The average time taken by the z-controller to stabilize the tip. + The average time taken by the z-controller to stabilize the tip. - The time taken by the z-controller to measure physical properties. + The time taken by the z-controller to measure physical properties. - The status of the controller to be held on the previous position, before going to the - next scan point or line to measure the physical properties. + The status of the controller to be held on the previous position, before going to the + next scan point or line to measure the physical properties. - The status of the controller to record the final z position after the scan. + The status of the controller to record the final z position after the scan. - The bais voltage sweep is a common technique used on the substance or sample or environment - to study the change in the behavior of the sample or substance or environment due to change - in applied bias voltage. + The bais voltage sweep is a common technique used on the substance or sample or environment + to study the change in the behavior of the sample or substance or environment due to change + in applied bias voltage. - The time is taken to settle the bias voltage at the desired value. On each sweep usually, the system - takes time to settle the bias voltage at the next value. + The time is taken to settle the bias voltage at the desired value. On each sweep usually, the system + takes time to settle the bias voltage at the next value. - The scan region (phase space or sub-phase space) is the region where the scan is - performed. + The scan region (phase space or sub-phase space) is the region where the scan is + performed. - The offset of the bias voltage for bias sweep. + The offset of the bias voltage for bias sweep. - The range of the scan is the length of the bias voltage over which the sweep - scan will be performed. + The range of the scan is the length of the bias voltage over which the sweep + scan will be performed. - The start of the bias scan voltage. + The start of the bias scan voltage. - The end of the bias scan voltage. + The end of the bias scan voltage. - The linear sweep is a type of scan where the bias voltage is swept - linearly from the starting voltage to the ending voltage. + The linear sweep is a type of scan where the bias voltage is swept + linearly from the starting voltage to the ending voltage. - The number of voltage points the sweep scan to be performed. + The number of voltage points the sweep scan to be performed. - The step size of the sweep. - The step size is the difference between the two consecutive bias voltage during the sweep. + The step size of the sweep. + The step size is the difference between the two consecutive bias voltage during the sweep. - The reset_bias is used to reset the bias voltage to the starting value after a - sweep is completed. + The reset_bias is used to reset the bias voltage to the starting value after a + sweep is completed. @@ -414,25 +414,25 @@ - The DC bias voltage that is applied to the sample. + The DC bias voltage that is applied to the sample. - The bias voltage (DC) applied to the sample. + The bias voltage (DC) applied to the sample. - Offset value of the bias voltage. + Offset value of the bias voltage. - Calibration of the bias voltage measurement (V/V). + Calibration of the bias voltage measurement (V/V). - The coefficients of the calibration. + The coefficients of the calibration. @@ -440,34 +440,34 @@ - The sample information. + The sample information. - A set of physical processes that occurred to the sample prior/during experiment. + A set of physical processes that occurred to the sample prior/during experiment. - Information of environment around the sample. + Information of environment around the sample. - Link to the sample_bias_voltage sensor under the instrument. + Link to the sample_bias_voltage sensor under the instrument. - The group of indicators (links to the existing fields in different groups) that measure - the reproducibility of the experiment. + The group of indicators (links to the existing fields in different groups) that measure + the reproducibility of the experiment. - The group of indicators (links to the existing fields in different groups) that - are used to measure the resolution of the experiment results. + The group of indicators (links to the existing fields in different groups) that + are used to measure the resolution of the experiment results. diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml index 337b64ff46..57b99ceed2 100644 --- a/contributed_definitions/NXstage_lab.nxdl.xml +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -21,7 +21,7 @@ # # For further information, see http://www.nexusformat.org --> - + Base class for a stage (lab) used to hold, orient, and prepare a specimen. diff --git a/contributed_definitions/NXstm.nxdl.xml b/contributed_definitions/NXstm.nxdl.xml index e0322ff437..ca552fc4a5 100644 --- a/contributed_definitions/NXstm.nxdl.xml +++ b/contributed_definitions/NXstm.nxdl.xml @@ -26,12 +26,12 @@ https://thesis.library.caltech.edu/1943/4/03chapter3.pdf TODO: Replace rename NXenvironment to experiment_environment in NXstm, NXspm and NXafm--> - An application definition to describe Scanning Tunneling Microscopy (STM). + An application definition to describe Scanning Tunneling Microscopy (STM). - Name of the definition that is used for the application. + Name of the definition that is used for the application. @@ -39,8 +39,8 @@ TODO: Replace rename NXenvironment to experiment_environment in NXstm, NXspm and - The mode of the scan that is performed. Two commonly used ones are constant - height mode and constant current mode. + The mode of the scan that is performed. Two commonly used ones are constant + height mode and constant current mode. @@ -49,39 +49,39 @@ TODO: Replace rename NXenvironment to experiment_environment in NXstm, NXspm and - The group explains the instrumentation of the STM experiment such - as current sensor, lock-in amplifier etc. + The group explains the instrumentation of the STM experiment such + as current sensor, lock-in amplifier etc. - The lock-in amplifier information. The device is being used to extract - the very weak signal buried in noisy signals. + The lock-in amplifier information. The device is being used to extract + the very weak signal buried in noisy signals. - The type of the signal (voltage or current) subject fo modulation. + The type of the signal (voltage or current) subject fo modulation. - The frequency of the sine modulation that is used to modulate the signal in - lock-in. + The frequency of the sine modulation that is used to modulate the signal in + lock-in. - The environment information for stm or sts experiment. + The environment information for stm or sts experiment. - The scan control information like scan region or phase space, type of scan - (e.g. mesh, spiral, etc.), and scan speed, etc. + The scan control information like scan region or phase space, type of scan + (e.g. mesh, spiral, etc.), and scan speed, etc. - The type of scan like mesh, spiral, etc. For STS experiment, the scan type is - usually a single-point scan (trajectory scan). + The type of scan like mesh, spiral, etc. For STS experiment, the scan type is + usually a single-point scan (trajectory scan). @@ -93,189 +93,189 @@ TODO: Replace rename NXenvironment to experiment_environment in NXstm, NXspm and - This group stands for the same concept as - /ENTRY[entry]/experiment_instrument/tip_temperature + This group stands for the same concept as + /ENTRY[entry]/experiment_instrument/tip_temperature - This group stands for the same concept as - /ENTRY[entry]/experiment_instrument/cryo_temperature + This group stands for the same concept as + /ENTRY[entry]/experiment_instrument/cryo_temperature - This group stands for the same concept as - /ENTRY[entry]/experiment_instrument/cryo_shield_temperature + This group stands for the same concept as + /ENTRY[entry]/experiment_instrument/cryo_shield_temperature - The temperature of the tip one of the tip. + The temperature of the tip one of the tip. - The temperature of the cryostat. + The temperature of the cryostat. - The temperature of the cryo shield. + The temperature of the cryo shield. - The sensor information. + The sensor information. - The tunneling current between tip and sample after - applying bias voltage. + The tunneling current between tip and sample after + applying bias voltage. - Offset value of the current measurement. + Offset value of the current measurement. - Calibration of the current measurement. + Calibration of the current measurement. - The coefficients of the calibration. + The coefficients of the calibration. - An amplifier information for the input signal (e.g. from tip). + An amplifier information for the input signal (e.g. from tip). - Proportional relationship between the probe output voltage and the actual - tunneling current when measuring the tunneling current. + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. - To explain bias (sweep measurement) voltage applied to the sample. + To explain bias (sweep measurement) voltage applied to the sample. - Setup and scan data for continuous measurement of bias-voltage on the subject of experiment - vs tunneling current from probe. - Data from from this experiment can also be used to calculate the dI/dV spectra. + Setup and scan data for continuous measurement of bias-voltage on the subject of experiment + vs tunneling current from probe. + Data from from this experiment can also be used to calculate the dI/dV spectra. - The sensor information for the piezo device. + The sensor information for the piezo device. - The piezo configuration information like piezoelectric device calibration and - material properties. + The piezo configuration information like piezoelectric device calibration and + material properties. - Calibration of the piezo device. + Calibration of the piezo device. - + - The N (substring) denotes X and Y directions. The 2nd order piezo - compensate the error for that axis. The following equation shows the - interpretation of the 2nd order correction parameters, - For the X-piezo: "Ux = 1/cx · X + cxx · X2" - with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" - where cx is the calibration of the piezo X and cxx is the 2nd order - correction. The unit for such the second-order correction is (V/m^2). + The N (substring) denotes X and Y directions. The 2nd order piezo + compensate the error for that axis. The following equation shows the + interpretation of the 2nd order correction parameters, + For the X-piezo: "Ux = 1/cx · X + cxx · X2" + with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" + where cx is the calibration of the piezo X and cxx is the 2nd order + correction. The unit for such the second-order correction is (V/m^2). - The name of the calibration type, sometimes it is called - e.g active calibration, passive calibration. + The name of the calibration type, sometimes it is called + e.g active calibration, passive calibration. - + - The calibration coefficient is the ratio of the actual distance moved by the piezo to - the voltage applied to the piezo. It is also called first-order correction. + The calibration coefficient is the ratio of the actual distance moved by the piezo to + the voltage applied to the piezo. It is also called first-order correction. - + - Set up the settings to enable or disable the drift compensation. + Set up the settings to enable or disable the drift compensation. - Whether the drift has been corrected in case there is a deviation in the - drift. + Whether the drift has been corrected in case there is a deviation in the + drift. - + - The N (substring) denotes X and Y directions, and for both directions - tilt needs to be adjusted according to the actual surface. + The N (substring) denotes X and Y directions, and for both directions + tilt needs to be adjusted according to the actual surface. - + - The N (substring) denotes X or Y or Z. In some systems, - there is an HV gain readout feature. For these systems, - the HV gain should be automatically adjusted whenever - the gain is changed at the high voltage amplifier. + The N (substring) denotes X or Y or Z. In some systems, + there is an HV gain readout feature. For these systems, + the HV gain should be automatically adjusted whenever + the gain is changed at the high voltage amplifier. - The positioner information like the position of the tip, - PID loop feedback etc. + The positioner information like the position of the tip, + PID loop feedback etc. - + - The PID controller information for the z-axis. + The PID controller information for the z-axis. - To indicate the relative tip position z between tip and sample. The tip position - can also be varied when the z_controller is not running. + To indicate the relative tip position z between tip and sample. The tip position + can also be varied when the z_controller is not running. - The set point for the z-controller to be fixed and the target value could be - height or current. + The set point for the z-controller to be fixed and the target value could be + height or current. - The name of the controller or channels. + The name of the controller or channels. - The status of the controller to say was PID has been used or not. + The status of the controller to say was PID has been used or not. - If the tip is lifted from the stable point. + If the tip is lifted from the stable point. - The switch-off delay of the controller from its stable point. + The switch-off delay of the controller from its stable point. @@ -284,86 +284,86 @@ TODO: Replace rename NXenvironment to experiment_environment in NXstm, NXspm and - The group's concepts hold the link to the related concepts that define the - reproducibility of the STM experiment. + The group's concepts hold the link to the related concepts that define the + reproducibility of the STM experiment. - The tunneling current between tip and sample after application of bias voltage. - link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current + The tunneling current between tip and sample after application of bias voltage. + link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current - The tunneling current between tip and sample after application of bias voltage. - link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current + The tunneling current between tip and sample after application of bias voltage. + link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current - Proportional relationship between the probe output voltage and the actual - tunneling current when measuring the tunneling current. - link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/amplifier/current_gain + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. + link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/amplifier/current_gain - Link to target: - /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] + Link to target: + /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] - This is the signal on which the modulation voltage or current will be added. - link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type + This is the signal on which the modulation voltage or current will be added. + link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type - The frequency of the sine modulation that is used to modulate the signal in lock-in. - link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency + The frequency of the sine modulation that is used to modulate the signal in lock-in. + link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency - The group's concepts hold the link to the related concepts that define the - resolution of the STM experiment. + The group's concepts hold the link to the related concepts that define the + resolution of the STM experiment. - Link to target: /ENTRY[entry]/experiment_instrument/scan_environment/tip_temp + Link to target: /ENTRY[entry]/experiment_instrument/scan_environment/tip_temp - Link to target: - /ENTRY[entry]/experiment_instrument/scan_environment/cryo_bottom_temp + Link to target: + /ENTRY[entry]/experiment_instrument/scan_environment/cryo_bottom_temp - Link to target: - /ENTRY[entry]/experiment_instrument/scan_environment/cryo_shield_temperature + Link to target: + /ENTRY[entry]/experiment_instrument/scan_environment/cryo_shield_temperature - Link to target: - /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] + Link to target: + /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] - This is the signal on which the modulation voltage or current will be added. - link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type - modulation_signal_type + This is the signal on which the modulation voltage or current will be added. + link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type + modulation_signal_type - The frequency of the sine modulation that is used to modulate the signal in lock-in. - link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency + The frequency of the sine modulation that is used to modulate the signal in lock-in. + link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 93b72d609c..444b1b84ea 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -38,82 +38,100 @@ Molecular mass of the substance - - - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - - - + - CAS REGISTRY name of the sample chemical content + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. - + - CAS REGISTRY URI + Unique CAS REGISTRY URI. + For further information, see https://www.cas.org/. - + + + + + + + + Numeric CAS REGISTRY number associated with this identifier. + + + + + CAS REGISTRY name associated with this identifier. + + + CAS REGISTRY image - - - Synonyms in the CAS system. - - - + - String InChi identifier. + Standard string InChi identifier" (as per v1.02). + The InChI identifier expresses chemical structures in terms of atomic connectivity, tautomeric state, isotopes, stereochemistry and electronic charge in order to produce a string of machine-readable characters unique to the respective molecule. For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - + Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). - + Name according to the IUPAC system (standard). For further information, see https://iupac.org/. - + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system For further information, see https://www.daylight.com/smiles/. - + - Canonical version of the smiles identifier + Canonical version of the SMILES identifier - + - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. - - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + Standard PubChem identifier (CID). + + The PubChem Compound Identifier (CID) is a unique numerical identifier assigned to + a compound in the PubChem database, which contains information on the biological activities + of small molecules. The CID allows users to access detailed data about compounds, including + their chemical structure, molecular formula, and biological properties. + + For further information, see https://pubchem.ncbi.nlm.nih.gov/. + + + CAS REGISTRY name associated with this identifier. + + diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index c39aeafccc..a341a455e3 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -72,7 +72,7 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. @@ -81,7 +81,7 @@ Draft NeXus application definition for transmission experiments--> investigator. * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the @@ -100,12 +100,12 @@ of instrument.--> used to generate the result file(s) with measured data and metadata. - + - Version number of the program that was used to generate the result - file(s) with measured data and metadata. + Version number of the program that was used to generate the result + file(s) with measured data and metadata. - + Website of the software diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/contributed_definitions/NXwaveplate.nxdl.xml index 23743c484d..46ed95de1f 100644 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ b/contributed_definitions/NXwaveplate.nxdl.xml @@ -23,28 +23,28 @@ --> - + - Size of the wavelength array for which the refractive index of the material - and/or coating is given. + Size of the wavelength array for which the refractive index of the material + and/or coating is given. - Number of discrete wavelengths for which the waveplate is designed. If it - operates for a range of wavelengths then N_wavelengths = 2 and the minimum - and maximum values of the range should be provided. + Number of discrete wavelengths for which the waveplate is designed. If it + operates for a range of wavelengths then N_wavelengths = 2 and the minimum + and maximum values of the range should be provided. - A waveplate or retarder. + A waveplate or retarder. - Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). + Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). @@ -59,13 +59,13 @@ A draft of a new base class to describe a waveplate--> - If you selected 'other' in type describe what it is. + If you selected 'other' in type describe what it is. - Specify the retardance of the waveplate (e.g. full-wave, half-wave - (lambda/2), quarter-wave (lambda/4) plate). + Specify the retardance of the waveplate (e.g. full-wave, half-wave + (lambda/2), quarter-wave (lambda/4) plate). @@ -75,10 +75,10 @@ A draft of a new base class to describe a waveplate--> - Discrete wavelengths for which the waveplate is designed. If the - waveplate operates over an entire range of wavelengths, enter the minimum - and maximum values of the wavelength range (in this case - N_wavelengths = 2). + Discrete wavelengths for which the waveplate is designed. If the + waveplate operates over an entire range of wavelengths, enter the minimum + and maximum values of the wavelength range (in this case + N_wavelengths = 2). @@ -86,42 +86,42 @@ A draft of a new base class to describe a waveplate--> - Wavelength resolved retardence of the waveplate. + Wavelength resolved retardance of the waveplate. - Diameter of the waveplate. + Diameter of the waveplate. - Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of - length/height for square geometry). + Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of + length/height for square geometry). - Describe the material of the substrate of the wave plate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. + Describe the material of the substrate of the wave plate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. - Specify the material of the wave plate. If the device has a - coating it should be described in coating/coating_material. + Specify the material of the wave plate. If the device has a + coating it should be described in coating/coating_material. - Thickness of the wave plate substrate. + Thickness of the wave plate substrate. - Complex index of refraction of the wave plate substrate. Specify at - given wavelength (or energy, wavenumber etc.) values. + Complex index of refraction of the wave plate substrate. Specify at + given wavelength (or energy, wavenumber etc.) values. @@ -131,30 +131,30 @@ A draft of a new base class to describe a waveplate--> - Is the wave plate coated? If yes, specify the type and material of the - coating and the wavelength range for which it is designed. If known, you - may also provide its index of refraction. + Is the wave plate coated? If yes, specify the type and material of the + coating and the wavelength range for which it is designed. If known, you + may also provide its index of refraction. - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Specify the coating material. + Specify the coating material. - Thickness of the coating. + Thickness of the coating. - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. @@ -162,8 +162,8 @@ A draft of a new base class to describe a waveplate--> - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). @@ -173,7 +173,7 @@ A draft of a new base class to describe a waveplate--> - Average reflectance of the waveplate in percentage. + Average reflectance of the waveplate in percentage. diff --git a/contributed_definitions/NXxpcs.nxdl.xml b/contributed_definitions/NXxpcs.nxdl.xml index 9839fbb2a9..6d3c14d106 100644 --- a/contributed_definitions/NXxpcs.nxdl.xml +++ b/contributed_definitions/NXxpcs.nxdl.xml @@ -3,7 +3,7 @@ -# -# -# 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/contributed_definitions/nyaml/NXafm.yaml b/contributed_definitions/nyaml/NXafm.yaml index 6be0b8f155..7274604426 100644 --- a/contributed_definitions/nyaml/NXafm.yaml +++ b/contributed_definitions/nyaml/NXafm.yaml @@ -66,6 +66,7 @@ NXafm(NXspm): doc: | Link to the group ENTRY[entry]/experiment_instrument/height_piezo_sensor. XY_piezo_sensor(NXsensor): + nameType: specified doc: | Link to the group ENTRY[entry]/experiment_instrument/XY_piezo_sensor. tip_temp_sensor(NXsensor): @@ -88,6 +89,7 @@ NXafm(NXspm): The positioner information like the position of the tip, the position of the sample, PID loop feedback etc. XY_piezo_sensor(NXsensor): + nameType: specified exists: optional doc: | The sensor information for the xy piezo device. @@ -107,9 +109,17 @@ NXafm(NXspm): exists: optional doc: | The temperature of the scan environment or tip of the cantilever. + reproducibility_indicators(NXobject): + doc: | + The group of indicators (links to the existing fields in different groups) that measure + the reproducibility of the experiment. + resolution_indicators(NXobject): + exists: optional + doc: | + The group of indicators (links to the existing fields in different groups) that # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5e6d35c0745060adc6707dfd9991c887a33b67ca2ed32ece1f7a00403906419f +# 7ce97049396964826e30ad4b7ec4439b47ca9f2a9a641ae8f4fadeeb9b094a12 # # # # # -# An application definition to describe atomic force microscopy (AFM) scanning -# technique. +# An application definition to describe atomic force microscopy (AFM) scanning +# technique. # # # # -# Name of the definition that is used for the application. +# Name of the definition that is used for the application. # # # @@ -149,7 +159,7 @@ NXafm(NXspm): # # # -# The mode of the scan. +# The mode of the scan. # # # @@ -161,49 +171,49 @@ NXafm(NXspm): # # # -# The group explains the core instruments' setup of the AFM experiment as well as the environment of the corresponding -# instruments. +# The group explains the core instruments' setup of the AFM experiment as well as the environment of the corresponding +# instruments. # # # -# Information about the quadrant photodiode deflection detector. +# Information about the quadrant photodiode deflection detector. # # # # -# The cantilever information. -# -# Generally speaking, the cantilever resembles a leaf spring, which behaves as a simple harmonic oscillator. -# When the probe (tip or particle) on the end of the cantilever is close to the surface of the sample, -# an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. -# The detector (typically a light pointer hitting a quadrant photodiode) measures this deformation and, therefore, -# the force acting on the cantilever. -# In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting -# on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of -# this loop controls the vertical position of the cantilever. +# The cantilever information. +# +# Generally speaking, the cantilever resembles a leaf spring, which behaves as a simple harmonic oscillator. +# When the probe (tip or particle) on the end of the cantilever is close to the surface of the sample, +# an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. +# The detector (typically a light pointer hitting a quadrant photodiode) measures this deformation and, therefore, +# the force acting on the cantilever. +# In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting +# on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of +# this loop controls the vertical position of the cantilever. # # # -# When a cantilever is oscillated close to its resonance, this describes the oscillator properties. -# -# A cantilever can be used in direct contact mode to detect interaction forces or oscillated close to its -# resonance frequency. Changes in the oscillation amplitude, phase (between oscillated tail and moving tip) -# or resonance frequency are very sensitive to changes in the interction potential field, giving rise of -# various measurement modes, such as non-contact or intermittent-contact (tapping) modes. +# When a cantilever is oscillated close to its resonance, this describes the oscillator properties. +# +# A cantilever can be used in direct contact mode to detect interaction forces or oscillated close to its +# resonance frequency. Changes in the oscillation amplitude, phase (between oscillated tail and moving tip) +# or resonance frequency are very sensitive to changes in the interction potential field, giving rise of +# various measurement modes, such as non-contact or intermittent-contact (tapping) modes. # # # # -# The threshold voltage for oscillator excitation. +# The threshold voltage for oscillator excitation. # # # # -# Phase locked loop for cantilever lock-in device. +# Phase locked loop for cantilever lock-in device. # # # -# The reference amplitude (also called drive amplitude) of the cantilever. +# The reference amplitude (also called drive amplitude) of the cantilever. # # # @@ -211,73 +221,84 @@ NXafm(NXspm): # # # -# The environment information. +# The environment information. # # # -# Link to the group ENTRY[entry]/experiment_instrument/height_piezo_sensor. +# Link to the group ENTRY[entry]/experiment_instrument/height_piezo_sensor. # # -# +# # -# Link to the group ENTRY[entry]/experiment_instrument/XY_piezo_sensor. +# Link to the group ENTRY[entry]/experiment_instrument/XY_piezo_sensor. # # # # -# Link to the group ENTRY[entry]/experiment_instrument/cantilever_temperature. +# Link to the group ENTRY[entry]/experiment_instrument/cantilever_temperature. # # # # # -# The sensor information for the height piezo device. +# The sensor information for the height piezo device. # # # -# The piezo configuration information like piezoelectric calibration and material -# properties. +# The piezo configuration information like piezoelectric calibration and material +# properties. # # # -# The material description and properties of the piezoelectric scanner materials. +# The material description and properties of the piezoelectric scanner materials. # # # # # -# The positioner information like the position of the tip, the position of the -# sample, PID loop feedback etc. +# The positioner information like the position of the tip, the position of the +# sample, PID loop feedback etc. # # # -# +# # -# The sensor information for the xy piezo device. +# The sensor information for the xy piezo device. # # # -# The piezo configuration information like piezoelectric calibration and material -# properties. +# The piezo configuration information like piezoelectric calibration and material +# properties. # # # -# The material description and properties of the piezoelectric scanner materials. +# The material description and properties of the piezoelectric scanner materials. # # # # # -# The positioner information like the position of the end of the cantilever, the position of the -# sample, PID loop feedback etc. +# The positioner information like the position of the end of the cantilever, the position of the +# sample, PID loop feedback etc. # # # # # -# The temperature of the scan environment or tip of the cantilever. +# The temperature of the scan environment or tip of the cantilever. # # # +# +# +# The group of indicators (links to the existing fields in different groups) that measure +# the reproducibility of the experiment. +# +# +# +# +# The group of indicators (links to the existing fields in different groups) that +# +# # # diff --git a/contributed_definitions/nyaml/NXapm.yaml b/contributed_definitions/nyaml/NXapm.yaml index 2301b25b2d..a665348f20 100644 --- a/contributed_definitions/nyaml/NXapm.yaml +++ b/contributed_definitions/nyaml/NXapm.yaml @@ -31,6 +31,7 @@ NXapm(NXobject): # command_line_call(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | A collection of all programs and libraries which are considered relevant @@ -51,18 +52,15 @@ NXapm(NXobject): \@version(NX_CHAR): # \@url: - experiment_identifier(NXidentifier): + identifier_experiment: exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): run_number(NX_CHAR): exists: recommended # cannot be made required as for simulations you do not have a run number! doc: | The identifier whereby the experiment is referred to in the control software. - This is neither the specimen_name nor the experiment_identifier. For + This is neither the specimen_name nor the identifier_experiment. For Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, @@ -71,7 +69,7 @@ NXapm(NXobject): The field does not have to be required if the information is recoverable in the dataset which for LEAP instruments is the case (provided these RHIT or HITS files respectively are stored alongside a data artifact). - With NXapm the RHIT or HITS can be stored as via the NXserialized group + With NXapm the RHIT or HITS can be stored as via the NXnote group in the hit_finding algorithm section. As a destructive microscopy technique, a run can be performed only once. @@ -131,10 +129,11 @@ NXapm(NXobject): (NXcite): exists: ['min', '0', 'max', 'unbounded'] doi(NX_CHAR): - serializedID(NXserialized): + serializedID(NXnote): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): operation_mode(NX_CHAR): @@ -158,11 +157,8 @@ NXapm(NXobject): exists: recommended name(NX_CHAR): exists: optional - identifier(NXidentifier): + identifier: exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): sample(NXsample): exists: recommended doc: | @@ -189,11 +185,8 @@ NXapm(NXobject): alias(NX_CHAR): doc: | Given name/alias for the sample. - identifier(NXidentifier): + identifier: exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): grain_diameter(NX_FLOAT): exists: optional unit: NX_LENGTH @@ -277,6 +270,7 @@ NXapm(NXobject): fractional quantities. enumeration: [atom_percent, weight_percent] ionID(NXion): + nameType: partial exists: ['min', '1', 'max', '118'] chemical_symbol(NX_CHAR): doc: | @@ -305,20 +299,14 @@ NXapm(NXobject): doc: | Given name an alias. Better use identifier and parent_identifier instead. A single NXentry should be used only for the characterization of a single specimen. - identifier(NXidentifier): + identifier: exists: recommended - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - parent_identifier(NXidentifier): + identifier_parent: exists: recommended doc: | Identifier of the sample from which the specimen was cut or the string n/a. The purpose of this field is to support functionalities for tracking sample provenance via a research data management system. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): preparation_date(NX_DATE_TIME): exists: recommended doc: | @@ -443,7 +431,7 @@ NXapm(NXobject): fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended reflectron(NXreflectron): status(NX_CHAR): @@ -474,6 +462,7 @@ NXapm(NXobject): model(NX_CHAR): pulse_mode(NX_CHAR): sourceID(NXsource): + nameType: partial exists: ['min', '0', 'max', '2'] fabrication(NXfabrication): exists: recommended @@ -603,6 +592,7 @@ NXapm(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial real(NX_NUMBER): axis_j(NX_NUMBER): dimensions: @@ -622,15 +612,16 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): # point at least to the proprietary artifact - serialized(NXserialized): + serialized(NXnote): exists: recommended type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): hit_finding(NXapm_hit_finding): @@ -644,15 +635,16 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): # config of the hit_finding algorithm - serialized(NXserialized): + serialized(NXnote): exists: recommended type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): number_of_dld_wires(NX_UINT): @@ -663,7 +655,7 @@ NXapm(NXobject): # results of the hit_finding algorithm hit_quality_types(NX_CHAR): exists: optional - hit_quality_identifier(NX_UINT): + identifier_hit_quality(NX_UINT): exists: optional hit_positions(NX_NUMBER): exists: recommended @@ -701,20 +693,22 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - serialized(NXserialized): + serialized(NXnote): exists: optional type(NX_CHAR): - path(NX_CHAR): + identifierNAME(NX_CHAR): + nameType: partial checksum(NX_CHAR): algorithm(NX_CHAR): - evaporation_identifier_offset(NX_INT): + identifier_evaporation_offset(NX_INT): unit: NX_UNITLESS doc: | Integer used to name the first pulse to know if there is an - offset of the evaporation_identifier to zero. + offset of the identifier_evaporation to zero. Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval @@ -727,7 +721,7 @@ NXapm(NXobject): For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit identifier conventions where identifier_offset is 1 and 0 respectively. - evaporation_identifier(NX_INT): + identifier_evaporation(NX_INT): unit: NX_UNITLESS doc: | (Molecular) ion identifier which resolves the sequence in which @@ -751,13 +745,14 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - serialized(NXserialized): + serialized(NXnote): exists: optional type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): @@ -782,13 +777,14 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - serialized(NXserialized): + serialized(NXnote): exists: recommended type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): @@ -803,10 +799,11 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - config(NXserialized): + config(NXnote): exists: recommended doc: | For LEAP and IVAS/APSuite-based analyses root file which stores @@ -816,10 +813,10 @@ NXapm(NXobject): The respective RHIT/HITS file should ideally be specified in the serialized group of the hit_finding section of this application definition. type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - results(NXserialized): + results(NXnote): exists: recommended doc: | For LEAP and IVAS/APSuite-based analyses the resulting typically @@ -833,7 +830,7 @@ NXapm(NXobject): which should be stored alongside this record in the research data management system. type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): @@ -851,6 +848,7 @@ NXapm(NXobject): dim: (n, 3) naive_discretization(NXprocess): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -861,6 +859,7 @@ NXapm(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial # dim: (3,) # \@long_name: @@ -889,15 +888,16 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): - definitions(NXserialized): + definitions(NXnote): exists: recommended doc: | The respective ranging definitions file RNG/RRNG/ENV/HDF5. type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): @@ -908,6 +908,7 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -918,6 +919,7 @@ NXapm(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial # \@long_name(NX_CHAR): title(NX_CHAR): @@ -936,6 +938,7 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -966,10 +969,12 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): peakID(NXpeak): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] label(NX_CHAR): exists: recommended @@ -997,10 +1002,12 @@ NXapm(NXobject): sequence_index(NX_POSINT): exists: recommended programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): ionID(NXion): + nameType: partial exists: ['min', '1', 'max', '256'] nuclide_hash(NX_UINT): charge_state(NX_INT): @@ -1028,7 +1035,7 @@ NXapm(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 81e056ae147152ade1a808f3f1b0b4827d86d442a254951c86c6a22c90bec002 +# caad90e4467ddac14732edbac5115f3f31e8dd3e10590783ae17dff7ae2fcb04 # # # -# +# # -# A collection of all programs and libraries which are considered relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. +# A collection of all programs and libraries which are considered relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. # # # @@ -1114,54 +1121,48 @@ NXapm(NXobject): # # # -# -# -# -# -# +# # -# +# # -# The identifier whereby the experiment is referred to in the control software. -# This is neither the specimen_name nor the experiment_identifier. For -# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the -# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. -# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, -# or the instruments at GPM in Rouen, use the identifier which matches -# best conceptually to the LEAP run number. -# The field does not have to be required if the information is recoverable -# in the dataset which for LEAP instruments is the case (provided these -# RHIT or HITS files respectively are stored alongside a data artifact). -# With NXapm the RHIT or HITS can be stored as via the NXserialized group -# in the hit_finding algorithm section. -# -# As a destructive microscopy technique, a run can be performed only once. -# It is possible, however, to interrupt a run and restart data acquisition -# while still using the same specimen. In this case, each evaporation run -# needs to be distinguished with different run numbers. -# We follow this habit of most atom probe groups. Such interrupted runs -# should be stored as individual :ref:`NXentry` instances in one NeXus file. +# The identifier whereby the experiment is referred to in the control software. +# This is neither the specimen_name nor the identifier_experiment. For +# Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the +# run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. +# For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, +# or the instruments at GPM in Rouen, use the identifier which matches +# best conceptually to the LEAP run number. +# The field does not have to be required if the information is recoverable +# in the dataset which for LEAP instruments is the case (provided these +# RHIT or HITS files respectively are stored alongside a data artifact). +# With NXapm the RHIT or HITS can be stored as via the NXnote group +# in the hit_finding algorithm section. +# +# As a destructive microscopy technique, a run can be performed only once. +# It is possible, however, to interrupt a run and restart data acquisition +# while still using the same specimen. In this case, each evaporation run +# needs to be distinguished with different run numbers. +# We follow this habit of most atom probe groups. Such interrupted runs +# should be stored as individual :ref:`NXentry` instances in one NeXus file. # # # # -# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. -# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. +# Either an identifier or an alias that is human-friendly so that scientists find that experiment again. +# For experiments usually this is the run_number but for simulation typically no run_numbers are issued. # # # # -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into this field. -# -# The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into this field. +# +# The reason is that such free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn in how far the +# current base classes need extension based on user feedback. # # # # # -# ISO 8601 time code with local time zone offset to UTC information -# included when the atom probe session started. If the exact duration of -# the measurement is not relevant start_time only should be used. -# -# Often though it is useful to specify both start_time and end_time to -# capture more detailed bookkeeping of the experiment. The user should -# be aware that even with having both dates specified, it may not be -# possible to infer how long the experiment took or for how long data -# were collected. -# -# More detailed timing data over the course of the experiment have to be -# collected to compute this event chain during the experiment. For this -# purpose the :ref:`NXevent_data_apm` instance should be used. +# ISO 8601 time code with local time zone offset to UTC information +# included when the atom probe session started. If the exact duration of +# the measurement is not relevant start_time only should be used. +# +# Often though it is useful to specify both start_time and end_time to +# capture more detailed bookkeeping of the experiment. The user should +# be aware that even with having both dates specified, it may not be +# possible to infer how long the experiment took or for how long data +# were collected. +# +# More detailed timing data over the course of the experiment have to be +# collected to compute this event chain during the experiment. For this +# purpose the :ref:`NXevent_data_apm` instance should be used. # # # # -# ISO 8601 time code with local time zone offset to UTC included -# when the atom probe session ended. +# ISO 8601 time code with local time zone offset to UTC included +# when the atom probe session ended. # # # # # -# +# # -# +# # # # # # -# What type of atom probe experiment is performed? This field is meant to -# inform research data management systems to allow filtering: -# -# * apt are experiments where the analysis_chamber has no imaging gas. -# experiment with LEAP instruments are typically performed such. -# * fim are experiments where the analysis_chamber has an imaging gas, -# which should be specified with the atmosphere in the analysis_chamber group. -# * apt_fim should be used for combinations of the two imaging modes. -# few experiments of this type have been performed as this can be detrimental -# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). -# * other should be used in combination with the user specifying details -# in the experiment_documentation field. -# -# If NXapm is used for storing details about a simulation use other for now. +# What type of atom probe experiment is performed? This field is meant to +# inform research data management systems to allow filtering: +# +# * apt are experiments where the analysis_chamber has no imaging gas. +# experiment with LEAP instruments are typically performed such. +# * fim are experiments where the analysis_chamber has an imaging gas, +# which should be specified with the atmosphere in the analysis_chamber group. +# * apt_fim should be used for combinations of the two imaging modes. +# few experiments of this type have been performed as this can be detrimental +# to LEAP systems (see `S. Katnagallu et al. <https://doi.org/10.1017/S1431927621012381>`_). +# * other should be used in combination with the user specifying details +# in the experiment_documentation field. +# +# If NXapm is used for storing details about a simulation use other for now. # # # @@ -1233,34 +1234,30 @@ NXapm(NXobject): # # # -# -# -# -# -# +# # # # -# Description of the sample from which the specimen was prepared or -# site-specifically cut out using e.g. a focused-ion beam instrument. -# -# The sample group is currently a place for storing suggestions from -# atom probers about knowledge they have gained about the sample. -# There are cases where the specimen is machined further or exposed to -# external stimuli during the experiment. In this case, these details should -# not be stored under sample but suggestions should be made -# how this application definition can be improved. -# -# In the future also details like how the grain_diameter was characterized, -# how the sample was prepared, how the material was heat-treated etc., -# should be stored. For this specific application definitions/schemas can be -# used which are then arranged and documented with a description of the -# workflow so that actionable graphs become instantiatable. +# Description of the sample from which the specimen was prepared or +# site-specifically cut out using e.g. a focused-ion beam instrument. +# +# The sample group is currently a place for storing suggestions from +# atom probers about knowledge they have gained about the sample. +# There are cases where the specimen is machined further or exposed to +# external stimuli during the experiment. In this case, these details should +# not be stored under sample but suggestions should be made +# how this application definition can be improved. +# +# In the future also details like how the grain_diameter was characterized, +# how the sample was prepared, how the material was heat-treated etc., +# should be stored. For this specific application definitions/schemas can be +# used which are then arranged and documented with a description of the +# workflow so that actionable graphs become instantiatable. # # # -# A qualifier whether the sample is a real one -# or a virtual one (in a computer simulation). +# A qualifier whether the sample is a real one +# or a virtual one (in a computer simulation). # # # @@ -1269,120 +1266,114 @@ NXapm(NXobject): # # # -# Given name/alias for the sample. +# Given name/alias for the sample. # # -# -# -# -# -# +# # # -# Qualitative information about the grain size, here specifically -# described as the equivalent spherical diameter of an assumed -# average grain size for the crystal ensemble. -# Users of this information should be aware that although the grain -# diameter or radius is often referred to as grain size. -# -# In atom probe it is possible that the specimen may contain a few -# crystals only. In this case the grain_diameter is not a reliable -# descriptor. Reporting a grain size may be useful though as it allows -# judging if specific features are expected to be found in the -# detector hit map. +# Qualitative information about the grain size, here specifically +# described as the equivalent spherical diameter of an assumed +# average grain size for the crystal ensemble. +# Users of this information should be aware that although the grain +# diameter or radius is often referred to as grain size. +# +# In atom probe it is possible that the specimen may contain a few +# crystals only. In this case the grain_diameter is not a reliable +# descriptor. Reporting a grain size may be useful though as it allows +# judging if specific features are expected to be found in the +# detector hit map. # # # # -# Magnitude of the standard deviation of the grain_diameter. +# Magnitude of the standard deviation of the grain_diameter. # # -# +# # # -# The temperature of the last heat treatment step before quenching. -# Knowledge about this value can give an idea how the sample -# was heat treated. However, if a documentation of the annealing -# treatment as a function of time is available one should better -# rely on this information and have it stored alongside the NeXus file. +# The temperature of the last heat treatment step before quenching. +# Knowledge about this value can give an idea how the sample +# was heat treated. However, if a documentation of the annealing +# treatment as a function of time is available one should better +# rely on this information and have it stored alongside the NeXus file. # # # # -# Magnitude of the standard deviation of the heat_treatment_temperature. +# Magnitude of the standard deviation of the heat_treatment_temperature. # # # # -# Rate of the last quenching step. Knowledge about this value can give -# an idea how the sample was heat treated. However, there are many -# situations where one can imagine that the scalar value for just the -# quenching rate is insufficient. -# -# An example is when the sample was left in the furnace after the -# furnace was switched off. In this case the sample cools down with -# a specific rate of how this furnace cools down in the lab. -# Processes which in practice are often not documented. -# -# This can be problematic though because when the furnace door was left open -# or the ambient temperature in the lab changed, i.e. for a series of -# experiments where one is conducted on a hot summer day and the next -# during winter this can have an effect on the evolution of the microstructure. -# There are many cases where this has been reported to be an QA issue in industry, -# e.g. think about aging aluminium samples left on the factory -# parking lot on a hot summer day. +# Rate of the last quenching step. Knowledge about this value can give +# an idea how the sample was heat treated. However, there are many +# situations where one can imagine that the scalar value for just the +# quenching rate is insufficient. +# +# An example is when the sample was left in the furnace after the +# furnace was switched off. In this case the sample cools down with +# a specific rate of how this furnace cools down in the lab. +# Processes which in practice are often not documented. +# +# This can be problematic though because when the furnace door was left open +# or the ambient temperature in the lab changed, i.e. for a series of +# experiments where one is conducted on a hot summer day and the next +# during winter this can have an effect on the evolution of the microstructure. +# There are many cases where this has been reported to be an QA issue in industry, +# e.g. think about aging aluminium samples left on the factory +# parking lot on a hot summer day. # # # # -# Magnitude of the standard deviation of the heat_treatment_quenching_rate. +# Magnitude of the standard deviation of the heat_treatment_quenching_rate. # # # # # -# The chemical composition of the sample. Typically, it is assumed that -# this more macroscopic composition is representative for the material -# so that the composition of the typically substantially less voluminous -# specimen probes from the more voluminous sample. +# The chemical composition of the sample. Typically, it is assumed that +# this more macroscopic composition is representative for the material +# so that the composition of the typically substantially less voluminous +# specimen probes from the more voluminous sample. # # # -# Reporting compositions as atom and weight percent yields both -# dimensionless quantities but their conceptual interpretation differs. -# A normalization based on atom_percent counts relative to the -# total number of atoms which are of a particular type. -# By contrast, weight_percent normalization factorizes in the -# respective mass of the elements. Python libraries like pint are -# challenged by these differences as at.-% and wt.-% are both -# fractional quantities. +# Reporting compositions as atom and weight percent yields both +# dimensionless quantities but their conceptual interpretation differs. +# A normalization based on atom_percent counts relative to the +# total number of atoms which are of a particular type. +# By contrast, weight_percent normalization factorizes in the +# respective mass of the elements. Python libraries like pint are +# challenged by these differences as at.-% and wt.-% are both +# fractional quantities. # # # # # # -# +# # # -# Human-readable name of the element (e.g. Fe). -# Name has to be a symbol of an element from the periodic table. -# All symbols in the set of NXion instances inside the group -# chemical_composition need to be disjoint. +# Human-readable name of the element (e.g. Fe). +# Name has to be a symbol of an element from the periodic table. +# All symbols in the set of NXion instances inside the group +# chemical_composition need to be disjoint. # # # # -# Composition value for the element/ion referred to under name. -# The value is normalized based on normalization, i.e. composition -# is either an atom or weight percent quantity. +# Composition value for the element/ion referred to under name. +# The value is normalized based on normalization, i.e. composition +# is either an atom or weight percent quantity. # # # # -# Magnitude of the standard deviation of the composition (value). +# Magnitude of the standard deviation of the composition (value). # # # @@ -1391,7 +1382,7 @@ NXapm(NXobject): # # # -# A qualifier whether the specimen is a real one or a virtual one. +# A qualifier whether the specimen is a real one or a virtual one. # # # @@ -1400,138 +1391,131 @@ NXapm(NXobject): # # # -# Given name an alias. Better use identifier and parent_identifier instead. -# A single NXentry should be used only for the characterization of a single specimen. +# Given name an alias. Better use identifier and parent_identifier instead. +# A single NXentry should be used only for the characterization of a single specimen. # # -# -# -# -# -# -# +# +# # -# Identifier of the sample from which the specimen was cut or the string -# n/a. The purpose of this field is to support functionalities for -# tracking sample provenance via a research data management system. +# Identifier of the sample from which the specimen was cut or the string +# n/a. The purpose of this field is to support functionalities for +# tracking sample provenance via a research data management system. # -# -# -# -# +# # # -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known time -# the measured specimen surface was actively prepared. Ideally, this -# matches the last timestamp that is mentioned in the digital resource -# pointed to by parent_identifier. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is -# especially required for environmentally sensitive material such as -# hydrogen charged specimens or experiments including tracers with a -# short half time. Additional time stamps prior to preparation_date -# should better be placed in resources which describe but which do not -# pollute the description here with prose. Resolving these connected -# pieces of information is considered within the responsibility of the -# research data management system. +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known time +# the measured specimen surface was actively prepared. Ideally, this +# matches the last timestamp that is mentioned in the digital resource +# pointed to by parent_identifier. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is +# especially required for environmentally sensitive material such as +# hydrogen charged specimens or experiments including tracers with a +# short half time. Additional time stamps prior to preparation_date +# should better be placed in resources which describe but which do not +# pollute the description here with prose. Resolving these connected +# pieces of information is considered within the responsibility of the +# research data management system. # # # # -# List of comma-separated elements from the periodic table that are -# contained in the specimen. If the specimen substance has multiple -# components, all elements from each component must be included in -# `atom_types`. -# -# The purpose of the field is to offer research data management systems an -# opportunity to parse the relevant elements without having to interpret -# these from the resources pointed to by parent_identifier or walk through -# eventually deeply nested groups in data instances. +# List of comma-separated elements from the periodic table that are +# contained in the specimen. If the specimen substance has multiple +# components, all elements from each component must be included in +# `atom_types`. +# +# The purpose of the field is to offer research data management systems an +# opportunity to parse the relevant elements without having to interpret +# these from the resources pointed to by parent_identifier or walk through +# eventually deeply nested groups in data instances. # # # # -# Discouraged free-text field. +# Discouraged free-text field. # # # # -# Report if the specimen is polycrystalline, in which case it -# contains a grain or phase boundary, or if the specimen is a -# single crystal. +# Report if the specimen is polycrystalline, in which case it +# contains a grain or phase boundary, or if the specimen is a +# single crystal. # # # # -# Report if the specimen is amorphous. +# Report if the specimen is amorphous. # # # # -# Ideally measured otherwise best elaborated guess of the initial radius of the -# specimen. +# Ideally measured otherwise best elaborated guess of the initial radius of the +# specimen. # # # # -# Ideally measured otherwise best elaborated guess of the (initial) shank angle. -# This is a measure of the specimen taper. Define it in such a way that the base of the specimen -# is modelled as a conical frustrum so that the shank angle is the (shortest) angle between -# the specimen space z-axis and a vector on the lateral surface of the cone. +# Ideally measured otherwise best elaborated guess of the (initial) shank angle. +# This is a measure of the specimen taper. Define it in such a way that the base of the specimen +# is modelled as a conical frustrum so that the shank angle is the (shortest) angle between +# the specimen space z-axis and a vector on the lateral surface of the cone. # # # # # # -# Set to hold different coordinate systems conventions. -# Inspect the description of the :ref:`NXcoordinate_system_set` -# and :ref:`NXcoordinate_system` base classes how to define -# coordinate systems in NeXus. Specific details for application -# in atom probe microscopy follow. -# -# In this research field scientists usually distinguish several -# Euclidean coordinate systems (CS): -# -# * World space; -# a CS specifying a local coordinate system of the planet earth which -# identifies into which direction gravity is pointing such that -# the laboratory space CS can be rotated into this world CS. -# * The laboratory space; -# a CS specifying the room where the instrument is located in or -# a physical landmark on the instrument, e.g. the direction of the -# transfer rod where positive is the direction how the rod -# has to be pushed during loading a specimen into the instrument. -# In summary, this CS is defined by the chassis of the instrument. -# * The specimen space; -# a CS affixed to either the base or the initial apex of the specimen, -# whose z axis points towards the detector. -# * The detector space; -# a CS affixed to the detector plane whose xy plane is usually in the -# detector and whose z axis points towards the specimen. -# This is a distorted space with respect to the reconstructed ion -# positions. -# * The reconstruction space; -# a CS in which the reconstructed ion positions are defined. -# The orientation depends on the analysis software used. -# * Eventually further coordinate systems attached to the -# flight path of individual ions might be defined. -# -# In atom probe microscopy a frequently used choice for the detector -# space (CS) is discussed with the so-called detector space image -# (stack). This is a stack of two-dimensional histograms of detected ions -# within a predefined evaporation identifier interval. Typically, the set of -# ion evaporation sequence IDs is grouped into chunks. -# -# For each chunk a histogram of the ion hit positions on the detector -# is computed. This leaves the possibility for inconsistency between -# the so-called detector space and the e.g. specimen space. -# -# To avoid these ambiguities, instances of :ref:`NXtransformations` should -# be used. +# Set to hold different coordinate systems conventions. +# Inspect the description of the :ref:`NXcoordinate_system_set` +# and :ref:`NXcoordinate_system` base classes how to define +# coordinate systems in NeXus. Specific details for application +# in atom probe microscopy follow. +# +# In this research field scientists usually distinguish several +# Euclidean coordinate systems (CS): +# +# * World space; +# a CS specifying a local coordinate system of the planet earth which +# identifies into which direction gravity is pointing such that +# the laboratory space CS can be rotated into this world CS. +# * The laboratory space; +# a CS specifying the room where the instrument is located in or +# a physical landmark on the instrument, e.g. the direction of the +# transfer rod where positive is the direction how the rod +# has to be pushed during loading a specimen into the instrument. +# In summary, this CS is defined by the chassis of the instrument. +# * The specimen space; +# a CS affixed to either the base or the initial apex of the specimen, +# whose z axis points towards the detector. +# * The detector space; +# a CS affixed to the detector plane whose xy plane is usually in the +# detector and whose z axis points towards the specimen. +# This is a distorted space with respect to the reconstructed ion +# positions. +# * The reconstruction space; +# a CS in which the reconstructed ion positions are defined. +# The orientation depends on the analysis software used. +# * Eventually further coordinate systems attached to the +# flight path of individual ions might be defined. +# +# In atom probe microscopy a frequently used choice for the detector +# space (CS) is discussed with the so-called detector space image +# (stack). This is a stack of two-dimensional histograms of detected ions +# within a predefined evaporation identifier interval. Typically, the set of +# ion evaporation sequence IDs is grouped into chunks. +# +# For each chunk a histogram of the ion hit positions on the detector +# is computed. This leaves the possibility for inconsistency between +# the so-called detector space and the e.g. specimen space. +# +# To avoid these ambiguities, instances of :ref:`NXtransformations` should +# be used. # # # @@ -1549,7 +1533,7 @@ NXapm(NXobject): # # # -# +# # # # @@ -1579,14 +1563,14 @@ NXapm(NXobject): # # # -# +# # # # # # # -# The wavelength of the radiation emitted by the source. +# The wavelength of the radiation emitted by the source. # # # @@ -1596,8 +1580,8 @@ NXapm(NXobject): # # # -# The space inside the atom probe along which ions pass nominally -# when they leave the specimen and travel to the detector. +# The space inside the atom probe along which ions pass nominally +# when they leave the specimen and travel to the detector. # # # @@ -1683,8 +1667,8 @@ NXapm(NXobject): # # # -# A region-of-interest analyzed either during or after the session for which -# specific processed data of the measured or simulated data are available. +# A region-of-interest analyzed either during or after the session for which +# specific processed data of the measured or simulated data are available. # # # # -# SEM or TEM image of the initial specimen i.e. -# ideally taken prior to the data acquisition. +# SEM or TEM image of the initial specimen i.e. +# ideally taken prior to the data acquisition. # # # # -# +# # # # @@ -1723,15 +1707,15 @@ NXapm(NXobject): # a time series of the specimen shape evolution--> # # -# +# # # # # # -# +# # -# +# # # # @@ -1743,15 +1727,15 @@ NXapm(NXobject): # is does not have the authority to decide which portions of proprietary code have to be public # we can only make recommendations--> # -# +# # # # # # -# +# # -# +# # # # @@ -1759,7 +1743,7 @@ NXapm(NXobject): # # # -# +# # # # @@ -1778,56 +1762,56 @@ NXapm(NXobject): # # # # # -# +# # # # # -# +# # -# +# # # # -# +# # -# Integer used to name the first pulse to know if there is an -# offset of the evaporation_identifier to zero. -# -# Identifiers can be defined either implicitly or explicitly. -# For implicit indexing identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# -# Therefore, implicit identifier are completely defined by the value of -# identifier_offset and cardinality. For example if identifier run from -# -2 to 3 the value for identifier_offset is -2. -# -# For explicit indexing the field identifier has to be used. -# Fortran-/Matlab- and C-/Python-style indexing have specific implicit -# identifier conventions where identifier_offset is 1 and 0 respectively. +# Integer used to name the first pulse to know if there is an +# offset of the identifier_evaporation to zero. +# +# Identifiers can be defined either implicitly or explicitly. +# For implicit indexing identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# +# Therefore, implicit identifier are completely defined by the value of +# identifier_offset and cardinality. For example if identifier run from +# -2 to 3 the value for identifier_offset is -2. +# +# For explicit indexing the field identifier has to be used. +# Fortran-/Matlab- and C-/Python-style indexing have specific implicit +# identifier conventions where identifier_offset is 1 and 0 respectively. # # -# +# # -# (Molecular) ion identifier which resolves the sequence in which -# the ions were evaporated but taking into account that a hit_finding -# and spatial_filtering was applied. +# (Molecular) ion identifier which resolves the sequence in which +# the ions were evaporated but taking into account that a hit_finding +# and spatial_filtering was applied. # # # @@ -1844,14 +1828,14 @@ NXapm(NXobject): # # # -# +# # # # # -# +# # -# +# # # # @@ -1874,14 +1858,14 @@ NXapm(NXobject): # # # -# +# # # # # -# +# # -# +# # # # @@ -1895,40 +1879,40 @@ NXapm(NXobject): # # # -# +# # # # # -# +# # -# For LEAP and IVAS/APSuite-based analyses root file which stores -# the settings whereby an RHIT/HITS file can be used to regenerate the -# reconstruction that is here referred to. -# -# The respective RHIT/HITS file should ideally be specified in the serialized -# group of the hit_finding section of this application definition. +# For LEAP and IVAS/APSuite-based analyses root file which stores +# the settings whereby an RHIT/HITS file can be used to regenerate the +# reconstruction that is here referred to. +# +# The respective RHIT/HITS file should ideally be specified in the serialized +# group of the hit_finding section of this application definition. # # -# +# # # # -# +# # -# For LEAP and IVAS/APSuite-based analyses the resulting typically -# file with the reconstructed positions and (calibrated) mass-to-charge -# state ratio values. -# -# For other data collection/analysis software the data artifact which comes -# closest conceptually to AMETEK/Cameca's typical file formats. -# -# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, -# which should be stored alongside this record in the research data -# management system. +# For LEAP and IVAS/APSuite-based analyses the resulting typically +# file with the reconstructed positions and (calibrated) mass-to-charge +# state ratio values. +# +# For other data collection/analysis software the data artifact which comes +# closest conceptually to AMETEK/Cameca's typical file formats. +# +# These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, +# which should be stored alongside this record in the research data +# management system. # # -# +# # # # @@ -1944,7 +1928,7 @@ NXapm(NXobject): # # # -# +# # # # @@ -1954,8 +1938,8 @@ NXapm(NXobject): # # # -# -# # # @@ -1988,17 +1972,17 @@ NXapm(NXobject): # # # -# +# # # # # -# +# # -# The respective ranging definitions file RNG/RRNG/ENV/HDF5. +# The respective ranging definitions file RNG/RRNG/ENV/HDF5. # # -# +# # # # @@ -2006,7 +1990,7 @@ NXapm(NXobject): # # # -# +# # # # @@ -2016,7 +2000,7 @@ NXapm(NXobject): # # # -# +# # # # @@ -2035,26 +2019,26 @@ NXapm(NXobject): # # # -# +# # # # # # # -# (Out-of-sync) background levels in ppm/ns -# reported by e.g. IVAS/APSuite for LEAP systems. +# (Out-of-sync) background levels in ppm/ns +# reported by e.g. IVAS/APSuite for LEAP systems. # # # # -# MRP, mass-resolving power, `D. Larson et al. -# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). +# MRP, mass-resolving power, `D. Larson et al. +# <https://doi.org/10.1007/978-1-4614-8721-0>`_ (p282, Eqs. D.7 and D.8). # # # # -# MRP, at which mrp_value was specified. +# MRP, at which mrp_value was specified. # # # @@ -2064,27 +2048,27 @@ NXapm(NXobject): # in an e.g. work of A. London et al.--> # # -# +# # # # # -# +# # # # # -# Category for the peak offering a qualitative statement of the location of the peak -# in light of limited mass-resolving power that is relevant for -# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ -# for examples of each category: -# -# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` -# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` -# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states -# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` -# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` -# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` +# Category for the peak offering a qualitative statement of the location of the peak +# in light of limited mass-resolving power that is relevant for +# composition quantification. See `D. Larson et al. (p172) <https://doi.org/10.1007/978-1-4614-8721-0>`_ +# for examples of each category: +# +# * 0, well-separated, :math:`^{10}B^{+}`, :math:`^{28}Si^{2+}` +# * 1, close, but can be sufficiently separated for quantification in a LEAP system, :math:`^{94}Mo^{3+}`, :math:`^{63}Cu^{2+}` +# * 2, closely overlapping, demands better than LEAP4000X MRP can provide :math:`^{14}N^{+}`, :math:`^{28}Si^{2+}` at different charge states +# * 3, overlapped exactly due to multi-charge molecular species, :math:`^{16}{O_{2}}^{2+}`, :math:`^{16}O^{+}` +# * 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, :math:`^{14}{N_{2}}^{+}`, :math:`^{28}Si^{+}` +# * 5, overlapped, same charge state, any expectation of resolvability, :math:`^{54}Cr^{2+}`, :math:`^{54}Fe^{2+}` # # # @@ -2101,12 +2085,12 @@ NXapm(NXobject): # # # -# +# # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml index 59076b8ab9..3bef00468c 100644 --- a/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml +++ b/contributed_definitions/nyaml/NXapm_compositionspace_config.yaml @@ -18,11 +18,9 @@ NXapm_compositionspace_config(NXobject): exists: optional enumeration: [NXapm_compositionspace_config] config(NXobject): - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): doc: | Specification of the tomographic reconstruction used for this analysis. Typically, reconstructions in the field of atom probe tomography are communicated via @@ -46,7 +44,7 @@ NXapm_compositionspace_config(NXobject): doc: | Name of the node which resolves the mass-to-charge-state ratio values for each reconstructed ion to use for this analysis. - ranging(NXserialized): + ranging(NXnote): doc: | Specification of the ranging definitions used for this analysis. @@ -54,7 +52,7 @@ NXapm_compositionspace_config(NXobject): iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. type(NX_CHAR): exists: optional - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): exists: recommended algorithm(NX_CHAR): @@ -142,7 +140,7 @@ NXapm_compositionspace_config(NXobject): point. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d0ffab223e677c8a31e24131a440df7d606b28fd4e555def8eaf87570f3275ad +# b2999b7a1f4a3e8cedd9d811e64b9eda121c689ea42f8a688b6e676cb9a588c9 # # # # @@ -372,18 +378,17 @@ NXapm_compositionspace_results(NXobject): # # -# +# # # # # # -# # # -# +# # -# Configuration file that was used in this analysis. +# Configuration file that was used in this analysis. # # # @@ -394,13 +399,13 @@ NXapm_compositionspace_results(NXobject): # # # -# Step during which the point cloud is discretized to compute element-specific composition fields. -# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that -# was ranged for each ion. -# -# Using a discretization grid that is larger than the average distance between reconstructed ion positions -# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods -# used in atom probe for characterizing microstructural features using the ion position data directly. +# Step during which the point cloud is discretized to compute element-specific composition fields. +# Iontypes are atomically decomposed to correctly account for the multiplicity of each element that +# was ranged for each ion. +# +# Using a discretization grid that is larger than the average distance between reconstructed ion positions +# reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods +# used in atom probe for characterizing microstructural features using the ion position data directly. # # # @@ -437,7 +442,7 @@ NXapm_compositionspace_results(NXobject): # # # -# Position of each cell in Euclidean space. +# Position of each cell in Euclidean space. # # # @@ -446,7 +451,7 @@ NXapm_compositionspace_results(NXobject): # # # -# Discrete coordinate of each voxel. +# Discrete coordinate of each voxel. # # # @@ -456,7 +461,7 @@ NXapm_compositionspace_results(NXobject): # # # -# For each ion, the identifier of the voxel into which the ion binned. +# For each ion, the identifier of the voxel into which the ion binned. # # # @@ -465,23 +470,23 @@ NXapm_compositionspace_results(NXobject): # # # -# Total number of weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms. +# Total number of weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms. # # # # # -# +# # # -# Chemical symbol of the element from the periodic table. +# Chemical symbol of the element from the periodic table. # # # # -# Element-specific weight (counts for discretization with a rectangular transfer function) -# for the occupancy of each voxel with atoms of this element. +# Element-specific weight (counts for discretization with a rectangular transfer function) +# for the occupancy of each voxel with atoms of this element. # # # @@ -491,8 +496,8 @@ NXapm_compositionspace_results(NXobject): # # # -# Optional step during which the subsequent segmentation step is prepared to -# improve the segmentation. +# Optional step during which the subsequent segmentation step is prepared to +# improve the segmentation. # # # @@ -502,32 +507,32 @@ NXapm_compositionspace_results(NXobject): # # # -# +# # # # -# Element identifier stored sorted in descending order of feature importance. +# Element identifier stored sorted in descending order of feature importance. # # # # # # -# Axis caption +# Axis caption # # # # # -# Element relative feature importance stored sorted in descending order of feature -# importance. +# Element relative feature importance stored sorted in descending order of feature +# importance. # # # # # # -# Axis caption +# Axis caption # # # @@ -535,12 +540,12 @@ NXapm_compositionspace_results(NXobject): # # # -# Step during which the voxel set is segmented into voxel sets with different -# chemical composition. +# Step during which the voxel set is segmented into voxel sets with different +# chemical composition. # # # -# PCA in the chemical space (essentially composition correlation analyses). +# PCA in the chemical space (essentially composition correlation analyses). # # # @@ -551,11 +556,11 @@ NXapm_compositionspace_results(NXobject): # # # -# +# # # # -# Explained variance values +# Explained variance values # # # @@ -563,8 +568,8 @@ NXapm_compositionspace_results(NXobject): # # # -# Elements identifier matching those from ENTRY/voxelization/elementID as the -# principal component analysis. +# Elements identifier matching those from ENTRY/voxelization/elementID as the +# principal component analysis. # # # @@ -574,7 +579,7 @@ NXapm_compositionspace_results(NXobject): # # # -# Information criterion minimization. +# Information criterion minimization. # # # @@ -582,18 +587,18 @@ NXapm_compositionspace_results(NXobject): # # # -# +# # -# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. +# Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. # # # -# n_components argument of the Gaussian mixture model. +# n_components argument of the Gaussian mixture model. # # # # -# y_pred return values of the computation. +# y_pred return values of the computation. # # # @@ -602,15 +607,15 @@ NXapm_compositionspace_results(NXobject): # # # -# Information criterion as a function of number of n_ic_cluster aka dimensions. +# Information criterion as a function of number of n_ic_cluster aka dimensions. # # # -# +# # # # -# Akaike information criterion values +# Akaike information criterion values # # # @@ -618,7 +623,7 @@ NXapm_compositionspace_results(NXobject): # # # -# Bayes information criterion values +# Bayes information criterion values # # # @@ -626,7 +631,7 @@ NXapm_compositionspace_results(NXobject): # # # -# Actual n_ic_cluster values used +# Actual n_ic_cluster values used # # # @@ -637,9 +642,9 @@ NXapm_compositionspace_results(NXobject): # # # -# Step during which the chemically segmented voxel sets are analyzed for their spatial organization -# into different spatial clusters of voxels in the same chemical set but representing individual object -# not-necessarily watertight or topologically closed objects built from individual voxels. +# Step during which the chemically segmented voxel sets are analyzed for their spatial organization +# into different spatial clusters of voxels in the same chemical set but representing individual object +# not-necessarily watertight or topologically closed objects built from individual voxels. # # # @@ -649,25 +654,25 @@ NXapm_compositionspace_results(NXobject): # # # -# Respective DBScan clustering result for each segmentation/ic_opt case. +# Respective DBScan clustering result for each segmentation/ic_opt case. # -# -# +# +# # # -# The maximum distance between voxel pairs in a neighborhood to be considered -# connected. +# The maximum distance between voxel pairs in a neighborhood to be considered +# connected. # # # # -# The number of voxels in a neighborhood for a voxel to be considered as a core -# point. +# The number of voxels in a neighborhood for a voxel to be considered as a core +# point. # # # # -# Raw label return values +# Raw label return values # # # @@ -675,10 +680,10 @@ NXapm_compositionspace_results(NXobject): # # # -# Voxel identifier -# -# Using these identifiers correlated element-wise with the values in the label array -# specifies for which voxel in the grid clusters from this process were found. +# Voxel identifier +# +# Using these identifiers correlated element-wise with the values in the label array +# specifies for which voxel in the grid clusters from this process were found. # # # diff --git a/contributed_definitions/nyaml/NXapm_hit_finding.yaml b/contributed_definitions/nyaml/NXapm_hit_finding.yaml index fb814f3127..d5e1aae004 100644 --- a/contributed_definitions/nyaml/NXapm_hit_finding.yaml +++ b/contributed_definitions/nyaml/NXapm_hit_finding.yaml @@ -16,7 +16,7 @@ symbols: type: group NXapm_hit_finding(NXprocess): (NXprogram): - (NXserialized): + (NXnote): # config/input number_of_dld_wires(NX_UINT): @@ -95,7 +95,7 @@ NXapm_hit_finding(NXprocess): # dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bec0a5a7871a2b42d592c5b879be13a52f2de4be073d3375187bbfde74269800 +# 124bb8d4281124d8582d2e7258e8f5c1e66a41f0a3878d15ca1070f268a1754f # # # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml index 612b862b84..35837a3efa 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_config.yaml @@ -35,14 +35,14 @@ NXapm_paraprobe_clusterer_config(NXobject): These labels are reported via the mass-to-charge-state-ratio column of what is effectively a binary file that is formatted like a POS file but cluster labels written out using floating point numbers. - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - results(NXserialized): + results(NXnote): doc: | File with the results of the cluster analyses that was computed with IVAS / AP suite (e.g. maximum-separation method clustering algorithm `J. Hyde et al. `_). @@ -57,7 +57,7 @@ NXapm_paraprobe_clusterer_config(NXobject): recover_evaporation_id(NX_BOOLEAN): doc: | Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction - for recovering for each position in the :ref:`NXserialized` results the closest matching position + for recovering for each position in the :ref:`NXnote` results the closest matching position (within floating point accuracy). This can be useful when users wish to recover the original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster results POS files that is referred to results. @@ -70,24 +70,25 @@ NXapm_paraprobe_clusterer_config(NXobject): # by the IVAS/APSuite cluster analysis. This can be useful to recover # the region of interest. cluster_analysisID(NXapm_paraprobe_tool_config): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | This process performs a cluster analysis on a reconstructed dataset or a ROI within it. - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - surface_distance(NXserialized): + surface_distance(NXnote): exists: optional doc: | Distance between each ion and triangulated surface mesh. @@ -304,6 +305,7 @@ NXapm_paraprobe_clusterer_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -315,7 +317,7 @@ NXapm_paraprobe_clusterer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 16df6da8b0a00ca4b5e2c35d8abe6946e8bff5bb5ef936f8e4f141e5fc08871e +# 7656aee2c9515f245a9b1031f90c7b2fbe6ccb25dda2c15c7cff115491ba1241 # # # -# +# # # This process performs a cluster analysis on a # reconstructed dataset or a ROI within it. # -# +# # # # @@ -440,14 +442,14 @@ NXapm_paraprobe_clusterer_config(NXobject): # # # -# +# # # # # # # -# +# # # Distance between each ion and triangulated surface mesh. # @@ -686,7 +688,7 @@ NXapm_paraprobe_clusterer_config(NXobject): # e.g. https://doi.org/10.1017/S1431927607070900--> # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml index 1ef45778c4..6da1156d16 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_clusterer_results.yaml @@ -22,9 +22,10 @@ NXapm_paraprobe_clusterer_results(NXobject): cameca_to_nexus(NXapm_paraprobe_tool_results): exists: optional cluster_analysisID(NXapm_paraprobe_tool_results): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -36,6 +37,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # results dbscanID(NXsimilarity_grouping): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Results of a DBScan clustering analysis. @@ -206,6 +208,7 @@ NXapm_paraprobe_clusterer_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -219,6 +222,7 @@ NXapm_paraprobe_clusterer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -245,7 +249,7 @@ NXapm_paraprobe_clusterer_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 447d86a2f94e6d0402ea74b596714bbf16975c8f3f287caa1f03370a10c520c8 +# f0d2a3b775506ce776c5ba85c979c19cc9f0c2a2dbe2111a51925b709404bd15 # # # # -# +# # -# +# # # # @@ -313,7 +317,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# +# # # Results of a DBScan clustering analysis. # @@ -501,7 +505,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# +# # # # @@ -515,7 +519,7 @@ NXapm_paraprobe_clusterer_results(NXobject): # # # -# +# # # If used, metadata of at least the person who performed this analysis. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml index 0eaeb2760e..a69c2a6ebb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_config.yaml @@ -15,18 +15,16 @@ NXapm_paraprobe_distancer_config(NXobject): enumeration: [NXapm_paraprobe_distancer_config] point_to_triangle(NXapm_paraprobe_tool_config): exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -108,7 +106,8 @@ NXapm_paraprobe_distancer_config(NXobject): How many triangle sets to consider. Multiple triangle sets can be defined which are composed into one joint triangle set for the analysis. - triangle_setID(NXserialized): + triangle_setID(NXnote): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Each triangle_set that is referred to here should be a face_list_data_structure, @@ -152,6 +151,7 @@ NXapm_paraprobe_distancer_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -163,7 +163,7 @@ NXapm_paraprobe_distancer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c85cd158ccd3997a074b80e5117d12e082d6ccd032fa8ad688830d283d92a1e9 +# c1544b4249ed356b23729a485c3e97821d9ca9e23ba820e3087fa21808102968 # # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml index bb84efa38c..38e2111ebb 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_distancer_results.yaml @@ -34,7 +34,7 @@ NXapm_paraprobe_distancer_results(NXobject): # config analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -120,6 +120,7 @@ NXapm_paraprobe_distancer_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -133,6 +134,7 @@ NXapm_paraprobe_distancer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -159,7 +161,7 @@ NXapm_paraprobe_distancer_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 70f1a3b11743d224cf01a30485e9bf01833648af2006cfadd682bee15c2b40b4 +# bef80e6c3fe3caf6acb28bb08f52213e2c5e92c644b59cd563ca98d047e60eaf # # # # -# +# # # # @@ -239,8 +241,8 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# The shortest analytical distance of each point to their -# respectively closest triangle from the joint triangle set. +# The shortest analytical distance of each point to their +# respectively closest triangle from the joint triangle set. # # # @@ -248,8 +250,8 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# For each point the identifier of the triangle for which the -# shortest distance was found +# For each point the identifier of the triangle for which the +# shortest distance was found # # # @@ -257,10 +259,10 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# A support field to enable the visualization of each point -# by an explicit identifier on the interval [0, n_ions - 1]. -# The field can be used to visualize the points as a function -# of their distance to the triangle set (e.g. via XDMF/Paraview). +# A support field to enable the visualization of each point +# by an explicit identifier on the interval [0, n_ions - 1]. +# The field can be used to visualize the points as a function +# of their distance to the triangle set (e.g. via XDMF/Paraview). # # # @@ -268,30 +270,30 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# A bitmask that identifies which of the distance values is -# assumed to have a consistent sign because the closest -# triangle had a consistent outer unit normal defined. -# -# For points whose bit is set to 0 the distance is correct -# but the sign is not reliable. +# A bitmask that identifies which of the distance values is +# assumed to have a consistent sign because the closest +# triangle had a consistent outer unit normal defined. +# +# For points whose bit is set to 0 the distance is correct +# but the sign is not reliable. # # # -# Number of triangles covered by the mask. +# Number of triangles covered by the mask. # # # # -# Bitdepth of the elementary datatype that is used to store -# the information content of the mask (typically 8 bit, uint8). +# Bitdepth of the elementary datatype that is used to store +# the information content of the mask (typically 8 bit, uint8). # # # # -# The content of the mask. Like for all masks used in the tools -# of the paraprobe-toolbox, padding is used when number_of_objects -# is not an integer multiple of bitdepth. If padding is used, -# padded bits are set to 0. +# The content of the mask. Like for all masks used in the tools +# of the paraprobe-toolbox, padding is used when number_of_objects +# is not an integer multiple of bitdepth. If padding is used, +# padded bits are set to 0. # # # @@ -300,8 +302,8 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# A bitmask that identifies which of the triangles in the set were -# considered when certain triangles have been filtered out. +# A bitmask that identifies which of the triangles in the set were +# considered when certain triangles have been filtered out. # # # @@ -318,7 +320,7 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# +# # # # @@ -332,9 +334,9 @@ NXapm_paraprobe_distancer_results(NXobject): # # # -# +# # -# If used, metadata of at least the person who performed this analysis. +# If used, metadata of at least the person who performed this analysis. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml index 05b00e7381..8e7ad4dfac 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_config.yaml @@ -20,6 +20,7 @@ NXapm_paraprobe_intersector_config(NXobject): doc: | How many v_v_spatial_correlation tasks should the tool execute. v_v_spatial_correlationID(NXapm_paraprobe_tool_config): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Tracking volume_volume_spatial_correlations (v_v) is the process of building logical @@ -107,7 +108,8 @@ NXapm_paraprobe_intersector_config(NXobject): So while these four sub-sets contain different so-called types of features, key is that they were all generated for one set, here the current_set. - featureID(NXserialized): + featureID(NXnote): + nameType: partial exists: ['min', '1', 'max', '4'] doc: | Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the @@ -163,7 +165,8 @@ NXapm_paraprobe_intersector_config(NXobject): So while these four sub-sets contain different so-called types of features key is that they were all generated for one set, here the next_set. - featureID(NXserialized): + featureID(NXnote): + nameType: partial exists: ['min', '1', 'max', '4'] feature_type(NX_CHAR): doc: | @@ -188,12 +191,13 @@ NXapm_paraprobe_intersector_config(NXobject): rank: 1 dim: (n_variable,) - #MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features + # MK::tetrahedra volume intersection and tessellation and Nef polyhedra intersection are considered guru features # and therefore currently supported only via modifying the C/C++ source code directly as one should know exactly # what one is doing here before using these functionalities common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -205,7 +209,7 @@ NXapm_paraprobe_intersector_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cb54404dbeb54c981015ce5ca524a5b016e44e995fef87407b11c4b11d7c6e61 +# be96bcc2e250fefbab6f1049369a6eeb9570d38a27c81c1309ec4190236e8cd4 # # # # # -# Specifies the method whereby to decide if two objects intersect volumetrically. -# For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, -# it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). -# -# Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to -# tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra -# to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner -# cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. -# These cases were virtually always associated with complicated non-convex polyhedra which had portions -# of the mesh that were connected by almost point like tubes of triangles. -# -# Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve -# the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron -# intersections in paraprobe-intersector. +# Specifies the method whereby to decide if two objects intersect volumetrically. +# For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, +# it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). +# +# Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to +# tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra +# to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner +# cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. +# These cases were virtually always associated with complicated non-convex polyhedra which had portions +# of the mesh that were connected by almost point like tubes of triangles. +# +# Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve +# the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron +# intersections in paraprobe-intersector. # # # @@ -293,81 +297,81 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# Specifies if the tool evaluates if objects intersect volumetrically. +# Specifies if the tool evaluates if objects intersect volumetrically. # # # # -# Specifies if the tool evaluates if objects lay closer to one another than -# threshold_proximity. +# Specifies if the tool evaluates if objects lay closer to one another than +# threshold_proximity. # # # # -# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting -# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ -# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, -# duplet, triplet, or high-order local groups. +# Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting +# or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ +# for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, +# duplet, triplet, or high-order local groups. # # # # # -# The maximum Euclidean distance between two objects below which they are -# considered within proximity. +# The maximum Euclidean distance between two objects below which they are +# considered within proximity. # # # # -# Specifies if the tool stores the so-called forward relations between nodes representing members of the -# current_set to nodes representing members of the next_set. +# Specifies if the tool stores the so-called forward relations between nodes representing members of the +# current_set to nodes representing members of the next_set. # # # # -# Specifies if the tool stores the so-called backward relations between nodes representing members of the -# next_set to nodes representing members of the current_set. +# Specifies if the tool stores the so-called backward relations between nodes representing members of the +# next_set to nodes representing members of the current_set. # # # # -# Current set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the current_set. -# The meshes were generated as a result of some other meshing process. +# Current set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the current_set. +# The meshes were generated as a result of some other meshing process. # # # -# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). # # # # # -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features, key is that they were all generated for one set, here the -# current_set. +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features, key is that they were all generated for one set, here the +# current_set. # # -# +# # -# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the -# members of the set as instances of NXcg_polyhedron_set. +# Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the +# members of the set as instances of NXcg_polyhedron_set. # # # -# Descriptive category explaining what these features are. +# Descriptive category explaining what these features are. # # # @@ -383,15 +387,15 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. # # # # # -# Array of identifier whereby the path to the geometry data can be interferred -# automatically. +# Array of identifier whereby the path to the geometry data can be interferred +# automatically. # # # @@ -401,39 +405,39 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# Next set stores a set of members, meshes of volumetric features, -# which will be checked for proximity and/or volumetric intersection, -# to members of the next_set. -# The meshes were generated as a result of some other meshing process. +# Next set stores a set of members, meshes of volumetric features, +# which will be checked for proximity and/or volumetric intersection, +# to members of the next_set. +# The meshes were generated as a result of some other meshing process. # # # -# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) -# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). +# This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) +# step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). # # # # # -# The total number of distinguished feature sets featureID. -# It is assumed that the members within all these featureID sets -# are representing a set together. As an example this set might represent -# all volumetric_features. However, users might have formed -# a subset of this set where individuals were regrouped. -# For paraprobe-nanochem this is the case for objects and proxies. -# Specifically, objects are distinguished further into those far -# from and those close to the edge of the dataset. -# Similarly, proxies are distinguished further into those far -# from and those close to the edge of the dataset. -# So while these four sub-sets contain different so-called types of -# features key is that they were all generated for one set, here the -# next_set. +# The total number of distinguished feature sets featureID. +# It is assumed that the members within all these featureID sets +# are representing a set together. As an example this set might represent +# all volumetric_features. However, users might have formed +# a subset of this set where individuals were regrouped. +# For paraprobe-nanochem this is the case for objects and proxies. +# Specifically, objects are distinguished further into those far +# from and those close to the edge of the dataset. +# Similarly, proxies are distinguished further into those far +# from and those close to the edge of the dataset. +# So while these four sub-sets contain different so-called types of +# features key is that they were all generated for one set, here the +# next_set. # # -# +# # # -# Descriptive category explaining what these features are. +# Descriptive category explaining what these features are. # # # @@ -448,15 +452,15 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# Absolute path to the group with geometry data in the HDF5 file referred to by -# path. +# Absolute path to the group with geometry data in the HDF5 file referred to by +# path. # # # # # -# Array of identifier whereby the path to the geometry data can be interferred -# automatically. +# Array of identifier whereby the path to the geometry data can be interferred +# automatically. # # # @@ -465,12 +469,12 @@ NXapm_paraprobe_intersector_config(NXobject): # # # -# # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml index 9199a690a1..b217ccdf5a 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_intersector_results.yaml @@ -165,12 +165,13 @@ NXapm_paraprobe_intersector_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): - path(NX_CHAR): + partial(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -184,6 +185,7 @@ NXapm_paraprobe_intersector_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -210,7 +212,7 @@ NXapm_paraprobe_intersector_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6d0a5d000834beb48642b287c4212f106f90d348fd381d00034aacdfbfd0272c +# 3b33823b0b411bedd74d076a7f484f3fd20aa46753f68d1e2fb37a89e0784140 # # # -# # -# +# # # # @@ -970,14 +964,14 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # # # # # -# +# # # A precomputed triangulated surface mesh representing a model (of the surface) # of the edge of the dataset. This model can be used to detect and control @@ -1000,7 +994,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # Distance between each ion and triangulated surface mesh. # @@ -1068,7 +1062,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # Serialized result of an already computed delocalization which is for performance # reasons here just loaded and not computed again. @@ -1424,9 +1418,8 @@ NXapm_paraprobe_nanochem_config(NXobject): # paraprobe-nanochem uses inspection functionalities which detect potential geometric # inconsistencies or self-interactions of the evolved DCOM mesh. # -# # -# +# # # # @@ -1434,14 +1427,14 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # # # # # -# +# # # A precomputed triangulated surface mesh representing a model (of the surface) # of the edge of the dataset. This model can be used to detect and control @@ -1531,7 +1524,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # Details about the control point file used. # @@ -1653,9 +1646,8 @@ NXapm_paraprobe_nanochem_config(NXobject): # intersection of triangles and convex polyhedra is a robust but currently # not implemented method to quantify intersections. # -# # -# +# # # # @@ -1663,14 +1655,14 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # # # # # -# +# # # A precomputed triangulated surface mesh representing a model (of the surface) # of the edge of the dataset. This model can be used to detect and control @@ -1693,7 +1685,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # Distance between each ion and triangulated surface mesh. # @@ -1709,7 +1701,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # A precomputed triangulated mesh of the feature representing a model of the # interface at which to place ROIs to profile. This can be the mesh of an @@ -1755,7 +1747,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # To enable an additional filtration of specific parts of the feature # mesh it is recommended to feed precomputed distances of each ion to @@ -1888,7 +1880,7 @@ NXapm_paraprobe_nanochem_config(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml index 1eea65e91b..71dd323863 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_nanochem_results.yaml @@ -41,6 +41,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # tasks delocalizationID(NXdelocalization): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): @@ -237,8 +238,9 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (6,) - #MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? + # MK::how to avoid storing it for once in NeXus for H5Web and for XDMF in ParaView ? scalar_field_magn_SUFFIX(NXdata): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces @@ -313,6 +315,7 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (i,) scalar_field_grad_SUFFIX(NXdata): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | The three-dimensional gradient :math:`\nabla \Phi`. @@ -379,8 +382,9 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (i,) - #MK:: + # MK:: iso_surfaceID(NXisocontour): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | An iso-surface is the boundary between two regions across which the magnitude of a @@ -717,8 +721,8 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 2 dim: (k, 3) - #MK::again we have no effective way to pinpoint the n_rows - #MK::namely k != i each OBB has eight vertices + # MK::again we have no effective way to pinpoint the n_rows + # MK::namely k != i each OBB has eight vertices xdmf_topology(NX_UINT): unit: NX_UNITLESS dimensions: @@ -730,6 +734,7 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (k,) objectID(NXcg_polyhedron_set): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] polyhedron(NXcg_face_list_data_structure): @@ -784,6 +789,7 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (i,) ionID(NXion): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] charge_state(NX_INT): @@ -844,6 +850,7 @@ NXapm_paraprobe_nanochem_results(NXobject): rank: 1 dim: (4,) mesh_stateID(NXcg_triangle_set): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | The triangle surface mesh representing the interface model. @@ -1035,6 +1042,7 @@ NXapm_paraprobe_nanochem_results(NXobject): if all ions are built from a single atom only. roiID(NXobject): exists: ['min', '0', 'max', 'unbounded'] + nameType: partial signed_distance(NX_FLOAT): unit: NX_LENGTH doc: | @@ -1053,12 +1061,13 @@ NXapm_paraprobe_nanochem_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -1072,6 +1081,7 @@ NXapm_paraprobe_nanochem_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -1098,7 +1108,7 @@ NXapm_paraprobe_nanochem_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4858408cb02f5fdf531f6a9269dee0449e6d3d51f156a6caf4216f1ccff426b6 +# cc84efcb4713ea73b25baac2d30ecde427d5f18a73459cc2838797e159a6239a # # # # # -# The total number of faces of triangles. +# The total number of faces of triangles. # # # # -# The total number of XDMF values to represent all faces of triangles via XDMF. +# The total number of XDMF values to represent all faces of triangles via XDMF. # # # # -# The total number of entries in a feature dictionary. +# The total number of entries in a feature dictionary. # # # # -# The total number of volumetric features. +# The total number of volumetric features. # # # # -# The total number of member distinguished when reporting composition. +# The total number of member distinguished when reporting composition. # # # # -# The total number of ROIs placed in an oned_profile task. +# The total number of ROIs placed in an oned_profile task. # # # # -# Application definition for results files of the paraprobe-nanochem tool. -# -# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. +# Application definition for results files of the paraprobe-nanochem tool. +# +# This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. # # # @@ -1198,7 +1208,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # @@ -1212,11 +1222,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# How were results of the kernel-density estimation normalized: -# * total, the total number (intensity) of ions or elements. -# * candidates, the total number (intensity) of ions matching weighting_model -# * composition, the value for candidates divided by the value for total, -# * concentration, the value for candidates divided by the volume of the cell. +# How were results of the kernel-density estimation normalized: +# * total, the total number (intensity) of ions or elements. +# * candidates, the total number (intensity) of ions matching weighting_model +# * composition, the value for candidates divided by the value for total, +# * concentration, the value for candidates divided by the volume of the cell. # # # @@ -1227,7 +1237,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The discretized domain/grid on which the delocalization is applied. +# The discretized domain/grid on which the delocalization is applied. # # # @@ -1238,7 +1248,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The total number of cells/voxels of the grid. +# The total number of cells/voxels of the grid. # # # @@ -1248,7 +1258,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The symmetry of the lattice defining the shape of the unit cell. +# The symmetry of the lattice defining the shape of the unit cell. # # # @@ -1256,8 +1266,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The unit cell dimensions according to the coordinate system defined under -# coordinate_system. +# The unit cell dimensions according to the coordinate system defined under +# coordinate_system. # # # @@ -1265,12 +1275,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Number of unit cells along each of the d-dimensional base vectors. -# The total number of cells, or grid points has to be the cardinality. -# If the grid has an irregular number of grid positions in each direction, -# as it could be for instance the case of a grid where all grid points -# outside some masking primitive are removed, this extent field should -# not be used. Instead use the coordinate field. +# Number of unit cells along each of the d-dimensional base vectors. +# The total number of cells, or grid points has to be the cardinality. +# If the grid has an irregular number of grid positions in each direction, +# as it could be for instance the case of a grid where all grid points +# outside some masking primitive are removed, this extent field should +# not be used. Instead use the coordinate field. # # # @@ -1279,17 +1289,17 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Integer which specifies the first index to be used for distinguishing identifiers for cells. -# Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are -# defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. +# Integer which specifies the first index to be used for distinguishing identifiers for cells. +# Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are +# defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# For explicit indexing the identifier array has to be defined. # # # # -# Halfwidth of the kernel about the central voxel. -# The shape of the kernel is that of a cuboid -# of extent 2*kernel_extent[i] + 1 in each dimension i. +# Halfwidth of the kernel about the central voxel. +# The shape of the kernel is that of a cuboid +# of extent 2*kernel_extent[i] + 1 in each dimension i. # # # @@ -1297,7 +1307,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Functional form of the kernel (Ansatz function). +# Functional form of the kernel (Ansatz function). # # # @@ -1305,8 +1315,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Standard deviation :math:`\sigma_i` of the kernel in each dimension -# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# Standard deviation :math:`\sigma_i` of the kernel in each dimension +# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. # # # @@ -1314,8 +1324,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Expectation value :math:`\mu_i` of the kernel in each dimension -# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. +# Expectation value :math:`\mu_i` of the kernel in each dimension +# in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. # # # @@ -1323,51 +1333,51 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# A tight axis-aligned bounding box about the grid. +# A tight axis-aligned bounding box about the grid. # # # -# For atom probe should be set to true. +# For atom probe should be set to true. # # # # -# Integer which specifies the first index to be used for distinguishing -# hexahedra. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. -# For explicit indexing the identifier array has to be defined. +# Integer which specifies the first index to be used for distinguishing +# hexahedra. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# For explicit indexing the identifier array has to be defined. # # # # # -# Integer which specifies the first index to be used for distinguishing -# identifiers for vertices. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array -# has to be defined. +# Integer which specifies the first index to be used for distinguishing +# identifiers for vertices. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array +# has to be defined. # # # # -# Integer which specifies the first index to be used for distinguishing -# identifiers for faces. Identifiers are defined either implicitly or explicitly. -# For implicit indexing the identifiers are defined on the interval -# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array -# has to be defined. +# Integer which specifies the first index to be used for distinguishing +# identifiers for faces. Identifiers are defined either implicitly or explicitly. +# For implicit indexing the identifiers are defined on the interval +# :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array +# has to be defined. # # # # -# Positions of the vertices. -# Users are encouraged to reduce the vertices to unique set of positions -# and vertices as this supports a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. -# Naively here means that one for example stores each vertex of a triangle -# mesh even though many vertices are shared between triangles and thus -# the positions of these vertices do not have to be duplicated. +# Positions of the vertices. +# Users are encouraged to reduce the vertices to unique set of positions +# and vertices as this supports a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. +# Naively here means that one for example stores each vertex of a triangle +# mesh even though many vertices are shared between triangles and thus +# the positions of these vertices do not have to be duplicated. # # # @@ -1376,16 +1386,16 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. # # # @@ -1394,10 +1404,10 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Six equally formatted sextets chained together. For each sextett the first entry is an -# XDMF primitive topology key (here 5 for polygon), the second entry the XDMF -# primitive count value (here 4 because each face is a quad). -# The remaining four values are the vertex indices. +# Six equally formatted sextets chained together. For each sextett the first entry is an +# XDMF primitive topology key (here 5 for polygon), the second entry the XDMF +# primitive count value (here 4 because each face is a quad). +# The remaining four values are the vertex indices. # # # @@ -1405,15 +1415,15 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# How many distinct boundaries are distinguished? -# Most grids discretize a cubic or cuboidal region. In this case -# six sides can be distinguished, each making an own boundary. +# How many distinct boundaries are distinguished? +# Most grids discretize a cubic or cuboidal region. In this case +# six sides can be distinguished, each making an own boundary. # # # # -# Name of the boundaries. E.g. left, right, front, back, bottom, top, -# The field must have as many entries as there are number_of_boundaries. +# Name of the boundaries. E.g. left, right, front, back, bottom, top, +# The field must have as many entries as there are number_of_boundaries. # # # @@ -1421,14 +1431,14 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The boundary conditions for each boundary: -# -# 0 - undefined -# 1 - open -# 2 - periodic -# 3 - mirror -# 4 - von Neumann -# 5 - Dirichlet +# The boundary conditions for each boundary: +# +# 0 - undefined +# 1 - open +# 2 - periodic +# 3 - mirror +# 4 - von Neumann +# 5 - Dirichlet # # # @@ -1436,20 +1446,20 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# -# +# +# # -# The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces -# will be computed. In commercial software so far there is no possibility to export this information. -# -# If the intensity for all matches of the weighting_model are summarized name this NXdata instance -# scalar_field_magn_total. -# -# If the intensity is reported for each iontype one can avoid many subsequent -# computations as individual intensities can be reinterpreted using a different weighting_model in -# down-stream usage of the here reported values (e.g. with Python scripting). -# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as -# per the configuration of the ranging definitions used. +# The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces +# will be computed. In commercial software so far there is no possibility to export this information. +# +# If the intensity for all matches of the weighting_model are summarized name this NXdata instance +# scalar_field_magn_total. +# +# If the intensity is reported for each iontype one can avoid many subsequent +# computations as individual intensities can be reinterpreted using a different weighting_model in +# down-stream usage of the here reported values (e.g. with Python scripting). +# In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as +# per the configuration of the ranging definitions used. # # # @@ -1459,7 +1469,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The actual delocalized intensity values. +# The actual delocalized intensity values. # # # @@ -1469,7 +1479,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along x. +# Cell center of mass positions along x. # # # @@ -1477,7 +1487,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along y. +# Cell center of mass positions along y. # # # @@ -1485,7 +1495,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along z. +# Cell center of mass positions along z. # # # @@ -1493,7 +1503,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Intensity of the field at given point +# Intensity of the field at given point # # # @@ -1501,8 +1511,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Center of mass positions of each voxel for rendering the scalar field -# via XDMF in e.g. Paraview. +# Center of mass positions of each voxel for rendering the scalar field +# via XDMF in e.g. Paraview. # # # @@ -1511,18 +1521,18 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF topology for rendering in combination with xdmf_xyz the scalar field -# via XDMF in e.g. Paraview. +# XDMF topology for rendering in combination with xdmf_xyz the scalar field +# via XDMF in e.g. Paraview. # # # # # # -# +# # -# The three-dimensional gradient :math:`\nabla \Phi`. -# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. +# The three-dimensional gradient :math:`\nabla \Phi`. +# Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. # # # @@ -1532,7 +1542,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The actual point-wise component values. +# The actual point-wise component values. # # # @@ -1543,7 +1553,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along x. +# Cell center of mass positions along x. # # # @@ -1551,7 +1561,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along y. +# Cell center of mass positions along y. # # # @@ -1559,7 +1569,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Cell center of mass positions along z. +# Cell center of mass positions along z. # # # @@ -1567,8 +1577,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The gradient vector formatted for direct visualization via XDMF in e.g. -# Paraview. +# The gradient vector formatted for direct visualization via XDMF in e.g. +# Paraview. # # # @@ -1577,8 +1587,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Center of mass positions of each voxel for rendering the scalar field gradient -# via XDMF in e.g. Paraview. +# Center of mass positions of each voxel for rendering the scalar field gradient +# via XDMF in e.g. Paraview. # # # @@ -1587,58 +1597,58 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF topology for rendering in combination with xdmf_xyz the scalar field -# via XDFM in e.g. Paraview. +# XDMF topology for rendering in combination with xdmf_xyz the scalar field +# via XDFM in e.g. Paraview. # # # # # # -# -# +# +# # -# An iso-surface is the boundary between two regions across which the magnitude of a -# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. -# -# For applications in atom probe microscopy, the location and shape of such a boundary (set) -# is typically approximated by discretization - triangulation to be specific. -# -# This yields a complex of not necessarily connected geometric primitives. -# Paraprobe-nanochem approximates this complex with a soup of triangles. +# An iso-surface is the boundary between two regions across which the magnitude of a +# scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. +# +# For applications in atom probe microscopy, the location and shape of such a boundary (set) +# is typically approximated by discretization - triangulation to be specific. +# +# This yields a complex of not necessarily connected geometric primitives. +# Paraprobe-nanochem approximates this complex with a soup of triangles. # # # # -# The threshold or iso-contour value :math:`\varphi`. +# The threshold or iso-contour value :math:`\varphi`. # # # # -# Details about the specific marching cubes algorithm that was used for computing -# the iso-surface. +# Details about the specific marching cubes algorithm that was used for computing +# the iso-surface. # # # -# Reference to the specific implementation of marching cubes used. -# The value placed here should be a DOI. If there are no specific -# DOI or details write not_further_specified, or give at least a -# free-text description. The program and version used is the -# specific paraprobe-nanochem. +# Reference to the specific implementation of marching cubes used. +# The value placed here should be a DOI. If there are no specific +# DOI or details write not_further_specified, or give at least a +# free-text description. The program and version used is the +# specific paraprobe-nanochem. # # # # # -# The resulting triangle soup computed via marching cubes. +# The resulting triangle soup computed via marching cubes. # # # # # -# Integer which specifies the first index to be used for distinguishing triangles. -# Identifiers are defined either implicitly or explicitly. For implicit indexing the -# identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. +# Integer which specifies the first index to be used for distinguishing triangles. +# Identifiers are defined either implicitly or explicitly. For implicit indexing the +# identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. # # # @@ -1648,13 +1658,13 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Positions of the vertices. -# -# Users are encouraged to reduce the vertices to a unique set as this may -# result in a more efficient storage of the geometry data. -# It is also possible though to store the vertex positions naively in which -# case vertices_are_unique is likely False. Naively here means that each -# vertex is stored even though many share the same positions. +# Positions of the vertices. +# +# Users are encouraged to reduce the vertices to a unique set as this may +# result in a more efficient storage of the geometry data. +# It is also possible though to store the vertex positions naively in which +# case vertices_are_unique is likely False. Naively here means that each +# vertex is stored even though many share the same positions. # # # @@ -1663,16 +1673,16 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of identifiers from vertices which describe each face. -# -# The first entry is the identifier of the start vertex of the first face, -# followed by the second vertex of the first face, until the last vertex -# of the first face. Thereafter, the start vertex of the second face, the -# second vertex of the second face, and so on and so forth. -# -# Therefore, summating over the number_of_vertices, allows to extract -# the vertex identifiers for the i-th face on the following index interval -# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. +# Array of identifiers from vertices which describe each face. +# +# The first entry is the identifier of the start vertex of the first face, +# followed by the second vertex of the first face, until the last vertex +# of the first face. Thereafter, the start vertex of the second face, the +# second vertex of the second face, and so on and so forth. +# +# Therefore, summating over the number_of_vertices, allows to extract +# the vertex identifiers for the i-th face on the following index interval +# of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. # # # @@ -1680,9 +1690,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). # # # @@ -1691,7 +1701,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Direction of each normal. +# Direction of each normal. # # # @@ -1700,12 +1710,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner # # # @@ -1713,11 +1723,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # +# exists: optional--> # # # -# Direction of each normal. +# Direction of each normal. # # # @@ -1726,12 +1736,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Qualifier how which specifically oriented normal to its -# primitive each normal represents. -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner +# Qualifier how which specifically oriented normal to its +# primitive each normal represents. +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner # # # @@ -1739,32 +1749,32 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. # # # # # # +# doc: | +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# Sum of squared values of cross product of triangle normal +# construction. +# unit: NX_ANY +# dim: (k,)--> # # -# Triangle normals are oriented in the direction of the -# gradient vector of the local delocalized scalar field. -# The projection variable here describes the cosine of the -# angle between the gradient direction and the normal -# direction vector. -# This is a descriptor of how parallel the projection is -# that is especially useful to document those triangles -# for whose the projection is almost perpendicular. +# Triangle normals are oriented in the direction of the +# gradient vector of the local delocalized scalar field. +# The projection variable here describes the cosine of the +# angle between the gradient direction and the normal +# direction vector. +# This is a descriptor of how parallel the projection is +# that is especially useful to document those triangles +# for whose the projection is almost perpendicular. # # # @@ -1778,9 +1788,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of edge length values. For each triangle the edge length -# is reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. +# Array of edge length values. For each triangle the edge length +# is reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. # # # @@ -1789,10 +1799,10 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of interior angle values. For each triangle the angle -# is reported for the angle opposite to the edges which are -# traversed according to the sequence in which vertices -# are indexed in triangles. +# Array of interior angle values. For each triangle the angle +# is reported for the angle opposite to the edges which are +# traversed according to the sequence in which vertices +# are indexed in triangles. # # # @@ -1801,7 +1811,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The center of mass of each triangle. +# The center of mass of each triangle. # # # @@ -1810,36 +1820,36 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. -# Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a -# connectivity analysis on the triangle soup representation of such iso-surface. -# This may yield a set of connected features whose individual surfaces are discretized -# by a triangulated mesh each. Such volumetric features can be processed further using -# paraprobe-nanochem using a workflow with at most two steps. -# -# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: -# -# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. -# These objects were already watertight within the triangulated iso-surface. -# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated -# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh -# processing operations (hole filling, refinement, fairing operations). -# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality -# that are not transformable into proxies or for which no transformation into proxies was -# instructed. -# -# These features can be interpreted as microstructural features. Some of them may be precipitates, -# some of them may be poles, some of them may be segments of dislocation lines or other -# crystal defects which are decorated (or not) with solutes. -# -# In the second step, the tool can be used to analyze the proximity of these objects to a -# model of the surface (edge) of the dataset. +# Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. +# Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a +# connectivity analysis on the triangle soup representation of such iso-surface. +# This may yield a set of connected features whose individual surfaces are discretized +# by a triangulated mesh each. Such volumetric features can be processed further using +# paraprobe-nanochem using a workflow with at most two steps. +# +# In the first step, the tool distinguishes three types of (v) i.e. volumetric features: +# +# 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. +# These objects were already watertight within the triangulated iso-surface. +# 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated +# iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh +# processing operations (hole filling, refinement, fairing operations). +# 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality +# that are not transformable into proxies or for which no transformation into proxies was +# instructed. +# +# These features can be interpreted as microstructural features. Some of them may be precipitates, +# some of them may be poles, some of them may be segments of dislocation lines or other +# crystal defects which are decorated (or not) with solutes. +# +# In the second step, the tool can be used to analyze the proximity of these objects to a +# model of the surface (edge) of the dataset. # # # -# The identifier which the triangle_soup connectivity analysis -# returned, which constitutes the first step of the -# volumetric_feature identification process. +# The identifier which the triangle_soup connectivity analysis +# returned, which constitutes the first step of the +# volumetric_feature identification process. # # # @@ -1847,7 +1857,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The array of keywords of feature_type dictionary. +# The array of keywords of feature_type dictionary. # # # @@ -1855,8 +1865,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The array of values for each keyword of the -# feature_type dictionary. +# The array of values for each keyword of the +# feature_type dictionary. # # # @@ -1864,10 +1874,10 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The array of controlled keywords, need to be from -# feature_type_dict_keyword, which specify which type -# each feature triangle cluster belongs to. -# Keep in mind that not each feature is an object or proxy. +# The array of controlled keywords, need to be from +# feature_type_dict_keyword, which specify which type +# each feature triangle cluster belongs to. +# Keep in mind that not each feature is an object or proxy. # # # @@ -1875,7 +1885,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The explicit identifier of features. +# The explicit identifier of features. # # # @@ -1883,21 +1893,21 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# In all situations instances of the parent NXprocess group are returned with a very similar -# information structuring and thus we here replace the template name FEATURE -# with one of the following types feature-specific group names: -# -# * objects, objects, irrespective their distance to the surface -# * objects_close_to_edge, sub-set of v_feature_object close surface -# * objects_far_from_edge, sub-set of v_feature_object not close to the surface -# * proxies, proxies, irrespective their distance to the surface -# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface -# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface +# In all situations instances of the parent NXprocess group are returned with a very similar +# information structuring and thus we here replace the template name FEATURE +# with one of the following types feature-specific group names: +# +# * objects, objects, irrespective their distance to the surface +# * objects_close_to_edge, sub-set of v_feature_object close surface +# * objects_far_from_edge, sub-set of v_feature_object not close to the surface +# * proxies, proxies, irrespective their distance to the surface +# * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface +# * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface # # # -# Explicit identifier of the feature a sub-set of the feature_identifier in the -# parent group. +# Explicit identifier of the feature a sub-set of the feature_identifier in the +# parent group. # # # @@ -1905,7 +1915,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Volume of the feature. NaN for non-watertight objects. +# Volume of the feature. NaN for non-watertight objects. # # # @@ -1913,11 +1923,11 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# An oriented bounding box (OBB) to each object. +# An oriented bounding box (OBB) to each object. # # # -# Edge length of the oriented bounding box from largest to smallest value. +# Edge length of the oriented bounding box from largest to smallest value. # # # @@ -1926,8 +1936,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Oriented bounding box aspect ratio. -# YX versus ZY or second-largest over largest and smallest over second largest. +# Oriented bounding box aspect ratio. +# YX versus ZY or second-largest over largest and smallest over second largest. # # # @@ -1936,9 +1946,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Position of the geometric center, which often is but -# not necessarily has to be the center_of_mass of the -# hexahedrally-shaped sample/sample part. +# Position of the geometric center, which often is but +# not necessarily has to be the center_of_mass of the +# hexahedrally-shaped sample/sample part. # # # @@ -1947,8 +1957,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# A simple approach to describe the entire set of hexahedra when the main intention -# is to store the shape of the hexahedra for visualization. +# A simple approach to describe the entire set of hexahedra when the main intention +# is to store the shape of the hexahedra for visualization. # # # @@ -1956,8 +1966,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # @@ -1970,7 +1980,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # # # # -# Count or weight which, when divided by total, yields the composition of this element, -# nuclide, or (molecular) ion within the volume of the feature/object. +# Count or weight which, when divided by total, yields the composition of this element, +# nuclide, or (molecular) ion within the volume of the feature/object. # # # @@ -2057,16 +2067,16 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The multiplicity whereby the ion position is accounted for -# irrespective whether the ion is considered as a decorator -# of the interface or not. -# As an example, with atom probe it is typically not possible -# to resolve the positions of the atoms which arrive at the detector -# as molecular ions. Therefore, an exemplar molecular ion of two carbon -# atoms can be considered to have a multiplicity of two to account that -# this molecular ion contributes two carbon atoms at the reconstructed -# location considering that the spatial resolution of atom probe -# experiments is limited. +# The multiplicity whereby the ion position is accounted for +# irrespective whether the ion is considered as a decorator +# of the interface or not. +# As an example, with atom probe it is typically not possible +# to resolve the positions of the atoms which arrive at the detector +# as molecular ions. Therefore, an exemplar molecular ion of two carbon +# atoms can be considered to have a multiplicity of two to account that +# this molecular ion contributes two carbon atoms at the reconstructed +# location considering that the spatial resolution of atom probe +# experiments is limited. # # # @@ -2074,8 +2084,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The multiplicity whereby the ion position is accounted for when -# the ion is considered one which is a decorator of the interface. +# The multiplicity whereby the ion position is accounted for when +# the ion is considered one which is a decorator of the interface. # # # @@ -2083,25 +2093,25 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The equation of the plane that is fitted initially. +# The equation of the plane that is fitted initially. # # # -# The four parameter :math:`ax + by + cz + d = 0` which define the plane. +# The four parameter :math:`ax + by + cz + d = 0` which define the plane. # # # # # # -# +# # -# The triangle surface mesh representing the interface model. -# Exported at state before or after the next DCOM step. +# The triangle surface mesh representing the interface model. +# Exported at state before or after the next DCOM step. # # # -# Was this state exported before or after the next DCOM step. +# Was this state exported before or after the next DCOM step. # # # @@ -2131,7 +2141,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Direction of each vertex normal. +# Direction of each vertex normal. # # # @@ -2140,12 +2150,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner # # # @@ -2159,7 +2169,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Direction of each face normal. +# Direction of each face normal. # # # @@ -2168,12 +2178,12 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Qualifier which details how specifically oriented the -# face normal is with respect to its primitive (triangle): -# -# * 0 - undefined -# * 1 - outer -# * 2 - inner +# Qualifier which details how specifically oriented the +# face normal is with respect to its primitive (triangle): +# +# * 0 - undefined +# * 1 - outer +# * 2 - inner # # # @@ -2192,9 +2202,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of edge length values. For each triangle the edge length is -# reported for the edges traversed according to the sequence -# in which vertices are indexed in triangles. +# Array of edge length values. For each triangle the edge length is +# reported for the edges traversed according to the sequence +# in which vertices are indexed in triangles. # # # @@ -2203,9 +2213,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Array of interior angle values. For each triangle the angle is -# reported for the angle opposite to the edges which are traversed -# according to the sequence in which vertices are indexed in triangles. +# Array of interior angle values. For each triangle the angle is +# reported for the angle opposite to the edges which are traversed +# according to the sequence in which vertices are indexed in triangles. # # # @@ -2223,17 +2233,17 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The ROIs are defined as cylinders for the computations. To visualize these we discretize -# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, -# resolves the lateral surface of each cylinder such that their renditions are smooth in -# visualization software like Paraview. +# The ROIs are defined as cylinders for the computations. To visualize these we discretize +# them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, +# resolves the lateral surface of each cylinder such that their renditions are smooth in +# visualization software like Paraview. # # # # # -# Position of the geometric center, which often is but not -# necessarily has to be the center_of_mass of the polyhedra. +# Position of the geometric center, which often is but not +# necessarily has to be the center_of_mass of the polyhedra. # # # @@ -2242,8 +2252,8 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# The orientation of the ROI defined via a vector which points along -# the cylinder axis and whose length is the height of the cylinder. +# The orientation of the ROI defined via a vector which points along +# the cylinder axis and whose length is the height of the cylinder. # # # @@ -2253,7 +2263,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF support to enable colouring each ROI by its identifier. +# XDMF support to enable colouring each ROI by its identifier. # # # @@ -2261,7 +2271,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF support to enable colouring each ROI whether it has edge contact or not. +# XDMF support to enable colouring each ROI whether it has edge contact or not. # # # @@ -2269,7 +2279,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF support to enable colouring each ROI by its number of atoms. +# XDMF support to enable colouring each ROI by its number of atoms. # # # @@ -2277,7 +2287,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# XDMF support to enable colouring each ROI by its number of ions. +# XDMF support to enable colouring each ROI by its number of ions. # # # @@ -2285,22 +2295,22 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Distance and iontype-specific processed data for each ROI. -# Arrays signed_distance and nuclide_hash are sorted by increasing -# distance. -# Array nuclide_hash reports one hash for each atom of each isotope. -# Effectively, this can yield to groups of values on signed_distance -# with the same distance value as molecular ions are reported decomposed -# into their atoms. -# Therefore, the XDMF support fields number_of_atoms and number_of_ions -# are only expected to display pairwise the same values respectively, -# if all ions are built from a single atom only. +# Distance and iontype-specific processed data for each ROI. +# Arrays signed_distance and nuclide_hash are sorted by increasing +# distance. +# Array nuclide_hash reports one hash for each atom of each isotope. +# Effectively, this can yield to groups of values on signed_distance +# with the same distance value as molecular ions are reported decomposed +# into their atoms. +# Therefore, the XDMF support fields number_of_atoms and number_of_ions +# are only expected to display pairwise the same values respectively, +# if all ions are built from a single atom only. # -# +# # # -# Sorted in increasing order projected along the positive direction -# of the ROI as defined by orientation in the parent group. +# Sorted in increasing order projected along the positive direction +# of the ROI as defined by orientation in the parent group. # # # @@ -2308,7 +2318,7 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# Hashvalue as defined in :ref:`NXion`. +# Hashvalue as defined in :ref:`NXion`. # # # @@ -2321,13 +2331,13 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # # # # # -# +# # # # @@ -2341,9 +2351,9 @@ NXapm_paraprobe_nanochem_results(NXobject): # # # -# +# # -# If used, metadata of at least the person who performed this analysis. +# If used, metadata of at least the person who performed this analysis. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml index 08efbbc1be..c5c82e9296 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_config.yaml @@ -22,18 +22,16 @@ NXapm_paraprobe_ranger_config(NXobject): # tool-specific range(NXapm_paraprobe_tool_config): exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -210,6 +208,7 @@ NXapm_paraprobe_ranger_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -221,7 +220,7 @@ NXapm_paraprobe_ranger_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4538830bd4cab87df1de7a4d7d3eee2ca77394a687c66de6e4947dc36202776b +# 6ff641838cd8f9e766fa687e8da14cd73057561d6f8c28e40fcf841e38c752b7 # # # # -# # -# +# # # # @@ -286,7 +284,7 @@ NXapm_paraprobe_ranger_config(NXobject): # # # -# +# # # # @@ -453,7 +451,7 @@ NXapm_paraprobe_ranger_config(NXobject): # ranging_definitions(NX_CHAR):--> # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml index b4b85be402..61d6471028 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_ranger_results.yaml @@ -59,12 +59,13 @@ NXapm_paraprobe_ranger_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -78,6 +79,7 @@ NXapm_paraprobe_ranger_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -104,7 +106,7 @@ NXapm_paraprobe_ranger_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4031417067442c68274fe4378416ddd9f3f34ff5f9d9287663a83f344bcadf0f +# 088fca31c73081f286406b893815f7321307129de4e280664632f335736f069b # # # # # @@ -452,12 +455,12 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Specifies, if the iontypes are randomized for the point cloud or not. -# Internally, paraprobe uses a sequentially executed deterministic MT19987 -# (MersenneTwister) pseudo-random number generator to shuffle the -# iontypes randomly across the entire set of ions. That is the total -# number of ions of either type remain the same but the information about -# their location is randomized. +# Specifies, if the iontypes are randomized for the point cloud or not. +# Internally, paraprobe uses a sequentially executed deterministic MT19987 +# (MersenneTwister) pseudo-random number generator to shuffle the +# iontypes randomly across the entire set of ions. That is the total +# number of ions of either type remain the same but the information about +# their location is randomized. # # # @@ -467,35 +470,35 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# How should the iontype be interpreted on the source-side, i.e. -# all these ion positions where a regions-of-interest (ROI) around -# so-called source ions will be placed. Different options exist -# how iontypes are interpreted given an iontype represents -# in general a (molecular) ion with different isotopes that have -# individually different multiplicity. -# -# The value resolve_all will set an ion active in the analysis regardless -# of which iontype it is. Each active ion is accounted for once. -# -# The value resolve_unknown will set an ion active when the ion is -# of the UNKNOWNTYPE type. Each active ion is accounted for once. -# -# The value resolve_ion will set an ion active if it is of the specific -# iontype, irregardless of its elemental or isotopic details. -# Each active ion is counted once. -# -# The value resolve_element will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# atoms of elements in the whitelist ion_query_isotope_vector. -# -# The value resolve_isotope will set an ion active, and most importantly, -# account for each as many times as the (molecular) ion contains -# isotopes in the whitelist ion_query_isotope_vector. -# -# In effect, ion_query_isotope_vector acts as a whitelist to filter -# which ions are considered as source ions of the correlation statistics -# and how the multiplicity of each ion will be factorized, i.e. how -# often it is accounted for. +# How should the iontype be interpreted on the source-side, i.e. +# all these ion positions where a regions-of-interest (ROI) around +# so-called source ions will be placed. Different options exist +# how iontypes are interpreted given an iontype represents +# in general a (molecular) ion with different isotopes that have +# individually different multiplicity. +# +# The value resolve_all will set an ion active in the analysis regardless +# of which iontype it is. Each active ion is accounted for once. +# +# The value resolve_unknown will set an ion active when the ion is +# of the UNKNOWNTYPE type. Each active ion is accounted for once. +# +# The value resolve_ion will set an ion active if it is of the specific +# iontype, irregardless of its elemental or isotopic details. +# Each active ion is counted once. +# +# The value resolve_element will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# atoms of elements in the whitelist ion_query_isotope_vector. +# +# The value resolve_isotope will set an ion active, and most importantly, +# account for each as many times as the (molecular) ion contains +# isotopes in the whitelist ion_query_isotope_vector. +# +# In effect, ion_query_isotope_vector acts as a whitelist to filter +# which ions are considered as source ions of the correlation statistics +# and how the multiplicity of each ion will be factorized, i.e. how +# often it is accounted for. # # # @@ -507,13 +510,13 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Matrix of isotope vectors, as many as rows as different candidates -# for iontypes should be distinguished as possible source iontypes. -# In the simplest case, the matrix contains only the proton number -# of the element in the row, all other values set to zero. -# Combined with ion_query_type_source set to resolve_element this will -# recover usual spatial correlation statistics like the 1NN C-C -# spatial statistics. +# Matrix of isotope vectors, as many as rows as different candidates +# for iontypes should be distinguished as possible source iontypes. +# In the simplest case, the matrix contains only the proton number +# of the element in the row, all other values set to zero. +# Combined with ion_query_type_source set to resolve_element this will +# recover usual spatial correlation statistics like the 1NN C-C +# spatial statistics. # # # @@ -522,14 +525,14 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Similarly as ion_query_type_source how should iontypes be interpreted -# on the target-side, i.e. how many counts will be bookkept for ions -# which are neighbors of source ions within or on the surface of each -# inspection/ROI about each source ion. -# Source ion in the center of the ROI are not accounted for during -# counting the summary statistics. -# For details about the resolve values consider the explanations in -# ion_query_type_source. These account for ion_query_type_target as well. +# Similarly as ion_query_type_source how should iontypes be interpreted +# on the target-side, i.e. how many counts will be bookkept for ions +# which are neighbors of source ions within or on the surface of each +# inspection/ROI about each source ion. +# Source ion in the center of the ROI are not accounted for during +# counting the summary statistics. +# For details about the resolve values consider the explanations in +# ion_query_type_source. These account for ion_query_type_target as well. # # # @@ -542,9 +545,9 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Matrix of isotope vectors, as many as rows as different candidates for -# iontypes to distinguish as possible targets. See additional comments -# under ion_query_isotope_vector_source. +# Matrix of isotope vectors, as many as rows as different candidates for +# iontypes to distinguish as possible targets. See additional comments +# under ion_query_isotope_vector_source. # # # @@ -553,20 +556,20 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Specifies which spatial statistics to compute. +# Specifies which spatial statistics to compute. # # # -# Compute k-th nearest neighbour statistics. +# Compute k-th nearest neighbour statistics. # # # -# Order k. +# Order k. # # # # -# Minimum value, increment, and maximum value of the histogram binning. +# Minimum value, increment, and maximum value of the histogram binning. # # # @@ -575,11 +578,11 @@ NXapm_paraprobe_spatstat_config(NXobject): # # # -# Compute radial distribution function. +# Compute radial distribution function. # # # -# Minimum value, increment, and maximum value of the histogram binning. +# Minimum value, increment, and maximum value of the histogram binning. # # # @@ -592,7 +595,7 @@ NXapm_paraprobe_spatstat_config(NXobject): # NEW ISSUE: two_point(NXcollection):--> # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml index 2752a4a207..0249932ca0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_spatstat_results.yaml @@ -22,6 +22,7 @@ NXapm_paraprobe_spatstat_results(NXobject): # tasks spatial_statisticsID(NXapm_paraprobe_tool_results): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] window(NXcs_filter_boolean_mask): number_of_ions(NX_UINT): @@ -105,12 +106,13 @@ NXapm_paraprobe_spatstat_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -124,6 +126,7 @@ NXapm_paraprobe_spatstat_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -150,7 +153,7 @@ NXapm_paraprobe_spatstat_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 7f5a2bd97403c179da347ecabf3d770ca52f27353199157c0b9ee54719681b7e +# d3857058154cf1a872f2c1036504646243c0a9fbd33226b01fff257b312e4de0 # # # -# +# # # # @@ -301,13 +304,13 @@ NXapm_paraprobe_spatstat_results(NXobject): # # # -# +# # # # # # -# +# # # # @@ -321,7 +324,7 @@ NXapm_paraprobe_spatstat_results(NXobject): # # # -# +# # # If used, metadata of at least the person who performed this analysis. # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml index 165b911ecb..0e381b0710 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_config.yaml @@ -19,18 +19,16 @@ NXapm_paraprobe_surfacer_config(NXobject): enumeration: [NXapm_paraprobe_surfacer_config] surface_meshing(NXapm_paraprobe_tool_config): exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -168,6 +166,7 @@ NXapm_paraprobe_surfacer_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -179,7 +178,7 @@ NXapm_paraprobe_surfacer_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0e5c1d41144b9e94e2940e6c9f8add86863b6b4c46c103ddd3be2299a83c6c48 +# 22584d36a5b5f662bb3ad6c60b0b6d195c9e4d2857f5e07526b35ab84ddaf34e # # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml index 5217c4fe3a..9df193f3c7 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_surfacer_results.yaml @@ -52,6 +52,7 @@ NXapm_paraprobe_surfacer_results(NXobject): # results alpha_complexID(NXcg_alpha_complex): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] # (NXcg_grid): currently we do not store the underlying grid @@ -175,12 +176,13 @@ NXapm_paraprobe_surfacer_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -194,6 +196,7 @@ NXapm_paraprobe_surfacer_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -220,7 +223,7 @@ NXapm_paraprobe_surfacer_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6d639fbf5b7a173a39c0de1a439de07418d1a112ed474097a49715ec6257a137 +# ca34a5157db8e6c9f46b686bf6d57930d008bdf896f2f83a02ee353d7584bd01 # # # # # -# Paraprobe-surfacer can be used to load a ROI that is the entire or a -# sub-set of the ion point cloud. In the point_cloud_wrapping process -# the tool computes a triangulated surface mesh which encloses the -# ROI/point cloud. This mesh can be seen as a model for the edge of -# the dataset. -# -# Different algorithms can be used with paraprobe-surfacer to create -# this mesh such as convex hulls, alpha-shapes as their generalization, -# or alpha wrappings. -# -# Ideally, the resulting mesh should be a watertight polyhedron. -# This polyhedron is not necessarily convex. For some algorithms there -# is no guarantee that the resulting mesh yields a watertight mesh. +# Paraprobe-surfacer can be used to load a ROI that is the entire or a +# sub-set of the ion point cloud. In the point_cloud_wrapping process +# the tool computes a triangulated surface mesh which encloses the +# ROI/point cloud. This mesh can be seen as a model for the edge of +# the dataset. +# +# Different algorithms can be used with paraprobe-surfacer to create +# this mesh such as convex hulls, alpha-shapes as their generalization, +# or alpha wrappings. +# +# Ideally, the resulting mesh should be a watertight polyhedron. +# This polyhedron is not necessarily convex. For some algorithms there +# is no guarantee that the resulting mesh yields a watertight mesh. # # # @@ -314,35 +317,35 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# +# # # # -# A bitmask which identifies exactly all those ions whose positions -# were considered when defining the filtered point set from which -# that alpha_complex instance was computed. -# -# This window can be different to the window of the *point_set_wrapping* -# parent group because irrelevant ions might have been filtered out in addition -# to the window defined in *point_set_wrapping* to reduce e.g. computational -# costs of the alpha complex computation. +# A bitmask which identifies exactly all those ions whose positions +# were considered when defining the filtered point set from which +# that alpha_complex instance was computed. +# +# This window can be different to the window of the *point_set_wrapping* +# parent group because irrelevant ions might have been filtered out in addition +# to the window defined in *point_set_wrapping* to reduce e.g. computational +# costs of the alpha complex computation. # # # # -# Number of ions covered by the mask. +# Number of ions covered by the mask. # # # # -# Number of bits assumed matching on a default datatype. +# Number of bits assumed matching on a default datatype. # # # # -# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for -# how this bitfield is to be interpreted. +# The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for +# how this bitfield is to be interpreted. # # # @@ -374,8 +377,8 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# The set of triangles in the coordinate system paraprobe -# which discretizes the exterior surface of the alpha complex. +# The set of triangles in the coordinate system paraprobe +# which discretizes the exterior surface of the alpha complex. # # # @@ -398,9 +401,9 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tri * (1+1+3). +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tri * (1+1+3). # # # @@ -408,26 +411,26 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# Do the triangles define a triangulated surface mesh that is watertight? +# Do the triangles define a triangulated surface mesh that is watertight? # # # # -# The volume which the triangulated surface mesh -# encloses if that mesh is watertight. +# The volume which the triangulated surface mesh +# encloses if that mesh is watertight. # # # # # # -# The set of tetrahedra which represent the interior volume -# of the complex if that is a closed two-manifold. +# The set of tetrahedra which represent the interior volume +# of the complex if that is a closed two-manifold. # # # # -# The accumulated volume of all interior tetrahedra. +# The accumulated volume of all interior tetrahedra. # # # @@ -443,9 +446,9 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# A list of as many tuples of XDMF topology key, XDMF number -# of vertices and a triple of vertex indices specifying each -# triangle. The total number of entries is n_f_tet * (1+1+4). +# A list of as many tuples of XDMF topology key, XDMF number +# of vertices and a triple of vertex indices specifying each +# triangle. The total number of entries is n_f_tet * (1+1+4). # # # @@ -460,13 +463,13 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# +# # # # # # -# +# # # # @@ -480,9 +483,9 @@ NXapm_paraprobe_surfacer_results(NXobject): # # # -# +# # -# If used, metadata of at least the person who performed this analysis. +# If used, metadata of at least the person who performed this analysis. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml index 8fab535fc3..068577ffd0 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_config.yaml @@ -18,24 +18,22 @@ NXapm_paraprobe_tessellator_config(NXobject): enumeration: [NXapm_paraprobe_tessellator_config] tessellate(NXapm_paraprobe_tool_config): exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): ranging_definitions(NX_CHAR): - surface_distance(NXserialized): + surface_distance(NXnote): exists: optional type(NX_CHAR): path(NX_CHAR): @@ -128,6 +126,7 @@ NXapm_paraprobe_tessellator_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -139,7 +138,7 @@ NXapm_paraprobe_tessellator_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f4c3408502cdbbe6c23210bf7267d29bf1583f8e6c355e8c2b649c6aaf34596e +# 2c0724d62abd1a5dd6950f64aa37a29f26d6a87d381a227ad8bbb50da9fa27a6 # # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml index 7775e6f7ae..d546999b61 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tessellator_results.yaml @@ -227,12 +227,13 @@ NXapm_paraprobe_tessellator_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -246,6 +247,7 @@ NXapm_paraprobe_tessellator_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -272,7 +274,7 @@ NXapm_paraprobe_tessellator_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 72772431a6a4d8aa66255fe434c06584a535aa870ab37f32c0da97aa2344b7b8 +# b081bda676f53f985af253e4b79d3be52d410d5f4ef83f497fffbf4486e7440d # # # # # -# The tool can be used to compute a Voronoi tessellation the entire -# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped -# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an -# axis-aligned bounding box (AABB) that is tight. This means points at -# the edge of the point cloud can lay on the surface of the bounding box. -# The tool detects if cells make contact with the walls of this bounding box. -# The tessellation is computed without periodic boundary conditions. +# The tool can be used to compute a Voronoi tessellation the entire +# or of a sub-set of the reconstructed volume. Each point (ion) is wrapped +# in one (Voronoi) cell. The point cloud in the ROI is wrapped into an +# axis-aligned bounding box (AABB) that is tight. This means points at +# the edge of the point cloud can lay on the surface of the bounding box. +# The tool detects if cells make contact with the walls of this bounding box. +# The tessellation is computed without periodic boundary conditions. # # # @@ -350,12 +352,12 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# The (tight) axis-aligned bounding box about the point cloud. +# The (tight) axis-aligned bounding box about the point cloud. # # # -# Coordinate triplet of the corner that lays closests -# to the origin of the *paraprobe* coordinate system. +# Coordinate triplet of the corner that lays closests +# to the origin of the *paraprobe* coordinate system. # # # @@ -363,8 +365,8 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# Coordinate triplet of the corner that lays farthest away -# from the origin of the *paraprobe* coordinate system. +# Coordinate triplet of the corner that lays farthest away +# from the origin of the *paraprobe* coordinate system. # # # @@ -379,12 +381,12 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# The number of points (and thus cells). +# The number of points (and thus cells). # # # # -# Volume of each Voronoi cell. +# Volume of each Voronoi cell. # # # @@ -392,7 +394,7 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# Which MPI process computed which Voronoi cell. +# Which MPI process computed which Voronoi cell. # # # @@ -400,7 +402,7 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# Which OpenMP thread computed which Voronoi cell. +# Which OpenMP thread computed which Voronoi cell. # # # @@ -408,9 +410,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# The number of faces for each cell. Faces of adjoining polyhedra are counted -# for each polyhedron. This field can be used to interpret the concatenated vector -# with the individual values for the area of each face. +# The number of faces for each cell. Faces of adjoining polyhedra are counted +# for each polyhedron. This field can be used to interpret the concatenated vector +# with the individual values for the area of each face. # # # @@ -419,8 +421,8 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# A simple approach to describe the entire set of polyhedra when the main -# intention is to store the shape of the polyhedra for visualization purposes. +# A simple approach to describe the entire set of polyhedra when the main +# intention is to store the shape of the polyhedra for visualization purposes. # # # @@ -430,12 +432,12 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# Sequence of tuples, concatenated in the order of the Voronoi cells. -# Each tuple contains encodes information to visualize using XDMF: -# Firstly, an XDMF geometric primitive type key. -# Secondly, the number of vertices of the polygon. -# Third, the sequence of vertex identifier which define the facet. -# Tuples encode faces faster than cells. +# Sequence of tuples, concatenated in the order of the Voronoi cells. +# Each tuple contains encodes information to visualize using XDMF: +# Firstly, an XDMF geometric primitive type key. +# Secondly, the number of vertices of the polygon. +# Third, the sequence of vertex identifier which define the facet. +# Tuples encode faces faster than cells. # # # @@ -443,12 +445,12 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# Sequence of cell identifier, concatenated such that each face is -# associated with its cell. Given that paraprobe-tessellator assigns -# each cell the evaporation_id of the ion that the cell wraps this -# information enables the segmentation of the tessellation and -# thus correlate per-ion properties with the volume that each cell -# represents. +# Sequence of cell identifier, concatenated such that each face is +# associated with its cell. Given that paraprobe-tessellator assigns +# each cell the evaporation_id of the ion that the cell wraps this +# information enables the segmentation of the tessellation and +# thus correlate per-ion properties with the volume that each cell +# represents. # # # @@ -457,10 +459,10 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# A bitmask that documents which of the cells are likely truncated because they -# share at least one face with the *aabb* of the point cloud. This field encodes the -# result of the boolean or operator applied to the value of all six wall_contact groups -# that document contact in specific outer unit normal directions of the *aabb*. +# A bitmask that documents which of the cells are likely truncated because they +# share at least one face with the *aabb* of the point cloud. This field encodes the +# result of the boolean or operator applied to the value of all six wall_contact groups +# that document contact in specific outer unit normal directions of the *aabb*. # # # @@ -474,9 +476,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # dim: (i,) # one would not need to constrain this but doing so communicates that all six bitfields have the same length--> # # -# In the spirit of wall_contact_global, the left face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# x-axis of the *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the left face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# x-axis of the *paraprobe* coordinate system. # # # @@ -488,9 +490,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# In the spirit of wall_contact_global, the right face of *aabb*. -# Its outer unit normal points in the direction of the x-axis -# of the *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the right face of *aabb*. +# Its outer unit normal points in the direction of the x-axis +# of the *paraprobe* coordinate system. # # # @@ -502,9 +504,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# y-axis of the *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# y-axis of the *paraprobe* coordinate system. # # # @@ -516,9 +518,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# In the spirit of wall_contact_global, the rear face of *aabb*. -# Its outer unit normal points in the direction of the y-axis -# of the *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the rear face of *aabb*. +# Its outer unit normal points in the direction of the y-axis +# of the *paraprobe* coordinate system. # # # @@ -530,9 +532,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the opposite direction of the -# z-axis of the *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the opposite direction of the +# z-axis of the *paraprobe* coordinate system. # # # @@ -544,9 +546,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# In the spirit of wall_contact_global, the front face of *aabb*. -# Its outer unit normal points in the direction of the z-axis of the -# *paraprobe* coordinate system. +# In the spirit of wall_contact_global, the front face of *aabb*. +# Its outer unit normal points in the direction of the z-axis of the +# *paraprobe* coordinate system. # # # @@ -560,13 +562,13 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# +# # # # # # -# +# # # # @@ -580,9 +582,9 @@ NXapm_paraprobe_tessellator_results(NXobject): # # # -# +# # -# If used, metadata of at least the person who performed this analysis. +# If used, metadata of at least the person who performed this analysis. # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml index e5d5c47e34..7ff7631dd1 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_tool_common.yaml @@ -33,13 +33,12 @@ NXapm_paraprobe_tool_common(NXobject): be that the tool has terminated prematurely or another error occurred. enumeration: [success, failure] (NXprogram): - (NXidentifier): analysis_identifier(NX_UINT): unit: NX_UNITLESS doc: | Internal identifier used by the tool to refer to an analysis (aka simulation id). - config(NXserialized): + config(NXnote): doc: | The configuration file that was used to parameterize the algorithms that this tool has executed. @@ -91,7 +90,7 @@ NXapm_paraprobe_tool_common(NXobject): # workflow from the ifes_apt_tc_data_modeling library # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 61f44d10699cb4e3d8fb0fc07e7ad6d7141ccfa64378ef7b5fa2158a690a4eea +# 8e481d59a192d58fabef91c2617ec88fd43c6c2a32ff8db86e42d57c666eb4ac # # # -# -# +# # # Internal identifier used by the tool to refer to an analysis (aka simulation # id). @@ -164,7 +162,7 @@ NXapm_paraprobe_tool_config(NXobject): # # -# +# # # Specification of the tomographic reconstruction to use for this analysis. # @@ -187,7 +185,7 @@ NXapm_paraprobe_tool_config(NXobject): # # # -# +# # # Specification of the ranging definitions to use for this analysis. # @@ -207,7 +205,7 @@ NXapm_paraprobe_tool_config(NXobject): # # # -# +# # # Specification of the triangulated surface mesh to use for this analysis. # @@ -219,7 +217,7 @@ NXapm_paraprobe_tool_config(NXobject): # doc: | # Name of the (parent) node directly below which (in the hierarchy) # an instance of :ref:`NXcg_triangle_set` is stored.--> -# +# # # Specification of the point-to-triangulated-surface-mesh distances to # use for this analysis. diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml index da3ecbc176..af191dda7f 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_config.yaml @@ -22,18 +22,16 @@ NXapm_paraprobe_transcoder_config(NXobject): # tool-specific transcode(NXapm_paraprobe_tool_config): exists: ['min', '1', 'max', '1'] - (NXidentifier): - exists: optional analysis_identifier(NX_UINT): exists: recommended - reconstruction(NXserialized): + reconstruction(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): position(NX_CHAR): mass_to_charge(NX_CHAR): - ranging(NXserialized): + ranging(NXnote): doc: | Specification of the ranging definition file to use for this analysis. type(NX_CHAR): @@ -46,6 +44,7 @@ NXapm_paraprobe_transcoder_config(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -57,7 +56,7 @@ NXapm_paraprobe_transcoder_config(NXobject): current_working_directory(NX_CHAR): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5860387771b6fde286608597f7582e7d56a5440035ef843b507317fdde59a327 +# 7d735fd7c9f4554b38ce5de6452c603ce05ee862ea04c045f857e4af2ae2c42e # # # # -# # -# +# # # # @@ -113,7 +111,7 @@ NXapm_paraprobe_transcoder_config(NXobject): # # # -# +# # # Specification of the ranging definition file to use for this analysis. # @@ -127,7 +125,7 @@ NXapm_paraprobe_transcoder_config(NXobject): # filter--> # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml index d2ad29f541..b432436bc5 100644 --- a/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml +++ b/contributed_definitions/nyaml/NXapm_paraprobe_transcoder_results.yaml @@ -51,7 +51,7 @@ NXapm_paraprobe_transcoder_results(NXobject): # this group mirrors the NXapm application definition # config analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): @@ -119,12 +119,13 @@ NXapm_paraprobe_transcoder_results(NXobject): common(NXapm_paraprobe_tool_common): status(NX_CHAR): analysis_identifier(NX_UINT): - config(NXserialized): + config(NXnote): type(NX_CHAR): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -138,6 +139,7 @@ NXapm_paraprobe_transcoder_results(NXobject): number_of_threads(NX_POSINT): number_of_gpus(NX_POSINT): userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | If used, metadata of at least the person who performed this analysis. @@ -164,7 +166,7 @@ NXapm_paraprobe_transcoder_results(NXobject): dim: (3,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 6cceb42c410f0ea365c149c39863bc7d050e2feb5eaaea6781b883fd4fc1a8e0 +# aa6e8fbb124face6b3b5967a6b12140c3a1243927757da3cf5ddbc01fb461b50 # # # # -# +# # # # @@ -334,13 +336,13 @@ NXapm_paraprobe_transcoder_results(NXobject): # # # -# +# # # # # # -# +# # # # @@ -354,7 +356,7 @@ NXapm_paraprobe_transcoder_results(NXobject): # # # -# +# # # If used, metadata of at least the person who performed this analysis. # diff --git a/contributed_definitions/nyaml/NXapm_ranging.yaml b/contributed_definitions/nyaml/NXapm_ranging.yaml index 98474ff1bc..f6c0f9fdaf 100644 --- a/contributed_definitions/nyaml/NXapm_ranging.yaml +++ b/contributed_definitions/nyaml/NXapm_ranging.yaml @@ -14,7 +14,7 @@ doc: | type: group NXapm_ranging(NXprocess): (NXprogram): - (NXserialized): + (NXnote): number_of_ion_types(NX_UINT): unit: NX_UNITLESS doc: | @@ -74,7 +74,7 @@ NXapm_ranging(NXprocess): (NXion): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 302fa2e8acf9b9e5538f1483d5a1930f2015a2fda3512bc8b419dfe35ca24cfa +# da98bf40dfacf19127c9dc042d094034403c9a0c0bb678f4022ea60c4af5af2f # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml index 01e0be7259..bd5387c5c5 100644 --- a/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml +++ b/contributed_definitions/nyaml/NXapm_volt_and_bowl.yaml @@ -16,7 +16,7 @@ symbols: type: group NXapm_volt_and_bowl(NXprocess): (NXprogram): - (NXserialized): + (NXnote): # config/input to the algorithm # NEW ISSUE: realistic is that currently scientists can pull always a calibrated time-of-flight @@ -40,7 +40,7 @@ NXapm_volt_and_bowl(NXprocess): dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 625df54664294a09f3528991fd2873c133c6dc101fa39ce08c3701c5dd151da3 +# f9eb14b05c5b9fc923fb8f0fc349b38032c5381ecf9c472c8d4f2e2437f96360 # # # -# -# -# +# NXtransformations? => discussion needed--> +# # -# A beam path consisting of one or more optical elements. -# -# NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement -# of optical elements between the excitation source and the sample, or between -# the sample and the detector unit. -# -# To describe the order of the elements, use 'order(NXtransformations)', where -# each element's position points to the preceding element via '@depends_on'. -# Special case beam splitter: A beam splitter is a device which separates the -# beam into two or more beams. If such a device is part of the beam path use -# two or more NXbeam_paths to describe the beam paths after the beam splitter. -# In this case, in the dependency chain of the new beam paths, the first -# elements each point to the beam splitter, as this is the previous element. -# -# Describe the relevant optical elements in the beam path by using the -# appropriate base classes. You may use as many elements as needed, also -# several elements of the same type as long as each element has its own name. +# A beam path consisting of one or more optical elements. +# +# NXbeam_path is used in NXopt to describe the beam path, i.e. the arrangement +# of optical elements between the excitation source and the sample, or between +# the sample and the detector unit. +# +# To describe the order of the elements, use 'order(NXtransformations)', where +# each element's position points to the preceding element via '@depends_on'. +# Special case beam splitter: A beam splitter is a device which separates the +# beam into two or more beams. If such a device is part of the beam path use +# two or more NXbeam_paths to describe the beam paths after the beam splitter. +# In this case, in the dependency chain of the new beam paths, the first +# elements each point to the beam splitter, as this is the previous element. +# +# Describe the relevant optical elements in the beam path by using the +# appropriate base classes. You may use as many elements as needed, also +# several elements of the same type as long as each element has its own name. # # # -# Entry point of the dependency chain defined by the NXtransformations -# field, i.e. a link to the last element in the beam path. -# Example: /entry/instrument/beam_path/detector. +# Entry point of the dependency chain defined by the NXtransformations +# field, i.e. a link to the last element in the beam path. +# Example: /entry/instrument/beam_path/detector. # # # @@ -393,49 +398,49 @@ NXbeam_path(NXobject): # (2) Base class similar to NXtransformations but for changes of optical # properties (e.g. polarization state).--> # -# Specify the order of the optical elements by defining a dependency chain. -# For each element, a '@depends_on' attribute should be used to state the -# position of the element in the beam path by pointing to the previous -# element. For the very first element, use the string "." instead. +# Specify the order of the optical elements by defining a dependency chain. +# For each element, a '@depends_on' attribute should be used to state the +# position of the element in the beam path by pointing to the previous +# element. For the very first element, use the string "." instead. # # # -# For each element in the beam path, one such field must exist with a -# '@depends_on' attribute defined to specify its position in the beam -# path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows -# ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and -# 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the -# dependency chain, i.e. may have an entry in this class even if they are -# not described in the beam path. -# ELEMENT is a place holder for the name of an optical beam path element. -# Note that the name of this field must be exactly the same as the -# element's field name. +# For each element in the beam path, one such field must exist with a +# '@depends_on' attribute defined to specify its position in the beam +# path. Note that also 'NXopt/ENTRY/INSTRUMENT/sample_stage' and windows +# ('NXopt/ENTRY/INSTRUMENT/sample_stage/entry_window' and +# 'NXopt/ENTRY/INSTRUMENT/sample_stage/exit_window') may be added to the +# dependency chain, i.e. may have an entry in this class even if they are +# not described in the beam path. +# ELEMENT is a place holder for the name of an optical beam path element. +# Note that the name of this field must be exactly the same as the +# element's field name. # # # -# Add a link to the previous beam path element. +# Add a link to the previous beam path element. # # # # # # -# Excitation source. One or more may be needed (e.g. two for a pump-probe -# setup with one pump and one probe beam). -# Depending on the source type, different properties are relevant, which -# are provided through the respective base class (e.g. use NXopt_source for -# lamps or lasers, NXchem_source for chemical reaction etc.). -# Some base classes are incomplete (NXchem_source, NXbio_source); the -# expertise of the respective communities is needed. +# Excitation source. One or more may be needed (e.g. two for a pump-probe +# setup with one pump and one probe beam). +# Depending on the source type, different properties are relevant, which +# are provided through the respective base class (e.g. use NXopt_source for +# lamps or lasers, NXchem_source for chemical reaction etc.). +# Some base classes are incomplete (NXchem_source, NXbio_source); the +# expertise of the respective communities is needed. # # # -# Use this field to point to the previous optical element. +# Use this field to point to the previous optical element. # # # # -# Type of excitation source. +# Type of excitation source. # # # @@ -469,40 +474,40 @@ NXbeam_path(NXobject): # Metal Jet X-ray--> # # # -# Lifespan of the excitation (typically provided in hours). +# Lifespan of the excitation (typically provided in hours). # # # # -# How many hours has the lamp been used? +# How many hours has the lamp been used? # # # # -# Wavelengths or energy vector of the excitation source. This can be a -# single value or a spectrum, depending on the type of experiment. +# Wavelengths or energy vector of the excitation source. This can be a +# single value or a spectrum, depending on the type of experiment. # # # -# Unit of wavelength or energy. +# Unit of wavelength or energy. # # # # # # -# Two- or three-dimensional beam profile. +# Two- or three-dimensional beam profile. # # # @@ -511,67 +516,67 @@ NXbeam_path(NXobject): # # # -# Power of one light pulse if the source is a pulsed source. +# Power of one light pulse if the source is a pulsed source. # # # # -# Is the excitation source continuous wave (CW)? +# Is the excitation source continuous wave (CW)? # # # # -# Power of CW beam. +# Power of CW beam. # # # # -# FWHM bandwidth of the excitation source. +# FWHM bandwidth of the excitation source. # # # # -# Coherence length. +# Coherence length. # # # # -# Divergence of the excitation beam. +# Divergence of the excitation beam. # # # # # -# Use this field to describe a simple pinhole (round geometry). Define its -# dimension using 'diameter'. For more complex geometries, 'NXaperture' -# should be used. +# Use this field to describe a simple pinhole (round geometry). Define its +# dimension using 'diameter'. For more complex geometries, 'NXaperture' +# should be used. # # # # -# Use this field to describe a simple slit (rectangular geometry). Define -# its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, -# 'NXaperture' should be used. +# Use this field to describe a simple slit (rectangular geometry). Define +# its dimensions using 'x_gap' and 'y_gap'. For more complex geometries, +# 'NXaperture' should be used. # # -# +# # -# Use this field to describe an aperture. To specify a window, use the -# field 'window_NUMBER(NXaperture)'. +# Use this field to describe an aperture. To specify a window, use the +# field 'window_NUMBER(NXaperture)'. # # -# +# # -# A window, e.g. an entry or exit window of a cryostat. +# A window, e.g. an entry or exit window of a cryostat. # # # -# Use this field to point to the previous optical element. +# Use this field to point to the previous optical element. # # # # -# The material of the window. +# The material of the window. # # # @@ -586,89 +591,89 @@ NXbeam_path(NXobject): # # # -# If you specified 'other' as material, decsribe here what it is. +# If you specified 'other' as material, decsribe here what it is. # # # # -# Thickness of the window +# Thickness of the window # # # # -# Angle of the window normal (outer) vs. the substrate normal -# (similar to the angle of incidence). +# Angle of the window normal (outer) vs. the substrate normal +# (similar to the angle of incidence). # # # # -# If reference data were measured add a link to the NeXus file where they -# are described. +# If reference data were measured add a link to the NeXus file where they +# are described. # # # # -# +# # # -# A device that reduces the intensity of a beam by attenuation. +# A device that reduces the intensity of a beam by attenuation. # # # -# The transmitted intensity divided by the incident intensity. +# The transmitted intensity divided by the incident intensity. # # # # -# Attenuation of the attenuator in dB. +# Attenuation of the attenuator in dB. # # # -# Unit of the measured data is not covered by NXDL units state -# here which unit was used. +# Unit of the measured data is not covered by NXDL units state +# here which unit was used. # # # # # -# Input and output aperture of the attenuator. +# Input and output aperture of the attenuator. # # # # -# Geometry (shape, size etc.) of the attenuator. +# Geometry (shape, size etc.) of the attenuator. # # # # # -# A diffraction grating. Define relevant parameters in the corresponding -# fields, e.g. order of diffration (diffraction_order) or angular -# dispersion (angular_dispersion). +# A diffraction grating. Define relevant parameters in the corresponding +# fields, e.g. order of diffration (diffraction_order) or angular +# dispersion (angular_dispersion). # # # -# Define the type of the grating. +# Define the type of the grating. # # # # -# Dispersion of the grating in nm/mm (or e.g. nm/mrad). +# Dispersion of the grating in nm/mm (or e.g. nm/mrad). # # # # -# Number of grooves per mm. +# Number of grooves per mm. # # # # -# Blaze wavelength of the grating. +# Blaze wavelength of the grating. # # # # -# Efficiency curve versus wavelength or energy. +# Efficiency curve versus wavelength or energy. # # # @@ -676,94 +681,94 @@ NXbeam_path(NXobject): # # # -# Spectral values, e.g. wavelength or energy. Vector of length -# N_spectrum. +# Spectral values, e.g. wavelength or energy. Vector of length +# N_spectrum. # # # -# Unit of wavelength array (e.g. nanometer or Angstrom) +# Unit of wavelength array (e.g. nanometer or Angstrom) # # # # # # -# A device blocking the beam in a temporal periodic pattern, e.g. a optical -# chopper wheel. Specify the frequency range using 'min_frequency' and -# 'max_frequency'. +# A device blocking the beam in a temporal periodic pattern, e.g. a optical +# chopper wheel. Specify the frequency range using 'min_frequency' and +# 'max_frequency'. # # # -# Minimum frequency in Hertz. +# Minimum frequency in Hertz. # # # # -# Maximum frequency in Hertz. +# Maximum frequency in Hertz. # # # # -# Frequency resolution in Hertz. +# Frequency resolution in Hertz. # # # # # -# A monochromator or spectrometer. +# A monochromator or spectrometer. # # # -# Spectral values of the monochromator, e.g. wavelength or energy values -# used for the measurement. +# Spectral values of the monochromator, e.g. wavelength or energy values +# used for the measurement. # # # -# Unit of wavelength array (e.g. nanometer or Angstrom) +# Unit of wavelength array (e.g. nanometer or Angstrom) # # # # # -# Diffraction grating. If two or more gratings were used, define the -# angular dispersion and the wavelength range (min/max wavelength) for -# each grating and make sure that the wavelength ranges do not overlap. -# The dispersion should be defined for the entire wavelength range of the -# experiment. +# Diffraction grating. If two or more gratings were used, define the +# angular dispersion and the wavelength range (min/max wavelength) for +# each grating and make sure that the wavelength ranges do not overlap. +# The dispersion should be defined for the entire wavelength range of the +# experiment. # # # -# Dispersion of the grating in nm/mm. +# Dispersion of the grating in nm/mm. # # # # -# Minimum wavelength of the grating. +# Minimum wavelength of the grating. # # # # -# Maximum wavelength of the grating. +# Maximum wavelength of the grating. # # # # # -# Spectral resolution of the instrument. +# Spectral resolution of the instrument. # # # # -# Define the width of the monochromator slit in the subfield x_gap. +# Define the width of the monochromator slit in the subfield x_gap. # # # -# Was the slit width fixed? +# Was the slit width fixed? # # # # -# If slit width was not fixed, define the maximum slit width. +# If slit width was not fixed, define the maximum slit width. # # # diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml index 2a18ce2a39..bacb98b465 100644 --- a/contributed_definitions/nyaml/NXbeam_splitter.yaml +++ b/contributed_definitions/nyaml/NXbeam_splitter.yaml @@ -25,7 +25,7 @@ symbols: # A draft of a new base class to describe a beam splitting device. type: group -NXbeam_splitter(NXobject): +NXbeam_splitter(NXcomponent): type: doc: | Specify the beam splitter type (e.g. dielectric mirror, pellicle, @@ -238,6 +238,7 @@ NXbeam_splitter(NXobject): Angle of deflection corresponding to the optimized angle of incidence defined in incident_angle. AOI_range(NX_NUMBER): + nameType: partial unit: NX_ANGLE doc: | Range of the angles of incidence (AOI) for which the beam splitter can be @@ -271,8 +272,8 @@ NXbeam_splitter(NXobject): dim: (N_outputs, N_spectrum_RT) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d739363819b4050b8b158dc1e9f64288e44b9c7f78f42c38c80d474b8330743d -# +# 1886d82b6c50fd6e7274490e735d68ba45e10aef0bef7e3df8a726763e277a17 +# # # -# -# +# +# # # # -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the beam splitter material and/or coating is defined. +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the beam splitter material and/or coating is defined. # # # # -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# reflectance or transmission of the beam splitter is given. +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# reflectance or transmission of the beam splitter is given. # # # # -# Number of parameters needed do descripe the shape of the beam splitter. +# Number of parameters needed do descripe the shape of the beam splitter. # # # # -# Number of objects the beam splitter is made up of. +# Number of objects the beam splitter is made up of. # # # # -# Number of outputs, i.e. number of paths the beam takes after being split by -# the beam splitter. +# Number of outputs, i.e. number of paths the beam takes after being split by +# the beam splitter. # # # # -# A beam splitter, i.e. a device splitting the light into two or more beams. -# -# Information about types and properties of beam splitters is provided e.g. -# [here](https://www.rp-photonics.com/beam_splitters.html). -# -# Use two or more NXbeam_paths to describe the beam paths after the beam -# splitter. In the dependency chain of the new beam paths, the first elements -# each point to this beam splitter, as this is the previous element. +# A beam splitter, i.e. a device splitting the light into two or more beams. +# +# Information about types and properties of beam splitters is provided e.g. +# [here](https://www.rp-photonics.com/beam_splitters.html). +# +# Use two or more NXbeam_paths to describe the beam paths after the beam +# splitter. In the dependency chain of the new beam paths, the first elements +# each point to this beam splitter, as this is the previous element. # # # -# Specify the beam splitter type (e.g. dielectric mirror, pellicle, -# dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension -# should be described in 'geometry'. Define if the beam splitter is -# polarizing or not in the field 'polarizing(NX_BOOLEAN)'. +# Specify the beam splitter type (e.g. dielectric mirror, pellicle, +# dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension +# should be described in 'geometry'. Define if the beam splitter is +# polarizing or not in the field 'polarizing(NX_BOOLEAN)'. # # # @@ -359,29 +361,29 @@ NXbeam_splitter(NXobject): # # # -# If you selected 'other' in 'type' use this field to specify which type of -# beam splitter was used. +# If you selected 'other' in 'type' use this field to specify which type of +# beam splitter was used. # # # # -# Is the beam splitter polarizing? +# Is the beam splitter polarizing? # # # # # -# Does the beam splitter have multiple outputs (diffractive optical -# element), i.e. more than two outputs? +# Does the beam splitter have multiple outputs (diffractive optical +# element), i.e. more than two outputs? # # # # -# Describe the geometry (shape, dimension etc.) of the beam splitter. -# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be -# provided in the 'sketch(NXdata)' field to clarify (i) the shape and -# dimensions of the device, and (ii) the input and outputs (i.e. the -# direction of the incoming and outcoming (split) beams). +# Describe the geometry (shape, dimension etc.) of the beam splitter. +# Specify the dimensions in 'SHAPE/size'. A sketch of the device should be +# provided in the 'sketch(NXdata)' field to clarify (i) the shape and +# dimensions of the device, and (ii) the input and outputs (i.e. the +# direction of the incoming and outcoming (split) beams). # # # # -# Describe the shape (plate, cube, wedged, prism etc.). +# Describe the shape (plate, cube, wedged, prism etc.). # # # @@ -404,32 +406,32 @@ NXbeam_splitter(NXobject): # # # -# If you chose 'other' in 'shape' describe what it is. +# If you chose 'other' in 'shape' describe what it is. # # # # -# Sketch of the beam splitter showing its geometry. The paths of the -# incoming and split beam should be illustrated and labelled (0 for the -# incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split -# beam paths)). +# Sketch of the beam splitter showing its geometry. The paths of the +# incoming and split beam should be illustrated and labelled (0 for the +# incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split +# beam paths)). # # # # -# Physical extent of the beam splitter device. The beam splitter might be -# made up of one or more objects (NX_objects). The meaning and location -# of the axes used will vary according to the value of the 'shape' -# variable. 'N_shapepar' defines how many parameters: -# -# * For 'cube' the parameters are (width, length). -# * For 'cylinder' the parameters are (diameter, length). -# * For 'plate' the parameters are (width, height, length). -# * For 'prism' the parameters are (width, height, length). -# * For 'wedged' the parameters are (width, height, shortest length). -# The wedge angle should be provided in 'SHAPE/wedge_angle'. -# * For 'other' the parameters may be (A, B, C, ...) with the labels -# defined in the sketch plotted in 'SHAPE/sketch'. +# Physical extent of the beam splitter device. The beam splitter might be +# made up of one or more objects (NX_objects). The meaning and location +# of the axes used will vary according to the value of the 'shape' +# variable. 'N_shapepar' defines how many parameters: +# +# * For 'cube' the parameters are (width, length). +# * For 'cylinder' the parameters are (diameter, length). +# * For 'plate' the parameters are (width, height, length). +# * For 'prism' the parameters are (width, height, length). +# * For 'wedged' the parameters are (width, height, shortest length). +# The wedge angle should be provided in 'SHAPE/wedge_angle'. +# * For 'other' the parameters may be (A, B, C, ...) with the labels +# defined in the sketch plotted in 'SHAPE/sketch'. # # # @@ -438,41 +440,41 @@ NXbeam_splitter(NXobject): # # # -# Wedge angle if 'shape' is 'wedged'. +# Wedge angle if 'shape' is 'wedged'. # # # # +# doc: | +# Specify the length of the beam splitter. If the device has a wedged +# shape provide the minimum and maximum length of the device. +# Otherwise, if the beam splitter has a homogeneous thickness, the two +# values are equal. +# dimensions: +# rank: 1 +# dim: [[1,2]]--> # # -# Beam splitting ratio(s) for the various outputs (i.e. the -# paths of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. +# Beam splitting ratio(s) for the various outputs (i.e. the +# paths of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. # # # @@ -480,30 +482,30 @@ NXbeam_splitter(NXobject): # # # -# Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of -# length and height for square geometry). +# Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of +# length and height for square geometry). # # # # # -# Substrate of the beam splitter. Describe the material of the substrate in -# substrate/substrate_material and provide its index of refraction in -# substrate/index_of_refraction_substrate, if known. +# Substrate of the beam splitter. Describe the material of the substrate in +# substrate/substrate_material and provide its index of refraction in +# substrate/index_of_refraction_substrate, if known. # # # -# Specify the material of the beam splitter. If the device has a coating -# it should be described in coating/coating_material. Is the material -# birefringent? +# Specify the material of the beam splitter. If the device has a coating +# it should be described in coating/coating_material. Is the material +# birefringent? # # # # -# Thickness of the beam splitter substrate. Define the minimum and -# maximum thickness (for a wedged geomtry). For a homogeneous thickness -# (e.g. as in plate beam splitters) the minimum and maximum values are -# equal. +# Thickness of the beam splitter substrate. Define the minimum and +# maximum thickness (for a wedged geomtry). For a homogeneous thickness +# (e.g. as in plate beam splitters) the minimum and maximum values are +# equal. # # # @@ -511,8 +513,8 @@ NXbeam_splitter(NXobject): # # # -# Complex index of refraction of the beam splitter substrate. Specify at -# given spectral values (e.g. wavelength, energy, wavenumber etc.). +# Complex index of refraction of the beam splitter substrate. Specify at +# given spectral values (e.g. wavelength, energy, wavenumber etc.). # # # @@ -522,32 +524,32 @@ NXbeam_splitter(NXobject): # # # -# Is the beam splitter coated? If yes, specify the type and material of the -# coating and the spectral range for which it is designed. If known, you -# may also provide its index of refraction. For a beam splitter cube -# consisting of two prisms which are glued together, you may want to -# specify the the glue and the coatings of each prism. +# Is the beam splitter coated? If yes, specify the type and material of the +# coating and the spectral range for which it is designed. If known, you +# may also provide its index of refraction. For a beam splitter cube +# consisting of two prisms which are glued together, you may want to +# specify the the glue and the coatings of each prism. # # # -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). # # # # -# Specify the coating material. +# Specify the coating material. # # # # -# Thickness of the coating. +# Thickness of the coating. # # # # -# Wavelength range for which the coating is designed. Enter the minimum -# and maximum values of the wavelength range. +# Wavelength range for which the coating is designed. Enter the minimum +# and maximum values of the wavelength range. # # # @@ -555,8 +557,8 @@ NXbeam_splitter(NXobject): # # # -# Complex index of refraction of the coating. Specify at given spectral -# values (e.g. wavelength, energy, wavenumber etc.). +# Complex index of refraction of the coating. Specify at given spectral +# values (e.g. wavelength, energy, wavenumber etc.). # # # @@ -566,10 +568,10 @@ NXbeam_splitter(NXobject): # # # -# Wavelength range for which the beam splitter is designed. Enter the -# minimum and maximum values of the wavelength range. Alternatively, or -# additionally, you may define the wavelength range for the coating in -# coating/wavelength_range_coating. +# Wavelength range for which the beam splitter is designed. Enter the +# minimum and maximum values of the wavelength range. Alternatively, or +# additionally, you may define the wavelength range for the coating in +# coating/wavelength_range_coating. # # # @@ -577,11 +579,11 @@ NXbeam_splitter(NXobject): # # # -# Optical loss of the beam splitter for the various outputs (i.e. the paths -# of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting -# with 1. +# Optical loss of the beam splitter for the various outputs (i.e. the paths +# of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting +# with 1. # # # @@ -589,20 +591,20 @@ NXbeam_splitter(NXobject): # # # -# Optimized angle of incidence for the desired splitting ratio. +# Optimized angle of incidence for the desired splitting ratio. # # # # # -# Angle of deflection corresponding to the optimized angle of incidence -# defined in incident_angle. +# Angle of deflection corresponding to the optimized angle of incidence +# defined in incident_angle. # # -# +# # -# Range of the angles of incidence (AOI) for which the beam splitter can be -# operated. Specify the minimum and maximum angles of the range. +# Range of the angles of incidence (AOI) for which the beam splitter can be +# operated. Specify the minimum and maximum angles of the range. # # # @@ -615,7 +617,7 @@ NXbeam_splitter(NXobject): # for the corresponding defelction angles...--> # # -# Reflectance of the beam splitter at given spectral values. +# Reflectance of the beam splitter at given spectral values. # # # @@ -623,11 +625,11 @@ NXbeam_splitter(NXobject): # # # -# Transmission at given spectral values for the various outputs (i.e. the -# paths of the beam after being split by the beam splitter). -# The order of the ratios must be consistent with the labels -# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting -# with 1. +# Transmission at given spectral values for the various outputs (i.e. the +# paths of the beam after being split by the beam splitter). +# The order of the ratios must be consistent with the labels +# 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting +# with 1. # # # diff --git a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml index 36bb934fd0..eae072f18a 100644 --- a/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml +++ b/contributed_definitions/nyaml/NXbeam_transfer_matrix_table.yaml @@ -17,6 +17,7 @@ symbols: type: group NXbeam_transfer_matrix_table(NXobject): datatype_N: + nameType: partial doc: | Select which type of data was recorded, for example aperture and focal length. @@ -73,7 +74,7 @@ NXbeam_transfer_matrix_table(NXobject): Specific name of output beam which the transfermatrix table is related to. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# bb8efd82466b6d6e6e501d73d164b0437964abe48ac78916903757f7f6ccc4f8 +# 3c72efd3163790099d59b3bf6be34cc1057f31649bf49712963a10e0ae19e95b # # # -# +# # # # Variables used throughout the document, e.g. dimensions or parameters. @@ -109,17 +110,17 @@ NXbeam_transfer_matrix_table(NXobject): # # # -# Contains datastructures of an experimental optical setup (i.e., multiple +# Contains datastructures of an experimental optical setup (i.e., multiple # transfermatrix tables). These datastructures are used to relate physical # properties of two beams (NXbeam) which have one common optical element # (NXopt_element) (one specific transfermatrix). # One of these beams in an input beam and the other one is an output beam. # -# The data describes the change of beam properties, e.g. the intensity of a +# The data describes the change of beam properties, e.g. the intensity of a # beam is reduced because the transmission coefficient of the beam device is # lower than 1. # -# +# # # Select which type of data was recorded, for example aperture and # focal length. @@ -148,7 +149,7 @@ NXbeam_transfer_matrix_table(NXobject): # # # -# Contains the datastructure which relates beam properties of an +# Contains the datastructure which relates beam properties of an # input and output beam as result of the input beam interaction # with the beam device. # diff --git a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml index c613e62da0..da1c1a42ad 100644 --- a/contributed_definitions/nyaml/NXbias_spectroscopy.yaml +++ b/contributed_definitions/nyaml/NXbias_spectroscopy.yaml @@ -120,6 +120,7 @@ NXbias_spectroscopy(NXobject): doc: | The offset of the scan area in 2D (X and Y) space. scan_angle_N(NX_NUMBER): + nameType: partial unit: NX_ANGLE doc: | The N (substring) denotes the angle of the scan area with different physical @@ -149,11 +150,12 @@ NXbias_spectroscopy(NXobject): doc: | Speed of the scanner or the probe that moves backward direction. SCAN_data(NXdata): + nameType: partial doc: | The data that comes from scanning the area. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4b1872302a9e6d1a4b687f8c648537e20f2fb5fc5f3dcdcc1c7afb6334d3c97f +# ce82fca45f4b9d70ad9bf3c0c95e4b81cc06395739e8f158b443edc6550d4bed # # # # # -# A base class for bias spectroscopy to describe the change in the physical properties -# of the sample with respect to the sweep voltage applied on a sample of STM/AFM/... experiment. -# -# In these experiments an electric potential is applied between the (conductive) sample and the probe -# (tip), and the physical properties (e.g. tunnelling current) is measured as the function of this -# potential. The potential is varied in so-called voltage sweeps and the corresponding properties are -# recorded accordingly. +# A base class for bias spectroscopy to describe the change in the physical properties +# of the sample with respect to the sweep voltage applied on a sample of STM/AFM/... experiment. +# +# In these experiments an electric potential is applied between the (conductive) sample and the probe +# (tip), and the physical properties (e.g. tunnelling current) is measured as the function of this +# potential. The potential is varied in so-called voltage sweeps and the corresponding properties are +# recorded accordingly. # # # -# The measurement of the I(V) curve can come in two ways: -# 1. Constant spacing: The bias voltage is swept from the start to the end with a constant -# spacing between the tip and surface. -# 2. Variable spacing: The bias voltage is swept from the start to the end in a discretized -# spacing between the tip and surface. (Either an array of voltages, or the steps are defined). +# The measurement of the I(V) curve can come in two ways: +# 1. Constant spacing: The bias voltage is swept from the start to the end with a constant +# spacing between the tip and surface. +# 2. Variable spacing: The bias voltage is swept from the start to the end in a discretized +# spacing between the tip and surface. (Either an array of voltages, or the steps are defined). # # # @@ -202,16 +204,16 @@ NXbias_spectroscopy(NXobject): # # # -# The PID (proportional, integral, differential feedback system) positioner information while running -# bias voltage-tunneling current measurement. -# -# These components position the probe relative to the sample, thus help obtaining maps of the data -# across the sample surface. +# The PID (proportional, integral, differential feedback system) positioner information while running +# bias voltage-tunneling current measurement. +# +# These components position the probe relative to the sample, thus help obtaining maps of the data +# across the sample surface. # # # -# The z-offset is a starting tip position before the sweep starts (typically the position of a -# piezo element). +# The z-offset is a starting tip position before the sweep starts (typically the position of a +# piezo element). # # # @@ -220,32 +222,32 @@ NXbias_spectroscopy(NXobject): # # # -# The time or period is taken by a bias sweep to acquire the data for -# a single bias sweep point (when the given point or whole sweep is started.). +# The time or period is taken by a bias sweep to acquire the data for +# a single bias sweep point (when the given point or whole sweep is started.). # # # # -# The time or period is taken by a bias sweep to be displayed. +# The time or period is taken by a bias sweep to be displayed. # # # # -# The time or period is taken by the circuit to measure a full bias sweep voltage or -# bias current. (duration of the measurement) +# The time or period is taken by the circuit to measure a full bias sweep voltage or +# bias current. (duration of the measurement) # # # # # -# The time or period is taken by the circuit to indicate the bias sweep voltage -# after measuring the voltage. +# The time or period is taken by the circuit to indicate the bias sweep voltage +# after measuring the voltage. # # # # # -# The bias sweep information. +# The bias sweep information. # # # # -# The type of scan like mesh, spiral, etc. -# -# This combines not only how the voltages are changed, but how the voltage values are -# correlated to a position across the sample surface, measuring sweeps are each spatial -# coordinate or mapping the response at constant voltage, etc. -# For STS experiment, the scan type is usually a single-point scan (trajectory scan). +# The type of scan like mesh, spiral, etc. +# +# This combines not only how the voltages are changed, but how the voltage values are +# correlated to a position across the sample surface, measuring sweeps are each spatial +# coordinate or mapping the response at constant voltage, etc. +# For STS experiment, the scan type is usually a single-point scan (trajectory scan). # # # @@ -266,91 +268,91 @@ NXbias_spectroscopy(NXobject): # # # -# The number of sweeps taken during the bias spectroscopy. +# The number of sweeps taken during the bias spectroscopy. # # # # -# The initial time is taken to settle the bias voltage at the desired value. -# On each sweep usually, the system takes time to settle to the bias voltage -# at the next value. +# The initial time is taken to settle the bias voltage at the desired value. +# On each sweep usually, the system takes time to settle to the bias voltage +# at the next value. # # # # -# The time is taken to settle the bias voltage at the desired value. -# The time (at the last sweep) to settle for the last value of the sweep. +# The time is taken to settle the bias voltage at the desired value. +# The time (at the last sweep) to settle for the last value of the sweep. # # # # -# The rate at which the amplifier responds to the voltage change -# (to reach at the desired value). It defines if the tip movement and -# voltage sweep are synchronized. +# The rate at which the amplifier responds to the voltage change +# (to reach at the desired value). It defines if the tip movement and +# voltage sweep are synchronized. # # # # -# The z position after the sweeps are done. +# The z position after the sweeps are done. # # # # -# The total time needed for the entire voltage sweep. +# The total time needed for the entire voltage sweep. # # # # -# The region of the scan area. +# The region of the scan area. # # # -# The range of the scan area. +# The range of the scan area. # # # # -# The offset of the scan area in 2D (X and Y) space. +# The offset of the scan area in 2D (X and Y) space. # # -# +# # -# The N (substring) denotes the angle of the scan area with different physical -# axes. +# The N (substring) denotes the angle of the scan area with different physical +# axes. # # # # # # -# The linear scan information for scanning of a smaple. -# -# In this scan type the probe is scanned with a constant velocity across the surface, -# and parameters are measured along the line. +# The linear scan information for scanning of a smaple. +# +# In this scan type the probe is scanned with a constant velocity across the surface, +# and parameters are measured along the line. # # # -# The speed of the scanner or the probe during the scan. +# The speed of the scanner or the probe during the scan. # # # # -# The time taken by the scanner to scan the entire area. +# The time taken by the scanner to scan the entire area. # # # # -# Speed of the scanner or the probe moves forward direction. +# Speed of the scanner or the probe moves forward direction. # # # # -# Speed of the scanner or the probe that moves backward direction. +# Speed of the scanner or the probe that moves backward direction. # # -# +# # -# The data that comes from scanning the area. +# The data that comes from scanning the area. # # # diff --git a/contributed_definitions/nyaml/NXbias_sweep.yaml b/contributed_definitions/nyaml/NXbias_sweep.yaml index 52834701ee..598ea1cbda 100644 --- a/contributed_definitions/nyaml/NXbias_sweep.yaml +++ b/contributed_definitions/nyaml/NXbias_sweep.yaml @@ -47,13 +47,14 @@ NXbias_sweep(NXscan_control): The reset_bias defines whether the bias voltage should be reset to the starting value after the sweep is completed. SCAN_data(NXdata): + nameType: partial doc: | The scan data is the data collected during the scan. If the scan has several channels or derivatives from the channel data, please duplicate this NXdata group for each. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 63c8e627522926180b6b1a3bb3699f0c7f94d6f86a2335d5f38add044dd2190c +# 57cb57bff8956f11feaba86d2553bd4ec082428eb94c06d8af29518d3eb27505 # # # # # -# A base class that defines how the bias voltage sweep is performed in the -# scanning probe microscopy experiments. +# A base class that defines how the bias voltage sweep is performed in the +# scanning probe microscopy experiments. # # # -# The scan region is the area of phase space or sub-phase space where the scan is -# performed. +# The scan region is the area of phase space or sub-phase space where the scan is +# performed. # # # -# The starting voltage of the bias sweep. The range of voltages for the sweep can -# be defined with scan voltage offset and scan voltage range (difference between -# minimum and maximum voltage values in a sweep) +# The starting voltage of the bias sweep. The range of voltages for the sweep can +# be defined with scan voltage offset and scan voltage range (difference between +# minimum and maximum voltage values in a sweep) # # # # -# The range of voltages for the sweep can be defined with scan voltage offset and -# scan voltage range (difference between minimum and maximum voltage values in a -# sweep) +# The range of voltages for the sweep can be defined with scan voltage offset and +# scan voltage range (difference between minimum and maximum voltage values in a +# sweep) # # # # -# The start of the bias scan voltage. +# The start of the bias scan voltage. # # # # -# The end value of the bias scan voltage. +# The end value of the bias scan voltage. # # # # # -# In the linear sweep, the bias voltage is changed linearly from the start value -# to the end value. +# In the linear sweep, the bias voltage is changed linearly from the start value +# to the end value. # # # -# If the bias voltage sweep is also performed in the opposite direction. +# If the bias voltage sweep is also performed in the opposite direction. # # # # -# The number of voltage points per sweep. +# The number of voltage points per sweep. # # # # -# The step size between the two consecutive bias voltage values during the sweep. +# The step size between the two consecutive bias voltage values during the sweep. # # # # -# The reset_bias defines whether the bias voltage should be reset to the starting -# value after the sweep is completed. +# The reset_bias defines whether the bias voltage should be reset to the starting +# value after the sweep is completed. # # -# +# # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, -# please duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, +# please duplicate this NXdata group for each. # # # diff --git a/contributed_definitions/nyaml/NXcalibration.yaml b/contributed_definitions/nyaml/NXcalibration.yaml deleted file mode 100644 index c4ec71774c..0000000000 --- a/contributed_definitions/nyaml/NXcalibration.yaml +++ /dev/null @@ -1,419 +0,0 @@ -category: base -doc: | - Subclass of NXprocess to describe post-processing calibrations. -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays - ncoeff: | - Number of coefficients of the calibration function - ncal: | - Number of points of the calibrated and uncalibrated axes -type: group -NXcalibration(NXobject): - description(NX_CHAR): - doc: | - A description of the procedures employed. - start_time(NX_DATE_TIME): - doc: | - The start time of the calibration. - end_time(NX_DATE_TIME): - doc: | - The end time of the calibration. - calibration_interval(NX_FLOAT): - unit: NX_TIME - doc: | - The time difference between the start and end time of the calibration. - Or the value directly comes from the instrument. - validity_period(NX_DATE_TIME): - doc: | - The period for which the calibration is valid. Usually, every instrument or part of the - needs to be calibrated at regular intervals. - calibration_type(NX_CHAR): - doc: | - The type of calibration, e.g., active calibration, passive calibration, - or according to the laboratory defined type. - physical_quantity: - doc: | - The physical quantity of the calibration, e.g., - energy, momentum, time, etc. - calibration_method(NXidentifier): - doc: | - A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a - calibration method but no actual calibration data. - calibration_reference(NXidentifier): - doc: | - A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement - used for this instrument, e.g., a measurement of a known standard containing calibration information. - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - calibration_object(NXserialized): - doc: | - A file serialisation of a calibration which may not be publicly available (externally from the nexus file). - - This metadata can be a documentation of the source (file) or database (entry) from which pieces - of information have been extracted for consumption (e.g. in a research data management system (RDMS)). - It is also possible to include the actual file by using the `file` field. - - The axis values may be copied or linked in the appropriate NXcalibration fields for reference. - last_process(NX_CHAR): - doc: | - Indicates the name of the last operation applied in the NXprocess sequence. - applied(NX_BOOLEAN): - doc: | - Has the calibration been applied? - calibration_software: - doc: | - Name of the software used for this calibration. - \@version: - doc: | - Software version. - original_axis(NX_FLOAT): - unit: NX_ANY - doc: | - Vector containing the data coordinates in the original uncalibrated axis - dimensions: - rank: 1 - dim: (ncal,) - \@symbol: - doc: | - The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. - This should comply to the following naming rules (similar to python's naming rules): - - * A variable name must start with a letter or the underscore character - * A variable name cannot start with a number - * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) - * Variable names are case-sensitive (age, Age and AGE are three different variables) - \@input_path: - doc: | - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - input_SYMBOL(NX_FLOAT): - unit: NX_ANY - doc: | - Additional input axis to be used in the formula. - The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., - if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. - dimensions: - rank: 1 - dim: (ncal,) - \@input_path: - doc: | - The path from which this data is derived, e.g., raw detector axis. - Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. - coefficients(NX_FLOAT): - unit: NX_ANY - doc: | - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - dimensions: - rank: 1 - dim: (ncoeff,) - fit_function(NX_CHAR): - doc: | - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the nth position in the `original_axis` field. - If there is the symbol attribute specified for the `original_axis` this may be used instead of x. - If you want to use the whole axis use `x`. - Alternate axis can also be available as specified by the `input_SYMBOL` field. - The data should then be referred here by the `SYMBOL` name, e.g., for a field - name `input_my_field` it should be referred here by `my_field` or `my_field0` if - you want to read the zeroth element of the array. - - The formula should be numpy compliant. - scaling(NX_FLOAT): - unit: NX_ANY - doc: | - For linear calibration. Scaling parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - offset(NX_FLOAT): - unit: NX_ANY - doc: | - For linear calibration. Offset parameter. - This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. - mapping_MAPPING(NX_FLOAT): - doc: | - Mapping data for calibration. - - This can be used to map data points from uncalibrated to calibrated values, - i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. - calibrated_AXIS(NX_FLOAT): - unit: NX_ANY - doc: | - A vector representing the axis after calibration, matching the data length - dimensions: - rank: 1 - dim: (ncal,) - \@output_path: - doc: | - The path to which this data is written, e.g., the calibrated energy. - Should be a valid NeXus path name, e.g., /entry/data/energy. - (NXdata): - doc: | - Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. - NXdata groups can be used for multidimensional data which are relevant to the calibration - \@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 ++++++++++++++++++++++++++++++++++ -# 0637e042803449160e95d45786d186382342ce32958d181cfbd42830ffb145c2 -# -# -# -# -# -# -# The symbols used in the schema to specify e.g. dimensions of arrays -# -# -# -# Number of coefficients of the calibration function -# -# -# -# -# Number of points of the calibrated and uncalibrated axes -# -# -# -# -# Subclass of NXprocess to describe post-processing calibrations. -# -# -# -# A description of the procedures employed. -# -# -# -# -# The start time of the calibration. -# -# -# -# -# The end time of the calibration. -# -# -# -# -# The time difference between the start and end time of the calibration. -# Or the value directly comes from the instrument. -# -# -# -# -# The period for which the calibration is valid. Usually, every instrument or part of the -# needs to be calibrated at regular intervals. -# -# -# -# -# The type of calibration, e.g., active calibration, passive calibration, -# or according to the laboratory defined type. -# -# -# -# -# The physical quantity of the calibration, e.g., -# energy, momentum, time, etc. -# -# -# -# -# A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a -# calibration method but no actual calibration data. -# -# -# -# -# A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement -# used for this instrument, e.g., a measurement of a known standard containing calibration information. -# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. -# -# -# -# -# A file serialisation of a calibration which may not be publicly available (externally from the nexus file). -# -# This metadata can be a documentation of the source (file) or database (entry) from which pieces -# of information have been extracted for consumption (e.g. in a research data management system (RDMS)). -# It is also possible to include the actual file by using the `file` field. -# -# The axis values may be copied or linked in the appropriate NXcalibration fields for reference. -# -# -# -# -# Indicates the name of the last operation applied in the NXprocess sequence. -# -# -# -# -# Has the calibration been applied? -# -# -# -# -# Name of the software used for this calibration. -# -# -# -# Software version. -# -# -# -# -# -# Vector containing the data coordinates in the original uncalibrated axis -# -# -# -# -# -# -# The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. -# This should comply to the following naming rules (similar to python's naming rules): -# -# * A variable name must start with a letter or the underscore character -# * A variable name cannot start with a number -# * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) -# * Variable names are case-sensitive (age, Age and AGE are three different variables) -# -# -# -# -# The path from which this data is derived, e.g., raw detector axis. -# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. -# -# -# -# -# -# Additional input axis to be used in the formula. -# The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., -# if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. -# -# -# -# -# -# -# The path from which this data is derived, e.g., raw detector axis. -# Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. -# -# -# -# -# -# For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit -# to a set of features (peaks) at well defined energy positions to determine -# E(TOF). Here we can store the array of fit coefficients. -# -# -# -# -# -# -# -# For non-linear energy calibrations. Here we can store the formula of the -# fit function. -# -# Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. -# -# Use x0, x1, ..., xn for the nth position in the `original_axis` field. -# If there is the symbol attribute specified for the `original_axis` this may be used instead of x. -# If you want to use the whole axis use `x`. -# Alternate axis can also be available as specified by the `input_SYMBOL` field. -# The data should then be referred here by the `SYMBOL` name, e.g., for a field -# name `input_my_field` it should be referred here by `my_field` or `my_field0` if -# you want to read the zeroth element of the array. -# -# The formula should be numpy compliant. -# -# -# -# -# For linear calibration. Scaling parameter. -# This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. -# -# -# -# -# For linear calibration. Offset parameter. -# This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. -# -# -# -# -# Mapping data for calibration. -# -# This can be used to map data points from uncalibrated to calibrated values, -# i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. -# -# -# -# -# A vector representing the axis after calibration, matching the data length -# -# -# -# -# -# -# The path to which this data is written, e.g., the calibrated energy. -# Should be a valid NeXus path name, e.g., /entry/data/energy. -# -# -# -# -# -# Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. -# NXdata groups can be used for multidimensional data which are relevant to the calibration -# -# -# -# -# .. 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/NXcantilever_spm.yaml b/contributed_definitions/nyaml/NXcantilever_spm.yaml index a10c276f2a..8fcda23ab8 100644 --- a/contributed_definitions/nyaml/NXcantilever_spm.yaml +++ b/contributed_definitions/nyaml/NXcantilever_spm.yaml @@ -73,6 +73,7 @@ NXcantilever_spm(NXobject): doc: | The coating material of the cantilever. curvature_radius_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The radius of curvature of the cantilever tip. The (substring) N denotes X or Y. @@ -110,7 +111,7 @@ NXcantilever_spm(NXobject): The spring constant coefficient of the cantilever. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 89398ae58cda108a83a696128f7e8021a9abb5a60b191883f4f622692f616ab1 +# 0bb179697bd3f260d94d8d9a8f4f2e30c0ea17f1d42f56ed12207897b7f3e976 # # # # # -# A base class to describe the cantilever used in Atomic Force Microscopy (AFM) -# techniques. +# A base class to describe the cantilever used in Atomic Force Microscopy (AFM) +# techniques. # # # -# Generally speaking, the cantilever resembles a simple harmonic oscillator. -# When the cantilever tip is close to the surface of the sample, an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. The detector (typically a photodiode) measures this deformation and, therefore, the force acting on the cantilever. -# In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of this loop controls the vertical position of the cantilever. -# This part describes the oscillator driving the oscillations of a cantilever in an AFM or other experiment. +# Generally speaking, the cantilever resembles a simple harmonic oscillator. +# When the cantilever tip is close to the surface of the sample, an attractive or repulsive force appears between the cantilever and the sample, deforming the cantilever. The detector (typically a photodiode) measures this deformation and, therefore, the force acting on the cantilever. +# In a typical AFM scan cantilever moves toward the surface of the sample until a user-defined value of force acting on the cantilever is reached. The measured force is used as an input of a PID feedback loop, and the output of this loop controls the vertical position of the cantilever. +# This part describes the oscillator driving the oscillations of a cantilever in an AFM or other experiment. # # # -# The reference amplitude (also called drive amplitude) of the cantilever. +# The reference amplitude (also called drive amplitude) of the cantilever. # # # # -# The reference frequency (also called drive frequency or resonance frequency) of -# the cantilever. +# The reference frequency (also called drive frequency or resonance frequency) of +# the cantilever. # # # # -# The harmonic (e.g., second harmonic of the fundamental frequency) frequency of -# the cantilever. +# The harmonic (e.g., second harmonic of the fundamental frequency) frequency of +# the cantilever. # # # # -# Phase locked loop for cantilever lock-in device. +# Phase locked loop for cantilever lock-in device. # # # -# Describes the cantilever frequency positioner, if it exists. +# Describes the cantilever frequency positioner, if it exists. # # # # -# Describes the cantilever phase positioner, if it exists. +# Describes the cantilever phase positioner, if it exists. # # # # -# Describes the cantilever frequency positioner, if it exists. +# Describes the cantilever frequency positioner, if it exists. # # # # # -# The phase difference between the reference signal of cantilever and response -# signal. +# The phase difference between the reference signal of cantilever and response +# signal. # # # # -# Shift in the resonance frequency of the cantilever. +# Shift in the resonance frequency of the cantilever. # # # # -# The cutoff frequency of the cantilever. +# The cutoff frequency of the cantilever. # # # # -# The bandwidth of the resonance frequency. +# The bandwidth of the resonance frequency. # # # # -# The target amplitude of the cantilever to start the AFM/SPM experiment. +# The target amplitude of the cantilever to start the AFM/SPM experiment. # # # # -# The active frequency of the cantilever to start the experiment. +# The active frequency of the cantilever to start the experiment. # # # # -# The reference phase of the cantilever oscillator. +# The reference phase of the cantilever oscillator. # # # # # -# The configuration information of the cantilever such as calibration information, -# material properties, size, resonance, etc. +# The configuration information of the cantilever such as calibration information, +# material properties, size, resonance, etc. # # # -# The coating material of the cantilever. +# The coating material of the cantilever. # # -# +# # -# The radius of curvature of the cantilever tip. The (substring) N denotes X or Y. +# The radius of curvature of the cantilever tip. The (substring) N denotes X or Y. # # # # -# The shape of the cantilever as a general text, such as A-shape, beam, or arrow. +# The shape of the cantilever as a general text, such as A-shape, beam, or arrow. # # # # -# Nominal length between base and end of the cantilever in micrometers. +# Nominal length between base and end of the cantilever in micrometers. # # # # -# Nominal width of the cantilever in microns. +# Nominal width of the cantilever in microns. # # # # -# Nominal thickness of the cantilever in microns. +# Nominal thickness of the cantilever in microns. # # # # -# Nominal free resonance frequency of the cantilever in air, in kHz. +# Nominal free resonance frequency of the cantilever in air, in kHz. # # # # -# The calibration information of the cantilever. +# The calibration information of the cantilever. # # # -# A force applied to the cantilever tip will cause a change in -# cantilever's oscillation amplitude (in dynamic mode) or deflection of the cantilever. -# The sensitivity of the cantilever is calculated as the ratio of this change to the force causing it. +# A force applied to the cantilever tip will cause a change in +# cantilever's oscillation amplitude (in dynamic mode) or deflection of the cantilever. +# The sensitivity of the cantilever is calculated as the ratio of this change to the force causing it. # # # # -# The spring constant coefficient of the cantilever. +# The spring constant coefficient of the cantilever. # # # diff --git a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml index e65659d43c..a64fe44def 100644 --- a/contributed_definitions/nyaml/NXcg_alpha_complex.yaml +++ b/contributed_definitions/nyaml/NXcg_alpha_complex.yaml @@ -45,6 +45,7 @@ NXcg_alpha_complex(NXcg_primitive_set): # check again carefully the CGAL documentation talks about, for 3D, the square of the radius! point_setID(NXcg_point_set): + nameType: partial # basically just constraints that if you use one or more instances of NXcg_point_set # inside an instance of NXcg_alpha_complex, name that group with the prefix "point_set" @@ -64,9 +65,11 @@ NXcg_alpha_complex(NXcg_primitive_set): # also using the assumption the base class reports the unique vertices # of the specifically filtrated alpha complex. triangle_setID(NXcg_triangle_set): + nameType: partial doc: | Triangle soup for which the alpha wrapping has been computed. triangle_meshID(NXcg_triangle_set): + nameType: partial doc: | Triangle mesh representing the alpha complex. @@ -79,6 +82,7 @@ NXcg_alpha_complex(NXcg_primitive_set): # more specifically it is the set of filtrated cells acknowledging mode # e.g. the interior cells of the regularized alpha complex interior_cellsID(NXcg_tetrahedron_set): + nameType: partial doc: | Set of tetrahedra representing the volume inside the alpha complex. @@ -86,7 +90,7 @@ NXcg_alpha_complex(NXcg_primitive_set): # https://doc.cgal.org/latest/Alpha_shapes_3/classCGAL_1_1Alpha__status.html # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a017934b2194181ba8c28b1edd9d3d86be5065955852f72cb9bbcfe3545b2ffd +# ac8bae322b29a5639cc19e742441020340a4e8646ab23e58aabbaf6800b02bfe # # # # # -# Computational geometry of alpha shapes or alpha wrappings about primitives. -# -# For details see: -# -# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, -# * https://dx.doi.org/10.1145/174462.156635 for 3D, -# * https://dl.acm.org/doi/10.5555/871114 for weighted, and -# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation -# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings -# -# in CGAL, the Computational Geometry Algorithms Library. -# As a starting point, we follow the conventions of the CGAL library. +# Computational geometry of alpha shapes or alpha wrappings about primitives. +# +# For details see: +# +# * https://dx.doi.org/10.1109/TIT.1983.1056714 for 2D, +# * https://dx.doi.org/10.1145/174462.156635 for 3D, +# * https://dl.acm.org/doi/10.5555/871114 for weighted, and +# * https://doc.cgal.org/latest/Alpha_shapes_3 for 3D implementation +# * https://doc.cgal.org/latest/Manual/packages.html#PkgAlphaWrap3 for 3D wrappings +# +# in CGAL, the Computational Geometry Algorithms Library. +# As a starting point, we follow the conventions of the CGAL library. # # # -# Type of alpha complex following the terminology used by CGAL for now. -# -# Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes -# created using the alpha_wrapping algorithm. +# Type of alpha complex following the terminology used by CGAL for now. +# +# Basic means (unweighted) alpha shapes. Alpha_wrapping means meshes +# created using the alpha_wrapping algorithm. # # # @@ -142,15 +146,15 @@ NXcg_alpha_complex(NXcg_primitive_set): # # # -# Are singular faces removed, i.e. has the alpha complex -# been regularized or not. +# Are singular faces removed, i.e. has the alpha complex +# been regularized or not. # # # # # -# The alpha parameter, i.e. the radius of the alpha-sphere that -# is used when computing the alpha complex. +# The alpha parameter, i.e. the radius of the alpha-sphere that +# is used when computing the alpha complex. # # # # # -# The offset distance parameter used when computing alpha_wrappings. +# The offset distance parameter used when computing alpha_wrappings. # # # -# -# +# +# # -# Point cloud for which the alpha shape or wrapping has been computed. +# Point cloud for which the alpha shape or wrapping has been computed. # # # -# +# # -# Triangle soup for which the alpha wrapping has been computed. +# Triangle soup for which the alpha wrapping has been computed. # # -# +# # -# Triangle mesh representing the alpha complex. +# Triangle mesh representing the alpha complex. # # # -# +# # -# Set of tetrahedra representing the volume inside the alpha complex. +# Set of tetrahedra representing the volume inside the alpha complex. # # # # # -# Qualifier for the shape of each hexahedron. +# Qualifier for the shape of each hexahedron. # # # @@ -248,9 +250,9 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Qualifier that is useful in cases when one edge is longer than all other -# edges of the hexahedra. Often the term length is associated with the -# assumption that one edge is parallel to an axis of the coordinate system. +# Qualifier that is useful in cases when one edge is longer than all other +# edges of the hexahedra. Often the term length is associated with the +# assumption that one edge is parallel to an axis of the coordinate system. # # # @@ -258,11 +260,11 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Qualifier often used to describe the extent of an object in the horizontal -# direction assuming a specific coordinate system. -# -# For the sake of explicitness quantities like length, width, and height -# should not be reported without specifying also the assumed reference frame. +# Qualifier often used to describe the extent of an object in the horizontal +# direction assuming a specific coordinate system. +# +# For the sake of explicitness quantities like length, width, and height +# should not be reported without specifying also the assumed reference frame. # # # @@ -270,8 +272,8 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Qualifier often used to describe the extent of an object in the vertical -# direction assuming a specific coordinate system. +# Qualifier often used to describe the extent of an object in the vertical +# direction assuming a specific coordinate system. # # # @@ -279,7 +281,7 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Volume of each hexahedron. +# Volume of each hexahedron. # # # @@ -287,7 +289,7 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Total (surface) area (of all six faces) of each hexahedron. +# Total (surface) area (of all six faces) of each hexahedron. # # # @@ -295,7 +297,7 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Area of each of the six faces of each hexahedron. +# Area of each of the six faces of each hexahedron. # # # @@ -304,8 +306,8 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Specifies if the hexahedra represent cuboids or cubes eventually rotated -# ones but at least not too exotic six-faced polyhedra. +# Specifies if the hexahedra represent cuboids or cubes eventually rotated +# ones but at least not too exotic six-faced polyhedra. # # # @@ -313,9 +315,9 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Only to be used if is_box is present. In this case, this field describes -# whether hexahedra are boxes whose primary edges are parallel to the -# axes of the coordinate system. +# Only to be used if is_box is present. In this case, this field describes +# whether hexahedra are boxes whose primary edges are parallel to the +# axes of the coordinate system. # # # @@ -329,17 +331,17 @@ NXcg_hexahedron_set(NXcg_primitive_set): # # # -# Combined storage of all primitives of all hexahedra. +# Combined storage of all primitives of all hexahedra. # # -# +# # -# Individual storage of each hexahedron. +# Individual storage of each hexahedron. # # -# +# # -# Individual storage of each hexahedron as a graph. +# Individual storage of each hexahedron as a graph. # # # diff --git a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml index 52664246fe..e6ce43c650 100644 --- a/contributed_definitions/nyaml/NXcg_marching_cubes.yaml +++ b/contributed_definitions/nyaml/NXcg_marching_cubes.yaml @@ -11,7 +11,8 @@ NXcg_marching_cubes(NXobject): grid(NXcg_grid): doc: | Metadata of the grid on which the here specified MC is operating. - (NXidentifier): + identifierNAME: + nameType: partial doc: | Reference to the specific implementation of marching cubes used. @@ -30,7 +31,7 @@ NXcg_marching_cubes(NXobject): # tools like Matlab do not expose the rule set. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# f8fb3ac6fcaa69c537fe96147e0e83785d989cc8c376c426fd22f1351f396732 +# 7ee43a95a3b4510e6ec3b55be5cfd8b0bfbc850b56f0fdf8796fc25c3ad013a8 # # # # # -# Base class to detail the marching cubes (MC) algorithm. -# -# Documenting which specific version of MC was used helps with understanding -# how robust the results are with respect to the topology of the triangulation. +# Base class to detail the marching cubes (MC) algorithm. +# +# Documenting which specific version of MC was used helps with understanding +# how robust the results are with respect to the topology of the triangulation. # # # -# Metadata of the grid on which the here specified MC is operating. +# Metadata of the grid on which the here specified MC is operating. # # -# +# # -# Reference to the specific implementation of marching cubes used. -# -# See for example the following papers for details about specific -# MC implementations: -# -# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ -# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ +# Reference to the specific implementation of marching cubes used. +# +# See for example the following papers for details about specific +# MC implementations: +# +# * `W. E. Lorensen <https://doi.org/10.1109/MCG.2020.2971284>`_ +# * `T. S. Newman and H. Yi <https://doi.org/10.1016/j.cag.2006.07.021>`_ # -# +# # # -# Free text field in case a proper identifier is not available. +# Free text field in case a proper identifier is not available. # # # diff --git a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml index 01851e8b65..1c0b570598 100644 --- a/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml +++ b/contributed_definitions/nyaml/NXcg_parallelogram_set.yaml @@ -65,14 +65,15 @@ NXcg_parallelogram_set(NXcg_primitive_set): doc: | Combined storage of all primitives of all parallelograms. parallelogramID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each parallelogram. - #MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) + # MK::parallelogram_half_edgeID(NXcg_half_edge_data_structure) # a half-edge structure would be overkill as this is a simple primitive # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b0a086bf5fa5c5eff4281f8b7d7b7fa6cc37dd88b466a432e92fbcb417c965d0 +# 187fcae08726cb89911d53b6a47fe2caa37da4859687fda856927f8391a986e6 # # # # # -# To specify which parallelogram is a rectangle. +# To specify which parallelogram is a rectangle. # # # @@ -154,9 +155,9 @@ NXcg_parallelogram_set(NXcg_primitive_set): # # # -# Only to be used if is_rectangle is present. In this case, this field -# describes whether parallelograms are rectangles whose primary edges -# are parallel to the axes of the coordinate system. +# Only to be used if is_rectangle is present. In this case, this field +# describes whether parallelograms are rectangles whose primary edges +# are parallel to the axes of the coordinate system. # # # @@ -164,18 +165,16 @@ NXcg_parallelogram_set(NXcg_primitive_set): # # # -# +# # -# Combined storage of all primitives of all parallelograms. +# Combined storage of all primitives of all parallelograms. # # -# +# # -# Individual storage of each parallelogram. +# Individual storage of each parallelogram. # # -# # diff --git a/contributed_definitions/nyaml/NXcg_polygon_set.yaml b/contributed_definitions/nyaml/NXcg_polygon_set.yaml index ec35cb30ed..390c54cffa 100644 --- a/contributed_definitions/nyaml/NXcg_polygon_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polygon_set.yaml @@ -52,9 +52,11 @@ NXcg_polygon_set(NXcg_primitive_set): doc: | Combined storage of all primitives of all polygons. polygonID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of the mesh of each polygon. polygon_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial doc: | Individual storage of each polygon as a graph. @@ -90,7 +92,7 @@ NXcg_polygon_set(NXcg_primitive_set): dim: (c,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b43bd18728cf45289f01e1a3e03d8630c3138e0f1dc08367eb2ba485715038a1 +# 8bf58f13110dc373800ee8818212b4ded2ac57a0f651795dc2c16e123e2c54cb # # # # # -# The symbols used in the schema to specify e.g. dimensions of arrays. +# The symbols used in the schema to specify e.g. dimensions of arrays. # # # -# The dimensionality, which has to be either 2 or 3. +# The dimensionality, which has to be either 2 or 3. # # # # -# The cardinality of the set, i.e. the number of polygons. +# The cardinality of the set, i.e. the number of polygons. # # # # # -# The total number of vertices when visiting every polygon. +# The total number of vertices when visiting every polygon. # # # -# +# # -# Computational geometry description of a set of polygons in Euclidean space. -# -# Polygons are specialized polylines: -# -# * A polygon is a geometric primitive that is bounded by a closed polyline -# * All vertices of this polyline lay in the d-1 dimensional plane. -# whereas vertices of a polyline do not necessarily lay on a plane. -# * A polygon has at least three vertices. -# -# Each polygon is built from a sequence of vertices (points with identifiers). -# The members of a set of polygons may have a different number of vertices. -# Sometimes a collection/set of polygons is referred to as a soup of polygons. -# -# As three-dimensional objects, a set of polygons can be used to define the -# hull of what is effectively a polyhedron; however users are advised to use -# the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed -# polyhedra. Even more general complexes can be thought of. An example are the -# so-called piecewise-linear complexes used in the TetGen library. -# -# As these complexes can have holes though, polyhedra without holes are one -# subclass of such complexes, users should rather design an own -# base class e.g. NXcg_polytope_set to describe such even more -# complex primitives instead of abusing this base class for such purposes. +# Computational geometry description of a set of polygons in Euclidean space. +# +# Polygons are specialized polylines: +# +# * A polygon is a geometric primitive that is bounded by a closed polyline +# * All vertices of this polyline lay in the d-1 dimensional plane. +# whereas vertices of a polyline do not necessarily lay on a plane. +# * A polygon has at least three vertices. +# +# Each polygon is built from a sequence of vertices (points with identifiers). +# The members of a set of polygons may have a different number of vertices. +# Sometimes a collection/set of polygons is referred to as a soup of polygons. +# +# As three-dimensional objects, a set of polygons can be used to define the +# hull of what is effectively a polyhedron; however users are advised to use +# the specific :ref:`NXcg_polyhedron_set` base class if they wish to describe closed +# polyhedra. Even more general complexes can be thought of. An example are the +# so-called piecewise-linear complexes used in the TetGen library. +# +# As these complexes can have holes though, polyhedra without holes are one +# subclass of such complexes, users should rather design an own +# base class e.g. NXcg_polytope_set to describe such even more +# complex primitives instead of abusing this base class for such purposes. # # # -# The total number of vertices in the set. +# The total number of vertices in the set. # # # # # -# Combined storage of all primitives of all polygons. +# Combined storage of all primitives of all polygons. # # -# +# # -# Individual storage of the mesh of each polygon. +# Individual storage of the mesh of each polygon. # # -# +# # -# Individual storage of each polygon as a graph. +# Individual storage of each polygon as a graph. # # # # # -# For each polygon its accumulated length along its edges. +# For each polygon its accumulated length along its edges. # # # @@ -199,11 +199,11 @@ NXcg_polygon_set(NXcg_primitive_set): # # # -# Interior angles for each polygon. There are as many values per polygon -# as the are number_of_vertices. -# The angle is the angle at the specific vertex, i.e. between the adjoining -# edges of the vertex according to the sequence in the polygons array. -# Usually, the winding_order field is required to interpret the value. +# Interior angles for each polygon. There are as many values per polygon +# as the are number_of_vertices. +# The angle is the angle at the specific vertex, i.e. between the adjoining +# edges of the vertex according to the sequence in the polygons array. +# Usually, the winding_order field is required to interpret the value. # # # @@ -211,11 +211,11 @@ NXcg_polygon_set(NXcg_primitive_set): # # # -# Curvature type: -# -# * 0 - unspecified, -# * 1 - convex, -# * 2 - concave +# Curvature type: +# +# * 0 - unspecified, +# * 1 - convex, +# * 2 - concave # # # diff --git a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml index 2a41d5bb3c..5ed60132b1 100644 --- a/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_polyhedron_set.yaml @@ -64,14 +64,16 @@ NXcg_polyhedron_set(NXcg_primitive_set): doc: | Combined storage of all primitives of all polyhedra. polyhedronID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each polyhedron. polyhedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial doc: | Individual storage of each polygon as a graph. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9712721e164e36357137dcc33a06b824e50f6d863384cbf37b61cc1693657371 +# e291b7a90f8a679ff8dffbf38903db0540afad9e9d4d62945756e9fc7f45320b # # # # # -# The number of faces for each polyhedron. Faces of adjoining polyhedra -# are counted for each polyhedron. +# The number of faces for each polyhedron. Faces of adjoining polyhedra +# are counted for each polyhedron. # # # @@ -149,7 +151,7 @@ NXcg_polyhedron_set(NXcg_primitive_set): # # # -# Area of each of faces. +# Area of each of faces. # # # @@ -157,13 +159,13 @@ NXcg_polyhedron_set(NXcg_primitive_set): # # # -# The number of edges for each polyhedron. Edges of adjoining polyhedra -# are counterd for each polyhedron. +# The number of edges for each polyhedron. Edges of adjoining polyhedra +# are counterd for each polyhedron. # # # # -# Length of each edge. +# Length of each edge. # # # @@ -172,17 +174,17 @@ NXcg_polyhedron_set(NXcg_primitive_set): # # # -# Combined storage of all primitives of all polyhedra. +# Combined storage of all primitives of all polyhedra. # # -# +# # -# Individual storage of each polyhedron. +# Individual storage of each polyhedron. # # -# +# # -# Individual storage of each polygon as a graph. +# Individual storage of each polygon as a graph. # # # diff --git a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml index 6928e2d6ef..9243bc30f1 100644 --- a/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml +++ b/contributed_definitions/nyaml/NXcg_tetrahedron_set.yaml @@ -42,14 +42,16 @@ NXcg_tetrahedron_set(NXcg_primitive_set): doc: | Combined storage of all primitives of all tetrahedra. tetrahedronID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each tetrahedron. tetrahedron_half_edgeID(NXcg_half_edge_data_structure): + nameType: partial doc: | Individual storage of each tetrahedron as a graph. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 71a9038c43e7664e52f7781bf712b0e06ec5b4f77b49ed79e12d2d0e145daa5d +# d8ccc211c8894acc7eac6b81ef354cd5af5a92dd0b9bd3a2dca403bbe6004f92 # # # # # -# Area of each of the four triangular faces of each tetrahedron. +# Area of each of the four triangular faces of each tetrahedron. # # # @@ -103,7 +105,7 @@ NXcg_tetrahedron_set(NXcg_primitive_set): # # # -# Length of each edge of each tetrahedron. +# Length of each edge of each tetrahedron. # # # @@ -113,26 +115,25 @@ NXcg_tetrahedron_set(NXcg_primitive_set): # # # -# Combined storage of all primitives of all tetrahedra. +# Combined storage of all primitives of all tetrahedra. # # -# +# # -# Individual storage of each tetrahedron. +# Individual storage of each tetrahedron. # # -# +# # -# Individual storage of each tetrahedron as a graph. +# Individual storage of each tetrahedron as a graph. # # # diff --git a/contributed_definitions/nyaml/NXcg_triangle_set.yaml b/contributed_definitions/nyaml/NXcg_triangle_set.yaml index 935a79b5b4..ded2cf6e70 100644 --- a/contributed_definitions/nyaml/NXcg_triangle_set.yaml +++ b/contributed_definitions/nyaml/NXcg_triangle_set.yaml @@ -23,12 +23,13 @@ NXcg_triangle_set(NXcg_primitive_set): This description resembles the typical representation of primitives in file formats such as OFF, PLY, VTK, or STL. triangleID(NXcg_face_list_data_structure): + nameType: partial doc: | Individual storage of each triangle. Users are advised that using such individual storage of primitives may be less storage efficient than creating a combined storage. - ##MK::considered too trivial: + #MK::considered too trivial: # triangle_half_edgeID(NXcg_half_edge_data_structure): # doc: | # Individual storage of each triangle as a graph. @@ -55,7 +56,7 @@ NXcg_triangle_set(NXcg_primitive_set): dim: (c, 3) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c6d43c52c3140c5e58081cf807c80946b3560fad3da2a49e06182f1fbce22bab +# 1d848f77305e03ff65e6574b889212b49e0c38694054821abd000e5583980e2a # # # # # -# Length of the edges of each triangle. -# -# For each triangle values are reported via traversing -# the vertices in the sequence as these are defined. +# Length of the edges of each triangle. +# +# For each triangle values are reported via traversing +# the vertices in the sequence as these are defined. # # # @@ -142,10 +143,10 @@ NXcg_triangle_set(NXcg_primitive_set): # # # -# Interior angles of each triangle. -# -# For each triangle values are reported for the angle opposite -# to the respective edges in the sequence how vertices are defined. +# Interior angles of each triangle. +# +# For each triangle values are reported for the angle opposite +# to the respective edges in the sequence how vertices are defined. # # # diff --git a/contributed_definitions/nyaml/NXchamber.yaml b/contributed_definitions/nyaml/NXchamber.yaml index 217c994511..bf132ad1e2 100644 --- a/contributed_definitions/nyaml/NXchamber.yaml +++ b/contributed_definitions/nyaml/NXchamber.yaml @@ -2,7 +2,7 @@ category: base doc: | Base class for a chamber in an instrument that stores real or simulated objects. type: group -NXchamber(NXobject): +NXchamber(NXcomponent): name(NX_CHAR): doc: | Given name for the chamber of this component e.g. analysis chamber @@ -11,10 +11,9 @@ NXchamber(NXobject): doc: | Free-text field for describing details about the chamber. For example out of which material was the chamber built. - (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2466d3b355c324278fa4174dce8b424faf3976a5122fa2a2e78d7602721210fc +# 57f86db83a26a7a0f384c5ab4d3219af0bbb0abb50a78ff7efb71c35cf6d0bc9 # # # -# +# # # Base class for a chamber in an instrument that stores real or simulated objects. # @@ -54,5 +53,4 @@ NXchamber(NXobject): # For example out of which material was the chamber built. # # -# # diff --git a/contributed_definitions/nyaml/NXcollectioncolumn.yaml b/contributed_definitions/nyaml/NXcollectioncolumn.yaml index 494b1b3ada..651d178d5c 100644 --- a/contributed_definitions/nyaml/NXcollectioncolumn.yaml +++ b/contributed_definitions/nyaml/NXcollectioncolumn.yaml @@ -3,7 +3,7 @@ doc: | Subclass of NXelectronanalyser to describe the electron collection column of a photoelectron analyser. type: group -NXcollectioncolumn(NXobject): +NXcollectioncolumn(NXcomponent): scheme(NX_CHAR): doc: | Scheme of the electron collection lens, i.e. angular dispersive, @@ -46,31 +46,6 @@ NXcollectioncolumn(NXobject): unit: NX_DIMENSIONLESS doc: | The magnification of the electron lens assembly. - depends_on(NX_CHAR): - doc: | - Specifies the position of the collectioncolumn by pointing to the last - transformation in the transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. - \@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. (NXaperture): doc: | The size and position of an aperture inserted in the column, e.g. field aperture @@ -84,7 +59,7 @@ NXcollectioncolumn(NXobject): (NXfabrication): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e6f754891fb42c6d38c265bae0bc286b14fbf807e3fd21d0d63be9d9a1b099cc +# a1ba311f85694976ece234760b7aabe8b7c219e82788b1c60842474febd873b4 # # # -# +# # # Subclass of NXelectronanalyser to describe the electron collection # column of a photoelectron analyser. @@ -168,37 +143,6 @@ NXcollectioncolumn(NXobject): # The magnification of the electron lens assembly. # # -# -# -# Specifies the position of the collectioncolumn by pointing to the last -# transformation in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component 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. -# -# # # # The size and position of an aperture inserted in the column, e.g. field aperture diff --git a/contributed_definitions/nyaml/NXcomponent.yaml b/contributed_definitions/nyaml/NXcomponent.yaml deleted file mode 100644 index 85536a528c..0000000000 --- a/contributed_definitions/nyaml/NXcomponent.yaml +++ /dev/null @@ -1,98 +0,0 @@ -category: base -doc: | - Base class for components of an instrument - real ones or a simulated ones. -type: group -NXcomponent(NXobject): - \@depends_on(NX_CHAR): - doc: | - Specifies the position of the component by pointing to the last - transformation in the transformation chain that is defined - via the NXtransformations group. - applied(NX_BOOLEAN): - doc: | - Was the component used? - name(NX_CHAR): - doc: | - Given name - description(NX_CHAR): - doc: | - Ideally, use instances of :ref:`NXidentifier` to point to a resource - that provides further details. - - If such a resource does not exist or should not be used, use this, though - discouraged, free-text. - (NXfabrication): - (NXidentifier): - (NXprogram): - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the - location and geometry of the component in the instrument. - (NXcircuit): - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 15222f66772445a0323ed2f5c0a9882093f1edd137fc7abe4b99a7af5656189a -# -# -# -# -# -# Base class for components of an instrument - real ones or a simulated ones. -# -# -# -# Specifies the position of the component by pointing to the last -# transformation in the transformation chain that is defined -# via the NXtransformations group. -# -# -# -# -# Was the component used? -# -# -# -# -# Given name -# -# -# -# -# Ideally, use instances of :ref:`NXidentifier` to point to a resource -# that provides further details. -# -# If such a resource does not exist or should not be used, use this, though -# discouraged, free-text. -# -# -# -# -# -# -# -# Collection of axis-based translations and rotations to describe the -# location and geometry of the component in the instrument. -# -# -# -# diff --git a/contributed_definitions/nyaml/NXcontainer.yaml b/contributed_definitions/nyaml/NXcontainer.yaml index eec0f61b17..b3c6332fc2 100644 --- a/contributed_definitions/nyaml/NXcontainer.yaml +++ b/contributed_definitions/nyaml/NXcontainer.yaml @@ -41,7 +41,7 @@ doc: | container with nothing inside, to allow data corrections (at a specific beam energy/measurement time) to be made. type: group -NXcontainer(NXobject): +NXcontainer(NXcomponent): name: doc: | Descriptive name of container. @@ -122,13 +122,13 @@ NXcontainer(NXobject): which these data are valid. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 037b114d3aecdc11946fa995fb3cafb177f3dd95a4d314e5fe1f2a8811af0268 +# fd240139c4a1eacf1c1593f017c2ed4ff250080dc08daf32cf8ee9e6e8ca34ca # # # # # -# Base class to hold different coordinate systems and representation conversions. -# -# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? -# -# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across -# the application definition, an instance of NXcoordinate_system is defined, -# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ -# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and -# NXcoordinate_system base classes backwards compatible to older -# NeXus conventions and classes. -# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed -# as high up in the node hierarchy (ideally right below an instance of NXentry) -# of the application definition tree as possible. -# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system -# instance. This shall be named such that it is clear how this coordinate system is -# typically referred to in a community. For the NeXus `McStas coordinate system, it is -# advised to call it mcstas for the sake of improved clarity. -# Additional NXcoordinate_system instances should be specified if possible in that same -# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. -# -# If this is the case, it is assumed that the NXcoordinate_system_members -# overwrite the NeXus default McStas coordinate system, i.e. users can thereby -# conveniently and explicitly specify the coordinate system(s) that -# they wish to use. -# -# Users are encouraged to write also explicit and clean depends_on fields in -# all groups that encode information about where the interpretation of coordinate -# systems is relevant. If these depends_on hints are not provided, it is -# automatically assumed that all children (to arbitrary depth) -# of that branch and sub-branches below the one in which that -# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set -# instance in that set or the application definition is considered -# underconstrained which should at all costs be avoided and in which case -# again McStas is assumed. -# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified -# somewhere in the tree, different interpretations are possible as to which -# of these coordinate system sets and instances apply or take preference. -# We realize that such ambiguities should at all costs be avoided. -# However, the opportunity for multiple sets and their instances enables to -# have branch-specific coordinate system conventions which could especially -# be useful for deep classes where multiple scientific methods are combined or -# cases where having a definition of global translation and conversion tables -# how to convert between representations in different coordinate systems -# is not desired or available for now. -# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective -# NXcoordinate_system instances makes the interpretation eventually unnecessary -# complicated. Instead, developers of application definitions should always try -# to work for clarity and thus use only one top-level coordinate system set. -# -# For these reasons we conclude that the option with one top-level -# :ref:`NXcoordinate_system_set` instance is the preferred choice. -# -# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance -# of NXcoordinate_system is specified. However, even in this case it is better -# to be explicit like for every other coordinate system definition to support -# users with interpreting the content and logic behind every instance of the tree. -# -# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? -# Individual coordinate systems should be specified as members of the -# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. -# -# How many individual instances of NXcoordinate_system to allow within one -# instance of :ref:`NXcoordinate_system_set`? -# -# * 0; This case should be avoided for the sake of clarity but this case could -# mean the authors of the definition meant that McStas is used. We conclude, -# McStas is used in this case. -# * 1; Like above-mentioned this case has the advantage that it is explicit -# and faces no ambiguities. However, in reality typically multiple -# coordinate systems have to be mastered especially for complex -# multi-signal modality experiments. -# * 2 or more; If this case is realized, the best practice is that in every -# case where a coordinate system should be referred to the respective class -# has a depends_on field which resolves the possible ambiguities which specific -# coordinate systems is referred to. The benefit of this explicit and clear -# specifying of the coordinate system used in every case is that especially -# in combination with having coordinate systems inside deeper branches -# makes up for a very versatile, backwards compatible, but powerful system -# to express different types of coordinate systems using NeXus. In the case -# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, -# it is also advised to specify the relationship between the two coordinate systems by -# using the (NXtransformations) group within NXcoordinate_system. -# -# In effect, 1 should be the preferred choice. However, if more than one coordinate -# system is defined for practical purposes, explicit depends_on fields should -# always guide the user for each group and field which of the coordinate system -# one refers to. +# Base class to hold different coordinate systems and representation conversions. +# +# How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? +# +# * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across +# the application definition, an instance of NXcoordinate_system is defined, +# the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ +# coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and +# NXcoordinate_system base classes backwards compatible to older +# NeXus conventions and classes. +# * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed +# as high up in the node hierarchy (ideally right below an instance of NXentry) +# of the application definition tree as possible. +# This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system +# instance. This shall be named such that it is clear how this coordinate system is +# typically referred to in a community. For the NeXus `McStas coordinate system, it is +# advised to call it mcstas for the sake of improved clarity. +# Additional NXcoordinate_system instances should be specified if possible in that same +# :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. +# +# If this is the case, it is assumed that the NXcoordinate_system_members +# overwrite the NeXus default McStas coordinate system, i.e. users can thereby +# conveniently and explicitly specify the coordinate system(s) that +# they wish to use. +# +# Users are encouraged to write also explicit and clean depends_on fields in +# all groups that encode information about where the interpretation of coordinate +# systems is relevant. If these depends_on hints are not provided, it is +# automatically assumed that all children (to arbitrary depth) +# of that branch and sub-branches below the one in which that +# :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set +# instance in that set or the application definition is considered +# underconstrained which should at all costs be avoided and in which case +# again McStas is assumed. +# * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified +# somewhere in the tree, different interpretations are possible as to which +# of these coordinate system sets and instances apply or take preference. +# We realize that such ambiguities should at all costs be avoided. +# However, the opportunity for multiple sets and their instances enables to +# have branch-specific coordinate system conventions which could especially +# be useful for deep classes where multiple scientific methods are combined or +# cases where having a definition of global translation and conversion tables +# how to convert between representations in different coordinate systems +# is not desired or available for now. +# We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective +# NXcoordinate_system instances makes the interpretation eventually unnecessary +# complicated. Instead, developers of application definitions should always try +# to work for clarity and thus use only one top-level coordinate system set. +# +# For these reasons we conclude that the option with one top-level +# :ref:`NXcoordinate_system_set` instance is the preferred choice. +# +# McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance +# of NXcoordinate_system is specified. However, even in this case it is better +# to be explicit like for every other coordinate system definition to support +# users with interpreting the content and logic behind every instance of the tree. +# +# How to store coordinate systems inside :ref:`NXcoordinate_system_set`? +# Individual coordinate systems should be specified as members of the +# :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. +# +# How many individual instances of NXcoordinate_system to allow within one +# instance of :ref:`NXcoordinate_system_set`? +# +# * 0; This case should be avoided for the sake of clarity but this case could +# mean the authors of the definition meant that McStas is used. We conclude, +# McStas is used in this case. +# * 1; Like above-mentioned this case has the advantage that it is explicit +# and faces no ambiguities. However, in reality typically multiple +# coordinate systems have to be mastered especially for complex +# multi-signal modality experiments. +# * 2 or more; If this case is realized, the best practice is that in every +# case where a coordinate system should be referred to the respective class +# has a depends_on field which resolves the possible ambiguities which specific +# coordinate systems is referred to. The benefit of this explicit and clear +# specifying of the coordinate system used in every case is that especially +# in combination with having coordinate systems inside deeper branches +# makes up for a very versatile, backwards compatible, but powerful system +# to express different types of coordinate systems using NeXus. In the case +# of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, +# it is also advised to specify the relationship between the two coordinate systems by +# using the (NXtransformations) group within NXcoordinate_system. +# +# In effect, 1 should be the preferred choice. However, if more than one coordinate +# system is defined for practical purposes, explicit depends_on fields should +# always guide the user for each group and field which of the coordinate system +# one refers to. # # # -# Convention how a positive rotation angle is defined when viewing -# from the end of the rotation unit vector towards its origin, -# i.e. in accordance with convention 2 of -# DOI: 10.1088/0965-0393/23/8/083501. -# Counter_clockwise is equivalent to a right-handed choice. -# Clockwise is equivalent to a left-handed choice. +# Convention how a positive rotation angle is defined when viewing +# from the end of the rotation unit vector towards its origin, +# i.e. in accordance with convention 2 of +# DOI: 10.1088/0965-0393/23/8/083501. +# Counter_clockwise is equivalent to a right-handed choice. +# Clockwise is equivalent to a left-handed choice. # # # @@ -308,9 +309,9 @@ NXcoordinate_system_set(NXobject): # # # -# How are rotations interpreted into an orientation -# according to convention 3 of -# DOI: 10.1088/0965-0393/23/8/083501. +# How are rotations interpreted into an orientation +# according to convention 3 of +# DOI: 10.1088/0965-0393/23/8/083501. # # # @@ -320,12 +321,12 @@ NXcoordinate_system_set(NXobject): # # # -# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) -# according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. -# -# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge -# but other conventions are possible. Apart from undefined, proper Euler angles -# are distinguished from (improper) Tait-Bryan angles. +# How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) +# according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. +# +# The most frequently used convention is zxz, which is based on the work of H.-J. Bunge +# but other conventions are possible. Apart from undefined, proper Euler angles +# are distinguished from (improper) Tait-Bryan angles. # # # @@ -345,9 +346,9 @@ NXcoordinate_system_set(NXobject): # # # -# To which angular range is the rotation angle argument of an -# axis-angle pair parameterization constrained according to -# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. +# To which angular range is the rotation angle argument of an +# axis-angle pair parameterization constrained according to +# convention 5 of DOI: 10.1088/0965-0393/23/8/083501. # # # @@ -356,9 +357,9 @@ NXcoordinate_system_set(NXobject): # # # -# Which sign convention is followed when converting orientations -# between different parameterizations/representations according -# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. +# Which sign convention is followed when converting orientations +# between different parameterizations/representations according +# to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. # # # @@ -372,46 +373,46 @@ NXcoordinate_system_set(NXobject): # convention 1 of DOI: 10.1088/0965-0393/23/8/083501 is implemented by inheriting type from NXcoordinate_system--> # # -# Details about eventually relevant named directions that may give reasons for anisotropies. -# The classical example is mechanical processing where one has to specify which directions -# (e.g. rolling, transverse, and normal direction) align how with the direction of the base -# vectors of the sample_reference_frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xp, Yp, Zp. +# Details about eventually relevant named directions that may give reasons for anisotropies. +# The classical example is mechanical processing where one has to specify which directions +# (e.g. rolling, transverse, and normal direction) align how with the direction of the base +# vectors of the sample_reference_frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xp, Yp, Zp. # # # # -# Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xs, Ys, Zs. +# Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xs, Ys, Zs. # # -# +# # -# Details about the detector_reference_frame for a specific detector. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the -# base vectors of this coordinate system as Xd, Yd, Zd. -# -# It is assumed that the configuration is inspected by looking towards the sample surface -# from a position that is located behind the detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. +# Details about the detector_reference_frame for a specific detector. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the +# base vectors of this coordinate system as Xd, Yd, Zd. +# +# It is assumed that the configuration is inspected by looking towards the sample surface +# from a position that is located behind the detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. # # # diff --git a/contributed_definitions/nyaml/NXcorrector_cs.yaml b/contributed_definitions/nyaml/NXcorrector_cs.yaml index cd632bab12..ef7af464e0 100644 --- a/contributed_definitions/nyaml/NXcorrector_cs.yaml +++ b/contributed_definitions/nyaml/NXcorrector_cs.yaml @@ -33,6 +33,7 @@ NXcorrector_cs(NXcomponent): # NEW ISSUE: clarify further mathematical details tableauID(NXprocess): + nameType: partial doc: | Specific information about the alignment procedure that is a process during which the corrector is configured to enable calibrated usage of the instrument. @@ -190,7 +191,7 @@ NXcorrector_cs(NXcomponent): # (NXdeflector): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3439cb61c31d7e778f099baded9ce96f4400e478851e969e8df95fdb4cbc8534 +# f16d9020165764d31e620e069cfe55c84be31e050d1d27723e69392ee5aad332 # # # # # -# Was the corrector used? +# Was the corrector used? # # # -# +# # -# Specific information about the alignment procedure that is a process during which -# the corrector is configured to enable calibrated usage of the instrument. -# -# This :ref:`NXprocess` group should also be used when one describes in a computer -# simulation the specific details about the modelled or assumed aberration -# corrections. +# Specific information about the alignment procedure that is a process during which +# the corrector is configured to enable calibrated usage of the instrument. +# +# This :ref:`NXprocess` group should also be used when one describes in a computer +# simulation the specific details about the modelled or assumed aberration +# corrections. # # # -# Discouraged free-text field to add further details about the alignment -# procedure. +# Discouraged free-text field to add further details about the alignment +# procedure. # # # # -# The outer tilt angle of the beam in tableau acquisition. -# -# TODO: The relevant axes which span the tilt_angle need a -# cleaner description. +# The outer tilt angle of the beam in tableau acquisition. +# +# TODO: The relevant axes which span the tilt_angle need a +# cleaner description. # # # @@ -280,7 +281,7 @@ NXcorrector_cs(NXcomponent): # # # -# The exposure time of single tilt images. +# The exposure time of single tilt images. # # # @@ -288,8 +289,8 @@ NXcorrector_cs(NXcomponent): # # # -# The factor of enlargement of the apparent size, -# not the physical size, of an object. +# The factor of enlargement of the apparent size, +# not the physical size, of an object. # # # @@ -297,16 +298,16 @@ NXcorrector_cs(NXcomponent): # # # -# The images taken during the alignment procedure. +# The images taken during the alignment procedure. # # # # -# Place for storing measured or estimated aberrations (for each image or final). -# -# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) -# for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how -# to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. +# Place for storing measured or estimated aberrations (for each image or final). +# +# See `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) +# for different definitions available and further details. Table 7-2 of Ibid. publication (page 305ff) documents how +# to convert from the Nion to the CEOS definitions. Conversion tables are also summarized by `Y. Liao <https://www.globalsino.com/EM/page3740.html>`_. # # # @@ -316,13 +317,13 @@ NXcorrector_cs(NXcomponent): # # # +# unit: NX_LENGTH--> # # # # # +# unit: NX_LENGTH--> # # # +# unit: NX_LENGTH--> # # # # # # +# unit: NX_LENGTH--> # # # @@ -348,7 +349,7 @@ NXcorrector_cs(NXcomponent): # # # +# unit: NX_LENGTH--> # # # @@ -361,7 +362,7 @@ NXcorrector_cs(NXcomponent): # # # +# unit: NX_LENGTH--> # # # diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml index 72e30e9cfb..119b1b4510 100644 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ b/contributed_definitions/nyaml/NXcrystal_structure.yaml @@ -32,7 +32,7 @@ NXcrystal_structure(NXobject): doc: | Dimensionality of the lattice. enumeration: [1, 2, 3] - reference(NXidentifier): + identifier_reference: doc: | Reference to another resource that was used for instantiating this structure model. @@ -94,7 +94,7 @@ NXcrystal_structure(NXobject): doc: | True if space group is considered a chiral one. False if space group is consider a non-chiral one. - phase_identifier(NX_INT): + identifier_phase(NX_INT): unit: NX_UNITLESS doc: | Identifier for each phase. @@ -112,9 +112,9 @@ NXcrystal_structure(NXobject): doc: | Name of the phase/alias. - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): + If the ``identifier_phase`` is 0 and one would like to use the field + ``phase_name``, the value should be n/a. + identifier_atom(NX_CHAR): doc: | Label for each atom position. dimensions: @@ -200,7 +200,7 @@ NXcrystal_structure(NXobject): # more general this section # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 331ef8ebc71a35a2f696780c56e6dbc31208f8f92c27030eb644058cf6d863ca +# 526f6e3673763658915517d57560a4c16a2d2b8b1c09d9c2d3d13c4e361fb3e8 # # # -# +# # # Deflectors as they are used e.g. in an electron analyser. # @@ -94,14 +75,7 @@ NXdeflector(NXobject): # # # Colloquial or short name for the deflector. For manufacturer names and -# identifiers use respective manufacturer fields. -# -# -# -# -# -# Ideally an identifier, persistent link, or free text which gives -# further details about the deflector. +# identifiers use ``NXfabrication`` and ``identifierNAME``. # # # @@ -128,22 +102,4 @@ NXdeflector(NXobject): # ```offset_x```). # # -# -# -# Specifies the position of the deflector by pointing to the last transformation -# in the transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# :ref:`NXtransformations` base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# # diff --git a/contributed_definitions/nyaml/NXdispersive_material.yaml b/contributed_definitions/nyaml/NXdispersive_material.yaml index 36bdcb1543..5a5d270db5 100644 --- a/contributed_definitions/nyaml/NXdispersive_material.yaml +++ b/contributed_definitions/nyaml/NXdispersive_material.yaml @@ -16,6 +16,18 @@ NXdispersive_material(NXobject): URL where to find further material (documentation, examples) relevant to the application definition enumeration: [NXdispersive_material] + program(NX_CHAR): + exists: recommended + doc: | + Name of the program used for creating this dispersion + version(NX_CHAR): + exists: recommended + doc: | + Version of the program used + date(NX_DATE_TIME): + exists: recommended + doc: | + Date and time of creating this dispersion. sample(NXsample): chemical_formula(NX_CHAR): atom_types(NX_CHAR): @@ -51,6 +63,7 @@ NXdispersive_material(NXobject): Denotes whether the dispersion is calculated or derived from an experiment enumeration: [measured, simulated] REFERENCES(NXcite): + nameType: any exists: recommended text: doc: | @@ -181,8 +194,8 @@ NXdispersive_material(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4f3fc95aec07d53a2d94428b85e9d688d916fc69844200218b2202ad3fb0f5b0 -# +# b123f0263fcf5e72475ddff891063ed9c1c73d9e87688358988403c01c52504f +# # # -# +# # -# NXdispersion +# NXdispersion # # # # -# An application definition for a dispersive material. +# An application definition for a dispersive material. # # # -# Version number to identify which definition of this application definition was -# used for this entry/data. +# Version number to identify which definition of this application definition was +# used for this entry/data. # # # # -# URL where to find further material (documentation, examples) relevant to the -# application definition +# URL where to find further material (documentation, examples) relevant to the +# application definition # # # # # # +# +# +# Name of the program used for creating this dispersion +# +# +# +# +# Version of the program used +# +# +# +# +# Date and time of creating this dispersion. +# +# # # # # -# List of comma-separated elements from the periodic table -# that are contained in the sample. -# If the sample substance has multiple components, all -# elements from each component must be included in `atom_types`. +# List of comma-separated elements from the periodic table +# that are contained in the sample. +# If the sample substance has multiple components, all +# elements from each component must be included in `atom_types`. # # # # -# The colloquial name of the material, e.g. graphite or diamond for carbon. +# The colloquial name of the material, e.g. graphite or diamond for carbon. # # # # -# The phase of the material +# The phase of the material # # # @@ -258,47 +286,47 @@ NXdispersive_material(NXobject): # # # -# Additional information about the phase if the -# material phase is other. +# Additional information about the phase if the +# material phase is other. # # # # -# This field may be used to denote additional phase information, -# such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or -# if a measurement was done on a thin film or bulk material. +# This field may be used to denote additional phase information, +# such as crystalin phase of a crystal (e.g. 4H or 6H for SiC) or +# if a measurement was done on a thin film or bulk material. # # # # # -# Denotes whether the dispersion is calculated or derived from an experiment +# Denotes whether the dispersion is calculated or derived from an experiment # # # # # # -# +# # # -# A text description of this reference, e.g. -# `E. Example et al, The mighty example, An example journal 50 (2023), 100` +# A text description of this reference, e.g. +# `E. Example et al, The mighty example, An example journal 50 (2023), 100` # # # # # # -# The dispersion along the optical axis of the material. -# This should be the only dispersion available for isotropic materials. -# For uniaxial materials this denotes the ordinary axis. -# For biaxial materials this denotes the x axis or epsilon 11 tensor element -# of the diagionalized permittivity tensor. +# The dispersion along the optical axis of the material. +# This should be the only dispersion available for isotropic materials. +# For uniaxial materials this denotes the ordinary axis. +# For biaxial materials this denotes the x axis or epsilon 11 tensor element +# of the diagionalized permittivity tensor. # # # -# The name of this dispersion model. +# The name of this dispersion model. # # # @@ -330,13 +358,13 @@ NXdispersive_material(NXobject): # # # -# This should only be filled for biaxial materials. -# It denotes the epsilon 22 direction of the diagionalized -# permittivity tensor. +# This should only be filled for biaxial materials. +# It denotes the epsilon 22 direction of the diagionalized +# permittivity tensor. # # # -# The name of this dispersion model. +# The name of this dispersion model. # # # @@ -368,14 +396,14 @@ NXdispersive_material(NXobject): # # # -# This should only be filled for uniaxial or biaxial materials. -# For uniaxial materials this denotes the extraordinary axis. -# For biaxial materials this denotes the epsilon 33 tensor element -# of the diagionalized perimittivty tensor. +# This should only be filled for uniaxial or biaxial materials. +# For uniaxial materials this denotes the extraordinary axis. +# For biaxial materials this denotes the epsilon 33 tensor element +# of the diagionalized perimittivty tensor. # # # -# The name of this dispersion model. +# The name of this dispersion model. # # # diff --git a/contributed_definitions/nyaml/NXebeam_column.yaml b/contributed_definitions/nyaml/NXebeam_column.yaml index f11a028648..d86b7d7656 100644 --- a/contributed_definitions/nyaml/NXebeam_column.yaml +++ b/contributed_definitions/nyaml/NXebeam_column.yaml @@ -2,10 +2,10 @@ category: base doc: | Base class for a set of components providing a controllable electron beam. -# NXebeam_column is an NXobject instead of an NXcomponent to make that -# part "an electron gun" reusable in other context +# symbols: +# doc: The symbols used in the schema to specify e.g. variables. type: group -NXebeam_column(NXobject): +NXebeam_column(NXcomponent): operation_mode(NX_CHAR): doc: | Typically tech-partner, microscope-, and control software-specific @@ -76,7 +76,7 @@ NXebeam_column(NXobject): (NXdeflector): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2a4631ba2df234444dfb57c6b48772101ff1f9eec7e84797f19ef820f810d741 +# ea5b38d017e38c479f28b8c793115e2860c2c2facfb3ab3316d5e237c54382b4 # # # -# -# +# +# # # Base class for a set of components providing a controllable electron beam. # diff --git a/contributed_definitions/nyaml/NXelectronanalyser.yaml b/contributed_definitions/nyaml/NXelectronanalyser.yaml index d3f5252195..b1ba90c8f5 100644 --- a/contributed_definitions/nyaml/NXelectronanalyser.yaml +++ b/contributed_definitions/nyaml/NXelectronanalyser.yaml @@ -18,7 +18,7 @@ symbols: n_transmission_function: | Number of data points in the transmission function. type: group -NXelectronanalyser(NXobject): +NXelectronanalyser(NXcomponent): description(NX_CHAR): doc: | Free text description of the type of the detector @@ -179,31 +179,6 @@ NXelectronanalyser(NXobject): dimensions: rank: 1 dim: (n_transmission_function,) - depends_on(NX_CHAR): - doc: | - Refers to the last transformation specifying the position of the electron analyser - in the NXtransformations chain. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or "." (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - \@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. (NXcollectioncolumn): doc: | Describes the electron collection (spatial and momentum imaging) column @@ -228,7 +203,7 @@ NXelectronanalyser(NXobject): Any other resolution not explicitly named in this base class. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 13dca83f412e8007f07d136ac9f60b641adef1fd65b902554bb9c43f06ea5c25 +# 1d17a38035e5850cc1e2de2d6a827035bc67a90048a7a385808e75ce0ac4b0f0 # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays @@ -471,37 +446,6 @@ NXelectronanalyser(NXobject): # # # -# -# -# Refers to the last transformation specifying the position of the electron analyser -# in the NXtransformations chain. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the electron analyser as a component in the instrument. Conventions -# from the NXtransformations base class are used. In principle, the McStas -# coordinate system is used. The first transformation has to point either to -# another component of the system or "." (for pointing to the reference frame) to -# relate it relative to the experimental setup. Typically, the components of a -# system should all be related relative to each other and only one component -# 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 diff --git a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml index 71c10c7e63..2f87b56752 100644 --- a/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml +++ b/contributed_definitions/nyaml/NXelectrostatic_kicker.yaml @@ -2,7 +2,7 @@ category: base doc: | definition for a electrostatic kicker. type: group -NXelectrostatic_kicker(NXobject): +NXelectrostatic_kicker(NXcomponent): description(NX_CHAR): doc: | extended description of the kicker. @@ -41,13 +41,13 @@ NXelectrostatic_kicker(NXobject): unit: NX_VOLTAGE # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a3d72e81674caa0cf1e7ade8d63eb49091b9601509572b6d60147cbfa3f2e192 +# 12d2b86ccd899f77b1c75a61f2cf4353f304c73c7a56a725887133f426cf3046 # # # -# # # +# Make ois maybe similar to NXdata_mpes. In this way, at all FAIR assignments of the data is possible. As well use this to guide the people, to let them know, where they have to save their data. Just use NXdata is too vague. Could be easing the threshold to get into NeXus. +# This explicitly refers to a wish to add: "exposure time, number of scans"--> # # # -# Variables used throughout the document, e.g. dimensions or parameters. +# Variables used throughout the document, e.g. dimensions or parameters. # # # -# Length of the spectrum array (e.g. wavelength or energy) of the measured -# data. +# Length of the spectrum array (e.g. wavelength or energy) of the measured +# data. # # # # -# Number of measurements (1st dimension of measured_data array). This is -# equal to the number of parameters scanned. For example, if the experiment -# was performed at three different temperatures and two different pressures -# N_measurements = 2*3 = 6. +# Number of measurements (1st dimension of measured_data array). This is +# equal to the number of parameters scanned. For example, if the experiment +# was performed at three different temperatures and two different pressures +# N_measurements = 2*3 = 6. # # # # -# Number of detection angles of the beam reflected or scattered off the -# sample. +# Number of detection angles of the beam reflected or scattered off the +# sample. # # # # -# Number of angles of incidence of the incident beam. +# Number of angles of incidence of the incident beam. # # # # -# This is the application definition describing ellipsometry experiments. -# -# Such experiments may be as simple as identifying how a reflected -# beam of light with a single wavelength changes its polarization state, -# to a variable angle spectroscopic ellipsometry experiment. -# -# The application definition specifies optical spectroscopy (NXopt), by extending -# the terms and setting specific requirements. -# -# Information on ellipsometry is provided, e.g. in: -# -# * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, -# John Wiley & Sons, 2007. -# * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, -# North-Holland Publishing Company, 1977. -# * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, -# William Andrew, 2005. -# -# Open access sources: -# -# * https://www.angstromadvanced.com/resource.asp -# * https://pypolar.readthedocs.io/en/latest/ -# -# Review articles: -# -# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", -# J. Phys. D: Appl. Phys. 32, R45 (1999), -# https://doi.org/10.1088/0022-3727/32/9/201 -# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", -# Thin Solid Films 571, 334-344 (2014), -# https://doi.org/10.1016/j.tsf.2014.03.056 -# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", -# Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, -# (3 October 1997), -# https://doi.org/10.1117/12.283870 -# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", -# Thin Solid Films 233, 96-111 (1993), -# https://doi.org/10.1016/0040-6090(93)90069-2 -# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", -# Adv. Opt. Techn., (2022), -# https://doi.org/10.1515/aot-2022-0016 +# This is the application definition describing ellipsometry experiments. +# +# Such experiments may be as simple as identifying how a reflected +# beam of light with a single wavelength changes its polarization state, +# to a variable angle spectroscopic ellipsometry experiment. +# +# The application definition specifies optical spectroscopy (NXopt), by extending +# the terms and setting specific requirements. +# +# Information on ellipsometry is provided, e.g. in: +# +# * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, +# John Wiley & Sons, 2007. +# * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, +# North-Holland Publishing Company, 1977. +# * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, +# William Andrew, 2005. +# +# Open access sources: +# +# * https://www.angstromadvanced.com/resource.asp +# * https://pypolar.readthedocs.io/en/latest/ +# +# Review articles: +# +# * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", +# J. Phys. D: Appl. Phys. 32, R45 (1999), +# https://doi.org/10.1088/0022-3727/32/9/201 +# * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", +# Thin Solid Films 571, 334-344 (2014), +# https://doi.org/10.1016/j.tsf.2014.03.056 +# * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", +# Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, +# (3 October 1997), +# https://doi.org/10.1117/12.283870 +# * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", +# Thin Solid Films 233, 96-111 (1993), +# https://doi.org/10.1016/0040-6090(93)90069-2 +# * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", +# Adv. Opt. Techn., (2022), +# https://doi.org/10.1515/aot-2022-0016 # # # # -# An application definition for ellipsometry. +# An application definition for ellipsometry. # # # -# Version number to identify which definition of this application -# definition was used for this entry/data. +# Version number to identify which definition of this application +# definition was used for this entry/data. # # # # -# URL where to find further material (documentation, examples) relevant -# to the application definition. +# URL where to find further material (documentation, examples) relevant +# to the application definition. # # # @@ -438,9 +438,9 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# Specify the type of the optical experiment. -# -# You may specify fundamental characteristics or properties in the experimental sub-type. +# Specify the type of the optical experiment. +# +# You may specify fundamental characteristics or properties in the experimental sub-type. # # # @@ -448,7 +448,7 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# Specify the type of ellipsometry. +# Specify the type of ellipsometry. # # # @@ -462,16 +462,16 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# If the ellipsometry_experiment_type is `other`, a name should be specified here. +# If the ellipsometry_experiment_type is `other`, a name should be specified here. # # # # -# Properties of the ellipsometry equipment. +# Properties of the ellipsometry equipment. # # # -# What type of ellipsometry was used? See Fujiwara Table 4.2. +# What type of ellipsometry was used? See Fujiwara Table 4.2. # # # @@ -491,13 +491,13 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# If the ellipsometer_type is `other`, a specific ellipsometry_type" should be -# added here. +# If the ellipsometer_type is `other`, a specific ellipsometry_type" should be +# added here. # # # # -# Define which element rotates, e.g. polarizer or analyzer. +# Define which element rotates, e.g. polarizer or analyzer. # # # @@ -508,8 +508,8 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# If focussing probes (lenses) were used, please state if the data -# were corrected for the window effects. +# If focussing probes (lenses) were used, please state if the data +# were corrected for the window effects. # # # @@ -523,39 +523,39 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# Were the recorded data corrected by the window effects of the -# focussing probes (lenses)? +# Were the recorded data corrected by the window effects of the +# focussing probes (lenses)? # # # # -# Specify the angular spread caused by the focussing probes. +# Specify the angular spread caused by the focussing probes. # # # # # -# Properties of the rotating element defined in -# 'instrument/rotating_element_type'. +# Properties of the rotating element defined in +# 'instrument/rotating_element_type'. # # # -# Define how many revolutions of the rotating element were averaged -# for each measurement. If the number of revolutions was fixed to a -# certain value use the field 'fixed_revolutions' instead. +# Define how many revolutions of the rotating element were averaged +# for each measurement. If the number of revolutions was fixed to a +# certain value use the field 'fixed_revolutions' instead. # # # # -# Define how many revolutions of the rotating element were taken -# into account for each measurement (if number of revolutions was -# fixed to a certain value, i.e. not averaged). +# Define how many revolutions of the rotating element were taken +# into account for each measurement (if number of revolutions was +# fixed to a certain value, i.e. not averaged). # # # # -# Specify the maximum value of revolutions of the rotating element -# for each measurement. +# Specify the maximum value of revolutions of the rotating element +# for each measurement. # # # @@ -563,8 +563,8 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# Was the backside of the sample roughened? Relevant for infrared -# ellipsometry. +# Was the backside of the sample roughened? Relevant for infrared +# ellipsometry. # # # @@ -575,32 +575,32 @@ NXellipsometry(NXoptical_spectroscopy): # NXellipsometry.--> # # -# Measured data, data errors, and varied parameters. This may be used to describe -# indirectly derived data or data transformed between different descriptions, -# such as: -# Raw Data --> Psi -# Delta Psi, Delta --> N,C,S -# Mueller matrix --> N,C,S -# Mueller matrix --> Psi, Delta -# etc. -# -# Other types of data, such as temperature or sample location, may be saved -# in a generic (NXdata) concept from NXopt, or better directly in the -# location of the sample positioner or temperature sensor. +# Measured data, data errors, and varied parameters. This may be used to describe +# indirectly derived data or data transformed between different descriptions, +# such as: +# Raw Data --> Psi +# Delta Psi, Delta --> N,C,S +# Mueller matrix --> N,C,S +# Mueller matrix --> Psi, Delta +# etc. +# +# Other types of data, such as temperature or sample location, may be saved +# in a generic (NXdata) concept from NXopt, or better directly in the +# location of the sample positioner or temperature sensor. # # # -# An identifier to correlate data to the experimental conditions, -# if several were used in this measurement; typically an index of 0-N. +# An identifier to correlate data to the experimental conditions, +# if several were used in this measurement; typically an index of 0-N. # # # # -# Select which type of data was recorded, for example intensity, -# reflectivity, transmittance, Psi and Delta etc. -# It is possible to have multiple selections. The enumeration list -# depends on the type of experiment and may differ for different -# application definitions. +# Select which type of data was recorded, for example intensity, +# reflectivity, transmittance, Psi and Delta etc. +# It is possible to have multiple selections. The enumeration list +# depends on the type of experiment and may differ for different +# application definitions. # # # @@ -614,36 +614,36 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# +# # -# Spectral values (e.g. wavelength or energy) used for the measurement. -# An array of 1 or more elements. Length defines N_spectrum. Replace -# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. +# Spectral values (e.g. wavelength or energy) used for the measurement. +# An array of 1 or more elements. Length defines N_spectrum. Replace +# 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. # # # # # # -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. # # # # # -# Resulting data from the measurement, described by 'data_type'. -# -# The first dimension is defined by the number of measurements taken, -# (N_measurements). The instructions on how to order the values -# contained in the parameter vectors given in the doc string of -# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, -# define the N_measurements parameter sets. For example, if the -# experiment was performed at three different temperatures -# (T1, T2, T3), two different pressures (p1, p2) and two different -# angles of incidence (a1, a2), the first measurement was taken at the -# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. +# Resulting data from the measurement, described by 'data_type'. +# +# The first dimension is defined by the number of measurements taken, +# (N_measurements). The instructions on how to order the values +# contained in the parameter vectors given in the doc string of +# INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, +# define the N_measurements parameter sets. For example, if the +# experiment was performed at three different temperatures +# (T1, T2, T3), two different pressures (p1, p2) and two different +# angles of incidence (a1, a2), the first measurement was taken at the +# parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. # # # @@ -652,16 +652,16 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. # # # # # -# Specified uncertainties (errors) of the data described by 'data_type' -# and provided in 'measured_data'. +# Specified uncertainties (errors) of the data described by 'data_type' +# and provided in 'measured_data'. # # # @@ -670,16 +670,16 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. -# If the unit of the measured data is not covered by NXDL units state -# here which unit was used. +# If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. +# If the unit of the measured data is not covered by NXDL units state +# here which unit was used. # # # # # -# List of links to the values of the sensors. Add a link for each -# varied parameter (i.e. for each sensor). +# List of links to the values of the sensors. Add a link for each +# varied parameter (i.e. for each sensor). # # # @@ -687,35 +687,35 @@ NXellipsometry(NXoptical_spectroscopy): # # # -# Link to the NeXus file which describes the reference data if a -# reference measurement was performed. Ideally, the reference -# measurement was performed using the same conditions as the actual -# measurement and should be as close in time to the actual measurement -# as possible. +# Link to the NeXus file which describes the reference data if a +# reference measurement was performed. Ideally, the reference +# measurement was performed using the same conditions as the actual +# measurement and should be as close in time to the actual measurement +# as possible. # # # # # -# Commercial or otherwise defined given name of the program that was -# used to generate the result file(s) with measured data and/or -# metadata (in most cases, this is the same as INSTRUMENT/software). -# If home written, one can provide the actual steps in the NOTE -# subfield here. +# Commercial or otherwise defined given name of the program that was +# used to generate the result file(s) with measured data and/or +# metadata (in most cases, this is the same as INSTRUMENT/software). +# If home written, one can provide the actual steps in the NOTE +# subfield here. # # # # -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. # # # # -# Website of the software. +# Website of the software. # # # diff --git a/contributed_definitions/nyaml/NXem.yaml b/contributed_definitions/nyaml/NXem.yaml index 8f627949b3..3a76a7eb99 100644 --- a/contributed_definitions/nyaml/NXem.yaml +++ b/contributed_definitions/nyaml/NXem.yaml @@ -37,6 +37,7 @@ NXem(NXobject): The configuration of the I/O writer software (e.g. `pynxtools `_ or its plugins) which was used to generate this NeXus file instance. programID(NXprogram): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | A collection of all programs and libraries that are considered as relevant @@ -55,7 +56,7 @@ NXem(NXobject): repository commit and respective submodule references used. program(NX_CHAR): \@version(NX_CHAR): - experiment_identifier(NXidentifier): + identifier_experiment: exists: recommended doc: | Ideally, a (globally) unique persistent identifier for referring to this experiment. @@ -67,9 +68,6 @@ NXem(NXobject): The identifier is usually issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments/simulations to e.g. proposals. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): experiment_alias(NX_CHAR): doc: | Alias which scientists can easier identify this experiment by. @@ -112,8 +110,10 @@ NXem(NXobject): See docstring of the start_time field to see how to use the start_time and end_time together. citeID(NXcite): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] - serializedID(NXserialized): + serializedID(NXnote): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Possibility to store a collection of serialized resources associated with the @@ -123,13 +123,14 @@ NXem(NXobject): e.g. generated by software of technology partners, the information in an instance of NXem was filled with during parsing or transcoding between different formats. type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): # this is one of the few examples where groups may end up without fields because # for reasons of not breaking GDPR compliance userID(NXuser): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Information about persons who performed or were involved in the microscope @@ -166,15 +167,12 @@ NXem(NXobject): Examples are technician operating the microscope, student, postdoc, principle investigator, or guest. - identifier(NXidentifier): + identifier: exists: optional doc: | Identifier offered by a service to report the user other than by using its name. Examples could be an ORCID or social media account of the user. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): sample(NXsample): doc: - | @@ -189,7 +187,7 @@ NXem(NXobject): doc: | Qualifier whether the sample is a real or a virtual one. enumeration: [experiment, simulation] - identifier(NXidentifier): + identifier: exists: recommended doc: | Ideally, (globally) unique persistent identifier which distinguishes the sample from all others @@ -203,19 +201,13 @@ NXem(NXobject): NXentry should be used for the characterization of a single specimen. Details about the specimen preparation should be stored in resources referring to parent_identifier. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): - parent_identifier(NXidentifier): + identifier_parent: exists: recommended doc: | Identifier of the sample from which the sample was cut or the string *None*. The purpose of this field is to support functionalities for tracking sample provenance in a research data management system. - service(NX_CHAR): - identifier(NX_CHAR): - is_persistent(NX_BOOLEAN): preparation_date(NX_DATE_TIME): doc: | ISO 8601 time code with local time zone offset to UTC information @@ -224,7 +216,7 @@ NXem(NXobject): Ideally, report the end of the preparation, i.e. the last known timestamp when the measured specimen surface was actively prepared. Ideally, this matches the last timestamp that is mentioned in the digital resource pointed to by - parent_identifier. + identifier_parent. Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as specimen charged with hydrogen @@ -245,7 +237,7 @@ NXem(NXobject): The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources - pointed to by parent_identifier or walk through eventually deeply nested groups in + pointed to by identifier_parent or walk through eventually deeply nested groups in individual data instances. thickness(NX_NUMBER): exists: optional @@ -290,7 +282,7 @@ NXem(NXobject): exists: optional doc: | Discouraged free-text field to provide further detail although adding - parent_identifier and having a working research data management system + identifier_parent and having a working research data management system should provide this contextualization. coordinate_system_set(NXcoordinate_system_set): exists: ['min', '1', 'max', '1'] @@ -384,6 +376,7 @@ NXem(NXobject): sample_reference_frame. enumeration: [undefined, north, east, south, west, in, out] detector_reference_frameID(NXcoordinate_system): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] depends_on(NX_CHAR): exists: optional @@ -437,9 +430,10 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended control_programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Details about the control program used for operating the microscope. @@ -452,10 +446,11 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended electron_source(NXsource): - doc: | xref: + doc: | + xref: spec: EMglossary term: Source url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 @@ -467,7 +462,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended # fabrication is an example which shows when one needs to specify in the appdef if some of the @@ -476,22 +471,25 @@ NXem(NXobject): # i.e. use NXfabrication from NXsource but demand it to be labelled with the symbol fabrication # likewise if you provide fabrication details you need to provide vendor and model but not necessarily identifier lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Device for improving energy resolution or reducing chromatic aberration. @@ -511,7 +509,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended corrector_cs(NXcorrector_cs): exists: ['min', '0', 'max', '1'] @@ -519,7 +517,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended corrector_ax(NXcomponent): exists: ['min', '0', 'max', '1'] @@ -534,7 +532,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended biprism(NXcomponent): exists: optional @@ -544,7 +542,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended # contributed definition NXwaveplate is a closely related concept but may fit even better but waveplate @@ -554,6 +552,7 @@ NXem(NXobject): # but both concepts have in common that they can be assumed to be specialization of a super class # lenses i.e. devices which can affect the pathes of beams phaseplateID(NXcomponent): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Device that causes a change in the phase of an electron wave. @@ -568,11 +567,13 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] ibeam_column(NXibeam_column): exists: ['min', '0', 'max', '1'] @@ -584,27 +585,30 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended ion_source(NXsource): probe(NXion): lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Device for improving energy resolution or reducing chromatic aberration. @@ -619,29 +623,29 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended # device for correcting axial astigmatism of ion beam? sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] detectorID(NXdetector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] fabrication(NXfabrication): vendor(NX_CHAR): model(NX_CHAR): - - # identifier(NXidentifier): # only relevant when deprecating serial_number - # exists: recommended scan_controller(NXscanbox_em): exists: optional fabrication(NXfabrication): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended (NXsensor): exists: ['min', '0', 'max', 'unbounded'] @@ -653,7 +657,7 @@ NXem(NXobject): exists: optional vendor(NX_CHAR): model(NX_CHAR): - identifier(NXidentifier): + identifier: exists: recommended (NXchamber): exists: ['min', '0', 'max', 'unbounded'] @@ -672,20 +676,22 @@ NXem(NXobject): (NXimage_set): exists: ['min', '0', 'max', 'unbounded'] (NXprocess): - source(NXserialized): + source(NXnote): exists: recommended type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): absolute_path(NX_CHAR): exists: recommended - detector_identifier(NX_CHAR): + identifier_detector: + exists: recommended image_1d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -705,6 +711,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -726,6 +733,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -749,6 +757,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -761,10 +770,10 @@ NXem(NXobject): intensity(NX_NUMBER): exists: optional \@long_name(NX_CHAR): - group_identifier(NX_INT): + identifier_group(NX_INT): exists: optional \@long_name(NX_CHAR): - image_identifier(NX_INT): + identifier_image(NX_INT): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): @@ -773,6 +782,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -785,10 +795,10 @@ NXem(NXobject): intensity(NX_NUMBER): exists: optional \@long_name(NX_CHAR): - group_identifier(NX_INT): + identifier_group(NX_INT): exists: optional \@long_name(NX_CHAR): - image_identifier(NX_INT): + identifier_image(NX_INT): \@long_name(NX_CHAR): axis_j(NX_NUMBER): \@long_name(NX_CHAR): @@ -799,6 +809,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): real(NX_NUMBER): \@long_name(NX_CHAR): @@ -811,10 +822,10 @@ NXem(NXobject): intensity(NX_NUMBER): exists: optional \@long_name(NX_CHAR): - group_identifier(NX_INT): + identifier_group(NX_INT): exists: optional \@long_name(NX_CHAR): - image_identifier(NX_INT): + identifier_image(NX_INT): \@long_name(NX_CHAR): axis_k(NX_NUMBER): \@long_name(NX_CHAR): @@ -825,20 +836,21 @@ NXem(NXobject): (NXspectrum_set): exists: ['min', '0', 'max', 'unbounded'] (NXprocess): - source(NXserialized): + source(NXnote): exists: recommended type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): absolute_path(NX_CHAR): exists: recommended - detector_identifier(NX_CHAR): + identifier_detector(NX_CHAR): spectrum_0d(NXdata): exists: optional \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): @@ -849,6 +861,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): @@ -861,6 +874,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): @@ -875,6 +889,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): @@ -891,10 +906,11 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): + identifier_spectrum(NX_INT): \@long_name(NX_CHAR): axis_energy(NX_NUMBER): \@long_name(NX_CHAR): @@ -903,10 +919,11 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): + identifier_spectrum(NX_INT): \@long_name(NX_CHAR): axis_i(NX_NUMBER): \@long_name(NX_CHAR): @@ -917,10 +934,11 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): + identifier_spectrum(NX_INT): \@long_name(NX_CHAR): axis_j(NX_NUMBER): \@long_name(NX_CHAR): @@ -933,10 +951,11 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_INT): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): \@long_name(NX_CHAR): - spectrum_identifier(NX_INT): + identifier_spectrum(NX_INT): \@long_name(NX_CHAR): axis_k(NX_NUMBER): \@long_name(NX_CHAR): @@ -951,7 +970,8 @@ NXem(NXobject): ebeam_column(NXebeam_column): operation_mode(NX_CHAR): electron_source(NXsource): - doc: | xref: + doc: | + xref: spec: EMglossary term: Source url: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 @@ -999,9 +1019,11 @@ NXem(NXobject): term: Filament Current url: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): unit: NX_ANY @@ -1020,6 +1042,7 @@ NXem(NXobject): However, if more details are known or should be documented one should use the description field for this. monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: | Device to improve energy resolution or chromatic aberration. @@ -1049,6 +1072,7 @@ NXem(NXobject): applied(NX_BOOLEAN): exists: recommended tableauID(NXprocess): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] # model(NX_CHAR): @@ -1203,14 +1227,18 @@ NXem(NXobject): biprism(NXcomponent): exists: ['min', '0', 'max', '1'] phaseplateID(NXcomponent): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] (NXbeam): exists: ['min', '0', 'max', 'unbounded'] - doc: | xref: + doc: | + xref: spec: EMglossary term: Electron Beam url: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 @@ -1220,9 +1248,11 @@ NXem(NXobject): probe(NXion): voltage(NX_NUMBER): lensID(NXlens_em): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): apertureID(NXaperture): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] value(NX_NUMBER): unit: NX_ANY @@ -1241,15 +1271,19 @@ NXem(NXobject): However, if more details are known or should be documented one should use the description field for this. monochromatorID(NXmonochromator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] applied(NX_BOOLEAN): sensorID(NXsensor): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] actuatorID(NXactuator): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] (NXbeam): exists: ['min', '0', 'max', 'unbounded'] detectorID(NXdetector): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] mode(NX_CHAR): scan_controller(NXscanbox_em): @@ -1291,6 +1325,7 @@ NXem(NXobject): # but normalized in its representation ready to be consumed for a # research data management system roiID(NXroi): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] doc: - | @@ -1315,6 +1350,7 @@ NXem(NXobject): exists: optional # microstructureID(NXmicrostructure): + # nameType: partial # exists: optional ebsd(NXem_ebsd): exists: optional @@ -1339,17 +1375,17 @@ NXem(NXobject): measurement(NXprocess): exists: optional depends_on(NX_CHAR): - source(NXserialized): + source(NXnote): type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): simulation(NXprocess): exists: optional depends_on(NX_CHAR): - source(NXserialized): + source(NXnote): type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): indexing(NXprocess): @@ -1357,28 +1393,31 @@ NXem(NXobject): number_of_scan_points(NX_UINT): indexing_rate(NX_NUMBER): exists: recommended - source(NXserialized): + source(NXnote): exists: optional type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): phaseID(NXcrystal_structure): + nameType: partial exists: ['min', '0', 'max', 'unbounded'] number_of_scan_points(NX_UINT): a_b_c(NX_NUMBER): alpha_beta_gamma(NX_NUMBER): space_group(NX_CHAR): - phase_identifier(NX_INT): + identifier_phase(NX_INT): phase_name(NX_CHAR): # ipfID(NXmicrostructure_ipf): + # nameType: partial # exists: recommended # projection_direction(NX_NUMBER): # map(NXdata): # \@signal(NX_CHAR): # \@axes(NX_CHAR): # \@AXISNAME_indices(NX_INT): + # nameType: partial # title(NX_CHAR): # data(NX_NUMBER): # \@long_name(NX_CHAR): @@ -1394,6 +1433,7 @@ NXem(NXobject): # \@signal(NX_CHAR): # \@axes(NX_CHAR): # \@AXISNAME_indices(NX_INT): + # nameType: partial # title(NX_CHAR): # data(NX_NUMBER): # \@long_name(NX_CHAR): @@ -1406,6 +1446,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): descriptor(NX_CHAR): data(NX_NUMBER): @@ -1423,6 +1464,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): intensity(NX_NUMBER): axis_energy(NX_CHAR): @@ -1437,6 +1479,7 @@ NXem(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): exists: optional intensity(NX_NUMBER): @@ -1459,7 +1502,7 @@ NXem(NXobject): # in https://github.com/FAIRmat-NFDI/nexus_definitions/commit/0b928c4352bc5636f673b5fb25ce990f1af8a099 # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9d9e4ed7006a78cf61ba9e90a78179579df457c2b0f754e506d512c7f231e3fe +# 935d30bbf847d5225eb415457d6393a37e753d89b5a1410521f2924e3a9aeab2 # # # # # -# Application definition for normalized representation of electron microscopy research. -# -# This application definition is a comprehensive example for a general description -# with which to normalize specific pieces of information and data collected within -# electron microscopy research. -# -# NXem is designed to be used for documenting experiments or computer simulations in which -# controlled electron beams are used for studying electron-beam matter interaction to explore -# physical mechanisms and phenomena, or to characterize materials with an electron microscope. +# Application definition for normalized representation of electron microscopy research. +# +# This application definition is a comprehensive example for a general description +# with which to normalize specific pieces of information and data collected within +# electron microscopy research. +# +# NXem is designed to be used for documenting experiments or computer simulations in which +# controlled electron beams are used for studying electron-beam matter interaction to explore +# physical mechanisms and phenomena, or to characterize materials with an electron microscope. # # # # @@ -1517,262 +1560,248 @@ NXem(NXobject): # # # -# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) -# which was used to generate this NeXus file instance. +# The configuration of the I/O writer software (e.g. `pynxtools <https://github.com/FAIRmat-NFDI/pynxtools>`_ or its plugins) +# which was used to generate this NeXus file instance. # -# +# # -# A collection of all programs and libraries that are considered as relevant -# to understand with which software tools this NeXus file instance was -# generated. Ideally, to enable a binary recreation from the input data. -# -# Examples include the name and version of the libraries used to write the -# instance. Ideally, the software which writes these NXprogram instances -# also includes the version of the set of NeXus classes i.e. the specific -# set of base classes, application definitions, and contributed definitions -# with which the here described concepts can be resolved. -# -# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ -# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ -# research data management system, it makes sense to store e.g. the GitHub -# repository commit and respective submodule references used. +# A collection of all programs and libraries that are considered as relevant +# to understand with which software tools this NeXus file instance was +# generated. Ideally, to enable a binary recreation from the input data. +# +# Examples include the name and version of the libraries used to write the +# instance. Ideally, the software which writes these NXprogram instances +# also includes the version of the set of NeXus classes i.e. the specific +# set of base classes, application definitions, and contributed definitions +# with which the here described concepts can be resolved. +# +# For the `pynxtools library <https://github.com/FAIRmat-NFDI/pynxtools>`_ +# which is used by the `NOMAD <https://nomad-lab.eu/nomad-lab>`_ +# research data management system, it makes sense to store e.g. the GitHub +# repository commit and respective submodule references used. # # # # # # -# +# # -# Ideally, a (globally) unique persistent identifier for referring to this experiment. -# -# An experiment should be understood in that this can be an experiment -# in reality or a computer simulation because also the latter is an experiment -# (see the Cambridge Dictionary experiment *a test done in order to find out -# something, eg if an idea is correct*). -# -# The identifier is usually issued by the facility, laboratory, or the principle investigator. -# The identifier enables to link experiments/simulations to e.g. proposals. +# Ideally, a (globally) unique persistent identifier for referring to this experiment. +# +# An experiment should be understood in that this can be an experiment +# in reality or a computer simulation because also the latter is an experiment +# (see the Cambridge Dictionary experiment *a test done in order to find out +# something, eg if an idea is correct*). +# +# The identifier is usually issued by the facility, laboratory, or the principle investigator. +# The identifier enables to link experiments/simulations to e.g. proposals. # -# -# -# -# +# # # -# Alias which scientists can easier identify this experiment by. +# Alias which scientists can easier identify this experiment by. # # # # -# Free-text description about the experiment. -# -# Users are strongly advised to parameterize the description of their experiment -# by using respective groups and fields and base classes instead of writing prose -# into the field. The reason is that such free-text field is difficult to machine-interpret. -# The motivation behind keeping this field for now is to learn in how far the -# current base classes need extension based on user feedback. +# Free-text description about the experiment. +# +# Users are strongly advised to parameterize the description of their experiment +# by using respective groups and fields and base classes instead of writing prose +# into the field. The reason is that such free-text field is difficult to machine-interpret. +# The motivation behind keeping this field for now is to learn in how far the +# current base classes need extension based on user feedback. # # # # -# ISO 8601 time code with local time zone offset to UTC information included -# when the microscope session started. If the application demands that time -# codes in this section of the application definition should only be used -# for specifying when the experiment was performed - and the exact -# duration is not relevant use this start_time field. -# -# Often though it is useful to specify a time interval via setting both a start_time -# and an end_time because this enables software tools and users to collect a -# more detailed bookkeeping of the experiment. -# -# Users should be aware though that even with having both time instances -# specified, it may not be possible to infer how long the experiment took or -# for how long data were acquired. -# -# More detailed timing data over the course of the experiment have -# to be collected to compute this. These computations can take -# advantage of individual time stamps start_time and end_time -# in :ref:`NXevent_data_em` instances. +# ISO 8601 time code with local time zone offset to UTC information included +# when the microscope session started. If the application demands that time +# codes in this section of the application definition should only be used +# for specifying when the experiment was performed - and the exact +# duration is not relevant use this start_time field. +# +# Often though it is useful to specify a time interval via setting both a start_time +# and an end_time because this enables software tools and users to collect a +# more detailed bookkeeping of the experiment. +# +# Users should be aware though that even with having both time instances +# specified, it may not be possible to infer how long the experiment took or +# for how long data were acquired. +# +# More detailed timing data over the course of the experiment have +# to be collected to compute this. These computations can take +# advantage of individual time stamps start_time and end_time +# in :ref:`NXevent_data_em` instances. # # # # -# ISO 8601 time code with local time zone offset to UTC included when -# the microscope session ended. -# -# See docstring of the start_time field to see how to use the -# start_time and end_time together. +# ISO 8601 time code with local time zone offset to UTC included when +# the microscope session ended. +# +# See docstring of the start_time field to see how to use the +# start_time and end_time together. # # -# -# +# +# # -# Possibility to store a collection of serialized resources associated with the -# experiment. -# -# An example how to use this set could be to document from which files, which have been -# e.g. generated by software of technology partners, the information in an instance of -# NXem was filled with during parsing or transcoding between different formats. +# Possibility to store a collection of serialized resources associated with the +# experiment. +# +# An example how to use this set could be to document from which files, which have been +# e.g. generated by software of technology partners, the information in an instance of +# NXem was filled with during parsing or transcoding between different formats. # # -# +# # # # -# -# +# +# # -# Information about persons who performed or were involved in the microscope -# session or simulation run. -# -# This can be the principle investigator who performed this experiment or the student who performed simulations. -# Adding multiple users if relevant is recommended. +# Information about persons who performed or were involved in the microscope +# session or simulation run. +# +# This can be the principle investigator who performed this experiment or the student who performed simulations. +# Adding multiple users if relevant is recommended. # # # -# Given (first) name and surname. +# Given (first) name and surname. # # # # -# Name of the affiliation at the point in time when the experiment was performed. +# Name of the affiliation at the point in time when the experiment was performed. # # # # -# Postal address of the affiliation. +# Postal address of the affiliation. # # # # -# Email address at the point in time when the experiment was performed. -# -# Writing the most permanently used email is recommended. +# Email address at the point in time when the experiment was performed. +# +# Writing the most permanently used email is recommended. # # # # -# Telephone number at the point in time when the experiment was performed. +# Telephone number at the point in time when the experiment was performed. # # # # -# User role at the point in time when the experiment was performed. -# -# Examples are technician operating the microscope, student, postdoc, -# principle investigator, or guest. +# User role at the point in time when the experiment was performed. +# +# Examples are technician operating the microscope, student, postdoc, +# principle investigator, or guest. # # -# +# # -# Identifier offered by a service to report the user other than by using its name. -# -# Examples could be an ORCID or social media account of the user. +# Identifier offered by a service to report the user other than by using its name. +# +# Examples could be an ORCID or social media account of the user. # -# -# -# -# +# # # # -# A physical entity which contains material intended to be investigated. -# Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. -# -# This concept is related to term `Specimen`_ of the EMglossary standard. -# -# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 +# A physical entity which contains material intended to be investigated. +# Sample and specimen are treated as de facto synonyms. Samples can be real or virtual ones. +# +# This concept is related to term `Specimen`_ of the EMglossary standard. +# +# .. _Specimen: https://purls.helmholtz-metadaten.de/emg/EMG_00000046 # # # -# Qualifier whether the sample is a real or a virtual one. +# Qualifier whether the sample is a real or a virtual one. # # # # # # -# +# # -# Ideally, (globally) unique persistent identifier which distinguishes the sample from all others -# and especially the predecessor/origin from where that sample was cut. The terms sample -# and specimen are here considered as exact synonyms. -# -# This field must not be used for an alias! Instead, use name. -# -# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve -# the specific sample, whose results are stored by this :ref:`NXentry` instance because a single -# NXentry should be used for the characterization of a single specimen. -# -# Details about the specimen preparation should be stored in resources referring to parent_identifier. +# Ideally, (globally) unique persistent identifier which distinguishes the sample from all others +# and especially the predecessor/origin from where that sample was cut. The terms sample +# and specimen are here considered as exact synonyms. +# +# This field must not be used for an alias! Instead, use name. +# +# In cases where multiple specimens were loaded into the microscope, the identifier has to resolve +# the specific sample, whose results are stored by this :ref:`NXentry` instance because a single +# NXentry should be used for the characterization of a single specimen. +# +# Details about the specimen preparation should be stored in resources referring to parent_identifier. # -# -# -# -# -# +# +# # -# Identifier of the sample from which the sample was cut or the string *None*. -# -# The purpose of this field is to support functionalities for tracking -# sample provenance in a research data management system. +# Identifier of the sample from which the sample was cut or the string *None*. +# +# The purpose of this field is to support functionalities for tracking +# sample provenance in a research data management system. # -# -# -# -# +# # # -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known timestamp when -# the measured specimen surface was actively prepared. Ideally, this matches -# the last timestamp that is mentioned in the digital resource pointed to by -# parent_identifier. -# -# Knowing when the specimen was exposed to e.g. specific atmosphere is especially -# required for environmentally sensitive material such as specimen charged with hydrogen -# or experiments including tracers that have a short halflife. Additional time stamps -# prior to preparation_date should better be placed in resources which describe but -# which do not pollute the description here with prose. Resolving these connected -# pieces of information is considered the responsibility of the -# research data management system not of a NeXus file. +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known timestamp when +# the measured specimen surface was actively prepared. Ideally, this matches +# the last timestamp that is mentioned in the digital resource pointed to by +# identifier_parent. +# +# Knowing when the specimen was exposed to e.g. specific atmosphere is especially +# required for environmentally sensitive material such as specimen charged with hydrogen +# or experiments including tracers that have a short halflife. Additional time stamps +# prior to preparation_date should better be placed in resources which describe but +# which do not pollute the description here with prose. Resolving these connected +# pieces of information is considered the responsibility of the +# research data management system not of a NeXus file. # # # # -# An alias used to refer to the specimen to please readability for humans. +# An alias used to refer to the specimen to please readability for humans. # # # # -# List of comma-separated elements from the periodic table that are contained in the sample. -# If the sample substance has multiple components, all elements from each component -# must be included in atom_types. -# -# The purpose of the field is to offer research data management systems an opportunity -# to parse the relevant elements without having to interpret these from the resources -# pointed to by parent_identifier or walk through eventually deeply nested groups in -# individual data instances. +# List of comma-separated elements from the periodic table that are contained in the sample. +# If the sample substance has multiple components, all elements from each component +# must be included in atom_types. +# +# The purpose of the field is to offer research data management systems an opportunity +# to parse the relevant elements without having to interpret these from the resources +# pointed to by identifier_parent or walk through eventually deeply nested groups in +# individual data instances. # # # # -# (Measured) sample thickness. -# -# The information is recorded to qualify if the beam used was likely -# able to shine through the specimen. For scanning electron microscopy, -# in many cases the specimen is typically thicker than what is -# illuminatable by the electron beam. -# -# In this case the value should be set to the actual thickness of -# the specimen viewed for an illumination situation where the nominal -# surface normal of the specimen is parallel to the optical axis. +# (Measured) sample thickness. +# +# The information is recorded to qualify if the beam used was likely +# able to shine through the specimen. For scanning electron microscopy, +# in many cases the specimen is typically thicker than what is +# illuminatable by the electron beam. +# +# In this case the value should be set to the actual thickness of +# the specimen viewed for an illumination situation where the nominal +# surface normal of the specimen is parallel to the optical axis. # # # # # -# (Measured) density of the specimen. -# -# For multi-layered specimens this field should only be used to describe -# the density of the excited volume. For scanning electron microscopy -# the usage of this field is discouraged and instead an instance of an -# :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` -# instances can provide a cleaner description of the relevant details -# why one may wish to store the density of the specimen. +# (Measured) density of the specimen. +# +# For multi-layered specimens this field should only be used to describe +# the density of the excited volume. For scanning electron microscopy +# the usage of this field is discouraged and instead an instance of an +# :ref:`NXinteraction_vol_em` within individual :ref:`NXevent_data_em` +# instances can provide a cleaner description of the relevant details +# why one may wish to store the density of the specimen. # # # # -# Discouraged free-text field to provide further detail although adding -# parent_identifier and having a working research data management system -# should provide this contextualization. +# Discouraged free-text field to provide further detail although adding +# identifier_parent and having a working research data management system +# should provide this contextualization. # # # # # -# Set to hold different coordinate systems conventions. -# -# Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes -# how to define coordinate systems in NeXus. +# Set to hold different coordinate systems conventions. +# +# Inspect the description of the :ref:`NXcoordinate_system_set` and :ref:`NXcoordinate_system` base classes +# how to define coordinate systems in NeXus. # # # @@ -1826,14 +1855,14 @@ NXem(NXobject): # # # -# Location of the origin of the processing_reference_frame. -# -# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their outer unit normals -# (which point either parallel or antiparallel) along respective base vector direction -# of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. +# Location of the origin of the processing_reference_frame. +# +# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their outer unit normals +# (which point either parallel or antiparallel) along respective base vector direction +# of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. # # # @@ -1849,8 +1878,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing x-axis base vector of the -# processing_reference_frame. +# Direction of the positively pointing x-axis base vector of the +# processing_reference_frame. # # # @@ -1864,8 +1893,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing y-axis base vector of the -# processing_reference_frame. +# Direction of the positively pointing y-axis base vector of the +# processing_reference_frame. # # # @@ -1879,8 +1908,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing z-axis base vector of the -# processing_reference_frame. +# Direction of the positively pointing z-axis base vector of the +# processing_reference_frame. # # # @@ -1896,8 +1925,8 @@ NXem(NXobject): # # # -# Reference to the specifically named :ref:`NXsample` instance(s) for -# which these conventions apply (e.g. /entry1/sample1). +# Reference to the specifically named :ref:`NXsample` instance(s) for +# which these conventions apply (e.g. /entry1/sample1). # # # @@ -1905,14 +1934,14 @@ NXem(NXobject): # # # -# Location of the origin of the sample_reference_frame. -# -# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. -# Edges are interpreted by inspecting the direction of their outer unit normals -# (which point either parallel or antiparallel) along respective base vector direction -# of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. +# Location of the origin of the sample_reference_frame. +# +# It is assumed that regions-of-interest in this reference frame form a rectangle or cuboid. +# Edges are interpreted by inspecting the direction of their outer unit normals +# (which point either parallel or antiparallel) along respective base vector direction +# of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. # # # @@ -1928,8 +1957,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing x-axis base vector of the -# sample_reference_frame. +# Direction of the positively pointing x-axis base vector of the +# sample_reference_frame. # # # @@ -1943,8 +1972,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing y-axis base vector of the -# sample_reference_frame. +# Direction of the positively pointing y-axis base vector of the +# sample_reference_frame. # # # @@ -1958,8 +1987,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing z-axis base vector of the -# sample_reference_frame. +# Direction of the positively pointing z-axis base vector of the +# sample_reference_frame. # # # @@ -1972,11 +2001,11 @@ NXem(NXobject): # # # -# +# # # -# Reference to the specifically named :ref:`NXdetector` instance for -# which these conventions apply (e.g. /entry1/instrument/detector1). +# Reference to the specifically named :ref:`NXdetector` instance for +# which these conventions apply (e.g. /entry1/instrument/detector1). # # # @@ -1984,13 +2013,13 @@ NXem(NXobject): # # # -# Location of the origin of the detector_reference_frame. -# -# If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted -# by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) -# along respective base vector direction of the reference frame. -# -# If any of these assumptions is not met, the user is required to explicitly state this. +# Location of the origin of the detector_reference_frame. +# +# If the regions-of-interest forms a rectangle or cuboid, it is assumed that edges are interpreted +# by inspecting the direction of their outer unit normals (which point either parallel or antiparallel) +# along respective base vector direction of the reference frame. +# +# If any of these assumptions is not met, the user is required to explicitly state this. # # # @@ -2006,8 +2035,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing x-axis base vector of the -# detector_reference_frame. +# Direction of the positively pointing x-axis base vector of the +# detector_reference_frame. # # # @@ -2021,8 +2050,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing y-axis base vector of the -# detector_reference_frame. +# Direction of the positively pointing y-axis base vector of the +# detector_reference_frame. # # # @@ -2036,8 +2065,8 @@ NXem(NXobject): # # # -# Direction of the positively pointing z-axis base vector of the -# detector_reference_frame. +# Direction of the positively pointing z-axis base vector of the +# detector_reference_frame. # # # @@ -2060,11 +2089,11 @@ NXem(NXobject): # # # -# +# # -# +# # -# Details about the control program used for operating the microscope. +# Details about the control program used for operating the microscope. # # # @@ -2075,13 +2104,13 @@ NXem(NXobject): # # # -# +# # # # -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 # # # @@ -2089,7 +2118,7 @@ NXem(NXobject): # # # -# +# # # # -# +# # # # -# +# # # -# +# # # # -# +# # # -# +# # -# Device for improving energy resolution or reducing chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# Device for improving energy resolution or reducing chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ # # # # -# Qualitative type of the component. +# Qualitative type of the component. # # # @@ -2137,59 +2166,57 @@ NXem(NXobject): # # # -# +# # # # # # # -# +# # # # # -# Device reshaping an ellipse-shaped electron beam to a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. +# Device reshaping an ellipse-shaped electron beam to a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. # # # # -# +# # # # # -# Electron biprism as it is used e.g. for electron holography. +# Electron biprism as it is used e.g. for electron holography. # # # # -# +# # # -# -# +# lenses i.e. devices which can affect the pathes of beams--> +# # -# Device that causes a change in the phase of an electron wave. -# -# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ -# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ +# Device that causes a change in the phase of an electron wave. +# +# * `M. Malac et al. <https://doi.org/10.1093/jmicro/dfaa070>`_ +# * `R. R. Schröder et al. <https://www.lem.kit.edu/152.php>`_ # # # -# Qualitative type +# Qualitative type # # # @@ -2199,11 +2226,11 @@ NXem(NXobject): # # # -# +# # # -# -# +# +# # # # @@ -2211,35 +2238,35 @@ NXem(NXobject): # # # -# +# # # # # -# +# # # # -# +# # # -# +# # # # -# +# # # -# +# # -# Device for improving energy resolution or reducing chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# Device for improving energy resolution or reducing chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ # # # -# Qualitative type of the component. +# Qualitative type of the component. # # # @@ -2253,26 +2280,24 @@ NXem(NXobject): # # # -# +# # # # -# -# +# +# # -# +# # # # # # -# # # # # -# +# # # # @@ -2281,7 +2306,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2294,19 +2319,19 @@ NXem(NXobject): # # # -# +# # -# +# # # # # -# +# # # # # -# +# # # # @@ -2327,7 +2352,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2351,7 +2376,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2378,7 +2403,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2392,10 +2417,10 @@ NXem(NXobject): # # # -# +# # # -# +# # # # @@ -2405,7 +2430,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2419,10 +2444,10 @@ NXem(NXobject): # # # -# +# # # -# +# # # # @@ -2435,7 +2460,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2449,10 +2474,10 @@ NXem(NXobject): # # # -# +# # # -# +# # # # @@ -2468,19 +2493,19 @@ NXem(NXobject): # # # -# +# # -# +# # # # # -# +# # # # # -# +# # # # @@ -2492,7 +2517,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2507,7 +2532,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2525,7 +2550,7 @@ NXem(NXobject): # # # -# +# # # # @@ -2546,12 +2571,12 @@ NXem(NXobject): # # # -# +# # # # # -# +# # # # @@ -2561,12 +2586,12 @@ NXem(NXobject): # # # -# +# # # # # -# +# # # # @@ -2579,12 +2604,12 @@ NXem(NXobject): # # # -# +# # # # # -# +# # # # @@ -2600,12 +2625,12 @@ NXem(NXobject): # # # -# +# # # # # -# +# # # # @@ -2627,101 +2652,101 @@ NXem(NXobject): # # # -# This concept is related to term `Source`_ of the EMglossary standard. -# -# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 +# This concept is related to term `Source`_ of the EMglossary standard. +# +# .. _Source: https://purls.helmholtz-metadaten.de/emg/EMG_00000045 # # # -# The potential difference between anode and cathode. -# -# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. -# -# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 +# The potential difference between anode and cathode. +# +# This concept is related to term `Acceleration Voltage`_ of the EMglossary standard. +# +# .. _Acceleration Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000004 # # # # -# Voltage which is utilised to create an electric field that draws particles from -# the source. -# -# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. -# -# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# Voltage which is utilised to create an electric field that draws particles from +# the source. +# +# This concept is related to term `Extraction Voltage`_ of the EMglossary standard. +# +# .. _Extraction Voltage: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 # # # # -# Electrical current which is released from the source. -# -# This concept is related to term `Emission Current`_ of the EMglossary standard. -# -# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 +# Electrical current which is released from the source. +# +# This concept is related to term `Emission Current`_ of the EMglossary standard. +# +# .. _Emission Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000025 # # # # -# Electrical current which flows through the source. -# -# This concept is related to term `Filament Current`_ of the EMglossary standard. -# -# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 +# Electrical current which flows through the source. +# +# This concept is related to term `Filament Current`_ of the EMglossary standard. +# +# .. _Filament Current: https://purls.helmholtz-metadaten.de/emg/EMG_00000027 # # # -# +# # # -# +# # # -# Relevant value from the control software. -# -# This is not always just the diameter of the aperture (not even in the case) -# of a circular aperture. Usually, it is a value that is set in the control -# software whereby a specific configuration of an aperture is selected by the -# software. -# -# The control software of commercial microscope typically offers the user -# access at a high abstraction level because of which many details about -# the actual settings of the electrical components are typically unknown. -# -# However, if more details are known or should be documented one should -# use the description field for this. +# Relevant value from the control software. +# +# This is not always just the diameter of the aperture (not even in the case) +# of a circular aperture. Usually, it is a value that is set in the control +# software whereby a specific configuration of an aperture is selected by the +# software. +# +# The control software of commercial microscope typically offers the user +# access at a high abstraction level because of which many details about +# the actual settings of the electrical components are typically unknown. +# +# However, if more details are known or should be documented one should +# use the description field for this. # # # -# +# # -# Device to improve energy resolution or chromatic aberration. -# -# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector -# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ +# Device to improve energy resolution or chromatic aberration. +# +# Examples are Wien, $\textalpha$-, or $\Omega$- energy filter or `cc corrector +# like <https://www.ceos-gmbh.de/en/basics/cc-corrector>`_ # # # # -# Was the corrector used? +# Was the corrector used? # # # # # -# Energy dispersion in e.g. µm/eV. +# Energy dispersion in e.g. µm/eV. # # # # -# Corresponding voltage for that energy dispersion. +# Corresponding voltage for that energy dispersion. # # # # # -# +# # # # @@ -2847,42 +2872,42 @@ NXem(NXobject): # basically optional use of NXaberration therein at least some value required--> # # -# Device reshaping an ellipse-shaped electron beam to a circular one. -# -# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ -# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ -# -# Stigmator is an exact synonym. +# Device reshaping an ellipse-shaped electron beam to a circular one. +# +# * `L. Reimer 1998, Springer, 1998 <https://dx.doi.org/10.1007/978-3-540-3896>`_ +# * `M. Tanaka et al., Electron Microscopy Glossary, 2024 <https://www.jeol.com/words/semterms/20201020.111014.php#gsc.tab=0>`_ +# +# Stigmator is an exact synonym. # # # -# Was the corrector used? +# Was the corrector used? # # # # -# Descriptor for the correction strength along the first direction when exact technical details -# are unknown or not directly controllable as the control software of the microscope does not -# enable or was not configured to display these values (for end users). +# Descriptor for the correction strength along the first direction when exact technical details +# are unknown or not directly controllable as the control software of the microscope does not +# enable or was not configured to display these values (for end users). # # # # -# Descriptor for the correction strength along the second direction when exact technical details -# are unknown or not directly controllable as the control software of the microscope does not -# enable or was not configured to display these values (for end users). +# Descriptor for the correction strength along the second direction when exact technical details +# are unknown or not directly controllable as the control software of the microscope does not +# enable or was not configured to display these values (for end users). # # # # -# -# -# +# +# +# # # -# This concept is related to term `Electron Beam`_ of the EMglossary standard. -# -# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 +# This concept is related to term `Electron Beam`_ of the EMglossary standard. +# +# .. _Electron Beam: https://purls.helmholtz-metadaten.de/emg/EMG_00000021 # # # @@ -2891,36 +2916,36 @@ NXem(NXobject): # # # -# +# # # -# +# # # -# Relevant value from the control software. -# -# This is not always just the diameter of the aperture (not even in the case) -# of a circular aperture. Usually, it is a value that is set in the control -# software whereby a specific configuration of an aperture is selected by the -# software. -# -# The control software of commercial microscope typically offers the user -# access at a high abstraction level because of which many details about -# the actual settings of the electrical components are typically unknown. -# -# However, if more details are known or should be documented one should -# use the description field for this. +# Relevant value from the control software. +# +# This is not always just the diameter of the aperture (not even in the case) +# of a circular aperture. Usually, it is a value that is set in the control +# software whereby a specific configuration of an aperture is selected by the +# software. +# +# The control software of commercial microscope typically offers the user +# access at a high abstraction level because of which many details about +# the actual settings of the electrical components are typically unknown. +# +# However, if more details are known or should be documented one should +# use the description field for this. # # # -# +# # # -# -# +# +# # # -# +# # # # @@ -2932,17 +2957,17 @@ NXem(NXobject): # # # -# Nominal current of the heater. +# Nominal current of the heater. # # # # -# Nominal voltage of the heater. +# Nominal voltage of the heater. # # # # -# Nominal power of the heater. +# Nominal power of the heater. # # # @@ -2960,14 +2985,14 @@ NXem(NXobject): # -# +# # -# A region-of-interest analyzed either during or after the session -# for which specific processed data are available. -# -# This concept is related to term `Region Of Interest`_ of the EMglossary standard. -# -# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 +# A region-of-interest analyzed either during or after the session +# for which specific processed data are available. +# +# This concept is related to term `Region Of Interest`_ of the EMglossary standard. +# +# .. _Region Of Interest: https://purls.helmholtz-metadaten.de/emg/EMG_00000042 # # +# nameType: partial +# exists: optional--> # # # @@ -3000,18 +3026,18 @@ NXem(NXobject): # # # -# +# # -# +# # # # # # # -# +# # -# +# # # # @@ -3019,53 +3045,56 @@ NXem(NXobject): # # # -# +# # -# +# # # # -# +# # # # # -# +# # # # +# nameType: partial +# exists: recommended +# projection_direction(NX_NUMBER): +# map(NXdata): +# \@signal(NX_CHAR): +# \@axes(NX_CHAR): +# \@AXISNAME_indices(NX_INT): +# nameType: partial +# title(NX_CHAR): +# data(NX_NUMBER): +# \@long_name(NX_CHAR): +# axis_x(NX_NUMBER): +# \@long_name(NX_CHAR): +# axis_y(NX_NUMBER): +# exists: optional +# \@long_name(NX_CHAR): +# axis_z(NX_NUMBER): +# exists: optional +# \@long_name(NX_CHAR): +# legend(NXdata): +# \@signal(NX_CHAR): +# \@axes(NX_CHAR): +# \@AXISNAME_indices(NX_INT): +# nameType: partial +# title(NX_CHAR): +# data(NX_NUMBER): +# \@long_name(NX_CHAR): +# axis_x(NX_NUMBER): +# \@long_name(NX_CHAR): +# axis_y(NX_NUMBER): +# \@long_name(NX_CHAR):--> # # # -# +# # # # @@ -3084,7 +3113,7 @@ NXem(NXobject): # # # -# +# # # # @@ -3098,7 +3127,7 @@ NXem(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXem_calorimetry.yaml b/contributed_definitions/nyaml/NXem_calorimetry.yaml index ace66a049b..2fb7d0d452 100644 --- a/contributed_definitions/nyaml/NXem_calorimetry.yaml +++ b/contributed_definitions/nyaml/NXem_calorimetry.yaml @@ -38,7 +38,7 @@ NXem_calorimetry(NXobject): # take here inspiration from the dozens of example appdefs # e.g. NXem, NXapm_paraprobe_* which shows how to add context - identifier(NXidentifier): + identifier: exists: optional # a place whereby you can refer to your simulation run, etc @@ -77,11 +77,11 @@ NXem_calorimetry(NXobject): path(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): - actuator(NXserialized): + actuator(NXnote): doc: | Reference to the resource which stores actuator log file from the experiment. type(NX_CHAR): - path(NX_CHAR): + identifier(NX_CHAR): checksum(NX_CHAR): algorithm(NX_CHAR): time_synchronization(NXprocess): @@ -90,7 +90,7 @@ NXem_calorimetry(NXobject): detector used for collecting diffraction pattern and the actuator (heating chip) were synchronized. sequence_index(NX_POSINT): - pattern_identifier(NX_UINT): + identifier_pattern(NX_UINT): unit: NX_UNITLESS dimensions: rank: 1 @@ -128,6 +128,7 @@ NXem_calorimetry(NXobject): exists: optional sequence_index(NX_POSINT): programID(NXprogram): + nameType: partial exists: optional program(NX_CHAR): \@version(NX_CHAR): @@ -149,6 +150,7 @@ NXem_calorimetry(NXobject): Acquired diffraction pattern azimuthally integrated as a function of time. sequence_index(NX_POSINT): programID(NXprogram): + nameType: partial exists: optional program(NX_CHAR): \@version(NX_CHAR): @@ -159,6 +161,7 @@ NXem_calorimetry(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): intensity(NX_FLOAT): unit: NX_UNITLESS @@ -166,7 +169,7 @@ NXem_calorimetry(NXobject): rank: 2 dim: (n_p, n_f) \@long_name(NX_CHAR): - axis_pattern_identifier(NX_UINT): + identifier_axis_pattern(NX_UINT): unit: NX_UNITLESS dimensions: rank: 1 @@ -193,6 +196,7 @@ NXem_calorimetry(NXobject): exists: recommended sequence_index(NX_POSINT): programID(NXprogram): + nameType: partial program(NX_CHAR): \@version(NX_CHAR): config(NXcollection): @@ -208,6 +212,7 @@ NXem_calorimetry(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): intensity(NX_FLOAT): unit: NX_UNITLESS @@ -215,7 +220,7 @@ NXem_calorimetry(NXobject): rank: 2 dim: (n_p, n_f) \@long_name(NX_CHAR): - axis_pattern_identifier(NX_UINT): + identifier_axis_pattern(NX_UINT): unit: NX_UNITLESS dimensions: rank: 1 @@ -260,7 +265,7 @@ NXem_calorimetry(NXobject): # number_of_gpus(NX_POSINT): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 72d2a9b22bd8d987b5c506c6151d7219ed74287e7d778bdbc4e7c71a048583f7 +# 915be4fff05119ff3f12e91e93ac520952a3afa1d09ca2f57502bf8673253281 # # # # # -# Number of pattern +# Number of pattern # # # # -# Number of azimuthal integration bins +# Number of azimuthal integration bins # # # # -# Number of coordinates along i axis. +# Number of coordinates along i axis. # # # # -# Number of coordinates along j axis. +# Number of coordinates along j axis. # # # # -# Application definition for minimal example in-situ calorimetry. -# -# What is the technique about. -# -# General context. -# -# Literature references. +# Application definition for minimal example in-situ calorimetry. +# +# What is the technique about. +# +# General context. +# +# Literature references. # # # @@ -335,7 +340,7 @@ NXem_calorimetry(NXobject): # # -# +# # # # @@ -350,47 +355,47 @@ NXem_calorimetry(NXobject): # # # -# Reference to the resource which stores acquired pattern from the experiment. -# -# Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. +# Reference to the resource which stores acquired pattern from the experiment. +# +# Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. # # # # # # -# +# # -# Reference to the resource which stores actuator log file from the experiment. +# Reference to the resource which stores actuator log file from the experiment. # # -# +# # # # # # -# Assumptions and computations whereby timestamp data from the -# detector used for collecting diffraction pattern and the actuator -# (heating chip) were synchronized. +# Assumptions and computations whereby timestamp data from the +# detector used for collecting diffraction pattern and the actuator +# (heating chip) were synchronized. # # -# +# # # # # # # -# Timestamp when pattern acquisition started. +# Timestamp when pattern acquisition started. # # # @@ -398,7 +403,7 @@ NXem_calorimetry(NXobject): # # # -# Timestamp when pattern acquisition ended. +# Timestamp when pattern acquisition ended. # # # @@ -411,8 +416,8 @@ NXem_calorimetry(NXobject): # # # +# doc: | +# Hint to help resolve in which coordinate system position values are defined.--> # # # @@ -424,7 +429,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # # @@ -442,14 +447,12 @@ NXem_calorimetry(NXobject): # # # -# +# # -# Acquired diffraction pattern azimuthally integrated as a function of time. +# Acquired diffraction pattern azimuthally integrated as a function of time. # # -# +# # # # @@ -459,7 +462,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # # @@ -468,7 +471,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # # @@ -483,7 +486,7 @@ NXem_calorimetry(NXobject): # # # -# Time since start of the in-situ experiment +# Time since start of the in-situ experiment # # # @@ -494,7 +497,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # # @@ -505,12 +508,12 @@ NXem_calorimetry(NXobject): # # # -# Azimuthally integrated diffraction intensities corrected for background as a -# function of time. +# Azimuthally integrated diffraction intensities corrected for background as a +# function of time. # # # -# +# # # # @@ -519,7 +522,7 @@ NXem_calorimetry(NXobject): # # # -# +# # # # @@ -534,7 +537,7 @@ NXem_calorimetry(NXobject): # # # -# Time since start of the in-situ experiment +# Time since start of the in-situ experiment # # # @@ -544,9 +547,9 @@ NXem_calorimetry(NXobject): # # # # diff --git a/contributed_definitions/nyaml/NXem_ebsd.yaml b/contributed_definitions/nyaml/NXem_ebsd.yaml index 10033aaed7..760effb97d 100644 --- a/contributed_definitions/nyaml/NXem_ebsd.yaml +++ b/contributed_definitions/nyaml/NXem_ebsd.yaml @@ -233,7 +233,7 @@ NXem_ebsd(NXem_method): If available and it is stored in an instance of an application definition this field specifies the path to an instance of :ref:`NXdata` where the measured patterns are stored. - source(NXserialized): + source(NXnote): doc: | Reference (e.g. path and filename) to an existent data artifact which stores either the measured pattern or input (already processed EBSD data). @@ -258,7 +258,7 @@ NXem_ebsd(NXem_method): doc: | If available and it is stored in an instance of an application definition this field specifies the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. - source(NXserialized): + source(NXnote): doc: | Reference (e.g. path and filename) to an existent digital resource which stores either the pattern or input (already processed EBSD data) @@ -305,7 +305,7 @@ NXem_ebsd(NXem_method): doc: | If available and it is stored in an instance of an application definition this field specifies the path to an instance of :ref:`NXem_msr` where calibration is stored. - source(NXserialized): + source(NXnote): doc: | Reference to a digital resource where the calibration is stored. indexing(NXprocess): @@ -330,7 +330,7 @@ NXem_ebsd(NXem_method): The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. `_). Recently, dictionary-based indexing methods are increasingly becoming used partly driven by the interest to use artificial intelligence algorithms. - source(NXserialized): + source(NXnote): doc: | This group enables to establish a logical connection between previous processing steps or on-the-fly-performed indexing of the EBSD map. @@ -354,6 +354,7 @@ NXem_ebsd(NXem_method): doc: | Specific parameter relevant only for certain algorithms used. phaseID(NXcrystal_structure): + nameType: partial doc: | Details for each phase used as a model with which the patterns were indexed. Instances of :ref:`NXcrystal_structure` in this group must @@ -469,9 +470,13 @@ NXem_ebsd(NXem_method): Number of scan points in the original mapping. # odfID(NXmicrostructure_odf): + # nameType: partial # pfID(NXmicrostructure_pf): + # nameType: partial # ipfID(NXmicrostructure_ipf): + # nameType: partial # microstructureID(NXmicrostructure): + # nameType: partial # overview over the entire map, rediscretized on a tight aabb roi(NXdata): doc: | @@ -530,7 +535,7 @@ NXem_ebsd(NXem_method): Label for the x axis # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 45aa2708048c78bc81f55a6ede151d65c04b0bee5d0cf4afbd404a21665f5b6d +# 0307e3cc196b1878d14dda47138f202aabeec278f976c43fa3d4f8229b7c05a2 # # # # # -# Details about the gnomonic (projection) reference frame. -# -# It is assumed that the configuration is inspected by looking towards the sample surface. -# If a detector is involved, it is assumed that the configuration is inspected from a position -# that is located behind this detector. -# -# If any of these assumptions is not met, the user is required to explicitly state this. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the -# base vectors of this coordinate system as Xg, Yg, Zg. +# Details about the gnomonic (projection) reference frame. +# +# It is assumed that the configuration is inspected by looking towards the sample surface. +# If a detector is involved, it is assumed that the configuration is inspected from a position +# that is located behind this detector. +# +# If any of these assumptions is not met, the user is required to explicitly state this. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to label the +# base vectors of this coordinate system as Xg, Yg, Zg. # # # -# Origin of the gnomonic_projection_reference_frame. -# -# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to -# assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. +# Origin of the gnomonic_projection_reference_frame. +# +# Reference DOI: 10.1016/j.matchar.2016.04.008 suggests to +# assume that this is coordinate Xg = 0, Yg = 0, Zg = 0. # # # @@ -710,8 +715,8 @@ NXem_ebsd(NXem_method): # # # -# Direction of the positively pointing x-axis base vector of the -# gnomonic_reference_frame. +# Direction of the positively pointing x-axis base vector of the +# gnomonic_reference_frame. # # # @@ -725,8 +730,8 @@ NXem_ebsd(NXem_method): # # # -# Direction of the positively pointing y-axis base vector of the -# gnomonic_reference_frame. +# Direction of the positively pointing y-axis base vector of the +# gnomonic_reference_frame. # # # @@ -740,8 +745,8 @@ NXem_ebsd(NXem_method): # # # -# Direction of the positively pointing z-axis base vector of the -# gnomonic_reference_frame. +# Direction of the positively pointing z-axis base vector of the +# gnomonic_reference_frame. # # # @@ -756,28 +761,28 @@ NXem_ebsd(NXem_method): # # # -# Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. -# -# Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. -# Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane -# (of the detector reference frame). -# -# When the normalization direction is the same as e.g. the detector x-axis direction one -# effectively normalizes in fractions of the width of the detector. -# -# The issue with terms like width and height is that these degenerate if the detector -# region-of-interest is square-shaped. This is why instead of referring to width and height -# one should report as if one were to measure practically with a ruler and one is specific -# about in which direction positive distances are measured. -# -# For the concepts used to specify the boundary_convention it is assumed that the -# region-of-interest is defined by a rectangle, referring to the direction of outer-unit -# normals to the respective edges of this rectangle. +# Details about the definition of the pattern centre as a special point in the gnomonic_reference_frame. +# +# Keep in mind that the gnomonic space is in virtually all cases embedded in the detector space. +# Specifically, the XgYg plane is defined such that it is laying inside the XdYd plane +# (of the detector reference frame). +# +# When the normalization direction is the same as e.g. the detector x-axis direction one +# effectively normalizes in fractions of the width of the detector. +# +# The issue with terms like width and height is that these degenerate if the detector +# region-of-interest is square-shaped. This is why instead of referring to width and height +# one should report as if one were to measure practically with a ruler and one is specific +# about in which direction positive distances are measured. +# +# For the concepts used to specify the boundary_convention it is assumed that the +# region-of-interest is defined by a rectangle, referring to the direction of outer-unit +# normals to the respective edges of this rectangle. # # # -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's x-position (PCx) measured. +# From which border of the EBSP (in the detector reference frame) is the pattern +# centre's x-position (PCx) measured. # # # @@ -789,8 +794,8 @@ NXem_ebsd(NXem_method): # # # -# In which direction are positive values for the x-axis coordinate value measured -# from the specified boundary. +# In which direction are positive values for the x-axis coordinate value measured +# from the specified boundary. # # # @@ -802,8 +807,8 @@ NXem_ebsd(NXem_method): # # # -# From which border of the EBSP (in the detector reference frame) is the pattern -# centre's y-position (PCy) measured. +# From which border of the EBSP (in the detector reference frame) is the pattern +# centre's y-position (PCy) measured. # # # @@ -815,8 +820,8 @@ NXem_ebsd(NXem_method): # # # -# In which direction are positive values for the y-axis coordinate value measured -# from the specified boundary. +# In which direction are positive values for the y-axis coordinate value measured +# from the specified boundary. # # # @@ -839,174 +844,174 @@ NXem_ebsd(NXem_method): # enumeration: [undefined, Bruker, JEOL, FEI, Oxford]--> # # -# This group documents relevant details about the conditions and the tools -# used for measuring a stack of Kikuchi diffraction pattern with an -# electron microscope. -# -# The most frequently collected EBSD data are captured for rectangular -# regions-of-interested which are sampled with regular square or -# hexagon-shaped pixels. +# This group documents relevant details about the conditions and the tools +# used for measuring a stack of Kikuchi diffraction pattern with an +# electron microscope. +# +# The most frequently collected EBSD data are captured for rectangular +# regions-of-interested which are sampled with regular square or +# hexagon-shaped pixels. # # # -# Physical time since the beginning of a timestamp that is required to be -# same for all experiments in the set. The purpose of this marker is -# to identify how all experiments in the set need to be arranged -# sequentially based on the time elapsed. -# The time is relevant to sort e.g. experiments of consecutive quasi -# in-situ experiments where a measurement was e.g. taken after 0 minutes, -# 30 minutes, 6 hours, or 24 hours of annealing. +# Physical time since the beginning of a timestamp that is required to be +# same for all experiments in the set. The purpose of this marker is +# to identify how all experiments in the set need to be arranged +# sequentially based on the time elapsed. +# The time is relevant to sort e.g. experiments of consecutive quasi +# in-situ experiments where a measurement was e.g. taken after 0 minutes, +# 30 minutes, 6 hours, or 24 hours of annealing. # # # -# Timestamp relative to which time was counted to aid -# converting between time and timestamp. +# Timestamp relative to which time was counted to aid +# converting between time and timestamp. # # # # +# doc: | +# True if pattern were stored and are retrieveable via depends_on or source.--> # # -# If available and it is stored in an instance of an application definition this field -# specifies the path to an instance of :ref:`NXdata` where the measured patterns -# are stored. +# If available and it is stored in an instance of an application definition this field +# specifies the path to an instance of :ref:`NXdata` where the measured patterns +# are stored. # # -# +# # -# Reference (e.g. path and filename) to an existent data artifact which -# stores either the measured pattern or input (already processed EBSD data). +# Reference (e.g. path and filename) to an existent data artifact which +# stores either the measured pattern or input (already processed EBSD data). # # # # # -# This group documents relevant details about the conditions and the tools -# used for simulating a stack of Kikuchi diffraction pattern with some -# physical model. -# -# This group should not be confused with a group named simulation that -# is however an instance of NXem_sim. Instead, the simulation group here -# should be used if (e.g. instead of a measurement) a stack of pattern -# were simulated that one wishes to use for indexing patterns. -# -# In many practical cases where pattern are analyzed on-the-fly and dictionary -# indexing strategies are used, so-called master pattern(s) are used to compare -# measured or simulated pattern with the master pattern. In this case, -# master pattern are the result of a computer simulation and thus should -# be stored using an own properly documented entry within a simulation -# group as an instance of :ref:`NXem_sim`. +# This group documents relevant details about the conditions and the tools +# used for simulating a stack of Kikuchi diffraction pattern with some +# physical model. +# +# This group should not be confused with a group named simulation that +# is however an instance of NXem_sim. Instead, the simulation group here +# should be used if (e.g. instead of a measurement) a stack of pattern +# were simulated that one wishes to use for indexing patterns. +# +# In many practical cases where pattern are analyzed on-the-fly and dictionary +# indexing strategies are used, so-called master pattern(s) are used to compare +# measured or simulated pattern with the master pattern. In this case, +# master pattern are the result of a computer simulation and thus should +# be stored using an own properly documented entry within a simulation +# group as an instance of :ref:`NXem_sim`. # # # -# If available and it is stored in an instance of an application definition this field specifies -# the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. +# If available and it is stored in an instance of an application definition this field specifies +# the path to an instance of :ref:`NXimage_set` where the simulated patterns are stored. # # -# +# # -# Reference (e.g. path and filename) to an existent digital resource which -# stores either the pattern or input (already processed EBSD data) -# which is now processed further as described by this NXem_ebsd instance. +# Reference (e.g. path and filename) to an existent digital resource which +# stores either the pattern or input (already processed EBSD data) +# which is now processed further as described by this NXem_ebsd instance. # # # # # -# The EBSD system, including components like the electron gun, pole-piece, -# stage tilting, EBSD detector, and the gnomonic projection have to be -# calibrated to achieve reliable indexing results. -# -# Specifically, the gnomonic projection has to be calibrated. -# Typically, silicon or quartz crystals are used for this purpose. -# -# Considering a system is well-calibrated, it is much more frequently the -# case in practice that users assume the system is calibrated (and thus usable) -# vs. they perform the calibration of the EBSD system. -# -# In the first case, the user assumes that the principle geometry of the -# hardware components and the settings in the control and EBSD pattern -# acquisition software has been calibrated. Consequently, users pick from -# an existent library of phase candidates, i.e. -# :ref:`NXcrystal_structure` instances. Examples are -# reflector models as stored in CRY files (HKL/Channel 5/Flamenco). -# -# In the second case, users calibrate the system during the session -# using standards (silicon, quartz, or other common specimens). -# There is usually one person in each lab responsible for doing such -# calibrations. Often this person or technician is also in charge of -# configuring the graphical user interface and software with which most -# users control and perform their analyses. -# -# For EBSD this has key implications: Taking TSL OIM/EDAX as an example, -# the conventions how orientations are stored is affected by how the -# reference frames are configured and this setup is made at the level -# of the GUI software. -# -# Unfortunately, these pieces of information are not necessarily stored -# in the results files. In effect, key conventions become disconnected -# from the data so it remains the users' obligation to remember these -# settings or write these down in a lab notebook. Otherwise, these metadata -# get lost. All these issues are a motivation and problem which -# :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. +# The EBSD system, including components like the electron gun, pole-piece, +# stage tilting, EBSD detector, and the gnomonic projection have to be +# calibrated to achieve reliable indexing results. +# +# Specifically, the gnomonic projection has to be calibrated. +# Typically, silicon or quartz crystals are used for this purpose. +# +# Considering a system is well-calibrated, it is much more frequently the +# case in practice that users assume the system is calibrated (and thus usable) +# vs. they perform the calibration of the EBSD system. +# +# In the first case, the user assumes that the principle geometry of the +# hardware components and the settings in the control and EBSD pattern +# acquisition software has been calibrated. Consequently, users pick from +# an existent library of phase candidates, i.e. +# :ref:`NXcrystal_structure` instances. Examples are +# reflector models as stored in CRY files (HKL/Channel 5/Flamenco). +# +# In the second case, users calibrate the system during the session +# using standards (silicon, quartz, or other common specimens). +# There is usually one person in each lab responsible for doing such +# calibrations. Often this person or technician is also in charge of +# configuring the graphical user interface and software with which most +# users control and perform their analyses. +# +# For EBSD this has key implications: Taking TSL OIM/EDAX as an example, +# the conventions how orientations are stored is affected by how the +# reference frames are configured and this setup is made at the level +# of the GUI software. +# +# Unfortunately, these pieces of information are not necessarily stored +# in the results files. In effect, key conventions become disconnected +# from the data so it remains the users' obligation to remember these +# settings or write these down in a lab notebook. Otherwise, these metadata +# get lost. All these issues are a motivation and problem which +# :ref:`NXem_ebsd` solves in that all conventions can be specified explicitly. # # # -# If available and it is stored in an instance of an application definition this field specifies -# the path to an instance of :ref:`NXem_msr` where calibration is stored. +# If available and it is stored in an instance of an application definition this field specifies +# the path to an instance of :ref:`NXem_msr` where calibration is stored. # # -# +# # -# Reference to a digital resource where the calibration is stored. +# Reference to a digital resource where the calibration is stored. # # # # # -# Indexing is a data processing step performed either after or while -# (on-the-fly) the beam scans the specimen. The resulting method is also -# known as orientation imaging microscopy (OIM). -# -# Different algorithms can be used to index EBSD pattern. Common to them -# is the computational step where simulated reference pattern are compared -# with measured or simulated patterns. These latter patterns are referred -# to via the measurement or simulation groups of this base class. -# -# Quality descriptors are defined based on which an indexing algorithm -# yields a quantitative measure of how similar measured and reference -# pattern are, and thus if no, one, or multiple so-called solutions -# were found. -# -# Assumed or simulated pattern are simulated using kinematic or dynamical -# theory of electron diffraction delivering master pattern. -# -# The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). -# Recently, dictionary-based indexing methods are increasingly becoming used -# partly driven by the interest to use artificial intelligence algorithms. +# Indexing is a data processing step performed either after or while +# (on-the-fly) the beam scans the specimen. The resulting method is also +# known as orientation imaging microscopy (OIM). +# +# Different algorithms can be used to index EBSD pattern. Common to them +# is the computational step where simulated reference pattern are compared +# with measured or simulated patterns. These latter patterns are referred +# to via the measurement or simulation groups of this base class. +# +# Quality descriptors are defined based on which an indexing algorithm +# yields a quantitative measure of how similar measured and reference +# pattern are, and thus if no, one, or multiple so-called solutions +# were found. +# +# Assumed or simulated pattern are simulated using kinematic or dynamical +# theory of electron diffraction delivering master pattern. +# +# The Hough transform is essentially a discretized Radon transform (for details see `M. van Ginkel et al. <https://www.semanticscholar.org/paper/A-short-introduction-to-the-Radon-and-Hough-and-how-Ginkel/fb6226f606cad489a15e38ed961c419037ccc858>`_). +# Recently, dictionary-based indexing methods are increasingly becoming used +# partly driven by the interest to use artificial intelligence algorithms. # -# +# # -# This group enables to establish a logical connection between previous -# processing steps or on-the-fly-performed indexing of the EBSD map. -# Typically these processing steps are performed with commercial software. -# Therefore, in many cases a results file from this indexing is often -# all that is communicated and saved. These are typically files in a format -# specific to the instrument and its configuration. -# -# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. +# This group enables to establish a logical connection between previous +# processing steps or on-the-fly-performed indexing of the EBSD map. +# Typically these processing steps are performed with commercial software. +# Therefore, in many cases a results file from this indexing is often +# all that is communicated and saved. These are typically files in a format +# specific to the instrument and its configuration. +# +# Typical file formats are CPR/CRC, ANG, OSC, HDF5, H5EBSD, EDAXH5. # # # # -# Principal algorithm used for indexing. +# Principal algorithm used for indexing. # # # @@ -1018,38 +1023,38 @@ NXem_ebsd(NXem_method): # # # -# Details about the background correction applied to each Kikuchi pattern. +# Details about the background correction applied to each Kikuchi pattern. # # # # -# Binning i.e. downsampling of the pattern. +# Binning i.e. downsampling of the pattern. # # # # -# Specific parameter relevant only for certain algorithms used. +# Specific parameter relevant only for certain algorithms used. # # -# +# # -# Details for each phase used as a model with which the patterns were -# indexed. Instances of :ref:`NXcrystal_structure` in this group must -# have the group name prefix phase. The identifier in the name is an -# integer. We start counting from 1 because the value 0 is reserved for -# the special phase that is the null-model, i.e. the null phase, notIndexed. +# Details for each phase used as a model with which the patterns were +# indexed. Instances of :ref:`NXcrystal_structure` in this group must +# have the group name prefix phase. The identifier in the name is an +# integer. We start counting from 1 because the value 0 is reserved for +# the special phase that is the null-model, i.e. the null phase, notIndexed. # # # # -# Which return value did the indexing algorithm yield for each scan point. -# Practically useful is to use an uint8 mask. -# -# * 0 - Not analyzed -# * 1 - Too high angular deviation -# * 2 - No solution -# * 100 - Success -# * 255 - Unexpected errors +# Which return value did the indexing algorithm yield for each scan point. +# Practically useful is to use an uint8 mask. +# +# * 0 - Not analyzed +# * 1 - Too high angular deviation +# * 2 - No solution +# * 100 - Success +# * 255 - Unexpected errors # # # @@ -1057,21 +1062,21 @@ NXem_ebsd(NXem_method): # # # -# How many phases i.e. crystal structure models were used to index each -# scan point if any? Let's assume an example to explain how this field -# should be used: In the simplest case users collected one pattern for -# each scan point and have indexed using one phase, i.e. one instance -# of an NXem_ebsd_crystal_structure_model. -# -# In another example users may have skipped some scan points (not indexed) -# them at all) and/or used differing numbers of phases for different scan -# points. -# -# The cumulated of this array decodes how phase_identifier and phase_matching -# arrays have to be interpreted. In the simplest case (one pattern per scan -# point, and all scan points indexed using that same single phase model), -# phase_identifier has as many entries as scan points -# and phase_matching has also as many entries as scan points. +# How many phases i.e. crystal structure models were used to index each +# scan point if any? Let's assume an example to explain how this field +# should be used: In the simplest case users collected one pattern for +# each scan point and have indexed using one phase, i.e. one instance +# of an NXem_ebsd_crystal_structure_model. +# +# In another example users may have skipped some scan points (not indexed) +# them at all) and/or used differing numbers of phases for different scan +# points. +# +# The cumulated of this array decodes how phase_identifier and phase_matching +# arrays have to be interpreted. In the simplest case (one pattern per scan +# point, and all scan points indexed using that same single phase model), +# phase_identifier has as many entries as scan points +# and phase_matching has also as many entries as scan points. # # # @@ -1079,28 +1084,28 @@ NXem_ebsd(NXem_method): # # # -# The array n_phases_per_scan_point details how the phase_identifier -# and the phase_matching arrays have to be interpreted. -# -# For the example with a single phase phase_identifier has trivial -# values either 0 (no solution) or 1 (solution matching -# sufficiently significant with the model for phase 1). -# -# When there are multiple phases, it is possible (although not frequently -# needed) that a pattern matches eventually (not equally well) sufficiently -# significant with multiple pattern. This can especially happen in cases of -# pseudosymmetry and more frequently with an improperly calibrated system -# or false or inaccurate phase models e.g. (ferrite, austenite). -# Having such field is especially relevant for recent machine learning -# or dictionary based indexing schemes because in combination with -# phase_matching these fields communicate the results in a model-agnostic -# way. -# -# Depending on the n_phases_per_scan_point value phase_identifier and -# phase_matching arrays represent a collection of concatenated tuples, -# which are organized in sequence: The solutions for the 0-th scan point, -# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples -# for those scan points with no phases according to n_phases_per_scan_point +# The array n_phases_per_scan_point details how the phase_identifier +# and the phase_matching arrays have to be interpreted. +# +# For the example with a single phase phase_identifier has trivial +# values either 0 (no solution) or 1 (solution matching +# sufficiently significant with the model for phase 1). +# +# When there are multiple phases, it is possible (although not frequently +# needed) that a pattern matches eventually (not equally well) sufficiently +# significant with multiple pattern. This can especially happen in cases of +# pseudosymmetry and more frequently with an improperly calibrated system +# or false or inaccurate phase models e.g. (ferrite, austenite). +# Having such field is especially relevant for recent machine learning +# or dictionary based indexing schemes because in combination with +# phase_matching these fields communicate the results in a model-agnostic +# way. +# +# Depending on the n_phases_per_scan_point value phase_identifier and +# phase_matching arrays represent a collection of concatenated tuples, +# which are organized in sequence: The solutions for the 0-th scan point, +# the 1-th scan point, the n_sc - 1 th scan point and omitting tuples +# for those scan points with no phases according to n_phases_per_scan_point # # # @@ -1108,10 +1113,10 @@ NXem_ebsd(NXem_method): # # # -# One-dimensional array, pattern by pattern labelling the solutions found. -# The array n_phases_per_scan_point has to be specified because it details -# how the phase_identifier and the phase_matching arrays have to be interpreted. -# See documentation of phase_identifier for further details. +# One-dimensional array, pattern by pattern labelling the solutions found. +# The array n_phases_per_scan_point has to be specified because it details +# how the phase_identifier and the phase_matching arrays have to be interpreted. +# See documentation of phase_identifier for further details. # # # @@ -1119,9 +1124,9 @@ NXem_ebsd(NXem_method): # # # -# Phase_matching is a descriptor for how well the solution matches or not. -# Examples can be confidence_index, mean_angular_deviation, some AI-based -# matching probability (other), i.e. the details are implementation-specific. +# Phase_matching is a descriptor for how well the solution matches or not. +# Examples can be confidence_index, mean_angular_deviation, some AI-based +# matching probability (other), i.e. the details are implementation-specific. # # # @@ -1131,22 +1136,18 @@ NXem_ebsd(NXem_method): # # # -# +# # -# +# to sample_reference_frame--> # -# Calibrated center positions of each scan point -# in the sample surface reference system. +# Calibrated center positions of each scan point +# in the sample surface reference system. # # # @@ -1155,27 +1156,31 @@ NXem_ebsd(NXem_method): # # # -# Fraction of successfully indexed pattern with a phase -# not the null-phase vs the number_of_scan_points. +# Fraction of successfully indexed pattern with a phase +# not the null-phase vs the number_of_scan_points. # # # # -# Number of scan points in the original mapping. +# Number of scan points in the original mapping. # # # # # -# An overview of the entire ROI. +# An overview of the entire ROI. # # # -# Descriptor representing the image contrast. +# Descriptor representing the image contrast. # # # @@ -1194,12 +1199,12 @@ NXem_ebsd(NXem_method): # \@long_name:--> # # -# Title of the default plot. +# Title of the default plot. # # # # -# Descriptor values displaying the ROI. +# Descriptor values displaying the ROI. # # # @@ -1210,33 +1215,33 @@ NXem_ebsd(NXem_method): # while for _indices fastest to fast--> # # -# Descriptor values. +# Descriptor values. # # # # # -# Calibrated coordinate along the y-axis. +# Calibrated coordinate along the y-axis. # # # # # # -# Label for the y axis +# Label for the y axis # # # # # -# Calibrated coordinate along the x-axis. +# Calibrated coordinate along the x-axis. # # # # # # -# Label for the x axis +# Label for the x axis # # # diff --git a/contributed_definitions/nyaml/NXenergydispersion.yaml b/contributed_definitions/nyaml/NXenergydispersion.yaml index 0db3ab83ec..b54cbb79f4 100644 --- a/contributed_definitions/nyaml/NXenergydispersion.yaml +++ b/contributed_definitions/nyaml/NXenergydispersion.yaml @@ -3,7 +3,7 @@ doc: | Subclass of NXelectronanalyser to describe the energy dispersion section of a photoelectron analyser. type: group -NXenergydispersion(NXobject): +NXenergydispersion(NXcomponent): scheme(NX_CHAR): doc: | Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, @@ -157,7 +157,7 @@ NXenergydispersion(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8a5bbb27c91cdc2b97cb9801a60382f11098fb3f0ff7f3ebf0ad1a7201cef1f2 +# 697f203f770797875b07fcb9a389363348aae8dc420e993f372d31c644432a10 # # # -# +# # # Subclass of NXelectronanalyser to describe the energy dispersion section of a # photoelectron analyser. diff --git a/contributed_definitions/nyaml/NXfiber.yaml b/contributed_definitions/nyaml/NXfiber.yaml index 99bd740b67..c9f6fde87f 100644 --- a/contributed_definitions/nyaml/NXfiber.yaml +++ b/contributed_definitions/nyaml/NXfiber.yaml @@ -18,7 +18,7 @@ symbols: # A draft of a new base class to describe an optical fiber (e.g. glass fiber) type: group -NXfiber(NXobject): +NXfiber(NXcomponent): description: exists: recommended doc: | @@ -138,7 +138,7 @@ NXfiber(NXobject): Acceptance angle of the fiber. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 60bb6b3dec7c38f043fc80d4964bd33654f2b9c4152f75a08a7c6bcb40cb9c3e +# d19abc0dac8aa84e2b5d20d1e84789fe4b24f72c337104db342b5a167ff27f1b # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXfit.yaml b/contributed_definitions/nyaml/NXfit.yaml index ca6e9a16b4..8555cc21c9 100644 --- a/contributed_definitions/nyaml/NXfit.yaml +++ b/contributed_definitions/nyaml/NXfit.yaml @@ -42,6 +42,7 @@ NXfit(NXprocess): dimensions: rank: dimRank peakPEAK(NXpeak): + nameType: partial doc: | One peak of the peak model. If there is no characteristic name for each peak component, is envisioned that peaks @@ -69,6 +70,7 @@ NXfit(NXprocess): additionally dividing by the relative sensitivity factors). Details shall be given in `global_fit_function`. backgroundBACKGROUND(NXfit_background): + nameType: partial doc: | One fitted background (functional form, position, and intensities) of the peak fit. If there is no characteristic name for each peak component, it is envisioned that backgrounds are labeled @@ -104,6 +106,7 @@ NXfit(NXprocess): It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). figure_of_meritMETRIC(NX_NUMBER): + nameType: partial unit: NX_UNITLESS doc: | Figure-of-merit to determine the goodness of fit, i.e., how well the peak model @@ -119,7 +122,7 @@ NXfit(NXprocess): - :math:`R^2`, the coefficient of determination # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e8220535e28a6d9aebaf026f5132e691dd72367b1319461238953d95d8df23f8 +# a9e341ba0c7a7522391dfc76ce51555c01d73ddf0ab75b1eb0e5b71dd2f9ced4 # # # -# +# +# # # Base class for a set of components equipping an instrument with FIB capabilities. # diff --git a/contributed_definitions/nyaml/NXidentifier.yaml b/contributed_definitions/nyaml/NXidentifier.yaml deleted file mode 100644 index db4456d7b9..0000000000 --- a/contributed_definitions/nyaml/NXidentifier.yaml +++ /dev/null @@ -1,72 +0,0 @@ -category: base -doc: | - An identifier for a (persistent) resource, e.g., a DOI or orcid. -type: group -NXidentifier(NXobject): - service(NX_CHAR): - doc: | - The service by which the resource can be resolved. - - Examples: doi, urn, hdl, purl, orcid, iso, url - identifier(NX_CHAR): - doc: | - 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. - is_persistent(NX_BOOLEAN): - doc: | - True if the identifier is persistent (i.e., unique and available indefinitely), - False otherwise. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 099e037472f021504429af9313a124518390c5cfce8466f6d1b1d4f279fc7b81 -# -# -# -# -# -# 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. -# -# -# diff --git a/contributed_definitions/nyaml/NXimage_set.yaml b/contributed_definitions/nyaml/NXimage_set.yaml index 72591a7426..4e270c21aa 100644 --- a/contributed_definitions/nyaml/NXimage_set.yaml +++ b/contributed_definitions/nyaml/NXimage_set.yaml @@ -71,7 +71,7 @@ NXimage_set(NXobject): (NXprocess): doc: | Details how NXdata instance were processed from detector readings/raw data. - source(NXserialized): + source(NXnote): doc: | Resolvable data artifact (e.g. file) from which all values in the :ref:`NXdata` instances in this :ref:`NXimage_set` were loaded during parsing. @@ -483,7 +483,7 @@ NXimage_set(NXobject): Point coordinate along the fastest dimension. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# e30b4ffdf41b611d842315092e2dde22cff48f6eed0b8e568af95cdf88e899b8 +# 57504aef23c1b9f5eb3a257e702664fda6cbfd65141fb96587310b6988f4e893 # # # # # -# Version specifier of this application definition. +# Version specifier of this application definition. # # # # -# Official NeXus NXDL schema with which this file was written. +# Official NeXus NXDL schema with which this file was written. # # # # # -# +# # -# -# +# +# # # # # -# +# # -# +# # -# A preparation step performed by a human or a robot/automated system. +# A preparation step performed by a human or a robot/automated system. # # @@ -196,15 +198,15 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# Carrier/plate used on which the abrasive/(lubricant) mixture was applied. +# Carrier/plate used on which the abrasive/(lubricant) mixture was applied. # # # # # -# Medium on the abrasive_medium_carrier (cloth or grinding plate) -# whereby material is abrasively weared. +# Medium on the abrasive_medium_carrier (cloth or grinding plate) +# whereby material is abrasively weared. # # # # # -# Lubricant +# Lubricant # # # # # -# Qualitative statement how the revelation of the machine was configured. -# If the rotation was controlled manually, e.g. by turning knobs -# choose manual and estimate the nominal average rotation. -# If the rotation was controlled via choosing from a fixed set -# of options offered by the machine choose fixed and -# specify the nominal rotation. -# If programmed use rotation_history (e.g. for automated/robot systems). +# Qualitative statement how the revelation of the machine was configured. +# If the rotation was controlled manually, e.g. by turning knobs +# choose manual and estimate the nominal average rotation. +# If the rotation was controlled via choosing from a fixed set +# of options offered by the machine choose fixed and +# specify the nominal rotation. +# If programmed use rotation_history (e.g. for automated/robot systems). # # # @@ -238,14 +240,14 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# Qualitative statement how the (piston) force with which the sample -# was pressed into/against the abrasive medium was controlled if at all. -# If the force was controlled manually e.g. by turning knobs -# choose manual and estimate nominal average force. -# If the force was controlled via choosing from a fixed set -# of options offered by the machine choose fixed and -# specify the nominal force. -# If programmed use force_history (e.g. for automated/robot systems). +# Qualitative statement how the (piston) force with which the sample +# was pressed into/against the abrasive medium was controlled if at all. +# If the force was controlled manually e.g. by turning knobs +# choose manual and estimate nominal average force. +# If the force was controlled via choosing from a fixed set +# of options offered by the machine choose fixed and +# specify the nominal force. +# If programmed use force_history (e.g. for automated/robot systems). # # # @@ -256,9 +258,9 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# Qualitative statement for how long (assuming regular uninterrupted) -# preparation at the specified conditions the preparation step was -# applied. +# Qualitative statement for how long (assuming regular uninterrupted) +# preparation at the specified conditions the preparation step was +# applied. # # # @@ -269,24 +271,24 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# Turns per unit time. +# Turns per unit time. # # # # # -# Force exerted on the sample to press it into the abrasive. +# Force exerted on the sample to press it into the abrasive. # # # # # -# Seconds +# Seconds # # # # -# Qualitative statement how the material removal was characterized. +# Qualitative statement how the material removal was characterized. # # # @@ -296,7 +298,7 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # # # -# How thick a layer was removed. +# How thick a layer was removed. # # # @@ -306,10 +308,10 @@ NXlab_electro_chemo_mechanical_preparation(NXobject): # a corrosive medium, eventually some wet lab steps have characteristics # of pure grinding, mechanical polishing, or a mixture with corrosive # attack--> -# +# # -# A preparation step performed by a human or a robot/automated system -# with the aim to remove residual abrasive medium from the specimen surface. +# A preparation step performed by a human or a robot/automated system +# with the aim to remove residual abrasive medium from the specimen surface. # # # diff --git a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml index c02e787208..82b213ba48 100644 --- a/contributed_definitions/nyaml/NXlab_sample_mounting.yaml +++ b/contributed_definitions/nyaml/NXlab_sample_mounting.yaml @@ -16,9 +16,9 @@ NXlab_sample_mounting(NXobject): doc: | Official NeXus NXDL schema with which this file was written. enumeration: [NXlab_sample_mounting] - SAMPLE(NXsample): + (NXsample): exists: ['min', '1', 'max', '1'] - USER(NXuser): + (NXuser): exists: ['min', '1', 'max', 'unbounded'] start_time(NX_DATE_TIME): end_time(NX_DATE_TIME): @@ -27,7 +27,7 @@ NXlab_sample_mounting(NXobject): mounting_machine(NXfabrication): vendor: model: - identifier(NXidentifier): + identifier: exists: recommended mounting_method: doc: | @@ -55,7 +55,7 @@ NXlab_sample_mounting(NXobject): # key question is which steps has the sample experienced? # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# effcf1879e5ea3c79aa2a5eb5975841433a079d3aa0fe7bed174fafbaf76feee +# ad85874b621c3063ca66ea36a945f5853110d63beaaa41f436ca58c6831888af # # # # # -# Version specifier of this application definition. +# Version specifier of this application definition. # # # # -# Official NeXus NXDL schema with which this file was written. +# Official NeXus NXDL schema with which this file was written. # # # # # -# -# +# +# # # # # # # -# +# # # # -# Qualitative statement how the sample was mounted. +# Qualitative statement how the sample was mounted. # # # @@ -124,7 +124,7 @@ NXlab_sample_mounting(NXobject): # # # -# Type of material. +# Type of material. # # # @@ -133,7 +133,7 @@ NXlab_sample_mounting(NXobject): # # # -# Electrical conductivity of the embedding medium. +# Electrical conductivity of the embedding medium. # # # diff --git a/contributed_definitions/nyaml/NXlens_em.yaml b/contributed_definitions/nyaml/NXlens_em.yaml index 161e29ba33..8e32a740fc 100644 --- a/contributed_definitions/nyaml/NXlens_em.yaml +++ b/contributed_definitions/nyaml/NXlens_em.yaml @@ -8,13 +8,12 @@ doc: | For details of electro-magnetic lenses in the literature see e.g. `L. Reimer `_ - -# has_part pole_piece https://purls.helmholtz-metadaten.de/emg/EMG_00000039 - -# more consolidation to harvest from a generic component base class -# with other research fields (MPES, XPS, OPT) could be useful type: group NXlens_em(NXcomponent): + name: + doc: | + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use ``NXfabrication`` and ``identifierNAME``. # user perspective value(NX_NUMBER): @@ -62,7 +61,7 @@ NXlens_em(NXcomponent): enumeration: [single, double, quadrupole, hexapole, octupole, dodecapole] # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 397ac709a5edd3c9098c327861950dc8451807c2153be5b3cd10e36629f34813 +# 14d454a5c8e20b16855b04d5257b5b03aea8b693f228c39af66d8cf5cbc292b2 # # # -# -# -# +# # -# Base class for an electro-magnetic lens or a compound lens. -# -# For :ref:`NXtransformations` the origin of the coordinate system is placed -# in the center of the lens (its polepiece, pinhole, or another -# point of reference). The origin should be specified in the :ref:`NXtransformations`. -# -# For details of electro-magnetic lenses in the literature -# see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ +# Base class for an electro-magnetic lens or a compound lens. +# +# For :ref:`NXtransformations` the origin of the coordinate system is placed +# in the center of the lens (its polepiece, pinhole, or another +# point of reference). The origin should be specified in the :ref:`NXtransformations`. +# +# For details of electro-magnetic lenses in the literature +# see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ # +# +# +# Given name, alias, colloquial, or short name for the lens. +# For manufacturer names and identifiers use ``NXfabrication`` and ``identifierNAME``. +# +# # # # -# Descriptor for the lens excitation when the exact technical details -# are unknown or not directly controllable as the control software of -# the microscope does not enable or was not configured to display these -# values (for end users). -# -# Although this value does not document the exact physical voltage or -# excitation, it can still give useful context to reproduce the lens -# setting, provided a properly working instrument and software sets the lens -# into a similar state to the technical level possible when no more -# information is available physically or accessible legally. +# Descriptor for the lens excitation when the exact technical details +# are unknown or not directly controllable as the control software of +# the microscope does not enable or was not configured to display these +# values (for end users). +# +# Although this value does not document the exact physical voltage or +# excitation, it can still give useful context to reproduce the lens +# setting, provided a properly working instrument and software sets the lens +# into a similar state to the technical level possible when no more +# information is available physically or accessible legally. # # # # -# Descriptor for the operation mode of the lens when other details are not -# directly controllable as the control software of the microscope -# does not enable or is not configured to display these values. -# -# Like value, the mode can only be interpreted for a specific microscope -# but can still be useful to guide users as to how to repeat the measurement. +# Descriptor for the operation mode of the lens when other details are not +# directly controllable as the control software of the microscope +# does not enable or is not configured to display these values. +# +# Like value, the mode can only be interpreted for a specific microscope +# but can still be useful to guide users as to how to repeat the measurement. # # # # # -# Excitation voltage of the lens. -# -# For dipoles it is a single number. -# For higher order multipoles, it is an array. +# Excitation voltage of the lens. +# +# For dipoles it is a single number. +# For higher order multipoles, it is an array. # # # # -# Excitation current of the lens. -# -# For dipoles it is a single number. -# For higher-order multipoles, it is an array. +# Excitation current of the lens. +# +# For dipoles it is a single number. +# For higher-order multipoles, it is an array. # # # # # -# Qualitative type of lens with respect to the number of pole pieces. +# Qualitative type of lens with respect to the number of pole pieces. # # # diff --git a/contributed_definitions/nyaml/NXlens_opt.yaml b/contributed_definitions/nyaml/NXlens_opt.yaml index cece0b83ea..5ca1f24975 100644 --- a/contributed_definitions/nyaml/NXlens_opt.yaml +++ b/contributed_definitions/nyaml/NXlens_opt.yaml @@ -15,7 +15,7 @@ symbols: # A draft of a new base class describing an optical lens # (Note: NXlens_em describes an electro-magnetic lens or a compound lens) type: group -NXlens_opt(NXobject): +NXlens_opt(NXcomponent): type: doc: | Type of the lens (e.g. concave, convex etc.). @@ -50,6 +50,7 @@ NXlens_opt(NXobject): rank: 2 dim: (2, N_spectrum) COATING(NXsample): + nameType: any # Used captial letters for COATING so that more than one can be defined if # the lens has different coatings on the front and back side. @@ -104,6 +105,7 @@ NXlens_opt(NXobject): rank: 1 dim: (2,) curvature_radius_FACE(NX_NUMBER): + nameType: partial exists: recommended unit: NX_LENGTH doc: | @@ -114,6 +116,7 @@ NXlens_opt(NXobject): which the light beam is incident, while the back face is the one from which the light beam exits the lens. Abbe_number(NX_NUMBER): + nameType: specified unit: NX_UNITLESS doc: | Abbe number (or V-number) of the lens. @@ -125,7 +128,7 @@ NXlens_opt(NXobject): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# c814eedb37a9fca9e4d29c052eadfc7f3f1ec0a23025b0277701dc2312cd4cb4 +# bcffd0096011eaf96dcd6697460d43f628f62eedeb05543ebb29cfcc3dd19c2e # # # -# +# # # # -# Size of the wavelength array for which the refractive index of the material -# is given. +# Size of the wavelength array for which the refractive index of the material +# is given. # # # # -# Size of the wavelength array for which the refractive index of the coating -# is given. +# Size of the wavelength array for which the refractive index of the coating +# is given. # # # # -# Size of the wavelength array for which the reflectance or transmission of -# the lens is given. +# Size of the wavelength array for which the reflectance or transmission of +# the lens is given. # # # # -# Description of an optical lens. +# Description of an optical lens. # # # -# Type of the lens (e.g. concave, convex etc.). +# Type of the lens (e.g. concave, convex etc.). # # # @@ -193,38 +196,38 @@ NXlens_opt(NXobject): # # # -# If you chose 'other' as type specify what it is. +# If you chose 'other' as type specify what it is. # # # # -# Is it a chromatic lens? +# Is it a chromatic lens? # # # # -# Diameter of the lens. +# Diameter of the lens. # # # # -# Properties of the substrate material of the lens. If the lens has a -# coating specify the coating material and its properties in 'coating'. +# Properties of the substrate material of the lens. If the lens has a +# coating specify the coating material and its properties in 'coating'. # # # -# Specify the substrate material of the lens. +# Specify the substrate material of the lens. # # # # -# Thickness of the lens substrate at the optical axis. +# Thickness of the lens substrate at the optical axis. # # # # -# Complex index of refraction of the lens material. Specify at given -# wavelength (or energy, wavenumber etc.) values. +# Complex index of refraction of the lens material. Specify at given +# wavelength (or energy, wavenumber etc.) values. # # # @@ -232,40 +235,38 @@ NXlens_opt(NXobject): # # # -# -# +# +# # -# If the lens has a coating describe the material and its properties. -# Some basic information can be found e.g. [here] -# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). -# If the back and front side of the lens are coated with different -# materials, use separate COATING(NXsample) fields to describe the coatings -# on the front and back side, respectively. For example: -# coating_front(NXsample) and coating_back(NXsample). +# If the lens has a coating describe the material and its properties. +# Some basic information can be found e.g. [here] +# (https://www.opto-e.com/basics/reflection-transmission-and-coatings). +# If the back and front side of the lens are coated with different +# materials, use separate COATING(NXsample) fields to describe the coatings +# on the front and back side, respectively. For example: +# coating_front(NXsample) and coating_back(NXsample). # # # -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). # # # # -# Describe the coating material (e.g. MgF2). +# Describe the coating material (e.g. MgF2). # # # # -# Thickness of the coating. +# Thickness of the coating. # # # # -# Complex index of refraction of the coating. Specify at given spectral -# values (wavelength, energy, wavenumber etc.). +# Complex index of refraction of the coating. Specify at given spectral +# values (wavelength, energy, wavenumber etc.). # # # @@ -275,7 +276,7 @@ NXlens_opt(NXobject): # # # -# Reflectance of the lens at given spectral values. +# Reflectance of the lens at given spectral values. # # # @@ -283,7 +284,7 @@ NXlens_opt(NXobject): # # # -# Transmission of the lens at given spectral values. +# Transmission of the lens at given spectral values. # # # @@ -291,36 +292,36 @@ NXlens_opt(NXobject): # # # -# Focal length of the lens on the front side (first value), i.e. where the -# beam is incident, and on the back side (second value). +# Focal length of the lens on the front side (first value), i.e. where the +# beam is incident, and on the back side (second value). # # # # # -# +# # -# Curvature radius of the lens. -# Instead of 'FACE' in the name of this field, the user is advised to -# specify for which surface (e.g. front or back) the curvature is provided: -# e.g. curvature_front or curvature_back. The front face is the surface on -# which the light beam is incident, while the back face is the one from -# which the light beam exits the lens. +# Curvature radius of the lens. +# Instead of 'FACE' in the name of this field, the user is advised to +# specify for which surface (e.g. front or back) the curvature is provided: +# e.g. curvature_front or curvature_back. The front face is the surface on +# which the light beam is incident, while the back face is the one from +# which the light beam exits the lens. # # -# +# # -# Abbe number (or V-number) of the lens. +# Abbe number (or V-number) of the lens. # # # # -# The numerical aperture of the used incident light optics. +# The numerical aperture of the used incident light optics. # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXlockin.yaml b/contributed_definitions/nyaml/NXlockin.yaml index e508afb255..70b5a4feac 100644 --- a/contributed_definitions/nyaml/NXlockin.yaml +++ b/contributed_definitions/nyaml/NXlockin.yaml @@ -79,26 +79,31 @@ NXlockin(NXobject): doc: | List of the demodulator channels. low_pass_N(NX_NUMBER): + nameType: partial unit: NX_FREQUENCY doc: | Frequency of the low-pass filter applied on the demodulated signals (X,Y), cut-off frq (low pass filter) (for each DemodulatorChannels). hi_pass_N(NX_NUMBER): + nameType: partial unit: NX_FREQUENCY doc: | Frequency of the high-pass filter applied on the demodulation signal cut-off frq (hi pass filter) (for each DemodulatorChannels). lp_filter_order_N(NX_NUMBER): + nameType: partial doc: | Order of the low-pass filter applied on the demodulated signals (X, Y). Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, but increases settling and measurement times. hp_filter_order_N(NX_NUMBER): + nameType: partial doc: | Order of the high-pass filter applied on the demodulation signal. This is used mainly to suppress a DC component of the input signal noise. ref_phase_N(NX_NUMBER): + nameType: partial unit: NX_ANGLE doc: | An extra reference phase offset of reference signal with respect to the demodulated signal @@ -108,6 +113,7 @@ NXlockin(NXobject): doc: | Integration time for the product of the input and the reference signals harmonic_order_N(NX_NUMBER): + nameType: partial doc: | The reference signal can be a higher harmonic of the modulation signal. Here the order of the harmonic is stored. @@ -116,7 +122,7 @@ NXlockin(NXobject): Ratio of output signal amplitude to input signal amplitue (V/V). # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 340ff0c78db623cc9da1e2fbb030f3c24cd1f514f6d5a410c310d9238449a7b1 +# 2e4a2083f48fb1b21f298f3c49187c785d39741e83a733ae619de05c45ba434f # # # # # -# A base class definition for a lock-in amplifier. -# -# The lock-in amplifier information: the device is being used to extract a (potentially) -# very weak input signal buried in the noisy background, where the input signal has -# the same frequency (or its harmonic) as a known reference signal, using heterodyne -# detection. -# This method extracts the amplitude and phase shift of the current signal to the reference. -# The reference signal might be created by a generator built-in into the lock-in amplifier. +# A base class definition for a lock-in amplifier. +# +# The lock-in amplifier information: the device is being used to extract a (potentially) +# very weak input signal buried in the noisy background, where the input signal has +# the same frequency (or its harmonic) as a known reference signal, using heterodyne +# detection. +# This method extracts the amplitude and phase shift of the current signal to the reference. +# The reference signal might be created by a generator built-in into the lock-in amplifier. # # # -# Hardware manufacturers and type (product number) of lock-in amplifier. +# Hardware manufacturers and type (product number) of lock-in amplifier. # # # # -# Description of the amplifier (after detection of the signal from the noise) +# Description of the amplifier (after detection of the signal from the noise) # # # # -# Bias divider for lock-in channel if if has. -# Bias divider = V(ref)/[V(ref)+V(input)] +# Bias divider for lock-in channel if if has. +# Bias divider = V(ref)/[V(ref)+V(input)] # # # # -# Switch the lock-in modulation on or off. +# Switch the lock-in modulation on or off. # # # # -# A periodic voltage signal generated by the lock-in, -# usually applied to a sample and used to create a reference signal for the detection of the input signal +# A periodic voltage signal generated by the lock-in, +# usually applied to a sample and used to create a reference signal for the detection of the input signal # # # # -# The sign (1 or -1) that defines the sign of the lock-in current. -# The calibration procedure with retracted tip is normally performed to compensate for the signal phase delay -# in SPM. The procedure yields two possible solutions, this number should be equal -# to 1 or -1 depending on which solution is chosen (this concept mainly used in STS experiments, -# e.g. in Nanonis machine). +# The sign (1 or -1) that defines the sign of the lock-in current. +# The calibration procedure with retracted tip is normally performed to compensate for the signal phase delay +# in SPM. The procedure yields two possible solutions, this number should be equal +# to 1 or -1 depending on which solution is chosen (this concept mainly used in STS experiments, +# e.g. in Nanonis machine). # # # @@ -193,97 +199,97 @@ NXlockin(NXobject): # even when common reference is sent to different channels--> # # -# Amplitude of the reference signal for the lock-in amplifier. +# Amplitude of the reference signal for the lock-in amplifier. # # # # -# Frequency of the reference signal for the lock-in amplifier. +# Frequency of the reference signal for the lock-in amplifier. # # # # -# Phase of the reference signal set in the lock-in amplifier. +# Phase of the reference signal set in the lock-in amplifier. # # # # -# Type of the demodulated signal, current | voltage. +# Type of the demodulated signal, current | voltage. # # # # -# The frequency of the demodulated signal. +# The frequency of the demodulated signal. # # # # -# The bandwidth of the modulated signal that can be applied in frequency -# demodulation mechanism. +# The bandwidth of the modulated signal that can be applied in frequency +# demodulation mechanism. # # # # # -# The amplitude of the demodulated signal. +# The amplitude of the demodulated signal. # # # # -# The phase of the demodulated signal. +# The phase of the demodulated signal. # # # # -# List of the demodulator channels. +# List of the demodulator channels. # # -# +# # -# Frequency of the low-pass filter applied on the demodulated -# signals (X,Y), cut-off frq (low pass filter) (for each DemodulatorChannels). +# Frequency of the low-pass filter applied on the demodulated +# signals (X,Y), cut-off frq (low pass filter) (for each DemodulatorChannels). # # -# +# # -# Frequency of the high-pass filter applied on the demodulation -# signal cut-off frq (hi pass filter) (for each DemodulatorChannels). +# Frequency of the high-pass filter applied on the demodulation +# signal cut-off frq (hi pass filter) (for each DemodulatorChannels). # # -# +# # -# Order of the low-pass filter applied on the demodulated signals (X, Y). -# Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, -# but increases settling and measurement times. +# Order of the low-pass filter applied on the demodulated signals (X, Y). +# Reducing the bandwidth or increasing the order reduces noise on the demodulated signals, +# but increases settling and measurement times. # # -# +# # -# Order of the high-pass filter applied on the demodulation -# signal. This is used mainly to suppress a DC component of the input -# signal noise. +# Order of the high-pass filter applied on the demodulation +# signal. This is used mainly to suppress a DC component of the input +# signal noise. # # -# +# # -# An extra reference phase offset of reference signal with respect to the demodulated signal -# (foreach Channels). +# An extra reference phase offset of reference signal with respect to the demodulated signal +# (foreach Channels). # # # # -# Integration time for the product of the input and the reference signals +# Integration time for the product of the input and the reference signals # # -# +# # -# The reference signal can be a higher harmonic of the modulation signal. -# Here the order of the harmonic is stored. +# The reference signal can be a higher harmonic of the modulation signal. +# Here the order of the harmonic is stored. # # # # -# Ratio of output signal amplitude to input signal amplitue (V/V). +# Ratio of output signal amplitude to input signal amplitue (V/V). # # # diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml index e3ba4c0ace..1f946680ec 100644 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -2,7 +2,7 @@ category: base doc: | definition for a magnetic kicker. type: group -NXmagnetic_kicker(NXobject): +NXmagnetic_kicker(NXcomponent): description(NX_CHAR): doc: | extended description of the kicker. @@ -41,13 +41,13 @@ NXmagnetic_kicker(NXobject): unit: NX_VOLTAGE # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 309f569f14a65c4df630758cc7b5f31575914bc0ece104c30876f7f55f9ca33e +# 5d7457340c4c16e1a7e43ffe5f0a324e1904ceb38746588fa0dc0f5e17dfb4e6 # # # -# # # -# +# # -# Extension of NXpositioner to include fields to describe the use of manipulators -# in photoemission experiments. +# Extension of NXpositioner to include fields to describe the use of manipulators +# in photoemission experiments. # # # -# Name of the manipulator. +# Name of the manipulator. # # # # -# A description of the manipulator. +# A description of the manipulator. # # # # -# Type of manipulator, Hexapod, Rod, etc. +# Type of manipulator, Hexapod, Rod, etc. # # # # -# Cryostat for cooling the sample. +# Cryostat for cooling the sample. # # # # # # -# +# # # -# In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. -# It can also be a 1D array of temperature setpoints (without time stamps). +# In case of a fixed or averaged cooling temperature, this is the scalar temperature setpoint. +# It can also be a 1D array of temperature setpoints (without time stamps). # # # # # -# In the case of an experiment in which the temperature is changed and the setpoints are -# recorded with time stamps, this is an array of length m of temperature setpoints. +# In the case of an experiment in which the temperature is changed and the setpoints are +# recorded with time stamps, this is an array of length m of temperature setpoints. # # # @@ -234,7 +208,7 @@ NXmanipulator(NXobject): # # # -# Temperature sensor measuring the sample temperature. +# Temperature sensor measuring the sample temperature. # # # @@ -243,23 +217,23 @@ NXmanipulator(NXobject): # # # -# In case of a single or averaged temperature measurement, this is the scalar temperature measured -# by the sample temperature sensor. It can also be a 1D array of measured temperatures -# (without time stamps). +# In case of a single or averaged temperature measurement, this is the scalar temperature measured +# by the sample temperature sensor. It can also be a 1D array of measured temperatures +# (without time stamps). # # # # # -# In the case of an experiment in which the temperature changes and is recorded with time stamps, -# this is an array of length m of temperatures. +# In the case of an experiment in which the temperature changes and is recorded with time stamps, +# this is an array of length m of temperatures. # # # # # # -# Device to heat the sample. +# Device to heat the sample. # # # @@ -268,30 +242,30 @@ NXmanipulator(NXobject): # # # -# In case of a fixed or averaged heating power, this is the scalar heater power. -# It can also be a 1D array of heater powers (without time stamps). +# In case of a fixed or averaged heating power, this is the scalar heater power. +# It can also be a 1D array of heater powers (without time stamps). # # # # # -# In the case of an experiment in which the heater power is changed and recorded with time stamps, -# this is an array of length m of temperature setpoints. +# In the case of an experiment in which the heater power is changed and recorded with time stamps, +# this is an array of length m of temperature setpoints. # # # -# +# # # -# In case of a fixed or averaged temperature, this is the scalar temperature setpoint. -# It can also be a 1D array of temperature setpoints (without time stamps). +# In case of a fixed or averaged temperature, this is the scalar temperature setpoint. +# It can also be a 1D array of temperature setpoints (without time stamps). # # # # # -# In the case of an experiment in which the temperature is changed and the setpoints are -# recorded with time stamps, this is an array of length m of temperature setpoints. +# In the case of an experiment in which the temperature is changed and the setpoints are +# recorded with time stamps, this is an array of length m of temperature setpoints. # # # @@ -299,7 +273,7 @@ NXmanipulator(NXobject): # # # -# Amperemeter measuring the drain current of the sample and sample holder. +# Amperemeter measuring the drain current of the sample and sample holder. # # # @@ -308,40 +282,40 @@ NXmanipulator(NXobject): # # # -# In case of a single or averaged drain current measurement, this is the scalar drain current measured between -# the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). +# In case of a single or averaged drain current measurement, this is the scalar drain current measured between +# the sample and sample holder. It can also be an 1D array of measured currents (without time stamps). # # # # # -# In the case of an experiment in which the current changes and is recorded with -# time stamps, this is an array of length m of currents. +# In the case of an experiment in which the current changes and is recorded with +# time stamps, this is an array of length m of currents. # # # # # # -# Actuator applying a voltage to sample and sample holder. +# Actuator applying a voltage to sample and sample holder. # # # # # # -# +# # # -# In case of a fixed or averaged applied bias, this is the scalar voltage applied between -# sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). +# In case of a fixed or averaged applied bias, this is the scalar voltage applied between +# sample and sample holder. It can also be an 1D array of voltage setpoints (without time stamps). # # # # # -# In the case of an experiment in which the bias is changed and the setpoints are -# recorded with time stamps, this is an array of length m of voltage setpoints. +# In the case of an experiment in which the bias is changed and the setpoints are +# recorded with time stamps, this is an array of length m of voltage setpoints. # # # @@ -349,7 +323,7 @@ NXmanipulator(NXobject): # # # -# Sensor measuring the voltage applied to sample and sample holder. +# Sensor measuring the voltage applied to sample and sample holder. # # # @@ -358,65 +332,33 @@ NXmanipulator(NXobject): # # # -# In case of a single or averaged bias measurement, this is the scalar voltage measured between -# sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). +# In case of a single or averaged bias measurement, this is the scalar voltage measured between +# sample and sample holder. It can also be an 1D array of measured voltages (without time stamps). # # # # # -# In the case of an experiment in which the bias changes and is recorded with -# time stamps, this is an array of length m of voltages. +# In the case of an experiment in which the bias changes and is recorded with +# time stamps, this is an array of length m of voltages. # # # # # # -# Any additional actuator on the manipulator used to control an external -# condition. +# Any additional actuator on the manipulator used to control an external +# condition. # # # # -# Any additional sensors on the manipulator used to monitor an external condition. +# Any additional sensors on the manipulator used to monitor an external condition. # # # # -# Class to describe the motors that are used in the manipulator +# Class to describe the motors that are used in the manipulator # # -# -# -# Refers to the last transformation specifying the positon of the manipulator in -# the NXtransformations chain. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the manipulator as a component in the instrument. Conventions from -# the NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component 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. -# -# -# # diff --git a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml index 409f2cb9a6..7930ca3479 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_gragles_config.yaml @@ -41,6 +41,7 @@ NXmicrostructure_gragles_config(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -52,11 +53,11 @@ NXmicrostructure_gragles_config(NXobject): # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file # Microstructure.SimID.10.uds # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file - grid(NXserialized): + grid(NXnote): doc: | From which file should the microstructure be instantiated. type: - path: + identifier: algorithm: checksum: edge_length(NX_FLOAT): @@ -284,7 +285,7 @@ NXmicrostructure_gragles_config(NXobject): # # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 89ba23eb12242817ed95327144820cfbcf0e5a67386185050d585c87841ad629 +# dc27836a79fd105e7e096c40c5fcde44f59d4f955a91f73fe3060fc092f77b8e # # # -# +# # -# Application definition for configuring GraGLeS. -# -# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations -# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. -# CPU parallelization is achieved with OpenMP. -# -# The code has been implemented by C. Mießen in the group of G. Gottstein -# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. -# -# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. +# Application definition for configuring GraGLeS. +# +# GraGLeS is a continuum-scale model for shared-memory-parallelized simulations +# of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. +# CPU parallelization is achieved with OpenMP. +# +# The code has been implemented by C. Mießen in the group of G. Gottstein +# at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. +# +# Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. # # # @@ -332,12 +333,12 @@ NXmicrostructure_gragles_config(NXobject): # # # -# Simulation ID as an alias to refer to this simulation. +# Simulation ID as an alias to refer to this simulation. # # # # -# Discouraged free-text field to add further details to the computation. +# Discouraged free-text field to add further details to the computation. # # # @@ -352,9 +353,9 @@ NXmicrostructure_gragles_config(NXobject): # # # -# Programs and libraries representing the computational environment +# Programs and libraries representing the computational environment # -# +# # # # @@ -367,48 +368,48 @@ NXmicrostructure_gragles_config(NXobject): # Microstructure.SimID.10.GrainIDs.2D.1188.raw all in config file # Microstructure.SimID.10.uds # 0 0, E_CUBIC, 1, E_HEXAGONAL fish from config file--> -# +# # -# From which file should the microstructure be instantiated. +# From which file should the microstructure be instantiated. # # -# +# # # # # # -# The formulation of mean curvature flow in the GraGLeS model is scale invariant. -# Therefore, the discretization has to be scaled to the actual physical length -# of the simulation domain (ve, ROI). -# For GraGLeS the discretization is always a square or cubic axis-aligned -# bounding box with a regular tiling into material points -# (either squares or cubes respectively). -# -# Edge_length is the length of the entire domain along its edge not -# the length of the Wigner-Seitz cell about each material point! +# The formulation of mean curvature flow in the GraGLeS model is scale invariant. +# Therefore, the discretization has to be scaled to the actual physical length +# of the simulation domain (ve, ROI). +# For GraGLeS the discretization is always a square or cubic axis-aligned +# bounding box with a regular tiling into material points +# (either squares or cubes respectively). +# +# Edge_length is the length of the entire domain along its edge not +# the length of the Wigner-Seitz cell about each material point! # # # # # -# Configuration when snapshots of the system should be taken. -# -# Keep in mind that essentially geometry snapshot data store the -# polylines and polyhedra of all grains which can take substantial disk -# space. +# Configuration when snapshots of the system should be taken. +# +# Keep in mind that essentially geometry snapshot data store the +# polylines and polyhedra of all grains which can take substantial disk +# space. # # # -# Generate a snapshot of the properties of the grains to follow -# the evolution of the microstructure every :math:`n`-th iteration. -# Setting zero causes that no property snapshots are taken. +# Generate a snapshot of the properties of the grains to follow +# the evolution of the microstructure every :math:`n`-th iteration. +# Setting zero causes that no property snapshots are taken. # # # # -# Generate a snapshot of the geometry of the entire grain boundary network -# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. +# Generate a snapshot of the geometry of the entire grain boundary network +# every :math:`n`-th iteration. Setting zero instructs to store no geometry data. # # # @@ -416,30 +417,30 @@ NXmicrostructure_gragles_config(NXobject): # 1--> # # -# Configuration when the simulation should be stopped in a controlled manner. -# Whichever criterion is fulfilled first triggers the controlled stop of -# and termination of GraGLeS. +# Configuration when the simulation should be stopped in a controlled manner. +# Whichever criterion is fulfilled first triggers the controlled stop of +# and termination of GraGLeS. # # # -# The simulation stops if the total number of grains -# becomes smaller than this criterion. +# The simulation stops if the total number of grains +# becomes smaller than this criterion. # # # # -# The simulation stops if more iterations than this criterion have been computed. +# The simulation stops if more iterations than this criterion have been computed. # # # # # -# Configuration of numerical details of the solver. +# Configuration of numerical details of the solver. # # # # -# Which type of convolution kernel and model is used. +# Which type of convolution kernel and model is used. # # # @@ -449,7 +450,7 @@ NXmicrostructure_gragles_config(NXobject): # # # -# Constant to calibrate the real time scaling of the simulation. +# Constant to calibrate the real time scaling of the simulation. # # # @@ -470,33 +471,33 @@ NXmicrostructure_gragles_config(NXobject): # --> # # -# Configuration of the grid coarsement algorithm whereby the representation -# of the system is continuously rediscretized such that on average grains -# are discretized with discretization many material points along each -# direction. -# -# Grid coarsement can reduce the computational costs substantially although -# it cannot be ruled out completely that the rediscretizing may have an effect -# on the system evolution. Without grid coarsement the total number of material -# points to consider stays the same throughout the simulation. +# Configuration of the grid coarsement algorithm whereby the representation +# of the system is continuously rediscretized such that on average grains +# are discretized with discretization many material points along each +# direction. +# +# Grid coarsement can reduce the computational costs substantially although +# it cannot be ruled out completely that the rediscretizing may have an effect +# on the system evolution. Without grid coarsement the total number of material +# points to consider stays the same throughout the simulation. # # # -# Number of material points along each direction to discretize the -# average grain. The larger this value is chosen the finer the curvature -# details are that can be resolved but also the longer the simulation -# takes. +# Number of material points along each direction to discretize the +# average grain. The larger this value is chosen the finer the curvature +# details are that can be resolved but also the longer the simulation +# takes. # # # # -# If true grid coarsement is active, otherwise it is not. +# If true grid coarsement is active, otherwise it is not. # # # # -# Fraction how strongly the number of grains has to reduce -# to trigger a grid coarsement step in an iteration. +# Fraction how strongly the number of grains has to reduce +# to trigger a grid coarsement step in an iteration. # # # @@ -506,20 +507,20 @@ NXmicrostructure_gragles_config(NXobject): # 0 # 0, DEFAULT, 1 skips comparison and let grains shring isolated--> # # -# Physically-based model of the assumed mobility of the grain boundaries. -# -# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent -# especially as grain boundaries in reality are decorated with defects as a consequence of which -# the actual mobility is a combination of the mobility of the individual defects and the attached -# boundary patches. Grain boundaries have different degrees of microscopic freedom. -# Therefore, their mobility follows a distribution. +# Physically-based model of the assumed mobility of the grain boundaries. +# +# Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent +# especially as grain boundaries in reality are decorated with defects as a consequence of which +# the actual mobility is a combination of the mobility of the individual defects and the attached +# boundary patches. Grain boundaries have different degrees of microscopic freedom. +# Therefore, their mobility follows a distribution. # # # # -# Fundamental model how :math:`m` is assumed a function of the disorientation -# angle :math:`\Theta`. +# Fundamental model how :math:`m` is assumed a function of the disorientation +# angle :math:`\Theta`. # # # @@ -528,39 +529,39 @@ NXmicrostructure_gragles_config(NXobject): # # # -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. +# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed +# temperature. GraGLeS was developed for modelling isothermal annealing. # # # # -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. # # # # # -# Mobility scaling factor :math:`c_2`. Typically 5. +# Mobility scaling factor :math:`c_2`. Typically 5. # # # # -# Mobility scaling factor :math:`c_3`. Typically 9. +# Mobility scaling factor :math:`c_3`. Typically 9. # # # # # -# Physically-based model of the assumed grain boundary surface energy. -# -# Like for the grain boundary mobility, defects cause a distribution of energies for the -# patches of which the boundary is composed. In practice a too complicated dependency -# of the energy and mobility model is observed as a function of the type and chemical -# decoration of the defects. Therefore, simplifying assumptions are typically made. +# Physically-based model of the assumed grain boundary surface energy. +# +# Like for the grain boundary mobility, defects cause a distribution of energies for the +# patches of which the boundary is composed. In practice a too complicated dependency +# of the energy and mobility model is observed as a function of the type and chemical +# decoration of the defects. Therefore, simplifying assumptions are typically made. # # # -# Fundamental type of assumption if energies are considered isotropic or not. +# Fundamental type of assumption if energies are considered isotropic or not. # # # @@ -569,8 +570,8 @@ NXmicrostructure_gragles_config(NXobject): # # # -# Fundamental model how :math:`\gamma` is assumed a function of the disorientation -# angle :math:`\Theta`. +# Fundamental model how :math:`\gamma` is assumed a function of the disorientation +# angle :math:`\Theta`. # # # @@ -578,9 +579,9 @@ NXmicrostructure_gragles_config(NXobject): # # # -# Mean grain boundary surface energy that is assumed a function of the -# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. -# This value factorizes the curvature_driving_force model. +# Mean grain boundary surface energy that is assumed a function of the +# disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. +# This value factorizes the curvature_driving_force model. # # # @@ -591,43 +592,43 @@ NXmicrostructure_gragles_config(NXobject): # these Scaling parameter are not read as well but utilized in the ReadShockley enery model-\->--> # # -# A continuum-scale curvature of an interface causes the interface to -# migrate towards the center of the curvature radius. +# A continuum-scale curvature of an interface causes the interface to +# migrate towards the center of the curvature radius. # # # -# If true the curvature_driving_force is considered, otherwise it is not. +# If true the curvature_driving_force is considered, otherwise it is not. # # # # # -# A continuum-scale difference of the stored elastic energy in dislocation -# configurations across a grain boundary can exert a driving force on the -# grain boundary such that the boundary migrates into the volume with the -# higher stored elastic energy. +# A continuum-scale difference of the stored elastic energy in dislocation +# configurations across a grain boundary can exert a driving force on the +# grain boundary such that the boundary migrates into the volume with the +# higher stored elastic energy. # # # -# If true the dislocation_driving_force is considered, otherwise it is not. +# If true the dislocation_driving_force is considered, otherwise it is not. # # # # -# Prefactor :math:`0.5Gb^2` that factorizes the average -# stored elastic energy per length dislocation line. +# Prefactor :math:`0.5Gb^2` that factorizes the average +# stored elastic energy per length dislocation line. # # # # # -# In case of an applied magnetic field, a difference of the magnetic -# susceptibility can exert a driving force on the grain boundary such that -# the boundary migrates into the volume with the higher magnetic energy. +# In case of an applied magnetic field, a difference of the magnetic +# susceptibility can exert a driving force on the grain boundary such that +# the boundary migrates into the volume with the higher magnetic energy. # # # -# If true the magnetic_driving_force is considered, otherwise it is not. +# If true the magnetic_driving_force is considered, otherwise it is not. # # # @@ -635,20 +636,20 @@ NXmicrostructure_gragles_config(NXobject): # https://github.com/GraGLeS/GraGLeS2D/blob/master/params/MagneticField.xml--> # # -# A triple line mediates the atomic arrangement differences between three -# interface patches. Therefore, the triple line is a defect that may not -# have the same mobility as adjoining grain boundaries and thus it may -# exert what can be conceptualized as a drag (resistance) to the motion -# of the adjoining interface patches. +# A triple line mediates the atomic arrangement differences between three +# interface patches. Therefore, the triple line is a defect that may not +# have the same mobility as adjoining grain boundaries and thus it may +# exert what can be conceptualized as a drag (resistance) to the motion +# of the adjoining interface patches. # # # -# Assumed triple junction drag. +# Assumed triple junction drag. # # # # -# -# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml index ae064f7856..843b6fc01f 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_imm_results.yaml @@ -41,10 +41,12 @@ NXmicrostructure_imm_results(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): microstructureID(NXmicrostructure): + nameType: partial grid(NXcg_grid): extent(NX_UINT): cell_dimensions(NX_NUMBER): @@ -54,6 +56,7 @@ NXmicrostructure_imm_results(NXobject): \@signal(NX_CHAR): \@axes(NX_CHAR): \@AXISNAME_indices(NX_CHAR): + nameType: partial title(NX_CHAR): crystal_identifier(NX_NUMBER): unit: NX_UNITLESS @@ -135,7 +138,7 @@ NXmicrostructure_imm_results(NXobject): dim: (c,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 08fe6beb07393be6b837da900ac777d4c6d742c361bf19ac3a0fca38fe70fa50 +# 19fd740fcafded7de4d9438988397567a8cd1ebb722f6e297bbb7d4872a782dc # # # -# +# # # # @@ -244,7 +247,7 @@ NXmicrostructure_kanapy_results(NXobject): # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml index 28dc0ebbde..10ddd08507 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_config.yaml @@ -48,6 +48,7 @@ NXmicrostructure_score_config(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -94,13 +95,13 @@ NXmicrostructure_score_config(NXobject): dimensions: rank: 2 dim: (n_dg_ori, 3) - ebsd(NXserialized): + ebsd(NXnote): exists: optional doc: | The EBSD dataset from which the initial microstructure is instantiated if model is ebsd. type: - path: + identifier: algorithm: checksum: stepsize(NX_FLOAT): @@ -384,7 +385,7 @@ NXmicrostructure_score_config(NXobject): dim: (n_su,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 422c0869db2c497f9bffff5fdab2e4801c83b6380ce9721d1bfb775d5218d0a1 +# a995666792a798962808a1aab1408074ee9d0ea48add1977f395e3eae7d49697 # # # # # -# Melting temperature in degrees Celsius. +# Melting temperature in degrees Celsius. # # # # # -# Model for the assumed mobility of grain boundaries with different disorientation -# essentially implementing variations of Turnbull's model for -# thermally-activated migration. +# Model for the assumed mobility of grain boundaries with different disorientation +# essentially implementing variations of Turnbull's model for +# thermally-activated migration. # # # -# Which type of fundamental model for the grain boundary mobility. -# -# Grain boundaries with disorientation angle smaller than 15 degree are considered -# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. +# Which type of fundamental model for the grain boundary mobility. +# +# Grain boundaries with disorientation angle smaller than 15 degree are considered +# as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. # # @@ -662,80 +663,80 @@ NXmicrostructure_score_config(NXobject): # # # -# Parameter of the Sebald-Gottstein migration model. +# Parameter of the Sebald-Gottstein migration model. # # # -# At which disorientation angle are grain boundary considered as high-angle grain -# boundaries. +# At which disorientation angle are grain boundary considered as high-angle grain +# boundaries. # # # # -# Pre-exponential factor for low-angle grain boundaries. +# Pre-exponential factor for low-angle grain boundaries. # # # # -# Migration activation enthalpy for low-angle grain boundaries. +# Migration activation enthalpy for low-angle grain boundaries. # # # # -# Pre-exponential factor for high-angle grain boundaries. +# Pre-exponential factor for high-angle grain boundaries. # # # # -# Migration activation enthalpy for high-angle grain boundaries. +# Migration activation enthalpy for high-angle grain boundaries. # # # # -# Pre-exponential factor for particularly mobile boundaries. +# Pre-exponential factor for particularly mobile boundaries. # # # # -# Migration activation enthalpy for particularly mobile boundaries. +# Migration activation enthalpy for particularly mobile boundaries. # # # # # -# Parameter of the Rollett-Holm migration model. +# Parameter of the Rollett-Holm migration model. # # # # -# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed -# temperature. GraGLeS was developed for modelling isothermal annealing. +# The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed +# temperature. GraGLeS was developed for modelling isothermal annealing. # # # # -# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. +# Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. # # # # -# Mobility scaling factor :math:`c_2`. Typically 5. +# Mobility scaling factor :math:`c_2`. Typically 5. # # # # -# Mobility scaling factor :math:`c_3`. Typically 9. +# Mobility scaling factor :math:`c_3`. Typically 9. # # # # # # -# Time-dependent reduction of the stored (elastic) energy to account for recovery. +# Time-dependent reduction of the stored (elastic) energy to account for recovery. # # # -# Which type of recovery model. +# Which type of recovery model. # # # @@ -744,12 +745,12 @@ NXmicrostructure_score_config(NXobject): # # # -# Reduction of the grain boundary migration speed due to the presence of dispersoids -# through which the total grain boundary area of the recrystallization front can be reduced. +# Reduction of the grain boundary migration speed due to the presence of dispersoids +# through which the total grain boundary area of the recrystallization front can be reduced. # # # -# Which type of drag model. +# Which type of drag model. # # # @@ -758,23 +759,23 @@ NXmicrostructure_score_config(NXobject): # # # -# Parameter of the Zener-Smith drag model. +# Parameter of the Zener-Smith drag model. # # # -# Configuration-dependent constant which factorizes the drag pressure. +# Configuration-dependent constant which factorizes the drag pressure. # # # # -# Average surface energy of the grain-boundary-dispersoid-surface configuration -# which factorizes the drag pressure. +# Average surface energy of the grain-boundary-dispersoid-surface configuration +# which factorizes the drag pressure. # # # # -# Support point of the linearized curve of simulated time matching -# a specific support point of the average dispersoid radius. +# Support point of the linearized curve of simulated time matching +# a specific support point of the average dispersoid radius. # # # @@ -782,7 +783,7 @@ NXmicrostructure_score_config(NXobject): # # # -# Support point of the linearized curve of the average dispersoid radius. +# Support point of the linearized curve of the average dispersoid radius. # # # @@ -792,12 +793,12 @@ NXmicrostructure_score_config(NXobject): # # # -# Desired simulated time-temperature profile +# Desired simulated time-temperature profile # # # -# Support point of the linearized curve of simulated time matching -# a specific support point of the temperature. +# Support point of the linearized curve of simulated time matching +# a specific support point of the temperature. # # # @@ -805,7 +806,7 @@ NXmicrostructure_score_config(NXobject): # # # -# Support point of the linearized curve of the temperature. +# Support point of the linearized curve of the temperature. # # # @@ -814,61 +815,61 @@ NXmicrostructure_score_config(NXobject): # # # -# Criteria which enable to stop the simulation in a controlled manner. -# Whichever criterion is fulfilled first stops the simulation. +# Criteria which enable to stop the simulation in a controlled manner. +# Whichever criterion is fulfilled first stops the simulation. # # # -# Maximum recrystallized volume fraction. +# Maximum recrystallized volume fraction. # # # # -# Maximum simulated physical time. +# Maximum simulated physical time. # # # # -# Maximum number of iteration steps. +# Maximum number of iteration steps. # # # # # -# Settings relevant for stable numerical integration. +# Settings relevant for stable numerical integration. # # # -# Maximum fraction equivalent to the migration of the -# fastest grain boundary in the system how much a cell -# may be consumed in a single iteration. +# Maximum fraction equivalent to the migration of the +# fastest grain boundary in the system how much a cell +# may be consumed in a single iteration. # # # # -# Fraction of the total number of cells in the CA which -# should initially be allocated for offering cells in the -# recrystallization front. +# Fraction of the total number of cells in the CA which +# should initially be allocated for offering cells in the +# recrystallization front. # # # # -# By how much more times should the already allocated memory -# be increased to offer space for storing states of cells -# in the recrystallization front. +# By how much more times should the already allocated memory +# be increased to offer space for storing states of cells +# in the recrystallization front. # # # # -# Should the cache for cells in the recrystallization front -# be defragmented on-the-fly. +# Should the cache for cells in the recrystallization front +# be defragmented on-the-fly. # # # # -# Heuristic recrystallized volume target values at which -# the cache for cells in the recrystallization front -# will be defragmented on-the-fly. +# Heuristic recrystallized volume target values at which +# the cache for cells in the recrystallization front +# will be defragmented on-the-fly. # # # @@ -878,18 +879,18 @@ NXmicrostructure_score_config(NXobject): # # # -# List of recrystallized volume target values at which a -# snapshot of the CA state should be stored. -# -# The code documents summary statistics like recrystallized volume fraction -# for each iteration. However, snapshots of the microstructure can take much -# space as SCORE is able to evolve automata with up to :math:`1600^3` cells. -# Snapshot data document the current microstructure which includes the grain -# assigned to each of these cells plus the state of the recrystallization front. -# -# Despite these front data make up for approximately one order of magnitude -# less cells than represented in the domain, more numerical data have to be -# collected each cell in the front than just a grain identifier. +# List of recrystallized volume target values at which a +# snapshot of the CA state should be stored. +# +# The code documents summary statistics like recrystallized volume fraction +# for each iteration. However, snapshots of the microstructure can take much +# space as SCORE is able to evolve automata with up to :math:`1600^3` cells. +# Snapshot data document the current microstructure which includes the grain +# assigned to each of these cells plus the state of the recrystallization front. +# +# Despite these front data make up for approximately one order of magnitude +# less cells than represented in the domain, more numerical data have to be +# collected each cell in the front than just a grain identifier. # # # @@ -899,26 +900,26 @@ NXmicrostructure_score_config(NXobject): # # # -# Perform a statistical analyses of the results as it was -# proposed by M. Kühbach (solitary unit model ensemble approach). +# Perform a statistical analyses of the results as it was +# proposed by M. Kühbach (solitary unit model ensemble approach). # # # # -# How many independent cellular automaton domains -# should be instantiated. +# How many independent cellular automaton domains +# should be instantiated. # # # # -# Into how many time steps should the real time interval be discretized upon -# during post-processing the results with the solitary unit modeling approach. +# Into how many time steps should the real time interval be discretized upon +# during post-processing the results with the solitary unit modeling approach. # # # # -# List of identifier for those domain which should be rendered. -# Identifier start from 0. +# List of identifier for those domain which should be rendered. +# Identifier start from 0. # # # diff --git a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml index 973b9fe5bf..212cab06f7 100644 --- a/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml +++ b/contributed_definitions/nyaml/NXmicrostructure_score_results.yaml @@ -60,6 +60,7 @@ NXmicrostructure_score_results(NXobject): doc: | Programs and libraries representing the computational environment programID(NXprogram): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] program(NX_CHAR): \@version(NX_CHAR): @@ -132,6 +133,7 @@ NXmicrostructure_score_results(NXobject): rank: 1 dim: (6,) spatiotemporalID(NXobject): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] doc: | Documentation of the spatiotemporal evolution @@ -235,6 +237,7 @@ NXmicrostructure_score_results(NXobject): # the typically storage-costlier snapshot data microstructureID(NXmicrostructure): + nameType: partial exists: ['min', '1', 'max', 'unbounded'] time(NX_NUMBER): iteration(NX_INT): @@ -407,7 +410,7 @@ NXmicrostructure_score_results(NXobject): # number_of_gpus(NX_POSINT): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 948da7e41fa06807004f02cfa2b9cb58683afe09dcea48a4ef3ce1c505776998 +# 97253fbdce69a2f4fe62187d9784dfcd0cabf787ad27b7cb57eb787fef8f0ee0 # # # -# +# # # # @@ -938,16 +941,16 @@ NXmicrostructure_score_results(NXobject): # # # +# exists: optional +# current_working_directory: +# command_line_call: +# exists: optional +# start_time(NX_DATE_TIME): +# exists: recommended +# end_time(NX_DATE_TIME): +# exists: recommended +# total_elapsed_time(NX_NUMBER): +# number_of_processes(NX_POSINT): +# number_of_threads(NX_POSINT): +# number_of_gpus(NX_POSINT):--> # diff --git a/contributed_definitions/nyaml/NXmpes.yaml b/contributed_definitions/nyaml/NXmpes.yaml index 2130f7af74..f3beec0f10 100644 --- a/contributed_definitions/nyaml/NXmpes.yaml +++ b/contributed_definitions/nyaml/NXmpes.yaml @@ -115,9 +115,10 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended sourceTYPE(NXsource): + nameType: partial exists: recommended doc: | A source used to generate a beam. Properties refer strictly to parameters of the @@ -146,7 +147,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended associated_beam(NX_CHAR): doc: | @@ -157,6 +158,7 @@ NXmpes(NXobject): Example: * /entry/instrument/source_probe = /entry/instrument/beam_probe beamTYPE(NXbeam): + nameType: partial doc: | Properties of the photon beam at a given location. Should be named with the same appendix as sourceTYPE, e.g., @@ -196,7 +198,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended description: exists: recommended @@ -254,7 +256,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended (NXenergydispersion): scheme: @@ -291,7 +293,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended (NXdetector): amplifier_type: @@ -310,7 +312,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended raw_data(NXdata): exists: recommended @@ -376,7 +378,7 @@ NXmpes(NXobject): type: exists: optional heater_power(NX_FLOAT): - (NXpid): + (NXpid_controller): exists: recommended setpoint(NX_FLOAT): exists: recommended @@ -388,7 +390,7 @@ NXmpes(NXobject): enumeration: [temperature] type: exists: optional - (NXpid): + (NXpid_controller): setpoint(NX_FLOAT): exists: recommended drain_current_amperemeter(NXsensor): @@ -417,7 +419,7 @@ NXmpes(NXobject): enumeration: [voltage] type: exists: optional - (NXpid): + (NXpid_controller): exists: recommended setpoint(NX_FLOAT): exists: recommended @@ -427,7 +429,7 @@ NXmpes(NXobject): exists: recommended model: exists: recommended - identifier(NXidentifier): + identifier: exists: recommended pressure_gauge(NXsensor): exists: recommended @@ -493,14 +495,17 @@ NXmpes(NXobject): calibrated_axis(NX_FLOAT): exists: recommended kN_calibration(NXcalibration): + nameType: partial exists: optional calibrated_axis(NX_FLOAT): exists: recommended angularN_calibration(NXcalibration): + nameType: partial exists: optional calibrated_axis(NX_FLOAT): exists: recommended spatialN_calibration(NXcalibration): + nameType: partial exists: optional calibrated_axis(NX_FLOAT): exists: recommended @@ -552,7 +557,7 @@ NXmpes(NXobject): dim: (n_transmission_function,) (NXsample): name: - identifier(NXidentifier): + identifier: exists: recommended (NXsubstance): exists: recommended @@ -819,7 +824,7 @@ NXmpes(NXobject): exists: recommended # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3e58ed625b14ef29d660f7b843a6a513b5b8911e65a85ff7ee1e4db07af5c20d +# 7189aa54c59dca1bf24fe83c7827926fd7735191f92b8c46482d8dcf0a0fd5e4 # # # @@ -1249,14 +1251,14 @@ NXoptical_spectroscopy(NXobject): # # # -# Angle of the linear polarized light, with respect to a fixed arbitrary -# defined 0° position. This can be used if no definition of respective -# cooridnate systems for beam and sample normal is done. If coordinate systems -# are defined, refer to beam "incident_polarization". +# Angle of the linear polarized light, with respect to a fixed arbitrary +# defined 0° position. This can be used if no definition of respective +# cooridnate systems for beam and sample normal is done. If coordinate systems +# are defined, refer to beam "incident_polarization". # # # -# +# # # # @@ -1265,7 +1267,7 @@ NXoptical_spectroscopy(NXobject): # # # -# Description of the detector type. +# Description of the detector type. # # # @@ -1282,16 +1284,16 @@ NXoptical_spectroscopy(NXobject): # # # -# Type of detector, if "other" was selected in "detector_type". +# Type of detector, if "other" was selected in "detector_type". # # # # -# Contains the raw data collected by the detector before calibration. -# The data which is considered raw might change from experiment to experiment -# due to hardware pre-processing of the data. -# This field ideally collects the data with the lowest level of processing -# possible. +# Contains the raw data collected by the detector before calibration. +# The data which is considered raw might change from experiment to experiment +# due to hardware pre-processing of the data. +# This field ideally collects the data with the lowest level of processing +# possible. # # # # -# Allows description of beam properties via matrices, which relate ingoing with -# outgoing beam properties. +# Allows description of beam properties via matrices, which relate ingoing with +# outgoing beam properties. # # # # -# Sample stage (or manipulator) for positioning of the sample. This should -# only contain the spatial orientation of movement. +# Sample stage (or manipulator) for positioning of the sample. This should +# only contain the spatial orientation of movement. # # # -# Specify the type of the sample stage. +# Specify the type of the sample stage. # # # @@ -1717,24 +1719,24 @@ NXoptical_spectroscopy(NXobject): # # # -# If "other" was chosen in stage_type, enter here a free text description -# of the stage type. +# If "other" was chosen in stage_type, enter here a free text description +# of the stage type. # # # # -# This allows a description of the stages relation or orientation and -# position with respect to the sample or beam, if an laboratory or -# an stage coordinate system is defined. +# This allows a description of the stages relation or orientation and +# position with respect to the sample or beam, if an laboratory or +# an stage coordinate system is defined. # # # # -# Description of relation of the beam with the sample. How dit the -# sample hit the beam, e.g. 'center of sample, long edge parallel -# to the plane of incidence'. -# Is redundent, if a full orientation description is done via the -# stages "transformations" entry. +# Description of relation of the beam with the sample. How dit the +# sample hit the beam, e.g. 'center of sample, long edge parallel +# to the plane of incidence'. +# Is redundent, if a full orientation description is done via the +# stages "transformations" entry. # # # @@ -1750,10 +1752,10 @@ NXoptical_spectroscopy(NXobject): # # # -# +# # -# Type of control for the sample temperature. Replace TYPE by "cryostat" or -# "heater" to specify it. +# Type of control for the sample temperature. Replace TYPE by "cryostat" or +# "heater" to specify it. # # # @@ -1769,75 +1771,75 @@ NXoptical_spectroscopy(NXobject): # # # -# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive +# Hardware used for actuation, i.e. laser, gas lamp, filament, resistive # # -# +# # # # # # # -# General device information of the optical spectroscopy setup, if -# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). -# For custom build setups, this may be limited to the construction year. +# General device information of the optical spectroscopy setup, if +# suitable (e.g. for a tabletop spectrometer or other non-custom build setups). +# For custom build setups, this may be limited to the construction year. # # # -# +# # # -# +# # # -# Commercial or otherwise defined given name of the program that was -# used to control any parts of the optical spectroscopy setup. -# The uppercase TYPE should be replaced by a specification name, i.e. -# "software_detector" or "software_stage" to specify the respective -# program or software components. +# Commercial or otherwise defined given name of the program that was +# used to control any parts of the optical spectroscopy setup. +# The uppercase TYPE should be replaced by a specification name, i.e. +# "software_detector" or "software_stage" to specify the respective +# program or software components. # # # -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. # # # # -# Description of the software by persistent resource, where the program, -# code, script etc. can be found. +# Description of the software by persistent resource, where the program, +# code, script etc. can be found. # # # # -# +# # -# Pre-calibration of an arbitrary device of the instrumental setup, which -# has the name DEVICE. You can specify here how, at which time by which method -# the calibration was done. As well the accuracy and a link to the calibration -# dataset. +# Pre-calibration of an arbitrary device of the instrumental setup, which +# has the name DEVICE. You can specify here how, at which time by which method +# the calibration was done. As well the accuracy and a link to the calibration +# dataset. # # # -# Path to the device, which was calibrated. -# Example: entry/instrument/DEVICE +# Path to the device, which was calibrated. +# Example: entry/instrument/DEVICE # # # # -# Provide data about the determined accuracy of the device, this may -# may be a single value or a dataset like wavelength error vs. wavelength etc. +# Provide data about the determined accuracy of the device, this may +# may be a single value or a dataset like wavelength error vs. wavelength etc. # # # # -# Was a calibration performed? If yes, when was it done? If the -# calibration time is provided, it should be specified in -# ENTRY/INSTRUMENT/calibration/calibration_time. +# Was a calibration performed? If yes, when was it done? If the +# calibration time is provided, it should be specified in +# ENTRY/INSTRUMENT/calibration/calibration_time. # # # @@ -1849,21 +1851,21 @@ NXoptical_spectroscopy(NXobject): # # # -# If calibtration status is 'calibration time provided', specify the -# ISO8601 date when calibration was last performed before this -# measurement. UTC offset should be specified. +# If calibtration status is 'calibration time provided', specify the +# ISO8601 date when calibration was last performed before this +# measurement. UTC offset should be specified. # # # # -# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. -# This can be for example the instrument response function. +# Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. +# This can be for example the instrument response function. # # # # # -# The overall resolution of the optical instrument. +# The overall resolution of the optical instrument. # # # @@ -1873,16 +1875,16 @@ NXoptical_spectroscopy(NXobject): # # # -# Minimum distinguishable wavelength separation of peaks in spectra. +# Minimum distinguishable wavelength separation of peaks in spectra. # # # # # -# Array of pairs of complex refractive indices n + ik of the medium -# for every measured spectral point/wavelength/energy. -# Only necessary if the measurement was performed not in air, or -# something very well known, e.g. high purity water. +# Array of pairs of complex refractive indices n + ik of the medium +# for every measured spectral point/wavelength/energy. +# Only necessary if the measurement was performed not in air, or +# something very well known, e.g. high purity water. # # # @@ -1892,71 +1894,71 @@ NXoptical_spectroscopy(NXobject): # # # -# Properties of the sample, such as sample type, layer structure, -# chemical formula, atom types, its history etc. -# Information about the sample stage and sample environment should be -# described in ENTRY/INSTRUMENT/sample_stage. +# Properties of the sample, such as sample type, layer structure, +# chemical formula, atom types, its history etc. +# Information about the sample stage and sample environment should be +# described in ENTRY/INSTRUMENT/sample_stage. # # # # -# Locally unique ID of the sample, used in the reasearch institute or group. +# Locally unique ID of the sample, used in the reasearch institute or group. # # # # -# State the form of the sample, examples are: -# thin film, single crystal, poly crystal, amorphous, single layer, -# multi layer, liquid, gas, pellet, powder. -# Generic properties of liquids or gases see NXsample properties. +# State the form of the sample, examples are: +# thin film, single crystal, poly crystal, amorphous, single layer, +# multi layer, liquid, gas, pellet, powder. +# Generic properties of liquids or gases see NXsample properties. # # # # -# Free text description of the sample. +# Free text description of the sample. # # # # -# Chemical formula of the sample. Use the Hill system (explained here: -# https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write -# the chemical formula. In case the sample consists of several layers, -# this should be a list of the chemical formulas of the individual -# layers, where the first entry is the chemical formula of the top -# layer (the one on the front surface, on which the light incident). -# The order must be consistent with layer_structure +# Chemical formula of the sample. Use the Hill system (explained here: +# https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write +# the chemical formula. In case the sample consists of several layers, +# this should be a list of the chemical formulas of the individual +# layers, where the first entry is the chemical formula of the top +# layer (the one on the front surface, on which the light incident). +# The order must be consistent with layer_structure # # # # -# List of comma-separated elements from the periodic table that are -# contained in the sample. If the sample substance has multiple -# components, all elements from each component must be included in -# 'atom_types'. +# List of comma-separated elements from the periodic table that are +# contained in the sample. If the sample substance has multiple +# components, all elements from each component must be included in +# 'atom_types'. # # # # -# ISO 8601 time code with local time zone offset to UTC information -# when the specimen was prepared. -# -# Ideally, report the end of the preparation, i.e. the last known timestamp when -# the measured specimen surface was actively prepared. +# ISO 8601 time code with local time zone offset to UTC information +# when the specimen was prepared. +# +# Ideally, report the end of the preparation, i.e. the last known timestamp when +# the measured specimen surface was actively prepared. # # # # -# A set of activities that occurred to the sample prior to/during the experiment. +# A set of activities that occurred to the sample prior to/during the experiment. # # # # -# Sample temperature (either controlled or just measured). +# Sample temperature (either controlled or just measured). # # # -# If no sensor was available for the determination of temperature, selected -# a nominal value which represents approximately the situation of sample temperature. +# If no sensor was available for the determination of temperature, selected +# a nominal value which represents approximately the situation of sample temperature. # # # @@ -1967,38 +1969,38 @@ NXoptical_spectroscopy(NXobject): # # # -# If temperature_nominal is "other", enter here a nominal/assumed/estimated -# sample temperature. +# If temperature_nominal is "other", enter here a nominal/assumed/estimated +# sample temperature. # # # # -# Temperature sensor measuring the sample temperature. -# This should be a link to /entry/instrument/manipulator/temperature_sensor. +# Temperature sensor measuring the sample temperature. +# This should be a link to /entry/instrument/manipulator/temperature_sensor. # # # # -# Device to heat the sample. -# This should be a link to /entry/instrument/manipulator/sample_heater. +# Device to heat the sample. +# This should be a link to /entry/instrument/manipulator/sample_heater. # # # # -# Device for cooling the sample (Cryostat, Airflow cooler, etc.). -# This should be a link to /entry/instrument/manipulator/cryostat. +# Device for cooling the sample (Cryostat, Airflow cooler, etc.). +# This should be a link to /entry/instrument/manipulator/cryostat. # # # # # -# Arbirary sample property which may be varied during the experiment -# and controlled by a device. Examples are pressure, voltage, magnetic field etc. -# Similar to the temperautre description of the sample. +# Arbirary sample property which may be varied during the experiment +# and controlled by a device. Examples are pressure, voltage, magnetic field etc. +# Similar to the temperautre description of the sample. # # # -# Medium, in which the sample is placed. +# Medium, in which the sample is placed. # # # @@ -2015,72 +2017,72 @@ NXoptical_spectroscopy(NXobject): # # # -# (Measured) sample thickness. -# -# The information is recorded to qualify if the light used was likely -# able to shine through the sample. -# -# In this case the value should be set to the actual thickness of -# the specimen viewed for an illumination situation where the nominal -# surface normal of the specimen is parallel to the optical axis. +# (Measured) sample thickness. +# +# The information is recorded to qualify if the light used was likely +# able to shine through the sample. +# +# In this case the value should be set to the actual thickness of +# the specimen viewed for an illumination situation where the nominal +# surface normal of the specimen is parallel to the optical axis. # # # # -# If a thickness if given, please specify how this thickness was estimated or -# determined. +# If a thickness if given, please specify how this thickness was estimated or +# determined. # # # # # -# Qualitative description of the layer structure for the sample, -# starting with the top layer (i.e. the one on the front surface, on -# which the light incident), e.g. native oxide/bulk substrate, or -# Si/native oxide/thermal oxide/polymer/peptide. +# Qualitative description of the layer structure for the sample, +# starting with the top layer (i.e. the one on the front surface, on +# which the light incident), e.g. native oxide/bulk substrate, or +# Si/native oxide/thermal oxide/polymer/peptide. # # # # -# Specify the sample orientation, how is its sample normal oriented -# relative in the laboratory reference frame, incident beam reference -# frame. +# Specify the sample orientation, how is its sample normal oriented +# relative in the laboratory reference frame, incident beam reference +# frame. # # # # -# If the sample is grown or fixed on a substrate, specify this here by -# a free text description. +# If the sample is grown or fixed on a substrate, specify this here by +# a free text description. # # # # # -# Here generic types of data may be saved.. This may refer to data derived -# from single or multiple raw measurements (i.e. several intensities are -# evaluated for different parameters: ellipsometry -> psi and delta) - -# i.e. non-raw data. -# As well plotable data may be stored/linked here, which provides the most suitable -# representation of the data (for the respective community). -# -# You may provide multiple instances of NXdata +# Here generic types of data may be saved.. This may refer to data derived +# from single or multiple raw measurements (i.e. several intensities are +# evaluated for different parameters: ellipsometry -> psi and delta) - +# i.e. non-raw data. +# As well plotable data may be stored/linked here, which provides the most suitable +# representation of the data (for the respective community). +# +# You may provide multiple instances of NXdata # # # -# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) +# Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) # # # # -# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) +# Spectrum, i.e. y-axis of the data (e.g. counts, intensity) # # # -# +# # # # -# Location to save the calibrated wavelength data. +# Location to save the calibrated wavelength data. # # # @@ -2091,11 +2093,11 @@ NXoptical_spectroscopy(NXobject): # psi and delta values), will be done later after the NXopt workshop.--> # # -# Parameters that are derived from the measured data. +# Parameters that are derived from the measured data. # # # -# Light loss due to depolarization as a value in [0-1]. +# Light loss due to depolarization as a value in [0-1]. # # # @@ -2105,7 +2107,7 @@ NXoptical_spectroscopy(NXobject): # # # -# Jones quality factor. +# Jones quality factor. # # # @@ -2115,7 +2117,7 @@ NXoptical_spectroscopy(NXobject): # # # -# Reflectivity. +# Reflectivity. # # # @@ -2125,7 +2127,7 @@ NXoptical_spectroscopy(NXobject): # # # -# Transmittance. +# Transmittance. # # # @@ -2133,22 +2135,22 @@ NXoptical_spectroscopy(NXobject): # # # -# +# # # -# Commercial or otherwise defined given name of the program that was -# used to generate or calculate the derived parameters. -# If home written, one can provide the actual steps in the NOTE -# subfield here. +# Commercial or otherwise defined given name of the program that was +# used to generate or calculate the derived parameters. +# If home written, one can provide the actual steps in the NOTE +# subfield here. # # # # -# Either version with build number, commit hash, or description of a -# (online) repository where the source code of the program and build -# instructions can be found so that the program can be configured in -# such a way that result files can be created ideally in a -# deterministic manner. +# Either version with build number, commit hash, or description of a +# (online) repository where the source code of the program and build +# instructions can be found so that the program can be configured in +# such a way that result files can be created ideally in a +# deterministic manner. # # # diff --git a/contributed_definitions/nyaml/NXpid.yaml b/contributed_definitions/nyaml/NXpid_controller.yaml similarity index 58% rename from contributed_definitions/nyaml/NXpid.yaml rename to contributed_definitions/nyaml/NXpid_controller.yaml index 696560424c..85eba3774f 100644 --- a/contributed_definitions/nyaml/NXpid.yaml +++ b/contributed_definitions/nyaml/NXpid_controller.yaml @@ -2,7 +2,7 @@ category: base doc: | Contains the settings of a PID controller. type: group -NXpid(NXobject): +NXpid_controller(NXcomponent): description: doc: | Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. @@ -27,6 +27,7 @@ NXpid(NXobject): doc: | Time log of the setpoint(s) used as an input for the PID controller. K_p_value(NX_NUMBER): + nameType: specified doc: | Proportional term. The proportional term produces an output value that is proportional to the current error value. @@ -34,6 +35,7 @@ NXpid(NXobject): 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. K_i_value(NX_NUMBER): + nameType: specified doc: | The contribution from the integral term is proportional to both the magnitude of the error and the duration of the error. @@ -43,6 +45,7 @@ NXpid(NXobject): multiplied by the integral gain (Ki) and added to the controller output. K_d_value(NX_NUMBER): + nameType: specified doc: | The derivative of the process error is calculated by determining the slope of the error over time and multiplying this rate of @@ -50,6 +53,7 @@ NXpid(NXobject): contribution of the derivative term to the overall control action is termed the derivative gain, K_d K_t_const(NX_NUMBER): + nameType: specified unit: NX_TIME doc: | The Type switches controller parameters between P/I (proportional gain/integral @@ -69,7 +73,7 @@ NXpid(NXobject): for a summary of the discussion. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2fdd9f1fe9b895042b3f4619e0bd988f7ad713ccde87a2992361baf8950cc5fe +# b277bde479ffd9d1c87bc258f315f525f149d9975ec59e9fb8412d00c29af45c # # # -# +# # -# Contains the settings of a PID controller. +# 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. +# 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 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 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. +# The Setpoint(s) used as an input for the PID controller. +# +# It can also be a link to an NXsensor.value field. # # # # -# Time log of the setpoint(s) used as an input for the PID controller. +# Time log of the setpoint(s) used as an input for the PID controller. # # -# +# # -# 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 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. +# 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 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. # # -# +# # -# 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 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 +# 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 # # -# +# # -# 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. +# 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. # # # # -# .. 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. # # # diff --git a/contributed_definitions/nyaml/NXpiezo_config_spm.yaml b/contributed_definitions/nyaml/NXpiezo_config_spm.yaml index 136a6b50e7..fe8171b385 100644 --- a/contributed_definitions/nyaml/NXpiezo_config_spm.yaml +++ b/contributed_definitions/nyaml/NXpiezo_config_spm.yaml @@ -13,6 +13,7 @@ NXpiezo_config_spm(NXobject): doc: | The material description and properties of the piezoelectric scanner materials. curvature_radius_N(NX_NUMBER): + nameType: partial unit: NX_LENGTH doc: | The N (substring) denotes X or Y. There are 2 parameters in X and Y directions. It can be set @@ -30,32 +31,38 @@ NXpiezo_config_spm(NXobject): doc: | The date of the calibration. calibrated_AXIS(NX_NUMBER): + nameType: partial doc: | The AXIS (substring) denotes X, Y or Z. There are three directions X, Y, and Z for calibration, along with three available parameters each: Calibration (m/V), Range (m), and HV gain. Only two of these parameters are required to define the calibration. Consequently, when any value is changed, one of the other values will be automatically updated. hv_gain_N(NX_NUMBER): + nameType: partial doc: | The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For these systems, the HV gain should be automatically adjusted whenever the gain is changed at the high voltage amplifier. range_N(NX_NUMBER): + nameType: partial unit: NX_LENGTH doc: | The N (substring) denotes X or Y or Z. There are 3 parameters in X, Y and Z directions. The range is the maximum distance the piezo can move. calibration_coefficient_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The calibration coefficient is the ratio of the actual distance moved by the piezo due to the voltage applied to the piezo. It is also called first-order correction. tilt_N(NX_NUMBER): + nameType: partial unit: NX_ANGLE doc: | The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according to the actual surface. - 2nd_order_correction_N(NX_NUMBER): + second_order_correction_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The N (substring) denotes X and Y directions. If you know them, you can enter the 2nd order piezo @@ -69,6 +76,7 @@ NXpiezo_config_spm(NXobject): doc: | The drift correction status (true / false) in calibration step of piezo. drift_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The N (substring) denotes X, Y and Z directions. Define the @@ -76,7 +84,7 @@ NXpiezo_config_spm(NXobject): move at that speed. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 96e710da01fe879d6ab92e5a15bf41b9f916f75e23b1d254f36999406f0afa60 +# c4d63a3b96c8b7339c29f711dcad4108ace41b7495cc6960f9426f3bfbfe324f # # # # # -# A base class describing piezo actuator settings for scanning probe microscopy. -# -# Piezoelectric actuators work utilizing the inverse-piezoelectric effect, when a voltage -# is applied on the material and it deforms proportional to the applied voltage. -# Description below shows calibration coefficients and other configuration parameters of open loop piezo actuators (that is actuators without capacitive sensor feedback systems). +# A base class describing piezo actuator settings for scanning probe microscopy. +# +# Piezoelectric actuators work utilizing the inverse-piezoelectric effect, when a voltage +# is applied on the material and it deforms proportional to the applied voltage. +# Description below shows calibration coefficients and other configuration parameters of open loop piezo actuators (that is actuators without capacitive sensor feedback systems). # # # -# The material description and properties of the piezoelectric scanner materials. +# The material description and properties of the piezoelectric scanner materials. # -# +# # -# The N (substring) denotes X or Y. There are 2 parameters in X and Y directions. It can be set -# approximately to the length of the piezo tube along X and Y axis. +# The N (substring) denotes X or Y. There are 2 parameters in X and Y directions. It can be set +# approximately to the length of the piezo tube along X and Y axis. # # # # # # -# The name of the calibration type, sometimes it is called -# `active calibration`. +# The name of the calibration type, sometimes it is called +# `active calibration`. # # # @@ -134,68 +142,68 @@ NXpiezo_config_spm(NXobject): # # # -# A specific name of the calibration (e.g. active type with name 'LHe'). +# A specific name of the calibration (e.g. active type with name 'LHe'). # # # # -# The date of the calibration. +# The date of the calibration. # # -# +# # -# The AXIS (substring) denotes X, Y or Z. There are three directions X, Y, and Z for calibration, -# along with three available parameters each: Calibration (m/V), Range (m), and HV gain. Only -# two of these parameters are required to define the calibration. Consequently, when any -# value is changed, one of the other values will be automatically updated. +# The AXIS (substring) denotes X, Y or Z. There are three directions X, Y, and Z for calibration, +# along with three available parameters each: Calibration (m/V), Range (m), and HV gain. Only +# two of these parameters are required to define the calibration. Consequently, when any +# value is changed, one of the other values will be automatically updated. # # -# +# # -# The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For -# these systems, the HV gain should be automatically adjusted whenever the gain is -# changed at the high voltage amplifier. +# The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For +# these systems, the HV gain should be automatically adjusted whenever the gain is +# changed at the high voltage amplifier. # # -# +# # -# The N (substring) denotes X or Y or Z. There are 3 parameters in X, Y and Z directions. The range -# is the maximum distance the piezo can move. +# The N (substring) denotes X or Y or Z. There are 3 parameters in X, Y and Z directions. The range +# is the maximum distance the piezo can move. # # -# +# # -# The calibration coefficient is the ratio of the actual distance moved by the piezo due to -# the voltage applied to the piezo. It is also called first-order correction. +# The calibration coefficient is the ratio of the actual distance moved by the piezo due to +# the voltage applied to the piezo. It is also called first-order correction. # # -# +# # -# The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according -# to the actual surface. +# The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according +# to the actual surface. # # -# +# # -# The N (substring) denotes X and Y directions. If you know them, you can enter the 2nd order piezo -# characteristics to compensate the error for that axis. -# The following equation shows the -# interpretation of the 2nd order correction parameters, For the X-piezo: "Ux = 1/cx · X + cxx · X2" -# with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" -# where cx is the calibration of the piezo X and cxx is the 2nd order correction. The unit for -# such the second-order correction is (V/m^2). +# The N (substring) denotes X and Y directions. If you know them, you can enter the 2nd order piezo +# characteristics to compensate the error for that axis. +# The following equation shows the +# interpretation of the 2nd order correction parameters, For the X-piezo: "Ux = 1/cx · X + cxx · X2" +# with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" +# where cx is the calibration of the piezo X and cxx is the 2nd order correction. The unit for +# such the second-order correction is (V/m^2). # # # # -# The drift correction status (true / false) in calibration step of piezo. +# The drift correction status (true / false) in calibration step of piezo. # # -# +# # -# The N (substring) denotes X, Y and Z directions. Define the -# drift speed [m/s] for all three axes. When the compensation is on, the piezo will start to -# move at that speed. +# The N (substring) denotes X, Y and Z directions. Define the +# drift speed [m/s] for all three axes. When the compensation is on, the piezo will start to +# move at that speed. # # # diff --git a/contributed_definitions/nyaml/NXpiezoelectric_material.yaml b/contributed_definitions/nyaml/NXpiezoelectric_material.yaml index 3a926a5a57..f0da505096 100644 --- a/contributed_definitions/nyaml/NXpiezoelectric_material.yaml +++ b/contributed_definitions/nyaml/NXpiezoelectric_material.yaml @@ -14,12 +14,9 @@ NXpiezoelectric_material(NXobject): doc: | The name of the material of the piezo scanner such as Lead Zirconate Titanates (PZTs). - piezo_material_identifier(NXidentifier): + identifier_piezo_material: doc: | The identifier of the piezo material. - identifier(NX_CHAR): - doc: | - The identifier of the piezo material. chemical_description(NXsubstance): doc: | The chemical formula of the material of the piezo scanner such as Pb(Zr,Ti)O3. @@ -38,22 +35,26 @@ NXpiezoelectric_material(NXobject): doc: | The relative permittivity (dielectric constant) of the piezo material. D_piezoelectric_constant(NX_NUMBER): + nameType: specified unit: NX_ANY doc: | The piezoelectric charge coefficients of the material. The coefficients describe the electric polarization generated by the applied stress in material. Different coefficients correspond to different relative directions of the polarization and the stress. G_voltage_constant(NX_NUMBER): + nameType: specified unit: NX_ANY doc: | The constants define the electric field produced by the external mechanical strain. Different coefficients correspond to different relative directions of the electric field and the strain. K_electromechanical_constant(NX_NUMBER): + nameType: specified unit: NX_ANY doc: | The electromechanical constant measures the efficiency of the conversion of mechanical energy into electrical energy. P_pyroelectric_constant(NX_NUMBER): + nameType: specified unit: NX_ANY doc: | The pyroelectric constant defines the change of the polarization vector of the piezoelectric material @@ -81,7 +82,7 @@ NXpiezoelectric_material(NXobject): viscous state. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0f228771942f8ad9c37ecfbdd4dc96d0193a3da548a401a92aec2d436caf26c6 +# 3c006a01f003b1b56a0f0de361f20a9fd21b9a234352fd024f89bce7564728b2 # # # # # -# Description and properties of the piezoelectric actuator materials. -# The piezoelectric actuator is usually composed of polycrystalline solids and -# attached at the head of the tip or cantilever. The material deforms when the external electric field is applied. +# Description and properties of the piezoelectric actuator materials. +# The piezoelectric actuator is usually composed of polycrystalline solids and +# attached at the head of the tip or cantilever. The material deforms when the external electric field is applied. # # # # -# The name of the material of the piezo scanner such as Lead Zirconate Titanates -# (PZTs). +# The name of the material of the piezo scanner such as Lead Zirconate Titanates +# (PZTs). # # -# +# # -# The identifier of the piezo material. +# The identifier of the piezo material. # -# -# -# The identifier of the piezo material. -# -# -# +# # # -# The chemical formula of the material of the piezo scanner such as Pb(Zr,Ti)O3. +# The chemical formula of the material of the piezo scanner such as Pb(Zr,Ti)O3. # # # # -# The type of the material of the piezo scanner (e.g. piezoelectric ceramics, -# polymer-film piezoelectrics). +# The type of the material of the piezo scanner (e.g. piezoelectric ceramics, +# polymer-film piezoelectrics). # # # # # -# The density of the piezo material. +# The density of the piezo material. # # # # -# The relative permittivity (dielectric constant) of the piezo material. +# The relative permittivity (dielectric constant) of the piezo material. # # -# +# # -# The piezoelectric charge coefficients of the material. The coefficients describe the electric -# polarization generated by the applied stress in material. Different coefficients correspond to different -# relative directions of the polarization and the stress. +# The piezoelectric charge coefficients of the material. The coefficients describe the electric +# polarization generated by the applied stress in material. Different coefficients correspond to different +# relative directions of the polarization and the stress. # # -# +# # -# The constants define the electric field produced by the external mechanical strain. Different coefficients -# correspond to different relative directions of the electric field and the strain. +# The constants define the electric field produced by the external mechanical strain. Different coefficients +# correspond to different relative directions of the electric field and the strain. # # -# +# # -# The electromechanical constant measures the efficiency of the conversion of mechanical energy -# into electrical energy. +# The electromechanical constant measures the efficiency of the conversion of mechanical energy +# into electrical energy. # # -# +# # -# The pyroelectric constant defines the change of the polarization vector of the piezoelectric material -# per unit change in temperature. +# The pyroelectric constant defines the change of the polarization vector of the piezoelectric material +# per unit change in temperature. # # # # -# The acoustic impedance of the piezo material. +# The acoustic impedance of the piezo material. # # # # -# The Young's modulus of the piezo material. +# The Young's modulus of the piezo material. # # # # -# The surface resistivity of the piezo material. +# The surface resistivity of the piezo material. # # # # -# The temperature range of the piezo material. +# The temperature range of the piezo material. # # # # -# The range of temperature where a piezoelectric hard material transforms into the -# viscous state. +# The range of temperature where a piezoelectric hard material transforms into the +# viscous state. # # # diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXpolarizer_opt.yaml index 7f31454f16..03bfd1dd4a 100644 --- a/contributed_definitions/nyaml/NXpolarizer_opt.yaml +++ b/contributed_definitions/nyaml/NXpolarizer_opt.yaml @@ -15,7 +15,7 @@ symbols: # A draft of a new base class to describe an optical polarizer # (NXpolarizer describes a spin polarizer) type: group -NXpolarizer_opt(NXobject): +NXpolarizer_opt(NXcomponent): type: doc: | Type of the polarizer (e.g. dichroic, linear, circular etc.) @@ -164,7 +164,7 @@ NXpolarizer_opt(NXobject): # anything missing? # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 3b9c2fc87c61369fdceeabf9d4701c2713f48dc9238767d1d88e9aceb3456c5d +# d8b34eabf0ae09437f9b3274c9fc24cf01449070de182363d535017dec81a3ad # # # # -# +# # # # diff --git a/contributed_definitions/nyaml/NXpositioner_spm.yaml b/contributed_definitions/nyaml/NXpositioner_spm.yaml index d5dd677887..50598774ca 100644 --- a/contributed_definitions/nyaml/NXpositioner_spm.yaml +++ b/contributed_definitions/nyaml/NXpositioner_spm.yaml @@ -4,7 +4,7 @@ doc: | a feedback loop, specialized for scanning probe microscopy applications. type: group NXpositioner_spm(NXpositioner): - z_controller(NXpid): + z_controller(NXpid_controller): doc: | This controller's task is to continuously adjust the Z position of the STM/STS tip in order to keep the selected control signal as close as possible to the Set Point. Different control @@ -31,7 +31,7 @@ NXpositioner_spm(NXpositioner): controller. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# a5050064b9d6434b8199aad19b42444df89447c2ffc7e324b0dacecbb0ca4c1c +# 48e2a59eca966d065844c2daedb91bd3a51ff43805f8f93c87dd89be6f4d12fa # # # # # -# Extending positioner from NXpositioner to maintain a measurement signal through -# a feedback loop, specialized for scanning probe microscopy applications. +# Extending positioner from NXpositioner to maintain a measurement signal through +# a feedback loop, specialized for scanning probe microscopy applications. # -# +# # -# This controller's task is to continuously adjust the Z position of the STM/STS tip in order -# to keep the selected control signal as close as possible to the Set Point. Different control -# signals lead to different controller's behavior. -# -# The second PID feedback loop intends to position the tip in the Z direction. -# -# p_gain (proportional gain) from z_controller is the same as K_p_value from PID controller. -# i_gain (integral gain) from z_controller is the same as K_i_value from PID controller. -# setpoint from z_controller is the same as setpoint from PID controller. +# This controller's task is to continuously adjust the Z position of the STM/STS tip in order +# to keep the selected control signal as close as possible to the Set Point. Different control +# signals lead to different controller's behavior. +# +# The second PID feedback loop intends to position the tip in the Z direction. +# +# p_gain (proportional gain) from z_controller is the same as K_p_value from PID controller. +# i_gain (integral gain) from z_controller is the same as K_i_value from PID controller. +# setpoint from z_controller is the same as setpoint from PID controller. # # # # -# Offset added to the initial averaged position tip on Z-axis before starting to -# scan. +# Offset added to the initial averaged position tip on Z-axis before starting to +# scan. # # # # -# Indicate the tip position Z. The tip position can also be varied when the controller is not running. -# This is the final position after the tip reaches an equilibrium state. +# Indicate the tip position Z. The tip position can also be varied when the controller is not running. +# This is the final position after the tip reaches an equilibrium state. # # # # -# Controller name. This name which will be displayed at places where you can select a -# controller. +# Controller name. This name which will be displayed at places where you can select a +# controller. # # # diff --git a/contributed_definitions/nyaml/NXpositioner_sts.yaml b/contributed_definitions/nyaml/NXpositioner_sts.yaml index a96a449bd6..f6941527b5 100644 --- a/contributed_definitions/nyaml/NXpositioner_sts.yaml +++ b/contributed_definitions/nyaml/NXpositioner_sts.yaml @@ -165,6 +165,7 @@ NXpositioner_sts(NXobject): doc: | The name of calibration type. calib_N(NX_NUMBER): + nameType: partial # z_contronller(NXcollection): # name: @@ -239,8 +240,8 @@ NXpositioner_sts(NXobject): Use the button to turn on/off the drift compensation. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 99dc7e3d4936a11c78fb4e36b5dd4ab02576070be0c6e5cb804c2bce89096b44 -# +# 367f8d6e539bcb93b2cb90b28e56a40ae2d2dbd386ef06a0a8383bfa66ac9799 +# # # # # -# A generic positioner such as a motor or piezo-electric transducer. +# A generic positioner such as a motor or piezo-electric transducer. # # # -# symbolic or mnemonic name (one word) +# symbolic or mnemonic name (one word) # # # # -# description of positioner +# description of positioner # # # # -# best known value of positioner - need [n] as may be scanned +# best known value of positioner - need [n] as may be scanned # # # @@ -287,7 +288,7 @@ NXpositioner_sts(NXobject): # # # -# raw value of positioner - need [n] as may be scanned +# raw value of positioner - need [n] as may be scanned # # # @@ -295,7 +296,7 @@ NXpositioner_sts(NXobject): # # # -# targeted (commanded) value of positioner - need [n] as may be scanned +# targeted (commanded) value of positioner - need [n] as may be scanned # # # @@ -303,7 +304,7 @@ NXpositioner_sts(NXobject): # # # -# maximum allowable difference between target_value and value +# maximum allowable difference between target_value and value # # # @@ -311,242 +312,242 @@ NXpositioner_sts(NXobject): # # # -# minimum allowed limit to set value +# minimum allowed limit to set value # # # # -# maximum allowed limit to set value +# maximum allowed limit to set value # # # # -# velocity of the positioner (distance moved per unit time) +# velocity of the positioner (distance moved per unit time) # # # # -# time to ramp the velocity up to full speed +# time to ramp the velocity up to full speed # # # # -# Hardware device record, e.g. EPICS process variable, taco/tango ... +# Hardware device record, e.g. EPICS process variable, taco/tango ... # # # # -# .. 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 positioner. +# 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 positioner. # # # # -# 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. # # # # -# To clarify the frame laboratory frame. The scanning area in x, y, and z position in the -# frame. +# To clarify the frame laboratory frame. The scanning area in x, y, and z position in the +# frame. # # # # -# This controllers task is to continuously adjust the Z position of the stm tip in order -# to keep the selected control signal as close as possible to the Set Point. Different control -# signals lead to different contronller beahvior. +# This controllers task is to continuously adjust the Z position of the stm tip in order +# to keep the selected control signal as close as possible to the Set Point. Different control +# signals lead to different contronller beahvior. # # # # -# Offset added to the initial averaged position Zaver before starting to swepp. +# Offset added to the initial averaged position Zaver before starting to swepp. # # # # -# Indicate the tip position Z between tip and sample. The tip position can also be varied when -# the controller is not running. +# Indicate the tip position Z between tip and sample. The tip position can also be varied when +# the controller is not running. # # # # -# Controller name. This name which will be displayed at places where you can select a -# controller. +# Controller name. This name which will be displayed at places where you can select a +# controller. # # # # -# Set Point is the desired value of the control signal. It can be set by editing the number -# or using the slider bar. Click the "Set" button above the input field to use the actual -# value as Set Point. The slider shows the Set Point as well as the current value. +# Set Point is the desired value of the control signal. It can be set by editing the number +# or using the slider bar. Click the "Set" button above the input field to use the actual +# value as Set Point. The slider shows the Set Point as well as the current value. # # # # -# Lifts the tip by the specified amount when then controller is switched off. This can be -# a positive or a negative number, i.e. the tip can also be moved towards the sample. Be -# careful with sign and value when using this feature. +# Lifts the tip by the specified amount when then controller is switched off. This can be +# a positive or a negative number, i.e. the tip can also be moved towards the sample. Be +# careful with sign and value when using this feature. # # # # -# Use this parameter for a reproducible position when switching off the Z-controller. -# When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues -# to run for the specified time and averages the Z position. +# Use this parameter for a reproducible position when switching off the Z-controller. +# When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues +# to run for the specified time and averages the Z position. # # # # -# (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during -# the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters -# are disabled. +# (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during +# the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters +# are disabled. # # # # -# The final z-position during the bias spectroscopy scan. The availability of values is -# related to the mode of scanning. +# The final z-position during the bias spectroscopy scan. The availability of values is +# related to the mode of scanning. # # # +# doc: | +# To control the tip and various scan operations.--> # # -# Configure the scan frame like x position; y position; width; height. +# Configure the scan frame like x position; y position; width; height. # # # # -# Scan resolution by setting the Lines equal to Pixels. +# Scan resolution by setting the Lines equal to Pixels. # # # # -# Define the image resolution. +# Define the image resolution. # # # # -# Define the scan forward speed in the forward direction. +# Define the scan forward speed in the forward direction. # # # # -# Define the scan backward speed in the forward direction. +# Define the scan backward speed in the forward direction. # # # # -# Piezo calibration module is used to define the X Y Z piezos calibration. +# Piezo calibration module is used to define the X Y Z piezos calibration. # # # # -# The name of calibration type. +# The name of calibration type. # # -# +# # +# doc: The unit of setpoint during the scanning.--> # # -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` -# (proportional gain/time constant). The formula for the controller in the frequency domain is: -# :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. -# The integral gain and time constant are related as follows: :math:`I = P/T`. +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` +# (proportional gain/time constant). The formula for the controller in the frequency domain is: +# :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. +# The integral gain and time constant are related as follows: :math:`I = P/T`. # # # # -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and -# P/T (proportional gain/time constant). The formula for the controller in the frequency -# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related -# as follows: `:math:I = P/T`. +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and +# P/T (proportional gain/time constant). The formula for the controller in the frequency +# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related +# as follows: `:math:I = P/T`. # # # # -# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and -# :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency -# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related -# as follows: :math:`I = P/T`. +# The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and +# :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency +# domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related +# as follows: :math:`I = P/T`. # # # +# doc: | +# (In biase spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) +# during the sweep. It is selected by default. When deselected, Z-offset and Z control time +# parameters are disabled.--> # # -# There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order -# piezo characteristics to compensate for it. The following equation shows the interpretation -# of the 2nd order correction parameter: For the X-piezo: -# :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` -# where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` +# There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order +# piezo characteristics to compensate for it. The following equation shows the interpretation +# of the 2nd order correction parameter: For the X-piezo: +# :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` +# where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` # # # # -# There are 2 parameters in X and Y directions. Define the drift speed for all three axes. -# When the compensation is on, the piezos will start to move at that speed. +# There are 2 parameters in X and Y directions. Define the drift speed for all three axes. +# When the compensation is on, the piezos will start to move at that speed. # # # # -# Use the button to turn on/off the drift compensation. +# Use the button to turn on/off the drift compensation. # # # diff --git a/contributed_definitions/nyaml/NXprocess_mpes.yaml b/contributed_definitions/nyaml/NXprocess_mpes.yaml index 9d290e607c..2f60d8bb9b 100644 --- a/contributed_definitions/nyaml/NXprocess_mpes.yaml +++ b/contributed_definitions/nyaml/NXprocess_mpes.yaml @@ -40,6 +40,7 @@ NXprocess_mpes(NXobject): doc: | This is the calibrated energy axis to be used for data plotting. kN_calibration(NXcalibration): + nameType: partial doc: | Calibration event on a k-space axis. @@ -57,6 +58,7 @@ NXprocess_mpes(NXobject): doc: | This is the calibrated k-space axis to be used for data plotting. angularN_calibration(NXcalibration): + nameType: partial doc: | Calibration event of an angular axis. @@ -70,6 +72,7 @@ NXprocess_mpes(NXobject): doc: | This is the calibrated angular axis to be used for data plotting. spatialN_calibration(NXcalibration): + nameType: partial doc: | Calibration event of a spatial axis. @@ -214,7 +217,7 @@ NXprocess_mpes(NXobject): See https://www.nexusformat.org/2014_How_to_find_default_data.html # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 1a204c9c0c2a4034318717852589000442ae85c7e9c1bcf22c04938aa344566b +# e8db16907347d628920c9865fed59970f37dbbf02c47595c24cf4d87b2d4b449 # # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -204,8 +203,7 @@ NXpulser_apm(NXobject): # Base class for a laser- and/or voltage-pulsing device used in atom probe # microscopy. # -# -# +# # # Detail whereby ion extraction is triggered methodologically. # diff --git a/contributed_definitions/nyaml/NXpump.yaml b/contributed_definitions/nyaml/NXpump.yaml index a95fb88625..526611f9ff 100644 --- a/contributed_definitions/nyaml/NXpump.yaml +++ b/contributed_definitions/nyaml/NXpump.yaml @@ -2,9 +2,8 @@ category: base doc: | Device to reduce an atmosphere (real or simulated) to a controlled pressure. type: group -NXpump(NXobject): - (NXfabrication): - design(NX_CHAR): +NXpump(NXcomponent): + design: doc: | Principle type of the pump. enumeration: [membrane, rotary_vane, roots, turbo_molecular] @@ -14,7 +13,7 @@ NXpump(NXobject): # NEW ISSUE: the role, pros and cons of pump used for atom probe microscopy # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fdea0522aa33b02d0d0a4e73cd644d5f4a87214c7c1c215833b6cea4185f5af2 +# ba7fe5441162bb60b96d2a81243a59a26268401317ece2eb428aff7e23d88945 # # # -# +# # # Device to reduce an atmosphere (real or simulated) to a controlled pressure. # -# -# +# # # Principle type of the pump. # diff --git a/contributed_definitions/nyaml/NXquadric.yaml b/contributed_definitions/nyaml/NXquadric.yaml index b657a0b043..bbeee1f717 100644 --- a/contributed_definitions/nyaml/NXquadric.yaml +++ b/contributed_definitions/nyaml/NXquadric.yaml @@ -32,7 +32,7 @@ NXquadric(NXobject): # -# # # -# +# # # # The symbols used in the schema to specify e.g. dimensions of arrays. @@ -109,7 +108,6 @@ NXreflectron(NXobject): # Given name/alias. # # -# # # # Free-text field to specify further details about the reflectron. diff --git a/contributed_definitions/nyaml/NXregion.yaml b/contributed_definitions/nyaml/NXregion.yaml index 204b091157..58ec345b27 100644 --- a/contributed_definitions/nyaml/NXregion.yaml +++ b/contributed_definitions/nyaml/NXregion.yaml @@ -150,7 +150,7 @@ NXregion(NXobject): # -# -# -# Describes the resolution of a physical quantity. -# -# -# -# The physical quantity of the resolution, e.g., -# energy, momentum, time, etc. -# -# -# -# -# The process by which the resolution was determined. -# -# -# -# -# -# -# -# -# -# -# Additional details of the estimate or description of the calibration procedure -# -# -# -# -# The resolution of the physical quantity. -# -# -# -# -# Standard deviation of the resolution of the physical quantity. -# -# -# -# -# Ratio of the resolution at a specified measurand value to that measurand value, -# -# -# -# -# Standard deviation of the relative resolution of the physical quantity. -# -# -# -# -# The response of the instrument or part to a infinitesimally sharp input signal -# along the physical quantity of this group. -# This is also sometimes called instrument response function for time resolution or -# point spread function for spatial response. -# The resolution is typically determined by taking the full width at half maximum (FWHM) -# of the response function. -# -# -# -# The input axis or grid of the response function. -# The unit should match the one of the resolution field. -# -# -# -# -# The magnitude of the response function corresponding to the points -# in the input axis or grid. -# This field should have the same dimensions as `input`. -# -# -# -# -# -# A symbol linking to another path in this appdef to be referred to from the -# `resolution_formula` field. This should be a valid path inside this application -# definition, i.e., of the form /entry/instrument/my_part/my_field. -# -# -# -# -# A resolution formula to determine the resolution from a set of symbols as -# entered by the `formula_...` fields. -# The output unit should match the provided unit of this field. -# -# -# -# -# .. 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. -# -# -# -# -# For storing details and data of a calibration to derive a resolution from data. -# -# -# diff --git a/contributed_definitions/nyaml/NXscan_control.yaml b/contributed_definitions/nyaml/NXscan_control.yaml index 8561581aad..1d23e2cdc9 100644 --- a/contributed_definitions/nyaml/NXscan_control.yaml +++ b/contributed_definitions/nyaml/NXscan_control.yaml @@ -33,12 +33,14 @@ NXscan_control(NXobject): The list is in the order of axes of the scan from the fastest to the slowest. scan_resolution_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan resolution along each dimension as the number of steps per unit of the dimension parameters. Rename the field according to the name of the independent dimension (e.g. scan_resolution_x, scan_resolution_voltage). accuracy_N(NX_NUMBER): + nameType: partial unit: NX_LENGTH doc: | Define the accuracy of the scan probe. @@ -56,16 +58,19 @@ NXscan_control(NXobject): performed. The region could be N-dimensional and is defined by the minimum and maximum values of the scan axes. scan_offset_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The offset of center of the scan region from the origin along the specific scan axis. 'N' denotes the name of the specific scan axis. (Offset, start and end positions are related) scan_range_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The range of the scan is the length of the scan region along the dimension 'N'. scan_angle_N(NX_NUMBER): + nameType: partial unit: NX_ANGLE doc: | The orientation of the scan region or subspace. Usually, the scan_offset and scan_range are enough @@ -74,6 +79,7 @@ NXscan_control(NXobject): Rename the field describing the angle with an axis of the spatial space (e.g. scan_angle_x). scan_start_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The start of the scan is the starting point of the scan region (phase space or sub-phase space) @@ -81,6 +87,7 @@ NXscan_control(NXobject): For N-dimensional, it is a list of N numbers. scan_end_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The end of the scan is the ending point of the scan region (phase space or sub-phase space) @@ -90,11 +97,13 @@ NXscan_control(NXobject): For N-dimensional, it is a list of N numbers. mesh_SCAN(NXobject): + nameType: partial doc: | For each dimension a range and a direction are chosen. When a scan along a dimension is done, a single step in the next dimension is taken, and then the scan in the previous dimension is repeated. As such we can speak about the fastest and the slowest scan axes. scan_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in the forward direction along the axis if forward and backward @@ -104,27 +113,32 @@ NXscan_control(NXobject): Rename the field, according to the name of the dimension (e.g. scan_speed_x, scan_speed_voltage). forward_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in the forward directions. Rename the field, according to the name of the dimension. backward_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in the backward directions. Rename the field, according to the name of the dimension. - channel_NAME_N: + channel_NAME: + nameType: partial doc: | Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is to represent the name of the dimensions. Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). scan_points_N(NX_NUMBER): + nameType: partial doc: | Define the total number of points in the given axis scan to be performed. Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). stepping_N(NX_NUMBER): + nameType: partial doc: | The number of steps the probe jumps over the scan steps or points. This describes when not every point from the scan_points is measured along an axis. @@ -135,12 +149,14 @@ NXscan_control(NXobject): If the scan probe jumps over a number of scan steps or points (more than one) to perform each scan. By default, it is False. step_size_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The length of each step in the scan on each dimension. Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). continuous_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe moves continuously over the scan points or steps, use True. The default value is True. Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves @@ -148,6 +164,7 @@ NXscan_control(NXobject): Rename the field, according to the name of the dimension (e.g. continuous_voltage). oscillating_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe oscillates over the scan point, use True. The default value is False. @@ -155,6 +172,7 @@ NXscan_control(NXobject): doc: | The number of oscillations on each scanning point per second. SCAN_data(NXdata): + nameType: partial data: doc: | The scan data is the data collected during the scan. @@ -163,9 +181,11 @@ NXscan_control(NXobject): # For spiral scan spiral_SCAN(NXobject): + nameType: partial doc: | To define the spiral or circular scan, use this group. scan_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in forward (clockwise) directions. @@ -180,6 +200,7 @@ NXscan_control(NXobject): along the surface normal) enumeration: [clockwise, anticlockwise] forward_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in the forward (clockwise) directions. @@ -187,6 +208,7 @@ NXscan_control(NXobject): In case, the speed is the same for all the circles, replace 'N' by 'all'. backward_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed in the backward (anti-clockwise) directions. @@ -194,18 +216,21 @@ NXscan_control(NXobject): In case, the speed is the same for all the circles, replace 'N' by 'all'. spiral_radius_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the radius of the spiral circle of scanning. Rename the field, according to the circle order, the nearest circle to the center is 0. scan_points_N(NX_NUMBER): + nameType: partial doc: | Define the total number of points in a given circle scan to be performed. Rename the field, according to the circle order, the nearest circle to the center is 0 (e.g. scan_points_2). stepping_N(NX_NUMBER): + nameType: partial doc: | If the scan probe steps over a number of scan points. @@ -216,6 +241,7 @@ NXscan_control(NXobject): If the scan probe jumps over a number of scan steps or points (more than one), use True. The default value is False. step_size_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the number of points that the scan probe steps over. @@ -224,6 +250,7 @@ NXscan_control(NXobject): parameter starts with 0. In case, the step size is the same for all the circles, replace 'N' by 'all'. continuous_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe moves continuously over the scan points, use True. The default value is True. A scan process can run continuously in the spatial dimension but can be discretized in time or @@ -232,6 +259,7 @@ NXscan_control(NXobject): Rename this field according to the dimensions, considering continuous scan in a two-dimensional space rename the field as continuous_x_y. oscillating_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe oscillates over the scan point, use True. The default value is False. @@ -240,6 +268,7 @@ NXscan_control(NXobject): doc: | Number of oscillation on each scanning point per second. SCAN_data(NXdata): + nameType: partial doc: | The scan data is the data collected during the scan. If the scan has several channels or derivatives from the channel data, please @@ -247,9 +276,11 @@ NXscan_control(NXobject): # This active_trajectory could be explained under the same group snake_SCAN(NXobject): + nameType: partial doc: | To define the snake scan, use this group. scan_speed_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | Define the scan speed for the type of snake scan. For the same speed along the @@ -269,11 +300,13 @@ NXscan_control(NXobject): Rename the field, according to the name of the fast axis. scan_points_N(NX_NUMBER): + nameType: partial doc: | Define the total number of points in the given axis scan to be performed. Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). stepping_N(NX_NUMBER): + nameType: partial doc: | The number of steps the probe jumps over the scan steps or points. @@ -285,18 +318,21 @@ NXscan_control(NXobject): Rename the field, according to the name of the dimension. step_size_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The length of each step in the scan on each dimension. Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). - channel_NAME_N: + channel_NAME: + nameType: partial doc: | Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is to represent the name of the dimensions. Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). continuous_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe moves continuously over the scan points or steps, use True. The default value is True. Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves @@ -304,6 +340,7 @@ NXscan_control(NXobject): Rename the field, according to the name of the dimension (e.g. continuous_voltage). oscillating_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe oscillates over the scan point, use True. The default value is False. @@ -312,11 +349,13 @@ NXscan_control(NXobject): doc: | The number of oscillations on each scanning point per second. SCAN_data(NXdata): + nameType: partial doc: | The scan data is the data collected during the scan. If the scan has several channels or derivatives from the channel data, please duplicate this NXdata group for each. traj_SCAN(NXobject): + nameType: partial doc: | To define the trajectory scan, use this group. scan_speed(NX_NUMBER): @@ -333,7 +372,8 @@ NXscan_control(NXobject): doc: | The field defines the scan speed in the backward directions (backtracking) through the trajectory points. - channel_NAME_N: + channel_NAME: + nameType: partial doc: | Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is to represent the name of the dimensions. @@ -352,12 +392,14 @@ NXscan_control(NXobject): rank: 2 dim: (nTraj, nD) scan_points_N(NX_NUMBER): + nameType: partial doc: | Define the total number of scan points between two trajectory points. Rename the field, according to the index of the second trajectory points. For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. stepping_N(NX_NUMBER): + nameType: partial doc: | The number of steps the probe jumps over the scan steps or points along the trajectory line from between two trajectory points. @@ -376,6 +418,7 @@ NXscan_control(NXobject): If the scan probe moves continuously over the scan points or steps between two trajectory points, use True. The default value is True. oscillating_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe oscillates over the scan point, use True. The default value is False. @@ -384,11 +427,13 @@ NXscan_control(NXobject): doc: | The number of oscillations on each scanning point per second. SCAN_data(NXdata): + nameType: partial doc: | The scan data is the data collected during the scan. If the scan has several channels or derivatives from the channel data, please duplicate this NXdata group for each. linear_SCAN(NXobject): + nameType: partial doc: | Define the scan mode that is performed for a single independent data axis. scan_speed(NX_NUMBER): @@ -405,14 +450,17 @@ NXscan_control(NXobject): doc: | Define the scan speed in the backward directions. channel_NAME(NX_CHAR): + nameType: partial doc: | Name of the channel that records the scan data for the given dimension. scan_points_N(NX_NUMBER): + nameType: partial doc: | Define the total number of points in the given axis scan to be performed. Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). stepping_N(NX_NUMBER): + nameType: partial doc: | The number of steps the probe jumps over the scan steps or points. @@ -422,12 +470,14 @@ NXscan_control(NXobject): If the scan probe jumps over a number of scan steps or points (more than one) to perform each scan. By default, it is False. step_size_N(NX_NUMBER): + nameType: partial unit: NX_ANY doc: | The length of each step in the scan on each dimension. Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). continuous_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe moves continuously over the scan points or steps, use True. The default value is True. Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves @@ -435,6 +485,7 @@ NXscan_control(NXobject): Rename the field, according to the name of the dimension (e.g. continuous_voltage). oscillating_N(NX_BOOLEAN): + nameType: partial doc: | If the scan probe oscillates over the scan point, use True. The default value is False. @@ -443,13 +494,14 @@ NXscan_control(NXobject): doc: | The number of oscillations on each scanning point per second. SCAN_data(NXdata): + nameType: partial doc: | The scan data is the data collected during the scan. If the scan has several channels or derivatives from the channel data, please duplicate this NXdata group for each. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 8352402a507d224285ddd1be6fafa63ecf38997cbc1d226daf27adf61f58301b +# 491b37f072af78bb287d8af2c9b2e97ad1cf116f6ebcda56c760e0de0f9bff44 # # # # -# A scan is performed inside an N-dimensional phase space, where each dimension can correspond not only to real space coordinates (x,y) but also to any other parameter. This class contains detailed information about controlling the scan in such a phase space (or its subspace). -# -# scan_types: -# Trajectory: A list of N-dimensional sequential vectors describes the trajectory line for a full scan. -# Mesh: For each dimension a range and a direction are chosen. When a scan along a dimension is done, a single step in the next dimension is taken, and then the scan in the previous dimension is repeated. As such we can speak about the fastest and the slowest scan axes. -# Snake: Similar to a mesh scan but with the scanning direction reversed after each line. -# Spiral: A scan taken along a spiral trajectory. -# Tilt: At each step, a proportional movement is done in all dimensions. -# Linear: A scan where the scanning will be performed along a single independent axis. -# -# Scan_control_types: -# Stepping: At each step, a movement to the next point is performed; correction (for example backlash) or active regulation (feedback loop) may or may not be applied. After the movement is done, the measurement is performed without the movement. -# Continuous: The scanning of each line in an N-dimensional phase space is done without stopping; measurements are done simultaneously with the movement. -# Oscillating: Scanning over a scan point continuously and then moving to start scanning at the next position. +# A scan is performed inside an N-dimensional phase space, where each dimension can correspond not only to real space coordinates (x,y) but also to any other parameter. This class contains detailed information about controlling the scan in such a phase space (or its subspace). +# +# scan_types: +# Trajectory: A list of N-dimensional sequential vectors describes the trajectory line for a full scan. +# Mesh: For each dimension a range and a direction are chosen. When a scan along a dimension is done, a single step in the next dimension is taken, and then the scan in the previous dimension is repeated. As such we can speak about the fastest and the slowest scan axes. +# Snake: Similar to a mesh scan but with the scanning direction reversed after each line. +# Spiral: A scan taken along a spiral trajectory. +# Tilt: At each step, a proportional movement is done in all dimensions. +# Linear: A scan where the scanning will be performed along a single independent axis. +# +# Scan_control_types: +# Stepping: At each step, a movement to the next point is performed; correction (for example backlash) or active regulation (feedback loop) may or may not be applied. After the movement is done, the measurement is performed without the movement. +# Continuous: The scanning of each line in an N-dimensional phase space is done without stopping; measurements are done simultaneously with the movement. +# Oscillating: Scanning over a scan point continuously and then moving to start scanning at the next position. # # # -# The start time of the scan. +# The start time of the scan. # # # # -# The end time of the scan. +# The end time of the scan. # # # # -# A list of scan axes which are controlled independently of each other. -# (e.g. X, Y, Z, or other physical dimensions) -# -# The list is in the order of axes of the scan from the fastest to the slowest. +# A list of scan axes which are controlled independently of each other. +# (e.g. X, Y, Z, or other physical dimensions) +# +# The list is in the order of axes of the scan from the fastest to the slowest. # # -# +# # -# Define the scan resolution along each dimension as the number of steps per unit of the dimension parameters. -# -# Rename the field according to the name of the independent dimension (e.g. scan_resolution_x, scan_resolution_voltage). +# Define the scan resolution along each dimension as the number of steps per unit of the dimension parameters. +# +# Rename the field according to the name of the independent dimension (e.g. scan_resolution_x, scan_resolution_voltage). # # -# +# # -# Define the accuracy of the scan probe. +# Define the accuracy of the scan probe. # # # # -# This group specifies how the trajectory of the scan is defined. +# This group specifies how the trajectory of the scan is defined. # # # @@ -534,7 +586,7 @@ NXscan_control(NXobject): # # # -# This strig describes how the scan was performed. +# This strig describes how the scan was performed. # # # @@ -544,162 +596,162 @@ NXscan_control(NXobject): # # # -# The scan region is the area of phase space or sub-phase space where the scan is -# performed. The region could be N-dimensional and is defined by the minimum and -# maximum values of the scan axes. +# The scan region is the area of phase space or sub-phase space where the scan is +# performed. The region could be N-dimensional and is defined by the minimum and +# maximum values of the scan axes. # -# +# # -# The offset of center of the scan region from the origin along the specific scan axis. -# -# 'N' denotes the name of the specific scan axis. (Offset, start and end positions are related) +# The offset of center of the scan region from the origin along the specific scan axis. +# +# 'N' denotes the name of the specific scan axis. (Offset, start and end positions are related) # # -# +# # -# The range of the scan is the length of the scan region along the dimension 'N'. +# The range of the scan is the length of the scan region along the dimension 'N'. # # -# +# # -# The orientation of the scan region or subspace. Usually, the scan_offset and scan_range are enough -# to define the scan region. This field defines how the spatial space is oriented with respect to -# the frame of reference. -# -# Rename the field describing the angle with an axis of the spatial space (e.g. scan_angle_x). +# The orientation of the scan region or subspace. Usually, the scan_offset and scan_range are enough +# to define the scan region. This field defines how the spatial space is oriented with respect to +# the frame of reference. +# +# Rename the field describing the angle with an axis of the spatial space (e.g. scan_angle_x). # # -# +# # -# The start of the scan is the starting point of the scan region (phase space or sub-phase space) -# for each independent scan axis. -# -# For N-dimensional, it is a list of N numbers. +# The start of the scan is the starting point of the scan region (phase space or sub-phase space) +# for each independent scan axis. +# +# For N-dimensional, it is a list of N numbers. # # -# +# # -# The end of the scan is the ending point of the scan region (phase space or sub-phase space) -# for each independent scan axis. -# -# Note: The scan_offset and scan_range are equivalent to the scan_start and scan_end. -# -# For N-dimensional, it is a list of N numbers. +# The end of the scan is the ending point of the scan region (phase space or sub-phase space) +# for each independent scan axis. +# +# Note: The scan_offset and scan_range are equivalent to the scan_start and scan_end. +# +# For N-dimensional, it is a list of N numbers. # # # -# +# # -# For each dimension a range and a direction are chosen. When a scan along a dimension is done, -# a single step in the next dimension is taken, and then the scan in the previous dimension is -# repeated. As such we can speak about the fastest and the slowest scan axes. +# For each dimension a range and a direction are chosen. When a scan along a dimension is done, +# a single step in the next dimension is taken, and then the scan in the previous dimension is +# repeated. As such we can speak about the fastest and the slowest scan axes. # -# +# # -# Define the scan speed in the forward direction along the axis if forward and backward -# speeds below are not specified. -# -# If the scan goes in the negative direction, the speed should be negative. -# -# Rename the field, according to the name of the dimension (e.g. scan_speed_x, scan_speed_voltage). +# Define the scan speed in the forward direction along the axis if forward and backward +# speeds below are not specified. +# +# If the scan goes in the negative direction, the speed should be negative. +# +# Rename the field, according to the name of the dimension (e.g. scan_speed_x, scan_speed_voltage). # # -# +# # -# Define the scan speed in the forward directions. -# Rename the field, according to the name of the dimension. +# Define the scan speed in the forward directions. +# Rename the field, according to the name of the dimension. # # -# +# # -# Define the scan speed in the backward directions. -# Rename the field, according to the name of the dimension. +# Define the scan speed in the backward directions. +# Rename the field, according to the name of the dimension. # # -# +# # -# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is -# to represent the name of the dimensions. -# -# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). +# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is +# to represent the name of the dimensions. +# +# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). # # -# +# # -# Define the total number of points in the given axis scan to be performed. -# -# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). +# Define the total number of points in the given axis scan to be performed. +# +# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). # # -# +# # -# The number of steps the probe jumps over the scan steps or points. This describes when not -# every point from the scan_points is measured along an axis. -# -# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). +# The number of steps the probe jumps over the scan steps or points. This describes when not +# every point from the scan_points is measured along an axis. +# +# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). # # # -# If the scan probe jumps over a number of scan steps or points (more than one) -# to perform each scan. By default, it is False. +# If the scan probe jumps over a number of scan steps or points (more than one) +# to perform each scan. By default, it is False. # # # -# +# # -# The length of each step in the scan on each dimension. -# -# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). +# The length of each step in the scan on each dimension. +# +# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). # # -# +# # -# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. -# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves -# in steps. -# -# Rename the field, according to the name of the dimension (e.g. continuous_voltage). +# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. +# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves +# in steps. +# +# Rename the field, according to the name of the dimension (e.g. continuous_voltage). # # -# +# # -# If the scan probe oscillates over the scan point, use True. -# The default value is False. +# If the scan probe oscillates over the scan point, use True. +# The default value is False. # # # # -# The number of oscillations on each scanning point per second. +# The number of oscillations on each scanning point per second. # # -# +# # # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, please -# duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, please +# duplicate this NXdata group for each. # # # # # -# +# # -# To define the spiral or circular scan, use this group. +# To define the spiral or circular scan, use this group. # -# +# # -# Define the scan speed in forward (clockwise) directions. -# -# If the scan goes in the negative (anti-clockwise) direction, the speed should be negative. -# -# Rename the field, according to the circle index. The circle near the center starts with 0. -# In case, the speed is the same for all the circles, replace 'N' by 'all'. +# Define the scan speed in forward (clockwise) directions. +# +# If the scan goes in the negative (anti-clockwise) direction, the speed should be negative. +# +# Rename the field, according to the circle index. The circle near the center starts with 0. +# In case, the speed is the same for all the circles, replace 'N' by 'all'. # # # -# Define the direction of the spiral scan. (e.g. clockwise, anticlockwise from looking back -# along the surface normal) +# Define the direction of the spiral scan. (e.g. clockwise, anticlockwise from looking back +# along the surface normal) # # # @@ -707,356 +759,356 @@ NXscan_control(NXobject): # # # -# +# # -# Define the scan speed in the forward (clockwise) directions. -# Rename the field, according to the circle index. The circle near the center starts with 0. -# -# In case, the speed is the same for all the circles, replace 'N' by 'all'. +# Define the scan speed in the forward (clockwise) directions. +# Rename the field, according to the circle index. The circle near the center starts with 0. +# +# In case, the speed is the same for all the circles, replace 'N' by 'all'. # # -# +# # -# Define the scan speed in the backward (anti-clockwise) directions. -# Rename the field, according to the circle index. The circle near the center starts with 0. -# -# In case, the speed is the same for all the circles, replace 'N' by 'all'. +# Define the scan speed in the backward (anti-clockwise) directions. +# Rename the field, according to the circle index. The circle near the center starts with 0. +# +# In case, the speed is the same for all the circles, replace 'N' by 'all'. # # -# +# # -# Define the radius of the spiral circle of scanning. -# -# Rename the field, according to the circle order, the nearest circle to the center is 0. +# Define the radius of the spiral circle of scanning. +# +# Rename the field, according to the circle order, the nearest circle to the center is 0. # # -# +# # -# Define the total number of points in a given circle scan to be performed. -# -# Rename the field, according to the circle order, the nearest circle to the center -# is 0 (e.g. scan_points_2). +# Define the total number of points in a given circle scan to be performed. +# +# Rename the field, according to the circle order, the nearest circle to the center +# is 0 (e.g. scan_points_2). # # -# +# # -# If the scan probe steps over a number of scan points. -# -# Rename the field, according to the circle index. The circle near the center starts with 0. -# In case, the stepping is the same for all the circles, replace 'N' by 'all'. +# If the scan probe steps over a number of scan points. +# +# Rename the field, according to the circle index. The circle near the center starts with 0. +# In case, the stepping is the same for all the circles, replace 'N' by 'all'. # # # -# If the scan probe jumps over a number of scan steps or points (more than one), use True. -# The default value is False. +# If the scan probe jumps over a number of scan steps or points (more than one), use True. +# The default value is False. # # # -# +# # -# Define the number of points that the scan probe steps over. -# -# Rename the field, according to the circle index. The circle near the center or lowest value of a -# parameter starts with 0. -# In case, the step size is the same for all the circles, replace 'N' by 'all'. +# Define the number of points that the scan probe steps over. +# +# Rename the field, according to the circle index. The circle near the center or lowest value of a +# parameter starts with 0. +# In case, the step size is the same for all the circles, replace 'N' by 'all'. # # -# +# # -# If the scan probe moves continuously over the scan points, use True. The default value is True. -# A scan process can run continuously in the spatial dimension but can be discretized in time or -# other physical dimensions (e.g. voltage). -# -# Rename this field according to the dimensions, considering continuous scan in a two-dimensional space -# rename the field as continuous_x_y. +# If the scan probe moves continuously over the scan points, use True. The default value is True. +# A scan process can run continuously in the spatial dimension but can be discretized in time or +# other physical dimensions (e.g. voltage). +# +# Rename this field according to the dimensions, considering continuous scan in a two-dimensional space +# rename the field as continuous_x_y. # # -# +# # -# If the scan probe oscillates over the scan point, use True. The default value is -# False. +# If the scan probe oscillates over the scan point, use True. The default value is +# False. # # # # -# Number of oscillation on each scanning point per second. +# Number of oscillation on each scanning point per second. # # -# +# # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, please -# duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, please +# duplicate this NXdata group for each. # # # # -# +# # -# To define the snake scan, use this group. +# To define the snake scan, use this group. # -# +# # -# Define the scan speed for the type of snake scan. For the same speed along the -# positive and negative directions, use a single number -# -# Rename the field, according to the name of the fast and slow axis e.g. scan_speed_x. +# Define the scan speed for the type of snake scan. For the same speed along the +# positive and negative directions, use a single number +# +# Rename the field, according to the name of the fast and slow axis e.g. scan_speed_x. # # # # -# The field defines the scan speed in the positive direction on the fast axis. -# -# Rename the field, according to the name of the fast axis. +# The field defines the scan speed in the positive direction on the fast axis. +# +# Rename the field, according to the name of the fast axis. # # # # -# The field defines the scan speed in the negative direction on the fast axis. -# -# Rename the field, according to the name of the fast axis. +# The field defines the scan speed in the negative direction on the fast axis. +# +# Rename the field, according to the name of the fast axis. # # -# +# # -# Define the total number of points in the given axis scan to be performed. -# -# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). +# Define the total number of points in the given axis scan to be performed. +# +# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). # # -# +# # -# The number of steps the probe jumps over the scan steps or points. -# -# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). +# The number of steps the probe jumps over the scan steps or points. +# +# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). # # # -# If the scan probe jumps over a number of scan steps or points (more than one) -# to perform each scan. By default, it is False. -# -# Rename the field, according to the name of the dimension. +# If the scan probe jumps over a number of scan steps or points (more than one) +# to perform each scan. By default, it is False. +# +# Rename the field, according to the name of the dimension. # # # -# +# # -# The length of each step in the scan on each dimension. -# -# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). +# The length of each step in the scan on each dimension. +# +# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). # # -# +# # -# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is -# to represent the name of the dimensions. -# -# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). +# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is +# to represent the name of the dimensions. +# +# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). # # -# +# # -# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. -# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves -# in a stepping manner. -# -# Rename the field, according to the name of the dimension (e.g. continuous_voltage). +# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. +# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves +# in a stepping manner. +# +# Rename the field, according to the name of the dimension (e.g. continuous_voltage). # # -# +# # -# If the scan probe oscillates over the scan point, use True. -# The default value is False. +# If the scan probe oscillates over the scan point, use True. +# The default value is False. # # # # -# The number of oscillations on each scanning point per second. +# The number of oscillations on each scanning point per second. # # -# +# # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, please -# duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, please +# duplicate this NXdata group for each. # # # -# +# # -# To define the trajectory scan, use this group. +# To define the trajectory scan, use this group. # # # -# Define the scan speed through the trajectory points. +# Define the scan speed through the trajectory points. # # # # -# The field defines the scan speed in the forward directions through the -# trajectory points. +# The field defines the scan speed in the forward directions through the +# trajectory points. # # # # -# The field defines the scan speed in the backward directions (backtracking) -# through the trajectory points. +# The field defines the scan speed in the backward directions (backtracking) +# through the trajectory points. # # -# +# # -# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is -# to represent the name of the dimensions. -# -# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). +# Name of the channel that records the scan data for the given dimension. The ending annotation 'N' is +# to represent the name of the dimensions. +# +# Rename the field, according to the name of the channel and dimension (e.g. piezo_scanner_x). # # # # -# The number of trajectory points in the entire scan. +# The number of trajectory points in the entire scan. # # # # -# The trajectory points are the N-dimensional vectors describing all the scan points sequentially. -# -# The second rank dataset should contain total number of trajectory points (nTraj) and -# a full coordinate (nD) of each trajectory point. +# The trajectory points are the N-dimensional vectors describing all the scan points sequentially. +# +# The second rank dataset should contain total number of trajectory points (nTraj) and +# a full coordinate (nD) of each trajectory point. # # # # # # -# +# # -# Define the total number of scan points between two trajectory points. -# -# Rename the field, according to the index of the second trajectory points. -# For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. +# Define the total number of scan points between two trajectory points. +# +# Rename the field, according to the index of the second trajectory points. +# For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. # # -# +# # -# The number of steps the probe jumps over the scan steps or points along the trajectory line from between two trajectory points. -# -# Rename the field, according to the index of the second trajectory points. -# For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. +# The number of steps the probe jumps over the scan steps or points along the trajectory line from between two trajectory points. +# +# Rename the field, according to the index of the second trajectory points. +# For example, scan_points_1 is the number of points between the starting(zero) and first trajectory points. # # # -# If the scan probe jumps over a number of scan steps or points (more than one) -# to perform each scan. By default, it is False. +# If the scan probe jumps over a number of scan steps or points (more than one) +# to perform each scan. By default, it is False. # # # # # -# The length of each step along the entire trajectory line. +# The length of each step along the entire trajectory line. # # # # -# If the scan probe moves continuously over the scan points or steps between two -# trajectory points, use True. The default value is True. +# If the scan probe moves continuously over the scan points or steps between two +# trajectory points, use True. The default value is True. # # -# +# # -# If the scan probe oscillates over the scan point, use True. -# The default value is False. +# If the scan probe oscillates over the scan point, use True. +# The default value is False. # # # # -# The number of oscillations on each scanning point per second. +# The number of oscillations on each scanning point per second. # # -# +# # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, please -# duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, please +# duplicate this NXdata group for each. # # # -# +# # -# Define the scan mode that is performed for a single independent data axis. +# Define the scan mode that is performed for a single independent data axis. # # # -# Define the scan speed of the scan disregarding the forward or backward -# direction. +# Define the scan speed of the scan disregarding the forward or backward +# direction. # # # # -# Define the scan speed in the forward directions. +# Define the scan speed in the forward directions. # # # # -# Define the scan speed in the backward directions. +# Define the scan speed in the backward directions. # # -# +# # -# Name of the channel that records the scan data for the given dimension. +# Name of the channel that records the scan data for the given dimension. # # -# +# # -# Define the total number of points in the given axis scan to be performed. -# -# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). +# Define the total number of points in the given axis scan to be performed. +# +# Rename the field, according to the name of the dimension (e.g. scan_points_x, scan_points_voltage). # # -# +# # -# The number of steps the probe jumps over the scan steps or points. -# -# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). +# The number of steps the probe jumps over the scan steps or points. +# +# Rename the field, according to the name of the dimension (e.g. stepping_x, stepping_voltage). # # # -# If the scan probe jumps over a number of scan steps or points (more than one) -# to perform each scan. By default, it is False. +# If the scan probe jumps over a number of scan steps or points (more than one) +# to perform each scan. By default, it is False. # # # -# +# # -# The length of each step in the scan on each dimension. -# -# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). +# The length of each step in the scan on each dimension. +# +# Rename the field, according to the name of the dimension (e.g. step_size_x, step_size_voltage). # # -# +# # -# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. -# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves -# in a stepping manner. -# -# Rename the field, according to the name of the dimension (e.g. continuous_voltage). +# If the scan probe moves continuously over the scan points or steps, use True. The default value is True. +# Usually, continuous scanning is possible in one dimension. On other dimensions, the scan probe moves +# in a stepping manner. +# +# Rename the field, according to the name of the dimension (e.g. continuous_voltage). # # -# +# # -# If the scan probe oscillates over the scan point, use True. -# The default value is False. +# If the scan probe oscillates over the scan point, use True. +# The default value is False. # # # # -# The number of oscillations on each scanning point per second. +# The number of oscillations on each scanning point per second. # # -# +# # -# The scan data is the data collected during the scan. -# If the scan has several channels or derivatives from the channel data, please -# duplicate this NXdata group for each. +# The scan data is the data collected during the scan. +# If the scan has several channels or derivatives from the channel data, please +# duplicate this NXdata group for each. # # # diff --git a/contributed_definitions/nyaml/NXscanbox_em.yaml b/contributed_definitions/nyaml/NXscanbox_em.yaml index 013e21590e..e19a731485 100644 --- a/contributed_definitions/nyaml/NXscanbox_em.yaml +++ b/contributed_definitions/nyaml/NXscanbox_em.yaml @@ -107,7 +107,7 @@ NXscanbox_em(NXcomponent): # # # # For further information, see http://www.nexusformat.org # --> -# +# # # Scan box and coils which deflect a beam of charged particles in a controlled manner. # diff --git a/contributed_definitions/nyaml/NXsensor_scan.yaml b/contributed_definitions/nyaml/NXsensor_scan.yaml index da0b672c3c..4b5244398c 100644 --- a/contributed_definitions/nyaml/NXsensor_scan.yaml +++ b/contributed_definitions/nyaml/NXsensor_scan.yaml @@ -27,23 +27,23 @@ NXsensor_scan(NXobject): definition(NX_CHAR): \@version: enumeration: [NXsensor_scan] - experiment_identifier(NXidentifier): + identifier_experiment: exists: recommended doc: | The unique identifier for the entry. The identifier is mainly lab-defined and can be a combination of the sample name, date and time, experiment condition (such as temperature) or instrument-generated unique identifier. - collection_identifier(NXidentifier): + identifier_collection: exists: optional doc: | The unique identifier for the collection. The identifier is used to group a number of the experiments run upon the same setup and/or same sample. experiment_description: exists: recommended - start_time(NX_NUMBER): + start_time(NX_DATE_TIME): unit: NX_TIME exists: recommended - end_time(NX_NUMBER): + end_time(NX_DATE_TIME): unit: NX_TIME exists: recommended (NXprocess): @@ -148,7 +148,7 @@ NXsensor_scan(NXobject): doc: | ISO8601 datum when calibration was last performed before this measurement. UTC offset should be specified. - (NXpid): + (NXpid_controller): independent_controllers: doc: | A list of names of NXsensor groups used as independently scanned controllers. @@ -166,7 +166,7 @@ NXsensor_scan(NXobject): Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 9d1b4ddda3ab18f649b5c8d64cde1e5b5ab603aea8ebc3176380b145602d160d +# 17d1059004461097e162b6a6e8246d4a1929b51236aba55f0a09ce3f490a313c # # # -# # define position of beamline element relative to production target # -# +# # current set on magnet supply. # -# +# # current read from magnet supply. # # -# +# # voltage read from magnet supply. # # -# +# # current set on HT supply. # -# +# # current read from HT supply. # # -# +# # voltage read from HT supply. # # diff --git a/contributed_definitions/nyaml/NXserialized.yaml b/contributed_definitions/nyaml/NXserialized.yaml deleted file mode 100644 index aa897f5736..0000000000 --- a/contributed_definitions/nyaml/NXserialized.yaml +++ /dev/null @@ -1,116 +0,0 @@ -category: base -doc: | - Metadata to a set of pieces of information of a resource that has been serialized. - - A typical use case is the documentation of the source (file) or database (entry) - from which pieces of information have been extracted for consumption in e.g. a - research data management system (RDMS). This may be for reasons of enabling - services such as providing access to normalized information for which reading - again from the resource may not be desired, possibe, or feasible. - - Possible reasons could be the extraction of specific information for caching, - performance reasons, or re-evaluate given pieces of information based on other - views and interaction patterns with the data where information has been formatted - differently by tools than how these pieces of information were originally - serialized. -type: group -NXserialized(NXobject): - type(NX_CHAR): - doc: | - Answers into what resource the information was serialized. - enumeration: [file, database] - path(NX_CHAR): - doc: | - Path to the resource. - - E.g. the name of a file or its absolute or relative path, or the - identifier to a resource in another database. - checksum(NX_CHAR): - doc: | - Value of the hash that is obtained when running algorithm - on the content of the resource referred to by path. - algorithm(NX_CHAR): - doc: | - Name of the algorithm whereby the checksum was computed. - - # enumeration: [md5, sha256] - file(NXnote): - doc: | - Extracted file containing the serialized information. - -# ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 24ddd8ff040c9fd03d71f9ae59284f9645605424323617f0e3a1d35e296f2e08 -# -# -# -# -# -# Metadata to a set of pieces of information of a resource that has been serialized. -# -# A typical use case is the documentation of the source (file) or database (entry) -# from which pieces of information have been extracted for consumption in e.g. a -# research data management system (RDMS). This may be for reasons of enabling -# services such as providing access to normalized information for which reading -# again from the resource may not be desired, possibe, or feasible. -# -# Possible reasons could be the extraction of specific information for caching, -# performance reasons, or re-evaluate given pieces of information based on other -# views and interaction patterns with the data where information has been formatted -# differently by tools than how these pieces of information were originally -# serialized. -# -# -# -# Answers into what resource the information was serialized. -# -# -# -# -# -# -# -# -# Path to the resource. -# -# E.g. the name of a file or its absolute or relative path, or the -# identifier to a resource in another database. -# -# -# -# -# Value of the hash that is obtained when running algorithm -# on the content of the resource referred to by path. -# -# -# -# -# Name of the algorithm whereby the checksum was computed. -# -# -# -# -# -# Extracted file containing the serialized information. -# -# -# diff --git a/contributed_definitions/nyaml/NXsnsevent.yaml b/contributed_definitions/nyaml/NXsnsevent.yaml index 13b3c22b78..95f24719c2 100644 --- a/contributed_definitions/nyaml/NXsnsevent.yaml +++ b/contributed_definitions/nyaml/NXsnsevent.yaml @@ -7,7 +7,7 @@ type: group NXsnsevent(NXobject): (NXentry): exists: ['min', '1'] - (NXcollection)DASlogs: + DASlogs(NXcollection): doc: | Details of all logs, both from cvinfo file and from HistoTool (frequency and proton_charge). (NXlog): @@ -52,7 +52,7 @@ NXsnsevent(NXobject): dimensions: rank: 1 dim: (numvalue,) - (NXnote)SNSHistoTool: + SNSHistoTool(NXnote): SNSbanking_file_name: SNSmapping_file_name: author: @@ -95,8 +95,8 @@ NXsnsevent(NXobject): end_time(NX_DATE_TIME): entry_identifier: experiment_identifier: - (NXinstrument)instrument: - (NXsource)SNS: + instrument(NXinstrument): + SNS(NXsource): frequency(NX_FLOAT): unit: NX_FREQUENCY name: @@ -144,15 +144,15 @@ NXsnsevent(NXobject): dimensions: rank: 1 dim: (numevents,) - (NXgeometry)origin: - (NXorientation)orientation: + origin(NXgeometry): + orientation(NXorientation): value(NX_FLOAT): doc: | Six out of nine rotation parameters. dimensions: rank: 1 dim: (6,) - (NXshape)shape: + shape(NXshape): description: shape: size(NX_FLOAT): @@ -160,7 +160,7 @@ NXsnsevent(NXobject): dimensions: rank: 1 dim: (3,) - (NXtranslation)translation: + translation(NXtranslation): distance(NX_FLOAT): unit: NX_LENGTH dimensions: @@ -200,7 +200,7 @@ NXsnsevent(NXobject): exists: ['min', '0'] distance(NX_FLOAT): unit: NX_LENGTH - (NXmoderator)moderator: + moderator(NXmoderator): coupling_material: distance(NX_FLOAT): unit: NX_LENGTH @@ -210,15 +210,15 @@ NXsnsevent(NXobject): name: (NXaperture): exists: ['min', '0'] - (NXgeometry)origin: - (NXorientation)orientation: + origin(NXgeometry): + orientation(NXorientation): value(NX_FLOAT): doc: | Six out of nine rotation parameters. dimensions: rank: 1 dim: (6,) - (NXshape)shape: + shape(NXshape): description: shape: size(NX_FLOAT): @@ -226,7 +226,7 @@ NXsnsevent(NXobject): dimensions: rank: 1 dim: (3,) - (NXtranslation)translation: + translation(NXtranslation): distance(NX_FLOAT): unit: NX_LENGTH dimensions: @@ -246,21 +246,21 @@ NXsnsevent(NXobject): # motor links from DASlogs when exist (NXcrystal): exists: ['min', '0'] - (NXgeometry)origin: + origin(NXgeometry): description: - (NXorientation)orientation: + orientation(NXorientation): value(NX_FLOAT): doc: | Six out of nine rotation parameters. dimensions: rank: 1 dim: (6,) - (NXshape)shape: + shape(NXshape): description: shape: size(NX_FLOAT): unit: NX_LENGTH - (NXtranslation)translation: + translation(NXtranslation): distance(NX_FLOAT): unit: NX_LENGTH dimensions: @@ -290,7 +290,7 @@ NXsnsevent(NXobject): unit: NX_CHARGE raw_frames(NX_INT): run_number: - (NXsample)sample: + sample(NXsample): changer_position: holder: identifier: @@ -311,7 +311,7 @@ NXsnsevent(NXobject): role: # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 00e070628601de92d5e9207d251ce51659e838e99da52c5dfa8b5c64ce3f2bdb +# 5bffbcf4c45d3d0dc2aaaa98c85542d5286161d13a75272eb8b0fb82890b43de # # # -# # # -# # define position of beamline element relative to production target # -# +# # current set on magnet supply. # -# +# # current read from magnet supply. # # -# +# # voltage read from magnet supply. # # -# +# # current set on HT supply. # -# +# # current read from HT supply. # # -# +# # voltage read from HT supply. # # diff --git a/contributed_definitions/nyaml/NXspindispersion.yaml b/contributed_definitions/nyaml/NXspindispersion.yaml index e55994bd36..0b5b1dc6ee 100644 --- a/contributed_definitions/nyaml/NXspindispersion.yaml +++ b/contributed_definitions/nyaml/NXspindispersion.yaml @@ -3,7 +3,7 @@ doc: | Subclass of NXelectronanalyser to describe the spin filters in photoemission experiments. type: group -NXspindispersion(NXobject): +NXspindispersion(NXcomponent): type(NX_CHAR): doc: | Type of spin detector, VLEED, SPLEED, Mott, etc. @@ -32,20 +32,6 @@ NXspindispersion(NXobject): target_preparation_date(NX_DATE_TIME): doc: | Date of last preparation of the spin target - depends_on(NX_CHAR): - doc: | - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - (NXtransformations): - doc: | - Collection of axis-based translations and rotations to describe the location and - geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate - system is used. The first transformation has to point either to another - component of the system or . (for pointing to the reference frame) to relate it - relative to the experimental setup. Typically, the components of a system should - all be related relative to each other and only one component should relate to - the reference coordinate system. (NXdeflector): doc: | Deflectors in the spin dispersive section @@ -54,7 +40,7 @@ NXspindispersion(NXobject): Individual lenses in the spin dispersive section # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5f68e83a10b4fa836b7ab5fafa790e5d55657315050706de79f99356f2b01872 +# 7090f5dda81358f248b3a89089dac77c5625e6c594b64217910392f35fa92d20 # # # -# +# # # Subclass of NXelectronanalyser to describe the spin filters in photoemission # experiments. @@ -123,24 +109,6 @@ NXspindispersion(NXobject): # Date of last preparation of the spin target # # -# -# -# Specifies the position of the lens by pointing to the last transformation in the -# transformation chain in the NXtransformations group. -# -# -# -# -# Collection of axis-based translations and rotations to describe the location and -# geometry of the deflector as a component in the instrument. Conventions from the -# NXtransformations base class are used. In principle, the McStas coordinate -# system is used. The first transformation has to point either to another -# component of the system or . (for pointing to the reference frame) to relate it -# relative to the experimental setup. Typically, the components of a system should -# all be related relative to each other and only one component should relate to -# the reference coordinate system. -# -# # # # Deflectors in the spin dispersive section diff --git a/contributed_definitions/nyaml/NXspm.yaml b/contributed_definitions/nyaml/NXspm.yaml index 4f32a24f27..892d3edaf9 100644 --- a/contributed_definitions/nyaml/NXspm.yaml +++ b/contributed_definitions/nyaml/NXspm.yaml @@ -27,7 +27,7 @@ NXspm(NXsensor_scan): doc: | The type of the scan. It mainly describes how scan probe moves in the scan region, e.g. forward, backward, or both (if scan is repeated). - experiment_identifier(NXidentifier): + experiment_identifier: exists: optional doc: | The identifiers for the experiment which should be unique at least in lab. @@ -115,7 +115,7 @@ NXspm(NXsensor_scan): doc: | This is a link to the current_sensor under the instrument group: entry/experiment_instrument/current_sensor. - volatage_sensor(NXsensor): + voltage_sensor(NXsensor): exists: optional doc: | This is a link to the voltage_sensor under the instrument group: @@ -181,7 +181,7 @@ NXspm(NXsensor_scan): doc: | The positioner information like the position of the tip, the position of the sample, PID loop feedback etc. - z_controller(NXpid): + z_controller(NXpid_controller): doc: | The PID controller information for the z-axis. z(NX_NUMBER): @@ -196,6 +196,7 @@ NXspm(NXsensor_scan): doc: | The material description and properties of the piezoelectric scanner materials. TEMPERATURE(NXsensor): + nameType: any exists: optional doc: | A group handling the temperature such as cryo, shield and tip. For different @@ -206,6 +207,7 @@ NXspm(NXsensor_scan): doc: | The temperature of the sample. CHANNEL_temp(NX_CHAR): + nameType: partial exists: optional doc: | The name of the channel to measure the temperature. @@ -218,6 +220,7 @@ NXspm(NXsensor_scan): doc: | The coefficients of the calibration. TEMPERATURE_DATA(NXdata): + nameType: any exists: optional doc: | Data (e.g, record from SPM head temperature) from temperature sensor. @@ -232,7 +235,7 @@ NXspm(NXsensor_scan): exists: optional doc: | The positioner information like the position of the tip, PID loop feedback etc. - z_controller(NXpid): + z_controller(NXpid_controller): exists: optional doc: | The PID controller information for the z-axis. @@ -352,7 +355,7 @@ NXspm(NXsensor_scan): are used to measure the resolution of the experiment results. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# fadb9a432abce8ec46294c66adab428bad405bb9f79f5c21f906b18ed9e4a05d +# b77e4035e2b6857170f2602796d13724f9d71f4d7f7dbf2ec204b80489ff4d51 # # # # # -# Scanning Probe Microscopy (SPM) is a branch of microscopy that utilizes a physical probe to scan the surface of -# sample and image it at the atomic level. -# -# The application class NXspm is designed as a skeleton and contains common technical concepts -# for specific SPM sub-techniques such as STM, STS, AFM etc. +# Scanning Probe Microscopy (SPM) is a branch of microscopy that utilizes a physical probe to scan the surface of +# sample and image it at the atomic level. +# +# The application class NXspm is designed as a skeleton and contains common technical concepts +# for specific SPM sub-techniques such as STM, STS, AFM etc. # # # # -# Name of the definition that is used for the application. +# Name of the definition that is used for the application. # # # @@ -395,7 +398,7 @@ NXspm(NXsensor_scan): # # # -# The technique of the experiment like STM, STS, AFM, etc. +# The technique of the experiment like STM, STS, AFM, etc. # # # @@ -405,362 +408,362 @@ NXspm(NXsensor_scan): # # # -# The mode of the scan. The possible options depend on the type of experiment. -# For example, in STM, the scan mode could be constant height or constant current, -# in AFM, the scan mode could be contact mode, tapping mode or non-contact mode. +# The mode of the scan. The possible options depend on the type of experiment. +# For example, in STM, the scan mode could be constant height or constant current, +# in AFM, the scan mode could be contact mode, tapping mode or non-contact mode. # # # # -# The type of the scan. It mainly describes how scan probe moves in the scan region, e.g. -# forward, backward, or both (if scan is repeated). +# The type of the scan. It mainly describes how scan probe moves in the scan region, e.g. +# forward, backward, or both (if scan is repeated). # # -# +# # -# The identifiers for the experiment which should be unique at least in lab. +# The identifiers for the experiment which should be unique at least in lab. # -# +# # # -# The description of the experiment like comments, ontes from from the experiment. +# The description of the experiment like comments, ontes from from the experiment. # # # # -# The instrument information. +# The instrument information. # # # -# The hardware description of the core instrument setup of the experiment. -# Usually, the entire instrument is supplied by a single manufacturer. -# To describe the hardware from any sub-components, use the hardware group of that -# sub-component (child group of the NXinstrument group) group. +# The hardware description of the core instrument setup of the experiment. +# Usually, the entire instrument is supplied by a single manufacturer. +# To describe the hardware from any sub-components, use the hardware group of that +# sub-component (child group of the NXinstrument group) group. # # # -# Company name of the manufacturer. +# Company name of the manufacturer. # # # # -# Version or model of the hardware setup provided by the manufacturer. +# Version or model of the hardware setup provided by the manufacturer. # # # -# If different versions are possible, the value in this field should be made -# specific enough to resolve the version. +# If different versions are possible, the value in this field should be made +# specific enough to resolve the version. # # # # # # -# The software description of the core instrument setup of the experiment. -# Usually, the entire instrument is supplied by a single name/manufacturer/model/etc. -# To describe the software from any sub-components, use the software group of that component. +# The software description of the core instrument setup of the experiment. +# Usually, the entire instrument is supplied by a single name/manufacturer/model/etc. +# To describe the software from any sub-components, use the software group of that component. # # # -# Company name of the manufacturer. +# Company name of the manufacturer. # # # # -# Version or model of the component named by the manufacturer. +# Version or model of the component named by the manufacturer. # # # -# If different versions are possible, the value in this field should be made -# specific enough to resolve the version. +# If different versions are possible, the value in this field should be made +# specific enough to resolve the version. # # # # # # -# The real-time controller information. +# The real-time controller information. # # # -# The frequency of the real-time controller system which indicated the number of close-loop process -# (gathering data, process data and update system) control cycles per second. +# The frequency of the real-time controller system which indicated the number of close-loop process +# (gathering data, process data and update system) control cycles per second. # # # # # -# The lock-in amplifier information. +# The lock-in amplifier information. # # # # -# Information of the scan environment. +# Information of the scan environment. # # # -# Temperature of STM head. Note: At least one field from tip_temp, -# cryo_bottom_temp and cryo_shield_temp must be provided. +# Temperature of STM head. Note: At least one field from tip_temp, +# cryo_bottom_temp and cryo_shield_temp must be provided. # # # # -# Temperature of the cold tail of the cryostat. Note: At least one field from -# tip_temp, cryo_bottom_temp and cryo_shield_temp must be provided. +# Temperature of the cold tail of the cryostat. Note: At least one field from +# tip_temp, cryo_bottom_temp and cryo_shield_temp must be provided. # # # # -# Temperature of liquid nitrogen shield. Note: At -# least one field from tip_temp, cryo_bottom_temp and cryo_shield_temp. +# Temperature of liquid nitrogen shield. Note: At +# least one field from tip_temp, cryo_bottom_temp and cryo_shield_temp. # # # # -# The name of the scan, mainly lab defined, that helps to differentiate among different -# scans performed in the lab. +# The name of the scan, mainly lab defined, that helps to differentiate among different +# scans performed in the lab. # # # # -# This is a link to the current_sensor under the instrument group: -# entry/experiment_instrument/current_sensor. +# This is a link to the current_sensor under the instrument group: +# entry/experiment_instrument/current_sensor. # # -# +# # -# This is a link to the voltage_sensor under the instrument group: -# entry/experiment_instrument/voltage_sensor. +# This is a link to the voltage_sensor under the instrument group: +# entry/experiment_instrument/voltage_sensor. # # # # -# This is a link to the piezo_sensor under the instrument group: -# entry/experiment_instrument/piezo_sensor. +# This is a link to the piezo_sensor under the instrument group: +# entry/experiment_instrument/piezo_sensor. # # # # -# The scan control information like scan region or phase space, type of scan (e.g. -# mesh, spiral, etc.), and scan speed, etc. This group mainly stores the raw scan -# data. For processed data or final experimental data would go to NXdata group. +# The scan control information like scan region or phase space, type of scan (e.g. +# mesh, spiral, etc.), and scan speed, etc. This group mainly stores the raw scan +# data. For processed data or final experimental data would go to NXdata group. # # # -# The name of the scan, mainly lab defined, that helps to differentiate among different -# scans performed in lab. This field is intended for several types of scan control -# run under the same environment. +# The name of the scan, mainly lab defined, that helps to differentiate among different +# scans performed in lab. This field is intended for several types of scan control +# run under the same environment. # # # # # # -# Information for current sensor. +# Information for current sensor. # # # -# An amplifier information for the input signal (e.g. from tip). +# An amplifier information for the input signal (e.g. from tip). # # # # # -# The sensor information for the voltage device. +# The sensor information for the voltage device. # # # # # -# The piezo sensor refers to the height (or Z) piezo sensor if nothing is -# mentioned along the X and Y directions. +# The piezo sensor refers to the height (or Z) piezo sensor if nothing is +# mentioned along the X and Y directions. # # # -# The x position of the piezo. In STS experiment, the piezo stays fixed at -# x,y and z and the the tunneling current is measured with respect to the -# bias voltage (sweep voltage). +# The x position of the piezo. In STS experiment, the piezo stays fixed at +# x,y and z and the the tunneling current is measured with respect to the +# bias voltage (sweep voltage). # # # # -# The y position of the piezo. +# The y position of the piezo. # # # # -# The z position of the piezo. +# The z position of the piezo. # # # # -# The piezo configuration information like piezoelectric calibration and material -# properties. +# The piezo configuration information like piezoelectric calibration and material +# properties. # # # -# Calibration of the piezo device. +# Calibration of the piezo device. # # # # # -# The positioner information like the position of the tip, the position of the -# sample, PID loop feedback etc. +# The positioner information like the position of the tip, the position of the +# sample, PID loop feedback etc. # -# +# # -# The PID controller information for the z-axis. +# The PID controller information for the z-axis. # # # -# To indicate the relative tip position z between tip and sample. The tip position -# can also be varied when the z_controller is not running. +# To indicate the relative tip position z between tip and sample. The tip position +# can also be varied when the z_controller is not running. # # # # -# Status if controller is active. +# Status if controller is active. # # # # # # -# The material description and properties of the piezoelectric scanner materials. +# The material description and properties of the piezoelectric scanner materials. # # # -# +# # -# A group handling the temperature such as cryo, shield and tip. For different -# type of temperature sensors repeat this group. +# A group handling the temperature such as cryo, shield and tip. For different +# type of temperature sensors repeat this group. # # # -# The temperature of the sample. +# The temperature of the sample. # # -# +# # -# The name of the channel to measure the temperature. +# The name of the channel to measure the temperature. # # # # -# Calibration of the temperature measurement. +# Calibration of the temperature measurement. # # # -# The coefficients of the calibration. +# The coefficients of the calibration. # # # -# +# # -# Data (e.g, record from SPM head temperature) from temperature sensor. +# Data (e.g, record from SPM head temperature) from temperature sensor. # # # # # -# To explain bias (sweep measurement) voltage applied to the sample. +# To explain bias (sweep measurement) voltage applied to the sample. # # # -# Setup and scan data for continuous measurement of bias-voltage on the subject of experiment -# vs tunneling current from probe. +# Setup and scan data for continuous measurement of bias-voltage on the subject of experiment +# vs tunneling current from probe. # # # -# The positioner information like the position of the tip, PID loop feedback etc. +# The positioner information like the position of the tip, PID loop feedback etc. # -# +# # -# The PID controller information for the z-axis. +# The PID controller information for the z-axis. # # # -# The average time taken by the z-controller to stabilize the tip. +# The average time taken by the z-controller to stabilize the tip. # # # # -# The time taken by the z-controller to measure physical properties. +# The time taken by the z-controller to measure physical properties. # # # # -# The status of the controller to be held on the previous position, before going to the -# next scan point or line to measure the physical properties. +# The status of the controller to be held on the previous position, before going to the +# next scan point or line to measure the physical properties. # # # # -# The status of the controller to record the final z position after the scan. +# The status of the controller to record the final z position after the scan. # # # # # # -# The bais voltage sweep is a common technique used on the substance or sample or environment -# to study the change in the behavior of the sample or substance or environment due to change -# in applied bias voltage. +# The bais voltage sweep is a common technique used on the substance or sample or environment +# to study the change in the behavior of the sample or substance or environment due to change +# in applied bias voltage. # # # -# The time is taken to settle the bias voltage at the desired value. On each sweep usually, the system -# takes time to settle the bias voltage at the next value. +# The time is taken to settle the bias voltage at the desired value. On each sweep usually, the system +# takes time to settle the bias voltage at the next value. # # # # -# The scan region (phase space or sub-phase space) is the region where the scan is -# performed. +# The scan region (phase space or sub-phase space) is the region where the scan is +# performed. # # # -# The offset of the bias voltage for bias sweep. +# The offset of the bias voltage for bias sweep. # # # # -# The range of the scan is the length of the bias voltage over which the sweep -# scan will be performed. +# The range of the scan is the length of the bias voltage over which the sweep +# scan will be performed. # # # # -# The start of the bias scan voltage. +# The start of the bias scan voltage. # # # # -# The end of the bias scan voltage. +# The end of the bias scan voltage. # # # # # -# The linear sweep is a type of scan where the bias voltage is swept -# linearly from the starting voltage to the ending voltage. +# The linear sweep is a type of scan where the bias voltage is swept +# linearly from the starting voltage to the ending voltage. # # # -# The number of voltage points the sweep scan to be performed. +# The number of voltage points the sweep scan to be performed. # # # # -# The step size of the sweep. -# The step size is the difference between the two consecutive bias voltage during the sweep. +# The step size of the sweep. +# The step size is the difference between the two consecutive bias voltage during the sweep. # # # # -# The reset_bias is used to reset the bias voltage to the starting value after a -# sweep is completed. +# The reset_bias is used to reset the bias voltage to the starting value after a +# sweep is completed. # # # @@ -769,25 +772,25 @@ NXspm(NXsensor_scan): # # # -# The DC bias voltage that is applied to the sample. +# The DC bias voltage that is applied to the sample. # # # -# The bias voltage (DC) applied to the sample. +# The bias voltage (DC) applied to the sample. # # # # -# Offset value of the bias voltage. +# Offset value of the bias voltage. # # # # -# Calibration of the bias voltage measurement (V/V). +# Calibration of the bias voltage measurement (V/V). # # # -# The coefficients of the calibration. +# The coefficients of the calibration. # # # @@ -795,34 +798,34 @@ NXspm(NXsensor_scan): # # # -# The sample information. +# The sample information. # # # -# A set of physical processes that occurred to the sample prior/during experiment. +# A set of physical processes that occurred to the sample prior/during experiment. # # # # -# Information of environment around the sample. +# Information of environment around the sample. # # # -# Link to the sample_bias_voltage sensor under the instrument. +# Link to the sample_bias_voltage sensor under the instrument. # # # # # # -# The group of indicators (links to the existing fields in different groups) that measure -# the reproducibility of the experiment. +# The group of indicators (links to the existing fields in different groups) that measure +# the reproducibility of the experiment. # # # # -# The group of indicators (links to the existing fields in different groups) that -# are used to measure the resolution of the experiment results. +# The group of indicators (links to the existing fields in different groups) that +# are used to measure the resolution of the experiment results. # # # diff --git a/contributed_definitions/nyaml/NXstage_lab.yaml b/contributed_definitions/nyaml/NXstage_lab.yaml index c402930e7a..88d1b2945a 100644 --- a/contributed_definitions/nyaml/NXstage_lab.yaml +++ b/contributed_definitions/nyaml/NXstage_lab.yaml @@ -167,7 +167,7 @@ NXstage_lab(NXcomponent): # # # # For further information, see http://www.nexusformat.org # --> -# +# # # Base class for a stage (lab) used to hold, orient, and prepare a specimen. # diff --git a/contributed_definitions/nyaml/NXstm.yaml b/contributed_definitions/nyaml/NXstm.yaml index ebbf62e0ae..a00f5988b0 100644 --- a/contributed_definitions/nyaml/NXstm.yaml +++ b/contributed_definitions/nyaml/NXstm.yaml @@ -125,7 +125,8 @@ NXstm(NXspm): exists: optional doc: | Calibration of the piezo device. - 2nd_order_correction_N(NX_NUMBER): + second_order_correction_N(NX_NUMBER): + nameType: partial exists: optional unit: NX_ANY doc: | @@ -142,12 +143,14 @@ NXstm(NXspm): The name of the calibration type, sometimes it is called e.g active calibration, passive calibration. calibration_coefficient_N(NX_NUMBER): + nameType: partial exists: optional unit: NX_ANY doc: | The calibration coefficient is the ratio of the actual distance moved by the piezo to the voltage applied to the piezo. It is also called first-order correction. drift_N(NX_NUMBER): + nameType: partial exists: optional unit: NX_ANY doc: | @@ -158,12 +161,14 @@ NXstm(NXspm): Whether the drift has been corrected in case there is a deviation in the drift. tilt_N(NX_NUMBER): + nameType: partial exists: optional unit: NX_ANGLE doc: | The N (substring) denotes X and Y directions, and for both directions tilt needs to be adjusted according to the actual surface. hv_gain_N(NX_NUMBER): + nameType: partial doc: | The N (substring) denotes X or Y or Z. In some systems, there is an HV gain readout feature. For these systems, @@ -173,7 +178,7 @@ NXstm(NXspm): doc: | The positioner information like the position of the tip, PID loop feedback etc. - z_controller(NXpid): + z_controller(NXpid_controller): doc: | The PID controller information for the z-axis. z(NX_NUMBER): @@ -276,7 +281,7 @@ NXstm(NXspm): link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d4f102d19440e68b55d6c23aeb6a8daa8d3a053a5fb7fe566d3d0a80aaa1a96f +# c7e6f44a0fb8e385d24877045089e95c5beb9d6fbd8d133ffc4fe10e686a29bb # # # # # -# An application definition to describe Scanning Tunneling Microscopy (STM). +# An application definition to describe Scanning Tunneling Microscopy (STM). # # # # -# Name of the definition that is used for the application. +# Name of the definition that is used for the application. # # # @@ -318,8 +323,8 @@ NXstm(NXspm): # # # -# The mode of the scan that is performed. Two commonly used ones are constant -# height mode and constant current mode. +# The mode of the scan that is performed. Two commonly used ones are constant +# height mode and constant current mode. # # # @@ -328,39 +333,39 @@ NXstm(NXspm): # # # -# The group explains the instrumentation of the STM experiment such -# as current sensor, lock-in amplifier etc. +# The group explains the instrumentation of the STM experiment such +# as current sensor, lock-in amplifier etc. # # # -# The lock-in amplifier information. The device is being used to extract -# the very weak signal buried in noisy signals. +# The lock-in amplifier information. The device is being used to extract +# the very weak signal buried in noisy signals. # # # -# The type of the signal (voltage or current) subject fo modulation. +# The type of the signal (voltage or current) subject fo modulation. # # # # -# The frequency of the sine modulation that is used to modulate the signal in -# lock-in. +# The frequency of the sine modulation that is used to modulate the signal in +# lock-in. # # # # # -# The environment information for stm or sts experiment. +# The environment information for stm or sts experiment. # # # -# The scan control information like scan region or phase space, type of scan -# (e.g. mesh, spiral, etc.), and scan speed, etc. +# The scan control information like scan region or phase space, type of scan +# (e.g. mesh, spiral, etc.), and scan speed, etc. # # # -# The type of scan like mesh, spiral, etc. For STS experiment, the scan type is -# usually a single-point scan (trajectory scan). +# The type of scan like mesh, spiral, etc. For STS experiment, the scan type is +# usually a single-point scan (trajectory scan). # # # @@ -372,189 +377,189 @@ NXstm(NXspm): # # # -# This group stands for the same concept as -# /ENTRY[entry]/experiment_instrument/tip_temperature +# This group stands for the same concept as +# /ENTRY[entry]/experiment_instrument/tip_temperature # # # # -# This group stands for the same concept as -# /ENTRY[entry]/experiment_instrument/cryo_temperature +# This group stands for the same concept as +# /ENTRY[entry]/experiment_instrument/cryo_temperature # # # # -# This group stands for the same concept as -# /ENTRY[entry]/experiment_instrument/cryo_shield_temperature +# This group stands for the same concept as +# /ENTRY[entry]/experiment_instrument/cryo_shield_temperature # # # # # -# The temperature of the tip one of the tip. +# The temperature of the tip one of the tip. # # # # -# The temperature of the cryostat. +# The temperature of the cryostat. # # # # -# The temperature of the cryo shield. +# The temperature of the cryo shield. # # # # -# The sensor information. +# The sensor information. # # # -# The tunneling current between tip and sample after -# applying bias voltage. +# The tunneling current between tip and sample after +# applying bias voltage. # # # # -# Offset value of the current measurement. +# Offset value of the current measurement. # # # # -# Calibration of the current measurement. +# Calibration of the current measurement. # # # -# The coefficients of the calibration. +# The coefficients of the calibration. # # # # # -# An amplifier information for the input signal (e.g. from tip). +# An amplifier information for the input signal (e.g. from tip). # # # -# Proportional relationship between the probe output voltage and the actual -# tunneling current when measuring the tunneling current. +# Proportional relationship between the probe output voltage and the actual +# tunneling current when measuring the tunneling current. # # # # # # -# To explain bias (sweep measurement) voltage applied to the sample. +# To explain bias (sweep measurement) voltage applied to the sample. # # # -# Setup and scan data for continuous measurement of bias-voltage on the subject of experiment -# vs tunneling current from probe. -# Data from from this experiment can also be used to calculate the dI/dV spectra. +# Setup and scan data for continuous measurement of bias-voltage on the subject of experiment +# vs tunneling current from probe. +# Data from from this experiment can also be used to calculate the dI/dV spectra. # # # # # -# The sensor information for the piezo device. +# The sensor information for the piezo device. # # # -# The piezo configuration information like piezoelectric device calibration and -# material properties. +# The piezo configuration information like piezoelectric device calibration and +# material properties. # # # -# Calibration of the piezo device. +# Calibration of the piezo device. # -# +# # -# The N (substring) denotes X and Y directions. The 2nd order piezo -# compensate the error for that axis. The following equation shows the -# interpretation of the 2nd order correction parameters, -# For the X-piezo: "Ux = 1/cx · X + cxx · X2" -# with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" -# where cx is the calibration of the piezo X and cxx is the 2nd order -# correction. The unit for such the second-order correction is (V/m^2). +# The N (substring) denotes X and Y directions. The 2nd order piezo +# compensate the error for that axis. The following equation shows the +# interpretation of the 2nd order correction parameters, +# For the X-piezo: "Ux = 1/cx · X + cxx · X2" +# with units: "[V] = [V/m] · [m] + [V/m2] · [m2]" +# where cx is the calibration of the piezo X and cxx is the 2nd order +# correction. The unit for such the second-order correction is (V/m^2). # # # # -# The name of the calibration type, sometimes it is called -# e.g active calibration, passive calibration. +# The name of the calibration type, sometimes it is called +# e.g active calibration, passive calibration. # # -# +# # -# The calibration coefficient is the ratio of the actual distance moved by the piezo to -# the voltage applied to the piezo. It is also called first-order correction. +# The calibration coefficient is the ratio of the actual distance moved by the piezo to +# the voltage applied to the piezo. It is also called first-order correction. # # -# +# # -# Set up the settings to enable or disable the drift compensation. +# Set up the settings to enable or disable the drift compensation. # # # # -# Whether the drift has been corrected in case there is a deviation in the -# drift. +# Whether the drift has been corrected in case there is a deviation in the +# drift. # # -# +# # -# The N (substring) denotes X and Y directions, and for both directions -# tilt needs to be adjusted according to the actual surface. +# The N (substring) denotes X and Y directions, and for both directions +# tilt needs to be adjusted according to the actual surface. # # -# +# # -# The N (substring) denotes X or Y or Z. In some systems, -# there is an HV gain readout feature. For these systems, -# the HV gain should be automatically adjusted whenever -# the gain is changed at the high voltage amplifier. +# The N (substring) denotes X or Y or Z. In some systems, +# there is an HV gain readout feature. For these systems, +# the HV gain should be automatically adjusted whenever +# the gain is changed at the high voltage amplifier. # # # # # # -# The positioner information like the position of the tip, -# PID loop feedback etc. +# The positioner information like the position of the tip, +# PID loop feedback etc. # -# +# # -# The PID controller information for the z-axis. +# The PID controller information for the z-axis. # # # -# To indicate the relative tip position z between tip and sample. The tip position -# can also be varied when the z_controller is not running. +# To indicate the relative tip position z between tip and sample. The tip position +# can also be varied when the z_controller is not running. # # # # -# The set point for the z-controller to be fixed and the target value could be -# height or current. +# The set point for the z-controller to be fixed and the target value could be +# height or current. # # # # -# The name of the controller or channels. +# The name of the controller or channels. # # # # -# The status of the controller to say was PID has been used or not. +# The status of the controller to say was PID has been used or not. # # # # -# If the tip is lifted from the stable point. +# If the tip is lifted from the stable point. # # # # -# The switch-off delay of the controller from its stable point. +# The switch-off delay of the controller from its stable point. # # # @@ -563,86 +568,86 @@ NXstm(NXspm): # # # -# The group's concepts hold the link to the related concepts that define the -# reproducibility of the STM experiment. +# The group's concepts hold the link to the related concepts that define the +# reproducibility of the STM experiment. # # # -# The tunneling current between tip and sample after application of bias voltage. -# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current +# The tunneling current between tip and sample after application of bias voltage. +# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current # # # # -# The tunneling current between tip and sample after application of bias voltage. -# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current +# The tunneling current between tip and sample after application of bias voltage. +# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/current # # # # -# Proportional relationship between the probe output voltage and the actual -# tunneling current when measuring the tunneling current. -# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/amplifier/current_gain +# Proportional relationship between the probe output voltage and the actual +# tunneling current when measuring the tunneling current. +# link to the target: /ENTRY[entry]/experiment_instrument/current_sensor/amplifier/current_gain # # # # -# Link to target: -# /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] +# Link to target: +# /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] # # # # -# This is the signal on which the modulation voltage or current will be added. -# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type +# This is the signal on which the modulation voltage or current will be added. +# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type # # # # -# The frequency of the sine modulation that is used to modulate the signal in lock-in. -# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency +# The frequency of the sine modulation that is used to modulate the signal in lock-in. +# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency # # # # # -# The group's concepts hold the link to the related concepts that define the -# resolution of the STM experiment. +# The group's concepts hold the link to the related concepts that define the +# resolution of the STM experiment. # # # -# Link to target: /ENTRY[entry]/experiment_instrument/scan_environment/tip_temp +# Link to target: /ENTRY[entry]/experiment_instrument/scan_environment/tip_temp # # # # -# Link to target: -# /ENTRY[entry]/experiment_instrument/scan_environment/cryo_bottom_temp +# Link to target: +# /ENTRY[entry]/experiment_instrument/scan_environment/cryo_bottom_temp # # # # -# Link to target: -# /ENTRY[entry]/experiment_instrument/scan_environment/cryo_shield_temperature +# Link to target: +# /ENTRY[entry]/experiment_instrument/scan_environment/cryo_shield_temperature # # # # -# Link to target: -# /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] +# Link to target: +# /ENTRY[entry]/experiment_instrument/bias_spectroscopy_environment/BIAS_SPECTROSCOPY[bias_spectroscopy]/BIAS_SWEEP[bias_sweep] # # # # -# This is the signal on which the modulation voltage or current will be added. -# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type -# modulation_signal_type +# This is the signal on which the modulation voltage or current will be added. +# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_signal_type +# modulation_signal_type # # # # -# The frequency of the sine modulation that is used to modulate the signal in lock-in. -# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency +# The frequency of the sine modulation that is used to modulate the signal in lock-in. +# link to the target: /ENTRY[entry]/experiment_instrument/lockin_amplifier/modulation_frequency # # # diff --git a/contributed_definitions/nyaml/NXsubstance.yaml b/contributed_definitions/nyaml/NXsubstance.yaml index d5b6495d49..199ae9cec4 100644 --- a/contributed_definitions/nyaml/NXsubstance.yaml +++ b/contributed_definitions/nyaml/NXsubstance.yaml @@ -13,65 +13,78 @@ NXsubstance(NXobject): unit: NX_MOLECULAR_WEIGHT doc: | Molecular mass of the substance - cas_number: - doc: | - Unique numeric CAS REGISTRY number of the sample chemical content - For further information, see https://www.cas.org/. - cas_name: + molecular_formula_hill: doc: | - CAS REGISTRY name of the sample chemical content - cas_uri: + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + identifier_cas: doc: | - CAS REGISTRY URI + Unique CAS REGISTRY URI. + For further information, see https://www.cas.org/. + \@type: + enumeration: [URL] + \@cas_number: + doc: | + Numeric CAS REGISTRY number associated with this identifier. + \@cas_name: + doc: | + CAS REGISTRY name associated with this identifier. cas_image(NXnote): doc: | CAS REGISTRY image - cas_synonyms: - doc: | - Synonyms in the CAS system. - inchi_str: + identifier_inchi_str: doc: | - String InChi identifier. + Standard string InChi identifier" (as per v1.02). + The InChI identifier expresses chemical structures in terms of atomic connectivity, tautomeric state, isotopes, stereochemistry and electronic charge in order to produce a string of machine-readable characters unique to the respective molecule. For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. - inchi_key: + identifier_inchi_key: doc: | Condensed, 27 character InChI key. Hashed version of the full InChI (using the SHA-256 algorithm). - iupac_name: + identifier_iupac_name: doc: | Name according to the IUPAC system (standard). For further information, see https://iupac.org/. - smile: + identifier_smiles: doc: | Identifier in the SMILES (Simplified Molecular Input Line Entry System) system For further information, see https://www.daylight.com/smiles/. - canonical_smile: + identifier_canonical_smiles: doc: | - Canonical version of the smiles identifier - molecular_formula_hill: + Canonical version of the SMILES identifier + identifier_pub_chem: doc: | - The chemical formula specified using CIF conventions. - Abbreviated version of CIF standard:107 - This is the *Hill* system used by Chemical Abstracts. + Standard PubChem identifier (CID). - * Only recognized element symbols may be used. - * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. - * A space or parenthesis must separate each cluster of (element symbol + count). - * Where a group of elements is enclosed in parentheses, the multiplier for the - group must follow the closing parentheses. That is, all element and group - multipliers are assumed to be printed as subscripted numbers. - * Unless the elements are ordered in a manner that corresponds to their chemical - structure, the order of the elements within any group or moiety depends on - whether or not carbon is present. - * If carbon is present, the order should be: - - C, then H, then the other elements in alphabetical order of their symbol. - - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + The PubChem Compound Identifier (CID) is a unique numerical identifier assigned to + a compound in the PubChem database, which contains information on the biological activities + of small molecules. The CID allows users to access detailed data about compounds, including + their chemical structure, molecular formula, and biological properties. + + For further information, see https://pubchem.ncbi.nlm.nih.gov/. + \@pub_chem_link: + doc: | + CAS REGISTRY name associated with this identifier. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# edfde06a5e9cb004cef553235a02e7a35aac1e9609544c7238f3cffdc3664760 +# b9cfdb88e2cfb39c66f67097a6c63ed36255bf6ae6f1e69ba61bd47e4c1d2dda # # # # -# +# # # # -# Size of the wavelength array for which the refractive index of the material -# and/or coating is given. +# Size of the wavelength array for which the refractive index of the material +# and/or coating is given. # # # # -# Number of discrete wavelengths for which the waveplate is designed. If it -# operates for a range of wavelengths then N_wavelengths = 2 and the minimum -# and maximum values of the range should be provided. +# Number of discrete wavelengths for which the waveplate is designed. If it +# operates for a range of wavelengths then N_wavelengths = 2 and the minimum +# and maximum values of the range should be provided. # # # # -# A waveplate or retarder. +# A waveplate or retarder. # # # -# Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). +# Type of waveplate (e.g. achromatic waveplate or zero-order waveplate). # # @@ -175,13 +175,13 @@ NXwaveplate(NXobject): # # # -# If you selected 'other' in type describe what it is. +# If you selected 'other' in type describe what it is. # # # # -# Specify the retardance of the waveplate (e.g. full-wave, half-wave -# (lambda/2), quarter-wave (lambda/4) plate). +# Specify the retardance of the waveplate (e.g. full-wave, half-wave +# (lambda/2), quarter-wave (lambda/4) plate). # # # @@ -191,10 +191,10 @@ NXwaveplate(NXobject): # # # -# Discrete wavelengths for which the waveplate is designed. If the -# waveplate operates over an entire range of wavelengths, enter the minimum -# and maximum values of the wavelength range (in this case -# N_wavelengths = 2). +# Discrete wavelengths for which the waveplate is designed. If the +# waveplate operates over an entire range of wavelengths, enter the minimum +# and maximum values of the wavelength range (in this case +# N_wavelengths = 2). # # # @@ -202,42 +202,42 @@ NXwaveplate(NXobject): # # # -# Wavelength resolved retardence of the waveplate. +# Wavelength resolved retardance of the waveplate. # # # # -# Diameter of the waveplate. +# Diameter of the waveplate. # # # # -# Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of -# length/height for square geometry). +# Clear aperture of the device (e.g. 90% of diameter for a disc or 90% of +# length/height for square geometry). # # # # # -# Describe the material of the substrate of the wave plate in -# substrate/substrate_material and provide its index of refraction in -# substrate/index_of_refraction_substrate, if known. +# Describe the material of the substrate of the wave plate in +# substrate/substrate_material and provide its index of refraction in +# substrate/index_of_refraction_substrate, if known. # # # -# Specify the material of the wave plate. If the device has a -# coating it should be described in coating/coating_material. +# Specify the material of the wave plate. If the device has a +# coating it should be described in coating/coating_material. # # # # -# Thickness of the wave plate substrate. +# Thickness of the wave plate substrate. # # # # -# Complex index of refraction of the wave plate substrate. Specify at -# given wavelength (or energy, wavenumber etc.) values. +# Complex index of refraction of the wave plate substrate. Specify at +# given wavelength (or energy, wavenumber etc.) values. # # # @@ -247,30 +247,30 @@ NXwaveplate(NXobject): # # # -# Is the wave plate coated? If yes, specify the type and material of the -# coating and the wavelength range for which it is designed. If known, you -# may also provide its index of refraction. +# Is the wave plate coated? If yes, specify the type and material of the +# coating and the wavelength range for which it is designed. If known, you +# may also provide its index of refraction. # # # -# Specify the coating type (e.g. dielectric, anti-reflection (AR), -# multilayer coating etc.). +# Specify the coating type (e.g. dielectric, anti-reflection (AR), +# multilayer coating etc.). # # # # -# Specify the coating material. +# Specify the coating material. # # # # -# Thickness of the coating. +# Thickness of the coating. # # # # -# Wavelength range for which the coating is designed. Enter the minimum -# and maximum values of the wavelength range. +# Wavelength range for which the coating is designed. Enter the minimum +# and maximum values of the wavelength range. # # # @@ -278,8 +278,8 @@ NXwaveplate(NXobject): # # # -# Complex index of refraction of the coating. Specify at given spectral -# values (wavelength, energy, wavenumber etc.). +# Complex index of refraction of the coating. Specify at given spectral +# values (wavelength, energy, wavenumber etc.). # # # @@ -289,7 +289,7 @@ NXwaveplate(NXobject): # # # -# Average reflectance of the waveplate in percentage. +# Average reflectance of the waveplate in percentage. # # # diff --git a/contributed_definitions/nyaml/NXxpcs.yaml b/contributed_definitions/nyaml/NXxpcs.yaml index abe8be8433..57a6946f57 100644 --- a/contributed_definitions/nyaml/NXxpcs.yaml +++ b/contributed_definitions/nyaml/NXxpcs.yaml @@ -17,7 +17,7 @@ symbols: Number of points type: group NXxpcs(NXobject): - (NXentry)entry: + (NXentry): definition: doc: | Official NeXus NXDL schema to which this file conforms @@ -57,7 +57,7 @@ NXxpcs(NXobject): exists: ['min', '0', 'max', '1'] doc: | Ending time of experiment, such as "2021-02-11 11:23:45Z". - (NXdata)data: + data(NXdata): doc: | The results data captured here are most commonly required for high throughput, equilibrium dynamics experiments. Data (results) describing on-equilibrium dynamics consume more memory resources so these data are separated. @@ -146,7 +146,7 @@ NXxpcs(NXobject): refer to :ref:`NXdetector` for conversion to time units. \@storage_mode(NX_CHAR): enumeration: [one_array, data_exchange_keys, other] - (NXdata)twotime: + twotime(NXdata): exists: ['min', '0'] doc: | The data (results) in this section are based on the two-time intensity correlation function derived from a time series of scattering images. @@ -265,13 +265,13 @@ NXxpcs(NXobject): The derivation of the error is left up to the implemented code. Symmetric error will be expected (:math:`\pm` error). - (NXinstrument)instrument: + instrument(NXinstrument): doc: | XPCS instrument Metadata. Objects can be entered here directly or linked from other objects in the NeXus file (such as within ``/entry/instrument``). - (NXbeam)incident_beam: + incident_beam(NXbeam): incident_energy(NX_FLOAT): unit: NX_ENERGY doc: | @@ -352,7 +352,7 @@ NXxpcs(NXobject): exists: ['min', '0', 'max', '1'] doc: | Length of pixel in y direction. - (NXnote)masks: + masks(NXnote): exists: ['min', '0', 'max', '1'] doc: | Data masks or mappings to regions of interest (roi) for specific :math:`Q` values @@ -423,7 +423,7 @@ NXxpcs(NXobject): exists: ['min', '0'] doc: | 1-D list of :math:`|Q|` values, 1 for each roi. - (NXsample)sample: + sample(NXsample): exists: ['min', '0'] # Describes the minimum requirements regarding equilibrium sample conditions. NXsample @@ -442,13 +442,13 @@ NXxpcs(NXobject): exists: ['min', '0'] doc: | Sample temperature actual, (C or K). - (NXpositioner)position_x: + position_x(NXpositioner): exists: ['min', '0'] - (NXpositioner)position_y: + position_y(NXpositioner): exists: ['min', '0'] - (NXpositioner)position_z: + position_z(NXpositioner): exists: ['min', '0'] - (NXnote)NOTE: + NOTE(NXnote): exists: ['min', '0', 'max', 'unbounded'] doc: | Any other notes. @@ -464,13 +464,13 @@ NXxpcs(NXobject): Describe the computation process that produced these results. # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# d01f4a9d3b63fef1b2b07d373760acc10504f370c66a87beece059e6c9eda89a +# 5a1c4536e3269a7940f6e21f19dc3c40b169637204909ca497d5f67ba24f2682 # # # + + + + + + This interprets the ``name`` attribute as: + + * ``"specified"`` = Exactly this name. + Note that if no ``name`` and ``nameType`` are provided + for a group, ``nameType="any"`` becomes the default. + * ``"any"`` = Any name not already used in group. + * ``"partial"`` = The capital letters are substitutable + (empty string allowed) and the lower case letters + (and other allowed symbols, such as ``_``) are not. + + In each case, all names in a NeXus data file must + follow the naming :ref:`rules<Design-Naming>`. + + + + + + + + + + + + @@ -486,6 +517,7 @@ + @@ -660,9 +692,25 @@ String describing the engineering units. - The string should be appropriate for the value - and should conform to the NeXus rules for units. + The string should be appropriate for the value. + + * If a unit is not provided by the list of NeXus + unit categories, instead of providing a category, + a field element can include an example of the + units directly. + + * The example does not constrain the scale of the + units. For example, if the unit is ``eV/mm``, the + user could specify in a data file ``eV/cm``, or any + other unit that is convertible to the example given. + + It is recommended that users and application developers + check if their units and their unit examples adhere to + the UDUNITS standard. [#]_ + Conformance is not validated at this time. + + .. [#] https://www.unidata.ucar.edu/software/udunits/ @@ -913,21 +961,7 @@ - - - - This interprets the name attribute as: - * ``specified`` = use as specified - * ``any`` = can be any name not already used in group - - - - - - - - - + @@ -1006,6 +1040,7 @@ + @@ -1197,7 +1232,7 @@ (This data type is used internally in the NXDL schema to define elements and attributes to be used by users in NXDL specifications.) - + :: @@ -1209,6 +1244,20 @@ + Enumerations can be closed or open. A closed enumeration is one where the list of + values are the only ones allowed for a specification. An open enumeration is one + where the list of values is incomplete and additional values other than those listed + are allowed. Open enumerations should be used sparingly as the designer of the enumeration + should try to find all possible values for a given field/attribute. + + In case an open enumeration is used and the data provider wants to declare that the provided + value deliberately not from the given list of values, the data provider should, + + * for fields, set the attribute ``@custom=True``. + * for attributes, set an additional attribute ``@my_attribute_custom=True``, where + ``my_attribute`` is the name of the attribute with the open enumeration. + + Such attributes can be used deliberately to suppress warnings in NeXus validators. @@ -1244,6 +1293,14 @@ + + + + Is this an open enumeration? + An open enumeration allows additional values not listed. + + + diff --git a/nxdlTypes.xsd b/nxdlTypes.xsd index 8811142b90..b9c972571d 100644 --- a/nxdlTypes.xsd +++ b/nxdlTypes.xsd @@ -10,7 +10,7 @@ .. 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 @@ -44,6 +44,7 @@ They should describe valid units consistent with the manual section on NeXus units (based on UDUNITS). + Units are not validated by NeXus. @@ -81,6 +82,7 @@ nxdl:NX_VOLUME nxdl:NX_WAVELENGTH nxdl:NX_WAVENUMBER + xs:string " /> @@ -466,18 +468,14 @@ nxdl:NX_POSINT nxdl:NX_QUATERNION nxdl:NX_UINT + nxdl:NX_CHAR_OR_NUMBER "/> - The preferred string representation is :index:`UTF-8`. - Both fixed-length strings and variable-length strings are valid. - String arrays cannot be used where only a string is expected - (title, start_time, end_time, ``NX_class`` attribute,...). - Fields or attributes requiring the use of string arrays will be - clearly marked as such (like the ``NXdata`` attribute ``auxiliary_signals``). + A string of characters. The preferred string encoding is :index:`UTF-8`. This is the default field type. @@ -619,4 +617,14 @@ + + + Any valid character string or NeXus number representation + + + + diff --git a/package/README.txt b/package/README.txt deleted file mode 100644 index 8719003a9a..0000000000 --- a/package/README.txt +++ /dev/null @@ -1,5 +0,0 @@ -README for installer GUI ------------------------- - -Unless specified otherwise, files will be installed in a default location root -such as /usr/share/nexus/ or /usr/local/share/nexus/ diff --git a/package/WELCOME.txt b/package/WELCOME.txt deleted file mode 100644 index 957339d8ff..0000000000 --- a/package/WELCOME.txt +++ /dev/null @@ -1,3 +0,0 @@ -Welcome to the NeXus definitions and documentation installer. - -For more details on NeXus see http://www.nexusformat.org/ diff --git a/package/description.txt b/package/description.txt deleted file mode 100644 index 01d90c9008..0000000000 --- a/package/description.txt +++ /dev/null @@ -1,13 +0,0 @@ -NeXus: A common data format for neutron, X-ray and muon science. - - http://www.nexusformat.org/ - -NeXus is developed as an international standard by scientists -and programmers representing major scientific facilities in -Europe, Asia, Australia, and North America in order to facilitate -greater cooperation in the analysis and visualization of neutron, -X-ray, and muon data. - -This installer package contains: -* NeXus base class and instrument definitions in NXDL format -* NeXus documentation and examples, such as the user and reference manuals diff --git a/package/nexus.ico b/package/nexus.ico deleted file mode 100644 index 28b3098798..0000000000 Binary files a/package/nexus.ico and /dev/null differ diff --git a/requirements.txt b/requirements.txt index 16fb73372c..0b24e6cf91 100644 --- a/requirements.txt +++ b/requirements.txt @@ -1,13 +1,14 @@ # Prepare for Documentation lxml>=4.9.1 pyyaml -nyaml==0.2.0 +nyaml==0.2.1 # Documentation building sphinx>=5 sphinx-tabs sphinx-toolbox sphinx_comments +chios # Testing pytest diff --git a/utils/create_release_notes.py b/utils/create_release_notes.py index 77a4d2c3b6..26ea3fc747 100755 --- a/utils/create_release_notes.py +++ b/utils/create_release_notes.py @@ -95,19 +95,23 @@ def get_release_info(token, base_tag_name, head_branch_name, milestone_name): logger.debug(f"repo: {repo}") # fmt: off - milestones = [ + all_milestones = tuple(repo.get_milestones(state="all")) + matching_milestones = tuple( m - for m in repo.get_milestones(state="all") + for m in all_milestones if m.title == milestone_name - ] + ) # fmt: on - if len(milestones) == 0: - msg = f"Could not find milestone: {milestone_name}" + if len(matching_milestones) == 0: + msg = f"Could not find milestone to match '{milestone_name}':" + for m in all_milestones: + msg += f"\n\t{m.title}" logger.error(msg) raise ValueError(msg) - milestone = milestones[0] + milestone = matching_milestones[0] logger.debug(f"milestone: {milestone}") + logger.debug(f"compare: {base_tag_name} -> {head_branch_name}") compare = repo.compare(base_tag_name, head_branch_name) logger.debug(f"compare: {compare}") @@ -124,9 +128,10 @@ def get_release_info(token, base_tag_name, head_branch_name, milestone_name): # t.commit == commit # t.commit.last_modified != commit.last_modified commit = repo.get_commit(t.commit.sha) - dt = str2time(commit.last_modified) + dt = commit.last_modified_datetime earliest = min(dt, earliest or dt) - logger.debug(f"# tags: {len(tags)}") + + logger.debug(f"# tags: {len(tags)} {earliest}") # fmt: off pulls = { @@ -191,18 +196,6 @@ def parse_command_line(): return parser.parse_args() -def str2time(time_string): - """convert date/time string to datetime object - - input string example: ``Tue, 20 Dec 2016 17:35:40 GMT`` - """ - if time_string is None: - msg = f"need valid date/time string, not: {time_string}" - logger.error(msg) - raise ValueError(msg) - return datetime.datetime.strptime(time_string, "%a, %d %b %Y %H:%M:%S %Z") - - def report(title, repo, milestone, tags, pulls, issues, commits): print(f"## {title}") print("") @@ -228,7 +221,7 @@ def report(title, repo, milestone, tags, pulls, issues, commits): print("-" * 5, " | ", "-" * 5, " | ", "-" * 5) for k, tag in sorted(tags.items()): commit = repo.get_commit(tag.commit.sha) - when = str2time(commit.last_modified).strftime("%Y-%m-%d") + when = commit.last_modified_datetime.strftime("%Y-%m-%d") print(f"[{tag.commit.sha[:7]}]({tag.commit.html_url}) | {when} | {k}") print("") print("### Pull Requests") @@ -240,7 +233,7 @@ def report(title, repo, milestone, tags, pulls, issues, commits): print("-" * 5, " | ", "-" * 5, " | ", "-" * 5, " | ", "-" * 5) for k, pull in sorted(pulls.items()): state = {True: "merged", False: "closed"}[pull.merged] - when = str2time(pull.last_modified).strftime("%Y-%m-%d") + when = pull.closed_at.strftime("%Y-%m-%d") # fmt: off print( f"[#{pull.number}]({pull.html_url})" @@ -307,7 +300,7 @@ def main(base=None, head=None, milestone=None, token=None, debug=False): # 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 diff --git a/utils/update_copyright_date.py b/utils/update_copyright_date.py index 261b1933a3..c2aff310cb 100755 --- a/utils/update_copyright_date.py +++ b/utils/update_copyright_date.py @@ -12,12 +12,19 @@ import os, sys import mimetypes -from build_preparation import ROOT_DIR_EXPECTED_RESOURCES import datetime YEAR = datetime.datetime.now().year LEFT_SIDE_TEXT_MATCH = "Copyright (C) " RIGHT_SIDE_TEXT_MATCH = " NeXus International Advisory Committee (NIAC)" +ROOT_DIR_EXPECTED_RESOURCES = { + "files": """COPYING LGPL.txt Makefile NXDL_VERSION + nxdl.xsd nxdlTypes.xsd README.md + """.split(), + "subdirs": """applications base_classes contributed_definitions manual + package utils www impatient-guide + """.split(), +} def update(filename): @@ -170,7 +177,7 @@ def __developer_build_setup__(): # 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 diff --git a/www/download.nexusformat.org/favicon.ico b/www/download.nexusformat.org/favicon.ico deleted file mode 100644 index 064181b36a..0000000000 Binary files a/www/download.nexusformat.org/favicon.ico and /dev/null differ diff --git a/www/download.nexusformat.org/index.html b/www/download.nexusformat.org/index.html deleted file mode 100644 index a198163a54..0000000000 --- a/www/download.nexusformat.org/index.html +++ /dev/null @@ -1,26 +0,0 @@ - - -NeXus Downloads - - - -

NeXus Downloads

- -
- - diff --git a/www/download.nexusformat.org/kits/index.shtml b/www/download.nexusformat.org/kits/index.shtml deleted file mode 100644 index 185981ccae..0000000000 --- a/www/download.nexusformat.org/kits/index.shtml +++ /dev/null @@ -1,13 +0,0 @@ - - -NeXus Data Format Distribution Kits - - -

NeXus Data Format Distribution Kits

-

Moved to Github!

-All release packages of the definitions and NAPI have been moved to -the NeXus Github code repository or -the NeXus Github definitions repository. -
- - diff --git a/www/download.nexusformat.org/robots.txt b/www/download.nexusformat.org/robots.txt deleted file mode 100644 index eb0536286f..0000000000 --- a/www/download.nexusformat.org/robots.txt +++ /dev/null @@ -1,2 +0,0 @@ -User-agent: * -Disallow: