houdini simulations in deadline

Deadline
1

so over the last few weeks i’ve been working on some houdni flip sims with limited success. the basic jist of the problem is that my sim times have been very high for how many particles i’m using.

turns out the “initialize simulations” toggle in the rop should NEVER be toggled on with deadline. because deadline does not call the rop with a frame range and instead manually loops over the rop to process a frame at a time, the “initialize simulations” option will cause houdini to re-sim all the runup frames each time you call the rop. obviously, this will make your sims bog down very quickly without giving much feedback as to why.

i’m not sure why the deadline script calls the rop repeatedly rather than just letting it loop by itself, but if this is how it must work, then i would suggest that it also toggle off the “initialize simulations” option after the first iteration so that subsequent calls to the rop won’t re-sim.

2

Hi,
This sounds like something that should be improved in the Houdini plugin in Deadline.
Any example code on where this would be set in Houdini would be appreciated :slight_smile:
Thanks,
Mike

3

The Deadline script calls the ROP repeatedly so that it can report progress between frames. We could do one of two things here:

  1. Have a “simulation” option in the submitter, and if enabled, Deadline would just call the ROP once with the full frame range. It could also automatically set the Frames Per Task to ensure there is only one task for the job.

  2. At render time, turn off the “initialize simulations” option.

I kind of like option (1), since it reduces some of the manual work required to submit the job. What do you guys think?

4

option #2 is the easiest.

i’m guessing something like “rop.parm(“initsim”).set(0)” right after the rop.render() call.

probably should do a rop.parm(“initsim”).deleteAllKeyframes() first to ensure the parm is set properly. it may be that somebody has an expression in this parm and simply setting a value won’t always take in those cases.

however, the reality is that the manual iterating method is kind of unexpected and may break other things (for example, pre-/post-render scripts), so letting the rop iterate itself is probably a better bet when it comes to the farm process matching up with the local process. any time you have behind the scenes changes taking place, debugging gets that much harder.

i find the progress report to be somewhat unreliable. like at the moment, i have a sim that’s been running for hours and is at 0% in the monitor window. the slave report says it’s on the first frame. on disk, i can see that it’s completed 25+ frames. so my vote is for option #1 i guess. if people really require more feedback, they can set verbosity in the rop.

unless… by looping manually you can better handle frame completions for dependent tasks (ie, not forcing sims to complete in full before any dependencies can work on the output frames).

5

We use option 1 (already) here using our custom in app deadline submit tools, automating the expected behaviour saves soo many headaches as you can imagine.

We get reliable progress output from the sim (if it’s only one sim running within that submit) by enabling both “alf progress” and “report network” options.

We force it on in the Houdini plugin by adding in the below to hrender_dl.py (about line 60-ish):

ropType = rop.type().name() if ropType == 'rop_geometry': print ( "Setting Alfred Progress and report network params to ON" ) alfredProgress = rop.parm( "alfprogress" ) reportNetwork = rop.parm ( "reportnetwork" ) if alfredProgress != None: alfredProgress.set( 1 ) if reportNetwork != None: reportNetwork.set( 1 )

You could also add in your override/check for initsim here as well.

6

Thanks for the info guys! In Deadline 6.1, we’re going to be making a couple changes that should help this simulation problem:

  1. We’ll be enabling “vm_alfprogress” and setting “vm_verbose” to 3 for ifd rops, and we’ll be enabling “alfprogress” and “reportnetwork” for geometry. The Houdini plugin will also be updated to parse this progress from stdout properly.

  2. We’ll no longer be looping over individual frames for a task when rendering. Instead, we will just call the rop once with the full frame range. Progress reporting will still work because of (1).

Cheers,

  • Ryan