Teleconference 2022-01-26

From VTKM
Revision as of 13:49, 26 January 2022 by Kmorel (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Attendees: Ken Moreland (ORNL), Roxana Bujack (LANL), Silvio Rizzi (ANL), Berk Geveci (Kitware), Nick Davis (SNL), Manish Mathi (UO), Ollie Lo (LANL), Tushar Athawale (ORNL), Hank Childs (UO), Vicente Bolea (Kitware), Sujin Philip (Kitware), James Kress (ORNL), Ollie Lo (LANL)

ECP Updates

  • 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
  • ECP management is wanting weekly updates on early access progress
    • Not sure how that communication is going to happen
  • 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
    • Possible highlight slide on particle advection with WarpX (Matt)
    • Some work with MFIX. Going to execute on Summit. Might wait for run on early access machine before highlight.

Porting Activities

ECP task updates

ECP/VTK-m Project Management

Roundtable

Expect to release 1.7.1 this week.

When updating the tests, Ken noticed some discrepancies in the rendering for some types of components. Who is now responsible for rendering and can take a look at this:

They are probably not used. Maybe they should be deprecated.

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.

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.