iotaa v1.1.0 update

[maddenp-noaa]

Synopsis

Update iotaa version.

The iotaa v1.0.0 release revamped internals to use an actual graph data structure (graphlib.TopologicalSorter from the Python standard library), which made it possible to first assemble a graph of task nodes and then inspect it to remove duplicate nodes, which appear when multiple tasks declare "the same task" as a common requirement. This also allowed the elimination of global state in iotaa, which made it non-thread-safe. Tasks now execute without being interrupted by the execution of requirement that followed from iotaa's old greedy-execution algorithm. Log output was simplified and improved. Use of a graph data structure also made concurrency possible.

The iotaa v1.1.0 release added thread-based concurrency. This PR doesn't add the use of concurrency to uwtools, but it is an option for future work. For example, IO-bound activities like file copies could benefit from thread-based concurrency.

This PR is not meant to change uwtools behavior, just to interface with the updated iotaa correctly. I'll mark it as a breaking change, though, because coupled drivers that provide their own iotaa tasks may need to make minor updates. I'll contact the Coastal App team about this when uwtools v2.6.0 is released.

A minor bug is fixed here, though: In the previous iotaa version, common required tasks (e.g. tasks file1 and file2 both require task directory to create the directory in which their files will be created) would previously have been executed multiple times, as iotaa was not able to correctly deduplicate them. This was basically harmless given the idempotence of tasks, but would result in multiple checks of those common tasks' readiness, and associated log messages, which might have been confusing. I think this was rare-to-nonexistent in uwtools, but was lurking as an oddity/annoyance.

This will need to be on-hold until conda-forge builds the iotaa v1.1.0 package, which is queued in their CI system.

Type

• Bug fix (corrects a known issue)
• Code maintenance (refactoring, etc. without behavior change)
• Documentation
• Enhancement (adds new functionality)

Impact

• This is a breaking change (changes existing functionality)

Checklist

• I have added myself and any co-authors to the PR's Assignees list.
• I have reviewed the documentation and have made any updates necessitated by this change.

[elcarpenterNOAA]

I like the new log output!

[christinaholtNOAA]

LGTM.

[maddenp-noaa]

@christinaholtNOAA You have to run a task to see its graph, but you can do it in dry-run mode to avoid making any changes, e.g. via the CLI (and similarly for the API)

$ uw ungrib run --cycle 2025-01-28T12 --config-file docs/shared/ungrib.yaml --dry-run --graph-file demo.dot 2>/dev/null
$ dot -Tpng demo.dot >demo.png

produces the attached image.