Continuing the dive into TOPs. Is there a more direct way to divide a work item into more work items based on a array attribute, and have it hold the array attribute corresponding value in a new attribute? I was able to do this in two ways, but I'm wondering is there's a more simple straight up method: - With Python Processor - With a Generic Generator and the a Python Script to create the single string attribute.
Also, the new work items generated by Python Processor have the same Index. Is there a way to basically recreate the indices so they match the new work items serialization?
The Work Item Expand node can be configured to create a work item from each entry in an array attribute. It'll set the index of the work item to match the index of each value in the array as well. With the Python Processor, you need to set the index yourself by passing an index=<something> argument to the call to addWorkItem.
tpetrick The Work Item Expand node can be configured to create a work item from each entry in an array attribute. It'll set the index of the work item to match the index of each value in the array as well. With the Python Processor, you need to set the index yourself by passing an index=<something> argument to the call to addWorkItem.
That works great, thanks!
Work Item Expand: Only suggestion would be to include the option to rename of the expandvalue attribute.
Python Processor: index=array_iteration did the job.
tpetrick The Work Item Expand node can be configured to create a work item from each entry in an array attribute. It'll set the index of the work item to match the index of each value in the array as well.
One last thing about this topic, for some reason it is throwing this error on one of the arrays. What is the common cause? H18.5.351 here.
For some reason this prints the attribute in the Pyton Script TOP
EDIT: Got it, similar issue I had with the Generic Generator in 18.5 coming from Python Script. Had to be set to "All Upstream Items Are Cooked" in order to pick up the incoming attributes. This seemed to be corrected in 19.0
It's hard to tell without seeing an actual .hip file, but my guess is your network is creating that attribute in a Python Script that runs when the work item cooks, instead of when the work item generates. If an attribute is added when a work item cooks, downstream nodes cannot access it when they generate because it doesn't exist yet. Generation happens before anything cooks.
You can see that by doing an RMB -> Generate Node on the TOP node instead of cooking it.
tpetrick It's hard to tell without seeing an actual .hip file, but my guess is your network is creating that attribute in a Python Script that runs when the work item cooks, instead of when the work item generates. If an attribute is added when a work item cooks, downstream nodes cannot access it when they generate because it doesn't exist yet. Generation happens before anything cooks.
You can see that by doing an RMB -> Generate Node on the TOP node instead of cooking it.
Thanks again for these conceptual pointers. Indeed I can see the attribute does not exist on generation only, probably because the Out-of-Process Python Script is the one that is generating the attribute. Simply turned on "All Upstream Items Are Cooked" and that made it work.
