Teleconference 2022-01-12

From VTKM
Revision as of 11:55, 12 January 2022 by Kmorel (talk | contribs)
Jump to navigation Jump to search

Attendees: Ken Moreland (ORNL), Ollie Lo (LANL)

ECP Updates

  • Will break early for ECP project review feedback
  • ECP Annual Meeting
    • Call for BoF, Breakout, Panel, Tutorials: Due Feb 16
    • Usually participate with Alpine
  • Crusher test and development system for Frontier
    • Our CSC331 project now has access
      • Apparently Kitware does not have access (even though I was told they would have it)
    • If you are waiting on my approval for something, send me an email
      • System is still not alerting me when I have approvals waiting
  • Software sustainability town halls
  • Let's think about possible highlights
    • App engagement
    • Success with porting (e.g. run on Aurora)
    • Engagement with other ST teams (e.g. using Kokkos)
    • WDM
      • Submitted highlight on integration with EFFIS
      • Expect to submit another highlight when used in a big run
    • Possible highlight slide on particle advection with WarpX (Matt)
    • Improvement with Kokkos on Spock

Porting Activities

ECP task updates

ECP/VTK-m Project Management

Roundtable

Break at 10:30 for ECP project review feedback.

LSSw whitepaper: a big part of Jim's response is a question of whether everything should be in VTK-m or if there is still stuff that should be otherwise. We should give some thought on what should or shouldn't be in VTK-m and have a reasonable argument for it.

Gunther brings up an issue where he tried contour trees with large data sets that ran slowly on CUDA but crashed with HIP/Kokkos. This might be an issue of lack of proper unified memory on the HIP/Kokkos end. We are not sure.

R&D100?

  • Thinking of submitting for 2022
  • Big stumbling block: needs to be "created" between Jan 2021 to March 2022
  • Plan: Release VTK-m 2.0, do a copyright assertion

Rename master branch?

  • Need to wait for some changes to git before the transition (for some automated features of repo).
  • Can we for a time have a master that mirrors the new default?
    • Don't know, but seems possible. Will have to look into that.