Data Structures and Workflows for ICME
27
Fig. 3 A schematic example
of two grains from a crystal
plasticity simulation, each
meshed by a set of tetrahedra.
The data structure should be
capable of storing
information on all unit
elements of the mesh: points,
edges, faces, and tetrahedra,
with support for various
component dimensions. The
data in this example are stress
and strain tensors (σ ij and
ε ij ), triple line identifiers (t),
misorientation (Δg), and
grain orientation (g)
on the data. Thus, a scalable approach to storing multicomponent data is necessary.
Another practical requirement is the fundamental type used to represent the data.
Identifiers may be stored as integers, while orientations may be stored as floating
point numbers. Precision may also vary (e.g., 32-bit or 64-bit floating point), while
integers must consider being signed or unsigned. Data type handling is partly tied
to the implementation: certain languages, such as C and C++, utilize strong typing,
whereas Python utilizes the weaker duck typing. Regardless, a successful data
schema must be capable of representing data of various types, with adjustments
as needed for the given language.
A final data handling requirement stems from the natural structure of materials.
Materials are inherently hierarchical: physical phenomena couple across multiple
length scales to yield observed behavior and performance at the macroscale. Representing this natural hierarchy is critical to fully capturing the space of materials
information. Figure 4 shows an example of this hierarchy for a cast Ni-base superalloy blade. Note the inherent coupling and reciprocity across the scale continuum. An
ICME data structure must be capable of allowing users to efficiently move across
these scales; thus, a mapping scheme is required that shifts reference up and down
the hierarchy. For field data, this translates to an ability for arbitrarily grouping the
various simplicial complexes that comprise the data geometry, which can then be
continuously grouped further until all data are members of a unifying set.
4.2 Modular Workflow Requirements
Beyond efficient storage of materials field data, a user should be capable of
interacting with that data through a standardized interface. Ideally, this interface
27
Fig. 3 A schematic example
of two grains from a crystal
plasticity simulation, each
meshed by a set of tetrahedra.
The data structure should be
capable of storing
information on all unit
elements of the mesh: points,
edges, faces, and tetrahedra,
with support for various
component dimensions. The
data in this example are stress
and strain tensors (σ ij and
ε ij ), triple line identifiers (t),
misorientation (Δg), and
grain orientation (g)
on the data. Thus, a scalable approach to storing multicomponent data is necessary.
Another practical requirement is the fundamental type used to represent the data.
Identifiers may be stored as integers, while orientations may be stored as floating
point numbers. Precision may also vary (e.g., 32-bit or 64-bit floating point), while
integers must consider being signed or unsigned. Data type handling is partly tied
to the implementation: certain languages, such as C and C++, utilize strong typing,
whereas Python utilizes the weaker duck typing. Regardless, a successful data
schema must be capable of representing data of various types, with adjustments
as needed for the given language.
A final data handling requirement stems from the natural structure of materials.
Materials are inherently hierarchical: physical phenomena couple across multiple
length scales to yield observed behavior and performance at the macroscale. Representing this natural hierarchy is critical to fully capturing the space of materials
information. Figure 4 shows an example of this hierarchy for a cast Ni-base superalloy blade. Note the inherent coupling and reciprocity across the scale continuum. An
ICME data structure must be capable of allowing users to efficiently move across
these scales; thus, a mapping scheme is required that shifts reference up and down
the hierarchy. For field data, this translates to an ability for arbitrarily grouping the
various simplicial complexes that comprise the data geometry, which can then be
continuously grouped further until all data are members of a unifying set.
4.2 Modular Workflow Requirements
Beyond efficient storage of materials field data, a user should be capable of
interacting with that data through a standardized interface. Ideally, this interface