I've got a very basic question on how to setup a TOP graph where I have 2 Dopnet caches (where the 2nd Dopnet relies on the successful cook of the first one). The second cache also runs on a different frame range (e.g : first one is 1001-1200, second one is 1001-1050).
At the moment I have my ROPgeometryOutput for the first sim set to “All frames in One Batch” as it's a sim, and the frame range set accordingly. This gives me @200 workers. If I connect a second RopGeometryOutput which does the 2nd sim and I give it the same settings but with different frame range I get 200 workers from upstream multiplied by my frames and I end up recooking the 2nd dopnet by as many workers as the upstream node.
The dirty workaround I found so far is to use a Generic Generator and set it so that downstream I send only one worker. Then my 2nd dopnet only cooks once accordingly.
I assume there's better ways to do this?

There's a “Wait for all” top, which does exactly what you want.

The second ROP should be set to “Single Frame” instead of “Frame Range”. In general, the parms on the TOP node describe what to do for each incoming work item. If you have a ROP node with 100 frames, and you want the next node to create 1 frame per incoming frame, the “Single Frame” will do what you're looking for. For example, rendering a sim's output with a ROP Mantra.

If you want to use some subset of the upstream frame range in the second ROP Geometry, you could put a Filter by Expression node between the first and second ROP node - in your case, I think the expression would be @pdg_frame > 1050, to filter out work items with a frame value larger than that.

Rico571
There's a “Wait for all” top, which does exactly what you want.

Thanks for that, it's a nice quick option.

tpetrick
If you want to use some subset of the upstream frame range in the second ROP Geometry, you could put a Filter by Expression node between the first and second ROP node - in your case, I think the expression would be @pdg_frame > 1050, to filter out work items with a frame value larger than that.

Yeah that's exactly what I'm more after, the sim to start as soon as the correspondent dependency upstream has cooked, and not wait for the whole chain to cook before it starts.
I'm using Filter by expression followed by map by index, however in the production build 173 that we have the cooking doesn't start straight away, I'll give it a go in the latest 222 build

You don't need a mapper. I've attached a simple example with two “sims” that are just writing out/coloring geometry, but the TOP graph structure should be the same.