|On this page|
This scheduler node utilizes Thinkbox’s Deadline to schedule and execute PDG work items on a Deadline farm.
To use this scheduler, you must have the Deadline client installed and working on the local machine. As well, you must have Deadline setup on your farm machines to receive and execute jobs. Deadline 10.0.16.6 was the most recent version tested.
The scheduling behaviour of this node is such that for a PDG cook operation a single Deadline job is created, and each PDG work item is scheduled as a task under it. The first task (task ID 0) will start a server called
PDGMQ that runs in the background on that Slave machine throughout the entire cook process, and stopped after all other tasks are completed. This server runs on the farm in order to receive result data over the network from other running tasks on other Slave machines, and relay that information to the job submitter’s machine via a known port. This design works around certain network limitations such as DNS routing and firewalled networks.
By default, this scheduler requires and uses the custom
PDGDeadline plugin which is shipped with Houdini (in
$HFS/houdini/pdg/plugins/PDGDeadline). No setup is necessary to enable this plugin as it should work out of the box. Note that the rest of this documentation assumes the use of the PDGDeadline plugin.
On Windows, Deadline processes require executables to have the
.exe suffix. To appease this requirement,
\$PDG_EXE can be appended to executables. The PDGDeadline plugin will evaluate the
\$PDG_EXE specified in work item executables as follows
$PDG_EXEwill be replaced by
On other platforms,
$PDG_EXEwill be removed.
For example, hython will be framed between
\$PDG_EXE and evaluated on Windows as
C:/Program Files/Side Effects Software/Houdini 17.5.173/bin/hython.exe
Install Deadline client on the machine you will use to cook the TOP network. Refer to Thinkbox’s instructions for how to install Deadline on each platform.
Make sure of the following:
deadlinecommandexecutable is working. See
The Deadline repository is accessible on the machine where the TOPs network will cook (either the repository is local, or the network mount/share it’s on is available locally).
If you are using a mixed farm setup (i.e. any combination of Linux, macOS, Windows machines) then set the following path mapping for each OS. To do this, in Deadline’s
Configure Repository Options, under
Set up path mapping for
$HFSto the Houdini install directory on Deadline Slave machines.
Set up path mapping for
<expanded HFS path>/bin/python.exeor local Python installation.
On Linux or macOS:
Set up path mapping for
$HFSto the Houdini install directory. Or override the default parm values for Hython and Python in the Job Parms interface.
\in front of
$HFSto escape Houdini’s local evaluation. Using
\$HFSwill make sure to evaluate it on farm marchine running the job.
Repeat for any other variable that needs to be evaluated on the farm machine.
$DEADLINE_PATHvariable to point to the Deadline installation directory.
DEADLINE_PATHis not set:
You can add the Deadline installation directory to the system path.
On macOS, the node falls back to checking the standard Deadline install directory.
When the schedule submits a work item to Deadline, it will add this attribute to the work item in order to track the Deadline job and task IDs.
These are global parameters for all work items.
Submit Graph As Job
Called when the scheduler should cook the entire TOP Network as a standalone job.
Local Shared Path
The root path on the local machine pointing to the directory where the job will be generating intermediate files and output. The intermediate files will be placed in a subdirectory. Use this if the local and farm marchines have same path configuration.
Override Remote Shared Path
Enable this if the farm machines have different path configuration than the local submission machine. This is required for mixed farms where due to different OS, the mounted paths are different.
These are the job description properties that will be written to a Deadline job file.
The required name of the job.
An optional comment to put on all jobs.
The default department (for example,
Lighting) for all jobs. This is optional, to allow grouping jobs together and provide information to the farm operator.
Job Batch Name
An optional batch name to group the job under.
A named pool to use to execute the job (default is
A named group to use to execute the job (default is
The default priority for new jobs. The default is
50. The lowest priority is
0. The maximum priority is a setting in Deadline’s repository options, usually
The number of tasks to run simultaneously for each Deadline Slave. The default is
1 meaning one task at a time.
Limit Concurrent Tasks To CPUs
If enabled, limits the concurrent tasks to the number of CPUs on the Slave, or the CPU Affinity setting.
Pre Job Script
Path to a Python script to run when the job starts.
Post Job Script
Path to a Python script to run after the job finishes.
Limit the number of Deadline Slaves that can execute this job. The default is
0 which means no limit.
Restricted list of Deadline Slaves that can execute this job. The list is written out as
Whitelist in the job info file, unless
Machine List is A Blacklist below is enabled, in which case it is written out as a
Machine List Is A Blacklist
If enabled, the Machine List is written out as
Blacklist therefore not allowing the listed machines to execute this job. If disabled, the list of machines are only allowed to execute this job.
The required Deadline Limits (Resource or License type) for the scheduled jobs. The Limits are created and managed via Deadline Monitor.
What to do with a job’s information when it finishes. The default is Nothing. See Deadline’s documentation for more information.
Job File Key-Values
Lets you add custom key-value options for this job. These will be written out to the job file required by the Deadline plugin specified above.
Plugin File Key-Values
Lets you add custom key-value options for the plug-in. These will be written out to the plugin file required by the Deadline plugin specified above.
Enable this to print information that could be useful for debugging problems during cooking.
Use IP Address for PDGMQ
Enable this to use IP address, instead of hostname, for connecting to the PDGMQ server. This should work around networking issues such as DNS not working or the hostname not properly resolving to the correct farm machine running the PDGMQ server.
PDGMQ Server As Task
Whether to execute the PDGMQ server as a separate task instead of a background monitor program on the first slave. If enabled, PDG cooks will require at least
2 Deadline Slave instances available or the
ConcurrentTasks to be set greater than 1. This is required to be enabled if
Force Reload Plugin needs to be enabled.
Force Reload Plugin
Whether to reload the plugin between frames of a job (the default is
false). This can help deal with memory leaks or applications that do not unload all job aspects properly.
Note that this can only be enabled if
PDGMQ Server As Task is also enabled since reloading the plugin between tasks will force shutdown the PDGMQ server.
Launch Monitor Machine Name
Set this to the name of the machine if you want to launch Deadline Monitor on that machine when jobs are scheduled. Otherwise leave this field empty.
Enable this to use another Deadline repository than the system default.
If you have a single Deadline repository or want to use your system’s default Deadline Repository, you should leave this field empty.
Otherwise, you can specify another Deadline repository to use, along with SSL credentials if required. For a Direct connection type, this could be the path to the mounted directory
//testserver.com/DeadlineRepository). For a Proxy, this would be the URL to the repository along with the port, and login information.
The type of connection ("Direct" or "Proxy") to the repository.
Enable this to use another Deadline plugin than the shipped PDGDeadline plugin. Do not enable this unless you have written a custom Deadline plugin that supports the PDG cooking process. The other plugins shipped with Deadline will not work out of the box.
Specify custom Deadline plugin to execute each PDG work item. If you want to control the execution of the PDG work item’s process, then you can write a custom Deadline plugin and specify it here, along with the directory below. The custom plugin must utlize the task files written out for each work item, and set the evaluated environment variables in the process. Check the PDGDeadline.py for reference.
Specify the path to the custom Deadline plugin specified above.
Task Callback Port
Set the TCP Port used by the Message Queue Server for the XMLRPC callback API. The port must be accessible between farm blades.
Set the TCP Port used by the Message Queue Server connection between PDG and the blade that is running the Message Queue Command. The port must be reachable on farm blades by the PDG/user machine.
These parameters can be set for each TOP node via the override settings in each node.
The rooted path to Houdini installation on all Deadline Slave machines. If variables are used, they will be evaluated locally unless escaped with
\. For example,
$HFS will be evaluated on the local machine then the result value is sent to the farm. To force evaluation on the Slave instead (for a mixed farm setup), use
\$HFS. The following should then be set in Deadline’s Path Mapping:
C:/Program Files/Side Effects Software/Houdini 17.5.173).
The rooted path to python, which should point to the required Python version installed on all Slave machines, such as
$HFS/bin/python. If variables are used, then they should be mapped in Deadline’s Path Mapping (e.g. $HFS should be path mapped if using default value). On Windows, the path mapping should add
\$PDG_EXE for a mixed farm setup.
C:/Program Files/Side Effects Software/Houdini 17.5.173/bin/python.exe).
Inherit Local Environment
When enabled, environment variables in the current session of PDG will be copied into the task’s environment.
Houdini Max Threads
Set the HOUDINI_MAXTHREADS environment to the given value. By default HOUDINI_MAXTHREADS is set to the value of At Most Slots, if enabled.
The default of 0 means to use all available processors.
Positive values will limit the number of threads that can be used. A value of 1 will disable multithreading entirely (limiting to only one thread). Positive values will be clamped to the number of CPU cores available.
If the value is negative, the value is added to the maximum number of processors to determine the threading limit. For example, a value of -1 will use all CPU cores except 1.
Lets you add custom key-value environment variables for each task.