View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015407ParaView(No Category)public2015-04-02 17:552015-09-06 12:18
ReporterAlan Scott 
Assigned ToUtkarsh Ayachit 
PriorityhighSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.3 
Target Version4.4Fixed in Version4.4 
Summary0015407: State files failing with changing max time
DescriptionI 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.



 



  
TagsNo tags attached.
ProjectSandia
Topic Name
Typeincorrect functionality
Attached Files

 Relationships

  Notes
(0034338)
Utkarsh Ayachit (administrator)
2015-04-06 14:15

 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.
(0034347)
Alan Scott (manager)
2015-04-08 17:09

 Utkarsh,
I have permission to pass the real files to you. Just File/ Load State/ stateMaxTimeBug.pvsm. Correct the location of fluid1.e. Notice that it has 172 timesteps, but you can only get to 8 [0-7]. If you select the fluid1.e file, the Information tab has the correct steps. If you delete the first MaxTime in the file, (lines 18, 19 and 20) it works! stateMaxTimeBug-fixed-hack.pvsm shows this.

Linux, local server, 4.3.1. As I stated on the phone, this exodus file is created by reading an exodus dataset as it is being created, saving a state, letting the simulation continue writing the dataset, and using the state file. You can never go further in time than the original max time.
(0034351)
Utkarsh Ayachit (administrator)
2015-04-09 16:41

 Fix awaiting review:

https://gitlab.kitware.com/paraview/paraview/merge_requests/53 [^]
(0034356)
Utkarsh Ayachit (administrator)
2015-04-10 19:42

 Merged in master.
(0034383)
Alan Scott (manager)
2015-04-29 20:37

 Tested local server, master, Linux. Nice fix.

 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

Copyright © 2000 - 2018 MantisBT Team