• 7.2.1.1 MNC Configuration:
• 7.2.1.2 MNC Inputs:
• 7.2.1.3 MNC Output:

7.2.1 Using MNC

7.2.1.1 MNC Configuration:

As with all MITgcm packages, MNC can be turned on or off at compile time using the packages.conf file or the genmake2 -enable=mnc or -disable=mnc switches.

While MNC is likely to work ``as is'', there are a few compile-time constants that may need to be increased for simulations that employ large numbers of tiles within each process. Note that the important quantity is the maximum number of tiles per process. Since MPI configurations tend to distribute large numbers of tiles over relatively large numbers of MPI processes, these constants will rarely need to be increased.

If MNC runs out of space within its ``lookup'' tables during a simulation, then it will provide an error message along with a recommendation of which parameter to increase. The parameters are all located within pkg/mnc/mnc_common.h and the ones that may need to be increased are:

In those rare cases where MNC ``out-of-memory'' error messages are encountered, it is a good idea to increase the too-small parameter by a factor of 2-10 in order to avoid wasting time on an iterative compile-test sequence.

7.2.1.2 MNC Inputs:

Like most MITgcm packages, all of MNC can be turned on/off at runtime using a single flag in data.pkg

One important MNC-related flag is present in the main data namelist file in the PARM03 section and it is:

For run-time configuration, most of the MNC-related model parameters are contained within a Fortran namelist file called data.mnc. The availabe parameters currently include:

Unlike the older MDSIO method, MNC has the ability to create or use existing output directories. If either mnc_outdir_date or mnc_outdir_num is true, then MNC will try to create directories on a PER PROCESS basis for its output. This means that a single directory will be created for a non-MPI run and multiple directories (one per MPI process) will be created for an MPI run. This approach was chosen since it works safely on both shared global file systems (such as NFS and AFS) and on local (per-compute-node) file systems. And if both mnc_outdir_date and mnc_outdir_num are false, then the MNC package will assume that the directory specified in mnc_outdir_str already exists and will use it. This allows the user to create and specify directories outside of the model.

For input, MNC can use a single global input directory. This is a just convenience that allows MNC to gather all of its input files from a path other than the current working directory. As with MDSIO, the default is to use the current working directory.

The flags snapshot_mnc, monitor_mnc, timeave_mnc, and autodiff_mnc allow the user to turn on MNC for particular ``types'' of output. If a type is selected, then MNC will be used for all output that matches that type. This applies to output from the main model and from all of the optional MITgcm packages. Mostly, the names used here correspond to the names used for the output frequencies in the main data namelist file.

The mnc_max_fsize parameter is a convenience added to help users work around common file size limitations. On many computer systems, either the opterating system, the file system(s), and/or the netCDF libraries are unable to handle files greater than two or four gigabytes in size. The MNC package is able to work within this limitation by creating new files which grow along the netCDF ``unlimited'' (usually, time) dimension. The default value for this parameter is just slightly less than 2GB which is safe on virtually all operating systems. Essentially, this feature is a way to intelligently and automatically split files output along the unlimited dimension. On systems that support large file sizes, these splits can be readily concatenated (that is, un-done) using tools such as the netCDF Operators (with ncrcat) which is available at:

http://nco.sourceforge.net/

Another way users can force the splitting of MNC files along the time dimension is the mnc_filefreq option. With it, files that contain variables with a temporal dimension can be split at regular intervals based solely upon the model time (specified in seconds). For some problems, this can be much more convenient than splitting based upon file size.

Additional MNC-related parameters may be contained within each package. Please see the individual packages for descriptions of their use of MNC.

7.2.1.3 MNC Output:

Depending upon the flags used, MNC will produce zero or more directories containing one or more netCDF files as output. These files are either mostly or entirely compliant with the netCDF ``CF'' convention (v1.0) and any conformance issues will be fixed over time. The patterns used for file names are:

Some example BASENAME values are:

grid

contains the variables that describe the various grid constants related to locations, lengths, areas, etc.

state

contains the variables output at the snapshot or dumpFreq time frequency

pickup.ckptA, pickup.ckptB

are the ``rolling'' checkpoint files

tave

contains the time-averaged quantities from the main model

All MNC output is currently done in a ``file-per-tile'' fashion since most NetCDF v3.x implementions cannot write safely within MPI or multi-threaded environments. This tiling is done in a global fashion and the tile numbers are appended to the base names as described above. Some scripts to manipulate MNC output are available at MITgcm/utils/matlab/ which includes a spatial ``assembly'' script called MITgcm/utils/matlab/mnc_assembly.m.

More general manipulations can be performed on netCDF files with

the NetCDF Operators (``NCO'')
at http://nco.sourceforge.net

the Climate Data Operators (``CDO'') 
at http://www.mpimet.mpg.de/~cdo/

Unlike the older MDSIO routines, MNC reads and writes variables on different ``grids'' depending upon their location on, for instance, an Arakawa C-grid. The following table provides examples:

1. For some grid topologies it is impossible to output all quantities using only sNx,sNy arrays for every tile. Two examples of this failure are the missing corners problem for vorticity values on the cubesphere and the velocity edge values for some open-boundary domains.
2. Writing quantities located on velocity or vorticity points with the above scheme introduces a very small data redundancy. However, any slight inconvenience is easily offset by the ease with which one can, on every individual tile, interpolate these values to mass points without having to perform an ``exchange'' (or ``halo-filling'') operation to collect the values from neighboring tiles. This makes the most common post-processing operations much easier to implement.

Copyright © 2006 Massachusetts Institute of Technology

Last update 2011-01-09