NXapm¶
Status:
application definition, extends NXobject
Description:
Atom probe tomography and field-ion microscopy experiments.
Symbols:
The symbols used in the schema to specify e.g. dimensions of arrays
Nions: Total number of ions collected
Ndldwires: Total number of independent wires in the delay-line detector.
Nsupport: Number of support points for e.g. modeling peaks in the mass-to- charge-state ratio histogram.
Nivecmax: Maximum number of allowed atoms per (molecular) ion (fragment). Needs to match maximum_number_of_atoms_per_molecular_ion.
Nranges: Number of mass-to-charge-state-ratio range intervals mapped on this ion type.
- Groups cited:
NXaperture, NXbeam, NXchamber, NXcollection, NXdata, NXdetector, NXentry, NXinstrument, NXion, NXnote, NXpeak, NXpositioner, NXprocess, NXpulser_apm, NXpump, NXreflectron, NXsample, NXsource, NXstage_lab, NXtransformations, NXuser
Structure:
ENTRY: (required) NXentry
definition: (required) NX_CHAR
Official NeXus NXDL schema to which this entry conforms.
@version: (required) NX_CHAR
Version specifier which enables documentation of modifications to the schema.
experiment_identifier: (required) NX_CHAR
Ideally, a (globally) persistent unique 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
Possibility for leaving a 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 writing these details in prose into this field here.
start_time: (required) NX_DATE_TIME
ISO 8601 formatted time code with local time zone offset to UTC information included when the experiment 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 of the experiment is not relevant - this start time field should be used. Often though it is useful to specify a time interval, i.e. 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 time instances specified it may not be advisable to infer how long the experiment took or for how long data were acquired. More detailed timing data over the course of the experiment have to be collected for such a detailed bookkeeping.
end_time: (recommended) NX_DATE_TIME
ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended.
program: (required) NX_CHAR
Commercial or otherwise given name to the program that was used to acquire/measure the dataset. Atom probe microscopy experiments are nowadays still in most cases controlled via commercial software. These are often designed as 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. Supplementary metadata are kept in a database which is connected to the control software. RHIT and HITS are proprietary binary file formats whose content must not be accessed with software other than of AMETEK (IVAS/AP Suite). In effect, RHIT and HITS store the experiment 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 delivers a dataset with which one 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), calibrated time-of-flight data. These derived quantities are also need to obtain calibrated mass-to-charge-state ratios, and finally the tomographically reconstructed atomic positions. In many cases cases, an APM dataset is useful only if it gets post-processed via so-called ranging. Ranging defines a set of rules how one map between time-of-flight and mass-to-charge data on ion types, i.e. labels. In turn, these labels decode elemental identities and 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 in atom probe not even for the early data acquisition and processing stages until one arrives at a useful reconstructed and ranged dataset. Therefore, the application definition documents not only the measurement but also these key post- processing steps.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result file is numerically recreatable in the same deterministic manner.
run_number: (required) NX_CHAR
Not the specimen name or 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/AP Suite run number. For other instruments, such as the one from Stuttgart or Oxcart from Erlangen, or the instruments in Rouen, use the identifier that is closest in meaning to the LEAP run number. As a destructive microscopy method, 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. # This is how most atom probe groups handle it across the globe.
operation_mode: (required) NX_CHAR
What type of atom probe microscope experiment is performed. This field can be used e.g. by materials database systems to qualitatively filter experiments.
Any of these values:
leap|apt|fim|apt_and_fimexperiment_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 e.g. a ppt, pdf, latex, txt, image, or zip archive …).
thumbnail: (recommended) NXnote
A small image that is representative of the entry. For reconstructed datasets it is recommended to display the reconstruction as a 640x480 pixel jpeg image. 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
operator: (required) NXuser
Contact information of at least the user of the instrument who measured this specimen or 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: (required) NX_CHAR
Email address of the user at the point in time when the experiment was performed. Giving the most permanently used email is recommended.
orcid: (recommended) NX_CHAR
Globally unique identifier of the user as offers by services like ORCID or ResearcherID.
telephone_number: (recommended) 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, or did the user hold when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principle investigator, guest …).
specimen: (required) NXsample
name: (required) NX_CHAR
Descriptive name or identifier with which to distinguish the specimen from all others and especially the parts from where it 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.
sample_history: (required) NX_CHAR
Ideally, a reference to the location of or a (globally persistent) unique 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 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
ISO8601 date and time with local time zone offset to UTC included 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. 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. The user is advised to include these temporal details in 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 considered relevant from a scientific point. 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.
DATA: (required) NXdata
Hard link to a location/locations in the hierarchy of the NeXus file where the data for default plotting are stored.
atom_probe: (required) NXinstrument
Metadata and numerical data of not only the microscope but also the lab in which this microscope is located. An atom probe microscope (experiment) is different compared to a large-scale facility accelerator or an electron microscope 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 an atom probe microscope. Therefore, the reference coordinate system that is usually referred to in NeXus (McStas coordinate system) is modified when using this application definition. Specifically, the reference coordinate system is defined such that it represents the specimen coordinate system. To be consistent with accelerator and microscopy techniques we define that the positive z-axis points outwards from the apex of the specimen into the vacuum, i.e. towards the detector. The coordinate system remains/is a right-handed one. Clockwise rotations are considered positive rotations.
name: (required) NX_CHAR
Given name of the microscope, e.g Raptor, Oxcart, One atom at a time.
location: (recommended) NX_CHAR
Geographic coordinates of the lab or the place where the instrument is installed using GEOREF geocodes ideally.
instrument_manufacturer: (recommended) NX_CHAR
Manufacturer of the entire instrument (e.g. AMETEK/Cameca) to enable e.g. queries in materials database systems for instrument manufacturers. Usually more technical details are needed though to specify the instrument, these should be written into instrument_model and instrument_capabilities.
instrument_model: (required) NX_CHAR
Manufacturer brand/model to enable e.g. queries about microscope models (e.g. LEAP3000XS).
instrument_identifier: (recommended) NX_CHAR
Hardware name/serial number or hash identifier given by the manufacturer to identify the instrument.
instrument_capability: (recommended) NX_CHAR
Free-text list possibly multiple terms of functionalities which the instrument provides.
flight_path_length: (required) NX_FLOAT {units=NX_LENGTH}
The space inside the atom probe that ions pass through when they leave the specimen and travel to the detector.
has_reflectron: (recommended) NX_BOOLEAN
analysis_chamber: (optional) NXchamber
load_lock_chamber: (optional) NXchamber
buffer_chamber: (optional) NXchamber
getter_pump: (optional) NXpump
roughening_pump: (optional) NXpump
turbomolecular_pump: (optional) NXpump
REFLECTRON: (recommended) NXreflectron
Device for reducing flight time differences of ions in ToF experiments.
name: (recommended) NX_CHAR
Given name.
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.
description: (recommended) NX_CHAR
Free-text field to specify further details about the reflectron. The quantity can inform for instance if the reflectron is flat or curved.
TRANSFORMATIONS: (optional) NXtransformations
Affine transformation(s) which detail where the reflectron is located relative to e.g. the origin of the specimen space reference coordinate system. This group can also be used for specifying how the reflectron is rotated relative to the specimen axis. The purpose of these more detailed instrument descriptions is to support the creation of a digital twin of the instrument for computational science.
flat_test_data: (recommended) NXcollection
NEED FOR FURTHER DISCUSSIONS WITH APM COLLEAGUES WHAT IS RELEVANT HERE.
counter_electrode: (required) NXaperture
description: (recommended) NX_CHAR
An (ideally globally persistent) unique identifier, link, or text which gives further details.
ion_detector: (required) NXdetector
Details about the detector which is used to collect raw time-of-flight data and ion/hit impact positions.
type: (recommended) NX_CHAR
Description of the detector type. Specify if the detector is not the usual type of delay-line detectors.
Any of these values:
mcp_dld|phosphor_ccdname: (recommended) NX_CHAR
Given name.
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[Nions]: (optional) NX_FLOAT {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 in Rouen, France.
TRANSFORMATIONS: (optional) NXtransformations
Affine transformation which aligns the Cartesian right-handed coordinate system which defines the detector space with the specimen space. In atom probe microscopy a frequently used choice is to discuss 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 coordinate system and a specimen-affixed coordinate system. The transformation here resolves this ambiguity by specifying how the positive z-axes of either coordinate systems can be oriented.
pulser: (required) NXpulser_apm
pulse_mode: (required) NX_CHAR
Any of these values:
laser|high_voltage|laser_and_high_voltagepulse_frequency: (required) NX_NUMBER {units=NX_FREQUENCY}
Frequency with which the high voltage or laser pulser fires.
pulse_fraction: (required) NX_NUMBER {units=NX_UNITLESS}
Fraction of the pulse_voltage that is applied in addition to the standing_voltage at peak voltage of a pulse.
pulsed_voltage[Nions]: (recommended) NX_FLOAT {units=NX_VOLTAGE}
NEED TO DISCUSS WITH APM COLLEAGUES IN MORE DETAIL WHAT THIS IS SPECIFICALLY!
standing_voltage[Nions]: (recommended) NX_FLOAT {units=NX_VOLTAGE}
Direct current voltage between the specimen and the (local electrode) in the case of a LEAP instrument.
laser_pulser: (optional) 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 in an atom probe microscopy experiment. # Many microscopes have a laser installed which enables measurements also with poorly conductive specimens.
name: (recommended) NX_CHAR
Given name.
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.
wavelength: (required) NX_FLOAT {units=NX_WAVELENGTH}
Nominal wavelength of the laser radiation.
power: (recommended) NX_FLOAT {units=NX_POWER}
Average power of the laser source while illuminating the specimen.
pulse_energy: (recommended) NX_FLOAT {units=NX_ENERGY}
Average (??) energy of the laser at peak of (each) ?? pulse.
TRANSFORMATIONS: (recommended) NXtransformations
Set of transformations which describe the geometry between how the laser focusing optics/pinhole-attached coordinate system is defined, how it has to be transformed so that it aligns with the specimen coordinate system. A right-handed Cartesian coordinate system, the so- called laser space, should be assumed, whose positive z-axis points into the direction of the propagating laser beam.
laser_beam: (optional) NXbeam
Details about specific positions along the focused laser beam which illuminates the atom probe specimen.
pinhole_position: (recommended) NXcollection
Track time-dependent settings over the course of the measurement where the laser beam exits the focusing optics.
spot_position: (recommended) NXcollection
Track time-dependent settings over the course of the measurement where the laser hits the specimen.
STAGE_LAB: (required) NXstage_lab
design: (recommended) NX_CHAR
Principal design of the stage.
name: (recommended) NX_CHAR
Given name.
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.
description: (optional) NX_CHAR
Ideally a link to a (globally persistent) unique identifier which documents or can be used to infer further details of the component. If such a resource is not available, use this field for a free-text description and describe further details to the stage.
base_temperature: (required) NX_FLOAT {units=NX_TEMPERATURE}
Average temperature at the specimen base, i.e. base temperature, during the measurement.
TRANSFORMATIONS: (optional) NXtransformations
Set of transformations which describe how the stage-affixed coordinate system is defined and how it has to be transformed so that it aligns with the specimen coordinate system.
POSITIONER: (optional) NXpositioner
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 individual 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. This motivates the current design of the application definition which stores quantities to begin with via an NXcollection. Holding heterogeneous, not yet standardized, but relevant pieces of information is the purpose of this collection.
analysis_chamber: (required) NXcollection
Track time-dependent settings over the course of the measurement about the environment in the analysis chamber such as gas pressure values etc.
pressure: (required) NX_FLOAT {units=NX_PRESSURE}
Average pressure in the analysis chamber.
specimen_monitoring: (optional) 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 only to measure the shape evolution: One is via correlative electron microscopy but this usually evolves an interrupted experiment in which the specimen is transferred, an image taken, and a new evaporation sequence initiated. Another, less accurate method, 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 (pioneered by the imec group, Belgium). A continuous monitoring of the specimen in an correlative electron microscopy/atom probe experiment is planned to be developed by the Jülich group (Dunin-Borkowski/Gault).
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.
ion_impact_positions: (optional) NXprocess
This group in the hierarchy should be used to store the ion hit positions. Data post-processing step of analog-to-digital conversion of the 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, at least in the case of AMETEK instruments, which applies to the majority of atom probe microscopes, kept proprietary and inaccessible. For instruments build 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. Although for LEAP instruments this program is often the same software as one would specify under program for the NXentry (usually IVAS or AP Suite), the field is required because in cases where data is post- processed with different software it would not be possible to distinguish which portions of the dataset were computed with which software.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
arrival_time_pairs[2, Ndldwires, Nions]: (recommended) NX_NUMBER {units=NX_TIME}
Three-dimensional array of raw readings from the analog-to-digital- converter timing circuits of the detector wires.
hit_positions[2, Nions]: (required) NX_FLOAT {units=NX_LENGTH}
Evaluated ion impact coordinates at the detector (either as computed from the arrival time data or as reported as the result of a not necessarily further specified processing within commercial control software.
detection_rate: (required) NX_FLOAT {units=NX_DIMENSIONLESS}
Average detection rate over the course of the experiment.
hit_multiplicity: (recommended) NXprocess
Data post-processing step which is, like the impact position analyses, also usually executed in the integrated control software. This processing yields how many ions were detected with each pulse. In fact, 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 of the same element or isotope, respectively, a molecular ion contains. By contrast, this latter multiplicity is encoded in the (isotope_vector) field within in a (NXion) instance.
program: (required) NX_CHAR
Given name of the program that was used to perform this computation. Similar comments as for ion_impact_positions apply.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
pulses_since_last_ion[Nions]: (optional) NX_UINT {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[Nions]: (recommended) NX_UINT {units=NX_UNITLESS}
Hit multiplicity.
pulse_id[Nions]: (optional) NX_UINT {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 when 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 commercial analysis software like IVAS/APSuite.
program: (required) NX_CHAR
Given name of the program that was used to perform this computation. Similar comments as to hit_multiplicity apply.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
evaporation_id_included[Nions]: (required) NX_BOOLEAN
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. Also this step is usually performed with commercial software.
program: (required) NX_CHAR
Given name of the program that was used to perform this computation. Similar comments as to ion_filtering apply.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
raw_tof[Nions]: (recommended) NX_FLOAT {units=NX_TIME}
Raw time-of-flight data as read-out from the acquisition software if these data are or accessible.
calibrated_tof[Nions]: (required) NX_FLOAT {units=NX_TIME}
Calibrated time-of-flight.
tof_calibration: (optional) 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 systems this should be the place for storing initial calibration values. These values are accessible normally only by AMETEK service engineers and used by them for calibrating for the detector and instrument. Furthermore, one could then also store here the iteratively identified calibrations which scientists will get displayed in e.g. AP Suite while executing the voltage-and-bowl correction as part of the reconstruction pipeline.
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. Similar comments as voltage_and_bowl_correction apply.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
mass_to_charge[Nions]: (required) NX_FLOAT {units=NX_ANY}
Mass-to-charge-state ratios
parameter: (recommended) NXcollection
Like for the voltage-and-bowl correction, this collection should be used for storing vendor-specific calibration models if these are 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, 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
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
protocol_name: (recommended) NX_CHAR
Qualitative statement about which algorithmic approach, i.e. reconstruction protocol was used.
Any of these values:
bas_original
bas_modified
geiser
gault
ivas
apsuite
otherreconstructed_positions[3, Nions]: (required) NX_FLOAT {units=NX_LENGTH}
Three-dimensional reconstructed positions of the ions. Interleaved array of x, y, z positions in the specimen space.
reconstruction_parameter: (recommended) NXcollection
Different models and associated algorithms, i.e. (numerical) protocols exist to reconstruct atom probe data. 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 we store the reconstruction parameter in a collection.
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 (M. K”uhbach et al. 2021, Microsc. Microanal.).
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 been designed for executing this task. Therefore, it is essential to document which tool was used.
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner.
number_of_iontypes: (required) NX_UINT {units=NX_UNITLESS}
How many ion types are distinguished.
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. The (NXprocess) stores the settings of this binning.
program: (required) NX_CHAR
Given name of the program that was used to perform this binning. If the computation is a integrated into the ranging tool, type .
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type .
range_minmax[2]: (required) NX_FLOAT {units=NX_ANY}
Smallest and largest mass-to-charge value.
range_increment: (required) NX_FLOAT {units=NX_ANY}
Binning width
background_quantification: (recommended) NXprocess
Details of the background model which was used to correct the total counts per bin into used counts.
program: (required) NX_CHAR
Given name of the program that was used to perform the background quantification. If the computation is a integrated into the ranging tool, type .
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type .
peak_search_and_deconvolution: (recommended) NXprocess
How where peaks in the background-corrected mass-to-charge histogram identified.
program: (required) NX_CHAR
Given name of the program that was used to search and detect peaks. If the computation is a integrated into the ranging tool type .
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type .
PEAK: (optional) NXpeak
List of peaks.
label: (optional) NX_CHAR
Human-readable identifier to specify which concept/entity the peak identifies.
peak_model: (required) NX_CHAR
Is the peak described analytically via a functional form or is it described empirically via measured/reported intensity/counts as a function of an independent variable.
Any of these values:
empirical|gaussian|lorentzianposition[Nsupport]: (required) NX_NUMBER {units=NX_ANY}
In the case of an empirical description of the peak and its shoulders, this array holds the positions were independent variable values were taken.
intensity[Nsupport]: (required) NX_NUMBER {units=NX_ANY}
In the case of an empirical description of the peak and its shoulders, this array holds the intensity/count values at each position.
COLLECTION: (optional) NXcollection
In the case of an analytical description this group can be used to hold parameter of the functional form. For example in the case of Gaussian peaks mu, sigma, and cut-off values and background intensity.
peak_identification: (recommended) NXprocess
Details about how peaks, with taking into account error models, were interpreted as an iontype or not.
program: (required) NX_CHAR
Given name of the program that was used to perform identify peaks. If the computation is a integrated into the ranging tool, type .
@version: (required) NX_CHAR
Ideally program version plus build number, or commit hash or description of ever persistent resources where the source code of the program and build instructions can be found so that the program can be configured ideally in such a manner that the result of this computational process is recreatable in the same deterministic manner. If the version is the same as for the ranging tool, type .
ION: (optional) NXion
The individual ions and their set of mass-to-charge intervals (ranges). If ranging was performed as a computational step then the NeXus-writing software needs to assure that there is always a default ion type which is the unknown ion type. By definition this unknown type has 0 as the id and a default associated mass-to-charge-state ratio interval of [0, 0.001] Da.
ion_type: (required) NX_UINT {units=NX_UNITLESS}
Ion type (ion species) identifier. The identifier zero is reserved for the special unknown ion type.
isotope_vector[Nivecmax]: (required) NX_UINT {units=NX_UNITLESS}
A vector of isotope hash values. These values have to be stored in a decreasingly sorted array. The array is filled with zero hash values indicating unused places. The individual hash values are built with the following hash function: Hashvalue = Z + N*256 with Z the number of protons and N the number of neutrons of the isotope respectively. Z and N have to be 8-bit unsigned integers.
charge_state: (recommended) NX_INT {units=NX_DIMENSIONLESS}
Signed charge state of the ion in multiples of the elementary electron charge. Only positive values will be measured in atom probe microscopy as the ions are accelerated by a negatively signed bias electric field. In the case that the charge state is not explicitly recoverable, the value should be set to zero. This is for example the case when using classical range file formats like RNG, RRNG for atom probe data. These file formats do not document the charge state explicitly but report an integer with the atom type which can be used to compute the charge state via the theoretically-known mass-to- charge-state-ratios of the elements.
name: (optional) NX_CHAR
Human-readable ion type name (e.g. Al +++), i.e. ASCII UTF-8 character array, ideally using LaTeX notation to specify the ion and charge state. Examples are 12C+ or Al+++. Although this name may be human- readable and intuitive, parsing such names becomes impractical for more complicated cases. Therefore, the isotope_vector should be the preferred machine-readable format in use.
mass_to_charge_range[2, Nranges]: (required) NX_FLOAT {units=NX_ANY}
Associated lower (mqmin) and upper (mqmax) bounds of mass-to-charge- state ratio interval(s) [mqmin, mqmax] (boundaries included) for which the respective ion is labelled as an ion of the here referred to ion_type.
Hypertext Anchors¶
Table of hypertext anchors for all groups, fields, attributes, and links defined in this class.
