[Paraview] problem in defining vtkStructuredGrid in MPI
u.utku.turuncoglu at be.itu.edu.tr
u.utku.turuncoglu at be.itu.edu.tr
Tue Jun 30 08:32:11 EDT 2015
Hi Again,
Now, i have some problem when i trying to create the visualisation. I
created grid as it suggested. In this case, i have multi piece data
(structured grid) inside of the single block. The grid can be seen in the
attached plot (plot_grid.png).In this case, it seems correct and you could
see the each element clearly. If i attach data to the grid using Paraview
co-processing then i am getting output as it shown in the image_0.png. So,
i have still see the gaps between the pieces even the grid defined
correctly. Is it normal in this case? It might be the feature of multi
piece dataset. Anyway, i would like to see the complete view of the field
without any gap between the pieces (or decomposition elements). Is it
possible to do that with the current setup? I might also need to add the
overlap regions (among the decomposition elements) in the grid but i am
not sure. Any suggestion might be helpful at this point.
Best Regards,
--ufuk
> Hi,
>
> Thanks for your suggestion. I did it as follows,
>
> vtkMultiBlockDataSet* grid = vtkMultiBlockDataSet::New();
> vtkNew<vtkMultiPieceDataSet> mpds;
> mpds->SetNumberOfPieces(*mpiSize);
> mpds->SetPiece(*mpiRank, sg.GetPointer());
> grid->SetNumberOfBlocks(1);
> grid->SetBlock(0, mpds.GetPointer());
>
> so, there is one block that has each partition in a vtkMultiPieceDataSet.
> Thanks again.
>
> Regards,
>
> --ufuk
>
>
>> If the output of the vtm is what you're looking for you won't be able to
>> do
>> that with the parallel XML structured grid writer because you have a
>> node
>> partition (i.e. nodes are uniquely assigned to a process and in this
>> case
>> no other process has that node). Thus the missing cells at the partition
>> boundary are causing you problems with the pvts reader.
>>
>> With the multiblock data set my suggestion is to make the first block in
>> that be a vtkMultiPieceDataSet and then add each process's structured
>> grid
>> as a piece to that. Then when you load it into ParaView it will behave
>> much
>> more uniformly.
>>
>>
>>
>> On Fri, Jun 26, 2015 at 9:56 AM, <u.utku.turuncoglu at be.itu.edu.tr>
>> wrote:
>>
>>> Hi,
>>>
>>> Thanks for your help. Actually, every processor has its own data and i
>>> am
>>> just using the interior regions (so, it does not overlap, no ghost or
>>> halo
>>> regions). Anyway, after my initial mail, i changed the SetExtent part
>>> of
>>> the code as
>>>
>>> sg->SetExtent (*nxstart-2, *nxend-2, *nystart-2, *nyend-2, 0, 0);
>>>
>>> because it was starting from 1 in each direction, now it starts from
>>> zero.
>>> This modification fixes the mismatch problem in the number of points
>>> comes
>>> from Paraview and seen in the C++ code. On the other hand, the Paraview
>>> still complains about the following extents (seems that the inner
>>> boundary
>>> of the 2 x 2 decomposition elements, like ghost region).
>>>
>>> 0 140 57 58 0 0
>>> 70 71 0 57 0 0
>>> 70 71 58 114 0 0
>>>
>>> You can find the data in the attached file (data_00.tar.gz).
>>>
>>> Then, i tried to put the individual parts of the structured grid into
>>> the
>>> vtkMultiBlockDataSet using following code
>>>
>>> //
>>> // Create multi block grid
>>> //
>>> vtkMultiBlockDataSet* grid = vtkMultiBlockDataSet::New ();
>>> grid->SetNumberOfBlocks(*mpiSize);
>>> grid->SetBlock (*mpiRank, sg.GetPointer());
>>>
>>> and write the grid information to the file (data_01.tar.gz). In this
>>> case,
>>> Paraview could open the *.vtm file without any message. So, i could not
>>> be
>>> sure about the grid. It seems fine if i look at multi block data file
>>> (vtm) but not in pvts file.
>>>
>>> Regards,
>>>
>>> --ufuk
>>>
>>>
>>> > Do you have a node partitioning of your grid? If you do you really
>>> need a
>>> > cell partitioning of the grid which will have multiple points a the
>>> > partition overlap.
>>> >
>>> > Can you share your data?
>>> >
>>> > On Fri, Jun 26, 2015 at 5:58 AM, <u.utku.turuncoglu at be.itu.edu.tr>
>>> wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I am trying to create structured grid in an MPI application and i am
>>> >> using
>>> >> following C++ code to implement it
>>> >>
>>> >> extern "C" void createstgrid_(double* y, double* x,
>>> >> int* nxstart, int* nxend, int*
>>> nystart,
>>> >> int*
>>> >> nyend,
>>> >> int* nx, int* ny, int* nz, int*
>>> mpiSize,
>>> >> int* mpiRank) {
>>> >> //
>>> >> // Create structured grid
>>> >> //
>>> >> vtkSmartPointer<vtkStructuredGrid> sg =
>>> >> vtkSmartPointer<vtkStructuredGrid>::New();
>>> >> sg->SetExtent (*nxstart-1, *nxend-1, *nystart-1, *nyend-1, 0, 0);
>>> >>
>>> >> //
>>> >> // Create data structure to store grid coordinates
>>> >> //
>>> >> int pnx = ((*nxend)-(*nxstart))+1;
>>> >> int pny = ((*nyend)-(*nystart))+1;
>>> >> vtkSmartPointer<vtkPoints> points =
>>> vtkSmartPointer<vtkPoints>::New();
>>> >>
>>> >> //
>>> >> // Insert grid coordinate data as points
>>> >> //
>>> >> k = 0;
>>> >> for (int j = 0; j < pny; j++) {
>>> >> for (int i = 0; i < pnx; i++) {
>>> >> points->InsertPoint(k, x[i+j*pnx], y[i+j*pnx], 0);
>>> >> k = k+1;
>>> >> }
>>> >> }
>>> >> sg->SetPoints(points);
>>> >>
>>> >> //
>>> >> // Set grid
>>> >> //
>>> >>
>>> >>
>>> vtkCPPythonAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName("input")->SetGrid(sg);
>>> >>
>>> >>
>>> vtkCPPythonAdaptorAPI::GetCoProcessorData()->GetInputDescriptionByName("input")->SetWholeExtent(0,
>>> >> *nx-1, 0, *ny-1, 0, 0);
>>> >> }
>>> >>
>>> >> so, when i run the code with grid writer, it creates the individual
>>> file
>>> >> (*.vts) for each processor and one extra for the combination
>>> (*.pvts).
>>> >> Anyway, the individual files looks fine in Paraview but if i open
>>> the
>>> >> file
>>> >> with pvts extension, i am getting following error,
>>> >>
>>> >> ERROR: In
>>> >>
>>> >>
>>> /Users/turuncu/Qsync/progs/paraview-4.3.1/src/VTK/IO/XML/vtkXMLPStructuredDataReader.cxx,
>>> >> line 461
>>> >> vtkXMLPStructuredGridReader (0x7f961c0910a0): No available piece
>>> >> provides
>>> >> data for the following extents:
>>> >> 0 140 0 1 0 0
>>> >> 0 1 1 58 0 0
>>> >> 0 140 58 59 0 0
>>> >> 0 1 59 114 0 0
>>> >> 71 72 1 58 0 0
>>> >> 71 72 59 114 0 0
>>> >>
>>> >> The UpdateExtent cannot be filled.
>>> >>
>>> >> What is the meaning of this message? It means that some of the grid
>>> data
>>> >> (or points) are not filled by the code. I also check the loop in the
>>> C++
>>> >> code and print out the number of points for each processor
>>> >>
>>> >> 0 number of points = 4118
>>> >> 1 number of points = 4047
>>> >> 2 number of points = 4060
>>> >> 3 number of points = 3990
>>> >>
>>> >> and the total is 16215, which is consistent with the size of the
>>> grid
>>> >> but
>>> >> if i check the individual vts files from the Paraview, the files
>>> shows
>>> >> different number of points for each file
>>> >>
>>> >> 0 number of points = 4118
>>> >> 1 number of points = 3976
>>> >> 2 number of points = 4002
>>> >> 3 number of points = 3864
>>> >>
>>> >> So, only first file matchs with the C++ code but others not. I am
>>> not
>>> >> sure
>>> >> what is happening in there and if you have any suggestion that will
>>> be
>>> >> great.
>>> >>
>>> >> Anyway, in this case i did not use vtkMultiBlockDataSet but after
>>> having
>>> >> correct representation of the grid, i am planing use SetBlock method
>>> of
>>> >> vtkMultiBlockDataSet to assign decomposition elements as individual
>>> >> blocks.
>>> >>
>>> >> Regards,
>>> >>
>>> >> --ufuk
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >>
>>> >
>>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plot_grid.png
Type: image/png
Size: 83665 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150630/ce0f5f54/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image_0.png
Type: image/png
Size: 19597 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150630/ce0f5f54/attachment-0003.png>
More information about the ParaView
mailing list