14 ROSAT Data Cube

This recipe shows how to import and display a data cube observed with the ROSAT X-ray astronomy satellite (Röntgensatellit). ROSAT data come in a number of different formats. The example used here is an Asterix binned dataset of the irregular galaxy M82 (NGC 3034). This format is used by the Asterix package (see SUN/98[9]). The data cube comprises a grid of 216 by 216 points on the sky, with a spectrum of 22 points at each position. The example data are available as file m82ast.sdf. The procedure for importing and displaying these data is very similar to the corresponding procedure for JCMT data described in Section 13.

The first stage to importing an Asterix binned dataset is to convert it to a simple data cube in the standard Starlink NDF format. Application ast2ndf in the CONVERT package (see SUN/55[6]) performs this task. Proceed as follows. First type:
  % convert

to make the CONVERT applications available. Then type:

  % ast2ndf   m82ast  m82ndf

Note that though the input Asterix binned dataset and output NDF are respectively held in files called m82ast.sdf and m82ndf.sdf they are specified to application ast2ndf without the ‘.sdf’ file type.

It is also worth noting that an Asterix binned dataset is itself almost a standard Starlink NDF. ast2ndf merely makes the data format completely standard and rearranges the order of the axes.

Once the Asterix binned dataset has been converted to a simple data cube in the NDF format then a variety of standard Starlink applications can be used to process and display it. For example, it can be accessed with the image processing applications in KAPPA (see SUN/95[8]). It is also possible to inspect the structure of the data set using hdstrace. Simply type:
  % hdstrace  m82ndf

Again 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[10]. In addition, hdstrace and many other standard Starlink applications, will also work on the original Asterix binned dataset.

The next step is to convert the NDF format file into a file in the ‘native’ DX format, which DX can read. This operation could be performed ‘on the fly’ as DX reads the file. However, it is simpler to convert the file in a separate operation prior to invoking DX. The conversion is performed using application ndf2dx, which is part of SX, the Starlink enhancements to DX (see SUN/203[11]). By convention files in the native DX format have file type ‘.dx’. To convert the entire data cube simply type:
  % $SX_DIR/ndf2dx  m82ndf  m82.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 energies. For example, in the example dataset most of the useful information lies between energy steps 5 and 15. It is possible to convert a subset of the NDF corresponding to a given range of energy steps. For example, to convert a subset corresponding to steps 5 through to 15 type:

  % $SX_DIR/ndf2dx  ’m82ndf(5:15,,)’  m82sub.dx  axes=no

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[3].

The axes=no option causes ndf2dx to ignore any axis information present in the input dataset and write the output DX file with axes consisting of simple pixel numbers. This option may or may not be appropriate depending on the details of your data. In the present case it leads to a better visualisation.

Figure 17 shows a DX network to display a sequence of slices through a ROSAT data cube Each slice corresponds to the grid of points seen on the sky at a given radial velocity. The network is available as files rosatslice.net and rosatslice.cfg (rosatslice.net is the basic network and rosatslice.cfg is a ‘configuration file’ which controls some aspects of its behaviour). Start DX (as described in Section 2). Then proceed as follows.


Figure 17: Network to display a sequence of slices through a ROSAT data cube.

Load the network. Select the ‘Open Program’ option from the ‘File’ menu of the main DX window. Select file rosatslice.net. The network should now load and appear in the main window. See Section 4 for further details.
Select the ‘Open All Control Panels’ option from the ‘Windows’ menu of the main DX window. Set the required file name and number of slices. (In the current example these are m82sub.dx and 10 respectively.) Close the ‘Control Panel’ window.
Execute the network once. Once the network has executed you will probably have to reset the display window (option ‘Reset’ in the ‘Options’ menu of the display window). For a more effective display select ‘View control’ from the ‘Options’ menu and set the ‘Set View’ parameter to one of the ‘Off’ options, perhaps ‘Off top’.
Finally double click on the ‘Sequencer’ module and click on the play button. A sequence of slices sweeping through the data cube will now be displayed.

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 count rate in counts per second. This network for displaying ROSAT data is virtually identical to the corresponding network for JCMT data (see Section 13 and Figure 15). The only differences are the defaults for the file names and the axis labels. Similarly, the network for generating an iso-surface in JCMT data (see Figure 16) requires only minor cosmetic modifications to display ROSAT data.

Part III
The DX Data Model