[vtkusers] Different behavior of vtkXMLPUnstructuredGridWriter in VTK 7.1

Andrew Parker andy.john.parker at googlemail.com
Mon Feb 5 13:40:25 EST 2018


Andy,

My own code. I’ve always had those Piece lines in my src from day one, and
always used it via mpi, so don’t need added. All procs call all lines in my
file writer. There is no if-master-section.  Literally just a vtk version
number change that causes the problem. Can’t get the data files or the cut
down source until tomorrow.

I shared the other two links as those in addition to this post are the only
places I can find that reference such a major change to the library that is
undocumented and causes such a significant change to user code. Are there
any further references on this change that I can read about to try to
resolve this?

I find it strange that this has not come up more. It would mean all users
of 7.1 without the additional vtkmpicontroller lines would fail when
calling a parallel writer from a parallel mpi-user-code....

Cheers,
Andy

On Mon, 5 Feb 2018 at 18:07, Andy Bauer <andy.bauer at kitware.com> wrote:

> Are you using libMesh or another simulation code? You'll definitely need
> the following to tell each process what piece it has:
> pwriter->SetNumberOfPieces(nprocs);
>
> pwriter->SetStartPiece(rank);
>
> pwriter->SetEndPiece(rank);
>
> pwriter->Write();
>
> Can you share the portion of your code that uses
> vtkXMLPUnstructuredGridWriter? Also, looking at the data files from 6.3 and
> 7.1.1 may help.
>
> Thanks,
> Andy
>
>
> On Mon, Feb 5, 2018 at 12:08 PM, Andrew Parker <
> andy.john.parker at googlemail.com> wrote:
>
>> Andy,
>>
>> Just moved from vtk 6.3.0 to vtk 7.1.1.  Cannot for the life of me get
>> your modifications to work from your vtk_test.C.  I've included the
>> vtkmpiController stuff after I init mpi myself.  I found the migration
>> problem mentioned here:
>>
>> https://github.com/libMesh/libmesh/issues/1179
>>
>> and here:
>>
>> https://gitlab.kitware.com/vtk/vtk/issues/16924
>>
>> as well as this post.  My parallel unstructured grid now only contains
>> one source within the piece section of the pvtu, as opposed to n-processor
>> sources (all processors have real data to write and this is not a case of
>> empty meshes on these processors).  I can re-link and recompile against 6.3
>> and the problem goes away and I get the correct number of sources written
>> to the pvtu file as before.  Can you help?  I make extensive use of pvtu
>> files from my mpi-based code and now all grid files (pvtu and pvtp) have
>> stopped working just by moving to 7.1.1 (which has been built with
>> mpi-enabled).
>>
>> Any thoughts?
>>
>> Thanks,
>> Andy
>>
>>
>> On 6 December 2016 at 16:12, Andy Bauer <andy.bauer at kitware.com> wrote:
>>
>>> Hi John,
>>>
>>> The issue is indeed due to changes that I mentioned before (i.e. only
>>> data sets that have data get written out and the .pvtu file is adjusted
>>> accordingly). With this change though interprocess communication is
>>> required which is done the the
>>> vtkMultiProcessController::GetGlobalController() object which essentially
>>> acts as MPI_COMM_WORLD within VTK. You need to create a vtkMPIController
>>> which derives from vtkMultiProcessController. See the attached files for
>>> how that is done. This should also be backwards compatible but if it isn't,
>>> please let us know.
>>>
>>> Best,
>>> Andy
>>>
>>> ps. Ignore the ADIOS stuff in there (it's commented out). I was trying
>>> to do two things at once and that's why the ADIOS stuff is in the
>>> CMakeLists.txt.
>>>
>>> On Mon, Dec 5, 2016 at 6:06 PM, John Peterson <jwpeterson at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Dec 5, 2016 at 12:45 PM, Andy Bauer <andy.bauer at kitware.com>
>>>> wrote:
>>>>
>>>>> Beyond this I can't think of any change off the top of my head that
>>>>> would cause your issue. I looked at the repo but can't figure out the VTK
>>>>> configurations from that. If you can share a simple test case which
>>>>> demonstrates the issue I may be able to easily diagnose it.
>>>>>
>>>>
>>>> Here's a standalone test code that reproduces the issue for me:
>>>>
>>>> https://gist.github.com/jwpeterson/92f4b8422d6fbb1056e848c9b14ee1d7
>>>>
>>>> Run on two procs with: mpiexec -np 2 and I get the following test.pvtu
>>>> file:
>>>>
>>>> <?xml version="1.0"?>
>>>>> <VTKFile type="PUnstructuredGrid" version="0.1"
>>>>> byte_order="LittleEndian" header_type="UInt32"
>>>>> compressor="vtkZLibDataCompressor">
>>>>>   <PUnstructuredGrid GhostLevel="1">
>>>>>     <PPointData>
>>>>>       <PDataArray type="Float64" Name="u"/>
>>>>>     </PPointData>
>>>>>     <PCellData>
>>>>>       <PDataArray type="Int32" Name="elem_id"/>
>>>>>       <PDataArray type="Int32" Name="subdomain_id"/>
>>>>>       <PDataArray type="Int32" Name="processor_id"/>
>>>>>     </PCellData>
>>>>>     <PPoints>
>>>>>       <PDataArray type="Float64" Name="Points" NumberOfComponents="3"/>
>>>>>     </PPoints>
>>>>>     <Piece Source="test_0.vtu"/>
>>>>>   </PUnstructuredGrid>
>>>>> </VTKFile>
>>>>
>>>>
>>>>
>>>> As you can see, only one "Piece Source" is listed, but the output of
>>>> the program is actually all 3 files (test.pvtu, test_0.vtu, test_1.vtu) and
>>>> both the _0 and _1 files have nodes in them.  Furthermore, if I simply add
>>>> a second "Piece Source" line corresponding to "test_1.vtu", the whole thing
>>>> opens up just fine in Paraview.  I am a novice VTK programmer so it's very
>>>> possible I'm doing something wrong, but this code definitely worked in VTK
>>>> 6.x, and 7.0.
>>>>
>>>> Thanks for your help,
>>>> John
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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: <https://vtk.org/pipermail/vtkusers/attachments/20180205/041221e4/attachment.html>


More information about the vtkusers mailing list