WIP [1pt] PR: Dissolve unilateral catchments

[mluck]

Unilateral catchments i.e., catchments that only capture one side of the floodplain, are identified and adjacent, sequential catchments that are on alternating sides (left, right) are dissolved. Attributes of dissolved catchments are updated.

Closes #1540.

Additions

• src/dissolve_unilateral_catchments.py: identify and dissolve unilateral catchments

Changes

• src/
  • delineate_hydros_and_produce_HAND.sh: integrates dissolve_unilateral_catchments
  • mitigate_branch_outlet_backpool.py: accommodate MultiLineStrings

Testing

Results from a UAT will be posted in the comments below.

Deployment Plan (For developer use)

How does the changes affect the product?

• Code only?
• If applicable, has a deployment plan be created with the deployment person/team?
• Require new or adjusted data inputs? Does it have start, end and duration code (in UTC)?
• If new or updated data sets, has the FIM code been updated and tested with the new/adjusted data (subset is fine, but must be a subset of the new data)?
• Require new pre-clip set?
• Has new or updated python packages?

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
• 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
• 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

[mluck]

An example of the dissolved catchments. The original catchments include the black and red catchment boundaries, and the red lines are removed in the dissolving process

[mluck]

Evaluation against the NWS benchmark shows an improvement at lower flows, but the BLE benchmark shows a decline in skill at higher flows.

[mluck]

Comparison between v4.7.4.6 (blue) with other layers shown in orange (purple is both layers agree):

• v4.7.4.6 with longitudinal flow correction off (left),
• dev-dissolve-unilateral-catchments (center)
• dev-dissolve-unilateral-catchments with longitudinal flow correction off (right).

v4.7.4.6 catchments are in red and dev-dissolve-unilateral-catchments are in black.

Turning longitudinal flow correction off tends to decrease inundation and dev-dissolve-unilateral-catchments tends to increase inundation.

A similar, but less pronounced difference is seen in a different HUC for v4.7.4.6 with longitudinal flow correction off (left), dev-dissolve-unilateral-catchments (top right), and dev-dissolve-unilateral-catchments with longitudinal flow correction off (bottom right).

[mluck]

Updated results for v4.8.10.0, comparing this branch with the current mean reach length of 1500m as well as increasing it to 3000m. For the 1500m stream length comparison with dev, the circles indicate catchment boundaries that have been dissolved by this feature branch.

With the mean stream length set to 3000m, this feature branch had no effect (i.e., the catchment were the same at 3000m both with and without this feature branch). 3000m produces larger catchments and these are not unilateral; however, it may be that the 3000m reach length may still be subject to producing unilateral catchments if the sinuosity period is longer, for example in a larger river system, where this feature branch may still have benefit.

[mluck]

Here's an example of the difference in synthetic rating curves between two catchments in v4.8.10.0 (solid lines) that are dissolved into one catchment (dashed lines) for the catchments highlighted in red [HUC 11070203, branch 2090000006, hydroIDs 23230033 and 23230034]

[mluck]

Another example SRC comparison for HUC 05120206, branch 1844000003, hydroIDs 16180034 and 16180035

[mluck]

Metrics from comparing dissolving unilateral catchments with increasing the mean reach length to 3000m (from 1500m): dissolving unilateral catchments is nearly identical, but slightly worse than v4.8.10.0, while increasing the mean reach length performs a bit worse.