[1pt] PR: Modified HUC processing duration system

[ZahraGhahremani]

This PR improves the current HUC processing duration system by saving the processing time for each HUC separately. This helps prevent collisions that can happen during parallel processing and ensures more accurate, comprehensive results. The new Python script reads all the processing time files and combines them into a CSV. It also adds a summary line at the end with the total runtime, as well as the number of HUCs and branches.

Additions

• src/duration_system.py: This is a new script that reads duration files for each huc and concatenates them into a csv.

Changes

• src/run_unit_wb.sh : Recorded the processing time for branch 0 and saved a separate file for each huc.
• fim_post_processing.sh: Added new lines to execute the new script.

Removals

Testing

Tested for HUCs 05030104 and 10240004.

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

[RobHanna-NOAA]

oops... found a bug. If a branch fails and the branch log file does not exists, the entire system crashes. I suggest, just dropping that branch log data in the total logs counts.

[ZahraGhahremani]

oops... found a bug. If a branch fails and the branch log file does not exists, the entire system crashes. I suggest, just dropping that branch log data in the total logs counts.

Thanks Rob! This script saves the log file for each HUC as we discussed. So, I added a line to solve that issue for failed HUC.

[RobHanna-NOAA]

This is soooo cool and a huge help for me. Major Thanks. Rob