View Issue Details Jump to Notes ] Print ]
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 
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.


TagsNo tags attached.
ProjectSandia
Topic Name
Typeincorrect functionality
Attached Files

 Relationships
related to 0015470closedDavid C. Lonie pvd + vtr combo doesn't work in parallel 

  Notes
(0035062)
Alan Scott (manager)
2015-08-25 20:38

Marking for 4.4, since this is impacting a customer.
(0035109)
Utkarsh Ayachit (administrator)
2015-08-31 16:59

Very curious indeed!
(0035110)
Alan Scott (manager)
2015-08-31 17:04

I figured you'd like this one!
(0035127)
Dan Lipsa (developer)
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 (manager)
2015-09-02 19:48

Fixed.

Tested Linux, remote server, 8 servers, master.

 Issue History
Date Modified Username Field Change
2015-08-25 20:37 Alan Scott New Issue
2015-08-25 20:38 Alan Scott Note Added: 0035062
2015-08-25 20:38 Alan Scott Status backlog => todo
2015-08-25 20:38 Alan Scott Target Version => 4.4
2015-08-31 16:59 Utkarsh Ayachit Note Added: 0035109
2015-08-31 17:02 Utkarsh Ayachit Relationship added related to 0015470
2015-08-31 17:02 Utkarsh Ayachit Assigned To => Dan Lipsa
2015-08-31 17:04 Alan Scott Note Added: 0035110
2015-09-02 14:41 Dan Lipsa Note Added: 0035127
2015-09-02 14:42 Dan Lipsa Note Edited: 0035127
2015-09-02 14:42 Dan Lipsa Note Edited: 0035127
2015-09-02 14:43 Dan Lipsa Status todo => gatekeeper review
2015-09-02 14:46 Utkarsh Ayachit Status gatekeeper review => customer review
2015-09-02 14:46 Utkarsh Ayachit Resolution open => no change required
2015-09-02 14:46 Utkarsh Ayachit Fixed in Version => git-master
2015-09-02 19:48 Alan Scott Note Added: 0035143
2015-09-02 19:48 Alan Scott Status customer review => closed
2015-09-06 12:17 Utkarsh Ayachit Fixed in Version git-master => 4.4


Copyright © 2000 - 2018 MantisBT Team