Teleconference 2015-06-10
Attendees: Ken Moreland (SNL), Sujin Philip (Kitware), Chunming Chen (Kitware), Tom Fogal (NVIDIA), Jeremy Meredith (ORNL), Berk Geveci (Kitware), Rob Maynard (Kitware)
The data model is now merged into master. Sujin is working on getting worklets running across the data model. One current issue with the data model is that it needs to better identify the point coordinates. In the near future the point coordinates will also require a different dynamic storage container since they could use storage unlikely to be used in other fields. There is even a special DynamicPointCoordinates class to make it easier to manage this.
We are running into issues with the conversion of dynamic arrays into static instances in the worklet execution. Most of the time you expect data of a specific precision and just operate on that. However, the dynamic to static conversion for the worklet invoke happens independently for each parameter. In addition to leading to code bloat, it means that the worklet has to be prepared for every combination of data type, even if they don't make sense. This makes it easy to generate compile problems. There was some discussion on changing the mechanism to have one type for all parameters. In addition to being unclear what this would look like, this might cause problems later when integrating with VTK/ParaView/VisIt where users could easily (and with good reason) attempt to run algorithms using fields of different types. This remains an open issue.
There has been an issue with zipped arrays and other derived arrays. It is not possible to do in place operations in the device adapter on these structures. The problem is that in order to be writable, the iterator adapters are returning a reference object rather than the actual data type, which messes up the templating of the generic algorithm. (Side note, this is why we use ArrayPortal objects rather than try to make everything iterators.) There is a branch that fixes the issue for zipped arrays, but we need a more general solution.