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)