MantisBT - ParaView
View Issue Details

ID	Project	Category	View Status	Date Submitted	Last Update
0015407	ParaView	(No Category)	public	2015-04-02 17:55	2015-09-06 12:18

Reporter	Alan Scott
Assigned To	Utkarsh Ayachit
Priority	high	Severity	minor	Reproducibility	have not tried
Status	closed	Resolution	fixed
Platform		OS		OS Version
Product Version	4.3
Target Version	4.4	Fixed in Version	4.4
Project	Sandia
Topic Name
Type	incorrect functionality

Summary	0015407: State files failing with changing max time
Description	I have numerous users that are having issues with state files pointing to datasets that have a variable number of timesteps. This happens for at least two reasons. One is you create a state fine from one dataset (such as climate for February), and want to then use the same state file on a dataset that is exactly the same, but from another month (March) (28 vs 31 days). The second is if you need to visualize a dataset that is being written, and will be for many days or a few weeks. You want to know it is running correctly. If it is a complex visualization, you want to set up your pipeline once, save a state file, and continuously re-use it on the dataset as it is being written. A common example is simulating a house fire - there are lots of steps to get to a car on fire. Here is how to replicate this bug. I am providing three datasets, 1 timestep (toy_problem_timestep1.e), 5 timesteps (toy_problem_timestep4.e) and 9 timesteps (toy_problem_timestep8.e). * Local server, Linux, 4.3.1. * Open toy_problem_timestep1.e. * Information tab. Notice that there are no timestep. * File/ Save State. I am saving as toyC.pvsm * Edit/ Reset Session. * File/ Load State. Now, point at toy_problem_timestep8.e. OK. * Information tab. Notice that there are 9 timesteps. <<bug - notice that the Time toolbar does not have the correct maximum number of timesteps.>> * Play. Notice that you do see all 9 (0-8)timesteps, and we go to time 2. this is correct. However, I think this is a hidden artifact of my toy dataset - it only goes to 2 seconds. If it went higher, you would also see bugs. We will replicate this next. * File/ Reset session. * Edit the toyC.pvsm file. * <<not necessary>> To make life easier, change all references to toy_problem_timestep1.e to toy_problem_timestep8.e. * Change line 19, under the Properties name="EndTime", to value="0". * Save toyC.pvsm. * In ParaView, open state file toyC.pvsm. * <<bug>> Play. We don't move forward in time. If you look in the Information tab, you can see that the Exodus reader knows about the timesteps, but ParaView doesn't. * File/ Reset session. * Edit the toyC.pvsm file. * Change line 19, under the Properties name="EndTime", to value="1.1" (my user's EndTime is actually around 0.6, so floating point is saved some times. * Save toyC.pvsm. * In ParaView, open state file toyC.pvsm. * <<bug>> Play. We don't move forward in time. * More detail - Open the View/ Animation View. Snap to Timesteps. You only see three timesteps (out of 9). Solution: * File/ Reset session. * Edit the toyC.pvsm file. * Delete lines 18, 19 and 20 (i.e., name="EndTime"). * Save toyC.pvsm. * In ParaView, open state file toyC.pvsm. * <<bug>> Play. This will work properly. (However, you never do get the correct max number of steps in the time toolbar. Sorry for being so verbose, but wanted to be clear. I will give the datasets to Utkarsh (including the final toyC.pvsm). It is DoNotRelease-reloadStateFileError.tar.gz.
Steps To Reproduce
Additional Information
Tags	No tags attached.
Relationships
Attached Files

Issue History
Date Modified	Username	Field	Change
2015-04-02 17:55	Alan Scott	New Issue
2015-04-02 18:27	Alan Scott	Target Version	=> 4.4
2015-04-06 14:15	Utkarsh Ayachit	Note Added: 0034338
2015-04-08 17:09	Alan Scott	Note Added: 0034347
2015-04-09 16:41	Utkarsh Ayachit	Note Added: 0034351
2015-04-09 16:41	Utkarsh Ayachit	Status	backlog => gatekeeper review
2015-04-09 16:41	Utkarsh Ayachit	Resolution	open => fixed
2015-04-09 16:41	Utkarsh Ayachit	Assigned To	=> Utkarsh Ayachit
2015-04-10 19:42	Utkarsh Ayachit	Note Added: 0034356
2015-04-10 19:42	Utkarsh Ayachit	Status	gatekeeper review => customer review
2015-04-10 19:42	Utkarsh Ayachit	Fixed in Version	=> git-master
2015-04-29 20:37	Alan Scott	Note Added: 0034383
2015-04-29 20:37	Alan Scott	Status	customer review => closed
2015-09-06 12:18	Utkarsh Ayachit	Fixed in Version	git-master => 4.4

Notes

I'll answer this in parts, since there are many parts to this bug.

-------------------------------------------------------------------------------------------------------------------------------
Part A:
-------------------------------------------------------------------------------------------------------------------------------

* Open toy_problem_timestep1.e.
* Information tab. Notice that there are no timestep.
* File/ Save State. I am saving as toyC.pvsm
* Edit/ Reset Session.
* File/ Load State. Now, point at toy_problem_timestep8.e. OK.
* Information tab. Notice that there are 9 timesteps.
<<bug - notice that the Time toolbar does not have the correct maximum number of timesteps.>>
* Play. Notice that you do see all 9 (0-8)timesteps, and we go to time 2. this is correct. However, I think this is a hidden artifact of my toy dataset - it only goes to 2 seconds. If it went higher, you would also see bugs. We will replicate this next.

Explanation:

I contend this is not a bug. The issue here is that the original dataset (timetesp1.e) had no timesteps at all. Thus, when the data file is loaded, ParaView doesn't switch the animation playback mode to "Snap To TimeSteps", but leaves it at default: "Sequence". Now, when you load this state file, toyC.pvsm, (and change the dataset to be timestep8.e), while ParaView has noticed the 8 timesteps, since you're loading state file, it won't change the "Play Mode" automatically. It has to preserve the animation state from the PVSM file. This the first issue you see. The time toolbar didn't change since the current play mode doesn't follow the timesteps in the dataset. If you manually change the animation mode to be "Snap To TimeSteps", the toolbar will correctly show "0 of 9" and stepping through the animation one step at a time will confirm that the time values go from 0.0 to 2.0.

You'll not see this issue if the timestep1.e even had 1 timestep. Currently it has no timesteps at all.

-------------------------------------------------------------------------------------------------------------------------------
Part B:
-------------------------------------------------------------------------------------------------------------------------------
* File/ Reset session.
* Edit the toyC.pvsm file.
* <<not necessary>> To make life easier, change all references to toy_problem_timestep1.e to toy_problem_timestep8.e.
* Change line 19, under the Properties name="EndTime", to value="0".
* Save toyC.pvsm.
* In ParaView, open state file toyC.pvsm.
* <<bug>> Play. We don't move forward in time. If you look in the Information tab, you can see that the Exodus reader knows about the timesteps, but ParaView doesn't.

Explanation:

What you're doing here is bad. One should not do this. But if you do this, what you see is exactly what's expected. Let me explain. toyC.pvsm has default animation playback mode set to "Sequence" (as explained in Part A). Thus, the animation is set to go from StartTime to EndTime, in as many steps as NumberOfFrames (by default this is 10). Now, you edited the file to change the EndTime to 0. The StartTime, by default, is 0. Hence you're telling the animation to go from Time 0 to 0. Hence nothing changes.

-------------------------------------------------------------------------------------------------------------------------------
Part C:
-------------------------------------------------------------------------------------------------------------------------------

I am a little lost after this :). But, here's an alternative set of steps that work as expected.

* ParaView, Local Server
* Open timestep4.e, Apply
* Play -- notice we go from through 5 timesteps - 0, 0.26, 0.5, 0.76, 1
* Save state file as toy4.pvsm

* Reset session
* Load toy4.pvsm but change the FileName and FilePrefix to point to timestep8.e instead of timestep4.e.
* Notice Time toolbar shows (0 of 9) as expected.
* Play, and you'll see the animation goes through 9 steps: 0, 0.26, 0.5, 0.76, 1, 1.26, 1.5, 1.76, and 2.

So the bottom line is that if the original dataset had no timesteps, then if you replaced it with a dataset that has timesteps, you need to change the Play Mode. Note, there's a difference between a dataset that has *no* timesteps and a dataset that has 1 timestep. I suspect things will work fine if the dataset has 1 timestep too.