Block Hierarchy Meta Data

Problem statement

Several file formats have multiple ways of representing data blocks in hierarchies. The most of important of these are Exodus and SILO. All Exodus data files contain a collection of element blocks. Furthermore, some contain additional meta-data to groups these blocks into hierarchies and also material groups. Similarly, SILO files contains domains and materials. One major difference between the two formats is that, in SILO, domains are element blocks that can contain multiple materials. There is a separate data structure that lists the elements of different materials. Therefore, extract a certain material out of a domain requires reading the whole domain and the list of elements for that material and then extracting those elements out.

The problem we are trying to address is the fact that there is no easy way of getting meta-data about these blocks, materials and hierarchies and delivering it to the client for use by the GUI. Currently, the GUI knows nothing about the relationship between blocks, materials and hierarchies. For example, when the user selects a material, the GUI updates the server side reader's material selection and asks it to give back a new selection for all blocks and hierarchies. For large number of blocks, this has a significant overhead. We want to be able to deliver the whole hierarchy as meta-data to the client so that the selection GUI can avoid any additional communication with the server.

Proposed solution

First of all, we need a data structure that represents the various data hierarchies. For this, I propose using a DAG. An example DAG is below.

Here, the top node SIL is an artificial root. It points to three groupings: Blocks, Materials and Assembly. All these grouping are subdivided further. The important thing to note is that all leaf nodes are blocks. This is natural for Exodus files since blocks are the smallest building blocks of a datasets. It is not as natural for SILO since these "blocks" correspond to individual materials inside domains. However, this DAG still contains all the necessary information to represent the hierarchy inside SILO files.

This DAG will have to be created by the reader and provided as meta-data. The easiest way of doing this is for the reader to create a vtkGraph (vtkMutableDirectedGraph actually) and adding it to the output information. Once the DAG is available as meta-data, an information object can bring it back to the client side. This is especially easy with vtkGraph because it can be serialized/unserialized using the legacy writers/readers.

Once on the client side, a custom item model would adapt this DAG to a set of tree widgets - one per grouping. The existing GUI is sufficient and does not have to change. Here, if the user unselects a particular node, for example "Steel" in this example, the GUI code has to traverse down the graph and unselect all the leaf nodes, blocks 1 and 2 in this example. Then, the model for blocks and assembly would be updated based on this information. Note that to determine whether a non-leaf node is on, off or partial, the GUI has to traverse down to the leaf nodes.

Once the user applies, all the GUI has to do is to send a list of blocks to the reader. No information about materials or hierarchies is needed. This will probably require a bit of work for the SILO reader since it does not know about blocks but it should be fairly easy.