How to reduce RGS data and extract spectra of point-like sources
This thread contains a step-by-step recipe to process RGS data of
point-like sources to produce spectra and the associated response
matrices.
Throughout this thread it is assumed that the 10-digit Observation
Id. is
xxxxxxyyyy (proposal number
xxxxxx -the first
6 digits, observation
yyyy, the last 4 digits) while RGS
exposure identifier is
eeee (first character either
S for 'scheduled', or
U for 'unscheduled', last 3
eee characters is a number from
001 to
999).
R1 in file names refers to RGS1 exposures,
R2 to RGS2. The files generated by the Pipeline Processing
Subsystem, PPS, are named accordingly,
e.g.
PxxxxxxyyyyR1eeeeEVENLI0000.FIT is used for the filtered
RGS1 event list.
- Set up your SAS environment as described in the
SAS-startup thread
- Check the version of the SAS used to generate the PPS products
(e.g. end of keyword CREATOR in the primary header of any
pipeline file, or look for the 'Configuration Info' in the
XMM-Newton Science Archive)
against the current SAS version in
http://xmm.esac.esa.int/sas/
- If the PPS version is lower than the current one, you should run
rgsproc,
the interactive version of the RGS pipeline to reprocess the data:
rgsproc
Allow enough time for it to finish. It may take between 5-10 minutes
depending on the ODF size and your computer. It may be wise and to
redirect the output to a log file:
rgsproc -V 5 >& my_rgsproc_logfile
The task can redo different stages of processing without starting from
scratch. The different entry and exit points are called processing
stages, of which there are five:
- 1:events: preliminary tasks, source-independent calibrations
- 2:angles: aspect-drift corrections
- 3:filter: filter events and exposure
- 4:spectra: generate spectra
- 5:fluxing: generate response matrices and a combined flux-calibrated spectrum
The default entry and final stages are
1:events and
5:fluxing, respectively.
The resulting files are created in the working directory. If the task
has been run as far as the
fluxing stage the resulting files
would be for RGS1:
| PxxxxxxyyyyR1eeeeEVENLI0000.FIT |
event list |
| PxxxxxxyyyyR1eeeeSRSPEC1001.FIT |
source+background first order spectrum |
| PxxxxxxyyyyR1eeeeBGSPEC1001.FIT |
background first order spectrum |
| PxxxxxxyyyyR1eeeeSRSPEC2001.FIT |
source+background second order spectrum |
| PxxxxxxyyyyR1eeeeBGSPEC2001.FIT |
background second order spectrum |
| PxxxxxxyyyyR1eeeeSRCLI_0000.FIT |
source list |
| PxxxxxxyyyyR1eeeeRSPMAT1000.FIT |
first order response matrix |
| PxxxxxxyyyyR1eeeeRSPMAT2000.FIT |
second order response matrix |
| PxxxxxxyyyyOBX000fluxed1000.FIT |
combined fluxed first order spectrum |
| PxxxxxxyyyyOBX000fluxed2000.FIT |
combined fluxed second order spectrum |
If the task has only been run through
spectra neither the
response matrices nor the fluxed spectra are created. Note that the
last stage (
5:fluxing) is the most time consuming, and
therefore it is recommended to run it only once the results of the
previous stages are satisfactory.
Is any further processing required?
- Check validity of prime source coordinates
The accuracy of the rgsproc results
depends critically on the accuracy of the coordinates used for the
prime source, i.e., the source used to compute corrections for
spacecraft attitude variations in the dispersion coordinate (or
beta channel).
If you have run previously rgsproc, there will be two sets of
coordinates in your source list: PROPOSAL and
ONAXIS. The first one gets the position from the target
coordinates as given in the proposal and is, by default, the prime
source. The second one is calculated from the spacecraft attitude. If
you are working with the PPS files, then your source lists are
probably longer because, in the PPS, the EPIC sources are added to
the RGS source list. Also, in the PPS, the prime source is chosen as
the brightest of the EPIC sources within the RGS field of view.
By default the prime source is the only one for which an spectrum is
extracted and the only one excluded from the background extraction
region.
Care should be taken that the target whose spectrum you are
interested in is selected as prime in the source list and that its
coordinates are correct.
- Open the source list with e.g. fv:
fv PxxxxxxyyyyR1eeeeSRCLI_0000.FIT
and check that the coordinates of the 'PROPOSAL' source are
correct. If this is not the case, please go to the
rgsproc: coordinates and masks thread.
- Display the dispersion versus cross dispersion and dispersion
versus energy images and overlay the selected region masks.
evselect table='PxxxxxxyyyyR1eeeeEVENLI0000.FIT:EVENTS' \
imageset='my_spatial.fit' xcolumn='BETA_CORR' ycolumn='XDSP_CORR'
evselect table='PxxxxxxyyyyR1eeeeEVENLI0000.FIT:EVENTS' \
imageset='my_pi.fit' xcolumn='BETA_CORR' ycolumn='PI'\
yimagemin=0 yimagemax=3000 \
expression='REGION(PxxxxxxyyyyR1eeeeSRCLI_0000.FIT:RGS1_SRC1_SPATIAL,BETA_CORR,XDSP_CORR)'
rgsimplot endispset='my_pi.fit' spatialset='my_spatial.fit' \
srcidlist='1' srclistset='PxxxxxxyyyyR1eeeeSRCLI_0000.FIT' \
device=/xs
The corresponding plots can also be found in the PPS files under
the names PxxxxxxyyyyR1eeeeIMAGE_0000.PNG and
PxxxxxxyyyyR1eeeeORDIMG0000.PNG, for the spatial and order
images with overlaid sources and masks, respectively. Therefore, in
case you are directly working with PPS files, you do not need to
generate the plots yourself.
In case the plot does not look fine, you may want to select a
different source as prime, define new source(s) and/or new
source-inclusion and background-exclusion regions. Please refer to the
rgsproc: coordinates and masks thread.
It is very important to check that all the sources in the RGS
exposures have been correctly identified and that the
event-selection regions centered on each source, or extraction
masks, are correctly defined. It is also important to check that
the region used for background extraction correctly excludes the
existing sources.
- Is my observation affected by high background? If yes, how can
I filter out the high-background time intervals?
In common with the other XMM-Newton instruments, RGS observations can
be affected by high particle background periods caused by solar
activity. The particles are most probably soft protons being focused
by the mirrors and gratings. You should check your observations and,
if necessary, filter out these periods before extracting any
scientific products.
- Create a light curve of the pure background events:
evselect table=PxxxxxxyyyyR1eeeeEVENLI0000.FIT timebinsize=100 \
rateset=my_rgs1_background_lc.fit \
makeratecolumn=yes maketimecolumn=yes \
expression='(CCDNR==9)&&(REGION(PxxxxxxyyyyR1eeeeSRCLI_0000.FIT:RGS1_BACKGROUND,BETA_CORR,XDSP_CORR))'
dsplot table=my_rgs1_background_lc.fit x=TIME y=RATE
where timebinsize is the time binning (in seconds) of the
light curve and makeratecolumn set to yes is used
to create a column RATE (giving count rates in counts/sec per time
bin) in the output file. If it was set to no then a COUNTS
column would be created instead, with total number of counts per
bin.
The first part of the expression in the
evselect task indicates that only events
in CCD number 9 are selected (it is the one closest to the optical
axis of the telescope, therefore the most affected by background
flares). The second expression makes use of the background region
already generated by rgsregions
when called by rgsproc to get rid of genuine target variations.
Check the created light curve as displayed with
dsplot for 'flares' with much larger
count rates than the average . If such flares are visible, they can
be filtered out using good time interval tables.
- If necessary, create a good time interval table:
Good Time Intervals, GTI, are the set of time intervals in which a
given scientific product is accumulated. RGS event lists have one
GTI extension for each chip generated by
rgsproc. These GTI tables define
good periods based on the attitude and housekeeping data included on
the ODF.
You can construct an extra GTI table for filtering periods of high
background out of the event list to be used in conjunction with its
internal GTI tables:
tabgtigen table=my_rgs1_background_lc.fit gtiset=my_low_back.fit expression='(RATE<r)'
The expression in the tabgtigen task indicates that only
periods with count rates less than r counts/sec should be
selected. The value of r should be chosen after inspection of
the background light curve, typically from 0.1 to 2 counts/sec.
- Re-process the data with rgsproc starting at the
filter stage.
The filter stage needs a combined event list as input. The
expected name for this file is
PxxxxxxyyyyR1eeeemerged0000.FIT. If you have run
rgsproc already, such a file has
been created and it is already in your working directory. If you are
instead working with the PPS products, the provided filtered event
list is still a valid combined event list and can be used as input
for rgsproc entrystage=3:filter. You should first copy it to a new
file with the appropriate name:
cp PxxxxxxyyyyR1eeeeEVENLI0000.FIT PxxxxxxyyyyR1eeeemerged0000.FIT
and now you can interactively process the data with:
rgsproc entrystage=3:filter auxgtitables=my_low_back.fit
or with:
rgsfilter mergedset=PxxxxxxyyyyR1eeeemerged0000.FIT \
evlist=PxxxxxxyyyyR1eeeeEVENLI0000.FIT \
auxgtitables=my_low_back.fit
rgsproc entrystage=4:spectra
- Do I have everything I need to start fitting the spectra?
If you were happy with the PPS products, the validity checks were OK,
and you did not need to run rgsproc
at all, the answer is then NO. You still need to generate response
matrices
rgsproc entrystage=4:spectra
With this rgsproc call, only two SAS tasks are run:
rgsrmfgen
rgsfluxer
that generate the response matrices and the fluxed spectra,
respectively.
Some Frequently Asked Questions...
- Should I use total or net (i.e. background
subtracted) spectra?
- If you want to inspect a combined spectrum in flux units (rather
than counts/sec), in particular combining data from the two cameras
(RGS1 and RGS2), then it is better to subtract the background from
each spectrum. The fluxed spectrum is extremely useful for
visualizing the data free from the peculiarities the instruments. It
can be generated by running rgsproc with the finalstage
left to its default value of 5:fluxing.
- If you want to perform quantitative analysis of the spectra, a
spectral fitting package, (such as XSPEC, SPEX, SHERPA ...), should
be used. Especially for medium or low signal-to-noise spectra, it
is recommended to carry out such analysis simultaneously on
total and background spectra.
- I want to have a quick look at my spectra
Display the combined fluxed, first order, spectrum:
dsplot table=PxxxxxxyyyyOBX000fluxed1000.FIT
displays the qualitative final first order spectrum after
combining all RGS exposures within the observation, already
calibrated in
photons cm-2s-1Â-1, with
the estimated errors overlaid.
Warning: In case the spectrum is not correctly displayed (that may
happen depending on the operating system), it might be necessary to
replace first the NULL values in the table by e.g. 0, with
dsreplacenulls \
objects='PxxxxxxyyyyOBX000fluxed1000.FIT:FLUXED:FLUX PxxxxxxyyyyOBX000fluxed1000.FIT:FLUXED:ERROR' \
value=0
The combined fluxed spectrum,
PxxxxxxyyyyOBX000fluxed1000.FIT, is very useful to get a
quick look of combinations of any number of observations of both RGS
instruments, but it should not be used for detailed analysis of
spectral features.
- In most cases, celestial sources are weak for RGS, giving low
signal-to-noise spectra. Since the use of Chi-2 minimization
techniques do not apply to spectra limited by low number of
counts, a different likelihood function (implying Poisson statistics)
should be used instead. Alternatively, the parameter rebin
can be used for channel rebinning, e.g.
rgsproc rebin=5
to increase the number of counts per bin.
