Attendees: Dave Pugmire (ORNL), Jeremy Meredith (ORNL), Berk Geveci (Kitware), Matt Larsen (LLNL), Chris Sewell (LANL)
Distributed Memory Investigation
Right now primarily interested in Legion integration. LANL is going to pursue that. There is already a Thrust-Legion example, which suggests that there is a good chance of doing something successful.
From Rob Maynard: Chuck Atkins is going to start managing the dashboards for the project this month, so we should see an increase in stability once the transition is complete.
We need to do a DOE copyright assertion for the V1.0 release of VTK-m. To do this, we need a list of people who have contributed to VTK-m to sign off on it. Berk has volunteered to get someone to go through the git repository for all commits since February 2015 and see who has committed anything.
Point coordinates for rectilinear grids
Dave Pugmire is working on various data set builders. For the rectilinear grid data set builder, he needs to use a special array called ArrayHandleCartesianProduct to represent the point coordinates. This array can be added to the dynamic array handle just fine, but once it is there worklet operations on the array cannot cast it back to the appropriate type. The solution is simple enough: add this array's storage type to the list of storage objects used in DynamicArrayHandleCoordinateSystem. The downside to doing this is that every invocation of a worklet using a coordinate system will add a code path for this type whether it is used or not.
The solution we came to was to add ArrayHandleCartesianProduct as one of the default storage types for coordinate systems, but only for a single floating point type (specifically vtkm::FloatDefault). The DataSetBuilderRectilinear will have to convert incoming arrays to arrays of that type if necessary.
Version 1.0 ToDo List
We went over the Version 1.0 ToDo List. Here is a snapshot of the current list of tasks.
|Settling of the core interface||Rob working on interface for finding what device adapters are available at runtime. Probably will move device adapter traits outside of internal.|
|Standardization of "filters"
||Rob is going to work on this. Originally the design was to compile filters into libraries, but the latest design is using a header-based approach. The current status is at https://gitlab.kitware.com/robertmaynard/vtk-m/tree/vtkm_filters.|
|Support worklet operations that are not one-to-one output||Done|
|Basic file I/O||Done. Except Matt has been having trouble loading in VTK files. He has had to modify the files to get them to work. Action item: Matt needs to send an example file that does not work to the Kitware folks to take a look.|
|Basic rendering||Not started yet. There is a Rendering Infrastructure design document.|
|Clean up Doxygen||Need to get documentation syncing nightly.|
|User's Guide||Behind. Trying to catch up. Making some progress.|
|Prototype VTK/ParaView/VisIt integration
(Technically not part of the release, but should indicate we have viable components.)
|Eric Brugger has made some progress on integrating VTK-m into VisIt. He is able to run the marching cubes algorithm from within VisIt and generate images.|