3.3.3.94. NXem¶
Status:
application definition (contribution), extends NXobject
Description:
Characterization of a sample during a session on an electron microscope. ...
Characterization of a sample during a session on an electron microscope.
The idea and aim of NXem: Electron microscopy (EM) research, whether it be performed with scanning electron microscope (SEM) or transmission electron microscope (TEM) instruments, uses versatile tools for preparing and characterizing samples and specimens. The term specimen is considered a synonym for sample in this application definition. A specimen is a physical portion of material that is studied/characterized during the microscope session, eventually in different places on the specimen surface, illuminating the surface layers or shining through thin specimens. These places are named regions of interest (ROIs).
Fundamentally, an electron microscope is an electron accelerator. Experimentalists use it in sessions during which they characterize as well as prepare specimens. This application definition describes data and metadata about processes and characterization tasks applied to one specimen. The application definition focuses on the usage of EM in materials research. The application definition design makes it in principle applicable also in cryo-EM on biomaterials.
Multiple specimens have to be described with multiple NXentry instances.
Electron microscopes motivate the development of a comprehensive data schema: There are research groups who use an EM in a manner where it is exclusively operated by a single, instrument-responsible scientists or a team of scientists. These users may perform analyses for other users as a service task, especially in large research facility settings. Oftentimes, though, and especially for cutting-edge instruments, the scientists guide the process and maybe even control the microscope. Instruments are usually controlled on-premises but also more and more functionalities for remote control have become available. Scientists oftentimes can ask technicians for support. In all cases, these people are considered users. Users might have different roles though.
The rational behind a common EM schema rather than making separate schemas for SEM or TEM are primarily the key similarities of SEM and TEM instruments:
Both type of instruments have electro-magnetic lenses. These may differ in design, alignment, number, and level of corrected for aberrations. As an obvious difference, a TEM is mainly used for measuring the transmitted electron beam. This calls for using a different lens setup and relative placement of the specimen in the lens setup. Also TEM specimens are substantially thinner than specimens characterized with SEM to enable an illumination through the specimen. This offers capabilities for probing of additional physical mechanisms of electron-matter interaction which are unavailable in SEMs.
Nevertheless, both types of electron microscopes use detector systems which measure different types of signals that originate from the same set of radiation/specimen interactions. Often these detectors have a similar design and technology or are even used both in SEMs and TEMs.
A comprehensive schema instead of specific SEM or TEM schemas: Given these physical and technical differences, different instruments have been developed. This led to a coexistence of two broad interacting communities: SEM and TEM users. From a data science perspective, we acknowledge that the more specific a research question is and the narrower it is the addressed circle of users which develops or uses schemas for research data management (RDM) with EM, the more understandable it is that scientists of either community (or sub-community) ask for designing method-specific schemas.
Researchers who have a single (main) microscope of some vendor in their lab, may argue they need an NXem_vendor_name schema or an NXem_microscope_name or an NXem_sem or a NXem_tem schema. Scientists exclusively working with one technique or type of signal probed (X-rays, electrons) may argue they wish to be pragmatic and store only what is immediately relevant for their particular technique and research questions. In effect, they may advocate for method-specific schemas such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging.
However, the history of electron microscopy has shown that these activities led to a zoo of schemas and vocabulary, with implementation in many data and file formats, difficult to make interoperable. Instead of trying to maintain this, we would like to advocate that the FAIR principles should guide all decisions how data and metadata should be stored.
EM instruments, software, and research are moving targets. Consequently, there is a key challenge and inconvenience with having many different schemas with associated representations of data and metadata: Each combination of schemas or an interoperable-made handshake between two file formats or software packages has to be maintained by software developers. This counts especially when data should be processed interoperably between software packages.
This brings two problems: Many software tools and parsers for the handshaking between tools have to be maintained. This can result in usage of different terminology, which in turn results in representations and connections made between different data representations and workflows that are not machine-actionable. There are community efforts to harmonize the terminology.
The advantage of working towards a common vocabulary and representation: A common vocabulary can serve interoperability as developers of schemas and scientists can reuse for instance these terms, thus supporting interoperability. Ideally, scientists specialize an application definition only for the few very specific additional quantities of their instruments and techniques. This is better than reimplementing the wheel for descriptions of EM instruments. This route of more standardization can support the EM community in that it removes the necessity for having to maintain a very large number of schemas.
Aiming for more standardization, i.e. a lower number of schemas rather than a single standard for electron microscopy is a compromise that can serve academia and industry as it enables a focusing of software development efforts on those schemas, on fixing and discussing them, and on harmonizing their common vocabulary. These activities can be specifically relevant also for technology partners building EM hard- and software as it improves the longevity of certain schemas; and thus can help with incentivizing them to support the community with implementing support for such schemas into their applications.
In effect, everybody can gain from this as it will likely reduce the cases in which scientists have to fix bugs in making their own tools compliant and interoperable with tools of their colleagues and the wider community.
The here proposed NXem application definition offers modular components (EM-research specific base classes) for defining schemas for EM research. Thereby, NXem can be useful to extends top-level ontologies towards a domain- and method-specific ontology for electron microscopy as it is used for materials research.
Working towards a common vocabulary is a community activity that profits from everybody reflecting in detail whether certain terms they have used in the past are not eventually conceptually similar if not the same as what this application definition and its base classes provide. We are happy for receiving your feedback.
Addressing the generality versus specificity challenge: It is noteworthy to understand that (not only for NeXus), schemas differ already if at least one field is required in one version of the schema, but it is set optional in another schema. If group(s), field(s), or attributes are removed or added, or even a docstring is changed, schemas can become inconsistent. It is noteworthy to mention that the idea of a NeXus application definition serves as a contract between a data provider and a data consumer. Providers can be the software of a specific microscopes or users with specific analysis needs. Consumers can be again specific software tools, like vendor software for controlling the instrument or a scientific software for doing artificial intelligence analyses on EM data). Such changes of a schema lead to new versions.
Verification of constraints and conditions: Tools like NeXus do not avoid or protect against all such possible inconsistencies; however NeXus offers a mechanism and toolset, through which schemas can be documented and defined. In effect, having an openly documented (at a case-specific level of technical detail) schema is a necessary but alone not a sufficient step to take EM research on a route of machine-actionable and interoperable FAIR data.
This stresses again the fundamental and necessary role of working towards a common vocabulary and, with a longer perspective in mind, a machine-actionable knowledge representation and verification engine. So far many conditions and requirements are formulated in the docstrings of the respective entries of the application definition.
NXem takes a key step towards standardization of EM data schemas. It offers a controlled vocabulary and set of relations between concepts and enables the description of the data which are collected for research with electron microscopes. To be most efficient and offering reusability, the NXem application definition should be understood as a template that one should ideally use as is. NXem can be considered a base for designing more specialized definitions. These should ideally be prefixed with NXem_method (e.g. NXem_ebsd).
The use of NXem should be as follows: Offspring application definitions should not remove groups but leave these optional or, even better, propose changes to NXem.
A particular challenge with electron microscopes as physical instruments are their dynamics. To make EM data understandable, repeatable, and eventually corresponding experiments reproducible in general requires a documentation of the spatio-temporal dynamics of the instrument in its environment. It is questionable to which level such a reproducibility is possible with EM at all considering beam damage, effects of the environment, and other not exactly quantifiable influences. While this points to the physical limitations there are also practical and economical constraints on how completely EM research can be documented: For most commercial systems there is a specific accessibility beyond which detailed settings like lens excitations and low-level hardware settings may not be retrievable as technology partners have a substantiated interest in finding a compromise between being open to their users and securing their business models.
By design, EM experiments illuminate the specimen with electrons as a consequence of which the specimen changes if not may get destroyed. As such, repeatability of numerical processing and clear descriptions of procedures and system setups should be addressed first.
If especially a certain simulation package needs a detailed view of the geometry of the lens system and its excitations during the course of the experiment, it is difficult to fully abstract the technical details of the hardware into a set of names for fields and groups that make for a compromise between clarity but being system-agnostic at the same time. Settings of apertures are an example where aperture modes are in most cases aliases behind which there is a set of very detailed settings specific to the software and control units used. These settings are difficult to retrieve, are not fully documented by technology partners. This simplification for users of microscopes makes experiments easier understandable. On the flipside these subtilities limit the opportunities of especially open- source developments to make data schemas covering enough for general usage and specific enough and sufficiently detailed to remain useful for research by electron microscopy domain experts.
Instead, currently it is for the docstring to specify what is conceptually eventually behind such aliases. The design rule we followed while drafting this NXem application definition and base classes is that there are numerous (technical) details about an EM which may warrant a very detailed technical disentangling of settings and reflection of numerous settings as deeply nested groups, fields and attributes. An application definition can offer a place to hold these nested representations; however as discussed at the cost of generality.
Which specific details matter for answering scientific research questions is a difficult question to answer by a single team of scientists, especially if the application definition is to speak for a number of vendors. What makes it especially challenging is when the application definition is expected to hold all data that might be of relevance for future questions.
We are skeptical if there is one such representation that can fulfill all these aims and interest, while remaining at the same time approachable and executable by a large number of scientists in a community. However, we are also convinced that this is not a reason to accept the status quo of having a very large set of oftentimes strongly overlapping and redundant schemas.
NXem is our proposal to motivate the EM community to work towards more standardization and discussion of what constitutes data, i.e. metadata, numerical and categorical data in research with electron microscopes. We found that existent terminology can be encoded into a more controlled vocabulary.
We have concluded that despite all these details of current EM research with SEM, TEM, and focused-ion beam instruments, there a clearly identifiable common components and generalizable settings of EM research use cases. Therefore,
This application definition has the following components at the top-level:
Each signal, such as a spectrum or image taken at the microscope, should have an associated time-zone-aware time stamp and report of the specific settings of the microscope at that point in time when the image was taken. This is why instances of NXevent_data_em have their own em_lab section. The reason is that EMs can be highly dynamic, used to illuminate the specimen differently or show drift during signal acquisition, to name but a few effects. What constitutes a single EM experiment/measurement? This can be the collecting of a single diffraction pattern with a scanning TEM (STEM), taking of a secondary electron image for fracture analysis, taking a set of EBSD line scans and/or surface mappings in an SEM, or the ion-beam-milling of a specimen in preparation for e.g. an atom probe experiment.
NXmonitor; instances to keep track of time-dependent quantities pertaining to specific components of the instrument. Alternatively, NXevent_data_em instances can be used to store time-zone-aware dates of the components, which is relevant for documenting as exactly as practically possible settings when images and spectra were taken.
NXinstrument; conceptually this is a container to store an arbitrary level of detail of the technical components of the microscope as a device and the lab in which the microscope is operated.
NXuser; conceptually, this is a set with at least one NXuser instance which details who operated or performed the measurement. Additional NXusers can be referred to in an NXevent_data_em instance to store individualized details of who executed an event of data acquisition or processing.
NXevent_data_em instances as an NXevent_data_em_set; each NXevent_data_em instance is a container to group specific details about the state of the microscope when a measurement was taken and relevant data and eventual processing steps were taken (on-the-fly).
NXdata; at the top-level, this is a place for documenting available default plottable data. A default plottable can be useful for research data management systems to show a visual representation of some aspect of the content of the EM session. Default plottables are not intended to serve every possible analysis and visualization demand but are instead a preview. We made this choice because what constitutes a useful default plot is often a matter of interpretation, somewhat of personal taste, and community standards. In effect, default plottables are case- and method-specific.
Usually a session at a microscope is used to collect multiple signals. Examples for possible default plottables could be arbitrarily taken secondary, back-scattered, electron image, diffraction pattern, EELS spectra, composition, or orientation mappings to name but a few.
There are a few design choices to consider with sub-ordinate groups:
Images and spectra should be stored as NXimage_set and NXspectrum_set instances to hold data at the earliest possible step in the computational processing (which is usually performed with the microscope control and or integrated analysis software). The formatting of the NXdata groups enables the display of image and spectra with web technology visualization software.
When two- and three-dimensional geometric primitive data are stored, it is useful to write additional optional XDMF fields which support additional plotting of the data with visualization software.
Consumable results of EM characterization tasks are usually a sub-set of data artifacts, as there is not an infinite amount of possible electron/ion beam-specimen interactions.
Images based on electron counts are typically detected with specific operation modes such as bright field or dark field imaging in TEM or secondary/back-scattered electron imaging in SEM.
Also spectra (X-ray quanta or Auger electron counts) typically are referred to under the assumption of a specific operation mode of the microscope.
These data are in virtually all cases a result of some numerical processing. These data and processing steps are modelled as instances of NXprocess which use terms from a controlled vocabulary e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, X-ray, Auger, Cathodolum(inescence).
A key question often asked with EM experiments is how the actual (meta)data should be stored (in memory or on disk).
The application definition NXem is a graph which describes how numerical data and (meta)data for EM research are related to one another.
Electron microscopy experiments are usually controlled/performed via commercial integrated acquisition and instrument control software. In many cases, an EM dataset is useful only if it gets post-processed already during the acquisition, i.e. while the scientist is sitting at the microscope. Many of these processes are automated, while some demand GUI interactions with the control software. Examples include collecting of diffraction pattern and on-the-fly indexing of these.
It is possible that different types of programs might be used to perform these processing steps whether on-the-fly or not. If this is the case the processing should be structured with individual NXprocess instances. If the program and/or version used for processing referred to in an NXprocess group is different to the program and version mentioned in this field, the NXprocess needs to hold an own program and version.
Symbols:
No symbol table
- Groups cited:
NXaberration_model_ceos, NXaberration_model_nion, NXaberration, NXaperture_em, NXchamber, NXcoordinate_system_set, NXcorrector_cs, NXdata, NXdetector, NXebeam_column, NXentry, NXevent_data_em_set, NXevent_data_em, NXfabrication, NXibeam_column, NXimage_set, NXinstrument, NXion, NXlens_em, NXmonitor, NXnote, NXoptical_system_em, NXprocess, NXprogram, NXpump, NXsample, NXscanbox_em, NXsource, NXspectrum_set, NXstage_lab, NXtransformations, NXuser
Structure:
ENTRY: (required) NXentry
@version: (required) NX_CHAR
An at least as strong as SHA256 hashvalue of the file ...
An at least as strong as SHA256 hashvalue of the file that specifies the application definition.
definition: (required) NX_CHAR ⤆
NeXus NXDL schema to which this file conforms. ...
NeXus NXDL schema to which this file conforms.
Obligatory value:
NXem
experiment_identifier: (required) NX_CHAR ⤆
Ideally, a (globally) unique persistent identifier ...
Ideally, a (globally) unique persistent identifier for referring to this experiment.
The identifier is usually defined/issued by the facility, laboratory, or the principle investigator. The identifier enables to link experiments to e.g. proposals.
experiment_description: (optional) NX_CHAR ⤆
Free-text description about the experiment. ...
Free-text description about the experiment.
Users are strongly advised to detail the sample history in the respective field and fill rather as completely as possible the fields of this application definition rather than write details about the experiment into this free-text description field.
start_time: (recommended) NX_DATE_TIME ⤆
ISO 8601 time code with local time zone offset to UTC information included ...
ISO 8601 time code with local time zone offset to UTC information included when the microscope session started. If the application demands that time codes in this section of the application definition should only be used for specifying when the experiment was performed - and the exact duration is not relevant - this start_time field should be used.
Often though it is useful to specify a time interval by specifying both a start_time and an 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 possible 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 to compute this. These computations can take advantage of individual time stamps in NXevent_data_em instances to provide additional pieces of information.
end_time: (recommended) NX_DATE_TIME ⤆
ISO 8601 time code with local time zone offset to UTC included when ...
ISO 8601 time code with local time zone offset to UTC included when the microscope session ended.
PROGRAM: (required) NXprogram
experiment_documentation: (optional) NXnote ⤆
Binary container for a file or a compressed collection of files which ...
Binary container for a file or a compressed collection of files which can be used to add further descriptions and details to the experiment. The container can hold a compressed archive.
thumbnail: (optional) NXnote ⤆
A small image that is representative of the entry; this can be an ...
A small image that is representative of the entry; this can be an image taken from the dataset like a thumbnail of a spectrum. A 640 x 480 pixel jpeg image is recommended. Adding a scale bar to that image is recommended but not required as the main purpose of the thumbnail is to provide e.g. thumbnail images for displaying them in data repositories.
Contact information and eventually details of at least one person ...
Contact information and eventually details of at least one person involved in the taking of the microscope session. This can be the principle investigator who performed this experiment. Adding multiple users if relevant is recommended.
Given (first) name and surname of the user.
affiliation: (recommended) NX_CHAR ⤆
Name of the affiliation of the user at the point in time ...
Name of the affiliation of the user at the point in time when the experiment was performed.
address: (recommended) NX_CHAR ⤆
Postal address of the affiliation.
email: (recommended) NX_CHAR ⤆
Email address of the user at the point in time when the experiment ...
Email address of the user at the point in time when the experiment was performed. Writing the most permanently used email is recommended.
orcid: (recommended) NX_CHAR
Globally unique identifier of the user as offered by services ...
Globally unique identifier of the user as offered by services like ORCID or ResearcherID. If this field is field the specific service should also be written in orcid_platform
orcid_platform: (recommended) NX_CHAR
Name of the OrcID or ResearcherID where the account ...
Name of the OrcID or ResearcherID where the account under orcid is registered.
telephone_number: (optional) NX_CHAR ⤆
(Business) (tele)phone number of the user at the point ...
(Business) (tele)phone number of the user at the point in time when the experiment was performed.
Which role does the user have in the place and at the point ...
Which role does the user have in the place and at the point in time when the experiment was performed? Technician operating the microscope. Student, postdoc, principle investigator, guest are common examples.
social_media_name: (optional) NX_CHAR
Account name that is associated with the user in social media platforms.
social_media_platform: (optional) NX_CHAR
A description of the material characterized in the experiment. ...
A description of the material characterized in the experiment. Sample and specimen are threaded as de facto synonyms.
method: (required) NX_CHAR
A qualifier whether the sample is a real one or a ...
A qualifier whether the sample is a real one or a virtual one (in a computer simulation)
Any of these values:
experiment
|simulation
Ideally (globally) unique persistent identifier. The name distinguishes ...
Ideally (globally) unique persistent identifier. The name distinguishes the specimen from all others and especially the predecessor/origin from where the specimen was cut.
This field must not be used for an alias of the sample. Instead, use short_title for this, more convenient alias name.
In cases where multiple specimens have been loaded into the microscope the name has to identify the specific one, whose results are stored by this NXentry, because a single NXentry should be used only for the characterization of a single specimen.
Details about the specimen preparation should be stored in the sample history.
sample_history: (required) NX_CHAR
Ideally, a reference to a (globally) unique persistent identifier, ...
Ideally, a reference to a (globally) unique persistent identifier, representing a data artifact which documents ideally as many details of the material, its microstructure, and its thermo-chemo-mechanical processing/preparation history as possible.
The sample_history is the record what happened before the specimen was placed into the microscope at the beginning of the session.
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 are the key steps and relevant information about the specimen, its material, microstructure, thermo-chemo-mechanical processing state, and the details of the preparation.
Specific details about eventual physically-connected material like embedding resin should be documented ideally also in the sample_history. If all fails, the description field can be used but it is strongly discouraged because it leads to eventually non-machine-actionable data.
preparation_date: (required) NX_DATE_TIME ⤆
ISO 8601 time code with local time zone offset to UTC information ...
ISO 8601 time code with local time zone offset to UTC information when the specimen was prepared.
Ideally report the end of the preparation, i.e. the last known time the measured specimen surface was actively prepared. Usually this should be a part of the sample history, i.e. the sample is imagined handed over for analysis.
Knowing when the specimen was exposed to e.g. specific atmosphere is especially required for environmentally sensitive material such as hydrogen charged specimens or experiments including tracers with a short half time. Further time stamps prior to preparation_date should better be placed in resources which describe the sample_history.
short_title: (optional) NX_CHAR ⤆
Possibility to give an abbreviation or alias of the specimen name field.
atom_types: (required) NX_CHAR
List of comma-separated elements from the periodic table that are ...
List of comma-separated elements from the periodic table that are contained in the sample. If the sample substance has multiple components, all elements from each component must be included in atom_types.
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.
thickness: (required) NX_FLOAT {units=NX_LENGTH} ⤆
(Measured) sample thickness. The information is recorded to qualify ...
(Measured) sample thickness. The information is recorded to qualify if the beam used was likely able to shine through the specimen. For scanning electron microscopy, in many cases the specimen is much thicker than what is illuminatable by the electron beam. In this case the value should be set to the actual thickness of the specimen viewed for an illumination situation where the nominal surface normal of the specimen is parallel to the optical axis.
density: (optional) NX_FLOAT {units=NX_ANY} ⤆
(Measured) density of the specimen. For multi-layered specimens this ...
(Measured) density of the specimen. For multi-layered specimens this field should only be used to describe the density of the excited volume. For scanning electron microscopy the usage of this field is discouraged and instead an instance of an NXinteraction_vol_em within individual NXevent_data_em instances can provide a much better description of the relevant details why one may wish to store the density of the specimen.
description: (optional) NX_CHAR ⤆
Discouraged free-text field in case properly designed records ...
Discouraged free-text field in case properly designed records for the sample_history are not available.
Hard link to a location in the hierarchy of the NeXus file ...
Hard link to a location in the hierarchy of the NeXus file where the data for default plotting are stored.
COORDINATE_SYSTEM_SET: (recommended) NXcoordinate_system_set
TRANSFORMATIONS: (optional) NXtransformations ⤆
MONITOR: (optional) NXmonitor ⤆
em_lab: (required) NXinstrument ⤆
instrument_name: (required) NX_CHAR
Given name of the microscope at the hosting institution. This is an alias. ...
Given name of the microscope at the hosting institution. This is an alias. Examples could be NionHermes, Titan, JEOL, Gemini, etc.
location: (optional) NX_CHAR
Location of the lab or place where the instrument is installed. ...
Location of the lab or place where the instrument is installed. Using GEOREF is preferred.
FABRICATION: (required) NXfabrication
CHAMBER: (optional) NXchamber
EBEAM_COLUMN: (required) NXebeam_column
FABRICATION: (recommended) NXfabrication ⤆
CHAMBER: (optional) NXchamber
electron_source: (required) NXsource ⤆
APERTURE_EM: (optional) NXaperture_em ⤆
LENS_EM: (optional) NXlens_em ⤆
aberration_correction: (recommended) NXcorrector_cs ⤆
applied: (required) NX_BOOLEAN ⤆
FABRICATION: (recommended) NXfabrication ⤆
ZEMLIN_TABLEAU: (recommended) NXprocess ⤆
description: (optional) NX_CHAR ⤆
tilt_angle: (recommended) NX_FLOAT {units=NX_ANGLE} ⤆
exposure_time: (recommended) NX_FLOAT {units=NX_TIME} ⤆
magnification: (optional) NX_NUMBER {units=NX_DIMENSIONLESS} ⤆
PROCESS: (optional) NXprocess ⤆
ceos: (optional) NXaberration_model_ceos ⤆
c_1: (recommended) NXaberration ⤆
a_1: (recommended) NXaberration ⤆
b_2: (recommended) NXaberration ⤆
a_2: (recommended) NXaberration ⤆
c_3: (recommended) NXaberration ⤆
s_3: (recommended) NXaberration ⤆
a_3: (recommended) NXaberration ⤆
b_4: (optional) NXaberration ⤆
d_4: (optional) NXaberration ⤆
a_4: (optional) NXaberration ⤆
c_5: (optional) NXaberration ⤆
s_5: (optional) NXaberration ⤆
r_5: (optional) NXaberration ⤆
a_6: (optional) NXaberration ⤆
nion: (optional) NXaberration_model_nion ⤆
c_1_0: (recommended) NXaberration ⤆
c_1_2_a: (recommended) NXaberration ⤆
c_1_2_b: (recommended) NXaberration ⤆
c_2_1_a: (recommended) NXaberration ⤆
c_2_1_b: (recommended) NXaberration ⤆
c_2_3_a: (recommended) NXaberration ⤆
c_2_3_b: (recommended) NXaberration ⤆
c_3_0: (recommended) NXaberration ⤆
c_3_2_a: (recommended) NXaberration ⤆
c_3_2_b: (recommended) NXaberration ⤆
c_3_4_a: (recommended) NXaberration ⤆
c_3_4_b: (recommended) NXaberration ⤆
c_4_1_a: (recommended) NXaberration ⤆
c_4_1_b: (recommended) NXaberration ⤆
c_4_3_a: (recommended) NXaberration ⤆
c_4_3_b: (recommended) NXaberration ⤆
c_4_5_a: (recommended) NXaberration ⤆
c_4_5_b: (recommended) NXaberration ⤆
c_5_0: (recommended) NXaberration ⤆
c_5_2_a: (optional) NXaberration ⤆
c_5_2_b: (optional) NXaberration ⤆
c_5_4_a: (optional) NXaberration ⤆
c_5_4_b: (optional) NXaberration ⤆
c_5_6_a: (optional) NXaberration ⤆
c_5_6_b: (optional) NXaberration ⤆
IBEAM_COLUMN: (optional) NXibeam_column
FABRICATION: (recommended) NXfabrication ⤆
CHAMBER: (optional) NXchamber
ion_source: (required) NXsource ⤆
APERTURE_EM: (recommended) NXaperture_em ⤆
LENS_EM: (recommended) NXlens_em ⤆
EBEAM_DEFLECTOR: (optional) NXscanbox_em
IBEAM_DEFLECTOR: (optional) NXscanbox_em
OPTICAL_SYSTEM_EM: (recommended) NXoptical_system_em
DETECTOR: (required) NXdetector ⤆
Description of the type of the detector. ...
Description of the type of the detector.
Electron microscopes have typically multiple detectors. Different technologies are in use like CCD, scintillator, direct electron, CMOS, or image plate to name but a few.
local_name: (required) NX_CHAR ⤆
Instrument-specific alias/name
FABRICATION: (recommended) NXfabrication ⤆
PUMP: (optional) NXpump
stage_lab: (required) NXstage_lab
measurement: (optional) NXevent_data_em_set
A container for storing a set of NXevent_data_em instances. ...
A container for storing a set of NXevent_data_em instances.
An event is a time interval during which the microscope was configured in a specific way. The microscope is considered as stable enough during this interval that a measurement with one or multiple detectors is possible. What constitutes such time interval depends on how the microscope is used and which measurements the user would like to perform.
Each NXevent_data_em instance holds one acquisition task with detectors. Each NXevent_data_em section contains an em_lab group in which specific settings and states of the microscope during the time interval can be stored to document the history of states of the microscope over the course of the session.
The NXem application definition offers maximal flexibility. One extreme could be that the only one NXevent_data_em instance is used and this covers the time interval of the entire session at the microscope. The other extreme case is that each collection of an image or even single spot measurement is defined as an NXevent_data_em instance. In this case the em_lab group inside the NXevent_data_em also holds the specific time-dependent state of the microscope with which in theory all dynamics of the system (if measured) can be captured and documented.
Nowadays microscopes exists for which hard- and software solutions enable a tracking of the dynamics of the microscope and the actions of the user (such as with solution like AXONSynchronicity from Protochips). The NXem application definition can however also be used for less complex interaction and lower demands wrt to time tracking activities.
An NXevent_data_em instance holds specific details about how raw data from a detector were processed. Raw data may already be post-processed as they are accessible only by the control software with after some internal processing happened. Nevertheless, these data have to be distinguished from post-processed data where e.g. raw data are converted to interpreted spectra, or orientation mappings.
This post-processing tasks can be performed (on-the-fly, i.e. during acquisition for sure during the microscope session) or afterwards. Post-processing is performed with commercial software or various types and scripts.
Currently, several specializations of NXimage_set and Nspectrum_set are used which store some details of this processing. However, as post- processing tasks can be substantially more advanced and involved it is clear that data artifacts from the measurement and data artifacts generated during post-processing are weakly connected only, maybe exclusively by the fact that a complex numerical post-processing workflow just takes one raw dataset from an NXevent_data_em instance but generates multiple derived data artifacts from this. All these should be described as own application definitions and only weak connections should be made to an instance of NXem. Instances of NXsubentry is one mechanism in NeXus how this can be achieved in the future.
EVENT_DATA_EM: (required) NXevent_data_em ⤆
A container holding a specific result of the measurement and ...
A container holding a specific result of the measurement and eventually metadata how that result was obtained numerically.
NXevent_data_em instances can hold several specific NXimage_em or NXspectrum_em instances taken and considered as one event, i.e. a point in time when the microscope had the settings specified either in NXinstrument or in this NXevent_data_em instance.
The application definition is designed without an explicit need for having an NXevent_data_em instance that contains an NXimage_em or NXspectra_em instance. Thereby, an NXevent_data_em can also be used for just documentation about the specific state of the microscope irrespective whether data have been collected during this time interval.
In other words the NXinstrument group details primarily the more static settings and components of the microscope as they are found by the operator during the session. The NXevent_data_em samples the dynamics.
It is not necessary to store data in NXebeam, NXibeam instances of NXevent_data_em but in this case it is assumed that the settings were constant over the entire course of the microscope session and thus all relevant metadata inside the NXinstrument groups are sufficient to understand the session.
So far there exists no standard which a majority of the technology partners and the materials science electron microscopy community have accepted which could be used for a very generic documentation, storage and exchange of electron microscope data. Therefore, it is still a frequent case that specific files have many fields which cannot safely be mapped or interpreted. Therefore, users are always given the advice to keep the vendor files. Working however with these vendor files inside specific software, like materials databases, demands for parsers which extract pieces of information from the vendor representation (numerical data and metadata) and map them on a schema with which the database and its associated software tools can work with.
Currently, one would loose immediately track of e.g. provenance and the origin of certain data in NXevent_data_em instances unless really all data are safely and reliably copied over into an instance of the schema. Currently, though, this is sadly effectively prevented in many cases as vendors indeed implemented often sophisticated provenance and commercial software state tracking tools but these are not yet documented covering enough in our opinion so that it is safe to assume all vendor field names are known, logically understood, interpretable, and thus mappable on a common schema using a controlled common vocabulary.
Therefore we encourage user for now to store for each NXimage_set or NXspectra_set instance to supply the so-called source of the data. This can for instance be the name and hashvalue of the original file which was acquired during the microscope session and from which then certain details like numerical data and metadata were copied into an instance of this schema for the purpose of working with the data in e.g. tools offered by research data management (RDM) systems or materials database.
During our work on implementing file format/metadata parsers and developing this application definition, we realized that several software tools currently do not consistently format critical metadata like time-zone-aware timestamps when events of data collection or processing happened.
We would like to encourage the community and especially the vendors to work towards a standardization, or at least an open documentation of the way how time-zone-aware time data are collected and stored how and where during a microscope session and how they end up in files and databases with which users interact. This would enable to supplement instances of this schema with specific time data and assure that these time data can be used to reliably contextualize individual datasets and processing steps in materials information systems.
For the reason that these measures have not yet been fully taken, the start_time and end_time is a recommended option. The idea behind these time-zone-aware dates is to identify when the data were collected at the microscope but NOT when they were transcoded by some software tool(s) while storing the data in an instance of this schema.
start_time: (recommended) NX_DATE_TIME ⤆
end_time: (recommended) NX_DATE_TIME ⤆
event_identifier: (recommended) NX_CHAR ⤆
event_type: (recommended) NX_CHAR ⤆
IMAGE_SET: (optional) NXimage_set ⤆
SPECTRUM_SET: (optional) NXspectrum_set ⤆
PROCESS: (required) NXprocess ⤆
data_counts: (required) NX_NUMBER (Rank: 3, Dimensions: [n_y, n_x, n_energy]) {units=NX_UNITLESS} ⤆
axis_y: (required) NX_NUMBER (Rank: 1, Dimensions: [n_y]) {units=NX_LENGTH} ⤆
axis_x: (required) NX_NUMBER (Rank: 1, Dimensions: [n_x]) {units=NX_LENGTH} ⤆
axis_energy: (required) NX_NUMBER (Rank: 1, Dimensions: [n_energy]) {units=NX_ENERGY} ⤆
summary: (recommended) NXdata ⤆
adf: (optional) NXimage_set ⤆
inner_half_angle: (recommended) NX_FLOAT {units=NX_ANGLE}
Annulus inner half angle
outer_half_angle: (recommended) NX_FLOAT {units=NX_ANGLE}
Annulus outer half angle
PROCESS: (required) NXprocess ⤆
xray: (optional) NXspectrum_set ⤆
PROCESS: (required) NXprocess ⤆
indexing: (optional) NXprocess ⤆
eels: (optional) NXspectrum_set ⤆
kikuchi: (optional) NXimage_set ⤆
em_lab: (optional) NXinstrument ⤆
CHAMBER: (optional) NXchamber
EBEAM_COLUMN: (optional) NXebeam_column
CHAMBER: (optional) NXchamber
electron_source: (optional) NXsource ⤆
APERTURE_EM: (optional) NXaperture_em ⤆
LENS_EM: (optional) NXlens_em ⤆
aberration_correction: (recommended) NXcorrector_cs ⤆
applied: (required) NX_BOOLEAN ⤆
FABRICATION: (recommended) NXfabrication ⤆
ZEMLIN_TABLEAU: (recommended) NXprocess ⤆
description: (optional) NX_CHAR ⤆
tilt_angle: (recommended) NX_FLOAT {units=NX_ANGLE} ⤆
exposure_time: (recommended) NX_FLOAT {units=NX_TIME} ⤆
magnification: (optional) NX_NUMBER {units=NX_DIMENSIONLESS} ⤆
PROCESS: (optional) NXprocess ⤆
ceos: (optional) NXaberration_model_ceos ⤆
c_1: (recommended) NXaberration ⤆
a_1: (recommended) NXaberration ⤆
b_2: (recommended) NXaberration ⤆
a_2: (recommended) NXaberration ⤆
c_3: (recommended) NXaberration ⤆
s_3: (recommended) NXaberration ⤆
a_3: (recommended) NXaberration ⤆
b_4: (optional) NXaberration ⤆
d_4: (optional) NXaberration ⤆
a_4: (optional) NXaberration ⤆
c_5: (optional) NXaberration ⤆
s_5: (optional) NXaberration ⤆
r_5: (optional) NXaberration ⤆
a_6: (optional) NXaberration ⤆
nion: (optional) NXaberration_model_nion ⤆
c_1_0: (recommended) NXaberration ⤆
c_1_2_a: (recommended) NXaberration ⤆
c_1_2_b: (recommended) NXaberration ⤆
c_2_1_a: (recommended) NXaberration ⤆
c_2_1_b: (recommended) NXaberration ⤆
c_2_3_a: (recommended) NXaberration ⤆
c_2_3_b: (recommended) NXaberration ⤆
c_3_0: (recommended) NXaberration ⤆
c_3_2_a: (recommended) NXaberration ⤆
c_3_2_b: (recommended) NXaberration ⤆
c_3_4_a: (recommended) NXaberration ⤆
c_3_4_b: (recommended) NXaberration ⤆
c_4_1_a: (recommended) NXaberration ⤆
c_4_1_b: (recommended) NXaberration ⤆
c_4_3_a: (recommended) NXaberration ⤆
c_4_3_b: (recommended) NXaberration ⤆
c_4_5_a: (recommended) NXaberration ⤆
c_4_5_b: (recommended) NXaberration ⤆
c_5_0: (recommended) NXaberration ⤆
c_5_2_a: (optional) NXaberration ⤆
c_5_2_b: (optional) NXaberration ⤆
c_5_4_a: (optional) NXaberration ⤆
c_5_4_b: (optional) NXaberration ⤆
c_5_6_a: (optional) NXaberration ⤆
c_5_6_b: (optional) NXaberration ⤆
IBEAM_COLUMN: (optional) NXibeam_column
ebeam_deflector: (optional) NXscanbox_em
ibeam_deflector: (optional) NXscanbox_em
OPTICAL_SYSTEM_EM: (optional) NXoptical_system_em
DETECTOR: (optional) NXdetector ⤆
PUMP: (optional) NXpump
STAGE_LAB: (optional) NXstage_lab
Hypertext Anchors¶
List of hypertext anchors for all groups, fields, attributes, and links defined in this class.
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/applied-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/FABRICATION-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/FABRICATION/model-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/name-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/description-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/exposure_time-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/magnification-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_1-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_1/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_2-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_2/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_3-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_3/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_4-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_4/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_6-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/a_6/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/b_2-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/b_2/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/b_4-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/b_4/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/c_1-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/c_3-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/c_5-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/d_4-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/d_4/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/r_5-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/r_5/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/s_3-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/s_3/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/s_5-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/ceos/s_5/angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_1_0-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_1_2_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_1_2_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_2_1_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_2_1_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_2_3_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_2_3_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_3_0-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_3_2_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_3_2_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_3_4_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_3_4_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_1_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_1_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_3_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_3_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_5_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_4_5_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_0-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_2_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_2_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_4_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_4_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_6_a-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/PROCESS/nion/c_5_6_b-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU/tilt_angle-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/APERTURE_EM/description-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/APERTURE_EM/FABRICATION-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/APERTURE_EM/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/APERTURE_EM/FABRICATION/model-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/APERTURE_EM/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/emitter_type-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/FABRICATION-group
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/FABRICATION/model-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/electron_source/voltage-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/LENS_EM/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/LENS_EM/FABRICATION/model-field
/NXem/ENTRY/em_lab/EBEAM_COLUMN/LENS_EM/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/EBEAM_DEFLECTOR/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/APERTURE_EM/FABRICATION-group
/NXem/ENTRY/em_lab/IBEAM_COLUMN/APERTURE_EM/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/APERTURE_EM/FABRICATION/model-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/APERTURE_EM/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/emitter_type-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/FABRICATION-group
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/FABRICATION/model-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/FABRICATION/vendor-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/probe/charge_state-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/ion_source/probe/isotope_vector-field
/NXem/ENTRY/em_lab/IBEAM_COLUMN/LENS_EM/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/IBEAM_DEFLECTOR/FABRICATION/identifier-field
/NXem/ENTRY/em_lab/OPTICAL_SYSTEM_EM/beam_current_description-field
/NXem/ENTRY/em_lab/OPTICAL_SYSTEM_EM/semi_convergence_angle-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/inner_half_angle-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/outer_half_angle-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_image_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_image_identifier@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/adf/stack@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_energy_loss-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_energy_loss@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/stack@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary/axis_energy_loss-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary/axis_energy_loss@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/eels/summary@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/aberration_correction-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/aberration_correction/applied-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/aberration_correction/FABRICATION-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/aberration_correction/name-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/aberration_correction/ZEMLIN_TABLEAU-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/APERTURE_EM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/APERTURE_EM/value-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/CHAMBER-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/electron_source-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/electron_source/voltage-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/LENS_EM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/LENS_EM/current-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/LENS_EM/value-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/EBEAM_COLUMN/LENS_EM/voltage-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/ebeam_deflector-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/ebeam_deflector/pixel_time-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/APERTURE_EM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/APERTURE_EM/value-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/CHAMBER-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/current-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/probe-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/probe/charge_state-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/probe/isotope_vector-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/probe/name-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/ion_source/voltage-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/LENS_EM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/LENS_EM/current-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/LENS_EM/value-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/IBEAM_COLUMN/LENS_EM/voltage-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/ibeam_deflector-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/beam_current-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/beam_current_description-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/camera_length-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/defocus-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/magnification-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/semi_convergence_angle-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/OPTICAL_SYSTEM_EM/working_distance-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/STAGE_LAB-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/STAGE_LAB/position-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/STAGE_LAB/rotation-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/STAGE_LAB/tilt_1-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/em_lab/STAGE_LAB/tilt_2-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/event_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_image_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_image_identifier@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/IMAGE_SET/stack@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/pattern_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/pattern_identifier@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/scan_point_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/kikuchi/stack@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_energy-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_energy@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/axis_energy-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/axis_energy@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/SPECTRUM_SET/summary/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/indexing/ELEMENTNAME/summary@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/detector_identifier-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/mode-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/PROGRAM-group
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/PROGRAM/program-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/PROGRAM/program@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/source-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/PROCESS/source@version-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_photon_energy-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_photon_energy@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_x-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_x@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_y-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/axis_y@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/stack@signal-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary/axis_photon_energy-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary/axis_photon_energy@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary/data_counts-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary/data_counts@long_name-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary/title-field
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary@axes-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary@AXISNAME_indices-attribute
/NXem/ENTRY/measurement/EVENT_DATA_EM/xray/summary@signal-attribute