next up previous contents
Next: 8. An OM Data Up: XMM ABC Guide Previous: 6. An EPIC Data   Contents

Subsections


7. An RGS Data Processing and Analysis Primer

Before beginning this chapter please consult the ``watchout'' page at the SOC:

http://xmm.esac.esa.int/sas/current/watchout/
This web site discusses current and past SAS bugs and analysis issues.

Many files are associated with an RGS dataset, and it is easy to be overwhelmed. The INDEX.HTM file, and links therein, are viewable with a web browser and will help you navigate the dataset. The different types of files are discussed in more detail in Chapter 1.

As ever, it is strongly recommended that you keep all reprocessed data in its own directory! SAS places output files in whichever directory it is in when a task is called. Throughout this primer, it is assumed that the Pipleline Processed data are in the PPS directory, the ODF data (with upper case file names, and uncompressed) are in the directory ODF, the reprocessing and analysis is taking place in the PROC directory, and the CCF data are in the directory CCF.

If you have just received your data from the SOC, it has been processed with the most recent version of SAS, and you should not need to repipeline it (though no harm is done if you do); you need only to gunzip the files and prepare the data for processing (see §5. However, it is very likely that you will want to filter your data; in this case, you will need to reprocess it in order to determine the appropriate filters. Therefore, we recommend that you rerun the pipeline regardless of the age of your dataset.

But if you decide that reprocessing is unnecessary, you need only to gunzip the files and rename event files for easier handling. For example, for the RGS1 event list,

cp PPS/PiiiiiijjkkR1lEVENLInmmm.FTZ PROC/r1_evt.fits

where

iiiiiijjkk - observation number
l - scheduled (S) or unscheduled (U) obseravtion
n - spectral order number
mmm - source number

As noted in Tables 3.2 and 3.3 you can view images of your data. While the zipped FITS files may need to be unzipped before display in ds9 (depending on the version of ds9), they can be displayed when zipped using fv. As usual, there are some HTML products to help you inspect the data. These have file names of the form:

PPiiiiiijjkkAAAAAA000_0.HTM

where

iiiiiijjkk - Observation number
jj - observation ID - target number in proposal
kk - observation ID - observation number for target
AAAAAA - Group ID (see Table 3.2)

You will find a variety of RGS-specific files in XMM-Newton data sets. Generally there are two of each because there are two RGS instruments. Table 3.3 lists typical file names, their purpose, the file format, and a list of tools that will enable the user to inspect their data. Remember that the INDEX.HTM file will help you navigate.

Various analysis procedures are demonstrated using the Mkn 421 dataset, ObsID 0153950701, which definitely needs to be repipelined. The following procedures are applicable to all XMM-Newton datasets, so it is not required that you use this particular dataset; any observation should be sufficient.

The next two sections (§7.1 and §7.2) will deal with pipelining and filtering RGS data on the command line, respectively. Users who prefer to use the GUI should skip ahead to find the demonstrations for the same tasks with the GUI (§7.3 and §7.4).


7.1 Rerun the Pipeline on the Command Line

We assume that the data was prepared and environment variables were set according to §5. In the window where SAS was initialized, in your ``processing directory'' PROC, run the task rgsproc:

rgsproc orders='1 2' bkgcorrect=no withmlambdacolumn=yes spectrumbinning=lambda

where

orders - dispersion orders to extract
bkgcorrect - subtract background from source spectra?
withmlambdacolumn - include a wavelength column in the event file product
spectrumbinning - accumulate the spectrum either in wavelength or beta space

Note the last keyword, spectrumbinning. If you want to merge data from the same orders in RGS1 and RGS2, keep it at the default value lambda. Merging spectra is discussed in §7.2.6.

This takes several minutes, and outputs 12 files per RGS, plus 3 general use FITS files. At this point, renaming files to something easy to type is a good idea.

ln -s *R1*EVENLI*FIT r1_evt1.fits
ln -s *R2*EVENLI*FIT r2_evt1.fits


7.1.1 Potentially useful tips for using the pipeline

The pipeline task, rgsproc, is very flexible and can address potential pitfalls for RGS users. In §7.1, we used a simple set of parameters with the task; if this is sufficient for your data (and it should be for most), feel free to skip to §7.2, where data filters are discussed. In the following subsections, we will look at the cases of a nearby bright optical source, a nearby bright X-ray source, and a user-defined source.


7.1.2 A Nearby Bright Optical Source

With certain pointing angles, zeroth-order optical light may be reflected off the telescope optics and cast onto the RGS CCD detectors. If this falls on an extraction region, the current energy calibration will require a wavelength-dependent zero-offset. Stray light can be detected on RGS DIAGNOSTIC images taken before, during and after the observation. This test, and the offset correction, are not performed on the data before delivery. To check for stray light and apply the appropriate offsets, type

rgsproc orders='1 2' bkgcorrect=no calcoffsets=yes withoffsethistogram=no

where the parameters are as described in §7.1 and

calcoffsets - calculate PHA offsets from diagnostic images
withoffsethistogram - produce a histogram of uncalibrated excess for the user


7.1.3 A Nearby Bright X-ray Source

In the example above, it is assumed that the field around the source contains sky only. Provided a bright background source is well-separated from the target in the cross-dispersion direction, a mask can be created that excludes it from the background region. Here the source has been identified in the EPIC images and its coordinates have been taken from the EPIC source list which is included among the pipeline products. The bright neighboring object is found to be the third source listed in the sources file. The first source is the target:

rgsproc orders='1 2' bkgcorrect=no withepicset=yes
$   $ epicset=PiiiiiijjkkaablllEMSRLInmmm.FTZ exclsrcsexpr='INDEX==1&&INDEX==3'

where the parameters are as described in §7.1 and

withepicset - calculate extraction regions for the sources contained in an EPIC source list
epicset - name of the EPIC source list, such as generated by emldetect or eboxdetect procedures
exclsrcsexpr - expression to identify which source(s) should be excluded from the background extraction region


7.1.4 User-defined Source Coordinates

If the true coordinates of an object are not included in the EPIC source list or the science proposal, the user can define the coordinates of a new source by typing:

rgsproc orders='1 2' bkgcorrect=no withsrc=yes srclabel=Mkn421 srcstyle=radec
$   $ srcra=166.113808 srcdec=+38.208833

where the parameters are as described in §7.1 and

withsrc - make the source be user-defined
srclabel - source name
srcstyle - coordinate system in which the source position is defined
srcra - the source's right ascension in decimal degrees
srcdec - the source's declination in decimal degrees


7.2 Examine and Analyze the Data on the Command Line

Since the event files are current, we can proceed with some simple analysis demonstrations, which will allow us to generate filters. Rememer that all tasks should be called from the window where SAS was initiated, and that tasks place output files in whatever directory you are in when they are called.


7.2.1 Create and Display an Image

Two commonly-made plots are those showing PI vs. BETA_CORR (also known as ``banana plots'') and XDSP_CORR vs. BETA_CORR.

To create images on the command line, type

evselect table=r1_evt1.fits:EVENTS withimageset=yes
$   $ imageset=pi_bc.fits xcolumn=BETA_CORR ycolumn=PI
$   $ imagebinning=imageSize ximagesize=600 yimagesize=600

where

table - input event table
withimageset - make an image
imageset - name of output image
xcolumn - event column for X axis
ycolumn - event column for Y axis
imagebinning - form of binning, force entire image into a given size or bin by a specified number of pixels
ximagesize - output image pixels in X
yimagesize - output image pixels in Y

Plots comparing BETA_CORR to XDSP_CORR may be made in a similar way. The output files can be viewed by using a standard FITS display, such as ds9 (see Figure 7.1).

Figure 7.1: Plots of PI vs. BETA_CORR (left) and XDSP vs. BETA_CORR (right).

\includegraphics[scale=0.5]{pi_bc.ps} \includegraphics[scale=0.5]{xc_bc.ps}


7.2.2 Create and Display a Light Curve

The background is assessed through examination of the light curve. We will extract a region, CCD9, that is most susceptible to proton events and generally records the least source events due to its location close to the optical axis. Also, to avoid confusing solar flares for source variability, a region filter that removes the source from the final event list should be used. The region filters are kept in the source file product P*SRCLI_*.FIT.

More experienced users should be aware that with SAS 13, the *SRCLI* file's column information changed. rgsproc now outputs an M_LAMBDA column instead of BETA_CORR, and M_LAMBDA should be used to generate the light curve. (The *SRCLI* file that came with the PPS products still contains a BETA_CORR column if you prefer to use that instead.)

To create a light curve, type

evselect table=r1_evt1.fits withrateset=yes rateset=r1_ltcrv.fits
$   $ maketimecolumn=yes timebinsize=100 makeratecolumn=yes
$   $ expression=
$   $ '(CCDNR==9)&&(REGION(P0153950701R1S001SRCLI_0000.FIT:RGS1_BACKGROUND,M_LAMBDA,XDSP_CORR))'

where

table - input event table
withrateset - make a light curve
rateset - name of output light curve file
maketimecolumn - control to create a time column
timebinsize - time binning (seconds)
makeratecolumn - control to create a count rate column, otherwise a count column will be created
expression - filtering criteria

The output file r1_ltcrv.fits can be viewed using dsplot:

dsplot table=r1_ltcrv.fits x=TIME y=RATE &

where

table - input event table
x - column for plotting on the X axis
y - column for plotting on the Y axis

The light curve is shown in Figure 7.2.

Figure 7.2: Background event rate from the RGS1 CCD9 chip. The flares are solar events. The time units are elapsed mission time.

\includegraphics[scale=0.5]{rgs_ltcrv.eps}


7.2.3 Generating the Good Time Interval (GTI) File

Examination of the lightcurve shows that there is a noisy section at the end of the observation, after 1.36975e8 seconds, where the count rate is well above the normal background count rate of $\sim $ 0.05 count/second. There are two procedures that make the GTI file (gtibuild and tabgtigen) that, when applied to the event file in another run of rgsproc, will excise these sections.

The first method, using gtibuild, requires a text file as input. In the first two columns, refer to the start and end times (in seconds) that you are interested in, and in the third column, indicate with either a + or - sign whether that region should be kept or removed. Each good (or bad) time interval should get its own line. In the example case, we would write in our ASCII file (named gti.txt):

1.36958e8 1.36975e8 +

and proceed to the SAS task gtibuild:

gtibuild file=gti.txt table=gti.fits

where

file - intput text file
table - output gti table

Alternatively, we can make the GTI file with tabgtigen and filter for RATE (though we could just as easily filter on TIME):

tabgtigen table=r1_ltcrv.fits gtiset=gti.fits expression='(RATE$<$0.2)'

where

table - the lightcurve file
gtiset - output gti table
expression - the filtering criteria. Since the nominal count rate is 0.05 about count/sec, we have set the upper limit to 0.2 count/sec.


7.2.4 Applying the GTI

Now that we have GTI file, we can apply it to the event file by running rgsproc again. rgsproc is a complex task, running several steps, with five different entry and exit points. It is not necessary to rerun all the steps in the procudure, only the ones involving filtering.

To apply the GTI to the event file, type

rgsproc orders='1 2' auxgtitables=gti.fits bkgcorrect=no
$   $ withmlambdacolumn=yes entrystage=3:filter finalstage=5:fluxing

where

orders - spectral orders to be processed
auxgtitables - gti file in FITS format
bkgcorrect - subtract background from source spectra?
withmlambdacolumn - include a wavelength column in the event file product
entrystage - stage at which to begin processing
finalstage - stage at which to end processing


7.2.5 Creating the Response Matrices (RMFs)

Response matrices (RMFs) are not provided as part of the pipeline product package, so you must create your own before analyzing data. The task rgsproc generates a response matrix automatically, but as noted in §7.1.4, the source coordinates are under the observer's control. The source coordinates have a profound influence on the accuracy of the wavelength scale as recorded in the RMF that is produced automatically by rgsproc, and each RGS instrument and each order will have its own RMF.

Making the RMF is easily done with the package rgsrmfgen. Please note that, unlike with EPIC data, it is not necessary to make ancillary response files (ARFS).

To make the RMFs, type

rgsrmfgen spectrumset=P0153950701R1S001SRSPEC1001.FIT rmfset=r1_o1_rmf.fits
$   $ evlist=r1_evt1.fits emin=0.4 emax=2.5 rows=5000

where

spectrumset - spectrum file
evlist - event file
emin - lower energy limit of the response file
emax - upper energy limit of the response file
rows - number of energy bins; this should be greater than 3000
rmfset - output FITS file

At this point, the spectra can be analyzed. If you you wish, skip the discussion on combining spectra (§7.2.6) and go straight to fitting the spectrum (§7.5.)


7.2.6 Combining Spectra

Spectra from the same order in RGS1 and RGS2 can be safely combined to create a spectrum with higher signal-to-noise if they were reprocessed using rgsproc with spectrumbinning=lambda, as we did in §7.1 (this also happens to be the default). The task rgscombine also merges response files and background spectra. When merging response files, be sure that they have the same number of bins. For this example, we assume that RMFs were made for order 1 in both RGS1 and RGS2.

To merge RGS1 and RGS2 spectra, type

rgscombine pha='P0153950701R1S001SRSPEC1001.FIT P0153950701R2S002SRSPEC1001.FIT'
$   $ rmf='r1_o1_rmf.fits r2_o1_rmf.fits'
$   $ bkg='P0153950701R1S001BGSPEC1001.FIT P0153950701R2S002BGSPEC1001.FIT'
$   $ filepha='r12_o1_srspec.fits' filermf='r12_o1_rmf.fits'
$   $ filebkg='r12_o1_bgspec.fits' rmfgrid=5000

where

pha - list of spectrum files
rmf - list of response matrices
bkg - list of bakcground spectrum files
filepha - output merged spectrum
filermf - output merged response matrix
filebkg - output merged badkground spectrum
rmfgrid - number of energy bins; should be the same as the input RMFs

The spectra are ready for analysis, so skip ahead to prepare the spectrum for fitting (§7.5).


7.3 Rerun the Pipeline with the GUI

We assume that the data was prepared and environment variables were set according to §5. In the window where SAS was initialized, in your ``processing directory'' PROC, invoke the SAS GUI (see Figure 6.10).

On the command line, type

sas &

A window will appear with two panels. The upper one will contain task names, what group they belong to (such as utility, epic, timing, calibration, etc.) and a short description of each. The lower one will contain information about environment variables, and as tasks are invoked, feedback from the tasks.

From the upper window, select rgsproc. As with all SAS tasks in the GUI, double-clicking the task will bring up pop-up windows that will allow you to change the parameters. For rgsproc,

1)
In the ``global'' tab, verify that ``orders'' is set to 1 2 and ``spectrumbinning'' is set to lambda. In the ``angles'' tab, verify that ``withmlambdacolumn'' is set to yes. In the ``spectra'' tab, under the ``rgsspectrum'' sub-tab, verify that ``bkgcorrect'' is set to no.
2)
Click ``Run''.

This takes several minutes, and outputs 12 files per RGS, plus 3 general use FITS files. At this point, renaming files to something easy to type is a good idea. In the following sections, we will refer to the RGS1 event file, P0134520301R1S001EVENLI0000.FIT as r1_evt1.fits.


7.3.1 Potentially useful tips for using the pipeline

The pipeline task, rgsproc, is very flexible and can address potential pitfalls for RGS users. In §7.3, we used a simple set of parameters with the task; if this is sufficient for your data (and it should be for most), feel free to skip to §7.4, where data filters are discussed. In the following subsections, we will look at the cases of a nearby bright optical source, a nearby bright X-ray source, and a user-defined source.


7.3.2 A Nearby Bright Optical Source

With certain pointing angles, zeroth-order optical light may be reflected off the telescope optics and cast onto the RGS CCD detectors. If this falls on an extraction region, the current energy calibration will require a wavelength-dependent zero-offset. Stray light can be detected on RGS DIAGNOSTIC images taken before, during and after the observation. This test, and the offset correction, are not performed on the data before delivery.

To check for stray light and apply the appropriate offsets,

1)
Call rgsproc.
2)
In the ``global'' tab, verify that ``orders'' is set to 1 2 and ``spectrumbinning'' is set to lambda. In the ``angles'' tab, verify that ``withmlambdacolumn'' is set to yes. In the ``spectra'' tab, under the ``rgsspectrum'' sub-tab, verify that ``bkgcorrect'' is set to no.
3)
In the ``events'' tab, under the ``rgsoffsetcalc'' sub-tab, set ``calcoffsets'' to yes and ``withoffsethistogram'' to no.
4)
Click ``Run''.


7.3.3 A Nearby Bright X-ray Source

In the example above, it is assumed that the field around the source contains sky only. Provided a bright background source is well-separated from the target in the cross-dispersion direction, a mask can be created that excludes it from the background region. Here the source has been identified in the EPIC images and its coordinates have been taken from the EPIC source list which is included among the pipeline products. The bright neighboring object is found to be the third source listed in the sources file. The first source is the target:

1)
Call rgsproc.
2)
In the ``global'' tab, verify that ``orders'' is set to 1 2 and ``spectrumbinning'' is set to lambda. In the ``angles'' tab, verify that ``withmlambdacolumn'' is set to yes. In the ``spectra'' tab, under the ``rgsspectrum'' sub-tab, verify that ``bkgcorrect'' is set to no.
3)
In the ``events'' tab, under the ``rgssources'' sub-tab, set ``withepicset'' to yes and ``epicset'' to the name of the EPIC source list as generated by emldetect or eboxdetect. In the ``spectra'' tab, under the ``rgsregions'' sub-tab, set ``exclsrcsexpr'' to INDEX==1&&INDEX==3.
4)
Click ``Run''.


7.3.4 User-defined Source Coordinates

If the true coordinates of an object are not included in the EPIC source list or the science proposal, the user can define the coordinates of a new source.

1)
Call rgsproc.
2)
In the ``global'' tab, verify that ``orders'' is set to 1 2 and ``spectrumbinning'' is set to lambda. In the ``angles'' tab, verify that ``withmlambdacolumn'' is set to yes. In the ``spectra'' tab, under the ``rgsspectrum'' sub-tab, verify that ``bkgcorrect'' is set to no.
3)
In the ``events'' tab, under the ``rgssources'' sub-tab, set ``withsrc'' to yes. Be sure that the box beneath ``withsrc'' is toggled to radec. Next to ``srcra'', enter the RA in decimal degrees, 166.113808 and next to ``srcdec'', enter the declination (again in decimal degrees), +38.208833. Next to ``srclabel'', enter Mkn421.
4)
Click ``Run''.


7.4 Examine and Analyze the Data with the GUI

Since the event files are current, we can proceed with some simple analysis demonstrations, which will allow us to generate filters. Rememer that all tasks should be called from the window where SAS was initiated, and that tasks place output files in whatever directory you are in when they are called.


7.4.1 An Introduction to xmmselect

The task xmmselect is used for many procedures in the GUI. Like all tasks, it can easily be invoked by starting to type the name and pressing enter when it is highlighted.

When xmmselect is invoked a dialog box will first appear requesting a file name. You can either use the browser button or just type the file name in the entry area, ``r1_evts1.fits:EVENTS'' in this case. To use the browser, select the file folder icon; this will bring up a second window for the file selection. Choose ``r1_evts1.fits'', then the ``EVENTS'' extension in the right-hand column, and click ``OK''. The directory window will then disappear and you can click ``Run'' on the selection window.

When the file name has been submitted the xmmselect GUI (see Figure 7.3) will appear. (Later, when loading an event file that has been filtered, the filters that have been applied to that point will appear in the selection expression area.)

Figure 7.3: The xmmselect GUI.
\begin{figure}
\centerline{\psfig{file=xmmselect_rgs.eps,width=5in}}
\end{figure}


7.4.2 Create and Display an Image

Two commonly-made plots are those showing PI vs. BETA_CORR (also known as ``banana plots'') and XDSP_CORR vs. BETA_CORR.

To create images,

1)
Check the square boxes to the left of the ``BETA_CORR'' and ``PI'' entries.
2)
Click on the ``Image'' button near the bottom of the page. This brings up the evselect GUI.
3)
Click on the ``Image'' tab in the evselect GUI.
4)
Confirm that the withimageset box is checked.
5)
In the imageset box, change the output image name from image.ds to something descriptive, in this case, pi_bc.fits.
6)
Click on the ``Run'' button on the lower left corner of the evselect GUI.

Different binnings and other selections can be invoked by accessing the ``Image'' tab at the top of the GUI. The default settings are reasonable, however, for a basic image. The resultant image is automatically displayed using ds9. Similarly, plots can be made comparing BETA_CORR to XDSP_CORR. These two example plots can be seen in Figure 7.4.

Figure 7.4: Plots of PI vs. BETA_CORR (left) and XDSP vs. BETA_CORR (right).

\includegraphics[scale=0.5]{pi_bc.ps} \includegraphics[scale=0.5]{xc_bc.ps}


7.4.3 Create and Display a Light Curve

The background is assessed through examination of the light curve. We will extract a region, CCD9, that is most susceptible to proton events and generally records the least source events due to its location close to the optical axis. Also, to avoid confusing solar flares for source variability, a region filter that removes the source from the final event list should be used. The region filters are kept in the source file product P*SRCLI_*.FIT. (For our example data, this would be P0134520301R1S001SRCLI_0000.FIT).

More experienced users should be aware that with SAS 13, the *SRCLI* file's column information changed. rgsproc now outputs an M_LAMBDA column instead of BETA_CORR, and M_LAMBDA should be used to generate the light curve. (The *SRCLI* file that came with the PPS products still contains a BETA_CORR column if you prefer to use that instead.)

To create light curves,

1)
Enter the filtering criteria in the ``Selection expression'' box at the top of the xmmselect GUI:
(CCDNR==9)&&(REGION(P0153950701R1S001SRCLI_0000_PPS.FIT:RGS1_BACKGROUND,M_LAMBDA,XDSP_CORR))
2)
Check the round box to the left of the time entry.
3)
Click on the ``OGIP Rate Curve'' button near the bottom of the page. This brings up the evselect GUI.
4)
Click on the ``Lightcurve'' tab and confirm that the withrateset box is checked.
5)
Change the timebinsize to a reasonable amount, e.g. 10 or 100 s, and change the default output file name in the rateset box to something appropriate, in this case, r1_ltcrv.fits.
6)
Click on the ``Run'' button at the lower left corner of the evselect GUI.

The resultant light curve is displayed automatically using Grace and is shown in Figure 7.5.

Figure 7.5: Background event rate from the RGS1 CCD9 chip. The flares are solar events. The time units are elapsed mission time.

\includegraphics[scale=0.5]{rgs_ltcrv.eps}


7.4.4 Generating the Good Time Interval (GTI) File

Examination of the lightcurve shows that there is a noisy section at the end of the observation, after 1.36975e8 seconds, where the count rate is well above the normal background count rate of $\sim $ 0.05 count/second. There are two procedures that make the GTI file (gtibuild and tabgtigen) that, when applied to the event file in another run of rgsproc, will excise these sections.

The first method, using gtibuild, requires a text file as input. In the first two columns, refer to the start and end times (in seconds) that you are interested in, and in the third column, indicate with either a + or - sign whether that region should be kept or removed. Each good (or bad) time interval should get its own line. In the example case, we would write in our ASCII file (named gti.txt):

1.36958e8 1.36975e8 +

and proceed to the SAS task gtibuild:

1)
Call the gtibuild task in the SAS GUI.
2)
Enter the name of the text file in the file box.
3)
Enter the name of the output fits file in the table box.
4)
Click ``Run''.

Alernatively, we can make the GTI file with tabgtigen and filter on RATE (though we could just as easly filter on TIME):

1)
Call the tabgtigen task.
2)
Enter the name of the lightcurve file in the table box, in this case, r1_ltcrv.fits.
3)
Enter the name of the output file in the gtiset box, in this case, gti.fits.
4)
Enter the filtering expression in the expression box. Since the nominal count rate is about 0.05 count/sec, we will set the upper limit to 0.2 count/sec: RATE$<$0.2
5)
Click ``Run''.


7.4.5 Applying the GTI

Now that we have GTI file, we can apply it to the event file by running rgsproc again. rgsproc is a complex task, running several steps, with five different entry and exit points. It is not necessary to rerun all the steps in the procudure, only the ones involving filtering.

To apply the GTI to the event file,

1)
Call the rgsproc in the SAS GUI.
2)
In the ``global'' tab, make sure that the orders box is set for both orders, 1 2 . Use the pulldown menus for entrystage and exitstage to select 3:filter and 5:fluxing, respectively.
3)
In the ``filter'' tab, enter the name of the GTI file, in this case, gti.fits, in the auxgtitables box.
4)
In the ``spectra'' tab, click on the ``rgsspectrum'' tab, and make sure that bkgcorrect is set to no.
5)
In the ``angles'' tab, make sure the withmlambda column is set to yes.
6)
Click ``Run''.


7.4.6 Creating the Response Matrices (RMFs)

Response matrices (RMFs) are not provided as part of the pipeline product package, so you must create your own before analyzing data. The task rgsproc generates a response matrix automatically, but as noted in §7.3.4, the source coordinates are under the observer's control. The source coordinates have a profound influence on the accuracy of the wavelength scale as recorded in the RMF that is produced automatically by rgsproc, and each RGS instrument and each order will have its own RMF.

Making the RMF is easily done with the package rgsrmfgen. Please note that, unlike with EPIC data, it is not necessary to make ancillary response files (ARFS).

To make the RMFs,

1)
Call the rgsrmfgen task in the GUI.
2)
In the spectrumset box, enter the name of the spectrum file; it has the form *SRSPEC*.
3)
In the evlist box, enter the name of the event list, r1_evt1.fits.
4)
Set emin to 0.4, emax to 2.5, and rows to 5000.
5)
Set rmfset to the output file name, in this case, r1_o1_rmf.fits.
6)
Click ``Run''.

At this point, the spectra can be analyzed. If you wish, skip the discussion on combining spectra (§7.4.7) and go straight to fitting the spectrum (§7.6.)


7.4.7 Combining Spectra

Spectra from the same order in RGS1 and RGS2 can be safely combined to create a spectrum with higher signal-to-noise if they were reprocessed using rgsproc with spectrumbinning=lambda, as we did in §7.3 (this also happens to be the default). The task rgscombine also merges response files and background spectra. When merging response files, be sure that they have the same number of bins.

To merge RGS1 and RGS2 spectra,

1)
Call the rgscombine task.
2)
In the pha box, enter the spectrum files to combine, seperated by a space:
P0153950701R1S001SRSPEC1001.FIT P0153950701R2S002SRSPEC1001.FIT.
3)
In the bkg box, enter the corresponding background files,
P0153950701R1S001BGSPEC1001.FIT P0153950701R2S002BGSPEC1001.FIT.
4)
In the rmf box, enter the response files, r1_o1_rmf.fits r2_o1_rmf.fits.
5)
In the filepha box, enter the output merged spectrum, r12_o1_srspec.fits. In the filermf box, enter the output merged response files, r12_o1_rmf.fits. In the filebkg box, enter the output merged background spectrum, r12_o1_bgspec.fits.
6)
Set the rmfgrid parameter to the same as that used to make the RMFs, 5000.
7)
Click ``Run''.

The spectra are ready for analysis, so we can now prepare the spectrum for fitting.


7.5 Approaches to Spectral Fitting and the Cash Statistic

For data sets of high signal-to-noise and low background, where counting statistics are within the Gaussian regime, the data products above are suitable for analysis using the default fitting scheme in XSPEC, $\chi^2$-minimization. However, for low count rates, in the Poisson regime, $\chi^2$-minimization is no longer suitable. With low count rates in individual channels, the error per channel can dominate over the count rate. Since channels are weighted by the inverse-square of the errors during $\chi^2$ model fitting, channels with the lowest count rates are given overly-large weights in the Poisson regime. Spectral continua are consequently often fit incorrectly, with the model lying underneath the true continuum level. This will be a common problem with most RGS sources. Even if count rates are large, much of the flux from these sources can be contained within emission lines, rather than the continuum. Consequently, even obtaining correct equivalent widths for such sources is non-trivial.

The traditional way to increase the signal-to-noise of a data set is to rebin or group the channels, since, if channels are grouped in sufficiently large numbers, the combined signal-to-noise of the groups will jump into the Gaussian regime. However, this results in the loss of information. For example, sharp features like an absorption edge or emission line can be completely washed out. Further, in the Poisson regime, the background spectrum cannot simply be subtracted, as is commonly done in the Gaussian regime, since this could result in negative counts. Therefore, rebinning should be reserved for fast, preliminary analysis of spectra without sharp features, or for making plots for publication. When working on the final analysis for a low-count data set, the (unbinned) background and source spectra should be fitted simultaneously using the Cash statistic. (If fitting with XSPEC, be sure you are running v11.1.0 or later. This is because RGS spectrum files have prompted a slight modification to the OGIP standard, since the RGS spatial extraction mask has a spatial-width which is a varying function of wavelength. Thus, it has become necessary to characterize the BACKSCL and AREASCL parameters as vectors (i.e., one number for each wavelength channel), rather than scalar keywords as they are for data from the EPIC cameras and past missions. These quantities map the size of the source extraction region to the size of the background extraction region and are essential for accurate fits. Only Xspec v11.1.0, or later versions, are capable of reading these vectors, so be certain that you have an up-to-date installation at your site.)

Finally, a caveat of using the Cash statistic in Xspec is that the scheme requires a ``total'' and ``background'' spectrum to be loaded into Xspec. This is in order to calculate parameter errors correctly. Consequently, be sure not to use the ``net'' spectra that were created as part of product packages by SAS v5.2 or earlier. To change schemes in Xspec before fitting the data, type:

XSPEC$>$ statistic cstat

For our sample spectrum, we will rebin and fit it with $\chi^2$ statistics.


7.5.1 Spectral Rebinning

There are two ways to rebin a spectrum: the FTOOL grppha, or the RGS pipeline. grppha can group channels using an algorithm which bins up consecutive channels until a count rate threshold is reached. This method conserves the resolution in emission lines above the threshold while improving statistics in the continuum.

To rebin the spectrum with grppha, type

grppha

and edit the parameters as needed:

   > Please enter PHA filename[] P0153950701R1S001SRSPEC1001.FIT
   > Please enter output filename[] P0153950701R1S001SRSPEC1001.bin30.FIT
   > GRPPHA[] group min 30 
   > GRPPHA[] exit

The disadvantage of using grppha is that, although channel errors are propagated through the binning process correctly, the errors column in the original spectrum product is not strictly accurate. The problem arises because there is no good way to treat the errors within channels containing no counts. To allow statistical fitting, these channels are arbitrarily given an error value of unity, which is subsequently propagated through the binning. Consequently, the errors are overestimated in the resulting spectra.

The other approach, which involves calling the RGS pipeline after it is complete, bins the data during spectral extraction. The following rebins the pipeline spectrum by a factor 3.

To rebin the spectrum with rgsproc, type

rgsproc orders='1 2' rebin=3 rmfbins=5000 entrystage=4:spectra
$   $ finalstage=5:fluxing bkgcorrect=no

where

orders - dispersion orders to extract
rebin - wavelength rebinning factor
rmfbins - number of bins in the response file; this should be greater than 3000
entrystage - entry stage to the pipeline
finalstage - exit stage for the pipeline

One disadvantage of this approach is that you can only choose integer binning of the original channel size. To change the sampling of the events, the pipeline must be run from the second stage (``angles'') or earlier:

rgsproc orders='1 2' nbetabins=1133 rmfbins=5000 entrystage=2:angles
$   $ finalstage=fluxing bkgcorrect=no

where the parameters are as defined previously, and

nbetabins - number of bins in the dispersion direction; the default is 3400

The disadvantage of using rgsproc, as opposed to grppha, is that the binning is linear across the dispersion direction. Velocity resolution is lost in the lines, so the accuracy of redshift determinations will be degraded, transition edges will be smoothed, and neighboring lines will become blended.


7.6 Fitting a Spectral Model

SAS does not include fitting software, so HEASoft packages will be used, and all fitting tasks will be called from the command line. Now that we have a response file, we can fit the spectrum using Xspec. We will use the unmerged files for this demonstration. (If you are using data from a low-count data set, make sure you are using Xspec v 11.1.0 or later and see §7.5.)

To fit the spectrum, type

xspec

Enter the data, background, and response file at the prompts, and edit the fitting parameters as needed. Please note that in this example, we are using the output from rgsproc, not the PPS data that came with the data set, so the names are slightly different. If we were using the PPS data, the input spectrum would be *SBSPEC*. Since we did not include background correction when we ran rgsproc, we can correct for it now.

      XSPEC> data P0153950701R1S001SRSPEC1001.bin30.FIT ! input data 
      XSPEC> back P0153950701R1S001BGSPEC1001.bin30.FIT ! input background
      XSPEC> resp r1_o1_rmf.fits                        ! input response file
      XSPEC> ignore **-0.4                              ! set sensible limits
      XSPEC> model wabs*pow                             ! set spectral model to absorbed powerlaw
      1:wabs:nH> 0.01                                   ! enter reasonable initial values
      2:powerlaw:PhoIndex>2.0
      3:powerlaw:norm>1.0
      XSPEC> renorm
      XSPEC> fit
      XSPEC> cpd /xw
      XSPEC> setplot wave
      XSPEC> setplot command window all
      XSPEC> setplot command log x off
      XSPEC> setplot command wind 1
      XSPEC> setplot command r y 0 6e-17
      XSPEC> setplot command wind 2
      XSPEC> setplot command r y -10 10
      XSPEC> plot data chi
      XSPEC> exit

Figure 7.6 shows the fit to the spectrum.

Figure 7.6: 1st order RGS1 spectrum of Mkn 421. The fit is an absorbed power law model. The gap between 10-15Å is due to the absence of CCD7.

\includegraphics[scale=0.5]{Mkn421_rgs_xspec_bin30.eps}


7.7 Analysis of Extended Sources


7.7.1 Region masks

The optics of the RGS allow spectroscopy of reasonably extended sources, up to a few arc minutes. The width of the spatial extraction mask is defined by the fraction of total events one wishes to extract. With the default pipeline parameter values, 90% of events are extracted, assuming a point-like source.

Altering and optimizing the mask width for a spatially-extended source may take some trial and error, and, depending on the temperature distribution of the source, may depend on which lines one is currently interested in. While Mkn 421 is not an extended source, the following example increases the width of the extraction mask and ensures that the size of the background mask is reduced so that the two do not overlap.

Observing extended sources effectively broadens the psf of the spectrum in the dispersion direction. Therefore, it is prudent to also increase the width of the PI masks using the pdistincl parameter in order to prevent event losses.

To adjust the region mask with rgsproc from the command line, type

rgsproc orders='1 2' entrystage=4:spectra finalstage=5:fluxing bkgcorrect=no
$   $ xpsfincl=99 xpsfexcl=99 pdistincl=95

where

xpsfincl - include this fraction of point-source events inside the spatial source extraction mask
xpsfexcl - exclude this fraction of point-source events from the spatial background extraction mask
pdistincl - include this fraction of point-source events inside the pulse height extraction mask

Alternatively, to do the same in the SAS GUI,

1)
Call rgsproc.
2)
In the ``global'' tab, make sure that the orders box is set for both orders, 1 2.
3)
In the ``global'' tab, use the pulldown menus for entrystage and exitstage to select 4:spectra and 5:fluxing, respectively.
4)
In the ``spectra'' tab, in the ``rgsregions'' sub-tab, set both xpsfincl and xpsfexcl to 99, and pdistincl to 95.
5)
Click ``Run''.


7.7.2 Fitting spectral models to extended sources

RGS response matrices are consistent for point sources only. Since extended source spectra are broadened, the simplest way to deal with this problem during spectral fitting is to reproduce the broadening function, and convolve it across the spectral model. Xspec v11.2 and later contains the convolution model rgsxsrc. It requires two external files to perform the operation:

1)
An OGIP FITS image of the source. The better the resolution of the image, the more accurate the convolution. For example, if a Chandra image of the source is available, this will provide a more accurate result than an EPIC image.

2)
An ASCII file containing three lines of input. For this example case, we will name it xsource.mod. It defines three environment variables and should look like this example:
RGS_XSOURCE_IMAGE ./MOS1.fit
RGS_XSOURCE_BORESIGHT 23:25:19.8 -12:07:25 247.302646
RGS_XSOURCE_EXTRACTION 2.5

where

RGS_XSOURCE_IMAGE - path to the source image
RGS_XSOURCE_BORESIGHT - RA, Dec of the center of the source and PA of the telescope
RGS_XSOURCE_EXTRACTION - The extent (in arcmin), centered on the source, over which you want to construct the convolution function. You want this ``aperture'' to be larger than the source itself.

To set these environment variables within Xspec execute the command:

xset rgs_xsource_file xsource.mod

Here is an example. Note that the spectral order is always negative.

xspec

       XSPEC>data P0108460201R1S004SRSPEC1003.FIT  
       XSPEC>ignore bad 
       XSPEC>xset rgs_xsource_file xsource.mod 
       XSPEC>model rgsxsrc*wabs*mekal 
       rgsxsrc:order>-1 
       wabs:nH>1 
       mekal:kT>2 
       mekal:nH>1 
       mekal:Abundanc>1 
       mekal:Redshift> 
       mekal:Switch>0 
       mekal:norm>1 
       XSPEC>renorm 
       XSPEC>fit 
       XSPEC>setplot device /xs 
       XSPEC>setplot wave 
       XSPEC>setplot command window all 
       XSPEC>setplot command log x off 
       XSPEC>plot data residuals 
       XSPEC>exit 
       Do you really want to exit? (y)y

Figure 7.7 compares a point source model with an extended source counterpart.

Figure 7.7: The top figure is a thin, thermal plasma at 2 keV from a point source. The lower figure is the same spectral model, but convolved by the MOS1 0.3-2.0 keV spatial profile of a low-redshift cluster.
\begin{figure}
\vspace{5mm}
\centerline{\psfig{file=pntsrc.ps,angle=270,w...
...pace{5mm}
\centerline{\psfig{file=extsrc.ps,angle=270,width=3in}}
\end{figure}


7.7.3 Model limitations

Users should be aware that this method assumes an isothermal source (or uniform emissivity from line to line in the case of a non-thermal spectrum) where the spatial distributions of all the lines are identical. In reality, however, the thermal structure of the source is likely to be more complicated. The broad-band convolution function may bear little resemblance to the correct function for particular line transitions.

One way around this problem would be to have a temperature map of the source to define line emissivity across the source and convolve the model spectrum accordingly. The RGS instrument team at the Columbia Astrophysics Laboratory are developing a Monte Carlo code to perform an operation with this effect. While it is unlikely the code will be publicly available in the near future, the team welcomes investigators who would be interested in collaboration. Interested parties are encouraged to contact John Peterson (jrpeters@astro.columbia.edu).


next up previous contents
Next: 8. An OM Data Up: XMM ABC Guide Previous: 6. An EPIC Data   Contents
Lynne Valencic 2014-04-17