Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spst/lrpg/documentation/procedures/lrpg_how_to_script_spike.pdf Дата изменения: Fri Feb 27 01:21:02 2004 Дата индексирования: Sun Mar 2 12:06:12 2014 Кодировка:

How to write a simple "batch job" for SPIKE.
Introduction: As a preliminary, to interact with SPIKE, one must invoke a SPIKE image. There are two different kinds of SPIKE images: bare, and non-bare. The default "bare" spike-operational image (which has no proposals, constraint sets or control files loaded into it), can be brought up from an emacs window by typing "control-c s". SPIKE automatically starts up and leaves the user at a LISP prompt. A non-bare image is typically a "bare" image which has had a number of operations performed within it and then is saved out to a separate SPIKE image by the user. This image can then later be called up and used in a separate session. To interact with SPIKE through a batch job, one must place the relevant LISP/SPIKE commands into a .lisp file and then load that file into SPIKE either interactively in an emacs window or in a batch-mode script. Here, we describe how to perform this in a SPIKE script. The Basic Command Flow for Using SPIKE: Let us first outline the essential command flow for feeding a bare SPIKE image. Although one can vary the following sequences somewhat, the general process flow can be characterized as follows: 1. 2. 3. 4. Load special patches, LISP code, or other preliminaries (if necessary). Load a control file which specifies a constraint set and other SPIKE parameters. Explicitly Load desired HST proposals into the image. Proposal, plan, data, and SPIKE state manipulation. This includes: O Perform plan window manipulation (PW loads, generations, deletes, etc.) O W rite-out or "dump an image" of SPIKE's complete internal state. O W rite out reports to files. O W rite out an LRP to the database. O Exiting SPIKE.

There are a number of other functions which can be executed within SPIKE at various stages such as writing out constraint windows to the database, invoking/executing unix shell programs or scripts, generating time-stamps and other messages in the stdi/o stream, and modifying SPIKE control parameters. Closer Look at a Specific Example: There are copious examples to be found in the subidrectories of /home/lrp/c12 , /home/lrp/c11 , and similar trees. As a specific example, let us take the scripts found in the directory /home/lrp/c12/build_c12/t07/ . This tree contains scripts, input and output files associated with a trial LRP Cycle build attempt before Cycle 12 began. In here you will find a number of files, but let us start closest to SPIKE itself. Note the file .lisp . It exemplifies the central means of communicating with SPIKE in a batch mode--it contains a set of SPIKE commands which are executed sequentially when fed into SPIKE. Although this file can be loaded during an interactive SPIKE/emacs sessions by typing (load "") at the lisp prompt, we will show how to feed this file as input to SPIKE purely through a unix shell invocation. Notice the sequence of commands fed to SPIKE in the *.lisp file: a) (load-a-control-file "") This is almost always the first necessary command in a SPIKE script. SPIKE will automatically search for the control file name in the directory /data/operational1/control/ . These files tell SPIKE about its fundamental behaviours such as what HST constraints to assume, the planning interval, special files to load, the resource limits to employ, and the state of numerous switches and parameters needed for planning.


b) () c) (load-props :props '( ...) ) This command tells SPIKE to read in proposal information from the database, tic-files, and cvdesc files for the specified proposals. d) (run-scheduler :to-schedule '("" ... ) :sogs-start "" :sogs-end "" :value-selection-file "" :criticfile "") The run-scheduler command tells SPIKE to run the plan-window scheduler on the specified visits, limiiting plan window generation to between the given dates and using the specified "criteria" and critics files (which control the fundamental behaviour of the scheduler and plan window generation). There are many other parameters which can be used in the run-scheduler command. e) (dump-image "" :directory "") The dump-image command tells SPIKE to se out all internal states and data values to a file such that they can be reloaded and used by SPIKE in some future session. f) (write-plan "" :comment "" ) The write-plan command tells SPIKE to write current LRP states to the database tables such as plan_windows, plan_window_status, plan_orient, lrp_unschedulables, lrp_cat, and lrp_processing_errors. g) (exit) This is a command necessary to terminate the SPIKE process from memory. If it is not used, the process will remain in computer memory consuming swap space or RAM.

Invoking a SPIKE job in a batch mode. There are some advantages to O progress can be monitored r O an interactive session is not O there is some speed gain in O SPIKE can be run from a ter batching up SPIKE jobs: emotely via the stdio log files needed if there is some reason that is undesirable not having stdio directed through an emacs session minal session without requiring the user to stay logged in.

Invoking SPIKE in a batch mode is conceptually quite simple: Unixprompt> Lisp-image ­I spike.image < lisp-command-file.lisp > output-log-file.log & Starting SPIKE this way redirects all standard output to the logfile and feeds all commands from the lisp-command-file.lisp file. However, invoking SPIKE in this way still doesn't allow the user to exit the terminal window without also killing this job. This can be corrected by placing this command within a unix file (e.g., unix-command-file-name), modifying it to be an executable, and then using the "at" command to schedule its execution time: Unixprompt> chmod +x unix-command-file-name Unixprompt> at now


> unix-command-file-name > control-d The process will immediately be scheduled for execution and the terminal window may even be closed without terminating the processes.