Next: The RPS2 Generic Distributed Computing Framework
Previous: A Tcl/Tk-Based, Intelligent Graphical Editor for Preparing HST Programs
Table of Contents --- Search ---
PS reprint
David J. Bell
National Optical Astronomy Observatories,1 Tucson, AZ 85719
Christopher D. Biemesderfer
ferberts associates
Jeannette Barnes
National Optical Astronomy Observatories,1 Tucson, AZ 85719
Phil Massey
Kitt Peak National Observatory,1 Tucson, AZ 85719
1Operated by the Association of Universities for Research in Astronomy (AURA), Inc. under cooperative agreement with the National Science Foundation
The system has been in use at KPNO during the past four observing semesters and now processes several hundred documents each semester. A modified version of the software has also been in use at CTIO, with both observatories now receiving the vast majority of all proposals electronically. Although a few problems have occurred over this time period, they are clearly outweighed by the time-cost benefits of such an automated system.
Kitt Peak National Observatory accepts observing proposals from its user community twice annually. Incoming documents, at a rate that can exceed 100/day near the end of a proposal season, must quickly be accepted, acknowledged, and accounted by a small office staff of just two or three people. Further along the processing stream, a wealth of observer and project information must be taken from the proposals and entered into observing databases for record keeping and scheduling needs. Many of these tasks are best handled in an automated manner.
Such an automated proposal handling system has now been in use at KPNO during the past four observing semesters. We present here a description of the system, including statistics regarding its usage since being introduced, and a brief discussion of its advantages and some problems that have occurred.
The process begins when remote users retrieve LaTeX template forms either by anonymous FTP or through an automated e-mail return system. These forms are filled in and sent back to KPNO by electronic mail where the incoming mail is parsed with the UNIX procmail utility and processed with C-shell scripts. Acknowledgment or error messages are automatically e-mailed back to the user for each processed file.
Each new proposal is assigned a unique identification number which is relayed back to the submitter in the first acknowledgment message. Many proposals include documents ancillary to the main LaTeX form: PostScript figure files and queue-observing coordinate lists. Such files are mailed in followup messages by including the proposal ID on the subject line so that they too can be automatically processed and stored with the proposals. A flow diagram of the processing system is shown in Figure 1. UNIX scripts can be used to globally process and print out the final proposals, and to extract information into tagged input files for observatory databases.
Figure 1: Flow diagram of the processing system.
Figure 1: PS 63 Kb
The system has been in use at KPNO during each of the past four
semiannual proposal seasons, while optional paper copies have continued to
be accepted by ``snail mail.'' The number of electronic proposals has
increased each semester, while paper-copy submissions have
steadily decreased (Table 1, Figure 2).
Figure 2: Bar graphs of electronic and paper proposals received.
Figure 2: PS 76 Kb
Table 1: Number of electronic vs. paper observing proposals received.
That the vast majority of users now choose the electronic option speaks for the success of the system. Electronic mail is a familiar interface to even novice computer users, and very little LaTeX knowledge is required to fill in the template forms.
LaTeX files possess a significant advantage over many other document formats in that they are ``living documents'' with information that is well-marked with tags. They are easily edited and reformatted locally, and much of their information can be automatically extracted with processing scripts. Furthermore, LaTeX is widely available on virtually all platforms commonly used by astronomers.
The system has proven itself to be quite flexible as it has been repeatably expanded and adapted to accommodate other document processing needs. A modified version of the package has been successful at CTIO, and was used for the abstract submission system for this meeting. A similar system is now being used to process all files needed for KPNO queue observing.
Despite its successes, the system has not been without a few problems. These have been addressed on a case-by-case basis, with the system often modified to minimize future occurrences. Version incompatibilities of processing software have sometimes led to submitted proposals which won't compile at KPNO or that appear different from what the user intended. These problems can be handled by keeping the KPNO software up to date and by creating more version-tolerant LaTeX style files. Some very large or otherwise unusual files have had trouble making it through the mail intact. A processing module was added to screen for mail-truncated messages, and users are instructed to use FTP for troublesome files. By far the most frequent problems have been due to simple errors in the submitted forms. Instructions and examples have been enhanced to address the more common problems, and many of these should diminish as users become more comfortable with the process. The formats of some fields are not well defined, making extraction of the information difficult without human intervention. By standardizing input fields so that the information they contain can be easily recognized, more proposal data will be extractable for automated loading into observatory databases.
As remote observing modes become more common, many observatories will rely on automated systems for receiving and processing program information. In the past two years, the KPNO observing proposal system has performed well and shown great flexibility, thanks largely to its use of LaTeX. Attempts are continually being made to standardize software and simplify instructions so that the process is easier for users on both ends of the processing stream.