MantisBT - ParaView
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006067ParaView(No Category)public2007-11-19 18:342008-03-07 07:56
ReporterDavid Karelitz 
Assigned ToDavid Karelitz 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Project
Topic Name
Type
Summary0006067: (MARS-high) Save and disconnect results in repeat geometry
DescriptionWhen saving and disconnecting with AMRCTH data, the geometry appears to be duplicated from one timestep to another. The time value label updates, but the geometry might repeat for 2 or 3 timesteps before new geometry is shown.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2007-11-19 18:34David KarelitzNew Issue
2008-01-03 10:20David KarelitzNote Added: 0010056
2008-01-03 15:16David KarelitzStatusbacklog => @80@
2008-01-03 15:16David KarelitzResolutionopen => fixed
2008-01-03 15:16David KarelitzAssigned To => David Karelitz
2008-01-03 15:16David KarelitzNote Added: 0010057
2008-01-23 17:00Alan ScottStatus@80@ => closed
2008-01-23 17:00Alan ScottNote Added: 0010271
2008-01-24 16:53Alan ScottNote Added: 0010294
2008-01-24 16:53Alan ScottStatusclosed => tabled
2008-01-28 10:32David KarelitzStatustabled => closed
2008-01-28 10:32David KarelitzNote Added: 0010305
2008-03-07 07:56Berk GeveciTarget Version => MARS
2011-06-16 13:10Zack GalbreathCategory => (No Category)

Notes
(0010056)
David Karelitz   
2008-01-03 10:20   
This happens with Exodus data as well.

When saving an animation using the GUI or through pvbatch, 3D geometry is not always from the correct timestep. If I open can.exo (which I believe Kitware has), add a time annotator, and save the animation, I get a the correct number of frames (one per timestep). The timestamp on each frame is correct, but the geometry is not correct. It is often duplicated from the previous frame. Out of 43 frames, there are only 33 different geometries.

If I load the state into the GUI, I see the same timestep discrepancies that I saw in the animation images. If I then open can.exo (with the version from the state file still there), the timesteps are still wrong. If I delete everything and open can.exo, the timesteps are correct.
(0010057)
David Karelitz   
2008-01-03 15:16   
This turned out to be a problem due to the precision of the time values saved in pvsm files versus the precision used in the readers. It was fixed for Exodus and CTH by modifying the reader to snap to the nearest timestep versus the first timestep larger than the requested value.
(0010271)
Alan Scott   
2008-01-23 17:00   
Tested client/server - using can.exo
(0010294)
Alan Scott   
2008-01-24 16:53   
As per Dave, there are cases with some data and some clusters that this bug still occurs. Not to be closed until Dave says it is OK.
(0010305)
David Karelitz   
2008-01-28 10:32   
Misunderstanding between myself and Alan as to which bug should remain open