diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml new file mode 100644 index 0000000000..5769036aff --- /dev/null +++ b/applications/NXellipsometry.nxdl.xml @@ -0,0 +1,422 @@ + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + This is the application definition describing ellipsometry experiments. + + Such experiments may be as simple as identifying how a reflected + beam of light with a single wavelength changes its polarization state, + to a variable angle spectroscopic ellipsometry experiment. + + The application definition specifies optical spectroscopy (NXopt), by extending + the terms and setting specific requirements. + + Information on ellipsometry is provided, e.g. in: + + * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, + John Wiley & Sons, 2007. + * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, + North-Holland Publishing Company, 1977. + * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, + William Andrew, 2005. + + Open access sources: + + * https://www.angstromadvanced.com/resource.asp + * https://pypolar.readthedocs.io/en/latest/ + + Review articles: + + * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", + J. Phys. D: Appl. Phys. 32, R45 (1999), + https://doi.org/10.1088/0022-3727/32/9/201 + * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", + Thin Solid Films 571, 334-344 (2014), + https://doi.org/10.1016/j.tsf.2014.03.056 + * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", + Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, + (3 October 1997), + https://doi.org/10.1117/12.283870 + * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", + Thin Solid Films 233, 96-111 (1993), + https://doi.org/10.1016/0040-6090(93)90069-2 + * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", + Adv. Opt. Techn., (2022), + https://doi.org/10.1515/aot-2022-0016 + + + + + An application definition for ellipsometry. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + + + + + + + + Specify the type of ellipsometry. + + + + + + + + + + + + + + If the ellipsometry_experiment_type is `other`, a name should be specified here. + + + + + Properties of the ellipsometry equipment. + + + + What type of ellipsometry was used? See Fujiwara Table 4.2. + + + + + + + + + + + + + + + + + + + + If the ellipsometer_type is `other`, a specific ellipsometry_type" should be + added here. + + + + + Define which element rotates, e.g. polarizer or analyzer. + + + + + + + + + + + If focussing probes (lenses) were used, please state if the data + were corrected for the window effects. + + + + + + + + + + + + + + Were the recorded data corrected by the window effects of the + focussing probes (lenses)? + + + + + Specify the angular spread caused by the focussing probes. + + + + + + Properties of the rotating element defined in + 'instrument/rotating_element_type'. + + + + Define how many revolutions of the rotating element were averaged + for each measurement. If the number of revolutions was fixed to a + certain value use the field 'fixed_revolutions' instead. + + + + + Define how many revolutions of the rotating element were taken + into account for each measurement (if number of revolutions was + fixed to a certain value, i.e. not averaged). + + + + + Specify the maximum value of revolutions of the rotating element + for each measurement. + + + + + + + + Was the backside of the sample roughened? Relevant for infrared + ellipsometry. + + + + + + + Measured data, data errors, and varied parameters. This may be used to describe + indirectly derived data or data transformed between different descriptions, + such as: + Raw Data --> Psi + Delta Psi, Delta --> N,C,S + Mueller matrix --> N,C,S + Mueller matrix --> Psi, Delta + etc. + + Other types of data, such as temperature or sample location, may be saved + in a generic (NXdata) concept from NXopt, or better directly in the + location of the sample positioner or temperature sensor. + + + + An identifier to correlate data to the experimental conditions, + if several were used in this measurement; typically an index of 0-N. + + + + + Select which type of data was recorded, for example intensity, + reflectivity, transmittance, Psi and Delta etc. + It is possible to have multiple selections. The enumeration list + depends on the type of experiment and may differ for different + application definitions. + + + + + + + + + + + + + + + + Spectral values (e.g. wavelength or energy) used for the measurement. + An array of 1 or more elements. Length defines N_spectrum. Replace + 'SPECTRUM' by the physical quantity that is used, e.g. wavelength. + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Resulting data from the measurement, described by 'data_type'. + + The first dimension is defined by the number of measurements taken, + (N_measurements). The instructions on how to order the values + contained in the parameter vectors given in the doc string of + INSTRUMENT/sample_stage/environment_conditions/PARAMETER/values, + define the N_measurements parameter sets. For example, if the + experiment was performed at three different temperatures + (T1, T2, T3), two different pressures (p1, p2) and two different + angles of incidence (a1, a2), the first measurement was taken at the + parameters {a1,p1,T1}, the second measurement at {a1,p1,T2} etc. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + Specified uncertainties (errors) of the data described by 'data_type' + and provided in 'measured_data'. + + + + + + + + + If applicable, change 'unit: NX_ANY' to the appropriate NXDL unit. + If the unit of the measured data is not covered by NXDL units state + here which unit was used. + + + + + + List of links to the values of the sensors. Add a link for each + varied parameter (i.e. for each sensor). + + + + + + + + Link to the NeXus file which describes the reference data if a + reference measurement was performed. Ideally, the reference + measurement was performed using the same conditions as the actual + measurement and should be as close in time to the actual measurement + as possible. + + + + + + Commercial or otherwise defined given name of the program that was + used to generate the result file(s) with measured data and/or + metadata (in most cases, this is the same as INSTRUMENT/software). + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Website of the software. + + + + + + diff --git a/applications/NXoptical_spectroscopy.nxdl.xml b/applications/NXoptical_spectroscopy.nxdl.xml new file mode 100644 index 0000000000..cdf4a78821 --- /dev/null +++ b/applications/NXoptical_spectroscopy.nxdl.xml @@ -0,0 +1,1215 @@ + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + A general application definition of optical spectroscopy elements, which may + be used as a template to derive specialized optical spectroscopy experiments. + + Possible specializations are ellipsometry, Raman spectroscopy, photoluminescence, + reflectivity/transmission spectroscopy. + + A general optical experiment consists of (i) a light/photon source, (ii) a sample, + (iii) a detector. + + For any free text descriptions, it is recommended to enter data in english + language, as this is the most FAIR representation. + + + + + An application definition describing a general optical experiment. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + + Datetime of the start of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise, the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + + + + + Datetime of the end of the measurement. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + It is required to enter at least one of both measurement times, either "start_time" or "end_time". + + + + + A (globally persistent) unique identifier of the experiment. + (i) The identifier is usually defined by the facility, laboratory or + principal investigator. + (ii) The identifier enables to link experiments to e.g. proposals. + + + + + + Select the range of validity of this identier. + Local: Setup#1 at Institute building #2 in Room #3 + Global: Unique identification of with by unique location and unique + globally persistent time stamp. + + + + + + + + + + + An optional free-text description of the experiment. + + Users are strongly advised to parameterize the description of their experiment + by using respective groups and fields and base classes instead of writing prose + into this field. + + The reason is that such a free-text field is difficult to machine-interpret. + The motivation behind keeping this field for now is to learn how far the + current base classes need extension based on user feedback. + + + + + Specify the type of the optical experiment. + + Chose other if none of these methods are suitable. You may specify + fundamental characteristics or properties in the experimental sub-type. + + For Raman spectroscopy or ellipsometry use the respective specializations + of NXoptical_spectroscopy. + + + + + + + + + + + Specify a special property or characteristic of the experiment, which specifies + the generic experiment type. + + + + + + + + + + + If "other" was selected in "experiment_type" and/or in "experiment_sub_type", + specify the experiment here with a free text name, which is knwon in the + respective community of interest. + + + + + Description of one or more coordinate systems that are specific to the + experiment. Examples are beam centered, sample-normal centered, + laboratory-system centered, sample-stage centered, crystal-symmetry centered. + + + + + This refers to the coordinate system along the beam path. The origin and + base is defined at z=0, where the incident beam hits the sample at the surface. + + + + + This is the default NeXus coordinate system (McStas), if the transformation + does not change the coordinate system at all - i.e. it is unity. + Otherwise, by this a respective transformation of the beam + reference frame to the default reference frame could be made. i.e. + exchange of x and z coordinate, rotation of respective coordinates + towards each other. + + + + + + + Link to transformations defining the sample-normal base coordinate system, + which is defined such that the positive z-axis is parallel to the sample normal, + and the x-y-plane lies inside the sample surface. + + + + + Set of transformations, describing the orientation of the sample-normal coordinate system + with respect to the beam coordinate system (.). + + + + + + + Contact information and eventually details of at persons who + performed the measurements. This can be for example the principal + investigator or student. Examples are: name, affiliation, address, telephone + number, email, role as well as identifiers such as orcid or similar. + It is recommended to add multiple users if relevant. + + Due to data privacy concerns, there is no minimum requirement. + If no user with specific name is allowed to be given, it is required to + assign at least an affiliation + + + + + Devices or elements of the optical spectroscopy setup described with its + properties and general information. + + This includes for example: + - The beam device's or instrument's model, company, serial number, construction year, etc. + - Used software or code + - Experiment descriptive parameters as reference frames, resolution, calibration + - Photon beams with their respective properties such as angles and polarization + - Various optical beam path devices, which interact, manipulate or measure optical beams + - Characteristics of the medium surrounding the sample + - "Beam devices" for a beam path description + - Stages(NXmanipulator) + - Sensors and actuators to control or measure sample or beam properties + + + + This can be used to describe properties of a photon beam. + A beam is always defined between two beam_devices, via + "previous_device" and "next_device". + + It is required to define at least one incident beam which is incident + to the sample. You may specify if this beam parameters are acutally measured + or just nominal. + If this beam is the output of a source, chose the same + name appendix as for the NXsource instance (e.g. TYPE=532nm) + + + + Select the reliability of the respective beam characteristics. Either, + the parameters are measured via another device or method or just given + nominally via the properties of a light source properties (532nm, 100mW). + + + + + + + + + + + + + The path to the device which emitted this beam (light source or frequency doubler). + + This parameter is recommended, if the previous optical element is a photon source. + In this way, the properties of the laser or light souce can be described + and associated. + The beam should be named with the same appendix as the source, e.g., + for TYPE=532nmlaser, there should be both a NXsource named + "source_532nmlaser" and a NXbeam named "beam_532nmlaser". + + Example: /entry/instrument/source_532nmlaser + + + + + + + + + + + + + + Angle of the linear polarized light, with respect to a fixed arbitrary + defined 0° position. This can be used if no definition of respective + cooridnate systems for beam and sample normal is done. If coordinate systems + are defined, refer to beam "incident_polarization". + + + + + + + + + + + + + Description of the detector type. + + + + + + + + + + + + + + + + + Type of detector, if "other" was selected in "detector_type". + + + + + Contains the raw data collected by the detector before calibration. + The data which is considered raw might change from experiment to experiment + due to hardware pre-processing of the data. + This field ideally collects the data with the lowest level of processing + possible. + + + + + + + + + + Raw data before calibration. + + + + + + Specify respective hardware which was used for the detector. For + example special electronics required for time-correlated single photon + counting (TCSPC). + + + + + + + + + + + + + + + + + + + + + + + + + + + Specification of type, may also go to name. + + + + + + If available, name/ID/norm of the light source standard. + + + + + Details about the device information. + + + + + The path to a beam emitted by this source. + Should be named with the same appendix, e.g., + for TYPE=532nmlaser, there should as well be + a NXbeam named "beam_532nmlaser" together with this source + instance named "source_532nmlaser" + + Example: /entry/instrument/beam_532nmlaser + + + + + + + + + Defines the reference frame which is used to describe the sample orientation + with respect to the beam directions. + + A beam centered description is the default and uses 4 angles(similar to XRD): + - Omega (angle between sample surface and incident beam) + - 2Theta (angle between the transmitted beam and the detection beam) + - Chi (sample tilt angle, angle between plane#1 and the surface normal, + plane#1 = spanned by incidence beam and detection + and detection. If Chi=0°, then plane#1 is the plane of + incidence in reflection setups) + - Phi (inplane rotation of sample, rotation axis is the samples + surface normal) + + + A sample normal centered description is as well possible: + - angle of incidence (angle between incident beam and sample surface) + - angle of detection (angle between detection beam and sample surface) + - angle of incident and detection beam + - angle of in-plane sample rotation (direction along the sample's surface normal) + + An arbitrary reference frame can be defined by "reference_frames" + and used via "instrument/angle_sample_and_beam_TYPE" + + + + + + + + + Angle between sample incident beam and sample surface. + + + + + Angle between incident and detection beam + + + + + Sample tilt between sample normal, and the plane spanned by detection and + incident beam. + + + + + Inplane rotation of the sample, with rotation axis along sample normal. + + + + + Angle(s) of the incident beam vs. the normal of the bottom reflective + (substrate) surface in the sample. These two directions span the plane + of incidence. + + + + + Detection angle(s) of the beam reflected or scattered off the sample + vs. the normal of the bottom reflective (substrate) surface in the + sample if not equal to the angle(s) of incidence. + These two directions span the plane of detection. + + + + + Angle between the incident and detection beam. + If angle_of_detection + angle_of_incidence = angle_of_incident_and_detection_beam, + then the setup is a reflection setup. + If angle_of_detection + angle_of_incidence != angle_of_incident_and_detection_beam + then the setup may be a light scattering setup. + (i.e. 90° + 90° != 90°, i.e. incident and detection beam in the sample surface, but + the angle source-sample-detector is 90°) + + + + + Angle of the inplane orientation of the sample. This might be an arbitrary, + angle without specific relation to the sample symmetry, + of the angle to a specific sample property (i.e. crystallographic axis or sample + shape such as wafer flat) + + + + + Set of transformations, describing the relative orientation of different + parts of the experiment (beams or sample). You may select one of the specified + angles for incident and detection beam or sample, and then use polar and azimuthal + angles to define the direction via sperical coordinates. + This allows consistent defintion between different coordinate system. + You may refer to self defined coordinate system as well. + + + If "angle_reference_frame = beam centered", then this coordinate system is used: + McStas system (NeXus default) + (https://manual.nexusformat.org/design.html#mcstas-and-nxgeometry-system) + + i.e. the z-coordinate math:`[0,0,1]` is along the incident beam direction and + the x-coordinate math:`[1,0,0]` is in the horizontal plane. Hence, usually math:`[0,1,0]` + is vertically oriented. + + If "angle_reference_frame = sample-normal centered", then this coordinate + system is used + z - math:`[0,0,1]` along sample surface normal + x - math:`[1,0,0]` defined by sample surface projected incident beam. + y - math:`[0,1,0]` in the sample surface, orthogonal to z and x. + For this case, x may be ill defined, if the incident beam is perpendicular + to the sample surface. In this case, use the beam centered description. + + + + + + + + + + + Rotation about the y axis (polar rotation within the sample plane). + + + + + + + + + + + + + + Path to a transformation that places the sample surface + into the origin of the arpes_geometry coordinate system. + + + + + + Rotation about the z axis (azimuthal rotation within the sample plane). + + + + + + + + + + + + + + + + + + + + + Specify if there is a lateral offset on the sample surface, between the focal + points of the incident beam and the detection beam. + + + + + Describes the order of respective beam devices in the optical beam + path. + + Everything object which interacts or modifies optical beam properties, + may be an beam device, e.g. Filter, Window, Beamsplitter, Photon Source, + Detector, etc, + + It is intended, to include this functionality later to "older" beam + components, such as NXsource, NXdetector, NXlens, etc. + Until this is possbible, auxillary beam devices have to be created, + for each "older" beam component instead, to allow a beam path description. + To link the auxillary beam device to the real device properties, the + attribute \@device should be used. + + + + Reference to beam device, which is described by a NeXus concept + (e.g. for NXsource, entry/instrument/source_TYPE). + + + + + Reference to the previous beam device, from which the photon beam came + to reach this beam device. A photon source is related as origin by ".". + This enables a logical order description of the optical setup. + + + + + + This is the optical element used to focus or collect light. This may + be a genereic lens or microcope objectives which are used for the + Raman scattering process. + + + + + + + + + + + + + + + + + polarization filter to prepare light to be measured or to be incident + on the sample. + Genereric polarization filter porperties may be implemented via NXfilter_pol + at a later stage. + + + + Physical principle of the polarization filter used to create a + defined incident or scattered light state. + + + + + + + + + + + + Specific name or type of the polarizer used. + + Free text, for example: Glan-Thompson, Glan-Taylor, Rochon Prism, Wollaston + Polarizer... + + + + + + + Spectral filter used to modify properties of the scattered or incident light. + Genereric spectral filter porperties may be implemented via NXfilter_spec + at a later stage. + + + + Type of laserline filter used to supress the laser, if measurements + close to the laserline are performed. + + + + + + + + + + + + + Type of laserline filter used to supress the laser, if measurements + close to the laserline are performed. + + + + + + + + + + + + Properties of the spectral filter such as wavelength dependent Transmission + or reflectivity. + + + + Which property is used to form the spectral properties of light, + i.e. transmission or reflection properties. + + + + + + + + + + + + + Allows description of beam properties via matrices, which relate ingoing with + outgoing beam properties. + + + + + Sample stage (or manipulator) for positioning of the sample. This should + only contain the spatial orientation of movement. + + + + Specify the type of the sample stage. + + + + + + + + + + + + + + If "other" was chosen in stage_type, enter here a free text description + of the stage type. + + + + + This allows a description of the stages relation or orientation and + position with respect to the sample or beam, if an laboratory or + an stage coordinate system is defined. + + + + + Description of relation of the beam with the sample. How dit the + sample hit the beam, e.g. 'center of sample, long edge parallel + to the plane of incidence'. + Is redundent, if a full orientation description is done via the + stages "transformations" entry. + + + + + + + + + + + + + + + + + + Type of control for the sample temperature. Replace TYPE by "cryostat" or + "heater" to specify it. + + + + + + + + + + + + + + + + Hardware used for actuation, i.e. laser, gas lamp, filament, resistive + + + + + + + + + + General device information of the optical spectroscopy setup, if + suitable (e.g. for a tabletop spectrometer or other non-custom build setups). + For custom build setups, this may be limited to the construction year. + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to control any parts of the optical spectroscopy setup. + The uppercase TYPE should be replaced by a specification name, i.e. + "software_detector" or "software_stage" to specify the respective + program or software components. + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + Description of the software by persistent resource, where the program, + code, script etc. can be found. + + + + + + + Pre-calibration of an arbitrary device of the instrumental setup, which + has the name DEVICE. You can specify here how, at which time by which method + the calibration was done. As well the accuracy and a link to the calibration + dataset. + + + + Path to the device, which was calibrated. + Example: entry/instrument/DEVICE + + + + + Provide data about the determined accuracy of the device, this may + may be a single value or a dataset like wavelength error vs. wavelength etc. + + + + + Was a calibration performed? If yes, when was it done? If the + calibration time is provided, it should be specified in + ENTRY/INSTRUMENT/calibration/calibration_time. + + + + + + + + + + + + If calibtration status is 'calibration time provided', specify the + ISO8601 date when calibration was last performed before this + measurement. UTC offset should be specified. + + + + + Generic data which does not fit to the 'NX_FLOAT' fields in NXproces. + This can be for example the instrument response function. + + + + + + The overall resolution of the optical instrument. + + + + + + + + + + Minimum distinguishable wavelength separation of peaks in spectra. + + + + + + Array of pairs of complex refractive indices n + ik of the medium + for every measured spectral point/wavelength/energy. + Only necessary if the measurement was performed not in air, or + something very well known, e.g. high purity water. + + + + + + + + + + Properties of the sample, such as sample type, layer structure, + chemical formula, atom types, its history etc. + Information about the sample stage and sample environment should be + described in ENTRY/INSTRUMENT/sample_stage. + + + + + Locally unique ID of the sample, used in the reasearch institute or group. + + + + + State the form of the sample, examples are: + thin film, single crystal, poly crystal, amorphous, single layer, + multi layer, liquid, gas, pellet, powder. + Generic properties of liquids or gases see NXsample properties. + + + + + Free text description of the sample. + + + + + Chemical formula of the sample. Use the Hill system (explained here: + https://en.wikipedia.org/wiki/Chemical_formula#Hill_system) to write + the chemical formula. In case the sample consists of several layers, + this should be a list of the chemical formulas of the individual + layers, where the first entry is the chemical formula of the top + layer (the one on the front surface, on which the light incident). + The order must be consistent with layer_structure + + + + + List of comma-separated elements from the periodic table that are + contained in the sample. If the sample substance has multiple + components, all elements from each component must be included in + 'atom_types'. + + + + + ISO 8601 time code with local time zone offset to UTC information + when the specimen was prepared. + + Ideally, report the end of the preparation, i.e. the last known timestamp when + the measured specimen surface was actively prepared. + + + + + A set of activities that occurred to the sample prior to/during the experiment. + + + + + Sample temperature (either controlled or just measured). + + + + If no sensor was available for the determination of temperature, selected + a nominal value which represents approximately the situation of sample temperature. + + + + + + + + + + + If temperature_nominal is "other", enter here a nominal/assumed/estimated + sample temperature. + + + + + Temperature sensor measuring the sample temperature. + This should be a link to /entry/instrument/manipulator/temperature_sensor. + + + + + Device to heat the sample. + This should be a link to /entry/instrument/manipulator/sample_heater. + + + + + Device for cooling the sample (Cryostat, Airflow cooler, etc.). + This should be a link to /entry/instrument/manipulator/cryostat. + + + + + + Arbirary sample property which may be varied during the experiment + and controlled by a device. Examples are pressure, voltage, magnetic field etc. + Similar to the temperautre description of the sample. + + + + Medium, in which the sample is placed. + + + + + + + + + + + + + + + + + (Measured) sample thickness. + + The information is recorded to qualify if the light used was likely + able to shine through the sample. + + In this case the value should be set to the actual thickness of + the specimen viewed for an illumination situation where the nominal + surface normal of the specimen is parallel to the optical axis. + + + + + If a thickness if given, please specify how this thickness was estimated or + determined. + + + + + + Qualitative description of the layer structure for the sample, + starting with the top layer (i.e. the one on the front surface, on + which the light incident), e.g. native oxide/bulk substrate, or + Si/native oxide/thermal oxide/polymer/peptide. + + + + + Specify the sample orientation, how is its sample normal oriented + relative in the laboratory reference frame, incident beam reference + frame. + + + + + If the sample is grown or fixed on a substrate, specify this here by + a free text description. + + + + + + Here generic types of data may be saved.. This may refer to data derived + from single or multiple raw measurements (i.e. several intensities are + evaluated for different parameters: ellipsometry -> psi and delta) - + i.e. non-raw data. + As well plotable data may be stored/linked here, which provides the most suitable + representation of the data (for the respective community). + + You may provide multiple instances of NXdata + + + + Spectrum, i.e. x-axis of the data (e.g. wavelength, energy etc.) + + + + + Spectrum, i.e. y-axis of the data (e.g. counts, intensity) + + + + + + + + Location to save the calibrated wavelength data. + + + + + + + + + Parameters that are derived from the measured data. + + + + Light loss due to depolarization as a value in [0-1]. + + + + + + + + + + Jones quality factor. + + + + + + + + + + Reflectivity. + + + + + + + + + + Transmittance. + + + + + + + + + + + Commercial or otherwise defined given name of the program that was + used to generate or calculate the derived parameters. + If home written, one can provide the actual steps in the NOTE + subfield here. + + + + + Either version with build number, commit hash, or description of a + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. + + + + + + \ No newline at end of file diff --git a/applications/NXraman.nxdl.xml b/applications/NXraman.nxdl.xml new file mode 100644 index 0000000000..02290711de --- /dev/null +++ b/applications/NXraman.nxdl.xml @@ -0,0 +1,261 @@ + + + + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the spectrum array (e.g. wavelength or energy) of the measured + data. + + + + + Number of measurements (1st dimension of measured_data array). This is + equal to the number of parameters scanned. For example, if the experiment + was performed at three different temperatures and two different pressures + N_measurements = 2*3 = 6. + + + + + Number of detection angles of the beam reflected or scattered off the + sample. + + + + + Number of angles of incidence of the incident beam. + + + + + Number of scattering configurations used in the measurement. + It is 1 for only parallel polarization meausement, 2 for parallel and cross + polarization measurement or larger, if i.e. the incident and scattered photon + direction is varied. + + + + + An application definition for Raman spectrocopy experiments. + + Such experiments may be as simple a single Raman spectrum from spontanous + Raman scattering and range to Raman imaging Raman spectrometer, + surface- and tip-enhanced Raman techniques, x-Ray Raman scattering, as well + as resonant Raman scattering phenomena or multidimenional Raman spectra (i.e. + varying temperature, pressure, electric field, ....) + + The application definition contains two things: + 1. The structures in the application definition of NXopt: + * Instrument and data calibrations + * Sensors for sample or beam conditions + + AND + + 2. The strucutres specified and extended in NXraman: + * description of the experiment type + * descroption of the setup's meta data and optical elements (source, monochromator, detector, waveplate, lens, etc.) + * description of beam properties and their relations to the sample + * sample information + + Information on Raman spectroscopy are provided in: + + General + + * Lewis, Ian R.; Edwards, Howell G. M. + Handbook of Raman Spectroscopy + ISBN 0-8247-0557-2 + + Raman scattering selection rules + + * Dresselhaus, M. S.; Dresselhaus, G.; Jorio, A. + Group Theory - Application to the Physics ofCondensed Matter + ISBN 3540328971 + + Semiconductors + + * Manuel Cardona + Light Scattering in Solids I + eBook ISBN: 978-3-540-37568-5 + DOI: https://doi.org/10.1007/978-3-540-37568-5 + + * Manuel Cardona, Gernot Güntherodt + Light Scattering in Solids II + eBook ISBN: 978-3-540-39075-6 + DOI: https://doi.org/10.1007/3-540-11380-0 + + * See as well other Books from the "Light Scattering in Solids" series: + III: Recent Results + IV: Electronic Scattering, Spin Effects, SERS, and Morphic Effects + V: Superlattices and Other Microstructures + VI: Recent Results, Including High-Tc Superconductivity + VII: Crystal-Field and Magnetic Excitations + VIII: Fullerenes, Semiconductor Surfaces, Coherent Phonons + IX: Novel Materials and Techniques + + Glasses, Liquids, Gasses, ... + + Review articles: + Stimulated Raman scattering, Coherent anti-Stokes Raman scattering, + Surface-enhanced Raman scattering, Tip-enhanced Raman scattering + * https://doi.org/10.1186/s11671-019-3039-2 + + + + + An application definition for Raman spectrsocopy. + + + + Version number to identify which definition of this application + definition was used for this entry/data. + + + + + URL where to find further material (documentation, examples) relevant + to the application definition. + + + + + + + + + + Specify the type of the optical experiment. + + You may specify fundamental characteristics or properties in the experimental sub-type. + + + + + + + + Specify the type of Raman experiment. + + + + + + + + + + + + + + + + + + + + If the raman_experiment_type is `other`, a name should be specified here. + + + + + Metadata of the setup, its optical elements and physical properites which + defines the Raman measurement. + + + + Scattering configuration as defined by the porto notation by three + states, which are othogonal to each other. Example: z(xx)z for + parallel polarized backscattering configuration. + + See: + https://www.cryst.ehu.es/cgi-bin/cryst/programs/nph-doc-raman + + A(BC)D + + A = The propagation direction of the incident light (k_i) + B = The polarization direction of the incident light (E_i) + C = The polarization direction of the scattered light (E_s) + D = The propagation direction of the scattered light (k_s) + + An orthogonal base is assumed. + Linear polarized light is displayed by e.g. "x","y" or "z" + Unpolarized light is displayed by "." + For non-orthogonal vectors, use the attribute porto_notation_vectors. + + + + Scattering configuration as defined by the porto notation given by + respective vectors. + + Vectors in the porto notation are defined as for A, B, C, D above. + Linear light polarization is assumed. + + + + 3 x 4 Matrix, which lists the porto notation vectors A, B, C, D. + A has to be perpendicular to B and C perpendicular to D. + + + + + + + + + + Beam which is incident to the sample. + + + + + + diff --git a/base_classes/NXactivity.nxdl.xml b/base_classes/NXactivity.nxdl.xml new file mode 100644 index 0000000000..f354de06d2 --- /dev/null +++ b/base_classes/NXactivity.nxdl.xml @@ -0,0 +1,56 @@ + + + + + + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + + This class is planned be used in the future as the super class for all other activities if inheritance + in base classes is supported in NeXus. + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity started. + + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this activity ended. + + + + + Short description of the activity. + + + + + This can be any data or other descriptor acquired during the activity + (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. + + + diff --git a/base_classes/NXactuator.nxdl.xml b/base_classes/NXactuator.nxdl.xml new file mode 100644 index 0000000000..3fe0a4108f --- /dev/null +++ b/base_classes/NXactuator.nxdl.xml @@ -0,0 +1,127 @@ + + + + + + An actuator used to control an external condition. + + The condition itself is described in :ref:`NXenvironment`. + + + + Actuator identification code/model number + + + + + Name of the actuator + + + + + Short name of actuator used e.g. on monitor display program + + + + + Describe where the actuator is attached to. + This could be an instance of NXsample or a device on NXinstrument. + + + + + Name for the physical quantity effected by the actuation + + Examples: + temperature | pH | magnetic_field | electric_field | current | conductivity | resistance | voltage | + pressure | flow | stress | strain | shear | surface_pressure + + + + + The type of hardware used for the actuation. + + Examples (suggestions, but not restrictions): + + :Temperature: laser | gas lamp | filament | resistive + :Pressure: anvil cell + :Voltage: potentiostat + + + + + Any output that the actuator produces. + For example, a heater can have the field heater_power(NX_FLOAT). + + + + + Time history of actuator outputs. + + + + + If the actuator is PID-controlled, the settings of the PID controller can be + stored here. + + + + Nominal actuator setpoint. + Can be a scalar or a vector (of [n] actuations). + + + + + Time history of actuator setpoints. + + + + + + Refers to the last transformation specifying the position of the actuator + in the NXtransformations chain. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the actuator within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + diff --git a/base_classes/NXbeam.nxdl.xml b/base_classes/NXbeam.nxdl.xml index b3a44a1dbc..3cd0d94732 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/NXbeam_device.nxdl.xml b/base_classes/NXbeam_device.nxdl.xml new file mode 100644 index 0000000000..81bf135c0e --- /dev/null +++ b/base_classes/NXbeam_device.nxdl.xml @@ -0,0 +1,67 @@ + + + + + + Properties of generic beam device in an experimental setup. + + Any beam related devices like source, detector, filter, mirror, + beamsplitter, ... which may modifies a beam in an experimental setup + can be described here with its experimental position and relationship + to the other beam devices in the setup. + + + + Single device or list of devices pointing to the devices from which an + beam originated to reach this device. + This is used to describe a logical order of devices and for the whole setup. + In this way, a "beam path" can be described (i.e., with starting point (light source) + and end point (photo detector)). + + Example: /entry/instrument/detector. + + + + + Description of the intended purpose of this device for + the experimental setup. + + + + + Name of the group with which this device can be associated. + For example, if a group of devices is used for second harmonic generation, + all these devices have the group name "second harmonic generation". + Is used for simplified setup vizualization (or description?). + + + + + Location and orientation of the device. Note that even a + simple distance can be given as a translation. + + You can use the @depends_on to describe from which device + the transformation needs to be applied. + + + diff --git a/base_classes/NXbeam_transfer_matrix_table.nxdl.xml b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml new file mode 100644 index 0000000000..d61f275566 --- /dev/null +++ b/base_classes/NXbeam_transfer_matrix_table.nxdl.xml @@ -0,0 +1,120 @@ + + + + + + + Variables used throughout the document, e.g. dimensions or parameters. + + + + Length of the array associated to the data type. + + + + + Contains datastructures of an experimental optical setup (i.e., multiple + transfermatrix tables). These datastructures are used to relate physical + properties of two beams (NXbeam) which have one common optical element + (NXopt_element) (one specific transfermatrix). + One of these beams in an input beam and the other one is an output beam. + + The data describes the change of beam properties, e.g. the intensity of a + beam is reduced because the transmission coefficient of the beam device is + lower than 1. + + + + Select which type of data was recorded, for example aperture and + focal length. + It is possible to have multiple selections. This selection defines + how many columns (N_variables) are stored in the data array. + N in the name, is the index number in which order the given + property is listed. + + + + + + + + + + + Please list in this array the column and row names used in your actual data. + That is in the case of aperture ['diameter'] or focal length ['focal_length_value'] + and for orientation matrix ['OM1', 'OM2', 'OM3'] or for jones matrix + ['JM1','JM2'] + + + + + + + + Contains the datastructure which relates beam properties of an + input and output beam as result of the input beam interaction + with the beam device. + + Transfermatrix relationship between N input beams and M output beams. + It contains a table with the relevant matricis to be used for different + transmissitted properties (such as polarization, intensity, phase). + + Data structure for all transfermatrices of an beam device in a setup. + For each combination of N input and M output beams and for L physical + concept (i.e. beam intensity), one matrix can be defined. + + In this way, the transfermatrix table has the dimension NxM. + + For each entry, in this transfermatrix, there are L formalisms. + Each formalism has the dimension math:`dim(L_i)xdim(L_i)`, + whereby math:`L_i` is the specific physical concept (Intensity, polarization, direction). + + A beamsplitter with two input laser beams can have a total of + four transfermatrices (2 Input x 2 Output). + + The dimension of the transfermatrix depends on the parameters. + Examples are: + 1x1 for intensity/power + 2x2 for jones formalism + 3x3 for direction + + + + Square matrix with dimension N_variables x N_variables + + + + + + + Specific name of input beam which the transfermatrix table is related to. + + + + + Specific name of output beam which the transfermatrix table is related to. + + + + diff --git a/base_classes/NXcalibration.nxdl.xml b/base_classes/NXcalibration.nxdl.xml new file mode 100644 index 0000000000..702688fc2c --- /dev/null +++ b/base_classes/NXcalibration.nxdl.xml @@ -0,0 +1,220 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays + + + + Number of coefficients of the calibration function + + + + + Number of points of the calibrated and uncalibrated axes + + + + + Subclass of NXprocess to describe post-processing calibrations. + + + + A description of the procedures employed. + + + + + The physical quantity of the calibration, e.g., + energy, momentum, time, etc. + + + + + A digital persistent identifier (e.g., DOI, ISO standard) referring to a detailed description of a + calibration method but no actual calibration data. + + + + + A digital persistent identifier (e.g., a DOI) referring to a publicly available calibration measurement + used for this instrument, e.g., a measurement of a known standard containing calibration information. + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + A file serialisation of a calibration which may not be publicly available (externally from the nexus file). + + This metadata can be a documentation of the source (file) or database (entry) from which pieces + of information have been extracted for consumption (e.g. in a research data management system (RDMS)). + It is also possible to include the actual file by using the `file` field. + + The axis values may be copied or linked in the appropriate NXcalibration fields for reference. + + + + + Indicates the name of the last operation applied in the NXprocess sequence. + + + + + Has the calibration been applied? + + + + + Name of the software used for this calibration. + + + + Software version. + + + + + + Vector containing the data coordinates in the original uncalibrated axis + + + + + + + The symbol of the axis to be used in the fit_function, e.g., `energy`, `E`. + This should comply to the following naming rules (similar to python's naming rules): + + * A variable name must start with a letter or the underscore character + * A variable name cannot start with a number + * A variable name can only contain alpha-numeric characters and underscores (A-z, 0-9, and _ ) + * Variable names are case-sensitive (age, Age and AGE are three different variables) + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + Additional input axis to be used in the formula. + The part after `input_` is used as the symbol to be used in the `fit_function`, i.e., + if the field name is `input_my_field` you should refer to this axis by `my_field` in the `fit_function`. + + + + + + + The path from which this data is derived, e.g., raw detector axis. + Should be a valid NeXus path name, e.g., /entry/instrument/detector/raw. + + + + + + For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit + to a set of features (peaks) at well defined energy positions to determine + E(TOF). Here we can store the array of fit coefficients. + + + + + + + + For non-linear energy calibrations. Here we can store the formula of the + fit function. + + Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. + + Use x0, x1, ..., xn for the nth position in the `original_axis` field. + If there is the symbol attribute specified for the `original_axis` this may be used instead of x. + If you want to use the whole axis use `x`. + Alternate axis can also be available as specified by the `input_SYMBOL` field. + The data should then be referred here by the `SYMBOL` name, e.g., for a field + name `input_my_field` it should be referred here by `my_field` or `my_field0` if + you want to read the zeroth element of the array. + + The formula should be numpy compliant. + + + + + For linear calibration. Scaling parameter. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + For linear calibration. Offset parameter. + This should yield the relation `calibrated_axis` = `scaling` * `original_axis` + `offset`. + + + + + Mapping data for calibration. + + This can be used to map data points from uncalibrated to calibrated values, + i.e., by multiplying each point in the input axis by the corresponding point in the mapping data. + + + + + A vector representing the axis after calibration, matching the data length + + + + + + + The path to which this data is written, e.g., the calibrated energy. + Should be a valid NeXus path name, e.g., /entry/data/energy. + + + + + + Any data acquired/used during the calibration that does not fit the `NX_FLOAT` fields above. + NXdata groups can be used for multidimensional data which are relevant to the calibration + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/base_classes/NXchemical_process.nxdl.xml b/base_classes/NXchemical_process.nxdl.xml new file mode 100644 index 0000000000..437fcf0b6a --- /dev/null +++ b/base_classes/NXchemical_process.nxdl.xml @@ -0,0 +1,60 @@ + + + + + + A planned or unplanned process which results in chemical changes (i.e., changes in the chemical bonds) in a specified material. + + Examples include any chemical reactions (addition, subtraction, replacement, ...). + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. + + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. + + + + + Short description of the chemical process. + + + + + Method by which this process was performed. + + + + + This can be any data or other descriptor acquired during the chemical process + (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. + + + diff --git a/base_classes/NXcircuit.nxdl.xml b/base_classes/NXcircuit.nxdl.xml new file mode 100644 index 0000000000..9648ae103a --- /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/base_classes/NXcomponent.nxdl.xml b/base_classes/NXcomponent.nxdl.xml new file mode 100644 index 0000000000..d317db6803 --- /dev/null +++ b/base_classes/NXcomponent.nxdl.xml @@ -0,0 +1,64 @@ + + + + + + Base class for components of an instrument - real ones or a simulated ones. + + + + Specifies the position of the component by pointing to the last + transformation in the transformation chain that is defined + via the NXtransformations group. + + + + + Was the component used? + + + + + Given name + + + + + Ideally, use instances of :ref:`NXidentifier` to point to a resource + that provides further details. + + If such a resource does not exist or should not be used, use this, though + discouraged, free-text. + + + + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the component in the instrument. + + + + diff --git a/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..9c26b8c9b6 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 concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector + + The ``AXISNAME_indices`` attribute is a single integer or an array of integers that defines which :ref:`data </NXdata/DATA-field>` @@ -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 concept allows to link an axis to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Examples: + If a calibration has been performed, ``@reference`` links to the result of + that calibration: + + @reference: '/entry/process/calibration/calibrated_axis' + + If the axis corresponds to a coordinate of a detector, ``@reference`` links + to that detector axis: + + @reference: '/entry/instrument/detector/axis/some_axis' for a 2D detector + + If the axis is a scanned motor, ``@reference`` links to the transformation + describing the respective motion, e.g.: + + @reference: '/entry/instrument/detector/transformations/some_transformation' for a motion of the detector + + @@ -414,6 +452,23 @@ data label + + + Points to the path of a field defining the data to which the `DATA` field refers. + + This concept allows to link the data to a respective field in the NeXus hierarchy, thereby + defining the physical quantity it represents. + + Here, *DATA* is to be replaced by the name of each + data field. + + Example: + If the data corresponds to a readout of a detector, ``@reference`` links + to that detectors data: + + @reference: '/entry/instrument/detector/data' for a 2D detector + + 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 abdea5bbbf..10e699c881 100644 --- a/contributed_definitions/NXdeflector.nxdl.xml +++ b/base_classes/NXdeflector.nxdl.xml @@ -1,10 +1,10 @@ - + - + Deflectors as they are used e.g. in an electron analyser. - + - Qualitative type of deflector with respect to the number of pole pieces + Qualitative type of deflector with respect to the number of pole pieces. @@ -36,52 +36,54 @@ - + Colloquial or short name for the deflector. For manufacturer names and identifiers use respective manufacturer fields. - + + - Name of the manufacturer who built/constructed the deflector. + Ideally an identifier, persistent link, or free text which gives + further details about the deflector. - + - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the deflector. + Excitation voltage of the deflector. For dipoles it is a single number. + For higher order multipoles, it is an array. - + - Ideally an identifier, persistent link, or free text which gives further details - about the deflector. + Excitation current of the deflector. For dipoles it is a single number. For + higher orders, it is an array. - + - Excitation voltage of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Spatial offset of the deflector in x direction (perpendicular to + ```offset_y```). - + - Excitation current of the deflector. For dipoles it is a single number. For - higher orders, it is an array. + Spatial offset of the deflector in y direction (perpendicular to + ```offset_x```). - + Specifies the position of the deflector by pointing to the last transformation in the transformation chain in the NXtransformations group. - + Collection of axis-based translations and rotations to describe the location and geometry of the deflector as a component in the instrument. Conventions from the - NXtransformations base class are used. In principle, the McStas coordinate + :ref:`NXtransformations` base class are used. In principle, the McStas coordinate system is used. The first transformation has to point either to another component of the system or . (for pointing to the reference frame) to relate it relative to the experimental setup. Typically, the components of a system should diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index b555456f8e..f1ea1f2aaf 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -933,7 +933,57 @@ + + + Type of electron amplifier, MCP, channeltron, etc. + + + + + Description of the detector type, DLD, Phosphor+CCD, CMOS. + + + + + Voltage applied to detector. + + + + + Voltage applied to the amplifier. + + + + + The low voltage of the amplifier migh not be the ground. + + + + + Size of each imaging sensor chip on the detector. + + + + + Number of imaging sensor chips on the detector. + + + + + Physical size of the pixels of the imaging chip on the detector. + + + + + Number of raw active elements in each dimension. Important for swept scans. + + + + + raw data output from the detector + + .. index:: plotting diff --git a/contributed_definitions/NXdistortion.nxdl.xml b/base_classes/NXdistortion.nxdl.xml similarity index 100% rename from contributed_definitions/NXdistortion.nxdl.xml rename to base_classes/NXdistortion.nxdl.xml 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/NXenvironment.nxdl.xml b/base_classes/NXenvironment.nxdl.xml index 4f878263b2..74ed194f03 100644 --- a/base_classes/NXenvironment.nxdl.xml +++ b/base_classes/NXenvironment.nxdl.xml @@ -48,6 +48,17 @@ Note, it is recommended to use NXtransformations instead. + + + This is to be used if there is no actuator/sensor that controls/measures + the environment parameters, but the user would still like to give a value for + it. An example would be a room temperature experiment where the temperature is + not actively measured, but rather estimated. + + Note that this method for recording the environment parameters is not advised, + but using NXsensor and NXactuator is strongly recommended instead. + + NeXus positions components by applying a set of translations and rotations @@ -69,6 +80,29 @@ Additional information, LabView logs, digital photographs, etc - - + + + Any actuator used to control the environment. This can be linked to an actuator + defined in an NXinstrument instance. + + + + + Any sensor used to monitor the environment. This can be linked to a sensor + defined in an NXinstrument instance. + + + + + .. index:: plotting + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + diff --git a/base_classes/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml new file mode 100644 index 0000000000..76f48e3b84 --- /dev/null +++ b/base_classes/NXfabrication.nxdl.xml @@ -0,0 +1,70 @@ + + + + + + Details about a component as it is defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + If different versions exist are possible, the value in this field should be made + specific enough to resolve the version. + + + + + + Ideally, (globally) unique persistent identifier. This may contain e.g. a hash + identifier of the component. + + + + + Serial number of the component. + + + + + Datetime of components initial construction. This refers to the date of + first measurement after new construction or to the relocation date, + if it describes a multicomponent/custom-build setup. + Should be a ISO8601 date/time stamp. It is recommended to add an explicit time zone, + otherwise the local time zone is assumed per ISO8601. + + + + + Free-text list with eventually multiple terms of + functionalities which the component offers. + + + diff --git a/base_classes/NXhistory.nxdl.xml b/base_classes/NXhistory.nxdl.xml new file mode 100644 index 0000000000..9dfa25d722 --- /dev/null +++ b/base_classes/NXhistory.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + A set of activities that occurred to a physical entity prior/during experiment. + + Ideally, a full report of the previous operations (or links to a chain of operations). + Alternatively, notes allow for additional descriptors in any format. + + + + Any activity that was performed on the physical entity prior or during the experiment. In + the future, if there is base class inheritance, this can describe any activity, + including processes and measurements. + + + + + + Any physical process that was performed on the physical entity prior or during the + experiment. + + + + + Any chemical process that was performed on the physical entity prior or during the + experiment. + + + + + An ID or reference to the location or a unique (globally + persistent) identifier of e.g. another file which gives + as many as possible details of the history event. + + + + + + A descriptor to keep track of the treatment of the physical entity before or during the + experiment (NXnote allows to add pictures, audio, movies). Alternatively, a + reference to the location or a unique identifier or other metadata file. In the + case these are not available, free-text description. + This should only be used in case that there is no rigorous description + using the base classes above. This field can also be used to pull in any activities + that are not well described by an existing base class definition. + + + diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXidentifier.nxdl.xml similarity index 55% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXidentifier.nxdl.xml index 1f940f0795..ce05800f9e 100644 --- a/contributed_definitions/NXfabrication.nxdl.xml +++ b/base_classes/NXidentifier.nxdl.xml @@ -1,10 +1,10 @@ - + - + - Details about a component as defined by its manufacturer. + An identifier for a (persistent) resource, e.g., a DOI or orcid. - - - Company name of the manufacturer. - - - + - Version or model of the component named by the manufacturer. + The service by which the resource can be resolved. + + Examples: doi, urn, hdl, purl, orcid, iso, url - + - Ideally, (globally) unique persistent identifier, i.e. - a serial number or hash identifier of the component. + The unique code, IRI or hash to resolve this reference. + Typically, this is stated by the service which is considered a complete + identifier, e.g., for a DOI it's something of the form `10.1107/S1600576714027575` + or `https://doi.org/10.1107/S1600576714027575`, which are both resolvable. - + - Free-text list with eventually multiple terms of - functionalities which the component offers. + True if the identifier is persistent (i.e., unique and available indefinitely), + False otherwise. - diff --git a/base_classes/NXinstrument.nxdl.xml b/base_classes/NXinstrument.nxdl.xml index 15e7645403..197163ff38 100644 --- a/base_classes/NXinstrument.nxdl.xml +++ b/base_classes/NXinstrument.nxdl.xml @@ -42,6 +42,7 @@ short name for instrument, perhaps the acronym + @@ -55,16 +56,20 @@ + + + + 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/contributed_definitions/NXlens_opt.nxdl.xml b/base_classes/NXlens_opt.nxdl.xml similarity index 92% rename from contributed_definitions/NXlens_opt.nxdl.xml rename to base_classes/NXlens_opt.nxdl.xml index 753a58e550..f413dc19f0 100644 --- a/contributed_definitions/NXlens_opt.nxdl.xml +++ b/base_classes/NXlens_opt.nxdl.xml @@ -1,4 +1,4 @@ - + - - + @@ -104,8 +105,10 @@ - + If the lens has a coating describe the material and its properties. Some basic information can be found e.g. [here] @@ -182,4 +185,14 @@ the lens has different coatings on the front and back side.--> Abbe number (or V-number) of the lens. + + + The numerical aperture of the used incident light optics. + + + + + + + diff --git a/base_classes/NXmanipulator.nxdl.xml b/base_classes/NXmanipulator.nxdl.xml new file mode 100644 index 0000000000..a057a167df --- /dev/null +++ b/base_classes/NXmanipulator.nxdl.xml @@ -0,0 +1,257 @@ + + + + + + Extension of NXpositioner to include fields to describe the use of manipulators + in photoemission experiments. + + + + 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 actuator on the manipulator used to control an external + condition. + + + + + Any additional sensors on the manipulator used to monitor an external condition. + + + + + Class to describe the motors that are used in the manipulator + + + + + 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/NXopt_window.nxdl.xml b/base_classes/NXopt_window.nxdl.xml new file mode 100644 index 0000000000..f1fc90e670 --- /dev/null +++ b/base_classes/NXopt_window.nxdl.xml @@ -0,0 +1,128 @@ + + + + + + + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + + This first verion originates from NXopt to describe cryostate windows + and possible influences for ellipsometry measurements. + + For environmental measurements, the environment (liquid, vapor + etc.) is enclosed in a cell, which has windows both in the + direction of the source (entry window) and the detector (exit + window) (looking from the sample). In case that the entry and exit + windows are not the same type and do not have the same properties, + use a second 'WINDOW(NXaperture)' field. + + The windows also add a phase shift to the light altering the + measured signal. This shift has to be corrected based on measuring + a known sample (reference sample) or the actual sample of interest + in the environmental cell. State if a window correction has been + performed in 'window_effects_corrected'. Reference data should be + considered as a separate experiment, and a link to the NeXus file + should be added in reference_data_link in measured_data. + + The window is considered to be a part of the sample stage but also + beam path. Hence, its position within the beam path should be + defined by the 'depends_on' field. + + + + + Was a window correction performed? If 'True' describe the window + correction procedure in 'window_correction/procedure'. + + + + + Type of effects due to this window on the measurement. + + + + + + + + + + + Was a window correction performed? If 'True' describe the + window correction procedure in '' + + + + Describe when (before or after the main measurement + time + stamp in 'date') and how the window effects have been + corrected, i.e. either mathematically or by performing a + reference measurement. In the latter case, provide the link to + to the reference data in 'reference_data_link'. + + + + + Link to the NeXus file which describes the reference data if a + reference measurement for window correction was performed. + Ideally, the reference measurement was performed on a reference + sample and on the same sample, and using the same conditions as + for the actual measurement with and without windows. It should + have been conducted as close in time to the actual measurement + as possible. + + + + + + The material of the window. + + + + + + + + + + + + + + + If you specified 'other' as material, decsribe here what it is. + + + + + Thickness of the window. + + + + + Angle of the window normal (outer) vs. the substrate normal + (similar to the angle of incidence). + + + + diff --git a/base_classes/NXphysical_process.nxdl.xml b/base_classes/NXphysical_process.nxdl.xml new file mode 100644 index 0000000000..d422e516c6 --- /dev/null +++ b/base_classes/NXphysical_process.nxdl.xml @@ -0,0 +1,61 @@ + + + + + + A planned or unplanned process which results in physical changes in a specified material. + + A physical change involve changes only in intermolecular forces, not in the chemical bonds. + Examples include sample preparation, material transformation, or (partially) destructive measurements. + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process started. + + + + + ISO 8601 formatted time code (with local time zone offset to UTC information + included) when this process ended. + + + + + Short description of the activity. + + + + + Method by which this process was performed. + + + + + This can be any data or other descriptor acquired during the physical process + (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. + + + diff --git a/contributed_definitions/NXpid.nxdl.xml b/base_classes/NXpid.nxdl.xml similarity index 70% rename from contributed_definitions/NXpid.nxdl.xml rename to base_classes/NXpid.nxdl.xml index 62fad3f835..4941cac937 100644 --- a/contributed_definitions/NXpid.nxdl.xml +++ b/base_classes/NXpid.nxdl.xml @@ -1,10 +1,10 @@ - + - + Contains the settings of a PID controller. @@ -53,12 +53,18 @@ 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. @@ -81,4 +87,25 @@ 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/base_classes/NXprocess.nxdl.xml b/base_classes/NXprocess.nxdl.xml index d7d1a80f84..7a9cecd4d5 100644 --- a/base_classes/NXprocess.nxdl.xml +++ b/base_classes/NXprocess.nxdl.xml @@ -43,6 +43,21 @@ Date and time of processing. + + + Describes the operations of image registration + + + + + Describes the operations of image distortion correction + + + + + Describes the operations of calibration procedures, e.g. axis calibrations. + + The note will contain information about how the data was processed @@ -67,4 +82,3 @@ - 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/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/base_classes/NXresolution.nxdl.xml b/base_classes/NXresolution.nxdl.xml new file mode 100644 index 0000000000..4197d55506 --- /dev/null +++ b/base_classes/NXresolution.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + Describes the resolution of a physical quantity. + + + + The physical quantity of the resolution, e.g., + energy, momentum, time, etc. + + + + + The process by which the resolution was determined. + + + + + + + + + + + Additional details of the estimate or description of the calibration procedure + + + + + The resolution of the physical quantity. + + + + + Standard deviation of the resolution of the physical quantity. + + + + + Ratio of the resolution at a specified measurand value to that measurand value, + + + + + Standard deviation of the relative resolution of the physical quantity. + + + + + The response of the instrument or part to a infinitesimally sharp input signal + along the physical quantity of this group. + This is also sometimes called instrument response function for time resolution or + point spread function for spatial response. + The resolution is typically determined by taking the full width at half maximum (FWHM) + of the response function. + + + + The input axis or grid of the response function. + The unit should match the one of the resolution field. + + + + + The magnitude of the response function corresponding to the points + in the input axis or grid. + This field should have the same dimensions as `input`. + + + + + + A symbol linking to another path in this appdef to be referred to from the + `resolution_formula` field. This should be a valid path inside this application + definition, i.e., of the form /entry/instrument/my_part/my_field. + + + + + A resolution formula to determine the resolution from a set of symbols as + entered by the `formula_...` fields. + The output unit should match the provided unit of this field. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + For storing details and data of a calibration to derive a resolution from data. + + + diff --git a/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.nxdl.xml b/base_classes/NXsample.nxdl.xml index c101fcb56f..4b15f3b8fa 100755 --- a/base_classes/NXsample.nxdl.xml +++ b/base_classes/NXsample.nxdl.xml @@ -48,6 +48,9 @@ Descriptive name of sample + + Identification number or signatures of the sample used. + The chemical formula specified using CIF conventions. @@ -379,13 +382,63 @@ - Any positioner (motor, PZT, ...) used to locate the sample - - - - This group describes the shape of the sample - - + Any positioner (motor, PZT, ...) used to locate the sample + + + + This group describes the shape of the sample + + + + + Physical form of the sample material. + Examples include single crystal, foil, pellet, powder, thin film, disc, foam, gas, liquid, amorphous. + + + + + If the sample is a single crystal, add description of single crystal and unit + cell. + + + + + Set of sample components and their configuration. + There can only be one NXsample_component_set in one component. + + + + + + If the sample is made from a pure substance and cannot be further divided using + NXsample_component. + + + + + + Details about the sample vendor (company or research group) + + + + + An (ideally) globally unique identifier for the sample. + + + + + + Any environmental or external stimuli/measurements. + These can include, among others: + applied pressure, surrounding gas phase and gas pressure, + external electric/magnetic/mechanical fields, temperature, ... + + + + + A set of physical processes that occurred to the sample prior/during experiment. + + .. index:: plotting @@ -418,4 +471,3 @@ - diff --git a/base_classes/NXsample_component.nxdl.xml b/base_classes/NXsample_component.nxdl.xml index 1b5a282613..3c4670a148 100644 --- a/base_classes/NXsample_component.nxdl.xml +++ b/base_classes/NXsample_component.nxdl.xml @@ -38,11 +38,16 @@ - One group like this per component can be recorded For a sample consisting of multiple components. + One group like this per component can be recorded for a sample consisting of multiple components. Descriptive name of sample component + + + Identification number or signatures of the sample component used. + + The chemical formula specified using CIF conventions. @@ -139,6 +144,48 @@ As a function of Wavelength + + + If the component is a single crystal, add description of single crystal and unit + cell. + + + + + Set of sub-components and their configuration. + There can only be one NXsample_component_set in one component. + + + + + + If the component is made from a pure substance and cannot be further divided + using NXsample_component. + + + + + + Details about the sample component vendor (company or research group) + + + + + An (ideally) globally unique identifier for the sample component. + + + + + A set of physical processes that occurred to the sample component prior/during + experiment. + + + + + Any NXsample_component depends on the instance of NXsample_component_set, at the same level of + description granularity where the component is located. + + .. index:: plotting @@ -152,4 +199,4 @@ for a summary of the discussion. - + \ No newline at end of file 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/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 5917c370f3..7c2e5fce39 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -55,6 +55,7 @@ + @@ -154,6 +155,7 @@ This group describes the shape of the sensor when necessary. + .. index:: plotting @@ -190,4 +192,3 @@ - diff --git a/base_classes/NXserialized.nxdl.xml b/base_classes/NXserialized.nxdl.xml new file mode 100644 index 0000000000..fda0769482 --- /dev/null +++ b/base_classes/NXserialized.nxdl.xml @@ -0,0 +1,74 @@ + + + + + + Metadata to a set of pieces of information of a resource that has been serialized. + + A typical use case is the documentation of the source (file) or database (entry) + from which pieces of information have been extracted for consumption in e.g. a + research data management system (RDMS). This may be for reasons of enabling + services such as providing access to normalized information for which reading + again from the resource may not be desired, possibe, or feasible. + + Possible reasons could be the extraction of specific information for caching, + performance reasons, or re-evaluate given pieces of information based on other + views and interaction patterns with the data where information has been formatted + differently by tools than how these pieces of information were originally + serialized. + + + + Answers into what resource the information was serialized. + + + + + + + + + Path to the resource. + + E.g. the name of a file or its absolute or relative path, or the + identifier to a resource in another database. + + + + + Value of the hash that is obtained when running algorithm + on the content of the resource referred to by path. + + + + + Name of the algorithm whereby the checksum was computed. + + + + + + Extracted file containing the serialized information. + + + diff --git a/base_classes/NXsingle_crystal.nxdl.xml b/base_classes/NXsingle_crystal.nxdl.xml new file mode 100644 index 0000000000..44f6e92c30 --- /dev/null +++ b/base_classes/NXsingle_crystal.nxdl.xml @@ -0,0 +1,72 @@ + + + + + + Description of a single crystal material or a single crystalline phase in a material. + + There is the option of using Busing-Levy convention (as orginally designed in NXsample) + or using a more detailed description with NXrotation_set. + + + + This will follow the Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + Orientation matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464 + + + + + + + + + UB matrix of single crystal sample using Busing-Levy convention: + W. R. Busing and H. A. Levy (1967). Acta Cryst. 22, 457-464. This is + the multiplication of the orientation_matrix, given above, + with the :math:`B` matrix which can be derived from the lattice constants. + + + + + + + + + Detailed description of single crystal orientation and misorientation. + + + + + Unit cell of the single crystal. + + + diff --git a/base_classes/NXsource.nxdl.xml b/base_classes/NXsource.nxdl.xml index 16974c945f..3743fb4218 100644 --- a/base_classes/NXsource.nxdl.xml +++ b/base_classes/NXsource.nxdl.xml @@ -240,6 +240,11 @@ Deflectors inside the source. + + + Individual electromagnetic lenses inside the source. + + 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/base_classes/NXsubstance.nxdl.xml b/base_classes/NXsubstance.nxdl.xml new file mode 100644 index 0000000000..6d246ca224 --- /dev/null +++ b/base_classes/NXsubstance.nxdl.xml @@ -0,0 +1,119 @@ + + + + + + A form of matter with a constant, definite chemical composition. + + Examples can be single chemical elements, chemical compunds, or alloys. + For further information, see https://en.wikipedia.org/wiki/Chemical_substance. + + + + User-defined chemical name of the substance + + + + + Molecular mass of the substance + + + + + Unique numeric CAS REGISTRY number of the sample chemical content + For further information, see https://www.cas.org/. + + + + + CAS REGISTRY name of the sample chemical content + + + + + CAS REGISTRY URI + + + + + CAS REGISTRY image + + + + + Synonyms in the CAS system. + + + + + String InChi identifier. + The InChI identifier expresses chemical structures in terms of atomic connectivity, + tautomeric state, isotopes, stereochemistry and electronic charge in order to + produce a string of machine-readable characters unique to the respective molecule. + For further information, see https://iupac.org/who-we-are/divisions/division-details/inchi/. + + + + + Condensed, 27 character InChI key. + Hashed version of the full InChI (using the SHA-256 algorithm). + + + + + Name according to the IUPAC system (standard). + For further information, see https://iupac.org/. + + + + + Identifier in the SMILES (Simplified Molecular Input Line Entry System) system + For further information, see https://www.daylight.com/smiles/. + + + + + Canonical version of the smiles identifier + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard:107 + This is the *Hill* system used by Chemical Abstracts. + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + + diff --git a/base_classes/NXtransformations.nxdl.xml b/base_classes/NXtransformations.nxdl.xml index c8337ce725..fd40f89e48 100644 --- a/base_classes/NXtransformations.nxdl.xml +++ b/base_classes/NXtransformations.nxdl.xml @@ -170,8 +170,9 @@ - Points to the path to a field defining the axis on which this - depends or the string ".". + Points to the path of a field defining the axis on which this instance of + NXtransformations depends or the string ".". It can also point to an instance of + ``NX_coordinate_system`` if this transformation depends on it. @@ -202,7 +203,7 @@ the corresponding axis moves during the exposure of a frame. Ideally, the value of this field added to each value of ``AXISNAME`` would agree with the corresponding values of ``AXISNAME_end``, but there is a possibility of significant - differences. Use of ``AXISNAME_end`` is recommended. + differences. Use of ``AXISNAME_end`` is recommended. @@ -218,4 +219,4 @@ for a summary of the discussion. - + \ No newline at end of file diff --git a/base_classes/NXunit_cell.nxdl.xml b/base_classes/NXunit_cell.nxdl.xml new file mode 100644 index 0000000000..b20c22cbc1 --- /dev/null +++ b/base_classes/NXunit_cell.nxdl.xml @@ -0,0 +1,225 @@ + + + + + + + + Number of atom positions. + + + + + Description of a unit cell, i.e., the crystal structure of a single + thermodynamic phase. + + + + Identifier of an entry resolvable via crystallographic_database + which was used for creating this structure model. + + + + + Name of the crystallographic database to resolve + crystallographic_database_identifier e.g. COD, ICSD, or others. + + + + + A lattice system is a group of lattices with the same set of lattice point groups. + For further information, see https://en.wikipedia.org/wiki/Crystal_system. + + + + + + + + + + + + + + Crystallographic space group. + A space group is the symmetry group of a repeating pattern in space. + For further information, see International Table for Crystallography (https://it.iucr.org/). + + + + + Crystallographic point group. + A crystallographic point group is a set of symmetry operations, corresponding to one of the point groups in three dimensions, + such that each operation (perhaps followed by a translation) would leave the structure of a crystal unchanged. + This field should use Schoenflies notation (see Schoenflies, A., Krystallsysteme und Krystallstructur, 1891). + For further information, see https://dictionary.iucr.org/Point_group. + + + + + Laue group (also called Laue class). + The Laue classes are eleven geometric crystal classes containing centrosymmetric crystallographic types of point groups and their subgroups. + When absorption is negligible and Friedel's law applies, it is impossible to distinguish by diffraction between a centrosymmetric point group + and one of its non-centrosymmetric subgroups; only point groups belonging to different Laue classes can then be distinguished. + For further information, see https://dictionary.iucr.org/Laue_class. + + + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell vector a + + + + + + + For definining which coordinate system the unit cell vector a is defined in. + + + + + + Crystallography unit cell vector b + + + + + + + For definining which coordinate system the unit cell vector b is defined in. + + + + + + Crystallography unit cell vector c + + + + + + + For definining which coordinate system the unit cell vector c is defined in. + + + + + + Crystallography unit cell angles alpha, beta, and gamma + + + + + + + + Volume of the unit cell + + + + + + True if space group is considered a centrosymmetric one. + False if space group is considered a non-centrosymmetric one. + Centrosymmetric has all types and combinations of symmetry elements + (translation, rotational axis, mirror planes, center of inversion) + Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). + Chiral compared to non-centrosymmetric is constrained (no mirror planes). + + + + + True if space group is considered a chiral one. + False if space group is consider a non-chiral one. + + + + + Identifier for the phase. + The value 0 is reserved for the unknown phase which represents the null-model + that no phase model was sufficiently significantly confirmed. + + + + + Trivial name of the phase/alias. + + + + + Labels for each atom position + + + + + + + + The hash value :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Atom positions x, y, z. + + + + + + + + Reference to an instance of NXcoordinate_system whereby the positions can be + resolved. + + + + + + Relative occupancy of the atom position. + + + + + + + + For definining which coordinate system the unit cell parameters are defined in. + + + diff --git a/base_classes/NXuser.nxdl.xml b/base_classes/NXuser.nxdl.xml index 607d50e90a..e014584c2b 100644 --- a/base_classes/NXuser.nxdl.xml +++ b/base_classes/NXuser.nxdl.xml @@ -66,12 +66,13 @@ address/contact database - - - an author code, Open Researcher and Contributor ID, - defined by https://orcid.org and expressed as a URI - - + + + Details about an author code, open researcher, or contributor + (persistent) identifier, e.g. defined by https://orcid.org and expressed + as a URI. + + .. index:: plotting @@ -85,5 +86,4 @@ for a summary of the discussion. - - + \ No newline at end of file diff --git a/contributed_definitions/NXwaveplate.nxdl.xml b/base_classes/NXwaveplate.nxdl.xml similarity index 95% rename from contributed_definitions/NXwaveplate.nxdl.xml rename to base_classes/NXwaveplate.nxdl.xml index 52abcb0baa..02178ac9fa 100644 --- a/contributed_definitions/NXwaveplate.nxdl.xml +++ b/base_classes/NXwaveplate.nxdl.xml @@ -1,4 +1,4 @@ - + - - + + @@ -83,6 +84,11 @@ + + + Wavelength resolved retardence of the waveplate. + + Diameter of the waveplate. diff --git a/contributed_definitions/NXcalibration.nxdl.xml b/contributed_definitions/NXcalibration.nxdl.xml deleted file mode 100644 index 8dd7a6da55..0000000000 --- a/contributed_definitions/NXcalibration.nxdl.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - 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/NXellipsometry.nxdl.xml b/contributed_definitions/NXellipsometry.nxdl.xml deleted file mode 100644 index b082b310c9..0000000000 --- a/contributed_definitions/NXellipsometry.nxdl.xml +++ /dev/null @@ -1,357 +0,0 @@ - - - - - - - - - - - Variables used throughout the document, e.g. dimensions or parameters. - - - - Length of the spectrum array (e.g. wavelength or energy) of the measured - data. - - - - - Number of sensors used to measure parameters that influence the sample, - such as temperature or pressure. - - - - - Number of measurements (1st dimension of measured_data array). This is - equal to the number of parameters scanned. For example, if the experiment - was performed at three different temperatures and two different pressures - N_measurements = 2*3 = 6. - - - - - Number of detection angles of the beam reflected or scattered off the - sample. - - - - - Number of angles of incidence of the incident beam. - - - - - Number of observables that are saved in a measurement. e.g. one for - intensity, reflectivity or transmittance, two for Psi and Delta etc. This - is equal to the second dimension of the data array 'measured_data' and the - number of column names. - - - - - Number of time points measured, the length of NXsample/time_points - - - - - Ellipsometry, complex systems, up to variable angle spectroscopy. - - Information on ellipsometry is provided, e.g. in: - - * H. Fujiwara, Spectroscopic ellipsometry: principles and applications, - John Wiley & Sons, 2007. - * R. M. A. Azzam and N. M. Bashara, Ellipsometry and Polarized Light, - North-Holland Publishing Company, 1977. - * H. G. Tompkins and E. A. Irene, Handbook of Ellipsometry, - William Andrew, 2005. - - Open access sources: - - * https://www.angstromadvanced.com/resource.asp - * https://pypolar.readthedocs.io/en/latest/ - - Review articles: - - * T. E. Jenkins, "Multiple-angle-of-incidence ellipsometry", - J. Phys. D: Appl. Phys. 32, R45 (1999), - https://doi.org/10.1088/0022-3727/32/9/201 - * D. E. Aspnes, "Spectroscopic ellipsometry - Past, present, and future", - Thin Solid Films 571, 334-344 (2014), - https://doi.org/10.1016/j.tsf.2014.03.056 - * R. M. A. Azzam, "Mueller-matrix ellipsometry: a review", - Proc. SPIE 3121, Polarization: Measurement, Analysis, and Remote Sensing, - (3 October 1997), - https://doi.org/10.1117/12.283870 - * E. A. Irene, "Applications of spectroscopic ellipsometry to microelectronics", - Thin Solid Films 233, 96-111 (1993), - https://doi.org/10.1016/0040-6090(93)90069-2 - * S. Zollner et al., "Spectroscopic ellipsometry from 10 to 700 K", - Adv. Opt. Techn., (2022), - https://doi.org/10.1515/aot-2022-0016 - - - - This is the application definition describing ellipsometry experiments. - - Such experiments may be as simple as identifying how a reflected - beam of light with a single wavelength changes its polarization state, - to a variable angle spectroscopic ellipsometry experiment. - - The application definition defines: - - * elements of the experimental instrument - * calibration information if available - * parameters used to tune the state of the sample - * sample description - - - - An application definition for ellipsometry. - - - - Version number to identify which definition of this application - definition was used for this entry/data. - - - - - URL where to find further material (documentation, examples) relevant - to the application definition. - - - - - - - - - An optional free-text description of the experiment. - - However, details of the experiment should be defined in the specific - fields of this application definition rather than in this experiment - description. - - - - - Specify the type of ellipsometry. - - - - - - - - - - - - - - Properties of the ellipsometry equipment. - - - - Name of the company which build the instrument. - - - - - ISO8601 date when the instrument was constructed. - UTC offset should be specified. - - - - - - Commercial or otherwise defined given name of the program that was - used to generate the result file(s) with measured data and metadata. - This program converts the measured signals to ellipsometry data. If - home written, one can provide the actual steps in the NOTE subfield - here. - - - - - - What type of ellipsometry was used? See Fujiwara Table 4.2. - - - - - - - - - - - - - - - - - - - Define which element rotates, e.g. polarizer or analyzer. - - - - - - - - - - - - Specify the used light source. Multiple selection possible. - - - - - - - - - - - - - If focussing probes (lenses) were used, please state if the data - were corrected for the window effects. - - - - Were the recorded data corrected by the window effects of the - focussing probes (lenses)? - - - - - Specify the angular spread caused by the focussing probes. - - - - - - Properties of the detector used. Integration time is the count time - field, or the real time field. See their definition. - - - - - Properties of the rotating element defined in - 'instrument/rotating_element_type'. - - - - Define how many revolutions of the rotating element were averaged - for each measurement. If the number of revolutions was fixed to a - certain value use the field 'fixed_revolutions' instead. - - - - - Define how many revolutions of the rotating element were taken - into account for each measurement (if number of revolutions was - fixed to a certain value, i.e. not averaged). - - - - - Specify the maximum value of revolutions of the rotating element - for each measurement. - - - - - - The spectroscope element of the ellipsometer before the detector, - but often integrated to form one closed unit. Information on the - dispersive element can be specified in the subfield GRATING. Note - that different gratings might be used for different wavelength - ranges. The dispersion of the grating for each wavelength range can - be stored in grating_dispersion. - - - - - - - - Was the backside of the sample roughened? Relevant for infrared - ellipsometry. - - - - - - - Select which type of data was recorded, for example Psi and Delta - (see: https://en.wikipedia.org/wiki/Ellipsometry#Data_acquisition). - It is possible to have multiple selections. Data types may also be - converted to each other, e.g. a Mueller matrix contains N,C,S data - as well. This selection defines how many columns (N_observables) are - stored in the data array. - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml deleted file mode 100644 index 92be5ae595..0000000000 --- a/contributed_definitions/NXlens_em.nxdl.xml +++ /dev/null @@ -1,109 +0,0 @@ - - - - - - Description of an electro-magnetic lens or a compound lens. - - For 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 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>`_ - - - - Qualitative type of lens with respect to the number of pole pieces. - - - - - - - - - - - - Given name, alias, colloquial, or short name for the lens. - For manufacturer names and identifiers use respective manufacturer fields. - - - - - Name of the manufacturer who built/constructed the lens. - - - - - - Hardware name, hash identifier, or serial number that was given by the - manufacturer to identify the lens. - - - - - Ideally an identifier, persistent link, or free text which gives further details - about the lens. - - - - - Excitation voltage of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - Excitation current of the lens. For dipoles it is a single number. For higher - orders, it is an array. - - - - - This field should be used when the exact voltage or current of the lens is not directly controllable - as the control software of the microscope does not enable users/or is was not configured to enable - the user to retrieve these values. In this case this field should be used to specify the value as - read from the control software. Although consumers of the application definition should not expect - this value to represent the exact physical voltage or excitation, it is still useful to know though - as it allows other users to reuse this lens setting, which, provided a properly working instrument - and software should bring the lenses into a similar state. - - - - - Specifies the position of the lens by pointing to the last transformation in the - transformation chain in the NXtransformations group. - - - - - Collection of axis-based translations and rotations to describe the - location and geometry of the lens as a component in the instrument. - Typically, the components of a system should all be related relative to - each other and only one component should relate to the reference - coordinate system. - - - diff --git a/contributed_definitions/NXmanipulator.nxdl.xml b/contributed_definitions/NXmanipulator.nxdl.xml deleted file mode 100644 index dff2584fcf..0000000000 --- a/contributed_definitions/NXmanipulator.nxdl.xml +++ /dev/null @@ -1,100 +0,0 @@ - - - - - - Extension of NXpositioner to include fields to describe the use of manipulators - in photoemission experiments. - - - - Name of the manipulator. - - - - - A description of the manipulator. - - - - - Type of manipulator, Hexapod, Rod, etc. - - - - - Is cryocoolant flowing through the manipulator? - - - - - Temperature of the cryostat (coldest point) - - - - - Power in the heater for temperature control. - - - - - Temperature at the closest point to the sample. This field may also be found in - NXsample if present. - - - - - Current to neutralize the photoemission current. This field may also be found in - NXsample if present. - - - - - Possible bias of the sample with trespect to analyser ground. This field may - also be found in NXsample if present. - - - - - 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. - - -