diff --git a/contributed_definitions/NXapm_composition_space_results.nxdl.xml b/contributed_definitions/NXapm_composition_space_results.nxdl.xml deleted file mode 100644 index 0c6403690a..0000000000 --- a/contributed_definitions/NXapm_composition_space_results.nxdl.xml +++ /dev/null @@ -1,488 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of voxel of discretized domain for analyzed part of the dataset. - - - - - The dimensionality of the grid. - - - - - The cardinality or total number of cells/grid points. - - - - - Number of terms in the composition clustering dictionary - - - - - Number of terms in the position clustering dictionary - - - - - Results of a run with Alaukik Saxena's composition space tool. - - This is an initial draft application definition for the common NFDI-MatWerk, - FAIRmat infrastructure use case IUC09 how to improve the organization and - results storage of the composition space tool and make these data at the same - time directly understandable for NOMAD. - - This draft does no contain yet the annotations for how to also store - in the HDF5 file a default visualization whereby the composition grid - could directly be explored using H5Web. I am happy to add this ones the - data have been mapped on this schema, i.e. more discussion needed. - - Also iso-surfaces can be described, for paraprobe, this is a solved problem, - check the respective group in the NXapm_paraprobe_results_nanochem data - schema/application definition. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - TBD, maybe how to link between pyiron state tracking and app state tracking - - - - - Discouraged place for free-text for e.g. comments. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. when composition space tool was started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and composition space tool exited as a process. - - - - - The path and name of the config file for this analysis. - TBD, this can be e.g. Alaukik's YAML file for composition space. - - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - - The path and name of the file (technology partner or community format) - from which reconstructed ion positions were loaded. - - - - - - - - The path and name of the file (technology partner or community format - from which ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes were loaded. - - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the executable managed to process the analysis - or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Some suggestions follow, e.g. that field names should be prefixed - with the following controlled terms indicating which individual - coordinate system is described: - - * world - * composition_space - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - - - - - - - - - - Position of each cell in Euclidean space. - - - - - - - - - - - - - - - - For each ion, the identifier of the voxel in which the ion is located. - - - - - - - - - - - - - - - - - - In Alaukik's tool the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished compositionally- - defined cluster, e.g. the phases. Examples for keywords could be - phase1, phase2, and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of either phase1 - or phase2, the cluster_dict_keyword would be a list with two names - phase1 and phase2, respectively. The cluster_dict_value would be a - list of e.g. integers 1 and 2. These could be used to build an - array with as many entries as there are voxel and store in this array - the respective value to encode which phase is assumed for each voxel. - - - - - - - - - - In Alaukik's tool the DBScan step after the GMM step. - - - - - - - - - The keywords of the dictionary of distinguished spatially-contiguous - clusters. Examples for keywords could be precipitate1, precipitate2, - and so one and so forth. - - - - - - - - Resolves for each keyword in cluster_dict which integer is used to - label something that it belongs or is assumed to represent this - cluster. - - - - - - - - - For example if the voxel grid is used to report that there - are voxels which are assumed to represent volume of certain precipitates, - say we found ten precipitates and consider the rest as matrix. - We could make a list of say matrix, precipitate1, precipitate2, ..., - precipitate10. With cluster_dict_value then running from 0 to 10, - i.e. matrix is flagged special as 0 and the remaining particles - are indexed conveniently as 1, 2, ..., 10 like end users expect. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_compositionspace_config.nxdl.xml b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml new file mode 100644 index 0000000000..157a362d9a --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_config.nxdl.xml @@ -0,0 +1,208 @@ + + + + + + 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 tool by using the NeXus data model and semantics. + + + + + + + + + + + + Specification of the tomographic reconstruction used for this analysis. + + Reconstructions in the field of atom probe tomography are communicated via + a file which stores the reconstructed position and mass-to-charge-state-ratio + value for each ion. + + Container file formats like HDF5, such as NeXus/HDF5 files using :ref:`NXapm`, + can store multiple reconstructions. In this case, the position and mass_to_charge + concepts point to specific instances in the file referred to by file_name for the + analysis with CompositionSpace. + + + + + + + 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. + + Ranging definitions in the field of atom probe tomography are communicated via + a file which stores the mass-to-charge-state-ratio interval and the number of elements + of which each (molecular) ion is composed. These values are stored for each ion. + + Container file formats like HDF5, such as NeXus/HDF5 files using :ref:`NXapm`, + can store multiple ranging definitions. + + Indices of ions start from 1. The value 0 is reserved for the null model of unranged positions + whose iontype is referred to as the unknown_type. The value 0 is also reserved for voxels + that lie outside the dataset. + + + + + + + Name of that (parent) node whose child stores the ranging definitions that + are applied in this analysis with CompositionSpace. + + + + + + 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 evaluated to preprocess a result that + is subsequently 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 evaluation 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..92a2f356d0 --- /dev/null +++ b/contributed_definitions/NXapm_compositionspace_results.nxdl.xml @@ -0,0 +1,420 @@ + + + + + + + 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. + + + + + + + + + + + + + + + + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + Configuration file that was used in this analysis. + + + + + + + + + + Contextualize back to the specimen from which the + dataset was collected that was here analyzed with + CompositionSpace tool. + + + + True, if the specimen that the reconstructed dataset + describes is a simulated one. + False, if the specimen that the reconstructed dataset + describes is a real one. + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources pointed to by identifier_parent or walk through + eventually deeply nested groups in data instances. + + + + + + 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 that use 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/ionID + used during 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 objects. + The objects are constructed from blobs of neighboring voxels. + The objects are not necessarily watertight or topologically closed. + + + + + + + + + + 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_input_ranging.nxdl.xml b/contributed_definitions/NXapm_input_ranging.nxdl.xml deleted file mode 100644 index b82a78e70d..0000000000 --- a/contributed_definitions/NXapm_input_ranging.nxdl.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - - - - Metadata to ranging definitions made for a dataset in atom probe microscopy. - - Ranging is the process of labeling time-of-flight data with so-called iontypes - which ideally specify the most likely ion/molecular ion evaporated within a - given mass-to-charge-state-ratio value interval. - - The paraprobe-toolbox uses the convention that the so-called UNKNOWNTYPE - iontype (or unranged ions) represents the default iontype. - The ID of this special iontype is always reserved as 0. Each ion - is assigned to the UNKNOWNTYPE by default. Iontypes are assigned - by checking if the mass-to-charge-state-ratio values of an ion matches - to any of the defined mass-to-charge-state-ratio intervals. - - - - Path and name of the NeXus/HDF5 file which stores ranging definitions. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the group (prefix to the individual ranging definitions) inside - the file referred to by filename which points to the specific ranging - definition to use. - An HDF5 file can store multiple ranging definitions. Using an ID is - the mechanism to distinguish which specific ranging (version) will - be processed. Reconstruction and ranging IDs can differ. - They specify different IDs. - - - diff --git a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml b/contributed_definitions/NXapm_input_reconstruction.nxdl.xml deleted file mode 100644 index 8ed7b90021..0000000000 --- a/contributed_definitions/NXapm_input_reconstruction.nxdl.xml +++ /dev/null @@ -1,58 +0,0 @@ - - - - - - - Metadata of a dataset (tomographic reconstruction) in atom probe microscopy. - - - - Name of the (NeXus)/HDF5 file which stores reconstructed ion position - and mass-to-charge-state ratios. Such an HDF5 file can store multiple - reconstructions. Using the information within the dataset_name fields - is the mechanism whereby paraprobe decides which reconstruction to - process. With this design it is possible that the same HDF5 - file can store multiple versions of a reconstruction. - - - - Version identifier of the file (representing an at least SHA256 strong) - hash. Such hashes serve reproducibility as they can be used for tracking - provenance metadata in a workflow. - - - - - - Name of the dataset inside the HDF5 file which refers to the - specific reconstructed ion positions to use for this analysis. - - - - - Name of the dataset inside the HDF5 file which refers to the - specific mass-to-charge-state-ratio values to use for this analysis. - - - 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..e0fe10b8b1 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_config.nxdl.xml @@ -0,0 +1,295 @@ + + + + + + + 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. + + The tool paraprobe-clusterer evaluates how points cluster in space. + + + + + + + + + + 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:`NXnote` 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 high_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..031010b79c --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_clusterer_results.nxdl.xml @@ -0,0 +1,229 @@ + + + + + + + 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 a results file of the paraprobe-clusterer tool. + + The tool paraprobe-clusterer evaluates how points cluster in space. + + + + + + + + + + + + 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: + * index_offset - 1 indicates an object belongs to no cluster. + * index_offset - 2 indicates an object belongs to the noise category. + + Setting for instance index_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) id (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_id. + + + + + + + + Number of members for each feature. + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml deleted file mode 100644 index 20afcceeb2..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_clusterer.nxdl.xml +++ /dev/null @@ -1,477 +0,0 @@ - - - - - - - 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. - - - - - Configuration of a paraprobe-clusterer tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - How many tasks to perform? - - - - - This process maps results from cluster analyses performed with IVAS/APSuite - into an interoperable representation. Specifically in this process - paraprobe-clusterer takes results from clustering methods from other tools - of the APM community, like IVAS/APSuite. These results are usually reported - in two ways. Either as an explicit list of reconstructed ion positions. - In the case of IVAS these positions are reported through a text file - with a cluster label for each position. - - Alternatively, the list of positions is reported, as it is the case for - AMETEK (IVAS/AP Suite) but the cluster labels are specified implicitly - only in the following way: The mass-to-charge-state ratio column of a - what is effectively a file formatted like POS is used to assign a hypothetical - mass-to-charge value which resolves a floating point representation - of the cluster ID. - - Another case can occur where all disjoint floating point values, - i.e. here cluster labels, are reported and then a dictionary is created - how each value matches to a cluster ID. - - In general the cluster ID zero is reserved for marking the dataset - as to not be assigned to any cluster. Therefore, indices of disjoint - clusters start at 1. - - - - - - - - - AMETEK/Cameca results of cluster analyses, like with the maximum- - separation (MS) method clustering algorithm `J. Hyde et al. <https://doi.org/10.1557/PROC-650-R6.6>`_ - are stored as an improper POS file: This is a matrix of floating - point quadruplets, one for each ion and as many quadruplets as - ions were investigated. The first three values encode the position - of the ion. The fourth value is an improper mass-to-charge-state-ratio - value which encodes the integer identifier of the cluster as a floating - point number. - - - - - - - Specifies if the tool should try to recover for each position the closest - matching position from dataset/dataset_name_reconstruction (within - floating point accuracy). This can be useful for instance when users - wish to recover the original evaporation ID, which IVAS/AP Suite drops - for instance when writing their *.indexed.* cluster results POS files. - - - - - - - This process performs a cluster analysis on a reconstructed dataset - or a portion of the reconstruction. - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How should iontypes be interpreted/considered during the cluster analysis. - Different options exist how iontypes are interpreted (if considered at all) - 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. - 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 elemental or isotopic details. - The value resolve_element will set an ion active, and most importantly, - account as many times for it, 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 as many times for it, 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. - - This is relevant as in atom probe we have the situation that a ion - of a molecular ion with more than one nuclide, say Ti O for example - is counted such that although there is a single TiO molecular ion - at a position that the cluster has two members. This multiplicity - affects the size of the feature and chemical composition. - - - - - - - - - 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. - - - - - - - - - Settings for DBScan clustering algorithm. For original details about the - algorithms 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 runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - As an example we may define eps with ten entries and min_pts with - three entries. If high_throughput_method is tuple the analysis is - invalid as we have an insufficient number of min_pts for the ten - eps values. - By contrast, for combinatorics paraprobe-clusterer will run three - individual min_pts runs for each eps value, resulting in a total - of 30 analyses. - As an example the DBScan analysis reported in `M. Kühbach et al. <https://dx.doi.org/10.1038/s41524-020-00486-1>`_ - would have defined an array of values np.linspace(0.2, 5.0, nums=241, endpoint=True) - eps values, min_pts one, and high_throughput_method set to combinatorics. - - - - - - - - - Array of epsilon (eps) parameter values. - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - - - Settings for the OPTICS clustering algorithm. - - * `M. Ankerest et al. <https://dx.doi.org/10.1145/304181.304187>`_ - - - - Strategy how runs are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - Array of minimum points (min_pts) parameter values. - - - - - - - - Array of maximum epsilon (eps) 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 are performed with different parameter: - - * For tuple as many runs are performed as parameter values. - * For combinatorics individual parameter arrays are looped over. - - See the explanation for the corresponding parameter for dbscan - processes above-mentioned for further details. - - - - - - - - - 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_config_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml deleted file mode 100644 index 14db557bd6..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_distancer.nxdl.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration/settings of a paraprobe-distancer software tool run. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Compute for all filtered points, e.g. ions of the point set - the shortest Euclidean distance to the closest triangle of the - set of triangles. The triangles can formed a closed surface mesh. - Distances are not simple distances based on normal projections but - giving an exact solution. - - - - - Paraprobe-distancer enables the computation of the Euclidean shortest - distance for each member of a set of points against a set of triangles. - In contrast to comparable methods used in atom probe the here computed - distance is not simply the projected distance to one of the triangles - but the more costly but robust computation of the distance between - a point and a triangle. - - The triangles can represent for instance the facets of a triangulated - surface mesh of a model for the edge of the dataset. Such a model can - be computed with paraprobe-surfacer. Alternatively, the triangles can - be those from the set of all facets for a set of convex hulls, alpha-shapes, - or alpha wrappings about three-dimensional objects like precipitates - (computed with e.g. paraprobe-nanochem). - - Currently, the tool does not check if the respectively specified - triangle sets are consistent, what their topology is, or whether or - not they are consistently oriented. - Each dataset that is referred to in the list_of _dataset_names_vertices - should be an (Nvertices, 3) array of NX_FLOAT. Each dataset referred - to in the list_of_dataset_names_facet_indices should be an - (Nfacets, 3) array of NX_UINT. - Facet indices refer to vertex indices. These need to start at zero - and must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and vertices are indexed thus implicitly. - Facet normal vectors have to be also an array - of shape (Nfacets, 3) of NX_FLOAT. - - - - How many triangle sets to consider. - - - - - List of triangle sets. This design allows users to combine - multiple triangle sets. - - - - Name of the HDF5 file(s) which contain(s) vertex coordinates - and facet indices to describe the desired set of triangles. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility. - - - - - - Absolute HDF5 path to the dataset which - specifies the array of vertex positions. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet indices. - - - - - Absolute HDF5 path to the dataset which - specifies the array of facet normal vectors. - - - - - - - Specifies for which ions/points the tool will compute distances. - The purpose of this setting is to avoid unnecessary computations - when the user requests to only compute distances of ions within a - threshold distance to the triangle soup. - - By default the distances are computed for all ions; however - the setting skin enables to compute distances only for those - ions which are not farther away located to a triangle - than threshold_distance. - - - - - - - - - - Maximum distance for which distances are computed when method is skin. - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml deleted file mode 100644 index 0826854cb8..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_intersector.nxdl.xml +++ /dev/null @@ -1,348 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-intersector tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should execute as part of the analysis. - - - - - Tracking volume_volume_spatial_correlation is the process of building logical - relations between volumetric features based on meshes, their proximity and - eventual intersections. 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 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. - In the analysis of M. Kühbach et al. specifically features can be - so-called objects (closed non-degenerated polyhedra representing watertight - parts of an e.g. iso-surface) and/or proxies. Proxies are computed - doppelganger/replacement meshes for parts of an iso-surface which initially - were not resulting in watertight meshes because objects at the edge - of the dataset or incompletely measured or truncated objects. - - - - 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>`_, the tool by - default assumes 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 currently used library (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. - - - - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) intersect volumetrically. - - - - - Specifies if the tool evaluates if for each pair the two objects - (and proxies if used) lie closer to one another than the - threshold_proximity. - - - - - Specifies if the tool evaluates, ones all tracking tasks were - successfully completed, how intersecting or proximity related - objects build sub-graphs. This is the feature which enabled - M. Kühbach et al. 2022 the high-throughput analyses of how many - objects are coprecipitates in the sense that they are single, - duplet, triplet, or high-order. For these analyses to work - has_object_volume needs to be activated. - - - - - The maximum Euclidean distance between two objects below which - both objects are still 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 represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k`. - - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE 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. - - - - - - Descriptive category explaining what these features are. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be inferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be inferred 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 next_set. The label - effectively represents (can be interpreted as) the time/iteration - step when the current set was taken. As it is detailed in `M. Kühbach - et al. 2022 <https://arxiv.org/abs/2205.13510>`_, this identifier - takes the role of the time variable :math:`k + 1`. - - - - - - The total number of distinguished feature sets FEATURE. - It is assumed that the members within all these FEATURE 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. - - - - - - - - - - - Name of the (NeXus)/HDF5 file which contains triangulated - surface meshes of the members of the set as instances of - NXcg_polyhedron_set. - - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - String whereby the path to the geometry data can be inferred automatically. - Currently groupname_geometry_prefix/object<ID>/polyhedron. - - - - - Array of identifier whereby the path to the geometry data - can be inferred automatically. - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml deleted file mode 100644 index bc0042d472..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_nanochem.nxdl.xml +++ /dev/null @@ -1,1114 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - How many iontypes does the delocalization filter specify. - - - - - 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. - - - - - Configuration of a paraprobe-nanochem tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to - UTC information included when this configuration file was created. - - - - - How many individual analyses should the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject a previously computed triangle soup or - 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. - - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the edge of the dataset. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - - The tool enables to inject precomputed distance information for each - point/ion which can be used for further post-processing and analysis. - - - - - Name of an HDF5 file which contains the ion distances. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - - Discretization of the ion point cloud on a three-dimensional grid. - - - - Delocalization in the field of atom probe microscopy is the process - of discretizing a point cloud. By default the tool computes a full - kernel density estimation of decomposed ions to create one discretized - field for each element. - - Although, this uses an efficient multithreaded algorithm, - the computation is costly. Therefore, it can be advantageous for users - to load an already computed delocalization. This can be achieved with - the load_existent option. - When using this option the user is responsible to assure that the - settings which were used for computing this already existent delocalization - are specified in the same manner as they were. - - - - - - - - - - - Matrix of isotope vectors representing iontypes. - The filter specifies a matrix of isotope_vectors which is the most - general approach to define if and how many times an ion is counted. - Currently, paraprobe_nanochem performs a so-called atomic decomposition - of all iontypes. Specifically, the tool interprets of how many - elements/atoms a molecular ion is composed; and thus determines the - atoms multiplicity with respect to the iontype. - - Let's take the hydroxonium H3O+ molecular ion as an example: - It contains hydrogen and oxygen as atoms. The multiplicity of hydrogen - is three whereas that of oxygen is one. Therefore in an atomic - decomposition computation of the iso-surface each H3O+ ion adds - three hydrogen counts. This is a practical solution which accepts - the situation that during an atom probe experiment not each bond - of each ion/a group of neighboring atoms is broken but molecular - ions get detected. The exact ab-initio details depend on the local - field conditions and thus also the detailed spatial arrangement - of the atoms and their own electronic state and that of the neighbors - before and upon launch. - Being able to measure the information for such sites only as - molecular ions causes an inherent information loss with respect to the - detailed spatial arrangement. This information loss is more relevant - for local electrode atom probe than for field ion microscopy setting - how precisely the atomic positions can be reconstructed. - Accounting for multiplicities assures that at least the - compositional information is analyzed. - - - - - - - - - List of individual grid resolutions to analyse. - Paraprobe discretizes on a cuboidal 3D grid with cubic cells, with - an edge length of values in gridresolutions. - - - - - - Half the width of a :math:`{(2 \cdot n + 1)}^3` cubic kernel of voxel - beyond which the Gaussian Ansatz function will be truncated. - Intensity beyond the kernel is refactored into the kernel via - a normalization procedure. - - - - - Variance of the Gaussian Ansatz kernel :math:`\sigma_x = \sigma_y = 2 \cdot - \sigma_z`. - - - - - - How should the results of the kernel-density estimation be computed - 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 white list of elements in each voxel. - - - - - - - - - - - Specifies if the tool should report the delocalization 3D field values. - - - - - - - Optional computation of iso-surfaces after each computed delocalization - to identify for instance objects in the microstructure - (line features, interfaces, precipitates). - - - - As it is detailed in M. Kühbach et al. 2022 npj Comp. Mat., - the handling of triangles at the edge of the dataset requires - special attention. Especially for composition-normalized - delocalization it is possible that the composition increases - towards the edge of the dataset because the quotient of two numbers - which 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, (via setting keep_edge_triangles) the user can - instruct the tool to not remove these triangles at the cost of bias. - - Specifically, in this case the user should understand that all - objects/microstructural features in contact with the edge of the - dataset get usually artificial enlarged and their surface mesh - often closed during the marching. This closure however is artificial! - It can result in biased shape analyses for those objects. - The reason why this should in general be avoided is a similar - argument as when one analyzes grain shapes in orientation microscopy - via e.g. SEM/EBSD. Namely, these grains, here the objects at the - edge of the dataset, were not fully captured during e.g. limited - field of view. - Therefore, it is questionable if one would like to make - substantiated quantitative statements about them. - - Thanks to collaboration with the V. V. Rielli and S. Primig, though, - paraprobe-nanochem implements a complete pipeline to - process even these objects at the edge of the dataset. Specifically, - the objects are replaced by so-called proxies, i.e. replacement - objects whose holes on the surface mesh have been closed if possible - via iterative mesh and hole-filling procedures with fairing operations. - In the results of each paraprobe-nanochem run, these proxy objects - are listed separately to allow users to quantify and analyze in - detail the differences when accounting for these objects or not. - Especially this is relevant in atom probe microscopy as objects - can contain a few dozen atoms only. - 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. - - Also users should be careful with overestimating the statistical - significance of their dataset especially when using atom probe - to compare multiple descriptors: Even though a dataset may give - statistically significant results for compositions, this does not - necessarily mean it will yield also statistically significant - and unbiased results for three-dimensional 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-edge-distance that is used in the analyses of objects - (and proxies) to identify whether these are inside the dataset or - close to the edge of the dataset. If an object has at least one ion - with an ion-to-edge-distance below this threshold, the object is - considered as one which lies close to the edge of the dataset. - This implements essentially a distance-based approach to solve - the in general complicated and involved treatment of computing - volumetric intersections between not-necessarily convex - closed 2-manifolds. In fact, such computational geometry analyses - can face numerical robustness issues as a consequence of which a - mesh can be detected as lying completely inside a dataset although - in reality it is epsilon-close only, i.e. almost touching only - the edge (e.g. from inside). - Practically, humans would 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 more flexible. - - - - - - Array of iso-contour values. For each value the tool computes - an iso-surface and performs subsequent analyses. - 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. - Each triangle is reported with an ID specifying to which triangle - cluster (with IDs starting at zero) the triangle belongs. - The clustering 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 these - effects 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 Al3Sc precipitates in aluminum alloys which in reconstructions - can appear as ellipsoids although they should be almost spherical, - depending on their size. - - - - - 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 very - small sub-complexes (e.g. small isolated tetrahedra). - - These can be for instance be small tetrahedra/polyhedra about the - center of a voxel of the support grid on which marching cubes operates. - When these objects are small, it is possible that they contain no 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: - Physically 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 not at least one 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). - - - - - - Specifies if the tool should report for each closed polyhedron - all evaporation IDs of those ions which lie inside or on the - boundary of the polyhedron. This information can be used e.g. - in the paraprobe-intersector tool to infer if two objects share - common ions, which can be interpreted as an argument to assume - 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. - 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 ion positions and thus sharing ions is a sufficient - but not a necessary condition for object intersections. - - 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 edge of the dataset. For this the tool currently - inspects if the shortest distance between the set of triangles of the - surface mesh and the triangles of the edge model is larger than the - 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 is likely affected - by the fact that the dataset is finite. - - - - - - Specifies if the tool should analyze a doppelganger/proxy mesh for - each cluster of triangles whose combinatorial analysis according - to has_object showed 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 precipitate. In most cases objects, - like precipitates in atom probe end up as open objects because - they have been clipped by the edge of the dataset. Using a proxy is - then a strategy to still be able to account for these objects. - Nevertheless users should make themselves familiar with the - potential consequences and 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 placed, centered, and align - 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 the edge of - the dataset. Currently paraprobe-nanochem supports cylindrical - ROIs. A possible intersection of these with the edge of the - dataset, i.e. the triangulated surface mesh model for the edge - is performed. This test checks if the cylinder intersects with - a triangle of the surface mesh. If this is the case, the ROI is - assumed to make edge contact, else, the ROI is assumed to have - no edge contact. - - This approach does not work if the ROI would be completely - outside the dataset. Also in this case there would be - no intersection. For atom probe this case is practically - irrelevant because for such a ROI there would also be no ion - laying inside the ROI. Clearly it has thus to be assumed that - the edge model culls the entire dataset. Instead, if one would - cut a portion of the dataset, compute an edge model for this - point cloud, it might make sense to place a ROI but in this - case the edge contact detection is not expected to work properly. - - - - - - - Analyses of interfacial excess. - - - - Interfacial excess computations are performed for local regions-of-interests - (ROIs) at selected facets or interface patch. - For instance many scientist compute the interfacial excess for - selected triangle facets of a created iso-surface. In this case, - computed iso-surfaces of paraprobe could be used. An example are triangle - facet sets about closed polyhedra, for instance to compute interfacial - excess related to phase boundaries of second-phase precipitates. - - Another example are free-standing triangle patches of the iso- - surfaces which paraprobe creates. These could be characterized - for interfacial excess. The sub-routines during iso-surface - computations already include a procedure to automatically align - local triangle normals based on the gradients of e.g. composition - fields. In this case, these triangulated surface patches - could also be used as a source for computing interfacial - excess. - - Often scientists face situations, though, in which there is no - immediately evident composition gradient across the interface - (grain or phase boundary) and orientation information about the - adjoining crystal is neither available nor reliable enough. - - In this case `P. Felfer et al. <https://doi.org/10.1016/j.ultramic.2015.06.002>`_ proposed a method - to manually place control points and run an automated tessellation-based - algorithm to create a triangulated surface patch, i.e. a model of the - location of the interface. In a post-processing step this triangle - set can then be used to compute again interfacial excess in an - automated manner by placing ROIs and aligning them with - consistently precomputed triangle normals. - - A similar use case is conceptually the one proposed by `X. Zhou et al. <https://doi.org/10.1016/j.actamat.2022.117633>`_ - They used first a deep-learning method to locate planar triangulated - grain boundary patches. These are eventually processed further - with manual editing of the mesh via tools like Blender. - Once the user is satisfied with the mesh, the computations of interfacial - excess reduce again to an automated placing of ROIs, computations - of the distributing of ions to respective ROIs and - reporting the findings via plotting. - - Yet another approach for constructing an triangulated surface patch - of an interface is to use point cloud processing methods which have - been proposed in the laser-scanning, geoinformatics, and CAD community. - Different computational geometry methods are available for fitting - a parameterized surface to a set of points, using e.g. non-uniform - rational B-splines (NURBS) and triangulating these according - to prescribed mesh quality demands. - - The advantage of these methods is that they can be automated and - pick up curved interface segments. The disadvantage is their often - strong sensitivity to parameterization. As a result also such methods - can be post-processed to yield a triangulated surface patch, - and thus enable to run again automated ROI placement methods. - For example like these which were explored for the use case of - iso-surfaces with closed objects and free-standing - surface patches that delineate regions of the dataset with a - pronounced composition gradient normal to the interface. - - This summary of the situations which atom probers can face when - requesting for interfacial excess computations, substantiates there - exists a common set of settings which can describe all of these methods - and, specifically, as here exemplified, the automated placing - and alignment functionalities for ROIs that is an important - step all these workflows. - - Specifically, paraprobe-nanochem operates on an already existent - triangle set. - - - - - - - - - - The interface model is the result of a previous (set of) processing - steps as a result of which the user has created a triangulated - surface mesh (or a set of, eventually connected such meshes). - These interface models are useful, if not required, in cases when - there is no other independent approach to locate an interface. - - These are cases when insufficient crystallographic latent - information is available and also no consistent concentration - gradient detectable across the interface. It is then the users' - responsibility to deliver a triangle mesh of the interface model. - - - - Filename to HDF5 file which contain vertex coordinates, facet indices, - facet unit normals. The user is responsible for the triangle - and winding order to be consistent. - Input is expected as a matrix of the coordinates for all disjoint - vertices, a (Nvertices, 3)-shaped array of NX_FLOAT. - Input is expected to include also a matrix of facet indices - referring to these disjoint vertices. This matrix should be a - (Nfacets, 3)-shaped array of NX_UINT. Further required input - is a (Nfacets, 3)-shaped array of NX_FLOAT signed facet unit - normals and a (Nvertices, 3)-shaped array of NX_FLOAT signed - vertex unit normals. Vertex indices need to start at zero and - must not exceed Nvertices - 1, i.e. the identifier_offset is 0 - and facet indices are indexed implicitly, i.e. [0, Nvertices-1]. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex positions. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet indices. - - - - - Absolute HDF5 path to the dataset which specifies the - array of facet signed unit normals. - - - - - Absolute HDF5 path to the dataset which specifies the - array of vertex signed unit normals. - - Users should be aware that triangulated surface meshes are - only approximations to a given complex, eventually curved shape. - Consequently, computations of normals show differences between - the vertex and facet normals. Vertex normals have to be - interpolated from normals of neighboring facets. Consequently, - these normals are affected by the underlying parameterization - and curvature estimation algorithms, irrespective of how - contributions from neighboring facets are weighted. By contrast, - facet normals are clearly defined by the associated triangle. - Their disadvantage is that they the normal field has discontinuities - at the edges. In general the coarser an object is triangulated - the more significant the difference becomes between computations - based on facet or vertex normals. - Paraprobe-nanochem works with facet normals as it can use - parts of the numerical performance gained by using cutting - edge libraries to work rather with finer meshes. - - - - - - - - Create a simple principle component analysis (PCA) to mesh a - free-standing interface patch through a point cloud of decorating solutes. - These models can be useful for quantification of Gibbsian - interfacial excess for interfaces where iso-surface based methods - may fail or closed objects from iso-surfaces are not desired or - when e.g. there are no substantial or consistently oriented - concentration gradients across the interface patch. - - The interface_meshing functionality of paraprobe-nanochem can be useful - when there is also insufficient latent crystallographic information - available that could otherwise support modelling the interface, - via e.g. ion density traces in field-desorption maps, as were used and - discussed by `Y. Wei et al. <https://doi.org/10.1371/journal.pone.0225041>`_ - or are discussed by `A. Breen et al. <https://github.com/breen-aj/detector>`_ - - It is noteworthy that the method here used is conceptually very similar - in implementation to the work by `Z. Peng et al. <https://doi.org/10.1017/S1431927618016112>`_ - Noteworthy, her team uses the DCOM approach originally proposed by P. Felfer et al. - However, both of these previous works neither discuss in detail - nor implement inspection functionalities which enable a detection of - potential geometric inconsistencies or self-interactions of the - resulting DCOM mesh. This is what paraprobe-nanochem implements - via the Computational Geometry Algorithms Library. - - - - Method how to initialize the PCA: - - * 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>`_ - to create a control_point_file which can be parsed by paraprobe-parmsetup - to match the here required formatting in control_points. - - - - - - - - - The name of the control point file to use. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically - contains these data. - - - - - - X, Y, Z coordinates of disjoint control point read from - an HDF5 file named according to control_point_file. - - - - - - - - - - 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 in a more robust - implementation. - - - - - - - - Specify the types of those ions which decorate the interface and - can thus be assumed as markers for locating the interface and - refining its local curvature. - - - - Array of iontypes to filter. The list is interpreted as a whitelist, - i.e. ions of these types are considered the decorating species (solutes). - - - - - - - - - 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 will - be eventually relocated. The larger the DCOM radius is relative to - the target_edge_length the more likely it is that vertices will be - relocated so substantially that eventually triangle self-intersections - can occur. If the code detects these it warns and stops in a - controlled manner so that the user can repeat the analyses - with a smaller value. - - - - - - - - - Array of integers which specify for each DCOM step how many times - the mesh should be iteratively smoothened. - - Users should be aware the three array 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 - 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. - - - - - - - - - Functionalities for placing regions-of-interest (ROIs) in the dataset - or at specific microstructural features to characterize composition - profiles and cumulated profiles for quantification of interfacial excess. - Paraprobe-nanochem currently places cylindrical ROIs. ROIs are probed - across the triangulated surface of a user-defined mesh. - ROIs are placed at the barycenter of the triangular facet. - - The tool can be instructed to orient the profile for each ROIs with - the positive normal of the triangle facet normals. Profiles are - computed for each ROI and facet triangle. The code will test which - ROIs are completely embedded in the dataset. - Specifically, in this test the tool evaluates if the ROI cuts at least - one triangle of the triangulated surface mesh of the edge of the dataset. - If this is the case the ROI will be considered close to the edge - (of the dataset) and not analyzed further; else the ROI will be - processed further. - Users should be aware that the latter intersection analysis is strictly - speaking not a volumetric intersection analysis as such one is much - more involved because the edge model can be a closed non-convex polyhedron - in which case one would have to test robustly if the cylinder pierces - or is laying completely inside the polyhedron. For this the polyhedron has - to be tessellated into convex polyhedra as otherwise tests like the - Gilbert-Johnson-Keerthi algorithm would not be applicable. - - Specifically, the tool computes atomically decomposed profiles. - This means molecular ions are split into atoms/isotopes with respective - multiplicity. As an example an H3O+ molecular ion contains three - hydrogen and one oxygen atom respectively. The tool then evaluates - how many ions are located inside the ROI or on the surface of the - ROI respectively. All atom types and the unranged ions are distinguished. - As a result, the analyses yield for each ROI a set of sorted lists of - signed distance values. Currently, the distance is the projected - distance of the ion position to the barycenter of the triangle - and triangle plane. - - This will return a one-dimensional profile. Post-processing the set - of atom-type-specific profiles into cumulated profiles enable the - classical Krakauer/Seidman-style interfacial excess analyses. - Furthermore, the tool can be instructed to compute for each - (or a selected sub-set of facet) a set of differently oriented profiles. - - - - - The feature mesh enables the injection of previously computed triangle - soup or mesh data. Such a mesh can be the model for a grain- or phase - boundary patch (from e.g. interface_meshing) jobs. - - - - Name of the HDF5 file which contains vertex coordinates and facet - indices to describe the desired set of triangles which represents - the feature. - - - - Version identifier of the file such as a secure hash which documents - the binary state of the file to add an additional layer of - reproducibility from which file specifically contains these data. - - - - - - Absolute path to the HDF5 dataset in the respectively specified HDF5 - file under filename which details the array of vertex positions. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details the array of facet indices. - - - - - Absolute path to the HDF5 dataset in the respective specified HDF5 - file under filename which details consistently oriented facet - normals of the facets. - - - - - - - - - - - The tool enables to inject precomputed distance information for each - point which can be used for further post-processing and analysis. - - - - - Name of an HDF5 file which contains ion distances. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional - layer of reproducibility from which file specifically contains - these data. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - Which type of distance should be reported for the profile. - - - - - - - - - In which directions should the tool probe for each ROI. - - - - - - - - - For each ROI, how high (projected on the cylinder axis) - should the cylindrical ROI be. - - - - - - For each ROI, how wide (radius) should the cylindrical ROI be. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml deleted file mode 100644 index e5594b5049..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_ranger.nxdl.xml +++ /dev/null @@ -1,297 +0,0 @@ - - - - - - - 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. - - - - - Configuration of a paraprobe-ranger tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - How many task to perform? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - A list of pairs of number of protons and either the value 0 (per row) - or the mass number for all those isotopes which are assumed present - in a virtual specimen. - The purpose of this field is to compute also composition-weighted - products to yield a simple estimation which could potentially help - scientists to judge if certain molecular ions are to be expected. - The corresponding setting store_composition_weighted_product should be - activated. - - - - - - - - - - A list of pairs of number of protons and mass number for all isotopes - to consider that can be composed into (molecular) ions, during the - recursive molecular_ion_search. - - - - - - - - - The mass-to-charge-state ratio interval in which - all molecular ions are searched. - - - - - - - - The maximum charge that a molecular ion should have. - - - - - The maximum number of isotopes of which the molecular ion - should be composed. Currently this must not be larger than 32. - - Users should be warned that the larger the maximum_charge and - especially the larger the maximum_number_of_isotopes is chosen, - the eventually orders of magnitude more costly the search becomes. - - This is because paraprobe-ranger computes really all (at least) - theoretically possible combinations that would have likely a - mass-to-charge-state ratio in the specified mass_to_charge_interval. - It is the challenge in atom probe to judge which of these (molecular) - ions are feasible and also practically possible. This tool does not - answer this question. - - Namely, which specific molecular ion will evaporate, remain stable - during flight and becomes detected is a complicated and in many cases - not yet in detail understood phenomenon. The ab-initio conditions - before and during launch, the local environment, arrangement and field - as well as the flight phase in an evacuated but not analysis chamber - with a complex electrical field, eventual laser pulsing in place, - temperature and remaining atoms or molecules all can have an effect - which iontypes are really physically evaporating and detected. - - - - - Report the accumulated atomic mass from each isotope building the ion. - Accounts for each identified ion. - Relativistic effects are not accounted for. - - - - - Report the product of the natural abundances from each isotope building - the ion. Accounts for each identified ion. - - The value zero indicates it is not possible to build such molecular ion - from nuclides which are all observationally stable. - Very small values can give an idea/about how likely such a molecular ion - is expected to form assuming equal probabilities. - - However in atom probe experiments this product has to be modified - by the (spatially-correlated) local composition in the region from - which the ions launch because the formation of a molecular ion depends - as summarized under maximum_number_of_isotopes on the specific - quantum-mechanical configuration and field state upon launch - or/and (early state) of flight respectively. - We are aware that this modified product can have a substantially - different value than the natural_abundance_product. - - Natural abundancies folded with the estimated compositions of the - specimen can differ by orders of magnitude. - - - - - - Report the charge state of the ions. - - - - - Report if identified ions should be characterized - wrt to their number of disjoint isotopes. - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml deleted file mode 100644 index 9663ac34c0..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_selector.nxdl.xml +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-selector tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many roi_selection processes should the tool execute. - - - - - This process identifies which of the points/ions in the datasets are - inside or on the surface of geometric primitives and meet optionally - specific other filtering constraints. - A typical use case of a roi_selection is to restrict analyses to - specific regions of the dataset, eventually regions with a complicated - shape. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml deleted file mode 100644 index 9c4f3854ed..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_spatstat.nxdl.xml +++ /dev/null @@ -1,374 +0,0 @@ - - - - - - - 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 sources iontypes to distinguish. - - - - - Number of different target iontypes to distinguish. - - - - - Configuration of a paraprobe-spatstat tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many range_with_existent_iontypes processes should - the tool execute as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distances of each ion to a - representation of the edge of the dataset which can be used to - control and substantially reduce edge effects when computing - spatial statistics. - - - - Name of an HDF5 file which contains ion-to-edge distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-edge distance values for each ion. - The shape of the distance values has to match the length - of the ion positions array in dataset/dataset_name_reconstruction - and dataset_name_mass_to_charge respectively. - - - - - Threshold to define how large an ion has to lay at least far away - from the edge of the dataset so that the ion can act as a source, - i.e. that an ROI is placed at the location of the ion and its - neighbors are analyzed how they contribute to the computed statistics. - - The ion_to_edge_distances threshold can be combined with a threshold - for the ion_to_feature_distances. - Specifically, if ion_to_feature_distances are loaded an ion only - acts as a source if both threshold criteria are met. - - The threshold is useful to process the dataset such that ROIs do - not protrude out of the dataset as this would add bias. - - - - - - 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 - a threshold value. - - - - Name of an HDF5 file which contains ion-to-feature distances. - - - - - Absolute HDF5 path to the dataset with the - ion-to-feature distance values for each ion. - - - - - 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 the ion_to_feature_distances threshold is combined - with the ion_to_edge_distances threshold. - - - - - - - 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 - iontype labels randomly across the entire set of ions. - - - - - - - - - - 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_config_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml deleted file mode 100644 index 984be5dec6..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_surfacer.nxdl.xml +++ /dev/null @@ -1,287 +0,0 @@ - - - - - - - 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. - - - - - Configuration of a paraprobe-surfacer tool run in atom probe microscopy. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - For now a support field for the tool to identify how many individual - analyses the tool should executed as part of the analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specifies the method that is used to preprocess the point cloud. - The main purpose of this setting is to specify whether the point - cloud should be segmented or not during the preprocessing - to identify which points are more likely lying close to the edge - of the point cloud. These points could be more relevant than the - interior points for certain alpha-shape constructions. - - By default no such filtering is used during pre-processing. - By contrast, the option percolation activates a preprocessing - step during which a Hoshen-Kopelman percolation analysis is used - to identify which points are closer to the edge of the dataset. - This can reduce the number of points in the alpha-shape - computation and thus improve performance substantially. - Details about the methods are reported in - `M. Kühbach et al. <https://doi.org/10.1038/s41524-020-00486-1>`_. - - - - - - - - - - When using the option percolation during 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. This 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 computes first also a convex_hull_naive - but refines the mesh by triangle flipping and splitting to improve - the quality of the mesh. - - 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 library to choose a value - which the library considers as an optimal value. Details are - define in the respective section of the CGAL library on 3D alpha - shapes. - - The value set_of_values instructs to compute a list of - alpha-shapes for the specified alpha-values. - - The value set_of_alpha_wrappings instructs the library to generate - a set of so-called alpha wrappings. These are a method - which is similar to alpha shapes but provide additional guarantees - though 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_config_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml deleted file mode 100644 index 0bf6e109c5..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_tessellator.nxdl.xml +++ /dev/null @@ -1,253 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configuration of a paraprobe-tessellator tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - How many individual analyses should the tool execute. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The tool enables to inject precomputed distance information for - each point which can be used for further post-processing and analysis. - - - - Name of an HDF5 file which contains the ion distances. - Users are responsible this file and referred to dataset under - dataset_name have an ion_distance value for each ion. - - - - Version identifier of the file such as a secure hash which - documents the binary state of the file to add an additional layer of - reproducibility. - - - - - - Absolute HDF5 path to the dataset with distance values for each ion. - - - - - - - Specifies for which points the tool will compute the tessellation. - By default, a Voronoi tessellation is computed for all ions in the - filtered point cloud. - - - - - - - - - - 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 if the cell 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 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 - by the presence of the boundary. - - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml deleted file mode 100644 index 4dd9de431b..0000000000 --- a/contributed_definitions/NXapm_paraprobe_config_transcoder.nxdl.xml +++ /dev/null @@ -1,119 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Configurations of a paraprobe-transcoder tool run in atom probe microscopy. - - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ideally an ever persistent resource where the source code of the - program and build instructions can be found so that the program can be - configured ideally in such a manner that the result of this computational - process is recreatable deterministically. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - - - - The path and name of the file (technology partner or community format) - from which to read the reconstructed ion positions. Currently, POS, - ePOS, APT files from APSuite, and NXS, i.e. NeXus/HDF5 files - are supported. - - - - - - - - The path and name of the file (technology partner or community format - from which to read the ranging definitions, i.e. how to map mass-to- - charge-state ratios on iontypes. Currently, RRNG, RNG, and NXS, i.e. - NeXus/HDF5 files are supported. - - - - - - - - - - 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..d7d0f13191 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_config.nxdl.xml @@ -0,0 +1,119 @@ + + + + + + Application definition for a configuration file of the paraprobe-distancer tool. + + The tool paraprobe-distancer tool evaluates exactly the shortest Euclidean distance for each + member of a set of points against a set of triangles. + + 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. + + + + + + + + + + + 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 index_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..1cffc8eab2 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_distancer_results.nxdl.xml @@ -0,0 +1,139 @@ + + + + + + + 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 a results file of the paraprobe-distancer tool. + + The tool paraprobe-distancer tool evaluates exactly the shortest Euclidean distance for each + member of a set of points against a set of triangles. + + 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. + + + + + + + + + + + + + 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..76a3c27c00 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_intersector_config.nxdl.xml @@ -0,0 +1,253 @@ + + + + + + + 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. + + + + + + + + + + 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. + + + + 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 inferred + 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 inferred + 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..dff4a65f9f --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_intersector_results.nxdl.xml @@ -0,0 +1,219 @@ + + + + + + + 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. + + + + + + + + + + The results of an overlap/intersection analysis. + + + + + A matrix of indices_feature 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 indices_feature 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 indices_feature + 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 precipitates B. + + Coprecipitation analysis now logically connects these independent + characterization results to establish spatial correlations of e.g. + the precipitates' spatial arrangement. + + + + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature was assigned. + Here for features of the current_set. + + + + + + + + + Matrix of indices_feature and cluster_id pairs which + encodes the cluster to which each indices_feature 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. + + + + + + + + + + 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..98b61e358a --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_nanochem_config.nxdl.xml @@ -0,0 +1,864 @@ + + + + + + + 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. + + + + + + + + + + Discretization and distributing of the ion point cloud on a 3D grid + to enable analyses at the continuum scale. + + 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. + + + + + + + + + Configuration for the algorithm that defines the multiplicity of + each reconstructed position during the delocalization. + + + + The multiplicity of an ion at a reconstructed position is defined as follows: + + * resolve_unknown, multiplicity equals 1 for all ions of the unknown_type + This mode is useful for segmenting regions with poor ranging. + * resolve_point, multiplicity equals 1 for all ions + This mode is useful for segmenting point density. + * resolve_atom, multiplicity equals the number of atoms per ion + This mode is useful for segmenting atomic density. + * resolve_element, multiplicity equals the number of elements in the whitelist per ion + This mode is useful for segmenting regions of specific elemental composition (ignoring nuclids) + * resolve_element_charge, ???multiplicity like resolve_element when charge is met + * resolve_isotope, multiplicity equals the number of nuclides in the whitelist per ion + This mode is useful for segmenting regions of specific isotopic composition + * resolve_isotope_charge, ??? + + Other multiplicities are 0. + + + + + + + + + + + + + + TODO + + + + + TODO + + + + + + + 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:`NXatom`) 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 + (microstructural) 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 bias 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 aluminum 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 bias 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 paraprobe-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 split 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..431f2360e7 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_nanochem_results.nxdl.xml @@ -0,0 +1,1177 @@ + + + + + + + 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 a oned_profile task. + + + + + Application definition for a results file of the paraprobe-nanochem tool. + + + + + + + + + + + + + + + + + + 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. + + + + + + + + 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. + + + + + + + + + + + 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. + + + + + 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 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 XDMF 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`. + + + + + 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. + + + + + + + + + + + + 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 indices_feature 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_id / identifier_ion 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 coloring each ROI by its identifier. + + + + + + + + XDMF support to enable coloring each ROI whether it has edge contact or not. + + + + + + + + XDMF support to enable coloring each ROI by its number of atoms. + + + + + + + + XDMF support to enable coloring 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:`NXatom`. + + + + + + + + + + + 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..2852414f13 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_config.nxdl.xml @@ -0,0 +1,55 @@ + + + + + + + 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. + + The tool paraprobe-ranger evaluates how mass-to-charge-state-ratio + values map on (molecular) ion types. + + + + + + + + + + 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..2d42fa8948 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_ranger_results.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + + 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. + + The tool paraprobe-ranger evaluates how mass-to-charge-state-ratio + values map on (molecular) ion types. + + + + + + + + + + The tool loads ranging definitions from the configuration file and + evaluates for each ion to which iontype it matches. + If an ion matches on no type, the ion is assume of the default + *unknown_type*. In this case, the value *iontypes* is 0. + In other cases the value is larger than 0. + + + + The iontype (identifier) for each ion that was best matching, + stored in the order of the evaporation sequence ID. + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml deleted file mode 100644 index db2efc503c..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_clusterer.nxdl.xml +++ /dev/null @@ -1,501 +0,0 @@ - - - - - - - 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 entries in the restricted_identifier dictionary. - - - - - Results of a paraprobe-clusterer tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - - - - - - - - - The result of a cluster analyses. These include typically the label for - each ion/point documenting to which feature (if any) an ion is assigned. - Typically, each analysis/run yields only a single cluster. - In cases of fuzzy clustering it can be possible that an ion is assigned - to multiple cluster (eventually with different) weight/probability. - - - - Results of a DBScan clustering analysis. - - - - The epsilon (eps) parameter. - - - - - The minimum points (min_pts) parameter. - - - - - Number of members in the set which is partitioned into features. - Specifically, this is the total number of targets filtered from the - dataset. Cardinality here is not 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 values to -1 and unassigned points to 0. - Numerical identifier have to be strictly increasing. - - - - - - The evaporation sequence identifier to figure out which ions - from the reconstruction were considered targets. - - - - - - - - - The raw labels from the DBScan clustering backend process. - - - - - - - - The raw array of core sample indices which specify which of the - targets are core points. - - - - - - - - - Matrix of numerical label for each member in the set. - For classical clustering algorithms this can for instance - encode the cluster_identifier. - - - - - - - - - The array of weight which specifies how surely/likely the - cluster is associated/assigned to a specific identifier as - is specified in the cluster_identifier array. - For the DBScan and atom probe tomography 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 isotope of - requested type. - - - - - - - - Optional bitmask encoding if members of the set are assigned to as noise or not. - - - - - - - - Optional bitmask encoding if member of the set are a core point. - For details to which feature/cluster an ion/point is a core point - consider numerical_label. - - - - - - - - In addition to the detailed storage which members was grouped to - which feature/group summary statistics are stored under this group. - - - - - 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). - - - - - Array of numerical identifier of each feature (cluster). - - - - - - - - Array of number of members for each feature. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml deleted file mode 100644 index 1da4549b95..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_distancer.nxdl.xml +++ /dev/null @@ -1,388 +0,0 @@ - - - - - - - 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 triangles in the set. - - - - - Results of a paraprobe-distancer tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute the analytical distance of each ion - to a set of triangles. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of the triangles in the set - were considered. Usually these are all but sometimes users may - wish to filter certain portions of the triangles out. - If window_triangles is not provided it means that - all triangles were taken. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - The closest analytical distance of the ions to their respectively - closest triangle from the triangle set. - - - - - - - - A bitmask which identifies which of the distance values - can be assumed to have a consistent sign because the closest - triangle had a consistent outer unit normal defined. - For points whose bit is set 0 the distance is correct but the - sign is not reliable. - - - - Number of triangles covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. - - - - - - - - - The identifier of the triangle that is closest for each ion. - - - - - - - - A support field to visualize each ion and with this the distance - information using XDMF and e.g. Paraview. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml deleted file mode 100644 index 140c1baf5b..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_intersector.nxdl.xml +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - - 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 stats. - - - - - Results of a paraprobe-intersector tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The results of an overlap/intersection analysis. - - - - A matrix of feature_identifier which 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 a 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 is symmetric next_to_current maps the links in current_to_next - in 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 the - pair relations are analyzed with respect to which feature identifier - cluster in identifier space. Thereby a logical connection (link) is - established between the features in the current_set and next_set. - Recall that these two set 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 to characterize precipitates - B. Coprecipitation analysis now logically connects these independent - characterization results to establish spatial correlations of e.g. - 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 last 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml deleted file mode 100644 index bf2f7afa02..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_nanochem.nxdl.xml +++ /dev/null @@ -1,1962 +0,0 @@ - - - - - - - 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 XDMF values to represent all faces of triangles via XDMF. - - - - - The total number of entries in a feature dictionary. - - - - - The total number of member distinguished when reporting composition. - - - - - Results of a paraprobe-nanochem tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must no longer compute analyses. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases, it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - If nothing else is specified we assume that there - has to be at least one set of NXtransformations named - paraprobe defined, which specifies the coordinate system. - In which all positions are defined. - - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed during this process. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used, padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe-toolbox executable. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth (padding). - - - - - - - - - - - The weighting model specifies how mark data are mapped to a weight - per point/ion. For atom probe microscopy (APM) mark data are e.g. - which iontype an ion has. As an example, different models are used - which account differently for the multiplicity of a point/ion - during delocalization: - - * unity, all points/ions get the same weight 1. - * atomic_decomposition, points get as much weight as they - have atoms of a type in atomic_decomposition_rule, - * isotope_decomposition, points get as much weight as they have - isotopes of a type in isotopic_decomposition_rule. - - - - - - - - - - - A list of elements (via proton number) to consider for the - atomic_decomposition weighting model. - Elements must exist in the periodic table of elements and be - specified by their number of protons. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - In the case of elements this hashing rule has the advantage - that for elements the proton number is their hash value because - N is zero. - - - - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - - - - - - - - - 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/not considered. - - - - - - - - - A list of isotopes (via proton and neutron number) to consider - for the isotopic_decomposition weighting model. - Isotopes must exist in the nuclide table. - Values in match are isotope hash values using the following - hashing rule $H = Z + 256*N$ with $Z$ the number of protons - and $N$ the number of neutrons of the isotope. - - - - Meaning of the filter: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. - - - - - - - - - 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/not considered. - - - - - - - - - How results of the kernel-density estimation were computed - 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 white list of elements in each voxel. - - - - - - - - - - - Weighting factor, in atom probe, often termed multiplicity. - The weighting factor is the multiplier with which the integrated - intensity contribution from the point/ion gets multiplied. - The delocalization computes the integrated intensity for each - grid cell. Effectively, this is an explicitly evaluated kernel - method where each specific position of an ion is replaced by a - smoothing kernel. For atom probe weights are positive and integer - specifically the multiplicity of the ion, in accordance with the - respective rulesets as defined by weighting_model. - - - - - - - - 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 unit 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. - - - - - - - - - Reference to or definition of a coordinate system with - which the positions and directions are interpretable. - If the coordinate system is not specified the paraprobe - coordinate system is used. - - - - - - 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 - [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - - - - 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 [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 [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 [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: [$\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 based on which subsequent - iso-surfaces will be computed. In commercial software so far - there is not a possibility to export such grid. - - - - - - - - - - - - - - - - - - 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 nabla operator applied to - scalar_field_magnitude. - - - - - - - - - - - - - - - - - - - - Cell center of mass positions along x. - - - - - - - - - Cell center of mass positions along y. - - - - - - - - Cell center of mass positions along z. - - - - - - - - The gradient vector. - - - - - - - - - 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. - - - - - - - - - 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. - - - - - - - - - - Sigma 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 of the kernel in each dimension in the paraprobe - coordinate_system with i = 0 is x, i = 1 is y, i = 2 is z. - - - - - - - - - - An iso-surface is the boundary between two regions across which - the magnitude of a scalar field falls below/exceeds a threshold - magnitude phi. - For applications in atom probe microscopy the location and shape - of such a boundary (set) is typically approximated by - discretization. - 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. - - - - - Details about the specific marching cubes algorithm - which was taken to compute the iso-surface. - The grid is the delocalization grid. - - - - 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 - [identifier_offset, identifier_offset+c-1]. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - 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 [identifier_offset, identifier_offset+c-1]. - - - - - 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 [identifier_offset, identifier_offset+c-1]. - - - - - 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: [$\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 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. This yields a - set of connected features with their surfaces discretized - by triangles. Currently, the tool distinguishes at most - three types of features: - - 1. So-called objects, i.e. necessarily watertight features - represented polyhedra. - 2. So-called proxies, i.e. features that were replaced by a - proxy mesh and made watertight. - 3. Remaining triangle surface meshes of arbitrary shape and - cardinality. - - 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. - - - - - 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. - - - - - - - - - Details for features which are (closed) objects. - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - 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. - - - - - - - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - Details for all those objects close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - - - Count or weight which, when divided by total, - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - Details for all those objects far from edge, i.e. those - whose ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - - - Details for features which are so-called proxies, i.e. objects - which have been reconstructed and combinatorially closed with - processing their partial triangulated_surface_mesh - (hole filling, refinement). - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Details for those proxies close to edge, i.e. those which - have at least one ion which lays closer to a modelled edge - of the dataset than threshold. - Identifier have to exist in feature_identifier. - - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - Details for those proxies far from edge, i.e. those whose - ions lay all at least threshold distant from a - modelled edge of the dataset. - - - - - - - - - - - - - - - Total (count) relevant for normalization. - - - - - - - - - - Count or weight which, when divided by total - yields the composition of this element, isotope, - molecule or ion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Array of evaporation_identifier / ion_identifier which - specify ions laying inside or on the surface of the feature. - - - - - - - - - - - - - - - - - - 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 some iteration before the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 - - - - - - - - - - - - - - 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 triangle surface mesh representing the interface model. - Exported at some iteration after the next DCOM step. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 - - - - - - - - - - - - - - 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 though we discretize them into regular n-gons. - Using for instance a 360-gon, i.e. a regular n-gon with 360 - edges resolves the lateral surface of each cylinder very finely - so that they are rendered smoothly in visualization software. - - - - - - Position of the geometric center, which often is but not - necessarily has to be the center_of_mass of the polyhedra. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - ROI cylinder. Identifiers are defined explicitly. - - - - - - - - - - - - - - - The number of atoms in each ROI. - - - - - - - - The number of ions in each ROI. - - - - - - - - The orientation of the ROI defined via a vector which points along - the cylinder axis and whose length is the height of the cylinder. - - - - - - - - - - In the direction of the ROI. - - - - - Hashvalue - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml deleted file mode 100644 index 9a56d796e1..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_ranger.nxdl.xml +++ /dev/null @@ -1,425 +0,0 @@ - - - - - - - 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. - - - - - Results of a paraprobe-ranger tool run. - - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - 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 with a 0 as its - respective value in the iontypes array. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - The iontype ID 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 elements of which a (molecular) ion - is build are considered. By contrast, charged_iontypes takes - into account also the charge state. - - - - - - - - A bitmask which identifies exactly all those ions ranged irrespective - the type they ended up with. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - Paraprobe-ranger performs a combinatorial search over - all possible or a reduced set of nuclides to identify - into which ions these can be composed. - - - - The main result is the list of molecular ions, here formatted - according to the definitions of a set of isotope_vectors - as detailed in :ref:`NXion`. - - - - - - - - - The mass-to-charge-state ratio of each molecular ion - without considering relativistic or quantum effects. - - - - - - - - The mass of each molecular ion without - considering relativistic or quantum effects. - - - - - - - - - The charge_state of each molecular ion. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The product of the natural abundance of the isotopes building - each molecular ion. Further details are available in - :ref:`NXapm_paraprobe_config_ranger`. - - - - - - - - The number of disjoint nuclides for each molecular ion. - - - - - - - - The number of nuclides for each molecular ion. - - - - - - - - - Paraprobe-ranger loads 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 with a 0 as its respective value in the - iontypes array. In contrast to use_existent_ranging this process - does neither needs measured ion position nor mass-to-charge-state - ratio values. - - - - - The length of the isotope_vector used to describe molecular ions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml deleted file mode 100644 index 61f42450d5..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_selector.nxdl.xml +++ /dev/null @@ -1,272 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-selector tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset - were selected to become included in the region-of-interest (ROI). - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml deleted file mode 100644 index 46faf02652..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_spatstat.nxdl.xml +++ /dev/null @@ -1,362 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The total number of ions in the reconstruction. - - - - - Results of a paraprobe-spatstat tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - 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 stay the same. - - The order matches the iontypes array from a given ranging results - as is specified in the configuration settings inside the specific - config_filename that was used for this spatstat analysis. - - - - - - - - K-nearest neighbor statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - Radial distribution statistics. - - - - Right boundary of the binning. - - - - - - - - - - - - - Cumulated - - - - - - - - Cumulated and normalized by total counts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml deleted file mode 100644 index 2edb334304..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_surfacer.nxdl.xml +++ /dev/null @@ -1,501 +0,0 @@ - - - - - - - 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. - - - - - Results of a paraprobe-surfacer tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. Computations of alpha complexes may have filtered this - ion set further but this process is deterministic. - - - - Number of ions covered by the mask. The mask may be 0 for most. - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - 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 - the alpha complex was then in fact computed. This window - can be different to the entire window as irrelevant ions might - have been filtered out to reduce the computational costs of the - alpha complex analysis. - - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The set of triangles in the coordinate system paraprobe - which discretizes the exterior surface of the alpha complex. - - - - 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 [identifier_offset, identifier_offset+c-1]. - - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - - - - - - - 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 which - is watertight? - - - - - The volume which the triangulated surface mesh encloses - provided that the mesh is watertight. - - - - - - The set of tetrahedra which represent the interior volume of the - complex if that is a closed 2-manifold. - - - - Integer which specifies the first index to be used for distinguishing - tetrahedra. 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. - - - - - The accumulated volume of all interior tetrahedra. - - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - 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). - - - - - - - - - - - - In the future we may want to wrap other primitives - like triangles or polylines. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml deleted file mode 100644 index ba60544672..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_tessellator.nxdl.xml +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - - 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 facets/polygons defining the tessellation. - - - - - Results of a paraprobe-tessellator tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - The tool can be used to compute a Voronoi tessellation the entire - or a sub-set of the reconstruction. The point cloud in the ROI is - wrapped into a tight axis-aligned bounding box. The tool detects if - Voronoi cells make contact with the walls of this bounding box. - The tessellation is computed without periodic boundary conditions. - - - - A bitmask which identifies which of the ions in the dataset were - analyzed. - - - - Number of ions covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by the global axis-aligned bounding box, i.e. boundaries - of the threads are ignored. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The right wall has the positive x axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The front wall has the negative y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The rear wall has the positive y axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the negative z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - A bitmask which identifies which of points have Voronoi cells that - are truncated by a specific wall of the axis-aligned bounding box. - The left wall has the positive z axis of the paraprobe coordinate - system as the outer unit normal. - - - - Number of points covered by the mask. - The mask value for most may be 0. - - - - - - Number of bits assumed matching on a default datatype. - (e.g. 8 bits for a C-style uint8). - - - - - The unsigned integer array representing the content of the mask. - If padding is used the padded bits are set to 0. The mask is for - convenience always as large as the entire dataset as it will - be stored compressed anyway. The convenience feature with this - is that then the mask can be decoded with numpy and mirrored - against the evaporation_id array and one immediately can filter - out all points that were used by the paraprobe. - The length of the array adds to the next unsigned integer - if the number of ions in the dataset is not an integer - multiple of the bitdepth. - - - - - - - - - - - - - - - - Interior volume - - - - - - - - By which MPI process was the Voronoi cell computed. - - - - - - - - By which OpenMP thread was the Voronoi cell computed. - - - - - - - - The number of faces for each polyhedron. Faces of adjoining polyhedra - are counted for each polyhedron. This field can be used to interpret - the array/field with the individual area values for each face. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - polyhedra. 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. - - - - - Integer used to distinguish polyhedra for explicit indexing. - - - - - - - - A simple approach to describe the entire set of polyhedra when - the main intention is to store the shape of the polyhedra for - visualization. - - - - - Number of vertices. - - - - - Number of faces. - - - - - - - - - - - - - A sequence of always first an XDMF topology type key, followed - by the XDMF number of vertices of the polygon, followed by - the vertex identifier which define the facet polygon. First - we store the polygon of the first facet of the first cell, then - the second facet of the first cell, until the last facet of the - first cell, followed by the first facet of the second cell, - and so on and so forth. - - - - - - - - A sequence of cell identifier so that each facet is associated - with its cell because of which it is then possible to segment - out cells three-dimensionally based on cell i.e. evaporation_id. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml b/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml deleted file mode 100644 index e2020b0006..0000000000 --- a/contributed_definitions/NXapm_paraprobe_results_transcoder.nxdl.xml +++ /dev/null @@ -1,566 +0,0 @@ - - - - - - - - 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. - - - - - Number of mass-to-charge-state-ratio intervals mapped on this ion type. - - - - - Total number of integers in the supplementary XDMF topology array. - - - - - Number of ions probed in the combinatorial analysis of the charge states - - - - - Results of a paraprobe-transcoder tool run. - - - - - Version specifier of this application definition. - - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - Given name of the program/software/tool with which this NeXus - (configuration) file was generated. - - - - Ideally program version plus build number, or commit hash or description - of ever persistent resources where the source code of the program and - build instructions can be found so that the program can be configured - ideally in such a manner that the result of this computational process - is recreatable in the same deterministic manner. - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - was started, i.e. the paraprobe-tool executable started as a process. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when the analysis behind this results file - were completed and the paraprobe-tool executable exited as a process. - - - - - The absolute path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the paraprobe-tool executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - If used, contact information and eventually details - of at least the person who performed this analysis. - - - - - - - - - - - - - - - Details about the coordinate system conventions used. - - - - The individual coordinate systems which should be used. - Field names should be prefixed with the following controlled terms - indicating which individual coordinate system is described: - - * paraprobe - * lab - * specimen - * laser - * leap - * detector - * recon - - - - - - - - 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. - - - - - - - - - - On a mid term perspective we would like to evolve the paraprobe-toolbox - to an implementation stage where it works exclusively with completely - provenance-tracked formats for both the configuration of the workflow step - and/or analysis with each tool and also for the output of these analyses - in the form of so-called tool-specific results files. - Currently the Hierarchical Data Format 5 (HDF5) is used to store such data. - - Different file formats can be used to inject reconstructed datasets and - ranging definitions into the toolbox. Traditionally, these are the POS, - ePOS, and APT files with the tomographic reconstruction and other metadata - and RNG and RRNG file formats for the ranging definitions how mass-to-charge - state-ratio values map on (molecular) ion types. Such input should be - injected via specific NeXus/HDF5 files which are documented - in compliance with the NXapm application definition. - - So far the paraprobe-toolbox was used as a standalone tool. Therefore, it - was not relevant during the development to focus on interoperability. - Essentially paraprobe-transcoder was used as a parser to transcode data - in the above-mentioned file formats into a paraprobe-specific - representation. This transcoding should become deprecated. - Here we describe steps we have taken into this direction. - - With the work in the FAIRmat project and the desire to make the paraprobe- - toolbox also accessible as a cloud-computing capable service in the Nomad - Remote Tools Hub (NORTH) the topic of interoperability became more important - and eventually the NXapm application definition was proposed. - NORTH is a GUI and related service in a NOMAD OASIS instance which allows - to spawn pre-configured docker containers via JupyterHub. - Currently, NORTH includes the so-called apm container. A container with - tools specific for analyzing data from atom probe microscopy as well as - processing of point cloud and mesh data. - - The NXapm application definition and related implementation work within - NOMAD OASIS enabled users to parse content of POS, ePOS, APT, RNG, and - RRNG files, surplus key metadata from vendor-agnostic electronic lab notebook - solutions directly into NOMAD OASIS via the uploads section. - The process is automated and yields an NXapm-compliant NeXus/HDF5 file - inside the uploads section in return. - - With these improvements made there is no longer a need for - at least the - users of a NOMAD OASIS and NORTH instance to use the deprecated - PARAPROBE.Transcoder.Results.*.h5 files. Ideally, paraprobe should - automatically detect that the input can now be an NXapm-compliant NeXus/HDF5 - file and in response work with this file directly. - To remain compliant with users however who do not have or do not wish - to use a NOMAD OASIS or NXapm or NeXus at all right now, the solution is - as follows: - - Calling the configuration stage of paraprobe-transcoder is always mandatory. - It is always the first step of working with the toolbox. In this process - the user defines the input files. These can either be nxs i.e. the NXapm/NeXus/ - HDF5 file from e.g. the upload section, or such a file that was obtained from - a colleague with a NOMAD OASIS instance. - In all other cases, users can pass the reconstruction and ranging definitions - using the traditional POS, ePOS, or APT and RNG or RRNG file formats respectively. - - Based on which input the user delivers, the parmsetup-transcoder tool then - creates a configuration file PARAPROBE.Transcoder.Config.SimID.*.nxs and - informs the user whether the input was NeXus (and thus if all relevant - input is already available) or whether the paraprobe-transcoder tool needs - to be executed to convert the content of the vendor files first into a - format which paraprobe can provenance track and understand. - In the latter case, the PARAPROBE.Transcoder.Config.SimID.*.nxs file is - used to communicate to all subsequently used tools from which files - the tools can expect to find the reconstruction and ranging definitions. - - All subsequent analysis steps start also with a tool-specific configuration. - This configuration step reads in (among others) the - PARAPROBE.Transcoder.Config.SimID.*.nxs file from which the configuration - tool identifies automatically whether to read the reconstruction and ranging data - from PARAPROBE.Transcoder.Results.SimID.*.h5 or directly the NXapm-compliant - NeXus/HDF5 file that was created upon preparing the upload or the file shared - from a colleague. This design removes the need for unnecessary copies of the data. - Currently still though users should execute the transcoder step as it will - generate a supplementary XDMF topology field with which the data in either - the NeXus/HDF5 or the transcoded vendor files can be displayed using e.g. - Paraview. For this purpose XDMF is used. - - Of course ideally the APT community would at some point converge to use - a common data exchange file format. To this end, AMETEK/Cameca's APT file format - could be a good starting point but so far it is lacking a consistent way of - how to store generalized ranging definitions and post-processing results. - POS, ePOS, Rouen's ATO, as well as other so far used representations of data - like CSV or text files have, to the best of our current knowledge, no - concept of how to marry reconstruction and (optional) ranging data into - one self-descriptive format. - - This summarizes the rationale behind the current choices of the I/O for - paraprobe. Furthermore, this summarizes also why the fundamental design - of splitting an analysis always into steps of configuration (with parmsetup), - task execution (with the respective C/C++ or Python tool of the toolbox), - and post-processing (e.g. with auto-reporter) is useful because it offers - a clear description of provenance tracking. This is a necessary step to make - atom probe microscopy data at all better aligned with the aims of the - FAIR principles. - - The internal organization of the data entries in the atom_probe group - in this application definition for paraprobe-transcoder results files - mirror the definitions of the NXapm for consistency reasons. - - - - - - Mass-to-charge-state ratio values. - - - - - - - - - - - - Three-dimensional reconstructed positions of the ions. - Interleaved array of x, y, z positions in the specimen space. - - - - - - - - - - - Details about how peaks, with taking into account - error models, were interpreted as ion types or not. - - - - - - - - - Details and results of the combinatorial analyses of this - range definition to identify the charge_state for an ion. - - - - Currently charge_state not charge! - - - - - - - - Specific isotopes building each candidate matching the range. - - - - - - - - - Accumulated mass of the isotopes in each candidate. - Not corrected for quantum effects. - - - - - - - - - Product of natural abundance of the isotopes per candidate. - - - - - - - - Filter criterion on the product of the natural abundances - computed from each isotope building the (molecular) ion. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - Filter criterion on the minimum half life which all isotopes - building the (molecular) ion need to have to consider the - candidate. - Such a filter can be used to reduce the number of possible - molecular ions considered when trying to find a unique solution - to the question which charge_state does a molecular ion - within a given range and given combination of elements have. - - - - - - If the value is zero/false it means that non-unique solutions - are accepted. These are solutions where multiple candidates - differ in their isotopes but have the same charge. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXcs_mm_sys.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml similarity index 57% rename from contributed_definitions/NXcs_mm_sys.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml index d9c6779fd8..d57fa80c9f 100644 --- a/contributed_definitions/NXcs_mm_sys.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_config.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a main memory system of a computer. + Application definition for a configuration file of the paraprobe-selector tool. - - - How much physical memory does the system provide. - - - + + + + + + + + diff --git a/contributed_definitions/NXcs_io_sys.nxdl.xml b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml similarity index 52% rename from contributed_definitions/NXcs_io_sys.nxdl.xml rename to contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml index 5608c9f886..760d26b8b2 100644 --- a/contributed_definitions/NXcs_io_sys.nxdl.xml +++ b/contributed_definitions/NXapm_paraprobe_selector_results.nxdl.xml @@ -2,9 +2,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. + + + The total number of ions in the reconstruction. + + - Computer science description of system of a computer. + Application definition for a results file of the paraprobe-selector tool. - + + + + + + + + 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..34d3efc6f5 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_spatstat_config.nxdl.xml @@ -0,0 +1,259 @@ + + + + + + + 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. + + The tool paraprobe-spatstat evaluates spatial distribution functions. + + + + + + + + + + + + + + + + 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 of the histogram binning. + + + + + Increment of the histogram binning. + + + + + Maximum value of the histogram binning. + + + + + + Compute radial distribution function. + + + + Minimum value of the histogram binning. + + + + + Increment value of the histogram binning. + + + + + 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..094a3f9a82 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_spatstat_results.nxdl.xml @@ -0,0 +1,141 @@ + + + + + + + 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 a results file of the paraprobe-spatstat tool. + + The tool paraprobe-spatstat evaluates spatial distribution functions. + + + + + + + + + + + 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. + + + + + + + + + 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..cf9b4f66ef --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_config.nxdl.xml @@ -0,0 +1,151 @@ + + + + + + + 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. + + + + + + + + + + + + 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 *percolation* 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 *percolation* 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..42c1143938 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_surfacer_results.nxdl.xml @@ -0,0 +1,222 @@ + + + + + + + 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 a results file of the paraprobe-surfacer tool. + + + + + + + + + + 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). + + + + + + + + + + + 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..c6aa0c5549 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_config.nxdl.xml @@ -0,0 +1,93 @@ + + + + + + + Application definition for a configuration file of the paraprobe-tessellator tool. + + The tool paraprobe-tessellator computes a tessellation of the reconstructed positions. + + + + + + + + + + + + + + + + + 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..04604c08bb --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tessellator_results.nxdl.xml @@ -0,0 +1,277 @@ + + + + + + + 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 a results file of the paraprobe-tessellator tool. + + The tool paraprobe-tessellator computes a tessellation of the reconstructed positions. + + + + + + + + + + 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 closest + 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 indices_vertex 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. + + + + + + + + + + + + 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..eead897424 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_common.nxdl.xml @@ -0,0 +1,102 @@ + + + + + + Base class documenting organizational metadata used by all tools of the + paraprobe-toolbox. + + + + 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. + Simulation ID is an alias. + + + + + 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_reference_frame + * lab_reference_frame + * specimen_reference_frame + * laser_reference_frame + * instrument_reference_frame + * detector_reference_frame + * reconstruction_reference_frame + + 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..edd9849446 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_config.nxdl.xml @@ -0,0 +1,125 @@ + + + + + + Application definition for a (configuration) file of a tool from 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. + + + + + + + + A specific configuration to achieve a processing result + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml new file mode 100644 index 0000000000..7305242e88 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_parameters.nxdl.xml @@ -0,0 +1,114 @@ + + + + + + Base class documenting parameters for processing used by all tools of the + paraprobe-toolbox. + + + + Internal identifier used by the tool to refer to an analysis. + Simulation ID an alias. + + + + + 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 unknown_type iontype represents the null model of an ion + that has not been ranged (for whatever reasons) or is not rangeable. + 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_process.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml new file mode 100644 index 0000000000..a42c6f31fb --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_process.nxdl.xml @@ -0,0 +1,68 @@ + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of entries in the mask. + + + + + Base class documenting a processing step within a tool of the paraprobe-toolbox. + + + + 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_tool_results.nxdl.xml b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml new file mode 100644 index 0000000000..485397ea00 --- /dev/null +++ b/contributed_definitions/NXapm_paraprobe_tool_results.nxdl.xml @@ -0,0 +1,106 @@ + + + + + + Application definition for storing processing results of a tool from 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. + + + + + + + + A specific processing result + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + If used, metadata of at least the person who performed this analysis. + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXbeam_splitter.nxdl.xml b/contributed_definitions/NXbeam_splitter.nxdl.xml index 3043820693..636a33dc64 100644 --- a/contributed_definitions/NXbeam_splitter.nxdl.xml +++ b/contributed_definitions/NXbeam_splitter.nxdl.xml @@ -3,7 +3,7 @@ - - + + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the beam splitter material and/or coating is defined. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the beam splitter material and/or coating is defined. - Length of the spectrum vector (e.g. wavelength or energy) for which the - reflectance or transmission of the beam splitter is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + reflectance or transmission of the beam splitter is given. - Number of parameters needed do describe the shape of the beam splitter. + Number of parameters needed do describe the shape of the beam splitter. - Number of objects the beam splitter is made up of. + Number of objects the beam splitter is made up of. - Number of outputs, i.e. number of paths the beam takes after being split by - the beam splitter. + Number of outputs, i.e. number of paths the beam takes after being split by + the beam splitter. - A beam splitter, i.e. a device splitting the light into two or more beams. - - Information about types and properties of beam splitters is provided e.g. - [here](https://www.rp-photonics.com/beam_splitters.html). - - Use two or more NXbeam_paths to describe the beam paths after the beam - splitter. In the dependency chain of the new beam paths, the first elements - each point to this beam splitter, as this is the previous element. + A beam splitter, i.e. a device splitting the light into two or more beams. + + Information about types and properties of beam splitters is provided e.g. + [here](https://www.rp-photonics.com/beam_splitters.html). + + Use two or more instances of NXbeam to describe the beam paths after the beam + splitter. In the dependency chain of the new beam paths, the first elements + each point to this beam splitter, as this is the previous element. - Specify the beam splitter type (e.g. dielectric mirror, pellicle, - dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension - should be described in 'geometry'. Define if the beam splitter is - polarizing or not in the field 'polarizing(NX_BOOLEAN)'. + Specify the beam splitter type (e.g. dielectric mirror, pellicle, + dichroic mirror etc.). Shape (e.g. prism, plate, cube) and dimension + should be described in 'geometry'. Define if the beam splitter is + polarizing or not in the field 'polarizing(NX_BOOLEAN)'. @@ -79,35 +80,27 @@ - - - - - If you selected 'other' in 'type' use this field to specify which type of - beam splitter was used. - - - Is the beam splitter polarizing? + Is the beam splitter polarizing? - Does the beam splitter have multiple outputs (diffractive optical - element), i.e. more than two outputs? + Does the beam splitter have multiple outputs (diffractive optical + element), i.e. more than two outputs? - Describe the geometry (shape, dimension etc.) of the beam splitter. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). + Describe the geometry (shape, dimension etc.) of the beam splitter. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). - Describe the shape (plate, cube, wedged, prism etc.). + Describe the shape (plate, cube, wedged, prism etc.). @@ -128,34 +121,29 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - - - If you chose 'other' in 'shape' describe what it is. - - - Sketch of the beam splitter showing its geometry. The paths of the - incoming and split beam should be illustrated and labelled (0 for the - incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split - beam paths)). + Sketch of the beam splitter showing its geometry. The paths of the + incoming and split beam should be illustrated and labelled (0 for the + incoming beam, and 1, 2,..., N_outputs for the outputs (i.e. the split + beam paths)). - Physical extent of the beam splitter device. The beam splitter might be - made up of one or more objects (NX_objects). The meaning and location - of the axes used will vary according to the value of the 'shape' - variable. 'N_shapepar' defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + Physical extent of the beam splitter device. The beam splitter might be + made up of one or more objects (NX_objects). The meaning and location + of the axes used will vary according to the value of the 'shape' + variable. 'N_shapepar' defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. @@ -164,41 +152,41 @@ in 'substrate/substrate_thickness' and 'coating/coating_thickness'.--> - Wedge angle if 'shape' is 'wedged'. + Wedge angle if 'shape' is 'wedged'. +doc: | +Specify the length of the beam splitter. If the device has a wedged +shape provide the minimum and maximum length of the device. +Otherwise, if the beam splitter has a homogeneous thickness, the two +values are equal. +dimensions: +rank: 1 +dim: [[1,2]]--> - Beam splitting ratio(s) for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. + Beam splitting ratio(s) for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting with 1. @@ -206,30 +194,30 @@ length(NX_FLOAT): - Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of - length and height for square geometry). + Clear aperture of the device (e.g. 90% of diameter for a disc, or 90% of + length and height for square geometry). - Substrate of the beam splitter. Describe the material of the substrate in - substrate/substrate_material and provide its index of refraction in - substrate/index_of_refraction_substrate, if known. + Substrate of the beam splitter. Describe the material of the substrate in + substrate/substrate_material and provide its index of refraction in + substrate/index_of_refraction_substrate, if known. - Specify the material of the beam splitter. If the device has a coating - it should be described in coating/coating_material. Is the material - birefringent? + Specify the material of the beam splitter. If the device has a coating + it should be described in coating/coating_material. Is the material + birefringent? - Thickness of the beam splitter substrate. Define the minimum and - maximum thickness (for a wedged geometry). For a homogeneous thickness - (e.g. as in plate beam splitters) the minimum and maximum values are - equal. + Thickness of the beam splitter substrate. Define the minimum and + maximum thickness (for a wedged geometry). For a homogeneous thickness + (e.g. as in plate beam splitters) the minimum and maximum values are + equal. @@ -237,8 +225,8 @@ length(NX_FLOAT): - Complex index of refraction of the beam splitter substrate. Specify at - given spectral values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the beam splitter substrate. Specify at + given spectral values (e.g. wavelength, energy, wavenumber etc.). @@ -248,32 +236,32 @@ length(NX_FLOAT): - Is the beam splitter coated? If yes, specify the type and material of the - coating and the spectral range for which it is designed. If known, you - may also provide its index of refraction. For a beam splitter cube - consisting of two prisms which are glued together, you may want to - specify the the glue and the coatings of each prism. + Is the beam splitter coated? If yes, specify the type and material of the + coating and the spectral range for which it is designed. If known, you + may also provide its index of refraction. For a beam splitter cube + consisting of two prisms which are glued together, you may want to + specify the the glue and the coatings of each prism. - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - Specify the coating material. + Specify the coating material. - Thickness of the coating. + Thickness of the coating. - Wavelength range for which the coating is designed. Enter the minimum - and maximum values of the wavelength range. + Wavelength range for which the coating is designed. Enter the minimum + and maximum values of the wavelength range. @@ -281,8 +269,8 @@ length(NX_FLOAT): - Complex index of refraction of the coating. Specify at given spectral - values (e.g. wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (e.g. wavelength, energy, wavenumber etc.). @@ -292,10 +280,10 @@ length(NX_FLOAT): - Wavelength range for which the beam splitter is designed. Enter the - minimum and maximum values of the wavelength range. Alternatively, or - additionally, you may define the wavelength range for the coating in - coating/wavelength_range_coating. + Wavelength range for which the beam splitter is designed. Enter the + minimum and maximum values of the wavelength range. Alternatively, or + additionally, you may define the wavelength range for the coating in + coating/wavelength_range_coating. @@ -303,11 +291,11 @@ length(NX_FLOAT): - Optical loss of the beam splitter for the various outputs (i.e. the paths - of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Optical loss of the beam splitter for the various outputs (i.e. the paths + of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. @@ -315,20 +303,20 @@ length(NX_FLOAT): - Optimized angle of incidence for the desired splitting ratio. + Optimized angle of incidence for the desired splitting ratio. - Angle of deflection corresponding to the optimized angle of incidence - defined in incident_angle. + Angle of deflection corresponding to the optimized angle of incidence + defined in incident_angle. - + - Range of the angles of incidence (AOI) for which the beam splitter can be - operated. Specify the minimum and maximum angles of the range. + Range of the angles of incidence (AOI) for which the beam splitter can be + operated. Specify the minimum and maximum angles of the range. @@ -341,7 +329,7 @@ If this is the case for some devices, we might also have to define a field for the corresponding deflection angles...--> - Reflectance of the beam splitter at given spectral values. + Reflectance of the beam splitter at given spectral values. @@ -349,11 +337,11 @@ for the corresponding deflection angles...--> - Transmission at given spectral values for the various outputs (i.e. the - paths of the beam after being split by the beam splitter). - The order of the ratios must be consistent with the labels - 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting - with 1. + Transmission at given spectral values for the various outputs (i.e. the + paths of the beam after being split by the beam splitter). + The order of the ratios must be consistent with the labels + 1, 2, ... N_outputs defined by the sketch in 'SHAPE/sketch', starting + with 1. diff --git a/contributed_definitions/NXclustering.nxdl.xml b/contributed_definitions/NXclustering.nxdl.xml deleted file mode 100644 index 76351758dd..0000000000 --- a/contributed_definitions/NXclustering.nxdl.xml +++ /dev/null @@ -1,124 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of numeral labels per object. - - - - - Number of categorical labels per object. - - - - - Total number of clusters detected. - - - - - Metadata to the results of a clustering analysis. - - Clustering algorithms are routine tools to segment a set of objects/primitives - into groups, objects of different type. A plethora of algorithms have been - proposed for geometric primitives as objects, such as points, triangles, - or (abstract) objects. - - This base class considers metadata and results of one clustering - applied to a set in which objects are either categorized as noise - or belonging to a cluster, specifically here only one cluster. - - - - How many numeric labels does each object have. - - - - - How many categorical labels does each object have. - - - - - Reference to a set of objects investigated in a cluster analysis. - Objects must have clear integer identifier. - - - - - Reference to numeric attribute data for each object. - - - - - Reference to categorical attribute data for each object. - - - - - - 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 values to -1 and unassigned points to 0. - - - - - Total number of objects categorized as unassigned. - - - - - Total number of objects categorized as noise. - - - - - Total number of clusters (excluding noise and unassigned). - - - - - Number of objects associated to each cluster. The labels are implicit, - meaning the zeroth/first entry in the array belongs to the first cluster, - the second entry to the second cluster and so on and so forth. - The first cluster has the value of identifier_offset as its identifier. - The second cluster has identifier_offset + 1, and so on and so forth. - - - - - - - diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml deleted file mode 100644 index ce437ec7d6..0000000000 --- a/contributed_definitions/NXcoordinate_system_set.nxdl.xml +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - Base class to hold different coordinate systems and representation conversions. - - How many nodes of type :ref:`NXcoordinate_system_set` should be used in an application definition? - - * 0; if there is no instance of :ref:`NXcoordinate_system_set` and therein or elsewhere across - the application definition, an instance of NXcoordinate_system is defined, - the default NeXus `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ - coordinate system is assumed. This makes :ref:`NXcoordinate_system_set` and - NXcoordinate_system base classes backwards compatible to older - NeXus conventions and classes. - * 1; if only one :ref:`NXcoordinate_system_set` is defined, it should be placed - as high up in the node hierarchy (ideally right below an instance of NXentry) - of the application definition tree as possible. - This :ref:`NXcoordinate_system_set` should define at least one NXcoordinate_system - instance. This shall be named such that it is clear how this coordinate system is - typically referred to in a community. For the NeXus `McStas coordinate system, it is - advised to call it mcstas for the sake of improved clarity. - Additional NXcoordinate_system instances should be specified if possible in that same - :ref:`NXcoordinate_system_set` instead of cluttering them across the tree. - - If this is the case, it is assumed that the NXcoordinate_system_members - overwrite the NeXus default McStas coordinate system, i.e. users can thereby - conveniently and explicitly specify the coordinate system(s) that - they wish to use. - - Users are encouraged to write also explicit and clean depends_on fields in - all groups that encode information about where the interpretation of coordinate - systems is relevant. If these depends_on hints are not provided, it is - automatically assumed that all children (to arbitrary depth) - of that branch and sub-branches below the one in which that - :ref:`NXcoordinate_system_set` is defined use either the only NXcoordinate_system_set - instance in that set or the application definition is considered - underconstrained which should at all costs be avoided and in which case - again McStas is assumed. - * 2 and more; as soon as more than one :ref:`NXcoordinate_system_set` is specified - somewhere in the tree, different interpretations are possible as to which - of these coordinate system sets and instances apply or take preference. - We realize that such ambiguities should at all costs be avoided. - However, the opportunity for multiple sets and their instances enables to - have branch-specific coordinate system conventions which could especially - be useful for deep classes where multiple scientific methods are combined or - cases where having a definition of global translation and conversion tables - how to convert between representations in different coordinate systems - is not desired or available for now. - We argue that having 2 or more :ref:`NXcoordinate_system_set` instances and respective - NXcoordinate_system instances makes the interpretation eventually unnecessary - complicated. Instead, developers of application definitions should always try - to work for clarity and thus use only one top-level coordinate system set. - - For these reasons we conclude that the option with one top-level - :ref:`NXcoordinate_system_set` instance is the preferred choice. - - McStas is used if neither an instance of :ref:`NXcoordinate_system_set` nor an instance - of NXcoordinate_system is specified. However, even in this case it is better - to be explicit like for every other coordinate system definition to support - users with interpreting the content and logic behind every instance of the tree. - - How to store coordinate systems inside :ref:`NXcoordinate_system_set`? - Individual coordinate systems should be specified as members of the - :ref:`NXcoordinate_system_set` instance using instances of NXcoordinate_system. - - How many individual instances of NXcoordinate_system to allow within one - instance of :ref:`NXcoordinate_system_set`? - - * 0; This case should be avoided for the sake of clarity but this case could - mean the authors of the definition meant that McStas is used. We conclude, - McStas is used in this case. - * 1; Like above-mentioned this case has the advantage that it is explicit - and faces no ambiguities. However, in reality typically multiple - coordinate systems have to be mastered especially for complex - multi-signal modality experiments. - * 2 or more; If this case is realized, the best practice is that in every - case where a coordinate system should be referred to the respective class - has a depends_on field which resolves the possible ambiguities which specific - coordinate systems is referred to. The benefit of this explicit and clear - specifying of the coordinate system used in every case is that especially - in combination with having coordinate systems inside deeper branches - makes up for a very versatile, backwards compatible, but powerful system - to express different types of coordinate systems using NeXus. In the case - of two or more instances of NXcoordinate_system in one :ref:`NXcoordinate_system_set`, - it is also advised to specify the relationship between the two coordinate systems by - using the (NXtransformations) group within NXcoordinate_system. - - In effect, 1 should be the preferred choice. However, if more than one coordinate - system is defined for practical purposes, explicit depends_on fields should - always guide the user for each group and field which of the coordinate system - one refers to. - - - - Convention how a positive rotation angle is defined when viewing - from the end of the rotation unit vector towards its origin, - i.e. in accordance with convention 2 of - DOI: 10.1088/0965-0393/23/8/083501. - Counter_clockwise is equivalent to a right-handed choice. - Clockwise is equivalent to a left-handed choice. - - - - - - - - - How are rotations interpreted into an orientation - according to convention 3 of - DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - How are Euler angles interpreted given that there are several choices (e.g. zxz, xyz) - according to convention 4 of DOI: 10.1088/0965-0393/23/8/083501. - - The most frequently used convention is zxz, which is based on the work of H.-J. Bunge - but other conventions are possible. Apart from undefined, proper Euler angles - are distinguished from (improper) Tait-Bryan angles. - - - - - - - - - - - - - - - - - - - To which angular range is the rotation angle argument of an - axis-angle pair parameterization constrained according to - convention 5 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - Which sign convention is followed when converting orientations - between different parametrizations/representations according - to convention 6 of DOI: 10.1088/0965-0393/23/8/083501. - - - - - - - - - - - - Details about eventually relevant named directions that may give reasons for anisotropies. - The classical example is mechanical processing where one has to specify which directions - (e.g. rolling, transverse, and normal direction) align how with the direction of the base - vectors of the sample_reference_frame. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xp, Yp, Zp. - - - - - Details about the sample_reference_frame that is typically overlaid onto the surface of the sample. - - It is assumed that the configuration is inspected by looking towards the sample surface. - If a detector is involved, it is assumed that the configuration is inspected from a position - that is located behind this detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xs, Ys, Zs. - - - - - Details about the detector_reference_frame for a specific detector. - - Reference DOI: 10.1016/j.matchar.2016.04.008 suggest to label the - base vectors of this coordinate system as Xd, Yd, Zd. - - It is assumed that the configuration is inspected by looking towards the sample surface - from a position that is located behind the detector. - - If any of these assumptions is not met, the user is required to explicitly state this. - - - diff --git a/contributed_definitions/NXcs_gpu.nxdl.xml b/contributed_definitions/NXcs_gpu.nxdl.xml deleted file mode 100644 index 3392e41d39..0000000000 --- a/contributed_definitions/NXcs_gpu.nxdl.xml +++ /dev/null @@ -1,39 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a graphic processing unit (GPU) of a computer. - - - - Given name of the GPU. Users should be as specific as possible. - - - - diff --git a/contributed_definitions/NXcs_io_obj.nxdl.xml b/contributed_definitions/NXcs_io_obj.nxdl.xml deleted file mode 100644 index eb1e7e19c5..0000000000 --- a/contributed_definitions/NXcs_io_obj.nxdl.xml +++ /dev/null @@ -1,56 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Computer science description of a storage object in an input/output system. - - - - Qualifier for the type of storage medium used. - - - - - - - - - - - Total amount of data which the medium can hold. - - - - - - Given name to the I/O unit. - - - - diff --git a/contributed_definitions/NXdelocalization.nxdl.xml b/contributed_definitions/NXdelocalization.nxdl.xml index 2fa42210a7..a555db20f2 100644 --- a/contributed_definitions/NXdelocalization.nxdl.xml +++ b/contributed_definitions/NXdelocalization.nxdl.xml @@ -2,9 +2,9 @@ - + The symbols used in the schema to specify e.g. dimensions of arrays. @@ -41,31 +41,31 @@ 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 nuclide 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 hashing rule defined in :ref:`NXatom`. + + + + + + + + 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/NXdispersion.nxdl.xml b/contributed_definitions/NXdispersion.nxdl.xml index b581fb87c9..06d8152f6a 100644 --- a/contributed_definitions/NXdispersion.nxdl.xml +++ b/contributed_definitions/NXdispersion.nxdl.xml @@ -23,13 +23,13 @@ --> - A dispersion denoting a sum of different dispersions. - All NXdispersion_table and NXdispersion_function groups will be added together - to form a single dispersion. + A dispersion denoting a sum of different dispersions. + All NXdispersion_table and NXdispersion_function groups will be added together + to form a single dispersion. - The name of the composite model. + The name of the composite model. diff --git a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml index 3d1c92c98c..f4913ca7dd 100644 --- a/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_repeated_parameter.nxdl.xml @@ -25,30 +25,30 @@ - The number of parameter repetitions + The number of parameter repetitions - A repeated parameter for a dispersion function + A repeated parameter for a dispersion function - The name of the parameter + The name of the parameter - A description of what this parameter represents + A description of what this parameter represents - A unit array associating a unit with each parameter. - The first element should be equal to values/@unit. - The values should be SI interpretable standard units - with common prefixes (e.g. micro, nano etc.) or their - short-hand notation (e.g. nm, mm, kHz etc.). + A unit array associating a unit with each parameter. + The first element should be equal to values/@unit. + The values should be SI interpretable standard units + with common prefixes (e.g. mikro, nano etc.) or their + short-hand notation (e.g. nm, mm, kHz etc.). @@ -56,7 +56,7 @@ - The value of the parameter + The value of the parameter diff --git a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml index 59b38788a8..d5d6b4c40f 100644 --- a/contributed_definitions/NXdispersion_single_parameter.nxdl.xml +++ b/contributed_definitions/NXdispersion_single_parameter.nxdl.xml @@ -23,21 +23,21 @@ --> - A single parameter for a dispersion function + A single parameter for a dispersion function - The name of the parameter + The name of the parameter - A description of what this parameter represents + A description of what this parameter represents - The value of the parameter + The value of the parameter diff --git a/contributed_definitions/NXdispersion_table.nxdl.xml b/contributed_definitions/NXdispersion_table.nxdl.xml index f0a0851531..48897dc426 100644 --- a/contributed_definitions/NXdispersion_table.nxdl.xml +++ b/contributed_definitions/NXdispersion_table.nxdl.xml @@ -24,25 +24,25 @@ - The symbols in this schema to denote the dimensions + The symbols in this schema to denote the dimensions - The number of energy and dielectric function points + The number of energy and dielectric function points - A dispersion table denoting energy, dielectric function tabulated values. + A dispersion table denoting energy, dielectric function tabulated values. - The name of this dispersion model. + The name of this dispersion model. - The sign convention being used (n + or - ik) + The sign convention being used (n + or - ik) @@ -51,9 +51,9 @@ - The wavelength array of the tabulated dataset. - This is essentially a duplicate of the energy field. - There should be one or both of them present. + The wavelength array of the tabulated dataset. + This is essentially a duplicate of the energy field. + There should be one or both of them present. @@ -61,9 +61,9 @@ - The energy array of the tabulated dataset. - This is essentially a duplicate of the wavelength field. - There should be one or both of them present. + The energy array of the tabulated dataset. + This is essentially a duplicate of the wavelength field. + There should be one or both of them present. @@ -71,7 +71,7 @@ - The refractive index array of the tabulated dataset. + The refractive index array of the tabulated dataset. @@ -79,7 +79,7 @@ - The dielectric function of the tabulated dataset. + The dielectric function of the tabulated dataset. diff --git a/contributed_definitions/NXdispersive_material.nxdl.xml b/contributed_definitions/NXdispersive_material.nxdl.xml index eae5f4d05d..1726fc1449 100644 --- a/contributed_definitions/NXdispersive_material.nxdl.xml +++ b/contributed_definitions/NXdispersive_material.nxdl.xml @@ -23,103 +23,90 @@ --> - NXdispersion + An application definition for describing a dispersive material. - - An application definition for a dispersive material. - - Version number to identify which definition of this application definition was - used for this entry/data. + Version number to identify which definition of this application definition was + used for this entry/data. - + - URL where to find further material (documentation, examples) relevant to the - application definition + URL where to find further material (documentation, examples) relevant to the + application definition - - Name of the program used for creating this dispersion - - - Version of the program used - - - Date and time of creating this dispersion. - - 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`. + 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 colloquial name of the material, e.g. graphite or diamond for carbon. + The colloquial name of the material, e.g. graphite or diamond for carbon. - The phase of the material + The phase of the material - + - - Additional information about the phase if the - material phase is other. + Additional information about the phase if the + material phase is not from the enumerated list. - This field may be used to denote additional phase information, - such as crystalline phase of a crystal (e.g. 4H or 6H for SiC) or - if a measurement was done on a thin film or bulk material. + This field may be used to denote additional phase information, + such as crystalline phase of a crystal (e.g. 4H or 6H for SiC) or + if a measurement was done on a thin film or bulk material. - Denotes whether the dispersion is calculated or derived from an experiment + Denotes whether the dispersion is calculated or derived from an experiment - + - A text description of this reference, e.g. - `E. Example et al, The mighty example, An example journal 50 (2023), 100` + A text description of this reference, e.g. + `E. Example et al, The mighty example, An example journal 50 (2023), 100` - The dispersion along the optical axis of the material. - This should be the only dispersion available for isotropic materials. - For uniaxial materials this denotes the ordinary axis. - For biaxial materials this denotes the x axis or epsilon 11 tensor element - of the diagionalized permittivity tensor. + The dispersion along the optical axis of the material. + This should be the only dispersion available for isotropic materials. + For uniaxial materials this denotes the ordinary axis. + For biaxial materials this denotes the x axis or epsilon 11 tensor element + of the diagonalized permittivity tensor. @@ -155,13 +142,13 @@ - This should only be filled for biaxial materials. - It denotes the epsilon 22 direction of the diagionalized - permittivity tensor. + This should only be filled for biaxial materials. + It denotes the epsilon 22 direction of the diagonalized + permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -193,14 +180,14 @@ - This should only be filled for uniaxial or biaxial materials. - For uniaxial materials this denotes the extraordinary axis. - For biaxial materials this denotes the epsilon 33 tensor element - of the diagionalized permittivity tensor. + This should only be filled for uniaxial or biaxial materials. + For uniaxial materials this denotes the extraordinary axis. + For biaxial materials this denotes the epsilon 33 tensor element + of the diagonalized permittivity tensor. - The name of this dispersion model. + The name of this dispersion model. @@ -231,4 +218,4 @@ - + \ No newline at end of file diff --git a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml index 039fa24e78..c36c4a2c21 100644 --- a/contributed_definitions/NXelectrostatic_kicker.nxdl.xml +++ b/contributed_definitions/NXelectrostatic_kicker.nxdl.xml @@ -26,35 +26,35 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > -definition for a electrostatic kicker. +Base class for an electrostatic kicker. -extended description of the kicker. +Extended description of the kicker. -define position of beamline element relative to production target +Define position of beamline element relative to production target -kicker timing as defined by ``description`` attribute +Kicker timing as defined by ``description`` attribute -current set on supply. +Current set on supply. -current read from supply. +Current read from supply. -voltage set on supply. +Voltage set on supply. -voltage read from supply. +Voltage read from supply. diff --git a/contributed_definitions/NXem_calorimetry.nxdl.xml b/contributed_definitions/NXem_calorimetry.nxdl.xml new file mode 100644 index 0000000000..ad838cb623 --- /dev/null +++ b/contributed_definitions/NXem_calorimetry.nxdl.xml @@ -0,0 +1,297 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of diffraction pattern. + + + + + Number of radial integration bins. + + + + + Number of coordinates along i axis. + + + + + Number of coordinates along j axis. + + + + + Application definition for minimal example in-situ calorimetry. + + TODO: + + * What is the technique about. + * General context. + * Literature references. + + + + + + + + + + + Details about performance, profiling, etc. + + + + + + + + Name of the program whereby this config file was created. + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + + + Qualifier whether the sample is a real (in which case is_simulation should be set to false) + or a virtual one (in which case is_simulation should be set to true). + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from the resources. + + + + + + + + + Reference to the resource which stores acquired pattern from the + experiment or simulation that are analyzed in this workflow. + + 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. + + + + + + + + Configuration file that was used for parametrizing this analysis workflow. + + + + + + + + Assumptions and computations whereby timestamping data from + the detector and actuator (e.g. heating chip) were synchronized. + + + + + ISO8601 with local time zone reference timestamp that tells + with which delta_time can be converted in timestamp. + The reference timestamp is defined as the time when the + actuator started acting on the sample. + + Time differences to this timestamp when correlated signals such + as diffraction pattern matching with a specific state of the sample + (e.g. obtained temperature via the actuator) are reported through + delta_time. + + + + + + + + + + Time difference to start_time. + + Collecting diffraction pattern also takes some time. + It is assumed that the acquisition time for each pattern is + substantial shorter than the time it takes the actuator to + cause a change in stimulus (e.g. temperature). + + + + + + + + + + Computation of the center for each pattern using e.g. a Circular Hough + Transformation. + + + + + + Computed center for each pattern. + + + + + + + + + + + Elliptical distortion correction as a step when computing the center for + patterns. + + + + + + Computed center for each pattern. + + + + + + + + + + + Integrated diffraction pattern intensity as a function of radial distance from the center + azimuthally integrated as a function of time. + + + + + + The integrated intensities: + + * result_with_background + * result_without_background + + + + + + + + Integrated intensity as a function of time and the radial distance from the + pattern center. + + + + + + + + + + Identifier for each pattern. + + + + + + + + + Positions in reciprocal space. + + + + + + + + + + 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 deleted file mode 100644 index 69440ae0c4..0000000000 --- a/contributed_definitions/NXgraph_edge_set.nxdl.xml +++ /dev/null @@ -1,113 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The number of edges. - - - - - A set of (eventually directed) edges which connect nodes/vertices of a graph. - - - - Total number of edges, counting eventual bidirectional edges only once. - - - - - 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. - - 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. - - - - - Integer used to distinguish edges for explicit indexing. - - - - - - - - Specifier whether each edge is non-directional, one-directional, - or bidirectional. Use the smallest available binary representation - which can store three different states: - - * 0 / state 0x00 is non-directional - * 1 / state 0x01 is one-directional - * 2 / state 0x02 is bi-directional - - - - - - - - Pairs of node/vertex identifier. Each pair represents the connection - between two nodes. - - In the case that the edge is non- or bi-directional - node identifier should be stored 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. - - - - - - - - - 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. - - - - - - diff --git a/contributed_definitions/NXgraph_node_set.nxdl.xml b/contributed_definitions/NXgraph_node_set.nxdl.xml deleted file mode 100644 index 9b98765d21..0000000000 --- a/contributed_definitions/NXgraph_node_set.nxdl.xml +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - - 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/vertices of the graph. - - - - - A set of nodes/vertices in space representing members of a 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. - - 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. - - - - - Integer used to distinguish nodes for explicit indexing. - - - - - - - - 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. - - - - - - - - A human-readable label/caption/tag of the graph. - - - - - - - diff --git a/contributed_definitions/NXgraph_root.nxdl.xml b/contributed_definitions/NXgraph_root.nxdl.xml deleted file mode 100644 index 0e41c38d4f..0000000000 --- a/contributed_definitions/NXgraph_root.nxdl.xml +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - An instance of a graph. - - - - - diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml deleted file mode 100644 index 0874421ece..0000000000 --- a/contributed_definitions/NXion.nxdl.xml +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - - 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. - - - - - Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. - - - - 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. - - - - - A vector of isotope hash values. - These values have to be stored in an array, sorted in decreasing order. - The array is filled with zero hash values indicating unused places. - The individual hash values are built with the following hash function: - - The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` - the number of protons and :math:`N` the number of neutrons - of each isotope respectively. - - Z and N have to be 8-bit unsigned integers. - For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ - - - - - - - - - A supplementary row vector which decodes the isotope_vector into - a human-readable matrix of nuclides with the following formatting: - - The first row specifies the isotope mass number, i.e. using the hashvalues - from the isotope_vector this is :math:`Z + N`. As an example for a - carbon-14 isotope the number is 14. - The second row specifies the number of protons :math:`Z`, e.g. 6 for the - carbon-14 example. This row matrix is thus a mapping the notation of - using superscribed isotope mass and subscripted number of protons to - identify isotopes. - Unused places filling up to n_ivecmax need to be filled with zero. - - - - - - - - - Color code used for visualizing such ions. - - - - - 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 in range files and will - be used when building a tomographic reconstruction of an atom probe - dataset. - - - - - Charge of the ion. - - - - - Signed charge state of the ion in multiples of electron charge. - - Only positive values will be measured in atom probe microscopy 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 range file formats like RNG, RRNG for atom probe data. - These file formats do not document the charge state explicitly. - They report the number of atoms of each element per molecular ion - surplus the mass-to-charge-state-ratio interval. - With this it is possible to recover the charge state only for - specific molecular ions as the accumulated mass of the molecular ion - is defined by the isotopes, which without knowing the charge leads - to an underconstrained problem. - Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ - - - - - Human-readable ion type name (e.g. Al +++) - The string should consists of ASCII UTF-8 characters, - ideally using LaTeX notation to specify the isotopes, ions, and charge - state. Examples are 12C + or Al +++. - Although this name may be human-readable and intuitive, parsing such - names becomes impractical for more complicated cases. Therefore, for the - field of atom probe microscopy the isotope_vector should be the - preferred machine-readable format to use. - - - - - Associated lower (mqmin) and upper (mqmax) bounds of - mass-to-charge-state ratio interval(s) [mqmin, mqmax] - (boundaries included) for which the respective ion is one to be labelled - with ion_identifier. The field is primarily of interest to document the - result of indexing a ToF/mass spectrum. - - - - - - - - diff --git a/contributed_definitions/NXisocontour.nxdl.xml b/contributed_definitions/NXisocontour.nxdl.xml index 8c4361d279..eace731923 100644 --- a/contributed_definitions/NXisocontour.nxdl.xml +++ b/contributed_definitions/NXisocontour.nxdl.xml @@ -2,9 +2,9 @@ - + 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 Marching Cubes and others are frequently + used to segment d-dimensional regions at crossings of a threshold value, + the so-called isovalue. - 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. + In Computational Materials Science phase-field methods are frequently used. + Phase-field variables are discretized frequently using regular grids. - 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. + 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_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 deleted file mode 100644 index 798424f5d4..0000000000 --- a/contributed_definitions/NXlab_electro_chemo_mechanical_preparation.nxdl.xml +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Grinding and polishing of a sample using abrasives in a wet lab. - Manual procedures, electro-chemical, vibropolishing. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - A preparation step performed by a human or a robot/automated system. - - - - - - - - Carrier/plate used on which the abrasive/(lubricant) mixture was applied. - - - - - - Medium on the ``abrasive_medium_carrier`` (cloth or grinding plate) - whereby material is removed. - - - - - - Lubricant - - - - - - Qualitative statement how the revelation of the machine was configured. - If the rotation was controlled manually, e.g. by turning knobs - choose manual and estimate the nominal average rotation. - If the rotation was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal rotation. - If programmed use rotation_history (e.g. for automated/robot systems). - - - - - - - - - - - Qualitative statement how the (piston) force with which the sample - was pressed into/against the abrasive medium was controlled if at all. - If the force was controlled manually e.g. by turning knobs - choose manual and estimate nominal average force. - If the force was controlled via choosing from a fixed set - of options offered by the machine choose fixed and - specify the nominal force. - If programmed use force_history (e.g. for automated/robot systems). - - - - - - - - - - - Qualitative statement for how long (assuming regular uninterrupted) - preparation at the specified conditions the preparation step was - applied. - - - - - - - - - - - Turns per unit time. - - - - - - Force exerted on the sample to press it into the abrasive. - - - - - - Seconds - - - - - Qualitative statement how the material removal was characterized. - - - - - - - - - - How thick a layer was removed. - - - - - - - A preparation step performed by a human or a robot/automated system - with the aim to remove residual abrasive medium from the specimen surface. - - - - - diff --git a/contributed_definitions/NXlab_sample_mounting.nxdl.xml b/contributed_definitions/NXlab_sample_mounting.nxdl.xml deleted file mode 100644 index 56459ac3e9..0000000000 --- a/contributed_definitions/NXlab_sample_mounting.nxdl.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Embedding of a sample in a medium for easing processability. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - - - - - - Qualitative statement how the sample was mounted. - - - - - - - - - Type of material. - - - - - - - - - Electrical conductivity of the embedding medium. - - - - - diff --git a/contributed_definitions/NXmagnetic_kicker.nxdl.xml b/contributed_definitions/NXmagnetic_kicker.nxdl.xml index 1ce3aec0bf..89a610d08b 100644 --- a/contributed_definitions/NXmagnetic_kicker.nxdl.xml +++ b/contributed_definitions/NXmagnetic_kicker.nxdl.xml @@ -26,32 +26,32 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a magnetic kicker. + Base class for a magnetic kicker. - extended description of the kicker. + Extended description of the kicker. - define position of beamline element relative to production target + Define position of beamline element relative to production target - kicker timing as defined by ``description`` attribute + Kicker timing as defined by ``description`` attribute - current set on supply. + Current set on supply. - current read from supply. + Current read from supply. - voltage set on supply. + Voltage set on supply. - voltage read from supply. + Voltage read from supply. diff --git a/contributed_definitions/NXmatch_filter.nxdl.xml b/contributed_definitions/NXmatch_filter.nxdl.xml index 482b028d97..757e61c02d 100644 --- a/contributed_definitions/NXmatch_filter.nxdl.xml +++ b/contributed_definitions/NXmatch_filter.nxdl.xml @@ -2,9 +2,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - How many different match values does the filter specify. + How many different match values does the filter specify. - 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: - Whitelist specifies which entries with said value to include. - Entries with all other values will be filtered out. - - Blacklist specifies which entries with said value to exclude. - Entries with all other values will be included. + Definition of the logic what the filter yields: + + * Whitelist specifies which entries with said value to include. + 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..e5059f1926 --- /dev/null +++ b/contributed_definitions/NXmicrostructure.nxdl.xml @@ -0,0 +1,886 @@ + + + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + The number of crystals or their projections + + + + + The number of interfaces or their projections + + + + + The number of triple junctions or their projections + + + + + The number of quadruple junctions or their projections + + + + + + 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. The base class here can be used to describe + the structural aspect of a region-of-interest for a specimen that was investigated or a computer + simulation that was performed for a virtual specimen. + + Specimens experience thermo-chemo-mechanical processing (steps) before characterization. Therefore, + the characterized microstructure may not turn out to be 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 characterize only a two-dimensional representation + (projection) of the characterized material volume. 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 and technical surplus practical limitations. + + The term microstructural feature covers here crystals and all sorts of crystal defects within the material + (interfaces, triple junctions, dislocations, pores, etc.). + A key challenge with the description of representations and properties of such microstructural features is that + they can be represented and view as features with different dimensionality. Furthermore, combinations of features of + different dimensionality are frequently expected to be documented with intuitive naming conventions when + flat property lists are used. 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. + + For crystals the number of typically used technical terms are smaller than for interfaces or line like defects and + junctions of different types of crystal defects. The term grain describes a contiguous region of material that is + delineated by interfaces (phase or grain boundaries). With its origin motivated by light optical microscopy though + a grain is not necessarily a single crystal but can have an internal structure of defect such as dislocations. + In this base class we use the term and respective group crystals though for single crystals and grains. + The reason why this is possible is that when e.g. materials engineers talk about grains they inherently assume + that the internal structure of these grains can be described with homogenized effective properties. + If alternatively the individual structural crystalline or features of this grain should be distinguished + it is useful to instantiate these as individual instances of crystals. + + Grain boundaries and phase boundaries are two main categories of interfaces. + A grain boundary delineates two regions with similar crystal structure and phase but different orientation. + A grain boundary is thus a homophase interface. By contrast, a heterophase boundary delineates two regions with typically + but not necessarily dissimilar crystal structure but a different atomic occupation that justifies to distinguish two + phases. There is a substantial variety of interfaces whose distinction was classically based on geometrical arguments + but considers that atomic segregation is an equally important structural aspect to consider when classifying grain + boundaries. A concise overview on theoretical aspect of and the semantics for characterizing interfaces and their properties + is provided in e.g. `W. Bollmann <https://doi.org/10.1007/978-3-642-49173-3>`_ and A. Sutton and R. W. Baluffi, + Interfaces in Crystalline Materials, Clarendon Press, ISBN 9780198500612. + + Also for junctions between crystal defects there is a considerable variety of terms. Junctions are features in + three-dimensional Euclidean space even if they are formed maybe only through a monolayer or a pearl chain of atoms. + Either way their local atomic and electronic environment is different compared to the situation of an ideal crystal, + or the adjoining defects, which gives typically rise to a plethora of configurations of which some yield useful material + properties or affect material 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 line or a triple point as the projection of a line. Therefore, different representations can + be used to describe the location, shape, and structure of such defect. + + This base class provides definitions for crystals, grains, interfaces, triple junctions, and quadruple junctions thus covering, + volumetric, patch, line, and point like features that can serve as examples for future extension. + + 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 exist dislocation-line- + triple-line junctions, likewise dislocations form own junctions. + + The description 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 in 1970 to categorize features based on their dimensionality. + + Indices can be defined either implicitly or explicitly. Indices for implicit indexing are defined + on the interval :math:`[index\_offset, index\_offset + cardinality - 1]`. Indices can be used as identifiers + for distinguishing instances, i.e. indices are equivalent to instance names of individual crystals. + + + + + 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. + + + + + + + + + + + + + + + The chemical composition of this microstructure (region). + + + + + Different (thermodynamic) phases can be distinguished for the region-of- + interest. + + + + First identifier whereby to identify phases implicitly. + + + + + + + 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` for a one- or two-dimensional representation as only a projection is available (like in linear intercept analysis) + * :ref:`NXcg_polygon`, :ref:`NXcg_triangle`, or :ref:`NXcg_polyhedron` for a two- or three-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) + + 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. + + + + + + + + Identifier whereby to identify phase for each crystal explicitly. + + + + + + + + + True, if the feature makes contact with the edge of the ROI. + False, if the feature does not make 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 + + + + + + + + Possibility to store the mean orientation of the grain. + + + + + + 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. + + Interfaces are typically reported as discretized features. For interface projections on the 2D plane + these are most frequently polyline segments. For interface patches in 3D these are most frequently + triangulations. Descriptions with continuous functions are seldom used unless simplified configurations + are studied in modeling and theoretical studies. + + When using discretizations the individual interface segments need to be distinguished from the interfaces + themselves. Consequently, there are two sets of indices. + + + + Reference to an instance of: + + * :ref:`NXcg_point` for a one-dimensional representation as only a projection is available (as in linear intercept analyses) + * :ref:`NXcg_polyline` or :ref:`NXcg_polygon` for a two-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) 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. + + An array with as many entries as interfaces or their projections. + + + + + + + + + Set of pairs of indices_crystal values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + Set of pairs of indices_phase values, for each interface one value pair. + + An array with as many pairs as interfaces or their projections. + + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + + Interfaces can be the physical three-dimensional surfaces or two- or one-dimensional + projections. The latter situation applies typically for characterization with electron + microscopy. + + In the case of a two-dimensional projection interfaces are interface traces. These have + two terminating junctions. In three dimensions though the interface is a surface patch + that is bounded by multiple triple lines. + + Number of triple_junctions adjoining each interface. This array resolves the number of + values along the second dimension for the field indices_triple_junctions. + + + + + + + + Set of pairs of indices_triple_junction for each interface. + + An array with as many tuples of pairs to describe + all junctions about all interfaces. + + + + + + + The specific identifiers whereby to resolve ambiguities. + + + + + + + True, if the interface makes contact with the edge of the ROI. + False, if the interface does not make 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` for a one-dimensional representation as only a projection is available (like in most experiments) + * :ref:`NXcg_polyline` for a two-dimensional representation as only a projection is available + * :ref:`NXcg_polygon` 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` 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 indices_polyline whereby to resolve ambiguities. + + + + + + + True, if the triple line makes contact with the edge of the ROI. + False, if the triple line does not make 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 about each triple junction. + + Respective cut-off criteria need to be specified. + + + + + + + + + Quadruple junctions as a region where four crystals meet. + + An example for a point (like) defect. + + Thermodynamically such junctions can be unstable. + Specifically when discretizations are used in simulations + that do not address the thermodynamics of and splitting characteristics + of junctions in cases when more than four crystals meet, it is possible + that so-called higher-order junctions are observed. + + + + Reference to an instance of: + + * :ref:`NXcg_point` + * :ref:`NXcg_grid` for regularly pixelated (in 1D, 2D) or voxelated representations (in 3D) using (boolean) masks + + which represent the geometrical entities of the discretization. + + + + + 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, if the junction makes contact with the edge of the ROI. + True, if the junction does not make 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/NXcs_cpu.nxdl.xml b/contributed_definitions/NXmicrostructure_feature.nxdl.xml similarity index 63% rename from contributed_definitions/NXcs_cpu.nxdl.xml rename to contributed_definitions/NXmicrostructure_feature.nxdl.xml index b27b87481d..0a341174c2 100644 --- a/contributed_definitions/NXcs_cpu.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_feature.nxdl.xml @@ -2,9 +2,9 @@ - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - + - Computer science description of a central processing unit (CPU) of a computer. + Base class for documenting structuring features of a microstructure. + + Instances of the class enable sub-grouping of microstructural features + as the abstract base class NXobject should not be used for this purpose. - + - Given name of the CPU. Users should be as specific as possible. + The chemical composition of this microstructural feature + or set of such features. - - + diff --git a/contributed_definitions/NXmicrostructure_ipf.nxdl.xml b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml new file mode 100644 index 0000000000..59ae193e3d --- /dev/null +++ b/contributed_definitions/NXmicrostructure_ipf.nxdl.xml @@ -0,0 +1,245 @@ + + + + + + + + Number of pixel along the slow direction used for the IPF color key. + + + + + Number of pixel along the fast direction used for the IPF color key. + + + + + Number of pixel along the slowest direction, typically labeled z or k. + + + + + Number of pixel along the slow direction, typically labeled y or j. + + + + + Number of pixel along the fast direction, typically labeled x or i. + + + + + 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 instance of :ref:`NXcoordinate_system` in which the axes axis_z, + axis_y, and axis_x are defined. + + + + + The algorithm whereby orientations are colored. + + + + + + + + + The direction normal vector along which orientations are projected. + + + + + + + Reference to an instance of :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. + + + + + + Details about the original grid, i.e. 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. + + Instances named phase0 should by definition refer to the null phase notIndexed. + Inspect the definition of :ref:`NXphase` and its field phase_id + 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). + + + + Inverse pole figure color code for each map coordinate. + + Different types of AXISNAME dimensional scale axes are found in practice. A few examples: + + * No scaling, e.g. pixel position values like 0, 1, 2, 3 pixel. + Pixels on the map can be distinguished but that map is disconnected from + any sample surface context and eventually physical scaling + * Scaling but no offset, e.g. calibrated pixel position 0., 0.5, 1.0, 1.5 micron. + Pixels on the map can be compared for their distance to obtain e.g. size of features + but the position of the map relative to the e.g. the sample surface is unclear. + For IPF maps this is the most frequently reported situation. + * Scaling and offset, which resolves also the absolute position of the map in + relation to the sample surface. This is useful information for stitching multiple + mappings together and other processing where precise and accurate + position data are relevant e.g. for correlative materials characterization. + + Three types of dimensional constraints for maps are possible: + + * (n_x, 3), a one-dimensional map, + typically used for coarse sampling and crystal size statistics. + * (n_y, n_x, 3), a two-dimensional map, + the most frequently found reported + * (n_z, n_y, n_x, 3), a three-dimensional map, + these are commonly generated using computational methods, + or in cases multiple EBSD maps have been stitched/reconstructed + into a three-dimensional map. + + + + + + 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 color 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. + + + + + + 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..40dc06c9f8 --- /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 barycenter coordinate along z direction. + + + + + + + Coordinate along z direction. + + + + + + Material point barycenter coordinate along y direction. + + + + + + + Coordinate along y direction. + + + + + + Material point barycenter 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..a9c13a13b3 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_mtex_config.nxdl.xml @@ -0,0 +1,325 @@ + + + + + + + + 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. + + + + MTex 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 + + + + + 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..0d795855b6 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_odf.nxdl.xml @@ -0,0 +1,230 @@ + + + + + + + + Number of pixel per varphi section plot along the :math:`\varphi_2` slow + 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_1` fastest + 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 for a rough classification of an ODF. + + + + The texture index :math:`t = \int_{\mathcal{SO(3)}} f(R)^{2}dR` with :math:`f(R)`, denoting the ODF + is evaluated in orientation space :math:`\mathcal{SO(3)}`. + + The higher it is the texture index the sharper it is the ODF. + + + + + + + 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 decreasing 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 :math:`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 the orientation space is a distorted space when it using an Euler angle parameterization. + 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..3c8285419c --- /dev/null +++ b/contributed_definitions/NXmicrostructure_pf.nxdl.xml @@ -0,0 +1,113 @@ + + + + + + + + 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 following the notation of the International Table of Crystallography. + + + + + Point group of assumed sample symmetries following the + notation of the International Table of Crystallography. + + + + + + Halfwidth of the kernel. + + + + + Miller (:math:`(hkl)[uvw]`) or Miller-Bravais indices used 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..32a66a1f79 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_score_config.nxdl.xml @@ -0,0 +1,724 @@ + + + + + + + + Number of Bunge-Euler angle triplets for deformed grains. + + + + + Number of Bunge-Euler angle triplets for recrystallization nuclei. + + + + + Number of texture components to analyze. + + + + + Number of support points for the linearized drag profile. + + + + + Number of support 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. + + + + + Dimensionality of the simulation. + + + + + 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>`_ + + + + + + + + + + An alias to refer to this simulation. + + + + + Discouraged free-text field to add further details to the computation. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the configuration file was created. + + + + + + + + + Dimensionality of the simulation. + + + + + + + + + + A qualifier whether the sample is a real one or a virtual one. + + + + + + + + + List of comma-separated elements from the periodic table that are + contained in the specimen. If the specimen substance has multiple + components, all elements from each component must be included in + `atom_types`. + + The purpose of the field is to offer research data management systems an + opportunity to parse the relevant elements without having to interpret + these from other sources. + + + + + + Name of the program whereby this config file was created. + + + + + + + + Programs and libraries representing the computational environment + + + + + + + + + + (Mechanical) properties of the material which scale the + amount of stored (elastic) energy in the system and + thus mainly affect recrystallization kinetics. + + + + Reference shear modulus at zero Kelvin. + + + + + Magnitude of the Burgers vector at zero Kelvin. + + + + + + Melting temperature + + + + + + Details about the geometry and properties of the polycrystal that represents the + starting configuration (typically a deformed microstructure) for the simulation. + + + + Which model should be used to generate a starting microstructure. + + * cuboidal, a regular array of equally-shaped cuboidal grains + * poisson_voronoi, a discretized Poisson Voronoi tessellation + * ebsd, a microstructure synthesized based on a simulated or a measured EBSD orientation map + * damask, the result of a simulation from `DAMASK <https://damask-multiphysics.org>`_. + + + + + + + + + + + + Extent of each deformed grain in voxel along the + x, y, and z direction when model is cuboidal. + + + + + + + + Average spherical diameter when model is poisson_voronoi. + + + + + Settings for instantiating properties of deformed grains when model is cuboidal + or poisson. + + + + Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + out of which the orientations of deformed grains are sampled. + + + + + + + + + Set of stored elastic energy quantified as a dislocation density which is assigned + to deformed grains with orientations from bunge_euler with index queries matching + for the bunge_euler and stored_energy fields. + + + + + + + + + Settings for instantiating properties of deformed grains from an + EBSD orientation map when model is cuboidal or poisson. + + + + + + + Extent of the pixel of the EBSD orientation mapping assuming square-shaped pixels + or cube-shaped voxels respectively. + + + + + + + + + Settings for instantiating properties of deformed grains and nuclei when model + is damask. + + + + Name of the DREAM.3D HDF5 file that was instantiated from the + a previously performed DAMASK simulation. + + + + + + + + + Phenomenological model according to which recrystallization nuclei + are placed into the domain. Studying the growth of these nuclei + is the main purpose of a SCORE simulation. + + + + 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: + + * site_saturation, instantaneously + + + + + + + + According to which model will the nuclei get their orientation assigned: + + * ensemble, picking randomly one from ensemble/bunge_euler + * random, picking randomly on the SO3 + * damask, picking based on information provided in deformation/damask + + + + + + + + + + + Settings for instantiating properties of nuclei for recrystallizing grains. + + + + Set of Bunge-Euler orientations (:math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` ) + out of which the orientations of nuclei/recrystallized grains are sampled. + + + + + + + + + Incubation time which is assigned to deformed grains with orientations from bunge_euler + with index queries matching for the bunge_euler and stored_energy fields. + + + + + + + + + + Model for the assumed mobility of grain boundaries with different disorientation + implemented as a parameterized Turnbull's model for thermally-activated + grain boundary 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. + + + + + 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 high-angle grain boundaries which in + bicrystal or other tailored experiments showed a particular high + mobility. + + + + + Migration activation enthalpy for high-angle grain boundaries which in + bicrystal or other tailored experiments showed a particular high + mobility. + + + + + + Parameter of the Rollett-Holm migration model. + + + + + Pre-exponential factor for the fastest grain boundary in the system. + + + + + Migration activation enthalpy for the fastest grain boundary in the system. + + + + + Mobility scaling factor :math:`c_1`. Typically 0.99 or higher but not 1. + + + + + Mobility scaling factor :math:`c_2`. Typically 5. + + + + + Mobility scaling factor :math:`c_3`. Typically 9. + + + + + + + Time-dependent reduction of the stored energy to account for recovery effects. + + + + 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 + while the boundary is arrested at the dispersoids. + + + + Which type of drag model. + + + + + + + + + + Parameter of the Zener-Smith drag model when model is zener_smith. + + + + Configuration-dependent constant which factorizes the drag pressure. + + + + + Average surface energy of the grain-boundary-dispersoid-surface configuration + which factorizes the drag pressure. + + + + + + Assumed dispersoid mean radius-time profile + + + + + + + + + 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. + + + + + + + + + + + + + Given name of a texture component. + + + + + + + + Bunge-Euler angle representation :math:`\varphi_1`, :math:`\Phi`, :math:`\varphi_2` of the + of texture components in sequence of the name field. + + + + + + + + + Integration radius that constraints the theta angular region of the orientation space (SO3) + about each central location (obeying symmetries) as specified by bunge_euler indexed in + the same sequence as the bunge_euler and name fields. + + + + + + + + + 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. + + + + + + + + + + Relevant data to instantiate a starting configuration that is typically + a microstructure in deformed conditions where (elastic) energy is stored + in the form of crystal defects (mostly dislocations). The SCORE model + does not resolve individual dislocations but works with one + homogenized mean-field density per grain. For simulations that are + instantiated from EBSD datasets or crystal plasticity simulations + individual values are available for each voxel that may be used as is + for each voxel or may need a pre-processing of the data to coarse-grain + material point-specific values to values averaged per deformed grain. + + + + + 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. + + + + + + + + Edge length of the material point that in SCORE + is discretized via equisized cubic voxels. + + + + + + + + Criteria which enable to stop the simulation in a controlled manner + and assure a stable numerical integration. + Whichever criterion is fulfilled first stops the simulation. + + + + Maximum recrystallized volume fraction. + + + + + Maximum simulated physical time. + + + + + Maximum number of iteration steps. + + + + + 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. + + + + + List of target values at which recrystallized volume fractions the state + of the CA is evaluated and stored. The code documents summary statistics + like recrystallized volume fraction for each iteration and the volume of each + grain. Furthermore, snapshots of the microstructure are stored. + These can take much disk space though because SCORE is able to evolve CA + with up to :math:`1600^3` cells. Snapshot data document the current microstructure + including the assignment of grains and cells surplus the state of the + recrystallization front. + + Despite these, data about the cells that define the recrystallization front make up + for approximately one order of magnitude less cells than present in the domain. + For the cells in this front, though, more data have to be collected + than just a grain identifier. + + + + + + + + Parameter which control the memory management + of cells in the recrystallization front. + + + + Fraction of the total number of cells in the CA which + should initially be allocated for offering storage for + cells making up 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 or not. + + + + + Target values at which recrystallized volume fraction the cache + for cells in the recrystallization front will be defragmented + on-the-fly. Defragmentation packs active cells closer into + main memory to reduce cache misses in subsequent evaluations + of the recrystallization front. + + + + + + + + + + + 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. + + + + + diff --git a/contributed_definitions/NXmicrostructure_score_results.nxdl.xml b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml new file mode 100644 index 0000000000..f9f6c8b864 --- /dev/null +++ b/contributed_definitions/NXmicrostructure_score_results.nxdl.xml @@ -0,0 +1,567 @@ + + + + + + + + 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 about the computational + 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 automata model. + + The SCORE cellular automata model for primary recrystallization is an example + of a typical materials engineering application 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 nuclei during + static recrystallization. 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. + + + + + Configuration file with the parameterization of the + SCORE model that was used for this simulation. + + + + + + + + Discouraged free-text field to add further details to the computation. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the simulation was started. + + + + + ISO 8601 time code with local time zone offset to UTC information + included when the simulation ended. + + + + + + + Name of the program with which the simulation was performed. + + + + + + + + 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 for each CA domain. + + SCORE is a hybrid parallelized code that can evolve multiple replicas + in parallel. The set of replicas is distributed across MPI processes. + Each such replica is then evolved via OpenMP multi-threading. + + + + + Summary quantities which are the result of some post-processing of the snapshot data + (averaging, integrating, interpolating) happening for practical and performance reasons + during 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. + + + + + + + + + + + + + + Simulated physical time for this snapshot. + + + + + Iteration or increment counter of this snapshot. + + + + + 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. + + + + + + + Index for each crystal whereby its metadata can be retrieved. + + + + + + + + + + Identifier of the OpenMP thread that processed this part of the grid. + + + + + + + + + + + + + + + + + + + + + + + + + + + Volume of each grain (partially transformed cells are accounted for). + + + + + + + + + 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. + + Each CA is processed by a team of OpenMP threads. + + + + Which cells are currently in a halo region of threads. + + The halo region is a layer of cells about the sub-domain + of the simulation grid evolved by a thread. + + + + + + + + So-called mobility weight which is a scaling factor to control the + mobility of the grain boundary that is modelled sweeping cells that + make the discrete recrystallization front. + + + + + + + + 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/NXslip_system_set.nxdl.xml b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml similarity index 65% rename from contributed_definitions/NXslip_system_set.nxdl.xml rename to contributed_definitions/NXmicrostructure_slip_system.nxdl.xml index 8fafee2e41..f9387095c3 100644 --- a/contributed_definitions/NXslip_system_set.nxdl.xml +++ b/contributed_definitions/NXmicrostructure_slip_system.nxdl.xml @@ -2,9 +2,9 @@ - + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - Number of slip systems. + Number of slip systems. + + + + + Number of indices used for reporting Miller (3) or Miller-Bravais indices (4). - Base class for describing a set of crystallographic slip systems. + Base class for describing a set of crystallographic slip systems. - - - + + + Bravais lattice type + @@ -50,33 +54,29 @@ identifier(NX_UINT):--> - - Array of Miller indices which describe the crystallographic plane. + Array of Miller indices which describe the crystallographic planes. - - Array of Miller indices which describe the crystallographic direction. + Array of Miller or Miller-Bravais indices that describe the crystallographic + direction. - + - For each slip system a marker whether the specified Miller indices - refer to the specific slip system or the set of crystallographic equivalent - slip systems of the respective family of slip systems. + For each slip system a marker whether the Miller indices refer to a specific slip system + or to a set of equivalent crystallographic slip systems. diff --git a/contributed_definitions/NXms.nxdl.xml b/contributed_definitions/NXms.nxdl.xml deleted file mode 100644 index fbd6aed5d6..0000000000 --- a/contributed_definitions/NXms.nxdl.xml +++ /dev/null @@ -1,527 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Number of boundaries of the bounding box or primitive to domain. - - - - - Number of parameter required for the chosen orientation parameterization. - - - - - Number of texture components identified. - - - - - Application definition, spatiotemporal characterization of a microstructure. - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this experiment or computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the workflow (experiment/analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - - - - - - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe - a microstructure. - - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - Given that microstructure simulations nowadays more and more consider - the atomic arrangement, this application definition can also be used - to describe features at the scale of atoms. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron, or NXcg_point. This geometry group needs - to contain details about the boundary conditions. - - - - - - - - A boundary to the volume element. - Either an instance of NXcg_hexahedron or of NXcg_ellipsoid. - - - - - How many distinct boundaries are distinguished. Value required equal to n_b. - - - - - Name of the boundaries. E.g. left, right, front, back, bottom, top, - - - - - - - - The boundary conditions for each boundary: - - 0 - undefined - 1 - open - 2 - periodic - 3 - mirror - 4 - von Neumann - 5 - Dirichlet - - - - - - - - - Collection of microstructural data observed/simulated. - - - - Integer which specifies the first index to be used for distinguishing - snapshots. 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. - - 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. - - - - - - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - - - - - - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - - - - - - - - Conceptually distinguished object/feature in the ROI/ - system with some relevance. Instances of NXms_feature_set can - be nested to build a hierarchy of logically-related objects. - - A typical example for MD simulations is to have one - ms_feature_set for the atoms which is the parent to another - ms_feature_set for monomers/molecules/proteins which is then the - parent to another ms_feature_set for the secondary, another feature_set - for the tertiary, and the parent for another feature_set for the - quaternary structure. - - Another typical example from materials engineering is to have - one ms_feature_set for crystals (grains/phases) which serves as - the parent to another ms_feature_set for interfaces between these - crystals which then is the parent for another ms_feature_set to - describe the triple junctions which is then the parent for the - quadruple/higher-order junctions between which connect the - triple lines. - - Another example from discrete dislocation dynamics could be to - have one ms_feature_set for the dislocations (maybe separate - sets for each dislocation type or family) which are then - parents to other ms_feature_set which describe junctions between - dislocations or features along the dislocation line network. - - - - - - Details about the orientation distribution function - within the entire domain. - - - - With which method was the ODF approximated? - - - - - - TO BE DEFINED - - - - - TO BE DEFINED - - - - - Collection of texture components commonly referred to. - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - Parameterized orientations. - - - - - - - - - Name of each texture component, e.g. Cube, Dillamore, Y. - - - - - - - - The portion of orientation space integrated over - to compute the volume fraction. - - - - - - - - The volume fraction of each texture component. - - - - - - - - - - Details about the disorientation distribution function - within the entire domain. - - - - - Details about the grain boundary character distribution - within the entire domain. - - - - - - - - - - - - - - - - - - diff --git a/contributed_definitions/NXms_feature_set.nxdl.xml b/contributed_definitions/NXms_feature_set.nxdl.xml deleted file mode 100644 index 3b39927959..0000000000 --- a/contributed_definitions/NXms_feature_set.nxdl.xml +++ /dev/null @@ -1,278 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Dimensionality - - - - - Cardinality/number of members/features in the feature set. - - - - - Number of types in the dictionary of human-readable types of features. - - - - - Total number of parent identifier. - - - - - Set of topological/spatial features in materials build from other features. - - - - - - Name (or link?) to another NXms_feature_set which defines features what are - assumed as the parents/super_features of all members in this feature set. - If depends_on is set to "." or this attribute is not defined in an instance - of this application definition, assume that this feature_set instance - represents the root feature_set of the feature tree/graph. - - - - - - What is the best matching description how dimensional the feature is. - - - - - - - - - - - - How many features/members are in this set? - - - - - - The keywords of the dictionary of human-readable types of features. - Using terms from a community-agreed upon controlled vocabulary, e.g. - atom, solute, vacancy, monomer, molecule, anti-site, crowd_ion, - quadruple junction, triple line, disconnection, dislocation, - kink, jog, stacking_fault, homo_phase_boundary, hetero_phase_boundary, - surface, thermal_groove_root, precipitate, dispersoid, pore, crack - is recommended. - - - - - - - - - The integer identifier used to resolve of which type each feature is, - i.e. the values of the dictionary of human-readable types of features. - - - - - - - - For each feature in the set specify the associated number of identifier - to parent features as are resolvable via depends_on. - This array enables to compute the array interval from which details for - specific features can be extracted as if they would be stored in an own - group. - - - - - - - - Concatenated array of parent identifier for each feature (in the sequence) - according to identifier and how the identifier of features in the here - described feature set are defined (implicitly from 0, to c-1 or via explicit - identifier. - - - - - - - - - Integer which specifies the first index to be used for distinguishing - features. 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. - - 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. - - - - - Integer used to distinguish features for explicit indexing. - - - - - - - - Assumptions and parameter to arrive at geometric primitives - to locate zero-dimensional/point-(like) features which are - discretized/represented by points. - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate one-dimensional/line-like features which are - discretized by polylines. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate two-dimensional/interface features which are - discretized by triangulated surface meshes. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - Assumptions and parameters to arrive at geometric primitives - to locate three-dimensional/volumetric features which are - discretized by triangulated surface meshes of polyhedra. - - - - - - Assumptions, parameters, and details how positional uncertainty - of the geometry is quantified. - - - - - - - - - diff --git a/contributed_definitions/NXms_score_config.nxdl.xml b/contributed_definitions/NXms_score_config.nxdl.xml deleted file mode 100644 index 557b619291..0000000000 --- a/contributed_definitions/NXms_score_config.nxdl.xml +++ /dev/null @@ -1,452 +0,0 @@ - - - - - - - - Number of Bunge-Euler angle triplets for deformed grains. - - - - - Number of Bunge-Euler angle triplets for recrystallization nuclei. - - - - - Number of solitary unit domains to export. - - - - - Application definition to control a simulation with the SCORE model. - - - - - Version specifier of this application definition. - - - - - Official NeXus NXDL schema with which this file was written. - - - - - - - - - - - - - Ideally, a (globally persistent) unique identifier for referring - to this analysis. - - - - - Possibility for leaving a free-text description about this analysis. - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - ISO 8601 formatted time code with local time zone offset to UTC - information included when this configuration file was created. - - - - - 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. - - - - Which model should be used to generate a starting microstructure. - - - - - - - - - - - Edge length of the cubic cells of each CA domain. - - - - - 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. - - - - - - - - Extent of each deformed grain along the x, y, and z direction when type is - cuboidal. - - - - - - - - Average spherical diameter when type is poisson_voronoi. - - - - - Set of Bunge-Euler angles to sample orientations randomly from. - - - - - - - - - The EBSD dataset from which the initial microstructure is instantiated - if initial_microstructure/type has value ebsd. - - - - Path and name of the EBSD dataset from which to generate the starting - microstructure. - - - - SHA256 checksum of the file which contains the EBSD dataset. - - - - - - Size of the EBSD. The EBSD orientation mapping has to be on a - regular grid of square-shaped pixels. - - - - - - - - - - Phenomenological model according to which it nuclei are placed - into the domain and assumed growing. - - - - According to which model will the nuclei become distributed spatially. - CSR means complete spatial randomness. - Custom is implementation specific. - GB places nuclei 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 to sample orientations of nuclei randomly from. - - - - - - - - - - (Mechanical) properties of the material which scale the amount - of stored (elastic) energy in the ROI/system. - - - - 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. - - - - Which type of fundamental model for the grain boundary mobility: - For the Sebald-Gottstein model the following equation is used. - For the Rollett-Holm model the following equation is used. - - - - - - - - - - - - - - - - - - - - - - - - - Simulated evolution of the dislocation density as the stored - (elastic) energy assumed stored in each grain. - - - - Which type of recovery model. - - - - - - - - - Simulated reduction of the grain boundary 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. - - - - - - - - - - - - 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. - - - - - - - - - - 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 is 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 exported for. - - - - - - - - - - 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/NXms_score_results.nxdl.xml b/contributed_definitions/NXms_score_results.nxdl.xml deleted file mode 100644 index 5d749ebc95..0000000000 --- a/contributed_definitions/NXms_score_results.nxdl.xml +++ /dev/null @@ -1,720 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - 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>`_ - - - - - An at least as strong as SHA256 hashvalue of the file - that specifies the application definition. - - - - - - NeXus NXDL schema to which this file conforms. - - - - - - - - Ideally, a (globally) unique persistent identifier - for referring to this computer simulation. - - The identifier is usually defined/issued by the facility, laboratory, - or the principle investigator. The identifier enables to link - experiments to e.g. proposals. - - - - - Free-text description about the workflow (analysis/simulation). - - Users are strongly advised to detail the sample history in the - respective field and fill rather as completely as possible the fields - of this application definition rather than write details about the - experiment into this free-text description field. - - - - - ISO 8601 time code with local time zone offset to UTC information - included when the characterization started. - - - - - ISO 8601 time code with local time zone offset to UTC included - when the characterization ended. - - - - - - - - - - Specify if the (characterization) results/data of this instance of an - application definition are based on the results of a simulation or the - results of a post-processing of measured data to describe a microstructure. - The term microstructure is used to describe the spatial arrangement of - crystal defects inside a sample/specimen without demanding necessarily - that this structure is mainly at the micron length scale. - Nanostructure and macrostructure are close synonyms. - Material architecture is a narrow synonym. - - - - - - - - - - The path and name of the config file for this analysis. - - - - At least SHA256 strong hash of the specific config_file for - tracking provenance. - - - - - - Path to the directory where the tool should store NeXus/HDF5 results - of this analysis. If not specified results will be stored in the - current working directory. - - - - - A statement whether the SCORE executable managed to - process the analysis or failed prematurely. - - This status is written to the results file after the end_time - at which point the executable must not compute any analysis. - Only when this status message is present and shows `success`, the - user should consider the results. In all other cases it might be - that the executable has terminated prematurely or another error - occurred. - - - - - - - - - Contact information and eventually details of at least one person - involved in creating this result. This can be the principle investigator - who performed this experiment. Adding multiple users if relevant is recommended. - - - - Given (first) name and surname of the user. - - - - - Name of the affiliation of the user at the point in time - when the experiment was performed. - - - - - Postal address of the affiliation. - - - - - Email address of the user at the point in time when the experiment - was performed. Writing the most permanently used email is recommended. - - - - - Globally unique identifier of the user as offered by services - like ORCID or ResearcherID. If this field is field the specific service - should also be written in orcid_platform - - - - - Name of the OrcID or ResearcherID where the account - under orcid is registered. - - - - - (Business) (tele)phone number of the user at the point - in time when the experiment was performed. - - - - - Which role does the user have in the place and at the point - in time when the experiment was performed? Technician operating - the microscope. Student, postdoc, principle investigator, guest - are common examples. - - - - - Account name that is associated with the user in social media platforms. - - - - - Name of the social media platform where the account - under social_media_name is registered. - - - - - - - - Descriptive name or ideally (globally) unique persistent identifier. - - - - - - - Hard link to a location in the hierarchy of the NeXus file - where the data for default plotting are stored. - - - - - Container to hold different coordinate systems conventions. - A least a right-handed Cartesian coordinate system with base vectors - named x, y, and z has to be specified. Each base vector of the - coordinate system should be described with an NXtransformations instance. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The simulated or characterized material volume element aka domain. - At least one instance of geometry required either NXcg_grid, - NXcg_polyhedron, or NXcg_point. This geometry group needs - to contain details about the boundary conditions. - - - - - - - - - - - - - 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. - - - - - 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 - - - - - - - - - Collection of microstructural data observed/simulated. - - - - Integer which specifies the first index to be used for distinguishing - snapshots. 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. - - 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. - - - - - - Summary quantities which are the result of some post-processing of - the snapshot data (averaging, integrating, interpolating). - Frequently used descriptors from continuum mechanics and thermodynamics - can be used here. A few examples are given. Each descriptor is currently - modelled as an instance of an NXprocess because it is relevant to - understand how the descriptors are computed. - - - - Evolution of the physical time. - - - - - Evolution of the simulated temperature over time. - - - - - - Evolution of the recrystallized volume fraction over time. - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Simulated temperature. - - - - - Iteration or increment counter. - - - - - - - Grain identifier for each cell. - - - - - - - - - - Identifier of the OpenMP thread which processed this part of the grid. - - - - - - - - - - - - Details about those cells which in this time step represent - the discretized 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. - - - - - - - - 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. - - - - - - - - Relative volume transformed as a measure of infection progress. - - - - - - - - Identifier of the OpenMP thread processing each cell in the recrystallization - front. - - - - - - - - Hint about the direction from which the cell was infected. - - - - - - - - - Current grain-related quantities. - - - - Bunge-Euler angle triplets for each grain. - - - - - - - - - Discrete volume of each grain accounting also for partially - transformed cells. - - - - - - - - Current value for the dislocation density as a measure of - the remaining stored energy in assumed crystal defects inside - each grain. The difference between these values scales the - driving force of grain boundary migration. - - - - - - - - Is the grain deformed. - - - - - - - - Is the grain recrystallized. - - - - - - - - - Current recrystallized volume fraction. - - - - Currently evaluated actual recrystallized volume fraction. - This takes into account partially recrystallized cells. - - - - - Currently desired target recrystallized volume fraction at - which the user requested to log a snapshot. - - - - - - - - Currently assumed globally applied Cauchy stress tensor on the ROI. - - - - - - - - - - - Currently assumed globally applied Cauchy strain tensor on the ROI. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Specify if it was different from the number_of_processes - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - Specify if it was different from the number_of_threads - in the NXcs_profiling super class. - - - - - - - - - diff --git a/contributed_definitions/NXms_snapshot.nxdl.xml b/contributed_definitions/NXms_snapshot.nxdl.xml deleted file mode 100644 index 1f922e281b..0000000000 --- a/contributed_definitions/NXms_snapshot.nxdl.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - Base class for data on the state of the microstructure at a given - time/iteration. - - - - Is this time for a measurement or a simulation. - - - - - - - - - Measured or simulated physical time stamp for this snapshot. - Not to be confused with wall-clock timing or profiling data. - - - - - Iteration or increment counter. - - - diff --git a/contributed_definitions/NXms_snapshot_set.nxdl.xml b/contributed_definitions/NXms_snapshot_set.nxdl.xml deleted file mode 100644 index 6cff36cc33..0000000000 --- a/contributed_definitions/NXms_snapshot_set.nxdl.xml +++ /dev/null @@ -1,62 +0,0 @@ - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - A collection of spatiotemporal microstructure data. - - - - Is this set describing a measurement or a simulation? - - - - - - - - - Integer which specifies the first index to be used for distinguishing - snapshots. 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. - - 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. - - - - - - diff --git a/contributed_definitions/NXfiber.nxdl.xml b/contributed_definitions/NXoptical_fiber.nxdl.xml similarity index 53% rename from contributed_definitions/NXfiber.nxdl.xml rename to contributed_definitions/NXoptical_fiber.nxdl.xml index f4a32db3c3..15358ba2a2 100644 --- a/contributed_definitions/NXfiber.nxdl.xml +++ b/contributed_definitions/NXoptical_fiber.nxdl.xml @@ -3,7 +3,7 @@ - + - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the core material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the core material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - refractive index of the cladding material is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + refractive index of the cladding material is given. - Length of the spectrum vector (e.g. wavelength or energy) for which the - attenuation curve is given. + Length of the spectrum vector (e.g. wavelength or energy) for which the + attenuation curve is given. - An optical fiber, e.g. glass fiber. - - Specify the quantities that define the fiber. Fiber optics are described in - detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for - example. + An optical fiber, e.g. glass fiber. + + Specify the quantities that define the fiber. Fiber optics are described in + detail [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4), for + example. - Descriptive name or brief description of the fiber, e.g. by stating its - dimension. The dimension of a fiber can be given as 60/100/200 which - refers to a core diameter of 60 micron, a clad diameter of 100 micron, - and a coating diameter of 200 micron. + Descriptive name or brief description of the fiber, e.g. by stating its + dimension. The dimension of a fiber can be given as 60/100/200 which + refers to a core diameter of 60 micron, a clad diameter of 100 micron, + and a coating diameter of 200 micron. - Type/mode of the fiber. Modes of fiber transmission are shown in - Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). + Type/mode of the fiber. Modes of fiber transmission are shown in + Fig. 5 [here](https://www.photonics.com/Article.aspx?AID=25151&PID=4). @@ -71,9 +71,9 @@ - Type of dispersion. + Type of dispersion. - + @@ -81,8 +81,8 @@ - Spectrum-dependent (or refractive index-dependent) dispersion of the - fiber. Specify in ps/nm*km. + Spectrum-dependent (or refractive index-dependent) dispersion of the + fiber. Specify in ps/nm*km. @@ -90,22 +90,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Core diameter of the fiber (e.g. given in micrometer). + Core diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -115,22 +115,22 @@ - Core of the fiber, i.e. the part of the fiber which transmits the light. + Core of the fiber, i.e. the part of the fiber which transmits the light. - + - Specify the material of the core of the fiber. + Specify the material of the core of the fiber. - + - Clad diameter of the fiber (e.g. given in micrometer). + Clad diameter of the fiber (e.g. given in micrometer). - + - Complex index of refraction of the fiber. Specify at given wavelength - (or energy, wavenumber etc.) values. + Complex index of refraction of the fiber. Specify at given wavelength + (or energy, wavenumber etc.) values. @@ -140,64 +140,59 @@ - Coating of the fiber. + Coating of the fiber. - + - Specify the material of the coating of the fiber. + Specify the material of the coating of the fiber. - + - Outer diameter of the fiber (e.g. given in micrometer). + Outer diameter of the fiber (e.g. given in micrometer). - Length of the fiber. + Length of the fiber. - Spectral range for which the fiber is designed. Enter the minimum and - maximum values (lower and upper limit) of the wavelength range. + Spectral range for which the fiber is designed. Enter the minimum and + maximum values (lower and upper limit) of the wavelength range. - Unit of spectral array (e.g. nanometer or angstrom for wavelength, or - electronvolt for energy etc.). + Unit of spectral array (e.g. nanometer or angstrom for wavelength, or + electronvolt for energy etc.). - + - Transfer rate of the fiber (in GB per second). + Transfer rate of the fiber (in GB per second). - - - GB/s - - - Numerical aperture (NA) of the fiber. + Numerical aperture (NA) of the fiber. - + - Wavelength-dependent attenuation of the fiber (specify in dB/km). + Wavelength-dependent attenuation of the fiber (specify in dB/km). - Use dB/km. + Use dB/km. @@ -206,12 +201,12 @@ - Power loss of the fiber in percentage. + Power loss of the fiber in percentage. - Acceptance angle of the fiber. + Acceptance angle of the fiber. diff --git a/contributed_definitions/NXpolarizer_opt.nxdl.xml b/contributed_definitions/NXoptical_polarizer.nxdl.xml similarity index 51% rename from contributed_definitions/NXpolarizer_opt.nxdl.xml rename to contributed_definitions/NXoptical_polarizer.nxdl.xml index 47a6560c21..9536b3896c 100644 --- a/contributed_definitions/NXpolarizer_opt.nxdl.xml +++ b/contributed_definitions/NXoptical_polarizer.nxdl.xml @@ -3,7 +3,7 @@ - - + - Size of the wavelength array for which the refractive index of the material - and/or coating is given. + Size of the wavelength array for which the refractive index of the material + and/or coating is given. - Size of the wavelength array for which the reflectance or transmission of - the polarizer is given. + Size of the wavelength array for which the reflectance or transmission of + the polarizer is given. - An optical polarizer. - - Information on the properties of polarizer is provided e.g. - [here](https://www.rp-photonics.com/polarizers.html). + An optical polarizer. + + Information on the properties of polarizer is provided e.g. + [here](https://www.rp-photonics.com/polarizers.html). - Type of the polarizer (e.g. dichroic, linear, circular etc.) + Type of the polarizer - + @@ -61,23 +62,16 @@ - - - - - If you selected 'other' in type specify what it is. - - - Angle of the polarizer. + Angle of the polarizer. - Acceptance angle of the polarizer (range). + Acceptance angle of the polarizer (range). @@ -85,18 +79,17 @@ - Describe the geometry (shape, dimension etc.) of the device. - Specify the dimensions in 'SHAPE/size'. A sketch of the device should be - provided in the 'sketch(NXdata)' field to clarify (i) the shape and - dimensions of the device, and (ii) the input and outputs (i.e. the - direction of the incoming and outcoming (split) beams). + Describe the geometry (shape, dimension etc.) of the device. + Specify the dimensions in 'SHAPE/size'. A sketch of the device should be + provided in the 'sketch(NXdata)' field to clarify (i) the shape and + dimensions of the device, and (ii) the input and outputs (i.e. the + direction of the incoming and outcoming (split) beams). - - Describe the shape (plate, cube, wedged, prism etc.). + Describe the shape (plate, cube, wedged, prism etc.). - + @@ -105,33 +98,28 @@ - - - If you chose 'other' in 'shape' describe what it is. - - - Sketch of the device showing its geometry. The paths of the - incoming and outgoing beam should be illustrated and labelled (0 for - the incoming beam, and 1, 2,..., N_outputs for the outputs). + Sketch of the device showing its geometry. The paths of the + incoming and outgoing beam should be illustrated and labelled (0 for + the incoming beam, and 1, 2,..., N_outputs for the outputs). - Physical extent of the device. The device might be made up of one or - more objects (NX_objects). The meaning and location of the axes used - will vary according to the value of the 'shape' variable. 'N_shapepar' - defines how many parameters: - - * For 'cube' the parameters are (width, length). - * For 'cylinder' the parameters are (diameter, length). - * For 'plate' the parameters are (width, height, length). - * For 'prism' the parameters are (width, height, length). - * For 'wedged' the parameters are (width, height, shortest length). - The wedge angle should be provided in 'SHAPE/wedge_angle'. - * For 'other' the parameters may be (A, B, C, ...) with the labels - defined in the sketch plotted in 'SHAPE/sketch'. + Physical extent of the device. The device might be made up of one or + more objects (NX_objects). The meaning and location of the axes used + will vary according to the value of the 'shape' variable. 'N_shapepar' + defines how many parameters: + + * For 'cube' the parameters are (width, length). + * For 'cylinder' the parameters are (diameter, length). + * For 'plate' the parameters are (width, height, length). + * For 'prism' the parameters are (width, height, length). + * For 'wedged' the parameters are (width, height, shortest length). + The wedge angle should be provided in 'SHAPE/wedge_angle'. + * For 'other' the parameters may be (A, B, C, ...) with the labels + defined in the sketch plotted in 'SHAPE/sketch'. @@ -140,14 +128,14 @@ - Wedge angle if 'shape' is 'wedged'. + Wedge angle if 'shape' is 'wedged'. - Wavelength range for which the polarizer is designed. Enter the minimum - and maximum wavelength (lower and upper limit) of the range. + Wavelength range for which the polarizer is designed. Enter the minimum + and maximum wavelength (lower and upper limit) of the range. @@ -155,23 +143,23 @@ - Properties of the substrate material of the polarizer. If the device has - a coating specify the coating material and its properties in 'coating'. + Properties of the substrate material of the polarizer. If the device has + a coating specify the coating material and its properties in ``COATING``. - Specify the substrate material of the polarizer. + Specify the substrate material of the polarizer. - Thickness of the polarizer substrate. + Thickness of the polarizer substrate. - Complex index of refraction of the polarizer material. Specify at given - spectral values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the polarizer material. Specify at given + spectral values (wavelength, energy, wavenumber etc.). @@ -179,36 +167,37 @@ - - - If the device has a coating describe the material and its properties. - Some basic information can be found e.g. [here] - (https://www.opto-e.com/basics/reflection-transmission-and-coatings). - If the back and front side of the polarizer are coated with different - materials, you may define two coatings (e.g. COATING1 and COATING2). + If the device has a coating describe the material and its properties. + Some basic information can be found e.g. [here] + (https://www.opto-e.com/basics/reflection-transmission-and-coatings). + If the back and front side of the polarizer are coated with different + materials, you may define two coatings (e.g. coating_front and + coating_back). - + - Specify the coating type (e.g. dielectric, anti-reflection (AR), - multilayer coating etc.). + Specify the coating type (e.g. dielectric, anti-reflection (AR), + multilayer coating etc.). - + - Describe the coating material (e.g. MgF2). + Describe the coating material (e.g. MgF2). - + - Thickness of the coating. + Thickness of the coating. - Complex index of refraction of the coating. Specify at given spectral - values (wavelength, energy, wavenumber etc.). + Complex index of refraction of the coating. Specify at given spectral + values (wavelength, energy, wavenumber etc.). @@ -218,7 +207,7 @@ the device has different coatings on the front and back side.--> - Extinction ratio (maximum to minimum transmission). + Extinction ratio (maximum to minimum transmission). @@ -226,7 +215,7 @@ the device has different coatings on the front and back side.--> - Reflection of the polarizer at given wavelength values. + Reflection of the polarizer at given wavelength values. @@ -234,11 +223,10 @@ the device has different coatings on the front and back side.--> - Transmission of the polarizer at given wavelength values. + Transmission of the polarizer at given wavelength values. - diff --git a/contributed_definitions/NXorientation_set.nxdl.xml b/contributed_definitions/NXorientation_set.nxdl.xml deleted file mode 100644 index 196f0f3a34..0000000000 --- a/contributed_definitions/NXorientation_set.nxdl.xml +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - The symbols used in the schema to specify e.g. dimensions of arrays. - - - - The dimensionality of the reference space/coordinate system. - - - - - The cardinality of the set, i.e. the number of orientations. - - - - - Number of parameters for the chosen parameterization. - - - - - Details about individual orientations of a set of objects. - - For a more detailed insight into the discussion of parametrizing - orientations in materials science see: - - * https://doi.org/10.1016/j.matchar.2016.04.008 - * https://doi.org/10.1088/0965-0393/23/8/083501 - * https://doi.org/10.1007/978-3-662-09156-2 group-theory of rotations - * https://doi.org/10.1016/C2013-0-11769-2 the classical book of H.-J. Bunge - - - - - Reference to or definition of a coordinate system with - which the definitions are interpretable. - - - - - - - - - - - - A link or reference to the objects whose identifier are referred to in - identifier to resolve which row tuple is the orientation of each object - by reading orientations. - - - - - Integer which specifies which orientation (row of array orientation) matches - to which object.e 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 [identifier_offset, identifier_offset+c-1]. - For explicit indexing the identifier array has to be defined. - - 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. - - - - - Integer used to distinguish how a row in orientation describes a specific - object with an explicit identifier that can be queried via inspecting the - list of available objects in objects. - - The rational behind having such a more complicated pattern is that not - all objects referred when following the link in objects may still exists - or are still tracked when the orientation set was characterized. - - This design enables to also use NXorientation_set in situations where - the orientation of objects change as a function in time. - - - - - - - - Parameterized orientations. - - - - - - - - - diff --git a/contributed_definitions/NXquadrupole_magnet.nxdl.xml b/contributed_definitions/NXquadrupole_magnet.nxdl.xml index 84442c7a17..27c43f1258 100644 --- a/contributed_definitions/NXquadrupole_magnet.nxdl.xml +++ b/contributed_definitions/NXquadrupole_magnet.nxdl.xml @@ -26,26 +26,26 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a quadrupole magnet. + Base class for a quadrupole magnet. -extended description of the magnet. +Extended description of the magnet. -define position of beamline element relative to production target +Define position of beamline element relative to production target -current set on supply. +Current set on supply. -current read from supply. +Current read from supply. -voltage read from supply. +Voltage read from supply. diff --git a/contributed_definitions/NXsensor_scan.nxdl.xml b/contributed_definitions/NXsensor_scan.nxdl.xml index 3f9b7c5922..0a0384363c 100644 --- a/contributed_definitions/NXsensor_scan.nxdl.xml +++ b/contributed_definitions/NXsensor_scan.nxdl.xml @@ -2,9 +2,9 @@ - + - Variables used to set a common size for collected sensor data. + Variables used to set a common size for collected sensor data. - The number of scan points measured in this scan. + The number of scan points measured in this scan. - Application definition for a generic scan using sensors. - - In this application definition, times should be specified always together - with an UTC offset. + Application definition for a generic scan using sensors. + + In this application definition, times should be specified always together + with an UTC offset. + + + .. 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 visualized upon entry. + See https://www.nexusformat.org/2014_How_to_find_default_data.html + for a summary of the discussion. + + - - - - + + + The unique identifier for the entry. The identifier is mainly lab-defined and + can be a combination of the sample name, date and time, experiment condition + (such as temperature) or instrument-generated unique identifier. + + + + + The unique identifier for the collection. The identifier is used to group a + number of the experiments run upon the same setup and/or same sample. + + + + + - Define the program that was used to generate the results file(s) - with measured data and metadata. + Define the program that was used to generate the results file(s) + with measured data and metadata. - Commercial or otherwise defined given name of the program - (or a link to the instrument software). + Commercial or otherwise defined given name of the program + (or a link to the instrument software). - Either version with build number, commit hash, or description of an - (online) repository where the source code of the program and build - instructions can be found so that the program can be configured in - such a way that result files can be created ideally in a - deterministic manner. + Either version with build number, commit hash, or description of an + (online) repository where the source code of the program and build + instructions can be found so that the program can be configured in + such a way that result files can be created ideally in a + deterministic manner. - Website of the software. + Website of the software. - Contact information of at least the user of the instrument or the - investigator who performed this experiment. Adding multiple users if - relevant is recommended. + Contact information of at least the user of the instrument or the + investigator who performed this experiment. Adding multiple users if + relevant is recommended. - Name of the user. + Name of the user. - Name of the affiliation of the user at the point in time when - the experiment was performed. + Name of the affiliation of the user at the point in time when + the experiment was performed. - Full address (street, street number, ZIP, city, country) - of the user's affiliation. + Full address (street, street number, ZIP, city, country) + of the user's affiliation. - Email address of the user. + Email address of the user. - Author ID defined by https://orcid.org/. + Author ID defined by https://orcid.org/. - Official telephone number of the user. + Official telephone number of the user. + + + Any additional information or notes (e.g. purpose of the experiment) that might + be useful to understand the experiment. + + - Describes an environment setup for the experiment. - - All the setting values of the independently scanned controllers are listed under corresponding - NXsensor groups. Similarly, separate 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 - present as independently scanned controllers and the current sensor must also be present with - its readings. + Describes an environment setup for the experiment. + + All the setting values of the independently scanned controllers are listed under corresponding + NXsensor groups. Similarly, separate 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 + present as independently scanned controllers and the current sensor must also be present with + its readings. - + - Plot of measured signal as a function of the timestamp of when they have been - acquired is also possible. + Plot of measured signal as a function of the timestamp of when they have been + acquired is also possible. - For each point in the scan space, either the nominal setpoint of an independently scanned controller - or a representative average value of a measurement sensor is registered. - - The length of each sensor's data value array stored in this group should be equal to the number of scan points - probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. - This allows the scan to be made in any order as the user describes above in the experiment. We get matching - values simply using the index of the scan point. + For each point in the scan space, either the nominal setpoint of an independently scanned controller + or a representative average value of a measurement sensor is registered. + + The length of each sensor's data value array stored in this group should be equal to the number of scan points + probed in this scan. For every scan point [N], the corresponding sensor value can be picked from index [N]. + This allows the scan to be made in any order as the user describes above in the experiment. We get matching + values simply using the index of the scan point. @@ -150,48 +181,49 @@ - Timestamp for when the values provided in the value field were registered. - - Individual readings can be stored with their timestamps under value_log. This is to timestamp - the nominal setpoint or average reading values listed above in the value field. + Timestamp for when the values provided in the value field were registered. + + Individual readings can be stored with their timestamps under value_log. This is to timestamp + the nominal setpoint or average reading values listed above in the value field. - Free-text describing the data acquisition control: an internal - sweep using the built-in functionality of the controller device, - or a set/wait/read/repeat mechanism. + Free-text describing the data acquisition control: an internal + sweep using the built-in functionality of the controller device, + or a set/wait/read/repeat mechanism. - + - ISO8601 datum when calibration was last performed - before this measurement. UTC offset should be specified. + ISO8601 datum when calibration was last performed + before this measurement. UTC offset should be specified. - - + + - A list of names of NXsensor groups used as independently scanned controllers. + A list of names of NXsensor groups used as independently scanned controllers. - + - A list of names of NXsensor groups used as measurement sensors. + A list of names of NXsensor groups used as measurement sensors. - + + - A scan specific representation of the measured signals as a function of the independently controlled environment settings. - Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. + A scan specific representation of the measured signals as a function of the independently controlled environment settings. + Plot of every measured signal as a function of the timestamp of when they have been acquired is also possible. diff --git a/contributed_definitions/NXseparator.nxdl.xml b/contributed_definitions/NXseparator.nxdl.xml index 81ba465340..1b90017b30 100644 --- a/contributed_definitions/NXseparator.nxdl.xml +++ b/contributed_definitions/NXseparator.nxdl.xml @@ -26,32 +26,32 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for an electrostatic separator. + Base class for an electrostatic separator. - extended description of the separator. + Extended description of the separator. - define position of beamline element relative to production target + Define position of beamline element relative to production target - current set on magnet supply. + Current set on magnet supply. - + current read from magnet supply. - + voltage read from magnet supply. - + current set on HT supply. - + current read from HT supply. - + voltage read from HT supply. diff --git a/contributed_definitions/NXsimilarity_grouping.nxdl.xml b/contributed_definitions/NXsimilarity_grouping.nxdl.xml index 2973b9d649..0a0878f449 100644 --- a/contributed_definitions/NXsimilarity_grouping.nxdl.xml +++ b/contributed_definitions/NXsimilarity_grouping.nxdl.xml @@ -2,9 +2,9 @@ - + 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,30 +75,29 @@ How many categorical labels does each feature have. - - + + - Which identifier is the first to be used to label a cluster. + Which numerical index 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. - 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. + * index_offset - 1 indicates that an object belongs to no cluster. + * index_offset - 2 indicates that an object belongs to the noise category. + Setting for instance index_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. - - - - + Matrix of numerical label for each member in the set. For classical clustering algorithms this can for instance - encode the cluster_identifier. + encode the indices_cluster. @@ -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 d036d84574..68367062a7 100644 --- a/contributed_definitions/NXspatial_filter.nxdl.xml +++ b/contributed_definitions/NXspatial_filter.nxdl.xml @@ -2,9 +2,9 @@ - - + + - The symbols used in the schema to specify e.g. dimensions of arrays. + The symbols used in the schema to specify e.g. dimensions of arrays. - + - Number of ellipsoids. + Number of hexahedra. - + - Number of hexahedra. + Number of cylinders. - + + + Number of ellipsoids. + + + - Number of cylinders. + 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, objects composed from other geometric primitives, + or objects. - + - Qualitative statement which specifies which spatial filtering with respective - geometric primitives or bitmask is used. These settings are possible: - - * 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. + Qualitative statement which describes the logical operations + that define which objects will be included and which excluded: + + * 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. + Multiple instances of NXcg base classes are used to compose a union_of_primitives. @@ -78,8 +77,9 @@ - - + + + diff --git a/contributed_definitions/NXspin_rotator.nxdl.xml b/contributed_definitions/NXspin_rotator.nxdl.xml index 8c0b93ad1f..e0e4046537 100644 --- a/contributed_definitions/NXspin_rotator.nxdl.xml +++ b/contributed_definitions/NXspin_rotator.nxdl.xml @@ -26,32 +26,32 @@ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://definition.nexusformat.org/nxdl/3.1 ../nxdl.xsd" > - definition for a spin rotator. + Base class for a spin rotator. - extended description of the spin rotator. + Extended description of the spin rotator. - define position of beamline element relative to production target + Define position of beamline element relative to production target - + current set on magnet supply. - + current read from magnet supply. - + voltage read from magnet supply. - + current set on HT supply. - + current read from HT supply. - + voltage read from HT supply. diff --git a/contributed_definitions/NXsubsampling_filter.nxdl.xml b/contributed_definitions/NXsubsampling_filter.nxdl.xml index ea378eab39..29d2399beb 100644 --- a/contributed_definitions/NXsubsampling_filter.nxdl.xml +++ b/contributed_definitions/NXsubsampling_filter.nxdl.xml @@ -2,9 +2,9 @@ - - - - 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 indices. + + The filter defines three parameters: The minimum, the increment, and the maximum + index of values 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 indices. The increment controls which n-th index (value) to take. + + Take as an example a dataset with 100 indices (aka entries). Assume that the indices start at zero, + i.e., index_offset is 0. Assume further that min, increment, max are set to 0, 1, and 99, respectively. + In this case the filter will yield all indices. Setting min, increment, max to 0, 2, and 99, respectively + will yield each second index value. Setting min, increment, max to 90, 3, and 99 respectively will yield + each third index value beginning from index values 90 up to 99. - + + + Minimum index. + + + + + Increment. + + + - Triplet of the minimum, increment, and maximum value which will - be included in the analysis. The increment controls which n-th entry 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. + Maximum index. - - - diff --git a/contributed_definitions/NXsubstance.nxdl.xml b/contributed_definitions/NXsubstance.nxdl.xml index 7d2328c81c..7e4b19f390 100644 --- a/contributed_definitions/NXsubstance.nxdl.xml +++ b/contributed_definitions/NXsubstance.nxdl.xml @@ -3,7 +3,7 @@ Application definition for transmission experiments - - This application definition - - - An application definition for transmission. - Version number to identify which definition of this application definition was used for this entry/data. - + URL where to find further material (documentation, examples) relevant to the application definition. @@ -72,10 +66,10 @@ Draft NeXus application definition for transmission experiments--> Start time of the experiment. - + Unique identifier of the experiment, such as a (globally persistent) - unique identifier. + unique identifier. * The identifier is usually defined by the facility or principle investigator. @@ -89,10 +83,6 @@ Draft NeXus application definition for transmission experiments--> definition rather than in this experiment description. - @@ -100,7 +90,7 @@ 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. @@ -112,7 +102,7 @@ of instrument.--> - + Contact information of at least the user of the instrument or the investigator who performed this experiment. Adding multiple users if relevant is recommended. @@ -122,32 +112,12 @@ of instrument.--> Name of the user. - + Name of the affiliation of the user at the point in time when the experiment was performed. - - - Street address of the user's affiliation. - - - - - Email address of the user. - - - - - Author ID defined by research ID services, e.g. orcid (https://orcid.org/). - - - - - Telephone number of the user. - - @@ -191,20 +161,21 @@ of instrument.--> Wavelength value(s) used for the measurement. - An array of 1 or more elements. Length defines N_wavelengths + An array of 1 or more elements. Length defines N_wavelenghts - + Overall spectral resolution of this spectrometer. If several gratings are employed the spectral resolution should rather be specified for each grating inside the NXgrating group of this spectrometer. - + + Diffraction grating, as could be used in a monochromator. @@ -214,7 +185,7 @@ of instrument.--> do not overlap. The dispersion should be defined for the entire wavelength range of the experiment. - + Dispersion of the grating in nm/mm used. @@ -224,12 +195,13 @@ of instrument.--> The blaze wavelength of the grating used. - + Overall spectral resolution of the instrument when this grating is used. - + + Wavelength range in which this grating was used @@ -310,7 +282,7 @@ of instrument.--> The type of lamp, e.g. halogen, D2 etc. - + @@ -334,8 +306,6 @@ of instrument.--> - Properties of the sample measured diff --git a/contributed_definitions/NXxrd.nxdl.xml b/contributed_definitions/NXxrd.nxdl.xml new file mode 100644 index 0000000000..626a13840d --- /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 collected + 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 diffractogram + + + + + + + + + + + + + + + + link (suggested target:/NXentry/NXinstrument/NXdetector/polar_angle) + Link to polar 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..a406ba60a5 --- /dev/null +++ b/contributed_definitions/NXxrd_pan.nxdl.xml @@ -0,0 +1,335 @@ + + + + + + NXxrd_pan is a specialization 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 analyzed, but sample might be identified by + assumed name or given name. + + + + + diff --git a/manual/source/classes/contributed_definitions/cgms-structure.rst b/manual/source/classes/contributed_definitions/cgms-structure.rst index 323d356494..ac18d3cebb 100644 --- a/manual/source/classes/contributed_definitions/cgms-structure.rst +++ b/manual/source/classes/contributed_definitions/cgms-structure.rst @@ -93,8 +93,5 @@ of material (area or volume) which can be useful not only for stencil-based meth is smoothed in a controlled manner. :ref:`NXsimilarity_grouping`: - An alternative for NXclustering. - - :ref:`NXclustering`: A description for clustering of objects (such as atoms or features). diff --git a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst index 134e245698..285e33775e 100644 --- a/manual/source/classes/contributed_definitions/ellipsometry-structure.rst +++ b/manual/source/classes/contributed_definitions/ellipsometry-structure.rst @@ -43,13 +43,13 @@ This is the set of base classes for describing an optical experiment. splitter. In the dependency chain of the new beam paths, the first elements each point to this beam splitter, as this is the previous element. - :ref:`NXfiber` + :ref:`NXoptical_fiber` An optical fiber, e.g. glass fiber. :ref:`NXoptical_lens` Description of an optical lens. - :ref:`NXpolarizer_opt` + :ref:`NXoptical_polarizer` An optical polarizer. :ref:`NXwaveplate`