Tweak Up Your Centering the Easy Way!

John Thorstensen, Dartmouth College

2004 December

It is sometimes desirable to center a direct image accurately. The MDM telescopes point reasonably well, but not to arcsecond precision, so accurate centering requires lots of overhead -- taking a test shot, displaying it, consulting your finding chart, figuring out how far to move the telescope (and it always seems like you have less than a 50-50 chance of getting the sign right), and so on. This tedious process wastes telescope time.

This document describes a script which makes the process faster, easier, and more accurate in almost all cases. It requires a one-time investment of a few minutes on your part to set up the first time (this can be done in the afternoon), and there are cases where it will fail, but it generally works well and saves a lot of bother.

It works like this. Basically, you set on your object, take a quick unguided test shot (like 10 seconds) and run the script, which turns around and immediately tells you exactly where to move the telescope. The script works by finding the stars in the image, matching them to the USNO A2.0 star catalog, deriving a "plate model", and figuring out the telescope RA and dec readings which will put your object right where you want it in the image.

I intend to install this on the fast Linux boxes Agung and Hill, and eventually on Chichon and Kilauea when they are replaced by fast machines (anticipated in the summer of 2005).

Setting It Up.

  • At present the scheme works only for those chips run by CCDCOM. It could easily be adapated to TIFKAM, but probably wouldn't work as reliably given the difference between the passband of TIFKAM and the visible-wavelength catalog used to match stars. If there's enough interest I could see what I could do with the 8k, though its field is so large that exact framing may seldom be an issue.

  • In order not to waste time reading the chip (especially echelle, which reads at a glacially slow pace), you'll probably want to use a binned format for your finding shots and a larger, unbinned format for your science data. You can switch quickly and reliably between these setups by creating two little files in the directory into which you're writing the data. You might call these files "tofind" and "tosci; their contents are respectively (for a 2048 chip): 
     
sf 2 2 512 512 512 512 32
fp junk.
auto 0 y y y n
et 10
    and 
    sf 1 1 0 0 2048 2048 32
obj 120 
auto 1 y y y n
fp ccd.
    Once you've made these files, typing the command source tofind in CCDCOM will then invoke the 'set format' command sf to make the chip read a small format, binned 2x2, turn off the pre-exposure clearing of the chip, set up to name the data files things like junk.123.fits, and set the exposure time to 10 seconds. Typing source tosci restores the full chip format, sets the naming convention to things like ccd.124.fits, restores the pre-exposure chip clearing, and sets the exposure time to be longer. Using the file prefix "junk" (the fp line) makes it easy to erase the setup images later. One gotcha here: The running file number automatically updates after each exposure, including "junk" exposures. If you want your science images to have an unbroken numbering sequence you'll need to reset the running number by hand using the fn command in CCDCOM.

  • In the visitor directory space on agung, make a directory to work in and enter it, by typing for example 
    	mkdir centerdir
	cd centerdir

  • In this directory edit a little file called centermdm.config. This will set up various fixed information. Here is an example of its contents, which you'll want to alter to suit your purposes: 
    	xaim 256
	yaim 256
	pointlist targets_apr05
	imagedir /data/pinatubo/visitor/smith/direct/
    The format is fairly obvious -- it's keyword/value pairs. xaim and yaim will in most circumstances be the middle of the finder frame (assuming that corresponds to the location you want to put your objects in the science images). pointlist is the name of an mdm-style pointing file. This is optional but saves a lot of tedious and error-prone typing later. MDM-style pointing files have lines of the form 
    	targetname_no_blanks  rah mm ss  decd mm ss  equinox
    e.g. 
    	4U2129+47   21 29 36.2  47 04 08  1950
    These are the format used to feed coordinates by name to xtcs, so hopefully you'll have one ready. Note that the coordinates in this file will be used to tweak up the telescope pointing, so they need to be accurate. Finally, imagedir is the directory you're using to take data. Note that the pinatubo disks are cross-mounted on chichon, the example shows how the image data get accessed.

  • Be sure to copy the pointing list you're going to use (the one specified in centermdm.config) into the directory you're using.

    Using It.

    With the setup out of the way, the program should be easy to use.

  • Set the telescope on your object. The telescope will need to point decently (within 1 to 2 arcmin) but doesn't need to be perfect. If your pointing is sloppier than this, the program may fail to match the star pattern (it uses the header coordinates to look up stars in the USNO A2.0 catalog).

  • Be sure you're using a sensitive broadband filter such as V, R, or I.

  • Type source tofind in CCDcom. If you're at high latitude, where fields are sparse, you may want to increase the exposure time by typing (for example) et 20 . If it's been a while since you read the chip you'll definitely want to manually clear the chip it by typing cl . This will eliminate any cosmic-ray hits which have accumulated.

  • Take a finder exposure by typing go as usual.

  • When the image finishes reading, type in an Agung window: 
    	centermdm.py junk.123 mytarget
    where junk.123 is (obviously) the picture you just took, and mytarget is the name of the target in the pointing list.

  • If you don't have a pointing list, or your object isn't on it for some reason, you can simply give its coordinates explicitly: 
    	centermdm.py junk.123  18:22:22.8  -13:14:15
    The coordinates must be J2000, and must be in this "colon-ized" format. They should also be accurate, since the telescope will end up pointing straight at them.

  • As the program runs, you may get a prompt like "accept this fit?". If it looks good -- if it finds a reasonable number of stars (like 5 or more) with small rms residuals (less than 1 arcsec) and a rotation angle which is what you expect (generally close to a multiple of 90 degrees), just answer "y" and it'll rip through to the end. The coordinates to aim the telescope at are presented in a box at the end of the output -- simply point at these coordinates.

    (If on the other hand the solution fails, or looks fishy, your best bet is to forget about it and set however you like. Don't waste time trying to save time.)

  • After you've set on the aim point, get the autoguider going before the telescope has a chance to drift off. See the manual for gs24 - `Guide star selector manual' on the mountaintop web server - for instructions as to how to pre-select guide stars. This can save a lot of time!

  • Before you take your science exposure, be sure to type source tosci (or whatever) to return to your science-object setup, fn 123 (or whatever) to reset the file number if needed, and set your filter, exposure time, object name, and so on as appropriate.

  • Note that you can start your science exposure going right away, there's no need to display the image or find the object -- if there's a good convincing USNO A2.0 match, and the object coordinates (from the list or the command line) are accurate, you'll point right at it without ever looking at it. Of course, once you do get going on your science exposure (with the guider working and so on) you'll want to have a look at the finder exposure just to be sure things are working right.

  • If for some reason you want to override the pixel coordinates of the aim point, you can do so on the command line by giving the X and Y pixel coordinates of the desired aim point in the system of the finder field. If for example you'd taken a 512-square test shot and found it to be too sparse, and decided to use a 1024-square test shot instead, you could type 
    	cenermdm.py junk.124 mytarget 512 512
    to reflect the new finder-field center.

  • Once you're settled and are certain that you're pointed just right, you might consider updating the telescope readouts since you know know exactly where you're pointing. I wouldn't recommend doing this far from the zenith (especially at the 1.3m) since that puts strong demands on the pointing model (which may not be much good, and isn's used at the 1.3m). If you do update your pointing, be sure to proceed cautiously. Before you move away from your known pointing, be sure to carefully verify that the RA and dec have set correctly (including the epoch) -- sometimes the coordinates don't "take" correctly! If you move away from a known pointing with incorrectly reset coordinates, you lose track entirely of where you are, and have to go to the zenith, set the tilt meters to zero, and reset again. But, if you are careful, having certain knowledge that your target is centered perfectly offers a nice opportunity to update the pointing, which makes subsequent observations smoother.

    • As noted earlier, if the program doesn't find the star field, your best bet is to grab your finding chart and center up the old-fashioned way. Time's a-wastin', and you don't want to fiddle with technicalities while the sky wheels overhead -- the idea is to save time, not waste time. You can expect the program to fail occasionally; it doesn't necessarily mean the procedure is broken. (If it never works, it probably is broken -- tell me about it and I can probably fix it in a couple of minutes the next day if I'm around.)

    Some locations in the sky will always be problematic. At high latitude some fields are too sparse, and in very crowded fields the matching algorithm sometimes fails. The USNO A2.0 is useless wherever the Sky Survey is burned out (e.g., in bright galaxies, some globular fields, in the brightest parts of the Milky Way, and so on). Proper motions since the 1950s are occasionally an issue. But over nearly the whole sky the procedure should work fine.

    If you get a high failure rate, you could try increasing the size of the finder field a bit, or increaing the exposure time slightly. In practice, a 5-arcmin square finder field and a 10-sec exposure in the I-band on the 2.4m almost always gets enough stars to match.

    Fine points, blah blah blah ...

  • This software is adapted from the makematch family of coordinate-matching stuff. Those scripts generate precise RA and dec for your science images automagically (in nearly all cases). There is a separate web manual describing these, "automatch: finding precise coordinates for images", which is on the MDM mountaintop web server. If this is at all interesting you should check it out, it can be a huge labor saver.

  • In presenting the coordinates to you, the program adjusts them to the equinox (or "epoch" as it's incorrectly called) which it finds in the image header. This is the "display epoch" set in xtcs, and should match the equinox on the TCS display. So, just set the telescope.

  • You may get some vestigial output from the star-finding stuff, like 
    If you're running stand-alone, run it by typing
  ./wcs_script1   
    ... if not, it's about to run on its own.
    Just ignore this.

  • There are various error messages and checks which are executed by the script. Most are self-explanatory. The one non-trivial one is a safeguard against incorrect target coordinates (e.g., giving the wrong object name) If it turns out you have to move the telescope more than 10 arcmin but less than 5 degrees, warnings are printed to prompt you that it is a long move and you may have specified the wrong target coordinates. If the move is more than 5 degrees, the program refuses to tell you where to move the telescope, since then it's virtually certain you've given the wrong target coordinates and an offset that long will be suspect at best. I put in these features to avoid the situation in which a sleepy observer sends the telescope off to some completely different location just because the program said so.

    The reason for including a broad "warning zone" instead of just cutting off at a few arcmin is that it may be useful to have the capacity to set very roughly, take a test shot, and then do a fine set. This could be especially useful at the 1.3 m, where fine-setting can take some doing. You could set within a half-degree or so in the dome and tweak up reasonably well from inside the control room using the test-shot procedure.

  • The program leaves a lot of little files around every time it runs. They are things like (for example) 
    	junk.123.radec.match.wcs     - a set of XY vs RA/dec matches.
	junk.123.audit               - a little summary of the solution, with
	                               the filename, catalog used, number of 
	                               stars matched, RMS, and date
	junk.123.cat                 - a list of stars detected by SExtractor,
				       the first line is the seeing in pixels.
	match_diagn.tmp		     - as the name implies, more diagnostic
                                       info, including the rotation, scale,
                                       and parity of the fit
	test.cat                     - Raw output from SExtractor, all the 
                                       detected images
        wcs_script1                  - an executable script which would in
                                       principle load world coords into 
                                       your junk image header, in case you
                                       wanted to do such a thing.
    Some of this may be interesting, but in general it's all expendable. In fact you should wipe out your whole centering directory at the end of your run, it's basically only of interest when you're setting.