diff --git a/contributed_definitions/NXapm.nxdl.xml b/applications/NXapm.nxdl.xml similarity index 100% rename from contributed_definitions/NXapm.nxdl.xml rename to applications/NXapm.nxdl.xml diff --git a/contributed_definitions/NXem.nxdl.xml b/applications/NXem.nxdl.xml similarity index 100% rename from contributed_definitions/NXem.nxdl.xml rename to applications/NXem.nxdl.xml diff --git a/contributed_definitions/NXaberration.nxdl.xml b/base_classes/NXaberration.nxdl.xml similarity index 100% rename from contributed_definitions/NXaberration.nxdl.xml rename to base_classes/NXaberration.nxdl.xml diff --git a/contributed_definitions/NXchamber.nxdl.xml b/base_classes/NXchamber.nxdl.xml similarity index 100% rename from contributed_definitions/NXchamber.nxdl.xml rename to base_classes/NXchamber.nxdl.xml diff --git a/contributed_definitions/NXcollectioncolumn.nxdl.xml b/base_classes/NXcollectioncolumn.nxdl.xml similarity index 100% rename from contributed_definitions/NXcollectioncolumn.nxdl.xml rename to base_classes/NXcollectioncolumn.nxdl.xml diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/base_classes/NXcoordinate_system_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXcoordinate_system_set.nxdl.xml rename to base_classes/NXcoordinate_system_set.nxdl.xml diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/base_classes/NXcorrector_cs.nxdl.xml similarity index 100% rename from contributed_definitions/NXcorrector_cs.nxdl.xml rename to base_classes/NXcorrector_cs.nxdl.xml diff --git a/contributed_definitions/NXcs_computer.nxdl.xml b/base_classes/NXcs_computer.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_computer.nxdl.xml rename to base_classes/NXcs_computer.nxdl.xml diff --git a/contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml b/base_classes/NXcs_filter_boolean_mask.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_filter_boolean_mask.nxdl.xml rename to base_classes/NXcs_filter_boolean_mask.nxdl.xml diff --git a/contributed_definitions/NXcs_prng.nxdl.xml b/base_classes/NXcs_prng.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_prng.nxdl.xml rename to base_classes/NXcs_prng.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling.nxdl.xml b/base_classes/NXcs_profiling.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling.nxdl.xml rename to base_classes/NXcs_profiling.nxdl.xml diff --git a/contributed_definitions/NXcs_profiling_event.nxdl.xml b/base_classes/NXcs_profiling_event.nxdl.xml similarity index 100% rename from contributed_definitions/NXcs_profiling_event.nxdl.xml rename to base_classes/NXcs_profiling_event.nxdl.xml diff --git a/contributed_definitions/NXdeflector.nxdl.xml b/base_classes/NXdeflector.nxdl.xml similarity index 100% rename from contributed_definitions/NXdeflector.nxdl.xml rename to base_classes/NXdeflector.nxdl.xml diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/base_classes/NXebeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXebeam_column.nxdl.xml rename to base_classes/NXebeam_column.nxdl.xml diff --git a/contributed_definitions/NXem_ebsd.nxdl.xml b/base_classes/NXem_ebsd.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_ebsd.nxdl.xml rename to base_classes/NXem_ebsd.nxdl.xml diff --git a/contributed_definitions/NXem_img.nxdl.xml b/base_classes/NXem_img.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_img.nxdl.xml rename to base_classes/NXem_img.nxdl.xml diff --git a/contributed_definitions/NXem_method.nxdl.xml b/base_classes/NXem_method.nxdl.xml similarity index 100% rename from contributed_definitions/NXem_method.nxdl.xml rename to base_classes/NXem_method.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/base_classes/NXevent_data_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em.nxdl.xml rename to base_classes/NXevent_data_em.nxdl.xml diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/base_classes/NXevent_data_em_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXevent_data_em_set.nxdl.xml rename to base_classes/NXevent_data_em_set.nxdl.xml diff --git a/contributed_definitions/NXfabrication.nxdl.xml b/base_classes/NXfabrication.nxdl.xml similarity index 100% rename from contributed_definitions/NXfabrication.nxdl.xml rename to base_classes/NXfabrication.nxdl.xml diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/base_classes/NXibeam_column.nxdl.xml similarity index 100% rename from contributed_definitions/NXibeam_column.nxdl.xml rename to base_classes/NXibeam_column.nxdl.xml diff --git a/contributed_definitions/NXimage_set.nxdl.xml b/base_classes/NXimage_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXimage_set.nxdl.xml rename to base_classes/NXimage_set.nxdl.xml diff --git a/contributed_definitions/NXion.nxdl.xml b/base_classes/NXion.nxdl.xml similarity index 100% rename from contributed_definitions/NXion.nxdl.xml rename to base_classes/NXion.nxdl.xml diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/base_classes/NXlens_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXlens_em.nxdl.xml rename to base_classes/NXlens_em.nxdl.xml diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/base_classes/NXoptical_system_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXoptical_system_em.nxdl.xml rename to base_classes/NXoptical_system_em.nxdl.xml diff --git a/contributed_definitions/NXpeak.nxdl.xml b/base_classes/NXpeak.nxdl.xml similarity index 100% rename from contributed_definitions/NXpeak.nxdl.xml rename to base_classes/NXpeak.nxdl.xml diff --git a/contributed_definitions/NXprogram.nxdl.xml b/base_classes/NXprogram.nxdl.xml similarity index 100% rename from contributed_definitions/NXprogram.nxdl.xml rename to base_classes/NXprogram.nxdl.xml diff --git a/contributed_definitions/NXpump.nxdl.xml b/base_classes/NXpump.nxdl.xml similarity index 100% rename from contributed_definitions/NXpump.nxdl.xml rename to base_classes/NXpump.nxdl.xml diff --git a/contributed_definitions/NXregistration.nxdl.xml b/base_classes/NXregistration.nxdl.xml similarity index 100% rename from contributed_definitions/NXregistration.nxdl.xml rename to base_classes/NXregistration.nxdl.xml diff --git a/contributed_definitions/NXroi.nxdl.xml b/base_classes/NXroi.nxdl.xml similarity index 100% rename from contributed_definitions/NXroi.nxdl.xml rename to base_classes/NXroi.nxdl.xml diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/base_classes/NXscanbox_em.nxdl.xml similarity index 100% rename from contributed_definitions/NXscanbox_em.nxdl.xml rename to base_classes/NXscanbox_em.nxdl.xml diff --git a/contributed_definitions/NXspectrum_set.nxdl.xml b/base_classes/NXspectrum_set.nxdl.xml similarity index 100% rename from contributed_definitions/NXspectrum_set.nxdl.xml rename to base_classes/NXspectrum_set.nxdl.xml diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/base_classes/NXstage_lab.nxdl.xml similarity index 100% rename from contributed_definitions/NXstage_lab.nxdl.xml rename to base_classes/NXstage_lab.nxdl.xml diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml index 81b2909088..84a36254c2 100644 --- a/contributed_definitions/NXaperture_em.nxdl.xml +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of coefficients of the calibration function - - - - - Number of features used to fit the calibration function - - - - - Number of points of the calibrated and uncalibrated axes - - - - - Subclass of NXprocess to describe post-processing calibrations. - - - - Indicates the name of the last operation applied in the NXprocess sequence. - - - - - Has the calibration been applied? - - - - - For non-linear energy calibrations, e.g. in a TOF, a polynomial function is fit - to a set of features (peaks) at well defined energy positions to determine - E(TOF). Here we can store the array of fit coefficients. - - - - - - - - For non-linear energy calibrations. Here we can store the formula of the - fit function. - - Use a0, a1, ..., an for the coefficients, corresponding to the values in the coefficients field. - - Use x0, x1, ..., xn for the variables. - - The formula should be numpy compliant. - - - - - For linear calibration. Scaling parameter. - - - - - For linear calibration. Offset parameter. - - - - - A vector representing the axis after calibration, matching the data length - - - - - - - - Vector containing the data coordinates in the original uncalibrated axis - - - - - - - - A description of the procedures employed. - - - diff --git a/contributed_definitions/NXcg_primitive_set.nxdl.xml b/contributed_definitions/NXcg_primitive_set.nxdl.xml deleted file mode 100644 index e8cb457bc1..0000000000 --- a/contributed_definitions/NXcg_primitive_set.nxdl.xml +++ /dev/null @@ -1,212 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the space. - - - - - The cardinality of the set, i.e. the number of members. - - - - - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). - - - - - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - - - - - The dimensionality of the primitive set. - - - - - - - - - - The cardinality of the primitive set. - - - - - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - - - - - Identifier of each member for explicit indexing. - - - - - - - - The center of mass position of each primitive. - - - - - - - - - - True if the center is a center of mass. - - - - - - - - A qualitative description of the shape of each primitive. - - - - - - - - - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - - - - - - - - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - - - - - - - - True if primitive is closed such that it has properties like area or volume. - - - - - - - - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - - - - - - - - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - - - - - - - - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - - - - - - - - - - - diff --git a/contributed_definitions/NXcoordinate_system.nxdl.xml b/contributed_definitions/NXcoordinate_system.nxdl.xml deleted file mode 100644 index 494b92956e..0000000000 --- a/contributed_definitions/NXcoordinate_system.nxdl.xml +++ /dev/null @@ -1,143 +0,0 @@ - - - - - - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. - - - - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - - - - - - An alternative name given to that coordinate system. - - - - - Coordinate system type. - - - - - - - - Handedness of the coordinate system if it is a Cartesian. - - - - - - - - - Possibility to define an alias for the name of the x-axis. - - - - - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - - - - - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the y-axis. - - - - - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - - - - - - - - Possibility to define an alias for the name of the z-axis. - - - - - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - - - - - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the z-axis in real space and - the k-axis in reciprocal space. - - - - - - diff --git a/contributed_definitions/NXcrystal_structure.nxdl.xml b/contributed_definitions/NXcrystal_structure.nxdl.xml deleted file mode 100644 index 921663cef6..0000000000 --- a/contributed_definitions/NXcrystal_structure.nxdl.xml +++ /dev/null @@ -1,280 +0,0 @@ - - - - - - - - - Number of reflectors (Miller crystallographic plane triplets). - - - - - Number of atom positions. - - - - - Dimensionality of the lattice. - - - - - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. - - - - Detail in which reference frame the unit cell is defined. - - - - - Dimensionality of the lattice. - - - - - - - - - - Reference to another resource that was used for - instantiating this structure model. - - - - - Crystallography unit cell parameters a, b, and c. - - - - - - - - - Crystallography unit cell parameters alpha, beta, and gamma. - - - - - - - - Area of the unit cell considering that d = 2. - - - - - Volume of the unit cell considering that d = 3. - - - - - Crystal system - - - - - - - - - - - - - - - Laue group using International Table of Crystallography Notation. - - - - - - Point group using International Table of Crystallography Notation. - - - - - - Space group from the International Table of Crystallography Notation. - - - - - - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - - - - - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - - - - - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - - - - - - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - - - - - Label for each atom position. - - - - - - - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - Atom positions. - - - - - - - - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - - - - - - - Relative occupancy of the atom position. - - - - - - - - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - - - - - - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - - - - - - - - - Spacing between crystallographic planes as defined by field miller. - - - - - - - - Relative intensity of the signal for the plane. - - - - - - - - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - - - - - - - diff --git a/contributed_definitions/NXcs_cpu_obj.nxdl.xml b/contributed_definitions/NXcs_cpu_obj.nxdl.xml deleted file mode 100644 index 8a23293212..0000000000 --- a/contributed_definitions/NXcs_cpu_obj.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a (central) processing unit (C)PU of a computer. - - - - Given name of the CPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_cpu_sys.nxdl.xml b/contributed_definitions/NXcs_cpu_sys.nxdl.xml deleted file mode 100644 index 7a05ae8403..0000000000 --- a/contributed_definitions/NXcs_cpu_sys.nxdl.xml +++ /dev/null @@ -1,48 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a system of classical central processing units. - - For coprocessor or graphic cards use :ref:`NXcs_gpu_sys` instead. - - - - Granularizing at the socket level. - - Typical examples follow: A desktop computer with a single CPU one - could describe using one instance of :ref:`NXcs_cpu_obj` inside one instance of - :ref:`NXcs_cpu_sys`. - A dual-socket server one could describe using two instances of :ref:`NXcs_cpu_obj` - inside one instance of :ref:`NXcs_cpu_sys`. - A server with two dual-socket server nodes one could describe - with the above group of one :ref:`NXcs_cpu_sys` into another :ref:`NXcs_cpu_sys`. - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml index e8ef1af2d0..eb1e7e19c5 100644 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ b/contributed_definitions/NXcs_io_obj.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a memory in a memory system. - - - - Qualifier for the type of random access memory. - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXelectronanalyser.nxdl.xml b/contributed_definitions/NXelectronanalyser.nxdl.xml deleted file mode 100644 index c8211195ea..0000000000 --- a/contributed_definitions/NXelectronanalyser.nxdl.xml +++ /dev/null @@ -1,157 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays - - - - Number of fast axes (axes acquired symultaneously, without scanning a pysical - quantity) - - - - - Number of slow axes (axes acquired scanning a pysical quantity) - - - - - Subclass of NXinstrument to describe a photoelectron analyser. - - - - Free text description of the type of the detector - - - - - Name or model of the equipment - - - - Acronym or other shorthand name - - - - - - Energy resolution of the electron analyser (FWHM of gaussian broadening) - - - - - Momentum resolution of the electron analyser (FWHM) - - - - - Angular resolution of the electron analyser (FWHM) - - - - - Spatial resolution of the electron analyser (Airy disk radius) - - - - - List of the axes that are acquired simultaneously by the detector. - These refer only to the experimental variables recorded by the electron analyser. - Other variables such as temperature, manipulator angles etc. are labeled as fast or slow in the data. - - .. csv-table:: Examples - :header: "Mode", "fast_axes", "slow_axes" - - Hemispherical in ARPES mode, "['energy', 'kx']","" - "Hemispherical with channeltron, sweeping energy mode", "", [\"energy\"] - "Tof", "['energy', 'kx', 'ky']","" - "Momentum microscope, spin-resolved", "['energy', 'kx', 'ky']", "['spin up-down', 'spin left-right']" - - Axes may be less abstract than this, i.e. ['detector_x', 'detector_y']. - If energy_scan_mode=sweep, fast_axes: ['energy', 'kx']; slow_axes: ['energy'] is allowed. - - - - - - - - List of the axes that are acquired by scanning a physical parameter, listed in - order of decreasing speed. See fast_axes for examples. - - - - - - - - Refers to the last transformation specifying the positon of the manipulator in - the NXtransformations chain. - - - - - Collection of axis-based translations and rotations to describe the location and - geometry of the electron analyser as a component in the instrument. Conventions - from the NXtransformations base class are used. In principle, the McStas - coordinate system is used. The first transformation has to point either to - another component of the system or . (for pointing to the reference frame) to - relate it relative to the experimental setup. Typically, the components of a - system should all be related relative to each other and only one component - should relate to the reference coordinate system. - - - - - Describes the electron collection (spatial and momentum imaging) column - - - - - Describes the energy dispersion section - - - - - Describes the spin dispersion section - - - - - Describes the electron detector - - - - - Deflectors outside the main optics ensambles described by the subclasses - - - - - Individual lenses outside the main optics ensambles described by the subclasses - - - diff --git a/contributed_definitions/NXem_correlation.nxdl.xml b/contributed_definitions/NXem_correlation.nxdl.xml deleted file mode 100644 index 95a644b519..0000000000 --- a/contributed_definitions/NXem_correlation.nxdl.xml +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. - - - - Details about processing steps. - - - - - - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - - - - - - Descriptor representing the image contrast. - - - - - - Title of the default plot. - - - - - Descriptor values displaying the ROI. - - - - - - - - - - Descriptor values. - - - - - - Calibrated coordinate along the z-axis. - - - - - - - Label for the z axis - - - - - - Calibrated coordinate along the y-axis. - - - - - - - Label for the y axis - - - - - - Calibrated coordinate along the x-axis. - - - - - - - Label for the x axis - - - - - - - diff --git a/contributed_definitions/NXem_eels.nxdl.xml b/contributed_definitions/NXem_eels.nxdl.xml deleted file mode 100644 index 926e5acb64..0000000000 --- a/contributed_definitions/NXem_eels.nxdl.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - - - - - Number of electron energy loss bins. - - - - - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). - - - - - NXspectrum_set_em specialized for EELS. - - - - - - - - - - Energy loss. - - - - - - - - - Energy loss. - - - - - - - Energy loss. - - - - - - - diff --git a/contributed_definitions/NXem_msr.nxdl.xml b/contributed_definitions/NXem_msr.nxdl.xml deleted file mode 100644 index 7e9d834b80..0000000000 --- a/contributed_definitions/NXem_msr.nxdl.xml +++ /dev/null @@ -1,97 +0,0 @@ - - - - - - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. - - - - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - - - - Given name of the microscope at the hosting institution. - This is an alias. Examples could be NionHermes, Titan, JEOL, - Gemini, etc. - - - - - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - - - - - - - - - - - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - - - - Instrument-specific alias/name - - - - - - - - - - diff --git a/contributed_definitions/NXem_sim.nxdl.xml b/contributed_definitions/NXem_sim.nxdl.xml deleted file mode 100644 index 66282e001d..0000000000 --- a/contributed_definitions/NXem_sim.nxdl.xml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - - - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. - - - - Details about the simulation. - - - - - - - diff --git a/contributed_definitions/NXenergydispersion.nxdl.xml b/contributed_definitions/NXenergydispersion.nxdl.xml deleted file mode 100644 index 37868b4bca..0000000000 --- a/contributed_definitions/NXenergydispersion.nxdl.xml +++ /dev/null @@ -1,90 +0,0 @@ - - - - - - Subclass of NXelectronanalyser to describe the energy dispersion section of a - photoelectron analyser. - - - - Energy dispersion scheme employed, for example: tof, hemispherical, cylindrical, - mirror, retarding grid, etc. - - - - - Energy of the electrons on the mean path of the analyser. Pass energy for - hemispherics, drift energy for tofs. - - - - - Center of the energy window - - - - - The interval of transmitted energies. It can be two different things depending - on whether the scan is fixed or swept. With a fixed scan it is a 2 vector - containing the extrema of the transmitted energy window (smaller number first). - With a swept scan of m steps it is a 2xm array of windows one for each - measurement point. - - - - - Size, position and shape of a slit in dispersive analyzer, e.g. entrance and - exit slits. - - - - - Diameter of the dispersive orbit - - - - - Way of scanning the energy axis (fixed or sweep). - - - - - - - - - Length of the tof drift electrode - - - - - Deflectors in the energy dispersive section - - - - - Individual lenses in the energy dispersive section - - - diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml deleted file mode 100644 index a6beeb6482..0000000000 --- a/contributed_definitions/NXinteraction_vol_em.nxdl.xml +++ /dev/null @@ -1,37 +0,0 @@ - - - - - Base class for storing details about a modelled shape of interaction volume. - - The interaction volume is mainly relevant in scanning electron microscopy - when the sample is thick enough so that the beam is unable to illuminate - through the specimen. - Computer models like Monte Carlo or molecular dynamics / electron beam - interaction simulations can be used to qualify and/or quantify the shape of - the interaction volume. - - Explicit or implicit descriptions are possible. - - * An implicit description is via a set of electron/specimen interactions - represented ideally as trajectory data from the computer simulation. - * An explicit description is via an iso-contour surface using either - a simulation grid or a triangulated surface mesh of the approximated - iso-contour surface evaluated at specific threshold values. - Iso-contours could be computed from electron or particle fluxes through - an imaginary control surface (the iso-surface). - Threshold values can be defined by particles passing through a unit control - volume (electrons) or energy-levels (e.g. the case of X-rays). - Details depend on the model. - * Another explicit description is via theoretical models which may - be relevant e.g. for X-ray spectroscopy - - Further details on how the interaction volume can be quantified - is available in the literature for example: - - * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ - * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ - - - - diff --git a/contributed_definitions/NXmpes.nxdl.xml b/contributed_definitions/NXmpes.nxdl.xml deleted file mode 100644 index 3f1db75e2b..0000000000 --- a/contributed_definitions/NXmpes.nxdl.xml +++ /dev/null @@ -1,371 +0,0 @@ - - - - - - - This is the most general application definition for multidimensional - photoelectron spectroscopy. - - - - - - Datetime of the start of the measurement. - - - - - - - - - - - Contact information of at least the user of the instrument or the investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Name of the user. - - - - - Name of the affiliation of the user at the point in time when the experiment was - performed. - - - - - Full address (street, street number, ZIP, city, country) of the user's - affiliation. - - - - - Email address of the user. - - - - - Author ID defined by https://orcid.org/. - - - - - - - - The source used to generate the primary photons. Properties refer strictly to - parameters of the source, not of the output beam. For example, the energy of the - source is not the optical power of the beam, but the energy of the electron beam - in a synchrotron and so on. - - - - - - - - - - - - - - - - - - Type of probe. In photoemission it's always photons, so the full NIAC list is - restricted. - - - - - - - - - - - - Distance of the point of evaluation of the beam from the sample surface. - - - - - - - - - - - Energy resolution of the analyser with the current setting. May be linked from a - NXcalibration. - - - - - - - - Scheme of the electron collection column. - - - - - - - - - - - - - - - The size and position of the field aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - The size and position of the contrast aperture inserted in the column. To add - additional or other apertures use the APERTURE group of NXcollectioncolumn. - - - - - - - - - - - - - - - - - - - Size, position and shape of the entrance slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - Size, position and shape of the exit slit in dispersive analyzers. To add - additional or other slits use the APERTURE group of NXenergydispersion. - - - - - - - Type of electron amplifier in the first amplification step. - - - - - - - - - - Description of the detector type. - - - - - - - - - - - - - - - - - - - Raw data before calibration. - - - - - - - - Manipulator for positioning of the sample. - - - - - - - - - Document an event of data processing, reconstruction, or analysis for this data. - Describe the appropriate axis calibrations for your experiment using one or more - of the following NXcalibrations - - - - - Has an energy calibration been applied? - - - - - This is the calibrated energy axis to be used for data plotting. - - - - - - - Has an angular calibration been applied? - - - - - This is the calibrated angular axis to be used for data plotting. - - - - - - - Has an spatial calibration been applied? - - - - - This is the calibrated spatial axis to be used for data plotting. - - - - - - - Has an momentum calibration been applied? - - - - - This is the momentum axis to be used for data plotting. - - - - - - - - - The chemical formula of the sample. For mixtures use the NXsample_component - group in NXsample instead. - - - - - A descriptor to keep track of the treatment of the sample before entering the - photoemission experiment. Ideally, a full report of the previous operations, in - any format (NXnote allows to add pictures, audio, movies). Alternatively, a - reference to the location or a unique identifier or other metadata file. In the - case these are not available, free-text description. - - - - - List of comma-separated elements from the periodic table - that are contained in the sample. - If the sample substance has multiple components, all - elements from each component must be included in `atom_types`. - - - - - Date of preparation of the sample for the XPS experiment (i.e. cleaving, last - annealing). - - - - - Description of the surface preparation technique for the XPS experiment, i.e. - UHV cleaving, in-situ growth, sputtering/annealing etc. Ideally, a full report - of the previous operations, in any format(NXnote allows to add pictures, audio, - movies). Alternatively, a reference to the location or a unique identifier or - other metadata file. In the case these are not available, free-text description. - - - - - - In the case of a fixed temperature measurement this is the scalar temperature of - the sample. In the case of an experiment in which the temperature is changed and - recoded, this is an array of length m of temperatures. This should be a link to - /entry/instrument/manipulator/sample_temperature. - - - - - - - - - - - - - - - - - - - - - - Represents a measure of one- or more-dimensional photoemission counts, where the - varied axis may be for example energy, momentum, spatial coordinate, pump-probe - delay, spin index, temperature, etc. The axes traces should be linked to the - actual encoder position in NXinstrument or calibrated axes in NXprocess. - - - - - diff --git a/contributed_definitions/NXms_ipf_set.nxdl.xml b/contributed_definitions/NXms_ipf_set.nxdl.xml deleted file mode 100644 index 7f490dd84b..0000000000 --- a/contributed_definitions/NXms_ipf_set.nxdl.xml +++ /dev/null @@ -1,33 +0,0 @@ - - - - - - - Base class to group multiple :ref:`NXms_ipf` instances. - - A collection of inverse pole figure approximations. - - - diff --git a/contributed_definitions/NXpulser_apm.nxdl.xml b/contributed_definitions/NXpulser_apm.nxdl.xml deleted file mode 100644 index a57b1af0d5..0000000000 --- a/contributed_definitions/NXpulser_apm.nxdl.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Total number of ions collected. - - - - - Metadata for laser- and/or voltage-pulsing in atom probe microscopy. - - - - - How is field evaporation physically triggered. - - - - - - - - - - Frequency with which the high voltage or laser pulser fires. - - - - - - - - - Fraction of the pulse_voltage that is applied in addition - to the standing_voltage at peak voltage of a pulse. - - If a standing voltage is applied, this gives nominal pulse fraction - (as a function of standing voltage). Otherwise this field should not be - present. - - - - - - - - In laser pulsing mode the values will be zero so the this field is recommended. - However, for voltage pulsing mode it is highly recommended that users report the pulsed_voltage. - - - - - - - - Absolute number of pulses starting from the beginning of the experiment. - - - - - - - - Direct current voltage between the specimen and the (local electrode) in - the case of local electrode atom probe (LEAP) instrument. - The standing voltage applied to the sample, relative to system ground. - - - - - - - - Atom probe microscopes use controlled laser, voltage, - or a combination of pulsing strategies to trigger the - excitation and eventual field evaporation/emission of - an ion during an experiment. - - - - Given name/alias. - - - - - - Nominal wavelength of the laser radiation. - - - - - Nominal power of the laser source while illuminating the specimen. - - - - - - Average energy of the laser at peak of each pulse. - - - - - Details about specific positions along the focused laser beam - which illuminates the (atom probe) specimen. - - - - Track time-dependent settings over the course of the - measurement how the laser beam in tip space/reconstruction space - laser impinges on the sample, i.e. the mean vector is parallel to - the laser propagation direction. - - - - - Track time-dependent settings over the course of the - measurement where the laser beam exits the - focusing optics. - - - - - Track time-dependent settings over the course of the - measurement where the laser hits the specimen. - - - - - - Affine transformations which describe the geometry how the - laser focusing optics/pinhole-attached coordinate system is - defined, how it has to be transformed so that it aligns with - the specimen coordinate system. - A right-handed Cartesian coordinate system, the so-called laser space, - should be assumed, whose positive z-axis points - into the direction of the propagating laser beam. - - - - diff --git a/contributed_definitions/NXreflectron.nxdl.xml b/contributed_definitions/NXreflectron.nxdl.xml deleted file mode 100644 index e2220a1bed..0000000000 --- a/contributed_definitions/NXreflectron.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - Device for reducing flight time differences of ions in ToF experiments. - For atom probe the reflectron can be considered an energy_compensation - device, which can e.g. be realized technically as via a Poschenrieder lens - (see US patent 3863068 or US patents for the reflectron 6740872, or the curved reflectron 8134119 design). - - - - Given name/alias. - - - - - - Free-text field to specify further details about the reflectron. - The field can be used to inform e. g. if the reflectron is flat or curved. - - - - - - Affine transformation(s) which detail where the reflectron - is located relative to e.g. the origin of the specimen space - reference coordinate system. - This group can also be used for specifying how the reflectron - is rotated relative to the specimen axis. - The purpose of these more detailed instrument descriptions - is to support the creation of a digital twin of the instrument - for computational science. - - - diff --git a/contributed_definitions/nyaml/NXcg_primitive_set.yaml b/contributed_definitions/nyaml/NXcg_primitive_set.yaml deleted file mode 100644 index 586929596f..0000000000 --- a/contributed_definitions/nyaml/NXcg_primitive_set.yaml +++ /dev/null @@ -1,136 +0,0 @@ -category: base -doc: | - Computational geometry description of a set of primitives in Euclidean space. - - Primitives must neither be degenerated nor self-intersect. - Individual primitives can differ in their properties (e.g. size, shape, rotation). -# this base class defines common fields and properties of geometric primitives -# more complex primitive sets like NXcg_cylinder_set are considered specializations -# of NXcg_primitive_set. They contain all fields and groups which NXcg_primitive_set -# defines. This is an action of compositing an information set; an act of inheriting -# TODO:: many properties of non-degenerate primitives are in the number set -# R+ instead of in R+0 but currently NeXus does not allow for such value range -# constraints unless the coarsely discretized NX_INT, NX_POSINT, NX_FLOAT -# but there is no say NX_FLOAT+0 -# MK::but in computational geometry numerical precision matters as it defines -# whether objects numerically intersect or not and thus it can make a real difference -# if one stores triangles with 16, 32, or 64 bit precision, however: -# are two triangle_set instance A and B no longer conceptually triangle sets -# because A stores the positions of vertices using int8 while B stores such using float64 ? -# we here assume that we still conceptually talk that A and B are triangle sets -# but this brings at the level of the application definition the problem that if the -# precision is not properly constrainted a consuming application will not obtain -# the instances of the concept triangle_set with relevant high enough precision -# and thus neither the base class nor the application definition is specific enough -# for what it was designed in the first place - be specific about the requirements -# on your data... -symbols: - doc: | - The symbols used in the schema to specify e.g. dimensions of arrays. - d: | - The dimensionality of the space. - c: | - The cardinality of the set, i.e. the number of members. -type: group -NXcg_primitive_set(NXobject): - # individual specializations like NXcg_polyline_set typically overwrite - # the meaning of the depends_on concept to build consistent inference chains - # to enable an instantiation of the actual geometric primitives - \@depends_on(NX_CHAR): - doc: | - Hint to help resolve in which Euclidean coordinate system field values - like center or orientation are defined. - dimensionality(NX_POSINT): - doc: | - The dimensionality of the primitive set. - unit: NX_UNITLESS - enumeration: [1, 2, 3] - cardinality(NX_POSINT): - doc: | - The cardinality of the primitive set. - unit: NX_UNITLESS - identifier_offset(NX_INT): - doc: | - Integer offset whereby the identifier of the first member - of the set differs from zero. - - Identifiers can be defined either implicitly or explicitly. - For implicit indexing identifiers are defined on the interval - :math:`[identifier_offset, identifier_offset + c - 1]`. - - Therefore, implicit identifier are completely defined by the value of - identifier_offset and cardinality. For example if identifier run from - -2 to 3 the value for identifier_offset is -2. - - For explicit indexing the field identifier has to be used. - Fortran-/Matlab- and C-/Python-style indexing have specific implicit - identifier conventions where identifier_offset is 1 and 0 respectively. - unit: NX_UNITLESS - identifier(NX_INT): - doc: | - Identifier of each member for explicit indexing. - dim: (c,) # numpy style indexing - center(NX_NUMBER): - doc: | - The center of mass position of each primitive. - unit: NX_ANY - dim: (c, d) - # a depends_on to define in which coordinate system - is_center_of_mass(NX_BOOLEAN): - doc: | - True if the center is a center of mass. - dim: (c,) - shape(NX_NUMBER): - doc: | - A qualitative description of the shape of each primitive. - unit: NX_LENGTH - dim: (c, d) - length(NX_NUMBER): - doc: | - Qualifier for the length of characteristic features of the primitive. - - Often the term length is associated with the assumption that one - edge is parallel to an axis of the coordinate system. - unit: NX_LENGTH - dim: (c,) - width(NX_NUMBER): - doc: | - Qualifier often used to describe the length of one characteristic edge - within the coordinate system. - unit: NX_LENGTH - dim: (c,) - is_closed(NX_BOOLEAN): - doc: | - True if primitive is closed such that it has properties like area or volume. - dim: (c,) - volume(NX_NUMBER): - doc: | - Volume of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_VOLUME - dim: (c,) - area(NX_NUMBER): - doc: | - Alias for surface_area of each primitive. - - Set to NaN if does not apply for primitives for which is_closed is False. - unit: NX_AREA - dim: (c,) - orientation(NX_NUMBER): - doc: | - Direction unit vector which points along the - longest principal axis of each primitive. - - Use the depends_on attribute to specify in which coordinate system - these direction unit vectors are defined. - unit: NX_DIMENSIONLESS - dim: (c, d) - vertex_normal(NXcg_unit_normal_set): - edge_normal(NXcg_unit_normal_set): - face_normal(NXcg_unit_normal_set): - # roi(NXcg_parallelogram_set or NXcg_hexahedron_set) - # aabb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # obb(NXcg_parallelogram_set or NXcg_hexahedron_set) - # MK::one could add (NXcg_parallelogram_set) and/or (NXcg_hexahedron_set) - # but then one would not give any hint at the base class level how to name diff --git a/contributed_definitions/nyaml/NXcoordinate_system.yaml b/contributed_definitions/nyaml/NXcoordinate_system.yaml deleted file mode 100644 index b219399001..0000000000 --- a/contributed_definitions/nyaml/NXcoordinate_system.yaml +++ /dev/null @@ -1,86 +0,0 @@ -category: base -doc: | - Base class to detail a coordinate system (CS). - - Whenever possible, an instance of :ref:`NXcoordinate_system` should be used as - a member in an :ref:`NXcoordinate_system_set` and the name of the instance - should be this alias. This may support a process whereby jargon when talking - about coordinate systems and conventions may become cleaner for users - because it is not evident for people outside a lab that terms like e.g. - tip space or specimen space refer to the same coordinate system. - This is an example of jargon used in e.g. the field of atom - probe tomography. -type: group -NXcoordinate_system(NXobject): - origin(NX_CHAR): - doc: | - Human-readable field telling where the origin of this CS is. - Exemplar values could be *left corner of the lab bench*, *door-handle* - *pinhole through which the electron beam exists the pole piece*. - *barycenter of the triangle*, *center of mass of the stone*. - # implementing a proposal for "a common base table" along thoughts like: - # https://manual.nexusformat.org/classes/base_classes/NXtransformations.html#nxtransformations - # similar to a place where all transformations are stored - # https://www.zenodo.org/record/3526738/files/lyso009a_0087.JF07T32V01_master.h5?download=1 - alias(NX_CHAR): - doc: | - An alternative name given to that coordinate system. - type(NX_CHAR): - doc: | - Coordinate system type. - enumeration: [cartesian] - handedness(NX_CHAR): - doc: | - Handedness of the coordinate system if it is a Cartesian. - enumeration: [right_handed, left_handed] - x_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the x-axis. - x_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the x-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - Exemplar values could be direction of gravity. - x(NX_NUMBER): - doc: | - Base unit vector along the first axis which spans the coordinate system. - This axis is frequently referred to as the x-axis in real space and - the i-axis in reciprocal space. - unit: NX_LENGTH - dim: (3,) - y_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the y-axis. - y_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the y-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - y(NX_NUMBER): - doc: | - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the y-axis in real space and - the j-axis in reciprocal space. - unit: NX_LENGTH - dim: (3,) - z_alias(NX_CHAR): - doc: | - Possibility to define an alias for the name of the z-axis. - z_direction(NX_CHAR): - doc: | - Human-readable field telling in which direction the z-axis points if that - instance of :ref:`NXcoordinate_system` has no reference to any parent and as such - is the mighty world reference frame. - - See docstring of x_alias for further details. - z(NX_NUMBER): - doc: | - Base unit vector along the second axis which spans the coordinate system. - This axis is frequently referred to as the z-axis in real space and - the k-axis in reciprocal space. - unit: NX_LENGTH - dim: (3,) diff --git a/contributed_definitions/nyaml/NXcrystal_structure.yaml b/contributed_definitions/nyaml/NXcrystal_structure.yaml deleted file mode 100644 index 796ac83d3c..0000000000 --- a/contributed_definitions/nyaml/NXcrystal_structure.yaml +++ /dev/null @@ -1,178 +0,0 @@ -category: base -doc: | - Base class to describe the atomic crystal structure of a phase. - - This base class contains key metadata that are relevant parameter to every - physics-based model to simulate radiation matter interaction. - - Examples where such base class is useful are kinematic or dynamic - diffraction simulations of e.g. (Kikuchi or other type of) patterns. -# The actual indexing of Kikuchi patterns may use different algorithms. -# Such are used within different workflows where simulated and measured -# Kikuchi pattern are compared to rate which phase and orientation is the most -# likely candidate describing the pattern measured at that each scan point -# respectively. If this evaluation yields scan points without any solutions, -# these are represented using the null-phase model phase0, aka n/a aka notIndexed. -# Traditionally, Hough transformation-based indexing has been the most frequently -# used algorithm. Dictionary-based alternatives are emerging. -symbols: - n_hkl: | - Number of reflectors (Miller crystallographic plane triplets). - n_pos: | - Number of atom positions. - d: | - Dimensionality of the lattice. -type: group -NXcrystal_structure(NXobject): - \@depends_on(NX_CHAR): - doc: | - Detail in which reference frame the unit cell is defined. - dimensionality(NX_POSINT): - doc: | - Dimensionality of the lattice. - enumeration: [1, 2, 3] - reference(NXidentifier): - doc: | - Reference to another resource that was used for - instantiating this structure model. - a_b_c(NX_NUMBER): - doc: | - Crystallography unit cell parameters a, b, and c. - unit: NX_LENGTH - dim: (d,) - # defined using which convention? - alpha_beta_gamma(NX_NUMBER): - doc: | - Crystallography unit cell parameters alpha, beta, and gamma. - unit: NX_ANGLE - dim: (d,) - area(NX_NUMBER): - doc: | - Area of the unit cell considering that d = 2. - unit: NX_AREA - volume(NX_NUMBER): - doc: | - Volume of the unit cell considering that d = 3. - unit: NX_VOLUME - crystal_system(NX_CHAR): - doc: | - Crystal system - enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] - # 2d - laue_group(NX_CHAR): - doc: | - Laue group using International Table of Crystallography Notation. - # add enumeration of all possible - point_group(NX_CHAR): - doc: | - Point group using International Table of Crystallography Notation. - # add enumeration all possible - # 3d - space_group(NX_CHAR): - doc: | - Space group from the International Table of Crystallography Notation. - # add enumeration of all possible - is_centrosymmetric(NX_BOOLEAN): - doc: | - True if space group is considered a centrosymmetric one. - False if space group is considered a non-centrosymmetric one. - Centrosymmetric has all types and combinations of symmetry elements - (translation, rotational axis, mirror planes, center of inversion) - Non-centrosymmetric compared to centrosymmetric is constrained (no inversion). - Chiral compared to non-centrosymmetric is constrained (no mirror planes). - is_chiral(NX_BOOLEAN): - doc: | - True if space group is considered a chiral one. - False if space group is consider a non-chiral one. - phase_identifier(NX_INT): - doc: | - Identifier for each phase. - - The value 0 is reserved for the unknown phase that represents the - null-model no sufficiently significant confirmation. In other words, - the phase_name is n/a, notIndexed. - - The phase identifier value has to match with the integer postfix of the - group name which represents that instance in a NeXus/HDF5 file, i.e. - if two phases were used e.g. 0 and 1, two instances of an - :ref:`NXcrystal_structure` named phase0 and phase1 - should be stored in the HDF5 file. - unit: NX_UNITLESS - # \@depends_on(NX_CHAR): - # doc: | - # Refers to the specific identifier_offset to consider. - # - # If not provided assume identifier_offset is 0. - phase_name(NX_CHAR): - doc: | - Name of the phase/alias. - - If the phase_identifier is 0 and one would like to use the field - phase_name the value should be n/a. - atom_identifier(NX_CHAR): - doc: | - Label for each atom position. - dim: (n_pos,) - atom_type(NX_UINT): - doc: | - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) `_ - unit: NX_UNITLESS - dim: (n_pos,) - # atom_position(NXcg_point_set): - atom_position(NX_NUMBER): - doc: | - Atom positions. - dim: (n_pos, d) - unit: NX_ANY - \@depends_on(NX_CHAR): - doc: | - Reference to an instance of :ref:`NXcoordinate_system` - whereby the positions can be resolved. - # in addition we need to have a physical model e.g. kinematic or dynamical e-diffraction theory - # to describe the simulated Kikuchi pattern generated from such a model - atom_occupancy(NX_NUMBER): - doc: | - Relative occupancy of the atom position. - unit: NX_DIMENSIONLESS - dim: (n_pos,) - number_of_planes(NX_UINT): - doc: | - How many reflectors are distinguished. - - Value has to match value for symbol n_hkl. - unit: NX_UNITLESS - # Miller indices :math:`(hkl)[uvw]`. - miller(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Miller indices :math:`(hkl)[uvw]` of the planes. - - The first triplet specify :math:`(hkl)` the second triplet :math:`[uvw]`. - Miller indices refer to the Cartesian right-handed coordinate system - of the unit cell. - dim: (n_hkl, 6) - dspacing(NX_NUMBER): - doc: | - Spacing between crystallographic planes as defined by field miller. - unit: NX_LENGTH - dim: (n_hkl,) - relative_intensity(NX_NUMBER): - doc: | - Relative intensity of the signal for the plane. - unit: NX_DIMENSIONLESS - dim: (n_hkl,) - number_of_scan_points(NX_UINT): - doc: | - In case the :ref:`NXcrystal_structure` base class is used - with analyzed orientation maps this field stores how many scan points - of the map were identified as that phase. - unit: NX_UNITLESS - ipfID(NXms_ipf): - pfID(NXms_pf): - odfID(NXms_odf): -# here the theoreticians expert (Marc deGraeff, Aimo Winkelmann, Peter Rez) -# can give some good suggestions on how to improve and ideally make even -# more general this section diff --git a/contributed_definitions/nyaml/NXem_correlation.yaml b/contributed_definitions/nyaml/NXem_correlation.yaml deleted file mode 100644 index 2acf65ec86..0000000000 --- a/contributed_definitions/nyaml/NXem_correlation.yaml +++ /dev/null @@ -1,191 +0,0 @@ -category: base -doc: | - Base class to combine different method-specific data in electron microscopy. - - This base class represent a template for documenting correlations - (spatial, temporal) between different method-specific results. -type: group -NXem_correlation(NXem_method): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - indexing(NXprocess): - doc: | - Details about correlated or logically connected EBSD datasets. - - One important class of such correlated experiments are the so-called - (quasi) in-situ experiments. In this case the same or nearly the same ROI - gets analyzed via a repetitive sequence of thermomechanical treatment, - sample preparation, measurement, on-the-fly-indexing. Phenomena - investigated are recrystallization, strain accumulation, material damage. - Post-processing is required to correlate and reidentify eventual - microstructural features or local ROIs across several orientation maps. - - Another important class of correlated experiments are the so-called - serial-sectioning experiments. Here the same sample is measured - repetitively after polishing each time, to create a stack of - orientation data which can be reconstructed to a - three-dimensional volume ROI. - - Data can be correlated in time, position (spatial), or both (spatiotemporal). - - Spatial correlations between repetitively characterized regions-of-interests - are typically correlated using image registration and alignment algorithms. - For this typically so-called landmarks are used. These can be grains with - a very large size or specific shape, i.e. grains which are qualitatively - different enough to be used as a guide how images are shifted relative to - one another. Other commonly used landmarks are fiducial marks which are - milled into the specimen surface using focus-ion beam milling and/or various - types of indentation methods. - - As far as the same physical region-of-interest is just measured several times, - the additional issue of the depth increment is not a concern. However, correct - assumptions for the depth increment, amount of material removed along the milling - direction is relevant for accurate and precise three-dimensional (serial-sectioning) - correlations. For these studies it can be tricky though to assume or estimate - useful depth increments. Different strategies have been proposed like - calibrations, wedged-shaped landmarks and computer simulation assisted - assumption making. - - Despite the use of landmarks, there are many practical issues which make the - processing of correlations imprecise and inaccurate. Among these are drift - and shift of the specimen, instabilities of the holder, the beam, irrespective - of the source of the drift, charging effects, here specifically causing local - image distortions and rotations which may require special processing algorithms - to reduce such imprecisions. - - Time correlations face all of the above-mentioned issues surplus the challenge - that specific experimental protocols have to be used to ensure the material state - is observed at specific physical time. The example of quasi in-situ characterization - of crystal growth phenomena, a common topic in engineering or modern catalysis research - makes it necessary to consider that e.g. the target value for the desired annealing - temperature is not just gauged based on macroscopic arguments but considers - that transient effects take place. Heating or quenching a sample might thus might - not have been executed under conditions in the interaction volume as they are - documented and/or assumed. - - These issue cause that correlations have an error margin as to how accurately - respective datasets were not only just synced based on the geometry of the - region-of-interests and the time markers but also to asssure which physical - conditions the specimen experienced over the course of the measurements. - - The fourth example of the em_om reference implementation explores the use of the - correlation group with a serial-sectioning datasets that was collected by the - classical Inconel 100 dataset collected by M. D. Uchic and colleagues - (M. Groeber M, Haley BK, Uchic MD, Dimiduk DM, Ghosh S 3d reconstruction and - characterization of polycrystalline microstructures using a fib-sem system data set. - Mater Charac 2006, 57 259–273. 10.1016/j.matchar.2006.01.019M). - - This dataset was specifically relevant in driving forward the implementation - of the DREAM.3D software. DREAM.3D is an open-source software project for - post-processing and reconstructing, i.e. correlating sets of orientation - microscopy data foremost spatially. One focus of the software is the - (post-)processing of EBSD datasets. Another cutting edge tool with similar - scope but a commercial solution by Bruker is QUBE which was developed by - P. Konijnenberg and coworkers. - - Conceptually, software like DREAM.3D supports users with creating linear - workflows of post-processing tasks. Workflows can be instructed via the - graphical user interface or via so-called pipeline processing via command line - calls. DREAM.3D is especially useful because its internal system documents all - input, output, and parameter of the processing steps. This makes DREAM.3D a - good candidate to interface with tools like em_om parser. Specifically, DREAM.3D - documents numerical results via a customized HDF5 file format called DREAM3D. - Workflow steps and settings are stored as nested dictionaries in JSON syntax - inside a supplementary JSON file or alongside the data in the DREAM3D file. - DREAM.3D has a few hundred algorithms implemented. These are called filters - in DREAM.3D terminology. - - Users configure a workflow which instructs DREAM.3D to send the data through - a chain of predefined and configured filters. Given that for each analysis - the filter is documented via its version tags surplus its parameter and setting - via a controlled vocabulary, interpreting the content of a DREAM3D HDF5 file - is possible in an automated manner using a parser. This makes DREAM.3D analyses - repeatable and self-descriptive. A key limitation though is that most frequently - the initial set of input data come from commercial files like ANG. - This missing link between the provenance of these input files, their associated - creation as electron microscope session, is also what NXem_ebsd solves. - - Nevertheless, as this can be solved with e.g. NXem_ebsd we are convinced that - the DREAM.3D and the em_om parser can work productively together to realize - RDMS-agnostic parsing of serial-section analyses. - - The internal documentation of the DREAM.3D workflow also simplifies the - provenance tracking represented by an instance of NXem_ebsd as not every - intermediate results has to be stored. Therefore, the fourth example - focuses on the key result obtained from DREAM.3D - the reconstructed - and aligned three-dimensional orientation map. - - Usually, this result is the starting point for further post-processing - and characterization of structural features. As here orientation microscopy - is insofar scale invariant using DREAM.3D, NXem_ebsd, and em_om should - be useful for different characterization methods, such as EBSD, Transmission - Kikuchi Diffraction (TKD), Automated Crystal Orientation Mapping (ACOM), - Nanobeam Electron Diffraction (using commercial systems like NanoMegas ASTAR) - or open-source implementations of these techniques (such as via pyxem/orix). - - The result of orientation microscopy methods are maps of local orientation - and thermodynamic phase (crystal structure) pieces of information. Virtually - all post-processing of such results for structural features includes again - a workflow of steps which are covered though by the NXms partner application - definition. The respective source of the data in an instance of NXms can - again be a link or reference to an instance of NXem_ebsd to complete the - chain of provenance. - (NXcrystal_structure): - roi(NXdata): - descriptor: - doc: | - Descriptor representing the image contrast. - # \@signal: # data - # \@axes: # [axis_y, axis_x] - # \@axis_x_indices: 0 - # \@axis_y_indices: 1 - # \@signal: - # \@axes: - # \@AXISNAME_indices: - # \@long_name: - title: - doc: | - Title of the default plot. - data(NX_NUMBER): - unit: NX_UNITLESS - doc: | - Descriptor values displaying the ROI. - dim: (n_z, n_y, n_x) - # n_0 slowest 3, n_1 slow 2, n_2 fast 1, rgb triplet is fastest 0 - # in axes fast to fastest - # while for _indices fastest to fast - \@long_name: - doc: | - Descriptor values. - axis_z(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the z-axis. - dim: (n_z,) - \@long_name: - doc: | - Label for the z axis - axis_y(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the y-axis. - dim: (n_y,) - \@long_name: - doc: | - Label for the y axis - axis_x(NX_NUMBER): - unit: NX_LENGTH - doc: | - Calibrated coordinate along the x-axis. - dim: (n_x,) - \@long_name: - doc: | - Label for the x axis - # NEW ISSUE: implement support for filters eventually many of them - # NEW ISSUE: for now only show that data from DREAM3D can be loaded. - # NEW ISSUE: how to handle landmarks - # NEW ISSUE: again an entire set of workflows such as rigid or non-rigid - # image registration etc. - # sequence_index(N0): diff --git a/contributed_definitions/nyaml/NXem_eds.yaml b/contributed_definitions/nyaml/NXem_eds.yaml deleted file mode 100644 index 9a5a97fcd0..0000000000 --- a/contributed_definitions/nyaml/NXem_eds.yaml +++ /dev/null @@ -1,80 +0,0 @@ -category: base -doc: | - Base class method-specific for energy-dispersive X-ray spectroscopy (EDS/EDX). - - `IUPAC instead of Siegbahn notation `_ should be used. - -# NEW ISSUE: use computational geometry to offer arbitrary scan pattern -# NEW ISSUE: make the binning flexible per scan point -symbols: - # n_p: Number of scan points - n_y: | - Number of pixel along the y direction, the slow direction - n_x: | - Number of pixel along the x direction, the fast direction - n_photon_energy: | - Number of X-ray photon energy (bins), the fastest direction. - n_elements: | - Number of identified elements - n_peaks: | - Number of peaks detected -type: group -NXem_eds(NXem_method): - # NXprocess is composed from NXem_method base class - # SPECTRUM_SET(NXspectrum_set) is composed from NXem_method base class - # for post-processing of/with the above-defined data entries - # including feedback from Christoph Pauly (from MX Uni Saarland, NFDI-MatWerk), - # Sabine Bergmann and Sebastian Brückner (both from FAIRmat, IKZ), - # and Adrien Teutrie, Cecile Hebert (EPFL) - indexing(NXprocess): - doc: | - Details about computational steps how peaks were indexed as elements. - (NXprogram): - doc: | - The program with which the indexing was performed. - PEAK(NXpeak): - doc: | - Name and location of each X-ray line which was indexed as a known ion. - For each ion, an NXion instance should be created which specifies - the origin of the signal. For each ion also the relevant IUPAC notation - X-ray lines should be specified. - (NXion): - energy_range(NX_NUMBER): - doc: | - Associated lower :math:`[e_{min}, e_{max}]` bounds of the - energy which is assumed associated with this peak. - unit: NX_ENERGY - dim: (2,) - energy(NX_NUMBER): - doc: | - Theoretical energy of the line according to IUPAC. - unit: NX_ENERGY - iupac_line_names(NX_CHAR): - doc: | - IUPAC notation identifier of the line which the peak represents. - - This can be a list of IUPAC notations for (the seldom) case that - multiple lines are grouped with the same peak. - dim: (i,) - element_names(NX_CHAR): - doc: | - List of the names of identified elements. - dim: (n_elements,) - IMAGE_R_SET(NXimage_r_set): - doc: | - Individual element-specific EDS/EDX/EDXS/SXES mapping - - A composition map is an image whose intensities for each pixel are the - accumulated X-ray quanta *under the curve(s)* of a set of peaks. - - These element-specific EDS maps are NXimage_r_set instances - and need to be named with the name of the element from the - element_names field. - (NXprocess): - peaks(NX_CHAR): - doc: | - A list of NXpeak instance names whose X-ray quanta - where accumulated for each pixel which yields an element-specific - EDS map. - dim: (n_peaks,) - # everything else is composed from NXimage_r_set diff --git a/contributed_definitions/nyaml/NXem_eels.yaml b/contributed_definitions/nyaml/NXem_eels.yaml deleted file mode 100644 index 4e5c69fe4a..0000000000 --- a/contributed_definitions/nyaml/NXem_eels.yaml +++ /dev/null @@ -1,39 +0,0 @@ -category: base -doc: | - Base class method-specific for Electron Energy Loss Spectroscopy (EELS). -symbols: - n_energy_loss: | - Number of electron energy loss bins. -type: group -NXem_eels(NXem_method): - # NXem_method can offers to keep a SPECTRUM_SET - # NXem_method also has an NXprocess which in this base class can be - # specialized to include EELS-specific post-processing - SPECTRUM_SET(NXspectrum_set): - doc: | - NXspectrum_set_em specialized for EELS. - stack(NXdata): - # \@signal: data_counts - # \@axes: [axis_y, axis_x, axis_energy_loss] - # \@energy_loss_indices: 2 - # \@axis_x_indices: 1 - # \@axis_y_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - summary(NXdata): - # \@signal: data_counts - # \@axes: [axis_energy_loss] - # \@energy_loss_indices: 0 - axis_energy_loss(NX_NUMBER): - unit: NX_ENERGY - doc: | - Energy loss. - dim: (n_energy_loss,) - \@long_name(NX_CHAR): - doc: | - Energy loss. - # collection if needed can be composed from NXspectrum_set diff --git a/contributed_definitions/nyaml/NXem_img.yaml b/contributed_definitions/nyaml/NXem_img.yaml deleted file mode 100644 index 8c257d121a..0000000000 --- a/contributed_definitions/nyaml/NXem_img.yaml +++ /dev/null @@ -1,25 +0,0 @@ -category: base -doc: | - Base class for method-specific generic imaging. - - In the majority of cases simple d-dimensional regular scan patterns are used - to probe a region-of-interest (ROI). Examples can be single point aka spot - measurements, line profiles, or (rectangular) surface mappings. - The latter pattern is the most frequently used. - - For now the base class provides for scans for which the settings, - binning, and energy resolution is the same for each scan point. -symbols: - n_images: | - Number of images in the stack. - n_y: | - Number of pixel per image in the slow direction. - n_x: | - Number of pixel per image in the fast direction. -type: group -NXem_img(NXem_method): - imaging_mode(NX_CHAR): - doc: | - Which imaging mode was used? - enumeration: [secondary_electron, backscattered_electron] - IMAGE_R_SET(NXimage_r_set): diff --git a/contributed_definitions/nyaml/NXem_method.yaml b/contributed_definitions/nyaml/NXem_method.yaml deleted file mode 100644 index afe91de973..0000000000 --- a/contributed_definitions/nyaml/NXem_method.yaml +++ /dev/null @@ -1,21 +0,0 @@ -category: base -doc: | - Base class to describe specific analysis methods in electron microscopy. - - This base class represent a template how specialized, deep, and method-specific - base classes can be defined with which an (NXem) application - definition gets equipped with specific groups to document method-specific - processing steps and report analyzed quantities. - - The template base class name :ref:`NXem_method` needs to be changed for each - method e.g. :ref:`NXem_adf`, :ref:`NXem_ebsd`, :ref:`NXem_eels`, :ref:`NXem_eds`. -# :ref:`NXem_se`, :ref:`NXem_bse`. -type: group -NXem_method(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT): - IMAGE_R_SET(NXimage_r_set): - IMAGE_C_SET(NXimage_c_set): - SPECTRUM_SET(NXspectrum_set): diff --git a/contributed_definitions/nyaml/NXem_msr.yaml b/contributed_definitions/nyaml/NXem_msr.yaml deleted file mode 100644 index 16c349ca58..0000000000 --- a/contributed_definitions/nyaml/NXem_msr.yaml +++ /dev/null @@ -1,63 +0,0 @@ -category: base -doc: | - Base class for collecting a session with a real electron microscope. - - For collecting data and experiments which are simulations of an - electron microscope use the :ref:`NXem_sim` base class. -type: group -NXem_msr(NXem_method): - em_lab(NXinstrument): - doc: | - (Meta)data of the microscope and the lab in which it stands. - - This em_lab group differs from potential em_lab groups inside - :ref:`NXevent_data_em` instances in that here the more static descriptions - are kept while changing, i.e. time-dependent pieces of information are - logged, via the em_lab group inside the desired number of instances - of NXevent_data_em. - - While using an :ref:`NXevent_data_em` instance, users should store only those - settings about a component which are relevant to understand the current - state of the component. Here, current means for the time interval which - the event covers (as it is detailed via start_time and end_time) timestamps. - - For example it is not relevant to store in each :ref:`NXevent_data_em` - electron_source group again the details of the gun type and the manufacturer - but only the high-voltage value and that only if it is different from the value - that is specified in the em_lab section for the static settings. - - In effect, this defines an information inference hierarchy which starts - in an individual :ref:`NXevent_data_em` instance followed by a probing of the - static section. - instrument_name(NX_CHAR): - doc: | - Given name of the microscope at the hosting institution. - This is an alias. Examples could be NionHermes, Titan, JEOL, - Gemini, etc. - location(NX_CHAR): - doc: | - Location of the lab or place where the instrument is installed. - Using GEOREF is preferred. - (NXfabrication): - (NXchamber): - (NXebeam_column): - (NXibeam_column): - (NXoptical_system_em): - (NXdetector): - doc: | - Description of the type of the detector. - - Electron microscopes have typically multiple detectors. - Different technologies are in use like CCD, scintillator, - direct electron, CMOS, or image plate to name but a few. - local_name(NX_CHAR): - doc: | - Instrument-specific alias/name - # it is unfortunate that for NXdetector there are already many places - # how one can specify details which could equally end up in fabrications - # we should give better guidance which option to use, pr to niac - # (NXfabrication): - (NXpump): - (NXstage_lab): - (NXevent_data_em_set): -# (NXevent_data_em): diff --git a/contributed_definitions/nyaml/NXem_sim.yaml b/contributed_definitions/nyaml/NXem_sim.yaml deleted file mode 100644 index 81fe20db1b..0000000000 --- a/contributed_definitions/nyaml/NXem_sim.yaml +++ /dev/null @@ -1,34 +0,0 @@ -category: base -doc: | - Base class for simulating electron microscopy relevant beam-matter interaction. - - The concept behind this base class is to keep it as generic as possible - that simulations of electron/ion beam interaction with matter can be - represented. This base class is envisioned as the twin of the :ref:`NXem_msr` - base class. - - It is an attempt to test the idea if at some point one might even use the - same base class template to describe measurements and computer simulations - of electron microscopy. This idea is attractive because the only practical - difference between a description of a measurement with a microscope and a - computer simulation is that the latter is typically a substantially simplified - representation of the real microscope surplus the focus of the research - in such cases on specific questions. - - Such simplification can be with respect to the optical setup, typically the - ignoring of the fact that the electron beam is produced by a complex setup - of lenses while in simulations often single Einzel lenses are considered. - Dynamics of the environment like temperature fluctuation in a lab, vibrations, - users, and multiple detectors are typically either ignored or reduced in - complexity and number and coming with idealizations to keep the simulations - focused on the specific reason questions and efficiently numerically executable. -# abTEM and other simulation packages, TEMgym, etc. -type: group -NXem_sim(NXem_method): - simulation(NXprocess): - doc: | - Details about the simulation. - # sequence_index(N): - (NXprogram): - (NXcg_geodesic_mesh): - (NXimage_r_set_diff): diff --git a/contributed_definitions/nyaml/NXroi.yaml b/contributed_definitions/nyaml/NXroi.yaml deleted file mode 100644 index a8ba2426ad..0000000000 --- a/contributed_definitions/nyaml/NXroi.yaml +++ /dev/null @@ -1,9 +0,0 @@ -category: base -doc: | - Base class to describe a region-of-interest analyzed. -type: group -NXroi(NXobject): - (NXprocess): - doc: | - Details about processing steps. - sequence_index(NX_INT):