Job Submission Scripting
To help with automation, you can submit batch jobs can through script commands of the oDesktop object. The SubmitJob script command uses job submission settings that have been exported from the Submit Job window to an .areg file. The path to this .areg file is thus the first argument to the SubmitJob command. Additional arguments include the path to the project file, the design name (if restricting the solve to a particular design), and the setup name (if further restricting the solve to a single setup within a design).
For further automation, you can use the SelectScheduler scripting command to determine what scheduler to use for submission, to include options for head node, username, and whether to require password entry from the user. (If the username differs from the cached username, or the force password flag is set, then the Select Scheduler dialog box appears.) If there are any issues with the scheduler selection (for example, a password is required or the requested host wasn’t found), then the Select Scheduler dialog box appears. This is the only part of job submission scripting that may required user intervention. This same mechanism is used if, from within the SubmitJob command, there is failure to connect to the scheduler. Even though there are allowances for graphical user intervention if something goes wrong, if the password (if required) is cached and all settings are correct, the entire submission process can run non-graphically and fully automated.
Limitations
All settings besides the arguments passed to the SubmitJob command must be stored in the .areg file containing settings exported from the job submission window. These include (but aren’t limited to) batch options, environment variables, batch extract settings, and compute resource selections. To run many job submission scripts with variation of these settings, there must be multiple .areg files available.
Note that the same project can be submitted multiple times with a single script. Care must be taken in this situation because each time a project is submitted, the state-keeping files used for monitoring are removed so that the job can create them from scratch to ensure consistency. While this ensures proper monitoring for a job that is just being submitted, it could interfere with monitoring (or even correct solving if a lock file is deleted) of a job that is already in progress. Because of this, if the same project is to be re-submitted from within a single script, the job should be monitored (waiting for completion) before trying to submit it again. This monitoring/waiting can be done with a combination of a single LaunchJobMonitor command followed by a loop that checks the result of a RefreshJobMonitor command.
How to Perform Job Submission Scripting
The typical scenario for job submission scripting would be to do the following:
- Manually select the scheduler. Use the Select Scheduler window to open the Submit Job To window.
- Choose a representative project (with the desired design type), and select appropriate analysis settings.
- Make the required compute resource selections and try to preview the job.
- If preview is successful, export the dialog settings and record the path to the new .areg file.
- Create a script containing at a minimum a SubmitJob command with the path to the .areg file, and the path to the project file. Note that there must be double backslashes for each backslash of a path, since the backslash is an escape character. When the script is run, and all is successful, there should be a message in the message windows stating that the job was submitted, including the job ID(s). There could be multiple job IDs if multi-step submission is used.
See the Scripting help (click Help >