Teleconference 2016-01-06

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.

Dashboard status

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.

Copyright Assertion

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.

Feature	Status
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" Proposal for filter interfaces in issue #17	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.
Green dashboard	Still have problems with some CUDA dashboards Some may have been resolved There are issues with dejagore running out of memory Some working CUDA dashboards have a timer failure There have been some interop failures. - Rob thinks they are fixed. Some further output issues on Windows (see delve dashboards e.g. https://open.cdash.org/viewTest.php?onlyfailed&buildid=4123995) Need to get the buildbot tests running nightly to check up on this issue. Some timeout issues on renar (e.g. https://open.cdash.org/viewTest.php?onlyfailed&buildid=4123644). Could be caused by JIT of CUDA kernels or might be because multiple things are running. This should be resolved with a branch being merged in today.
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.