Introduction

As the ROSAT data have been distributed as FITS files, one can easily and quickly analyze ROSAT data using the xselect analysis system developed for ASCA.

xselect is a command-line interface to ftools. Its major role is to allow easy manipulation of the data (storing intermediate data products internally during use). It allows quick and easy extraction of images, light curves and spectra from the events files, with easy application of filters, data screening and other selection criteria, and easy viewing of intermediate data products (images, light curves and spectra). At present, xselect runs under SunOS-4, DEC/Ultrix, DEC/OSF and VAX/VMS. + xselect+ runs optimally with 24 MB of memory.

The ftools which you almost always need in your analysis are spawned from xselect. There are also a number of ftools which you may need, depending on your particular analysis requirements, these can be run at the system level.

This document outlines the analysis of ROSAT data using the ftools and xselect software. It assumes that the session is running on a terminal capable of supporting X-windows.

Please note that the xselect program is still evolving very fast so some things illustrated below will change in future releases. If you have suggestions for ROSAT-related improvements or spot bugs then please send them to turner@lheavx.gsfc.nasa.gov.

This document assumes that ftools and xselect are available standalone on your system. If they are not, you need to install them before you begin. To obtain the software, installation guide and full Users Manual for these tools please ftp to the anonymous account at heasarc.gsfc.nasa.gov Software and documentation are available under /software/ftools/release/ and help is available by emailing ftoolshelp@athena.gsfc.nasa.gov

This document does not cover all of the sophisticated functionality provided by ftools/xselect, but covers some of the basics steps you are likely to need during your ROSAT data analysis. Please see the xselect Users Guide or online help for a detailed description of the more advanced features of the software.

ROSAT File formats

As ROSAT data processing software has been upgraded during the course of the mission, the file formats and the sequence-naming conventions have evolved. Data exist in three formats at the current time.

• Data processed in the US before mid-April 1994 were written in the so- called Rev0 FITS format. In the Rev0 format there are approximately 30 files for a typical PSPC dataset and 35 for a typical HRI dataset; the exact number of files depends on the details of the processing.

• Data processed after mid-April 1994 are written to tape as FITS files using the Rationalized Data Format (RDF), which uses a standard set of header keywords and data table structures to provide the data in a more user- friendly, multi-mission context. For data written in RDF there are 15 data files associated with each PSPC dataset, and 8 files associated with each HRI dataset.

• Data processed before mid-April 1994 in Germany are written in what we designate Rev0 German format. Data storage in the German files is significantly different to the oether two formats, and one must reformat the German events files before analysis is possible in the xselect or ftools environment. For data written in Rev0 German format there are 21 files associated with a PSPC dataset (the events file has a name like wp700272_events.tfits).

Because both MPE and the USRSDC have adopted RDF, the format of the ROSAT data products will be independent of where the data were processed; thus users of ROSAT data processed at MPE will easily be able to interpret and use ROSAT datasets processed in the US, and vice-versa. Eventually the ROSAT data archive will be overwritten such that all data are in the same Rationalized Data Format -RDF). In addition, RDF is being adopted by numerous other missions (EINSTEIN, ASCA and XTE) which means that software which can interpret and analyze ROSAT data should be able to interpret and analyze data from these and other missions.

The files distributed on the RDF data tape adhere to the FITS standard as described in the NASA/OSSA Office of Standards and Technology (NOST) draft 100-0.3b, ``Implementation of the Flexible Image Transport System (FITS),'' dated November 6, 1991. The ROSAT files use FITS primary images and FITS IMAGE extensions and ASCII and BINARY table extensions, although most data (apart from images) are stored in BINARY table (BINTABLE) extensions.

Detailed descriptions of each of the Rev0 and RDF files can be found in the Data Products Guide.

U.S. Sequence Naming Conventions

A key difference between early Rev0 format data and later Revo format data pertains to the way separate observation intervals (called "OBIs") are combined. Initially, all available OBIs were used to produce a single set of data products, later, OBIs which were part of the same sequence but which occurred in different "observing seasons" (i.e.,  6 months apart) were processed and distributed separately.

All data processed by the U.S. RSDC using SASS versions 3_0 through 5_9 (Rev0) used file names of the form:

               r<detector-code><ROR><extensions>,

where:         r                - stands for ROSAT

               <detector-code>  - code for detector/filter:
                                        h - HRI
                                        p - PSPC
                                        f - Filtered PSPC.

               <ROR>           - 6-digit Rosat Observation Request number

              <extensions>     - additional characters specifying "type"
                                  of data.

In later Rev0 data, observations conducted over different "observing seasons" (i.e., over gaps of several months) were no longer combined to form a single data set. Additional observations, known as "add-ons", were processed separately. The sequence-naming convention became:

r<detector-code><ROR><add-on number><extensions>

where the two additional digits added after the ROR number are:

                <add-on number> - 00 indicates the first segment,
                                - 01 indicates the second segment,
                                - 02 indicates the third segment,
                                    and so on.

An additional identifier has been inserted into the RDF file names to indicate both "split" Rev0 sequences and "mispointed" observations (those for which the telescope was not pointed at the intended target). The RDF FITS file names have the form:

r<detector-code><ROR><obs-code><extensions>

where obs-code has replaced add-on number:

<obs-code> =

• n00 - observed as scheduled, first segment ("n" = Normal)

• a01,a02,... - observed as scheduled: first, second, and subsequent segments added to the "normal" segment ("a" = Add-on)

• a00,a01,... - indicate 1st, 2nd, and subsequent segments for an observation which was first processed as a single observation in rev 0 processing.

• m01,m02,... - mispointed segment (targeting was not as scheduled), numbering begins at 1 ("m" = Mispointed)

Coverting Old style German events files to RDF

xselect can handle both the old style US FITS files (hereafter called US Rev0), and the new RDF FITS format files. In the Rev0 case the events for sequence "rp700105" for example are in the file rp700105.fits or rp70010500.fits, depending on what version of SASS was used for the data processing. In the RDF case the events are in a file with a name like rp700105n00_bas.fits or rh110267n00_bas.fits, the "basic" file.

Old format German events files must be converted to RDF format prior to starting xselect. To do this run

gevt2rdf
Enter file name: wp700559_events.tfits
Infile is wp700559_events.tfits
ONTIME :    2393.0000000000
Number of rows in STDGTI table:   2
Number of rows in STDEVT table:   28845
New file wp700559.fits written

Old German format archive images can also be converted to RDF FITS format, the converted image can then be displayed via saoimage

Example:

        img2us
        Name of German ROSAT image FITS file[ ] wp700559_image1.ifits

This creates a FITS image of name wp700559_im1.fits which can be displayed using saoimage at the system level i.e.

        saoimage wp700559_im1.fits