Writing Job Scripts¶
Avoid hardcoding in your job scripts¶
Use relative paths and environment variables instead of hardcoding directory names in your job scripts. Hardcoding in scripts and elsewhere can make debugging your code more difficult and also complicate situations in which others need to copy your directories to build and run your code as themselves.
Here’s one simple example of what not to do in your script:
Instead, replace your hardcoded username with $USER:
Better yet, assume that you will launch the job from your working directory so you don’t need to include the path in your script at all.
Use comments in job scripts¶
When setting a variable in your job scripts or startup files, include the date and a brief description of the variable's purpose. This practice may help prevent propagation of variables that are possibly inappropriate in carrying jobs and environments forward. One example is noting the use of a variable that is not set or appropriate in most other scripts.
# yyyy-mm-dd Context: MPT peak_memusage job.
# Variable MPI_SHEPHERD is set in this job in order to
# enable peak_memusage. Do not propagate it to other MPT
# jobs as it may cause significant slowdown or timeout.
export MPI_SHEPHERD="true"
Prepare for debugging and troubleshooting¶
Arrange the script, source code, and data used in your job in a few directories to make it easy for others to copy and debug if necessary. Also: Include a README file that details the environment needed to configure, build and run, and that identifies the required modules and environment variables. Ask a colleague or CISL Consulting Services Group consultant to copy and run the code themselves.