Closed mzhangw closed 2 years ago
I am conducting RTs on Hera.
On Jun 13, 2022, at 4:11 PM, ligiabernardet @.***> wrote:
@ligiabernardet commented on this pull request.
Thank you for making these changes. The documentation looks good to me. In out last DTC-CCPP meeting, we discussed running RTs before new commits to the release branch, so we can be sure all is in order. This is a low risk change but since there are Fortran files that were modified, this seems like a good idea. Will you be conducting those? We also need PRs for the release v6 branches of FV3ATM and UFS WM, so that we can include these changes in the release.
— Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/pull/943#pullrequestreview-1005011416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG7TW2QRK5DJPFZAJHRMSQDVO6WX5ANCNFSM5YVSFITQ. You are receiving this because you authored the thread.
@ligiabernardet Are we responsible for updating the submodule pointers in the supermodule release branches or will EPIC do this once we've merged this and have a new commit hash?
@mzhangw Have the RTs finished?
Also, since this PR doesn't update any of the files updated by #932 , there shouldn't necessarily be a need to pull in the latest public/release-v6 branch before merging this one, although it wouldn't hurt anything to do so (which is the normal procedure for main).
@ligiabernardet Are we responsible for updating the submodule pointers in the supermodule release branches or will EPIC do this once we've merged this and have a new commit hash? No, we are not responsible. EPIC will do those updates because the UFS WM supermodule is in the EPIC fork.
@mzhangw Have the RTs finished?
@grantfirl I don't see how @mzhangw could conduct the RTs because we do not have access to the UFS WM code meant for the UFS SRW App v2 release - this code is in an EPIC fork. For this reason, in today's EPIC-led SRW release meeting, it was decided that we'd merge the PR without conducting RTs and they (EPIC, Mark Potts) would conduct the RTs. While this is backwards (merge then test), the upside is that, if the tests pass, we have the final hash for the release.
Thanks for reverting those changes.
@mzhangw Have the RTs finished?
@grantfirl I don't see how @mzhangw could conduct the RTs because we do not have access to the UFS WM code meant for the UFS SRW App v2 release - this code is in an EPIC fork. For this reason, in today's EPIC-led SRW release meeting, it was decided that we'd merge the PR without conducting RTs and they (EPIC, Mark Potts) would conduct the RTs. While this is backwards (merge then test), the upside is that, if the tests pass, we have the final hash for the release.
Yea, as I mentioned in Slack, running the RTs should really just confirm that the changes can pass ccpp_prebuild and compile.
Do you want me to revert it? Otherwise, it is complete. BTW, In the origin scidoc v6 PR, I have cleaned up these empty subroutines as much as I can. As Ligia suggested, EPIC will run the RTs since all v3 branches are brocken.
On Jun 14, 2022, at 3:11 PM, Grant Firl @.***> wrote:
@ligiabernardet https://github.com/ligiabernardet Are we responsible for updating the submodule pointers in the supermodule release branches or will EPIC do this once we've merged this and have a new commit hash?
@mzhangw https://github.com/mzhangw Have the RTs finished?
— Reply to this email directly, view it on GitHub https://github.com/NCAR/ccpp-physics/pull/943#issuecomment-1155716903, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG7TW2TS2MOMV47UWMII5XTVPDYQNANCNFSM5YVSFITQ. You are receiving this because you were mentioned.
GFS_v17_p8 is now supported by CCPP SCM only. see Doxygen result here