Data Structures and Workflows for ICME
31
A key component of the DREAM.3D software architecture is its modular
nature; this allows for dependencies to be added or swapped as needed for a
given application. Most commonly, this approach is taken for adding new plugin
dependencies. For example, an image processing plugin in DREAM.3D leverages
ITK as an underlying dependency, bringing the power and flexibility of a tool
originally designed for medical image analysis into the materials domain.
The following sections overview the structure of both SIMPL and DREAM.3D,
including: data structure; filter, pipeline, and plugin infrastructure; graphical interface; and analysis capabilities.
5.1 SIMPL Data Structure
The SIMPL data structure is inspired by approaches in other well-known libraries,
such as VTK, along with methods in combinatorics and topology. The data structure
was designed to directly address those requirements stated in the Data Handling
Requirements section above. Principally, the data structure takes the form of a tree;
since trees are hierarchical, the data structure is able to naturally conform to the
grouping requirements needed for materials data. Items within the data structure are
generally termed objects, with four primary types of objects available:
• Data Container Array: The root node of the data structure. The data container
array has access to create and retrieve all descended children objects and check
the structure for validity.
• Data Container: The direct descendant of data container array, data containers
store attribute matrix objects that correspond to a unique geometry. Data
containers are therefore distinguished by what geometry they represent.
• Attribute Matrix: Stored within data containers, attribute matrices contain the
objects that store the dense data on each geometry. Attribute matrices are
distinguished by a type identifier which signifies at what specific grouping
hierarchy the data should be associated. Additionally, attribute matrices define
the shape of the underlying dense data.
• Attribute Array: Attribute arrays are the leaves of the data structure tree and store
the heavy field data for a given dataset.
Objects within the data structure have an associated name; similar to a standard
file system, no two objects at the same level of the tree are allowed to have the
same name. Additionally, objects deeper within the tree have a unique path, the
concatenation of all parent object names with the child. An example data structure is
shown in Fig. 6. In this example, two data containers are stored in the data container
array, one that represents an image and one that represents a surface mesh.
Geometries are a special kind of data structure object, represented by the red
boxes in Fig. 6. A data container may only store one geometry, and usually this
geometry is unique within the overall data structure. The child attribute matrices
31
A key component of the DREAM.3D software architecture is its modular
nature; this allows for dependencies to be added or swapped as needed for a
given application. Most commonly, this approach is taken for adding new plugin
dependencies. For example, an image processing plugin in DREAM.3D leverages
ITK as an underlying dependency, bringing the power and flexibility of a tool
originally designed for medical image analysis into the materials domain.
The following sections overview the structure of both SIMPL and DREAM.3D,
including: data structure; filter, pipeline, and plugin infrastructure; graphical interface; and analysis capabilities.
5.1 SIMPL Data Structure
The SIMPL data structure is inspired by approaches in other well-known libraries,
such as VTK, along with methods in combinatorics and topology. The data structure
was designed to directly address those requirements stated in the Data Handling
Requirements section above. Principally, the data structure takes the form of a tree;
since trees are hierarchical, the data structure is able to naturally conform to the
grouping requirements needed for materials data. Items within the data structure are
generally termed objects, with four primary types of objects available:
• Data Container Array: The root node of the data structure. The data container
array has access to create and retrieve all descended children objects and check
the structure for validity.
• Data Container: The direct descendant of data container array, data containers
store attribute matrix objects that correspond to a unique geometry. Data
containers are therefore distinguished by what geometry they represent.
• Attribute Matrix: Stored within data containers, attribute matrices contain the
objects that store the dense data on each geometry. Attribute matrices are
distinguished by a type identifier which signifies at what specific grouping
hierarchy the data should be associated. Additionally, attribute matrices define
the shape of the underlying dense data.
• Attribute Array: Attribute arrays are the leaves of the data structure tree and store
the heavy field data for a given dataset.
Objects within the data structure have an associated name; similar to a standard
file system, no two objects at the same level of the tree are allowed to have the
same name. Additionally, objects deeper within the tree have a unique path, the
concatenation of all parent object names with the child. An example data structure is
shown in Fig. 6. In this example, two data containers are stored in the data container
array, one that represents an image and one that represents a surface mesh.
Geometries are a special kind of data structure object, represented by the red
boxes in Fig. 6. A data container may only store one geometry, and usually this
geometry is unique within the overall data structure. The child attribute matrices