2.3.3.3.120. NXevent_data_apm

Status:

base class, extends NXobject

Description:

Base class to store state and (meta)data of events over the course of an atom pr ...

Base class to store state and (meta)data of events over the course of an atom probe experiment.

This base class applies the concept of the NXevent_data_em base class to the specific needs of atom probe research. Against static and dynamic quantities are splitted to avoid a duplication of information. Specifically, the time interval considered is the entire time starting at start_time until end_time during which we assume the pulser triggered named pulses. These pulses are identified via the pulse_identifier field. The point in time when each was issued is specified via the combination of start_time and delta_time.

Conceptually and technically NeXus currently stores tensorial information as arrays of values (with each value of the same datatype). For instance, a field temperature(NX_FLOAT) stores a set of temperature values but that field when used somewhere is a concept. However, that concept has no information at which point in time these temperatures were taken. An existent functional relationship between the two concepts is not defined.

However, a correct interpretation of the temperature values demands knowledge about what is the independent quantity on which temperature depends on or according to which frequency temperature values were sampled. In NeXus there are two approaches which cope with such correlations: One is NXdata where the attribute signal specifies the correlation. The other one is NXlog which, like NXdata, demands to granularize logged_against (dependent signal) and independent quantities into an own group. In many cases this additional grouping is not desired though.

One naive solution typically employed is then to store the independent variable values via a second vector e.g. time_stamp with the same number of entries (with dimensionality defined through symbols). However, there is no independent logical connection between these two concepts, i.e. temperature and time_stamp.

In the case of atom probe though the time that one would use in NXlog is defined implicitly via pulse_identifier, which is the independent variable vector against which eventually dozens of channels of data are logged. Not only are these channels logged they should ideally also be self-descriptive in that these channels have pulse_identifier as the independent variable but we do not wish to duplicate this information all the time but reference it.

Therefore, we here explore the use of an attribute with symbol logged_against. Maybe it is better to use the symbol depends_on but this is easily to be confused with depends_on that is used for instances of NXtransformations. Consequently, if depends_on were to be used extra logic is needed by consuming applications to understand that the here build correlations are conceptually different ones.

This issue should be discussed further by the NeXus community.

Symbols:

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

p: Number of pulses collected in between start_time and end_time.

Groups cited:

NXchamber, NXcollection, NXdetector, NXinstrument, NXlens_em, NXpulser_apm, NXreflectron, NXstage_lab

Structure:

start_time: (optional) NX_DATE_TIME

ISO 8601 time code with local time zone offset to UTC information included ...

ISO 8601 time code with local time zone offset to UTC information included when the snapshot time interval started. If the user wishes to specify an interval of time that the snapshot should represent during which the instrument was stable and configured using specific settings and calibrations, the start_time is the start (left bound of the time interval) while the end_time specifies the end (right bound) of the time interval.

end_time: (optional) NX_DATE_TIME

ISO 8601 time code with local time zone offset to UTC information included ...

ISO 8601 time code with local time zone offset to UTC information included when the snapshot time interval ended.

delta_time: (optional) NX_NUMBER (Rank: 1, Dimensions: [p]) {units=NX_TIME}

Delta time array which resolves for each pulse_identifier the time difference ...

Delta time array which resolves for each pulse_identifier the time difference between when that pulse was issued and start_time.

In summary, using start_time, end_time, delta_time, pulse_identifier_offset, and pulse_identifier exactly specifies the connection between when a pulse was issued relative to start and absolute in UTC.

pulse_identifier_offset: (optional) NX_INT {units=NX_UNITLESS}

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

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

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

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

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

pulse_identifier: (optional) NX_INT (Rank: 1, Dimensions: [p]) {units=NX_UNITLESS}

Identifier that contextualizes how the detector and pulser of an atom probe ...

Identifier that contextualizes how the detector and pulser of an atom probe instrument follows a sequence of pulses to trigger field evaporation.

The pulse_identifier is used to associate thus an information about time when the quantities documented in this NXpulser_apm base class have been collected via sampling.

In virtually all cases the pulser is a blackbox. Depending on how the instrument is configured during a measurement the target values and thus also the actual values may change.

Maybe the first part of the experiment is run at a certain pulse fraction but thereafter the pulse_fraction is changed. In this case the field pulse_fraction is a vector which collects all measured values of the pulse_fraction, pulse_identifier is then an equally long vector which stores the set of events (e.g. pulsing events) when that value was measured.

This may cause several situations: In the case that e.g. the pulse_fraction is never changed and also exact details not interesting, one stores the set value for the pulse_fraction and a single value for the pulse_identifier e.g. 0 to indicate that the pulse_fraction was set at the beginning and it was maintained constant during the measurement. If the pulse_fraction was maybe changed after the 100000th pulse, pulse_fraction is a vector with two values one for the first and another one for the value from the 100000-th pulse onwards. The values of pulse_identifier are then [0, 99999] respectively.

instrument: (optional) NXinstrument

(Meta)data of the dynamics and changes of the microscope over the course of ...

(Meta)data of the dynamics and changes of the microscope over the course of pulsing.

control: (optional) NXcollection ⤆

Relevant quantities during a measurement with a LEAP system as suggested by ...

Relevant quantities during a measurement with a LEAP system as suggested by T. Blum et al..

evaporation_control: (optional) NX_CHAR

Obligatory value: detection_rate

target_detection_rate: (optional) NX_FLOAT {units=NX_ANY}

REFLECTRON: (optional) NXreflectron

local_electrode: (optional) NXlens_em

ion_detector: (optional) NXdetector ⤆

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

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

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

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

pulser: (optional) NXpulser_apm

stage_lab: (optional) NXstage_lab

setpoint_temperature: (optional) NX_FLOAT {units=NX_TEMPERATURE}

Set point temperature to achieve during the measurement.

base_temperature: (optional) NX_FLOAT {units=NX_TEMPERATURE}

Average temperature (at the specimen base) during the measurement.

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

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

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

@logged_against: (optional) NX_CHAR

Path to pulse_identifier in an instance of NXevent_data_apm.

analysis_chamber: (optional) NXchamber

chamber_pressure: (optional) NX_FLOAT {units=NX_PRESSURE}

Average pressure in the analysis chamber during the measurement.

pressure: (optional) NX_FLOAT (Rank: 1, Dimensions: [p]) {units=NX_PRESSURE}

Pressure in the analysis chamber.

@logged_against: (optional) NX_CHAR

Path to pulse_identifier in an instance of NXevent_data_apm.

buffer_chamber: (optional) NXchamber

pressure: (optional) NX_FLOAT (Rank: 1, Dimensions: [p]) {units=NX_PRESSURE}

Pressure in the analysis chamber.

@logged_against: (optional) NX_CHAR

Path to pulse_identifier in an instance of NXevent_data_apm.

load_lock_chamber: (optional) NXchamber

pressure: (optional) NX_FLOAT (Rank: 1, Dimensions: [p]) {units=NX_PRESSURE}

Pressure in the analysis chamber.

@logged_against: (optional) NX_CHAR

Path to pulse_identifier in an instance of NXevent_data_apm.

Hypertext Anchors

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

NXDL Source:

https://github.com/FAIRmat-NFDI/nexus_definitions/tree/fairmat/contributed_definitions/NXevent_data_apm.nxdl.xml