Home Contact Us Site Map  
    next up previous contents
Next: 7.2.2 MNC Troubleshooting Up: 7.2 NetCDF I/O: MNC Previous: 7.2 NetCDF I/O: MNC   Contents


7.2.1 Using MNC 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:

Name Default Description
MNC_MAX_ID 1000 IDs for various low-level entities
MNC_MAX_INFO 400 IDs (mostly for object sizes)
MNC_CW_MAX_I 150 IDs for the ``wrapper'' layer

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. MNC Inputs:

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

Name T Default Description
useMNC L .FALSE. overall MNC ON/OFF switch

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

Name T Default Description
outputTypesInclusive L .FALSE. use all available output ``types''
which specifies that turning on MNC for a particular type of output should not simultaneously turn off the default output method as it normally does. Usually, this option is only used for debugging purposes since it is inefficient to write output types using both MNC and MDSIO or ASCII output. This option can also be helpful when transitioning from MDSIO to MNC since the output can be readily compared.

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:

Name T Default Description
mnc_use_outdir L .FALSE. create a directory for output
mnc_outdir_str S 'mnc_' output directory name
mnc_outdir_date L .FALSE. embed date in the outdir name
mnc_outdir_num L .TRUE. optional
pickup_write_mnc L .TRUE. use MNC to write pickup files
pickup_read_mnc L .TRUE. use MNC to read pickup files
mnc_use_indir L .FALSE. use a directory (path) for input
mnc_indir_str S '' input directory (or path) name
snapshot_mnc L .TRUE. write snapshot output w/MNC
monitor_mnc L .TRUE. write monitor output w/MNC
timeave_mnc L .TRUE. write timeave output w/MNC
autodiff_mnc L .TRUE. write autodiff output w/MNC
mnc_max_fsize R 2.1e+09 max allowable file size (<2GB)
mnc_filefreq R -1 frequency of new file creation (seconds)
readgrid_mnc L .FALSE. read grid quantities using MNC
mnc_echo_gvtypes L .FALSE. list pre-defined ``types'' (debug)

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:


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. 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:

and examples are:
grid.t001.nc, grid.t002.nc
state.0000000000.t001.nc, surfDiag.0000036000.t001.nc
where BASENAME is the name selected to represent a set of variables written together, nIter is the current iteration number as specified in the main data namelist input file and written in a zero-filled 10-digit format, tileNum is a three-or-more-digit zero-filled and ``t''-prefixed tile number, faceNum is a three-or-more-digit zero-filled and ``f''-prefixed face number, and .nc is the file suffix specified by the current netCDF ``CF'' conventions.

Some example BASENAME values are:

contains the variables that describe the various grid constants related to locations, lengths, areas, etc.
contains the variables output at the snapshot or dumpFreq time frequency
pickup.ckptA, pickup.ckptB
are the ``rolling'' checkpoint files
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
or with
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:

Name C-grid location # in X # in Y
Temperature mass sNx sNy
Salinity mass sNx sNy
U velocity U sNx+1 sNy
V velocity V sNx sNy+1
Vorticity vorticity sNx+1 sNy+1
and the intent is two-fold:
  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.

next up previous contents
Next: 7.2.2 MNC Troubleshooting Up: 7.2 NetCDF I/O: MNC Previous: 7.2 NetCDF I/O: MNC   Contents
Copyright 2006 Massachusetts Institute of Technology Last update 2018-01-23