2.3.3.3.13. NXapm

Status:

application definition (contribution), extends NXobject

Description:

Application definition for atom probe and field ion microscopy experiments.

Symbols:

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

n_ht: Number of hit qualities (hit types) distinguished.

n_dld: Number of delay-line 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 NXevent_data_apm. 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 datasets.

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 identifier_evaporation). This identifier must not be confused with the identifier_pulse. Typically smaller than both p_out and p_out.

Groups cited:

NXapm_charge_state_analysis, NXapm_ranging, NXapm_reconstruction, NXatom, NXchemical_composition, NXcite, NXcollection, NXcomponent, NXcoordinate_system, NXcs_filter_boolean_mask, NXcs_profiling, NXdata, NXdetector, NXentry, NXevent_data_apm, NXfabrication, NXimage, NXinstrument_apm, NXion, NXlens_em, NXmanipulator, NXnote, NXobject, NXpeak, NXprocess, NXprogram, 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. This is neither the specimen_name nor the experiment_identifier. For Local Electrode Atom Probe (LEAP) instruments, it is recommended to use the run_number from the proprietary software IVAS/APSuite of AMETEK/Cameca. 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

Either an identifier or an alias that is human-friendly so that scientists f ...

Either an identifier or an alias that is human-friendly so that scientists find that experiment again. For experiments usually this is the run_number but for simulation typically no run_numbers are issued.

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

The reason is that such free-text field is difficult to machine-interpret. The motivation behind keeping this field for now is to learn in how far the current base classes need extension based on user feedback.

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.

Often though it is useful to specify both start_time and end_time to capture 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 NXevent_data_apm 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.

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? This field is meant to ...

What type of atom probe experiment is performed? This field is meant to inform research data management systems to allow filtering:

  • apt are experiments where the analysis_chamber has no imaging gas. experiment with LEAP instruments are typically performed such.

  • 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 this can be detrimental to LEAP systems (see S. Katnagallu et al.).

  • other should be used in combination with the user specifying details in the experiment_documentation field.

If NXapm is used for storing details about a simulation use other for now.

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 I/O writer software (e.g. `pynxtools

The configuration of the I/O writer software (e.g. pynxtools or its plugins) which was used to generate this NeXus file instance.

PROGRAM: (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 ⤆

CITE: (optional) NXcite

doi: (required) NX_CHAR ⤆

NOTE: (optional) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

USER: (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.

The sample group is currently a place for storing suggestions from atom probers about knowledge they have gained about the sample. There are cases where the specimen is machined further or exposed to external stimuli during the experiment. In this case, these details should not be stored under sample but suggestions should be made how this application definition can be improved.

In the future also details like how the grain_diameter was characterized, how the sample was prepared, how the material was heat-treated etc., should be stored. For this specific application definitions/schemas can be used which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable.

identifierNAME: (recommended) NX_CHAR ⤆

is_simulation: (required) NX_BOOLEAN

Qualifier whether the sample is a real (in which case is_simulation should ...

Qualifier whether the sample is a real (in which case is_simulation should be set to false) or a virtual one (in which case is_simulation should be set to true).

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. Users of this information should be aware that although the grain diameter or radius is often referred to as grain size.

In atom probe it is possible that the specimen may contain a few crystals only. In this case the grain_diameter is not a reliable 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_error: (optional) NX_FLOAT {units=NX_LENGTH}

Magnitude of the standard deviation of the grain_diameter.

heat_treatment_temperature: (optional) NX_FLOAT {units=NX_TEMPERATURE}

The temperature of the last heat treatment step before quenching. ...

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.

heat_treatment_temperature_error: (optional) NX_FLOAT {units=NX_TEMPERATURE}

Magnitude of the standard deviation of the heat_treatment_temperature.

heat_treatment_quenching_rate: (optional) NX_FLOAT {units=NX_ANY}

Rate of the last quenching step. Knowledge about this value can give ...

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.

An example is when the sample was left in the furnace after the furnace was switched off. In this case the sample cools down with a specific rate of how this furnace cools down in the lab. Processes which in practice are often not documented.

This can be problematic though because when the furnace door was left open or the ambient temperature in the lab changed, i.e. for a series of experiments where one is conducted on a hot summer day and the next during winter this can have an effect on the evolution of the microstructure. There are many cases where this has been reported to be an QA issue in industry, e.g. think about aging aluminum samples left on the factory parking lot on a hot summer day.

heat_treatment_quenching_rate_error: (optional) NX_FLOAT {units=NX_ANY}

Magnitude of the standard deviation of the heat_treatment_quenching_rate.

description: (optional) NX_CHAR ⤆

chemical_composition: (recommended) NXchemical_composition

The chemical composition of the sample. Typically, it is assumed that ...

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_error: (required) NX_FLOAT ⤆

specimen: (required) NXsample ⤆

identifierNAME: (recommended) NX_CHAR ⤆

is_simulation: (required) NX_BOOLEAN

Qualifier whether the specimen is a real (in which case is_simulation shou ...

Qualifier whether the specimen is a real (in which case is_simulation should be set to false) or a virtual one (in which case is_simulation should be set to true).

alias: (recommended) NX_CHAR

Given name an alias. Better use identifierNAME and identifier_parent inste ...

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

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. Additional time stamps prior to preparation_date should better be placed in resources which describe but which do not pollute the description here with prose. Resolving these connected pieces of information is considered within the responsibility of the research data management system.

atom_types: (required) NX_CHAR

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

List of comma-separated elements from the periodic table that are contained in the specimen. If the specimen substance has multiple components, all elements from each component must be included in atom_types.

The purpose of the field is to offer research data management systems an opportunity to parse the relevant elements without having to interpret these from the resources pointed to by identifier_parent or walk through eventually deeply nested groups in data instances.

description: (optional) NX_CHAR ⤆

Discouraged free-text field.

is_polycrystalline: (recommended) NX_BOOLEAN

Report if the specimen is polycrystalline, in which case it ...

Report if the specimen is polycrystalline, in which case it contains a grain or phase boundary, or if the specimen is a single crystal.

is_amorphous: (recommended) NX_BOOLEAN

Report if the specimen is amorphous.

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 elaborated guess of the (initial) shank an ...

Ideally measured otherwise best elaborated guess 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 (shortest) angle between the specimen space z-axis and a vector on the lateral surface of the cone.

consistent_rotations: (recommended) NXobject

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 is zxz, which is based on the work of H.-J. Bunge but other conventions are possible. Apart from undefined, proper Euler angles are distinguished from (improper) Tait-Bryan angles.

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

COORDINATE_SYSTEM: (required) NXcoordinate_system

A collection of coordinate systems. Several Euclidean ...

A collection of coordinate systems. 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.

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

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

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

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.

origin: (required) NX_CHAR ⤆

alias: (required) NX_CHAR ⤆

type: (required) NX_CHAR ⤆

handedness: (required) NX_CHAR ⤆

x_direction: (required) NX_CHAR ⤆

y_direction: (required) NX_CHAR ⤆

z_direction: (required) NX_CHAR ⤆

measurement: (optional) NXobject

Base class for collecting a session with a real atom probe or field-ion micr ...

Base class for collecting a session with a real atom probe or field-ion microscope.

Workflows used during experiments or simulations of atom probe and related field-evaporation research should be documented in more detail and be better contextualized not only because of ongoing developments and the tighter becoming connection between atom probe and other methods for material characterization foremost electron microscopy see e.g.:

to mention but a few.

To arrive at a design of base classes and an application definition that can be used for both real and simulated atom probe experiments it is worthwhile to recall concepts that are related to events and (molecular) ions:

  • Pulsing events which are used to trigger ion extraction events.

  • Physical events and corresponding signal triggered by an ion hitting the detector. Some of these events are not necessarily caused by or directly correlated with an identifiable pulsing event.

  • Processed ion hits which are the result of an algorithm that took the physical and pulsing events as input and qualified some of these events as to be of sufficiently high quality to call them (molecular) ions that are worthwhile to be considered further and eventually included in the reconstructed volume.

  • Calibration and signal filtering steps applied to these processed ion hits as input which results in actually selected (molecular) ions based on which an instance of a reconstruction is created.

  • Correlation of these ions with a statistics and theoretical model of mass-to-charge-state ratio values and charge states of the (molecular) ions to substantiate that some of these ions can be considered as rangeable ions and hence an iontype can be assigned to these via running peak finding algorithms and subsequent peak labeling. In the field of atom probe this these peak identification methods are known as ranging definitions.

Not only in AMETEK/Cameca’s IVAS/APSuite 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 (detector hits) ions is a proprietary one - the so-called hit finding algorithm.

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

There is a number of research groups who build own instruments and share different aspects of their technical specifications and approaches how they apply data processing e.g.:

to name but a few.

Despite some of these activities embrace practices of open-source development, they use essentially the same workflow that has been proposed by AMETEK/Cameca and its forerunner company Imago: A graphical user interface software is used to explore and thus analyze reconstructed atom probe datasets.

Specifically, software is used to correlate and interpret pulsing and physical events into processed ion hits. Some of these ion hits are reported as (molecular) ions with ranged iontypes to yield a dataset based on which scientific conclusions about the characterized material volume are made. Also here a reconstruction is point cloud that serves as the proxy for the characterized material volume, i.e. the reconstruction is a model.

By contrast, simulations of field-evaporation have the luxury to document the flight path and allow a following of all the whereabouts of each ion evaporated if this is desired. This level of detail is currently not characterizable in experiment. Thus, there is a divide between schemas describing simulations of atom probe vs measurements of atom probe. We argue that this divide can be bridged with realizing the above-mentioned context and the realization that similar concepts are used in both research realms with many concepts not only being similar but being exactly the same.

A further argument to support this view is that computer simulations of atom probe usually are compared to reconstructed datasets, either to the input configuration that served as the virtual specimen or to a real world atom probe experiment and reconstructions computed from these. In both cases, the recorded simulated physical events of simulated ions hitting a simulated detector is not the end of the research workflow but typically the input to apply additional algorithms such as (spatial) filtering and reconstruction algorithms.

Only the practical need for making ranging definitions is (at least as of now) not as much needed in field-evaporation simulations than it is in real world measurements because each ion has a prescribed iontype in the simulation. Be it a specifically charged nuclid or a molecular ion whose flight path the simulation resolves. Although, in principle simpler though, we have to consider that this is caused by many assumptions made in the simulations. Indeed, the multi-scale (time and space) aspects of the challenge that is the simulating of field-evaporation often require simplifications because of otherwise too high becoming computing resource demands and existent knowledge gaps in how to deal with all quantum physics complexities. Molecular ion dissociation upon flight is one such complexity. Also the complexity of simulation setups is typically defined simpler in simulation (e.g. straight flight path assumption) than in a measurement with a real instrument. In addition, simulation often also ignore objects and fields in the flight path such as local electrodes or physical obstacles and electric fields (controlled or stray fields).

status: (recommended) NX_CHAR

A statement whether the measurement was successful or failed prematurely. ...

A statement whether the measurement was successful or failed prematurely.

Any of these values: success | failed

quality: (recommended) NX_CHAR

CAnalysis.CResults.fQuality

instrument: (required) NXinstrument_apm

type: (recommended) NX_CHAR ⤆

location: (recommended) NX_CHAR ⤆

comment: (required) NX_CHAR ⤆

Free text field for additional comments.

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) NXlens_em ⤆

name: (required) 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 ⤆

SOURCE: (optional) NXsource ⤆

fabrication: (recommended) NXfabrication ⤆

vendor: (required) NX_CHAR ⤆

model: (required) NX_CHAR ⤆

serial_number: (recommended) NX_CHAR ⤆

events: (optional) NXobject

Group to hold instances of :ref:`NXevent_data_apm`. ...

Group to hold instances of NXevent_data_apm.

Which temporal granularity is adequate depends on the situation and research question. Using a model which enables a collection of events offers the most flexible way to cater for both atom probe experiments or simulation.

To monitor the course of an ion extraction experiment (or simulation) it makes sense to track time explicitly via time stamps or implicitly via e.g. a clock inside the instrument, such as the clock of the pulser and respective pulsing event identifier.

As set and measured quantities typically change over time and we do not yet know during the measurement which of the events have associated (molecular) ions that will end up in the reconstructed volume, we must not document quantities as a function of the identifier_evaporation but as a function of the (pulsing) identifier_event.

EVENT_DATA_APM: (optional) NXevent_data_apm

Instances should use event as a name prefix.

start_time: (recommended) NX_DATE_TIME ⤆

end_time: (recommended) NX_DATE_TIME ⤆

instrument: (recommended) NXinstrument_apm ⤆

reflectron: (recommended) NXcomponent ⤆

voltage: (required) NX_FLOAT ⤆

local_electrode: (recommended) NXlens_em ⤆

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]) ⤆

SOURCE: (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) NXcollection ⤆

evaporation_control: (required) NX_CHAR ⤆

target_detection_rate: (required) NX_NUMBER ⤆

simulation: (optional) NXobject

Simulation of ion extraction from matter via laser and/or voltage pulsing.

atom_probe: (recommended) NXobject

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.

initial_specimen: (recommended) NXimage

SEM or TEM image of the initial specimen (ideally taken prior data acquisition).

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: (recommended) NXprocess

For almost atom probe instruments (meta)data about raw data follow proprie ...

For almost atom probe instruments (meta)data about raw data follow proprietary semantics. Therefore, this group can currently be used only to point to these digital artifacts in an effort to document all step 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 wires in the detector. ...

The number of wires in the detector.

Any of these values: 1 | 2 | 3

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

Alias tuple (begin, end) of each DLD wire of the detector. ...

Alias tuple (begin, end) of each DLD wire of the detector. Order follows arrival_time_pairs.

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.

PROGRAM: (optional) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

hit_finding: (recommended) NXprocess

Configuration of and results obtained from a hit finding algorithm.

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.

@depends_on: (required) NX_CHAR

Defines in which reference frame the positions are defined.

total_event_golden: (optional) NX_UINT {units=NX_UNITLESS}

CRunHeader.fTotalEventGolden

total_event_incomplete: (optional) NX_UINT {units=NX_UNITLESS}

CRunHeader.fTotalEventIncomplete

total_event_multiple: (optional) NX_UINT {units=NX_UNITLESS}

CRunHeader.fTotalEventMultiple

total_event_partial: (optional) NX_UINT {units=NX_UNITLESS}

CRunHeader.fTotalEventPartials

total_event_record: (optional) NX_UINT {units=NX_UNITLESS}

CRunHeader.fTotalEventRecords

identifier_hit_quality: (optional) NX_UINT (Rank: 1, Dimensions: [n_ht])

Identifier used for each hit_quality type. ...

Identifier used for each hit_quality type. Following the order of hit_quality_types.

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 have to be within identifier_hit_quality.

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

This processing yields for each ion with how many others it evaporated ...

This processing yields for each ion with how many others it evaporated if these were collected on the same pulse. Extraction of multiple ions on one pulse on different or even the same pixel of the detector are possible.

Multiplicity must not be confused with how many atoms of the same element a molecular ion contains.

PROGRAM: (optional) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

config: (recommended) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

hit_spatial_filtering: (recommended) NXprocess

sequence_index: (recommended) NX_POSINT ⤆

identifier_evaporation_offset: (required) NX_INT {units=NX_UNITLESS}

Integer used to name the first pulse to know if there is an ...

Integer used to name the first pulse to know if there is an offset of the identifier_evaporation to zero.

Identifiers can be defined either implicitly or explicitly. For implicit indexing identifiers are defined on the interval \([identifier\_offset, identifier\_offset + c - 1]\).

Therefore, implicit identifier are completely defined by the value of identifier_offset and cardinality. For example if identifier run from -2 to 3 the value for identifier_offset is -2.

For explicit indexing the field identifier has to be used. Fortran-/Matlab- and C-/Python-style indexing have specific implicit identifier conventions where identifier_offset is 1 and 0 respectively.

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

(Molecular) ion identifier which resolves the sequence in which ...

(Molecular) ion identifier which resolves the sequence in which the ions were evaporated but taking into account that a hit_finding and spatial_filtering was applied.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (optional) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

hit_filter: (recommended) NXcs_filter_boolean_mask

number_of_objects: (required) NX_UINT ⤆

bitdepth: (required) NX_UINT ⤆

mask: (required) NX_UINT ⤆

identifier: (required) NX_INT ⤆

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.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (optional) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

mass_to_charge_conversion: (recommended) NXprocess

sequence_index: (recommended) NX_POSINT ⤆

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

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

source: (recommended) NXnote ⤆

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

reconstruction: (recommended) NXapm_reconstruction

sequence_index: (recommended) NX_POSINT ⤆

parameter: (recommended) NX_CHAR ⤆

protocol_name: (recommended) NX_CHAR ⤆

crystallographic_calibration: (recommended) NX_CHAR ⤆

field_of_view: (recommended) NX_FLOAT ⤆

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

PROGRAM: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

config: (recommended) NXnote ⤆

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

For LEAP and IVAS/APSuite-based analyses root file which stores the settings whereby an RHIT/HITS file can be used to regenerate the reconstruction 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: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

results: (recommended) NXnote ⤆

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

For LEAP and IVAS/APSuite-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: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

naive_discretization: (required) NXprocess ⤆

PROGRAM: (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 ⤆

PROGRAM: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

definitions: (recommended) NXnote ⤆

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

type: (required) NX_CHAR ⤆

file_name: (required) NX_CHAR ⤆

checksum: (required) NX_CHAR ⤆

algorithm: (required) NX_CHAR ⤆

mass_to_charge_distribution: (recommended) NXprocess ⤆

sequence_index: (recommended) NX_POSINT ⤆

min_incr_max: (required) NX_FLOAT ⤆

PROGRAM: (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) background levels in ppm/ns ...

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

mrp_value: (recommended) NX_FLOAT {units=NX_DIMENSIONLESS}

MRP, mass-resolving power, `D. Larson et al. ...

MRP, mass-resolving power, D. Larson et al. (p282, Eqs. D.7 and D.8).

mrp_mass_to_charge: (recommended) NX_FLOAT {units=NX_ANY}

MRP, at which mrp_value was specified.

PROGRAM: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

peak_search: (recommended) NXprocess

sequence_index: (recommended) NX_POSINT ⤆

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

PEAK: (optional) NXpeak

label: (recommended) NX_CHAR ⤆

description: (required) 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 ⤆

PROGRAM: (required) NXprogram ⤆

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

ION: (required) NXion ⤆

Instances should use ion as a name prefix.

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

nuclides: (required) NX_UINT ⤆

mass_to_charge_range: (required) NX_FLOAT ⤆

min_half_life: (required) NX_FLOAT ⤆

min_abundance: (required) NX_FLOAT ⤆

min_abundance_product: (required) NX_FLOAT

sacrifice_isotopic_uniqueness: (required) NX_BOOLEAN ⤆

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 ⤆

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/contributed_definitions/NXapm.nxdl.xml