Lori Thompson
Lori.Thompson
noaa.gov
Table of Contents
The Modular Ocean Model (MOM) is a numerical representation of the ocean's hydrostatic primitive equations, and it is designed primarily as a tool for studying the global ocean climate system. MOM4 is the latest version of the GFDL ocean model whose origins date back to the pioneering work of Kirk Bryan and Mike Cox in the 1960s-1980s. It is developed and supported by researchers at NOAA's Geophysical Fluid Dynamics Laboratory (GFDL), with contributions also provided by researchers worldwide.
The first release of MOM4 took place January of 2004. There have been three releases of this code: MOM4p0a (Jan 2004), MOM4p0b (March 2004), and MOM4p0c (August 2004). The developers welcome feedback, both positive and negative, on the code's integrity and portability. It is through such feedback that the code evolves and becomes more robust and user friendly.
The purpose of this web page is to provide general information about MOM4 and particular information for how to download and run the code.
MOM4 users can acquire the source code and associated datasets from GForge, and are required to register at the GFDL GForge location. Therefore, users need to register only once to get both the source code and datasets of MOM4. More details can be found in the quickstart_guide.html.
Email concerning MOM4 should be directed to the
mom4-email list located at oar.gfdl.mom4p0noaa.gov. All
questions, comments, and suggestions are to be referred
to this list. An archive of all emails is maintained at
the mom4 email archive. A subject-organized archive of
the emails is available at mom4p0_email.html. Note that by
registering at GForge to access the code, you are
automatically subscribed to the email list.
There have been three releases of MOM4p0: (1) MOM4p0a was released January 2004, (2) MOM4p0b was released March 2004, and (3) MOM4p0c was released August 2004. Each release is documented on this web page.
There are two major algorithm issues that are being addressed by GFDL developers. (1) Generalized quasi-Eulerian vertical coordinates are being implemented in MOM4. (2) Two-way nesting is being considered for MOM. It is hopled that both of these new features will be available in MOM4p1 (late 2004 or early 2005).
Each release of MOM4 has identified portability and efficiency issues. In particular, use of MOM4 on the SGI Origin machine used at GFDL saw a sizable reduction in efficiency relative to similar experiments with MOM3.1. Research identified the use of array syntax for dynamically allocated arrays to be at the root of the problem. Compiling the model with static allocation (array sizes specified at compile time) leads to a factor of two speed-up relative to the default dynamic allocation (array sizes allocated at run-time). We are unaware of whether similar behaviour exists on other computer platforms. Compiler engineers at SGI are presently addressing the issues, with the hoped-for result being the elimination of the compiler "feature" leading to the slow-down. Until then, MOM4 will maintain the ability to run with either static or dynamically allocated arrays. The distinction is facilitated by a cpp-preprocessor option, with dynamical allocation the default.
In addition to this user guide, documentation for MOM4 is provided by two LaTeX generated postscript documents:
-
A Technical Guide to MOM4 by Stephen.Griffiesnoaa.gov, Matthew.Harrisonnoaa.gov, Ronald.Pacanowskinoaa.gov, and Tony.Rosatinoaa.gov. This
is the primary reference for MOM4. It contains
details about some of the numerical algorithms and
diagnostics. All usage of MOM4 in the literature
should refer to this document:
A Technical Guide to MOM4
GFDL Ocean Group Technical Report No. 5
S.M. Griffies, M.J. Harrison, R.C. Pacanowski, and A. Rosati
NOAA/Geophysical Fluid Dynamics Laboratory
Available on-line at http://www.gfdl.noaa.gov/~fms.
- A theoretical rationalization of ocean climate models is provided by Fundamentals of Ocean Climate Models. This book has been published by Princeton University Press, August 2004.
Although MOM4 shares much in common with earlier versions of MOM, it possesses a number of computational, numerical, and physical characteristics that are noteworthy. The following provides an overview of the main characteristics of MOM4 (please refer to A Technical Guide to MOM4 for references).
Computational characteristics of MOM4 include the following.
- MOM4 is coded in Fortran 90 and physical units are MKS.
- MOM4 meets the code standards set by the GFDL Flexible Modeling System (FMS). It also utilizes a substantial number of software infrastructure modules shared by other FMS-based models. In particular, all I/O (e.g., restarts, forcing fields, initial fields) is handled via NetCDF.
- There is only a single cpp-preprocessor option (i.e., ifdefs) associated with the handling of memory in the model. All options for physical and dynamical choices are handled via namelists and/or switching in/out of modules at compile time. Removing ifdefs allows for more readable code that possesses a higher level of error checker handling.
- 2D (latitudinal/longitudinal) horizontal domain decomposition is used for single or multiple parallel processors. Correspondingly, 3D arrays are dimensioned (i,j,k) instead of (i,k,j) used in earlier MOMs. MOM4 has no memory window or slabs.
Numerical and kinematic/dynamic characteristics of MOM4 include the following.
- Generalized orthogonal horizontal coordinates are used. GFDL is supporting both the standard spherical coordinates as well as the ''tripolar'' grid of Murray (1996). Details are provided in A Technical Guide to MOM4.
- Bottom topography is represented using the partial cells of Pacanowski and Gnanadesikan (1998). The older full cell approach is available as a namelist in the preprocessing code used to generate the grid specification file.
- The dynamics/kinematics for MOM4p0a and MOM4p0b are based on the non-Boussinesq method of Greatbatch et al. (2002). The Boussinesq option is available via a namelist. This option was jettisoned in MOM4p0c for purposes of code brevity, and in anticipation of using pressure coordinates in MOM4p1 to realize non-Boussinesq dynamics.
- The time tendency for tracer and baroclinic velocity can be discretized two ways. (1) The first approach uses the traditional leap-frog method along with a Robert-Asselin time filter. Note that the Euler forward or Euler backward mixing time step used in earlier MOMs has been eliminated. This method is avalable in MOM4p0a, MOM4p0b and MOM4p0c. (2) MOM4p0c provides an additional method, which is strongly recommended. Here, the time tendency is discretized with a two-level forward step, which eliminates the need to time filter. Tracer and velocity are staggered in time, thus providing second order accuracy in time. For certain model configurations, this scheme is roughly twice as stable as the leap-frog, thus allowing for a factor of two in computational savings. Without the time filtering needed with the leap-frog, the new scheme conserves total tracer to within numerical roundoff. This scheme shares much in common with time stepping used in the Hallberg Isopycnal Model and the MIT GCM. It is the default in MOM4p0c. Details of both the leap-frog and two-level schemes are provided in Fundamentals of Ocean Climate Models.
- The sole external mode solver is a variant of the Griffies et al. (2001) explicit free surface. There are two time stepping schemes supported: (1) leap-frog and (2) predictor-corrector. The predictor-corrector is more stable and is thus the default method. Top model grid cells have time dependent volume, thus allowing for total tracer to be conserved to within roundoff. The linearized free surface method used in MOM3 (and many other implementations of the free surface in z-models) has been jettisoned since it precludes tracer conservation. Details are provided in Fundamentals of Ocean Climate Models.
- McDougall et al. (2003) equation of state has been implemented, with in situ density a function of the local potential temperature, salinity, and hydrostatic pressure (baroclinic pressure plus free surface pressure plus applied pressure from the atmosphere and sea ice). Details are provided in Fundamentals of Ocean Climate Models.
- Tracer advection is available using various schemes. The centered 2nd, 4th, 6th order schemes are available, as documented in The MOM3 Manual of Pacanowski and Griffies (1999). The 4th and 6th order schemes assume constant grid spacing, which simplifies the code though compromises accuracy on the more commonly used non-uniform grids. The Quicker scheme documented by Holland et al. (1998) and The MOM3 Manual is available. Finally, two multi-dimensional flux limited schemes have been ported from the MIT GCM. These schemes are monotonic and have been found to be roughly the same cost as the Quicker scheme. GFDL researchers have found the Sweby scheme to be most satisfying for many applications, such as biogeochemistry. Hence, effort has been made to enhance this scheme's efficiency in MOM4p0c. Other schemes remain much as they were with the MOM4p0a release.
- Tidal forcing from the various lunar and solar components are available to force the free ocean surface.
- Open boundary conditions are available to allow open boundaries in either of the north, south, east, or west directions.
Physical parameterizations available in MOM4 include the following.
- Neutral tracer physics includes Redi neutral diffusion according to Griffies et al. (1998), and Gent-McWilliams stirring according to the Griffies (1998) skew-flux method. Two-dimensional flow dependent diffusivities are available and can be determined in many different ways, such as the depth integrated Eady growth rate and Rossby radius of deformation, as motivated by the ideas of Held and Larichev (1996) and Visbeck et al. (1997). Details are provided in Fundamentals of Ocean Climate Models.
- Vertical mixing schemes include the time-independent depth profile of Bryan and Lewis (1979), the Richardson number dependent scheme of Pacanowski and Philander (1981), and the KPP scheme of Large et al. (1994).
- Horizontal friction schemes include uniform and grid dependent viscosity schemes, as well as the shear-dependent Smagorinsky viscosity according to Griffies and Hallberg (2000). The anisotropic scheme of Large et al. (2001) and Smith and McWilliams (2002) has been implemented. Details are provided in Fundamentals of Ocean Climate Models.
- Topographically oriented tracer diffusion introduces enhanced diffusion when heavy parcels are above lighter parcels. It is implemented according to the ideas of Beckmann and Döscher (1997) and Döscher and Beckmann(1999). Details are provided in A Technical Guide to MOM4.
- The "overflow" scheme of Campin and Goosse (1999) has been implemented, whereby gravitationally unstable fluid parcels are allowed to move downslope via an upwind advection scheme.
- Penetration of shortwave radiative heating into the upper ocean is generally attenuated by the inclusion of chlorophyll data.
Miscellaneous features of the code released with MOM4 include the following.
- MOM4 comes with three tracer packages: (1) ideal age tracer (2) tracers for the OCMIP biotic protocol (3) CFC tracers. Additionally, a suite of code is available for handling tracers inside MOM4 and FMS shared code (field_manager). This code provides the user with many options for adding new tracer packages, ecosystem models, etc.
- MOM4 has numerous diagnostics for checking algorithm and solution integrity. These diagnostics include budgets for energetic consistency, tracer conservation, solution stability, etc. Additional diagnostics are available for numerous fields of relevance to the different physics schemes, as well as term balances.
- MOM4 is distributed with a prognostic sea ice model (SIS) via mom4_test4 and mom4_test5.
- As a forward model, MOM4 is compatible with the most recent automatic differentiation tool of Ralf Giering and Thomas Kaminski. See their FastOpt home page at http://www.FastOpt.com/frameset.html for more details.
MOM4 has been coded within GFDL's Flexible Modeling System (FMS). Doing so allows for MOM4 developers to use numerous FMS infrastructure and superstructure modules that are shared amongst various atmospheric, ocean, sea ice, land, vegetative, etc. models. Common standards and shared software tools facilitate the development of high-end earth system models, which necessarily involves a wide variety of researchers working on different computational platforms. Such standards also foster efficient input from computational scientists and engineers as they can more readily focus on common computational issues.
The following list represents a sample of the FMS shared modules used by MOM4.
- time manager: keeps model time and sets time dependent flags
- coupler: used to couple MOM4 to other component models
- I/O : to read and write data in either NetCDF, ASCII, or native formats
- parallelization tools: for passing messages across parallel processors
- diagnostic manager: to register and send fields to be written to a file for later analysis
- field manager: for integrating multiple tracers and organizing their names, boundary conditions, and advection schemes
The FMS infrastructure (the "Khartoum version") has been released to the public on GForge, with further releases every few months.
The Flexible Modeling System ( FMS) is free software; you can redistribute it and/or modify it and are expected to follow the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
FMS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with MOM4; if not, write to:
Free Software Foundation, Inc.
59 Temple Place, Suite 330
Boston, MA 02111-1307
USA
or see: http://www.gnu.org/licenses/gpl.html
MOM4 is distributed with a set of test cases located in mom4/exp/. These tests are taken from models used at GFDL for testing the numerical and computational integrity of the code.
![[Warning]](images/warning.gif) |
Warning |
|---|---|
| These experiments are NOT sanctioned for their physical relevance. They are instead provided for the user to learn how to run MOM4, and to verify the numerical and/or computational integrity of the code. PLEASE do not assume that the experiments will run for more than the short time selected in the sample runscripts. | |
mom4_test1: This experiment consists of a flat bottom sector domain and uses very simple physics. This experiment is very small and can be easily run on a single workstation. It should provide the user with a basic experience of running mom4.
mom4_test2: This experiment consists of a flat bottom sector domain and it uses more realistic physics options. This experiment has the same grid as test1, but it more thoroughly exercises the model's various physics packages. Since the domain is small, it should be accessible to those with single workstations, though it will be slower than mom4_test1 due to the use of more realistic physical parameterizations.
mom4_test3A: This experiment consists of an east-west channel using open boundary conditions at the western end of the channel. This experiment provides an illustration of the open boundary condition capability of MOM4. Tracers include potential temperature and salinity.
mom4_test3B: This experiment consists of an solid wall on all four sides and with a domain twice as long as the open boundary condition test3A. This experiment is used to verify the relevance of the open boundary solution from test3A solution at early times. That is, for early times, the solution from test3A should closely (though not bitwise) agree with that from test3B. Tracers include potential temperature and salinity.
mom4_test4: This model uses a global tripolar grid with roughly "3-degree" resolution and 28 vertical levels. The ocean is coupled to the GFDL sea ice model. Tracers include temperature and salinity, as well as the age, OCMIP biotic, and cfc tracer packages. This model is aimed to test the capabilities of the multipe tracers available with mom4. Note that the Sweby advection scheme is used here for all tracers, as is recommended by GFDL researchers.
mom4_test5: This model uses a global tripolar grid with roughly "1-degree" resolution and 50 vertical levels. The ocean is coupled to the GFDL sea ice model. The configuration is forced with the German OMIP dataset. Ocean tracers include potential temperature and salinity as well as the age tracer package. This is a large model, and it is similar (though not the same) to the ocean and ice configuration used for the GFDL IPCC simulations.
mom4_iom: This is Indian Ocean Community Model version 1.0 developed for Intensive Course on Ocean Modeling held at CMMACS, India, October 4-14, 2004.
As with previous MOMs, the GFDL-MOM4 developers aim to provide the international climate research community with a repository for robust and well documented methods to simulate the ocean climate system. Consequently, we encourage researchers to support various modules that are presently absent from MOM4, yet may arguably enhance the simulation integrity (e.g., a new physical parameterization or new advection scheme) or increase the model's functionality.
Depending on the level of code contributions, we envision a directory where "contributed MOM4 code" will reside. Maintenance and ownership of this code will remain with the contributor. As a practical matter, prior to spending time developing a new module, it is recommended that the developer query the MOM4 mailing list to see what efforts in the community may have already been availed.
Requirements that contributed code must meet include the following:
- Clean modular Fortran 90 code that minimally touches other parts of the model
- Satisfaction of the FMS code specifications outlined in the FMS Developers' Manual
- Compatibility with the MOM4 test cases
- Thorough and pedagogical documentation of the module for inclusion in A Technical Guide to MOM4 (a Latex document)
- Comments within the code emulating other parts of the model so that HTML documentation files can be generated by our converter
The FMS development team uses a local implementation of GForge to serve FMS software, located at http://fms.gfdl.noaa.gov. In order to obtain the source code and data sets, you must register as an FMS user on our software server. After submitting the registration form on the software server, you should receive an automatically generated confirmation email within a few minutes. Clicking on the link in the email confirms the creation of your account.
After your account has been created, you should log in and request access to the Flexible Modeling System project. Once the FMS project administrator grants you access, you will receive a second email notification. This email requires action on the part of the project administrator and thus may take longer to arrive. The email will contain a software access password along with instructions for obtaining the release package, which are described below.
To check out the release package containing source code, scripts, and documentation via CVS, type the following commands into a shell window. You might wish to first create a directory called fms in which to run these commands. You should enter the software access password when prompted by the cvs login command. At cvs login, the file ~/.cvspass is read. If this file does not already exist, an error message may display and the cvs login may fail. In this event, you should first create this file via touch ~/.cvspass.
cvs -z3 -d:pserver:cvs@fms.gfdl.noaa.gov:/cvsroot/mom4 login
(Enter the password you receive in the welcome email here)
cvs -z3 -d:pserver:cvs@fms.gfdl.noaa.gov:/cvsroot/mom4 co -r mom4p0c mom4
This will create a directory called mom4 in your current working directory containing the release package.
If you have already checked out this CVS tag previously and some files have been modified since your last checkout you may wish to update your code as follows:
cvs -z3 -d:pserver:cvs@fms.gfdl.noaa.gov:/cvsroot/mom4 login
(Enter the password you receive in the welcome email here)
cvs -z3 -d:pserver:cvs@fms.gfdl.noaa.gov:/cvsroot/mom4 update -r mom4p0c mom4
If you prefer not to use CVS, you may download the tar file from https://fms.gfdl.noaa.gov/projects/mom4/. Sample output is also available there for download. See Section 7.1, “Sample model output” for more information on the sample output.
All data sets that are needed to run MOM4 test cases are available for download from the same place in GForge where users get the source code. Therefore, users need to register only once to get both the source code and data sets of MOM4. More details can be found in the quickstart_guide.html.
The topography data set for test4, and test5 is a coarsened version of that kindly provided by Andrew Coward and David Webb at the Southampton Oceanography Centre. Their topography is a montage of that developed by Smith and Sandwell (1997) by satellite data in the region of 72°S to 72°N, the NOAA (1988) 5-minute global topography ETOPO5, and the International Bathymetric Chart of the Arctic Ocean (IBCAO). The chlorophyll-a density data set was compiled by Colm Sweeney, using data from James A. Yoder and Maureen A. Kennelly at the Graduate School of Oceanography, University of Rhode Island. This data set contains monthly chlorophyll concentrations from the SeaWiFS satellite for the period 1999-2001. Monthly wind stress is based on Hellerman and Rosenstein (1983). Temperature and salinity initial and boundary conditions are provided by the NOAA National Oceanographic Data Center (NODC) World Ocean Atlas (WOA).
All datasets of MOM4 are in NetCDF format since this format is widely used in the community. A number of useful tools are available here that allow the user to perform some necessary operations (editting attributes, merging, etc.) on a NetCDF file.
The grid_spec.nc file is generated by executing the make_xgrids utility. make_xgrids generates the two exchange grids used by the FMS coupler, one for surface fluxes and the other for runoff, when the simulation requires an atmospheric grid different from the sample exchange grids provided by FMS. make_xgrids is created by compiling its C source, for example:
cc -O -o make_xgrids make_xgrids.c -L/usr/local/lib -lnetcdf -lm
creates the make_xgrids executable from C-source and the netCDF and standard math libraries and is executed with the command:
make_xgrids -o LON2.5LAT2LONLAT.nc -a N45.nc -l N45.nc
which makes a grid_spec.nc file (input files containing grid information for the ocean/sea-ice, atmosphere and land component models are indicated by the -o, -a and -l flags, respectively). make_xgrids expect a netCDF format input specification for the ice/ocean grid ( LON2.5LAT2LONLAT.nc in the above example). Three fields are required to be in this file:
- wet - a 2D array of double precision numbers set to 1.0 where the ice and ocean models are active and 0.0 elsewhere. wet has im indices in the i (pseudo east-west) direction and jm indices in the j (pseudo north-south) direction. These correspond to the global arrays of temperature, salinity and ice thickness in the coupled climate model.
- x_vert_T and y_vert_T - 2D double precision arrays (dimensioned im+1 by jm+1) that contain the longitudes and latitudes (respectively) of the four corners of T- cells in degrees.
make_xgrids also expects a netCDF format input specification for the atmosphere and land grid (N45.nc in the above example). x_vert_T and y_vert_t are required in the atmosphere/land grid file (N45.nc). make_xgrids copies all fields of the ice/ocean grid specification file to its output file, grid_spec.nc, and then appends fields that specify the atmosphere and land model grids and the surface and runoff exchange grids.
make_xgrids
takes care that the land and ocean grids perfectly tile
the sphere. The land model's domain is defined as the
part of the sphere not covered by ocean (where wet = 0 on
the ocean grid). To accomplish this, the land cells must
be modified to remove the ocean parts. This is done in
make_xgrids by first
taking the intersections of atmosphere and land cells.
The overlap area between these cells and active ocean
cells are then subtracted. Finally, the modified
atmosphere/land intersections are aggregated into land
cell areas and atmosphere/land exchange cell areas.
Model cell intersections are calculated using the Sutherland-Hodgeman polygon clipping algorithm (Sutherland, I. E. and G. W. Hodgeman, 1974: Reentrant polygon clipping, CACM, 17(1), 32-42.). This algorithm finds the intersection of a convex and arbitrary polygon by successively removing the portion of the latter that is "outside" each boundary of the former. It can be found in many computer graphics text books (e.g., Foley, J. D., A. van Dam, S. K. Feiner, and J. F. Hughes, 1990: Computer graphics: principles and practice, second edition. Addison Wesley, 1174 pp.). The implementation in make_xgrids is particularly simple because the clipping polygon is always a rectangle in longitude/latitude space. For the purpose of finding the line intersections in the clipping operations, the cell boundaries are assumed to be straight lines in longitude/latitude space. This treatment is only perfectly accurate for cells bounded by lines of longitude and latitude.
Spherical areas are calculated by taking the integral of the negative sine of latitude around the boundary of a polygon (Jones, P. W., 1999: First- and second-order conservative remapping schemes for grids in spherical coordinates. Monthly Weather Review, 127, 2204-2210.). The integration pathways are again straight lines in longitude/latitude space. make_xgrids checks that the sphere and the individual cells of the atmosphere and ocean grids are tiled by the surface exchange cells. The fractional tiling errors are reported.
A runscript is provided in each test case directory (mom4/exp/$test_case ) for each test case. Details can be found in quickstart_guide.html.
Incorporated in the FMS infrastructure is MPP (Massively Parallel Processing), which provides a uniform message-passing API interface to the different message-passing libraries. If MPICH is installed, the user can compile the MOM4 source code with MPI. If the user does not have MPICH or the communications library, the MOM4 source code can be compiled without MPI by omitting the CPPFLAGS value -Duse_libMPI in the example runscript.
The diagnostics table allows users to specify the sampling rates and choose the output fields prior to executing the MOM4 source code. It is included in the input directory for each test case (mom4/exp/$test_case/input). A portion of a sample MOM4 diagnostic table is displayed below. Reference diag_manager.html for detailed information on the use of diag_manager.
"Diagnostics for MOM4 test case"
1980 1 1 0 0 0
#output files
"ocean_month",1,"months",1,"hours","Time"
"ocean_snap",1,"days",1,"hours","Time"
#####diagnostic field entries####
#===============================================================
# ocean model grid quantities (static fields and so not time averaged))
"ocean_model","geolon_t","geolon_t","ocean_month" "all",.false.,"none",2
"ocean_model","geolat_t","geolat_t","ocean_month","all",.false.,"none",2
#================================================================
# prognostic fields
"ocean_model","temp","temp","ocean_month","all", "max", "none",2
"ocean_model","age_global","age_global","ocean_month","all","min","none",2
#================================================================
# diagnosing tracer transport
"ocean_model","temp_xflux_sigma","temp_xflux_sigma","ocean_month","all",.true.,"none",2
"ocean_model","temp_yflux_sigma","temp_yflux_sigma","ocean_month","all",.true.,"none",2
#================================================================
# surface forcing
"ocean_model","sfc_hflux","sfc_hflux","ocean_month","all",.true.,"none",2
"ocean_model","sfc_hflux_adj","sfc_hflux_adj","ocean_month","all",.true.,"none",2
#================================================================
# ice model fields
"ice_model", "FRAZIL", "FRAZIL", "ice_month", "all", .true., "none", 2,
"ice_model", "HI", "HI", "ice_month", "all", .true., "none", 2
#-----------------------------------------------------------------
The diagnostics manager module, diag_manager_mod, is a set of simple calls for parallel diagnostics on distributed systems. It provides a convenient set of interfaces for writing data to disk in NetCDF format. The diagnostics manager is packaged with the MOM4 source code. The FMS diagnostic manager can handle scalar fields as well as arrays. For more information on the diagnostics manager, reference diag_manager.html.
The MOM4 field table is used to specify tracers and their advection schemes, cross-land tracer mixing and checkerboard smoothing. The field table is included in the runscript as a namelist and is written to an output file upon execution of the runscript.
"diag_tracers","ocean_mod","frazil" file_in = INPUT/ocean_frazil.res.nc file_out = RESTART/ocean_frazil.res.nc /
"prog_tracers","ocean_mod","temp" horizontal-advection-scheme = quicker vertical-advection-scheme = quicker file_in = INPUT/ocean_temp_salt.res.nc file_out = RESTART/ocean_temp_salt.res.nc /
"prog_tracers","ocean_mod","salt" horizontal-advection-scheme = mdfl_sweby vertical-advection-scheme = mdfl_sweby file_in = INPUT/ocean_temp_salt.res.nc file_out = RESTART/ocean_temp_salt.res.nc /
"tracer_packages","ocean_mod","ocean_age_tracer" names = global horizontal-advection-scheme = mdfl_sweby vertical-advection-scheme = mdfl_sweby file_in = INPUT/ocean_age.res.nc file_out = RESTART/ocean_age.res.nc min_tracer_limit=0.0 /
"namelists","ocean_mod","ocean_age_tracer/global" slat = -90.0 nlat = 90.0 wlon = 0.0 elon = 360.0 /
In the first section of the field table, the user can specify tracers to be used in the simulation. Although there is no limit to the number of tracers specified, temperature (temp) and salinity (salt) must be included. The user may also define the horizontal and vertical tracer advection schemes. For more information on the field manager, reference field_manager.html.
In climate modeling, it is often necessary to allow water masses that are separated by land to exchange tracer and surface height properties. This situation arises in models when the grid mesh is too coarse to resolve narrow passageways that in reality provide crucial connections between water masses. The cross-land mixing establishes communication between bodies of water separated by land. The communication consists of mixing tracers and volume between non-adjacent water columns. Momentum is not mixed. The scheme conserves total tracer content, total volume, and maintains compatibility between the tracer and volume budgets.
Discretization of gravity waves on a B-grid can admit a stationary grid scale checkerboard pattern (e.g., Killworth et al., 1991). This pattern is associated with an unsuppressed grid splitting that can be initiated through grid scale forcing, such as topography, or indeed any forcing that projects onto the grid scale, such as fresh water forcing. The field table contains specifications for selectively enhancing the smoothing provided by the ocean_checkerboard.F90 module.
For a technical description of cross-land tracer mixing and checkerboard null mode, please reference A Technical Guide to MOM4.
Running the MOM4 source code in a parallel processing environment will produce one output NetCDF diagnostic file per processor. mppnccombine joins together an arbitrary number of data files containing chunks of a decomposed domain into a unified NetCDF file. If the user is running the source code on one processor, the domain is not decomposed and there is only one data file. mppnccombine will still copy the full contents of the data file, but this is inefficient and mppnccombine should not be used in this case. Executing mppnccombine is automated through the runscripts. The data files are NetCDF format for now, but IEEE binary may be supported in the future.
mppnccombine requires decomposed dimensions in each file to have a domain_decomposition attribute. This attribute contains four integer values: starting value of the entire non-decomposed dimension range (usually 1), ending value of the entire non-decomposed dimension range, starting value of the current chunk's dimension range and ending value of the current chunk's dimension range. mppnccombine also requires that each file have a NumFilesInSet global attribute which contains a single integer value representing the total number of chunks (i.e., files) to combine.
The syntax of mppnccombine is:
mppnccombine [-v] [-a] [-r] output.nc [input ...]
Table 1. mppnccombine arguments
| -v | print some progress information |
| -a | append to an existing NetCDF file |
| -r | remove the '.####' decomposed files after a successful\ run |
An output file must be specified and it is assumed to be the first filename argument. If the output file already exists, then it will not be modified unless the option is chosen to append to it. If no input files are specified, their names will be based on the name of the output file plus the extensions '.0000', '.0001', etc. If input files are specified, they are assumed to be absolute filenames. A value of 0 is returned if execution is completed successfully and a value of 1 indicates otherwise.
The source of mppnccombine is packaged with the MOM4 module in the postprocessing directory. mppnccombine.c should be compiled on the platform where the user intends to run the FMS MOM4 source code so the runscript can call it. A C compiler and NetCDF library are required for compiling mppnccombine.c:
cc -O -o mppnccombine -I/usr/local/include -L/usr/local/lib mppnccombine.c -lnetcdf
Sample MOM4 model output data files are available to registered MOM4 users on GFDL's NOMADS server. The output data are organized into directories that bear the same names as the test cases . For example, output for test case test5 can be found in directory test5. Output files are classified into three subdirectories:
- ascii: the description of the setup of the run and verbose comments printed out during the run.
- restart: the model fields necessary to initialize future runs of the model.
- history: output of the model, both averaged over specified time intervals and snapshots.
Note that these output files are compressed using tar. All .tar files should be decompressed for viewing. The decompress command is:
tar -xvf filename.tar
There are several graphical packages available to display the model output. These packages vary widely depending on factors, such as the number of dimensions, the amount and complexity of options available and the output data format. The data will first have to be put into a common format that all the packages can read. FMS requires the data to be stored in NetCDF format since it is so widely supported for scientific visualization. The graphical package is also dependent upon the computing environment. For ocean modeling, ncview, Ferret and GrADS are most commonly used.
This is a list of files modified in March/April 2004 for the MOM4p0b release of MOM4.
| shared/exchange/xgrid.f90: | Minor edits to make the code compliant with IFC version 8. |
| ice_param/ocean_albedo.f90: | Minor edits to make the code compliant with IFC version 8. |
| shared/column_diagnostics/column_diagnostics.f90: | Minor edits to make the code compliant with IFC version 8. |
| shared/horiz_interp/horiz_interp.f90: | Change the step size of radial search from 1 to 100. This will improve the efficiency and a workaround to fix a bug. |
| preprocessing/generate_grids/ocean/topog.f90: | Modify io format to fix one error message. |
| preprocessing/generate_grids/ocean/ocean_grid_generator.csh: | Minor comments update |
| shared/mpp/mpp_io.F90: | Added optional argument "time_method" to write_meta_field subroutine. This is used by diag_manager to document how a diagnostic is manipulated along the time axis, e.g. averaging, max, min. The metadata used are compliant with CF1.0 metadata standard. |
| shared/mpp/mpp_read_2Ddecomp.h: | Bug fix for lenx and leny variables |
| shared/diag_manager: | In addition to time average now users can have min, max in the same time period. |
| coupler/coupler_main.f90: | Replace constant number 2 with parameter variable FATAL in error message. |
| drivers/ocean_solo.F90: | Remove redundant mpp_clock for Ocean. |
| postprocessing/regrid: | using netcdf library to read and write data, instead of using mpp_io_mod. Added vertical interpolation. Add namelist do_laplace_extrap to improve efficiency when doing vertical interpolation. |
| ocean_core/ocean_domains.F90: | Added (len=*) for variable name in subroutine set_ocean_domain. |
| ocean_core/ocean_velocity_advect.F90: | Corrected bug identified by Pacanowski. For bottom partial cells with k=nk, the vertical advection of horizontal velocity was a factor of 2 too large. A mask has been added to correct this bug. |
| ocean_core/ocean_grids.F90: | Send to diagnostics for area_u had id_area_t in send_data, trivial bug. |
| ocean_core/ocean_topog.F90: | Added nml for flat_bottom for use in helping to debug problems related to bottom topography. |
| ocean_core/ocean_freesurf.F90: | Added nml option to have eta_t = 0.0 at the initial condition. This is useful when have restart files that have nonzero eta, and wish to debug without changing the restart files. Added nml option check_volume_conserve for debugging purposes. |
| ocean_param/mixing/vert/kpp/ocean_vert_mix_coeff.F90: | Removed the tidal_mix option as this remains a topic of research. |
| ocean_param/mixing/neutral/ocean_neutral_physics.F90: | Unified the calculation of the surface boundary layer. Now include information about the KPP boundary layer in the computation of the "neutral physics boundary layer". |
| ocean_tracers/ocmip2_biotic.F90: | Corrected bug identified by John Dunne. Bug fix necessary to keep model from bombing. |
| ocean_param/sources/sponge/ocean_sponges.F90: | Removed code that inverted the input sponge coefficients. The input sponge_coeff NetCDF file should now give these coefficients in inverse seconds, rather than in seconds. Reasoning: (1) matches the documentation; (2) more intuitively linked to the name "sponge_coeff," with a large coeff implying a strong sponge; and (3) allows tapering of sponge coefficients to exactly zero. |
| shared/mpp_domains.F90: | Bug fix for C grid case, does not affect MOM4 since MOM4 runs on B grid. |
| shared/mpp_update_domains2D.h: | Bug fix for C grid case, does not affect MOM4 since MOM4 runs on B grid. |
The following lists some new features of the MOM4p0c release in August 2004.
|
Warning |
|---|---|
|
|
New or modified algorithms available in MOM4p0c
- The time tendency for tracer and baroclinic velocity can be discretized two ways. (1) The first approach uses the traditional leap-frog method along with a Robert-Asselin time filter. (2) MOM4p0c provides an additional method, which is strongly recommended. Here, the time tendency is discretized with a two-level forward step, which eliminates the need to time filter. Tracer and velocity are staggered in time, thus providing second order accuracy in time. For certain model configurations, this scheme is roughly twice as stable as the leap-frog, thus allowing for a factor of two in computational savings. Without the time filtering needed with the leap-frog, the new scheme conserves total tracer to within numerical roundoff. Extensive tests indicate that the simulations are quite similar qualitatively and quantitatively to those run with the leap-frog scheme. However, the user is encouraged to verify such prior to moving forward with the new time stepping scheme. Note that the new scheme shares much in common with time stepping used in the Hallberg Isopycnal Model and the MIT GCM. This new scheme is the default in MOM4p0c.
- The barotropic mode can be updated using either the older leap-frog method, or a newer defaulted predictor-corrector method motivated by a similar method used in the Hallberg Isopycnal Model.
- Thickness weighted tracer concentration and thickness weighted baroclinic velocity are updated, rather than tracer concentration and velocity. This new approach provides simpler conservation budgets, in which there is no longer a source-like term associated with the time tendency of the surface height.
- Optimizations have been implemented to reduce array syntax and to improve parallelization. This work is ongoing, with assistance from the MOM4 user community greatly appreciated.
- A new derived type has been introduced: ocean_thickness_type. This type absorbs elements of the ocean_grid_type that invove time dependent thicknesses of layers. It is anticipated that this type will expand in the future as MOM4 evolves towards generalized vertical coordinates. This change required interfaces changes.
- The Time derived type has been removed from the other derived types in order to simplify the definitions of the types. This change required interfaces changes.
- The non-Boussinesq option has been jettisoned in order to simplify some of the code. It is anticipated that the next release of MOM4 will be MOM4p1 (late 2004 or early 2005), and this code will include a pressure-coordinate option to allow for simpler implementation of non-Boussinesq kinematics/dynamics.
Corrected algorithms in MOM4p0c
- The shortwave fraction computed in mom4/ocean_param/sources/shortwave/ocean_shortwave_pen.F90 was not constrained to monotonically decrease with depth. In some cases, the fraction could spuriously increase. A new nml logical has been introduced: enforce_sw_frac. The default of this logical is true.
- Tidal forcing in mom4/ocean_core/ocean_freesurf.F90 has been corrected. The older code had problems with the phases.
New features of the FMS infrastructure
- Extensive work has been included to enhance the portability and flexibility of FMS codes. This work is ongoing, with assistance from the MOM4 user community greatly appreciated.
- The new version of shared/time_manager.f90 requires that every dataset with a time dimension also have a calendar attribute associated with this time. This new attribute is now required because problems were found with the old time manager when running the model assuming a repeating annual cycle using the NOLEAP calendar type, yet without the datasets also having this calendar type. A spurious shift in the date accumulated over time, which caused shifts in the forcing relative to what the model intended. The calendar attribute is missing from many datasets released with mom4p0a and mom4p0b. Since the missing of calendar attribute would cause a fatal error in mom4p0c release, NEW datasets that have calendar attribute are required for mom4p0c release.
- Because getting NetCDF datasets in a proper format for FMS code remains a frustrating aspect of running MOM4, we have provided a new stand-alone utility that tests a data file for compatibility with FMS. This utility is in shared/time_interp_external.F90 and there is an associated run script at src/preprocessing/test_time_interp_ext that the user should modify for their machines. Use of this utility to debug the datasets prior to running MOM4 can help to remove a significant level of frustration associated with building a new model with new datasets.
- Another substantial update to the FMS infrastructure involves the mpp code, such as shared/mpp.F90 . This code has been significantly reorganized for easier understanding, and many new features have been added. One new feature that has been found quite useful is that it is now possible to update a set of fields across processors after accumulating the full set, rather than sending each member individually. In general, sending one very large package of data for mpp_update_domains is far more efficient than sending multiple smaller packages. This new feature is most useful, for example, when sending multiple tracers or tracer tendencies for updates in modules such as ocean_neutral_physics.F90 and tracer advection. (Note that only the Sweby advection scheme has been modified to allow for this improved efficiency. Other schemes can be modified similarly. Since they are not commonly used at GFDL, they have not been modified).