X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 Message-ID: <40F45B41.8060505@lbl.gov> Date: Tue, 13 Jul 2004 14:59:29 -0700 From: Wes Bethel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: diva at lbl dot gov Subject: Coding camp objectives X-Enigmail-Version: 0.76.8.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit As promised, here's a brain dump of coding camp objectives. The DiVA/CCA coding camp scheduled for July 27-28 in SLC is intended to focus on deriving answers to some fundamental questions that will help us better understand the strengths/weaknesses of CCA as a component model substrate for a Distributed Visualization Architecture (DiVA). What follows is a set of questions we're seeking answers for, and then a list of tasks that are intended to produce answers. 1. How well is CCA suited for existing design patterns used by current leading interactive visualization applications and toolkits? The context we're talking about here is an application that is an aggregration of a bunch of components (a la AVS, etc.) or method calls (a la VTK). For the July 2004 exercise, we want to focus on the latter approach to quickly answer a number of questions that will help us to better understand the suitability for CCA and one of the existing frameworks in these areas: a. Is it possible, and if so, how easy to wrap up VTK methods as CCA components? b. Once suitable wrapped, do any of the existing frameworks support deployment of components (let's say they're serial components for now) on distributed resources? c. What happens when when we interactive adjust parameters on any of the pipeline components? The desired behavior is that the change on some components parameters will result in downstream components (in the dataflow sense) to execute accordingly. 2. How well does CCA accommodate existing implementations of data structures. This includes the ability to wrap complex data structures (eg. templates and iterators) and the performance impact of this wrapping both for local and remote utilization. a. How well does SIDL/BABEL support the automation of marshaling and unmarshaling for remote data transfer vs. local data exchanges between components? Is the support for local/remote abstraction completely transparent or is that a "framework issue"? "How well" is measured in terms of programming pain, performance efficiency and perceived maintainability. b. For iterator-based data models (FM, for example), there are two subquestions. The first concerns language issues: FM, for example, makes heavy use of templates, which may cause some problems when used in CCA (or the may not - we need to find out). Second, we wish to better understand the impact on performance that will result from using both fine- and coarse-grained data model libraries wrapped in CCA using SIDL/BABEL. E.g., there is an outstanding question of not fully understanding the performance overhead that will be incurred by having lots of method calls transmitted between components as small chunks of data are requested then moved. Related, we want to compare the performance of coarse-grained approaches (MxN and similar) vs. fine-grained (FM, an iterator-based DML). 3. Does CCA offer any specific benefit for supporting interoperation between components that have different internal data representations and/or calling interfaces (eg. connecting a VTK component to a SCIRun component), or are the capabilities conferred by CCA orthogonal to issues of interoperability? To achive these objectives, what we (LBL guys) plan to do prior to the coding camp is to attempt to build all this stuff and begin testing. That way, we'll be spending time fixing things rather than composing software. This approach will hopefully make the best use of time while at the coding camp. We intend to proceed along the following lines: Usability for interactive vis apps: Create a simple VTK pipeline in C++ where all data manip and rendering is performed by standard VTK tools. Wrap the methods as CCA components and deploy them in one or more CCA frameworks. Choose methods that have user-tweakable paramters; e.g., isosurface generator. Replace the standard VTK rendering component with one of our own making (that uses other software). There is a small data modeling issue to be solved here... our solution will be some disposable code created simply for the purposes of the experiment. These two tasks will provide us with the tools we need to begin obtaining answers to questions in (1) above. Data Models stuff: Comparative data marshal/send performance measurement for bulk data transfers. Take some existing (very simple) vis components (written by a graduate student during a recent performance modeling and optimization project) and port them to be CCA components. We can measure the performance of local and distributed pipelines in each configuration (native, using CCA w/SIDL&BABEL marshal/ send/unmarshal). Comparative data marshal/send performance for fine-grained data transfers. Build some simple components (they don't even need to be vis components) that use an iterator-based method (e.g., FM) to communicate data. Measure performance between native and CCA-wrapped versions when components are run (1) on the same host, (2) on different hosts (same platform) (3) different hosts (different platform). These two tasks should be sufficient for us to begin obtaining answers to all questions in (2) above.