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!
Processing multiple wedged simulations
9178 29 2- ChristopherC
- Member
- 19 posts
- Joined: 12月 2013
- Offline
- Ostap
- Member
- 209 posts
- Joined: 11月 2010
- Offline
- kenxu
- Member
- 544 posts
- Joined: 9月 2012
- Offline
- ChristopherC
- Member
- 19 posts
- Joined: 12月 2013
- Offline
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’.
- kenxu
- Member
- 544 posts
- Joined: 9月 2012
- Offline
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.
- Ken Xu
- ChristopherC
- Member
- 19 posts
- Joined: 12月 2013
- Offline
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?
- Tyler Britton2
- Member
- 85 posts
- Joined: 4月 2014
- Offline
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?
- chrisgreb
- Member
- 603 posts
- Joined: 9月 2016
- Offline
- Tyler Britton2
- Member
- 85 posts
- Joined: 4月 2014
- Offline
- kenxu
- Member
- 544 posts
- Joined: 9月 2012
- Offline
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.
- Ken Xu
-
- Quick Links