Teleconference 2019-08-21

From VTKM
Revision as of 09:07, 21 August 2019 by Kmorel (talk | contribs) (Created page with "Attendees: == ECP Updates == * Budget plus ups ** Remember to send BOEs to Ken * ECP review coming up ** September 23-27 ** 30 minute talk like previous years ** Will ask f...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Attendees:

ECP Updates

  • Budget plus ups
    • Remember to send BOEs to Ken
  • ECP review coming up
    • September 23-27
    • 30 minute talk like previous years
    • Will ask for input as necessary
  • Capability Assessment Report (CAR) also coming up
    • Will update from last year
  • KPP-3 will undergo another iteration
    • There will be a standard scoring system
    • It will likely be similar, but not accumulative

ECP deliverable updates

FY19Q4

  • [MS-19/09] Path Geometry
    • Just need User's guide documentation
    • Dave plans to have the documentation done this week
  • [MS-20/01] Lightweight Cell Library
    • Test set that is working for both CPU and GPU
    • By end of August should have all cell types done and start working on VTK-m integration.
  • [MS-20/02] Specialized Data Models
    • Just need documentation from Mark
    • Dave will ask Mark to get it done this week
  • [MS-20/05] Cell Metrics
    • Implementations for 18 metrics.
      • Not all tested thoroughly
    • New student Sam Schwartz is getting up to speed
  • [MS-20/06] Contouring
    • Ollie has started coding. Has some design questions he will ask offline.
  • [MS-20/07] Advanced Flow Algorithms
    • FTLE is merged in and documented
    • Stream surface merged in a while ago
    • Dave plans to have the documentation done this week

Rountable notes

We were contacted by Mahesh Rajan about having a VTK-m instance on some OSTI-managed resources. Not sure who is taking point in that.

During this week while testing the new contour filters, Ollie found some issues with the gradient computation used to generate normals. Part of this was a bug in how normals were computed in pyramids, which Ken fixed. However, Ollie was still getting NaN values for the gradient in pyramids. After looking into this more, Ken found that this was caused by clipping a hexahedron with the plane intersecting exactly at 3 points. This caused the clip tables to create degenerate pyramids, and the gradient computation is sensitive to degenerate pyramids. Ken checked and saw that the clip in ParaView has the same behavior with respect to both the clip filter and the gradient computation, so at least for now we can probably ignore this. The easiest solution is to change the test to put the plane in general position.