diff --git a/contributed_definitions/NXaberration.nxdl.xml b/contributed_definitions/NXaberration.nxdl.xml new file mode 100644 index 0000000000..0b3a8a5632 --- /dev/null +++ b/contributed_definitions/NXaberration.nxdl.xml @@ -0,0 +1,79 @@ + + + + + Models for aberrations of electro-magnetic lenses in electron microscopy. + + The notation follows `O. Krivanek et al. (1999) <https://doi.org/10.1016/S0304-3991(99)00013-3>`_ + and `O. Krivanek et al. (2003) <https://doi.org/10.1016/S0304-3991(03)00090-1>`_ + See also `S. J. Pennycock and P. D. Nellist <https://doi.org/10.1007/978-1-4419-7200-2>`_ (page 44ff, and page 118ff) + for further details, additional literature, and the unit of the coefficients. + Consult Table 7-2 of Ibid. publication on how to convert between + conventions of different groups/vendors. + + + + Defocus + + + + + Two-fold astigmatism + + + + + Two-fold astigmatism + + + + + Second-order axial coma + + + + + Second-order axial coma + + + + + Threefold astigmatism + + + + + Threefold astigmatism + + + + + Spherical aberration + + + + + Star aberration + + + + + Star aberration + + + + + Fourfold astigmatism + + + + + Fourfold astigmatism + + + + + Fifth-order spherical aberration + + + diff --git a/contributed_definitions/NXaperture_em.nxdl.xml b/contributed_definitions/NXaperture_em.nxdl.xml new file mode 100644 index 0000000000..5fbae08d4d --- /dev/null +++ b/contributed_definitions/NXaperture_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Details of an individual aperture for electron beams. + + + + Given name/alias of the aperture. + + + + + + Relevant value from the control software. + + This is not always just the diameter of (not even in the case) + of a circular aperture. Usually it is a mode setting value which + is selected in the control software. + Which settings are behind the value should be defined + for now in the description field, if these are known + in more detail. + + + + + Ideally, a (globally) unique persistent identifier, link, or text to a + resource which gives further details. Alternatively a free-text field. + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + diff --git a/contributed_definitions/NXchamber.nxdl.xml b/contributed_definitions/NXchamber.nxdl.xml new file mode 100644 index 0000000000..4a6973cc81 --- /dev/null +++ b/contributed_definitions/NXchamber.nxdl.xml @@ -0,0 +1,19 @@ + + + + + Component of an instrument to store or place objects and specimens. + + + + Given name/alias. + + + + + + Free-text field for describing details about the chamber. + For example out of which material was the chamber built. + + + diff --git a/contributed_definitions/NXcoordinate_system_set.nxdl.xml b/contributed_definitions/NXcoordinate_system_set.nxdl.xml new file mode 100644 index 0000000000..3e1d15e101 --- /dev/null +++ b/contributed_definitions/NXcoordinate_system_set.nxdl.xml @@ -0,0 +1,62 @@ + + + + + Container to hold different coordinate systems conventions. + + It is the purpose of this base class to define these conventions and + offer a place to store mappings between different coordinate systems + which are relevant for the interpretation of the data described + by the application definition and base class instances. + + For each Cartesian coordinate system users should use a set of + NXtransformations: + + * These should define the three base vectors. + * The location of the origin. + * The affine transformations which bring each axis of this coordinate system + into registration with the McStas coordinate system. + * Equally, affine transformations should be given for the inverse mapping. + + As an example one may take an experiment or computer simulation where + there is a laboratory (lab) coordinate system, a sample/specimen coordinate + system, a crystal coordinate system, and additional coordinate systems, + which are eventually attached to components of the instrument. + + If no additional transformation is specified in this group or if an + instance of an NXcoordinate_system_set is absent it should be assumed + the so-called McStas coordinate system is used. + + Many application definitions in NeXus refer to this `McStas <https://mailman2.mcstas.org/pipermail/mcstas-users/2021q2/001431.html>`_ coordinate system. + This is a Cartesian coordinate system whose z axis points along the neutron + propagation axis. The systems y axis is vertical up, while the x axis points + left when looking along the z-axis. Thus, McStas is a right-handed coordinate system. + + Within each NXtransformations a depends_on section is required. The depends_on + field specifies if the coordinate system is the root/reference + (which is indicated by writing "." in the depends_on section.) + + + + A group of transformations which specify: + + * Three base vectors of the coordinate system. + * Origin of the coordinate system. + * A depends_on keyword. Its value can be "." or the name of an + NXtransformations instance which needs to exist in the + NXcoordinate_system_set instance. + * If the coordinate system is the reference one it has to be named + reference. + + In case of having more than one NXtransformations there has to be for + each additional coordinate system, i.e. the one not the reference: + + * A set of translations and rotations which map each base vector to the reference. + * A set of translations and rotations which map each reference base vector + to the coordinate system. + + The NXtransformations for these mappings need to be formatted + according to the descriptions in NXtransformations. + + + diff --git a/contributed_definitions/NXcorrector_cs.nxdl.xml b/contributed_definitions/NXcorrector_cs.nxdl.xml new file mode 100644 index 0000000000..47e10cf9f7 --- /dev/null +++ b/contributed_definitions/NXcorrector_cs.nxdl.xml @@ -0,0 +1,40 @@ + + + + + Corrector for aberrations in an electron microscope. + + Different vendors use a different naming schemes for aberration coefficients. + It is the users responsibility to map to the best matching values. + + In transmission electron microscopes the spherical aberration corrector is + a component that is controlled via instructing the microscope to achieve + set point values. The corrector is composed of multiple lenses and other + parts with vendor-specific details which are often undisclosed. + + In the case of Nion Co. microscopes the coefficients of the corrector can be + retrieved via NionSwift, which is why currently the Nion convention for the + aberration coefficients is used. + + + + Was the corrector used? + + + + + Given name/alias. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. If this does not exist + a free-text field to report further details about the corrector. + + + + + + diff --git a/contributed_definitions/NXebeam_column.nxdl.xml b/contributed_definitions/NXebeam_column.nxdl.xml new file mode 100644 index 0000000000..c31a227224 --- /dev/null +++ b/contributed_definitions/NXebeam_column.nxdl.xml @@ -0,0 +1,82 @@ + + + + + Container for components to form a controlled electron beam. + + + + + The source which creates the electron beam. + + + + Given name/alias. + + + + + + Voltage relevant to compute the energy of the electrons + immediately after they left the gun. + + + + + Type of radiation. + + + + + + + + Emitter type used to create the beam. + + If the emitter type is other, give further details + in the description field. + + + + + + + + + + + Material of which the emitter is build, e.g. the filament material. + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Affine transformation which detail the arrangement in the + microscope relative to the optical axis and beam path. + + + + + + + + + + A sensor used to monitor an external or internal condition. + + + + + Individual ocharacterization results for the position, shape, + and characteristics of the electron beam. + + NXtransformations should be used to specify the location + of the position at which the beam was probed. + + + diff --git a/contributed_definitions/NXem.nxdl.xml b/contributed_definitions/NXem.nxdl.xml new file mode 100644 index 0000000000..d7567ab3c9 --- /dev/null +++ b/contributed_definitions/NXem.nxdl.xml @@ -0,0 +1,713 @@ + + + + + Characterization and session with one sample in an electron microscope. + + **The idea and aim of NXem**: + Electron microscopes (EM), whether it be a scanning electron microscope (SEM) + or a transmission electron microscope (TEM), are versatile tools for preparing + and characterizing samples and specimens. The term specimen is here understood + as a synonym for a sample. A specimen is a physical portion of material that + is studied/characterize in the microscope session, eventually in different + places on the specimen surface. + These places are named regions of interest (ROIs). + + Fundamentally, an EM is an electron accelerator. Experimentalists use an EM + 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. + + Multiple specimens have to be described with multiple NXentry instances. + + 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 + (staff) scientists. These users perform analyses for other users as a service + task. Oftentimes, though, and especially for cutting-edge instruments, + the scientists and their team guide the process while operating the + microscope. Oftentimes the scientists operate the instrument themselves + either on-site or remotely and 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 separate SEM or TEM + schemata are primarily the key similarities of SEM and TEM instruments: + Both have electro-magnetic lenses. These lens may differ in design, alignment, + number, and level of corrected-for aberrations. As an obvious difference, + a TEM is used mainly to measure the transmitted electron beam. + This demands thinner specimens as in SEM but offers capabilities for probing + of additional physical mechanisms of electron-matter interaction. + + Compared to SEMs, TEMs have a different relative arrangement between the + lenses and the specimen which is most obvious by the different relative + arrangement of the objective lens versus the specimen. + + Nevertheless, both types of electron microscopes use detector systems which + measure different types of signals that originate though from the same set of + radiation/specimen interactions. Consequently, detectors can also be similar. + + 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 + the addressed user base is which develops or uses schemata for + research data management with EM, the more understandable it is + that scientists of either community (or sub-community) ask for + method-specific schemata. + + 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 + schemata such as NXem_ebsd, NXem_eels, NXem_edx, or NXem_imaging. + + The development in the past has shown that these activities led to a zoo of + schemata and implementations of these into many data and file formats. + There is nothing which prevents the communities to make these schemata + open and interoperable. Open here means specifically not that all data are + compliant with/or use the schema and have to end up in the open-source domain. + There can be embargo periods first of all. Open means that the metadata and + associated schemata are documented in a manner that as many details as + possible are open in the sense that others can understand what the + (meta)data mean conceptually. + The `FAIR principles <https://doi.org/10.1038/sdata.2016.18>`_ 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 + schemata with associated representations of data and metadata in EM: + Each combination of schemata 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 to maintain. 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. <https://gitlab.hzdr.de/em_glossary/em_glossary>`_ + + A common vocabulary can serve interoperability as developers of schemata + and scientists can take for instance then these terms as closely as possible. + Ideally, they specialize the 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 schemata. + + Aiming for more standardization, i.e. a lower number of schemata rather than + a single standard for electron microscopy is a compromise that can serve + academia as it enables the EM community to focus their software development + efforts on those schemata, on fixing and discussing them, and on harmonize + their common vocabulary. These activities can be specifically relevant also + for vendors of EM hard- and software as it improves the longevity of certain + schema and thus can help to incentivize vendors to support the community with + implementing support for such schemata into their proprietary 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 using NeXus to define schemata for + electron microscopy research. Working towards a common vocabulary is a + community activity that profits from everybody reflecting in detail whether + certain terms they have used 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. + + It is noteworthy to understand that (not only for) NeXus, schema differ + already if at least one field is required in one version of the schema, + but it is set optional in another version. If group(s), field(s), or + attributes are removed or added, or even a docstring is changed, schemata can + become inconsistent. An application definition here serves as a contract + between a data provider and a data consumer. These two can be software tools + (like the vendor software to drive the instrument or a scientific software + for doing artificial intelligence with EM data). + Such changes of a schema lead to new versions. + + Tools like NeXus do not avoid or protect against inconsistencies; however + NeXus offers a mechanism and toolset, through which schemata 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. + A common vocabulary and a machine-actionable knowledge representation/engine + is also required. Essentially when the docstrings are no longer needed + but can be replaced by a connection to an automated tool which understands + what a specific field represents conceptually, EM data have become more + generally interoperable EM data. + + This application definition takes a key step into this direction. + It offers a controlled vocabulary and relation between concepts and data + relevant for research with electron microscopes. To be most efficient and + offering reusability, the application definition should be understood as a + template that one should ideally use as is. This application definition + is called NXem. It can be considered a base for more specialized definitions + (ideally prefixed with NXem) *method*. + + **The use of NXem should be as follows:** + Offspring application definitions should not remove groups but make + them optional or, even better, propose changes in the application definition. + + 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. + 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. + + EM experiments by design 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 and being vendor-agnostic. Settings of apertures are an + example where aperture modes are aliases behind which there is a set of + settings. These settings are difficult to retrieve, often undocumented in + detail. This serves users and makes EM experiments easier understandable and + conveniently executable for a broader user base. The opportunities for + application definitions to offer an abstraction layer are limited. + + Instead, currently it is for the docstring to specify what is conceptually + eventually behind such aliases. The design rule we followed while drafting + the 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 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 if the application definition is expected to hold + all data that might be of relevance for future questions. + + We are skeptical if there is one representation that can fulfill all these + aims, while remaining at the same time approachable and executable by a large + number of scientists in a community. With this application definition we + would like to motivate the community to work towards such aim. While doing + so 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. + + **This application definition has the following components at the top-level:** + + * Generic experimental details (timestamp, identifiers, name); + conceptually these are session details. A session at a microscope may + involve the characterization of multiple specimens. For each specimen + an instance of an (NXentry) is created. Details of the instrument have to + be stored at least in an entry. Other entries should refer to these + metadata via links to reduce redundancies. + * Each signal, such as a spectrum or image taken at the microscope, should + have an associated time stamp and report of the specific settings at that + point in time when the image was taken. The reason is that EMs can be + highly dynamic, be 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 scan and surface mappings in an SEM, or ion-beam-milling of a + specimen in preparation for 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 timestamp states of the + components, which is relevant to document the exact settings when images + and spectra were taken. + * NXinstrument; + conceptually this is a container to store arbitrary level of detail of the + technical components of the microscope as a device and the lab in which + it 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 who executed an event. + * 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; a the top-level, conceptually, 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. + It is clear that what constitutes a useful default plot is 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 and + images. Examples for possible default plottables could be an 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:** + + * Above images, spectra, and mappings should be stored as NXdata instances, + ideally formatted in such a way that they can be displayed with + visualization software that can be specific for the file format in which + the data are stored. NeXus specifies only the data model, i.e. the terms + and their relations. These descriptions can be implemented and stored in + JSON, HDF5, XML, or HSDS, file storage, or even other formats, although + HDF5 is the most commonly used. + * 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 of electron counts detected in specific operation modes (bright + field, dark field in TEM, secondary/back-scattered, Kikuchi in SEM) + * Spectra (X-ray quanta or auger electron counts) + * These data are in virtually all cases a result of some numerical + processing. It makes sense to name them with a controlled vocabulary, + e.g. SE (secondary electron), BSE (back-scattered electron), Kikuchi, + X-ray, Auger, Cathodolum(inescence) etc. + + A key question often asked with EM experiments is how the actual (meta)data + should be stored (in memory or on disk). To this end the schema, here makes no + specific assumptions, not even that all the fields/group of a schema instance + have to be stored into a single file. Instead, the schema specifies the + relations between metadata, constraints on how they should be formatted, what + they conceptually represent and which terms (controlled vocabulary) is + practical to store with the data. + + In effect, the application definition is a graph which describes how + (meta)data are related to one another. + + + + + An at least as strong as SHA256 hashvalue of the file + that specifies the application definition. + + + + + NeXus NXDL schema to which this file conforms. + + + + + + + + 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. + + + + + 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. + + + + + 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 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 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_em instances to + provide additional pieces of information. + + + + + ISO 8601 time code with local time zone offset to UTC included when + the microscope session ended. + + + + + Commercial or otherwise given name to the program which was used to + create the file. + + 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. + + + + Program version plus build number, commit hash, or description of + an ever persistent resource where the source code of the program + and build instructions can be found so that the program can be + configured in such a manner that the result file is ideally + recreatable yielding the same results. + + + + + + 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. + + + + + 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 + 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. + + + + + Name of the affiliation of the user at the point in time when the experiment was + performed. + + + + + Postal address of the affiliation. + + + + + Email address of the user at the point in time when the experiment was + performed. Writing the most permanently used email is recommended. + + + + + Globally unique identifier of the user as offered by services like ORCID or + ResearcherID. + + + + + (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 + in time when the experiment was performed? Technician operating + the microscope. Student, postdoc, principle investigator, guest + are common examples. + + + + + Account name that is associated with the user in social media platforms. + + + + + Name of the social media platform where the account under social_media_name is + registered. + + + + + + + A qualifier whether the sample is a real one or a virtual one (in a computer + simulation) + + + + + + + + A description of the material characterized in the experiment. + Sample and specimen are threaded as de facto synonyms. + + + + Descriptive name or 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. + + 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. + + + + + 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. + + + + + 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 the analysis. At the point it enters the microscope the session starts. + + 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. + + + + + Possibility to give an abbreviation or alias of the specimen name field. + + + + + Use Hill's system for listing elements of the periodic table which are inside or attached + to the surface of the specimen and thus relevant from a scientific point of view. + + 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. + + + + + (Measured) sample thickness. The information is recorded to qualify + if the beam used was likely able to shine through the specimen. + + + + + 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 + where the data for default plotting are stored. + + + + + + + Metadata and numerical data of the microscope and the lab in which it stands. + + The em_lab section contains a description of the instrument and its components. + The component descriptions in this section differ from those inside individual + NXevent_em sections. These event instances take the role of time snapshot. + For an NXevent_em instance users should store only those settings for a + component which are relevant to understand the current state of the component. + Here, current means at the point in time, i.e. the time interval, + which the event represents. + + For example it is not relevant to store in each event's electron_gun group + again the details of the gun type and manufacturer but only the high-voltage + if for that event the high-voltage was different. If for all events + the high-voltage was the same it is not even necessary to include an electron_gun + section in the event. + + Individual sections of specific type should have the following names: + + * NXaperture: the name should match with the name of the lens + * NXlens_em: condenser_lens, objective_lens are commonly used names + * NXcorrector_cs: device for correcting spherical aberrations + * NXstage_lab: a collection of component for holding the specimen and + eventual additional component for applying external stimuli on the sample + * NXdetector: several possible names like secondary_electron, + backscattered_electron, direct_electron, ebsd, edx, wds, auger, + cathodoluminescence, camera, ronchigram + + + + Given name of the microscope at the hosting institution. This is an alias. + Examples could be NionHermes, Titan, JEOL, Gemini, etc. + + + + + Location of the lab or place where the instrument is installed. + Using GEOREF is preferred. + + + + + + + + + + + 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. + + + + + Free text option to write further details about the detector. + + + + + + + + A container to structure a set of NXevent_em instances. + + An event is a time point/interval during which the microscope + was configured in a specific way and the microscope was used + to take a measurement. + + Each NXevent_em holds an acquisition task with the microscope. + For instance the capturing of a secondary electron, backscattered + electron, diffraction image, or spectrum. + + An NXevent_em_data instance holds specific details about how raw data + from a detector were processed into consumable data like images, spectra, + etc. These on-the-fly data processing tasks are usually performed + by the control software, eventually realized with custom scripts. + + Furthermore, NXevent_em_state instances can document specific values + and settings of the microscope during the snapshot/event. + + + + A container holding a specific result of the measurement and + eventually metadata how that result was obtained numerically. + + NXevent_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 + an NXevent_data_em instance that contains an NXimage_em or + NXspectra_em instance. An NXevent_data_em can be used to document a + specific state of the microscope at a time without having it placed + into the NXinstrument group. + + 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 microscope session + and thus all relevant metadata inside the NXinstrument groups + are sufficient to understand the session. + + + + + + Reference to a specific state and setting of the microscope components. + + + + + + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match one of the names of available + NXdetector instances e.g. if the instrument has an ebsd_camera + the detector for an NXimage_em_kikuchi should be the NXdetector + instance called ebsd_camera. + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXevent_data_em.nxdl.xml b/contributed_definitions/NXevent_data_em.nxdl.xml new file mode 100644 index 0000000000..f650af3648 --- /dev/null +++ b/contributed_definitions/NXevent_data_em.nxdl.xml @@ -0,0 +1,165 @@ + + + + + Metadata and settings of an electron microscope for scans and images. + + The need for such a structuring of data is evident from the fact that + electron microscopes are dynamic. Oftentimes it suffices to calibrate the + instrument at the start of the session. Subsequently, data + (images, spectra, etc.) can be collected. Users may wish to take only + a single scan or image and complete their microscope session; however + + frequently users spend much longer at the microscope, recalibrate, + and take multiple data items (scans, images, spectra) each coming + with own detector and on-the-fly processing settings and calibration. + + For the single data item use case one may argue that the need for additional + grouping is redundant. Instead, the metadata could equally be stored inside + the respective groups of the top-level mandatory NXinstrument group. + On the flip side, even for a session with a single image it would also not + harm to nest the data. + + In fact, oftentimes scientists feel that there is a need to store details + about eventual drift of the specimen in its holder (if such data is available) + or record changes to the lens excitations caused or apertures used. + Although current microscopes are usually equipped with stabilization + systems for many of the individual components, it can still be useful + to store time-dependent data in detail. + + Another reason if not a need for more finely granularizable options for + storing time-dependent data, is that over the course of a session one may + reconfigure the microscope. What is a reconfiguration? This could be the + change of an aperture mode because a scientist may first collect an image + with some aperture and then choose a different one. As the aperture affects + the electron beam it will affect the system. + + Let aside for a moment the technology and business models, an EM could be + monitored (and will likely become so more in the future) for streaming out + spatio-temporal details about its components, locations of objects + and eventually applied stimuli and positioning of the specimen. + + Some snapshot or integrated data from this stream are relevant for + understanding signal genesis and electron/ion beam paths. In such a generic + case it might be necessary to sync these streaming data with those intervals + in time when specific measurements are taken (spectra collected, + images taken, diffraction images indexed on-the-fly). + + Theoretically, an instrument and specimen should be considered as dynamic. + Scientists often report or feel (difficult to quantify) observations that + microscopes *perform differently* across sessions, without sometimes being + able to identify clear root causes. Users of the instrument may consider + such conditions impractical and thus either abort their session or try to + bring the microscope first into a state where conditions are considered + stable and of high enough quality for collecting data. + + In all these cases it is practical to store time-dependent data of the + instrument state not in the respective instrument component groups + of the top-level NXinstrument but in a sort of a log of event data. + This is the idea behind the NXevent_data_em snapshot containers. + + The base class requires a start time and an optional end time. + The end time should be added to represent a time interval + (remind the idea of the instrument state stream) during which the + scientist considered the microscope (especially ebeam and specimen) + as stable enough. + + For specific simulation purposes, mainly in an effort to digitally repeat + or simulate the experiment, it is tempting to consider dynamics of the + instrument, implemented as time-dependent functional descriptions of + e.g. lens excitations, beam shape functions, trajectories of groups of + electrons, or detector noise models. + + For now the preferred strategy to handle these cases is through + customizations of the specific fields within NXevent_data_em instances. + + Another alternative could be to sample finer, eventually dissimilarly along + the time axis; however this may cause situations where an NXevent_data_em + instance does not contain specific measurements + (i.e. images, spectra of scientific relevance). + + In this case one should better go for a customized application definition + with a functional property description inside members (fields or groups) + in NXevent_data_em instances or resort to a specific application definition + which documents metadata for tracking explicitly electrons + (with ray-tracing based descriptors/computational geometry descriptors) + or tracking of wave bundles. + + This perspective on more subtle time-dependent considerations of electron + microscopy can be advantageous also for storing details of time-dependent + additional components that are coupled to and/or synced with instrument. + + Examples include cutting-edge experiments where the electron beam gets + coupled/excited by e.g. lasers. In this case, the laser unit should be + registered under the top-level NXinstrument section. Its spatio-temporal + details could be stored inside respective groups of the NXinstrument. + + + + 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. + + + + + ISO 8601 time code with local time zone offset to UTC included when the snapshot time interval ended. + If the user does not wish to specify a time interval, end_time should have the same value as start_time. + + + + + Reference to a specific state and setting of the microscope components. + + + + + Which specific event/measurement type. Examples are: + + * In-lens/backscattered electron, usually has quadrants + * Secondary_electron, image, topography, fractography, overview images + * Backscattered_electron, image, Z or channeling contrast (ECCI) + * Bright_field, image, TEM + * Dark_field, image, crystal defects + * Annular dark field, image (medium- or high-angle), TEM + * Diffraction, image, TEM, or a comparable technique in the SEM + * Kikuchi, image, SEM EBSD and TEM diffraction + * X-ray spectra (point, line, surface, volume), composition EDS/EDX(S) + * Electron energy loss spectra for points, lines, surfaces, TEM + * Auger, spectrum, (low Z contrast element composition) + * Cathodoluminescence (optical spectra) + * Ronchigram, image, alignment utility specifically in TEM + * Chamber, e.g. TV camera inside the chamber, education purposes. + + + + + The detector or set of detectors that was used to collect this signal. + The name of the detector has to match the names used for available + detectors, i.e. if the instrument has an *ebsd_camera* + named detector, instances of NXimage_em_kikuchi should use + *ebsd_camera* as the detector name. + + + + + + + + + + + + + + + + + + + + + + + diff --git a/contributed_definitions/NXevent_data_em_set.nxdl.xml b/contributed_definitions/NXevent_data_em_set.nxdl.xml new file mode 100644 index 0000000000..030f21c18c --- /dev/null +++ b/contributed_definitions/NXevent_data_em_set.nxdl.xml @@ -0,0 +1,11 @@ + + + + + Container to hold NXevent_data_em instances of an electron microscope session. + + An event is a time interval during which the microscope was configured, + considered stable, and used for characterization. + + + diff --git a/contributed_definitions/NXibeam_column.nxdl.xml b/contributed_definitions/NXibeam_column.nxdl.xml new file mode 100644 index 0000000000..43c53282ed --- /dev/null +++ b/contributed_definitions/NXibeam_column.nxdl.xml @@ -0,0 +1,99 @@ + + + + + Container for components of a focused-ion-beam (FIB) system. + + FIB capabilities turn especially scanning electron microscopes + into specimen preparation labs. FIB is a material preparation + technique whereby portions of the sample are illuminated with a + focused ion beam with controlled intensity intense enough and with + sufficient ion momentum to remove material in a controllable manner. + + The fact that an electron microscope with FIB capabilities has needs a + second gun with own relevant control circuits, focusing lenses, and + other components, warrants an own base class to group these components + and distinguish them from the lenses and components for creating and + shaping the electron beam. + + For more details about the relevant physics and application examples + consult the literature, for example: + + * `L. A. Giannuzzi et al. <https://doi.org/10.1007/b101190>`_ + * `E. I. Preiß et al. <https://link.springer.com/content/pdf/10.1557/s43578-020-00045-w.pdf>`_ + * `J. F. Ziegler et al. <https://www.sciencedirect.com/science/article/pii/S0168583X10001862>`_ + * `J. Lili <https://www.osti.gov/servlets/purl/924801>`_ + + + + + The source which creates the ion beam. + + + + Given name/alias for the ion gun. + + + + + Emitter type used to create the ion beam. + + If the emitter type is other, give further + details in the description field. + + + + + + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Which ionized elements or molecular ions form the beam. + Examples are gallium, helium, neon, argon, krypton, + or xenon, O2+. + + + + + Average/nominal brightness + + + + + Charge current + + + + + Ion acceleration voltage upon source exit and entering the vacuum flight path. + + + + + + Affine transformation which detail the arrangement in the microscope relative to + the optical axis and beam path. + + + + + + + + + Individual characterization results for the position, shape, + and characteristics of the ion beam. + + NXtransformations should be used to specify the location or position + at which details about the ion beam are probed. + + + diff --git a/contributed_definitions/NXimage_set_em_adf.nxdl.xml b/contributed_definitions/NXimage_set_em_adf.nxdl.xml new file mode 100644 index 0000000000..a9658fe2a9 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_adf.nxdl.xml @@ -0,0 +1,113 @@ + + + + + + + Number of images + + + + + Number of pixel per image in the slow direction + + + + + Number of pixel per image in the fast direction + + + + + Container for reporting a set of annular dark field images. + + + + Details about how the images were processed from the detector readings. + + + + Commercial or otherwise given name to the program which was used + to process detector data into the adf image(s). + + + + Program version plus build number, commit hash, or description + of an ever persistent resource where the source code of the program + and build instructions can be found so that the program + can be configured in such a manner that the result file + is ideally recreatable yielding the same results. + + + + + + Annulus inner half angle + + + + + Annulus outer half angle + + + + + + Annular dark field images. + + + + Image intensity values. + + + + + + + + + + Image intensities + + + + + Image identifier + + + + + + + Image ID. + + + + + + Pixel center of mass position y-coordinates. + + + + + + + Label for the y axis. + + + + + + Pixel center of mass position x-coordinates. + + + + + + + Label for the x axis. + + + + + diff --git a/contributed_definitions/NXimage_set_em_bf.nxdl.xml b/contributed_definitions/NXimage_set_em_bf.nxdl.xml new file mode 100644 index 0000000000..066b2b3e46 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_bf.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of images taken in bright field mode. + + + + diff --git a/contributed_definitions/NXimage_set_em_bse.nxdl.xml b/contributed_definitions/NXimage_set_em_bse.nxdl.xml new file mode 100644 index 0000000000..6c99db5649 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_bse.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of back-scattered electron images. + + + + diff --git a/contributed_definitions/NXimage_set_em_chamber.nxdl.xml b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml new file mode 100644 index 0000000000..09973347dc --- /dev/null +++ b/contributed_definitions/NXimage_set_em_chamber.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for images recorded with e.g. a TV camera in the microscope chamber. + + + + diff --git a/contributed_definitions/NXimage_set_em_df.nxdl.xml b/contributed_definitions/NXimage_set_em_df.nxdl.xml new file mode 100644 index 0000000000..f9c37cab96 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_df.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of images taken in dark field mode. + + + + diff --git a/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml new file mode 100644 index 0000000000..7065a8a981 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_diffrac.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of diffraction images. + + + + diff --git a/contributed_definitions/NXimage_set_em_ecci.nxdl.xml b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml new file mode 100644 index 0000000000..820ec8869f --- /dev/null +++ b/contributed_definitions/NXimage_set_em_ecci.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting back-scattered electron channeling contrast images. + + + + diff --git a/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml new file mode 100644 index 0000000000..42cfa824a7 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_kikuchi.nxdl.xml @@ -0,0 +1,327 @@ + + + + + + + Number of scan points, one pattern per scan point. + + + + + Number of pixel per Kikuchi pattern in the slow direction + + + + + Number of pixel per Kikuchi pattern in the fast direction + + + + + Electron backscatter diffraction (EBSD) Kikuchi pattern. + + The container can also store data related to a post-processing of these + Kikuchi pattern, which is the backbone of orientation microscopy + especially in materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. <https://doi.org/10.1186/2193-9772-3-4>`_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. <https://doi.org/10.1017/S1431927621006103>`_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. <https://doi.org/10.1186/2193-9772-3-5>`_ + * `A. J. Schwartz et al. <https://doi.org/10.1007/978-1-4757-3205-4>`_ + * `P. A. Rottman et al. <https://doi.org/10.1016/j.mattod.2021.05.003>`_ + + With serial-sectioning this involves however always a sequence of + measuring, milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack respective digital + microstructure representation as (a representative) volume element. + Several software packages are available for this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class. + + + + Collected Kikuchi pattern as an image stack. + + + + + + + + + + Kikuchi pattern intensity + + + + + + + + + + Kikuchi pattern identifier + + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + Which pixel primitive shape is used. + + + + + + + + + The prescribed step size. First value is for the slow changing, + second value is for the fast changing dimension. + + + + + + + + + OIM, orientation imaging microscopy. + Post-processing of the Kikuchi pattern to identify orientations. + + + + + + + + + + + + + + + + + + + Details about the background correction applied to each Kikuchi pattern. + + + + + + How are Kikuchi bands detected + + + + + + + + + + + + + + + + + + How many bands were detected in the pattern. + + + + + + + + + + Lattice planes used as reflectors for indexing pattern + in electron-backscatter diffraction (EBSD). + One collection for each reflector. + + + + Crystallography unit cell parameters a, b, and c + + + + + + + + Crystallography unit cell parameters alpha, beta, and gamma + + + + + + + + + + + + + + + + + + + Crystallographic space group + + + + + Laue group + + + + + Numeral identifier for each phase. The value 0 is reversed for the unknown + phase. + + + + + Name of the phase/alias. + + + + + + Miller indices :math:`(hkl)[uvw]`. + + + + + + + + + + How are pattern being indexed? + + + + + + + + Minimum number of bands required to index the pattern + + + + + + + + Which return value did the indexing algorithm yield for each pattern. + + * Details about bad pixels + * Too high angular deviation + * No solution + * Not analyzed + * Success + * Unexpected errors + + + + + + + + Labels referring to the phase_identifier for each pattern (from reflectors) that + matched best. + + + + + + + + + + + + + + + + + + + + + Free-text description for instrument specific settings + + + + + How is the camera signal binned. + First the number of pixel along the slow direction. + Second the number of pixel along the fast direction. + + + + + + + + + + + + + Average number of patterns taken on average. + + + + + Wall-clock time the acquisition took. + + + + + Fraction of successfully indexed pattern of the set. + + + + diff --git a/contributed_definitions/NXimage_set_em_kikuchi.yaml b/contributed_definitions/NXimage_set_em_kikuchi.yaml new file mode 100644 index 0000000000..b275ed20d6 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_kikuchi.yaml @@ -0,0 +1,292 @@ +category: base +symbols: + n_p: Number of scan points, one pattern per scan point. + n_y: Number of pixel per Kikuchi pattern in the slow direction + n_x: Number of pixel per Kikuchi pattern in the fast direction +doc: | + Electron backscatter diffraction (EBSD) Kikuchi pattern. + + The container can also store data related to a post-processing of these + Kikuchi pattern, which is the backbone of orientation microscopy + especially in materials science and materials engineering. + + Based on a fuse of the `M. A. Jackson et al. `_ + of the DREAM.3D community and the open H5OINA format of Oxford Instruments + `P. Pinard et al. `_ + + EBSD can be used, usually with FIB/SEM microscopes, for three-dimensional + orientation microscopy. So-called serial section analyses. For a detailed + overview of these techniques see e.g. + + * `M. A. Groeber et al. `_ + * `A. J. Schwartz et al. `_ + * `P. A. Rottman et al. `_ + + With serial-sectioning this involves however always a sequence of + measuring, milling. In this regard, each serial section (measuring) and milling + is an own NXevent_data_em instance and thus there such a three-dimensional + characterization should be stored as a set of two-dimensional data, + with as many NXevent_data_em instances as sections were measured. + + These measured serial sectioning images need virtually always post-processing + to arrive at the aligned and cleaned image stack respective digital + microstructure representation as (a representative) volume element. + Several software packages are available for this post-processing. + For now we do not consider metadata of these post-processing steps + as a part of this base class. +# NEW ISSUE: the above-mentioned post-processing could be added though via a (NXprocess) +(NXimage_set_em_kikuchi): + # a collection of pattern-related metadata + (NXdata): + doc: | + Collected Kikuchi pattern as an image stack. + intensity(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 3 + dim: [[1, n_p], [2, n_y], [3, n_x]] + \@long_name: + doc: Kikuchi pattern intensity + # \@signal: intensity + # \@axes: [image_id, ypos, xpos] + # \@image_id_indices: 0 + # \@ypos_indices: 1 + # \@xpos_indices: 2 + image_id(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + \@long_name: + doc: Kikuchi pattern identifier + ypos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_y]] + \@long_name: + doc: Label for the y axis + xpos(NX_NUMBER): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_x]] + \@long_name: + doc: Label for the x axis + # post-processing into EBSD mappings follows, here an example for 2D map + # if the pattern is a regular grid + # NEW ISSUE: use cg classes + # (NXgrid): + # number of pixels + # step size + # what about examples for a 1D map and a 3D map? + # NEW ISSUE: one could do a reanalyzing with having a collection of NXprocesses + grid_type: + doc: Which pixel primitive shape is used. + enumeration: [square, hexagon] + step_size(NX_NUMBER): + doc: | + The prescribed step size. First value is for the slow changing, + second value is for the fast changing dimension. + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 2]] + calibration(NXprocess): ##MK gain etc on the detector + oim(NXprocess): + doc: | + OIM, orientation imaging microscopy. + Post-processing of the Kikuchi pattern to identify orientations. + pattern_quality(NX_FLOAT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + pattern_center(NX_NUMBER): + # NEW ISSUE: replace by (NXcg_point_set): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_p]] + detector_distance(NX_FLOAT): + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, n_p]] + background_correction(NXprocess): + doc: Details about the background correction applied to each Kikuchi pattern. + # NEW ISSUE: + # auto_background_correction: + # static_or_dynamic: + band_detection(NXprocess): + mode: + doc: How are Kikuchi bands detected + enumeration: [center] + band_contrast(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + band_slope(NX_NUMBER): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + bands(NX_NUMBER): + doc: How many bands were detected in the pattern. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + indexing(NXprocess): + # NEW ISSUE: for now as collections, with microstructure proposal NXreflectors + reflector(NXcollection): + doc: | + Lattice planes used as reflectors for indexing pattern + in electron-backscatter diffraction (EBSD). + One collection for each reflector. + unit_cell_abc(NX_FLOAT): + doc: Crystallography unit cell parameters a, b, and c + unit: NX_LENGTH + dimensions: + rank: 1 + dim: [[1, 3]] + unit_cell_alphabetagamma(NX_FLOAT): + doc: Crystallography unit cell parameters alpha, beta, and gamma + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, 3]] + unit_cell_class: + enumeration: [triclinic, monoclinic, orthorhombic, tetragonal, rhombohedral, hexagonal, cubic] + space_group: + doc: Crystallographic space group + laue_group: + doc: Laue group + phase_identifier(NX_UINT): + doc: Numeral identifier for each phase. The value 0 is reversed for the unknown phase. + unit: NX_UNITLESS + phase_name: + doc: Name of the phase/alias. + number_of_reflectors(NX_UINT): + miller_indices(NX_NUMBER): + doc: Miller indices :math:`(hkl)[uvw]`. + unit: NX_UNITLESS + dimensions: + rank: 2 + dim: [[1, number_of_reflectors], [2, 6]] + mode: + doc: How are pattern being indexed? + enumeration: [optimize_bd] + # NEW ISSUE: what doesoptimize_bd mean Oxford? + min_bands(NX_NUMBER): + doc: Minimum number of bands required to index the pattern + dimensions: + rank: 1 + dim: [[1, n_p]] + status(NX_NUMBER): + doc: | + Which return value did the indexing algorithm yield for each pattern. + + * Details about bad pixels + * Too high angular deviation + * No solution + * Not analyzed + * Success + * Unexpected errors + + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + phase_identifier(NX_UINT): + doc: Labels referring to the phase_identifier for each pattern (from reflectors) that matched best. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + # NEW ISSUE: (NXorientation_set): + mean_angular_deviation(NX_FLOAT): + unit: NX_ANGLE + dimensions: + rank: 1 + dim: [[1, n_p]] + confidence_index(NX_FLOAT): + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, n_p]] + # on the other hand there are specific metadata to store with taking EBSD + # mappings + # tilt_angle(NX_FLOAT): + # maybe better make this integrated into the NXtransformations of the stage_lab, a stage_lab event? + # beam_position(NXcg_point_set): + # (NXdetector): + # exposure_time(NX_FLOAT): + # unit: NX_TIME + # gain(NX_FLOAT): + # ##MK how does a gain translate mathematically an input signal into an intensity signal? + # insertion_distance(NX_FLOAT): + # unit: NX_LENGTH + # ##MK a coordinate system for the detector in the NXcoordinate_system_set + # drift_correction(NX_BOOLEAN): ##MK?? + binning(NXcollection): + mode: + doc: Free-text description for instrument specific settings + # NEW ISSUE: binning replace by NXgrid + binning(NX_UINT): ##MK equivalent to pattern height and width? + doc: | + How is the camera signal binned. + First the number of pixel along the slow direction. + Second the number of pixel along the fast direction. + unit: NX_UNITLESS + dimensions: + rank: 1 + dim: [[1, 2]] + hough_transformation(NXprocess): + resolution(NX_NUMBER): + unit: NX_UNITLESS + profiling(NXcollection): + acquisition_speed(NX_FLOAT): + doc: Average number of patterns taken on average. + unit: NX_FREQUENCY + acquisition_time(NX_FLOAT): + doc: Wall-clock time the acquisition took. + unit: NX_TIME + hit_rate(NX_FLOAT): + doc: Fraction of successfully indexed pattern of the set. + unit: NX_DIMENSIONLESS + # NEW ISSUE: frame averaging + # NEW ISSUE: going towards the level of suggestions what would all be immediately possible + # ebsd_mapping(NXprocess): + # doc: | + # An EBSD mapping is the result of a collecting and indexing of Kikuchi + # pattern, so that for each pattern there is either an associated + # phase_identifier or a status marker stating that no solution was found + # (NXsst_color_model): ##MK + # doc: | + # For each stereographic standard triangle, (fundamental zone) of + # the orientation space, it is possible to define a color model which + # associates an orientation in the fundamental zone to a color. + # + # For details see: + # * [G. Nolze et al.](https://doi.org/10.1107/S1600576716012942) + # * Srikanth Patala and coworkers"'" work and of others. + # (NXorientation_set): + # doc: | + # Collection of quaternions in the SO3 fundamental zone with colors and + # details about how to plot the stereographic standard triangle (SST). + # rgb(NX_NUMBER): + # doc: RGB colors. + # unit: NX_UNITLESS + # dimensions: [[1, n_oris], [2, 3]] + # # hsv and other models + # (NXcg_point_set): + # rgb(NX_NUMBER): + # dimensions: [[1, n_points], [2, 3]] + # mapping(NX_NUMBER): + # doc: | + # The EBSD mapping with colors outlined + # unit: NX_UNITLESS + # dimensions: [[1, n_y], [2, n_x], [3, 3]] + # NEW ISSUE: it would also be possible to define additional color models to overlay diff --git a/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml new file mode 100644 index 0000000000..8ab388cf25 --- /dev/null +++ b/contributed_definitions/NXimage_set_em_ronchigram.nxdl.xml @@ -0,0 +1,12 @@ + + + + + Container for reporting a set of images related to a ronchigram. + + Ronchigrams are specifically used in transmission electron microscopy + to judge the settings for the aberration corrections and alignment. + + + + diff --git a/contributed_definitions/NXimage_set_em_se.nxdl.xml b/contributed_definitions/NXimage_set_em_se.nxdl.xml new file mode 100644 index 0000000000..a5ab12200b --- /dev/null +++ b/contributed_definitions/NXimage_set_em_se.nxdl.xml @@ -0,0 +1,142 @@ + + + + + + + Number of images. + + + + + Number of pixels along the slow scan direction (often y). + + + + + Number of pixels along the fast scan direction (often x). + + + + + Container for reporting a set of secondary electron images. + + Secondary electron images are one of the most important signal especially + for scanning electron microscopy in materials science and engineering, for + analyses of surface topography, getting an overview of the analysis region, + or fractography. + + + + Collected secondary electron images (eventually as an image stack). + + + + + + + + + + Secondary electron image intensity + + + + + + + + + + Image identifier + + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + Physical dimensions of the region-of-interest on + the specimen surface which the image covers. + The first and second number are the coordinates for the + minimum edge, the third and fourth number are the coordinates + for the maximum edge of the rectangular ROI. + + + + + + + + + + How many frames were averaged to obtain the image. + + + + + + + + Bias voltage applied to the e.g. Faraday cage in front of the + SE detector to attract or repell secondary electrons below + a specific kinetic energy. + + + + + Container to store relevant settings affecting beam path, + magnification, and working_distance + + + + + Scan rotation is an option offer by most control software. + + + + + Tilt correction is an option offered by most control software of SEMs + to apply an on-the-fly processing of the image to correct for + the excursion of objects when characterized with SE images + on samples whose surface normal is tilted about an axis perpendicular + to the optical axis. + + + + Was the option switched active or not. + + + + + + Dynamic focus is an option offered by most control software of SEMs + to keep the image also focused when probing locations on the specimens + beyond those for which the lens system was calibrated. + + + + Was the option switched active or not. + + + + diff --git a/contributed_definitions/NXinteraction_vol_em.nxdl.xml b/contributed_definitions/NXinteraction_vol_em.nxdl.xml new file mode 100644 index 0000000000..a6beeb6482 --- /dev/null +++ b/contributed_definitions/NXinteraction_vol_em.nxdl.xml @@ -0,0 +1,37 @@ + + + + + Base class for storing details about a modelled shape of interaction volume. + + The interaction volume is mainly relevant in scanning electron microscopy + when the sample is thick enough so that the beam is unable to illuminate + through the specimen. + Computer models like Monte Carlo or molecular dynamics / electron beam + interaction simulations can be used to qualify and/or quantify the shape of + the interaction volume. + + Explicit or implicit descriptions are possible. + + * An implicit description is via a set of electron/specimen interactions + represented ideally as trajectory data from the computer simulation. + * An explicit description is via an iso-contour surface using either + a simulation grid or a triangulated surface mesh of the approximated + iso-contour surface evaluated at specific threshold values. + Iso-contours could be computed from electron or particle fluxes through + an imaginary control surface (the iso-surface). + Threshold values can be defined by particles passing through a unit control + volume (electrons) or energy-levels (e.g. the case of X-rays). + Details depend on the model. + * Another explicit description is via theoretical models which may + be relevant e.g. for X-ray spectroscopy + + Further details on how the interaction volume can be quantified + is available in the literature for example: + + * `S. Richter et al. <https://doi.org/10.1088/1757-899X/109/1/012014>`_ + * `J. Bünger et al. <https://doi.org/10.1017/S1431927622000083>`_ + + + + diff --git a/contributed_definitions/NXion.nxdl.xml b/contributed_definitions/NXion.nxdl.xml new file mode 100644 index 0000000000..a066144821 --- /dev/null +++ b/contributed_definitions/NXion.nxdl.xml @@ -0,0 +1,91 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Maximum number of atoms/isotopes allowed per (molecular) ion + (fragment). + + + + + Number of mass-to-charge-state-ratio range intervals for ion type. + + + + + Set of atoms of a molecular ion or fragment in e.g. ToF mass spectrometry. + + + + Ion type (ion species) identifier. The identifier zero + is reserved for the special unknown ion type. + + + + + A vector of isotope hash values. + These values have to be stored in an array, sorted in decreasing order. + The array is filled with zero hash values indicating unused places. + The individual hash values are built with the following hash function: + + The hash value :math:`H` is :math:`H = Z + N*256` with :math:`Z` + the number of protons and :math:`N` the number of neutrons + of each isotope respectively. + + Z and N have to be 8-bit unsigned integers. + For the rationale behind this `M. Kühbach et al. (2021) <https://doi.org/10.1017/S1431927621012241>`_ + + + + + + + + Signed charge state of the ion in multiples of electron charge. + + Only positive values will be measured in atom probe microscopy as the + ions are accelerated by a negatively signed bias electric field. + In the case that the charge state is not explicitly recoverable, + the value should be set to zero. + + In atom probe microscopy this is for example the case when using + classical range file formats like RNG, RRNG for atom probe data. + These file formats do not document the charge state explicitly. + They report the number of atoms of each element per molecular ion + surplus the mass-to-charge-state-ratio interval. + With this it is possible to recover the charge state only for + specific molecular ions as the accumulated mass of the molecular ion + is defined by the isotopes, which without knowing the charge leads + to an underconstrained problem. + Details on ranging can be found in the literature: `M. K. Miller <https://doi.org/10.1002/sia.1719>`_ + + + + + Human-readable ion type name (e.g. Al +++) + The string should consists of ASCII UTF-8 characters, + ideally using LaTeX notation to specify the isotopes, ions, and charge + state. Examples are 12C + or Al +++. + Although this name may be human-readable and intuitive, parsing such + names becomes impractical for more complicated cases. Therefore, the + isotope_vector should be the preferred machine-readable format to use. + + + + + Associated lower (mqmin) and upper (mqmax) bounds of + mass-to-charge-state ratio interval(s) [mqmin, mqmax] + (boundaries included) for which the respective ion is labelled + as an ion of the here referred to ion_type. + + + + + + + diff --git a/contributed_definitions/NXlens_em.nxdl.xml b/contributed_definitions/NXlens_em.nxdl.xml new file mode 100644 index 0000000000..1fdfbb4e41 --- /dev/null +++ b/contributed_definitions/NXlens_em.nxdl.xml @@ -0,0 +1,77 @@ + + + + + Description of an electro-magnetic lens or a compound lens. + + For NXtransformations the origin of the coordinate system is placed + in the center of the lens + (its polepiece, pinhole, or another point of reference). + The origin should be specified in the NXtransformations. + + For details of electro-magnetic lenses in the literature see e.g. `L. Reimer <https://doi.org/10.1007/978-3-540-38967-5>`_ + + + + Qualitative type of lens with respect to the number of pole pieces. + + + + + + + + + + + + Given name, alias, colloquial, or short name for the lens. + For manufacturer names and identifiers use respective manufacturer fields. + + + + + Name of the manufacturer who built/constructed the lens. + + + + + + Hardware name, hash identifier, or serial number that was given by the + manufacturer to identify the lens. + + + + + Ideally an identifier, persistent link, or free text which gives further details + about the lens. + + + + + Excitation voltage of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Excitation current of the lens. For dipoles it is a single number. For higher + orders, it is an array. + + + + + Specifies the position of the lens by pointing to the last transformation in the + transformation chain in the NXtransformations group. + + + + + Collection of axis-based translations and rotations to describe the + location and geometry of the lens as a component in the instrument. + Typically, the components of a system should all be related relative to + each other and only one component should relate to the reference + coordinate system. + + + diff --git a/contributed_definitions/NXmanufacturer.nxdl.xml b/contributed_definitions/NXmanufacturer.nxdl.xml new file mode 100644 index 0000000000..54f1c8fd22 --- /dev/null +++ b/contributed_definitions/NXmanufacturer.nxdl.xml @@ -0,0 +1,29 @@ + + + + + Details about a component as defined by its manufacturer. + + + + Company name of the manufacturer. + + + + + Version or model of the component named by the manufacturer. + + + + + Ideally, (globally) unique persistent identifier, i.e. a serial number or hash + identifier of the component. + + + + + Free-text list with eventually multiple terms of functionalities which the + component offers. + + + diff --git a/contributed_definitions/NXoptical_system_em.nxdl.xml b/contributed_definitions/NXoptical_system_em.nxdl.xml new file mode 100644 index 0000000000..22db765166 --- /dev/null +++ b/contributed_definitions/NXoptical_system_em.nxdl.xml @@ -0,0 +1,13 @@ + + + + + A container for qualifying an electron optical system. + + + + + + + + diff --git a/contributed_definitions/NXpeak.nxdl.xml b/contributed_definitions/NXpeak.nxdl.xml new file mode 100644 index 0000000000..4eaffed5de --- /dev/null +++ b/contributed_definitions/NXpeak.nxdl.xml @@ -0,0 +1,66 @@ + + + + + + The symbols used in the schema to specify e.g. dimensions of arrays. + + + + Number of support points + + + + + Description of peaks, their functional form or measured support. + + + + Human-readable identifier to specify which concept/entity + the peak represents/identifies. + + + + + Is the peak described analytically via a functional form + or is it empirically defined via measured/reported + intensity/counts as a function of an independent variable. + + If the functional form is not empirical or gaussian, users + should enter other for the peak_model and add relevant details + in the NXcollection. + + + + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the position values for the independent variable. + + + + + + + + In the case of an empirical description of the peak and its shoulders, + this array holds the intensity/count values at each position. + + + + + + + + In the case of an analytical description (or if peak_model is other) this + collection holds parameter of (and eventually) the functional form. + For example in the case of Gaussians mu, sigma, cut-off values, + and background intensity are relevant parameter. + + + diff --git a/contributed_definitions/NXpump.nxdl.xml b/contributed_definitions/NXpump.nxdl.xml new file mode 100644 index 0000000000..3982438b55 --- /dev/null +++ b/contributed_definitions/NXpump.nxdl.xml @@ -0,0 +1,18 @@ + + + + + Device to reduce an atmosphere to a controlled remaining pressure level. + + + + Principle type of the pump. + + + + + + + + + diff --git a/contributed_definitions/NXscanbox_em.nxdl.xml b/contributed_definitions/NXscanbox_em.nxdl.xml new file mode 100644 index 0000000000..0af3ac4f8f --- /dev/null +++ b/contributed_definitions/NXscanbox_em.nxdl.xml @@ -0,0 +1,19 @@ + + + + + Scan box and coils which deflect an electron beam in a controlled manner. + + In electron microscopy, the scan box is instructed by the microscope + control software. This component directs the probe to controlled + locations according to a scan scheme and plan. + + + + + + + + + + diff --git a/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml new file mode 100644 index 0000000000..e41ce1a860 --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_auger.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of auger electron energy spectra. + + + + diff --git a/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml new file mode 100644 index 0000000000..20ce7bf72d --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_cathodolum.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of cathodoluminescence spectra. + + + + diff --git a/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml new file mode 100644 index 0000000000..7e44d1f118 --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_eels.nxdl.xml @@ -0,0 +1,9 @@ + + + + + Container for reporting a set of electron energy loss spectra. + + + + diff --git a/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml new file mode 100644 index 0000000000..916f1376a3 --- /dev/null +++ b/contributed_definitions/NXspectrum_set_em_xray.nxdl.xml @@ -0,0 +1,215 @@ + + + + + + + Number of scan points + + + + + Number of pixel per Kikuchi pattern in the slow direction + + + + + Number of pixel per Kikuchi pattern in the fast direction + + + + + Number of X-ray photon energy (bins) + + + + + Number of identified elements + + + + + Number of peaks + + + + + Container for reporting a set of energy-dispersive X-ray spectra. + + Virtually the most important case is that spectra are collected in + a scanning microscope (SEM or STEM) for a collection of points. + The majority of cases use simple d-dimensional regular scan pattern, + such as single point, line profiles, or (rectangular) surface mappings. + The latter pattern is the most frequently used. + + For now the base class provides for scans where the settings, + binning, and energy resolution is the same for each scan point. + + `IUPAC instead of Siegbahn notation <https://doi.org/10.1002/xrs.1300200308>`_ should be used. + + + + Collected X-ray counts chunked based on rectangular images. + + This representation supports only rectangular scan pattern. + + + + + + + + + + + X-ray photon counts + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + + + + X-ray energy + + + + + + + Details about computational steps how peaks were indexed as elements. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an ever persistent resource + where the source code of the program and build instructions can be found so that the program + can be configured in such a manner that the result file is ideally recreatable yielding the + same results. + + + + + + Name and location of each X-ray line which was indexed as a known ion. + For each ion an NXion instance should be created which specifies + the origin of the signal. For each ion also the relevant IUPAC notation + X-ray lines should be specified. + + + + + IUPAC notation identifier of the line which the peak represents. + + This can be a list of IUPAC notations for (the seldom) case that + multiple lines are group with the same peak. + + + + + + + List of the names of identified elements. + + + + + + + + Individual element-specific EDX/EDS/EDXS/SXES mapping + + A composition map is an image whose intensities for each pixel are the + accumulated X-ray quanta *under the curve(s)* of a set of peaks. + + + + Given name of the program that was used to perform this computation. + + + + Program version plus build number, commit hash, or description of an ever persistent resource + where the source code of the program and build instructions can be found so that the program + can be configured in such a manner that the result file is ideally recreatable yielding the + same results. + + + + + + A list of strings of named instances of NXpeak from indexing + whose X-ray quanta where accumulated for each pixel. + + + + + + + + Human-readable, given name to the image. + + + + + Individual element-specific maps. Individual maps should + each be a group and be named according to element_names. + + + + + + + + + + Accumulated X-ray photon counts + + + + + + + + + Label for the y axis + + + + + + + + + + Label for the x axis + + + + + + + diff --git a/contributed_definitions/NXstage_lab.nxdl.xml b/contributed_definitions/NXstage_lab.nxdl.xml new file mode 100644 index 0000000000..5aa4c431a2 --- /dev/null +++ b/contributed_definitions/NXstage_lab.nxdl.xml @@ -0,0 +1,137 @@ + + + + + A stage lab can be used to hold, align, orient, and prepare a specimen. + + Modern stages are multi-functional devices. Many of which offer a controlled + environment around (a part) of the specimen. Stages enable experimentalists + to apply stimuli. A stage_lab is a multi-purpose/-functional tools which + can have multiple actuators, sensors, and other components. + + With such stages comes the need for storing various (meta)data + that are generated while manipulating the sample. + + Modern stages realize a hierarchy of components: For example the specimen + might be mounted on a multi-axial tilt rotation holder. This holder is + fixed in the support unit which connects the holder to the rest of the + microscope. + + In other examples, taken from atom probe microscopy, researchers may work + with wire samples which are clipped into a larger fixing unit for + convenience and enable for a more careful specimen handling. + This fixture unit is known in atom probe jargon as a stub. + Stubs in turn are positioned onto pucks. + Pucks are then loaded onto carousels. + A carousel is a carrier unit with which eventually entire sets of specimens + can be moved in between parts of the microscope. + + An NXstage_lab instance reflects this hierarchical design. The stage is the + root of the hierarchy. A stage carries the holder. + In the case that it is not practical to distinguish these two layers, + the holder should be given preference. + + Some examples for stage_labs in applications: + + * A nanoparticle on a copper grid. The copper grid is the holder. + The grid itself is fixed to the stage. + * An atom probe specimen fixed in a stub. In this case the stub can be + considered the holder, while the cryostat temperature control unit is + a component of the stage. + * Samples with arrays of specimens, like a microtip on a microtip array + is an example of a three-layer hierarchy commonly employed for + efficient sequential processing of atom probe experiments. + * With one entry of an application definition only one microtip should be + described. Therefore, the microtip is the specimen, + the array is the holder and the remaining mounting unit + that is attached to the cryo-controller is the stage. + * For in-situ experiments with e.g. chips with read-out electronics + as actuators, the chips are again placed in a larger unit. + * Other examples are (quasi) in-situ experiments where experimentalists + anneal or deform the specimen via e.g. in-situ tensile testing machines + which are mounted on the specimen holder. + + To cover for an as flexible design of complex stages, users should nest + multiple instances of NXstage_lab objects according to their needs to reflect + the differences between what they consider as the holder and what + they consider is the stage. + + Instances should be named with integers starting from 1 as the top level unit. + In the microtip example stage_lab_1 for the stage, stage_lab_2 for the holder + (microtip array), stage_lab_3 for the microtip specimen, respectively. + The depends_on keyword should be used with relative or absolute naming inside + the file to specify how different stage_lab instances build a hierarchy + if this is not obvious from numbered identifiers like the stage_lab_1 to + stage_lab 3 example. The lower it is the number the higher it is the + rank in the hierarchy. + + For specific details and inspiration about stages in electron microscopes: + + * `Holders with multiple axes <https://www.nanotechnik.com/e5as.html>`_ + * `Chip-based designs <https://www.protochips.com/products/fusion/fusion-select-components/>`_ + * `Further chip-based designs <https://www.nanoprobetech.com/about>`_ + * `Stages in transmission electron microscopy <https://doi.org/10.1007/978-3-662-14824-2>`_ (page 103, table 4.2) + * `Further stages in transmission electron microscopy <https://doi.org/10.1007/978-1-4757-2519-3>`_ (page 124ff) + * `Specimens in atom probe <https://doi.org/10.1007/978-1-4614-8721-0>`_ (page 47ff) + * `Exemplar micro-manipulators <https://nano.oxinst.com/products/omniprobe/omniprobe-200>`_ + + + + Principal design of the stage. + + Exemplar terms could be side_entry, top_entry, + single_tilt, quick_change, multiple_specimen, + bulk_specimen, double_tilt, tilt_rotate, + heating_chip, atmosphere_chip, + electrical_biasing_chip, liquid_cell_chip + + + + + Given name/alias for the components making the stage. + + + + + + Ideally, a (globally) unique persistent identifier, link, + or text to a resource which gives further details. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + Should be defined by the application definition. + + + + + + + + Voltage applied to the stage to decelerate electrons. + + + + + The rotation, tilt and position of stage components can be specified + either via NXtransformations or via the tilt_1, tilt_2, rotation, + and position fields. + + + +