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 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 "<filename>") 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 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.