ROMS has a generalized vertical, terrain-following, coordinate system. Currently, two vertical transformation equations, , are available which can support numerous vertical stretching 1D-functions when several constraints are satisfied.
The following vertical coordinate transformations are available:
where is a nonlinear vertical transformation functional, is the time-varying free-surface, is the unperturbed water column thickness and corresponds to the ocean bottom, is a fractional vertical stretching coordinate ranging from , is a nondimensional, monotonic, vertical stretching function ranging from , and is a positive thickness controlling the stretching. In sediment applications, is changed at every time-step since it is affected by erosion and deposition processes.
Warning: We are now very strict about the value of and other input vertical transformation parameters. Since the beginning of ROMS, where and is the stretching parameter specified in ocean.in. Notice that it is not possible to build the vertical stretching coordinates when and using transformation (1) because it yields . This has been a legacy issue in ROMS for years, and you are either consistent with the previous set-up of your application or change the value of in all input NetCDF files and ocean.in. Therefore, in new applications you need to be sure that when using the transformation (1). Notice that this restriction is removed in transformation (2) and can be any positive value. It works for both or . Again, we are now checking internally for all stretching parameters for consistency in all input NetCDF files that have such variables.
We find it convenient to define:
where are the vertical grid thicknesses. In ROMS, is computed discretely as since this leads to the vertical sum of being exactly the total water column thickness .
In an undisturbed ocean state, corresponding to zero free-surface, . Shchepetkin and McWilliams (2005) denotes this transformation as an unperturbed coordinate system since all the depths are not affected by the displacements of the free-surface. This ensures that the vertical mass fluxes generated by a purely barotropic motion will vanish at every interface
- Regardless of the design of , it behaves like equally-spaced sigma-coordinates in shallow regions, where . This is advantageous because it avoids excessive resolution and associated CFL limitation is such areas.
- Near-surface refinement behaves more or less like geopotential coordinates in deep regions (level thicknesses, , do not depend or weakly depend on bathymetry), while near-bottom like sigma coordinates ( is roughly proportional to depth). This reduces the extreme r-factors near the bottom and reduces pressure gradient errors.
- The true sigma-coordinate system is recovered as . This is useful when configuring applications with flat bathymetry and uniform level thickness. Practically, you can achieve this by setting Tcline to 1.0d+16 in ocean.in. This will set . Although not necessary, we also recommend that you set and .
In an undisturbed ocean state, , transformation (2) yields the following unperturbed depths, ,
As a consequence, the uppermost grid box retains very little dependency from bathymetry in deep areas, where . For example, if and changes from to , the uppermost grid box changes only by a factor of 1.08 (less than ).
Vertical Stretching Functions
The above generic vertical transformation design facilitates numerous vertical stretching functions, . This function is defined in terms of several parameters which are specified in the standard input file, ocean.in.
Stretching Function Properties:
- is a dimensionless, nonlinear, monotonic function;
- is a continuous differentiable function, or a differentiable piecewise function with smooth transition;
- must be discretized in terms of the fractional stretched vertical coordinate ,
- must be constrained by , that is,
Available Stretching Functions:
- Song and Haidvogel (1994) function available in ROMS since its beginning, Vstretching = 1. is defined as:
- It is infinitely differentiable in .
- The larger the value of , the more resolution is kept above .
- For , the resolution all goes to the surface as is increased.
- For , the resolution goes to both the surface and the bottom equally as is increased.
- For , there is a subtle mismatch in the discretization of the model equations, for instance in the horizontal viscosity term. We recommend that you stick with reasonable values of , say .
- Some applications turn out to be sensitive to the value of used.
- A. Shchepetkin (2005) UCLA-ROMS deprecated function, Vstretching = 2. is defined as a piecewise function:
- R. Geyer function for high bottom boundary layer resolution in relatively shallow applications, Vstretching = 3. is defined as a piecewise function:
(7) minimal increase of surface resolution significant surface amplification no bottom amplification significant bottom amplification good bottom resolution for gravity flows super-high bottom resolution
- A. Shchepetkin (2010) UCLA-ROMS current function, Vstretching = 4. is defined as a continuous, double stretching function:
Surface refinement function:
Bottom refinement function:
Notice that the bottom function (9) is the second stretching of an already stretched transform (8). The resulting stretching function is continuous with respect to and as their values approach zero. The range of meaningful values for and are:
However, users need to pay attention to extreme r-factor (rx1) values near the bottom.
Due to its functionality and properties Vtransform = 2 and Vstretching = 4 are now the default values for ROMS.
The above vertical transformations have been registered with the CF Conventions Committee and the NetCDF-Java group. We expect that it will take some time for the CF Committee to approve them. However, the NetCDF-Java is expected to be coded right away. Two new standard_name variable attributes: ocean_s_coordinate_g1 and ocean_s_coordinate_g2 have been assigned for transformations (1) and (2), respectively. The terms in the definition are associated with file variables by the formula_terms attribute as follows:
double s_rho(s_rho) ; s_rho:long_name = "S-coordinate at RHO-points" ; s_rho:valid_min = -1. ; s_rho:valid_max = 0. ; s_rho:positive = "up" ; s_rho:standard_name = "ocean_s_coordinate_g1" ; s_rho:formula_terms = "s: s_rho C: Cs_r eta: zeta depth: h depth_c: hc" ; double s_w(s_w) ; s_w:long_name = "S-coordinate at W-points" ; s_w:valid_min = -1. ; s_w:valid_max = 0. ; s_w:positive = "up" ; s_w:standard_name = "ocean_s_coordinate_g1" ; s_w:formula_terms = "s: s_w C: Cs_w eta: zeta depth: h depth_c: hc" ;
double s_rho(s_rho) ; s_rho:long_name = "S-coordinate at RHO-points" ; s_rho:valid_min = -1. ; s_rho:valid_max = 0. ; s_rho:positive = "up" ; s_rho:standard_name = "ocean_s_coordinate_g2" ; s_rho:formula_terms = "s: s_rho C: Cs_r eta: zeta depth: h depth_c: hc" ; double s_w(s_w) ; s_w:long_name = "S-coordinate at W-points" ; s_w:valid_min = -1. ; s_w:valid_max = 0. ; s_w:positive = "up" ; s_w:standard_name = "ocean_s_coordinate_g2" ; s_w:formula_terms = "s: s_w C: Cs_w eta: zeta depth: h depth_c: hc" ;
Notice that the formula_terms are identical for both transformations and are independent of the vertical stretching function used. This metadata conventions allows to process/visualize any NetCDF file generated by ROMS easily and correctly compute the associated vertical grid depths.
Vertical Grid Examples
The following figures shows the -surfaces for both vertical transformations and available vertical stretching functions. These plots were generated in Matlab using the script scoord.m.