2.3.3.2.1. NXapm

Status:

application definition, extends NXobject

Description:

Application definition for real or simulated atom probe and field-ion microscopy ...

Application definition for real or simulated atom probe and field-ion microscopy experiments.

Atom probe tomography and field-ion microscopy are methods for characterizing materials through induced controlled extraction of individual atoms as ions and molecular ions from a sharp needle-shaped specimen.

Offering isotopic and nanometer-scale resolution, atom probe data enable quantification of local chemical composition and computing of volumetric reconstructions which are models for the atomic architecture of the small specimen volume analyzed. These reconstructions provide input for characterization of atomic segregation at crystal defects. The term microstructural features is considered as a narrow synonym for crystal defects.

The aim of the NXapm application definition is to provide a general yet specific enough solution to serialize artifacts for virtually all atom probe and field-ion microcopy experiments.

Before summarizing the design of the base classes and the parts of the NXapm application definition, it is worthwhile to recall and distinguish concepts that are related to atom extraction events and the molecular ions that are frequently generated by the sequence of events:

  • An atom probe instrument uses laser or voltage pulsing events to trigger ion extraction events.

  • These ions are accelerated in an electric field towards a position-sensitive detector system. Physical events and corresponding signal on this detector is triggered by an ion hitting the detector. Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event.

  • Note that only a part the specimen volume can be measured and finite detection efficiency means that not all atoms in the measured volume will be detected. Neutral atoms can escape detection. Some ions escape detection because they hit into walls of the analysis_chamber.

Raw data are typically processed as follows:

  • Detector pulses and their timing are processed and discriminated into signal events of different quality levels. High quality events might be considered in further processing to identify the corresponding molecular ion and its original position in the reconstructed volume.

  • Signal calibration and filtering steps are applied to convert raw time-of-flight data to calibrated mass-to-charge state ratio values and obtain calibrated impact positions on the detector.

  • Ranging and identifying an ion that corresponds to each detector event. Isotopic abundance and theoretical models inform these ranging algorithms.

  • Finally, such selected ion impact positions and iontypes are used to compute a reconstructed volume of the specimen using backprojection algorithms. In effect, an atom probe measurement is a combination of a data acquisition and a data analysis workflow.

Not only in AMETEK/Cameca’s APSuite/IVAS software, which the majority of atom probers use, these concepts are well distinguished. However, the algorithms used to transform correlations between pulses and physical events into actual events, the so-called detector hits of ions, is a proprietary one. This algorithm is also referred to as the hit finding algorithm.

Due to this practical inaccessibility of details, virtually all atom probe studies currently use a reporting schema where the course of the specimen evaporation is documented such that quantities are a function of evaporation_id i.e. actual event/ion, i.e. after having the hit finding algorithm and correlations applied. That is the evaporation_id values take the role of an implicit time and course of the experiment given that ion extraction physically is a sequential process.

This application definition includes fields that the atom probe community has decided to represent best practices for reporting atom probe measurements. Exemplar mapping tables are provided for documents that reported these best practices to translate technical term into concepts of the NXapm application definition.

The NeXus application definition NXapm defines a hierarchical data model with ten building blocks:

The data model represents a tree of concepts. The tree is constructed from groups of concepts representing the branches, together with fields and attributes representing leaves. NXapm is defined by composing and specializing base classes into the following ten categories:

  • The field definition specifies that the data schema is NXapm. In combination with administrative metadata such as the attribute NeXus_version provided by NXroot this specifies which version of NXapm the instance data in a NeXus/HDF5 file are compliant with.

  • The fields run_number, experiment_alias, experiment_description and the group userID provide concepts for storing organizational metadata that contextualize the work within the research workflow and humans involved in this.

  • The fields start_time, end_time provide concepts for framing a temporal context for the research.

  • The groups citeID, noteID provide concepts for adding contextual details such as citations or notes that are associated with the data, i.e. other artifacts that are deemed relevant when reporting about a measurement or simulation. These groups are useful when NXapm is used as a serialization format for technology-partner-agnostic archival of data and metadata that have been collected during a session with an atom probe instrument. The terms run and session are understood as exact synonyms that refer to an uninterrupted period of measurement. Resuming measurement on a specimen after an interruption is viewed as a new run and the new data should not be appended to the previous run, but written to either a new NXentry, or a new file. Removing the specimen from the instrument is an interruption. Changing evaporation conditions while the specimen is remains in the analysis_chamber and resuming thereafter the measurement is not considered as an interruption. It is a common strategy to probe the evaporation process for different instrument parameters. Each individual collection should then though be stored in an own NXapm_event_data group. Parking the specimen to the buffer_chamber and resuming the measurement at a later stage is an interruption. During a run, the microscope is used for a certain amount of time to characterize a single specimen.

  • The groups sample and specimen provide concepts for storing metadata about the sample and the specimen, i.e. the smaller part that was removed from the sample to be measured in the atom probe session. The term “tip” in the context of atom probe research is considered jargon. Specimen is an exact synonym for tip.

  • The field operation_mode and group measurement provides concepts that are useful for describing a measurement during a session with an atom probe or field-ion microscope. This includes the chain of events of data and metadata that were collected during such a session.

  • The group simulation provides concepts that are useful for describing a simulation of an atom extraction, ionization, and ion trajectory simulation. Combined with measurement this provides a data schema for defining a digital twin of the instrument and its setup.

  • The groups consistent_rotations, and NAMED_reference_frame provide concepts for reporting coordinate systems (frames of reference) and rotation conventions that clarify how data should be interpreted specifying the rotation of orientable objects in the microscope, its components, or of crystals and crystal defects in the material analyzed.

  • The group atom_probeID provides concepts for the computational workflows that were used to convert raw detector data into reconstructed ion positions and documentation of ranging definitions made.

  • The group profiling provides concepts for reporting computational details such as programs and libraries used, for documenting the libraries of virtual environments such as those used by conda or python virtual environment, including details about the computing hardware used, and documenting capabilities for performance analyses and benchmarking of the software or its parts.

Design choices:

Given that most atom probe instruments across the globe were built by AMETEK/Cameca and are delivered with the AP Suite/IVAS software there is some homogeneity in how a measurement is performed and which data artifacts and algorithms used for data processing. Complementary use of open-source software specifically for the reconstruction, ranging, and later data processing stages contributes to a landscape of multiple tools in use. Therefore, communication of atom probe research differs between user groups. This holds even more so true for the sub community in atom probe which study physical mechanisms involved during ionization to the point that here that almost each research work defines different simulation tools with different types of data artifacts.

NXapm defines constraints on the existence and cardinality of concepts and its concept branches but seeks to offer a compromise. The key design pattern followed is that most branches are made optional or at most recommended but their child concepts are conditionally required. Thereby, NXapm can cover a variety of simple but also complex use cases. An example of this parent-optional-but-childs-stronger-restricted design is the combination of the optional group measurement with its required child measurement/instrument: Users which report simulations are not forced to document the instrument but users which have characterized a specimen are motivated to report about the instrument. They are though not necessarily required to report all the details of the instruments’ components because the design pattern is applied recursively.

NXapm distinguishes and stores instance data based on how long they remain unchanged:

measurement provides two groups measurement/instrument and measurement/eventID. The first group is designed for storing metadata about the instrument that do not change over the course of the session. Examples are the name of the technology partner who built the microscope or whether a laser or voltage pulser and reflectron exists or not. The second group is designed for metadata and data that are collected during the session with the instrument. These, are stored as instances of measurement/eventID, events that can be time-stamped individually. Each instance of a group measurement/eventID contains measurement/instrument whose purpose is to store those specific state and settings of the instrument that was present during the collection of the event. Thereby, changing conditions such as campaigns with different target detection rate can be stored.

Noteworthy, such an approach of the atom probe detecting groups of events and storing these as groups has also been in use in the proprietary software via CamecaRoot, a set of customized data structures and file formats that use the CernRoot library. By virtue of design this reduces unnecessary repetition of metadata stored in the first group.

atom_probeID offer classes for the each task relevant task in the data processing pipeline that converts raw detector event data to calibrated mass-to-charge-state-ratio values and hit_position on the detector. These include initial_specimen, and final_specimen locations for storing images of the specimen prior/after the measurement as considered best practice by AMETEK/Cameca, raw_data for delay-line timing data, hit_finding for details of the hit finding algorithm, hit_spatial_filtering a process that filters hits of too low quality and those laying outside the about to be computed reconstruction volume. Furthermore, group voltage_and_bowl offers a place for documenting calibrations and processing non-linearities. Group mass_to_charge_conversion is used to document the mass calibration and the conversion from time-of-flight to mass-to-charge-state-ratio values.

Finally, the groups reconstruction and ranging were designed to match and document the classical approaches how from all the previous sources of input one can compute a reconstructed volume, and apply peak fitting routines on the mass-to-charge-state-ratio histogram to label ions, i.e. range them for their isotopic identity. Group atom_probeID/reconstruction/naive_discretization offers a standardized way to report simple three-dimensional histograms. Group atom_probeID/ranging/peak_identification/ionID and its complementing group atom_probeID/ranging/peak_identification/ionID/charge_state_analysis solves the issue that the ranging definitions in classical file formats are not reported for always for their isotopic identity and charge state. The field atom_probeID/ranging/peak_identification/iontypes provides a place for storing a compact representation of the results of each ranging definition made at the level of each ion.

The compatibility of NXapm and NXem:*

The design of NXapm mirrors that of NXem. This was an intentional choice to support the increasingly stronger connection between these two materials characterization methods, especially in light of recent advances in the direct coupling of atom probe and transmission electron microscopes and scanning transmission electron microscopes.

Symbols:

The symbols used in the schema to specify e.g. dimensions of arrays.

n_ht: Number of hit qualities, the so-called hit types, distinguished.

n_dld: Number of delay-line-detector (DLD) wires of the detector.

n_bins: Number of bins used in the mass-to-charge-state-ratio spectrum.

p: Number of pulses collected in between start_time and end_time resolved by an instance of NXapm_event_data. If this is not defined, p is the number of ions included in the reconstructed volume if the application definition is used to store results of an already reconstructed dataset.

p_out: Number of pulses returned by the hit_finding algorithm. Neither necessarily equal to p nor to n.

n: Number of ions spatially filtered from results of the hit_finding algorithm from which an instance of a reconstructed volume has been generated. These ions get new identifier assigned in the process, the so-called evaporation_id. This identifier must not be confused with the pulse_id. This value is typically smaller than both p and p_out.

m_r: Number of mass resolution values.

Groups cited:

NXapm_charge_state_analysis, NXapm_event_data, NXapm_instrument, NXapm_measurement, NXapm_ranging, NXapm_reconstruction, NXapm_simulation, NXatom, NXchemical_composition, NXcite, NXcollection, NXcomponent, NXcoordinate_system, NXcs_filter_boolean_mask, NXcs_profiling, NXdata, NXdetector, NXelectromagnetic_lens, NXentry, NXfabrication, NXimage, NXmanipulator, NXnote, NXparameters, NXpeak, NXprocess, NXprogram, NXpump, NXroi_process, NXsample, NXsensor, NXsource, NXuser

Structure:

ENTRY: (required) NXentry

definition: (required) NX_CHAR ⤆

Obligatory value: NXapm

@version: (optional) NX_CHAR ⤆

run_number: (recommended) NX_UINT {units=NX_UNITLESS}

The identifier whereby the experiment is referred to in the control software ...

The identifier whereby the experiment is referred to in the control software.

It is common practice in atom probe research to refer to a measurement on a single specimen as a run. When working with AMETEK/Cameca instruments it is a common practice also to store all data associated with such a run in files whose name is composed from a prefix that details the type of instrument (e.g. R5076) followed by the run_number. These filenames are often used as the specimen_name or experiment_identifier. The terms run and session are understood as exact synonyms.

For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments at GPM in Rouen, use the identifier which matches best conceptually to the LEAP run number.

The field does not have to be required, if the information is recoverable in the dataset which for LEAP instruments is the case; provided these RHIT or HITS files respectively are stored alongside a data artifact. With NXapm the RHIT or HITS can be stored via NXnote in the hit_finding algorithm section.

As a destructive microscopy technique, a run can be performed only once. It is possible, however, to interrupt a run and restart data acquisition while still using the same specimen. In this case, each evaporation run needs to be distinguished with different run numbers. We follow this habit of most atom probe groups. Such interrupted runs should be stored as individual NXentry instances in one NeXus file.

experiment_alias: (optional) NX_CHAR

Alias or short name which scientists can use to refer to this experiment.

experiment_description: (optional) NX_CHAR ⤆

Free-text description about the experiment. ...

Free-text description about the experiment.

Users are strongly advised to parameterize the description of their experiment by using respective groups and fields and base classes instead of writing prose into the field.

start_time: (required) NX_DATE_TIME ⤆

ISO 8601 time code with local time zone offset to UTC information ...

ISO 8601 time code with local time zone offset to UTC information included when the atom probe session started. If the exact duration of the measurement is not relevant, start_time only should be used.

The start_time is required in order to ensure that at least one point in time is provided for full temporal context to a measurement and simulation when writing instance data using NXapm. Otherwise, the instance data can not be sorted in order or even placed in a logical sequence to other steps of the research workflow, which would disallow using functionalities in research data management systems that rely on temporal context.

Specifying start_time and end_time is useful for capturing more detailed bookkeeping of the experiment. The user should be aware that even with having both dates specified, it may not be possible to infer how long the experiment took or for how long data were collected.

More detailed timing data over the course of the experiment have to be collected to compute this event chain during the experiment. For this purpose the NXapm_event_data instance should be used.

end_time: (recommended) NX_DATE_TIME ⤆

ISO 8601 time code with local time zone offset to UTC included ...

ISO 8601 time code with local time zone offset to UTC included when the atom probe session ended.

Writing the end_time can be a tricky in practice. If written at the start of the experiment, it can only be an estimate. If written at the end, there is the risk for having the computer crash or lose power. The absence of end_time should not be interpreted as that the experiment was aborted. Only, the field status should be used for communicating such abortion.

elapsed_time: (recommended) NX_FLOAT {units=NX_TIME}

How long did the measurement take e.g. use CRunHeader.CAnalysis.fElapsedTime

operation_mode: (required) NX_CHAR

What type of atom probe experiment is performed to inform research data mana ...

What type of atom probe experiment is performed to inform research data management systems and allow filtering:

  • apt are experiments where the analysis_chamber has no imaging gas. Experiments with LEAP instruments are typically with this operation_mode.

  • fim are experiments where the analysis_chamber has an imaging gas, which should be specified with the atmosphere in the analysis_chamber group.

  • apt_fim should be used for combinations of the two imaging modes. Few experiments of this type have been performed, as it can be detrimental to LEAP systems (see S. Katnagallu et al.).

Any of these values or a custom value (if you use a custom value, also set @custom=True): apt | fim | apt_fim

profiling: (optional) NXcs_profiling

The configuration of the software that was used to generate this NeXus file.

programID: (optional) NXprogram

A collection of all programs and libraries which are considered relevant ...

A collection of all programs and libraries which are considered relevant to understand with which software tools this NeXus file instance was generated. Ideally, to enable a binary recreation from the input data.

Examples include the name and version of the libraries used to write the instance. Ideally, the software which writes these NXprogram instances also includes the version of the set of NeXus classes i.e. the specific set of base classes, application definitions, and contributed definitions with which the here described concepts can be resolved.

For the pynxtools library which is used by the NOMAD research data management system, it makes sense to store e.g. the GitHub repository commit and respective submodule references used.

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

environment: (recommended) NXcollection ⤆

Programs and libraries representing the computational environment

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

citeID: (optional) NXcite

author: (optional) NX_CHAR

The author(s) of that reference.

doi: (required) NX_CHAR ⤆

noteID: (optional) NXnote ⤆

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

userID: (recommended) NXuser ⤆

identifierNAME: (recommended) NX_CHAR ⤆

@type: (required) NX_CHAR ⤆

name: (optional) NX_CHAR ⤆

sample: (recommended) NXsample ⤆

Description of the sample from which the specimen was prepared or ...

Description of the sample from which the specimen was prepared or site-specifically cut out using e.g. a focused-ion beam instrument.

In NXapm, a measurement is performed on a specimen. Since APM specimens are very small, they are typically cut from a larger object with some scientific significance, which NXapm refers to as a sample.

identifierNAME: (recommended) NX_CHAR ⤆

is_simulation: (required) NX_BOOLEAN

False, if the sample is a real one. ...

False, if the sample is a real one. True, if the sample is a virtual one.

alias: (required) NX_CHAR

Given name/alias for the sample.

grain_diameter: (optional) NX_FLOAT {units=NX_LENGTH}

Qualitative information about the grain size, here specifically ...

Qualitative information about the grain size, here specifically described as the equivalent spherical diameter of an assumed average grain size for the crystal ensemble.

If the specimen does not contain many crystals average values might be an unreliable descriptor.

Reporting a grain size may be useful though as it allows judging if specific features are expected to be found in the detector hit map.

grain_diameter_errors: (optional) NX_FLOAT {units=NX_LENGTH}

Magnitude of the standard deviation of the grain_diameter.

heat_treatment_time: (optional) NX_FLOAT {units=NX_TIME}

An array of elapsed time, the independent axis, of a time-temperature curv ...

An array of elapsed time, the independent axis, of a time-temperature curve.

This field can be used in combination with heat_treatment_temperature and heat_treatment_temperature_errors as well as heat_treatment_quenching_rate and heat_treatment_quenching_rate_errors respectively. In this case, these fields should also be stored as an array with the same dimensions as heat_treatment_time to store the dependant axes of a time-temperature curve as well as its first derivative.

heat_treatment_temperature: (optional) NX_FLOAT {units=NX_TEMPERATURE}

If heat_treatment_time is absent, the temperature of the last heat treatme ...

If heat_treatment_time is absent, the temperature of the last heat treatment step before quenching.

Knowledge about this value can give an idea how the sample was heat treated. However, if a documentation of the annealing treatment as a function of time is available one should better rely on this information and have it stored alongside the NeXus file.

If heat_treatment_time is provided, the temperature. Consult the docstring of heat_treatment_time.

heat_treatment_temperature_errors: (optional) NX_FLOAT {units=NX_TEMPERATURE}

Magnitude of the standard deviation of the heat_treatment_temperature. ...

Magnitude of the standard deviation of the heat_treatment_temperature.

If heat_treatment_time is provided, the magnitude of the standard derivation of the temperature. Consult the docstring of heat_treatment_time.

heat_treatment_quenching_rate: (optional) NX_FLOAT {units=NX_ANY}

If heat_treatment_time is absent, the rate of the last quenching step. ...

If heat_treatment_time is absent, the rate of the last quenching step.

Knowledge about this value can give an idea how the sample was heat treated. However, there are many situations where one can imagine that the scalar value for just the quenching rate is insufficient.

If heat_treatment_time is provided, the first derivative of the time-temperature curve. Consult the docstring of heat_treatment_time for further details.

heat_treatment_quenching_rate_errors: (optional) NX_FLOAT {units=NX_ANY}

Magnitude of the standard deviation of the heat_treatment_quenching_rate. ...

Magnitude of the standard deviation of the heat_treatment_quenching_rate.

If heat_treatment_time is provided, the magnitude of the standard deviation of the first derivative of the time-temperature curve. Consult the docstring of heat_treatment_time for further details.

description: (optional) NX_CHAR ⤆

chemical_composition: (recommended) NXchemical_composition

The chemical composition of the sample. ...

The chemical composition of the sample.

Typically, it is assumed that this more macroscopic composition is representative for the material so that the composition of the typically substantially less voluminous specimen probes from the more voluminous sample.

normalization: (required) NX_CHAR ⤆

ELEMENT: (required) NXatom ⤆

chemical_symbol: (required) NX_CHAR

composition: (required) NX_FLOAT ⤆

composition_errors: (recommended) NX_FLOAT ⤆

specimen: (required) NXsample ⤆

Description of the specimen that was cut off from the sample. ...

Description of the specimen that was cut off from the sample.

In atom probe jargon this is typically referred to as the tip.

identifierNAME: (recommended) NX_CHAR ⤆

is_simulation: (required) NX_BOOLEAN

False, if the specimen is a real one. ...

False, if the specimen is a real one. True, if the specimen is a virtual one.

alias: (recommended) NX_CHAR

Given name or an alias. Better use identifierNAME and identifier_parent in ...

Given name or an alias. Better use identifierNAME and identifier_parent instead.

A single NXentry should be used only for the characterization of a single specimen.

identifier_parent: (recommended) NX_CHAR ⤆

Identifier of the sample from which the specimen was cut or the string "n/ ...

Identifier of the sample from which the specimen was cut or the string “n/a”.

The purpose of this field is to support functionalities for tracking sample provenance via a research data management system.

preparation_date: (recommended) NX_DATE_TIME ⤆

ISO 8601 time code with local time zone offset to UTC information ...

ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared.

Ideally, report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Ideally, this matches the last timestamp that is mentioned in the digital resource pointed to by identifier_parent.

Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen charged specimens or experiments including tracers with a short half time.

atom_types: (required) NX_CHAR

List of comma-separated elements from the IUPAC periodic table that are ...

List of comma-separated elements from the IUPAC 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.

description: (optional) NX_CHAR ⤆

Discouraged free-text field.

is_polycrystalline: (recommended) NX_BOOLEAN

True, if the specimen contains a grain or phase boundary. ...

True, if the specimen contains a grain or phase boundary. False, if the specimen is a single crystal.

is_amorphous: (recommended) NX_BOOLEAN

True, if the specimen is amorphous. ...

True, if the specimen is amorphous. False, if the specimen is not.

initial_radius: (recommended) NX_FLOAT {units=NX_LENGTH}

Ideally measured otherwise best elaborated guess of the initial radius of ...

Ideally measured otherwise best elaborated guess of the initial radius of the specimen.

shank_angle: (recommended) NX_FLOAT {units=NX_ANGLE}

Ideally measured, otherwise best estimate, of the initial shank angle. ...

Ideally measured, otherwise best estimate, of the initial shank angle.

This is a measure of the specimen taper. Define it in such a way that the base of the specimen is modelled as a conical frustrum so that the shank angle is the smallest angle between the specimen space z-axis and a vector on the lateral surface of the cone.

consistent_rotations: (recommended) NXparameters ⤆

The conventions used when reporting crystal orientations. ...

The conventions used when reporting crystal orientations. We follow the best practices of the Material Science community that are defined in reference https://doi.org/10.1088/0965-0393/23/8/083501.

rotation_handedness: (required) NX_CHAR

Convention how a positive rotation angle is defined when viewing ...

Convention how a positive rotation angle is defined when viewing from the end of the rotation unit vector towards its origin. This is in accordance with convention 2 of reference https://doi.org/10.1088/0965-0393/23/8/083501.

Counter_clockwise is equivalent to a right-handed choice. Clockwise is equivalent to a left-handed choice.

Any of these values: counter_clockwise | clockwise

rotation_convention: (required) NX_CHAR

How are rotations interpreted into an orientation according to convention ...

How are rotations interpreted into an orientation according to convention 3 of reference https://doi.org/10.1088/0965-0393/23/8/083501.

Any of these values: passive | active

euler_angle_convention: (required) NX_CHAR

How are Euler angles interpreted given that there are several choices e.g. ...

How are Euler angles interpreted given that there are several choices e.g. zxz, xyz according to convention 4 of reference https://doi.org/10.1088/0965-0393/23/8/083501.

The most frequently used convention in Materials Science is zxz, which is based on the work of H.-J. Bunge but using other conventions is possible. Proper Euler angles are distinguished from Tait-Bryan angles.

Any of these values:

  • zxz

  • xyx

  • yzy

  • zyz

  • xzx

  • yxy

  • xyz

  • yzx

  • zxy

  • xzy

  • zyx

  • yxz

axis_angle_convention: (required) NX_CHAR

To which angular range is the rotation angle argument of an ...

To which angular range is the rotation angle argument of an axis-angle pair parameterization constrained according to convention 5 of reference https://doi.org/10.1088/0965-0393/23/8/083501.

Obligatory value: rotation_angle_on_interval_zero_to_pi

sign_convention: (required) NX_CHAR

Which sign convention is followed when converting orientations ...

Which sign convention is followed when converting orientations between different parametrizations/representations according to convention 6 of reference https://doi.org/10.1088/0965-0393/23/8/083501.

Any of these values: p_plus_one | p_minus_one

NAMED_reference_frameID: (required) NXcoordinate_system

A coordinate system. Multiple instances require unique names. ...

A coordinate system. Multiple instances require unique names.

Several Euclidean coordinate systems (CS) are used in the field of atom probe:

  • World space; a CS specifying a local coordinate system of the planet earth which identifies into which direction gravity is pointing such that the laboratory space CS can be rotated into this world CS.

  • The laboratory space; a CS specifying the room where the instrument is located in or a physical landmark on the instrument, e.g. the direction of the transfer rod where positive is the direction how the rod has to be pushed during loading a specimen into the instrument. In summary, this CS is defined by the chassis of the instrument. Suggested name of the group laboratory_reference_frame.

  • The specimen space; a CS affixed to either the base or the initial apex of the specimen, whose z axis points towards the detector. Suggested name of the group specimen_reference_frame.

  • The detector space; a CS affixed to the detector plane whose xy plane is usually in the detector and whose z axis points towards the specimen. This is a distorted space with respect to the reconstructed ion positions. Suggested name of the group detector_reference_frame.

  • The reconstruction space; a CS in which the reconstructed ion positions are defined. The orientation depends on the analysis software used.

  • Eventually further coordinate systems attached to the flight path of individual ions might be defined. Suggested name of the group reconstruction_reference_frame.

To achieve unique names, the prefix “NAMED” should be replaced to with something derived from an alias for the coordinate system, or the value of the “alias” field.

Use the suffix _reference_frame when creating specific instances of NXcoordinate_system e.g. laboratory_reference_frame, reconstruction_reference_frame and so on and so forth.

In atom probe microscopy a frequently used choice for the detector space (CS) is discussed with the so-called detector space image stack. This is a stack of two-dimensional histograms of detected ions within a predefined evaporation identifier interval. Typically, the set of ion evaporation sequence identifiers is grouped into chunks.

For each chunk a histogram of the ion hit positions on the detector is computed. This leaves the possibility for inconsistency between the so-called detector space and the e.g. specimen space.

To avoid these ambiguities, instances of NXtransformations should be used.

alias: (optional) NX_CHAR

type: (required) NX_CHAR ⤆

origin: (recommended) NX_CHAR ⤆

x: (required) NX_NUMBER ⤆

x_direction: (recommended) NX_CHAR ⤆

y: (required) NX_NUMBER ⤆

y_direction: (recommended) NX_CHAR ⤆

z: (required) NX_NUMBER ⤆

z_direction: (recommended) NX_CHAR ⤆

measurement: (optional) NXapm_measurement

status: (recommended) NX_CHAR ⤆

quality: (recommended) NX_CHAR ⤆

instrument: (required) NXapm_instrument ⤆

type: (recommended) NX_CHAR ⤆

location: (recommended) NX_CHAR ⤆

flight_path: (recommended) NX_FLOAT ⤆

fabrication: (recommended) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

reflectron: (optional) NXcomponent ⤆

applied: (required) NX_BOOLEAN ⤆

local_electrode: (recommended) NXelectromagnetic_lens

name: (required) NX_CHAR ⤆

aperture_type: (recommended) NX_CHAR

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

ion_detector: (recommended) NXdetector ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

pulser: (recommended) NXcomponent ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

sourceID: (optional) NXsource ⤆

fabrication: (recommended) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

stage: (optional) NXmanipulator ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

analysis_chamber: (optional) NXcomponent ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

buffer_chamber: (optional) NXcomponent ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

load_lock_chamber: (optional) NXcomponent ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

getter_pump: (optional) NXpump ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

roughening_pump: (optional) NXpump ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

turbomolecular_pump: (optional) NXpump ⤆

fabrication: (optional) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

eventID: (optional) NXapm_event_data ⤆

start_time: (recommended) NX_DATE_TIME ⤆

end_time: (recommended) NX_DATE_TIME ⤆

instrument: (recommended) NXapm_instrument ⤆

reflectron: (recommended) NXcomponent ⤆

voltage: (required) NX_FLOAT ⤆

local_electrode: (recommended) NXelectromagnetic_lens

voltage: (required) NX_FLOAT

pulser: (recommended) NXcomponent ⤆

pulse_mode: (required) NX_CHAR ⤆

pulse_frequency: (required) NX_FLOAT ⤆

pulse_fraction: (required) NX_FLOAT ⤆

pulse_voltage: (optional) NX_FLOAT (Rank: 1, Dimensions: [n]) ⤆

pulse_number: (optional) NX_UINT (Rank: 1, Dimensions: [n]) ⤆

standing_voltage: (optional) NX_FLOAT (Rank: 1, Dimensions: [n]) ⤆

sourceID: (optional) NXsource ⤆

wavelength: (recommended) NX_FLOAT {units=NX_WAVELENGTH} ⤆

power: (required) NX_FLOAT {units=NX_POWER} ⤆

pulse_energy: (required) NX_FLOAT (Rank: 1, Dimensions: [n]) ⤆

stage: (required) NXmanipulator ⤆

temperature_sensor: (required) NXsensor ⤆

measurement: (required) NX_CHAR ⤆

value: (required) NX_FLOAT ⤆

analysis_chamber: (required) NXcomponent ⤆

pressure_sensor: (required) NXsensor ⤆

measurement: (required) NX_CHAR ⤆

value: (required) NX_FLOAT ⤆

control: (recommended) NXparameters ⤆

evaporation_control: (required) NX_CHAR ⤆

target_detection_rate: (required) NX_NUMBER ⤆

simulation: (optional) NXapm_simulation

atom_probeID: (optional) NXroi_process

A region-of-interest analyzed either during or after the session for which ...

A region-of-interest analyzed either during or after the session for which specific processed data of the measured or simulated data are available.

If a single instance is required the group should be named atom_probe. If multiple groups are required these should be named atom_probe1, atom_probe2, and so on and so forth.

initial_specimen: (recommended) NXimage

SEM or TEM image of the initial specimen taken before the measurement.

image_2d: (required) NXdata ⤆

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_UINT

real: (required) NX_NUMBER ⤆

axis_j: (required) NX_NUMBER (Rank: 1, Dimensions: [n_j]) ⤆

@long_name: (required) NX_CHAR ⤆

axis_i: (required) NX_NUMBER (Rank: 1, Dimensions: [n_i]) ⤆

@long_name: (required) NX_CHAR ⤆

final_specimen: (recommended) NXimage

SEM or TEM image of the final specimen taken after completion of the ...

SEM or TEM image of the final specimen taken after completion of the measurement.

image_2d: (required) NXdata ⤆

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_UINT

real: (required) NX_NUMBER ⤆

axis_j: (required) NX_NUMBER (Rank: 1, Dimensions: [n_j]) ⤆

@long_name: (required) NX_CHAR ⤆

axis_i: (required) NX_NUMBER (Rank: 1, Dimensions: [n_i]) ⤆

@long_name: (required) NX_CHAR ⤆

raw_data: (optional) NXprocess ⤆

Document the control software that was used on the instrument with which r ...

Document the control software that was used on the instrument with which raw data were collected.

For almost all atom probe instruments, the recorded raw data and metadata follow proprietary semantics. Therefore, this group can currently often not be filled with more than the control software and some pointing to digital artifacts (e.g. proprietary files) that have been collected during the measurement in an effort to document as best as possible all steps of an analysis workflow.

The physical quantities measured in an atom probe experiment are time-of-flight and tuples of arrival_time_pairs as a function of the event chain on the pulser. From these tuples, hits are computed in a process called hit_finding.

sequence_index: (recommended) NX_POSINT ⤆

number_of_dld_wires: (recommended) NX_UINT {units=NX_UNITLESS}

The number of delay-line-detector (DLD) wires present. ...

The number of delay-line-detector (DLD) wires present.

Any of these values: 1 | 2 | 3

dld_wire_names: (optional) NX_CHAR (Rank: 2, Dimensions: [n_dld, 2])

Alias tuple, typical for the begin and the end of each DLD wire ...

Alias tuple, typical for the begin and the end of each DLD wire of the detector. Order follows arrival_time_pairs.

The order of the first dimension should match that of the second dimension of the arrival_time_pairs field.

arrival_time_pairs: (optional) NX_NUMBER (Rank: 3, Dimensions: [p, n_dld, 2]) {units=NX_TIME}

Raw readings from the analog-to-digital-converter ...

Raw readings from the analog-to-digital-converter timing circuits of the detector wires.

programID: (optional) NXprogram

The control software that was used for running the measurement. ...

The control software that was used for running the measurement.

At least the main software should be reported. If this is the only program to report name the group “program” and use its below fields program and version to detail the version used. E.g. program AP Suite, version 6.3

It is recommended to report multiple programs though, i.e. also the libraries and dependencies of the software. In the case of AP Suite/IVAS this can be used to document the AP Suite GUI, LAS, CamecaRoot, and CernRoot versions. In this case always name the program groups program1, program2, … with program one being AP Suite/IVAS.

In the case of an open-source instrument, like P. Felfer’s Oxcart or G. Schmitz’s M-TAP instruments, also use program1, program2, … with program1 representing the control software e.g. M. Monajem and P. Felfer pyCCAPT. Further instances (program2, …) can be used to list the dependencies, the python virtual environment.

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

Possibility to point to files that contain raw data. ...

Possibility to point to files that contain raw data.

Exemplar files that could be pointed to here when working with AMETEK/Cameca instruments are the proprietary STR, RRAW, or HITS files that AP Suite/IVAS generates.

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

hit_finding: (recommended) NXprocess ⤆

The configuration of a hit finding algorithm and its output. ...

The configuration of a hit finding algorithm and its output.

Hit finding is the process of deciding which detector signals are significant and assigning specific ions colliding with the detector to each observed event.

sequence_index: (recommended) NX_POSINT ⤆

hit_positions: (recommended) NX_NUMBER (Rank: 2, Dimensions: [p_out, 2]) {units=NX_LENGTH}

Evaluated ion impact coordinates on the detector. ...

Evaluated ion impact coordinates on the detector. Use the depends_on field to specify which reference frame the positions are defined in.

@depends_on: (required) NX_CHAR

Contains the path to an instance of NX_coordinate_system ...

Contains the path to an instance of NX_coordinate_system in which the positions are defined.

total_event_golden: (optional) NX_UINT {units=NX_UNITLESS}

Number of events of type "golden" when APSuite/IVAS was used as the ...

Number of events of type “golden” when APSuite/IVAS was used as the software with which the measurement was performed.

The value can be extracted from the CRunHeader.fTotalEventGolden field of a CamecaRoot RHIT/HITS file.

total_event_incomplete: (optional) NX_UINT {units=NX_UNITLESS}

Number of events of type "incomplete" when APSuite/IVAS was used as the ...

Number of events of type “incomplete” when APSuite/IVAS was used as the software with which the measurement was performed.

The value can be extracted from the CRunHeader.fTotalEventIncomplete field of a CamecaRoot RHIT/HITS file.

total_event_multiple: (optional) NX_UINT {units=NX_UNITLESS}

Number of events of type "multiple" when APSuite/IVAS was used as the ...

Number of events of type “multiple” when APSuite/IVAS was used as the software with which the measurement was performed.

The value can be extracted from the CRunHeader.fTotalEventMultiple field of a CamecaRoot RHIT/HITS file.

total_event_partials: (optional) NX_UINT {units=NX_UNITLESS}

Number of events of type "partials" when APSuite/IVAS was used as the ...

Number of events of type “partials” when APSuite/IVAS was used as the software with which the measurement was performed.

The value can be extracted from the CRunHeader.fTotalEventPartials field of a CamecaRoot RHIT/HITS file.

total_event_record: (optional) NX_UINT {units=NX_UNITLESS}

Number of events when APSuite/IVAS was used as the ...

Number of events when APSuite/IVAS was used as the software with which the measurement was performed.

The value can be extracted from the CRunHeader.fTotalEventRecords field of a CamecaRoot RHIT/HITS file.

hit_quality_type: (optional) NX_CHAR (Rank: 1, Dimensions: [n_ht])

Hit quality is an integer that specifies which category/type a hit was a ...

Hit quality is an integer that specifies which category/type a hit was assigned to. This field lists the human-readable, possibly though proprietary types distinguished. The indices of this array are used in hit_quality to encode hit_quality for each pulse in a more efficient way than by repeating the string that is used for each type as it is provided in this field.

As an example, assume two types, “golden” and “partial”, are distinguished. If hit_quality_type stores the array “golden”, “partial”, the index 0 in hit_quality identifies all those pulses of category “golden”, while the index 1 in hit_quality identifies all of category “partial”.

hit_quality: (optional) NX_UINT (Rank: 1, Dimensions: [p_out]) {units=NX_UNITLESS}

Hit quality identifier for each pulse. ...

Hit quality identifier for each pulse. Identifier has to be within hit_quality_type.

hit_multiplicity: (optional) NX_UINT (Rank: 1, Dimensions: [p_out]) {units=NX_UNITLESS}

The number of ions determined to have been collected on the same pulse. ...

The number of ions determined to have been collected on the same pulse. These ions may hit different pixels, or even the same detector pixel. The hit_multiplicity is not related to the makeup of the ions and should not be confused with the number of atoms or elements that constitute a molecular ion.

programID: (optional) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

config: (recommended) NXnote ⤆

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

hit_spatial_filtering: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

evaporation_id_offset: (required) NX_INT {units=NX_UNITLESS}

Integer which defines the first evaporation_id. ...

Integer which defines the first evaporation_id. Typically, this is either zero or one.

evaporation_id: (required) NX_INT (Rank: 1, Dimensions: [n]) {units=NX_UNITLESS}

There are two possibilities to report evaporation_id values: ...

There are two possibilities to report evaporation_id values:

If evaporation_id_offset is provided, the evaporation_id values are defined by the sequence \([evaporation\_id\_offset, evaporation\_id\_offset + n]\) with \(n\) the number of ions in the reconstructed volume.

Alternatively, evaporation_id_offset is not provided but instead a a sequence of \(n\) values is defined, these integer values do not need to be sorted.

programID: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (optional) NXnote ⤆

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

hit_filter: (recommended) NXcs_filter_boolean_mask

number_of_objects: (required) NX_UINT ⤆

bitdepth: (required) NX_UINT ⤆

mask: (required) NX_UINT ⤆

voltage_and_bowl: (recommended) NXprocess ⤆

Configuration of and results obtained from a voltage-and-bowl time-of-flig ...

Configuration of and results obtained from a voltage-and-bowl time-of-flight correction algorithm.

The voltage-and-bowl correction is a data post-processing step to correct ion impact positions for flight path differences, detector bias, and nonlinearities.

sequence_index: (recommended) NX_POSINT ⤆

raw_tof: (recommended) NX_FLOAT (Rank: 1, Dimensions: [n])

Raw time-of-flight data without corrections.

tof_zero_estimate: (optional) NX_FLOAT {units=NX_TIME}

The parameter \(t_0\), CAnalysis.CCalibMass.fT0Estimate

calibrated_tof: (recommended) NX_FLOAT (Rank: 1, Dimensions: [n])

Calibrated time-of-flight.

programID: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (optional) NXnote ⤆

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

config: (required) NXparameters ⤆

correction_peak: (recommended) NX_FLOAT {units=NX_ANY}

Reference mass-to-charge state ratio value ...

Reference mass-to-charge state ratio value

For example 16 Da as mentioned by T. Blum et al. (page 371).

mass_to_charge_conversion: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

mass_to_charge: (required) NX_FLOAT (Rank: 1, Dimensions: [n])

programID: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

config: (required) NXparameters ⤆

mass_calibration: (recommended) NX_FLOAT {units=NX_ANY}

Mass calibration with unit peaks/interp. as mentioned by `T. Blum et a ...

Mass calibration with unit peaks/interp. as mentioned by T. Blum et al. (page 371).

mass_resolution: (recommended) NX_FLOAT (Rank: 1, Dimensions: [m_r]) {units=NX_ANY}

Inverse of the mass resolution :math:`\frac{M}{\Delta M}` as mentioned ...

Inverse of the mass resolution \(\frac{M}{\Delta M}\) as mentioned by T. Blum et al. (page 371).

Multiple values can be reported but reporting each is only useful when stating also:

  • The full width at which \({\Delta M}_{fw}\) fraction of maximum this value was defined.

    Examples are at tenth \({\Delta M}_{10}\) or at half maximum (FWHM). Consequently, mass_resolution_fw should needs to be a vector of the same length and using the same order like used for mass_resolution, i.e. the first mass resolution was defined at the maximum as defined by the first value from mass_resolution_fw.

  • The reference molecular ion e.g. \(^{16}{O_{2}}^{+}\)

    As many instances of mass_resolutionION should be used with instances numbered starting from 1 up to the length of the mass_resolution vector.

mass_resolution_fw: (recommended) NX_FLOAT (Rank: 1, Dimensions: [m_r]) {units=NX_ANY}

The full width at which :math:`{\Delta M}_{fw}` fraction of maximum th ...

The full width at which \({\Delta M}_{fw}\) fraction of maximum this value was defined. Examples are at tenth \({\Delta M}_{10}\) or at half maximum (FWHM). Consequently, mass_resolution_fw should needs to be a vector of the same length and using the same order like used for mass_resolution, i.e. the first mass resolution was defined at the maximum as defined by the first value from mass_resolution_fw.

mass_resolutionION: (recommended) NXatom

The reference molecular ion e.g. :math:`^{16}{O_{2}}^{+}` ...

The reference molecular ion e.g. \(^{16}{O_{2}}^{+}\) As many instances of mass_resolutionION should be used with instances numbered starting from 1 up to the length of the mass_resolution vector.

nuclide_hash: (recommended) NX_UINT ⤆

name: (required) NX_CHAR ⤆

reconstruction: (recommended) NXapm_reconstruction

sequence_index: (recommended) NX_POSINT ⤆

reconstructed_positions: (required) NX_FLOAT (Rank: 2, Dimensions: [n, 3]) ⤆

volume: (recommended) NX_FLOAT ⤆

field_of_view: (recommended) NX_FLOAT ⤆

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

For LEAP and APSuite/IVAS-based analyses the root file which stores ...

For LEAP and APSuite/IVAS-based analyses the root file which stores the settings whereby an RHIT/HITS file can be used to regenerate the reconstructed volume that is here referred to.

The respective RHIT/HITS file should ideally be specified in the serialized group of the hit_finding section of this application definition.

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

results: (recommended) NXnote ⤆

For LEAP and APSuite/IVAS-based analyses the resulting typically ...

For LEAP and APSuite/IVAS-based analyses the resulting typically file with the reconstructed positions and calibrated mass-to-charge- state ratio values.

For other data collection/analysis software the data artifact which comes closest conceptually to AMETEK/Cameca’s typical file formats.

These are typically exported as a POS, ePOS, APT, ATO, ENV, or HDF5 file, which should be stored alongside this record in the research data management system.

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

config: (recommended) NXparameters ⤆

voltage_filter_initial: (recommended) NX_FLOAT ⤆

voltage_filter_final: (recommended) NX_FLOAT ⤆

protocol_name: (recommended) NX_CHAR ⤆

primary_element: (recommended) NX_CHAR ⤆

efficiency: (recommended) NX_FLOAT ⤆

flight_path: (recommended) NX_FLOAT ⤆

evaporation_field: (recommended) NX_CHAR

image_compression: (recommended) NX_FLOAT ⤆

kfactor: (recommended) NX_FLOAT ⤆

shank_angle: (recommended) NX_FLOAT ⤆

ion_volume: (recommended) NX_FLOAT ⤆

crystallographic_calibration: (recommended) NX_CHAR ⤆

comment: (recommended) NX_CHAR ⤆

naive_discretization: (required) NXprocess ⤆

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

DATA: (required) NXdata ⤆

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_UINT

title: (recommended) NX_CHAR ⤆

intensity: (required) NX_NUMBER (Rank: 3, Dimensions: [n_z, n_y, n_x])

axis_z: (required) NX_FLOAT (Rank: 1, Dimensions: [n_z])

@long_name: (required) NX_CHAR

axis_y: (required) NX_FLOAT (Rank: 1, Dimensions: [n_y])

@long_name: (required) NX_CHAR

axis_x: (required) NX_FLOAT (Rank: 1, Dimensions: [n_x])

@long_name: (required) NX_CHAR

ranging: (recommended) NXapm_ranging

sequence_index: (recommended) NX_POSINT ⤆

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

The respective ranging definitions file RNG/RRNG/ENV/HDF5.

type: (recommended) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (recommended) NX_CHAR ⤆

algorithm: (recommended) NX_CHAR ⤆

mass_to_charge_distribution: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

min_mass_to_charge: (required) NX_FLOAT ⤆

max_mass_to_charge: (required) NX_FLOAT ⤆

n_mass_to_charge: (required) NX_POSINT ⤆

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

mass_spectrum: (required) NXdata ⤆

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_UINT

title: (recommended) NX_CHAR ⤆

intensity: (required) NX_NUMBER (Rank: 1, Dimensions: [n_bins])

@long_name: (required) NX_CHAR

axis_mass_to_charge: (required) NX_FLOAT (Rank: 1, Dimensions: [n_bins])

@long_name: (required) NX_CHAR

background_quantification: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

background: (recommended) NX_FLOAT {units=NX_ANY}

(Out-of-sync, time-independent) background levels in ppm/ns ...

(Out-of-sync, time-independent) background levels in ppm/ns reported by e.g. APSuite/IVAS for LEAP systems.

mrp_value: (recommended) NX_FLOAT {units=NX_DIMENSIONLESS}

The mass-resolving power (MRP) value ...

The mass-resolving power (MRP) value

D. Larson et al. report Eq. D.8 in page 282:

\(MRP = \frac{1}{2\delta t} \cdot \sqrt{\frac{m}{n}\frac{1}{2eV}L}\),

with \(\delta t\) representing the timing imprecision, \(\frac{m}{n}\) the mass-to-charge state ratio, \(e\) the elementary charge, \(V\) the potential difference, and \(L\) the flight path length.

Timing imprecision is caused by variations of flight path length and voltage, the fact that the precision of electronics is finite and a spread of the time-of-departure of individual ions is observed.

mrp_mass_to_charge: (recommended) NX_FLOAT {units=NX_ANY}

Mass-to-charge state ratio \(\frac{m}{n}\) at which mrp_value was specified.

mrp_voltage: (recommended) NX_FLOAT {units=NX_VOLTAGE}

Potential difference \(V\) at which mrp_value was specified.

mrp_flight_path_length: (recommended) NX_FLOAT {units=NX_LENGTH}

Flight path length \(L\) at which mrp_value was specified.

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

peak_search: (recommended) NXprocess

sequence_index: (recommended) NX_POSINT ⤆

programID: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

peakID: (optional) NXpeak

label: (recommended) NX_CHAR ⤆

description: (recommended) NX_CHAR

category: (recommended) NX_CHAR

Category for the peak offering a qualitative statement of the locati ...

Category for the peak offering a qualitative statement of the location of the peak in light of limited mass-resolving power that is relevant for composition quantification. See D. Larson et al. (p172) for examples of each category:

  • 0, well-separated, \(^{10}B^{+}\), \(^{28}Si^{2+}\)

  • 1, close, but can be sufficiently separated for quantification in a LEAP system, \(^{94}Mo^{3+}\), \(^{63}Cu^{2+}\)

  • 2, closely overlapping, demands better than LEAP4000X MRP can provide \(^{14}N^{+}\), \(^{28}Si^{2+}\) at different charge states

  • 3, overlapped exactly due to multi-charge molecular species, \(^{16}{O_{2}}^{2+}\), \(^{16}O^{+}\)

  • 4, overlapped, same charge state, cannot as of 2013 be discriminated with a LEAP4000X, \(^{14}{N_{2}}^{+}\), \(^{28}Si^{+}\)

  • 5, overlapped, same charge state, any expectation of resolvability, \(^{54}Cr^{2+}\), \(^{54}Fe^{2+}\)

Any of these values: 0 | 1 | 2 | 3 | 4 | 5

position: (required) NX_NUMBER

peak_identification: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

number_of_ion_types: (required) NX_UINT ⤆

maximum_number_of_atoms_per_molecular_ion: (required) NX_UINT ⤆

iontypes: (recommended) NX_UINT (Rank: 1, Dimensions: [n]) {units=NX_UNITLESS}

The iontype identifier for each ion that was best matching; ...

The iontype identifier for each ion that was best matching; stored in the order of the evaporation_id.

The value zero is reserved for documenting that an ion was unranged. Identifier for ranged ions need to start at 1 up to number_of_ion_types.

programID: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

ionID: (required) NXatom ⤆

Ions that were ranged. ...

Ions that were ranged.

The value zero is reserved for documenting that an ion was unranged. Identifier for ranged ions need to start at 1 up to number_of_ion_types.

nuclide_hash: (required) NX_UINT ⤆

charge_state: (required) NX_INT

mass_to_charge_range: (required) NX_FLOAT

nuclide_list: (recommended) NX_UINT ⤆

name: (recommended) NX_CHAR ⤆

charge_state_analysis: (optional) NXapm_charge_state_analysis

charge_state: (required) NX_INT ⤆

nuclide_hash: (required) NX_UINT ⤆

mass: (required) NX_FLOAT ⤆

natural_abundance_product: (required) NX_FLOAT ⤆

shortest_half_life: (required) NX_FLOAT ⤆

config: (required) NXparameters ⤆

nuclides: (required) NX_UINT ⤆

mass_to_charge_range: (required) NX_FLOAT ⤆

min_half_life: (required) NX_FLOAT ⤆

min_abundance: (required) NX_FLOAT ⤆

sacrifice_isotopic_uniqueness: (required) NX_BOOLEAN ⤆

Hypertext Anchors

List of hypertext anchors for all groups, fields, attributes, and links defined in this class.

NXDL Source:

https://github.com/FAIRmat-NFDI/nexus_definitions/tree/fairmat/applications/NXapm.nxdl.xml