Attendees: Ken Moreland (SNL), Nick Thompson (ORNL), Ollie Lo (LANL), Matt Larsen (LLNL)
- Report for latest P6 Activity submitted
- Ken is transitioning to ORNL
- Calendar invite will be canceled and a new one should be coming next week
- Meeting should happen next week but is not guaranteed
- 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)
- 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).
ECP task updates
Matt has brought up some issues with compiling Ascent (more specifically, VTK-h) with newer versions of CMake. It is not totally clear what versions of CMake the issue comes up, but it has been noted that the dashboards do not use the latest versions. In particular, the highest version of CMake used for a CUDA build is 3.16. We need to check for newer versions of CMake.
Version 1.6.0-rc1 is released. What do we need to do before the official release? Update Ascent? Update VTK? Others?
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.)
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.