SGE_REQUEST(5)

πŸ’– sge_request(5) β€” Grid Engine File Formats πŸ’–

okay bestie, sit down, hydrate, because we're talking about sge_request, the Grid Engine default request definition file format. yes it's a mouthful, no you don't have to say it out loud. it's the file format for your default request profiles, and it's lowkey the main character of your job submission setup. let's get into it 🫢


✨ NAME ✨

<rainbow>sge_request</rainbow> β€” the Grid Engine default request definition file format, bestie. that's it, that's the name, and it's iconic.


🌸 DESCRIPTION 🌸

so <pink>sge_request</pink> is all about the format of the files that define your default request profiles. these apply to qsub(1), qsh(1), qrsh(1), and qlogin(1) β€” but for convenience (and because typing four names is a lot), only qsub gets mentioned below. iykyk πŸ’…

if they exist, default request files get read and processed during job submission, and here's the timeline that matters:

  1. default request files are processed first
  2. then any submit options embedded in the job script
  3. then any options in the qsub(1) command-line

which means the command-line and embedded script options can overwrite the settings in the default request files (peep qsub(1) for the deets). ✨

⚠️ but wait β€” where options may be repeated and accumulated, typically they get collected into a list from the various sources. and that list situation may not be what you want. no cap. πŸ’€

there are three default request definition files, and they have a whole hierarchy:

  • a cluster global file
  • a user private file
  • a working directory local file

and the precedence goes like this: the working directory local default request file has the highest precedence, then the user private one, and then the cluster global default request file. so local girl wins, then you, then everybody. πŸ‘‘

ngl, one thing you should know: the -clear option to qsub(1) can be used to discard any previous settings at any time β€” in a default request file, in the embedded script flags, or in a qsub(1) command-line option. it's giving reset button πŸŽ€

so, the format of the default request definition files is:

  • the default request files may contain an arbitrary number of lines. blank lines, and lines with a '#' sign in the first column, are skipped. πŸ™ˆ
  • each line not to be skipped may contain any qsub(1) option. more than one option per line is allowed, slay. the batch script file and argument options to the batch script are not considered as qsub(1) options and thus are not allowed in a default request file. periodt. 🚫

πŸ¦‹ EXAMPLES πŸ¦‹

here's a simple little example of a default request definition file, and honestly? it ate:

=====================================================
# Default Requests File

# request group to be sun4 and a CPU-time of 5hr
-l arch=sun4,s_cpu=5:0:0

# don't restart the job in case of system crashes
-r n
=====================================================

and having defined a default request definition file like this, submitting a job like:

qsub test.sh

would have precisely the same effect as if the job was submitted with:

qsub -l arch=sun4,s_cpu=5:0:0 -r n test.sh

see how that works? the file did the talking so you didn't have to. obsessed. πŸ˜­πŸ’–


πŸŽ€ FILES πŸŽ€

here's where these bad boys live:

  • <sge_root>/<cell>/common/sge_request β€” global defaults file
  • $HOME/.sge_request β€” user private defaults file
  • $cwd/.sge_request β€” cwd directory defaults file

πŸ’œ SEE ALSO πŸ’œ

go read them, bestie, they're right there. πŸ‘‘


See sge_intro(1) for a full statement of rights and permissions.


okay that's the whole page!! this was SGE 8.1.3pre, dated 2004-04-19, and yes she's vintage and yes she still serves. go forth and write your .sge_request files with main character energy πŸ’…βœ¨πŸ¦‹πŸŒΈπŸ’–