MantisBT - ParaView
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015679ParaView(No Category)public2015-08-25 20:372015-09-06 12:17
ReporterAlan Scott 
Assigned ToDan Lipsa 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Versiongit-master 
Target Version4.4Fixed in Version4.4 
ProjectSandia
Topic Name
Typeincorrect functionality
Summary0015679: parallel, remote server fails (and soon faults) rendering vts/ pvd files
DescriptionI have a dataset that is showing crazy behavior with ParaView in parallel. Here is how to replicate:

* Linux, master, Local server.
* Open G1WakeGrid.pvd. Apply. There are 6 timesteps. (Note that the .pvd file has many more timesteps. Don't go beyond about step 4, or you get an error from the inconsistent .pvd file.)
* Step forward a few timesteps. Step back.
<<Note>> This case looks good.

* Linux, master, Remote server, 2 processes.
* Open G1WakeGrid_0.vts. Apply.
<<Note>> This case looks good.
* Open G1WakeGrid_1.vts. Apply.
<<Note>> This case looks good.

* Linux, master, Remote server, 2 processes.
* Open G1WakeGrid.pvd. Apply.
* Step forward one timesteps.
<<Bug>> This case looks bad. Half of the model will go away. If you go to the information tab, every step forward or backward will halve the number of cells/ points in the dataset. Just step forward/ back to see this crazy behavior.

This will eventually progress until there is a seg fault, trying to malloc a few trillion bytes.

Utkarsh, ask me for this dataset.

Alan - G1WakeGrid, gpfs1.


Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0015470closed David C. Lonie pvd + vtr combo doesn't work in parallel 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-08-25 20:37Alan ScottNew Issue
2015-08-25 20:38Alan ScottNote Added: 0035062
2015-08-25 20:38Alan ScottStatusbacklog => todo
2015-08-25 20:38Alan ScottTarget Version => 4.4
2015-08-31 16:59Utkarsh AyachitNote Added: 0035109
2015-08-31 17:02Utkarsh AyachitRelationship addedrelated to 0015470
2015-08-31 17:02Utkarsh AyachitAssigned To => Dan Lipsa
2015-08-31 17:04Alan ScottNote Added: 0035110
2015-09-02 14:41Dan LipsaNote Added: 0035127
2015-09-02 14:42Dan LipsaNote Edited: 0035127bug_revision_view_page.php?bugnote_id=35127#r1263
2015-09-02 14:42Dan LipsaNote Edited: 0035127bug_revision_view_page.php?bugnote_id=35127#r1264
2015-09-02 14:43Dan LipsaStatustodo => gatekeeper review
2015-09-02 14:46Utkarsh AyachitStatusgatekeeper review => customer review
2015-09-02 14:46Utkarsh AyachitResolutionopen => no change required
2015-09-02 14:46Utkarsh AyachitFixed in Version => git-master
2015-09-02 19:48Alan ScottNote Added: 0035143
2015-09-02 19:48Alan ScottStatuscustomer review => closed
2015-09-06 12:17Utkarsh AyachitFixed in Versiongit-master => 4.4

Notes
(0035062)
Alan Scott   
2015-08-25 20:38   
Marking for 4.4, since this is impacting a customer.
(0035109)
Utkarsh Ayachit   
2015-08-31 16:59   
Very curious indeed!
(0035110)
Alan Scott   
2015-08-31 17:04   
I figured you'd like this one!
(0035127)
Dan Lipsa   
2015-09-02 14:41   
(edited on: 2015-09-02 14:42)
Indeed, this seems already fixed in master as of commit
33d87dede6aafdd3a4a28bd52288e91e0da88b1d.
I cannot reproduce the behavior described.
(0035143)
Alan Scott   
2015-09-02 19:48   
Fixed.

Tested Linux, remote server, 8 servers, master.