XVis Kickoff Meeting 2014-11-17: Difference between revisions
No edit summary |
No edit summary |
||
| Line 141: | Line 141: | ||
| | | | ||
| Breakout Sessions? | | Breakout Sessions? | ||
|} | |||
== Notes == | |||
=== VTK-m === | |||
One of the discussions that came up during the talk about EAVL is the use of VTK-m for self contained in situ visualization. EAVL is completely self contained with complete implementations of CUDA and multi-core algorithms, font embedding, and rendering. EAVL can be built with no dependencies making it easy to integrate with other packages such as Boost or Thrust. How far should we go with this concept in VTK-m? Can we bring in third party libraries? Can we have optional dependencies? | |||
The basic iterator/functor idea for algorithm implementation is common across EAVL, PISTON, and Dax. What VTK-m should provide on top of this is performance across all data types. Implementing an algorithm on a regular grid might be straightforward, but how well will that algorithm perform on unstructured, higher order, hierarchical, or multi-dimensional data? VTK-m should also provide search structures. Should that be part of the data types? | |||
Some discussion was given to task parallelism. Should VTK-m find independent operations in a sequence of operations? Should that be a layer on VTK-m? Is that important enough to implement? (Perhaps tasks can be created in more obvious and effective ways in practice, such as through blocks or other coarse data partitions.) | |||
How much does VTK-m need to worry about distributed parallelism? At a minimum it needs to be aware of and support ghost elements. Support beyond that is likely unneeded but can be investigated. | |||
[[ | Another important point for VTK-m to succeed is that we need to implement a large enough set of algorithms that makes VTK-m useful to simply take an apply to scientific visualization. Some time was taken to brainstorm on a top 10 common [[missing algorithms]] list that we should implement, which quickly grew to more than 10 elements. | ||
Revision as of 16:17, 25 November 2014
Monday, November 17, 2014
ILE France III boardroom, JW Marriott
614 Canal St., New Orleans 70130
| 8:45 | Gather and Introduction | |
|---|---|---|
| 9:00 | Emerging Architectures | |
| Existing codes | ||
| What should go into VTK-m, what they want from VTK-m, Possible integration issues. | ||
| PISTON 15 minutes | Chris Sewell | |
| EAVL 15 minutes | Jeremy Meredith | |
| Dax 15 minutes | Robert Maynard | |
| VTK-m Logistics 15 minutes | Kenneth Moreland | |
| Discussion and Milestones 30 minutes | ||
| 1.a Initial VTK-m Design (SNL, Kitware, ORNL, LANL) | ||
| 10:30 | In Situ | |
| Flyweight In Situ 15 minutes | Berk Geveci | |
| Flexible Data Models 15 minutes | Jeremy Meredith | |
| Early Career Project 30 minutes | Hank Childs | |
| What it provides. What XVis can provide. | ||
| Discussion and Milestones 30 minutes | ||
| 2.a Expand Data Models (ORNL, Kitware) | ||
| 2.b Post Hoc Interaction (Oregon) | ||
| 12:00 | Lunch | |
| 1:30 | User Studies | |
| Overview of Visualization User Studies 30 minutes | Kwan-Liu Ma | |
| Science behind user studies | ||
| Logistics (DOE requirements, getting/handling subjects, cost) | ||
| Discussion and Milestones 30 minutes | ||
| 3.a Develop Techniques to be Studied (Davis) | ||
| 2:30 | Proxy Applications | |
| Mini-apps 30 minutes | Michael Heroux | |
| Brief overview of Mantevo | ||
| Requirements of mini-apps | ||
| Difference between mini-apps and proxy apps | ||
| What should a vis mini-app look like? | ||
| Empirically Testing Scientific Apps 30 minutes | Jeremy Meredith | |
| Brief overview of Oxbow | ||
| Plans for vis | ||
| Discussion and Milestones 30 minutes | ||
| 4.a Initial Mini-App Implementation (Sandia, ORNL) | ||
| 4:00 | General Discussions | |
| Differentiating XVis from SDAV 15 minutes | ||
| XVis and VTK-m Logos 15 minutes | ||
| Breakout Sessions? |
Notes
VTK-m
One of the discussions that came up during the talk about EAVL is the use of VTK-m for self contained in situ visualization. EAVL is completely self contained with complete implementations of CUDA and multi-core algorithms, font embedding, and rendering. EAVL can be built with no dependencies making it easy to integrate with other packages such as Boost or Thrust. How far should we go with this concept in VTK-m? Can we bring in third party libraries? Can we have optional dependencies?
The basic iterator/functor idea for algorithm implementation is common across EAVL, PISTON, and Dax. What VTK-m should provide on top of this is performance across all data types. Implementing an algorithm on a regular grid might be straightforward, but how well will that algorithm perform on unstructured, higher order, hierarchical, or multi-dimensional data? VTK-m should also provide search structures. Should that be part of the data types?
Some discussion was given to task parallelism. Should VTK-m find independent operations in a sequence of operations? Should that be a layer on VTK-m? Is that important enough to implement? (Perhaps tasks can be created in more obvious and effective ways in practice, such as through blocks or other coarse data partitions.)
How much does VTK-m need to worry about distributed parallelism? At a minimum it needs to be aware of and support ghost elements. Support beyond that is likely unneeded but can be investigated.
Another important point for VTK-m to succeed is that we need to implement a large enough set of algorithms that makes VTK-m useful to simply take an apply to scientific visualization. Some time was taken to brainstorm on a top 10 common missing algorithms list that we should implement, which quickly grew to more than 10 elements.