GPU-Based Volume Rendering of Noisy Multi-Spectral Astronomical Data
A. Hassan, C.J.Fluke, D.G.Barnes
Swinburne Centre for Astrophysics & Supercomputing, Melbourne, Victoria, Australia, 3122
Introduction

Our design objectives were:

Design Decisions and Implementation tools
Why Volume Rendering?

Next-generation astronomy research facilities will generate newchallenges for data storage, access, analysis and systemmonitoring, bringing astronomy into the Petascale Data Era. But
even today, astronomical knowledge is not growing at thesame rate as the data. Scientific visualization is a fundamental,
enabling technology for knowledge discovery. Despite recent
progress, many current astronomy visualization approaches will
be seriously challenged by, or are completely incompatible
with, the Petascale Data Era. With an emphasis on developing
new approaches compatible with data from the Square
Kilometer Array and its Pathfinders, the goal of this work is toadvance the field of astrophysical visualization in preparation for
the Petascale Era.

Negative

Positive

Relatively Hard
to implement

No need fora previous
targetGlobalPicture of thedata cube

Why GPU?
Negative

Easy tounderstandComputationallyIntensive

Positive

Cheaper
No Message
Passing
ModelSpecial
development
paradigm

PeakPerformance> 4 TFlops
Massively
ParallelArchitecture

Multi-Spectral Astronomical Data

2.Build a mixed framework based on a distributed GPU
architecture to visualize such cubes.

Multi-GPU
Model
Distributed
Rendering(MPI)

Efficient GPU
Implementation

Multi-Threading
Environment

GPUGPU

Network Card

Comm. Thread

Network CardMPIBus Network Communication

Challenges and Design Objectives
Our main goal is to enable astronomers to visualize large
spectral data cubes of the size that will be generated fromAustralia SKA Pathfinder (ASKAP) (at least 1TB of data). To
achieve this target we designed a framework that utilizes thelatest available hardware technologies combined with thelatest software infrastructure.

MPI

Our Framework

OurFramework

VolumeRendering(Ray Tracing)Multiple GPU NodeMultispectral data can be considered as a 4D data volume
where three dimensions are associated to position allocation(two dimensions for the spatial position in sky coordinates andone dimension for the wavelength) and one dimension for theflux density. The data cube can be considered as a stack ofimages where each image presents a sky portion over a small
wavelength range (Δλ).

Comm. Thread

Single GPU Node

1.Use ray-casting volume rendering as our visualizationtechnique.

Distributed GPU Framework
Single GPU Nodezeiss.magnet.fsu.edu

Based on that, the following design decisions were taken:

Network Card

MPI

Comm. ThreadComm. ThreadComm. ThreadComm. Thread

GPUGPUGPUGPU

Our distributed GPU framework combines the processing
power of multiple GPU nodes to speed-up and enhance
the spectral line cube visualization process. This frameworkuses Message Passing Interface (MPI), Multi-threading, andCUDA to allow many GPUs to work on the same problem.

Framework workflow

Main Framework Modules

Sample Output

An expanding HI shell from the Canadian Galactic Plane Survey observed withthe Dominion Radio Astrophysical Observatory interferometer. X and Y axes are
Galactic longitude and latitude (714 x 520 pixels), and the Z axis is velocity withrespect to local standard of rest (30 channels). Note that axis labels have yet tobe implemented. Data courtesy Jayanne English (U.Manitoba).

Scene Integration

This figure shows a cross-functional diagram containing themain components of our proposed framework. These
components are partitioned based on their mainfunctionality into:•Scheduling module: responsible
controlling the overall process.

formanagingand•GPU module: includes different execution kernels and utilizes
the parallelization paradigm of the GPUs.
•Scene integration module: responsible for generating thefinal display output by combining the output of thecontributing GPUs.
•I/O and User interaction modules: support the user’s
interactivity and change the output according to the user’sinput.

Screen 1

Screen 2

Screen 3

Screen 4

Screen 5

Screen 6

A. The spectral line cube will be partitioned into a set ofsmaller sub-cubes.
B. The scheduler module will assign these sub-cubes to theprocessing Nodes/GPUs.
C. Each GPU will apply ray-tracing volume rendering to map
each output pixel into a color (RGBA) based on a preselected transfer function.
D. The process of volume rendering will produce (N) images
with the same resolution as the output screen(s).
E. The scene interation module will reapply the same transfer
function to these images to combine them into the finaloutput.
F. The final output will be directed to the output display(s).

Conclusion:
The focus of this work is to improve multi-spectral data visualization to cope with the vast amount ofdata to be produced by ASKAP and similar facilities. By employing GPUs combined with distributed
processing, we are aiming to implement a scalable system capable to interactively visualize “greaterthan memory” astrophysical datasets.

Web-site: http://astronomy.swin.edu.au

More information: E-mail ahassan@swin.edu.au or cfluke@swin.edu.au

115.27 GHz 12CO(J=1-0) observation of EP Aqr obtained with the IRAM
interferometer (Winters et al. 2007, A&A, 475, 559; VizieR On-line Data Catalog:J/A+A/475/559). The spectral cube comprises 26 velocity channels (Z axis) of
256x256 sky pixels.

Neutral hydrogen (21cm) observation of part of the Ursa Major galaxy cluster,
made with the Lovell radio-telescope at Jodrell Bank, Manchester. The image is
157x148 sky pixels by 148 velocity channels. Data courtesy Virginia Kilborn(Swinburne).