Difference between revisions of "Nested Grids"
| Line 18: | Line 18: | ||
The nested grid implementation was divided in three sequential phases: | 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. | * 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. | ||
* 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 '''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. | ||
| Line 29: | Line 30: | ||
==Nested Grids Classes== | ==Nested Grids Classes== | ||
<wikitex> | <wikitex> | ||
The ROMS nested grid design includes three Super-Classes and several Sub-Classes: | The ROMS nested grid design includes three Super-Classes and several Sub-Classes: | ||
| Line 40: | Line 40: | ||
#* Single Refinement Sub-Class | #* Single Refinement Sub-Class | ||
#* Multiple Refinement Sub-Class | #* Multiple Refinement Sub-Class | ||
# Composite | # Composite and Refinement Combination Super-Class: | ||
#* Complex Estuary Refinement Grids Sub-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. | 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> | |||
==Contact Regions and Contact Points== | |||
<wikitex> | |||
A contact region is an extended section of the grid that overlays or is adjacent to a nested grid. A contact point is grid cell inside the contact region. The contact points are located according to the staggered Arakawa C-grid horizontal positions. Therefore, we have contact points at the ρ-, ψ-, u-, and v-points. However, the ψ-points are only used find the physical grid perimeters. In a nested application we have ([[Ngrids]]-1)*2 contact regions. Each contact region has a '''receiver''' grid and '''donor''' grid. The contact points of the '''receiver''' grid are processed using the '''donor''' grid cell containing the contact point. The contact points are coincident if the '''receiver''' and '''donor''' grids occupy the same position. The receiver grid contact point data is just filled using the donor data. Otherwise, if not coincident the receiver grid data is linearly interpolated from the donor grid cell containing the contact point. | |||
The contact points are processed outside of ROMS and all the connectivity within nested grids are read from a NetCDF file. This facilitates the configuration of various grid Sub-Classes. It simplifies tremendously the processing of such points in parallel applications. It also give the user full editing control of the contact points. They just needs to be set-up once for a particular application. | |||
</wikitex> | </wikitex> | ||
<!-- | |||
{| | {| | ||
|- | |- | ||
| Line 52: | Line 65: | ||
|[[Image:refinement_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | |[[Image:refinement_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | ||
|} | |} | ||
--> | |||
<!-- | |||
< | |||
{| | {| | ||
|- | |- | ||
| Line 61: | Line 74: | ||
|[[Image:mosaic_grid1.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | |[[Image:mosaic_grid1.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | ||
|} | |} | ||
--> | |||
< | <!-- | ||
{| | {| | ||
|- | |- | ||
| Line 70: | Line 83: | ||
|[[Image:composite_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | |[[Image:composite_grid2.png|thumb|330px|<center>Blue Grid Contact Points</center>]] | ||
|} | |} | ||
--> | |||
Revision as of 21:36, 19 April 2012
| 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.
- 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:
- 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 and Refinement Combination 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>
Contact Regions and Contact Points
<wikitex> A contact region is an extended section of the grid that overlays or is adjacent to a nested grid. A contact point is grid cell inside the contact region. The contact points are located according to the staggered Arakawa C-grid horizontal positions. Therefore, we have contact points at the ρ-, ψ-, u-, and v-points. However, the ψ-points are only used find the physical grid perimeters. In a nested application we have (Ngrids-1)*2 contact regions. Each contact region has a receiver grid and donor grid. The contact points of the receiver grid are processed using the donor grid cell containing the contact point. The contact points are coincident if the receiver and donor grids occupy the same position. The receiver grid contact point data is just filled using the donor data. Otherwise, if not coincident the receiver grid data is linearly interpolated from the donor grid cell containing the contact point.
The contact points are processed outside of ROMS and all the connectivity within nested grids are read from a NetCDF file. This facilitates the configuration of various grid Sub-Classes. It simplifies tremendously the processing of such points in parallel applications. It also give the user full editing control of the contact points. They just needs to be set-up once for a particular application.
</wikitex>
