[vtkusers] Different behavior of vtkXMLPUnstructuredGridWriter in VTK 7.1
Andy Bauer
andy.bauer at kitware.com
Mon Feb 5 13:07:26 EST 2018
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/fa1f6ca8/attachment.html>
More information about the vtkusers
mailing list