Date: Fri Sep 12, 2003 2:29:28 PM US/Pacific
To: email@example.com (John Shalf)
Subject: Re: DiVA Survey (Please return by Sept 10!)
John Shalf writes:
Another question John...
You mentioned that VTK is unable to deal well with time-varying data.
Can you provide a use-case or example of what VTK lacks here in
treatment of time-varying data? I've heard complaints that particle
advection scheme are typically done per-timestep with no notion of
temporal changes in the flow-field. Likewise there are more subtle
issues like it re-ranging the internal isosurface level-parameter to
match the range of the data it is presented on a per-timestep basis
(thereby making it difficult to hold the same isolevel through an
entire time-sequence where the min/max is constantly changing).
Well I wasn't aware of the isosurfacing issue, but definitely there is
not support for any routines that require temporal integration (e.g.
unsteady flow viz). In general, there is no notion of a timestep in
VTk. Datasets are 3D. Period.
Additionally, there is a performance issue: VTK is not optimized in any
way at moving data through the pipeline at high rates. It's underlying
archictecture seems to assume that as long as the pipeline eventually
generates some geometry, it's ok if it take a loooong time because
you're going to interact with that geometry (navigating through camera
space, color space, etc.) and the "pre-processing" doesn't have to run
at interactive rates. So the data readers are pathetically slow (and
there is little hope for optimization here with that data model that is
used). There is no way to exploit temporal coherence in any of the data
operators. No simple way to cache results if you want to play out of
What functionality needs to be supported to address this issue. Is it
a data-structure/data-representation issue or is it a system-level
Well I think it's both and I mentioned some of the things above. At a
high level you need a design that gives consideration to temporal needs
throughout the architecture. I think the data structures do need to be
time varying data aware, not just capable of dealing with 4D data
(although I can't think of a specific example of why now). One issue is
that the temporal dimension often has different spacing/regularity than
the spatial dimension. Obviously you're talking different units from
the spatial dimensions as well. There are also system-level issues as
well (e.g. unsteady flow viz needs, exploiting temporal coherence,
caching, support for exploring the temporal dimension from user
I know i've only just started to scratch the surface here. We could
probably devote an entire workshop to time varying data needs and
several more figuring out how to actually suppor them.
Hope this helps.
On Friday, September 5, 2003, at 03:40 PM, John Clyne wrote:
Must/Want: "vertex-centered" data, "cell-centered" data?
Must: support time-varying data, sequenced, streamed data?
Must. Time varying data is what makes so many of our problems currently
intractible. Too many of the available tools (e.g. VTK) assume static
data and completely fall apart when the data is otherwise.
John Clyne (firstname.lastname@example.org)
National Center for Atmospheric Research
1850 Table Mesa Dr. Boulder, CO 80303 USA
1.303.497.1236 (v), 1.303.497.1239 (fax)