Should I move my proposal's plan windows?

Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spst/lrpg/documentation/procedures/lrpg_should_i_move_my_planwindows.html
Дата изменения: Fri Apr 2 23:34:13 2004
Дата индексирования: Sun Mar 2 12:46:05 2014
Кодировка:
Поисковые слова: п п п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п р п

You have this proposal, and SPIKE placed its windows either too far (likely) or to near (yeah, right) in the future. You "need" to move the plan windows to a more suitable location.

So, the question of the day is: what do i need to know before i can attempt to move the visits' windows? In what follows, we'll point out the basic things you need to know and be able to do in order to answer that question.

Are there any conflicts in the place i want to move them to?
Is there enough room where i want to move them?

Conflicts

If your visit has plan windows that will become quite short, examine the file /home/lrp/current_available_list.rpt to determine if there are any direct conflicts. If this file is empty, then type the following command:

unixprompt> do_vms do available 2000.001 2010.001

A list containing an equivalent contents will be generated and printed to the screen. You will need 132-column width screens to read these files.

Some things to note about the contents of the file for proceeding with the evaluation:

Entries are ordered by plan window end_date.

Column 4:	Orbit size.
Columns 5 & 6:	Minimum plan window start time & maximum plan window end time.
Column 7:	Flag showing length of plan window in days if less than about a week.
Column 8:	shows the number of windowlettes in the plan window (how choppy).
Column 9,10,11:	Future suitability according to SPIKE (explanatory key to table columns at top of file).

^{What to do:}

Scan down to where your visits would go if they were to move and note the extent and degree of visits which cross that timeframe.
Also look at those visits whose plan windows end within 1 week after where your visit would end. Are there a lot of such orbits? If so, then there could be problems getting all of the other visits and yours to fit.

Danger Areas

There are a number of weeks that should be avoided, since they are crowded by large programs: LRP Hotspots. Only place visits in the redzones with the advice and knowledge of the other planners.

Test Calendars

You might want to fire up SGS and see if there are any test calendars which could illuminate the problem. Most planners have been embedding some form of their initials in the calendar name.

Calendar Boundaries

If you want to assign plan windows to a certain timeframe, and you know that due to tight links or time critical windows that the visit(s) need to go in a narrow range of places, check to see if that time crosses a calendar boundary.

Resource Level Issues

In many ways, this is the trickiest concern.

The procedure for looking at and analyzing LRP resource levels is given at this URL.

Running the Scheduler

^{What to do?}

total orbits, SAA-free orbits,

SAA-hider orbits

su_track.lrp_state=ready

If the visit is not su_track.lrp_state=ready then you may try running the scheduler yourself. You may either try doing this from within the "full image" that you are working in to display the resource plots, or from a "bare or empty image" that you can start directly out of the PC toolbox.

The procedure for running the scheduler on the command line can be found at this URL.