Baroclinic sea level calculation#1104
Conversation
Algorithms implemented in MOM_interface_heights.F90
Implemented in MOM_diagnostics.F90
Implemented for harmonic analysis
* Rewrite algorithm for the EOS and non-Boussinesq case. * Skip calculations at grid points with potentially zero depth.
| gz, & ! Geopotential at the bottom of a layer [L2 T-2 ~> m2 s-2] | ||
| dp, & ! Pressure change across a layer in Boussinesq mode [R L2 T-2 ~> Pa] | ||
| dg, & ! Geopotential change across a layer in non-Boussinesq mode [L2 T-2 ~> m2 s-2] | ||
| dp_int, & ! Layer-integrated pressure change in Boussinesq mode [R L T-2 ~> Pa m] |
There was a problem hiding this comment.
The units of dp_int should be [R L2 Z T-1 ~> Pa m].
| dg, & ! Geopotential change across a layer in non-Boussinesq mode [L2 T-2 ~> m2 s-2] | ||
| dp_int, & ! Layer-integrated pressure change in Boussinesq mode [R L T-2 ~> Pa m] | ||
| dg_int, & ! Layer-integrated geopotential change in non-Boussinesq mode [L2 T-2 Z ~> m3 s-2] | ||
| p_int ! Vertical integral of pressure at the bottom of a layer [R L2 T-2 Z ~> Pa m] |
There was a problem hiding this comment.
It is useful to follow a standard order of the units when grepping for strange (and usually wrong) units, so we always list the units in the numerator before those in the denominator. The unit description for dg_int should be [Z L2 T-2 ~> m3 s-2], while that for p_int could be [R L2 Z T-2 ~> Pa m].
|
|
||
| I_gEarth = 1.0 / GV%g_Earth | ||
|
|
||
| Rho0 = GV%Rlay(1) ; SpV0 = 1.0 / GV%Rlay(1) |
There was a problem hiding this comment.
The target potential density (often sigma-2) of the surface layer is usually not a physically meaningful quantity. We often simply set it to be light enough to ensure that there is not a big gap in resolution in fresh marginal seas, and in z-coordinate mode it might not be set at all! If Rho0 here needs to be a global constant, it should be set explicitly via a separate run-time parameter, and it should not be called Rho0 to avoid confusion with the Boussinesq reference density, which should never be used in non-Boussinesq mode. If this can be spatially and temporally varying, perhaps it should be set to the local surface density.
There was a problem hiding this comment.
Spv0 is only used in int_specific_vol_dp (non-Boussinesq cases), and in other calls to this routine its value is either 0.0 or 1.0 / CS%rho_ref.
Rho0 is used in int_density_dz, and in other calls to this routine its value is GV%Rho0, the Boussinesq reference density. This is certainly the correct value here.
Rho0 is also used to convert a pressure to a height. In Boussinesq cases this should be the Boussinesq reference density. In non-Boussinesq cases, this might be the average density of the water column i.e. a 2-D field. In cases without an equation of state, Rho0 might be GV%Rho0 or perhaps the average density of the water column i.e. a 2-D field.
This calculation is effectively using PRESSURE_RECONSTRUCTION_SCHEME=0 (PCM or no reconstruction), but almost all actual cases are using 1 (PLM reconstruction). I don't know if this makes a difference or not.
There was a problem hiding this comment.
Rho0 as the normalization factor in the denominator should be the surface density, rather than the water column averaged density, since only the surface pressure matters in determining the barotropic/baroclinic sea level, though I agree that Rho0 is not a good variable name since it could imply GV%Rho0 of the Boussinesq approximation. If the surface density is very different from GV%Rho0, then the results could be inaccurate/incorrect if GV%Rho0 is used in the calculation (though the Boussinesq approximation should probably not be used at all in this case).
I'm not sure if we should use a spatially varying Rho0 (a 2D field). It seems unnecessary to me, since BSL calculation is relevant only in the open ocean, whereas significant surface density change usually occurs along the coast due to runoff, or in the high latitude regions due to sea ice, where baroclinic tides are sub-inertial any way. But other than GV%Rlay(1), I'm not sure what's the most appropriate variable for the surface density.
There was a problem hiding this comment.
The error from using a constant RHO, or from using the wrong RHO, is only 1-2%. So it will be difficult to resolve what the right approach is, and it is moot if we think of this as an approximate splitting of SSH. So I am OK with the current approach.
I agree with Bob that you need a MOM_input parameter, and I suggest calling it RHO_BSL since the diagnostic is named bsl. Then Spv0 is 1.0/rho_bsl.
There was a problem hiding this comment.
Thanks @Hallberg-NOAA and @awallcraft. The requested changes are incorporated into the latest commit. Instead of GV%Rho0 or GV%Rlay(1), I simply used RHO_BSL = 1025 kg m-3 as the default value, which I think should work for most cases.
There was a problem hiding this comment.
This looks good except that the get_param for RHO_BSL should always be called. This is consistent with the other "diagnostics only" parameters, and avoids issues if RHO_BSL is explicitly set when the diagnostic is not used (e.g. if FATAL_UNUSED_PARAMS is set).
There was a problem hiding this comment.
Thanks @awallcraft, this has been fixed.
c2xu
force-pushed
the
c2xu/bsl2
branch
4 times, most recently
from
c8f776f to
d0be54e
Compare
* Fix dimensions of variables * Set the surface density as a run-time parameter, RHO_BSL, with the default value being RHO_BSL = 1025 kg m-3.
4 participants
This replaces PR #984 and is based on algorithms in a manuscript that we plan to submit to JPO. Reference to this work will be added as soon as it's available.