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

Fix a minor bug in porous barriers #726

Closed
wants to merge 2 commits into from

Conversation

herrwang0
Copy link

This PR fixes a minor bug in porous barriers module.

It may change answers for some very rare cases in barotropic runs. For an example I tested with barotropic tides, the answer is unchanged at bit level. Given the functionality is not yet widely used, I decide to omit a bug flag.

A second commit turns the default of USE_POROUS_BARRIER to false, responding to a long standing request.

Fix a bug that layer/interface weights may not be reset to 1.0 if no
calculations are needed. The bug has negligible impact for barotropic
applications but may affect baroclinic runs which are yet to performed.
@herrwang0
Copy link
Author

Fails with different diagnostics in regression tests are to be expected, as by changing the default of USE_POROUS_BARRIER, a few diagnostics are turned off.

Copy link
Member

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

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

These changes seem sensible to me, and appear to be correctly implemented. I am tempted to approve them now.

However, it might make sense to hold these changes (especially the changes to the default value for USE_POROUS_BARRIER) until after the next PR from dev/gfdl to main. The PR immediately after that will include numerous other changes to defaults, as was agreed to in a late-July MOM6 dev call, and it might make sense to put this PR in along with the other PRs that will change defaults.

@Hallberg-NOAA Hallberg-NOAA added bug Something isn't working Parameter change Input parameter changes (addition, removal, or description) labels Sep 20, 2024
@herrwang0
Copy link
Author

These changes seem sensible to me, and appear to be correctly implemented. I am tempted to approve them now.

However, it might make sense to hold these changes (especially the changes to the default value for USE_POROUS_BARRIER) until after the next PR from dev/gfdl to main. The PR immediately after that will include numerous other changes to defaults, as was agreed to in a late-July MOM6 dev call, and it might make sense to put this PR in along with the other PRs that will change defaults.

In this regard, does it make sense to break this PR into two? We could maybe fast-track a bug fix PR, so that it does not hinder some of the experiments we have in mind for regional runs? A second PR for default parameter change can be merged later.

@marshallward
Copy link
Member

marshallward commented Sep 24, 2024

@herrwang0 It would be OK add the USE_POROUS_BARRIER parameter to the MOM_input files of each test. Overall it's probably better to avoid the regression.

(Although maybe there is value in letting the regression fail, to signal a change in defaults? If so , then I think this needs discussion.)

@herrwang0
Copy link
Author

@marshallward Thanks for the response. In a way, I think it is informative to have these anticipated fails. But I guess this boils down to what is the standard practice for changing defaults. Can/should I change the default in MOM_input for tc tests? Or is it better to consolidate all default changes to a single (annual) PR?

@marshallward
Copy link
Member

@herrwang0 The original purpose of the test is to catch unintentional regressions. I don't think any of us would consider a default parameter change to be a regression. So that would be the simplest answer to your question.

But you make a good point. There is value in detecting and reporting changes in default parameters which change answers. But is this test the place to do it?

There's a lot more to say here (GitHub's lack of a "Warn" state, the impact on later PRs to main, etc), but we should probably hold that discussion for another time.

Personally I'd just change the tests, but I'm open to whatever you think is right. (However, I don't necessarily speak for the others!)

@herrwang0
Copy link
Author

I am breaking this PR into two, so that the bug fix can be adopted first.

@herrwang0 herrwang0 closed this Oct 3, 2024
@herrwang0 herrwang0 deleted the fix_pb_bug branch October 13, 2024 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Parameter change Input parameter changes (addition, removal, or description)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants