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):