Dealing with moving objects in ODI data

In most cases, astronomical observations look at static things such as stars, galaxies, etc that do not move relative to the stars, Then, however, there are the cases of really nearby objects such as asteroids and comets that do move. The complication of these cases lies in the fact that the usual WCS calibration does not work when the target is moving, making stacking individual frames to increase the signal-to-noise ratio of the moving object impossible. The following describes two ways of dealing with them.

 

Automatic reduction with WCS and non-sidereal

The first way works well if you know the non-sidereal proper motion of the object and the object is not moving fast enough to cause significant trailing during the exposure. The recommended way of reducing these frames then is as follows.

For this step to work you need at least QR Revision 723 (checked in 2014-01-16). Run “svn info” to check your revision and “svn up” if you need to update your copy.

  1. Prepare calibration products as above (podi_makecalibration); also see the tutorial on creating calibration products.
    If you have reduced the data before with an older QR version, you better re-do this step as there were some changes with respect to gain correction and binning support
  2. Reduce the data using podi_collectcells with the following additional component
 ~/quick_reduce/podi_collectcells.py /some/dir/o20140102T030405.6/ output.fits -cals=cals/ -nonlinearity -wcs=~/quick_reduce/2mass_distort5.fits -fixwcs -nonsidereal=x,y,z

The critical part here is the -nonsidereal option.

Above, in the -nonsidereal=x,y,z change:

  • x → dRA*cos(dec) as given by, e.g., the NASA horizons service
    Units are in arc-seconds per hour
  • y → dDec
    again using arc-seconds per hour
  • z → MJD reference
    This can be either the MJD of any frame that will serve as reference frame, or the filename of a FITS file that contains the MJD-OBS keyword in the primary header. This means that both QR-reduced frames AND raw-frames work as reference frames.

Make sure the WCS for each frame works, i.e. you have enough stars in each of the frames, as the non-sidereal correction will be relative to the WCS solution of the frame.

  1. Go stack data – this i haven’t checked yet, but I see no reason why it wouldn’t work.

Caveat:
If there’s significant trailing, SourceExtractor might not find the best center position of each trailed star, leading to a not-well determined WCS solution, and hence the alignment might not be great. One option would be to skip the -fixwcs step and hope that while the absolute telescope pointing is off the offsets between frames are good enough.

 

Aligning frames by hand

Alternatively, there is a hacked-up script to align frames visually that works in all cases where you can see the moving object, but also in cases with extreme trailing:

  1. Make calibration files (see tutorial)
  2. Reduce all frames. With or without WCS doesn’t matter, but you probably need the -wcs=/some/dir/2mass_distort5.fits option.
  3. Run the offset finder script:
 /work/podi_devel/test/dev_fudgewcs2.py 20131108T051333.1___ISON___odi_g___110.0.fits OTA42.SCI 20131108T051739.1___ISON___odi_g___110.0.fits OTA42.SCI

Syntax is as follows:

dev_fudgewcs2.py reference.fits (OTA-name in reference frame containing the object) (frame to align) (OTA of object in frame to align)

This will output you the commands required to fix the WCS. These commands will look like:

/work/podi_devel/test/dev_fudgewcs2.py 20131108T051739.1___ISON___odi_g___110.0.fits -0.002422 0.002790 20131108T051739.1___ISON___odi_g___110.0.fudged.fits

Syntax here is

dev_fudgewcs2.py (file to get fixed) delta_RA delta_DEC output-file.fits
  1. Execute the fixing commands
  2. done – go and stack data with swarp etc.