Code Sprint 2017-04-04
Our third code sprint was held on April 4-6, 2017 and was hosted at the University of Oregon. Pictured left-to-right: James Kress (ORNL/UO), Abhishek Yenpure (UO), Sudhanshu Sane (UO), Manish Mathai (UO), Matt Larsen (LLNL), Nicole Marsaglia (UO), Bernd Hentschel (RWTH-Aachen), Brent Lessley (UO), Roba Binyahib (UO), Rob Maynard (Kitware), Hank Childs (UO), Stephanie Labasan (LLNL/UO), Dave Pugmire (ORNL), Ken Moreland (SNL), David Lonie (Kitware), Mark Kim (ORNL), Dongliang Chu (ORNL), Tom Otahal (SNL), and Alberto Villareal (Intel).
http://ix.cs.uoregon.edu/~hank/vtkm17.html
Contents
Get VTK-m Now
Get the latest version of the VTK-m Users' Guide. (I just uploaded an updated version.)
If you have not yet, get VTK-m on your laptop now by cloning the following URL:
Build it. The Users' Guide has some instructions.
Possible topics
- Sources (wavelet, tangle field, miniIO)
- Hash function bake off
- Image comparison testing
- Filters compiled into library
- Dynamic classes
- Fix exports in rendering library for OSX
- Build simple "tutorial" exercises
- Clean up old merge requests
- Redesign error reporting
Participants
| Participant | From | Project |
|---|---|---|
| Dongliang Chu | ORNL | particle advection |
| Mark Kim | ORNL | particle advection, ray tracing |
| James Kress | ORNL | particle advection |
| Matt Larsen | LLNL | hash function bakeoff, ray-tracing infrastructure, spatial search structures, point-based rendering |
| David Lonie | Kitware | reducing VTK-m library size, virtual functions |
| Rob Maynard | Kitware | answer questions! |
| Ken Moreland | SNL | hash function bakeoff |
| Thomas Otahal | SNL | vectorization/threading on Xeon Phi |
| David Pugmire | ORNL | particle advection |
| Brent Lessley | UO | hash function bakeoff, graph analysis |
| Alberto Villareal | Intel | vectorization/threading on Xeon Phi |
| Hank Childs | UO | "getting started", particle advection, spatial search structures |
| Bernd Hentschel | Aachen | "getting started", particle advection |
Quick Tutorial
To follow along (or do on your own) clone:
Quick Poll on Signature Types
VTK-m's heavy use of templates requires many type aliases to be defined. Originally we used typedef exclusively for this, but recently we moved to using. The effect of the two keywords is equivalent, but we like the syntax of using better because it brings the name being defined to the front of the statement, which makes it easier to see and read.
One current disagreement the designers have is whether we should use using for signatures (like ControlSignature and ExecutionSignature) or we should keep using typedef. The argument for using is that it cleanly separates the signature from the alias name. The argument for typedef is that the declaration itself looks like a function prototype declaration and will be easier for end users to grok the high level concept.
Here is a comparison. The following code is copied from a worklet for extract surface. It is nontrivial but not abnormal. The current implementation here uses typedef
typedef void ControlSignature(CellSetIn cellset,
FieldOut<> faceHashes,
FieldOut<> originCells,
FieldOut<> originFaces);
typedef void ExecutionSignature(_2,
_3,
_4,
CellShape,
FromIndices,
InputIndex,
VisitIndex);
Now here is the same declarations using the using keyword instead.
using ControlSignature = void(CellSetIn cellset,
FieldOut<> faceHashes,
FieldOut<> originCells,
FieldOut<> originFaces);
using ExecutionSignature = void(_2,
_3,
_4,
CellShape,
FromIndices,
InputIndex,
VisitIndex);
Since we have several users from different backgrounds, this is a good time to collect several opinions.
