From: clyne@ncar.ucar.edu
Date: Fri
Sep 12, 2003 2:29:28 PM US/Pacific
To: jshalf@lbl.gov
(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
memory.
What functionality needs to be supported to address this
issue. Is it
a data-structure/data-representation issue or is it a
system-level
behavioral issue.
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
interactors).
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.
jc
On Friday, September 5, 2003, at 03:40 PM, John Clyne wrote:
Must/Want: "vertex-centered" data,
"cell-centered" data?
other-centered?
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
--
John Clyne (clyne@ncar.ucar.edu)
National Center for Atmospheric Research
1850 Table Mesa Dr. Boulder, CO 80303 USA
1.303.497.1236 (v), 1.303.497.1239 (fax)