Code Sprint 2017-04-04

Jump to navigation Jump to search

CodeSprint2017 GroupPicture.png

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).

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


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,

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,

Since we have several users from different backgrounds, this is a good time to collect several opinions.