2022.12.01 Meeting Notes

Agenda

JD

tracking down a potential bug, potentially related to flux correction
no significant progress on face fields, we'll put this on the agenda for early Jan meeting, but PR is effectively ready for review, FG will get a first look

BR

LR

BP

signal handling code is back in WIP because of inconsistent signal handling by MPI libs. Will no turn into file trigger
will also remove SIGALRM (and other signals)
updating output naming (e.g., more flexible "final" naming)

TG

Fixed Kokkos warning handling (required by our catch2 tests), which changed in Kokkos 3.7
Updated second order refinement to match new design
Will merge now and then we'll update zones to check in a separate PR
Will look at refinement loop bug next

FG

Need to answer final comments for https://github.com/parthenon-hpc-lab/parthenon/pull/753 but basically ready to merge
other group member are waiting for FaceFields/CT in AthenaPK

PM

JS

Now has AMR work with "5D view" in AthenaK -- is happy with performance
Would be interested in a performance comparison (e.g., hydro Sedov similar to Athena++ paper)
Also have z4c solver in AthenaK now (for binary BH mergers)

PG

Will submit abstract to Cray User Group Meeting with John at OLCF
tracking down bug (JSC/AMD GPU workshop) https://github.com/parthenon-hpc-lab/parthenon/issues/659
BW will work on adding Ascent
Reviewing PRs

Parthenon currently ships two modules as part of the repo
Q: Should we move them to a separate repo?
Potential advantages:
- streamline CI
- easier downstream handling for phdf dependent python tools
Potential disadvantages
- changes in two repo may add developer "overhead"
- keep/maintain backward compatibility
- need new approval for new repo?
Result:
- BP and JD will look into approval
- BP will work on separate CI concerns (C++ from Python code) and PG will provide pointer to Github Actions for file based triggers

Can we get a "breaks downstream" label? -> Dev are encouraged to add a label to new PRs to add extra visiility for down stream devs
Can we separate "trivial" PR from "need more attention" PRs? May be difficult because there may be hidden side effects.
Will introduce "trivial" branch to collect trivial changes (like typos) from everyone and regularly merge potentially without Changelog for editorial changes (PG will add doc)