ParaView 3 Telecon 09-24-2009: Difference between revisions
Line 64: | Line 64: | ||
* Hints added to avoid Input Selector pop-up | * Hints added to avoid Input Selector pop-up | ||
* Patch for 3.6.2 sent to Utkarsh | * 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. |
Revision as of 22:08, 18 September 2009
Item | People | Description |
---|---|---|
1 | Ice | MARS/V&V Milestone issues |
2 | Moreland | Stronger Dashboard
|
3 | Thompson | Statistics Update |
4 | Ayachit | Partial Arrays with Plot Over Line (Bug #9252) |
5 | Moreland | Time pipeline changes owner |
6 | Moreland | Python shell overloaded? |
7 | 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.