[5pt] PR: Post-processing tool for inundation: interpolate water surface

[CarsonPruitt-NOAA]

This script produces inundation depths and attempts to overcome the catchment boundary issue by interpolating water surface elevations between catchments. Water surface calculations require the hydroconditioned DEM (dem_thalwegCond_{}.tif) for computation, however, this file is not in the standard outputs from fim_pipeline.sh. Therefore, users may have to re-run fim_pipeline.sh with dem_thalwegCond_{}.tif removed from all deny lists.

Additions

• tools/interpolate_water_surface.py: New post-inundation processing tool for extending depths beyond catchment limits. The interpolate_wse() contains the logic for computing the updated depth raster, but users can also call this module directly to perform inundation, similar to how inundate_mosaic_wrapper.py works, but with the new post-processing enhancement.

Testing

This method has not been widely tested for improved FIM skill. Here is the example usage:

python interpolate_water_surface.py -y /outputs/fim_pipline_outputs -u 17110009 17110010 \
    -f /home/user/interpolated_fim/custom_flow_file.csv -d /home/user/interpolated_fim/depth_raster.tif

Screenshots

This plot shows a transect of water surface elevation and the DEM in between 2 catchments where a catchment boundary is limiting inundation extent. The interpolate_water_surface.py tool interpolates the water surface to fill the gap in between. If the DEM surface is below the interpolated water surface, the area should be classified as inundated.

These maps show the results. Blue is the original depth output from HAND and the yellow/orange shows the additional interpolated depth using this method. The catchment boundaries are the red polygons.

Issuer Checklist (For developer use)

You may update this checklist before and/or after creating the PR. If you're unsure about any of them, please ask, we're here to help! These items are what we are going to look for before merging your code.

• Informative and human-readable title, using the format: [_pt] PR: <description>
• Links are provided if this PR resolves an issue, or depends on another other PR
• If submitting a PR to the dev branch (the default branch), you have a descriptive Feature Branch name using the format: dev-<description-of-change> (e.g. dev-revise-levee-masking)
• Changes are limited to a single goal (no scope creep)
• The feature branch you're submitting as a PR is up to date (merged) with the latest dev branch
• pre-commit hooks were run locally
• Any change in functionality is tested
• Passes all unit tests locally (inside interactive Docker container, at /foss_fim/, run: pytest unit_tests/)
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• CHANGELOG updated with template version number, e.g. 4.x.x.x
• Reviewers requested
• Add yourself as an assignee in the PR as well as the FIM Technical Lead

Merge Checklist (For Technical Lead use only)

• Update CHANGELOG with latest version number and merge date
• Update the Citation.cff file to reflect the latest version number in the CHANGELOG
• If applicable, update README with major alterations

[jameshalgren]

Hi @CarsonPruitt-NOAA, at some point, it might make sense to see if this code could be transformed to python to permit spillover in the library generation step.

@ku22dw

[CarsonPruitt-NOAA]

@RyanSpies-NOAA Hey, just wanted to put this one back on your radar so we can merge this PR. Since we're unlikely to use this tool much, just a quick test is okay.

[RyanSpies-NOAA]

Tested and reviewed