Feature #141 estimate optimal core count

Also fixed bug where number of cores is not saved as 0 when "Set automatically" is checked.

Expected Differences

[X] Do these changes modify the system output in any way? [No]

Pull Request Testing

[X] Describe testing already performed for these changes:

Added unit tests to ensure core number estimates are as expected. Started a cluster and ran jobs that use configs that auto compute number of cores to ensure that logic is being executed properly.

[ec2-user@ip-172-31-28-94 ~]$ wrfcloud-run --job-id W146C654FDD

{"time": "2023-04-10 18:59:35.000 +0000", "message": "Initializing cli environment", "appName": "no_name", "className": "NoClass", "level": "INFO "} 2023-04-10 18:59:35.000 +0000 - INFO - wrfcloud-cli - NoClass - Starting new run "W146C654FDD" 2023-04-10 18:59:35.000 +0000 - INFO - wrfcloud-cli - NoClass - Setting up working directory /data/W146C654FDD 2023-04-10 18:59:36.000 +0000 - INFO - wrfcloud-cli - WrfConfig - Estimate core count: 102 2023-04-10 18:59:36.000 +0000 - INFO - wrfcloud-cli - NoClass - Using 96 cores 2023-04-10 18:59:36.000 +0000 - INFO - wrfcloud-cli - NoClass - Updating job status W146C654FDD Done

[ec2-user@ip-172-31-28-94 ~]$ wrfcloud-run --job-id W83C165E19E

{"time": "2023-04-10 18:59:42.000 +0000", "message": "Initializing cli environment", "appName": "no_name", "className": "NoClass", "level": "INFO "} 2023-04-10 18:59:42.000 +0000 - INFO - wrfcloud-cli - NoClass - Starting new run "W83C165E19E" 2023-04-10 18:59:42.000 +0000 - INFO - wrfcloud-cli - NoClass - Setting up working directory /data/W83C165E19E 2023-04-10 18:59:43.000 +0000 - INFO - wrfcloud-cli - WrfConfig - Estimate core count: 297 2023-04-10 18:59:43.000 +0000 - INFO - wrfcloud-cli - NoClass - Using 96 cores 2023-04-10 18:59:43.000 +0000 - INFO - wrfcloud-cli - NoClass - Updating job status W83C165E19E Done

[X] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:

Configs Upper-midwest_3km_test_auto_compute_cores and caribbean_6km_test_auto_compute_cores can be used to test.

[X] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]
[X] Do these changes include sufficient testing updates? [Yes]

Once other tests are fixed, we could consider adding another test to read from a WPS namelist and ensure the correct core estimate is computed. Also, when we support mulitple domains, more tests could be added to ensure the correct result occurs. The unit tests currently only assume a single domain.

[X] Will this PR result in changes to the test suite? [Yes]
New tests that should pass
[X] Please complete this pull request review by 4/24/2023.

Pull Request Checklist

[X] Review the source issue metadata (labels, project, and milestone).
[X] Complete the PR definition above.
[X] Ensure the PR title matches the feature or bugfix branch name.
[X] Define the PR metadata, as permissions allow. Select: Reviewer(s) Select: Project Select: Milestone as the version that will include these changes Select: Development to link to the original development issue.
[ ] After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
[ ] Close the linked issue and delete your feature or bugfix branch from GitHub. …to determine smallest and largest grids that can be used when support for multiple domains is added. Currently only the first domain is used to estimate core count…to determine smallest and largest grids that can be used when support for multiple domains is added. Currently only the first domain is used to estimate core count…to determine smallest and largest grids that can be used when support for multiple domains is added. Currently only the first domain is used to estimate core count

NCAR / wrfcloud