Hello Ken,
Adding a new option for the ‘Evaluate Using’ parameter is exactly what I was hoping for and it's great to hear that we won't need to workaround it!
Thanks for your help!
Full Version: Processing multiple wedged simulations
Agree. Should be a nice solution.
Are you planning to implement it for all ROP Feth nodes?
Are you planning to implement it for all ROP Feth nodes?
Yes 
Hello Ken,
Do you think that it would be possible to also make the ‘Evaluate Using’ functionality available as a standalone node?
For example, if we were to wrap a RopGeometry node within a subnetwork to add some extra functionalities, it would be nice to have a node upstream of the subnetwork that would generate the expected work items and frame attributes for the other nodes downstream to inherit. Then we'd only have to set the inner RopGeometry node to use ‘Single Frame’.
Do you think that it would be possible to also make the ‘Evaluate Using’ functionality available as a standalone node?
For example, if we were to wrap a RopGeometry node within a subnetwork to add some extra functionalities, it would be nice to have a node upstream of the subnetwork that would generate the expected work items and frame attributes for the other nodes downstream to inherit. Then we'd only have to set the inner RopGeometry node to use ‘Single Frame’.
Hi Christopher, I think I get what you're saying, sort of to break out the functionality to generate the right frames to be outside of the ROP so it can be used elsewhere. The trouble with that is that a lot of the time you'll want to use the batch functionality of the ROP (to minimize startup and shutdown costs), and breaking it out like this wouldn't allow you to take advantage of that.
I'm not too sure to understand why this would be the case? If the ‘Evaluate Using’ functionality is duplicated into a standalone node (without being removed from the RopFetch node), then we would still be able to set the RopGeometry node to use ‘Single Frame’, which means that it would evaluate all upstream work items the same way as it currently does it, and the batch functionality should still apply. Am I missing something?
chrisgrebTyler Britton2Yes, unfortunately it looks like that is the case, please let us know if you are having trouble with a more recent version.
I am working in 17.5.173, could that be why?
Hey Chris, I finally got to test the latest production build and it works like a charm, thanks. However I am having problems filtering out some attributes I am loading in with a csv input.
In the screenshots I have a “shotindex” integer attribute I am brining in, and am using a Partition by Attribute to ideally partition my above work items by the “shotindex” attribute, however it doesnt seem to be working the same way it did with the wedges I did in my other case. Am I doing something wrong?
You probably need to turn on Use Dynamic Partitioning if the csvinput is being generated from upstream work.
chrisgreb
You probably need to turn on Use Dynamic Partitioning if the csvinput is being generated from upstream work.
That helped, thanks.
Hi Christopher,
It has to do with the way PDG generates downstream work from upstream. If we already have all the frames represented separately as workitems, then PDG can only generate 1 or more workitems (in this case frames) per upstream workitem or frame. The only thing that really makes sense here is to generate just 1 frame per upstream frame, given that we already have fully expanded the frames. If we do that, though, we'd end up creating one separate task per frame, which is not batching and would suffer from a lot of setup/tear down overhead. If we go this route, at a minimum we'd need to partition the expanded frames, so that we can generate a batch workitem for the frames in the partition. That then is adding more complexity, but we'll think about it a bit more to see if it's worth it.
It has to do with the way PDG generates downstream work from upstream. If we already have all the frames represented separately as workitems, then PDG can only generate 1 or more workitems (in this case frames) per upstream workitem or frame. The only thing that really makes sense here is to generate just 1 frame per upstream frame, given that we already have fully expanded the frames. If we do that, though, we'd end up creating one separate task per frame, which is not batching and would suffer from a lot of setup/tear down overhead. If we go this route, at a minimum we'd need to partition the expanded frames, so that we can generate a batch workitem for the frames in the partition. That then is adding more complexity, but we'll think about it a bit more to see if it's worth it.