Feeding UVOTGRASPCORR a catalog of selected stars to lock onto¶
Note:
This page applies only to the reduction of UVOT grism observations
without using an accompanying lenticular filter image. In that
case the sky position of the weaker zeroth orders is matched to
the USNO-B1 catalog by the UVOTGRASPCORR tool. The image header
of the image containing the spectrum is updated accordingly.
Sometimes this fails. Then your wavelengths jump around from one
spectrum to the next. Here is a possible solution. It requires
some work and may depend on the roll angle of the observations
being in a limited range, or you may have to do this repeatedly.
Aspect correction problem identification¶
The straighforward way to check if the WCS keywords in the header of a grism image are correct is to open the image in “DS9”, then blink with the DSS image, or plot catalog positions.
So here is what I do:
ds9 sw00030366009ugu_sk.img
scale -> log
zoom out
in ds9: analysis -> catalogs -> optical -> gsc 2.3
the catalog panel pops up, -> retrieve
in the panel edit the filter:
$Fmag > 13 && $Fmag < 17
press <filter> button
Now we get the following figure:
As you can see, the zeroth orders typically have a circle for the catalog position just above them. Here the aspect is not good. Checking the header shows that uvotgraspcorr was not run (ASPCORR not set to GRASPCORR).
In order to get a good data set with uvotgraspcorr applied, download the reprocessed data from MAST or the HEASARC Swift archive. Otherwise, process yourself using my (unofficial!) script:
grismpipe sw00030366009ugu sw00030366009sat.fits
The script can be downloaded here :download: grismpipe <grismpipe>
To check the header of the reprocessed file:
ftlist sw00030366009ugu_sk.img+1 hk
which gives (part):
(...)
HISTORY P12 chatter = 1
HISTORY P13 history = yes
HISTORY P14 mode = ql
HISTORY END PARAMETER list for imagetrans_1.2.0
HISTORY
UTELDEF = 'swugu0160_20041120v105.teldef' / UVOT TELDEF file name
DTELDEF = '/sciencesoft/CALDB/data/swift/uvota/bcf/teldef/' / UVOT TELDEF direct
ASPCORR = 'GRASPCORR'
A_ORDER = 3
B_ORDER = 3
A_1_0 = 0.000808337503837
A_2_0 = -1.00634932413E-05
A_1_1 = -6.05027923295E-07
A_0_2 = -7.40281887760E-07
A_3_0 = 6.75543414620E-09
A_2_1 = -2.20404783943E-08
A_1_2 = 1.25607162442E-08
A_0_3 = -8.19315287996E-09
B_0_1 = -0.0119355520972
(...)
As you can see, the ‘ASPCORR’ keyword has now been set to ‘GRASPCORR’, while also the distortion coefficients for the zeroth orders on the image are present. Good. Let’s try again.
Although the “uvotgraspcorr” program ran, it clearly failed. The zeroth orders still don’t match. Now, if you have a single spectrum, you can edit the WCS header keywords to align the image. However, if there are more images, a better method is needed. The reason uvotgraspcorr could not match the catalog is that it confused the sources. Your eye easily picks that up, but the matching algorithm doesn’t. The matching is using triangles of the fainter stars on the sky. So we will try to feed uvotgraspcorr our own catalog which is a subset taken from the USNO-B1 catalog. We cannot use the bright zeroth orders, since they are too extended, but we can find nice sets of triangles. What I do in the following depends on how crowded your field is. This one is pretty crowded, so I am chosing the ones that look brightest and still small.
I finally settled on a filter like:
$Fmag < 15.5 && $Fmag >13.0&& $_DEJ2000 > -06.96&&$_RAJ2000 > 267.4
save -> tab-separated-value -> catalog.tsv
I now have a file:
_RAJ2000 _DEJ2000 GSC2.3 RAJ2000 DEJ2000 Epoch Fmag jmag Vmag Nmag Class ae
267.558773 -06.776805 S7XO018785 267.558773 -06.776805 1989.564 15.41 16.79 14.60 0 3.69 0.15
267.556488 -06.779179 S7XO018675 267.556488 -06.779179 1989.564 13.89 15.58 13.05 3 5.51 0.28
267.531593 -06.778963 S7XO018657 267.531593 -06.778963 1989.564 15.13 16.44 14.34 0 4.14 0.20
267.588769 -06.780796 S7XO018581 267.588769 -06.780796 1989.564 14.31 16.07 13.34 3 5.08 0.27
267.533930 -06.781334 S7XO018510 267.533930 -06.781334 1989.564 14.76 16.66 13.72 3 4.63 0.31
267.544399 -06.786720 S7XO018227 267.544399 -06.786720 1989.564 14.88 16.31 13.81 0 3.92 0.12
267.548245 -06.855490 S7XO014489 267.548245 -06.855490 1989.564 15.05 16.38 14.31 0 4.40 0.22
267.567991 -06.855803 S7XO014487 267.567991 -06.855803 1989.564 14.08 15.88 12.96 0 4.42 0.02
267.519343 -06.850837 S7XO014739 267.519343 -06.850837 1989.564 14.25 16.20 13.02 0 4.60 0.16
267.549267 -06.863718 S7XO013989 267.549267 -06.863718 1989.564 15.24 16.60 14.23 0 3.74 0.15
267.508769 -06.865075 S7XO013931 267.508769 -06.865075 1989.564 14.86 16.08 14.37 3 4.86 0.27
267.548635 -06.866673 S7XO013843 267.548635 -06.866673 1989.564 14.68 16.28 15.25 3 4.69 0.07
267.540147 -06.829210 S7XO015972 267.540147 -06.829210 1989.564 15.37 16.44 14.51 0 3.51 0.06
267.539192 -06.824686 S7XO042330 267.539192 -06.824686 1989.564 14.34 16.33 13.25 3 5.40 0.36
(...)
It is actually 385 records long. I delete the first line to get a proper ASCII table, but I use that below. The Fmag is what we want to use, in column 7. Now we need to make a descriptor file (or whatever it is called), for the catalog input to “UVOTGRASPCOORR”. Save as catalog1.spec:
# Catalog descriptor for GSC over the web.
# Note that the StarID::SearchCat uses the scat WCS Tool.
type => StarID::SearchCat
fields => RA1,DEC1,ID,RA,DEC,EPOCH,MAGF,MAGJ,MAGV,NMAG,CLASS, ae
packed => 0
data => user
catalog/type => Indexed
catalog/n => 4
mag => MAGF
path => /Volumes/data/various/RS_Oph/catalog1.cat
First we have to edit the header file to remove the wrong ‘ASPCORR’ keyword (we do this for the detector image), then run uvotgraspcorr
fparkey None "sw00030366009ugu_dt.img[1]" ASPCORR
uvotgraspcorr catspec=/Volumes/users/Users/kuin/various/RS_Oph/catalog1.spec sw00030366009ugu_dt.img clobber=yes
For some reason, uvotdetect does not find any source positions.
In DS9, we chose the WCS-S system (WCS -> multiple WCS -> WCS-S). Then load the catalog again. Apply the same filter as above.
Unfortunately, this does not work when I try to update the sky image. I suppose I need to have a script to reprocess using the special catalog I made. However, the match now seems close to within a few pixels, so the wavelength error should not be too much (1 pixel~3.2A).