Subject: Improperly Prepared 3.5m Scheduling Requests

From: Ed Turner

Submitted: Mon, 23 Sep 2002 22:15:37 -0400 (EDT)

Message number: 611 (previous: 610, next: 612 up: Index)

The relative ease, informality and flexibility of the APO 3.5m scheduling
process and forms (compared to many other facilities) is an advantage
for users of the telescope, I hope and believe.  However, this approach
has also had some negative consequences that are making the scheduling
of the telescope increasingly difficult and frustrating.  Indeed, improperly
and inconsistently prepared scheduling requests, submitted by 3.5m users
through their institutional TACs and schedulers, have increased
in frequency and "severity" to the point that they have become a major
obstacle to the accurate and timely preparation of the telescope's
quarterly observing calendars.  I strongly request that all those submitting
these forms take care to make sure that they are properly prepared and
that each institutional scheduler carefully proofread their submissions
before sending them to me.

Starting in 1Q2003 I will begin to more freely exercise the option of simply
not scheduling programs for which an incorrectly prepared scheduling
request is submitted.  Instead I will simply assign the relevant number
of half nights of the appropriate moon phase to the institution at whatever
time they most conveniently fit into the observing calendar (i.e., typically
during low demand parts of the quarter).  It will then be an institutional
responsibility to assign the time as best it can internally.  Obviously use of
this option will cause everyone concerned a lot of extra hassle and result
in a less scientifically productive use of the telescope, so I very much hope
that it will rarely be necessary.  Some examples of the specific problems
which I hope that we can avoid in the future are given below.

In a separate following message, I will send the current version of the
scheduling request ASCII template and its accompanying instructions.
Many of the problems result from users incorrectly understanding what
information is being requested in specific fields of the template.  It would
be very helpful if everyone could consult the fairly detailed instructions to
determine where to put all the necessary info.

The current scheduling request template may be modified or perhaps
replaced with a web form version fairly soon, but the issues discussed
here will still apply to future versions of the template.

This message will undoubtedly seem needlessly bureaucratic and nit picky to
many, and it is indeed the case that a careful reading of most of the
submitted requests provides all of the information necessary to schedule
the program, even if it is not given in the right field or requested format or it
requires an informed "reading between the lines" to guess omitted info.
There would be no problem if only one or a few programs were involved, but
with a few dozen per quarter to be scheduled, the added time and distraction
of havng to give most requests an individualized reading  to extract the
necessary information becomes serious.

The ASCII template was intended to be used for *scheduling requests*, not
*observing proposals*, but most of the institutions are now using it for both.
As a result, there is often information included which is not needed for
scheduling and which makes it harder to quickly find the information that is
needed.  One approach would be to separate the proposal and TAC allocation
process into two steps, so that a PI does not have to simultaneously try to
make the scheduling request clear and concise while making the proposal
detailed and compelling.  Another, more streamlined approach, would be to
stick with one form and step but to put all of the detailed information intended
to "sell" the program into the SCIENTIFIC JUSTIFICATION section, which it should
not even be necessary to read during the scheduling process.

For those interested in some details of the types of problems that seem to
be becoming more and more frequent, I list some of the more common
ones below:

- The most common single problem is putting important information in the
wrong field.  Some proposals put much critical information in a narrative
form in the SCIENTIFIC JUSTIFICATION section or put information there
which modifies or contradicts info given in the more specific fields higher up
in the form.  Or, for another example, a request might give a description of
the program's filter requirements (which is not even a scheduling issue) under
the SPECIAL REQUIREMENTS field where I look to find dates that the PI or
observers cannot use for non-astronomical reasons.

- Another common problem is that the necessary info is in the right field but
that it is not readily located at a glance because a lot of other extraneous
material is also included.  For example, the best way to indicate dates on which
the observer(s) will be unavailable is simply to list them, as opposed to "hiding"
them in a narrative paragraph which explains how the observer(s) will be
otherwise occupied.  Similarly, if it is possible to just say that the program's
targets require first halves early in the quarter, I can absorb that information
more quickly if it is not diluted by a discussion of how these particular objects
are needed to complete a magnitude limited sample and thus allow some
specific statistical quantity to be determined (which would be an appropriate
discussion for the SCIENTIFIC JUSTIFICATION section, of course.)  Another example
is that if both the time the PI requested and the time the TAC allocated are listed,
I must be careful not to read off the wrong one when glancing at the form.

- Scheduling requirements written by the PI for the requested amount of time
are often rendered ambiguous or impossible if the TAC cuts the request.  For
example, a PI may request 6 half nights scheduled in blocks of two in each of
the quarter's three dark runs, but when the TAC only allocates 4 half nights of
dark time to the program, it is no longer clear how to proceed - two blocks of
two half nights in just two of the dark runs (which two?) or some time in each
of the three dark runs (how split up) or...?  Again, by reading the request in
detail, I can usually make a reasonable guess, but it is a distraction from
assemblying the schedule and may not even be the right guess.  In general, if a
program's request is cut by the TAC, it would be best if the PI were allowed to
revise the scheduling constraints/preferences before it is submitted.

- It is clear that most regular users of the telescope edit previous requests
and resubmit them in later quarters.  I do that too, of course.  The problem
occurs when an old requests is not completely updated.  For example, it is not
uncommon to see scheduling requests that were clearly written for a different
quarter (e.g., asking for September nights in a 4Q request).

- Requests should not require me to run SkyCalc for the PI.  For example, if a
bright time program wants to impose the constraint that it be scheduled when
the target is more than 30 deg from the Moon, it should specify the dates
that are or are not acceptable for that reason explicitly.  In general I should not
have to think about the RA's and DEC's of a program's targets explicitly, and it
is not even required to list them or give ranges.  However, especially for low
priority programs which cannot be scheduled on there ideal dates, it is often
useful to know something about target positions, so there is no harm in
listing them.  It should not, however, replace an indication of preferred and
acceptable dates or some more complex, but explicit, scheduling constraint.

- Finally there are sometimes scheduling requests that are impossible to meet
due to celestial realities, for example requests for full nights of gray time or
for a program's bright halves to be scheduled before its dark halves in month
which starts going into a dark run and ends coming out of a bright run.

I feel, and hope that users agree, that our ability to schedule the 3.5m in an
unusually flexible and responsive way is one of its unique strengths and better
features.  I will greatly appreciate your help in making the process of
assembling the schedule work as well and smoothly as possible.  As always, I
welcome any comments or suggestions on the scheduling process; either
post them on apo35-general or email them directly to me, as you prefer.

Ed Turner

APO APO APO APO APO  Apache Point Observatory 3.5m  APO APO APO
APO  This is message 611 in the apo35-general archive. You can find
APO  the archive on
APO  To join/leave the list, send mail to
APO  To post a message, mail it to