MOM6
MOM6 copied to clipboard
Remove conversion to meters for diagnostics in non-Boussinesq mode
Description
A number of diagnostics related to thickness fluxes have which should change if the MOM6 is run in non-Boussinesq or Boussinesq mode. Additionally, many of these diagnostics contain a conversion factor GV%H_to_m
which uses a reference density (even in non-Boussinesq mode) to convert the diagnostic to units of 'meters'. If MOM6 is run in non-Boussinesq mode, this will mean that the thickness (and other) budgets may not close even in native coordinates.
@klindsay28 compiled a list of such diagnostics.
Diagnostics with Boussinesq dependent units:
dhdt eta_bt eta_hifreq eta_pred_hifreq eta_st h h_dyn h_preale h_rho
Diagnostics with units independent of Boussinesq
boundary_forcing_h boundary_forcing_h_tendency diabatic_diff_h dynamics_h dynamics_h_tendency frazil_h h_pre_sync h_regrid thkcello vert_remap_h vert_remap_h_tendency
Recommended solution:
To retain full accuracy, @klindsay28 and I would recommend that all thickness related diagnostics use the units native to the model (e.g. 'kg m-2' for non-Boussinesq and 'm' for Boussinesq). Additionally, a new conversion factor H_to_native_h
could be added to verticalGrid_type
which would contain the appropriate scaling factor for the mode that the model was in (i.e. H_to_m
for Boussinesq and H_to_MKS
for non-Boussinesq.
GV%H_to_mks already fulfills the role of the proposed GV%H_to_native_h, in that it resolves to either GV%H_to_m or GV%H_to_kg_m2 depending on whether the model is in Boussinesq or non-Boussinesq mode.
Ah ok, thanks @Hallberg-NOAA for clarifying. Life is a bit easier then so that all that really needs to be done is to replace those diagnostics with GV%H_to_mks
We discussed this at the MOM6 dev call on 4/25/2022, and everyone is on board with making the units of most of these thickness variables on the second list dependent on whether the Boussinesq approximation is made. The one exception is thkcello, which is always defined to be thicknesses in m, as opposed to masscello, which is always in kg m-2.
@klindsay28 and @ashao, are either of you aware of efforts that are underway to implement your excellent suggestion, or do we need to arrange for someone to look into this?
I'm not aware of an effort to implement this.
This issue should be fully addressed once https://github.com/NOAA-GFDL/MOM6/pull/181 has been merged into the main branch of the code. @ashao or @klindsay28, if you would like to provide review comments on that PR, it would be greatly appreciated.
The code correcting this issue has now been merged onto the main branch of MOM6 as a part of https://github.com/mom-ocean/MOM6/pull/1582, with the specific changes coming in from https://github.com/NOAA-GFDL/MOM6/pull/181.