ParaView 3 Telecon 03-05-2009
Item | People | Description |
---|---|---|
1 | Ice | MARS/V&V Milestone issues |
2 | Moreland | Vis/Supercomputing Tutorials |
3 | Moreland | Sandia-Kitware Summit |
4 | Moreland | ParaView 3.6 Deliverables |
MARS
Lisa took her own notes.
Kitware Summit
Tutorials
Current plan for vis tutorial: Morning talks about customizing ParaView: scripting and plugins. Afternoon talks about selected advanced topics. Jim Ahrens already volunteered from last year. Anyone else? Anyone outside we should ask about?
- A what's new section.
- Charts
- Ahrens whatever.
- In-situ - Dave T., Nathan F.
- Statistics - Phillipe P.
- Send call out to paraview@paraview.org
I will again organize a ParaView tutorial for supercomputing. It will be very much like last years. Who volunteers for helping out (i.e. being helpers for attendees)?
Deliverables
ParaView/Titan Chart Merger (Pat/Utkarsh)
There are some minor issue to fix up. They will be the default soon.
Simplified Scripting (Berk/Utkarsh)
Berk not here to report.
Plots Along Curves (Berk)
Not started
VisIt AVT Integration (Burlen)
Working on building VisIt on windows. Have 83 readers available. Took 10 out because they are already available on ParaView.
Statistics (Phillipe)
Phillipe is not comfortable with running statistics on point data in parallel because points are replicated, and the replicated data can skew the statistics. As a compromise, we decided to only allow users to run statistics on cell data. Cell data is not replicated. If a user needs statistics on point data, they will have to explicitly convert them to cells, which signals a change in the data.
There is also an issue with accessing vectors in columns of tables. The design really assumes that each components is going to be in its own array. To make matters worse, the current implementation of getting a vtkVariant of a tuple is really slow. In the short term, we will continue to read tuples as vtkVariant. We should also look at that code and make it more efficient. In the long term, we are looking into implementing arrays that have different striding than that currently implemented in the vtkDataArray classes. When that is implemented, we can break up these vectors into separate arrays with shallow copies. (This would probably happen in the data-set-to-table filter.)