NXapm

Status:

application definition, 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_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 mapped on 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.

Groups cited:

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

Structure:

ENTRY: (required) NXentry

@version: (required) NX_CHAR

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.

Obligatory value: NXapm

experiment_identifier: (required) NX_CHAR

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

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

experiment_description: (optional) NX_CHAR

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 this application definition rather than write details about the experiment into this free-text description field.

start_time: (recommended) NX_DATE_TIME

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

program: (required) NX_CHAR

Commercial or otherwise given name to the program which was used to create the original results file of the atom probe experiment. This file and program should not be confused with downstream processing operations and file format conversion tasks.

Atom probe microscopy experiments are except for still very much cases controlled via commercial software. Such software 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 RHIT and HITS files, which are proprietary and the specifications of which are not publicly documented.

Supplementary metadata are kept in a database which is connected to the instrument control software and synced with the experiment while signal is being 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 to resolve 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 data acquisition and processing stages to obtain a useful reconstructed and ranged dataset.

Therefore, 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 vendors could improve this description to cover a substantial larger number of eventually metadata that so far are not publicly documented and accessible in an open-source manner.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

run_number: (required) NX_CHAR

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.

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 to store the entire set of such interrupted runs to be stored and covered. However, this is not because of a technical limitation within NeXus but because we have not seen a covering use case based on which we could have implemented and conceptualized this. 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. 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

experiment_documentation: (optional) NXnote

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

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

Contact information and eventually details of at least one person involved in the taking of 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 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 was performed. Writing the most permanently used email is recommended.

orcid: (recommended) NX_CHAR

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

Name of the OrcID or ResearcherID where the account under orcid is registered.

telephone_number: (optional) NX_CHAR

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

Account name that is associated with the user in social media platforms.

social_media_platform: (optional) NX_CHAR

Name of the social media platform where the account under social_media_name is registered.

specimen: (required) NXsample

name: (required) NX_CHAR

Descriptive name or ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the predecessor/origin from where the specimen was cut. In cases where the specimen was e.g. site-specifically cut from samples 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 specimens were cut/prepared from samples in the sample history. This field must not be used for an alias of the specimen. Instead, use short_title.

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 should be used only for the characterization of a single specimen in a single continuous run.

Details about the specimen preparation should be stored in the sample history.

sample_history: (required) NX_CHAR

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

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.

short_title: (optional) NX_CHAR

Possibility to give an abbreviation of the specimen name field.

atom_types: (required) NX_CHAR

Use Hill’s system for listing elements of the periodic table which are inside or attached to the surface of the specimen, and thus relevant from a scientific point of view.

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 for the sample_history are not available.

DATA: (optional) NXdata

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.

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):

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

  • 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 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 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. Using GEOREF is preferred.

flight_path_length: (required) NX_FLOAT {units=NX_LENGTH}

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

FABRICATION: (required) NXfabrication

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

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

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

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

local_electrode: (required) NXlens_em

A local electrode guiding the ion flight path.

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

ion_detector: (required) NXdetector

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

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.

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

laser_gun: (recommended) NXsource

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

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

laser_beam: (recommended) 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. base_temperature during the measurement.

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

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

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

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

getter_pump: (optional) NXpump

design: (recommended) NX_CHAR

FABRICATION: (optional) NXfabrication

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

roughening_pump: (optional) NXpump

design: (recommended) NX_CHAR

FABRICATION: (optional) NXfabrication

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

turbomolecular_pump: (optional) NXpump

design: (recommended) NX_CHAR

FABRICATION: (optional) NXfabrication

identifier: (recommended) NX_CHAR

capabilities: (optional) NX_CHAR

specimen_monitoring: (recommended) NXcollection

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 initial radius of the specimen.

shank_angle: (required) NX_FLOAT {units=NX_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.

control_software: (required) NXcollection

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) NX_CHAR

Name of the control software of the microscope used during acquisition (e.g. IVAS/APSuite).

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

buffer_chamber: (optional) NXcollection

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

analysis_chamber: (optional) NXcollection

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

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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 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 (either as computed from the arrival time data or as reported by the control software).

hit_multiplicity: (recommended) NXprocess

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

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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

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

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

Hit multiplicity.

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

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

ion_filtering: (recommended) NXprocess

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.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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

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

voltage_and_bowl_correction: (recommended) NXprocess

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.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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

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

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

Calibrated time-of-flight.

tof_calibration: (recommended) NXcollection

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 (ToF) are interpreted into mass-to-charge-state ratios.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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

Mass-to-charge-state ratio values.

parameter: (recommended) NXcollection

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

reconstruction: (recommended) NXprocess

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.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Similar comments as voltage_and_bowl_correction apply.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

protocol_name: (required) NX_CHAR

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 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 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. Interleaved array of x, y, z positions in the specimen space.

naive_point_cloud_density_map: (required) NXprocess

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) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

DATA: (required) NXdata

A default three-dimensional histogram of the total number of ions in each bin.

@long_name: (required) NX_CHAR

Naive point cloud density map.

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

Array of counts for each bin.

zpos: (required) NX_NUMBER {units=NX_LENGTH}

Bin positions along the z axis.

ypos: (required) NX_NUMBER {units=NX_LENGTH}

Bin positions along the y axis.

xpos: (required) NX_NUMBER {units=NX_LENGTH}

Bin positions along the x axis.

ranging: (recommended) NXprocess

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:

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

number_of_ion_types: (required) NX_POSINT {units=NX_UNITLESS}

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 molecular ions, even the most complicated ones. Currently a value of 32 is used.

mass_to_charge_distribution: (recommended) NXprocess

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.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

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.

mass_spectrum: (required) NXdata

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

@long_name: (required) NX_CHAR

Mass-to-charge-state histogram.

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

Array of counts for each bin.

bin_ends: (required) NX_NUMBER {units=NX_ANY}

End of value for each mass-to-charge-state ratio bin.

background_quantification: (recommended) NXprocess

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

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

peak_search_and_deconvolution: (recommended) NXprocess

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

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

PEAK: (optional) NXpeak

label: (recommended) NX_CHAR

peak_model: (required) NX_CHAR

peak_identification: (recommended) NXprocess

Details about how peaks, with taking into account error models, were interpreted as ion types or not.

program: (required) NX_CHAR

Given name of the program that was used to perform this computation. Apart from the classical approach to use AMETEK software for this processing step, a number of open-source alternative tools exists.

@version: (required) NX_CHAR

Program version plus build number, commit hash, or description of an ever persistent resource where the source code of the program and build instructions can be found so that the program can be configured in such a manner that the result file is ideally recreatable yielding the same results.

ION: (required) NXion

isotope_vector: (required) NX_UINT

nuclid_list: (recommended) NX_UINT

charge_state: (required) NX_INT

mass_to_charge_range: (required) NX_FLOAT

Hypertext Anchors

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

NXDL Source:

https://github.com/FAIRmat-Experimental/nexus_definitions/tree/fairmat/contributed_definitions/NXapm.nxdl.xml