Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spst/lrpg/documentation/procedures/lrpg_load_sms.html
Дата изменения: Fri Apr 2 23:37:06 2004
Дата индексирования: Sun Mar 2 09:04:55 2014
Кодировка:
Поисковые слова: п п п п п п п п п п п п п п п п п п п п п п п п
How to load an SMS into a SPIKE Image How to load flight calendars into SPIKE.

How to load an SMS into a SPIKE Image.

If the current week's calendar build had not been baselined the previous evening, then the calendar will need to be loaded manually. This is the procedure for doing that.

  1. Start an emacs window.

    (Note: LRPGers must have their .clinit.cl file existent)

    unixprompt> emacs &

    or, if you wish to use a faster machine, for example, you can rsh an emacs session to a faster SPARCstation

    unixprompt> rsh -n ringworld emacs &

    an emacs window should appear on the terminal screen.

  2. Load up a full LRP image from emacs.

    In the emacs window, type the following in response to the prompts: 

    1.      {meta} x

      You should see "M-x" appear in the bottom single-line of the window. Type in response to the prompts: 

    2. M-x     shell
       

    3. unixprompt>      imageshell ~lrp/latest.image
       

    4. Memory problems:

        If you see an error about lack of swap space within the first few lines, and it does not scroll up with a bunch of warning messages, you will need to exit lisp & emacs and restart from the beginning.

        • What to do if you *do* encounter this problem:

          "couldn't alloc heap: Resource temporarily unavailable Couldn't allocate initial heap, probably due to lack of swap space."

          If you keep getting this problem, you will have to fire up emacs and lisp on another machine on the cluster, otherwise wait until resources come available. One important thing to check is that there aren't any defunct processes on the machine being used.

          unixprompt> ps -ef | grep defunct

          If you find any, seriously consider killing them, and starting the procedure over from the beginning. If any of these defunct processes were old SPIKE images improperly terminated, they may be hogging too much memory for a new image to be loaded.

      From an LRP window: 

      
$ do latest_cals
%DCL-I-SUPERSEDE, previous value of DSQUERY has been superseded
%DCL-I-SUPERSEDE, previous value of DB has been superseded
Output defaulting to tt:

200 records affected
11 records affected
Latest baselined calendars .                                15-MAY-1997 12:56:18
calendar        load date (UT)
971327D2  1997.129:05:17:10    9-MAY-97  5:17:10
971397D7  1997.134:22:19:59   14-MAY-97 22:19:59
971467D5  1997.129:16:06:21    9-MAY-97 16: 6:21
971537A8  1997.135:12:54:26   15-MAY-97 12:54:26
Latest baselined calendar.                                  15-MAY-1997 12:56:18
calendar        load date (UT)
971537A8  1997.135:12:54:26   15-MAY-97 12:54:26
$

  3. Load an LRP and an SMS into the full image.

    USER(1): (load-pws "97135A")

    This will take a *long* time.

    USER(2): (load-sms "97.153")

    This will also take a while.

  4. Write out the Plan Windows to a new LRP.

    USER(3): (write-plan "97135B" :comment "97135A LRP + SMS for 97.153: 971537C2")

    Yes, this too will take some time. You will see a slow string of in-window messages about Relative Constraint Violations, GUIDE-STAR-CONSTRAINT,0682506 Combination of - ("Guide Star" "Orbital Viewing"), Combination of - ("Guide Star" "Low Sky Window"), Combination of - ("Absolute Orient" "Guide Star"), Combination of - ("Between" "Absolute Orient"), etc.

    When it finishes, you then need to go to an LRP window and type (e.g.):

    $ do diff_lrps 97135a 97135b 97135a_97136b.difference

    to see if there are any differences between these two LRPs.

LRPG Procedures home page