Visapult Milestones

Project Plans & Milestones

Completed Milestones

November 16, 2000
Source code release, including all changes/modifications needed to win the Application Bandwidth Challenge at SC00.
November 5-10, 2000
Winner! of the SC00 Application Bandwidth Challenge with the "Fastest and Fattest" application.
August 30, 2000
Rearranged and updated the Visapult technical overview page. In particular, added a section that describes the architecture of the soon-to-come OmniAxis view capability. (Note: thanks to Peter Reeves of UCSF for suggesting this term.)
August 23, 2000
August 23 source code release includes support for direct reading of UCSF confocal microscopy volume data.
August 14-16, 2000
Bethel and Jason Lee (LBL) give a Visapult presentation and demonstration at the Gigabit Networking Workshop sponsored by the Nasa Research and Education Network Group at NASA Ames.
August 9, 2000
Source code release. Check the Visapult source download page for more details.
July 28, 2000
Final version of SC00 paper submitted.
July 24-28, 2000
Bethel gives Visapult presentation at Siggraph 2000.
July 18-21, 2000
A collaborative project based upon Visapult and CIBRview is being demonstrated at iGrid2000. Jason Leigh and Mark Lewis of the Electronic Visualization Laboratory at the University of Illinois at Chicago are the collaborators and presenters.
June 23, 2000
Preliminary version of code (very, very early) working that changes volume data access order as a function of the primary view axis. Currently, only the AVS reader has been modified and updated. The geometry used for the texture mapping has not yet been changed to reorient the quads/quadmeshes to the new axis - that's next.
June 9, 2000
Source code release containing new beefed-up backEnd that supports overlapped I/O and rendering.
June 6, 2000
Preliminary addition of overlapped i/o and rendering in the back end. Please see this page for more information.
May 26, 2000
Movies! Two animations/movies were created from a 40GB source data file, representing the density species over 265 timesteps. Refer to the Visapult art page.
A side benefit of this process was a tool for performing MP read tests on a new JBOD filesystem connected to a large SGI visualization server.
May 16, 2000
1. Source code release
  Includes support for file-based, large data. Check the May 16 release notes for more details.
  Sample data tarball (111233307 bytes)
  A file-based version of the DPSS data. Check here for more information.
May 8-10, 2000
Partial porting of Visapult viewer to the ActiveMural at ANL. Showed images of combustion data resident on the DPSS at LBL on tiled surface displays at ANL. The IBR engine (visapult back end) was running on a large SMP at ANL. Showed full time-varying data on one wall of the CAVE at ANL.

Brief Visapult presentation to Globus group at ANL. Identified two potential areas where Visapult and Globus overlap:
1. "Globus socket layer." Globus has a drop-in replacement for custom TCP socket code that will provide a secure, point-to-point communication channel.
2. "Gram." Gram is a framework for scheduling and launching distributed jobs. One of the difficulties with using Visapult is that users must launch two separate jobs on potentially different machines, and in the right order. This framework appears to hold promise in nicely packaging the base Visapult technology for field deployment and use.
April 28, 2000
Visapult paper submitted to SC00. PDF Source, LBNL-45365, 113356 bytes.

April 27, 2000
Engineering Advisory Committee Review, LLNL Presented Visapult to the EAC at LLNL as an example application that makes exceptional demands upon the network. This group evaluates the effectiveness of engineering programs, such as NTON.

During the course of preparing for this demonstration, the NTON link between LBL and LLNL/SNL went down and did not come back up. Therefore, it was necessary to move data from the DPSS to disks local to the CPlant. We created a new reader for Visapult that will read directly from disk files using the same format as the DPSS.

April 21, 2000
Contacted and met with a staff member from UCSF that is interested in deploying Visapult in a research clinical setting for use in viewing data obtained using confocal microscopy.
April 12, 2000
First Light Campaign - demonstrated remote visualization of time-varying combustion data. We used the LBL DPSS for data storage of a medium-sized data set (goal: 100Gbytes), the CPlant at SNL-CA for parallel rendering, NTON for data transport between LBL and SNL, and ran the Visapult viewer on a researcher's desktop machine at SNL. Please visit this page for more detailed information.
- Sample Data on DPSS
  We created a sample dataset, derived directly from AMR data, which was then stored on the LBL DPSS. The sample dataset consisted of a grid of size 640x256x256 over 265 time steps. We stored only one species, density, as IEEE big-endian floats, for a total size of 42.4 Gbytes. Each time step was 160Mbytes.
  
  In order to generate this data, we ran a standalone program on an SGI Onyx2 (serial program) that first read one time step's worth of AMR data, flattened the data, then wrote the data to the DPSS. Due to several as-yet unresolved problems, we were unable to create more than 4G worth of data on the DPSS at one run before trouble set in. In response, we created several, smaller datasets which in total (if concatenated together) would represent the entire data set. The DPSS group is looking in to these issues at this time.
- Test DPSS-enabled Visapult on CPLANT
  We have already run several tests using DPSS-enabled Visapult on LBL machines. These tests show that Visapult can read and render time varying data from the LBL DPSS, with the backEnd running on one of several LBL machines, and the viewer running in arbitrary locations.
  
  Prior to the 12th, we tested the Visapult back end on CPlant reading from the DPSS over NTON, but with a viewer running at LBL.
  Profiling/Instrumentation of Visapult on CPLANT
  Visapult was fully instrumented with NetLogger, and the results are posted on the campaigns page.
27 March 2000
- Compiling Visapult Viewer with CC
  Mike Lewis at EVL reported difficulties compiling Visapult with CC under IRIX. The source of these problems stems from missing #ifdef __cplusplus directives from some of the Visapult source header files. These problems were fixed, resulting in fresh Visapult and Libcvdev source releases in 24 March 2000, then again on 27 March 2000.
20 March 2000
- CPLANT Port
  Visapult was ported and tested on the CPLANT at SNL-CA. Our test consisted of running the Visapult backend on the CPLANT, using sample data files that were resident on the CPLANT filesystem.
17 March 2000
- DPSS Resurrection
  During the past two weeks, the DPSS portion of the Visapult backend has been undergoing a redesign and reimplementation. Among the changes, which will be documented concurrent with a source code release, we are now using a "config" file which resides on the DPSS itself. The config file contains metadata concerning the large payload scientific data. Again, more details will be forthcoming with the source code release.
- Prototype combustion data on the DPSS
  A sample program was written using the CCSE Boxlib/AMR library and the DPSS libraries, which creates flattened versions of the adaptive data, and stores it on the DPSS. We ran two tests, both of which store time varying combustion datasets on the DPSS. One data set was small (~30 Mbytes for five time steps), the other data set was medium-sized (~30 Gbytes for twelve or so time steps). Creation of the second data set failed due to what appears to be an unrelated crash of the DPSS. Prior to this crash, we created a two-time-step version of this larger data file.
- Time Varying Visualization with Visapult & DPSS Data
  We tested the new DPSS-enabled Visapult with both the small and the two-time-step version of the larger file. Both tests went well, but did point out the bandwidth limitations between the DPSS and the computational engine. This link will require careful analysis and tuning in the future.
7 March 2000
- Image resizing implemented in Visapult.
  The problem is that OpenGL textures must be an even power of two in size. It is rare that source data will be an exact power of two in size, so somewhere in the visualization process, images must be scaled to accommodate OpenGL texture size restrictions.
  
  What we did was to grab the source code for the OpenGL routine gluScaleImage() from the Mesa-3.1 distribution, and pare it down to remove all OpenGL-ism's (scanline padding, pixel unpack alignment, etc) and wedge the resulting subroutine into the back-end side. Now, volume data is rendered at it's native resolution, then the resulting image is scaled prior to transmission. This approach allows for parallel image resizing, as well as preserving the fidelity of volume rendering (we resize the final image, rather than the data).
  
  The 7 March 2000 Visapult source code release has the new image resize code, as well as a viewer-side bug fix (revealed when stressing the grid visualization). See the Visapult download page for more information.
- Siggraph 2000 Submission.
  This short application sketch was submitted to Siggraph 2000 to the Applications & Sketches track (LBNL-45215).
3 March 2000
- Visapult source code updated to use OpenRM v1.2.0. The new Visapult source may be obtained from the visapult download page, and OpenRM is available from the OpenRM project website.
Feb 18, 2000
- Rebuilt the AMR-aware back-end to make it compatible with the new Visapult communication protocol and parallel computing model. We have a functioning version of the AMR backend working, but it won't win any awards for code-prettiness.
- Instrumented the new AMR-aware back-end, post results on Visapult/ Netlogger campaign page. Check out the new Visapult campaign pages.
- Rebuild the "caveViewer" part of Visapult to make it conformant with new protocol. Actually, we did one better than that, and integrated caveViewer back into the main viewer code. To build the CAVE-enabled viewer (the trackd-aware viewer, to be more precise), use the "caveViewer" make target.
- Source code release for the new Visapult code. Check out the download page.
- Updated this website to reflect name change from IBRAVR to Visapult. We're still short one Visapult logo, but that's on it's way.
11 Feb, 2000
We now have a "real name" for this application: Visapult. The entire website will be updated in the near future to reflect this change. We got tired of people stumbling over the IBRABR acronym.
- Netlogger instrumentation of new Visapult completed.
  We instrumented the new version of Visapult with Netlogger, and have posted the results on this page.
- Visapult design changes summary.
  Please visit this page for more information on the new, improved Visapult design.
9 Feb, 2000
An article titled Visualization Dot Com (LBNL-44871) was accepted for publication in the May/June 2000 issue of IEEE Computer Graphics and Applications. The article provides details about our prototype implementation of a shared/distributed/parallel visualization and rendering framework, the relationship between our approach and more traditional methods of remote and parallel visualization and rendering, and identifies shared and distributed visualization and rendering as a promising field for future research.
4 Feb, 2000
- Feb 4 IBRAVR Release
  Fixed minor problems pertaining to Netlogger & DPSS configuration and Makefiles.
  Fresh sample data in AVS format. (removed pending approval by J.Bell)
  
  IBRAVR infrastructure redesign complete. Implementation is currently underway. When the implementation is complete, fresh documentation and sources will be posted.
  Redesign goals:
  Makes more efficient use of network resources (no burbles).
  Facilitates future growth.
  More reasonably separates the visualization algorithm from the underlying communication infrastructure.
  
  To accomplish these goals, we did the following:
  
  Rewrite IBRAVR infrastructure to move "total domain" information outside the per-frame loop (removes a class of upstream traffic). Feb 4, 2000
  Rewrite IBRAVR communications infrastructure to use a balance of "encapsulated data objects" (pseudo-self-describing object info) along with "conversation recipes" that are defined by the types of visualization requested. Feb 4, 2000
  Backend compositing engine will be pipelined-parallel, so that some processors are reading the data for the next frame while other processors are rendering data for the current frame.
  
  This paper was accepted for publication in the May/June 2000 IEEE Computer Graphics and Applications in the "Visualization Viewpoints" column.
Jan 21, 2000
1. Preliminary grid vis added to the viewer.
2. Added preliminary support for automatic negotiation of TCP window size setting between viewer and back end. As a result of this effort, new versions of Slam! and the IBRAVR source were generated. Please visit the appropriate download pages for more info.
Jan 12, 2000
DavidR completed the documentation describing the instrumentation of the IBRAVR package with Netlogger, a profiling tool suitable for use with distributed computing tools.
Jan 7, 2000
1. Added support for instrumenting network bandwidth consumption to the viewer. A viewer command-line option can be used to generate bandwidth consumption reporting.
2. Release of Slam!, a simple network instrumentation tool used as the basis for streamlining and instrumenting the underlying TCP code in the viewer.
3. Installation of a Linux workstation in a Combustion Researcher's office containing a working version of the viewer. The user is experimenting with the tool to look at simulation results computed and stored on NERSC machines.
4. Second release of IBRAVR source containing the new, network instrumentation code.
Dec 17, 1999
Initial release of the source code for public access. Check this page for more information.
November 15, 1999 - SC99
We demonstrated the IBRAVR application at SC99 using a number of resources as computational/rendering engines, data sources and viewers. Please see this page for more info.
October 15, 1999
Data Engine: first integration with BoxLib/AMR. The goal is to enable semi-automatic viewing of large volumes of time varying data.
October 8, 1999
First prototype implementation of IBRAVR working. The data engine is written using MPI for parallelism. The data loader is custom-code for reading data volumes in AVS volume format (this format limits the maximum size of the volume to 255^3 - fine for toy problems). The rendering engine uses pthreads for network-communication parallelization.
This PowerPoint presentation has a few slides that shows all the system components.

The Current TODO List and Target Dates of Completion

Alternate Axis Viewing
Support for rendering and viewing from arbitrary views. Currently, Visapult is limited to views from the +Z direction (looking down the -Z axis). To accomplish this goal, view information needs to be transmitted to the back end from the viewer, and the viewer needs to alter how it accesses data; slabs along Z, slabs along X or slabs along Y. This feature was requested by the user in the April 12 campaignlet.
Block Decomposition
Decompose data in block rather than slab fashion to achieve better load balancing, better scalability and more options in terms of IBR techniques on the viewer side.
Finish port to CAVElib.
The Visapult viewer uses pthreads as the MP model, whereas CAVElib uses fork() and explicit System V shm operations for shared memory and IPC control. We started this port during the May 8-10 visit to ANL, but it should be finished. When finished, Visapult will run out-of-the-box on any tiled surface display where CAVElib is installed.
September 1, 2000
Finalization of project, reports, etc.

The following list represents things that would be nice to implement based upon accumulated experience and feedback from the user community.

Compute-side classifier and shader, Drebin & Hanrahan style volume rendering shader.
Web-based DPSS config-file browser.
Knowing what's where in the DPSS Visapult data blobs is not a straightforward thing. Having a web-based interface to this metadata, perhaps including some pics or something would be helpful.
Movies!
The time required to move 100Gbytes of data for time-varying visualization is currently much too long. We need better than 1GB second transfer rates for time-varying vis to occur in speeds that could be considered interactive - we're far from that now. With some redesign, we could start up Visapult, let it run, then when a "data gather" stage has completed, "play" the results. The basic idea is to retain the IBR-based volume rendering, and geom, but to cache all that info somewhere for the purpose of streaming it to the viewer. If we assume an order-of-magnitude data reduction between data source and viewer, we can probably cache all this information either in primary or secondary storage on the backEnd.
Port to NERSC-SP2
Data is currently being generated on the NERSC-SP2, and moving it elsewhere is proving to be an obstacle (for the researchers). Having access to a version of Visapult that runs on the SP2 would be useful.

Stuff that's not in the above list, but should be:

Generate a "terascale" test data set. This data should come from the combustion community. With a big, interesting data set, the combustion people will begin to try out these tools to look at this new and interesting data.
"Network-aware" is an elusive term. It appears at this time that the best metric of "network status" will be an ongoing test of available bandwidth, with the IBRAVR client-server responding accordingly. This figure will become available early in 2000 with the integration of usable network timing code.
Identification of some number of resources to be used for testing the back-end renderer. Possibilities include the CPLANT at SNL-CA, the LBL cluster(s) and NERSC machines such as the T3E.

Areas of Concern:

We need a DPSS library for the T3E in order to move combustion data directly from the T3E to the DPSS w/o the need to stage on smaller workstations.
Long term goals for this project. What will be the disposition of the tools created by this work? Where are sources of support for long-term maintenence, support and deployment into "the mainstream?"