MantisBT - ParaView | |||||
View Issue Details | |||||
ID | Project | Category | View Status | Date Submitted | Last Update |
0009626 | ParaView | Bug | public | 2009-09-30 12:10 | 2009-10-02 14:59 |
Reporter | Zhanping Liu | ||||
Assigned To | Zhanping Liu | ||||
Priority | normal | Severity | minor | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Platform | OS | OS Version | |||
Product Version | 3.6 | ||||
Target Version | 3.6.2 | Fixed in Version | 3.6.2 | ||
Project | |||||
Topic Name | |||||
Type | |||||
Summary | 0009626: Wrong bounding info obtained in vtkMergeCells::MapPointsToIdsUsingLocator() | ||||
Description | I have had a problem of ridiculously slow D3 of PV 3.6.1/3.7-cvs under some conditions. Most of the time the problem occurs when I have more pvserver processes than the number of data pieces, in which case D3 takes two orders of magnitude more time than usual, despite that the resulting repartitioned dataset looks fine. Attaching a performance analyzer (Apple's Shark) to the pvserver processes revealed that, in one of the pvserver processes vtkMergePoints::InsertUniquePoint() took up virtually all of the processor time, as attached sharkOutput.jpg. It further turned out that this is because the instance of vtkMergePoints is given indeterminate bounds by its caller vtkMergeCells::MapPointsToIdsUsingLocator() and hence hashing based on relative point coordinates in the bounds is not working. Here is a proposed fix to the problem (the comment "points0->GetNumberOfPoints() is equal to..." was taken from about 50 lines below the patched lines in the same function. I believe it explains everything.). Index: vtkMergeCells.cxx =================================================================== RCS file: /cvsroot/ParaView3/ParaView3/VTK/Graphics/vtkMergeCells.cxx,v retrieving revision 1.9 diff -u -r1.9 vtkMergeCells.cxx --- vtkMergeCells.cxx 23 Jan 2009 03:25:07 -0000 1.9 +++ vtkMergeCells.cxx 30 Sep 2009 06:47:09 -0000 @@ -723,7 +723,12 @@ if (npoints0 > 0) { double tmpbounds[6]; + // points0->GetNumberOfPoints() is equal to the upper bound + // on the points in the final merged grid. We need to temporarily + // set it to the number of points added to the merged grid so far. + points0->GetData()->SetNumberOfTuples(npoints0); grid->GetBounds(tmpbounds); + points0->GetData()->SetNumberOfTuples(this->TotalNumberOfPoints); bounds[0] = ((tmpbounds[0] < bounds[0]) ? tmpbounds[0] : bounds[0]); bounds[2] = ((tmpbounds[2] < bounds[2]) ? tmpbounds[2] : bounds[2]); | ||||
Steps To Reproduce | |||||
Additional Information | This bug was reported by Takuya Oshima. Thanks. | ||||
Tags | No tags attached. | ||||
Relationships | |||||
Attached Files | |||||
Issue History | |||||
Date Modified | Username | Field | Change | ||
2009-09-30 12:10 | Zhanping Liu | New Issue | |||
2009-09-30 12:11 | Zhanping Liu | Assigned To | => Zhanping Liu | ||
2009-09-30 12:11 | Zhanping Liu | Status | backlog => tabled | ||
2009-09-30 12:34 | Zhanping Liu | Note Added: 0017847 | |||
2009-09-30 12:34 | Zhanping Liu | Status | tabled => @80@ | ||
2009-10-01 10:51 | Utkarsh Ayachit | Fixed in Version | => 3.6.2 | ||
2009-10-01 10:51 | Utkarsh Ayachit | Target Version | => 3.6.2 | ||
2009-10-01 10:52 | Utkarsh Ayachit | Note Added: 0017866 | |||
2009-10-02 14:59 | Alan Scott | Note Added: 0017912 | |||
2009-10-02 14:59 | Alan Scott | Status | @80@ => closed | ||
2009-10-02 14:59 | Alan Scott | Resolution | open => fixed |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|