Difference: BatchUsageCondor (2 vs. 3)

Revision 32015-03-30 - FedericoMelaccio

Line: 1 to 1
 
META TOPICPARENT name="BatchSystem"
Condor works differently to many other batch systems so it is advised that you have a look at the User Manual. We are currently only supporting the "Vanilla" universe.

Submitting a Job

To submit a jobs to the condor batch system you first need to write a "submit description file" to describe the job to the system: A very simple file would look like this:

Changed:
<
<
####################                                                    

>
>
####################                                                    

 # # Example 1 # Simple HTCondor submit description file
Line: 20 to 19
 Queue
Changed:
<
<
That runs myexe on the batch machine (after copying it and inputfile to a temporary directory on the machine) and copies back the standard output of the job to a file called outputfile
>
>
That runs myexe on the batch machine (after copying it and inputfile to a temporary directory on the machine) and copies back the standard output of the job to a file called outputfile
  A more complex example submit description would look like:
Changed:
<
<
####################                                                    

>
>
####################                                                    

 # # Example 2 # More Complex HTCondor submit description file
Line: 47 to 45
 Queue 20
Changed:
<
<
This submit runs 20 copies (Queue 20) of my_analysis.sh input-$(process).txt result/output-$(process).txt where $(process) is replaced by a number 0 to 19. It will copy my_analysis.sh and input-$(process).txt to each of the worker nodes (taking the input file from the local input directory). The standard output and error from the job are copied back to the local output directory at the end of the job and the file result/output-$(process).txt is copied back to the local results directory. It copies over the local environment to the worker node (Getenv = True) and requests 2GB of memory to run in on the worker node. Finally it e-mails the user when each job completes.
>
>
This submit runs 20 copies (Queue 20) of my_analysis.sh input-$(process).txt result/output-$(process).txt where $(process) is replaced by a number 0 to 19. It will copy my_analysis.sh and input-$(process).txt to each of the worker nodes (taking the input file from the local input directory). The standard output and error from the job are copied back to the local output directory at the end of the job and the file result/output-$(process).txt is copied back to the local results directory. It copies over the local environment to the worker node (Getenv = True) and requests 2GB of memory to run in on the worker node. Finally it e-mails the user when each job completes.
 

Monitoring Your Jobs

Changed:
<
<
The basic command for monitoring jobs is condor_q by default this only shows jobs submitted to the "schedd" (essentially submit node) you are using, to see all the jobs in the system run condor_q -global
>
>
The basic command for monitoring jobs is condor_q by default this only shows jobs submitted to the "schedd" (essentially submit node) you are using, to see all the jobs in the system run condor_q -global
 
Changed:
<
<
If jobs have been idle for a while you can use condor_q -analyze <job_id> to look at the resources requested by the job and how they match to the available resources on the cluster.
>
>
If jobs have been idle for a while you can use condor_q -analyze <job_id> to look at the resources requested by the job and how they match to the available resources on the cluster.
 
Changed:
<
<
Failed jobs often go into a "Held" state rather than disappearing, condor_q -held <jobid> will often give some information on why the job failed.
>
>
Failed jobs often go into a "Held" state rather than disappearing, condor_q -held <jobid> will often give some information on why the job failed.
 
Changed:
<
<
condor_userprio will give you an idea of the current usage and failshares on the cluster.
>
>
condor_userprio will give you an idea of the current usage and failshares on the cluster.
 

Local Commands

Line: 66 to 64
 You can use bqsub to submit jobs (similar to LSF's bsub command). The full command can be specified on the command-line, so you don't need to create a "submit description file". Specify a time limit with bqsub -c hh:mm. eg.
Changed:
<
<
bqsub -c 24:00 Sherpa PTCUT:=20 EVENTS=1000
>
>
bqsub -c 24:00 Sherpa PTCUT:=20 EVENTS=1000
  qjobs (like LSF's bjobs) lists your running jobs with more helpful information.
Line: 75 to 72
  Use bqsub -h, qjobs -h, or qpeek -h for help.
Added:
>
>

How to retrieve output files from a running job

Sometimes it is useful to retrieve files from running jobs to check them or before killing a job which is not needed anymore. Here is a short guide:

  • from the user interface type condor_ssh_to_job [jobid] to connect to the scratch directory on the batch worker node (this may prompt for your password);

  • by typing ls you can list all the files used by your jobs;

  • by typing cp [filename] /home/ppd/yourname/yourpath you can copy [filename] to a folder of choice in your home area;

  • exit disconnects your session from the scratch dir, bringing you back to the UI. Now you can check if your files were successfully copied and kill your job if needed.
 -- ChrisBrew - 2014-03-26
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback