Sandia-Kitware-ETI Summit, Nov. 29-30, 2006
| Time | Length | Item | Who | Slides |
|---|---|---|---|---|
| 8:30 | 0.5 hr | Coffee and knock-knock jokes | All | |
| 9:00 | 1 hr | ParaView 2.6 | Geveci | |
| 10:00 | 1.5 hr | Software Methodology
|
Greenfield | Original Methodology update |
| 11:30 | 1.5 hr | Lunch | All | |
| 1:00 | 1 hr | ParaView 3 Deployment | Scott | |
| 2:00 | 3 hr | GUI Choices
|
Greenfield | GUI choices |
| Time | Length | Item | Who | Slides |
|---|---|---|---|---|
| 8:30 | 0.5 hr | Coffee and knock-knock jokes | All | |
| 9:00 | 1 hr | ParaView 3 Selection | Geveci | |
| 10:00 | 1 hr | ParaView 3 Time Support | Geveci | |
| 11:00 | 0.5 hr | ParaView Plugins | Moreland | |
| 11:30 | 1.5 hr | Lunch | All | |
| 1:00 | 1 hr | V&V Milestone | Karelitz | |
| 2:00 | 0.5 hr | DSTK Functionality: Python Scripting | Greenfield | Scripting |
| 2:30 | 1 hr | DSTK Functionality: Subsetting/Math | Greenfield | |
| 3:30 | 1.5 hr | ThreatView/Titan | Wilson/Shead |
| Time | Length | Item | Who | Slides |
|---|---|---|---|---|
| 8:30 | 0.5 hr | Coffee and knock-knock jokes | All | |
| 9:00 | 1.5 hr | ThreatView/Titan (cont.) | Wilson/Shead | |
| 10:30 | 0.5 hr | Wrap-up | All | |
| 11:00 | Airport Dash | Sandia |
Notes
Software Methodology
Recently, we have been particularly bad with documenting what we intend to do for a monthly build and then document what was actually done. To get better at this, we are building a list of deliverables, prioritizing, and determining a timeline for them. Berk is capturing them in an application he has on his laptop. After the meeting, we will build Wiki pages capturing these deliverables and thier schedule as well as tracking which bugs pertain to which deliverables.
Time Support
Current implementation in ParaView 2: Readers have input properties that give the time range and output properties that set the desired time.
Recently, Kitware has implemented better time support in the VTK pipeline. At the bottom of the pipeline, a desired time value (or range) is selected. That value gets sent up the pipeline to be provided by readers (or perhaps filters). If multiple time steps are requested, a reader will generate a multiblock data set, with entries for all the requested time steps. This allows for things like interpolation between time steps and particle tracking in fluids.
How do we request time from a reader in the interface? We have a request for a "global" time step. A problematic use case is loading multiple data sets with differing time steps. Tim's idea for that is to have a special filter that either shifts/scales or sets the time.
It is also generally agreed that there has to be a time value per view. By default, the time values are locked, but there is an option to unlock the time value.
The implementation will have a time associated with each view. That time will be given to each display, which will in turn send the time value up the pipeline.
Another counter-intuitive use case. Given an input with non-constant time steps, the user still wants an animation that shows each time step in sequence.
