-
Notifications
You must be signed in to change notification settings - Fork 37
2023.10.19 Meeting Notes
Philipp Grete edited this page Nov 8, 2023
·
3 revisions
- Individual/group updates
- API forward compatibility, see https://github.com/parthenon-hpc-lab/parthenon/issues/951
- Next developer/user(?) meeting
- review non-WIP PRs
LR
- GMG was planned to be merged BUT discovered an issue with MPI and AMR
- Running on different ranks results in different results. Now into debugging -- likely related to reusing comm buffers.
- PR for cleanup GMG example and separating solver interface ready for review
BP
- working through long KHARMA backlog related to restructuring (PEP1, bound conditions, ...)
- found AMR bug (but currently expected to be an issue inside KHARMA)
PM
- fixed
-d
bug for creating directories
BW
- while working on AthenaPK, came across API issue, raising question on forward compatibility (see discussion below)
- trying to add FPE traps, but those don't work for MacOS. Will open PR that works on other architectures
PG
- INCITE runs are going well (finally) though analysis is tough given the data volume
- added in-situ histograms and "analysis restarts" to Parthenon to mitigate some of the analysis issue (with Ascent, Paraview, and yt)
- PRs are ready for review though the "analysis restart" should be considered PEPish, so more a discussion with an example implementation
- PG didn't properly communicate API breaking changes when updating AthenaPK to latest Parthenon
- This raised a discussion on fixing the API and release cycles
- Tentative results of the discussion (to be revisited at the next meeting)
- Parthenon is still evolving and we do not want to force ourselves in maintaining an API that is incompatible with a new feature
- we should make tagged releases roughly every 6 months and keep the API stable in between
- to keep the overhead small, we could add automated downstream compatibility tests (literally, continuous "integration") so flag PRs that break downstream codes
- when releasing the API breaking changes should be well documented so that downstream codes can easily adjust