diff --git a/applications/NXarpes.nxdl.xml b/applications/NXarpes.nxdl.xml index e1375a8939..9cfe8a4f40 100644 --- a/applications/NXarpes.nxdl.xml +++ b/applications/NXarpes.nxdl.xml @@ -30,7 +30,12 @@ This is an application definition for angular resolved photo electron spectroscopy. - It has been drawn up with hemispherical electron analysers in mind. + 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`." @@ -125,4 +130,4 @@ - + \ No newline at end of file diff --git a/applications/NXmpes.nxdl.xml b/applications/NXmpes.nxdl.xml new file mode 100644 index 0000000000..ea00c73897 --- /dev/null +++ b/applications/NXmpes.nxdl.xml @@ -0,0 +1,1590 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + 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 + + + + + + + + + + + + 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. + + + + + 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 + + + + + String or list of strings of the electronic core levels that were probed in this MPES experiment. + The convention for writing the core levels is to write the element symbol, separated by a whitespace from the electronic orbital configuration of the electronic level. + The core levels should be selected from the following list. + - H 1s + - He 1s + - Li 1s + - Be 1s + - B 1s + - C 1s + - N 1s + - O 1s + - F 1s + - Ne 1s + - Na 1s + - Mg 1s + - Al 1s + - Si 1s + - P 1s + - S 1s + - Cl 1s + - Ar 1s + - K 1s + - Ca 1s + - Sc 1s + - Ti 1s + - V 1s + - Cr 1s + - Mn 1s + - Fe 1s + - Fe 2p + - Fe 2p1/2 + - Fe 2p3/2 + - Co 1s + - Co 2p + - Co 2p1/2 + - Co 2p3/2 + - Ni 1s + - Ni 2p + - Ni 2p1/2 + - Ni 2p3/2 + - Cu 1s + - Cu 2p + - Cu 2p1/2 + - Cu 2p3/2 + - Zn 2p + - Zn 2p1/2 + - Zn 2p3/2 + - Ga 2p + - Ga 2p1/2 + - Ga 2p3/2 + - Ge 2p + - Ge 2p1/2 + - Ge 2p3/2 + - As 3d5/2 + - As 3d3/2 + - Se 3d5/2 + - Se 3d3/2 + - Br 3d5/2 + - Br 3d3/2 + - Kr 3d5/2 + - Kr 3d3/2 + - Rb 2p + - Rb 2p3/2 + - Sr 3d5/2 + - Sr 3d3/2 + - Y 3d5/2 + - Y 3d3/2 + - Zr 3d5/2 + - Zr 3d3/2 + - Nb 3d5/2 + - Nb 3d3/2 + - Mo 3d5/2 + - Mo 3d3/2 + - Tc 3d5/2 + - Tc 3d3/2 + - Ru 3d5/2 + - Ru 3d3/2 + - Rh 3d5/2 + - Rh 3d3/2 + - Pd 3d5/2 + - Pd 3d3/2 + - Ag 3d5/2 + - Ag 3d3/2 + - Cd 3d5/2 + - Cd 3d3/2 + - In 3d5/2 + - In 3d3/2 + - Sn 3d5/2 + - Sn 3d3/2 + - Sb 3d5/2 + - Sb 3d3/2 + - I 3d5/2 + - I 3d3/2 + - Xe 3d5/2 + - Xe 3d3/2 + - Cs 2p + - Cs 2p3/2 + - Ba 3d5/2 + - Ba 3d3/2 + - La 3d5/2 + - La 3d3/2 + - Ce 3d5/2 + - Ce 3d3/2 + - Pr 3d5/2 + - Pr 3d3/2 + - Nd 3d5/2 + - Nd 3d3/2 + - Pm 3d5/2 + - Pm 3d3/2 + - Sm 3d5/2 + - Sm 3d3/2 + - Eu 3d5/2 + - Eu 3d3/2 + - Gd 3d5/2 + - Gd 3d3/2 + - Tb 3d5/2 + - Tb 3d3/2 + - Dy 3d5/2 + - Dy 3d3/2 + - Ho 3d5/2 + - Ho 3d3/2 + - Er 3d5/2 + - Er 3d3/2 + - Tm 3d5/2 + - Tm 3d3/2 + - Yb 3d5/2 + - Yb 3d3/2 + - Lu 3d5/2 + - Lu 3d3/2 + - Hf 3d5/2 + - Hf 3d3/2 + - Ta 3d5/2 + - Ta 3d3/2 + - W 3d5/2 + - W 3d3/2 + - Re 3d5/2 + - Re 3d3/2 + - Os 3d5/2 + - Os 3d3/2 + - Ir 3d5/2 + - Ir 3d3/2 + - Pt 3d5/2 + - Pt 3d3/2 + - Au 4f5/2 + - Au 4f7/2 + - Hg 4f5/2 + - Hg 4f7/2 + - Tl 4f5/2 + - Tl 4f7/2 + - Pb 4f5/2 + - Pb 4f7/2 + - Bi 4f5/2 + + In addition, it is also possible to list Auger transitions that were probed. The Auger transitions should be selected from the following list. + - Be KLL + - B KLL + - C KLL + - N KLL + - O KLL + - F KLL + - Ne KLL + - Na KLL + - Mg KLL + - Al KLL + - Si KLL + - P KLL + - S KLL + - Cl KLL + - Ar KLL + - K KLL + - Ca KLL + - Sc KLL + - Ti KLL + - V KLL + - Cr KLL + - Mn KLL + - Fe KLL + - Co KLL + - Ni KLL + - Cu KLL + - Zn KLL + - Ga KLL + - Ge KLL + - As KLL + - Se KLL + - Br KLL + - Kr KLL + - Rb KLL + - Sr KLL + - Y KLL + - Zr KLL + - Nb KLL + - Mo KLL + - Tc KLL + - Ru KLL + - Rh KLL + - Pd KLL + - Ag KLL + - Cd KLL + - In KLL + - Sn KLL + - Sb KLL + - I KLL + - Xe KLL + - Cs KLL + - Ba KLL + - La KLL + - Ce KLL + - Pr KLL + - Nd KLL + - Pm KLL + - Sm KLL + - Eu KLL + - Gd KLL + - Tb KLL + - Dy KLL + - Ho KLL + - Er KLL + - Tm KLL + - Yb KLL + - Lu KLL + - Hf KLL + - Ta KLL + - W KLL + - Re KLL + - Os KLL + - Ir KLL + - Pt KLL + - Au KLL + - Hg KLL + - Tl KLL + - Pb KLL + - Bi KLL + - Th MNN + - Pa MNN + - U MNN + - Np MNN + - Pu MNN + - Am MNN + - Cm MNN + - Bk MNN + - Cf MNN + - Es MNN + - Fm MNN + - Md MNN + - No MNN + - Lr MNN + + + + + 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. + + + + Name of the user. + + + + + 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 + + + + Overall energy resolution of the photoemission instrument. + + + + + + + + + + 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 + + + + + + + + + + + The source used to generate the :ref:`beam_probe &lt;/NXmpes/ENTRY/INSTRUMENT/beam_probe-field&gt;`. + + 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. + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + + + + + + + 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 + + + + + + The source used to generate the :ref:`beam_probe &lt;/NXmpes/ENTRY/INSTRUMENT/beam_probe-field&gt;` + in pump-probe experiments. + + Properties refer strictly to parameters of the source, not of the output beam. + + + + + + + + + + + + A reference to a beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_pump` it should refer to `beam_pump`. + + Example: + * /entry/instrument/source_pump = /entry/instrument/beam_pump + + + + + + Any other source used to generate a beam. + + This group is to be used for any additional beams that are not described by + :ref:`source_probe &lt;/NXmpes/ENTRY/INSTRUMENT/source_probe-field&gt;` or + :ref:`source_pump &lt;/NXmpes/ENTRY/INSTRUMENT/source_pump-field&gt;`. + + An example could be a low energy electron source for charge neutralization + (see also :ref:`flood_gun &lt;/NXmpes/ENTRY/INSTRUMENT/flood_gun-group&gt;`. + + Properties refer strictly to parameters of the source, not of the output beam. + + 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_laser` and a `source_electron`. + + + + + + + + + + + + A reference to a beam emitted by this source. + Should be named with the same appendix, e.g., + for `source_laser` it should refer to `beam_laser`. + + Example: + * /entry/instrument/source_laser = /entry/instrument/beam_laser + + + + + + Properties of the probe beam at a given location. + + This is the beam that is used to facilitate the photoemission during MPES + experiments. It is used to measure the state of a system at a specific moment + in time. + + + + 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. + + + + + + + + + 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 + + + + + + Properties of the pump beam at a given location. + + In pump-probe experiments, this is the beam that excites the system, + initiating a change in its state. It sets the timing for the experiment + by defining time zero in a pump-probe setup. + + + + 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. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_pump` it should refer to `source_pump`. + This should be specified if an associated source exists. + + Example: + * /entry/instrument/beam_pump = /entry/instrument/source_pump + + + + + + Properties of any other photon beam at a given location. + + This group is to be used for any additional beams that are not described by + :ref:`beam_probe &lt;/NXmpes/ENTRY/INSTRUMENT/beam_probe-field&gt;` or + :ref:`beam_pump &lt;/NXmpes/ENTRY/INSTRUMENT/beam_pump-field&gt;`. + + Should be named with the same appendix as sourceTYPE, e.g., + for `source_laser` it should refer to `beam_laser`. + + + + 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. + + + + + + + + + The source that emitted this beam. + Should be named with the same appendix, e.g., + for `beam_laser` it should refer to `source_laser`. + This should be specified if an associated source exists. + + Example: + * /entry/instrument/beam_laser = /entry/instrument/source_laser + + + + + + + + + + + + + + + + + + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + 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. + + + + + 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. + + + + + + + + + + + + + + + + + + + + + + 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. + + + + + + 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. + + + + + + + + + + + + Type of electron amplifier in the first amplification step. + + + + + + + + + Description of the 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 group ideally collects the data with the lowest level of processing + possible. + + Axes should be named according to the conventions defined below. Note that this + list is a glossary with explicitly named axis names, which is only intended to + coverthe most common measurement axes and is therefore not complete. It is + possible to add axes with other names at any time. + + + + + + + + + Raw data before calibration. + + + + + Detector pixel in x direction. + + + + + Detector pixel in y direction. + + + + + (Un)calibrated energy axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + (Un)calibrated kinetic energy axis. + + 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 + + + + + (Un)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 + + + + + + + + (Un)calibrated photon energy of the incoming probe beam. + + Could be a link to /entry/instrumen/beam_probe/incident_energy. + + + + + (Un)calibrated k-space coordinate in x direction. It is envisioned that the axes in + momentum space are named ``kx``, ``ky``, and ``kz``. Typically, the vectors in + momentum space are defined such that ``kx`` and ``ky`` comprise the parallel + component, while ``kz`` is the perpendicular component. + + It is also possible to define ``k_parallel`` and ``k_perp`` for the parallel + and perpendicular momenta, respectively. + + Units are typically 1/Angström. + + + + + (Un)calibrated k-space coordinate in y direction. For more information, see the + definition of the :ref:`kx &lt;/NXmpes/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/raw_data/kx-field&gt;` + axis. + + + + + (Un)calibrated k-space coordinate in z direction. For more information, see the + definition of the :ref:`kx &lt;/NXmpes/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/raw_data/kx-field&gt;` + axis. + + + + + (Un)calibrated parallel component in k-space. + + ``k_parallel`` and :ref:`k_perpendicular &lt;/NXmpes/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/raw_data/k_perpendicular-field&gt;` + describe how the electron's wave vector ``k`` is split into components relative + to the surface. + + ``k_parallel`` is the component of the electron's wave vector that is parallel to + the surface. It is conserved during the photoemission process. This means that the + electron's momentum along the surface inside the material is directly related to + its measured momentum outside the material. + + Units are typically 1/Angström. + + + + + (Un)calibrated perpendicular component in k-space. + + ``k_perpendicular`` is the component that is normal (perpendicular) to the surface. + It is not conserved during photoemission because the electron experiences a potential + change when it exits the material into vacuum. To determine ``k_perpendicular`` + inside the material, one typically needs to estimate the inner potential :math:`V_0`, + which accounts for the energy shift due to the material's work function and electronic + structure. + + Units are typically 1/Angström. + + + + + First (un)calibrated angular coordinate. It is envisioned that the axes in angular space + are named ``angular0`` and ``angular1``. + + The angular axes should be named in order of decreasing speed, i.e., ``angular0`` + should be the fastest scan axis and ``angular1`` should be the slow-axis angular + coordinate. However, ``angular0`` may also be second slow axis if the measurement + is angularly integrated and ``angular1`` could also be the second fast axis in the + case of simultaneous dispersion in two angular dimensions. + + + + + Second (un)calibrated angular coordinate. + + For more information, see the + definition of the :ref:`angular0 &lt;/NXmpes/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/raw_data/angular0-field&gt;` + axis. + + This is typically the slower scan axis compared to ``angular0``. + + + + + First (un)calibrated spatial coordinate. It is envisioned that the axes in angular space + are named ``spatial0`` and ``spatial1``. + + The spatial axes should be named in order of decreasing speed, i.e., ``spatial0`` + should be the fastest scan axis and `spatial1`` should be the slow-axis spatial + coordinate. However, ``spatial`` may also be second slow axis if the measurement + is spatially integrated and ``spatial1`` could also be the second fast axis in the + case of simultaneous dispersion in two spatial dimensions. + + + + + Second (un)calibrated spatial coordinate. + + For more information, see the + definition of the :ref:`spatial0 &lt;/NXmpes/ENTRY/INSTRUMENT/ELECTRONANALYSER/DETECTOR/raw_data/spatial0-field&gt;` + axis. + + This is typically the slower scan axis compared to ``spatial0``. + + + + + Calibrated delay time. + + + + + (Un)calibrated temperature axis in case of experiments where the temperature was + scanned. This is typically the sample temperature and could be linked from + /entry/sample/temperature_env/temperature_sensor/value. + + + + + + + + Manipulator for positioning of the sample. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Device to measure the gas pressure in the instrument. + + + + + + + + + + + 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. + + + + + + + Device to bring low-energy electrons to the sample for charge neutralization + + + + + + + + + + + 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. + + + + + + + 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. + + + + + + Calibration event for one on the axes in the main + :ref:`NXdata &lt;/NXmpes/data-group&gt;`_. + + The naming of these calibrations should follow those in the + :ref:`NXdata &lt;/NXmpes/data-group&gt;`_. For example, + for the momentum axis ``kx``, the corresponding calibration should + be called ``kx_calibration``. + + + + + + For energy referencing, the measured energies are corrected for the charging potential + (i.e., the electrical potential of the surface region of an insulating sample, caused by + irradiation) such that those energies correspond to a sample with no surface charge. + Usually, the energy axis is adjusted by shifting all energies uniformally until one + well-defined emission line peak (or the Fermi edge) is located at a known _correct_ energy. + + This concept is related to term `12.74 ff.`_ of the ISO 18115-1:2023 standard. + + .. _12.74 ff.: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.74 + + + + + + + + + Electronic core or valence level that was used for the calibration. + + + + + Reference peak that was used for the calibration. + + For example: adventitious carbon | C-C | metallic Au | elemental Si | Fermi edge | vacuum level + + + + + The binding energy (in units of eV) that the specified emission line appeared at, + after adjusting the binding energy scale. + + 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 + + + + + Offset between measured binding energy and calibrated binding energy of the + emission line. + + + + + This is the calibrated energy axis to be used for data plotting. + + This could be a link to /entry/data/energy. + + + + + + In the transmission correction, each intensity measurement for electrons of a given + kinetic energy is multiplied by the corresponding value in the relative_intensity + field of the transmission_function. This calibration procedure is used to account for + the different tranmsission efficiencies when using different lens modes. + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency for electrons of + different kinetic energy passing through the electron analyser. + + This can be a link to /entry/instrument/electronanalyser/transmission_function. + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + + Describes the operations of image registration. + + + + + Describes the operations of image distortion correction. + + + + + Any further calibration procedures, e.g. axis calibrations. + + + + + + + + + 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`. + + + + + + + + + + + + + + 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 method of sample preparation before the photoemission + experiment. + + + + + + + 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. + + + + + 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. + + + + + 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. + + + + 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. + + + + + + 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. + + + + + 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. + + + + + + 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. + + + + + 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. + + + + 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. + + + + + + + + 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. + + Axes should be named according to the conventions defined below. 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. + + + + + + + + + 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 axis for the energy of the measured electrons. + + Could be linked from the respective '@reference' field. + + + + 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 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' + + + + + + + Calibrated photon energy of the incoming probe beam. + + Could be a link to /entry/instrumen/beam_probe/incident_energy. + + + + + Calibrated k-space coordinate in x direction. It is envisioned that the axes in + momentum space are named ``kx``, ``ky``, and ``kz``. Typically, the vectors in + momentum space are defined such that ``kx`` and ``ky`` comprise the parallel + component, while ``kz`` is the perpendicular component. + + It is also possible to define ``k_parallel`` and ``k_perp`` for the parallel + and perpendicular momenta, respectively. + + Units are typically 1/Angström. + + + + + Calibrated k-space coordinate in y direction. For more information, see the + definition of the :ref:`kx &lt;/NXmpes/ENTRY/data/kx-field&gt;` + axis. + + + + + Calibrated k-space coordinate in z direction. For more information, see the + definition of the :ref:`kx &lt;/NXmpes/ENTRY/data/kx-field&gt;` + axis. + + + + + Calibrated parallel component in k-space. + + ``k_parallel`` and :ref:`k_perpendicular &lt;/NXmpes/ENTRY/data/k_perpendicular-field&gt;` + describe how the electron's wave vector ``k`` is split into components relative + to the surface. + + ``k_parallel`` is the component of the electron's wave vector that is parallel to + the surface. It is conserved during the photoemission process. This means that the + electron's momentum along the surface inside the material is directly related to + its measured momentum outside the material. + + Units are typically 1/Angström. + + + + + Calibrated perpendicular component in k-space. + + ``k_perpendicular`` is the component that is normal (perpendicular) to the surface. + It is not conserved during photoemission because the electron experiences a potential + change when it exits the material into vacuum. To determine ``k_perpendicular`` + inside the material, one typically needs to estimate the inner potential :math:`V_0`, + which accounts for the energy shift due to the material's work function and electronic + structure. + + Units are typically 1/Angström. + + + + + First calibrated angular coordinate. It is envisioned that the axes in angular space + are named ``angular0`` and ``angular1``. + + The angular axes should be named in order of decreasing speed, i.e., ``angular0`` + should be the fastest scan axis and ``angular1`` should be the slow-axis angular + coordinate. However, ``angular0`` may also be second slow axis if the measurement + is angularly integrated and ``angular1`` could also be the second fast axis in the + case of simultaneous dispersion in two angular dimensions. + + + + + Second calibrated angular coordinate. + + For more information, see the + definition of the :ref:`angular0 &lt;/NXmpes/ENTRY/data/angular0-field&gt;` + axis. + + This is typically the slower scan axis compared to ``angular0``. + + + + + First calibrated spatial coordinate. It is envisioned that the axes in angular space + are named ``spatial0`` and ``spatial1``. + + The spatial axes should be named in order of decreasing speed, i.e., ``spatial0`` + should be the fastest scan axis and `spatial1`` should be the slow-axis spatial + coordinate. However, ``spatial`` may also be second slow axis if the measurement + is spatially integrated and ``spatial1`` could also be the second fast axis in the + case of simultaneous dispersion in two spatial dimensions. + + + + + Second calibrated spatial coordinate. + + For more information, see the + definition of the :ref:`spatial0 &lt;/NXmpes/ENTRY/data/spatial0-field&gt;` + axis. + + This is typically the slower scan axis compared to ``spatial0``. + + + + + Calibrated delay time. + + + + + Calibrated temperature axis in case of experiments where the temperature was + scanned. This is typically the sample temperature and could be linked from + /entry/sample/temperature_env/temperature_sensor/value. + + + + + diff --git a/applications/NXmpes_arpes.nxdl.xml b/applications/NXmpes_arpes.nxdl.xml new file mode 100644 index 0000000000..d18d0056c6 --- /dev/null +++ b/applications/NXmpes_arpes.nxdl.xml @@ -0,0 +1,417 @@ + + + + + + + This is an general application definition for angle-resolved multidimensional + photoelectron spectroscopy. + + + + + + + + + + + + + Link to transformations defining an APRES base coordinate system, + which is defined such that the positive z-axis points towards the analyzer entry, + and the x-axis lies within the beam/analyzer plane. + + + + + Set of transformations, describing the orientation of the ARPES coordinate system + with respect to the beam coordinate system (.). + + + + + + + + Overall angular resolution along the Nth angular axis. Create one such entry per relevant angular axis, + corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. + + + + + + + + + + + + + Analyzer angular resolution along the Nth angular axis. + Create one such entry per relevant angular axis, corresponding to the angular axes in NXdata. + For hemispherical analyzers, angular0_resolution corresponds to the direction along the analyzer slit, + and angular1_resolution to the one perpendicular to it. + + + + + + + + + + + + Reference to the last transformation describing the orientation of the analyzer relative to the beam, + e.g. transformations/analyzer_elevation. + + + + + Set of transformations, describing the relative orientation of the analyzer + with respect to the beam coordinate system (.). + + + + Rotation about the analyzer lens axis. + Its zero reference is defined such that the angular0 axis is + increasing towards the positive y axis (analyzer slit vertical). + + + + + + + + + + + + + + Path to a transformation that places the analyzer origin system into the + arpes_geometry coordinate system. + + + + + + Elevation of the effective analyzer acceptance area, e.g. realized by + deflectors, or as one angle in a TOF detector. If a resolved angle, place the + calibrated axis coordinates here. + + + + + + + + + + + + + + + + + + + + In-plane analyzer coordinate along a dispersive direction, + e.g. along an analyzer slit. If a resolved angle, place the calibrated coordinates here. + + + + + + + + + + + + + + + + + + + + + + Scheme of the electron collection column. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to the end of the transformation chain, + orienting the sample surface within the arpes_geometry coordinate system + (sample_azimuth or anything depending on it). + + + + + Set of transformations, describing the relative orientation of the sample + with respect to the arpes_geometry coordinate system. + + + + Rotation about the y axis (typically the long manipulator axis). + + + + + + + + + + + + + + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. + + + + + + Offset of polar rotation. + + + + + + + + + + + + + + + + + + + + Rotation about the x axis (typically a manipulator tilt). + + + + + + + + + + + + + + + + + + + + Offset of tilt rotation. + + + + + + + + + + + + + + + + + + + + Rotation about the z axis (azimuthal rotation within the sample plane). + + + + + + + + + + + + + + + + + + + + Offset of azimuthal rotation. + + + + + + + + + + + + + + + + + + + + + + + There is an object named data that contains the signal. + + + + + + + + There are three dimensions, one energy and two angular coordinates. Any coordinates that do not move, + are represented by one point. + + + + + + + + + + + Trace of the energy axis. Could be linked from the respective ``@reference`` + field. + + + + Points to the path of a field defining the calibrated axis which the energy axis refers. + + For example: + @reference: '/entry/instrument/detector/sensor_y' for a 2D detector + @reference: '/entry/instrument/energydispersion/center_kinetic_energy' for a swept scan + @reference: '/entry/process/calibration/energy_calibration/calibrated_axis' for a preprocessed axis. + + + + + + Trace of the first angular axis. Could be linked from the respective + ``@reference`` field. + + + + Points to the path of a field defining the calibrated axis which the ``angular0`` axis refers. + + For example: + @reference: '/entry/sample/transformations/sample_tilt' for a manipulator angular scan + @reference: '/entry/instrument/detector/sensor_x' for a 2D detector + @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @reference: '/entry/process/calibration/angular0_calibration/calibrated_axis' for a preprocessed axis. + + + + + + Trace of the second axis. Could be linked from the respective ``@reference`` + field. + + + + Points to the path of a field defining the calibrated axis which the ``angular1`` axis refers. + + For example: + @reference: '/entry/sample/transformations/sample_polar' for a manipulator angular scan + @reference: '/entry/instrument/detector/sensor_y' for a 2D detector + @reference: '/entry/instrument/collectioncolumn/deflector' for a deflector scan + @reference: '/entry/process/calibration/angular1_calibration/calibrated_axis' for a preprocessed axis. + + + + + + Represents a measure of three-dimensional photoemission counts, where + the varied axes are energy, and one or more angular coordinates. Axes traces + should be linked to the actual encoder position in NXinstrument or calibrated axes in NXprocess. + + + + + diff --git a/applications/NXxps.nxdl.xml b/applications/NXxps.nxdl.xml new file mode 100644 index 0000000000..db1419bdde --- /dev/null +++ b/applications/NXxps.nxdl.xml @@ -0,0 +1,492 @@ + + + + + + This is the application definition for X-ray photoelectron spectroscopy. + + + + + + + + + + A name of the experimental method according to `Clause 11`_ of + the `ISO 18115-1:2023`_ specification. + + Examples for XPS-related experiments include: + * X-ray photoelectron spectroscopy (XPS) + * angle-resolved X-ray photoelectron spectroscopy (ARXPS) + * ultraviolet photoelectron spectroscopy (UPS) + * hard X-ray photoemission spectroscopy (HAXPES) + * near ambient pressure X-ray photoelectron spectroscopy (NAPXPS) + * electron spectroscopy for chemical analysis (ESCA) + + .. _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 + + + + + + In traditional surface science, a left-handed coordinate system is used such that the positive z-axis + points along the normal of the sample stage, and the x- and y-axes lie in the plane of the sample stage. + However, in NeXus, a coordinate system that is the same as `McStas`_ is used. `xps_coordinate_system` + gives the user the opportunity to work in the traditional base coordinate system. + + .. _McStas: http://mcstas.org/ + + .. image:: xps/xps_cs.png + :width: 40% + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Link to transformations defining the XPS base coordinate system, + which is defined such that the positive z-axis points along the sample stage normal, and the + x- and y-axes lie in the plane of the sample stage. + + + + + Set of transformations, describing the orientation of the XPS coordinate system + with respect to the beam coordinate system (.) or any other coordinate system. + + The transformations in `coordinate_system_transformations` depend on the actual instrument geometry. + If the z-axis is pointing in the direction of gravity (i.e., if the sample is mounted horizontally), + the following transformations can be used for describing the XPS coordinate system + with respect to the beam coordinate system (.): + + .. code-block:: + + xps_coordinate_system:NXcoordinate_system + depends_on=entry/geometries/xps_coordinate_system/coordinate_transformations/z_rotation + coordinate_system_transformations:NXtransformations + z_rotation=beam_azimuth_angle + @depends_on=y_flip + @transformation_type=rotation + @vector=[0, 0, 1] + @units=degree + y_flip=180 + @depends_on=y_rotation + @transformation_type=rotation + @vector=[0, 1, 0] + @units=degree + y_rotation=beam_polar_angle_of_incidence + @depends_on=. + @transformation_type=rotation + @vector=[0, 1, 0] + @units=degree + + + + + + + Description of the XPS 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 + + + + + + + + Reference to the transformation describing the orientation of the beam + relative to a defined coordinate system. + + + + + + Incidence angle of the beam with respect to the upward z-direction, defined by + the sample stage. + + + + + + + + + + + + + + + + + + + + Azimuthal rotation of the beam from the y-direction towards the operator, defined + by the sample stage. + + + + + + + + + + + + + + This should point to the last element of the coordinate system transformations defined in + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. + + + + + + + + + + + + + + + + + + Reference to the transformation describing the orientation of the analyzer + relative to a defined coordinate system. + + + + + + Polar tilt of the analyser with respect to the upward z-direction, defined by + the sample stage. + + The angle between the incoming beam and the analyser is given by + beam_analyser_angle = beam_polar_angle_of_incidence + analyser_take_off_polar_angle. + In practice, the analyser axis is often set as the z axis (analyser_take_off_polar_angle = 0), + so that beam_analyser_angle = beam_polar_angle_of_incidence. For magic angle configurations, + this angle is 54.5°. + + + + + + + + + + + + + + + + + + + + Azimuthal rotation of the analyser from the y-direction towards the operator, + defined by the sample stage. + + + + + + + + + + + + + + This should point to the last element of the coordinate system transformations defined in + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. + + + + + + + + + + + + + + Reference to the transformation describing the orientation of the sample + relative to a defined coordinate system. + + + + + + Clockwise rotation about the sample normal. + + + + + + + + + + + + + + + + + + + + Polar tilt of the sample with respect to the upward z-direction, defined by + the sample stage. + + + + + + + + + + + + + + + + + + + + Azimuthal rotation of the sample from the y-direction towards the operator, + defined by the sample stage. + + + + + + + + + + + + + + This should point to the last element of the coordinate system transformations defined in + /entry/geometries/xps_coordinate_system/coordinate_system_transformations. + + + + + + + + + + + + + + Peak model for XPS fitting. Each `NXfit` instance shall be used for the description of + _one_ peak fit in _one_ XPS region. As an example, this could be used to describe the + fitting of one measured C 1s spectrum. + + This concept is related to term `3.29`_ of the ISO 18115-1:2023 standard. + + .. _3.29: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.29 + + + + + Input data and results of the fit. + + + + Dependent variable for this fit procedure. + + This could be a link to entry/data/data. + + + + + Independent variable for this fit procedure. + + This could be a link to entry/data/energy. + + + + + + + + + + + This could be a link to entry/data/energy. + + + + + Intensity values of the fitted function at each energy in the position field. + + This concept is related to term `3.15`_ of the ISO 18115-1:2023 standard. + + .. _3.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.15 + + + + + + + + + + Area of the peak. + + + + + Width of a peak at a defined fraction of the peak height. + + Usually, this will be the Full Width at Half Maximum of the peak (FWHM). + For asymmetric peaks, convenient measures of peak width are the half-widths of + each side of the peak at half maximum intensity. + + This concept is related to term `3.28`_ of the ISO 18115-1:2023 standard. + + .. _3.28: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.28 + + + + + Position of the peak on the energy axis. + + + + + + + Total area under the peak after background removal. + + This concept is related to term `3.16`_ of the ISO 18115-1:2023 standard. + + .. _3.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.16 + + + + + Atomic concentration of the species defined by this peak. This should be a value + between 0 and 1. + + + + + + Functional form of the fitted XPS background. + + This concept is related to term `3.21`_ of the ISO 18115-1:2023 standard. + + .. _3.21: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.21 + + + + + + + + + + Human-readable description of the background fit function. + + .. csv-table:: Examples for background descriptions + :header: "Background Type", "Description" + + "Linear", "Linear background, i.e., a simple straight line from the minimal to the maximal abscissa value." + "Shirley", "Shirley background. In the Shirley background, the background intensity at any given binding energy is proportional to the intensity of the total peak area above the background in the lower binding energy peak range (i.e., the background goes up in proportion to the total number of photoelectrons below its binding energy position)." + "Tougaard", "Tougaard background (or Tougaard universal cross-section approach) which is a methodology for integrating the intensity of the background at a given binding energy from the spectral intensities to higher kinetic energies." + "Step Down/Step Up", "Background function for fitting a complementary error function to an edge, used for fitting a step in the data." + + In case none of these examples apply, the functional form of the background should be given by the `formula` + field. + + + + + + + + + + + + + + + + + + + diff --git a/applications/xps/xps_cs.png b/applications/xps/xps_cs.png new file mode 100644 index 0000000000..f83b15e707 Binary files /dev/null and b/applications/xps/xps_cs.png differ diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index 71370d4592..527d1d1b04 100644 --- a/base_classes/NXbeam.nxdl.xml +++ b/base_classes/NXbeam.nxdl.xml @@ -61,11 +61,45 @@ Distance from sample. Note, it is recommended to use NXtransformations instead. - Energy carried by each particle of the beam on entering the beamline component + + Energy carried by each particle of the beam on entering the beamline component. + + In the case of a monochromatic beam this is the scalar energy. + Several other use cases are permitted, depending on the + presence of other incident_energy_X fields. + + * In the case of a polychromatic beam this is an array of length m of energies, with the relative weights in incident_energy_weights. + * In the case of a monochromatic beam that varies shot-to-shot, this is an array of energies, one for each recorded shot. + Here, incident_energy_weights and incident_energy_spread are not set. + * In the case of a polychromatic beam that varies shot-to-shot, + this is an array of length m with the relative weights in incident_energy_weights as a 2D array. + * In the case of a polychromatic beam that varies shot-to-shot and where the channels also vary, + this is a 2D array of dimensions nP by m (slow to fast) with the relative weights in incident_energy_weights as a 2D array. + + Note, variants are a good way to represent several of these use cases in a single dataset, + e.g. if a calibrated, single-value energy value is available along with the original spectrum from which it was calibrated. + + + + The energy spread FWHM for the corresponding energy(ies) in incident_energy. In the case of shot-to-shot variation in + the energy spread, this is a 2D array of dimension nP by m + (slow to fast) of the spreads of the corresponding + wavelength in incident_wavelength. + + + + + In the case of a polychromatic beam this is an array of length m of the relative + weights of the corresponding energies in incident_energy. In the case of a + polychromatic beam that varies shot-to-shot, this is a 2D array of dimensions np + by m (slow to fast) of the relative weights of the corresponding energies in + incident_energy. + + Energy carried by each particle of the beam on leaving the beamline component @@ -160,7 +194,9 @@ Size of the beam entering this component. Note this represents - a rectangular beam aperture, and values represent FWHM + a rectangular beam aperture, and values represent FWHM. + If applicable, the first dimension shall be the horizontal extent + and the second dimension shall be the vertical extent. @@ -179,6 +215,24 @@ + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + Polarization vector on leaving beamline component @@ -186,6 +240,24 @@ + + + The units for this observable are not included in the NIAC list. + Responsibility on correct formatting and parsing is handed to the user + by using `NX_ANY`. Correct parsing can still be implemented by using + this attribute. + + | Fill with: + + * The unit unidata symbol if the unit has one (Example: T for the unit of magnetic flux density tesla). + * The unit unidata name if the unit has a name (Example: farad for capacitance). + * A string describing the units according to unidata unit operation notation, if the unit is a complex combination of named units and + does not have a name. + + Example: for lightsource brilliance (SI) 1/(s.mm2.mrad2). + Here: SI units are V2/m2. + + @@ -245,6 +317,87 @@ + + + Energy of a single pulse at the diagnostic point + + + + + Average power at the diagnostic point + + + + + Incident fluence at the diagnostic point + + + + Here: SI units are 'J/m2', customary 'mJ/cm2'. + + + + + + FWHM duration of the pulses at the diagnostic point + + + + + Delay time between two pulses of a pulsed beam. + + + + A reference to the beam in relation to which the delay is. + + + + + + FROG trace of the pulse. + + + + + + + + + Horizontal axis of a FROG trace, i.e. delay. + + + + + + + + Vertical axis of a FROG trace, i.e. frequency. + + + + + + + + The type of chirp implemented + + + + + Group delay dispersion of the pulse for linear chirp + + + + + Indicates the beam device from which this beam originates. + This defines, whether the beam in an "input" or "output" beam. + + + + + Gives the beam device which this beam will interact with next. + + Distribution of beam with respect to relevant variable e.g. wavelength. This is mainly diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..c715384f03 --- /dev/null +++ b/base_classes/NXcircuit.nxdl.xml @@ -0,0 +1,136 @@ + + + + + + Base class for circuit devices. + + + + Hardware type used in circuit, includes hardware manufacturers and type + + + + + The tunneling current between tip and sample after application of bias voltage. + + + + + Calibration of the current measurement (A/V). + + + + + Offset of the current measurement. + + + + + Proportional relationship between the probe output voltage and the actual + tunneling current when measuring the tunneling current. + + + + + The scan channels are selected by users (in scan contronaller). + + + + + The bandwitdh of the Hardware and/or Software + + + + + (Signals Periods) The Signals Period is the rate at which the signals are + transferred to the host computer running the control software. This is usually + lower by a factor of 10 than the sampling rate, because an internal oversampling + of the signal is done on the real time engine. You can reduce the oversampling + down to 1 in order to resolve higher frequencies in the Spectrum Analyzer. + + + + + Update rate for several processes like History Graph, Auto-Approach, and for + many Programming Interface functions. This is usually set to 20 ms. All + additional timings (7-9) can only be integer multiples of this value. They can + be set to different values, but the actual timing value will be coerced to a + multiple of the Acquisition Period. + + + + + Update rate of animated graphical indicators. These are e.g. some graphs & + sliders. A reasonable value is 40 ms (25 updates per second). Increase this + period to reduce the processor load for the graphical user interface, especially + on slow computers. This value is purely a user interface update rate and does + not affect measurements in any way. + + + + + Update rate of digital indicators, e.g. the numbers displayed besides each + slider. Here, 3 updates per second, or 300 ms is enough. This value is purely a + user interface update rate and does not affect measurements in any way. + + + + + The Measurements period is the integration time for precise measurements + (averaging over specified period), mostly used in sweep modules. Examples are + recording of a force-distance curve or a resonance of a cantilever. For fast + measurements with small steps, a value of 40 ms may be reasonable. For normal + use, 300-500 ms is a good value, but for recording a resonance of a high-Q + cantilever, values of several seconds might be necessary. Usually this parameter + doesn’t need to be set from this module; the sweep modules will set this value + according to the sweep timings. + + + + + Number of output channels + + + + + The user output in each monitor mode. + + + + + The values for each output channel. + + + + + User outputs whose name can be modified in the corresponding module. + + + + + The rate at which the one of the signal changes when ramping to the starting + point. (V/s) + + + diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 77% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml index 2720309109..375e0fc52b 100644 --- a/contributed_definitions/NXcollectioncolumn.nxdl.xml +++ b/base_classes/NXcollectioncolumn.nxdl.xml @@ -1,10 +1,10 @@ - + - Subclass of NXelectronanalyser to describe the electron collection column of a - photoelectron analyser. + Subclass of NXelectronanalyser to describe the electron collection + column of a photoelectron analyser. - Scheme of the electron collection lens, i.e. standard, deflector, PEEM, momentum - microscope, etc. + Scheme of the electron collection lens, i.e. angular dispersive, + spatial dispersive, momentum dispersive, non-dispersive, etc. @@ -48,7 +48,7 @@ Distance between sample and detector entrance - + Labelling of the lens setting in use. @@ -62,6 +62,20 @@ + + + Acceptance angle of the collection column. + + This concept is related to term `7.4`_ of the ISO 18115-1:2023 standard. + + .. _7.4: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.4 + + + + + Acceptance length or area of the collection column. + + The magnification of the electron lens assembly. @@ -83,4 +97,5 @@ Individual lenses in the collection column section + diff --git a/base_classes/NXcoordinate_system.nxdl.xml b/base_classes/NXcoordinate_system.nxdl.xml new file mode 100644 index 0000000000..80de81f407 --- /dev/null +++ b/base_classes/NXcoordinate_system.nxdl.xml @@ -0,0 +1,159 @@ + + + + + + Base class to detail a coordinate system (CS). + + Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as + a member in an :ref:`NXcoordinate_system_set` and the name of the instance + should be this alias. This may support a process whereby jargon when talking + about coordinate systems and conventions may become cleaner for users + because it is not evident for people outside a lab that terms like e.g. + tip space or specimen space refer to the same coordinate system. + This is an example of jargon used in e.g. the field of atom + probe tomography. + + + + Human-readable field telling where the origin of this CS is. + Exemplar values could be *left corner of the lab bench*, *door-handle* + *pinhole through which the electron beam exists the pole piece*. + *barycenter of the triangle*, *center of mass of the stone*. + + + + + + An alternative name given to that coordinate system. + + + + + Coordinate system type. + + + + + + + + + Handedness of the coordinate system if it is a Cartesian. + + + + + + + + + + Possibility to define an alias for the name of the x-axis. + + + + + Human-readable field telling in which direction the x-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + Exemplar values could be direction of gravity. + + + + + + Base unit vector along the first axis which spans the coordinate system. + This axis is frequently referred to as the x-axis in real space and + the i-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the y-axis. + + + + + Human-readable field telling in which direction the y-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the second axis which spans the coordinate system. + This axis is frequently referred to as the y-axis in real space and + the j-axis in reciprocal space. + + + + + + + + Possibility to define an alias for the name of the z-axis. + + + + + Human-readable field telling in which direction the z-axis points if that + instance of :ref:`NXcoordinate_system` has no reference to any parent and as such + is the mighty world reference frame. + + See docstring of x_alias for further details. + + + + + Base unit vector along the third axis which spans the coordinate system. + This axis is frequently referred to as the z-axis in real space and + the k-axis in reciprocal space. + + + + + + + + This specificies the relation to another coordinate system by pointing to the last + transformation in the transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe this coordinate system + with respect to another coordinate system. + + + diff --git a/base_classes/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 0000000000..a842d257d2 --- /dev/null +++ b/base_classes/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,240 @@ + + + + + + + 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. + + + + + + + + + + How are rotations interpreted into an orientation + according to convention 3 of + DOI: 10.1088/0965-0393/23/8/083501. + + + + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + 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. + + + + + + + + + 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. + + + + + + + + + + + + + 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 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/base_classes/NXdata.nxdl.xml b/base_classes/NXdata.nxdl.xml index 41d3e59355..458886fbdd 100644 --- a/base_classes/NXdata.nxdl.xml +++ b/base_classes/NXdata.nxdl.xml @@ -309,6 +309,20 @@ + + + Points to the path of a field defining the data to which the `DATA` group refers. + + This attribute indicates the origin of the data, thereby providing an association to + further metadata that define the physical quantity that the data represents. + + Example: + If the data corresponds to a readout of a detector, ``@target`` points + to that detectors data: + + @target: '/entry/instrument/detector/data' for a detector + + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` @@ -371,6 +385,30 @@ 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 attribute indicates the origin of the axis, thereby providing an association to + further metadata that define the physical quantity that the ``AXISNAME`` represents. + + Examples: + If a calibration has been performed, ``@target`` points to the result of + that calibration: + + @target: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@target`` points + to that detector axis: + + @target: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@target`` points to the transformation + describing the respective motion, e.g.: + + @target: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + @@ -414,6 +452,20 @@ data label + + + Points to the path of a field defining the data to which the ``DATA`` field refers. + + This attribute indicates the origin of the data, thereby providing an association to + further metadata that define the physical quantity that the ``DATA`` represents. + + Example: + If the data corresponds to a readout of a detector, ``@target`` points + to that detectors data: + + @target: '/entry/instrument/detector/data' for a 2D detector + + @@ -535,4 +587,4 @@ - + \ No newline at end of file diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 77% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml index 34a5af5910..d09c19b545 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/base_classes/NXdeflector.nxdl.xml @@ -1,10 +1,10 @@ - + + + + Electronic level probed in X-ray spectroscopy or resonance experiments. + + + + Symbol of the chemical element. + + For each, the atomic number, common English name, and standard atomic weight are also given. + + + + + Z=1, name="hydrogen", standard_atomic_weight=1.0078 + + + + + Z=2, name="helium", standard_atomic_weight=4.0026 + + + + + Z=3, name="lithium", standard_atomic_weight=6.94 + + + + + Z=4, name="beryllium", standard_atomic_weight=9.0122 + + + + + Z=5, name="boron", standard_atomic_weight=10.81 + + + + + Z=6, name="carbon", standard_atomic_weight=12.011 + + + + + Z=7, name="nitrogen", standard_atomic_weight=14.007 + + + + + Z=8, name="oxygen", standard_atomic_weight=15.999 + + + + + Z=9, name="fluorine", standard_atomic_weight=18.9984 + + + + + Z=10, name="neon", standard_atomic_weight=20.1797 + + + + + Z=11, name="sodium", standard_atomic_weight=22.9898 + + + + + Z=12, name="magnesium", standard_atomic_weight=24.305 + + + + + Z=13, name="aluminum", standard_atomic_weight=26.9815 + + + + + Z=14, name="silicon", standard_atomic_weight=28.085 + + + + + Z=15, name="phosphorus", standard_atomic_weight=30.9738 + + + + + Z=16, name="sulfur", standard_atomic_weight=32.06 + + + + + Z=17, name="chlorine", standard_atomic_weight=35.453 + + + + + Z=18, name="argon", standard_atomic_weight=39.948 + + + + + Z=19, name="potassium", standard_atomic_weight=39.0983 + + + + + Z=20, name="calcium", standard_atomic_weight=40.078 + + + + + Z=21, name="scandium", standard_atomic_weight=44.9559 + + + + + Z=22, name="titanium", standard_atomic_weight=47.867 + + + + + Z=23, name="vanadium", standard_atomic_weight=50.9415 + + + + + Z=24, name="chromium", standard_atomic_weight=51.996 + + + + + Z=25, name="manganese", standard_atomic_weight=54.938 + + + + + Z=26, name="iron", standard_atomic_weight=55.845 + + + + + Z=27, name="cobalt", standard_atomic_weight=58.9332 + + + + + Z=28, name="nickel", standard_atomic_weight=58.6934 + + + + + Z=29, name="copper", standard_atomic_weight=63.546 + + + + + Z=30, name="zinc", standard_atomic_weight=65.38 + + + + + Z=31, name="gallium", standard_atomic_weight=69.72 + + + + + Z=32, name="germanium", standard_atomic_weight=72.63 + + + + + Z=33, name="arsenic", standard_atomic_weight=74.9216 + + + + + Z=34, name="selenium", standard_atomic_weight=78.971 + + + + + Z=35, name="bromine", standard_atomic_weight=79.904 + + + + + Z=36, name="krypton", standard_atomic_weight=83.798 + + + + + Z=37, name="rubidium", standard_atomic_weight=85.4678 + + + + + Z=38, name="strontium", standard_atomic_weight=87.62 + + + + + Z=39, name="yttrium", standard_atomic_weight=88.9058 + + + + + Z=40, name="zirconium", standard_atomic_weight=91.224 + + + + + Z=41, name="niobium", standard_atomic_weight=92.9064 + + + + + Z=42, name="molybdenum", standard_atomic_weight=95.95 + + + + + Z=43, name="technetium", standard_atomic_weight=97.907 + + + + + Z=44, name="ruthenium", standard_atomic_weight=101.07 + + + + + Z=45, name="rhodium", standard_atomic_weight=102.906 + + + + + Z=46, name="palladium", standard_atomic_weight=106.42 + + + + + Z=47, name="silver", standard_atomic_weight=107.868 + + + + + Z=48, name="cadmium", standard_atomic_weight=112.414 + + + + + Z=49, name="indium", standard_atomic_weight=114.818 + + + + + Z=50, name="tin", standard_atomic_weight=118.71 + + + + + Z=51, name="antimony", standard_atomic_weight=121.76 + + + + + Z=52, name="tellurium", standard_atomic_weight=127.6 + + + + + Z=53, name="iodine", standard_atomic_weight=126.905 + + + + + Z=54, name="xenon", standard_atomic_weight=131.293 + + + + + Z=55, name="cesium", standard_atomic_weight=132.905 + + + + + Z=56, name="barium", standard_atomic_weight=137.327 + + + + + Z=57, name="lanthanum", standard_atomic_weight=138.905 + + + + + Z=58, name="cerium", standard_atomic_weight=140.116 + + + + + Z=59, name="praseodymium", standard_atomic_weight=140.908 + + + + + Z=60, name="neodymium", standard_atomic_weight=144.242 + + + + + Z=61, name="promethium", standard_atomic_weight=145.0 + + + + + Z=62, name="samarium", standard_atomic_weight=150.36 + + + + + Z=63, name="europium", standard_atomic_weight=151.96 + + + + + Z=64, name="gadolinium", standard_atomic_weight=157.25 + + + + + Z=65, name="terbium", standard_atomic_weight=158.925 + + + + + Z=66, name="dysprosium", standard_atomic_weight=162.5 + + + + + Z=67, name="holmium", standard_atomic_weight=164.93 + + + + + Z=68, name="erbium", standard_atomic_weight=167.259 + + + + + Z=69, name="thulium", standard_atomic_weight=168.934 + + + + + Z=70, name="ytterbium", standard_atomic_weight=173.045 + + + + + Z=71, name="lutetium", standard_atomic_weight=174.967 + + + + + Z=72, name="hafnium", standard_atomic_weight=178.49 + + + + + Z=73, name="tantalum", standard_atomic_weight=180.948 + + + + + Z=74, name="tungsten", standard_atomic_weight=183.84 + + + + + Z=75, name="rhenium", standard_atomic_weight=186.207 + + + + + Z=76, name="osmium", standard_atomic_weight=190.23 + + + + + Z=77, name="iridium", standard_atomic_weight=192.217 + + + + + Z=78, name="platinum", standard_atomic_weight=195.084 + + + + + Z=79, name="gold", standard_atomic_weight=196.967 + + + + + Z=80, name="mercury", standard_atomic_weight=200.592 + + + + + Z=81, name="thallium", standard_atomic_weight=204.383 + + + + + Z=82, name="lead", standard_atomic_weight=207.2 + + + + + Z=83, name="bismuth", standard_atomic_weight=208.98 + + + + + Z=84, name="polonium", standard_atomic_weight=209.0 + + + + + Z=85, name="astatine", standard_atomic_weight=210.0 + + + + + Z=86, name="radon", standard_atomic_weight=222.0 + + + + + Z=87, name="francium", standard_atomic_weight=223.0 + + + + + Z=88, name="radium", standard_atomic_weight=226.0 + + + + + Z=89, name="actinium", standard_atomic_weight=227.0 + + + + + Z=90, name="thorium", standard_atomic_weight=232.038 + + + + + Z=91, name="protactinium", standard_atomic_weight=231.036 + + + + + Z=92, name="uranium", standard_atomic_weight=238.029 + + + + + Z=93, name="neptunium", standard_atomic_weight=237.048 + + + + + Z=94, name="plutonium", standard_atomic_weight=239.052 + + + + + Z=95, name="americium", standard_atomic_weight=243.0 + + + + + Z=96, name="curium", standard_atomic_weight=247.0 + + + + + Z=97, name="berkelium", standard_atomic_weight=247.0 + + + + + Z=98, name="californium", standard_atomic_weight=251.0 + + + + + Z=99, name="einsteinium", standard_atomic_weight=252 + + + + + Z=100, name="fermium", standard_atomic_weight=257 + + + + + Z=101, name="mendelevium", standard_atomic_weight=258 + + + + + Z=102, name="nobelium", standard_atomic_weight=259 + + + + + Z=103, name="lawrencium", standard_atomic_weight=266 + + + + + Z=104, name="rutherfordium", standard_atomic_weight=267 + + + + + Z=105, name="dubnium", standard_atomic_weight=268 + + + + + Z=106, name="seaborgium", standard_atomic_weight=269 + + + + + Z=107, name="bohrium", standard_atomic_weight=270 + + + + + Z=108, name="hassium", standard_atomic_weight=269 + + + + + Z=109, name="meitnerium", standard_atomic_weight=278 + + + + + Z=110, name="darmstadtium", standard_atomic_weight=281 + + + + + Z=111, name="roentgenium", standard_atomic_weight=282 + + + + + Z=112, name="copernicium", standard_atomic_weight=285 + + + + + Z=113, name="nihonium", standard_atomic_weight=286 + + + + + Z=114, name="flerovium", standard_atomic_weight=289 + + + + + Z=115, name="moscovium", standard_atomic_weight=290 + + + + + Z=116, name="livermorium", standard_atomic_weight=293 + + + + + Z=117, name="tennessine", standard_atomic_weight=294 + + + + + Z=118, name="oganesson", standard_atomic_weight=294 + + + + + + + IUPAC symbol of the electronic level. + For each level, the electronic orbital configuration is also given + + For reference, see Jenkins, R., Manne, R., Robin, R., & Senemaud, C. (1991). + IUPAC—nomenclature system for x-ray spectroscopy. X-Ray Spectrometry, 20(3), 149-155. + + + + + same as 1s in level_xray + + + + + 2s + + + + + 2p_{1/2} + + + + + 2p_{3/2} + + + + + 3s + + + + + 3p_{1/2} + + + + + 3p_{3/2} + + + + + 3d_{3/2} + + + + + 3d_{5/2} + + + + + 4s + + + + + 4p_{1/2} + + + + + 4p_{3/2} + + + + + 4d_{3/2} + + + + + 4d_{5/2} + + + + + 4f_{5/2} + + + + + 4f_{7/2} + + + + + 5s + + + + + 5p_{1/2} + + + + + 5p_{3/2} + + + + + 5d_{3/2} + + + + + 5d_{5/2} + + + + + 5f_{5/2} + + + + + 5f_{7/2} + + + + + 6s + + + + + 6p_{1/2} + + + + + 6p_{3/2} + + + + + + + Electronic orbital configuration of the electronic level. + + + + + same as K in level_xray + + + + + L1 + + + + + L3 + + + + + M1 + + + + + M2 + + + + + M3 + + + + + M4 + + + + + M5 + + + + + N1 + + + + + N2 + + + + + N3 + + + + + N4 + + + + + N5 + + + + + N6 + + + + + N7 + + + + + O1 + + + + + O2 + + + + + O3 + + + + + O4 + + + + + O5 + + + + + O6 + + + + + O7 + + + + + P1 + + + + + P2 + + + + + P3 + + + + + + + description of X-ray electronic level + + + + + .. 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/NXelectronanalyser.nxdl.xml b/base_classes/NXelectronanalyser.nxdl.xml new file mode 100644 index 0000000000..bcf01224d2 --- /dev/null +++ b/base_classes/NXelectronanalyser.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of fast axes (axes acquired simultaneously, without scanning a + physical quantity) + + + + + Number of slow axes (axes acquired scanning a physical quantity) + + + + + Number of data points in the transmission function. + + + + + Basic class for describing a electron analyzer. + + This concept is related to term `12.59`_ of the ISO 18115-1:2023 standard. + + .. _12.59: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.59 + + + + Free text description of the type of the detector + + + + + Name or model of the equipment + + + + Acronym or other shorthand name + + + + + + Work function of the electron analyser. + + The work function of a uniform surface of a conductor is the minimum energy required to remove + an electron from the interior of the solid to a vacuum level immediately outside the solid surface. + + The kinetic energy :math:`E_K` of a photoelectron emitted from an energy-level with binding energy + :math:`E_B` below the Fermi level is given by :math:`E_K = h\nu - E_B - W = h\nu - E_B - e \phi_{\mathrm{sample}}`. + Here, :math:`W = e \phi_{\mathrm{sample}}` is the work function of the sample surface (with the potential difference :math:`\phi_{\mathrm{sample}}` + between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the vacuum just outside the surface). + + In PES measurements, the sample and the spectrometer (with work function :math:`\phi_{\mathrm{spectr.}}`) + are electrically connected and therefore their Fermi levels are aligned. Due to the difference in local + vacuum level between the sample and spectrometer, there exists an electric potential difference (contact potential) + :math:`\Delta\phi = \phi_{\mathrm{sample}} - \phi_{\mathrm{spectr.}}`. The measured kinetic energy of + a photoelectron in PES is therefore given by + :math:`E_K^{\mathrm{meas.}} = h\nu - E_B + \Delta \phi = h\nu - E_B - e \phi_{\mathrm{spectr.}}`. + As a result, the measured kinetic energy :math:`E_K^{\mathrm{meas.}}` of a photoelectron is `independent` + of the sample work function. Nonetheless, the work function :math:`\phi_s` needs to be known to + accurately determine the binding energy scale. + + + + + Energy range of the voltage supplies. This influences the noise of the supplies, + and thereby the energy resolution. + + + + + Energy resolution of the analyser with the current setting. May be linked from an + NXcalibration. + + + + + + + + + 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 electron analyser at a specified energy + value to that energy value. + + This concept is related to term `10.7`_ of the ISO 18115-1:2023 standard. + + .. _10.7: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.7 + + + + + + Momentum resolution of the electron analyser (FWHM) + + + + + + + + + + + + Angular resolution of the electron analyser (FWHM) + + + + + + + + + + + + Spatial resolution of the electron analyser (Airy disk radius) + + This concept is related to term `10.14`_ of the ISO 18115-1:2023 standard. + + .. _10.14: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:10.15 + + + + + + + + + + + + List of the axes that are acquired simultaneously by the detector. + These refer only to the experimental variables recorded by the electron analyser. + Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. + + .. csv-table:: Examples + :header: "Mode", "fast_axes", "slow_axes" + + Hemispherical in ARPES mode, "['energy', 'kx']","" + "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] + "Tof", "['energy', 'kx', 'ky']","" + "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" + + Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. + If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. + + + + + + + + List of the axes that are acquired by scanning a physical parameter, listed in + order of decreasing speed. See fast_axes for examples. + + + + + + + + Transmission function of the electron analyser. + + The transmission function (TF) specifies the detection efficiency per solid angle for electrons of + different kinetic energy passing through the electron analyser. It depends on the spectrometer + geometry as well as operation settings such as lens mode and pass energy. + The transmission function is usually given as relative intensity vs. kinetic energy. + + The TF is used for calibration of the intensity scale in quantitative XPS. Without proper + transmission correction, a comparison of results measured from the same sample using different + operating modes for an instrument would show significant variations in atomic + concentrations. + + This concept is related to term `7.15`_ of the ISO 18115-1:2023 standard. + + .. _7.15: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:7.15 + + + + + + + + + + + + + + Kinetic energy values + + + + + + + + Relative transmission efficiency for the given kinetic energies + + + + + + + + + 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 + + + + + Describes the energy dispersion section + + + + + Describes the spin dispersion section + + + + + Describes the electron detector + + + + + Deflectors outside the main optics ensembles described by the subclasses + + + + + Individual lenses outside the main optics ensembles described by the subclasses + + + + + + Any other resolution not explicitly named in this base class. + + + diff --git a/base_classes/NXenergydispersion.nxdl.xml b/base_classes/NXenergydispersion.nxdl.xml new file mode 100644 index 0000000000..8e90246e25 --- /dev/null +++ b/base_classes/NXenergydispersion.nxdl.xml @@ -0,0 +1,209 @@ + + + + + + Subclass of NXelectronanalyser to describe the energy dispersion section of a + photoelectron analyser. + + + + Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, + mirror, retarding grid, etc. + + + + + Mean kinetic energy of the electrons in the energy-dispersive portion of the analyser. + This term should be used for hemispherical analysers. + + This concept is related to term `12.63`_ of the ISO 18115-1:2023 standard. + + .. _12.63: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.63 + + + + + Kinetic energy set for the dispersive analyzer section. Can be either the set kinetic energy, + or the whole calibrated energy axis of a scan. + + + + + Drift energy for time-of-flight energy dispersive elements. + + + + + Center of the energy window + + + + + The interval of transmitted energies. It can be two different things depending + on whether the scan is fixed or swept. With a fixed scan it is a 2 vector + containing the extrema of the transmitted energy window (smaller number first). + With a swept scan of m steps it is a 2xm array of windows one for each + measurement point. + + + + + Diameter of the dispersive orbit + + + + + Radius of the dispersive orbit + + + + + Way of scanning the energy axis + + + + + constant :math:`\Delta E` mode, where the electron retardation (i.e., the fraction of pass energy to + kinetic energy, :math:`R = (E_K - W/E_p)`, is scanned, but the pass energy :math:`E_p` is kept constant. + Here, :math:`W = e \phi` is the spectrometer work function (with the potential difference :math:`\phi_{\mathrm{sample}}` + between the electrochemical potential of electrons in the bulk and the electrostatic potential of an electron in the + vacuum just outside the surface). + + This mode is often used in XPS/UPS because the energy resolution does not change with + changing energy (due to the constant pass energy). + + Synonyms: constant :math:`\Delta E` mode, constant analyser energy mode, CAE + mode, FAT mode + + This concept is related to term `12.64`_ of the ISO 18115-1:2023 standard. + + .. _12.64: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.64 + + + + + constant :math:`\Delta E/E` mode, where the pass energy is scanned such that the electron retardation + ratio is constant. In this mode, electrons of all energies are decelerated with this same + fixed factor. Thus, the pass energy is proportional to the kinetic energy. This mode is often + used in Auger electron spectroscopy (AES) to improve S/N for high-KE electrons, but this + leads to a changing energy resolution (:math:`\Delta E \sim E_p`) at different kinetic energies. + It can however also be used in XPS. + + Synonyms: constant :math:`\Delta E/E` mode, constant retardation ratio mode, CRR + mode, FRR mode + + This concept is related to term `12.66`_ of the ISO 18115-1:2023 standard. + + .. _12.66: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.66 + + + + + In the fixed energy (FE) mode, the intensity for one single kinetic energy is measured for a + specified time. This mode is particulary useful during setup or alignment of the + electron analyzer, for analysis of stability of the excitation source or for sample + alignment. + + Since the mode measures intensity as a function of time, the difference in channel signals + is not of interest. Therefore, the signals from all channels are summed. + + Synonyms: FE mode + + + + + Snapshot mode does not involve an energy scan and instead collects data from all channels of + the detector without averaging. The resulting spectrum reflects the energy distribution of + particles passing through the analyzer using the current settings. This mode is commonly used + to position the detection energy at the peak of a peak and record the signal, enabling faster + data acquisition within a limited energy range compared to FAT. Snapshot measurements are + particularly suitable for CCD and DLD detectors, which have multiple channels and can accurately + display the peak shape. While five or nine-channel detectors can also be used for snapshot + measurements, their energy resolution is relatively lower. + + + + + In dither acquisition mode, the kinetic energy of the analyzer is randomly varied by a small value + around a central value and at fixed pass energy. This allows reducing or removing inhomogeneities + of the detector efficiency, such as e.g. imposed by a mesh in front of the detector. + Mostly relevant for CCD/DLD type of detectors. + + + + + + + Length of the tof drift electrode + + + + + Size, position and shape of a slit in dispersive analyzer, e.g. entrance and + exit slits. + + + + + Deflectors in the energy dispersive section + + + + + Individual lenses in the energy dispersive section + + + + + + Specifies the position of the energy dispesive elemeent 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 energy dispersive element 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/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index 7c2950340b..8f8f323ca9 100755 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -98,32 +98,62 @@ 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. - - + + UUID identifier for the measurement. Version of UUID used - + + + City and country where the experiment took place + + + + Start time of experimental run that includes the current + measurement, for example a beam time. + + + + + End time of experimental run that includes the current + measurement, for example a beam time. + + + + + Name of the institution hosting the facility + + + + + Name of the experimental facility + + + + + Name of the laboratory or beamline + + Reserved for future use by NIAC. @@ -227,4 +257,4 @@ - + \ No newline at end of file diff --git a/base_classes/NXfit.nxdl.xml b/base_classes/NXfit.nxdl.xml new file mode 100644 index 0000000000..b0d77f2cec --- /dev/null +++ b/base_classes/NXfit.nxdl.xml @@ -0,0 +1,199 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) + + + + + Description of a fit procedure. + + + + Human-readable label for this fit procedure. + + + + + Input data and results of the fit. + + + + Position values along one or more data dimensions (to hold the + values for the independent variable for this fit procedure). + + + + The ``input_dependent`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``input_dependent`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + + + + + + Independent input axis for this fit procedure. + + + + The ``input_independent`` field must have the same rank (``dimRank``) + as the ``input_dependent`` field. Each individual dimension of ``input_independent`` + must have the same number of points as the corresponding dimension in + the ``input_dependent`` field. + + + + + + Resulting envelope of applying the `global_fit_function` with its parameter to the data stored + in `input_independent`. + + + + The ``envelope`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``envelope`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + + + + + + Difference between the envelope and the `input_independent` data to be fitted. + + + + The ``residual`` field must have the same rank (``dimRank``) + as the ``input_independent`` field. Each individual dimension of ``residual`` + must have the same number of points as the corresponding dimension in + the ``input_independent`` field. + + + + + + + One peak of the peak model. + If there is no characteristic name for each peak component, is envisioned that peaks + are labeled as peak_0, peak_1, and so on. + + + + Total area under the curve (can also be used for the total area minus any + background values). + + + + + Relative sensitivity for this peak, to be used for quantification in + an NXprocess. + + As an example, in X-ray spectroscopy could depend on the energy scale + (see position), the ionization cross section, and the element probed. + + + + + Relative area of this peak compared to other peaks. + + The relative area can simply be derived by dividing the total_area by the + total area of all peaks or by a more complicated method (e.g., by + additionally dividing by the relative sensitivity factors). Details shall + be given in `global_fit_function`. + + + + + + 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 + as background_0, background_1, and so on. + + + + + Function used to describe the overall fit to the data, taking into account the parameters of the + individual `NXpeak` and `NXfit_background` components. + + + + Oftentimes, if the peaks and fit backgrounds are defined independently (i.e, with their own + parameter sets), the resulting global fit is a function of the form + :math:`model = peak_1(p_1) + peak2(p_2) + backgr(p_3).`, where each :math:`p_x` describes the + set of parameters for one peak/background. + + + + + + Function used to optimize the parameters during peak fitting. + + + + Description of the method used to optimize the parameters during peak fitting. + Examples: + - least squares + - non-linear least squares + - Levenberg-Marquardt algorithm (damped least-squares) + - linear regression + - Bayesian linear regression + + + + + For the optimization, the formula is any optimization process on the `global_fit_function` given above. + As an example, for a linear least squared algorithm on independent components, the formula of the error_function + would be :math:`LLS(peak_1(p_1) + peak2(p_2) + backgr(p_3))`, where each :math:`p_x` describes the set + of parameters for one peak/background. + + It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). + + + + + + Figure-of-merit to determine the goodness of fit, i.e., how well the peak model + fits the measured observations. + + This value (which is a single number) is oftenused to guide adjustments to the + fitting parameters in the peak fitting process. + + + + Metric used to determine the goodness of fit. Examples include: + - :math:`\chi^2`, the squared sum of the sigma-weighted residuals + - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom + - :math:`R^2`, the coefficient of determination + + + + diff --git a/base_classes/NXfit_background.nxdl.xml b/base_classes/NXfit_background.nxdl.xml new file mode 100644 index 0000000000..9aa09b7695 --- /dev/null +++ b/base_classes/NXfit_background.nxdl.xml @@ -0,0 +1,93 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) + + + + + Description of the background for an NXfit model. + + + + Human-readable label which specifies which concept/entity + the background represents/identifies. + + + + + + Position values along one or more data dimensions (to hold the + values for the independent variable). + + + + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + + + + + + This array holds the intensity/count values of the fitted background + at each position. + + + + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + + + + + + + The functional form of the background. + + + + + .. 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/NXfit_function.nxdl.xml b/base_classes/NXfit_function.nxdl.xml new file mode 100644 index 0000000000..bbf08ab3d7 --- /dev/null +++ b/base_classes/NXfit_function.nxdl.xml @@ -0,0 +1,71 @@ + + + + + + This describes a fit function that is used to fit data to any functional form. + + A fit function is used to describe a set of data :math:`y_k, k = 1 ... M`, which are collected as a function + of one or more independent variables :math:`x` at the points :math:`x_k`. The fit function :math:`f` describes + these data in an approximative way as :math:`y_k \approx f(a_0, . . . a_n, x_k)`, + where :math:`a_i, i = 0 . . . n` are the *fit parameters* (which are stored the instances of ``NXfit_parameter``). + + + + Human-readable description of this fit function. + + + + + Description of the mathematical formula of the function, taking into account the instances of ``TERM`` in ``fit_parameters``. + + + + + + + + A parameter for a fit function. + This would typically be a variable that + is optimized in a fit. + + + + A description of what this parameter represents. + + + + + + The minimal value of the parameter, to be used as a constraint during fitting. + + + + + The maximal value of the parameter, to be used as a constraint during fitting. + + + + + diff --git a/base_classes/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..e878d25e35 --- /dev/null +++ b/base_classes/NXlens_em.nxdl.xml @@ -0,0 +1,96 @@ + + + + + + + + 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>`_ + + + + + 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. + + + + + + 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. + + + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..ae922457ae --- /dev/null +++ b/base_classes/NXmanipulator.nxdl.xml @@ -0,0 +1,255 @@ + + + + + + Extension of NXpositioner to include fields to describe the use of manipulators. + + + + Name of the manipulator. + + + + + A description of the manipulator. + + + + + Type of manipulator, Hexapod, Rod, etc. + + + + + 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 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. + + + + + + + + Temperature sensor measuring the sample temperature. + + + + + + + + + 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. + + + + + + + Device to heat the sample. + + + + + + + + + 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 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. + + + + + + + + Amperemeter measuring the drain current of the sample and sample holder. + + + + + + + + + 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. + + + + + + + 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 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. + + + + + + + + Sensor measuring the voltage applied to sample and sample holder. + + + + + + + + + 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. + + + + + + + Any additional actuators on the manipulator. + + + + + Any additional sensors on 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/base_classes/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml new file mode 100644 index 0000000000..4fdd173471 --- /dev/null +++ b/base_classes/NXpeak.nxdl.xml @@ -0,0 +1,99 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Rank of the dependent and independent data arrays (for + multidimensional/multivariate fit.) + + + + + Base class for describing a peak, its functional form, and support values + (i.e., the discretization (points) at which the function has been evaluated). + + + + Human-readable label which specifies which concept/entity + the peak represents/identifies. + + + + + + Position values along one or more data dimensions (to hold the + values for the independent variable). + + + + The ``position`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``intensity`` field. + + + + + + This array holds the intensity/count values of the fitted peak at each position. + + + + The ``intensity`` field must have the same rank (``dimRank``) + as the ``intensity`` field. Each individual dimension of ``position`` + must have the same number of points as the corresponding dimension in + the ``position`` field. + + + + + + + The functional form of the peak. This could be a Gaussian, Lorentzian, + Voigt, etc. + + + + + Total area under the curve. + + + + + .. 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/NXpid_controller.nxdl.xml b/base_classes/NXpid_controller.nxdl.xml new file mode 100644 index 0000000000..2677d72d20 --- /dev/null +++ b/base_classes/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/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/base_classes/NXrotation_set.nxdl.xml b/base_classes/NXrotation_set.nxdl.xml new file mode 100644 index 0000000000..3f47e3fb89 --- /dev/null +++ b/base_classes/NXrotation_set.nxdl.xml @@ -0,0 +1,256 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The cardinality of the set, i.e. the number of value tuples. + + + + + How many phases with usually different crystal and symmetry are distinguished. + + + + + Base class to detail a set of rotations, orientations, and disorientations. + + For getting a more detailed insight into the discussion of the + parameterized description of orientations in materials science see: + + * `H.-J. Bunge <https://doi.org/10.1016/C2013-0-11769-2>`_ + * `T. B. Britton et al. <https://doi.org/10.1016/j.matchar.2016.04.008>`_ + * `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_ + * `A. Morawiec <https://doi.org/10.1007/978-3-662-09156-2>`_ + + Once orientations are defined, one can continue to characterize the + misorientation and specifically the disorientation. The misorientation describes + the rotation that is required to register the lattices of two oriented objects + (like crystal lattice) into a crystallographic equivalent orientation: + + * `R. Bonnet <https://doi.org/10.1107/S0567739480000186>`_ + + + + Reference to an instance of :ref:`NXcoordinate_system_set` which contextualizes + how the here reported parameterized quantities can be interpreted. + + + + + + Point group which defines the symmetry of the crystal. + + This has to be at least a single string. If crystal_symmetry is not + provided point group 1 is assumed. + + In the case that misorientation or disorientation fields are used + and the two crystal sets resolve for phases with a different + crystal symmetry, this field has to encode two string. + In this case the first string is for phase A the second one for phase B. + An example of this most complex case is the description of the + disorientation between crystals adjoining a hetero-phase boundary. + + + + + + + + Point group which defines an assumed symmetry imprinted upon processing + the material/sample which could give rise to or may justify to use a + simplified description of rotations, orientations, misorientations, + and disorientations via numerical procedures that are known as + symmetrization. + + If sample_symmetry is not provided point group 1 is assumed. + + The traditionally used symmetrization operations within the texture + community in Materials Science, though, are thanks to methodology and + software improvements no longer strictly needed. Therefore, users are + encouraged to set the sample_symmetry to 1 (triclinic) and thus assume + there is no justification to assume the imprinting of additional + symmetry because of the processing. + + In practice one often faces situations where indeed these assumed + symmetries are anyway not fully observed, and thus an accepting of + eventual inaccuracies just for the sake of reporting a simplified + symmetrized description should be avoided. + + + + + + + + The set of rotations expressed in quaternion parameterization considering + crystal_symmetry and sample_symmetry. Rotations which should be + interpreted as antipodal are not marked as such. + + + + + + + + + The set of rotations expressed in Euler angle parameterization considering + the same applied symmetries as detailed for the field rotation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + True for all those value tuples which have assumed antipodal symmetry. + False for all others. + + + + + + + + The set of orientations expressed in quaternion parameterization and + obeying symmetry for equivalent cases as detailed in crystal_symmetry + and sample_symmetry. The supplementary field is_antipodal can be used + to mark orientations with the antipodal property. + + + + + + + + + The set of orientations expressed in Euler angle parameterization following + the same assumptions like for orientation_quaternion. + To interpret Euler angles correctly, it is necessary to inspect the + conventions behind depends_on to resolve which of the many Euler-angle + conventions possible (Bunge ZXZ, XYZ, Kocks, Tait, etc.) were used. + + + + + + + + + + + The set of misorientations expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Misorientation angular argument (eventually signed) following the same + symmetry assumptions as expressed for the field misorientation_quaternion. + + + + + + + + Misorientation axis (normalized) and signed following the same + symmetry assumptions as expressed for the field misorientation_angle. + + + + + + + + + + The set of disorientation expressed in quaternion parameterization + obeying symmetry operations for equivalent misorientations + as defined by crystal_symmetry and sample_symmetry. + + + + + + + + + Disorientation angular argument (should not be signed, see + `D. Rowenhorst et al. <https://doi.org/10.1088/0965-0393/23/8/083501>`_) + following the same symmetry assumptions as expressed for the field + disorientation_quaternion. + + + + + + + + Disorientation axis (normalized) following the same symmetry assumptions + as expressed for the field disorientation_angle. + + + + + + + + diff --git a/base_classes/NXsample_component_set.nxdl.xml b/base_classes/NXsample_component_set.nxdl.xml new file mode 100644 index 0000000000..aa3a0e794f --- /dev/null +++ b/base_classes/NXsample_component_set.nxdl.xml @@ -0,0 +1,78 @@ + + + + + + + + number of components + + + + + Set of sample components and their configuration. + + The idea here is to have a united place for all materials descriptors that are not + part of the individual sample components, but rather their configuration. + + + + Array of strings referring to the names of the NXsample_components. + The order of these components serves as an index (starting at 1). + + + + + Concentration of each component + + + + + + + + Volume fraction of each component + + + + + + + + Scattering length density of each component + + + + + + + + Each component set can contain multiple components. + + + + + For description of a sub-component set. Can contain multiple components itself. + + + diff --git a/contributed_definitions/NXspindispersion.nxdl.xml b/base_classes/NXspindispersion.nxdl.xml similarity index 100% rename from contributed_definitions/NXspindispersion.nxdl.xml rename to base_classes/NXspindispersion.nxdl.xml diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index 2a95f45019..726080c202 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -83,7 +83,7 @@ Extended title for entry - + Unique identifier for the experiment, defined by the facility, possibly linked to the proposals @@ -95,13 +95,13 @@ 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. @@ -185,5 +185,4 @@ - - + \ No newline at end of file diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index c2276f3a93..0000000000 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,137 +0,0 @@ - - - - - - Container to hold different coordinate systems conventions. - - It is the purpose of this base class to define these conventions and - offer a place to store mappings between different coordinate systems - which are relevant for the interpretation of the data described - by the application definition and base class instances. - - For each Cartesian coordinate system users should use a set of - NXtransformations: - - * These should define the three base vectors. - * The location of the origin. - * The affine transformations which bring each axis of this coordinate system - into registration with the McStas coordinate system. - * Equally, affine transformations should be given for the inverse mapping. - - As an example one may take an experiment or computer simulation where - there is a laboratory (lab) coordinate system, a sample/specimen coordinate - system, a crystal coordinate system, and additional coordinate systems, - which are eventually attached to components of the instrument. - - If no additional transformation is specified in this group or if an - instance of an NXcoordinate_system_set is absent it should be assumed - the so-called McStas coordinate system is used. - - Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. - This is a Cartesian coordinate system whose z axis points along the neutron - propagation axis. The systems y axis is vertical up, while the x axis points - left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. - - Within each NXtransformations a depends_on section is required. The depends_on - field specifies if the coordinate system is the root/reference - (which is indicated by writing "." in the depends_on section.) - - - - - A group of transformations which specify: - - * Three base vectors of the coordinate system. - * Origin of the coordinate system. - * A depends_on keyword. Its value can be "." or the name of an - NXtransformations instance which needs to exist in the - NXcoordinate_system_set instance. - * If the coordinate system is the reference one it has to be named - reference. - - In case of having more than one NXtransformations there has to be for - each additional coordinate system, i.e. the one not the reference: - - * A set of translations and rotations which map each base vector to the reference. - * A set of translations and rotations which map each reference base vector - to the coordinate system. - - The NXtransformations for these mappings need to be formatted - according to the descriptions in NXtransformations. - - - - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index c2bfe957c6..0000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - 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 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. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. 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 and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - 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. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (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. - - - - - 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`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(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. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - 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. - - - - - diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml deleted file mode 100644 index 4a030c6844..0000000000 --- a/contributed_definitions/NXpeak.nxdl.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of support points - - - - - Description of peaks, their functional form or measured support. - - - - Human-readable identifier to specify which concept/entity - the peak represents/identifies. - - - - - Is the peak described analytically via a functional form - or is it empirically defined via measured/reported - intensity/counts as a function of an independent variable. - - If the functional form is not empirical or gaussian, users - should enter other for the peak_model and add relevant details - in the NXcollection. - - - - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the position values for the independent variable. - - - - - - - - In the case of an empirical description of the peak and its shoulders, - this array holds the intensity/count values at each position. - - - - - - - - In the case of an analytical description (or if peak_model is other) this - collection holds parameter of (and eventually) the functional form. - For example in the case of Gaussians mu, sigma, cut-off values, - and background intensity are relevant parameter. - - - diff --git a/contributed_definitions/NXpid.nxdl.xml b/contributed_definitions/NXpid.nxdl.xml deleted file mode 100644 index 594afbfa45..0000000000 --- a/contributed_definitions/NXpid.nxdl.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - Contains the settings of a PID controller. - - - - Description of how the Process Value for the PID controller is produced by sensor(s) in the setup. - - For example, a set of sensors could be averaged over before feeding it back into the loop. - - - - - The sensor representing the Process Value used in the feedback loop for the PID. - - In case multiple sensors were used, this NXsensor should contain the proper calculated/aggregated value. - - - - - The actual timeseries data fed back to the PID loop. - - - - - - - The Setpoint(s) used as an input for the PID controller. - - It can also be a link to an NXsensor.value field. - - - - - Proportional term. The proportional term produces an output value - that is proportional to the current error value. - The proportional response can be adjusted by multiplying the error - by a constant Kp, called the proportional gain constant. - - - - - The contribution from the integral term is proportional to both - the magnitude of the error and the duration of the error. - The integral in a PID controller is the sum of the instantaneous - error over time and gives the accumulated offset that should have - been corrected previously. The accumulated error is then - multiplied by the integral gain (Ki) and added to the - controller output. - - - - - The derivative of the process error is calculated by determining - the slope of the error over time and multiplying this rate of - change by the derivative gain K_d. The magnitude of the - contribution of the derivative term to the overall control - action is termed the derivative gain, K_d - - -