[1pt] PR: Minor adj to test_case_by_hydroid

[RobHanna-NOAA]

Just a few minor tweaks:

• removed tqdm in favor of an (x of y) output line. Why? when you add print lines inside a for loop with tqdm, the progress bar repaints over and over after each print line. Also added some sorting to the for loop for easier progress tracking.

Changes

• tools\test_case_by_hydroid.py: as described

Testing

Ran it at full scale and validated the outputs for the number of recs inside the FIM Performance catchment output file.

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]

Looks good. Just a comment that the progress bar can be disabled in tqdm() but removing it might be a better solution here.

[mluck]

tqdm() has an optional argument disable=True that will prevent the progress bar from being displayed. But I'm not sure why to keep using tqdm in that case unless you wanted to be able to set disable dynamically (e.g., command-line vs. batch).

[RobHanna-NOAA]

Yes. I knew we could remove it but it will no longer have value, so we are removing it. Generally all of our products will eventually remove tqdm progress bars for the same reason. If you want print statements in a piece of code inside a block with t2dm, it just paints the progress bar with its current status (ie.. 20 of 200), then prints something on the next line(s), then tqdm needs to full repaint the bar to show 21 of 200). It can not update the progress bar, print a value, then come back up to adjust the tqdm. In lieu, I believe it is best just to print lines as "processing 20 of 200"... print, print, "processing 21 of 200".. The point of having these various types of process includes "how far along are we" and "is it still running if we don't see any prints or something for a while".