- Apr 2023
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
ROI: (optional) NXcollection signed_distance: (required) NX_FLOAT In the direction of the ROI. isotope: (required) NX_UINT Hashvalue
appdef needs to be changed here, paraprobe-toolbox==0.4 currently reports ROI without a clear group (which should be changed in the paraprobe-nanochem source code) but also the fields signed_distance and isotope are not scalars but arrays of the same length [k] although that length may different for each instance of a ROI
It would be possible to add a default plot for every single ROI in this way the classical proxigram could be displayed directly using H5Web, the key overhead which comes with this is the need for very many small data entries which likely blow up the HDF5 file unnecessarily, for this reason currently such default plot is not exported
-
roi_identifier: (required) NX_UINT (Rank: 1, Dimensions: [i]) {units=NX_UNITLESS} Integer which specifies the first index to be used for distinguishing ROI cylinder. Identifiers are defined explicitly. edge_contact: (optional) NX_UINT (Rank: 1, Dimensions: [i]) {units=NX_UNITLESS} number_of_atoms: (optional) NX_UINT (Rank: 1, Dimensions: [i]) {units=NX_UNITLESS} The number of atoms in each ROI. number_of_ions: (optional) NX_UINT (Rank: 1, Dimensions: [i]) {units=NX_UNITLESS} The number of ions in each ROI.
there is a bug in this appdef in that the shape of these arrays must not be denoted with i because they are not necessarily the same as ofr the center and orientation arrays. Instead, these arrays have as many values (all the arrays) as are needed to visualize the ROIs using XDMF. Specifically these arrays are the geometric primitive property array whereby e.g. Paraview identifies how to color each primitive, paraprobe-toolbox==0.4 reports this situation correctly but the appdef does not reflect it yet
-
volumetric_feature
should be changed to plural "volumetric_features"
postponed because will in the future use the NXms_feature_set instances
-
@long_name: (optional) NX_CHAR @signal: (required) NX_CHAR @axes: (required) NX_CHAR @xpos_indices: (required) NX_CHAR @ypos_indices: (required) NX_CHAR @zpos_indices: (required) NX_CHAR intensity: (required) NX_FLOAT (Rank: 3, Dimensions: [n_z, n_y, n_x]) xpos: (required) NX_FLOAT (Rank: 1, Dimensions: [n_x]) Cell center of mass positions along x. ypos: (required) NX_FLOAT (Rank: 1, Dimensions: [n_y]) Cell center of mass positions along y. zpos: (required) NX_FLOAT (Rank: 1, Dimensions: [n_z]) Cell center of mass positions along z.
fix the application definition that these are rendered out correctly, in paraprobe-toolbox==0.4 these have been deactivated and will be fixed with the next bug fix release to show directly in H5Web
-
atomic_decomposition_rule: (optional) NXmatch_filter 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. method: (required) NX_CHAR 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. Any of these values: whitelist | blacklist match: (required) NX_NUMBER (Rank: 1, Dimensions: [n_atomic]) {units=NX_UNITLESS} 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. isotopic_decomposition_rule: (optional) NXmatch_filter A list of isotopes (via proton and neutron number) to consider for the isotopic_decomposition weighting model. Isotopes must exist in the nuclid 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. method: (required) NX_CHAR 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. Any of these values: whitelist | blacklist match: (required) NX_NUMBER (Rank: 1, Dimensions: [n_isotopic]) {units=NX_UNITLESS} 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.
make this all into one match filter based on isotope_vectors as these can represent elements/atoms and specific combinations of ions (molecular ions)
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename:
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
config_filename
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
The path
Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
The absolute path
Currently only the filename
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
decorating_iontypes_filter: (required) NXprocess 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. candidates: (required) NX_UINT (Rank: 1, Dimensions: [n_fct_filter_cand]) {units=NX_UNITLESS} Array of iontypes to filter. The list is interpreted as a whitelist, i.e. ions of these types are considered the decorating species (solutes).
this can be considered a bug in both the appdef and the implementation of paraprobe-parmsetup-nanochem: paraprobe-toolbox=v0.4 expects here a field named isotope_whitelist(NX_INT) of length (n_filter, 32) the docstring/meaning of decorating_iontypes_filter group is correct and how v0.4 interprets the isotope_whitelist e.g. setting a isotope_whitelist of 5, 0 ... (with 32-1 zeros following) instructs the code to take all molecular ions with boron and assume that these ions decorate the defect, a subset of the point cloud including these ions is computed and the interface model fitted
-
X, Y, Z coordinates of disjoint control point read from an HDF5 file named according to control_point_file.
what happens if these are defined in a different coordinate system? currently, it is the users responsibility to define them in the paraprobe coordinate system, Alexander Reichmann: Does your tool flip the reconstruction to accommodate for the fact that different versions of IVAS may use different local coordinate systems?
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
tessellating
should be tessellation and would be good to have e.g. NXcg_tiling base class
-
-
fairmat-experimental.github.io fairmat-experimental.github.io
-
OPTICAL_SYSTEM_EM: (optional) NXoptical_system_em camera_length: (optional) NX_NUMBER magnification: (optional) NX_NUMBER defocus: (recommended) NX_NUMBER semi_convergence_angle: (recommended) NX_NUMBER working_distance: (recommended) NX_FLOAT beam_current: (recommended) NX_FLOAT beam_current_description: (recommended) NX_CHAR
objective_lens_mode illumination_mode probe_mode image_mode field_mode spot_size or NXbeam geometry probe_size
-
value
eventually should be replaced like all other fields name value as set_point_value to communicate clearer the intention and meaning of the field
-
DATA: (optional) NXdata
add an field called data_source(NX_CHAR): an array of strings specifying which sources were parsed to fill an instance of NXem, maybe but this also in the top-level entry section next to program and program/version
-
NX_CHAR
example of a field for which one could also argue it would be useful if its type would be allowed to come from two sets, i.e. a link/reference or a string.
-
the record
should be understood as a reference to a source of pieces of information in some system (file, research data management system) which specifies further details of what happened
-
affiliation: (recommended) NX_CHAR Name of the affiliation of the user at the point in time when the experiment was performed. address: (recommended) NX_CHAR Postal address of the affiliation.
affiliation is nothing but an organization unit, maybe have it a base class like NXlocation which can then have address, name, identifier etc...
-
experiment_documentation: (optional) NXnote Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive. thumbnail: (optional) NXnote A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. A 640 x 480 pixel jpeg image is recommended. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories.
unless the data in these fields follow own documented schema this is not matching FAIR so consider to remove these entries
-
experiment_identifier: (required) NX_CHAR Ideally, a (globally) unique persistent identifier for referring to this experiment. The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals.
experiment_identifier_type https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json Better however would be to have a base class NXidentifier which then has value and type and then experiment_identifier(NXidentifier)
-
Addressing the generality versus specificity challeng
Data schemes are a graph: It is noteworthy to ....
is a graph .... NeXus specifically offers not only terms and an associated structuring of these (taxonomy) but also relations between items. This makes NeXus base classes and application definitions an ontology. Ontology and instance of ontology with real data i.e. knowledge graph are two different things. Namely the application definition specifies if a field is required or optional and thus sets constraints on their existence. Exactly these constaints though are not necessarily relevant or specific enough for specific applications.
-