View on GitHub

IRAF Community Distribution

IRAF maintained by the community

Home | Installation | Packages | X11IRAF | PyRAF | Forum

Echelle Spectra and sky not aligned with columns

Frank Valdes wrote on Jun 26, 1998


Q1:  I have several nights of spectra that are dominated by night sky lines
(we are working with faint white dwarf stars) but, up to this point, I
have been unsuccessful at remiving them.  I have not found a routine in
IRAF that sky-subtracts echelle spectra.  I am really only interested
in the order containing H-alpha so I have been extracting only one
order from the image, designating sky apertures on both sides of that
order and using the "skysub" routine in IRAF for multispec spectra to
eliminate the sky.  As far as I can tell, it is not working at all.  In
some instances, the spectra looks worse!

Is there a package/routing that will do this properly that I have
overlooked or is sky subtraction just something that is not performed
with echelle spectra?  I have been told that most people working with
echelle spectra do not bother with sky-subtraction when doing radial
velocity work (thats what I am doing) which seems odd.


A: First, I have a question for you.... are your spectra
aligned such that the slit image is parallel to lines or columns
on the ccd, or such that the spectral order is parallel to the lines
or columns.  If the former, then the "background=average or median"
option in either apsum or doecslit in the echelle package should
do the job.  Those options allow you to set background regions on
either side of the stellar aperture, and will do either the average
or the median of the points in the background region to subtract a
local sky background.  Use the "b" key when you are in the "edit
apertures" screen to see and mark the background apertures.  (You
can also use apscatter to subtract a global, diffuse scattered light
background in a previous step.

If your spectral orders are parallel to the lines or columns, then
sky subtraction will be hard because the slit image will be tilted
with respect to the columns or lines.  I don't think there is a
task in IRAF to deal with this situation for sky subtraction.  What
you might try is to extract a small image including the order you want
and the night sky lines, and use a task in the twod/apextract package
(I think it's "fitcoords") to rectify the slit image with the 
spectral order.  Then you can probably use the resulting image for
sky subtraction.  This procedure may, however, introduce a ripple
into the continuum (that ripple would probably show up also if the
spectra are not parallel to the lines/columns as in the other case
above).

Caty Pilachowski


A: The only thing I would add is that rather than do the 2D regridding
of the orders using the LONGSLIT package (IDENTIFY/FITCOORDS/TRANSFORM)
if your slit image is significantly tilted, I would suggest you define
two apertures per order, one for the object and one for the sky.
Extract both, wavelength calibrate both and then subtract the 1D skys
in wavelength space using SARITH.

With many orders the bookkeepping can be a challange.  The way I would
do it is mark the set of apertures for the object and then extract
the object to one .ec file.  Then do APALL again with the edit option.
Setting the 'a' option to operate on all the apertures shift all the
apertures by a uniform amount to get the apertures over sky.  Then
extract this to another .ec file.  Use the same apertures, first the
object and then the sky positions to get two .ec arc files for wavelength
calibration.  Do ECIDENTIFY on one of the arcs and use the solution
to wavelength calibrate the matching data.  The second arc may just
be automatically ECREIDENTIFYed or you can do it separately.  The point
of all this is to make sure to use the same apertures for the arc and
object for the star and sky positions.  After DISPCOR you should have
the sky and object spectra calibrated to the same wavelength scale
and then subtracting in wavelength space should be all you need.
Note that there is a new task SKYTWEAK which could also be used for
further fine tuning if you really need to optimize the sky subtraction.

Actually I did not read your message carefully enough to note that you
probably will only need to work on one order.  You can, of course, do
the above on a single order and use IDENTIFY for the dispersion solution.
However if the order does not have enough sky lines this could be
a problem and you might want to do multiple orders so you can use
ECIDENTIFY for an echelle dispersion solution that ties the arc lines
from multiple order together.  If you do not care about actual wavelength
calibration you can take your two extractions, one of the star position
in the order and one of the sky position in the order and simply use
SKYTWEAK to shift and subtract assuming a small pixel shift is ok
(which it should be).  This last, two extractions of a single order
followed by SKYTWEAK should be quite easy and better than doing the
LONGSLIT method.


Q2: Thank you for your suggestions.  I will try them at once!  Is there a
cookbook for the type of routines you described that I am missing, or
is this just something that you pick up as you go along?  I'm thinking
that if there is a reference or two around, I could have saved both you
and Caty the extra effort of explaining this to me.


A: The main user guide is "A User's Guide to Reducing Echelle Spectra
With IRAF" by Willmarth and Barnes, 1994.  It can be obtained from our
ftp archive:

ftp://iraf.noao.edu/iraf/docs/ech.ps.Z

Another source of information which can still be of use for echelle users
is "A User's Guide to Reducing Slit Spectra with IRAF" by Massey, Valdes,
and Barnes, 1992

ftp://iraf.noao.edu/iraf/docs/spect.ps.Z

Thes documents are probably limited to the basics and may not discuss some
of the subtleties such as you are asking about.  The method of waiting
for sky subtraction in wavelength space after extracting separate sky
and object spectra is not generally appreciated or discussed in guides
since if one can sky subtract during extraction the bookkeeping is a lot
less and is fairly standard.

Last post on Jun 26, 1998