Flux processes jobs using a batch system. If you've never used a batch system
before, it's useful to think of jobs as backgrounded processes (eg: ./my_script &
);
batch systems, unlike the interactive shell that you're likely accommodated to
(eg: BASH), queue and execute
unattended programs without requiring (or, generally speaking, allowing) user
interaction.
This chapter is the meat-and-potatoes of this guide and will cover the following topics:
PBS
, and other useful toolsUsing the login server, you'll issue a command that will submit a job to the worker
queue. Once the queue selects your job for execution, a worker node will start
whatever program you've given the job. While the worker node is executing your
program you'll have (generally speaking) very limited knowledge of what is
actually happening (eg: what state the program is in, what messages are being
printed to STDOUT
or STDERR
).
In the context of EECS 470, this means running a synthesis build will involve
logging into Flux, issuing a command to submit make syn
as the program to
run, and waiting until the job has completed. If all goes well, you can start
synthesis on Flux, log off, grab a bite to eat, log back in an hour or two
later, and view the proc.rep
file to make sure everything work as expected.
No more all-nighters in 1695 waiting for builds to complete!