�������� ���� �� ���� ��������� ������. ����� ������������� ��������� : http://www.stsci.edu/~miller/papers-and-meetings/94-ADASS/phase-1.ps ���� ���������: Thu Nov 22 00:04:34 2007 ���� ��������������: Sat Dec 22 19:12:55 2007 ���������: ��������� �����: arp 220

Electronic Submission of HST Phase I Observing
Proposals
H. E. Payne and D. J. Asson
Space Telescope Science Institute, Baltimore, MD 21218
Abstract. The process of proposing for Hubble Space Telescope observ�
ing time has been revised, to make it simpler for proposers. We describe
the simple, flexible, and robust prototype system created to handle pro�
posal submission. Using tools available in the public domain, we created
our prototype in a remarkably short period of time.
1. Introduction
Proposing for Hubble Space Telescope (HST) observing time proceeds in two
phases: the scientific merits of the proposal are considered in Phase I; only
accepted proposals enter Phase II, where the observations are described in com�
plete detail. The procedure for submitting Phase I proposals has been revised,
to simplify it. Our contribution has been to implement a system for electronic
proposal submission. Our goals were (i) to provide a single form for producing
both the formatted, paper output required by the reviewers and a ``database''
(flat files, really) used by STScI staff to track proposals, (ii) to minimize the
amount of typing required by the proposer, (iii) to provide a robust, secure sys�
tem for archiving and analyzing proposals, and (iv) to provide report generators
for tracking the proposals.
The single form turned out to be a L A T E X template that proposers can
obtain from a mail server, edit, and e�mail back. An accompanying style file
allows proposers to format and print their proposals, since we also require paper
copies. On our end, the e�mailed proposals are carefully archived and sent to
a ``stripper,'' which parses them, checks for a variety of errors and omissions,
sends an acknowledgment back to the proposer, and sends a report to someone
on staff. The procmail program allows most of these activities to be automated.
Many aspects of our system were inspired by the Kitt Peak proposal han�
dling system.
2. From The Proposer's Perspective
We asked proposers to fill out a heavily commented L A T E X template. All input
destined for our electronic database is entered as tagged items, as shown in Fig�
ure 1. Proposers can process the same document to obtain formatted hardcopy.
The layout was designed to give TAC's the information they require, with a
minimum of distracting clutter.
1

% 4. PRINCIPAL INVESTIGATOR
%
% Identify the PRINCIPAL INVESTIGATOR (PI). If you wish to
% include your title (Dr., Prof.,...), include it in ``PIfirstname,
% as in
% ``PIfirstname--Dr. Bob�.
%
% Use ```` to break lines in your address, as in
%
% ``address--Science Hall````4321 University Avenue````Anytown, MD 21218�
%
% but limit yourself to four lines (three ````'s).
``PIfirstname --Michael�
``PIlastname --Shara�
``institution --Space Telescope Science Institute�
``address --3700 San Martin Drive````Baltimore, MD USA 21218�
``telephone --410�516�4543�
``email --mshara@stsci.edu�
``country --USA� % Country of above named institution.
``USstate --MD� % 2�letter code required for US proposers only
%``ESAmember --yes� % Uncomment this line only if you are an ESA member.
Figure 1. A fragment from the observing proposal template.
We (HEP) used the programming capabilities of L A T E X to format the printed
output according to the proposer's input. For example, the observing proposal
format is different from the archival research (AR) proposal format---AR pro�
posals have a budget and do not have observing time requests. By eliminating
the table of observing time requests from the formatted output we spare the
reviewers from a possible distraction. Typesetting tagged items as tables was
an interesting challenge; column widths and formats are calculated on�the�fly to
improve readability, and the Jurriens and Braams supertabular style is used to
break long tables. Default strings highlight omissions, and the proposer's arith�
metic is checked. Although these checks are extremely simple, they did reduce
errors.
3. The Processing
Proposal files received at the STScI are ``stripped'' by perl scripts, finding
the values of the tagged items, and writing them to a file. A thorough check
for missing or illegal inputs is performed, and the complete report is sent to
a staff member. An abbreviated report is sent back to the proposer as an
acknowledgment.
A variety of report generators make use of the information stripped from
all of the proposals. In addition, we generate partially completed Phase II
proposals, to save proposers from entering information they already gave us for
Phase I.
We (DJA) chose an interpreted language to speed development, debugging,
and testing, and at the time, perl was the obvious choice. The entire process�
ing system was assembled in a period of weeks. It's regular expression handling
2

and report generation tools made parsing the L A T E X file quite easy. The re�
port writing tools (format and write) simplified the task of generating mail
messages, analysis reports, TAC reports, and partially completed Phase II tem�
plates. Again, the reports vary according to the user's input. Perl's associative
arrays and interpreted nature allow actual data values to invoke the routines
needed to process them in the parsing or archiving steps, making it a truly
data�driven system! The code is quite generic, as illustrated by the fact that it
was adapted to process the abstracts for this meeting, and will run on the many
platforms that support perl. Perl regular expressions were used to replace the
user specified home institution with a canonical form.
In hindsight, the tools might better have been written in Tcl/Tk, to provide
an easier path to expanding the system to a graphical interface for generating a
Phase I proposal and submitting it.
4. The Glue
The pieces of this system are all held together by the procmail program, a
simple utility to trigger various actions via e�mail, depending on the subject line
or contents of the message. Users can request proposal templates and they are
automatically sent. Proposal submissions are automatically recognized, carefully
archived, and sent off for processing. Bounced mail messages and ``vacation''
messages were automatically set aside. All activity was logged.
5. Status
From the beginning of operations until the Phase I proposal deadline, the system
handled a total of 1360 e�mail messages, which included 350 requests for proposal
templates, 863 proposals (not counting proposals that were corrected and re�
submitted), and 48 PostScript proposals (in lieu of paper copies) in the all�
electronic pilot program. Only 2 all�paper (i.e., non�electronic) proposals were
received. Proposers and staff agree that Phase I went smoothly.
Acknowledgments. Our work took place in the context of a committee
chaired by Mark Johnston. Many improvements were made at the suggestion of
other members of the committee, and it is our pleasure to thank them.
3