Process Forcings (case.process_forcings)

The final step: generate the forcing files your configure_forcings call (previous notebook) declared. This notebook covers the normal one-shot path, and the offline/iterative path for long or large runs where generating everything at once is too slow or resource-intensive.

This notebook covers:

• Section 1: the normal, one-shot path

• Section 2: offline/iterative processing (config.json, crocodash process) for long runs

📖 CrocoDash process_forcings docs · CLI reference · regional-mom6 docs (OBC regridding internals)

Section 1: Normal, One-Shot Processing¶

In this step, we call the process_forcings method of CrocoDash to cut out and interpolate the initial condition as well as all boundaries. CrocoDash also updates MOM6 runtime parameters and CESM xml variables accordingly.

Section 2: Offline or Iterative Processing (for Long Runs)¶

Often, generating OBC datasets can be done all in one shot, but in longer and larger cases (like running the Northwest Atlantic for a year) we need to start iterating through the generation. Generating open boundary condition (OBC) data is essential for the entire model runtime but can be time-consuming and resource-intensive.

The Extract Forcings Workflow in CrocoDash helps manage this by breaking data access into smaller, more manageable pieces, though the piecewise/chunked download+regrid pattern described below only applies to boundary conditions (--bc). The other forcing types (initial conditions, tides, chlorophyll, runoff, BGC) each run as a single call regardless of run length.

Extract Forcings Workflow Overview¶

When configure_forcings is called, it creates an extract_forcings/ folder under your input directory and writes a configuration file (config.json) there describing the boundary condition and other forcing files you need. The processing code itself lives in the installed CrocoDash.forcing package, never copied per-case. You trigger the workflow from the shell with crocodash process (see the CLI reference).

Folder Structure¶

inputdir/extract_forcings/ only holds data and config for this case, the actual processing code (driver.py and the modules it calls) lives in the installed CrocoDash package and is never copied per-case:

• config.json – written by configure_forcings(); the region-specific requirements and run parameters crocodash process/run_workflow() read back.

• raw_data/ – downloaded-but-unprocessed chunks, created during process_forcings() for both the initial condition (--ic) and boundary conditions (--bc).

• regridded_data/ – regridded OBC chunks, created during process_forcings() for boundary conditions (--bc) only.

Both cache directories let a re-run skip work that already succeeded instead of starting over from scratch.

What Each Component Actually Does¶

forcing/driver.py’s run_workflow() (what crocodash process calls under the hood) resolves the configurators present in config.json and dispatches to one method per component you request:

Each flag maps onto a configurator method through that class’s process_components declaration, so adding a forcing type surfaces its flag automatically:

--all runs every component the case has configured.

How to Use¶

1. Identify and allocate available computing resources, on Derecho, get a starter PBS submission script with crocodash template --output submit_forcings.pbs --kind pbs --machine glade (see the CLI reference).

2. For long boundary-condition runs specifically, shrink get_step_days and regrid_step_days (inside config.json’s conditions.outputs block). They default to 7 and 30 days respectively. Smaller steps mean more, cheaper chunks; this is the main knob for fitting a long OBC run into a walltime or memory limit.

3. Run crocodash process. You can rerun with a different --skip list if only some forcings changed, without redoing everything (see below).

See the CrocoDash docs’ Process Forcings page for more detail.

Running crocodash process¶

inputdir/extract_forcings/ holds only config.json and (once you’ve run this at least once) the raw_data//regridded_data/ caches, not a copy of the processing code itself, so running it always needs CrocoDash installed: crocodash process is a CLI entry point CrocoDash ships, not a standalone script sitting in that folder.

Run it from inside the extract_forcings directory, config.json is auto-detected from the current directory:

cd <inputdir>/extract_forcings
crocodash process --all

Or from anywhere, with --caseroot or a direct --config path:

crocodash process --caseroot <caseroot> --all
crocodash process --config <inputdir>/extract_forcings/config.json --all

Especially consider adjusting the data-download function in config.json: on Derecho, use the RDA reader (get_glorys_data_from_rda); on a local machine, use a GLORYS API/CLI function instead (see Configure Forcings, Section 2 for the full list of access functions). Change it by editing the function_name field under config.json’s conditions.inputs block.

Use --help (or crocodash process --help) to see all available flags, including running only specific forcings (--ic --tides --runoff) or skipping ones you don’t need (--all --skip bgcic). There’s no bare --bgc flag, BGC is three separate components (--bgcic, --bgcironforcing, --bgcrivernutrients) you enable individually.

Next steps¶

• Interior OBC Segments and Nesting, advanced domain/boundary topics

• Use Cases: real-world, end-to-end configurations