Tamas Szalay, Volker Springel, Gerard Lemson GPU-Based Interactive Visualization of Billion-Point Cosmological Simulations Tamas Szalay, Volker Springel, Gerard Lemson

The Visualization Problem Getting better at storage and processing Distributed databases, clouds, etc… I/O needs to be only as fast as computation Doesn’t work for visualization Would need to read all the data every frame or have it all in memory Even rendering itself would be prohibitive Could use pre-rendered movies Trial and error takes time

The Aquarius Simulations A series of n-body dark matter simulations Run from the early universe to today Box roughly the size of galactic neighborhood Run five times at different particle resolutions Lowest has 2.3 million, takes up about 25 GB total Highest has 4 billion, and takes up 20 TB Each version has point data in 128 ‘snapshots’, with positions and velocities Movies have been rendered, took weeks

Visualization Motivation Certain types of analysis very difficult otherwise Qualitative impressions of gravitational structures Verification of simulation and accuracy of structure finding Identification of events of interest Comparisons of multiple objects Two colliding gravitational clusters Dark matter streams Public outreach

Hierarchical Rendering Don’t need to render everything Saturates screen anyway So show the same data, but render less Create different levels-of-detail for entire dataset Load different parts from different levels as needed Put levels-of-detail on fast storage system And give it a rendering front-end Think Google Microsoft Maps

Level Structure Chose spatial octree because it is simple and general Each node also has associated data All of the data spatially contained within the cube Except simplified to <= N points Deeper in the tree means higher resolution Organized this way on disk

Selective Loading What resolution data to load in what spatial location? Close to viewer in high detail and far away in low detail Can use the on-screen size of the relevant octree cube to determine resolution Means, in theory, visually equivalent to entire dataset Automatically scales to rendering hardware Can spread out through time as well

Rendering Front-End GPUs are fast The actual rendering algorithm: Really fast Can do an unbelievable amount of computation in rendering pipeline Allows tool to still do significant processing The actual rendering algorithm: Brightness represents the line integral of the squared density in that pixel Color represents the temperature But there is quite a bit of computation involved

Practical Results Program currently runs on single desktop computer and attached storage 4 GB RAM, GeForce 8800 GTS, 2x750 GB disk Smoothly interacts with and renders 1 TB dataset (150 million points x 128 timesteps) Rarely loads or renders to full depth Could have arbitrarily large underlying data

Future Possibilities Storing and accessing data via databases Could even do some processing in between Distributed rendering Remote rendering Other datasets and data types Meshes, volume data, medical imaging