Nested subjobs for jobs with many components

[agraham]

This is probably a stupid question, but I'm trying to figure out if Qube is able to generate a 'master' job that controls/contains other jobs.

I'm trying to figure out the logistics of submitting a job with multiple render passes (using just straight --cmdrange -- we have our own mi generation wrapper). For a long time, users have been requesting to have control over individual passes ("I see a problem with the occlusion pass, I want to kill just that pass and keep the beauty rendering").

My first thought was to submit each pass as a separate job. Some of our jobs, however, have upwards of 15 render passes. I really, really don't want to have 15 jobs listed in the GUI, just for one render, for one user. What if 5 users submit 3 renders each, with, let's say, 4 passes per render. That's 60 jobs in the queue! Sure, jobs can be filtered, but that's asking a lot of each user, not to mention the poor schmo who has to monitor all this activity.

So, I was thinking about how Pixar's Alfred organizes jobs, with a sort of 'nested' hierarchy. There's a master 'controller' job that contains all the necessary preflight, frames, layers and postflight jobs. You can dive into each controller to see the progress of or kill individual components, but the overall view is simply of individual containers.

Is this what --pid or --pgrp is for? The docs don't really explain what those flags can be used for (other than dependencies), but that's not what I'm getting at.

Any ideas? How do the big Qube users handle this? Any help would be much appreciated.

AG

[jesse]

I have limited experience with qbsub, but if it works like the api then I can suggest a couple options.

You need to use --dependecy [trigger] (called callbacks in the API) and probably --preexec [command].  You have a couple options that I can see from the qbsub --help.  You can submit your jobs and keep them in the same pgrp and apply labels to them or simply specify the pid (parent id).

In the api I would use my main job id as the pid of all the child jobs.  Then the children get a trigger of kill-job-parent and a command of kill-job-parent. (Actually in the api it is simple to submit a whole group of jobs that will automatically get the same pgrp and in that case using labels is much simpler.)

If I was doing this I would also set the status of all the child jobs to be blocked so they don't start until a trigger is reached such that complete-job-parent could unblock-job-self.

The api allows for as many triggers as you want, but the command line utility may work differently.

Check out Use.pdf page 45 for Job Dependancy.  The file should be in the qube install directory.

cheers,
jesse

[eric]

Just to add to what Jesse said, the pgrp is the "process group" that you can use to tie a bunch of jobs together. It won't give you a hierarchy, per se, but that would be a way to keep them together structurally.

I've heard that some studios have managed to post-process jobs by callback into a rudimentary structure as well. I don't have the details, but it's something to think about.