reuploading changes for bounds of derived variables

[HGWright]

🚀 Pull Request

Description

I seem to have royally screwed up the old PR for this. So here are all of the relevant current changes for that.

Will copy over all of the discussions from the PR soon.

---

Consult Iris pull request check list

---

Add any of the below labels to trigger actions on this PR:

• benchmark_this Request that this pull request be benchmarked to check if it introduces performance shifts

[codecov]

Codecov Report

❌ Patch coverage is 29.33333% with 53 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.60%. Comparing base (da199ee) to head (82be35f).
⚠️ Report is 218 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/iris/fileformats/cf.py	28.37%	49 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6350      +/-   ##
==========================================
- Coverage   89.79%   89.60%   -0.20%     
==========================================
  Files          90       90              
  Lines       23554    23608      +54     
  Branches     4391     4411      +20     
==========================================
+ Hits        21150    21153       +3     
- Misses       1662     1710      +48     
- Partials      742      745       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[pp-mo]

Note (for my benefit!)
This basically replaces #6190

This comment is a useful summary of the agreed behaviour we should be delivering
-- plus the statement, just previous
"We can also avoid making this save to the best version of CF until a later date"
-- which means, as I read it, no change to saving at all (for now)

[stephenworsley]

Just a couple notes on places to improve the code. As mentioned offline, the major thing this needs now tests. It's worth pushing something up demonstrating expected behaviour even if they're currently failing.

[stephenworsley]

if you reach this point you will have a standard name, so or cf_root_var.long_name is unnecessary.

[stephenworsley]

I feel like this is probably not necessary. Would you not want to do something like bounds_name = getattr(cf_root_coord, "bounds", default=None)?

[stephenworsley]

Ultimately, I think you'll probably want to replace this try-except call. I expect you ought to be able to replace this with something like:

bounds_vars = [...]
if len(bounds_vars) == 1:
  bounds_var = bounds_vars[0]
  ...
else:
  ...

[trexfeathers]

A reminder, the work of #6317 is relying on certain behaviour of cf.py:

Note that I have checked cf.py and believe it can remain unchanged. This has a defensive philosophy already, which involves checking if variables can be interpreted as different types, and the remainder are all represented as CfDataVariables, so we already have an existing fallback in place. Anything here that is not formatted correctly just shows up as extra Cube(s) in the loaded CubeList.

If you need to break the above 'contract' please make me aware as I'll need to re-scope my work. Last I checked @HGWright was hopeful we could keep this behaviour though 🤞

[pp-mo]

A reminder, the work of #6317 is relying on certain behaviour of cf.py:

Note that I have checked cf.py and believe it can remain unchanged. This has a defensive philosophy already, which involves checking if variables can be interpreted as different types, and the remainder are all represented as CfDataVariables, so we already have an existing fallback in place. Anything here that is not formatted correctly just shows up as extra Cube(s) in the loaded CubeList.

If you need to break the above 'contract' please make me aware as I'll need to re-scope my work. Last I checked @HGWright was hopeful we could keep this behaviour though 🤞

I don't think the framework of the behaviour will need to change.
Obviously, actual code + details of how it handles specific cases will

[HGWright]

This is superseded by #6481. That makes all of the changes and more from this PR.