From: Randall Frank <frank12@llnl.gov>

Date: Tue Sep 2, 2003 1:05:06 PM US/Pacific

To: John Shalf <jshalf@lbl.gov>

Cc: diva@lbl.gov

Subject: Re: DiVA Survey (Please return by Sept 10!)

At 03:49 PM 8/29/2003 -0700, John Shalf wrote:

...

I think that interoperability (both in terms of data and perhaps more

critically operation/interaction) is more critical than fine-grained

data sharing. My motivation: there is no way that DiVA will be able to

meet all needs initially and in many cases, it may be fine for data to

go "opaque" to the framework once inside a "limb" in the framework (e.g.

VTK could be a limb). This allows the framework to be easily populated

with a lot of solid code bases and shifts the initial focus on important

interactions (perhaps domain centric). Over time, I see the fine-grain

stuff coming up, but perhaps proposed by the "limbs" rather than the

framework. I do feel that the coarse level must take into account

distributed processing however...

To that end, how did you go about wrapping data structure transfers for VisIt? Is it a very straightforward serialization or pointer-hand-off of VTK datastructures or was there motivation to create your own structures/methods for inter-component data handling?

Ok, here is the low-down. VisIt internally uses most of the VTK

data model, with some additional "stand-aside" structures for things

like SILs (subset inclusion lattice) and the like (VisIt marries some

SAF ideas to the VTK data model under the hood, to provide the level

of control and data access our users were requesting). VisIt provides

its own interface to the data readers, but the readers can be VTK

objects as well (they can rely on an upper level class to deal with the

SIL and load balancing). So, VisIt can just "pointer-hand-off" to

VTK objects under the hood. VisIt's execution model fires off the

VTK objects by hand. I should note that the VTK distributed node

transport mechanisms are not used in VisIt at all. VisIt takes care

of all the distributed marshalling. VTK is used more like a library

and less like a system. I could go into all the motivations for

this model if folks are interested, but this train of thought is in

line with my earlier comments. I want to facilitate interfaces

between packages, opting for (possibly specific) data models that map

to the application at hand. I could use some generic mechanisms

provided by DiVA to reduce the amount of code I need or bootstrap

more rapid prototyping, but it is not key that the data model be

burned fully into the Framework. I certainly feel that the Framework

should be able to support more than one data model (since we have

repeatedly illustrated that all "realizable" models have design

boundaries that we will eventually hit.

Thanks.

-john

rjf.

Randall Frank | Email: rjfrank@llnl.gov

Lawrence Livermore National Laboratory | Office: B451 R2039

7000 East Avenue, Mailstop:L-561 | Voice: (925) 423-9399

Livermore, CA 94550 | Fax: (925) 423-8704