From: James Kohl <>

Date: Thu Sep 11, 2003  7:59:11 AM US/Pacific

To: John Shalf <>


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



Hi John,


  On Wed, Sep 10, 2003 at 04:49:42PM -0700, John Shalf wrote:

On Wednesday, September 10, 2003, at 03:32 PM, James Kohl wrote:

What do you consider the most elegant/comprehensive implementation for

data representations that you believe could form the basis for a

comprehensive visualization framework?


Sounds like the "Holy Grail" to me...  If anything even remotely close

to this already existed, we'd all be using it already...

(Unless of course it's the dreaded NIH syndrome...)


I wanted to check to see if someone had already found the "Holy Grail"

and just forgot to tell the rest of us schmucks that game was up... :-)


I doubt it...  :-)  As I've mentioned before, the SciDAC TSTT center is

working on parts of this, but they are early in the progres....


For the purpose of this survey, "data analysis" is defined broadly as

all non-visual data processing done *after* the simulation code has

finished and *before* "visual analysis".

             * Is there a clear dividing line between "data analysis" and "visual

analysis" requirements?


NO.  There shouldn't be - these operations are tightly coupled, or even

symbiotic, and *should* all be incorporated into the same framework,

indistinguishable from each other.


Good, because there are folks in the SDM community who think vis people

don't care about this.   This question was intended to generate



Then you have succeeded...  :)


             * how should one manage parallelism for interactive scripting

languages that have a single thread of control?  (eg. I'm using a

commandline language like IDL that interactively drives an arbitrarily

large set of parallel resources.  How can I make the parallel back-end

available to a single-threaded interactive thread of control?)


Broadcast, Baby...  Either you blast the commands out to everyone SIMD

style (unlikely) or else you talk to the Rank 0 task and the command

gets forwarded on a fast internal network.


This leads to the question:  Does CCA support broadcast as an

interface/port construct?  How is broadcast expressed in SIDL?



This is an important point, that I have tried to express in various ways,

but will try again.  The CCA model supports exactly *one* type of interaction,

and that is "port-based" invocations.  A port is either a direct-connection

API in the local address space, or it is a proxy for a distibuted component's

API.  Either way, what you "pass" through a port is arguments to a method

invocation - these arguments can move data to the component or return results

from the invocation, e.g. "port->foo( in data, out results );", but there

isn't any concept of "dataflow" per se through a port.  If you want to move

data using a port invocation, it better look like port->heres_my_data( data );


If you want to send an MPI message, it is *outside* the scope of CCA.  If you

want one CCA framework to talk to another one, there better be a proxy "bridge"

provided by the two frameworks, or else you're on your own and better open

up a TCP socket (from "inside" your component implementation)...


For the "parallel" CCA frameworks, like "Ccaffeine", the components all talk

to each other *within* a process using CCA ports, and *between* processes

using whatever they want, say MPI, but this is *out-of-band* from CCA entirely.


Anyway, the short answer to your question about broadcast is "No."  The

CCA does not dictate or provide any mechanism for a front-end process to

"broadcast" anything to a back-end parallel application.  The CCA will

only help you build the parallel application from reusable software



I hope this makes sense, please let me know if not - I'll try again...  :-)