ParaView 3 Telecon 02-05-2009: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
(New page: {| cellpadding="2" cellspacing="4" |- ! style="background:#abcdef" | Item ! style="background:#abcdef" | People ! style="background:#abcdef" | Description |- | 1 || Ice || MARS/V&V Milesto...)
 
No edit summary
 
Line 1: Line 1:
{| cellpadding="2" cellspacing="4"
== Statistics ==
|-
! style="background:#abcdef" | Item
! style="background:#abcdef" | People
! style="background:#abcdef" | Description
|-
| 1 || Ice || MARS/V&V Milestone issues
|-
| 2 || Moreland || [[ParaView 3.6 Deliverables]]
|}


== MARS ==
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.)
== Deliverables ==
 
=== ParaView/Titan Chart Merger (Pat/Utkarsh) ===
 
Starting work on options dialog.  After that, start trying it out.
 
Dave Thompson has list of features he would like to see for the dialog.
 
=== Simplified Scripting (Berk/Utkarsh) ===
 
Looking at replacing array calculator with python-based calculator.  Made some good progress.  Does everything current calculator but also a lot more.  Berk has 10-line calculator to do gradients.
 
There is a deployment issue in that right now this code depends on NumPy and MPI wrappings.  To get around the MPI wrappings, we should work on getting vtkMultiProcessController properly wrapped.
 
To handle the finding/loading of these python modules, we should modify the CMake files to look for these things and warn if they are not there (identifying what features will be missing).  The user can then install them and run CMake again to add them in.
 
Upcoming are some changes to allow you to references input properties without dereferencing output ports.  There will also be improvements with proxy properties that have list domains.
 
=== Temporal Cleanup (Berk) ===
 
* Show temporal bounds of all datasets in statistics view (or elsewhere)
* Show continuous data set temporal bounds in info page
* Plot/Probe over time, results should very in Sequence, Snap, and Real Time modes
 
Not started yet.  John Biddiscombe has been looking at it.
 
=== Plots Along Curves (Berk) ===
 
Not started
 
=== VisIt AVT Integration (Burlen) ===
 
Getting material stuff working.  Parallel is now working for databases that provide multiple domains.  If fewer domains than processors, some will be empty.
 
Working on AMR.
 
=== Statistics (Phillipe) ===
 
Some backpedaling here.  The statistics filters may not be ready because (1) there needs to be a mechanism to take a data object rather than a table (auto conversion) and (2) there needs to be some further changes to handle multicomponent arrays correctly.
 
=== Particle Support (Zhanping/John Biddiscombe) ===
 
* Provide a particle representation that renders points more intelligently
** Spheres with size vs. squares of pixel width
** Optional sizing based on a scalar
** Appropriate alpha blending (at least when particles are small)
** Splatting?
* Filters for meshless data? (Need to get customer requirements.)
** Sampling point cloud?
** Surface extraction?
 
Not started yet.

Latest revision as of 13:46, 5 February 2009

Statistics

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.)

Retrieved from "http://www.paraview.org/ParaView/index.php?title=ParaView_3_Telecon_02-05-2009&oldid=6122"