Difference between revisions of "Nested Grids"

From WikiROMS
Jump to navigationJump to search
(Created page with "<wikitex> ROMS has a nested design structure for the temporal coupling between a hierarchy of parent and child grids. All the state model variables are dynamically allocated and…")   (change visibility)
 
Line 1: Line 1:
<div class="title">Nested Gris</div>__NOTOC__
<!-- Edit Template:Nested_Grids_TOC to modify this Table of Contents-->
<div style="float: left;margin: 0 20px 0 0;">{{Nested Grids TOC}}</div>__TOC__
<div style="clear: both"></div>
==Introduction==
ROMS has a nested design structure for the temporal coupling between a hierarchy of parent and child grids.  All the state model variables are dynamically allocated and passed as arguments to the computational routines via Fortran-90 dereferenced pointer structures. All private arrays are automatic; their size is determined when the procedure is entered.  This code structure facilitates computations over nested grids of different topologies. There are three types of nesting capabilities in ROMS:
* '''Mosaics Grids''' which connect several grids along their edges,
* '''Composite Grids''' which allow overlap regions of aligned and non-aligned grids, and
* '''Refinement Grids''' which provide increased resolution (3:1, 5:1, or 7:1) in a specific region.
The mosaic and composite grid code infrastructures are identical.  The differences are geometrical and primary based on the alignment between adjacent grids.  All the mosaic grids are exactly aligned with the adjacent grid.  In general, the mosaic grids are special case of the composite grids.
The nested grid implementation was divided in three sequential phases:
* Phase '''I''', released on April 2011 as ROMS version '''3.5''', included major updates to the nonlinear (NLM), perturbation tangent linear (TLM), finite-amplitude tangent linear (RPM), and adjoint (ADM) models numerical kernels to allow different horizontal '''I'''- and '''J'''-ranges in the '''DO'''-loops to permit operations on various nested grid classes (refinement, mosaics, and composite) and nesting layers (refinement and composite grid combinations).  This facilitates the computation of any horizontal operator (advection, diffusion, gradient, etc.) in the nesting overlap regions and avoids the need for cumbersome lateral boundary conditions on the model variables and their associated flux/gradient values.  The advantage of this approach is that it is generic to any discrete horizontal operator.  The overlap region is an extended section of the grid that overlays an adjacent grid. The strategy is to compute the full horizontal operator at the contact points between nested grids instead of specifying boundary conditions, as shown in Fig. 1 of Warner et al. (2010).
* Phase '''II''', released on September 2011 as ROMS version '''3.6''', included a major overhaul of lateral boundary conditions.  All their associated C-preprocessing options were eliminated and replaced with logical switches that depend on the nested grid, if any.  This facilitates, in a generic way, the processing or not of lateral boundary conditions in applications with nested grids.  In nesting applications, the values at the lateral boundary points are computed directly in the overlap region by the numerical kernel.  In addition, the logical switches allow different lateral boundary conditions types between active (temperature and salinity) and passive (biology, sediment, inert, etc.) tracers. The lateral boundary condition switches for each state variable and boundary edge are now specified in ROMS input script file, ocean.in.
* Phase '''III''', to be released soon as ROMS version '''3.7''', includes the nesting calls to ROMS main time-stepping routines, main2d and main3d.  The routine main2d is only used in shallow-water 2D barotropic applications whereas main3d is used in full 3D baroclinic applications.  Several new routines will be added to process the information that it is required in the overlap region, what information needs to be exchanged from/to another grid, and when to exchange it.  The exchange between grids can be one-way or two-way.
The current plan is to move to ROMS version '''4.0''' when all complex new developments are fully stable and tested.
==Nested Grids Classes==
<wikitex>
<wikitex>
ROMS has a nested design structure for the temporal coupling between a hierarchy of parent and child grids.  All the state model variables are dynamically allocated and passed as arguments to the computational routines via Fortran-90 dereferenced pointer structures. All private arrays are automatic; their size is determined when the procedure is entered.  This code structure facilitates computations over nested grids of different topologies. There are three types of nesting capabilities in ROMS:


* '''Refinement Grids''' which provide increased resolution (3:1 or 5:1) in a specific region,
The ROMS nested grid design includes three Super-Classes and several Sub-Classes:
* '''Mosaics Grids''' which connect several grids along their edges, and
 
* '''Composite Grids''' which allow overlap regions of aligned and non-aligned grids.
# Composite Grids Super-Class:
#* Mosaic Grids Sub-Class
#* Composite Overlap Grids Sub-Class
#* Partial Boundary Composite Grids Sub-Class
#* Complex Estuary Composite Grids Sub-Class
# Refinement Grids Super-Class:
#* Single Refinement Sub-Class
#* Multiple Refinement Sub-Class
# Composite/Refinement Super-Class:
#* Complex Estuary Refinement Grids Sub-Class
 
Hence, there are several possibilities and combinations. The design is flexible enough to allow complex nested grid configurations in coastal applications.  These capabilities are better illustrated with diagrams of the different Sub-Classes. The diagrams are all in terms of computational coordinates ($\xi$, $\eta$) or fractional ($i$, $j$) coordinates.  Therefore we have squares and rectangles that may map to physical curvilinear coordinates.


</wikitex>
</wikitex>
===Refinement Grids===
<wikitex>
{|
{|
|-
|-
Line 15: Line 52:
|[[Image:refinement_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]]
|[[Image:refinement_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]]
|}
|}
</wikitex>
 
===Mosaic Grids===
===Mosaic Grids===
<wikitex>
<wikitex>

Revision as of 20:38, 19 April 2012

Nested Gris
Nested Grids Menu
  1. Introduction
  2. Matlab Processing Scripts

Introduction

ROMS has a nested design structure for the temporal coupling between a hierarchy of parent and child grids. All the state model variables are dynamically allocated and passed as arguments to the computational routines via Fortran-90 dereferenced pointer structures. All private arrays are automatic; their size is determined when the procedure is entered. This code structure facilitates computations over nested grids of different topologies. There are three types of nesting capabilities in ROMS:

  • Mosaics Grids which connect several grids along their edges,
  • Composite Grids which allow overlap regions of aligned and non-aligned grids, and
  • Refinement Grids which provide increased resolution (3:1, 5:1, or 7:1) in a specific region.

The mosaic and composite grid code infrastructures are identical. The differences are geometrical and primary based on the alignment between adjacent grids. All the mosaic grids are exactly aligned with the adjacent grid. In general, the mosaic grids are special case of the composite grids.

The nested grid implementation was divided in three sequential phases:

  • Phase I, released on April 2011 as ROMS version 3.5, included major updates to the nonlinear (NLM), perturbation tangent linear (TLM), finite-amplitude tangent linear (RPM), and adjoint (ADM) models numerical kernels to allow different horizontal I- and J-ranges in the DO-loops to permit operations on various nested grid classes (refinement, mosaics, and composite) and nesting layers (refinement and composite grid combinations). This facilitates the computation of any horizontal operator (advection, diffusion, gradient, etc.) in the nesting overlap regions and avoids the need for cumbersome lateral boundary conditions on the model variables and their associated flux/gradient values. The advantage of this approach is that it is generic to any discrete horizontal operator. The overlap region is an extended section of the grid that overlays an adjacent grid. The strategy is to compute the full horizontal operator at the contact points between nested grids instead of specifying boundary conditions, as shown in Fig. 1 of Warner et al. (2010).
  • Phase II, released on September 2011 as ROMS version 3.6, included a major overhaul of lateral boundary conditions. All their associated C-preprocessing options were eliminated and replaced with logical switches that depend on the nested grid, if any. This facilitates, in a generic way, the processing or not of lateral boundary conditions in applications with nested grids. In nesting applications, the values at the lateral boundary points are computed directly in the overlap region by the numerical kernel. In addition, the logical switches allow different lateral boundary conditions types between active (temperature and salinity) and passive (biology, sediment, inert, etc.) tracers. The lateral boundary condition switches for each state variable and boundary edge are now specified in ROMS input script file, ocean.in.
  • Phase III, to be released soon as ROMS version 3.7, includes the nesting calls to ROMS main time-stepping routines, main2d and main3d. The routine main2d is only used in shallow-water 2D barotropic applications whereas main3d is used in full 3D baroclinic applications. Several new routines will be added to process the information that it is required in the overlap region, what information needs to be exchanged from/to another grid, and when to exchange it. The exchange between grids can be one-way or two-way.

The current plan is to move to ROMS version 4.0 when all complex new developments are fully stable and tested.


Nested Grids Classes

<wikitex>

The ROMS nested grid design includes three Super-Classes and several Sub-Classes:

  1. Composite Grids Super-Class:
    • Mosaic Grids Sub-Class
    • Composite Overlap Grids Sub-Class
    • Partial Boundary Composite Grids Sub-Class
    • Complex Estuary Composite Grids Sub-Class
  2. Refinement Grids Super-Class:
    • Single Refinement Sub-Class
    • Multiple Refinement Sub-Class
  3. Composite/Refinement Super-Class:
    • Complex Estuary Refinement Grids Sub-Class

Hence, there are several possibilities and combinations. The design is flexible enough to allow complex nested grid configurations in coastal applications. These capabilities are better illustrated with diagrams of the different Sub-Classes. The diagrams are all in terms of computational coordinates ($\xi$, $\eta$) or fractional ($i$, $j$) coordinates. Therefore we have squares and rectangles that may map to physical curvilinear coordinates.

</wikitex>

Blue and Red Grids
Red Grid Contact Points
Blue Grid Contact Points

Mosaic Grids

<wikitex>

Blue and Red Grids
Red Grid Contact Points
Blue Grid Contact Points

</wikitex>

Composite Grids

<wikitex>

Red and Blue Grids
Red Grid Contact Points
Blue Grid Contact Points

</wikitex>