Teleconference 2015-05-08

Jump to: navigation, search

Attendees: Ken Moreland (SNL), Rob Maynard (Kitware), James Kress (OU), Chris Sewell (LANL), Jeremy Meredith (ORNL)

Currently the implementation of the data model is on the critical path for students of the Google Summer of Code. These students are expected to complete their project by the end of July and are now gearing up to get started. Those working on VTK-m will need the data model in place to make significant progress. According to Jeremy the data model implementation is well underway. We could be ready for an informal code review. Also, Rob has some time available in the short term to work on the data model. To jump start this, there will be a discussion next Tuesday.

At DOECGF Jim Jeffers from Intel expressed interest in meeting with the VTK-m developers to help improve the implementation for Intel processors (in particular, Xeon Phi). Ken volunteered to contact Jim to start to plan when this could take place and what the format should be. Overall, the format used for NVIDIA worked well enough: the first half a day was an overview of the mechanics of VTK-m, the second half day was the vendor's engineers responding with advice for our development and some hints on what to expect in future years. One particular aspect we want to stress is that we are not interested in a sales pitch. Our team is already committed to supporting the hardware that is being installed on ASCR and ASC machines. What we really want is deep technical engineers (with probably at least one outside of the visualization team) that can help us with hardware and software. One topic that is particularly important to the developers is vectorization.

Chris is bringing in a student this summer who will be funded under ASC. The student will probably help get algorithms to run well on Trinity (i.e. Xeon Phi).

Chris has been working with Hamish Carr on building contour trees in parallel, and Pat Fasel has been working on standard filtering algorithms.

In the near term, Chris plans to spend some time defining what a "pipeline" is in VTK-m. What followed was a long discussion of pipelines in VTK-m (most of which I did not capture). One salient point is whether VTK-m will have its own pipeline or whether it will rely on VTK and AVT to implement their pipeline. In either case, VTK-m must play well within these pipelines. The design may be to look into the previous work of incorporating PISTON and Dax into VTK and Eric Brugger's VisIt integration.

Recently Ken and Rob checked in some new fancy array handles (specifically implicit, transform, permutation, and zip). They are being tested across different devices.