ParaView 3 Telecon 09-24-2009: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
No edit summary
Line 14: Line 14:
| 4 || Ayachit || Partial Arrays with Plot Over Line ([http://www.paraview.org/Bug/view.php?id=9252 Bug #9252])
| 4 || Ayachit || Partial Arrays with Plot Over Line ([http://www.paraview.org/Bug/view.php?id=9252 Bug #9252])
|-
|-
| 5 || Moreland || Time pipeline changes owner
| 5 || Ayachit || Fast online help updates (relates to [http://www.paraview.org/Bug/view.php?id=8923 Bug #8923])
|-
|-
| 6 || Moreland || Python shell overloaded?
| 6 || Moreland || Time pipeline changes owner
|-
|-
| 7 || Moreland || PV scalar bar to VTK?
| 7 || Moreland || Python shell overloaded?
|-
| 8 || Moreland || PV scalar bar to VTK?
|}
|}



Revision as of 11:33, 23 September 2009

Item People Description
1 Ice MARS/V&V Milestone issues
2 Moreland Stronger Dashboard
  • Boiling the frog coverage
3 Thompson Statistics Update
4 Ayachit Partial Arrays with Plot Over Line (Bug #9252)
5 Ayachit Fast online help updates (relates to Bug #8923)
6 Moreland Time pipeline changes owner
7 Moreland Python shell overloaded?
8 Moreland PV scalar bar to VTK?

MARS Milestone

Previously:

Nathan talked to Karen Devine for suggestions. She suggested using a "data dictionary" to resolve fragments. You do two all-to-all broadcasts to choose which id to assign to each fragment.

Berk reports that the biggest bottleneck to scaling is the exchange of ghost cell information. One approach would be to not do ghost cells and do fragment resolution later. The down side is that interfaces become non-watertight. We should at least try approaches that do no communication (such as CTH parts) to at least demonstrate the scalability.

Another possibility is to try to leverage the ghost levels provided by CTH.

This Week:

Stronger Dashboard

Previously:

Dave P. is now monitoring the dashboard.

Utkarsh is still going to think about how to run more tests faster.

In Utkarsh's branding branch, allows you to run multiple tests in one invocation and have each have their own result images. Between tests, the GUI resets but the connection remains. You can also isolate tests that could effect others (like the color palette tests).

Might be committing the branding stuff next week.

This Week:

Statistics Update

Previously:

  • Initial implementation complete.
  • Should there be a "no second input" version of each filter? no, use Hints
  • Approaches for handling shared points in distributed-memory mode?
  • How to create tests for plugins? turn it into not-a-plugin
  • If/when to merge into 3.6 branch? send patch to Utkarsh
  • Semi-offtopic: "Root" of multiblock of tables appears to be mashed version of first table?
  • Semi-offtopic: Possible to include HTML/images in online docs?

This week:

  • Moved out of plugin directory (no tests yet)
  • Hints added to avoid Input Selector pop-up
  • Patch for 3.6.2 sent to Utkarsh
  • Avoiding skew in distributed-memory mode: there are 2 cases to handle (but not for 3.6.2)
    • Unstructured: if data has point GLOBAL_ID attribute, might not be too hard to compute a list of ranges of IDs present on each process, do an AllGather, and then have each process determine which IDs it owns (using a lowest-rank tie-breaker rule). When the D3 filter assigns global IDs, it gives each process a contiguous range of IDs so the list of ranges should be small (on the size of the number of boundaries with other processes, not the size of the mesh "interior" to each process).
    • Structured: This is simple using a lowest-rank tie-breaker rule.