wedge ROP and dependencies

[meeotch]

Context: I've got a file with particles being advected by a fluid. AutoDopNetwork is set to "explicit cache" (so already cached). Five particle passes with different seeds are run via a geometryROP/wedgeROP pair. A mantraROP then pulls in all five passes per frame.

Q1: When the geoROP is set to "any frame" & I run the wedgeROP, the seeds run interleaved: seed1.1.bgeo, seed2.1.bgeo ... seed5.1.bgeo, then seed1.2.bgeo, seed2.2.bgeo, etc. What's going on here - are all of the sims being held in memory simultaneously? (I assume it's not "running up" for each file written, though it's hard to tell & it does seem slow-ish. It does *not* seem to be running in parallel - i.e. separate threads for each seed.)

When the geoROP is instead set to a frame range, say 1-100, and I run the wedgeROP with "use node range settings", the seeds run serially: seed1.1.bgeo, seed1.2.bgeo, seed1.3.bgeo, etc. This is sort of what I'd expect. However, if I now run the wedgeROP with a frame range x1-5, it runs the whole wedge five times (each run being 100 frames x nSeeds, serially), instead of just running five frames of wedge. Not sure why this would ever be useful, since each full wedge is identical.

Now I lay down a mantraROP, with the wedgeROP wired as a dependency. I run the mantraROP with Order == "Node by Node" (Frame by Frame produces undesirable behavior in all cases.) Again geoROP == "any frame" renders interleaved seeds, and geoROP == "1-100" renders serially. Only this time, the latter case loops the wedge multiple times before running the mantraROP! So interleaved seeds seems to be the only option, when the dependency is involved.

Q2: How would I wire it if I want the following behavior?

seed1.1-100.bgeo seed2.1-100.bgeo ... seed5.1-100.bgeo running in *parallel* (5 separate serial threads)

|

|

V

mantra.1-100.exr, one frame at a time, but multithreaded for each frame

I tried five single-seed wedgeROPS wired into a mergeROP, but they didn't run in parallel as suggested in the docs. Nor did turning off "Wait for Render to Complete" in the wedgeROP. Is it even possible to get one instance of houdini to fire off several simultaneous ROPs?

The issue is that POPs don't seem to be multithreaded very well, so my 12-core machine is largely idle while running the particle wedge. I could run five instances of houdini, but then I lose the dependency functionality of auto-magically firing off the mantra render once all five seeds are done.

[Adam Ferestad]

Context: I've got a file with particles being advected by a fluid. AutoDopNetwork is set to "explicit cache" (so already cached). Five particle passes with different seeds are run via a geometryROP/wedgeROP pair. A mantraROP then pulls in all five passes per frame.

Q1: When the geoROP is set to "any frame" & I run the wedgeROP, the seeds run interleaved: seed1.1.bgeo, seed2.1.bgeo ... seed5.1.bgeo, then seed1.2.bgeo, seed2.2.bgeo, etc. What's going on here - are all of the sims being held in memory simultaneously? (I assume it's not "running up" for each file written, though it's hard to tell & it does seem slow-ish. It does *not* seem to be running in parallel - i.e. separate threads for each seed.)

When the geoROP is instead set to a frame range, say 1-100, and I run the wedgeROP with "use node range settings", the seeds run serially: seed1.1.bgeo, seed1.2.bgeo, seed1.3.bgeo, etc. This is sort of what I'd expect. However, if I now run the wedgeROP with a frame range x1-5, it runs the whole wedge five times (each run being 100 frames x nSeeds, serially), instead of just running five frames of wedge. Not sure why this would ever be useful, since each full wedge is identical.

Now I lay down a mantraROP, with the wedgeROP wired as a dependency. I run the mantraROP with Order == "Node by Node" (Frame by Frame produces undesirable behavior in all cases.) Again geoROP == "any frame" renders interleaved seeds, and geoROP == "1-100" renders serially. Only this time, the latter case loops the wedge multiple times before running the mantraROP! So interleaved seeds seems to be the only option, when the dependency is involved.

Q2: How would I wire it if I want the following behavior?

seed1.1-100.bgeo seed2.1-100.bgeo ... seed5.1-100.bgeo running in *parallel* (5 separate serial threads)

|

|

V

mantra.1-100.exr, one frame at a time, but multithreaded for each frame

I tried five single-seed wedgeROPS wired into a mergeROP, but they didn't run in parallel as suggested in the docs. Nor did turning off "Wait for Render to Complete" in the wedgeROP. Is it even possible to get one instance of houdini to fire off several simultaneous ROPs?

The issue is that POPs don't seem to be multithreaded very well, so my 12-core machine is largely idle while running the particle wedge. I could run five instances of houdini, but then I lose the dependency functionality of auto-magically firing off the mantra render once all five seeds are done.

It sounds like you have the basic stuff down on the wedge (I am assuming that you do have it setup so that it is incrementing the seed value for you with each pass), you just need to name it right in your Geometry ROP. It should be something like:

$HIP/$HIPNAME.$WEDGE.$F3.bgeo

This will give you an output with the appropriate info in it. Then you setup the wedge and render out. Uncheck the "Wait for Render to Complete" box on the Wedge ROP to do all of the wedges in parallel, at least that is what they help says. I have a feeling that it will work once you get the settings right. Once you have the .bgeo series, you need to turn off the original geometry and use a Geometry SOP with a File node for each Wedge pass and then wire them all into a Merge node. I just did a wedge in this way of my tornado I am building and it worked flawlessly. Let me know if it works, or maybe upload a file, I will take a look and see what is going on.

[meeotch]

Adam - thanks for the response. You're correct - I've already got everything working, the current behavior is just not very efficient.

To be more clear: bgeo's render as intended (i.e. not in repeating loopson) if I run the wedge manually, but they won't run in parallel (only serially or what I'm calling "interleaved", but never using more than one thread), even with "Wait for Render" unchecked. At least via the interface - I've not tried running it from the command line.

Problem #2 is that when I wire the wedgeROP to the mantraROP as a dependency, and attempt render the whole thing as one job (again, from the interface), it will only work correctly in "interleaved" mode (all seeds frame1, all seeds frame2, etc.) This *seems* to be slower than serial mode (seed1 frame1, seed1 frame2, etc.), by a factor of at least 50%.

If I have time, I'll try to create a minimal test file to upload. But for now, this is what the graph looks like:

geoROP ["Any Frame", "Initialize Sims" ON, references a POP]

wedgeROP ["Wait for Render" OFF, 5 steps, references geoROP, and writes POP seed]

|

|

V

mantraROP

I've only got one machine, but it's 12 cores and 24Gb of memory. So what I'd like is all seeds in the wedge to run in parallel, one per thread - then the mantraROP, one frame at a time, multithreaded.

It sounds like you have the basic stuff down on the wedge (I am assuming that you do have it setup so that it is incrementing the seed value for you with each pass), you just need to name it right in your Geometry ROP. It should be something like:

$HIP/$HIPNAME.$WEDGE.$F3.bgeo

This will give you an output with the appropriate info in it. Then you setup the wedge and render out. Uncheck the "Wait for Render to Complete" box on the Wedge ROP to do all of the wedges in parallel, at least that is what they help says. I have a feeling that it will work once you get the settings right. Once you have the .bgeo series, you need to turn off the original geometry and use a Geometry SOP with a File node for each Wedge pass and then wire them all into a Merge node. I just did a wedge in this way of my tornado I am building and it worked flawlessly. Let me know if it works, or maybe upload a file, I will take a look and see what is going on.