1 Grid data files

With OASIS3-MCT, the grid data files grids.nc, masks.nc and areas.nc are required for certain operations:

These NetCDF files can be created by the user before the run or can be written directly at run time by the processes of each component model using the grid data definition routines (see section 2.2.4).

The arrays containing the grid information are dimensioned (nx, ny), where nx and ny are the grid first and second dimension. Unstructured grids or other grids expressed with 1D vectors are supported by setting nx to the total number of grid points and ny to 1.

  1. grids.nc: contains the model grid longitudes and latitudes in double precision REAL arrays. The array names must be composed of a prefix (4 characters), given by the user in the namcouple on the second line of each field (see section 3.3), and of a suffix,.lon or .lat, for respectively the grid point longitudes or latitudes.

    If the SCRIPR/CONSERV remapping is specified, longitudes and latitudes for the source and target grid corners must also be available in the grids.nc file as double precision REAL arrays dimensioned (nx,ny,nc) where nc is is the maximum number of corners (in the counterclockwize sense, starting by any corner) over all cells; nc can be any number. For cells that do not have the maximum number of distinct corners, we recommend to repeat the last corner as many times as needed to describe nc corners. The names of the arrays must be composed of the grid prefix and the suffix .clo or .cla for respectively the grid corner longitudes or latitudes. As for the other grid information, the corners can be provided in grids.nc before the run by the user or directly by the component code through specific calls (see section 2.2.4).

    Longitudes must be given in degrees East in the interval -360.0 to 720.0. Latitudes must be given in degrees North in the interval -90.0 to 90.0. Note that if some grid points overlap, it is recommended to define those points with the same number (e.g. 360.0 for both, not 450.0 for one and 90.0 for the other) to ensure automatic detection of overlap by OASIS3-MCT.

    The corners of a cell cannot be defined modulo 360 degrees. For example, a cell located over Greenwich will have to be defined with corners at -1.0 deg and 1.0 deg but not with corners at 359.0 deg and 1.0 deg.

    Cells larger than 180.0 degrees in longitude are not supported.

    Longitudes and latitudes of grid points or corners can be defined through the oasis_write_grid or oasis_write_corner API routines respectively, see section 2.2.4.

  2. masks.nc: contains the masks for all component model grids in INTEGER arrays. Be careful to use the historical OASIS3-MCT convention: 0 = not masked (i.e. active), 1 = masked (i.e. not active) for each grid point. The array names must be composed of the grid prefix and the suffix “.msk”. Mask can be defined through the oasis_write_mask API routine, see section 2.2.4.

    File masks.nc may also contain the grid cell fractions that defines the active (i.e. not masked) part of the cells. Fractions should be consistent with the mask field. The fraction fields, if present, are only used in the global CONSERV, CHECKIN and CHECKOUT operations. If both a mask and fractions are defined for a grid, they must be consistent; OASIS3-MCT will abort if they are not coherent or if both are missing. Note that by OASIS3-MCT convention for the mask, a gridcell with mask=0 (active) should have a fractions greater than 0 and a gridcell with mask=1 (inactive) should have a fractions equal to 0. The fraction array name must be composed of the grid prefix and the suffix .frc. Fractions can be defined through the oasis_write_frac API routine, see section 2.2.4.

  3. areas.nc: this file contains mesh surfaces for the component model grids in double precision REAL arrays. The array names must be composed of the grid prefix and the suffix .srf. The surfaces may be given in any units but they must be the same on the source and target sides; furthermore they must be in square radians if the True Area (TR) correction is activated, see section 4.3.

    Surfaces can be defined through the oasis_write_area API routine, see section 2.2.4.

    This file areas.nc is mandatory for the global CONSERV post-processing operation; it is not required otherwise.