[1pt] PR: log duration times per module for post processing

[RobHanna-NOAA]

We are having problems with post processing overall duration taking a long time. This new system captures duration times for each module/section inside fim_post_processing.sh and records it to a file on the output directory. It records it as it progress and will also help us learn if fim_post_processing.sh stopped along the way.

Note: When used in code, we call Set_log_file_path shell variable with a file name and path (no validation done at this time). The each time a person wants to print to screen and console, use the l_echo command instead of the native echo command. If the log file has not been set, the output will continue to go to screen, just not the log file.

Changes

• fim_pipeline.sh: A couple of minor text output changes.
• fim_post_processing.sh: As described above.
• src\bash_functions.env: New functions and adjustments to support the new log system.

Testing

Start with a fim_pipeline.sh with any huc is fine. You should see the new post_proc.log file. If you re-run it and overwrite the output, it should create a whole new replacement post_proc.log file. It should also clear if if you re-run, just fim_post_processing.sh

Deployment Plan (For developer use)

How does the changes affect the product?

• Code only?
• 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?
• If applicable, has a deployment plan be created with the deployment person/team?

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
• n/a - 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)
• n/a - 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

[mluck]

Looks good. Runs as expected, nice to see the logging as it's running.