26
S. P. Donegan and M. A. Groeber
for automated materials discovery workflows, the present focus is placed on the
processing and analysis of materials field data.
4.1 Data Handling Requirements
Given the wide variety of data types produced by characterization and software
tools, a successful implementation of an ICME workflow manager must utilize
a flexible data structure to properly ingest and handle the different materials
information streams. The previously introduced critical aspects that help define
the diversity of materials data are: geometry, type, kind, and dimensionality. An
ICME data schema must implement a structure capable of handling variety in each
of these categories. Practically, this translates to a requirement to represent data on
different topology types, including point clouds, 2D and 3D meshes, and regular and
irregular rectilinear grids. A crucial component of representing these geometries is a
capability to store them together within a consistent spatial reference frame, which
enables direct correlation between different datasets. Such correlative workflows
are a cornerstone of effective ICME, allowing for direct validation of simulation
results using experimental measurements or simultaneous analysis of multimodal
information.
A result of this capability is an additional requirement to store data on any
unit element that composes a geometry. More generally, an effective data structure
should be flexible enough to store information on any component of a set of
simplicial complexes. Figure 2 showcases a simplified example of this need for
output from a crystal viscoplasticity simulation. Output from such a simulation
may be geometrically represented as a set of connected tetrahedra that tile the 3D
volume. Resulting stress and strain tensors could be stored on the vertices of the
tetrahedra, while crystal orientations might be stored on the tetrahedra themselves.
Additionally, further connectivity analysis may require information storage on the
faces or edges that compose the tetrahedra. For example, it may be advantageous
to store information about misorientations across grain boundaries, which would
naturally be stored on tetrahedral faces. Similarly, identification of triple lines would
be stored on tetrahedral edges where three grains meet. Importantly, what kind of
information, and where it should be stored, may not be known a priori for any given
problem; thus, the data structure should be extensible enough to handle changing
user requirements.
While cursory, the example in Fig. 3 demonstrates the requirement for flexibility
in geometric data storage. It also communicates a need for efficient storage of
multidimensional information. Triple line identifiers are scalar, while orientations
and full misorientations are at least three components. Stress and strain tensors,
as symmetric second-rank tensors, require storage of at least six components. In
principle, the number and shape of components is arbitrary, tailorable to the specific
application or analysis workflow. A common example of this specificity is the
number of time steps for a given simulation, which imposes an additional dimension
S. P. Donegan and M. A. Groeber
for automated materials discovery workflows, the present focus is placed on the
processing and analysis of materials field data.
4.1 Data Handling Requirements
Given the wide variety of data types produced by characterization and software
tools, a successful implementation of an ICME workflow manager must utilize
a flexible data structure to properly ingest and handle the different materials
information streams. The previously introduced critical aspects that help define
the diversity of materials data are: geometry, type, kind, and dimensionality. An
ICME data schema must implement a structure capable of handling variety in each
of these categories. Practically, this translates to a requirement to represent data on
different topology types, including point clouds, 2D and 3D meshes, and regular and
irregular rectilinear grids. A crucial component of representing these geometries is a
capability to store them together within a consistent spatial reference frame, which
enables direct correlation between different datasets. Such correlative workflows
are a cornerstone of effective ICME, allowing for direct validation of simulation
results using experimental measurements or simultaneous analysis of multimodal
information.
A result of this capability is an additional requirement to store data on any
unit element that composes a geometry. More generally, an effective data structure
should be flexible enough to store information on any component of a set of
simplicial complexes. Figure 2 showcases a simplified example of this need for
output from a crystal viscoplasticity simulation. Output from such a simulation
may be geometrically represented as a set of connected tetrahedra that tile the 3D
volume. Resulting stress and strain tensors could be stored on the vertices of the
tetrahedra, while crystal orientations might be stored on the tetrahedra themselves.
Additionally, further connectivity analysis may require information storage on the
faces or edges that compose the tetrahedra. For example, it may be advantageous
to store information about misorientations across grain boundaries, which would
naturally be stored on tetrahedral faces. Similarly, identification of triple lines would
be stored on tetrahedral edges where three grains meet. Importantly, what kind of
information, and where it should be stored, may not be known a priori for any given
problem; thus, the data structure should be extensible enough to handle changing
user requirements.
While cursory, the example in Fig. 3 demonstrates the requirement for flexibility
in geometric data storage. It also communicates a need for efficient storage of
multidimensional information. Triple line identifiers are scalar, while orientations
and full misorientations are at least three components. Stress and strain tensors,
as symmetric second-rank tensors, require storage of at least six components. In
principle, the number and shape of components is arbitrary, tailorable to the specific
application or analysis workflow. A common example of this specificity is the
number of time steps for a given simulation, which imposes an additional dimension