Asteroseismology is a powerful technique for probing the internal structure of distant stars by studying time-varying disturbances on their surfaces. A direct analogy can be drawn to the way that the study of earthquakes (seismology) allows us to infer the internal structure of the Earth. Due to the recent launch of space satellites devoted to discovering and monitoring these surface disturbances in hundreds of thousands of stars, paired with ground-based telescopes capable of high-resolution, high-cadence follow-up spectroscopy, asteroseismology is currently enjoying a golden age. However, there remains a significant computation challenge: how do we analyze and interpret the veritable torrent of new asteroseismic data?

To date, the most straightforward and accurate analysis approach is direct modeling via spectral synthesis (discussed in greater detail later in this chapter). Given a set of observations of the time-varying radiant flux received from a star, we attempt to construct a sequence of synthetic spectra to reproduce these observations. Any given model depends on the assumed parameters describing the star and its surface disturbances. Using an optimization strategy we find the combination of parameters that best reproduces the observations, ultimately allowing us to establish constraints on the stellar structure.

Stellar spectral synthesis is the process of summing up the Earth-directed radiant flux from each region on the visible hemisphere of a star. A typical procedure, e.g., Reference 1, comprises the following steps:

Steps (1) and (2) are performed once for a star and/or set of stellar and disturbance parameters. The main computational cost comes in step (3), which we now discuss in greater detail.

Over the wavelength grid λ _j the radiant flux is calculated as Here, A is the area of the fragment, D the distance to the star, and I (…) the specific intensity of the radiation emerging at rest wavelength and direction cosine μ from a stellar atmosphere with effective temperature T and surface gravity g (see Table 7.1 ). The rest wavelength is obtained from the Doppler shift formula, where v is the line-of-sight velocity of the fragment and c is the speed of light.

Calculating the specific intensity I (…) requires detailed modeling of the atomic physics and energy transport within the stellar atmosphere and is far too costly to do on the fly. Instead, we evaluate this intensity by four-dimensional linear interpolation in precalculated tables .

For typical parameters (N _frag , N _λ ≈ 5,000−10,000) a synthetic spectrum typically takes only a few seconds to generate on a modern CPU. However, with many possible parameter combinations, the overall optimization (see Section 7.1.1 ) can be computationally expensive, taking many weeks in a typical analysis. The primary bottleneck lies in the 4-D specific intensity interpolations described earlier in this chapter; although algorithmically simple, their arithmetic and memory-access costs quickly add up. This issue motivates us to pose the following question:

In addressing this question, we have developed grassy (GR aphics Processing Unit — A ccelerated S pectral SY nthesis) — a hardware/software platform for fast spectral synthesis that leverages the texture interpolation functionality in CUDA-capable GPUs (see Figure 7.2 ). In the following section, we establish a more formal basis for the interpolation problem; then, in Section 7.3 , we introduce our grassy platform. Section 7.4 presents results from initial validation and testing, and in Section 7.5 , we discuss future directions for this avenue of GPU computing research.

In this section, we introduce the grassy spectral synthesis platform. To leverage the texture interpolation functionality in CUDA-capable GPUs, some modifications to the procedure outlined in Listing 7.1 are necessary. In particular, we decompose the calculations into a series of 2-D interpolations, which are then implemented as fetches (with bilinear filtering) from 2-D textures. This brings the dual benefits of efficient memory access due to use of the texture cache, and “free” interpolation arithmetic provided by the linear filtering mode. One potential pitfall, however, is the limited precision of the linear filtering; we review this issue in Section 7.3.6 .

The 4-D to 2-D interpolation decomposition is enabled by a CPU-based preprocessing step, whereby quads [ T , g , v , m ] from step (2) of the spectral synthesis procedure are translated into 10-tuples [ v , μ , k ₀ , k ₁ , k ₂ , k ₃ , w ₀ , w ₁ , w ₂ , w ₃ ]. A single 10-tuple codes for four separate bilinear interpolations, in 2-D tables representing the specific intensity for a given combination of effective temperature and surface gravity. The indices indicate which tables to interpolate within, while the weights w ₀ … w ₃ are used post-interpolation to combine the results together.

Because CUDA does not support arrays of texture references (which would allow us to place each table into a separate texture), grassy packs the 2-D intensity tables into a single 2-D texture. ¹ For a given interpolation, the floating-point texture coordinates (x , y ) are calculated from λ , μ and the table index k via and Here, is the direction cosine dimension of each intensity table, while is the base wavelength and the wavelength spacing (not to be confused with λ and Δ λ ). The offsets by 0.5 come from the recommendations of Appendix F.3 of [10] . Note that these two equations are not the actual interpolation, but rather the conversion from physical (wavelength, direction cosine) coordinates to un-normalized texture coordinates.

To maximize texture cache locality, grassy groups calculations into N _b batches of consecutive wavelengths. These batches map directly into CUDA thread blocks, with each thread in a block responsible for interpolating the intensity, and accumulating the flux, at a single wavelength. To ensure adequate utilization of GPU resources, N _b should be an integer multiple of the number of streaming multiprocessors (SMs) in the device.

Every thread block processes the entire input stream of N _frag 10-tuples, to build up the aggregated flux spectrum for the wavelength range covered by the block. Upon completion, this spectrum is written to global memory, from where it can subsequently be copied over to the CPU.

Listing 7.2 provides pseudo code for the CUDA kernel within grassy , which handles the flux calculation and aggregation. Kernel arguments are the input stream of 10-tuples and a pointer to an array in device global memory where the resulting flux spectrum will be placed. Each thread evaluates its own wavelength on the fly from the index j , which in turn is obtained from thread and block indices.

In this subsection we discuss in detail the potential issues arising from the 9-bit precision of the GPU texture interpolation. For exact one-dimensional linear interpolation between two pairs of points, (x ₀ , f ₀ ) and (x ₁ , f ₁ ), the interpolant f (x ) can be expressed as Here, is the weight function, whose linear variation between 0 (x = x ₀ ) and 1 (x = x ₁ ) gives a corresponding linear change in f (x ), from f = f ₀ to f = f ₁ . In a floating-point implementation of these expressions, the finite precision means that f (x ) no longer varies completely smoothly, instead exhibiting step-wise jumps. However, these jumps are typically on the order of a few units of last place and thus not a particularly important source of numerical error.

The situation is different if the weight function w (x ) is evaluated using fixed-precision arithmetic. With n bits of precision, there are only 2 _n distinct values that w (x ) can assume — and, by implication, only 2 _n distinct values of f (x ) between f ₀ and f ₁ . Then, the step-wise jumps in f (x ) can be significant.

Exactly how significant the step-wise jump is depends on the difference between f ₀ and f ₁ . The worst-case scenario occurs when f ₁ = − f ₀ , giving a bound on the error in f (x ) of For the fixed-precision linear interpolation offered through CUDA texture lookups, n = 9 bits, giving an error bound of . However, in practice the error will be much smaller than this because for an adequately sampled lookup table the worst-case scenario will never arise. If all features in the table have a characteristic width of m points, then the maximum difference between f ₀ and f ₁ is f / m , giving an error bound

Listing 7.2.

Pseudo code for the grassy kernel.

Clearly, a more-finely sampled table (i.e., larger m ) yields smaller errors, at the cost of consuming more memory.

In the present context of specific intensity interpolation, we use tables sampled at 0.03 Angstrom. Over the optical wavelength range of 3,500–7,500 Angstrom, features in the tables have a typical scale of at least 0.2 Angstrom (the thermal broadening width), six times the sampling interval. This implies an error bound (assuming n = 9) of . Errors of this magnitude are unimportant when contrasted against uncertainties in the tabulated intensities (due to theoretical approximations) and against the inherent noise in the observations against which synthetic spectra are compared.

In anticipation of the performance evaluation in the following section, here we provide a simple model to estimate the expected performance of grassy . Let be the number of computational operations required to process one 10-tuple at one wavelength; the total number of operations for synthesis of a complete spectrum is then . For (typical values, and the ones adopted in the calculations below), and assuming , we estimate billion operations (GOPS) per spectrum.

A Tesla C1060 GPU has a peak throughput of 933 GOPS/s. Assuming we are able to achieve half of this, we expect a throughput of 70 spectra per second, or 14 ms per spectrum.

Our testing and validation platform is a Dell Precision 490 workstation, containing two 2.33 GHz Intel Xeon E5345 quad-core CPUs and a Tesla C1060 GPU. The workstation runs 64-bit Gentoo Linux (kernel 2.6.25) and uses version 3.0 of the CUDA SDK. As a CPU-based comparison code, we adopt a highly optimized Fortran 95 version of the kylie code [1] , running on the same workstation.

We use specific intensity tables based on the OSTAR2002 and BSTAR2006 grids of model stellar atmospheres [8] and [9] , with intensities calculated using the synspec package developed by I. Hubeny and T. Lanz. The input stream of 10 tuples is generated from a modified version of the bruce code [1] .

Table 7.2 summarizes the average time taken by the CPU and GPU platforms to synthesize a spectrum with . For these calculations, we adopt a GPU thread block size of 128; a gradual performance degradation occurs toward larger values of the block size because of a shortage of blocks to map on to multiprocessors.

As mentioned in Section 7.1 , the CPU platform takes on the order of seconds per spectrum. The Tesla C1060 is around 30 times faster than the CPU, although not so fast as we had estimated from our simple analysis in Section 7.3.7 . The bottleneck appears to be in the memory accesses; the global memory throughput reported by the cudaprof profiler is only 17.1 GB/sec. On closer inspection, it appears that we are not making best use of the texture cache; the ratio of misses to hits is an alarming 90:1! We are currently examining ways in which better cache locality might be achieved, for instance, by altering the texture-packing layout (Section 7.3.3 ).

As we have discussed already in this chapter, specific intensity interpolation currently represents the major bottleneck in synthesizing spectra for asteroseismic analyses. Current CPU-based implementations typically lead to per-star analysis runtimes of weeks. The speedups reported earlier in this chapter — when scaled to multidevice systems — herald the prospect of being able to shorten these times to hours. It goes without saying that this will have a significant impact on the field of asteroseismology, as the analysis throughput and/or resolution of parameter determinations can be greatly increased, in turn allowing stronger constraints to be placed on the internal structures of stars.

The benefits of accelerated spectral synthesis will also extend to other fields of astrophysics, from the analysis of rotationally flattened stars to the generation of combined spectra for clusters or entire galaxies of stars (so-called population synthesis). Our approach generalizes to other numerical techniques that rely on interpolation as well.

In terms of numerical analysis, our work opens up new avenues. While building this application and investigating the use of textures for computation, we realized several features from a numerical standpoint that introduce trade-offs:

Our initial prototype implementation of the code is complete, but optimizations are ongoing. We expect to provide a hosted multiple-device system with remote access for astronomers in the next 12 to 18 months. At this juncture, all source code will be released under the GNU General Public License.

We acknowledge support from NSF Advanced Technology and Instrumentation grant AST-0904607. The Tesla C1060 GPU used in this study was donated by NVIDIA through its Professor Partnership Program.