View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014373 | ParaView | (No Category) | public | 2013-10-29 18:45 | 2016-07-14 20:09 | ||||
Reporter | Alan Scott | ||||||||
Assigned To | Alan Scott | ||||||||
Priority | high | Severity | minor | Reproducibility | have not tried | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | git-master | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0014373: Time should not be read from state files | ||||||||
Description | When 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. | ||||||||
Tags | No tags attached. | ||||||||
Project | Sandia | ||||||||
Topic Name | |||||||||
Type | incorrect functionality | ||||||||
Attached Files | stateTimeBug.tar.gz [^] (6,644 bytes) 2013-10-29 18:47 | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |