View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014373ParaView(No Category)public2013-10-29 18:452016-07-14 20:09
ReporterAlan Scott 
Assigned ToAlan Scott 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versiongit-master 
Target VersionFixed in Version 
Summary0014373: Time should not be read from state files
DescriptionWhen you save and then restore a run from a state file, ParaView correctly asks for the directory and name of the dataset. It should then read what it can from the new dataset. Currently, ParaView reads time data from the state file, and if this is different than the new dataset, ParaView acts poorly. On CAM data, ParaView doesn't even read in the data.

I have a trivial example that shows bad behavior that I believe shows the bad behavior on CAM data. If necessary, I can probably voodoo up CAM data to show this problem. Let me know if it is needed.

* Unzip the attached file.
* ParaView master, Linux (or Windows), local server.
* Open file First-dataset/ sampleUnstrcturedTimeBasedXML.pvd.
* Create a state file. There is an example state file at this point, called buggyStateFile.pvsm.
* Open the state file you created. (buggyStateFile.pvsm would probably do.)
* When it asks what file you want to open, change the file to Second-dataset/ sampleUnstructuredTimeBasedXML.pvd.

Bug - Notice that it didn't open the first time step - but rather the second. Further the time says 2, which came from the previous dataset.

Note - First-dataset is exactly the same as Second-dataset, except First-dataset has time run from 2 to 3, where Second-dataset has time run from 0 to 1.

This is severely impacting climate and CAM work.
TagsNo tags attached.
ProjectSandia
Topic Name
Typeincorrect functionality
Attached Filesgz file icon stateTimeBug.tar.gz [^] (6,644 bytes) 2013-10-29 18:47

 Relationships

  Notes
(0031859)
Utkarsh Ayachit (administrator)
2013-11-15 15:27

It must be noted that the timesteps/timevalues are indeed loaded correctly. When on plays the animation, it does indeed play using the new range. The state file tries to preserve the "time" that one save out, the "current time" is never changed, it's always what the user saved out.

It's unclear if we should change the "current time" when a new dataset was loaded.
(0036499)
Alan Scott (manager)
2016-07-14 20:09

This was found and fixed about a year ago. I also just tested as stated above.

Tested Linux, remote server, 5.1.1.

 Issue History
Date Modified Username Field Change
2013-10-29 18:45 Alan Scott New Issue
2013-10-29 18:47 Alan Scott File Added: stateTimeBug.tar.gz
2013-11-15 15:27 Utkarsh Ayachit Note Added: 0031859
2016-07-14 20:09 Alan Scott Note Added: 0036499
2016-07-14 20:09 Alan Scott Status backlog => closed
2016-07-14 20:09 Alan Scott Assigned To => Alan Scott
2016-07-14 20:09 Alan Scott Resolution open => fixed


Copyright © 2000 - 2018 MantisBT Team