Difference between revisions of "Teleconference 2017-11-22"
(Created page with "Attendees: VTK-m/h integration. ECP/VTK-m multiblock milestone: push back? Make second part?") |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Attendees: | + | Attendees: Ken Moreland (SNL), Robert Maynard (Kitware), Berk Geveci (Kitware), Utkarsh Ayachit (Kitware), Sujin Philip (Kitware), Matt Larsen (LLNL), Dave Pugmire (ORNL), Cyrus Harrison (LLNL), Ollie Lo (LANL), Will Schroeder (Kitware), Abhishek Yenpure (UO), Tom Otahal (SNL), Hank Childs (OU) |
| − | VTK-m/h integration. | + | The majority of this meeting is about a VTK-m/h integration. That is, start integrating MPI functionality into VTK-m. |
| − | + | This requires merging the VTK-m and VTK-h multiblock structures. One structural change would be to have ways to query either local or global data ranges. | |
| + | |||
| + | In the current VTK-h implementation, a block can only be assigned to one task, so the VTK-m core data sets do not have to change. Just the multiblock class. | ||
| + | |||
| + | VTK-m needs to have a change in the execution infrastructure to iterate over blocks differently. Currently only iterate over block individually and independently. This needs to change to allow both those algorithms that can operate in this way but also allow tasks that require communication across blocks. This might be pushing requests down to the DIY layer, or it might be the filter programmer handling that itself if necessary. | ||
| + | |||
| + | Another (slightly longer term) goal is to allow multiple blocks to be scheduled concurrently on the same hardware. This can help when blocks are small with little work and you need multiple blocks running to fill the processing. It is currently possible to execute worklets from different threads without them stomping on each other. | ||
| + | |||
| + | Action items: wiring up VTK-h inside of the VTK-m repository. Kitware will take that on. | ||
| + | |||
| + | Should we have a shared-fate milestone between ECP VTK-m and ALPINE project? | ||
Latest revision as of 13:51, 22 November 2017
Attendees: Ken Moreland (SNL), Robert Maynard (Kitware), Berk Geveci (Kitware), Utkarsh Ayachit (Kitware), Sujin Philip (Kitware), Matt Larsen (LLNL), Dave Pugmire (ORNL), Cyrus Harrison (LLNL), Ollie Lo (LANL), Will Schroeder (Kitware), Abhishek Yenpure (UO), Tom Otahal (SNL), Hank Childs (OU)
The majority of this meeting is about a VTK-m/h integration. That is, start integrating MPI functionality into VTK-m.
This requires merging the VTK-m and VTK-h multiblock structures. One structural change would be to have ways to query either local or global data ranges.
In the current VTK-h implementation, a block can only be assigned to one task, so the VTK-m core data sets do not have to change. Just the multiblock class.
VTK-m needs to have a change in the execution infrastructure to iterate over blocks differently. Currently only iterate over block individually and independently. This needs to change to allow both those algorithms that can operate in this way but also allow tasks that require communication across blocks. This might be pushing requests down to the DIY layer, or it might be the filter programmer handling that itself if necessary.
Another (slightly longer term) goal is to allow multiple blocks to be scheduled concurrently on the same hardware. This can help when blocks are small with little work and you need multiple blocks running to fill the processing. It is currently possible to execute worklets from different threads without them stomping on each other.
Action items: wiring up VTK-h inside of the VTK-m repository. Kitware will take that on.
Should we have a shared-fate milestone between ECP VTK-m and ALPINE project?
