diff --git a/.cspell/custom-dictionary.txt b/.cspell/custom-dictionary.txt index 5da39883a5..cbefe5838b 100644 --- a/.cspell/custom-dictionary.txt +++ b/.cspell/custom-dictionary.txt @@ -61,7 +61,8 @@ DCOM DFM DXRD Defocus -Delocalization, +Delocalization +EASI EBSD EBSP ECCI @@ -109,6 +110,7 @@ ISSN IVAS Idev Inconel +INDU Inplane Iontype Iontypes @@ -144,6 +146,7 @@ Raman Ronchigram SAS SAXS +SENB SERS SNSnxtranslate SPIE @@ -173,6 +176,7 @@ WWPDB XDMF XFEL XPCS +Xtranslation Zincblende Zirconate aabb @@ -254,6 +258,7 @@ detectorn deuterated diagionalized diffractogram +diffractograms disclination disorientations dispersoids @@ -313,7 +318,6 @@ hydroxonium hyperslab hyperspectral ibeam -illuminatable infty inplane interconvert @@ -491,6 +495,7 @@ underconstrained underload undulator unvalidated +varepsilon vibropolishing voxelated voxelization @@ -633,6 +638,7 @@ Ophus PANalytical Patala Pauly +Pawley Pedersen Peltier Pennycock @@ -646,6 +652,7 @@ Reichmann Reimer Remmele Rielli +Rietveld Rochon Rollett Romaner @@ -723,6 +730,21 @@ paraprobe-parmsetup-nanochem pynxtools pyxem +# Data plotting +azim +DAXIS +edgecolors +facecolors +figsize +fontsize +mplot +toolkits +verts +XAXIS +xlim +ylim +zlim + # other languages Institut @@ -767,6 +789,16 @@ recreatable speciality timeslot timestamping +tracability unlooped unranged -weared \ No newline at end of file +weared + +# to fix in future releases (all in NXstress) +acquistion +acquistions +asscociated +dimensioness +folowing +reproducability +Uncentrainties \ No newline at end of file diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml index dcdbbb2087..d5b7921f6f 100755 --- a/.github/workflows/ci.yaml +++ b/.github/workflows/ci.yaml @@ -81,6 +81,13 @@ jobs: texlive-fonts-recommended tex --version + - name: Install tools for SVG vector graphics support + run: | + sudo apt-get update -y && \ + sudo apt-get install -y \ + inkscape \ + imagemagick + - name: Generate build files env: GH_TOKEN: ${{ (env.python_version == env.python_deploy_version && (github.event.inputs.deploy || github.event.inputs.upload)) && secrets.GITHUB_TOKEN || 'NONE' }} diff --git a/README.md b/README.md index fc2de9e80c..7e083f2f59 100644 --- a/README.md +++ b/README.md @@ -7,6 +7,12 @@ ## NeXus definition developers +After making a change to the NeXus class definitions there are two important checks +to be made before commiting the change: + +1. check whether the change does not violate any syntax rules +2. verify whether the change looks as intended in the HTML documentation + First install the test and build requirements with this command (only run once) make install diff --git a/applications/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml index 95ccfa5576..75cd9d3b76 100644 --- a/applications/NXapm.nxdl.xml +++ b/applications/NXapm.nxdl.xml @@ -84,7 +84,7 @@ is considered as a narrow synonym for crystal defects. The aim of the NXapm application definition is to provide a general yet specific enough - solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments. + solution to serialize artifacts for virtually all atom probe and field-ion microscopy experiments. Before summarizing the design of the base classes and the parts of the NXapm application definition, it is worthwhile to recall and distinguish concepts that are related to atom extraction @@ -187,7 +187,7 @@ NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex - use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the + use cases. An example of this parent-optional-but-children-stronger-restricted design is the combination of the optional group ``measurement`` with its required child ``measurement/instrument``: Users which report simulations are not forced to document the instrument but users which have characterized a specimen are motivated to report about the instrument. They are though not necessarily required to report all @@ -215,7 +215,7 @@ considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations - and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the + and processing nonlinearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the conversion from time-of-flight to mass-to-charge-state-ratio values. Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how @@ -984,7 +984,7 @@ In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's M-TAP instruments, also use program1, program2, ... with program1 representing - the control software e.g. `M. Monajem and P. Felfer pyCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_. + the control software e.g. `M. Monajem and P. Felfer PYCCAPT <https://pyccapt.readthedocs.io/en/latest/>`_. Further instances (program2, ...) can be used to list the dependencies, the python virtual environment. diff --git a/applications/NXcanSAS.nxdl.xml b/applications/NXcanSAS.nxdl.xml index fd7f964db5..4297aeb6da 100644 --- a/applications/NXcanSAS.nxdl.xml +++ b/applications/NXcanSAS.nxdl.xml @@ -72,7 +72,7 @@ * NXcanSAS is for reduced SAS data and metadata to be stored together in one file. * *Reduced* SAS data consists of :math:`I(\vec{Q})` or :math:`I(|\vec{Q}|)` * External file links are not to be used for the reduced data. - * A good practice/practise is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. + * A good practice is, at least, to include a reference to how the data was acquired and processed. Yet this is not a requirement. * There is no need for NXcanSAS to refer to any raw data. The canSAS data format has a structure similar to NeXus, not identical. diff --git a/applications/NXellipsometry.nxdl.xml b/applications/NXellipsometry.nxdl.xml index 70a70e52af..3d27735f34 100644 --- a/applications/NXellipsometry.nxdl.xml +++ b/applications/NXellipsometry.nxdl.xml @@ -280,7 +280,7 @@ 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. + 'NAME' by the physical quantity that is used, e.g. wavelength. diff --git a/applications/NXem.nxdl.xml b/applications/NXem.nxdl.xml index 7cc6029eef..7b0420922a 100644 --- a/applications/NXem.nxdl.xml +++ b/applications/NXem.nxdl.xml @@ -89,7 +89,7 @@ relevant. NXem defines constraints on the existence and cardinality of concepts and its concept branches but seeks to offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended but their child concepts conditional required. Thereby, NXem can cover a variety - of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design + of simple but also complex use cases. An example of this parent-optional-but-children-stronger-restricted design is the combination of the optional group ``measurement`` with its required child ``measurement/instrument``: Users which report simulations are not forced to document the instrument but users which have characterized a sample are motivated to report about the instrument. They are though not @@ -414,8 +414,8 @@ The information is recorded to qualify if the beam used was likely able to shine through the specimen. For scanning electron microscopy, - in many cases the specimen is typically thicker than what is - illuminatable by the electron beam. + in many cases the specimen is typically thicker than what is illuminable + by the electron beam. In this case the value should be set to the actual thickness of the specimen viewed for an illumination situation where the nominal surface normal of the diff --git a/applications/NXstress.nxdl.xml b/applications/NXstress.nxdl.xml new file mode 100644 index 0000000000..dba688fac0 --- /dev/null +++ b/applications/NXstress.nxdl.xml @@ -0,0 +1,1149 @@ + + + + + + + Number of diffractogram channels. + + + Number of diffractograms. For example the number of energy-dispersive detectors or the number of azimuthal sections in an area detector. + + + Number of reflections. + + + Diffractogram X units. + + + Diffractogram Y units. + + + Converted diffractogram X units (could be the same as *x_Unit*). + + + number of temperatures + + + number of values in applied stress field + + + number of scan points (only present in scanning measurements) + + + number of detector pixels in the first (slowest) direction + + + number of detector pixels in the second (faster) direction + + + + Application definition for stress and strain analysis of crystalline material defined by the `EASI-STRESS consortium <https://easi-stress.eu>`_. + + When a crystal is loaded (applied or residual stress) its crystallographic parameters change. + + Stress and strain analysis calculates deformation (strain) and the associated force (stress) + from diffraction data. + + This application definition essentially standardizes the result of diffraction pattern analysis + from different types of diffraction experiments for the purpose of stress and strain analysis. + The analysis is typically some form of diffraction peak indexing and fitting. + The experiments are for example + + - energy-dispersive X-ray powder diffraction + - angular-dispersive X-ray powder diffraction + - angular-dispersive neutron powder diffraction + - time-of-flight (TOF) neutron powder diffraction. + + In addition, the application definition guarantees that the information about instrumental setups, measurement conditions, and data analysis workflows are described. + This ensures not only the reproducability and tracability of the measured data, but also the metadata. Since not all participating beamlines or instruments can provide an input to all the NeXus fields listed in this application definition, not all of them are "required". + + However, when possible and technically feasible, the instrument using the NXstress application definition is expected to provide the type of information outlined below. + + Sample and detector positions can be defined with :ref:`NXtransformations`. If you don't specify the direction of gravity + and the direction of the beam then the standard NeXus Coordinate System is used. + + It is highly recommended that when certain parameters or values are the same for all the measurements (acquistions) in the same + file, they are stored only in one location and then linked in the other instances. For example, if during an acquisition all + + instrumental parameters but one stay the same and only the sample table moves in one direction (e.g. Xtranslation), then all the + static instrumental parameters should be saved just once (e.g. in just one NXentry or in a *Shared_Information group*) and their + values linked to every *instrument group* under all the other acquisitions. The value for the variable that changes, Xtranslation + in this example, is suggested to be saved only at every instrument group under each acquistion but not in the *Shared_Information group*. + + It is not always necessary to link each field. In case all the fields with an entire group are the same, the entire group can be linked. + + + + + The name of the *NXentry group(s)* can be freely chosen by the facility. The *NXentry group* can contain any form of data acquisition (e.g. a measurement point, multiple measurement points, a line scan, a mesh, all data points from one sample …). + + + Official NeXus NXDL schema to which this file conforms + + + + + + Extended title for the entry. + + + + Unique identifier for the experiment as defined by the facility (e.g. DOI, proposal id, ...). At ILL, this could be, for example, ``exp_1-02-286``, ``exp_INDU-229``, or ``exp_INTER-569``. + + + + + Brief summary of the experiment, including key objectives. At least one of the following information should be provided: + * ``energy-dispersive X-ray powder diffraction`` + * ``angular-dispersive X-ray powder diffraction`` + * ``angular-dispersive neutron powder diffraction`` + * ``time-of-flight (TOF) neutron powder diffraction`` + + + + + + The starting time(s) of measurement(s) which can be provided in form of a list if multiple measurements are included in the same NXentry. + + + + + The end time(s) of measurement(s) which can be provided in form of a list if multiple measurements are included in the same NXentry. + + + + + + User or Data Acquisition defined identifier from which + the content of this application definition is derived. This can be freely chosen by the user or the instrument scientist and could be, for example, ``05_DA_650_AX_B3P5``, ``SENB-14``, ``Quartz``,.... + + + + + Brief summary of the collection, including grouping criteria. The information provided in this field can highlight, for example, the measurement setup or information about experimental conditions. + + + + + Describes the way strain :math:`\varepsilon` can be calculated from the :ref:`center </NXstress/ENTRY/peaks/center-field>` + peak parameter. + + + + + :math:`\varepsilon = \large \frac{sin(\mathrm{\theta}_{0})}{sin(\mathrm{\theta})}-1` + + + + + :math:`\varepsilon = \large \frac{\mathrm{E}_{0}}{\mathrm{E}}-1` + + + + + :math:`\varepsilon = \large \frac{\mathrm{d}}{\mathrm{d}_{0}}-1` + + + + + :math:`\varepsilon = \large \frac{\mathrm{TOF}}{\mathrm{TOF}_{0}}-1` + + + + + A description of the :math:`\mathrm{\sin}^{2}\psi` method can be found in the literature. Two examples are + `Fitzpatrick et al. 2005 <http://eprintspublications.npl.co.uk/id/eprint/2391>`_ + and + `DIN ISO 15305:2009-01 <https://www.en-standard.eu/din-en-15305-non-destructive-testing-test-method-for-residual-stress-analysis-by-x-ray-diffraction/>`_. + + + + + + + Describes the specific measurement direction covered by the data in this file. + + + + + + + + + + + Information about the person who performed the experiment. + + + + Role of user responsible for this entry. Suggested roes are, for example, ``local contact``, ``beamline_scientist``, ``post_doc``,… + + + + + Name of the diffractometer, instrument, or beamline used for the experiment. This could be, for example, *Strain Analyser for Large and Small scale engineering Applications*. + + Short name for the instrument, perhaps the acronym, which would be for the the example above ``SALSA``. + + + + This group contains information about the geometry and/or efficiency measurement(s). + + Describe the type of calibration. + + + File name(s) and/or path(s) (within file(s)) containing data from the last calibration(s). This can be an array. + + + + Calibration file content. + + + Mime content type of calibration *data* field e.g. text/plain, application/json,... + + + Author or creator of the calibration. + + + Date calibration was created/added + + + + + + Type of radiation source + + + + + + + + + + + + + + Type of radiation probe + + + + + + + + + Zero or more of these groups describe the detectors used in the experiment. + + name/manufacturer/model/etc. information + + + + Description of type such as \ :sup:`3`\ He gas cylinder, \ :sup:`3`\ He PSD, scintillator, fission chamber, proportion counter, ion chamber, CCD, pixel, image plate, CMOS, … + + + + + This is the distance to the previous component in the + instrument; most often the sample. The usage depends on the + nature of the detector: Most often it is the distance of the + detector assembly. But there are irregular detectors. In this + case the distance must be specified for each detector pixel. + + Note, it is recommended to use NXtransformations instead. + + + + + + + + + + efficiency of the detector + + + + + + + + This field can be two things: + + 1. For a pixel detector it provides the nominal wavelength + for which the detector has been calibrated. + + 2. For other detectors this field has to be seen together with + the efficiency field above. + For some detectors, the efficiency is wavelength dependent. + Thus this field provides the wavelength axis for the efficiency field. + In this use case, the efficiency and wavelength arrays must + have the same dimensionality. + + + + + + + + Detector dead time + + + + + + + + Elapsed actual counting time + + + + + + + The axis on which the detector position depends may be stored + anywhere, but is normally stored in the *NXtransformations + group* within the *NXdetector group*. + + + + + This is the recommended location for detector goniometer + and other related axes. + + + + + + Defines the dimensions of the beam profile used for probing the sample which corresponds to or can be used to determine the instrumental gauge volume. + A description of the subsequent fields can be found in the folowing figure. The term "primary" in the subsequent fields refers to the beam path between the sample and the source. The term "secondary" refers to the beam path between the sample and the detector(s). + + .. figure:: stress/Beam_profile_sketch3.jpg + :width: 70% + :alt: Examples for the beam intensity profile. + + Some examples for the beam intensity profile. The 1D description of the beam profile on the right can equally be applied for the horizontal and vertical direction for the primary and the secondary side. + + + + If the beam profile was measured, the filename(s) of the measurement can be specified here. + + + + Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. + + + + Defines the primary beam size intensity profile on the side closer to the source in the vertical direction. + + + + + Defines the primary beam size intensity profile on the side closer to the sample in the vertical direction. + + + + + Defines the distance between the center of the gauge volume and the beam shaping device. + + + + + Describes how the beam intensity profile in the primary vertical direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... + + + + + Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. + + + + Defines the primary beam size intensity profile on the side closer to the source in the horizontal direction. + + + + + Defines the primary beam size intensity profile on the side closer to the sample in the horizontal direction. + + + + + Defines the distance between the center of the gauge volume and the beam shaping device. + + + + + Describes how the beam intensity profile in the primary horizontal direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... + + + + + Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. + + + + Defines the secondary beam size intensity profile on the side closer to the detector in the horizontal direction. + + + + + Defines the secondary beam size intensity profile on the side closer to the sample in the horizontal direction. + + + + + Defines the distance between the center of the gauge volume and the beam shaping device. + + + + + Describes how the beam intensity profile in the secondary horizontal direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... + + + + Incident energy mostly useful for monochromatic beams. + + + Incident wavelength mostly useful for monochromatic beams. + + + + + + + This is the recommended location for describing parameters associated with the sample. + + + + Descriptive name of sample + + + + + The chemical formula specified using CIF conventions. + Abbreviated version of CIF standard: + + * Only recognized element symbols may be used. + * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. + * A space or parenthesis must separate each cluster of (element symbol + count). + * Where a group of elements is enclosed in parentheses, the multiplier for the + group must follow the closing parentheses. That is, all element and group + multipliers are assumed to be printed as subscripted numbers. + * Unless the elements are ordered in a manner that corresponds to their chemical + structure, the order of the elements within any group or moiety depends on + whether or not carbon is present. + * If carbon is present, the order should be: + + - C, then H, then the other elements in alphabetical order of their symbol. + - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. + + * This is the *Hill* system used by Chemical Abstracts. + + + + Sample temperature. This could be a scanned variable + + + + + + Applied external stress field + + + + + + + + + + + + + The gauge volume can be described with the following parameters: + .. figure:: stress/gauge_volume.png + :width: 70% + :alt: Gauge volume parameters and coordinate system. + + Gauge volume parameters and coordinate system. + + + + Length of the first diagonal. + + + + + Length of the second diagonal normal to :ref:`x </NXstress/ENTRY/sample_description/gauge_volume/a-field>`. + + + + + Height of the gauge volume. + + + + + In the local coordinate system, the beam is aligned along the X-axis, + and the Z-axis is oriented in the opposite direction of gravity. The origin + is the center to the gauge volume. + + + + + The last field typically depends on the first + field of the :ref:`sample transformations </NXstress/ENTRY/SAMPLE_DESCRIPTION/TRANSFORMATIONS-group>`. + + + + + + The axis on which the sample position depends may be stored + anywhere, but is normally stored in the NXtransformations + group within the NXsample group. + + + + + This is the recommended location for sample goniometer + and other related axes. + + + + + + + Zero or more groups to describe the data processing steps + to obtain the content of this application definition. + + + + The raw data file name(s) used during the data reduction process. This can be a list. + + + + + Date when the raw data was reduced and the data in the *NXstress* file format generated. + + + + + Software package used to perform data reduction including the version number or release date. + + + + + Describes how the data was integrated. + + + + + Describes the type of binning used during data reduction. + + + + + Describes how the fitting of the peaks was done. For example, single peak fit, multiple peak fit, Pawley refinement, Rietveld refinement, … + + + + + Describes the data range used for peak fitting. + + + + + Type and value describing the goodness of fit. For example, Rw 0.23. + + + + + Describes whether the data was normalized and if so , how. Examples of valid entries are: ``None``, ``time``, ``primary monitor``, ``detector``, … + + + + Information about the person who performed the data reduction. + + + + Role of user responsible for this entry. Suggested roles are, for example, ``local contact``, ``beamline_scientist``, ``post_doc``,… + + + + + The note will contain information about how the data was processed + or anything about the data provenance. + The contents of the note can be anything that the processing code + can understand, or a simple text. + + The name will be numbered to allow for ordering of steps. + + + + + This group contains all diffraction peak fit parameters. + This information is not required for stress and strain calculations. + + + Diffraction peak profile. + + + + + + + + + + + + Diffraction peak area (not including the background) in *y_Unit* units. + + + + + Specify the *y_Unit* units + + + + + Error value(s) asscociated with :ref:`area </NXstress/ENTRY/fit/peak_parameters/area-field>` + + + + + + + + Diffraction peak position in *x_Unit* units. + + + + + Specify the *x_Unit* units + + + + + Error value(s) asscociated with :ref:`center </NXstress/ENTRY/fit/peak_parameters/center-field>` + + + + + + + + Diffraction peak height (not including the background) in *y_Unit* units. + + + + + Specify the *y_Unit* units + + + + + Error value(s) asscociated with :ref:`height </NXstress/ENTRY/fit/peak_parameters/height-field>` + + + + + + + + Diffraction peak full width at half maximum in *x_Unit* units. + + + + + Specify the *x_Unit* units + + + + + Error value(s) asscociated with :ref:`fwhm </NXstress/ENTRY/fit/peak_parameters/fwhm-field>` + + + + + + + + Left-side FWHM for split profiles in *x_Unit* units. + + + + + Specify the *x_Unit* units + + + + + Error value(s) asscociated with :ref:`fwhm_left </NXstress/ENTRY/fit/peak_parameters/fwhm_left-field>` + + + + + + + + Right-side FWHM for split profiles in *x_Unit* units. + + + + + Specify the *x_Unit* units + + + + + Error value(s) asscociated with :ref:`fwhm_right </NXstress/ENTRY/fit/peak_parameters/fwhm_right-field>` + + + + + + + + + - Voigt or Pseudo-Voigt: Lorentzian fraction + - Pearson VII: decay parameter + - Other profiles: not applicable + + + + + + + + Error value(s) asscociated with :ref:`form_factor </NXstress/ENTRY/fit/peak_parameters/form_factor-field>` + + + + + + + + + Angle that defines the position of the integrated sector in the diffraction cone + for angular-dispersive diffraction or the position of the detector for energy-dispersive + diffraction. + + + + + + + + + This group contains all background fit parameters. + This information is not required for stress and strain calculations. + + + + Diffraction background profile. Required when background parameter fields are present. + Some example values with equations are shown below: + + - ``manual`` : No equations nor variables needed to describe this background. + - ``linear`` : \ :math:`\small background= A0 + A1 \cdot x` + - ``5-degree polynomial`` : \ :math:`\small background= A0 + A1 \cdot x + A2 \cdot \mathrm{x}^{2} + A3 \cdot \mathrm{x}^{3} + A4 \cdot \mathrm{x}^{4} + A5 \cdot \mathrm{x}^{5}` + - ``shape function plus polynomial`` : A shape function is not a mathematical function, it contains a manual background obtained from a fit and a polynomial part. This allows to adapt and modify the fit for subsequent measurements in the same measurement campaign. The function describing it is the following: \ :math:`\small background= as + b \cdot SHAPE(x-o)` Where SHAPE is the name of the variable used to describe the background value at the position x. x can be e.g. the scattering angle \ :math:`2\theta` in degrees. + + + + Background parameter(s). For example a second-degree polynomial will have fields ``A0``, ``A1`` and ``A2``. + + + + + + Background parameter *constant* for SHAPE function. + + + + + + Error associated with background parameter *constant* for SHAPE function. + + + + + + Background parameter *amplitude* for SHAPE function. + + + + + + Error associated with background parameter *amplitude* for SHAPE function. + + + + + + Background parameter *offset* for SHAPE function. + + + + + + Error associated with background parameter *offset* for SHAPE function. + + + + + + The background area in *y_Unit* units, integrated over a confidence interval around the center (*0.95* by default). + + + + + Specify the *y_Unit* units + + + + + Confidence interval from which the background counts are integrated. + For example *0.95* means that the background is integrated over the range in + which the integrated peak area is 95% of the total peak area. + + + + + + + Diffractogram with fit results in :ref:`peak_parameters </NXstress/ENTRY/fit/peak_parameters-group>` + and :ref:`background_parameters </NXstress/ENTRY/fit/background_parameters-group>`. + This information is not required for stress and strain calculations. + + + List of the one to two axes field name(s) to be used by default. The axes are further described in the fields DAXIS and XAXIS. + + + + + One or more fields that contain the values for the **n_D** dimension. + For example the azimuthal positions of different energy-dispersive detectors + or the average azimuth of different azimuthal sections on an area detector. + + + + + + + + + One or more fields that contain the values for the **n_X** dimension in *x_Unit* units. + For example: MCA channels, scattering angle \ :math:`2\theta` in degrees, + scattering vector length q in \ :math:`\mathrm{nm}^{-1}`, ... + + + + + + Specify the *x_Unit* units + + + + + Default field name to be plotted. + + + + + + + List of additional field names to be plotted. This could be e.g. fit, background, residuals, … + + + + Diffractogram counts in *y_Unit* units (default signal) + + + + + + + + + + + Specify the *y_Unit* units + + + + + Diffractogram counts error in *y_Unit* units (default signal) + + + + + + + + + + + Specify the *y_Unit* units + + + + + Diffractogram fit counts (auxiliary signal). + + + + + + + + + + + + + Diffractogram fit counts error (auxiliary signal). + + + + + + + + In case the diffraction background was manually determined. Diffractogram background counts (auxiliary signal). + + + + + + + + + + + + Difference between diffractogram and fit (auxiliary signal). + + + + + + + + + + + + + + + + User description of the data acquisitions. + A description of data analysis goes in the + :ref:`fit descriptions </NXstress/ENTRY/FIT/DESCRIPTION-group>`. + + + + + + This group contains all diffraction peak parameters that could be needed for stress and strain calculations. + These parameters are derived from :ref:`peak_parameters </NXstress/ENTRY/fit/peak_parameters-group>` and additional metadata. + + + First Miller index. + + + + + + Second Miller index. + + + + + + Third Miller index. + + + + + + Crystal lattice systems (*cubic*, *hexagonal*, ...) + + + + + + Crystallographic space group :math:`(Fm\bar{3}m, Im\bar{3}m, ...)` + + + + + + Name of the crystallographic phase (hematite, goethite, \ :math:`\alpha`-Al\ :sub:`2`\ O\ :sub:`3`\ , ...). + + + + + + + First component of the *normalized* scattering vector *Q* in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + + Second component of the *normalized* scattering vector *Q* in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + + Third component of the *normalized* scattering vector *Q* in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + Diffraction peak position in *c_Unit* units. + + + + + Specify the *c_Unit* units (see :ref:`center_type </NXstress/ENTRY/peaks/center_type-field>`) + + + two-theta + + + energy + + + momentum-transfer + + + d-spacing + + + time-of-flight + + + channel (dimensionless) + + + + + + Uncentrainties on :ref:`center </NXstress/ENTRY/peaks/center-field>` in *c_Unit* units. + + + + + Specify the *c_Unit* units (see :ref:`center_type </NXstress/ENTRY/peaks/center_type-field>`) + + + two-theta + + + energy + + + momentum-transfer + + + d-spacing + + + time-of-flight + + + channel (dimensionless) + + + + + + + The space in which :ref:`center </NXstress/ENTRY/peaks/center-field>` is defined. + It defines the *c_Unit* as follows + + - if *center_type="two-theta"* then *c_Unit* must have the angle unit *degrees* + - if *center_type="energy"* then *c_Unit* must have the unit *keV* + - if *center_type="momentum-transfer"* then *c_Unit* must have the unit \ :math:`Å^{-1}` + - if *center_type="d-spacing"* then *c_Unit* must have the unit \ :math:`Å` + - if *center_type="channel"* then *c_Unit* must be *dimensioness* + - if *center_type="time-of-flight"* then *c_Unit* must have the unit \ :math:`\mu\mathrm{s}` + + + + + + + + + + + + + First component of the sample position in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + + + First component of the sample position in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + + First component of the sample position in the sample reference frame. + The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. + + + + + + + + + diff --git a/applications/NXtomoproc.nxdl.xml b/applications/NXtomoproc.nxdl.xml index 163cde233a..5230cb89a9 100644 --- a/applications/NXtomoproc.nxdl.xml +++ b/applications/NXtomoproc.nxdl.xml @@ -83,7 +83,7 @@ - + This is the reconstructed volume. This can be different things. Please indicate in the unit attribute what physical @@ -91,7 +91,7 @@ - + diff --git a/applications/NXxps.nxdl.xml b/applications/NXxps.nxdl.xml index e38757fab5..3f4832247a 100644 --- a/applications/NXxps.nxdl.xml +++ b/applications/NXxps.nxdl.xml @@ -142,7 +142,7 @@ Reference to the transformation describing the direction of the beam relative to a defined coordinate system. - + Should point to /entry/instrument/beam_probe/transformations/beam_direction. @@ -199,7 +199,8 @@ - This should point to the coordinate system defined in /entry/xps_coordinate_system. + This should point to the coordinate system defined in + /entry/xps_coordinate_system. @@ -251,7 +252,8 @@ - Azimuthal rotation of the analyzer from the y-direction defined by the sample stage. + Azimuthal rotation of the analyzer from the y-direction defined by the sample + stage. @@ -265,7 +267,8 @@ - This should point to the coordinate system defined in /entry/xps_coordinate_system. + This should point to the coordinate system defined in + /entry/xps_coordinate_system. @@ -481,7 +484,7 @@ Area of the peak. - + Width of a peak at a defined fraction of the peak height. @@ -578,7 +581,7 @@ modeling the XPS background in situations where the background is integrated from the peak intensities at each binding energy to higher kinetic energies. It is useful when fitting the background in spectra that display significant low-energy tailing or when the background - exhibits a non-linear rise with binding energy. + exhibits a nonlinear rise with binding energy. The model incorporates the notion of electron energy loss and the behavior of the photoelectrons as they travel through the material and lose energy. It is a more sophisticated background @@ -708,7 +711,8 @@ - Azimuthal rotation of the sample from the y-direction defined by the sample stage. + Azimuthal rotation of the sample from the y-direction defined by the sample + stage. @@ -722,7 +726,8 @@ - This should point to the coordinate system defined in /entry/xps_coordinate_system. + This should point to the coordinate system defined in + /entry/xps_coordinate_system. diff --git a/applications/nyaml/NXapm.yaml b/applications/nyaml/NXapm.yaml index 3dc6fc8efa..7ef94f4a3e 100644 --- a/applications/nyaml/NXapm.yaml +++ b/applications/nyaml/NXapm.yaml @@ -13,7 +13,7 @@ doc: | is considered as a narrow synonym for crystal defects. The aim of the NXapm application definition is to provide a general yet specific enough - solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments. + solution to serialize artifacts for virtually all atom probe and field-ion microscopy experiments. Before summarizing the design of the base classes and the parts of the NXapm application definition, it is worthwhile to recall and distinguish concepts that are related to atom extraction @@ -116,7 +116,7 @@ doc: | NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex - use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the + use cases. An example of this parent-optional-but-children-stronger-restricted design is the combination of the optional group ``measurement`` with its required child ``measurement/instrument``: Users which report simulations are not forced to document the instrument but users which have characterized a specimen are motivated to report about the instrument. They are though not necessarily required to report all @@ -144,7 +144,7 @@ doc: | considered best practice by AMETEK/Cameca, ``raw_data`` for delay-line timing data, ``hit_finding`` for details of the hit finding algorithm, ``hit_spatial_filtering`` a process that filters hits of too low quality and those laying outside the about to be computed reconstruction volume. Furthermore, group ``voltage_and_bowl`` offers a place for documenting calibrations - and processing non-linearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the + and processing nonlinearities. Group ``mass_to_charge_conversion`` is used to document the mass calibration and the conversion from time-of-flight to mass-to-charge-state-ratio values. Finally, the groups ``reconstruction`` and ``ranging`` were designed to match and document the classical approaches how @@ -910,7 +910,7 @@ NXapm(NXobject): In the case of an open-source instrument, like P. Felfer's Oxcart or G. Schmitz's M-TAP instruments, also use program1, program2, ... with program1 representing - the control software e.g. `M. Monajem and P. Felfer pyCCAPT `_. + the control software e.g. `M. Monajem and P. Felfer PYCCAPT `_. Further instances (program2, ...) can be used to list the dependencies, the python virtual environment. program(NX_CHAR): @@ -1537,7 +1537,7 @@ NXapm(NXobject): dim: (n,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 2642b118e31af3d0c5cf93a12ba96d32f0458074c69b36c51821bfa5307ef97c +# 536d6cfd33b104dc536f9c1639cc26cb665ec85143a23181602c1dd15487834f # # # +# +# +# +# Number of diffractogram channels. +# +# +# Number of diffractograms. For example the number of energy-dispersive detectors or the number of azimuthal sections in an area detector. +# +# +# Number of reflections. +# +# +# Diffractogram X units. +# +# +# Diffractogram Y units. +# +# +# Converted diffractogram X units (could be the same as *x_Unit*). +# +# +# number of temperatures +# +# +# number of values in applied stress field +# +# +# number of scan points (only present in scanning measurements) +# +# +# number of detector pixels in the first (slowest) direction +# +# +# number of detector pixels in the second (faster) direction +# +# +# +# Application definition for stress and strain analysis of crystalline material defined by the `EASI-STRESS consortium <https://easi-stress.eu>`_. +# +# When a crystal is loaded (applied or residual stress) its crystallographic parameters change. +# +# Stress and strain analysis calculates deformation (strain) and the associated force (stress) +# from diffraction data. +# +# This application definition essentially standardizes the result of diffraction pattern analysis +# from different types of diffraction experiments for the purpose of stress and strain analysis. +# The analysis is typically some form of diffraction peak indexing and fitting. +# The experiments are for example +# +# - energy-dispersive X-ray powder diffraction +# - angular-dispersive X-ray powder diffraction +# - angular-dispersive neutron powder diffraction +# - time-of-flight (TOF) neutron powder diffraction. +# +# In addition, the application definition guarantees that the information about instrumental setups, measurement conditions, and data analysis workflows are described. +# This ensures not only the reproducability and tracability of the measured data, but also the metadata. Since not all participating beamlines or instruments can provide an input to all the NeXus fields listed in this application definition, not all of them are "required". +# +# However, when possible and technically feasible, the instrument using the NXstress application definition is expected to provide the type of information outlined below. +# +# Sample and detector positions can be defined with :ref:`NXtransformations`. If you don't specify the direction of gravity +# and the direction of the beam then the standard NeXus Coordinate System is used. +# +# It is highly recommended that when certain parameters or values are the same for all the measurements (acquistions) in the same +# file, they are stored only in one location and then linked in the other instances. For example, if during an acquisition all +# +# instrumental parameters but one stay the same and only the sample table moves in one direction (e.g. Xtranslation), then all the +# static instrumental parameters should be saved just once (e.g. in just one NXentry or in a *Shared_Information group*) and their +# values linked to every *instrument group* under all the other acquisitions. The value for the variable that changes, Xtranslation +# in this example, is suggested to be saved only at every instrument group under each acquistion but not in the *Shared_Information group*. +# +# It is not always necessary to link each field. In case all the fields with an entire group are the same, the entire group can be linked. +# +# +# +# +# The name of the *NXentry group(s)* can be freely chosen by the facility. The *NXentry group* can contain any form of data acquisition (e.g. a measurement point, multiple measurement points, a line scan, a mesh, all data points from one sample …). +# +# +# Official NeXus NXDL schema to which this file conforms +# +# +# +# +# +# Extended title for the entry. +# +# +# +# Unique identifier for the experiment as defined by the facility (e.g. DOI, proposal id, ...). At ILL, this could be, for example, ``exp_1-02-286``, ``exp_INDU-229``, or ``exp_INTER-569``. +# +# +# +# +# Brief summary of the experiment, including key objectives. At least one of the following information should be provided: +# * ``energy-dispersive X-ray powder diffraction`` +# * ``angular-dispersive X-ray powder diffraction`` +# * ``angular-dispersive neutron powder diffraction`` +# * ``time-of-flight (TOF) neutron powder diffraction`` +# +# +# +# +# +# The starting time(s) of measurement(s) which can be provided in form of a list if multiple measurements are included in the same NXentry. +# +# +# +# +# The end time(s) of measurement(s) which can be provided in form of a list if multiple measurements are included in the same NXentry. +# +# +# +# +# +# User or Data Acquisition defined identifier from which +# the content of this application definition is derived. This can be freely chosen by the user or the instrument scientist and could be, for example, ``05_DA_650_AX_B3P5``, ``SENB-14``, ``Quartz``,.... +# +# +# +# +# Brief summary of the collection, including grouping criteria. The information provided in this field can highlight, for example, the measurement setup or information about experimental conditions. +# +# +# +# +# Describes the way strain :math:`\varepsilon` can be calculated from the :ref:`center </NXstress/ENTRY/peaks/center-field>` +# peak parameter. +# +# +# +# +# :math:`\varepsilon = \large \frac{sin(\mathrm{\theta}_{0})}{sin(\mathrm{\theta})}-1` +# +# +# +# +# :math:`\varepsilon = \large \frac{\mathrm{E}_{0}}{\mathrm{E}}-1` +# +# +# +# +# :math:`\varepsilon = \large \frac{\mathrm{d}}{\mathrm{d}_{0}}-1` +# +# +# +# +# :math:`\varepsilon = \large \frac{\mathrm{TOF}}{\mathrm{TOF}_{0}}-1` +# +# +# +# +# A description of the :math:`\mathrm{\sin}^{2}\psi` method can be found in the literature. Two examples are +# `Fitzpatrick et al. 2005 <http://eprintspublications.npl.co.uk/id/eprint/2391>`_ +# and +# `DIN ISO 15305:2009-01 <https://www.en-standard.eu/din-en-15305-non-destructive-testing-test-method-for-residual-stress-analysis-by-x-ray-diffraction/>`_. +# +# +# +# +# +# +# Describes the specific measurement direction covered by the data in this file. +# +# +# +# +# +# +# +# +# +# +# Information about the person who performed the experiment. +# +# +# +# Role of user responsible for this entry. Suggested roes are, for example, ``local contact``, ``beamline_scientist``, ``post_doc``,… +# +# +# +# +# Name of the diffractometer, instrument, or beamline used for the experiment. This could be, for example, *Strain Analyser for Large and Small scale engineering Applications*. +# +# Short name for the instrument, perhaps the acronym, which would be for the the example above ``SALSA``. +# +# +# +# This group contains information about the geometry and/or efficiency measurement(s). +# +# Describe the type of calibration. +# +# +# File name(s) and/or path(s) (within file(s)) containing data from the last calibration(s). This can be an array. +# +# +# +# Calibration file content. +# +# +# Mime content type of calibration *data* field e.g. text/plain, application/json,... +# +# +# Author or creator of the calibration. +# +# +# Date calibration was created/added +# +# +# +# +# +# Type of radiation source +# +# +# +# +# +# +# +# +# +# +# +# +# +# Type of radiation probe +# +# +# +# +# +# +# +# +# Zero or more of these groups describe the detectors used in the experiment. +# +# name/manufacturer/model/etc. information +# +# +# +# Description of type such as \ :sup:`3`\ He gas cylinder, \ :sup:`3`\ He PSD, scintillator, fission chamber, proportion counter, ion chamber, CCD, pixel, image plate, CMOS, … +# +# +# +# +# This is the distance to the previous component in the +# instrument; most often the sample. The usage depends on the +# nature of the detector: Most often it is the distance of the +# detector assembly. But there are irregular detectors. In this +# case the distance must be specified for each detector pixel. +# +# Note, it is recommended to use NXtransformations instead. +# +# +# +# +# +# +# +# +# +# efficiency of the detector +# +# +# +# +# +# +# +# This field can be two things: +# +# 1. For a pixel detector it provides the nominal wavelength +# for which the detector has been calibrated. +# +# 2. For other detectors this field has to be seen together with +# the efficiency field above. +# For some detectors, the efficiency is wavelength dependent. +# Thus this field provides the wavelength axis for the efficiency field. +# In this use case, the efficiency and wavelength arrays must +# have the same dimensionality. +# +# +# +# +# +# +# +# Detector dead time +# +# +# +# +# +# +# +# Elapsed actual counting time +# +# +# +# +# +# +# The axis on which the detector position depends may be stored +# anywhere, but is normally stored in the *NXtransformations +# group* within the *NXdetector group*. +# +# +# +# +# This is the recommended location for detector goniometer +# and other related axes. +# +# +# +# +# +# Defines the dimensions of the beam profile used for probing the sample which corresponds to or can be used to determine the instrumental gauge volume. +# A description of the subsequent fields can be found in the folowing figure. The term "primary" in the subsequent fields refers to the beam path between the sample and the source. The term "secondary" refers to the beam path between the sample and the detector(s). +# +# .. figure:: stress/Beam_profile_sketch3.jpg +# :width: 70% +# :alt: Examples for the beam intensity profile. +# +# Some examples for the beam intensity profile. The 1D description of the beam profile on the right can equally be applied for the horizontal and vertical direction for the primary and the secondary side. +# +# +# +# If the beam profile was measured, the filename(s) of the measurement can be specified here. +# +# +# +# Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. +# +# +# +# Defines the primary beam size intensity profile on the side closer to the source in the vertical direction. +# +# +# +# +# Defines the primary beam size intensity profile on the side closer to the sample in the vertical direction. +# +# +# +# +# Defines the distance between the center of the gauge volume and the beam shaping device. +# +# +# +# +# Describes how the beam intensity profile in the primary vertical direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... +# +# +# +# +# Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. +# +# +# +# Defines the primary beam size intensity profile on the side closer to the source in the horizontal direction. +# +# +# +# +# Defines the primary beam size intensity profile on the side closer to the sample in the horizontal direction. +# +# +# +# +# Defines the distance between the center of the gauge volume and the beam shaping device. +# +# +# +# +# Describes how the beam intensity profile in the primary horizontal direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... +# +# +# +# +# Defines the last device right in front of the sample used to shape the beam. This could be, for example, a :ref:`(radial) collimator <NXcollimator>` or a :ref:`slit <NXslit>`. +# +# +# +# Defines the secondary beam size intensity profile on the side closer to the detector in the horizontal direction. +# +# +# +# +# Defines the secondary beam size intensity profile on the side closer to the sample in the horizontal direction. +# +# +# +# +# Defines the distance between the center of the gauge volume and the beam shaping device. +# +# +# +# +# Describes how the beam intensity profile in the secondary horizontal direction was determined. Examples of valid entries are: ``measured``, ``theoretical``, ``estimated``, ... +# +# +# +# Incident energy mostly useful for monochromatic beams. +# +# +# Incident wavelength mostly useful for monochromatic beams. +# +# +# +# +# +# +# This is the recommended location for describing parameters associated with the sample. +# +# +# +# Descriptive name of sample +# +# +# +# +# The chemical formula specified using CIF conventions. +# Abbreviated version of CIF standard: +# +# * Only recognized element symbols may be used. +# * Each element symbol is followed by a 'count' number. A count of '1' may be omitted. +# * A space or parenthesis must separate each cluster of (element symbol + count). +# * Where a group of elements is enclosed in parentheses, the multiplier for the +# group must follow the closing parentheses. That is, all element and group +# multipliers are assumed to be printed as subscripted numbers. +# * Unless the elements are ordered in a manner that corresponds to their chemical +# structure, the order of the elements within any group or moiety depends on +# whether or not carbon is present. +# * If carbon is present, the order should be: +# +# - C, then H, then the other elements in alphabetical order of their symbol. +# - If carbon is not present, the elements are listed purely in alphabetic order of their symbol. +# +# * This is the *Hill* system used by Chemical Abstracts. +# +# +# +# Sample temperature. This could be a scanned variable +# +# +# +# +# +# Applied external stress field +# +# +# +# +# +# +# +# +# +# +# +# +# The gauge volume can be described with the following parameters: +# .. figure:: stress/gauge_volume.png +# :width: 70% +# :alt: Gauge volume parameters and coordinate system. +# +# Gauge volume parameters and coordinate system. +# +# +# +# Length of the first diagonal. +# +# +# +# +# Length of the second diagonal normal to :ref:`x </NXstress/ENTRY/sample_description/gauge_volume/a-field>`. +# +# +# +# +# Height of the gauge volume. +# +# +# +# +# In the local coordinate system, the beam is aligned along the X-axis, +# and the Z-axis is oriented in the opposite direction of gravity. The origin +# is the center to the gauge volume. +# +# +# +# +# The last field typically depends on the first +# field of the :ref:`sample transformations </NXstress/ENTRY/SAMPLE_DESCRIPTION/TRANSFORMATIONS-group>`. +# +# +# +# +# +# The axis on which the sample position depends may be stored +# anywhere, but is normally stored in the NXtransformations +# group within the NXsample group. +# +# +# +# +# This is the recommended location for sample goniometer +# and other related axes. +# +# +# +# +# +# +# Zero or more groups to describe the data processing steps +# to obtain the content of this application definition. +# +# +# +# The raw data file name(s) used during the data reduction process. This can be a list. +# +# +# +# +# Date when the raw data was reduced and the data in the *NXstress* file format generated. +# +# +# +# +# Software package used to perform data reduction including the version number or release date. +# +# +# +# +# Describes how the data was integrated. +# +# +# +# +# Describes the type of binning used during data reduction. +# +# +# +# +# Describes how the fitting of the peaks was done. For example, single peak fit, multiple peak fit, Pawley refinement, Rietveld refinement, … +# +# +# +# +# Describes the data range used for peak fitting. +# +# +# +# +# Type and value describing the goodness of fit. For example, Rw 0.23. +# +# +# +# +# Describes whether the data was normalized and if so , how. Examples of valid entries are: ``None``, ``time``, ``primary monitor``, ``detector``, … +# +# +# +# Information about the person who performed the data reduction. +# +# +# +# Role of user responsible for this entry. Suggested roles are, for example, ``local contact``, ``beamline_scientist``, ``post_doc``,… +# +# +# +# +# The note will contain information about how the data was processed +# or anything about the data provenance. +# The contents of the note can be anything that the processing code +# can understand, or a simple text. +# +# The name will be numbered to allow for ordering of steps. +# +# +# +# +# This group contains all diffraction peak fit parameters. +# This information is not required for stress and strain calculations. +# +# +# Diffraction peak profile. +# +# +# +# +# +# +# +# +# +# +# +# Diffraction peak area (not including the background) in *y_Unit* units. +# +# +# +# +# Specify the *y_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`area </NXstress/ENTRY/fit/peak_parameters/area-field>` +# +# +# +# +# +# +# +# Diffraction peak position in *x_Unit* units. +# +# +# +# +# Specify the *x_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`center </NXstress/ENTRY/fit/peak_parameters/center-field>` +# +# +# +# +# +# +# +# Diffraction peak height (not including the background) in *y_Unit* units. +# +# +# +# +# Specify the *y_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`height </NXstress/ENTRY/fit/peak_parameters/height-field>` +# +# +# +# +# +# +# +# Diffraction peak full width at half maximum in *x_Unit* units. +# +# +# +# +# Specify the *x_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`fwhm </NXstress/ENTRY/fit/peak_parameters/fwhm-field>` +# +# +# +# +# +# +# +# Left-side FWHM for split profiles in *x_Unit* units. +# +# +# +# +# Specify the *x_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`fwhm_left </NXstress/ENTRY/fit/peak_parameters/fwhm_left-field>` +# +# +# +# +# +# +# +# Right-side FWHM for split profiles in *x_Unit* units. +# +# +# +# +# Specify the *x_Unit* units +# +# +# +# +# Error value(s) asscociated with :ref:`fwhm_right </NXstress/ENTRY/fit/peak_parameters/fwhm_right-field>` +# +# +# +# +# +# +# +# +# - Voigt or Pseudo-Voigt: Lorentzian fraction +# - Pearson VII: decay parameter +# - Other profiles: not applicable +# +# +# +# +# +# +# +# Error value(s) asscociated with :ref:`form_factor </NXstress/ENTRY/fit/peak_parameters/form_factor-field>` +# +# +# +# +# +# +# +# +# Angle that defines the position of the integrated sector in the diffraction cone +# for angular-dispersive diffraction or the position of the detector for energy-dispersive +# diffraction. +# +# +# +# +# +# +# +# +# This group contains all background fit parameters. +# This information is not required for stress and strain calculations. +# +# +# +# Diffraction background profile. Required when background parameter fields are present. +# Some example values with equations are shown below: +# +# - ``manual`` : No equations nor variables needed to describe this background. +# - ``linear`` : \ :math:`\small background= A0 + A1 \cdot x` +# - ``5-degree polynomial`` : \ :math:`\small background= A0 + A1 \cdot x + A2 \cdot \mathrm{x}^{2} + A3 \cdot \mathrm{x}^{3} + A4 \cdot \mathrm{x}^{4} + A5 \cdot \mathrm{x}^{5}` +# - ``shape function plus polynomial`` : A shape function is not a mathematical function, it contains a manual background obtained from a fit and a polynomial part. This allows to adapt and modify the fit for subsequent measurements in the same measurement campaign. The function describing it is the following: \ :math:`\small background= as + b \cdot SHAPE(x-o)` Where SHAPE is the name of the variable used to describe the background value at the position x. x can be e.g. the scattering angle \ :math:`2\theta` in degrees. +# +# +# +# Background parameter(s). For example a second-degree polynomial will have fields ``A0``, ``A1`` and ``A2``. +# +# +# +# +# +# Background parameter *constant* for SHAPE function. +# +# +# +# +# +# Error associated with background parameter *constant* for SHAPE function. +# +# +# +# +# +# Background parameter *amplitude* for SHAPE function. +# +# +# +# +# +# Error associated with background parameter *amplitude* for SHAPE function. +# +# +# +# +# +# Background parameter *offset* for SHAPE function. +# +# +# +# +# +# Error associated with background parameter *offset* for SHAPE function. +# +# +# +# +# +# The background area in *y_Unit* units, integrated over a confidence interval around the center (*0.95* by default). +# +# +# +# +# Specify the *y_Unit* units +# +# +# +# +# Confidence interval from which the background counts are integrated. +# For example *0.95* means that the background is integrated over the range in +# which the integrated peak area is 95% of the total peak area. +# +# +# +# +# +# +# Diffractogram with fit results in :ref:`peak_parameters </NXstress/ENTRY/fit/peak_parameters-group>` +# and :ref:`background_parameters </NXstress/ENTRY/fit/background_parameters-group>`. +# This information is not required for stress and strain calculations. +# +# +# List of the one to two axes field name(s) to be used by default. The axes are further described in the fields DAXIS and XAXIS. +# +# +# +# +# One or more fields that contain the values for the **n_D** dimension. +# For example the azimuthal positions of different energy-dispersive detectors +# or the average azimuth of different azimuthal sections on an area detector. +# +# +# +# +# +# +# +# +# One or more fields that contain the values for the **n_X** dimension in *x_Unit* units. +# For example: MCA channels, scattering angle \ :math:`2\theta` in degrees, +# scattering vector length q in \ :math:`\mathrm{nm}^{-1}`, ... +# +# +# +# +# +# Specify the *x_Unit* units +# +# +# +# +# Default field name to be plotted. +# +# +# +# +# +# +# List of additional field names to be plotted. This could be e.g. fit, background, residuals, … +# +# +# +# Diffractogram counts in *y_Unit* units (default signal) +# +# +# +# +# +# +# +# +# +# +# Specify the *y_Unit* units +# +# +# +# +# Diffractogram counts error in *y_Unit* units (default signal) +# +# +# +# +# +# +# +# +# +# +# Specify the *y_Unit* units +# +# +# +# +# Diffractogram fit counts (auxiliary signal). +# +# +# +# +# +# +# +# +# +# +# +# +# Diffractogram fit counts error (auxiliary signal). +# +# +# +# +# +# +# +# In case the diffraction background was manually determined. Diffractogram background counts (auxiliary signal). +# +# +# +# +# +# +# +# +# +# +# +# Difference between diffractogram and fit (auxiliary signal). +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# +# User description of the data acquisitions. +# A description of data analysis goes in the +# :ref:`fit descriptions </NXstress/ENTRY/FIT/DESCRIPTION-group>`. +# +# +# +# +# +# This group contains all diffraction peak parameters that could be needed for stress and strain calculations. +# These parameters are derived from :ref:`peak_parameters </NXstress/ENTRY/fit/peak_parameters-group>` and additional metadata. +# +# +# First Miller index. +# +# +# +# +# +# Second Miller index. +# +# +# +# +# +# Third Miller index. +# +# +# +# +# +# Crystal lattice systems (*cubic*, *hexagonal*, ...) +# +# +# +# +# +# Crystallographic space group :math:`(Fm\bar{3}m, Im\bar{3}m, ...)` +# +# +# +# +# +# Name of the crystallographic phase (hematite, goethite, \ :math:`\alpha`-Al\ :sub:`2`\ O\ :sub:`3`\ , ...). +# +# +# +# +# +# +# First component of the *normalized* scattering vector *Q* in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# +# Second component of the *normalized* scattering vector *Q* in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# +# Third component of the *normalized* scattering vector *Q* in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# Diffraction peak position in *c_Unit* units. +# +# +# +# +# Specify the *c_Unit* units (see :ref:`center_type </NXstress/ENTRY/peaks/center_type-field>`) +# +# +# two-theta +# +# +# energy +# +# +# momentum-transfer +# +# +# d-spacing +# +# +# time-of-flight +# +# +# channel (dimensionless) +# +# +# +# +# +# Uncentrainties on :ref:`center </NXstress/ENTRY/peaks/center-field>` in *c_Unit* units. +# +# +# +# +# Specify the *c_Unit* units (see :ref:`center_type </NXstress/ENTRY/peaks/center_type-field>`) +# +# +# two-theta +# +# +# energy +# +# +# momentum-transfer +# +# +# d-spacing +# +# +# time-of-flight +# +# +# channel (dimensionless) +# +# +# +# +# +# +# The space in which :ref:`center </NXstress/ENTRY/peaks/center-field>` is defined. +# It defines the *c_Unit* as follows +# +# - if *center_type="two-theta"* then *c_Unit* must have the angle unit *degrees* +# - if *center_type="energy"* then *c_Unit* must have the unit *keV* +# - if *center_type="momentum-transfer"* then *c_Unit* must have the unit \ :math:`Å^{-1}` +# - if *center_type="d-spacing"* then *c_Unit* must have the unit \ :math:`Å` +# - if *center_type="channel"* then *c_Unit* must be *dimensioness* +# - if *center_type="time-of-flight"* then *c_Unit* must have the unit \ :math:`\mu\mathrm{s}` +# +# +# +# +# +# +# +# +# +# +# +# +# First component of the sample position in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# +# +# First component of the sample position in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# +# First component of the sample position in the sample reference frame. +# The sample reference frame is defined by the :ref:`sample transformations </NXstress/ENTRY/sample_description/TRANSFORMATIONS-group>`. +# +# +# +# +# +# +# +# +# diff --git a/applications/nyaml/NXtomoproc.yaml b/applications/nyaml/NXtomoproc.yaml index 3ddd1dc53e..e9a7192d67 100644 --- a/applications/nyaml/NXtomoproc.yaml +++ b/applications/nyaml/NXtomoproc.yaml @@ -43,7 +43,7 @@ NXtomoproc(NXobject): doc: | Original raw data file this data was derived from data(NXdata): - data(NX_INT): + data(NX_NUMBER): signal: 1 doc: | This is the reconstructed volume. This can be different @@ -51,7 +51,7 @@ NXtomoproc(NXobject): quantity this really is. dimensions: rank: 3 - dim: (nX, nX, nZ) + dim: (nX, nY, nZ) \@transform: \@offset: \@scaling: @@ -84,7 +84,7 @@ NXtomoproc(NXobject): dim: (nZ,) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# b395d0dd95ed66fe67c366e17ff23211dabe00c191edfc44d0d72677cc3e7c81 +# dcb9c3a07d99aa51a9131d967d4f28daddf17053ab2c9c37a356f70475758b49 # # # diff --git a/base_classes/NXcg_primitive.nxdl.xml b/base_classes/NXcg_primitive.nxdl.xml index 2f096e316d..eb5b01f402 100644 --- a/base_classes/NXcg_primitive.nxdl.xml +++ b/base_classes/NXcg_primitive.nxdl.xml @@ -74,7 +74,7 @@ Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + :math:`[index\_offset, index\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of index_offset and cardinality. For example if identifier run from diff --git a/base_classes/NXdetector.nxdl.xml b/base_classes/NXdetector.nxdl.xml index 7eb3bebec3..10221fa40c 100644 --- a/base_classes/NXdetector.nxdl.xml +++ b/base_classes/NXdetector.nxdl.xml @@ -26,8 +26,6 @@ xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xmlns:xs="http://www.w3.org/2001/XMLSchema" - xmlns:ns="http://definition.nexusformat.org/nxdl/@NXDL_RELEASE@" > diff --git a/base_classes/NXdetector_channel.nxdl.xml b/base_classes/NXdetector_channel.nxdl.xml index 16d3657df5..0bb9ba1049 100644 --- a/base_classes/NXdetector_channel.nxdl.xml +++ b/base_classes/NXdetector_channel.nxdl.xml @@ -26,8 +26,6 @@ xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xmlns:xs="http://www.w3.org/2001/XMLSchema" - xmlns:ns="http://definition.nexusformat.org/nxdl/@NXDL_RELEASE@" > diff --git a/base_classes/NXelectromagnetic_lens.nxdl.xml b/base_classes/NXelectromagnetic_lens.nxdl.xml index 3cf9ed46d3..a13375ce71 100644 --- a/base_classes/NXelectromagnetic_lens.nxdl.xml +++ b/base_classes/NXelectromagnetic_lens.nxdl.xml @@ -26,7 +26,7 @@ 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. + in the center of the lens its pole piece, 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. diff --git a/base_classes/NXelectron_detector.nxdl.xml b/base_classes/NXelectron_detector.nxdl.xml index 6d7bb0f04e..9f3b8618b7 100644 --- a/base_classes/NXelectron_detector.nxdl.xml +++ b/base_classes/NXelectron_detector.nxdl.xml @@ -26,8 +26,6 @@ xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" xmlns="http://definition.nexusformat.org/nxdl/3.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xmlns:xs="http://www.w3.org/2001/XMLSchema" - xmlns:ns="http://definition.nexusformat.org/nxdl/@NXDL_RELEASE@" > A subclass of NXdetector for detectors that detect electrons. diff --git a/base_classes/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml index 622665993e..5cc2aa7599 100644 --- a/base_classes/NXem_ebsd.nxdl.xml +++ b/base_classes/NXem_ebsd.nxdl.xml @@ -78,7 +78,7 @@ From this point onwards typically the microscope runs automatically. Diffraction pattern get collected until the queue finishes or gets interrupted by - either errors or arrival at the end of the users' allocated timeslot at the instrument. + either errors or arrival at the end of the users' allocated time slot at the instrument. Kikuchi pattern (EBSP) are usually indexed on-the-fly. These patterns are the raw data. Once indexed, these patterns are often not stored. diff --git a/base_classes/NXentry.nxdl.xml b/base_classes/NXentry.nxdl.xml index fbe7e00acc..1aeb997207 100755 --- a/base_classes/NXentry.nxdl.xml +++ b/base_classes/NXentry.nxdl.xml @@ -98,14 +98,7 @@ 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, @@ -118,26 +111,16 @@ Description of the full experiment (document in pdf, latex, ...) - - User or Data Acquisition defined group of NeXus files or NXentry - - + User or Data Acquisition defined group of NeXus files or NXentry Brief summary of the collection, including grouping criteria. - + Unique identifier for the measurement, defined by the facility. - - unique identifier for the measurement, defined by the facility. - - - UUID identifier for the measurement. - Version of UUID used - - + UUID identifier for the measurement. Version of UUID used diff --git a/base_classes/NXfit.nxdl.xml b/base_classes/NXfit.nxdl.xml index fce599395f..0d0bcf13a0 100644 --- a/base_classes/NXfit.nxdl.xml +++ b/base_classes/NXfit.nxdl.xml @@ -164,9 +164,9 @@ Description of the method used to optimize the parameters during peak fitting. Examples: - + - least squares - - non-linear least squares + - nonlinear least squares - Levenberg-Marquardt algorithm (damped least-squares) - linear regression - Bayesian linear regression @@ -181,7 +181,7 @@ :math:`min(\chi^2)`, where :math:`\chi^2` is the sum of squared residuals between the model and the observed data: :math:`min(\chi^2) = \sum_{i=1}^{N} \left( y_i - \left( \text{peak}_1(p_1, x_i) + \text{peak}_2(p_2, x_i) + \text{backgr}(p_3, x_i) \right) \right)^2` - + It is however also possible to supply more involved formulas (e.g., in the case of constrained fits). @@ -197,7 +197,7 @@ Metric used to determine the goodness of fit. Examples include: - + - :math:`\chi^2`, the squared sum of the sigma-weighted residuals - reduced :math:`\chi^2`:, :math:`\chi^2`: per degree of freedom - :math:`R^2`, the coefficient of determination diff --git a/base_classes/NXinsertion_device.nxdl.xml b/base_classes/NXinsertion_device.nxdl.xml index f03078849b..c6a6a1241d 100644 --- a/base_classes/NXinsertion_device.nxdl.xml +++ b/base_classes/NXinsertion_device.nxdl.xml @@ -28,9 +28,11 @@ type="group" extends="NXcomponent"> An insertion device, as used in a synchrotron light source. + It is recommended (effective from 2025) to use the "wavelength_shifter" choice for 3-pole wigglers, while reserving the generic "wiggler" designation for extended multipole wigglers. - - + + + diff --git a/base_classes/NXpid_controller.nxdl.xml b/base_classes/NXpid_controller.nxdl.xml index 70f8188339..a9e1b7cc1e 100644 --- a/base_classes/NXpid_controller.nxdl.xml +++ b/base_classes/NXpid_controller.nxdl.xml @@ -44,7 +44,7 @@ * K_ff A classic PID controller only implements the P, I and D terms and the values of the K_p, K_i and K_d constants are sufficient to fully - describe the behaviour of the feedback system implemented by such a PID controller. The inclusion of a Feed Forward term in a feedback system + describe the behavior of the feedback system implemented by such a PID controller. The inclusion of a Feed Forward term in a feedback system is a modern adaptation that aids optimization of the automated control. It is not present in all PID controllers, but it is also not uncommon. Note that the ``NXpid_controller`` is designed to be a child object of the actuator that its output is connected to. The parent object @@ -130,7 +130,7 @@ the Process Variable that is lower than the Setpoint results in a positive Error Value and a generally positive control output that tells the actuator to push the value of the Process Variable upwards. In some implementations, the actuator will respond to a more positive control output by pushing the Process Variable towards lower values (e.g. - a Peltier cooler) and so the output of the feedback system must be reversed to match the behaviour of the physical system. + a Peltier cooler) and so the output of the feedback system must be reversed to match the behavior of the physical system. A feedback system may also be implemented with reverse action in order to ensure that failures (e.g. disconnected sensor output or actuator input) result in a safe state (e.g. a valve should be left open to release pressure). diff --git a/base_classes/NXsensor.nxdl.xml b/base_classes/NXsensor.nxdl.xml index 0e68e4b2e2..45e76f3c8c 100644 --- a/base_classes/NXsensor.nxdl.xml +++ b/base_classes/NXsensor.nxdl.xml @@ -155,7 +155,6 @@ This group describes the shape of the sensor when necessary. - .. todo:: diff --git a/base_classes/NXsubentry.nxdl.xml b/base_classes/NXsubentry.nxdl.xml index 778c351947..0b64a336b5 100644 --- a/base_classes/NXsubentry.nxdl.xml +++ b/base_classes/NXsubentry.nxdl.xml @@ -83,18 +83,10 @@ 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 + Unique identifier for the experiment, defined by + the facility, possibly linked to the proposals @@ -103,19 +95,13 @@ Description of the full experiment (document in pdf, latex, ...) - - User or Data Acquisition defined group of NeXus files or :ref:`NXentry` - - + User or Data Acquisition defined group of NeXus files or :ref:`NXentry` Brief summary of the collection, including grouping criteria. - - unique identifier for the measurement, defined by the facility. - - + unique identifier for the measurement, defined by the facility. @@ -129,23 +115,23 @@ - End 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 institution hosting the facility - Name of the experimental facility + Name of the experimental facility - Name of the laboratory or beamline + Name of the laboratory or beamline diff --git a/base_classes/nyaml/NXapm_reconstruction.yaml b/base_classes/nyaml/NXapm_reconstruction.yaml index 040e895939..be7ce17455 100644 --- a/base_classes/nyaml/NXapm_reconstruction.yaml +++ b/base_classes/nyaml/NXapm_reconstruction.yaml @@ -141,7 +141,8 @@ NXapm_reconstruction(NXprocess): for best practices on the reporting of metadata in atom probe tomography. The value can be extracted from the CAnalysis.CResults.fComments - field of a CamecaRoot ROOT file. + field of a CamecaRoot ROOT file. + # results reconstructed_positions(NX_FLOAT): unit: NX_LENGTH @@ -159,6 +160,7 @@ NXapm_reconstruction(NXprocess): The value can be extracted from the CAnalysis.CResults.fQuality field of a CamecaRoot ROOT file. + # plots and statistics about the reconstructed volume naive_discretization(NXprocess): (NXprogram): @@ -217,7 +219,7 @@ NXapm_reconstruction(NXprocess): Maximum coordinate value along the z-direction # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# cb26300799d2708792b9a84040c6b2b80f994eaec0210976a888c5f141df38ff +# 5f602a9b8eb5e82e20208740bdb86e3cab2f4e0e51b1b7f30e51391187f6c4a1 # # # # # diff --git a/base_classes/nyaml/NXatom.yaml b/base_classes/nyaml/NXatom.yaml index 712d05e432..93f4c70cd5 100644 --- a/base_classes/nyaml/NXatom.yaml +++ b/base_classes/nyaml/NXatom.yaml @@ -137,7 +137,7 @@ NXatom(NXobject): unit: NX_UNITLESS doc: | Table which decodes the entries in nuclide_hash into a human-readable matrix - instances for either nuclids or elements. Specifically, the first row specifies the + instances for either nuclides or elements. Specifically, the first row specifies the nuclide mass number. When the nuclide_hash values are used this means the row should report the sum :math:`Z + N` or 0. The value 0 documents that an element from the IUPAC periodic table is meant. @@ -163,7 +163,7 @@ NXatom(NXobject): dim: (n_ranges, 2) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 4206980cd0848593553abf0f86e1635d60421cdb4907604abdf41526bbe3632a +# 3e34106345f5362bb2054e1922a28101a0e963d2e2a1de6d03fa8905403dc0e6 # # # diff --git a/base_classes/nyaml/NXcg_primitive.yaml b/base_classes/nyaml/NXcg_primitive.yaml index bb8b776909..75ff38f52b 100644 --- a/base_classes/nyaml/NXcg_primitive.yaml +++ b/base_classes/nyaml/NXcg_primitive.yaml @@ -39,7 +39,7 @@ NXcg_primitive(NXobject): Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval - :math:`[identifier\_offset, identifier\_offset + c - 1]`. + :math:`[index\_offset, index\_offset + c - 1]`. Therefore, implicit identifier are completely defined by the value of index_offset and cardinality. For example if identifier run from @@ -182,7 +182,7 @@ NXcg_primitive(NXobject): face_normal(NXcg_unit_normal): # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 65f66dd89993d2350d6905134228c02bcc0bb2608e12fadfd29b8e2730de164a +# ca4dd20755c60f28ea76056b7af1377e9b242aa52e907040ea8b979e05775a82 # # # - - - - - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. - - Is the beam splitter polarizing? @@ -129,11 +121,6 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - - - If you chose 'other' in 'shape' describe what it is. - - Sketch of the beam splitter showing its geometry. The paths of the diff --git a/contributed_definitions/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml index 9f861e8c4e..3c88a11509 100644 --- a/contributed_definitions/NXdispersion.nxdl.xml +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -3,7 +3,7 @@ - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. - The name of the composite model. + The name of the composite model. diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml index 762dc40f0e..48660aae3b 100644 --- a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -3,7 +3,7 @@ - A single parameter for a dispersion function + A single parameter for a dispersion function - The name of the parameter + The name of the parameter - A description of what this parameter represents + A description of what this parameter represents - The value of the parameter + The value of the parameter diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml index e6ce6a0299..4673e3386b 100644 --- a/contributed_definitions/NXdispersion_table.nxdl.xml +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -3,7 +3,7 @@ - + - NXdispersion + An application definition for describing a dispersive material. - - An application definition for a dispersive material. - Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition @@ -46,21 +43,6 @@ - - - Name of the program used for creating this dispersion - - - - - Version of the program used - - - - - Date and time of creating this dispersion. - - @@ -80,17 +62,16 @@ The phase of the material - + - Additional information about the phase if the - material phase is other. + material phase is not from the enumerated list. @@ -125,11 +106,11 @@ This should be the only dispersion available for isotropic materials. For uniaxial materials this denotes the ordinary axis. For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. + of the diagonalized permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -162,7 +143,7 @@ This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized + It denotes the epsilon 22 direction of the diagonalized permittivity tensor. @@ -202,7 +183,7 @@ This should only be filled for uniaxial or biaxial materials. For uniaxial materials this denotes the extraordinary axis. For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized permittivity tensor. + of the diagonalized permittivity tensor. @@ -237,4 +218,4 @@ - + \ No newline at end of file diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 9cec2c3b7f..84f0e391fb 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -26,32 +26,32 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a magnetic kicker. + Base class for a magnetic kicker. - extended description of the kicker. + Extended description of the kicker. - define position of beamline element relative to production target + Define position of beamline element relative to production target - kicker timing as defined by ``description`` attribute + Kicker timing as defined by ``description`` attribute - current set on supply. + Current set on supply. - current read from supply. + Current read from supply. - voltage set on supply. + Voltage set on supply. - voltage read from supply. + Voltage read from supply. diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXoptical_fiber.nxdl.xml similarity index 54% rename from contributed_definitions/NXfiber.nxdl.xml rename to contributed_definitions/NXoptical_fiber.nxdl.xml index 495f3fb926..15358ba2a2 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXoptical_fiber.nxdl.xml @@ -22,46 +22,46 @@ # For further information, see http://www.nexusformat.org --> - + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the core material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the cladding material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - attenuation curve is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. - An optical fiber, e.g. glass fiber. - - Specify the quantities that define the fiber. Fiber optics are described in - detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for - example. + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. - Descriptive name or brief description of the fiber, e.g. by stating its - dimension. The dimension of a fiber can be given as 60/100/200 which - refers to a core diameter of 60 micron, a clad diameter of 100 micron, - and a coating diameter of 200 micron. + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. - Type/mode of the fiber. Modes of fiber transmission are shown in - Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). @@ -71,9 +71,9 @@ - Type of dispersion. + Type of dispersion. - + @@ -81,8 +81,8 @@ - Spectrum-dependent (or refractive index-dependent) dispersion of the - fiber. Specify in ps/nm*km. + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. @@ -90,22 +90,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Core diameter of the fiber (e.g. given in micrometer). + Core diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -115,22 +115,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Clad diameter of the fiber (e.g. given in micrometer). + Clad diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -140,64 +140,59 @@ - Coating of the fiber. + Coating of the fiber. - + - Specify the material of the coating of the fiber. + Specify the material of the coating of the fiber. - + - Outer diameter of the fiber (e.g. given in micrometer). + Outer diameter of the fiber (e.g. given in micrometer). - Length of the fiber. + Length of the fiber. - Spectral range for which the fiber is designed. Enter the minimum and - maximum values (lower and upper limit) of the wavelength range. + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. - Unit of spectral array (e.g. nanometer or angstrom for wavelength, or - electronvolt for energy etc.). + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). - + - Transfer rate of the fiber (in GB per second). + Transfer rate of the fiber (in GB per second). - - - GB/s - - - Numerical aperture (NA) of the fiber. + Numerical aperture (NA) of the fiber. - + - Wavelength-dependent attenuation of the fiber (specify in dB/km). + Wavelength-dependent attenuation of the fiber (specify in dB/km). - Use dB/km. + Use dB/km. @@ -206,12 +201,12 @@ - Power loss of the fiber in percentage. + Power loss of the fiber in percentage. - Acceptance angle of the fiber. + Acceptance angle of the fiber. diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXoptical_polarizer.nxdl.xml similarity index 89% rename from contributed_definitions/NXpolarizer_opt.nxdl.xml rename to contributed_definitions/NXoptical_polarizer.nxdl.xml index d1e0687beb..71d2a3d9c1 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXoptical_polarizer.nxdl.xml @@ -24,7 +24,7 @@ - + @@ -47,9 +47,9 @@ A draft of a new base class to describe an optical polarizer - Type of the polarizer (e.g. dichroic, linear, circular etc.) + Type of the polarizer - + @@ -62,15 +62,8 @@ A draft of a new base class to describe an optical polarizer - - - - - If you selected 'other' in type specify what it is. - - Angle of the polarizer. @@ -96,20 +89,14 @@ A draft of a new base class to describe an optical polarizer Describe the shape (plate, cube, wedged, prism etc.). - + - - - - If you chose 'other' in 'shape' describe what it is. - - Sketch of the device showing its geometry. The paths of the @@ -156,7 +143,7 @@ A draft of a new base class to describe an optical polarizer Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. + a coating specify the coating material and its properties in ``coatingTYPE``. @@ -179,28 +166,29 @@ A draft of a new base class to describe an optical polarizer - - If the device has a coating describe the material and its properties. Some basic information can be found e.g. [here] (https://www.opto-e.com/basics/reflection-transmission-and-coatings). If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). + materials, you may define two coatings (e.g. coating_front and + coating_back). - + Specify the coating type (e.g. dielectric, anti-reflection (AR), multilayer coating etc.). - + Describe the coating material (e.g. MgF2). - + Thickness of the coating. @@ -240,5 +228,4 @@ the device has different coatings on the front and back side.--> - diff --git a/contributed_definitions/NXstm.nxdl.xml b/contributed_definitions/NXstm.nxdl.xml index 08900bca65..ee16343d03 100644 --- a/contributed_definitions/NXstm.nxdl.xml +++ b/contributed_definitions/NXstm.nxdl.xml @@ -134,7 +134,7 @@ /entry/instrument/bias_spectroscopy_environment/bias_spectroscopy/bias_sweep - + This is the signal on which the modulation voltage or current will be added. This should be a link to diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 13483c0076..03d5e58ee8 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -44,20 +44,14 @@ Draft NeXus application definition for transmission experiments--> Application definition for transmission experiments - - This application definition - - - An application definition for transmission. - 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. @@ -75,7 +69,7 @@ Draft NeXus application definition for transmission experiments--> Unique identifier of the experiment, such as a (globally persistent) - unique identifier. + unique identifier. * The identifier is usually defined by the facility or principle investigator. @@ -89,10 +83,6 @@ Draft NeXus application definition for transmission experiments--> definition rather than in this experiment description. - @@ -112,7 +102,7 @@ of instrument.--> - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -122,32 +112,12 @@ of instrument.--> Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - - - Street address of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by research id services, e.g. orcid (https://orcid.org/). - - - - - Telephone number of the user. - - @@ -197,14 +167,15 @@ of instrument.--> - + Overall spectral resolution of this spectrometer. If several gratings are employed the spectral resolution should rather be specified for each grating inside the NXgrating group of this spectrometer. - + + Diffraction grating, as could be used in a monochromator. @@ -214,7 +185,7 @@ of instrument.--> do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. @@ -224,12 +195,13 @@ of instrument.--> The blaze wavelength of the grating used. - + Overall spectral resolution of the instrument when this grating is used. - + + Wavelength range in which this grating was used @@ -310,7 +282,7 @@ of instrument.--> The type of lamp, e.g. halogen, D2 etc. - + @@ -334,8 +306,6 @@ of instrument.--> - Properties of the sample measured diff --git a/contributed_definitions/nyaml/NXbeam_splitter.yaml b/contributed_definitions/nyaml/NXbeam_splitter.yaml index 089b6284ea..66eba5a016 100644 --- a/contributed_definitions/nyaml/NXbeam_splitter.yaml +++ b/contributed_definitions/nyaml/NXbeam_splitter.yaml @@ -32,13 +32,7 @@ NXbeam_splitter(NXcomponent): dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension should be described in 'geometry'. Define if the beam splitter is polarizing or not in the field 'polarizing(NX_BOOLEAN)'. - enumeration: [dichroic mirror, dielectric mirror, metal-coated mirror, Nicol prism, Glan-Thompson prism, pellicle mirror, Polka dot beam splitter, fiber optic splitter, other] - - # ??? Are there any other common types of beam splitters ??? - other_type: - doc: | - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. + enumeration: [dichroic mirror, dielectric mirror, metal-coated mirror, Nicol prism, Glan-Thompson prism, pellicle mirror, Polka dot beam splitter, fiber optic splitter] polarizing(NX_BOOLEAN): doc: | Is the beam splitter polarizing? @@ -67,9 +61,6 @@ NXbeam_splitter(NXcomponent): doc: | Describe the shape (plate, cube, wedged, prism etc.). enumeration: [cube, cylinder, plate, prism, wedged, other] - other_shape: - doc: | - If you chose 'other' in 'shape' describe what it is. sketch(NXdata): doc: | Sketch of the beam splitter showing its geometry. The paths of the @@ -272,7 +263,7 @@ NXbeam_splitter(NXcomponent): dim: (N_outputs, N_spectrum_RT) # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 77d77ed20b614756dc9c077b9bdba91f86bce9d5eb889fbb5b3a471b83064f92 +# 3d5dca300538700adc742ffa4c549fa93be87ac999d99e82d5756216c31031f6 # # # -# -# -# If you selected 'other' in 'type' use this field to specify which type of -# beam splitter was used. -# -# # # # Is the beam splitter polarizing? @@ -404,11 +387,6 @@ NXbeam_splitter(NXcomponent): # # # -# -# -# If you chose 'other' in 'shape' describe what it is. -# -# # # # Sketch of the beam splitter showing its geometry. The paths of the diff --git a/contributed_definitions/nyaml/NXdispersion.yaml b/contributed_definitions/nyaml/NXdispersion.yaml index 3d28d71350..c0af7d1381 100644 --- a/contributed_definitions/nyaml/NXdispersion.yaml +++ b/contributed_definitions/nyaml/NXdispersion.yaml @@ -18,7 +18,7 @@ NXdispersion(NXobject): # # # -# A dispersion denoting a sum of different dispersions. -# All NXdispersion_table and NXdispersion_function groups will be added together -# to form a single dispersion. +# A dispersion denoting a sum of different dispersions. +# All NXdispersion_table and NXdispersion_function groups will be added together +# to form a single dispersion. # # # -# The name of the composite model. +# The name of the composite model. # # # diff --git a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml index 5974d87da1..b76c2e4738 100644 --- a/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml +++ b/contributed_definitions/nyaml/NXdispersion_single_parameter.yaml @@ -21,7 +21,7 @@ NXdispersion_single_parameter(NXobject): # # # -# A single parameter for a dispersion function +# A single parameter for a dispersion function # # # -# The name of the parameter +# The name of the parameter # # # # -# A description of what this parameter represents +# A description of what this parameter represents # # # # -# The value of the parameter +# The value of the parameter # # # diff --git a/contributed_definitions/nyaml/NXdispersion_table.yaml b/contributed_definitions/nyaml/NXdispersion_table.yaml index 5c06c505ed..3288729311 100644 --- a/contributed_definitions/nyaml/NXdispersion_table.yaml +++ b/contributed_definitions/nyaml/NXdispersion_table.yaml @@ -55,7 +55,7 @@ NXdispersion_table(NXobject): # -# +# # -# NXdispersion +# An application definition for describing a dispersive material. # # # -# -# An application definition for a dispersive material. -# # # # Version number to identify which definition of this application definition was # used for this entry/data. # # -# +# # # URL where to find further material (documentation, examples) relevant to the # application definition @@ -243,21 +229,6 @@ NXdispersive_material(NXobject): # # # -# -# -# Name of the program used for creating this dispersion -# -# -# -# -# Version of the program used -# -# -# -# -# Date and time of creating this dispersion. -# -# # # # @@ -277,17 +248,16 @@ NXdispersive_material(NXobject): # # The phase of the material # -# +# # # # -# # # # # # Additional information about the phase if the -# material phase is other. +# material phase is not from the enumerated list. # # # @@ -322,11 +292,11 @@ NXdispersive_material(NXobject): # This should be the only dispersion available for isotropic materials. # For uniaxial materials this denotes the ordinary axis. # For biaxial materials this denotes the x axis or epsilon 11 tensor element -# of the diagionalized permittivity tensor. +# of the diagonalized permittivity tensor. # # # -# The name of this dispersion model. +# The name of this dispersion model. # # # @@ -359,7 +329,7 @@ NXdispersive_material(NXobject): # # # This should only be filled for biaxial materials. -# It denotes the epsilon 22 direction of the diagionalized +# It denotes the epsilon 22 direction of the diagonalized # permittivity tensor. # # @@ -399,7 +369,7 @@ NXdispersive_material(NXobject): # This should only be filled for uniaxial or biaxial materials. # For uniaxial materials this denotes the extraordinary axis. # For biaxial materials this denotes the epsilon 33 tensor element -# of the diagionalized permittivity tensor. +# of the diagonalized permittivity tensor. # # # @@ -434,4 +404,4 @@ NXdispersive_material(NXobject): # # # -# +# \ No newline at end of file diff --git a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml index fdc0978231..18c30f84d7 100644 --- a/contributed_definitions/nyaml/NXmagnetic_kicker.yaml +++ b/contributed_definitions/nyaml/NXmagnetic_kicker.yaml @@ -1,47 +1,47 @@ category: base doc: | - definition for a magnetic kicker. + Base class for a magnetic kicker. type: group NXmagnetic_kicker(NXcomponent): description(NX_CHAR): doc: | - extended description of the kicker. + Extended description of the kicker. beamline_distance(NX_FLOAT): unit: NX_LENGTH exists: ['min', '0', 'max', '1'] doc: | - define position of beamline element relative to production target + Define position of beamline element relative to production target timing(NX_FLOAT): unit: NX_TIME exists: ['min', '0', 'max', '1'] doc: | - kicker timing as defined by ``description`` attribute + Kicker timing as defined by ``description`` attribute \@description(NX_CHAR): set_current(NX_FLOAT): unit: NX_CURRENT exists: ['min', '0', 'max', '1'] doc: | - current set on supply. + Current set on supply. read_current(NXlog): exists: ['min', '0', 'max', '1'] doc: | - current read from supply. + Current read from supply. value: unit: NX_CURRENT set_voltage(NX_FLOAT): unit: NX_VOLTAGE exists: ['min', '0', 'max', '1'] doc: | - voltage set on supply. + Voltage set on supply. read_voltage(NXlog): exists: ['min', '0', 'max', '1'] doc: | - voltage read from supply. + Voltage read from supply. value: unit: NX_VOLTAGE # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 5d7457340c4c16e1a7e43ffe5f0a324e1904ceb38746588fa0dc0f5e17dfb4e6 +# 5c57e9f05b6b4a60acb44ec06d31492427fbc216fc81972d0e26f0326333240d # # # # -# +# # # # -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the core material is given. +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the core material is given. # # # # -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# refractive index of the cladding material is given. +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# refractive index of the cladding material is given. # # # # -# Length of the spectrum vector (e.g. wavelength or energy) for which the -# attenuation curve is given. +# Length of the spectrum vector (e.g. wavelength or energy) for which the +# attenuation curve is given. # # # # -# An optical fiber, e.g. glass fiber. -# -# Specify the quantities that define the fiber. Fiber optics are described in -# detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for -# example. +# An optical fiber, e.g. glass fiber. +# +# Specify the quantities that define the fiber. Fiber optics are described in +# detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for +# example. # # # -# Descriptive name or brief description of the fiber, e.g. by stating its -# dimension. The dimension of a fiber can be given as 60/100/200 which -# refers to a core diameter of 60 micron, a clad diameter of 100 micron, -# and a coating diameter of 200 micron. +# Descriptive name or brief description of the fiber, e.g. by stating its +# dimension. The dimension of a fiber can be given as 60/100/200 which +# refers to a core diameter of 60 micron, a clad diameter of 100 micron, +# and a coating diameter of 200 micron. # # # # -# Type/mode of the fiber. Modes of fiber transmission are shown in -# Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). +# Type/mode of the fiber. Modes of fiber transmission are shown in +# Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). # # # @@ -212,9 +211,9 @@ NXfiber(NXcomponent): # # # -# Type of dispersion. +# Type of dispersion. # -# +# # # # @@ -222,8 +221,8 @@ NXfiber(NXcomponent): # # # -# Spectrum-dependent (or refractive index-dependent) dispersion of the -# fiber. Specify in ps/nm*km. +# Spectrum-dependent (or refractive index-dependent) dispersion of the +# fiber. Specify in ps/nm*km. # # # @@ -231,22 +230,22 @@ NXfiber(NXcomponent): # # # -# Core of the fiber, i.e. the part of the fiber which transmits the light. +# Core of the fiber, i.e. the part of the fiber which transmits the light. # -# +# # -# Specify the material of the core of the fiber. +# Specify the material of the core of the fiber. # # -# +# # -# Core diameter of the fiber (e.g. given in micrometer). +# Core diameter of the fiber (e.g. given in micrometer). # # -# +# # -# Complex index of refraction of the fiber. Specify at given wavelength -# (or energy, wavenumber etc.) values. +# Complex index of refraction of the fiber. Specify at given wavelength +# (or energy, wavenumber etc.) values. # # # @@ -256,22 +255,22 @@ NXfiber(NXcomponent): # # # -# Core of the fiber, i.e. the part of the fiber which transmits the light. +# Core of the fiber, i.e. the part of the fiber which transmits the light. # -# +# # -# Specify the material of the core of the fiber. +# Specify the material of the core of the fiber. # # -# +# # -# Clad diameter of the fiber (e.g. given in micrometer). +# Clad diameter of the fiber (e.g. given in micrometer). # # -# +# # -# Complex index of refraction of the fiber. Specify at given wavelength -# (or energy, wavenumber etc.) values. +# Complex index of refraction of the fiber. Specify at given wavelength +# (or energy, wavenumber etc.) values. # # # @@ -281,64 +280,59 @@ NXfiber(NXcomponent): # # # -# Coating of the fiber. +# Coating of the fiber. # -# +# # -# Specify the material of the coating of the fiber. +# Specify the material of the coating of the fiber. # # -# +# # -# Outer diameter of the fiber (e.g. given in micrometer). +# Outer diameter of the fiber (e.g. given in micrometer). # # # # # -# Length of the fiber. +# Length of the fiber. # # # # -# Spectral range for which the fiber is designed. Enter the minimum and -# maximum values (lower and upper limit) of the wavelength range. +# Spectral range for which the fiber is designed. Enter the minimum and +# maximum values (lower and upper limit) of the wavelength range. # # # # # # -# Unit of spectral array (e.g. nanometer or angstrom for wavelength, or -# electronvolt for energy etc.). +# Unit of spectral array (e.g. nanometer or angstrom for wavelength, or +# electronvolt for energy etc.). # # # -# +# # -# Transfer rate of the fiber (in GB per second). +# Transfer rate of the fiber (in GB per second). # -# -# -# GB/s -# -# # # # -# Numerical aperture (NA) of the fiber. +# Numerical aperture (NA) of the fiber. # # -# +# # -# Wavelength-dependent attenuation of the fiber (specify in dB/km). +# Wavelength-dependent attenuation of the fiber (specify in dB/km). # # # # # # -# Use dB/km. +# Use dB/km. # # # @@ -347,12 +341,12 @@ NXfiber(NXcomponent): # # # -# Power loss of the fiber in percentage. +# Power loss of the fiber in percentage. # # # # -# Acceptance angle of the fiber. +# Acceptance angle of the fiber. # # # diff --git a/contributed_definitions/nyaml/NXpolarizer_opt.yaml b/contributed_definitions/nyaml/NXoptical_polarizer.yaml similarity index 87% rename from contributed_definitions/nyaml/NXpolarizer_opt.yaml rename to contributed_definitions/nyaml/NXoptical_polarizer.yaml index a9b3999dc5..e2d6122242 100644 --- a/contributed_definitions/nyaml/NXpolarizer_opt.yaml +++ b/contributed_definitions/nyaml/NXoptical_polarizer.yaml @@ -15,16 +15,13 @@ symbols: # A draft of a new base class to describe an optical polarizer # (NXpolarizer describes a spin polarizer) type: group -NXpolarizer_opt(NXcomponent): +NXoptical_polarizer(NXcomponent): type: doc: | - Type of the polarizer (e.g. dichroic, linear, circular etc.) - enumeration: [dichroic, linear, circular, Glan-Thompson prism, Nicol prism, Glan-Taylor prism, Glan-Focault prism, Wollaston prism, Normarski prism, Senarmont prism, thin-film polarizer, wire grid polarizer, other] - - # ??? Any other common polarizer types ??? - type_other: - doc: | - If you selected 'other' in type specify what it is. + Type of the polarizer + enumeration: + open_enum: true + items: [dichroic, linear, circular, Glan-Thompson prism, Nicol prism, Glan-Taylor prism, Glan-Focault prism, Wollaston prism, Normarski prism, Senarmont prism, thin-film polarizer, wire grid polarizer] polarizer_angle(NX_NUMBER): exists: recommended unit: NX_ANGLE @@ -49,10 +46,9 @@ NXpolarizer_opt(NXcomponent): shape: doc: | Describe the shape (plate, cube, wedged, prism etc.). - enumeration: [cube, cylinder, plate, prism, wedged, other] - other_shape: - doc: | - If you chose 'other' in 'shape' describe what it is. + enumeration: + open_enum: true + items: [cube, cylinder, plate, prism, wedged] sketch(NXdata): doc: | Sketch of the device showing its geometry. The paths of the @@ -92,7 +88,7 @@ NXpolarizer_opt(NXcomponent): substrate(NXsample): doc: | Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. + a coating specify the coating material and its properties in ``coatingTYPE``. substrate_material: doc: | Specify the substrate material of the polarizer. @@ -108,24 +104,26 @@ NXpolarizer_opt(NXcomponent): dimensions: rank: 2 dim: (2, N_spectrum) - COATING(NXsample): + coatingTYPE(NXsample): + nameType: partial - # Used capital letters for COATING so that more than one can be defined if + # Used capital letters for TYPE so that more than one can be defined if # the device has different coatings on the front and back side. doc: | If the device has a coating describe the material and its properties. Some basic information can be found e.g. [here] (https://www.opto-e.com/basics/reflection-transmission-and-coatings). If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). - coating_type: + materials, you may define two coatings (e.g. coating_front and + coating_back). + type: doc: | Specify the coating type (e.g. dielectric, anti-reflection (AR), multilayer coating etc.). - coating_material: + material: doc: | Describe the coating material (e.g. MgF2). - coating_thickness(NX_FLOAT): + thickness(NX_FLOAT): unit: NX_LENGTH doc: | Thickness of the coating. @@ -158,11 +156,9 @@ NXpolarizer_opt(NXcomponent): dimensions: rank: 1 dim: (N_spectrum_RT,) - - # anything missing? # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 0823bc365fa339e531e477f046098dfede125af734fa1e90660b0b979b52b243 +# 56c59bb3910db5368e4021228db2181312c76d641b134fe2ad5f2dbeefca43fd # # # -# +# # # # @@ -212,9 +208,9 @@ NXpolarizer_opt(NXcomponent): # # # -# Type of the polarizer (e.g. dichroic, linear, circular etc.) +# Type of the polarizer # -# +# # # # @@ -227,15 +223,8 @@ NXpolarizer_opt(NXcomponent): # # # -# # # -# -# -# -# If you selected 'other' in type specify what it is. -# -# # # # Angle of the polarizer. @@ -261,20 +250,14 @@ NXpolarizer_opt(NXcomponent): # # Describe the shape (plate, cube, wedged, prism etc.). # -# +# # # # # # -# # # -# -# -# If you chose 'other' in 'shape' describe what it is. -# -# # # # Sketch of the device showing its geometry. The paths of the @@ -321,7 +304,7 @@ NXpolarizer_opt(NXcomponent): # # # Properties of the substrate material of the polarizer. If the device has -# a coating specify the coating material and its properties in 'coating'. +# a coating specify the coating material and its properties in ``coatingTYPE``. # # # @@ -344,28 +327,29 @@ NXpolarizer_opt(NXcomponent): # # # -# -# # # If the device has a coating describe the material and its properties. # Some basic information can be found e.g. [here] # (https://www.opto-e.com/basics/reflection-transmission-and-coatings). # If the back and front side of the polarizer are coated with different -# materials, you may define two coatings (e.g. COATING1 and COATING2). +# materials, you may define two coatings (e.g. coating_front and +# coating_back). # -# +# # # Specify the coating type (e.g. dielectric, anti-reflection (AR), # multilayer coating etc.). # # -# +# # # Describe the coating material (e.g. MgF2). # # -# +# # # Thickness of the coating. # @@ -405,5 +389,4 @@ NXpolarizer_opt(NXcomponent): # # # -# # diff --git a/contributed_definitions/nyaml/NXstm.yaml b/contributed_definitions/nyaml/NXstm.yaml index 8fd13db5e9..88e11489c5 100644 --- a/contributed_definitions/nyaml/NXstm.yaml +++ b/contributed_definitions/nyaml/NXstm.yaml @@ -87,7 +87,6 @@ NXstm(NXspm): This should be a link to /entry/instrument/bias_spectroscopy_environment/bias_spectroscopy/bias_sweep modulation_signal_type: - nameType: any exists: optional doc: | This is the signal on which the modulation voltage or current will be added. @@ -140,7 +139,7 @@ NXstm(NXspm): /entry/instrument/lockin_amplifier/reference_frequency # ++++++++++++++++++++++++++++++++++ SHA HASH ++++++++++++++++++++++++++++++++++ -# 557ffe6cbd0f9b49a01f281d9d2533de75f276fe47f5406c55ae17a29c6d905c +# 17dbd250bce39649addc743bc5d85fd2b9548652747dd52707d1e7692b0b904c # # # # # # @@ -362,7 +332,7 @@ NXtransmission(NXobject): # # # -# +# # # Contact information of at least the user of the instrument or the investigator # who performed this experiment. Adding multiple users if relevant is recommended. @@ -372,32 +342,12 @@ NXtransmission(NXobject): # Name of the user. # # -# +# # # Name of the affiliation of the user at the point in time when the experiment was # performed. # # -# -# -# Street address of the user's affiliation. -# -# -# -# -# Email address of the user. -# -# -# -# -# Author ID defined by research id services, e.g. orcid (https://orcid.org/). -# -# -# -# -# Telephone number of the user. -# -# # # # @@ -447,14 +397,15 @@ NXtransmission(NXobject): # # # -# +# # # Overall spectral resolution of this spectrometer. # If several gratings are employed the spectral resolution # should rather be specified for each grating inside the # NXgrating group of this spectrometer. # -# +# +# # # # Diffraction grating, as could be used in a monochromator. @@ -464,7 +415,7 @@ NXtransmission(NXobject): # do not overlap. The dispersion should be defined for the # entire wavelength range of the experiment. # -# +# # # Dispersion of the grating in nm/mm used. # @@ -474,12 +425,13 @@ NXtransmission(NXobject): # The blaze wavelength of the grating used. # # -# +# # # Overall spectral resolution of the instrument # when this grating is used. # -# +# +# # # # Wavelength range in which this grating was used @@ -560,7 +512,7 @@ NXtransmission(NXobject): # # The type of lamp, e.g. halogen, D2 etc. # -# +# # # # @@ -584,8 +536,6 @@ NXtransmission(NXobject): # # # -# # # Properties of the sample measured # diff --git a/dev_tools/docs/nxdl_index.py b/dev_tools/docs/nxdl_index.py index 81178e63ba..150edc1bfc 100644 --- a/dev_tools/docs/nxdl_index.py +++ b/dev_tools/docs/nxdl_index.py @@ -8,16 +8,81 @@ from ..globals.nxdl import NXDL_NAMESPACE from ..nxdl import iter_definitions +SOURCE_TO_CATEGORY = { + "applications": {"alias": "application definitions", "sphx_id": "AppDef"}, + "base_classes": {"alias": "base classes", "sphx_id": "BC"}, + "contributed_definitions": {"alias": "contributed definitions", "sphx_id": "CC"}, +} + +SOURCE_TO_GROUPING = { + "applications": ["apm", "diff", "em", "mpes", "optical-spectroscopy", "sas", "tof"], + "base_classes": [ + "core", + "tech", + "sample", + "computer", + "danalysis", + "cg", + "apm", + "em", + "mpes", + "optical-spectroscopy", + ], + "contributed_definitions": [ + "sample", + "danalysis", + "cg", + "apm", + "optical-spectroscopy", + "transport", + "micro", + "spm", + ], +} + +MOVE_LONG_FLAT_LIST_TO_OWN_GROUP = ( + True # True for long-flat list in own group, else for legacy support +) -def nxdl_indices() -> Dict[str, dict]: + +def nxdl_indices(write_rst: bool = True) -> Dict[str, dict]: """For each directory under the NXDL root, create the content of an index file which link all NeXus class definition doc files. + + write_rst, if true instructs the writing of rst documents with the + list of all definitions for each respective section (appdefs, classes) """ indentation = " " * 4 namespaces = {"nx": NXDL_NAMESPACE} sections = dict() root = directories.get_nxdl_root() + if MOVE_LONG_FLAT_LIST_TO_OWN_GROUP: + # apart from groupings for NXDL/XML on specifics topics wish to have index for respective complete-structure.rst + all_rst_lines: Dict[str, list] = { + "applications": [], + "base_classes": [], + "contributed_definitions": [], + } + for source in SOURCE_TO_CATEGORY: + all_rst_lines[source].append(".. do NOT edit this file\n") + all_rst_lines[source].append( + " automatically generated by dev_tools.docs.nxdl_index\n" + ) + all_rst_lines[source].append("\n") + all_rst_lines[source].append( + f".. _{SOURCE_TO_CATEGORY[source]['sphx_id']}-Complete-Structure:\n" + ) + all_rst_lines[source].append("\n") + title = SOURCE_TO_CATEGORY[source]["alias"].title() + all_rst_lines[source].append(f"{'=' * len(title)}\n") + all_rst_lines[source].append(f"{title}\n") + all_rst_lines[source].append(f"{'=' * len(title)}\n") + all_rst_lines[source].append("\n") + all_rst_lines[source].append( + f"This is the complete list of {SOURCE_TO_CATEGORY[source]['alias']}:\n" + ) + for nxdl_file in iter_definitions(): source = os.path.relpath(nxdl_file.parent, root) section = sections.get(source) @@ -38,6 +103,15 @@ def nxdl_indices() -> Dict[str, dict]: rst_lines.append("\n") rst_lines.append(preample) rst_lines.append("\n") + if MOVE_LONG_FLAT_LIST_TO_OWN_GROUP: + rst_lines.append( + f" :ref:`Complete List <{SOURCE_TO_CATEGORY[source]['sphx_id']}-Complete-Structure>`\n" + ) + else: + rst_lines.append( + f"The full list of {SOURCE_TO_CATEGORY[source]['alias']}:\n" + ) + rst_lines.append("\n") else: classes = sections[source]["classes"] rst_lines = sections[source]["rst_lines"] @@ -45,14 +119,38 @@ def nxdl_indices() -> Dict[str, dict]: nxclass_name = nxdl_file.with_suffix("").stem classes.append(nxclass_name) summary = get_nxclass_description(nxdl_file, namespaces) - if "NXcg" in nxclass_name or "NXapm" in nxclass_name or "NXms" in nxclass_name: - continue - rst_lines.append("\n") - rst_lines.append(f":ref:`{nxclass_name}`\n") - rst_lines.append(f"{indentation}{summary}\n") + if MOVE_LONG_FLAT_LIST_TO_OWN_GROUP: + all_rst_lines[source].append("\n") + all_rst_lines[source].append(f":ref:`{nxclass_name}`\n") + all_rst_lines[source].append(f"{indentation}{summary}\n") + else: # the legacy long flat list listing all + rst_lines.append("\n") + rst_lines.append(f":ref:`{nxclass_name}`\n") + rst_lines.append(f"{indentation}{summary}\n") + + assert list(sections.keys()) == [ + "applications", + "base_classes", + "contributed_definitions", + ] + + if MOVE_LONG_FLAT_LIST_TO_OWN_GROUP: + for source in all_rst_lines: + file_path = ( + directories.manual_build_sphinxroot() + / "classes" + / f"{source}" + / "complete-structure.rst" + ) + if write_rst: # when called from pytest build dir might not exist + with open(file_path, "w") as fh: + fh.writelines(all_rst_lines[source]) + print(f"{file_path} written") + del all_rst_lines # Create a table of content for each index file - for section in sections.values(): + for source, section in sections.items(): + # rst_lines is list of rst document for each NXDL/XML classes = section.pop("classes") rst_lines = section["rst_lines"] rst_lines.append("\n") @@ -66,19 +164,14 @@ def nxdl_indices() -> Dict[str, dict]: else: file = "" print("---------++++++++-", section) - if file.endswith("contributed_definitions/index.rst"): - rst_lines.append(f"{indentation}em-structure\n") - rst_lines.append(f"{indentation}optical-spectroscopy-structure\n") - rst_lines.append(f"{indentation}mpes-structure\n") - rst_lines.append(f"{indentation}apm-structure\n") - rst_lines.append(f"{indentation}transport-structure\n") - rst_lines.append(f"{indentation}spm-structure\n") - rst_lines.append(f"{indentation}cgms-structure\n") - rst_lines.append(f"{indentation}icme-structure\n") - + if file.endswith(f"{source}/index.rst"): + for domain in SOURCE_TO_GROUPING[source]: + rst_lines.append(f"{indentation}{domain}-structure\n") + # do not forget autogenerated summary + if MOVE_LONG_FLAT_LIST_TO_OWN_GROUP: + rst_lines.append(f"{indentation}complete-structure\n") for cname in sorted(classes): rst_lines.append(f"{indentation}{cname}\n") - return sections @@ -112,6 +205,29 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: *might* be used in an instance of that class. Consider the base classes as a set of *components* that are used to construct a data file. + +A grouping of base classes is offered to assist users with +navigating the full list of base classes along the following topics: + + :ref:`Core Classes ` + + :ref:`Instrument Components ` + + :ref:`Working with Samples ` + + :ref:`Working with Computers ` + + :ref:`Conventions, Reference Frames, and Data Analysis ` + + :ref:`Computational and Constructive Solid Geometry ` + + :ref:`Atom Probe Microscopy ` + + :ref:`Electron Microscopy ` + + :ref:`Multi-Dimensional Photoemission Spectroscopy ` + + :ref:`Optical Spectroscopy ` """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "applications": """ @@ -140,6 +256,24 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: In application definitions involving raw data, write the raw data in the :ref:`NXinstrument` tree and then link to it from the location(s) defined in the relevant application definition. + +Application definitions are grouped together based on the research fields +where these are typically used. Definitions that address multiple +research fields are listed in each category: + + :ref:`Atom Probe Microscopy ` + + :ref:`Diffraction Techniques ` + + :ref:`Electron Microscopy ` + + :ref:`Multi-Dimensional Photoemission Spectroscopy ` + + :ref:`Optical Spectroscopy ` + + :ref:`Scattering Techniques ` + + :ref:`Time-of-Flight Techniques ` """, # - - - - - - - - - - - - - - - - - - - - - - - - - - - - "contributed_definitions": """ @@ -155,27 +289,30 @@ def get_nxclass_description(nxdl_file: Path, namespaces) -> str: A description of each NeXus contributed definition is given. NXDL files in the NeXus contributed definitions include propositions from the community for NeXus base classes or application definitions, as well -as other NXDL files for long-term archival by NeXus. Consider the contributed +as other NXDL files for long-term archival by NeXus. Consider the contributed definitions as either in *incubation* or a special case not for general use. The :ref:`NIAC` is charged to review any new contributed definitions and provide feedback to the authors before ratification and acceptance as either a base class or application definition. -Some contributions are grouped together: - :ref:`Optical Spectroscopy ` +These contributions are grouped together based on the research fields +where these are typically used. Definitions that address multiple +research fields are listed in each category: - :ref:`Multi-dimensional Photoemission Spectroscopy ` + :ref:`Working with Samples ` - :ref:`Atom Probe Microscopy ` + :ref:`Conventions and Data Analysis ` - :ref:`Electron Microscopy ` + :ref:`Computational and Constructive Solid Geometry ` - :ref:`Transport Measurements ` + :ref:`Atom Probe Microscopy ` - :ref:`Geometry and Microstructures ` + :ref:`Optical Spectroscopy ` + :ref:`Scanning Probe Microscopy ` -and others are simply listed here: + :ref:`Transport Measurements ` + :ref:`Microstructures Characterization and Representation ` """, } diff --git a/dev_tools/tests/test_docs.py b/dev_tools/tests/test_docs.py index f0a8bca984..01288d3227 100644 --- a/dev_tools/tests/test_docs.py +++ b/dev_tools/tests/test_docs.py @@ -42,7 +42,7 @@ def test_nxdl_anchor_write_list(nxdl_file, doc_generator, anchor_registry_write) def test_nxdl_indices(): - sections = nxdl_indices() + sections = nxdl_indices(write_rst=False) expected = {"base_classes", "applications", "contributed_definitions"} assert set(sections) == expected diff --git a/manual/source/apm-structure.rst b/manual/source/apm-structure.rst index 581e2ec5b8..ea049918b0 100644 --- a/manual/source/apm-structure.rst +++ b/manual/source/apm-structure.rst @@ -6,4 +6,5 @@ Atom-probe tomography Atom probe tomography and related field-ion microscopy, aka atom probe microscopy (techniques) cover metrology methods with an origin in the materials science and condensed-matter physics communities. With its maturation and commercialization in the last two decades atom probe is increasingly being used for characterization of bio materials and fundamental science of field evaporation physics. -A status report of the ongoing work on data schemas for atom probe using NeXus is available here: :ref:`Apm-Structure`. +The list of standardized data schemas for atom probe in NeXus is available here: :ref:`Appdef-Apm-Structure`. +A status report of additional ongoing work on NeXus data schemas for atom probe is available here: :ref:`CC-Apm-Structure`. diff --git a/manual/source/applying-nexus.rst b/manual/source/applying-nexus.rst index 0809ab172d..bc009dea7b 100644 --- a/manual/source/applying-nexus.rst +++ b/manual/source/applying-nexus.rst @@ -561,12 +561,18 @@ Processed Data NXprocess Processed Data -Data reduction and analysis programs are encouraged to store their results in -NeXus data files. As far as the necessary, the normal NeXus -:index:`hierarchy ` -is to be implemented. In addition, processed data files -must contain a :ref:`NXprocess` -group. This group, that documents and preserves data provenance, -contains the name of the data processing program and the -parameters used to run this program in order to achieve the results stored in -this entry. Multiple processing steps must have a separate entry each. +Data reduction and analysis programs are encouraged to store their +results in NeXus data files, which may be the same file that contains +the raw data. It is recommended to document the actions taken to +generate the processed data in a :ref:`NXprocess` group, which has +fields to store the name of the program used, its version number, and +the date when it was run. If there are multiple processes recorded in +the file, the group should also contain a sequence index to specify the +order in which they were run. NXprocess groups can also contain one or +more :ref:`NXparameters` groups to store the parameters used by the +program as well as one or more :ref:`NXdata` groups that contain the +results of the process. This has the advantage of encapsulating all the +information required to preserve the provenance of the processed data in +a single group. However, it is also acceptable to store the resulting +data in a NXdata group at the same level as the NXprocess group in the +NeXus :index:`hierarchy `. diff --git a/manual/source/cgms-structure.rst b/manual/source/cgms-structure.rst index 563479b17f..1f346ef2df 100644 --- a/manual/source/cgms-structure.rst +++ b/manual/source/cgms-structure.rst @@ -8,6 +8,4 @@ Computational geometry is a frequently used tool for describing the shape and ge NeXus has a long history of base classes which serve specifically the former tasks. Upon closer inspection during the first year of the FAIRmat project we found though that the collection of base classes could profit from an extension to make working with computational geometry data in NeXus simpler and more fine-grained. -A status report of this ongoing work is available here: :ref:`CgmsFeatures-Structure`. - -A status report of how these definitions can be of value for the field of Integrated Materials Engineering (ICME) is available here: :ref:`Icme-Structure`. +A status report of this ongoing work is available here: :ref:`BC-Cgeometry-Structure` and :ref:`CC-Micro-Structure`. \ No newline at end of file diff --git a/manual/source/classes/applications/NXem.TopLevelDoc.FIB.svg b/manual/source/classes/applications/NXem.TopLevelDoc.FIB.svg new file mode 100644 index 0000000000..961b7bdd01 --- /dev/null +++ b/manual/source/classes/applications/NXem.TopLevelDoc.FIB.svg @@ -0,0 +1,1532 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + optical axis + + + + + + + ebeam_column:NXebeam_column + ibeam_column:NXibeam_column + NXcs_computerNXcs_processor... + NXuserNXciteNXnote + NXpumpNXcircuit + + + + + + NXcoordinate_systemNXtransformations + instrument:NXem_instrument + + + + + + >> 011011 >> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + gas_injector:NXmanipulator + nanoprobeID:NXmanipulator + + + + + + + e- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Xe + + + ion_source:NXsource + lensID:NXelectromagnetic_lens + apertureID:NXaperture + scan_controller:NXscan_controller + + diff --git a/manual/source/classes/applications/NXem.TopLevelDoc.SEM.svg b/manual/source/classes/applications/NXem.TopLevelDoc.SEM.svg new file mode 100644 index 0000000000..ebeed62e68 --- /dev/null +++ b/manual/source/classes/applications/NXem.TopLevelDoc.SEM.svg @@ -0,0 +1,1360 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + aperture1:NXaperture + + + + + aperture2:NXaperture + lens1:NXelectromagnetic_lens + lens2:NXelectromagnetic_lens + scan_controller:NXscan_controller + corrector_ax:NXcomponent + electron_source:NXsource + detector1:NXdetector + detector2:NXdetector + detector3:NXdetector + sample:NXsample + componentID:NXcomponentlensID:NXelectromagnetic_lensapertureID:NXaperturedeflectorID:NXdeflectorsensorID:NXsensoractuatorID:NXactuatorbeamID:NXbeamdetectorID:NXdetectormonochromatorID:NXmonochromator + interaction_volumeID:NXem_interaction_volume + + + + + + + + + + + + + + + + + + + + + + + + + optical axis + + + + + + + ebeam_column:NXebeam_column + NXcs_computerNXcs_processorNXcs_memoryNXcs_storageNXcs_profilingNXprocessNXprogramNXem_imgNXem_ebsdNXem_edsNXem_eels + NXuserNXciteNXnote + NXpumpNXcircuit + + + + + + NXcoordinate_systemNXtransformations + instrument:NXem_instrument + + + + + + >> 011011 >> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + stage:NXmanipulator + + + e- + + + + Cax + + + diff --git a/manual/source/classes/applications/NXem.TopLevelDoc.TEM.svg b/manual/source/classes/applications/NXem.TopLevelDoc.TEM.svg new file mode 100644 index 0000000000..17766353f7 --- /dev/null +++ b/manual/source/classes/applications/NXem.TopLevelDoc.TEM.svg @@ -0,0 +1,1851 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + aperture1:NXaperture + + + + + aperture3:NXaperture + lens1:NXelectromagnetic_lens + lens3:NXelectromagnetic_lens + lens4:NXelectromagnetic_lens + lens5:NXelectromagnetic_lens + scan_controller:NXscan_controller + NXmonochromator + electron_source:NXsource + NXdetector + NXdetector + NXdetector + NXdetector + sample:NXsample + NXcomponentNXelectromagnetic_lensNXapertureNXdeflectorNXmonochromatorNXsensorNXactuatorNXbeamNXdetectorbiprismID:NXcomponentphaseplateID:NXcomponent + NXem_interaction_volume + + + + + + + + + + + + + + + aperture2:NXaperture + lens2:NXelectromagnetic_lens + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + optical axis + + + + + + + + + + + + + ebeam_column:NXebeam_column + NXcs_computer...NXprocess... + NXuserNXciteNXnote + NXpumpNXcircuit + + + + + + NXcoordinate_systemNXtransformations + corrector_cs:NXcorrector_cs + + >> 011011 >> + + + + + + + + + + + + + + + + + + + + + + + + + + + EELS + + + + CCD + + stage:NXmanipulator + + + + + + + Cs + + + + Ω + + + + + + + + + + + + + + + + + + + + + + instrument:NXem_instrument + + + e- + + + diff --git a/manual/source/classes/applications/apm-structure.rst b/manual/source/classes/applications/apm-structure.rst new file mode 100644 index 0000000000..ac561166d4 --- /dev/null +++ b/manual/source/classes/applications/apm-structure.rst @@ -0,0 +1,36 @@ +.. _AppDef-Apm-Structure: + +================================== +Atom Probe Microscopy / Tomography +================================== + +.. index:: + AppDef-Apm-Introduction + AppDef-Apm-Definitions + +.. _AppDef-Apm-Introduction: + +Introduction +############ + +Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, +steps to compute mass-to-charge-state ratios from uncorrected time of flight data, the reconstruction, and the ranging +i.e., the identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. +The data schemas are also useful for reporting field-ion microscopy experiments. + +.. _AppDef-Apm-Definitions: + +Application Definition +###################### + +Measurements as well as computer simulations of atom probe tomography and field-ion microscopy research +are standardized with one application definition: + +:ref:`NXapm` + A general application definition with many detailed places for leaving metadata + and computational steps described which are commonly used when reporting the + measurement of atom probe data including also detector hit data, as well as how + to proceed with reconstructing atom positions from these data, and how to store + details about definitions made which describe how mass-to-charge-state ratio + values are mapped to (molecular) iontypes in a process called ranging. + diff --git a/manual/source/classes/applications/diff-structure.rst b/manual/source/classes/applications/diff-structure.rst new file mode 100644 index 0000000000..fa77d123f7 --- /dev/null +++ b/manual/source/classes/applications/diff-structure.rst @@ -0,0 +1,66 @@ +.. _AppDef-Diff-Structure: + +================================== +Diffraction Techniques +================================== + +.. index:: + AppDef-Diff-Introduction + AppDef-Diff-Definitions + +.. _AppDef-Diff-Introduction: + +Introduction +############ + +Application definitions for different diffraction techniques + +.. _AppDef-Diff-Definitions: + +Application Definitions +####################### + +:ref:`NXiqproc` + Application definition for any :math:`I(Q)` data. + +:ref:`NXlauetof` + This is the application definition for a TOF laue diffractometer. + +:ref:`NXmonopd` + Monochromatic Neutron and X-Ray Powder diffractometer. + +:ref:`NXtomo` + This is the application definition for x-ray or neutron tomography raw data. + +:ref:`NXtomophase` + This is the application definition for x-ray or neutron tomography raw data + with phase contrast variation at each point. + +:ref:`NXtomoproc` + This is an application definition for the final result of a tomography experiment: + a 3D construction of some volume of physical properties. + +:ref:`NXxbase` + This definition covers the common parts of all monochromatic single crystal raw data application definitions. + +:ref:`NXxeuler` + Raw data from a :index:`four-circle diffractometer` with an :index:`eulerian cradle`, extends :ref:`NXxbase`. + +:ref:`NXxkappa` + Raw data from a kappa geometry (CAD4) single crystal diffractometer, extends :ref:`NXxbase`. + +:ref:`NXxlaue` + Raw data from a single crystal laue camera, extends :ref:`NXxrot`. + +:ref:`NXxlaueplate` + Raw data from a single crystal Laue camera, extends :ref:`NXxlaue`. + +:ref:`NXxnb` + Raw data from a single crystal diffractometer, extends :ref:`NXxbase`. + +:ref:`NXxrot` + Raw data from a rotation camera, extends :ref:`NXxbase`. + + + + diff --git a/manual/source/classes/applications/em-structure.rst b/manual/source/classes/applications/em-structure.rst new file mode 100644 index 0000000000..2fa059d3ac --- /dev/null +++ b/manual/source/classes/applications/em-structure.rst @@ -0,0 +1,125 @@ +.. _AppDef-Em-Structure: + +=================== +Electron microscopy +=================== + +.. index:: + AppDef-Em-Introduction + AppDef-Em-Design + AppDef-Em-Definitions + +.. _AppDef-Em-Introduction: + +Introduction +############ + +A set of data schemas is available to describe components of an electron microscope (EM) and its focused-ion beam (FIB) capabilities if available. + +Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as +on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using +high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and are becoming more closely +interconnected with classical modes of controlling the instrument and performing data processing. A challenge in electron microscopy +is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep +track of workflows in a technology-partner-agnostic, i.e., in an interdisciplinary manner. + +The application definitions and associated base classes were designed from the perspective of how electron microscopes are used in the +materials-science-branch of electron microscopy. Therefore, the focus is on the usage of electron microscopy in condensed-matter physics, +chemical physics of solids, and materials engineering applications. + +The biology-/bio-materials-/omics-/life-science-community of the electron microscopy community can also take advantage of the definitions +and classes. We acknowledge that the Open Microscopy Environment (https://www.openmicroscopy.org) offers a data model and +schema set for the life science. Conceptual and semantic overlap between concepts of these two data models exist but should be explored +further in the future to improve on the interoperability of data exchange between the materials-science and life science communities. + +.. _AppDef-Em-Design: + +Design +###### + +NXem provides support for documenting research with scanning electron microscopes (SEM), scanning electron microscopes that are equipped with +focused-ion beam (FIB) capabilities (SEM/FIB), and transmission electron microscopes (TEM) respectively scanning transmission electron microscopy (STEM). +The actual design of the electron-optical beam path and individual components used differ. Therefore, the base classes of and application definition NXem +offers modular building blocks from which a virtual electron microscope is instantiated. + +The following three figures provide one schematic example for each respective type of instrument (SEM, SEM/FIB, (S)TEM). Specifically, the figure +shows how the concepts of NXem can be used to describe each instrument. All figures are meant for illustrative and educational purposes. +The figures build up complexity successively starting with the simpler case of an SEM (Fig. 1), moving to an SEM with FIB capabilities (Fig. 2), and +arriving at an (S)TEM (Fig. 3) instrument. The capabilities that are illustrated for the SEM in Fig. 1 are also offered for all further cases. +For the sake of conciseness and clarity these classes are not repeated though in subsequent figures. The examples take the perspective of +typical users who are interested in reporting metadata and data that have been collected during a session with such microscopes: + +.. image:: NXem.TopLevelDoc.SEM.svg + :width: 100% + +**Fig. 1** - an example for an SEM +The instrument is constructed from a so-called column, a housing for all technical components such as the electron source, +the lenses, like here shown a condenser and an objective lens, respective apertures, and further components, like a stigmator +to correct for axial image distortions. The trajectory of the electron beam along the optical axis is simplified for +illustrative purposes. In summary, the sample is illuminated by an electron beam that is guided along the optical axis +through and past a set of components. A scan controller is used to deflect this beam to illuminate specific locations +on the sample surface. In response to the electron-beam sample interaction an interaction volume is formed. +Different types of signals are generated that are picked up by different types of detectors. Three detectors +are shown as an example. Apart from the column, an SEM has further components: The base classes that are used for +modeling these are listed in the lower part of the figure. These document pumps and other hardware, assumptions made +such as frames of references and transformations between these frames, and the computing hardware and software tools +that are used for controlling the SEM and all its connected components. Using an electron microscope demands +processing of data. These processing steps are modeled with instances and specializations of the NXprocess base class. +These specializations are used for documenting the parameterization, the results, and the sequence of such processing steps. +Examples of method-specific base classes are NXem_ebsd for electron backscatter diffraction (EBSD), NXem_eds for +energy-dispersive X-ray spectroscopy (EDS/EDXS), NXem_img for different imaging modes (secondary electron, backscattered electron), +and NXem_eels for electron energy loss spectroscopy (EELS). + +.. image:: NXem.TopLevelDoc.FIB.svg + :width: 100% + +**Fig. 2** - an example for an SEM with plasma FIB capabilities +Adding or flanging another column to an electron microscope equips it with focused-ion beam capabilities. +The design of this NXibeam_column follows the design of the NXebeam_column: A housing with technical components, +such as the ion source, lenses, apertures, beam distortion and beam shaping components, and an own scan controller +for guiding the ion beam towards the sample surface. Like in Fig. 1, the trajectory of the ion beam is simplified. + +.. image:: NXem.TopLevelDoc.TEM.svg + :width: 100% + +**Fig. 3** an example for a (S)TEM +The design principles for the SEM as well as the FIB are used for modeling a transmission electron microscope. +Noteworthy is that the figure illustrates an optical setup that is a mixture of a conventional TEM and a STEM +(again for illustrative purposes). The presence of a scan controller is one characteristic feature of an STEM. +Given that a TEM specimen is typically orders of magnitude thinner than a specimen used in an SEM, the electron beam +can penetrate the material. This enables investing additional imaging modes and probing other characteristic +electron-matter interactions such as electron energy loss spectroscopy. Consequently, additional lenses and components +are introduced into the beam path of the exiting electrons. + +.. _AppDef-Em-Definitions: + +Application Definition +###################### + +An experiment with an electron microscope proceeds as follows: users place a sample into the microscope, calibrate the instrument, +take measurements, may prepare their specimens with a focused ion beam, calibrate again, and take further measurements, +they process data, until eventually their session on the instrument ends. In between virtually all of these steps, data +are collected and stream in from different detectors. Each detector probes different physical mechanisms +of the interaction between electrons or other types of radiation with the specimen and its environment. +A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. +Occasionally, service technicians perform calibrations and maintenance, which also can be described as a session on the microscope. +Base classes are provided to describe these steps and events. + +A simulation of an electron microscope or of the interaction between an electron beam with matter takes a simpler perspective on many of +these practical aspects. Typically, an electron-optical setup and material is defined, assumptions about the properties and trajectory +of the electron beam are made or simulated. The simulation analyzes the interaction volume by inspecting e.g. the trajectories of +individual electrons or by modeling their collective behavior via computing numerical solutions or approximations for the +electromagnetic field. + +Measurements as well as computer simulations of electron microscopy research +are standardized with one application definition: + +:ref:`NXem` + A general application definition which explores the possibilities of electron microscopes + for characterizing electron- and ion-beam matter interactions. + +Currently NXem does not provide standardized descriptions for experiments where photons are interacting with the electron beam. +The blueprint of NXebeam_column and NXibeam_column surplus the definitions and classes provided by :ref:`NXoptical_spectroscopy` +provide though a starting point for adding such descriptions in the future via for example an NXpbeam_column. + + diff --git a/manual/source/classes/applications/mpes-structure.rst b/manual/source/classes/applications/mpes-structure.rst new file mode 100644 index 0000000000..270dcb7e73 --- /dev/null +++ b/manual/source/classes/applications/mpes-structure.rst @@ -0,0 +1,46 @@ +.. _AppDef-Mpes-Structure: + +======================================= +Photoemission & core-level spectroscopy +======================================= + +.. index:: + AppDef-Mpes-Introduction + AppDef-Mpes-Definitions + + +.. _AppDef-Mpes-Introduction: + +Introduction +############ + +These are a set of application definitions to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) +and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, +near-ambient pressure conditions, dichroism etc. + +.. _AppDef-Mpes-Definitions: + +Application Definitions +####################### + +:ref:`NXmpes` + A general application definition with minimalistic metadata requirements, + apt to describe all photoemission experiments. + +:ref:`NXmpes_arpes` + An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. + +:ref:`NXxps` + An application definition for X-ray/UV photoelectron spectroscopy (XPS/UPS) experiments. + + +:ref:`NXarpes` + An application definition for angular resolved photo emission spectroscopy. + Note that this application definition is only kept for legacy reasons and + new NeXus ARPES files should use :ref:`NXmpes_arpes`. + +Base classes +####################### + +A specific set of base classes which are used in these application definitions can be found :ref:`here `. diff --git a/manual/source/classes/applications/optical-spectroscopy-structure.rst b/manual/source/classes/applications/optical-spectroscopy-structure.rst new file mode 100644 index 0000000000..c7fe8ffde8 --- /dev/null +++ b/manual/source/classes/applications/optical-spectroscopy-structure.rst @@ -0,0 +1,56 @@ +.. _AppDef-Opt-Spec-Structure: + +==================== +Optical Spectroscopy +==================== + +.. index:: + AppDef-Opt-Spec-Ellipsometry + AppDef-Opt-Spec-Raman + AppDef-Opt-Spec-Definitions + +.. _AppDef-Opt-Spec-Ellipsometry: + +Ellipsometry +############ + +Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. +The measurements are based on determining how the polarization state of light changes upon transmission and reflection. +Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. + +In the application definition, a minimum set of description elements allowing for a reproducible recording of ellipsometry +measurements is provided. + +.. _AppDef-Opt-Spec-Raman: + +Raman spectroscopy +################## + +Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases, or solids. +The measurements are based on the inelastic light scattering due to the material's vibrations. +Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). + +The application definition contains a minimum of descriptive elements required to understand Raman spectroscopy measurements. + +.. _AppDef-Opt-Spec-Definitions: + +Application Definitions +----------------------- + +:ref:`NXoptical_spectroscopy` + A generic application definition for spectroscopy measurements. This includes in particular ellipsometry and Raman spectroscopy measurements, + but also other techniques such as photoluminescence, transmission, and reflection measurements. + The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons, + and (iii) a sample. + +:ref:`NXellipsometry` + An application definition for ellipsometry measurements, including complex systems + up to variable angle spectroscopic ellipsometry. + +:ref:`NXraman` + An application definition for Raman spectroscopy measurements. + +Base classes +####################### + +A specific set of base classes which are used in these application definitions can be found :ref:`here `. diff --git a/manual/source/classes/applications/sas-structure.rst b/manual/source/classes/applications/sas-structure.rst new file mode 100644 index 0000000000..a237637475 --- /dev/null +++ b/manual/source/classes/applications/sas-structure.rst @@ -0,0 +1,33 @@ +.. _AppDef-Sas-Structure: + +=================================== +(Small-Angle) Scattering Techniques +=================================== + +.. index:: + AppDef-Sas-Introduction + AppDef-Sas-Definitions + +.. _AppDef-Sas-Introduction: + +Introduction +############ + +Application definitions for (small-angle) scattering + +.. _AppDef-Sas-Definitions: + +Application Definitions +####################### + +:ref:`NXcanSAS` + Implementation of the canSAS standard to store reduced small-angle scattering data of any dimension. + +:ref:`NXsas` + Raw, monochromatic 2-D SAS data with an area detector. + +:ref:`NXsastof` + Raw 2-D SAS data with an area detector with a time-of-flight source. + + + diff --git a/manual/source/classes/applications/tof-structure.rst b/manual/source/classes/applications/tof-structure.rst new file mode 100644 index 0000000000..0048ea0909 --- /dev/null +++ b/manual/source/classes/applications/tof-structure.rst @@ -0,0 +1,48 @@ +.. _AppDef-Tof-Structure: + +================================== +Time-of-Flight (TOF) Techniques +================================== + +.. index:: + AppDef-Tof-Introduction + AppDef-Tof-Definitions + +.. _AppDef-Tof-Introduction: + +Introduction +############ + +Classical application definitions for time-of-flight (spectroscopy) techniques. + +.. _AppDef-Tof-Definitions: + +Application Definitions +####################### + +:ref:`NXdirecttof` + This is a application definition for raw data from a direct geometry TOF spectrometer. + +:ref:`NXindirecttof` + This is a application definition for raw data from an indirect geometry TOF spectrometer. + +:ref:`NXlauetof` + This is the application definition for a TOF laue diffractometer. + +:ref:`NXreftof` + This is an application definition for raw data from a TOF reflectometer. + +:ref:`NXsastof` + Raw, 2-D SAS data with an area detector with a time-of-flight source. + +:ref:`NXtofnpd` + This is a application definition for raw data from a TOF neutron powder diffractometer. + +:ref:`NXtofraw` + This is an application definition for raw data from a generic TOF instrument. + +:ref:`NXtofsingle` + This is a application definition for raw data from a generic TOF instrument. + + + diff --git a/manual/source/classes/base_classes/apm-structure.rst b/manual/source/classes/base_classes/apm-structure.rst new file mode 100644 index 0000000000..fb19aaba7f --- /dev/null +++ b/manual/source/classes/base_classes/apm-structure.rst @@ -0,0 +1,49 @@ +.. _BC-Apm-Structure: + +================================== +Atom Probe Microscopy / Tomography +================================== + +.. index:: + BC-Apm-Introduction + BC-Apm-Classes + +.. _BC-Apm-Introduction: + +Introduction +############ + +The :ref:`NXapm` application definition uses base classes that describe the acquisition, i.e., the measurement side, the extraction of hits +from detector raw data, processing steps to compute mass-to-charge-state ratios from uncorrected time of flight data, the reconstruction, +and the ranging, i.e., identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. +The base classes can be useful to generate data artifacts also for field-ion microscopy experiments. + +.. _BC-Apm-Classes: + +Base Classes +############ + +:ref:`NXapm_charge_state_analysis` + Base class to document the parameters, configuration, and results of a processing for recovering + +:ref:`NXapm_event_data` + Base class to store state and (meta)data of events over the course of an atom probe experiment. + +:ref:`NXapm_instrument` + Base class for instrument-related details of a real or simulated + +:ref:`NXapm_measurement` + Base class for collecting a run with a real or a simulated atom probe or field-ion microscope. + +:ref:`NXapm_ranging` + Base class for the configuration and results of ranging definitions. + +:ref:`NXapm_reconstruction` + Base class for the configuration and results of a reconstruction algorithm. + +:ref:`NXapm_simulation` + Base class for simulation of ion extraction from matter via laser and/or voltage + +To see a full list of all base classes which NXapm uses, inspect the **Groups cited** +section the :ref:`NXapm` application definition. Consider also the alignment between +the design of the atom-probe- and electron-microscopy-specific definitions that is detailed in :ref:`BC-Em-Structure`. diff --git a/manual/source/classes/base_classes/cg-structure.rst b/manual/source/classes/base_classes/cg-structure.rst new file mode 100644 index 0000000000..4abae02d08 --- /dev/null +++ b/manual/source/classes/base_classes/cg-structure.rst @@ -0,0 +1,112 @@ +.. _BC-Cgeometry-Structure: + +============================================== +Computational and Constructive Solid Geometry +============================================== + +.. index:: + BC-Cgeometry-Introduction + BC-Cgeometry-Base-Classes + +.. _BC-Cgeometry-Introduction: + +Introduction +############ + +A set of base classes to describe the location and shape of objects using +concepts from the fields of computer graphics, computational geometry, +and constructive solid geometry (CSG). + +.. _BC-Cg-Introduction-Base-Classes: + +Base Classes +############ + +The following base classes are defined to incentivize the use of NeXus for +using computational-geometry-based descriptions. In what follows, base classes +for frequently used shapes and geometric primitives are proposed: + +:ref:`NXcg_primitive` + Base class from which most other NXcg classes that define specific primitives inherit. + +:ref:`NXcg_ellipsoid` + A description for a set of possibly dissimilar oriented ellipsoids. + +:ref:`NXcg_cylinder` + A description for a set of possibly dissimilar oriented cylinders. + +:ref:`NXcg_point` + A collection of points with labels. + +:ref:`NXcg_polyline`: + A collection of lines and linear segments. + +:ref:`NXcg_triangle` + A collection of triangles. + +:ref:`NXcg_parallelogram` +A collection of possibly dissimilar parallelograms. + +:ref:`NXcg_polygon` + A collection of polygons. + +:ref:`NXcg_polyhedron` + A collection of polyhedra. + +:ref:`NXcg_roi` + A container to host a number of different types of primitives. + +:ref:`NXcg_tetrahedron` + A collection of tetrahedra. + +:ref:`NXcg_hexahedron` + A collection of hexahedra with capabilities to represent + also simpler (bounding) boxes for e.g. binary trees. + +An example how to use these classes follows: + +.. literalinclude:: cube_example.txt + :tab-width: 4 + :linenos: + :language: text + +These base classes describe data structures used for more complex geometries: + +:ref:`NXcg_face_list_data_structure` + In essence, the usual way how polygon/polyhedra data are reported: + A list of vertices and faces with identifier and properties. + +:ref:`NXcg_half_edge_data_structure` + A half-edge data structure (also known as a doubly connected edge list) + is a useful complementary descriptor for polygon/polyhedra which enables + topological analyses and traversal of the graph of how polygons and + polyhedra are connected. + +:ref:`NXcg_unit_normal` + As an additional structuring element especially for meshes, well-documented + normal information is crucial for distance computations. + +:ref:`NXcg_alpha_complex` + Alpha shapes and alpha wrappings, specifically the special case of the + convex hull, are frequently used geometrical models for describing + a boundary or edge to a set of geometric primitives. + + Next, a few base classes are defined for documenting discretized representations + of material (area or volume) which can be useful not only for stencil-based methods: + +:ref:`NXcg_grid` + A grid of cells. + +:ref:`NXisocontour` + A description for isocontour descriptions. + +:ref:`NXdelocalization` + An approach to document procedures whereby a scalar field + is smoothed in a controlled manner. + +:ref:`NXsimilarity_grouping` + A description for clustering of objects (such as atoms or features). + +:ref:`NXrotations` + A set of parameters to describe the relative orientation of + members of a set of features/objects. diff --git a/manual/source/classes/base_classes/computer-structure.rst b/manual/source/classes/base_classes/computer-structure.rst new file mode 100644 index 0000000000..eef7bc7a2d --- /dev/null +++ b/manual/source/classes/base_classes/computer-structure.rst @@ -0,0 +1,53 @@ +.. _BC-Computer-Structure: + +========================= +Working with Computers +========================= + +.. index:: + BC-Computer-Base-Classes + +Data schemas to describe a computer that was used for collecting or processing data. + +Base Classes +############ + +:ref:`NXcircuit` + Base class for documenting circuit devices. + +:ref:`NXcs_computer` + Base class for reporting the description of a computer. + +:ref:`NXcs_filter_boolean_mask` + Base class for packing and unpacking booleans. + +:ref:`NXcs_memory` + Base class for reporting the description of the memory system of a computer. + +:ref:`NXcs_prng` + Computer science description of pseudo-random number generator. + +:ref:`NXcs_processor` + Base class for reporting the description of processing units of a computer. + +:ref:`NXcs_profiling` + Computer science description for performance and profiling data of an application. + +:ref:`NXcs_profiling_event` + Computer science description of a profiling event. + +:ref:`NXcs_storage` + Base class for reporting the description of the I/O of a computer. + +:ref:`NXnote` + Any additional freeform information not covered by the other base classes. + +:ref:`NXprocess` + The :ref:`NXprocess` class describes an operation of processing data. + +:ref:`NXprogram` + Base class to describe a software tool or library. + +:ref:`NXuser` + Contact information for a user. + diff --git a/manual/source/classes/base_classes/core-structure.rst b/manual/source/classes/base_classes/core-structure.rst new file mode 100644 index 0000000000..49bc35d9c7 --- /dev/null +++ b/manual/source/classes/base_classes/core-structure.rst @@ -0,0 +1,59 @@ +.. _BC-Core-Structure: + +========================= +Core classes +========================= + +.. index:: + BC-Core-Base-Classes + +Base Classes +############ + +:ref:`NXcite` + A literature reference + +:ref:`NXcollection` + An unvalidated set of terms, such as the description of a beam line. + +:ref:`NXdata` + The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. + +:ref:`NXentry` + (**required**) :ref:`NXentry` describes the measurement. + +:ref:`NXenvironment` + Parameters for controlling external conditions + +:ref:`NXevent_data` + +:ref:`NXlog` + Information recorded as a function of time. + +:ref:`NXmonitor` + A monitor of incident beam data. + +:ref:`NXnote` + Any additional freeform information not covered by the other base classes. + +:ref:`NXobject` + This is the base object of NeXus. + +:ref:`NXparameters` + Container for parameters, usually used in processing or analysis. + +:ref:`NXprocess` + The :ref:`NXprocess` class describes an operation of data processing. + +:ref:`NXroot` + The root of a NeXus file. + +:ref:`NXsample` + Any information on the sample. + +:ref:`NXsubentry` + Group of multiple application definitions for "multi-modal" (e.g. SAXS/WAXS) measurements. + +:ref:`NXuser` + Contact information for a user. + diff --git a/manual/source/classes/base_classes/cube_example.txt b/manual/source/classes/base_classes/cube_example.txt new file mode 100644 index 0000000000..2f669d767f --- /dev/null +++ b/manual/source/classes/base_classes/cube_example.txt @@ -0,0 +1,12 @@ +/entry1:NXentry + /reference_frame:NXcoordinate_system + /x = [1, 0, 0] + /y = [0, 1, 0] + /z = [0, 0, 1] + /unit_cube:NXcg_hexahedron + /is_axis_aligned = True + /hexahedron1:NXcg_face_list_data_structure + /@depends_on = "/entry1/reference_frame" + /number_of_vertices = 8 + /vertices = [[0, 0, 0], [1, 0, 0], [1, 1, 0], [0, 1, 0], + [0., 0, 1], [1, 0, 1], [1, 1, 1], [0, 1, 1]] diff --git a/manual/source/classes/base_classes/danalysis-structure.rst b/manual/source/classes/base_classes/danalysis-structure.rst new file mode 100644 index 0000000000..75f0fe26a6 --- /dev/null +++ b/manual/source/classes/base_classes/danalysis-structure.rst @@ -0,0 +1,78 @@ +.. _BC-Danalysis-Structure: + +================================================= +Conventions, Reference Frames, and Data Analysis +================================================= + +.. index:: + BC-Danalysis-Base-Classes + +Base Classes +############ + +:ref:`NXaberration` + Quantified aberration coefficient in an aberration_model. + +:ref:`NXactivity` + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + +:ref:`NXcoordinate_system` + Base class to detail a coordinate system (CS). + +:ref:`NXdata` + The :ref:`NXdata` class is designed to encapsulate all the information required for a set of data to be plotted. + +:ref:`NXevent_data` + NXevent_data is a special group for storing data from neutron + +:ref:`NXfilter` + For band pass beam filters. + +:ref:`NXfit` + Description of a fit procedure using a scalar valued global function + +:ref:`NXfit_function` + This describes a fit function that is used to fit data to any functional form. + +:ref:`NXhistory` + A set of activities that occurred to a physical entity prior/during experiment. + +:ref:`NXimage` + Base class for reporting a set of images representing specializations of NXdata. + +:ref:`NXlog` + Information recorded as a function of time. + +:ref:`NXparameters` + Container for parameters, usually used in processing or analysis. + +:ref:`NXpdb` + A NeXus transliteration of a PDB file, to be validated only as a PDB. + +:ref:`NXpeak` + Base class for describing a peak, its functional form, and support values. + +:ref:`NXprocess` + The :ref:`NXprocess` class describes an operation of processing data. + +:ref:`NXprogram` + Base class to describe a software tool or library. + +:ref:`NXreflections` + Reflection data from diffraction experiments + +:ref:`NXregistration` + Describes image registration procedures. + +:ref:`NXresolution` + Describes the resolution of a physical quantity. + +:ref:`NXroi_process` + Base class to report on the characterization of an area or volume of material. + +:ref:`NXspectrum` + Base class container for reporting a set of spectra. + +:ref:`NXtransformations` + Collection of axis-based translations and rotations to describe a geometry. + diff --git a/manual/source/classes/base_classes/em-structure.rst b/manual/source/classes/base_classes/em-structure.rst new file mode 100644 index 0000000000..cac42dcbb8 --- /dev/null +++ b/manual/source/classes/base_classes/em-structure.rst @@ -0,0 +1,100 @@ +.. _BC-Em-Structure: + +=================== +Electron Microscopy +=================== + +.. index:: + BC-Em-Introduction + BC-Em-Classes + +.. _BC-Em-Introduction: + +Introduction +############ + +These are the base classes to describe components of an electron microscope and its focused-ion beam capabilities, +as well as the associated data analyses. These base classes are used within the EM-related :ref:`application definitions `, specifically in NXem. +Some of the base classes are specific to EM, whereas others are used in other techniques as well. + +.. _BC-Em-Classes: + +Base Classes +############ + +The design of NXem uses several existent base class and added concepts to existent base classes to make these +applicable for electron microscopy (:ref:`NXactuator`, :ref:`NXaperture`, :ref:`NXbeam`, :ref:`NXcite`, +:ref:`NXcollection`, :ref:`NXcomponent`, :ref:`NXcoordinate_system`, :ref:`NXdata`, :ref:`NXdeflector`, :ref:`NXdetector`, +:ref:`NXfabrication`, :ref:`NXmanipulator`, :ref:`NXmonochromator`, :ref:`NXnote`, :ref:`NXparameters`, :ref:`NXprocess`, +:ref:`NXsample`, :ref:`NXsensor`, :ref:`NXsource`, and :ref:`NXuser`). + +Many design decisions of the application definitions :ref:`NXem` and :ref:`NXapm` are aligned. Examples are the use of base +classes for instrument-specific events :ref:`NXem_event_data`, the grouping of measurements :ref:`NXem_measurement` and simulations +:ref:`NXem_simulation`, and the encapsulating of :ref:`NXparameters` and :ref:`NXdata` in :ref:`NXprocess` instances to describe +workflows of processing. The base classes :ref:`NXatom`, :ref:`NXunit_cell`, and :ref:`NXphase` were introduced to document sets +of atoms, the spatial arrangement of atoms, and offer concepts for documenting when regions-of-interest :ref:`NXroi_process` in a material represent +thermodynamic phases. + +In addition to these considerations, there exist base classes to define concepts that are specific for electron microscopy: + +:ref:`NXaberration`: + A base class to describe procedures and values for the calibration of aberrations. + +:ref:`NXcorrector_cs`: + A base class to describe a corrective lens or compound lens sets to reduce the aberration of an electron beam. + +:ref:`NXebeam_column`: + A base class to group the components relevant for generating and shaping an electron beam. + +:ref:`NXibeam_column`: + A base class to group the components relevant for generating and shaping an ion beam. + +:ref:`NXimage`: + A base class to store individual images or stacks of images. + +:ref:`NXem_instrument`: + A base class to document all components that make up an instrument (real or simulated) when using it for studying + electron matter interaction. This base class is used in NXem in two places: + Firstly, inside an ENTRY/measurement/instrument group. This group holds all those (meta)data which do not change + during a session, i.e. instrument name, typically identifier of hardware components or version of control software. + Secondly, inside ENTRY/measurement/eventID groups; these hold all those (meta)data data that change during a session. + +:ref:`NXroi_process` and specialization :ref:`NXem_interaction_volume`: + A base class to document the region-of-interest within an area or volume of material. + The region of material where the electron beam interacts with the sample is called the interaction volume. + +:ref:`NXelectromagnetic_lens`: + A base class to describe an electro-magnetic lens. In practice, an electron microscope has many such lenses. + It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope + and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of + software tools which strive to model the instrument e.g. to create digital twins of the instrument. + +:ref:`NXem_optical_system`: + A base class to store for now qualitative and quantitative values of frequent interest + which are affected by the interplay of the components and state of an electron microscope. + Examples are the semiconvergence angle, the magnification, or the camera length. + +:ref:`NXpump`: + A base class to describe details about a pump in an instrument. + +:ref:`NXscan_controller`: + A base class to represent a component that is used to deflect a beam of charged particles in a controlled manner. + This can be used to document the scan pattern. + +:ref:`NXspectrum`: + A base class to store individual spectra and stacks of spectra. + +Method-specific concepts and their usage in application definitions +################################################################### + +It became clear during the design of the electron-microscopy-specific additions to NeXus that many data and metadata which are relevant for +a given experiment have usually only few connections to the detailed description of the instrument. Instead, these are steps of +data analysis and data processing workflows. This motivated a granularization of these concepts into own method-specific base classes: + +:ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`: + These base classes provide concepts for specific data acquisition modes and associated analyses as are used in electron microscopy + such as for collecting and indexing Kikuchi diffraction patterns into orientation maps for two-dimensional, three-dimensional point + cloud data, reporting X-ray spectroscopy (EDS/EDXS), different imaging modes, or documenting electron energy loss spectroscopy (EELS). + A substantial further number of such base class could be designed that can build on the ideas and principles that are + suggested via these four base classes. + diff --git a/manual/source/classes/contributed_definitions/mpes-structure.rst b/manual/source/classes/base_classes/mpes-structure.rst similarity index 68% rename from manual/source/classes/contributed_definitions/mpes-structure.rst rename to manual/source/classes/base_classes/mpes-structure.rst index 35cda2d75c..ef9f891e06 100644 --- a/manual/source/classes/contributed_definitions/mpes-structure.rst +++ b/manual/source/classes/base_classes/mpes-structure.rst @@ -1,46 +1,35 @@ -.. _Mpes-Structure: +.. _BC-Mpes-Structure: ======================================= -Photoemission & core-level spectroscopy +Photoemission & Core-Level Spectroscopy ======================================= .. index:: - IntroductionMpes - MpesAppDef - MpesBC - MpesCommonBC - MpesExtendedBC + BC-Mpes-Introduction + BC-Mpes-Classes + BC-MpesCommonBC -.. _IntroductionMpes: +.. _Mpes-BC-Introduction: Introduction ############ -Set of data storage objects to describe photoemission experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), +These are a set of base classes to describe multidimensional photoemission (MPES) experiments including x-ray photoelectron spectroscopy (XPS), ultraviolet photoelectron spectroscopy (UPS), hard x-ray photoelectron spectroscopy (HAXPES), angle-resolved photoemission spectroscopy (ARPES), two-photon photoemission (2PPE) -and photoemission electron microscopy (PEEM). Also includes descriptors for advanced specializations, such as spin-resolution, time resolution, -near-ambient pressure conditions, dichroism etc. +and photoemission electron microscopy (PEEM). -.. _MpesAppDef: +Some of the base classes are specific to MPES (like :ref:`NXelectronanalyzer`), whereas others are used in other techniques as well. -Application Definitions -####################### +These base classes are used within the MPES-related :ref:`application definitions `. -:ref:`NXmpes`: - A general application definition with minimalistic metadata requirements, apt to describe all photemission experiments. - -:ref:`NXmpes_arpes`: - An application definition for angle-resolved photoemission spectroscopy (ARPES) experiments. - -:ref:`NXxps`: - An application definition for X-ray/UV photoelectron spectroscopy (XPS/UPS) experiments. - -.. _MpesBC: +.. _BC-Mpes-Classes: Base Classes ############ +Base classes describing instrument components used in photemission experiments: + :ref:`NXelectronanalyzer`: A base class to describe electron kinetic energy analyzers. Contains the collective characteristics of the instrument such as energy resolution, and includes the following classes: @@ -56,8 +45,7 @@ Base Classes :ref:`NXelectron_detector`: Specialization of :ref:`NXdetector` to describe electron detectors used in photoemission experiments. - -Four base classes (which are subclasses of :ref:`NXprocess`) to describe data (post-)processing: +Base classes (which are subclasses of :ref:`NXprocess`) to describe data (post-)processing: :ref:`NXcalibration`: Base class to describe the 1D calibration of an axis, with a function mapping a raw data scale to a calibrated scale with the same number of points. @@ -77,19 +65,24 @@ Four base classes (which are subclasses of :ref:`NXprocess`) to describe data (p :ref:`NXpeak`: Base class to describe a peak, its functional form, and support values (i.e., the discretization (points) at which the function has been evaluated). -.. _MpesCommonBC: + +.. _BC-MpesCommonBC: Common Base Classes ################### -There are three related base classes that are common to other techniques: +There are additional base classes that were introduced in the context of photoemission spectroscopy, +but that are commonly used in other techniques as well. - :ref:`NXmanipulator`: - A base class to describe the complex manipulators used in experiments, often with > 4 degrees of freedom, - cryogenic cooling, and other advanced features. + :ref:`NXdeflector` + A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. :ref:`NXelectromagnetic_lens`: A class to describe all types of lenses. Includes electrostatic lenses for electron energy analysers. - :ref:`NXdeflector` - A class to describe all kinds of deflectors, including electrostatic and magnetostatic deflectors for electron energy analysers. + :ref:`NXmanipulator`: + A base class to describe the complex manipulators used in experiments, often with > 4 degrees of freedom, + cryogenic cooling, and other advanced features. + + :ref:`NXresolution`: + Describes the resolution of a physical quantity, e.g. the resolution of the MPES spectrometer. diff --git a/manual/source/classes/base_classes/optical-spectroscopy-structure.rst b/manual/source/classes/base_classes/optical-spectroscopy-structure.rst new file mode 100644 index 0000000000..f858d3ee8a --- /dev/null +++ b/manual/source/classes/base_classes/optical-spectroscopy-structure.rst @@ -0,0 +1,46 @@ +.. _BC-Opt-Spec-Structure: + +==================== +Optical Spectroscopy +==================== + +.. index:: + BC-Opt-Spec-Introduction + Raman-BC + DispersiveMaterial-BC + +.. _BC-Opt-Spec-Introduction: + +Introduction +############ + +These are a set of base classes to describe optical spectroscopy, including :ref:`Ellipsometry ` +and :ref:`Raman spectroscopy ` + +These base classes are used within the :ref:`application definitions ` related to optical spectroscopy. + +.. _BC-Opt-Spec-Classes: + +Base Classes +------------ + +The application definitions for optical spectroscopy use several existent base class and add edits and additions of some concepts to +make these base classes applicable for the field of optical spectroscopy (:ref:`NXactuator`, :ref:`NXbeam`, :ref:`NXcalibration`, +:ref:`NXcomponent`, :ref:`NXcoordinate_system`, :ref:`NXdata`, :ref:`NXdetector`, :ref:`NXenvironment`, :ref:`NXfabrication`, +:ref:`NXhistory`, :ref:`NXinstrument`, :ref:`NXmanipulator`, :ref:`NXmonochromator`, :ref:`NXpid_controller`, :ref:`NXprocess`, +:ref:`NXprogram`, :ref:`NXresolution`, :ref:`NXsample`, :ref:`NXsensor`, :ref:`NXsource`, :ref:`NXtransformations`, and :ref:`NXuser`). + +In addition, there exist base classes to define concepts that are specific for optical spectroscopy: + +:ref:`NXbeam_transfer_matrix_table` + Used to relate physical properties of two beams (:ref:`NXbeam`) which + have one common optical component (:ref:`NXcomponent`) inbetween. + +:ref:`NXoptical_lens` + Description of an optical lens. + +:ref:`NXoptical_window` + Description of an optical window. + +:ref:`NXwaveplate` + Description of a waveplate or retarder. diff --git a/manual/source/classes/base_classes/sample-structure.rst b/manual/source/classes/base_classes/sample-structure.rst new file mode 100644 index 0000000000..7e12b31cd9 --- /dev/null +++ b/manual/source/classes/base_classes/sample-structure.rst @@ -0,0 +1,54 @@ +.. _BC-Sample-Structure: + +========================= +Working with Samples +========================= + +.. index:: + BC-Sample-Base-Classes + +Base Classes +############ + +:ref:`NXactivity` + A planned or unplanned action that has a temporal extension and for some time depends on some entity. + +:ref:`NXatom` + Base class for documenting a set of atoms. + +:ref:`NXchemical_composition` + Chemical composition of a sample or a set of things. + +:ref:`NXenvironment` + Parameters for controlling external conditions + +:ref:`NXfabrication` + Details about a component as it is defined by its manufacturer. + +:ref:`NXhistory` + A set of activities that occurred to a physical entity prior/during experiment. + +:ref:`NXmanipulator` + Base class to describe the use of manipulators and sample stages. + +:ref:`NXnote` + Any additional freeform information not covered by the other base classes. + +:ref:`NXphase` + Base class to describe a (thermodynamic) phase as a component of a material. + +:ref:`NXroi_process` + Base class to report on the characterization of an area or volume of material. + +:ref:`NXrotations` + Base class to detail a set of rotations, orientations, and disorientations. + +:ref:`NXsample` + Any information on the sample. + +:ref:`NXsample_component` + One group like this per component can be recorded for a sample consisting of multiple components. + +:ref:`NXunit_cell` + Base class to describe structural aspects of an arrangement of atoms. + diff --git a/manual/source/classes/base_classes/tech-structure.rst b/manual/source/classes/base_classes/tech-structure.rst new file mode 100644 index 0000000000..96c3cc0c4c --- /dev/null +++ b/manual/source/classes/base_classes/tech-structure.rst @@ -0,0 +1,186 @@ +.. _BC-Tech-Structure: + +========================= +Parts of instruments +========================= + +.. index:: + BC-Tech-Base-Classes + +Data schemas to describe parts, components, or sets of components for building an instrument. + +Base Classes +############ + +:ref:`NXactuator` + An actuator used to control an external condition. + +:ref:`NXaperture` + A beamline aperture. + +:ref:`NXattenuator` + A device that reduces the intensity of a beam by attenuation. + +:ref:`NXbeam_stop` + A device that blocks the beam completely, usually to protect a detector. + +:ref:`NXbending_magnet` + A bending magnet + +:ref:`NXcapillary` + A capillary lens to focus the X-ray beam. + +:ref:`NXcircuit` + Base class for documenting circuit devices. + +:ref:`NXcollectioncolumn` + Electron collection column of an electron analyzer. + +:ref:`NXcollimator` + A beamline collimator. + +:ref:`NXcomponent` + Base class for components of an instrument - real ones or simulated ones. + +:ref:`NXcorrector_cs` + Base class for a corrector reducing (spherical) aberrations of an electron optical setup. + +:ref:`NXcrystal` + A crystal monochromator or analyzer. + +:ref:`NXdeflector` + Component of an electron analyzer that deflects the paths of electrons. + This includes electrostatic and electromagnetic deflectors. + +:ref:`NXdetector` + A detector, detector bank, or multidetector. + +:ref:`NXdetector_channel` + Description and metadata for a single channel from a multi-channel detector. + +:ref:`NXdetector_group` + Logical grouping of detectors. When used, describes a group of detectors. + +:ref:`NXdetector_module` + Geometry and logical description of a detector module. When used, child group to NXdetector. + +:ref:`NXdisk_chopper` + A device blocking the beam in a temporal periodic pattern. + +:ref:`NXebeam_column` + Base class for a set of components providing a controllable electron beam. + +:ref:`NXelectromagnetic_lens` + Base class for an electro-magnetic lens or a compound lens. + +:ref:`NXelectron_detector` + A subclass of NXdetector for detectors that detect electrons. + +:ref:`NXelectronanalyzer` + Basic class for describing an electron analyzer. + +:ref:`NXem_instrument` + Base class for instrument-related details of a real or simulated electron microscope. + +:ref:`NXem_optical_system` + Base class for qualifying an electron optical system. + +:ref:`NXenergydispersion` + Energy dispersion section of an electron analyzer. + +:ref:`NXfabrication` + Details about a component as it is defined by its manufacturer. + +:ref:`NXfermi_chopper` + A Fermi chopper, possibly with curved slits. + +:ref:`NXfilter` + For band pass beam filters. + +:ref:`NXflipper` + A spin flipper. + +:ref:`NXfresnel_zone_plate` + A fresnel zone plate + +:ref:`NXgrating` + A diffraction grating, as could be used in a soft X-ray monochromator + +:ref:`NXguide` + A neutron optical element to direct the path of the beam. + +:ref:`NXibeam_column` + Base class for a set of components equipping an instrument with FIB capabilities. + +:ref:`NXinsertion_device` + An insertion device, as used in a synchrotron light source. + +:ref:`NXinstrument` + Collection of the components of the instrument or beamline. + +:ref:`NXmanipulator` + Base class to describe the use of manipulators and sample stages. + +:ref:`NXmirror` + A beamline mirror or supermirror. + +:ref:`NXmoderator` + A neutron moderator + +:ref:`NXmonitor` + A monitor of incident beam data. + +:ref:`NXmonochromator` + A wavelength defining device. + +:ref:`NXoptical_lens` + Description of an optical lens. + +:ref:`NXoptical_window` + A window of a cryostat, heater, vacuum chamber or a simple glass slide. + +:ref:`NXpdb` + A NeXus transliteration of a PDB file, to be validated only as a PDB + +:ref:`NXpid_controller` + A description of a feedback system in terms of the settings of a proportional-integral-derivative (PID) controller. + +:ref:`NXpinhole` + A simple pinhole. + +:ref:`NXpolarizer` + A spin polarizer. + +:ref:`NXpositioner` + A generic positioner such as a motor or piezo-electric transducer. + +:ref:`NXpump` + Device to reduce an atmosphere to a controlled pressure. + +:ref:`NXreflections` + Reflection data from diffraction experiments + +:ref:`NXscan_controller` + The scan box or scan controller is a component that is used to deflect a + +:ref:`NXsensor` + A sensor used to monitor an external condition + +:ref:`NXslit` + A simple slit. + +:ref:`NXsource` + Radiation source emitting a beam. + +:ref:`NXspindispersion` + Class to describe spin filters in photoemission experiments. + +:ref:`NXvelocity_selector` + A neutron velocity selector + +:ref:`NXwaveplate` + A waveplate or retarder. + +:ref:`NXxraylens` + An X-ray lens, typically at a synchrotron X-ray beam line. + diff --git a/manual/source/classes/contributed_definitions/apm-structure.rst b/manual/source/classes/contributed_definitions/apm-structure.rst index 5e3f79749e..6242152756 100644 --- a/manual/source/classes/contributed_definitions/apm-structure.rst +++ b/manual/source/classes/contributed_definitions/apm-structure.rst @@ -1,117 +1,89 @@ -.. _Apm-Structure: +.. _CC-Apm-Structure: ===================== -Atom-probe tomography +Atom Probe Microscopy ===================== .. index:: - IntroductionApm - ApmAppDef - ApmBC - StatusQuoApm - ApmParaprobeAppDef - ApmGermanNfdi + CC-Apm-Introduction + CC-Apm-Definitions + CC-Apm-Paraprobe-Introduction + CC-Apm-Paraprobe-Status-Quo + CC-Apm-Paraprobe-Application-Definitions + CC-Apm-Paraprobe-German-NFDI -.. _IntroductionApm: +.. _CC-Apm-Introduction: Introduction -############ - -Set of data schemas to describe the acquisition, i.e. measurement side, the extraction of hits from detector raw data, -steps to compute mass-to-charge state ratios from uncorrected time of flight data, the reconstruction, and the ranging, i.e. identification of peaks in the mass-to-charge-state ratio histogram to detect (molecular) ions. -The data schemas can be useful to generate data artifacts also for field-ion microscopy experiments. - -.. _ApmAppDef: +############## -Application Definition -###################### +For the use case atom probe tomography the community contributed not only the :ref:`NXapm` application definition. +It was also explored how using several instances of :ref:`NXprocess` is useful for documenting the many data +processing steps that are typical in atom probe research to investigate structural features of the material +demanding reconstructions, i.e., models of the crystal and defect network by analyzing the collective position +data of atoms. The following definitions are a summary of the status quo how NeXus can be used for documenting +these processing steps to improve numerical reproducibility and assist researchers with documenting procedural +aspects of their data analysis workflows. - :ref:`NXapm`: - A general application definition with many detailed places for leaving metadata and computational steps described which are commonly used when reporting the measurement of atom probe data including also detector hit data, as well as how to proceed with reconstructing atom positions from these data, and how to store details about definitions made, which describe how mass-to-charge-state ratio values are mapped to iontypes in a process called ranging. The structure of the schema has been designed to also document a simulation of an atom probe - experiment. Having a combined schema for the measurement and the simulation is beneficial to document that - there are many similarities between the measurement and a computer simulation of it. - -.. _ApmBC: +.. _CC-Apm-Definitions: Base Classes ############ -The following base classes are proposed to support modularizing the storage of pieces of information: - +The processing steps of ranging and reconstructing are documented as two specializations of :ref:`NXprocess`: - :ref:`NXcoordinate_system` and :ref:`NXtransformations`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another when interpreting the dataset. +:ref:`NXapm_ranging` + Metadata to ranging definitions made for a dataset in atom probe microscopy. - :ref:`NXatom`: - A base class to elements, ions, and clusters of atoms be these charged or not. +:ref:`NXapm_reconstruction` + Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about - a component or device of an instrument. +Spatial or other type of filters which are frequently used for atom probe to select specific atom positions +or portions of the data based on isotopic identity are modeled as base classes for filters, which are +defined atom-probe-agnostic empower reuse: - :ref:`NXpeak`: (about to become complemented by NXpeak_fitting) - A base class to describe peaks mathematically to detail how peaks in - mass-to-charge-state ratio histograms (aka mass spectra) are defined and - labelled as iontypes. +:ref:`NXdelocalization` + Base class to describe the delocalization of point-like objects on a grid. + +:ref:`NXisocontour` + Computational geometry description of isocontouring/phase-fields in Euclidean space. + +:ref:`NXmatch_filter` + Base class to filter ions based on their type or other descriptors like hit multiplicity. - :ref:`NXpump`: - A base class to describe details about pump(s) used as components of an instrument. +:ref:`NXspatial_filter` + Base class to filter based on position. This base class takes advantage of :ref:`NXcg_ellipsoid`, - :ref:`NXmanipulator`: - A base class to describe the specimen fixture including the cryo-head. - Nowadays, stages of microscopes represent small-scale laboratory platforms. - Therefore, there is a need to define the characteristics of such stages in more detail, - especially in light of in-situ experiments. Many similarities exists between a stage - in an electron microscope and one in an atom probe instrument. Both offer fixture - functionalities and additional components for applying e.g. stimuli on the specimen. +:ref:`NXcg_cylinder`, :ref:`NXcg_hexahedron` + Base classes to describe commonly used geometric primitives (not only) in atom probe. + The primitives are used for defining the shape and extent of a region of interest + (ROI) :ref:`NXroi_process` of material. -Microscopy experiments, not only taking into account those performed on commercial instruments, offer users to apply a set of -data processing steps. Some of them are frequently applied on-the-fly. For now we represent these steps with specifically named -instances of the :ref:`NXprocess` base class. +:ref:`NXsubsampling_filter` + Base class for a filter that can also be used for specifying how entries + like ions can be filtered via sub-sampling. -Several instances of NXprocess were defined in NXapm to document processing of atom probe data -including hit finding, voltage-and-bowl correction, combinatorial recovery of charge states, reconstruction, -and ranging definitions. These base classes are examples that substantiate that data processing steps are -essential when transforming atom probe measurements or simulations into knowledge. Consequently, these -steps should be documented to enable reproducible research, if possible even numerical reproducibility -of the results, and to learn better the workflow. In what follows, an example is presented how an -open-source community software can be modified to use descriptions of these computational steps. +.. _CC-Apm-Paraprobe-Introduction: -A detailed inspection of spatial and other type of filters frequently used in analysis of atom probe -data revealed that it is better to define atom-probe-agnostic reusable concepts for filters: +Tools and applications in APM +############################# - :ref:`NXspatial_filter`: - A base class proposing how a point cloud can be spatially filtered in a specific yet general manner. - This base class takes advantage of :ref:`NXcg_ellipsoid`, :ref:`NXcg_cylinder`, and :ref:`NXcg_hexahedron` - to cater for commonly used geometric primitives in atom probe. - The primitives are used for defining the shape and extent of a region of interest (ROI). +There exist several research software tools in the APM community that deal with handling and analyzing APM data. - :ref:`NXsubsampling_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered via sub-sampling. - - :ref:`NXmatch_filter`: - A base class for a filter that can also be used for specifying how entries - like ions can be filtered based on their type or other descriptors like hit multiplicity. - -The respective research software here is the `paraprobe-toolbox `_ +One of these is the `paraprobe-toolbox `_ The software is developed by `M. Kühbach et al. `_. -For atom probe research the proposal can also serve as a blue print how computational steps of other software -tool including commercial ones could be developed further to benefit from NeXus. - -.. _IntroductionApmParaprobe: - -apmtools -######## The paraprobe-toolbox is an example of an open-source parallelized software for analyzing point cloud data, for assessing meshes in 3D continuum space, and for studying the effects of parameterization on descriptors of micro- and nanoscale structural features (crystal defects) within materials when characterized and studied with atom probe. -The need for a thorough documentation of the tools in not only the paraprobe-toolbox -was motivated by several needs: +There is a set of contributed application definitions describing each computational step in the +paraprobe-toolbox. These were added to describe the whole workflow in this particular software, +but can also act as a blueprint for how computational steps of other software tools +(including commercial ones) could be developed further to benefit from NeXus. + +The need for a thorough documentation of the tools was motivated by several needs: First, users of software would like to better understand and also be able to study for themselves which individual parameters and settings for each tool exist and how configuring these @@ -125,36 +97,29 @@ provenance and workflow should be documented. Individual tools of paraprobe-toolbox are developed in C/C++ and/or Python. Provenance tracking is useful as it is one component and requirement for making -workflows exactly numerically reproducible and thus to enable reproducibility (the "R" -of the FAIR principles of data stewardship). +workflows exactly numerically reproducible and thus to enable reproducibility +(the "R" of the FAIR principles of data stewardship). For tools of the paraprobe-toolbox each workflow step is a pair or triple of sub-steps: 1. The creation of a configuration file. -2. The actual analysis using the Python/or C/C++ tools. +2. The actual analysis using a given Python/or C/C++ tool from the toolbox. 3. The optional analyses/visualization of the results based on data in NeXus/HDF5 files generated by each tool. -.. _StatusQuoApm: - -What has been achieved so far? -############################## - -This proposal summarizes work of members of the FAIRmat project, which is part of the `German -National Research Data Infrastructure `_. The here detailed -proposal documents how all tools of the paraprobe-toolbox were modified to generate -only well-defined configuration files as accepted input and yield specifically formatted output -files according to the following NeXus application definitions. - Data and metadata between the tools are exchanged with NeXus/HDF5 files. This means that data inside HDF5 binary containers are named, formatted, and hierarchically structured according -to application definitions. +to NeXus application definitions. -For example the application definition NXapm_paraprobe_config_surfacer specifies -how a configuration file for the paraprobe-surfacer tool should be formatted +In a refactoring project, within the FAIRmat project, which is part of the `German +National Research Data Infrastructure `_, the tools of the +paraprobe-toolbox were modified to read from and write data using NeXus application definitions. + +For example the application definition :ref:`NXapm_paraprobe_surfacer_config`: specifies +the expectation how a configuration file for the paraprobe-surfacer tool is formatted and which parameters it contains including optionality and cardinality constraints. -Thereby, each config file uses a controlled vocabulary of terms. Furthermore, -the config files store a SHA256 checksum for each input file. This implements a full -provenance tracking on the input files along the workflow. +Thereby, each config file uses a controlled vocabulary of terms. The config files store +SHA256 checksum for each input file, thereby implementing an uninterrupted +provenance tracking chain documenting the computational workflow. As an example, a user may first range their reconstruction and then compute spatial correlation functions. The config file for the ranging tool stores the files @@ -166,88 +131,76 @@ imported by the spatial statistics tool which again keeps track of all files and reports its results in a spatial statistics tool results file. This design makes it possible to rigorously trace which numerical results were achieved -with specific inputs and settings using specifically-versioned tools. Noteworthy +with specific inputs and settings using specifically-versioned tools. Noteworthy, this includes Y-junction on a graph which is where multiple input sources are combined to generate new results. -We are convinced that defining, documenting, using, and sharing application definitions -is useful and future-proof strategy for software development and data analyses as it enables -automated provenance tracking which happens silently in the background. - -Base classes have been defined to group common pieces of information for each tool of the -toolbox. For each tool we define a pair of base classes. One for the configuration (input) side -and one for the results (output) side: +Defining, documenting, using, and sharing application definitions is a useful and future-proof +strategy for software development and data analyses as it enables automated provenance +tracking working silently in the background. - :ref:`NXapm_paraprobe_tool_config`, :ref:`NXapm_paraprobe_tool_results`, :ref:`NXapm_paraprobe_tool_common`: - Configuration, results, and common parts respectively useful for the application definitions for tools of the paraprobe-toolbox. +In summary, the following application definitions were defined for the paraprobe-toolbox. +These are always pairs of application definitions --- one for the configuration (input) side +and one for the results (output) side. For each tool one such pair is proposed: -.. _ApmParaprobeAppDef: +.. _CC-Apm-Paraprobe-Application-Definitions: Application Definitions ####################### -NXapm_paraprobe application definitions are in fact pairs of application definitions. -One for the configuration (input) side and one for the results (output) side. For each -tool one such pair is proposed: +:ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results` + Configuration and results respectively of the paraprobe-ranger tool. + Apply ranging definitions and explore possible molecular ions. + Store applied ranging definitions and combinatorial analyses of possible iontypes. - :ref:`NXapm_paraprobe_transcoder_config`, :ref:`NXapm_paraprobe_transcoder_results`: - Configuration and the results respectively of the paraprobe-transcoder tool. - Load POS, ePOS, APSuite APT, RRNG, RNG, and NeXus NXapm files. - Store reconstructed positions, ions, and charge states. +:ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results` + Configuration and results respectively of the paraprobe-surfacer tool. + Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. + Store triangulated surface meshes of models for the edge of a dataset. - :ref:`NXapm_paraprobe_ranger_config`, :ref:`NXapm_paraprobe_ranger_results`: - Configuration and results respectively of the paraprobe-ranger tool. - Apply ranging definitions and explore possible molecular ions. - Store applied ranging definitions and combinatorial analyses of possible iontypes. +:ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results` + Configuration and results respectively of the paraprobe-distancer tool. + Compute and store analytical distances between ions to a set of triangles. - :ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results`: - Configuration and results respectively of the paraprobe-selector tool. - Defining complex spatial regions-of-interest to filter reconstructed datasets. - Store which points are inside or on the boundary of complex spatial regions-of-interest. +:ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results` + Configuration and results respectively of the paraprobe-tessellator tool. + Compute and store Voronoi cells and properties of these for all ions in a dataset. - :ref:`NXapm_paraprobe_surfacer_config`, :ref:`NXapm_paraprobe_surfacer_results`: - Configuration and results respectively of the paraprobe-surfacer tool. - Create a model for the edge of a point cloud via convex hulls, alpha shapes, or alpha-wrappings. - Store triangulated surface meshes of models for the edge of a dataset. +:ref:`NXapm_paraprobe_selector_config`, :ref:`NXapm_paraprobe_selector_results` + Configuration and results respectively of the paraprobe-selector tool. + Defining complex spatial regions-of-interest to filter reconstructed datasets. + Store which points are inside or on the boundary of complex spatial regions-of-interest. - :ref:`NXapm_paraprobe_distancer_config`, :ref:`NXapm_paraprobe_distancer_results`: - Configuration and results respectively of the paraprobe-distancer tool. - Compute and store analytical distances between ions to a set of triangles. +:ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results` + Configuration and results respectively of the paraprobe-spatstat tool. + Compute spatial statistics on the entire or selected regions of the reconstructed dataset. - :ref:`NXapm_paraprobe_tessellator_config`, :ref:`NXapm_paraprobe_tessellator_results`: - Configuration and results respectively of the paraprobe-tessellator tool. - Compute and store Voronoi cells and properties of these for all ions in a dataset. +:ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results` + Configuration and results respectively of the paraprobe-nanochem tool. + Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - :ref:`NXapm_paraprobe_spatstat_config`, :ref:`NXapm_paraprobe_spatstat_results`: - Configuration and results respectively of the paraprobe-spatstat tool. - Compute spatial statistics on the entire or selected regions of the reconstructed dataset. +:ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results` + Configuration and results respectively of the paraprobe-clusterer tool. + Compute cluster analyses with established machine learning algorithms using CPU or GPUs. - :ref:`NXapm_paraprobe_clusterer_config`, :ref:`NXapm_paraprobe_clusterer_results`: - Configuration and results resepctively of the paraprobe-clusterer tool. - Compute cluster analyses with established machine learning algorithms using CPU or GPUs. +:ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results` + Configuration and results resepctively of the paraprobe-intersector tool. + Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes + in continuum space to study the effect the parameterization of surface extraction algorithms on the + resulting shape, spatial arrangement, and colocation of 3D objects via graph-based techniques. - :ref:`NXapm_paraprobe_nanochem_config`, :ref:`NXapm_paraprobe_nanochem_results`: - Configuration and results resepctively of the paraprobe-nanochem tool. - Compute delocalization, iso-surfaces, analyze 3D objects, composition profiles, and mesh interfaces. - - :ref:`NXapm_paraprobe_intersector_config`, :ref:`NXapm_paraprobe_intersector_results`: - Configuration and results resepctively of the paraprobe-intersector tool. - Analyze volumetric intersections and proximity of 3D objects discretized as triangulated surface meshes - in continuum space to study the effect the parameterization of surface extraction algorithms on the resulting shape, - spatial arrangement, and colocation of 3D objects via graph-based techniques. - -.. _ApmGermanNfdi: +.. _CC-Apm-Paraprobe-German-NFDI: Joint work German NFDI consortia NFDI-MatWerk and FAIRmat ####################################################################### -Members of the NFDI-MatWerk and the FAIRmat consortium of the German National Research Data Infrastructure +Members of the FAIRmat and the NFDI-MatWerk consortia of the German National Research Data Infrastructure are working together within the Infrastructure Use Case IUC09 of the NFDI-MatWerk project to work on examples how software tools in both consortia become better documented and interoperable to use. Within this project, -we have also added the `CompositionSpace tool that has been developed at the Max-Planck-Institut für Eisenforschung -GmbH in Düsseldorf `_ by A. Saxena et al. +we have also added the `CompositionSpace tool `_ by A. Saxena et al. that has been developed at the +Max Planck Institute for Sustainable Materials in Düsseldorf + +:ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results` + Results of a run with Alaukik Saxena's composition space tool. + -Specifically, within the IUC09 we refactored the code base behind the publication `A. Saxena et al. `_ to better document its configuration, here as an example implemented like for the above-mentioned paraprobe-toolbox using NeXus: - - :ref:`NXapm_compositionspace_config`, :ref:`NXapm_compositionspace_results`: - Configuration and the results respectively of the CompositionSpace tool. diff --git a/manual/source/classes/contributed_definitions/cg-structure.rst b/manual/source/classes/contributed_definitions/cg-structure.rst new file mode 100644 index 0000000000..d5cfb99964 --- /dev/null +++ b/manual/source/classes/contributed_definitions/cg-structure.rst @@ -0,0 +1,29 @@ +.. _CC-Cgeometry-Structure: + +============================================= +Computational and Constructive Solid Geometry +============================================= + +.. index:: + CC-Cgeometry-Definitions + +.. _CC-Cgeometry-Definitions: + +Application Definitions +####################### + + +Base classes +############ + +:ref:`NXcsg` + Constructive Solid Geometry base class, using :ref:`NXquadric` and :ref:`NXoff_geometry` + +:ref:`NXquadric` + Definition of a quadric surface + +:ref:`NXsolid_geometry` + The head node for constructively defined geometry + + + diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst deleted file mode 100644 index 7db9a3d6a0..0000000000 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ /dev/null @@ -1,93 +0,0 @@ -.. _CgmsFeatures-Structure: - -========================= -Geometry & Microstructure -========================= - -.. index:: - CgmsBC - -.. _CgmsBC: - -Base Classes -############ - -The following base classes are defined to incentivize the use of NeXus for -using computational-geometry-based descriptions. In what follows, base classes -for frequently used shapes and geometric primitives are proposed: - - :ref:`NXcg_primitive`: - Base class from which most other NXcg classes that define specific primitives inherit. - - :ref:`NXcg_ellipsoid`: - A description for a set of possibly dissimilar oriented ellipsoids. - - :ref:`NXcg_cylinder`: - A description for a set of possibly dissimilar oriented cylinders. - - :ref:`NXcg_point`: - A collection of points with labels. - - :ref:`NXcg_polyline`: - A collection of lines and linear segments. - - :ref:`NXcg_triangle`: - A collection of triangles. - - :ref:`NXcg_parallelogram`: - A collection of possibly dissimilar parallelograms. - - :ref:`NXcg_polygon`: - A collection of polygons. - - :ref:`NXcg_tetrahedron`: - A collection of tetrahedra. - - :ref:`NXcg_hexahedron`: - A collection of hexahedra with capabilities to represent - also simpler (bounding) boxes for e.g. binary trees. - - :ref:`NXcg_polyhedron`: - A collection of polyhedra. - - :ref:`NXcg_roi`: - A container to host a number of different types of primitives. - -These base classes describe data structures used for more complex geometries: - - :ref:`NXcg_face_list_data_structure`: - In essence, the usual way how polygon/polyhedra data are reported: - A list of vertices and faces with identifier and properties. - - :ref:`NXcg_half_edge_data_structure`: - A half-edge data structure (also known as a doubly connected edge list) - is a useful complementary descriptor for polygon/polyhedra which enables - topological analyses and traversal of the graph of how polygons and - polyhedra are connected. - - :ref:`NXcg_unit_normal`: - As an additional structuring element especially for meshes, well-documented - normal information is crucial for distance computations. - - :ref:`NXcg_alpha_complex`: - Alpha shapes and alpha wrappings, specifically the special case of the - convex hull, are frequently used geometrical models for describing - a boundary or edge to a set of geometric primitives. - -Next, a few base classes are defined for documenting discretized representations -of material (area or volume) which can be useful not only for stencil-based methods: - - :ref:`NXcg_grid`: - A grid of cells. - - :ref:`NXisocontour`: - A description for isocontour descriptions. - - :ref:`NXdelocalization`: - An approach to document procedures whereby a scalar field - is smoothed in a controlled manner. - - :ref:`NXsimilarity_grouping`: - A description for clustering of objects (such as atoms or features). - -TODO CHECK THAT MICROSTRUCTURE PART IS COVERED IN ICME WHEN MICROSTRUCTURE PROPOSAL SYNCED UP diff --git a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png b/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png deleted file mode 100644 index 597cee834c..0000000000 Binary files a/manual/source/classes/contributed_definitions/container/ComplexContainerBeampath.png and /dev/null differ diff --git a/manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png b/manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png deleted file mode 100644 index 4ffdd862da..0000000000 Binary files a/manual/source/classes/contributed_definitions/container/ComplexExampleContainer.png and /dev/null differ diff --git a/manual/source/classes/contributed_definitions/danalysis-structure.rst b/manual/source/classes/contributed_definitions/danalysis-structure.rst new file mode 100644 index 0000000000..a7110ee91d --- /dev/null +++ b/manual/source/classes/contributed_definitions/danalysis-structure.rst @@ -0,0 +1,29 @@ +.. _CC-Danalysis-Structure: + +============= +Data Analysis +============= + +.. index:: + CC-Danalysis-Definitions + +.. _CC-Danalysis-Definitions: + +Application Definitions +####################### + + +Base classes +############ + +:ref:`NXregion` + Geometry and logical description of a region of data in a parent group. + When used, it could be a child group to, say, :ref:`NXdetector`. + +:ref:`NXsimilarity_grouping` + Metadata to the results of a similarity grouping analysis. + + + + + diff --git a/manual/source/classes/contributed_definitions/em-structure.rst b/manual/source/classes/contributed_definitions/em-structure.rst deleted file mode 100644 index 7c7ea7b544..0000000000 --- a/manual/source/classes/contributed_definitions/em-structure.rst +++ /dev/null @@ -1,162 +0,0 @@ -.. _Em-Structure: - -=================== -Electron microscopy -=================== - -.. index:: - IntroductionEm - EmAppDef - EmBC - EmAnalysisClasses - EmExamples - -.. _IntroductionEm: - -Introduction -############ - -A set of data schemas is proposed to describe components of an electron microscope and its eventually available focused-ion beam functionalities. -The data schemas were designed from the perspective of how electron microscopes are used by colleagues in the materials-science-branch of electron microscopy. -We realize that the biology-/bio-materials/omics-branch of electron microscopy is eventually in an already more mature state of discussion with respect -to data management practices. In what follows, the focus is on the usage of electron microscopy in condensed-matter physics, chemical physics of solids, -and materials engineering applications. As many of the components of electron microscopes used in the bio-materials communities are the same or at least many -components are very similar, it is likely that the here presented schema definitions can also inspire discussion and exchange with the bio-materials community. -Partner consortia in the German National Research Data Infrastructure are here e.g. NFDI-BioImage, NFDI-Microbiota, NFDI4Health, and e.g. NFDI-Neuro. - -Electron microscopes are functionally very customizable tools: Examples include multi-signal/-modal analyses which are frequently realized as on-the-fly computational analyses, regularly switching between GUI-based instrument control, computational steps, and more and more using high-throughput stream-based processing. Also artificial intelligence methods are increasingly used and are becoming more closely interconnected with classical modes of controlling the instrument and perform data processing. A challenge in electron microscopy is that these steps are often executed within commercial integrated control and analysis software. This makes it difficult to keep track of workflows in a technology-partner-agnostic, i.e. interdisciplinary manner. - -.. _EmAppDef: - -Application Definition NXem -########################### - -We acknowledge that it can be difficult to agree on a single application definition which is generally enough applicable yet not unnecessarily complex and useful for applications across a variety of instruments, technology partners, and instrument use cases. In what follows, the proposal conceptualizes first the basic components of an electron microscope and the usual workflow of how an electron microscope is used for collecting data with detectors via probing radiation-specimen-matter interaction mechanisms. - -In summary, scientists place a specimen/sample into the microscope, calibrate the instrument, take measurements, and may perform experiments, prepare their specimens with a focused ion beam, calibrate again, and take other measurements, before their session on the instrument ends. In between virtually all of these steps data are collected and stream in from different detectors probing different physical mechanisms of the interaction between electrons or other types of radiation with the specimen. - -A microscope session ends with the scientist removing the specimen from the instrument or parking it so that the next user can start a session. Occasionally, service technicians perform calibrations and maintenance which also can be described as a session on the microscope. We have provided base classes to describe these steps and events and an application definition for electron microscopy: - - :ref:`NXem`: - An application definition which explores the possibilities of research on electron-beam matter interaction with (real or simulated) electron microscopes. - - -.. _EmBC: - -Base Classes -############ - -The following base classes are proposed to support modularizing the storage of pieces of information related to electron microscopy research: - - :ref:`NXcomponent`: - A base class to describe components aka devices to building an instrument like a microscope irrespective whether that is a real one or a simulated one. - - :ref:`NXfabrication`: - A base class to bundle manufacturer/technology-partner-specific details about a component or device of an instrument. - - :ref:`NXcircuit`: - A base class to describe a logical unit of at least one integrated circuit. - - :ref:`NXebeam_column`: - A base class serving the possibility to group the components relevant for generating - and shaping the electron beam. - - :ref:`NXibeam_column`: - A base class serving the possibility to group the components relevant for generating - and shaping an ion beam of an instrument to offer focused-ion beam (milling) capabilities. - - :ref:`NXelectromagnetic_lens`: - A base class to detail an electro-magnetic lens. In practice, an electron microscope has many such lenses. It is possible to specify as many lenses as necessary to represent eventually each single lens of the microscope and thus describe how the lenses are affecting the electron beam. This can offer opportunities for developers of software tools which strive to model the instrument e.g. to create digital twins of the instrument. We understand there is still a way to go with this to arrive there though. Consequently, we suggest to focus first on which details should be collected for a lens as a component so that developers of application definitions can take immediate advantage of this work. - - :ref:`NXdeflector`: - A base class to describe a component to deflect a beam of charged particles. - - :ref:`NXpump`: - A base class to describe details about pump(s) as components of an electron microscope. - - :ref:`NXcorrector_cs`, :ref:`NXaberration`: - Base classes to describe procedures and values for the calibration of aberrations based on - conventions of different companies active in the field of aberration correction including a base class - to describe details about corrective lens or compound lens devices which reduce - (spherical) aberrations of an electron beam. - - :ref:`NXscan_controller`: - A base class to represent the component of an electron microscope which realizes a controlled deflection - (and eventually shift, blanking, and/or descanning) of the electron beam to illuminate the specimen in a controlled manner - This base class can be used to document the scan pattern. The base class focuses mostly on the concept idea that there - is a component in a microscope which controls eventually multiple other components such as beam deflectors to achieve deflection - and thus a controlled scanning of the beam over the sample/specimen surface. - - :ref:`NXmanipulator`: - A base class to describe the stage/specimen holder which offers place for the documentation of the small-scale laboratory functionalities - which modern stages of electron microscopes typically offer. - - :ref:`NXem_instrument`: - A base class to group the components that make up an electron microscope. - -Contextualizing and defining definitions of reference frames and transformations of these and rotations and orientations defined within such reference frames: - - :ref:`NXcoordinate_system`, :ref:`NXtransformations`: - Base classes to describe different coordinate systems used and/or to be harmonized - or transformed into one another and respective transformations. - - :ref:`NXem_event_data`: - A base class representing a container to hold time-stamped and microscope-state-annotated - data during a session at an electron microscope. - - :ref:`NXimage`: - Base classes for storing acquisition details for individual images or stacks of images. - - :ref:`NXspectrum`: - A base class and specializations comparable to :ref:`NXimage` but for storing spectra. - - :ref:`NXatom`: - A base class to elements, ions, and clusters of atoms be these charged or not. - - :ref:`NXem_optical_system`: - A base class to store for now qualitative and quantitative values of frequent interest - which are affected by the interplay of the components and state of an electron microscope. - Examples are the semiconvergence angle or the depth of field and depth of focus, the magnification, or the camera length. - - :ref:`NXpeak`: - A base class to describe peaks mathematically. - - -.. _EmAnalysisClasses: - -Storage of event-base data and results of post-processing -######################################################### - -We provide specific base classes which granularize frequently collected or analyzed quantities in specific application fields of electron microscopy to deal -with the situation that there are cases were logical connections between generated data artifacts mainly exist for the fact that the data artifacts were -collected during a workflow of electron microscopy research (e.g. taking measurements and then performing method-specific analyses generating new data and conclusions). -We see a value in granularizing out these pieces of information into own classes. In fact, one limitation of application definitions in NeXus, exactly as it applies for serialization -of information also more generally, is currently that they define a set of constraints on their graph of controlled concepts and terms. - -If we take for example diffraction experiments performed with an electron microscope, it is usually the case that (diffraction) patterns are collected in the session at the microscope. -However, all scientifically relevant conclusions are typically drawn later, i.e. through post-processing the collected diffraction (raw) data. These numerical and algorithmic steps -define computational workflows were data from an instance of an application definition such as NXem are used as input but many additional concepts, constraints, and assumptions -are applied without that these demand necessarily changes in the constraints on fields or groups of NXem. If we were to modify NXem for these cases, -NXem would combinatorially diverge as every different combination of required constraints demands having an own but almost similar application definition. -For this reason, method-specific base classes are used which granularize out how specific pieces of information are processed further to eventually enable their -storage (i.e. serialization) using NeXus. - -More consolidation through the use of NXsubentry classes should be considered in the future. For now we use an approach whereby base classes are combined to reuse vocabulary and a hierarchical organization of pieces of information with specific constraints which are relevant only for specific usage of such data by specific tools used by an eventually smaller circle of users. - - :ref:`NXem_ebsd`, :ref:`NXem_eds`, :ref:`NXem_eels`, :ref:`NXem_img`: - Base classes with method-specific details especially when it comes to reporting post-processed data within electron microscopy. - - :ref:`NXphase`, :ref:`NXunit_cell`, :ref:`NXatom`: - Base classes to store crystal structure specific details e.g. to support simulation of and post-processing of diffraction patterns. - - :ref:`NXcg_roi`: - A base class to granularize information collected and relevant for the characterization of a region-of-interest. - - -.. _EMExamples: - -Domain-specific data analysis -############################# - - :ref:`NXem_calorimetry`: - Example together with the IKZ in Berlin and FAIRmat, in-situ (transmission) electron microscopy with a heating stage. diff --git a/manual/source/classes/contributed_definitions/icme-structure.rst b/manual/source/classes/contributed_definitions/icme-structure.rst deleted file mode 100644 index cef6c662eb..0000000000 --- a/manual/source/classes/contributed_definitions/icme-structure.rst +++ /dev/null @@ -1,38 +0,0 @@ -.. _Icme-Structure: - -============================================== -Integrated Computational Materials Engineering -============================================== - -.. index:: - IcmeMsModels - -.. _IcmeMsModels: - -Application definitions for ICME models -####################################### - -It is important to embrace the large research community of materials engineers -as they are frequent users of electron microscopy and atom probe microscopy. -Integrated Computational Materials Engineering (ICME) is a design strategy and -workflow whereby physics-based modeling of microstructure evolution is used to -understand the relations between the microstructure and its technologically relevant -descriptors to understand and tailor properties of materials. - -The following application definitions are proposed to support the discussion on how -materials-engineering-specific data schemas can connect to or be mapped on -concepts which are equally modellable with NeXus: - - :ref:`NXmicrostructure`: - A base class for documenting a snapshot of a reconstructed microstructure. - - :ref:`NXmicrostructure_kanapy_results`: - A specific example of an application definition for documenting the results - of a computer simulation with the kanapy microstructure synthesizer - developed at the ICAMS in Bochum. - - :ref:`NXmicrostructure_score_config`, :ref:`NXmicrostructure_score_results`: - A specific example of an application definition for documenting the - configuration and results respectively of a computer simulation with - the static recrystallization cellular automata model SCORE. - diff --git a/manual/source/classes/contributed_definitions/micro-structure.rst b/manual/source/classes/contributed_definitions/micro-structure.rst new file mode 100644 index 0000000000..6a160dfd02 --- /dev/null +++ b/manual/source/classes/contributed_definitions/micro-structure.rst @@ -0,0 +1,58 @@ +.. _CC-Micro-Structure: + +=================================================== +Microstructure Characterization and Representation +=================================================== + +.. index:: + CC-Micro-Introduction + CC-Micro-Definitions + +.. _CC-Micro-Introduction: + +Introduction +############## + +The internal structure of a material modeled as crystals and the defect network that connect these. + +.. _CC-Micro-Definitions: + +Application Definitions +####################### + +Base classes +############ + +:ref:`NXmicrostructure` + Base class to describe elements of the microstructure of a material. + +:ref:`NXmicrostructure_pf`, :ref:`NXmicrostructure_ipf`, :ref:`NXmicrostructure_odf` + Base classes for describing parameterization, results, and data from texture analysis, + specifically pole figure (pf), inverse pole figure (ipf), + and orientation distribution function (odf), respectively. + +:ref:`NXmicrostructure_feature` + Set of topological/spatial features in materials built from atoms, from coarse-grained + representations of atoms, or from other microstructure features. + +:ref:`NXmicrostructure_slip_system` + Base class for describing a set of crystallographic slip systems. + +:ref:`NXmicrostructure_mtex_config` + Base class for documenting the parameterization of MTex, which is + a software for analyzing material texture written in MATLAB. + +:ref:`NXmicrostructure_score_config` + Application definition to control a simulation with the SCORE cellular automata simulation tool. + +:ref:`NXmicrostructure_score_results` + Application definition for storing results of the SCORE cellular automata simulation tool. + +:ref:`NXmicrostructure_kanapy_results` + Application definition for storing results of the kanapy microstructure synthesis tool. + + + + + + diff --git a/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst b/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst index 804cb9d33c..228e726360 100644 --- a/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst +++ b/manual/source/classes/contributed_definitions/optical-spectroscopy-structure.rst @@ -1,85 +1,51 @@ -.. _Optical-Spectroscopy-Structure: +.. _CC-Opt-Spec-Structure: ==================== Optical Spectroscopy ==================== .. index:: - Ellipsometry - Raman - DispersiveMaterial + CC-Opt-Spec-Introduction + CC-Opt-Spec-Definitions + CC-Opt-Spec-DispersiveMaterial -.. _Ellipsometry: +.. _CC-Opt-Spec-Introduction: -Ellipsometry -############ - -Ellipsometry is an optical characterization method to describe optical properties of interfaces and thickness of films. -The measurements are based on determining how the polarization state of light changes upon transmission and reflection. -Interpretation is based on Fresnel equations and numerical models of the optical properties of the materials. - -In the application definition we provide a minimum set of description elements allowing for a reproducible recording of ellipsometry measurements. - -.. _Raman: - -Raman -############ - -Raman spectroscopy is a characterization method to analyze vibrational properties for liquids, gases or solids. -The measurements is based on the inelastic light scattering due to the materials vibrations. -Interpretation can be done based on peaks, which represent the phonon properties (intensity, center, width). - -The application provides a minimum set of description elements, which are necessary to understand for Raman spectroscopy measurements. +Introduction +############## +:ref:`Application definitions ` and :ref:`base classes ` +to describe optical spectroscopy experiments are already part of the NeXus standard. +In addition, there are several contributed definitions that are currently under discussion. +.. _CC-Opt-Spec-Definitions: Application Definitions ------------------------ - - :ref:`NXoptical_spectroscopy`: - A generic application definition for optial spectorscopy measurements. This including specifically ellipsometry and Raman spectroscopy measurements, but as well other techniques such as photoluminescence, transmission, reflection measurements. The requirements are: (i) an incident photon beam, (ii) a detector to measure scattered/emitted photons and (iii) a sample. +####################### - :ref:`NXellipsometry`: - An application definition for ellipsometry measurements, including complex systems up to variable angle spectroscopic ellipsometry. - - :ref:`NXraman`: - An application definition for Raman spectroscopy measurements. +:ref:`NXtransmission` + Application definition for transmission experiments Base Classes ------------- - -This is the set of base classes for describing an optical experiment. - - :ref:`NXbeam` - Beam properties such as intensity, polarization, wavelength or direction. - - :ref:`NXdetector` - A detector for signal detection. - - :ref:`NXsource` - A light source such as laser, lamp or LED. - - :ref:`NXmonochromator` - A monochromator is often used to energetically disperse the scattered or emitted light. - - :ref:`NXoptical_lens` - Description of an optical lens. - - :ref:`NXoptical_window` - Description of an optical window. - - :ref:`NXwaveplate` - A waveplate or retarder. +############ - :ref:`NXsensor` - Specify external parameters that have influenced the sample such as - varied parameters e.g. temperature, pressure, pH value, beam intensity, etc. +These are new base classes to describe additional, yet to be standardized components of optical spectroscopy experiments. + +:ref:`NXbeam_splitter` + A beam splitter, i.e., a device splitting the light into two or more beams. + Use two or more NXbeam_paths to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. +:ref:`NXoptical_fiber` + An optical fiber, e.g. glass fiber. +:ref:`NXoptical_polarizer` + An optical polarizer. -.. _DispersiveMaterial: +.. _CC-Opt-Spec-DispersiveMaterial: Dispersive Material ################### @@ -91,11 +57,10 @@ This description may be used to store optical model data from an ellipsometric a Application Definition ---------------------- - :ref:`NXdispersive_material`: - An application definition to describe the dispersive properties of a material. - The material may be isotropic, uniaxial or biaxial. Hence, it may contain up - to three dispersive functions or tables. - +:ref:`NXdispersive_material` + An application definition to describe the dispersive properties of a material. + The material may be isotropic, uniaxial, or biaxial. Hence, it may contain up + to three dispersive functions or tables. Base Classes @@ -103,28 +68,28 @@ Base Classes There is a set of base classes for describing a dispersion. - :ref:`NXdispersion` - This is an umbrella base class for a group of dispersion functions to describe the material. - For a simple dispersion it may contain only on NXdispersion_function or NXdispersion_table entry. - If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. - This allows for, e.g. splitting real and imaginary parts and describing them seperately or - adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). - - :ref:`NXdispersion_function` - This dispersion is described by a function and its single and repeated parameter values. - It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` - (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. - - :ref:`NXdispersion_single_parameter` - This denotes a parameter which is used outside the summed part of a dispersion function, - e.g. ``eps_inf`` in the formula example above. - - :ref:`NXdispersion_repeated_parameter` - This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. - ``A`` and ``B`` are repeated parameters in the formula above. - - :ref:`NXdispersion_table` - This describes a tabular dispersion where the permittivity is an array versus wavelength or energy. +:ref:`NXdispersion` + This is an umbrella base class for a group of dispersion functions to describe the material. + For a simple dispersion it may contain only one NXdispersion_function or NXdispersion_table entry. + If it contains multiple entries the actual dispersion is the sum of all dispersion functions and tables. + This allows for, e.g. splitting real and imaginary parts and describing them separately or + adding a dielectric background (e.g. Sellmeier model) to an oscillator model (e.g. Lorentz). + +:ref:`NXdispersion_function` + This dispersion is described by a function and its single and repeated parameter values. + It follows a formula of the form ``eps = eps_inf + sum[A * lambda ** 2 / (lambda ** 2 - B ** 2)]`` + (Sellmeier formula). See the formula grammar below for an ebnf grammar for this form. + +:ref:`NXdispersion_single_parameter` + This denotes a parameter which is used outside the summed part of a dispersion function, + e.g. ``eps_inf`` in the formula example above. + +:ref:`NXdispersion_repeated_parameter` + This denotes arrays of repeated parameters which are used to build a sum of parameter values, e.g. + ``A`` and ``B`` are repeated parameters in the formula above. + +:ref:`NXdispersion_table` + This describes a tabular dispersion where the permittivity is an array versus wavelength or energy. Formula Grammar --------------- diff --git a/manual/source/classes/contributed_definitions/sample-structure.rst b/manual/source/classes/contributed_definitions/sample-structure.rst new file mode 100644 index 0000000000..955cf17a0d --- /dev/null +++ b/manual/source/classes/contributed_definitions/sample-structure.rst @@ -0,0 +1,24 @@ +.. _CC-Sample-Structure: + +==================== +Working with Samples +==================== + +.. index:: + CC-Sample-Definitions + +.. _CC-Sample-Definitions: + +Application Definitions +####################### + + +Base classes +############ + +:ref:`NXcontainer` + State of a container holding the sample under investigation. + +:ref:`NXsubstance` + A form of matter with a constant, definite chemical composition. + diff --git a/manual/source/classes/contributed_definitions/spm-structure.rst b/manual/source/classes/contributed_definitions/spm-structure.rst index 7cc84df86c..2518e33948 100644 --- a/manual/source/classes/contributed_definitions/spm-structure.rst +++ b/manual/source/classes/contributed_definitions/spm-structure.rst @@ -1,13 +1,14 @@ -.. _Spm-Structure: +.. _CC-Spm-Structure: =============================== Scanning Probe Microscopy =============================== .. index:: - SpmAppDef + CC-SpmAppDef + CC-SpmNewBC -.. _SpmAppDef: +.. _CC-SpmAppDef: Scanning probe microscopy (SPM) is a branch of microscopes that forms images of surfaces using a physical probe that scans the specimen. Using proper instrument setup, SPM can be used to measure various properties of the material surface, such as its topography, magnetic and @@ -61,7 +62,7 @@ Application Definition An application definition for Atomic Force Microscopy experiments inherited from the :ref:`NXspm`. -.. _SpmNewBC: +.. _CC-SpmNewBC: Base Classes ############ diff --git a/manual/source/classes/contributed_definitions/transport-structure.rst b/manual/source/classes/contributed_definitions/transport-structure.rst index d9558cdfff..29cfa1e895 100644 --- a/manual/source/classes/contributed_definitions/transport-structure.rst +++ b/manual/source/classes/contributed_definitions/transport-structure.rst @@ -1,32 +1,35 @@ -.. _Transport-Structure: +.. _CC-Transport-Structure: =================== Transport Phenomena =================== .. index:: - IntroductionTransport - TransportAppDef + CC-Transport-Introduction + CC-Transport-Definitions -.. _IntroductionTransport: +.. _CC-Transport-Introduction: Introduction -############ - - -.. _TransportAppDef: - -Application Definitions -####################### +############## Many experiments in condensed-matter physics and materials engineering belong to the category of measurements of transparent phenomena. A possible example of such experiments are temperature-dependent current-voltage (IV) curve measurements (or JV for engineers) measurements. In this case, electrical charge is transported and the temperature-dependent current response as a function of applied voltage is recorded. + +.. _CC-Transport-Definitions: + +Application Definitions +####################### + Below is an example for such an application definition for an experiment. This application definition has exemplar parts which show how such an experiment can be controlled with the `EPICS system `_: - :ref:`NXiv_temp`: - Application definition for temperature-dependent current-voltage (IV) curve measurements. +:ref:`NXsensor_scan` + Application definition for a generic scan using sensors. + +:ref:`NXiv_temp` + Application definition for temperature-dependent current-voltage (IV) curve measurements. diff --git a/manual/source/conf.py b/manual/source/conf.py index 70775bdd1a..d634f8803e 100644 --- a/manual/source/conf.py +++ b/manual/source/conf.py @@ -48,6 +48,7 @@ "sphinx.ext.viewcode", "sphinx.ext.githubpages", "sphinx.ext.todo", + "sphinx.ext.imgconverter", "sphinx_tabs.tabs", "contrib_ext", "chios.bolditalic", diff --git a/manual/source/em-structure.rst b/manual/source/em-structure.rst index 148e513aa2..4ecb51a8ec 100644 --- a/manual/source/em-structure.rst +++ b/manual/source/em-structure.rst @@ -6,4 +6,4 @@ Electron microscopy Electron microscopy is a cross-cutting characterization technique of key demand and relevance within materials science, materials engineering, and bio-science/omics research communities. -A status report of the ongoing work on data schemas for electron microscopy using NeXus is available here: :ref:`Em-Structure`. +A status report of the ongoing work on data schemas for electron microscopy using NeXus is available here: :ref:`AppDef-Em-Structure`. diff --git a/manual/source/icme-structure.rst b/manual/source/icme-structure.rst deleted file mode 100644 index 8ff31eaf78..0000000000 --- a/manual/source/icme-structure.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. _Icme-Structure-Fairmat: - -============================================== -Integrated Computational Materials Engineering -============================================== - -With a large set of data schemas for computational geometry, and methods from condensed-matter physics as well as materials engineering we are convinced that the NeXus standardization framework can be one component of efforts to harmonize and consolidate the zoo of descriptions and data schemas used within the field of Integrated Computational Materials Engineering (ICME). - -A status report along these lines of thoughts and ongoing efforts is available here: :ref:`Icme-Structure`. diff --git a/manual/source/index.rst b/manual/source/index.rst index 6911553a19..aeb4653d77 100644 --- a/manual/source/index.rst +++ b/manual/source/index.rst @@ -20,7 +20,6 @@ https://www.nexusformat.org/ spm-structure cgms-structure north-structure - icme-structure napi history diff --git a/manual/source/north-structure.rst b/manual/source/north-structure.rst index 26526638d2..f6e8bfe351 100644 --- a/manual/source/north-structure.rst +++ b/manual/source/north-structure.rst @@ -23,4 +23,4 @@ apmtools container One containerized application in NORTH and its apmtools container, is the paraprobe-toolbox. This software is developed by `M. Kühbach et al. `_. The software provides an implementation which exemplifies how NeXus/HDF5 and community tools for atom probe can be used to document provenance and steps of post-processing -for many steps relevant within the field of atom probe tomography and related field-ion microscopy: Inspect :ref:`Apm-Structure` for a status report and details. +for many steps relevant within the field of atom probe tomography and related field-ion microscopy: Inspect :ref:`CC-Apm-Structure` for a status report and details. diff --git a/manual/source/spm-structure.rst b/manual/source/spm-structure.rst index 0a830da698..a07806cb2a 100644 --- a/manual/source/spm-structure.rst +++ b/manual/source/spm-structure.rst @@ -12,4 +12,4 @@ Microscopy) in SPM domain. This is one community under the large umbrella of scanning (probe) microscopy methods. A status report of these efforts will be reported here: -:ref:`Spm-Structure`. +:ref:`CC-Spm-Structure`.