314 Matching Annotations
  1. Jun 2023
    1. USER:

      Alex Reichmann's comment 2023/06/09: This could be a misleading naming convention because is it the NOMAD OASIS user or is it the creator of the specimen or is it the technician or is some other person(s)

  2. Apr 2023
    1. config_filename

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. accumulated

      this is a bug, should be named cumulated and there should be another field cumulated_normalized(NX_FLOAT) for the normalized values of the cumulated(NX_FLOAT) field

      same story for the rdf group

    1. config_filename

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. volume_volume_spatial_correlation

      this is a bug, paraprobe-toolbox will write volume_volume_spatial_correlationID

    3. time_stamp: (required) NX_DATE_TIME ISO 8601 formatted time code with local time zone offset to UTC information included when this results file was created.

      this is a bug in this appdef, paraprobe-toolbox==0.4 writes out start_time and end_time like for all other NXapm_paraprobe_results_* appdefs these timestamps are again ISO8601 compliant timestamps

    1. 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

    2. 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

    3. volumetric_feature

      should be changed to plural "volumetric_features"

      postponed because will in the future use the NXms_feature_set instances

    4. @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

    5. 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)

    6. config_filename

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    7. 3

      this has to be 4 because paraprobe-toolbox==v0.4 reports a four-column array where indeed the first three columns are the mentioned angles but the last column is the sum of the interior angles

    8. initial_interface: (optional) NX_CHAR The equation of the plane that is fitting initially. point_normal_form: (required) NX_FLOAT (Rank: 1, Dimensions: [4]) {units=NX_LENGTH} The four parameter ax + by + cz + d = 0 which define the plane.

      here is a bug in the appdef initial_interface(NXprocess) and point_normal_form is a field of this group, paraprobe-toolbox==0.4 does it correctly this way

    9. that is fitting initially.

      fitted initially

    10. ed´one

      correct formatting

    11. The multiplicity whereby the ion position is accounted for irrespective whether the ion is considered as a decorator of the interface or not.

      would need a clearer explanation

    12. whereby

      with which the ion

    13. whereby

      with which the ion

    14. charge

      this is a bug, it has to be charge_state because charge should have a unit

    15. charge

      this is a bug, it has to be charge_state because charge should have a unit

    16. :mathcal:$identifier in feature_identifier$.

      fix mathematical notation

    17. needs to be registered

      this is a bug because feature_type_dict is optional so one cannot in all cases "need to register" them, has functionally though no effect on computed results for paraprobe-toolbox==0.4

    18. i.e. not

      this is a bug and has to be removed paraprobe-toolbox==0.4 understands objects as features which need to be watertight!

    19. Triangle normals are oriented in the direction of the gradient vector of the local delocalized scalar field.

      fix mathematical notation

    20. isovalue

      make consistent with NXapm_paraprobe_config_nanochem and name phi with the next release

    21. @signal: (required) NX_CHAR @axes: (required) NX_CHAR @xpos_indices: (required) NX_CHAR @ypos_indices: (required) NX_CHAR @zpos_indices: (required) NX_CHAR @long_name: (optional) NX_CHAR intensity: (required) NX_FLOAT (Rank: 4, Dimensions: [n_z, n_y, n_x, 3]) 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

    22. The gradient vector

      add a hint that this is also for the visualization with paraview

    23. coordinate_system: (optional) NX_CHAR Reference to or definition of a coordinate system with which the positions and directions are interpretable.

      add a note what happens in case the coordinate system is not added, for paraprobe-toolbox==0.4 the default coordinate system takes precedence

    24. 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.

      this is a known bug in paraprobe-toolbox==0.4 which does not affect the functionality though, bool isosurfaceHdl::write_vxlizer_task_info_h5( vector<p3dinfo> const & iinfo ) does not report which isotope_whitelist was used, instead inspect the config file

    25. delocalization

      needs to be DELOCALIZATION

    1. config_filename

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. points

      is number_of_ions instead of number_of_points, values are correctly reported, this is a bug of this appdef (for all wall_contact_* groups)

    3. wall_contact_global:

      conditional required not implemented for NeXus

    1. config_filename

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. Usually

      Sentence has to be changed to reflect that if window_triangles is not provided it means that all triangles were taken

    3. (required)

      optional constraints not implemented yet

    1. config_filename:

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. tetrahedra: (required)

      must not be required, paraprobe-toolbox==0.4 does not report this by default

    3. dimensionality: (required) NX_POSINT {units=NX_UNITLESS}

      this should not always be repeated but instead inferred from the parent group?

    4. distin- guish

      check formatting of the NXDL to RST conversion

    1. The path

      Currently only the filename, paraprobe-toolbox==0.4 assumes that config for tool run is in the working directory

    2. charged_iontypes: (required) NX_UINT (Rank: 1, Dimensions: [n_ions]) {units=NX_UNITLESS} The iontype ID for each ion that was best matching, stored in the order of the evaporation sequence ID. For the here computed charged_iontypes the information for each (molecular) ion defined in e.g. RNG or RRNG files is analyzed for which differently charge states are possible. As an example while iontypes might only consider if an ion is Al charged_iontypes will resolve if it is Al1+, Al2+, or Al3+. To decide the charge state a recursive algorithm is used which enumerates first all possible isotopic variants of a given molecular ion build from a specific set of elements. All variants are then analyzed for their natural abundance and filtered. The sub-set of all significantly abundant variants is inspected if their charge states are all the same. If only one significant variant is found its charge state is assumed the relevant. If multiple significant variants are found and all their charge states is the same this charge state will be the decisive one. However, if multiple variants are found and their charge state differs such a case highlights that the charge state analysis is underconstrained and thus the charge state is set to 0. Underconstrained cases are possible because an arbitrary combination of elements into a molecular ion that is constrained only by an additional single interval of mass-to-charge state ratios is not necessarily sufficient.

      deprecated this field is no longer required because ions have now by default a charge state if that was recoverable via the combinatorial analyses performed by ifes_apt_tc_data_modeling package otherwise the charge_state is set to 0

    1. 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

    2. 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?

    3. piercing or laying

      pierces or is laying

    4. self-intersections can occur.

      what happens if this occurs? currently the code detects this and stops in a controlled manner so that the user can repeat the analyses with a smaller value

    5. isotope_whitelist: (required)

      conditional required currently not support by NeXus, if normalization is total paraprobe-toolbox==0.4 currently creates an empty but existent field named isotope_whitelist, this field should be removed in future version

    6. Especially this is relevant in atom probe microscopy ar

      as in atom probe tomography ...

      also a note of caution should be given that the results from fairing operations should also be compared to object populations where all objects at the edge of the dataset have been removed

    7. (2n+1)^3

      use Latex notation

    8. Ansatz kernel sigma_x = sigma_y = 2*sigma_z.

      use Latex notation

    9. Although, this uses an efficient multithreaded algorithm, the computation is costly.

      an optimization of this algorithm using a two-step procedure (explicit narrow kernel first followed by a fast fourier transform adding in quadrature) is possible but has not been implemented.

    10. 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.

      when the delocalization was computed the first place

    11. number_of_delocalizations: (required) NX_UINT {units=NX_UNITLESS} For now a support field for the tool to identify how many individual delocalization analyses for the above-mentioned dataset and supplementary files are executed as part of the high-throughput analysis.

      not needed any longer paraprobe-toolbox==0.4 detects number of groups automatically

    1. 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

    2. tilt_1: (recommended) NX_FLOAT tilt_2: (recommended) NX_FLOAT

      how they are defined should refer to an NXtransformations object which itself then refers to an instance in NXcoordinate_system_em in this way the values of tilt and position can always be interpreted and/or transformed into other representations

    3. COORDINATE_SYSTEM_SET: (recommended) NXcoordinate_system_set

      add description for NXcoordinate_system as details

    4. 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

    5. 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

    6. 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.

    7. 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

    8. 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...

    9. 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

    10. 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)

    11. 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.

    1. NXprocess

      paraprobe_toolbox==0.4 does not export this NX_class group attribute

    2. number_of_ranging_processes: (required) NX_UINT {units=NX_UNITLESS} How many range_with_existent_iontypes processes should the tool execute as part of the analysis. number_of_ion_search_processes: (required) NX_UINT {units=NX_UNITLESS} How many molecular_ion_search processes should the tool execute as part of the analysis.

      these are not used, paraprobe-toolbox==v0.4 assumes there is only a single process in this NXprocess group

    1. alpha_values: (required) NX_FLOAT (Rank: 1, Dimensions: [n_alpha_values]) {units=NX_LENGTH}

      conditionally different types of units not supported yet in NeXus, paraprobe-toolbox==0.4 currently reports alpha values with unit nm^2 (square of the radius of the carving spoon) and nm if it is the alpha for the first parameter of sets of alpha wrappings

    2. (required)

      conditional requirements not yet supported

    1. Application Definitions¶

      one bug in this version of the NXapm_paraprobe_config application definitions specifically the spatial_filter primitive sets is that they state that fields like vertices are scalars while in paraprobe-toolbox==0.4 these are arrays, this bug has no consequences though for the functioning of the v0.4 tools

    2. Application Definitions

      analysis_identifier should be made required for all NXapm_paraprobe_config/results_*

    1. roi_selection

      this is a bug, has to be ROI_SELECTION for future versions of paraprobe-toolbox, currently this group is named "process1" with which functionality-wise there is no problem for paraprobe-toolbox==0.4

    1. volume_volume_spatial_correlation

      name has to be changed to volume_volume_spatial_correlationID to reflect that this field can have more than one group

    2. feature_identifier: (required) NX_UINT

      same bug as with current_set/FEATURE/feature_identifier, has to be an array of (j,)

    3. feature_identifier: (required) NX_UINT

      this must not be a scalar but an array of length (i,)

    4. FEATURE

      should be featureID (here discussion with members from FAIRmat Area B needed)

    5. As it is detailed in M. Kühbach et al. 2022

      link to the publication, also for the same field under next_set

    6. NXcollection

      should be a set of (microstructural) features

    1. (required)

      conditional required not supported and not required for specific values of ion_query_type_source because e.g. for resolve_all it is clear that each ion will be accounted for so no need for further specifications

    2. 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

      also add how many times and ion is accounted for for resolve_all, _unknown, etc.

    3. of

      remove "of" for grammar and readability also in other places in these docstrings

    4. randomize_labels

      this field name is wrong paraprobe-toolbox==0.4 expects randomize_ion_types

    5. spatial_statistics: (optional) NXprocess

      here the application definition is incorrect, this spatial_statistics should be nested into another NXprocess group, implementation in paraprobe-toolbox==0.4 is correct but appdef does not reflect this, content inside spatial stats okay though

    1. Structure:

      paraprobe returns also "volume(NX_FLOAT)" as field unit nm^3 which is the used reconstructed volume per ion (average) from the ranging definitions file if available

    2. {units=NX_CHARGE}

      currently ifes_apt_tc_data_modeling==0.0.6 and the paraprobe-toolbox yield here no unit or eV but it should be NX_UNITLESS as it is a multiplier which specifies the charge of the ion in multiples of the elementary charge instead a new field "charge(NX_FLOAT)" should be added whose unit is C

  3. Mar 2023
    1. ION: (required) NXion isotope_vector: (required) NX_UINT nuclid_list: (recommended) NX_UINT charge_state: (required) NX_INT mass_to_charge_range: (required) NX_FLOAT

      not yet documented here is the sub_group charge_model which comes from the combinatorial analysis that is performed for each range to try to identify which charge state does this ion have

    1. Application Definitions

      terms charge and charge_state should be distinguished charge_state is the multiplier how many times an ion observable in atom probe is positively charged i.e. multiples of an electrons charge but as charge unit is Coulomb one can also argue that mass_to_charge diagram has atomic mass unit / Coulomb as its unit, however the number is the same is one talks about mass_to_charge_state_ratio where the unit then would be atomic mass unit / 1 i.e. atomic mass unit

    1. temperature

      currently a field under the snapshot than an own group

    2. grain_size_distribution

      grain_ensemble

    3. recrystallized

      recrystallization

    4. symmetry: (required) NX_CHAR cell_dimensions: (required) NX_NUMBER extent: (required) NX_POSINT identifier_offset: (required) NX_INT

      should be intended and stored in "grid"

  4. Jan 2023
    1. Therefore, the isotope_vector should be the preferred machine-readable format to use.

      or alternatively an InChi identifier

    2. Z and N have to be 8-bit unsigned integers. For the rationale behind this M. Kühbach et al. (2021)

      Add a comment that this design is too much focused on conventions useful for the research field of atom probe tomography. We appreciate there are more general descriptions like InChi which include details about the structure of the molecular ion, H-H+ is a good example https://webbook.nist.gov/cgi/inchi?ID=C12184906&Mask=1000

    3. is labelled as an ion of the here referred to ion_type.

      is on to be labelled with ion_identifier. The field is primarily of interest to document the result of indexing a ToF/mass spectrum.

    4. _state

      drop _state it is really a charge

    5. mass,

      mass number

    6. row vector

      matrix which decodes the isotope_vector

    7. Rank: 1, Dimensions: [n_ivecmax]

      rank = 2 [1, 1], [2, n_ivecmax])

  5. Dec 2022
    1. The symbols used in

      status how the experiment ended (fracture, stopped, etc.)

    2. stage_lab: (required) NXstage_lab

      evaporation control

    3. evaporation_id_included:

      use ion_sequence_id instead of evaporation_id if the evaporation_id_included probes a continuous section then this field also defines implicitly the Vstart and Vend but maybe it is better to give an own field for each

    4. reconstruction: (recommended) NXprocess

      add: atomic volume, detection efficiency, electric field (assumptions), final specimen state, pre, post image analysis,

      a reference to three images taken as recommended by cameca, before or after, radius evolution model, field factor, image compression

    5. DATA: (optional) NXdata

      default statistics would be good to report as output e.g.

      total ions (single, multiple, partial) reconstructed ions (ranged, unranged) voltage and bowl calibration (peak) mass_calibration as an own field

    6. program: (required) NX_CHAR

      several programs and libraries are usually coupled together for LEAP instruments, if it is possible to have a different root version with a different ivas/apsuite version that having a single program and version field is not enough but multiple are required

      e.g.: LAS root version camecaroot version analysis software

  6. Nov 2022
    1. atom probe and field io

      mass_calibration for stretching the raw time of flight to mass-to-charge data should be added with positions of peaks used for calibrating what exactly

    2. Application definition

      do not use evaporation_identifier but ion_sequence_number

    3. thumbnail: (optional) NXnote

      vendor_result_file(NX_CHAR): doc: | The name of an immutable file which contains the measured data in their most unprocessed form. The necessity for having such a field is that most measurements in atom probe are performed with commercial instruments for which results such as the raw time of flight and detector event data are stored in a proprietary representation (e.g. file). Examples are RHIT and HITS files whose content is not accessible with software other of the instrument manufacturer (AMETEK/Cameca). Therefore, we cannot safely assume that all relevant content from the measurement can be transcoded into a more accessible and documented digital form other than via processing the vendor_result_file with the commercial software (e.g. IVAS/APSuite) and doing so with a specific version (referred to under program/@version). Although many results from the measurement can be transcoded into more accessible formats like APT as well as ePOS or POS, this transcoding happens via the same proprietary software which may use or not numerical algorithms which are not fully documented but process the data. In effect, all relevant scientific results are affected including key results like calibrated time of flight, and thus mass-to-charge-state ratio values, and thus reconstructed ion positions and ranging definitions derived from the mass-to-charge-state ratio histogram. We are aware that not every such processing substantially modifies the data so that this would lead to substantial different numerical results. However, that is an assumption which in order to be proven demands that it is always possible to recompute the vendor_result_file using the specific version of the program in such a way that the same i.e. deterministic binary results are achieved. We have to assure that such dataset in a research data management system which rely on such proprietary procedures, irrespective how how sophisticated they are or not must keep a documentation of the provenance. Otherwise the data are not even reproducible and thus not meeting the R of the FAIR principles. Therefore, the fields program, program/@version, and vendor_result_file and /@version are required.

      For users of the NXapm application definition for which all relevant quantities can be stored using the data structures in the NXapm schema, there is factually no need for specifying a vendor_result_file. The key point is that vendor_result_file should give a statement of what is the immutable data representation of the experiment. If this is already realized via using NXapm throughout and thus there is no need for a vendor_result_file, in this case the users should store the value EXPERIMENT_NXAPM_INSTEAD_OF_PROPRIETARY under vendor_result_file and 0 for its version SHA256 checksum. The only other special case and value for vendor_result_file is that of a computer simulation of a virtual specimen with tools like TAPSim and those of the GPM and Oxford groups. In this case no measurement is performed and thus SIMULATION_NXAPM_INSTEAD_OF_PROPRIETARY should be used. \@version(NX_CHAR): doc: SHA256 checksum of that file.

  7. Oct 2022
    1. local_electrode: (required) NXlens_em

      for the invizo 6000 instrument it makes sense to add at least groups for the two additional lenses whereby the field of view is brought from 50-60 to at most 100 the key invention

      add: decelerating_electrode(NXlens_em) accelerating_mesh maybe needs an own base class

      I suggest that this section should be reworked with the local_electrode being required and all other components and opposite counter_electrodes being optional WO2016171675A1 details the key specifications of the components and the setup

    2. REFLECTRON: (required) NXreflectron

      call this energy_compensation(NXreflectron) can be a Poschenrieder lens US patent 3863068 or a reflectron US patent 6740872 the curved reflectron us patent 8134119

    3. pulser: (required) NXpulser_apm

      other sources of pulsers are possible: see in WO2016171675A1 invizo 6000 patent from ametek

    4. local_electrode: (required) NXlens_em

      also termed counter_electrode or extraction_electrode

    5. application definition, extends NXobject

      this is the relevant patent for the invizo 6000 WO2016171675A1

    6. atom_probe: (required) NXinstrument

      so far the application definition does not really cover fim as there is no place to store values for a gas injection system and a (partial) pressure sensor for the imaging gas it should be clarified in the docstring of the pressure field if this measured either a chamber total of a species partial pressure

    7. atom_probe: (required) NXinstrument

      add NXapm_energy_analyzer, a voltage grid like done in Rouen/GPM

    8. REFLECTRON: (required) NXreflectron

      https://www.youtube.com/watch?v=99hNEkqdj78t=1876s

      Eventually also add a section instrument_calibration(NXcollection) where the gridded-counter-electrode shadow image polyline fits are exported as NXcg_spline_set see also https://www.youtube.com/watch?v=99hNEkqdj78t=2348s

    9. arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 2]) {units=NX_TIME}

      eventually one may wish to store values from an NXmonitoring tracking the DLD signal amplitude (mV) = f(t)

    10. voltage_and_bowl_correction: (recommended) NXprocess

      add section for propagation_delay(NXprocess) ?

    11. raw_tof: (recommended) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_TIME} Raw time-of-flight data as read out from the acquisition software if these data are available and accessible. calibrated_tof: (required) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_TIME} Calibrated time-of-flight.

      move raw_tof and calibrated_tof under tof_calibration coming before the voltage and bowl correction add a sequence_id for each process to add which step comes first in the pipeline

    12. tof_calibration

      this should be an NXprocess m/n = 2ealpha(Vdc+beta*Vpulse)((t-t0)/L)^2 maybe a mistake in the equation?, Slide7 from the conference incorrect?

    13. flight_path_length: (required) NX_FLOAT {units=NX_LENGTH}

      add: start_voltage(NX_FLOAT) and end_voltage(NX_FLOAT), eventually also monitor Kp values from pulser etc

    14. ion_impact_positions: (recommended) NXprocess

      check also here the PYCCAPT pipeline from P. Felfer's group

    15. specimen: (required) NXsample

      addition of a NXfurnace in which one can define the atmosphere and partial pressures of the agents in that atmosphere with which the sample was annealed at which temperature see the work happening at PNNL

    16. specimen_monitoring: (recommended) NXcollection

      add an estimated_field(NXcollection) field_at_the_apex(NX_FLOAT) shape(n_ions, 1)

      maybe make this an (NXmonitor) and then also the voltage curve or all often discussed quantities can be an NXmonitor voltage_curve(NXmonitor): voltage = f(evaporation_id)

      also a monitor for Saxey plot i.e. mass correlation plots for on the same hit coming signals

    17. reconstructed_positions: (required)

      add xdmf_topology(NX_UINT) array to visualize the specimen

    18. load_lock_chamber: (optional) NXchamber

      add: a field for chamber geometry via NXcsg, also for the other chambers, add fitted field https://researchdata.edu.au/spatial-reconstruction-parameters-common-minerals/1792332

    19. specimen_monitoring: (recommended) NXcollection

      add: NXcsg to describe the specimen geometry

    20. pulsed_voltage: (recommended) NX_FLOAT standing_voltage: (recommended) NX_FLOAT

      add a default plot V = f(time/evaporation_id), essentially for each quantity

    21. NXaperture_em, NXbeam, NXchamber, NXcollection, NXcoordinate_system_set, NXdata, NXdetector, NXentry, NXfabrication, NXinstrument, NXion, NXlens_em, NXmonitor, NXnote, NXpeak, NXprocess, NXpulser_apm, NXpump, NXreflectron, NXsample, NXsource, NXstage_lab, NXtransformations, NXuser

      add a base class for spatial statistics / correlation statistics SRO equations, kNN, RDF, n-point statistics

    22. parameter: (required) NX_CHAR

      image compression factor(NX_FLOAT), dimensionless, ICF kf field factor NX_FLOAT, dimensionless ?

    23. MONITOR: (optional) NXmonitor

      NXapm_detector_stack as a base class which has then - NXdata for the stack - possibility for instances of NXcg_circle_set to mark positions of specific peaks - add NXcg_circle_set for each circle would be nice to have a place where one can store LaTeX-formatted UTF-8 text - conceptualize also a default plot for overlaying a stereographic or equidistant projection

    24. ion_detector: (required) NXdetector

      detection_rate but is this not the target_detection_rate ?

    25. pulse_fraction: (required) NX_FLOAT

      move to laser_gun

    26. pulse_frequency: (required) NX_FLOAT

      is this the pulse_rate?

    27. specimen: (required) NXsample

      it would be good to have an application definition NXicp for chemical composition

    28. Metadata and numerical data of the atom probe and the lab in which it stands.

      electric_field_estimation(NXprocess) or something like this to describe the details of the Kingham curve analyses differently charged ion ratio = f(evaporation_id)

    29. local_electrode:

      see https://en.wikipedia.org/wiki/Einzel_lens for details double einzel lens in the invizo 6000 according to A. Breen (UNSW)

    30. charge_state: (required) NX_INT

      this has to be improved, interview atom probers on how they add the charge state or know the charge state

    31. field_of_view: (recommended) NX_FLOAT {units=NX_LENGTH}

      add target_detection_rate(NX_FLOAT)

    32. laser_gun: (recommended) NXsource

      rename to LASER_SOURCE because the Invizo 6000 has a dual laser or should the dual laser be considered as one component

    33. atom_probe: (required) NXinstrument

      NXdecelerating_mesh and check counter-electrode again

    1. stage_lab: (required) NXstage_lab
    2. em_lab: (required) NXinstrument

      Add a specific cryo_transfer(NXchamber)

    3. EVENT_DATA_EM: (required) NXevent_data_em

      A key question raise by the https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/SEM_schema.json schema proposal is how to handle correlative results. My personal opinion is that this is should be thought and stored in such a way that data are automatically correlateable. Take an example. A frequent situation in SEM is the beam scans a ROI while n detectors take different signal. In this case usually the control software/tools of the individual detectors either assures that the collection of the signals is already synced or it has to be synced later. Syncing later can essentially happen if one e.g. collects data at such a high frame rate that only an additional hardware tool can manage the stream of incoming data and these come with an own time code. And thats the point if the signals individually have a time-code they should be stored such that we can get an answer for, when was the beam illuminating what and what during that point/interval was happening with each detector. Maybe a 1d, 2d, signal was captured. In this way we leave it open from a data modeling point of view to say that the results form a collection of signals which can be used for correlative analyses. Instead we have a description which a machine can understand by arranging the signal streams on the time axis and if we then ask, are there pieces of information / signals within time [t, t + deltat] what is available? With this we discuss the important case of correlation analysis not just from the perspective of what the research intended but we give already all these pieces of information which somebody else would need if one were to repurpose the data for a different study. In this case either we get an answer if we have detector readings for [t, delta +t ] if yes, we can use these data, if not there is likely no algorithm that can recover these data as they simply havent measured

      if then a certain parser already aggegates the time stamped data and syncs them so that the scientists gets an easier representation for the study for which the measurement was originally performed this is an additional advantage but storing only this already "synced" data makes the representation unnecessarily limited wrt to possible repurposability of the data. https://www.cambridge.org/core/journals/microscopy-and-microanalysis/article/5dstem-live-processing-and-display-at-15000-diffraction-patterns-per-second/ACE6E17B131FC599D731310BFDB2D227

    4. IBEAM_COLUMN

      angle to the electron beam gun pressure, gas injection system (maybe a base class) deposition_current, deposition_size, deposition_time

    5. em_lab: (required) NXinstrument

      electron beam deceleration is currently not handled, landing_energy, stage_bias, e.g. also grid in front of SE detectors

    6. IMAGE_SET_

      instances of NXimage_set should have a field for the tilt_correction in the case of se detectors

    7. sample: (required) NXsample

      additional descriptions can be added such as the shape and form of the sample as additional named field but it would be better to use instances of e.g. NXcg_ base classes as these have many of the shape and geometrical descriptors already included but can, if people want be optionally made immediately as specific as that the exact shape and geometry of the sample and all possible ROIs on the sample are well described in a consistent and documented coordinate system

    8. NXspectrum_set_em_eels

      It would be better to disentangle the spectrometer from the instrument as yes it is a detector but usually is an own complicated piece of equipment with many details lenses and parts. It does certainly not harm to group this "set" of components under detector as one could then add (in addition to the already existent fields in NXdetector add also again an entire construction plan of the spectrometer if needed however from the perspective of an application definition most of these cannot be made required because if then one user has also a spectrometer but again one field is different it would need another application definition this makes clear that constraints on the nodes in the hierarchy of NeXus have to be disentangled from the definitions

    9. SPECTRUM_SET_EM_EELS: (optional)

      in https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json a number of eels details are specified which can all be stored in an instance of NXimage_set_em_eels

      spectrometer details though should be placed under detector as the spectrometer is nothing but an own detector + maybe additional pieces of information

    10. em_lab: (required) NXinstrument

      add NXscanbox_em as this could then hold all relevant settings when the image was taken i.e. scan details

    11. em_lab: (required) NXinstrument

      add an NXdeflector_em which can be passed as an additional component of the gun, https://www.jeol.com/words/emterms/20160713.103817.php currently the idea behind NXscanbox_em is rather https://www.globalsino.com/EM/page4225.html the electron deflection/scanning coil (the one with the brownish arrow on the figure)

      precession is a particular operation mode of the NXscanbox_em for which one should place the angle, frequency and details in the NXscanbox_em

      for Astar is this a particular hardware component talking to the scanbox ? in this case astar parameters should be added as fields of an instance of a base class https://nanomegas.com/precession-electron-diffractionand-applications/#

    12. em_lab: (required) NXinstrument
    13. APERTURE_EM: (recommended) NXaperture_em value: (required) NX_NUMBER

      value is often a set value in the control software whereby one can pick a specifically shaped so-and-so large aperture there are two approaches to this: either one stores the set_point_value like possible right now (which has value for somebody going back to the microscope but which is problematic because values are not comparable directly) maybe better store diameter or radius or some geometric measure of the aperture (problem here is that also this is not comparable for most people but thanks to having a fabrication one could store the aperture identifier and with this know exactly what one talks about,

      Users should also note that each base class can also use an attached NXtransformations which would allow to locate the aperture as a technical component in the microscope and with this use an application definition to describe also an entire construction plan of the microscope

    14. electron_gun: (required) NXsource

      lifetime of the source in Ah

    15. electron_gun: (required) NXsource

      rename to electron_source and ion_gun rename to ion_source

      then details about the source in a particular place should better be stored under electron_source (NXbeam) and at this position one has measured a current, a current density a beam energy etc

    16. em_lab: (required) NXinstrument

      add an instance of NXmonochromator all properties under monochromator details could then be placed under (NXmonochromator)

      https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json

    17. em_lab: (required) NXinstrument

      Would profit from chamber state values like pressure coming from an NXsensor or plain field

      e.g. omega_filter(NXmonochromator)

    18. sample: (required) NXsample A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms.

      it might be intersting to store if the sample is conductive, magnetic, or beam sensitive the problem with these statements is they are all qualitative, how would one filter for this i.e. show me all those measurements with so and so beam sensitive material, when do I switch the boolean on or off, if this can be quantified like conductivity, coercivity, ... etc that might be better but we know that for practical EM operations oftentimes qualitative statements are sufficient

      https://raw.githubusercontent.com/kit-data-manager/Metadata-Schemas-for-Materials-Science/main/TEM_schema.json what is final specimen? for plasma cleaning one should have an own appdef what to fill in storage conditions? ion sensitivity well like electron sensivity I see value of having such fields the probelm I have with this (all here my personal opinion) is that how do you know that sth is sensitive, common knowledge, results from other analyses? fact is assuming a sample to be sensititive is a model according to previously gained knowledge, if one would probe for this knowledge during the experiment one could have a measurement where these evidences are collected and then the statement about sensitivity inferred later

      Plasma cleaning, this is clearly a processing step:

      (NXplasma_cleaning): gas_composition(NX_NUMBER)(1): gas_species(NXion)(2): power(NX_NUMBER)(3): percent_power(NX_NUMBER)(4): duration(NX_TIME)(5):

      constraints: shape(i) == (n,) forall i in [1, 2]

    19. INTERACTION_VOL_EM: (optional) NXinteraction_vol_em

      currently has no fields but should get some when there is a specific example

    20. SPECTRUM_SET_EM

      All NXspectrum_set_em will get a field intention(NX_CHAR) with values to pick form an enumeration of controlled intention e.g. xreay, eels, auger, cathodolum

      but then there is the possibility to add method-post-processing specific base classes of what will be essentially NXprocesses to describe and document how the data were post-processed

    21. IMAGE_SET_

      All NXimage_set_em will get a field method(NX_CHAR) with values to pick form an enumeration of controlled intention e.g. se, bse, bf, df, adf, kikuchi, ecci, sad, nbed, ronchigram, chamber,

      but then there is the possibility to add method-post-processing specific base classes of what will be essentially NXprocesses to describe and document how the data were post-processed

    22. detector_identifier: (recommended) NX_CHAR The detector or set of detectors that was used to collect this signal. The name of the detector has to match one of the names of available NXdetector instances e.g. if the instrument has an ebsd_camera the detector for an NXimage_em_kikuchi should be the NXdetector instance called ebsd_camera.

      Will be moved to the individual NXimage_set_em and NXspectrum_set_em base classes

    23. start_time: (recommended) NX_DATE_TIME

      hint on iso with local time zone and again stating that for all settings they are assumed constant in between [start_time, end_time]

    24. systems

      and RDMS

    25. vendors

      technology partners

    26. a

      an open

    27. vendors

      technology partners

    28. This is in partly a consequence of vendor which store detailed time data in different formats

      remove

    29. track

      format metadata like

    30. processing, and during the microscope session

      its processing, and the microscope session in general.

    31. w

      ,

    32. the materials database.

      or research data management system (RDMS) introduce abbrev earlier.

    33. like

      details like

    34. image_set_em or spectra_set_em

      NX and NX

    35. , users

    36. dynamically, coveringly enough i

      documented covering enough.

    37. dviced

      given the advice to keep the original files. Make that sentence in bold. The more a schema like NXem establishes the more likely it could be that technology partners will be motivated to offer parsers that export to this format and in this case eventually it may no longer be needed to store the original files.

    38. vendor-

      specific files

    39. y

      frequent case

    40. vendor-overarching

      common

    41. m

      the

    42. an

      of an

    43. s one event, i.e. a point in time

      during the event

    1. NXapm:

      also an NXapm_pl would be possible, as soon as NXluminescence by Carola Emminger and Florian Dobner is ready whereby then there would be two subentries one for an NXapm and one for NXphotoluminesence to capture the photonic atom probe of Rouen/GPM

      and finally if there were an NXafm for atomic force microscopy the IMEC AFM/APT experiments could be stored with an NXapm_afm application definition with NXapm and NXafm being respective subentries of the appdef but as NXapm_afm is a step-by-step approach one would have to release the constraint that only a single measurement can be performed.

    2. NXapm:

      NXasat should be a fuse of NXapm and NXem within an NXentry with NXsubentry, in this way we can combine the strength of both application definitions to describe also the upcoming technique of "atomic scale analytical tomography" https://doi.org/10.1017/9781316677292

    3. NXapm:

      TKD should be reflected also with an NXimage_set_em_tkd within NXem