Bugfix on total column thickness for wetting #975
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
herrwang0
force-pushed
the
bugfix-zref-thickness
branch
from
53d92c3 to
61039e2
Compare
adcroft
requested changes
Oct 1, 2025
src/core/MOM_barotropic.F90
Outdated
| if (G%OBCmaskCu(I,j) * htot > 0.) then | ||
| ! Using CS%IDatu(I,j) = G%OBCmaskCu(I,j) * 2.0 / htot would be better but it changes answer. | ||
| CS%IDatu(I,j) = G%OBCmaskCu(I,j) * 2.0 / (Z_to_H * (max(G%bathyT(i+1,j) + G%Z_ref, 0.0) & | ||
| + max(G%bathyT(i,j) + G%Z_ref, 0.0))) |
There was a problem hiding this comment.
The denominator could be expressed in terms of htot here?
There was a problem hiding this comment.
I agree. mistaken it for a * Ihtot scenario. (even that it should be OK in this case, right? Since the numerator has 0 as its significand)
src/core/MOM_barotropic.F90
Outdated
| if (G%OBCmaskCv(i,J) * htot > 0.) then | ||
| ! Using CS%IDatu(i,J) = G%OBCmaskCv(i,J) * 2.0 / htot would be better but it changes answer. | ||
| CS%IDatv(i,J) = G%OBCmaskCv(i,J) * 2.0 / (Z_to_H * (max(G%bathyT(i,j+1) + G%Z_ref, 0.0) & | ||
| + max(G%bathyT(i,j) + G%Z_ref, 0.0))) |
In a number of cases, total resting column thickness is calucated as
G%bathyT + G%Z_ref, which is largely correct but for wetting, i.e.
G%bathyT < 0. This commit makes a correction for eight cases with this
potential bug. Additionally, a correction is made in one case that
G%bathyT + G%Z_ref is used as depth where negative depth does not make
sense.
There is no answer changes if no wetting points are used and G%Z_ref is
zero.
List of modules/processes affected:
* MOM_barotropic
* affects only surface stress when BT_NONLIN_STRESS is False.
* MOM_wave_speed
* h2 calculations in
* subroutine internal_tides_init
* subroutine int_tide_input_int
* subroutine tidal_mixing_init
* MOM_tracer_z_init
* D_[uv] in set_viscous_BBL, which is used only when CHANNEL_DRAG = True
* MOM_lateral_mixing_coeffs
* MOM_MEKE
herrwang0
force-pushed
the
bugfix-zref-thickness
branch
from
61039e2 to
a67ff8e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In a number of cases, total resting column thickness is calucated as
G%bathyT + G%z_ref, which is largely correct but for wetting, i.e.G%bathyT + G%z_ref< 0. This commit makes a correction for eight cases with this potential bug. Additionally, a correction is made in one case thatG%bathyT + G%z_refis used as depth where negative depth does not make sense.List of modules/processes affected:
MOM_barotropicBT_NONLIN_STRESSis False.MOM_wave_speedh2calculations ininternal_tides_initint_tide_input_inttidal_mixing_initMOM_tracer_z_initD_[uv]inset_viscous_BBL, which is used only whenCHANNEL_DRAG= TrueMOM_lateral_mixing_coeffsMOM_MEKEThere is no answer changes if no wetting points are used and G%Z_ref is zero.