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 the 'Configuration Info' field 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 convenient to
redirect the output to a log file:
rgsproc -V 5 >& my_rgsproc_logfile
The task rgsproc 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:
5:fluxing: generates 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:
PxxxxxxyyyyR[12]zeeeEVENLI0000.FIT
filtered event lists
PxxxxxxyyyyR[12]zeeeSRSPEC1001.FIT
source+background first order spectra
PxxxxxxyyyyR[12]zeeeBGSPEC1001.FIT
background first order spectra
PxxxxxxyyyyR[12]zeeeSRSPEC2001.FIT
source+background second order spectra
PxxxxxxyyyyR[12]zeeeBGSPEC2001.FIT
background second order spectra
PxxxxxxyyyyR[12]zeeeSRCLI_0000.FIT
source lists
PxxxxxxyyyyR[12]zeeeRSPMAT1000.FIT
first order response matrices
PxxxxxxyyyyR[12]zeeeRSPMAT2000.FIT
second order response matrices
PxxxxxxyyyyOBX000fluxed1000.FIT
combined fluxed first order spectrum
PxxxxxxyyyyOBX000fluxed2000.FIT
combined fluxed second order spectrum
If the task has been run only through "spectra" neither the
response matrices nor the fluxed spectra are created. Note that the
last stage (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 results of rgsproc 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. 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.
Once you have run rgsproc, the source list will contain two
sets of coordinates: 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 set of coordinates (ONAXIS) is computed from the
spacecraft attitude. If you are working with the PPS files, then the
source lists are probably longer because during the pipeline
processing the source detected in the EPIC cameras 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.
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 PxxxxxxyyyyR1zeeeSRCLI_0000.FIT
and check that the coordinates of the PROPOSAL source are
correct.
These plots can also be found in the PPS files under the names
PxxxxxxyyyyRrzeeeIMAGE_0000.PNG and
PxxxxxxyyyyRrzeeeORDIMG0000.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 them.
It is very important to check that all the sources in the RGS field
of view have been correctly identified and that the 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.
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 for details.
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:
where timebinsize is the time binning of the light curve in
seconds.
The first part of the expression in the evselect
call 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 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
Intervals.
If necessary, create a Good Time Interval table:
Good Time Intervals, GTIs, 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, that
define good periods based on the attitude and housekeeping data
included on the ODF.
Extra GTI tables can be generated for filtering periods of high
background out of the event list, to be used in conjunction with its
internal GTI tables:
The expression in the tabgtigen task indicates that only
periods with count rates less than maxr counts/sec should be
selected. The value of r should be chosen after inspection of
the background light curve; it goes 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
task expects a file named PxxxxxxyyyyRrzeeemerged0000.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:
Do I have everything I need to start analyzing 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 YES !.
If you are starting the process from the ODF, once you have performed
all the checks and/or corrections described above, do not forget to run
rgsproc until the last stage (fluxing), to generate the appropriate
response matrices.
Some Frequently Asked Questions...
Should I use total or net (i.e. background subtracted) spectra?
If you want to perform quantitative analysis of the spectra, a
spectral fitting package, (XSPEC, SPEX, SHERPA ...), should be
used. It is recommended to carry out such analysis on
total and background spectra, i.e. not in background
subtracted spectra..
I want to have a quick look at my spectra...
If you want to inspect a combined spectrum in flux units (rather than
counts), in particular combining data from the two spectrometers
(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 of the instruments. It
can be generated by running rgsproc with the finalstage
left to its default value of fluxing, or taken from the PPS
products.
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.
The combined fluxed spectrum 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, as it does not take into account the
redistribution matrix.
Can I combine spectra from different observations?
Yes. The SAS task rgscombine combines RGS source and
background spectra and response matrices. The only restriction is
that all the spectra must belong to the same spectral order, and must
have been created in wavelength space (i.e. using the default option
spectrumbinning=lambda in rgsspectrum or rgsproc).
In most cases, celestial sources are weak for RGS, giving low
signal-to-noise spectra. Since 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.
