Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

One Way Nesting a Regional Ocean Model: Strait of Gibraltar Example

This notebook demonstrates MOM6-in-CESM domain nesting: running progressively finer child domains whose open-boundary conditions (OBCs) come from the next coarser parent, rather than from a global reanalysis like GLORYS.

Feature: the Strait of Gibraltar, the narrow (~14 km wide) sill connecting the Atlantic and the Mediterranean. Warm, salty Mediterranean water sinks over the Camarinal Sill (~300 m) and cascades down the Gulf of Cadiz slope as Mediterranean Overflow Water, spinning off eddies (“Meddies”), a classic hydraulic-control/overflow process that only shows up once resolution is fine enough to resolve the sill itself.

Each level in this hierarchy refines by 4× (the max recommended child:parent ratio), so the tiny child reaches sub-kilometer, “hyper-resolution”, while every domain stays small enough to build and run on ~10 cores.


Domain hierarchy

Parent      (gibraltar_parent)      1/12°   (~7.5-9 km)   -8.0→-2.0 lon,  34.5→37.0 lat   (Gulf of Cadiz + Alboran approach)
│  4× refinement
└── Middle child                     1/48°   (~1.9-2.3 km) -6.0→-5.0 lon,  35.75→36.25 lat  (strait mouth)
    │  4× refinement
    └── Tiny child                   1/192°  (~0.47-0.58 km) -5.9→-5.65 lon, 35.83→35.955 lat  (Camarinal Sill)

Rule of thumb: each child should be no more than 4× finer than its parent (4:1 ratio). This hierarchy now sits right at that maximum every step, rather than the more conservative 2× used previously. The parent alone (1/12°) can’t resolve the 14 km-wide strait at all; the middle child (1/48°) resolves the strait mouth with several points across it; the tiny child (1/192°) zooms in tight enough to resolve the Camarinal Sill itself at sub-kilometer resolution.


Workflow

The three domains are built up together, step by step, rather than one domain at a time. Each step below does the same thing for the parent and both children, since the calls are basically identical across domains:

  1. Paths: case/input paths for all three domains

  2. Grids: horizontal grid for all three (created fresh. There’s no existing reference case for Gibraltar, unlike a production run)

  3. Topography: bathymetry for all three, from GEBCO

  4. Vertical grids: hyperbolic vertical grid for all three

  5. CESM cases: create all three cases. Each pinned to a small NTASKS_OCN (~10 cores or fewer)

  6. Forcings: configure OBCs for all three: parent from GLORYS, children from CESM_MOM_OUTPUT.get_mom6_output_data() reading their parent’s nesting output

Setup: imports

Step 1: Paths (parent, middle child, tiny child)

Step 2: Horizontal grids (parent, middle child, tiny child)

Step 3: Bathymetry / topography (parent, middle child, tiny child)

Step 4: Vertical grids (parent, middle child, tiny child)

Step 5: Create the CESM cases (parent, middle child, tiny child)

All three grids are small enough that NTASKS_OCN is pinned to 10 cores or fewer. This demo is meant to build and run quickly, not to scale up.

Step 6: Configure and process forcings (parent, middle child, tiny child)

The parent gets its OBCs from GLORYS (there’s no existing reference case to reuse for Gibraltar, unlike a production run). Both children instead read their parent’s nesting output as OBCs, via CESM_MOM_OUTPUT.get_mom6_output_data.

Step 7: Visualize the nested current fields

All three domains actually ran to completion (see ~/scratch/archive/gibraltar_*), so we can pull real surface-current output (speed) and land-mask (geolon/geolat/wet) from each domain’s mom6.h.sfc and mom6.h.static history files and paint all three directly on top of one another, in the same map, at each domain’s true geographic location, parent on the bottom, middle child on top of it, tiny child on top of that, with a thin white outline marking where each child’s footprint actually starts. One shared color scale across all three, and the displayed window is cropped in around the strait so the nested children aren’t tiny slivers in the full parent extent. We also animate it over the run so you can watch the Gibraltar jet meander day by day.


Summary

This notebook walked through a full 3-level nesting hierarchy over the Strait of Gibraltar, building all three domains together at each step, refining by 4× at each level (the max recommended child:parent ratio) so the tiny child reaches sub-kilometer resolution, and kept every domain small enough to build and run on ~10 cores or fewer:

DomainResolutionlonlatGrid sizeNTASKS_OCNOBC source
Parent (gibraltar_parent)1/12° (~8 km)-8.0→-2.034.5→37.0~72×3010GLORYS
Middle child1/48° (~2 km)-6.0→-5.035.75→36.25~48×248Parent nesting output
Tiny child1/192° (~0.5 km)-5.9→-5.6535.83→35.955~48×246Middle-child nesting output

Each level runs independently once its case is built. Once the parent finishes, the middle child can start;
once the middle child finishes, the tiny child can start.

See CESM_MOM_OUTPUT (CrocoDash/raw_data_access/datasets/cesm_ocean_output.py) for the native-MOM6-output readers used above, get_mom6_output_data (multi-variable-per-file history/diag_table output) and get_mom6_single_variable_data (CESM tseries-style output), and their docstrings for direct-call usage. CESM_MOM_OUTPUT is a separate product from CESM_POP_OUTPUT specifically because they need different variable/ coordinate metadata (native MOM6 names vs. CESM-POP names). Each child’s dataset_path is threaded through per-call via configure_forcings(function_overrides={"dataset_path": ...}) rather than sourced from class-level metadata, since CESM_MOM_OUTPUT has no single universal default (it’s meant to point at whichever parent run produced its OBC source). see the note in Step 6 for why that directory should hold only the 5 OBC-relevant fields (zos, thetao, so, uo, vo) rather than a parent’s full history output.

A larger, Caribbean 3-level nesting demo (loading an existing reference case for the parent instead of building it from scratch) is kept in dev/nesting_caribbean_demo/ for reference.</cell id=“cell-15”>