2.3.3.3.97. NXevent_data_apm

Status:

base class (contribution), 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.

Having at least one instance for an instance of NXapm is recommended.

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 split 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 identifier_pulse 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 identifier_pulse, 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 identifier_pulse 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:

NXinstrument_apm

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 identifier_pulse the time difference ...

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

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

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

identifier_pulse: (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 identifier_pulse is used to associate thus an information about time when quantities 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, identifier_pulse 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 identifier_pulse 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 identifier_pulse are then [0, 99999] respectively.

instrument: (optional) NXinstrument_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