[5pt] PR: Bug fixes for Sierra test (vertical lines)

[ZahraGhahremani]

The vertical lines (recurrence intervals) do not appear in the Sierra test plots. This PR tries to fix this issue as much as possible. Some locations still do not have any vertical lines because they lack USGS rating curve data (missing USGS rating curve data for USGS station x in HUC y). Therefore, this is not a problem.
However, the vertical lines were not plotted previously for some location_ids with more than one feature_id. This FB will always use the first feature_id to plot the vertical lines unless its flow is significantly lower than the USGS maximum flow.

Changes

• tools/rating_curve_comparison.py: Modified the script to make sure vertical lines are displayed.

Testing

I tested this branch for HUCs 05010006, 15050302, 07140104.

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]

If a location_id has more than one feature_id, would it make sense to use the feature_id with the highest flow instead of the first feature_id?

[mluck]

An unrelated issue that this PR highlights is that the scale of the synthetic rating curve before the correction (bottom left) is so large that it masks the informative portion of the SRC as compared with the corrected SRC in the bottom right. All of the information in that gage is contained in the overlapping vertical part of the SRC (red oval), and what variation is displayed is outside of the usable range. Other gages without USGS data, for example the gage in the top row, remain scaled out of range. Should something be done to scale the SRCs so they display useful information?
.

[ZahraGhahremani]

If a location_id has more than one feature_id, would it make sense to use the feature_id with the highest flow instead of the first feature_id?

Carson mentioned to use the feature_id from branch 0 (when it is possible) for consistency.

[ZahraGhahremani]

An unrelated issue that this PR highlights is that the scale of the synthetic rating curve before the correction (bottom left) is so large that it masks the informative portion of the SRC as compared with the corrected SRC in the bottom right. All of the information in that gage is contained in the overlapping vertical part of the SRC (red oval), and what variation is displayed is outside of the usable range. Other gages without USGS data, for example the gage in the top row, remain scaled out of range. Should something be done to scale the SRCs so they display useful information? .

Thank you for highlighting this issue. For the top row, since the purpose is to compare with the USGS rating curve and we don't have that data, we will need to leave them as they are unless you have any other suggestions.