Database Reference
In-Depth Information
because it can be highly dependent on screen size. We note that using spa-
tial metadata typically yields a consistent performance improvement, whereas
performance gains resulting from metadata about fields defined on the mesh
(e.g., pressure, density, etc.) can be highly problem specific. To illustrate this
effect, we show results from running the contouring algorithm on simulation
data from both early and late timesteps. In earlier timesteps, the fluids have
not mixed much, so the shape of the contour approximates a planar slice and
does not intersect many domains. In the later timestep, the fluid has under-
gone substantial mixing, and the contour has much greater surface area due
to folding, so it intersects many more data domains.
In summary, the presence of metadata can improve performance to the
point of being interactive for certain algorithms. And interactivity is widely
regarded to be a key component for scientific discovery.
9.2.3 Data Models and Semantics
Visualization tools devote a substantial amount of code to representing data
(i.e., data structures), importing data, and translating it into those data
structures. Anecdotal evidence suggests that as much as 80% of any given vi-
sualization application is dedicated to these very activities. The large amount
of SDM-related code typically comes from the fact that various simulation
tools have many different ways to represent their data, and the visualization
often must support them all. By way of example, the VisIt visualization tool
devotes approximately 40,000 lines of code to various data structures. This
does not include the portion of the data model that is incorporated from a
third-party library (the Visualization ToolKit), which in fact forms the core of
the data model (the portion for mesh and field representations). In addition,
VisIt has over 80 separate file format readers, each of which ranges from 800
lines of code to 12,000 lines of code. Approximately 150,000 lines of code in
VisIt is devoted to file format readers.
In addition to a basic data model for representing standard mesh types (e.g.,
rectilinear, curvilinear, unstructured, adaptive mesh refinement (AMR), and
point meshes), and fields (e.g., scalars, vectors, and tensors), production vi-
sualization tools must understand many types of metadata about the dataset
to perform certain operations. We list a subset of this metadata to give a feel
for how deep the visualization tool must go:
For each array in the file that corresponds to data that should be visu-
alized, the tool must understand what this array is and how it should be
interpreted. For example, the visualization tool must understand that
an array in a file labeled “den” is in fact a scalar field defined on a mesh.
It is often not necessary to know that “den” is actually the density field,
but it may be necessary to know if the field values are explicit (i.e.,
density of some material per unit of volume) or implicit (i.e., density is
directly related to the volume of the cell).
