I’m just testing out the new Deadline 9 submitter to do a simulation from Houdini 16. Because it’s a basic sim I’m not distributing it and it’s rendering the whole job as one task (there doesn’t seem to be a simple option to enforce this other than putting the ‘Frame per task’ right up) but it’s saving the bgeo files locally which is going to cause a serious issue with local drive space. I can’t see an option for disabling local saving to put it straight onto the server? Am I missing an option somewhere in the submitter or doing it wrong? On the plus side it is doing the simulation and hasn’t complained about the $HIP variable so that’s a big improvement on the version 8!
I’m not sure of any explicit re-direction for the bgeo output. Maybe it’s another variable issue? What’s the path for those files now?
As far as the single task, it’s possible to ‘force sequential rendering’ which should make the Slave especially sticky between tasks. Along with setting the machine count to “1”, that could likely do good things here. Also because the geo is being written out usually Houdini’s quick to pick up where it left off. I’ll see if that’s something we’re supposed to be currently doing, and if not add it as a feature.
Update: I did some research and some discussing internally. We definitely are not doing enforce sequential rendering yet in Houdini and we also don’t have a batch mode as of yet. That means that we would have to close and re-open Houdini every task which slows things down at the benefit of recovering from errors or being able to suspend the job without losing work. Does Houdini support skipping over existing bgeo and other sim data? Maybe it’s not worth adding sequential rendering (there’s a lot of edge cases for when to enable/disable it).
With regards to the local rendering I’m not sure what’s going on now. I tried to set up a demo file to send over to you and it’s saving directly to the server as I want! Typical. I’ll keep an eye on it and see if it crops up again, it’s possibly something I’m doing.
I don’t think force sequential rendering is what we’d use. I was thinking more of a convenience method in the submitter (like in After Effects for movie rendering) to force a single task for the entire job. That way it sims the entire job in one go without getting interrupted. At the moment I’m just setting the frames per task to a higher value than the frame range so something like a tick box to say it’s a sim job or something like that might be useful?
The new submitter is certainly more flexible than the old one though so that’s great. Although there are a few things we’ve discovered. We’re using takes to control the objects for different outputs and during the submission process it’s selecting the take and then not deselecting it at the end of the submission. it would be good if that could be fixed as it breaks if you try to submit it again with the take selected.
You have to make sure you’re saving your .bgeo’s with a path that doesn’t change on the render hosts. $HIP will change, so set your own $JOB (using set -g) and then have all files written below that.
That might be a useful to to put in the documentation somewhere or as a sanity check? We try to make sure we’re never using $HIP but it creeps in there sometimes as it’s Houdini default behaviour and we haven’t got round to writing a script to replace it with $JOB.
yeah something like that would be useful in all the submitters, although the max one is quite slow and I know most people turn it off in our studio because of false positives. For this though it would be useful and you would need to both set the $JOB variable to the same path as $HIP and replace all the instances of $HIP in the scene file. That would work for us but I’m not sure if others remap use the $JOB variable differently.
