Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spst/lrpg/documentation/procedures/lrpg_cycle9_lrp_build.html
Дата изменения: Tue May 23 23:59:40 2000
Дата индексирования: Sun Mar 2 10:03:04 2014
Кодировка:
Поисковые слова: comet tail
The Mechanics of How to Build A New Cycle LRP

Details of How to Construct a New Cycle LRP

INTRODUCTION

This is a more detailed document than the outline/overview in that specific tools and commands are named. Hopefully, it serves a dual purpose--documenting how Cycle 9 was built and providing a guide to build future Cycle LRPs.

  • PRE-CYCLE ORBIT ACCOUNTING

    • See the document http://www.sogs.stsci.edu/spst/lrpg/lrpg_orbit_accounting.html . A number of different tools and techniques are necessary to obtain the requisite info.

  • TAC & MANAGEMENT ORBIT RECOMMENDATIONS

    • A memo from the planning team needs to be drafted for the OPT and HOD management for purposes of defining what resources will be available and what likely consequences follow from restrictions within the LRP and know restrictions which may impact operations.

  • MONITORING INGEST PROGRESS & PRE-BUILD ACTIVITIES

  • BUILDING THE NEW CYCLE LRP

    1. Visit and Proposal List Compilation and Categorization

      2. The lists of Proposals and Visits in the cycle was generated by the VMS tool SPIKE_LAYERS. Besides generating lists of proposals and visits, the intent of this tool is to produce a categorized list of visits, each visit tagged with a number representing how tight the constraints are, how difficult it would potentially be to schedule on a calendar, and the likelihood of conflicting with other visits.

      This categorization is used as input by the python script which constructs the corresponding LISP/SPIKE script.

      The lists contained within that tool are (successive exclusion, in the order which the visits are identified):

      1. Integrated CWs < 1 week . . . . . . . . . . . . . . . . Category 1
      2. After-Bys w/ Infinite Tolerances. . . . . . . . . . . . Category 7
      3. After-By Tolerance < 1 week . . . . . . . . . . . . . . Category 2
      4. Group & Sequence Within w/ Tolerance < 1 week . . . . . Category 2
      5. CVZs. . . . . . . . . . . . . . . . . . . . . . . . . . Category 3
      6. After-By Tolerance < 1 month. . . . . . . . . . . . . . Category 4
      7. Group & Sequence Within w/ Tolerance < 1 month. . . . . Category 5
      8. Integrated CWs < 1 month. . . . . . . . . . . . . . . . Category 6
      9. Remaining Linksets. . . . . . . . . . . . . . . . . . . Category 7
      10. Large MAMA Visits . . . . . . . . . . . . . . . . . . . Category 8
      11. Remaining Large Orbit Visits. . . . . . . . . . . . . . Category 9
      12. Remaining MAMAs . . . . . . . . . . . . . . . . . . . . Category 10
      13. SAA Hiders. . . . . . . . . . . . . . . . . . . . . . . Category 13
      14. All Short Alignments. . . . . . . . . . . . . . . . . . Category 14
      15. Medium Sized Alignments, partial SAA schedulers . . . . Category 12
      16. Remainder . . . . . . . . . . . . . . . . . . . . . . . Category 11
      For future Cycles, the order the queries are executed in and the category sequence as well as the number of different categories should be reviewed to determine if they are appropriate.

      Note that the ordering of the categorization does not exactly match the sequence in which they were generated. This was necessitated by several different requirements and a few workarounds that were necessary.

      After the lists are generated, work then proceeds on the unix side.

    2. SPIKE Script Building & Execution.

      3. For the Cycle 9 runs, work never proceded beyond the 'test' phases wherein we intentionally ran the tests from /data/ringworld1/jordan/cyc9/ instead of a directory tree within /data/ringworld1/lrp/ . Ultimately, the 'tests' slowly evolved and yielded a product which (fortuitously) turned out to be useful.

      SPIKE Script building still seems to be somewhat of an art since many characteristics and behaviors of the various commands, the sequence in which they are run, the conditions under which they are executed, and known system shortcomings all impact how best to construct the commands in a way to achieve the stated goal.

      Cycle 9 was unique in that a more ambitious approach was adopted in SPIKE/LISP scripting. The goal was to layer planning of visits restrictions by means of direct control of which visits SPIKE would attempt to schedule. Unfortunately, the net result of this was to unveil a number of shortcomings in SPIKE.

      Bugs and Unexpected/Undesired Behaviours Discovered:

      The SPIKE scripts themselves are largely composed of the commands that can mostly be found on one of the documents in the SPIKE LRP commands page. Only a small subset of those commands are actually useful in preparing an LRP, at least as currently practiced.

      Useful SPIKE/LISP commands:

      In constructing a SPIKE/LISP script, one must first decide what the script is intended to do. The approach adopted for most of the scripting was to create and modify a python script to generate the SPIKE/LISP script because of the repetitive, looping nature of the sequence of commands for building an LRP. For example, it was desired to run the scheduler ~ 14 times sequentially on different categories of visits. Python was used to read in the visits and their categories, and construct a LISP script or series of LISP scripts as well as the unix invocations script(s) to run these SPIKE/LISP scripts.

      By way of specific example, we will point the reader to /data/ringworld1/lrp/cycle9/build_cycle_9/cyc9/t24/ as a case in point. This directory contains most of the files used to construct the LRP which was the parent of the LRP ultimately released as the Cycle 9 LRP. One element not contained in that subdirectory is the SPIKE/LISP image used as an element in the chain of products.

    3. Evaluating the Output of the SPIKE script.

      4. A number of details need to be addressed along the way to evaluating the quality of the LRP output by the SPIKE script?

      1. Did the SPIKE/LISP script execute & complete successfully?

        2. If not, then there will either be obvious signs of failure or not so obvious signs.

        Obvious Signs

        Not-So Obvious Signs

        Scan the output of the log file, particularly the end of the log file. Below is an example of how best to do this:

        unixprompt> tail -5000 log_file_name.log | more

        If the job did complete successfully, evaluation can proceed.

      2. Evaluation

        3. Two important tools in evaluating the quality of the output product are the diff_report and the main report. Currently, these are available only on the VMS side of the fence.

        Other important tools are the LRP plot tools. Also, at current, the full battery of plots is only available on the VMS LRP account.

    4. Iteration

      5. If errors occurred in the script or the output is not judged acceptable as a base for proceeding upon, then going back to earlier steps in the procedure are necessary.

    5. Repair of the Acceptable Output LRP

      6. If an output LRP is judged acceptable as a forming the essential endpoint of the build process, it may then have any necessary changes made to it that are required before it is 'released'.

    6. Release of the Accepted LRP.

      7. Here, release of the LRP follows naturally to allow the LRP to become the new basis of nightly batch runs and source of plan window information to PCs and the outside world.

      From the planning VMS account, the LRP may be released in the following way:

      VMS_PROMPT$ DO RELEASE_LRP lrp_name