Difference between revisions of "CFX/Batch"
(Created page with "You can either submit your CFX job from the command line, using the cfx_submit_job script, or you can directly submit your jobs to the batch system from the CFX graphical user...") |
|||
| Line 1: | Line 1: | ||
You can either submit your CFX job from the command line, using the cfx_submit_job script, or you can directly submit your jobs to the batch system from the CFX graphical user interface (GUI). | You can either submit your CFX job from the command line, using the cfx_submit_job script, or you can directly submit your jobs to the batch system from the CFX graphical user interface (GUI). | ||
| + | |||
| + | ===Submitting jobs from the command line=== | ||
| + | CFX jobs can be submitted from the command line, using the script ''cfx_submit_job''. | ||
| + | |||
| + | [leonhard@euler01 ~]$ '''./cfx_submit_job''' | ||
| + | |||
| + | USAGE: cfx_submit_job [-h|--help] [-n NCPUS] [-W HH:MM] [-M MBytes] [-J job_name] ... | ||
| + | |||
| + | -h | --help : show usage information and exit | ||
| + | -n NCPUS : number of processors for the job (default 1, maximum 96) | ||
| + | -W HH:MM : job run-time limit in hours and minutes (default 1 hour) | ||
| + | -M MBytes : memory required per processor (default 2 GB) | ||
| + | -J job_name : name of the job (jobs with the same name will be chained) | ||
| + | -ptile N : use N processors per node | ||
| + | -wrap X : wrap up at given time point or percent (X = HH:MM or %) | ||
| + | -lsf "opts" : pass additional bsub options to the batch system (LSF) | ||
| + | ... : all subsequent arguments are passed varbatim to cfx5solve | ||
| + | |||
| + | The number of processors (NCPUS) and run-time limit (HH:MM) are optional. The default values are 1 processor for one hour. The options <tt>-h</tt> or <tt>--help</tt> can also be used to print a brief description of the command's arguments. All other arguments are passed verbatim to <tt>cfx5solve</tt>. You can get a complete list of all supported options using the command | ||
| + | |||
| + | cfx5solve -h | ||
| + | |||
| + | The most important options are | ||
| + | |||
| + | -def {definition or results file} | ||
| + | |||
| + | -ini {initial values file} | ||
| + | |||
| + | Most other cfx5solve options — especially those relative to partitioning, parallel execution, hosts, etc. — should be avoided due to potential conflicts with the batch system on our clusters. | ||
| + | |||
| + | ===Submitting jobs from the GUI== | ||
Revision as of 07:52, 30 August 2016
You can either submit your CFX job from the command line, using the cfx_submit_job script, or you can directly submit your jobs to the batch system from the CFX graphical user interface (GUI).
Submitting jobs from the command line
CFX jobs can be submitted from the command line, using the script cfx_submit_job.
[leonhard@euler01 ~]$ ./cfx_submit_job USAGE: cfx_submit_job [-h|--help] [-n NCPUS] [-W HH:MM] [-M MBytes] [-J job_name] ... -h | --help : show usage information and exit -n NCPUS : number of processors for the job (default 1, maximum 96) -W HH:MM : job run-time limit in hours and minutes (default 1 hour) -M MBytes : memory required per processor (default 2 GB) -J job_name : name of the job (jobs with the same name will be chained) -ptile N : use N processors per node -wrap X : wrap up at given time point or percent (X = HH:MM or %) -lsf "opts" : pass additional bsub options to the batch system (LSF) ... : all subsequent arguments are passed varbatim to cfx5solve
The number of processors (NCPUS) and run-time limit (HH:MM) are optional. The default values are 1 processor for one hour. The options -h or --help can also be used to print a brief description of the command's arguments. All other arguments are passed verbatim to cfx5solve. You can get a complete list of all supported options using the command
cfx5solve -h
The most important options are
-def {definition or results file}
-ini {initial values file}
Most other cfx5solve options — especially those relative to partitioning, parallel execution, hosts, etc. — should be avoided due to potential conflicts with the batch system on our clusters.
