This recipe shows how to import and display a set of spectra observed in the mm or sub-mm wavelength range of the electromagnetic spectrum with a heterodyne receiver on the James Clerk Maxwell Telescope (JCMT) in Hawaii. The example used here is an observation of emission from the CO transition in L1689B, a dense core within the molecular cloud Lynds Dark Nebula 1689. The data cube comprises a grid of 7 by 7 points on the sky, with a spectrum of 153 channels at each position. The example data are available as file l1689b.sdf. JCMT heterodyne observations are usually reduced using the SPECX package (see SUN/17) and the example data are in the native SPECX data format. In SPECX terminology a collection of spectra on a grid of points on the sky is a called a `map'.
The data for L1689B have kindly been made available in advance of publication; they may not be published without the express, written permission of the observers (see Section for details).
to make the CONVERT applications available. Then type:
specx2ndf l1689b l1689bndf
Note that though the input SPECX map and output NDF are respectively held in files called l1689b.sdf and l1689bndf.sdf they are specified to application specx2ndf without the ` .sdf' file type.
When displaying SPECX maps it is conventional to represent the spectral axis as a series of radial velocities computed for the rest wavelength of the line being observed and corrected to a kinematical local standard of rest. By default specx2ndf generates the spectral axis in this fashion and this is how it will be computed in the above example. However, specx2ndf allows some flexibility in how the spectral axis is represented; see the appropriate section of SUN/55 for details of the alternatives available.
to make the KAPPA applications available. Then type:
Again the file name is specified without the `.sdf' file type. This application lists the history information describing the processing which has been performed on the data. The history information appended by specx2ndf includes details of the way in which the spectral axis was computed. It is also possible to inspect the structure of the data set using hdstrace. Simply type:
As usual the file name is specified without the `.sdf' file type. This facility is useful because it lists the value of much of the auxiliary information contained in the data set. hdstrace is documented in SUN/102. In addition hdstrace will also work on the original SPECX map.
$SX_DIR/ndf2dx l1689bndf l1689ball.dx
Note that though the file type is not specified for the input NDF file, it should be given for the output native DX format file.
The above example will convert the entire data cube. However, often the useful information will be contained in only a small range of radial velocities. For example, in the example map most of the useful information lies between velocity channels 65 and 85. It is possible to convert a subset of the NDF corresponding to a given range of velocity channels. For example, to convert a subset corresponding to channels 65 through to 85 type:
$SX_DIR/ndf2dx 'l1689bndf(65:85,,)' l1689bsub.dx
The syntax to specify a subset of an NDF is to give the bounds of the required region inside parentheses after the file name. Unfortunately however, by default the Unix shell will attempt to interpret these parentheses. Thus, in the above example the input file name and NDF subset are enclosed in single quotes in order to prevent this behaviour and ensure they are passed correctly to ndf2dx. The use of `escape mechanisms' of this sort to prevent the premature interpretation of special characters sent to Starlink applications is discussed in SC/4.
The network includes a `scale bar' showing how the colour displayed for each pixel in each slice corresponds to the value of the pixel. In this example the value of each pixel is the radio `brightness temperature' in Kelvin.
Much of the complexity of this network occurs because it contains an option to normalise the axes of the cube. Two of the axes correspond to positions on the sky and the third to the dispersion, usually expressed as a radial velocity computed from the rest wavelength of the line. There is no relation between the spacial and spectral axes, so the `cube' can be either very `long' or `thin' in the spectral axis compared to the spacial ones. In order to generate an effective iso-surface it often helps to `normalise' the cube so that it has unit length in each axis. Though this procedure often improves the iso-surfaces generated it makes the axes less intuitive. Hence it is made optional so that you can choose the alternative most suitable for your data.
The DX Cookbook