Before you can submit a job to Condor, you need a job. We will quickly write a small program in C. If you aren't an expert C program, fear not. We will hold your hand throughout this process.
First, create a file called simple.c using your favorite editor. Put it anywhere you like in your home directory. In that file, put the following text. Copy and paste is a good choice:
% mkdir ~/condor-test
% cd ~/condor-test
% cat > simple.c
#include <stdio.h>
main(int argc, char **argv)
{
int sleep_time;
int input;
int failure;
if (argc != 3) {
printf("Usage: simple <sleep-time> <integer>\n");
failure = 1;
} else {
sleep_time = atoi(argv[1]);
input = atoi(argv[2]);
printf("Thinking really hard for %d seconds...\n", sleep_time);
sleep(sleep_time);
printf("We calculated: %d\n", input * 2);
failure = 0;
}
return failure;
}
type control-d here
Now compile that program:
% gcc -o simple simple.c % ls -lh simple -rwxr-x--- 1 temp-01 temp-01 4.9K Mar 15 16:24 simple*
Finally, run the program and tell it to sleep for four seconds and calculate 10 * 2:
% ./simple 4 10 Thinking really hard for 4 seconds... We calculated: 20
Great! You have a job you can tell Condor to run! Although it clearly isn't an interesting job, it models some of the aspects of a real scientific program. It takes a while to run and it does a calculation.
Now that you have a job, you just have to tell Condor to run it. Put the following text into a file called submit:
Universe = vanilla Executable = simple Arguments = 4 10 Log = simple.log Output = simple.out Error = simple.error Queue
Let's examine each of these lines:
Next, tell Condor to run your job:
% condor_submit submit Submitting job(s)con. Logging submit event(s). 1 job(s) submitted to cluster 6075.
Now, watch your job run:
% condor_q -- Submitter: ws-03.gs.unina.it : <192.167.2.23:34353> : ws-03.gs.unina.it ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 2.0 temp-01 3/15 16:27 0+00:00:00 I 0 0.0 simple 4 10 1 jobs; 1 idle, 0 running, 0 held % condor_q -- Submitter: ws-03.gs.unina.it : <192.167.2.23:34353> : ws-03.gs.unina.it ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 2.0 temp-01 3/15 16:27 0+00:00:01 R 0 0.0 simple 4 10 1 jobs; 0 idle, 1 running, 0 held % condor_q -- Submitter: ws-03.gs.unina.it : <192.167.2.23:34353> : ws-03.gs.unina.it ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 0 jobs; 0 idle, 0 running, 0 held
Notice a few things here. In a real pool, when you do condor_q, you might get a long list of everyone's jobs. So you can tell condor_q to just list you jobs with the -sub option, which is short for submitter, as in:
% condor_q -sub royFor this tutorial, there is probably only one person per computer, so it probably isn't necessary. When my job was done, it was no longer listed. Because I told Condor to log information about my job, I can see what happened:
% cat simple.log
000 (002.000.000) 03/15 16:27:22 Job submitted from host: <192.167.2.23:34353>
...
001 (002.000.000) 03/15 16:27:25 Job executing on host: <192.167.2.23:33085>
...
005 (002.000.000) 03/15 16:27:29 Job terminated.
(1) Normal termination (return value 0)
Usr 0 00:00:00, Sys 0 00:00:00 - Run Remote Usage
Usr 0 00:00:00, Sys 0 00:00:00 - Run Local Usage
Usr 0 00:00:00, Sys 0 00:00:00 - Total Remote Usage
Usr 0 00:00:00, Sys 0 00:00:00 - Total Local Usage
0 - Run Bytes Sent By Job
0 - Run Bytes Received By Job
0 - Total Bytes Sent By Job
0 - Total Bytes Received By Job
...
That looks good: It took a few seconds for the job to start up, though you will often see slightly slower startups. Condor doesn't optimize for fast job startup, but for high throughput, The job ran for about four seconds. But did our job execute correctly? If this had been a real Condor pool, the execution computer would have been different than the submit computer, but otherwise it would have looked the same.
% cat simple.out Thinking really hard for 4 seconds... We calculated: 20
Excellent! We ran our sophisticated scientific job on a Condor pool!
If you only ever had to run a single job, you probably wouldn't need Condor. But we would like to have our program calculate a whole set of values for different inputs. How can we do that? Let's change our submit file to look like this:
Universe = vanilla Executable = simple Arguments = 4 10 Log = simple.log Output = simple.$(Process).out Error = simple.$(Process).error Queue Arguments = 4 11 Queue Arguments = 4 12 Queue
There are two important differences to notice here. First, the Output and Error lines have the $(Process) macro in them. This means that the output and error files will be named according to the process number of the job. You'll see what this looks like in a moment. Second, we told Condor to run the same job an extra two times by adding extra Arguments and Queue statements. We are doing a parameter sweep on the values 10, 11, and 12. Let's see what happens:
% condor_submit submit Submitting job(s)... Logging submit event(s)... 3 job(s) submitted to cluster 2. % condor_q -- Submitter: roy@ws-03.gs.unina.it : <192.167.2.23:32787> : ws-03.gs.unina.it ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 2.0 roy 1/25 12:28 0+00:00:00 R 0 0.0 simple 4 10 2.1 roy 1/25 12:28 0+00:00:00 R 0 0.0 simple 4 11 2.2 roy 1/25 12:28 0+00:00:00 R 0 0.0 simple 4 12 3 jobs; 0 idle, 3 running, 0 held % condor_q -- Submitter: roy@ws-03.gs.unina.it : <128.105.48.160:32787> : ws-03.gs.unina.it ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD 0 jobs; 0 idle, 0 running, 0 held % ls simple*out simple.0.out simple.1.out simple.2.out simple.out % cat simple.0.out Thinking really hard for 4 seconds... We calculated: 20 % cat simple.1.out Thinking really hard for 4 seconds... We calculated: 22 % cat simple.2.out Thinking really hard for 4 seconds... We calculated: 24Notice that we had three jobs with the same cluster number, but different process numbers. They have the same cluster number because they were all submitted from the same submit file. When the jobs ran, they created three different output files, each with the desired output.
You are now ready to submit lots of jobs! Although this example was simple, Condor has many, many options so you can get a wide variety of behaviors. You can find many of these if you look at the documentation for condor_submit.