3.3.3.13. NXapm

Status:

application definition (contribution), extends NXobject

Description:

Application definition for atom probe and field ion microscopy experiments. ...

Application definition for atom probe and field ion microscopy experiments.

This application definition provides a place to document data and metadata to an atom probe experiment. Primarily the measurement itself is documented. However, as most atom probe experiments are controlled with commercial software which does not allow to access the raw detector hits, this application definition also includes two key groups of processing steps (reconstruction and ranging).

During tomographic reconstruction measured data are processed into a point cloud of reconstructed positions of certain ions. During ranging time-of-flight data are identified as representing specific ions to annotate each ion with a label.

Commercial software used in atom probe research is designed as an integrated acquisition and instrument control software. For AMETEK/Cameca local electrode atom probe (LEAP) instruments the least processed (rawest) numerical results and metadata are stored in so-called STR, RRAW, RHIT, and HITS files, which are proprietary and their file format specifications not publicly documented.

Supplementary metadata are kept in a database (formerly known as the ISDb) which is connected to the instrument control software and synced with the experiment while ions are detected. In effect, RHIT and HITS files store the (rawest) experiment data in a closed manner that is practically useless for users unless they have access to the commercial software.

To arrive at a state that atom probe microscopy (APM) with LEAP instruments delivers a dataset with which users can study reconstructed atomic position and do e.g. composition analyses or other post-processing analysis tasks, these raw data have to be processed. Therefore, it is necessary that for an application definition to be useful, details about the physical acquisition of the raw data and all its processing steps have to be stored.

With this a user can create derived quantities like ion hit positions (on the detector) and calibrated time-of-flight data. These derived quantities are also needed to obtain calibrated mass-to-charge-state ratios, and finally the tomographic reconstruction of the ion positions.

In most cases, an APM dataset is useful only if it gets post-processed via so-called ranging. Ranging defines rules for mapping time-of-flight and mass-to-charge-state ratio values on ion species. This is post-processing even though in practice it is performed sometimes already (as preview) already while data are still being collected.

The ion types decode molecular identities which can very often be mapped to elemental identities, and also be used to distinguish isotopes. All these steps are in most cases performed using commercial software.

Frequently, though, ranging and post-processing is also performed with (open-source) research software. Therefore, there is strictly speaking not a single program used throughout an atom probe analysis not even for the early stage of data acquisition and processing stages to obtain a useful reconstructed and ranged dataset.

This application definition documents not only the measurement but also the key post-processing steps which transform the proprietary data into a tomographic reconstruction with ranging definitions.

Future guidance by the technology partners like AMETEK/Cameca could improve this description to cover a substantial larger number of eventually metadata that so far are neither publicly documented nor accessible.

Symbols:

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

n_ions: Total number of ions collected.

n_dld_wires: Total number of independent wires in the delay-line detector.

n_support: Number of support points for e.g. modeling peaks.

n_ivec_max: Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion.

n_ranges: Number of mass-to-charge-state-ratio intervals of this ion type.

n_x: Number of bins in the x direction.

n_y: Number of bins in the y direction.

n_z: Number of bins in the z direction.

n_bins: Number of bins.

n_topology: Total number of integers in the supplementary XDMF topology array.

Groups cited:

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

Structure:

ENTRY: (required) NXentry

@version: (required) NX_CHAR

An at least as strong as SHA256 hashvalue of the file ...

An at least as strong as SHA256 hashvalue of the file that specifies the application definition.

definition: (required) NX_CHAR ⤆

NeXus NXDL schema to which this file conforms. ...

NeXus NXDL schema to which this file conforms.

Obligatory value: NXapm

experiment_identifier: (required) NX_CHAR ⤆

Ideally, a (globally) unique persistent identifier ...

Ideally, a (globally) unique persistent identifier for referring to this experiment.

The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals.

experiment_description: (optional) NX_CHAR ⤆

Free-text description about the experiment. ...

Free-text description about the experiment.

Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of the application definition behind instead of filling in these details into the experiment_description free-text description field.

Users are encouraged to add in this field eventual DOIs to papers which yield further details to the experiment.

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 microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start_time field should be used.

Often though it is useful to specify a time interval with specifying both start_time and end_time to allow for more detailed bookkeeping and interpretation 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.

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 microscope session ended.

run_number: (recommended) NX_CHAR

Neither the specimen_name nor the experiment_identifier but the identifier ...

Neither the specimen_name nor the experiment_identifier but the identifier through which the experiment is referred to in the control software. For LEAP instruments it is recommended to use the IVAS/APSuite run_number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments at GPM in Rouen, use the identifier which is closest in meaning 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 when RHIT or HITS files are also stored alongside a data artifact instance which is generated according to this NXapm application definition.

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.

This application definition does currently not allow storing the entire set of such interrupted runs. Not because of a technical limitation within NeXus but because we have not seen a covering use case based on which we could have designed and implemented this case. Atom probers are invited to contact the respective people in the FAIRmat team to fix this.

operation_mode: (required) NX_CHAR

What type of atom probe microscopy experiment is performed. ...

What type of atom probe microscopy experiment is performed. This field is primarily meant to inform materials database systems to qualitatively filter experiments:

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

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

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

Any of these values: apt | fim | apt_fim | other

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

experiment_documentation: (optional) NXnote ⤆

Binary container for a file or a compressed collection of files which ...

Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive.

Required for operation_mode apt_fim or other to give further details. Users should not abuse this field to provide free-text information. Instead, these pieces of information should be mapped to respective groups and sections.

thumbnail: (optional) NXnote ⤆

A small image that is representative of the entry; this can be an ...

A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. A 640 x 480 pixel jpeg image is recommended. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories.

@type: (required) NX_CHAR ⤆

USER: (optional) NXuser ⤆

Contact information and eventually details person(s) involved in the ...

Contact information and eventually details person(s) involved in the microscope session. This can be the principle investigator who performed this experiment. Adding multiple users if relevant is recommended.

name: (required) NX_CHAR ⤆

Given (first) name and surname of the user.

affiliation: (recommended) NX_CHAR ⤆

Name of the affiliation of the user at the point in time ...

Name of the affiliation of the user at the point in time when the experiment was performed.

address: (recommended) NX_CHAR ⤆

Postal address of the affiliation.

email: (recommended) NX_CHAR ⤆

Email address of the user at the point in time when the experiment ...

Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended.

orcid: (recommended) NX_CHAR

Globally unique identifier of the user as offered by services ...

Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform

orcid_platform: (recommended) NX_CHAR

telephone_number: (optional) NX_CHAR ⤆

(Business) (tele)phone number of the user at the point ...

(Business) (tele)phone number of the user at the point in time when the experiment was performed.

role: (recommended) NX_CHAR ⤆

Which role does the user have in the place and at the point ...

Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating the microscope. Student, postdoc, principle investigator, guest are common examples.

social_media_name: (optional) NX_CHAR

social_media_platform: (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 other knowledge they have gained about the sample from which they cut the specimen which is field-evaporated during the experiment. Typically this is possible because the atom probe specimen is usually not heat treated as is but one assumes that one has the sample prepared as needed (i.e. with a specific grain diameter) and can thus just cut out the specimen from that material.

There are cases though where the specimen is processed further, i.e. the specimen is machined further or exposed to external stimuli during the experiment. In this case, these details should not be stored in the sample group but atom probers should make suggestions how this application definition can be improved to find a better place and compromise how to improve this application definition.

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 as using specific application definitions/schemas which are then arranged and documented with a description of the workflow so that actionable graphs become instantiatable.

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 and used in e.g. Hall-Petch-type materials models this is if at all an ensemble average whose reporting may be very informative or not if the specimen contains a few grains only. In atom probe the latter is often the case because grains are measured partially as their diameter can be in the order of magnitude of the physical diameter of the specimen.

Reporting a grain size is 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 available a documentation of the annealing treatment should be delivered by adding additional files which are uploaded alongside an NXapm instance. In the future there should better be an own schema used for the heat treatment.

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

Rate of the last quenching step. Knowledge about this value can give an idea how the specimen was heat treated, however there are many situations where one can imagine that the scalar value for just the quenching rate, i.e. the first derivative of the measured time-temperature profile is itself time-dependant. An example is when the specimen was left in the furnace after the furnace was switched off. In this case the specimen cools down with a specific rate of how this furnace cools down in the lab. Processes which in practice are often not documented with measuring the time-temperature profile.

This can be problematic because when the furnace door was left open or the ambient temperature in the lab changes, i.e. for a series of experiments where one is conducted on a hot summer day and the next during winter as might have an effect on the evolution of the microstructure. There are many cases where this has been reported to be an issue in industry, e.g. think about aging aluminium 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

Reporting compositions as atom and weight percent yields both ...

Reporting compositions as atom and weight percent yields both dimensionless quantities but their conceptual interpretation differs. A normalization based on atom_percent counts relative to the total number of atoms are of a particular type. By contrast, weight_percent normalization factorizes in the respective mass of the elements. Python libraries like pint are challenged by these differences as at.-% and wt.-% both yield fractional quantities.

Any of these values: atom_percent | weight_percent

ION: (required) NXion ⤆

name: (required) NX_CHAR ⤆

Human-readable name of the element/ion (e.g. Fe). ...

Human-readable name of the element/ion (e.g. Fe). Name has to be a symbol of an element from the periodic table. All symbols in the set of NXion instances inside the group chemical_composition need to be disjoint.

composition: (required) NX_FLOAT {units=NX_DIMENSIONLESS}

Composition value for the element/ion referred to under name. ...

Composition value for the element/ion referred to under name. The value is normalized based on normalization, i.e. composition is either an atom or weight percent quantity.

composition_error: (optional) NX_FLOAT {units=NX_DIMENSIONLESS}

Magnitude of the standard deviation of the composition (value).

specimen: (required) NXsample ⤆

name: (required) NX_CHAR ⤆

Descriptive name or ideally (globally) unique persistent identifier. ...

Descriptive name or ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the predecessor/origin (see the sample group) from where this specimen was cut. In cases where the specimen was e.g. site-specifically cut from the sample referred to in the sample group or in cases of an instrument session during which multiple specimens are loaded, the name has to be descriptive enough to resolve which specimen on e.g. the microtip array was taken.

The user is advised to store the details how a specimen was cut/prepared from a specific sample in the sample_history. The sample_history field must not be used for writing an alias of the specimen. Instead, use the field alias for this. As an example there may be a specimen/sample monitoring system in a lab with bar codes. The bar code is a good specimen/sample name. A shorter and more human readable alias like A0 can be an example for something to write in the alias field.

In cases where multiple specimens have been loaded into the microscope the name has to be the specific one, whose results are stored by this NXentry, because a single NXentry is to be used for the characterization of a single specimen in a single continuous run.

Details about the specimen preparation should be stored in the sample_history or if this is not possible in the sample group.

sample_history: (recommended) NX_CHAR

Ideally, a reference to the location of or a (globally) unique ...

Ideally, a reference to the location of or a (globally) unique persistent identifier of e.g. another file which should document ideally as many details as possible of the material, its microstructure, and its thermo-chemo-mechanical processing/ preparation history.

In the case that such a detailed history of the sample/specimen is not available, use this field as a free-text description to specify a sub-set of the entire sample history, i.e. what you would consider as being the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state and details of the preparation.

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. Usually this should be a part of the sample history, i.e. the sample is imagined handed over for the analysis. At the point it enters the microscope the session starts.

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. Further time stamps prior to preparation_date should better be placed in resources which describe the sample_history.

alias: (optional) NX_CHAR

Short_name or abbreviation of the specimen name field.

atom_types: (required) NX_CHAR

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

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

The purpose of the field is to offer materials database systems an opportunity to parse the relevant elements without having to interpret these from the sample history or from other data sources.

description: (optional) NX_CHAR ⤆

Discouraged free-text field in case properly designed records ...

Discouraged free-text field in case properly designed records for the sample_history or sample section are not available.

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.

DATA: (optional) NXdata ⤆

Hard link to a location in the hierarchy of the NeXus file ...

Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored.

COORDINATE_SYSTEM_SET: (recommended) NXcoordinate_system_set

Container to hold different coordinate systems conventions. ...

Container to hold different coordinate systems conventions.

For the specific idea and conventions to use with the NXcoordinate_system_set inspect the description of the NXcoordinate_system_set base class. Specific details for application in atom probe microscopy follow.

In this research field scientists distinguish usually several Euclidean coordinate systems (CS):

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

Coordinate systems should be right-handed ones. Clockwise rotations should be considered positive rotations.

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 ID interval. Typically, the set of ion evaporation sequence IDs 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.

The transformation here resolves this ambiguity by specifying how the positive z-axes of either coordinate systems is oriented. Consult the work of A. J. Breen and B. Gault and team for further details.

TRANSFORMATIONS: (optional) NXtransformations ⤆

MONITOR: (optional) NXmonitor ⤆

atom_probe: (required) NXinstrument ⤆

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

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

An atom probe microscope (experiment) is different compared to a large- scale facility or electron accelerator experiments in at least two ways:

  • First, ionized atoms and molecular ion(s fragments) (in the case of atom probe tomography) and (primarily) imaging gas ions (in the case of field ion microscopy) are accelerated towards a position-sensitive and time-of-flight taking detector system. Hence, there is no real probe/beam.

  • Second, the specimen is the lens of the microscope.

instrument_name: (required) NX_CHAR

Given name of the atom probe at the hosting institution. This is an ...

Given name of the atom probe at the hosting institution. This is an alias. Examples could be LEAP5000, Raptor, Oxcart, one atom at a time, etc.

location: (optional) NX_CHAR

Location of the lab or place where the instrument is installed. ...

Location of the lab or place where the instrument is installed. Using GEOREF is preferred.

flight_path_length: (required) NX_FLOAT {units=NX_LENGTH}

The space inside the atom probe along which ions pass nominally ...

The space inside the atom probe along which ions pass nominally when they leave the specimen and travel to the detector.

THIS DOCSTRING NEEDS CLARIFICATION.

field_of_view: (recommended) NX_FLOAT {units=NX_LENGTH}

The nominal diameter of the specimen ROI which is measured in the ...

The nominal diameter of the specimen ROI which is measured in the experiment. It is important to mention that the physical specimen cannot be measured completely because ions may launch but not be detected or hit elsewhere in the analysis_chamber.

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 | failure | unknown

CSG: (optional) NXcsg

FABRICATION: (recommended) NXfabrication

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

REFLECTRON: (required) NXreflectron

applied: (required) NX_BOOLEAN

Is a reflectron installed and was it used?

name: (optional) NX_CHAR ⤆

description: (recommended) NX_CHAR ⤆

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

local_electrode: (required) NXlens_em

A local electrode guiding the ion flight path. Also called ...

A local electrode guiding the ion flight path. Also called counter or extraction electrode.

name: (required) NX_CHAR ⤆

Identifier of the local_electrode in an e.g. database.

APERTURE_EM: (optional) NXaperture_em

name: (recommended) NX_CHAR ⤆

value: (recommended) NX_NUMBER ⤆

FABRICATION: (optional) NXfabrication ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

ion_detector: (required) NXdetector ⤆

Detector for taking raw time-of-flight and ...

Detector for taking raw time-of-flight and ion/hit impact positions data.

type: (required) NX_CHAR ⤆

Description of the detector type. Specify if the detector is ...

Description of the detector type. Specify if the detector is not the usual type, i.e. not a delay-line detector. In the case the detector is a multi-channel plate/ delay line detector, use mcp_dld. In the case the detector is a phosphor CCD use phosphor_ccd. In other case specify the detector type via free-text.

name: (recommended) NX_CHAR

Given name/alias.

model: (recommended) NX_CHAR

Given brand or model name by the manufacturer.

serial_number: (recommended) NX_CHAR ⤆

Given hardware name/serial number or hash identifier ...

Given hardware name/serial number or hash identifier issued by the manufacturer.

manufacturer_name: (recommended) NX_CHAR

Given name of the manufacturer.

signal_amplitude: (optional) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_CURRENT}

Amplitude of the signal detected on the multi-channel plate (MCP). ...

Amplitude of the signal detected on the multi-channel plate (MCP).

This field should be used for storing the signal amplitude quantity within ATO files. The ATO file format is used primarily by the atom probe groups of the GPM in Rouen, France.

CSG: (optional) NXcsg

pulser: (required) NXpulser_apm

pulse_mode: (required) NX_CHAR ⤆

pulse_frequency: (required) NX_FLOAT ⤆

pulse_fraction: (required) NX_FLOAT ⤆

pulsed_voltage: (recommended) NX_FLOAT ⤆

standing_voltage: (recommended) NX_FLOAT ⤆

CSG: (optional) NXcsg

SOURCE: (optional) NXsource ⤆

Atom probe microscopes use controlled laser, voltage, or a ...

Atom probe microscopes use controlled laser, voltage, or a combination of pulsing strategies to trigger the excitation and eventual field evaporation/emission of an ion during an experiment. If pulse_mode is set to laser or laser_and_voltage (e.g. for LEAP6000-type instruments) having the group/section laser_gun is required and the following of its fields have to be filled:

  • name

  • wavelength

  • energy

name: (required) NX_CHAR ⤆

wavelength: (recommended) NX_FLOAT ⤆

power: (recommended) NX_FLOAT ⤆

pulse_energy: (recommended) NX_FLOAT ⤆

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

BEAM: (optional) NXbeam ⤆

pinhole_position: (recommended) NXcollection ⤆

spot_position: (recommended) NXcollection ⤆

stage_lab: (required) NXstage_lab

base_temperature: (required) NX_FLOAT {units=NX_TEMPERATURE}

Average temperature at the specimen base, i.e. ...

Average temperature at the specimen base, i.e. base_temperature during the measurement.

temperature: (optional) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_TEMPERATURE}

The best estimate, at experiment time, for the temperature at the ...

The best estimate, at experiment time, for the temperature at the sample base (furthest point along sample apex and holding assembly that is removable from the sample stage).

CSG: (optional) NXcsg

analysis_chamber: (required) NXchamber

name: (optional) NX_CHAR ⤆

description: (optional) NX_CHAR ⤆

pressure: (required) NX_FLOAT {units=NX_PRESSURE}

Average pressure in the analysis chamber.

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

buffer_chamber: (optional) NXchamber

name: (optional) NX_CHAR ⤆

description: (optional) NX_CHAR ⤆

pressure: (required) NX_FLOAT {units=NX_PRESSURE}

Average pressure in the buffer chamber.

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

load_lock_chamber: (optional) NXchamber

name: (optional) NX_CHAR ⤆

description: (optional) NX_CHAR ⤆

pressure: (required) NX_FLOAT {units=NX_PRESSURE}

Average pressure in the load_lock_chamber.

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

getter_pump: (optional) NXpump

design: (recommended) NX_CHAR ⤆

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

roughening_pump: (optional) NXpump

design: (recommended) NX_CHAR ⤆

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

turbomolecular_pump: (optional) NXpump

design: (recommended) NX_CHAR ⤆

FABRICATION: (optional) NXfabrication ⤆

vendor: (recommended) NX_CHAR ⤆

model: (recommended) NX_CHAR ⤆

identifier: (recommended) NX_CHAR ⤆

capabilities: (optional) NX_CHAR

CSG: (optional) NXcsg

instrument_calibration: (recommended) NXcollection ⤆

A possible place, which has to be discussed with the atom probe ...

A possible place, which has to be discussed with the atom probe community more though, where quantitative details about the calibration of the counter electrode could be stored. Work in this direction was e.g. reported by the Erlangen group (see P. Felfer et al. )

specimen_monitoring: (recommended) NXcollection ⤆

A place where details about the initial shape of the specimen ...

A place where details about the initial shape of the specimen can be stored. Ideally, here also data about the shape evolution of the specimen can be stored. There are currently very few techniques which can measure the shape evolution:

  • Correlative electron microscopy coupled with modeling but this usually takes an interrupted experiment in which the specimen is transferred, an image taken, and a new evaporation sequence initiated. Examples are I. Mouton et al. and C. Fletcher.

  • Another method, which is less accurate though, is to monitor the specimen evolution via the in-built camera system (if available) in the instrument.

  • Another method is to use correlated scanning force microscopy methods like reported in C. Fleischmann.

  • A continuous monitoring of the specimen in a correlative electron microscopy/atom probe experiment is planned to be developed by T. Kelly et al. Nothing can be said about the outcome of this research yet but here is where such spatio-temporally data could be stored.

initial_radius: (required) NX_FLOAT {units=NX_LENGTH}

Ideally measured or best elaborated guess of the ...

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

shank_angle: (required) NX_FLOAT {units=NX_ANGLE}

Ideally measured or best elaborated guess of the shank angle. ...

Ideally measured or best elaborated guess of the 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.

detection_rate: (required) NX_FLOAT {units=NX_DIMENSIONLESS}

Average detection rate over the course of the experiment.

estimated_field_at_the_apex: (optional) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_ANY}

Estimated field at the apex along the evaporation sequence.

control_software: (required) NXcollection ⤆

The majority of atom probe microscopes come from a ...

The majority of atom probe microscopes come from a single commercial manufacturer AMETEK (formerly Cameca). Their instruments are controlled via an(/a set) of integrated instrument control system(s) (APSuite/IVAS/DAVis).

By contrast, instruments which were built by individual research groups such as of the French (GPM, Rouen, France), the Schmitz (Inspico, Stuttgart, Germany), the Felfer (Oxcart, Erlangen, Germany), the Northwestern (D. Isheim, Seidman group et al.), or the PNNL group (Pacific Northwest National Laborary, Portland, Oregon, U.S.) have other solutions to control the instrument.

Some of which are modularized and open, some of which realize also integrated control units with portions of eventually undisclosed source code and (so far) lacking (support of)/open APIs.

Currently, there is no accepted/implemented community-specific API for getting finely granularized access to such control settings.

These considerations motivated the design of the NXapm application definition in that it stores quantities in NXcollection. groups to begin with. Holding heterogeneous, not yet standardized but relevant pieces of information is the purpose of this collection.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

buffer_chamber: (optional) NXcollection

Track time-dependent details over the course of the measurement about th ...

Track time-dependent details over the course of the measurement about the buffer_chamber.

load_lock_chamber: (optional) NXcollection

Track time-dependent details over the course of the measurement about th ...

Track time-dependent details over the course of the measurement about the load_lock_chamber.

analysis_chamber: (optional) NXcollection

Track time-dependent details over the course of the measurement about th ...

Track time-dependent details over the course of the measurement about the analysis_chamber.

ion_impact_positions: (recommended) NXprocess

Details about where ions hit the ion_detector and data processing ...

Details about where ions hit the ion_detector and data processing steps related to analog-to-digital conversion of detector signals into ion hit positions. For AMETEK LEAP instruments this processing takes place partly in the control unit of the detector partly in the software. The process is controlled by the acquisition/ instrument control software (IVAS/APSuite/DAVis). The exact details are not documented by AMETEK in an open manner. For instruments built by individual research groups, like the Oxcart instrument, individual timing data from the delay-line detector are openly accessible.

sequence_index: (recommended) NX_POSINT ⤆

arrival_time_pairs: (recommended) NX_NUMBER (Rank: 3, Dimensions: [n_ions, n_dld_wires, 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.

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

Evaluated ion impact coordinates at the detector ...

Evaluated ion impact coordinates at the detector (either as computed from the arrival time data or as reported by the control software). If the acquisition software enables it one can also store in this field the hit_positions, as measured by the detector, without any corrections.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

hit_quality_filtering: (optional) NXprocess

This could be a place where currently the publicly undocumented ...

This could be a place where currently the publicly undocumented algorithmic steps are stored how detected hits are judged for their quality. In CamecaRoot this there is something mentioned like golden and partial hits, here is where this could be documented.

sequence_index: (recommended) NX_POSINT ⤆

hit_multiplicity: (recommended) NXprocess

Data post-processing step which is, like the impact position analyses, ...

Data post-processing step which is, like the impact position analyses, usually executed in the integrated control software. This processing yields how many ions were detected with each pulse.

It is possible that multiple ions evaporate and hit the same or different pixels of the detector on the same pulse. These data form the basis to analyses of the so-called (hit) multiplicity of an ion.

Multiplicity must not be confused with how many atoms f the same element or isotope, respectively, a molecular ion contains (which is instead encoded with the isotope_vector field of each NXion instance).

sequence_index: (recommended) NX_POSINT ⤆

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

Number of pulses since the last detected ion pulse. ...

Number of pulses since the last detected ion pulse. For multi-hit records, after the first record, this is zero.

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

Number of pulses since the start of the atom probe ...

Number of pulses since the start of the atom probe run/evaporation sequence.

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

Hit multiplicity.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

ion_filtering: (recommended) NXprocess

Like impact position and hit multiplicity computations, ...

Like impact position and hit multiplicity computations, ion filtering is a data post-processing step with which users identify which of the detected ions should be included in the voltage-and-bowl correction. This post-processing is usually performed via GUI interaction in the reconstruction pipeline of IVAS/APSuite.

sequence_index: (recommended) NX_POSINT ⤆

evaporation_id_included: (required) NX_BOOLEAN (Rank: 1, Dimensions: [n_ions])

Bitmask which is set to true if the ion ...

Bitmask which is set to true if the ion is considered and false otherwise.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

voltage_and_bowl_correction: (recommended) NXprocess

Data post-processing step to correct for ion impact ...

Data post-processing step to correct for ion impact position flight path differences, detector biases, and nonlinearities. This step is usually performed with commercial software.

sequence_index: (recommended) NX_POSINT ⤆

raw_tof: (recommended) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_TIME}

Raw time-of-flight data as read out from the acquisition software ...

Raw time-of-flight data as read out from the acquisition software if these data are available and accessible.

calibrated_tof: (required) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_TIME}

Calibrated time-of-flight.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

tof_calibration: (recommended) NXcollection

The key idea and algorithm of the voltage-and-bowl correction is ...

The key idea and algorithm of the voltage-and-bowl correction is qualitatively similar for instruments of different manufacturers or research groups.

Specific differences exists though in the form of different calibration models. For now we do not wish to resolve or generalize these differences. Rather the purpose of this collection is to provide a container where model-specific parameters and calibration models can be stored if users know these for sure.

For AMETEK LEAP instruments this should be the place for storing initial calibration values. These values are accessible normally only by AMETEK service engineers. They use these for calibrating the detector and instrument.

Users can also use this NXcollection for storing the iteratively identified calibrations which scientists will see displayed in e.g. APSuite while they execute the voltage-and-bowl correction as a part of the reconstruction pipeline in APSuite.

mass_to_charge_conversion: (recommended) NXprocess

Data post-processing step in which calibrated time-of-flight data ...

Data post-processing step in which calibrated time-of-flight data (ToF) are interpreted into mass-to-charge-state ratios.

sequence_index: (recommended) NX_POSINT ⤆

mass_to_charge: (required) NX_FLOAT (Rank: 1, Dimensions: [n_ions]) {units=NX_ANY}

Mass-to-charge-state ratio values.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

parameter: (recommended) NXcollection

Store vendor-specific calibration models here (if available).

reconstruction: (recommended) NXprocess

Data post-processing step to create a tomographic reconstruction ...

Data post-processing step to create a tomographic reconstruction of the specimen based on selected calibrated ion hit positions, the evaporation sequence, and voltage curve data. Very often scientists use own software scripts according to published procedures, so-called reconstruction protocols, i.e. numerical recipes how to compute x, y, z atomic positions from the input data.

sequence_index: (recommended) NX_POSINT ⤆

protocol_name: (required) NX_CHAR

Qualitative statement about which reconstruction protocol was used. ...

Qualitative statement about which reconstruction protocol was used.

Any of these values: bas | geiser | gault | cameca | other

parameter: (required) NX_CHAR

Different reconstruction protocols exist. Although these approaches ...

Different reconstruction protocols exist. Although these approaches are qualitatively similar, each protocol uses different parameters (and interprets these differently). The source code to IVAS/APSuite is not open. For now users should store reconstruction parameter in a collection.

crystallographic_calibration: (required) NX_CHAR

Different strategies for crystallographic calibration of the ...

Different strategies for crystallographic calibration of the reconstruction are possible. The field is required and details should be specified in free-text at least. If the not crystallographic calibration was performed the field should be filled with the n/a, meaning not applied.

reconstructed_positions: (required) NX_FLOAT (Rank: 2, Dimensions: [n_ions, 3]) {units=NX_LENGTH}

Three-dimensional reconstructed positions of the ions. ...

Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space.

xdmf_topology: (required) NX_UINT (Rank: 1, Dimensions: [36]) {units=NX_UNITLESS}

Six equally formatted sextets chained together. For each ...

Six equally formatted sextets chained together. For each sextett the first entry is an XDMF primitive topology key (here 5 for polygon), the second entry the XDMF primitive count value (here 4 because each face is a quad). The remaining four values are the vertex indices.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

visualization: (recommended) NXprocess

xdmf_topology: (required) NX_UINT (Rank: 1, Dimensions: [n_topology]) {units=NX_UNITLESS}

An array of triplets of integers which can serve as a supplementary ...

An array of triplets of integers which can serve as a supplementary array for Paraview to display the reconstructed dataset. The XDMF primitive type is here 1, the number of primitives 1 per triplet, the last integer in each triplet is the identifier of each point starting from zero.

naive_point_cloud_density_map: (required) NXprocess

To get a first overview of the reconstructed dataset, ...

To get a first overview of the reconstructed dataset, the format conversion computes a simple 3d histogram of the ion density using one nanometer cubic bins without applying smoothening algorithms on this histogram.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

DATA: (required) NXdata

A default three-dimensional histogram of the total ...

A default three-dimensional histogram of the total number of ions in each bin obtained via using a rectangular transfer function.

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_CHAR

title: (required) NX_CHAR ⤆

data_counts: (required) NX_NUMBER (Rank: 3, Dimensions: [n_z, n_y, n_x]) {units=NX_UNITLESS} ⤆

Array of counts for each bin.

axis_z: (required) NX_FLOAT (Rank: 1, Dimensions: [n_z]) {units=NX_LENGTH}

Bin center of mass position along the z axis.

@long_name: (required) NX_CHAR

axis_y: (required) NX_FLOAT (Rank: 1, Dimensions: [n_y]) {units=NX_LENGTH}

Bin center of mass position along the y axis.

@long_name: (required) NX_CHAR

axis_x: (required) NX_FLOAT (Rank: 1, Dimensions: [n_x]) {units=NX_LENGTH}

Bin center of mass position along the x axis.

@long_name: (required) NX_CHAR

ranging: (recommended) NXprocess

Data post-processing step in which elemental, isotopic, ...

Data post-processing step in which elemental, isotopic, and/or molecular identities are assigned to the ions. The documentation of these steps is based on ideas described in the literature:

sequence_index: (recommended) NX_POSINT ⤆

number_of_ion_types: (required) NX_UINT {units=NX_UNITLESS}

How many ion types are distinguished. ...

How many ion types are distinguished. If no ranging was performed each ion is of the special unknown type. The iontype ID of this unknown type is 0 which is a reserve value. Consequently, iontypes start counting from 1.

maximum_number_of_atoms_per_molecular_ion: (required) NX_UINT {units=NX_UNITLESS}

Assumed maximum value that suffices to store all relevant ...

Assumed maximum value that suffices to store all relevant molecular ions, even the most complicated ones. Currently a value of 32 is used.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

mass_to_charge_distribution: (recommended) NXprocess

Specifies the computation of the mass-to-charge histogram. ...

Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity, specifically these values are binned. This (NXprocess) stores the settings of this binning.

range_minmax: (required) NX_FLOAT (Rank: 1, Dimensions: [2]) {units=NX_ANY}

Smallest and largest mass-to-charge-state ratio value.

range_increment: (required) NX_FLOAT {units=NX_ANY}

Binning width of the mass-to-charge-state ratio values.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

mass_spectrum: (required) NXdata

A default histogram aka mass spectrum of ...

A default histogram aka mass spectrum of the mass-to-charge-state ratio values.

@signal: (required) NX_CHAR ⤆

@axes: (required) NX_CHAR ⤆

@AXISNAME_indices: (required) NX_CHAR

title: (required) NX_CHAR ⤆

data_counts: (required) NX_NUMBER (Rank: 1, Dimensions: [n_bins]) {units=NX_UNITLESS} ⤆

Array of counts for each bin.

@long_name: (required) NX_CHAR ⤆

axis_mass_to_charge: (required) NX_FLOAT (Rank: 1, Dimensions: [n_bins]) {units=NX_ANY}

Right boundary of each mass-to-charge-state ratio value bin.

@long_name: (required) NX_CHAR

background_quantification: (recommended) NXprocess

Details of the background model which was used to ...

Details of the background model which was used to correct the total counts per bin into counts.

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

peak_search_and_deconvolution: (recommended) NXprocess

How where peaks in the background-corrected in the histogram ...

How where peaks in the background-corrected in the histogram of mass-to-charge-state ratio values identified?

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

PEAK: (optional) NXpeak

label: (recommended) NX_CHAR ⤆

peak_model: (required) NX_CHAR ⤆

THIS DOCSTRING NEEDS CLARIFICATION.

peak_identification: (recommended) NXprocess

PROGRAM: (required) NXprogram

program: (required) NX_CHAR ⤆

@version: (required) NX_CHAR ⤆

ION: (optional) NXion

isotope_vector: (required) NX_UINT ⤆

charge_state: (required) NX_INT ⤆

mass_to_charge_range: (required) NX_FLOAT ⤆

nuclid_list: (recommended) NX_UINT ⤆

name: (recommended) NX_CHAR ⤆

Hypertext Anchors

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

NXDL Source:

https://github.com/nexusformat/definitions/blob/main/contributed_definitions/NXapm.nxdl.xml