[vtkusers] copying GlobalIds through vtkExtractGeometry

Wed Jul 21 14:32:37 EDT 2010

David,

I've attached a (very simple) patch for vtkExtractGeometry.cxx that sets the Copy Tuple flag for GlobalIds.  As far as my tests go, it seems to work.

We've also decided to use PedigreeIds in our code instead of GlobalIds, after reading the mailing list as you suggested.  (PedigreeIds are copied through vtkExtractGeometry, so no issue there.)

An important detail, which I now count as hard-won knowledge, is that if you name your PedigreeIds array "vtkOriginalPointIds", then vtkExtractSelectedIds will clobber it, and instead of getting the actual original point Ids, you will get the point Ids as they were at the input to vtkExtractSelectedIds.  This is easy to avoid.  As long as the name is anything else (or not set), you are fine.

cheers,
Eric Nodwell

On 2010-07-20, at 1:17 PM, David E DeMarle wrote:

> I agree. That filter is doing a simple subsetting operation, it seems
> logical that it should pass through the ids (both pedigree and global
> ids*). Try directly changing the filter. If that works for you send me
> a patch and I will test it and commit to vtk.
> 
> *globalids are used for this in many places for historical reasons.
> pedigree ids are better suited for this though since they support be
> n:m. Search the mailing list for explanations of the distinction
> between the two.
> 
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 28 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-371-3971 x109
> 
> 
> 
> On Tue, Jul 20, 2010 at 2:34 PM, Eric Nodwell <enodwell at ucalgary.ca> wrote:
>> David,
>> 
>> Thank you for the reply.  It is possible that we are mis-using GlobalIds.  We are using VTK to assemble (and visualize) finite element models.  We've found it very handy to be able to chain together a number of VTK (and custom) filters to obtain a desired set of points for a constraint (boundary condition).  A typical user request might be something like this: find all the points of a vtkUnstructuredGrid that lie on the top surface of a rough porous bone and within a certain annulus.  At the end however, it is necessary to identify the original point IDs in order to be able to generate correct constraint values for the finite element model.  Up till now we have used a variety of techniques, including custom-named attribute arrays and PedigreeIds.  However, it seems GlobalIds is intended for this purpose.  I could be mistaken.  With most filters it works as expected; vtkExtractGeometry is an exception.
>> 
>> As for getting vtkExtractGeometry to copy through GlobalIds, I have found it works adequately for our purpose to subclass vtkExtractGeometry and set the Copy GlobalIds flag in RequestData before calling the vtkExtractGeometry::RequestData .  It works, but it seems somewhat inelegant to have to create a new class.  This is the relevant bit of code:
>> 
>> int vtkExtractGeometryPreserveGlobalIds::RequestData(
>>  vtkInformation* request,
>>  vtkInformationVector **inputVector,
>>  vtkInformationVector *outputVector)
>> {
>>  // get the info object
>>  vtkInformation *outInfo = outputVector->GetInformationObject(0);
>> 
>>  // get the output
>>  vtkDataSet *output = vtkDataSet::SafeDownCast(
>>      outInfo->Get(vtkDataObject::DATA_OBJECT()));
>> 
>>  // modify the Copy Tuple flag for GlobalIds
>>  output->GetPointData()->CopyGlobalIdsOn();
>>  output->GetCellData()->CopyGlobalIdsOn();
>> 
>>  // Now do the usual work of the superclass
>>  return vtkExtractGeometry::RequestData (request, inputVector, outputVector);
>> }
>> 
>> 
>> cheers,
>> Eric Nodwell
>> 
>> 
>> 
>> 
>> 
>> On 2010-07-20, at 10:35 AM, David E DeMarle wrote:
>> 
>>> That flag is meant to be used internally by the filter and is not a
>>> control that you can change the behavior of arbitrary filters with.
>>> 
>>> Filters that know how to work with gobalid data without destroying
>>> their meaning turn it on when they are preparing to do their work.
>>> This makes the DataSetAttributes copy helpers copy that array. Most
>>> filters  do not know how to preserve the meaning of globalids  (having
>>> been written well before globalids existed or being incompatible with
>>> it). They leave the flag in the default off state. This ensures that
>>> their outputs do not have the array, which is better than having the
>>> array with invalid results in it.
>>> 
>>> For reference, see how vtkDataSetSurfaceFilter uses the flag when its
>>> PassThroughCell/PointIds flags are on.
>>> 
>>> David E DeMarle
>>> Kitware, Inc.
>>> R&D Engineer
>>> 28 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-371-3971 x109
>>> 
>>> 
>>> 
>>> On Mon, Jul 19, 2010 at 6:11 PM, Eric Nodwell <enodwell at ucalgary.ca> wrote:
>>>> Hi,
>>>> 
>>>> I would like to preserve the attribute array GlobalIds of the PointData on an object being operated on by vtkExtractGeometry .  I am having some difficulty however in determining where to set the Copy Flag for GlobalIds.
>>>> 
>>>> According to the comments in the header of vtkDataSetAttributes, and examining the source code, this flag should be set on the destination, not on the source.  So that would suggest code like this:
>>>> 
>>>>  // Make an extractor
>>>>  vtkExtractGeometry* extractor = vtkExtractGeometry::New();
>>>>  extractor->SetImplicitFunction (function);
>>>>  extractor->SetInput (data);
>>>> 
>>>>  // OK, now get the output of the filter because we need to set the Copy Tuples flag on GlobalIds
>>>>  vtkDataSet* output = extractor->GetOutput();
>>>>  output->GetPointData()->CopyGlobalIdsOn();
>>>>  // CopyGlobalIds on output is verifiably ON at this point
>>>> 
>>>>  // Run the filter.
>>>>  extractor->Update();
>>>>  // Oops, CopyGlobalIds on output is verifiably OFF at this point.  No GlobalIds are present on output.
>>>> 
>>>> The problem is that the pipeline, during the Update of the vtkExtractGeometry object, calls vtkDataObject::PrepareForNewData, which wipes out any flags that we have set.
>>>> 
>>>> So the question is, what is the solution to this catch 22?  How does one set the Copy Tuple flag on the filter output *before* the filter updates, but *after* the PrepareForNewData call?
>>>> 
>>>> Thank you for any insight,
>>>> Eric Nodwell
>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Please keep messages on-topic and check the VTK FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkExtractGeometry.cxx.patch
Type: application/octet-stream
Size: 555 bytes
Desc: not available
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20100721/c6bf55b6/attachment.obj>