Block Hierarchy Meta Data: Difference between revisions
Line 1: | Line 1: | ||
=Problem statement= | ==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. | 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. | 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. |
Revision as of 13:50, 16 July 2008
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.