Closed iangrooms closed 1 month ago
Thanks @Hallberg-NOAA for your review! I am still working on mastering the unit scalings and Boussinesq vs non aspects of MOM6. I think my latest commit addresses all your comments, but please take a look.
With these changes that you just introduced, it is all looking good to me!
Thanks, @iangrooms, for this contribution, and thanks, @Hallberg-NOAA, for reviewing this PR.
The pr_mom
tests are passing. I only have the minor comment raised above regarding a new logical parameter (allow_preserve_variance
) in subroutine ALE_remap_velocities
.
New MOM_input parameter:
REMAP_VEL_CONSERVE_KE = False ! [Boolean] default = False
! If true, a correction is applied to the baroclinic component of velocity after
! remapping so that total KE is conserved. KE may not be conserved when
! (CS%BBL_h_vel_mask > 0.0) .and. (CS%h_vel_mask > 0.0)
New available diagnostics:
"ale_u2" [Unused]
! modules: {ocean_model,ocean_model_d2}
! long_name: Rate of change in half rho0 times depth integral of squared zonal velocity by remapping. If REMAP_VEL_CONSERVE_KE is .true. then this measures the change before the KE-conserving correction is applied.
! units: W m-2
! cell_methods: xq:point yh:mean
"ale_v2" [Unused]
! modules: {ocean_model,ocean_model_d2}
! long_name: Rate of change in half rho0 times depth integral of squared meridional velocity by remapping. If REMAP_VEL_CONSERVE_KE is .true. then this measures the change before the KE-conserving correction is applied.
! units: W m-2
! cell_methods: xh:mean yq:point
When I was first implementing this I noticed that the subroutine ALE_remap_velocities
gets called in more than one context; e.g. this subroutine is applied to remap diffusive tendencies. If we just control the action with a MOM_input
parameter then the correction either happens every time the subroutine is called or not at all, and we don't necessarily want to apply this KE-conserving correction every time the subroutine is called - only when remapping the velocity during the time stepping loop.
At the time I discussed this with Alistair, who suggested that I add the logical parameter ALE_remap_velocities
. I then hard-code the value to 'true' but only in the places where I want the correction to be allowed. In other places it is 'false' by default. (Alistair also helped me significantly by providing code snippets for various parts of the algorithm.)
In short, we have 2 logical parameters controlling this feature. Only one parameter can be set by the user, and it turns the feature on or off. The other parameter is only internal, and serves to ensure that the correction only happens in the places we want it to happen.
Thanks for the clarification!
This PR does two things:
ale_u2
andale_v2
, that measure the rate of depth-integrated KE loss (or gain) associated with remapping velocity. The rates are computed separately for the u and v components, and the output units are Watts per square meter.The correction is described in more detail here ke_conserving_remap.pdf