Not reading in as vtkIdType is an independent bug. It is one we meant to fix, but haven't gotten to just yet.
David E DeMarle Kitware, Inc. R&D Engineer 28 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-371-3971 x109 On Fri, Apr 23, 2010 at 4:30 PM, Eric E. Monson <emon...@cs.duke.edu> wrote: > Hey Dave, > > I'll definitely try this sometime early next week, but I just wanted to point > out something else, first, that may be interfering somewhere: > > If you look at the output of the Xdmf reader, like you said, it has allowed > Global IDs to be set on the PointData, but they are not read in as idtype > (mine says Data type: long), so they aren't recognized by things like the > Selection Inspector as real Global Node IDs (the list ends up blank if you > try to switch the Selection Type to Global Node IDs). So, I don't know if > there is something strange happening when the clip filter tries to copy > across the GlobalIds since they're not really of the correct type? > > Anyway, thanks for getting back to me on this and I'll let you know how it > goes. > -Eric > > > On Apr 23, 2010, at 4:11 PM, David E DeMarle wrote: > >> The XDMF in 3.6 did not have the global id attribute so it did the >> unsafe thing and let filters have their way with them. It kept the >> array around, but in most cases the values in the array at the end of >> the pipeline were worthless. >> >> Not that XDMF does have global ids, the clip filter (like most of the >> other filters) is doing the safe thing and not keeping the globalids. >> >> Off the top of my head, I can not think of a reason really why the >> clip filter shouldn't be allowed to copy the globalids across though. >> >> Erik, try this and see if it works for you: >> >> in vtkTableBasedClipDataSet, look for the three places where it calls >> CopyAllocate. >> For example: >> outPD->CopyAllocate(inPD, nOutPts); >> >> Insert a line before each one of those that tells VTK that it is OK >> top copy this array across. >> In that case: >> outPD->SetCopyGlobalIds(1,vtkDataSetAttributes::COPYTUPLE); >> >> The globalIDS will then make it through this filter. >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 28 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-371-3971 x109 >> >> >> >> On Mon, Apr 19, 2010 at 1:48 PM, Eric E. Monson <emon...@cs.duke.edu> wrote: >>> Hello, >>> >>> It seems that we're sort of getting the worst of both worlds right now >>> ParaView and Xdmf GlobalID AttributeType: Besides not being read in as >>> "idtype", a Clip filter removes the GlobalID attribute from the data set. >>> >>> Attached is a simple XML example adapted from the Xdmf source data sets, >>> but with a duplicate scalar point attribute labeled as >>> AttributeType="GlobalID". Load it into PV and apply a Clip filter and >>> you'll see the IDvalues array disappear. >>> >>> I see this behavior with PV 3.8-RC1 and last week's CVS, but not with >>> 3.6.2. I can't remember if the Xdmf reader in 3.6.2 had GlobalID type or >>> not. (OS X 10.6.3) >>> >>> I can file a bug report for this if someone can replicate it. >>> >>> Thanks a lot, >>> -Eric >>> >>> ------------------------------------------------------ >>> Eric E Monson >>> Duke Visualization Technology Group >>> >>> >>> _______________________________________________ >>> 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 ParaView Wiki at: >>> http://paraview.org/Wiki/ParaView >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.paraview.org/mailman/listinfo/paraview >>> >>> > > _______________________________________________ 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 ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
