You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When trying to trace down the source of mass conservation issues between MOM6 and SIS2, I realized that different definitions for the Earth's radius are used.
Here is an overview of various radius definitions I found when grepping the source code:
SIS2
src/SIS2/src/SIS_hor_grid.F90
real :: Rad_Earth = 6.378e6 !< The radius of the planet in meters.
MOM6
src/MOM6/.testing/tc4/build_grid.py:
Re = 6.378e6 # Radius of earth
src/MOM6/src/core/MOM_grid.F90:
real :: Rad_Earth = 6.378e6 !< The radius of the planet [m].
src/MOM6/src/initialization/MOM_grid_initialize.F90:
src/MOM6/src/initialization/MOM_shared_initialization.F90:
call get_param(..., Rad_Earth, ..., default=6.378e6)
Icebergs
src/icebergs/icebergs.F90
real, parameter :: Rearth=6360000. !< Radius of earth (m)
FMS
src/FMS/constants/constants.F90
real, public, parameter :: RADIUS = 6371.0e3 !< Radius of the Earth [m]
src/FMS/mosaic/constant.h
#define RADIUS (6371000.)
I am not entirely sure whether these inconsistencies are intentional or not and how big the impact is. But a recompiled version with standardized radius definitions did not solve my MOM6/SIS2 conservation problem.
In case the differing definitions are well intended, this issue can be closed.
The text was updated successfully, but these errors were encountered:
Mass conservation is only possible in the non-Boussinesq mode of MOM6. Most configurations are using the Boussinesq limit which is volume conserving. We monitor volume conservation closely and the model reports the error in the budgets, e.g.:
MOM Date 1/01/01 06:00:00 6: En 7.020957E-01, MaxCFL 0.12679, Mass 1.382931929760E+21, Salt 34.72005686423, Temp 3.59373019872
Total Mass: 1.3829319297597139E+21, Change: -1.2351907382348820E+13 Error: 1.03372E+05 ( 7.5E-17)
MOM Date 1/01/01 12:00:00 12: En 7.075805E-01, MaxCFL 0.14495, Mass 1.382931916797E+21, Salt 34.72005718968, Temp 3.59372786160
Total Mass: 1.3829319167967777E+21, Change: -1.2962935890103574E+13 Error: 3.04646E+05 ( 2.2E-16)
MOM Date 1/01/01 18:00:00 18: En 7.099155E-01, MaxCFL 0.13165, Mass 1.382931906711E+21, Salt 34.72005744291, Temp 3.59372639148
Total Mass: 1.3829319067106112E+21, Change: -1.0086167090303922E+13 Error: 4.07609E+05 ( 2.9E-16)
MOM Date 1/01/02 00:00:00 24: En 7.109936E-01, MaxCFL 0.14788, Mass 1.382931901010E+21, Salt 34.72005758602, Temp 3.59372562877
Total Mass: 1.3829319010101876E+21, Change: -5.7004231177696201E+12 Error: 5.19247E+05 ( 3.8E-16)
If there's a number larger than round-off within the parenthesis then there is a bug within the model component.
The differing radii do not contribute to volume/mass budgets if you are using the FMS coupler. It exchanges extensive quantities which means the model components could have different total surface areas but net mass exchange would still add up to zero. In Boussinesq mode, MOM6 does the conversions between mas/volume so that the coupled always works in mass. We always run MOM6 and SIS2 using the same grid. In coupled mode the grids are usually pre-generated and MOM6/SIS2/icebergs read the same file. Rad_Earth is only used if the models are generating their own grid at run-time. The iceberg Rearth is a metric that will affect changes in position of bergs but does not affect mass conservation. The FMS RADIUS is not used by MOM6/SIS2/icebergs.
Why do you think you have a mass conservation problem?
When trying to trace down the source of mass conservation issues between MOM6 and SIS2, I realized that different definitions for the Earth's radius are used.
Here is an overview of various radius definitions I found when grepping the source code:
SIS2
MOM6
Icebergs
FMS
I am not entirely sure whether these inconsistencies are intentional or not and how big the impact is. But a recompiled version with standardized radius definitions did not solve my MOM6/SIS2 conservation problem.
In case the differing definitions are well intended, this issue can be closed.
The text was updated successfully, but these errors were encountered: