NXms_interface_setΒΆ
Status:
base class, extends NXobject
Description:
Base class to describe details about interfaces observed in microstructures.
Classically, interfaces are two-dimensional crystal defects whose relevance is that they are agents which trigger crystal growth and discontinuities of the crystal at which defects can accumulate and solutes segregate with fundamental effect on the properties of materials. Conceptually, interfaces are a continuum-scale description of how atoms arrange spatio-temporally. Interfaces manifests as persistent defects. When inspected in more detail though they show atom dynamics, coarse-grainable into again interactions between line-type crystal defects (disconnections) through which interfaces are dynamic and can interact with other defects. Owing to this complexity very different descriptions are used depending on which length-, time-scale, and research question people address.
This is manifested in the large amount of literature on the topic:
Sutton et al. ISBN-13 978-0198500612
Gottstein et al. ISBN-13 978-1-4200-5436-1
Chen et al. https://doi.org/10.1073/pnas.1920504117
Interfaces, specifically grain and phase boundaries, are representatives of two-dimensional microstructural features. It would be rude to claim that a single base class can encompass the entire complexity that this effective coarse-graining of atomic spatio-temporal configurations has. In the end, interfaces are a model, an effort to simplicify the description in the hope to arrive at physical models which do not need to take into account the static and dynamic details of every atom.
However, it is also a fact that not every description, research question, and thus use cases that one could think of storing as data and metadata for interfaces, is equally relevant and useful for an ensemble of research studies.
Thus, for the design of concrete schemes for a structured storage of data on interfaces are measured or characterized, one has to prioritize which descriptors and aspects about interfaces are likely relevant for a large number of users of the research infrastructure. Consequently, it is possible to narrow down the scope of this base class.
It is noteworthy to mention that this applies not only to schemes build with NeXus, but points to the problem of creating a golden-bullet schema that could handle all possible subtleties of interfaces.
For now we have to accept that there is not yet an ontology of e.g. the above-mentioned understanding of what interfaces are.
Pragmatically we thus make the following assumptions:
This base class is essentially a template how specific, often referred to quantities, for two-dimensional crystal defects can be stored.
Coarse-graining point-like features into a curve or surfaces is an ill-posed problem. In practice, it has to be accounted for that interfaces have a finite extent, they are delineated by triple lines and quadruple junctions. Interfaces are thus connected into a three-dimensional network of defects. Interfaces can interact or intersect with other defects (partially or completely, as it is the case for disconnections).
There are the following general approaches of studying/characterizing:
Non-atomically resolved measurements of 2D or 3D sections. Examples are optical, electron, X-ray, or atom probe microscopy.
Under specific conditions using electron microscopy, electron tomography (provided numerical post-processing is applied) as well as with atom probe microscopy these measurement can resolve structural motifs of or in the interface plane.
Atomic-scale-resolved simulations. In this case the most frequently performed tasks are again post-processing snapshots with grain identification or graph-based techniques to identify which atoms belong to the regions with local changes or breakdown of the long-range crystal symmetry.
Analytical approaches whereby grain boundaries are resolved at the continuum scale, as surface defects containing other elementary defects (for instance) in models of disconnection motion), using eventual statistical approaches, or again atomically resolved treatments.
From this we can conclude that an NXms_interface_set can primarily be useful as a wrapper class in which specific details about interfaces can be stored in an arbitrarily nested manner.
Symbols:
The symbols used in the schema to specify e.g. dimensions of arrays.
- Groups cited:
none
Structure: