The facility CCDs at MDM -- Echelle, Templeton, Wilbur, and Nellie -- are the only detectors that work with the Modspec and MarkIII spectrographs, and are often the detectors of choice for other projects as well.
These detectors were brought on line in the 1990s, largely by John Tonry and Mark Metzger, using Gen I Leach controllers (made by Bob Leach's company, Astronomical Research Cameras, or ARC), and Sun Sparcstations.
The Leach controllers have held up well through the years, but the computers and some of the other electronics became increasingly difficult to maintain. In the spring of 2011 we decided to replace the controllers and computers with new Leach Gen III controllers and PCs running Linux. This was our second run at project -- about five years ago I had tried to fix the situation by simply replacing the computers and the interface cards, without replacing the controllers. This proved to be Byzantinely complex, far more than I could manage, but at that time we bought some nice little computers made by Shuttle. These are almost unused and in good shape, so we have pressed them into service again.
In the summer of 2011, Bob Barr hand-delivered the first system (Nellie) to ARC in San Diego. They replaced the interface cards, installed their latest software on the computer, and tuned up the system. it was delivered to MDM on 2011 September 14, and first mounted on the telescope on September 16. As of this writing, Templeton and Wilbur are at ARC, and Echelle is to be shipped soon. All three of our controller-card boxes are being modified to take the new controller cards, so there is no turning back.
In the old system, the venerable command-line oriented program CCDCOM served as a front end for the detectors. This had its idiosyncracies but was reasonably observer-friendly.
We have not ported CCDCOM for use with the new Leach controllers, and at this time have no firm plans to do so. The only interace available immediately is Owl, which is ARC's GUI-based program developed largely for engineering work. It has no native provision for reading telescope information and the like, and it isn't optimized for taking astronomical data. Fortunately, it does have provisions for customization using scripts. I have developed software to adapt Owl to the MDM environment, so we have a system that is usable for data taking. The interface is radically different from CCDCOM.
If the keywords don't appear, you have to load them. Just hit the LOAD button at the upper left, and use the dialog box to find mdminterface/mdmheader.xml When you open this, the template of keywords will be set up for you.
Once you have them set up, go down the list and fill in your instrument and your name for the observer. Fill in the GAIN and SECPIX keywords if you know them; for Nellie, SECPIX at the 2.4m is 0.240, for Echelle or Templeton it's 0.275. Templeton at the 1.3m is something like 0.502. [My star-finding algorithms depend on this keyword, but you may not care.]
Now, the most important step: specify the update script at the bottom of the window. For the 2.4m this should be
/home/arc/mdminterface/getmdmheader.bsh [note: 2.4m only.]You don't have to type it, simply use the little yellow folder gui to find it and load it. [ I hope to write the corresponding script for the 1.3m tomorrow (!); if I can manage it, I'll give it some obvious, similar name. ]
This getmdmheader.bsh is an elaborate script written in the bean shell, which is a java-based scripting language understood by owl. It has code to go and read the telescope and MIS information, and to fill in the appropriate FITS keywords automatically. The FITS header script runs when you hit EXPOSE to start an exposure, so all the values are read at that time. The time written is from the system clock, which is on NTP; the prep time for the chip, and so on, is only a second or two, which should be accurate enough for most purposes.
The script can't do everything, though -- you
need to fill in the following by hand
for each new object:
You can change any value by simply editing the field in the Fits header window.
CCDPICNO is useful. It is a running number that increments automatically each time the update script is executed. More on this later.
Where will my data go? In the main window, look for Image file options. Check Save and Increment filename unless you're just fooling around. For the Dir I recommend specifying /home/data or a subdirectory below that (which you should create first), because /home/data is cross-mounted on the other machines, so that on hiltner (for example) it's available as /data/mdmarc1. The mdmarc machines don't have much analysis software (e.g. no IRAF). The cross-mounted directory makes it easy to examine your data more closely, and trivial to copy elsewhere. A similar directory structure was used on the old Sparcstations.
For File:, you'll want something like ccd.1.fit. After you write out an exposure, the software looks for a number before the last "dot" in the filename, and increments it. [Unfortunately, it doesn't insert any leading zeros, so the lexicographic order of the files won't match their actual order.]
Now, it's also useful to have a running number in the header -- that's what CCDPICNO is for. But CCDPICNO updates at the start of the exposure. Therefore, if you set it to one less than the number in the file name before you take the exposure, then CCDPICNO will match the number in the filename in the final product. The sequence of events in updating these numbers means that
You'll want to copy over your data onto hiltner or something pretty frequently as a backup.
Setting up for exposures. This is straightforward.
Obtaining good focus with a slow-reading chip is time-consuming. One good way to do it is a focus frame. To do this, you put several exposures on a single image, offsetting the telescope and changing the focus value between exposures. Each star makes a line of dots that ideally go from bad focus, through good focus, to bad focus on the other side. Knowing the focus numbers for each spot, you interpolate the best focus and set it. Owl has no provision for taking this kind of an image -- an exposure either has the shutter open or not, and the image is read out every time.
I therefore wrote a script called focustest.bsh, which gets around this limitation but only at the 2.4m as of this writing. It uses primitive commands to generate a focus frame, unfortunately with no flexibility for the user. It's only useful when you have a pretty good idea where the focus is (say within 15 units).
These are done with the Sub-array and
Binning dialogs. You invoke these
by clicking on their icons in the lower right
part of the owl window ("Supported Configurations").
For both of them, you make the changes you want,
and then click on RUN to load the
configurations into the controller.
The binning tool is much simpler -- just
select the binning you want, and hit RUN.
I have little experience with
this; be especially careful, because it may
interact oddly with subarrays.
These are done with the Sub-array and Binning dialogs. You invoke these by clicking on their icons in the lower right part of the owl window ("Supported Configurations"). For both of them, you make the changes you want, and then click on RUN to load the configurations into the controller.
The binning tool is much simpler -- just select the binning you want, and hit RUN. I have little experience with this; be especially careful, because it may interact oddly with subarrays.
The Quick Actions section on the gui has some useful buttons, and some dangerous ones!
The little thermometer refreshes the temperature measurement; with Nellie, at the moment, the calibration seems to be off a bit so that the chip registers warmer than it is; it reads -86, but it's somewhat cooler. The shutter button opens and closes the shutter, but it's not intuitive; when it shows open, it's actually closed, and vice versa. The next button, with the red right-sweeping arrow over a grid, clears the chip. This is often a good thing to do.
The last three buttons are to be avoided - they toggle power to the controller, reset the controller, and do other low-level hardware stuff that you probably don't want to mess with, especially if you're observing!
First -- if you do write your own scripts for owl by modifying mine, please do not modify the originals.
If you have some experience with Java, you'll find the bean shell that's used for scripting to be fairly straightforward. The header script makes heavy use of my own classes from JSkyCalc; these are in the mdminterface directory. Controlling the CCD is somewhat more challenging, but the focus script may help you see how to do it.
There is also documentation on the mdmarc machines in /usr/local/Owl/3.0 -- there's a doc directory, and also a Scripts directory that has examples of the code.
The Owl user's manual -- the general-purpose edition by the developer, Scott Streit -- is in the /usr/local/Owl/3.0/doc directory on the mdmarc machines. If I've done my job right you won't need to refer to it.