In an attempt to clear my bug backlog, I revisited this issue. I am happy to report that this is now fixed. I am even happier to report that I didn't have to do anything. It seems like our overhaul of the ghost information addressed it. The version I tested is several months all so this is definitely fixed in 4.4.
Best, -berk On Sat, Dec 6, 2014 at 11:01 AM, Berk Geveci <[email protected]> wrote: > This is a very interesting bug. First the quick fix: uncheck > vtkGhostLevels for cells and points when loading the dataset. > > Here is the explanation: > > The pvti writer writes all inputs cells including the ghost ones. So, if > you look at the resulting vti files, there is an overlap. When the pvti > reader reads these files, it makes a decision to pick the overlapping cells > from one of the files - since they are ghosts, they should be identical and > it should not matter which one. Well it does matter because if it loads a > cell from a piece that marks it as ghost instead of the one that does not, > it will only have a ghost copy of the data in the output. Which is thrown > out by the geometry filter before rendering. > > The issue with the unstructured grid is actually different. It seems like > there is a bug in the code where the ghost values are calculate for points. > It seems to be marking some of the outer boundary points as ghosts. The fix > for that is to not load vtkGhostLevels for points. > > Both of these problems show up when you are writing the data after > applying a filter that causes the reader to generate ghost levels (the > contour filter probably). Which is why this was not caught earlier. Thank > you for reporting it. > > I will work on a fix and a set of tests, hopefully for 4.3. > > Best, > -berk > > On Fri, Dec 5, 2014 at 4:58 PM, Berk Geveci <[email protected]> > wrote: > >> Thanks Greg. I'll track this down. >> >> -berk >> >> On Thu, Nov 27, 2014 at 1:40 PM, Greg Abram <[email protected]> wrote: >> >>> Hey y'all - >>> >>> Tracking down a user's problem, I'm getting some problems with >>> parallel-format files. I've generated a little test case using the >>> Wavelet source and a Calculator, creating three time steps with Result >>> being mag(coords)*1.0 1.1 and 1.2, which contour as a shrinking sphere. >>> I'm running it on 4 processes, so when I export each "timestep" I generate >>> 4 .vti's and a .pvti. These are the 'w' files. >>> >>> When I try to load the following w.pvd on Maverick (1 node, 4 >>> processes): >>> >>> <?xml version="1.0"?> >>> <VTKFile type="Collection" version="0.1" byte_order="LittleEndian"> >>> <Collection> >>> <DataSet timestep="0" group="" part="0" file="w-0.pvti"/> >>> <DataSet timestep="1" group="" part="0" file="w-1.pvti"/> >>> <DataSet timestep="2" group="" part="0" file="w-2.pvti"/> >>> </Collection> >>> </VTKFile> >>> >>> (as per >>> http://www.paraview.org/Wiki/ParaView/Data_formats#PVD_File_Format) I >>> get only parts of the data for each timestep when I use 4.2, and when I use >>> 4.1 I get a double-ghost-zone gap between the partitions. >>> >>> When I write a similar dataset after Tetrahedralizing it (to get the vtu >>> files my user is having troubles with), 4.2 does the same thing - only >>> shows one partition, though 4.1 seems OK. These are the the 't' files. >>> >>> I've uploaded the dataset to: >>> https://utexas.box.com/s/iwn4ajbvfh2davd375gh >>> >>> Greg >>> >>> Gregory D. Abram, Ph.D. >>> Research Engineering/Scientist Associate >>> Texas Advanced Computing Center >>> The University of Texas at Austin >>> (512) 471-8196 >>> [email protected] >>> >>> [image: TACC Website] <https://www.tacc.utexas.edu/> >>> >>> Connect With TACC <https://www.tacc.utexas.edu/> >>> >>> >>> >>> >>> _______________________________________________ >>> 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://public.kitware.com/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 Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
