diff --git a/contributed_definitions/NXamplifier.nxdl.xml b/contributed_definitions/NXamplifier.nxdl.xml new file mode 100644 index 0000000000..c9b719a7b1 --- /dev/null +++ b/contributed_definitions/NXamplifier.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + Base classed definition for amplifier devices. + + + + (IC, device) (NXmanufacturer?) + + + + + The number of preamplifier channels are assgined. + + + + + The number of preamplifier channels are ready tp to be used. (array for active + channels) + + + + + The output signal does not go through a feedback loop to adjust the + amplification of the amplifier. (array for active channels) + + + + + + The ratio of the amplitue of the useful signal to the amplitude of the noise in + the output signal of the amplifier. S/N=V_signal/V_noise. (array for active + channels) + + + + + (if active >1) + + + + + for reducing interferences between different signalling pathways + + + + + The spectrum of frequency it can amplify, from its lowest to highest frequency + limits. + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml new file mode 100644 index 0000000000..923e1a1373 --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -0,0 +1,191 @@ + + + + + + Application definition for a configuration of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ + + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace software using NeXus. + + + + + + + + + + + + + + + Specification of the tomographic reconstruction used for this analysis. + Typically, reconstructions in the field of atom probe tomography are communicated via + files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + + + + + Name of the node which resolves the reconstructed + ion position values to use for this analysis. + + + + + Name of the node which resolves the mass-to-charge-state ratio + values for each reconstructed ion to use for this analysis. + + + + + + Specification of the ranging definitions used for this analysis. + + Indices start from 1. The value 0 is reserved for the null model of unranged positions whose + iontype is unknown_type. The value 0 is also reserved for voxels that lie outside the dataset. + + + + + + + + Name of the (parent) node directly below which the ranging definitions for + (molecular) ions are stored. + + + + + + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + + + Edge length of cubic voxels building the 3D grid that is used for discretizing + the point cloud. + + + + + + Optional step during which the subsequent segmentation step is prepared with the aim to eventually + reduce the dimensionality of the chemical space in which the machine learning model works. + + In this step a supervised reduction of the dimensionality of the chemical space is quantified using + the (Gini) feature importance of each element to suggest which columns of the composition matrix + should be taken for the subsequent segmentation step. + + + + Was the automated phase assignment used? + + + + + Estimated guess for which a Gaussian mixture model is evaluted to preprocess a result that + is subsequenty post-processed with a random_forest_classifier to lower the number of + dimensions in the chemical space to the subset of trunc_species many elements with the + highest feature importance. + + + + + The number of elements to use for reducing the dimensionality. + + + + + Configuration for the random forest classification model. + + + + + + Step during which the voxel set is segmented into voxel sets with different + chemical composition. + + + + A principal component analysis of the chemical space to guide a decision into how many sets of voxels + with different chemical composition the machine learning algorithm suggests to split the voxel set. + + + + + The decision is guided through the evalution of the information criterion + minimization. + + + + The maximum number of chemical classes to probe with the Gaussian mixture model + with which the voxel set is segmented into a mixture of voxels with that many different + chemical compositions. + + + + + Configuration for the Gaussian mixture model that is used in the segmentation + step. + + + + + + + Step during which the chemically segmented voxel sets are analyzed for their + spatial organization. + + + + Configuration for the DBScan algorithm that is used in the clustering step. + + + + The maximum distance between voxel pairs in a neighborhood to be considered + connected. + + + + + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + + + + + + + diff --git a/contributed_definitions/NXapm_compositionspace_results.nxdl.xml b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml new file mode 100644 index 0000000000..7bf1c7912e --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -0,0 +1,390 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The dimensionality of the grid. + + + + + Total number of voxels. + + + + + Total number of ions in the reconstructed dataset. + + + + + Application definition for results of the CompositionSpace tool used in atom probe. + + * `A. Saxena et al. <https://www.github.com/eisenforschung/CompositionSpace.git>`_ + + This is an application definition for the common NFDI-MatWerk/FAIRmat infrastructure + use case IUC09 that explores how to improve the organization and results storage of the + CompositionSpace software using NeXus. + + + + + + + + + + + + + + + + + + + + + + Configuration file that was used in this analysis. + + + + + + + + + + + Step during which the point cloud is discretized to compute element-specific composition fields. + Iontypes are atomically decomposed to correctly account for the multiplicity of each element that + was ranged for each ion. + + Using a discretization grid that is larger than the average distance between reconstructed ion positions + reduces computational costs. This is the key idea of the CompositionSpace tool compared to other methods + used in atom probe for characterizing microstructural features using the ion position data directly. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Position of each cell in Euclidean space. + + + + + + + + + Discrete coordinate of each voxel. + + + + + + + + + + For each ion, the identifier of the voxel into which the ion binned. + + + + + + + + + Total number of weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms. + + + + + + + + + Chemical symbol of the element from the periodic table. + + + + + Element-specific weight (counts for discretization with a rectangular transfer function) + for the occupancy of each voxel with atoms of this element. + + + + + + + + + + Optional step during which the subsequent segmentation step is prepared to + improve the segmentation. + + + + + + + + + + + + + + Element identifier stored sorted in descending order of feature importance. + + + + + + + Axis caption + + + + + + Element relative feature importance stored sorted in descending order of feature + importance. + + + + + + + Axis caption + + + + + + + + Step during which the voxel set is segmented into voxel sets with different + chemical composition. + + + + PCA in the chemical space (essentially composition correlation analyses). + + + + + + + + + + + + + + + Explained variance values + + + + + + + + Elements identifier matching those from ENTRY/voxelization/elementID as the + principal component analysis. + + + + + + + + + + Information criterion minimization. + + + + + + + + + + Results of the Gaussian mixture analysis for n_components equal to n_ic_cluster. + + + + n_components argument of the Gaussian mixture model. + + + + + y_pred return values of the computation. + + + + + + + + + Information criterion as a function of number of n_ic_cluster aka dimensions. + + + + + + + + Akaike information criterion values + + + + + + + + Bayes information criterion values + + + + + + + + Actual n_ic_cluster values used + + + + + + + + + + + Step during which the chemically segmented voxel sets are analyzed for their spatial organization + into different spatial clusters of voxels in the same chemical set but representing individual object + not-necessarily watertight or topologically closed objects built from individual voxels. + + + + + + + + + + Respective DBScan clustering result for each segmentation/ic_opt case. + + + + + + The maximum distance between voxel pairs in a neighborhood to be considered + connected. + + + + + The number of voxels in a neighborhood for a voxel to be considered as a core + point. + + + + + Raw label return values + + + + + + + + Voxel identifier + + Using these identifiers correlated element-wise with the values in the label array + specifies for which voxel in the grid clusters from this process were found. + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml new file mode 100644 index 0000000000..21897a43b9 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -0,0 +1,384 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of clustering algorithms used. + + + + + Number of different iontypes to distinguish during clustering. + + + + + Application definition for a configuration file of the paraprobe-clusterer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + How many cluster_analysis tasks should the tool execute. + + + + + This process maps results from a cluster analysis made with IVAS / AP Suite + into an interoperable representation. IVAS / AP Suite usually exports such results + as a list of reconstructed ion positions with one cluster label per position. + These labels are reported via the mass-to-charge-state-ratio column of what is effectively + a binary file that is formatted like a POS file but cluster labels written out using floating + point numbers. + + + + + + + + + + + + File with the results of the cluster analyses that was computed with IVAS / AP suite + (e.g. maximum-separation method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_). + The information is stored in an improper (.indexed.) POS file as a matrix of floating + point quadruplets, one quadruplet for each ion. The first three values of each + quadruplet encode the position of the ion. The fourth value is the integer identifier + of the cluster encoded as a floating point number. + + + + + + + + + Specifies if paraprobe-clusterer should use the evaporation_ids from reconstruction + for recovering for each position in the :ref:`NXserialized` results the closest matching position + (within floating point accuracy). This can be useful when users wish to recover the + original evaporation_id, which IVAS /AP Suite drops when writing their *.indexed.* cluster + results POS files that is referred to results. + + + + + + + This process performs a cluster analysis on a + reconstructed dataset or a ROI within it. + + + + + + + + + + + + + + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How should iontypes be considered during the cluster analysis. + + The value resolve_all will set an ion active + in the analysis regardless of which iontype it is. + + The value resolve_unknown will set an ion active + when it is of the UNKNOWNTYPE. + + The value resolve_ion will set an ion active + if it is of the specific iontype, irregardless of its nuclide structure. + + The value resolve_element will set an ion active and account as many times + for it, as the (molecular) ion contains atoms of elements in the whitelist + ion_query_nuclide_vector. + + The value resolve_isotope will set an ion active and account as many times + for it, as the (molecular) ion contains nuclides in the whitelist + ion_query_nuclide_vector. + + In effect, ion_query_nuclide_vector acts as a whitelist to filter which ions are + considered as source ions of the correlation statistics and how the multiplicity + of each ion will be factorized. + + This is relevant as in atom probe we have the situation that an ion of a molecular + ion with more than one nuclide, say Ti O for example is counted potentially several + times because at that position (reconstructed) position it has been assumed that + there was a Ti and an O atom. This multiplicity affects the size of the feature and its + chemical composition. + + + + + + + + + Matrix of nuclide vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + + + + + + + + + + Settings for DBScan clustering algorithm. For original details about the + algorithm and (performance-relevant) details consider: + + * `M. Ester et al. <https://dx.doi.org/10.5555/3001460.3001507>`_ + * `M. Götz et al. <https://dx.doi.org/10.1145/2834892.2834894>`_ + + For details about how the DBScan algorithms is the key behind the + specific modification known as the maximum-separation method in the + atom probe community consider `E. Jägle et al. <https://dx.doi.org/10.1017/S1431927614013294>`_ + + + + Strategy how a set of cluster analyses with different parameter is executed: + + * For tuple as many runs are performed as parameter values have been defined. + * For combinatorics individual parameter arrays are looped over. + + As an example we may provide ten entries for eps and three entries for min_pts. + If high_throughput_method is set to tuple, the analysis is invalid because we have + an insufficient number of min_pts values to pair them with our ten eps values. + By contrast, if high_throughput_method is set to combinatorics, the tool will run three + individual min_pts runs for each eps value, resulting in a total of 30 analyses. + + A typical example from the literature `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ + can be instructed via setting eps to an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True), + one min_pts value that is equal to 1, and high_throughput_method set to combinatorics. + + + + + + + + + Array of epsilon (eps) parameter values. + + + + + + + + Array of minimum points (min_pts) parameter values. + + + + + + + + + + Settings for the HPDBScan clustering algorithm. + + * L. McInnes et al. <https://dx.doi.org/10.21105/joss.00205>`_ + * scikit-learn hdbscan library `<https://hdbscan.readthedocs.io/en/latest/how_hdbscan_works.html>`_ + + See also this documentation for details about the parameter. + Here we use the terminology of the hdbscan documentation. + + + + Strategy how runs with different parameter values are composed, + following the explanation for higih_throughput_method of dbscan. + + + + + + + + + Array of min_cluster_size parameter values. + + + + + + + + Array of min_samples parameter values. + + + + + + + + Array of cluster_selection parameter values. + + + + + + + + Array of alpha parameter values. + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml new file mode 100644 index 0000000000..763a37b1c9 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -0,0 +1,299 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Number of clusters found. + + + + + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + + + + + + + + + + + + + + + + Results of a DBScan clustering analysis. + + + + The epsilon (eps) parameter used. + + + + + The minimum points (min_pts) parameter used. + + + + + Number of members in the set which is partitioned into features. + Specifically, this is the total number of targets filtered from the + dataset, i.e. typically the number of clusters which is usually not and + for sure not necessarily the total number of ions in the dataset. + + + + + Which identifier is the first to be used to label a cluster. + + The value should be chosen in such a way that special values can be resolved: + * identifier_offset - 1 indicates an object belongs to no cluster. + * identifier_offset - 2 indicates an object belongs to the noise category. + + Setting for instance identifier_offset to 1 recovers the commonly used + case that objects of the noise category get the value of -1 and points of the + unassigned category get the value 0. + + + + + The evaporation (sequence) identifier (aka evaporation_id) to figure out + which ions from the reconstruction were considered targets. The length + of this array is not necessarily n_ions. + Instead, it is the value of cardinality. + + + + + + + + + The number of solutions found for each target. Typically, + this value is 1 in which case the field can be omitted. + Otherwise, this array is the concatenated set of values of solution + tuples for each target that can be used to decode model_labels, + core_sample_indices, and weight. + + + + + + + + The raw labels from the DBScan clustering backend process. + The length of this array is not necessarily n_ions. + Instead, it is typically the value of cardinality provided that each + target has only one associated cluster. If targets are assigned to + multiple cluster this array is as long as the total number of solutions + found and + + + + + + + + The raw array of core sample indices which specify which of the + targets are core points. + + + + + + + + Numerical label for each target (member in the set) aka cluster identifier. + + + + + + + + Categorical label(s) for each target (member in the set) aka cluster name(s). + + + + + + + + Weights for each target that specifies how probable the target is assigned to + a specific cluster. + + For the DBScan algorithm and atom probe tomography this value is the + multiplicity of each ion with respect to the cluster. That is how many times + should the position of the ion be accounted for because the ion is e.g. a + molecular ion with several elements or nuclides of requested type. + + + + + + + + + Are targets assigned to the noise category or not. + + + + + + + + + Are targets assumed a core point. + + + + + + + + In addition to the detailed storage which members were grouped to which + feature here summary statistics are stored that communicate e.g. how many + cluster were found. + + + + + Total number of targets in the set, i.e. ions that were filtered + and considered in this cluster analysis. + + + + + Total number of members in the set which are categorized as noise. + + + + + Total number of members in the set which are categorized as a core point. + + + + + Total number of clusters (excluding noise and unassigned). + + + + + + Numerical identifier of each feature aka cluster_identifier. + + + + + + + + Number of members for each feature. + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml new file mode 100644 index 0000000000..e7d6d7917b --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -0,0 +1,202 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Application definition for a configuration file of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies for which point the tool will compute distances. + + The value *default* configures that distances are computed for all points. + The value *skin* configures that distances are computed only for those + points which are not farther away located to a triangle than + threshold_distance. + + + + + + + + + Maximum distance for which distances are + computed when *method* is *skin*. + + + + + + How many triangle sets to consider. + Multiple triangle sets can be defined which are + composed into one joint triangle set for the analysis. + + + + + Each triangle_set that is referred to here should be a face_list_data_structure, + i.e. an array of (n_vertices, 3) of NX_FLOAT for vertex coordinates, an (n_facets, 3) + array of NX_UINT incident vertices of each facet. Vertex indices are assumed to + start at zero and must not exceed n_vertices - 1, i.e. the identifier_offset is 0. + Facet normal have to be provided as an array of (n_facets, 3) of NX_FLOAT. + + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of vertex normal vectors for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of facet normal vectors for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of identifier for the triangles in that triangle_set. + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml new file mode 100644 index 0000000000..011214db13 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -0,0 +1,202 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of points, i.e. ions in the reconstruction. + + + + + The total number of triangles in the set. + + + + + Application definition for results files of the paraprobe-distancer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The paraprobe-distancer tool can be used for the computing of the shortest Euclidean distance for each + member of a set of points against a set of triangles. In contrast to most approaches in atom probe where the + distance is computed as the projected distance, this tool evaluates robustly the exact distance between + a point and a triangle. + + Triangles can represent for instance the facets of a triangulated surface mesh like those returned by + paraprobe-surfacer or any other set of triangles. Triangles do not have to be connected. + + Currently, paraprobe-distancer does not check if the respectively specified triangle sets are consistent, + what their topology is, or whether or not these triangles are consistently oriented. + + + + + + + + + + + + + + + + + + + + + + + + + + + The shortest analytical distance of each point to their + respectively closest triangle from the joint triangle set. + + + + + + + + For each point the identifier of the triangle for which the + shortest distance was found + + + + + + + + A support field to enable the visualization of each point + by an explicit identifier on the interval [0, n_ions - 1]. + The field can be used to visualize the points as a function + of their distance to the triangle set (e.g. via XDMF/Paraview). + + + + + + + + A bitmask that identifies which of the distance values is + assumed to have a consistent sign because the closest + triangle had a consistent outer unit normal defined. + + For points whose bit is set to 0 the distance is correct + but the sign is not reliable. + + + + Number of triangles covered by the mask. + + + + + Bitdepth of the elementary datatype that is used to store + the information content of the mask (typically 8 bit, uint8). + + + + + The content of the mask. Like for all masks used in the tools + of the paraprobe-toolbox, padding is used when number_of_objects + is not an integer multiple of bitdepth. If padding is used, + padded bits are set to 0. + + + + + + + + + A bitmask that identifies which of the triangles in the set were + considered when certain triangles have been filtered out. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml new file mode 100644 index 0000000000..efdbdf9aeb --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -0,0 +1,278 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of entries + + + + + Application definition for a configuration file of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + How many v_v_spatial_correlation tasks should the tool execute. + + + + + Tracking volume_volume_spatial_correlations (v_v) is the process of building logical + relations between objects, their proximity and eventual volumetric intersections. + Here, objects are assumed to be represented as a set of triangulated surface meshes. + + Volumetric overlap and proximity of volumetric features is identified for members of + sets of features to members of other sets of volumetric features. Specifically, for each time + step :math:`k` pairs of sets are compared: + Members of a so-called current_set to members of a so-called next_set. + Members can be different types of volumetric features. + + + + + Specifies the method whereby to decide if two objects intersect volumetrically. + For reasons which are detailed in the supplementary material of `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, + it is assumed by default that two objects intersect if they share at least one ion with the same evaporation ID (shared_ion). + + Alternatively, with specifying tetrahedra_intersections, the tool can perform an intersection analysis which attempts to + tetrahedralize first each polyhedron. If successful, the tool then checks for at least one pair of intersecting tetrahedra + to identify if two objects intersect or not. However, we found that these geometrical analyses can result in corner + cases which the tetrahedralization library used in the tests (TetGen) was not unable to tetrahedralize successfully. + These cases were virtually always associated with complicated non-convex polyhedra which had portions + of the mesh that were connected by almost point like tubes of triangles. + + Finding more robust methods for computing intersections between not necessarily convex polyhedra might improve + the situation in the future. For practical reasons we have thus deactivated the functionality of tetrahedra-tetrahedron + intersections in paraprobe-intersector. + + + + + + + + Specifies if the tool evaluates if objects intersect volumetrically. + + + + + Specifies if the tool evaluates if objects lay closer to one another than + threshold_proximity. + + + + + Specifies if the tool evaluates, provided that all (preprocessing tasks were successful), how intersecting + or proximity related objects build sub-graphs. This is the feature that was used in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_ + for the high-throughput analyses of how many objects are coprecipitates in the sense that they are single, + duplet, triplet, or high-order local groups. + + + + + + The maximum Euclidean distance between two objects below which they are + considered within proximity. + + + + + Specifies if the tool stores the so-called forward relations between nodes representing members of the + current_set to nodes representing members of the next_set. + + + + + Specifies if the tool stores the so-called backward relations between nodes representing members of the + next_set to nodes representing members of the current_set. + + + + + Current set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the current_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + + + + + + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features, key is that they were all generated for one set, here the + current_set. + + + + + Name of the (NeXus)/HDF5 file which contains triangulated surface meshes of the + members of the set as instances of NXcg_polyhedron_set. + + + + Descriptive category explaining what these features are. + + + + + + + + + + + + + + + + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + + + + + + Array of identifier whereby the path to the geometry data can be interferred + automatically. + + + + + + + + + + Next set stores a set of members, meshes of volumetric features, + which will be checked for proximity and/or volumetric intersection, + to members of the next_set. + The meshes were generated as a result of some other meshing process. + + + + This identifier can be used to label the current set. The label effectively can be interpreted as the time/iteration (i.e. :math:`k + 1`) + step when the current set was taken (see `M. Kühbach et al. 2022 <https://arxiv.org/abs/2205.13510>`_). + + + + + + The total number of distinguished feature sets featureID. + It is assumed that the members within all these featureID sets + are representing a set together. As an example this set might represent + all volumetric_features. However, users might have formed + a subset of this set where individuals were regrouped. + For paraprobe-nanochem this is the case for objects and proxies. + Specifically, objects are distinguished further into those far + from and those close to the edge of the dataset. + Similarly, proxies are distinguished further into those far + from and those close to the edge of the dataset. + So while these four sub-sets contain different so-called types of + features key is that they were all generated for one set, here the + next_set. + + + + + + Descriptive category explaining what these features are. + + + + + + + + + + + + + + + Absolute path to the group with geometry data in the HDF5 file referred to by + path. + + + + + + Array of identifier whereby the path to the geometry data can be interferred + automatically. + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml new file mode 100644 index 0000000000..55b2aeea3c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -0,0 +1,274 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of links pointing from current to next. + + + + + The total number of links pointing from next to current. + + + + + The total number of members in the current_set. + + + + + The total number of members in the next_set. + + + + + The total number of cluster found for coprecipitation analysis. + + + + + The number of rows in the table/matrix for coprecipitation statistics. + + + + + Application definition for results files of the paraprobe-intersector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + The results of an overlap/intersection analysis. + + + + + A matrix of feature_identifier that specifies which named features + from the current_set have directed link(s) pointing to which named + feature(s) from the next_set. + + + + + + + + + For each link/pair in current_to_next a characterization whether the + link is due to volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). + + + + + + + + A matrix of feature_identifier which specifies which named feature(s) + from the next_set have directed link(s) pointing to which named + feature(s) from the current_set. Only if the mapping whereby the + links are defined is symmetric it holds that next_to_current maps + the links for current_to_next in just the opposite direction. + + + + + + + + + For each link/pair in next_to_current a characterization whether the + link is due to a volumetric overlap (0x00 == 0), proximity (0x01 == 1), + or something else unknown (0xFF == 255). + + + + + + + + For each pair of links in current_to_next the volume of the + intersection, i.e. how much volume do the two features share. + If features do not intersect the volume is zero. + + + + + + + + During coprecipitation analysis the current and next set are analyzed + for links in a special way. Three set comparisons are made. Members + of the set in each comparison are analyzed for overlap and proximity: + + The first comparison is the current_set against the current_set. + The second comparison is the next_set against the next_set. + The third comparison is the current_set against the next_set. + + Once the (forward) links for these comparisons are ready, pair relations + are analyzed with respect to which objects with feature_identifier(s) + cluster in identifier space. Thereby, a logical connection (link) is + established between the features in the current_set and the next_set. + Recall that these two sets typically represent different features + within an observed system for otherwise the same parameterization. + + Examples include two sets of e.g. precipitates with differing + chemical composition that were characterized in the same material + volume representing a snapshot of an e.g. microstructure at the same + point in time. Researchers may have performed two analyses, one to + characterize precipitates A and another one for percipitates B. + + Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + the precipitates' spatial arrangement. + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the current_set. + + + + + + + + + Matrix of feature_identifier and cluster_identifier pairs which + encodes the cluster to which each feature_identifier was assigned. + Here for features of the next_set. + + + + + + + + + The identifier (names) of the cluster. + + + + + + + + Pivot table as a matrix. + The first column encodes how many members from the current_set + are in each cluster, one row per cluster. + + The second column encodes how many members from the next_set + are in each cluster, in the same row per cluster respectively. + + The third column encodes the total number of members in the cluster. + + + + + + + + + Pivot table as a matrix. + + The first column encodes the different types of + clusters based on their number of members in the sub-graph. + + The second column encodes how many clusters with + as many members exist. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml new file mode 100644 index 0000000000..08a2b878ba --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -0,0 +1,1040 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + How many iontypes does the delocalization filter specify. + + + + + How many grid_resolutions values. + + + + + How many kernel_variance values. + + + + + How many disjoint control points are defined. + + + + + How many iontypes does the interface meshing iontype filter specify. + + + + + How many DCOM iterations. + + + + + Maximum number of atoms per molecular ion. + + + + + Number of cylinder ROIs to place for oned_profile if no feature mesh is used. + + + + + Application definition for a configuration file of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + Discretization and distributing of the ion point cloud on a 3D grid + to enable continuum-scale analyses. + + By default, the tool computes a full kernel density estimation of decomposed + ions to create one discretized field for each element. + + One delocalization task configures a parameter sweep with at least one + delocalization. The total number of runs depends on the number of + grid_resolution and kernel_variance values. For example, setting two grid_resolutions + and three kernel_variance will compute six runs. Two sets of three with the first set using + the first grid_resolutions and in sequence the kernel_variance respectively. + + + + + + + + + + + + + + + + + + + + + + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Compute delocalization or load an existent one from input. + + + + + + + + + Serialized result of an already computed delocalization which is for performance + reasons here just loaded and not computed again. + + + + + + + + Absolute path in the (HDF5) file that points to the group within which + individual delocalization results are stored. + + + + + + + Matrix of nuclides representing how iontypes should be accounted for during + the delocalization. This is the most general approach to define if and how many + times an ion is to be counted. The tool performs a so-called atomic decomposition + of all iontypes, i.e. the tool analyses from how many atoms of each nuclide + or element respectively an (molecular) ion is built from. + + Taking the hydroxonium H3O+ molecular ion as an example: + It contains hydrogen and oxygen atoms. The multiplicity of hydrogen + is three whereas that of oxygen is one. Therefore, the respective atomic decomposition + analysis prior to the iso-surface computation adds three hydrogen counts for each + H3O+ ion. + + This is a practical solution which accepts that on the one hand not every bond is + broken during an atom probe experiment but also that ions may react further during + their flight to the detector. The exact details depend on the local field conditions, + quantum mechanics of possible electron transfer and thus the detailed trajectory + of the system and its electronic state. + + The detection of molecular ions instead of always single atom ions only is the + reason that an atom probe experiment tells much about field evaporation physics + but also faces an inherent loss of information with respect to the detailed spatial + arrangement that is independent of other imprecisions such as effect of limited + accuracy of reconstruction protocols and their parameterization. + + Unused values in each row of the matrix are nullified. + Nuclides are identified as hashed nuclide (see :ref:`NXion`) for further details. + + + + + + + + + Array of edge lengths of the cubic cells used for discretizing the reconstructed dataset + on a cuboidal 3D grid (:ref:`NXcg_grid`). The tool performs as many delocalization + computations as values are specified in grid_resolution. + + + + + + + + Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of cubic voxel + beyond which the Gaussian Ansatz function will be truncated. Intensity outside + the kernel is factorized into the kernel via a normalization procedure. + + + + + Array of variance values :math:`\sigma` of the Gaussian Ansatz kernel + (:math:`\sigma_x := \sigma`, :math:`\sigma_x = \sigma_y = 2 \cdot \sigma_z`). + The tool performs as many delocalization computations as values are specified + in kernel_variance. + + + + + + + + How should the results of the kernel-density estimation be normalized into quantities. + By default, the tool computes the total number (intensity) of ions or elements. + Alternatively, the tool can compute the total intensity, the composition, + or the concentration of the ions/elements specified by the nuclide_whitelist. + + + + + + + + + + Specifies if the tool should report the delocalization 3D field values. + + + + + Configuration of the set of iso-surfaces to compute using that delocalization. + Such iso-surfaces are the starting point for a reconstruction of so-called objects or + (microstructual) features. Examples of scientific relevant are (line features e.g. dislocations + poles, surface features such as interfaces, i.e. phase and grain boundaries, or volumetric + features such as precipitates. + Users should be aware that reconstructed datasets in atom probe are a model and may face + inaccuracies and artifacts that can be mistaken incorrectly as microstructural features. + + + + As it is detailed in `M. Kühbach et al. <https://arxiv.org/abs/2205.13510>`_, the handling of + triangles at the surface (edge) of the dataset requires special attention especially for + composition-normalized delocalization. Here, it is possible that the composition + increases towards the edge of the dataset because the quotient of two numbers + that are both smaller than one is larger instead of smaller than the counter. + + By default, the tool uses a modified marching cubes algorithm of Lewiner et al. + which detects if voxels face such a situation. In this case, no triangles are generated + for such voxels. + + Alternatively, keep_edge_triangles instructs the tool to not remove triangles at the + edge of the dataset at the cost of bias. When using this keep_edge_triangles users + should understand that all features in contact with the edge of the dataset get usually + artificial enlarged. Consequently, triangulated surface meshes of these objects are + closed during the marching. However, this closure is artificial and can biased shape + analyses for those objects. This also holds for such practices that are offered in + proprietary software like IVAS / AP Suite. The situation is comparable to analyses + of grain shapes via orientation microscopy from electron microscopy or X-ray + diffraction tomography. Features at the edge of the dataset may have not been + captured fully. + + Thanks to collaboration with V. V. Rielli and S. Primig from the Sydney atom probe group, + paraprobe-nanochem implements a complete pipeline to process features at the edge of the + dataset. Specifically, these are modelled and replaced with closed polyhedral objects using + an iterative mesh and hole-filling procedures with fairing operations. + + The tool bookkeeps such objects separately to lead the decision whether or not to + consider these objects to the user. Users should be aware that results from fairing operations + should be compared to results from analyses where all objects at the edge + of the dataset have been removed. Furthermore, users should be careful with overestimating + the statistical significance of their dataset especially when using atom probe when they + use their atom probe result to compare different descriptors. Even though a dataset may + deliver statistically significant results for compositions, this does not necessarily mean that + same dataset will also yield statistically significant and insignificantly biased results for + 3D object analyses! + + Being able to quantify these effects and making atom probers aware of these subtleties + was one of the main reasons why the paraprobe-nanochem tool was implemented. + + + + + + + + + The ion-to-surface distance that is used in the analyses of features to identify whether + these are laying inside the dataset or close to the surface (edge) of the dataset. + + If an object has at least one ion with an ion-to-surface-distance below this threshold, + the object is considered close to the edge of the dataset. The tool uses a distance-based + approach to solve the in general complicated and involved treatment of computing + volumetric intersections between closed 2-manifolds that are not necessarily convex. + The main practical reason is that such computational geometry analyses face numerical + robustness issues as a consequence of which a mesh can be detected as being completely + inside another mesh although in reality it is only :math:`\epsilon`-close only, i.e. almost + touching only the edge (e.g. from inside). + + Practically, humans would likely still state in such case that the object is close to the + edge of the dataset; however mathematically the object is indeed completely inside. + In short, a distance-based approach is rigorous and flexible. + + + + + Iso-contour values. For each value, the tool computes an iso-surface and performs + subsequent analyses for each iso-surface. The unit depends on the choice for the + normalization of the accumulated ion intensity values per voxel: + + * total, total number of ions, irrespective their iontype + * candidates, total number of ions with type in the isotope_whitelist. + * composition, candidates but normalized by composition, i.e. at.-% + * concentration, candidates but normalized by voxel volume, i.e. ions/nm^3 + + + + + Specifies if the tool should report the triangle soup which represents each triangle of the + iso-surface complex. The resulting set of triangles is colloquially referred to as a soup + because different sub-set may not be connected. + + Each triangle is reported with an ID specifying to which triangle cluster (with IDs starting at zero) + the triangle belongs. The clustering of triangles within the soup is performed with a + modified DBScan algorithm. + + + + + Specifies if the tool should analyze for each cluster of triangles how they can be combinatorially + processed to describe a closed polyhedron. Such a closed polyhedron (not-necessarily convex!) + can be used to describe objects with relevance in the microstructure. + + Users should be aware that the resulting mesh does not necessarily represent the original precipitate. + In fact, inaccuracies in the reconstructed positions cause inaccuracies in all downstream processing + operations. Especially the effect on one-dimensional spatial statistics like nearest neighbor correlation + functions were discussed in the literature `B. Gault et al. <https://doi.org/10.1017/S1431927621012952>`_. + + In continuation of these thoughts, this applies also to reconstructed objects. + A well-known example is the discussion of shape deviations of scandium-rich precipitates in aluminium alloys + which in reconstructions may appear as ellipsoids although they should be indeed almost spherical + provided their size is larger than the atomic length scale. + + + + + Specifies if the tool should report a triangulated surface mesh for each identified closed polyhedron. + It is common that a marching cubes algorithm creates iso-surfaces with a fraction of tiny sub-complexes + (e.g. small isolated tetrahedra). + + These can be small tetrahedra/polyhedra about the center of a voxel of the support grid + on which marching cubes operates. Such objects may not contain an ion; especially when considering + that delocalization procedures smoothen the positions of the ions. Although these small objects are + interesting from a numerical point of view, scientists may argue they are not worth to be reported because + a microstructural feature should contain at least a few atoms to become relevant. + Therefore, paraprobe-nanochem by default does not report closed objects which bound a volume + that contains no ion. + + + + + Specifies if the tool should report properties of each closed polyhedron, such + as volume and other details. + + + + + Specifies if the tool should report for each closed polyhedron an approximately optimal bounding box + fitted to all triangles of the surface mesh of the object and ion positions inside or on the surface of the mesh. + This bounding box informs about the closed object's shape (aspect ratios). + + Users should be aware that the choice of the algorithm to compute the bounding box can have an + effect on aspect ratio statistics. It is known that computing the true optimal bounding box of in 3D + is an :math:`\mathcal{O}^3`-time-complex task. The tool uses well-established approximate algorithms + of the Computational Geometry Algorithms Library (CGAL). + + + + + Specifies if the tool should report for each closed polyhedron all evaporation IDs of those ions which + lay inside or on the boundary of the polyhedron. This information is used by the paraprobe-intersector + tool to infer if two objects share common ions, which is then understood as that the two objects intersect. + + Users should be aware that two arbitrarily closed polyhedra in three-dimensional space can intersect + but not share a common ion. In fact, the volume bounded by the polyhedron has sharp edges and flat + face(t)s. When taking two objects, an edge of one object may for instance pierce into the surface of + another object. In this case the objects partially overlap / intersect volumetrically; however this piercing + might be so small or happening in the volume between two reconstructed ion positions. Consequently, + sharing ions is a sufficient but not a necessary condition for interpreting (volumetric) intersections + between objects. + + Paraprobe-intersector implements a rigorous alternative to handle such intersections using a tetrahedralization + of closed objects. However, in many practical cases, we found through examples that there are polyhedra (especially when they are non-convex and have almost point-like) connected channels, where + tetrahedralization libraries have challenges dealing with. In this case, checking intersections + via shared_ions is a more practical alternative. + + + + + Specifies if the tool should report if a (closed) object has contact with the surface aka edge of the dataset. + For this the tool currently inspects if the shortest distance between the set of triangles of the triangulated + surface mesh and the triangles of the edge model is larger than edge_threshold. + If this is the case, the object is assumed to be deeply embedded in the interior of the dataset. + Otherwise, the object is considered to have an edge contact, i.e. it shape is likely affected by the edge. + + + + + Specifies if the tool should analyze a closed polyhedron (aka proxy) for each cluster of triangles whose + combinatorial analysis according to has_object returned that the object is not a closed polyhedron. + Such proxies are closed via iterative hole-filling, mesh refinement, and fairing operations. + + Users should be aware that the resulting mesh does not necessarily represent the original feature. + In most cases objects, precipitates in atom probe end up as open objects because they have been + clipped by the edge of the dataset. Using a proxy is in this case a strategy to still be able to account + for these objects. However, users should make themselves familiar with the consequences and + potential biases which this can introduce into the analysis. + + + + + Like has_object_geometry but for the proxies. + + + + + Like has_object_properties but for the proxies. + + + + + Like has_object_obb but for the proxies. + + + + + Like has_object_ions but for the proxies. + + + + + Like has_object_edge_contact but for the proxies. + + + + + Specifies if the tool should report for each closed object a (cylindrical) region-of-interest (ROI) that gets + placed, centered, and aligned with the local normal for each triangle of the object. + + + + + Specifies if the tool should report for each ROI that was placed at a triangle of each object if this ROI intersects + with the edge the dataset. Currently, the tool supports cylindrical ROIs. A computational geometry test is + performed to check for a possible intersection of each ROI with the triangulated surface mesh that is defined + via surface. Results of this cylinder-set-of-triangles intersection are interpreted as follows: + If the cylinder intersects with at least one triangle of the surface (mesh) the ROI is assumed to make edge contact. + Otherwise, the ROI is assumed to make no edge contact. + + Users should note that this approach does not work if the ROI is laying completely outside the dataset as also + in this case the cylinder intersects with any triangle. However, for atom probe this case is practically irrelevant + provided constructions such as alpha shapes or alpha wrappings (such as paraproeb-surfacer does) about the + ions of the entire reconstructed volume are used. + + + + + + + + Use a principle component analysis (PCA) to mesh a single free-standing interface patch within + the reconstructed volume that is decorated by ions of specific iontypes (e.g. solute atoms). + + Interface_meshing is a typical starting point for the quantification of Gibbsian interfacial excess + in cases when closed objects constructed from patches e.g. iso-surfaces are not available or + when there is no substantial or consistently oriented concentration gradients across an interface + patch. The functionality can also be useful when the amount of latent crystallographic information + within the point cloud is insufficient or when combined with interface_meshing based on ion density + traces in field-desorption maps (see `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ + and `A. Breen et al. <https://github.com/breen-aj/detector>`_ for details). + + Noteworthy to mention is that the method used is conceptually similar to the work of `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ and related work (DCOM algorithm) by `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_. Compared to these implementations + paraprobe-nanochem uses inspection functionalities which detect potential geometric + inconsistencies or self-interactions of the evolved DCOM mesh. + + + + + + + + + + + + + + + + + + + + + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How is the PCA initialized: + + * default, means based on segregated solutes in the ROI + * control_point_file, means based on reading an external list of + control points, currently coming from the Leoben APT_Analyzer. + + The control_point_file is currently expected with a specific format. + The Leoben group lead by L. Romaner has developed a GUI tool `A. Reichmann et al. <https://github.com/areichm/APT_analyzer>`_ creates a control_point_file that + can be parsed by paraprobe-parmsetup-nanochem to match the here required + formatting in control_points. + + + + + + + + + Details about the control point file used. + + + + + + + + X, Y, Z position matrix of disjoint control points. + + + + + + Method used for identifying and refining the location of the interface. Currently, + paraprobe-nanochem implements a PCA followed by an iterative loop of isotropic + mesh refinement and DCOM step(s), paired with self-intersection detection. + + + + + + + + Specify those nuclides which the tool should inspect iontypes for if they contain such nuclides. + If this is the case ions of such type are taken with the number of nuclides of this multiplicity found. + The atoms of these ions are assumed to serve as useful markers for locating the interface and + refining the interface mesh. + + + + + + + + + Array of nuclide iontypes to filter. + + + + + + + + + + How many times should the DCOM and mesh refinement be applied? + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify how the initial triangles of the mesh should be iteratively + refined by edge splitting and related mesh refinement operations. + + + + + + + + Array of decreasing positive not smaller than one nanometer real values + which specify the radius of the spherical region of interest within which the + DCOM algorithm decides for each vertex how the vertex might be relocated. + + The larger it is the DCOM radius in relation to the target_edge_length the more + likely it becomes that vertices will be relocated so substantially that triangle + self-intersections may occur. The tool detects these and stops in a controlled + manner so that the user can repeat the analyses with using a different parameterization. + + + + + + + + Array of integers which specify for each DCOM step how many times the mesh + should be iteratively smoothened. Users should be aware that all three arrays + target_edge_length, target_dcom_radius, and target_smoothing_step are interpreted + in the same sequence, i.e. the zeroth entry of each array specifies the respective + parameter values to be used in the first DCOM iteration. The first entry of each array + those for the second DCOM iteration and so on and so forth. + + + + + + + + + Analysis of one-dimensional profiles in ROIs placed in the dataset. + Such analyses are useful for quantifying interfacial excess or for + performing classical composition analyses. + + The tool will test for each ROIs if it is completely embedded in the dataset. + Specifically, each such test evaluates if the ROI cuts at least one triangle + of the triangulated surface mesh that is referred to by surface. + If this is the case the ROI is marked as one close to the surface + and not analyzed further. Otherwise, the ROI is marked as one far + from the surface and processed further. + + For each ROI the tool computes atomically decomposed profiles. + This means, molecular ions are splitted into nuclides as many times as + their respective multiplicity. For each processed ROI the tool stores + a sorted list of signed distance values to enable post-processing with + other software like e.g. reporter to perform classical + Krakauer/Seidman-style interfacial excess analyses. + + Users should be aware that the latter intersection analysis is not + a volumetric intersection analysis. Given that the triangulated mesh + referred to in surface is not required to mesh neither a watertight + nor convex polyhedron a rigorous testing of volumetric intersection + is much more involved. If the mesh is watertight one could use split + the task in first tessellating the mesh into convex polyhedra (e.g. + tetrahedra and apply a volumetric intersection method like the + Gilbert-Johnson-Keerthi algorithm (GJK). In cases when the mesh is not + even watertight distance-based segmentation in combination with again + intersection of triangles and convex polyhedra is a robust but currently + not implemented method to quantify intersections. + + + + + + + + + + + + + + + + + + + + + A precomputed triangulated surface mesh representing a model (of the surface) + of the edge of the dataset. This model can be used to detect and control + various sources of bias in the analyses. + + + + + + + + Absolute path in the (HDF5) file that points to the array + of vertex positions for the triangles in that triangle_set. + + + + + Absolute path in the (HDF5) file that points to the array + of vertex indices for the triangles in that triangle_set. + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + + + + A precomputed triangulated mesh of the feature representing a model of the + interface at which to place ROIs to profile. This can be the mesh of an + interface as returned e.g. by a previous interface_meshing task or the + mesh of an iso-surface from a previous delocalization task. + + + + + + + + Absolute HDF5 path to the dataset that specifies the array of vertex positions. + + + + + Absolute HDF5 path to the dataset that specifies the array of facet indices + which refer to vertices. + + + + + Absolute HDF5 path to the dataset that specifies the array of facet signed unit + normals. + + + + + Absolute HDF5 path to the dataset that specifies the array of vertex signed unit + normals. + + + + + + If interface_model is isosurface this filter can be used to restrict the analysis to specific + patches of an iso-surface. + + + + + + + + To enable an additional filtration of specific parts of the feature + mesh it is recommended to feed precomputed distances of each ion to + the triangles of the feature mesh. + + + + + + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + As an alternative mode the tool can be instructed to place ROIs + at specific locations into the dataset. This is the programmatic + equivalent to the classical approach in atom probe to place ROIs + for composition analyses via positioning and rotating them via + a graphical user interface (such as in IVAS / AP Suite). + + + + + + + + + + + + + + + + + + + + + + + + + + + Which type of distance should be reported for the profile. + + + + + + + + For each ROI, along which direction should the cylindrical ROI + be oriented if ROIs are placed at triangles of the feature mesh. + + + + + + + + For each ROI, how high (projected onto the cylinder axis) should + the cylindrical ROI be if ROIs are placed at triangles + of the feature mesh. + + + + + For each ROI, how wide (in radius) should the cylindrical ROI + be if ROIs are placed at triangles of the feature mesh. + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml new file mode 100644 index 0000000000..4b8e2d3a55 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -0,0 +1,1272 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of atoms in the atomic_decomposition match filter. + + + + + The total number of isotopes in the isotopic_decomposition match filter. + + + + + The dimensionality of the delocalization grid. + + + + + The cardinality/total number of cells/grid points in the delocalization grid. + + + + + + The total number of faces of triangles. + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of entries in a feature dictionary. + + + + + The total number of volumetric features. + + + + + The total number of member distinguished when reporting composition. + + + + + The total number of ROIs placed in an oned_profile task. + + + + + Application definition for results files of the paraprobe-nanochem tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + + + + + + + + + + + + + How were results of the kernel-density estimation normalized: + * total, the total number (intensity) of ions or elements. + * candidates, the total number (intensity) of ions matching weighting_model + * composition, the value for candidates divided by the value for total, + * concentration, the value for candidates divided by the volume of the cell. + + + + + + + + + + + The discretized domain/grid on which the delocalization is applied. + + + + + + + + + + + The total number of cells/voxels of the grid. + + + + + + + + + + The symmetry of the lattice defining the shape of the unit cell. + + + + + + + + The unit cell dimensions according to the coordinate system defined under + coordinate_system. + + + + + + + + Number of unit cells along each of the d-dimensional base vectors. + The total number of cells, or grid points has to be the cardinality. + If the grid has an irregular number of grid positions in each direction, + as it could be for instance the case of a grid where all grid points + outside some masking primitive are removed, this extent field should + not be used. Instead use the coordinate field. + + + + + + + + + Integer which specifies the first index to be used for distinguishing identifiers for cells. + Identifiers are defined either implicitly or explicitly. For implicit indexing the identifiers are + defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. + + + + + Halfwidth of the kernel about the central voxel. + The shape of the kernel is that of a cuboid + of extent 2*kernel_extent[i] + 1 in each dimension i. + + + + + + + + Functional form of the kernel (Ansatz function). + + + + + + + + Standard deviation :math:`\sigma_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + Expectation value :math:`\mu_i` of the kernel in each dimension + in the paraprobe coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. + + + + + + + + A tight axis-aligned bounding box about the grid. + + + + For atom probe should be set to true. + + + + + Integer which specifies the first index to be used for distinguishing + hexahedra. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + For explicit indexing the identifier array has to be defined. + + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for vertices. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. + + + + + Integer which specifies the first index to be used for distinguishing + identifiers for faces. Identifiers are defined either implicitly or explicitly. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. For explicit indexing the identifier array + has to be defined. + + + + + Positions of the vertices. + Users are encouraged to reduce the vertices to unique set of positions + and vertices as this supports a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. + Naively here means that one for example stores each vertex of a triangle + mesh even though many vertices are shared between triangles and thus + the positions of these vertices do not have to be duplicated. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + + + + + + + + + Six equally formatted sextets chained together. For each sextett the first entry is an + XDMF primitive topology key (here 5 for polygon), the second entry the XDMF + primitive count value (here 4 because each face is a quad). + The remaining four values are the vertex indices. + + + + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + Name of the boundaries. E.g. left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + + + + The result of the delocalization :math:`\Phi = f(x, y, z)` based on which subsequent iso-surfaces + will be computed. In commercial software so far there is no possibility to export this information. + + If the intensity for all matches of the weighting_model are summarized name this NXdata instance + scalar_field_magn_total. + + If the intensity is reported for each iontype one can avoid many subsequent + computations as individual intensities can be reinterpreted using a different weighting_model in + down-stream usage of the here reported values (e.g. with Python scripting). + In this case name the individual NXdata instances scalar_field_magn_ionID using the ID of the ion as + per the configuration of the ranging definitions used. + + + + + + + + + + The actual delocalized intensity values. + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + Intensity of the field at given point + + + + + + + + Center of mass positions of each voxel for rendering the scalar field + via XDMF in e.g. Paraview. + + + + + + + + + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDMF in e.g. Paraview. + + + + + + + + + The three-dimensional gradient :math:`\nabla \Phi`. + Follow the naming convention of scalar_field_magn_SUFFIX to report parallel structures. + + + + + + + + + + The actual point-wise component values. + + + + + + + + + + + Cell center of mass positions along x. + + + + + + + + Cell center of mass positions along y. + + + + + + + + Cell center of mass positions along z. + + + + + + + + The gradient vector formatted for direct visualization via XDMF in e.g. + Paraview. + + + + + + + + + Center of mass positions of each voxel for rendering the scalar field gradient + via XDMF in e.g. Paraview. + + + + + + + + + XDMF topology for rendering in combination with xdmf_xyz the scalar field + via XDFM in e.g. Paraview. + + + + + + + + + + An iso-surface is the boundary between two regions across which the magnitude of a + scalar field falls below/exceeds a threshold magnitude :math:`\varphi`. + + For applications in atom probe microscopy, the location and shape of such a boundary (set) + is typically approximated by discretization - triangulation to be specific. + + This yields a complex of not necessarily connected geometric primitives. + Paraprobe-nanochem approximates this complex with a soup of triangles. + + + + + The threshold or iso-contour value :math:`\varphi`. + + + + + Details about the specific marching cubes algorithm that was used for computing + the iso-surface. + + + + Reference to the specific implementation of marching cubes used. + The value placed here should be a DOI. If there are no specific + DOI or details write not_further_specified, or give at least a + free-text description. The program and version used is the + specific paraprobe-nanochem. + + + + + + The resulting triangle soup computed via marching cubes. + + + + + + Integer which specifies the first index to be used for distinguishing triangles. + Identifiers are defined either implicitly or explicitly. For implicit indexing the + identifiers are defined on the interval :math:`[identifier\_offset, identifier\_offset + c - 1]`. + + + + + + + + + + Positions of the vertices. + + Users are encouraged to reduce the vertices to a unique set as this may + result in a more efficient storage of the geometry data. + It is also possible though to store the vertex positions naively in which + case vertices_are_unique is likely False. Naively here means that each + vertex is stored even though many share the same positions. + + + + + + + + + Array of identifiers from vertices which describe each face. + + The first entry is the identifier of the start vertex of the first face, + followed by the second vertex of the first face, until the last vertex + of the first face. Thereafter, the start vertex of the second face, the + second vertex of the second face, and so on and so forth. + + Therefore, summating over the number_of_vertices, allows to extract + the vertex identifiers for the i-th face on the following index interval + of the faces array: :math:`[\sum_{i = 0}^{i = n-1}, \sum_{i=0}^{i = n}]`. + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + Direction of each normal. + + + + + + + + + Qualifier how which specifically oriented normal to its + primitive each normal represents. + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + :math:`\sum_{x, y, z} {\nabla{c}_i}^2`. + + + + + + + + + Triangle normals are oriented in the direction of the + gradient vector of the local delocalized scalar field. + The projection variable here describes the cosine of the + angle between the gradient direction and the normal + direction vector. + This is a descriptor of how parallel the projection is + that is especially useful to document those triangles + for whose the projection is almost perpendicular. + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length + is reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle + is reported for the angle opposite to the edges which are + traversed according to the sequence in which vertices + are indexed in triangles. + + + + + + + + + The center of mass of each triangle. + + + + + + + + + Iso-surfaces of arbitrary scalar three-dimensional fields can show a complicated topology. + Paraprobe-nanochem can run a DBScan-like clustering algorithm which performs a + connectivity analysis on the triangle soup representation of such iso-surface. + This may yield a set of connected features whose individual surfaces are discretized + by a triangulated mesh each. Such volumetric features can be processed further using + paraprobe-nanochem using a workflow with at most two steps. + + In the first step, the tool distinguishes three types of (v) i.e. volumetric features: + + 1. So-called objects, i.e. necessarily watertight features represented by polyhedra. + These objects were already watertight within the triangulated iso-surface. + 2. So-called proxies, i.e. features that were not necessarily watertight within the triangulated + iso-surface but were subsequently replaced by a watertight mesh using polyhedral mesh + processing operations (hole filling, refinement, fairing operations). + 3. Remaining triangle surface meshes or parts of these of arbitrary shape and cardinality + that are not transformable into proxies or for which no transformation into proxies was + instructed. + + These features can be interpreted as microstructural features. Some of them may be precipitates, + some of them may be poles, some of them may be segments of dislocation lines or other + crystal defects which are decorated (or not) with solutes. + + In the second step, the tool can be used to analyze the proximity of these objects to a + model of the surface (edge) of the dataset. + + + + The identifier which the triangle_soup connectivity analysis + returned, which constitutes the first step of the + volumetric_feature identification process. + + + + + + + + The array of keywords of feature_type dictionary. + + + + + + + + The array of values for each keyword of the + feature_type dictionary. + + + + + + + + The array of controlled keywords, need to be from + feature_type_dict_keyword, which specify which type + each feature triangle cluster belongs to. + Keep in mind that not each feature is an object or proxy. + + + + + + + + The explicit identifier of features. + + + + + + + + In all situations instances of the parent NXprocess group are returned with a very similar + information structuring and thus we here replace the template name FEATURE + with one of the following types feature-specific group names: + + * objects, objects, irrespective their distance to the surface + * objects_close_to_edge, sub-set of v_feature_object close surface + * objects_far_from_edge, sub-set of v_feature_object not close to the surface + * proxies, proxies, irrespective their distance to the surface + * proxies_close_to_edge, sub-set of v_feature_proxies, close to surface + * proxies_far_from_edge, sub-set of v_feature_proxies, not close to surface + + + + Explicit identifier of the feature a sub-set of the feature_identifier in the + parent group. + + + + + + + + Volume of the feature. NaN for non-watertight objects. + + + + + + + + An oriented bounding box (OBB) to each object. + + + + Edge length of the oriented bounding box from largest to smallest value. + + + + + + + + + Oriented bounding box aspect ratio. + YX versus ZY or second-largest over largest and smallest over second largest. + + + + + + + + + Position of the geometric center, which often is but + not necessarily has to be the center_of_mass of the + hexahedrally-shaped sample/sample part. + + + + + + + + + A simple approach to describe the entire set of hexahedra when the main intention + is to store the shape of the hexahedra for visualization. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Array of evaporation_identifier / ion_identifier which details which ions + lie inside or on the surface of the feature. + + + + + + + + + + + Total (count) of ions inside or on the surface of the feature relevant for normalization. + NaN for non watertight objects. + + + + + + + + + + + + + Count or weight which, when divided by total, yields the composition of this element, + nuclide, or (molecular) ion within the volume of the feature/object. + + + + + + + + + + + + + + + + + + + + + + + + The multiplicity whereby the ion position is accounted for + irrespective whether the ion is considered as a decorator + of the interface or not. + As an example, with atom probe it is typically not possible + to resolve the positions of the atoms which arrive at the detector + as molecular ions. Therefore, an exemplar molecular ion of two carbon + atoms can be considered to have a multiplicity of two to account that + this molecular ion contributes two carbon atoms at the reconstructed + location considering that the spatial resolution of atom probe + experiments is limited. + + + + + + + + The multiplicity whereby the ion position is accounted for when + the ion is considered one which is a decorator of the interface. + + + + + + + + The equation of the plane that is fitted initially. + + + + The four parameter :math:`ax + by + cz + d = 0` which define the plane. + + + + + + + + + The triangle surface mesh representing the interface model. + Exported at state before or after the next DCOM step. + + + + Was this state exported before or after the next DCOM step. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Direction of each vertex normal. + + + + + + + + + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + Direction of each face normal. + + + + + + + + + Qualifier which details how specifically oriented the + face normal is with respect to its primitive (triangle): + + * 0 - undefined + * 1 - outer + * 2 - inner + + + + + + + + + + + + + + + + + + + Array of edge length values. For each triangle the edge length is + reported for the edges traversed according to the sequence + in which vertices are indexed in triangles. + + + + + + + + + Array of interior angle values. For each triangle the angle is + reported for the angle opposite to the edges which are traversed + according to the sequence in which vertices are indexed in triangles. + + + + + + + + + + + + + + + + + + The ROIs are defined as cylinders for the computations. To visualize these we discretize + them into regular n-gons. Using for instance 360-gons, i.e. a regular n-gon with 360 edges, + resolves the lateral surface of each cylinder such that their renditions are smooth in + visualization software like Paraview. + + + + + + Position of the geometric center, which often is but not + necessarily has to be the center_of_mass of the polyhedra. + + + + + + + + + The orientation of the ROI defined via a vector which points along + the cylinder axis and whose length is the height of the cylinder. + + + + + + + + + + XDMF support to enable colouring each ROI by its identifier. + + + + + + + + XDMF support to enable colouring each ROI whether it has edge contact or not. + + + + + + + + XDMF support to enable colouring each ROI by its number of atoms. + + + + + + + + XDMF support to enable colouring each ROI by its number of ions. + + + + + + + + Distance and iontype-specific processed data for each ROI. + Arrays signed_distance and nuclide_hash are sorted by increasing + distance. + Array nuclide_hash reports one hash for each atom of each isotope. + Effectively, this can yield to groups of values on signed_distance + with the same distance value as molecular ions are reported decomposed + into their atoms. + Therefore, the XDMF support fields number_of_atoms and number_of_ions + are only expected to display pairwise the same values respectively, + if all ions are built from a single atom only. + + + + + Sorted in increasing order projected along the positive direction + of the ROI as defined by orientation in the parent group. + + + + + + + + Hashvalue as defined in :ref:`NXion`. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml new file mode 100644 index 0000000000..3282c203db --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of isotopes to consider as building blocks for searching molecular + ions. + + + + + The number of compositions to consider for molecular ion search tasks. + + + + + Application definition for a configuration file of the paraprobe-ranger tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml new file mode 100644 index 0000000000..de5680a967 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -0,0 +1,139 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstructed volume. + + + + + Application definition for results files of the paraprobe-ranger tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-ranger tool is to apply a given set of ranging definitions within + a certain (possibly complicated) selection of ions (based on their properties or location in the + reconstructed volume. + + + + + + + + + + + + Paraprobe-ranger loads the iontypes and evaluates for each + ion on which iontype it matches. If it matches on None, the + ion is considered of the default *unknown_type*. This iontype + is marked with a 0 in the iontypes array. + + + + + + + + + + + + + + + + + + The iontype (identifier) for each ion that was best matching, stored + in the order of the evaporation sequence ID. The here computed iontypes + do not take into account the charge state of the ion which is + equivalent to interpreting a RNG and RRNG range files for each + ion in such a way that only the those elements are considered of which + a (molecular) ion is assumed composed according to the NXion instances. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml new file mode 100644 index 0000000000..89484faa9f --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Application definition for a configuration file of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml new file mode 100644 index 0000000000..5630291783 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -0,0 +1,111 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Application definition for results files of the paraprobe-selector tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-selector tool is to identify which reconstructed positions + are located inside or on the surface of a (possibly complicated) region-of-interest (ROI). + In addition, the tool allows to filter ions for properties. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml new file mode 100644 index 0000000000..5f4b26836a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -0,0 +1,338 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms per molecular ion. Should be 32 for paraprobe. + + + + + Number of different source iontypes to distinguish. + + + + + Number of different target iontypes to distinguish. + + + + + Application definition for a configuration file of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + How many spatial_statistics tasks should the tool execute. + + + + + + + + + + + + + + + + + + + + + + + Distance between each ion and triangulated surface mesh. + + + + + + + + + Threshold to define how far an ion has to lay at least from the edge + of the dataset so that the ion can act as a source. This means that + an ROI is placed at the location of the ion and its neighbors are + analyzed how they contribute to the computed statistics. + + The edge_distance threshold can be combined with the feature_distance threshold. This threshold defines defines up to which distance to a + microstructural feature an ROI is placed. + + The threshold is useful to process the dataset such that ROIs do + not protrude out of the dataset as this would add bias. + + + + + + Distance between each ion and triangulated mesh of microstructural features. + In addition to spatial filtering and considering how far ions lie to the + edge of the dataset, it is possible to restrict the analyses to a sub-set of + ions within a distance not farther away to a feature than the feature_distance + threshold value. + + + + + + + + Absolute path in the (HDF5) file which points to the distance of each + ion to the closest feature. + + + + + Threshold to define how close an ion has to lay to a feature so that + the ion can at all qualify as a source, i.e. that an ROI is placed + at the location of the ion and its neighbors are then analyzed + how they contribute to the computed statistics. + + Recall that this feature_distance threshold is used in combination + with the edge_distance threshold when placing ROI about source ions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies, if the iontypes are randomized for the point cloud or not. + Internally, paraprobe uses a sequentially executed deterministic MT19987 + (MersenneTwister) pseudo-random number generator to shuffle the + iontypes randomly across the entire set of ions. That is the total + number of ions of either type remain the same but the information about + their location is randomized. + + + + + + + + + + How should the iontype be interpreted on the source-side, i.e. + all these ion positions where a regions-of-interest (ROI) around + so-called source ions will be placed. Different options exist + how iontypes are interpreted given an iontype represents + in general a (molecular) ion with different isotopes that have + individually different multiplicity. + + The value resolve_all will set an ion active in the analysis regardless + of which iontype it is. Each active ion is accounted for once. + + The value resolve_unknown will set an ion active when the ion is + of the UNKNOWNTYPE type. Each active ion is accounted for once. + + The value resolve_ion will set an ion active if it is of the specific + iontype, irregardless of its elemental or isotopic details. + Each active ion is counted once. + + The value resolve_element will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + atoms of elements in the whitelist ion_query_isotope_vector. + + The value resolve_isotope will set an ion active, and most importantly, + account for each as many times as the (molecular) ion contains + isotopes in the whitelist ion_query_isotope_vector. + + In effect, ion_query_isotope_vector acts as a whitelist to filter + which ions are considered as source ions of the correlation statistics + and how the multiplicity of each ion will be factorized, i.e. how + often it is accounted for. + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates + for iontypes should be distinguished as possible source iontypes. + In the simplest case, the matrix contains only the proton number + of the element in the row, all other values set to zero. + Combined with ion_query_type_source set to resolve_element this will + recover usual spatial correlation statistics like the 1NN C-C + spatial statistics. + + + + + + + + + Similarly as ion_query_type_source how should iontypes be interpreted + on the target-side, i.e. how many counts will be bookkept for ions + which are neighbors of source ions within or on the surface of each + inspection/ROI about each source ion. + Source ion in the center of the ROI are not accounted for during + counting the summary statistics. + For details about the resolve values consider the explanations in + ion_query_type_source. These account for ion_query_type_target as well. + + + + + + + + + + + + + Matrix of isotope vectors, as many as rows as different candidates for + iontypes to distinguish as possible targets. See additional comments + under ion_query_isotope_vector_source. + + + + + + + + + Specifies which spatial statistics to compute. + + + + Compute k-th nearest neighbour statistics. + + + + Order k. + + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + Compute radial distribution function. + + + + Minimum value, increment, and maximum value of the histogram binning. + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml new file mode 100644 index 0000000000..52187c9518 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -0,0 +1,200 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of bins in the histogram for the k-th nearest neighbor. + + + + + The total number of bins in the histogram for the radial distribution function. + + + + + Application definition for results files of the paraprobe-spatstat tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + + + + + + + + The iontype ID for each ion that was assigned to each ion during + the randomization of the ionlabels. Iontype labels are just permuted + but the total number of values for each iontype remain the same. + + The order matches the iontypes array from a given ranging results + as it is specified in the configuration settings inside the specific + config_filename that was used for this paraprobe-spatstat analysis. + + + + + + + + K-nearest neighbor statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated not normalized by total counts. + + + + + + + + Cumulated and normalized by total counts. + + + + + + + + + Radial distribution statistics. + + + + Right boundary of the binning. + + + + + + + + + + + + + Cumulated not normalized by total counts. + + + + + + + + Cumulated and normalized by total counts. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml new file mode 100644 index 0000000000..3cb04dac60 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -0,0 +1,235 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of alpha values (and offset values) to probe. + + + + + How many different match values does the filter specify. + + + + + Application definition for a configuration file of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Specifies the method that is used to preprocess the point cloud + prior to the alpha-shape computation. + + The option *default* specifies that no such filtering is applied. + The option *kuehbach* specifies that a Hoshen-Kopelman + percolation analysis is used to identify points that lie closer + to the edge of the dataset. Details about the methods are reported + in `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. + + + + + + + + + When using the kuehbach preprocessing, this is the width of the + kernel for identifying which ions are in voxels close to the + edge of the point cloud. + + + + + + Specifies which method to use to define the alpha value. + + The value *convex_hull_naive* is the default. The setting instructs + the tool to use a fast specialized algorithm for computing only + the convex hull. The resulting triangles can be skinny. + + The value *convex_hull_refine* instructs to tool to refine the + quality of the mesh resulting from *convex_hull_naive* + via triangle flipping and splitting. + + The value *smallest_solid* instructs the CGAL library to choose a + value which realizes an alpha-shape that is the smallest solid. + + The value *cgal_optimal* instructs the CGAL library to choose a + value which the library considers as to be an optimal value. + Details are defined in the respective section of the CGAL library + on 3D alpha shapes. + + The value *set_of_values* instructs the tool to compute a list + collection of alpha-shapes for the specified alpha-values. + + The value *set_of_alpha_wrappings* instructs the tool to generate + a set of so-called alpha wrappings. These are similar to alpha-shapes + but provide additional guarantees (such as watertightness and + proximity constraints) on the resulting wrapping. + + + + + + + + + + + + + Array of alpha values to use when alpha_value_choice is + set_of_values or when alpha_value_choice is set_of_alpha_wrappings. + + + + + + + + Array of offset values to use when alpha_value_choice is set_of_alpha_wrappings. + The array of alpha_values and offset_values define a sequence of (alpha and offset value). + + + + + + + + Specifies if the tool should compute the set of exterior triangle facets + for each alpha complex (for convex hull, alpha shapes, and wrappings). + + + + + Specifies if the tool should check if the alpha complex of + exterior triangular facets is a closed polyhedron. + + + + + Specifies if the tool should compute all interior tetrahedra + of the alpha complex (currently only for alpha shapes). + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml new file mode 100644 index 0000000000..fa2bbd8825 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -0,0 +1,289 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The number of vertices of the alpha complex. + + + + + The number of faces of the alpha complex. + + + + + The total number of XDMF values to represent all faces of triangles via XDMF. + + + + + The total number of XDMF values to represent all faces of tetrahedra via XDMF. + + + + + Application definition for results files of the paraprobe-surfacer tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-surfacer tool is the generation of meshed + representation of the surface of the the reconstructed volume (or a portion) of it + using different algorithms from the computational geometry community. + + + + + + + + + + + + Paraprobe-surfacer can be used to load a ROI that is the entire or a + sub-set of the ion point cloud. In the point_cloud_wrapping process + the tool computes a triangulated surface mesh which encloses the + ROI/point cloud. This mesh can be seen as a model for the edge of + the dataset. + + Different algorithms can be used with paraprobe-surfacer to create + this mesh such as convex hulls, alpha-shapes as their generalization, + or alpha wrappings. + + Ideally, the resulting mesh should be a watertight polyhedron. + This polyhedron is not necessarily convex. For some algorithms there + is no guarantee that the resulting mesh yields a watertight mesh. + + + + + + + + + + + + + A bitmask which identifies exactly all those ions whose positions + were considered when defining the filtered point set from which + that alpha_complex instance was computed. + + This window can be different to the window of the *point_set_wrapping* + parent group because irrelevant ions might have been filtered out in addition + to the window defined in *point_set_wrapping* to reduce e.g. computational + costs of the alpha complex computation. + + + + + Number of ions covered by the mask. + + + + + Number of bits assumed matching on a default datatype. + + + + + The bitfield of the mask. See :ref:`NXcs_filter_boolean_mask` for + how this bitfield is to be interpreted. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The set of triangles in the coordinate system paraprobe + which discretizes the exterior surface of the alpha complex. + + + + + + + + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tri * (1+1+3). + + + + + + + + Do the triangles define a triangulated surface mesh that is watertight? + + + + + The volume which the triangulated surface mesh + encloses if that mesh is watertight. + + + + + + + The set of tetrahedra which represent the interior volume + of the complex if that is a closed two-manifold. + + + + + The accumulated volume of all interior tetrahedra. + + + + + + + + + + + + + + + + A list of as many tuples of XDMF topology key, XDMF number + of vertices and a triple of vertex indices specifying each + triangle. The total number of entries is n_f_tet * (1+1+4). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml new file mode 100644 index 0000000000..bf91256517 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -0,0 +1,175 @@ + + + + + + + Application definition for a configuration file of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The method used to compute the tessellation. + The value *default* configures the computation of the Voronoi tessellation. + + + + + + + + + Specifies if the tool should report the volume of each cell. + + + + + Specifies if the tool should report the first-order neighbors of each cell. + + + + + Specifies if the tool should report the facets and vertices of each cell. + + + + + Specifies if the tool should report for each cell if it makes contact with + the tight axis-aligned bounding box about the point cloud. + This can be used to identify if the shape of the cell is likely affected + by the edge of the dataset or if cells are deeply enough embedded + into the point cloud so that the shape of their cells are not affected + anymore by the boundary. This is valuable information to judge + about the significance of finite size effects. + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml new file mode 100644 index 0000000000..dbfa7dc94c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -0,0 +1,337 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + The total number of values required to represent all faces of each cell. + + + + + The total number of values required to represent all faces of each cell + (polyhedron) using XDMF. + + + + + Application definition for results files of the paraprobe-tessellator tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + + + + + + + + + + + + The tool can be used to compute a Voronoi tessellation the entire + or of a sub-set of the reconstructed volume. Each point (ion) is wrapped + in one (Voronoi) cell. The point cloud in the ROI is wrapped into an + axis-aligned bounding box (AABB) that is tight. This means points at + the edge of the point cloud can lay on the surface of the bounding box. + The tool detects if cells make contact with the walls of this bounding box. + The tessellation is computed without periodic boundary conditions. + + + + + + + + + + + The (tight) axis-aligned bounding box about the point cloud. + + + + Coordinate triplet of the corner that lays closests + to the origin of the *paraprobe* coordinate system. + + + + + + + + Coordinate triplet of the corner that lays farthest away + from the origin of the *paraprobe* coordinate system. + + + + + + + + + + + + + + + The number of points (and thus cells). + + + + + Volume of each Voronoi cell. + + + + + + + + Which MPI process computed which Voronoi cell. + + + + + + + + Which OpenMP thread computed which Voronoi cell. + + + + + + + + The number of faces for each cell. Faces of adjoining polyhedra are counted + for each polyhedron. This field can be used to interpret the concatenated vector + with the individual values for the area of each face. + + + + + + + + + A simple approach to describe the entire set of polyhedra when the main + intention is to store the shape of the polyhedra for visualization purposes. + + + + + + + + + + Sequence of tuples, concatenated in the order of the Voronoi cells. + Each tuple contains encodes information to visualize using XDMF: + Firstly, an XDMF geometric primitive type key. + Secondly, the number of vertices of the polygon. + Third, the sequence of vertex identifier which define the facet. + Tuples encode faces faster than cells. + + + + + + + + Sequence of cell identifier, concatenated such that each face is + associated with its cell. Given that paraprobe-tessellator assigns + each cell the evaporation_id of the ion that the cell wraps this + information enables the segmentation of the tessellation and + thus correlate per-ion properties with the volume that each cell + represents. + + + + + + + + + A bitmask that documents which of the cells are likely truncated because they + share at least one face with the *aabb* of the point cloud. This field encodes the + result of the boolean or operator applied to the value of all six wall_contact groups + that document contact in specific outer unit normal directions of the *aabb*. + + + + + + + + + + + + + In the spirit of wall_contact_global, the left face of *aabb*. + Its outer unit normal points in the opposite direction of the + x-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the right face of *aabb*. + Its outer unit normal points in the direction of the x-axis + of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + y-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the rear face of *aabb*. + Its outer unit normal points in the direction of the y-axis + of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the opposite direction of the + z-axis of the *paraprobe* coordinate system. + + + + + + + + + + + + In the spirit of wall_contact_global, the front face of *aabb*. + Its outer unit normal points in the direction of the z-axis of the + *paraprobe* coordinate system. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml new file mode 100644 index 0000000000..541a059a7d --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -0,0 +1,129 @@ + + + + + + Base class documenting the information common to tools of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The common section can be used as a place to store e.g. organizational + metadata and contextualization of that analysis in a research data + management system. + + + + A statement whether the tool executable managed to process the analysis + or whether this failed. Status is written to the results file after the + end_time beyond which point in time the tool must no longer compute + any further analysis results but exit. + + Only when this status message is present and its value is `success`, + one should consider the results of the tool. In all other cases it might + be that the tool has terminated prematurely or another error occurred. + + + + + + + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + The configuration file that was used to parameterize + the algorithms that this tool has executed. + + + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file was started, + i.e. when the respective executable/tool was started as a process. + + + + + ISO 8601 formatted time code with local time zone offset to UTC + information included when the analysis in this results file were + completed and the respective process of the tool exited. + + + + + Wall-clock time. + + + + + + + Details about coordinate systems (reference frames) used. In atom probe several coordinate + systems have to be distinguished. Names of instances of such :ref:`NXcoordinate_system` + should be documented explicitly and doing so by picking from the + following controlled set of names: + + * paraprobe + * lab + * specimen + * laser + * instrument + * detector + * recon + + The aim of this convention is to support users with contextualizing which reference frame + each instance (coordinate system) is. If needed, instances of :ref:`NXtransformations` + are used to detail the explicit affine transformations whereby one can convert + representations between different reference frames. + Inspect :ref:`NXtransformations` for further details. + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml new file mode 100644 index 0000000000..c2169cc139 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -0,0 +1,137 @@ + + + + + + Base class documenting the configuration used for a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source software tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). + + + + + + Internal identifier used by the tool to refer to an analysis (aka simulation + id). + + + + + Possibility for leaving a free-text description about this analysis. + + Although offered here for convenience we strongly encourage to + parameterize such descriptions as much as possible to support + reusage and clearer communication. + + + + + + Specification of the tomographic reconstruction to use for this analysis. + + Typically, reconstructions in the field of atom probe tomography are communicated + via files which store at least reconstructed ion positions and mass-to-charge-state-ratio + values. Container files like HDF5 though can store multiple reconstructions. + Therefore, the position and mass_to_charge concepts point to specific instances + to use for this analysis. + + + + Name of the node which resolves the reconstructed ion position + values to use for this analysis. + + + + + Name of the node which resolves the mass-to-charge-state-ratio + values to use for this analysis. + + + + + + Specification of the ranging definitions to use for this analysis. + + Ranging is the process of labeling time-of-flight data with so-called iontypes + (aka ion species). Ideally, iontypes specify the most likely (molecular) ion + that is assumed to have been evaporated given that its mass-to-charge-state ratio + lies within the specific mass-to-charge-state-ratio value interval of the iontype. + + The so-called UNKNOWNTYPE iontype represents the null model of an ion + that has not been ranged (for whatever reasons). + The identifier of this special iontype is always the reserved value 0. + + + + Name of the (parent) node directly below which (in the hierarchy) + the ranging definition for (molecular) ions are stored. + + + + + + Specification of the triangulated surface mesh to use for this analysis. + + Such a surface mesh can be used to define the edge of the reconstructed + volume to account for finite size effects. + + + + + + Specification of the point-to-triangulated-surface-mesh distances to + use for this analysis. + + + + Absolute path in the (HDF5) file that points to the distance values. + The tool assumes that the values are stored in the same order as + points (ions). + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml new file mode 100644 index 0000000000..2ac82f751a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -0,0 +1,87 @@ + + + + + + + Base class documenting the results obtained with a tool of the paraprobe-toolbox. + + The paraprobe-toolbox is a collection of open-source tools for performing + efficient analyses of point cloud data where each point can represent atoms or + (molecular) ions. A key application of the toolbox has been for research in the + field of Atom Probe Tomography (APT) and related Field Ion Microscopy (FIM): + + * `paraprobe-toolbox <https://www.gitlab.com/paraprobe/paraprobe-toolbox>`_ + * `M. Kühbach et al. <https://paraprobe-toolbox.readthedocs.io/en/main/>`_ + + The toolbox does not replace but complements existent software tools in this + research field. Given its capabilities of handling points as objects with + properties and enabling analyses of the spatial arrangement of and inter- + sections between geometric primitives, the software can equally be used + for analyzing data in Materials Science and Materials Engineering. + + The configuration and results of a run of a tool from the toolbox is documented + using binary container formats. Currently, paraprobe-toolbox uses the + Hierarchical Data Format 5 (HDF5). + + The paraprobe coordinate system is the reference *NXcoordinate_system* + for each geometric primitive. + + + + + Possibility for leaving a free-text description about this analysis. + + + + + A bitmask which identifies all ions considered in the analysis. + + + + Number of ions covered by the mask. + By default, the total number of ions in the dataset. + + + + + Number of bits assumed matching on a default datatype. + + + + + The mask. The length of the mask is an integer multiple of bitdepth. + In such case, padded bits are set to 0. + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml new file mode 100644 index 0000000000..21b882cc6c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_config.nxdl.xml @@ -0,0 +1,83 @@ + + + + + + + + Application definition for a configuration file of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect :ref:`NXapm_paraprobe_tool_config` for details. + + + + + + + + + + + + + + + + + + + + + + + + Specification of the ranging definition file to use for this analysis. + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml new file mode 100644 index 0000000000..3153d95581 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_transcoder_results.nxdl.xml @@ -0,0 +1,219 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of ions in the reconstruction. + + + + + Maximum number of allowed atoms per (molecular) ion (fragment). + Needs to match maximum_number_of_atoms_per_molecular_ion. + + + + + Total number of integers in the supplementary XDMF topology array. + + + + + Number of entries + + + + + Application definition for results files of the paraprobe-transcoder tool. + + This tool is part of the paraprobe-toolbox. Inspect the base class :ref:`NXapm_paraprobe_tool_results`. + The purpose and need of the paraprobe-transcoder tool is to create a standardized representation + of reconstructed position and mass-to-charge-state-ratio values surplus other pieces of information + to enable working with atom probe data in reconstruction space in the paraprobe-toolbox. + This includes ranging definitions which map mass-to-charge-state ratio values onto iontypes. + + So far the atom probe community has not yet agreed upon a comprehensive standardization on how to + exchange information especially when it comes to the communication of configurations and results + from analyses of atom probe data. Instead, different simplistic file formats are used, such as POS, ePOS, + APT, or RNG and RRNG. None of these formats, though, are self-descriptive, standardize, or document + their origin and thus the sequence in which the file was generated during an analysis. + + Paraprobe-transcoder solves this limitation by interpreting the information content in such files + and standardize the representation prior injection into the scientific data analysis tools of the toolbox. + Therefore, the here proposed set of NeXus base classes and application definitions can be a useful + starting point for the atom probe community to take advantage of standardized information + exchange and improve the here proposed classes and concepts to become more inclusive. + + Paraprobe-transcoder uses a Python library developed based on efforts by members of the + global atom probe community `International Field Emission Society (IFES) Atom Probe Technical Committee (APT TC) <https://www.github.com/atomprobe-tc/ifes_apt_tc_data_modeling>`_. This library offers the + actual low-level I/O operations and respective information interpretation of above-mentioned file formats. + + + + + + + + + + + + + + + + + + + + + By default the entire reconstructed volume is processed. + In this case, using window is also equivalent to an + NXspatial_filter that specified a window *entire_dataset*. + + + + + + + + + + Mass-to-charge-state-ratio values. + + + + + + + + + + Three-dimensional reconstructed positions of the ions. + Interleaved array of x, y, z positions in the specimen space. + + + + + + + + Defines in which reference frame the positions are defined. + + + + + + + An array of triplets of integers which can serve as a supplementary + array for Paraview to display the reconstruction. The XDMF datatype + is here 1, the number of primitives 1 per triplet, the last integer + in each triplet is the identifier of each point starting from zero. + + + + + + + + + + + Details about how peaks are interpreted as ion types or not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXatom_set.nxdl.xml b/contributed_definitions/NXatom_set.nxdl.xml new file mode 100644 index 0000000000..0a1e208560 --- /dev/null +++ b/contributed_definitions/NXatom_set.nxdl.xml @@ -0,0 +1,158 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Base class for documenting a set of atoms. + + + + A unique identifier whereby such an ion can be referred to + via the service offered as described in identifier_type. + + + + + How can the identifier be resolved? + + + + + + + + Ion type (ion species) identifier. + + The identifier zero is reserved for the special unknown ion type. + + + + + Vector of nuclide hash values. + + Individual hash values :math:`H` is :math:`H = Z + N \cdot 256` with :math:`Z` + encode the number of protons :math:`Z` and the number of neutrons :math:`N` + of each nuclide respectively. :math:`Z` and :math:`N` have to be 8-bit unsigned integers. + + The array is sorted in decreasing order. For the rationale behind this see `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Table which decodes the entries in nuclide_hash into a human-readable matrix of instances. + The first column specifies the nuclide mass number, i.e. using the hashvalues + from the isotope_vector this is :math:`Z + N` or 0. The value 0 documents that no + isotope-specific information about the element encoded is relevant. + The second row specifies the number of protons :math:`Z` or 0. + The value 0 in this case documents a placeholder or that no element-specific + information is relevant. + Taking a carbon-14 nuclide as an example the mass number is 14. + That is encoded as a value pair (14, 6) as one row of the table. + + Therefore, this notation is the typical superscribed nuclide mass number + and subscripted number of protons element notation e.g. :math:`^{14}C`. + The array is stored matching the order of nuclide_hash. + + + + + + + + + + Assumed volume of the ion. + + In atom probe microscopy this field can be used to store the reconstructed + volume per ion (average) which is typically stored alongside ranging + definitions. + + + + + Charge of the ion. + + + + + Signed charge state if the atoms form an ion reported in multiples of electron charge. + + In the example of atom probe microscopy, only positive values will be measured + as the ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, the value should + be set to zero. + + In atom probe microscopy this is for example the case when using + classical ranging definition files in formats like RNG, RRNG. + These file formats do not document the charge state explicitly + but the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + Details on ranging definition files can be found in the literature: + `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable name (e.g. Al +++) of the atom set, the atom group, or ion type. + The string should consists of UTF-8 characters, ideally using LaTeX + notation to specify the isotopes, ions, and charge state. + Examples are 12C + or Al +++. + + To ease automated parsing, isotope_vector should be the + preferred machine-readable information used. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of the + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries inclusive). This field is primarily of interest + for documenting :ref:`NXprocess` steps of indexing a + ToF/mass-to-charge state histogram. + + + + + + + diff --git a/contributed_definitions/NXbias_spectroscopy.nxdl.xml b/contributed_definitions/NXbias_spectroscopy.nxdl.xml new file mode 100644 index 0000000000..ad484c806f --- /dev/null +++ b/contributed_definitions/NXbias_spectroscopy.nxdl.xml @@ -0,0 +1,168 @@ + + + + + + Base classes definition for bias spectroscopy. + + Bias sweeps while measuring arbitrary channels with I(V) curves. + + + + Select the channels to record. + + + + + If chosen, the Bias voltage resets to its initial value (before the sweep initiation) at + the conclusion of the spectroscopy measurement. When this option is not selected, the Bias + voltage maintains the last value acquired during the sweep. This functionality proves + beneficial, especially when combining multiple sweep segments. As an illustration of an + automated measurement: turn off the z-Controller, commence spectroscopy sweep segments ( + forward sweep only, without resetting the bias), restore the bias to its initial value, + and then turn on the z-Controller. + + + + + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + Time during which the spectroscopy data are acquired and averaged. + + + + + Number of sweeps to measure and average. + + + + + The first bias values of the sweep. + + + + + The last bias values of the sweep. + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the z-Controller is set to hold and the tip is + placed at the previously averaged z position (plus z offset). + + + + + Select a filter to smooth the displayed data. When saving, if any filter is selected, + filtered data are saved to file along with the unfiltered data. + + + + + Filter order of a dynamic filter or width (in number of points) for the Gaussian + filter. + + + + + Cutoff frequency for dynamic filters. + + + + + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + + + + + Time to wait after changing the bias to the next level and before + starting to acquire data. + + + + + No doc yet. + + + + + Time to wait after the sweep has finished and the bias is ramped to + the initial value. + + + + + Time during which the Z-Controller is enabled once a sweep has finished. + When averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled + for this duration between each sweep. After the last sweep, it will wait the + specified time before continuing a running scan. This ensures each sweep + reliably starts from the same position. This parameter is disabled when + Z-Controller to Hold is deselected in the Advanced section. + + + + + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + + + + + Select whether to measure the backward (return) sweep or the forward only. + + + + + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. + + + diff --git a/contributed_definitions/NXdata_mpes.nxdl.xml b/contributed_definitions/NXdata_mpes.nxdl.xml new file mode 100644 index 0000000000..8fe879134b --- /dev/null +++ b/contributed_definitions/NXdata_mpes.nxdl.xml @@ -0,0 +1,134 @@ + + + + + + :ref:`NXdata_mpes` describes the plottable data and related dimension scales in photoemission + experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for photoemission data. + + + + Calibrated energy axis. + + Could be linked from the respective '@reference' field. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + Calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + Calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + The energy can be dispersed according to different strategies. ``@reference`` points to + the path of a field defining the calibrated axis which the ``energy`` axis refers. + + For example: + @reference: 'entry/process/energy_calibration/calibrated_axis' + @reference: 'entry/process/energy_referencing/calibrated_axis' + + + + + + One calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz, + in accordance with the calibrations defined in NXprocess_mpes. + + Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, + while kz is taken as the perpendicular component. + + It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. + Units are 1/Angström. + + + + + One calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc., + in accordance with the calibrations defined in NXprocess_mpes. + + The angular axes should be named in order of decreasing speed, i.e., angular0 should be + the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, + angular0 may also be second slow axis if the measurement is angularly integrated and angular1 + could also be the second fast axis in the case of simultaneous dispersion in two angular + dimensions. + + + + + One calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc., + in accordance with the calibrations defined in NXprocess_mpes. + + The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be + the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, + spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 + could also be the second fast axis in the case of simultaneous dispersion in two spatial + dimensions. + + + + + Calibrated delay time. + + + + + Linear polarization angle of the incoming or outgoing beam. + + In an application definition, this could be a link to + /entry/instrument/beam/incident_polarization_angle or + /entry/instrument/beam/final_polarization_angle if they exist. + + + + + Ellipticity of the incoming or outgoing beam. + + Can be any of linear polarization angle (degrees), ellipticity (arb. units). + In an application definition, this could be a link to + /entry/instrument/beam/incident_ellipticity or + /entry/instrument/beam/final_ellipticity if they exist. + + + diff --git a/contributed_definitions/NXdata_mpes_detector.nxdl.xml b/contributed_definitions/NXdata_mpes_detector.nxdl.xml new file mode 100644 index 0000000000..3faebab2f6 --- /dev/null +++ b/contributed_definitions/NXdata_mpes_detector.nxdl.xml @@ -0,0 +1,147 @@ + + + + + + :ref:`NXdata_mpes_detector` describes the plottable data and related + dimension scales for raw detector data in photoemission experiments. + + It extends the NXdata class and provides a glossary of explicitly named axis names + which are typical for raw photoemission data. + + + + Raw data before calibration. + + + + + Detector pixel in x direction. + + + + + Detector pixel in y direction. + + + + + (Un)calibrated energy axis. + + + + The energy can be either stored as kinetic or as binding energy. + + + + + (Un)calibrated kinetic energy axis. + + This concept is related to term `3.35`_ of the ISO 18115-1:2023 standard. + + .. _3.35: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:3.35 + + + + + (Un)calibrated binding energy axis. + + This concept is related to term `12.16`_ of the ISO 18115-1:2023 standard. + + .. _12.16: https://www.iso.org/obp/ui/en/#iso:std:iso:18115:-1:ed-3:v1:en:term:12.16 + + + + + + + + One (un)calibrated k-space coordinate. It is envisioned that the axes are named kx, ky, and kz. + + Typically, the vectors in momentum space are defined such that kx and ky comprise the parallel component, + while kz is taken as the perpendicular component. + + It is also possible to define k_parallel and k_perp for the parallel and perpendicular momenta, respectively. + Units are 1/Angström. + + + + + One (un)calibrated angular coordinate. It is envisioned that the axes are name angular0, angular1, etc. + + The angular axes should be named in order of decreasing speed, i.e., angular0 should be + the fastest scan axis and angular1 should be the slow-axis angular coordinate. However, + angular0 may also be second slow axis if the measurement is angularly integrated and angular1 + could also be the second fast axis in the case of simultaneous dispersion in two angular + dimensions. + + + + + One (un)calibrated spatial coordinate. It is envisioned that the axes are name spatial0, spatial1, etc. + + The spatial axes should be named in order of decreasing speed, i.e., spatial0 should be + the fastest scan axis and spatial1 should be the slow-axis spatial coordinate. However, + spatial0 may also be second slow axis if the measurement is spatially integrated and spatial1 + could also be the second fast axis in the case of simultaneous dispersion in two spatial + dimensions. + + + + + + Total time of flight. + + + + + Time-of-flight values, analog-to-digital converted. + + + + + (Un)calibrated delay time. + + + + + Linear polarization angle of the incoming or outgoing beam. + + + + + Ellipticity of the incoming or outgoing beam. + + + + + Describes an axis which is coming from outside the detectors scope. + + Think of a detector just being triggered for readout by the rest of the experimental + setup - it would just know that it collected N images, which would flatten the external + parameters to one axis, too. + This can then be linked, e.g. with NXcalibration, to the appropriate fields in the instrument + and write it to the top-level NXdata_mpes. + + + diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index f061f7f583..8fd3685a1a 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,30 +41,30 @@ Number of atoms in the whitelist. - + Number of isotopes in the whitelist. - Base class to describe the delocalization of point-like objects on a grid. + Base class of the configuration and results of a delocalization algorithm. - Such a procedure is for instance used in image processing and e.g. atom probe - microscopy (APM) to discretize a point cloud onto a grid to enable e.g. - computing of point density, composition, or concentration values, obtain - scalar fields, and compute gradients of these fields. + Delocalization is used to distribute point-like objects on a grid to obtain + e.g. smoother count, composition, or concentration values of scalar fields + and compute gradients of these fields. - + - Reference or link to the grid on which the delocalization is applied. + Details about the grid on which the delocalization is applied. - - - - Reference or link to the points which are delocalized on the grid. - - + + - - - The weighting model specifies how mark data are mapped to a weight per point. - For atom probe microscopy (APM) as an example, different models are used which - account differently for the multiplicity of an ion/atom: - - * default, points all get the same weight 1.; - for APM this is equivalent to ion species - * atomic_decomposition, points get as much weight as they have atoms - of a type in element_whitelist, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotope_whitelist. - - This description shows an example that could be reinterpreted for - similar such data processing steps in other fields of science. - - - - - - - - - - - A list of elements (via proton number) to consider for the atomic_decomposition - weighting model. Elements must exist in the periodic table of elements. - - - - - - - - A list of isotopes to consider for the isotope_decomposition weighting model. - Isotopes must exist in the nuclid table. Entries in the fastest changing - dimension should be the pair of proton (first entry) and neutron number - (second entry). - - - - - - - + - Attribute data for each member of the point cloud. For APM these are the - ion species labels generated via ranging. The number of mark data per - point is 1 in the case for atom probe. + The weighting model specifies how mark data are mapped to a weight per + point/object. - - - - - - - - Weighting factor with which the integrated intensity per grid cell is - multiplied specifically for each point. For APM the weight are positive - integer values, specifically the multiplicity of the ion, - according to the details of the weighting_model. - - + + + As an example from the research field of atom probe points/objects are (molecular) ions. + Different methods are used for weighting ions: + + * default, points get all the same weight 1., which for atom probe is equivalent + to (molecular) iontype-based delocalization. + * element, points get as much weight as they have atoms representing a nuclide + with a proton number that is matching to a respective entry in whitelist. + In atom probe jargon, this means atomic_decomposition. + * isotope, points get as much weight as they have atoms representing a nuclides + from a respective entry in whitelist. + In atom probe jargon, this means isotope_decomposition. + + + + + + + + + + + + + + + + A list of nuclides based on which to evaluate the weight. Nuclides need to exist in the nuclide table. + Values are nuclide (isotope) hash values using the following hashing rule :math:`H = Z + N \cdot 256` + with :math:`Z` the number of protons and :math:`N` the number of neutrons of the nuclide. + For elements set :math:`N` to zero. + + + + + + + + Attribute data for each member of the point cloud. For APM these are the + iontypes generated via ranging. The number of mark data per point is 1 + in the case for atom probe. + + + + + + + + + Weighting factor with which the integrated intensity per grid cell is + multiplied specifically for each point/object. For APM the weight are + positive integer values, specifically the multiplicity of the ion, + according to the details of the weighting_method. + + + + + + diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index e4e4118b68..bc70d81a86 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -46,15 +46,6 @@ - - Name of the program used for creating this dispersion - - - Version of the program used - - - Date and time of creating this dispersion. - @@ -231,4 +222,4 @@ - + \ No newline at end of file diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml new file mode 100644 index 0000000000..632722293e --- /dev/null +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -0,0 +1,299 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + Number of pattern + + + + + Number of azimuthal integration bins + + + + + Number of coordinates along i axis. + + + + + Number of coordinates along j axis. + + + + + Application definition for minimal example in-situ calorimetry. + + What is the technique about. + + General context. + + Literature references. + + + + + + + + + + + + + + + + + + + + + + + + + + Reference to the resource which stores acquired pattern from the experiment. + + Can refer to the original EMD or MRC files or the parsed NXem in RDM e.g. NOMAD OASIS. + + + + + + + + + Reference to the resource which stores actuator log file from the experiment. + + + + + + + + + Assumptions and computations whereby timestamp data from the + detector used for collecting diffraction pattern and the actuator + (heating chip) were synchronized. + + + + + + + + + + Timestamp when pattern acquisition started. + + + + + + + + Timestamp when pattern acquisition ended. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Acquired diffraction pattern azimuthally integrated as a function of time. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Time since start of the in-situ experiment + + + + + + + + + + + + + + + + + + + + + + Azimuthally integrated diffraction intensities corrected for background as a + function of time. + + + + + + + + + + + + + + + + + + + + + + + + + + + + Time since start of the in-situ experiment + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXgraph_edge_set.nxdl.xml b/contributed_definitions/NXgraph_edge_set.nxdl.xml index 69440ae0c4..99adeb4d8b 100644 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ b/contributed_definitions/NXgraph_edge_set.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,9 +33,19 @@ - A set of (eventually directed) edges which connect nodes/vertices of a graph. + A set of (eventually directed) edges which connect nodes of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of :ref:`NXgraph_root` is defined by this instance. - + + + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_edge_set` + refers to. + + + Total number of edges, counting eventual bidirectional edges only once. @@ -43,14 +53,13 @@ Integer which specifies the first index to be used for distinguishing - edges. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + edges. Identifiers are defined either implicitly or explicitly. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. + + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. @@ -61,7 +70,7 @@ - + Specifier whether each edge is non-directional, one-directional, or bidirectional. Use the smallest available binary representation @@ -77,34 +86,33 @@ - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. + Pairs of node/vertex identifier. Each pair represents the connection + between two nodes. The order in the pair encodes eventual directionality. - In the case that the edge is non- or bi-directional - node identifier should be stored in ascending order is preferred. + In the case that an edge is non- or bi-directional, storing + node identifier in ascending order is preferred. - In the case of one-directional, for each pair the identifier of the source - node is the first entry in the pair. The identifier of the target is the - second entry in the pair, i.e. the pair encodes the information as - if one traverses the edge from the source node walking to the target node. + In the case that an edge is one-directional, node identifier should be + stored such that the identifier of the source node is the first entry + and the identifier of the target is the second entry in the pair. - + A human-readable qualifier which type or e.g. class instance the edge is an instance of. - + - + - A human-readable label/caption/tag for the edge. + A human-readable label/caption/tag of each edge. diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml index 9b98765d21..744f8ae9be 100644 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ b/contributed_definitions/NXgraph_node_set.nxdl.xml @@ -1,4 +1,4 @@ - + - - + The symbols used in the schema to specify e.g. dimensions of arrays. - + - The dimensionality of the graph. Eventually use one for categorical. + The cardinality of the set, i.e. the number of nodes of the graph. - + - The cardinality of the set, i.e. the number of nodes/vertices of the graph. + The dimensionality of the graph. Eventually use one for categorical. - A set of nodes/vertices in space representing members of a graph. + A set of nodes representing members of a graph. + + Use as a direct child of an instance of :ref:`NXgraph_root`. + Alternatively, use depends_on to specify which instance + of NXgraph_root is defined by this instance. - - + + + Specify which instance of :ref:`NXgraph_root` this :ref:`NXgraph_node_set` + refers to. + + + + + About which space does the graph make statements. + + + + + + + + + Dimensionality of the space about which the graph makes statements. + Use only when value of the field space is euclidean. + + + + + + + + + + Number of nodes of the graph. + + Integer which specifies the first index to be used for distinguishing - nodes. Identifiers are defined either implicitly - or explicitly. For implicit indexing the identifiers are defined on the - interval [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. + nodes. Identifiers are defined either implicitly or explicitly. + + For implicit indexing the identifiers are defined on the interval + :math:`[identifier\_offset, identifier\_offset + c - 1]`. - The identifier_offset field can for example be used to communicate if the - identifiers are expected to start from 1 (referred to as Fortran-/Matlab-) - or from 0 (referred to as C-, Python-style index notation) respectively. + For explicit indexing use the field identifier. For implicit indexing, + consult :ref:`NXcg_primitive_set` to get guidance how to set identifier_offset. @@ -64,26 +95,24 @@ - + A human-readable qualifier which type or e.g. class instance the - node is an instance of. As e.g. a NeXus application definition is a - graph, more specifically a hierarchical directed labelled property graph, - instances which are groups like NXgraph_node_set could have an is_a - qualifier reading NXgraph_node_set. + node is an instance of. An example: a NeXus application definition is a + graph, more specifically a hierarchical directed labelled property graph. + Instances which are groups like :ref:`NXgraph_node_set` could have an is_a + qualifier reading :ref:`NXgraph_node_set`. - + - A human-readable label/caption/tag of the graph. + A human-readable label/caption/tag of each node. - diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml index 0e41c38d4f..6fc5f054ce 100644 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ b/contributed_definitions/NXgraph_root.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -32,5 +32,4 @@ - diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 8c4361d279..182fe98106 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,24 +33,35 @@ - Computational geometry description of isocontouring/phase-fields in Euclidean space. + Base class for describing isocontouring/phase-fields in Euclidean space. - Iso-contouring algorithms such as MarchingCubes and others are frequently - used to segment d-dimensional regions into regions where intensities are - lower or higher than a threshold value, the so-called isovalue. + Iso-contouring algorithms such as Marching Cubes and others are frequently + used to segment d-dimensional regions at crossings of a threshold value, + the so-called isovalue. - Frequently in computational materials science phase-field methods are - used which generate data on discretized grids. Isocontour algorithms - are often used in such context to pinpoint the locations of microstructural - features from this implicit phase-field-variable-based description. + In Computational Materials Science phase-field methods are frequently used. + Phase-field variables are discretized frequently using regular grids. + + Isocontour algorithms are often used in such context to pinpoint the + locations of microstructural features from this implicit phase-field- + variable-value-based description. One of the key intentions of this base class is to provide a starting point - for scientists from the phase-field community (condensed matter physicists, - and materials engineers) to incentivize that also phase-field simulation - data could be described with NeXus, provided base classes such as the this one - get further extend according to the liking of the phase-field community. + for scientists from the phase-field community (condensed-matter physicists, + and materials engineers) to incentivize that also phase-field (and other) + simulation data can take advantage of NeXus base class to improve + interoperability. - + + + The dimensionality of the space in which the isocontour is embedded. + + + + + + + The discretized grid on which the iso-contour algorithm operates. diff --git a/contributed_definitions/NXiv_bias.nxdl.xml b/contributed_definitions/NXiv_bias.nxdl.xml new file mode 100644 index 0000000000..a23dd89762 --- /dev/null +++ b/contributed_definitions/NXiv_bias.nxdl.xml @@ -0,0 +1,192 @@ + + + + + + Application definition for bias devices. + + + + Applied a voltage between tip and sample. + + + + + The ratio between the tunneling current at the sample surface and the bias voltage + applied between the sample and the tip. + + + + + Calibration of the Bias output (V/V). + + + + + Allows compensating for an offset in Bias. Hardware parameter offset. + + + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + + + + Bias sweeps while measuring arbitrary channels with I(V) curves. + + + + + Select the channels to record. + + + + + When selected, the Bias voltage returns to the initial value (before starting the sweep) at + the end of the spectroscopy measurement (default). When not selected, Bias remains at the + last value of the sweep. This is useful e.g. when combining several sweep segments. Example + for an automated measurement (using Programming Interface): switch off Z-Controller, start + spectroscopy sweep segments (only fwd sweep, no reset bias), set bias back to initial value, + switch on Z-Controller. + + + + + Select whether to record the Z position during Z averaging time at the end of + the sweep (after Z control time) and store the average value in the header of + the file when saving. Using this option increases the sweep time by Z averaging + time. + + + + + Select whether to set the Lock-In to run during the measurement. When using this + feature, make sure the Lock-In is configured correctly and settling times are + set to twice the Lock-In period at least. This option is ignored when Lock-In is + already running. This option is disabled if the Sweep Mode is MLS and the flag + to configure the Lock-In per segment in the Multiline segment editor is set. + + + + + Time during which the spectroscopy data are acquired and averaged. + + + + + Number of sweeps to measure and average. + + + + + The first bias values of the sweep. + + + + + The last bias values of the sweep. + + + + + Define the sweep number of points, that is, the maximum spectrum resolution eq. + Bias window divide by Num Pixel. + + + + + Duration over which the Z position is recorded and averaged before and after the + sweep (the latter only if Record final Z position is selected in the Advanced + section). After the initial Z averaging time, if Z-Controller to Hold is + selected in the Advanced section, the Z-Controller is set to hold and the tip is + placed at the previously averaged Z position (plus Z offset). + + + + + Select a filter to smooth the displayed data. When saving, if any filter + selected, filtered data are saved to file along with the unfiltered data. + + + + + Filter order of a dynamic filter or width (in number of points) for the gaussian + filter. + + + + + Cutoff frequency for dynamic filters. + + + + + Offset added to the initial averaged position Zaver before starting to sweep. + This parameter is disabled when Z-Controller to Hold is deselected in the + Advanced section. The LED “Alt” next to the Z offset indicates if an alternate + Z-controller setpoint is enabled. + + + + + time to wait after changing the bias to the next level and before starting to + acquire data. + + + + + Time to wait after the sweep has finished and the bias is ramped to the initial + value. + + + + + Time during which the Z-Controller is enabled once a sweep has finished. When + averaging multiple sweeps (i.e. Sweeps>1), the Z-Controller is enabled for this + duration between each sweep. After the last sweep, it will wait the specified + time before continuing a running scan. This ensures each sweep reliably starts + from the same position. This parameter is disabled when Z-Controller to Hold is + deselected in the Advanced section. + + + + + Maximum rate at which the bias changes (before, during and after sweeping). + (V/s) + + + + + Select whether to measure the backward (return) sweep or the forward only. + + + + + Select whether to set the Z-Controller on hold (i.e. disabled) during the sweep. + It is selected by default. When deselected, Z-offset and Z-control time + parameters are disabled. + + + diff --git a/contributed_definitions/NXiv_temp.nxdl.xml b/contributed_definitions/NXiv_temp.nxdl.xml index 927c7bba88..6d881019a1 100644 --- a/contributed_definitions/NXiv_temp.nxdl.xml +++ b/contributed_definitions/NXiv_temp.nxdl.xml @@ -51,6 +51,25 @@ + + + + Descriptive name or ideally (globally) unique persistent identifier. + + + + + List of comma-separated elements from the periodic table + that are contained in the sample. + If the sample substance has multiple components, all + elements from each component must be included in `atom_types`. + + The purpose of the field is to offer materials database systems an + opportunity to parse the relevant elements without having to interpret + these from the sample history or from other data sources. + + + diff --git a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml index 8bb1e4f93e..e9a3ae64da 100644 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ b/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -54,7 +54,7 @@ - + diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml index 9127e40475..4113ea123e 100644 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ b/contributed_definitions/NXlab_sample_mounting.nxdl.xml @@ -1,4 +1,4 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -53,7 +53,7 @@ - + diff --git a/contributed_definitions/NXlockin.nxdl.xml b/contributed_definitions/NXlockin.nxdl.xml new file mode 100644 index 0000000000..f72a279d4c --- /dev/null +++ b/contributed_definitions/NXlockin.nxdl.xml @@ -0,0 +1,151 @@ + + + + + + Base classes definition for lock in devices. + + + + Hardware manufacturers and type of lockin amplifier. + + + + + By mixing the input signal (STS signal) with the modulated signal (such as Bias) + and comparing it with the reference signal, they are enhanced and the effects of + noise interference are reduced, resulting in more accurate measurements. + + + + + if Lock-in -- Bias Divider 1/10 or 1/100, Bias divider = + V(ref)/[V(ref)+V(input)] + + + + + Switch the lock-in moulation on or off. + + + + + A modulation signal (such as bias, current et.al.) is a periodic voltage signal, + usually applied to the surface of a sample, which serves to modify the physical + properties of the sample surface and generate weak AC current signals that can + be detected and analysed by instruments such as lock-in amplifiers. + + + + + + Sets the amplitude (in physical units of the modulated signal) of the sine + modulation. + + + + + Sets the frequency of the sine modulation added to the signal to modulate. + + + + + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + + + + + + The number of signals which will be demodulated. + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Cut-off frq (low pass filter) (foreach DemodulatorChannels) + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal. Cut-off frq (hi pass filter) (foreach DemodulatorChannels) + + + + + Sets the cut-off frequency of the low-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + + + + + Order and cut-off frequency of the low-pass filter applied on the demodulated + signals (X,Y). Reducing the bandwidth or increasing the order reduces noise on + the demodulated signals, but will require longer settling and measurement times. + + + + + Sets the cut-off frequency of the high-pass filter (affects the displayed TC (s) + value) for D1. The filter is applied to the demodulated signals (X,Y). + + + + + Order and cut-off frequency of the high-pass filter applied on the demodulation + signal of D!. This is used mainly to suppress a DC component of the demodulation + signal, which would lead to a component at modulation frequency in the + demodulated signals. + + + + + Switch on/off the Sync filter on the demodulated signals (X,Y) on or off. + (foreach DemodulatorChannels) + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. (foreach DemodulatorChannels) + + + + + Time during which the data are acquired and averaged. (for the input filter) + + + + + The order of the harmonic oscillation to detect on the demodulated signals. + (with respect to the modulation frequency) + + + + + Ratio of output signal amplitude to input signal amplitue (V/V). (input gain) + + + diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 482b028d97..fde6b345ab 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -33,13 +33,13 @@ - Settings of a filter to select or remove entries based on their value. + Base class of a filter to select members of a set based on their identifier. - + - Meaning of the filter: + Definition of the logic what the filter yields: Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. + Entries with all other values will be excluded. Blacklist specifies which entries with said value to exclude. Entries with all other values will be included. @@ -51,10 +51,9 @@ - Array of values to filter according to method. For example if the filter - specifies [1, 5, 6] and method is whitelist, only entries with values - matching 1, 5 or 6 will be processed. All other entries will be filtered - out. + Array of values to filter according to method. If the match e.g. specifies + [1, 5, 6] and method is set to whitelist, only entries with values matching + 1, 5 or 6 will be processed. All other entries will be excluded. diff --git a/contributed_definitions/NXmicrostructure.nxdl.xml b/contributed_definitions/NXmicrostructure.nxdl.xml new file mode 100644 index 0000000000..44d462c045 --- /dev/null +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -0,0 +1,776 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + + The number of one-dimensional crystal projections + + + + + The number of one-dimensional interface projections + + + + + + The number of two-dimensional crystal projections + + + + + The number of two-dimensional interface projections + + + + + The number of two-dimensional triple line projections + + + + + The number of two-dimensional line defect projections + + + + + + The number of crystals (grain and sub-grain are exact synonyms for crystal). + + + + + The number of interfaces (grain boundary and phase boundary are subclasses of + interfaces). + + + + + The number of triple junctions (triple line is a exact synonym for triple + junction, triple point is projection of a triple junction). + + + + + The number of quadruple junctions. + + + + + + The dimensionality of the representation that needs to match the value for + configuration/dimensionality + + + + + Base class to describe a microstructure, its structural aspects, associated descriptors, properties. + + Whether one uses a continuum or atomic scale description of materials, these are always a model only of + the true internal structure of a material. Such models are useful as they enable a coarse-graining and + categorizing of properties and representational aspects from which measured or simulated descriptions + can be correlated with properties, i.e. descriptor values. + + Keep in mind that most specimens are thermo-chemo-mechanically processed prior characterization. + Therefore, the characterized microstructure may not have probed the same structure as of the untreated + sample from which the region-of-interests on the specimen were sampled. + + Fields such as time and increment enable a quantification of the spatiotemporal evolution of a materials' + structure by using multiple instances of NXmicrostructure. Both measurements and simulation virtually + always sample this evolution. Most microscopy techniques support to generate only a two-dimensional + representation (projection) of the characterized material. Often materials are characterized only for + specific states or via sampling coarsely in time relative to the timescale at which the + physical phenomena take place. This is typically a compromise between the research questions at hand and technical surplus practical limitations. + + The term microstructural feature covers here crystals and all sorts of crystal defects within the material. + A key challenge with the description of representations and properties of microstructural features is that + features with different dimensionality exist and combinations of features of different dimensionality are + frequently expected to be documented with intuitive naming conventions using flat property lists. + For these key-value dictionaries often folksonomies are used. These can be based on ad hoc documentation + of such dictionaries in the literature and the metadata section of public data repositories. + + NXmicrostructure is an attempt to standardize these descriptions stronger. + + The descriptive variety is large especially for junctions. Like crystals and interfaces, junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or pearl chain of atoms. + Either way the local atomic and electronic environment is different compared to the situation of an ideal crystal, + which gives typically rise to a plethora of configurations of which some yield useful properties. + + Like crystals and interfaces, junctions are assumed to represent groups of atoms that have specific descriptor values + which are different to other features. Taking an example, a triple junction is practically a three-dimensional defect as its atoms + are arranged in three-dimensional space but the characteristics of that defect can often be reduced to a lower-dimensional + description such as a triple point or a triple line. Therefore, different representations can be used to describe the location, + shape, and structure of the defect. As different types of crystal defects can interact, there is a substantial number of + in principle characterizable and representable objects. Take again a triple line as an example. It is a tubular feature built from three + adjoining interfaces. However, dislocations as line defects can interact with triple lines. Therefore, one can also argue that + along a triple line there can be dislocation-line-triple-line junctions, likewise dislocations form own junctions. + + It is not the aim of this base class to cover all these cases, rather this base class currently provides examples how the + typically most relevant types of features can be represented using a combination of base classes in NeXus. Currently, + these are crystals, interfaces, triple lines, quadruple junctions. + + The description attempt here took inspiration from `E. E. Underwood <https://doi.org/10.1111/j.1365-2818.1972.tb03709.x>`_ + and E. E. Underwood's book on Quantitative Stereology published 1970 to categorize features based on their dimensionality. + + Identifiers can be defined either implicitly or explicitly. Identifiers for implicit indexing are defined + on the interval :math:`[identifier\_offset, identifier\_offset + cardinality - 1]`. + + + + + Discouraged free-text field for leaving comments. + + + + + ISO8601 with offset to local time zone included when a timestamp is required. + + + + + Measured or simulated physical time stamp for this microstructure snapshot. + Not to be confused with wall-clock timing or profiling data. + + + + + Iteration or increment counter. + + + + + Group where to store details about the configuration and parameterization of algorithms + used whereby microstructural features were identified. + + + + Dimensionality of Euclidean space in which the analysis is performed. + + This field can be used e.g. by a research data management system to identify + if the description specifies one-, two-, or three-dimensional microstructural representations. + + + + + + + + + + Algorithm whereby interfaces between crystals were reconstructed. + + * Disorientation clustering groups nearby material points based on their crystallographic disorientation + * Fast multiscale clustering based on `D. Kushnir et al. <https://doi.org/10.1016/j.patcog.2006.04.007>`_ + * Markov chain clustering `F. Niessen et al. <https://doi.org/10.1107/S1600576721011560>`_ + + + + + + + + + + + + Threshold to define at which disorientation angle to assume two crystalline regions have a significant + orientation difference that warrants to assume that there exists an interface between the two regions. + + + + + The program with which the microstructure was reconstructed. + + + + + + + + + + + + + + One- or two-dimensional projections, or three-dimensional representations of crystals. + + An example for a volume bounded by other crystal defects. Crystals can be grains of + different phases, precipitates, dispersoids; there are many terms used specifically in + the materials engineering community. + + Typically, crystals are measured on the surface of a sample via optical or electron microscopy. + Using X-ray diffraction methods crystals can be observed in bulk specimens. + + Crystals are represented by a set of pixel, voxel, or polygons and their polyline boundaries. + In rare cases the volume bounded gets represented using constructive solid geometry approaches. + + + + + Reference to an instance of: + + * :ref:`NXcg_polyline_set` for a one-dimensional representation as only a projection is available (like in linear intercept analysis) + * :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyhedron_set` or :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions + (like in computer simulations or 3D experiments) + + which represent the geometrical entities of the discretization. + + + + + How many crystals are distinguished. + + Crystals are listed irrespective of the phase to which these are assigned. + + + + + How many phases are distinguished. + + Phases are typically distinguished based on statistical thermodynamics argument and crystal structure. + + + + + First identifier whereby to identify crystals implicitly. + + + + + Identifier whereby to identify each crystal explicitly. + + + + + + + + First identifier whereby to identify phases implicitly. + + + + + Identifier whereby to identify phase for each crystal explicitly. + + + + + + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Average disorientation angle for each crystal between individual orientations + of that crystal evaluated as a summary statistic for all probed positions vs the + average disorientation of that crystal. + + + + + + + + Length of each crystal + + + + + + + + Area of each crystal. + + + + + + + + Volume of each crystal + + + + + + + + + One- or two-dimensional projections or three-dimensional representation of interfaces + between crystals as topological entities equivalent to dual_junctions. + + An example for a surface defect. Most important are interfaces such as grain and phase boundaries + but factually interfaces also exist between the environment and crystals exposed at the + surface of the specimen or internal surfaces like between crystals, cracks, or pores. + + + + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) + * :ref:`NXcg_polyline_set` or :ref:`NXcg_polygon_set` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + (like in computer simulations or 3D experiments) + + which represent the geometrical entities of the discretization. + + + + + How many interfaces are distinguished. + + + + + First identifier whereby to identify interfaces implicitly. + + + + + Identifier whereby to identify each interface explicitly. + + + + + + + + + Set of pairs of crystal_identifier for each interface. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + Set of pairs of phase_identifier for each interface. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + + Set of pairs of triple_junction_identifier for each interface. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Gibbs free surface energy for each interface. + + + + + + + + Non-intrinsic mobility of each interface. + + + + + + + + The length of each interface if only projections are available. + + This is not necessarily the same as the length of the individual + polyline segments whereby the interface is discretized. + + + + + + + + The surface area of all interfaces. + + + + + + + + + Projections or representations of junctions at which three interfaces meet. + + An example for a line defect. Triple junctions are characterized as triple lines or triple points as their projections, + or junctions observed between crystals (at the specimen surface exposed to an environment) + (including wetting phenomena) or inside the specimen (crack, pores). + + + + Reference to an instance of: + + * :ref:`NXcg_point_set` for a one-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyline_set` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_polygon_set` for a two-dimensional representation in the (seldom) case of sufficient spatial resolution + and the line in the projection plane or cases where triple junction locations are approximated e.g. using a set of triangles + * :ref:`NXcg_polyhedron_set` for a three-dimensional representation via e.g. a representation of Voronoi cells about atoms + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + which represent the geometrical entities of the discretization. + + + + + Number of triple junctions. + + + + + First identifier to identify triple junctions implicitly. + + + + + Identifier to identify each triple junction explicitly. + + + + + + + + + Set of identifier for positions whereby to identify the location of each + junction. + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + Explicit positions. + + + + + + + + + Set of tuples of identifier of crystals connected to the junction for each + triple junction. + + + + + + + + + + Set of tuples of identifier of interfaces connected to the junction for each + triple junction. + + + + + + + + The specific interface identifiers whereby to resolve ambiguities. + + + + + + + Set of tuples of identifier for polyline segments connected to the junction for + each triple junction. + + + + + + + + The specific polyline identifiers whereby to resolve ambiguities. + + + + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Specific line energy of each triple junction + + + + + + + + Non-intrinsic mobility of each triple junction. + + + + + + + + The length of each triple junction. + + This is not necessarily the same as the length of the individual + polyline segments whereby the junction is discretized. + + + + + + + + The volume of the each triple junction + + + + + + + + + Quadruple junctions as a region where four crystals meet. + + An example for a point defect. + + + + Reference to an instance of: + + * :ref:`NXcg_point_set` + * :ref:`NXcg_grid` for regularly pixelated or voxelated representation in one, two, or three dimensions using (boolean) masks + + + + + Number of quadruple junctions. + + + + + First identifier to identify quadruple junctions implicitly. + + + + + Identifier to identify each quadruple junction explicitly. + + + + + + + + + Set of identifier for positions whereby to identify the location of each + junction. + + + + + + + The specific point identifier whereby to resolve ambiguities. + + + + + + Explicit positions. + + + + + + + + + + Set of tuples of identifier of crystals connected to the junction for each + junction. + + + + + + + + The specific identifier to instances of crystal identifiers whereby to resolve + ambiguities. + + + + + + Set of tuples of identifier of interfaces connected to the junction for each + junction. + + + + + + + + The specific identifier to instances of interface identifiers whereby to resolve + ambiguities. + + + + + + + Set of tuples of identifier for triple junctions connected to the junction for + each quadruple junction. + + + + + + + + The specific identifier to instances of triple junction identifiers whereby to + resolve ambiguities. + + + + + + + Set of tuples of identifier for phases of crystals connected to the junction for + each quadruple junction. + + + + + + + + The specific identifier to instances of phase identifier whereby to resolve + ambiguities. + + + + + + + True or false value, one for each crystal, to communicate whether that feature + makes contact with the edge of the ROI. + + + + + + + + Energy of the quadruple_junction as a defect. + + + + + + + + Non-intrinsic mobility of each quadruple_junction. + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml new file mode 100644 index 0000000000..e078938cfa --- /dev/null +++ b/contributed_definitions/NXmicrostructure_gragles_config.nxdl.xml @@ -0,0 +1,369 @@ + + + + + + + Application definition for configuring GraGLeS. + + GraGLeS is a continuum-scale model for shared-memory-parallelized simulations + of the isothermal evolution of 2D and 3D grain boundary networks with a level-set approach. + CPU parallelization is achieved with OpenMP. + + The code has been implemented by C. Mießen in the group of G. Gottstein + at the Institute für Metallkunde und Metallphysik, RWTH Aachen University. + + Details of the model are summarized in `C. Mießen <https://publications.rwth-aachen.de/record/709678>`_. + + + + + + + + + + Simulation ID as an alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + From which file should the microstructure be instantiated. + + + + + + + + + The formulation of mean curvature flow in the GraGLeS model is scale invariant. + Therefore, the discretization has to be scaled to the actual physical length + of the simulation domain (ve, ROI). + For GraGLeS the discretization is always a square or cubic axis-aligned + bounding box with a regular tiling into material points + (either squares or cubes respectively). + + Edge_length is the length of the entire domain along its edge not + the length of the Wigner-Seitz cell about each material point! + + + + + + Configuration when snapshots of the system should be taken. + + Keep in mind that essentially geometry snapshot data store the + polylines and polyhedra of all grains which can take substantial disk + space. + + + + Generate a snapshot of the properties of the grains to follow + the evolution of the microstructure every :math:`n`-th iteration. + Setting zero causes that no property snapshots are taken. + + + + + Generate a snapshot of the geometry of the entire grain boundary network + every :math:`n`-th iteration. Setting zero instructs to store no geometry data. + + + + + + + Configuration when the simulation should be stopped in a controlled manner. + Whichever criterion is fulfilled first triggers the controlled stop of + and termination of GraGLeS. + + + + The simulation stops if the total number of grains + becomes smaller than this criterion. + + + + + The simulation stops if more iterations than this criterion have been computed. + + + + + + Configuration of numerical details of the solver. + + + + + Which type of convolution kernel and model is used. + + + + + + + + + + Constant to calibrate the real time scaling of the simulation. + + + + + + + Configuration of the grid coarsement algorithm whereby the representation + of the system is continuously rediscretized such that on average grains + are discretized with discretization many material points along each + direction. + + Grid coarsement can reduce the computational costs substantially although + it cannot be ruled out completely that the rediscretizing may have an effect + on the system evolution. Without grid coarsement the total number of material + points to consider stays the same throughout the simulation. + + + + Number of material points along each direction to discretize the + average grain. The larger this value is chosen the finer the curvature + details are that can be resolved but also the longer the simulation + takes. + + + + + If true grid coarsement is active, otherwise it is not. + + + + + Fraction how strongly the number of grains has to reduce + to trigger a grid coarsement step in an iteration. + + + + + + + Physically-based model of the assumed mobility of the grain boundaries. + + Grain boundary mobility is not an intrinsic property of a grain boundary but system-dependent + especially as grain boundaries in reality are decorated with defects as a consequence of which + the actual mobility is a combination of the mobility of the individual defects and the attached + boundary patches. Grain boundaries have different degrees of microscopic freedom. + Therefore, their mobility follows a distribution. + + + + + Fundamental model how :math:`m` is assumed a function of the disorientation + angle :math:`\Theta`. + + + + + + + + + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + + + + + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + + + + + + Mobility scaling factor :math:`c_2`. Typically 5. + + + + + Mobility scaling factor :math:`c_3`. Typically 9. + + + + + + Physically-based model of the assumed grain boundary surface energy. + + Like for the grain boundary mobility, defects cause a distribution of energies for the + patches of which the boundary is composed. In practice a too complicated dependency + of the energy and mobility model is observed as a function of the type and chemical + decoration of the defects. Therefore, simplifying assumptions are typically made. + + + + Fundamental type of assumption if energies are considered isotropic or not. + + + + + + + + + Fundamental model how :math:`\gamma` is assumed a function of the disorientation + angle :math:`\Theta`. + + + + + + + + Mean grain boundary surface energy that is assumed a function of the + disorientation angle :math:`\Theta` of the adjoining grains :math:`\gamma(\Theta)`. + This value factorizes the curvature_driving_force model. + + + + + + + A continuum-scale curvature of an interface causes the interface to + migrate towards the center of the curvature radius. + + + + If true the curvature_driving_force is considered, otherwise it is not. + + + + + + A continuum-scale difference of the stored elastic energy in dislocation + configurations across a grain boundary can exert a driving force on the + grain boundary such that the boundary migrates into the volume with the + higher stored elastic energy. + + + + If true the dislocation_driving_force is considered, otherwise it is not. + + + + + Prefactor :math:`0.5Gb^2` that factorizes the average + stored elastic energy per length dislocation line. + + + + + + In case of an applied magnetic field, a difference of the magnetic + susceptibility can exert a driving force on the grain boundary such that + the boundary migrates into the volume with the higher magnetic energy. + + + + If true the magnetic_driving_force is considered, otherwise it is not. + + + + + + + A triple line mediates the atomic arrangement differences between three + interface patches. Therefore, the triple line is a defect that may not + have the same mobility as adjoining grain boundaries and thus it may + exert what can be conceptualized as a drag (resistance) to the motion + of the adjoining interface patches. + + + + Assumed triple junction drag. + + + + + + diff --git a/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml new file mode 100644 index 0000000000..2f25c33a61 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_gragles_results.nxdl.xml @@ -0,0 +1,295 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of summary statistic log entries. + + + + + Number of grains in the computer simulation. + + + + + Number of interfaces in the computer simulation. + + + + + Application definition for documenting results with GraGLeS. + + + + + + + + + + + Simulation ID as an alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + + + + + + + + + + + + + + + Documentation of the spatiotemporal evolution + + + + + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening in for practical reasons though in while + running the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. + + + + Evolution of the recrystallized volume fraction over time. + + + + Evolution of the physical time not to be confused with wall-clock time or + profiling data. + + + + + + + + Iteration or increment counter. + + + + + How many crystals are distinguished. + Crystals are listed irrespective of the phase to which these are assigned. + + + + + + + + + + Which type of stress. + + + + + + + + Applied external stress tensor on the ROI. + + + + + + + + + + + + Which type of strain. + + + + + Applied external strain tensor on the ROI. + + + + + + + + + + + + Which type of deformation gradient. + + + + + + + + Applied deformation gradient tensor on the ROI. + + + + + + + + + + + + Applied external magnetic field on the ROI. + + + + + + + + + + + + + Applied external electrical field on the ROI. + + + + + + + + + + + + + + + + Simulated temperature for this snapshot. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Set of pairs of crystal_identifier for each interface. + + + + + + + + + + Mobility times surface energy density of the interface normalized + to the maximum such product of the interface set. + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml new file mode 100644 index 0000000000..a98be4dd41 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_imm_config.nxdl.xml @@ -0,0 +1,244 @@ + + + + + + + + How many texture components are distinguished, minimum is 1. + + + + + How many special texture components are distinguished if any. + + + + + Number of discrete orientations that are distributed across the grains. + + + + + Application definition for the configuration of the legacy (micro)structure generator + developed by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. + + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ + * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ + * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ + * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ + + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. + + + + + + + + + + The computational domain will be synthesized either as a square (for dimensionality = 2) + or a cube (for dimensionality = 3) with axis-aligned cuboidal parent grains. The domain is + discretized into material points using either square pixel or cubic voxel as the tessellating + unit cells. + + + + Two-dimensional or three-dimensional simulation. + + + + + + + + + Target value for the number of material points per equivalent + discrete diameter of the arithmetic average sub-grain. + + + + + Assumed space group of the material. + + + + + + + + + + + Target value for the number of grains. The actual domain size and grid will be configured + based on the choices for discretization, number_of_grains, and shape of these grains. + + + + + Target value for the average number of sub-grains per grain. + + + + + + If available used to define the sequence of relative extent of grains along the y (first value) + and z-axis (second value) assuming the relative shape along the x-axis is 1. If not provided, + the relative extent of the grains will be 1 one average along each axis (globulitic structure). + + + + + + + + + + In texture research component analyses set on the idea that properties + of grains different based on orientation with certain regions in orientation + space show similar trends like a different average dislocation density + or orientation_spread. + + + + The first entry is always the null model None which measn that an orientation + is not categorized as a special component. Examples for special components are + Dillamore, Copper, Cube, Y, P and Q. + + + + + + + + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + + + + + + + + + Disorientation angle below which an orientation is categorized as one of the + components. + + + + + + + + + Dislocations are modelled as Rayleigh-distributed mean-field density that + can differ between but is constant within grains and sub-grains. + + + + The minimum and the maximum dislocation density to distribute across grains. + + + + + + + + + The minimum and the maximum dislocation density to distribute across sub-grains. + + + + + + + + + + + The variance of the dislocation density distribution across the grains. + + + + + + + + The variance of the dislocation density distribution across the sub-grains. + + + + + + + + + Orientations of the grains are sampled from a set of Bunge-Euler angle triplets. + Orientations of the sub-grains are sampled by scattering the orientation + of the (parent) grain and with optional Rayleigh-distributed scatter. + + + + Bunge-Euler angle parameterization of the texture components + location in orientation space for which specifically different settings + should be configured. + + + + + + + + + The variance of the disorientation of the sub-grain to their parent grain. + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml new file mode 100644 index 0000000000..7d0dabed31 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_imm_results.nxdl.xml @@ -0,0 +1,189 @@ + + + + + + + + Number of material points along the edge of the square- or cube-shaped domain. + + + + + Number of crystals. + + + + + Application definition for the results of the legacy (micro)structure generator developed + by the Institut für Metallkunde und Metallphysik at RWTH Aachen University. + + * `N. Leuning et al. <https://doi.org/10.3390/ma14216588>`_ + * `C. Mießen <https://doi.org/10.18154/RWTH-2017-10148>`_ + * `M. Kühbach <https://doi.org/10.18154/RWTH-2018-00294>`_ + * `M. Kühbach et al. <https://github.com/mkuehbach/GraGLeS>`_ + + The tool can be used to instantiate specific configurations for two- and three-dimensional discretized microstructures. + Specifically, single-phase material that is composed of crystals, so-called (parent) grains which are tessellated into so-called sub-grains. + Grains are modelled as elongated crystals to mimic fundamental geometrical constraints of the interface network in deformed material. + + + + + + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + Default plot showing the grid. + + + + + + + + Crystal identifier that was assigned to each material point. + + + + + + Material point barycentre coordinate along z direction. + + + + + + + Coordinate along z direction. + + + + + + Material point barycentre coordinate along y direction. + + + + + + + Coordinate along y direction. + + + + + + Material point barycentre coordinate along x direction. + + + + + + + Coordinate along x direction. + + + + + + + + + + + + + + + + + + + + + + + + + + True if the crystal is considered a sub-grain. + False if the crystal is considered a grain. + + + + + + + + Bunge-Euler angle orientation of each crystal. + + + + + + + + + Mean-field dislocation density as a measure of the stored elastic energy + content that is stored in the dislocation network of this grain and related + defects within each crystal. + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml new file mode 100644 index 0000000000..38256637b9 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -0,0 +1,243 @@ + + + + + + + + Number of pixel along the z slowest direction. + + + + + Number of pixel along the y slow direction. + + + + + Number of pixel along the x fast direction. + + + + + Number of RGB values along the fastest direction, always three. + + + + + Base class to store an inverse pole figure (IPF) mapping (IPF map). + + + + Reference to an :ref:`NXcoordinate_system` in which the projection_direction is defined. + + If the field depends_on is not provided but parents of the instance of this base class or its + specializations define an instance of :ref:`NXcoordinate_system`, projection_direction + is defined in this coordinate system. + + If nothing is provided it is assumed that projection_direction is defined in the McStas coordinate system. + + + + + The direction along which orientations are projected. + + + + + + + + Details about the original grid. + + Here original grid means the grid for which the IPF map was computed when that + IPF map was exported from the tech partner's file format representation. + + + + + Details about the grid onto which the IPF is recomputed. + + Rescaling the visualization of the IPF map may be needed to enable + visualization in specific software tools like H5Web. + + + + + How where orientation values at positions of input_grid computed to values on output_grid. + + Nearest neighbour means the orientation of the closed (Euclidean distance) grid point of the input_grid was taken. + + + + + + + + Inverse pole figure mapping. + + phase. No ipf_mapID instances for non-indexed scan points as these are + by definition assigned the null phase with phase_identifier 0. + Inspect the definition of :ref:`NXcrystal_structure` and its field + phase_identifier for further details. + + Details about possible regridding and associated interpolation + during the computation of the IPF map visualization can be stored + using the input_grid, output_grid, and interpolation fields. + + The main purpose of this map is to offer a normalized default representation + of the IPF map for consumption by a research data management system (RDMS). + This is aligned with the first aim of :ref:`NXmicrostructure_ipf`, to bring colleagues + and users of IPF maps together to discuss which pieces of information need storage. + + We are convinced a step-by-step design and community-driven discussion is a practical + strategy to work towards an interoperable description and data model for exchanging + IPF maps as a specific community-accepted method to convey orientation maps. + + With this design the individual RDMS solutions and tools can still continue + to support specific custom data analyses workflow and routes but at least + there is one common understanding which enables also those users who are + not necessarily experts in all the details of the underlying techniques an + understanding if the dataset is worth to become reused or repurposed. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel center coordinate calibrated for step size along the z axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the y axis of the map. + + + + + + + + + Pixel center coordinate calibrated for step size along the x axis of the map. + + + + + + + + + + The color code which maps colors to orientation in the fundamental zone. + + For each stereographic standard triangle (SST), i.e. a rendering of the + fundamental zone of the crystal-symmetry-reduced orientation space + SO3, it is possible to define a color model which assigns a color to each + point in the fundamental zone. + + Different mapping models are used. These implement (slightly) different + scaling relations. Differences exist across representations of tech partners. + + Differences are which base colors of the RGB color model are placed in + which extremal position of the SST and where the white point is located. + + For further details see: + + * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + * [S. Patala et al.](https://doi.org/10.1016/j.pmatsci.2012.04.002). + + Details are implementation-specific and not standardized yet. + + Given that the SST has a complicated geometry, it can not yet be + visualized using tools like H5Web, which is why for now the matrix + of a rasterized image which is rendered by the backend tool gets + copied into an RGB matrix to offer a default plot. + + + + + + Inverse pole figure color code for each map coordinate. + + + + + + + + + + Pixel along the y-axis. + + + + + + + + + Pixel along the x-axis. + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml new file mode 100644 index 0000000000..5b85f6473d --- /dev/null +++ b/contributed_definitions/NXmicrostructure_kanapy_results.nxdl.xml @@ -0,0 +1,193 @@ + + + + + + + + Number of material points along the z axis of the domain. + + + + + Number of material points along the y axis of the domain. + + + + + Number of material points along the x axis of the domain. + + + + + Number of crystals. + + + + + Application definition for the microstructure generator kanapy from ICAMS Bochum. + + * `A. Hartmeier et al. <https://joss.theoj.org/papers/10.21105/joss.01732>`_ + + A draft application definition to support discussion within the infrastructure use case IUC07 of the + NFDI-MatWerk consortium of the German NFDI working on a data model for documenting simulations + of spatiotemporal microstructure evolution with scientific software from this community. + + + + + + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + + + + Default plot showing the grid. + + + + + + + + Crystal identifier that was assigned to each material point. + + + + + + Material point barycentre coordinate along z direction. + + + + + + + Coordinate along z direction. + + + + + + Material point barycentre coordinate along y direction. + + + + + + + Coordinate along y direction. + + + + + + Material point barycentre coordinate along x direction. + + + + + + + Coordinate along x direction. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Bunge-Euler angle orientation of each crystal. + + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml new file mode 100644 index 0000000000..2dae22c987 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -0,0 +1,321 @@ + + + + + + + + Number of entries in the default color map + + + + + Number of entries in color map + + + + + Base class to store the configuration when using the MTex/Matlab software. + + MTex is a Matlab package for texture analysis used in the Materials and Earth Sciences. + See `R. Hielscher et al. <https://mtex-toolbox.github.io/publications>`_ and + the `MTex source code <https://github.com/mtex-toolbox>`_ for details. + + + + Reference frame and orientation conventions. + Consult the `MTex docs <https://mtex-toolbox.github.io/EBSDReferenceFrame.html>`_ for details. + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + TODO with MTex developers + + + + + + + + + + + Settings relevant for generating plots. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + True if MTex renders a scale bar with figures. + + + + + True if MTex renders a grid with figures. + + + + + Code for the function handle used for annotating pole figure plots. + + + + + TODO with MTex developers + + + + + + + + + TODO with MTex developers + + + + + + + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous other settings of MTex. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + + Miscellaneous settings relevant for numerics. + + + + Return value of the Matlab eps command. + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Miscellaneous settings relevant of the system where MTex runs. + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + TODO with MTex developers + + + + + + Collection of paths from where MTex reads information and code. + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + Absolute path to specific component of MTex source code. + + + + + List of file type suffixes for which MTex assumes + texture/pole figure information. + + + + + List of file type suffixes for which MTex assumes EBSD content. + + + + + diff --git a/contributed_definitions/NXmicrostructure_odf.nxdl.xml b/contributed_definitions/NXmicrostructure_odf.nxdl.xml new file mode 100644 index 0000000000..764e0ab77d --- /dev/null +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -0,0 +1,224 @@ + + + + + + + + Number of pixel per varphi section plot along the :math:`\varphi_1` fastest + direction. + + + + + Number of pixel per varphi section plot along the :math:`\Phi` fast direction. + + + + + Number of pixel per varphi section plot along the :math:`\varphi_2` slow + direction. + + + + + Number of local maxima evaluated in the component analysis. + + + + + Number of sampled positions in orientation space. + + + + + Base class to store an orientation distribution function (ODF). + + An orientation distribution function is a probability distribution that details how + much volume of material has a specific orientation. An ODF is computed from + pole figure data in a computational process called `pole figure inversion <https://doi.org/10.1107/S0021889808030112>`_. + + + + Details about the algorithm used for computing the ODF. + + + + Point group of the crystal structure of the phase for which the here documented phase- + dependent ODF was computed.(following the notation of the International Table of Crystallography). + + + + + Point group assumed for additionally considered sample symmetries + following the notation of the International Table of Crystallography). + + + + + Halfwidth of the kernel. + + + + + Name of the kernel. + + + + + Resolution of the kernel. + + + + + + + Group to store descriptors and summary statistics for extrema of the ODF. + + + + Minima or maxima, if extrema is set to minima values for location and volume_fraction + are sorted in increasing order. If extrema is set to maxima values for location and + volume_fraction are sorted in descreasing order. Therefore, the global extremum is + always the first entry in location and volume_fraction. + + + + + + + + + Number of local extrema evaluated + + + + + + Disorientation threshold within which intensity of the ODF + is integrated for the component analysis. + + + + + Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the kth-most + maxima in decreasing order of the intensity maximum. + + + + + + + + + Integrated ODF intensity within a theta angular region of the orientation space (SO3) + about each location (obeying symmetries) as specified for each location. + + + + + + + + + The ODF intensity values (weights) as sampled with a software + + + + Sampling resolution + + + + + Bunge-Euler (i.e. ZXZ convention) locations of each position + in orientation space for which a weight was sampled. + + + + + + + + + Weight at each sampled position following the order in euler. + + + + + + + + + Visualization of the ODF intensity as discretized orthogonal sections through + orientation space parameterized using Bunge-Euler angles. + + This is one example of typical default plots used in the texture community in materials engineering. + + Mind that when parameterized using Euler angles the orientation space is a distorted space. + Therefore, equivalent orientations show intensity contributions in eventually multiple locations. + + + + + ODF intensity at probed locations relative to the intensity of the null model of + a random texture. + + + + + + + + + + Pixel center angular position along the :math:`\varphi_1` direction. + + + + + + + + + Pixel center angular position along the :math:`\Phi` direction. + + + + + + + + + Pixel center angular position along the :math:`\varphi_2` direction. + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_pf.nxdl.xml b/contributed_definitions/NXmicrostructure_pf.nxdl.xml new file mode 100644 index 0000000000..01804b54bf --- /dev/null +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -0,0 +1,114 @@ + + + + + + + + Number of pixel per pole figure in the slow direction. + + + + + Number of pixel per pole figure in the fast direction. + + + + + Base class to store a pole figure (PF) computation. + + A pole figure is the X-ray diffraction intensity for specific integrated + peaks for a hemispherical illumination of a real or virtual specimen. + + + + Details about the algorithm that was used to compute the pole figure. + + + + Point group of the crystal structure of the phase for which the pole figure + was computed (according to International Table of Crystallography). + + + + + Point group of assumed sample symmetries (according to International Table of + Crystallography). + + + + + + Halfwidth of the kernel. + + + + + Miller indices (:math:`(hkl)[uvw]`) to specify the pole figure. + + + + + Resolution of the kernel. + + + + + + Pole figure. + + + + + Pole figure intensity. + + + + + + + + + Pixel center along y direction in the equatorial plane of + a stereographic projection of the unit sphere. + + + + + + + + + Pixel center along x direction in the equatorial plane of + a stereographic projection of the unit sphere. + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_score_config.nxdl.xml b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml new file mode 100644 index 0000000000..082293a3e6 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -0,0 +1,542 @@ + + + + + + + + Number of Bunge-Euler angle triplets for deformed grains. + + + + + Number of Bunge-Euler angle triplets for recrystallization nuclei. + + + + + Number of support points for the linearized drag profile. + + + + + Number of suport points for the desired time-temperature profile. + + + + + Number of entries when to defragment i.e. garbage collect the memory holding + state information for recrystallized cells. + + + + + Number of entries when to collect snapshots of the evolving microstructure. + + + + + Number of solitary unit domains to export. + + + + + Application definition to configure a simulation with the SCORE model. + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + + + + + + + + + + Simulation ID as an alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where stored (elastic) energy + is stored in the form of crystal defects, which in the SCORE model are + is considered as mean-field dislocation content. + + + + + Extend of each CA domain in voxel along the x, y, and z direction. + Deformation of sheet material is assumed. + The x axis is assumed pointing along the rolling direction. + The y axis is assumed pointing along the transverse direction. + The z axis is assumed pointing along the normal direction. + + + + + + + + Details how the deformed grains should be modelled. + + + + Which model should be used to generate a starting microstructure. + + + + + + + + + + + Extent of each deformed grain in voxel along the + x, y, and z direction when type is cuboidal. + + + + + + + + Average spherical diameter when type is poisson_voronoi. + + + + + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of deformed grains randomly from. + + + + + + + + + The EBSD dataset from which the initial microstructure is + instantiated if model is ebsd. + + + + + + + + Extent of the pixel of the EBSD orientation mapping assuming square-shaped + pixels. + + + + + + + + + + Phenomenological model according to which recrystallization nuclei + are placed into the domain and assumed growing. + + + + According to which model will the nuclei become distributed spatially: + + * csr, complete spatial randomness. + * custom, implementation specific. + * gb, nuclei placed at grain boundaries + + + + + + + + + + According to which model will the nuclei start to grow. + + + + + + + + According to which model will the nuclei get their orientation assigned. + + + + + + + + Set of Bunge-Euler angles ( :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + to sample orientations of nuclei randomly from. + + + + + + + + + + (Mechanical) properties of the material which scale + the amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. + + + + Shear modulus at zero Kelvin. + + + + + Magnitude at the Burgers vector at zero Kelvin. + + + + + + Melting temperature in degrees Celsius. + + + + + + Model for the assumed mobility of grain boundaries with different disorientation + essentially implementing variations of Turnbull's model for + thermally-activated migration. + + + + Which type of fundamental model for the grain boundary mobility. + + Grain boundaries with disorientation angle smaller than 15 degree are considered + as low-angle grain boundaries. Other grain boundaries are high-angle boundaries. + + + + + + + + + + Parameter of the Sebald-Gottstein migration model. + + + + At which disorientation angle are grain boundary considered as high-angle grain + boundaries. + + + + + Pre-exponential factor for low-angle grain boundaries. + + + + + Migration activation enthalpy for low-angle grain boundaries. + + + + + Pre-exponential factor for high-angle grain boundaries. + + + + + Migration activation enthalpy for high-angle grain boundaries. + + + + + Pre-exponential factor for particularly mobile boundaries. + + + + + Migration activation enthalpy for particularly mobile boundaries. + + + + + + Parameter of the Rollett-Holm migration model. + + + + + The assumed mobility :math:`m_0` of the fastest grain boundary in the system at the assumed + temperature. GraGLeS was developed for modelling isothermal annealing. + + + + + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not one. + + + + + Mobility scaling factor :math:`c_2`. Typically 5. + + + + + Mobility scaling factor :math:`c_3`. Typically 9. + + + + + + + Time-dependent reduction of the stored (elastic) energy to account for recovery. + + + + Which type of recovery model. + + + + + + + + + Reduction of the grain boundary migration speed due to the presence of dispersoids + through which the total grain boundary area of the recrystallization front can be reduced. + + + + Which type of drag model. + + + + + + + + + Parameter of the Zener-Smith drag model. + + + + Configuration-dependent constant which factorizes the drag pressure. + + + + + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. + + + + + Support point of the linearized curve of simulated time matching + a specific support point of the average dispersoid radius. + + + + + + + + Support point of the linearized curve of the average dispersoid radius. + + + + + + + + + + Desired simulated time-temperature profile + + + + Support point of the linearized curve of simulated time matching + a specific support point of the temperature. + + + + + + + + Support point of the linearized curve of the temperature. + + + + + + + + + Criteria which enable to stop the simulation in a controlled manner. + Whichever criterion is fulfilled first stops the simulation. + + + + Maximum recrystallized volume fraction. + + + + + Maximum simulated physical time. + + + + + Maximum number of iteration steps. + + + + + + Settings relevant for stable numerical integration. + + + + Maximum fraction equivalent to the migration of the + fastest grain boundary in the system how much a cell + may be consumed in a single iteration. + + + + + Fraction of the total number of cells in the CA which + should initially be allocated for offering cells in the + recrystallization front. + + + + + By how much more times should the already allocated memory + be increased to offer space for storing states of cells + in the recrystallization front. + + + + + Should the cache for cells in the recrystallization front + be defragmented on-the-fly. + + + + + Heuristic recrystallized volume target values at which + the cache for cells in the recrystallization front + will be defragmented on-the-fly. + + + + + + + + + + List of recrystallized volume target values at which a + snapshot of the CA state should be stored. + + The code documents summary statistics like recrystallized volume fraction + for each iteration. However, snapshots of the microstructure can take much + space as SCORE is able to evolve automata with up to :math:`1600^3` cells. + Snapshot data document the current microstructure which includes the grain + assigned to each of these cells plus the state of the recrystallization front. + + Despite these front data make up for approximately one order of magnitude + less cells than represented in the domain, more numerical data have to be + collected each cell in the front than just a grain identifier. + + + + + + + + + + Perform a statistical analyses of the results as it was + proposed by M. Kühbach (solitary unit model ensemble approach). + + + + + How many independent cellular automaton domains + should be instantiated. + + + + + Into how many time steps should the real time interval be discretized upon + during post-processing the results with the solitary unit modeling approach. + + + + + List of identifier for those domain which should be rendered. + Identifier start from 0. + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml new file mode 100644 index 0000000000..1e9283c976 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -0,0 +1,543 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The total number of summary statistic log entries. + + + + + Number of boundaries of the bounding box or primitive to domain. + + + + + Number of parameter required for chosen orientation parameterization. + + + + + Number of texture components identified. + + + + + Dimensionality. + + + + + Cardinality. + + + + + Number of active cells in the (recrystallization) front. + + + + + Number of grains in the computer simulation. + + + + + Application definition for storing results of the SCORE cellular automaton. + + The SCORE cellular automaton model for primary recrystallization is an + example of typical materials engineering applications used within the field + of so-called Integral Computational Materials Engineering (ICME) whereby + one can simulate the evolution of microstructures. + + Specifically the SCORE model can be used to simulate the growth of static + recrystallization nuclei. The model is described in the literature: + + * `M. Kühbach et al. <https://doi.org/10.1016/j.actamat.2016.01.068>`_ + * `C. Haase et al. <https://doi.org/10.1016/j.actamat.2015.08.057>`_ + * `M. Diehl et al. <https://doi.org/10.1088/1361-651X/ab51bd>`_ + + + + + + + + + + Simulation ID as an alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + A tight bounding box or sphere or bounding primitive about the grid. + + + + + How many distinct boundaries are distinguished? + Most grids discretize a cubic or cuboidal region. In this case + six sides can be distinguished, each making an own boundary. + + + + + The boundary conditions for each boundary: + + 0 - undefined + 1 - open + 2 - periodic + 3 - mirror + 4 - von Neumann + 5 - Dirichlet + + + + + + + + Name of the boundaries. Left, right, front, back, bottom, top, + The field must have as many entries as there are number_of_boundaries. + + + + + + + + + + Documentation of the spatiotemporal evolution + + + + + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening in for practical reasons though in while + running the simulation. Place used for storing descriptors from continuum mechanics + and thermodynamics at the scale of the entire ROI. + + + + Evolution of the recrystallized volume fraction over time. + + + + Evolution of the physical time not to be confused with wall-clock time or + profiling data. + + + + + + + + Iteration or increment counter. + + + + + Evolution of the simulated temperature over time. + + + + + + + + Recrystallized volume fraction. + + + + + + + + + + Which type of stress. + + + + + + + + Applied external stress tensor on the ROI. + + + + + + + + + + + + Which type of strain. + + + + + Applied external strain tensor on the ROI. + + + + + + + + + + + + Which type of deformation gradient. + + + + + + + + Applied deformation gradient tensor on the ROI. + + + + + + + + + + + + Applied external magnetic field on the ROI. + + + + + + + + + + + + + Applied external electrical field on the ROI. + + + + + + + + + + + + + + + + Simulated temperature for this snapshot. + + + + + Current recrystallized volume fraction (taking fractional infections into + account). + + + + + Target value for which a snapshot was requested for the recrystallized volume + fraction. + + + + + + + Grain identifier for each cell. + + + + + + + + + + Identifier of the OpenMP thread which processed this part of the grid. + + + + + + + + + + + + + + + + + + + + + + + + + + + Volume of each grain accounting also for partially transformed cells. + + + + + + + + + Bunge-Euler angle triplets for each grain. + + + + + + + + + Current value for the dislocation density as a measure of the remaining stored energy + in assumed crystal defects inside each grain. + + + + + + + + Is the grain deformed. + + + + + + + + Is the grain recrystallized. + + + + + + + + + Details about those cells which in this time step represent the discrete + recrystallization front. + + + + Which cells are currently in a halo region of threads. + + + + + + + + So-called mobility weight which is a scaling factor to + control the mobility of the grain boundary which is assumed + to sweep currently this volume. + + + + + + + + The x, y, z grid coordinates of each cell in the recrystallization front. + + + + + + + + + Grain identifier assigned to each cell in the recrystallization front. + + + + + + + + Grain identifier assigned to each nucleus which affected that cell in the + recrystallization front. + + + + + + + + Identifier of the OpenMP thread processing each cell in the recrystallization + front. + + + + + + + + Hint about the direction from which the cell was infected. + + + + + + + + + + + diff --git a/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml new file mode 100644 index 0000000000..ec660d6de6 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -0,0 +1,80 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of slip systems. + + + + + Base class for describing a set of crystallographic slip systems. + + + + Bravais lattice type + + + + + + + + + + + + + + Array of Miller indices which describe the crystallographic planes. + + + + + + + + + + Array of Miller indices which describe the crystallographic direction. + + + + + + + + + For each slip system a marker whether the specified Miller indices refer to + a specific or a crystallographic equivalent set of the slip system. + + + + + + diff --git a/contributed_definitions/NXpositioner_sts.nxdl.xml b/contributed_definitions/NXpositioner_sts.nxdl.xml new file mode 100644 index 0000000000..7d13592b97 --- /dev/null +++ b/contributed_definitions/NXpositioner_sts.nxdl.xml @@ -0,0 +1,310 @@ + + + + + + A generic positioner such as a motor or piezo-electric transducer. + + + + symbolic or mnemonic name (one word) + + + + + description of positioner + + + + + best known value of positioner - need [n] as may be scanned + + + + + + + + raw value of positioner - need [n] as may be scanned + + + + + + + + targeted (commanded) value of positioner - need [n] as may be scanned + + + + + + + + maximum allowable difference between target_value and value + + + + + + + + minimum allowed limit to set value + + + + + maximum allowed limit to set value + + + + + velocity of the positioner (distance moved per unit time) + + + + + time to ramp the velocity up to full speed + + + + + Hardware device record, e.g. EPICS process variable, taco/tango ... + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a positioner. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + To clarify the frame laboratory frame. The scanning area in x, y, and z position in the + frame. + + + + + This controllers task is to continuously adjust the Z position of the stm tip in order + to keep the selected control signal as close as possible to the Set Point. Different control + signals lead to different contronller beahvior. + + + + + Offset added to the initial averaged position Zaver before starting to swepp. + + + + + Indicate the tip position Z between tip and sample. The tip position can also be varied when + the controller is not running. + + + + + Controller name. This name which will be displayed at places where you can select a + controller. + + + + + Set Point is the desired value of the control signal. It can be set by editing the number + or using the slider bar. Click the "Set" button above the input field to use the actual + value as Set Point. The slider shows the Set Point as well as the current value. + + + + + Lifts the tip by the specified amount when then controller is switched off. This can be + a positive or a negative number, i.e. the tip can also be moved towards the sample. Be + careful with sign and value when using this feature. + + + + + Use this parameter for a reproducible position when switching off the Z-controller. + When >0 and the Z-controller is switched off, it doesn't switch off immediately but continues + to run for the specified time and averages the Z position. + + + + + (In bias spectroscopy) Select whether to set the Z-Controller on hold (i.e. disabled) during + the sweep. It is selected by default. When deselected, Z-offset and Z control time parameters + are disabled. + + + + + The final z-position during the bias spectroscopy scan. The availability of values is + related to the mode of scanning. + + + + + + Configure the scan frame like x position; y position; width; height. + + + + + Scan resolution by setting the Lines equal to Pixels. + + + + + Define the image resolution. + + + + + Define the scan forward speed in the forward direction. + + + + + Define the scan backward speed in the forward direction. + + + + + Piezo calibration module is used to define the X Y Z piezos calibration. + + + + + The name of caliberation type. + + + + + + + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and :math:`P/T` + (proportional gain/time constant). The formula for the controller in the frequency domain is: + :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. + The integral gain and time constant are related as follows: :math:`I = P/T`. + + + + + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + P/T (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: `:math:I = P/T`. + + + + + The Type switches controller parameters between :math:`P/I` (proportional gain/integral gain) and + :math:`P/T` (proportional gain/time constant). The formula for the controller in the frequency + domain is: :math:`G(s) = P + I/s = P(1 + 1/(Ts))`. The integral gain and time constant are related + as follows: :math:`I = P/T`. + + + + + + There are 2 parameters in X and Y directions. If you know them, you can enter the 2nd order + piezo characteristics to compensate for it. The following equation shows the interpretation + of the 2nd order correction parameter: For the X-piezo: + :math:`Ux = 1/cx · X + cxx · X2`; with units: :math:`[V] = [V/m] · [m] + [V/m2] · [m2]` + where cx is the calibration of the piezo X and cxx is the 2nd order correction. :math:`(V/m^2)` + + + + + There are 2 parameters in X and Y directions. Define the drift speed for all three axes. + When the compensation is on, the piezos will start to move at that speed. + + + + + Use the button to turn on/off the drift compensation. + + + diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index be67c3c15e..bea9efa218 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -1,10 +1,10 @@ - + - + Variables used to set a common size for collected sensor data. @@ -45,7 +45,7 @@ - + @@ -123,7 +123,7 @@ NXsensor groups. Similarly, seperate NXsensor groups are used to store the readings from each measurement sensor. - For example, in a temperature-dependent IV measurement, the temperature and voltage must be + For example, in a temperature-dependent IV measurement, the temperature and voltage must be present as independently scanned controllers and the current sensor must also be present with its readings. diff --git a/contributed_definitions/NXsensor_sts.nxdl.xml b/contributed_definitions/NXsensor_sts.nxdl.xml new file mode 100644 index 0000000000..31094bd4e1 --- /dev/null +++ b/contributed_definitions/NXsensor_sts.nxdl.xml @@ -0,0 +1,233 @@ + + + + + + A sensor used to monitor an external condition + + The condition itself is described in :ref:`NXenvironment`. + + + + Sensor identification code/model number + + + + + Name for the sensor + + + + + Short name of sensor used e.g. on monitor display program + + + + + where sensor is attached to ("sample" | "can") + + + + + Defines the axes for logged vector quantities if they are not the global + instrument axes. + + + + + name for measured signal + + + + + + + + + + + + + + + + + + + + + The type of hardware used for the measurement. + Examples (suggestions but not restrictions): + + :Temperature: + J | K | T | E | R | S | Pt100 | Pt1000 | Rh/Fe + :pH: + Hg/Hg2Cl2 | Ag/AgCl | ISFET + :Ion selective electrode: + specify species; e.g. Ca2+ + :Magnetic field: + Hall + :Surface pressure: + wilhelmy plate + + + + + + link to second amplifer circuit with 1MOhm + + + + + Is data collection controlled or synchronised to this quantity: + 1=no, 0=to "value", 1=to "value_deriv1", etc. + + + + + Upper control bound of sensor reading if using run_control + + + + + Lower control bound of sensor reading if using run_control + + + + + nominal setpoint or average value + - need [n] as may be a vector + + + + + + + + Nominal/average first derivative of value + e.g. strain rate + - same dimensions as "value" (may be a vector) + + + + + + + + Nominal/average second derivative of value + - same dimensions as "value" (may be a vector) + + + + + + + + Time history of sensor readings + + + + + Time history of first derivative of sensor readings + + + + + Time history of second derivative of sensor readings + + + + + + + + + + + + + + + For complex external fields not satisfied by External_field_brief + + + + + This group describes the shape of the sensor when necessary. + + + + + .. index:: plotting + + Declares which child group contains a path leading + to a :ref:`NXdata` group. + + It is recommended (as of NIAC2014) to use this attribute + to help define the path to the default dataset to be plotted. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + + + + NeXus positions components by applying a set of translations and rotations + to apply to the component starting from 0, 0, 0. The order of these operations + is critical and forms what NeXus calls a dependency chain. The depends_on + field defines the path to the top most operation of the dependency chain or the + string "." if located in the origin. Usually these operations are stored in a + NXtransformations group. But NeXus allows them to be stored anywhere. + + .. todo:: + Add a definition for the reference point of a sensor. + + + + + This is the group recommended for holding the chain of translation + and rotation operations necessary to position the component within + the instrument. The dependency chain may however traverse similar groups in + other component groups. + + + + + External sensors connected to the device. For example, T1, temperature of STM + head. T2, temperature of bottom of LHe helium cryostat. T3, temperature of LN2 + nitrogen shield. + + + + + External sensors connected to the device. Pressure of each chamber or ion pump, + such as prepare chamber and analysis chamber + + + + + The power present in the signal as a function of frequency. Used to characterise + the vibration and noise of scanning probes to detect and reduce the impact on + resolution during STM imaging + + + diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d649..e9d893e285 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -1,10 +1,10 @@ - + - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -43,29 +43,26 @@ - Total number of similarity groups aka features, objects, clusters. + Total number of similarity groups aka features/clusters. - Metadata to the results of a similarity grouping analysis. + Base class to store results obtained from applying a similarity grouping (clustering) algorithm. - Similarity grouping analyses can be supervised segmentation or machine learning - clustering algorithms. These are routine methods which partition the member of - a set of objects/geometric primitives into (sub-)groups, features of - different type. A plethora of algorithms have been proposed which can be applied - also on geometric primitives like points, triangles, or (abstract) features aka - objects (including categorical sub-groups). + Similarity grouping algorithms are segmentation or machine learning algorithms for + partitioning the members of a set of objects (e.g. geometric primitives) into + (sub-)groups aka features of different kind/type. A plethora of algorithms exists. - This base class considers metadata and results of one similarity grouping - analysis applied to a set in which objects are either categorized as noise - or belonging to a cluster. - As the results of the analysis each similarity group, here called feature - aka object can get a number of numerical and/or categorical labels. + This base class considers metadata and results of having a similarity grouping + algorithm applied to a set in which objects are either categorized as noise + or belonging to a cluster, i.e. members of a cluster. + The algorithm assigns each similarity group (feature/cluster) at least one + identifier (numerical or categorical labels) to distinguish different cluster. - Number of members in the set which is partitioned into features. + Number of members in the set which gets partitioned into features. @@ -78,26 +75,25 @@ How many categorical labels does each feature have. - - + + - Which identifier is the first to be used to label a cluster. + Which numerical identifier is the first to be used to label a feature. The value should be chosen in such a way that special values can be resolved: - * identifier_offset-1 indicates an object belongs to no cluster. - * identifier_offset-2 indicates an object belongs to the noise category. + * identifier_offset - 1 indicates that an object belongs to no cluster. + * identifier_offset - 2 indicates that an object belongs to the noise category. Setting for instance identifier_offset to 1 recovers the commonly used - case that objects of the noise category get values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. + case that objects of the noise category get values to -1 and unassigned + points to 0. Numerical identifier have to be strictly increasing. - - - - + Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance @@ -112,8 +108,6 @@ Matrix of categorical attribute data for each member in the set. - @@ -121,44 +115,39 @@ e.g. (NXclustering_hdbscan):--> - In addition to the detailed storage which members was grouped to which + In addition to the detailed storage which objects were grouped to which feature/group summary statistics are stored under this group. - - + + - Total number of members in the set which are categorized as unassigned. + Total number of features categorized as unassigned. - - - - Total number of members in the set which are categorized as noise. + Total number of features categorized as noise. - - - - - + - Total number of clusters (excluding noise and unassigned). + Total number of features. - + + - Array of numerical identifier of each feature (cluster). + Array of numerical identifier of each feature. - + - - + - Array of number of members for each feature. + Array of number of objects for each feature. diff --git a/contributed_definitions/NXspatial_filter.nxdl.xml b/contributed_definitions/NXspatial_filter.nxdl.xml index 25e5ae820a..7103ab86b8 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -1,10 +1,10 @@ - + - - + + The symbols used in the schema to specify e.g. dimensions of arrays. - - - Number of ellipsoids. - - Number of hexahedra. @@ -44,42 +39,51 @@ Number of cylinders. + + + Number of ellipsoids. + + + + + Number of polyhedra. + + - Spatial filter to filter entries within a region-of-interest based on their - position. + Base class for a spatial filter for objects within a region-of-interest (ROI). + + Objects can be points or objects composed from other geometric primitives. - + - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: + Qualitative statement which describes the logical operations + that define which objects will be included and which excluded: - * entire_dataset, no filter is applied, the entire dataset is used. - * union_of_primitives, a filter with (rotated) geometric primitives. - All ions in or on the surface of the primitives are considered - while all other ions are ignored. - * bitmasked_points, a boolean array whose bits encode with 1 - which ions should be included. Those ions whose bit is set to 0 - will be excluded. Users of python can use the bitfield operations - of the numpy package to define such bitfields. - - Conditions: - In the case that windowing_method is entire_dataset all entries are processed. - In the case that windowing_method is union_of_primitives, - it is possible to specify none or all types of primitives - (ellipsoids, cylinder, hexahedra). If no primitives are specified - the filter falls back to entire_dataset. - In the case that windowing_method is bitmask, the bitmask has to be defined; - otherwise the filter falls back to entire dataset. + * entire_dataset, no filter is applied, all objects are included. + * union_of_primitives, a filter with (possibly non-axis-aligned) geometric + primitives. Objects in or on the surface of the primitives are included. + All other objects are excluded. + * bitmask, a boolean array whose bits encode with 1 which objects + are included. Bits set to zero encode which objects are excluded. + Users of python can use the bitfield operations + of the numpy package to work with bitfields. + - - + + + diff --git a/contributed_definitions/NXsts.nxdl.xml b/contributed_definitions/NXsts.nxdl.xml new file mode 100644 index 0000000000..f13d5a90cb --- /dev/null +++ b/contributed_definitions/NXsts.nxdl.xml @@ -0,0 +1,995 @@ + + + + + + + + + + Application definition for temperature-dependent IV curve measurements + #2023.19.7 This Nexus file is currently only for STS data, it will be updated to handle the + STM image mode in the future with a focus on bias spectroscopy in Scanning Tunneling Microscopy. + + In this application definition, times should be specified always together with a UTC offset. + + This is the application definition describing temperature (T) dependent current voltage (IV) curve + measurements. For this, a temperature is set. After reaching the temperature, a voltage sweep + is performed. For each voltage, a current is measured. + Then, the next desired temperature is set and an IV measurement is performed. + The data can be visualized in a tensor with: + I (NXsensor_C, NXsoftware_Read_offset, NXcircuit) + parameters: + V has (NXsource+offset, NXsoftware_Scan_offset, NXsensor_V, NXcircuit) + T has (NXsource, NXsoftware_Scan_offset, NXsensor_T) + x has (NXsoftware_Scan_offset) + y has (NXsoftware_Scan_offset) + z has (NXsoftware_Scan_offset) + + + + + + + + + + Name of the experiment where the application is applicable. + + + + + + + + + The equipments and techniques as well as the parameter settings and reference signals + are used during the experiments used in Scanning Tunneling Microscopy (STM). + + + + + + + + + + + The name of the output file, with the number of scans at the end. (e.g. + 221122_Au_5K00014) + + + + + The name of the series output file, which represents only the public part of the + output file. (e.g. 221122_Au_5K) + + + + + Path to storage of output files. + (e.g. Path C:\Users\SPM-PEEM\Desktop\DATA_Nanonis\20220711_CreaTec_Service_Benchmarks_LHe\Nanonis-Session-PMD100-HVHU_CreaTec_Service_PalmaLabBerlin220711) + + + + + Descriptive comments for this experiment, added by the experimenter, coming from the + output file. (e.g. Comment01 SYNC & Filter LP 8order WITHDRAW 600 steps, locked Au(111), + 50pA, 100 mV set point, 1mV DCA, 973Hz,138 1st H, -84 2nd H) + + + + + + Hardware type used in SPM experiment, includes hardware manufacturers and type. + (e.g. Nanonis BP5e) + + + + + + Type of software used in SPM experiments, such as software version serial number, UI and + RT probe release method. (e.g. SW Version Generic 5e -- RT Release 10771) + + + + + + The Amplifier description that improves or helps to determine tunnel current (current + between tip and bias). + + + + + + + Status of Lock-in device whether while performing the experiment + + + + + + This is the signal on which the modulation (sine) will be added. + + + + + + + The signal is modulated by adding the frequency of the sine modulation. The + modulation frequency spans can be from 10 mHz to 40 kHz, corresponding to the output filter + cut-off range. When dealing with harmonics, it's essential to ensure that the + harmonic frequencies remain below ~100 kHz, which aligns with the input filter cut-off. + Be mindful that hardware filters might impact the amplitude as the signal approaches + their cut-off frequencies." (e.g. 973E+0) + + + + + + The amplitude (in physical units of modulated signal) of the sine modulation. + + + + + + The input signal (STS signal) will be demodulated, in order to determine the amplitude + and phase at the frequency set in the Frequency field or harmonics, such as current, + bias, et.al. + + + + + + N denotes 1 or 2. The order of the harmonic oscillation to be detected in the demodulated + signal should be considered relative to the modulation frequency. When dealing with + higher harmonics, it's essential to ensure that their frequencies do not surpass + the analogue signal bandwidth (e.g. harmonic_order_1). + + + + + + Reference phase for the sine on the demodulated signal with respect to the + modulation signal. The determined phase is displayed with respect to the + reference phase. + + + + + + + + Bias voltage applied to the sample. + + + + Applied a voltage between tip and sample. + + + + + + + + + Temperature of STM head. Note: At least one field from stm_head_temperature, + cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of liquid helium cryostat. Note: At least one field from + stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp must be provided. + + + + + Temperature of liquid nitrogen shield. Temperature 3 (K) (e.g 78.00000E+0). Note: At + least one field from stm_head_temperature, cryo_bottom_temp and cryo_sheild_temp + must be provided. + + + + + + + Configuration for piezoelectric scanner used to move tip along X and Y direction. The + material of the Piezoelectric scanner composed of polycrystalline solids and sensitive to + applied voltage. + + + + The name of calibration type. (e.g. LHe) + + + + + N denotes X or Y or Z. There are three parameters in the X, Y, and Z directions, + along with three available controls: Calibration (m/V), Range (m), and HV gain. Only + two of these parameters are required to define the calibration. Consequently, when any + value is changed, one of the other values will be automatically updated. (e.g. calib_X = 3.8E-9) + + + + + N denotes X or Y or Z. In some systems, there is an HV gain readout feature. For + these systems, the HV gain should be automatically adjusted whenever the gain is + changed at the high voltage amplifier. (e.g. 14.5) + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions, and tilt needs to be + adjusted according to the actual surface. (in degrees, first order correction). + + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. (can be set + approximately to the length of the piezotube). + + + + + N denotes X or Y. There are 2 parameters in X and Y directions. If you know them, + you can enter the 2nd order piezo characteristics to compensate for it. The + following equation shows the interpretation of the 2nd order correction parameter: + For the X-piezo: "Ux = 1/cx · X + cxx · X2" with units: + [V] = [V/m] · [m] + [V/m2] · [m2] where cx is the calibration of the piezo X and cxx + is the 2nd order correction. (V/m^2). (e.g. 0E+0) + + + + + N denotes X, Y or Z. There are 3 parameters in X, Y and Z directions. Define the + drift speed for all three axes. When the compensation is on, the piezos will start to + move at that speed. (e.g. 0E+0) + + + + + Use the button to enable or disable the drift compensation. (e.g. FALSE) + + + + + + An environmental setup to measure the tunneling current due to different tip- + sample biases. + + + + + This is set-point of tip current (in the constant current mode should be equal to set-point, + in the constant height mode means the real tunnelling current between tip and sample). + + + + + Value of calibration that comes as A/V. The value for this concept can be read + as current per unit voltage. + + + + + + + + + + Clarify the frame laboratory frame. + + + + The scanning area in x position in the frame. (e.g. -890.53E-12) + + + + + The scanning area in y position in the frame. (e.g. 29.6968E-9) + + + + + The scanning area in z position in the frame. (e.g. 130.5E-9) + + + + + + Indicate the relative tip position z between tip and sample. The tip position can also + be varied when the z_controller is not running. (e.g. 130.5E-9) + + + + + + + + + + Time during which the spectroscopy data are acquired and averaged. (e.g. 150E-6) + + + + + Number of sweeps to measure and average. (e.g. 100) + + + + + The start bias values of the sweep. (e.g. -300E-3) + + + + + The end bias values of the sweep. (e.g. 300E-3) + + + + + The sweep number of points is defined as the maximum spectrum resolution, which + is equal to the bias sweep window divided by the number of pixels. (e.g. 4096) + + + + + The Z position is recorded and averaged for a certain duration both before and + after the sweep. After the initial Z averaging time, if "Z-Controller to Hold" + is selected, the Z-Controller is set to hold mode, and the tip is positioned at + the previously averaged Z position (adjusted by the Z offset). (e.g. 100E-3) + + + + + + + The bandwidth of the Hardware and/or Software is instrument specific. + For example, Nanonis Generic 5 has 'RT Frequency' (e.g. 20E+3). + + + + + The Signals Period represents the rate at which signals are transferred to + the host computer, which operates the control software. This rate may + be 10 times lower than the sampling rate, as the real-time engine internally + oversamples the signal. If desired, you may have the option to reduce the oversampling + to 1, enabling higher frequency resolution in the Spectrum Analyzer. (e.g. 10) + + + + + The update rate is utilized in various processes, including the History Graph, + Auto-Approach, and multiple Programming Interface functions. It may be + configured to a 20 ms interval. Any additional timings must strictly be integer + multiples of this base value. While it is possible to set these additional + timings to different values, the actual timing value will automatically be + adjusted to become a multiple of the Acquisition Period. (e.g. 20E-3) + + + + + The update rate of animated graphical indicators, such as graphs and sliders, + can be adjusted. A normal value may be 40 ms, which corresponds to 25 updates + per second. Increasing this period can help reduce the processor load on the + graphical user interface, particularly on slower computers. It is important to + note that this update rate solely impacts the user interface and does not affect + measurements in any manner. (e.g. 20E-3) + + + + + The update rate of digital indicators, such as the numbers displayed, can be set + to 3 updates per second, equivalent to 300 ms. This interval is sufficient for + the user interface and does not impact measurements in any manner. (e.g. 300E-3) + + + + + The Measurements period determines the integration time required for precise + measurements, primarily utilized in sweep modules. It is particularly useful for + tasks such as recording force-distance curves or cantilever resonances. For + swift measurements with small steps, a value of 40 ms is often adequate. For + regular use, a range of 300-500 ms may be recommended, but when capturing the + resonance of a high-Q cantilever, longer values in the range of several seconds + might be necessary. Usually, this parameter does not require manual adjustment + within this module, as the sweep modules automatically set this value according + to the sweep timings. (e.g. 500E-3) + + + + + + + + + In STM experiment, the scan range is the coordinate (x,y) along the X and Y axis from the origin (scan_offset) of + the scan area (e.g. 5.000000E-9 5.000000E-9). + + + + + In STM experiment, the scan offset is the position of the tip at the starting point of scan area. + (e.g. -2.354637E-7 1.267476E-) + + + + + In STM experiment, the scan direction is the direction from which side of the + sample the tip starts scanning. + + + + + + + + + + + The angle of scan with the bottom or top side (depends on the scan_direction + field) of the sample. (e.g. 0.000E+0). + + + + + + Also clarify the frame for the ROI of the scan in lab frame, the middle of the lab + frame is (0, 0), and positive in x means right and in y means up. + + + + + + + The scan channels are selected by users. (e.g. (A);Bias (V);Z (m);LI Demod 2 X + (A);LI Demod 2 Y (A);LI Demod 1 X (A);LI Demod 1 Y (A)) + + + + + + + Configure the scan frame like x position; y position; width; height. (e.g. + 3.11737E-9;29.1583E-9;15E-9;15E-9;0E+0). If the 'scanfield' is not considered, use + the 'scan_range' and 'scan_offset' from 'scan_control' group + + + + + Scan resolution by setting the Lines equal to Pixels. (e.g. 512) + + + + + Define the image resolution. (e.g. 512) + + + + + Define the scan forward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + Define the scan backward speed in the forward direction. (m/s) (e.g. 11.7187E-9) + + + + + + + + + + + + Link to target: /NXentry/NXinstrument/stm_head_temp + + + + + + Link to target: /NXentry/NXinstrument/cryo_bottom_temp + + + + + + Link to target: /NXentry/NXinstrument/temp_cryo_shield + + + + + + Link to target: /NXentry/NXinstrument/NXlock_in/modulation_signal + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/NXintegration_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/number_of_sweeps + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_start + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/sweep_end + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/num_pixel + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_avg_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/rt_frequency + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/signals_oversampling + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/acquisition_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/animations_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/indicators_period + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXcircuit/measurements_period + + + + + + + + + Link to target: /NXentry/NXinstrument/NXsample_bias/bias + + + + + + Link to target: /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current + + + + + + Link to target: /NXentry/NXnstrument/NXsample_bias/bias_calibration + + + + + Link to target: /NXentry/NXinstrument/NXsample_bias/bias_offset + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_calibration + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_offset + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXcurrent_sensor/current_gain + + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_offset + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_ccontroller_hold + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/record_final_z + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/first_settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/end_settling_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/z_control_time + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/max_slew_rate + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXsweep_control/NXbias_spectroscopy/backward_sweep + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_name + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/controller_status + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/set_point + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/p_gain + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/i_gain + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/time_const + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/tip_lift + + + + + + Link to target: + /NXentry/NXinstrument/NXenvironment/NXposition/NXz_controller/switchoff_delay + + + + + + This describes the sample and its properties, as well as constraints that are + applied to the sample before scanning. + + + + At this moment no base class available that can track entire sample preparation. + + + + + + + This NXdata should contain separate fields for the current values at different temperature setpoints, for example current_at_100C. + There should also be two more fields called temperature and voltage containing the setpoint values. + There should also be a field with an array of rank equal to the number of different temperature setpoints and each child's dimension + equal to the number of voltage setpoints. + axes: bias_calc + signals: + li_demod_[1;2]_[X/Y]_[-;bwd;filt;bwd_filt] + current_[-;bwd;filt;bwd_filt] + temperature + + + + + + Plot for a single point (x,y) with I vs. V curve. + + + + + + Line scan with multiple I vs. V curves for different single (x,y) co-ordinates. + + + + + + Plot for current(I) curve in the 2D space of (position(x), bias(V)) which can be + derived from the `line_scan` plot. + + + + + + Mesh scan with 2D slices of the above alternative plot for other y co-ordinates. + + + + diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index ea378eab39..2ecb9877a0 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -1,4 +1,4 @@ - + - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + + - Settings of a filter to sample entries based on their value. + Base class of a filter to sample members in a set based on their identifier. - + - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry to take. + Triplet of the minimum, the increment, and the maximum identifier to + include of a sequence :math:`[i_0, i_0 + 1, i_0 + 2, \ldots, i_0 + \mathcal{N}] with i_0 \in \mathcal{Z}` + of identifier. The increment controls which n-th identifier (value) to take. - Take as an example a dataset with 100 entries (their indices start at zero) - and the filter set to 0, 1, 99. This will process each entry. - 0, 2, 99 will take each second entry. 90, 3, 99 will take only each third - entry beginning from entry 90 up to 99. + Take as an example a dataset with 100 identifier (aka entries). Assume that + the identifier start at zero, i.e. identifier_offset is 0). Assume further + that min_incr_max is set to [0, 1, 99]. In this case the filter will + yield all identifier. Setting min_incr_max to [0, 2, 99] will take each + second identifier. Setting min_incr_max to [90, 3, 99] will take each + third identifier beginning from identifier 90 up to 99. diff --git a/contributed_definitions/NXtransmission.nxdl.xml b/contributed_definitions/NXtransmission.nxdl.xml index 1fb2d51d46..15ed29e3b3 100644 --- a/contributed_definitions/NXtransmission.nxdl.xml +++ b/contributed_definitions/NXtransmission.nxdl.xml @@ -1,10 +1,10 @@ - + - - + Variables used throughout the experiment @@ -71,7 +72,7 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) unique identifier. @@ -80,7 +81,7 @@ Draft NeXus application definition for transmission experiments--> investigator. * The identifier enables to link experiments to e.g. proposals. - + An optional free-text description of the experiment. However, details of the @@ -99,12 +100,12 @@ of instrument.--> used to generate the result file(s) with measured data and metadata. - + Version number of the program that was used to generate the result file(s) with measured data and metadata. - + Website of the software @@ -333,8 +334,10 @@ of instrument.--> - + Properties of the sample measured diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml new file mode 100644 index 0000000000..c534d8194e --- /dev/null +++ b/contributed_definitions/NXxrd.nxdl.xml @@ -0,0 +1,99 @@ + + + + + + + NXxrd on top of NXmonopd + + + + + Official NeXus NXDL schema to which this file conforms + + + + + + + + + + + + + raw detector signal (usually counts) as colected + it can be a multi-dimensional dataset depending on + the detector type (faster axes) and + the scanning method (slower axes) + + + + + The 2-theta range of the difractogram + + + + + + + + + + + + + + + + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to ponglar ale in /NXentry/NXinstrument/NXdetector + + + + + + + + link (suggested target:/NXentry/NXinstrument/NXdetector/data) + Link to data in /Nxentry/Nxinstrument/Nxdetector + + + + + + + + + Description of a processing or analysis step, such as the + baseline extraction or azimuth integration. + Add additional fields as needed to describe value(s) of + any variable, parameter, or term related to + the NXprocess step. Be sure to include units attributes + for all numerical fields. + + + + diff --git a/contributed_definitions/NXxrd_pan.nxdl.xml b/contributed_definitions/NXxrd_pan.nxdl.xml new file mode 100644 index 0000000000..4918e4ef4f --- /dev/null +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -0,0 +1,335 @@ + + + + + + NXxrd_pan is a specialisation of NXxrd with extra properties + for the PANalytical XRD data format. + + + + + Name of the data file. + + + + + Type of measurement. + + + + + Official NeXus NXDL schema to which this file conforms. + + + + + + + + Method used to collect the data + default='X-Ray Diffraction (XRD)' + + + + + + + + + + + Type of the X-ray tube. + + + + + + + + + + + + + + Current of the X-ray tube. + + + + + Voltage of the X-ray tube. + + + + + + Wavelength of the K\u03b1 1 line. + + + + + + + + + + Wavelength of the K\u03b1 2 line. + + + + + + + + + + K\u03b1 2/K\u03b1 1 intensity ratio. + + + + + Wavelength of the K\u00df line. + + + + + + + + + + Wavelength of the X-ray source. Used to convert from 2-theta to Q. + + + + + + + Axis scanned. + + + + + Mode of scan. + + + + + Integration time per channel. + + + + + + + + Collect user inputs e.g. name or path of the input file. + + + + + Starting value of the diffraction angle. + + + + + Ending value of the diffraction angle. + + + + + Minimum step size in-between two diffraction angles. + + + + + + + Starting value of the incident angle. + + + + + Ending value of the incident angle. + + + + + Minimum step size in the between two incident angles. + + + + + + Beam attenuation factors over the path. + + + + + Goniometer position X. + + + + + Goniometer position Y. + + + + + Goniometer position Z + + + + + Total time of count. + + + + + + All experiment results data such as scattering angle (2theta), + intensity, incident angle, scattering vector, etc will be stored here. + + + + Number of scattered electrons per unit time. + + + + + + + + Two-theta (scattering angle) of the diffractogram. + + + + + + + + Incident angle of the diffractogram. + + + + + + + + The phi range of the diffractogram. + + + + + + + + The chi range of the diffractogram + + + + + + + + The scattering vector component, which is parallel to the sample surface. + + + + + The scattering vector component, which is perpendicular to the sample surface. + + + + + The norm value of the scattering vector, q. The scattering vector is defined as a + difference between the incident and scattered wave vectors. + For details: https://en.wikipedia.org/wiki/Powder_diffraction + and https://theory.labster.com/scattering-vector/ + + + + + + The desired view for scattering vectors. + + + + This concept corresponds to the norm value of the scattering vector(q). + The concept is the same as 'q_norm' of 'experiment_result' + and should be linked to /entry[ENTRY]/experiment_result/q_norm. + + + + + Number of scattered electrons per unit time at each scattering vector (q) value. + The concept is the same as the 'intensity' of experiment_result + and should be linked to /entry[ENTRY]/experiment_result/intensity. + + + + + The scattering vector (q) component, which is parallel to the sample surface. + This component is used in the Reciprocal Space Mapping (RSM) technique of + X-ray diffraction method. + + The concept is the same as 'q_parallel' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_parallel. + + + + + The scattering vector component, which is perpendicular to the sample surface. + + The concept is the same as 'q_perpendicular' of experiment_result, + and should be linked to /entry[ENTRY]/experiment_result/q_perpendicular. + + + + + + Description on sample. + + + + Mode of sample. + + + + + Id of sample. + + + + + Usually in xrd sample are being analysed, but sample might be identified by + assumed name or given name. + + + + + diff --git a/dev_tools/docs/nxdl.py b/dev_tools/docs/nxdl.py index 157acce335..ed3db94cca 100644 --- a/dev_tools/docs/nxdl.py +++ b/dev_tools/docs/nxdl.py @@ -303,12 +303,34 @@ def _get_doc_blocks(ns, node): out_blocks.append("\n".join(out_lines)) return out_blocks + def _handle_multiline_docstring(self, blocks): + links = [] + docstring = "" + expanded_blocks = [] + for block in blocks: + expanded_blocks += block.split("\n") + + for block in expanded_blocks: + if not block: + continue + + link_match = re.search(r"\.\. _([^:]+):(.*)", block) + if link_match is not None: + links.append((link_match.group(1), link_match.group(2).strip())) + else: + docstring += " " + re.sub(r"\n", " ", block.strip()) + + for name, target in links: + docstring = docstring.replace(f"`{name}`_", f"`{name} <{target}>`_") + + return docstring + def _get_doc_line(self, ns, node): blocks = self._get_doc_blocks(ns, node) if len(blocks) == 0: return "" if len(blocks) > 1: - raise Exception(f"Unexpected multi-paragraph doc [{'|'.join(blocks)}]") + return self._handle_multiline_docstring(blocks) return re.sub(r"\n", " ", blocks[0]) def _get_minOccurs(self, node):