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

[Dan Lipsa]

Indeed, this workaround requires the relevant dataset to be available. It
just happened that this was the case in both projects. For a general
pipeline, where Update() is not called by the user on the relevant filter
this workaround would be trickier to use.
The API Berk suggested would work in both cases and it would be explicit
which is another big advantage.
Dan

On Wed, Mar 16, 2016 at 10:05 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> The only correct & general solution for this is to provide an API on the
> filter. Sometimes it is correct to copy global ids, sometimes it is not.
> The append filter could go either way depending on the data.
>
> PS: vtkShrinkFilter should never copy global ids since it duplicates
> points.
>
> On Mon, Mar 14, 2016 at 5:23 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/20160316/c463ba08/attachment-0001.html>