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 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. It is also assumed that the data have been prepared for processing by running the tasks in §5, whether you choose to repipeline your data or not. We will use the AB Dor dataset (ObsID 0134520301), available through links at the HEASARC archive, will be used throughout this portion of the primer.
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). 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,
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.
The AB Dor observation definitely needs to be repipelined. 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:
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. If you want to merge data from different orders, but the same RGS, change it to beta. Merging spectra is discussed in §7.4.7.
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.
The pipeline task, rgsproc, is very flexible and can address potential pitfalls for RGS users. In §7.2, we used a simple set of parameters with the task, and if this is sufficient for your data, feel free to skip to §7.4. 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 §7.2 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:
where the parameters are as described in §7.2 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:
where the parameters are as described in §7.2 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 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.1.
To create images on the command line:
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).
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:
The resultant light curve is displayed automatically using Grace (see Figure 7.2).
To create a light curve of the observation by using the task evselect on the command line:
The light curve is shown in Figure 7.2.
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:
To make the GTI with tabgtigen in the SAS GUI:
To make the GTI with tabgtigen from the command line:
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:
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.) This can be done with the package rgsrmfgen.
Please note that it is not necessary to make ancillary response files (ARFS).
To make the RMFs using the GUI:
To make the RMFs from the command line:
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. Data from different
orders from the same RGS can be merged if they were reprocessed with
spectrumbinning=beta. 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 from the command line:
Now that we have a response file, we can fit the spectrum using Xspec. For this demonstration, we will use the unmerged files.
Enter the data, background, and response file at the prompts, and edit the fitting parameters as needed.
XSPEC> data P0136540101R1S001SBSPEC1003.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 7.3 shows the fit to the spectrum.
To fit one model to the two RGS units 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.
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.
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:
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:
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:
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 7.4 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 (firstname.lastname@example.org).
To summarize, the steps you must take to prepare your data for analysis are: