Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modification made to reflect the V6 release plan change #943

Merged
merged 2 commits into from
Jun 15, 2022

Conversation

mzhangw
Copy link
Collaborator

@mzhangw mzhangw commented Jun 13, 2022

GFS_v17_p8 is now supported by CCPP SCM only. see Doxygen result here

Copy link
Collaborator

@ligiabernardet ligiabernardet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@mzhangw
Copy link
Collaborator Author

mzhangw commented Jun 13, 2022 via email

@@ -383,7 +383,7 @@ module rrtmg_lw

! --- public accessable subprograms

public rrtmg_lw_run, rrtmg_lw_finalize, rlwinit
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that we were going to wait to make any more changes like this so that we can remove all empty subroutines in one PR? Piecemeal changes of this nature make code management harder, IMO.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mzhangw Perhaps revert this change and later do a more complete cleanup of empty subroutines?

@grantfirl
Copy link
Collaborator

@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?

@grantfirl
Copy link
Collaborator

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
Copy link
Collaborator

ligiabernardet commented Jun 14, 2022

@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.

@ligiabernardet
Copy link
Collaborator

@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.

@ligiabernardet
Copy link
Collaborator

Thanks for reverting those changes.

@grantfirl
Copy link
Collaborator

@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.

@grantfirl grantfirl merged commit 87d4b6c into NCAR:release/public-v6 Jun 15, 2022
@mzhangw
Copy link
Collaborator Author

mzhangw commented Oct 11, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CCPP v6 Needed for CCPP v6 public release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants