Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/stories/9.text Дата изменения: Tue Jul 13 19:27:26 1999 Дата индексирования: Sun Apr 10 14:27:08 2016 Кодировка: Поисковые слова: http astrokuban.info astrokuban

Spike and the LRP
=================

A long time ago in a distant galaxy...

Some ramblings about long range planning
from the 1990-1995 era.

Step 1: Loading a cycles worth of proposals.

In order to create a LRP with SPIKE, a cycles worth
of proposals must be loaded into the SPIKE image.
This resulted in the following problems:

A. Initially SPIKE and TRANS were in the same image.
In order to SPIKE a proposal you first had to run
TRANS (Actually there was an experimental way to
run SPIKE without TRANS but it did not include all
of the needed proposal data). As a result SPIKE and
TRANS deliveries had to be coordinated and it took
forever to load proposals into SPIKE. This problem
was fixed by creating a file interface between SPIKE
and TRANS.

B. The next problem was deciding which proposals to load.
There was no good source for tracking visit and proposal
status. There was no access to the PMDB and even if we
had access proposals were not loaded into the PMDB until
late in the process. This problem was part of the motivation
for the ASSIST database.

C. Okay, we now know which proposals we want to run and
enter them as input to SPIKE. The system would chug along
for a day or so and then die. Why? Well, in order for SPIKE
to use a proposal there need to be up to date constraint
windows (this is still true). Invariably a few of the ~350
proposals would have out of date constraint windows. Creating
constraint windows in a lisp image with a few hundred proposals
already loaded would bring the image to a halt. Another problem
was that if a single proposal had a run time error in it then
the whole LRP would crash. In the new system proposals with out
of date windows (or crashes) are ignored and a ASSIST record is
written so the problem can be tracked.

Step 2: So we can create an LRP. What good is it?

SPSS creates schedules for a week. Thus, the original
LRP operations concept was that SPIKE was to plan SUs
to a week bins (i.e. every SU is assigned a week).

I am sure this made PIs happy (until they found that
most visits did not schedule in their assigned week).

D. The problem with this approach is resources. Suppose we
want to actually schedule 140 hours a week worth of science.
If SPIKE put exactly 140 hours worth of science in a week
then SPSS would not be able to create efficient schedules.
The problem was that SPIKE and SPSS had slightly different
constraint models. The fix for this problem was for SPIKE
to over subscribe each week by 100% (i.e. 280 hours worth
of visits). The result of this policy was massive instability
because each week 140 hours of visits needed to be replanned.

E. At this point everyone realized that there was a problem
and that it needed to be fixed. There were lots of plans
for fixing the system. In fact there were plans from the
SPIKE lead, the APSB branch chief, the SESD deputy division
head, the LRP team, and a few others. Unfortunately there
was no agreement as to which plan to take. This resulted
in some thrashing as each plan was implemented just a little
bit.

The happy ending to this tale of woe is that with the creation
of PRESTO the plan window concept was formed and we can actually
create and use long range plans.