MOM4 Frequently Asked Questions

In GFDL, we try our best to make the scripts independent from platforms as much as possible. In theory, all platform specifics are contained in Make templates (mkmf.template.platform). When users set platform (sgi, ibm, ifc ...) the scripts will pick the right template.

In reality, users encounter various problems related to implementation on different platforms. Users may need to modify the source code and/or scripts. Please refer to MOM4 on Various Computer Platforms section to find if your problems are listed there. If not, please report your problems to us and we try our best to address your problems.

Our limitation is that in GFDL currently we have only SGI, Altix and Beowulf (using IFC). MOM4 code has been tested extensively on these platforms. For experience running MOM4 on other platforms we rely on contributions from external users. For the benefits of MOM4 community please report problems and or solutions related to your platform.

In the runscript you see:

      set days = 1
      set months = 0
   

You can change days and months to any number you want. However, note that the tests are provided for checking ports of the code to different machines, and overall numerical integrity of the code. The tests are not guaranteed to run for an indefinite period of time (i.e., they are not `` tuned models''). A test case therefore may bomb if changing the runlength to something longer.

In the runscript you see:

      set npes = 15
   

In this example, there are 15 processors, you can set npes to any number your system can afford. However, You need to pay attention in case of STATIC option.

Based on our experience with SGI Origins at GFDL, The compiler is performing an excessive number of array copies if all the arrays are dynamically allocated. The solution is to allocate arrays at compile time.

Requirements of static option: each processor should have the same number of grid points as all other processor. For example, if your global grid is 100x100 you can not have 13 processors but you can have 2, 4, 8, 10 ... processors.

For more details see the sample script for static option (for test case test1A).

In the runscript look for ocean_solo_nml (or ocean_coupler_nml if you run coupled model). You will see:

      dt_ocean = 3600
   

This is time step of ocean model measured in seconds. Note that a longer time step may violate CFL conditions and the model may bomb.

"dt_ocean" corresponds to the ocean tracer time step. The other model time steps are set relative to one another via the correspondence

       dt_ocean = dtts
                = momentum_ts_split * dtuv
                = eta_ts_split * dteta
                = freesurf_ts_split * momentum_ts_split * dtfs
   

with

       dtts  = tracer time step
       dtuv  = baroclinic momentum time step
       dteta = "big leap-frog" time step (the time which updates the surface height)
       dtfs  = barotropic momentum time step
   

Output files are compressed in tar format. First, you need to uncompress the output files. The command for extracting a tar file is:

      tar -xvf filename.tar
   

As a result, you will get a number of files in NetCDF format. Some common tools working with NetCDF are ncview and ferret.

It is possible that in mkmf.template the following is missing: CFLAGS = -D__IFC

If it is the case, you need to add that to mkmf.template.

Basically, you need to use restart data instead of initial condition data. If you are using the runscripts provided by the mom4p0/mom4p1 release. Do the following:

      Remove the following section from the runscript:
         cp $expdir/preprocessing/ocean_tracers_ic.tar .
         tar -xvf ocean_tracers_ic.tar
         rm -f ocean_tracers_ic.tar
      and add the following in the same place:
         cp restart_file.nc.tar . (including the path)
         tar -xvf restart_file.nc.tar
         rm -f restart_file.nc.tar
   

The debugging tool used at GFDL is Totalview. To use this tool the user must:

     - compile the code with -g option in FFLAGS
     - insert "make localize" in the runscript so that all source code will be copied to the working directory.
   

If you do not have Totalview, then the old-fashioned method of adding print statements is the suggested method for debugging.

Data are supplied so that users can make test runs for all experiments. Users can also generate their own grid and initial/boundary conditions data. For more instruction refer to directory src/preprocessing that users get after CVS check out.

At GFDL we use both SHMEM and MPI libraries. In our experiments with MOM4 code SHMEM outperforms MPI by 20-30%. To use SHMEM, users need to replace a cppDefs option -Duse_libMPI by Duse_libSMA in the runscript.

	Note
	Only experiments using ocean_solo.F90 driver currently allow for SHMEM. We are working to allow all fms codes to use SHMEM, but that work is still in progress.

It is good idea for each test case to check if:

    - model results reproduce across different sets of processors
    - model results reproduce across restart data
   

In both cases users can rely on checksums that are printed at the end of each run (output file fms.out). For example a run using 1 processor and another run using 10 processors should have the same checksums. NetCDF tool ncdiff can also be used to view differences of two .nc files.

MOM4 has plenty of material written to stdout (which is what is written to fms.out). The user is strongly recommended to become familiar with the contents of fms.out, especially when building a new model experiment. This file contains numerous notes, warnings, error messages, and numerical diagnostics. Our experience is that most of the problems running MOM4 can be resolved by reading through the fms.out file.

The mom4-test cases are not well tuned models. Hence, they generally will not result in physically meaningful simulations. Additionally, the models may crash if run for longer than suggested in the distributed run scripts. That is, the test cases are supported ONLY for testing the integrity of the code on various platforms (i.e., does the code compile and run for a few time steps?). PLEASE PLEASE do not take the test cases and write papers based on them. We are not providing models--instead we are providing code.

Let's call the time at the top of diag_table T1 and the time entered in namelist T2. The time at the top of the diag_table (T1) is used as starting time of time axis in all output files that have time axis. When you open any output file and look for variable Time, you will see:

      Time:units = "hours since T1"
   

(assuming unit is hours).

T2 is the initial time for running the model, all fields cannot be written to output files sooner than T2. Since time can not be negative you should have T2 >= T1. In practice, to keep values in time axis from being exceedingly large, you should have T2=T1.