Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/spst/lrpg/documentation/procedures/lrpg_how_to_script_spike.doc Дата изменения: Fri Feb 27 01:19:06 2004 Дата индексирования: Sun Mar 2 12:06:09 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. Load special patches, LISP code, or other preliminaries (if necessary).
2. Load a control file which specifies a constraint set and other SPIKE
parameters.
3. Explicitly Load desired HST proposals into the image.
4. Proposal, plan, data, and SPIKE state manipulation. This includes:
O Perform plan window manipulation (PW loads, generations, deletes,
etc.)
O Write-out or "dump an image" of SPIKE's complete internal state.
O Write out reports to files.
O Write 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 cv-desc files for the specified proposals.

d) (run-scheduler :to-schedule '("" . ) :sogs-start "" :sogs-end ""
:value-selection-file "" :critic-file "")

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 batching up SPIKE jobs:
O progress can be monitored remotely via the stdio log files
O an interactive session is not needed if there is some reason that is
undesirable
O there is some speed gain in not having stdio directed through an emacs
session
O SPIKE can be run from a terminal 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.