Teleconference 2014-12-10
Attendees: Ken Moreland (SNL), Dave Pugmire (ORNL), Jeremy Meredith (ORNL), Robert Maynard (Kitware), Hank Childs (UO), James Kress (UO), Matt Larson (UO), Chris Sewell (LANL), Pat Fasel (LANL)
All VTK-m developers should be on the VTK-m mailing list now (http://vtk.org/mailman/listinfo/vtkm). There appeared to be some issues with the mailing list at the beginning of the meeting, but they all seem to be resolved by the end. Future announcements about these meetings will go to that list.
Several developers did not have a copy of the latest VTK-m Users' Guide. Due to some release issues at SNL, the document is not publicly posted yet. Ken was tasked to send it out to the other developers.
There was also some questions about how to set up, run and develop VTK-m. Ken said he would add some pages to the VTK-m Wiki to describe that.
Ken sent a proposal to talk about VTK-m for GTC. The talk is accepted, but Ken now has a conflict. Jeremy and Robert both said they could do it. They can work out which one will actually go later.
It was brought up that we might want to do some tutorials next fall (Vis/SC). It is a little unclear if we will have enough to give a tutorial by then and the due date will be somewhere around March. It could be a good opportunity though and would establish a good deadline.
Hank also brought up doing a State of the Art presentation at EuroVis. It was a little unclear what the requirements of that is or whether what we have fits well. Hank will get more information (CFP and more general description) and email it to the group. A proposal for EuroVis state of the art is due January 16. We think it is about 20 pages, but should be easy to pull together from existing material.
There was a little discussion on the Boost dependency in VTK-m. Jeremy stresses a dependency-free library to make it easy to integrate in situ with codes. Robert suggested that there is a Boost copy functionality that can copy the subset of Boost required by VTK-m and even place it in its own namespace so that it will not conflict with other Boost installations. In any case, the API to VTK-m does not rely on Boost and should stay that way, so whatever decision we make should be of little consequence to users. The conversation is tabled until later.
