Interoperability of DOE Visualization Centers:
Technical Issues and Approaches

Nancy Johnston, Editor

Introduction and Purpose

This report is the product of the "Workshop on Interoperability of DOE Visualization Centers," held from March 30 to April 1, 1998, in Berkeley, California, and sponsored by the DOE Mathematical, Information, and Computational Sciences Office (MICS). The purpose of the workshop was to address technical issues relevant to the interchange and sharing of visualization research and software. The goal of the workshop was to produce this report, which identifies feasible solutions to the challenges posed by using tools developed in unfamiliar and sometimes incompatible environments.

Visualization experts from the national laboratories, other federally funded institutions, and academia were invited and attended this workshop. They will be referred to as "the attendees" throughout this document. Appendix A is the list of the attendees.

WHAT IS INTEROPERABILITY, AND WHY DO WE WANT IT?

Interoperability in the broadest sense is a continuum of capability that ranges from the informal discussions of ideas and algorithms to the sharing of software modules. We agreed on the following definition of interoperability in a stricter sense:

Interoperability is the idea that different developers, working almost entirely independently, can contribute software components to a common, quality-assured collection (e.g., a repository) AND that components can be easily obtained from this collection and easily combined into larger assemblies using a variety of interconnection mechanisms.

This definition is derived from a number of factors that influence the successful sharing of software between developers. For example, the idea that developers can work "almost entirely independently" is crucial. The more that human interaction is needed in order to share and exchange software, the less likely it is to happen over a large number of developers such as the DOE community. The idea of a "quality assured collection (e.g. a repository)" is also critical. What good is it to a developer if the software s/he can obtain through interoperating with other developers does not work or performs poorly? The idea that "components can be easily obtained from this collection" is another very important factor. In order for a developer to use someone else's software, s/he must first know that it even exists. Next, it is just as important to be able to easily locate and obtain the actual software. There are other issues as well. One is the granularity of the software components that are shared. Are they code fragments, libraries or whole executable programs? Another is the ease with which a component can be integrated into new software settings.

None of the attendees believed that we have a framework in place today to achieve the kind of interoperability defined above. More research and development is needed. What we can do now is start taking the steps needed to reach this goal. For example, at a basic level, we need the ability to share data. Users of today's visualization systems usually have to convert their data to a different format to try out a new or different visualization package. Often, this conversion is a painstaking process.

Why do we need or want interoperability? Some of the benefits of interoperability are easy to enumerate. If we can share code or code fragments, development is faster, duplication is avoided, and the cost of development is reduced. New functionality is easier to add to codes, and users will have a wider choice of capabilities to choose from. Researchers will better be able to ask "what if" questions. As more people use various pieces of visualization software, there is a better chance to catch and reduce bugs and to generalize the software for different computing environments.

Users of visualization software often have a different view of interoperability than software developers. A user may be more interested in ease of use, consistency of the user interface, and user interface terminology that reflects the terminology used in his or her scientific field. The developer may be more interested in portability issues, flexibility, and access to the source code. Both user and developer are interested in robustness, performance, functionality, and portability.

COSTS / BARRIERS / RISKS OF INTEROPERABILITY

The attendees identified three categories of barriers to interoperability: cost, technical, and psychological.

A major concern of the attendees was that interoperability is commonly perceived as being either free or easy to add to prototype research software. Interoperability is not free, and additional work is needed to make any software production-quality. For example, industry experts in software engineering estimate that the cost of developing production-quality software is easily 5-10 times that of the original research prototype. Visualization research activities are not well funded, and research will suffer if interoperability requirements are added without additional funding.

Some of the technical barriers the attendees identified include:

• Large data sets and multi-source data. Tera-scale and peta-scale data sets require a rethinking of much of the visualization software that has been developed to date. Similar comments apply to the integration of different data sources in a common visualization.
• Performance. Speed and predictability of response are essential to the success of any tool.
• Remote collaboration. The locations of the computer/visualization server and the researchers are becoming more dispersed. Additionally, researchers want to work simultaneously with other researchers at different sites to visualize and interact with their data.

Psychological barriers include a lack of motivation or a feeling of "why bother." For example, a developer might ask "What will I get in return?" Frequently, developers are being pushed by day-to-day, short-term needs of their scientific programs, and producing a software module that can be used by others is not highly regarded by their management.

Another barrier is each laboratory's desire to hold onto its intellectual property rights. If we exchange software and changes are made to it at another site, who owns the result? The consensus of the workshop was that DOE headquarters needs to deal with this issue.

WHERE ARE WE TODAY?

The attendees agreed that today most interaction is done on an informal basis at conferences or meetings. Members of the visualization community can meet and exchange information at three regularly scheduled conferences: the ACM Siggraph Conference, the IEEE Visualization Conference, and the DOE Computer Graphics Forum (DOECGF). The first two are conferences where one goes to learn about the latest research in the field of computer graphics and visualization.

The DOECGF is an informal meeting of representatives from DOE national laboratories and other invited federally funded organizations. DOECGF has met annually since 1975. Originally founded to discuss topics in computer graphics, the DOECGF has continually updated the topics of interest, and now deals predominantly with the many facets of scientific visualization.

All of these forums provide an important place for exchange of information, ideas, and algorithms. But if your algorithm is still in the developmental stages and you don't happen to attend one of these meetings or talk with the right person, you may be reinventing the wheel.

Today, there is no formal mechanism in place for the exchange of software except for joint projects (e.g., ASCI). The attendees' consensus is that without a formal mechanism, interoperability will be difficult or impossible.

Most instances of interoperability that have been achieved to date have evolved out of interpersonal relationships of the people working on the projects. Only a few minutes of discussion at the workshop generated the following list of examples of this kind of interoperation between DOE sites:

• LBNL asked for and obtained a parallel polygon renderer developed at LANL and ported it to NERSC's T3E.
• Researchers at LBNL and SNL have exchanged AVS modules with researchers at other sites since AVS was introduced as a commercial product. Early in AVS' history, DOE sites exchanged source code with AVS. In some cases, software contributed by DOE sites made its way into the commercial product.
• LANL developed a way to easily integrate IBM's Data Explorer product with Builder Accessory. The Data Explorer team is trying to modify their product to make integration with Builder Accessory an easy service for their customers. LANL also worked closely with the Data Explorer team to suggest modifications to their product to improve usability and performance. Some of these have been integrated into IBM's product.
• LANL is working with Argonne to obtain and modify the CAVE software for the ASCI "Visualization corridor." They have already exchanged the CAVE software and are now working on modifications for LANL's specific needs.
• The Brick of Bytes volume rendering tool (called "BOB") has been used at LLNL, SNL, and LANL recently to do some ASCI visualization work. BOB was developed by Army Research Lab.
• All the DOE labs use the ImageMagick image conversion tool for all sorts of purposes including animation, web page production, and slide/viewgraph preparation. It is a very important tool developed and maintained by SDSC.
• Sandia and Livermore have exchanged the MeshTV visualization tool originally developed at LLNL. Now, a few Sandia scientists are using MeshTV for their ASCI work.
• SNL has shared its EIGEN/VR software with Oak Ridge, where it has been used to develop new application-specific visualizations.
• NCSA's Hierarchical Data Format (HDF) team have used parts of both PDB and Aio (both of which are I/O libraries for self-describing scientific data) to develop their next generation HDF file format called HDF-5. A beta release of HDF-5 was made in February.

HOW DID WE APPROACH THIS WORKSHOP?

The workshop attendees addressed three major topic areas. The first group, "Major Challenges," discussed the fundamental issues in research that are a barrier to or facilitate/require interoperability. The second group, "Software Interoperability," considered the engineering of software and data interoperability. The third group, "Communications," dealt with the non-technical barriers to interoperability and how can we break them down.

Major Challenges in Research

One of the questions that was asked during this workshop was: Are there fundamental issues in research that are a barrier to, or facilitate, or require interoperability? The working group that addressed this question first identified a set of specific research challenges, then considered them in the context of the above question.

RESEARCH CHALLENGES

There are a number of research challenges facing the DOE visualization community in meeting strategic goals. They include (but are not limited to):

• Applications and enhanced scientific analysis. The objective of visualization research is to expand the capabilities of high level scientific applications. Enhanced scientific analysis requires straightforward integration of data exploration components with other application components. Integration mechanisms may take the form of visualization application frameworks and can contribute to runtime application capabilities, such as runtime visualization, computational tracking, and/or computational steering.
• Very large datasets. We need to be able to visualize bigger and bigger datasets in support of increasingly large and complex scientific computations, real world datasets, information databases, etc. We must develop new approaches for handling such datasets which enable efficient and effective comprehension of data by balancing interactivity and display accuracy with preservation of fundamental features. We need new adaptive level-of-detail and multi-resolution techniques for hierarchical representation of data and information. We need new and better discovery and filtering tools. We need efficient access to out-of-core data so that we load and process only the data we need. We need approaches that help expose intricacies in the data at a high level of detail (such as very high resolution displays). We need to provide widespread, effective access to large datasets and large, possibly distributed, collections of data and information to promote further research.
• Scalability. As our computing environments become more parallel and/or distributed, it is important that we develop tools that make efficient use of such resources. We need to push the envelope for visualization of very large data when we have access to very large resources (such as massively parallel machines), but we also need to maximize performance and make optimal use of more modest resources (such as a parallel desktop PC).
• Multiple and diverse data sources. As the number and variety of data and information sources increase, data fusion and registration pose a significant problem. Some applications, for example, need to correlate empirical data with computational data. In order to deal with multiple sources of data, we need to identify new, effective display and presentation techniques.
• Human-computer interfaces. While there have been significant advances in the development of human-computer interfaces, these interfaces still give a sense that the user is interacting with a tool which is interacting with the data. There is much work to be done to enable more transparent access to underlying data by appealing to the various human senses and by continuing to investigate advanced interface techniques that strive for intuitive interaction.
• Non-spatial data and information spaces. We live in the information age. We continue to accumulate vast quantities of data and information which, frankly, we do not entirely know what to do with. A large number of applications are emerging in this area. We need to develop new techniques for organizing, filtering, and representing such data for display.
• Visual metaphors. Whether data are spatial or non-spatial, we must continue to develop new and better visual metaphors that enable more straightforward comprehension and analysis of data.

RESEARCH AND BARRIERS TO INTEROPERABILITY

The circumstances in which research is done often discourage interoperability. When faced with limited research budgets and the pressures of delivering state-of-the-art work at a furious pace, software engineering issues, such as interoperability, inevitably take on a low priority -- unless they are a funded part of the work.

While the research process itself can be a fundamental barrier to interoperability, our goal was to address barriers to interoperability in the context of the specific research challenges we had previously identified. Research aside, we first identified certain technical barriers to interoperability, which are listed below in no specific order.

• Large/complex data. When data sets are relatively small and/or simple, interoperability can be achieved by converting output data from one component into another format for input into other software components. This, however, becomes very difficult when datasets become large -- the memory and performance overhead associated with data conversion quickly becomes unacceptable.
• Performance. Certain applications demand high performance, which can be difficult to achieve in very general environments that offer a high degree of interoperability. If interoperability is achieved by implementing layers of virtual interfaces, the overhead associated with such layers is, in some cases, unacceptable.
• Heterogeneity. We often face a large diversity of computational systems, data sources and formats, users, languages, and programming models. This heterogeneity presents both an incentive for and a hindrance to interoperability.
• Rate of change. Computational technologies (both hardware and software) are continuing to advance at an increasing rate. When a new technology becomes available, there is often increased pressure from users as well as sponsors to exploit the new technology. We are also faced with an exploding change of scale in our computational environments and our problem complexities. Keeping up with this rate of change leaves interoperability low on the priority list.
• Diverse application domains. Inevitably, different applications have differing sets of requirements. As with heterogeneous environments, this diversity presents additional challenges when trying to implement tools for general interoperability. Among these challenges is the need to adapt tools to accommodate the terminology and semantics associated with a particular application domain.
• Fundamental change to the visualization process/system. While it is a challenge to continuously accommodate incremental changes in technology and maintain an interoperable environment, many such changes can still be made by extending the environment in some way. Occasionally, however, we discover a change whose implementation permeates the entire process or system. In such cases, some prior investment towards interoperability is lost and an expensive overhaul is required, whose cost is further increased by any efforts to redesign for interoperability.

In Table 1, we capture some of the relationships between our research challenges and the barriers to interoperability which they expose. The research challenges in the column on the right are positioned across from barriers to which they relate in the column on the left. Many of the research challenges are related to multiple barriers. Not all relationships are shown.

A few thoughts deserve special mention:

• We reiterate the need for high performance and low overhead when dealing with very large data.
• The problem of general interoperability is a difficult one even when we constrain ourselves to single-threaded, sequential software components. The problem becomes significantly more complex when we introduce parallel software components with parallel data interfaces.
• A great deal of work is now under way to develop effective methods for hierarchical data representation (adaptive level of detail, multi-resolution). This is one of those technologies whose exploitation is going to require fundamental changes throughout a visualization process/system.

Table 1: Relationships between barriers to interoperability and research challenges

Barriers		Research Challenges
Large/complex data		Large data & large data collections Better discovery and filters for large data/collections
Performance		Large data & large data collections Human-computer interface research Interaction metaphors
Heterogeneity Data Source Data formats Users Equipment Languages and programming models		Multi-source data and data fusion Human-computer interface research Interaction metaphors Effective representation/display Visual metaphors Parallel software components
Rate of Change Technology (hardware and software) User's expectations Scale Local vs. global change		Parallel software components Scalability Human-computer interface research Interaction metaphors Visual metaphors
Diverse application domains Semantics/terminology		Applications Non-spatial data, information
Fundamental changes to visualization process/systems		Adaptive level of detail, multi-resolution Out-of-core techniques

 

RESEARCH AREAS THAT FACILITATE INTEROPERABILITY

A few research areas would facilitate interoperability. In general, these areas involve the development of general frameworks for visualization and data analysis, and/or the development of special tools, which are designed for multi-use. More specifically, such work might include:

• Investigation of abstract data models and data interfaces.
• Use of component interfaces to integrate computation, data analysis, and visualization, especially in parallel and/or distributed environments.
• Implementation of software components and/or libraries that provide a useful set of functionality in reusable form, available to many applications (e.g., a library of data filtering subroutines, or a set of code modules that convert conventional data arrays into hierarchical data representations, etc.).

Different application domains have differing requirements. For example, one domain may emphasize quantification while another may emphasize qualitative discovery, or certain domains may rely on fundamentally different underlying data types. These differing requirements can result in domain-dependent frameworks and/or tools. It may still be possible to develop general-purpose frameworks and/or tools which provide enough flexibility and breadth of use to enable customized use by relatively broad communities.

RESEARCH AREAS THAT REQUIRE INTEROPERABILITY

There are certain research areas that mandate a certain level of interoperability. While it is possible to encourage interoperability as a design goal of all code development, some situations naturally require minimal levels of interoperability, at least within the closed system that is being implemented. With a modest additional emphasis on generalization, it is possible that applications in these areas could provide foundations that would contribute to farther-reaching interoperability.

Such research and/or application areas include:

• Applications that need multi-source data, such as for comparison of empirical and computational results, or for coupling physics results from runs on different grid types, etc.
• Augmented reality applications, which combine computer-generated images with real-world images (e.g., video) into a unified application environment, such as computer-assisted surgery, aircraft maintenance training, etc.
• Multidisciplinary projects, such as coupling of ocean and climate models, or merging of biological, medical research, and chemical structural information for the genome initiative.
• Collaborative environments, whose internals must somehow enable the interaction of multiple individuals with shared data.
• Any effort to provide canonical access to large data and/or large distributed collections of data, for the sake of encouraging further research.

Software Interoperability

This section presents a broad outline of the software engineering basis for sharing tools within the visualization community. The discussion includes three major topics: data file interoperability, sharing of software modules and code fragments, and remote sharing of visualization resources.

DATA FILE INTEROPERABILITY

A scientist or engineer who wants to use visualization tools often spends a great deal of time converting data from one format to another because of the wide variety of file formats and data models in use today.

Imagine being able to use a variety of visualization tools from different vendors and sources on a data file without having to perform any format conversion. In this scenario, the user benefits from access to new categories of tools, codes, and applications, as well as new functionality and high performance. Tool developers also benefit from the wider applicability and more widespread use of their tools.

The ASCI-funded Data Models and Formats (DMF) project is an effort to create this kind of data file interoperability. DMF is developing a common abstract data model and format that is portable across architectures, applications, tools, and scientific disciplines. The result of the DMF committee's work is the Vector Bundle Application Programming Interface (VB-API), based on the mathematical foundation of vector bundles. VB-API is designed to be general enough to support the gamut of scientific data model requirements, without the limitations of netCDF (Network Common Data Form), HDF (Hierarchical Data Format), and other data formats.

Prototype testing of a non-parallel VB-API has been ongoing since October 1997. A new parallel version will be released in May 1998. Two parallel ASCI applications will be tested with VB-API by the end of this month (April 1998), one at Sandia and one at Livermore. Summer 1998 will bring two further tests: exchange of vector bundle data between Livermore and Sandia physics codes without format conversion, and exchange of visualization tools, such as MeshTV, between applications that use VB-API. If these tests are successful, the DMF group will encourage the ASCI partners to adopt VB-API as widely as possible.

Non-ASCI partners, such as Ensight (a commercial visualization package) and DX (IBM's Visualization Data Explorer) could begin porting to VB-API in September 1998. The IBM Data Explorer team has already participated in several ASCI DMF meetings and has expressed a desire to collaborate in the DMF work. Other organizations expressing interest in VB-API include NCSA (because of HDF), the French Atomic Energy Commission (CEA), the British Atomic Weapons Establishment (AWE), the University of Illinois Pablo Research Group, and representatives of the petroleum industry. DOD and DOE researchers outside of ASCI will be encouraged to adopt VB-API.

Once the VB-API model has been validated within the ASCI community, it should be adopted at the grassroots level within the ER visualization community. The ER community should become involved with the ASCI DMF effort in order to communicate their technical needs and to keep up with progress in the testing of VB-API. During the transition to support the VB-API format, we recommend that many sample data files be made available to facilitate testing of applications and visualization tools. The best source for specifications for sample data files will be the DMF committee. Vendors should be lobbied to extend commercial products to support the VB-API model.

VB-API is not yet a proven technology. If it is successful, it will be a boon to the DOE research community. But there are potential risks. If performance is sluggish, researchers may have to generate two types of data -- interoperable and non-interoperable data. Poor performance would hinder widespread acceptance.

Even if VB-API performs well, its success as an interoperability tool will depend on a large-scale buy-in among the research community, which will require a significant marketing effort. To use VB-API, existing ER codes and applications will need to be extended to read and write the VB-API format. The cost of developing readers and writers will vary on a case-by-case basis. For example, the estimated cost of adding a VB-API reader to MeshTV (an interactive graphical analysis tool for visualizing and analyzing data on two- and three-dimensional meshes) is about one person-month, with an additional one-time cost of one person-month to learn the vector bundle model. Programmers will feel some resistance to spending so much time learning an unfamiliar abstract data model. And when users are able to experiment and evaluate new tools that were previously unavailable due to incompatible data formats, software developers may feel threatened by the new competition. In short, there will be many excuses for not adopting VB-API. The research community will have to be convinced of its benefits before they will buy in.

CODE SHARING

From a historical perspective, code sharing has been successful when some specific guidelines have been followed. Netlib, the repository of mathematical software at Oak Ridge and the University of Tennessee, has been very successful. The code, which is available at Netlib, consists primarily of subroutines with well-defined and documented interfaces. These subroutines are ready to be dropped into an application to solve some particular numerical problem. Another success story, at least for a period of time, was the International AVS Center (IAC), formerly in the Research Triangle Park but now at the University of Leeds in the UK. The IAC maintains a source code repository of modules for the AVS (Application Visualization System) framework. The modules can be compiled and then plugged into an AVS dataflow network. Data-typing issues are addressed by the data flow executive itself.

These two examples illustrate two types of code sharing: modules to be run within an established framework, and code fragments. One distinction between these two models is that a certain amount of development effort is required to integrate code fragments into a visualization tool or application. The application developer must usually write software that converts data from the application's format into a format suitable for the imported code. On the other hand, modules by definition have strongly typed data interfaces, so little, if any, software must be written to run an imported module within an established framework -- it should just drop into the data flow network and execute.

Sharing Modules within Established Frameworks

For modules that run within an established framework such as AVS, Khoros, Data Explorer, vtk (Visualization Toolkit), etc., low-level technical interoperability is a given. Typically, these tools do not need modification to perform adequately on serial machines with data of modest size. These are general-purpose tools that work well for a wide class of problems.

Among the established frameworks, there are a number of both commercially supported systems and freeware systems. The freeware systems are available over the Web and in source code form.

Commercially supported frameworks should have a long lifetime, since that is in the vendor's best interest, and generally provide good documentation and support. These frameworks have a large user base and a large knowledge base, so there is a high potential for exchanging tools.

What is needed to make that potential a reality is an effective distribution medium. To encourage use of visualization tool modules, we recommend that MICS sponsor a central visualization code and information repository similar to the DOE2000 ACTS Toolkit.

Sharing Code Fragments

Tools consisting of code fragments written for a specific architecture or a specific task serve valuable purposes in the visualization community. For example, commercial and off-the-shelf tools are not capable of processing today's increasing data sizes and often are not available for specialized high performance computing (HPC) architectures. Code fragment tools can bring new and previously unattainable computing and visualization capacity to users of specialized systems. Having source code for tools also facilitates debugging and quick enhancements. Often the user of a code fragment has a collegial relationship with the tool author and can expect a certain amount of informal support if needed.

Due to the variety of HPC architectures (e.g., vector, symmetric multiprocessing, distributed memory), different memory access strategies are required to achieve adequate performance. In scientific visualization, fast performance is crucial to human understanding because it allows interactivity, which improves the scientist's ability to manipulate, analyze, and understand data.

Despite the heterogeneity of code structure and methods in code fragment tools, a simple and direct software design and engineering philosophy could promote interoperability. Specifically, designing new software to read and write to the VB-API format would improve portability and save time for software integrators, who would no longer have to write data conversion software for each new imported tool. As time permits, existing code fragment tools should also be converted to use the VB-API model. But before this can happen, a significant technical development is needed -- the ability of VB-API to handle both in-core and out-of-core data. The present implementations of VB-API only support out-of-core data.

REMOTE SHARING OF VISUALIZATION RESOURCES

As the various computing centers have evolved, each center has tended to focus on a particular specialty. For example, one of the first teraflops machines is on line at Sandia Albuquerque, and specialized virtual reality facilities are available at Berkeley and Argonne. As time goes on, this trend will continue, and these "pockets of capability" will continue to grow in number and in capacity.

To maximize the value and use of these resources, our long-term vision is to establish a framework whereby a user located anywhere in cyberspace can make use of visualization hardware and software resources at any of these facilities, either singly or in combination. For example, imagine being able to use a teraflops machine to compute isosurfaces from a very large data set, then using a visualization server to create images of the isosurface, then having the images delivered to the desktop.

A research effort is needed to address the numerous technical challenges to achieving such a goal. Technical issues include scheduling and resource allocation, as well as incompatibility between vendor implementations of the CORBA (Common Object Request Broker Architecture) standard for distributed objects.

Shared resources would benefit many scientific programs by making visualization available to researchers who do not have a strong on-site visualization program, and by making the full range of visualization solutions to data interpretation problems available everywhere.

Communications

Interpersonal communications are fundamental to the effective dissemination of information within any technical society, including the DOE visualization community. For example, during the first ten minutes of the communications working group breakout session, two potential collaborations were discussed that would probably not have occurred without this session.

An effective communication structure to facilitate interoperability between DOE visualization centers would include four elements:

• a visualization facilitator to serve as a single point of contact and an intelligent information filter
• electronic mail lists, both moderated and unmoderated
• a central Web site
• official guidance from DOE HQ to laboratory legal and technology transfer offices to reduce the barriers to efficient communication between laboratory participants.

 

VISUALIZATION FACILITATOR

The visualization facilitator would be a central point of contact for the visualization community -- a gatherer, solicitor, and disseminator of useful information that is not readily available to the visualization community from a single source. The facilitator would also bring together members of the visualization community who have common interests or a possible symbiosis but who are unaware of each other's interests and resources.

The visualization facilitator would be an experienced and respected member of the visualization community who would represent the entire community rather than a particular lab or program. The facilitator would not be a policy shaper. To maintain close contact with the scientific and visualization communities, we recommend that the visualization facilitator be stationed at one of the DOE laboratories rather than in Washington, D.C.

The duties of the visualization facilitator would be:

• Develop, maintain, and disseminate a list of contacts at the various visualization sites. The number of contacts for a given site will depend on the scope of the visualization efforts at that site. A logical starting point for such a list would be the email list and site reports maintained by the DOECGF.
• Create and maintain both moderated and unmoderated email distribution groups for the visualization community. Moderating the moderated email group would guarantee a baseline level of communication between the facilitator and the visualization community.
• Create and maintain a visualization community Web site as a central repository for information, references, and links. The facilitator would be responsible for the scope, accuracy, and currency of the information on the Web site.
• Write a monthly email news report summarizing new and interesting visualization projects at the various sites, as well as the availability of new software, new concepts and applications, and new Web site entries.
• Organize and schedule meetings to promote opportunities for interoperability within the visualization community. Small meetings might be appropriate to promote a small-scale form of interoperability such as sharing an algorithm, while larger meetings might discuss broader opportunities. Such meetings would make use of a wide range of communications resources such as videoconferencing, teleconferencing, Internet conferencing (via Mbone or Voyager project), as well as traditional in-person meetings.
• Attend established visualization community meetings such as DOECGF and conferences such as IEEE Visualization, SCXY, and SIGGRAPH, using interest group sessions at these venues to promote interoperability within the DOE community.

Accomplishing these tasks will require substantial interaction between the facilitator and the visualization community across the country. Much of this contact can be done electronically, but significant travel to visualization sites and meetings will also be required, so an appropriate travel budget will be required. The facilitator should have United States citizenship to avoid security-related accessibility issues.

A successful facilitator would have the following capabilities:

• Solid background in scientific visualization. At least 5 years of visualization experience at a DOE laboratory or similar facility is crucial to the task of gathering and disseminating the type of information noted above. The facilitator must understand the work being done by the visualization community and be able to recognize interoperability opportunities involving software, concepts, programs, and people.
• Effective interpersonal skills. The facilitator will spend significant time dealing with people, both as a solicitor of information and as a "matchmaker" bringing people together to encourage interoperability.
• Effective technical writing and editing skills. Writing effective monthly news reports and Web pages will require clarity, brevity, and completeness, since members of the visualization community are already approaching information and work overload.

To assess the usefulness of the visualization facilitator's efforts, success metrics could include:

• quality and timeliness of web site contents
• quality and relevance of monthly news reports
• attempts at interoperability by the visualization community, including both successes and failures (since increased communication is always valuable).

EMAIL

The existing DOECGF mail list, doecgf@inel.gov, could be leveraged to promote interoperability. We recommend the following email activities:

1. Q&A. Any question related to DOE visualization activities could be posted on the unmoderated mail list. The traffic on this list would be monitored, but not moderated, by the visualization facilitator so that important communication threads could be passed on to the group as a whole and inappropriate uses of the list could be eliminated.
2. Unmoderated visualization news. Visualization activities, conferences, and accomplishments worldwide could be posted to the unmoderated list. The facilitator would include relevant news items from this source in the moderated mailings.
3. Moderated visualization news. The facilitator would establish and maintain a moderated electronic mail list and regularly (monthly) compile and send a summary of information of interest to the entire community, including references to additional information.
4. Archives. Searchable archives would be established and maintained for both the moderated and unmoderated email lists.

The first two items can be implemented immediately without additional funding as a simple expansion of the existing DOECGF email reflector. However, without a facilitator, the effectiveness of these activities would be somewhat limited, since there is currently little incentive to provide information to the list. A facilitator could generate enthusiasm for the first two activities and take on the additional workload required by the other two.

WEB SITE

The visualization community uses the World Wide Web daily to examine status information, identify contacts, locate software, and ask questions within each site's "intranet," or local electronic community. We don't realize the same level of value from the broader federal visualization community's Web sites. The reasons for this include uncertainty about the electronic location, timeliness, and accuracy of data. A source of comprehensive and reliable information would spur the development and use of interoperable visualization software tools.

We propose the creation of a federal visualization web site for visualization tool and application developers as well as managers and users of visualization programs. The contents of the site would include:

• an up-to-date list of participants, their affiliations, contact information, projects, and interests
• a visualization-oriented Frequently Asked Questions (FAQ) list
• URL pointers to visualization software, organizations, and upcoming conferences/workshops/forums
• site-specific progress reports from individuals and groups
• documentation of successes in visualization interoperability
• regular updates based on comments and suggestions from the visualization community.

The software pointers would include software in various stages of development in order to provide advance access to software for inspection, testing, and suggestions that may improve interoperability.

A baseline Web site for federal visualization already exists and is recommended as a starting point -- www.persephone.inel.gov/DOEGCF -- which was established in 1992 by participants in the annual DOE Computer Graphics Forum. The value of this site includes its contact list, which has been maintained sporadically, and its links to software of relevance and interest over the past several years. Its use has been moderate to low for several reasons:

• lack of an interoperability imperative within the DOE community
• issues related to release of information and software technology
• insufficient funding to allow a focus beyond immediate technical issues.

One of the principal roles of the visualization facilitator would be to promote and maintain this web site with current, relevant information. Ongoing activities would include:

• advertise the existence of the site to the visualization community
• document visualization results culled from various media (Web, publications, etc.)
• administer a moderated Q/A archive
• review and summarize site reports
• update the contact list, conference list, and URLs
• organize information by various criteria (activity, interest, site, time)
• document meetings and discussions with visualization staff and federal officials.

INTELLECTUAL PROPERTY

A potential barrier to the effective exchange of information, whether it is paradigms, algorithms, or software, is the unnecessary encumbrance of licensing issues. Code sharing for research must become an established practice, while protecting the rights to license of the authors. A standard software license should be actively developed, based on models such as the GNU or VTK licenses, and instructions for its use should be given to the labs and the site offices.

Recommendations

Workshop participants had four recommendations for improving visualization interoperability, which are rank ordered. Additionally, many attendees expressed interest in having another meeting in six months to a year to assess the progress and results. This meeting might be coordinated with the 1999 meeting of the Computer Graphics Forum.

1. Observers to DMF

We recommend that several non-ASCI DOE sites participate in the next ASCI Data Model and Formats meeting, to be held May 7-8, 1998. (As a result of this workshop, one representative from each of ANL, BNL, INEL, LBNL/NERSC, ORNL, and PNNL has been invited to this meeting.)

2. Common abstract data model

A common abstract data model is fundamental to interoperability. Once VB-API is proven, we recommend that the national laboratories incorporate it into their visualization codes. To accelerate the adoption of this technology and demonstrate its usefulness to the scientific community, we recommend that DOE fund the following:

• at least two test trials during the fourth quarter of FY98
• seminars or other presentations on VB-API at labs and conferences
• extension of the most commonly used existing visualization codes to read and write VB-API.

3. Facilitator

We recommend that DOE fund a senior visualization expert to be the full-time Visualization Facilitator to actively promote interoperability.

4. Interoperability research

We recommend that the DOE fund some visualization research efforts that promote interoperability by encouraging proposals that focus explicitly on interoperability or that emphasize interoperability in support of other research goals. Research focused explicitly on interoperability might include:

• Visualization application frameworks
• Visualization data models
• Multi-use visualization software components/tools.

Research that addresses certain aspects of interoperability as part of a larger effort might involve:

• Integration of computation and data analysis (including visualization) in specific application environments, which is to be accomplished by investigating one or more methods that enable the general integration of separate components/tools
• Visualization of multi-source data
• Visualization of multi-disciplinary data
• Collaborative environments
• The construction of large-data/large-data-collection repositories together with tools/interfaces for effective, universal access.

---

Appendix A

Workshop on Interoperability of DOE Visualization Centers
Attendees

The following attendees contributed to this report:

DOE National Labs and Related Research Facilities:

Argonne National Laboratory

Terry Disz

Mike Papka

Brookhaven National Laboratory

Arnie Peskin

Gordon Smith

Idaho National Engineering and Environmental Laboratory

Eric Greenwade

Lawrence Berkeley National Lab

Wes Bethel

Nancy Johnston

Lawrence Livermore National Lab

Mark C. Miller

Dan Schikore

James Reus

Los Alamos National Laboratory

Jim Ahrens

James Painter

NASA-Ames

Sam Uselton

Oak Ridge National Laboratory

Nancy Grady

James Arthur Kohl

Ross Toedte

Pacific Northwest National Lab

Don Jones

Sandia National Laboratories

Jeff Jortner - Livermore

Constantine Pavlakos

Stanford Linear Accelerator Center

Joseph Perl

National Center for Supercomputing Applications

Polly Baker

ACTS Toolkit

Jim Mcgraw, Lawrence Livermore National Laboratory

Academia

Bill Ribarsky, Georgia Tech

Technical Editor

John Hules, Lawrence Berkeley National Laboratory

Web problem or question? Send email to viswebmaster at lbl dot gov. Privacy and Security Notice, Page Owner
This page last modified Tuesday, 05-Jun-2018 10:42:27 PDT