John Thorstensen, Dartmouth College
2010 September - rev. 2012 September, 2016 August Largely rewritten 2019 January
Why and What: In long-slit mode, the OSMOS instrument is centered using images taken from behind the slit -- there are no slit-viewing optics, as there are on CCDS, MarkIII, and Modspec. This makes target acquisition with OSMOS much more complicated than for these other instruments.
In overview, you have to:
The possibilities for screwups here are endless. The loss of efficiency can be very serious for programs that involve frequent target acquisitions. Because my own programs have many targets, I've developed procedures and tools to speed this up. But even so, the process is inherently complicated and error-prone.
Therefore, even more than with most manuals, you must resist the natural tendency to skim. The process involves interacting with at least five different pieces of software, each with its own peculiarities. (For reference, they are JSkyCalc24mGS, the guider program Maxim DL, the DFM TCS system, including its handpaddle, Prospero, and pyraf.) Because this is so complicated, I recommend painstakingly 'checklisting' your way through this process until you're familiar with it.
The underlying reason this is so complicated is that setting an object dead in the middle of the slit requires sub-arcsecond setting accuracy, and the telescope will not blind-offset to this accuracy. The workaround is to use the autoguiding system to make small, precise adjustments -- we tell the guider to keep the guide star centered on a certain pixel in the guide camera, and the telescope follows. Because there are no mechanical moving parts, this is extremely accurate.
For reference, the guider pixels subtend 0.223 arcsec, smaller than OSMOS B4K pixels at 0.273 arcsec. The smallest OSMOS slits are 0.9 arcsec, which is more than 4 guider pixels across. It's not hard to center to 1 pixel using the procedures described here.
Be prepared! Before your run:
Target lists. Both JSkyCalc24mGS and the centering procedure are greatly simplified if you prepare file of anything you might point at (including e.g. standards). Here, for the millionth time, is the format:
objname 18 22 33.45 -0 17 18.2 2000
Note that (a) the object name cannot have any blanks, (b) the coordinate fields are sexigesimal and space separated, and the RA is in HOURS minutes and seconds; and (c) the equinox must be included. The example shown would be at an RA of 18 HOURS (and change), not 18 degrees.
For osctrtask you'll want a single list including your targets, your standards, whatever -- everything you might point at. For JSkyCalc it can be helpful to have lists segregated by function (e.g. standardlist, prog1list, prog2list), but in osctrtrask it's better to have them all glommed together. Repetition doesn't hurt anything.
Acquisition will work best if your coordinates are accurate to 1 arcsec or better. Don't forget proper motion if it's non-negligible. Gaia and PAN-STARRS are great sources for accurate coordinates of non-transients.
It'll be most efficient to stuff all your lists in a directory (i.e., folder), say 'mytarglists', on your laptop.
Setting up at the observatory.
When you get to MDM, make yourself a directory on the workstation mdm24ws1. Do this by popping a terminal window and typing
substituting your name or whatever for 'mydirectory'.
Just to keep you oriented, thefull path to 'mydirectory' will be /lhome/obs24m/mydirectory.
Connect your laptop the local network, and then from a window on the laptop type
rsync -azvt mytarglists email@example.com:mydirectory
and the whole folder will copy, so you'll have a directory called e.g. /lhome/obs24m/mydirectory/mytarglists.
Now make yourself a scratch directory for centroiding. To do this, on mdm24ws1, 'cd mydirectory' and then 'mkdir centering' or whatever you want to call it. Descend inot it with e.g.
Now, if you type 'pwd' (print working directory) you should have something like
Now that you're in your own centering directory, copy the centering task from my (Thorstensen's) centering directory to yours:
cp /lhome/thorsten/oscenter/osctrtask.py .
Don't overlook the final dot on the line -- it means to copy into the directory you're in.
OPTIONAL in greenish: You an get quick-look spectral reduction if you also copy cp /lhome/thorsten/oscenter/osqlsq_new.py .
If you happen to have created some good wavelength solutions for the setups you're going to use, you can copy those from your device into the centering directory too. In that case, on mdm24ws1, create a subdirectory called database (exactly that name) under your centering directory, and then copy both the comp spectrum and the file summarizing the solution as follows:
scp argon_center_red.0001.fits firstname.lastname@example.org:mydirectory/centering cd database scp idargon_center_red.0001 email@example.com:mydirectory/centering/database
The reason for doing this is that you can then apply an accurate wavelength solution to any quick-look spectra you generate for that particular setup.
(End of quick-look data reduction part.)
Set up osctrtask.py as follows:
pyexecute('osctrtask.py')where the parentheses and quote marks need to be exactly as shown. osctrtask.py is a python script with extra hooks that allow pyraf to turn it into an IRAF task.
Make some useful prospero scripts.
OSMOS is pretty complicated, and one gets tired and frazzled, so it can be incredibly easy to take images with the wrong configuration of slits, dispersers, and filters. I HIGHLY recommend that you automate some routine actions by making yourself some simple prospero scripts. This is easy.
Prospero executes scripts that it finds in the directory /lhome/obs24m/Scripts, so you'll need to put your scripts there. All scripts have the file extension .pro. They are invoked from prospero by typing, for example,
to the prospero prompt, without the ".pro" suffix.
The Scripts directory has about a million old scripts that people have dropped there. It's socially responsible to give your own scripts a distinctive prefix so you don't generate name collisions.
Note carefully that filters, slits etc. the slits, filters, and dispersers installed in different wheel positions change from run to run, so you must at the least check over any scripts you're going to use at the start of your run, and update wheel numbers as needed.
Here are two that I'll refer to:
# *** thorblueacq.pro **** # Get acquisition exposures for osmos inner slit. # Wheel positions for 2019 January run # # Do slit exposure first while acquiring guide star # open except for 1.2 arcsec inner slit. # exp 15 filter1 6 filter2 6 slit 2 disp 2 sleep 5 go # # Short direct exposure in V or g exp 20 # filter2 3 filter1 1 slit 6 sleep 5 go # # Leave in place for a confirming exposure if desired.
As you can see, the script first takes an exposure of the slit alone, which will appear as a bright vertical line in the image. Then it takes out the slit, inserts a g filter (this is optional -- it's just to give the acquisition image some scientific usefulness), and takes another exposure.
When you're sure the centering is right, a script like this will set up for a spectral exposure by inserting the slit and disperser and withdrawing any filters:
# Set up for a 'science' exposure for blue, inner slit # Wheel positions for 2019 January run # filter1 6 filter2 6 slit 2 disp 1 # Leave the 'go' to the user.
Some notes on the Maxim DL Guider
The 'trick' used to steer the telescope onto the target is to tell the guide system to center the star on a specific set of XY coordinates on the guide camera. You'll be manipulating the guider a lot, so here's a cheat sheet outlining (in red!) the controls you'll use most frequently:
OSMOS-specific target acquisition procedure
This is an inherently complicated procedure, and the following list attempts to break. it. down. into individual steps. It's a dauntingly long list, but I believe it explains everything. As I noted earlier, you can save tons of time and tears of frustration by methodically running this list until you've mastered the procedure.
Once you're not making mistakes, an uneventful acquisition can be accomplished in something like 5 minutes. If you're getting things wrong or out of order, this can stretch out considerably.
Note again that a script (e.g. "thorbluespec.pro" above) can make this less error prone. It does not set the exposure time or start the exposures, though.
What osctrtask does (in brief) :
Note that the script leaves the original data untouched -- you needn't be afraid of it screwing anything up.
It's marked off by the color of the type. I haven't deleted it all because some of the esoteric discussion of centering still applies.
Quick Instructions: You should be logged on as obs24m on mdm24ws1 (or ws2).
cp /usr/local/pkg/thorsoft/scripts/osctrtask.py .(Don't overlook the final dot).
!ds9 &The exclamation point is a shell escape, and the ampersand puts it in background.
Here's a screenshot of the 'epar' for osctrtask.
The first four parameters tell osctrtask where to get the data. Note that the datapath requires a final slash, and the prefix requires a final dot (which is nearly invisible here). acqnum and slitnum are the exposure numbers for the two images; you need to give something for slitnum even if you're not using it. These are internally converted to the standard four-digit format. In the case shown here, the program would go looking for the original acquisition image as
/data/hiltner/160823.0692.fitsIf the program fails immediately, there's probably something wrong with the path or prefix. The program assumes that the image number is padded with zeros to have 4 digits, as is standard.
For the bare-bones use of the program,
You'll find the bare-bones use to be a bit labor-intensive, and there's considerable ease and efficiency to be gained by using the other features of the program, as follows.
slit -- This must be 'inner', 'center', or 'outer'. This parameter is only used to show you the region of interest in the ds9 display.
slitns -- In the comissioning runs (spring 2010), OSMOS was mounted so that the slits were east-west. To minimize atmospheric dispersion near the meridian, one wants the slits north-south by default, and that has been adopted as standard for some time now. If for some reason OSMOS is mounted at 90 degrees to this, deselect this.
twoframes, xslitpar and yslitpar -- If you are using a fresh exposure to locate the slit, set twoframes to Yes. If you're using a nominal slit position from a previous exposure, de-select twoframes and type the X and Y pixel coordinates of your slit location into the xslitpar and yslitpar boxes. If you do this, use caution -- the X coordinate needs to be accurate to around one pixel!
The next nine (!) parameters control automatic target finding. This doesn't always work, but when it does it is a tremendous convenience.
getwcs -- If this is checked, the program will find star images in the acqimage and attempt to match them to entries in a compact version of the PPMXL astrometric catalog stored on disk. If this appears to work, the world coordinate system parameters will be set in acqimage's header, in which case you know the precise RA and dec for every point in the image.
marktarg -- If this is selected, then if the wcs is successfully found, and you supply target coordinates, your target will be marked with a circle on the ds9 display.
autotarg -- If this is selected and the wcs is successfully found, and you supply target coordinates, the centroid of the target will be found automatically (by automatically running the IRAF imexam command 'a'). Otherwise, you'll have to type 'a' yourself (see below), or enter the coordinates manually if autocentering will converge on the wrong object (a problem if your target is the fainter member of a close pair)..
There are two ways to feed in the nominal RA and dec of the target, so the program can mark and/or centroid it on the image:
name_no_blanks rah ram ras decd decm decs equinoxNote that if your list is in some other directory than the one you're working in, you'll have to give the full pathname, as in the example shown.
Feige98 14 38 15.76 +27 29 32.9 2000.0
Finally, there's the rawtarg parameter, which turns off the centroiding of the target. This is useful if, for example, you're centering on a faint object with a nearby bright companion. In this case, inspect the acquisition image to find the X and Y pixel coordinates you want, and type them in when the program prompts you.
The pushprobe parameter is not implemented.
When you run osctrtask, the acqimage (and optionally the slitimage) are automatically displayed in ds9; acqimage is in Frame 1, and slitimage (if any) is in Frame 2. You will need to use ds9's Frame commands 'next' and/or 'previous' to bring up the appropriate image.
Unless you're autocentroiding the target and using a previous slit position, you will need to mark one or two positions on these images using a cursor. To get these positions, the program runs the IRAF imexam task and parses the output. Unfortunately, the programming trick used makes it impossible to see the results as you go along -- when you mark the target, or the slit, nothing happens. This is awkward and disconcerting, but it's normal (and apparently inevitable).
Note that when imexam is alive, you get a "blinking life preserver" cursor in ds9 -- if you have an arrow cursor instead, then imexam is not in control yet. A common reason for this is that there's an unanswered prompt in the window where you're running pyraf - possibly something like "Display frame :" Just hit enter to keep it happy, and you should get the blinking life preserver in ds9, and be able to proceed.
Depending on what the program needs, it will tell you to mark the slit with an 'x', the object with an 'a', or both.
All these procedures go better if you have really accurate target coordinates, good to the sub-arcsecond level. The JSkyCalc24mGS program that moves the guide probe uses the UCAC3 as the base catalog, and the guide star coordinates are updated for proper motion, so their coordinates are typically good to less than 0.1 arcsec.
Experience has shown that the center of the 'center' slit is not perfectly aligned with the guide probe coordinate system. In our 2010 September run, we adopted the practice of applying an extra offset of dx = -180, dy = -100 to the JSkyCalc24mGS coordinates -- basically, we just moved the guide probe using JSkyCalc24mGS, then manually made the small extra move using the dx and dy boxes in the xmis window, and then centered the guide star and started guiding. We always used the same nominal guide star pixel coordinates in the Maxim DL guide software, and with accurate target coordinates the stars were already in the slit (though not necessarily dead-center).
It's important to be aware that in the Maxim DL system, if you're in the GUIDE tab and have the expose radiobutton selected, then when you hit Go, the camera will take an exposure and the nominal camera XY coords for the guide star will be reset. This is OK when you first set up on the field, but for subsequent centering steps you'll want to control changes in the nominal XY coordinates manually.
The OSMOS manual claims that once the slits have been installed in the filter wheel, their projected locations on the detector are very steady. For this reason, I've offered the option of re-using the slit position, by turning off twoframes and supplying the appropriate slitxpar and slitypar. It might be best to treat this claim cautiously, especially if your program calls for observations at funny telescope positions or rotator angles.
In order for the getwcs option to work, you need accurate telescope coordinates -- within 20 or 30 arcsec, ideally. These should be the coordinates of the field center, not an offset slit. The JSkyCalc24mGS program provides field center coordinates for the offset slits, even if you have the instrument rotated. If you need to rezero the telescope coordinates, be sure to insert the appropriate field center coordinates in the RA and dec boxes in xtcs, and then carefully check that the RA and dec have reset to the correct values before moving away. If you blunder when you re-zero coordinates, and move away before you realize your mistake, you have a real mess on your hands, so be careful. (The 2.4m user's guide, on the mountaintop web server, has a section on 'how to restore lost pointing').
Note that the only places you need to account for the image rotator are in the JSkyCalc24mGS guide star selector, and in the MaximDL rotation setting -- once the instrument is mounted, the guide stage rotates with the instrument, so they're in the same frame. However, mounting the instrument at a different angle does affect the relation between the guide stage and the instrument; that's the reason we need the slitns parameter.
Because the 4x1k readout option is long and skinny the star-matching algorithms read a strip of the catalog that should coincide with the field of view, more or less. This involved a rewrite of the star-matching software, which had assumed that the field is a square patch. The star-matching software needs to know both the mounting choice and the instrument rotator, but it gets the instrument rotator from the image header.
The bias-subtraction scheme splits the image into four pieces, bias-subtracts each piece, and then pastes the pieces back together. In the process, any header information that is not explictly copied into the new image is lost. I have copied some of the most informative header parameters into the new images -- title, ra, dec, filter and so on -- but beware that much of the header information will be missing from acqimage and slitimage.
Footote: What is the world coordinate system? The WCS refers to the "real" coordinates in an image, e.g, the RA and dec rather than the XY pixel coordinates. An image with WCS has keywords written into the header that express the transformation from XY to "real" coordinates (in this case RA and dec). DS9 can interpret WCS, so when the WCS in an image is set, and it's displayed in DS9 the RA and dec that show in DS9 are the real RA and dec, not some lame guess.
Important note: DS9 is only 'wcs-aware' if you use its own 'File' menu to display images. If instead you use 'display' from within IRAF, nearly all the header information is lost. In addition, all the dynamic range is lost because IRAF was written in the dark ages of 256-level displays; if you use display from within IRAF, it forcibly maps the original image into a fake 8-bit image, and then displays the fake image. There is no good reason to display from within IRAF -- imexam and the like work fine if you don't -- and it basically cripples DS9. Make it a practice NEVER to display an image from within IRAF. Instead, use the File pull-down menu in ds9, and choose Open and use the dialog box. You'll never go back.
[Back to wcs loading discussion ... ]
This way of setting up a pyraf task depends on the existence of a parameter file, which is a short file that gives the names of the parameter, their data types, default values, and so on.
The file must be named
If this is corrupted for some reason, you can grab a fresh copy by getting into the /lhome/obs24m/iraf/uparm directory, and typing
cp /usr/local/pkg/thorsoft/scripts/osctrtask.par .[Don't overlook the final dot.] Once you're sure you have a fresh parameter file in the right spot, go back to where you were working within pyraf (restart if need be), and repeat the
pyexecute('osctrtask.py')command. Now, it should work.
[Back to the instructions.] Other Useful OSMOS tasks: Once you've successfully taken a spectrum, there is a program called osqlsp that will give you a properly bias-subtracted, optimally extracted, sky-subtracted, and (optionally) wavelength-calibrated version for quick-look. This is not documented separately, but it is functionally almost identical to the qccds program for CCDS spectra. You should be able to use the qccds documentation to run this; just substitute 'osqlsp' for 'qccds' in the instructions.
For direct images, the task osbias is very useful. It subtracts the bias strips, reassembles the four images, and attempts to find a World Coordinate System solution and mark your target right on the image. You can get this in just the same way as osctrtask -- follow the same instructions as below for making a local copy and doing the pyexecute to make pyraf aware of the task.