Visualizing AMR Data with Embedded Boundaries
Our initial goal is to provide a basic set of tools for visualizing AMR data with embedding boundaries. More importantly, we want to provide a framework to do this type of visualization that can be extended by the users of AMR (with or without embedded boundaries) and reused by us for the visualization of other computations done using a variable number of grids at a variety of resolutions.
Computations done with adaptively refined grids are not directly viewable with the currently available "off the shelf" visualization tools (e.g. AVS, DX, and VTk). All these tools primarily deal with individual grids that are logically a single array of numbers (e.g. scalars, vectors, and tensors). These arrays may be multidimensional and each point in the array may be mapped to an arbitrary position in some physical space but the visualization tools only deal with one of these at a time. If there are multiple arrays, they have to be handled independently. If there are a variable number of them it may not be possible to handle them directly. Even if this is possible, it may be necessary to take into account their interdependencies (e.g. if the data in some grids overrides data in coarser grids) and not treat them independently.
In addition to the adaptively refined grids, these data sets contain embedded boundaries and the data structures to represent them. Visualizing these is currently an open issue. On the one hand, these are represented (or, at least, stored to disk) as a flat grid of information. On the other hand, the information contain at each cell in the grid can be quite complex, encoding multiple fluids per cell, their volumes, the connections to other cells, and the resulting area fractions of these connections. In addition, there is no direct, unambiguous geometric interpretation of this data. Approaches to this will be discussed after we discuss visualizing adaptively refined grids.
There are a number of ways to address the problems of visualizing adaptively refined grids (or, in general, a collection of grids that possibly have some interdependency) and our goal to provide a set of tools that mirror these approaches as they all have merits and shortcomings.
The often one of the easiest things to do is to "flatten" the data set. This means that one grid is chosen or created and all the data from all the grids is mapped onto that grid. For example, in the case of the AMR data, if one grid at the maximum resolution is created which spans the entire computation space then all the data from all the grids can be written into that grid with the coarser data being overwritten by the finer data. This illustrates several things. The some of original data and all its structure are lost. The grid needed for this may be quite large. Data selected or picked from the flattened grid can be very difficult to trace back to the original data set (e.g. where did this value come from). The interdependencies in the data (e.g. fine data overrides coarse data) are handled at this point. In addition, for other collections of grids it may be fairly difficult to define one grid that they all map into. Even with all these shortcomings, this technique provides immediate access to most visualization packages and all the tools they contain. Also, by flattening the data to different resolutions different views of the data are possible.
Another possibility is to extend the basic visualization tools to handle a list of grids (or some more complex structure) in the following way. Add some type of iteration mechanism so that the available visualization tools can be used and iterated over all the grids. There are, at least, two forms this can take. In one case, an object can be added to the visualization package and the tools can be extended so that when they encounter this object they iterate through all the things (e.g. grids) it contains and produce outputs that mirror this. For example, if the input was a list of grids and the visualization tool was "isosurface" then the output would be a list of isosurfaces (i.e. a list of geometric objects). Another possibility is to iterate over the grids in the list and provide them (one at a time) as the input to a visualization network/pipeline and then superimpose all the results. In either case, the result is an independent collection of visualizations that can be viewed simultaneously. The shortcoming of this approach is that the grids are handled independently and no integration occurs until the rendering of the results of the independent visualization operations. This can still be useful, especially if there is some reasonable mechanism for selecting various subsets of the lists or collections (e.g. all the grids at a given level, all the grids coarser or finer than a certain amount, all the grids in some portion of the problem space). Also, the modifications to the original visualization tools may be fairly simple and they are all then available for visualization. Finally, data selected or picked in the visualization can be fairly directly tracked back to the grid (or grids) it may have come from since they are handled independently and simply merged when displayed.
The final possibility for visualizing groups of grids that will be discussed here involves truly integrating the interdependencies and interrelationships between the grids into the visualization tools. For example, to produce an accurate isosurface from a set of adaptively refined grids which doesn't have "seams" or "tears" it is necessary to interpolate the data over the problem domain in a smooth, consistent way. This will demand viewing all the grids and their data simultaneously. Similarly, doing a volume rendering which takes advantage of the various levels of refinement but accurately represents the data set needs to take into account the detailed interrelationship of the grids. This can be achieved by translating a given representation of a collect of grids (e.g. AMR adaptively refined grids) into a representation appropriate for doing visualization and then extending a visualization package by adding tools that deal with this new representation of data. The advantages of this stem from the fact that the interdependencies and interrelationships between the grids can be used when appropriate and preserved as long as possible. Because of this, very accurate visualization can be done and tracing back from the visualization to the original data can be straightforward. The disadvantage of this is that most (if not all) of the visualization tools that deal with grids will have to be written (or modified) to correctly handle the new representation. On the other hand, once data output by a tool is something that is part of the original visualization package (e.g. the geometric output of a new isosurface tool) then the preexisting tools (e.g. coloring geometry, slicing geometry, rendering geometry) can manipulate it.
Finally, we come to the topic of visualizing embedded boundaries. Our current plan is to handle the visualization of these separated from the adaptively refined grids. We will also provide the capability of finding and displaying relevant data based on things picked in the visualization of the AMR data. For example, if a cell is selected and it contains a boundary then it will be possible to get the information associated with that and view it. This may also affect how a cell is represented in the visualization (e.g. its color may be noticeably different). It should also be possible to control how the information from the embedded boundaries is integrated with the AMR data/information. Sometimes it would be useful to see which cells contained boundary and sometimes it would be useful to have them "blend in". In addition, geometry (which may not be unique) can be created for the embedded boundaries on a cell by cell basis or in some integrated fashion and this geometry can be viewed.
The approach described above was used to begin to extend Vtk. This effort was stopped when we discovered that similar work had been going on at NCSA for several years. It addition, much of the data they were visualizing was generated using a early version of the CCSE/ANAG AMR library. We then went about getting these extensions, installing them, and evaluating the result. We continue to approach the problem as outlined above simply using this work as a very useful starting point.