Difference between revisions of "Animating Live Data"

From KitwarePublic
Jump to: navigation, search
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
The general idea of this feature is to have ParaView automatically update its visualization as new data becomes available.
 
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 ==
 
== Usage Scenarios ==
Line 15: 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 23: Line 29:
 
It might help if this feature is broken down into sub-features. Here are some possible items:
 
It might help if this feature is broken down into sub-features. Here are some possible items:
 
<ul>
 
<ul>
 +
<li>[[What to Do While Waiting]]
 
<li>[[Acquiring New Data]]
 
<li>[[Acquiring New Data]]
 
<li>[[What Is Updated]]
 
<li>[[What Is Updated]]
 
</ul>
 
</ul>
 
Please supply additional sub-features if needed.<br><br>
 
Please supply additional sub-features if needed.<br><br>
 +
 +
== Implementations ==
 +
 +
[[Livedata 0.001]]
  
  
Line 32: Line 43:
 
  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 13: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

Livedata 0.001


Kent Eschenberg   eschenbe@psc.edu
Pittsburgh Supercomputing Center
(This is an open forum so I am merely the first contributor)



ParaView: [Welcome | Site Map]