| 12 | | The submitter monitors progress and resubmits a new submitter job as needed until the workflow completes. See [wiki://Workshops/JobCheckpointing/Examples#Checkpointworkflowimplementation Checkpoint workflow implementation] below. |
| | 14 | === Submitter self-resubmits before timing out === |
| | 15 | |
| | 16 | The submitter itself also runs for a bounded time while monitoring progress. Just before timing out, the submitter resubmits a new submitter job as needed until the workflow completes using the '''sbatch''' command rather than the SLURM '''requeue''' feature. For details on this checkpointing implementation, see [wiki://Workshops/JobCheckpointing/Examples#Checkpointworkflowimplementation Checkpoint workflow implementation] below. |
| | 17 | |
| | 18 | === Why do we use sbatch vs SLURM requeue? === |
| | 19 | |
| | 20 | ==== Unacceptable use of requeue ==== |
| | 21 | |
| | 22 | The SLURM resource manager provides an option to requeue a running job via the command '''scontrol requeue'''. (See '''man scontrol'''.) |
| | 23 | |
| | 24 | However, when a job is requeued, any previous record of elapsed time used by that same job is '''overwritten'''. |
| | 25 | |
| | 26 | Hence, the requeue option has the following 2 consequences. |
| | 27 | |
| | 28 | 1. You would '''not''' be able to track the total elapsed time used by your requeued job. |
| | 29 | 2. As a result, your job would be in violation of Tulane Information Technology's [https://it.tulane.edu/acceptable-use-policy Acceptable Use Policy], including monitoring your use of Cypress. |