# Presentation: 733339

**Prototyping a Combustion Corridor**
**Bob Lucas**
**HIGH PERFORMANCE COMPUTING RESEARCH DEPARTMENT**
**NATIONAL ENERGY RESEARCH SCIENTIFIC COMPUTING CENTER**
**LAWRENCE BERKELEY NATIONAL LABORATORY**
**rflucas@lbl.gov**
**510-495-2431**

**Notes:**
1974	Founded at Lawrence Livermore Laboratory as the Controlled Thermonuclear Research Computer Center late 1970s	Began operating system development, name changed to Magnetic Fusion Energy Computer Center (MFECC)
1980s	Developed the Cray Time Sharing System (CTSS) for Cray 1, S-MP, Y-MP and Cray 2
1980s	Established MFEnet, including satellite uplinks
1985-90	Transition from MFEnet to Energy Science Network (ESnet)
1988	DOE broadened mission of the Center, name changed to National Energy Research Supercomputer Center (NERSC)
1990	Energy Science Network (ESnet) began T1 service
1991	Switch to vendor supplied operating systems
1995-96	DOE recompeted the NERSC Program, Lawrence Berkeley National Laboratory has been chosen as the new site		Grand Reopenning at LBNL Oct 22, 1996

## Combustion Corridor PIs

**ANL**
**Paul Fischer, Ian Foster, and Rick Stevens**
**LBNL**
**John Bell, Bill Johnston, Nancy Johnston, Bob Lucas, and Brian Tierney**
**SNL-CA**
**Helen Chen, Robert Clay and Joe Grcar**
**University of Wisconsin, Madison**
**Chris Rutland**

## Outline

**Applications, Network Technology, and **
**Network Testbed Partnership **
**(DOE LAB 99-09)**
**Combustion Application**
**Network Technology**
**Network Testbed**

## What’s a Corridor?

**The Data and Visualization Corridor is a concept inspired by ASCI researchers and their colleagues**
**ASCI VIEWS PM is John van Rosendale**
**Goal is to provide scientists with unimpeded access (including visualization) to large data sets over geographic distances**
**Broad corridor as opposed to thin straw**

## Prototyping a Corridor for an Existing Collaboratoin

**Argonne National Laboratory**
**Tom Canfield **
**Paul Fischer**
**Lawrence Berkeley National Laboratory****	**
**John Bell**
**Phil Colella**
**Sandia National Laboratory, California**
**Joe Grcar**
**University of Wisconsin**
**Chris Rutland****	**

## Why Combustion?

**Combustion is:**
**Source of 85% of energy consumed in US**
**Source of 98% of CO2 emmitted in US**
**Combustion Modeling and Simulation Initiative (CMSI)**
**DOE Strategic Simulation Initiative (SSI) signature application, together with modeling global systems**
**Combustion scientists are planning large scale computations of reacting flows in three dimensions with complex chemistry**
**Three-dimensional, time-dependent fluid dynamics**
**Kinetics mechanisms with as many as several hundred chemical species**

## Static Combustion Images

** **

## Animation of CFD Data

## There’s Lots of Data

**Combination of three-dimensional fluid dynamics and complex kinetics means the data sets we need to manage are very large.**
**Current codes generate 100 MB/s of data on NERSC T3E**
**The next generation supercomputers will enable combustion computations to easily generate Petabytes of data**
**These codes will only run on a handful of large National assets (E.g., NERSC)**

## Adaptive Mesh Refinement

**Data is irregular, not given on a simple lattice**
**Data is inherently hierarchical**

## AMRVIS Screen Shot

## AMRVIS Volume Rendered Data

## The Alternative?

## Volume Rendering

**“****True” 3D presentation of 3D data**
**Blending of user-defined color and opacity**
**Reveals subtle details/structure in data that could be lost in isosurface rendering**

## Distributing Volume Rendering

***Two approaches:***
**Render at user’s location**
**Gain: interactivity**
**Cost: can’t afford big enough local system to hold the data much less do true volume rendering**
**Multiple distributed collaborative users**
**Render at data source **
**Gain: avoid large data transfer to desktop**
**Cost: loss of interactivity**

## Our Solution: Image-Based Rendering Assisted Volume Rendering (IBRAVR)

**1. Subvolumes are composited together on remote host**
**2. Resulting images are sent to rendering engine**
**3. Use of 2D texture mapping hardware to achieve interactivity (limited rotation/motion parallax)**
**    ****Can adapt to changes in underlying network bandwidth**

- 1.

- 2.

- 3.

## Bandwidth Required

**Texture plane of 1000 x 1000 pixels**
**32-bits per pixel**
**Eight textures**
**Four updates per second**
**Bottom line: 1 Gb/s sustained B/W**
**Could be less:**
**Reduce resolution, update rate, textures transfered**
**Compression**
**Could be more:**
**Six-wall CAVES?**

## Network Technology

**Visualization protocols and tools**
**Corridor One**
**Advanced Visualization Toolkit**
**High bandwidth distribution of data**
**China Clipper**
**Resource management**
**Globus**
**Wide-area data management**
**budget was cut :-(**
**Access control**
**Akenti**
**Stream Management for Collaborative Applications**

## Advanced Visualiztion Toolkit

**An NGI Research in Basic Technologies effort**
**Enables network-adaptive visualization applications**
**Will provide interfaces to existing network status and monitoring software**
**Provides mechanisms for prioritizing different data streams (I.e., video, audio, etc.)**

## High Bandwidth Data Distribution

- Achieved 35 MBytes/sec. of user data
- delivered to the STAF application

## Other Enabling Services

**Grid Storage API**
**New Globus component**
**Joint work involving ANL, LBNL, USC/ISI and SDSC**
**Single API for file and block level access to NFS, HPSS, DPSS, FTP, HTTP, eventually other storage systems as well**
**Design for high-speed transfers**
**Directory services**
**Build on LDAP, integrate SRB functionality**
**Integration of replica management**
**Resource Reservation System**
**Globus Architecture for Reservation and Allocation (GARA)**
**Reserve networks, disk caches, computers, etc.**
**Grid Security Infrastructure**
**Authentication and authorization in all of the above**

** **

**Web**
**Server**

**Database**
**Server**

**LDAP**

**Certificate Servers**

**Akenti**

**Identity (X509)**
**certificate on behalf**
**of the user.**

**Internet**

**File**
**Servers**

**Fetch **
**Certificate**

**Cache**
**Manager**

**Log**
**Server**

**Use condition or attribute**
**certificates**

**Identity certificates**

- DN

**Akenti Access Control**

**Client**

**DN**

- DN

- DN

**Resource**
**Server**

## Stream Management

**Image-Based Rendering Assisted Volume Rendering**
**High B/W critical**
**Control channel to manipulate images**
**Low latency and reliability are critical**
**Video from multiple collaborators**
**Audio from multiple collaborators**
**Synchronization of the above with dozens of streams with different, time varying requirements for B/W and QoS (security, reliability, multicast, etc.)**

## Monitoring Architecture

## Part of a Broader Collaboration

**DARPA Supernet**
**Related DOE NGI Applications Efforts**
**Corridor One**
**Earth Systems Grid**
**Particle Physics Data Grid**
**Related DOE NGI Network Research Efforts**
**Advanced Visualization Toolkit (LBNL)**
**ENABLE (LBNL/Kansas)**
**Secure and Reliable Group Communications (LBNL)**
**Diplomat: Policy Mechanisms for Grids (ANL/ISI/UW)**
**Uniform Instrumentation Project (ANL/UIUC)**
**Wide Area MPI (ANL/NIU)**
**Related Network Testbeds**
**ESnet (China Clipper)**
**MREN (EMERGE)**
**NTON**

## Collaborators

**Collaborators**

**SNL-CA**

**FNAL**

**SLAC**

**J-Lab**

**USC/ISI**

**NCAR**

**UTAH**

**Wisconsin**

**BNL**

**UIUC**

**SDSC**

**Princeton**

**LLNL**

**Caltech**

**ANL**

**LANL**

**Indiana**

## Unifying Concept:An Integrated Grid Architecture

- Archives, networks, computers, display devices, etc.;
- associated local services

- Protocols, authentication, policy, resource
- management, instrumentation, discovery, etc., etc.

- Grid
- Fabric

- Grid
- Services

- Appln
- Toolkits

- Applns

**...**

- ... a rich variety of applications ...

- Remote
- viz
- toolkit

- Remote
- comp.
- toolkit

- Remote
- data
- toolkit

- Remote
- sensors
- toolkit

- Async.
- collab.
- toolkit

## Combustion Corridor Testbed

**Combustion Corridor Testbed**

## Network Testbed Issues

**Testbeds need to extend into local areas**
**LAN B/W**
**LAN QoS**
**Money**
**Didn’t budget for testbeds at Wisconsin or SNL-CA**
**Assuming MREN connects Wisconsin**
**Assuming ESnet connects SNL-CA**
**Assuming Esnet maintains China Clipper testbed**
**Quality of service**
**What rates?**
**Multiple domains?**

## Summary

**We will develop the first large, distributed IBRAVR application allowing multiple remote combustion researchers to interact with volume rendered data.**
**We will develop and integrate advanced networking technology and services to facilitate it.**
**We will deploy this over three network testbeds**
**ESnet, MREN, and NTON**