| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0006067 | ParaView | (No Category) | public | 2007-11-19 18:34 | 2008-03-07 07:56 | ||||
| Reporter | David Karelitz | ||||||||
| Assigned To | David Karelitz | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0006067: (MARS-high) Save and disconnect results in repeat geometry | ||||||||
| Description | When 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Project | |||||||||
| Topic Name | |||||||||
| Type | |||||||||
| Attached Files | |||||||||
| Relationships | |
| Relationships |
| Notes | |
|
(0010056) David Karelitz (reporter) 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 (reporter) 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 (manager) 2008-01-23 17:00 |
Tested client/server - using can.exo |
|
(0010294) Alan Scott (manager) 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 (reporter) 2008-01-28 10:32 |
Misunderstanding between myself and Alan as to which bug should remain open |
| Notes |
| Issue History | |||
| Date Modified | Username | Field | Change |
| 2007-11-19 18:34 | David Karelitz | New Issue | |
| 2008-01-03 10:20 | David Karelitz | Note Added: 0010056 | |
| 2008-01-03 15:16 | David Karelitz | Status | backlog => @80@ |
| 2008-01-03 15:16 | David Karelitz | Resolution | open => fixed |
| 2008-01-03 15:16 | David Karelitz | Assigned To | => David Karelitz |
| 2008-01-03 15:16 | David Karelitz | Note Added: 0010057 | |
| 2008-01-23 17:00 | Alan Scott | Status | @80@ => closed |
| 2008-01-23 17:00 | Alan Scott | Note Added: 0010271 | |
| 2008-01-24 16:53 | Alan Scott | Note Added: 0010294 | |
| 2008-01-24 16:53 | Alan Scott | Status | closed => tabled |
| 2008-01-28 10:32 | David Karelitz | Status | tabled => closed |
| 2008-01-28 10:32 | David Karelitz | Note Added: 0010305 | |
| 2008-03-07 07:56 | Berk Geveci | Target Version | => MARS |
| 2011-06-16 13:10 | Zack Galbreath | Category | => (No Category) |
| Issue History |
| Copyright © 2000 - 2018 MantisBT Team |