XVis Kickoff Meeting 2014-11-17: Difference between revisions

From XVis
Jump to navigation Jump to search
No edit summary
No edit summary
 
(11 intermediate revisions by 2 users not shown)
Line 2: Line 2:
ILE France III boardroom, JW Marriott<br/>
ILE France III boardroom, JW Marriott<br/>
614 Canal St., New Orleans 70130
614 Canal St., New Orleans 70130
<span style="color:red">Note that the times in the agenda are likely to be moved around to accommodate everyone's schedule and conflicts. Let me know if you have any requirements or desires.</span>


{| cellpadding="2" cellspacing="0"
{| cellpadding="2" cellspacing="0"
Line 22: Line 20:
|-
|-
|
|
| &nbsp;&nbsp;&nbsp; PISTON <span style="font-size:smaller; color:gray">15 minutes</span>
| &nbsp;&nbsp;&nbsp; [[Media:XVisKickOffMeetingLANLPresentation.pdf|PISTON]] <span style="font-size:smaller; color:gray">15 minutes</span>
| Chris Sewell
| Chris Sewell
|-
|-
Line 34: Line 32:
|-
|-
|
|
| VTK-m Logistics <span style="font-size:smaller; color:gray">15 minutes</span>
| [[media:XVisKickoffVTKmLogistics.pptx|VTK-m Logistics]] <span style="font-size:smaller; color:gray">15 minutes</span>
| Kenneth Moreland
| Kenneth Moreland
|- style="font-size:smaller"
|-
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What we have, what is planned, what we need.
| &nbsp;&nbsp;&nbsp; [[Missing algorithms]]
|-
|-
|
|
Line 47: Line 45:
|- style="background:#abcdef"
|- style="background:#abcdef"
! align="right" | 10:30
! align="right" | 10:30
! User Studies
! In Situ
!
!
|-
|-
|
|
| Overview of Visualization User Studies <span style="font-size:smaller; color:gray">30 minutes</span>
| Flyweight In Situ <span style="font-size:smaller; color:gray">15 minutes</span>
| Kwan-Liu Ma
| Berk Geveci
|- style="font-size:smaller"
|-
|
| Flexible Data Models <span style="font-size:smaller; color:gray">15 minutes</span>
| Jeremy Meredith
|-
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Science behind user studies
| [[media:hank_kickoff_slides.pdf|Early Career Project]] <span style="font-size:smaller; color:gray">30 minutes</span>
| Hank Childs
|- style="font-size:smaller"
|- style="font-size:smaller"
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Logistics (DOE requirements, getting/handling subjects, cost)
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What it provides. What XVis can provide.
|-
|-
|
|
Line 64: Line 67:
|- style="font-size:smaller"
|- style="font-size:smaller"
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.a Develop Techniques to be Studied (Davis)
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.a Expand Data Models (ORNL, Kitware)
|- style="font-size:smaller"
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.b Post Hoc Interaction (Oregon)
|- style="background:#abcdef"
|- style="background:#abcdef"
! style="border-bottom: 2px solid white" align="right" | 11:30
! style="border-bottom: 2px solid white" align="right" | 12:00
! style="border-bottom: 2px solid white" |  Lunch
! style="border-bottom: 2px solid white" |  Lunch
! style="border-bottom: 2px solid white" |
! style="border-bottom: 2px solid white" |
|- style="background:#abcdef"
|- style="background:#abcdef"
! align="right" | 1:00
! align="right" | 1:30
! In Situ
! User Studies
!
!
|-
|-
|
|
| Flyweight In Situ <span style="font-size:smaller; color:gray">15 minutes</span>
| Overview of Visualization User Studies <span style="font-size:smaller; color:gray">30 minutes</span>
| Berk Geveci
| Kwan-Liu Ma
|-
|- style="font-size:smaller"
|
|
| Flexible Data Models <span style="font-size:smaller; color:gray">15 minutes</span>
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Science behind user studies
| Jeremy Meredith
|-
|
| Early Career Project <span style="font-size:smaller; color:gray">30 minutes</span>
| Hank Childs
|- style="font-size:smaller"
|- style="font-size:smaller"
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What it provides. What XVis can provide.
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Logistics (DOE requirements, getting/handling subjects, cost)
|-
|-
|
|
Line 93: Line 94:
|- style="font-size:smaller"
|- style="font-size:smaller"
|
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.a Expand Data Models (ORNL, Kitware)
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3.a Develop Techniques to be Studied (Davis)
|- style="font-size:smaller"
|
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2.b Post Hoc Interaction (Oregon)
|- style="background:#abcdef"
|- style="background:#abcdef"
! align="right" | 2:30
! align="right" | 2:30
Line 103: Line 101:
|-
|-
|
|
| Mini-apps <span style="font-size:smaller; color:gray">30 minutes</span>
| [[Media:HerouxHowtoMakeAMiniapp.pptx|Mini-apps]] <span style="font-size:smaller; color:gray">30 minutes</span>
| Michael Heroux
| Michael Heroux
|- style="font-size:smaller"
|- style="font-size:smaller"
Line 134: Line 132:
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.a Initial Mini-App Implementation (Sandia, ORNL)
| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4.a Initial Mini-App Implementation (Sandia, ORNL)
|- style="background:#abcdef"
|- style="background:#abcdef"
! align="right" | 5:00
! align="right" | 4:00
! General Discussions
! General Discussions
!
!
Line 143: Line 141:
|
|
| XVis and VTK-m Logos <span style="font-size:smaller; color:gray">15 minutes</span>
| XVis and VTK-m Logos <span style="font-size:smaller; color:gray">15 minutes</span>
|-
|
| 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.)
Streaming and distributed processing are important use cases for VTK-m. Streaming will likely take some thought and design. 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.
=== User Studies ===
The studies Kwan-Liu intends to do a primarily qualitative user studies in which collaborators in other science projects evaluate different in situ techniques (e.g. standard rendering vs. explorable images). The challenge with this type of study is in demonstrating the value of the results. This is important both in terms of publishing and reporting back to ASCR. Hank is also considering more quantitative studies in which groups of subjects are measured performing particular tasks.
There was some brief discussion about getting IRB approval. Considering the nature of the study, IRB approval should be a straightforward formality. There was also the suggestion that the more qualitative studies might be exempt from having IRB approval since no formal measurements are taken, but given the nature of the proposed work, our program manager will likely be expecting an IRB review to happen.
=== Mini-apps ===
Mike's slides capture well the process of building mini-apps.
One side conversation that happened during this time was a discussion on creating task-centric dataflow networks. It can be the case that our parallel algorithms logically overdecompose the data. This can be particularly problematic for vector instructions that require multiple data elements to stay full. It is good to implement algorithms as asynchronous task launches. This maps well to mluticore architectures as well as mapping well to heterogeneous and multi-GPU architectures.
=== Differentiating XVis from SDAV ===
For the most part, XVis and SDAV are significantly different projects, but there is overlap in the VTK-m software. We need to clearly demarcate what types of work we do with each project and be careful not to double report the same work to the two projects.
The following types of work falls under the XVis project:
* Infrastructure
* Research
* Filters
These types of work fall under the SDAV project:
* Integration
* Collaboration
* Filters
Note that filters can fall under either project. Which one that is depends on the nature of the filter and the reason it is created. A filter that is part of the core research or infrastructure should be part of XVis. However, a filter to support a collaboration should be part of SDAV.

Latest revision as of 17:49, 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
    Missing algorithms
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.)

Streaming and distributed processing are important use cases for VTK-m. Streaming will likely take some thought and design. 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.

User Studies

The studies Kwan-Liu intends to do a primarily qualitative user studies in which collaborators in other science projects evaluate different in situ techniques (e.g. standard rendering vs. explorable images). The challenge with this type of study is in demonstrating the value of the results. This is important both in terms of publishing and reporting back to ASCR. Hank is also considering more quantitative studies in which groups of subjects are measured performing particular tasks.

There was some brief discussion about getting IRB approval. Considering the nature of the study, IRB approval should be a straightforward formality. There was also the suggestion that the more qualitative studies might be exempt from having IRB approval since no formal measurements are taken, but given the nature of the proposed work, our program manager will likely be expecting an IRB review to happen.

Mini-apps

Mike's slides capture well the process of building mini-apps.

One side conversation that happened during this time was a discussion on creating task-centric dataflow networks. It can be the case that our parallel algorithms logically overdecompose the data. This can be particularly problematic for vector instructions that require multiple data elements to stay full. It is good to implement algorithms as asynchronous task launches. This maps well to mluticore architectures as well as mapping well to heterogeneous and multi-GPU architectures.

Differentiating XVis from SDAV

For the most part, XVis and SDAV are significantly different projects, but there is overlap in the VTK-m software. We need to clearly demarcate what types of work we do with each project and be careful not to double report the same work to the two projects.

The following types of work falls under the XVis project:

  • Infrastructure
  • Research
  • Filters

These types of work fall under the SDAV project:

  • Integration
  • Collaboration
  • Filters

Note that filters can fall under either project. Which one that is depends on the nature of the filter and the reason it is created. A filter that is part of the core research or infrastructure should be part of XVis. However, a filter to support a collaboration should be part of SDAV.