Teleconference 2021-03-24

Attendees:

ECP Updates

• Upcoming OLCF early access machine: Spock
  • No NDA
  • We will automatically get access through our Summit allocation
  • Expected to be available starting around mid May
• New ALCF early access machine: Arcticus
  • Available now (?)
• ECP Annual Meeting
  • BoF days will be held 2 weeks beforehand (March 30 - April 1)
  • Sign up for any BoFs you are interested in. (You don't need to be a member of ECP.)
  • Go to: https://www.exascaleproject.org/event/ecp-community-bof-days-2021/
  • In particular, consider attending the DAV session on March 30.
  • Registration is open
    • Will be virtual, registration is free
    • Everyone funded by ECP/VTK-m should register and plan to attend at least part of the meeting
  • Our project will need to create a poster
    • Looks like the design will be a traditional poster
    • Not totally clear how the poster session will work
    • Looks like they are planning on using a virtual meet space.
• 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).

Porting Activities

• https://confluence.exascaleproject.org/display/STDA05/Porting+Activities+A21
• https://confluence.exascaleproject.org/display/STDA05/Porting+Activities+O21

ECP task updates

ECP/VTK-m Project Management

Roundtable

Vicente will work on making a release. Matt has requested the release happen right before the removal of virtuals from implicit functions. We will start with a branch and a release candidate that Matt can add fixes to. Matt will be something of a guinea pig for this.

Wiki will go away at some point (and will definitely move soon). We should avoid using it for anything other than these notes.

We need some redesign design workflow for branchy release process

• When we create a VTK-m release, we have a branch for that release (at least until the subsequent release).
• New feature development continues on the main branch
• _Bug fixes_ happen off the release branch
  • Get merged to both the release branch and the master branch
• This in principal should already be supported by GitLab
  • Just create a merge request on a different branch
  • Will need to add support to gitlab-push
    • Ask VTK folks. They might just have a select few to do a special process.
  • Need to check that bot stuff works (CI builds, Do: merge, etc.)

Should think about releasing VTK-m 1.6, 2.0.

Filter redesign requirements: https://gitlab.kitware.com/vtk/vtk-m/-/issues/601

Matt working on WarpX highlight.

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.