Animating Live Data: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 19: | Line 19: | ||
<li>A file could instead be a set of files such as is produced by a parallel application. PV should not update until all files in the set are present. | <li>A file could instead be a set of files such as is produced by a parallel application. PV should not update until all files in the set are present. | ||
<li>Should there be support for the new data being in the same file as the old? That seems dangerous, if PV and the source get out of sync, but maybe its useful in some cases. | <li>Should there be support for the new data being in the same file as the old? That seems dangerous, if PV and the source get out of sync, but maybe its useful in some cases. | ||
<li>I see several cases where the new data is appended to the same file as the old. This doesn't have the sync problem that overwriting the data has, but it does require checking the file for a new EOF position or change in size. | |||
<li>The new data is appended (same as above) but a set of parallel files. PV should not update until all files in the set have been appended. | |||
</ul> | </ul> | ||
Please supply additional use cases if the above doesn't cover yours. If you add a **long** description please make your entry here a link to a new page where you can provide as much detail as desired. | Please supply additional use cases if the above doesn't cover yours. If you add a **long** description please make your entry here a link to a new page where you can provide as much detail as desired. | ||
| Line 33: | Line 35: | ||
Please supply additional sub-features if needed.<br><br> | Please supply additional sub-features if needed.<br><br> | ||
== | == Implementations == | ||
[[Livedata 0.001]] | |||
Kent Eschenberg eschenbe@psc.edu | Kent Eschenberg eschenbe@psc.edu | ||
Pittsburgh Supercomputing Center | Pittsburgh Supercomputing Center | ||
(This is an open forum so I am merely the first contributor) | (This is an open forum so I am merely the first contributor) | ||
{{ParaView/Template/Footer}} | |||
Latest revision as of 17:53, 2 February 2007
The general idea of this feature is to have ParaView automatically update its visualization as new data becomes available.
The feature is not yet a part of ParaView but is being developed. The purpose of this Wiki section is to collect and develop ideas from the user's point of view.
We don't want to get into those implementation details best left to Kitware. We might need to get into details where the new feature interfaces with user-written code such as a simulation.
Usage Scenarios
It will help if we clarify the way this feature would be used.
- A simulation produces transient (time varying) data where each time step is written to a different file.
- A simulation refines its result where each refinement is written to a different file.
- A data acquision system recording transient data writes each new set of measurements to a different file.
- Greg's Case
- Kent's Case
Variations:
- A file could instead be a set of files such as is produced by a parallel application. PV should not update until all files in the set are present.
- Should there be support for the new data being in the same file as the old? That seems dangerous, if PV and the source get out of sync, but maybe its useful in some cases.
- I see several cases where the new data is appended to the same file as the old. This doesn't have the sync problem that overwriting the data has, but it does require checking the file for a new EOF position or change in size.
- The new data is appended (same as above) but a set of parallel files. PV should not update until all files in the set have been appended.
Please supply additional use cases if the above doesn't cover yours. If you add a **long** description please make your entry here a link to a new page where you can provide as much detail as desired.
Sub Features
It might help if this feature is broken down into sub-features. Here are some possible items:
Please supply additional sub-features if needed.
Implementations
Kent Eschenberg eschenbe@psc.edu Pittsburgh Supercomputing Center (This is an open forum so I am merely the first contributor)
