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