namespace mom

Overview

The central module of the MOM6 ocean model. More…

namespace mom {

// global variables

integer id_clock_ocean;

// global functions

subroutine, public step_mom(
    forces forces,
    fluxes fluxes,
    sfc_state sfc_state,
    Time_start Time_start,
    time_interval time_interval,
    CS CS,
    Waves Waves,
    do_dynamics do_dynamics,
    do_thermodynamics do_thermodynamics,
    start_cycle start_cycle,
    end_cycle end_cycle,
    cycle_length cycle_length,
    reset_therm reset_therm
    );

subroutine, public step_offline(
    forces forces,
    fluxes fluxes,
    sfc_state sfc_state,
    Time_start Time_start,
    time_interval time_interval,
    CS CS
    );

subroutine, public initialize_mom(
    Time Time,
    Time_init Time_init,
    param_file param_file,
    dirs dirs,
    CS CS,
    restart_CSp restart_CSp,
    Time_in Time_in,
    offline_tracer_mode offline_tracer_mode,
    input_restart_file input_restart_file,
    diag_ptr diag_ptr,
    count_calls count_calls,
    tracer_flow_CSp tracer_flow_CSp
    );

subroutine, public finish_mom_initialization(Time Time, dirs dirs, CS CS, restart_CSp restart_CSp);
subroutine, public extract_surface_state(CS CS, sfc_state sfc_state);
logical function, public mom_state_is_synchronized(CS CS, adv_dyn adv_dyn);
subroutine, public get_mom_state_elements(CS CS, G G, GV GV, US US, C_p C_p, use_temp use_temp);

subroutine, public get_ocean_stocks(
    CS CS,
    mass mass,
    heat heat,
    salt salt,
    on_PE_only on_PE_only
    );

subroutine, public mom_end(CS CS);

} // namespace mom

Detailed Documentation

The central module of the MOM6 ocean model.

Modular Ocean Model (MOM) Version 6.0 (MOM6)

Alistair Adcroft, Robert Hallberg, and Stephen Griffies

Additional contributions from:

  • Whit Anderson

  • Brian Arbic

  • Will Cooke

  • Anand Gnanadesikan

  • Matthew Harrison

  • Mehmet Ilicak

  • Laura Jackson

  • Jasmine John

  • John Krasting

  • Zhi Liang

  • Bonnie Samuels

  • Harper Simmons

  • Laurent White

  • Niki Zadeh

MOM ice-shelf code was developed by

  • Daniel Goldberg

  • Robert Hallberg

  • Chris Little

  • Olga Sergienko

Overview of MOM

This program (MOM) simulates the ocean by numerically solving the hydrostatic primitive equations in generalized Lagrangian vertical coordinates, typically tracking stretched pressure (p*) surfaces or following isopycnals in the ocean’s interior, and general orthogonal horizontal coordinates. Unlike earlier versions of MOM, in MOM6 these equations are horizontally discretized on an Arakawa C-grid. (It remains to be seen whether a B-grid dynamic core will be revived in MOM6 at a later date; for now applications requiring a B-grid discretization should use MOM5.1.) MOM6 offers a range of options for the physical parameterizations, from those most appropriate to highly idealized models for geophysical fluid dynamics studies to a rich suite of processes appropriate for realistic ocean simulations. The thermodynamic options typically use conservative temperature and preformed salinity as conservative state variables and a full nonlinear equation of state, but there are also idealized adiabatic configurations of the model that use fixed density layers. Version 6.0 of MOM continues in the long tradition of a commitment to climate-quality ocean simulations embodied in previous versions of MOM, even as it draws extensively on the lessons learned in the development of the Generalized Ocean Layered Dynamics (GOLD) ocean model, which was also primarily developed at NOAA/GFDL. MOM has also benefited tremendously from the FMS infrastructure, which it utilizes and shares with other component models developed at NOAA/GFDL.

When run is isopycnal-coordinate mode, the uppermost few layers are often used to describe a bulk mixed layer, including the effects of penetrating shortwave radiation. Either a split- explicit time stepping scheme or a non-split scheme may be used for the dynamics, while the time stepping may be split (and use different numbers of steps to cover the same interval) for the forcing, the thermodynamics, and for the dynamics. Most of the numerics are second order accurate in space. MOM can run with an absurdly thin minimum layer thickness. A variety of non-isopycnal vertical coordinate options are under development, but all exploit the advantages of a Lagrangian vertical coordinate, as discussed in detail by Adcroft and Hallberg (Ocean Modelling, 2006).

Details of the numerics and physical parameterizations are provided in the appropriate source files. All of the available options are selected at run-time by parsing the input files, usually MOM_input and MOM_override, and the options choices are then documented for each run in MOM_param_docs.

MOM6 integrates the equations forward in time in three distinct phases. In one phase, the dynamic equations for the velocities and layer thicknesses are advanced, capturing the propagation of external and internal inertia-gravity waves, Rossby waves, and other strictly adiabatic processes, including lateral stresses, vertical viscosity and momentum forcing, and interface height diffusion (commonly called Gent-McWilliams diffusion in depth- coordinate models). In the second phase, all tracers are advected and diffused along the layers. The third phase applies diabatic processes, vertical mixing of water properties, and perhaps vertical remapping to cause the layers to track the desired vertical coordinate.

The present file (MOM.F90) orchestrates the main time stepping loops. One time integration option for the dynamics uses a split explicit time stepping scheme to rapidly step the barotropic pressure and velocity fields. The barotropic velocities are averaged over the baroclinic time step before they are used to advect thickness and determine the baroclinic accelerations. As described in Hallberg and Adcroft (2009), a barotropic correction is applied to the time-mean layer velocities to ensure that the sum of the layer transports agrees with the time-mean barotropic transport, thereby ensuring that the estimates of the free surface from the sum of the layer thicknesses agrees with the final free surface height as calculated by the barotropic solver. The barotropic and baroclinic velocities are kept consistent by recalculating the barotropic velocities from the baroclinic transports each time step. This scheme is described in Hallberg, 1997, J. Comp. Phys. 135, 54-65 and in Hallberg and Adcroft, 2009, Ocean Modelling, 29, 15-26.

The other time integration options use non-split time stepping schemes based on the 3-step third order Runge-Kutta scheme described in Matsuno, 1966, J. Met. Soc. Japan, 44, 85-88, or on a two-step quasi-2nd order Runge-Kutta scheme. These are much slower than the split time-stepping scheme, but they are useful for providing a more robust solution for debugging cases where the more complicated split time-stepping scheme may be giving suspect solutions.

There are a range of closure options available. Horizontal velocities are subject to a combination of horizontal biharmonic and Laplacian friction (based on a stress tensor formalism) and a vertical Fickian viscosity (perhaps using the kinematic viscosity of water). The horizontal viscosities may be constant, spatially varying or may be dynamically calculated using Smagorinsky’s approach. A diapycnal diffusion of density and thermodynamic quantities is also allowed, but not required, as is horizontal diffusion of interface heights (akin to the Gent-McWilliams closure of geopotential coordinate models). The diapycnal mixing may use a fixed diffusivity or it may use the shear Richardson number dependent closure, like that described in Jackson et al. (JPO, 2008). When there is diapycnal diffusion, it applies to momentum as well. As this is in addition to the vertical viscosity, the vertical Prandtl always exceeds 1. A refined bulk-mixed layer is often used to describe the planetary boundary layer in realistic ocean simulations.

MOM has a number of noteworthy debugging capabilities. Excessively large velocities are truncated and MOM will stop itself after a number of such instances to keep the model from crashing altogether. This is useful in diagnosing failures, or (by accepting some truncations) it may be useful for getting the model past the adjustment from an ill-balanced initial condition. In addition, all of the accelerations in the columns with excessively large velocities may be directed to a text file. Parallelization errors may be diagnosed using the DEBUG option, which causes extensive checksums to be written out along with comments indicating where in the algorithm the sums originate and what variable is being summed. The point where these checksums differ between runs is usually a good indication of where in the code the problem lies. All of the test cases provided with MOM are routinely tested to ensure that they give bitwise identical results regardless of the domain decomposition, or whether they use static or dynamic memory allocation.

Structure of MOM

About 115 other files of source code and 4 header files comprise the MOM code, although there are several hundred more files that make up the FMS infrastructure upon which MOM is built. Each of the MOM files contains comments documenting what it does, and most of the file names are fairly self-evident. In addition, all subroutines and data types are referenced via a module use, only statement, and the module names are consistent with the file names, so it is not too hard to find the source file for a subroutine.

The typical MOM directory tree is as follows:

../MOM

|– config_src | |– coupled_driver | |– dynamic | `– solo_driver |– examples | |– CM2G | |– … | `– torus_advection_test `– src

|– core |– diagnostics |– equation_of_state |– framework |– ice_shelf |– initialization |– parameterizations | |– lateral | `– vertical |– tracer `– user

Rather than describing each file here, each directory contents will be described to give a broad overview of the MOM code structure.

The directories under config_src contain files that are used for configuring the code, for instance for coupled or ocean-only runs. Only one or two of these directories are used in compiling any, particular run.

  • config_src/coupled_driver: The files here are used to couple MOM as a component in a larger run driven by the FMS coupler. This includes code that converts various forcing fields into the code structures and flux and unit conventions used by MOM, and converts the MOM surface fields back to the forms used by other FMS components.

  • config_src/dynamic: The only file here is the version of MOM_memory.h that is used for dynamic memory configurations of MOM.

  • config_src/solo_driver: The files here are include the _main driver that is used when MOM is configured as an ocean-only model, as well as the files that specify the surface forcing in this configuration.

    The directories under examples provide a large number of working configurations of MOM, along with reference solutions for several different compilers on GFDL’s latest large computer. The versions of MOM_memory.h in these directories need not be used if dynamic memory allocation is desired, and the answers should be unchanged.

    The directories under src contain most of the MOM files. These files are used in every configuration using MOM.

  • src/core: The files here constitute the MOM dynamic core. This directory also includes files with the types that describe the model’s lateral grid and have defined types that are shared across various MOM modules to allow for more succinct and flexible subroutine argument lists.

  • src/diagnostics: The files here calculate various diagnostics that are anciliary to the model itself. While most of these diagnostics do not directly affect the model’s solution, there are some, like the calculation of the deformation radius, that are used in some of the process parameterizations.

  • src/equation_of_state: These files describe the physical properties of sea-water, including both the equation of state and when it freezes.

  • src/framework: These files provide infrastructure utilities for MOM. Many are simply wrappers for capabilities provided by FMS, although others provide capabilities (like the file_parser) that are unique to MOM. When MOM is adapted to use a modeling infrastructure distinct from FMS, most of the required changes are in this directory.

  • src/initialization: These are the files that are used to initialize the MOM grid or provide the initial physical state for MOM. These files are not intended to be modified, but provide a means for calling user-specific initialization code like the examples in src/user.

  • src/parameterizations/lateral: These files implement a number of quasi-lateral (along-layer) process parameterizations, including lateral viscosities, parameterizations of eddy effects, and the calculation of tidal forcing.

  • src/parameterizations/vertical: These files implement a number of vertical mixing or diabatic processes, including the effects of vertical viscosity and code to parameterize the planetary boundary layer. There is a separate driver that orchestrates this portion of the algorithm, and there is a diversity of parameterizations to be found here.

  • src/tracer: These files handle the lateral transport and diffusion of tracers, or are the code to implement various passive tracer packages. Additional tracer packages are readily accommodated.

  • src/user: These are either stub routines that a user could use to change the model’s initial conditions or forcing, or are examples that implement specific test cases. These files can easily be hand edited to create new analytically specified configurations.

Most simulations can be set up by modifying only the files MOM_input, and possibly one or two of the files in src/user. In addition, the diag_table (MOM_diag_table) will commonly be modified to tailor the output to the needs of the question at hand. The FMS utility mkmf works with a file called path_names to build an appropriate makefile, and path_names should be edited to reflect the actual location of the desired source code.

There are 3 publicly visible subroutines in this file (MOM.F90).

  • step_MOM steps MOM over a specified interval of time.

  • MOM_initialize calls initialize and does other initialization that does not warrant user modification.

  • extract_surface_state determines the surface (bulk mixed layer if traditional isoycnal vertical coordinate) properties of the current model state and packages pointers to these fields into an exported structure.

    The remaining subroutines in this file (src/core/MOM.F90) are:

  • find_total_transport determines the barotropic mass transport.

  • register_diags registers many diagnostic fields for the dynamic solver, or of the main model variables.

  • MOM_timing_init initializes various CPU time clocks.

  • write_static_fields writes out various time-invariant fields.

  • set_restart_fields is used to specify those fields that are written to and read from the restart file.

Diagnosing MOM heat budget

Here are some example heat budgets for the ALE version of MOM6.

Depth integrated heat budget

Depth integrated heat budget diagnostic for MOM.

  • OPOTTEMPTEND_2d = T_ADVECTION_XY_2d + OPOTTEMPPMDIFF_2d + HFDS + HFGEOU

  • T_ADVECTION_XY_2d = horizontal advection

  • OPOTTEMPPMDIFF_2d = neutral diffusion

  • HFDS = net surface boundary heat flux

  • HFGEOU = geothermal heat flux

  • HFDS = net surface boundary heat flux entering the ocean = rsntds + rlntds + hfls + hfss + heat_pme + hfsifrazil

  • More heat flux cross-checks

    • hfds = net_heat_coupler + hfsifrazil + heat_pme

    • heat_pme = heat_content_surfwater = heat_content_massin + heat_content_massout = heat_content_fprec + heat_content_cond + heat_content_vprec

      • hfrunoffds + hfevapds + hfrainds

Depth integrated heat budget

Here is an example 3d heat budget diagnostic for MOM.

  • OPOTTEMPTEND = T_ADVECTION_XY + TH_TENDENCY_VERT_REMAP + OPOTTEMPDIFF + OPOTTEMPPMDIFF

    • BOUNDARY_FORCING_HEAT_TENDENCY + FRAZIL_HEAT_TENDENCY

  • OPOTTEMPTEND = net tendency of heat as diagnosed in MOM.F90

  • T_ADVECTION_XY = heating of a cell from lateral advection

  • TH_TENDENCY_VERT_REMAP = heating of a cell from vertical remapping

  • OPOTTEMPDIFF = heating of a cell from diabatic diffusion

  • OPOTTEMPPMDIFF = heating of a cell from neutral diffusion

  • BOUNDARY_FORCING_HEAT_TENDENCY = heating of cell from boundary fluxes

  • FRAZIL_HEAT_TENDENCY = heating of cell from frazil

  • TH_TENDENCY_VERT_REMAP has zero vertical sum, as it redistributes heat in vertical.

  • OPOTTEMPDIFF has zero vertical sum, as it redistributes heat in the vertical.

  • BOUNDARY_FORCING_HEAT_TENDENCY generally has 3d structure, with k > 1 contributions from penetrative shortwave, and from other fluxes for the case when layers are tiny, in which case MOM6 partitions tendencies into k > 1 layers.

  • FRAZIL_HEAT_TENDENCY generally has 3d structure, since MOM6 frazil calculation checks the full ocean column.

  • FRAZIL_HEAT_TENDENCY[k=@sum] = HFSIFRAZIL = column integrated frazil heating.

  • HFDS = FRAZIL_HEAT_TENDENCY[k=@sum] + BOUNDARY_FORCING_HEAT_TENDENCY[k=@sum]

    Here is an example 2d heat budget (depth summed) diagnostic for MOM.

  • OPOTTEMPTEND_2d = T_ADVECTION_XY_2d + OPOTTEMPPMDIFF_2d + HFDS

    Here is an example 3d salt budget diagnostic for MOM.

  • OSALTTEND = S_ADVECTION_XY + SH_TENDENCY_VERT_REMAP + OSALTDIFF + OSALTPMDIFF

    • BOUNDARY_FORCING_SALT_TENDENCY

  • OSALTTEND = net tendency of salt as diagnosed in MOM.F90

  • S_ADVECTION_XY = salt convergence to cell from lateral advection

  • SH_TENDENCY_VERT_REMAP = salt convergence to cell from vertical remapping

  • OSALTDIFF = salt convergence to cell from diabatic diffusion

  • OSALTPMDIFF = salt convergence to cell from neutral diffusion

  • BOUNDARY_FORCING_SALT_TENDENCY = salt convergence to cell from boundary fluxes

  • SH_TENDENCY_VERT_REMAP has zero vertical sum, as it redistributes salt in vertical.

  • OSALTDIFF has zero vertical sum, as it redistributes salt in the vertical.

  • BOUNDARY_FORCING_SALT_TENDENCY generally has 3d structure, with k > 1 contributions from the case when layers are tiny, in which case MOM6 partitions tendencies into k > 1 layers.

  • SFDSI = BOUNDARY_FORCING_SALT_TENDENCY[k=@sum]

    Here is an example 2d salt budget (depth summed) diagnostic for MOM.

  • OSALTTEND_2d = S_ADVECTION_XY_2d + OSALTPMDIFF_2d + SFDSI (+ SALT_FLUX_RESTORE)

Global Variables

integer id_clock_ocean

CPU time clock IDs.

Global Functions

subroutine, public step_mom(
    forces forces,
    fluxes fluxes,
    sfc_state sfc_state,
    Time_start Time_start,
    time_interval time_interval,
    CS CS,
    Waves Waves,
    do_dynamics do_dynamics,
    do_thermodynamics do_thermodynamics,
    start_cycle start_cycle,
    end_cycle end_cycle,
    cycle_length cycle_length,
    reset_therm reset_therm
    )

This subroutine orchestrates the time stepping of MOM. The adiabatic dynamics are stepped by calls to one of the step_MOM_dyn_…routines. The action of lateral processes on tracers occur in calls to advect_tracer and tracer_hordiff. Vertical mixing and possibly remapping occur inside of diabatic.

Parameters:

forces

A structure with the driving mechanical forces

fluxes

A structure with pointers to themodynamic, tracer and mass exchange forcing fields

sfc_state

surface ocean state

time_start

starting time of a segment, as a time type

time_interval

time interval covered by this run segment [s].

cs

control structure from initialize_MOM

waves

An optional pointer to a wave property CS

do_dynamics

Present and false, do not do updates due to the dynamics.

do_thermodynamics

Present and false, do not do updates due to the thermodynamics or remapping.

start_cycle

This indicates whether this call is to be treated as the first call to step_MOM in a time-stepping cycle; missing is like true.

end_cycle

This indicates whether this call is to be treated as the last call to step_MOM in a time-stepping cycle; missing is like true.

cycle_length

The amount of time in a coupled time stepping cycle [s].

reset_therm

This indicates whether the running sums of thermodynamic quantities should be reset. If missing, this is like start_cycle.

 
subroutine, public step_offline(
    forces forces,
    fluxes fluxes,
    sfc_state sfc_state,
    Time_start Time_start,
    time_interval time_interval,
    CS CS
    )

step_offline is the main driver for running tracers offline in MOM6. This has been primarily developed with ALE configurations in mind. Some work has been done in isopycnal configuration, but the work is very preliminary. Some more detail about this capability along with some of the subroutines called here can be found in tracers/MOM_offline_control.F90

Parameters:

forces

A structure with the driving mechanical forces

fluxes

pointers to forcing fields

sfc_state

surface ocean state

time_start

starting time of a segment, as a time type

time_interval

time interval

cs

control structure from initialize_MOM

 
subroutine, public initialize_mom(
    Time Time,
    Time_init Time_init,
    param_file param_file,
    dirs dirs,
    CS CS,
    restart_CSp restart_CSp,
    Time_in Time_in,
    offline_tracer_mode offline_tracer_mode,
    input_restart_file input_restart_file,
    diag_ptr diag_ptr,
    count_calls count_calls,
    tracer_flow_CSp tracer_flow_CSp
    )

Initialize MOM, including memory allocation, setting up parameters and diagnostics, initializing the ocean state variables, and initializing subsidiary modules.

Parameters:

time

model time, set in this routine

time_init

The start time for the coupled model’s calendar

param_file

structure indicating parameter file to parse

dirs

structure with directory paths

cs

pointer set in this routine to MOM control structure

restart_csp

pointer set in this routine to the restart control structure that will be used for MOM.

time_in

time passed to MOM_initialize_state when model is not being started from a restart file

offline_tracer_mode

True is returned if tracers are being run offline

input_restart_file

If present, name of restart file to read

diag_ptr

A pointer set in this routine to the diagnostic regulatory structure

tracer_flow_csp

A pointer set in this routine to

count_calls

If true, nstep_tot counts the number of calls to step_MOM instead of the number of dynamics timesteps.

 
subroutine, public finish_mom_initialization(
    Time Time,
    dirs dirs,
    CS CS,
    restart_CSp restart_CSp
    )

Finishes initializing MOM and writes out the initial conditions.

Parameters:

time

model time, used in this routine

dirs

structure with directory paths

cs

pointer to MOM control structure

restart_csp

pointer to the restart control structure that will be used for MOM.

 
subroutine, public extract_surface_state(CS CS, sfc_state sfc_state)

Set the surface (return) properties of the ocean model by setting the appropriate fields in sfc_state. Unused fields are set to NULL or are unallocated.

Parameters:

cs

Master MOM control structure

sfc_state

transparent ocean surface state structure shared with the calling routine data in this structure is intent out.

 
logical function, public mom_state_is_synchronized(CS CS, adv_dyn adv_dyn)

Return true if all phases of step_MOM are at the same point in time.

Parameters:

cs

MOM control structure

adv_dyn

If present and true, only check whether the advection is up-to-date with the dynamics.

Returns:

True if all phases of the update are synchronized.

subroutine, public get_mom_state_elements(
    CS CS,
    G G,
    GV GV,
    US US,
    C_p C_p,
    use_temp use_temp
    )

This subroutine offers access to values or pointers to other types from within the MOM_control_struct, allowing the MOM_control_struct to be opaque.

Parameters:

cs

MOM control structure

g

structure containing metrics and grid info

gv

structure containing vertical grid info

us

A dimensional unit scaling type

c_p

The heat capacity

use_temp

Indicates whether temperature is a state variable

 
subroutine, public get_ocean_stocks(
    CS CS,
    mass mass,
    heat heat,
    salt salt,
    on_PE_only on_PE_only
    )

Find the global integrals of various quantities.

Parameters:

cs

MOM control structure

heat

The globally integrated integrated ocean heat [J].

salt

The globally integrated integrated ocean salt [kg].

mass

The globally integrated integrated ocean mass [kg].

on_pe_only

If present and true, only sum on the local PE.

 
subroutine, public mom_end(CS CS)

End of ocean model, including memory deallocation.

Parameters:

cs

MOM control structure