-
Notifications
You must be signed in to change notification settings - Fork 236
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
Remove conversion to meters for diagnostics in non-Boussinesq mode #1565
Comments
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. |
Modified the units for 10 thickness or thickness tendency diagnostics to write them in their native units (e.g., kg m-2) when run in non-Boussinesq mode. These changes were proposed in mom-ocean#1565 and discussed and agreed to at the MOM6 dev call on 4/25/22. Previously these diagnostics had been converted to approximate thicknesses in m using a constant reference density, but this was only accurate to about 0.1% and could be misinterpreted. A number of other (more commonly used) thickness-related variables were already being written in their native units, and this makes the model's output more self consistent. All solutions are bitwise identical, but some diagnostics will change when run in non-Boussinesq mode.
This issue should be fully addressed once NOAA-GFDL#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. |
Modified the units for 10 thickness or thickness tendency diagnostics to write them in their native units (e.g., kg m-2) when run in non-Boussinesq mode. These changes were proposed in mom-ocean#1565 and discussed and agreed to at the MOM6 dev call on 4/25/22. Previously these diagnostics had been converted to approximate thicknesses in m using a constant reference density, but this was only accurate to about 0.1% and could be misinterpreted. A number of other (more commonly used) thickness-related variables were already being written in their native units, and this makes the model's output more self consistent. All solutions are bitwise identical, but some diagnostics will change when run in non-Boussinesq mode.
The code correcting this issue has now been merged onto the main branch of MOM6 as a part of #1582, with the specific changes coming in from NOAA-GFDL#181. |
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 toverticalGrid_type
which would contain the appropriate scaling factor for the mode that the model was in (i.e.H_to_m
for Boussinesq andH_to_MKS
for non-Boussinesq.The text was updated successfully, but these errors were encountered: