[vtk-developers] vtkDataSetAttributes::COPYTUPLE for GlobalIds and appending data

[Dan Lipsa]

As it happens, I hit this problem in a different project, more than a year
after I first encountered it. I wanted to share the workaround I have used
then which works in my new project as well.

To prevent append or other VTK filters from removing the GLOBALIDS a
solution is to unset the GLOBALIDS attribute on the dataset:

    attributes.SetActiveAttribute(-1, attributes.GLOBALIDS);

Later on, you can access the global ids array using the name you used for
it.

Regards,
Dan


On Mon, Feb 9, 2015 at 6:26 AM, John Platt <jcplatt at dsl.pipex.com> wrote:

> Hi,
>
> This problem also arises when an unstructured grid must be split into
> parts because the field data is not continuous, for example, stresses
> between two different materials. Appending the parts again for node
> labelling loses the global Ids (node numbers) .
>
> vtkClipPolyData does not copy point global Ids which is reasonable because
> the data would typically need to be interpolated. But if the poly data
> consists solely of vertices, it is safe to copy them. vtkShrinkFilter does
> not copy cell global Ids; vtkUnstructuredGridGeometryFilter does not copy
> point global Ids (VTK 5.10.1).
>
> I would definitely go for an API on the algorithm which allows
> specification of attribute data to be copied.
>
> Thanks.
>
> John.
>
>
>
> On 06/02/2015 20:33, David Cole via vtk-developers wrote:
>
>> When I read "if COPYTUPLE for an attribute is 0, data is still copied"
>> I think to myself, well that doesn't seem to make sense...
>>
>> I think (2) sounds like a better idea.
>>
>>
>> 2 cents,
>> D
>>
>>
>>
>> On Fri, Feb 6, 2015 at 3:12 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>
>>> Hello all,
>>> We would like the feedback of the community for the following problem:
>>>
>>> In an append operation, the GLOBALIDS array is not copied to the output
>>> because, by default, vtkDataSetAttributes::COPYTUPLE is 0 for the
>>> vtkDataSetAttributes::GLOBALIDS attribute.
>>>
>>> This behavior makes sense if appending datasets coming from different
>>> sources, but it does work in a ParaView use case.
>>>
>>> In ParaView running with a remote pvserver configuration, data is
>>> processed
>>> on MPI nodes, sent to node 0 and appended together there (using
>>> vktAppendCompositeDataLeaves) and then sent to the client. In this case,
>>> the
>>> GLOBALIDS arrays is valid, and should be preserved.
>>>
>>> We are thinking of two possible/alternate solutions to this problem:
>>>
>>> 1. Change vtkDataSetAttributes such that if COPYTUPLE for an attribute
>>> is 0,
>>> data is still copied but it does not set that attribute as an active
>>> attribute (using vtkDataSetAttributes::SetActiveAttribute).
>>>
>>>
>>> 2.  Provide API for vktAppendCompositeDataLeaves (and vtkAppendFilter,
>>> vtkAppendPolyData) that
>>> specifies that the GLOBALIDS should be copied.
>>>
>>> Do you have any feedback on this?
>>>
>>> Thank you,
>>> Dan
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at:
>>> http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160314/1190cb3a/attachment.html>