Next: The INTEGRAL Ground Segment
Up: High Performance Computing
Previous: Making FITS available on Dot Net and its applications
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

Jenness, T., Economou, F., Scott, D., Kelly, B. D., & Holland, W. S. 2003, in ASP Conf. Ser., Vol. 314 Astronomical Data Analysis Software and Systems XIII, eds. F. Ochsenbein, M. Allen, & D. Egret (San Francisco: ASP), 428

Preliminary design of the SCUBA-2 Data Reduction Pipeline

Tim Jenness1, Frossie Economou
Joint Astronomy Centre, 660 N. A`oh{\={o\/}}k{\={u\/}} Place, University Park, Hilo, Hawaii, 96720

Douglas Scott
University of British Columbia, 6224 Agricultural Road, Vancouver, British Columbia, V6T 1Z1, Canada

Dennis Kelly, Wayne S. Holland
UK Astronomy Technology Centre, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ, UK


SCUBA-2, scheduled for delivery in late 2005, will be the largest submillimetre bolometer array ever built. Data from this instrument are stored at a rate of 200 Hz generating approximately 0.5 TB per night; unheard of for a submillimetre array. This paper will discuss the overall design of the planned pipeline, with reference to some of the unique algorithmic challenges that must be resolved.

1. Introduction

SCUBA-2 (Holland et al. 2003) is a second generation wide-field submillimetre camera under development for the James Clerk Maxwell Telescope (JCMT). With over 10,000 pixels in two arrays (850- and 450-$\mu$m), SCUBA-2 will map the submillimetre sky up to 1000 times faster than the current SCUBA (Holland et al. 1999).

2. Observing Modes

Unlike SCUBA, which can only record an AC (i.e. chopped) signal, the signal output of the SCUBA-2 pixels will be DC-coupled to the signal processing electronics. This will lead to significant efficiency improvements, since half of the integration cycle is not spent on blank sky. There is no need for sky chopping, leading to better image fidelity and sensitivity to source structure on all scales. It also gives a lower confusion limit i.e. by not continuously subtracting two images of the sky. However, the main complication is that 1/f noise from detectors or electronics must be at an acceptable level. A cold shutter will take ``dark frames'' to compensate for any 1/f noise and any other instrumental drifts. It is envisaged that SCUBA-2 will provide JCMT with the following observing modes.

2.1 Imaging

To produce images up to a few arrays in size the array can image regions of the sky equivalent to the array field-of-view (8 arcmin) and mosaic together offset frames. There are two techniques to achieve this. The simplest imaging mode is simply to co-add the 200 Hz data, de-spike, flat-field and fit a sky signal. Whilst straightforward, it is not yet clear that the flat-field will be stable enough for this to work.

The difficulty associated with maintaining a stable flat-field indicates that it is likely that an observing mode more complex than simple co-adding and sky fitting will be required for simple imaging mode. We intend to use the DREAM (Dutch Real-Time Acquisition Mode) technique as prototyped on SCUBA (Le Poole & van Someren Greve 1998). In essence, with this technique the secondary mirror is moved rapidly such that multiple bolometers measure the same point in the sky during a single second of integration. The relative response for each bolometer can then be solved such that the individual maps created for each bolometer can be tiled to create a complete image. The main constraint on the system is the maximum size of the secondary mirror excursion (any larger than about 30 arcsec will lead to vignetting of the array) and the requirement to get round the pattern before the atmosphere changes.

2.2 Scan Mode

The 200 Hz readout rate and the 7 arcsec beam at 450 $\mu$m combine to limit the maximum scan speed to approximately 600 arcsec/sec whilst Nyquist sampling. This is significantly faster than the current SCUBA scan rate of 24 arcsec/sec at 450 $\mu$m or 60 arcsec/sec at 850 $\mu$m, resulting in maps potentially covering up to tens of degrees at a time.

2.3 Spectroscopic/Polarimetric

The polarimeter and FTS will rely on the standard STARE mode (not DREAM) in order to maximize observing efficiency. The polarimeter wave-plate will be spinning fast (up to 25 Hz) in order to minimize sky variations and will be a scaled-up version of the current SCUBA polarimeter (Greaves et al. 2003). Similarly, the FTS mirror will be scanned rapidly to generate a cube as quickly as possible (see, e.g. Naylor et al. 2003). Processing the data whilst keeping up with observing will be challenging.

3. Computing Challenges

While 10,000 pixels spread over 2 wavelengths may not seem like much to those used to large CCDs, the challenge for SCUBA-2 lies in the fact that the instrument is read out and data stored to disk at 200 frames per second (and up to 20 kHz in the acquisition electronics). This speed is required in order to enable the sky variation during the readout to be minimized and allows for a very fast mapping speed.

The data rate for SCUBA-2 translates to 4 MB/s for each wavelength, equivalent to 0.5 TB of data per night for a normal 16 hour observing period. Each sub-array is connected to a separate data acquisition (DA) computer running Real Time Linux. In imaging mode a file is written every few seconds (limited by sky rotation; the instrument is on the Nasmyth platform without an image rotator) while in SCAN mode a file is written approximately every minute. The pipeline and display system pick up data from the file system.

4. Data Display

There is no real-time display associated with SCUBA-2. Observer feedback is provided by an instance of the pipeline optimized to display the observation progress as fast as possible (the so-called ``Quick Look'' (QL) pipeline): simply co-adding sub-scans and re-gridding the data from Nasmyth coordinates to RA/Dec. The QL pipeline is fundamentally identical to the main analysis pipeline, differing only in the recipe that is executed. No data analysis is included in this version of the pipeline. GAIA/RTD (e.g. Draper 2000) will be used as the main display engine.

5. Pipeline Architecture

The SCUBA-2 pipeline will use the ORAC-DR pipeline infrastructure (Economou et al. 1999). This architecture has a proven track record on UKIRT (Economou et al. 2001), JCMT (Jenness & Economou 1999) and the AAT, is truly generic (it can also support Gemini (Cavanagh et al. 2003) and ESO data (Currie 2004)) and is easily flexible enough to incorporate SCUBA-2 data. Where possible we will make use of existing applications (the standard SCUBA algorithms for skydip fitting (Jenness & Lightfoot 1998; Archibald et al. 2002), Starlink applications for mosaicking and world coordinate handling (Giaretta et al. 2004; Berry 2004), and standard point source extraction tools) but new applications will also have to be written to deal with the unique observational and computing requirements for the specified observing modes (the so-called algorithm engines). Supported messaging interfaces are SOAP, DRAMA (Bailey, Farrell & Shortridge 1995) and Starlink ADAM.

6. Calibration Enhancements

The ability to generate complete fully-sampled images in 1 second (significantly faster than the 64 seconds required with the current SCUBA) allows some fairly significant improvements in calibration accuracy possible from the pipeline. For example, the opacity correction can be applied from the water vapor radiometer (see e.g. Wiedner et al. 2001) which can provide line-of-sight opacity values every 1.2 seconds. Also, the field-of-view is 16 times larger than with SCUBA and much more sensitive; bright sources in the field can usefully allow for fast pointing/seeing corrections to be applied. Finally, calibration drifts can be corrected much more accurately due to the faster sampling and larger field-of-view. (cf. Jenness et al. 2002).

7. Time Line

SCUBA-2 is considered a high risk high return project on an aggressive time schedule. It is currently due to go on JCMT in early 2006. The general pipeline architecture will be tested on simulated data prior to delivery, but the details of specific algorithms may change significantly during commissioning.


Archibald, A., et al. 2002, MNRAS, 336, 1

Bailey, J. A., Farrell, T. & Shortridge, K. 1995, Proc. SPIE, 2479, 62

Berry, D. S. 2004, this volume, 412

Cavanagh, B. et al. 2003, in ASP Conf. Ser., Vol. 295, Astronomical Data Analysis Software and Systems XII, ed. H. E. Payne, R. I. Jedrzejewski, & R. N. Hook (San Francisco: ASP), 237

Currie, M. J. 2004, this volume, 460

Draper, P. W. 2000, in ASP Conf. Ser., Vol. 216, Astronomical Data Analysis Software and Systems IX, ed. N. Manset, C. Veillet, & D. Crabtree (San Francisco: ASP), 615

Economou, F. et al. 1999, in ASP Conf. Ser., Vol. 172, Astronomical Data Analysis Software and Systems VIII, ed.  David M. Mehringer, Raymond L. Plante, & Douglas A. Roberts (San Francisco: ASP), 11

Economou, F. et al. 2001, in ASP Conf. Ser., Vol. 238, Astronomical Data Analysis Software and Systems X, ed. F. R. Harnden, Jr., Francis A. Primini, & Harry E. Payne (San Francisco: ASP), 314

Giaretta, D. et al. 2004, this volume, 832

Greaves, J. S. et al. 2003, MNRAS, 340, 353

Holland, W. S. et al. 1999, MNRAS, 303, 659

Holland, W. S. et al. 2003, Proc. SPIE, 4855, 1

Jenness, T., & Lightfoot, J. F. 1998, in ASP Conf. Ser., Vol. 145, Astronomical Data Analysis Software and Systems VII, ed. R. Albrecht, R. N. Hook, & H. A. Bushouse (San Francisco: ASP), 216

Jenness, T., & Economou, F. 1999, in ASP Conf. Ser., Vol. 172, Astronomical Data Analysis Software and Systems VIII, ed.  David M. Mehringer, Raymond L. Plante, & Douglas A. Roberts (San Francisco: ASP), 171

Jenness, T. et al. 2002, MNRAS, 336, 14

Le Poole, R. S. & van Someren Greve, H. W. 1998, Proc. SPIE, 3357, 638

Naylor, D. A. et al. 2003, Proc. SPIE, 4855, 540

Wiedner, M. C., Hills, R. E., Carlstrom, J. E. & Lay, O. P. 2001, ApJ, 553, 1036


... Jenness1
University of British Columbia

© Copyright 2004 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: The INTEGRAL Ground Segment
Up: High Performance Computing
Previous: Making FITS available on Dot Net and its applications
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint