[Paraview] Bugs with pvti and pvd

[Berk Geveci]

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 <berk.geveci at kitware.com>
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 <berk.geveci at kitware.com>
> wrote:
>
>> Thanks Greg. I'll track this down.
>>
>> -berk
>>
>> On Thu, Nov 27, 2014 at 1:40 PM, Greg Abram <gda at tacc.utexas.edu> 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
>>> gda at tacc.utexas.edu
>>>
>>> [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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150915/77da5e21/attachment.html>