Page Contents
1. Introduction
   1.1 What is MOM?
   1.2 MOM4 registration
   1.3 MOM4-beta
2. Details of MOM4
   2.1 Documentation
   2.2 Characteristics
   2.3 MOM4 and FMS
   2.4 Test cases
   2.5 Test case 1 quickstart
   2.6 Test case 2 quickstart
   2.7 Test case 3 quickstart
3. Ongoing MOM4 development
   3.1 MOM4 mailing list
   3.2 Continued code development
   3.3 Contributing MOM4-modules
4. Source code and data sets
   4.1 Source code and data sets
   4.2 Description of the data sets
   4.3 mom4_beta.tar.gz
   4.4 Running mom4 test cases
   4.5 Top-level directories
5. Preprocessing steps
   5.1 Grid generation
   5.2 Grid interpolation
6. Compiling the source code
   6.1 Example compile scripts
   6.2 Compiling without MPI
7. Preparing the runscript
   7.1 The runscript
   7.2 The diagnostics table
   7.3 The field table
   7.4 mppnccombine
8. Examining the output
   8.1 Sample model output
   8.2 Analysis tools
9. MOM4-beta2
   9.1 Availability
   9.2 Summary of changes
   9.3 FMS infrastructure changes
   9.4 Changes in drivers
   9.5 Changes in ocean_core
   9.6 Changes in ocean_param/mixing
   9.7 Changes in ocean_param/sources
   9.8 Changes in ocean_surface_bc/ocean_flux.F90
10. Experience on different platforms
   10.1 Model runtimes

The FMS MOM4-beta User Guide



1. Introduction
   1.1 What is MOM?
   1.2 MOM4 registration
   1.3 MOM4-beta

1.1 What is MOM?

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.

Presently, MOM4 is undergoing its second phase of beta-testing (MOM4-beta2). This is a fully open beta test, so anyone wishing to obtain the code can do so, as described below. The purpose of this web page is to provide general information about MOM4, and particular information for how to download and run the code.


1.2 MOM4 registration

In order to facilitate communication within the MOM4 community, please register in two separate places. The first is with the MOM4 web page at SourceForge. SourceForge is the avenue for MOM4 developers and users to broadcast bug-fixes, code updates, etc. Second, please fill out the MOM4 registration form at the GFDL NOMADS server. This registration provides GFDL developers with more detailed information than available through SourceForge. Also, registration at GFDL NOMADS is a necessary step prior to downloading the source-code.


1.3 MOM4-beta

The first beta release of MOM4 was been made available to selected researchers late April 2002. After extensive input and modifications to enhance functionality and portability, a second beta version (MOM4-beta2) was released early August, 2002. MOM4-beta2 is made available to anyone wishing to download the code.

As with previous MOM versions, the beta testing phase aims to expose the code to the scrutiny of those working on various computational platforms and coming from different research perspectives. The code will continue to undergo changes to address issues raised by feedback from beta-testers.

Those wishing to be beta-testers should fill out the MOM4 registration form. After your registration has been received (please allow a few days), you will be provided with a password allowing access to the GFDL NOMADS-server web page containing the MOM4-beta source code.



Back to top


2. Details of MOM4
   2.1 Documentation
   2.2 Characteristics
   2.3 MOM4 and FMS
   2.4 Test cases

2.1 Documentation

In addition to this web page, documentation for MOM4 is provided by A Technical Guide to MOM4 by Griffies, Harrison, Pacanowski, and Rosati. This is the primary reference for the code. A theoretical rationalization of the model's algorithms is provided by Fundamentals of Z-Coordinate Ocean Climate Models by Griffies. These documents will continue to be edited during the beta phase of the MOM4 development. Both are available on-line as hyperlinked PDF documents. As with the Fortran code, your feedback on these documents is welcome.


2.2 Characteristics

Although MOM4 shares much in common with earlier versions of MOM, it possesses a number of computational, numerical, and physical characteristics that are noteworthy. Click here to read a summary of the differences between MOM3 and MOM4. The following provides an overview of the main characteristics of MOM4 (please refer to A Technical Guide to MOM4 for references).


2.3 MOM4 and FMS

MOM4 has been coded within GFDL's Flexible Modeling System (FMS). Doing so allows for MOM4 developers to use numerous FMS infrastructure 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.

The FMS infrastructure (the so-called "Havana version") has been released to the public on SourceForge, with further releases every three months or so. Notably, the MOM4-beta release of MOM4 represents the first major model code to be released using the FMS infrastructure.

The Flexible Modeling System (FMS), including MOM4, is free software; you can redistribute it and/or modify it under 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


2.4 Test cases

MOM4-beta is distributed with test cases that serve many purposes for both the developers and researchers using the code. The test cases are not sanctioned for their physical integrity by GFDL researchers. Indeed, there is no guarantee that the test cases will run for an indefinite period of time. That is, there has been minimal tuning involved in their construction. Instead, the tests are distributed for illustrative purposes enabling one to verify that the code flow is correct.

In addition to providing the researcher with a means to verify code flow, the test cases exercise different domain topologies, dynamical formulations, and physical parameterizations. The test suite thus provides the researcher with a sense for the baseline numerical behavior maintained by the code. In particular, those aiming to contribute new modules to MOM4 should establish how the test cases are altered upon introducing their new algorithms.

MOM4-beta has three test cases. They are: The first test case is a flat bottom sector model with solid walls and internally generated boundary and initial conditions. Similar models have been used for idealized studies of the thermocline and thermohaline circulation. The second test case is a global configuration whose grid is based on spherical coordinates. No polar filtering is used in this test case, as there is no polar filtering module in MOM4. The third test case is a global model whose grid is based on the Murray (1996) tripolar grid. Detailed information regarding the grids, prescribed quantities, initial and boundary conditions and simulation physics can be found in A Technical Guide to MOM4. Quickstart guides are available for each of the three test cases (sections 2.5-2.7).



Back to top


3. Ongoing MOM4 development
   3.1 Feedback and Communication via the MOM4 mailing list
   3.2 Continued GFDL MOM4-beta code development
   3.3 Contributing MOM4-modules

3.1 Feedback and Communication via the MOM4 mailing list

Organization of feedback and queries concerning MOM4 is provided by the MOM4 mailing list. This replaces the MOM3 Bulletin Board used to communicate information regarding earlier MOMs. We encourage critical and constructive feedback be posted at the MOM4 mailing list, such as reports of possible bugs, incorrect or unclear documentation, unfriendly scripts, etc. We also encourage mention of quirks that will inevitably arise when porting FMS/MOM4 to various computer platforms. To receive email postings of MOM4 information, including updates, please register on the MOM4 mailing list.


3.2 Continued GFDL MOM4-beta code development

There remain outstanding code development issues that GFDL developers are actively pursuing at this time. This list includes the following items:
  1. The coupling of MOM4 to other component models is actively being pursued at GFDL in the context of earth system modeling. In particular, a current project aims to unify the MOM4 drivers used to run the model either as an ocean-only or in a coupled or semi-coupled mode.


  2. Presently, MOM4 has no open boundary conditions (OBCs). However, there is a GFDL-FMS project aiming to develop sets of generic computational tools of use for building OBC capabilities for geophysical fluid models. Researchers at GFDL most interested in these tools include regional atmospheric modelers and hurricane modelers. These tools should be of use Fall 2002 for those wishing to develop OBCs in MOM4.


  3. General testing/tuning of the model's physics remains, as always, an ongoing process. This work is closely coupled to the development of new modules and/or bug fixes. The main focus of development at GFDL is global ocean/sea ice modeling as well as fully coupled earth system modeling.



3.3 Contributing MOM4-modules

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 (e.g., open boundary conditions mentioned above). 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:
  1. clean modular Fortran 90 code that minimally touches other parts of the model


  2. satisfaction of the FMS code specifications outlined in the FMS Developers' Manual


  3. compatibility with the MOM4 test cases


  4. thorough and pedagogical documentation of the module for inclusion in A Technical Guide to MOM4 (a Latex document)


  5. comments within the code emulating other parts of the model so that HTML documentation files can be generated by our converter




Back to top


4. Source code and data sets
   4.1 Source code and data sets
   4.2 Description of the data sets
   4.3 Description of mom4_beta.tar.gz
   4.4 Brief on running mom4 test cases
   4.5 Contents of some top-level directories

4.1 Source code and data sets

The following MOM4-beta source code and global data sets are currently available for registered MOM4 users through the NOAA Operational Model Archive Distribution System (NOMADS). The source code is contained in a single tar file. Raw initial and boundary data sets are available. Registered users may also download separate data sets for the three test cases.

MOM4-beta Source Code mom4_beta.tar
Initial and Boundary Datasets OCCAM_1degree.nc
SeaWiFS_Non_Elino_clim.nc
hellerman.nc
nodc_woa98_salt.nc
nodc_woa98_sss.nc
nodc_woa98_sst.nc
nodc_woa98_temp.nc
Test Case 1 Preprocessing Data grid_spec.nc
Test Case 2 Preprocessing Data grid_spec.nc
salt.nc
sss.nc
sst.nc
tau.nc
temp.nc
Test Case 3 Preprocessing Data grid_spec.nc
salt.nc
sss.nc
sst.nc
tau.nc
temp.nc


4.2 Description of the data sets

The topography data set for test 2 and test 3 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).

The initial and boundary data for running mom4 are processed for the particular model grid via the preprocessing steps. The results from these preprocessing steps are available for the three test cases. The grid description file, grid_spec.nc, is the product of the preprocessing step grid generation. The test cases use different grids; test one uses a spectral sector grid, two, global spherical and three, tripolar. Therefore, there are separate grid_spec.nc files for each case. The flat bottom sector model (test 1) has internally generated initial and boundary conditions, and potential temperature and salinity is uniform. There are no data sets required for simulating this test case. Test cases 2 and 3 use interpolated temperature, salinity and momentum data for the initial and boundary conditions. The preprocessing section illustrates how the test case data was prepared.


4.3 Description of mom4_beta.tar.gz

This tarred and gzipped file contains all relevant code for running the three mom4 test cases. Compilation scripts and example run scripts are provided. To unzip and untar:

gunzip mom4_beta.tar.gz
tar -xvf mom4_beta.tar

The result will be a series of directories under the top directory where you started.


4.4 Brief on running mom4 test cases

This section contains a description for how to run the mom4 test cases. Subsequent sections and the quickstart guides (sections 2.5-2.7) provide more details. In brief, the steps that need to be completed include the following:

1. Obtain the source code tar file from NOMADS. The directory containing the source code will be refered to as $FMS_SRC_DIR. mom4_beta.tar
2. Edit the file that sets the paths for some top level FMS code. Edit $FMS_SRC_DIR/runscripts/fms_site_paths.
3. Edit the file that sets the test case specific paths. The variable $TEST_DIR refers to the three test case directories (e.g., test1, test2 and test3). Edit $FMS_SRC_DIR/runscripts/$TEST_DIR/mom4_experiment_paths.
4. Perform the necessary preprocessing steps. These include obtaining or creating the grid specification file, preparing the surface forcing data and preparing the initial condition data. Refer to the individual test case quickstart guides (sections 2.5-2.7) for the case-specific preprocessing steps.
5. Set up a compilation template for your platform and compiler and compile the code. Edit and execute $FMS_SRC_DIR/runscripts/$TEST_DIR/mom4_compile.csh.
6. Compile the post-processing utility by executing the following on the platform where MOM4 will be executed. cd $FMS_SRC_DIR/postprocessing
cc -O -o mppnccombine -I/usr/local/include -L/usr/local/lib \
   mppnccombine.c -lnetcdf
mv mppnccombine $FMS_SRC_DIR/bin
7. Edit the runscript by changing the batch options (if running in batch mode), setting the path to mppnccombine and setting INIT=.true. for the first run. Edit $FMS_SRC_DIR/runscripts/$TEST_DIR/mom4_run.csh.
8. Execute the run script. Execute $FMS_SRC_DIR/runscripts/$TEST_DIR/mom4_run.csh.
9. Examine the output. Sample output for comparison is provided on NOMADS. Look at output in $RESTART_PATH, $PRINTOUT_PATH and $OUTPUT_PATH.
10. Change the run length. Edit the unit and length of the run.


4.5 Contents of some top-level directories



fms_site_paths Contains environment variables for compiling and running the model
build_grid_generator.csh Compile executable for creating mom4 grids and topography
(run scripts are in $FMS_SRC_DIR/runscripts/$TEST_DIR
build_edit_grid.csh Compile executable to edit output from grid generation based on ASCII values
build_grid_compare.csh Compile utility to compare two grids and write differences to an ASCII file (useful for fine tuning grids)
build_regrid_2d.csh Compile 2d regridding tool for logically rectangular grids
(run scripts are in $FMS_SRC_DIR/runscripts/$TEST_DIR
build_regrid_3d.csh Compile 3d regridding tool for logically rectangular grids
(run scripts are in $FMS_SRC_DIR/runscripts/$TEST_DIR)
template.IRIX64 Sample make template for sgi mipspro compiler on Irix6.4
template.Linux Sample make file for pgf90 w/ MPICH
input_data Can be used to store inputs for preprocessing steps
mom4 mom4 source code and example run scripts
preprocessing Source code for preprocessing steps (regridding of forcing fields and initial conditions; grid generation)
shared shared fms code (may be used by different component models)



Back to top


5. Preprocessing steps
   5.1 Grid generation
   5.2 Grid interpolation

5.1 Grid generation

MOM4 data sets must be preprocessed prior to executing the source code for grid computation. The grids are computed in two steps; grid generation and regridding. Grid generation is a preprocessing step whereby grid factors are computed in a generic manner compatible with other models used at GFDL. This step knows nothing about halo regions, so it only computes grid information over the computational domain. The result of grid generation is a netCDF grid specification file, grid_spec.nc. Further discussion on the grid specification file can be found in the The FMS Havana User Guide.

This file contains a complete description of the grid. This includes two-dimensional arrays of geographical coordinates of t(racer), c(orner), n(orth) and e(ast) points. 'c' points are NE B-grid points. 'e' and 'n,' points are C-grid points. The grid_descriptor file also contains rotation angles for 'c' points.

Topography generation is included in the grid generation preprocessing step. Acceptable topography datasets are in netCDF format with COARDS-compliance. scale_factor can be changed in the namelist to reverse sign or change units in the data set. To change the "ht" field (topography at tracer points), create an ASCII file with the "i,j,ht_new" values and run edit_grid.


5.2 Grid interpolation

Once the grid has been generated, the grid specification file must be read into MOM4 and the generic grid information needs to be translated into grid arrays used by MOM4. SBC and IC/SPONGE generation in MOM4 can be accomplished using the regrid_2d and regrid_3d tools. Acceptable input data sets are netCDF format with COARDS-compliance.

All regridding is accomplished non-conservatively using a nearest neighbor distance weighting. A maximum radial distance (in radians) can be selected using the namelist value max_dist. regrid_2d ignores missing data points during regridding. If the nearest point is flagged missing, the resulting destination grid point is flagged as well. num_bins can be adjusted for speed, although for most applications this is not necessary. regrid_3d will not function properly if there are missing points in the input data sets. In the case of regrid_3d, this would require recalculating the mappings at each vertical level which could become expensive. A Ferret external function is available to extrapolate over land points.



Back to top


6. Compiling the source code
   6.1 Example compile scripts
   6.2 Compiling without MPI

6.1 Example compile scripts

The MOM4-beta source code contains example compile scripts for each of the three test cases. Within the compile scripts, the location of the source and physical parameterizations are specified. A template file is a platform-specific file that contains standard compilation flags. This file is used by the mkmf utility, which reads the template file, runs a list of make macros, commands and compilers and creates a makefile. This is automated through the example compile scripts, mom4_compile.csh located in the $FMS_SRC_DIR/runscripts/$TEST_DIR directory. Information regarding the makefile and the mkmf utility can be obtained from The FMS Havana User Guide.


6.2 Compiling without MPI

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-beta source code with MPI. If the user does not have MPICH or the communications library, the MOM4-beta source code can be compiled without MPI by omitting the CPPFLAGS value "-Duse_libMPI" in the example compile script.



Back to top


7. Preparing the runscript
   7.1 The runscript
   7.2 The diagnostics table
   7.3 The field table
   7.4 What is mppnccombine?

7.1 The runscript

A runscript is a shell script containing utilities and processes that are executed with the source code. It contains several variables that the user must specify prior to executing the runscript, including several input namelist variables. The runscript, mom4_run.csh, creates directories, copies the namelist variables, diagnostic table and field table into separate files, obtains the restart files if needed, runs the executable and saves the restart and output files. There are separate run scripts for each test case located in the $FMS_SRC_DIR/runscripts/$TEST_DIR directory.


7.2 The diagnostics table

The diagnostics table allows users to specify the sampling rates and choose the output fields prior to executing the FMS source code. It is included in the runscript for each test case, mom4_run.csh, located in the $FMS_SRC_DIR/runscripts/$TEST_DIR directory. A portion of a sample MOM4 diagnostic table is displayed below. Reference The FMS Havana User Guide for a detailed discussion on the diagnostics table and its sections.

"MOM4 run_ocean"
1980 1 1 0 0 0
 "test1",  315360000,  "seconds",   1,  "hours",  "Time"
"ocean_flux", "taux",              "taux",              "test1", "all", .false., "none", 2
"ocean_flux", "tauy",              "tauy",              "test1", "all", .false., "none", 2
"ocean_flux", "sfwf",              "sfwf",              "test1", "all", .false., "none", 2
"ocean_flux", "hflx",              "hflx",              "test1", "all", .false., "none", 2
"ocean_model",       "eta_t",             "eta_t",             "test1", "all", .false., "none", 2
"ocean_model",       "eta_u",             "eta_u",             "test1", "all", .false., "none", 2
"ocean_model",       "ud",                "ud",                "test1", "all", .false., "none", 2
"ocean_model",       "vd",                "vd",                "test1", "all", .false., "none", 2
"ocean_model",       "temp",              "temp",              "test1", "all", .false., "none", 2
"ocean_model",       "salt",              "salt",              "test1", "all", .false., "none", 2
"ocean_model",       "test",              "test",              "test1", "all", .false., "none", 2
"ocean_model",       "rho",               "rho",               "test1", "all", .false., "none", 2
"ocean_model",       "u",                 "u",                 "test1", "all", .false., "none", 2
"ocean_model",       "v",                 "v",                 "test1", "all", .false., "none", 2
"ocean_model",       "wt",                "wt",                "test1", "all", .false., "none", 2
"ocean_model",       "wu",                "wu",                "test1", "all", .false., "none", 2
"ocean_model",       "pres",              "pres",              "test1", "all", .false., "none", 2
"ocean_model",       "agm",               "agm",               "test1", "all", .false., "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, namely in netCDF format. The diagnostics manager is packaged with the MOM4 source code. The FMS diagnostic manager presently cannot handle scalar fields that are functions of time for technical reasons. This limitation of the FMS diagnostic tool will be remedied. Until then, scalars sent to the diagnostic manager are given a vertical dimension, with each value in the vertical the same. See ocean diagnostics.F90 for an example of how global kinetic energy is sent to the diagnostic manager. For more information on the diagnostics manager, refer to The FMS Havana User Guide.


7.3 The field table

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.

# Tracers

"tracer","ocean_mod","temp",1
"advection_scheme_horiz","quicker",""
"advection_scheme_vert","quicker",""
"longname","potential temperature",""

"tracer","ocean_mod","salt",1
"advection_scheme_horiz","quicker",""
"advection_scheme_vert","quicker",""
"longname","salinity",""

"tracer","ocean_mod","test",1
"advection_scheme_horiz","4th_order",""
"advection_scheme_vert","4th_order",""
"longname","test passive tracer",""


# Cross-land mixing

"xland_mix","ocean_mod","xland_mix",2
"xland","$EXPERIMENT","ixland_1=4,ixland_2=6,jxland_1=20,jxland_2=22,kxland_1=1,kxland_2=4,vxland=0.5e6"
"xland","$EXPERIMENT","ixland_1=15,ixland_2=16,jxland_1=2,jxland_2=3,kxland_1=3,kxland_2=9,vxland=0.5e6"


# Checkerboard null mode

"checkerboard","ocean_mod","checkerboard",2
"check","$EXPERIMENT","i=15,j=11,mix_vel=.50"
"check","$EXPERIMENT","i=1,j=3,mix_vel=.50"



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 amount of tracers specified, temperature (temp) and salinity (salt) must be included. The user may also define the horizontal and vertical tracer advection schemes.

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.


7.4 What is mppnccombine?

Running the FMS 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. Detailed information on mppnccombine can be found in The FMS Havana User Guide.

mppnccombine.c should be compiled on the platform where the user intends to run the MOM4-beta source code so the runscript can call it. The FMS Havana User Guide contains instructions on how to compile mppnccombine.c.



Back to top


8. Examining the output
   8.1 Sample model output
   8.2 Analysis tools

8.1 Sample model output

Sample MOM4-beta model output data files are available to registered MOM4 users on GFDL's NOMADS server. The data files contain output for the three test cases and can be used by beta-testers to assess differences across computing platforms. The sample model output data files are:

Test case 1 printout_test1.002000.01.11_1
printout_test1.002000.01.11_4
Test case 2 printout_test2.002000.01.02_4
Test case 3 printout_test3.002000.01.02_8


8.2 Analysis tools

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.



Back to top


9. MOM4-beta2
   9.1 Availability of MOM4-beta2
   9.2 Summary of changes: MOM4-beta1 --> MOM4-beta2
   9.3 Summary of salient FMS infrastructure changes
   9.4 Some details of changes in drivers
   9.5 Some details of changes in ocean_core
   9.6 Changes in ocean_param/mixing
   9.7 Some details of changes in ocean_param/sources
   9.8 Some detail of changes in ocean_surface_bc/ocean_flux

9.1 Availability of MOM4-beta2

MOM4-beta2 was released August 12, 2002. This release addresses problems identified with the MOM4-beta1 code released April 26, 2002. In particular, certain platform dependent issues have been resolved, with suggested mkmf.template files provided for various machines. In addition to platform issues, MOM4-beta2 provides a non-Boussinesq namelist option and fixes some algorithm bugs. Details of the differences between beta1 and beta2 are given in this section.

Note that anyone registering at http://nomads.gfdl.noaa.gov/nomads/forms/mom4_registration.html will receive password permission to download MOM4-beta2. We still expect further nearterm changes aimed at resolving outstanding algorithm development and computational platform issues. Hence, MOM4-beta2 still falls under the "beta" classification, with the attendant caveats.


9.2 Summary of changes: MOM4-beta1 --> MOM4-beta2

Major changes consist of the following:
9.3 Summary of salient FMS infrastructure changes

MOM4-beta2 is based on the Havana release of the FMS infrastructure. There are some updates within Havana that are salient to MOM4-beta2 versus MOM4-beta1.

9.4 Some details of changes in drivers


9.5 Some details of changes in ocean_core


9.6 Changes in ocean_param/mixing


9.7 Some details of changes in ocean_param/sources


9.8 Some detail of changes in ocean_surface_bc/ocean_flux



Back to top


10. Experience on different platforms
   10.1 Model runtimes

10.1 Model runtimes

To be completed.

MOM4-beta Example Code Runtime (sec/day)

# of processors 1 2 3 4 5 6
Test case 1            
Test case 2            
Test case 3            



Back to top


Last update:  2002/08/14 09:22:14
Send comments/suggestions to Lori Thompson