NXapm¶
Status:
application definition, extends NXobject
Description:
Draft application definition for atom probe tomography and related field-ion microscopy, all summarized as atom probe microscopy experiments.
Symbols:
The symbols used in the schema to specify e.g. dimensions of arrays
Nions
- Groups cited:
NXaperture, NXbeam, NXcollection, NXdata, NXdetector, NXentry, NXinstrument, NXion, NXlens_apm, NXnote, NXpeak, NXpositioner, NXprocess, NXpulser_apm, 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.
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 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 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.
end_time: (recommended) NX_DATE_TIME
ISO 8601-formatted time code with local time zone offset to UTC included when the experiment ended.
program_name: (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 to arrive at derived quantities like ion hit positions (on the detector), calibrated time-of-flight data, and from these results 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 to map between time-of-flight and mass-to-charge data on ion types with which in turn one can 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 to arrive at a useful reconstructed and ranged dataset. Hence, the reason to design the application definition with the acquisition and 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, still all 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 + 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 principal 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. Given the most permanently used email is recommended.
orcid: (recommended) NX_CHAR
Globally unique identifier of the user as offers by services like ORCID or Researcher ID.
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, and at the point in time when, the experiment was performed (e.g. technician operating the microscope, student, postdoc, principal 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: (required) 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.
counter_electrode: (required) NXlens_apm
has_reflectron: (required) NX_BOOLEAN
name: (recommended) NX_CHAR
model: (recommended) NX_CHAR
serial_number: (recommended) NX_CHAR
manufacturer_name: (recommended) NX_CHAR
TRANSFORMATIONS: (optional) NXtransformations
flat_test_data: (required) NXcollection
APERTURE: (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 of within historic the ATO-formatted 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.
laser_or_high_voltage_pulser: (required) NXpulser_apm
pulse_mode: (required) NX_CHAR
Any of these values:
laser|high voltagepulse_frequency: (required) NX_NUMBER {units=NX_FREQUENCY}
pulse_fraction: (required) NX_NUMBER {units=NX_UNITLESS}
pulsed_voltage[Nions]: (recommended) NX_FLOAT {units=NX_VOLTAGE}
standing_voltage[Nions]: (recommended) NX_FLOAT {units=NX_VOLTAGE}
laser_pulser: (optional) NXsource
name: (recommended) NX_CHAR
Given name.
model: (recommended) NX_CHAR
serial_number: (recommended) NX_CHAR
manufacturer_name: (recommended) NX_CHAR
wavelength: (required) NX_FLOAT {units=NX_WAVELENGTH}
pulse_energy: (required) NX_FLOAT {units=NX_ENERGY}
power: (recommended) NX_FLOAT {units=NX_POWER}
TRANSFORMATIONS: (recommended) NXtransformations
laser_beam: (optional) NXbeam
pinhole_position: (recommended) NXcollection
spot_position: (recommended) NXcollection
STAGE_LAB: (required) NXstage_lab
design: (recommended) NX_CHAR
name: (recommended) NX_CHAR
model: (recommended) NX_CHAR
serial_number: (recommended) NX_CHAR
manufacturer_name: (recommended) NX_CHAR
description: (optional) NX_CHAR
base_temperature: (required) NX_FLOAT {units=NX_TEMPERATURE}
Average temperature at the specimen base, i.e. base temperature, during the measurement.
TRANSFORMATIONS: (optional) NXtransformations
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), 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, the is no community-specific API for getting finely granularized access to such control settings. This motivates the current design of the application definition 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 few techniques 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.
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 and is instructed and monitored/supervised by the acquisition/instrument control software (IVAS/APSuite/DAVis). The exact details are, at least in the case of AMETEK instruments (the large majority of installations worldwide) kept proprietary and inaccessible. For instruments like Oxcart individual timing data from the delay-line detector are open and thus community software can be used to decode these data into ion impact positions.
program: (required) NX_CHAR
Given name of the program that was used to perform this computation. Although, for LEAP from AMETEK this is often the same software as one would specify under program_name for the NXentry (usually IVAS or AP Suite), the field is required because in cases where data are post-processed with different software inconsistencies can occur.
@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 pairs or as reported as the result of a not further specified processing from 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 where detected during the pulse as it is possible that multiple ions evaporate and hit the same detector pixel, which forms the foundation to analyses of the so-called multiplicity of the ion. Multiplicity must not be confused with how many atoms of the same element or isotope, respectively, built a molecular ion.
program: (required) NX_CHAR
Given name of the program that was used to perform this computation. Similar comments as to 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 computation ion filtering and are data post-processing steps for identifying which of the detected ions should be included in the voltage-and-bowl correction.
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 are available.
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 but different specific calibration models exists. In the first draft of the application definition 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 available.
reconstruction: (required) 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.
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.
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 an no smoothing of the histogram.
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.
DATA: (required) NXdata
A default three-dimensional histogram of the total number of ions in each bin.
@signal: (required) NX_CHAR
Which is the dependent signal to plot, here the counts.
@axes: (required) NX_CHAR
Which axes are plotted, here the three principal coordinate directions.
@xpos_indices: (required) NX_CHAR
Bin edge end along x.
@ypos_indices: (required) NX_CHAR
Bin edge end along y.
@zpos_indices: (required) NX_CHAR
Bin edge end along z.
@long_name: (required) NX_CHAR
Title of the diagram.
counts[n_x, n_y, n_z]: (required) NX_NUMBER {units=NX_UNITLESS}
Array of counts for each bin.
xpos: (required) NX_NUMBER {units=NX_LENGTH}
Bin positions along the x axis.
@units: (required) NX_CHAR
ypos: (required) NX_NUMBER {units=NX_LENGTH}
Bin positions along the y axis.
@units: (required) NX_CHAR
zpos: (required) NX_NUMBER {units=NX_LENGTH}
Bin positions along the z axis.
@units: (required) NX_CHAR
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 there have been a number of open-source tools been designed for 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. Usually a value of 32 suffices well.
mass_to_charge_distribution: (required) NXprocess
Specifies the computation of the mass-to-charge histogram. Usually mass-to-charge values are studied as an ensemble quantity and binned so document here settings related to (eventual) 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
mass_spectrum: (required) NXdata
A default histogram aka mass spectrum of the mass-to-charge-state ratio values.
@signal: (required) NX_CHAR
Which is the dependent signal to plot.
@axes: (required) NX_CHAR
Which axes are plotted, here counts over bins.
@bin_ends_indices: (required) NX_CHAR
Label of the mass-to-charge-state ratio bin axis.
@long_name: (required) NX_CHAR
Title of the diagram.
counts[Nbins]: (required) NX_NUMBER {units=NX_UNITLESS}
Array of counts for each bin.
bin_ends: (required) NX_NUMBER {units=NX_ANY}
End of mass-to-charge-state ratio bin.
@units: (required) NX_CHAR
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: (required) NX_CHAR
peak_model: (required) NX_CHAR
Any of these values:
empirical|gaussian|lorentzianposition[Nsupport]: (required) NX_NUMBER {units=NX_ANY}
intensity[Nsupport]: (required) NX_NUMBER {units=NX_ANY}
COLLECTION: (optional) NXcollection
Placeholder for additional details and mathematical models used.
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}
isotope_vector[Nivecmax]: (required) NX_UINT {units=NX_UNITLESS}
charge_state: (recommended) NX_INT {units=NX_DIMENSIONLESS}
name: (optional) NX_CHAR
mass_to_charge_range[2, Nranges]: (required) NX_FLOAT {units=NX_ANY}
Hypertext Anchors¶
Table of hypertext anchors for all groups, fields, attributes, and links defined in this class.
