forked from mom-ocean/MOM6
-
Notifications
You must be signed in to change notification settings - Fork 51
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
SET_DTBT using wrong face area #660
Comments
herrwang0
changed the title
SET_DTBT is underestimating gravity wave speed
SET_DTBT using wrong face area
May 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Subroutine
set_dtbt
() is used to estimate barotropic time step size. The subroutine is called inMOM6/src/core/MOM_barotropic.F90
Line 4907 in 7305528
dtbt_reset_period
MOM6/src/core/MOM_dynamics_split_RK2.F90
Line 646 in 7305528
In the subroutine, there are currently three options in calculating/estimating face area
BT_cont
eta
, passing to subroutinefind_face_areas
()add_SSH
, passing to subroutinefind_face_areas
()And all of them seem to have an issue.
Issues
1.
BT_cont
For reasons unknown,
BT_cont
option is never used in this subroutine.2.
eta
Instead,
eta
is used in recalculating dtbt. The problem is thateta
is almost never used because of this buggy block (NONLINEAR_BT_CONTINUITY
is by default False and not used withUSE_BT_CONT_TYPE
):MOM6/src/core/MOM_barotropic.F90
Lines 2869 to 2875 in 7305528
3.
add_SSH
The bug in the if-block above effectively let the model use zero sea surface height (add_SSH is zero by default) to calculate face area, which may underestimate gravity wave speed.
Moreover, without
eta
, subroutinefind_face_areas
() will use (Z_ref
-bathymetry) to estimate thickness. This does not apply to cases like the Great Lakes, where 1) Within the domain, the reference height is spatially varying 2) portions of the water bodies are above the sea level reference height . (and runtime parameterSSH_EXTRA
, which is currently only used to estimate an upper bound of eta during initialization would not help.)Solutions
BT_cont
when possibleeta
Z_ref
a 2D field, rather than a scalar. I put an asterisk because the scalar should be fine for most cases, even with spatially varying reference heights. But I wonder if something weird may come up with OBCs...The fixes may make the model slower with shorter dtbt.
The text was updated successfully, but these errors were encountered: