|
|||||
Render Scripts should at very least make use of $RUSH_FRAME or $RUSH_PADFRAME to determine the current frame being rendered.
| ||||||||
| RUSH_DIR |
This variable is the directory name of the rush directory. Normally, this is /usr/local/rush. Appending '/bin' gives a path to the rush(1) and rushd(8) binaries.
This variable should be in the user's environment so all rush(1) commands can access it, and as well, should also be set in the boot scripts before rushd(8) is started. Both rush(1) and rushd(8) depend on this variable being set.
| RUSH_FRAME |
This variable contains the frame number to be rendered, i.e., "1", "12", "104". No padded zeroes are used.
| RUSH_FU |
If set to '1', implies the '-fu' flag for all commands. Not recommended for use in user's environment. This variable is meant only to be used by GUI interfaces that are layered on top of the rush command line tool.
| RUSH_HOSTNAME |
The local hostname the render script is running on. This is the name that appears in 'rush -lah' reports.
| RUSH_JOBID |
Contains the jobid of the current running job. i.e., "tahoe-37"
| RUSH_LOGFILE |
Contains the absolute path to the output log for the currently running render script. The contents of this file grows as the render script generates output.
The pathname in this variable always ends with the frame number being rendered [eg. 0001, 0002, 0003], so it will be a pathname specific to the current frame being rendered.
This variable is dependent on the job's current LogDir value, which can be changed dynamically with the rush -logdir command line option.
For example, the render script can use this variable to search the renderer's output for error messages, and act conditionally based on the error detected. See Detecting Render Problems with Grep for examples of this technique.
| RUSH_PADFRAME |
This variable contains the frame number to be rendered, and includes
4 padding zeroes,
I.e., "0001", "0012", "0104".
| RUSH_PRE102_20 |
If set, causes old rush command line options to be in effect:
NEW BEHAVIOR
'rush -laj' - lists all jobs using fast UDP messaging
'rush -lac' - lists all cpus use
'rush -lah' - lists all hosts (old -lac report)
OLD BEHAVIOR (PRE-102.20)
'rush -lac' - lists all hosts (new -lah report)
'rush -laj' - lists all jobs, TCP oriented polling
|
Setting this variable to any value disables the new behavior in rush(1) 102.20 for commands like 'rush -lac', so as to be backwards compatible with previous versions.
Use this *only* if you have old scripts or programs dependent on the old behavior of 'rush -lac'.
Please convert old programs and scripts to use '-lah' instead of '-lac' for hosts reports.
| RUSH_RAM |
This variable contains the job's current Ram value, which can be changed dynamically with the rush -ram command line option.
| RUSH_TMPDIR |
Contains the path to a temp directory that is automatically created before the frame starts rendering, and is completely removed after the frame completes execution, deleting all files left behind.
This variable is dependent on the current TmpDir setting in the rush.conf file.
Use this variable when creating temporary files in your render script, so that the files are automatically removed even if your renders are bumped or dumped while in progress, e.g.,
### YOUR RENDER COMMANDS HERE
render -output $RUSH_TMPDIR/foo.rgb
post_filter -in=$RUSH_TMPDIR/foo.rgb \
-out=/job/SHOW/img/$RUSH_PADFRAME.rgb
|
| RUSH_TRY |
The number of times this frame has attempted to render this frame; the number in the 'TRY' column of a 'rush -lf' report. Can be changed with rush -try.
Priority values are in the range 1-999. Values outside this range cause an error.
Priority values are generally specified in the 'cpus' command, such as:
Both of the above are equivalent, asking for one cpu on tahoe at 100 priority. (If the number of cpus is not specified, '1' is the default).
Jobs contend for cpus based primarily on priority. When priority values are equal, the system uses a round robin scheme as 'first come, first served'.
Priority values are 'relative'. If all other jobs on the network are 100 but your job is 101, it will always win battles for an idle cpu. (Making your job 200 priority will not make it execute any quicker.)
When priority values differ, cpus are arbitrated using these rules:
In addition to the above, 'priority flags' may be appended to the priority values. (eg. 100k, 100a, 100ka). These flags augment the above behavior in the following ways:
Priority flags are normally used separately, but can be combined (e.g., 100ka) to create the situation known as 'Kick Ass' mode.
Here are some example situations to demonstrate the above rules.
Example: Passive Higher Priority (Non-Killer)
Suddenly, someone submits a 200 priority job to the same cpu. The 100 priority job will be allowed to finish rendering the current frame and then the 200 priority takes over the cpu, rendering all its frames. Once the 200 priority job has completed, the 100 priority job continues to render the remaining frames.
|
Example: Aggressive Higher Priority (Killer)
But this time, someone submits a 200k priority job (kill flag is set). The 100 priority job's frame is immediately killed, and the 200k priority job takes over the cpu until all its frames are rendered, at which point the 100 priority job resumes on the cpu.
|
Example: Equal Priority (Round Robin)
Then someone submits a different job at 100 priority. Both jobs will alternate using the cpu, yielding to each other. Note: Even if either or both jobs had their 'k' flags set, the behavior would still be the same, since the priority of both jobs is equal (killer jobs will only kill lower priority jobs, not jobs of equal priority).
|
Hostgroups are free-form names defined by agreement between TDs and sysadmins. The '+any' hostgroup always represents 'all hosts'.
Hostgroups are used like hostnames, and always start with a '+' character, as in:
All hosts on the network should be a member of the special host group name '+any'. So if a TD specifies '+any=10@500', this indicates the job wants to use any 10 available cpus at a priority of 500, taking into account limitations set by the submit script's criteria and neverhosts commands.
For example, if the resource manager creates a hostgroup called +badlands, adding several hosts as members of that group, then TD's can put in their submit script:
...to inherit all hosts configured in the +badlands hostgroup at a priority of 100.
Hostgroups can be specified in the following submit script commands:
Hostgroups can be viewed with 'rush -lah', or by clicking the 'All Hosts' button in irush.