[laurscham]

Modifications to generate forcing data on a grid and output LDASOUT-style netcdfs of the forcing data for ingestion by coastal models.

Edited by @mxkpp

About

This primarily adds a new module NextGen_Forcings_Engine_BMI.coastal.gridded which is leveraged by nwm-rte's nwm-rte/bin_mounted/ngen_rte/coastal/make_coastal_forcing.py in PR: NGWPC/nwm-rte#36.

This also overhauls run_bmi_forcing.py to provide a high-level interface into leveraging the new module.

Some auxiliary changes were needed in config.py, model.py, and other core files in order to accommodate the needs of the coastal gridded workflow.

Not all Configurations are Supported

Not all configurations are supported.

For example, the default configuration file for Puerto Rico AnA uses CONUS MRMS data instead of Puerto Rico MRMS data. This causes the PR AnA to crash in the gridded forcing workflow.

T0 vs T1

For coastal modeling workflows, T0 must exist in the atmospheric forcing timeseries grids. So here, an optional parameter write_t0 was added to cause an additional T0 record to be written to the NetCDF file.

In this case, T0 has identical forcing values as T1. This method of copying the T1 data to T0 was necessary since some of the underlying forecast products do not provide a T0 state.

Inputs

For required static input data, see scripts/setup_data_coastal.sh in the nwm-coastal repository.

Usage

See: NGWPC/nwm-rte#36

Handling CONUS (large domain)

Warmup

A "warmup" mode is provided to handle the large memory requirements of generating ESMF weights files for large domains such as CONUS. The warmup writes weights to disk one product at a time, then quits. After the warmup runs, then the weights files are available for reuse for forecasts.

Additions

• See above

Removals

• None

Changes

• See above

Testing

1. ngen-forcing pytests were ran from the nwm-rte Dev Container: ( cd src/ngen-forcing && mpirun -n 2 pytest ) and ( cd src/ngen-forcing && pytest )
2. make_coastal_forcing.py from the related nwm-rte PR was ran: Add Coastal Forcing nwm-rte#36

Screenshots

Notes

Todos

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Visually tested in supported browsers and devices (see checklist below 👇)
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist

Target Environment support

• Linux

[mxkpp]

@laurscham in addition to the individual comments listed here in this first round of review, the branch needs to be rebased against development. It would be better to do that rebase first, before addressing the comments.

[mxkpp]

@laurscham in addition to the individual comments listed above in this first round of review, the branch needs to be rebased against development. It would be better to do that rebase first, before addressing the comments.

[mxkpp]

For managing the PRs of the 2 bases, development vs development-pw, IMO the PR into development (this one, #212) should be treated as the primary PR, with all review cycles and thorough PR description.

Then when review cycles are finished and this is merged into development, then the equivalent development-pw PR can be made to reflect the final changes from #212.

[mxkpp]

Rebased against development

[mxkpp]

For managing the PRs of the 2 bases, development vs development-pw, IMO the PR into development (this one, #212) should be treated as the primary PR, with all review cycles and thorough PR description.

Then when review cycles are finished and this is merged into development, then the equivalent development-pw PR can be made to reflect the final changes from #212.

Closing the other PR that points to development-pw. If this does need to be mirrored to it later, we can do that in a targeted cherry pick commit.

[mxkpp]

This was tested by multiple members of the team and found to produce the expected coastal forcing files, and they were ingestible into the coastal model.

[mxkpp]

This was tested by multiple members of the team and found to produce the expected coastal forcing files, and they were ingestible into the coastal model.

EDIT: the equivalent coastalforcing-pw-2 branch for testing on ParallelWorks contains the same changes as this branch, relative to its respective base. That branch does not need to be maintained but was needed as a mirror for testing in that environment.