Before beginning this chapter please consult the ``watchout'' page at the VILSPA SOC:
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 3.
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 reprocess it (though no harm is done if you do). 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,
where
where
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.
You will need to reprocess the data before being able to determine the appropriate filters, but before doing that, you must prepare the data and initialize SAS. Throughout this primer, we will use the AB Dor dataset with ObsID 0134520301 available through links at the HEASARC archive.
where
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.
Once the new event files have been obtained, the analysis techniques described in §6.3 and later can be used.
The pipeline task, rgsproc, is very flexible and can address potential pitfalls for RGS users. In §6.1, we used a simple set of parameters with the task, and if this is sufficient for your data, feel free to skip to §6.3. In the following sections, we will look at the cases of a nearby bright optical source, a nearby bright X-ray source, and a user-defined 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 use, type
where the parameters are as described in §6.1 and
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:
epicset=PiiiiiijjkkaablllEMSRLInmmm.FTZ exclsrcsexpr='INDEX==1&&INDEX==3'
where the parameters are as described in §6.1 and
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:
srcra=82.185493 srcdec=-65.449329
where the parameters are as described in §6.1 and
We are now ready to invoke the SAS GUI if we have not already done so. Make sure that you are in the directory where you want the output to go before invoking the SAS GUI or any of the SAS tasks on the command line!
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 by using the xmmselect GUI:
To create images by using the task evselect on the command line:
imageset=pi_bc.fits xcolumn=BETA_CORR ycolumn=PI
imagebinning=imageSize ximagesize=600 yimagesize=600
where
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 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).
To create light curves of the observation by using the xmmselect GUI:
To create a light curve of the observation by using the task evselect on the command line:
maketimecolumn=yes timebinsize=100 makeratecolumn=yes
expression=
'(CCDNR==9)&&(REGION(P0134520301R1S001SRCLI_0000.FIT:RGS1_BACKGROUND,BETA_CORR,XDSP_CORR))'
where
The light curve is shown in Figure 6.1.
 |
Examination of the lightcurve shows that there are two noisy sections,
one between 9.6405e7 and 9.6413e7 seconds, and another between 9.6422e7
and 9.6425e7 seconds. Both show rates well in excess of the normal background
count rate of 
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. In the example case,
then, we would write in our ASCII file (named gti.txt):
9.6405e7 9.6413e7 -
9.6422e7 9.6425e7 -
and proceed to the SAS task gtibuild.
To make the GTI with gtibuild in the SAS GUI:
To make the GTI with gtibuild on the command line:
where
To make the GTI with tabgtigen in the SAS GUI:
0.2
To make the GTI with tabgtigen from the command line:
0.2)'
where
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 rerun the pipeline in the SAS GUI:
To rerun the pipeline from the command line:
withmlambdacolumn=yes entrystage=3:filter finalstage=5:fluxing
where
Response matrices (RMFs) are not provided as part of the pipeline product package, so you must create your
own before analyzing data. This can be done with the package rgsrmfgen.
To make the RMFs using the GUI:
To make the RMFs from the command line:
evlist=r1_evt1.fits emin=0.4 emax=2.5 rows=5000
where
Now that we have a response file, we can fit the spectrum using Xspec.
Enter the data, background, and response file at the prompts, and edit the fitting parameters as needed.
XSPEC> data P0136540101R1S001SRSPEC1003.FIT ! input data
XSPEC> back P0136540101R1S001BGSPEC1003.FIT ! input background
XSPEC> resp r1_o1_rmf.fits ! input response file
XSPEC> model wabs*mekal ! set spectral model to absorbed mekal
wabs:nH> 1
mekal:kT> 1
mekal:nH>
mekal:Anbundanc> .4
mekal:Redshift>
mekal:Switch> 0
mekal:norm> 1
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 1e-5 1.6
XSPEC> setplot command wind 2
XSPEC> setplot command r y -9.99 9.99
XSPEC> plot data residuals
XSPEC> exit
Figure 6.2 shows the fit to the spectrum.
 |
While it is tempting to merge the RGS1 and RGS2 data, or data from different pointings, to provide a single spectrum with a signal-to-noise improvement over either individual spectrum, this is strongly discouraged since it results in data degradation.
The pointings of the two instruments are not identical, resulting in different dispersion angles and wavelength scales. Separate response files are always required for each unit. While it is possible to merge spectra and response files, great care must be taken to account for different exposure times, background subtractions, error propagation, and so on. However, the resulting response will always have inferior resolution to the originals. It is therefore simpler and more accurate to keep data from the two RGS units separate and use both sets to fit one model in tandem.
XSPEC>data 1:1 P0136540101R1S001SRSPEC1003.FIT 1:2 P0136540101R1S001SRSPEC2003.FIT
XSPEC>ignore bad
XSPEC>model phabs*mekal
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, 
-minimization. However, for
low count rates, in the Poisson regime, -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
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. There are two approaches to fitting low signal-to-noise RGS data, spectral rebinning and maximum-likelihood statistics. The correct approach would normally be to use an optimization of the two.
By grouping channels in appropriately large numbers, the combined signal-to-noise of groups will jump into the Gaussian regime. There are two ways to do this: 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.
> Please enter PHA filename[] P0136540101R1S001SRSPEC1003.FIT
> Please enter output filename[] P0136540101R1S001SRSPEC1003.bin.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.
finalstage=5:fluxing bkgcorrect=no
where
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.
finalstage=fluxing bkgcorrect=no
where the parameters are as defined previously, and
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.
The second method is to replace the -minimization scheme with the Cash
maximum-likelihood scheme (cstat in Xspec) when fitting data. This method is much
better suited to data with low count rates and is a suitable option only if one
is running Xspec v11.1.0 or later. The reason for this is that RGS spectrum files
have prompted a slight modification to the OGIP standard. Because the RGS spatial
extraction mask has a spatial-width which is a varying function of wavelength, 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.
One caveat of using the cstat option 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:
statistic cstat
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
AB Dor 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.
To adjust the region mask with rgsproc in the SAS GUI:
To adjust the region mask with rgsproc from the command line:
xpsfincl=99 xpsfexcl=99 pdistincl=95
where parameters are as they were decsribed previously, and
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.
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 contains the convolution model rgsxsrc. It requires two external files to perform the operation:
where
To set these environment variables within Xspec execute the command:
Here is an example. Note that the spectral order is always negative.
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 6.3 compares a point source model with an extended source counterpart.
 |
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).
To summarize, the steps you must take to prepare your data for analysis are: