[vtkusers] how to avoid overlapping (ghost) layer in *.pvti files

[Berk Geveci]

Yes, writing as cell data will fix the issue. I also agree that in
practice, there is no difference and that the reader should handle your
case by doing redundant reads across files when reading in parallel and
without any additional work when reading in serial. It is a deficiency in
the reader.

Best,
-berk

On Mon, Nov 9, 2015 at 11:37 AM, Kaya Onur Dag <kaya.onur.dag at gmail.com>
wrote:

> Dear Berk,
>
> Thanks for the reply.
>
> I will adjust my data to write cell data instead of point data and overlap
> cell boundary nodes.. I think this would be most reasonable approach. To my
> (naive) understanding, (even) if I reproduce nodes to overlap with mpi
> transfers, that would be wrong since paraview will be taking them as cell
> arrays even if they were mentioned as point data.
>
> Further, technically it should be possible to interpolate also with the
> point data with given information since the shared boundary this time is
> the one in between two points from two different fields. Also I think there
> should not be a need for an external filter to do such an operation. It
> should just do it automatically. It is referred as point data at the end,
> and necessary information is provided in the pvti file... Well it just
> boils to the point that I just can't understand why Paraview is not capable
> of taking 2 datas from 2 different fields and interpolate in between.
> Because it does interpolate if the data is from the same file. This is very
> annoying for a user like me who doesn't know much about these :)
>
> Thanks again.
>
> Kaya
>
> On 9 November 2015 at 15:54, Berk Geveci <berk.geveci at kitware.com> wrote:
>
>> Dear Kaya,
>>
>> We need nodes overlapping for visualization purposes. We need to be able
>> to interpolate the field on each partition all the way to a shared boundary
>> to prevent gaps. Think of operations such as slicing or iso-surfacing. You
>> can verify this by loading several vti files individually, grouping them
>> and then applying slice. You'll see the gap at the boundary. There are
>> various way of fixing this. One would be to use a format such as hdf5 and
>> write to a single 3D array. Another would be to do the data movement to
>> close the gaps in ParaView. We currently don't have a filter that does this
>> out of box so using a Python programmable with mpi4py would be the simplest
>> way to go there. Then there is the option of doing it in the code before
>> outputting of course. From a developer perspective, this may be the
>> simplest one for you to do but may introduce an overhead that may not be
>> acceptable if you are running on thousands of codes and cannot exploit some
>> sort of locality.
>>
>> Best,
>> -berk
>>
>> On Fri, Nov 6, 2015 at 4:43 AM, Kaya Onur Dag <kaya.onur.dag at gmail.com>
>> wrote:
>>
>>> I have my own cfd solver in which I was using *.vti for paraview input
>>> but decided to use parallel data write with *.pvti format and do node
>>> parallelisation.
>>>
>>> My *.pvti file is like :
>>>
>>> <?xml version="1.0"?>
>>> <VTKFile type="PImageData" version="1.0" byte_order="LittleEndian"
>>> header_type="UInt64">
>>>   <PImageData WholeExtent=[/QUOTE][/QUOTE]"       0      31       0
>>>  31       0      31" Origin="  0.000000000000E+00  0.000000000000E+00
>>>  0.000000000000E+00" Spacing="  0.196349540849E+00  0.196349540849E+00
>>>  0.645161290323E-01" GhostLevel="0">
>>>       <PPointData Scalars="u v w">
>>>     <PDataArray type="Float64" Name="u" NumberOfComponents="1"
>>> format="appended"/>
>>> <PDataArray type="Float64" Name="v" NumberOfComponents="1"
>>> format="appended"/>
>>> <PDataArray type="Float64" Name="w" NumberOfComponents="1"
>>> format="appended"/>
>>> </PPointData>
>>> <Piece Extent="0 31 0 31 0 15" Source="data0_0.vti"/>
>>> <Piece Extent="0 31 0 31 16 31" Source="data0_1.vti"/>
>>> </PImageData></VTKFile>
>>>
>>>
>>> The problem I am facing is I am having a gap in between z-axis 15-16 -
>>> which paraview complains.
>>>
>>> I know that the solution is to have a ghost (overlapping) layer (can't
>>> understand why since I am using point data?), and the issue is that my code
>>> is not capable of generating overlapping nodes, unless I code it up and
>>> manually transfer ghost layers at each data output stage for the sake of
>>> being able to write data in parallel but it feels like an overkill...
>>>
>>> Any suggestions?
>>>
>>> Thanks in advance.
>>> Kaya
>>>
>>> _______________________________________________
>>> 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
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151111/755b3597/attachment.html>