John Thorstensen, Dartmouth College
with contributions from Jules Halpern
(Columbia), Rick Pogge (OSU) & Eric Galayda (MDM)
PDF Version (88KB)
MDM Observatory's 2.4m Hiltner telescope is among the largest telescopes in the world that always operates without a night assistant.
It is therefore essential that all observers be familiar with how it works, and attuned to their responsibiities. Each observer is responsible to the MDM observer community for the safety of the equipment, and each observer is responsible to the astronomical community for the integrity of their data. If you're attentive, thoughtful about technical matters, and patient with detail, it's not difficult to get good data at MDM and have a great time getting it, but if you gloss over the difficulties, you will pay.
This document is a guide to observing with the 2.4m. It contains checklists for operating the equipment, designed to prompt experienced users who haven't observed recently, and more detailed sections intended to elucidate common procedures for novices. This document is not intended to replace the more detailed manual in the control room (also available in a web-based version). When in doubt, "Read The Fine Manual".
If you read this document carefully, understand the information discussed here and follow the procedures conscientiously, it will help you avoid many common problems and result in a happier and more productive run. I've spent many hundreds of nights observing on the 2.4m over the years since it was built in 1985, and I've tried in this manual to give you the benefit of that experience. Don't just skim it.
I should be careful here to note that novice observers must be trained at MDM in person by a qualified observer before they can observe alone. MDM has a very small staff, and there simply are not enough people on site to train novices. Since it is hoped that novices will read this guide before their first run, I include some material aimed at them, but novices must not arrive expecting to teach themselves how to observe. Seasoned observers with experience elsewhere may be able to get by on their own. However, if you are such an observer, you shouldn't be overconfident -- MDM has idiosyncracies that you ignore at your peril. Don't forget, there's no night assistant to get you out of a jam.
Organization of this Guide
The first part of this guide is a set of terse checklists to prompt the experienced but slightly rusty observer. The second gives detailed checklsts, a version of the terse lists in which background information and reasoning is given at every step. The third is a set of remarks for the first-time observer, essentially an attempt on my part to resurrect some of the good aspects of the observing culture I grew up with. Subsequent chapters offer overviews of the important telescope systems: computers, telescope, MIS, guide/acquire cameras, and so on.
Note that there are quite a few instrument combinations available, some of which I've never used personally. I'll try to make clear when an item or a statement refers only to a particular setup.
Before the Run [Detailed version.]
Some rules ... [Terse version.]
Before the Run [Terse version.]
my_object 18 23 23.28 -0 14 14 2000where the fields are a name without blanks, the RA and dec in the usual sexagesimal form (hours minutes seconds and degrees minutes seconds), and the coordinate equinox (i.e., "epoch"). Note that you can't use colons to delimit the fields - they have to be blanks. Otherwise, the format is free (you don't have to get the information into specific columns). You'll be selecting objects from the list by typing their names, so you'll want to make the names simple and mnemonic (e.g., tausource rather than 4E_0235.27389+123457-a).
If you have lots and lots of targets in different categories, it's also a good idea to split these out into separate lists, which work nicely in the JSkyCalc program.
The internet from the mountain has somewhat limited bandwidth. If your images are fairly modest, you may be able to just send them home via sftp or scp. If you're taking short exposures with the 4k all night, this may be a bit much. In any case, it is a very good idea to put your precious images on some kind of medium.
I repeat here the link to the local National Weather Service site, at http://www.wrh.noaa.gov/twc.
Top off instrument dewar if needed.
If the storage dewars are up to pressure, it should take roughly five minutes to fill an MDM dewar which has been sitting for 12 hours. If it takes a lot less than this, it's probably a bad fill, and You Will Pay. It's a good idea to just let the LN2 run for a little bit after you think the dewar is full -- nitrogen is relatively cheap compared to the expense of running the observatory and getting you there, and a warm dewar is a true show-stopper.
Note that the procedure above can keep you going even in the event of a more serious failure of the autodome system, as long as you can still rotate the dome manually.
rsync -azvt /data/mdmarc1/mydir/night1 .This will make a copy of "night1" in your current directory. If "night1" already exists, it will copy only new files or files that have changed.
Nightly observing reports are stored on the mountaintop server, and emailed to a short list of recipients that includes the observatory directory, site manager, and the MDM consortium representatives from each member institution. Report data are used to track how much observing time is lost to weather, problems, etc., as well as to keep a permanent record of activities.
If you encountered any problems at all, even ones you fixed yourself (i.e., not common mistakes but real problems that required you to take some special action to continue working), also fill out a Trouble Report Form. There is no such thing as a "minor" trouble report. Often a big problem starts as lots of little problems or quirky annoyances. If we can see a pattern develop in the trouble logs, we might be able to head off bigger problems later. Remember, the run you save could be your own!
Some problems occur when using the data-acquisition software or other computer systems. It will greatly help diagnosis and solve a problem if you can include the verbatim text of any error messages printed when the problem occurred.
I trained as an observer at Lick in the 1970s. At that time
observers were walked through procedures by seasoned staff observers.
This certainly got the job done - we learned the equipment - but in the
long run, the most important lessons we learned from this were not
which buttons to push, or how to develop plates. They were instead
lessons about the experience of observing, and the attitude to bring to
the telescope. As an old curmudgeon I think some of these lessons have
atrophied over the intervening years, as overworked faculty pack
students off to observe with minimal preparation. Here's a distillation
of some of that acculturation, as refined through many hundreds of
nights of observing experience since then, most of them at MDM.
This little blurb isn't complete but might help get you started.
There are two main computers at each telescope. These, along with most of the other aspects of data acquisition and scientific instrument control, are interfaced through a Linux-based workstation. At the 2.4-meter telescope, the main computers are:
In addition, there are specialty machines for the instruments; the facility CCDs are run by mdmarc1, and the Ohio State instruments (OSMOS, CCDS, and TIFKAM) that are run by Prospero have their own machines. Refer to the individual instrument manuals for details.
On all machines, you login to a visitor account named obs24m. Logging onto hiltner as obs24m puts you into the directory /lhome/obs24m. The data all go to directories under /data, where the next item in the path is the machine name (e.g., hiltner or mdmarc1), followed by the user name (obs24m), followed by whatever you want to put there. The /data directories are transparently visible to all the machines. The telescope and the MIS (Multiple Instrument System) are controlled from windows on the workstation. There's one terminal window called bridge, which links the telescope control software with instrument software, and another called xmis2, which runs the MIS. These controls are thoughtfully designed and should be fairly intuitive. The web-based manual has sample displays of these windows, in color.
The facility MDM CCDs (Echelle, Templeton, Nellie) are run by a program called Owl, which runs on the mdmarc1 machine, but still, is brought up through the workstation. Here is a manual for Owl.
It's probably a good idea to use mdm24ws2 for any heavy reduction, as this keeps mdm24ws1 free for observing.
The official manual contains a lot of detailed information on the workings of the telescope. Here's a short overview which may be helpful but which is necessarily very general. (Note also the gotchas listed elsewhere, all of which are known telescope bugs.)
The telescope is generally configured as an f/7.5 Ritchey-Chretian. An f/13.5 secondary has not been used in decades and should be considered decommisioned. It has an equatorial fork mount, built by DFM engineering in the early 80s. The drives are unusual in that they do not have worm gears - rather, the telescope is driven by large steel wheels with smaller driving wheels pressed up against them (friction drive systems).
Telescope Control System, or TCS, is a PC containing a
of custom hardware. In particular, it a galil-based system that
receives signals from the telescope via absolute (HA, dec & focus)
and incremental (dome AZ & rotator position) encoders and input
from the user via the telescope control software. These in turn send
the stepper motors which run almost everything. The TCS was upgraded
a 1995-based Lovell system back to a DFM system in October of 2017.
The user interface for computer control of the telescope is
through a program on the DFM control PC called TCS.
This is fairly
easy to use once you are familiar with the step-through procedures. As
noted earlier, a program on mdm24ws1 called bridge interfaces things
like instrument control and JSkyCalc to the TCS program.
Observations can be made more efficiently by putting your target
list into JSkyCalc ahead of time. The TCS program also allows users to reset the encoders for the rotator and dome AZ, adjust
track rates, control and monitor mirror AC systems and so on. When
the TCS computer program is running normally, the TCS computer's
monitor displays the status of the telescope as well as temperature and
humidity information from various points within the dome.I'd recommend
that you peruse the monitor display carefully on your first day -
be looking at it a lot, so you'll want to understand what you're
seeing and where to locate the most critical features.
In practice, the telescope points to about 30 arcsec rms. The position as displayed has been corrected using a model of the telescope errors. The position displayed is also corrected for refraction, nutation, aberration, and precession, so it should approximate the mean coordinates for the specified equinox.
Note that the telescope has some pointing limits. It can't get extremely close to the horizon, or various hard and soft limits are triggered (see the comprehensive manual for where these limits are and how to back out of them if you get into them). The RA is limited to +/-6 hours to avoid cable wrap problems. Observing under the pole is not really supported, though I hear it's been done.
There are manual control paddles to move the telescope. These have directional buttons NSEW, and two buttons labeled SET and SLEW. The actions of these buttons are quite standard. Holding a directional button down moves the telescope very slowly in GUIDE rate (typically one or two arcsec per second of time - the guide rate can be adjusted). Holding down the SET button results in a much faster rate, about 1 arcmin per second. Finally, the SLEW rate is full-speed, around 1 degree per second, used for major repositioning of the telescope. If you need to slew manually, you must keep an eye on the telescope to be sure you know what it's up to.
Here are a few more aspects of the telescope you'll want to know about:
The focus control:
The telescope is
focused by holding down the IN and OUT buttons on the
paddle. This moves the focus rather slowly. If you also hold down the
SET button, the focus moves much more quickly. Conversely, you can control focus from the TCS program (Telescope>Misc>Focus
tab): enter a target position and hit "Apply". Once focus has
been found, the software will maintain proper separation between the
primary and secondary mirrors to continue to remain at optimal
focus. This is transparent to the user. Note that the focus
value on the TCS display will not change as this routine adjusts
secondary mirror positioning. This is normal and to be
expected. It is also worth noting that this compensartion does
not take into account any change in focus due to filter changes that
may not be parfocal. If changing filters, it is worthwhile to
verify focus (OSMOS filters should in theory be parfocal).
The Instrument Rotator: There is an instrument rotator at the back of the telescope. It has its own encoder. While it is stressed that the user should consult with MDM staff prior to updating this readout, you can set the encoder using the TCS program (Telescope>Initialization>Other Positions tab)--this should not be necessary under typical circumstances. A monitor that echoes the TCS program display is located in the dome so you can watch rotator position as you move the unit via hand paddle. Remember:
If you intend to track an object over a large range of hour angle, you will want to check out the Parallactic... button on JSkyCalc24mGS. This computes the optimal rotator setting over a range of time for your object and gives a graph showing how badly you do if you're off on either side. The "cross-slit refraction factor" given there is a "badness parameter", computed as the tangent of the zenith distance times the sine of the mismatch of the slit away from the parallactic angle. How much effect this has depends on a host of factors, but it you keep the absolute value less than 0.5 or so you should have minimal effects with most setups.
About the MIS
All the commonly used instruments are mounted on an adapter called the MIS (Multiple Instrument System). This provides a number of commonly-needed utilities. Some useful diagrams can be found in the manual.
There are three parts to the MIS. Working downward from the telescope they are
One can also move the guide probe using the JSkyCalc24mGS program. Read on for details.
There are a number of things to be aware of when using the guide probe.
In order to do science, you obviously need to find targets and keep the telescope pointed at them accurately as they track across the sky. The telescope position readouts are nowhere near accurate enough to do this -- you need to be able to acquire and guide on targets. This requires the use of sensitive cameras.
Because every observer needs to know how to autoguide new observers should be sure to READ THE MANUAL that describes how to do this.
Mark III and Modspec users will also want to read the manual for the Andor cameras.
Note that CCDS has its own slit-viewing camera, an SBIG. The Andor cameras are much better than this, but as of this writing the slit-viewer on CCDS has not been mated to an Andor. However, work is being persued to replace the SBIG with one of the FLI cameras, which should prove much more sensitive.
Until mid-2011, the facility MDM CCDs, which are workhorse direct imagers and the only detectors that work on the Mark III and Modspec spectrographs, were run by a program called CCDCOM. (The Ohio State instruments OSMOS, CCDS, and TIFKAM are run using an entirely separate progam called Prospero). CCDCOM was tied to old Sun Sparcstation computers that were unmaintainable, so over the summer of 2011 we shipped the controllers and detectors to Bob Leach at Astronomical Research Cameras (ARC) in San Diego. Detectors have been converted to run with ARC Gen III controllers. The change is not reversible -- the old controllers and computers could not be revived even if we wanted to.
At present (and probably indefinitely), the new system is controlled using ARC's in-house software, called Owl. The Manual for Owl explains the details. Be sure to have a look at this if you're intending to use a facility CCD. Even if you're familiar with the old commands, be advised that this is completely different.
At present the system is a little primitive, but it does get the job done and it is not especially difficult to use. It does at least capture the telescope and MIS configuration information and populate the FITS header keywords automatically. As of this writing there is only one automated script written for Owl, a multiple-exposure "step-and-shoot" script for focusing direct images. There is, unfortunately, no easy way to generate observing scripts "on the fly", but one can at least take a series of identical exposures without any difficulty.
What time should I start?
OK, so the weather's great -- low humidity, photometrically clear, and the wind is a gentle zephyr. So you can open. But when should you plan to start observing? Here are a few remarks on that.
It obviously depends on what time it gets dark. Java skycalc, and its 2.4 m version JSkyCalc24mGS, both have a "Nightly Almanac" button, which pops up a window with the information you want. If you can do it, it's a good idea to open the dome maybe 15-20 minutes before sunset so you can have your dewar topped off and ready to go by the time the sun actually sets (that way you can enjoy the sunset and see the green flash!). There are constructive uses for twilight time. If you're doing direct imaging in the optical, sky flats can start in the U band shortly after sunset, within 5 minutes or so, and the window of opportunity for well-exposed sky flats is pretty short. Bright stars can be found almost in bright twilight to verify telescope pointing. Certain kinds of spectroscopic standards can be done in quite a bright sky -- e.g. 10-th magnitude flux standards should be do-able within 20 minutes after sunset. The limiting factor will be when the sky saturates the guide camera in a very short exposure.
A word about the python-based skycalc GUI ...
There's an older python-based GUI skycalc, which was the prototype of the Java version and resembles it closely. The python version has several useful tools not implemented in JSkyCalc24mGS. These include:
You have (at least) two ways to get at this program:
ssh agungand it should fire right up. The "disp" means it has the planetarium display implemented; the ".py" indicates that it's in the Python language.